建模要求
1.建模答案需包括：
- 用例图
- 新建清单及任务的活动图
- 清单/任务管理领域模型
- 清单/任务的状态图
- 任意一个场景的系统顺序图
- 操作协议
2.具体的制图要求同课程规范
建模者答案与评价
1.https://blog.csdn.net/Alice_am/article/details/80294682
- 【用例图】这个应用中涉及的操作有很多，对象之间也有嵌套关系，所以用例图是比较难画的。这份答案的用例图逻辑很清晰，没有遗漏操作——搜索和云同步功能可以暂时不考虑进系统。只不过添加任务的用例因为它有不同层级的两个入口，所以既可以认为是管理清单内容的子用例，也可以认为是一个单独的用例，这时候“选择清单”这个动作会有差别，很难同时把两种意思表达出来。
- 【活动图】其实我感觉，站在用户的角度，这个应用的业务里面随便一个动作都可以单拎出来做一个活动：开始->修改XXX->结束。就比方说，复制清单跟管理任务没有绝对的先后关系。不过既然如此这里的活动图也没啥好画的，答案中的图或许进一步理清了系统的功能架构吧。
- 【领域模型】没毛病，很好。
- 【状态模型】理由和活动图那里一样，我觉得如果不考虑云同步的功能，没啥好画的。答案里面有点bug就是：框里面应该都是些像“被删除”、“被创建”这样的表状态的词，而编辑、添加、删除这样的动词应该放在直线旁边。
- 【系统顺序图】也没什么大问题。如果要更好的话，或许可以再仔细考虑参数，以及系统分本地和云端去考虑。
2.https://yinghongzhang.github.io/2018/05/13/Lesson9-%E5%A5%87%E5%A6%99%E6%B8%85%E5%8D%95/
- 【用例图】：搜索清单那里可以支持对所有任务的名称和描述进行搜索，用例图没表现出来
- 【活动图】：没好好利用符号
- 【领域模型】：没毛病，很好
- 【状态模型】：整体挺不错的，但是缺少了终止状态
- 【系统顺序图】：没有考虑到传参
3.https://mikexuq.github.io/2018/05/11/Lesson9/
- 【用例图】：用例图名称需要以动词开头，且“清单管理”仅是其中某一子用例；建议增加“管理任务”子用例，且将各个子用例细化，如“创建清单”创建清单子用例可拓展出“填写名称”、“邀请成员”和“选择清单夹”。
- 【活动图】：比较难画，可选择将业务中“创建清单”、“管理清单”、“创建任务”、“管理任务”等用例拆分成单个的活动图，这些用例之间没有绝对的先后关系。
- 【领域模型】：缺少“清单夹”，还有部分实体的属性有缺漏，如“文件”缺少“文件内容”。
- 【状态模型】：笔误将某些“清单”打成“订单”。
- 【系统顺序图】：考虑“创建任务”，以及细化参数。
4.https://blog.csdn.net/LadyCaro/article/details/80303246
- 【用例图】：用例图中第一级的几个清单对象的操作如创建清单、删除清单、编辑清单可以抽象成管理清单，创建任务和删除任务应该处于同一级，用例逻辑不够清晰
- 【活动图】：就创建任务这个用例来说，这个活动图挺好的
- 【领域模型】：如果一个用户有0-n个清单夹，不需要另外再表明用户有0-n个清单
- 【状态模型】：状态模型多个状态是重复的，应该合并到同一个框内
- 【系统顺序图】：没什么大问题
5.http://www.elsye.cn/system%20analysis%20and%20design/system-analysis-homework6/
6.https://blog.csdn.net/xiasilo/article/details/80286566
7.https://blog.csdn.net/Liluyuan5323/article/details/80290174
8.https://sasakiyori.github.io/2018/05/13/SAD-hw7.html
9.https://www.zybuluo.com/zichuanyan/note/1146003
10.https://blog.csdn.net/weixin_38057349/article/details/80298888
- 【用例图】：整体来说画的很详细，基本上覆盖了所有的用例。不过曾记得老师讲过“管理”一词可代表“增、删、改、查”四种功能，所以私以为可以将“创建任务”归属于“管理任务”，将“创建清单”归属于“管理清单”，而且“管理”父用例和“增、删、改、查”四个子用例间用《include》会更加准确（include：表示子用例是父用例的一部分，通常强调离开这个特性，父用例无法达成目标或失去意义！ extend：表示子用例是父用例的可选场景或技术特征。）。其他的没有什么问题。
- 【活动图】：“创建清单”下面，将“填写清单名称”、“邀请成员”、“选择清单选项”作为三条路径不妥，就图来看，似乎选择其中一个操作就不能选择其他的操作，但是这三个操作是可以同时发生的。下面的“创建任务”下的“设置到期时间、提醒”、“添加子任务”、“编写备注”、“添加文件”、“发表评论”的分路径也存在同样的问题。另外，私以为最好将创建清单和创建任务分成两个活动图，因为创建完清单并不一定需要创建任务，也就是说，清单创建完毕即可完成。
- 【领域模型】：“清单夹”和“清单”似乎有些冗余了，在“奇妙清单”上，进去的页面是一个清单夹列表，点进去某一个清单夹，则显示一个任务列表，故而“清单”这个概念类可以删去。其他的没有什么大问题。
- 【状态模型】：“已编辑”和“已创建”的订单都可以删除，故而都应该有指向“已删除”状态的箭头。
- 【系统顺序图】：这个顺序图应该包含了好几个场景不是一个，也就是说可以分开来成为多个系统顺序图。因为前面的操作（比如排序）和后面的操作（比如删除），没有因果关系，也没有前后顺序关系，系统顺序图是表明一个场景中严格的操作顺序关系，所以私以为放在一个场景里不妥。
- 【操作协议】：前置条件应该为“存在任务”。
11.https://blog.csdn.net/S_Mars/article/details/80303560