软件方法（下）分析和设计第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题
怪论：东北公司用用例做需求，反映了东北互联网落后？
别把洋垃圾当宝贝-评InfoQ中国“敏捷……”文章（一）
中文书籍中对《人月神话》的引用（完结，共110本）：软件工程通史1930-2019、实用Common Lisp编程……
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
UMLChina服务介绍
