首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >针对张逸观点的一些评点

针对张逸观点的一些评点

作者头像
用户6288414
发布2019-09-23 16:52:45
4070
发布2019-09-23 16:52:45
举报
文章被收录于专栏:软件方法软件方法

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

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

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

……

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-03-07,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 UMLChina 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
区块链
云链聚未来,协同无边界。腾讯云区块链作为中国领先的区块链服务平台和技术提供商,致力于构建技术、数据、价值、产业互联互通的区块链基础设施,引领区块链底层技术及行业应用创新,助力传统产业转型升级,推动实体经济与数字经济深度融合。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档