UML餐馆系统：实现

《UML餐馆系统：实现》由会员分享，可在线阅读，更多相关《UML餐馆系统：实现（18页珍藏版）》请在装配图网上搜索。

1、第7章 餐馆系统：实现前面几章已经讨论了餐馆预约系统的设计，本章描述该系统实现的某些方面。第1章阐明了对象模型的语义如何保证在设计及其实现之间存在紧密连接，本章举例说明将UML设计表示法转变为面向对象语言代码的一些简单而系统的技术。预约系统是一大类交互式单用户应用程序的典型代表，这些应用具有图形化的用户界面，并通过输入设备，例如鼠标和键盘，检测用户的交互。在这样的应用中涉及大量的低层代码，以处理应用代码和输入输出设备之间错综复杂的交互。由于这种代码是范围广泛的应用共有的，因而发展出了提供核心输入和输出功能的标准实现框架。现在，应用程序员通常只需要将实现特定应用的功能写入一个通用框架，而不用从零

2、开始编写整个应用程序。7.3节讨论了框架的一般概念，并在7.4节介绍了将预约系统集成到Java AWT框架的细节。7.1 实现图在分析和设计活动期间产生的文档描述了软件应用的逻辑结构。这基本上是将系统作为可能细分到若干个包中的一组类看待。这些类的实例的动态行为是通过交互图和状态图进一步定义的。在实现系统时，将用所使用的编程语言以某种方式表示这些类。这时，系统第一次呈现出实物形态，典型地是作为一组源代码文件。接着源代码被编译，产生各种目标文件、可执行文件或库文件。最后，这些文件在一个或多个处理器上可能结合其他资源而执行。UML定义了两种实现图以文档化系统物理结构的各个方面。构件图（compone

3、nt diagram）文档化系统的物理构件以及它们之间的关系，而部署图（deployment diagram）文档化如何将这些构件映射到实际的处理器上。7.1.1 构件程序员一般在谈到类和实现类的代码时好像它们是相同的东西，但这二者之间的区别是很重要的。如果开发的程序要在多个环境中运行，也许是在不同的操作系统平台上，那么同样的类可能需要以多种方式，或许甚至是用不同的编程语言来实现。为了明确这个区别，UML定义了构件（component）的概念。构件是表示系统部件的物理实体。存在很多不同类型的构件，包括源代码文件、可执行文件、库、数据库表等等，并经常用构造型来明确构件表示哪种实体。图7.1显示了

4、构件的UML表示法，它是一个边上嵌着小矩形的矩形框。类和实现类的构件之间的关系可以用二者之间的依赖性建模。这种依赖性有时用构造型“trace”标示，但如果图的含意已经很清楚，通常会省略构造型。 图 7.1 实现一个类的构件7.1.2 构件图组成系统的源文件可以显示在构件图上。构件图显示了用依赖性链接的构件，这种依赖性典型地表示构件之间的编译依赖。在两个源文件之间，如果要编译一个，另一个必须是可用的，那么二者之间存在编译依赖。在一个类使用另一个类，例如，作为一个属性的类型或者超类时就会发生这种情况。因而构件图文档化了系统的构造需求，并且，例如能够形成生成系统make文件的输入。图7.2显示了餐馆

5、预约系统的部分构件图，展示了表示层和应用层中的领域类。注意，构件图中保留了分析和设计模型中定义的包结构。除了预约类层次中的类放在单独一个源文件中之外，这个图基本上文档化了类和源文件之间的一一对应，如Java程序中常见的那样。 图 7.2 预约系统的构件图7.1.3 部署图部署图表明在部署系统时，系统中的构件如何映射到处理器。餐馆预约系统最初的意图是作为在独立的PC上运行的单用户应用来部署的，所以，图7.3所示的部署图有点无关紧要。进行处理的节点在部署图中用立方体表示，在该节点上部署的构件显示在立方体“内”。 图 7.3 预约系统的部署图当系统在网络上部署时，部署图更具有说明性，可以在图中显示网

6、络中的不同节点。因而部署图的目的是表明跨越不同节点的处理的物理分布。7.2 实现策略图7.2中的构件图显示了要实现预约系统而必须创建的源文件。然而，构件之间的依赖对源文件创建和测试的次序施加了特定的约束，并说明了实现的两种基本方法。自顶向下实现从高层构件开始，按照依赖性箭头的方向，经由图7.2 “向下”进行。这种策略的优点是，能够在过程的早期测试系统的总体设计。缺点是需要为低层类创建桩（stubs）或临时实现，只有随着开发的进行在稍后才用这些类的真正实现代替。自底向上实现从低层构件开始，在图中“向上”进行。这种方法使得单独构件的开发和设计更容易：当实现一个类时，所有它依赖的类都已经实现了，所以

7、可以不需要开发桩就可以容易地对它进行编译和测试。 然而，自底向上方法的风险是将整个可执行程序的生成一直推迟到实现中相当晚的阶段。这两种方法的折衷是采用一种更迭代的方法，并且不是从实现类而是从实现用例考虑。用这种方法，对每个类，开发者实现的是各个类中支持单个用例所需要的那些特征，然后充分地测试。然后一个接一个地实现更多的用例，对这些类增加所需要的另外的特征。7.3 应用框架像餐馆预约系统这样的应用程序，包含了一定数量的特定于应用的功能，这些功能与专用于该餐馆的业务对象和规则的实现有关，但是，也存在着大量和其他使用基于窗口的图形用户界面的应用程序共享的功能。应用程序员几乎没有必要编写这些执行通用低

8、层功能的代码。大多数编程语言和环境现在支持一种重要的复用层，使处理例如输入输出的代码能够以类的框架（framework）的形式复用。典型地，交互式图形应用的框架会支持以下功能。1它将管理应用与其环境之间的交互。在窗口环境中，框架可以支持应用所用窗口的创建和随后的管理。在applet的情况下，框架可以提供浏览器启动和终止在网页上运行applet所必需的功能。2它将提供检测用户输入并将这些输入以若干标准的良好定义的消息的形式提交给应用程序。这个输入可能直接由物理设备产生，譬如鼠标和键盘，或者以用户界面窗口部件为中介，譬如菜单项和按钮。3它将提供一个图形函数库，使得输出产生并显示在应用程序控制的窗口

9、中。术语“框架”是比喻的使用，它意味着两件事。第一，框架代码可以被想象为是围绕着特定于应用的代码，就和包围着照片的相框一样。第二，框架提供了一个完整的但又只是一个应用骨架，可以用作一个支持结构，能够在上面建立完整而专门的应用程序。框架在使应用程序员免于关注低层方面的作用，可以形象化地予以表示，如图7.4所示。这个非形式的图说明了，框架用什么方式使应用程序员可以避开用于处理输入输出的低层应用编程接口（API）。它还说明了，框架如何通过提供到低层功能的标准接口而可以在许多不同的应用中复用。 图 7.4 用户界面框架的作用7.3.1 热点框架作用的这种一般描述并没有解释，程序员如何能够将应用代码和框

10、架提供的代码集成到一起。面向对象的框架往往借助于热点（hotspot）达到这个目的。在框架中，热点是应用程序要特殊化的类，如图7.5所示。 图中的虚线是非正式的附加物，指示框架类和特定于特殊应用代码之间的分界线。 图 7.5 一个热点类假定热点类提供了显示窗口及窗口内容的基本功能。这些功能在所有应用程序中必须提供，并且在许多标准情况下执行。例如，如果用户打开了另一个窗口使应用窗口变暗了，然后又关闭或移动了该窗口时，那么就需要重画该应用窗口的内容以恢复正确的显示。框架将检测这些事件，并在适当的时候会向窗口类，即热点，发送一个消息，通知它刷新自己的显示。一般地，热点类定义若干由框架在标准时间调用的

11、操作。这种情形在图7.5中表示为从其他框架类发送到热点的消息。应用程序员的基本任务是定义热点类的特化，并覆盖这些操作，以实现特定于一个特殊应用的功能。热点类中的操作可能是抽象的。在产生完整的应用程序之前，应用程序员必须提供这些操作的实现。但是，在大多数情况下，可以为操作写一个切合实际的缺省实现，即使是琐细的什么都不做的一个实现。假若这样，可以从框架生成一个完整的应用程序，即使价值不高，应用程序员要做的全部工作就是覆盖所关注的操作。确切地说，哪些操作需要覆盖取决于该框架所提供的实现。图7.6所示的是热点接收一个指示用户移动了鼠标的消息。在这种情况下，不存在框架可以切合实际地提供的缺省功能，所以热

12、点类为这个操作提供了一个空实现。应用程序在特化的类中覆盖了这个操作，而动态绑定机制保证了在框架类发出一个消息时，会执行特定于应用的代码。 图7.6 覆盖框架操作在其他情况下，也许框架可能为一个操作提供有实际价值的缺省实现。图7.7说明了框架请求重新显示一个窗口及其内容的情形。在这种情况下，框架能够提供一些通用代码以重显示窗口背景、窗口的边界和滚动条等等。这些代码在图7.7中的“redisplay”方法中提供。另一方面，在窗口中显示特定于应用的内容的代码则必须由程序员提供。如果程序员通过覆盖redisplay方法提供这些代码，就会丢失由框架提供的通用代码。原则上，这个方法可以在覆盖函数中被复制，

13、但是这将消除使用框架所带来的许多益处。在这样的情况下，可以采用一种不同的机制。在图7.7中，热点类定义的第二个方法称为“displayContent”，该方法的目的是在窗口中显示特定于应用的内容。这里给了一个空的缺省实现，程序员覆盖的是这个方法。Redisplay函数在适当的地方调用这个增加的函数，以便将特定于应用的代码集成到通用框架中。那么，在运行时，当收到一个redisplay消息时，首先执行热点的redisplay函数；它调用显示内容的函数displayContent，而通过使用动态绑定，这个特化的函数将被执行。 图 7.7 覆盖“回调”方法像图7.7中的“displayContent”

14、这种操作称为回调（callback）函数或钩子（hook）函数。它们提供了一种技术，借此，应用程序员能够通过重定义框架方法调用的其他操作来扩充框架方法的功能。7.3.2 控制的倒置框架的使用带来了不同于传统风格的一种特殊编程风格。在传统模型中，程序员编写一个“主程序”，规定了应用程序内的整个控制流。应用可以被分解为一组类和函数，其中一些可以由库提供，但是实质上控制仍在程序员手中，程序员决定在程序运行时用户可以做什么。然而，当使用框架时，这个关系就颠倒过来了，这种情况通常被称为控制倒置（inversion of control）。程序中的控制流驻留在框架代码中，程序员只是提供一些函数，在过程中某

15、些合理确定的地方被调用。运行时的控制在用户手中，而不在程序员手中，程序员的工作是提供代码，以适当的方式响应用户的动作。因此，这种编程风格有时称为事件驱动。7.4 Java AWT框架作为使用框架的一个很简单的例子，本节描述如何用Java的抽象窗口操作工具包（Abstract Windowing Toolkit，AWT）框架支持餐馆预约系统如图4.3所概略说明的图形用户界面。该界面的结构常常见到，由带有一个标题和一个菜单栏的单窗口组成。显示有当前日期，窗口的其余部分由显示当前预约的区域占据，并可以在此检测鼠标事件。7.4.1 用UML文档化一个框架像AWT这样的框架完全是Java代码库，所以可以

16、用UML图文档化它们的结构和功能。通常，这作为一种理解框架如何被组织到一起以及如何使用框架的方法，可能非常有帮助。例如，图7.8展现了部分AWT框架的一个简化版本，是有关支持预约系统用户界面实现的一部分。 图7.8 一些AWT类（简化的）在图7.8中，AWT在Java包java.awt中定义，各种AWT类显示在相应的UML包内。组成用户界面的元素被称为构件，并被定义为抽象类“Component”的子类。某些构件，如被称为容器（Container）的构件可以包含其他构件，如“Container”和“Component”类之间的关联所示。边框（frame）是一种特殊的容器，表示应用程序窗口，它包含

17、标题、菜单栏，以及各种特定于平台的属性。菜单栏由一个另外的类定义，添加的关联记录了边框包含菜单的事实。另一类构件画布（canvas）定义了一块屏幕区域，上面可以产生任何类型的图形输出，并能够处理用户输入事件。在边框和画布之间没有预先定义的关系。用户产生的事件在子包java.awt.event中定义，它定义了一个接口“EventListener”。该接口由检测各种事件的各种各样的类实现。构件可以与一组监听器相关，以检测用户在该构件上产生的事件。图7.8显示了接口的另一种表示法，即连接到支持该接口的构件的一个小圆圈，在圆圈下面写上接口的名字。从“Component”类到“EventListener

18、”接口的依赖性文档化了构件可以附带有监听器的事实。7.4.2 集成预约系统和AWT框架在餐馆预约系统的实现中，为了利用AWT框架，我们必须确定AWT中需要特化的相关热点类。这些类中最重要的两个是“Frame”类和“Canvas”类。画布提供了用户界面的主显示区域必需的基本功能，即显示图形化资料和检测用户产生的事件的能力。在预约系统的设计中，这些任务是“StaffUI”类的责任。因此，一种切实的应用选择是将“StaffUI”作为java.awt.Canvas的一个子类实现，并通过重定义该类中适当的方法支持所需功能。然而，画布需要有一个容器来放置，所以我们另外需要一个“Frame”的子类，作为预约

19、系统的主应用窗口。至今，这个类还没有在设计中标明，因为它支持的例如“最小化窗口”这样的功能是由纯粹的通用操作组成的，这些操作在预约系统的用例中没有显式给出。这些新类如图7.9所示，它文档化了预约系统的表示层与AWT框架集成在一起的方法。 图7.9 将AWT框架用于表示层在预约系统中使用AWT还涉及了许多更低层的细节，然而一旦将总体策略展现在图7.9中，这些细节最好通过研究应用的源代码可能会更好理解，源代码可以从本书的站点获得。7.5 类的实现下面几节描述预约系统的Java实现的一些方面，说明设计中的各种UML特征如何映射到代码。这里提出的技术不是完成这种转换的唯一途径，但是具有清晰、简单易懂和

20、强调设计表示法与编程语言结构之间的密切关系的优点。7.5.1 类UML类图中的类作为面向对象语言中的类实现不会使人感到意外。图7.10显示了预约类，它具有在开发早期为其确定的属性和操作的一个子集。 图 7.10 Booking类这个类自然地可以作为一个包含等价的域和方法的Java类实现。图7.10所说明的预定类的Java类实现的要点如下。由于在设计类图中booking类是抽象的，所以它被实现为Java抽象类。定义了一个构造函数初始化属性的值，但是构造函数声明为protected，所以这个类的实例只能由子类创建。注意，在类图中经常省略了构造函数，但在类的实现中构造函数是必需的。类的属性在Java

21、中用域表示， UML的数据类型在必要的地方要转换为适当的Java的等价类型。类的操作在Java中定义为方法并应当有相应的实现，在这里相当琐细。“setArrivalTime”方法只对Reservation有意义，将它包含在Booking超类中是使所有的预约共享一个公共接口，但是提供了的是空实现，因而与它不相关的walk-in类可以忽略它。在实现一个类时，需要考虑其成员的可见性。如果设计者没有指定可见性，那么实现属性和操作的有用经验规则是：将属性转换为实现类的私有域，而将操作转换为实现类的公有方法。这反映了类的实现广泛采用的一种策略，它规定类的数据应该是私有的，并且只能通过它的操作接口访问。这个

22、规则的例外出现在该类的子类实例需要访问该类的属性时。像这个例子中一样，在这种情况下通常指定属性的可见性是protected。7.5.2 泛化图7.11显示了餐馆预约系统设计中的一个泛化的例子，这里在图7.10中定义的Booking类被代表两种不同预约的子类扩展。 图 7.11 预约系统中的泛化泛化可以使用Java中的继承实现。UML中的泛化允许无论哪里要求的超类实例都可以用一个子类实例代替，并从超类继承类的成员，而Java的继承语义保留了这两个特性，如下面“WalkIn”和“Reservation”类的实现要点所说明的。 “WalkIn”类在这里的实现相当小，因而可能会质问这究竟是否需要定义为

23、单独一个类。支持这里遵循的方法的理由将在14.2节更详细地讨论。7.5.3 类的重数定义类时，默认的是对系统可以创建的该类的实例数目没有限制。通常所需要的就是这样：例如，预约系统就需要创建和操纵预约类、餐台类和顾客类的多个实例。然而，在某些情况下，规定只能创建某个类的一个实例是有用的：例如，用户界面和预约系统类，由于它们在系统中起着中心的协调作用，我们只想各要一个实例。如图7.12所示，用在类图标的右上角包含相应的重数，可以显示出这个决定。只能实例化一次的类称为单件（Singleton）类。 图7.12 类重数的符号使一个类始终只有一个实例被创建的方式来实现一个类是可能的，其实现的标准方法记录

24、在称为单件（Singleton）的设计模式中。如果一个类作为单件实现，那么至多只能创建它的一个实例，并且这个实例可以由其他类在需要时获得。单件模式的主要思想是使类的构造函数不可访问，因而使用单件类的类就不能创建该类的实例。单件类把单独一个实例作为静态数据域保存，客户可以通过一个静态方法获得该实例并在第一次调用这个静态方法时初始化这个唯一的实例。这个模式在预约系统类的应用由下面的代码要点说明。7.6 关联的实现在类图中，关联把类联系在一起。尽管所有面向对象编程语言都提供了对类的概念的直接支持，但没有一种通常使用的语言提供可以直接用以实现关联的特征。因此，在实现一个设计时，想一想如何处理关联的问题

25、是必要的。关联的作用是定义系统运行时连接对象的链接的特性。链接表明一个对象知道另外某个对象的存在和位置。此外，在必要时链接还可以作为信道，使消息沿着信道发送到链接的对象。这提示了对象之间的各个链接可以使用引用实现。引用，实质上是对象的地址，当然记录了该对象的位置和本体，并且借助于引用可能调用到所链接的对象的成员函数，从而模拟了消息传递。因此，实现两个类之间的关联的一个简单策略就是，在每个类中声明一个域保存对所关联的类的实例的引用。然而，关联具有某些逻辑特性，不能用这种有点过于简单化的方法明确处理，而需要在关联的实现中仔细考虑。这些特性在本节的剩余部分简单考虑。在第13章将给出对实现关联的各种方

26、法的更系统的处理。7.6.1 双向性关联和链接分别连接类和对象，但是除非使用导航性注文，否则对链接能够在哪个方向遍历就没有限制。例如，协作图中的链接可以作为两个对象之间的通信信道，并且消息可以沿着这个信道在任一个方向发送，如设计需要所要求的那样。这种特性一般用说关联和链接是双向的来表达。另一方面，引用是单向的。如果对象x持有对对象y的引用，这就使x可以访问y，并能够调用y的成员函数，但y对x根本没有任何了解。为了实现一个双向链接，需要两个引用，一个从x到y，另一个从y回到x。为了说明其不同，图7.13显示了三个对象之间的链接，以及与之对照的在两个方向上实现链接所需要的引用。引用通过表示访问方向

27、的箭头与链接相区分。 图7.13 用引用实现双向链接尽管的确可能以这种方式用一对引用实现链接，但是有许多很好的理由说明这是不方便的，并应该尽可能避免。首先，为了支持引用的环状结构，相关的类声明必须互相引用。这只能以增加两个类之间的耦合为代价而实现，对结果代码的简单性和可维护性有不利影响。其次，在链接的整个生命期中，实现链接的两个引用必须保持相互一致。它们必须一起被创建和销毁，并且不能被独立地改变。然而，对引用编程是很容易引起错误的，而所需引用数目的成双结对也增加了潜在问题。即使定义了维护引用的一个安全的方案，并始终坚持这个方案，维护两个引用也可能有相当大的开销。7.6.2 关联的单向实现幸而，

28、依赖于系统的动态特性，通常并不需要在两个方向上实现关联。可以看到消息从预定发送到顾客对象，但是永远不会从顾客到预定。为了提供支持，很明显在预定中必然需要保存对其顾客的引用，但是让每个顾客对象都保存对他们的预定的引用，可能不能获得直接的益处。因此，通过只在实际上使用关联的方向提供引用，可以简化关联的实现。在实践中，需要在两个方向支持的关联相对地几乎没有。例如，在预约系统的第一次迭代中，消息从预定对象传递到顾客对象，但是决不会从顾客到预定。因此我们可以决定，为了简化实现，只在从预定到顾客的方向上实现这个关联。这个决定可以用导航性注文的形式加入到类图中，如图7.14所示。 图7.14 使关联成为单向

29、的这个关联简单的单向实现可以在预定类中用一个数据成员，如下所示，保存对所链接的顾客的引用，同时还给出了构造函数中初始化该引用的代码。通过选择只在一个方向上实现关联，我们在目前的易实现性和未来的可修改性之间做了一个折衷。现在不可能在从顾客到预定的方向上遍历这个关联。未来对系统的任何修改，例如想要检索一个特定顾客的所有预定，将会比本来不用这种方法更难以实现，因为我们将不得不退回去增加反向遍历链接的能力。7.6.3 实现重数约束在用引用实现关联时，类图包含的关于关联的重数信息并不总是能自动地保持。例如，图7.14中的关联声明，每个预定对象总是和恰好一个顾客对象关联。然而，Java中的引用可以始终具有

30、null值，不引用任何对象。因此，如果在系统运行的任何时候都是如此，系统将与关联指定的重数不一致。重数约束只能通过增加代码来保持，这段代码将在适当的地方明确地检查该变量没有存储null值。例如，如果试图创建一个没有与顾客对象相关联的预定，下面的代码会抛出一个异常。当关联指定一个大于1的重数时，如图7.15所示的例子，会出现与重数有关的问题。这里的问题是，单个的变量显然不能保存对多个链接的对象的引用。图 7.15 一对多的关联为了实现一对多的关联，一个类必须定义一种适当的数据结构，以保存未指定数目的引用，而不是一个单引用变量。在Java中，Vector类通常是一个适当而简单的选择，因为向量可以增

31、长，以容纳所需要的那么多的数据值。采用这种策略的“BookingSystem”类的代码要点如下。7.7 操作的实现类图包含了静态信息，例如类的定义及其成员，可以通过将其转换为实现的结构特征实现。类图还包含了每个类中的操作的定义，但是没有表述每个操作进行的处理。这种动态信息包含在用例实化所产生的交互图中，有些情况下在基于一个类一个类的状态图中得到总结。在实现一个操作的时候，首先应该整理显示相应消息的交互图。这些图表明了当执行该操作时发送了其他哪些消息，因而该操作的实现应该调用哪些类的方法。如果不同的交互图显示了不同的行为，就必须实现适当的控制结构，在涉及的不同情况之间进行判别。此外，如果所考虑的

32、类存在状态图，那么可以将状态图用作实现类中操作的指导，如下面所说明的那样。7.7.1 状态图的实现状态图提供了有关一个对象在其生存期中如何行为的动态信息。这些信息可以很容易地转换为代码，反映在类的方法的实现中，这些方法在被调用时需要知道对象当前的状态，以决定如何反应。 如同对类图那样，也希望使用一种系统的方法将包含在状态图中的信息转换为代码。这节用图6.15所示的预约系统类的状态图举例阐明一种可能的方法。构成这种方法的基本思想是，在预约系统类中定义的一个域中明确记录预约系统的当前状态。这个状态图中定义了两个不同的状态，“NotSelected”和“Selected”，这些状态被定义为预约系统类

33、中的常量，并用一个“state”域保存系统当前状态所对应的值。图6.15没有为系统指定初始状态，但合理的假设是在系统启动时没有被选择的预约，因而状态变量应该被设置为“NotSelected”。下面类的部分定义说明了这种情况，以及代表预约系统状态的常量值的定义。发送给预约系统的消息有可能在不同的时间引起不同的行为，这取决于它当前的状态。通过将每个方法组织为一个switch语句，可以在类的实现中反映这种特性。switch语句对状态变量的每个可能值都有一个case，每个case的代码指定了系统在那个特定状态下如果接收到了该消息时做些什么。如果遵循惯例，预约系统类中的每个方法将具有下面的模板指定的形式

34、。在一些方法中，很多case可能都是空，不过，包含所有这些case会使实现的结构清晰一致并易于修改。在每个不同的case中实现的特定行为有许多都能够直接来源于状态图中包含的动作，或者来自说明各种操作外部行为的顺序图。实现的详细资料最好通过餐馆预约系统的代码来研究。对状态图的这种实现方法的更详细描述在13.7节给出。7.8 小结许多软件开发现在都在应用框架的环境中进行。框架提供了半完全的、通用的应用程序，并使程序员避免使用低层的API。 面向对象的框架典型地将定义一些“热点”类。为了开发应用程序，程序员必须特化这些类，并覆盖各种操作，以提供特定于应用的功能。通过特化Java API中“Apple

35、t”和“Canvas”类，可以将图形编辑器作为Java applet实现。设计中的类自然映射到实现中的类，泛化则映射到继承。编程语言中不包含与关联相同的特征。关联可以借助类中的域实现，该域保存对关联类实例的引用。状态图可以通过使状态在实现中显式化，以系统地指导类中各个操作的实现。7.9 习题7.1 分析预约系统的代码，并通过扩充图7.2为该系统绘制一个完整的构件图。预约系统的代码可以从本书的站点获得。7.2 假如这家餐馆将预约系统部署在多台PC上，每台PC都连接到一台单独的机器，该机器上维护预约信息的一个共享数据库。绘制一个部署图说明这种新配置。7.3 假如这家餐馆要改进预约系统，以使预约信息

36、可以显示在手持设备上，该设备通过无线网络连接到运行应用层的PC上。绘制一个部署图，说明系统的这种配置。7.4 图7.5、7.6和7.7略微改变了UML的规则，在类图中包括了消息。对这些图各绘制一个相应的顺序图，图中显示框架类的一个实例和热点特化类的一个实例，以及在每次交互中将发送的消息。7.5 分析餐馆预约系统的代码，并产生图7.9的一个扩充版本，文档化系统表示层中的所有类，以及它们与java.awt包的关系。7.6 扩充预约系统的实现，以支持对预约的一般编辑，如在习题4.9和5.10的答案中描述的那样。7.7 扩充预约系统的实现，以支持超过餐台大小的预约的处理，如在习题4.10和5.11的答案中描述的那样。7.8 扩充预约系统的实现，允许调整预约的时间长短，如在习题4.12和5.12的答案中描述的那样。7.9 扩充预约系统的实现，允许为预约自动分配餐台，如在习题4.13和5.13的答案中描述的那样。7.10 扩充预约系统的实现，以支持等待名单的功能，如在习题4.14和5.14的答案中描述的那样。7.11 扩充预约系统的实现，允许对多张餐台进行预约，如在习题4.16和5.15的答案中描述的那样。