上一篇：UML（第二章：可视化建模实践概念知识）

前言

使用的ea环境：

---

一.用例建模相关理论知识

适合用例建模的情况：

• 系统由功能需求所主导
• 系统具有很多类型的用户，系统对他们提供不同的功能
• 系统具有很多接口

不适合：

• 系统有非功能需求所主导
• 系统具有很少的用户
• 系统具有很少的接口

1.1 获取原始需求

非功能性需求（Robert Grady软件质量准则“FURPS”）：

• 功能性（Functionality）
• 使用性（Usability）
• 可靠性（Reliability）
• 性能（Performance）
• 可支持性（Supportability）

1.2 开发一个可以理解的需求

1.2.1 识别参与者

1.2.1.1参与者定义（Actor）

在系统之外，透过系统边界与系统进行有意义交互的任何事物

1.2.1.2 参与者要点

• 参与者可以是系统外的，代表在系统边界之外的真实事务，并不是系统的成分
• 参与者可以是系统边界，表示参与者透过系统边界直接与系统交互，此时参与者的确定代表着系统边界的确定
• 参与者必须具备有意义的交互
• 参与者的类型可以是人、外系统、外部因素、时间等

1.2.1.3 参与者的名字

对参与者赋予能更好地表达其角色（作用）的名称，避免使用个人姓名。

1.2.1.4 参与者的泛化

• 同种类的用例之间可以进行通信。（例如下图中，经历可以参加雇员的所有用例）
  

• 没有实际意义的参与者，不允许访问任何用例（例如下图中的用户actor没有具体指向性）
  

1.2.2 识别用例

1.2.2.1用例定义

用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值。

1.2.2.2用例要点

• 可观测性：用例止于系统边界，这意味着用例重点在于描述交互行为，而不显示内在的系统活动

• 结果值：用例必须是有意义的目标

• 系统执行：结果值由系统生成

• 使用的语言是相应场景条件下的业务语言（用户词汇），且应该站在用户的观点。
  

• 一组用例实例即为用例的粒度

1.2.2.3用例的命名

1. 执行者视角：（状语）动词+（定语+）宾语
   

1.2.2.4用例粒度

需要注意的是下面两个问题：

• 步骤当用例（这样主要是会使得过于详细，不具有简洁性，在大型用例集合中选用优先级不高）
  

• 系统活动当用例（同上太详细了，不应该划分为用例，只用在用例对应的事件流中进行说明就行了）
  
  对于用例粒度的理解最好把握一个原则：当前用例独立而完整。
  下图中include“打印借书证”用例是一个正确的用法。
  这是因为办证和补证本身互相独立，但他们都包含了“打印借书证”这一公共部分，此时将多个用例的公共部分细化为一个新的用例就比上面单一化列出某一用例的include用例要好，它能够进一步表明办证和补证的独立性，也从逻辑上说明了用例的完整性，比如只要打印借书证功能正常，补证可以不考虑办证的情况而正常办理。
  

1.3 分析问题（描述需求）

1.3.1用例规约文档

用例图是框架，用例规约文档就是其内在的补充。

1.3.2用例规约组成

• 用例名称
• 用例标识
• 涉及的参与者
• 描述
• 用例的规格说明
  • 前置条件（PreConditions）：约束在用例开始前系统的状态
  • 后置条件（PostConditions）：约束用例执行后系统的状态
  • 正常事件流（Flow of events）
  • 备选事件流（Alternate flow）

1.3.3事件流描述要点

事件流一般是可观测的、体现客户利益的文字。
事件流有两种类型：

1. 基本事件流
   一般用来描述没有任何错误发生的情况。
2. 备选事件流
   是对于基本事件流的补充，比如基本事件流出现分支或异常的情况。

1.3.4活动图在用例需求分析中的作用

活动图能够直观清晰的分析用例，了解动作与动作之间的依赖关系。一张完整的活动图是所有用例的集成图。同时用例能对整个系统的工作过程加以区分。

1.4 重构用例模型

1.4.1 用例关系

• 包含关系（Include）：基用例中复用被包含用例的行为；一般提取公共步骤，便于复用。
  

• 扩展关系（Extend）：通过扩展用例对基用例增加附加的行为，表示功能被扩展。一般扩展发生在要处理某些特殊情况时。
  

• 泛化关系（Generalization）：父与子的关系，派生用例继承泛化用例的行为并添加新行为。
  

1.4.2 用例分类

1.4.2.1开发周期

是围绕用例的需求来组织的，一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例。

用例分类原则： 高级别用例——对系统核心体系影响最大的用例。

1.4.2.2用例的分包

目的是为了让用例图能够更为清晰的表现出系统的业务逻辑关系和层次。对系统进行模块的分割。是为了应对庞大数量的用例。
常见的分包方式：

• 按参与者分包
• 按主题分包
• 按开发团队分包
• 按发布情况分包
  推荐顺序：主题>开发团队>发布情况>参与者
  我们可以看一个例子：
  
  分别进入不同的包我们可以查看详情：

二.理论实战：某学校网上选课系统

题目详情：
管理员通过学校网络课程管理系统，建立本学期要开设的各种课程，将课程信息发布到网上，并可以对课程进行改动和删除。
学生通过自己的计算机进入系统，可以浏览课程目录，查询课程详细信息，选择课程，网上支付课程费用。

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

2.2 确定各参与者所期望的系统行为

管理员	学生
建立课程	浏览课程目录
发布课程	查询课程信息
修改课程信息	选择课程
删除课程	网上付费

2.3给这些系统行为命名为用例

2.4 绘制用例图

2.5 编制用例叙述

在这里紧以管理员“建立课程”这一用例为例——

• 用例一：建立课程
• 参与者：管理员
• 事件流：
  ①管理员选择进入管理界面，用例开始
  ②系统提示输入管理员账号密码
  ③管理员输入密码
  ④系统检验密码
  A1:密码错误（表示备选事件流）
  ⑤进入管理界面，系统显示当前所建立的全部课程信息
  ⑥管理员选择建立课程，管理员输入新课程信息
  ⑦系统验证是都与已有课程冲突
  A2:有冲突（表示备选事件流）
  ⑧系统添加新课程，并提示添加成功
  ⑨系统回到管理主界面，显示所有课程，用例结束。

三.ea（Enterprise Architect）实战：图书馆的图书借阅

文件——新建项目——（在弹出的提示框中给相应的EAP项目文件）命名

在跳出的“模型向导”中选择”use case“模板，（如果模型向导没有跳出来，可以点击项目浏览器栏中的第一个小图标）：

然后我们可以看到在项目浏览器中出现了相应use case的模板（默认格式是两个包，一个是用户包，一个是基本事件流包，我们可以对默认包里的组件进行更改，也可以新建包弄自己的）
补充说明：
当前视图中“工具栏”可以通过点击视图上方的"<<"调出来（最好把当前项目浏览器——工具栏——视图界面工作界面进行保存，就不用每次开始都要重新调出来了。保存方法：窗口——保存工作区布局——命名——确定）
ea刚开始学的时候一定要自己多瞎点看看，大不了就点崩而已哈！

接下来我们先直接利用默认包分析一下当前案例：

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

emmmm解释一哈，当时写这个博客的时候也在写自己的uml作业叫某学校网上选课管理系统，导致我根目录的用例图名称起成“某学校网上选课系统”了，哭，但我真的懒得再截图了，将就一哈哈哈，反正其他内容没错，只是取名取错了…… 就当它叫“图书馆的图书借阅”吧

3.2 确定各参与者所期望的系统行为

管理员：

• 借书证管理：办证、补证、注销、证件查询
• 图书管理：查询、添加、修改、删除
• 借阅管理：书目查询、借书、还书、过期催还、丢失处理

借阅者：书目查询

3.3 把这些系统行为命名为用例

3.4 确定各用例之间的关系（泛化、包含、扩展）

3.5 绘制用例图

在这个流程过程中涉及用例较多，所以我们可以采用包的形式对业务逻辑进行分层与控制。包图的相关知识可以看我以前的总结。
显然这个例子中我们使用nesting关系。
在根目录里的用例图“某学校网上管理系统”进行绘制，使用的package组件会自动生成子包放在当前的“Use Case Model”根下

然后我们进入对应的子包“借书证管理”中绘制用例图：

然后我们进入对应的子包“图书管理”中绘制用例图：

然后我们进入对应的子包“借阅管理”中绘制用例图：

这个时候我们再返回根目录的“某学校网上选课系统”就可以看到相应的包信息已经自动填充上去啦！

当然上述任何一张你画好的图你想保存的话，就先选中你要保存的图片所在，鼠标点击菜单栏中的图片——保存图到文件。

3.6 编制用例叙述

• 用例：借书
• 参与者：管理员
• 操作流
  ①管理员进入图书借阅界面，用例开始
  ②系统要求输入借阅者的借书证编码
  ③系统检验借书证编码，如果正确，则显示借阅者的信息
  A1：借书证编码有错
  A2：如果该借阅者所借图书已经超期，则提示，本次拒借
  ④系统要求输入所借图书的条码
  ⑤系统显示所借图书的信息
  ⑥确认借书
  ⑦系统回到上一界面，等待处理下一次借书请求