第7节 餐馆系统：实现.doc

第7章 餐馆系统：实现 前面几章已经讨论了餐馆预约系统的设计，本章描述该系统实现的某些方面。第1章阐明了对象模型的语义如何保证在设计及其实现之间存在紧密连接，本章举例说明将UML设计表示法转变为面向对象语言代码的一些简单而系统的技术。 预约系统是一大类交互式单用户应用程序的典型代表，这些应用具有图形化的用户界面，并通过输入设备，例如鼠标和键盘，检测用户的交互。在这样的应用中涉及大量的低层代码，以处理应用代码和输入输出设备之间错综复杂的交互。 由于这种代码是范围广泛的应用共有的，因而发展出了提供核心输入和输出功能的标准实现框架。现在，应用程序员通常只需要将实现特定应用的功能写入一个通用框架，而不用从零开始编写整个应用程序。7.3节讨论了框架的一般概念，并在7.4节介绍了将预约系统集成到Java AWT框架的细节。 7.1 实现图 在分析和设计活动期间产生的文档描述了软件应用的逻辑结构。这基本上是将系统作为可能细分到若干个包中的一组类看待。这些类的实例的动态行为是通过交互图和状态图进一步定义的。 在实现系统时，将用所使用的编程语言以某种方式表示这些类。这时，系统第一次呈现出实物形态，典型地是作为一组源代码文件。接着源代码被编译，产生各种目标文件、可执行文件或库文件。最后，这些文件在一个或多个处理器上可能结合其他资源而执行。 UML定义了两种实现图以文档化系统物理结构的各个方面。构件图（component diagram）文档化系统的物理构件以及它们之间的关系，而部署图（deployment diagram）文档化如何将这些构件映射到实际的处理器上。 7.1.1 构件 程序员一般在谈到类和实现类的代码时好像它们是相同的东西，但这二者之间的区别是很重要的。如果开发的程序要在多个环境中运行，也许是在不同的操作系统平台上，那么同样的类可能需要以多种方式，或许甚至是用不同的编程语言来实现。 为了明确这个区别，UML定义了构件（component）的概念。构件是表示系统部件的物理实体。存在很多不同类型的构件，包括源代码文件、可执行文件、库、数据库表等等，并经常用构造型来明确构件表示哪种实体。 图7.1显示了构件的UML表示法，它是一个边上嵌着小矩形的矩形框。类和实现类的构件之间的关系可以用二者之间的依赖性建模。这种依赖性有时用构造型“trace”标示，但如果图的含意已经很清楚，通常会省略构造型。 图 7.1 实现一个类的构件 7.1.2 构件图 组成系统的源文件可以显示在构件图上。构件图显示了用依赖性链接的构件，这种依赖性典型地表示构件之间的编译依赖。在两个源文件之间，如果要编译一个，另一个必须是可用的，那么二者之间存在编译依赖。在一个类使用另一个类，例如，作为一个属性的类型或者超类时就会发生这种情况。因而构件图文档化了系统的构造需求，并且，例如能够形成生成系统make文件的输入。 图7.2显示了餐馆预约系统的部分构件图，展示了表示层和应用层中的领域类。注意，构件图中保留了分析和设计模型中定义的包结构。除了预约类层次中的类放在单独一个源文件中之外，这个图基本上文档化了类和源文件之间的一一对应，如Java程序中常见的那样。 图 7.2 预约系统的构件图 7.1.3 部署图 部署图表明在部署系统时，系统中的构件如何映射到处理器。餐馆预约系统最初的意图是作为在独立的PC上运行的单用户应用来部署的，所以，图7.3所示的部署图有点无关紧要。进行处理的节点在部署图中用立方体表示，在该节点上部署的构件显示在立方体“内”。 图 7.3 预约系统的部署图 当系统在网络上部署时，部署图更具有说明性，可以在图中显示网络中的不同节点。因而部署图的目的是表明跨越不同节点的处理的物理分布。 7.2 实现策略 图7.2中的构件图显示了要实现预约系统而必须创建的源文件。然而，构件之间的依赖对源文件创建和测试的次序施加了特定的约束，并说明了实现的两种基本方法。 自顶向下实现从高层构件开始，按照依赖性箭头的方向，经由图7.2 “向下”进行。这种策略的优点是，能够在过程的早期测试系统的总体设计。缺点是需要为低层类创建桩（stubs）或临时实现，只有随着开发的进行在稍后才用这些类的真正实现代替。 自底向上实现从低层构件开始，在图中“向上”进行。这种方法使得单独构件的开发和设计更容易：当实现一个类时，所有它依赖的类都已经实现了，所以可以不需要开发桩就可以容易地对它进行编译和测试。 然而，自底向上方法的风险是将整个可执行程序的生成一直推迟到实现中相当晚的阶段。 这两种方法的折衷是采用一种更迭代的方法，并且不是从实现类而是从实现用例考虑。用这种方法，对每个类，开发者实现的是各个类中支持单个用例所需要的那些特征，然后充分地测试。然后一个接一个