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/区域中的文件。
用户界面布局图能够帮助你避免网站混乱，它对于规划网站是很有用的。而且，一旦确定了一种有效的网站结构组织方式，它还可以作为一个固定的模式在多个网站上应用。
