第4章：UML及用例图

UML

UML(统一建模语言)是为软件系统的制品进行描述、可视化、构造、文档化的一种语言。

UML是一种建模语言，并不是建模方法

建模方法 = 建模语言 + 建模过程

UML的构成

• UML基本图素
• UML模型图
• UML建模规则

UML的4+1视图

每个视图关注软件开发的某一个侧面，视图由模型图组成。模型图描述了构成视图的基本模型元素以及其相互关系。

• 用例视图
• 设计视图（逻辑视图）
• 进程视图
• 实现视图
• 分布视图

用例视图

描用来支持软件系统的需求分析，定义系统边界，关注于系统的外部功能描述。从系统使用者的角度，描述系统外部的静态功能和动态行为。

图书馆管理系统的用例视图

1. 参与者： 参与者是与系统进行交互的外部实体，可以是人、其他系统或者设备。在图书馆管理系统中，可能有以下参与者：
   • 图书管理员：负责管理图书馆的图书、借还书等操作。
   • 读者：使用图书馆服务来借阅和归还书籍。
   • 图书目录系统：一个自动化的系统，用于记录图书的信息。
2. 用例： 用例是系统中的一个功能或者一个完整的操作场景。例如：
   • 借书：读者通过系统借阅一本书。
   • 还书：读者通过系统归还一本书。
   • 查询图书信息：读者或管理员可以通过系统查询图书的基本信息。
   • 添加新书：管理员可以通过系统添加新的图书记录。
3. 关系： 用例图中的箭头表示参与者与用例之间的关系。例如：
   • 图书管理员与”借书”和”还书”用例有关联，表示管理员可以执行这些操作。
   • 读者与”借书”和”还书”用例也有关联，表示读者可以执行这些操作。
4. 系统边界： 用例图中的系统边界表示系统的范围，即用例图所描述的系统的边界。在图书馆管理系统中，系统边界可能包括图书馆内的所有相关功能和交互。

对应的模型图：交互图（顺序图和协作图）、状态图、活动图

逻辑视图

类图展示类之间的关系和行为，理解系统的静态结构和关系，系统蓝图，系统内部组成和关联，不涉及具体实现细节

图书管理系统的逻辑视图

1. 类： 在逻辑视图中，我们首先标识出系统中的类，每个类代表系统中的一个抽象概念。在图书管理系统中，可能有类如下：
   • Book（书籍）
   • Library（图书馆）
   • User（用户）
2. 关系： 接下来，我们描述这些类之间的关系，这可以通过类图中的连接线表示。例如：
   • 书籍和图书馆之间可能有关联关系，表示一本书属于某个图书馆。
   • 用户可能与图书馆之间有借阅关系，表示用户可以借阅图书馆的书籍。
3. 属性和方法： 我们还可以在每个类中标识出属性和方法。例如：
   • Book 类的属性可能包括书名、作者、出版日期等。
   • Library 类可能有方法如借书、还书等。

定义系统的实现逻辑，描述为了实现用例图描述的功能，在对软件设计时候所产生的设计概念（设计词汇，类对象）。逻辑视图定义了设计词汇的逻辑结构，之间的语意关系。

对应的模型图：类图、对象图、交互图、状态图、活动图

进程视图

系统的动态行为，即系统中各个组件之间的通信、交互、以及数据流动的过程，活动图或顺序图

在线订购系统

• 活动：用户登录、浏览商品、将商品加入购物车、结算购物车、选择支付方式、确认订单、生成订单
• 顺序：
  • 当用户登录时，系统会验证用户身份。
  • 当用户浏览商品并加入购物车时，系统会更新购物车中的商品信息。
  • 当用户选择支付方式并确认订单时，系统会生成订单并向用户发送确认消息。
• 流程：
  • 用户登录过程包括输入用户名和密码，系统验证用户信息。
  • 结算购物车的过程包括计算总价、选择配送地址等步骤。

实现视图

系统的物理实现和软件组件之间的依赖关系，逻辑结构到物理结构上的映射（软工中软件组件的部署运行维护）

在线购物系统的实现视图

1. 组件： 在实现视图中，我们标识系统中的各个组件，这些组件可以是软件模块、库、服务等。在在线购物系统中，可能有组件如下：
   • Web Frontend（Web前端）：负责处理用户的界面和交互。
   • Application Server（应用服务器）：包含业务逻辑，处理用户请求。
   • Database Server（数据库服务器）：存储商品信息、用户信息等数据。
2. 依赖关系： 我们通过箭头表示组件之间的依赖关系，即一个组件如何依赖于另一个组件。例如：
   • Web前端依赖于应用服务器，因为它需要通过应用服务器处理用户请求。
   • 应用服务器依赖于数据库服务器，因为它需要从数据库中检索商品信息。
3. 物理部署： 实现视图还可以包括系统的物理部署信息，即这些组件如何部署在硬件上。例如：
   • Web前端可能部署在Web服务器上。
   • 应用服务器可能运行在应用服务器集群中。
   • 数据库服务器可能位于独立的数据库服务器上。

定义了逻辑结构的物理实现，包括设计元素对应的源代码文件，物理文件之间的关系等。

对应模型图：部件图、交互图状态图、活动图

部署视图

软件组件如何被部署在硬件或者执行环境中，硬件设备、网络配置以及软件组件的分布

在线社交平台的部署视图

1. 硬件节点： 在部署视图中，我们首先标识系统所涉及的硬件节点，即物理设备。例如：
   • Web服务器：用于托管和运行Web应用程序。
   • 数据库服务器：存储用户数据和社交信息。
   • 负载均衡器：帮助分发用户请求到多个Web服务器上，以提高性能和可伸缩性。
2. 软件组件的物理部署： 我们描述软件组件如何被部署在硬件节点上。例如：
   • Web应用程序部署在Web服务器上。
   • 数据库管理系统（DBMS）运行在数据库服务器上。
3. 网络配置： 部署视图还包括系统中各个硬件节点之间的网络配置。例如：
   • Web服务器和数据库服务器之间通过高速局域网连接。
   • 负载均衡器和Web服务器之间通过负载均衡的网络配置进行通信。
4. 物理连接： 描述硬件节点之间的实际物理连接。例如：
   • Web服务器通过光纤与数据库服务器连接。
   • 负载均衡器通过交换机与Web服务器通信。

描述软件产品在计算机硬件系统和网络上的安装、分发和分布。

对应的模型图：静态特性：部署图。动态特性：交互图、状态图、活动图。

UML的9种图形

• 类图
• 对象图
• 用例图
• 顺序图
• 交互图
• 状态图
• 活动图
• 组件图
• 分布图

用例图

什么是用例

用例：对（用户）所关心的事情的描述。user case

场景：用户与系统之间的一个交互过程，也就是实现这次交互所要经历的一系列步骤。

用例就是一组场景，用以共同描述用户的某个特定的目标。客户，开发人员，其他人员都对用例模型很关心。

用例分析的意义：

任何方法的首要问题是了解需求。所以需要进行用例分析

1. 描述和决定系统的功能需求，帮助客户和开发人员形成一致意见
2. 给出系统应该做什么且与内容一致的可视化描述
3. 在软件测试阶段作为系统测试的基础。

用例的特点

• 用来描述系统功能（外部使用者看到的系统功能），不反映功能的实现方式
• 描述用户提出的一些可见需求，对应一个具体的用户目标
• 反应系统与用户的一次交互过程，具有交互的信息的传递。

用例图中的模型元素

• 系统边界：提供用例所需要的功能的的黑盒子。系统的外部特性由系统功能来定义，系统功能用一组用例来描述。

• 执行者：需要使用系统的任何外部实体

  系统边界之外

• 用例：用客户或客户语言和词汇来描述一个系统的完整功能。

• 关联：连接执行者和用例。表示执行者所表示的系统外部实体和该用例所描述的系统需求有关

  associate：执行者参与、使用用例

• 包含：用例A连向用例B，表示A使用了B的行为或功能

  include：

  package：组织模型元素

• 拓展：用例A连向用例B，表示B描述了一项基本需求，而A则描述了该基本需求的特殊情况。

  extend：

  generalization：用例继承或特化另一个用例（参与者），三角形箭头（父类或接口）

参与者（活动者、执行者）

参与者是外部需要与系统交互的事物，分为人、设备和外部系统

用例间的关系

1. 关联关系

（参与者与用例之间的关系），表示参与者与用例之间具有使用，交互信息的关联。

1. 泛化关系generalization

参与者与参与者之间，用例与用例之间的关系。被泛化的时候，表示其可以定义为一个更为抽象的参与者或者用例

1. 包含关系include

   两个用例之间，一个用例（基本用例）的行为包含了另一个用例（包含用例）的行为。包含关系用依赖关系的<<include>>构造型来表示。

   

   需要注意包含关系的正确使用，不要用它来描述功能，应该要描述对象。

2. 拓展关系extend

拓展关系表示基本用例在拓展点要增加的新的行为或功能，以拓展到新用例。用依赖关系的<<extend>>构造型表示。

拓展用例可以在基用例上添加新的行为，但是基用例必须生命某些特定的拓展点，并且拓展用例只能在这些拓展点上拓展新的行为。拓展用例的目的是在**不改变某个已经存在的用例**的前提下为其增添新的行为。

包含与拓展关系

包含关系强调被包含用例是基础功能的一部分，而拓展关系强调拓展用例是在特定条件下的可选功能。

在用例图中，包含关系通常使用虚线和箭头表示，而拓展关系通常使用带有条件的虚线和箭头表示。

箭头指向的是基础功能

1. 包含（Include）关系：
   • 解释： 包含关系表示一个用例包含了另一个用例，即被包含的用例是基础功能，而包含它的用例是扩展功能。
   • 例子： 假设有一个用例叫做”支付订单”，而另一个用例叫做”生成发票”。这两个用例可能存在包含关系，因为支付订单的过程中可能需要生成发票，而生成发票是支付订单的一个基本组成部分。
2. 拓展（Extend）关系：
   • 解释： 拓展关系表示一个用例在某些条件下可以扩展另一个用例，即被拓展的用例是基础功能，而拓展它的用例是可选的附加功能。
   • 例子： 假设有一个用例叫做”预订机票”，而另一个用例叫做”选择座位”。这两个用例可能存在拓展关系，因为在预订机票的过程中，并不是所有用户都会选择座位，但在某些情况下，用户可以选择座位，这是一种可选的扩展。

建立用例模型

主要工作流程

• 定义系统（系统边界、系统名）

  系统名、系统边界（哪些人工做、哪些系统做、有多复杂）、系统定义（有什么交互就表示什么交互、需要时才加入外界系统）

• 找出执行者（主要次要、主动被动）：生成角色描述模板【角色名、职责、指责识别】

  谁使用系统、谁需要系统支持、谁维护管理系统（人）、系统要控制什么硬件（传感器、IO）、和系统交互的其他系统（几乎都有数据库）、谁对系统感兴趣

  执行者也是类，有属性和行为

• 找出用例

  发现用例的一般方法：

  ① 找出系统外部参与者，确定系统边界和范围。

  ② 确定各参与者所期望的系统行为。（写出基本动作，一眼法！！！）

  ③ 把这些系统行为命名为用例。（动作命名，构成用例模块！！！）

  ④ 确定各用例之间的关系(泛化，包含，扩展)。（局部组装！！！）

  ⑤ 绘制用例图。（组装画图！！！）

  ⑥ 编制用例说明。（写说明书！！！提问执行者！！！给出每个基本用例的流程！！！）

  ⑦ 对异常流程确定单独用例。（写用例时问问操作有什么异常！！！）

  ⑧ 优化用例图，解决用例之间的冲突和重复。

  粒度划分：扩充用例

  • 用例有路径，路径有步骤，多用include和extend
  • 把步骤当用例
  • 把系统活动当用例（善用include）：问一下系统能否自动实现、系统要什么输入输出、手工操作的问题

• 描述用例（系统行为、关系、说明、优化）

• 用例的整理与加工（泛化、包装、包含、拓展）

• 验证模型（需求分析）

定义系统

• 系统名：软硬件以及业务流程都是系统，应该有名字
• 系统边界：确定哪些任务由系统完成，系统的边界在哪里，系统有什么功能，复杂程度怎么样

系统定义应该明确基本功能，语言准确，描述准确，架构优良

找出执行者

• 主要角色与次要角色
• 主动执行者与被动执行者

执行者与系统之间的交流是通过信息的收发。执行者主要是业务的客户。执行者是类，所以可以用类名及其属性和行为来描述一个执行者，必要的时候添加注释来说明。

找出用例并描述用例

• 确定各参与者所希望的系统行为

• 命名用例，确定用例之间的关系
• 绘制用例图，编写用例说明
• 对异常流程确定单独用例
• 优化用例图，解决冲突和重复

用例要有路径，路径要有执行者

• Previous
  需求分析概述
• Next
  系统设计