UML图的种类(DOC可编).docVIP

第1章 UML简介 在本章中，你将学习如下内容： (　为什么需要UML？ (　UML的诞生。 (　如何用图表示UML模型的各个部分？ (　为什么使用UML提供的不同类型的图对我们来说很重要？ 统一建模语言（Unified Modeling Language，UML）是当今世界上面向对象系统开发领域中最激动人心的工具之一。为什么？UML是一种可视化的建模语言，它能让系统构造者用标准的、易于理解的方式建立起能够表达出他们想象力的系统蓝图，并且提供一种机制，以便于不同的人之间有效地共享和交流设计结果。 交流思想是极为重要的。在UML出现以前，系统开发往往是无计划的议题。系统分析员尽力去获取客户的需求，用某种他自己能够理解（但客户不一定总能理解）的表示法来产生需求分析文档，然后将这个分析转交给一个程序员或者一个程序员小组，并且期待着最后所开发出的系统正是客户所需要的。 一些术语 在本书中，系统（system）指的是硬件和软件的结合体，它能提供业务问题的解决方案。系统开发（system development）是为客户建立一个系统的过程，而客户（client）是需要解决问题的人。系统分析员（analyst）将客户所要解决的问题编制成文档，并将该文档转交给开发人员（developer），开发人员是为了解决客户的问题而构造软件并在计算机硬件上实施该软件的程序员。 由于系统开发需要人与人之间的交流，因此在开发过程的每个阶段中都很可能潜伏着错误。系统分析员可能没有正确理解客户的需求。他编制的文档客户可能不能理解。系统分析员经常编写出语句冗长、内容庞大的需求文档，项目组的其他成员很难用上这些文档，这真是添乱。可笑的是，这些无足轻重的文档常常把重要的需求（以及需求之间的相关性）挤出人们的脑海之外。因此，系统分析的结果对程序员来说可能很不明确，随后程序员据此构造出的程序很可能不仅难以使用而且根本不是客户所需要的最初问题的解决方案。 难道你不奇怪，为什么今天很多已经运行了很长时间的那些老系统既笨重、麻烦，而且又难以使用吗？ 1.1 在纷繁复杂中寻求解决问题的办法 在计算机时代的早期，程序员们在编制程序之前几乎很少对手头问题进行详细的分析。如果他们真地对问题进行了充分分析的话，问题也就不是如此了。通常他们一开始就自底向上地编写程序，随着时间的进展代码不断扩充。这种大胆进行尝试的做法添加了一丝浪漫色彩，但是在今天这样一个高商业风险的社会里，这样做被证明是不适当的。 如今，一个经过深思熟虑的计划至关重要。客户必须理解开发组做什么，如果开发组没有充分理解客户需求的话（或者如果客户在半路改变了自己的想法），客户必须能够指出需求所发生的变化。不仅如此，系统开发还是一个典型的群组工作，因此小组的每个成员必须要知道自己的那部分作品应该放到整体作品中的哪个位置（当然还得要知道这个整体作品是什么）。 随着世界变得越来越复杂，存在于这个世界中的基于计算机的系统也增加了复杂性。这些计算机系统通常包括多个硬件和软件单元、跨越长距离的网络设施，还要连接到信息量堆积如山的数据库上。如果你要创建一个成功的系统，怎么来对付这些问题的复杂性呢？ 最关键的一点是要用一种系统分析员、客户、程序员和其他系统开发所涉及到的人员能够理解和达成一致的方式来组织系统的设计过程。UML就提供了这种组织方式。 不首先建立一个详细的蓝图，你不会马上开始建造一个诸如办公大楼这样的复杂建筑物。同样，不首先编制一个详细的设计计划，那么你也不大可能马上就在这栋办公大楼中建立起一个复杂的系统。拿给客户看的设计计划就如同建筑设计师拿给楼的买主的建筑物设计蓝图。设计计划应该源于对客户需求的细致分析。 短的开发周期是当今系统开发的又一个显著特征。当所要求的截止日期一个又一个地接踵而来时，可靠的系统设计是绝对必要的。 现代社会频繁发生的公司兼并使可靠的设计显得尤为必要。当一个公司收购了另一个公司，新成立的组织可能要对正在进行中的开发项目的许多重要方面（实施工具、编程语言及其他）进行修改。具有自我调整能力的“防弹项目蓝图”能够适应项目的大规模变更。如果设计是稳定可靠的，即使实施过程中遇到了变化，实施过程照样能够平稳地进行。 可靠的设计需要一种能被系统分析员、开发人员和客户接受为标准的设计表示法，就像电子工程师在绘制电路图时所用的标准表示法以及在物理学中被作为标准的冯诺依曼图所用的表示法那样。UML就是这样的表示法。 1.2 UML的诞生 UML是Grady Booch、James Rumbaugh和Ivar Jacobson智慧的结晶，他们被人们称为“三个好朋友”。这几位先生在20世纪80年代和90年代的初期分别在不同的组织里工作，各自设计他们自己的面向对象分析与设计方法学。他们的方法学和其他同行竞争者相比取得了卓越