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

时间:2014-03-27 20:37:24

标签: architecture uml diagram

我的CS软件架构类团队项目提交了一个"架构图表"对于我们的项目。我们正在设计一个在线DAW(数字音频工作站)。

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

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

如果有人对如何改进这一点有任何想法,或者如果有人能提供正确的架构图包含的好例子,请回复并告诉我们!

谢谢! Kameron

1 个答案:

答案 0 :(得分:1)

记录软件架构的一些常见最佳实践,在我的头脑中......

  1. 图表应表达特定的视图(在某些文本中也称为透视图),并清楚标明图表显示的视图。 (例如,这是动态的,静态的还是物理的?或者......组件和连接器,模块或分配?)
  2. 只有视图才能显示在图表中。例如,数据库无法连接到代码包。一个是运行时结构,另一个是静态/代码结构。
  3. 应明确定义符号,通常在图例中。即使您使用的是"标准"来自UML的符号。
  4. 符号应该是一致的,至少在图表内部,如果不是整个文档集。这意味着例如一个图中的框或虚线表示与其他图中相同的元素或关系。
  5. 应使用多个视图来传达不同的抽象粒度。架构描述将包含多个视图,每个视图至少有一个视图。
  6. 元素和关系的责任应明确阐述,通常在“元素 - 责任目录”中。"我想创建一个表格,更详细地描述图表中各种元素和关系的责任。例如,"数据库负责持久存储用户信息。"
  7. 描述性散文,包括基本原理,应描述所作出的关键决策(通常但不一定在图中描述),并提供解释为何做出决定的理由,包括未考虑的替代方案。在最好的情况下,将与明确的建筑驱动程序建立明确的联系。例如,"我们选择使用缓存库X来支持性能质量属性场景XYZ ......"
  8. 参见" Documenting Software Architecture: Views and Beyond"对于"权威"参考。如果您想使用UML来记录您的架构,请参阅" Just Enough Software Architecture: A risk-Driven Approach"的第二部分。对于受试者的良好治疗。每本书可能都有相关的在线章节,但它们值得拥有。

    根据上述最佳做法批评您的具体图表。

    • 没有传说,盒子,线条和圆圈是什么意思?虚线,箭头和扁线之间有区别吗?
    • 视角是什么?我看到所有引用的层,客户端,服务器和可能的代码模块。你可能有不同的观点。
    • 抽象的混合粒度 - 首先是"层"不能使用"客户" (一个是静态的,另一个是动态的,虽然我猜你想要表示某种层次关系?)。树的每个级别可能是不同的视图,显示您的抽象的更精细的粒度。
    • 没有理由或描述性散文。
    • 不了解要素或责任。

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

    从积极的方面来看,您似乎对系统有了很好的理解,您只需要一些帮助,找出如何使用架构最佳实践将其全部写下来!