UML基础、案例与应用：第3版.doc

《UML基础、案例与应用：第3版.doc》由会员分享，可在线阅读，更多相关《UML基础、案例与应用：第3版.doc（210页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、如有侵权，请联系网站删除，仅供学习与交流UML基础、案例与应用：第3版【精品文档】第 210 页第一部分基础知识第三部分高级应用第23章嵌入式系统建模23.1回到餐馆23.2发明之母23.3研制GetAGrip23.4什么是嵌入式系统23.5嵌入式系统中的基本概念23.5.1时间23.5.2线程23.5.3中断23.5.4操作系统23.6对GetAGrip系统建模23.6.1类23.6.2用例23.6.3交互23.6.4整体状态变化23.6.5整体部署23.7锻炼肌肉23.8小结23.9常见问题解答23.10小测验和习题23.10.1小测验23.10.2习题第24章描绘UML的未来24.1在业

2、务领域的扩展24.2从业务领域的扩展得到的经验24.3图形用户界面24.3.1连接到用例24.3.2GUI建模24.4专家系统24.4.1专家系统的构件24.4.2举例24.4.3知识库建模24.5Web应用24.6就写到这里吧24.7小结24.8常见问题解答24.9小测验和习题24.9.1小测验24.9.2习题第四部分附录附录A小测验答案附录BUML建模工具附录CUML图总结前言当我们能够想象出如何运用技术来把事情做得更好时，一个复杂的系统就随之诞生了。开发人员所开发的系统正是要将构想变为现实，因此他们必须要能够充分地理解这种想象力并将其牢记在心中.一个成功的系统开发项目的成功之处在于它能够

3、在想象者和实现这些想象的系统开发人员之间建立起沟通的桥梁。统一建模语言(UnifiedcModelingcLanguage，UML)就是一种建立桥梁的工具。它能帮你捕捉住对系统所发挥的想象力，并使你能够用这些想象出来的东西来和项目的风险承担人进行交流。UML借助于一套符号和图形来帮助我们完成这些工作。每种图形在开发过程中都发挥其各自不同的作用.本书的目标是让你通过高效的学习建立起UML的牢固基础。在本书每一章的内容中都为读者提供一些实例，以强化对所学知识的理解，并且在每章后面还留了一些习题让你能够将新知识学以致用。第3版的新内容在写本书的这一版的过程中，我仔细检查了本书的前两版，对其进行了精简

4、，并增加和修改了一些必要内容。一些新增的内容是针对UML最新修改的2.40版本的，另外一些则是为了适应时间的流逝和技术的进步.在前两个版本的第14章中都讲解了UML的一些基础的理论性概念。在第3版中，我们在很大程度上扩展了这一章，以包含UML2.50中的新概念.我细化了模型和图背后的一些思想，并针对它们增加了小测验和习题。作为改写的一部分，这一版中，我在每一个交互图前面都给出一个类图，以展示该类的操作。目的就是为了澄清在交互图中出现的消息，使它们显得更加直观。如果你了解一些UML的知识，你就会明白我的良苦用心。如果你不明白，那么在读完本书的时候，你就知道了。本书的目标读者本书针对那些需要快速掌

5、握UML基础的系统分析员、项目经理、系统设计师和开发者。如果你需要尽快地使用UML，或者需要了解足够多的UML知识以便理解其他人用UML所完成的工作，那么，这本书很适合你.本书的组织结构本书有3个部分。第一部分为“基础知识”部分，在这一部分中首先是对UML进行了综述，然后转向面向对象这个主题，面向对象的概念是建立对象图和类图时要用到的最基本的概念。本部分还讨论了用例(use case)用于展示从用户的角度所观察到的系统功能的UML组件以及如何实现用例图。我还花了额外的时间来讨论和面向对象及用例有关的基本概念，因为在使用UML的大部分时间里所要用到的东西都建立在这两个基本概念之上。在第一部分剩余

6、的内容中还将介绍其余的UML图.第二部分为“学习案例”。通过一个虚构的学习案例介绍了一种简化的系统开发方法。因此，第二部分说明了如何将UML运用到项目开发背景中去，在这部分中你将学习如何运用UML的各个组件协同工作来为系统建立模型.第三部分为“高级应用”部分，介绍了UML在设计模式和嵌入式系统中的应用，还探讨了UML在其他几个领域的应用。有不少供应商都提供用于创建UML图并将这些图组织成为模型的工具软件包。在附录B中，我们使用Microsoft Visio专业版完整地绘制3个UML图，向你展示这样一个工具软件包是如何使用的。另外，我们还简单介绍了其他3种建模工具.在学习这3个部分的过程中，你只

7、需要用铅笔和纸来画图，同时，需要对如何把模型当作系统设计的基础这个问题保持充分的好奇心.本书约定在阅读本书的过程中，你将会发现： 每章开头都有“在本章中，你将学到以下内容”的提示. 新术语用黑体字标出，例如：沿着每个对象向下延伸的虚线，叫做生命线(lifeline). 特殊的提示版块贯穿全书，它们提供额外的有用信息.讨论对象概念的章节第2章“理解面向对象”。第3章“运用面向对象思想”和第4章“关系”讨论面向对象这个主题。面向对象的概念对于全书的学习起着非常重要的作用.让我们开始建模吧!第一部分基础知识第一章UML简介在本章中，你将学习如下内容u 为什么需要UML？u UML的诞生。u 如何用图

8、表示UML模型的各个部分？u 为什么使用UML提供的不同类型的图对我们来说很重要？统一建模语言（Unified Modeling Language,UML）是当今世界上面向对象系统开发领域最激动人心的工具之一。为什么？UML是一种可视化的建模语言，它能让系统构造者用标准的、易于理解的方式建立起能够表达出他们想象力的系统蓝图，并且提供一种机制，以便于不同的人之间有效地共享和交流设计结果。交流思想是极为重要的。在UML出现以前，系统开发往往是无计划的议题。系统分析员尽力去获取客户的需求，用某种他自己能够理解（但客户不一定总能理解）的表示法来产生需求分析文档，然后将这个分析文档转交给一个程序员或者一

9、个程序员小组，并且期待着最后所开发出的系统正是客户所需要的。一些术语在本书中，系统（system）指的是硬件和软件的结合体，它能提供业务问题的解决方案。系统开发（system development）是为客户建立一个系统的过程，而客户（client）是需要解决问题的人。系统分析员（analyst）将客户所要解决的问题编制成文档，并将该文档转交给开发人员（developer），开发人员是为了解决客户的问题而构造软件并在计算机硬件上实施该软件的程序员。由于系统开发需要人与人之间的交流，因此在开发过程的每个阶段中都很可能潜伏着错误。系统分析员可能没有正确地理解客户的需求。他编制的文档客户可能不能理解

10、。系统分析员经常编写出语句冗长、内容庞大的需求文档，项目组的其他成员很难用上这些文档，这真是添乱。可笑的是，这些无足轻重的文档常常把重要的需求（以及需求之间的相关性）挤出人们的脑海之外。因此，系统分析的结果对程序员来说可能很不明确，随后程序员据此构造出的程序很可能不仅难以使用而且根本不是客户所需要的最初问题的解决方案。难道你不奇怪，为什么今天很多已经运行了很长时间的那些老系统既笨重、麻烦，而且难以使用吗？1.1在纷繁复杂中寻求解决问题的办法在计算机出现的早期，程序员们在编制程序之前几乎很少对手头问题进行详细的分析。如果他们真的对问题进行了充分分析的话，问题也就不是如此了。通常他们一开始就自底向

11、上地编写程序，随着时间的推移代码不断扩充。这种大胆进行尝试的做法添加了一丝浪漫色彩，但是在今天这样一个高商业风险的社会里，这样做被证明是不适的。如今，一个经过深思熟虑的计划至关重要。客户必须理解开发组在做什么，如果开发组没有充分理解客户需求的话（或者如果客户在中途改变了自己的想法），客户必须能够指出需求所发生的变化。不仅如此，系统开发还是一个典型的群组工作，因此小组的每个成员必须要知道自己的那部分作品应该放到整体作品的哪个位置（当然还需要知道这个整体作品是什么）。随着世界变得越来越复杂，存在于这个世界中的基于计算机的系统也增加了复杂性。这些计算机系统通常包括多个硬件和软件单元、跨越距离的网络设

12、施，还要连接到信息量堆积如山的数据库上。如果你要创建一个成功的系统，怎么来对付这些问题的复杂性呢？最关键的一点是要用一种系统分析员、客户、程序员和其他系统开发所涉及到的人员能够理解和达成一致的方式来组织系统的设计过程。UML就提供了这种组织方式。不首先建立一个详细的蓝图，你不会马上开始建造一个诸如办公大楼这样的复杂建筑物。同样，不首先编制一个详细的设计计划，那么你也不太可能马上就在这栋办公大楼中建立起一个复杂的系统。拿给客户看的设计计划就如同建筑设计师拿给楼的买主看的建筑物设计蓝图。设计计划应该源于对客户需求的细致分析。短的开发周期是当今系统开发的又一个显著特征。当所要求的截止日期一个又一个地

13、接踵而来时，可靠的系统设计是绝对必要的。现代社会频繁发生的公司兼并使可靠的设计显得尤为必要。当一个公司收购了另一个公司，新成立的组织可能要对正在进行中的开发项目的许多重要方面（实施工具、编程语言及其他）进行修改。具有自我调整能力的“防弹项目蓝图”能够适应项目的大规模变更。如果设计是稳定可靠的，即使实施过程中遇到了变化，实施过程照样能够平稳地进行。可靠的设计需要一种能被系统分析员、开发人员和客户接受为标准的设计表示法，就像电子工程师在电路图中所用的标准表示法以及在物理学中被作为标准的费因曼图所用的表示法那样。UML就是这样的表示法。1.2UML的诞生UML是Grady Booch、James R

14、umbaugh和Ivar Jacobson智慧的结晶，他们被人们称为“三个好朋友”。这几位先生在世纪年代和年代的初期分别在不同的组织里工作，各自设计他们自己的面向对象分析与设计方法学。他们的方法学和其他同行竞争者相比取得了卓越的成果。到世纪年代中期，他们开始相互借鉴，然后决定相互合作共同推进这项工作。第章“理解面向对象”、第3章“运用面向对象思想”和第章“关系”讨论面向对象这个主题。面向对象的概念对于全书的学习起着非常重要的作用。1994年，Rumbaugh加入Rational软件公司，而Booch早已经在那里工作。第二年Jacobson也加入了Rational公司。后面的事情，正如他们所说的

15、，是具有历史意义的。UML草案开始在软件工业界流传开来，并且根据大量的反馈信息做了大幅修改。由于许多公司感到UML能够适应它们的战略目标，因此一个UML联盟蓬勃发展起来。联盟的成员包括DEC、Hevlett-Packard、Intellicorp、Microsoft、Oracle、Texas Instruments、Rational和其他一些公司。1997年，应“对象管理组”（Object Management Group,OMG）向外界征求建模语言的建议，联盟制订了UML1.0版并提交给OMG。后来联盟继续发展，产生了UML1.1版，提交给OMG后，于1997年被OMG采纳为标准。1998年

16、OMG接管了UML标准的维护工作，并且制订了两个新的UML修订版。UML成为软件工业界事实上的标准，并且仍在不断发展。UML1.3版、1.4版和1.5版先后诞生，最近OMG正式批准了2.0版。大多数的面向对象模型和UML建模的相关图书，都是基于UML的早期版本，也就是说1.x版的。在本书中，我将向你展示UML的新旧版本之间的区别。1.3UML的组成UML包括了一些可以相互组合为图表的图形元素。由于UML是一种语言，所以UML具有组合这些元素的规则。这里先不介绍这些元素和规则，而是直接介绍UML各种图的用法，因为这些图是进行系统分析时要用到的。这样的方法类似于学习外语时首先是使用它而不是先学它的

17、语法和组词造句。当你花了一定时间来运用外语后，就很容易理解外语的语法规则和组词规则。UML提供这些图的目的是用多个视图来展示一个系统，这组视图被称为一个模型（model）。一个系统的UML模型有点像一个建筑物按照比例缩小并经艺术家粉饰后的建筑模型。在这里要注意的重要一点是一个UML模型只描述了一个系统要做什么，它并没告诉我们系统是如何被实施的。下一小节将简单介绍UML中最常见的图和它们所表达的概念。在第一部分的后部，你将能更仔细地审视每种图。记住，由这些图再混合组图也是可以的，UML提供了扩展这些图的方法。模型在科学和工程技术领域中模型是一个很有用的概念。在最通常的意义下，当建立了一个模型后，

18、其实就在运用已经了解的很多知识来帮助你理解暂时还不知道的很多东西。在某些领域中，一个模型可能是一组数学方程式；而在另一些领域中，一个模型可能是计算机仿真程序。模型可能有许多种类型。就我们的目的而言，一个模型是一组UML图，为了理解和开发一个系统，我们可以检查、获取和修改这些图。1.3.1类图考虑一下你周围的世界。你周围的事物大部分都可能具有某些属性（特性），并且它们以某种方式体现出各自的行为。我们可以认为这种行为是一组操作。你还会发现，事物很自然地都有其各自所属的种类（汽车、家具、洗衣机。）。我们把这些种类称为类。一个类（class）是一类或者一组具有类似属性和共同行为的事物。举一个例子，属于

19、洗衣机（washing machine）类的事物都具有诸如品牌（brand name）、型号（model name）、序列号（serial number）和容量（capacity）等属性。这类事物的行为包括“加衣物（accept clothes）”、“加洗涤剂（accept detergent）”、“开机（turn on）”和“关机（turn off）”等操作。图1.1是一个用UML表示法表示的洗衣机属性和行为的一个例子。矩形方框代表类的图标，它被分成个区域。最上面的区域中是类名，中间区域是类的属性，最下面区域里列出的是类的操作。类图就是由这些类框和表明类之间如何关联的连线所组成。注意类名、属

20、性名和操作名之间的间隔。在UML中，由多个单词组成的类名，每个单词的首字母要大写，并且单词和单词之间不用空格（例如，WashingMachine）。属性名和操作名也遵从相同的约定，但其首字母不用大写（例如，acceptClothes()）。每个操作名的后面都有一对括号，我们将在第章中解释其原因。在第章中，你将会看到由许多线条连接的矩形符号组成的类图，这些线条表示类之间是如何相关联的。为什么要如此麻烦地考虑事物的分类和它们的属性及行为呢？为了与我们所处的这个复杂世界进行交互，大部分现代软件都模拟现实世界的某些方面。几十年的经验告诉我们，当软件代表了现实世界中的事物的类时，采用这种模拟方式开发软件

21、最容易。类图就能为开发人员提供这种模仿现实世界的表达方式。类图对系统分析也有很大帮助。它可以让分析员使用客户所采用的术语和客户交流，这样就可以促使客户说出所要解决的问题的重要细节。1.3.2对象图对象（object）是一个类的实例，是具有具体属性值的一个具体事物。例如，你的洗衣机的品牌可能是“Laundatorium”，型号为“Washmeister”，序列号为“GL57774”，容量为16磅。图1.2中的图标说明了如何用UML来表示对象。注意对象的图标也是一个矩形，和类的图标一样，但是对象名下面要带下划线。在左边的这个图标中，具体实例的名字位于冒号的左边而该实例所属的类名位于冒号的右边。实例

22、的名字以一个小写字母开头。也可能是一个匿名的对象，如图1.2右边的图标所示。这仅仅意味着尽管你指明了对象所属的类，但你并没有提供一个具体的对象名。1.3.3用例图用例（use case）是从用户的观点对系统行为的一个描述。对于系统开发人员来说，用例是一个有价值的工具：它是用来从用户的观察角度收集系统需求的一项屡试不爽的技术。这对于那些试图建立一个供人使用的（而不是计算机设备使用的）系统是很重要的。我们在第章“介绍用例”、第章“用例图”、第章“收集系统需求”和第章“开发用例”中还要详细讨论用例。这里先举一个简单的例子。你使用一台洗衣机，显然是为了洗衣服（wash clothes）。图1.3说明了

23、如何用UML用例图来描述这个需求。代表洗衣机用户的直立小人形被称为参与者（actor）。椭圆形代表用例。注意参与者（它是发起用例的实体）可以是一个人也可以是另一个系统。还应该注意，用例位于一个代表着系统的矩形中，而参与者在矩形之外。拼读注意为了能够清楚地表示这个概念，在读“use case”中的use的时侯，轻发一个s的音（就像truce的最后一个音），而不要发snooze的最后一个音。1.3.4状态图在任一给定的时刻，一个对象总是处于某一特定的状态。一个人可以是新生儿、婴儿、儿童、少年、青年或者成人。一个电梯可以处于上升或停止状态。一台洗衣机可以处于浸泡（soaking）、洗涤（washin

24、g）、漂洗（rinsing）、脱水（spinning）或者关机（off）状态。UML状态图如图1.4所示，该图能够描述上面所提及的状态。该图说明洗衣机可以从一个状态转移到另一个状态。转换从一个状态到另一个状态的转换并不总是线性的。有时侯，条件指明了不同的路径。我们将在第章“状态图”中讨论这一点。在上图中，最顶端的符号代表起始状态，而最底端的符号表示终止状态。1.3.5顺序图类图和对象图表达的是系统的静态结构。在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。UML顺序图所表达的正是这种基于时间的动态交互。仍以洗衣机为例，洗衣机的构件包括一个定时器（timer）、一个注水的进

25、水管（water piper）和一个用来装衣物的洗涤缸（drum）。当然，这些构件也是对象（以后你将会看到，一个对象之中还可以包含其他对象）。当“洗衣服”这个用例被执行时，将会依次发生什么事情呢？假设你已经完成了“加衣物”、“加洗涤剂”和“开机”操作，那么步骤应按照如下顺序进行：1. 浸泡开始前，先通过进水管向洗涤缸中注水。2. 洗涤缸保持5分钟静止状态。3. 在浸泡之后，停止注水。4. 洗涤开始的时侯，洗涤缸往返旋转15分钟。5. 洗涤完毕后，通过排水管排掉洗涤后的水。6. 洗涤缸停止旋转。7. 漂洗开始时，重新开始注水。8. 洗涤缸继续往返旋转洗涤。9. 15分钟后停止向洗衣机中注水。10

26、. 漂洗结束时，通过排水管排掉漂洗衣物的水。11. 洗涤缸停止旋转。12. 脱水开始时，洗涤顺时针方向持续旋转5分钟。13. 脱水结束，洗涤缸停止旋转。14. 洗衣过程结束。我们把定时器、进水管和洗涤缸都假想为对象。假设每个对象都有一个或多个操作。对象之间通过相互传递消息来协同工作。每一条消息，都是发送者对象对接收者对象的一个请求，要求接收者对象完成（接收者对象的）一个操作。让我们来看看这些操作。定时器能够： 为浸泡定时。 为洗涤定时。 为漂洗定时。 为脱水定时。进水管能够： 开始注水。 停止注水。洗涤缸能够： 储存水。 往返旋转。 沿顺时针方向旋转。 停止旋转。 排水。图1.5展示了如何用这

27、些操作来创建一个顺序图，其中定时器、进水管、洗涤缸和排水管用匿名对象表示，顺序图则捕获了在它们之间传递的消息。每一个箭头，代表着从一个对象到另一个对象的消息。在这个图中，定时器贯穿始终。因此，第一条消息是timeSoak()，是定时器自己发送自己的。第二条消息sendWater()是定时器发送给进水管的。最后一条消息stopRotating()是定时器发送给洗涤缸的。注意，有一个对象能够给自己发送消息（本例中的定时器）。还有，注意，并不是所有的箭头都具有相同的形状。我们将在第9章“顺序图”中了解更多相关的内容。注意，如果你忘了什么是匿名对象，请回过头去参阅图1.2所示。1.3.6活动图正如上一

28、小节中提到的步骤一样，用例和对象的行为中的各个活动之间通常具有时间顺序。图1.6显示了步骤4到步骤6之间按顺序的UML活动图。再论转换在前面的“转换”中，我说过从一个状态到另一个状态的转换并不总是线性的，有时侯会有不同的路径。活动图中也是这样，我们将在第11章“活动图”中了解到这一点。1.3.7协作图系统的工作目标是由系统中各组成元素相互协作完成的，建模语言必须具备这种协作关系的表达方式。前面提到的顺序图就具备这种功能，图1.7所示的UML协作图（communicationdiagram）也能够完成此任务，不过其表达方式和顺序图略有不同。图1.7并不是和图1.5中的顺序图功能等同的协作图，它只

29、是捕获了定时器、进水管和排水管之间的头几条简单的消息。它并不是按垂直方向表示时间顺序，而是通过消息标记前面的数字来表示时间顺序的。顺序图和协作图都能够表示对象之间的交互。因此，UML中它们被合称为交互图（interaction diagram）。名称变化协作图（communication diagram）是UML2.0版本中的新名称。在以前的1.x版本中，它叫做collaboration diagram。由于2.0版本的出现，你会看到这两个术语混用，请不必大惊小怪，因为它们是一回事。1.3.8构件图构件图和下一个要介绍的部署图将不再使用洗衣机这个例子来做说明，因为构件图和部署图和整个计算机系统

30、密切相关。现代软件开发是基于构件的，这种开发方式对群组开发尤为重要。这里暂不对此做详细介绍，仅用图1.8来说明如何用UML1.x版本表示软件构件。这是UML 2.0有所改进的地方。鉴于很多建模工作者反映这个图标很糟糕，UML 2.0使用一个改进的标记。图1.9给出了表示一个软件构件的新的方式。尖括号做什么用？图1.9中，单词component外围的尖括号是做什么用的？这个符号在UML中有着特殊的作用。我们将在稍后的部分“关键字和构造型”中介绍。1.3.9部署图UML部署图显示了基于计算机系统的物理体系结构。它可以描述计算机，展示它们之间的连接，以及驻留在每台机器中的软件。每台计算机用一个立方体

31、来表示，立方体之间的连线表示这些计算机之间的通信关系。图1.10是部署图的一个例子。1.4其他特征前面曾提到过UML提供了一些用来扩展模型图的特征。本节描述这些特征中比较突出的一些。1.4.1注释有时图中的某一部分不会给出明确的解释。此时UML注释（note）很有用场。可以把注释看成是图形化的黄页。注释的图标是一个带折角的矩形。矩形框中是解释性文字。图1.11是注释的一个例子。注释和被注释的图元素之间用一条虚线连接。1.4.2关键字和构造型UML提供了很多有用的项，但绝不是一个完全彻底的模型元素集。有时你所要创建的模型需要包含一些新的概念和符号。构造型（stereotype）使你能够在现有的U

32、ML元素的基础上创建新的元素。这有点像你从货架中买了一套衣服然后再把这套衣服裁剪成你所需要的尺寸（而不是买一堆布料从头开始制作）。可以把构造型和这种裁制类比。构造型用两对尖括号括起来的一个名称来表示，这个括号叫做双尖括号（guillemets）。这个被括起来的名称叫做关键字（keyword）。有时侯，UML会为你创建新的模型即绘图元素。这时侯，UML并不是为某事物创建一个全新的符号，而是把一个关键字添加到已有的元素中。这个关键字表明了该元素的用法与其原来的意图多少有些不同。接口这个概念（你将在第章“聚焦、组成、接口和实现”中学习）是使用构造型的一个好例子。接口（interface）是一个没有属

33、性而只有操作的类。它是可以在整个模型中反复使用的一组行为（具体原因将在第章说明）。无须发明一个新的UML元素来表示接口，UML可以在类图标中类名的上面加一个关键字来表示接口，如图1.12所示。构造型的概念在使用UML建模工具的时侯特别有用。建模工具的一个重要特点是具备“字典”的功能，能够跟踪你在模型中创建的所有的元素，包括类、用例、构件等等。字典只能够对已有的元素和基于这些元素的构造型有效。因此，构造型允许你创建一些新的东西并把它们存储到字典中。这一点非常重要，因为字典能够帮助你管理自己的模型，并使你得以复用你所创建的元素。在第14章中,我们将深入UML内部并探讨诸如构造型等概念的基础。现在，

34、你只需要把构造型形象化地记为向UML图标中添加一个关键字。你还需要记住，当你使用UML的时侯（尤其是当你使用UML建模工具的时侯），你将会发现UML中有很多内建的构造型和预定义的关键字（如、等）。退化？我第一次提到双尖括号是在前面的“构件图”部分。我提到，图1.8中的UML 1.x软件构件符号已经被图1.9中的UML 2.0符号所取代。我针对构造型所介绍的一切内容都表明，当你缺乏某种符号的时候，你可以用构造型来创建它。而在UML 1.x到UML 2.0中，构件图的情况正好相反，带有一个关键字的类图标替代了原有的符号。1.5UML 2.0中的新图除了对UML 1.x的图加以替换（如软件构件图标）

35、，UML 2.0还加入了一些新鲜想法。1.5.1组成结构图当你对一个类建模的时侯，你会发现展示其内部结构是很有用的。当一个类由多个类构建而成的时侯，你往往会有这种感觉。例如，我们设想一个人是由思想（Mind）和身体（Body）组成的。在第5章中，你将看到传统的方法如何对这个表述建模。模型由线条和符号组成，它们把Person类连接到Mind类和Body类UML 2.0的组成结构图（composite structure diagram）为你提供了一种全新的方法。你可以把每一个构件类放入到一个整体中。这种方法传达的思想就是，你从类结构的内部来审视这个类。图1.13向你说明了这个意思。UML 1.x

36、版允许在类图中使用这种符号；UML 2.0则把这种方法明确地定义为自己的一种图。图1.13 对一个类的内部结构建模的组成结构图有关线条的哲学随着我们更加深入了解面向对象的知识，你会发现连接两个类（如Mind和Body）的线条通常都有一个名字。在图1.13中，我们该如何标注连接Mind类和Body类的线条呢？多年来，哲学家对这个问题一直是百思不得其解。他们一直不断地争论这种关系的命名，它是否存在？Mind这个组成部分是否存在？等等等等。1.5.2交互纵览图再次考虑活动图（图1.6），它向我们展示了一系列的步骤，也就是“活动”。假设这些活动中的每一个都包含了对象之间的一个消息序列。如果你用顺序图或

37、协作图（或者是二者的结合体）来替换其中的某些活动，你将会得到UML 2.0中的新图交互纵览图（interaction overview diagram）。下面举个例子。假设在一个图书馆中：1. 你从图书馆的数据库中查找到一本书。2. 你把这本书拿到服务台去办理借阅登记。3. 在你离开图书馆之前，出口处的门卫验证你的借阅登记。图1.14给出了反映这3个步骤的一个简单的活动图。图1.14 在图书馆的3个活动现在，我们来分析一下每个活动。在第1个活动中，你查询图书馆的数据库以找到图书，数据库做出反应，告诉你到哪里去找图书。在第2个活动中，你请求管理员为你办理借阅手续，手续办妥后，管理员告诉你可以把图

38、书带走了。在第3个活动中，只有门卫查验了你的借阅手续之后，你才能离开图书馆。图1.15展示了如何在顺序图中按顺序组织上述步骤。图1.15 扩展图1.14中的活动图后得到的交互纵览图1.5.3计时图回过头来考虑洗衣机的例子。我用这个典型的家用电器讨论了类图、状态图、顺序图和协作图。在顺序图部分，我提到了每一个状态的持续时间：5分钟浸泡、15分钟洗涤、15分钟漂洗和5分钟脱水。如果你仔细察看图1.5中的顺序图，你会发现其中并没有标明这些持续时间。UML 2.0的计时图（timing diagram）完成了这个任务。计时图就是设计用来表示对象处于某一个状态中的持续时间的。图1.16给出了这个新图的一

39、种形式。图1.16 UML计时图1.5.4有创新也有保留的包图UML 1.x版本具备组织一个图的元素的能力，这就是打个包（package）。包的图标就像是一个带有标签的文件夹，如图1.17所示。使用包的思想就是把共同工作的元素放到这样的一个带标签的文件夹图标中。例如，如果多个类或者构件组成了一个特殊的子系统，它们应该放入到一个包中。图1.17 UML包图标通过规范包图，UML 2.0促进了包的应用。包不再被认为只是一种组织图元素的方法，它有了自己专用的图。1.6为什么需要这么多种图正如你在前面所看到，各种UML图能让你从多个视角考察一个系统。要注意的重要一点是并不是每个UML模型都必须包含所有

40、的图。事实上大多数UML模型只包含上面列出的所有图的子集。对系统建立模型为什么需要这么多种图？最典型的情况是，一个系统有多个不同类型的风险承担人（stakeholder）那些在不同方面与这个系统有利益关系的人。让我们回顾洗衣机的例子。如果你正在设计一台洗衣机的马达，那么以你的视角来观察系统就得到一个系统的视图。如果你正在编写操作指令的话，你可能又会得到另一幅视图。要是你正在设计洗衣机整体外观的话，那么你观察这个系统的方式与你作为一个洗衣机用户的观察方式完全不同。认真细致的系统设计要考虑到所有这些视角，每一种UML图都为你提供一种组成特殊视图的方式。采用多视角的目标是为了能够和每一类风险承担人良

41、好地沟通。1.7这不仅仅是一系列图有人可能会争辩说UML建模无足轻重。毕竟，程序才是项目最重要的部分，难道不是吗？开发者作实际的工作，而建模者只是绘图，不是吗？为了理解精确的可视化建模的重要性，让我们来看看一个广为人知的、长期处于构建中的项目。这个项目开发地位于马萨诸塞州的波士顿市，其正式名称叫作“市区（中心）干线（隧道）”，现在被人戏称为“大挖掘”，其目的是缓解波士顿市的交通堵塞现象。一系列通过城市中心的隧道和桥梁将替代年久失修、容量有限的高架高速公路。除了解决交通问题，“大挖掘”还将带来巨大的经济效益和环保效益。这些益处最好是巨大的，因为项目的成本已经超过预算10亿美元。根据Boston

42、Globe（波士顿环球报）的报导，成本巨大的一个原因是指导开挖和建筑的图纸不完整并且不精确。例如，FleetCenter（富利中心，波士顿市的运动和娱乐中心）就在一张图纸中漏掉了。这个扎眼的遗漏误导了承包商，使他们以为在城市的某个特定区域，应该有一条连贯的线路用来设置公共设施。另一张图纸则多出了一个本不存在的检修孔（用来检查电线线路的）。还有另外一张隧道的图纸则在隧道段之间留下了一个4英尺的空隙，直到该隧道段定位以后，工人才发现有这么一个空隙。结果是耗费了大量的成本去完成始料不及的工作，以更正错误，同时一而再再而三地延误工期。这种情况听起来是不是有些耳熟。建模、学习和知识我认为，学习的进展过程

43、包括3个阶段：1. 你不知道你所缺乏的知识。也许，这一条的更好的说法是，你不熟悉某一个特定的领域。2. 你知道你所缺乏的知识。换句话说，你对于这个领域的方方面面有了一些了解，并开始查找你的知识缺陷。3. 填补你的知识缺陷。UML（以及普通的建模）是快速把你带入第2阶段的美妙途径，帮助你认识到自己所缺乏的知识，并开始寻找相关的信息。1.8小结系统开发是一项人力活动，如果没有易于理解的表示法系统，开发过程就会冒很大的错误风险。UML就是一套表示法系统，它已经成为系统开发领域中的标准。UML是由Grady Booch、James Rumbaugh和Ivar Jacobson发明的。UML由一组图组成

44、，它使得系统分析员可以利用这一标准来建立能够为客户、程序员以及任何参与开发过程的人员理解的多视角的系统蓝图。因为不同的风险承担人通常使用不同类型的图相互交流，因此UML包含所有这些种类的图是很有必要的。UML模型中说明一个系统应该做什么（what to do），并没有告诉我们系统应该怎么做（how to do）。1.9常见问题解答问：我注意到有人将统一建模语言表示为“UML”，还有的人将其表示为“the UML”。哪一种是正确的？答：语言的创作者更喜欢用“the UML”。问：你提到了面向对象的思想在本书中占据主要的地位。为了理解并应用这些概念，我必须是一个Java或C+的开发者吗？答：当然不

45、是。面向对象的思想并不只是对程序员有用。对于系统所处的专业领域的知识，系统分析员希望能够了解并对其建模，因此，面向对象的思想对系统分析员极为有用。问：你刚才提到，UML对系统分析员来说是一个非常有用的工具。然而，部署图似乎在系统开发过程的分析阶段不那么有用。它是不是更适合在开发过程的后期使用？答：的确不应该太早就开始考虑系统部署问题（以及其他一些传统上被认为应该在开发过程后期要考虑的问题，如系统安全）。确实，系统分析员的工作主要是和客户和用户交流，但在开发过程的早期，系统分析员也很可能要考虑构成系统硬件的计算机和组成。有时侯是客户要求系统分析员这么做的。有时客户想让开发组向他们推荐。当然部署对

46、系统体系结构设计师来说是非常有用的。问：前面你提到过，用UML的各种图混合组图也是可以的。那么，UML对模型图中哪个元素和哪个元素的结合做了限制吗？答：没有。UML对此没有限制。然而，一般的情况是某种图只是包含这种图的图形元素。当然你可以在部署图中加进一个类的图标，但这么做可能没有太大用处。问：图1.3是“洗衣服”的用例图，它所描述的一切都围绕着用户使用洗衣机洗衣服。我们真的需要用一组符号来描述这些么？我们难道不能只用一个简单的句子来描述？答：单单就你所提到的这个问题讲，你的说法是对的：你可以只是采用一个句子来描述。然而，在一个典型的开发项目中，用例就像是Star Trek影剧集（星际迷航）第

47、42场中的Tribble（一种繁殖力极强的星际小生物）。你开始入门了，但还需要了解更多。1.10小测验和习题1.10.1小测验1.10.2习题第2章理解面向对象在本章中，你将学习如下内容：u 如何理解面向对象思维方式。u 对象如何通信。u 对象如何与其他对象关联。u 对象如何组合。面向对象技术已经席卷了整个软件界，事实也确实如此。作为一种程序设计方法，它具有很多优点。基于构件的软件开发方法就是面向对象技术孕育出来的。采用这种方法建立一个系统时，首先建立一组类，然后通过增加已有构件的功能或者添加新的构件来逐步扩充系统，最后在建立一个新系统时，你还可以重用已经创建好的类。这样做可以大大削减系统开发时间。使用UML可以建立起易于使用和易于理解的对象模型。程序员能够创建出这些模型所对应的软件。因此，UML对基于类开发的全过程都有益处。面向对象是一种思维方法它是依赖于几个基本原则的思维方法。在这一章中，你将学习到这些基本原则。你将搞清楚对象是什么，在分析和设计中如何利用对象。从下一章开始介绍如何根据这些基本原则运用UML。2.1无处不在的对象对象，不