软工团队 - UML设计
软工团队 - UML设计
分工
对于分工我们没有不是按“自己负责部分的核心模块做练习”（每个人对每个图的某一模块来依次做完四个UML）的原因，是在于画这些图并不是都能彻底分成各个“自己负责部分”的，比如负责测试的、负责算法的同学就不懂干啥了。并且每个UML都按这种粒度的划分并不是太合理，比如活动图确实是可分成比较独立的多块，而用例图只要一两个人足够。
建立在团队成员对各个模块的业务逻辑都能对照原型比较熟悉地把控的基础上，同时又为避免分工混乱，我们还是选择了把这四个UML分别分配给相应同学，然后再由他们自己细化其中各模块怎么分工的这种方式。
UML
因为整个项目的逻辑并不是太复杂，而且各个操作之间相对连贯，如果非要从哪里断层来画的话，要不然就是太过简单，要不然就是整个逻辑完整性不好。所以对于其中一部分UML图，团队选择的方式是即使各人按模块分工，但仍然是在一整张大图上协同操作，最后整合导出来的图还是对整个系统的描述。
用例图
- 面临什么问题：无
- 解决什么问题：使各个参与者涉及到的功能一目了然
类图
- 面临什么问题：无
- 解决什么问题：能清楚系统中各个类及之间关系
状态图
- 面临什么问题：总感觉怎么画都不对劲，画着画着又觉得自己在画活动图，返工N次
- 解决什么问题：描述清楚各模块对一系列触发事件的状态变化
活动图
- 面临什么问题：无
- 解决什么问题：清晰化整个系统的业务逻辑
（大图地址）
工具
超级无敌好用一生推的 process on！
至于为什么选择process on，是因为我自己入坑一年多，画什么都拿process on，越用越觉得真的是超级强大的工具。思维导图、UML、各种流程图原型图拓扑图等等都有相应的模板。而且支持非常好用的多人协作功能，可以实时地看到协作者在图上的操作。整个操作是非常方便的，画出来的效果完全满足强迫症患者的需求，如果觉得不好用一定是没有get到正确的打开方式（逃
对于这次作业...虽然道理都懂，但是在画的过程中还是纠结于活动图和状态图的区别到底是什么，然后看到某篇关于UML状态图和活动图写的很详尽博客里是这样写的：
活动图可看作状态图的特殊形式。特殊性在于活动图中的一个活动结束后将立即进入下一个活动而不需要事件触发活动的转移。
突然觉得自己是做了多少冗余的工作啊……
个人感觉真正能解决作业博客里提到的施工混乱问题，应该是一个类似这样的表：
不过完成表的工作量巨大...还在施工中。
