1、本源码下载地址：http:/ 面向对象基础知识及应用 目录 第一篇 面向对象基本理论.4 第一章 面向对象技术的形成与发展.4 第二章 面向对象的方法学.4 第一节 认知方法学.4 第二节 程序设计方法学.62 第三章 面向对象的基本概念与特征.7 第一节 对象.7 第二节 消息和方法.8 第三节 类和类层次.8 第四节 继承性.9 第五节 封装性.9 第六节 多态性.10 第七节 动态聚束.10 第二篇 UML概貌.11 第一章 前言.11 第二章 UML的目的.11 第三章 UML的发展.12 第四章 UML的专业范围.13 第五章 面向对象大师简介.19 第三篇 Rational Ros
2、e 的使用方法20 第一章 前言.20 第二章 rose 的组成20 第三章 use case view.21 第一节 问题描述.22 第二节 Actor22 第三节 Use case.23 第四章 交互图（alternative diagrams）25 第五章 类图的要素.27 第一节 三个层次的观点.27 第二节 类（Classes）和对象（Objects）.27 第二节 属性（Attributes）.28 第三节 操作（Operations）.28 第四节 关联关系.29 第六章 双向工程.34 第七章 新的开发过程介绍.34 第四篇 San francisco 简介.37 第一章 Sa
3、n Francisco的开发背景.37 第一节 前言.37 第二节 San Francisco Frameworks.38 第三节 结论.40 第二章 San Francisco的体系结构.40 第一节 SF 的多层结构及抽象层次.40 第二节 平台的独立性.41 第三章 San Francisco Foundation.42 第一节 Foundation层的用意42 第二节 Foundation class43 第三节 Foundation Library Class47 第四节 San Francisco的编程模式.47 第四章 San Francisco Common Business
4、Objects483 第一节 Common Business Objects(CBOs)的介绍.48 第二节 Common Business objects 的使用48 第三节 Common Business object Categories48 第五章 San Francisco Core Business Processes50 第一节 什么是 CBP？50 第二节 General ledger 总帐50 第六章 San Francisco Patterns53 第一节 什么是 Pattern?.53 第二节 为何使用 Pattern?.53 第三节 SF Patterns53 第七章
5、San Francisco Utilities55 第一节 配置和服务器管理配置.55 第二节 安全配置.56 第三节 Confilict Control(冲突控制).57 第四节 Schema Mapping.574 第一篇 面向对象基本理论 第一章 面向对象技术的形成与发展 长久以来，人们一直在解决这样一个不合理的现象，即：我们认识一个系统的过程和方 法同我们用于分析、设计和实现一个系统的过程和方法不很一致。 我们对一个系统的认识是一个渐进过程， 是在继承了以往的有关知识的基础上、多次迭 代往复而逐步深化的。在这种认识的深化过程中，既包括了从一般到特殊的演绎，也包括了 从特殊到一般的归纳。
6、 而目前我们用于分析、 设计和实现一个系统的过程和方法大部分是 “瀑 布”型的，即后一步是前一步所提出的需求，或者是进一步发展前一步所得出的结果。因此， 当越接近系统设计（或实现）的后期时，如要对系统设计（或实现）的前期的结果做修改。 就越加困难了。同时也只有在系统设计的后期才能发现在前期所铸成的一些错误。当这个系 统越大、问题越复杂时，由于这种对系统的认识过程和对系统的设计（或实现）过程不一致 所引起的困扰也就越大。 当一个有数十年实践经验的工程师回首往事时， 经常把自己以往所完成的一些工程称为 “遗憾工程” 。这是因为当系统设计开始时，用户对系统的需求是比较笼统和抽象的，而那 时设计者的设
7、计“自由度”较大，设计者可以选用当时已有的原理、方法、工具、环境、构 件和器件去设计系统。但随着时间的推进，用户对系统的需求是越来越细致和具体，但设计 者对系统进行修改的“自由度”却越来越小。还应看到随着时间的推进，原理、方法、工具、 环境、构件和器件的水平是日益提高的，而设计着采用新技术的“自由度”却受到了限制。 因此，系统越大、周期越长、成为“遗憾工程”的可能性就越大。 为了解决上述这种不合理的现象，就应使我们分析、 设计和实现一个系统的方法尽可能 地接近我们认识一个系统的方法，换言之， 就是应使描述问题的问题空间和解决问题的方法 空间在结构上尽可能地一致。这就是面向对象（Object_o
8、riented）方法学的出发点和所追求 的基本原则。 和人们认识世界的规律一样，面向对象的基本方法学认为：客观世界是由许多各种各样 的对象所组成，每种对象都有各自的内部状态和运动规律，不同对象的相互作用和联系就构 成了各种不同的系统，构成了我们所面对的客观世界。当我们设计和实现一个客观系统时， 如能在满足需求的条件下把系统设计成是由一些不可变的（相对固定的）部分所组成的最小 集合，则这个设计就是优秀的，而这些不可变的（相对固定的）部分就被看成是一些不同的 对象。 第二章 面向对象的方法学 第一节 认知方法学 我国著名的科学家钱学森从 80年代发表了一系列有关思维科学（Noetic Scienc
9、e）的论5 文。他指出： “思维科学的目的在于研究人认识客观世界的规律和方法。因此我现在建议思 维科学的一个别名是认识科学 ，英文的 Congnitive Science”钱学森教授认为： “思 维学又可细分为抽象（逻辑）思维学、形象（直感）思维学和灵感（顿误）思维学三个组成 部分。 ”他接着指出：由于认识科学受“认知即计算” （Cognition as Computation）的影响 较深，因此目前的认知科学还很少设计灵感思维的问题。 面向对象技术是属于思维科学中的一项工程技术， 面向对象方法学是属于思维科学中的 一项技术科学。 抽象思维是以抽象的概念为基础的，形象思维是以具体的形象为基础的
10、。从人们认识世 界和获取知识的认知过程来看， 不论是抽象思维还是形象思维，主要是通过一般到特殊的演 绎方法和从特殊到一般的归纳方法来进行的。数百年来，人们对抽象思维的研究已取得一系 列的成果，对于形式逻辑、辩证逻辑和数理逻辑都已建立了有关演义和归纳的较完整的理论 和方法体系。在形象思维中，这种演绎或归纳都是在形象间的“相似”这一关系上进行的。 “客观事物发展中存在着同和变异。只有同，才能有继承；只有变异，事物才能往前发展” 。 当人们利用形象思维去认识客观事物和改造客观事物时，首先是“按照相似原理和关系，把 所要研究的问题区分成一定的相似系统与类别” ， “分类之后， 进一步对事物进行详细的解
11、刨 和分析” ，解刨分析后再进行“综合优化” ，并在事物的运动中和运动相互关系中去考察客观 事物的静态相似和动态相似的关系、宏观相似和微观相似的关系、 纵向相似和横向相似的关 系。 面向对象技术就是遵循上述的认知方法学的基本概念而建立的方法学。 面向对象方法学 认为：客观世界是由各种“对象”所组成，任何事物都是对象，每一个对象都有自己的运动 规律和内部状态，每一个对象都属于某个对象“类” ，都是该对象类的一个元素。复杂的对 象可以是由相对比较简单的各种对象以某种方式而构成的。 不同对象的组合及相互作用就构 成了我们要研究、分析和构造的客观系统。 面向对象方法学认为：通过类比，发现对象间的相似性
12、，即对象间的共同属性，这就是 构成对象类的根据。在按“类” 、 “子类” 、 “父类” （或“超类” ）的概念构成对象类的层次关 系时，如不加特殊说明， 则处在下一层次上的对象可自然地继承位于上一层次上的对象的属 性。 面向对象方法学认为：对于已分成类的各个对象，可以通过定义一组“方法”来说明该 对象的功能，也即是：允许作用于该对象上的各种操作。对象间的相互联系是通过传递“消 息”来完成的，消息就是通知对象去完成一个允许作用于该对象的操作。至于该对象将如何 完成这个操作的细节，则是封装在相应的对象类的定义中的，对于外界是隐蔽的。 综上所述，面向对象的方法学是比较自然地模拟了人类认识客观世界的方
13、式。从方法学 的角度来看， 如果有可能利用现有信息技术的手段来实现形象思维的载体和表示方法，则面 向对象方法学就不只是适用于对抽象 （逻辑） 思维的表示和处理， 也有可能适用于对形象 （直 感）思维的表示和处理。 由于面向对象方法学具有很强的类的概念， 因此它能很直接地模拟人类在认识过程中的 由一般到特殊的演绎功能或由特殊到一般的归纳功能， 类的概念既反映出对象的本质属性又 提供了实现对象共享机制的理论根据。6 第二节 程序设计方法学 一、引言 从 60 年代末开始，计算机软件的作用已得到普遍的重视，各种大型的、复杂的软件系 统已陆续问世。但是，随着软件系统规模的扩大和复杂性的增加，软件的开销
14、（开发时所耗 费的人力、物力和运行时所占用的硬件资源及运算时间）也惊人地增加了，软件系统的可靠 性和可维护性却明显地降低了。人们惊呼这是一种危机，是一种软件危机！产生这种危机的 根本原因是：用冯诺依曼机（Von Neumann Machine）所求解的问题的问题空间的结构与冯 诺依曼机所用的求解问题方法的方法空间结构的不一致性。这种不一致性主要表现在以下 几个方面： 1、语言的鸿沟 冯诺依曼机采用的是面向过程的计算机语言，与人类的自然语言距离较远。 2、程序设计的鸿沟 结构化的系统分析是建立在系统生命周期（System Life Cycle）的概念之上的，即任何 一个系统从概念到实现都是通过以
15、下几个步骤进行的：问题的定义、可行性研究、分析、系 统设计、详细设计、实现和维护。这些步骤在本质上具有冯诺依曼机系统的结构特点，是 软件开发人员从开发软件的立场出发而确定的， 并不是从人们认识客观世界的过程和方法出 发的。由于是从软件开发和冯诺依曼机结构特点的立场出发的，所以或者是遵循函数式的 程序设计的原则（将计算过程看作为函数作用过程），或者是遵循逻辑程序设计的原则（将 计算过程看作为推演过程），但这都不能直接反映出人类认识问题的过程，也未能反映出人 类认识问题的宏观层次。 3、冯诺依曼机的鸿沟 冯诺依曼机的基本特征，即：顺序地执行指令，按地址访问线性的存储空间，数据和 指令在机器内部采用
16、统一的表示形式，以及数字计算 二、 面向对象的程序设计方法 以往的结构化程序设计方法虽然给软件工程带来了许多的改进， 但仍然没能从根本上解 决软件危机。 人们原以为只要多积累一些标准程序库就能在很大的程度上提高软件的可重用 性，减轻人们的劳动量。但实际上除了一些接口十分简单的标准数学函数库外，几乎每次遇 到一个实际问题时，都要针对这个具体的问题作大量的重复而又烦琐的工作。总之，按照以7 往的结构化程序设计方法设计程序时，思维成果的“可重用性”很差。究其原因，是由于在 结构化程序设计方法中，是以“过程”和“操作”为中心来构造系统、设计程序的，而不是 以“对象”和“数据结构”为中心来构造系统、设计
17、程序的。 恩格斯指出： “必须先研究事物，而后才能研究过程。必须知道一个事物是什么，而 后才能觉察这个事物中所发生的变化。 ”因此，我们在认识和研究客观世界时应从“对象” 入手，然后再转向“过程” 。经验也告诉我们，在客观世界以及作为它的影射的软件系统中， “过程”和“操作”是不稳定的、多变的，而“对象”和“数据结构”则相对稳定得多。因 此，如以“过程”入手来设计软件，则思维成果的可重用性必然较差，而以“对象”或“数 据结构”入手，则软件的主体结构比较稳定，其所得的思维成果的可重用性较好。 三、面向对象的计算机体系结构 Smalltalk机和 Ada 机 第三章 面向对象的基本概念与特征 用计
18、算机解决问题时需要用程序设计语言对问题的求解加以描述，实质上，软件是问题 求解的一种表述形式。 面向对象的方法学的基本原则是：按人们通常的思维方式建立问题域 的模型，设计尽可能自然地表现求解方法的软件。 为了实现上述基本原则， 必须建立直接表现组成问题域的事物以及这些事物间的相互联 系的概念，还必须建立适应人们一般思维方式的描述范式。在面向对象的设计方法学中，对 象（Object）和传递消息（Message passing）分别是表现事物及事物间相互联系的概念。类 （Class）和继承（Inheritance）是适应人们一般思维方式的描述范式。方法（Method）是允 许作用在该类上的各种操作
19、。这种对象、类、消息和方法的程序设计范式的基本点在于对象 的封装性（Encapsulation）和继承性。通过封装能将对象的顶和对象的实现分开，通过继承 能体现类与类之间的关系，以及由此带来的动态聚束（Dynamic binding）和实体的多态性 （Polymorphism），从而构成了面向对象的基本特征。 第一节 对象 1. 问题域的对象：客观世界的问题都是由客观世界中的实体及实体之间的相互关系构成 的，客观世界的实体即问题域的对象。 2. 解空间的对象：即计算机用于解决问题的实体 3. 从存储角度看： “对象”是一片私有存储，其中有数据也有方法。 4. 从实现机制看： “对象“是一台自动
20、机，其中私有数据表示对象状态，该状态只能由私 有的方法改变它。 5. 在面向对象的设计中， “对象”是应用域中的建摸实体。所有对象在外观上都表现出相 同的特性，即固有的处理能力和通过传递消息实现的统一的联系方式。 6. 在面向对象的实现中， “对象”是系统中的基本运行实体。换句话说， “对象”是具有特 殊属性（数据）和行为方式（方法）的实体。对象占有存储空间且具有了传统程序设计 语言的数据，如数字、数组、字符串和记录。给对象分配存储单元就确定了给定时刻对8 象的状态。与每一个对象相关的方法定义了该对象上的操作。 第二节 消息和方法 消息用来请求对象执行某一处理或回答某些信息的要求。 程序的执行
21、是通过对象间传递消息来完成的。 消息模式（message pattern）不仅定义了对象所能受理的消息，而且还定义了 对象的固 有处理能力，它是定义对象接口的唯一信息。使用对象只需了解它的消息模式，所以，对象 具有极强的处理能力。 方法：是作用于类对象上的各种操作。 当一个面向对象的程序运行时，一般要做三件事：首先，根据需要创建对象；其次：当 程序处理信息或响应来自用户的输入时要从一个对象传递消息到另一对象（或从用户到对 象）；最后，若不再需要该对象时，应删除它并回收它所占的存储单元。 第三节 类和类层次 一、类 在面向对象程序设计中， “对象”是程序的基本单位，相似的对象和传统语言中的变量
22、和类型关系一样，归并到一类（class）中去。程序员只需定义一个类对象就可以得到若干个 实例（instance）。 具体地说，类由方法和数据组成，它是关于对象性质的描述，包括外部特性和内部实现 两个方面。类通过描述消息模式及其相应的处理能力来定义对象的外部特性，通过描述内部 状态的表现形式及固有处理能力的实现来定义对象的内部实现。 对象是在执行过程中由其所属的类动态生成的 ，一个类可以生成多个不同的对象。同 一个类的所有对象具有相同的性质，即其外部特性和内部实现都是相同的， 但他们可以有不 同的内部状态。 二、类层次（Class Hierarchy） 一个类上层可以有超类（superclass
23、），下层可以有子类（subclass）, 形成一种层次结构。 这种层次结构的一个重要特点是继承性。 三、抽象类（Abstract class） 抽象类是一种不能建立实例的类。 抽象类将有关的类组织在一起，提供一个公共的根， 其他一系列的子类从这个根派生出来。 抽象类刻画了公共行为的特征并将这些特征传给它的 子类。通常一个抽象类只描述与这个类有关的操作接口；或是这些操作的部分实现，完整的9 实现被留给一个或几个子类。有时，抽象类描述了这个类的完整实现，但只有在将这个类和 其他的类组合在一个新的类中时它才有用。抽象类已为一个特定的选择器集合定义了方法， 并且这些方法服从某种语义，所以抽象类的通常用
24、途是用来定义一种协议（或概念）。 判别一个类是否是抽象类，最容易的办法是使用它。如果有必要建立一个类，但是你只 使用从它那继承过来的子类，则这个类是抽象类。例如食肉动物表示一个概念，从它可以得 出更多具体的推论，例如狮子和老虎。你决不会遇到一只动物，简单地认为是食肉动物，它 总是一个具体种类的食肉动物。 一个抽象类包含了操作接口但没有实现，就定义了一种协议。如果包含有某种实现，则 抽象类用缺省实现定义一种协议。通过从多个父类中继承定义，几个协议可被组合在一起。 四、小结 总上所述，类是对一组对象的抽象，它将该种对象所具有的共同特征（包括操作特征和 存储特征）集中起来，由该种对象所共享。在系统构
25、成上，则形成了一个具有特定功能的模 块和一种代码共享的手段。 第四节 继承性 继承性（Inheritance）是自动地共享类、子类和对象中的方法和数据的机制。 继承性是实现从可重用成分构造软件系统最有效的特性，它不仅支持系统的可重用性， 而且还促进系统可扩充性。 第五节 封装性 封装性是一种信息隐蔽技术，用户只能见到对象封装界面上的信息。对象内部对用户是 隐蔽的。封装的目的在于将对象的使用者和对象的设计者分开，使用者不必知道行为实现的 细节，只须用设计者提供的消息来访问该对象。 封装的定义为： 一个清楚的边界，所有的对象的内部软件的范围被限定在这个边界内； 一个接口，这个接口描述这个对象和其他
26、的对象之间的相互的作用； 受保护的内部实现，这个实现给出了由软件对象提供的功能的细节，实现细节不能在定 义这个对象的类的外面访问。 对象用于封装的概念可以和集成电路芯片作一类比。一块集成电路芯片由陶瓷封装起 来，其内部电路是不可见的，也是使用者不关心的。芯片的使用者只关心引脚的个数、电器 参数和功能，通过这些引脚，硬件工程师对这个芯片有了全面的了解。只要将不同的芯片引 脚连在一起， 就可以组装一个具有一定功能的产品。 软件工程师通过使用类也努力达到这个 目的。面向对象的语言以对象协议（Protocol）或规格说明（Specification）作为对象的外界面。 协议指明该对象所能接受的消息，在
27、对象的内部，每个消息响应一个方法，方法实施对数据 的运算。对数据方法的描述是协议的实现部分或叫类体。10 显式地将对象的定义和对象的实现分开是面向对象系统的一大特色。封装本身即模块 性，把定义模块和实现模块分开，就使得用面向对象技术所开发设计的软件的维护性、修改 性大为改善，这也是软件技术追求的目标之一。 第六节 多态性 所谓多态（Polymorphic）即一个名字可具有多种语义。 在面向对象系统中，对象封装了方法。恰恰要利用诸如重名、重定义让各对象自己去释 意执行，而且这种多义性决不会带来混乱。这对于需求分析、模型设计是极为有利的，因为 这些工作不需要设计具体的数据结构和类型，只是着重于揭示
28、系统的逻辑合理性。 第七节 动态聚束 聚束（binding）是指一个程序经编译、连接成为可运行的目标码，就是将执行代码聚 束在一起。传统的程序设计语言编写的程序在运行之前即可聚束，我们称之为静态聚束 （Static binding）,面向对象语言是在程序正在执行的时候才发生聚束，称之为动态聚束 （Dynamic binding）. 应该看到，静态聚束是在编译时刻完成的，运行效率高，但修改维护工作量大；而动态 聚束是在运行时刻完成的，运行效率梢低，但它所带来的好处（如增删自如）符合近代软件 对可重用、可修改和可扩充等要求。随着 CPU 运行速度的日益提高，运行效率将不会成为 主要矛盾。11 第二
29、篇 UML概貌 第一章 前言 统一建模语言（Unified Modeling Language，简称 UML）是一种用于描述、视化和构 架软件系统以及商业建模的语言。它代表了在大型、复杂系统的建模领域得到认可的“优秀 的软件工程方法” 。 UML定义包括如下文档： UML概要 简要介绍 UML，并指导您对其它文档的阅读。 UML语义 介绍 UML的规范元模型。UML元模型是 UML语义的基础，是用 UML 表示法和简洁的自然语言表达的。UML词汇是该文档的附录。 UML表示法指南 介绍 UML表示法，并提供了一些范例。 UML特定进程扩展 用扩展机制和特定进程的图符来描述 UML特定进程的扩展
30、。 这些文档可以从美国 Rational 公司的网络站点 http:/获得。 第二章 UML的目的 在系统需求日益复杂的情况下，建模越来越重要。 正是因为感到无法对整个复杂的系统全面地把握， 所以我们需要建模。人对复杂性的认 识是有局限性的，对程序员来说， 仅仅几行源代码是不能对整个开发项目提供一个全面认识 的，而模型则可以使设计者从全局上把握系统及其内部的联系，而不至于陷入每个模块的细 节之中。 建模的意义重大， “分而治之” ，这是一个古老而有效的概念。可以想象，当我们把特别 复杂而困难的问题细化分解之后，一次只是设法解决其中一个的时候，事情就容易解决得多 了。模型的作用就是使复杂的信息关
31、联简单易懂，它使我们容易洞察复杂堆砌而成的原始数 据背后的规律，并能有效地使我们将系统需求映射到软件结构上去。 之所以为系统建模，是因为我们不可能全面的理解任何一个复杂的系统。随着系统复杂 性的增加，先进的建模技术越来越重要。一个项目的成功有许多原因，严格的建模语言标准 是其中一个重要的因素。建模语言应该包括以下几个部分： 模型元素 基本的建模概念和语义 表示法 模型元素的符号表示 准则 行业习惯用法12 第三章 UML的发展 一、UML 0.8 0.91 UML的前身 从 70 年代中期到 80 年代末期，随着方法学家在实践中对面向对象的分析和设计方法的 探索，出现了最初的面向对象的建模语言
32、。 独立的建模语言从 1989 年的不到 10 种猛增到 1994 年的 50多种。即使是在这种“方法大战”的推动下，许多面向对象技术的使用者还是 很难对某种建模语言表示完全满意。到了 90 年代中期，改进的方法陆续出现，最引人注目 的有 Booch 93 方法、不断完善的 OMT 技术、和 Fusion方法。这些方法不断吸收其他方法 的优点，产生了一批卓越的软件开发技术，如 OOSE、OMT2 和 Boch 93 方法。这些软件 工程方法都是完整的技术，但都只在某些方面具有优势。简单的说，OOSE 方法是面向 use case 的方法，对商业工程设计和需求分析提供了良好的支持；OMT2 方法
33、便于分析和开发 数据密集的信息系统；而 Booch93 方法则更注重工程的设计和构造阶段，在开发工程密集 的应用方面具有优势。 Booch、Rumbaugh和 Jacobson联合行动 UML的开发始于 94 年8 月，瑞理软件公司的 Grady Booch和 Jim Rumbaugh着手进行 统一 Booch 方法和 OMT（对象建模技术）的工作。由于 Booch 和 OMT 方法有很多相似之 处，而且被公认为世界范围内面向对象方法的先驱，Booch和 Rumbaugh决定合作设计一门 统一的建模语言。90 年 10 月发行了统一方法（The Unified Method）的初版（0.8 版
34、）。同年 秋天，Ivar Jacobson加盟联合开发小组，并力图把 OOSE 方法（面向对象的软件工程方法） 也统一进来。 作为 Booch、OMT 和 OOSE 方法的创始人，Boch、Rumbaugh 和 Jacobson 决定开发 UML 有三个原因：首先，这些方法有许多相似之处，通过这项工作，消除可能会给使用者 造成混淆的不必要的差异是非常有意义的。其次，通过对语义和表示法的统一，可以稳定面 向对象技术的市场，使工程开发可以采用一门成熟的建模语言，开发工具的设计者可以集中 精力设计更优越的性能。第三，他们希望通过统一的工作，使所有的方法更进一步，积累已 有的经验，解决以前没有解决好的
35、问题。 当 Booch，Rumbaugh和 Jacobson着手进行统一工作时，他们制订了四个目标： l 使用面向对象的概念构造系统（不仅仅指软件系统）的模型。 l 建立设计框架与代码框架间明确的联系。 l 解决复杂的、以任务为中心的系统内在的规模问题。 l 开发人与机器通用的建模语言。 开发应用于面向对象的分析和设计的表示法并不象设计一门编程语言那么简单。首先， 设计者要考虑： 表示法是不是应该能够表达系统的开发需求？是不是要把表示法设计成形象 化的语言？其次，设计者需要在表达能力和简洁程度之间作一下折衷：过于简洁的表示法会 限制应用的范围；而过于复杂的表示法又会吓倒刚入门的使用者。 如果设
36、计者是在统一已有 的一些方法，则还要照顾到过去的基础：改变过多会使原来的使用者感到混乱。不作改进， 又难以吸引更多的使用者。UML的定义力图在这几个方面平衡利弊。 经过 Booch，Rumbaugh和 Jacobson的不懈努力，UML 0.9 和 0.91 版终于在 1996 年的13 六月和十月分别出版。1996 年间，UML开发者们虚心求教并收到了来自社会各界的反馈。 他们据此作了相应的改进，但显然还有很多工作需要完成。 二、UML 1.0 与 UML 合作者 1996 年，一些组织逐渐认识到 UML对其业务的战略价值。几个愿意为 UML贡献力量 的组织联合组成了 UML 合作者协会。那
37、些对 UML 定义 1.0 版的开发作出很大贡献的组织 有：Digital Equipment Corp.、HP、iLogix、Intellicorp、IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、瑞理软件（Rational Software）公司、TI和 Unisys。这些 合作者联合开发了 UML 1.0，一门严格定义、功能强大、应用广泛的建模语言。 UML 的合作者们提出了许多内行的建议，包括：OMG 和 RMODP 技术、商业建模、 状态机语义、类型、界面、构件、协同、求精、框架、分配和元元模型。以上所列仅是其中 的一部分。UM
38、L 1.0 是集体智慧的结晶。 三、UML 的现状 1997 年OMG已决定接纳 UML作为对象建模方法的标准。 UML 致力于满足其基础方法的使用者和科学团体的需要。许多方法学家、组织和工具 开发者已经在使用 UML。UML 在 Booch、OMT 和 OOSE 等先进方法的基础上建立起类似 的语义和表示法， 并且采纳了 UML合作者和社会各界的建议， 因此很容易得到广泛的认可。 UML 对各种优秀方法的统一有两方面的含义：首先，它有效的消除了各种建模语言之 间许多不必要的差异。更重要是，它统一了各种方法对不同类型的系统（商业系统或软件系 统）、不同的开发阶段（需求分析、设计和实现）以及不同
39、的内部概念的不同观点。 第四章 UML的专业范围 统一建模语言（UML）是用来对软件密集系统进行描述、构造、视化和文档编制的一 种语言。 首先，也是最重要的一点，统一建模语言融合了Booch、OMT和 OOSE 方法中的概念， 它是可以被上述及其他方法的使用者广泛采用的一门简单、一致、通用的建模语言。 其次，统一建模语言扩展了现有方法的应用范围。特别值得一提的是，UML 的开发者 们把并行分布式系统的建模作为 UML 的设计目标，也就是说，UML 具有处理这类问题的 能力。第三，统一建模语言是标准的建模语言，而不是一个标准的开发流程。虽然 UML的应 用必然以系统的开发流程为背景，但根据我们的
40、经验，不同的组织，不同的应用领域需要不 同的开发过程。举个例子来说，开发错综复杂的软件是非常有趣的工作，但开发这种软件与 构造严格实时的航空电子系统是大不一样的，后者是性命攸关的大事。因此我们首先把精力 集中在设计通用的元模型上（统一不同方法的语义），其次是建立通用的表示法（提供对这 些语义的形象化的表达）。虽然 UML 的开发者们将继续倡导从用例驱动到体系结构为中心14 最后反复改进、 不断添加的软件开发过程， 但实际上设计标准的开发流程并不是非常必要的。 一、UML 的基本组成 UML 的基本成分什么是呢？这个问题可以从两个方面来回答：UML 的定义及如何应 用 UML构造系统框架。 1、
41、UML 定义的基本内容 为了有助于对统一建模语言本身（ “内部”观点）的理解，文档划分为 UML简介（本 文档）、UML 语义、UML 表示法指导和 UML 特定进程扩展这几部分。下面，将对这些文 档的内容作简单的介绍。除了这些文档之外，其他有关 UML的理解、范例以及习惯用法等 内容的书籍也将陆续出版。 （1）UML语义 该文档通过叙述性的语言和 UML表示法对 UML精确模型作了详细描述。 UML开发者 们用UML表示法及英文说明文字提出了一个严格的元模型。 提出这个元模型是为了给UML 要素的语法和语义作简单、一致的定义性说明。它把UML的语义与因人而异的最佳表达方 法相分离，从而使开发
42、者们能够对 UML的语义达成一致意见。另外，这个元模型还使开发 小组有可能通过（从某种意义上来说）统一 UML的元素来大大简化 UML。（例如，我们发 现类型、模式和用例这三个概念之间存在着相似之处。）开发者们希望通过描述元模型的语 义，从而选择那些能更精确的表达元模型的规范技术。 元模型是描述模型的语言。现在指对象模型。元模型非常重要，因为它能对模型的语法 和语义提供简单、通用、明确的描述。在模型里，元的“层次”有点儿任意。UML 的开发 者们有意识的选择语义丰富的元“层次” ，因为这是工具交互和复杂系统设计所依赖的语义 丰富的协议的必然要求。 （2）UML表示法指南 UML 表示法指南集中
43、介绍了 UML 的表示法，并给出了一些范例。当开发者或开发工 具应用 UML建造系统模型时，图形符号和文本语法是最直接可见的部分（ “外部”观点）。 这些图形符号和文字所表达的是应用级的模型。应用级模型是 UML元模型的实例。 （3）UML进程扩展 该文档主要介绍 UML 扩展机制中的进程特定的扩展（例如，构造型, 特征值和限制条 件等），以及其相应的符号（如果有的话）。 2、开发过程 设计怎样的模型对问题的解决及系统的开发有重要的影响。抽象，即抓住相关细节、忽 略无关信息，是学习和交流的基本方法。因为： 复杂的系统可以从系统模型的不同角度来更好的理解。 只从一个角度来考察系统是不够15 的。
44、一个模型可以表示成不同的抽象层次。优秀的模型是同实际相联系的。UML 从考察系 统的不同角度出发，定义了下列图表： Use case图 类图 行为图 状态转换图 活动图 序列图（时序图） 协同图 实现图 组件图 安装维护图 这些图表从不同的侧面对进行分析或设计的系统进行描述。 系统模型把这些不同的侧面 综合成一致的整体，便于系统的分析和构造。尽管 UML和其他开发工具还会设计出许多派 生的视图，但上述这些图表和其他辅助性的文档是软件开发人员所见的最基本的结构。上述 图表将在文档 UML表示法指南中详细介绍。 3、表示法和语义的发展史 UML是在 Booch、 OMT、 OOSE 等面向对象的方
45、法及许多其他来源的基础上发展起来的。 UML包含了来自许多人员的各种不同的观点，也受到了非面向对象方法的影响。UML表示 法混合了不同的图形表示方法，剔除了其中容易引起混淆、冗余的、或者很少使用的符号， 同时增添了一些新的符号。UML 中的概念来自于面向对象技术领域中众多人员的思想。 UML 开发者们并没有提出其中大部分的观点，而只是对优秀的面向对象和计算机科学的方 法加以选择和综合。表示法和语义的实际发展历程是非常复杂的， 这里介绍的只是一些简单 的背景知识，而不是详细的发展史。 UML用例图与 OOSE方法类似。 UML的类图综合了 OMT、Booch等面向对象方法中的类图。各种图表可以通
46、过进程特 定的扩展（如构造型及相应的符号）来支持其他的建模方法。 UML的状态图是对 David Harel 所提出的状态图的改进。UML活动图的基本语义与状 态图大致相同，它类似于许多方法（包括面向对象技术以前的一些方法）中的工作流图。 可以在许多面向对象的方法中发现 UML 时序图的影子（如交互作用、消息流 、事件 流）等，甚至可以追溯到面向对象技术以前的方法。UML的协同图是通过对 Boch方法的 对象图、Fusion方法的对象交互作用图以及其他一些方法中的相关图表改造而来的。 协同是比较基本的建模元素，它构成了模式的基础。 UML 的实现图（构件 和安装维护图）是在 Booch 方法中
47、的模块和进程图（处理器关 系图、处理器图）的基础上发展起来的，但 UML的实现图以构件为中心而不是以模块为中 心，相互之间的联系也更紧密。 构造型（stereotype）是 UML扩展机制中的一种，它扩展了 UML元模型的语义。构造 型还可以附带用户定义的符号，以满足特定开发流程的需要。 上述的这些概念有着深远的渊源和影响，只能进行简单扼要的介绍。UML 实际上是计 算机科学和软件工程学长期发展的产物。16 二、UML 未涉及的领域 UML 定义 1.0 版并没有提出开发工具和开发流程的标准，这是因为两者所考虑的问题 有很大不同。标准化的建模语言是开发工具和流程的必要基础。 1、工具 对象管理
48、小组的 RFP（OADTF RFP1）是推动 UML开发的重要力量。RFP 的初衷是增 强开发工具彼此之间相互协作的能力，但实际上，开发工具及其可协作性在很大程度上依赖 于一致的语义和表示法定义（如 UML）。虽然 UML 定义的是语义元模型，而不是工具元模 型，但这两者是非常接近的。在语义和表示法定义的基础上，很容易制订出一致的开发工具 交互标准。 在向OMG提交UML的同时， UML开发者们还提交了一个依从UML的工具接口定义。 这个定义在大批量数据传送的编码和语法方面采用了CDIF/ EIA标准。 UML 文档中包括一些给工具开发者的有关具体实现的建议，但并没有对所有的问题作 出回答。例
49、如，文档中没有关于图表设计、色彩、用户索引、生动性等特点的内容。 2、开发流程 许多组织都把 UML 作为框架设计的通用语言，并在各种不同类型的开发流程中使用 UML的图表。UML并不依赖于特定的开发流程方法，定义标准的开发流程并不是 UML开 发的计划，也不是OMG 的要求。 但 UML的开发者确实认识到了开发流程的重要作用。是否存在一个严格定义、管理方 便的工作流程是区别项目水平高低的关键。繁重的编程并不是持久的商业开发方法。 开发流 程可以 1）指导制订开发小组的行动规划，2）确定开发的框架，3）从总体上指导个人和开 发小组的工作，4）提供监督和衡量项目成果及开发工作的标准。 项目的流程在本质上要满足不同组织、 不同风格、 不同应用领域的需要。 在某些情况 （例 如错综繁绕的软件的开发）下有效的开发流程方法很可能在其他情况（如严格实时的系统开 发）下效果并不是很好。应用领域、实现技术和开发小组的技能在很大程度上决定了工作流 程的选择。 Booch、OMT、OOSE 以及许多其他方法都有自己严格定义的开发流程，UML 可以支 持其中大部分的开发流程方法。 虽然人们已经认识到了开发流程的重要作用，但流程标准化 的问题还没有引起足够的重视。 目前， 更有
