框图是如何组织的？
我想了解框图的确切层次结构。
如果块 A 位于块 B 之上，是否意味着 A 是以某种抽象方式使用 B 构建的？
一个具体问题：
我有一个组件 C，它调用组件 D、E 来实现其目标。 C 是在 D、E 之上（因为它使用了它们）还是这些不同的不相关块？每种情况是什么时候？ aD、E 不是 C 构建的平台，而只是 C 所使用的东西。
令我不安的是，我通常会看到带有大基础块和许多小“屋顶”块的框图，例如框架基础和其上的许多功能。然而，在我的示例中，如果每个组件都是使用另外两个组件构建的，那么我最终会得到一个包含许多块和一个“屋顶”的底座。或者，我最终会得到不相关（非分层）的块，这似乎错过了该图的目的（或者确实如此？）。
I would like to understand the exact hierarchy of a block diagram.
If a block A is on top of block B does it mean that A is in some abstract manner build using B?
A concrete question:
I have a component C that calls components D,E to achieve its goal.
Is C on top of D,E (since it uses them) or are these different unrelated blocks? When would be each case? aD,E are not a platform that C is build on but just something it uses.
What disturbes me is that I usually see block diagrams with a big base block and many small "roof" blocks, e.g. a framework base and many features over it. However in my example if every component is build using 2 others I would end up with a base containing many blocks and one "roof". Alternatively I would end up with unrelated (non hierarchical) blocks which seems to miss the purpose of this diagram (or does it?).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当您使用 UML 设计应用程序视图时，块和屋顶具有实际名称。 UML 使用类之间的线条上的装饰来表示它们的关系。通常，该关系是“是”或“具有”关系。它派生自另一个类，或者它有另一个类作为成员变量。
在图表的实际使用中，为了在给定的图表上清楚地传达给定的想法，大量的类通常会被省略。当我制作涉及特定焦点的类图时，我经常忽略类层次结构。通常需要大量图表才能完整描述一个应用程序，您甚至可以完全排除某些类并将其记入实现细节。
我强烈建议您研究 UML 的组件图、类图，然后继续研究您会发现有用的其他样式，包括：状态图、序列图和用例图。最重要的是，大多数开发人员都见过这些，或者以前使用过它们。
Blocks and roof have actual names when you are using UML to design your view of the application. UML uses decorations on lines between classes to denote their relationship. Typically the relationship is either a 'is a' or 'has a' relationship. It derives from another class, or it has another class as a member variable.
In practical uses of diagrams, a large amount of classes are often left out of the picture in order to clearly communicate a given idea on a given diagram. I often leave out a class hierarchy when I'm making a class diagram concerning a particular focus. It usually takes a large number of diagrams to fully describe an application, and you can even exclude some classes completely and chalk it up to implementation details.
I would highly recommend looking into UML's component diagrams, class diagrams, and then continue on to other styles that you will find useful including: state diagrams, sequence diagrams, and use case diagrams. The great part is that most developers will have seen these, or worked with them before.
如果您指的是大型代码库的整体架构图，那么就没有这样的标准。例如，在您的示例中，如果 D 和 E 位于同一级别，它们可以互相使用吗 - 您会看到两者都被使用。 Structure101 使用的约定是单元格只能使用其下方的单元格 - 实际代码中的任何向上依赖项都会在图表（和 IDE 中）上标记为“违规”。
如果通过架构您正在考虑类之间的关系，那么 UML 就是您想要的，框之间的箭头指定什么/应该使用什么以及如何使用...
If you mean architecture diagrams as in the big picture of a large-ish code base, then there is no standard as such. For example in your example, if D and E are on the same level, can they use each other - you'll see both used. Structure101 uses the convention that cells should only use cells below them - any upward dependencies in the actual code are flagged on the diagram (and in the IDE) as "violations".
If by architecture you're thinking of the relationship between classes, then UML is what you want and the arrows between the boxes specifies what does/should use what and how...
框图有一个技巧。
他们只是营销。
如果你想要精确的语义，你必须使用UML，它不使用带有简单随意的“之上”的框图。 “在……之上”显然太模糊了。
如果您有一个“金字塔”，并且您不想显示它，那么您的较低级别的块就太细粒度了。
将详细的较低级别块集中到更大的框架块中。那么底部的大块就可以少一些。
There's a trick to block diagrams.
They're just marketing.
If you want precise semantics, you have to use UML, which doesn't use block diagrams with simple casual "on top of". The "on top of" is clearly too vague.
If you have a "pyramid", and you'd rather not show that, then your lower-level blocks are too fine-grained.
Lump the detailed lower-level blocks into a bigger framework block. Then you can have fewer big blocks on the bottom.