[转]UML辅助网站规划和设计指南一
一、概述
Web
UML(Unified Modeling Language,统一建模语言)是一种通用的可视化建模语言,用于对
本文介绍用UML为Web网站建模的一些方法。全面采用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 定义需求
在正式开始编写代码之前,你应该对准备构造一个怎样的系统有一个清晰的认识。虽然在编写代码的同时也可以逐步完成这一工作,而且这种做法也很有吸引力,但借助图形和文字资料事先集体进行讨论效率要高得多。为
图2:Use Case图
即使是在这样一个
上图也显示出无线用户能够访问网站中其他用户不能访问的某些区域。在这个Use Case图中,只有无线用户能够访问
一般地,你应该为这些Use Case加上简单的说明。具体地说,你应该描述每一个Use Case里将要发生什么,谁可以使用它,它如何启动、如何停止,以及某些时候可能发生的特殊事件(称为variation,即变化)。
2.3 用户界面组织
在制作Use Case的过程中,你会得到一些指示网站需要哪些用户界面的线索。也许你早就有了
当Use Case逐渐清晰时,我们就可以开始勾画出网站的大致结构。有些人会强调说页面和文件应该用相应的构件图(Component Diagram)建模,其实类图(Class Diagram)工具也很方便。请参见下图:
图3:用户界面及其布局
在上图中,各种网站
- / - 网站的根
- /common/ - 公用的图形、脚本、CSS文件等
- /maps/ - 地图数据
- /traffic/ - 交通流量报表
- /weather/ - 天气报表
该图还显示了在页面之间传递的参数。regionId是一个很重要的参数,它代表着用户感兴趣的地区(可能是一个国家、城市或者省份)。regionId在页面之间传递地区
用户界面布局图能够帮助你避免网站混乱,它对于规划网站是很有用的。而且,一旦确定了一种有效的网站结构组织方式,它还可以作为一个固定的模式在多个网站上应用。
2.4 工具选择
对于小型
图4:网站体系结构图
讨论软件的整个生命周期已经超出了本文的范围,但应该指出的是,建立应用原型和界面模型应该在这个时候就开始。务必记下有关网站结构和页面布局的一些想法,因为最终你会想要为布局(菜单,导航条,页面整体布局等)编写一些公用的代码。另外,如果你正在转到新的工具和技术,建立原型的工作能够让你确保设计的可行性,确信已经就新工具的使用对开发组成员进行了足够的
三、设计阶段
3.1 为未来而设计
许多开发者花费在代码调试和改写上的时间超过了编写代码的时间,如果从一个以上网站的建设来看这个问题,情况就尤其严重了。好的网站设计能够以结构、组织方式和代码重用的形式应用到多个网站上。然而,如果代码只是匆匆忙忙堆砌而成,从现有代码长期获益的机会就减少了。要对网站进行设计
图5:类图
说明如下:
- Renderer类是一个抽象类(用斜体字显示)。这意味着Renderer类不能直接使用,程序只能创建其子类的实例(即new Region())。为了满足把页面内容显示到不同类型浏览器的需要,所有用来生成内容的页面都必须从Renderer类派生。
- WeatherReport类创建并拥有Region对象,这通过代表聚合关系(Aggregate Relationship)的黑色菱形显示出来,它表示一个对象拥有并创建其他对象。
- 方法名字前面的加号(“+”)表示该方法是公用方法,可以被其他对象或者函数调用;减号(“-”)表示方法或者变量是私有的,只能由同一对象内部的成员函数访问。在PHP中方法和变量是公用的,但我们应该总是把变量看成私有,避免从对象外部直接访问变量。
- HTMLWeatherReport类依赖于HTMLUtils类。依赖关系(dependency)表示一个类要创建另一个类的实例或者调用另一个类的方法。
- 类图中的每一个类应该注明:所有的方法(以及所有的变量,如有的话),方法的访问属性(public,private或者protected),方法的返回值类型,方法的参数,变量的类型。函数写在前面,如果类有变量的话,则一般随后在一个分开的方框中列出。
即使你所构造的不是一个面向对象的
3.2 运行时的系统模型
有些时候,我们需要显示出应用的各个部件如何在运行时协作完成任务。前面的类图显示了类之间的关系,但它没有显示出调用出现的次序,也没有显示出来自一个函数的结果可能决定下一次调用的目标。为了在更动态的层面上描述系统,UML提供了许多其他类型的图。对于Web网站设计来说,情节图(Scenario Diagram)特别有用。情节图分成两种:协作图(Collaboration Diagram),序列图(Sequence Diagram)。一般地,我们不会建立系统所有交互过程的
协作图和序列图分别举例如下。
图6:协作图
上面的协作图显示了从Web网站获取天气报表的一般过程。注意该图忽略了一些不重要的方法,因为我们只对处理过程中的关键步骤感兴趣。你可以根据编号“1”到“1.3.3.4”找出各个函数的执行次序。一些人喜欢以“1,2,3,……”形式对执行步骤编号,但一般而言,用“1,1.1,1.2,2,2.1,……”的形式显示出调用栈的深度是一种更好的选择,这种编号方式能够更清楚地显示出程序的控制转换过程。例如,上图显示出report()方法调用了WMLUtil以及Region对象中的许多方法:在通过一系列的查询和内容生成函数为指定地区生成报表之前,我们调用了WMLUtil中的buildHeader(…)函数;最后我们调用的是WMLUtil模块的buildFooter(…),然后返回report()方法,最后返回getPage()。你可以为协作图加上更多的细节说明,比如返回值、约束、条件等。
图7:序列图
就图形所传达的信息而言,次序图和协作图非常相似。事实上,许多UML建模工具能够从协作图生成次序图,或者相反。次序图与协作图的主要不同之处在于:在次序图上,事件的发生次序一目了然,非常直观。另外,次序图中还可以加入生存周期和时间方面的详细信息,比如延迟、线程并发、对象的构造和删除等。
在决定选用次序图还是协作图的时候,考虑以下几点有助于你作出最合适的选择:
- 如果要显示代码中与时间或线程密切相关的问题,选择次序图。
- 如果要显示对象之间的交互模式,选择协作图。
- 如果要显示几个或者大量对象之间的交互过程,选择次序图。
- 如果要显示少量对象之间的大量消息传递或交互过程,选择协作图。
]]>