设计也可以按图索骥
前言
随着时间的推移，软工课程已经步入尾声，团队中的每个同学都付出了自己的努力。时至今日，我们已经完成了设计分析并实现了大部分代码。接下来我将简单描述一下我们团队完成设计分析的心路历程。
存在的问题
在经历需求分析的答辩之后，老师给出了一些自己的理解和建议，比较关键的一点在于：我们小组对任务之间的关系理解的不够到位，不能用简单的前驱后继去描述任务之间的联系。
我们经历了多次讨论，共同商讨了这一问题，得到了比较一致的观点。
前驱后继是个不错的描述方式，问题在于前驱后继的关系难以采取并发的方式提升工作效率。例如后一任务可以提前进行材料准备等工作，并不需要前一任务完全收工才能启动生产。这一问题我们之前确实未曾考虑过，但是解决起来也并不困难。通过给每个任务增加额外的数值属性，用来描述所依赖任务的关联程度，当子任务进度达到相应百分比，即可触发父任务的分配流程，这样的做法并没有明显提升逻辑复杂性，但可以很大程度上提高生产效率，我们最终认定这是一个可行的解决方案，并作为最终的设计进行实现。
设计的门路
整个设计流程中，个人认为最能体现设计思路的点在于：
- 任务关系的分析
- 任务的分解分配
任务之间的关系简单描述起来至少有以下四类关系
这中任务关系的类型主要影响任务分解分配时的策略，经过讨论发现，我们可以简化多依赖一这一场景下的任务关系，当多个任务B、C依赖同一个任务A，我们可以将任务A依照数量拆分为A1和A2，分别被B、C依赖。这样的拆解之后，任务之间的关系只存在两种，即：
- 单依赖
- 一依赖多
而任务的分解分配流程的设计主要体现在类图的又一轮迭代。早期设计时，我们认为分配给工厂的任务数量恒为一，若需一个工厂生产多个产品，则需多次分配。这样的做法可以简化设计，但是实现过程非常离谱，同时会给数据存储带来压力。因此我们重新进行设计，提出工序类的概念，利用工序类来管理订单的各部生产数量，再通过带有数量属性的任务类进行任务分配。如此一来，同一个订单的同类任务想要分配给一个工厂，仅需要一次任务分配即可完成。
按“图”索骥
整个设计流程走下来之后，发现设计的过程是有规律、有经验可循的。
类图的实现，决定了项目的设计思路。类与类之间的关系多种多样，都可以通过类图去体现。
类图的缺陷在于类的属性、方法仅有声明，缺乏具体的描述，这时就可以借助OCL进行描述说明，使得设计更加直观。
通过类图与OCL的结合，可以将设计流程充实起来；同时小组内部的多次讨论，促进了类图和OCL的迭代，使得设计显得更加科学。
