架构方法实践 - 客户端CAD工具范例 (二 概念架构部分)

        跨过了概念架构的阶段, 下面进入概念架构的阶段. 一般有经验的架构师不会在这个阶段过早进入将系统划分为"模块+接口"的过程, 而是会根据前架构阶段的结果,识别重大需求, 核心需求, 高风险需求, 来设计概念架构. 概念架构应该能用简练的语言清晰阐述, 并能给客户说明如何实现客户价值, 担心的问题如何解决.个人认为概念架构刚好契合了<<架构之美>> 一书中一再强调的架构的概念完整性. 其定义:

        概念架构满足 "架构=组件+交互" 的基本定义, 仅关注高层设计.

        概念架构对高层的职责进行了笼统的界定, 给出了高级组件的交互关系.

        概念架构不涉及接口的细节. 举个例子: 比如下面这座斜拉大桥, 分为 索塔, 刚性梁, 斜拉索三个组件, 交互是索塔承重, 斜拉索吊起刚性梁, 这就是桥的概念架构.

        

        图5 斜拉桥的概念架构

        对于咱们的客户端CAD工具, 从架构方法实践 - 客户端CAD工具范例 (一 序论, 前架构部分) 的关键需求来看, 可以归纳为将DXF文档内的图层数据, 编辑并拷贝到自定义的一个图层堆叠(Template区域)中, 设置, 计算, 保存,  是一个数据的编辑和转换工具.组件包括DXF文档, Template文档, 两部分, 主要的交互有数据拷贝和数据编辑. 这一下我们也将这个软件的概念讲了出来, 也将软件分层了两个高层模块, 定义了其中的核心交互.

        有了两个高层组件(DXF文档, Template文档), 两个主要交互(数据拷贝, 数据编辑) 我们可以根据其展开细化概念架构,初步设计的目标是, 去发现这些模块和交互间的职责和协作. 这个过程中有一个很好用的工具: 鲁棒图(Robustness diagram), 可以使用magicUML工具绘制. 更多信息:http://www.agilemodeling.com/artifacts/robustnessDiagram.htm

        

        图6 鲁棒图的要素

        鲁棒图的一些规则: 1)Actor代表用户, 只能和Boundary模块交互.

        2) Boundary代表人机交互界面, 即UI,只能和Control模块, Actor交互.

        3) Control代表控制器, 可同时和若干Boundary, Entity模块交互.

        4) Entity代表数据, 只能和Control模块交互. 

        5) Actor->Boundary->Control->Entity->Control->Boundary->Actor 一次交互过程为一个完整用例, 也就是一个职责链,一般来说概念架构各拥有2-5个Entity, Control, Actor比较合适. 在概念架构只对关键用例画鲁棒图.注意Entity不代表持久化对象. 

        如此, 我们对客户端CAD工具使用鲁棒图进行建模:

        

         图7 CAD工具的鲁棒图  

         如此，可以用鲁棒图梳理出工具的四个典型用例（从上往下， 注意单向和双向的箭头）1. 用户import磁盘上的dxf. 2. 用户通过CAD视图能够查看编辑的几何体 3.用户可以使用template wizard编辑template数据，copy动作给了注释.4.用户通过一些算法和处理，将编辑好的几何数据生成eda设计数据。鲁棒图的好处是通过用例健壮性分析，将系统做第一次的高层切分，看上去，图的左右方向可以作为系统的分层（GUI-Controller-Data), 系统的上下方向可用用来分区。稍加改动，分层和分区的概念设计就容易了：

       

       图8 分层/分区图

       有了分层和分区，演化为逻辑架构就容易了。实现者也能知晓大致的工作，比如实现一个图中箭头的子系统，如果仅仅是分层，程序员看过设计会觉得没有可行性，如何知道没层里到底该做什么？有了分区，问题解决。

       在概念架构的阶段，还要考虑重要的非功能需求，比如性能和可扩展性，由于本人没有从事过相关的实践，例子也说明不了这些问题，略去不讲。在这个阶段，我们得到了概念架构的输出：简洁的系统概念归纳和表达。主要模块的交互鲁棒图，分层，分区图等。细化架构的一些东西将在下一篇再聊。