不得不说的UML和SysML用例图例的区别

1 简介

基于模型的系统工程(MBSE)，是建模在支撑系统中的形式化应用，需求、设计、分析、验证和确认的活动。 从概念设计阶段开始，一直持续到最后发展和生命周期后期阶段。

SysML系统模型语言与UML2有何关系？

用例图设计目的是捕捉系统的功能需求和用户的预期使用方式。

用例图的提供主题系统的高级视图，并以非技术语言向所有利益相关者（包括客户和项目经理以及架构师和工程师）传达顶级系统要求。需要其他更严格的SysML图来指定可扩展和可模拟的系统架构模型（SAM）。

2 UML2用例图

定义：用例图是UML的一部分，用于表示系统与外部用户（或其他系统）之间的交互。它主要用于捕捉系统的功能需求。

主要元素：

用例（Use Case）：系统的功能或服务，通常以椭圆表示。

角色（Actor）：与系统交互的外部实体，通常以小人图标表示。

关系：包括关联（Association）、扩展（Extend）、包含（Include）和泛化（Generalization）。

用例图uc有四类关系

• 关联  <<Relevance>>   参与者和用例之间有关联关系。

• 包含关系  <<include>> 这表明一个用例行为的包含在另一个用例中。

• 泛化关系 <<Generalization>> 这表明角色和用例的继承关系，一个用例是另一个的变异。

• 扩展关系 <<extend>> 一个用例扩展另一个用例的行为。这提供了一种比泛化关系更可控的扩展形式。

3 SysML1.5中 用例图

定义：SysML是从UML扩展而来的，专注于系统工程领域。SysML的用例图类似于UML，但更加关注系统与其环境之间的交互以及系统需求。

用例图显示了系统边界上下文中系统事务（用例）和外部用户（参与者）之间的通信（主题;符号：矩形）。

参与者可以是软件（个人、组织、设施）、软件系统或硬件系统。 定义系统主体和系统参与者之间的关系是定义系统有效范围的非正式方法。

• 主要元素：

    用例（Use Case）：和UML相同，用于表示系统的功能。
  
    角色（Actor）：和UML相同，表示与系统交互的外部实体。
  
    系统边界（System Boundary）：明确标识系统范围的矩形框，表示系统与环境的分界。
  
    四个关系：关联，扩展，包含，泛化，但可能包含更多针对系统工程的细节。

SysML中关系与UML基本相同

1 关联（Association）：同UML，用于表示角色与用例的交互。
2 扩展（Extend）：与UML相同，用于表示用例的扩展。
3 包含（Include）：与UML相同，用于表示用例的包含关系。

当几个用例共享公共步骤时，通常会发生这种情况。 包含的用例可以提出共同的行为。

ATM机的一个例子可能是"取款"和"转账"两者都使用"验证客户"。 包含关系取代了常用旧版的"使用关系"。

4 泛化（Generalization）：与UML相同，用于表示角色或用例的继承关系。

我们可能有一个取款用例(基本用例)和一个单独的用例来处理，比如因资金不足而拒绝提款的情形。

拒绝可以作为一个专门使用提取用例的用例来处理。(您也可以将其作为另一个场景来处理在取款用例中。) 一个专门化的用例，比如这可能会改变基本用例的任何方面。

在这里基本用例声明了许多扩展点。扩展的用例只能改变那些扩展的行为点。

如果你在网上购买产品，你可能会有一个购买带有扩展点的产品的用例，比如需要运输信息和捕获付款信息。

然后，可以将该用例扩展到普通客户这个信息可以通过另一种方式获得。

4 示例：SysML标准的用例图

用例图（Use Case Diagram）展示系统及其环境之间的交互。

应用场景通常是定义一个新软件系统的功能，如银行系统中的账户管理和交易处理。

用例（表示法：椭圆形/椭圆）表示与外部系统用户（称为 Actor ）的系统事务。用例图有时被视为高级功能需求。

• 示例1 卫星用例图

• 示例2 顶级用例图

会和用例

5 表示方法的区别

• UML2 用例图

UML2用例系统边界：使用矩形框表示，但不强制要求。系统内部和外部的交互通过角色和用例之间的关联关系体现。

UML2用例交互表示：通过角色与用例之间的连线（关联）表示系统与外部角色的交互。扩展、包含等关系用于表示用例之间的交互。

• SysML 用例图

SysML 用例系统边界：明确要求使用系统边界框来定义系统范围，这在系统工程中很重要，以清晰划分系统与外部环境。

SysML 用例交互表示：与UML类似，通过角色和用例之间的关联来表示交互，但更注重系统整体与外部环境的关系，通常会更详细地描述系统边界。

• 用例图使用实践

如果用例被认为是高级系统功能需求，则应使用细化（<<refine>>）依赖关系将其追溯到"functionalRequirement"需求。

• 如何最佳实践？

1 限制用于头脑风暴等。

2 尽快切换到高级活动图，通常配合其他模型图使用。

• 用例图的缺陷：

用例图细节不足：用例图主要用于高层次的需求分析和功能描述，对于复杂系统中的详细业务逻辑和操作步骤无法充分表达。例如，用例图可以显示"交易股票"这一用例，但无法展示交易过程中的详细步骤、条件和分支逻辑。

用例图缺少动态行为：用例图不能描述系统在运行过程中状态的变化和动态行为。对于复杂的系统，了解不同状态下的行为以及状态之间的转换是至关重要的。用例图在这方面无能为力，需要借助状态图或活动图等其他UML图来补充。

用例图交互细节不清晰：用例图中的角色与用例之间的关联关系通常只表示存在交互，但无法明确交互的细节和数据流。例如，用户提交交易请求后，系统如何验证、处理以及反馈结果，这些都无法通过简单的用例图清晰表达。

用例图在复杂系统的可视化困难：当系统变得非常复杂时，用例图可能变得过于庞大和复杂，难以理解和管理。一个包含几十个用例和角色的图可能会变得混乱，失去其应有的简洁性和可读性。

6 小结

用例图虽然在捕捉系统的功能需求和高层次的用户交互方面非常有用，但在复杂系统的详细行为描述、动态行为、交互细节和可视化方面存在局限。

为克服这些缺点，通常需要结合其他类型的UML图（如活动图、状态图和序列图）以及详细的需求文档来全面描述系统的行为和逻辑

一般用例图配合活动图一起使用，我们通常使用用例图表达产品需求，确定功能的系统边界，接着通过活动图来表达用例之间的流程。

用例图是需求结构化的表达，能够比较容易的看到系统包含哪些功能，是静态的，单纯从用例图没办法了解用例之间是怎么流通的，因此我们会通过活动图来配合，表达出用例的流程。

参考：

UML和SysML的用例图定义和标准由OMG（Object Management Group）提供。

• UML 2.5.1 规范见《UML 2.5.1 Specification》。

• SysML 1.6 规范见《SysML 1.6 Specification》。