在基于UML需求分析中，我们通常分析步骤是：（1）先定义项目所.docVIP

在基于UML的需求分析中，我们通常的分析步骤是：（1）先定义项目所包含的业务流程（也就是确定有哪些人、物、动作），这一阶段主要是绘制出业务用例图（Usecase Diagram）。如下图所示。  （2）接下来，是针对第一步中定义出来的每一个业务用例分析它的工作流程。这一阶段主要是绘制活动图（Activity Diagram）。需要注意的是，每一个业务用例下面可以有多个活动图。 （3）定义系统范围。也就是定义系统用例。在第一步中，是定义业务用例。系统用例与业务用例的区别在于：系统用例是与将要开发的信息系统紧密结合的，而业务用例则不一定会全部由信息系统来实现。这一阶段也是绘制用例图。但在这一步中，在绘制用例图时，可以通过建立包(Package)的方式，将不同的系统用例分门别类地进行管理。 如下面分别有：投资人、理财专员、主管、定时启动者四个包所对应的系统用例图。 （4）分析系统流程。主要是用系统用例叙述来描述系统用例的内部细节。 （5）分析业务规则。主要是用状态图来描述企业的业务规则。 业务规则通常分为:约束规则与衍生规则。 假定有如下规则： WHEN 约定日到 IF 正常扣款 THEN 自动扣款 要用状态图来描述该规则，应该如何绘制状态图。 分析：WHEN 约定日到（事件发生） IF 正常扣款（对象现处状态） THEN 自动扣款（转换至另一状态，并执行其中的动作） 假定有以下多项业务的规则： WHEN 约定日到（事件发生） IF 正常扣款（对象现处状态） THEN 自动扣款（转换至另一状态，并执行其中的动作） WHEN 扣款失败（事件发生） IF 自动申购（对象现处状态） THEN 累计扣款失败次数（发生转换，并执行动作） ELSE 正常扣款（转换至另一状态） WHEN 连续三次扣款不成功（警戒条件成立） IF 扣款失败（事件发生） THEN 终止扣款（转换至另一状态） ELSE 正常扣款（转换至另一状态） 要用状态图来描述该规则，应该如何绘制状态图。 在绘制状态图时，用圆角矩形表示状态，每个状态用两部分表示：上半部分表示状态名称，下半部分表示状态动作：进入动作（Entry Action）、执行动作（Do Action）、退出动作（Exit Action）。状态与状态间发生转换需要事件发生或警戒条件满足，状态的转换是通过转换线来描述（Transition），事件(Event)是添加在转换线旁边。在转换线的属性面板中，Triggers用来添加事件，其中有四类事件Signal Event（信号事件，如扣款成功或扣款失败）、Call Event（调用事件）、Time Event(时间事件，如约定日到)、Change Event（变更事件，如改成正常扣款）。Effects用来给转换线添加效果，如累计失败次数。Guard Condition用来添加警戒事件，通常是用[ ]来表示，如扣款期数 1 。 （6）定义静态结构。主要是为业务对象建立类以及业务对象之间的静态关系。对象通常会有属性与操作。该阶段主要是绘制类图（Class Diagram）。如下图所示。类通常是用一个三层的矩形表示，最上层是表示类的名称，中间是类的属性(Attribute)，最下方是类的操作(Operation)。对象之间的关系是用连线表示，连线两端表示一对多，多对多等关系，空心箭头表示泛化关系。属性前面的#表示protected，+表示Public。设置的方法是双击该属性名称，在弹出的任务条中，点击最左边的Visibility图标，进行设置。操作的参数需要通过Parameters来设置，每个参数前面的out 或in 是选中该参数后在右边的属性面板中找到Directionkind进行设置。 （7）定义操作及方法 这一阶段主要是通过序列图来实现。序列图主要由以下元素组成：对象、调用消息、执行规格、生命线。 针对一个系统用例，系统分析员可能绘制出多张序列图。通常会有一张描述主要流程的序列图，和替代流程的序列图。 下面，以网络申购单笔基金的系统用例为例，说明新增序列图的操作步骤。 在定义操作及方法 下，新增序列图（add sequence diagram），并更名为“网络申购单笔基金”、“主要流程”、“主要流程”。新增了序列图后，staruml会自动准备好绘制序列图的环境。 在“网络申购单笔基金”底下，新增序列图，并更名为“替代流程”、“替代流程”。 开始进入绘制序列图的阶段。首先，点击第三个步骤“定义系统范围”底下的“投资人”包，点击下面的“投资人”，并拖放至绘制区域的空白处。同样的，再将“存系统”拖放到空白处。再点击工具箱面板中的Object