《软件方法》第9章 分析之分析类图—案例篇Part1（20211114更新）
《软件方法》第8章 分析 之 分析类图——知识篇Part1（20211029更新）>>
鸳鸯扣，宜结不宜解
《身似摇红烛影》，词：唐涤生，曲：王粤生，唱：红线女，1954
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。
图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。
*分值：某个知识点会有一组题目让学员回答，同一组题目中，可根据题目难度为题目设置不同的分值，难度越大，分值越高。
4. 判分结果=学员姓名+得分+评价。
4. 评价从同一得分值的多个评价中随机抽取。
*评价：一些用于活跃气氛的热门用语，和学员回答的得分值对应，一个得分值会准备好多条评价。例如，得0分，评价可能有“不讲武德”、“耗子尾汁”、“你站在此处不要动”等，得1分，评价可能有“打工是不可能打工的”、“个个都是人才”等，得更高分，评价可能有“人类高质量男（女）性”、“yyds”等。
6. 抽奖结果=学员+奖品+抽奖时间
6. 抽奖规则：抽奖时，如果奖池有多于一件奖品，而且价值不完全相同，那么把价值最大的奖品抽中的概率调低为其他奖品的一半。
7. 抽奖结果=奖品名称
7. 剩余奖品=奖品名称+剩余数量。按奖品的价值降序排序。
*价值：每种奖品会设置一个价值，现金的价值为现金的金额，实物奖品的价值为该实物的价格，未抽到奖励视为抽到价值为0的奖品。
7. 成绩排行=学员姓名+总得分+中奖次数，先按总得分降序排序，再按中奖次数降序排序，最后按学员姓名升序排序。
*中奖：抽到的奖品价值大于0，为中奖。
9. 输入输出信息参见最新版微信支付接口规则
10. 回答+是否发放成功+发放时间
11. 是否发放成功
质量需求和设计约束：
1. 针对初次使用本用例的健康人样本，要求平均每秒1次按指令提交回答20次无错误。通过的比例不少于99%。
6. 本步骤的执行时间控制在3-5秒之间。
*太早出奖品会让学员觉得没有在随机抽奖，而是预设好的结果。
（待续）