设计也可以按图索骥
前言
随着设计评审答辩的结束，小组的设计模型也大约是敲定了；这里我打算先谈一下自己对设计建模过程的理解与认识，然后结合小组的整个设计建模过程探索详细设计阶段的设计过程可以参照的模式。“按图索骥”，“图”是什么，又该怎样“索”？
设计建模
设计建模就是设计初期要做的工作，建立起一个框架，就像建房先要画出平面图，装修要有装修图一样。只有建模完成了才能一步步来完成设计，完成工作。
软件详细设计阶段要干什么?
确定软件系统的总体布局，各个子模块的功能和模块间的关系，与外部系统的关系，选择的技术路线。有一些研究与论证性的内容; 对概要设计的进一步细化，一般由各部分的担当人员依据概要设计分别完成，然后在集成，是具体的实现细节。是“程序”的蓝图，确定每个模块采用的算法、数据结构、接口的实现、属性、参数。
在需求分析阶段主要确认了待开发系统的核心价值,而在设计阶段就要考虑如何让这些核心价值"落地",落到实处,可以真真切切的体现在软件的设计细节上,是一个将想法落到实处的过程.
详细设计最大的作用不是解释软件是如何设计的，而是解释业务流程在软件中是如何设计的。这是基于一个共识:
开发人员不一定懂业务
这时候开发不能决定做什么，怎么做。但是可能必须知道为什么这么做，哪些不能做。这些业务知识和专业知识，也都不一定是一年两年能通的下来的。而一名开发参与一个项目未必能有这么久，这就需要详细的文档来告诉我们为什么要这样做，以及哪些不能做。也就是解释业务设定了。
但是这一点在这一次小组项目中并没有体现得十分明显, 大家通常都是身兼数职, 产品经理和开发人员之间的特征与界限并不是十分明显，所以往往会默认，大家都懂业务，大家也应该都懂业务；
所以，一般来看，详细设计模型要达到的效果是：任何一个不熟悉相关领域的程序员，根据设计模型文档，都可以开发出符合需求分析要求的系统或者软件。
总的来说, 需求分析回答了软件是什么的问题, 而设计建模回答怎么做的问题,是目标软件的蓝图;设计建模就是软件开发的"图",让其可以"按图索骥",那么设计建模也可以"按图索骥"吗? 设计阶段的"图"又是什么呢?
建模过程
简单回顾一下项目的核心价值：
满足家庭工厂的订单需求，提供高效的订单分配服务，让家庭工厂更高效的合作，提高收益。
满足顾客的产品需求，将家庭工厂协作起来，为顾客提供更低的价格，更稳定的交货和质量保证。
对订单的生产过程进行追踪和状态评估，帮助订单中介更好的了解订单生产情况。
本系统也提供辅助决策的功能，可以根据当前系统的生产状况对是否有能力接单提供建议，防止违约和生产力浪费的现象。
基于以上考虑，在设计建模的过程中，我们将重心放在了以下方面：
- 任务关系的分类（订单依据产品工序图拆分成对应的任务）
- 任务的监控管理
- 风险的监控和管理
任务的关系与监管
依照分解订单之后可能出现的情况，我们将任务的关系做如下划分：
● 按依赖程度特性：
○ 强依赖关系：只有此任务的前驱任务全部完成后此任务才能开始；
○ 弱依赖关系：此任务的前驱任务部分完成，此任务可以启动开始，进行准备原材料等相关工作。
● 按依赖种类（如下图所示）：
○ 单依赖
○ 多依赖
■ 一依赖多
■ 多依赖一
■ 多依赖多
对于上述多依赖于一的关系，我们做如下处理：
把B和C所依赖的产品A看作成两种不一样的产品A1和A2，这样依赖关系就由多依赖一变成两个一依赖于一的关系，对于多依赖于多的关系也做同样的处理，这样一来产品之间的关系就简化为:
● 按依赖程度特性
○ 强依赖关系
○ 弱依赖关系
● 按依赖种类
○ 一依赖一
○ 一依赖多
- 依赖程度的表示
对于每一个任务而言，我们用它要求它的前驱任务完成进度的多少作为此任务的启动条件，来表示此任务对于它前驱任务依赖关系的强弱；在设计上，对每一个任务维护一个分配限制列表preAllocationLimit: Map(String, Float)用来表示前驱任务完成进度达到相应条件，该任务才能够启动开始，由此来表示依赖关系的强弱
- 依赖种类的表示
对于每一个任务而言，维护一个前驱任务数组pretasks: Task[]，表示它依赖于此列表里的任务；一依赖一，即数组里只有一个元素，一依赖多则数组里有多个元素，我们总是启动满足这两个条件之一的任务：
- 前驱任务数组为空
- 前驱任务的完成进度满足条件的任务
风险的监管
系统启动后，系统进入监听状态，时刻准备接收异常状态信息的汇报。此系统的异常主要的来源为家庭工厂，家庭工厂由于生产设备损坏，生产人员人事变动等情况，出现了生产能力与生产意愿值不符合的违约情况，为避免更大规模的损失，向系统上报异常，即表明自己无法在规定时间内完成任务；接收到异常之后，回收该异常对应的生产任务并重新进行分配，直到可以满足预期生产目标，处理完毕后，返回监听状态继续监听异常，若此任务回收后无法在规定时间内分配给相应工厂则上报订单中介，等待订单中介进行处理，订单中介处理完毕后，返回监听状态，直到系统关闭，结束。
以上就是体现小组设计建模的部分过程
“图”是什么？如何“索”？
设计阶段可以参照的模式规范是什么？
- 以需求分析为指导，以核心价值落地为目标，以不懂业务的程序员可以顺利开发为评判准则
- 以架构图描述技术框架，以用例图描述需求，以类图、组件图、顺序图、状态图描述系统细节和运行时各状态情况，以OCL来约束对一个模型或者系统中的一些值的限制
- 以业务流程分析与风险控制来说明业务与规避风险
总结来说，就是：业务分析+UML+OCL
最后
感谢队友们的认真负责，大家沉住气，争取拿下“实现阶段”最后一城！
