软件架构图的适当格式/内容是什么？

Question

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

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

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

如果任何人对如何改进这一点有任何想法，或者如果任何人可以提供一个正确的架构图所包含的良好示例，请回复并让我知道！

谢谢!卡梅隆

Answer 1

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

1. 图应该表达特定的视图(在某些文本中也称为透视图)，并清楚地标记出图中显示的视图。(例如，这是动态的、静态的还是物理的？或者..。视图中的component & connector、module或allocation?)
2. Only应该显示在图表中。例如，数据库不能连接到代码包。一个是运行时结构，另一个是静态/代码structure.
3. Notations应该清楚地定义，通常在图例中。即使您使用的是“标准”符号，例如来自UML.

的

1. 符号，也应该保持一致，如果不是整个文档集的话，至少在图内部是一致的。这意味着，例如，一个图中的框或虚线表示与其他diagrams.
2. Multiple视图中相同的元素或关系，应该使用它们来表达不同的抽象粒度。体系结构描述将由多个视图组成，元素和关系的每个perspectives.
3. The职责至少有一个视图应该清楚地表达出来，通常在“元素-职责目录”中。我喜欢创建一个表，更详细地描述图中各种元素和关系的职责。例如，“数据库负责持久存储用户information."
4. Descriptive散文，包括原理，应该描述所做的关键决策(通常但不一定在图表中描述)，并提供解释为什么做出决策的原理，包括未考虑的替代方案。在最好的情况下，会有一个清晰的连接返回到明确的架构驱动程序。例如，“我们选择使用缓存库X来支持性能质量属性场景XYZ..."

参见"Documenting Software Architecture: Views and Beyond“中的”确定的“参考。如果您想要使用统一建模语言来记录您的体系结构，请参阅"Just Enough Software Architecture: A risk-Driven Approach“的第二部分，以获得对该主题的很好的论述。每本书可能都有相关的在线章节，但它们是值得拥有的。

要根据上面的最佳实践对您的特定图表进行评论...

• 没有图例，方框、线条和圆圈是什么意思？虚线、箭头和扁平线之间有区别吗？
• 视角是什么？我看到层、客户端、服务器，可能还有代码模块都被引用了。您可能有混合的perspectives.
• Mixed抽象粒度--首先，“层”不能使用“客户端”(一个是静态的，另一个是动态的，尽管我猜您打算表示一种层次关系？)。树的每一层可能是不同的视图，显示abstraction.
• No基本原理或描述性行文的更细粒度。
• 不理解元素或元素的responsibilities.

如果您打算使用UML图，我建议您清楚地标记您正在使用的图，并且仍然为符号包含一个图例。并不是每个阅读您的文档的人都记住了所有的UML图表符号。

从积极的方面来看，您可能对系统有很好的理解，您只需要一些帮助来弄清楚如何使用体系结构最佳实践将其全部写下来！