
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
架构图是程序员在开发软件的时候会经常用到的一个开发工具,而今天我们就通过案例分析来了解一下,架构图设计都有哪些注意事项。
保持架构图的结构一致性和语义一致性
架构图之间应该在方框、形状、边框、线条、颜色等方面保持一致。架构图的结构外观应该是一样的,团队不同成员创建的架构图不应该给任何一个利益相关者造成理解上的障碍。理想情况下,可以在所有项目里使用相同的建模工具。
从语义角度来看,所有的架构图与新的代码变更之间以及架构图与架构图之间都应该定期保持同步,因为一个架构图的变更可能会影响到其他架构图。同步可以通过手动进行,也可以通过建模工具自动触发。通过建模工具自动触发会更好一些,不过这也取决于具体的项目。终的目的是要保持架构图和代码之间的一致性,至于使用什么样的方法或工具可以自行决定。
避免架构图碎片化
架构图越多就越难以理解,而且维护起来也很费劲。直接的后果就是有可能出现碎片化(比如,通过两到三个架构图来描述同样的质量属性——性能、伸缩性,等等——但每一个架构图都无法完整地描述它们)。在这种情况下,建议移除不能反映相关质量属性的架构图,或者把它们合并起来。
保持架构图的可追踪性
保留架构图的变更记录、比较不同版本架构图之间的不同点,以及可以很容易地进行回退,这些都是很重要的。如果建模工具不支持这几点,那么对我们来说可能会是个问题。近业界倾向于使用简单而直接的文本语言来生成架构图,这样似乎可以解决可追踪性问题。这样做的另一个好处是可以保持架构图之间的结构一致性。
在架构图旁边加上图例
如果你没有使用标准的架构描述语言(比如UML、ArchiMate),那么就要在图例里注明每个架构图元素的用意(比如方框、形状、边框、线条、颜色、缩略语,等等)。
如果使用了标准的架构描述语言,只要在图例里添加关键性的架构描述,不需要太多额外的信息,因为看图的人都知道如何按照标准的描述语言规范来理解你的架构图。
使用架构描述语言(比如UML、ArchiMate等)会有不一样的效果吗?
关于如何在项目里使用正确的架构描述语言有很多不同的看法。有些人认为UML太过死板,用来做架构设计缺乏灵活性,在某种程度上我认同这个看法。有时候,在不依赖UML的profile和stereotype特性的情况下也能很好地完成架构图设计。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。