一、概述
Web网站往往具有复杂与高度动态的特点。为了让Web使用在短时间之内开始运作，开发周期应该尽量地短。许多时候，开发者直接进入编写代码这一阶段，却不去细心考虑本人想要结构的是什么样的网站以及预备如何结构：服务器端代码往往是毫无预备的即兴式编写，数据库表也是随需随加，整个使用的体系有时候呈现一种无规划形状。然而，只需我们运用一些建模技术和软件工程技术，就能够让开发过程愈加流畅，确保Web使用将来更容易维护。

UML（Unified Modeling Language，统一建模言语）是一种通用的可视化建模言语，用于对软件进行描述、可视化处理、结构和建立软件系统的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种使用领域以及各种开发工具。UML能够描述系统的静态结构和动态行为：静态结构定义了系统中重要对象的属性和操作以及这些对象之间的互相关系；动态行为定义了对象的时间特性和对象为完成目标任务而互相进行通信的机制。UML不是一种程序设计言语，但我们可以用代码生成器将UML模型转换为多种程序设计言语代码，或使用反向生成器工具将程序源代码转换为UML模型。

本文引见用UML为Web网站建模的一些方法。全面采用UML技术是一个复杂的过程，但UML的某些部分很容易使用，而且它能够协助你用更少的时间结构出更好的系统。

为了示范UML在网站建设中的使用，本文将结构一个支持无线用户、提供各个地区天气报表和交通流量报表的网站。本文不预备详细引见UML本身。但为了方便起见，附录中简要引见了常见的UML符号和术语。要了解更多有关UML的信息，请参见文章最后的参考资源。

二、规划阶段
不论你是从头开始结构网站、移植网站还是添加某个重要的功用，为了确保设计决策的最优化，进行一些先期规划是必要的。如果你和其他人协作完成一项工程，就任务总量及其分配达成明确的共识具有不可估量的作用。在规划期间，你应该努力对系统的以下方面构成正确的认识：

用户和角色。
使用需求。
各个界面之间的转换流程。
要用到的工具和技术。

2.1 用户
了解使用系统的用户是很重要的。不只系统分析要求你接触一些用户（通过问卷调查、email，或者面对面交谈），而且你经常还要让系统能够控制不同的用户角色和权限。通过对用户进行分类并了解他们的需求，你就可以找出线索来确定数据库的安全机制、功用限制方法、用户界面分组、培训和协助需求、对具体内容的需求，甚至还可以从侧面了解到潜在广告客户的分布。

图1：参与者/角色 层次图

上图显示了几组不同的网站用户（在UML中称为Actor，即参与者）。在这里，最普通的用户类型（“Site User”）位于图的顶端，实线箭头表示generalization关系（“泛化”关系，参见本文附录说明，下同），它表示Site User又可以具体分成两类用户：Guest，Registered User。这两类用户共有的特征在“Site User”参与者中说明，而Guest和Registered User各无私有的特征则在对应的参与者中说明。通常，你可以直接为参与者加上说明文档，无需单独编写说明用户的文档，但具体与你所用的UML工具有关。在本例中，Registered User又可以细分为Wireless User和Administrator两品种型，系统对这些用户的处理方式应有所不同。

2.2 定义需求
在正式开始编写代码之前，你应该对预备结构一个怎样的系统有一个清晰的认识。虽然在编写代码的同时也可以逐渐完成这一任务，而且这种做法也很有吸引力，但借助图形和文字材料事先集体进行讨论效率要高得多。为网站编写详细的需求说明往往不那么合算，但你应该有时间画出几个草图、写下几段注解去说明网站预备提供的服务。这就要用到Use Case图（用例图）。Use Case可以看成一组功用——它可能对应网站上的一个页面、一个必须编写的程序，或者网站上可能发生的一个动作（比如，验证用户登录，改变用户的配置文件，清除过期的帐号，等等）。下面就是一个能够协助你规划网站的Use Case图。留意，该图并没有显示出网站的所有Use Case，通常我们需求多个Use Case图才能描述完整的网站功用。

图2：Use Case图

即便是在这样一个简单的Use Case图中，我们也能够轻松地表达出大量的信息。例如，include关系说明两个Use Case包含同样的身份验证功用；extend关系说明天气页面可能以WML或者HTML格式显示；generalization关系说明各个具体的表现过程将服从“Render HTML Page”或者“Render WML Page”所描述的基本行为规则以达到维持统一的风格效果和统一宏观行为模式的目的。

上图也显示出无线用户能够访问网站中其他用户不能访问的某些区域。在这个Use Case图中，只要无线用户能够访问交通流量报表。这是由于我们曾经得知只要在旅途中的挪动用户才需求交通流量报表，而且不想再花时间把交通流量报表制形成其他标记言语方式。由此，“Get Traffic Report”Use Case不需求分成WML和HTML两种显示方式，它可以直接包含“Render WML Traffic Report”这个Use Case。

普通地，你应该为这些Use Case加上简单的说明。具体地说，你应该描述每一个Use Case里将要发生什么，谁可以使用它，它如何启动、如何停止，以及某些时候可能发生的特殊事件（称为variation，即变化）。

2.3 用户界面组织
在制造Use Case的过程中，你会得到一些指示网站需求哪些用户界面的线索。也许你早就有了设计某些页面的绝妙主意，但Use Case协助我们从另外一个角度来看问题。用户能否确实需求那么多的界面？某个页面能否过于复杂？网站的导航设备能否简单易用，即从主页访问常用服务能否很方便？在勾勒界面草图、制造网站原型之前，你应该先在Use Case图中处理这些问题。

当Use Case逐渐清晰时，我们就可以开始勾勒出网站的大致结构。有些人会强调说页面和文件应该用相应的构件图（Component Diagram）建模，其实类图（Class Diagram）工具也很方便。请参见下图：

图3：用户界面及其规划

在上图中，各种网站服务被捆绑到了不同的网站区域：

/ - 网站的根
/common/ - 公用的图形、脚本、CSS文件等
/maps/ - 地图数据
/traffic/ - 交通流量报表
/weather/ - 天气报表

该图还显示了在页面之间传递的参数。regionId是一个很重要的参数，它代表着用户感兴味的地区（可能是一个国家、城市或者省份）。regionId在页面之间传递地区信息，使得用户能够从指定地区的天气报表跳转到交通流量信息。至于网站的common区域，你可以看到指针指向的是整个包（package）而不是区域中的单个文件，这是一种减少混乱的简化方法，由于所有其它的包都要用到大部分（如果不是全部的话）/common/区域中的文件。

用户界面规划图能够协助你避免网站混乱，它对于规划网站是很有用的。而且，一旦确定了一种无效的网站结构组织方式，它还可以作为一个固定的模式在多个网站上使用。

2.4 工具选择
对于小型网站，选择工具和技术相当简单。特别是由于投资的缘由，只要少数几种工具组合才具有理想意义——Apache，MySQL或者PostgreSQL，PHP、Perl或JSP/Servlet。当前最流行的组合是Apache + PHP + MySQL，有许多低价位的Web托管服务支持并次要集中在这种工具组合上。而对于规模较大的网站，在投资使用软件之前，它必须对各种工具进行更严厉的评估和测试。下面是一个构件图的例子，它可以用来说明网站的体系结构。这个图形虽然简单，但它曾经描述出了当前大多数网站的体系结构，对于你的网站，重新制造该图可能也没有必要，由于再也没有什么异乎寻常的内容值得加入这个图形了。

图4：网站体系结构图

讨论软件的整个生命周期曾经超出了本文的范围，但应该指出的是，建立使用原型和界面模型应该在这个时候就开始。务必记下有关网站结构和页面规划的一些想法，由于最终你会想要为规划（菜单，导航条，页面全体规划等）编写一些公用的代码。另外，如果你正在转到新的工具和技术，建立原型的任务能够让你确保设计的可行性，确信曾经就新工具的使用对开发组成员进行了足够的培训。

三、设计阶段
设计阶段应该与分析阶段交迭。一旦对本人所要结构的系统有了较多的认识，你就应该开始拟定设计思路。先100%地分析系统再进入设计阶段是没有意义的。需求总是不断地发展，而设计本身有时也会推动需求的发展（反之亦然）。所有的开发者都在进行某品种型的设计——只不过有些开发者直接以编程代码的方式进行设计。虽然这也能够完成任务，但它使得管理复杂工程和在任务组之内分配任务变得非常困难。先花一点时间通过设计图结构系统模型，当前你