软件设计—画图

本文绝大部分引自《程序员必读之软件架构》,这本书记录的很散乱无章,不是特别推荐的一本书,但是这本书也有一个亮点就是对软件设计过程中画图的问题进行了比较好的讲解,记录成此文。

可视化一个软件系统的架构是极少数人具备的技能。很多人都可以画图,但他们画的图往往有太多想象空间,也几乎没有人使用正规的图标符号来描述他们的解决方案

我是一个非常视觉化的人, 属于后一个阵营。 我喜欢在试图找到解决方案之前, 先将问题可视化。 向我描述业务流程, 我会勾画一个总结出来。 跟我谈商业问题, 我会画一个高层次领域模型。 对我来说, 可视化问题的一个方法是提问, 搞清楚我是否明白你在说什么。 我也喜欢把解决方案画出来, 因为它是让一切都公开化、 帮助 其他人迅速理解的好方法。

无效的草图

采购清单

没有太多方案内容,基本上只是技术采购清单

只有框没有线

能看出分层设计,但没有职责和交互。软件架构是关于结构的,是事物( 框)以及它们如何相互作用( 线)。

功能图

能看出分模块设计,但没有职责和交互。软件架构是关于结构的,是事物( 框)以及它们如何相互作用( 线)。

航线图

已经表明了输入输出交互,只是有些不标准的图示和未标明设计(右侧有个圈看起来很重要,所有东西都连向它,但没标明它是什么)

接近正确

已经很有“软件架构入门”风格,但要明确业务领域,不存在“总线逻辑”这样的业务

推迟技术

展示了软件架构的整体形态(包括职责),但忽略了技术选型

独立部署和执行上下文

图中框图右上角标注的unix和jar标记都是部署方案,而不是执行方案

太多假设

连线没有表明如何进行通信,RESTful API?SOAP?RPC?异步消息?

无家可归的对象

没有为各个模块画一个大框框起来(如web服务,应用程序等更高层次的框)

选择你的冒险

系统异常复杂,想用一张图表达一切,至少不同流程要用不同颜色

使用UML可以避免很多这样的陷阱,但现在似乎没有太多人有热情去学习这东西。简单而有效的软件架构草图是每个人都可以完成的,所需的不过是一些简单的建议和一组通用的抽象。

C4画图:语境(系统)、容器、组件、类

C4 不是用一张图表示所有事情,而是希望建立一套不同层级级抽象图。

语境图

为什么要画这张图?

语境图可以回答如下问题:

如何画交互?

语境图的一个示例如下:

在语境图的绘制过程中,细节不重要,重点放在人和软件系统上,而不是技术、协议和其他底层细节。

容器图

为什么要画这张图?

容器图可以回答下面的问题:

容器图可以指明如下内容:

如何画交互?

容器图的一个示例:

组件图:

为什么要画这张图?

组件图可以回答如下问题:

对于组件图中绘制的每一个组件,你都可以指定:

如何画交互:

组件图的一个示例:

PS:以上C4示例的架构图,作者是配了一套完整的程序的,https://github.com/techtribesje/techtribesje

联系我: