[答疑]三个类(CheckRecord、Project、CheckIssue)之间的关系表示方法是否正确

最新推荐文章于 2024-03-26 21:48:43 发布

原创最新推荐文章于 2024-03-26 21:48:43 发布 · 236 阅读

0 ·

CC 4.0 BY-SA版权

分析专栏收录该内容

265 篇文章

订阅专栏

本文探讨了软件方法中CheckRecord、Project和CheckIssue类之间的关系，重点在于分析类图如何准确表示多对多关系，并讨论了冗余信息的去除和最佳实践。

软件方法（下）分析和设计第8章连载[20210816更新]分析之分析类图——知识篇

一马行千里(759***22) 13:58:35
以下三个类(CheckRecord、Project、CheckIssue)之间的关系表示方法是否正确？两个箭头指向是否正确？或者是否需要箭头指向？
一马行千里(759***22) 13:58:45

一马行千里(759***22) 13:59:02
要表达的意思是：
1. 创建一条抽查记录(CheckRecord)时选择多个工程(Project)，代表对选中的这些工程进行抽查。
2. 针对每一条工程，抽查人员会记录发现的若干问题(CheckIssue)。
一马行千里(759***22) 14:00:57
我对关联关系的指向问题的理解是：箭头发起方知道被指向一方的存在。
基于这个理解，画的这个图。
一马行千里(759***22) 14:01:24
但是对Project和CheckIssue间的关系，不是特别确定。
一马行千里(759***22) 14:01:55
先谢谢大家啦
山猫(29***34) 14:13:07
如果做的是ER图，箭头方向表示外部键依赖，那上面的图是可以理解的
一马行千里(759***22) 14:47:42
不是做ER图。是用UML表达这三个类的关系。我的问题是，画的这个图，是不是正确的表达了这三个类的关系？
具体的说，
1. 抽查记录(CheckRecord)有一个列表属性projects，指的是抽查记录包含若干工程。
2. 但是工程(Project)却没有一个issues的列表属性，来表达一个工程有多个问题(CheckIssue)，而是在CheckIssue里添加了projectId，来表达一个问题(CheckIssue)属于哪个工程。
#1是上一级包含一个下一级的列表属性，#2是下级包含上级的id属性
一马行千里(759***22) 14:56:22
我先把我的问题描述完哈。
对于关系#1，如果在工程中添加一个recordId，来表示一个工程属于某一条抽查记录(CheckRecord)，感觉把Project类给弄脏了，但是说不清楚。
对于关系#2，如果在Project类中，添加一个issues的列表属性，也是感觉把Project类给弄脏了，但是说不清楚。
对于这一点"说不清楚的感觉"，能否帮忙分析一下。
一马行千里(759***22) 14:56:38
描述完了。谢谢各位的时间。
潘加宇(3504847) 07:42:12
（1）把图上的冗余信息去掉：id、projectid，projects：List等一堆List，这些是另外一个领域的内容，把User、Location改成关联。
（2）CheckIssue是不是应该关联到CheckRecord（Record这个后缀不好，可以改成ProjectCheck或Check或CheckEvent）
（3）Project要知道它身上发生的事件，才能维护自己的状态，“我被检查过了”。
一马行千里(759***22) 09:24:41
针对解答中的（1）和（3），有几个不明白的地方：
（1）把图上的冗余信息去掉：id、projectid，projects：List等一堆List，这些是另外一个领域的内容，把User、Location改成关联。
一马行千里：
a. 对于ProjectCheck类里的projects，这个List对应的是ProjectChect（原来是CheckRecord）到Project一对多的关系。不明白为什么这个List也要删掉？
b. 与#a相似，projectId对应的是CheckIssue到Project多对一的关系。不明白为什么projectId要删掉？
c. 每个类中的id属性，是代码实现（存储）时，每个记录的编号。这个类可以直接生成代码中的java类。如果删掉了，这个id应该是什么时候（或者是哪个阶段）、以什么方式在UML中表示呢？
d. Project类里的spotEvents、procedures两个List在另一个图里用的，确实是项目里另一个业务的。因为当前的业务和另一个业务用的是同一个Project类，把类拖到图中后，这些属性还是显示的。
e. Location类与工程的关联关系也是在另一图中。
（3）Project要知道它身上发生的事件，才能维护自己的状态，“我被检查过了”。
一马行千里：没明白这一条是针对哪个问题说的？
（2）CheckIssue是不是应该关联到CheckRecord（Record这个后缀不好，可以改成ProjectCheck或Check或CheckEvent）
一马行千里：应该关联的，表示CheckIssue是哪一个CheckRecord中的。加了这个关联，我最初的问题得到了解决。
一马行千里(759***22) 09:25:10
谢谢老师的时间
走单骑(37***455) 09:29:12
老板请求你编程。你说："你病了，不能编程，老板你为什么不问下我病没。"老板说，你病了我不管。
潘加宇(3504847) 06:43:50
图中涉及到了几方面的知识：（1）项目管理各个概念之间的关系；（2）如何实现一对多关联；（3）如何标识对象；这些知识是正交的，过早地混合类图上就会出现大量的冗余，例如，每个类都有个id属性，每个关联都带个List。人脑的容量是有限的，过早把各种领域的知识混杂，人脑需要处理的逻辑就会从M+N+O+P增加到M*N*O*P。正确的做法是将不同的知识分开表达，再选择好几个域之间的映射套路，通过工具或人按照套路来混合。
潘加宇(3504847) 06:44:41
@一马行千里：没明白这一条是针对哪个问题说的？
–关联的方向。@走单骑(376***55) 的类比很好