软件架构图的正确格式/内容是什么？

Question

我的 CS 软件架构课程团队项目已为我们的项目提交了“架构图”。我们正在设计一个在线 DAW（数字音频工作站）。

我将我们制作的图表通过电子邮件发送给教授以征求建议，但他的唯一回复是“这不是架构图表”，所以这并不是很有帮助。

我将一个链接粘贴到下面的图表，以便每个人都可以查看它。 http://www.webkam.us/images/ArchChart.png

如果有人对如何改进这一点有任何想法，或者如果有人可以提供一个很好的例子来说明正确的架构图包含什么，请回复并告诉我！

谢谢！ 卡梅隆

Answer 1

记录软件架构的一些常见最佳实践，我的脑海中浮现...

1. 图表应表达特定的视图（在某些文本中也称为透视图），并清楚地标记图表显示的视图。 （例如，这是动态的、静态的还是物理的？或者……组件和连接器、模块还是分配？）
2. 仅在视图中应显示在图表中。例如，数据库无法连接到代码包。一种是运行时结构，另一种是静态/代码结构。
3. 符号应明确定义，通常在图例中。即使您使用的是诸如 UML 之类的“标准”符号。
4. 符号应该是一致的，如果不是整个文档集的话，至少在图表内部是一致的。这意味着，例如，一个图中的框或虚线表示与其他图中相同的元素或关系。
5. 应使用多个视图来传达不同粒度的抽象。架构描述将包含多个视图，每个视图至少一个视图。
6. 元素和关系的职责应明确表述，通常在“元素职责目录”中。我喜欢创建一个表格，更详细地描述图表中各种元素和关系的职责。例如，“数据库负责用户信息的持久存储。”
7. 描述性散文，包括基本原理，应描述做出的关键决策（通常但不一定在图表中描述），并提供解释为什么做出决策的基本原理，包括未考虑的替代方案。在最好的情况下，将与明确的架构驱动程序建立明确的联系。例如，“我们选择使用缓存库 X 来支持性能质量属性场景 XYZ...”

请参阅“Documenting Software Architecture: Views and Beyond”以获取“权威”参考。如果您想使用 UML 来记录您的体系结构，请参阅“Just Enough Software Architecture: A risk-Driven Approach”的第 II 部分，以获得对该主题的良好处理。每本书网上可能都有相关章节，但都值得拥有。

根据上述最佳实践来评论您的特定图表......

• 没有图例，方框、线条和圆圈是什么意思？虚线、箭头和扁线之间有区别吗？
• 什么是透视图？我看到层、客户端、服务器和可能的代码模块都被引用了。您可能有不同的观点。
• 混合粒度的抽象——首先，“层”不能使用“客户端”（一个是静态的，另一个是动态的，尽管我猜你打算表示一种层次关系？）。树的每一层都可能是一个不同的视图，显示出更精细的抽象粒度。
• 没有理由或描述性散文。
• 不了解元素或其职责。

如果您要使用 UML 图，我建议您清楚地标记您正在使用的图，并且仍然包括表示法的图例。并非所有阅读您文档的人都记住了所有 UML 图表符号。

从积极的方面来说，您似乎对系统有很好的了解，您只需要一些帮助来弄清楚如何使用架构最佳实践将其全部写下来！