用例模型


用例模型描述的是新系统规划的功能。它表示用户(人或机器)和系统之间交互的离散单元。该交互是一个有意义的独立单元,如:创建账户,浏览帐户信息。

每一个用例描述建立在规划系统中的功能,它可以包含另一个用例功能或用自己的行为扩展另一个用例。

Use Case - Login

一个用例描述通常包括:

  • 描述用例的常规注释和说明
  • 需求 - 用例必须提供给最终用户正式的需求。如:<ability to update order>"能更新订单"。它们都对应构造方法中建立的功能规范,并建立用例执行动作和给系统提供值的约定。
  • 约束 - 用例运行所遵循的正式规则和限制,它们定义了什么能做,什么不能做。包括:
    • 预置条件是用例运行以前就已经发生了。如:"创建订单" <create order>必须发生在"修改订单"<modify order>之前。
    • 后置条件是用例完成后必须为真,如:"订单修改和一致性检查"。
    • 常量在用例的整个运行过程中始终为真,如:一个订单一直有客户号。
  • 情形 – 用例执行时各步骤正式有序的描述,或用例实例化过程中事件发生的流程。它包含多种情形来应付特殊环境和可选择的处理方式。它们通常由文本建立和对应于顺序图的文本表达。
  • 情形图 - 描绘工作流的顺序图;类似于情形,但是图形化描述。
  • 附加属性,如实施阶段,版本号,复杂性程度,构造型和状态。


执行者

用例通常与执行者关联,执行者可以是人或机器实体,用于系统交互来执行有意义的工作从而帮助他们完成目标。执行者参与的用例定义了它们在系统中总体的作用和动作的范围。

Actor


包含和扩展用例间的关系

一个用例可以包含另一个用例功能做为它自身正常运行的一部分。通常假设在用例运行时被包括的用例每次都会被调用。例如:在修改选定订单前,列出一份客户订单表,每次<modify order>"修改订单"用例执行时,<list orders>"列出订单"用例被调用执行。

一个用例可以被一个或多个其它用例包含。通过将通用的行为提炼成可以多次重复使用的用例,有助于降低功能重复级别。

通常,在特别情况下,一个用例可以扩展另一个用例的行为。例如:如果一个用户在修改一个特别类型的客户订单之前,该用户必须得到某种更高级别的许可,然后“获得许可”<Get Approval>用例将有选择地扩展常规的“修改订单”<Modify Order>用例。


顺序图

顺序图提供随时间变化,对象交互的图形化描述。通常用来表现一个用户或执行者,对象和组件,以及它们在用例执行过程中之间的交互。一个顺序图典型地表示一个单独的用例情形或事件流。

顺序图可以出色的显示文档使用情形,既可以记录早期分析的所需对象,也可以在稍后的设计阶段验证对象。它显示一个对象到另一个对象的消息流,这些消息流对应着一个类和对象支持的方法和事件。

下面顺序图例示了左侧的用户或执行者初始化事件和消息流,它们对应于用例情形。在最终模型中,对象间传递的消息变成类的操作。

Sequence Diagram


执行图

用例是对所构造系统将有功能的正式描述。与用例关联的执行图用来设计元素(如:组件和类)和实现用例在新系统中的功能。这为系统设计者,客户和团队,这些实际建立系统的人,提供了高级别可跟踪能力。组件和类连接的用例列表说明了必须被组件执行的最少功能。

Implrementation Diagram

上图说明用例"Login"实现需求"1.01 Log On to the website"。也显示组件"Business Logic"和"ASP Pages"组件实现部分或全部"Login"功能。进一步细化可显示"Login"界面(一个网页)来实现"Login"用例。这些执行和实现连接定义了从正式需求,到用例,直至组件和界面的可跟踪能力。