第1章UML导论

第1、2、3章学习提示第1章的重点是：模型和建模的概念，应当结合实际例子对模型在软件开发中的地位和作用有一个正确的理解。搞清楚模型、模型元素、图和视图之间的关系，分析模型和设计模型之间的关系，设计模型和代码之间的关系。对于方法学，应当知道为什么在软件开发中要使用它，结构化方法和面向对象方法的基本区别。方法学包括语言和过程，UML是一种语言。结合第2章的学习，理解为什么说对象模型是UML和面向对象程序设计语言共享的共同的计算模型和在软件开发过程中使用UML的好处。第2章的重点是：理解什么是对象、链接、消息和对象模型，对象有那些特性，这些特性对软件开发带来什么好处。书中说“对象模型的基本性质是计算发生在对象之中和对象之间。”你对这句话是怎样具体理解的。你对于对象模型在软件开发中的作用是怎样理解的。结合库存控制例子知道为什么要引入类、关联、抽象类和多态性，并将这些概念与相应代码相对照，具体了解这些代码与对象的特性的关系，如何创建对象，如何保持链接，如何传递消息，以及相应的UML表示法。2．10讨论了“对象模型的适用性”。你的观点是什么？同意、不同意还是部分同意部分不同意，提出自己的看法和依据。第3章概述了有代表性的软件开发过程模型。你能说明在什么情况下使用什么模型比较合适吗？你对统一过程模型如何评价？如果你了解极限编程(XP)也可以对统一过程和XP说说你的看法。本书每章的习题对于理解课文很有帮助，可以自由选做。第1章UML导论统一建模语言（UnifiedModelingLanguage），简称UML，按照UML的设计者所言，是一种“通用的可视建模语言，用于说明、可视化、构造并文档化软件系统的体系结构”。本章阐述软件开发过程中如何使用模型，以及像UML这种语言的作用。文中描述了UML的高级结构及其语义的非形式说明，以及设计表示法和代码之间的关系。1.1模型与建模模型在软件开发中的使用非常普遍。本节先介绍模型的两种典型用法，即在描述现实世界的应用中和实现应用的软件系统中的用法，随后讨论这两种模型之间的关系。1.1.1软件模型软件开发通常按以下的方式进行：一旦决定建立一个新的系统，就要写一个非正式的描述说明软件应该做什么，这个描述称作需求说明书（requirementsspecification），通常是经过与系统未来的用户磋商制定的，并且可以作为用户和软件供应商之间正式合同的基础。完成后的需求说明书移交给负责编写软件的程序员或者项目组，他们去相对隔离地根据说明书编写程序。幸运的话，结果程序能够按时完成，不超出预算，而且能够满足最初方案目标用户的需要。但不幸的是在许多情况下，事情并不是这样。许多软件项目的失败引发了人们对软件开发方法的研究，试图了解项目为何失败，结果得到了许多对如何改进软件开发过程的建议。这些建议通常以过程模型的形式，描述了开发所涉及的多个活动及其应该执行的次序。过程模型可以用图解的形式表示。例如，图1.1表示一个非常简单的过程，其中直接从系统需求开始编写代码，没有中间步骤。图中除了圆角矩形表示的过程之外，还显示了过程中每个阶段的产物。如果过程中的两个阶段顺次进行，一个阶段的输出通常就作为下一个阶段的输入，如虚线箭头所示。图1.1软件开发的原始模型开发初期产生的需求说明书可以采取多种形式。书面的说明书可以是所需系统的非常不正规的概要轮廓，也可以是非常详细、井井有条的功能描述。在小规模的开发中，最初的系统描述甚至可能不会写下来，而只是程序员对需要什么的非正式的理解。在有些情况下，可能会和未来的用户一起合作开发一个原型系统，成为后续开发工作的基础。上面所述的所有可能性都包括在“需求说明书”这个一般术语中，但并不意味着只有书面的文档才能够作为后继开发工作的起点。还要注意的是，图1.1没有描述整个软件生命周期。在本书中，术语“软件开发”是在比较狭隘的意义上使用的，它只包括软件系统的设计和实现，而忽略了生命周期的其他一些重要组成部分。一个完整的项目计划还应该提供例如项目管理、需求分析、质量保证和维护等关键活动。单个程序员在编写简单的小程序时几乎不需要比图1.1更多地组织开发过程。有经验的程序员在写程序时心中会很清楚程序的数据和子程序结构，如果程序的行为不是预期的那样，他们能够直接对代码进行必要的修改。在某些情况下，这是完全适宜的工作方式。然而，对比较大的程序，尤其是如果不止一个人参与开发时，在过程中引入更多的结构通常是必要的。软件开发不再被看作是单独的自由的活动，而是分割为多个子任务，每个子任务一般都涉及一些中间文档资料的产生。图1.2描述的是一个比图1.1稍微复杂一些的软件开发过程。在这种情况下，程序员不再只是根据需求说明书编写代码，而是先创建一个结构图，用以表示程序的总体功能如何划分为一些模块或子程序，并说明这些子程序之间的调用关系。图1.2较复杂的软件开发过程这个过程模型表明，结构图以需求说明书中包含的信息为基础，说明书和结构图在编写最终代码时都要使用。程序员可以使用结构图使程序的总体结构清楚明确，并在编写各个子过程的代码时参考说明书核对所需功能的详细说明。在开发一个软件期间所产生的中间描述或文档称为模型。图1.2中给出的结构图在此意义上即是模型一个的例子。模型展现系统的一个抽象视图，突出了系统设计的某些重要方面，如子程序和它们的关系，而忽略了大量的低层细节，如各个子程序代码的编写。因此，模型比系统的全部代码更容易理解，通常用来阐明系统的整体结构或体系结构。上面的结构图中包含的子程序调用结构就是这里所指的结构的一个例子。随着开发的系统规模更大、更复杂以及开发组人数的增加，需要在过程中引入更多的规定。这种复杂性的增加的一个外部表现就是在开发期间使用了更广泛的模型。实际上，软件设计有时就定义为构造一系列模型，这些模型越来越详细地描述系统的重要方面，直到获得对需求的充分理解，能够开始编程为止。因此，使用模型是软件设计的中心，它具有两个重要的优点，有助于处理重大软件开发中的复杂性。第一，系统要作为整体来理解可能过于复杂，模型则提供了对系统重要方面的简明描述。第二，模型为开发组的不同成员之间以及开发组和外界如客户之间提供了一种颇有价值的通信手段。本书描述面向对象设计中所用的模型，并举了一些模型的使用实例。1.1.2应用模型在软件开发进入系统设计和编码阶段之前，也用模型来帮助理解系统所针对的应用领域。这些模型通常称为分析模型，相对照的是设计模型，如上面所讨论的结构图。这两类模型可以通过这样的事实区分：分析模型不同于设计模型，它不涉及要开发的系统的任何特性，而是力求捕捉“现实世界”中的业务的某些方面和特性。总之，分析模型和设计模型满足相同的需要并带来同样的益处。它们支持的或与之相互作用的软件系统和现实世界系统往往都非常复杂，千头万绪。为了管理这种复杂性，系统的描述需要着重于结构而非细节，并要提供系统的一个抽象视图。这个抽象视图确切的特性将依赖它产生的目的，而且通常需要多个这样的视图或模型为系统提供一个足够的全景。典型地，分析模型描述应用中处理的数据和处理数据的各种过程。在传统的分析方法中，这些模型用图表示，如逻辑数据模型和数据流图。值得注意的是使用分析模型描述业务过程，早于并且独立于这种过程的计算机化，例如，组织结构图和说明特定生产过程的示意图在商业和工业中已经使用了相当长的时间。1.1.3分析模型和设计模型的关系在开发任何有效的软件系统期间，上面定义的分析模型和设计模型很可能都要产生。这就引出了一个问题：它们之间的关系是怎样的？软件开发过程传统上划分为若干阶段。分析阶段最终以产生一组分析模型而结束，随后是设计阶段，它产生一组设计模型。在这种情况下，分析模型用来形成设计阶段的输入，设计阶段的任务是创建支持分析模型中规定的特性和要求的结构。这样划分工作有一个问题，在多数情况下，分析和设计模型产物中使用的是完全不同的语言和表示法，这就导致从一个阶段转移到下一个阶段时需要一个翻译过程，分析模型中包含的信息必须用设计模型要求的表示法重新阐述。显然，这里存在一个危险，就是这个过程容易出错，而且很浪费。问题是，如果在开发过程中剩余的阶段要用设计模型取代分析模型，那么为什么还特意创建一个分析模型呢？而且，如果两种模型之间存在表示法上的差异，就难以肯定分析模型中包含的全部信息都准确地提取并且用设计表示法表示。面向对象技术的一个承诺就是，通过对分析和设计使用同样的模型和建模概念，来消除这些问题。按照这种设想，分析和设计模型之间任何明显的差别将会消除。显然，设计模型包含分析模型中未表现出来的低层细节，但希望的是分析模型的基本结构在设计模型中能够保持并且可以直接识别。除了其他之外，可以期望，这样能够消除与分析和设计表示法之间的转换相关的问题。分析和设计使用相同建模概念的一个后果是这两个阶段之间的区别变模糊了。这个转变最初的动机是希望软件开发能够视为一个“无缝”的过程：分析将标识现实世界系统中的有关对象，并在软件中直接表示这些对象。从这个观点看，设计基本上就是向基础的分析模型中加入详尽的实现细节，分析模型在整个开发过程中将保持不变。在详细讨论了面向对象的主要概念之后，将在2.10节中更详细地考虑这个观点的真实性。本书的目的是解释面向对象方法使用的建模概念，说明如何用UML中定义的表示法表示模型。本书的中心是设计以及在软件开发中使用设计模型，但是相同的建模概念同样适用于分析模型。分析是不同于设计的技术，要有效地实现分析还要学习许多技巧，但是作为结果的分析模型可以使用书中介绍的表示法完美地表示。1.2方法学（methodologies）软件开发并不是简单地坐在终端前键入程序代码，在大多数情况下，需要采取中间开发步骤，并且产生程序结构的若干抽象模型，以解决面对的问题的复杂性。这些点对于只包括一个程序员的开发和常规的团队开发同样适用。多年以来，已经试验了许多不同的开发软件策略，一些特别成功的或者广泛适用的策略已经形成并作为方法学发表。在软件工程界，术语“方法学”通常用于（或误用于）简单地指一种建议的开发软件系统的策略或方法。如图1.1和1.2所示的过程模型，它们说明了若干开发活动和各个阶段产生的制品，解释了一种方法学的本质方面。然而，用于“工业化生产”的方法学要比这两个图复杂得多。方法学对软件开发在至少两个重要方面提出了指导。第一，方法学定义了能够有助于开发一个系统的若干模型。如上节所说明的，模型在一个抽象层次上描述系统的特定方面，因此使得关于系统的讨论可以在一个适宜的高度层次上进行，而不会过早地涉及低层细节。方法学还定义了一组规范表示法来描写建议的模型，形成文档。通常，这些规范表示法是图形化的，因而导致了图形在软件开发中的广泛使用。模型以及描述模型的表示法一般称为方法学定义的语言。方法学在定义语言的同时，还定义了软件开发中包含的各种不同的活动，并指定了执行这些活动应当有的次序。这些活动和次序共同定义了一个开发过程模型，过程模型可以用如同图1.1和1.2那样的图形描述。由方法学定义的过程在规范化上远不如语言定义，为了适合于具有不同需求的应用，甚至可能不愿在写程序之前进行设计的程序员的应用，通常要预想到大量的灵活性，允许方法在广泛的多种多样的情形下使用。方法学定义的过程可以认为是定义了一个项目的概要进度表或计划。这个过程中的每个阶段，如图1.1和1.2所示，定义了特定的“可交付的工作成果”，这些可交付物的形式一般由方法学的语言指定。方法学的使用，除了在软件开发技术方面的帮助外，对项目管理也会有很大帮助。方法学的分类已经公布的许多方法学之间存在着大量的相似之处，在此基础上可以将方法学分为几大类。这些相似性的出现，是因为不同的方法学对如何描述软件系统的底层结构，有着共同理解的基础。因此，相关的方法学经常会建议在开发中使用非常类似的模型。当然，有时两个模型之间的关系可能因为使用不同的表示法而不明显，这种表面上的差异可能隐藏但是不会消除底层结构的相似性。众所周知的是称为结构化方法（structuredmethods）的一类方法学，包括结构化分析、结构化设计及它们的