软件方法(下)分析和设计第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) 的类比很好
[幻灯]9.2-9.5日晚-剔除“伪创新”和“无领域”的领域驱动设计-网课
[2020.01加一套题]UMLChina建模竞赛题大全-题目全文+分卷自测(11套110题)
全程字幕-25套UML+Enterprise Architect/StarUML建模示范视频
[新增:鸵鸟]软件开发团队的脓包:皇帝的新装、口号党、鸵鸟、废话迷
《软件方法》书中自测题-题目全文+分卷自测(1-8章)16套111题
中文书籍中对《人月神话》的引用(完结,共110本):软件工程通史1930-2019、实用Common Lisp编程……
CTO也糊涂的常用术语:功能模块、业务架构、用户需求……[20210217更新]