软工团队 - UML设计

软工团队 - UML设计

分工

对于分工咱们没有不是按“本身负责部分的核心模块作练习”（每一个人对每一个图的某一模块来依次作完四个UML）的缘由，是在于画这些图并非都能完全分红各个“本身负责部分”的，好比负责测试的、负责算法的同窗就不懂干啥了。而且每一个UML都按这种粒度的划分并非太合理，好比活动图确实是可分红比较独立的多块，而用例图只要一两我的足够。

创建在团队成员对各个模块的业务逻辑都能对照原型比较熟悉地把控的基础上，同时又为避免分工混乱，咱们仍是选择了把这四个UML分别分配给相应同窗，而后再由他们本身细化其中各模块怎么分工的这种方式。

UML

由于整个项目的逻辑并非太复杂，并且各个操做之间相对连贯，若是非要从哪里断层来画的话，要否则就是太过简单，要否则就是整个逻辑完整性很差。因此对于其中一部分UML图，团队选择的方式是即便各人按模块分工，但仍然是在一整张大图上协同操做，最后整合导出来的图仍是对整个系统的描述。

用例图

• 面临什么问题：无
• 解决什么问题：使各个参与者涉及到的功能一目了然

类图

• 面临什么问题：无
• 解决什么问题：能清楚系统中各个类及之间关系

状态图

• 面临什么问题：总感受怎么画都不对劲，画着画着又以为本身在画活动图，返工N次
• 解决什么问题：描述清楚各模块对一系列触发事件的状态变化

活动图

• 面临什么问题：无
• 解决什么问题：清晰化整个系统的业务逻辑

（大图地址）

工具

超级无敌好用一辈子推的 process on！

至于为何选择process on，是由于我本身入坑一年多，画什么都拿process on，越用越以为真的是超级强大的工具。思惟导图、UML、各类流程图原型图拓扑图等等都有相应的模板。并且支持很是好用的多人协做功能，能够实时地看到协做者在图上的操做。整个操做是很是方便的，画出来的效果彻底知足强迫症患者的需求，若是以为很差用必定是没有get到正确的打开方式（逃

---

对于此次做业...虽然道理都懂，可是在画的过程当中仍是纠结于活动图和状态图的区别究竟是什么，而后看到某篇关于UML状态图和活动图写的很详尽博客里是这样写的：

活动图可看做状态图的特殊形式。特殊性在于活动图中的一个活动结束后将当即进入下一个活动而不须要事件触发活动的转移。

忽然以为本身是作了多少冗余的工做啊……

我的感受真正能解决做业博客里提到的施工混乱问题，应该是一个相似这样的表：

不过完成表的工做量巨大...还在施工中。