专栏首页软件方法针对张逸观点的一些评点

针对张逸观点的一些评点

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

“我充分借鉴了事件风暴这种新方法,却又未完全抛弃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)的误用

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

……

本文分享自微信公众号 - UMLChina(umlchinagroup1),作者:UMLChina 潘加宇

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-03-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 评点张逸观点(2)对问题域(Problem Domain)的误用

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

    用户6288414
  • UMLChina建模竞赛题大全-题目全文+分卷自测(10套100题)

    以下是UMLChina出过的建模竞赛题,答案不直接给出,可访问每套题后面的自测链接或扫二维码自测,做到全对才能知道答案。

    用户6288414
  • UMLChina建模竞赛题大全-题目全文+分卷自测(1-4)

    以下是UMLChina出过的建模竞赛题,答案不直接给出,可访问每套题后面的自测链接或扫二维码自测,做到全对才能知道答案。

    用户6288414
  • 手把手教你破解Pycharm2018.2(JetBrains全家桶)

    最近有小伙伴反映自己的Pycharm快过期了,问我有没有时间出一个破解的教程。正好今天有空,我就准备写一篇。注意本篇笔记只限于个人交流使用,不用做商业活动。如由...

    编程思录
  • 优先改进哪个点?

    实践敏捷、精益或DevOps的团队,都在进行“持续改进”。但在持续改进中,会面临两个痛点:

    吾真本
  • 解决微信公众号文章的防盗链

    写一个服务,把微信图片下载到本地,然后放在静态文件目录中,修改微信图片中的域名为自己的IP或域名,备注:程序请求时,referer需要时空的

    JouyPub
  • 快速排序填坑口诀

    快速排序由于排序效率在同为O(N*logN)的几种排序方法中效率较高,因此经常被采用,再加上快速排序思想----分治法也确实实用,因此在很多笔试面试中出现的几率...

    KevinYan
  • 算法之常见排序算法-冒泡排序、归并排序、快速排序

    对于编程中琳琅满目的算法,本人向来是不善此道也不精于此的,而说起排序算法,也只是会冒泡排序。还记得当初刚做开发工作面试第一家公司时,面试官便让手写冒泡排序(入职...

    本人秃顶程序员
  • 业界|TensorFlow1.0正式发布,AI圈“互怼”那些事儿 | AI科技评论周刊

    编者按:本周TensorFlow 1.0 正式发布;南大教授周志华当选AAAI 2019 程序主席,华人学者第一人; 雷锋网与MXNet作者李沐畅谈两小时;Li...

    AI科技评论
  • Amazon Workspace正式上市 云计算领域现巨头之争

    作为电子零售兼云服务巨头打造的虚拟桌面基础设施服务,号称以“Windows 7桌面使用体验”为基础的Amazon Workspace已经正式迎来上市消息。 ...

    静一

扫码关注云+社区

领取腾讯云代金券