【教学课件】第2讲UML概述.ppt

2023/8/6,1,第2讲 UML概述,2023/8/6,2,内容,UML历史什么是UMLUML与软件体系结构UML构成,1.UML历史,2023/8/6,4,1.1 UML产生与发展,面向对象的分析与设计(OOAD)方法的发展在80年代末至90年代中出现了一个高潮.UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。,2023/8/6,5,70年代中期，公认的面向对象设计语言出现。从1989年到1994年，其数量从不到十种增加到了五十多种。Booch86,GOOD(通用面向对象的开发），HOOD(层次式面向对象的设计）、OOSD（面向对象的结构设计）等一批OOD（面向对象的设计或面向对象的开发的缩写）截至1994年，公开发表并具有一定影响的OOA&D方法已达50多种。,2023/8/6,6,Rational公司的G.Booch和J.Rumbaugh决定将他们各自的方法结合起来成为一种方法。1995年10月发布了第一个版本，称作统一方法（Unified Method 0.8）OOSE的作者I.Jacobson也加入了公司，于是也加入了统一行动，发布了第二个版本UML0.9鉴于统一行动的产物是一种建模语言，而不是一种建模方法，因此称为统一建模语言在此过程中，Rational公司发起成立了UML伙伴组织，开始时有12家参加，共同推出了UML1.0版，并在1997年1月提交给OMG把其他几家分头向OMG提交提案的公司纳入进来，推出了UML1.1版，在1997年11月4日被OMG采纳,2.什么是UML？,2023/8/6,8,2.1 概述,UML(统一建模语言)是为软件系统的制品进行描述（specifying）、可视化（visualizing）、构造（constructing）、文档化（documenting）的一种语言。它同样适用于商业模块和其他非软件系统。在大型和复杂系统的建模中，UML成功地描述一些优秀的工程实施。,2023/8/6,9,曹操,孙权,Environment,话说三国演义,OOAD 适用于社会组织法分析,(Domain)西蜀,2023/8/6,10,曹操,孙权,Environment,刘备,关羽,孔明,张飞,赤壁之战,其它流程,(Domain)西蜀,曹操进兵引发西蜀 的流程,谁来执行流程呢?,2023/8/6,11,OOAD 最关心流程与元素,1.描述流程(剧情)-分析,赤壁之战,其它流程,2.安排主/配角(元素)演出-设计,刘备,关羽,孔明,张飞,2023/8/6,12,OOAD 最主要的工具,UML,(Unified Modeling Language),OMG 认可的世界标准 1997,2023/8/6,13,为什么需要 UML 呢?,贝多芬作曲时使用五线谱,您设计软件时使用UML,2023/8/6,14,为什么需要 UML 呢?,五线谱有多种音符,UML也有多种符号,刘备,孔明,关羽,曹操,赤壁之战,其它流程,空城計退敵,Use Case 图,Sequence 图,2023/8/6,15,Use Case 叙述,曹操举兵南下,西蜀就拟定策略,展开部署並联络孙权,鼎力对抗曹操大军.,曹操,赤壁之战,孙权,西蜀,把西蜀看成黑箱!,准备打开西蜀黑箱,2023/8/6,16,Scenario 叙述,曹操,赤壁之战,孙权,把西蜀黑箱打开!,刘备,关羽,孔明,张飞,2023/8/6,17,Scenario 叙述,曹操,赤壁之战,孙权,刘备,关羽,孔明,张飞,曹操举兵南下,刘备请孔明拟定策略.派遣关羽和张飞防守荆州,同时请孔明联络孙权,共同对抗曹操.孔明联合孙权,借东风,火烧曹军于赤壁.,2023/8/6,18,Scenario 叙述,使用UML 表示之,2023/8/6,19,Scenario 叙述,刘备,孔明,关羽,求战,请拟定策略,张飞,请防守荆州,请防守荆州前线,孙权,曹操,请联络孙权,请孙权领兵相助,借东风火攻,火攻曹军,2023/8/6,20,刘备的責任?,刘备,求战,请拟定策略,请防守荆州,请联络孙权,我必需 迎战曹操!,2023/8/6,21,使用UML表示-类图,刘备,求战,刘备,迎战曹操,迎战曹操,迎战曹操,迎战曹操,迎战曹操,迎战曹操,2023/8/6,22,使用UML表示,孔明,请拟定策略,请联络孙权,请孙权领兵相助,借东风火攻,火攻曹军,孔明,拟定策略,联合孙权,借东风火攻,2023/8/6,23,使用UML表示,关羽,张飞,请防守荆州,请防守荆州前线,关羽,防守荆州,张飞,防守荆州前线,2023/8/6,24,关羽,防守荆州,张飞,防守荆州前线,刘备,迎战曹操,孔明,拟定策略,联合孙权,借东风火攻,UML的Class图,您已熟悉Use CaseSequence图Class 图,现在准备进入OOP 阶段,2023/8/6,25,3.认识 OOP,OOP 阶段的任务,-衔接OOAD 的工作,-从UML 到 Visual Basic,-从Visual Basic 到 COM 组件,2023/8/6,26,使用Visual Basic,刘备,迎战曹操,写VB程序,Class 刘备Sub 迎战曹操()End Sub,2023/8/6,27,孔明,拟定策略,联合孙权,借东风火攻,使用Visual Basic,写VB程序,Class 孔明Function 拟定策略()End FunctionSub 联合孙权()End SubSub 借东风火攻()End Sub,2023/8/6,28,Class 刘备Sub 迎战曹操()End Sub,使用Visual Basic,Class 孔明Function 拟定策略()End FunctionSub 联合孙权()End SubSub 借东风火攻()End Sub,Class 关羽Sub 防守荆州()End Sub,Class 张飞Sub 防守前线()End Sub,依樣畫葫蘆,准备填写 Sub內容,2023/8/6,29,写VB程序內容,刘备,求战,请拟定策略,请防守荆州,请联络孙权,写VB程序,Class 刘备Dim k As New 孔明Dim g as New 关羽Sub 迎战曹操()k.拟定策略 g.防守荆州 k.联合孙权End Sub,2023/8/6,30,写VB程序內容,孔明,请拟定策略,请联络孙权,请孙权领兵相助,借东风火攻,借东风火攻,写VB程序,Class 孔明Dim s As 孙权Function 拟定策略()End FunctionSub 联合孙权()s.请领兵相助 s.借东风火攻End SubSub 借东风火攻()End Sub,2023/8/6,31,写VB代码,Class 刘备Dim k As New 孔明Dim g as New 关羽Sub 迎战曹操()k.拟定策略 g.防守荆州 k.联合孙权End Sub,Class 孔明Dim s As 孙权Function 拟定策略()End FunctionSub 联合孙权()s.请领兵相助 s.借东风火攻End SubSub 借东风火攻()End Sub,2023/8/6,32,写VB代码,把VB类编译为COM组件,3.UML支持软件体系结构建模,2023/8/6,34,3.1 软件体系结构,为了表达不同的软件开发相关人员在软件开发周期的不同时期看待软件产品的不同侧重面,需要对模型进行分层。UML根据软件产品的体系结构（architecture）对软件进行分层软件体系结构由一系列的决定组成，这些决定定义了如下内容：软件系统的组织；构成软件系统的结构元素的结构及它们之间的接口；结构元素的行为及元素之间的协同（collaboration）结构元素的不断组合以构成日渐完备的子系统的过程指导软件建造过程的软件构筑风格（architectural style）静态和动态元素之间的接口、协同、构成（composition）。,2023/8/6,35,软件体系结构不仅仅决定软件的结构和行为，而且还决定软件的：用途功能性能应变性(resilience)可重用性经济和技术方面的限制和折衷以及美学考虑（aesthetic concern）,2023/8/6,36,3.2 体系结构的视图,UML将软件的体系结构分解为五个不同的侧面，称为视图(view)。分别是：用例视图（Use case view）设计视图(design view)进程视图（process view）实现视图(implementation view)分布视图(deployment view)设计视图和进程视图又可被统一称为逻辑视图(logical view)。,2023/8/6,37,2023/8/6,38,每个视图分别关注软件开发的某一侧面视图由一种或多种模型图(diagram)构成模型图描述了构成相应视图的基本模型元素（element）及它们之间的相互关系。,2023/8/6,39,3.3 用例视图（use case view）,用例视图用来支持软件系统的需求分析，它定义系统的边界，关注的是系统的外部功能的描述。它从系统的使用者的角度，描述系统的外部的静态的功能动态行为系统的动态功能由UML以下模型图描述：交互图(interaction diagram)状态图(state-chart diagram)活动图(activity diagram),2023/8/6,40,3.4 逻辑视图（Logical View）,逻辑视图定义系统的实现逻辑,描述为实现用例图描述的功能，在对软件系统进行设计时,所产生的设计概念，设计概念又称为软件系统的设计词汇(vocabulary)。逻辑视图定义了:设计词汇的逻辑结构存在于它们之间的语义联系设计词汇包括系统的类/协同/接口及其关系对逻辑视图的描述在原则上与软件系统的实现平台无关。它相当于电子产品生产中的电原理图。逻辑视图包含的模型图有：类图（class diagrams）对象图（object diagrams）交互图（interaction diagrams）状态图（state-chart diagrams）活动图（activity diagrams）,2023/8/6,41,3.5 实现视图（implementation view）,当系统的逻辑结构在逻辑视图里被定义之后，需要定义逻辑结构的物理实现。这包括：设计元素对应的源代码文件各物理文件之间的关系、存放路径，等等实现视图就是定义这些内容的地方，它当于电子产品的印刷电路板的布线图,2023/8/6,42,实现视图描述组成一个软件系统的各个物理部件，这些部件以各种方式组合起来，（如：不同的源代码经过编译，构成一个可执行系统；或者不同的软件组件配置成为一个可执行系统；以及不同的网页文件，以特定的目录结构，组成一个网站，等等）构成了一个可实际运行的系统。实现视图包含的模型图有:部件图（Component diagram）交互图（Interaction Diagram）状态图（state-chart diagram）活动图（activity diagram）,2023/8/6,43,3.6 分布视图（Deployment View）,软件产品将运行在计算机硬件系统上,如果软件产品是面向网络的应用系统，则有可能同时运行在多个计算机上。分布视图用来描述软件产品在计算机硬件系统和网络上的安装、分发（delivery）、分布（distribution）在分布视图中，系统的静态特性用分布图（deployment diagram）描述动态特性的描述用交互图（interaction diagram）状态图（state-chart diagram）活动图（activity diagram）,4.UML构成,2023/8/6,45,4.1 UML基本构成,从软件的体系结构出发，UML把软件模型分成了五个视图，每个视图由不同的模型图构成：模型图实际上就是UML的基本成员之一作为UML的完整的概念模型，UML的构成为：UML=UML成员+UML建模规则,2023/8/6,46,UML建模规则：相当于建模语言的语法 UML成员（building blocks of the UML）它是UML的基本组成部分UML成员可进一步划分为UML 基本模型元素（things in UML）关系（relationship）模型图（diagram）UML成员=UML 基本模型元素+关系+模型图,4.1.1 UML基本元素,UML成员=UML 基本模型元素+关系+模型图,2023/8/6,48,4.1.1.1 概述,UML基本模型元素，类似于电子产品电原理图里的集成电路符号，是模型图上包含的基本符号基本模型元素可分为四类，它们是：结构模型元素（structural things）行为模型元素（behavioral things）分组模型元素（grouping things）注解元素（annotational things）UML基本模型元素=结构模型元素+行为模型元素+成组元素+注解元素,2023/8/6,49,4.1.1.2 结构模型元素,结构模型元素（基础包）是UML模型里的名词（noun），是模型的静态组成部分，代表软件系统的概念的,或物理的存在。例如：类（class）是最常用的一个结构模型元素，代表一系列共享同样的属性（attributes），操作（operation），关系、语义的对象（object）。,2023/8/6,50,结构模型元素一共有七种，它们是：类接口（interface）协同用例（use case）主动类（active class）组件（component）节点（node）在这些结构元素中，最常用的包括类、用例、接口、组件等,2023/8/6,51,4.1.1.3 行为模型元素,行为模型元素（behavioral things）（行为元素包）是UML模型的动态组成部分，它是模型的动词，代表软件系统在空间和时间上的行为行为模型元素包括两类:交互（interaction）状态机（state machine）行为模型元素=交互+状态机,2023/8/6,52,交互是系统内一系列的对象之间互相交换消息的行为。消息代表软件系统内两个对象中一个对象向另一个对象发出的执行某种操作的请求。交互描述了一系列的对象为完成某一项任务而联合采取的一系列的行动，其中包括这些行动在时间上的顺序，以及为执行这些动作序列，对象之间所发生的语义上的联系。所以，消息是描述交互的一个重要手段。在模型图上，消息被表示为一个箭头,2023/8/6,53,状态机:状态机是描述一个对象的动态特性的有效手段它描述的是对象在其生命周期内，在响应外界的事件的过程中，自身的状态的变化过程。状态机包括：对象状态事件由事件引起的状态之间的变迁以及变迁发生的同时对象所执行的动作,2023/8/6,54,4.1.1.4 成组模型元素,分治的原则:在为复杂的软件系统建模的时候，将大的问题分解为多个子问题分别描述和解决。UML提供了支持分治原则的语言成份，成组模型元素(grouping things)（模型管理包）成组模型元素只有一类，即模型包（package）。模型包一个通用的手段,用来组织多种语言成份，其中可包含：结构模型元素行为模型元素成组模型元素自身都可以置于模型包中。模型包是纯概念性的，只存在于软件系统的开发阶段,2023/8/6,55,4.1.1.5 注解模型元素,注解大量存在于机械图和电子线路图中，被用来标示产品的工艺要求，等等UML中，也存在着相似的语言成分，这就是：注解元素（annotation things）注解元素只有一种，即标注（note）标注用来描述施加于一个或多个模型元素的限制，或对模型元素的语义加以说明标注的图形表示：一个折了角的长方形在长方形中写标注的内容。标注的内容可以是形式的文本,或非形式的文本也可以是图形。,4.1.2 关系,UML成员=UML 基本模型元素+关系+模型图,2023/8/6,57,结构模型元素是UML模型的静态组成部分，静态组成部分不是孤立存在的，它们被组合在一起互相协作以完成某项任务。因此，结构模型元素之间存在着某种语义上的联系。在UML中，这种联系是关系（relationship）UML中共有4种关系，它们是：关联关系（association）依赖关系(dependency)泛化关系(generalization)实现关系(realization),4.1.3 模型图,UML成员=UML 基本模型元素+关系+模型图,2023/8/6,59,4.1.3.1 概述,UML基本模型元素及其关系必须通过某种载体表示，这种载体就是模型图（diagram）在UML中，模型图是一组UML基本模型元素的图形表示，它通常由一组节点（UML基本模型元素）,及节点之间的连线（关系）组成软件系统体系结构的5个视图的内容,就是用模型图来表达的 一般地说，一个UML基本模型元素既可以出现在所有的模型图中，又可以出现在某些模型图中，甚至可以不在任何一个模型图上出现,2023/8/6,60,9种UML模型图。它们是:类图对象图用例图序列图协同图状态图活动图组件图分布图,2023/8/6,61,4.1.3.2 静态结构模型图,类图包含类、接口、协同及其关系，它用来描述逻辑视图的静态属性对象图包含对象及其关系，它用来表示类图的类的对象在系统运行过程中某一时刻的状态，对象也是软件系统的逻辑视图的一个组成部分。组件图描述系统的物理实现，包括构成软件系统的各部件（运行文件）的组织和关系，类图里的类在实现时最终会映射到组件图的某个组件。一个组件可以实现多个类。组件图是软件系统实现视图的组成部分。分布图描述系统的组件在运行时在运行节点上的分布，一个节点可包含一个或多个组件。分布图是软件系统分布视图的组成部分。上述四种模型图主要用来描述软件系统的静态结构。,2023/8/6,62,4.1.3.3 动态特性模型图,描述软件系统的动态特性的,使用用例图序列图协同图状态图活动图,2023/8/6,63,用例图描述系统的边界，和其上的动态行为，图中包括：用例（use case），系统作用者（actor）及其之间的(关联)关系。用例图是用例视图的重要组成部分。序列图和协同图用来描述一组对象之间的动态交互。以用来描述系统的动态特性、外部的动态特性、内部的动态特性。状态图和活动图用于描述对象的动态特性。状态图强调对象对外部事件的响应及相应的状态变迁，活动图描述对象之间控制流的转换和同步机制。,4.1.4 UML建模原则,UML=UML成员+UML建模规则,2023/8/6,65,UML的模型图不是UML语言成份（UML成员）的简单堆砌，它必须按特定的规则有机地组合而成，从而构成一个完备的UML模型图。完备的UML模型图（well-formed UML diagram）必须在语义上是一致的，并且和一切和它相关的模型和谐地组合在一起。UML建模规则包括:名字：任何一个UML成员都必须包含一个名字作用域：UML成员所定义的内容起作用的上下文环境可见性：UML成员能被其它成员引用的方式完整性：UML成员之间互相联接的合法性和一致性。运行属性（execution）：UML成员在运行时的特性。,2023/8/6,66,完备的UML模型必须对以上的内容给出完整的解释,当用于软件系统的建造时，UML模型是必须是完备的,但是当模型在不同的视图中出现时,出于不同的交流侧重点,其表达可以是不完备的,4.2 公共机制,2023/8/6,68,4.2.1 概述,在模型图上对UML成员进行描绘时，存在着共同的描绘方式，它们称为：UML公共机制（UML common mechanism）使用这些公共机制，使得建模的过程易于掌握，模型易于被理解公共机制可被分解为四个方面的内容：规格说明(Specification)通用划分(Common Division)修饰(Adornment)扩展机制(Extensibility),2023/8/6,69,4.2.2 规格说明,体现了UML规则的省略性原则模型图省略某些对突出重点不重要的内容但是软件模型必须是完备的，以便于软件系统的建造，意味着此模型必须具备足够的详细信息以供软件建造之用，这些构成一个完备模型的详细信息就是模型的规格说明（specification）所有UML模型元素都包含规格说明在模型图上被省略的内容并不代表它也不存在于模型之中，模型的完整的或完备的信息是被保存在模型的规格说明中的，而通常一个完备的模型全部内容是通过多个模型图表达出来的,2023/8/6,70,4.2.3 通用划分,在面向对象的设计中，有许多事物可以划分为抽象的描绘（class）和具体的实例UML提供了事物的这种两分法（dichotomy）表达几乎每种UML成员都有这种类/对象的两分法划分，通常对象和类使用同样的图符，在对象的名字下面加下划线以示区别。还有一种两分法是接口和实现的两分法划分，接口定义了一种协议，实现是此协议的实施。UML里这样的接口/实现两分法划分包括：接口/类或部件用例和协同操作和方法,2023/8/6,71,4.2.4 修饰和扩展机制,UML提供了一系列的图形化的标准建模元素，可用于描述软件系统的大多数侧面的特性但也有可能在某些情形下，由于应用领域特殊性，标准的UML建模元素,无法完整而准确地描述软件系统的分析和设计,这时，需要对UML的标准建模元素进行扩充,以提高模型的表达能力UML的修饰和扩展机制就是为这个目的而设置的,2023/8/6,72,4.2.4.1 标注,标注是UML修饰机制的一个重要组成部分当用UML的各种建模元素为软件系统建模时，将遇到关于这些建模元素的复杂的语法、语义、原理、约束、注释等，这些内容对表达问题的某一方面很重要，但又无法通过标准建模元素被完整地表达这时，可以使用标注对这些建模元素进行附加说明，例如在使用序列图来描述一组对象间的交互时，其中的消息的语义、语法无法在消息的名字字串内完整地表达，可以用标注的方法进行直观的说明。,2023/8/6,73,对于类、模型包、部件等，也可能遇到类似的情形，因此也可以用标注的方法进行补充说明标注的手段不是软件建模独有的，在其它工业建模领域，标注也是大量存在的例如，在电子线路图上，可以通过标注对电路的电气特性进行说明。,2023/8/6,74,标注（Note)的定义：在UML中,标注被定义为UML的一个图形表示，它用来描述对一个或一组UML建模元素的约束或注释标注可以作用于任何UML建模元素（如：类、对象、关系、消息等），用于对此建模元素的各方面的特性作补充说明、表示设计分析过程中产生的假设和决定等标注的内容对被标注的建模元素没有任何语义上的影响，它只起到增强模型的可读性的作用,2023/8/6,75,UML对标注的内容不作任何限制，它可以是普通的文本，也可以是形式化的描述如果工具支持的话，标注还可以包含网络链接。标注的内容不宜过长。如果有很长的内容需要通过标注表达的话，可以把内容存放在一个分开的文件内，在标注内则放置对此内容的引用标注的图形化表示在UML里，标注被图形化为一个折角矩形矩形的内部放置标注的内容，标注和被标注的建模元素之间用虚线连接一个标注可以为多个建模元素作标注,2023/8/6,76,位图显示:工作原理见,doublebuffering.doc,CBmpViewerView,(from bmpviewer),CBmpDblBuffering,(from bmpviewer),1,+m_pCBmpDblBuf,1,+m_pCBmpDblBuf,0.1,1,0.1,1,CBmpViewerDoc,(from bmpviewer),CBmpViewerData,(from bmpviewer),+m_pCBmpViewerData,1,1,1,1,位图文件,格式参见:,这个类用于维护图象,的当前状态,简单文字,对文件的引用,网络连接,2023/8/6,77,4.2.4.2 扩展机制,构造型、标记值(tagged value)、约束(constraint)是UML扩展机制的组成部分,2023/8/6,78,（1）扩展机制：构造型,UML已经提供了标准的建模元素用于软件系统的建模在对软件系统进行分析和设计时，可以用这些建模元素对软件系统的动态行为和静态结构进行建模但在各种不同的应用领域，往往有可能出现用现有的建模元素无法充分表达所需内容的情况，这时需要在现有的建模元素的基础上进行扩充，产生对特定建模问题特有的建模元素，这种建模元素就是构造型,2023/8/6,79,构造型(stereotype)的定义在UML中,构造型(stereotype)被定义为是对UML词汇（建模元素）的扩充，用来描述和已有的UML建模元素类似，但又对特定的问题领域有特殊意义的建模元素。当在UML模型现有的标准建模元素的基础上创建其构造型时，此构造型就变成了一个新的UML建模元素，这个新的建模元素除了和最初的建模元素类似之外，它可以有自己的：新的构成（用标记值表示）新的语义（可用约束表示）自己的标识符（文本的和图形化的）,2023/8/6,80,构造型的图形表示，构造型的标识可以采取两种形式：记名的构造型（named stereotype）构造型的图标形式(stereotyped element as icon)具名构造型是在UML模型中构造型最简单的表达形式，它保留了原建模元素的图形化表示，而用构造型名来修饰原建模元素的名字，以使构造型在图形化表示上区别于原建模元素。在创建一个构造型时，必须为其指定一个名字，当构造型的标识采用具名构造型的形式时，在原建模元素的图形表示的名字的上方，放置用双尖括号（）括起来的构造型名。,2023/8/6,81,构造型还可以使用自己的图标，用来代替原来的建模元素的图形化表示，这就是构造型标识的图标形式。,图标,形式,CBmpViewerView,(,from,bmpviewer),CBmpViewerView,(,from,bmpviewer),boundary,具名构造型,2023/8/6,82,(2)扩展机制：标记值,任何一个UML标准建模元素都有其基本构成例如，对于类而言，它的三个基本构成是：名字、属性、操作。在特定的情形下，将有必要在建模元素的基本构成之外再增加一些构成,此构成就是标记值(tagged value)。例如：可以在类上在增加一个名为version的标记值，用来表明词类的定义对某一特定的软件版本有效。,2023/8/6,83,标记值的定义在UML中，标记值被定义为是对UML建模元素的构成(property)的扩充，用于为此建模元素增加新的规格说明。标记值和类的属性不同，属性定义的是被建模的事物的构成，而标记值定义的是建模元素本身的构成，就这个角度而言，标记值可以看作是UML的元数据。标记值必须是具名的，此名字应有合法的取值，如果把类的属性看作标记值的话，此标记值的名字就是“属性(attribute)”,而类的属性定义的集合，就是“属性”这个标记值的取值。,2023/8/6,84,标记值的图形表示在UML里，标记值被图形化地表达为一个字符串，此字符串用花括弧括()起来，被放置到原建模元素的名字的下方标记值的字符串由标记值的名字、取值、及分隔符组成。名字位于字符串的起始，取值位于字符串的尾部，它们之间用等号分隔。在不引起混淆的情况下，标记值的名字可以省略。,2023/8/6,85,标记名被省略,trans,serverOnle,Server,processors=3,完整的标记值,2023/8/6,86,(3)扩展机制：约束,和标记值对UML建模元素的构成进行扩充类似，UML提供了对UML建模元素的语义进行扩充的机制，这机制被称为约束。约束的定义：在UML里，约束用来扩充UML建模元素的语义，以便增加新的规则或修改已有的规则在UML里，每一个建模元素都有明确的语义，语义规定了用建模元素为软件系统建模的规则。如果在建模时，有些特定的规则不包含在现有的UML语义内，可以用约束对建模元素的现有建模规则进行扩充。约束为对应的建模元素规定了一个条件，对于一个完备的模型而言，此建模对象必须使该条件被满足。,2023/8/6,87,约束的图形化表示在UML里，约束被图形化为一个文本串，此文本串被括在一对花括号内，并被放置在被约束的建模元素附近例如，通常，关联关系只表示两个类之间的语义连接，而在图中，需要表示用继承关系实现的多个鼠标工具的切换。这时，任何时刻，指向它们的基类的指针只和一个导出类相关连，为了表达这种情形，这些关联关系加以约束(or)，以表示任意时刻，类CmainFrame的关联角色m_pCToolBase 或者和CtoolZoom关联，或者和CtoolPan关联。,2023/8/6,88,or 约束:任何时刻只和,一个导出类相关,CToolPan,(from bmpviewer),CToolZoom,(from 图7.8 继承关系),CToolBase,(from bmpviewer),CMainFrame,(from bmpviewer),+m_pCToolBase,+m_pCToolBase,+m_pCToolBase,or,鼠标工具切换机制,2023/8/6,89,(4)标准扩展,UML的扩展机制应有节制地使用，避免产生过多的“方言”而影响UML交流功能的发挥。为此，UML提供了一些标准的扩展元素，称为标准扩展（standard elements）标准扩展可适用于大多数软件系统的建模，因此在建模时，通常应优先使用这些标准的扩展元素，其次再考虑设计自己的扩展元素,2023/8/6,90,（4）标准扩展：文档,文档(documentation)是一个标记值，可以用于所有的UML建模元素。其取值可以是对此建模元素的注释、描述或解释在一些工具里，此标记值不通过标准的标记值的图形表达法显示，而是在其用户界面上用一个标准窗口来显示。,2023/8/6,91,标记值：文档某些工具（Rational Rose）将文档作为建模对象的规格说明窗口的一部分,2023/8/6,92,（4）标准扩展：标准构造型,UML是一个通用的建模语言，它的建模对象不仅仅局限于软件系统在用UML进行软件系统的分析设计时，需要对这些建模元素的语义进行强化，这如同在人类的自然语言在不同的专业领域有不同的专业术语一样。,2023/8/6,93,1)、系统作用者系统作用者（actor）是在进行软件系统的用例分析时必须用到的概念系统作用者是类的构造型，代表位于系统之外，但又和系统相关联的对象系统作用者的图形表示UML用一个人形图符表示系统作用者可以用系统作用者代表软件系统的使用者位于系统之外的软件系统、硬件系统,2023/8/6,94,2)、控制类边界类实体UML对软件系统的分析和设计是从软件的体系结构出发的。在对软件体系结构的四个视图（用例视图、逻辑视图、部件视图、分布视图）进行分析和设计时，需要对UML进行语义的强化。这时可以使用：控制类边界类实体类它们是对这种强化的标准概括，它们都是类的构造型。,2023/8/6,95,控制类（control class）控制类代表一类控制或启动交互的对象。它的行为通常都是针对于一个特定的用例，它的对象一般只存在于此用例的协同中。例如在窗口操作系统中，对话框内的控制钮就可以用控制类来建模。其它的诸如操作系统命令窗口，设备控制器等也是控制类的建模对象控制类的图形化表示：在UML里，控制类被图形化表示为一个带有箭头的圆圈。,2023/8/6,96,边界类（boundary class）边界类的定义：边界类代表处于系统边界上，不但和系统内部对象交互，而且又和系统外部的系统作用者交互的一类对象。例如：软件系统的通用外部设备如打印机、显示器、键盘及其驱动软件等，可以用边界对象建模。边界类的图形化表示边界类被图形化描述为带有T形连接的圆圈。,2023/8/6,97,实体类(entity class)：实体类是一类被动的对象，它本身不会启动交互，可以参加多个用例的交互，并且存活于任何单独的交互之外。通常，软件系系统中的文件、数据库等，可以用实体类建模。实体类图形化表示实体类被图形化描述为和一条短直线在底部相切的圆圈。,2023/8/6,98,边界类,User,(,from Actors),ZoomIn,Buttom,(,from User Interface Design),显示,(from,图,3.2),位图文件,(from,图,3.2),控制类,实体类,系统作用者,2023/8/6,99,注意事项,在使用UML的标注和扩充机制进行建模时，应注意的一条重要原则是：UML建模的目的是交流，因此，可以充分利用标注的强化模型的可读性的功能，通过标注对建模元素的语义进行直观的解释和说明标注内可以包含任内容，甚至可以以包含图形，如果标注内容较长，则可把内容存放在一个分开的文件内，在标注上指明此文件的位置。,2023/8/6,100,注意事项,在使用UML的扩展机制时，应注意不要滥用扩展不要过多地扩展要尽量使用已有的UML标准建模元素如果确有必要扩展，就优先考虑使用标准扩展最后才考虑使用自定义的扩展,2023/8/6,101,小结,UML(统一建模语言)是为软件系统的制品进行描述（specifying）、可视化（visualizing）、构造（constructing）、文档化（documenting）的一种语言。UML的视图：用例视图，设计视图，进程视图，实现视图，分布视图UML=UML成员+UML建模规则UML成员=UML 基本模型元素+关系+模型图UML基本模型元素=结构模型元素+行为模型元素+成组元素+注解元素,