软件方法（下）分析和设计第8章分析 之 分析类图——知识篇（20211227更新）
鸳鸯扣，宜结不宜解
《身似摇红烛影》，词：唐涤生，曲：王粤生，唱：红线女，1954
可到此处下载本文档最新版本：
http://www.umlchina.com/book/softmeth09.pdf
您在阅读《软件方法》时如果发现错误，欢迎通过微信umlchina2告知。如果作者认为有道理，决定在下一次发布时根据您的意见修改，每个错误将付给您5.12元报酬，并在书中说明您的贡献。报酬通过微信支付。
（1）任何您认为的错误都可以，包括错别字。
（2）同一错误仅支付最先指正者报酬。
（3）请根据最新版本作指正。
下册内容目前指正人有（按指正时间排序）：吴佰钊、王周文、刘学斌、成文华、黄树成、李蜀斌、杨雪鸿、王书伟、高洪江、张志坚、龙燔。
9.1 本书案例介绍
9.1.1 案例更换
《软件方法（上）》以及下册2018年发布的电子版本，使用的案例是“UMLChina系统2018”。案例中讨论了给特定分区的联系人发公开课通知邮件的领域逻辑，类图如图9-1。
图9-1 本书下册2018版本第8章的案例类图
时过境迁，原先使用邮件、短信甚至QQ的场合绝大部分已经改成使用微信。现在，UMLChina已经很少使用发邮件和发短信的方式来通知学员，除了每年年底会发邮件询问最新邮政地址以便邮寄贺年卡。
而在微信上群发通知，从现在的礼仪来说，容忍度极低。所以，我们也不会针对微信的好友批量地发活动消息，只会在微信群里发。
第二个变化是，2019年底持续至今的2019-nCoV疫情，使得公开课从线下转到了线上，不再有地域限制。
第三个变化是，自媒体平台（公众号、抖音、B站等）成了首要的展示门户，自有网站的重要性大幅下降。
以上提到的是这几年周边业务环境的变化，当然，作为讲解建模的案例，这是小问题，无非是案例的核心域知识有些跟不上时代。
更大的问题是，上册所描述的举办公开课和群发邮件，涉及到的更多是查询的逻辑，如果是讲解类图的建模，是够用了，但状态变化涉及不多，后文讲解状态机图和序列图时不好展开，而通过状态机来封装修改属性值的逻辑是面向对象建模的重点。
考虑到以上变化，本书下册更换了案例。
案例一是写书时正在关注的另一个UMLChina流程：上课时做题并抽奖，涉及到考试和抽奖的领域知识。
案例二是我们正在研发的一款封装《软件方法》知识的智能建模工具——暂时命名为“发糕”。涉及到软件开发方法学的领域知识。
已成文的2018版本第8章的“UMLChina系统2018”案例剖析，继续作为参考案例保留，放在附录中。
9.1.2 案例一：答题抽奖
9.1.2.1 愿景
目标系统：
UMLChina系统2022
目标组织：
UMLChina
老大：
UMLChina负责人 潘加宇
需改进指标：
UMLChina训练中，花费在回答问题和抽奖上的平均时间
指标当前值：
3分钟/题
指标改进值：
2分钟/题
9.1.2.2 业务流程描述
UMLChina的训练中，老师每讲解一个知识点，就会用一个做题软件让学员做一些的题目，考查学员是否掌握。这些题目由老师在课前设置好。为了提高学员做题的兴趣，老师会用一个抽奖软件为答对题目的学员抽奖。
具体过程如下：
（1）老师请求做题软件显示下一道要做的题目，然后等待10-60秒，让学员阅读题目。
*同样难度的题甚至是同一道题，老师目前是凭感觉留给学员阅读题目的时间，留多了会造成浪费，留少了学员会觉得不公平。
图9-2 答题抽奖流程现状-1
（2）老师请求抽奖软件随机抽取一名学员，抽奖软件随机抽取并显示抽中学员名字，老师在教室里寻找该学员所在位置，点名该学员回答问题。
图9-3 答题抽奖流程现状-2
（3）学员思考并口头回答问题，老师确认听清学员的回答后（人多时噪音较多），向做题软件提交学员的回答，做题软件判断并反馈对错。
*有的学员思考时间过长，甚至有学员的答题习惯是先把题目念一遍，导致老师不得不出声催促。
图9-4 答题抽奖流程现状-3
（4）如果学员答对，老师请求抽奖软件为学员抽奖，抽奖软件从当前奖品池中随机抽取奖品，将抽中的奖品从奖品池扣除，反馈抽中的奖品信息，更新剩余奖品数量，更新学员答对排行榜。奖品可能是现金（金额从1.28元到40.96元），也可能是实物（书、饮料、小食等），还有一定比例的奖品是“木有”-没有抽到奖品。
图9-5 答题抽奖流程现状-4
（5）如果奖品是实物，老师将实物发给学员；如果奖品是现金，老师通过手机上的微信发红包给学员。
图9-6 答题抽奖流程现状-5
9.1.2.3 业务序列图
针对以上流程，绘制现状的业务序列图如图9-7。
图9-7 答题抽奖流程现状业务序列图
从图9-7可以看到，做题软件、抽奖软件和微信之间不直接通信。老师担任了信息搬运工的角色，用自己的手指按动电脑上的鼠标，把学员的回答搬运到做题软件里，用自己的手指按动手机上的软键盘，把做题软件抽出来的奖品金额搬运到微信里……。这种情况符合《软件方法》第4章提到的“改进模式二：改善信息流转”。
“寻找学员所在位置”、“判断超时”等逻辑封装在人脑中。这种情况符合《软件方法》第4章提到的“改进模式三：封装领域逻辑”。
改进的业务序列图如图9-8。注意，引进的系统依然是“UMLChina系统”，并非“UMLChina答题抽奖系统”。
图9-8 答题抽奖流程改进业务序列图
9.1.2.3 系统用例图
从图9-8映射“UMLChina系统2022”的用例图如图9-9。
图9-9 “UMLChina系统2022”的用例图
9.1.2.3 系统用例规约
“学员→回答问题”的用例规约如下：
用例名：
回答问题
执行者:
学员（主）、微信（辅）
涉众利益：
老师-担心评价更新不及时，让学员觉得陈旧。
学员-担心自己碰到有陷阱的题目，导致周围同事特别是领导认为自己答不对简单的题目，能力不行。
学员-担心题目字太小看不清楚，担心手滑选错答案。
老师-担心抽奖结果被认为是预设的，导致学员失去兴趣。
老师-担心大奖出现得太快，导致后面的学员没有动力。
学员-担心抽奖不公平，轮到自己抽奖时运气太差，轮到别人抽奖时运气太好。
奖品生产厂商负责人-担心自己的产品被用作不好的用途。
微信系统管理员-担心自己维护的系统受影响发生故障。
基本路径：
1. 学员提交回答。
2. 系统验证回答有效。
3. 系统判分，保存判分结果。
4. 系统反馈判分结果。
5. 系统验证得分大于0。
6. 系统随机抽取奖品，将抽中奖品从奖品池移除，保存抽奖结果。
7. 系统反馈抽奖结果、剩余奖品和学员成绩排行。
8. 系统验证抽中奖品为现金类型且存在学员的微信号。
9. 系统请求微信向学员的微信号发红包。
10. 系统保存发奖金结果。
11. 系统反馈发奖金结果。
扩展：
2a. 回答无效：
2a1. 系统反馈回答无效。
2a2. 用例结束。
字段列表和业务规则：
1. 回答为选项。系统暂时不考虑选择题之外的题型。
2. 有效规则：单选题的回答只能是1个选项，多选题的回答至少有2个选项。
3. 判分结果=学员+回答选项+得分+判分时间。
3. 得分规则：所回答选项集和题目预设答案选项集完全相同，则得到题目全部分值，否则题目得分为0。
*分值：某个知识点会有一组题目让学员回答，同一组题目中，可根据题目难度为题目设置不同的分值，难度越大，分值越高。难度是相对的，同一道题目，放在A组可能属于难题，放在B组可能就相对容易。
4. 判分结果=学员姓名+得分+评价。
4. 评价从同一得分值的多个评价中随机抽取。
*评价：一些用于活跃气氛的热门用语，和学员回答的得分值对应，一个得分值会准备好多条评价。例如，得0分，评价可能有“不讲武德”、“耗子尾汁”、“你站在此处不要动”等，得1分，评价可能有“打工是不可能打工的”、“个个都是人才”等，得更高分，评价可能有“人类高质量男（女）性”、“yyds”等。
6. 抽奖结果=学员+奖品+抽奖时间。
6. 抽奖规则：抽奖时，如果奖池有多于一件奖品，而且价值不完全相同，那么把价值最大的奖品抽中的概率调低为其他奖品的一半。
7. 抽奖结果=奖品名称。
7. 剩余奖品=奖品名称+剩余数量。按奖品的价值降序排序。
*价值：每种奖品会设置一个价值，现金的价值为现金的金额，实物奖品的价值为该实物的价格，未抽到奖励视为抽到价值为0的奖品。
7. 成绩排行=学员姓名+总得分+中奖次数，先按总得分降序排序，再按中奖次数降序排序，最后按学员姓名升序排序。
*中奖：抽到的奖品价值大于0，为中奖。
9. 输入输出信息参见最新版微信支付接口规则。
10. 回答+是否发放成功+发放时间。
11. 是否发放成功。
质量需求和设计约束：
1. 针对初次使用本用例的健康人样本，要求平均每秒1次按指令提交回答20次无错误。通过的比例不少于99%。
6. 本步骤的执行时间控制在3-5秒之间。
*即使计算时间很短，也不宜太早出奖品，因为会让学员觉得没有在随机抽奖，而是预设好的结果。
9.1.3 发糕智能建模工具
9.1.3.1 为什么要自行研发一款建模工具？
UML规范提供了各种建模元素并给出了语义，但是，建模时挑选哪些元素来建模，建模是怎样的过程，UML规范没有规定。
图9-10 摘自UML 2.5.1规范
《软件方法》所叙述的方法学挑选了一些表示元素来表示模型，如图9-11。
图9-11 《软件方法》所选择的表示元素
建模的过程可能如图9-12。
图9-12 《软件方法》的建模过程
使用当前的一些工具如Enterprise Architect等结合方法学建模时，建模人员需要熟练掌握方法学知识，在建模过程中做很多思考，挑选合适的表示元素来建模。
例如，在建模愿景的过程中，建模人员需要思考如何定位目标组织和老大，思考过程中，可能需要画类图来帮助定位；在画业务序列图时，建模人员需要思考如何正确描述各个系统恰当的责任，以及可能存在的改进模式……
建模人员还要了解模型中存在的对应关系。
例如，业务序列图上从外部指向某个业务实体的消息，会对应某个系统的用例；某个类的状态机图上的迁移事件，会对应某张序列图上指向该类的某个对象的操作……
《软件方法》详细描述了这些知识，但当前的各种建模工具并没有封装，而是依赖于建模人员的大脑，而且这颗大脑还得掌握《软件方法》。
如果能把这部分知识提炼出来，封装到建模工具中，可以大大降低得到高质量模型的门槛。
遗憾的是，从建模工具目前的发展走向来看，并没有在建模方法学方面下功夫，很多精力花在：
（1）支持更多的图（2）添加更多的项目管理功能（3）简单映射到更多编程语言和存储平台。
图9-13是Enterprise Architect 15.1的界面截图，从中可以看到Enterprise Architect现在支持的图。图9-13左侧列表框的滚动条高度是列表框高度的1/4左右，说明支持的图是图9-13上可见部分的4倍。
图9-13 Enterprise Architect 15.1支持的图（一小部分）
一些号称“新式”的建模工具，就是把现有工具的一些简单功能搬到web上，可以在浏览器上使用——实际上就是web上的画图工具。
我把建模工具和编码工具类比如下（当然，编码也是建模的一种）：
*画图工具 类似于 记事本
（一些“新一代”建模工具其实就相当于web记事本，连vscode.dev都不是）
*建模工具 类似于 编码环境
*封装方法学模板的建模工具 类似于 集成开发环境
*封装方法学智慧的建模工具 类似于 封装专家级程序员智慧的集成开发环境
我们试图制作一款封装《软件方法》所述方法学智慧的建模工具。
我们希望在工具中封装当前建模工具没有封装的《软件方法》知识。也就是说，我们把《软件方法》的知识作为核心域，制作一款封装《软件方法》知识的工具。可以这样说，在用这个案例学习分析设计技能的过程中，我们不仅可以学习建模，还可以学习到对建模的建模。
另外，我们也希望通过对工具的研发来反哺《软件方法》——通过严密的建模思考，清理方法学理论体系上可能存在的缺陷，使其逻辑更加严密。
《软件方法》参考了多方面的知识来源。愿景中的定位知识来源于Al Ries和Jack Trout，用例图和序列图的知识来源于Ivar Jacobson，阿布思考法来源于Barry Nalebuff和Ian Ayres，用例规约来源于Alistair Cockburn，分析类图来源于Peter Coad……“利润=需求-设计”，来源于高焕堂。文献可以参见《软件方法》的“推荐阅读”部分。
当然，经过二十年“聚焦最后一公里”实践，原有的知识都已经被拓展。大家感兴趣可以对照一下原有知识和《软件方法》中的知识。
9.1.3.2 愿景
目标系统：
发糕智能建模工具
目标组织：
信任并决定采用《软件方法》的需求和设计人员群体
老大：
王工，某供应链企业架构师，目前用Enterprise Architect建模供应链项目
需改进指标：
使用《软件方法》所授方法学建模时，得到同等质量建模工件所需人时
改进幅度：
下降50%
9.1.3.3 业务序列图
图9-14 建模人员在Enterprise Architect帮助下建模愿景的业务序列图
图9-14忽略了和涉众交流的过程，只描述思考和建模的过程。
从图9-14可以看到，许多思考是在人脑中进行的，可以提炼出来放在建模工具中。改进的序列图如图9-15。
图9-15 改进后的业务序列图
9.1.3.4 系统用例图
映射为系统用例图如图9-16。用例实际上就是一个，右侧三个用例是编写愿景过程中的可选分支，可独立为扩展用例。
图9-16 发糕建模工具的用例图
9.1.3.5 系统用例规约（部分）
“建模人员→编写愿景”的用例规约如下：
用例名：
编写愿景
执行者:
建模人员
涉众利益：
……
基本路径：
1. 需求人员请求编写愿景。
2. 系统反馈需要提供的信息项。
3. 需求人员可以
通过比较标签值协助定位目标组织
画因果图
查看组织类型KPI
4. 需求人员提交愿景信息。
5. 系统验证愿景信息充分。
6. 系统保存愿景信息。
7. 系统反馈愿景信息已保存。
扩展：
3a. 通过比较标签值协助定位：
3a1. 需求人员输入关键词，请求协助定位目标组织。
3a2. 系统反馈相关组织类型。
3a3. 需求人员指定组织类型。
3a4. 系统反馈组织类型标签信息。
3a5. 需求人员指定标签选项和排序。
3a6. 系统生成待提交的目标组织名称。
……
字段列表和业务规则：
2. 待提交的目标系统名称缺省为项目名称。
4. 愿景信息=目标系统名称+目标组织名称+老大角色+老大姓名+需改进指标+指标当前值+指标改进值+改进幅度。
6. 保存信息=4+保存时间。
5. 愿景信息充分规则：老大姓名、指标当前值、指标改进值、指标改进幅度允许为空。
3a2. 反馈信息={组织类型名称}*。
3a4. 反馈信息={标签名称+{可选项}*}*。
3a6. 生成规则：目标组织名称={标签选项值+“的”}*+组织类型名称，排序越靠前的标签离组织类型名称越近。
……
9.1.3.6 “发糕”名字的来源——兼谈IT起名
这小节内容本不应该属于下册，应该放在上册第2章“愿景”更合适，但由于第2章当时没有写到这方面内容，所以暂时放在这里。
起名可以分为三种类型：
（1）直接起名
直接用品类的名字起名，例如IBM、Microsoft、Enterprise Architect……包括UMLChina。
IBM是InternationalBusiness Machines（国际商业机器）的缩写，公司创建于1911年。IBM最开始做打字机，后来做计算机，都属于“商业机器”；Microsoft诞生于1975年，当时软件还属于顾客购买计算机时赠送的附属品，还没有“软件业”的概念。
在品类形成的初期，直接起名可以帮助抢占先机，但是不利于将来的延伸。
IBM研发和收购了许许多多的软件，所谓五大软件品牌，都没有得到期望的结果。幸亏IBM是缩写，如果使用全名，对IBM软件的形象就更不利了。
Microsoft的“soft”也让人感觉擅长软件，不擅长硬件，其实微软的笔记本电脑水准很高。
直接起名还有一个问题：容易模仿和混淆。
你来一个UMLChina，他来一个ChinaUML、UMLCn、CnUML，然后你就被淹没在茫茫人海之中。
建模工具Enterprise Architect属于直接起名，两个通用词汇连在一起，如果使用Enterprise Architect碰到问题，用搜索引擎搜索“Enterprise Architect”，得到如图9-17的结果。
图9-17 bing.com搜索enterprise architect的结果
可以看到，第一个结果类似广告，第二个结果确实是建模工具EA，第三个结果说的已经是企业架构。和EA相关的内容混杂在大量企业架构、企业架构师的内容之中。
（2）隐喻起名
名称中不直接包含品类名，而是用一个能联想到品类的名字，例如Google、百度、知乎、闲鱼、滴滴、饿了么、陌陌……。
Google是一个搜索引擎，名字来源于googol，即10的100次方，暗示后面有海量的信息供搜索。域名用google.com而不用search.com之类，原因当然不是买不起域名。如果起名search.com，可能就会有人山寨esearch.com、isearch.com，而Google这个词和起名者的创意相关，如果有人山寨了一个iGoogle，其他人也会联想到iGoogle里的Google怎么来的，山寨起来不划算，不如另起个名字，比如百度。
隐喻式起名虽然和品类的绑定没那么直接，可以延伸到其他品类，但也不是没有影响。百度搞地图、文库还好，搞外卖、商城之类搜索不是关键要素的领域就够呛了，除非不用百度的名字。
（3）无厘头起名
名字来自起名者灵光一闪，和品类没有内在联系，例如Dell、Apple、小米、京东、盒马、喜马拉雅、荔枝……，包括本书的案例“发糕”。
Dell是因为创始人姓Dell，Apple是因为乔布斯当时经常吃苹果，小米是因为大家早餐喝小米粥，京东是因为爱情。
从十多年前开始，我的胃就不好，后来我太太和我说，主食吃发酵食品，比如馒头、发糕等等。于是我即使出差时也注意把主食改为馒头、发糕，尤其喜欢点“西贝”的发糕（此处不是恰饭，虽然我很想恰。欢迎各餐饮企业来洽谈恰饭事宜，反正我吃过的发糕也不只西贝一家）。
现在，我的胃肠已经很好了。当然，还有其他的原因了，例如不喝酒、三餐之外不进食。
（*仅供参考，有一定年纪的同学，隔1-2年可以做一回胃肠镜套餐。不疼，10秒麻翻，醒过来就做好了。）
虽然无厘头用的词可能也是通用词，但是词义和品类没有内在联系。苹果不是卖水果的，小米不是卖杂粮的。这和Enterprise Architect不同，Enterprise Architect确实就是奔着“企业架构师”去的，如果Enterprise Architect是女性内衣品牌，那又是另外一回事了。
因为词义和品类没有内在联系，在初期的营销中，必须卖力宣传，而且要和品类一起连起来宣传。例如，Apple最开始叫Apple Computer。有一段时间霸占电梯广告的“瓜子二手车直卖网”，也是连在一起说。光说瓜子，大家以为是卖炒货的。
等到大家对品牌有认识了，再把品类名称去掉。“Apple Computer”把“Computer”去掉，喜马拉雅FM、荔枝FM现在把FM去掉了，“盒马鲜生”也去除“鲜生”，只保留“盒马”。
因为名字不绑定品类，通过宣传给名字赋予某种“气质”之后，就可以延伸到其他品类。Microsoft搞房地产比较别扭，Apple搞房地产，就是创新、精致、有点贵的房地产；小米搞房地产，就是性价比高的房地产，“年轻人的第一套房”。
图9-18 小米的广告
我对选择起名方式的看法：
如果在品类形成初期，对该品类看好，下决心锚定这个品类，而且有信心成为各品牌的领先者，就用直接起名好了，显得霸气；如果想要灵活变化，就无厘头起名。
UMLChina和《软件方法》都是直接起名。
UMLChina这个名字，好处是形象鲜明，在UML普及初期很有帮助。一看“UML+China”，就觉得是UML在中国的代表，在中国如果需要UML服务，就是它了。其实，除了我自己和OMG里个别人有过Email联系，UMLChina和OMG并没有官方合作关系，也没有绑定到哪家工具厂商。
好处的另一面就是坏处。
一个坏处是会让人认为“只会UML”。有时，来联系业务的是IT组织的人力资源专员或培训公司的行政老师，她们（女性居多）没有软件开发的经历，会问“潘老师，您这边除了UML的培训之外，还有没有针对产品经理或架构师的培训”。我不得不向对方解释方法、过程和工具等概念，以及UML和这些有什么关系。还有，要是OMG把UML改了名字，UMLChina这个名字就杯具了。
另一个坏处是走不出中国。毕竟在很多领域，China和“领先”还不能联系在一起。当然，目前还没有面对这方面的烦恼。
UMLChina如果不用直接起名，用隐喻起名，您觉得叫什么合适？欢迎在评论留言。
UMLChina如果不用直接起名，用无厘头起名，您觉得叫什么合适？欢迎在评论留言。
严格来说，UML不是品类，是品牌。品类是建模语言，UML是OMG这个“厂家”的一个品牌，只不过UML相对于其他建模语言品牌显得太突出，已经接近于品类。类似的例子还有可乐。可乐本来是品牌，后来大家大脑里逐渐建立起这样的概念：那种黑褐色的糖水叫可乐（Cola），于是可乐就成了品类。可口可乐，百事可乐、非常可乐、天府可乐……是可乐的品牌。
同理，《软件方法》也是直接起名，不另外起品牌名字，例如“潘氏方法”、“鲸鱼方法”、“灵便方法”，即使搜索时淹没在海量信息中也无所谓。这也是表达一种信心。
直接起名的书还有“The Art of Computer Programming”。
图9-17 “The Art of Computer Programming”封面
至于“发糕”嘛，因为《软件方法》的知识是公开的，人人都可以基于方法学开发相应的工具，也许其他人做的工具更好呢？所以就不敢直接起名了，先起一个无厘头的名。
特别声明：以上思考和我对建模的思考不一样，仅属于业余爱好，所以思考的价值不敢确定，仅供参考。竞争成败因素很多，起名因素占的比例难说有多少。
