DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

---

1.4 应用UML的建模工作流

1.4.1 概念

我用类图表示建模工作流相关概念如图1-16。

图1-16 建模工作流相关概念

图1-16左侧灰色部分定义了“游戏规则”，右侧则是在“游戏规则”上“玩游戏”的结果。

显然，只是看这个类图不能很好理解相关概念。我用对象图展示本书推荐的“游戏规则”如图1-17。

图1-17 建模工作流相关概念的对象图（图形较大，点开看或访问原图http://www.umlchina.com/book/1pics/fig1_017.png）

图1-17中，除了最左侧的“工作流类型”之外，都是可以变化的。

可以替换“表示元素”。例如，系统用例规约改为用活动图表达，则图1-17的相应部分可以改为图1-18。

图1-18 系统用例规约改为用活动图表达

可以替换“表示法”。例如，把UML换成其他表示法或自创的表示法，那么图1-17左起3到5列都要修改。

可以替换“方法学”，例如，受“少林功夫+唱歌跳舞”启发，创造出“浑元形意太极+革命性创造划时代洞见领域驱动设计敏捷精益方法学”，但仍然使用UML表示法，那么图1-17左起2、3列需要修改。

1.4.2 工具箱

从图1-17可以看出，本书重点使用的UML图形只有4种：用例图、类图、序列图和状态机图。

UML 2.5包含的图形一共有14种，如图1-19所示的树上的叶结点。

图1-19 UML图形（根据UML2.5规范绘制）

经常会有人有意无意地误导，让人以为使用UML建模需要画这么多图，顺势攻击“UML笨重”。其实，应该把UML看作一个工具箱。工具箱里面有各种工具，建模人员只需要根据当前所开发系统的特点，从这个工具箱中选择合适的工具就可以，并不需要“完整地”使用UML。

这和编程语言类似。很多人说“我用Java”，其实只是用Java的一小部分，而且很长时间内也只会用这一小部分。

经常有学员问：潘老师，能不能给一个案例，完完整整地实施了整套UML？这是一种误解，这样的案例不应该有。这相当于问：有没有一本经典的小说，把字典里所有的单词都用上了？有一些建模工具自带的案例模型会造成误解，一个模型里把所有的UML图都给用上了，但这是工具厂商出于展示其工具建模能力的目的而提供的，不可当真。