UML参考手册 第一部分 背景知识 第1章 UML 综述

VC++ 专栏收录该内容
43 篇文章 0 订阅

 

ML参考手册 

 第一部分 背景知识  

这一部分介绍了UML的基本原理,包括UML建模的性质和目标以及UML覆盖的所有功能领域。

 第1章 UML 综述

  本章是UML及其应用的一个快速浏览。
1.1 UML简介
  统一建模语言(UML)是一个通用的可视化建模语言,用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。它记录了对必须构造的系统的决定和理解,可用于对系统的理解、设计、浏览、配置、维护和信息控制。UML 适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具,UML 是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。UML包括概念的语义,表示法和说明,提供了静态、动态、系统环境及组织结构的模型。它可被交互的可视化建模工具所支持,这些工具提供了代码生成器和报表生成器。UML标准并没有定义一种标准的开发过程,但它适用于迭代式的开发过程。它是为支持大部分现存的面向对象开发过程而设计的。
  UML描述了一个系统的静态结构和动态行为。UML将系统描述为一些离散的相互作用的对象并最终为外部用户提供一定的功能的模型结构。静态结构定义了系统中的重要对象的属性和操作以及这些对象之间的相互关系。动态行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制。从不同但相互联系的角度对系统建立的模型可用 于不同的目的。
  UML还包括可将模型分解成包的结构组件,以便于软件小组将大的系统分解成易于处理的块结构,并理解和控制各个包之间的依赖关系,在复杂的开发环境中管理模型单元。它还包括用于显示系统实现和组织运行的组件。
UML不是一门程序设计语言。但可以使用代码生成器工具将UML模型转换为多种程序设计语言代码,或使用反向生成器工具将程序源代码转换为UML。UML不是一种可用于定理证明的高度形式化的语言,这样的语言有很多种,但它们通用性较差,不易理解和使用。UML是一种通用建模语言。对于一些专门领域,例如用户图形界面(GUI)设计、超大规模集成电路(VLSI)设计、基于规则的人工智能领域,使用专门的语言和工具可能会更适合些。UML是一种离散的建模语言,不适合对诸如工程和物理学领域中的连续系统建模。它是一个综合的通用建模语言,适合对诸如由计算机软件、固件或数字逻辑构成的离散系统建模。
1.2 UML 的历史
  UML是为了简化和强化现有的大量面向对象开发方法这一目的而开发的。
1.2.1 面向对象的开发方法
  利用传统程序设计语言(如Cobol和 Fortran语言)的软件开发方法出现于20世纪70年代,在80年代被广泛采用,其中最重要的是结构化分析和结构化设计方法[Yourdon-79]和它的变体,如实时结构化设计方法[Ward-85]等。这些方法最初由Constantine、Demarco、Mellor、Ward、Yourdon和其他一些人发明和推广,在一些大型系统,特别是和政府签约的航空和国防领域的系统中取得了一定突破,在这些系统中,主持项目的政府官员强调开发过程的有组织性和开发设计文档的完备和充分。结果不总是像预料的那么好—许多计算机辅助软件工程系统(CASE)只是摘录一些已实现的系统设计的报表生成器—尽管如此,这些方法中仍包含一些好的思想,有时在一些大系统中是很有效的。商业应用软件更不愿采用大型的CASE系统和开发方法。大部分商业企业都独立开发本企业内部使用的软件,客户和缔约人之间没有对立关系,而这种关系正是大型政府工程的特征。一般都认为商用系统比较简单,不论这种看法是否正确,反正它不需要经过外界组织的检查。
  普遍认为,诞生于1967年的Simula-67是第一个面向对象的语言。尽管这个语言对后来的许多面向对象语言的设计产生了很大的影响,但是它没有后继版本。80年代初Smalltalk,语言的广泛使用掀起了一场“面向对象运动”,随之诞生了面向对象的C、C++、Eiffel和CLOS等语言。起初,尽管面向对象编程语言在实际使用中有一定的局限性,但它仍然吸引了广泛的注意力。在smalltalk语言成名约5 年后,第一批介绍面向对象软件开发方法的书籍出现了。包括Shlaer/Mellor [Shlaer-88]和Coad/Yourdon [Coad-91],紧接着又有Booch的[Booch-91]、Rumbaugh/Blaha/Premerlani/Eddy/Lorensen的[Rumbaugh-91]和Wirfs-Brock/Wilkerson/Wiener [Wirfs-Brock-90](注意:图书版权年代往往包括了上一年度7月份以后出版的书)。这些著作再加上   Goldberg/Robson[Goldberg-83] Cox[Cox-86]和Meyer[Meyer-88] 等有关程序语言设计的著作,开创了面向对象方法的先河。第一阶段在1990年末完成。稍晚[Jacobson-92]出版了,它建立在以前的成果的基础上,介绍了一种稍微不同的方法,即以用例和开发过程为中心。
  在以后的5年中,大批关于面向对象方法的书籍问世,各有自己的一套概念、定义、表示法、术语和适用的开发过程。有些书提出了一些新概念,但总的来说各个作者所使用的概念大同小异。许多后继出版的书都照搬前人,自己再做一些小的扩充或修改。最早的著作者也没闲着,他们大部分人都更新了自己前期的著作,采纳了其他人一些好的思想。总之,出现了一些被广泛使用的核心概念,另外还有一大批被个别人采纳的概念。即使在被广泛接受的核心概念里,在各个面向对象方法中也有一些小的差异。这些面向对象方法之间的细微比较常使人觉得这些概念不知依据哪个为好,特别是非专业的读者。
1.2.2 统一工作
  在UML之前,已经有一些试图将各种方法中使用的概念进行统一的初期尝试,比较有名的一次是Coleman和他的同事们[Coleman-94]对OMT[Rumbaugh-91]、Booch[Booch-91]、CRC[Wirfs-Brock-90]方法使用的概念进行融合。由于这项工作没有这些方法的原作者参与,实际上仅仅形成了一种新方法,而不能替换现存的各种方法。第一次成功合并和替换现存的各种方法的尝试始于1994 年在Rational 软件公司Rumbaugh与 Booch合作。他们开始合并OMT和Booch 方法中使用的概念,于1995年提出了第一个建议。此时,Jacobson 也加入了Rational公司开始与Rumbaugh和Booch一同工作。他们共同致力于设计统一建模语言。三位最优秀的面向对象方法学的创始人共同合作,为这项工作注入了强大的动力,打破了面向对象软件开发领域内原有的平衡。而在此之前,各种方法的拥护者觉得没有必要放弃自己已经采用的概s念而接受这种统一的思想。
  1996年,OMG发布了征集向外界关于面向对象建模标准方法的消息。UML的三位创始人开始与来自其他公司的软件工程方法专家和开发人员一道制订一套使OMG感兴趣的方法,并设计一种能被软件开发工具提供者、软件开发方法学家和开发人员这些最终用户所接受的建模语言。与此同时,其他一些人也在做这项富有竞争性的工作。1997年9月,所有建议终于被合并成一套UML方法提交到OMG。 最后的成果是许多人共同努力的结果。我们发起了创建UML的工作并提出了一些有益的建议,但是这些建议的最终成型是集体智慧的结晶。
1.2.3 标准化
  1997年11月,UML被OMG全体成员一致通过,并被采纳为标准。OMG承担了进一步完善UML标准的工作。在UML标准通过前,就已经有许多概括UML精华的书出版发行。许多软件开发工具供应商声称他们的产品支持或计划支持UML,若干软件工程方法学家宣布他们将使用UML的表示法进行以后的研究工作。UML的出现似乎深受计算机界欢迎,因为它是由官方出面集中了许多专家的经验而形成的,减少了各种软件开发工具之间无谓的分歧。我们希望建模语言的标准化既能促进软件开发人员广泛使用面向对象建模技术,同时也能带来UML支持工具和培训市场的繁荣,因为不论是用户还是供应商都不用再考虑到底应该采用哪一种开发方法。
1.2.4 核心组员
  提出UML建议或进行UML标准修订工作的核心组员有下列人员:
数据存取公司:Tom Digre
DHR 技术公司:Ed Seidewitz
HP 公司:Martin Griss
IBM 公司:Steve Brodsky, Steve Cook, Jos Warmer
I—Lgix 公司:Eran Gery, David Harel
ICON Computing 公司:Desmond D'Souza
IntelliCorp and James Martin 公司:Conrad Bock, James Odell
MCI 系统企业:Cris Kobryn, Joaquin Miller
ObjecTime 公司:John Hogg, Bran Selic
Oracle 公司:Guus Ramackers
铂技术公司:Dilhar Desilva
Rational 软件公司:Grady Booch, Ed Eykholt, Ivar Jacobson, Gunnar Overgaard,
Karin Palmkvist, James Rumbaugh
SAP 公司:Oliver Wiegert
SOFTEAM:Philippe Desfray
Sterling 软件公司:John Cheesman, Keith Short
Taskon 公司:Trygve Reenskaug
1.2.5 统一的意义
  “统一”这个词在UML中有下列一些相互关联的含义:
* 在以往出现的方法和表示法方面。UML合并了许多面向对象方法中被普遍接受的概念,对每一种概念,UML都给出了清晰的定义、表示法和有关术语。使用UML可以对已有的用各种方法建立的模型进行描述,并比原来的方法描述得更好。
* 在软件开发的生命期方面。UML对于开发的要求具有无缝性。开发过程的不同阶段可以采用相同的一套概念和表示法,在同一个模型中它们可以混合使用。在开发的不同阶段,不必转换概念和表示。这种无缝性对迭代式的、增量式软件开发是至关重要的。
* 在应用领域方面。UML适用于各种应用领域的建模,包括大型的、复杂的、实时的、分布式的、集中式数据或计算的、嵌入式的系统。也许用某种专用语言来描述一些专门领域更有用,但在大部分应用领域中,UML 不但不比其他的通用语言逊色并且更好。
?在实现的编程语言和开发平台方面。 UML可应用于运行各种不同的编程实现语言和开发平台的系统。其中包括程序设计语言、数据库、4GL、组织文档及固件等。在各种情况下,前部分工作应当相同或相似,后部分工作因各种开发媒介的不同而有某种程度上的不同。
* 在开发全过程方面。UML是一个建模型语言,不是对开发过程的细节进行描述的工具。就像通用程序设计语言可以用于许多风格的程序设计一样,UML适用于大部分现有的或新出现的开发过程。尤其适用于我们所推荐的迭代式增量开发过程。
* 在内部概念方面。在构建UML元模型的过程中,我们特别注意揭示和表达各种概念之间的内在联系并试图用多种适用于已知和未知情况的办法去把握建模中的概念。这个过程会增强对概念及其适用性的理解。这不是统一各种标准的初衷,但却是统一各种标准最重要的结果之一。
1.3 UML的目标
  UML语言的开发有多个目标。首先,最重要的目标是使UML一个通用的建模语言,可供所有建模者使用。它并非某人专有,且建立在计算机界普遍认同的基础上,即它包括了各种主要的方法并可作为它们的建模语言。至少,我们希望它能够替代OMT,Booch,Objectory方法以及参与UML建议制订的其他人所使用的方法建立的模型。其次,我们希望 UML 采用源自OMt Booch, Objectory及其他主要方法的表示法,即尽可能地它能够很好地支持设计工作,像封装、分块、记录模型构造思路。此外,我们希望UML 准确表达当前软件开发中的热点问题,比如大规模、分布、并发、方式和团体开发等。
  UML并不试图成为一个完整的开发方法。它不包括一步一步的开发过程。我们认为一个好的软件开发过程对成功的开发软件是至关重要的,我们向读者推荐一本书[Jacobson-99]。UML和使用UML的软件开发过程是两回事,这一些很重要。我们希望UML可以支持所有的,至少是目前现有的大部分软件开发过程。UML包含了所有的概念,我们认为这些概念对于支持基于一个健壮的构架来解决用例驱动的需求的迭代式开发过程是必要的。
  UML的最终目标是在尽可能简单的同时能够对实际需要建立的系统的各个方面建模。UML需要有足够的表达能力以便可以处理现代软件系统中出现的所有概念,例如并发和分布,以及软件工程中使用的技巧,如封装和组件。它必须是一个通用语言,像任何一种通用程序设计语言一样。然而,这样就意味着UML必将十分庞大,不可能像描述一个近乎于玩具一样的软件系统那样简单。现代语言和操作系统比起40年前要复杂多,因为我们对它们的要求越来越多。UML提供了多种模型,不是在一天之内就能够掌握的。它比先前的建模语言更复杂,因为它更全面。但是你不必一下就完全学会它,就像学习任何一种程序设计语言、操作系统或是复杂的应用软件一样。
1.4 UML概念域
  UML的概念和模型可以分成以下几个概念域。
1. 静态结构。
  任何一个精确的模型必须首先定义所涉及的范围,即确定有关应用、内部特性及其相互关系的关键概念。UML的静态组件称为静态视图。静态视图用类构造模型来表达应用,每个类由一组包含信息和实现行为的离散对象组成。对象包含的信息被作为属性,它们执行的行为被作为操作。多个类通过泛化处理可以具有一些共同的结构。子类在继承它们共同的父类的结构和行为的基础上增加了新的结构和行为。对象与其他对象之间也具有运行时间连接,这种对象与对象之间的关系被称为类间的关联。一些元素通过依赖关系组织在一起,这些依赖关系包括在抽象级上进行模型转换、模板参数的捆绑、授予许可以及通过一种元素使用另一种元素等。另一类关系包括用例和数据流的合并。静态视图主要使用类图。静态视图可用于生成程序中用到的大多数数据结构声明。在UML视图中还要用到其他类型的元素,比如接口、数据类型、用例和信号等,这些元素统称为类元,它们的行为很像在每种类元上具有一定限制的类。
2. 动态行为。
  有两种方式对行为建模。一种是根据一个对象与外界发生关系的生命历史;另一种是一系列相关对象之间当它们相互作用实现行为时的通信方式。孤立对象的视图是状态机—当对象基于当前状态对事件产生反应,执行作为反应的一部分的动作,并从一种状态转换到另一种状态时的视图。状态机模型用状态图来描述。
相互作用对象的系统视图是一种协作,一种与语境有关的对象视图和相互之间的链,通过数据链对象间存在着消息流。视图点将数据结构、控制流和数据流在一个视图中统一起来。协作和互操作用顺序图和协作图来描述。对所有行为视图起指导作用的是一组用例,每一个用例描述了一个用例参与者或系统外部用户可见的一个功能。
3. 实现构造
  UML模型既可用于逻辑分析又可用于物理实现。某些组件代表了实现。构件是系统中物理上的可替换的部分,它按照一组接口来设计并实现。它可以方便地被一个具有同样规格说明的构件替换。节点是运行时间计算资源,资源定义了一个位置。它包括构件和对象。部署图描述了在一个实际运行的系统中节点上的资源配置和构件的排列以及构件包括的对象,并包括节点间内容的可能迁移。
4. 模型组织
  计算机能够处理大型的单调的模型,但人力不行。对于一个大型系统,建模信息必须被划分成连贯的部分,以便工作小组能够同时工作在不同部分上。即使是一个小系统,人的理解能力也要求将整个模型的内容组织成一个个适当大小的包。包是UML模型通用的层次组织单元,它们可以用于存储、访问控制、置以管理配及构造包含可重用的模型单元库。包之间的依赖关系是对包的组成部分之间的依赖关系的归纳。系统整个构架可以在包之间施加依赖关系。因此,包的内容必须符合包的依赖关系和有关的构架要求。
5. 扩展机制
  无论一种语言能够提供多么完善的机制,人们总是想扩展它的功能。我们已使UML具有一定的扩展能力,相信能够满足大多数对UML扩充的需求而不改变语言的基础部分。构造型是一种新的模型元素,与现有的模型元素具有相同的结构,但是加上了一些附加限制,具有新的解释和图标。代码生成器和其他的工具对它的处理过程也发生了变化。标记值是一对任意的标记值字符串,能够被连接到任何一种模型元素上并代表任何信息,如项目管理信息、代码生成指示信息和构造型所需要的值。标记和值用字符串代表。约束是用某种特定语言(如程序设计语言)的文本字符串表达的条件专用语言或自然语言。UML提供了一个表达约束的语言,名为OCL。与所有其他扩展机制一样,必须小心使用这些扩展机制,因为有可能形成一些别人无法理解的方言。但这些机制可以避免语言基础发生根本性变化。
1.5 表达式和图表语法
  本书列举了许多演示实际模型的表达式和图表,以及表达式的语法和图表的注释。为了尽量避免将解释说明和实例弄混,本书采用了一些约定的格式。
在图表和文本表达式中实际的表示法部分用Helvetica字体印刷。例如,模型中出现的Helvetica字体的类名是一  个合法的名称。语法表达式中的括弧是一个可能出现在实际表达式中的括弧,它不是实际语法机构的一部分。例如:Order.create(customer,amount)
在连续的文中,关键词和模型元素名都用Helvetica字体印刷,如:Order或Customer。
在一个语法表达式子中,句法单元名可以被实际的一段文字替代,这样的句法单元名用斜体印刷,如:name。斜体和下划线说明替换文本具有给定的性质。例如:
name. Operation(argument,..)
object-name:class
  在语法表达式中,下标和上划线用于指示某种语法性质。例如:
expression 这个表达式是任选的。
  expressionlist 用逗号来分隔一系列表达式。如果出现了零个或者一个重复符号,则不需要分隔符。每个重复符号都要用一个单独的替换符号。如果一个除逗号之外的标点符号出现在下标中,则它是分隔符。
=expressionlist 用上划线来连接两个或多个属于同一单元的可选的或重复出现的项目。在这个例子中,等号和表达式构成一个可以使用或省略的单元。如果只有一个项目,可以不用上划线。
  在图表中,楷体和箭头是注释,它们是解释性说明而不是实际表示法的一部分。其他文字和符号是实际表示法的一部分。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

UML参考手册 目录 译者序 i 前言 iv 第一部分 背景知识 1 1 UML综述 1 1.1 UML简介 1 1.2 UML 的历史 1 1.2.1 面向对象的开发方法 1 1.2.2 统一工作 2 1.2.3 标准化 3 1.2.4 核心组员 3 1.2.5 统一的意义 3 1.3 UML的目标 4 1.4 UML概念域 5 1.5 表达式和图表语法 6 2 模型的性质与目标 7 2.1 什么是模型 7 2.2 模型的用途 7 2.3 模型的层次 8 2.4 模型内容 10 2.5 模型说明了什么? 11 部分 基本概念 13 3 UML初览 14 3.1 UML视图 14 3.2 静态视图 15 3.3 用例视图 16 3.4 交互视图 17 3.4.1 顺序图 17 3.4.2 协作图 18 3.5 状态机视图 19 3.6 活动视图 20 3.7 物理视图 21 3.8 模型管理视图 24 3.9 扩展组件 25 3.10 各种视图间的关系 26 4 静态视图 27 4.1 概述 27 4.2 类元 27 4.3 关系 29 4.4 关联 30 4.5 泛化 33 4.5.1 继承 34 4.5.2 多重继承 34 4.5.3 单分类和多重分类 35 4.5.4 静态与动态类元 35 4.6 实现 36 4.7 依赖 37 4.8 约束 38 4.9 实例 39 4.10 对象图 39 5 用例视图 41 5.1 概述 41 5.2 参与者 41 5.3 用例 42 6 状态机视图 44 6.1 概述 44 6.2 状态机 44 6.3 事件 44 6.4 状态 46 6.5 转换 47 6.6 组成状态 50 7 活动视图 55 7.1 概述 55 7.2 活动图 55 7.3 活动和其他图 57 8 交互视图 58 8.1 概述 58 8.2 协作 58 8.3 交互 58 8.4 顺序图 59 8.5 激活 59 8.6 合作图 60 8.7 模板 62 9 物理视图 64 9.1 概述 64 9.2 构件 64 9.3 节点 65 10 模型管理视图 66 10.1 概述 66 10.2 包 66 10.3 包间的依赖关系 66 10.4 访问与引入依赖关系 67 10.5 模型和子系统 67 11 扩展机制 69 11.1 概述 69 11.2 约束 69 11.3 标签值 70 11.4 构造型 71 11.5 裁制UML 72 12 UML环境 73 12.1 概述 73 12.2 语义职责 73 12.3 表示法职责 74 12.4 程序语言职责 74 12.5 使用建模工具建模 75 12.5.1 工具问题 75 12.5.2 工作进展过程中产生的不一致模型 75 12.5.3 空值和未详细说明的值 75 部分  参考资料 77 13 术语大全 78 14 标准元素 334 部分 附录 343 附录 UML元模型 344 索引 347 译者序 随着计算机硬件性能的不断提高和价格的不断下降,其应用领域也在不断扩大。人们在越来越多的领域希望把更多、更难的问题交给计算机去解决。这使得计算机软件的规模和复杂性与日俱增,从而使软件技术不断地受到新的挑战。60年代软件危机的出现就是因为系统的复杂性超出了人们在当时的技术条件下所能驾御的程度。此后在软件领域,从学术界到工业界,人们一直在为寻求更先进的软件方法与技术而奋斗。每当出现一种先进的方法与技术,都会使软件危机得到一定程度的缓和。然而这种进步又立刻促使人们把更多、更复杂的问题交给计算机去解决。于是又需要更先进的方法与技术。 开发一个具有一定规模和复杂性的软件系统和编写一个简单的程序大不一样。其间的差别,借用G. Booch的比喻,如同建造一座大厦和搭一个狗窝的差别。大型的、复杂的软件系统的开发是一项工程,必须按工程学的方法组织软件的生产与管理,必须经过分析、设计、实现、测试、维护等一系列的软件生命周期阶段。这是人们从软件危机中获得的最重要的教益。这一认识促使了软件工程学的诞生。编程仍然是重要的,但是更具有决定意义的是系统建模。只有在分析和设计阶段建立了良好的系统模型,才有可能保证工程的正确实施。正是由于这一原因,许多在编程领域首先出现的新方法和新技术,总是很快地被拓展到软件生命周期的分析与设计阶段。 面向对象方法正是经历了这样的发展过程,它首先在编程领域兴起,作为一种崭新的程序设计范型引起世人瞩目。继Smalltalk-80之后,20世纪80年代又有一大批面向对象的编程语言问世,标志着面向对象方法走向成熟和实用。此时,面向对象方法开始向系统设计阶段延伸,出现了如Booch86、GOOD(通用面向对象的开发)、HOOD(层次式面向对象的设计)、OOSD(面向对象的结构设计)等一批OOD(“面向对象的设计”或“面向对象的开发”的缩写)方法。但是这些早期的OOD方法不是以面向对象的分析(OOA)为基础的,而主要是基于结构化分析。到1989年之后,面向对象方法的研究重点开始转向软件生命周期的分析阶段,并将OOA和OOD密切地联系在一起,出现了一大批面向对象的分析与设计(OOA&D)方法,如Booch方法、 Coad/Yourdon方法、 Firesmith方法、Jacobson的OOSE、 Martin/Odell方法、 Rumbaugh等人的OMT、 Shlaer/Mellor方法等等。截至1994年,公开发表并具有一定影响的OOA & D方法已达50余种。这种繁荣的局面表明面向对象方法已经深入到分析与设计领域,并随着面向对象的测试、集成与演化技术的出现而发展为一套贯穿整个软件生命周期的方法体系。目前,大多数较先进的软件开发组织已经从分析、设计到编程、测试阶段全面地采用面向对象方法,使面向对象无可置疑地成为当前软件领域的主流技术。 各种面向对象的分析与设计方法都为面向对象理论与技术的发展作出了贡献。这些方法各有自己的优点和缺点,同时在各自不同范围内拥有自己的用户群。各种方法的主导思想以及所采用的主要概念与原则大体上是一致的,但是也存在不少差异。这些差异所带来的问题是,不利于面向对象方法向一致的方向发展,也会给用户的选择带来一些困惑。为此,Rational公司的G. Booch和J. Rumbaugh决定将他们各自的方法结合起来成为一种方法。1995年10月发布了1个版本,称作“统一方法”(Unified Method 0.8)。此时OOSE的作者I. Jacobson也加入了Rational公司,于是也加入了统一行动。1996年6月发布了2个版本UML0.9。鉴于统一行动的产物只是一种建模语言,而不是一种建模方法,(因为不包含过程指导),所以自0.9版起,改称“统一建模语言”(Unified Modeling Language)。在此过程中,由Rationl公司发起成立了UML伙伴组织。开始时有12家公司加入,共同推出了UML1.0版,并于1997年1月提交到对象管理组织(OMG)申请作为一种标准建模语言。此后,又把其他几家分头向OMG提交建模语言提案的公司扩大到UML伙伴组织中,并为反映他们的意见而对UML进一步做了修改,产生了UML1.1版。该版本于1997年11月4日被OMG采纳。此后UML还在继续改进,目前最新的版本是UML1.3。 关于UML的历史、发起的动机、目标、权衡的问题等,这里不想做更多的介绍,因为读者很快会从《UML用户指南》的前言中看到更详细的叙述。这里想着重指出的是以下三点:第一点是UML的三位发起人G. Booch、J. Rumbaugh和I. Jacobson是从事面向对象研究的著名专家,他们各自的方法和著作在该领域均具有很大的影响;二点是众多的大公司加入了UML阵营,为UML的制定和推广提供了强有力的支持;三点是UML经过数年的努力终于被OMG采纳,成为该组织承认的一种标准建模语言。总之,UML是吸收多种方法的成果、凝结许多组织和个人智慧的产物。 UML是一种用于对软件密集型系统进行可视化、详述、构造和文档化的建模语言,主要适用于分析与设计阶段的系统建模。UML最主要的特点是表达能力丰富。因为它从各种OOA&D方法中吸取了大量的概念,并在“UML语义”、“UML表示法指南”、“对象约束语言规约”等UML文献中对这些概念的语义、图形表示法和使用规则作了完整而详细的定义。可以说,UML对系统模型的表达能力超出了以往任何一种OOA&D方法。当然,随之而来的问题是,它的复杂性也超出了以往任何一种方法。 UML的问世引起了计算机软件界的广泛重视,因为它代表了一种积极的方向—多种方法相互借鉴、相互融合、趋于一致、走向标准化。建模语言的标准化将为软件开发商及其用户带来诸多便利。因此,在美国等国家已有大量的软件开发组织开始用UML进行系统建模。学习和使用UML已经成为一种潮流。我国软件界对UML也相当关注。许多研究人员和技术人员已在数年前开始学习和研究UML。更有许多人想学习UML,但苦于找不到合适的书籍。由于UML的复杂性,仅通过UML的标准文献来学习和使用它确实不是一件轻松的事。以往国内外也曾发表过一些介绍或评述UML的著作或论文,但是与UML的丰富内容相比,这些介绍远不能满足读者的要求。 值得高兴的是,UML的三位主要设计者G. Booch、J. Rumbaugh和I. Jacobson现在已亲自撰写了这套详细阐述UML的著作,由Addison Wesley公司于1999年出版。这套著作对UML进行了详细、深入而准确的介绍和论述,而且语言生动、深入浅出、实例丰富、图文并茂。这是一套教会读者掌握和使用UML的教材和指导手册,而不是枯燥的标准文献。对于想学习和使用UML的广大读者,这是一套难得的好书。为了使中国的读者能够更好地从中受益,我们在机械工业出版社的恳切建议下,分头翻译了这三本书,即《UML用户指南》、《UML参考手册》和《统一软件开发过程》。 三本原著都是由这三位作者合著,既各自独立、又有很强的内在联系。其中《UML用户指南》介绍了UML的基础知识,包括UML的术语、规则和语言特点,以及如何运用该语言去解决常见的建模问题,初学者学习UML最好从阅读该书开始。《UML参考手册》对UML的组成和概念作了详细的介绍,包括这些概念的语义、语法、表示法和用途,是一本适合软件专业人员使用的方便而全面的参考读物。《统一软件开发过程》给出了一种以UML作为建模语言进行软件开发的过程指导。其内容不是UML固有的组成部分,因为被OMG采纳的UML只是一种建模语言,并不包含过程指导。实际上,UML是独立于过程的,可以用于不同的软件过程。但是该书介绍的软件开发过程是三位作者在开发UML时一直在头脑中思考的,因此很切合UML的特点。该书对于如何运用UML的概念进行软件开发提供了详细指导,适合软件专业人员使用。 鉴于UML本身以及这套著作的重要意义,译者在翻译这些著作时采取了特别慎重和严谨的态度,力求准确和通顺。在翻译过程中,一个重要问题是要使这套书中的专业术语的中文译法保持一致。这三本书的译者以往曾分别开展过一些与UML有关的研究和写作,对有些术语的译法互有差异。本次翻译工作中,所有译者在机械工业出版社的组织下进行了多次讨论、研究和交流,首先对所有专业术语的译法统一意见,达成共识。其中某些术语的译法颇难定夺:既要确切反映英文本意,又要符合中文习惯,还要避免与国内已习惯于与其它英文词对应的中文相混淆。经过反复切磋,大部分问题都得到满意的解决。对个别有争议的问题,在充分讨论的基础上采取放弃己见、服从大局的态度,从而形成了一个译法一致的词汇表。此后在翻译过程中还经常以各种交流方式进行磋商和勾通。最终使这套丛书能以一致的面貌呈献给读者。我们也希望这些工作能为UML术语今后在中文翻译中的统一贡献一份力量。 在科技著作的翻译中,保证准确和通顺的关键因素不仅仅是外文水平,还取决于译者真正了解所涉及的技术内容。这套著作的内容远远超出了UML的标准文献,因为除了介绍UML的语法、语义、使用规则之外,其中还包含许多学术思想、技术策略和实践经验。在翻译中遇到的许多疑难问题,我们是通过进一步研究UML以及有关的学术和技术问题而得到解决的,从而避免了许多讹误。因此,这套著作的翻译不仅是文字方面的工作,还包含译者在技术上的研究。我们希望这些研究最终通过较准确的翻译文字使读者受益。同时诚恳地希望广大读者对可能存在的疏漏和错误之处给予批评和指正。 译 者 2000年10月于北京 前言 目标 本书是关于统一建模语言UML, Unified Modeling Language)的一本全面实用的参考书,可供软件开发人员,设计人员,项目管理员,系统工程师,程序设计人员,分析员,用户以及研究、设计、开发和理解复杂软件系统的技术人员参考。书中对UML的组成和概念做了详细介绍,包括其语义、语法、表示法和用途。对广大专业软件开发人员来说,这是一本使用方便、内容全面的参考读物。此外,本书还讨论了有关标准文献没有解释清楚的细节问题和UML标准中一些结论的基本原理。 本书不是一本关于UML语言标准文献和UML元模型内部细节的指导手册。对元模型的细节感兴趣的是UML工具的开发者和研究开发方法的专家,一般的软件开发人员无需了解对象管理组织(OMG, Object Management Group)制定的这些不易为人了解的细节。本书涵盖了能够满足绝大部分软件开发人员需要的细节内容,对于某些源于原始标准的细节,往往指明了其出处。 本书所附光盘收录了一些原始标准文献,供读者参考。 在阅读本书之前,读者应具备有关面向对象技术的基本知识。为方便初学者,书后的参考文献中列出了我们和其他作者早期的原作。虽然这些书中采用的某些表示法现在已有了变化,但是一些书中介绍的面向对象的概念仍然有用,如[Rumbaugh-91]、[Booch-94]、[Jacobson-92]和[Meyer-88]等书,所以这里没有必要重新讨论这些基本概念。如果某些读者要个别学习如何用UML对一般问题建立模型,可参考《UML 用户指南》(即将由机械工业出版社出版)一书。那些已经了解如OMT、Booch、Objectory、Coad-Yourdon、Fusion等面向对象方法的读者,完全能够读懂本书,并能够掌握UML及其表示法和语义。若要快速学习UML,阅读《UML 用户指南》很有帮助。 使用UML并不局限于某一种专门的开发过程,本书也不针对某一种开发过程进行讨论和介绍。尽管UML可用于许多开发过程,但它最适用于以一个健壮的构架为中心的迭代的、增量的、用例驱动的开发过程—我们认为这是开发现代复杂软件最适宜的开发过程。《统一软件开发过程》(即将由机械工业出版社出版)[Jacobson-99]就描述了这样一种开发过程,我们认为这是对UML的补充和对软件开发的最好支持。 本书概貌 本书分为三部分:对UML历史和有关建模知识的概述;UML基本概念的综述UML术语和概念大全。 第一部分UML综述UML的历史、目标及使用—帮助理解UML的来源和它能满足的需求。 部分UML视图的简要概述,以便读者能将概念与视图联系起来。该部分综述UML所支持的各种视图,并说明各种构件如何协同工作。该部分首先介绍了一个用到了各种UML视图的例子,接着分介绍每一种视图。概述的目的不是提供一个完整的教材或对各种概念进行全面叙述,而主要是总结性地阐述UML 的各种概念,它是进一步详细阅读本书中术语和概念大全的起点。 部分包括了各种参考信息,这些信息被组织成一个个相关主题以便于查找。本书的主体是一个按字母顺序排列的所有UML概念和组件的大全。所有UML术语,不论重要与否,在大全中都有对应条目,大全尽可能提供全面信息。因此,凡是部分提到的概念,在大全中都有更详细的进一步阐述。相同或相似的信息有时在大全中的许多条目中都予以列出,以便读者查阅。 参考信息部分还包括了一个按字母顺序排列的UML标准元素列表。标准元素是使用UML扩充机制预定义的一个特性。标准元素是UML的扩展部分,相信应该能得到广泛使用。 附录列出了UML的元模型、UML表示法小结和用于专门领域的标准扩展集。附录还给出了一个有关面向对象知识的主要的参考文献,但不包含UML或其他方法的来源。参考文献中所列的许多文献都提及了一些优秀的书籍和杂志文,有兴趣的读者可据此进一步研究这些方法和概念的形成和发展。 大全部分的格式约定 本书的大全部分是一个按字母表顺序组织的条目表,每一条目都较为详细地描述了一个概念。条目下所有的解释性短文按照概念的不同层次组织。高层次概念通常包括其低层次概念的概括性说明,每一低层概念在一段单独的短文中有详细解释。各个短文中所阐述的概念彼此之间有复杂的相互参考关系。大全的这种组织形式使得每个概念在一致的层次中,避免了嵌套性的解释说明来回查找带来的麻烦。高度格式化的编排也有利于相关概念的引用。阅读本书时,不必根据索引查找书中内容,而可以直接到大全正文中查找有关概念和术语。但这种编排格式不适于学习UML语言。建议初学者首先阅读本书部分或其他UML的介绍性读物,如《UML 用户指南》。 大全条目包含以下部分,但并不是所有条目都包含所有部分。 简要定义 概念名用黑体表示,紧接在概念名之后的简要定义用一般字体印刷。概念的定义力求抓住该概念的主旨,以简洁的表达方式描述,因此,它只是一个简要定义。概念的精确涵义参考后面的主体解释短文。 语义 该部分详细解释概念的含义,包括该概念使用和执行顺序上的约束。尽管某些例子要用到表示法,但该部分不包括表示法。首先给出概念的概括语义。对于具有从属结构特性的概念,在概括性语义说明后面的“结构”子标题下有一系列特性名。在大多数情况下,特性按特性名的字母表顺序排列。如果某一特性还有更多的选择项,那么每一选择项均缩排。在更复杂的情况下,特性专门用一段短文叙述,以避免嵌套过多引起混乱。有时,对一个主要概念的说明分散在多个逻辑子项中而不是在一处。此时,附加说明段接在“结构”小节之后或替代了“结构”小节。尽管在结构编排上采取了多种方式,但该结构对读者来说仍然很清晰。 表示法 本节对概念的表示法进行详细的描述。通常,表示法段与其参考的语义描述段平行,并且通常与语义描述段有相同的划分。表示法段一般都有一个或多个图表,用来说明有关概念。为了帮助读者更好地理解表示法,许多图表中用楷体表示注释说明。所有用楷体表示的都是注释说明,不是实际表示法的一部分。 示例 本小节展示如何使用表示法以及有关概念的运用。这些例子一般都针对复杂的或容易产生混淆的情形来列举。 讨论 本节讨论难以理解和把握的问题,澄清疑惑和容易混淆的要点,并且包括一些其他方面的细节问题,这些细节问题有可能分散读者对语义说明段的注意力。只有一小部分的条目有讨论段。 本节还解释了在UML的开发过程中产生的设计结论,特别是有违直觉和容易引起激烈争论的设计结论。 只有一小部分条目有这一节。讨论一般不涉及风格上的简单不同点。 标准元素 本节列出了标准约束、标记、构造型和其他约定,这些是预先规定好的。这一节很少出现。 语法约定 语法表达式。语法表达式是用Sans Serif 字体印刷的经过修改的BNF范式。 标点符号也出现在目标字符串中。 文中的斜体表示能够被目标字符串中另一个字串或另一语法产生式替换的变量,可以包含字符和连字符。 在代码示例中,注释用楷体印刷在代码右侧。 下标或上划线为语法操作,举例如下: expression opt 这个表达式是任选的。 expression list, 用逗号来分隔一系列表达式。如果出现了零个或者一个重复符号,则不需要分隔符。每个重复符号都要用一个单独的替换符号。如果一个除逗号之外的标点符号出现在下标中,则它是分隔符。 =expression opt 用上划线来连接两个或多个属于同一单元的可选的或重复出现的项目。在这个例子中,等号和表达式构成一个可以使用或省略的单元。如果只有一个项目,可以不用上划线。 不允许出现两重嵌套。 字符串。在连续的文本中,关键字、模型元素名称和模型中的字符串例用 Sans Serif字体印刷。 图表。在图表中,楷体和箭头是注释,即,对图中表示法的解释不出现在实际图表中。其他所有文字和符号都是实际的图形表示法。 CD光盘 本书所附光盘以Adobe Reader(PDF)文件格式收录了本书全文,读者可以很容易地查到一个字或短语。本书CD 还包括一个可用鼠标点击操作的目录表,表中包括书中文的目录、索引、Adobe Reader的一小部分以及各个条目主体部分的可扩展热链接。用鼠标简单地点击某一热链接,即可跳到大全中对应该字或短语条目的节中去。 这张CD还收录了OMG的有关UML标准详细说明的全文,这是经过OMG授权认可的。 我们认为这张CD对UML高级用户来说,将是一本非常有用的在线参考书。 如何获取更多信息 有关UML的另外一些原始文件和最新信息及相关方面的主题可在万维网上查找。网址为:www.rational.com和www.omg.org。 致谢 我们感谢所有使UML成为现实的人。首先,我们必须感谢Rational软件公司,特别是Mike Devlin 和 Paul levy,正是他们颇具慧眼地将我们组织在一起,并发起面向对象建模语言的统一工作,历经四年的努力直至这项工作胜利完成。我们还得感谢OMG汇集了各方面的不同的观点,并使这些观点统一成被普遍接受的一致观点,这远非个人的力量所能够做到的。 我们尤其要感谢Cris Kobryn,他既是制定UML标准的技术小组的负责人,并且使众位各执己见的组员达成一致(当然我们三个人达成一致不会有太大的问题)。他的交际才能和技术上的斡旋能力使制定UML的努力没有因各种不同观点的影响而白费。Cris 还复审了全书,给出了大量有益的建议。 我们要对Gunnar 卾ergaard 表示感谢,感谢他对本书做了详细的复审,以及他为完成大量UML文献所做的辛勤劳动。这些文献不适于写入本书,但具有正确和有益的参考价值。 我们还要感谢Karin Palmkvist 对本书做了极为细致的校审,并指出了许多技术上的错误以及语法、措辞和表达方式上的缺陷。 我们还要感谢 Mike Blaha、Conrad Bock、Perry Cole、Bruce Douglass、Martin Fowler、Eran Gery、Pete Mcbreen、Guus Ramackers、Tom Schultz、Ed seidewitz 和Bran Selic ,感谢他们对本书做了复审。 尤其重要的是,我们要对所有对UML思想作出贡献的人表示感谢。他们提出了许多有益的见解和想法,这些想法涉及面向对象技术、软件方法、程序设计语言、用户界面、可视化编程和许许多多计算机方面的其他领域。在此我们不可能一一列举他们的名字,不经过学术上的讨论也难以理解他们的见解所具有的影响,并且本书是一本工程方面的书,并不是历史传记。这些见解有的广为人知,有的却因为提出这些见解的人运气不佳而不被人了解。 要是在一个更私人的场合,我希望能够表达对Jack Dennis教授的感谢。早在25年前,他就对我和我的学生在建模方面的工作进行鼓励。他所在的MIT的 计算结构组(Computations Structures Group)所提出的见解已产生了丰硕的成果,这些见解对UML的影响也是不小的。我还必须感谢Mary Loomis和Ashwin Shah,我和他们一起萌发了OMT的思想,还有我在GE 公司研发中心的同事Mike Blaha、Bill Premerlani、Fred Eddy和 Bill Lorensen,我和他们一起撰写了OMT的书籍。 最后要说的是,没有我的妻子 Madeline 及两个儿子Nick 和 Alex 的耐心支持,就没有UML和这本书。 James Rumbaugh 于加州 Cupertino 1998年11第一部分 背景知识 这一部分介绍了UML的基本原理,包括UML建模的性质和目标以及UML覆盖的所有功能领域。 1 UML综述UML及其应用的一个快速浏览。 1.1 UML简介 统一建模语言UML)是一个通用的可视化建模语言,用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。它记录了对必须构造的系统的决定和理解,可用于对系统的理解、设计、浏览、配置、维护和信息控制。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具UML 是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。UML包括概念的语义,表示法和说明,提供了静态、动态、系统环境及组织结构的模型。它可被交互的可视化建模工具所支持,这些工具提供了代码生成器和报表生成器。UML标准并没有定义一种标准的开发过程,但它适用于迭代式的开发过程。它是为支持大部分现存的面向对象开发过程而设计的。 UML描述了一个系统的静态结构和动态行为。UML将系统描述为一些离散的相互作用的对象并最终为外部用户提供一定的功能的模型结构。静态结构定义了系统中的重要对象的属性和操作以及这些对象之间的相互关系。动态行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制。从不同但相互联系的角度对系统建立的模型可用 于不同的目的。 UML还包括可将模型分解成包的结构组件,以便于软件小组将大的系统分解成易于处理的块结构,并理解和控制各个包之间的依赖关系,在复杂的开发环境中管理模型单元。它还包括用于显示系统实现和组织运行的组件。 UML不是一门程序设计语言。但可以使用代码生成器工具UML模型转换为多种程序设计语言代码,或使用反向生成器工具将程序源代码转换为UMLUML不是一种可用于定理证明的高度形式化的语言,这样的语言有很多种,但它们通用性较差,不易理解和使用。UML是一种通用建模语言。对于一些专门领域,例如用户图形界面(GUI)设计、超大规模集成电路(VLSI)设计、基于规则的人工智能领域,使用专门的语言工具可能会更适合些。UML是一种离散的建模语言,不适合对诸如工程和物理学领域中的连续系统建模。它是一个综合的通用建模语言,适合对诸如由计算机软件、固件或数字逻辑构成的离散系统建模。 1.2 UML 的历史 UML是为了简化和强化现有的大量面向对象开发方法这一目的而开发的。 1.2.1 面向对象的开发方法 利用传统程序设计语言(如Cobol和 Fortran语言)的软件开发方法出现于20世纪70年代,在80年代被广泛采用,其中最重要的是结构化分析和结构化设计方法[Yourdon-79]和它的变体,如实时结构化设计方法[Ward-85]等。这些方法最初由Constantine、Demarco、Mellor、Ward、Yourdon和其他一些人发明和推广,在一些大型系统,特别是和政府签约的航空和国防领域的系统中取得了一定突破,在这些系统中,主持项目的政府官员强调开发过程的有组织性和开发设计文档的完备和充分。结果不总是像预料的那么好—许多计算机辅助软件工程系统(CASE)只是摘录一些已实现的系统设计的报表生成器—尽管如此,这些方法中仍包含一些好的思想,有时在一些大系统中是很有效的。商业应用软件更不愿采用大型的CASE系统和开发方法。大部分商业企业都独立开发本企业内部使用的软件,客户和缔约人之间没有对立关系,而这种关系正是大型政府工程的特征。一般都认为商用系统比较简单,不论这种看法是否正确,反正它不需要经过外界组织的检查。 普遍认为,诞生于1967年的Simula-67是第一个面向对象的语言。尽管这个语言对后来的许多面向对象语言的设计产生了很大的影响,但是它没有后继版本。80年代初Smalltalk语言的广泛使用掀起了一场“面向对象运动”,随之诞生了面向对象的C、C++、Eiffel和CLOS等语言。起初,尽管面向对象编程语言在实际使用中有一定的局限性,但它仍然吸引了广泛的注意力。在smalltalk语言成名约5 年后,第一批介绍面向对象软件开发方法的书籍出现了。包括Shlaer/Mellor [Shlaer-88]和Coad/Yourdon [Coad-91],紧接着又有Booch的[Booch-91]、Rumbaugh/Blaha/Premerlani/Eddy/Lorensen的[Rumbaugh-91]和Wirfs-Brock/Wilkerson/Wiener [Wirfs-Brock-90](注意:图书版权年代往往包括了上一年度7月份以后出版的书)。这些著作再加上   Goldberg/Robson[Goldberg-83] Cox[Cox-86]和Meyer[Meyer-88] 等有关程序语言设计的著作,开创了面向对象方法的先河。第一阶段在1990年末完成。稍晚[Jacobson-92]出版了,它建立在以前的成果的基础上,介绍了一种稍微不同的方法,即以用例和开发过程为中心。 在以后的5年中,大批关于面向对象方法的书籍问世,各有自己的一套概念、定义、表示法、术语和适用的开发过程。有些书提出了一些新概念,但总的来说各个作者所使用的概念大同小异。许多后继出版的书都照搬前人,自己再做一些小的扩充或修改。最早的著作者也没闲着,他们大部分人都更新了自己前期的著作,采纳了其他人一些好的思想。总之,出现了一些被广泛使用的核心概念,另外还有一大批被个别人采纳的概念。即使在被广泛接受的核心概念里,在各个面向对象方法中也有一些小的差异。这些面向对象方法之间的细微比较常使人觉得这些概念不知依据哪个为好,特别是非专业的读者。 1.2.2 统一工作UML之前,已经有一些试图将各种方法中使用的概念进行统一的初期尝试,比较有名的一次是Coleman和他的同事们[Coleman-94]对OMT[Rumbaugh-91]、Booch[Booch-91]、CRC[Wirfs-Brock-90]方法使用的概念进行融合。由于这项工作没有这些方法的原作者参与,实际上仅仅形成了一种新方法,而不能替换现存的各种方法。第一次成功合并和替换现存的各种方法的尝试始于1994 年在Rational 软件公司Rumbaugh与 Booch合作。他们开始合并OMT和Booch 方法中使用的概念,于1995年提出了第一个建议。此时,Jacobson 也加入了Rational公司开始与Rumbaugh和Booch一同工作。他们共同致力于设计统一建模语言。三位最优秀的面向对象方法学的创始人共同合作,为这项工作注入了强大的动力,打破了面向对象软件开发领域内原有的平衡。而在此之前,各种方法的拥护者觉得没有必要放弃自己已经采用的概念而接受这种统一的思想。 1996年,OMG发布了征集向外界关于面向对象建模标准方法的消息。UML的三位创始人开始与来自其他公司的软件工程方法专家和开发人员一道制订一套使OMG感兴趣的方法,并设计一种能被软件开发工具提供者、软件开发方法学家和开发人员这些最终用户所接受的建模语言。与此同时,其他一些人也在做这项富有竞争性的工作1997年9月,所有建议终于被合并成一套UML方法提交到OMG。 最后的成果是许多人共同努力的结果。我们发起了创建UML工作并提出了一些有益的建议,但是这些建议的最终成型是集体智慧的结晶。 1.2.3 标准化 1997年11月,UML被OMG全体成员一致通过,并被采纳为标准。OMG承担了进一步完善UML标准的工作。在UML标准通过前,就已经有许多概括UML精华的书出版发行。许多软件开发工具供应商声称他们的产品支持或计划支持UML,若干软件工程方法学家宣布他们将使用UML的表示法进行以后的研究工作UML的出现似乎深受计算机界欢迎,因为它是由官方出面集中了许多专家的经验而形成的,减少了各种软件开发工具之间无谓的分歧。我们希望建模语言的标准化既能促进软件开发人员广泛使用面向对象建模技术,同时也能带来UML支持工具和培训市场的繁荣,因为不论是用户还是供应商都不用再考虑到底应该采用哪一种开发方法。 1.2.4 核心组员 提出UML建议或进行UML标准修订工作的核心组员有下列人员: 数据存取公司:Tom Digre DHR 技术公司:Ed Seidewitz HP 公司:Martin Griss IBM 公司:Steve Brodsky, Steve Cook, Jos Warmer I—Lgix 公司:Eran Gery, David Harel ICON Computing 公司:Desmond D'Souza IntelliCorp and James Martin 公司:Conrad Bock, James Odell MCI 系统企业:Cris Kobryn, Joaquin Miller ObjecTime 公司:John Hogg, Bran Selic Oracle 公司:Guus Ramackers 铂技术公司:Dilhar Desilva Rational 软件公司:Grady Booch, Ed Eykholt, Ivar Jacobson, Gunnar Overgaard, Karin Palmkvist, James Rumbaugh SAP 公司:Oliver Wiegert SOFTEAM:Philippe Desfray Sterling 软件公司:John Cheesman, Keith Short Taskon 公司:Trygve Reenskaug 1.2.5 统一的意义 “统一”这个词在UML中有下列一些相互关联的含义: 在以往出现的方法和表示法方面。UML合并了许多面向对象方法中被普遍接受的概念,对每一种概念,UML都给出了清晰的定义、表示法和有关术语。使用UML可以对已有的用各种方法建立的模型进行描述,并比原来的方法描述得更好。 在软件开发的生命期方面。UML对于开发的要求具有无缝性。开发过程的不同阶段可以采用相同的一套概念和表示法,在同一个模型中它们可以混合使用。在开发的不同阶段,不必转换概念和表示。这种无缝性对迭代式的、增量式软件开发是至关重要的。 在应用领域方面。UML适用于各种应用领域的建模,包括大型的、复杂的、实时的、分布式的、集中式数据或计算的、嵌入式的系统。也许用某种专用语言来描述一些专门领域更有用,但在大部分应用领域中,UML 不但不比其他的通用语言逊色并且更好。 在实现的编程语言和开发平台方面。 UML可应用于运行各种不同的编程实现语言和开发平台的系统。其中包括程序设计语言、数据库、4GL、组织文档及固件等。在各种情况下,前部分工作应当相同或相似,后部分工作因各种开发媒介的不同而有某种程度上的不同。 在开发全过程方面。UML是一个建模型语言,不是对开发过程的细节进行描述的工具。就像通用程序设计语言可以用于许多风格的程序设计一样,UML适用于大部分现有的或新出现的开发过程。尤其适用于我们所推荐的迭代式增量开发过程。 在内部概念方面。在构建UML元模型的过程中,我们特别注意揭示和表达各种概念之间的内在联系并试图用多种适用于已知和未知情况的办法去把握建模中的概念。这个过程会增强对概念及其适用性的理解。这不是统一各种标准的初衷,但却是统一各种标准最重要的结果之一。 1.3 UML的目标 UML语言的开发有多个目标。首先,最重要的目标是使UML一个通用的建模语言,可供所有建模者使用。它并非某人专有,且建立在计算机界普遍认同的基础上,即它包括了各种主要的方法并可作为它们的建模语言。至少,我们希望它能够替代OMT,Booch,Objectory方法以及参与UML建议制订的其他人所使用的方法建立的模型。其次,我们希望 UML 采用源自OMT Booch, Objectory及其他主要方法的表示法,即尽可能地它能够很好地支持设计工作,像封装、分块、记录模型构造思路。此外,我们希望UML 准确表达当前软件开发中的热点问题,比如大规模、分布、并发、方式和团体开发等。 UML并不试图成为一个完整的开发方法。它不包括一步一步的开发过程。我们认为一个好的软件开发过程对成功的开发软件是至关重要的,我们向读者推荐一本书[Jacobson-99]。UML和使用UML的软件开发过程是两回事,这一些很重要。我们希望UML可以支持所有的,至少是目前现有的大部分软件开发过程。UML包含了所有的概念,我们认为这些概念对于支持基于一个健壮的构架来解决用例驱动的需求的迭代式开发过程是必要的。 UML的最终目标是在尽可能简单的同时能够对实际需要建立的系统的各个方面建模。UML需要有足够的表达能力以便可以处理现代软件系统中出现的所有概念,例如并发和分布,以及软件工程中使用的技巧,如封装和组件。它必须是一个通用语言,像任何一种通用程序设计语言一样。然而,这样就意味着UML必将十分庞大,不可能像描述一个近乎于玩具一样的软件系统那样简单。现代语言和操作系统比起40年前要复杂多,因为我们对它们的要求越来越多。UML提供了多种模型,不是在一天之内就能够掌握的。它比先前的建模语言更复杂,因为它更全面。但是你不必一下就完全学会它,就像学习任何一种程序设计语言、操作系统或是复杂的应用软件一样。 1.4 UML概念域 UML的概念和模型可以分成以下几个概念域。 静态结构。任何一个精确的模型必须首先定义所涉及的范围,即确定有关应用、内部特性及其相互关系的关键概念。UML的静态组件称为静态视图。静态视图用类构造模型来表达应用,每个类由一组包含信息和实现行为的离散对象组成。对象包含的信息被作为属性,它们执行的行为被作为操作。多个类通过泛化处理可以具有一些共同的结构。子类在继承它们共同的父类的结构和行为的基础上增加了新的结构和行为。对象与其他对象之间也具有运行时间连接,这种对象与对象之间的关系被称为类间的关联。一些元素通过依赖关系组织在一起,这些依赖关系包括在抽象级上进行模型转换、模板参数的捆绑、授予许可以及通过一种元素使用另一种元素等。另一类关系包括用例和数据流的合并。静态视图主要使用类图。静态视图可用于生成程序中用到的大多数数据结构声明。在UML视图中还要用到其他类型的元素,比如接口、数据类型、用例和信号等,这些元素统称为类元,它们的行为很像在每种类元上具有一定限制的类。 动态行为。有两种方式对行为建模。一种是根据一个对象与外界发生关系的生命历史;另一种是一系列相关对象之间当它们相互作用实现行为时的通信方式。孤立对象的视图是状态机—当对象基于当前状态对事件产生反应,执行作为反应的一部分的动作,并从一种状态转换到另一种状态时的视图。状态机模型用状态图来描述。 相互作用对象的系统视图是一种协作,一种与语境有关的对象视图和相互之间的链,通过数据链对象间存在着消息流。视图点将数据结构、控制流和数据流在一个视图中统一起来。协作和互操作用顺序图和协作图来描述。对所有行为视图起指导作用的是一组用例,每一个用例描述了一个用例参与者或系统外部用户可见的一个功能。 实现构造。UML模型既可用于逻辑分析又可用于物理实现。某些组件代表了实现。构件是系统中物理上的可替换的部分,它按照一组接口来设计并实现。它可以方便地被一个具有同样规格说明的构件替换。节点是运行时间计算资源,资源定义了一个位置。它包括构件和对象。部署图描述了在一个实际运行的系统中节点上的资源配置和构件的排列以及构件包括的对象,并包括节点间内容的可能迁移。 模型组织。计算机能够处理大型的单调的模型,但人力不行。对于一个大型系统,建模信息必须被划分成连贯的部分,以便工作小组能够同时工作在不同部分上。即使是一个小系统,人的理解能力也要求将整个模型的内容组织成一个个适当大小的包。包是UML模型通用的层次组织单元,它们可以用于存储、访问控制、置以管理配及构造包含可重用的模型单元库。包之间的依赖关系是对包的组成部分之间的依赖关系的归纳。系统整个构架可以在包之间施加依赖关系。因此,包的内容必须符合包的依赖关系和有关的构架要求。 扩展机制。无论一种语言能够提供多么完善的机制,人们总是想扩展它的功能。我们已使UML具有一定的扩展能力,相信能够满足大多数对UML扩充的需求而不改变语言的基础部分。构造型是一种新的模型元素,与现有的模型元素具有相同的结构,但是加上了一些附加限制,具有新的解释和图标。代码生成器和其他的工具对它的处理过程也发生了变化。标记值是一对任意的标记值字符串,能够被连接到任何一种模型元素上并代表任何信息,如项目管理信息、代码生成指示信息和构造型所需要的值。标记和值用字符串代表。约束是用某种特定语言(如程序设计语言)的文本字符串表达的条件专用语言或自然语言UML提供了一个表达约束的语言,名为OCL。与所有其他扩展机制一样,必须小心使用这些扩展机制,因为有可能形成一些别人无法理解的方言。但这些机制可以避免语言基础发生根本性变化。 1.5 表达式和图表语法 本书列举了许多演示实际模型的表达式和图表,以及表达式的语法和图表的注释。为了尽量避免将解释说明和实例弄混,本书采用了一些约定的格式。 在图表和文本表达式中实际的表示法部分用Comic Sans字体印刷。例如,模型中出现的Helvetica字体的类名是一个合法的名称。语法表达式中的括弧是一个可能出现在实际表达式中的括弧,它不是实际语法机构的一部分。例如:Order.create(customer,amount) 在连续的文中,关键词和模型元素名都用Comic Sans字体印刷,如:Order或Customer。 在一个语法表达式子中,句法单元名可以被实际的一段文字用蓝色Comic Sans字体替代,如:name。表达式中的黑色正文表示出现在目标图示上字面上的值。斜体或下划线说明替换文本具有给定的性质。例如: name.operation(argument,...) object-name:class 在语法表达式中,下标和上划线用于指示某种语法性质。例如: expressionopt 这个表达式是任选的。 expressionlist, 用逗号来分隔一系列表达式。如果出现了零个或者一个重复符号,则不需要分隔符。每个重复符号都要用一个单独的替换符号。如果一个除逗号之外的标点符号出现在下标中,则它是分隔符。 用上划线来连接两个或多个属于同一单元的可选的或重复出现的项目。在这个例子中,等号和表达式构成一个可以使用或省略的单元。如果只有一个项目,可以不用上划线。 在图表中,中文楷体、蓝色的文字与箭头是注释,它们是解释性说明而不是实际表示法的一部分。其他文字和符号是实际表示法的一部分 2 模型的性质与目标 本将解释什么是模型,模型有何用途以及如何使用模型。本还要解释模型的不同层次:理想的,部分的和基于工具的。 2.1 什么是模型 模型是用某种工具对同类或其他工具的表达方式。模型从某一个建模观点出发,抓住事物最重要的方面而简化或忽略其他方面。工程、建筑和其他许多需要具有创造性的领域中都使用模型。 表达模型的工具要求便于使用。建筑模型可以是图纸上所绘的建筑图,也可以是用厚纸板制作的三维模型,还可以用存于计算机中的有限元方程来表示。一个建筑物的结构模型不仅能够展示这个建筑物的外观,还可以用它来进行工程设计和成本核算。 软件系统的模型用建模语言来表达,如UML。模型包含语义信息和表示法,可以采取图形和文字等多种不同形式。建立模型的目的是因为在某些用途中模型使用起来比操纵实物更容易和方便。 2.2 模型的用途 模型有多种用途 捕获精确和表达项目的需求和应用领域中的知识,以使各方面的利益相关者能够理解并达成一致。建筑物的各种模型能够准确表达出这个建筑物在外观、交通、服务设施、抗风和抗震性能,消费及其他需求。各方面的利益相关者则包括建筑设计师、建筑工程师、合同缔约人、各个子项目的缔约人、业主、出租者和市政当局。 软件系统的不同模型可以捕获关于这个软件的应用领域、使用方法、试题手段和构造模式等方面的需求信息。各方面的利益相关者包括软件结构设计师、系统分析员、程序员、项目经理、顾客、投资者、最终用户和使用软件的操作员。在UML中要使用各种各样的模型。 进行系统设计。建筑设计师可以用画在图纸上的模型图、存于计算机中的模型或实际的三维模型使自己的设计结果可视化,并用这些模型来做设计方面的的试验。建造、修改一个小型模型比较简单,这使得设计人员不需花费什么代价就可以进行创造和革新。 在编写程序代码以前,软件系统的模型可以帮助软件开发人员方便地研究软件的多种构架和设计方案。在进行详细设计以前,一种好的建模语言可以让设计者对软件的构架有全面的认识。 使具体的设计细节与需求分开。建筑物的某种模型可以展示出符合顾客要求的外观。另一类模型可以说明建筑物内部的电气线路、管线和通风管道的设置情况。实现这些设置有多种方案。最后确定的建筑模型一定是建筑设计师认为最好的一个设计方案。顾客可以对此方案进行检查验证,但通常顾客对具体的设计细节并不关心,只要能满足他们的需要即可。 软件系统的一类模型可以说明这个系统的外部行为和系统中对应于真实世界的有关信息,另一类模型可以展示系统中的类以及实现系统外部行为特性所需要的内部操作。实现这些行为有多种方法。最后的设计结果对应的模型一定是设计者认为最好的一种。 生成有用的实际产品。建筑模型可以有多种相关产品,包括建筑材料清单、在各种风速下建筑物的偏斜度、建筑结构中各点的应力水平等。 利用软件系统的模型,可以获得类的声明、过程体、用户界面、数据库、合法使用的说明、配置草案以及与其他单位技术竞争情况的对比说明。 组织、查找、过滤、重获、检查以及编辑大型系统的有关信息。建筑模型用服务设施来组织信息:建筑结构、电器、管道、通风设施、装潢等等。除非利用计算机存储,否则对这些信息的查找和修改没那么容易。相反,如果整个模型和相关信息均存储在计算机中,则这些工作很容易进行,并且可方便地研究多种设计方案,这些设计方案共享一些公共信息。 软件系统用视图来组织信息:静态结构视图、状态机视图、交互视图、反映需求的视图等等。每一种视图均是针对某一目的从模型中挑选的一部分信息的映射。没有模型管理工具的支持不可能使模型做得任意精确。一个交互视图编辑工具可以用不同的格式表示信息,可以针对特定的目的隐藏暂时不需要的信息并在以后再展示出来,可以对操作进行分组、修改模型元素以及只用一个命令修改一组模型元素等等。 经济地研究多种设计过程中的解决方案。对同一建筑的不同设计方案的利弊在一开始可能不很清楚。例如,建筑物可以采用的不同的子结构彼此之间可能有复杂的相互影响,建筑工程师可能无法对这些做出正确的评价。在实际建造建筑物以前,利用模型可以同时研究多种设计方案并进行相应的成本和风险估算。 通过研究一个大型软件系统的模型可以提出多个实际方案并可以对它们进行相互比较。当然模型不可能做得足够精细,但即使一个粗糙的模型也能够说明在最终设计中所要解决的许多问题。利用模型可以研究多种设计方案,所花费的成本只是实现其中一种方案所花费的成本。 利用模型可以全面把握复杂的系统。一个关于龙卷风袭击建筑物的工程模型中的龙卷风不可能是真实世界里的龙卷风,仅仅是模型而已。真正的龙卷风不可能呼之即来,并且它会摧毁测量工具。许多快速,激烈的物理过程现在都可以运用这种物理模型来研究和理解。 一个大型软件系统由于其复杂程度可能无法直接研究,但模型使之成为可能。在不损失细节的情况下,模型可以抽象到一定的层次以使人们能够理解。可以利用计算机对模型进行复杂的分析以找出可能的“问题点”,如时间错误和资源竞争等。在对实物做出改动前,通过模型研究系统内各组成部分之间的依赖关系可以得出这种改动可能会带来哪些影响。 2.3 模型的层次 针对不同目的,模型可以采取各种形式及不同的抽象层次。模型中所包含的信息量必须对应于以下几种目的: 指导设计思路。在项目早期所建立的高层模型用于集中利益相关者的思路和强调一些重要的选择方案。这些模型描述了系统的需求并代表了整个系统设计工作的起点。早期的模型帮助项目发起者在把精力放在系统的细节问题之前研究项目可能的选择方案。随着设计工作的进展,早期模型被更为精确的模型所替代。没有必要详细保存早期研究过程中的种种选择方案和返工情况。早期模型的目的是帮助获得思路。但最后得到的“思路模型”要在进行详细设计前记录下来。早期模型不需要达到实现阶段的模型的精确程度,无须涉及有关系统实现的一套概念。建立这种模型只使用了UML定义的组件的一个子集,比后期的设计阶段的模型使用的组件要少得多。 当早期模型发展到具有一定精度的完整的视图模型时—例如,分析系统需求的模型—那么要在开发过程进入下一阶段时将其保存下来。不断向模型中填加信息的增量式开发(在这种情况下开发的推理过程也要保存和记录)与一般的针对“死端点”进行研究直到得出正确的解决方案的随意漫步式开发之间一个重要的区别。后一种情况通常使人不知怎么着手,并且根本没有必要对整个开发过程进行记录保存,除非遇到特殊情况需要对开发过程进行回溯。 系统基本结构的抽象说明。在分析阶段和初步设计阶段所建立的模型以关键概念和最终系统的各种机制为中心。这些模型以某种方式与最终系统匹配。但是模型中丧失了细节信息,在设计过程中必需显式地补充这些信息。使用抽象模型的目的是在处理局部细节问题前纠正系统高层次的普遍问题。通过一个仔细的开发过程,这些模型可以发展成最终模型,该过程保证最终获得的模型能够正确实现初期模型的设计意图。必须具备跟踪能力来跟踪从基本模型到完备模型的过程,否则无法保证最终系统正确包含了基本模型所要表达的关键特性。基本模型强调语义,它们不需要涉及系统实现方面的细节。有时确实会出现这种情况:在低层实现方面的差别会使逻辑语义模糊不清。从基本模型到最后的实现模型的途径必须清晰和简明,不论这个过程由代码生成器自动实现还是由设计者人工实现。 最终系统的详细规格说明。系统实现模型包含能够建造这个系统的足够信息,它不仅要包括系统的逻辑语义和语法、算法、数据结构和确保能正确完成系统功能的机制,而且还要包括系统制品的组织决定,这些制品对个人之间的相互协作和使用辅助工具来说十分必要。这种模型必须包括对模型元素进行打包的组件以便于理解和用计算机进行自动处理。这不是目标应用系统的特性,而是系统构造过程应具有的特性。 典型或可能的系统范例。精心挑选的实例可以提高人们的观察能力并使系统的说明和实现有实际效果。然而,即使有非常多的例子,也起不到一段详细定义所起的效果。我们最终希望的是要让模型能够说明一般的情形,这也是程序代码所要做的事情。不过典型的数据结构、交互顺序或对象生命历程的例子对于理解复杂系统很有益处。必须小心使用例子。从逻辑上来说,从一大堆特例中归纳出最一般的情况是不可能的,但是大部分人思考某一问题时总是首先考虑一些被精心挑选出来的有关该问题的例子。范例模型仅是对模型的示例而不带有一般性的描述,因此,人们会觉得这两种模型之间有差异。范例模型一般只使用UML定义的组件的子集。说明型模型和范例模型在建模中都很有用。 对系统全面的或部分的描述。模型可以完全描述一个独立系统,并且不需要参考外部信息。更通常的情况是,模型是用相互区别的、不连续的描述单元组织起来的,每个单元作为整体描述的一部分可以被单独进行存储和操纵。这种模型带有必须与系统其他模型联系在一起的散件。因为这些散件具有相关性和含义,因此它们能够与其他散件通过各种方式结合来构造不同的系统。获得重用是一个好的建模方法的重要目标。 模型要随时间发展变化。深度细化的模型源于较为抽象的模型,具体模型源于逻辑模型。例如,开始阶段建立的模型是整个系统的一个高层视图。随着时间的推进,模型中增加了一些细节内容并引入了一些变化。再随着时间的推进,模型的核心焦点从一个以用户为中心的前端逻辑视图转变成了一个以实现为中心的后端物理视图。随着开发过程的进行和对系统的深入理解,必须在各种层次上反复说明模型以获得更好的理解,用一个单一视角或线性过程理解一个大型系统是不可能的。对模型的形式无所谓“正确和错误”之分 。 2.4 模型内容 语义和表示法。模型包含两个主要方面:语义方面的信息(语义)和可视化的表达方法(表示法)。 语义方面用一套逻辑组件表达应用系统的含义,如类、关联、状态、用例和消息。语义模型元素携带了模型的含义即,它们表达了语义。语义建模元素用于代码生成、有效性验证、复杂度的度量等,其可视化的外观与大多数处理模型的工具无关。语义信息通常被称作模型。一个语义模型具有一个词法结构、一套高度形式化的规则和动态执行结构。这些方面通常分别加以描述(定义UML的文献即如此),但它们紧密相关,并且是同一模型的一部分。 可视化的表达方式以可使人观察、浏览和编辑的形式展示语义信息。表示方式元素携带了模型的可视化表达方式,即语义是用一种可被人直接理解的方式来表达的。它们并未增添新的语义,但用一种有用的方式对表达式加以组织,以强调模型的的排例。因此它们对模型的理解起指导作用。表达式元素的语义来自于语义模型元素。但是,由于是由人来绘制模型图,所以表达式元素并不是完全来自于模型的逻辑元素。表达式元素的排列可能会表达出语义关系的另外含义,这些语义关系很不明显或模棱两可,以至于在模型中不能形式化地表达,但可给人启迪模。 上下文(语境)。模型自身是一个计算机系统的制品,被应用在一个给出了模型含义的大型语境中。这个包括模型的内部组织、整个开发过程中对每个模型的注释说明、一个缺省值集合、创建和操纵模型的假定条件以及模型与其所处环境之间的关系。 模型需要有内部组织,允许多个工作小组同时使用某个模型而不发生过多的相互牵涉。这种对模型的分解并不是语义方面所要求的—与一个被分解成意义前后连贯的多个包的模型相比,一个大的单块结构的模型所表达的信息可能会同样精确,因为组织单元的边界确定会使准确定义语义的工作复杂化,故这种单块模型表达的信息可能比包结构的模型表达得更精确。但是要想有效地工作于一个大的单块模型上的多个工作组不彼此相互妨害是不可能的。其次,单块模型没有适用于其他情况的可重用的单元。最后,对大模型的某些修改往往会引起意想不到的后果。如果模型被适当分解成具有良好接口的小的子系统,那么对其中一个小的、独立的单元所进行的修改所造成的后果可以跟踪确定。不管怎样,将大系统分解成由精心挑选的单元所构成的层次组织结构,是人类千百年来所发明的设计大系统的方法中最可靠的方法。 模型捕获一个应用系统的语义信息,但还需记录模型自身开发过程中的各种信息,如某个类的设计者、过程的调试状态和对各类人员的使用权限的规定。这些信息至多是系统语义的外围信息,但对开发过程非常重要。因此,建立一个系统的模型必须综合考虑两方面。最简便的实现方法是将项目管理信息作为注释加入到语义模型中—,即可以对模型元素用非建模语言进行任意描述。在UML中用文本字符串来表示注释。 文本编辑器或浏览器所使用的命令不是程序设计语言的一部分,同样,用于创建和修改模型的命令也不是建模语言语义的一部分。模型元素的属性没有缺省值,在一个特定的模型中,它们均具有值。然而,对于实际的开发过程,人们要求建立与修改模型时无须详细说明有关的所有细节。缺省值存在于建模语言和支持这种语言的建模工具的边界处。在建模工具所使用的创建模型的命令中,它们是真正的缺省值,尽管它们可能会超过单个的建模工具并用户所期望的那样成为建模工具所使用的通用语言。 模型不是被孤立地建造和使用的。它们是模型所处的大环境中的一部分,这个大环境包括建模工具、建模语言语言编译器、操作系统、计算机网络环境、系统具体实现方面的限制条件等等。系统信息应该包括环境所有方面的信息。系统信息的一部分应被保存在模型中,即使这些信息不是语义信息,例如项目管理注释(在上面已经讨论过)、代码生成提示、模型的打包、编辑工具缺省命令的设置。其他方面的信息应分别保存,如程序源代码和操作系统配置命令。即使是模型中的信息,对这些信息的解释也可以位于多个不同地方,包括建模语言、建模工具、代码生成器、编译器或命令语言等等。本书用UML自身对模型进行解释。但是当进行系统的具体物理实现时,要用到其他用于解释的资源,这些资源对UML来说是不可见的。 2.5 模型说明了什么? 一个模型是一个系统潜在配置的发生器;系统是它的范围,或值。按照模型来进行系统配置是一种理想化的情况。然而,有时模型所要求的种种条件在现实中无法实现。模型还是对系统含义和结构的一般性说明。这种描述是模型的范围,或含义。模型总是具有一定的抽象层次。它包含了系统中的最基本的成分而忽略了其他内容。对模型来说,有以下几方面需要考虑: 抽象和具体。模型包含了系统的基本成分而忽略了其他内容。哪些是基本内容哪些不是基本内容需要根据建模的目的来判定。这不是说要把模型所含信息的精度一分为二,即只有精确和不精确两种情况。可能会存在一系列表达精度不同但逐渐提高的模型。建模语言不是程序设计语言。建模语言所表达的内容可能很不精确,因为多余的详细内容与建模目的无关。具有不同精度级别的模型可应用于同一个项目的各个阶段。用于程序设计编码的模型要求必须与程序设计语言有关。典型的情况是,在早期分析阶段使用高层次的,表达精度低的模型。随着开发过程的深入,所用的模型越来越细化,最终所使用的模型包含了大量的细节内容,具有很高的精度。 说明和实现。一个模型可以告诉我们“做什么”(说明),也可以告诉我们“一个功能是如何实现的———即怎么做”(实现)。建模时要注意区分这两方面。在花大量时间研究怎么做之前很重要的一点就是要正确分析出系统要做什么。建模的一个重要的侧面是对具体实现细节进行抽象。在说明和实现之间可能有一系列相关关系,其中在某层次中的说明就是对它上一层次的实现。 阐述和举例。模型主要是描述性的。模型所描述的是一个个实例,这些实例仅是作为例子才出现在模型中的。大部分实例仅在运行的一部分时间中才存在。有时,运行实例自身是对其他事物的描述。我们把这些混杂对象称做元模型(Metamodel)。更深一层次的看,认为任何事物不是描述性的就是实例性的,这种观点是不符合实际情况的。某一事物是实例还是描述不是孤立区分的,与观察角度有关,大部分事物都可以用多种角度来考察。 解释的变更。用一种建模语言对模型可能会有多种的解释。可以定义语义变更点(semantic variation point)———可能会出现多种解释的地方———给每一个解释一个语义变更名,以便可以标识究竟使用了哪种解释。例如,Smalltalk语言的使用者要避免在系统实现模型种出现多重继承关系,因为Smalltalk语言不支持多重继承。而其他程序设计语言使用者可能会在模型种使用多重继承。语义变更点支持多种具体的实现过程 部分 基本概念 这一部分包括对UML中使用的各概念的综述,以说明在系统建模中如何综合运用这些概念。本部分不详细说明每一个概念,其详细说明可参见本书的大全部分 3 UML初览 本使用一个简单的例子对UML中所使用的概念和视图进行初览。本的目的是要将高层UML概念组织成一系
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值