软件工程第5章UML建模语言

UML建模语言第五章

软件工程领域在1995年至1997年取得了前所未有的进展,其成果超过软件工程领域1995年之前15年的成就总和。其中最重要的、具有划时代重大意义的成果之一就是统一建模语言—UML(UnifiedModelingLanguage)的出现。在世界范围内,至少在近10年内，UML将是面向对象技术领域内占主导地位的标准建模语言。概述

5.1UML概述

UML（UnifiedModelingLanguage）是软件界第一个统一的建模语言，该方法结合了Booch,OMT,和OOSE方法的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术。

它是一种标准的表示,已成为国际软件界广泛承认的标准。是一种基于面向对象的可视化的通用(General)建模语言。为不同领域的用户提供了统一的交流标准—UML图。

UML应用领域很广泛，可用于软件开发建模的各个阶段，商业建模（BusinessModeling）,也可用于其它类型的系统。模型是对系统的完整的抽象表示，建模是在不同层次上对系统的描述。面向对象建模的基本概念1.什么是模型？人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴涵在模型中。通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。2.为什么要建模？领域问题概念模型分析、抽取系统需求解决方案分析、设计提取

UML作为一种可视化的建模语言，提供了丰富的基于面向对象概念的模型元素及其图形表示元素。鉴于软件系统的复杂性和规模的不断增大，需要建立不同的模型对系统的各个层次进行描述。软件模型包括:数学模型、描述模型和图形模型。便于开发人员与用户的交流。模型为以后的系统维护和升级提供了文档。建模过程:九十年代中，面向对象方法已经成为软件分析和设计方法的主流。1994年10月JimRumbaugh和GradyBooch共同合作把他们的OMT和Booch方法统一起来，到1995年成为“统一方法”（UnifiedMethod）版本0.8。随后，IvarJacobson加入，并采用他的用例(Usercase)思想,到1996年，成为“统一建模语言”版本0.9。1997年1月，UML版本1.0被提交给OMG(ObjectManagementGroup)组织，作为软件建模语言标准的候选。其后的半年多时间里，一些重要的软件开发商和系统集成商都成为“UML伙伴”，如IBM,Mircrosoft,HP等.1997年11月7日被正式采纳作为业界标准。5.1.1UML的形成<documents>UML2.0<documents>UML1.2<documents>UML1.1<documents>UML1.0<documents>UML0.9<documents>UnifiedMethod0.8<documents>UML1.3<documents>UML1.41995文档版类1996精华相关1997年1月最初提交给

OMG1997年9月最后提交给OMG19981999

2000年(计划的较小修订)

2001年计划的重要修订文字上的修改没有显著的技术变化UML形成

(1)统一标准

UML统一了Booch、OMT和OOSE等方法中的基本概念，已成为OMG的正式标准，提供了标准的面向对象的模型元素的定义和表示。

(2)面向对象

UML还吸取了面向对象技术领域中其它流派的精华。删除了大量易引起混乱的、多余的和极少使用的符号,也添加了一些新符号。

(3)可视化、表示能力强系统的逻辑模型或实现模型都能用UML模型清晰的表示，可用于复杂软件系统的建模。

(4)易掌握、易用

UML的概念明确，建模表示法简洁明了，图形结构清晰，易于掌握使用。5.1.2UML的特点5.1.3UML的主要内容

UML的定义包括UML语义和UML表示法两个部分。(1)UML语义描述基于UML的精确元模型(meta-model)定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的表达方法所造成的影响。此外UML还支持对元模型的扩展定义。

UML支持各种类型的语义。如布尔、表达式、列表、阶、名字、坐标、字符串和时间等，还允许用户自定义类型。(2)UML表示法定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。UML表示法由通用表示和图形表示两部分组成。通用表示包括：字符串：表示有关模型的信息。名字：表示模型元素。标号：赋予图形符号的字符串。特定字串：赋予图形符号的特性。类型表达式：声明属性变量及参数。定制：是一种用已有的模型元素来定义新模型元素的机制。UML是一种标准化的图形建模语言，它是面向对象分析与设计的一种标准表示。由:

视图(views),

图(Diagrams),

模型元素(Modelelements)

通用机制(generalmechanism)等几个部分构成。

UML的图形表示：UML的主要内容一个系统应从不同的角度进行描述,从一个角度观察到的系统称为一个视图（view）。视图由多个图（Diagrams）构成，它不是一个图表（Graph）,而是在某一个抽象层上，对系统的抽象表示。如果要为系统建立一个完整的模型图，需定义一定数量的视图，每个视图表示系统的一个特殊的方面。另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。视图(views)设计视图实现视图配置视图过程视图Usecase视图UsecaseView描述系统的外部特性、系统功能等。ImplementationView

表示系统的实现特征，常用构件图表示。DesignView

描述系统设计特征，包括结构模型视图和行为模型视图，前者描述系统的静态结构(类图、对象图)，后者描述系统的动态行为(交互图、状态图、活动图)。ProcessView

表示系统内部的控制机制。常用类图描述过程结构，用交互图描述过程行为。DeploymentView

配置视图描述系统的物理配置特征。用配置图表示。UML常用视图UML语言定义了五种类型，9种不同的图，把它们有机的结合起来就可以描述系统的所有视图。用例图(Usecasediagram)

从用户角度描述系统功能,并指出各功能的操作者。静态图(Staticdiagram),表示系统的静态结构。包括类图、对象图、包图。行为图(Behaviordiagram)，描述系统的动态模型和组成对象间的交互关系。包括状态图、活动图。交互图(Interactivediagram),描述对象间的交互关系。包括顺序图、合作图。实现图(Implementationdiagram)用于描述系统的物理实现。包括构件图、部件图。

图(Diagrams)图通用机制(generalmechanism)

用于表示其他信息，比如注释，模型元素的语义等。另外，为了适应用户的需求，它还提供了扩展机制(Extensibilitymechanisms)

，包括构造型(Stereotype)、标记值(Taggedvalue)和约束(Constraint).使用UML语言能够适应一个特殊的方法（或过程），或扩充至一个组织或用户。模型元素(Modelelements)代表面向对象中的类，对象，关系和消息等概念，是构成图的最基本的常用的元素。一个模型元素可以用于多个不同的图中。5.2通用模型元素

模型元素是UML构造系统的各种元素，是UML构建模型的基本单位。分为以下两类：1.基元素是由UML定义的模型元素。如：类、结点、构件、注释、关联、依赖和泛化等。2.构造型元素在基元素的基础上增加了新的定义而构造的新的模型元素。如扩展基元素的语义（不能扩展语法结构）,也允许用户自定义。构造型元素用括在双尖括号<<>>中的字符串表示。目前UML提供了40多个预定义的构造型元素。如包含<<include>>、扩展<<Extend

>>。模型元素

关联：连接（connect）模型元素及链接(link)实例。

依赖：表示一个元素以某种方式依赖于另一种元素。

泛化：表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化。

聚合：表示整体与部分的关系。连接关系关联组合聚合依赖细化泛化（继承）模型元素与模型元素之间的连接关系也是模型元素，常见的关系有关联（association）、泛化（generalization）、依赖(dependency)和聚合(aggregation)，其中聚合是关联的一种特殊形式。这些关系的图示符号如图所示。5.2.1常用模型元素常用的模型元素

可以在图中使用的概念统称为模型元素。模型元素在图中用其相应的视图元素（符号）表示，图中给出了常用的元素符号：类、对象、结点、包和组件等。用例包结点状态组件属性类操作对象属性操作接口注释

关联（association）是两个或多个类之间的一个关系。链（link)是关联的具体体现。5.2.2关联和链

关联的表示

关联分为二元关联(binary)、三元关联(ternary)、多元关联(higherorder)。关联（a）二元关联人员公司雇用二元关联的例（人员）张涛（公司）通大雇用链的例子（b）三元关联项目语言◆人三元关联的例(项目)CAD系统(语言)C++◆(人)李波链的例子5.2.3关联的表示关联的重数 重数(multiplicity)表示多少个对象与对方对象相连接，常用的重数符号有：“0..1”表示零或1“0..*”或“*”表示零或多个“1..*”表示1或多个“1,3,7”表示1或3或7（枚举型）重数的默认值为1。PersonHobby1*CommitteePersonYear◆0..21..43..5Post带有多重性关联有序关联与导航（导引）

在关联的多端标注{ordered}指明这些对象是有序的。关联可以用箭头，表示该关联使用的方向(单向或双向)，称为导引或导航(navigation)。有序关联与导航(a)指定链接之间有明确的顺序0..*1..*{ordered}保险合同个人PolygonPoint14..*{ordered}(b)单向关联

受限关联(qualifiedassociation)

使用限定词对该关联的另一端的对象进行明确的标识和鉴别,如图。如果对关联的含义作出某种限制，称为受限关联。受限关联类A类B限定词目录文件文件名

受限关联的表示受限关联的例5.2.4约束

UML中提供了一种简便、统一和一致的约束（constraint），是各种模型元素的一种语义条件或限制。一条约束只能应用于同一类的元素。约束的表示如果约束应用于一种具有相应视图元素的模型元素，它可以出现在它所约束元素视图元素的旁边。通常一个约束由一对花括号括起来（{constraint}），花括号中为约束内容,如图。如果一条约束涉及同一种类的多个元素，则要用虚线把所有受约束的元素框起来，并把该约束显示在旁边（如或约束）。PolygonPoint14..*{ordered}约束0..*1..*{ordered}保险合同个人约束对泛化的约束的两种表示方法约束可分为：对泛化的约束、关联的约束

对泛化的约束应用于泛化的约束，显示在大括号里，若有多个约束，用逗号隔开。如果没有共享，则用一条虚线通过所有继承线，并在虚线的旁边显示约束，如图所示的两种表示法是等价的。{constraint1,constraint2}ClassAClassBClassCClassD{constraint1,constraint2}ClassAClassCClassBClassD

对泛化有以下常用的约束：

1.complete:

说明泛化中所有子元素都已在模型中说明，不允许再增加其它子元素。

2.disjoint:

父类对象不能有多于一个型的子对象。

3.incomplete:

说明不是泛化中所有子元素都已说明，允许再增加其它子元素。

4.overlapping:

给定父类对象可有多于一个型的子对象，表示重载。

返回对消息，链接角色和对象的约束

自定义约束

帐号人单位{xor}对象类的xor关联

关联的约束 对关联有以下常用的约束：

1.implicit:该关联只是概念性的,在对模型进行精化时不再用。

2.ordered:具有多重性的关联一端的对象是有序的。

3.changeable:关联对象之间的链(Link)是可变的（添加、修改、删除）。

4.addonly:可在任意时刻增加新的链接。

5.frozen:冻结已创建的对象,不能再添加、删除和修改它的链接。

6.xor:“或约束”，某时刻只有一个当前的关联实例。

依赖关系描述的是两个模型元素（类，组合，用例等）之间的语义上的连接关系，其中一个模型元素是独立的，另一个模型元素是非独立的（或依赖的）。如图表示类A依赖于类B的一个友元依赖关系。

类A类B《友元》5.2.6依赖友元依赖关系依赖的形式可能是多样的，针对不同的依赖的形式，依赖关系有不同的变体(varieties)：

依赖的形式可能是多样的，针对不同的依赖的形式，依赖关系有不同的变体(varieties)：

<1>抽象(abstraction)：从一个对象中提取一些特性，并用类方法表示。

<2>绑定(binding)：为模板参数指定值，以定义一个新的模板元素。

<3>组合(combination)：对不同类或包进行性质相似融合。

<4>许可(permission)：允许另一个对象对本对象的访问。

<5>使用(usage)：声明使用一个模型元素需要用到已存在的另一个模型元素，这样才能正确实现使用者的功能(包括调用、实例化、参数、发送)。

<6>跟踪(trace)：声明不同模型中元素的之间的存在一些连接。

<7>访问或连接(access)：允许一个包访问另一个包的内容。

<8>调用(call)：声明一个类调用其他类的操作的方法。

<9>导出(derive)：声明一个实例可从另一个实例导出。

<10>友元(friend)：允许一个元素访问另一个元素，不管被访问的元素是否具有可见性。

<11>引入(import)：允许一个包访问另一个包的内容并被访问组成部分增加别名。

<12>实例(instantiation)：关于一个类的方法创建了另一个类的实例声明。

<13>参数(parameter)：一个操作和它参数之间的关系。

<14>实现(realize)：说明和其实之间的关系。

<15>精化(refine)：声明具有两个不同语义层次上的元素之间的映射。

<16>发送(send)：信号发送者和信号接收者之间的关系。这是一个类人员注释

有两个元素A和B，若B元素是A元素的详细描述，则称为B元素细化A元素。 细化与类的抽象层次有密切的关系，在构造模型时要经过逐步细化,逐步求精的过程。5.2.7细化AB细化5.2.8注释

注释用于对UML语言的元素或实体进行说明，解释和描述。通常用自然语言进行注释。5.3用例建模

1992年由Jacobson提出了Usecase的概念及可视化的表示方法—Usecase图，并加入由他所倡导的OOSE。受到了IT界的欢迎，被广泛应用到了面向对象的系统分析中。用例驱动的系统分析与设计方法已成为面向对象的系统分析与设计方法的主流。

UML的用例模型一直被推荐为识别和捕获需求的首选工具!!

用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析，使开发者能够有效地了解用户的需求。5.3.1用例建模概述网络中间层状态包检测防火墙系统开/关防火墙防火墙规则表管理基于历史状态的包处理网卡驱动程序(NICDriver)防火墙规则管理员TCP/IP协议栈(TCPIP.SYS)<<use>>5.3.2用例模型(Usecasemodel)

用例模型描述外部执行者(Actor)所理解的系统功能。即待开发系统的功能需求。它驱动了需求分析之后各阶段的开发工作,还被用于验证和检测所开发的系统,影响了UML

的各个模型。用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。创建用例模型的工作包括：

定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。

如何建立用例模型

建立系统用例模型的过程就是对系统进行功能需求分析的过程。定义系统确定执行者和用例描述执行者和用例关系确认模型●确定系统范围；●分析系统功能。

●执行者通常是使用系统功能的外部用户或系统。●用例是一个子系统或系统的一个独立、完整功能。各模型元素之间有：关联、使用、扩展及泛化等关系。确认用例模型与用户需求的一致性，通常由用户与开发者共同完成。一、确定执行者(Actor)执行者是指用户在系统中所扮演的角色,执行者用类似人的图形来表示,但执行者可以是人，也可以是一个外界系统。如何确定执行者：1、谁使用系统的主要功能(主执行者)?2、谁需要从系统获得对日常工作的支持和服务？3、需要谁维护管理系统的日常运行（副执行者）？4、系统需要控制哪些硬件设备？5、系统需要与其它哪些系统交互？6、谁需要使用系统产生的结果（值)？一、执行者供货买饮料取货款客户供货人收银员自动售货系统回例1二、用例如何确定用例：1、与系统实现有关的主要问题是什么？2、系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？3、执行者需要系统提供哪些功能？4、执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？二、用例回例1二、用例二、用例(usecase)

从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能）。用例有以下特点:用例实现一个具体的用户目标。用例由执行者激活,并将结果值反馈给执行者。用例必须具有功能上的完整描述。二、用例三、用例之间的关系

执行者与用例之间通常是一种关联。用例之间的联系：<<Use>>表示一个用例使用另一个用例。<<Extend>>通过向被扩展的用例添加动作来扩展用例。<<include>>表示一个用例的行为包含了另一个用例的行为。售货供货取货款顾客供货人收银员售散装饮料打开机器关闭机器打开机器关闭机器<<扩展>><<使用>><<使用>><<使用>><<使用>>自动售货机系统含有使用和扩展关系的用例图其中:<<Use>>,<<Extend>>是一种泛化关系。

<<include>>是一种依赖关系。5.3.3用例图实例例1建立项目与资源管理系统的Usecase图

系统的主要功能是：包括项目管理，资源管理和系统管理三大管理功能。

1.项目管理包括项目的增加、删除、更新。

2.资源管理包括对资源和技能的添加、删除和更新。

3.系统管理包括系统的启动和关闭，数据的存储和备份等功能。说明：技能表示人力资源。1.分析确定系统的执行者(角色)到确定到确定

项目管理员、资源管理员、系统管理员、备份数据系统。项目管理，资源管理和系统管理。2.确定用例3.对用例进行分解，画出下层的Usecase图角色：角色职责：角色职责识别：角色描述模板

还应画出相应的执行者描述模板及用例描述模板。

对上层的用例进行分解,并将执行者分配到各层次的Usecase图中。用例名：功能描述：主要步骤：相关用例：相关信息：(优先级性能,频度…)用例描述模板例1项目与资源管理系统（PRMS）添加技能删除技能更新技能资源管理员添加资源删除资源更新资源查找技能<<Use>>查找资源<<Use>><<Use>><<Use>>把技能指定给资源从资源中清除技能<<Extend>><<Extend>>资源管理UseCase图

UseCase图可以自顶而下不断精化，抽象出不同层次的UseCase图。系统管理员项目管理员资源管理员资源管理项目管理系统管理备份系统PRMS高层UseCase图注：这里的“技能”是指人力资源。例1项目与资源管理系统（PRMS）项目管理员添加项目删除项目更新项目添加活动删除活动更新活动查找项目<<Use>>添加任务<<Use>>分配资源给任务取消对任务的资源分配<<Extend>><<Extend>>删除任务更新任务<<Extend>><<Extend>><<Extend>><<Extend>><<Extend>><<Extend>>项目管理UseCase图系统管理UseCase图系统管理员添加技能存储数据启动系统关闭系统查找技能<<Use>><<Use>><<Use>>备份资源数据备份项目数据<<Extend>><<Extend>><<Use>>备份数据备份系统应用举例

例2—医院病房监护系统一、问题描述

为了对危重病人进行实时监护，随时了解病人病情，及时进行处理，建立病房监护系统。

病症监视器安置在每个病床，通过网络将病人的病症信号（组合）实时传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。系统根据医生的要求随时打印病人的病情报告，系统定期自动更新病历。请对系统需求进行分析！经过初步的需求分析，得到系统功能要求：1.监视病员的病症（血压、体温、脉搏等）2.定时更新病历3.病员出现异常情况时报警。4.随机地产生某一病员的病情报告。

例2医院病房监护系统产生病情报告监视病情更新病历二、简单的需求分析说明对“医院病房监护系统”进行分析，确定系统的主要功能如下：

1.病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。

2.中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。

3.当病症信号异常时，系统自动更新病历并打印病情报告。

4.值班护士可以查看病情报告并进行打印。

5.医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。

6.系统定期自动更新病历。需求分析1.通过以下六个问题识别角色(1)谁使用系统的主要功能？(2)谁需要系统的支持以完成日常工作任务？(3)谁负责维护，管理并保持系统正常运行？(4)系统需要应付（或处理）哪些硬设备？(5)系统需要和哪些外部系统交互？(6)谁（或什么）对系统运行产生的结果（值）感兴趣？需求分析三、建立系统的用例模型值班护士、医生、病人值班护士、医生系统管理员监护器,网络,报警系统标准病症信号库、病历库同(2)

通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班护士，医生，病人，标准病症信号库。角色描述模板：角色：病人角色职责：提供病症信号角色职责识别：负责生成、实时提供各种病症信号。角色：值班护士角色职责：负责监视病人的病情变化角色职责识别：

(1)使用系统主要功能

(2)对系统运行结果感兴趣角色:标准病症信号库角色职责：负责向系统提供病症信号的正常值角色职责识别：

(1)负责保持系统正常运行

(2)与系统交互角色：医生角色职责：对病人负责，负责处理病情的变化角色职责识别：

(1)需要系统支持以完成其日常工作

(2)对系统运行结果感兴趣角色描述２.识别用例回答下面的问题：⑴

与系统实现有关的主要问题是什么？⑵系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？⑶执行者需要系统提供哪些功能？⑷执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：医院病房监护系统高层用例图值班护士医生病人标准病症信号库病症监护提供标准病症信号中央监护病历管理病情报告管理<<extend>><<include>><<include>><<include>>进一步将用例细化，即分解用例：1.中央监护

分解:a分解信号将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。

b比较信号将病人的病症信号与标准信号比较。

c报警如果病症信号发生异常（即高于峰值），发出报警信号。

d数据格式化将处理后的数据格式化以便写入病历库。2.病症监护

分解:e信号采集采集病人的病症信号。

f模数转化将采集来的模拟信号转化为数字信号。

g信号数据组合将采集到的脉搏，血压等信号数据组合为一组信号数据。

h采样频率改变根据病人的情况改变监视器采样频率。用例细化3.提供标准病症信号

i（此用例不分解）4.病历管理

分解为：j生成病历

k查看病历

l更新病历

m打印病历

5.病情报告管理

分解为：n显示病情报告

在显示器上显示病情

o打印病情报告在打印机打印病情报告用例细化给出细化的用例图细化的用例图病人模数转化数据格式化值班护士报警信号采集比较信号标准病症信号库医生信号数据组合采样频率改变提供标准病症信号生成病历查看病历更新病历打印病历显示病情报告打印病情报告分解信号<<Extend>><<Extend>><<Extend>><<include>><<include>><<include>><<include>><<include>><<include>><<include>><<include>>用例名：

中

央

监

视执行者：值班护士、医生目标：对病人的病症信号进行监测、处理，超过极限报警。功能描述：1.分解信号：将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。2.比较信号：将病人的病症信号与标准信号比较

。3.报警：如果病症信号发生异常（即高于峰值），发出报警信号。4.数据格式化：将处理后的数据格式化以便写入病历库

。其他非功能需求:高可靠性、实时性主要步骤：按设定频率连续接收来自各病人的病症信号，并进行分解。将病人的病症信号与专家系统（标准病症信号库）中的标准信号进行比较判断是否超过极限值。若超过极限值，进行报警，并及时更新病历和打印病情报告。相关用例：病症监护、提供标准病症信号、病历管理、病情报告管理。相关信息：(优先级、性能、频执行率)：优先级：报警处理具有最高优先级3,一般病历管理为1,其他2.性能：实时性、高可靠性频执行率：根据病情严重程度12-30次/小时用例“中央监护”描述模板

任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。所谓静态建模是指对象之间通过属性互相联系，而这些关系不随时间而转移。类和对象的建模，是UML建模的基础。我们认为,熟练掌握基本概念、区分不同抽象层次以及在实践中灵活运用,是三条最值得注意的建模基本原则。

UML的静态建模机制包括：

用例图(Usecasediagram)

类图(Classdiagram)

对象图(Objectdiagram)

包图(Packagediagram)

构件图(Componentdiagram)

配置图(Deploymentdiagram)5.4静态建模5.4.1对象类与对象

UML中的对象类图(ClassDiagram)与对象图(ObjectDiagram)表达了对象模型的静态结构，能够有效地建立专业领域的计算机系统对象模型。类图(Classdiagram)由系统中使用的类以及它们之间的关系组成，分为长式和短式。类及类型名均用英文大写字母开头，属性及操作名为小写字母开头。常见类型有：Char,Boolean,Double,Float,Integer,Object,Short,String等。类图是构建其它图的基础。对象是对象类的实例(instance),用对象图来描述。对象图亦分长式和短式。属性：类型类名操作类名对象名:类名属性操作对象名图5.24类与对象的描述(1)属性(attribute)

属性用来描述类的特征，表示需要处理的数据。

属性定义：

visibilityattribute-name:type=initial-value{property-string}

可见性属性名：类型=默认值{约束特性}

其中：可见性(visibility)表示该属性对类外的元素是否可访问。分为：

public（+）公有的，即模型中的任何类都可以访问该属性。

private（-）私有的，表示不能被别的类访问。

protected（#）受保护的，表示该属性只能被该类及其子类访问。如果可见性未申明，表示其可见性不确定。(2)操作对数据的具体处理方法的描述则放在操作部分，操作说明了该类能做些什么工作。操作通常称为函数，它是类的一个组成部分，只能作用于该类的对象上。

操作定义：

visibilityoperating-name(parameter-list):return-type{property-string}

可见性操作名（参数表）；返回类型{约束特性}

其中：可见性同上。参数表：参数名：类型，…

Parameter-name:type=default-value

返回类型：操作返回的结果类型。类图的描述二、类的识别是面向对象方法的一个难点，但又是建模的关键。常用的方法有：

1.名词识别法

2.系统实体识别法

3.从用例中识别类

4.利用分解与抽象技术关键是要定义类的“属性”及“操作”。１.名词识别法

识别问题域中的实体，实体的描述通常用名词、名词短语、名词性代词的形式出现。用指定语言对系统进行描述；从系统描述中标识名词、名词短语、名词性代词；识别确定（取、舍）类。描述过程应与领域专家共同合作完成，并遵循问题域中的概念和命名。１.名词识别法

识别问题域中的实体，实体的描述通常用名词、名词短语、名词性代词的形式出现。用指定语言对系统进行描述；从系统描述中标识名词、名词短语、名词性代词；识别确定（取、舍）类。

为了发现对象和类，开发人员要在系统需求和系统分析的文档中查找名词和名词短语，包括：可感知的事物、角色、事件、互相作用、人员、场所、组织、设备和地点等。

识别问题域中的实体，实体的描述通常用名词、名词短语、名词性代词的形式出现。用指定语言对系统进行描述；从系统描述中标识名词、名词短语、名词性代词；识别确定（取、舍）类。１.名词识别法根据下述原则进一步确定类：①去掉冗余类：如两个类表述同一信息，应保留最具有描述能力的类。②去掉不相干的类：删除与问题无关或关系不大的类。③删除模糊的类或性质独立性不强的类：有些初始类边界定义不确切，或范围太广，应该删除。⑤所描述的操作不适宜作为对象类，并被其自身所操纵，所描述的只是实现过程中的暂时的对象，应删去。２.系统实体识别法

不关心系统的运作流程及实体之间的通信状态，而只考虑系统中的人员、组织、地点、表格、报告等实体，经过分析将他们识别为类（或对象）。被标识的实体有：系统需要存储、分析、处理的信息实体；系统内部需要处理的设备；与系统交互的外部系统；系统相关人员；系统的组织实体。例1有一个购物超市，顾客可在货架上自由挑选商品，由收款机收款，收款机读取商品上的条型码标签，并计算商品价格。收款机应保留所有交易的记录，以备帐务复查及汇总使用。通过分析问题的陈述，确定以下几类实体：⑴信息实体：交易记录、商品、税务信息、销售记录、货存记录。⑵设备：收款机、条型码扫描器。⑶交互系统：信用卡付款系统。⑷人员职责：收款员、顾客、会计、经理。⑸系统的组织实体：本例不考虑。以上列出的实体，都可以直接识别为类。3.从用例中识别类

根据用例的描述来识别类;如用例的描述中出现哪些实体?用例执行过程中产生并存储哪些信息?与用例关联的角色向用例输入什么信息?用例又向该角色输出哪些信息?在确定类时，常使用两类技术：

⑴分解技术将整体类和组合类分解。可控制单个类的规模。

⑵抽象技术根据一些类的相似性建立抽象类，并建立抽象类与这些类之间的继承关系。抽象类实现了系统内部的重用，很好地控制了复杂性，并为所有子类定义了一个公共的界面，使设计局部化，提高系统的可修改性和可维护性。

UML中类的关系有关联(association),聚集(aggregation),泛化(generalization),依赖(depending)和细化(refinement)。一、关联

关联是类之间的连结,分为：1.常规关联2.多元关联3.有序关联4.受限关联5.或关联6.关联类公司员工0..*顾佣0..*工作于管理

1..*工人老板0..1常规关联

或关联用户工作站

授权**授权优先级特权开始一个时间片关联类5.4.2UML中类之间的关系保险公司保险合同人公司***{or}7、其它关联

递归关联(Recursiveassociation)

即一个类到自身的关联。节点连接**递归关联人治疗病人医生带有职责的递归关联二、聚集(aggregation)

聚集是一种特殊的关联，它指出类间的“整体-部分”关系。1、共享聚集(sharedaggregation)

其“部分”对象可以是任意“整体”对象的一部分。当“整体”端的重数不是1时，称聚集是共享的。整体类部分类２、组合聚集(compositionaggregation)

其“整体”(重数为0、1)拥有它的“部分”。部分仅属于同一对象，整体与部分同时存在。整体类部分类窗口工具框显示区标题共享聚集窗口标题工具框显示区组合聚集项目人员＊＊三、泛化泛化指出类之间的“一般与特殊关系”，即继承关系。父类与子类之间构成类的分层结构。一般类特殊人员教师学生抽象类

指没有实例的类，定义一些抽象的操作，即不提供实现方法的操作，只提供操作的特征。并附以{abstract}。交叠泛化在继承树中，若存在某种具有公共父类的多重继承，称为是交叠(overlapping)的。否则是不交的(disjoint)。完全泛化一般类特化出它所有的子类，称为完全泛化，记为{complete}。

不完全泛化即未特化出它所有的子类，称为是不完全泛化

的，表示为{incomplete}.有关泛化的约束三、泛化{complete}人女人男人性别完全泛化交通工具drive()汽车drive()轮船drive()drive()启动轮子转动drive()启动螺旋浆Person驾驶drive()是抽象操作泛化中的多态性及带识别名称的泛化{propulsion}{propulsion}{overlapping}交通工具重叠泛化汽车船水陆两栖车继承性的实例继承树图形{abstract}颜色中心位置笔的粗细移动（）旋转（）显示（）{abstract}2维{abstract}定位填充类型缩放填充多边形边数顶点数显示园直径显示旋转线端点显示0维{abstract}点显示样条控制点显示弧半径起始角弧度角显示1维{abstract}定位缩放维数OrderLine

Quantity:Integer

isSatisfied1*1*1*Customer

nameaddress

CreditRating()Order

dataReceived

isPrepaidnumber:String

dispatch()close()PersonalCustomercreditCardCorporateCustomer

contactName

creditRating

creditLimit

remind()

billForMonth()

EmployeeProduct0..1+LineItem具有泛化关系的类图案例—银行网络系统

一、问题的陈述

银行网络系统包括人工出纳和分行共享的自动出纳机；各分理处用自己的计算机处理业务（保存帐户、处理事务等）；各分理处与出纳站通过网络通信；出纳站录入帐户和事务数据；自动出纳机与分行计算机通信；自动出纳机与用户接口，接受现金卡；发放现金；打印收据；分行计算机与拨款分理处结帐。要求系统正确处理同一帐户的并发访问；网络费用平均摊派给各分理处。ATM(AutoTradeMachine)银行网络系统包括人工出纳和分行与分理处共享的自动出纳机。银行网络ATM系统自动出纳机自动出纳机自动出纳机出纳站分理处计算机分理处计算机出纳站帐户帐户用户分行计算机自动出纳机…一、确定类采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件银行网络出纳员分行系统自动出纳机帐户帐户数据出纳站分理处访问分理处计算机

事务事务数据现金卡用户顾客分行计算机现金收据费用安全措施记录保管根据下述原则进一步确定类：①去掉冗余类：如两个类表述同一信息，应保留最具有描述能力的类，如“用户”与“顾客”是重复的描述，由于“顾客”更具有描述性，故保留它，删除“用户”。②去掉不相干的类：删除与问题无关或关系不大的类，如“费用”。(一)确定类采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件银行网络出纳员分行系统自动出纳机帐户帐户数据出纳站分理处访问分理处计算机

事务事务数据现金卡用户顾客分行计算机现金收据费用安全措施记录保管③删除模糊的类：有些初始类边界定义不确切，或范围太广，应该删除。如“系统”、“安全措施”、“记录保管”、“银行网络”。④删除那些性质独立性不强的，而应该是类“属性”的候选类：如“帐户数据”、“收据”、“现金”、“事务数据”。采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件银行网络出纳员分行系统自动出纳机帐户帐户数据出纳站分理处访问分理处计算机

事务事务数据现金卡用户顾客分行计算机现金收据费用安全措施记录保管⑤所描述的操作不适宜作为对象类，并被其自身所操纵，所描述的只是实现过程中的暂时的对象，应删去。如“软件”，“访问”。最终确定的11个类为：

分行计算机分行出纳站出纳员分理处计算机自动出纳机帐户现金卡事务顾客

采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件银行网络出纳员分行系统自动出纳机帐户帐户数据出纳站分理处访问分理处计算机

事务事务数据现金卡用户顾客分行计算机现金收据费用安全措施记录保管（二）为每个建模实体准备数据词典—描述模板

对类进行精确描述，如ＡＴＭ系统中类的范围、成员、方法的限制等。（三）确定关联

关联通常用描述性动词和动词词组表示。

1.从问题陈述中抽出所有可能的关联表述。

2.问题陈述中是不明显的，或是隐含的。

3.还有一些关联与客观世界或应用领域有关，必须同用户一起确定这种关联。

关联通常由以下方面确定：１、银行网络系统问题陈述中抽取可能的关联（动词词组）２、隐含的动词词组３、基于问题域的知识４、去掉不必要和不正确的关联（三）确定关联

１.银行网络系统问题陈述中的关联

银行网络包括出纳站和自动出纳机。分行共享自动出纳机分理处提供分理处计算机分理处计算机保存帐户分理处计算机处理帐户支付事务分理处拥有出纳站出纳站与分行计算机通信出纳员为帐户录入事务自动出纳机接受现金卡自动出纳机与用户接口自动出纳机发放现金自动出纳机打印收据系统处理并发访问分理处提供软件费用分摊给分理处２.隐含的动词词组分行由分理处组成分理处拥有帐户分行拥有分行计算机系统提供记录保管系统提供安全顾客有现金卡３.基于问题域的知识分理处雇佣的出纳员现金卡访问帐户请对系统需求进行分析！经过初步的需求分析，得到系统功能要求：1.监视病员的病症（血压、体温、脉搏等）2.定时更新病历3.病员出现异常情况时报警。4.随机地产生某一病员的病情报告。

例2医院病房监护系统产生病情报告监视病情更新病历例2医院病房监护系统为了对危重病人进行实时监护，随时了解病人病情，及时进行处理，建立病房监护系统。

病症监视器安置在每个病床，通过网络将病人的组合病症信号实时传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。系统根据医生的要求随时打印病人的病情报告，系统定期自动更新病历。监视器网络值班护士医生病人病症监视中央监护系统报警信号标准病症信号库病历库病人病症信号病情报告标准病症信号病历中心值班室处理组合病症信号分析确定类：①去掉冗余类：保留最具有描述能力的类。②去掉不相干的类：删除与问题无关或关系不大的类。③删除模糊的类或性质独立性不强的类：有些初始类边界定义不确切，或范围太广，应该删除。⑤所描述的操作不适宜作为对象类，并被其自身所操纵，所描述的只是实现过程中的暂时的对象，应删去。根据名词识别法和实体识别法,确定了以下初始类:一、识别系统的类

通过名词识别法和系统实体识别法等方法可以确定系统的十二个类：医生

用户名密码查看病情报告（）要求打印病情报告（）查看病历（）要求打印病历（）病人

姓名性别年龄病症提供病症信号（）用户名密码查看病情报告（）打印病情报告（）值班护士

病症监视采集频率病症信号格式化信号数据（）采集信号（）信号组合（）类的识别值班护士医生病人病症监视中央监护系统报警信号标准病症信号库病历库病人病症信号病情报告病历标准病症信号病人病症信号

脉搏血压体温生成病症信号（）病历格式病人基本情况打印时间生成病历（）查看病历（）打印病历（）

标准病症信号脉搏血压体温生成标准信号（）标题格式生成病情报告（）查看病情报告（）打印病情报告（）病情报告报警信号

声音灯光文字报警（）数模转化（）病历库类型大小容量生成病历（）更新病历（）查看病历（）打印病历（）类型大小容量提供标准信号（）标准病症信号库

输入输出分解信号（）比较信号（）报警（）数据格式化（）中央监护系统

类的识别

使用下列标准去掉不必要和不正确的关联：

(1)

若某个类已被删除，那么与它有关的关联也必须删除或者用其他类来重新表述。(２)不相干的关联或实现阶段的关联。删除所有问题域之外的关联或涉及实现结构中的关联，(３)动作。关联应描述应用域的结构性质而不是瞬时事件。(４)

派生关联，省略那些可以用其他关联来定义的关联,因为这种关联是冗余的。确定关联医院病房监护系统类图系统类图*******1111111111111111

值班护士

医生

病人

病症监视病人病症信号

病历病历库病情报告报警信号

中央监护系统

标准病症信号11报警监视标准病症信号库

1五、类图的抽象层次和细化(Refinement)关系在软件开发的不同阶段都使用类图,但这些类图表示了不同层次的抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接口;而在实现阶段,类图描述软件系统中类的实现。类图分为三个层次：1.概念层(Conceptual)类图描述应用领域中的概念。2.说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分。3.只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部分。5.4.3包图２.什么是ＵＭＬ包？

●是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。

●是一种分组机制，把各种各样的模型元素通过内在的语义连接为一个整体。

●构成包的模型元素称为包的内容，包通常用于对模型的组织管理，因此有时又将包称为子系统（subsystem）。

●包与包之间不能共用一个相同的模型元素，包的实例没有任何语义（含义）。仅在模型执行期间包才有意义。

1.为什么要引入包？

引入包(Package)是为了降低系统的复杂性。包图举例财务子系统数据库子系统数据库操作数据库接口Oracle接口Sybasec接口包图举例包的内容：可以是类的列表,也可以是另一个包图,还可以是一个类图。包之间的关系：依赖关系：两个包中的任意两个类存在依赖关系，则包之间存在依赖关系。

泛化关系：使用继承中一般和特殊的概念来说明通用包和专用包之间的关系。例如,专用包必须符合通用包的界面,与类继承关系类似。包内容包名包名包A包B数据库界面Oracle界面Sybase界面（a）包的表示(b)包的依赖关系(c)包的泛化关系

包图的表示包和类一样包也有可见性，利用可见性控制外部包对包的内容的存取方式，UML中也定义了可见性：私有(private)，公有(public)，保护(protected)。缺省值为公有。包也可以有接口，接口与包之间用实线相连，接口通常由包的一个或多个类实现。X类P类SABDCI包图举例包图举例订单获取界面AWT邮件发送界面邮件发送应用订单获取应用订单顾客用户接口包应用层包问题域包其中:AWT是Java中管理GUI类的包。包图另一种划分方式订单获取界面AWT邮件发送界面邮件发送应用订单获取应用订单顾客用户接口系统

问题域5.5 动态建模9.5动态模型动态模型主要描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态及事件发生时状态的转移，对象间动态合作关系，对象之间的交互过程以及交互顺序，描述了为满足用例要求所进行的活动及活动间的约束关系。在动态模型中,对象间的交互是通过对象间消息的传递来完成的。在其生命周期中根据通信的结果不断改变自身的状态。动态模型状态图(statediagram)：描述某个对象，子系统，系统的生命周期。

活动图(activitydiagram)

：描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种。顺序图(sequencediagram)

：是一种交互图，描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。合作图(collaborationdiagram)

：用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。9.5动态模型包括4类图：状态图、活动图、顺序图、合作图。UML中的消息一、简单消息(simple)

表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节。二、同步消息(synchronous)

是一种嵌套的控制流，用操作调用实现。操作的执行者要到消息相应操作执行完并回送一个简单消息后，再继续执行。三、异步消息(asynchronous)

是一种异步的控制流，消息的发送者在消息发送后就继续执行，不等待消息的处理。状态图(StateDiagram)用来描述一个特定对象的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的转移。状态所有对象都具有状态,状态是对象执行了一系列活动的结果。当某个事件发生后,对象的状态将发生变化。状态图中定义的状态有:5.5.1状态图初态—状态图的起始点,一个状态图只能有一个初态。终态—是状态图的终点。而终态则可以有多个。中间状态—包括三个区域:名字域、状态变量与活动域。复合状态—可以进一步细化的状态称作复合状态。中间态初态终态状态名状态变量活动

响应事件的内部动作或活动的列表，定义为：事件名(参数表[条件])/动作表达式状态变量是状态图所显示的类的属性。活动列出了在该状态时要执行的事件和动作。

3个标准事件：

entry事件用于指明进入该状态时的特定动作。

exit事件用于指明退出该状态时的特定动作。

do事件用于指明在该状态中时执行的动作。

无参数迁移举例—login状态login状态loginlogintime=curenttimeentry/type“login”do/getusenamedo/getpasswordhelp/displayhelpexit/login(use_name.password)

事件是激发状态迁移的条件或操作。在UML中，有4类事件：1.某条件变为真；表示状态迁移上的警戒条件。2.收到来自外部对象的信号(signal)表示为状态迁移上的事件特征，也称为消息。3.收到来自外部对象的某个操作中的一个调用，表示为状态迁移上的事件特征，也称为消息。４.状态迁移上的时间表达式。

状态迁移一个对象的状态的变迁称为状态迁移。通常是由事件触发的,此时应标出触发转移的事件表达式。

画状态图1、确定要描述的对象，选择状态变化对实现系统功能影响大的对象。2、确定状态空间，即对象在其生命期中所有状态的和。3、确定引起状态迁移的事件。

状态图在第一层上行向上移动到达上行空闲到达向下移动下行超时向第一层移动到达电梯状态图

细化的状态表示

UML给出了电梯细化的状态表示。状态名状态变量活动细化电梯状态图On

firstfloorGoup(floor)Movingupdo/movingtofloorGoup(floor)Idletimer=0do/increasetimerarrivedMovingdowndo/movingtofloorGodown(floor)timer=timer-outMovingtofirstfloorarrivedarrived或关系的子状态

嵌套状态图

状态图可能有嵌套的子状态图，且子状态图可以是另一个状态图。子状态又可分为两种：“与”子状态和“或”子状态，与子状态及或子状态状态图前进后退低速高速运行向前向后行使状态图之间的消息发送状态图之间可以发送消息，用虚箭头表示。消息发送状态图on/stopoffon/playoff()on()play()stop()off()/stop()CDplayerRemoteControloffonon()off()stop()play()stop()play()off()on()顺序图构成：一组对象（对象名和类名）对象生命线（时间轴）对象被激发对象间的通信（消息）5.5.2顺序图顺序图(SequenceDiagram)用来描述对象之间动态的交互行为,着重体现对象间消息传递的时间顺序。

一、概述对象1对象2消息1消息2当收到消息时,接收对象立即开始执行活动,即对象被激活了，通过在对象生命线上显示一个细长矩形框来表示激活。

二、消息控制信息{条件控制信息如：［ｘ＞０］重复控制信息如：＊［Ｉ＝1..n］

消息延迟：用倾斜箭头表示。

消息串：包括消息和控制信号，控制信息位于信息串的前部。有两种使用顺序图的方式：一般格式和实例格式。实例格式详细描述一次可能的交互。没有任何条件和分支或循环，它仅仅显示选定情节（场景）的交互。而一般格式则描述所有的情节。因此，包括了分支，条件和循环。

三、顺序图的形式:CustomerWin:Customer1:Chang

Customerdata）2:UpdateCustomer(CustomerData)3:顺序图:Computer:PrinterServer:Printer:QueuePrint(file)[Printerfree]Print(file)[Printerbusy]Store(file)带分支的顺序图:C1:c:D1:D:D2:DOp()Op2()Op3()Op4()有循环标记的顺序图Sendmessageop2until…呼叫者交换接受者拿起话筒响拨号声拨号码路由选择鸣响音停音响铃声接电话停铃声ABCDE{B-A<1S}{C-B<10S}通过网络选择通话路径{E-D<5S}双方通话打电话的顺序图创建对象与对象的消亡

在顺序图中，还可以描述一个对象通过发送一条消息来创建另一个对象。

当对象消亡(destroying)时，用符号表示。：CustomerWindowsNewCustomer(Data)：CustomerCustomer(Data)DeleteCustomer()创建或删除对象

活动图(ActivityDiagram)的应用非常广泛,它既可用来描述操作(类的方法)的行为,也可以描述用例和对象内部的工作过程,并可用于表示并行过程。活动图是由状态图变化而来的,它们各自用于不同的目的。活动图描述了系统中各种活动的执行的顺序。刻化一个方法中所要进行的各项活动的执行流程。活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。5.5.3活动图一、概述二、活动图的模型元素

构成活动图的模型元素有：活动、转移、对象、信号、泳道等。１.活动是构成活动图的核心元素，是具有内部动作的状态，由隐含的事件触发活动的转移。在概念层描述中，活动表示要完成的一些任务；在说明层和实现层中，活动表示类中的方法。活动名[条件1][条件2]

活动活动的描述二、活动图的模型元素活动还有其它的图符：初态、终态、判断、同步。初态终态[条件1][条件2]判断同步线活动图的模型元素2.转移转移描述活动之间的关系，描述由于隐含事件引起的活动变迁，即转移可以连接各活动。转移用带箭头的直线表示，可标注执行该转移的条件，无标注表示顺序执行。活动图的模型元素：有泳道的活动图3.泳道

泳道进一步描述完成活动的对象,并聚合一组活动。泳道也是一种分组机制。

泳道可以直接显示动作在哪一个对象中执行，或显示的是一项组织工作的哪部分。●请求服务支付取货提货开订单供货