软件方法（下）第9章分析类图案例篇Part01
鸳鸯扣，宜结不宜解
《身似摇红烛影》，词：唐涤生，曲：王粤生，唱：红线女，1954
可到此处下载本文档最新版本：
http://www.umlchina.com/book/softmeth2.pdf
您在阅读《软件方法》时如果发现错误，欢迎通过微信umlchina2告知。如果作者认为有道理，决定在下一次发布时根据您的意见修改，每个错误将付给您5.12元报酬，并在书中说明您的贡献。报酬通过微信支付。
（1）任何您认为的错误都可以，包括错别字。
（2）同一错误仅支付最先指正者报酬。
（3）请根据最新版本作指正。
下册内容目前指正人有（按指正时间排序）：吴佰钊、王周文、刘学斌、成文华、黄树成、李蜀斌、杨雪鸿、王书伟、高洪江、张志坚、龙燔、陈文飞、郭沼兵、陈自平、张彬、李宏伟。
《软件方法（上）》以及下册2018年发布的电子版本，使用的案例是“UMLChina系统2018”。案例中讨论了给特定分区的联系人发公开课通知邮件的领域逻辑，类图如图9-1。
图9-1 本书下册2018版本第8章的案例类图
时过境迁，原先使用邮件、短信甚至QQ的场合绝大部分已经改成使用微信。现在，UMLChina已经很少使用发邮件和发短信的方式来通知学员，除了每年年底会发邮件询问最新邮政地址以便邮寄贺年卡。
而在微信上群发通知，从现在的礼仪来说，容忍度极低。所以，我们也不会针对微信的好友批量地发活动消息，只会在微信群里发。
第二个变化是，2019年底持续至今的2019-nCoV疫情，使得公开课从线下转到了线上，不再有地域限制。
第三个变化是，自媒体平台（公众号、抖音、B站等）成了首要的展示门户，自有网站的重要性大幅下降。
以上提到的是这几年周边业务环境的变化，当然，作为讲解建模的案例，这是小问题，无非是案例的核心域知识有些跟不上时代。
更大的问题是，上册所描述的举办公开课和群发邮件，涉及到的更多是查询的逻辑，如果是讲解类图的建模，是够用了，但状态变化涉及不多，后文讲解状态机图和序列图时不好展开，而通过状态机来封装修改属性值的逻辑是面向对象建模的重点。
考虑到以上变化，本书下册更换了案例。
案例一是写书时正在关注的另一个UMLChina流程：上课时做题并抽奖，涉及到考试和抽奖的领域知识。
案例二是我们正在研发的一款封装《软件方法》知识的智能建模工具——暂时命名为“发糕”，涉及到软件开发方法学的领域知识。
已成文的2018版本第8章的“UMLChina系统2018”案例剖析，继续作为参考案例保留，放在附录中。
9.1 案例一：答题抽奖
9.1.1 背景知识
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 愿景
目标系统：
UMLChina系统2022
目标组织：
UMLChina
老大：
UMLChina负责人 潘加宇
需改进指标：
UMLChina训练中，花费在回答问题和抽奖上的平均时间
指标当前值：
3分钟/题
指标改进值：
2分钟/题
9.1.3 业务序列图
针对以上流程，绘制现状的业务序列图如图9-7。
图9-7 答题抽奖流程现状业务序列图
从图9-7可以看到，做题软件、抽奖软件和微信之间不直接通信。老师担任了信息搬运工的角色，用自己的手指按动电脑上的鼠标，把学员的回答搬运到做题软件里，用自己的手指按动手机上的软键盘，把做题软件抽出来的奖品金额搬运到微信里……。这种情况符合《软件方法》第4章提到的“改进模式二：改善信息流转”。
“寻找学员所在位置”、“判断超时”等逻辑封装在人脑中。这种情况符合《软件方法》第4章提到的“改进模式三：封装领域逻辑”。
改进的业务序列图如图9-8。
图9-8 答题抽奖流程改进业务序列图
注意，引进的系统依然叫“UMLChina系统”，并非“UMLChina答题抽奖系统”。“答题抽奖”可以看作由若干用例组成的用例集。
实际上，现实中的“UMLChina系统”现在已经有了不少类，例如“学员”、“课程”，但为了讲解更清晰，书中假设不存在现有的类，从头构思“答题抽奖”案例用例集所需的类。
但要提醒的是，这样做的原因只是为了本书讲解方便，这是一个盘外因素，和系统内部组件的耦合内聚并不相关。
近几年，“微服务”之风盛行，但该不该切分为微服务，如果一定要切分应如何切分，是一个非常复杂的问题。有些人未必乐意面对以及学习如何应对这些复杂问题，于是就冒出来一些投资少、见效快、产量足的“微服务伪创新”，它们避开了复杂的软件结构问题，专从盘外招下功夫。
就像第1章所言，判断地震来了哪座楼倒塌的可能性最小，需要考虑大楼的结构、所用的材料、所在位置的地质环境等，但这涉及到艰深的工程力学、材料学和地质学知识。于是有人发明了简单易行的办法，从工作服的颜色、工人是否结对洗澡、施工队开会时是否站立等方面来找原因。
之所以做以上提醒，是怕读者误会，以为作者推荐从愿景、业务序列图推导出的用例集作为划分“微服务”的依据。
如何“切分微服务”，更好的做法，参见本书第8章之后各章的知识讲解。
9.1.4 系统用例图
从图9-8映射“UMLChina系统2022”的用例图如图9-9。
图9-9 “UMLChina系统2022”的用例图
9.1.5 系统用例规约
“学员→回答问题”的用例规约如下：
用例名：
回答问题
执行者:
学员（主）、微信（辅）
涉众利益：
老师-担心评价更新不及时，让学员觉得陈旧。
学员-担心自己碰到有陷阱的题目，导致周围同事特别是领导认为自己答不对简单的题目，能力不行。
学员-担心题目字太小看不清楚，担心手滑选错答案。
老师-担心抽奖结果被认为是预设的，导致学员失去兴趣。
老师-担心大奖出现得太快，导致后面的学员没有动力。
学员-担心抽奖不公平，轮到自己抽奖时运气太差，轮到别人抽奖时运气太好。
奖品生产厂商负责人-担心自己的产品被用作不好的用途。
微信系统管理员-担心自己维护的系统受影响发生故障。
基本路径：
1. 学员提交回答。
2. 系统验证回答有效。
3. 系统判分，保存判分结果。
4. 系统反馈判分结果。
5. 系统验证得分达到抽奖要求。
6. 系统随机抽取奖品，将抽中的奖品从奖池移除，保存抽奖结果。
7. 系统反馈抽奖结果、剩余奖品和学员成绩排行。
8. 系统验证抽中的奖品为现金类型且存在学员的微信号。
9. 系统请求微信向学员的微信号发红包。
10. 系统保存发奖结果。
11. 系统反馈发奖结果。
扩展：
2a. 回答无效：
2a1. 系统反馈回答无效。
2a2. 用例结束。
字段列表和业务规则：
1. 回答选择了题目的某个或若干个选项。
*系统暂时不考虑选择题之外的题型。
2. 有效规则：回答选择的选项必须属于同一道题目；单选题的回答只能是1个选项，多选题的回答至少有2个选项。
3. 判分结果=学员+回答选项集+得分。
3. 判分规则：所回答选项集和题目预设正确选项集完全相同，则得到该题全部分值，否则该题得分为0。
*分值：某个知识点会有一组题目让学员回答，同一组题目中，可根据题目难度为题目设置不同的分值，难度越大，分值越高。难度是相对的，同一道题目，放在A组可能属于难题，放在B组可能就相对容易。
4. 判分结果=学员姓名+得分+评价。
4. 评价从得分值所在的分值区间适用的评价集合中随机抽取。
*评价：一些用于活跃气氛的热门用语，和学员回答的得分值对应，一个得分值会准备好多条评价。例如，得0分，评价可能有“不讲武德”、“耗子尾汁”、“你站在此处不要动”等，得1分，评价可能有“打工是不可能打工的”、“个个都是人才”等，得更高分，评价可能有“人类高质量男（女）性”、“yyds”等。
5. 抽奖要求：得分值大于0。
6. 抽奖结果=学员+奖品+抽奖时间。
6. 抽奖规则：抽奖时，如果奖池有多于一件奖品，而且价值不完全相同，那么把价值最大的奖品抽中的概率调低为其他奖品的一半。
7. 抽奖结果=奖品名称。
7. 剩余奖品=奖品名称+剩余数量。按奖品的价值降序排序。
*价值：每种奖品会设置一个价值，现金的价值为现金的金额，实物的价值为该实物的估值，未抽到奖励视为抽到价值为0的奖品。
7. 成绩排行=学员姓名+成绩+中奖次数，先按成绩降序排序，再按中奖次数降序排序，最后按学员姓名升序排序。
*中奖：抽到的奖品价值大于0，为中奖。
7. 学员成绩为当前活动中，学员所提交回答的得分总和。
*某一次公开课或内训称为一次活动，一次活动可能会持续几天，学员会一直参加。在活动过程中，老师会出很多组试题（或者说出很多张试卷）。
*学员可以参加很多次UMLChina的活动。例如，两个月前参加了一次“软件需求设计方法学全程实例剖析”培训，这个月又参加“业务建模和需求高阶”培训。此处的学员成绩指在单个活动内的成绩，不跨活动累加。
9. 输入输出信息参见最新版微信支付接口规则。
9. 红包金额为现金奖品的价值。
10. 回答+是否发放成功+发放时间。
11. 是否发放成功。
质量需求和设计约束：
1. 针对初次使用本用例的健康人样本，要求平均每秒1次按指令提交回答20次无错误。通过的比例不少于99%。
6. 本步骤的执行时间控制在3-5秒之间。
*即使计算时间很短，也不宜太早出奖品，因为会让学员觉得没有在随机抽奖，而是预设好的结果。
[推荐升级]23套UML+EA和StarUML的建模示范视频-全程字幕（2022.6.1更新）
《软件方法》书中自测题-题目全文+分卷自测（1-8章）16套111题
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
腾讯云开发者
