第4章面向对象方法-UML.ppt

1、第4章 面向对象方法-UML,掌握在创建系统中用于表达信息的基本术语； 掌握用于表达模型的用况图、类图、顺序图和状态图。,本章内容及要求：,1、引言 1）面向对象方法发展概述 一句话概括地说：面向对象方法是一种以对象、对象关系等 来构造软件系统模型的系统化方法。可见,面向对象方法的世界 观是:一切系统都是由对象构成的,它们的相互作用、相互影响, 构成了大千世界的各式各样系统.,面向对象方法 -一种特定的软件开发方法学,其发展主要经历了： （1）支持编程的面向对象语言 1967：Dahl和 Nygaard在挪威开发了第一个面向对象语言： Simula-67 20世纪80年代初，Smallsalk

2、语言得到广泛应用； 随后出现了Objective C、C+和Eiffel等。 （2）20世纪80年中期以来，面向对象分析和设计方法学得 到了快速发展，相继提出了很多有关的方法学，典型的有： 1986：G.Booch的OOD； 1990：P.Coad和E.Yourdon的OOA，OOD 1991：J.Rumbbaugh的OMT; 1994：Embly的OSA等。,期间，形成了以下2大学派，即： 第一种：以“方法（method ）”驱动的方法学。 基本思想：在给出符号体系的基础上，明确规定 进行的“步骤”，并在每一步中给出 “实施策略”。 代表：P.Coad的“OOA（1990）”， “ OOD（

3、91）” 优缺点分析： 优点：容易学习和掌握。 缺点：不够灵活，可能对出现的新问题就没有 办法处理。,第二种：以“模型（model ）”驱动的方法学。 基本思想：给出模型化概念，即符号体系以及目标 模型；而不明确规定实现目标的“步骤”， 但给出一些必要的指导。 代表：Rumbaugh 的“OMT（1991）”等 优缺点分析： 优点：比较灵活；。 缺点：与OOA相比，不易学习和掌握。,（3）OMG发布的UML以及USDP（统一软件开发过程）,（A）95年，Grade Booch 、Jim Rumbaugh在OOPSA会议上 公布了他们的统一方法（0.8版）； （B）96年， G.Booch 、J

4、.Rumbaugh以及Ivar Jacobson “三友”，将他们的统一建模语言命名为UML； （C）97年，Rational公司发布了UML文档1.0版，作为OMG 的建议方案； （D）98年，在合并不同建议的基础上，OMG以其结果1.1版作为一个正式的标准。 （E）从此以后，于1999年，RTF发布了1.3版， 2000年9月，发布了1.4版， 2003年3月，发布了2.0版。,受到业界和学术界广泛关注，特别是UML以及相应的支持 工具已在软件开发中得到了广泛的应用。,“在建模语言方面,UML已成为一种绘制面向对象设计图的标准工具,并已传播到非面向对象领域.面向对象以前的主要方法已经消逝.

5、UML登场了,并且稳居宝座.” “统一建模语言UML乃软件设计与需求规约语言.论述语言之优劣,有用户,设计,实现等观点.这些观点既有区别,又有联系.UML问世以来,褒贬不一,但其应用广泛,成绩显著,实为具有代表性之建模语言.” 摘自序,徐家福译,2 UML 1) UML概述 UML是一种可视化语言，用于： （1）规约系统的制品； （2）构造系统的制品； （3）建立系统制品的文档。 UML应用范围 UML作为一种一般性的语言： （1）可用于对象方法和构件方法； （2）可用于 所有应用领域 （例如，航空航天、财政、通讯等） 不同的实现平台 （例如，J2EE、.NET等）,运行平台 （包括VB（VC

6、）、中间件、J2EE、.NET、框架等）,应用系统,祢补两者之间的“距离” -建立不同抽象层次的术语空间和模型表示工具 -支持多视角地建立系统模型,这意味着：UML是系统分析和设计的工具。,即就软件开发方法学而言，UML给出了方法学中不同抽象层次的 术语以及表达模型的工具。,表达模型的工具 -USE CASE图,需求获取层,表达模型的工具 -类图、交互图等,需求分析层,表达模型的工具 -类图、交互图等,设计层,表达模型的工具,2)面向对象方法术语/符号 基于面向对象方法的世界观,即“大千世界是由对象组成的， 对象有其自己的属性和运动规律，对象之间的相互作用构成了 客观世界各种各样的系统。” 为

7、了支持软件开发,面向对象方法 主要提供了两类术语: 一类是表达结构化事物的术语； 一类是表达关系的术语。,注：除了这两类术语之外， 为了控制信息组织的复杂性，还引入了用于组织特定对象结构的包。同样做一类比，一个包相当一个可管理的“预制块”。 为了使建造的系统模型容易理解，引入了术语-注解，用于对模型增加一些辅助性说明。,4.1 UML术语表 类与对象 -体现数据抽象 定义与表示： 类：一组具有相同属性、操作、关系和语义的对象的描述。 对象 :是类的一个实例.,通常把类表示为具有三个栏目的矩形，每个栏目分别代表类名、属性和操作。例如：,类的一种表示,类的其它种表示,其中，类名使用黑体字，第一个字

8、母通常要大写,并位于第 一栏的中央; 实践中,类名往往是从正被建模系统的词汇表中提取 的简单名词或名词短语; 类可以是抽象类，即没有实例的类,类名采用斜体字. 例如：,Window,Window size:Area visibility:Boolean display( ) hide( ),属性（attribute） 属性是类的一个命名特性，由该类的所有对象所共享，用于表达对象状态的数据。 3点说明 一个属性往往具有所属的类型,用于描述该特性的实例可 以取值的范围。 类的一个对象对每一个属性应有特定的值。 一个类可以有多个属性，也可以没有属性。,表示:,操作（operation） 操作是服务的

9、一个实现，由该类的任意对象为其行为所 要求的。换言之，一个操作抽象了一个对象所要做的事情， 并且该类的其它对象也要做这件事情。 2点说明： 调用一个对象上的操作可能会改变该对象的数据或状态。 一个类可以有多个操作，也可以没有操作。,Rectangle add( ) grow( ) move( ) isEmpty,表示：,其中： 在实际应用中，操作名往往是描述其所在类的行为的动词 或动词短语 在操作名中，除第一个词之外，其他每个词的第一个字母 要大写 可以通过给出操作的特征标记进一步描述之，特征标记通 常包括参数名、类型和默认值;如果该操作是一个函数，那么 其特征标记还包括返回类型。如下所示：,

10、TemperatureSensor reset() setAlarm(t:temperature) value():Temperature,责任（responsibility） 一个类承诺的任务（contract）或职责(obligation). 4点说明： 类的责任表达了定义一个类的目的。 例如：wall类 其目的是为了了解墙的高度、宽度和厚度。,给出一个类的责任，是建立该类模型的起始点。 实践中，每个结构良好的类至少要有一个职责，但最多 也只能是当时所能考虑到的几个。 例如： 一个接口“调制解调器”有四个功能： interface modem public void dial (strin

11、g pno); public void hangup ( ); public void send (char c); public void recv ( ); ,根据责任的定义，可以认为该接口有两个职责： 连接处理（public void dial (string pno); public void hangup ( );） 数据通信（public void send (char c); public void recv ( );） 显然，以上设计违背了：单一职责原则（SRP），即： 就一个类而言，应该仅有一个引起 它变化的原因。 这条原则被称为内聚性原则。 类的责任是有类中定义的属性和操作

12、实现的。在精化类 的模型时，需将责任转换为一组能够很好地完成责任的 属性和操作。,表示：,其他特征： 除了规约以上提到的属性、操作和责任外，有时还需要规 约类的其它特征，例如属性和操作的可见性，操作的多 态性等。,属性和操作的可见性,操作的多态性,Rectangle add( ) grow( ) move( ) isEmpty,Rectangle add( ) grow( ) move( )算法 isEmpty,Rectangle add( ) grow( ) move( )算法 isEmpty,类在建模中的主要用途 模型化一个系统中的词汇 要做以下工作： 针对用户的问题或实现者的解决方案，标

13、识使用UML可 描述其中的概念，作为一个类。 注：其中可使用USE CASE分析技术。 标识其责任集。其中应确保每一个类通过这一责 任集予以清晰地定义，并使这些责任在类之间得到了很 好地均衡。 为每个类的责任的实现，提供了所需的属性和操作。,例如：一个零售系统,模型化系统中的责任分布 其目标是：均衡系统中每一个类的责任，避免类过大或过 小。过大-难于复用；过小-难于理解和管理。 要做以下工作： 为了完成某些行为，标识一组紧密协同工作的类。 对以上的每个类，标识它的一组职责。 从整体上观察这些类，把其中职责过多的类分解为一些 教小抽象，而把责任过于锁碎的类合并为一个较大的类， 继之重新分配责任。

14、 考虑这些类的相互协作方式，调整它们的责任，使协作 中没有哪个类的职责过多或过少。,例如：,模型化基本类型 对简单类型建模，要做以下工作： 使用适当衍型的类，模型化所抽象为类型或枚举类型；其 中，若需要详述与该类型相关的值域，可使用约束。 例如：,类在使用中应注意的问题 每个类都应是某个有形的事物或概念的抽象。一个结构良好的类，应符合以下条件： 是对问题域或解域中的事物的明确抽象。 嵌入了一个小的、明确定义的责任集，并能很好地实现之。 清晰地分离了抽象的规约和实现。,接口 接口（interface）是操作的一个集合，其中每个操作描述了 类或构件的一个服务。,表示：,可以用带有分栏和关键字的矩形

15、符号来表 示接口。其中：在操作分栏中给出接口支持的操作列表 接口的属性分栏总是空的,也可以用小圆圈来表示接口：,注：该图表明， 类String支持接口Hashable、Comparable，而类HashTable使用接口Hashable、Comparable。,其中： 接口名放在圆圈的下面，并用实线把圆圈连接到支持它 的类目上。 这意味着这个类目要提供在接口中的所有操 作，其实类目提供的操作可能要更多。 把从类目到它支持的接口的实现关系显示为带有实 三角箭头的虚线。 用带有use标记的虚线箭头表示类目（在箭头 尾部）使用或者需要接口提供的操作。 显然，要显示接口的操作列表的话，就不能使用圆圈表

16、 示法，而应该使用矩形表示法。,几点说明(仅以类为例) 接口只描述类(构件或子系统)的外部可见操作，并不描述 内部结构。 通常，接口仅描述一个特定类的有限行为。接口没有实现， 接口也没有属性、状态或者关联，接口只有操作。 -接口在形式上等价于一个没有属性、没有方法而只有 抽象操作的抽象类。 接口只可以被其它类目使用，而其本身不能访问其它类目。 可以对接口使用泛化关系。,关于其它可表达结构化事物的术语符号 协作（collaboration）：定义了一个交互，其中由一组角 色和其它元素构成的，它们的共同工作提供了某种协作行为。 表示： 点说明： 协作具有结构、行为和维度。 由于一个给定的类或对象可

17、以参与多个协作，因此协 作表现了系统细化的构成模式。,用况（use case） 是对一组动作序列的描述，系统执行这些动作应产生对特 定的参与者有值的、可观察的结果。 表示： 点说明： 用况用于构造模型中的行为。 用况是通过协作予以细化的。,主动类（active class） 是一种至少具有一个进程或线程的类，因此它能够启动控制 活动。 表示： 主要特性： 主动类对象的行为通常与其他元素的行为是并发的。,构件（component） 是系统设计的模块化部件，通过外部接口隐藏了它的内部实 现。 表示： 3点说明； 在一个系统中，共享相同接口的构件可以相互替代，但其 中要保持相同的逻辑行为。 可以结合

18、连接件来表示构件的实现。 构件可以包含更小的构件。, 制品（artifact） 是系统中物理的、可替代的部件，其中包含物理信息(比特). 表示： 2点说明 在一个系统中，可能会存在不同类型的部署制品，例如源 代码文件、可执行程序和脚本等。 制品通常代表对源代码信息或运行时信息的一个物理打包,artifact Window.dll,注：以上个术语：主动类、构件和结点，都和类是相似的， 即它们描述了一组具有相同属性、操作和相同语义的实体。,节点（node） 是在运行时存在的物理元素，通常它表示一种具有记忆能 力和处理能力的计算机资源。 表示： 1点说明： 一个构件可以驻留在一个节点中，也可以从一个

19、 节点移到另一个节点。,Server,小结 以上八个术语(模型化概念) -类、接口、协作、用况、主动类、构件、制品、节点， 是可包含在一个UML模型中的基本模型化元素，用于抽象 客观世界中的任何实体对象 它们存在一些变体，例如： 类的变体-参与者、信号、实用程序; 主动类的变体-进程和线程； 制品的变体-应用、文档、库、页和表等。 在UML中，把以上结构化概念统称为类目（classifier）,为了组织类目,控制信息组织和文档组织的复杂性,UML引入了术语-包。 -语义 包是模型元素的一个分组。一个包本身可以被嵌套在其它包中，并且可以含有子包和其它种类的模型元素。 一个包元素对外的可见性，可以

20、通过在该元素名字前加上可见性符号（+：公共的，-：私有的，#：受保护的）来指示。 -表示 通常，在大矩形中描述包的内容，而把该包的名字放在左上角的小矩形中。,-包之间的关系 标准依赖：访问依赖和引入依赖。作用：使一个包可以访问和引入其它包。 注:包间的依赖通常隐含了各包中元素之间存在着的一个或 多个依赖。,可以把所包含的元素画在包的外面，通过符号，将这些元素与该包相连。这时可把该包的名字放在大矩形中。,引入: import 获得访问并将目标名字空间中的那些具有可见性的名字 引入到客户包（即对它们的引用可不需要一个路径名）,访问: access 目标包中具有可见性的内容可以被客户包引用，或被嵌套

21、在客户包中的其它包引用。 注意，一个访问:不修改客户的名字空间; 不以任何其它方式自动创建一些引用 访问仅准予建立一些引用。,注:如果在提出访问的那个包中还存在包，那么嵌套在其中的 包能得到与外层包同样的访问。,(2)、表达关系的术语 在UML中，有以下4种关系： 关联(association) 泛化（generalization） 实现（realization） 依赖(dependency) 这4种关系是UML的基本关系构造块，用于表达类目 之间的关系，以构造一个结构良好的UML模型。,关联(association) 定义：关联是类目之间的结构关系，描述了一组链（links）, 链是对象之间

22、的连接（connection）。例如： 注：如一个关联只连接两个类目，称为二元关联； 如一个关联连接n个类目，称为n元关联.,关联的语义表达（6点）： 关联名(name):关联可以有一个名字，用于描述该关联的“涵义”，为了避免该关联涵义上的歧义性，可给出其关联方向。如上图所示。 角色（role）:当一个类参与一个关联时，有一个特定角色。在类的一个关联中，可以显式地命名该角色,如下所示：,注： 在明确给出关联端点名的情况下，通常可以不给出该关联 名但若一个类有多个关联，可使用关联名或端点名来区分 它们若一个类有多个端点，可使用端点名来区分它们 同一个类可以在其它关联中扮演相同或不同的角色,多重性

23、（multiplicity）:类中对象参与一个关联的数目， 称为该关联角色的多重性。例如：,c1,c2,c3,c4,c5,c6,c7,p1,p3,p2,p4,p5,拥有关系：，, , , ,模型化为,1.2 0.1,拥有,多重性的表达：,聚合（aggregation）:一种特殊形式的关联，表达一种“整体 /部分”关系。即一个类表示了一个大的事物，它是有一些小 的事物（部分）组成的。 注意：不论是整体类还是部分类，它们在概念上是处于同一 个层次的。 -在建模实践中,这是区分是否把一类事物标识为一个部分类 还是把它标识为一个类的属性的基本准则.,组合（composition） 定义： A form

24、 of aggregation which requires that a part instance be included in at most one composite at a time,and that the composite object is responsible for the creation and destruction of the parts. Composition may be recursive. Synonym: composite aggregation. Composite:A class that is related to one or mor

25、e classes by a composition relationship.,点说明： 组合是聚合的一种形式。部分和整体之间具有很强的“属 于”关系，具有一致的生存期; 组合的末端，其多重性显然不能超过1； 在一个组合中，由一个链所连接的对象而构成的任何 元组，必须都属于同一个容器对象; 在一个组合中，其部分可以包含一些类和关联；根据需 要，也可以把它们规约为关联类。,该例给出了三种表示组合的方法。 其中，类Window由类Silder（角色为Scrollbar）、Header（角色为title） 和Panel（角色为body）组成。,表示： 表示组合的不同方法,限定符： 一个限定符是一个

26、关联的属性或属性表，这些属性的值将对该关联相关的对象集做了一个划分。 例如：,左图的限定符有一个属性account#，表明：在一个银行中， 一个帐户对应一个用户，或没有对应人员。 右图的限定符有两个属性，它们与Chessboard一起确定了 Square，且 Square是其组成部分。,关联类 一种模型元素，它有关联和类的特性。一个关联类，可以被看作是一个关联，但还有类的特性；或被看作是一个类，但有关联的特性。例如：,company,person,0.1 *,Job salary,employer,employee,* Job 1.*,boss,manages,worker,注意： 如果关联类

27、只有属性而没有操作或其他关联，名字可以显示 在关联路径上，从关联类符号中省去，以强调其“关联性质”。 如果它有操作和其他的关联，那么可以省略路径中的名字， 并将他们放在类的矩形中，以强调其“类性质”。 在关联路径的两端可能都具有通常的附属信息，类符号也可 以具有通常的内容，但在虚线上没有附属信息。 尽管把一个关联类画成一个关联和一个类，但它仍然是一个 单一的模型元素。,泛化（generalization） 定义： 泛化是一般性事物（称为超类或父类）和它的较为特殊种类 （称为子类）之间的一种关系，有时称为“is-a-kind-of”关系。 4点说明： 子类可继承父类的属性和操作，并可有更多的属性

28、和操作； 子类可以替换父类的声明； 若子类的一个操作的实现覆盖了父类同一个操作的实现， 这种情况被成为多态性，但两个操作必须具有相同的名字 和参数。,一个类可以有0个、1个或多个父类。没有父类且最少有一个子类的类被称为根类或基类；没有子类的类称为叶子类。如果一个类只有一个父类，则说它使用了单继承；如果一个类有多个父类，则说它使用了多继承。 注：在大多数情况中，用类和接口之间的泛化来表明继承关系。在UML中，也可在其他类目之间创建泛化，例如在结点之间。,表示：,分离表示法,共享表示法,细化（realization） 定义：细化是类目之间的一种语义关系，其中一个类目规 约了保证另一个类目执行的契约

29、。 说明：在以下2个地方会使用实现关系： 接口与实现它们的类和构件之间； 用况与实现它们的协作之间。 表示：,依赖 定义；依赖是一种使用关系，用于描述一个事物（如类 Window）使用另一事物（如类Event）的信息和服务。 3点说明： 在大多数情况里，使用依赖来描述一个类使用另一个的操 作； 如果被使用的类发生变化，那么另一个类的操作也会受到 影响； 依赖可用于其它事物之间，例如注解之间和包之间。,表示：一条有向虚线。例如：,为了进一步表达依赖的语义，UML对依赖进行了分类，并给出了相应的标记。 绑定（bind）：表明源的实例化是使用目标给定的实际参数来达到的。例如，可以把模板容器类（目标）

30、和这个类实例（源）之间的关系模型化为绑定。其中绑定涉及到一个映射，即实参到形参的映射。 导出（derive）:表明可以从目标推导出源。例如类Person 有属性“生日”和 “年龄”， 假定属性“生日”是具体的，而“年龄” 是抽象的，由于“年龄”可以从“生日”导出，因此可以把这两个属性之间的这一关系模型化为导出。,允许（permit）：表明目标对源而言是可见的。一般情况下，当许可一个类访问另一个类的私有特征时，往往把这种使用关系模型化为允许。 实例（instanceOf）：表明源的对象是目标的一个实例。 实例化（instantiate）：表明源的实例是由目标创建的。 幂类型（powertype）

31、：表明源是目标的幂类型。 精化（refine）：表明源比目标更精细。例如在分析时存在一个类A，而在设计时的A所包含的信息要比分析时更多。 使用（use）：表明源的公共部分的语义依赖于目标的语义.,以上谈到的4个术语，是UML模型中可以包含的基本关系。 它们也有一些变体，例如精化、跟踪、包含和扩展等。,4种关系的一般用法 模型化简单依赖 例如，一种常见的依赖关系是：一个类只是使用另一个类 作为它的操作参数。 对此,可从含有操作的类到被该操作用做参数的类创建一个 依赖。即:,CourseSchdule add(c:Course) remove(c:Course),Course,注：如果操作add和

32、remove给出了明显的操作标记 （c:Course，如上所示），则一般就不需要给出这个依赖； 但当省略操作标记时或一个模型还描述了被使用类的其它 关系时，就应显示这一依赖。,模型化单继承 第一步:对于给定的一组类，发现2个或2个以上类的共同责 任、属性和操作。 第二步:把发现的共同责任、属性和操作放到一个一般类中 其中要注意，不要引入过多的层次。 第三步:画出从每个特殊类到一般类（父类）的泛化关系。,例如：,注： 斜体字表明是一个抽象类或抽象操作； 子类中给出的操作为非斜体字，表明给出了操作的实现。,模型化结构关系 第一步：标识关联 若对于每一个类，需要导航到另一个类的对象，那么就 要在这2

33、个类之间给出一个关联。 这是关联的数据驱动观点。 例如，一个学校信息系统中的一组类：,例如： 要了解Student所要参与的课程，因此就应在Student和 Course之间给出一个关联，用于描述学生参与的课程； ,若对于每一个类的对象需要与另一个类的对象进行交互， 并且后一个对象不作为前一个对象的局部变量或操作参数，那 么就要在这2个类之间给出一个关联。 这是关联的行为驱动观点。 第二步：对于标识的每一个关联，添加语义描述 例如，就上图而言，给出关联的多重性： 每门课程至少有一名教师，而没有一名教师可以 教0到多门课程。 每门课程是精确地属于一个系的。,第三步：标识“整体部分” 如果关联中的

34、一个类与另一端的类相比，前者在结构上或组 织上是一个整体，而后者似乎是它们的一部分，那么就要把 它们标识为聚合，例如，见上图： 聚合：一所学校可以有0到多名学生，一个学生可以注册在 一所或多所学校学习； 聚合：一所学校可以有一个或多个系，而每个系只能属于一 所学校； 要注意：在该例中，Department和Instructor之间有两 个关联，其中：一个关联（聚合）说明可以指派一名教师 到一个或多个系中工作，而一个系可以有一名或多名教师 另一关联表明一个系只能有一名教师作系主任，而某些教 师不是系主任。,基本策略 在用UML对关系建模时，要遵循以下策略： 仅当要建模的关系不是结构关系时，才使用

35、依赖。 这条策略意味着什么？ 仅当关系是“is-a-kind-of”关系时，才使用泛化。 聚合可否替代多继承？ 一般不要引入循环的泛化关系。 应保持泛化关系的平衡：继承的层次不要多深，不要过宽 （如果出现这种情况，就要寻找可能的中间抽象类）。,1、静态模型表达工具-类图,定义： 类图是给出一组类、接口、协作以及它们之间 关系的图。 作用：可用于可视化地表达系统的静态模型。 是构件图和部署图的基础。 类图的内容： 通常包含：类；接口；依赖、泛化和关联关系。 还可以包含注解和约束,以及或子系统，甚至,可包含 一个实例,以便使其可视化。 注:这些成分,确定了所表达系统的各种形态.,4.2UML的模型

36、表达格式,例如:,类图的一般用法 类图主要用于对系统的静态设计视图（投影）进行建模，支持表达系统的功能需求，既系统提供给最终用户的服务。 一般以三种方式使用类图: 对系统中的词汇建模 当要决策：使用哪些类目和UML关系,作为系统的组成部分;哪些类目类目和UML关系,处于系统之外。此时可使用类图来描述这些抽象和它们的责任。,对简单协作建模 当需要用一组类来表达系统中的某一事物语义时，可使用类图详细描述这组类以及它们之间的关系。 对逻辑数据库模式建模 当需要给出数据库概念设计的指导,可对要在数据库中存储的信息,采用类图对相应的数据库模式进行建模。,关于UML的图-模型表达工具 UML为不同抽象层提

37、供了6种可对系统静态部分建模的 图形工具： 类图； 构件图； 组合结构图； 对象图； 部署图； 制品图。 UML为不同抽象层提供了7种可对系统动态部分建模的 图形工具： 用况图；状态图； 活动图； 顺序图；通信图； 交互概观图； 定时图。,(4)、系统行为（功能）的建模工具-USE CASE图 USE CASE 图,注:对行为的抽象，一直是人们的一个研究课题。,USE CASE图的内容： 通常包含6个抽象： 主题（Subject）；用况（Use cases）；参与者（Actor） 依赖； 泛化； 关联。 即：USE CASE图是一种表达动态模型的图形化工具，其中显 示了一组Use cases、

38、Actors以及它们之间的关系。 USE CASE图还可以包含包，形成一些更大的功能块。有时 为了对一个特定的执行系统进行可视化，也把用况的实例放 到USE CASE图中。 以上抽象确定了所表达的系统的各种形态. 注:为使以USE CASE图表达的系统更易理解,包含注解和约束。,关于USE CASE图中的术语 -主题 是由一组用况所描述的一个类，该类通常是一个系统或子系统。其中的这些用况描述了该主题的完整行为，而参与者则表示与该主题进行交互的另一种类。 -USE CASE 定义：（从2个视角） 使用视角：Each way the actor use the system is represen

39、ted as a use case. 例如： “做一次拼写检查”; “对一个文档建立索引”,系统设计视角： 一个 use case 规约了系统可以执行的一个动作（action）序 列，包括一些可能的变体，并对特定的操作者（ actor）产生可 见的、有值的结果。,值1,值2,注:以USE CASE 规约的系统功能是通过与操作者（ actor ） 可见结果的“交互”予以体现的。即一个USE CASE捕获了 参与交互的各方关于其行为的一个约定。通过这一约定， 描述了该语义实体在不同条件下的行为对参与者一个要求的 响应，以实现某一目的。其中同的行为序列，依赖于所给出 的特定要求以及与这些要求相关的条

40、件。 对于一个use case的行为，可以根据具体情况，通过交互（图）、活动（图）和状态机予以描述，或通过前置条件和后 置条件予以描述，或通过自然语言（例如事件流）予以描述。也可以以以上的某一组合来描述。,用况可用于整个系统，也可应用于子系统、单个类和接口。 不论应用到什么情况，它们仅代表这些元素被期望的行为，可 作为这些元素在开发中演化时测试用例的基础,特别是子系统 的用况是回归测试的最好的源；整个系统的用况是集成测试和 系统测试的最好的源。,图形表示： 每个用况必须有一个区别于其他用况的名字。名字是一个字符串。,Place order,Validate user,Sensors: Cali

41、brate location,简单名,受限名,对以后开发活动的影响： 它是类、对象、操作的源，是系统分析和设计阶段的输 入之一； 是分析和设计，制定开发计划，测试计划，设计测试用 例的依据之一。 Use Case可以划分系统与外部实体的界限，是系统开发的 起点。,- actor 定义：参与者表达了一组高内聚的角色，当用户与USE CASE 交互时，该用户扮演了这些角色。 3点说明： 通常，一个参与者表达了与系统交互的那些人的角色、硬件 的角色或其它系统的角色。 参与者实际上不是软件应用的一部分，而是在应用的环境 之中,其实例代表以某种特定方式与系统进行交互。 一个客体对象可以扮演多个参与者，例

42、如一个人既可以是 参与者LoanOffier，又是参与者Costomer。一个参与者代表 了客体一个方面的角色。,表示： 关系：可以定义参与者之间的泛化关系，例如：,-关系 关联：参与关系，即操作者参与一个USE CASE。例如，操 作者的实例与USE CASE实例相互通讯。 关联是操作者和USE CASE之间的唯一关系。 扩展：USE CASE A到USE CASE B的一个扩展关系，指出了 USE CASE B的一个实例可以由A说明的行为予以扩 展（根据该扩展所说明的特定条件），并依据该扩 展点定义的位置，A说明的行为被插入到B中。 包含：USE CASE A到USE CASE B的一个包

43、含，指出A的一个 实例将包含B说明的行为，即这一行为将包含在A定 义的那部分中。 泛化：USE CASE A到USE CASE B的泛化，指出A是B的特殊 情况。 注：扩展和包含是依赖的变体。,1 *, the salesperson asks for the catalog,Place Order extension points additional requests: after creation of the order,Supply Customer Data,Order Produck,Arrange Payment,Request Catalog,salesperson,例：US

44、E CASE 关系 Actor 关系,Supervisor,Establish Credit,1 *,用况图的使用 -对系统语境建模 给定一个系统，均有其内部的事物和外部的事物。例如； 在一个信用卡系统中，其内部事物有：帐户、事务处理和欺诈行为检测代理；其外部事务有：信用卡顾客和零售机构。其内部事物的责任是完成其外部事物所期望由系统提供的行为。与系统交互的外部事物构成了该系统的语境，该语境定义了系统存在的环境。 第一点:采用UML用况图对系统语境进行建模，应关注存在于系统周围的参与者,确定什么作为系统的参与者，什么不作为系统的参与者，使该图只包含那些在其生命周期内所必须的参与者。,财务结算机构

45、（负责信用卡帐户的结算服务）,零售机构（顾客通过该机构刷卡，购买商品或服务。,第二点:对系统语境建模，应遵循以下策略： 决定哪些行为是系统的一部分，那些行为是由外部实体执行 的，以此标识系统边界，同时定义主题。 在标识系统的参与者时，应考虑以下问题： 谁需要得到系统的帮助，以完成其任务； 谁执行系统的功能； 系统与哪些硬件设备或其他系统交互； 谁执行一些辅助功能进行系统的管理和维护。 将一些相似的参与者组织为一般/特殊结构。 在需要加深理解的地方，为每个参与者提供一个衍型。 最后,将这些参与者放入用况图中，并建立它们与系统用况之间的关联-通信路径.,-对需求建模 对系统的需求建模，应遵循以下策

46、略： 首先,通过标识参与者来建立系统的语境。 其次,对于每个参与者考虑他所期望或需要系统提供的行 为。并把它们作为用况。 第三,通过分解用况所表达的行为，形成必要的泛化结构和 扩展、包含结构。 第四,模型化用况图中各种关系。 最后,通过注解和约束给出这些用况的非功能需求。,需求可以用各种形式予以表达，但大多数的系统 功能都可以 表示成用况。,例如：,(5)、系统行为（交互）的建模工具-顺序图 定义：顺序图是一种交互图，即由一组对象以及这些对象之 间的关系组成，其中还包含这些对象之间被发送的消 息。例如：,顺序图所包含的内容： 交互各方：角色或对象 交互方式：通讯或链 交互内容：消息 像其它图形

47、一样，可以包含注解和约束。 这些成分确定了交互的各种形态.,从应用的角度来看，交互图是一个交互中各元素（各方、 方式和内容）的投影。其中把这些元素的语义应用到交互 图中。,5点说明 顺序图包含了一些由时间定序的消息。消息被表示为一条箭 头线，从一条生命线到另一条生命线。其中: -如果消息是异步的，则用枝形箭头线表示； -如果消息是同步的（调用），则用实心三角箭头线表示； 同步消息的回复用枝形箭头虚线表示。,对象生命线，用于表示一个对象在一个特定的时间段中的存 在。对象生命线被表示为垂直的虚线。 控制焦点（the focus of control）,表达一个对象执行一个动 作的时间段。可以表达嵌

48、套的控制焦点。控制焦点被表示为 细高的矩形。 时序，一条生命线上的时序是非常重要的，使消息集合形成 了一个偏序关系，建立了一个因果链。,顺序图中的结构控制,常见的控制类型有： 选择执行(Optional execution) 一种结构控制类型,其标签为opt。仅当进入该控制操作子（control operator），一个监护条件为真时，该控制操作子的体才予执行。 注:监护条件是一个布尔表达式，可以出现在该体中任意一个生命线顶端的方括号内，并且可以引用那个对象的属性。, 条件执行（Conditional execution） 一种结构控制类型,其标签为alt。该控制操作子的体通过水平线将其分为一

49、些部分。每一部分表示一个条件分支，并有一个监护条件。其中： 若一个部分的监护条件为真，那么该部分就被执行。但是，最多一个部分可以被执行；如果多个监护条件为真时，选择哪一部分执行，这是一个非确定性的问题，其执行可以不同。 如果没有一个监护条件为真，那么控制将绕过该控制操作子而继续。 一个部分可以有一个特定的监护条件else;对于这一部分而言，如果没有其它监护条件为真，那么该部分才被执行。, 并发执行（Parallel execution） 一种结构控制类型,其标签为par。该控制操作子的体通过水平线将其分为多个部分。每一部分表示一个并行计算。 在大多数情况下，每一部分涉及不同的生命线。 当进入该

50、控制操作子时，所有部分并发执行。 在每一部分中的消息的发送/接受是有次序的，但在整个并 发部分中的消息次序则完全是任意的。因此对于不同的计算的交互，就不应使用这一控制结构。 实际上存在很多情况，可分解为一些独立的、并发的活动，因此，这是一个非常有用的操作子。, 迭代执行（iterative execution） 一种结构控制类型,其标签为loop。一个监护条件出现在该体中一个生命线的顶端,只要在每一次迭代之前该监护条件为真，该循环体就反复执行。当该体上面的监护条件为假时，控制绕过该控制操作子。 注意：还存在其它控制操作子，但以上4中是最常使用的。,(6)、系统行为（生存周期）的建模工具-状态

51、图 定义：状态图是显示一个状态机的图，其中强调了从一个 状态到另一状态的控制流。,一个状态机是一种行为，规约了一个对象在其生存期间因 响应事件并作出响应而经历的状态。,状态1,或/和条件,Action,状态2,或/和条件,Action,状态3,状态4,或/和条件,Action,状态6,状态5,状态7,或/和条件,Action,状态8,条件,条件,状态图的内容 通常包含: 简单状态和组合状态； 事件 转换 像其它图形一样，可以包含注解和约束。 状态图中所包含的内容，确定了一个特定的抽象层，该抽象层决定了以状态图所表达的模型之形态。,从使用的角度来看，一个状态图可以包含一个状态机中任意的、所有的特

52、征（features）,即状态图基本上是一个状态机中那些元素(分支、结合、动作状态、活动状态、对象、初始状态、最终状态、历史状态等)的一个投影。,状态 定义:一个状态是类目的一个实例（以后简称对象）在其生 存期间的一种条件(condition)或情况（situation）,该 期间该对象满足这一条件，执行某一活动或等待某一消息。 表示：,一个状态表达了一个对象所处的特定阶段，所具有的对外呈现（外征）以及所能提供的服务。,Typing Password,(A),(B),状态分类: UML把状态分为初态、终态和正常状态: 初态:表达状态机默认的开始位置，用实心圆来表示； 终态:表达状态机的执行已经

53、完成，用内含一个实心圆的圆 来表示; 正常状态:既不是初态又不是终态的状态,称为正常状态. (注:在以后的叙述中，在没有特别说明的情况下所说的状 态指的是正常状态。) 实际上，初态和终态都是伪状态，即只有名字。从初态 转移到正常状态可以给出一些特征，例如监护条件和动作。,状态的规约： -名字 是一个标识状态的文本串，作为状态名。也可以有匿名状态 没有给出状态名 -进入/退出之效应(effect) 是进入或退出该状态时所执行的动作。 为了表达进入/退出之效应，UML给出2个专用的动作标号： entry 该标号标识在进入该状态时所要执行的、由相应动作表达式所规定的动作，简称进入动作。 exit 该

54、标号标识在退出该状态时所要执行的、由相应动作表达式所规定的动作，简称退出动作。 一般情况下，进入退出之效应不能有参数或监护条件，但位于类状态机顶层的进入效应可以具有参数，以表示在创建一个对象状态机时所要接受的参数。,-状态内部转移 是指没有导致该状态改变的内部转移。一般情况下，在此给出对象在这个状态中所要执行的内部动作或活动列表。其中表达动作的一般格式为：动作标号/ 动作表达式 其中，动作标号标识了在该环境下所要调用的动作，而该动作是通过/之后的动作表达式所规约，其中可以使用对象范围内的任何属性和链。若该表达式为空，则可省略斜线分隔符。 为了表达状态内转换中的动作或活动，UML给出了一个专用的

55、动作标号： do，该标号标识正在进行由其相应动作表达式所规定的活动，并且只要对象在一个状态中没有完成由该动作表达式所指定的活动，就一直执行之；当动作表达式指定的活动完成时，可能会产生一个完成事件。,注：动作标号“entry”、“ exit”和“ do”均不能作为事件名。,在以上的叙述中，使用了两个词： 动作（action）和活动(activity) 一个活动是指状态机中一种可中断的计算，中断处理后仍 可继续； 而一个动作是指不可中断的原子计算，它可导致状态的改 变或导致一个值的返回。 可见，一个活动往往是有多个动作组成的。,-子状态 如果在一个状态机中引入另一个状态机，那么被引入的状态机称为子

56、状态机。子状态是被嵌套在另一状态中的状态。相对地，把没有子状态的状态称为简单状态；而把含子状态的状态称为组合状态。 子状态机分类: 顺序子状态机（非正交）和并发子状态机（正交） 非正交子状态机,注意:右边是一个组合状态，包含一些子状态，表达了一个非正 交状态机。一个非正 交状态机最多有一个 子初态和一个子终态。,关于转入问题: 从组合状态之外的一个源状态（如上图中的“Idle”）， -可以转移到该组合状态，作为其目标状态； -可以转移到组合状态中一个子状态，作为其目标状态。 在第一种情况里，这个被嵌套的子状态机一定有一个初态，以便在进入该组合状态并执行其进入动作后，将控制传送给这一初态。 在第

57、二种情况里，在执行完该组合状态的进入动作（如有的话）和该子状态的进入动作后，将控制传送给这一子状态。,关于离开问题: 离开一个组合状态的转移，其源可以是该组合状态，也可以是该组合状态中的一个子状态。无论哪种情况，控制都是首先离开被嵌套的状态，即执行被嵌套状态的退出动作（如有的话），然后离开该组合状态，即执行该组合状态的退出动作（如有的话）。因此，如果一个转移，其源是一个组合状态，那么该转移的本质是终止被嵌套状态机的活动。当控制到达该组合状态的子终态时，就触发一个活动完成的转移。,对于一个包含非正交子状态机的组合状态而言，有时需要知道在转移出该组合状态之前所执行的那个活动所在的子状态，为此UML引入了一个概念-浅历史状态，用于指明这样的子状态，并用来表示之。如下图所示。,相对于H所表示的浅历史，可用H*来表示深历史，即在任何深度上表示最深的、被嵌套的状态。,正交子状态机 正交子状态机是组合状态中一些并发执行的子状态。如下所示：,其中，使用虚线段形成了两个正交区域（根据需要，可形成多个正交区域），分别以“T