用UML构建Web应用（第二版） (2010 年度畅销榜NO.2231 )

本书是享有广泛赞誉的《Building Web Applications with UML》的新版本。基于作者作为Web开发人员的广泛经验，并且结合有用的读者反馈，本书指出并阐述了基于页面的Web应用特有的建模问题，提供了实用的建议和简单明了的解决方案。
这个彻底修订的第二版反映了围绕Web软件和系统开发的最新技术和问题。你可以从本书中发现：
更新、扩展了第一版本的例子和图
更全面地阐述了涉及Web应用安全的最新内容
详细地阐述了Web应用开发中已验证的对象技术概念
健壮的、可升级的和功能丰富的Web应用是可以获得的。使用业内标准UML(Unified Modeling Language，统一建模语言)进行设计可以允许Web应用开发人员方便地将设计和其他用UML建模的系统进行整合。
本书面向的读者对象是项目经理、构架师、分析师、设计者和实施者。它阐明了在用UML的WAE(Web Application Extension，Web应用扩展)进行建模的过程中具有挑战性的部分。因为UML已作为软件系统建模的标准语言被广泛接受，所以毫无疑问，UML是Web应用设计建模的最佳选择。WAE从语义上和结构上扩展了UML的符号，使你能够使用Rational统一过程或其他类似方法为Web专有的构架元素建模。而且，使用UML允许将Web应用的建模作为完整系统的一部分，以及作为必须反映在每个应用中的集成业务逻辑的一部分。
用这本书作为指导，你可以清楚地了解怎样在基于页面的Web应用设计的建模过程中指出所出现的独特问题，而且更重要的是，可以了解如何将你的模型直接转换成有用的代码。

序
前言

第一部分 建模和与Web相关的技术概述

第1章 绪论
1.1 本书内容
1.2 建模的角色
1.3 过程的角色
1.4 构架的影响

第2章 Web应用基础
2.1 HTTP
2.2 HTML
2.3 Web应用

第3章 动态客户端
3.1 文档对象模型
3.2 脚本
3.3 JavaScript对象
3.4 自定义JavaScript对象
3.5 事件
3.6 JavaApplet
3.7 ActiveX/COM

第4章 超越HTTP与HTML
4.1 分布式对象
4.2 RMI/IIOP
4.3 DCOM
4.4 XML
4.5 Web Service

第5章 安全性
5.1 安全性隐患的种类
5.2 技术上的隐患
5.3 服务器端的隐患
5.4 客户端的隐患
5.5 安全性策略
5.6 安全系统建模

第二部分 构建Web应用

第6章 过程
6.1 软件开发概述
6.2 Web应用的软件开发
6.3 工件

第7章 定义构架
7.1 构架视点
7.2 构架活动
7.3 Web应用表示层: 构架模式

第8章 需求和用例
8.1 前瞻
8.2 需求
8.3 术语表
8.4 收集需求并为之定义优先级
8.5 用例
8.6 用例模型
8.7 用户体验

第9章 用户体验
9.1 用户体验模型的工作
9.2 用UML为用户体验建模

第10章 分析
10.1 迭代
10.2 分析模型结构
10.3 用户体验模型映射
10.4 构架细化

第11章 设计
11.1 UML的Web应用扩展
11.2 设计Web应用
11.3 映射用户体验模型
11.4 整合内容管理系统
11.5 Web应用设计原则

第12章 高级设计
12.1 HTML框架
12.2 高级客户端脚本
12.3 虚拟的HTTP资源与物理的HTTP资源
12.4 JSP自定义标签

第13章 实施
13.1 数字商店的主要控制机制
13.2 术语表应用的标记库

附录A Web应用扩展轮廓版本2
A.1 概述
A.2 从HTTP到UML
A.3 从UML到HTML
A.4 映射Web元素到UML以及映射UML到Web元素

附录B 数字商店参考应用
B.1 前瞻
B.2 前景
B.3 需求和特性
B.4 软件构架文档
B.5 样例屏幕快照

附录C 受控制的控制器模式
C.1 用例视图
C.2 分析模型类
C.3 分析模型协作

附录D 主模板模式
D.1 概述
D.2 用例视图
D.3 逻辑视图

附录E 术语表应用
E.1 简介
E.2 需求和用例模型
E.3 用户体验模型
E.4 设计模型
E.5 组件视图
E.6 样例屏幕快照

本书的第一版是在1999年末面市的。在很大程度上，它是基于我为零售行业和卫生部门开发基于ASP的应用的一些经验而写成的。我那时候已经是一个独立的顾问了，但是在完成那本书之前不久，我加入了Rafionfl软件公司。在Rafionfl公司工作，使得我有机会去访问一些机构并且与他们进行合作，那些机构正从事于构建以Web为中心的应用。我曾经见过各种各样的情况，有的是管理良好的、开发着顶尖质量的软件的开发小组，有的是管理混乱的、急于寻找正确的指导的开发小组，还有少数对这种应用持否定态度的开发者。 从第一版的公开出版到现在的两年时间里，我也已经感受到J2EE平台地位的提升，而且不得不说：自从那时起，我的绝大多数Web应用开发经验都是与J2EE体系结构相伴而行的。以至这个第二版中的绝大多数素材都是面向Java环境的。这并不意味着．NET开发人员，甚至Cold Fusion和PHP开发人员就不能利用本书的指导来构建应用。事实上完全可以。只有在设计和实施的章节以及在参考应用里面的大多数例子，才是专门为基于JSP的应用而写的。 本书和前一个版本里面透露的一些思想，都是出于试图把我的面向对象的技能和Web应用开发领域相结合的一种期望的结果。在应用用例(usecase)分析的时候，我很少遇到麻烦，直到我开始创建分析和设计模型的时候我才意识到事情开始变得艰难起来。当创建一个Web应用的时候，我的概念焦点一直集中在Web页上。而且，我关于一个模型的想法不停地围绕着一个站点地图的概念。我知道，为了理解一个应用，贯穿一个系统的导航路径将具有无可非议的重要性，而且任何系统模型将不得不包括它们。 我关于对Web应用进行建模的早期尝试是伴随着Rumbaugh的OMT(Object Modeling Technique，对象建模技术)一起开始的，后来，当UML(Unified Modeling Language，统一建模语言)0.8版本开始公开发布后，我开始应用它。我知道，为了使得任何建模技术更有用，它需要捕捉的不仅要有与Web特征元素(例如Web页面和超链接)相关的语义，而且还要有它们与系统的后台元素(例如中间层对象和数据库)的关系。那时候，我发现了OMT和UML都不能够充分地表达某些东西，而在我看来，这些东西在一个Web应用里面是非常重要的。 作为一个在某种程度上还算成功的对象实践者和一个工程师，我突然得出了一个结论，那就是一个整套新的开发方法和理念是急需的。毕竟，如果业已存在的方法和符号不能够满足我的需要，那么最明显的解决方法就是去发明一个。当然，这是一个陷阱，这个陷阱曾使得许多像我们这样呆在软件行业的人们陷入其中。在我的闲暇时间里，我开始起草一个新的基于图形和语义的方法，去表达Web应用的体系结构。在为我自己的工作感到骄傲之余，我开始把它展示给我的两位同——Joe Befumo和Gered Ruldolph，他们都是经验丰富的对象实践者。他们的直接反应是：为什么?我努力去解释那些牵涉到Web应用开发的论点，以及那种对于在视觉上真实地表达他们的设计的需求。然而，所有听到我陈述的人都仍然认为开发一个新的方法和理念对于原来的方法和理念有点矫枉过正了。 我开始重新思考我所从事的这项工作。我并没有太多地为自己辩护，认为我是对的，而其他人都是错的。还有更多的准备工作等着我去做。我重新审视了一下我的原始需求：为了用一个对于抽象和具体程度恰到好处的标准来表达Web应用的设计，而且更重要的是，这个标准要作为这个系统其余部分设计的一个部分。因为UML正在企业中运用得如火如荼，我意识到我做的任何工作都不能离开UML。 于是，我重新转向了UML。这时候它已经是0.91版本了，而且，一个新的概念被包括进来了——构造型(stereotype)。开始，我并不懂什么是构造型。毕竟，UML规范并不是很轻易就能读懂的。它又长又难，但是我知道，在对Web应用建模的领域，任何成功必须是从这个方向开始的。最终，我开始明白了构造型和其他的扩展机制：标记值(tagged value)和约束(constraints)的含义是什么。我终于开始看到黑暗隧道尽头的一线光明。 现在我有了一个机制，利用它我可以介绍新的语义到UMI,语法里面，而不会对原有的语义有所影响。我一直明白，关键是要提供一个一致且连贯的思路，以一种正确的抽象标准，同系统的其他部分的模型一起，去对Web特有的元素进行建模。UML的扩展机制提供给我这个框架去做这件事。 下一步是开始通过建立构造型、标记值和约束来定义扩展。在图里面通过构造型元素来使用自定义图标的能力大大帮助了我，使得我对于直观图的关注变得容易得多。而且，Rational Rose，即我所选择的可视化建模工具，已经介绍了在Rose模型里面利用你自己的构造型的一个方法。我很快创建了一套用于Web页面抽象的图标集。我试图让它们具有一致性，它们大都是矩形，而且在左上角带有构造型标记。我利用有填充的狗耳朵来表示页面，用没有填充的狗耳朵来代表组件。没有带狗耳朵的图标则通常代表被包含的类，它们是不能被Web浏览器直接请求的。Web页面的组件的图标是三巨头曾经在他们的书《Unified Modeling Language User Guide》里面用过的图标的一个非常恰当的拷贝。 回头想想，我记得花了不到一天的时间来画这些图标。我没有对此花太多的时间，因为我一直相信最终某个具备更多经验的人会设计一些更有意义的图标。从那以后的四年时间里，那些图标基本上保持原样。然而，一个更简洁的版本出现了，它叫做“装饰”。本书的这个版本也会包括一些我如何手画这许多图标的例子，目的是为了说明在鸡尾餐巾纸上对Web系统建模都是可能的。(事实上，我在讨论会上对于这类事情做了相当多的建模工作和深入思考。) 随着扩展功能的发展，也随着许多细节和不连贯的部分被修正，我一直额外关注代码自动生成的能力。在我的心目中，建模技术如果可能(仅仅在理论上)清晰地生成代码并且对代码进行逆向工程编译(reverse-engineer)，那么它就得到了验证。我甚至构造了一些Rose脚本的原型，它们的确限制了前向工程编译(forward-engineering)。从这一点开始，事情以飞快的速度进展。在奥兰多举行的1998年度Rational用户讨论会上，我公布了关于Internet的一份白皮书并提交了这一主题。Grady Booch对此工作很感兴趣，并且鼓励我。Addison—Wesley出版社问我是否有兴趣考虑把这一主题写成一本书。如果我当时就知道这本书写下去有这么难，我不敢确信我会答应。在起初的那本白皮书之后，我又为一些在线机构或者书面发行机构写了一系列其他的文章，而且开始对于扩展性进行经常性的电子邮件讨论。 自从这本书第一版公开发表后，Rational Rose公司开始把本书中介绍的自动Web建模的内容包括进来。在这一过程中，我开始有机会和一些顶尖的工程师——例如Tommy Fannon和Simon Johnston等一起工作，从而在UML具备正反向的设计功能之后应该是什么这一问题上，得到了更大的收获。因为他们的洞察力和其他很多Rational公司内外人士的努力，我相信这本书的新版和Web建模轮廓都会在当今的以Web为中心的构架应用方面更具健壮性和可行性。 本书面向的读者 本书目的是针对客户端服务器系统的构架师和设计者介绍一些关于Web开发的要点和技术。它将有助于项目经理去理解有关于Web应用开发的技术和要点。因为本书建立在已经存在的面向对象(OO)的方法和技术之上，所以就没有再去介绍这些内容。我们希望读者稍微熟悉一点面向对象的原理和概念，特别是要熟悉UML。我们同样希望读者至少熟悉一个Web应用的构架或环境。 对于客户端服务器系统的构架师来说，本书可以作为一个理解Web应用的技术和要点的指南。在关于哪一种技术适合服务于商业需求这个问题上，系统构架师需要做出决定，这些是通过需求和用例(use case)来表达的。第7章定义了三种主要的客户层构架模式，它们有助于对Web应用的构架进行分类。通过审查这些模式和它们的优缺点，构架师能够做出决定，从而定义一个应用的技术范围。根据任何工程规则，构架师必须对系统构架中运用到的每一种技术进行折衷权衡。在对可采用的技术以及它们之间因果关系的可靠理解的基础之上，我们能够找到一个合适的组合，使之最好地符合商业需求。 对于分析者和设计者来说，本书介绍了对于UML的一个扩展，它适合表达Web应用的设计。这个扩展的关键目标在于： ● 对适当的工件(例如Web页面、页面之间的关系、导航路径、客户端脚本以及服务器端页面生成)进行建模。 ● 在一个恰当的抽象和具体的标准上进行建模。 ● 使得模型中Web特有的元素能够与其他系统元素进行相互作用。 分析者／设计者必须能够用UML模型的术语来表达系统商业逻辑的执行。其思想是要对系统的商业逻辑有一个统一的模型。在模型中，一些商业逻辑是由传统的服务器端对象和组件(例如中间件、事务处理监视器、数据库)执行的，也有一些是由Web元素(例如浏览器、客户端脚本)执行的。 对于项目经理来说，本书讨论了关于Web应用开发的一些潜在的问题和要点。本书同时对开发小组成员的责任、活动和角色等方面也给出了指导。除了讨论分析者／设计者和构架师之外，本书还讨论了开发过程中的其他角色。项目经理是对于整个项目的健康发展负有责任的人，需要对所有的角色和与这个开发过程相关的每个人的责任有一个清晰的了解。 本书包括了更多的例子和图表。根据读者的反馈，我意识到从一些构架良好的例子中，而不是从一个长长的散文式的讲述中，他们能够学得更多更快。为了使本书更完整，我还在书中提供了两个参考应用：一个是术语表应用的J2EE版本，它在第一版已经出现过，还有一个是电子零售应用的例子。然而，这个电子零售应用仅仅包括客户端和表示层，因为这是本书的建模工作的焦点所在。 更新原来的针对．NET平台的基于ASP的术语表应用是我的初衷。然而，因为．NET工具和环境的延迟发布，我没有办法开发一个应用，使得它能够准确地适应．NET环境所能提供的所有功能。 本书的结构 本书分为13章和5个附录。从概念上讲，也可以分为两个主要部分。第1章—第5章实质上是对Web应用建模技术和概念的一个介绍。它们为本书第二部分奠定了基础。对于那些已经很熟悉Web应用构架的读者来说，这些章节可以忽略不读。但是，我建议大家至少对这一部分有一个粗略的浏览。 第2章是一个对于很基本的Web应用构架的介绍。这一章定义了一个术语“Web应用”，同时定义了它的范围和焦点。本章同时定义了主要的通信机制和语言，还讨论了支持Web应用的技术。它们是把简单Web站点(Web系统)转变为商业逻辑执行系统的基础设施。 当系统中由客户端执行一些商业逻辑的时候，绝大多数对Web应用的设计工作变得复杂起来。在第3章中讨论了允许其成为可能的技术。在这一章中讨论了普通的Web技术，例如JavaScript、applet和ActiveX控件。作为与客户端资源的主要对象接口，本章还介绍了DOM(Document Object Model，文档对象模型)。 由在第2章和第3章中介绍的技术所描述的基本Web应用构架，能够产生非常有用的Web应用，而且对常见的Internet应用特别有用，例如零售店。对一些应用来说，这些基本成分不足以用来实现所需要的复杂功能。那些限制因素常常是HTTP和HTML自身的基础性技术。除了HTTP和HTML之外，Web应用能够被扩展到容纳和利用其他通信和格式的技术中。在第4章里回顾和探讨了这些技术中最常见的技术。 第一部分的最后一章是第5章。不管一个应用多么地无趣，它的威胁性有多么地低，如果它在Internet上，那么安全性就是该考虑的因素。甚至对于Intranet应用来说，也应该考虑安全性。使得Web应用具有安全性在很多方面比起一个传统的客户端服务器应用要更难。电于它们本身的特性，Web服务器对于网络上的任何节点的请求都是开放的。保证一个应用是安全的诀窍在于对安全性危险自身特性的理解。不幸的是，你所能买到的产品或服务中没有一个能够保证是一个安全的应用。安全性必须在应用中设计，而且它必须在应用中不断地维持下去。新的安全性漏洞在现有软件中不断地被发现。最终，某一个会对你的应用构成威胁。在设计你的系统时牢记这一点，控制下一个将要出现的安全性危险将会更加容易一些。 本书的第二部分讲述构建Web应用的过程。它从第6章开始，回顾了开发面向对象系统的整个过程，还介绍了一个Web应用开发过程的例子。这个过程并不是一个完整的过程，但是它的确提供了足够的细节来确立了一个上下文环境，在这个上下文环境下面，过程中的模型和工件都能够被理解。 第7章讨论了定义Web应用构架的活动。虽然这些活动经常发生在对需求和系统用例的一个近乎于完整的检查之后，但是较早地讨论它可以帮助建立一个开发Web应用的思维模式。因为这里运用到的过程是迭代的和递增的，所以当定义和细化系统用例的时候，用例的说明者必须在他们的心中有一个Web系统的构架。从理论上说，这是不可能的。然而，实际上，在一个递增和迭代的过程里面，把用例放到一个特定构架的上下文环境里面，并不一定是个错误。 第8章回顾了搜集系统需求和定义系统用例的过程。各种各样的需求都可以搜集起来，用于帮助详细说明一个特定的系统。其中搜集功能性需求最有用的技术之一是使用用例。用例提供了一种结构化的方法来搜集和表达一个系统的功能性需求，而且描述了一个系统用户(叫做参与者)和系统的交互。用例是些文本文档，它仅仅在语言的范围内描述了系统应该做什么，而没有详细说明它应该怎么做。至于应该怎么做，是在第9章和第10章讨论的。 第9章介绍了开发过程中的一个新模型——UX(User Experience，用户体验)模型。UX模型描述了用户界面中对于构架具有重要意义的元素。通过建立UX模型，允许把外观问题和工程问题分离开来。本章中，UX模型被描述为在用户体验小组和工程小组之间订立的一个契约。用户体验小组负责设计和构建用户界面视图，而工程小组则负责实现必要的商业逻辑和功能。之所以要在这里介绍UX模型，是因为在我访问过的很多组织当中，对用户体验工件(artifact)进行填充的工作都是在第一批需求集建立之后很快就进行的，也就是差不多在分析者刚刚开始对解决方案进行建模的时候。 大概是在开始调查用户体验的同时，分析小组便开始分析系统的用例和需求说明，并开始以对象的概念来表达它们。这就是第10章的主题。分析是把系统需求转换为能够在软件中实现的设计的活动。正如在用例中所定义的那样，这里创建了一个分析模型，这个分析模型包括了类以及用于展示系统行为的类协作。 第11章和第12章讨论了如何将分析模型转变成可以直接映射到系统组件(实际交付的模块)的东西。第11章对针对UML的Web应用扩展(Web Application Extension，WAE)的主体部分作了介绍。一旦设计模型完成后，它便可以被直接映射为可执行代码。 本书的最后一章，即第13章讨论了从UML模型中生成代码的问题。因为本书的这个版本提供几个参考应用，并对WAE代码映射(附录A)作了详细描述，所以本章仅仅介绍一些实现WAE设计的例子。 附录在这个版本中占据很大篇幅。附录A是针对UML的WAE轮廓的一个概述，是本书中针对UML轮廓介绍的一个快速而又详细的参考。其他的附录是本书中一些应用的实际例子，这些例子已经用WAE轮廓进行过建模。附录B包括一个典型的在线零售店的关键的UML图表。这个应用一部分是用两种构架模式开发的：受控制的控制器(Controlled Controller)和主要模板(Master Template)，它们各自在附录C和附录D中描述。附录E包括第二个参考应用——一个简单的在线术语表。这个术语表应用管理着针对软件开发小组的定义集，演示了如何应用复杂的JavaScfipt对象以及如何对这些JavaScript对象建模。源码可以从www.wae-uml.org下载到，这是我开设的用于支持本书的一个网址。