软件架构图的艺术
201 浏览量
2021-01-27
16:29:46
上传
评论
收藏 188KB PDF 举报
软件架构图的艺术软件架构图的艺术
要点
1.设计软件架构图并非一件轻而易举的事情，即使是很简单的一个架构图也可能会出错。有意义且具备一致性的架构图有助于
为不同的利益相关者澄清事实，并达成共识。
2.在大多数情况下，问题的根源并不在于是否使用了一门有效的架构描述语言（比如UML），而在于低估了架构图的重要性，
转而依赖不恰当或不具备一致性的指导性原则，或者缺乏架构思维。
3.在创建架构图的过程中，试着混合使用自动生成的图元和手动创建的图元，这样可以减少工作量，并且可以表达出各方面的
关注点，覆盖到系统的各个层面。
4.系统不断地发生演化，要维护更新架构图需要花费额外的精力。我们需要知道如何有效地应对这种情况，同时能够保持架构
图的一致性和健壮性。
5.现代的软件架构带来了更多的复杂性，这些都反映在了架构图上。
曾几何时，我们的每一个软件项目都需要一个架构图。不管我们是否遵循正式的架构模型（比如Kruchten 4+1、Rozanski &
Woods等），都有必要通过图表来对应用程序的某些部分进行文档化。在软件架构里，这些图表一般都是按照某些视图进行
设计的，这些视图本身就是模型的一部分，不过在这篇文章里，我倾向于使用架构图这个术语，因为它看起来不是那么正式，
至于其他方面的内容并不会在这篇文章里涉及到。
作为一个软件架构师和技术培训师，从我的经验来看，不同项目之间以及同一个团队的不同开发人员之间创建架构图的方式也
是很不一样的。我看到过很多问题，比如一致性问题、碎片化问题、信息粒度大小的问题，以及图表的外观问题。相比架构模
型的正式和标准化，架构图倒是不必要那么正式或者遵循什么标准。
与100+国内外技术专家探索2017前瞻热点技术
不过，架构图必须是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。这也就是为什么架构师或软件工程师
在创建架构图时需要依赖各种指导性原则，因为它们是理解应用架构（比如结构、元素、关系、属性、原则）的基石，同时也
是具有不同技术背景和关注点的利益相关者的沟通基础。
当前架构图的不足之处
在深入展开说明之前，我想引用一句英语谚语：“一张图片胜过千言万语”。Wiki上解释说，“这句谚语的意思是，一个复杂的想
法可以通过一张静态的图片表达出来，或者图片可以表达一个主题的意思，又或者图片比文字描述来得更加直接有效”。对于
架构图来说也是一样的：如果它所导致的疑问比它能解释的问题还要多，那么它就不是一张好的架构图。一张好的架构图不需
要多余的文字解释！
图片：一张不是很好的架构图一般会存在如下几个问题。
现在让我们来过一下不好的架构图都有哪些问题，这些问题会阻碍我们创建好的架构图。
方框或其他形状表示什么意思？
随意使用方框或其他形状可能会引起误解。这些形状有可能表示数据、代码或者流程。一个简单的方框可能会引起多种猜想，
所以很有必要显式地给这些形状添加有意义的说明。
形状的边线表示什么意思？
在一个糟糕的架构图里，形状的边线（虚线、点线，等等）可能会引起误解。边线是否表示某种组件类型（比如虚线表示容
器、微服务、层，等等），或者只是因为设计者想让架构图的观感看起来更加丰富一些？所以，在使用多种边线或非标准边线
评论0