Uml/sequence/package/... JavaScript 和 Electron 应用程序的图表替代方案?
我的问题是我是否可以绘制任何图表来可视化和 Electron/JavaScript 应用程序?
My question is if there are any kind of diagram I could draw in order to visualise and Electron / JavaScript application?
对于不同的 uml 图，我需要替代方案，例如类图或包图，但由于 JS 是基于原型的，它不像 Java 或 C#，我不知道我能做什么.
I would need alternative for the different uml diagrams, like class or package diagram but since JS is prototype-based and it's not like Java or C# I don't know what I could do.
我唯一能做的就是一个序列图，但我也应该(可能必须)做其他的图.
The only one I might be able to make is a sequence diagram, but I should (probably must) make other diagrams as well.
推荐答案
首先，您根本没有义务在 UML 图中记录所有内容.因为工作软件比综合文档更重要.但是，UML 可以非常有用地突出您的软件中一些不容易在代码中找到的不那么琐碎的方面.我的建议是关注这些方面.
First of all, you're not obliged to document everything in UML diagrams at all. Because working software is more important than comprehensive documentation. However, UML can be extremely useful to highlight some less trivial aspects of your software that can not be easily found in the code. And lmy advice would be to focus on these aspects.
现在，您应该在 UML 中做什么取决于您打算在模型中表示什么，以及您如何使用 js.
Now what you should do in UML all depends on what you intend to represent in your model, and how you're using js.
UML 区分 结构图软件的静态视图和 行为图它的动态.
UML distinguishes structure diagrams to show the static view on your software and behavioural diagrams to show its dynamics.
这可能对你没有吸引力，因为 JS 基于原型与 UML 相当静态的基于类的视图相反，它在类型逻辑方面提供了极大的灵活性.
This could be less attractive to you, since JS is prototype-based and offers a great flexibility regarding the typing logic in contrary to the rather static class based view of UML.
尽管如此，您仍然可以从类的概念中受益并使用 类图为了显示您的设计意图(即您对对象分类的心理看法)或用于实例化对象的原型(尤其是如果您设计一些对象本质上充当原型，使它们事实上作为类的代表).当然，如果您的 JS 设计根本不是面向对象的，那么将您的程序映射到 OO 概念是没有意义的(请参阅 这里).
Nevertheless, you could still benefit from the concept of classes and use class diagrams in order to show either your design intent (i.e. your mental view on the object categorisation) or the prototype used to instantiate objects (especially if you design some objects to act essentially as prototype, making them de facto as representatives for classes). Of course, if your JS design is not at all object oriented, it would make no sense to map your program to OO concepts (see here).
请注意，旧版对象图可以对你来说更有意义，因为它可以解释对象而不是类之间的关系(另请参阅此处)
Note that the legacy object diagram could make more sense for you, since it allows to explain the relations between objects rather than classes (see also here)
在这两种情况下，您可能对使用依赖关系 有助于将静态元素(即对象或类)链接到行为意图.
In both cases, you may be especially interest in usage dependencies that help to link the static elements (i.e. objects or classes) to the behavioural intent.
最后包图可以用来展示.js 文件及其依赖关系的大图.它不是传统 java 包的意义，但也可能有用.
Finally package diagrams could be used for example to show the big picture of your .js files and their dependencies. It's not in the sense of the traditional java packages, but could also be useful.
在这里，我会假装所有这些图表都对你有意义.
Here, I would pretend that all these diagrams could make sense for you.
我首先想到的是序列图.因为它有助于可视化多个对象之间的预期交互，而这些仅通过浏览代码很难找到.
The very first that comes to my mind is the sequence diagram. Because it helps to visualise expected interactions between several objects, and these are difficult to find out just by browsing through the code.
在某些情况下，状态机图可以帮助好.如果行为取决于某个状态变量，或者如果您想显示对象的完整生命周期，这将特别有意义.
In some cases, the state machine diagram could help as well. This makes particular sense if the behaviour depends on some state variable, or if you want to show the full lifecycle of an object.
最后，您可以考虑活动图.如果您想显示系统中的控制流或对象流，这些特别有用.如果您不熟悉它们，并且简化到极端，它是一种超级流程图，但是箭头不仅代表下一个操作"，还可以代表在操作之间传递的对象.
Finally, you can consider the activity diagram. These are especially useful if you want to show the flow of control or of objects across your system. If you're not familiar with them, and to simplify to the extreme, it's a kind of super-flowchart, but where the arrows not jus represent "next operation" but could also represent objects that are passed between operations.
相关文章