人人都是领域专家-顺序图
/**
* 转载请注明作者longdick http://longdick.iteye.com
*
*/
相关帖子：
在分析阶段顺序图（Sequence Diagram）用来描述活动图里的单一事件流。
也就是说每个用例对应一个活动图，一个活动图对应一个以上的顺序图。
顺序图是交互图（interaction diagram）的一种。另一种交互图是协作图（Collaboration Diagram）。
第一次迭代我们只关注风险最大的两个用例“购买商品”和“登录”。
有了类图做铺垫，对照着用例的活动图，我们可以轻松的画出顺序图。
下图是登录用例的正常事件流顺序图。
你可以看到顺序图的类顺序排列符合一般架构的分层原则：参与者--边界类--控制类--实体类。
但是这里有个问题，就是控制类LoginWorkflow怎么定位实体类Customer呢，当然不能凭空变出来，从顺序图推导出可能需要引入辅助类协助LoginWorkflow定位Customer。
这时候我们就需要增加一个实体类定位器，这种构造型称为LifeCycle的类可以以 实体类名+后缀 的形式命名，后缀名可以是Factory，Locator，Handler等等，在一个模型里保持一致即可。我们将其命名为CustomerLocator，提供findByName方法来定位Customer，so，LoginWorkflow只需要持有一个对CustomerLocator的引用就可以了。
修改后的顺序图如下：
刚才已经说过了，顺序图对应活动图的每个事件流，除了正常事件流，可能还需要描述可选和异常事件流。
下图就是登录用例的可选事件流示例，除了个别细节不同，大体上是很类似的。
然后就到了购买商品的用例了，购买商品用例流程比较复杂，为了说明方便，对其做了精简，精简后的购买商品活动图如下：
这个购买商品的活动图有两个事件流，从活动图我们可以清晰的推出涉及到的实体：
商品、账户、订单和顾客。
顺序图可以说是水到渠成。
在作顺序图的时侯很适合做类的关联，可以在这个时候好好想想各个实体之间的关系、控制类对实体的直接引用还是使用辅助类间接引用等等。当然有些人喜欢在画类图时就考虑类之间的关系也没有问题，我只是建议，不是要求。
基于同样的原因，我们增加了一个StuffLocator的LifeCycle类。
购买商品的正常事件流如下：
OK，如果项目时间还宽裕的话，把每个可选和异常事件流都加上。