软件设计—画图

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

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

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

无效的草图

采购清单

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

只有框没有线

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

功能图

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

航线图

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

接近正确

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

推迟技术

展示了软件架构的整体形态（包括职责），但忽略了技术选型

独立部署和执行上下文

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

太多假设

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

无家可归的对象

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

选择你的冒险

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

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

C4画图：语境（系统）、容器、组件、类

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

• 语境（系统）

  • 代表最高层次的抽象，一个系统由多个容器构成

  • 设定场景，包括系统关键的依赖和参与者

• 容器

  • 一个容器代表一个可以独立运行的东西或者是数据驻留的东西，不同容器间的通信往往需要网络通信，如RPC，Restful接口，RMI等

  • 显示高层次技术选型，容器如何分担职责，如何进行通信

• 组件

  • 由一个类或多个类组成的逻辑群

  • 容器内关键逻辑组件及其关系

• 类

  • 面向对象系统里的最小单元

  • 可选的实现细节，通常是类似UML的草图

语境图

为什么要画这张图？

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

• 构建的软件系统是什么？

• 谁会使用它

• 如何融入已有IT环境

• 语境图可以作为与非技术人员沟通讨论的基础，也是系统接口定义的一个讨论起点。

如何画交互？

• 借助一些关于目标的信息，对标注交互行为（ 用户 <-> 系统、系统 <-> 系统，等等）非常有用，而不仅仅是由一堆框和意义不明的连接线组成的图。

语境图的一个示例如下：

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

容器图

为什么要画这张图？

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

• 软件系统的整体形态是什么样的？

• 高层次技术决策有哪些？

• 职责在系统中如何分布？

• 容器之间如何相互交流？

• 为了实现特性，作为一个开发者， 我需要在哪里写代码？

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

• 容器名称

• 容器的技术选择（独立终端进程，tomcat，mysql）

• 容器职责的高层次说明或清单

如何画交互？

• 容器间的交互通常是进程间交互，要表明以下信息，不要只是模糊的使用一些线和框

• 交互的目的（ 如“ 读/ 写 数据”、“ 发送 报告“ 等）；

• 通信方法（ 如 Web 服务、REST、Java远程方法调用、Windows通信基础、Java消息服务）；

• 通信方式（ 如同步、异步、批量、两阶段提交等）；

• 协议和端口号（ 如 HTTP、 HTTPS、 SOAP/ HTTP、 SMTP、 FTP、 RMI/ IIOP 等）。

容器图的一个示例：

组件图：

为什么要画这张图？

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

• 系统由哪些组件/服务组成？

• 在高层次上，系统如何工作是否清晰？

• 所有组件/服务都驻留在哪一个容器 中？

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

• 名称：组件的名称（ 如“ 风险 计算器”、“ 审计 组件” 等）；

• 技术：对组件的技术选择（ 如： 普通 的[ Java、C#、 Ruby、 其他] 对象、 EJB、 Windows通信基础服务等）；

• 职责：对组件职责的非常高层次的声明（ 如：要么是重要的操作名称，要么是描述职责的简短句子）。

如何画交互：

• 交互的目的（如：“使用”、“存留贸易数据”等）；

• 通信方式（ 如：同步、异步、批量、两阶段提交等）。

组件图的一个示例：

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

联系我: