DDD领域驱动设计批评文集>>
《软件方法》强化自测题集>>
《软件方法》各章合集>>
9.1.6.9 进一步思考
（1）奖品
系统不需要区分具体的奖品，只需要记住奖品的规格。例如，图9-24中的两听可乐，系统不加区分。这里的“奖品”实际上指的是奖品规格，因此需要记住某个“奖品”的数量。
图9-24 关于奖品的数据示例
那么，“数量”是哪个类的属性呢？
“奖品”能决定“数量”吗？不能。“数量”是“奖品”存在于“奖池”中的“数量”，即（奖品，奖池）→数量。
因此，可以添加一个关联到“奖品”和“奖池”的类“奖池项”，把“数量”作为“奖池项”的属性。“奖池项”和“奖品”关联，“奖池项”的多重性为0..1（注意，不是*了，因为有了“数量”属性，“奖品”现在是规格），“奖品”的多重性为1。“奖池项”和“奖池”关联，“奖池项”的多重性为*，“奖池”的多重性为1。
图9-25 奖池项
本系统只需要一个奖池，可以把“奖池”类删掉，但考虑到需要一个类来承担抽奖的责任，继续保留“奖池”类。
图9-26 类图进展
（2）多对多的关联
*学员-活动
学员参加活动的细节不需要考虑，所以此处不需要修改。
*活动-试卷
此处需要修改。学员成绩通过统计某次活动中学员回答问题的得分得到，当前的类图无法推断出某一次回答是在哪一次活动做出的。
例如，一名学员参加了一次“软件需求设计建模方法学全程实例剖析训练”，被老师点名答了一些题，成绩不好，于是，一周后又申请参加了一次“软件需求设计建模方法学全程实例剖析训练”，又答了一些题，这一次成绩大有改善。
这两次“软件需求设计建模方法学全程实例剖析训练”老师使用的试卷是一样的，甚至有可能该学员两次都被点到答同一题，但目前的类图无法区分。
可以有两种做法。第一种如图9-27，在“活动”和“回答”之间建立关联。
图9-27 解决活动-试卷问题 之一
第二种如图9-28，添加一个“考试”类，和“活动”、“试卷”、“回答”关联。
图9-28 解决活动-试卷问题 之二
我们采用第二种做法，虽然多了一个类，但概念更加清晰。“考试”是在某次“活动”中对某一份“试卷”的使用，产生许多“回答”，同时，也消除了“活动”和“试卷”之间的多对多关联。
*回答-选项
关联细节不需要考虑，所以此处不需要修改。
目前类图的进展如图9-29。
图9-29 类图进展
（3）有的类的属性框是空白的
属性框空白不代表没有属性，因为关联也是属性。
可能有人会想，“活动”、“试卷”是不是应该有个“名称”属性，“题目”是不是有个“内容”属性，“考试”要不要加个“时间”属性……
很可能是有的，但是所给用例的用例规约没有提到，说明该用例没有用到。如果确实需要这些属性，在某个用例规约里面会提到的。
至于“ID”、“状态”等属性，是不需要加的，知识点见第8章。
（4）关联的方向
关联如果没有标明方向，默认是双向的。如果能把其中一些改为单向关联，当然是有好处的，但是目前证据并不足，需要结合后面的序列图、状态机图来考虑。
目前的猜测可能是这这样：
图9-30 对于关联方向的猜测
要注意，仅仅是猜测。
（5）某些关联是否可以变为聚合/组合？
目前证据也不足，同样需要结合后面的序列图、状态机图来考虑，实际上后面我们会发现，也许根本就不需要聚合/组合的概念。
（6）如果把系统分为若干个独立的组件（时髦用语为“微服务”），类图上的类该如何分割？
同上，无足够证据，需要继续往下走。
[新增EA028高压注射器]24套UML EA和StarUML的建模示范视频-全程字幕（2022.7.4更新）
7月21-24晚剔除“伪创新”的领域驱动设计-网络公开课
《软件方法》书中自测题-题目全文 分卷自测（1-8章）16套111题
《软件方法》强化自测题集110题
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
