UML图的种类.docx
《UML图的种类.docx》由会员分享，可在线阅读，更多相关《UML图的种类.docx（17页珍藏版）》请在冰豆网上搜索。
UML图的种类
第1章UML简介
在本章中，你将学习如下内容：
为什么需要UML？
UML的诞生。
如何用图表示UML模型的各个部分？
为什么使用UML提供的不同类型的图对我们来说很重要？
统一建模语言（UnifiedModelingLanguage，UML）是当今世界上面向对象系统开发领域中最激动人心的工具之一。
为什么？
UML是一种可视化的建模语言，它能让系统构造者用标准的、易于理解的方式建立起能够表达出他们想象力的系统蓝图，并且提供一种机制，以便于不同的人之间有效地共享和交流设计结果。
交流思想是极为重要的。
在UML出现以前，系统开发往往是无计划的议题。
系统分析员尽力去获取客户的需求，用某种他自己能够理解（但客户不一定总能理解）的表示法来产生需求分析文档，然后将这个分析转交给一个程序员或者一个程序员小组，并且期待着最后所开发出的系统正是客户所需要的。
一些术语
在本书中，系统（system）指的是硬件和软件的结合体，它能提供业务问题的解决方案。
系统开发（systemdevelopment）是为客户建立一个系统的过程，而客户（client）是需要解决问题的人。
系统分析员（analyst）将客户所要解决的问题编制成文档，并将该文档转交给开发人员（developer），开发人员是为了解决客户的问题而构造软件并在计算机硬件上实施该软件的程序员。
由于系统开发需要人与人之间的交流，因此在开发过程的每个阶段中都很可能潜伏着错误。
系统分析员可能没有正确理解客户的需求。
他编制的文档客户可能不能理解。
系统分析员经常编写出语句冗长、内容庞大的需求文档，项目组的其他成员很难用上这些文档，这真是添乱。
可笑的是，这些无足轻重的文档常常把重要的需求（以及需求之间的相关性）挤出人们的脑海之外。
因此，系统分析的结果对程序员来说可能很不明确，随后程序员据此构造出的程序很可能不仅难以使用而且根本不是客户所需要的最初问题的解决方案。
难道你不奇怪，为什么今天很多已经运行了很长时间的那些老系统既笨重、麻烦，而且又难以使用吗？
1.1在纷繁复杂中寻求解决问题的办法
在计算机时代的早期，程序员们在编制程序之前几乎很少对手头问题进行详细的分析。
如果他们真地对问题进行了充分分析的话，问题也就不是如此了。
通常他们一开始就自底向上地编写程序，随着时间的进展代码不断扩充。
这种大胆进行尝试的做法添加了一丝浪漫色彩，但是在今天这样一个高商业风险的社会里，这样做被证明是不适当的。
如今，一个经过深思熟虑的计划至关重要。
客户必须理解开发组做什么，如果开发组没有充分理解客户需求的话（或者如果客户在半路改变了自己的想法），客户必须能够指出需求所发生的变化。
不仅如此，系统开发还是一个典型的群组工作，因此小组的每个成员必须要知道自己的那部分作品应该放到整体作品中的哪个位置（当然还得要知道这个整体作品是什么）。
随着世界变得越来越复杂，存在于这个世界中的基于计算机的系统也增加了复杂性。
这些计算机系统通常包括多个硬件和软件单元、跨越长距离的网络设施，还要连接到信息量堆积如山的数据库上。
如果你要创建一个成功的系统，怎么来对付这些问题的复杂性呢？
最关键的一点是要用一种系统分析员、客户、程序员和其他系统开发所涉及到的人员能够理解和达成一致的方式来组织系统的设计过程。
UML就提供了这种组织方式。
不首先建立一个详细的蓝图，你不会马上开始建造一个诸如办公大楼这样的复杂建筑物。
同样，不首先编制一个详细的设计计划，那么你也不大可能马上就在这栋办公大楼中建立起一个复杂的系统。
拿给客户看的设计计划就如同建筑设计师拿给楼的买主的建筑物设计蓝图。
设计计划应该源于对客户需求的细致分析。
短的开发周期是当今系统开发的又一个显著特征。
当所要求的截止日期一个又一个地接踵而来时，可靠的系统设计是绝对必要的。
现代社会频繁发生的公司兼并使可靠的设计显得尤为必要。
当一个公司收购了另一个公司，新成立的组织可能要对正在进行中的开发项目的许多重要方面（实施工具、编程语言及其他）进行修改。
具有自我调整能力的“防弹项目蓝图”能够适应项目的大规模变更。
如果设计是稳定可靠的，即使实施过程中遇到了变化，实施过程照样能够平稳地进行。
可靠的设计需要一种能被系统分析员、开发人员和客户接受为标准的设计表示法，就像电子工程师在绘制电路图时所用的标准表示法以及在物理学中被作为标准的冯诺依曼图所用的表示法那样。
UML就是这样的表示法。
1.2UML的诞生
UML是GradyBooch、JamesRumbaugh和IvarJacobson智慧的结晶，他们被人们称为“三个好朋友”。
这几位先生在20世纪80年代和90年代的初期分别在不同的组织里工作，各自设计他们自己的面向对象分析与设计方法学。
他们的方法学和其他同行竞争者相比取得了卓越的成果。
到20世纪90年代中期，他们开始相互借鉴，然后决定相互合作共同推进这项工作。
第2章“理解面向对象”、第3章“运用面向对象思想”和第4章“关系”讨论面向对象这个主题。
面向对象的概念对于全书的学习起着非常重要的作用。
1994年，Rumbaugh加入到Rational软件公司工作，而Booch早已经在那里工作。
第二年Jacobson也加入了Rational公司。
后面的事情，正如他们所说的，是具有历史意义的。
UML草案版开始在软件工业界流传开来，并且根据大量的反馈信息做了大幅度修改。
由于许多公司感到UML能够适应它们的战略目标，因此一个UML联盟蓬勃发展起来。
联盟的成员包括DEC、Hewlett-Packard、Intellicorp、Microsoft、Oracle、TexasInstruments、Rational和其他一些公司。
1997年，应“对象管理组”（ObjectManagementGroup，OMG）向外界征求标准建模语言的建议，联盟制订了UML1.0版并提交给OMG。
后来联盟继续发展，产生了UML1.1版，提交给OMG后，于1997年被OMG采纳为标准。
1998年OMG接管了UML标准的维护工作，并且又制订了两个新的UML修订版。
UML成为软件工业界事实上的标准，并且仍在不断发展。
UML1.3版、1.4版和1.5版先后诞生，最近OMG正式批准了2.0版。
大多数的面向对象模型和UML建模的相关图书，都是基于UML的早期版本，也就是说1.X版的。
在本书中，我将向你展示UML的新旧版本之间的区别。
1.3UML的组成
UML包括了一些可以相互组合为图表的图形元素。
由于UML是一种语言，所以UML具有组合这些元素的法规。
这里先不介绍这些元素和规则，而是直接介绍UML各种图的用法，因为这些图是进行系统分析时要用到的。
这样的方法类似于学习外国语时首先是使用它而不是先学它的语法和组词造句。
当你花了一定的时间来运用外语后，就很容易理解外语的语法规则和组词规则。
UML提供这些图的目的是用多个视图来展示一个系统，这组视图被称为一个模型（model）。
一个系统的UML模型有点像一个建筑物按照比例缩小并经艺术家粉饰后的建筑模型。
在这里要注意的重要一点是一个UML模型只描述了一个系统要做什么，它并没告诉我们系统是如何被实施的。
下一小节将简单介绍UML中最常见的图和它们所表达的概念。
在第一部分的后部，你将能更仔细地审视每种图。
记住，由这些图再混合组图也是可以的，UML提供了扩展这些图的方法。
模型
在科学和工程技术领域中模型是一个很有用的概念。
在最通常的意义下，当你建立了一个模型后，你其实就在运用你已经了解的很多知识来帮助你理解暂时还不知道的很多东西。
在某些领域中，一个模型可能是一组数学方程式；而在另一些领域中，一个模型可能是计算机仿真程序。
模型可能有许多种类型。
就我们的目的而言，一个模型是一组UML图，为了理解和开发一个系统，我们可以检查、获取和修改这些图。
1.3.1类图
考虑一下你周围的世界。
你周围的事物大部分都可能具有某些属性（特性），并且它们以某种方式体现出各自的行为。
我们可以认为这种行为是一组操作。
你还会发现，事物很自然地都有其各自所属的种类（汽车、家具、洗衣机……）。
我们把这些种类称为类。
一个类（class）是一类或者一组具有类似属性和共同行为的事物。
举一个例子，属于洗衣机（washingmachine）类的事物都具有诸如品牌（brandname）、型号（modelname）、序列号（serialnumber）和容量（capacity）等属性。
这类事物的行为包括“加衣物（acceptclothes）”、“加洗涤剂（acceptdetergent）”、“开机（turnon）”和“关机（turnoff）”等操作。
图1.1是一个用UML表示法表示的洗衣机属性和行为的一个例子。
矩形方框代表类的图标，它被分成3个区域。
最上面的区域中是类名，中间区域是类的属性，最下面区域里列出的是类的操作。
类图就是由这些类框和表明类之间如何关联的连线所组成。
图1.1UML类图标
注意类名、属性名和操作名之间的间隔。
在UML中，由多个单词组成的类名，每个单词的首字母要大写，并且单词和单词之间不用空格（例如，WashingMachine）。
属性名和操作名也遵从相同的约定，但其首字母不用大写（例如，acceptClothes）。
每个操作名的后面都有一对括号，我们将在第3章中解释其原因。
在第4章中，你将会看到有许多线条连接的矩形符号组成的类图，这些线条表示类之间是如何相关联的。
为什么要如此麻烦地考虑事物的分类和它们的属性及行为呢？
为了与我们所处的这个复杂世界进行交互，大部分现代软件都模拟现实世界的某些方面。
几十年的经验告诉我们，当软件代表了现实世界中的事物的类时，采用这种模拟方式开发软件最容易。
类图就能为开发人员提供这种模仿现实世界的表达方式。
类图对系统分析也有很大帮助。
它可以让分析员使用客户所采用的术语和客户交流，这样就可以促使客户说出所要解决的问题的重要细节。
1.3.2对象图
对象（object）是一个类的实例，是具有具体属性值的一个具体事物。
例如，你的洗衣机的品牌可能是“Laundatorium”，型号为“Washmeister”，序列号为“GL57774”，容量为16磅。
图1.2中的图标说明了如何用UML来表示对象。
注意对象的图标也是一个矩形，和类的图标一样，但是对象名下面要带下划线。
在左边的这个图标中，具体实例的名字位于冒号的左边而该实例所属的类名位于冒号的右边。
实例的名字以一个小写字母开头。
也可能是一个匿名的对象，如图1.2右边的图标所示。
这仅仅意味着尽管你指明了对象所属的类，但你并没有提供一个具体的对象名。
图1.2UML对象图标，左边的图标代表一个具名的对象，右边的图标代表一个匿名的对象
1.3.3用例图
用例（usecase）是从用户的观点对系统行为的一个描述。
对于系统开发人员来说，用例是一个有价值的工具：
它是用来从用户的观察角度收集系统需求的一项屡试不爽的技术。
这对于那些试图建立一个供人使用的（而不是计算机设备使用的）系统是很重要的。
我们在第6章“介绍用例”、第7章“用例图”、第18章“收集系统需求”和第19章“开发用例”中还要详细讨论用例。
这里先举一个简单的例子。
你使用一台洗衣机，显然是为了洗衣服（washclothes）。
图1.3说明了如何用UML用例图来描述这个需求。
图1.3UML用例图
代表洗衣机用户的直立小人形被称为参与者（actor）。
椭圆形代表用例。
注意参与者（它是发起用例的实体）可以是一个人也可以是另一个系统。
还应该注意，用例位于一个代表着系统的矩形中，而参与者在矩形之外。
1.3.4状态图
在任一给定的时刻，一个对象总是处于某一特定的状态。
一个人可以是新生儿、婴儿、儿童、少年、青年或者成人。
一个电梯可以处于上升或停止状态。
一台洗衣机可以处于浸泡（soaking）、洗涤（washing）、漂洗（rinsing）、脱水（spinning）或者关机（off）状态。
转换
从一个状态到另一个状态的转换并不总是线性的。
有时候，条件指明了不同的路径。
我们将在第8章“状态图”中讨论这一点。
UML状态图如图1.4所示，该图能够描述上面所提及的状态。
该图说明洗衣机可以从一个状态转移到另一个状态。
图1.4UML状态图
在上图中，最顶端的符号代表起始状态，而最底端的符号表示终止状态。
1.3.5顺序图
类图和对象图表达的是系统的静态结构。
在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。
UML顺序图所表达的正是这种基于时间的动态交互。
仍以洗衣机为例，洗衣机的构件包括一个定时器（timer）、一个注水的进水管（waterpiper）和一个用来装衣物的洗涤缸（drum）。
当然，这些构件也是对象（以后你将会看到，一个对象之中还可以包含其他对象）。
当“洗衣服”这个用例被执行时，将会依次发生什么事情呢？
假设你已经完成了“加衣物”、“加洗涤剂”和“开机”操作，那么步骤应按照如下顺序进行：
1．浸泡开始前，先通过进水管向洗涤缸中注水。
2．洗涤缸保持5分钟静止状态。
3．在浸泡之后，停止注水。
4．洗涤开始的时候，洗涤缸往返旋转15分钟。
5．洗涤完毕后，通过排水管排掉洗涤后的水。
6．洗涤缸停止旋转。
7．漂洗开始时，重新开始注水。
8．洗涤缸继续往返旋转洗涤。
9．15分钟后停止向洗衣机中注水。
10．漂洗结束时，通过排水管排掉漂洗衣物的水。
11．洗涤缸停止旋转。
12．脱水开始时，洗涤缸方向持续旋转5分钟。
13．脱水结束，洗涤缸停止旋转。
14．洗衣过程结束。
我们把定时器、进水管和洗涤缸都假想为对象。
假设每个对象都有一个或多个操作。
对象之间通过相互传递消息来协同工作。
每一条消息，都是发送者对象对接收者对象的一个请求，要求接收者对象完成（接收者对象的）一个操作。
让我们来看看这些操作。
定时器能够：
⏹为浸泡定时。
⏹为洗涤定时。
⏹为漂洗定时。
⏹为脱水定时。
进水管能够：
⏹开始注水。
⏹停止注水。
洗涤缸能够：
⏹储存水。
⏹往返旋转。
⏹沿顺时针方向旋转。
⏹停止旋转。
⏹排水。
图1.5展示了如何用这些操作来创建一个顺序图，其中定时器、进水管、洗涤缸和排水管用匿名对象来表示，顺序图则捕获了在它们之间传递的消息。
每一个箭头，代表着从一个对象到另一个对象的消息。
在这个图中，定时器贯穿始终。
因此，第一条消息是timeSoak（），是定时器自己发送给自己的。
第二条消息sendWater（）是定时器发送给进水管的。
最后一条消息stopRotating（）是定时器发送给洗涤缸的。
注意，有一个对象能够给自己发送消息（本例中的定时器）。
还有，注意，并不是所有的箭头都具有相同的形状。
我们将在第9章“顺序图”中了解更多相关内容。
注意，如果你忘了什么是匿名类，请回过头去参阅图1.2。
图1.5UML顺序图
1.3.6活动图
正如上一小节中提到的步骤一样，用例和对象的行为中的各个活动之间通常具有时间顺序。
图1.6显示了步骤4到步骤6之间按顺序的UML活动图。
图1.6UML活动图
再论转换
在前面的“转换”中，我说过从一个状态到另一个状态的转换并不总是线性的，有时候会有不同的路径。
活动图中也是这样，我们将在第11章“活动图”中了解到这一点。
1.3.7协作图
系统的工作目标是由系统中各组成元素相互协作完成的，建模语言必须具备这种协作关系的表达方式。
前面提到的顺序图就具备这种功能，图1.7所示的UML协作图（communicationdiagram）也能够完成此项任务，不过其表达方式和顺序图略有不同。
图1.7并不是和图1.5中的顺序图功能等同的协作图，它只是捕获了定时器、进水管和排水管之间的头几条简单的消息。
它也并不是按照垂直方向表示时间顺序，而是通过消息标记前面的数字来表示时间顺序。
顺序图和协作图都能够表示对象之间的交互。
因此，UML中它们被合称为交互图（interactiondiagram）。
名称变化
协作图（communicationdiagram）是UML2.0版本中的新名称。
在以前的1.X版本中，它叫做collaborationdiagram。
如果你在2.0版本确定下来后，看到这两个术语交叉使用，请不必大惊小怪，因为它们是一回事。
图1.7UML协作图
1.3.8构件图
构件图和下一个要介绍的部署图将不再使用洗衣机这个例子来做说明，因为构件图和部署图和整个计算机系统密切相关。
现代软件开发是基于构件的，这种开发方式对群组开发尤为重要。
这里暂不对此做详细介绍，仅用图1.8来说明如何用UML1.X版本表示软件构件。
图1.8UML1.X版本中的软件构件图标
这是UML2.0有所改进的地方。
鉴于很多建模工作者反映这个图标很糟糕，UML2.0使用一个改进的标记。
图1.9给出了表示一个软件构件的新的方式。
图1.9UML2.0中的软件构件图标记
尖括号做什么用？
图1.9中，单词component外围的尖括号是做什么用的？
这个符号在UML中有着特殊的作用。
我们将在稍后的部分“关键字和构造型”中介绍。
1.3.9部署图
UML部署图显示了基于计算机系统的物理体系结构。
它可以描述计算机，展示它们之间的连接，以及驻留在每台机器中的软件。
每台计算机用一个立方体来表示，立方体之间的连线表示这些计算机之间的通信关系。
图1.10是部署图的一个例子。
图1.10UML部署图
1.4其他特征
前面曾提到过UML提供了一些用来扩展模型图的特征。
本节描述这些特征中比较突出的一些。
包1
1.4.1注释
有时图中的某一部分不会给出明确的解释。
此时UML注释（note）很有用场。
可以把注释看成是图形化的黄页。
注释的图标是一个带折角的矩形。
矩形框中是解释性文字。
图1.11是注释的一个例子。
注释和被注释的图元素之间用一条虚线连接。
图1.11任何图中都可以附加注释来做解释说明
1.4.2关键字和构造型
UML提供了很多有用的项，但绝不是一个完全彻底的模型元素集。
有时你所要创建的模型需要包含一些新的概念和符号。
构造型（stereotype）使你能够在现有的UML元素的基础上创建新的元素。
这有点像你从货架中买了一套衣服然后再把这套衣服裁剪成你所需要的尺寸（而不是买一堆布料从头开始制作）。
可以把构造型和这种裁制类比。
构造型用两对尖括号括起来的一个名称来表示，这个括号叫做双尖括号（guillemets）。
这个被括起来的名称叫做关键字（keyword）。
有时候，UML会为你创建新的模型。
这时候，UML并不是为某事物创建一个全新的符号，而是把一个关键字添加到已有的元素中。
这个关键字表明了该元素的用法与其原来的意图多少有些不同。
接口这个概念（你将在第5章“聚集、组成、接口和实现”中学习）是使用构造型的一个好例子。
接口（interface）是一个没有属性而只有操作的类。
它是可以在整个模型中反复使用的一组行为（具体原因将在第5章说明）。
无需发明一个新的UML元素来表示接口，UML可以在类图标中类名的上面加一个<>关键字来表示接口，如图1.12所示。
图1.12构造型是在现有的元素上添加一个带书名号的关键字，这关键字表明了该元素的用法与其原来的意图多少有些不同
构造型的概念在使用UML建模工具的时候特别有用。
建模工具的一个重要特点是具备“字典”的功能，能够跟踪你在模型中创建的所有的元素，包括类、用例、构件等等。
字典只能够对已有的元素和基于这些元素的构造型有效。
因此，构造型允许你创建一些新的东西并把它们存储到字典中。
这一点非常重要，因为字典能够帮助你管理自己的模型，并使你得以复用你所创建的元素。
在14章中，我们将深入UML内部并探讨诸如构造型等概念的基础。
现在，你只需要把构造型形象化地记为向UML图标中添加一个关键字。
你还需要记住，当你使用UML的时候（尤其是当你使用UML建模工具的时候），你将会发现UML中有很多内建的构造型和预定义的关键字（如<>、<>等）。
退化？
我第一次提到双尖括号是在前面的“构件图”部分。
我提到，图1.8中的UML1.x软件构件符号已经被图1.9中的UML2.0符号所取代。
我针对构造型所介绍的一切内容都表明，当你缺乏某种符号的时候，你可以用构造型来创建它。
而在UML1.x到UML2.0中，构件图的情况正好相反，带有一个关键字的类符号替代了原有的符号。
1.5UML2.0中的新图
除了对UML1.x的图加以替换（如软件构件图标），UML2.0还加入了一些新鲜想法。
1.5.1组成结构图
当你对一个类建模的时候，你会发现展示其内部结构是很有用的。
当一个类由多个类构建而成的时候，你往往会有这种感觉。
例如，我们设想一个人是由思想（Mind）和身体（Body）组成的。
在第5章中，你将看到传统的方法如何对这个表述建模。
模型由线条和符号组成，它们把Person类连接到Mind类和Body类。
UML2.0的组成结构图（compositestructurediagram）为你提供了一种全新的方法。
你可以把每一个构件类放入到一个整体中。
这种方法传达的思想就是，你从类结构的内部来审视这个类。
图1.13向你说明这个意思。
图1.13对一个类的内部结构建模的组成结构图
UML1.x版允许在类图中使用这种符号；UML2.0则把这种方法明确地定义为自己的一种图。
有关线条的哲学
随着我们更加深入了解面向对象的知识，你会发现连接两个类（如Mind和Body）的线条通常都有一个名字。
在图1.13中，我们该如何标注连接Mind类和Body类的线条呢？
多年来，哲学家对这个问题一直是百思不得其解。
他们一直不断地争论这种关系的命名，它是否存在？
Mind这个组成部分是否存在？
等等等等…….
1.5.2交互纵览图
再次考虑活动图（图1.6），它向我们展示了一系列的步骤，也就是“活动”。
假设这些活动中的每一个都包含了对象之间的一个消息序列。
如果你用顺序图或协作图（或者是二者的结合体）来替换其中的某些活动，你将会得到UML2.0中的新图——交互纵览图（interactionoverviewdiagram）。
下面举个例子。
假设你在一个图书馆中：
1.你从图书馆的数据库中查找到一本书。
2.你把这本书拿到服务台去办理借阅。
3.在你离开图书馆之前，出口处的门卫验证你的借阅登记。
图1.14给出了反映这3个步骤的一个简单的活动图。
图1.14在图书馆的3个活动
现在，我们来分析一下每个活动。
在第1个活动中，你查询图书馆的数据库以找到图书，数据库做出反应，告诉你到哪里去找图书。
在第2个活动中，你请求管理员为你办理借阅手续，手续办妥后，管理员告诉你可以把图书带走了。
在第3个活动中，只有门卫查验了你的借阅手续之后，你才能离开图书馆。
图1.15扩展图1.14中的活动图后得到的交互纵览图
1.5.3时序图
回过头来考虑洗衣机的例子。
我用这个典型的家用电器讨论了类图、状态图、顺序图和协作图。
在顺序图部分，我提到了每一个状态的持续时间：
5分钟浸泡、15分钟洗涤、15分钟漂洗和15分钟脱水。
如果你仔细察看图1.5中的顺序图，你会发现其中并没有标明这些持续时间。
UML2.0的时序图（timingdiagram）完成了这个任务。
时序图就是设计用来表示对象处于某一个状态中的持续时间的。
图1.16给出了这个新图的一种形式。
图1.16UML时序图
1.5.4有创新也有
升级会员 