第3章 UML建模语言

3.1.4 UML概述
统一建模语言（UML）的应用领域十 分广泛，可以用于商业建模（business modeling）、软件开发过程中的各个阶段 建模等。它是一种通用的建模语言，可以 对系统进行全方位的建模，包含系统的静 态结构模型、动态行为模型等多种结构模 型。UML语言本身比较通俗易懂，具有可 扩展性和通用性。
视图
UML中的各种组件和概念之间没有明显的划分界限，但 为方便起见，我们用视图来划分这些概念和组件。视图只是 表达系统某一方面特征的UML建模组件的子集。 UML中的视图主要包括用例视图（Use-case view）、 逻辑视图（Logical view）、组件视图(Component view)、 部署视图（Deployment view）。
对象的建立和删除
: Manger
CustomerMange
Customer
1: NewCustomer 2: customer(data)
3: Delete
4: delete(data)
图3.4 客户管理顺序图
异步消息
: Actor OrderClient Server CreditServer
参与者 参与者是与系统、子系统或类发生交互作用的 外部用户、进程或其他系统的理想化概念。作为外 部用户与系统发生交互作用，这是参与者的特征。 在系统的实际运作中，一个实际用户可能对应系统 的多个参与者。不同的用户也可以只对应于一个参 与者，从而代表同一参与者的不同实例。 每个参与者可以参与一个或多个用例。它通过 交换信息与用例发生交互作用，因此也与用例所在 的系统或类发生了交互作用。而参与者的内部实现 与用例是不相关的,参与者可以被一组定义它的状态 的属性充分描述。
图
UML中的图由图片（graph）组成，图片是模型元素的符 号的有机组合体。图表示了系统的一个特殊部分或者某个方 面。在具体的系统里，应该有多个各种类型的图。图是一个 具体视图的组成部分，在某个视图中画图时，就把一个图分 配给这个视图了。根据图的内容，它也可以是多个视图的一 分子。UML中包含了用例图、类图、对象图、状态图、顺序 图、协作图、活动图、组件图、部署图九种。按照机制分 类，UML的建模机制分为静态建模机制和动态建模机制。图 中的用例图、类图、对象图、组件图和部署图属于静态建模 机制。
1997年1月，UML版本1.0被提交给OMG组织， 作为软件建模语言标准化的候选。在其后的半年 多时间内，一些重要的软件开发商和系统集成商 都成为UML的伙伴，如Microsoft、IBM、HP、 Rational Software等。他们积极地使用UML并提 出反馈意见，最后于1997年9月再次提交给OMG 组织，于1997年11月7日正式被OMG采纳作为业 界标准。UML的形成过程如图3－1所示。现在， OMG已经将UML作为公共可得到的规格说明 （Publicly Available Specification）提交给国际 标准化组织（ISO）进行国际标准化。
用例 用例是外部可见的一个系统功能单元，这些功 能由系统单元所提供，并通过一系列系统单元与一 个或多个参与者之间交换的消息所表达。用例的用 途是在不揭示系统内部构造的情况下定义连贯的行 为。用例的定义包含用例所必需的所有行为—执行 用例功能的主线次序、标准行为的不同变形、一般 行为下的所有异常情况及其预期反应。从用户角度 来看，上述情况很可能是异常情况；从系统角度来 看，它们是必须被描述和处理的附加情况。
3.1.2 UML的发展
从二十世纪八十年代初期开始，众多的方法 学家都在尝试用不同的方法进行面向对象的分析 与设计。在众多的建模语言中,语言的创造者努力 推崇自己的产品,并在实践中不断完善。但是,OO 方法的用户并不了解不同建模语言的优缺点及相 互之间的差异,因而很难根据应用特点选择合适的 建模语言,于是爆发了一场"方法大战"。90年代中, 一批新方法出现了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。
测试用例 用例可以用于测试系统的正确性和有效性。正 确性表明系统的实现符合规格说明；有效性保证所 开发的系统时用户真正需要的系统。Hale Waihona Puke Baidu效性检查一 般在系统开发之前进行。当用例构造完成后，开发 人员将所有用例交给用户进行讨论，用户检查这些 用例是否满足他们的要求。在有效性检查过程中， 往往会有双方理解的问题和用户新的想法。开发方 和用户最终达成共识。同时，用例也是系统测试的 基本依据之一，测试人员据此来测试系统是否达到 预先设计的功能。随着测试技术的发展，用例已成 为自动测试的主要模型。
3.1.1面向对象的开发方法
利用传统程序设计语言的软件开发方法出现于20世 纪70年代，在80年代被广泛采用，其中最重要的是结构 化分析和结构化设计方法和它的变体，如实时结构化设 计方法等。这些方法最初由Constantine、De Marco、 Mellor、Ward、Yourdon和其他一些人发明和推广，在 一些大型系统中，负责项目的官员强调开发过程的有组 织性和开发设计文档的完备性。尽管结果并不像预料的 那么好，但这些方法中包含了一些好的思想，有时在一 些大系统中是很有效的。商业应用软件更不愿采用大型 的CASE系统和开发方法。大部分商业企业都独立地开 发本企业内部使用的软件，客户和缔约人之间没有对立 关系，而这种关系正是大型工程的特征。
第三章 UML建模语言
3.1 UML简介
面向对象的软件工程同传统的面向过程 的软件工程相比，在需求的获取、系统分析、 设计和实现方面都有着很大的区别。然而， 过去数十种面向对象的建模语言都是相互独 立的,使得设计跟用户需求之间存在一些潜在 的不必要的差异,混淆用户的真实目的。这就 急需一个统一的、易理解的工具来对整个软 件开发过程进行描述。UML就是这样的产物。
UML由视图（views）、图（Diagrams）、模型元素 （Model elements）和通用机制（General mechanism） 等几个部分组成。其中，视图用来表示被建模系统的各个 方面，每个方面均以不同目的而建立，系统的多个视图反 映整个系统。描述整个系统的多个视图之间是一致的，他 们很好地从多个角度描述了系统。视图由多个图构成，它 并不是一个图片（graph），而是某一个抽象层次上的系 统表示。当需要建立一个完整的系统模型图时，只需要定 义一定数量的视图，每个视图表示系统的某个方面就行。 另外，视图还把建模语言和系统开发时选择的方法或者过 程连接起来。图（diagrams）由图片构成，用来描述一个 视图的内容。
通用机制 在建模过程中，某些信息可能无法通过基本模 型元素来表示。UML就利用通用机制为图添加附加 信息，通常用的通用机制有修饰、笔记、规格说 明。为了建模者能很好地区分开类型和实例，通常 利用修饰为模型元素附加一定语义。修饰的位置一 般紧靠这模型元素。UML还提供笔记能力，笔记可 以描述模型元素无法表示的信息，通常在我们认为 需要用较多的文字来说明某个特征时使用，在UML 中，字符串类型是不进行解释的。笔记可以放在图 的任何位置。
UML描述了一个系统的静态结构和动 态行为。UML将系统描述为一些离散的相 互作用的对象并最终为外部用户提供一定 功能的模型结构。静态结构定义了系统中 重要对象的属性和操作以及这些对象之间 的相互关系。动态行为定义了对象的时间 特性和对象为完成目标而相互进行通信的 机制。从不同但相互联系的角度对系统建 立的模型可用于不同的目的。
图3.1 UML的形成过程
3.1.3 什么是UML
统一建模语言（UML）是一个通用的可视化建模语 言，用于对软件进行描述、可视化处理、构造和建立软件 系统制品的文档。它记录了对必须构造的系统的决定和理 解，可用于对系统的理解、设计、浏览、配置、维护和信 息控制。UML 适用于各种软件开发方法、软件生命周期 的各个阶段、各种应用领域以及各种开发工具，是一种总 结了以往建模技术的经验并吸收当今优秀成果的标准建模 方法。UML包括概念的语义，表示法和说明，提供了静态、 动态、系统环境及组织结构的模型。它可被交互的可视化 建模工具所支持，这些工具提供了代码生成器和报表生成 器。UML标准并没有定义一种标准的开发过程，但它适用 于迭代式的开发过程。它是为支持大部分现存的面向对象 开发过程而设计的。
1: InsertCard 2: InputDate 3: ChooseSeat 4: Select 5: Submit 6: IsValid 8: OrderOK 9: PrintTicket 7: authorize
图3.5 异步订票系统的顺序图
3.2.3 协作图
在顺序图一节中，我们提到了消息序列可以由协作图 来表示。协作图主要描述协作对象之间的交互和链接，一 条链接就是一个关联的实例化。顺序图和协作图虽然都是 用来描述交互的，但顺序图强调的是时间，而协作图强调 的是空间。链接显示真正的对象以及对象间的联系方式， 可以只显示对象内部的结构。协作图也可以表示操作的执 行，用例的执行或者系统中的一次简单交互情形。 协作图显示对象、对象间的链接以及链接对象之间的 消息发送过程。在协作图中，对象用类一样的符号来表示， 但对象名下面有下划线；链接用线条来表示，在一条链接 上，可以给消息加一个消息标签来定义消息的序列号。协 作图从初始化整个交互或协作的消息开始。
模型元素
模型元素是在图中可以使用的所有概念。它用 语义、元素的正式定义或者确定的语句所代表的准 确含义来定义。模型元素在图中用相应的符号表 示。利用视图元素可以把图形象并且直观地表示出 来。一个符号可以在多个不同类型地图中出现，但 都得遵循相应的规则。UML中最常见的模型元素包 括对象、类、包、结点、状态、组件等。当然，模 型元素与模型元素之间的关系也是模型元素，比如 关联、依赖、聚合、泛化等。
3.2.2 顺序图
对象间的相互作用体现了对象的行为。这种 相互作用可以描述成两种互补的方式，一种以独 立的对象为中心进行考察，另一种以互相作用的 一组对象为中心进行考察。为了描述一组对象的 整体行为，UML采用对象间协作关系模型—交互 视图来表达。对象间的协作描述的内容是：在一 定的环境中一组对象以及用以实现某些行为的这 些对象间的相互作用。协作包括结构和行为两个 方面。结构方面包含一个角色集合和他们之间的 关系，这些关系定义了行为方面的内容；行为方 面是一个消息集合，这些消息在某些对象之间进 行传递。
UML中的用例表示 中的用例表示
<<extend>>
ATM
<<include>> <<include>> <<include>>
取取取取
查查
转转
取取
RMB提取
美美提取
图3.3 用例表示图
用例和参与者之间有着密切关系，在UML中称这种关系为关联关系。 关联关系表明哪种参与者能够与该用例通信。当然，用例之间也存在包 含、扩展、泛化关系。 包含：一个用例可以简单地包含其他用例具有的行为，并把它所包 含的用例行为做为自身行为的一部分，这被称作包含关系。在这种 情况下，新用例不是初始用例的一个特殊例子，而且不能被初始用 例代替。包含可以用含有关键字《i n c l u d e》的带箭头的虚线表 示，箭头指向被包含的用例。 扩展：一个用例也可以被定义为基用例的增量扩展,这叫做扩展关系。 同一个基用例的几个扩展用例可以在一起应用。基用例的扩展增加 了原有的语义, 此时是基用例而不是扩展用例被作为例子使用。扩 展关系可以用含有关键字《e x t e n d》的带箭头的虚线表示。关 系箭头指向被扩展的用例。 泛化：一个用例也可以被特别列举为一个或多个子用例，这被称为 用例泛化。当父用例能够被使用时，任何子用例也可以被使用。用 例泛化与其他泛化关系的表示法相同，都用一个三角箭头从子用例 指向父用例。
3.2 测试使用的模型
3.2.1 用例图
订订订订订查 销销销
顾顾
订订订订 货货 发货
订订订订
监监监销
图3.2 网上购物系统用例图
系统 系统是用例模型的一个组成部分，它代表的是 某个活动或者某个实体，而不是软件系统。系统的 边界用来说明所构建用例模型的应用范围。例如， 网络购物系统提供查看订单状态、订单处理、发 货、订单追踪功能，这些功能仅限于该网络购物系 统，一旦离开这个系统，就不考虑这些功能。在建 模过程中，由于某些功能既可以由系统自动实现， 又可以由别的系统提供或者手工完成，因此，要准 确确定系统的边界是比较困难的。用例图中的系统 用一个长方框来表示，系统名一般写在方框上。系 统内部（方框内）是系统中的用例。