uml05(第五章)
合集下载
UML面向对象分析、建模与设计课件第五章 类图
即可变、只增与冻结。
类——操作
操作是一个可以由类的对象请求以影响其行为的服务的实现，也即 是对一个对象所做的事情的抽象，并且由这个类的所有对象共享。
操作是类的行为特征或动态特征。 操作的语法格式为：
可见性OPT 操作名 ⌊(参数列表)⌋OPT ⌊:返回类型⌋OPT ⌊{特性}⌋OPT
操作名：操作的标识符。在描述操作时，操作名是必须的，其他部 分可选。
Student
+monitor 1
1..*
自关联
类图中的关系——关联关系
关联名称：放在关联路径的旁边，但远离关联端。 角色：放在靠近关联端的部分，表示该关联端连接的类在这一关联
关系中担任的角色。角色名上也可使用可见性修饰符号。 多重性：放在靠近关联端的部分，表示在关联关系中源端的一个对
象可以与目标类的多少个对象之间有关联。 导航性：一个布尔值，用来说明运行时刻是否可能穿越一个关联。 限定符：是二元关联上的属性组成的列表的插槽，其中的属性值用
/WorksForCompany
Department * +department 1 WorksForDepartment
* Person
类图中的关系——泛化关系
泛化关系定义为一个较普通的元素与一个较特殊的元素之间的类元 关系。其中描述一般的元素称为父，描述特殊的元素称为子。
通过泛化对应的继承机制使子类共享父类的属性和操作，小了模型 的规模，同时也防止了模型的更新所导致的定义不一致的意外。
法了，此时称之为N元关联。
类图中的关系——关联关系
class Logical View
ClassA
AssociationName
+rolename 0..*
类——操作
操作是一个可以由类的对象请求以影响其行为的服务的实现，也即 是对一个对象所做的事情的抽象，并且由这个类的所有对象共享。
操作是类的行为特征或动态特征。 操作的语法格式为：
可见性OPT 操作名 ⌊(参数列表)⌋OPT ⌊:返回类型⌋OPT ⌊{特性}⌋OPT
操作名：操作的标识符。在描述操作时，操作名是必须的，其他部 分可选。
Student
+monitor 1
1..*
自关联
类图中的关系——关联关系
关联名称：放在关联路径的旁边，但远离关联端。 角色：放在靠近关联端的部分，表示该关联端连接的类在这一关联
关系中担任的角色。角色名上也可使用可见性修饰符号。 多重性：放在靠近关联端的部分，表示在关联关系中源端的一个对
象可以与目标类的多少个对象之间有关联。 导航性：一个布尔值，用来说明运行时刻是否可能穿越一个关联。 限定符：是二元关联上的属性组成的列表的插槽，其中的属性值用
/WorksForCompany
Department * +department 1 WorksForDepartment
* Person
类图中的关系——泛化关系
泛化关系定义为一个较普通的元素与一个较特殊的元素之间的类元 关系。其中描述一般的元素称为父，描述特殊的元素称为子。
通过泛化对应的继承机制使子类共享父类的属性和操作，小了模型 的规模，同时也防止了模型的更新所导致的定义不一致的意外。
法了，此时称之为N元关联。
类图中的关系——关联关系
class Logical View
ClassA
AssociationName
+rolename 0..*
UML第5章
5.2.1 对象类的关联 在对象类图上， 在对象类图上，关联用一条把对象类连接在 一起的实线表示。 一起的实线表示。一个关联至少有两个关联 每个关联端连接到一个类， 端，每个关联端连接到一个类，关联端是有 序的。 序的。 关联线旁可以标出关联的名字。 关联线旁可以标出关联的名字。线旁的小实 心三角箭头表示关联的方向， 心三角箭头表示关联的方向，从源对象类指 向目标对象类。箭头起关联的导航作用。 向目标对象类。箭头起关联的导航作用。
第5章 对象类图与对象图 章
5.1 5.2 5.3 5.4 5.5
对象类图 对象类的关联 聚合与组合 泛化 依赖
5.6 5.7 5.8 5.9
对象图 接口与端口 对象类的高级概念 对象类图的应用
Home
5.1 对象类图 对象类（Class）简称类， 对象类（Class）简称类，是面向对象模型 的最基本的模型元素。 的最基本的模型元素。对象类图表达一组对 象类和它们的联系。 象类和它们的联系。 在对象类图中， 在对象类图中，一方面描述各个对象类本 身的组成，即类的属性、 身的组成，即类的属性、操作和对对象的约 束；另一方面描述系统中对象类之间的各种 静态的联系。 静态的联系。 对象类图描述的是系统的静态结构。 对象类图描述的是系统的静态结构。 对象类的结构性联系：关联、聚合、组合、 对象类的结构性联系：关联、聚合、组合、 泛化/特化。 泛化/特化。
5.1.3 操作 操作是对象类的行为特征或动态特征。 操作是对象类的行为特征或动态特征。 一个类可以有多个操作， 一个类可以有多个操作，也可以没有一个操 作。没有一个操作的类常用于表达接口或数 据表。 据表。 操作用文字串说明，如图5.4所示。 5.4所示 操作用文字串说明，如图5.4所示。 操作有在本对象类中唯一的操作名或标识符。 操作有在本对象类中唯一的操作名或标识符。 参数列表是可选项目， 参数列表是可选项目，即一个操作可以有参 也可以没有参数。 数，也可以没有参数。 操作 参数列表） 可视性 操作名 （参数列表）：返回列表 {性质} 性质}
第五章 包图
• •
构造性
<<system>>
<<subsystem>>
说明
表示正在建模的整个系统
表示正在建模的系统中某个独立的部分。 对于较大的系统，经常需要将其划分为几个独 立的子系统，每个子系统从较低的抽象层次观 察的时候就像一个较小的系统
<<facade>> <<stub>>
描述一个只引用其他包内元素的包，主要 用来为其他一些复杂的包提供简略视图 一个代理包，通常应用于分布式系统的建 模中，它服务于某个其他包的公共内容
总结：
本章介绍了UML包图，应用包图的目的是为了简化图， 通常当一个图变得庞大且在单一页中无法打印的时候引入 包。 • 包图中可以包含任何一种UML图，但通常更多的是用例 图或类图； • 创建用例包图，可以帮助组织需求，对需求进行高层次 的概述； • 创建类包图，可以在逻辑上组织类，对设计进行高层次 的概述。
在Rational Rose 中，支持4种包的构造型，如图5-6～
5-9。
5.2.4 子系统
•
系统是组织起来以完成一定目的的连结单元的集合，由 一个高级子系统建模，该子系统间接包含共同完成现实世 界目的的模型元素的集合。 子系统是指有单独说明和实现部分的包。它表示具有 对系统其他部分存在接口的连贯模型单元。 子系统使用具有构造型关键字subsystem的包表示，如 下图所示。
包的依赖性可以加上许多构造型规定它的语义，其中最 常见的是引入依赖。引入依赖（Import Dependency）是包与 包之间的一种存取依赖关系。 • 引入是指允许一个包中的元素存取另一个包中的元素， 引入依赖是单向的。引入依赖的表示方法是在虚箭线上标有构 造型Inport，箭头从引入方的包指向输出方的包。 • 如图所示
第五章 类图和对象图(UML)
＋
size
:integer
=(100)
9
第 五 章 类 图 和 对 象 图
５.１ 类的定义
说明：
３、属性还有取值范围。类型表示该属性的种类。 它可以是基本数据类型,例如整数、实数、布尔 型和枚举型等,也可以是用户自定义的类型。一 般它由所涉及的程序设计语言确定必须为其指定 数据类型。当一个类的属性被完整定义后，它的 任何一个对象的状态都由这些属性的特性值所决 定。
20
第 五 章 类 图 和 对 象 图
５.２ 类之间的关系
1、关联
关联是一种结构关系，它指明一个事物的对象与 另一个事物的对象间的联系 例如,一个人为一家公司工作,一家公司有许多办 公室。我们就认为人和公司、公司和办公室之间 存在某种语义上的联系。在分析设计的类图模型 中,则在对应人类和公司类、公司类和办公室类 之间建立关联关系
改变的因素：１.一个类向另一个类发送消息。 ２.一个类是另一个类的数据成员类型 ３.一个类是另一个类的操作的参数类型 注：如果两个类之间有关联，那么这两个类就有依赖关 系，但是我们一般不标出依赖关系。
37
第 五 章 类 图 和 对 象 图
５.２ 类之间的关系
３、泛化（generalization）关系
泛化关系：定义了一般元素和特殊元素之间的分类关系。 也就是一种继承关系。继承是在现有类的基础上定义和 实现一个新类的技术，刻画了类的一般性和特殊性。被 继承的类称为父类或超类，继承的类称为子类。 表示形式：用空心三角箭头实心线表示
25
第 五 章 类 图 和 对 象 图
５.２ 类之间的关系
1、关联
角色：当一个类处于关联的某一端时，该类就在 这个关系中扮演着一个特定的角色。角色就是关 联关系中一个类对另一个类所表现的职责
面向对象与UML 第五章 序列图和通信图
5.3 建立序列图
3. 添加消息
按发生的顺序在对象之间添加交互消息。
– 客户通过发送创建消息EntryDialogue打开登录对话 框
– 客户通过发送inputUserInfo消息向登录对话框中输 入用户信息
– 登录对话框通过发送sendUserInfo消息将用户信息发 往服务器
5.3 建立序列图
server:Server
database:DataBase
e n tryDi a l o g :En tryDi a l o g En tryDi a l o g ()
«create»
i n p u tUse rIn fo ()
sendUserInfo()
i n p u tUse rIn fo ()
5.3 建立序列图
1. 确定事件流
“用户登录”的异常流： 用户输入的信息与数据库中存储的信息不匹配，数据库 验证不通过，弹出错误信息。
5.3 建立序列图
2. 布置对象
基本流中的对象主要有客户(client)、数据库(database)、 服务器(server)、登录对话框(entryDialogue)、好友 列表(friendList)
– 服务器再把该用户信息发往数据库进行身份验证， 若合法，返回消息允许用户登录，同时服务器通过 向自身发送updateList消息更新在线用户列表
– 服务器通过创建消息FriendList创建该用户好友列表 – 通过消息getOfflineMessage向数据库请求其他好友向
该用户发送的离线
5.3 建立序列图
3. 添加消息
按发生的顺序在对象之间添加交互消息。
– 客户通过发送创建消息EntryDialogue打开登录对话框
uml课后习题答案
uml课后习题答案第一章系统建模与分析设计的演变课后习题：1、A2、C3、D4、B5、软件按照其工作方式可划分为实时处理软件、分时处理软件、交互式软件和批处理软件。
6、软件生存周期由软件的定义、软件的开发和软件的使用维护和更新换代三部分组成。
7、软件开发模型有瀑布模型、增量模型、螺旋模型、智能模型和快速原型模型等五种主要模型8、面向对象技术采用以类为中心的封装、继承、多态等不仅支持软件复用，而且使软件维护工作可靠有效，可实现软件系统的柔性制造。
9、UML的优点是：唯一性、连续性、维护性、复用性和完善性。
第二章统一建模语言UML1、A2、B3、C4、D5、B6、UML分析和设计模型由三类模型图表示，三类模型图是：用例模型图、静态模型图和动态模型图。
7、UML的软件统一开发过程，即生命周期按时间顺序可以划分为，开始，详细设计，系统构造和移交四个阶段及阶段中一系列的循环重复。
8、UML开发过程是一种二维结构软件开发过程，软件项目开发过程流程包括的核心工作内容是，分析，设计，实现，测试和配置9、UML中的五个不同的视图可以完整地描述出所建造的系统，这五种视图是用例视图、逻辑视图、构件视图、进程视图和配置视图。
10、UML中有10中基本图可以完整地描述出所有建造的系统，这10中视图是用例图、类图、对象图、包图、构件图、配置图、序列图、活动图、状态图和合作图。
第三章需求分析与用例建模习题：1、B2、A3、C4、D5、B6、A7、A8、UML软件开发过程需求分析阶段产生的模型由三类模型图表示。
他们是：用例模型图、静态模型图和动态模型图。
9、CRC卡中的描述由类名、类特征、类类型、责任和协作者共五部分组成10、软件项目的目的的可行性研究分析中，技术可行性研究包括风险分析、资源分析、技术分析三部分组成11、在UML软件开发过程的需求分析阶段，建立用例模型的步骤分为，确定系统的范围和边界，确定系统的执行者和用例，对用例进行描述，定义用例之间的关系和审核用例模型。
课件—UML系统建模与分析设计(5)
第五章
系统设计与对象动态交互模型
动态模型主要描述系统的动态行为和控制结构。动态行 为包括系统中对象生存期内可能的状态以及事件发生时状态 的转移，对象之间动态合作关系，显示对象之间的交互过程 以及交互顺序，同时描述了为满足用例要求所进行的活动以 及活动间的约束关系。 在动态模型中,对象间的交互是通过对象间消息的传递来 完成的。对象通过相互间的通信(消息传递)进行合作,并在其 生命周期中根据通信的结果不断改变自身的状态。
16
5.2.1 一个简单的顺序图例子
17
顺序图有两个坐标： 垂直坐标--时间（从上到下），水平坐标—对象。
对象
生存线
时间
18
激活期
消息
顺序图和用例图、类图的关系
19
5.2.2顺序图的主要元素：
（1）对象：顺序图中所包含的每个对象用一个 对象框（短式）表示，对象名需带下划线。
对象图
（2）生存线：对象框下画的一条垂直虚线，称 为该对象的生存线，表示对象的生存时间。 （3）激活期：对象生存线上的一个细长方形框， 表示该对象的激活时间段，即活动期间。一 个激活的对象要么正在执行自己的代码，要 么等待另一个对象的返回。 （4）消息：对象之间消息的发送和接收用两个 对象生存线（激活期）之间的消息箭头线。
28
5.3
对象之间的同步与异步操作
1．对象之间的同步操作
同步消息的发送者把进程控制传递给消息 的接收者，然后暂停活动，等待消息的接收者 放弃或返回控制； 同步消息的接收者执行所请求的操作，如 果需要的话，可以把控制传递给另一个对象角 色，请求做某个操作，并且当该操作完成后把 控制返回给原来的同步消息的发送者； 同步消息的接收者也可以直接返回或发送 信息给原来的消息发送者。
系统设计与对象动态交互模型
动态模型主要描述系统的动态行为和控制结构。动态行 为包括系统中对象生存期内可能的状态以及事件发生时状态 的转移，对象之间动态合作关系，显示对象之间的交互过程 以及交互顺序，同时描述了为满足用例要求所进行的活动以 及活动间的约束关系。 在动态模型中,对象间的交互是通过对象间消息的传递来 完成的。对象通过相互间的通信(消息传递)进行合作,并在其 生命周期中根据通信的结果不断改变自身的状态。
16
5.2.1 一个简单的顺序图例子
17
顺序图有两个坐标： 垂直坐标--时间（从上到下），水平坐标—对象。
对象
生存线
时间
18
激活期
消息
顺序图和用例图、类图的关系
19
5.2.2顺序图的主要元素：
（1）对象：顺序图中所包含的每个对象用一个 对象框（短式）表示，对象名需带下划线。
对象图
（2）生存线：对象框下画的一条垂直虚线，称 为该对象的生存线，表示对象的生存时间。 （3）激活期：对象生存线上的一个细长方形框， 表示该对象的激活时间段，即活动期间。一 个激活的对象要么正在执行自己的代码，要 么等待另一个对象的返回。 （4）消息：对象之间消息的发送和接收用两个 对象生存线（激活期）之间的消息箭头线。
28
5.3
对象之间的同步与异步操作
1．对象之间的同步操作
同步消息的发送者把进程控制传递给消息 的接收者，然后暂停活动，等待消息的接收者 放弃或返回控制； 同步消息的接收者执行所请求的操作，如 果需要的话，可以把控制传递给另一个对象角 色，请求做某个操作，并且当该操作完成后把 控制返回给原来的同步消息的发送者； 同步消息的接收者也可以直接返回或发送 信息给原来的消息发送者。
tanhuobin_uml05[1].Use-Case+Analysis
![tanhuobin_uml05[1].Use-Case+Analysis](https://img.taocdn.com/s3/m/3ed4572c0066f5335a81210a.png)
行为都是由相应的类来完成的 因此这些行为必须被分配到类中
分析阶段就是对这个过程的第一次尝试 这是一个从“无”到“有”的跨越
用例分析：对于每个用例实现
查找分析类
为分析类分配职责
构造参与类类图
-38-
分析类：达成目标的第一步
用例分析
-39-
什么是分析类
分析类代表了“系统中必须具备职责
用例分析流程
-20-
构架分析
构架分析的过程就是定义系统高层组
织结构和核心构架机制的过程
1.定义系统高层组织结构—备选构架
2.确定系统通用构架机制—分析机制
-21-
1.定义备选构架
RUP中的“定义备选构架”
创建系统
构架的初始草图 初步定义一组在构架方面具有重要意义的元素，
层之间建立依赖关系
-28-
2.构架机制
构架机制是对通用问题的决策、方针
和实践
构架机制描述了针对一个经常发生的问
题的一种通用解决方案 作为系统构架的一部分，构架机制常常 集中和定位在系统的非功能需求上
三类构架机制
分析机制（概念） 设计机制（具体） 实现机制（实际）
-29-
为什么使用分析机制
删除多余候选 删除不清楚的候选 删除执行者(系统外) 删除实现构造 删除属性 删除操作
-47-
示例：候选实体类
“学生选课”用例基本路径中的候选
实体类
-48-
示例：总结：分析类
-49-
总结：从用例中查找分析类
-50-
实例-旅店预订系统中查找分析类
-51-
2.2将用例行为分配给类
-26-
MVC备选构架示意图B-C-E
uml课件第五章
4
视
互动视（Interaction View） 互动视描述了系统不同部分之间的控制流，包括可能的并发 和同步机制。它体现了系统的性能、可扩展性、和总处理能 力。 静态方面：类图、对象图捕捉； 动态方面：互动图、状态机图、活动图捕捉。 实现视（Implementation View） 实现视包括用于组装、发布物理软件系统所需的各种产物， 主要描述了软件系统版本的配置管理。 静态方面：组件图捕捉； 动态方面：互动图、状态机图、活动图捕捉。
14
(4) 组合结构图(Composite Structure Diagram) 组合结构图是UML 2.0中新增的图，UML 1.x中没有。 组合结构图描述了分类器(如类、组件或用例)的内部结构， 包括分类器与系统其他部分的交互作用点。
10
UML的图
(5) 用例图(Use Case Diagram) 用例图描述了用例、参与者以及它们之间的关系。 用例图描述了系统的静态用例视。在分析系统行为并为之 建模时，用例图的使用尤其重要。 (6) 顺序图(Sequence Diagram) (7) 通信图(Communication Diagram) 在UML中，顺序图和通信图统称为互动图。
12
的图
统一建模语言UML是用来对软件系统的产物进行可视化、规范定义、构 造并为之建立文档的建模语言。 UML的13种图如下：
（1）类图（Class Diagram） （2）对象图（Object Diagram） （3）组件图（Component Diagram） （4）组合结构图（Composite Structure Diagram） （5）用例图（Use Case Diagram） （6）顺序图（Sequence Diagram） （7）通信图（Communication Diagram） （8）状态机图（State Machine Diagram） （9）活动图（Activity Diagram） （10）部署图（Deployment Diagram） （11）包图（Package Diagrams） （12）定时图（Timing Diagram） （13）交互概览图（Interaction Overview Diagram）
UML-5UML的关系、符号、视图与图
Home
UML的符号
Home
分类符图标示例
图3.10 联系图标示例
UML的符号
消息、状态和活动图标示例
Home
注释图标示例
模型元素与通用机制
模型元素指模型中的实体以及实体间相互连接的关系
类 属性 操作
用况
主动类 属性 操作
结点
对象：类 属性 操作
状态
包 关联 依赖
注解
泛化 实现
部分模型元素
文件
保险 公司
* 保险 * 合同
*
人
公司
保险 公司
* 保险 * 合同 * {xor}
人
公司
1..*
成员
1
政治家
{subset}
党派
1
党派领袖
1
关联的约束关系
雇主 公司
0..1
雇员 *
老板 员 工 0..1
* 工人
｛self.employer= self.boss.employer｝
Article
关联也可以被派生或约束
公司 employer 1
1
*
employer
* /worksForCompany
部门 1 department
* worksForDepartment 人
{ person.employer=person.department.employer }
6)模板（Templates）
Cost-price Sales-price /profit
{profit = Sales-price - Cost-price }
Invoice
+ amount : Real + date : Date = Current date + customer : String + specification : String - administrator : String=“unspecified” - number of invoices : Integer + status : Status = unpaid {unpaid, paid}
UML的符号
Home
分类符图标示例
图3.10 联系图标示例
UML的符号
消息、状态和活动图标示例
Home
注释图标示例
模型元素与通用机制
模型元素指模型中的实体以及实体间相互连接的关系
类 属性 操作
用况
主动类 属性 操作
结点
对象：类 属性 操作
状态
包 关联 依赖
注解
泛化 实现
部分模型元素
文件
保险 公司
* 保险 * 合同
*
人
公司
保险 公司
* 保险 * 合同 * {xor}
人
公司
1..*
成员
1
政治家
{subset}
党派
1
党派领袖
1
关联的约束关系
雇主 公司
0..1
雇员 *
老板 员 工 0..1
* 工人
｛self.employer= self.boss.employer｝
Article
关联也可以被派生或约束
公司 employer 1
1
*
employer
* /worksForCompany
部门 1 department
* worksForDepartment 人
{ person.employer=person.department.employer }
6)模板（Templates）
Cost-price Sales-price /profit
{profit = Sales-price - Cost-price }
Invoice
+ amount : Real + date : Date = Current date + customer : String + specification : String - administrator : String=“unspecified” - number of invoices : Integer + status : Status = unpaid {unpaid, paid}
UMLchapter5
第5章 用例图
▪5.1 用例图的概念 ▪5.2 用例图建模技术 ▪5.6 实例——图书馆管理系统中的用例图
5.1.1 概述
▪ 用例图显示谁将是相关的用户、用户希望系统提 供什么服务以及用户需要为系统提供的服务。
▪ 用案图用来定义系统的功能需求，它描述若干参 与者与系统提供的用例之间的连接关系
▪ 用例图最常用来描述系统以及子系统。
▪ 如何识别用例。
用例: 识别方法
确定系统边界：系统的边界是软件和应用加上用 户还是硬件和应用加上用户？
识别主要参与者：找出那些通过调用系统所提供 的服务而实现了用户目标的参与者
识别用户目标：对每个主要参与者，识别出其用 户目标
定义满足用户目标的诸用例，并按照相应的用户 目标名来命名用例
12
5.1.1 概述
▪ 用例图包含6个元素： ① 参与者（Actor） ② 用例（Use Case） ③ 关联关系（Association） ④ 包含关系（Include） ⑤ 扩展关系（Extend） ⑥ 泛化关系（Generalization）
系统
系统： 系统是用例模型的一个组成部分，它表示一台机 器或一次商务活动等 用例图中的系统用一个长方框表示，系统的名字 写在方框上方或方框内部，方框内部还可以包含 该系统中的用符号表示的用例
的行为。 ③ 把这些公共的行为命名为用例。 ④ 确定提供者用例和扩展用例。 ⑤ 对这些用例、参与者和它们之间的关系建模。 ⑥ 用注释修饰用例。
项目 数据库
用例包含关系示例
19
扩展关系
▪ 扩展用例被定义为基础用例的增量扩展。 ▪ 基础用例提供扩展点以添加新的行为。 ▪ 扩展用例提供插入片段以插入到基础用例的扩展点上。 ▪ 基础用例不必知道扩展用例的任何细节 ▪ 一个用例有多个扩展点
▪5.1 用例图的概念 ▪5.2 用例图建模技术 ▪5.6 实例——图书馆管理系统中的用例图
5.1.1 概述
▪ 用例图显示谁将是相关的用户、用户希望系统提 供什么服务以及用户需要为系统提供的服务。
▪ 用案图用来定义系统的功能需求，它描述若干参 与者与系统提供的用例之间的连接关系
▪ 用例图最常用来描述系统以及子系统。
▪ 如何识别用例。
用例: 识别方法
确定系统边界：系统的边界是软件和应用加上用 户还是硬件和应用加上用户？
识别主要参与者：找出那些通过调用系统所提供 的服务而实现了用户目标的参与者
识别用户目标：对每个主要参与者，识别出其用 户目标
定义满足用户目标的诸用例，并按照相应的用户 目标名来命名用例
12
5.1.1 概述
▪ 用例图包含6个元素： ① 参与者（Actor） ② 用例（Use Case） ③ 关联关系（Association） ④ 包含关系（Include） ⑤ 扩展关系（Extend） ⑥ 泛化关系（Generalization）
系统
系统： 系统是用例模型的一个组成部分，它表示一台机 器或一次商务活动等 用例图中的系统用一个长方框表示，系统的名字 写在方框上方或方框内部，方框内部还可以包含 该系统中的用符号表示的用例
的行为。 ③ 把这些公共的行为命名为用例。 ④ 确定提供者用例和扩展用例。 ⑤ 对这些用例、参与者和它们之间的关系建模。 ⑥ 用注释修饰用例。
项目 数据库
用例包含关系示例
19
扩展关系
▪ 扩展用例被定义为基础用例的增量扩展。 ▪ 基础用例提供扩展点以添加新的行为。 ▪ 扩展用例提供插入片段以插入到基础用例的扩展点上。 ▪ 基础用例不必知道扩展用例的任何细节 ▪ 一个用例有多个扩展点
UML活动图
（2）重命名泳道：双击泳道标签，弹出如下窗口
（3）调整泳道的宽度：拖动泳道间的调整线
（4）删除泳道 方法1：右击泳道->delete
此删除操作产生的效果：
泳道被删除（非彻底删除，可恢复）
泳道内的图形也会同时被删除(非彻底删除，可恢复)
方法2：在浏览器中右击泳道->delete
此删除操作产生的效果：
2、汇合 用于将两个或多个控制流合并到一起形成一个单向控制流。
如果一个控制流在其他控制流到达之前到达了连接，它将 会等待，直到所有控制流都到达了才会向连接传递控制权。
分叉用来表示将一个控制流分成两个或者多个并发运行 的分支，结合用来表示并行分支在此得到同步。
练习：销售合同从签订到履约的过程 销售合同签订后，要进行核对。如果发现错误，则终止履 约；如果没有错误，则要核对货物清单确定是否有货，还 要核对付款单确定对方是否已经付款，只有这两项都完成， 才可以发货。如果无货或对方尚未付款，则终止履约。
描述“播放MP3”用例：
实例引入：活动图的作用
public class assistant { public int id; …… public int max(int score1, int score2, int score3) { int temp; temp = score1; if (score2 > temp) temp = score2; if (score3 > temp) temp = score3; return temp; } }
在活动图中泳道区分了负责活动的对象，它明确地表示了 哪些活动是由哪些对象进行的。 在包含泳道的活动图中每个活动只能明确地属于一个泳道
三、对象流 用活动图描述某个对象时，可以将涉及到的对象放到活 动图中，并用一个依赖将其连接到活动或状态上，对象 的这种使用方法就构成了对象流。
UML_TP05_用例图
扩展关系
• 扩展用例被定义为基础用例的增量扩展。 • 基础用例提供扩展点以添加新的行为。 • 扩展用例提供插入片段以插入到基础用例的扩展点上。
泛化关系
• 父用例也可以被特别列举为一个或多个子用例。 • 子用例表示父用例的特殊形式。 • 子用例从父用例处继承行为和属性，还可以添加行为 或覆盖、改变继承的行为。
5.2 用例图建模技术
• 5.2.1 对语境建模 • 5.2.2 对需求建模
5.2.1 对语境建模
① 识别系统外部的参与者。 ② 将类似参与者组织成泛化的结构层次。 ③ 在需要加深理解的地方，为每个参与者提供 一个构造型。 ④ 将参与者放入到用例图中，并说明参与者与 用例之间的通信路径。
5.2.2 对需求建模
5.1.1 概述
• 用例图包含3个元素：
– – – 参与者（Actor） 用例（Use Case） 关系
• • • • 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization）
5.1.2 参与者
• 系统外部的一个实体。 • 参与用例的执行过程。 • 通过向系统输入或请求系统输 入某些事件来触发系统的执行。 • 由参与用例时所担当的角色来 表示。 • 每个参与者可以参与一个或多 个用例。
– 参与者是系统外部的对象，注意系统的边界 – 确定时，先确定主要的参与者，再确定次要的参 与者，对于可有可无的参与者就可以忽略掉。 – 最好能用简短的文本来描述参与者。
参与者间的关系
• 在用例图中，使用泛化 关系来描述多个参与者 之间的公共行为。 • 参与者间的泛化关系示 例：
5.1.3 用例
• • • 处理书籍借阅 处理书籍归还 删除预定信息
第5章-系统建模.
Actor之间的关系
执行者可以详细的泛化其他执行者:
用例模型-执行者
获取执行者（角色）
谁使用系统的主要功能（主要使用者）？ 谁需要系统支持他们的日常工作？ 谁来维护、管理系统使其能正常工作（辅助使用 者）？ 系统需要控制哪些硬件？ 系统需要与其他哪些系统交互？ 对L统一建模语言
面向对象建模的标准建模语言。 活动图 用例图 时序图 类图 状态图
图形建模的用途
为讨论现有系统或提出新功能的系统提供 便利 论证现有系统 作为详细的系统描述，该描述可用来产生 系统实现
5.1 上下文模型
上下文模型用来描述一个系统的运行环境。 用它来界定系统的边界。 应该在过程的早期阶段完成这些判断，以 便限制系统成本以及分析系统需求和设计 中需要花费的时间。
5.2.1 用例模型
用例模型被用来支持需求导出。它是UML中 的模型图之一。 用例，参与者，关系
每一个用例表示一个具体的任务 参与者可能是人，也可能是其他系统
传输数据用例
A use case in the MHC-PMS
用例“传输数据”的表格描述
MHC-PMS: 传输数据 参与者 描述 分诊医生，病人记录系统 (PRS) 分诊医生会将数据从MHC-PMS系统传递给更通用的病人记录数据 库，该数据库由卫生主管部分维护。信息传递也许是更新个人信 息，也许是简短记录病人的诊断和诊治
UML是一种定义良好、易于表达、功能强大 且普遍适用的建模语言。它的作用域不限 于支持面向对象的分析与设计，还支持从 需求分析开始的软件开发的全过程。 在美国，截止1996年10月，UML获得了工业 界、科技界和应用界的广泛支持，已有700 多个公司表示支持采用UML作为建模语言。 1996年底，UML已稳占面向对象技术市场的 85%，成为可视化建模语言事实上的工业标 准。1997年11月17日，OMG采纳UML 1.1作 为基于面向对象技术的标准建模语言。
第05章面向对象分析
经过初步筛选后，剩下的类与对象有：
手表、按钮、显示屏、电池、时间。
2 按钮 1 简单手表 1 1 时间
1 显示屏
1
1 电池
1
图5-8 电子表元素的UML类图
三、定义属性和方法
问题域中的事物的特征可以区分为静态特征和动态特征， 静态特征可以通过一组数据来表示，而动态特征则可以通过一 系列操作来表达。面向对象方法用对象来抽象问题域中的事物， 相应的对象属性和服务则与事物的静态特征和动态特征相对应。
第5章
面向对象分析
教学目的、要求，重点、难点
目的要求：使学生了解面向对象的分析过程，需求 陈述的书写，掌握建立对象模型、动态模型、功能 模型方法和步骤。 教学重点：建立对象模型、动态模型、功能模型的 方法和步骤。 教学难点：建立对象模型、动态模型、功能模型的 方法和步骤 讲授内容：面向对象的分析过程，需求陈述的书写， 建立对象模型、动态模型、功能模型方法和步骤。
电子表
构造对象模型的第一 步是标出来自问题域的相 关对象类。对象包括物理 实体和概念，所有类在应 用中都必须有意义，在问 题陈述中，并非所有类都 是明显给出的。有些是隐 含在问题域或一般知识中 的。
读时间
设置时间 手表用户 更换电池 手表修理工 图5－6 电子表的UML用例图
二、发现对象的方法 类-&-对象是在问题域中客观存在的，系统分 析员的任务，就是通过分析找出这些类-&-对象。 1、找出侯选的类-&-对象 客观事物可以分为五类： 1）可感知的物理实体;（飞机，汽车，书…） 2）人或组织的角色;（医生，教师，雇主，计算机系） 3）应该记忆的事件;（飞行，演出，交通事故…） 4）两个或多个对象的相互作用，通常具有交易或接触 的性质;（购买，纳税，结婚…） 5）需要说明的概念;（政策，保险政策，版税法…） 在分析所面临的问题时，可以参照上述五类事物， 找出在当前问题域中的侯选类-&-对象。
UML第5章 包图
• （1）在包间移动类。 • （2）添加包、分解包、合并包或删除包。
5.6.3 消除包的循环依赖
•应该尽量避免包模型中的循环依赖。 •如果包A以某种方式依赖包B，并且包B以某种方式依赖包A， 就应该合并这两个包，这是消除循环依赖非常有效的方法。 但是经常起作用的、更好的方法是，从A,B两个包中提起公 共元素，把它们封装为第三个包C。 •消除循环包的过程是一个多次迭代的过程。 •示例显示在后面图5-18中。
一种是在第二栏中列出包的所有元素名；另一种是在第二栏中 画出包中所有元素的图形和关系（参见图5-6）。
图5-6 元素的2种表示方法
• 2.包中的元素是用例
图5-7 包中的元素是用例
图5-7表示，包ATM中包含两个用例， 它们是：取款用例和超额取款用例。
3．包中元素是包 包中元素是包时，就是包嵌套。图5-8所示，就是包嵌套的 例子。外部包System:Web里面嵌入了一个包UI,UI包中有一 个类Page。
UI
System:Web:UI
（a）简单名
（b）含路径名（全名）
图5-5 包称的2种书写格式
5.2.2 包中的元素
一个包中包含的元素可能是系统、子系统、子包、 用例、构件、接口和类。下面介绍包中元素的表示方 法和元素的可见性。
• 1.包中元素是类和接口 • 当包中的元素是类和接口时，可以有两种表示类和接口的方法：
称的书写格式有两种，即简单名和全名。 • 1.包名称的书写位置 • 包名称可以有两种书写位置：一种方式是将包名写在第一栏中，另一种方式是将包名
写在第二栏中。 • （1）包名写在第一栏 • 如图5-3所示，包名Server写在第一栏。在第二栏列出了该包包含的类。
图5-3 包名写在第一栏
5.6.3 消除包的循环依赖
•应该尽量避免包模型中的循环依赖。 •如果包A以某种方式依赖包B，并且包B以某种方式依赖包A， 就应该合并这两个包，这是消除循环依赖非常有效的方法。 但是经常起作用的、更好的方法是，从A,B两个包中提起公 共元素，把它们封装为第三个包C。 •消除循环包的过程是一个多次迭代的过程。 •示例显示在后面图5-18中。
一种是在第二栏中列出包的所有元素名；另一种是在第二栏中 画出包中所有元素的图形和关系（参见图5-6）。
图5-6 元素的2种表示方法
• 2.包中的元素是用例
图5-7 包中的元素是用例
图5-7表示，包ATM中包含两个用例， 它们是：取款用例和超额取款用例。
3．包中元素是包 包中元素是包时，就是包嵌套。图5-8所示，就是包嵌套的 例子。外部包System:Web里面嵌入了一个包UI,UI包中有一 个类Page。
UI
System:Web:UI
（a）简单名
（b）含路径名（全名）
图5-5 包称的2种书写格式
5.2.2 包中的元素
一个包中包含的元素可能是系统、子系统、子包、 用例、构件、接口和类。下面介绍包中元素的表示方 法和元素的可见性。
• 1.包中元素是类和接口 • 当包中的元素是类和接口时，可以有两种表示类和接口的方法：
称的书写格式有两种，即简单名和全名。 • 1.包名称的书写位置 • 包名称可以有两种书写位置：一种方式是将包名写在第一栏中，另一种方式是将包名
写在第二栏中。 • （1）包名写在第一栏 • 如图5-3所示，包名Server写在第一栏。在第二栏列出了该包包含的类。
图5-3 包名写在第一栏
软件设计师UML知识点：第五章通用机制
UML中的四种机制使地它简单和更易于使⽤，你可以在UML语⾔的任何时候⽤同样的⽅法来使⽤，这四种机制是：l specificationsl adornmentsl common divisionsl extensibility本章讨论adornments和extensibility这两种机制。
注释是最重要的⼀种修饰。
⼀个注释在UML中是⼀个图形符号，描述了和它相关联的元素或⼀组元素的限制或注释语。
上图就是⼀个使⽤注释的例⼦，图中右边的为注释符号。
UML的扩充性机制允许你在控制的⽅式下扩充UML语⾔。
这⼀类的机制包括：stereotype，标记值、约束。
Stereotype扩充了UML的词汇表，允许你创建新的建筑块，这些建筑块从已有的继承⽽来，但特别针对你的问题。
标记值扩充了UML的建筑块的属性，允许你在元素的规格中创建新的信息。
约束扩充了UML建筑块的语义，允许你添加新的规则或修改已有的。
你将使⽤这些机制来让UML满⾜你的领域和开发的特别需要。
上⾯是⼀个使⽤扩充机制的例⼦。
<>是stereotype，{version = 3.2}是标记值术语和概念注释是⼀种图形符号⽤来限制或给⼀个元素或⼀组元素加上注解。
注释画成⼀个带折⾓的矩形，在矩形中加上⽂字或图形的注解，stereotype是UML词汇的扩充，允许你创建新的UML建筑块，这些新的建筑块和原有的类似，但特别针对你⾃⼰的问题。
通常stereotype画成⽤<<和>>包围起来的⼀个名字，通常放在另⼀个元素的名字之上。
作为可选，stereotype可以画成加⼀个图标。
标记值是UML元素特性的扩充，允许你创建元素规格的新的信息。
在UML中标记值画成{}内的字符串，跟在元素名后⾯。
限制是UML元素语义的扩充，允许你对⼀个UML元素添加新规则或修改存在的规则。
限制通常画成{}内的字符串，放在关系附近。
当然，你也可以把限制⽤注释来表⽰。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
从在构架方面具有重要意义的用例中确定分析类 通过分析类交互来更新用例实现
-34-
经典的三层构架-1
表示层
应用逻辑层
记录销售信息
支付授权
存储层
数据库
-35-
多层体系结构的动机
将应用逻辑作为单独的构件从系统中分离出来， 以便这些构件在其他系统中能得到重用 将各个层次分配到各个不同的物理计算节点， 或者分配给不同的进程。这样可以改善系统性 能、更好地支持客户和服务器系统中的信息共 享和协调 将不同层的开发任务在开发者之间适当地分配， 这可以有效地利用开发人员的专长和开发技巧， 并且能够提高并行开发能力
完备的
-19-
从用例开始-2
根据风险、重要性以及项目组的能力确定用例的优先 级：用例分级
风险 重要性 团队能力以及团队建设
在迭代开发中，通过一次全面的需求收集来获得所有 的用例；之后找出一个用例集，开发一个符合这些需 求的最小系统，完成一次迭代过程；在此基础上，进 行后续的增量开发过程
清晰地区分问题域（业务需求）和解域（详细 的设计考虑）
总是关注存在于问题域的抽象
-29-
经验法则-2
总是尽力最小化耦合
类之间的每个关联都是在它们之间建立耦合
继承关系
继承是类间耦合的最强形式 如果看起来存在自然的、强迫的抽象层次，则可探 索继承关系 分析中，永远不要仅为了复用代码而使用继承
-3-
下构化 分析设计
其它方法
自己的 土方法
系统
-4-
内容安排
面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术
-5-
面向对象分析、设计
基于面向对象的分析和设计理论，产生 了许多开发过程实践
RUP：Ration Unified Process MSF：Microsoft Solution Framework ALM：Application Lifecycle Manage
第 5 章用例分析技术
Use-Case Analysis
Review: Use-Case Modeling
基于用例的需求获取过程
1. 获取原始需求 2. 开发一个可以理解的需求
2.1 识别参与者 2.2 识别用例 2.3 构建用例图
进行用例阐述 4.1 识别用例间的关系 4.2 对用例进行组织和分包
Login Login
Employee Employee
Record Time Record Time Create Charge Code Create Employee
-26-
内容安排
面向对象分析设计过程 面向对象分析基础 面向对象分析原则 开始分析之前 用例分析技术
-27-
分析的基本原则
-16-
分析模型与用例模型
用例：外观
类图：内部机理
-17-
如何开始？
从 用 例 开 始！
-18-
从用例开始-1
根据高层用例图和文档来确认需求定义是可靠 的、一致的
可靠的
每个用例都包含对正常事件流和异常事件流的描述 存在备选事件流、异常事件流的描述
如果在分析过程中发现一些新的用例，说明需求是不完备 的，此时应对用例进行重构 在分析过程中，还有可能精化对每一个用例的理解
-31-
分析模式-2
分析模式更接近系统的概念模型，如果系统概 念模型经过抽象，可以应用在多个相似的环境 中，那么，它就变成了模式 在代码实现层面，我们很容易看到和理解重用 的概念，从最开始的函数库，到类库，到设计 模式，到应用框架，我们的对代码的重用程度 越来越高 在业务领域的分析层面，重用的可能性依然存 在，分析模式，就是这种重用的一部分，如果 我们都可以利用以往的经验，得到业务领域的 通用解决方案，它们将直接影响到应用系统的 设计，因而这种重用的价值将更加显著
-13-
OOA目标
开发一系列模型，以描述计算机软件， 从而满足客户定义的需求：分析模型
包括两种图，描述对象及其交互 这些图按照用例模型来组织，每个用例图都 会产生数张图
类图（class diagram）：描述了构成一类对象 特征的状态和行为（描述软件架构） 交互图（interaction diagram）：描述对象之 间的交互行为（演示用例实现）（描述系统行为）
------------------------------------------------------------------------------Glossary
Analysis workflow
: :
Analysis Class
-15-
OOA与用例模型
分析是建立在需求收集的基础上
Vision/Scope Approved
Release Readiness Approved
Product Management
Development
MSF
User Experience
Scope Complete Project Plans Approved
Communication
Test Release Management
-2-
3 详细、完整地描述需求
4 重构用例模型
References
[Arri02]CT Arrington, Enterprise Java with UML（马波，李雄锋译，Enterprise Java with UML中文版，机械工业出版社，2003年） [Larm01], Craig Larman, Applying UML and Patterns, 2e（姚淑珍、李虎等译，UML和模式应用 -面向对象分析与设计导论，机械工业出版社，2002 年） [DEV475], IBM Rational, Mastering ObjectOriented Analysis and Design with UML, 2003 [Kruc00], Philippe Kruchten, The Rational Unified Process: An Introduction (Second Edition)（周伯生等译，Rational统一过程引论，机 械工业出版社，2002.5）
1-用户几乎不注意用例的存在，在没有它的情况下系统不 会有什么影响 2-用户注意用例的存在，但稍加想象，系统仍然可以很好 的使用 3-系统的大部分可以独立于这个用例 4-系统的一部分可以独立于这个用例 5-没有它，就不可能使用这个系统
-24-
从用例开始-其它问题
合适性（suitability）：这个用例是否适合你 的团队
Employee
Record Time
Create Charge Code Create Employee
-21-
从用例开始-风险分析-1
项目本身风险（risk）：项目的风险清 单
无法接受的系统性能 无法应付新的需求 不确定的进度以及开发周期 无法接受的用户界面 ……
-22-
从用例开始-风险分析-2
分析模型建立在用例模型的基础上 用例模型确定了分析模型的结构（通过用例来组织 分析模型） 用户视角理解用户问题过渡到开发团队视角分析用 户问题
与需求一样，它还是在问题域中 用例分析也是分析的一个阶段，而OOA是分析的后期阶段， 从这个阶段开始，我们从用户域跨入开发团队域
分析与需求捕获在很大程度上重叠，这两个活动常 常相辅相成，为了澄清和找出任何遗漏或歪曲的需 求，常常需要在需求之上作一些分析
-6-
IBM RUP
-7-
RUP中的分析和设计工作流
软件构架文档 用例实现规约
分析 Analysis
设计 Design
-8-
分析阶段主要工件
用例视图：
用例模型 用例实现(分析)
逻辑视图：
分析(概念)模型 体系结构包图
:
:
-9-
MSF
Deployment Complete
Program Management
相对来说，策划一系列的小胜利和接受一些小的 失误总要好一点。策划一个巨大的胜利经常会导 致灾难性的失败！
-20-
用例图：考勤卡系统
Export Time Entries Billing System Change Password <<include>>
Administrativ e User
Login
“该模型对所有项目干系人有用吗？”
保持模型简单！
-30-
题外话：分析模式-1
分析模式（analysis pattern）：描述通用业 务/分析问题解决方案的一种模式
例：“游戏者击中白球，它以一定的速度前进，并 以特定的角度碰到红球，于是红球在某个特定的方 向上前进一段距离 ” 除了这些表面现象，还必须了解背后的本质，那就 是和质量有关的运动定律，速度，动量，等等。了 解这些规律将更容易看到软件可以怎样建立 我们建造应用系统的时候，需要大量的了解和研究， 才能接触到问题的本质
把分析限制在问题域词汇的那部分类 保持分析模型是一个对系统结构和行为 的精确和简单陈述
-28-
经验法则-1