UML建模语言第五章
UML建模语言目录
5.1 UML概述
5.2 通用模型元素
5.3 用例建模
5.4 静态建模
5.5 动态建模
5.6 实现模型
3UML建模语言概 述软件工程领域在 1995年至 1997年取得了前所未有的进展,其成果超过软件工程领域过去 15年来的成就总和 。 其中最重要的,具有划时代重大意义的成果之一就是统一建模语言 — UML ( Unified
Modeling Language)的出现 。 在世界范围内,至少在近 10年内,UML将是面向对象技术领域内占主导地位的标准建模语言 。
概 述
5.1 UML概述
5.1 UML概述
UML（ Unified Modeling Language） 是软件界第一个统一的建模语言,该方法结合了 Booch,OMT,和 OOSE方法的优点,统一了符号体系,并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术 。
它是一种标准的表示,已成为国际软件界广泛承认的标准 。
它是第三代面向对象的开发方法,是一种基于面向对象的可视化的通用 (General)建模语言 。 为不同领域的用户提供了统一的交流标准 — UML图 。
UML应用领域很广泛，可用于软件开发建模的各个阶段，
商业建模 （ Business Modeling）,也可用于其它类型的系统。
什么是模型？为什么要建模？
什么是模型？
模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴涵在模型中。
通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。
领域问题 概念模型分析、抽取系统需求 解决方案分析、设计提取
UML作为一种可视化的建模语言,提供了丰富的基于面向对象概念的模型元素及其图形表示元素。
5.1.1 UML的形成九十年代中,面向对象方法已经成为软件分析和设计方法的主流 。
1994年 10月 Jim Rumbaugh和 Grady Booch共同合作把他们的 OMT和 Booch方法统一起来,到 1995年成为,统一方法,（ Unified Method ） 版本 0.8 。 随后,Ivar
Jacobson加入,并采用他的用例 (User case)思想,到 1996年,
成为,统一建模语言,版本 0.9。
1997年 1月,UML版本 1.0被提交给 OMG组织,作为软件建模语言标准的候选 。 其后的半年多时间里,一些重要的软件开发商和系统集成商都成为,UML伙伴,,如
IBM,Mircrosoft,HP等,1997年 11月 7日被正式采纳作为业界标准 。
5.1.1 UML的形成
<documents>
UML 2.0
<documents>
UML 1.2
<documents>
UML 1.1
<documents>
UML1.0
<documents>
UML 0.9
<documents>
Unified Method
0.8
<documents>
UML 1.3
<documents>
UML 1.4
1995 文档版类
1996
精华相关
1997年 1月最初提交给 OMG
1997年 9月最后提交给 OMG
1998
1999
2000年
(计划的较小修订 )
2001年计划的重要修订文字上的修改没有显著的技术变化图 5.1
5.1.1 UML的形成
5.1.2 UML的主要内容
UML的定义包括 UML语义和 UML表示法两个部分 。
(1) UML语义 描述基于 UML的精确元模型 (meta-model)
定义 。 元模型为 UML的所有元素在语法和语义上提供了简单,
一致,通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的表达方法所造成的影响 。 此外 UML还支持对元模型的扩展定义 。
UML支持各种类型的语义 。 如布尔,表达式,列表,阶,
名字,坐标,这字符串和时间等,还允许用户自定义类型 。
(2) UML表示法 定义 UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准,。
这些图形符号和文字所表达的是应用级的模型,在语义上它是
UML元模型的实例 。
5.1.2 UML的主要内容
5.1.2 UML的主要构成
UML是一种标准化的图形建模语言,它是面向对象分析与设计的一种标准表示 。 由,
视图 (views),
图 (Diagrams),
模型元素 (Model elements)
通用机制 (general mechanism)
等几个部分构成 。
UML的主要构成
UML的主要内容一个系统应从不同的角度进行描述,从一个角度观察到的系统称为一个 视图 （ view） 。
视图由多个图 （ Diagrams） 构成,它不是一个图表
（ Graph）,而是在某一个抽象层上,对系统的抽象表示 。
如果要为系统建立一个完整的模型图,需定义一定数量的视图,每个视图表示系统的一个特殊的方面 。 另外,视图还把建模语言和系统开发时选择的方法或过程连接起来 。
5.1.2 UML的主要内容视图 (views)
设计视图 实现视图配置视图过程视图
Use case
视图
Use case View描述系统的外部特性、
系统功能等。 Implementation
View 表示系统的实现特征，常用构件图表示。
Design View 描述系统设计特征，
包括结构模型视图和行为模型视图，前者描述系统的静态结构 (类图、对象图 )，后者描述系统的动态行为 (交互图、
状态图、活动图 )。
Process View 表示系统内部的控制机制。常用类图描述过程结构，用交互图描述过程行为。
Deployment View 配臵视图描述系统的物理配臵特征。用配臵图表示 。
5.1.2 UML的主要内容
UML常用 视图
UML语言定义了五种类型,9种不同的图,把它们有机的结合起来就可以描述系统的所有视图 。
用例图 (Use case diagram) 从用户角度描述系统功能,并指出各功能的操作者 。
静态图 (Static diagram),表示系统的静态结构 。 包括 类图,
对象图,包图 。
行为图 (Behavior diagram),描述系统的动态模型和组成对象间的交互关系 。 包括 状态图,活动图 。
交互图 (Interactive diagram),描述对象间的交互关系 。 包括顺序图,合作图 。
实现图 ( Implementation diagram ) 用于描述系统的物理实现 。 包括 构件图,部件图 。
5.1.2 UML的主要内容图 (Diagrams)
图代表面向对象中的类,对象,关系和消息等概念,是构成图的最基本的常用的元素 。 一个模型元素可以用在多个不同的图中,无论怎样使用,它总是具有相同的含义和相同的符号表示 。
通用机制 (general mechanism)
用于表示其他信息,比如注释,模型元素的语义等 。
另外,为了适应用户的需求,它还提供了扩展机制
(Extensibility mechanisms),包括构造型 (Stereotype)、
标记值 (Tagged value)和约束 (Constraint).使用 UML语言能够适应一个特殊的方法 （ 或过程 ）,或扩充至一个组织或用户 。
5.1.2 UML的主要内容模型元素 (Model elements)
(1) 统一标准
UML统一了 Booch,OMT和 OOSE等方法中的基本概念，
已成为 OMG的正式标准，提供了标准的面向对象的模型元素的定义和表示。
(2) 面向对象
UML还吸取了面向对象技术领域中其他流派的长处。 UML
符号表示考虑了各种方法的图形表示,删掉了大量易引起混乱的、
多余的和极少使用的符号,也添加了一些新符号。
(3) 可视化、表示能力强系统的逻辑模型或实现模型都能用 UML模型清晰的表示,
可用于复杂软件系统的建模 。
(4) 独立于过程
UML是系统建模语言，独立于开发过程。
(5) 易掌握、易用由于 UML的概念明确，建模表示法简洁明了，图形结构清晰，易于掌握使用。
5.1.3 UML的特点
5.1.3 UML的特点
5.2 通用模型元素
5.2 通用模型元素模型元素是 UML构造系统的各种元素,是 UML构建模型的基本单位 。 模型元素代表面向对象中的类,对象,关系和消息等概念,是构成图的最基本的常用的概念 。 分为以下两类：
1,基元素是已由 UML定义的模型元素 。 如：类,结点,构件,注释,关联,依赖和泛化等 。
2,构造型元素在基元素的基础上构造的新的模型元素,是由基元素增加了新的定义而构成的,如扩展基元素的语义 （ 不能扩展语法结构 ）,也允许用户自定义 。 构造型用括在双尖括号,,中的字符串表示 。
目前 UML提供了 40多个预定义的构造型元素 。 如使用
,Use》,扩展,Extend,。
5.2.1 模型元素
5.2.1 模型元素图 5.2
可以在图中使用的概念统称为模型元素 。 模型元素在图中用其相应的视图元素 （ 符号 ） 表示,图 3.2给出了常用的元素符号：类,对象,结点,包和组件等 。
属性用例包结点状态组件类操作对象属性操作接口注释模型元素关联,连接 （ connect） 模型元素及链接 (link)实例 。
依赖,表示一个元素以某种方式依赖于另一种元素 。
泛化,表示一般与特殊的关系,即,一般,元素是,特殊,
关系的泛化 。
聚合,表示整体与部分的关系 。
除了上述的模型元素外,模型元素还包括消息,动作和版类
（ stereotype） 等 。
图 5.3
3.2.1 模型元素关联聚合组合依赖细化泛化（继承）
模型元素与模型元素之间的连接关系也是模型元素,常见的关系有 关联 （ association）,泛化 （ generalization）,依赖
(dependency)和 聚合 (aggregation),其中聚合是关联的一种特殊形式 。 这些关系的图示符号如图 3.3所示 。
5.2.2 关联和 链关联 （ association） 是两个或多个类之间的一个关系 。 链
（ link)是 关联的具体体现 。
5.2.2 关联和链关联的表示如图 3.４ (a)(b)所示,关联有二元关联 (binary),三元关联 (ternary),多元关联 (higherorder)。
图 5.４
（ a） 二元关联人员 公司雇用二元关联的例
（人员）
张涛
（公司）
通大雇用链的例子
（ b） 三元关联项目 语言◆
人三元关联的例
(项目 )
CAD系统
(语言 )
C ++◆
(人 )
李波链的例子
3.2.3 关联的表示关联的重数重数 (multiplicity)表示多少个对象与对方对象相连接 (图 3.5),常用的重数符号有：
,0..1‖ 表示零或 1
―0..*‖或,*” 表示零或多个
,1..*‖ 表示 1或多个
,1,3,7‖ 表示 1或 3或 7（ 枚举型 ）
重数的默认值为 1。
5.2.3 关联的表示
Person
Hobby
1
*
Committee
Person
Year ◆
0..2
1..4
3..5
Post
图 5.5 带有多重性关联有序关联与导航（导引）
在关联的多端标注 {ordered}指明这些对象是有序的 (图 3.6 ）。
关联可以用箭头，表示该关联使用的方向 (单向或双向 )，称为 导引 或导航 (navigation)。
(a)指定链接之间有明确的顺序
0..*
1..* {ordered}
保险合同个人
Polygon
Point
1
4..* {ordered}
图 5.6
(b)单向关联受限关联 (qualified association)
使用限定词对该关联的另一端的对象进行明确的标识和鉴别（图 5.7）。
限定词类 1 类 2
图 5.7 受限关联
5.3.1 关联的表示 5
关联的表示
5.2.4 约束
UML 中 提 供 了 一 种 简 便,统 一 和 一 致 的 约 束
（ constraint）,是各种模型元素的一种语义条件或限制 。 一条约束只能应用于同一类的元素 。
约束的表示如果约束应用于一种具有相应视图元素的模型元素，它可以出现在它所约束元素视图元素的旁边。
通常一个约束由一对花括号括起来（ {constraint}），花括号中为约束内容（图 3.6）。
如果一条约束涉及同一种类的多个元素,则要用虚线把所有受约束的元素框起来,并把该约束显示在旁边
（ 如或约束 ） 。
Polygon
Point
1
4..* {ordered}
图 5.8
5.2.4 约束
0..*
1..* {ordered}
保险合同个人约束图 5.9 对泛化的约束的两种表示方法约束可分为,对泛化的约束,关联的约束对泛化的约束应用于泛化的约束,显示在大括号里,若有多个约束,用逗号隔开 。 如果没有共享,则用一条虚线通过所有继承线,并在虚线的旁边显示约束,如图 3.9所示：
5.3.2 约束
{constraint 1,constraint 2}
Class A
Class B Class C Class D
{constraint 1,constraint 2}
Class A
Class CClass B Class D
对泛化有以下常用的约束：
1,complete,说明泛化中所有子元素都已在模型中说明,
不允许再增加其它子元素 。
2,disjoint,父类对象不能有多于一个型的子对象 。
3,incomplete,说明不是泛化中所有子元素都已说明,允许再增加其它子元素 。
4,overlapping,给定父类对象可有多于一个型的子对象,
表示重载 。
5.3.2 约束返回对消息,链接角色和对象的约束自定义约束帐号人单位
{xor}
图 5.10 对象类的 xor关联
5.3.2 约束关联的约束对关联有以下常用的约束：
1,implicit:该关联只是概念性的,在对模型进行精化时不再用 。
2,ordered:具有多重性的关联一端的对象是有序的 。
3,changeable:关联对象之间的链 (Link)是可变的 （ 添加,修改,删除 ） 。
4,addonly:可在任意时刻增加新的链接 。
5,frozen:冻结已创建的对象,不能再添加,删除和修改它的链接 。
6,xor,―或约束,,某时刻只有一个当前的关联实例 。
5.2.6 依赖依赖关系描述的是两个模型元素（类，组合，用例等）
之间的语义上的连接关系，其中一个模型元素是独立的，另一个模型元素是非独立的（或依赖的）。 如图 5.11表示 类 A
依赖于类 B的一个友元依赖关系。
类 A 类 B,友元,
5.2.6 依赖图 5.11
依赖的形式可能是多样的，针对不同的依赖的形式，
依赖关系有不同的变体 (varieties)：
依赖的形式可能是多样的，针对不同的依赖的形式，依赖关系有不同的变体 (varieties)：
<1>抽象 (abstraction),从一个对象中提取一些特性，并用类方法表示。
<2>绑定 (binding),为模板参数指定值，以定义一个新的模板元素。
<3>组合 (combination),对不同类或包进行性质相似融合。
<4>许可 (permission),允许另一个对象对本对象的访问。
<5>使用 (usage),声明使用一个模型元素需要用到已存在的另一个模型元素，这样才能正确实现使用者的功能 (包括调用、
实例化、参数、发送 )。
<6>跟踪 (trace),声明不同模型中元素的之间的存在一些连接。
<7>访问或连接 (access),允许一个包访问另一个包的内容。
<8>调用 (call),声明一个类调用其他类的操作的方法。
5.2.6 依赖
<9>导出 (derive),声明一个实例可从另一个实例导出。
<10>友元 (friend),允许一个元素访问另一个元素，不管被访问的元素是否具有可见性。
<11>引入 (import),允许一个包访问另一个包的内容并被访问组成部分增加别名。
<12>实例 (instantiation),关于一个类的方法创建了另一个类的实例声明。
<13>参数 (parameter),一个操作和它参数之间的关系。
<14>实现 (realize),说明和其实之间的关系。
<15>精化 (refine),声明具有两个不同语义层次上的元素之间的映射。
<16>发送 (send),信号发送者和信号接收者之间的关系。
5.2.6 依赖
5.2.7 细化有两个元素 A和 B,若 B元素是 A元素的详细描述,则称 B,A
元素之间的关系为 B元素细化 A元素 。
细化与类的抽象层次有密切的关系,在构造模型时要经过逐步细化,逐步求精的过程 。
如图 3.9所示,类 B是类 A细化的结果 。
5.2.7 细化
A B
图 5.12
5.2.8 注释注释用于对 UML语言的元素或实体进行说明,解释和描述 。 通常用自然语言进行注释 。
这是一个类人员图 5.13
5.3 用例建模
1992年由 Jacobson提出了 Use case 的概念及可视化的表示方法 — Use case图,受到了 IT界的欢迎,被广泛应用到了面向对象的系统分析中 。 用例驱动的系统分析与设计方法已成为面向对象的系统分析与设计方法的主流 。
用例模型由 Jacobson在开发 AXE系统中首先使用,
并加入由他所倡导的 OOSE和 Objectory方法中 。 用例方法引起了面向对象领域的极大关注 。 自 1994年 Ivar
Jacobson的著作出版后,面向对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志 。
5.3 用例建模用例建模技术,用于 描述系统的功能需求 。 在宏观上给出模型的总体轮廓 。 通过对典型用例的分析,使开发者能够有效地了解用户的需求 。
5.3.1 用例建模概述
5.3.1 用例建模概述贸易经理风险分析设置边界进行交易交易估价更新帐目
,使用,
,使用,
,扩展,
营销人员超越边界评价记帐系统销售人员图 3.14
3.3.2 用例模型 (Use case model)
用例模型描述的是外部执行者 (Actor)所理解的系统功能 。
它描述了待开发系统的功能需求 。
它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型 。
用例模型 由 若干个 用例图构成,用例图中主要描述执行者和用例之间的关系 。 在 UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系 。
3.3.2 用例模型创建用例模型的工作包括：
定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。
一,执行者 (Actor)
执行者是指用户在系统中所扮演的角色 。 执行者在用例图中是用类似人的图形来表示,但执行者可以是人,也可以是一个外界系统 。
注意：用例总是由执行者启动的。
如何确定执行者：
1、谁使用系统的主要功能 (主执行者 )?
2、谁需要从系统获得对日常工作的支持和服务？
3、需要谁维护管理系统的日常运行 （ 副执行者 ）？
4、系统需要控制哪些硬件设备？
5、系统需要与其它哪些系统交互？
6、谁需要使用系统产生的结果（值）？
一、执行者
5.3.2 用例模型供货买饮料取货款客户供货人收银员图 5.15自动售货系统回例 1
二,用例二,用例 (use case)
从本质上讲,一个用例是用户与计算机之间的一次典型交互作用 。 在 UML中,用例被定义成系统执行的一系列动作
（ 功能 ） 。
用例有以下特点,
用例捕获某些用户可见的需求,实现一个具体的用户目标 。
用例由执行者激活,并将结果值反馈给执行者 。
用例必须具有功能上的完整描述 。
如何确定用例：
1,与系统实现有关的主要问题是什么？
2,系统需要哪些输入 /输出？ 这些输入 /输出从何而来？ 到哪里去？
3,执行者需要系统提供哪些功能？
4,执行者是否需要对系统中的信息进行读,创建,修改,删除或存储？
二、用例
5.3.2 用例模型回例 1
5.3.3用例图图 3.16 用例图的元素
5.3.3用例图用例图描述了系统的功能需求,它是从执行者的角度来理解系统,用于捕获系统的需求,规划和控制项目；描述了系统外部的执行者与系统提供的用例之间的某种联系 。
图中还有另外两种类型的连接,即,使用,和,扩展,关系,是两种不同形式的泛化关系 。
用例 2
用例 A
用例执行者用例 1
用例 3
用例 B
,使用,
,使用,
,扩展,
(a) (b) (c)
,Use,表示一个用例使用另一个用例。
,Extend,通过向被扩展的用例添加动作来扩展用例。
用例图实例用例图实例图 5.18 应用生命周期用例图图 5.17 金融贸易系统贸易经理风险分析设置边界进行交易交易估价更新帐目
,使用,
,使用,
,扩展,营销人员超越边界评价记帐系统销售人员
5.3.4 用例图实例应用设计者应用提供者改变应用运行应用实现应用
<<使用 >>
<<扩展 >>
<<展开 >>
应用操作者
<<实现 >>
设计应用
5.3.4 用例图实例例 1 建立项目与资源管理系统的 Use case图系统的主要功能是：项目管理,资源管理和系统管理 。 项目管理包括项目的增加,删除,更新 。 资源管理包括对资源和技能的添加,删除和更新 。 系统管理包括系统的启动和关闭,
数据的存储和备份等功能 。
1、分析确定系统的执行者 (角色 ) 到确定到确定项目管理员、资源管理员、系统管理员、备份数据系统。
项目管理，资源管理和系统管理。
2、确定用例
3、对用例进行分解，画出下层的 Use case图对上层的用例进行分解,并将执行者分配到各层次的 Use case图中。
角色：
角色职责：
角色职责识别：
图 5.19角色描述模板还应画出相应的执行者描述模板及用例描述模板。
例 1 项目与资源管理系统（ PRMS）
添加技能删除技能更新技能资源管理员添加资源删除资源更新资源查找技能,Use》
查找资源,Use》
,Use》
,Use》
把技能指定给资源从资源中清除技能
,Extend》,Extend》
5.21 资源管理 Use Case图
Use Case图可以自顶而下不断精化，抽象出不同层次的 Use
Case图。
5.3.4 用例图实例系统管理员项目管理员资源管理员资源管理项目管理系统管理备份系统图 5.20 PRMS高层 Use Case图例 1 项目与资源管理系统（ PRMS）
项目管理员添加项目删除项目更新项目添加活动删除活动更新活动查找项目,Use》
添加任务
,Use》
把技能指定给资源从资源中清除技能
,Extend》,Extend》
删除任务更新任务
,Extend》
,Extend》
,Extend》
,Extend》
,Extend》
,Extend》
图 5.22 项目管理 Use Case图
5.3.4 用例图实例系统管理员图 5.23 系统管理 Use Case图添加技能存储数据启动系统关闭系统查找技能
,Use》,Use》
,Use》备份资源数据备份项目数据
,Extend,
,Extend,
,Use》
备份数据备份系统作 业现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警,并实时打印病人的病情报告，立及更新病历。
要求根据现场情景，对医院病房监护系统进行需求分析,建立系统的 Use case model。
请对系统需求进行分析！经过初步的需求分析,得到系统功能要求：1,监视病员的病症 （ 血压,体温,脉搏等 ）
2,定时更新病历
3,病员出现异常情况时报警 。
4,随机地产生某一病员的病情报告 。
例 2 医院病房监护系统产生病情报告监视病情更新病历情景教学任何建模语言都以静态建模机制为基础,标准建模语言
UML也不例外 。 所谓静态建模是指对象之间通过属性互相联系,而这些关系不随时间而转移 。
类和对象的建模,是 UML建模的基础 。 我们认为,熟练掌握基本概念,区分不同抽象层次以及在实践中灵活运用,是三条最值得注意的建模基本原则 。
UML的静态建模机制包括：
用例图 (Use case diagram)
类图 (Class diagram)
对象图 (Object diagram )
包图 (Package diagram)
构件图 (Component diagram)
配置图 (Deployment diagram)
5.4 静态建模
5.4 静态建模
5.4.1 对象类与对象
5.4.1 对象类与对象面向对象的开发方法的基本任务是建立对象模型,是软件系统开发的基础 。 UML中的对象类图 (Class Diagram)与对象图 (Object Diagram)表达了对象模型的静态结构,能够有效地建立专业领域的计算机系统对象模型 。
一,类图与对象图对象类简称类,是面向对象模型的最基本的模型元素,
用类图来描述 。 类图 (Class diagram)由系统中使用的类以及它们之间的关系组成,是描述系统的一种图式,分为长式和短式 。 类及类型名均用英文大写字母开头,属性及操作名为小写字母开头 。 常见类型有,Char,Boolean,Double,Float,
Integer,Object,Short,String等 。 类图是构建其它图的基础 。
小汽车注册号,String
日期,Cardata
速度,Integer
方向,Direction
5.4.1 对象类与对象属性：类型类名操作类名对象是对象类的实例 (instance),用对象图来描述。对象图亦分长式和短式。
对象名,类名属性操作对象名图 5.24 类图与对象图丁一：作家姓名 =丁一年龄 =30
丁一办公室中的 PC:
计算机名称 =Dell 466
内存 =64
丁一家里的 PC:
计算机名称 =长城 PII MMX
内存 =64
图 5.25 对象图
(1)属性 (attribute)
属性用来描述类的特征，表示需要处理的数据。
属性定义：
visibility attribute-name,type = initial-value {property-string}
可见性 属性名：类型 =缺省值 {约束特性 }
其中：可见性 (visibility)表示该属性对类外的元素是否可见。
分为：
public（ +） 公有的，即模型中的任何类都可以访问该属性。
private（ -） 私有的，表示不能被别的类访问。
protected（ #） 受保护的，表示该属性只能被该类及其子类访问。
如果可见性未申明，表示其可见性不确定。
5.4.1 对象类与对象
(2) 操作对数据的具体处理方法的描述则放在操作部分，操作说明了该类能做些什么工作。操作通常称为函数，它是类的一个组成部分，只能作用于该类的对象上。
操作定义：
visibility operating-name(parameter-list),return-type {property-
string}
可见性 操作名（参数表）；返回类型 {约束特性 }
其中：可见性同上。
参数表：参数名：类型,…
Parameter-name,type =default-value
返回类型：操作返回的结果类型。
5.4.1 对象类与对象 类图的描述
5。 4.1 对象类与对象二、类的识别是面向对象方法的一个难点，但又是建模的关键。常用的方法有：
1、名词识别法
2、系统实体识别法
3、从用例中识别类
4、利用分解与抽象技术关键是要定义类的“属性”及“操作”。
5.4.2 UML中类之间的关系
UML中类的关系有关联 (association),聚集 (aggregation),
泛化 (generalization),依赖 (depending)和细化 (refinement)。
一、关联关联是类之间的连结,分为：
1、常规关联 (图 5.26)
2、多元关联
3、有序关联
4、受限关联
5、或关联 (图 5.27)
6、关联类 (图 5.28)
公司 员工0..* 顾 佣 0..*
工作于 管理1..*
工人老板
0..1
图 5.26 顾佣关联图 5.27 或关联用户 工作站授权* *
授权优先级特权开始一个时间片 图 5.28 关联类
5.4.2 UML中类之间的关系保险公司 保险合同人 公司
*
*
*
{or}
5.4.2 UML中类之间的关系
7、其它关联递归关联 (Recursive association)
即一个类到自身的关联。
节点连接
*
*
图 5.29 递归关联人治疗病人医生图 5.30 带有职责的递归关联二、聚集 (aggregation)
聚集是一种特殊的关联，它指出类间的“整体 -部分”关系。
又分为：
1、共享聚集 (shared aggregation)
其“部分”对象可以是任意“整体”对象的一部分。当
“整体”端的重数不是 1时，称聚集是共享的。
整体类 部分类
２、组合聚集 (composition aggregation)
其“整体” (重数为 0,1)拥有它的“部分” 。部分仅属于同一对象，整体与部分同时存在。
整体类 部分类 窗口 工具框显示区标题图 3.31 共享聚集窗口标题工具框显示区图 3.32 组合聚集
3.4.2 UML中类之间的关系项目 人员＊ ＊
三、泛化泛化指出类之间的“一般与特殊关系”，即继承关系。父类与子类之间构成 类的分层结构 。
一般类 特殊 人员教师学生
5.4.2 UML中类之间的关系抽象类 指没有实例的类，定义一些抽象的操作，即不提供实现方法的操作，只提供操作的特征。并附以 {abstract}。
交叠泛化 在继承树中，若存在某种具有公共父类的多重继承，称为是交叠 (overlapping)的。否则是 不交 的 (disjoint)。
完全泛化 一般类特化出它所有的子类，称为完全泛化，记为 {complete}。
不完全泛化 即未特化出它所有的子类，称为是 不完全泛化的，表示为 {incomplete}.
有关泛化的约束
5.4.2 UML中类之间的关系三、泛化
{complete}
人女人男人性别图 3.34 完全泛化交通工具
drive()
汽车
drive()
轮船
drive()
drive()启动轮子转动
drive()启动螺旋浆
Person
驾驶
drive()是抽象操作图 3.35 泛化中的多态性及带识别名称的泛化
{propulsion} {propulsion}
{overlapping}
交通工具图 3.33 重叠泛化汽车 船水陆两栖车继承性的实例图 5.36 泛化关系图 形 {abstract}
颜 色中心位置笔的粗细移 动（）
旋 转（）
显 示（） {abstract}
2 维 {abstract}
定位填充类型缩放填充多边形边数顶点数显示园直径显示旋转线端点显示
0 维 {abstract}
点显示样条控制点显示弧半径起始角弧度角显示
1 维 {abstract}
定位缩放维数
5.4.2 UML中类之间的关系
5.4.2 UML中类之间的关系
OrderLine
Quantity:Integer
isSatisfied
1
*
1*
1*
Customer
name
address
CreditRating()
Order
dataReceived
isPrepaid
number:String
dispatch()
close() Personal Customer
creditCard
Corporate Customer
contactName
creditRating
creditLimit
remind()
billForMonth()
Employee
Product
0..1
+LineItem
图 5.37 泛化关系五、类图的抽象层次和细化 (Refinement)关系需要注意的是,虽然在软件开发的不同阶段都使用类图,
但这些类图表示了不同层次的抽象 。
在需求分析阶段,类图是研究领域的概念 ;在设计阶段,类图描述类与类之间的接口 ;
而在实现阶段,类图描述软件系统中类的实现 。
按照 Steve Cook和 John Dianiels的观点,类图分为三个层次,概念层,说明层,实现层 。
需要说明的是,这个观点同样也适合于其他任何模型,只是在类图中显得更为突出 。 描述了类图的抽象层次和细化
(Refinement)关系 。
5.4.2 UML中类之间的关系概念层概念层 (Conceptual)类图描述应用领域中的概念 。 实现它们的类可以从这些概念中得出,但两者并没有直接的映射关系 。 事实上,一个概念模型应独立于实现它的软件和程序设计语言 。
5.4.1 对象类与对象说明层说明层 (Specification)类图描述软件的接口部分,而不是软件的实现部分 。 面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这一差异 。 这主要是因为 OO语言中类的概念将接口与实现合在了一起 。 大多数方法由于受到语言的影响,也仿效了这一做法 。 现在这种情况正在发生变化 。 可以用一个类型 (Type )描述一个接口,这个接口可能因为实现环境,运行特性或者用户的不同而具有多种实现 。
实现层只有在实现层 (Implementation)才真正有类的概念,并且揭示软件的实现部分 。 这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流 。
理解以上层次对于画类图和读懂类图都是至关重要的 。
但是由于各层次之间没有一个清晰的界限,所以大多数建模者在画图时没能对其加以区分 。 画图时,要从一个清晰的层次观念出发 ;而读图时,则要弄清它是根据哪种层次观念来绘制的 。 要正确地理解类图,首先应正确地理解上述三种层次 。
虽然将类图分成三个层次的观点并不是 UML的组成部分,但是它们对于建模或者评价模型非常有用 。 尽管迄今为止人们似乎更强调实现层类图,但这三个层次都可应用于 UML,而且实际上另外两个层次的类图更有用 。
5.4.1 对象类与对象
5.4.3 包图一个最古老的软件方法问题是,怎样将大系统拆分成小系统 。 解决该问题的思路之一是将许多类集合成一个更高层次的单位,形成一个高内聚,低耦合的类的集合 。 UML中这种分组机制叫 包 (Package)。 引入包是为了降低系统的复杂性 。
包是一种组合机制,把各种各样的模型元素通过内在的语义连在一起成为一个整体就叫包,构成包的模型元素称为包的内容,包通常用于对模型的组织管理,因此有时又将包称为 子系统 （ subsystem） 。 包拥有自己的模型元素,包与包之间不能共用一个相同的模型元素,包的实例没有任何语义
（ 含义 ） 。 仅在模型执行期间包才有意义 。
5.4.3 包图图 3.32描述了包的表示及包之间的关系。
包的内容,可以是类的列表,也可以是另一个包图,还可以是一个类图 。
包之间的关系有依赖和泛化（继承）。
依赖关系,两个包中的任意两个类存在依赖关系,则包之间存在依赖关系 。 表示为：
泛化关系,使用继承中通用和特例的概念来说明通用包和专用包之间的关系。例如,专用包必须符合通用包的界面,与类继承关系类似。表示为：
5.4.3 包图包内容包名包名包 A
包 B
数据库界面
Oracle界面 Sybase界面
（ a）包的表示 (b)包的依赖关系 (c) 包的泛化关系图 5.38 包图包和类一样包也有可见性，利用可见性控制外部包对包的内容的存取方式,UML中定义了四种可见性：私有 (private)，
公有 (public)，保护 (protected)和实现 (implementation)。缺省值为公有。
包也可以有接口，接口与包之间用实线相连，接口通常由包的一个或多个类实现。
5.4.3 包图
X
类 P 类 S
A
B D
C
I
图 5.39 包图举例保险单填写界面系统内部保险单 客户数据库界面
（ abstract)
Oracle 界面
Sybasec界面包的继承包的依赖包
5.4.3 包图图 5.40 包图包图举例财务子系统数据库子系统数据库操作 数据库接口
Oracle 接口 Sybasec接口
5.4.3 包图图 5.41 包图举例
5.5 动态建模
9.5动态模型5.5 UML动态建模简单消息 (simple)
异步消息 (asynchronous)
同步消息 (synchronous)
图 5.42
动态模型主要描述系统的动态行为和控制结构。 动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了为满足用例要求所进行的活动以及活动间的约束关系。
在动态模型中,对象间的交互是通过对象间消息的传递来完成的 。 对象通过相互间的通信 (消息传递 )进行合作,并在其生命周期中根据通信的结果不断改变自身的状态 。
UML消息的图形表示是用带有箭头的线段。
动态模型状态图 (state diagram),状态图用来描述对象，子系统，
系统的生命周期。
活动图 (activity diagram),着重描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种。
顺序图 (sequence diagram),是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。
合作图 (collaboration diagram),用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。
9.5动态模型5.5 UML动态建模动态模型主要描述系统的动态行为和控制结构。包括 4
类图,状态图、活动图、顺序图、合作图。
UML中的消息一、简单消息 (simple)
表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节。
二,同步消息 (synchronous)
是一种嵌套 的控制流，用操作调用实现。操作的执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行。
三,异步消息 (asynchronous)
是一种异步 的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理。
5.5 UML动态建模消 息在面向对象技术中,对象间的交互是通过对象间 消息 的传递来完成的 。 在 UML中,消息的图形表示是用带有箭头的线段将消息的发送者和接收者联系起来,箭头的类型表示消息的类型 。
UML定义的消息类型有三种,
简单消息 (Simple Message) 表示简单的控制流 。
同步消息 (Synchronous Message) 表示嵌套的控制流 。
操作的调用是一种典型的同步消息 。
异步消息 (Asynchronous Message) 表示异步控制流 。 当调用者发出消息后不用等待消息的返回即可继续执行自己的操作 。 异步消息主要用于描述实时系统中的并发行为 。
5.5.3 顺序图简单消息同步消息异步消息
5.5.1 状态图状态图 (State Diagram)用来描述一个特定对象的所有可能的状态及其引起状态转移的事件 。 一个状态图包括一系列的状态以及状态之间的转移 。
状态 所有对象都具有状态,状态是对象执行了一系列活动的结果 。 当某个事件发生后,对象的状态将发生变化 。 状态图中定义的状态有,
5.5.1 状态图初态 —状态图的起始点,一个状态图只能有一个初态 。
终态 —是状态图的终点 。 而终态则可以有多个 。
中间状态 —可包括三个区域,名字域,状态变量与活动域 。
复合状态 —可以进一步细化的状态称作复合状态 。
中间态初态终态状态名状态变量活动响应事件的内部动作或活动的列表，定义为：
事件名 (参数表 [条件 ])/动作表达式状态变量 是状态图所显示的类的属性。
活动 列出了在该状态时要执行的事件和动作。有 3个 标准事件：
entry事件用于指明进入该状态时的特定动作。
exit事件用于指明退出该状态时的特定动作。
do事件用于指明在该状态中时执行的动作。
例,
无参数
5.5.1 状态图迁移图 5.43 login 状态
login
login time=curent time
entry/type ―login‖
do/get use name
do/get password
help/display help
exit/login(use_name.password)
5.5.1 状态图状态 迁移 一个对象的状态的变迁称为状态迁移 。 通常是由事件触发的,此时应标出触发转移的事件表达式 。 如果转移上未标明事件,则表示在源状态的内部活动执行完毕后自动触发转移 。
状态图在第一层 上行 向上移动到达 上行空闲到达向下移动下行超时向第一层移动到达图 5.44 电梯状态图
5.5.1 状态图图 5.45 或关系的子状态嵌套 状态 图状态图可能有嵌套的子状态图,且子状态图可以是另一个状态图 。 子状态又可分为两种：,与,子状态和,或,子状态,
图 5.46 与子状态及或子状态状态图前进 后退低速 高速运行向前 向后行使细化的状态表示
UML给出了电梯细化的状态表示 (图 5.47)。
状态名状态变量活动图 5.47 细化电梯状态图
On
first floor
Go up
(floor) Moving up
do/moving
to floor
Go up
(floor)
Idle
timer=0
do/increase timer
arrivedMoving down
do/moving to
floor
Go down (floor)
timer= timer-out
Moving to
first floor
arrived
arrived
5.5.1 状态图事件
5.5.1 状态图事件是激发状态迁移的条件或操作 。
在 UML中,有 4类事件：
1、某条件变为真；表示状态迁移的上的警戒条件。
2、收到来自外部对象的信号 (signal) 表示为状态迁移上的事件特征，也称为 消息。
3、收到来自外部对象的某个操作中的一个调用,表示为状态迁移上的事件特征，也称为 消息。
４,状态迁移上的时间表达式。
状态图之间的消息发送状态图之间可以发送消息，用虚箭头表示。
图 5.48 消息发送状态图
on/stopoff on/play
off( )
on( ) play( )
stop( )
off( )/stop( )
CD player
Remote Control
off on
on( )
off( )
stop( )play( )
stop( )play( )
off( )on( )
5.5.1 状态图顺序图存在两个轴,水平轴表示一组对象,垂直轴表示时间 。
顺序图中的对象用一个带有垂直虚线的矩形框表示,并标有对象名和类名 。 垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的 。
对象间的通信通过在对象的生命线之 间消息来表示,消息的箭头类型指明消息的类型 。
5.5.2 顺序图顺序图 (Sequence Diagram)用来描述对象之间动态的交互行为,着重体现对象间 消息传递的时间顺序 。
对象图
5.5.3 顺序图一,概述简单消息 (simple)
异步消息 (asynchronous)
同步消息 (synchronous)
当收到消息时,接收对象立即开始执行活动,即对象被激活了,通过在对象生命线上显示一个细长矩形框来表示激活 。
5.5.3 顺序图二,消息控制信息 {条件控制信息 如,［ ｘ＞０］重复控制信息 如：＊ ［ Ｉ＝ 1..n］
简单消息 (simple),表示消息类型不确定或与类型无关 。
或者是一同步消息的返回消息 。
同步消息 (synchronous),表示发送对象必须等待接收对象完成消息处理后,才能继续执行 。
异步消息 (asynchronous),表示发送对象在消息发送后,
不必等待消息处理后,可立即继续执行 。
消息 延迟,用倾斜箭头表示 。
消息串,包括消息和控制信号,控制信息位于信息串的前部 。
5.5.2 顺序图有两种使用顺序图的方式：一般格式和实例格式 。
实例格式详细描述一次可能的交互 。 没有任何条件和分支或循环,它仅仅显示选定情节 （ 场景 ） 的交互 （ 图 5.49） 。
而一般格式则描述所有的情节 。 因此,包括了分支,条件和循环 。
三,顺序图的形式
:Customer Win,Customer
1:Chang Customer data） 2:Update Customer(CustomerData)
3:
图 5.49 顺序图
:Computer,Printer Server,Printer,QueuePrint(file)
[Printer free]
Print(file)
[Printer busy]
Store(file)
图 5.50 带分支的顺序图
:C1:c,D1:D,D2:DOp( )
Op2( )
Op3( ) Op4( )
图 5.51 有循环标记的顺序图
Send message op2
until…
5.5.3 顺序图呼叫者 交换 接受者拿起话筒响拨号声拨号码路由选择鸣响音停音响铃声接电话停铃声
A
B
C
D
E
{B-A<1S}
{C-B<10S}
通过网络选择通话路径
{E-D<5S}
双方通话图 5.52 打电话的顺序图
5.5.3 顺序图创建对象与对象的消亡在顺序图中，还可以描述一个对象通过发送一条消息来创建另一个对象。
当对象消亡 (destroying)时，用符号? 表示。
,Customer WindowsNewCustomer(Data)
,CustomerCustomer(Data)
DeleteCustomer()
5.5.2 顺序图图 5.53 创建或删除对象活动图 (Activity Diagram)的应用非常广泛,它既可用来描述操作 (类的方法 )的行为,也可以描述用例和对象内部的工作过程,并可用于表示并行过程 。
活动图是由状态图变化而来的,它们各自用于不同的目的 。
活动图描述了系统中各种活动的 执行的顺序 。 刻化一个方法中所要进行的各项活动的执行流程 。
活动图中一个活动结束后将立即进入下一个活动 (在状态图中状态的变迁可能需要事件的触发 )。
5.5.3 活动图
5.5.3 活动图一、概述二、活动图的模型元素
5.5.3 活动图构成活动图的模型元素有：活动、转移、对象、信号、
泳道等。
１、活动是构成活动图的核心元素，是具有内部动作的状态，由隐含的事件触发活动的转移。
活动的解释依赖于作图的目的和抽象层次，在概念层描述中，活动表示要完成的一些任务；在说明层和实现层中，
活动表示类中的方法。
活动用圆角框表示，标注活动名。
活动名
[条件 1]
[条件 2]
图 5.54 活动二、活动图的模型元素活动还有其它的图符：初态、终态、判断、同步。
初态终态
[条件 1]
[条件 2]
判断 同步线图 5.55 活动
2、转移转移描述活动之间的关系，描述由于隐含事件引起的活动变迁，即转移可以连接各活动及特殊活动（初态、终态、
判断、同步线）。
转移用带箭头的直线表示，可标注执行该转移的条件，
无标注表示顺序执行。
5.5.2 活动图 活动图的模型元素：
图 5,56 泳道
3,泳道泳道进一步描述完成活动的对象，并聚合一组活动。活动图是另一种描述交互的方式，描述采取何种动作，做什么
（对象状态改变），何时发生（动作序列），以及在何处发生（泳道）。
泳道也是一种分组机制。
顾 客 售 货 库 房
●
请求服务支付取货提货开订单供货
５,控制图符活动图中可发送和接收信号，发送符号对应于与转移联系在一起的发送短句。接收符号也同转移联系在一起。
发送信号 接收信号
４,对象流活动图中可以出现对象，对象作为活动的输入／输出，用虚箭头表示。
测量测量值显示图 5.59 控制图符图 5.57 对象流开机器开动调制咖啡信号灯灭倒咖啡咖啡壶图 5.58 控制图符例
5.5.2 活动图活动图１
１,活动图中只有一个起点一个终点,表示方式和状态图一样,泳道被用来组合活动,通常根据活动的功能来组合 。
具体说泳道有如下目的：直接显示动作在哪一个对象中执行,
或显示的是一项组织工作的哪部分 。 泳道用纵向矩形来表示,
如图 5.60。
Displayer Sampler
Sampler.Run
(channel,frequency)
更新显示初始化测量
5.5.2 活动图三、活动图举例图 5.60 泳道
２,活动图中可发送和接收信号,发送符号对应于与转移联系在一起的发送短句 。 接收符号也同转移联系在一起 。 转移又分两种：发送信号的转移和接收信号的转移 。 发送和接收信号可以和消息的的发送对象和接收对象联系在一起,如图 5.61。
aPrinter:Printer
Print(file) Print(file)
打印创建 PS文件在屏幕上的报文框中显示“打印”
删除报文框图 5.61
CustomerWindow.
PrintAll
Customers()
5.5.2 活动图图 5.62 活动图举例
5.5.2 活动图合作图 (Collaboration Diagram),也称为协作图,用于描述相互合作的对象间的交互关系和链接 (Link)关系 。 虽然顺序图和合作图都用来描述对象间的交互关系,但侧重点不一样 。
顺序图着重体现交互的时间顺序,合作图则着重体现交互对象间的静态链接关系 。
5.5.4 合作图
5.5.4 合作图一,合作图中的模型元素合作图中对象的外观与顺序图中的一样 。 如果一个对象在消息的交互中被创建,则可在对象名称之后标以 {new}。 类似地,如果一个对象在交互期间被删除,则可在对象名称之后标以 {destroy}。
1、对象对象名 {new} 对象名 {destroy}
5.5.4 合作图
2,链接 (Link)
链接用于表示对象间的各种关系,包括 组成关系的链接
(Composition Link),聚集关系的链接 (Aggregation Link)、
限定关系的链接 (Qualified Link)以及 导航链接 (Navigation
Link)。 各种链接关系与类图中的定义相同,在链接的端点位臵可以显示对象的角色名和模板信息 。
对象Ａ
对象Ａ
对象Ｃ
对象Ｄ
对象Ｇ
对象Ｈ
对象Ｅ
对象Ｆ
限定词图 5.63 各种关系的链接对于 链接还可以加上,角色,与,约束,,在链角色上附加的约束有 global(全局 ),local(局部 ),parameter(参数 )，
self(自身 ),broadcast(广播 )。
３,消息在对象之间的静态链接关系上可标注消息,消息类型有简单消息,同步消息和异步消息三种 。 用标号表示消息执行的顺序 。 消息定义的格式如下：
消息类型 标号 控制信息：返回值,=消息名 参数表
5.5.4 合作图控制信息 {条件控制信息 如,［ ｘ＞ｙ］重复控制信息 如：＊ ［ Ｉ＝ 1..n］
标号有３种：
顺序执行：按整数大小执行。 １,２ …
嵌套执行：标号中带小数点。 1.1,1.2,1.3,…
并行执行,标号中带小写字母。 1.1.1a,1.1.1b,…
Predecessor guard-condition sequence-expression return-value:=signature
1.1*[i:= 1..n],drawsegment(i)
:控制器,窗口
:直线 {new}:布线
i-1 i
左,端点 右,端点
,参数,窗口
,局部,直线 内容 {new}
窗口
,自授,1.1.2 Create(r0,r1)
1.1.3 display(window)
1.1.1b:r1:=position()1.1.1a:r0:=position()
1,displaypositions(window) 1.1.3.1 add(self)
Redisplay()
5.5.4 合作图图 5.64 电路设计的合作图在控制器控制下进行布线，找出左端点 r0和右端点 r1，创建对象“直线”，并在窗口显示出来。
布线
5.5.4 合作图下图为一销售结果统计的合作图 。
图 5.65 统计销售结果的合作图
:Sales Statistics
Window
:Statistics
Summary
{new}
:Order
:Budget Sales
1:Show ( ) 1.1:Create( )
1.2*[while any
Lines left]
Get Rerultline( )
1.1.2*[for all
Sales persons]:
Budget=Get Budget
1.1.2.1:
Get Budget
Amount()
1.1.1.1*[for all
Orders]:Get
OrderAmount( )
:Sales Person
1.1.1*[for all SaiesPerson]:
Ordersum=GetTotalOrders( )
关于 顺序图与 合作图
１,顺序图与 合作图都是交互图，它们有何不同？所描述的主要系统特征是什么？
２,顺序图与 合作图各适合于在哪类系统中使用？
关于 状态图与 活动图
１,状态图与 活动图有何相同与不同之处？
２、在建立系统模型时，应该如何使用这两类模型？
5.6 实现模型实现模型 描述了系统实现时的一些特性，又称为 物理体系结构建模 。包括源代码的静态结构和运行时刻的实现结构。实现模型包括：
构件图 (Component diagram) 显示代码本身的逻辑结构,它描述系统中存在的软构件以及它们之间的依赖关系 。 构件图的元素有构件,依赖关系和界面 。
配臵图 (Deployment diagram)描述了系统中硬件和软件的物理配臵情况和系统体系结构。显示系统运行时刻的结构，配臵图中的简单结点是指实际的物理设备以及在该结点上运行构件或对象。配臵图还描述结点之间的连接以及通信类型。
5.6 实现模型构件（ component）
构件定义,系统中遵从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时，它是一个重要的构造块。
构件的名称和类的名称的命名法则很是相似，有简单名和路径名之分。
构件的描述如上图所示。
若构件的定义良好，该构件不直接依赖于构件的所支持的接口，在这种情况下，系统中的一个构件可以被支持正确接口的其他构件所替代。构件图符是一个矩形框（图 5.66）。
构件对外提供的可见操作和属性称为构件的界面。 界面的图符是一个小圆圈。用一条连线将构件与圆圈连起来。
5.6.1 构件图
5.6.1 构件图图形库
(graphic.dll)
图 5.66
5.6.1 构件图构件可以看作包与类对应的物理代码模块,逻辑上与包,类对应,实际上是一个文件,可以有下列几种类型的构件：
1） 源代码构件；
2） 二进制构件；
3） 可执行构件构件图符是一个矩形框 。
构件对外提供的可见操作和属性称为构件的界面 。
界面的图符是一个小圆圈 。 用一条连线将构件与圆圈连起来 。
构件之间的依赖关系是指结构之间在编译,连接或执行时的依赖关系 。 用虚线箭头表示 。
5.6.1 构件图图 5.67
5.6.1 构件图窗口控制
（ whnd.cpp）
通信控制
(comhnd.cpp)
主控模块
(main.cpp)
窗口控制
(whnd.obj)
通讯控制
(comhnd.obj)
主控模块
(main.obj)
图形库
(graphic.dll)
客户程序
(client.exe)
构件图实例构件关系
Circle.obj类
Circle.cpp
Main类
Main.obj
Main类
Main.cpp
图形库
Graphic.dll
Square类
Square.cpp
Square类
Square.objCircle类Circle.obj
可执行程序
Main.exe
图 5.68
5.6.1 构件图
开发期的依赖 (Development –time Dependency)
是指在编译阶段和连接阶段，组件之间的依赖关系。
调用依赖 (Call Dependency)
是指一个组件调用或使用另外一个组件服务。
组件的依赖关系又分为：开发期的依赖和调用依赖。
业 务
（源码）
项目管理
（源码）
项目管理
（对象）
项目管理
（执行码）
系统管理
（源码）
资源 管理
（源码）
资源 管理
（对象）
资源 管理
（执行码）
系统管理
（对象）
系统 管理
（执行码）
图 5.69
5.6.1 构件图
5.6.2 配置图配臵图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件,即系统运行时的刻的结构 。 配臵图可以显示计算机结点的拓扑结构和通信路径,结点上执行的软构件,
软构件包含的逻辑单元等,特别对于分布式系统,配臵图可以清楚的描述系统中硬件设备的配臵,通信以及在各硬件设备上各种软构件和对象的配臵 。 因此,配臵图是描述任何基于计算机的应用系统的物理配臵或逻辑配臵的有力工具,配臵图的元素有结点和连接 。
配臵图中的结点代表某种计算机构件,通常是某种硬件 。
同时结点还包括在其上运行的软构件,软构件代表可执行的物理代码模块 。 如一个可执行程序 。 结点的图符是一个立方体 。
5.6.2 配置图图 5.70
保险单填写界面保险系统保险数据库保险政策保险用户客户 PC,TCP/IP>
保险服务器保险系统配置配置保险系统的配置图
5.6.2 配置图配臵图各结点之间进行交互的通信路径称为连接，连接表示系统中的结点存在着联系，用结点之间的的连线表示连接，
在连接的连线上要标注通信类型。如图 5.70.
医院诊疗系统的配臵图图 5.71 医院诊疗系统的配置图 (C/S)
:Object
Database
:Health Care
Domain
Database Unit Server
（数据库服务器）
a Windows PC（客户机）
:Object
Database
:Health Care
Domain
Heart Unit Server（ 心血管病服务器 ）
:Configure
Knowledge
:Configure users
Heart Unit Configuration
,Communication,
TCP/IP
TCP/IP
:Heart Unit UI
:Heart Unit
Client Facade
:Heart Unit
Server
Application
5.6.2 配置图面向对象建模是软件工程中最重要的技术之一,
UML已成为面向对象建模事实上的标准 。
标准建模语言 UML定义良好,易于表达,功能强大,
不仅支持面向对象的分析与设计,而且支持从需求分析开始的软件开发的全过程 。 但如何恰当地将这种可视化图形建模技术用于解决软件开发所面临的问题,如何研制和开发支持 UML的建模过程及其支持环境,仍是目前该领域的热点问题 。
目前,在基于 UML的开发方法和环境方面,国际上已经进行了一些研究和实际开发工作 。 Rational 公司正致力于它称之为 Objectory过程的研究,并试图将其原有支持
OMT的工具作进一步扩充,以期支持 UML建模 。 国内对 UML
支持 环境的研制开发工作尚处于起步阶段 。
小 结小 结
UML建模语言目录
5.1 UML概述
5.2 通用模型元素
5.3 用例建模
5.4 静态建模
5.5 动态建模
5.6 实现模型
3UML建模语言概 述软件工程领域在 1995年至 1997年取得了前所未有的进展,其成果超过软件工程领域过去 15年来的成就总和 。 其中最重要的,具有划时代重大意义的成果之一就是统一建模语言 — UML ( Unified
Modeling Language)的出现 。 在世界范围内,至少在近 10年内,UML将是面向对象技术领域内占主导地位的标准建模语言 。
概 述
5.1 UML概述
5.1 UML概述
UML（ Unified Modeling Language） 是软件界第一个统一的建模语言,该方法结合了 Booch,OMT,和 OOSE方法的优点,统一了符号体系,并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术 。
它是一种标准的表示,已成为国际软件界广泛承认的标准 。
它是第三代面向对象的开发方法,是一种基于面向对象的可视化的通用 (General)建模语言 。 为不同领域的用户提供了统一的交流标准 — UML图 。
UML应用领域很广泛，可用于软件开发建模的各个阶段，
商业建模 （ Business Modeling）,也可用于其它类型的系统。
什么是模型？为什么要建模？
什么是模型？
模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴涵在模型中。
通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。
领域问题 概念模型分析、抽取系统需求 解决方案分析、设计提取
UML作为一种可视化的建模语言,提供了丰富的基于面向对象概念的模型元素及其图形表示元素。
5.1.1 UML的形成九十年代中,面向对象方法已经成为软件分析和设计方法的主流 。
1994年 10月 Jim Rumbaugh和 Grady Booch共同合作把他们的 OMT和 Booch方法统一起来,到 1995年成为,统一方法,（ Unified Method ） 版本 0.8 。 随后,Ivar
Jacobson加入,并采用他的用例 (User case)思想,到 1996年,
成为,统一建模语言,版本 0.9。
1997年 1月,UML版本 1.0被提交给 OMG组织,作为软件建模语言标准的候选 。 其后的半年多时间里,一些重要的软件开发商和系统集成商都成为,UML伙伴,,如
IBM,Mircrosoft,HP等,1997年 11月 7日被正式采纳作为业界标准 。
5.1.1 UML的形成
<documents>
UML 2.0
<documents>
UML 1.2
<documents>
UML 1.1
<documents>
UML1.0
<documents>
UML 0.9
<documents>
Unified Method
0.8
<documents>
UML 1.3
<documents>
UML 1.4
1995 文档版类
1996
精华相关
1997年 1月最初提交给 OMG
1997年 9月最后提交给 OMG
1998
1999
2000年
(计划的较小修订 )
2001年计划的重要修订文字上的修改没有显著的技术变化图 5.1
5.1.1 UML的形成
5.1.2 UML的主要内容
UML的定义包括 UML语义和 UML表示法两个部分 。
(1) UML语义 描述基于 UML的精确元模型 (meta-model)
定义 。 元模型为 UML的所有元素在语法和语义上提供了简单,
一致,通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的表达方法所造成的影响 。 此外 UML还支持对元模型的扩展定义 。
UML支持各种类型的语义 。 如布尔,表达式,列表,阶,
名字,坐标,这字符串和时间等,还允许用户自定义类型 。
(2) UML表示法 定义 UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准,。
这些图形符号和文字所表达的是应用级的模型,在语义上它是
UML元模型的实例 。
5.1.2 UML的主要内容
5.1.2 UML的主要构成
UML是一种标准化的图形建模语言,它是面向对象分析与设计的一种标准表示 。 由,
视图 (views),
图 (Diagrams),
模型元素 (Model elements)
通用机制 (general mechanism)
等几个部分构成 。
UML的主要构成
UML的主要内容一个系统应从不同的角度进行描述,从一个角度观察到的系统称为一个 视图 （ view） 。
视图由多个图 （ Diagrams） 构成,它不是一个图表
（ Graph）,而是在某一个抽象层上,对系统的抽象表示 。
如果要为系统建立一个完整的模型图,需定义一定数量的视图,每个视图表示系统的一个特殊的方面 。 另外,视图还把建模语言和系统开发时选择的方法或过程连接起来 。
5.1.2 UML的主要内容视图 (views)
设计视图 实现视图配置视图过程视图
Use case
视图
Use case View描述系统的外部特性、
系统功能等。 Implementation
View 表示系统的实现特征，常用构件图表示。
Design View 描述系统设计特征，
包括结构模型视图和行为模型视图，前者描述系统的静态结构 (类图、对象图 )，后者描述系统的动态行为 (交互图、
状态图、活动图 )。
Process View 表示系统内部的控制机制。常用类图描述过程结构，用交互图描述过程行为。
Deployment View 配臵视图描述系统的物理配臵特征。用配臵图表示 。
5.1.2 UML的主要内容
UML常用 视图
UML语言定义了五种类型,9种不同的图,把它们有机的结合起来就可以描述系统的所有视图 。
用例图 (Use case diagram) 从用户角度描述系统功能,并指出各功能的操作者 。
静态图 (Static diagram),表示系统的静态结构 。 包括 类图,
对象图,包图 。
行为图 (Behavior diagram),描述系统的动态模型和组成对象间的交互关系 。 包括 状态图,活动图 。
交互图 (Interactive diagram),描述对象间的交互关系 。 包括顺序图,合作图 。
实现图 ( Implementation diagram ) 用于描述系统的物理实现 。 包括 构件图,部件图 。
5.1.2 UML的主要内容图 (Diagrams)
图代表面向对象中的类,对象,关系和消息等概念,是构成图的最基本的常用的元素 。 一个模型元素可以用在多个不同的图中,无论怎样使用,它总是具有相同的含义和相同的符号表示 。
通用机制 (general mechanism)
用于表示其他信息,比如注释,模型元素的语义等 。
另外,为了适应用户的需求,它还提供了扩展机制
(Extensibility mechanisms),包括构造型 (Stereotype)、
标记值 (Tagged value)和约束 (Constraint).使用 UML语言能够适应一个特殊的方法 （ 或过程 ）,或扩充至一个组织或用户 。
5.1.2 UML的主要内容模型元素 (Model elements)
(1) 统一标准
UML统一了 Booch,OMT和 OOSE等方法中的基本概念，
已成为 OMG的正式标准，提供了标准的面向对象的模型元素的定义和表示。
(2) 面向对象
UML还吸取了面向对象技术领域中其他流派的长处。 UML
符号表示考虑了各种方法的图形表示,删掉了大量易引起混乱的、
多余的和极少使用的符号,也添加了一些新符号。
(3) 可视化、表示能力强系统的逻辑模型或实现模型都能用 UML模型清晰的表示,
可用于复杂软件系统的建模 。
(4) 独立于过程
UML是系统建模语言，独立于开发过程。
(5) 易掌握、易用由于 UML的概念明确，建模表示法简洁明了，图形结构清晰，易于掌握使用。
5.1.3 UML的特点
5.1.3 UML的特点
5.2 通用模型元素
5.2 通用模型元素模型元素是 UML构造系统的各种元素,是 UML构建模型的基本单位 。 模型元素代表面向对象中的类,对象,关系和消息等概念,是构成图的最基本的常用的概念 。 分为以下两类：
1,基元素是已由 UML定义的模型元素 。 如：类,结点,构件,注释,关联,依赖和泛化等 。
2,构造型元素在基元素的基础上构造的新的模型元素,是由基元素增加了新的定义而构成的,如扩展基元素的语义 （ 不能扩展语法结构 ）,也允许用户自定义 。 构造型用括在双尖括号,,中的字符串表示 。
目前 UML提供了 40多个预定义的构造型元素 。 如使用
,Use》,扩展,Extend,。
5.2.1 模型元素
5.2.1 模型元素图 5.2
可以在图中使用的概念统称为模型元素 。 模型元素在图中用其相应的视图元素 （ 符号 ） 表示,图 3.2给出了常用的元素符号：类,对象,结点,包和组件等 。
属性用例包结点状态组件类操作对象属性操作接口注释模型元素关联,连接 （ connect） 模型元素及链接 (link)实例 。
依赖,表示一个元素以某种方式依赖于另一种元素 。
泛化,表示一般与特殊的关系,即,一般,元素是,特殊,
关系的泛化 。
聚合,表示整体与部分的关系 。
除了上述的模型元素外,模型元素还包括消息,动作和版类
（ stereotype） 等 。
图 5.3
3.2.1 模型元素关联聚合组合依赖细化泛化（继承）
模型元素与模型元素之间的连接关系也是模型元素,常见的关系有 关联 （ association）,泛化 （ generalization）,依赖
(dependency)和 聚合 (aggregation),其中聚合是关联的一种特殊形式 。 这些关系的图示符号如图 3.3所示 。
5.2.2 关联和 链关联 （ association） 是两个或多个类之间的一个关系 。 链
（ link)是 关联的具体体现 。
5.2.2 关联和链关联的表示如图 3.４ (a)(b)所示,关联有二元关联 (binary),三元关联 (ternary),多元关联 (higherorder)。
图 5.４
（ a） 二元关联人员 公司雇用二元关联的例
（人员）
张涛
（公司）
通大雇用链的例子
（ b） 三元关联项目 语言◆
人三元关联的例
(项目 )
CAD系统
(语言 )
C ++◆
(人 )
李波链的例子
3.2.3 关联的表示关联的重数重数 (multiplicity)表示多少个对象与对方对象相连接 (图 3.5),常用的重数符号有：
,0..1‖ 表示零或 1
―0..*‖或,*” 表示零或多个
,1..*‖ 表示 1或多个
,1,3,7‖ 表示 1或 3或 7（ 枚举型 ）
重数的默认值为 1。
5.2.3 关联的表示
Person
Hobby
1
*
Committee
Person
Year ◆
0..2
1..4
3..5
Post
图 5.5 带有多重性关联有序关联与导航（导引）
在关联的多端标注 {ordered}指明这些对象是有序的 (图 3.6 ）。
关联可以用箭头，表示该关联使用的方向 (单向或双向 )，称为 导引 或导航 (navigation)。
(a)指定链接之间有明确的顺序
0..*
1..* {ordered}
保险合同个人
Polygon
Point
1
4..* {ordered}
图 5.6
(b)单向关联受限关联 (qualified association)
使用限定词对该关联的另一端的对象进行明确的标识和鉴别（图 5.7）。
限定词类 1 类 2
图 5.7 受限关联
5.3.1 关联的表示 5
关联的表示
5.2.4 约束
UML 中 提 供 了 一 种 简 便,统 一 和 一 致 的 约 束
（ constraint）,是各种模型元素的一种语义条件或限制 。 一条约束只能应用于同一类的元素 。
约束的表示如果约束应用于一种具有相应视图元素的模型元素，它可以出现在它所约束元素视图元素的旁边。
通常一个约束由一对花括号括起来（ {constraint}），花括号中为约束内容（图 3.6）。
如果一条约束涉及同一种类的多个元素,则要用虚线把所有受约束的元素框起来,并把该约束显示在旁边
（ 如或约束 ） 。
Polygon
Point
1
4..* {ordered}
图 5.8
5.2.4 约束
0..*
1..* {ordered}
保险合同个人约束图 5.9 对泛化的约束的两种表示方法约束可分为,对泛化的约束,关联的约束对泛化的约束应用于泛化的约束,显示在大括号里,若有多个约束,用逗号隔开 。 如果没有共享,则用一条虚线通过所有继承线,并在虚线的旁边显示约束,如图 3.9所示：
5.3.2 约束
{constraint 1,constraint 2}
Class A
Class B Class C Class D
{constraint 1,constraint 2}
Class A
Class CClass B Class D
对泛化有以下常用的约束：
1,complete,说明泛化中所有子元素都已在模型中说明,
不允许再增加其它子元素 。
2,disjoint,父类对象不能有多于一个型的子对象 。
3,incomplete,说明不是泛化中所有子元素都已说明,允许再增加其它子元素 。
4,overlapping,给定父类对象可有多于一个型的子对象,
表示重载 。
5.3.2 约束返回对消息,链接角色和对象的约束自定义约束帐号人单位
{xor}
图 5.10 对象类的 xor关联
5.3.2 约束关联的约束对关联有以下常用的约束：
1,implicit:该关联只是概念性的,在对模型进行精化时不再用 。
2,ordered:具有多重性的关联一端的对象是有序的 。
3,changeable:关联对象之间的链 (Link)是可变的 （ 添加,修改,删除 ） 。
4,addonly:可在任意时刻增加新的链接 。
5,frozen:冻结已创建的对象,不能再添加,删除和修改它的链接 。
6,xor,―或约束,,某时刻只有一个当前的关联实例 。
5.2.6 依赖依赖关系描述的是两个模型元素（类，组合，用例等）
之间的语义上的连接关系，其中一个模型元素是独立的，另一个模型元素是非独立的（或依赖的）。 如图 5.11表示 类 A
依赖于类 B的一个友元依赖关系。
类 A 类 B,友元,
5.2.6 依赖图 5.11
依赖的形式可能是多样的，针对不同的依赖的形式，
依赖关系有不同的变体 (varieties)：
依赖的形式可能是多样的，针对不同的依赖的形式，依赖关系有不同的变体 (varieties)：
<1>抽象 (abstraction),从一个对象中提取一些特性，并用类方法表示。
<2>绑定 (binding),为模板参数指定值，以定义一个新的模板元素。
<3>组合 (combination),对不同类或包进行性质相似融合。
<4>许可 (permission),允许另一个对象对本对象的访问。
<5>使用 (usage),声明使用一个模型元素需要用到已存在的另一个模型元素，这样才能正确实现使用者的功能 (包括调用、
实例化、参数、发送 )。
<6>跟踪 (trace),声明不同模型中元素的之间的存在一些连接。
<7>访问或连接 (access),允许一个包访问另一个包的内容。
<8>调用 (call),声明一个类调用其他类的操作的方法。
5.2.6 依赖
<9>导出 (derive),声明一个实例可从另一个实例导出。
<10>友元 (friend),允许一个元素访问另一个元素，不管被访问的元素是否具有可见性。
<11>引入 (import),允许一个包访问另一个包的内容并被访问组成部分增加别名。
<12>实例 (instantiation),关于一个类的方法创建了另一个类的实例声明。
<13>参数 (parameter),一个操作和它参数之间的关系。
<14>实现 (realize),说明和其实之间的关系。
<15>精化 (refine),声明具有两个不同语义层次上的元素之间的映射。
<16>发送 (send),信号发送者和信号接收者之间的关系。
5.2.6 依赖
5.2.7 细化有两个元素 A和 B,若 B元素是 A元素的详细描述,则称 B,A
元素之间的关系为 B元素细化 A元素 。
细化与类的抽象层次有密切的关系,在构造模型时要经过逐步细化,逐步求精的过程 。
如图 3.9所示,类 B是类 A细化的结果 。
5.2.7 细化
A B
图 5.12
5.2.8 注释注释用于对 UML语言的元素或实体进行说明,解释和描述 。 通常用自然语言进行注释 。
这是一个类人员图 5.13
5.3 用例建模
1992年由 Jacobson提出了 Use case 的概念及可视化的表示方法 — Use case图,受到了 IT界的欢迎,被广泛应用到了面向对象的系统分析中 。 用例驱动的系统分析与设计方法已成为面向对象的系统分析与设计方法的主流 。
用例模型由 Jacobson在开发 AXE系统中首先使用,
并加入由他所倡导的 OOSE和 Objectory方法中 。 用例方法引起了面向对象领域的极大关注 。 自 1994年 Ivar
Jacobson的著作出版后,面向对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志 。
5.3 用例建模用例建模技术,用于 描述系统的功能需求 。 在宏观上给出模型的总体轮廓 。 通过对典型用例的分析,使开发者能够有效地了解用户的需求 。
5.3.1 用例建模概述
5.3.1 用例建模概述贸易经理风险分析设置边界进行交易交易估价更新帐目
,使用,
,使用,
,扩展,
营销人员超越边界评价记帐系统销售人员图 3.14
3.3.2 用例模型 (Use case model)
用例模型描述的是外部执行者 (Actor)所理解的系统功能 。
它描述了待开发系统的功能需求 。
它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型 。
用例模型 由 若干个 用例图构成,用例图中主要描述执行者和用例之间的关系 。 在 UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系 。
3.3.2 用例模型创建用例模型的工作包括：
定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。
一,执行者 (Actor)
执行者是指用户在系统中所扮演的角色 。 执行者在用例图中是用类似人的图形来表示,但执行者可以是人,也可以是一个外界系统 。
注意：用例总是由执行者启动的。
如何确定执行者：
1、谁使用系统的主要功能 (主执行者 )?
2、谁需要从系统获得对日常工作的支持和服务？
3、需要谁维护管理系统的日常运行 （ 副执行者 ）？
4、系统需要控制哪些硬件设备？
5、系统需要与其它哪些系统交互？
6、谁需要使用系统产生的结果（值）？
一、执行者
5.3.2 用例模型供货买饮料取货款客户供货人收银员图 5.15自动售货系统回例 1
二,用例二,用例 (use case)
从本质上讲,一个用例是用户与计算机之间的一次典型交互作用 。 在 UML中,用例被定义成系统执行的一系列动作
（ 功能 ） 。
用例有以下特点,
用例捕获某些用户可见的需求,实现一个具体的用户目标 。
用例由执行者激活,并将结果值反馈给执行者 。
用例必须具有功能上的完整描述 。
如何确定用例：
1,与系统实现有关的主要问题是什么？
2,系统需要哪些输入 /输出？ 这些输入 /输出从何而来？ 到哪里去？
3,执行者需要系统提供哪些功能？
4,执行者是否需要对系统中的信息进行读,创建,修改,删除或存储？
二、用例
5.3.2 用例模型回例 1
5.3.3用例图图 3.16 用例图的元素
5.3.3用例图用例图描述了系统的功能需求,它是从执行者的角度来理解系统,用于捕获系统的需求,规划和控制项目；描述了系统外部的执行者与系统提供的用例之间的某种联系 。
图中还有另外两种类型的连接,即,使用,和,扩展,关系,是两种不同形式的泛化关系 。
用例 2
用例 A
用例执行者用例 1
用例 3
用例 B
,使用,
,使用,
,扩展,
(a) (b) (c)
,Use,表示一个用例使用另一个用例。
,Extend,通过向被扩展的用例添加动作来扩展用例。
用例图实例用例图实例图 5.18 应用生命周期用例图图 5.17 金融贸易系统贸易经理风险分析设置边界进行交易交易估价更新帐目
,使用,
,使用,
,扩展,营销人员超越边界评价记帐系统销售人员
5.3.4 用例图实例应用设计者应用提供者改变应用运行应用实现应用
<<使用 >>
<<扩展 >>
<<展开 >>
应用操作者
<<实现 >>
设计应用
5.3.4 用例图实例例 1 建立项目与资源管理系统的 Use case图系统的主要功能是：项目管理,资源管理和系统管理 。 项目管理包括项目的增加,删除,更新 。 资源管理包括对资源和技能的添加,删除和更新 。 系统管理包括系统的启动和关闭,
数据的存储和备份等功能 。
1、分析确定系统的执行者 (角色 ) 到确定到确定项目管理员、资源管理员、系统管理员、备份数据系统。
项目管理，资源管理和系统管理。
2、确定用例
3、对用例进行分解，画出下层的 Use case图对上层的用例进行分解,并将执行者分配到各层次的 Use case图中。
角色：
角色职责：
角色职责识别：
图 5.19角色描述模板还应画出相应的执行者描述模板及用例描述模板。
例 1 项目与资源管理系统（ PRMS）
添加技能删除技能更新技能资源管理员添加资源删除资源更新资源查找技能,Use》
查找资源,Use》
,Use》
,Use》
把技能指定给资源从资源中清除技能
,Extend》,Extend》
5.21 资源管理 Use Case图
Use Case图可以自顶而下不断精化，抽象出不同层次的 Use
Case图。
5.3.4 用例图实例系统管理员项目管理员资源管理员资源管理项目管理系统管理备份系统图 5.20 PRMS高层 Use Case图例 1 项目与资源管理系统（ PRMS）
项目管理员添加项目删除项目更新项目添加活动删除活动更新活动查找项目,Use》
添加任务
,Use》
把技能指定给资源从资源中清除技能
,Extend》,Extend》
删除任务更新任务
,Extend》
,Extend》
,Extend》
,Extend》
,Extend》
,Extend》
图 5.22 项目管理 Use Case图
5.3.4 用例图实例系统管理员图 5.23 系统管理 Use Case图添加技能存储数据启动系统关闭系统查找技能
,Use》,Use》
,Use》备份资源数据备份项目数据
,Extend,
,Extend,
,Use》
备份数据备份系统作 业现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警,并实时打印病人的病情报告，立及更新病历。
要求根据现场情景，对医院病房监护系统进行需求分析,建立系统的 Use case model。
请对系统需求进行分析！经过初步的需求分析,得到系统功能要求：1,监视病员的病症 （ 血压,体温,脉搏等 ）
2,定时更新病历
3,病员出现异常情况时报警 。
4,随机地产生某一病员的病情报告 。
例 2 医院病房监护系统产生病情报告监视病情更新病历情景教学任何建模语言都以静态建模机制为基础,标准建模语言
UML也不例外 。 所谓静态建模是指对象之间通过属性互相联系,而这些关系不随时间而转移 。
类和对象的建模,是 UML建模的基础 。 我们认为,熟练掌握基本概念,区分不同抽象层次以及在实践中灵活运用,是三条最值得注意的建模基本原则 。
UML的静态建模机制包括：
用例图 (Use case diagram)
类图 (Class diagram)
对象图 (Object diagram )
包图 (Package diagram)
构件图 (Component diagram)
配置图 (Deployment diagram)
5.4 静态建模
5.4 静态建模
5.4.1 对象类与对象
5.4.1 对象类与对象面向对象的开发方法的基本任务是建立对象模型,是软件系统开发的基础 。 UML中的对象类图 (Class Diagram)与对象图 (Object Diagram)表达了对象模型的静态结构,能够有效地建立专业领域的计算机系统对象模型 。
一,类图与对象图对象类简称类,是面向对象模型的最基本的模型元素,
用类图来描述 。 类图 (Class diagram)由系统中使用的类以及它们之间的关系组成,是描述系统的一种图式,分为长式和短式 。 类及类型名均用英文大写字母开头,属性及操作名为小写字母开头 。 常见类型有,Char,Boolean,Double,Float,
Integer,Object,Short,String等 。 类图是构建其它图的基础 。
小汽车注册号,String
日期,Cardata
速度,Integer
方向,Direction
5.4.1 对象类与对象属性：类型类名操作类名对象是对象类的实例 (instance),用对象图来描述。对象图亦分长式和短式。
对象名,类名属性操作对象名图 5.24 类图与对象图丁一：作家姓名 =丁一年龄 =30
丁一办公室中的 PC:
计算机名称 =Dell 466
内存 =64
丁一家里的 PC:
计算机名称 =长城 PII MMX
内存 =64
图 5.25 对象图
(1)属性 (attribute)
属性用来描述类的特征，表示需要处理的数据。
属性定义：
visibility attribute-name,type = initial-value {property-string}
可见性 属性名：类型 =缺省值 {约束特性 }
其中：可见性 (visibility)表示该属性对类外的元素是否可见。
分为：
public（ +） 公有的，即模型中的任何类都可以访问该属性。
private（ -） 私有的，表示不能被别的类访问。
protected（ #） 受保护的，表示该属性只能被该类及其子类访问。
如果可见性未申明，表示其可见性不确定。
5.4.1 对象类与对象
(2) 操作对数据的具体处理方法的描述则放在操作部分，操作说明了该类能做些什么工作。操作通常称为函数，它是类的一个组成部分，只能作用于该类的对象上。
操作定义：
visibility operating-name(parameter-list),return-type {property-
string}
可见性 操作名（参数表）；返回类型 {约束特性 }
其中：可见性同上。
参数表：参数名：类型,…
Parameter-name,type =default-value
返回类型：操作返回的结果类型。
5.4.1 对象类与对象 类图的描述
5。 4.1 对象类与对象二、类的识别是面向对象方法的一个难点，但又是建模的关键。常用的方法有：
1、名词识别法
2、系统实体识别法
3、从用例中识别类
4、利用分解与抽象技术关键是要定义类的“属性”及“操作”。
5.4.2 UML中类之间的关系
UML中类的关系有关联 (association),聚集 (aggregation),
泛化 (generalization),依赖 (depending)和细化 (refinement)。
一、关联关联是类之间的连结,分为：
1、常规关联 (图 5.26)
2、多元关联
3、有序关联
4、受限关联
5、或关联 (图 5.27)
6、关联类 (图 5.28)
公司 员工0..* 顾 佣 0..*
工作于 管理1..*
工人老板
0..1
图 5.26 顾佣关联图 5.27 或关联用户 工作站授权* *
授权优先级特权开始一个时间片 图 5.28 关联类
5.4.2 UML中类之间的关系保险公司 保险合同人 公司
*
*
*
{or}
5.4.2 UML中类之间的关系
7、其它关联递归关联 (Recursive association)
即一个类到自身的关联。
节点连接
*
*
图 5.29 递归关联人治疗病人医生图 5.30 带有职责的递归关联二、聚集 (aggregation)
聚集是一种特殊的关联，它指出类间的“整体 -部分”关系。
又分为：
1、共享聚集 (shared aggregation)
其“部分”对象可以是任意“整体”对象的一部分。当
“整体”端的重数不是 1时，称聚集是共享的。
整体类 部分类
２、组合聚集 (composition aggregation)
其“整体” (重数为 0,1)拥有它的“部分” 。部分仅属于同一对象，整体与部分同时存在。
整体类 部分类 窗口 工具框显示区标题图 3.31 共享聚集窗口标题工具框显示区图 3.32 组合聚集
3.4.2 UML中类之间的关系项目 人员＊ ＊
三、泛化泛化指出类之间的“一般与特殊关系”，即继承关系。父类与子类之间构成 类的分层结构 。
一般类 特殊 人员教师学生
5.4.2 UML中类之间的关系抽象类 指没有实例的类，定义一些抽象的操作，即不提供实现方法的操作，只提供操作的特征。并附以 {abstract}。
交叠泛化 在继承树中，若存在某种具有公共父类的多重继承，称为是交叠 (overlapping)的。否则是 不交 的 (disjoint)。
完全泛化 一般类特化出它所有的子类，称为完全泛化，记为 {complete}。
不完全泛化 即未特化出它所有的子类，称为是 不完全泛化的，表示为 {incomplete}.
有关泛化的约束
5.4.2 UML中类之间的关系三、泛化
{complete}
人女人男人性别图 3.34 完全泛化交通工具
drive()
汽车
drive()
轮船
drive()
drive()启动轮子转动
drive()启动螺旋浆
Person
驾驶
drive()是抽象操作图 3.35 泛化中的多态性及带识别名称的泛化
{propulsion} {propulsion}
{overlapping}
交通工具图 3.33 重叠泛化汽车 船水陆两栖车继承性的实例图 5.36 泛化关系图 形 {abstract}
颜 色中心位置笔的粗细移 动（）
旋 转（）
显 示（） {abstract}
2 维 {abstract}
定位填充类型缩放填充多边形边数顶点数显示园直径显示旋转线端点显示
0 维 {abstract}
点显示样条控制点显示弧半径起始角弧度角显示
1 维 {abstract}
定位缩放维数
5.4.2 UML中类之间的关系
5.4.2 UML中类之间的关系
OrderLine
Quantity:Integer
isSatisfied
1
*
1*
1*
Customer
name
address
CreditRating()
Order
dataReceived
isPrepaid
number:String
dispatch()
close() Personal Customer
creditCard
Corporate Customer
contactName
creditRating
creditLimit
remind()
billForMonth()
Employee
Product
0..1
+LineItem
图 5.37 泛化关系五、类图的抽象层次和细化 (Refinement)关系需要注意的是,虽然在软件开发的不同阶段都使用类图,
但这些类图表示了不同层次的抽象 。
在需求分析阶段,类图是研究领域的概念 ;在设计阶段,类图描述类与类之间的接口 ;
而在实现阶段,类图描述软件系统中类的实现 。
按照 Steve Cook和 John Dianiels的观点,类图分为三个层次,概念层,说明层,实现层 。
需要说明的是,这个观点同样也适合于其他任何模型,只是在类图中显得更为突出 。 描述了类图的抽象层次和细化
(Refinement)关系 。
5.4.2 UML中类之间的关系概念层概念层 (Conceptual)类图描述应用领域中的概念 。 实现它们的类可以从这些概念中得出,但两者并没有直接的映射关系 。 事实上,一个概念模型应独立于实现它的软件和程序设计语言 。
5.4.1 对象类与对象说明层说明层 (Specification)类图描述软件的接口部分,而不是软件的实现部分 。 面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这一差异 。 这主要是因为 OO语言中类的概念将接口与实现合在了一起 。 大多数方法由于受到语言的影响,也仿效了这一做法 。 现在这种情况正在发生变化 。 可以用一个类型 (Type )描述一个接口,这个接口可能因为实现环境,运行特性或者用户的不同而具有多种实现 。
实现层只有在实现层 (Implementation)才真正有类的概念,并且揭示软件的实现部分 。 这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流 。
理解以上层次对于画类图和读懂类图都是至关重要的 。
但是由于各层次之间没有一个清晰的界限,所以大多数建模者在画图时没能对其加以区分 。 画图时,要从一个清晰的层次观念出发 ;而读图时,则要弄清它是根据哪种层次观念来绘制的 。 要正确地理解类图,首先应正确地理解上述三种层次 。
虽然将类图分成三个层次的观点并不是 UML的组成部分,但是它们对于建模或者评价模型非常有用 。 尽管迄今为止人们似乎更强调实现层类图,但这三个层次都可应用于 UML,而且实际上另外两个层次的类图更有用 。
5.4.1 对象类与对象
5.4.3 包图一个最古老的软件方法问题是,怎样将大系统拆分成小系统 。 解决该问题的思路之一是将许多类集合成一个更高层次的单位,形成一个高内聚,低耦合的类的集合 。 UML中这种分组机制叫 包 (Package)。 引入包是为了降低系统的复杂性 。
包是一种组合机制,把各种各样的模型元素通过内在的语义连在一起成为一个整体就叫包,构成包的模型元素称为包的内容,包通常用于对模型的组织管理,因此有时又将包称为 子系统 （ subsystem） 。 包拥有自己的模型元素,包与包之间不能共用一个相同的模型元素,包的实例没有任何语义
（ 含义 ） 。 仅在模型执行期间包才有意义 。
5.4.3 包图图 3.32描述了包的表示及包之间的关系。
包的内容,可以是类的列表,也可以是另一个包图,还可以是一个类图 。
包之间的关系有依赖和泛化（继承）。
依赖关系,两个包中的任意两个类存在依赖关系,则包之间存在依赖关系 。 表示为：
泛化关系,使用继承中通用和特例的概念来说明通用包和专用包之间的关系。例如,专用包必须符合通用包的界面,与类继承关系类似。表示为：
5.4.3 包图包内容包名包名包 A
包 B
数据库界面
Oracle界面 Sybase界面
（ a）包的表示 (b)包的依赖关系 (c) 包的泛化关系图 5.38 包图包和类一样包也有可见性，利用可见性控制外部包对包的内容的存取方式,UML中定义了四种可见性：私有 (private)，
公有 (public)，保护 (protected)和实现 (implementation)。缺省值为公有。
包也可以有接口，接口与包之间用实线相连，接口通常由包的一个或多个类实现。
5.4.3 包图
X
类 P 类 S
A
B D
C
I
图 5.39 包图举例保险单填写界面系统内部保险单 客户数据库界面
（ abstract)
Oracle 界面
Sybasec界面包的继承包的依赖包
5.4.3 包图图 5.40 包图包图举例财务子系统数据库子系统数据库操作 数据库接口
Oracle 接口 Sybasec接口
5.4.3 包图图 5.41 包图举例
5.5 动态建模
9.5动态模型5.5 UML动态建模简单消息 (simple)
异步消息 (asynchronous)
同步消息 (synchronous)
图 5.42
动态模型主要描述系统的动态行为和控制结构。 动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了为满足用例要求所进行的活动以及活动间的约束关系。
在动态模型中,对象间的交互是通过对象间消息的传递来完成的 。 对象通过相互间的通信 (消息传递 )进行合作,并在其生命周期中根据通信的结果不断改变自身的状态 。
UML消息的图形表示是用带有箭头的线段。
动态模型状态图 (state diagram),状态图用来描述对象，子系统，
系统的生命周期。
活动图 (activity diagram),着重描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种。
顺序图 (sequence diagram),是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。
合作图 (collaboration diagram),用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。
9.5动态模型5.5 UML动态建模动态模型主要描述系统的动态行为和控制结构。包括 4
类图,状态图、活动图、顺序图、合作图。
UML中的消息一、简单消息 (simple)
表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节。
二,同步消息 (synchronous)
是一种嵌套 的控制流，用操作调用实现。操作的执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行。
三,异步消息 (asynchronous)
是一种异步 的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理。
5.5 UML动态建模消 息在面向对象技术中,对象间的交互是通过对象间 消息 的传递来完成的 。 在 UML中,消息的图形表示是用带有箭头的线段将消息的发送者和接收者联系起来,箭头的类型表示消息的类型 。
UML定义的消息类型有三种,
简单消息 (Simple Message) 表示简单的控制流 。
同步消息 (Synchronous Message) 表示嵌套的控制流 。
操作的调用是一种典型的同步消息 。
异步消息 (Asynchronous Message) 表示异步控制流 。 当调用者发出消息后不用等待消息的返回即可继续执行自己的操作 。 异步消息主要用于描述实时系统中的并发行为 。
5.5.3 顺序图简单消息同步消息异步消息
5.5.1 状态图状态图 (State Diagram)用来描述一个特定对象的所有可能的状态及其引起状态转移的事件 。 一个状态图包括一系列的状态以及状态之间的转移 。
状态 所有对象都具有状态,状态是对象执行了一系列活动的结果 。 当某个事件发生后,对象的状态将发生变化 。 状态图中定义的状态有,
5.5.1 状态图初态 —状态图的起始点,一个状态图只能有一个初态 。
终态 —是状态图的终点 。 而终态则可以有多个 。
中间状态 —可包括三个区域,名字域,状态变量与活动域 。
复合状态 —可以进一步细化的状态称作复合状态 。
中间态初态终态状态名状态变量活动响应事件的内部动作或活动的列表，定义为：
事件名 (参数表 [条件 ])/动作表达式状态变量 是状态图所显示的类的属性。
活动 列出了在该状态时要执行的事件和动作。有 3个 标准事件：
entry事件用于指明进入该状态时的特定动作。
exit事件用于指明退出该状态时的特定动作。
do事件用于指明在该状态中时执行的动作。
例,
无参数
5.5.1 状态图迁移图 5.43 login 状态
login
login time=curent time
entry/type ―login‖
do/get use name
do/get password
help/display help
exit/login(use_name.password)
5.5.1 状态图状态 迁移 一个对象的状态的变迁称为状态迁移 。 通常是由事件触发的,此时应标出触发转移的事件表达式 。 如果转移上未标明事件,则表示在源状态的内部活动执行完毕后自动触发转移 。
状态图在第一层 上行 向上移动到达 上行空闲到达向下移动下行超时向第一层移动到达图 5.44 电梯状态图
5.5.1 状态图图 5.45 或关系的子状态嵌套 状态 图状态图可能有嵌套的子状态图,且子状态图可以是另一个状态图 。 子状态又可分为两种：,与,子状态和,或,子状态,
图 5.46 与子状态及或子状态状态图前进 后退低速 高速运行向前 向后行使细化的状态表示
UML给出了电梯细化的状态表示 (图 5.47)。
状态名状态变量活动图 5.47 细化电梯状态图
On
first floor
Go up
(floor) Moving up
do/moving
to floor
Go up
(floor)
Idle
timer=0
do/increase timer
arrivedMoving down
do/moving to
floor
Go down (floor)
timer= timer-out
Moving to
first floor
arrived
arrived
5.5.1 状态图事件
5.5.1 状态图事件是激发状态迁移的条件或操作 。
在 UML中,有 4类事件：
1、某条件变为真；表示状态迁移的上的警戒条件。
2、收到来自外部对象的信号 (signal) 表示为状态迁移上的事件特征，也称为 消息。
3、收到来自外部对象的某个操作中的一个调用,表示为状态迁移上的事件特征，也称为 消息。
４,状态迁移上的时间表达式。
状态图之间的消息发送状态图之间可以发送消息，用虚箭头表示。
图 5.48 消息发送状态图
on/stopoff on/play
off( )
on( ) play( )
stop( )
off( )/stop( )
CD player
Remote Control
off on
on( )
off( )
stop( )play( )
stop( )play( )
off( )on( )
5.5.1 状态图顺序图存在两个轴,水平轴表示一组对象,垂直轴表示时间 。
顺序图中的对象用一个带有垂直虚线的矩形框表示,并标有对象名和类名 。 垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的 。
对象间的通信通过在对象的生命线之 间消息来表示,消息的箭头类型指明消息的类型 。
5.5.2 顺序图顺序图 (Sequence Diagram)用来描述对象之间动态的交互行为,着重体现对象间 消息传递的时间顺序 。
对象图
5.5.3 顺序图一,概述简单消息 (simple)
异步消息 (asynchronous)
同步消息 (synchronous)
当收到消息时,接收对象立即开始执行活动,即对象被激活了,通过在对象生命线上显示一个细长矩形框来表示激活 。
5.5.3 顺序图二,消息控制信息 {条件控制信息 如,［ ｘ＞０］重复控制信息 如：＊ ［ Ｉ＝ 1..n］
简单消息 (simple),表示消息类型不确定或与类型无关 。
或者是一同步消息的返回消息 。
同步消息 (synchronous),表示发送对象必须等待接收对象完成消息处理后,才能继续执行 。
异步消息 (asynchronous),表示发送对象在消息发送后,
不必等待消息处理后,可立即继续执行 。
消息 延迟,用倾斜箭头表示 。
消息串,包括消息和控制信号,控制信息位于信息串的前部 。
5.5.2 顺序图有两种使用顺序图的方式：一般格式和实例格式 。
实例格式详细描述一次可能的交互 。 没有任何条件和分支或循环,它仅仅显示选定情节 （ 场景 ） 的交互 （ 图 5.49） 。
而一般格式则描述所有的情节 。 因此,包括了分支,条件和循环 。
三,顺序图的形式
:Customer Win,Customer
1:Chang Customer data） 2:Update Customer(CustomerData)
3:
图 5.49 顺序图
:Computer,Printer Server,Printer,QueuePrint(file)
[Printer free]
Print(file)
[Printer busy]
Store(file)
图 5.50 带分支的顺序图
:C1:c,D1:D,D2:DOp( )
Op2( )
Op3( ) Op4( )
图 5.51 有循环标记的顺序图
Send message op2
until…
5.5.3 顺序图呼叫者 交换 接受者拿起话筒响拨号声拨号码路由选择鸣响音停音响铃声接电话停铃声
A
B
C
D
E
{B-A<1S}
{C-B<10S}
通过网络选择通话路径
{E-D<5S}
双方通话图 5.52 打电话的顺序图
5.5.3 顺序图创建对象与对象的消亡在顺序图中，还可以描述一个对象通过发送一条消息来创建另一个对象。
当对象消亡 (destroying)时，用符号? 表示。
,Customer WindowsNewCustomer(Data)
,CustomerCustomer(Data)
DeleteCustomer()
5.5.2 顺序图图 5.53 创建或删除对象活动图 (Activity Diagram)的应用非常广泛,它既可用来描述操作 (类的方法 )的行为,也可以描述用例和对象内部的工作过程,并可用于表示并行过程 。
活动图是由状态图变化而来的,它们各自用于不同的目的 。
活动图描述了系统中各种活动的 执行的顺序 。 刻化一个方法中所要进行的各项活动的执行流程 。
活动图中一个活动结束后将立即进入下一个活动 (在状态图中状态的变迁可能需要事件的触发 )。
5.5.3 活动图
5.5.3 活动图一、概述二、活动图的模型元素
5.5.3 活动图构成活动图的模型元素有：活动、转移、对象、信号、
泳道等。
１、活动是构成活动图的核心元素，是具有内部动作的状态，由隐含的事件触发活动的转移。
活动的解释依赖于作图的目的和抽象层次，在概念层描述中，活动表示要完成的一些任务；在说明层和实现层中，
活动表示类中的方法。
活动用圆角框表示，标注活动名。
活动名
[条件 1]
[条件 2]
图 5.54 活动二、活动图的模型元素活动还有其它的图符：初态、终态、判断、同步。
初态终态
[条件 1]
[条件 2]
判断 同步线图 5.55 活动
2、转移转移描述活动之间的关系，描述由于隐含事件引起的活动变迁，即转移可以连接各活动及特殊活动（初态、终态、
判断、同步线）。
转移用带箭头的直线表示，可标注执行该转移的条件，
无标注表示顺序执行。
5.5.2 活动图 活动图的模型元素：
图 5,56 泳道
3,泳道泳道进一步描述完成活动的对象，并聚合一组活动。活动图是另一种描述交互的方式，描述采取何种动作，做什么
（对象状态改变），何时发生（动作序列），以及在何处发生（泳道）。
泳道也是一种分组机制。
顾 客 售 货 库 房
●
请求服务支付取货提货开订单供货
５,控制图符活动图中可发送和接收信号，发送符号对应于与转移联系在一起的发送短句。接收符号也同转移联系在一起。
发送信号 接收信号
４,对象流活动图中可以出现对象，对象作为活动的输入／输出，用虚箭头表示。
测量测量值显示图 5.59 控制图符图 5.57 对象流开机器开动调制咖啡信号灯灭倒咖啡咖啡壶图 5.58 控制图符例
5.5.2 活动图活动图１
１,活动图中只有一个起点一个终点,表示方式和状态图一样,泳道被用来组合活动,通常根据活动的功能来组合 。
具体说泳道有如下目的：直接显示动作在哪一个对象中执行,
或显示的是一项组织工作的哪部分 。 泳道用纵向矩形来表示,
如图 5.60。
Displayer Sampler
Sampler.Run
(channel,frequency)
更新显示初始化测量
5.5.2 活动图三、活动图举例图 5.60 泳道
２,活动图中可发送和接收信号,发送符号对应于与转移联系在一起的发送短句 。 接收符号也同转移联系在一起 。 转移又分两种：发送信号的转移和接收信号的转移 。 发送和接收信号可以和消息的的发送对象和接收对象联系在一起,如图 5.61。
aPrinter:Printer
Print(file) Print(file)
打印创建 PS文件在屏幕上的报文框中显示“打印”
删除报文框图 5.61
CustomerWindow.
PrintAll
Customers()
5.5.2 活动图图 5.62 活动图举例
5.5.2 活动图合作图 (Collaboration Diagram),也称为协作图,用于描述相互合作的对象间的交互关系和链接 (Link)关系 。 虽然顺序图和合作图都用来描述对象间的交互关系,但侧重点不一样 。
顺序图着重体现交互的时间顺序,合作图则着重体现交互对象间的静态链接关系 。
5.5.4 合作图
5.5.4 合作图一,合作图中的模型元素合作图中对象的外观与顺序图中的一样 。 如果一个对象在消息的交互中被创建,则可在对象名称之后标以 {new}。 类似地,如果一个对象在交互期间被删除,则可在对象名称之后标以 {destroy}。
1、对象对象名 {new} 对象名 {destroy}
5.5.4 合作图
2,链接 (Link)
链接用于表示对象间的各种关系,包括 组成关系的链接
(Composition Link),聚集关系的链接 (Aggregation Link)、
限定关系的链接 (Qualified Link)以及 导航链接 (Navigation
Link)。 各种链接关系与类图中的定义相同,在链接的端点位臵可以显示对象的角色名和模板信息 。
对象Ａ
对象Ａ
对象Ｃ
对象Ｄ
对象Ｇ
对象Ｈ
对象Ｅ
对象Ｆ
限定词图 5.63 各种关系的链接对于 链接还可以加上,角色,与,约束,,在链角色上附加的约束有 global(全局 ),local(局部 ),parameter(参数 )，
self(自身 ),broadcast(广播 )。
３,消息在对象之间的静态链接关系上可标注消息,消息类型有简单消息,同步消息和异步消息三种 。 用标号表示消息执行的顺序 。 消息定义的格式如下：
消息类型 标号 控制信息：返回值,=消息名 参数表
5.5.4 合作图控制信息 {条件控制信息 如,［ ｘ＞ｙ］重复控制信息 如：＊ ［ Ｉ＝ 1..n］
标号有３种：
顺序执行：按整数大小执行。 １,２ …
嵌套执行：标号中带小数点。 1.1,1.2,1.3,…
并行执行,标号中带小写字母。 1.1.1a,1.1.1b,…
Predecessor guard-condition sequence-expression return-value:=signature
1.1*[i:= 1..n],drawsegment(i)
:控制器,窗口
:直线 {new}:布线
i-1 i
左,端点 右,端点
,参数,窗口
,局部,直线 内容 {new}
窗口
,自授,1.1.2 Create(r0,r1)
1.1.3 display(window)
1.1.1b:r1:=position()1.1.1a:r0:=position()
1,displaypositions(window) 1.1.3.1 add(self)
Redisplay()
5.5.4 合作图图 5.64 电路设计的合作图在控制器控制下进行布线，找出左端点 r0和右端点 r1，创建对象“直线”，并在窗口显示出来。
布线
5.5.4 合作图下图为一销售结果统计的合作图 。
图 5.65 统计销售结果的合作图
:Sales Statistics
Window
:Statistics
Summary
{new}
:Order
:Budget Sales
1:Show ( ) 1.1:Create( )
1.2*[while any
Lines left]
Get Rerultline( )
1.1.2*[for all
Sales persons]:
Budget=Get Budget
1.1.2.1:
Get Budget
Amount()
1.1.1.1*[for all
Orders]:Get
OrderAmount( )
:Sales Person
1.1.1*[for all SaiesPerson]:
Ordersum=GetTotalOrders( )
关于 顺序图与 合作图
１,顺序图与 合作图都是交互图，它们有何不同？所描述的主要系统特征是什么？
２,顺序图与 合作图各适合于在哪类系统中使用？
关于 状态图与 活动图
１,状态图与 活动图有何相同与不同之处？
２、在建立系统模型时，应该如何使用这两类模型？
5.6 实现模型实现模型 描述了系统实现时的一些特性，又称为 物理体系结构建模 。包括源代码的静态结构和运行时刻的实现结构。实现模型包括：
构件图 (Component diagram) 显示代码本身的逻辑结构,它描述系统中存在的软构件以及它们之间的依赖关系 。 构件图的元素有构件,依赖关系和界面 。
配臵图 (Deployment diagram)描述了系统中硬件和软件的物理配臵情况和系统体系结构。显示系统运行时刻的结构，配臵图中的简单结点是指实际的物理设备以及在该结点上运行构件或对象。配臵图还描述结点之间的连接以及通信类型。
5.6 实现模型构件（ component）
构件定义,系统中遵从一组接口且提供其实现的物理的、可替换的部分。对系统的物理方面建模时，它是一个重要的构造块。
构件的名称和类的名称的命名法则很是相似，有简单名和路径名之分。
构件的描述如上图所示。
若构件的定义良好，该构件不直接依赖于构件的所支持的接口，在这种情况下，系统中的一个构件可以被支持正确接口的其他构件所替代。构件图符是一个矩形框（图 5.66）。
构件对外提供的可见操作和属性称为构件的界面。 界面的图符是一个小圆圈。用一条连线将构件与圆圈连起来。
5.6.1 构件图
5.6.1 构件图图形库
(graphic.dll)
图 5.66
5.6.1 构件图构件可以看作包与类对应的物理代码模块,逻辑上与包,类对应,实际上是一个文件,可以有下列几种类型的构件：
1） 源代码构件；
2） 二进制构件；
3） 可执行构件构件图符是一个矩形框 。
构件对外提供的可见操作和属性称为构件的界面 。
界面的图符是一个小圆圈 。 用一条连线将构件与圆圈连起来 。
构件之间的依赖关系是指结构之间在编译,连接或执行时的依赖关系 。 用虚线箭头表示 。
5.6.1 构件图图 5.67
5.6.1 构件图窗口控制
（ whnd.cpp）
通信控制
(comhnd.cpp)
主控模块
(main.cpp)
窗口控制
(whnd.obj)
通讯控制
(comhnd.obj)
主控模块
(main.obj)
图形库
(graphic.dll)
客户程序
(client.exe)
构件图实例构件关系
Circle.obj类
Circle.cpp
Main类
Main.obj
Main类
Main.cpp
图形库
Graphic.dll
Square类
Square.cpp
Square类
Square.objCircle类Circle.obj
可执行程序
Main.exe
图 5.68
5.6.1 构件图
开发期的依赖 (Development –time Dependency)
是指在编译阶段和连接阶段，组件之间的依赖关系。
调用依赖 (Call Dependency)
是指一个组件调用或使用另外一个组件服务。
组件的依赖关系又分为：开发期的依赖和调用依赖。
业 务
（源码）
项目管理
（源码）
项目管理
（对象）
项目管理
（执行码）
系统管理
（源码）
资源 管理
（源码）
资源 管理
（对象）
资源 管理
（执行码）
系统管理
（对象）
系统 管理
（执行码）
图 5.69
5.6.1 构件图
5.6.2 配置图配臵图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件,即系统运行时的刻的结构 。 配臵图可以显示计算机结点的拓扑结构和通信路径,结点上执行的软构件,
软构件包含的逻辑单元等,特别对于分布式系统,配臵图可以清楚的描述系统中硬件设备的配臵,通信以及在各硬件设备上各种软构件和对象的配臵 。 因此,配臵图是描述任何基于计算机的应用系统的物理配臵或逻辑配臵的有力工具,配臵图的元素有结点和连接 。
配臵图中的结点代表某种计算机构件,通常是某种硬件 。
同时结点还包括在其上运行的软构件,软构件代表可执行的物理代码模块 。 如一个可执行程序 。 结点的图符是一个立方体 。
5.6.2 配置图图 5.70
保险单填写界面保险系统保险数据库保险政策保险用户客户 PC,TCP/IP>
保险服务器保险系统配置配置保险系统的配置图
5.6.2 配置图配臵图各结点之间进行交互的通信路径称为连接，连接表示系统中的结点存在着联系，用结点之间的的连线表示连接，
在连接的连线上要标注通信类型。如图 5.70.
医院诊疗系统的配臵图图 5.71 医院诊疗系统的配置图 (C/S)
:Object
Database
:Health Care
Domain
Database Unit Server
（数据库服务器）
a Windows PC（客户机）
:Object
Database
:Health Care
Domain
Heart Unit Server（ 心血管病服务器 ）
:Configure
Knowledge
:Configure users
Heart Unit Configuration
,Communication,
TCP/IP
TCP/IP
:Heart Unit UI
:Heart Unit
Client Facade
:Heart Unit
Server
Application
5.6.2 配置图面向对象建模是软件工程中最重要的技术之一,
UML已成为面向对象建模事实上的标准 。
标准建模语言 UML定义良好,易于表达,功能强大,
不仅支持面向对象的分析与设计,而且支持从需求分析开始的软件开发的全过程 。 但如何恰当地将这种可视化图形建模技术用于解决软件开发所面临的问题,如何研制和开发支持 UML的建模过程及其支持环境,仍是目前该领域的热点问题 。
目前,在基于 UML的开发方法和环境方面,国际上已经进行了一些研究和实际开发工作 。 Rational 公司正致力于它称之为 Objectory过程的研究,并试图将其原有支持
OMT的工具作进一步扩充,以期支持 UML建模 。 国内对 UML
支持 环境的研制开发工作尚处于起步阶段 。
小 结小 结
