UML-用例建模

为了有效地定义所沟构造系统的需要，提出需求工程的概念。主要包括：

• 定义需求：理解用户的需要，建立用户可理解的系统需求模型。
• 分析需求：根据需求模型，建立开发者无二义性解释的分析模型。

基于用例的需求定义过程是以用例为中心，来组织各类软件需求。通过用例来解决需求定义过程中出现的问题，针对需求的难捕获特点，我们需要从用户的角度去理解问题，针对易变的问题，则是通过用例来建立合理的需求结构，因为对于最终的软件产品来说，其面对的是经过开发的有价值的软件需求，而不是用户原始的要求。

业务模型描述了业务现状，而这些现状中，有些业务可能需要改进，改进点如下：

1. 流程控制   （由一连串的活动组成一个业务）下订单
2. 复杂业务逻辑  -下订单
3. 使用业务对象
4. 自动化业务

找到业务改进点知识需求定义的第一步，并不是所有的系统改进点都会作为软件需求而存在。远景包含了为待开发系统设定的目标和约束，她代表了项目涉及的所有人之间达成的第一个共识，是项目核心需求的概览。

对于每一个业务改进点，明确是否是为了达到远景目标的需要，若是，则作为软件需求而村阿紫啊，并把相应的模型转换为系统模型；若不是，则不作为需求而存在，可能作为一项潜在的需求考虑，或者直接抛弃。

与传统的输入-输出-处理的方式描述需求不同，通过用例来组织需求本身就是一种面向对象的思维方法，它通过将功能冲抽象为系统用例，从而为目标系统构建合适的用例模型，通过该用例模型完成对需求的开发和管理，而后续的分析和设计将完全基于本阶段所建立的用例模型进行。

通过各种方式获取的需求信息大多数是杂乱无章的，它们大部分是一些文字信息，开发人员需要此阿勇一种合理的方式对它们进行组织和分析。

1. 参与者要点分析 （系统外、系统边界、系统角色、与系统交互、任何事物）
2. 确定参与者（系统在哪些部门使用、谁向系统使用信息、谁与系统的需求有关联、谁对系统进行维护、与外部系统是否有关联、时间参与者）确定其成为一个参与者后，就把它表示到用例图中，此时，要给参与者一个合适的名称。参与者的命名要体现该参与者在系统中所扮演的角色，而不是具体的个人或职务，这实际上是一个抽象的过程，要从一个具体使用系统的个人的角度抽象出系统的角色。确定参与者时，还应了解参与者之间是否存在泛化关系，但过度的使用泛化对需求定义没有任何好处，反而会增加后续分析设计的复杂性。实际上，由于参与者不是系统的组成部分，一次参与者的确定并不是需求的重点，十倍参与者是为了更好的识别用例。
3. 文档化参与者

参与者是系统外与系统交互的事物，而用例就是支持参与者与系统交互并实现参与者使用系统的目标。

用例的目的是在不揭示系统内部结构的情况下定义一个连贯的行为

用例要点分析：

1. 可观测：用例的定义之关注系统对外所体现的行为。
2. 结果值：每个用例都会对外界参与者产生一个有价值的结果。
3. 系统执行：用例所产生的结果值是由目标系统所生成的。
4. 由参与者执行：用例的识别和定义都是从参与者角度出发的，以参与者的视角获取和命名用例。

识别用例的思路：

1. 参与者的日常工作
2. 参与者这业务中承担着什么样的作用
3. 参与者是否会操作与系统相关的信息
4. 参与者是否需要把外部变更通知给系统
5. 系统是否需要把内部事情通知给参与者
6. 是否需要系统维护

典型的用例名称应该是：（状语）动词+（形容词）宾语，动词前面可以加上适当的状语进行修饰，而宾语前面也可以加上定语

• 在绘制用例图时，除了表示所有的参与者和用例外，参与者和用例之间还存在关联关系，它表示该关联的参与者和用例之间存在信息交互。
• 参与者和用例之间的关联关系采用一条实线表示，这条实线可以带箭头，箭头由通信的主动方指向被动方。不带箭头则意味着建模过程中并没有考虑双方之间的影响
• 外部系统经常作为一个辅助参与者存在，代表一个需要与系统进行交互的外部不可控因素

• 用例的涉众是指用例所代表的业务影响的系统内外部人员或组织。由普通的人或部门来承担的参与者一般都是涉众。外部系统、时间等不是涉众，因为他们不是人或者组织，没有利益影响。从涉众的角度来看，用例实际上是涉众之间所达成的七月，并以参与者为达成特定目标和系统交互的方式演绎。
• 用例的前置调剂是指用例在执行之前必须满足的条件，它约束用例开始执行前系统的状态。作为用例的入口限制，前置调剂阻止参与者触发该用例直到满足所有条件。
• 后置调剂是指用例执行完成之后系统的状态。当用例存在多个事件流时，可能会对应多个不同的后置条件。利用后置条件，有助于确保涉众理解执行用例后的结果。
• 用例的事件流是指 参与者和系统交互的过程。在事件流描述时并不需要将这个完整的交互过程都表示出来；只需要描述需求部分，即用户需要什么，系统给出什么样的结果。其次事件流的描述要使用户和开发人员互相理解用例的功能。
• 一个用例可能会存在多个独立的事件流。其中一条最核心的事件流称为基本事件流，其他的时间流则为备选事件流。基本事件流是指在最一般的情况下，那些用例发生的路径，通常用来描述没有发生任何错误的情况。备选时间流代表该用例处理过程中的一些分支或者异常情况，它一般从基本事件流的某个步骤中分离出来。
• 用例重点在于描述功能需求， 但对于系统来说，还存在很多功能之外的东西，比如非功能需求等，还有其它的一些诸如数据项的定义、业务规则、设计约束等内容。这些内容统称为补充约束。与特定用例相关的补充约束，作为该用例文档中一部分来描述；而全局性的补充约束，单独形成一份独立的补充约束文档。
• 用例模型师，用例的关系主要包括包含关系、扩展关系和泛化关系。包含关系表示某个用例中包含了其他用例的行为（他提供了从两个或多个用例行为中提取公共部分的能力，把这些公共部分放到某个单独的用例中，通过包含关系来应用这些公共行为）；扩展关系是指某个用例在特定情况下无法进行处理，而把这些行为委托给其他用例；用例的泛化表明了一种继承层次，通过用例之间的泛化关系可以达到更高层次的需求复用。
• 扩展点是指在基用例中定义的特定条件，每个扩展用例都至少与一个扩展点相关联。当基用例满足了这些特定条件后，就会触发相应的扩展用例来为基用例提供附加行为