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

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

摘要
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及InternetWeb系统的方法。它的根本目标是降低动态数据库驱动的Web站点的维护成本。它提倡系统进行形象化表示，以便展开设计上的讨论。它是一个迭代式过程，包括Web页可视元素的分解，及这些元素与数据库实体的关联关系。RMM是一种用于动态Web站点创建和维护的“完整详尽”的方案。
不过，在构建Web应用程序方面RMM就显得无能为力了。Web应用程序以业务逻辑为中心，它包括了许多实施业务逻辑的技术机制，而这些内容在RMM表示法中并未充分说明。客户端脚本编写、Applet和ActiveX控件等技术为促进系统业务规则的执行发挥了重大作用。另外，Web应用程序还可用作分布式对象系统的交付机制。Applet和ActiveX控件可以包含那些独立于Web服务器，通过RMI或者DCOM与服务器端构件异步交互的构件。复杂应用程序还可利用多个浏览器实例和客户机上的框架，建立并维护自己的通信机制。
既然所有这些机制都对系统的业务逻辑有促进作用，因此同样也需要为它们建模。而且，由于它们只表示部分业务逻辑，它们需要与其余的系统模型集成。在很多情况下，大部分业务逻辑在Web服务器后、服务器端的某一层执行。建模语言和表示法的选择通常要按照这一端的应用程序的需要来决定。随着UML作为一种正式的对象建模语言被OMG所接受，越来越多的系统开始用UML表示。许多人选择UML作为软件密集型系统的建模语言。于是Web应用程序建模的主要问题变成了：“如何在应用程序的其余部分表示在特定Web构件中执行的业务逻辑？”答案取