用UML构建Web应用（第二版）
点击看大图基本信息
- 作者： （美）Jim Conallen [作译者介绍]
- 译者： 陈起 英宇
- 丛书名： 软件工程系列
- 出版社：中国电力出版社
- ISBN：750831557X
- 上架时间：2003-11-12
- 出版日期：2003 年11月
- 开本：16开
- 页码：329
- 版次：2-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 综合
内容简介回到顶部↑
健壮的、可升级的和功能丰富的web应用是可以获得的。使用业内标准uml（unified modeling language）进行设计可以使得web应用开发人员方便地将设计和其他用uml建模的系统进行整合。
[b]本书是享有广泛赞誉的《building web application with uml》的新版本。[/b]基于作者作为web开发人员所总结的广泛经验，本书结合了有用的读者反馈，指出并阐述了基于页面的web应用所特有的建模问题，并且提供了实用的建议和简单明了的解决方案。本书包括经过更新、扩展的例子和图；更全面地阐述了最新的有关web应用安全性的内容；详细地阐述了应用到web应用开发中已验证的对象技术概念。
[b]jim conallen[/b]是rational development accelerators小组的成员。他的研究范围包括：web应用建模、可重用部件的开发以及基于模型的软件开发工具和过程.
作译者回到顶部↑
本书提供作译者介绍
Jim Conallen是Rational Development Accelerators小组的成员。他的研究范围包括：Web应用建模、可重用部件的开发以及基于模型的软件开发工具和过程。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
第一部分 建模和与web相关的技术概述
第1章 绪论
1.1 本书内容
1.2 建模的角色
1.3 过程的角色
1.4 够架的影响
第2章 web应用基础
2.1 http
2.2 html
3.3 web应用
第三章 动态壳户端
3.1 文档对象模型
3.2 脚本
3.3 javascript 对象
第1章 绪论
1.1 本书内容
1.2 建模的角色
1.3 过程的角色
1.4 够架的影响
第2章 web应用基础
2.1 http
2.2 html
3.3 web应用
第三章 动态壳户端
3.1 文档对象模型
3.2 脚本
3.3 javascript 对象
前言回到顶部↑
本书的第一版是在1999年末面市的。在很大程度上，它是基于我为零售行业和卫生部门开发基于ASP的应用的一些经验而写成的。我那时候已经是一个独立的顾问了，但是在完成那本书之前不久，我加入了Rational软件公司。在Rational公司工作，使得我有机会去访问一些机构并且与他们进行合作，那些机构正从事于构建以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和Gerald Ruldolph，他们都是经验丰富的对象
实践者。他们的直接反应是：为什么?我努力去解释那些牵涉到Web应用开发的论点，以及那种对于在视觉上真实地表达他们的设计的需求。然而，所有听到我陈述的人都仍然认为开发一个新的方法和理念对于原来的方法和理念有点矫枉过正了。
我开始重新思考我所从事的这项工作。我并没有太多地为自己辩护，认为我是对的，而其他人都是错的。还有更多的准备工作等着我去做。我重新审视了一下我的原始需求：为了用一个对于抽象和具体程度恰到好处的标准来表达Web应用的设计，而且更重要的是，这个标准要作为这个系统其余部分设计的一个部分。因为UML正在企业中运用得如火如荼，我意识到我做的任何工作都不能离开UML。
于是，我重新转向了UML。这时候它已经是0．91版本了，而且，一个新的概念被包括进来了——构造型(stereotype)。开始，我并不懂什么是构造型。毕竟，UML规范并不是很轻易就能读懂的。它又长又难，但是我知道，在对Web应用建模的领域，任何成功必须是从这个方向开始的。最终，我开始明白了构造型和其他的扩展机制：标记值(tagged value)和约束(constraints)的含义是什么。我终于开始看到黑暗隧道尽头的一线光明。
现在我有了一个机制，利用它我可以介绍新的语义到UML语法里面，而不会对原有的语义有所影响。我一直明白，关键是要提供一个一致且连贯的思路，以一种正确的抽象标准，同系统的其他部分的模型一起，去对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页面、页面之间的关系、导航路径、客户端脚本以及服务器端页面生成)进行建模。
从第一版的公开出版到现在的两年时间里，我也已经感受到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和Gerald Ruldolph，他们都是经验丰富的对象
实践者。他们的直接反应是：为什么?我努力去解释那些牵涉到Web应用开发的论点，以及那种对于在视觉上真实地表达他们的设计的需求。然而，所有听到我陈述的人都仍然认为开发一个新的方法和理念对于原来的方法和理念有点矫枉过正了。
我开始重新思考我所从事的这项工作。我并没有太多地为自己辩护，认为我是对的，而其他人都是错的。还有更多的准备工作等着我去做。我重新审视了一下我的原始需求：为了用一个对于抽象和具体程度恰到好处的标准来表达Web应用的设计，而且更重要的是，这个标准要作为这个系统其余部分设计的一个部分。因为UML正在企业中运用得如火如荼，我意识到我做的任何工作都不能离开UML。
于是，我重新转向了UML。这时候它已经是0．91版本了，而且，一个新的概念被包括进来了——构造型(stereotype)。开始，我并不懂什么是构造型。毕竟，UML规范并不是很轻易就能读懂的。它又长又难，但是我知道，在对Web应用建模的领域，任何成功必须是从这个方向开始的。最终，我开始明白了构造型和其他的扩展机制：标记值(tagged value)和约束(constraints)的含义是什么。我终于开始看到黑暗隧道尽头的一线光明。
现在我有了一个机制，利用它我可以介绍新的语义到UML语法里面，而不会对原有的语义有所影响。我一直明白，关键是要提供一个一致且连贯的思路，以一种正确的抽象标准，同系统的其他部分的模型一起，去对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页面、页面之间的关系、导航路径、客户端脚本以及服务器端页面生成)进行建模。
序言回到顶部↑
在最近和Java的主要发明者James Gosling的一次会晤中，他谈到了开发一个复杂的软件密集型系统(Software-intensive system)所面临的挑战，并指出“当你手头拥有软件的许多片段时，绝大多数工具只把那些单独的代码行看作文本。如果不是只看到软件的一些单独的片段，而是看到整个的系统，那么常常就会很有用处。”接下来他还解释了他“为什么不像通常那样用文本的格式编辑代码，而是致力于寻找一种以可视化模型的方式编辑代码的方法。”’
整个软件工程的发展历史是以抽象水平的不断提高为标志的，这一点也很明显地体现在我们的编程语言、平台和方法当中。抽象是很重要的，因为这是一种人们用以把握复杂世界的基本手段。软件的图形建模仅仅是又一种更高程度的抽象而已，它使得开发人员可以可视化地研究系统、定义系统、建立系统的结构，为系统建立文档，还可以对系统进行推理研究。
以Web为中心的可视化建模系统确切地说是Jim Conallen工业做出的一个贡献。我第一次知晓Jim的工作是在1998年，那时他发表了一篇关于这一主题的早期论文。在那之前，那个最终导致UML的出现的统一化尝试正在进行之中，而对我们来说，能够对以Web为中心的系统进行建模是一个明确的目标。我们具有了对这类系统建模所必需的一些基本要素，但是Jim把一个解决建模问题的方法展现在了我们面前，那就是建立在UML扩展机制的基础之上。
这些年关注Jim的工作取得进展直至成熟是一件令人高兴的事情。将他的方法融入到一个商业建模工具，加上Jim本人对于各种有趣的以Web为中心的系统的涉猎，已经带领我们所有人去发现一些我们未知的事情。这一点，再加上平台(例如J2EE)的优势，已经使得Jim的建模工作更加切题。
正因为如此，我很高兴有这个机会来介绍Jim的《Building Web Applications with UML》这本书的第二版。从第一版开始，Web开发领域已经在某些微小的方面有所变化，主要标志是我们更深入地理解了一个声称是以Web为中心的体系结构看起来应该是什么样子，以及引导我们实现那个体系结构所要经历的开发过程。这两种变化都在本书的新版本中有所反映：Jim谈到了在J2EE领域很多最新的发展状况，也介绍了关于Rational Unified Process的一些工作，这项工作主要是针对Web的。
在过去的几年里和Jim在一起工作真是一种乐趣。他是一个老练的建模者和设计师，而且更难得的是，他是一个善于表达的人，既掌握了技术的精髓，又能把他所知道的东西以一种近乎通俗的方式传递出来。
我想你会真正喜欢上本书的，当然我也会。
Rational软件公司
首席科学家
Grady Booch
整个软件工程的发展历史是以抽象水平的不断提高为标志的，这一点也很明显地体现在我们的编程语言、平台和方法当中。抽象是很重要的，因为这是一种人们用以把握复杂世界的基本手段。软件的图形建模仅仅是又一种更高程度的抽象而已，它使得开发人员可以可视化地研究系统、定义系统、建立系统的结构，为系统建立文档，还可以对系统进行推理研究。
以Web为中心的可视化建模系统确切地说是Jim Conallen工业做出的一个贡献。我第一次知晓Jim的工作是在1998年，那时他发表了一篇关于这一主题的早期论文。在那之前，那个最终导致UML的出现的统一化尝试正在进行之中，而对我们来说，能够对以Web为中心的系统进行建模是一个明确的目标。我们具有了对这类系统建模所必需的一些基本要素，但是Jim把一个解决建模问题的方法展现在了我们面前，那就是建立在UML扩展机制的基础之上。
这些年关注Jim的工作取得进展直至成熟是一件令人高兴的事情。将他的方法融入到一个商业建模工具，加上Jim本人对于各种有趣的以Web为中心的系统的涉猎，已经带领我们所有人去发现一些我们未知的事情。这一点，再加上平台(例如J2EE)的优势，已经使得Jim的建模工作更加切题。
正因为如此，我很高兴有这个机会来介绍Jim的《Building Web Applications with UML》这本书的第二版。从第一版开始，Web开发领域已经在某些微小的方面有所变化，主要标志是我们更深入地理解了一个声称是以Web为中心的体系结构看起来应该是什么样子，以及引导我们实现那个体系结构所要经历的开发过程。这两种变化都在本书的新版本中有所反映：Jim谈到了在J2EE领域很多最新的发展状况，也介绍了关于Rational Unified Process的一些工作，这项工作主要是针对Web的。
在过去的几年里和Jim在一起工作真是一种乐趣。他是一个老练的建模者和设计师，而且更难得的是，他是一个善于表达的人，既掌握了技术的精髓，又能把他所知道的东西以一种近乎通俗的方式传递出来。
我想你会真正喜欢上本书的，当然我也会。
Rational软件公司
首席科学家
Grady Booch
)
加载中...
