1、UML 是面向对象的建模语言 建模并不是软件开发领域内的概念。在机械设计、建筑设计甚至应用数学 领域，都广泛的采用建模的方法。例如，机械制图就是建模。建模的基本原理 是对现实世界的我们关心的主要问题提供了一个抽象，以让人们忽略无关的细 节而把注意力放到系统的重要部分来思考系统。许多工作形式都依赖模型来理 解复杂的、真实世界的系统。模型被用在很多的方面：预期系统的质量，当系 统的某些方面变化时推理特定的属性，和为各种涉众沟通关键的系统特征。 在软件开发过程中，也需要对软件系统进行建模。建模是为了传达系统应 包含的结构和行为；建模为了可视化系统架构并能掌控它；建模为了更好地理 解我们正在建立的系统
2、；建模经常揭示简化和重用的机会；现代的软件开发采 用面向对象的角度进行建模，所有软件系统都用对象或类作为其主要构造块。 简单地讲，通常要从问题空间或解空间的词汇中找出对象；类是对具有共同性 质的一组对象的描述。每一个对象都有标识（你能够对它命名，以区别于其他 对象）、状态（通常有一些数据与它相联系）和行为（使你能对该对象做某 些事，它也能为其他对象做某些事）。 例如，可考虑把一个简单的计账系统的体系结构分成三层：用户接口层、 中间件层和数据库层。在用户层，你将找出具体的对象，如按钮、菜单和对话 框。在数据库层，你将找出具体的对象，如从问题域中找出描述实体的表，它 包含顾客、 产品和订单项。 在
3、中间件层， 你将找出诸如交易、 商业规则等对象， 以及更高层次上的问题实体，如顾客、产品和订单。 可以肯定地说，面向对象方法是软件开发方法的主流部分，其原因很简单， 因为事实已经证明， 它适合于在各种问题域中建造各种规模程度和复杂度的系 . . 统。此外，当前的大多数程序语言、操作系统和工具在一定的方式上都是面向 对象的，并给出更多按对象来观察世界的理由。面向对象的开发为使用构件技 术（如 Java Beans 或 C O M + ）装配系统提供了概念基础 3)UML 是统一建模语言 什么是“统一”？它表示UML 不仅仅是某个软件厂商的内部标准， 而是公 开的、业界广泛遵循的面向对象建模的标准
4、。另外，UML是由 Grady Booch 的 Booch方法、 James Rumbaugh 的对象建模技术（ OMT ）和 Ivar Jacobson的 面向对象软件工程（ OOSE ）及其他一些方法的基础上发展起来的，这也是“统 一”的含义之一。 第4节UML 不是什么？ 1)UML 不是方法论 UML 不能对问题域提供一套解决方案， 这是系统分析员和软件设计师的职责。 它仅仅是一种语言，支持UML 标准的软件也仅仅是一套系统建模工具，它就像 一般的编程语言一样，比如C# 语言本身并不能帮你解决实际的业务问题，具体 问题如何解决，就需要编程人员很好地使用C#语言来编程实现。总的来说，系
5、统的分析思路、 设计与构架思想是来自于系统分析员与软件设计师本身的，而不 是来自于UML 。而系统分析员和软件设计师对系统的分析与设计能力却是来源 于多年的项目分析、设计经验。 . . 2)UML 不是必须的。 一个伟大的系统分析师或软件构架师可以不懂UML ，但不能没有超强的分 析设计能力。不懂 UML 会使得互相之间直观的交流变得困难，但不一定会影响 分析师与构架师的表达和交流能力，如果他们之间使用另一种方式进行交流， 或许效果会比 UML 更好。 3)UML 不是一定的。 在使用 UML建模的时候，并没有一个“绝对正确”或者“绝对错误”的模 型，只能说模型的合理或者不合理。即使同样一个软
6、件系统，不同的建模人员 可能强调不同的重点和侧面，也可以采用不同的视图分解。这都是可以的。对 于一个软件系统来说， UML如何建模，关键是要把握如何表达建模者希望向读 者沟通的重点和要点。 只要能够向读者高效的传达建模者希望表达的想法和意 图，如何画 UML 图倒是在其次。 第二章对系统边界建模 第1节概述 当用例视图在外部用户前出现时，它捕获到系统、子系统或类的行为。它将 系统功能划分成对参与者(即系统的理想用户 ) 有用的需求。而交互功能部分被称 作用例。用例使用系统与一个或多个参与者之间的一系列消息来描述系统中的交 互作用。参与者可以是人, 也可以是外部计算机系统和外部进程。下图表述了一
7、 个电话目录销售的用例视图。此例是实际系统简化后的例子。 . . 第2节 参与者 参与者是与系统、子系统或类发生交互作用的外部用户、进程或其他系统的 理想化概念。 作为外部用户与系统发生交互作用，这是参与者的特征。 在系统的 实际运作中， 一个实际用户可能对应系统的多个参与者。不同的用户也可以只对 应于一个参与者， 从而代表同一参与者的不同实例。比如，一个人在不同的时刻 可以分别是一家商店的顾客和收银员。 每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互作用 （因此也与用例所在的系统或类发生了交互作用），而参与者的内部实现与用 例是不相关的 , 参与者可以被一组定义它的状态的属性
8、充分描述。 参与者可以通过泛化关系来定义 , 在这种泛化关系中，一个参与者的抽象描 . . 述可以被一个或多个具体的参与者所共享。 参与者可以是人、另一个计算机系统或一些可运行的进程。在图中，参与者 用一个名字写在下面的小人表示。 第3节用例 用例是外部可见的一个系统功能单元 , 这些功能由系统单元所提供，并通过 一系列系统单元与一个或多个参与者之间交换的消息所表达。用例的用途是在不 揭示系统内部构造的情况下定义连贯的行为。用例的定义包含用例所必需的所有 行为执行用例功能的主线次序、标准行为的不同变形、 一般行为下的所有异常 情况及其预期反应。 从用户角度来看 , 上述情况很可能是异常情况；
9、从系统角度 来看, 它们是必须被描述和处理的附加情况。 在模型中 , 每个用例的执行独立于其他用例， 虽然在具体执行一个用例功能时 由于用例之间共享对象的缘故可能会造成本用例与其他用例之间有这样或那样 的隐含的依赖关系。 每一个用例都是一个纵向的功能块，这个功能块的执行会和 其他用例的执行发生混杂。 用例的动态执行过程可以用 U M L 的交互作用来说明，可以用状态图、顺序 图、协作图或非正式的文字描述来表示。用例功能的执行通过类之间的协作来实 现。一个类可以参与多个协作，因此也参与了多个用例。 在系统层，用例表示整个系统对外部用户可见的行为。一个用例就像外部用 户可使用的系统操作。 然而，它
10、又与操作不同， 用例可以在执行过程中持续接受 参与者的输入信息。 用例也可以被像子系统和独立类这样的小单元所应用。一个 内部用例表示了系统的一部分对另一部分呈现出的行为。例如，某个类的用例表 . . 示了一个连贯的功能， 这个功能是该类提供给系统内其他有特殊作用的类的。一 个类可以有多个用例。 用例是对系统一部分功能的逻辑描述，它不是明显的用于系统实现的构件。 非但如此，每个用例必须与实现系统的类相映射。用例的行为与类的状态转换和 类所定义的操作相对应。 只要一个类在系统的实现中充当多重角色，那么它将实 现多个用例的一部分功能。 设计过程的一部分工作即在不引入混乱的情况下，找 出具有明显的多重
11、角色的类， 以实现这些角色所涉及的用例功能。用例功能靠类 间的协作来实现。 用例除了与其参与者发生关联外，还可以参与系统中的多个关系: 用例用一个名字在里面的椭圆表示，用例和与它通信的参与者之间用实线连 接。 虽然每个用例的实例是独立的，但是一个用例可以用其他的更简单的用例来 描述。这有点像一个类可以通过继承它的超类并增加附加描述来定义。一个用例 可以简单地包含其他用例具有的行为， 并把它所包含的用例行为做为自身行为的 一部分，这被称作包含关系。 在这种情况下， 新用例不是初始用例的一个特殊例 子，而且不能被初始用例代替。 一个用例也可以被定义为基用例的增量扩展 , 这叫做扩展关系。同一个基用
12、 . . 例的几个扩展用例可以在一起应用。基用例的扩展增加了原有的语义 , 此时是 基用例而不是扩展用例被作为例子使用。 包含和扩展关系可以用含有关键字 i n c l u d e和 e x t e n d的 带箭头的虚线表示。 包含关系箭头指向被包含的用例，扩展关系箭头指向被扩展 的用例。 一个用例也可以被特别列举为一个或多个子用例，这被称做用例泛化。当父 用例能够被使用时，任何子用例也可以被使用。 用例泛化与其他泛化关系的表示法相同，都用一个三角箭头从子用例指向父 用例。下图表示了销售中的用例关系。 第4节用例图 用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。用例 是系统中
13、的一个功能单元， 可以被描述为参与者与系统之间的一次交互作用。用 . . 例模型的用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例 的执行。图 3 - 2 是售票系统的用例图。参与者包括售票员、监督员和公用电话 亭。公用电话亭是另一个系统， 它接受顾客的订票请求。 在售票处的应用模型中， 顾客不是参与者， 因为顾客不直接与售票处打交道。用例包括通过公用电话亭或 售票员购票，购预约票（只能通过售票员）以及售票监督（应监督员的要求）。 购票和购预约票包括一个共同的部分即通过信用卡来付钱。（对售票系统的 完整描述还要包括其他一些用例，例如换票和验票等。 用例也可以有不同的层次。用例可以
14、用其他更简单的用例进行说明。在交互 视图中，用例做为交互图中的一次协作来实现。 . . 第三章对系统静态结构建摸 第1节 类结构图 静态视图是 U M L的基础。模型中静态视图的元素是应用中有意义的概念， 这些概念包真实世界中的概念、 抽象的概念、 实现方面的概念和计算机领域的概 念，即系统中的各种念。举个例子，一个剧院的售票系统有各种概念，如票、预 订、预约计划、座位分配规则网络订票和冗余信息等。 . . 静态视图说明了对象的结构。一个面向对象的系统使数据结构和行为特征 统一到一个立的对象结构中。 静态视图包括所有的传统数据结构思想，同时也包 括了数据操作的组织数据和操作都可量化为类。根据面
15、向对象的观点， 数据和行 为是紧密相关的。比如， Ti c k e t对象可以携带数据，如价格、演出日期、 座位号，该对象还可以有基于它的操作，例如：预这张票或以一定折扣计算它的 价格。 静态视图将行为实体描述成离散的模型元素，但是不包括它们动态行为的 细节。静态图将这些行为实体看作是将被类所指定、拥有并使用的物体。 这些实 体的动态行为由描述们内部行为细节的其他视图来描述，包括交互视图和状态机 视图。 动态视图要求静态视图述动态交互的事物如果不首先说清楚什么是交互 作用，就无法说清楚交互作用怎样进的。静态视图是建立其他视图的基础。 静态视图中的关键元素是类元及它们之间的关系。类元是描述事物的
16、建模 元素。有几类元，包括类、接口和数据类型。包括用例和信号在内的其他类元具 体化了行为方面的事物实现目的位于像子系统、构件和节点这几种类元之后。 为了利于理解和模型的可重用性，大的模型必须由较小的单元组成。包是 拥有和管理型内容的一般的组织单元。任何元素都可被包所拥有。 模型是用来描 述完整的系统视图的包并且使用时或多或少地独立于其他的模型这是掌握描 述系统的更细节的包的基础。 对象是从建模者理解和构造的系统中分离出来的离 散单元。它是类的实例即， 它是个其结构和行为都由类来描述的具有身份的个 体。对象是一个可识别的状态，该状态的行能被激发。 类元之间的关系有关联、泛化及各种不同的依赖关系，
17、包括实现和使用关 系。 . . 第2节类元 类元是模型中的离散概念，拥有身份、状态、行为和关系。有几种类元包括 类、接口和数据类型。 其他几种类元是行为概念、 环境事物、执行结构的具体化。 这些类元中包括用例、参与者、构件、节点和子系统。下表列出了几种类元和它 们的功能。元模型术语类元中包括了所有这些概念，因为类是我们所最熟悉的术 语，所以先讨论它，再根据类与其他概念的区别来定义其他概念。 类。类表示被建模的应用领域中的离散概念物理实体（如飞机）、商业事 物（如一份订单）、逻辑事物（如广播计划）、应用事物（如取消键）、计 算机领域的事物（如哈希表）或行为事物（如一项任务）。类是有着相同结构、
18、行为和关系的一组对象的描述符号。所用的属性与操作都被附在类或其他类元 上。类是面向对象系统组织结构的核心。 . . 对象是具有身份、状态和可激发行为的离散实体。对象是用来构造实际运行 系统的个体；类是用来理解和描述众多个别对象的个别概念。 类定义了一组有着状态和行为的对象。属性和关联用来描述状态。属性通常 用没有身份的纯数据值表示， 如数字和字符串。 关联则用有身份的对象之间的关 系表示。个体行为由操作来描述， 方法是操作的实现。 对象的生命期由附加给类 的状态机来描述。 类的表示法是一个矩形， 由带有类名、 属性和操作的分格框组 成。如图 4 - 1所示。 一组类可以用泛化关系和建立在其内的
19、继承机制分享公用的状态和行为描 述。泛化使更具体的类（子类）与含有几个子类公同特性的更普通的类（超类） 联系起来。一个类可以有零个或多个父类（超类）和零个或多个后代（子类）。 一个类从它的双亲和祖先那里继承状态和行为描述，并且定义它的后代所继承的 状态和行为描述。 类在它的包含者内有惟一的名字，这个包含者通常可能是一个包但有时也可 能是另一个类。 类对它的包含者来说是可见的， 可见性说明它如何被位于它的可 见者之外的类所利用。类的多重性说明了有多少个实例可以存在，通常情况下， 可以有多个（零个或多个，没有明确限制），但在执行过程中一个实例只属于 . . 一个类。 接口。接口是在没有给出对象的实现和状态的情况下对对象行为的描述。接 口包含操作但不包含属性， 并且它没有对外界可见的关联。 一个或多个类或构件 可以实现一个接口，并且每个类都
