用例图(参与者、用例...)

一 定义

        用例图(Use Case Diagram)是统一建模语言(UML)中的一种图表,用于描述系统的功能需求和系统与外部用户(参与者)之间的交互。用例图提供了一种从用户角度观察系统的方式,展示了系统的功能以及与之相关的用户或外部系统如何使用这些功能。

1.1 术语

  • 用例图是描述系统功能和用户如何与系统交互的视图。
  • 边界:边界定义了系统的外部界面,它将系统内部的元素(如用例和辅助角色)与系统外部的元素(如参与者)区分开来。
  • 参与者(Actor):是与系统交互的外部实体,可以是人、组织、外部系统或者其他软件。参与者位于边界之外。
  • 用例(Use Case):描述了系统提供的一项功能,它定义了参与者可以请求系统执行的一系列动作;用例位于边界之内。
  • 通信:参与者通过边界与系统内部的用例进行通信。边界表明了参与者与用例之间的交互点。
  • 封装:边界起到了封装的作用,它隐藏了系统内部的复杂性,只展示了对参与者可见的接口。

二 图例

2.1 角色

        参与者是与系统交互的外部实体,可以是人、组织、外部系统或其他软件;参与者通常用一个人形图标来表示,并附带一个名称。

语法:

@startuml

:First Actor: as actor1

actor ThiredActor as actor2

actor :Fourth Actor: as actor3

@enduml

2.2 用例

        用例是系统执行的一项动作序列,它从参与者的视角定义了系统的功能;用例通常用椭圆来表示,并附带一个简短的描述性名称。

语法:

@startuml

(First usecase) as UC1

usecase SecondUsecase as UC2

usecase (Third usecase) as UC3

@enduml

2.2.1 用例描述

如果想定义跨越多行的用例描述,可以使用双引号将其裹起来;还可以使用这些分隔符:

  • --(横线)
  • ..(虚线)
  • ==(双横线)
  • __(下划线)

并且还可以再分隔符中间放置标题。

语法

@startuml

usecase UC1 as "You can use

several lines to define your usecase.

You can alse use separators.

--

Several separators are possible.

==

And you can add titles:

..Conclusion..

This allows large description."

@enduml

2.3 包

是用来组织和管理用例图元素的工具,它有助于将大型系统的复杂性简化。包可以将相关的用例、参与者和其他包分组在一起,以展示它们之间的关系和组织结构。在用例图中,包通常用一个矩形来表示,矩形内部可以包含用例、参与者或其他包。包的名称通常显示在矩形的顶部或底部,而包的内容则显示在矩形的内部或旁边。

语法:

@startuml

left to right direction

actor Guest as g

package Professional {

actor Chef as c

actor "Food Critic" as fc

}

package Restaurant {

usecase "Eat Food" as UC1

usecase "Pay for Food" as UC2

usecase "Drink" as UC3

usecase "Review" as UC4

}

fc --> UC4

g --> UC1

g --> UC2

g --> UC3

@enduml

2.4 关系

关系类型

说明

表示符号

关联

参与者与用例之间的关系

泛化

参与者之间或用例之间的关系

包含

用例之间的关系

拓展

用例之间的管理

语法:

@startuml

left to right direction

actor Guest1 as g1

actor Guest2 as g2

usecase Usecase1 as u1

usecase Usecase2 as u2

usecase Usecase3 as u3

g1 --> u1

g1 -|> g2

u1 ..> u2 :<<include>>

u2 ..> u3 :<<extend>>

@enduml

2.4.1 包含

基础用例可以依赖包含用例执行的结果,但是双方都不能访问对方的属性;父类指向子类(has a)。当多个用例中用到多个相同的事件流时,把这些事件流抽象出来就形成了抽象用例,称为包含用例,(提高复用性,就像提取公因式一样),原始的是基础用例。

案例:

2.4.2 拓展

扩展用例为基础用例添加新的行为;扩展用例可以访问基用例的属性,因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基础用例不可见。

2.4.3 泛化

泛化相当于is a关系,继承关系。子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。

三 规约

用例图只是在总体上大致描述了系统所提供的各种服务,让人们对系统有一个总体的认识。但对于每一个用例,还需要详细地描述信息,以便让别人对于整个系统由更加详细的了解,这些信息包含在用例规约(Use Case Specification)中。

  1. 简要说明(Brief Description)

简要说明是指对用例作用和目的的简要描述。

  1. 事件流(Flow Event)

事件流包括基本流和备选流。基本流描述的是用例的基本流程,是指用例“正常”运行时的场景。备选流描述的时用例执行过程中可能发生的异常和偶尔发生的情况。

  1. 用例场景(Use-Case Scenario)

同一个用例在实际执行的时候会有很多不同的情况发生,称之为用例场景,也可以说用例场景就是用例的实例,用例场景包括成功用例场景和失败场景。

  1. 特殊需求(Sepcial Requirement)

特殊需求是指一个用例的非功能性需求和设计约束。特殊需求通常时非功能性需求,包括可靠性、性能、可用性和可扩展性等。

  1. 前置条件(Pre-Condition)

前置条件是指执行用例之间系统必须所处的状态。例如,前置条件是要求用户有访问的权限,或是要求某个用例必须已经执行完。

  1. 后置条件(Post-Condition)

后置条件是指用例执行完毕后系统可能处于的一组状态。例如,要求在某个用例执行完后,必须执行另一个用例。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值