软件工程五-领域分析——2.用例图和活动图

图 分支的表示

5. 分岔与汇合 在实际应用中，如果活动的转换是有条件的，我们就用分支与监护条 件来表示转换，如果一些活动是并发执行的，我们就用分岔和汇合来 表示并发活动。分岔线和汇合线都使用加粗的水平线或垂直线段表示。
分岔线 汇合线
图 分岔与汇合的表示




（1）分岔：每个分叉可以有一个输入转换和两个或多个输出 转换，每个转换都可以是独立的控制流。 （2）汇合：当两个或多个并发控制流都达到汇合点后，活动 流程才能进入下一个活动节点． 分岔用来表示两个或者多个并发活动的分支；而汇合则用于同 步这些并发活动的分支，当且仅当所有的并发分支(活动)都到 达汇合点后，活动流程才能进入下一个活动节点。 按照活动图表示的信息不同，将活动图分为：简单活动图、标 识泳道的活动图、标识对象流的活动图、复合活动图。

四种关系的UML图释
<<include>>
包含关系
用例2
用例1
<<extend>>
扩展关系
用例2
用例1
泛化关系
用例1 用例2
关联关系
参与者 用例1
泛化：同一业务目的的不同技术实现 包含：提取公共交互，提高复用 扩展：“冻结”基用例以保持稳定
*通过关系提高用例复用
当多个用例共同拥有一种类似的结构和行为的时 候 我们可以将它们的共性抽象成为父用例，其他的用 例 作为泛化关系中的子用例。
需求
分析和设计
实现
测试
Use Cases 把所有这些过程绑到一起

用例（Use Case） 参与者（Actor） 关系(Relationship)



参与者：在系统之外，透过系统边界与系统进行有 意义交互的任何事物。 参与者可能是人、另外一个系统、时间的流逝等。 UML中，参与者用“人形”图标来表示，名字写 在图标的下方。
•
分叉和汇合（表示并发 和同步）
NewSwimlane
•
Fra Baidu bibliotek
泳道
在系统建模过程中，活动图能够被附加到任何建模元素， 以描述其行为，这些元素包括用例、类、接口、组件、节 点、协作、操作和方法。 在建模过程中，读者可以参照以下步骤进行： （1）识别要对其工作流进行描述的类； （2）对动态状态建模； （3）对动作流建模； （4）对对象流建模； （5）对建模结果进行精化和细化。
泛化举例（一）：
泛化举例（二）：
包含是指基本用例(base use case)会用到包含用例 (inclusion)，具体地讲，就是将包含用例的事件流 插入到基础用例的事件流中。包含用例是可重用的 用例──多个用例的公共用例。
包含举例（一）：
包含举例（二）：
将扩展用例的事件流在一定的条件下按照相应的扩展点 插入到基础用例中。
Email客户端（如： outlook express），A 在北京发邮件给深圳的 B，系统提醒B”你有新邮 件”，B收邮件。
一个论坛类的应用， 用户可以提问，别人 来回答，如果有自己 问题被解答的话，就 给发问者发一份邮件 通知。 注意：发邮件这个用例 可以是单独的用例， 也可以是由回答用例 扩展出来的用例
图 初始节点和终点
图 活动节点的表示

下图列出的就是一些可能的活动节点描述，可能用文字描 述活动节点，可能用表达式描述活动节点，可能用消息描 述活动节点。
图 活动节点

3. 转换 当一个活动结束时，活动控制流就会马上传递给下一个活 动节点，在活动图中称之为“转换”，用一条带箭头的直 线来表示转换．下面的直线箭头就表示了一个转换。
我们的进度，在这里

根据以上访谈内容，我们识别出 参与者——图书馆工作人员 用例——图书管理、借阅管理和图书的借阅/归还 在Rational Rose中建模。 打开模型：图书管理系统 在UseCase中新建一个包，命名为“领域分析”， 在其中创建一个用例图（UseCase Diagram，命 名为：业务用例图
我们的进度，在这里

1 2 3 4
什么是活动图 活动图的用途 活动图的组成元素 活动图的建模技术

活动图是UML中描述系统动态行为的图之一，是描 述系统或业务的一序列活动构成的控制流，它描述 了系统从一种活动转换到另一种活动的整个过程。

活动图用于对系统的动态行为建模。 活动图常用来描述业务或软件系统的活动轨迹，描 述了系统的活动控制流程。我们常用活动图对业务 过程、工作流和用例实现进行建模。
我们的进度，在这里
我们的进度，在这里
1. 2.
根据访谈内容，进行业务用例建模 根据访谈内容，进行业务流程的建模
提交内容
1. 业务用例图 2. 业务流程活动图
我们的进度，在这里
我们的进度，在这里

什么是用例图（Use Case Diagram） 用例图的应用 用例图的组成 参与者、用例的识别 用例建模技术
自动售货机系统 买饮料 供货 供货人 取货款 收银员 自动售货系统 收银员 供货人 顾客 售货 <<扩展>> 售散装 饮料 打开机器 关闭机器 打开机器 关闭机器
客户
<<包含>> 供货 <<包含>> <<包含>> 取货款 <<包含>>
我们的进度，在这里
1. 2.
现在我们要对图书管理系统进行业务用例建模。 在上次进行的访谈中，我们得知： 该系统只有一种使用者：图书馆工作人员，并且 同一时刻只有一个工作人员使用该系统。 图书馆工作人员，日常的业务主要有：图书管理， 借阅证管理和图书的借阅/归还。
登记借阅信 息
对号入座
发试卷
开始答题
交试卷
收试卷
结束


为了有效地表示各个活动由谁负责的信息，可以通过泳道 (Swim Lane)来实现。 每个泳道用一条垂直的线将它们分开，并且每个泳道都必 须有一个唯一的名称，例如本例中的监考教师和考生。从 图中可以看出，每个活动节点，分支必须只属于一个泳道， 而转换，分岔与汇合是可以跨泳道的。通过泳道，不仅体 现了整个活动控制流，还体现出了每个活动的实施者。


下面分别描述活动图中的元素的语义和表示法。 1. 初始节点和终点 初始节点表示活动的起点；终点表示活动的终结点．用一个实心圆表 示初始节点，用一个圆圈内加一个实心圆来表示活动终点．在活动图 中，可能包含多个活动终点。

2. 活动节点 活动节点是活动图中最主要的元素之一，它用来表示一个活动，一个 活动表示多个动作的集合。活动节点用一个圆角矩形表示．活动的名 称写在圆角矩形内部，活动节点的表示方法，如图所示。
在UML中，一个用例模型由若干个用例图(use case diagram)描述。用例图是显示一组用例、 参与者以及它们之间关系的图。



用例图是从用户的角度来描述对软件产品的需求， 分析产品的功能和行为，因此，对整个软件开发过 程而言，用例图是至关重要的。 用例图定义和描述了系统的外部可见行为，是分析、 设计直至组装测试的重要依据。 让用户参与前期的系统分析与设计。
定义 系统
确定执行 者和用例
描述执行者 和用例关系
确认 模型
●确定系
●执行者通常是使
统范围； ●分析系 统功能。
用系统功能的外部 用户或系统。 ●用例是一个子系 统或系统的一个独 立、完整功能。
各模型元素 之间有：关 联、使用、 扩展及泛化 等关系。
确认用例模型 与用户需求的 一致性，通常 由用户与开发 者共同完成。

活动图主要应用对两个方面建模：一是在业务分 析阶段，对工作流程进行建模；二是在系统分析 和设计阶段，对操作流程进行建模。

动作状态
动作流
得到图书
活动图的元素包括 初始节点、终点、 活动节点、转换、 分支、分岔与汇合。 其中，转换、分支、 分岔与汇合把多个 活动节点连接在一 起。
•
•
分支（判定条件）




1. 泛化关系（Generalization）：一个用例可以被特别 列举为一个或多个子用例，这被称为用例泛化： 2. 包含关系（Include）一个用例可以简单地包含其他用 例具有的行为，并把它所包含的用例行为作为自身行为的 一部分，这被称作包含关系。 3. 扩展关系（Extend）：一个用例也可以被定义为基础 用例的增量扩展，这称作扩展关系，扩展关系是把新行为 插入到已有用例的方法。 4.关联关系：关联关系表示参与者与用例之间的通信。
参与者

• •
用例（use case）一个用例是用户与计算机之间的一 次典型交互作用。在UML中,用例被定义成系统执行的 一系列动作（功能） 。 参与者和用例分别描述了“谁来做？”和“做什么？” 这两个问题。 每个用例都必须有一个惟一的名字以区别于其他用例。 用例用一个椭圆来表示，用例的名字可以书写在椭圆的内 部或下方。用例的UML图标如图所示。

用一个活动图表示一下考试的过程。 思考一下： 你们每次参加考试的过程是怎么样的？
1. 2. 3. 4. 5. 6. 7. 8. 9.
开始 学生进入考场。 监考教师核对检查证件。 学生对号入座。 监考教师发试卷 学生开始答题。 学生交卷。 监考教师收取试卷。 结束
开始 进入考场
核对证件
例：图书管理系统的参与者：
Ø借阅者（Borrower） Ø图书管理员（Librarian）

参与者之间也可以象类一样存在泛化或者依赖关系。
用例A 雇员 用例B
经理
用例C
如系统中经理可以参加雇员的所有用例
①参与者希望系统提供什么功能； ②系统是否存储和检索信息；如果是，这个行为由哪个参 与者触发； ③当系统改变状态时，是否通知参与者； ④是否存在影响系统的外部事件，是哪个参与者通知系统 这些外部事件。
我们的进度，在这里
借阅管理
图书管理
图书馆工作员 图书借阅
图书归还
注意：这个用例图是从用户业务的视角出发，用来进行业务用例建模的。 在今后的需求分析阶段，我们会从系统的视角来进行系统用例建模。
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
我们的进度，在这里
我们的进度，在这里


通过UML中的活动图，可以帮助我们进行用户 业务流程建模，帮助我们站在用户的视角上进行 业务分析。 在业务流程建模中，我们关注的是用户进行某项 业务的执行步骤。
◦ 基础用例不必知道扩展用例的任何细节，它仅为其提供扩 展点。 ◦ 扩展用例的行为是否被执行要取决于主事件流中的判定点。
扩展举例（一）：
扩展举例（二）：

包含用例与扩展用例的区别
①相对于基础用例，扩展用例是可选的，而包含用例则不是。 ②如果缺少扩展用例，基础用例还是完整的，而缺少包含用 例，则基础用例就不完整了。 ③扩展用例的执行需要满足某种条件，而包含用例不需要。 ④扩展用例的执行会改变基础用例的行为，而包含用例不会。
客户给销售员发来传真订货， 销售员下班前将当日 订货单汇总输入系统。 谁是系统的Actor？ 答案： 销售员
商品销售系统。顾客通过网络下单之后，系统计算 出总计金额，税金，运费，并将数目传递给一个外 挂的会计系统，该系统是另外购买的。 有几个Actor？
答案： 顾客(商品销售系统)， 商品销售系统(会计系统)
图 转换的表示


4. 分支与监护条件 在实际应用中，有三种活动控制流，它们是顺序结构、分支结构、循 环结构．当从一个活动节点到另一个活动节点的转换需要条件时，常 用分支与监护条件来表示活动的分支结构． 分支是用菱形表示的，它有一个进入转换（箭头从外指向分支符号）， 一个或多个离开转换（箭头从分支符号指向外）。而每个离开转换上 都会有一个监护条件，用来表示满足某种条件时才执行该转换。分支 的表示法，如图所示。

识别参与者 识别用例 识别用例间的关系 用例阐述

谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件
我们的进度，在这里
监考教师
学生
开始
进入考场
核对证件 对号入座
发试卷
开始答题
交试卷 收试卷
结束
我们的进度，在这里
1. 2. 3.
根据访谈分析业务流程 1.借书流程 图书管理员得到学生出示的借书证 图书管理员得到学生递给他的书 进行借书信息登记
我们的进度，在这里
图书借阅开始
得到借阅证
得到图书信 息