摘要：本文描述了怎样使用rational软件公司提出的RUP（Rational
Unified Process Rational 统一过程）理论来开发web应用。本文特别关注于软件生命周期的前端部分，以及如何集成使用RUP理论的创意设计过程和软件工程过程。本文包含了context
integration公司对RUP的一些应用经验和扩展，context
Integration 公司是一家领先的web解决方案集成商，为其名列财富1000公司的客户提供web解决方案，并使用了该公司自己的wow（Web
Opportunity Workshop）软件和web开发优化理论：inContext。
简介
过去几年里，出现了一种新一代的软件模式，即经常谈到的e-commerce,
e-business等等。这些web应用软件使客户和商业公司具备了在线商务处理、供应链集成、动态满足客户要求以及个性化服务等能力。这些系统具有鲁棒的，可伸缩的和可扩展的架构，可以提升性能并且能处理大量的不可预知的商务交易负载。这种架构的特点是多层的、封装了商务逻辑、集成了多种遗留下来的异构系统。本文主要讨论如何建立这种类型的web应用软件。在本文的上下文中，我们称这种类型的软件系统为web解决方案（web
solution）。
开发web解决方案与开发其他应用软件有许多相似点，但在也有许多值得注意的不同之处。在许多方面它象是一种消费媒体，例如电影和电视。就和任何一种消费类产品一样。web解决方案的外型和观感被品头论足，同时还必须被新的一类人所接受，如市场人员、创意设计师和商务执行官。因此，对于web开发人员来说，挑战不仅仅在于要掌握新的软件技术，还必须使用一种能促进上述这一类新型涉众达成一致意见的开发过程。本文试图成为成功构造web解决方案的路标，该方案将具有良好的用户界面，并使用RUP作为基本的方法来开发。
本文在关注创意设计过程的重要性的同时，也希望能指出其他过程的重要性，例如架构、配置管理和测试。例如，对架构关注不够或缺少早期的架构运行测试，将可能会导致软件架构很脆弱，并且不能适应所需承受的处理负载。在本文末尾我们主要讨论了一些最好的实践方法，这些方法对于成功地实施基于web的项目是必须的。
在传统的软件开发中集成创意设计
此前人们从未象今天对待web应用一样，如此关注应用软件的用户界面，也从没有对用户界面给予如此高的的重视度。对以前的日子和技术而言，用户在不同程度上是被动地接受软件。但现在，他们不再被动，web上的市场经济对基于软件的商务活动有了更大的影响力。为什么这样说？因为在新的由web应用软件构建的市场环境中，客户并不是购买软件，然后安装在他们的机器上，他们在web上冲浪，并且立即判断出web界面是否吸引他。要构建一个成功的web解决方案的关键之一，就是要使web应用程序有引人注目的外观。所以在软件开发的各个过程中，都有必要集成创意设计过程。
用例图统一创意设计过程和软件设计过程
web解决方案对传统软件开发进行了扩展，它把软件工程的世界和艺术与创意设计的世界融合起来。这两个世界在过程、技能和文化上都不同。因为文化上的冲突，这些不同点常常成为一个web项目中的主要绊脚石。从通常意义来说，用例提供了对web应用软件预期行为的通用表达方式，这些表达方式大家都能理解。
用例提供了项目相关人员如用户、经理、艺术指导、构架师和程序员等相互进行联系的通用语言，任何人都可以使用这种语言与项目取得沟通，并描述web应用将做些什么。它允许人们用商业解决方案方面的语言进行交谈，每个人都根据用例确定的规则来表达。
要求
构建web解决方案与开发其他应用软件相比，要涉及到更多的人员。这些人员通常包括商业执行官、市场人员、创意设计人员、客户支持人员和技术研发团队等等。拥有一种能够促进这些人员相互交流的过程是成功的关键。
成功的web解决方案起始于引人注目的视觉外观。这种视觉外观必须由该web解决方案的涉众来亲自开发，并且要确保一开始就和项目的目标保持一致。视觉表现应符合以下目标：
1、必须与要解决的问题相适应
2、定义系统的边界
3、描述系统最重要的特征
一旦视觉外观取得一致意见，项目的涉众将要召开交流促进会，以进一步定义系统的用户，以及系统应该为这些用户提供的服务。这些用户和服务将使用统一建模语言（UML）进行记录归档。在UML语言中，用户被称为活动者（actors），服务被称为用例（use
cases）。这种将需求文档化的方法可以使用户说清楚他们到底需要什么服务，也能使开发人员完整而精确地验证用户需求。用例还能为开发过程提供一个前后一致的思路，我们接下来将会看到这一点。
无论何时，都要尽可能重用以前web项目的用例。在“web时代”，这对我们快速构建合适的解决方案是很重要的。正如设计模式和分析模式一样，也存在用例模式。例如：任何一个web上的零售店都有许多相同的用例。
因此不要做重复的事情，应从过去的项目中挖掘出可重用的用例来使用。
在开发系统用例的同时，还应在增补规格书中加入非功能性需求的描述，一些通用的术语也应该加入到词汇表中。增补规格书包含了一些对通常需求（对整个系统而言）的描述，如可用性、稳定性、性能、安全性、web机群和可支持性等。这个词汇表保证了项目成员对重要的概念保持统一的理解。
创意设计大纲
开发web解决方案需要更加重视用户接口的创意设计。在定义了活动者和用例的同时，就已经得到了初步的用户接口方案。更进一步的用户接口方案在web开发团体中通常被称做创意设计大纲。创意设计大纲定义了如下内容：
1、网站的总体风格（例如这个网站是权威性的，或是轻松幽默的，或是服务性的？是偏重于保守的还是充满煽动性的？）
2、用户将以什么样的方式来访问这个网站（例如他们的连接速度如何？）
3、用户将使用什么样的浏览器
4、网站是否使用了框架结构
5、网站在色彩的使用上是否有限制
6、如果有用，需要定义一个色彩标准指南（包含网站的logos和总体色调的标准）
7、需要一些什么样的动态效果点缀（例如鼠标翻滚效果、动画、滚动新闻、多媒体等等）
导航图
导航图是web解决方案中的一种用层次树方式显示的视图，能够描述网站的用户如何访问该网站。这种层次图通常被称作网站地图，但是我们选择“导航图”这种称法，因为“网站地图”这个短语有多个含义。导航图的每一层显示出到达该层对应的屏幕/页面需要多少次点击。通常，你总是希望只需在起始页（通常被称作主页）上点击一次，即可到达你的web站点上最重要的区域。
在项目的早期确定网站导航图，可以提供一种有效的沟通媒介，便于项目的涉及人员和项目开发团队之间交流。用户也可以更好地想象浏览该web应用的情况，创意设计人员可以更好地了解网站导航模式。用例模型用于描述系统向最终用户提供怎样的服务，因此导航图是自然地从用例模型进化而来的。由于上述原因，导航图应该在最初的用例模型确定后再创建。（有时，项目的涉众会在创建用例模型之前，预先勾画出了网站的导航图。在这种情况下，这个早期的导航图能起到为用例建模工作提供素材的作用，这样能保证网站能提供它的涉众所预期的所有功能。）
导航图是“用例故事板”技术的变种，“用例故事板”在Rational统一过程的“用户接口建模”行为中进行了定义。要开发导航图，首先应为每一个用例定义一个主窗口或主页面。在这个阶段，我们还不能确切地知道每一页看起来会是什么样子，甚至不能确切知道到底会有那些具体的页面。所以我们关注于定义“逻辑页面”。这些逻辑页面是可选的，将随着用户接口的发展完善被采纳或被抛弃。逻辑页面用UML的构件—边界类来分析描述。
随后在设计和实现阶段，我们将用HTML页面或其他可视元素来替代UML的描述。一旦逻辑页面被定义了，导航图着眼于描述用户如何从一个逻辑页面浏览到另一个，同时描述了逻辑页面提供的主要特性。作为例子，见图2、3和4。这使我们能从更高层次来观察导航图。对大型系统而言，人们通常会为每一个活动者定义一个导航图（见图3和4）。为了更深入地挖掘细节，每一个用例也需要定义同类的视图，以便定义那些用户在执行用例时将会浏览到的更多的页面（边界类）。当这些页面（边界类）被定义时，我们同时也描述了它们所处理的信息内容。
创意设计比选方案（Creative Design Comps）
创意设计比选方案向涉众提供了web解决方案的一些可选的视觉外观设计方案，以便推进创意设计过程，最终得到一个确实吸引人的视觉设计。
“比选方案”包含了一些网站的视觉外观模型。这些模型通常是一些有代表性的“平面”图形，由许多帧描绘浏览窗口外观的浏览视窗图组成。做方案比选的意图在于先就网站的视觉规范达成一致意见，然后才进行明显更费资金的HTML原型的开发。比选方案的非功能性（非功能性指它们仅仅是平面图形，不是真正能够交互的HTML页面—译者注）的特点也有助于避免产生误解。
Rational统一过程提供了一个活动，即用户接口原型建模，它提供了一个收集用户接口反馈意见的通用方法。在web开发方面，我们把这个活动稍微扩充了一下，提出了创意设计比选方案的概念。要创建比选方案，我们应选择一个最重要的用例，然后开发出许多可选的视觉外观设计方案（例如至少10个以上）。我们从这个方案集中选出三个最有希望的设计提交给涉众。通常在项目的涉众就最终的web设计方案达成一致意见以前会有三次迭代。这是一个创意设计和迭代的过程。
一旦这个过程达成一致意见并终止后，创意设计比选方案将进一步开发成具有实际功能的用户接口原型。非功能性的比选方案仅仅是第一代原型，用于征求那些关注网站视觉外观特性的涉众的意见。
web设计元素（Web Design Elements）
web设计元素指的是那些被组合到一个网站各个页面中的零散的图形图象。保证网站上用户接口的一致性对于保证网站的可用性来说是必须的。网站应该给用户提供前后一致的浏览体验。为了做到这点，项目开发过程中必须在网站中统一使用一整套标准的图形组件。这些图形组件应该在项目起始之初就设计好，还应设计如何使用这些图形组件的指南，以便项目组的全体成员都明白何时以及如何使用这些组件。
例如，web设计元素可以包含象导航图标和页面背景等图形元素。在整个网站中重复使用高质量的标准图形元素可以保证网站的一致性，并缩短网站投用前所需时间，减少开发费用，同时通过使用一套更高质量的图形也可以提高网站的开发质量。
Rational 统一过程在“工作流细节：分析行为”中区分了用例和组件。随后在“工作流细节：设计组件”中描述了这些组件的精确细节、实现和单元测试过程。
web设计元素是与最初的web用户接口原型一起创建的。创意设计比选方案中可以挑选加工出用于web用户接口原型的web设计元素，并可以从中确定最终的用户接口原型，同时web设计元素也被确定下来。
初始web用户接口原型
创意设计比选方案最终发展成用户接口原型。用户接口原型的外观基于最终确定的创意设计比选方案，并在Rational统一过程的“活动：原型化用户接口”阶段被创建，设计用户接口原型时使用了上面定义的web设计元素。初始web用户接口原型通常只支持了一小部分系统功能，这个原型是基于最重要和最典型的用例来创建的。
初始web用户接口原型的开发能促进用户和设计者的交流，更好地沟通对网站的外观和给人的感觉的看法，同时网站相关的功能也被开发出来。在投入主要资金用于开发用户接口和网站功能之前，尽早获得用户对网站的看法是很有必要的。
UI 指南
web用户接口原型完成后，就可以编写用户接口设计的详细指南。该设计风格指南将指定何时以及如何使用web设计元素、色彩配置、字体、层叠样式表，以及确定导航单元将怎样起作用和放置在哪里。UI
指南在“活动：开发用户接口指南”中被定义。
web 用户接口总体原型 （Full Web UI Prototype）
web
用户接口总体原型对初始用户接口原型进行了扩展，使其包含了所有的用例。现在原型将能演示所有可浏览的页面和网站上的所有可视元素。根据系统的后端功能开发情况，页面中使用了真实或虚拟的数据。
尽管人们希望在项目的每一个建设迭代过程中，作为web
用户接口总体原型组成部分的页面都能够被精心开发，但web
用户接口总体原型开发的目的主要在于使项目的涉众就用户接口的范围和详细性质达成一致。
web 用户接口总体原型源于Rational
统一过程指南的“用例故事板”。
总体导航图
在完成web
用户接口总体原型的开发后，应该创建总体导航图。该导航图基于最初的网站导航图和web解决方案中所有已定义的用例。该导航图应该包含web
用户接口原型中所有已定义的页面（屏幕）。
它不仅仅是漂亮的图片“新经济”最主要的基础是软件，特别是internet和www软件。许多在互联网淘金热中建立的公司陷入了一个误区，他们认为在“web时代”搞开发不需要实行健全的软件工程规范。公司要建立新颖的web
解决方案需要关注用户接口是否吸引人，但同时也要建立健壮的系统架构。web用户没有耐心浏览设计糟糕的网站，瞬间就可能失去一个潜在用户。互联网和WWW的出现带来了很多新机会，这些web解决方案总是必需的软件系统。
过去几十年来研究的软件工程理论表达得很清楚：要关注质量、进行迭代开发并减少风险，建立柔性架构以适应迅速变化的世界。在web开发中不遵循健全的软件工程方法学是导致项目失败的常见原因。最近一些被大力宣扬的网站的失败证实了这点。下面讨论Rational
统一过程所描述的6个最具实践意义的软件开发理论，同时也讨论怎样在web解决方案的开发中使用这些理论：
迭代开发：迭代开发基于不断地发现、发明和实现，它强调在开发周期的早期辨明项目的风险，以便能够一致地、及时地、富有效率地管理和克服这些风险。这种可控的迭代开发过程可以使web应用的发布周期更短、更快。
管理需求：需求管理是一种系统的方法，用于提取、组织、沟通和管理软件敏感系统或应用的不断变化的需求。由于web应用的需求经常随市场的口味和倾向而变更，因此跟踪市场的发展并在项目开发周期中跟踪这些变化是非常有必要的。
利用组件架构：架构从组件、组件集成方式和组件间交互作用的机制和模式等方面描述了应用软件的结构。
鉴于web应用软件必须是开放的和可扩展的，并且在当前基础上可以变更，因此使用组件架构是至关重要的。组件架构易于扩充，并能适应正在进行的变化，可以最大限度地重用以前开发的组件和第三方开发的组件。
在某些情况下，web解决方案的架构可以购买得来。只要可能并合适，就可以购买架构。某些功能如人性化、内容管理、负载平衡以及安全等等，都已包含在产品包中。使用包含组件的产品对于你的公司尽快发布web解决方案是很重要的。
可视化建模：模型可以帮助我们理解和弄清楚问题以及解决方案，模型是对实体的简化，用于理解复杂的系统。web架构是多层的和分布式的，在设计、开发和配置时比较复杂。管理这些复杂的需求需要建立慎重考虑的和清晰的架构和设计。可视化建模符号如UML之类提供了表示系统架构和设计的机制。
检验质量：质量关注过程和产品。无论是中间过程还是最终产品，都应有高质量。web产品主要用于公用场合，失败的代价会很高。在性能和稳定性不好的情况下，公众就会不再注意这个web站点。web应用的发布周期确定后，尽早地、经常地、自动化地对其进行测试是很重要的。
控制变更：web应用包含许多对象和组件，他们由许多人创建和编辑，经常并行被开发出来。在这个持续开发的工作和环境中，控制变更是必须的。多个版本和配置的并发管理需要在整个开发周期内进行严格的配置和变更管理。
辅助工作室（facilitated workshops）
构建web解决方案要把许多不同类型的涉众组织起来，涉及到不同的学科，包括市场、技术、以及许多内部和外部的组织单元。例如，一个b2b(business
to business)的外联网（extranet）解决方案通常涉及到组织内部的不同涉众，以及可能成为该网站客户的其他组织内部的涉众。一个消费者网站将涉及到客户服务和市场部门的涉众，以及真正的顾客。为了定位这些需求，使用交流促进会来沟通是必须的。
在RUP中，我们找到了如何操作需求工作室（requirements
workshop）、用例工作室（Use-Case Workshop）和用例分析工作室（Use-Case
Analysis Workshop）等的指南。Context Intergration公司把这些工作室和创意设计过程结合起来,构建到一个工作室里面,这就是web
Opportunity Workshop (WOW), 它由一系列的为WEB开发人员所特制的开发辅助工具所组成。WOW的目标在于给公司提供web解决方案的路标。这样公司可以在一周内确定初始需求（使用图片、用例模型、辅助说明书和词汇表等形式）、创意设计说明（用创意大纲、导航图和创意设计比选方案等形式）以及一些最初的分析模型（对象模型和数据库模型）。公司们一致发现这些步骤有助于帮助他们快速认识到他们的web机会，同时使用那些精心设计并经过工业证实的方法（例如RUP）来创建他们的解决方案。
结论
RUP是一种能用于指导web开发的很好的基本方法，在Context
Intergration公司成功为其财富1000公司客户开发项目的过程中，这一点已得到证实。通过使用现有的RUP过程框架，将它与创意设计过程结合，并且使用辅助工作室来正确地开始项目，web解决方案可以被按预定计划成功地交付。 |
|