PM Suite案例：鲁棒图探索发现架构级决策点

对PM Suite这样中等复杂度的系统，直接拍脑袋决定它是C/S架构还是B/S架构是不负责任的——PM Suite有哪些功能、这些功能用C/S实现合适还是B/S实现合适、非功能要求会如何影响架构风格选择，这些问题需要先积累决策依据才能回答。做法是运用[[鲁棒图的增量建模技巧]]，对”确定关键需求”步骤输出的关键功能做探索性的初步设计，为真正确定架构风格和高层分割积累依据。以”制定进度计划”这个关键功能为例：先识别出最明显的职责——”任务进度设置界面”边界对象、”排定任务时间”控制对象、”任务进度”实体对象；接着不断迭代发现新职责——”任务进度设置界面”也能”确定任务依赖”，进而想到还要支持通过”WBS展现界面”来确定任务依赖，”WBS展现界面”的数据又引出了”WBS”实体对象和”更新WBS展现”控制对象（读取WBS、任务间关系、任务进度三个实体对象，被”确定任务依赖”和”指定任务时间”共同触发调用）。不断这样分析下去，一些架构级的”关键决策点”就自然暴露出来了——比如”WBS的定义是放在File中、还是放在DB中”这个问题之所以关键，是因为它和”架构风格能不能采用纯B/S架构”直接相关：如果WBS这类复杂交互密集的数据结构必须靠文件级的本地操作支撑，纯B/S架构就可能力不从心。这个案例说明鲁棒图的价值不止于”设计单个功能”，用在关键功能上时，它还能像探针一样，把原本隐藏在功能细节里、真正决定架构走向的关键决策点主动”挖”出来，而这类决策点单靠拍脑袋分析架构风格是发现不了的。