针对张逸观点的一些评点

我看到张逸老师在最近的一些文章中喜欢提“老”字，例如：

“我充分借鉴了事件风暴这种新方法，却又未完全抛弃UML这种老方法”

“若有可能，我还希望再加上一个ICONIX方法，虽然它已经垂垂老矣，但该方法蕴含的一些设计思想仍有值得借鉴之处”

张逸老师的关注点从编码拓展到软件开发的全部工作流，值得称赞。不过每个工作流有各自的技能需要学习，是自己的感悟还罢了，如果要传授技艺给他人，更需要高标准严要求才对。

所以，我就用建模思维剖析张逸老师近期发表的一些内容，供大家参考。

就先从张逸老师上面这两句话开始吧。

一、不是什么都叫“方法”

上面这两句话，张逸老师对各种概念一律以“方法”称呼之。其实UML是“Unified Modeling Language”，是“语言”，或者“表示法”（Notation）。

ICONIX则是Doug Rosenberg等人提出的一种使用UML的建模过程（Process）。我们先来看2001年的著作：

图1 摘自Rosenberg, D., Scott,K., Applying Use Case Driven Object Modeling with UML: An Annotated e-CommerceExample. Addison Wesley (2001)

再来看2007年的著作：

图2 摘自Rosenberg, D., Stephens,M., Use Case Driven Object Modeling with UML: Theory and Practice. Apress (2007)

关于方法、过程和工具的定义，可以参照被广泛使用的教材“Software Engineering: A Practitioner's Approach”，2014出了第8版。

图3 摘自Pressman R.,Maxim B., Software Engineering: A Practitioner's Approach 8th Edition. SEM(2014)

我于2008年写的《四十年软件工程故事》（http://www.umlchina.com/book/se40.htm）也可以参考。

为什么对这些不当用词如此重视，我在《为什么要对术语"吹毛求疵"》一文（http://www.umlchina.com/qa/Content/906.htm）中阐述了我的观点：

我们听到有人像上面的姨妈表哥一样说话时，我们心里知道，这可不是什么习惯用语不同，而是说话的人是外行。因为我们是内行，我们比姨妈表哥们更知道一些概念之间的区别。

同理，如果我们真的弄懂了软件开发中的一些重要概念，当有人在我们面前说"功能模块"、"用户需求"、"设计阶段"等术语时，我们心里就知道了，这不是什么习惯问题，而是这个人在某些方面是个外行。

二、关于“老”

人们对事物的认识会不断深入，所以，已有的知识有的会被继承，有的会被淘汰。但是要注意，之所以某些知识会被淘汰，是因为人们针对这方面的知识有了更深刻的认识，而不是因为法律规定这个知识只有“**年**权”，到时间就要强行作废。几百年前的数学、物理知识，大部分我们今天不还在继续学习和使用吗？

图4 摘自《中华人民共和国城镇国有土地使用权出让和转让暂行条例》

既然张逸老师说“UML”、“ICONIX”老、垂垂老矣，那我请问张逸老师，能否具体说说看UML、ICONIX到底有哪些缺点，看看能不能说到位？但愿不是为了强调自己的“新”而随口一说。

我不认为UML这个建模语言是完美的，也不认为ICONIX这个过程的做法有多好。我甚至认为经过将近20年的积累，对于建模和UML的下一步改进，我的认识也许比起很多国外的人士更深刻。我还相信我在《软件方法》中提倡的过程比ICONIX（以及其他一些类似过程）要更高效实用。

不过，绝大多数软件开发人员基本上是“赤手空拳”，根本没有达到被UML的不完美和ICONIX的不足绊倒的地步。事实上，就算有人不使用UML里的图，能熟练使用数据流图和实体关系图建模，或者把能把ICONIX那几招用熟，我觉得他就已经高出周围的人一大截了。

NBA的格林可能清楚詹姆斯有啥缺点，但这对业余球员来说有多少参考价值？

癌症的化疗、放疗有局限性和副作用，是需要有更好的治疗手段，但方向应该是更精细的免疫治疗，而不是拿几味中药凑一凑得出来的“癌必灵”。

 三、“痛点”离“问题域”还有多远

图5 摘自张逸文章《领域驱动战略设计暨微服务设计工作坊》

“域”是一个面积或范围较大的概念，“点”是面积或范围很小或近似于零的概念，两者不能等同。

也许张逸老师要表述的意思是：通过痛点来判断哪一块领域需要建模。就像在人体按下痛点来判断哪一块区域需要深入研究。这样的表述更容易理解一些。

即使换了表述，也还是不准确，因为从“痛点”到领域模型，还有一段距离。“头痛”的问题未必在头。

先列举一些建模知识点，更详细内容请参见《软件方法》。

★序列图消息的含义： A指向B，意思是“A请求B做某事”。例如图6中，患者请求门诊收费挂号员办理挂号。如果发消息的是人，接收消息的是非人智能系统，意思符合“A用B来做某事”也可以。 ★业务工人（Business Worker）：组织内的人员，即人脑智能系统。 ★业务实体（Business Entity）：组织内的非人智能系统。 ★业务流程信息化改进 模式一：物流变信息流 模式二：改善信息流转 模式三：封装领域逻辑

通过下面例子来说明问题。某医院现在有个“痛点”：输液反应的投诉比往年多了。

这个“痛点”和需要改进的范围不是一一对应的。

【可能原因一】

有人组团碰瓷。

【改进方案】

1.1 引进一批记忆力好的高级保安（业务工人）盯牢每一个患者，发现可疑人员报警，如图6。

图6 改进方案1.1，引进业务工人

1.2 如果一定要“信息化改进”，可以应用改进模式三“封装领域逻辑”，引进一套人物特征识别系统（业务实体），把“监控人物特征”的逻辑从高级保安的大脑转移到人物特征识别系统，并争取和公安部门的业务实体对接。一旦检测到碰瓷党到来，直接报警并通知挂号员，如图7。

图7 改进方案1.2，业务实体替换业务工人

由图7可以映射出“人物特征识别系统”的用例图，也就是用例级别的需求，如图8。补充上用例的涉众利益、路径、步骤、补充约束，就得到完整的系统用例规约，即以用例为组织形式的需求规约。

图8 人物特征识别系统的用例图

可能有的人会问，这个系统应该还有其他用例吧？例如有个人用这个系统来设置一下规则？可能有，也可能没有（读者可以想一想，为什么可能没有？）。不过再有100个也不影响，因为每次迭代只需要关注最重要的用例，永远都在路上。

如果某个已有的非人智能系统已经提供了这个用例，评估过后觉得确实满足需求的约定，那事情到此为止，不用操心后面的分析设计工作流了。

如果没有现成的可用，还是要做，那就开始分析工作流。

只要构造出来的系统履行了需求的约定，按照哪种分析设计方法学来构造系统都可以。如果用面向对象分析设计方法学来构造系统，我们假设系统由“对象”这样一种东西构成。在分析工作流，系统中的对象在一个虚的"对象空间"中运行。这个空间不是内存，也不是硬盘，只是人脑中的一个逻辑空间。

可能的分析类图如下：

图9 人物特征识别系统的分析类图（不熟悉这个领域的逻辑，仅属猜测）

【可能原因二】

中国逐渐进入老龄社会，老年输液患者的人数越来越多。

【改进方案】

2.1 不改进，主管部门理解就行。

2.2 在内部下密令，医生开医嘱时，留心看一眼HIS系统里的患者资料。针对老年患者开医嘱时，尽量不要有输液内容，如图10。

图10 改进方案2.2-让医生（业务工人）判断是否老年患者

2.3 如果一定要“信息化改进”，可以应用改进模式三“封装领域逻辑”，在现有HIS系统里添加一些逻辑，医生在给老年患者开医嘱时，HIS系统提醒一下，如图11。

图11 改进方案2.3-HIS判断是否老年患者

HIS系统已有的用例“开医嘱”中，会多一些步骤（判断是否老年患者、提醒医生……）和补充约束（判断老年患者规则）。HIS系统内部可以不增加新的类，可以在原有“患者”类上增加一个操作“判断是否老年患者”，在原有“医生界面”类上增加一个操作“提醒医生有老年患者”。

【可能原因三】

医院采购部门人员和厂家勾结，为了获取回扣而购买劣质药品和器械。

【改进方案】

3.1 改进采购流程。例如集中采购权，由采购办主任把关审查。

图12 改进方案3.1-采购办主任把关

3.2 如果一定要“信息化改进”，可以应用改进模式一“物流变为信息流”，改为通过信息系统传递采购申请，取消各部门采购人员的责任；应用改进模式三“封装领域逻辑”，将采购办主任大脑里的审查逻辑封装一部分到HIS系统中，如图13。

图13 改进方案3.2-通过HIS系统传递信息，由HIS系统封装领域逻辑

从图13可以看出，HIS系统多了两个用例：

图14 HIS系统多了两个用例

要实现这两个用例，可能的类图如下：

图15 HIS系统可能需要增加和修改的类

【可能原因四】

护士职业技能或职业素养存在问题，例如对患者宣讲不到位，无菌操作不到位，没有根据患者差异调节输液速度等。

【改进方案】

4.1 加强培训，加强监督，加大奖惩力度。例如，增加暗访人员：

图16 改进方案4.1-增加暗访人员

4.2 如果一定要“信息化改进”，可以把业务工人“暗访员”替换成业务实体“监控系统”，事后安排监督员观看录像并评价。

图17 改进方案4.2-引进监控系统代替暗访人员

在市场上购买通用的监控系统应该可以满足需求。

4.3 更进一步的信息化改进，可以把护士这个业务工人去掉，用业务实体“超级输液机”和“无人运药小车”代替。

图18 改进方案4.3-引进超级输液机和无人运药小车

从图18可以映射出“超级输液机”的用例：

图19 超级输液机的用例

可能的类图如下：

图20 超级输液机的类图

由上可见，针对一个“痛点”，可以有很多改进的可能。不同的可能中，是否需要引进信息系统，引进新的信息系统还是在原有信息系统上改进，又有不同的选择。不管是哪一种选择，推导的思路是清晰的。

未完待续……

接下来的论题：

四、内外不分，对问题域（Problem Domain）的误用

五、需求、分析……是阶段吗

……

来而不往非礼也。我写的《软件方法》以及三年之内的公众号文章（当然也包括本文），也欢迎张逸老师和各位读者批评指正。

★《软件方法（上）》第2版，自行到书店购买，

亚马逊Kindle版：https://www.amazon.cn/dp/B07DFR2313，

勘误：http://www.umlchina.com/book/errata2ed.htm。

★《软件方法（下）》目前公开内容，http://www.umlchina.com/book/softmeth0809.pdf。

★UMLChina公众号二维码

您在阅读《软件方法》时如果发现错误，欢迎通过下面提供的微信、QQ或邮箱告知。如果作者认为有道理，决定在下一次发布时根据您的意见修改，将付给您5.12元报酬，并在书的前言中说明您的贡献。报酬通过微信或支付宝支付。每个错误只支付最先指出者。

书中有很多自测题，建议在把自测题做对后，判断书中确实可能有错，再向作者提出。

微信：umlchinapan，QQ和QQ邮箱：1493943028