UML基础学习知识,案例解析与应用-第3版.doc

-第一部分基础知识第1章UML简介1.1在纷繁复杂中寻求解决问题的办法1.2UML的诞生1.3UML的组成1.3.1类图1.3.2对象图1.3.3用例图1.3.4状态图1.3.5顺序图1.3.6活动图1.3.7协作图1.3.8构件图1.3.9部署图1.4其他特征1.4.1注释1.4.2关键字和构造型1.5UML 2.0中的新图1.5.1组成结构图1.5.2交互纵览图1.5.3计时图1.5.4有创新也有保留的包图1.6为什么需要这么多种图1.7这不仅仅是一系列图1.8小结1.9常见问题解答1.10小测验和习题1.10.1小测验1.10.2习题第2章理解面向对象2.1无处不在的对象2.2一些面向对象的概念2.2.1抽象2.2.2继承2.2.3多态性2.2.4封装2.2.5消息传递2.2.6关联2.2.7聚集2.3意义2.4小结2.5常见问题解答2.6小测验和习题第3章运用面向对象3.1类的可视化表示3.2属性3.3操作3.4属性、操作和可视化表达3.5职责和约束3.6附加注释3.7类应该做什么和如何识别它们3.8小结3.9常见问题解答3.10小测验和习题3.10.1小测验3.10.2习题第4章关系4.1关联4.1.1关联上的约束4.1.2关联类4.1.3链4.2多重性4.3限定关联4.4自身关联4.5继承和泛化4.5.1找出继承关系4.5.2抽象类4.6依赖4.7类图和对象图4.8小结4.9常见问题解答4.10小测验和习题4.10.1小测验4.10.2习题第5章聚集、组成、接口和实现5.1聚集5.2组成5.3组成结构图5.4接口和实现5.5接口和端口5.5.1可见性5.5.2作用域5.6小结5.7常见问题解答5.8小测验和习题5.8.1小测验5.8.2习题第6章介绍用例6.1什么是用例6.2用例的重要性6.3举例：饮料销售机6.3.1用例“买饮料”6.3.2其他用例6.4包含用例6.5扩展用例6.6开始用例分析6.7小结6.8常见问题解答6.9小测验和习题6.9.1小测验6.9.2习题第7章用例图7.1用例模型的表示法7.1.1回顾饮料销售机7.1.2跟踪场景中的步骤7.2用例之间关系的可视化表示7.2.1包含7.2.2扩展7.2.3泛化7.2.4分组7.3用例图在分析过程中的作用7.4运用用例模型：举例7.4.1理解领域7.4.2理解用户7.4.3理解用例7.4.4进一步深入7.5“清查存货”7.5.1结构元素7.5.2关系7.5.3分组7.5.4注释7.5.5扩展7.5.6其他7.6UML“大图”7.7小结7.8常见问题解答7.9小测验和习题7.9.1小测验7.9.2习题第8章状态图8.1什么是状态图8.1.1基本符号集8.1.2在状态图标中增加细节8.1.3增加转移的细节：事件和动作8.1.4增加转移的细节：保护条件8.2子状态8.2.1顺序子状态8.2.2并发子状态8.3历史状态8.4UML2.0中的新变化8.5为什么状态图很重要8.6UML“大图”8.7小结8.8常见问题解答8.9小测验和习题8.9.1小测验8.9.2习题第9章顺序图9.1什么是顺序图9.1.1对象9.1.2消息9.1.3时间9.2汽车和车钥匙9.2.1类图9.2.2顺序图9.3饮料销售机9.4顺序图：一般顺序图9.5在消息序列中创建对象实例9.6帧化顺序图：UML2.0中的顺序图9.6.1交互事件9.6.2交互片段的组合9.7UML“大图”9.8小结9.9常见问题解答9.10小测验和习题9.10.1小测验9.10.2习题第10章协作图10.1什么是协作图10.2汽车和车钥匙10.3饮料销售机10.4创建对象10.5编号的一点注意事项10.6其他概念10.6.1发送给多对象的消息10.6.2返回结果10.6.3主动对象10.6.4同步10.7UML“大图”10.8小结10.9常见问题解答10.10小测验和习题10.10.1小测验10.10.2习题第11章活动图11.1基础：什么是活动图11.1.1判定11.1.2并发路径11.1.3信号11.2活动图的应用11.3泳道11.4混合图11.5UML2.0中的新概念11.5.1一个活动的对象11.5.2处理异常11.5.3活动的析构11.5.4标记时间并结束流程11.5.5特殊影响11.6对一个交互的纵览11.7UML“大图”11.8小结11.9常见问题解答11.10小测验和习题11.10.1小测验11.10.2习题第12章构件图12.1什么是构件12.2构件和接口12.2.1回顾接口12.2.2替换和复用12.3什么是构件图12.3.1在UML1.x和UML2.0中表示一个构件12.3.2接口表示法12.3.3黑盒和白盒12.4应用构件图12.5UML“大图”中的构件图12.6小结12.7常见问题解答12.8小测验和习题12.8.1小测验12.8.2习题第13章部署图13.1什么是部署图13.2应用部署图13.2.1家用计算机系统13.2.2令牌环网13.2.3ARCnet13.2.4细缆以太网13.2.5Ricochet无线网13.3UML“大图”中的部署图13.4小结13.5常见问题解答13.6小测验和习题13.6.1小测验13.6.2习题第14章理解包和UML语言基础14.1包图14.1.1包的作用14.1.2包之间的关系14.1.3合并包14.2层级14.2.1一个类比14.2.2继续14.3大胆深入14.4用包表示UML的底层结构14.4.1Core包14.4.2Profiles包14.5回到UML14.5.1又见4层结构14.5.2用包表示UML的上层结构14.6UML的扩展14.6.1构造型14.6.2图形构造型14.6.3约束14.6.4标记值14.7小结14.8常见问题解答14.9小测验和习题14.9.1小测验14.9.2练习第15章在开发过程中运用UML15.1开发过程方法学：传统的和现代的15.1.1传统的开发过程方法学15.1.2新的开发过程方法学15.2开发过程中必须做什么15.3GRAPPLE15.4RAD3：GRAPPLE的结构15.4.1需求收集15.4.2分析15.4.3设计15.4.4开发15.4.5部署15.5GRAPPLE总结15.6小结15.7常见问题解答15.8小测验和习题第二部分学习案例第16章学习案例介绍16.1从业务入手16.2用GRAPPLE开发过程解决问题16.3发现业务过程16.3.1招待一位顾客16.3.2准备饭菜16.3.3清理餐桌16.4吸取的经验教训16.5小结16.6常见问题解答16.7小测验和习题16.7.1小测验16.7.2习题第17章领域分析17.1分析业务过程会谈17.2开发初步类图17.3对类分组17.4形成关联17.4.1Customer参与的关联17.4.2Server参与的关联17.4.3Chef参与的关联17.4.4Busser参与的关联17.4.5Manager参与的关联17.4.6其他问题17.5形成聚集和组成17.6填充类的信息17.6.1Customer类17.6.2Employee类17.6.3Check类17.7有关模型的一些问题17.7.1模型词典17.7.2模型图的组织17.8吸取的经验教训17.9小结17.10常见问题解答17.11小测验和习题17.11.1小测验17.11.2习题第18章收集系统需求18.1开发系统的映像18.2收集系统需求18.3需求联合应用开发会议18.4结果18.5下一步该做什么18.6小结18.7常见问题解答18.8小测验和习题18.8.1小测验18.8.2习题第19章开发用例19.1分析和描述用例19.2用例分析19.3Server包19.3.1用例“Take an Order”19.3.2用例“Transmit the Order to the Kitchen”19.3.3用例“Change an Order”19.3.4用例“Track Order Status”19.3.5用例“Notify Chef about Party Status”19.3.6用例“Total Up a Check”19.3.7用例“Print a Check”19.3.8用例“Summon an Assistant”19.3.9其余的用例19.4系统中的构件19.5小结19.6常见问题解答19.7小测验和习题19.7.1小测验19.7.2习题第20章交互20.1系统中的工作部件20.1.1Server包20.1.2Chef包20.1.3Busser包20.1.4Assistant Server包20.1.5Assistant Chef包20.1.6Bartender Chef包20.1.7Coat-Check Clerk包20.2系统中的交互20.2.1用例“Take an Order”20.2.2用例“Change an Order”20.2.3用例“Track Order Status”20.3结论20.4小结20.5常见问题解答20.6小测验和习题20.6.1小测验20.6.2习题第21章设计外观、感觉和部署21.1GUI设计的一般原则21.2用于GUI设计的JAD Session21.3从用例到用户界面21.4用于GUI设计的UML图21.5描绘出系统的部署21.5.1网络21.5.2节点和系统部署图21.6下一步21.7听听项目的发起人怎么说21.7.1扩展销售区的地理范围21.7.2扩展餐馆的地理范围21.8小结21.9常见问题解答21.10小测验和习题21.10.1小测验21.10.2习题第22章理解设计模式22.1参数化22.2设计模式22.3职责链模式22.3.1职责链模式：餐馆领域22.3.2职责链模式：Web浏览器事件模型22.4我们自己的设计模式22.5使用设计模式的好处22.6小结22.7常见问题解答22.8小测验和习题22.8.1小测验22.8.2习题第三部分高级应用第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在业务领域的扩展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图总结前言当我们能够想象出如何运用技术来把事情做得更好时，一个复杂的系统就随之诞生了。开发人员所开发的系统正是要将构想变为现实，因此他们必须要能够充分地理解这种想象力并将其牢记在心中.一个成功的系统开发项目的成功之处在于它能够在想象者和实现这些想象的系统开发人员之间建立起沟通的桥梁。统一建模语言(UnifiedcModelingcLanguage，UML)就是一种建立桥梁的工具。它能帮你捕捉住对系统所发挥的想象力，并使你能够用这些想象出来的东西来和项目的风险承担人进行交流。UML借助于一套符号和图形来帮助我们完成这些工作。每种图形在开发过程中都发挥其各自不同的作用.本书的目标是让你通过高效的学习建立起UML的牢固基础。在本书每一章的内容中都为读者提供一些实例，以强化对所学知识的理解，并且在每章后面还留了一些习题让你能够将新知识学以致用。第3版的新内容在写本书的这一版的过程中，我仔细检查了本书的前两版，对其进行了精简，并增加和修改了一些必要内容。一些新增的内容是针对UML最新修改的2.40版本的，另外一些则是为了适应时间的流逝和技术的进步.在前两个版本的第14章中都讲解了UML的一些基础的理论性概念。在第3版中，我们在很大程度上扩展了这一章，以包含UML2.50中的新概念.我细化了模型和图背后的一些思想，并针对它们增加了小测验和习题。作为改写的一部分，这一版中，我在每一个交互图前面都给出一个类图，以展示该类的操作。目的就是为了澄清在交互图中出现的消息，使它们显得更加直观。如果你了解一些UML的知识，你就会明白我的良苦用心。如果你不明白，那么在读完本书的时候，你就知道了。本书的目标读者本书针对那些需要快速掌握UML基础的系统分析员、项目经理、系统设计师和开发者。如果你需要尽快地使用UML，或者需要了解足够多的UML知识以便理解其他人用UML所完成的工作，那么，这本书很适合你.本书的组织结构本书有3个部分。第一部分为“基础知识”部分，在这一部分中首先是对UML进行了综述，然后转向面向对象这个主题，面向对象的概念是建立对象图和类图时要用到的最基本的概念。本部分还讨论了用例(use case)用于展示从用户的角度所观察到的系统功能的UML组件以及如何实现用例图。我还花了额外的时间来讨论和面向对象及用例有关的基本概念，因为在使用UML的大部分时间里所要用到的东西都建立在这两个基本概念之上。在第一部分剩余的内容中还将介绍其余的UML图.第二部分为“学习案例”。通过一个虚构的学习案例介绍了一种简化的系统开发方法。因此，第二部分说明了如何将UML运用到项目开发背景中去，在这部分中你将学习如何运用UML的各个组件协同工作来为系统建立模型.第三部分为“高级应用”部分，介绍了UML在设计模式和嵌入式系统中的应用，还探讨了UML在其他几个领域的应用。有不少供应商都提供用于创建UML图并将这些图组织成为模型的工具软件包。在附录B中，我们使用Microsoft Visio专业版完整地绘制3个UML图，向你展示这样一个工具软件包是如何使用的。另外，我们还简单介绍了其他3种建模工具.在学习这3个部分的过程中，你只需要用铅笔和纸来画图，同时，需要对如何把模型当作系统设计的基础这个问题保持充分的好奇心.本书约定在阅读本书的过程中，你将会发现： 每章开头都有“在本章中，你将学到以下内容”的提示. 新术语用黑体字标出，例如：沿着每个对象向下延伸的虚线，叫做生命线(lifeline). 特殊的提示版块贯穿全书，它们提供额外的有用信息.讨论对象概念的章节第2章“理解面向对象”。第3章“运用面向对象思想”和第4章“关系”讨论面向对象这个主题。面向对象的概念对于全书的学习起着非常重要的作用.让我们开始建模吧!第一部分基础知识第一章UML简介在本章中，你将学习如下内容u 为什么需要UML？u UML的诞生。u 如何用图表示UML模型的各个部分？u 为什么使用UML提供的不同类型的图对我们来说很重要？统一建模语言（Unified Modeling Language,UML）是当今世界上面向对象系统开发领域最激动人心的工具之一。为什么？UML是一种可视化的建模语言，它能让系统构造者用标准的、易于理解的方式建立起能够表达出他们想象力的系统蓝图，并且提供一种机制，以便于不同的人之间有效地共享和交流设计结果。交流思想是极为重要的。在UML出现以前，系统开发往往是无计划的议题。系统分析员尽力去获取客户的需求，用某种他自己能够理解（但客户不一定总能理解）的表示法来产生需求分析文档，然后将这个分析文档转交给一个程序员或者一个程序员小组，并且期待着最后所开发出的系统正是客户所需要的。一些术语在本书中，系统（system）指的是硬件和软件的结合体，它能提供业务问题的解决方案。系统开发（system development）是为客户建立一个系统的过程，而客户（client）是需要解决问题的人。系统分析员（analyst）将客户所要解决的问题编制成文档，并将该文档转交给开发人员（developer），开发人员是为了解决客户的问题而构造软件并在计算机硬件上实施该软件的程序员。由于系统开发需要人与人之间的交流，因此在开发过程的每个阶段中都很可能潜伏着错误。系统分析员可能没有正确地理解客户的需求。他编制的文档客户可能不能理解。系统分析员经常编写出语句冗长、内容庞大的需求文档，项目组的其他成员很难用上这些文档，这真是添乱。可笑的是，这些无足轻重的文档常常把重要的需求（以及需求之间的相关性）挤出人们的脑海之外。因此，系统分析的结果对程序员来说可能很不明确，随后程序员据此构造出的程序很可能不仅难以使用而且根本不是客户所需要的最初问题的解决方案。难道你不奇怪，为什么今天很多已经运行了很长时间的那些老系统既笨重、麻烦，而且难以使用吗？1.1在纷繁复杂中寻求解决问题的办法在计算机出现的早期，程序员们在编制程序之前几乎很少对手头问题进行详细的分析。如果他们真的对问题进行了充分分析的话，问题也就不是如此了。通常他们一开始就自底向上地编写程序，随着时间的推移代码不断扩充。这种大胆进行尝试的做法添加了一丝浪漫色彩，但是在今天这样一个高商业风险的社会里，这样做被证明是不适的。如今，一个经过深思熟虑的计划至关重要。客户必须理解开发组在做什么，如果开发组没有充分理解客户需求的话（或者如果客户在中途改变了自己的想法），客户必须能够指出需求所发生的变化。不仅如此，系统开发还是一个典型的群组工作，因此小组的每个成员必须要知道自己的那部分作品应该放到整体作品的哪个位置（当然还需要知道这个整体作品是什么）。随着世界变得越来越复杂，存在于这个世界中的基于计算机的系统也增加了复杂性。这些计算机系统通常包括多个硬件和软件单元、跨越距离的网络设施，还要连接到信息量堆积如山的数据库上。如果你要创建一个成功的系统，怎么来对付这些问题的复杂性呢？最关键的一点是要用一种系统分析员、客户、程序员和其他系统开发所涉及到的人员能够理解和达成一致的方式来组织系统的设计过程。UML就提供了这种组织方式。不首先建立一个详细的蓝图，你不会马上开始建造一个诸如办公大楼这样的复杂建筑物。同样，不首先编制一个详细的设计计划，那么你也不太可能马上就在这栋办公大楼中建立起一个复杂的系统。拿给客户看的设计计划就如同建筑设计师拿给楼的买主看的建筑物设计蓝图。设计计划应该源于对客户需求的细致分析。短的开发周期是当今系统开发的又一个显著特征。当所要求的截止日期一个又一个地接踵而来时，可靠的系统设计是绝对必要的。现代社会频繁发生的公司兼并使可靠的设计显得尤为必要。当一个公司收购了另一个公司，新成立的组织可能要对正在进行中的开发项目的许多重要方面（实施工具、编程语言及其他）进行修改。具有自我调整能力的“防弹项目蓝图”能够适应项目的大规模变更。如果设计是稳定可靠的，即使实施过程中遇到了变化，实施过程照样能够平稳地进行。可靠的设计需要一种能被系统分析员、开发人员和客户接受为标准的设计表示法，就像电子工程师在电路图中所用的标准表示法以及在物理学中被作为标准的费因曼图所用的表示法那样。UML就是这样的表示法。1.2UML的诞生UML是Grady Booch、James Rumbaugh和Ivar Jacobson智慧的结晶，他们被人们称为“三个好朋友”。这几位先生在世纪年代和年代的初期分别在不同的组织里工作，各自设计他们自己的面向对象分析与设计方法学。他们的方法学和其他同行竞争者相比取得了卓越的成果。到世纪年代中期，他们开始相互借鉴，然后决定相互合作共同推进这项工作。第章“理解面向对象”、第3章“运用面向对象思想”和第章“关系”讨论面向对象这个主题。面向对象的概念对于全书的学习起着非常重要的作用。1994年，Rumbaugh加入Rational软件公司，而Booch早已经在那里工作。第二年Jacobson也加入了Rational公司。后面的事情，正如他们所说的，是具有历史意义的。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年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）是一类或者一组具有类似属性和共同行为的事物。举一个例子，属于洗衣机（washing machine）类的事物都具有诸如品牌（brand name）、型号（model name）、序列号（serial number）和容量（capacity）等属性。这类事物的行为包括“加衣物（accept clothes）”、“加洗涤剂（accept detergent）”、“开机（turn on）”和“关机（turn off）”等操作。图1.1是一个用UML表示法表示的洗衣机属性和行为的一个例子。矩形方框代表类的图标，它被分成个区域。最上面的区域中是类名，中间区域是类的属性，最下面区域里列出的是类的操作。类图就是由这些类框和表明类之间如何关联的连线所组成。注意类名、属性名和操作名之间的间隔。在UML中，由多个单词组成的类名，每个单词的首字母要大写，并且单词和单词之间不用空格（例如，WashingMachine）。属性名和操作名也遵从相同的约定，但其首字母不用大写（例如，acceptClothes()）。每个操作名的后面都有一对括号，我们将在第章中解释其原因。在第章中，你将会看到由许多线条连接的矩形符号组成的类图，这些线条表示类之间是如何相关联的。为什么要如此麻烦地考虑事物的分类和它们的属性及行为呢？为了与我们所处的这个复杂世界进行交互，大部分现代软件都模拟现实世界的某些方面。几十年的经验告诉我们，当软件代表了现实世界中的事物的类时，采用这种模拟方式开发软件最容易。类图就能为开发人员提供这种模仿现实世界的表达方式。类图对系统分析也有很大帮助。它可以让分析员使用客户所采用的术语和客户交流，这样就可以促使客户说出所要解决的问题的重要细节。1.3.2对象图对象（object）是一个类的实例，是具有具体属性值的一个具体事物。例如，你的洗衣机的品牌可能是“Laundatorium”，型号为“Washmeister”，序列号为“GL57774”，容量为16磅。图1.2中的图标说明了如何用UML来表示对象。注意对象的图标也是一个矩形，和类的图标一样，但是对象名下面要带下划线。在左边的这个图标中，具体实例的名字位于冒号的左边而该实例所属的类名位于冒号的右边。实例的名字以一个小写字母开头。也可能是一个匿名的对象，如图1.2右边的图标所示。这仅仅意味着尽管你指明了对象所属的类，但你并没有提供一个具体的对象名。1.3.3用例图用例（use case）是从用户的观点对系统行为的一个描述。对于系统开发人员来说，用例是一个有价值的工具：它是用来从用户的观察角度收集系统需求的一项屡试不爽的技术。这对于那些试图建立一个供人使用的（而不是计算机设备使用的）系统是很重要的。我们在第章“介绍用例”、第章“用例图”、第章“收集系统需求”和第章“开发用例”中还要详细讨论用例。这里先举一个简单的例子。你使用一台洗衣机，显然是为了洗衣服（wash clothes）。图1.3说明了如何用UML用例图来描述这个需求。代表洗衣机用户的直立小人形被称为参与者（actor）。椭圆形代表用例。注意参与者（它是发起用例的实体）可以是一个人也可以是另一个系统。还应该注意，用例位于一个代表着系统的矩形中，而参与者在矩形之外。拼读注意为了能够清楚地表示这个概念，在读“use case”中的use的时侯，轻发一个s的音（就像truce的最后一个音），而不要发snooze的最后一个音。1.3.4状态图在任一给定的时刻，一个对象总是处于某一特定的状态。一个人可以是新生儿、婴儿、儿童、少年、青年或者成人。一个电梯可以处于上升或停止状态。一台洗衣机可以处于浸泡（soaking）、洗涤（washing）、漂洗（rinsing）、脱水（spinning）或者关机（off）状态。UML状态图如图1.4所示，该图能够描述上面所提及的状态。该图说明洗衣机可以从一个状态转移到另一个状态。转换从一个状态到另一个状态的转换并不总是线性的。有时侯，条件指明了不同的路径。我们将在第章“状态图”中讨论这一点。在上图中，最顶端的符号代表起始状态，而最底端的符号表示终止状态。1.3.5顺序图类图和对象图表达的是系统的静态结构。在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。UML顺序图所表达的正是这种基于时间的动态交互。仍以洗衣机为例，洗衣机的构件包括一个定时器（timer）、一个注水的进水管（water piper）和一个用来装衣物的洗涤缸（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.3.6活动图正如上一小节中提到的步骤一样，用例和对象的行为中的各个活动之间通常具有时间顺序。图1.6显示了步骤4到步骤6之间按顺序的UML活动图。再论转换在前面的“转换”中，我说过从一个状态到另一个状态的转换并不总是线性的，有时侯会有不同的路径。活动图中也是这样，我们将在第11章“活动图”中了解到这一点。1.3.7协作图系统的工作目标是由系统中各组成元素相互协作完成的，建模语言必须具备这种协作关系的表达方式。前面提到的顺序图就具备这种功能，图1.7所示的UML协作图（communicationdiagram）也能够完成此任务，不过其表达方式和顺序图略有不同。图1.7并不是和图1.5中的顺序图功能等同的协作图，它只是捕获了定时器、进水管和排水管之间的头几条简单的消息。它并不是按垂直方向表示时间顺序，而是通过消息标记前面的数字来表示时间顺序的。顺序图和协作图都能够表示对象之间的交互。因此，UML中它们被合称为交互图（interaction diagram）。名称变化协作图（communication diagram）是UML2.0版本中的新名称。在以前的1.x版本中，它叫做collaboration diagram。由于2.0版本的出现，你会看到这两个术语混用，请不必大惊小怪，因为它们是一回事。1.3.8构件图构件图和下一个要介绍的部署图将不再使用洗衣机这个例子来做说明，因为构件图和部署图和整个计算机系统密切相关。现代软件开发是基于构件的，这种开发方式对群组开发尤为重要。这里暂不对此做详细介绍，仅用图1.8来说明如何用UML1.x版本表示软件构件。这是UML 2.0有所改进的地方。鉴于很多建模工作者反映这个图标很糟糕，UML 2.0使用一个改进的标记。图1.9给出了表示一个软件构件的新的方式。尖括号做什么用？图1.9中，单词component外围的尖括号是做什么用的？这个符号在UML中有着特殊的作用。我们将在稍后的部分“关键字和构造型”中介绍。1.3.9部署图UML部署图显示了基于计算机系统的物理体系结构。它可以描述计算机，展示它们之间的连接，以及驻留在每台机器中的软件。每台计算机用一个立方体来表示，立方体之间的连线表示这些计算机之间的通信关系。图1.10是部署图的一个例子。1.4其他特征前面曾提到过UML提供了一些用来扩展模型图的特征。本节描述这些特征中比较突出的一些。1.4.1注释有时图中的某一部分不会给出明确的解释。此时UML注释（note）很有用场。可以把注释看成是图形化的黄页。注释的图标是一个带折角的矩形。矩形框中是解释性文字。图1.11是注释的一个例子。注