UML在项目实施中的使用心得(需求分析阶段)

不知为何，连续发了4次(每次都重新把图贴上），都把我的图给弄没了，崩溃......

与其说是使用心得，不如说是再次温习了UML后，结合10多年自身的项目经验以及看到的项目所进行的纸上推演。这种推演能够让我对UML在未来项目实施中到底该怎么用、用到什么程度有一个相对更清晰的概念，因此写此文一方面整理思路，一方面也请大虾们指正。

1.需求分析阶段

在需求分析中一般首先使用的是功能模块图，来标示出大的功能划分，比如监控模块、日志模块等等。然后在功能模块图的基础上，使用Use Case图和Sequence图。

如果说功能模块图是Level1的需求分解，那么use case图就是level 2的需求分解，而Sequence图就是Level3的需求分解。一般是把level1做完了再去做level2，level2做完了再去做level3，是一个WBS(Work Breakdown)的过程.当然我们有可能会在做level3的时候发现level2没有想全，又返回去补充level2，从而完成一个迭代过程。然而如果因为有可能会出现的迭代，就去垂直的在level2想清楚一个User Case后，马上就开始做level3的事情，则由于在思维的来回切换，会导致level 2有更多的遗漏，更不易保证其完备性。

我在网上看到过有人说这种做法是错误的，use case是不应该被以功能模块划分的，应该直接是use case.然而如果一个大型系统，其use case可能是非常多的，如果没有level1的划分，基本上无法全面的整理use case。而且这种模块划分的方法很适合分层汇报：向大领导汇报时使用功能模块，向中层领导汇报时使用use case，而sequence图就是具体业务人员才关心的了。

1.1 Use Case图

用例图是被称为参与者的外部用户所能观察到的系统功能的模型图.用例图列出系统中的用例和系统外的参与者，并显示哪个参与者参与了哪个用例的执行。用例图多用于静态建模阶段(主要是业务建模和需求建模)。

如下图所示例子：

参与者之间的泛化关系，如下面例子：

在参与者之间不存在泛化关系的情况下，各个参与者参与用例的情况分别是：经理参与用例管理人事和批准预算；安全主管参与用例批准安全证书；保安参与用例监视周边。由于安全主管与经理，安全主管与保安之间泛化关系的存在，意味着安全主管可以担任经理和保安的角色，就能够参与经理和保安参与的用例。这样，安全主管就可以参与全部4个用例。但经理或者保安却不能担任安全主管的角色，也就不能参与用例批准安全证书。

1.2 Sequence图

顺序图用来表示用例中的行为顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的事件。

顺序图展示对象之间的交互，这些交互是指在场景或用例的事件流中发生的。顺序图属于动态建模。

顺序图的重点在消息序列上，也就是说，描述消息是如何在对象间发送和接收的。表示了对象之间传送消息的时间顺序。

浏览顺序图的方法是：从上到下查看对象间交换的消息。

这个定义给人的感觉是，必须是具体的类才行，但是实际上我们在需求分析阶段，是在更粗的粒度上来表示业务流程。或者可以把此时的对象理解为粗粒度的对象，而不是编程中的对象。因为需求文档是要保证所有人尤其是不懂技术的业务人员都能看的懂的，而且此时也还不足以想清楚要用哪些类。

如下图所示例子：

这里售票中心可能在实现的时候就不是一个类。

Sequence图一般用来描述主流程，而一些异常流程单独以文字形式列出，称为备选流程(alternative sequence)。