[行为] 1用例图（用例图）

A，用例模型和用例图（用例模型和用例图）

A.1，用例模型（用例模型）

用例建模的主要功能是表达系统的功能需求或行为. （对于正在构建的新系统，用例描述了系统应该做什么；对于已经构建的系统，用例反映了系统可以做什么）. 用例建模是通过开发人员和用户之间的协商来完成的. 用例模型的基本组件是用例，参与者和系统边界. 用例模型可以包含多个用例图.

用例模型由用例图组成. 用例图显示了用例，参与者和用例之间的关系. 用例图在宏级别上给出了模型的总体轮廓，而用例的实际实现细节以文本形式编写. 用例图本身表示的图形用例模型无法提供用例模型所需的所有信息. 每个功能的含义和实现步骤必须使用用例图和文本进行描述. 用例图不仅应绘制三个模型元素，还应绘制元素之间的各种关系（关联，通用化，依赖性）.

A.2，用例图（用例图）

用例图捕获参与者和系统之间的用例和关系；他们描述了系统的功能需求，外部操作员在系统边界进行交互的方式以及系统的响应.

用例图捕获用例以及参与者与系统之间的关系. 它描述了系统的功能要求和系统的响应，以及外部操作员在系统边界处与系统进行交互.

UseTo:

n描述系统的功能要求

n描述外界（Actor）在系统边界的交互方式

n描述系统的响应.

用于:

n描述系统的功能要求

n描述外部事物如何在系统边界上相互作用

n描述系统的响应

B. 模型元素

B.1，用例（用例）

用例用于描述系统的功能，即从外部用户的角度描述系统应该支持哪些功能. 用例内容通常以纯文本形式编写.

OMG UML规范

UseCase是一种行为分类器，代表对所提供行为的声明. 每个用例都指定主题可以与一个或多个actor协作执行的某些行为，可能包括变体.

UseCase是一个行为类别，它表示提供行为的语句. 每个用例都指定一些行为，其中可能包含变量. 可以与一个或多个参与者协作执行此主题.

用例是一个UML建模元素，它描述了所建议系统的用户如何与系统交互以执行离散的工作单元. 它描述并表示随时间推移的单个交互，该交互对最终用户（人，机器或其他系统）具有意义，并且需要使整个系统处于完整状态: 交互已完成或回滚到初始状态.

UseCase是一个UML建模元素，它描述了系统用户与系统交互的方式如何执行离散的工作单元. 它描述了最终用户在一段时间内的单个交互，并且必须以完整状态保留在系统中: 交互已完成或回滚到初始状态.

一个用例:

n通常具有描述其操作所依据的基本功能和规则的要求和约束条件

n可以有一个关联的Sequencediagram来说明一段时间内的行为；谁对谁做什么，什么时候

n通常具有与之关联的场景，这些场景描述了随着时间推移产生最终结果的工作流程；还启用了替代工作流程（例如，捕获异常）.

用例:

n通常有一些要求和约束条件来描述此操作的一些基本功能和规则.

n可以有一个关联的序列图来说明随时间变化的行为，由谁执行用例图 系统边界，如何执行以及何时执行.

n通常，允许使用关联的图来描述随着时间的推移将产生最终结果的工作流，或者捕获异常.

B.2，演员（参与者）

也可以翻译为字符. 参与者是与系统交互的外部实体. 参与者是一个群体概念，代表了使用某种功能而不是个人的一类人或事物.

OMG UML规范

演员模仿由实体扮演的一种类型的角色，该实体与主体进行交互（例如，通过交换信号和数据），但是在主体外部. 演员可以代表人类用户，外部硬件或其他主体扮演的角色. 注意，参与者不一定代表特定的物理实体，而仅仅是代表与其相关用例的规范有关的某个实体的特定方面（即“角色”）. 因此，一个物理实例可以扮演几个不同演员的角色，相反，一个给定的演员可能由多个不同实例扮演.

Actor是系统的用户；用户可以表示模型中的人类用户，机器，甚至其他系统或子系统. 从外部或系统边界与系统交互的任何事物都称为Actor. 参与者通常与用例相关.

Actor是系统的用户. 在该模型中，用户可以是人类用户，机器或其他系统或子系统. 只要它与系统交互，无论它来自外部还是系统边界，任何东西都可以称为Actor. 参与者通常与用例相关.

Actor可以通过图形用户界面，批处理界面或其他某种媒体来使用系统. Actor与用例的交互记录在用例场景中，其中详细描述了系统必须提供的满足用户要求的功能. <

Actor可以通过图形用户界面，批处理界面或其他媒体使用系统. Actor和用例的交互记录在用例场景中，该用例场景详细描述了系统必须提供满足用户需求的功能.

B.3，系统边界（系统边界）

系统边界用于指示要建模的系统的边界. 边界内部表示系统的组成部分，边界外部表示系统的外部. 系统边界在图中用方框表示，并附带了系统名称. 参与者画在边界之外，用例画在边界内. 由于系统边界的功能有时并不明显，因此我个人理解在绘制时可以将其省略. （在myeclipse的UML组件中找不到系统边界）

B.4. 合作

（请参阅: “ [UML] 11复合”）.

B.5，包装（包装）

C，模型元素之间的关系

C.1，协会，协会（association）

用例与参与者之间的关系是关联用例图 系统边界，也称为交流关联. 这种关联表明参与者可以与用例进行交流. 关联关系是一种双向的关系，即参与者可以与用例进行交流，用例也可以与参与者进行交流.

（有关详细信息，请参见: “ [UML] 2类图”）.

C.2，概括，概括（概括）

在用例图中，用例和参与者都可以使用摘要. 将某些参与者的通用行为或用例抽象为一般行为，并将其描述为超类. 角色的概括/继承很容易理解，因为角色最初是类，是具有Actor原型的类，因此角色的继承是直观且自然的. 但是，用例的继承实际上分为两种情况. 这不是简单的泛化使用，而是使用扩展和包含两种类型的泛化的特殊情况.

（有关详细信息，请参见: “ [UML] 2类图”）.

C.3，扩展（扩展）

扩展连接用于指示一个元素扩展了另一个元素的行为. 在用例模型中使用扩展来指示一个用例（可选）扩展了另一个用例的行为. 扩展的用例通常表示替代流程.

扩展连接用于指示扩展另一个元素的元素的行为. 在用例建模中，扩展名用于指示一个用例的行为扩展了另一个用例. 扩展用例通常表示替代流程.

在一个用例中添加一些新操作就构成了另一个用例. 这两个用例之间的关系是扩展关系. 后者是通过继承前者的一些操作而获得的，前者成为通用用例，而后者称为扩展用例. 为子用例扩展的操作步骤与父用例的操作步骤基本相同，只是增加了其他步骤.

扩展用例对基本用例不可见.

偶尔描述处理正常行为的变形时，请考虑使用泛化关系. 当您想使用更多的控制方法来描述正常行为的变形时，可以使用USE CASE图在基本用例中设置扩展点并使用扩展关系. 扩展关系更难理解. 如果将扩展关系视为具有更多限制性规则的广义关系，则可以帮助您理解. 通常首先获得基本用例，然后询问有关该用例中的每种行为的问题: 在此步骤中会出什么问题？此步骤是否有其他情况？此步骤的工作方式如何以不同的方式进行，等等，所有更改都标识为扩展. 基本用例通常很容易构建，而扩展用例则需要重复分析和验证.

C.4，包含（包括）

包含连接表示源元素包含目标元素的功能. 包含连接用于用例模型，以反映一个用例包含另一个用例的行为. 使用Includerelationship来避免在许多用例中具有相同的行为子集；

包含连接表示源元素包含目标元素的功能. 在用例建模中，包含连接反映了一个用例包括另一个用例的行为. Include关系用于避免在许多用例中包含相同功能的子集.

用例可以简单地包括其他用例的行为，并将其包含的用例行为用作其自身行为的一部分. 这称为包含关系. 对于源用例，包含包含目标用例的所有操作. 它把目标用例作为自己的重要一步. 源用例通常包含多个目标用例.

包含关系是有向关系.

C.5，使用，用法（使用）

使用关系表示一个元素需要另一个元素来执行某些交互. 使用（或使用）关系没有指定目标供应商的使用方式，而是源客户端在定义或实现中使用它. 使用关系是子类型的依赖关系.

使用关系表示一个元素（Actor）需要另一个元素（Use Case）来执行某种交互. Use关系不需要指定如何使用目标元素（用例），除了在使用源元素（Actor）时定义和实现. 使用关系是依赖性的一个子类型（Dependency）.

您通常使用用例图中的“使用”关系来建模Actor如何使用系统功能（UseCases），或说明类或组件之间的使用依赖性.

在用例图中，通常使用Use关系来建模参与者如何使用系统功能（用例）. 或解释类和组件之间的用法依赖性.

注意:

n在Actor和UseCase之间具有关联连接器是更常见的做法（也是正确的UML）.

注意:

n更常见的是在Actor和用例之间使用关联连接（符合UML标准）.

C.6，实现（实现）

源对象实现或实现其目标对象. 在用例，组件或需求图中使用Realize连接器来表达模型的可追溯性和完整性. 业务流程或需求由一个或多个用例实现，这些用例又由某些类实现，而某些类又由组件实现，依此类推. 在整个系统设计中，从建模抽象的各个级别映射需求，类等，可以确保系统的整体能够记住并反映出所有约束和定义系统的细节.

源对象实现目标对象. 在用例，组件和需求图中，使用实现连接来表达模型的可追溯性和完整性. 业务流程或需求是由一个或多个用例实现的，而用例实际上是由某些类实现的，而类则是由组件实现的，依此类推. 通过提高建模抽象的水平，在整个系统中进行需求映射，分类和设计，确保系统的总体图片能够反映所有小的图片和细节，并对其进行限制和定义.

C.7，调用（呼叫）

调用和前提之间的关系在OML（开放建模语言）中定义. 它实际上是一个依赖项.

这表明用例A将导致用例B在某个时刻发生.

C.7，前置（前导）

它表示用例A必须在用例B开始使用之前完成.

UseCaseDiagram（用例图）'/>

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-248100-1.html