软件方法（下）第9章分析类图案例篇Part01

DDD领域驱动设计批评文集>>

《软件方法》强化自测题集>>

《软件方法》各章合集>>

鸳鸯扣，宜结不宜解

《身似摇红烛影》，词：唐涤生，曲：王粤生，唱：红线女，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秒之间。

*即使计算时间很短，也不宜太早出奖品，因为会让学员觉得没有在随机抽奖，而是预设好的结果。

《软件方法》强化自测题集110题

---