使用UML为Web应用程序构架建模..doc

Web 应用程序正变得越来越复杂，越来越重要。为了帮助管理这种复杂性，需要为 Web 应用程序建模。UML 是软件密集型系统的标准建模语言。在尝试用 UML 为 Web 应用程序建模时，很明显它的一些构件不能与标准的 UML 建模元素一一对应。为了让整个系统（Web 构件，以及传统的中间层构件）使用同一种建模表示法，必须扩展 UML。本文介绍 UML 的一种扩展方式（使用正式的扩展机制）。进行扩展是为了让 Web 特有的构件能与系统模型的其余部分集成，向 Web 应用程序的设计员、实施员以及构架设计师展示适当的抽象和明细级别。 近年来，IT 词汇表中出现了一条新的术语，它就是“Web 应用程序”。参与业务软件系统的所有人似乎都有构建 Web 应用程序的计划，而在与业务不相关的软件方面也有很多人对此感兴趣。对于很早前就采用这种构架的许多人来说，Web 应用程序这个词象系统本身一样，已经从成功的小型 Web 站点插件发展成了强壮的 n 层应用程序。Web 应用程序可以同时为分布在世界各地的、成千上万的用户提供服务，这种情况早已司空见惯。构建 Web 应用程序是一件严肃的事情。 在实际应用中，Web 应用程序这个词对不同的人而言含义略有不同。一些人认为凡是用到 Java 的都是 Web 应用程序，而另一些人则认为凡是使用 Web 服务器的都是 Web 应用程序。多数人的意见介于这两者之间。站在本文的角度，我们将 Web 应用程序大体定义为 Web 系统（Web 服务器、网络、HTTP、浏览器），在这个系统中，用户的输入（导航和数据输入）会影响到业务状态。该定义试图将 Web 应用程序确立为一个具有业务状态的软件系统，并且它的“前端”基本上是通过 Web 系统传递的。 Web 应用程序的总体构架是一个客户机服务器系统，但二者有几点显著的区别。Web 应用程序最重要的优点之一在于它的部署。部署 Web 应用程序通常指的是建立网络的服务器端构件。客户端不需要特别的软件或配置。两者的另一个重大差异在于客户机和服务器通信的本质。Web 应用程序的基本通信协议是 HTTP，这是一个无连接协议，它不是为最大的通信吞吐量设计的，而是为强壮性和容错而设计的。在 Web 应用程序中，客户机和服务器的通信通常围绕 Web 页导航进行，而不是在服务器端和客户端对象之间直接通信。在一定的抽象程度上，Web 应用程序中所有的信息传递都可描述为 Web 页实体的请求和接收。通常所说的 Web 应用程序构架与动态 Web 站点的构架并无太大区别。 Web 应用程序与 Web 站点，甚至是与动态 Web 站点的区别都要涉及到使用。Web 应用程序实现的是业务逻辑，它的使用改变了业务的状态（其状态为系统捕获）。这是很重要的，因为它确定了建模工作的重点。Web 应用程序执行业务逻辑，因此大多数重要的系统模型都侧重于业务逻辑和业务状态，而不是表示细节。表示很重要（否则系统将毫无用处），不过应尽量将业务和表示所关注的问题区分开。如果表示问题是重要的，甚至是复杂的，那么也需要对它们建模，但不必将它们作为业务逻辑模型的构成部分。此外，用于表示的资源更注重外观设计，而与实施业务规则关系不大。 关系管理方法 (RMM) 是与 Web 系统开发有关的一种方法/表示法。RMM 是一种用于设计、构建和维护 Intranet 及 Internet Web 系统的方法。它的根本目标是降低动态数据库驱动的 Web 站点的维护成本。它提倡系统进行形象化表示，以便展开设计上的讨论。它是一个迭代式过程，包括 Web 页可视元素的分解，及这些元素与数据库实体的关联关系。RMM 是一种用于动态 Web 站点创建和维护的“完整详尽”的方案。 不过，在构建 Web 应用程序方面 RMM 就显得无能为力了。Web 应用程序以业务逻辑为中心，它包括了许多实施业务逻辑的技术机制，而这些内容在 RMM 表示法中并未充分说明。客户端脚本编写、Applet 和 ActiveX 控件等技术为促进系统业务规则的执行发挥了重大作用。另外，Web 应用程序还可用作分布式对象系统的交付机制。Applet 和 ActiveX 控件可以包含那些独立于 Web 服务器，通过 RMI 或者 DCOM 与服务器端构件异步交互的构件。复杂应用程序还可利用多个浏览器实例和客户机上的框架，建立并维护自己的通信机制。 既然所有这些机制都对系统的业务逻辑有促进作用，因此同样也需要为它们建模。而且，由于它们只表示部分业务逻辑，它们需要与其余的系统模型集成。在很多情况下，大部分业务逻辑在 Web 服务器后、服务器端的某一层执行。建模语言和表示法的选择通常要按照这一端的应用程序的需要来决定。随着 UML 作为一种正式的对象建模语言被 OMG 所接受，越来