软件方法（下）第9章分析类图案例篇Part05-案例二-智能建模工具

DDD领域驱动设计批评文集>>

《软件方法》强化自测题集>>

《软件方法》各章合集>>

9.2 案例二 发糕智能建模工具

9.2.1 背景知识

现在已经有很多UML建模工具，UMLChina把它们汇总在：

http://www.umlchina.com/tools/search.aspx

那为什么还要自行研发一款建模工具呢？

UML规范提供了各种建模元素并给出了语义，但是，建模时挑选哪些元素来建模，建模是怎样的一个过程，UML规范没有规定。

图9-31 摘自UML 2.5.1规范

《软件方法》所叙述的方法学挑选了一些表示元素来表示模型，如图9-32。

图9-32 《软件方法》所选择的表示元素

建模的过程可能如图9-33。

图9-33 《软件方法》的建模过程

使用当前的建模工具如Enterprise Architect等结合方法学建模时，建模人员需要熟练掌握方法学知识，在建模过程中做很多思考。

在建模愿景的过程中，建模人员需要思考如何定位目标组织和老大，思考过程中，可能需要画类图来帮助定位；在画业务序列图时，建模人员需要思考如何正确描述各个系统恰当的责任，以及可能存在的改进模式；建模人员还要了解模型中存在的对应关系，把业务序列图上从外部指向目标系统业务实体的消息，映射成目标系统的用例……

《软件方法》详细描述了这些知识，但当前的各种建模工具并没有封装它们，而是依赖于建模人员的大脑——一颗掌握了方法学的大脑。

如果能把这部分知识提炼出来，封装到建模工具中，可以大大降低得到高质量模型的门槛。

遗憾的是，从建模工具目前的发展走向来看，并没有在建模方法学方面下功夫，很多精力花在：

（1）支持更多的图

（2）添加更多的项目管理功能

（3）简单映射到更多编程语言和存储平台。

图9-34是Enterprise Architect 15.1的界面截图，从中可以看到Enterprise Architect现在支持的图。图9-34左侧列表框的滚动条高度是列表框高度的1/4左右，说明支持的图是图9-34上可见部分的4倍。

图9-34 Enterprise Architect 15.1支持的图（一小部分）

一些号称“新式”的建模工具，就是把现有工具的一些简单功能搬到web上，可以在浏览器上使用——实际上就是web上的画图工具。

我把建模工具和编码工具类比如下（当然，编码也是建模的一种）：

*画图工具 类似于 记事本

（一些“新一代”建模工具其实就相当于web记事本，连vscode.dev都不算）

*建模工具 类似于 编码环境

*封装方法学模板的建模工具 类似于 集成开发环境

*封装方法学智慧的建模工具 类似于 封装专家级程序员智慧的集成开发环境

我们试图制作一款封装《软件方法》所述方法学智慧的建模工具。

也就是说，我们把《软件方法》的知识作为核心域，制作一款封装《软件方法》知识的工具。可以这样说，在用这个案例学习分析设计技能的过程中，我们不仅可以学习建模，还可以学习到“对建模的建模”。

另外，我们也希望通过对工具的研发来反哺《软件方法》。

通过对方法学的建模，找出方法学理论中存在的缺陷，使方法学的逻辑更加严密，同时，还可以看清楚哪些现有的概念是需要修正或抛弃的，这样我们就更有勇气抛弃历史包袱，去清理各种含糊或冗余的词汇。

事实上，在写作和“对建模的建模”过程中，作者已经感到受益匪浅。《软件方法》中的方法学，在下一版还将会有更大的改进。

9.2.2 领域类图

注意，此处的标题是“领域类图”，和上一个案例对应内容的标题有所不同。

在“答题抽奖”案例，我们针对优先级最高的用例“学员→回答问题”的用例规约，逐个词句提炼类、属性、关系，逐步精化。

如果建模人员的大脑中没有大局上的核心域概念及关系的轮廓，也没有现成的成熟模型可以借鉴，像“答题抽奖”这样逐个用例来探索和拼凑是可以接受的。

如果建模人员对某个领域的概念及关系在大局上有相当清晰的认识，甚至曾经建造了粗略的领域模型，或者有较强的信心能在领域专家的帮助下很快达到这个水平，那么我们可以先抛开某个具体的用例，从大局来建立领域模型，然后再参照用例规约“过滤”出目标系统的分析模型。这一点，在8.2.3.1 从需求规约之外的其他素材提炼以及图8-48中，已经阐述过。

在“发糕”案例中，建模人员（作者）对软件开发方法学的领域知识非常熟悉，所以我们就不再逐个用例探索和拼凑，而是逐个子域展示出软件开发方法学的画卷。

**9.2.2.1 子域1：**组织和系统

（待续……）