UML软件工程组织

作者注：

此部分根据RUP的资料进行整理，作者将此部分为序言，逐步分析以UML建模实现Web Service架构，以下的将采用以WebLogic提供服务，基于Java实现为例说明。此部分作者直接引用资料或相关图片知识产权属于RUP提供商。

近年来，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 所接受，越来越多的系统开始用 UML 表示。许多人选择 UML 作为软件密集型系统的建模语言。于是 Web 应用程序建模的主要问题变成了：“如何在应用程序的其余部分表示在特定Web构件中执行的业务逻辑？”答案取决于我们用UML在那些特定的Web元素和技术中表示系统业务逻辑执行的能力。

本文旨在简要介绍Web应用程序建模存在的问题和可能的解决方案。其中着重讲述在构架上对 Web 应用程序有重要意义的构件，以及如何使用 UML 对它们进行建模。本文假定读者熟悉UML、面向对象技术的原理和 Web 应用程序开发。文中描述的工作基于一些无偏向性的假设。

· Web 应用程序是日益复杂的软件密集型系统，它们在关键的任务中发挥着越来越重大的作用。

· 管理软件系统复杂性的一种方法是对它们进行抽象和建模。

· 软件系统一般有多个模型，每一个模型代表一个不同的观点、不同的抽象和详细级别。

· 哪个抽象和详细级别是合适的，这取决于开发流程中的工件和角色活动。

· 软件密集型系统的标准建模语言是统一建模语言 (UML)。

建模

通过简化一些细节，模型可以帮助我们理解系统。如何选择建模对象对理解问题和提供解决方案有重大影响。Web 应用程序与其他软件密集型系统一样，通常由用例模型、实施模型、部署模型、安全模型等一组模型来表示。Web 系统还另有一个专用模型，即站点图。站点图是对贯穿整个系统的 Web 页和导航路线的抽象。

目前采用的大部分建模方法都适用于各种 Web 应用程序模型的开发，因而无需对它们进行进一步的讨论。不过，有一个非常重要的模型，分析/设计模型 (ADM)，在尝试将 Web 页、与其相关的可执行代码和其他元素纳入模型时，确实出现了一些困难。

在决定如何建模时，确定正确的抽象和详细级别对于是否能让模型用户享受到建模带来的好处至关重要。一般而言，最好对系统的工件建模。工件就是那些为生成最终产品而构建和操纵的真实生活中的实体。对 Web 服务器的内部构件建模，或者对 Web 浏览器的具体构成部分建模，这对于 Web 应用程序的设计员和构架设计师并没有什么帮助。页、页之间的链接、构成页的所有动态内容，以及在客户机上出现过的页的动态内容，对这些建模才是重要的，而且是非常重要的。设计员设计的、实施员实施的正是这些工件。页、超链接、客户机和服务器上的动态内容正是需要建模的对象。

下一步是将这些工件映射到建模元素。例如，超链接自然映射到模型中的关联关系元素。超链接代表了从某一页到另一页的导航路径。将这种思路进行扩展，页就可以映射到模型逻辑视图中的类。如果 Web 页是模型的一个类，那么页的脚本自然就映射为这个类的操作。脚本中的所有页范围 (内的) 变量映射为类属性。Web 页可能包括一套在服务器上执行的脚本（准备页的动态内容），以及另一套完全不同的只在客户机上执行的脚本（如 JavaScript），考虑到这一点时，一个问题就出现了。在这种情况下，当我们查看模型中的 Web 页类时，我们搞不清楚在准备页的过程中哪些操作、属性甚至关系在服务器上处于活动状态，而当用户与页交互时哪些在客户机上处于活动状态。另外，Web 应用程序中传递的 Web 页最好是作为系统构件建模。简单地将 Web 页映射到 UML 类不会对我们理解系统有所帮助。

UML 的创始人意识到总会存在这样的情况：初始的 UML 不足以获取一个特定领域或构架的相关语义。为了解决这个问题，他们确定了一种正式扩展机制，允许实践者扩展 UML 的语义。该机制允许定义可应用到模型元素的构造型、标注值和约束。

构造型是一种修饰，允许我们为建模元素定义新的语义。标注值是可以与建模元素相关联的键值对，允许我们在建模元素?quot;标注"任何值。约束是定义模型外形的规则。它们可表示为任何形式的文本，或者用更正式的对象约束语言 (OCL) 表示。

本文讨论的工作引入了为 Web 应用程序所作的一种 UML 扩展。这种扩展从整体上看超出了本文的范围，然而这里还是讨论了其中大部分的概念和解释。

关于建模最后还要注意一点，一定要明确区分业务逻辑和表示逻辑。对于典型的业务应用程序而言，只有业务逻辑才应成为 ADM 的一部分。表示细节，如动画按钮、浮动帮助和其他 UI 增强方式通常不属于 ADM。如果为应用程序单独构建一个 UI 模型，则可在其中纳入表示细节。ADM 需要始终将重点放在业务问题和解决方案的表达上。在今天这个 Web 设计师的时代，对 Web 页外观的设计和实现最好由专业人员（技术绘图师）取代传统的开发人员来完成。