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

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）如果把系统分为若干个独立的组件（时髦用语为“微服务”），类图上的类该如何分割？

同上，无足够证据，需要继续往下走。

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

---