目录
Web项目解决方案框架
....
1
1
解决方案框架
...
2
2
用例文档
...
2
3
设计数据库
...
2
4
业务逻辑
...
3
5
设计
UI
3
5.1
UI文档描述
...
3
5.2
确定界面布局（
layerout）和风格（style）
...
4
5.3
页面复用技术
...
4
6
设计页面处理组件
...
4
7
设计操作流
...
4
收集基本用例：基本用例即系统功能。每个功能都是独立的或基本独立。这里的独立是指某个功能一旦实现并运作起来，那么就与系统的其它功能耦合系数很低，一般的讲，只有入的关系而无出的关系，那么该功能就可以算是个独立的功能，否则，就是一个功能的子功能而非独立功能，不算基本用例。
每个功能都是一个用例，包含细节和逻辑流程。
一般的讲，大型系统采用
UML UserCase
表达客户需求。
UML
建模
除了
UML
图，还需要文档描述，文档描述建议以下格式：
前置条件：开始使用这个用例之前，必须满足的条件。非必需
主事件流：用例的正常流程。必需
其它事件流：用例的非正常流，如：错误流
后置条件：用例执行结果“必须”为真的条件，也称为“附加条件”，非必需
举例：“安全登入”就是一个用例。
Ø
前置条件：无
Ø
主事件流：用户输入正确的用户名和密码，安全登入到
Web
应用中。向用户返回欢迎页，包括可操作的菜单，提示登陆成功。
Ø
其它事件流
1
：未输入用户名或密码，显示出错信息：用户名或密码不可为空
Ø
其它事件流
2
：用户名和密码不匹配，显示出错信息：用户名或口令错误
Ø
后置条件：该用例不是必须为真，无
数据库设计的最终目标是完整的回答：“数据从何处来，保存在什么地方”。
在这一步，应该给出数据库表的
UML
描述和
XML
文档示例。
UML
描述的文档说明格式建议如下（举例说明）：
/*
设计说明
设计人：
Sun Duction
时间：
2004-12-22
目标数据库：
Oracle 9i
表名：
ADDR_TABLE
*/
|
字段
|
类型
|
说明
|
|
ID
|
Int(4)
|
记录的
ID
，自动增长
|
|
NAME
|
Char(25)
|
姓名
|
|
PHONE
|
Char(10)
|
电话
|
|
ADDRESS
|
Char(50)
|
地址
|
XML
文档示例为：
<?xml version="1.0" encoding="UTF-8"?>
<Table TableName="ADDR_TABLE">
<item ID="1" NAME="
小强
" PHONE="02483992100" ADDRESS="
北京市海淀区
9
号
(110000)"/>
<item ID="2" NAME="
王小花
" PHONE="02483992100" ADDRESS="
北京市海淀区
9
号
(110000)"/>
<item ID="3" NAME="Jim Green" PHONE="02483992100" ADDRESS="
北京市海淀区
9
号
(110000)"/>
</Table>
业务逻辑是独立于系统实现的。采用
JAVA
，还是采用
.NET
，那时实现的体系结构问题。业务逻辑描述系统中各个数据实体之间的关系。
MVC
框架下：
Model
实现业务逻辑。
在
JAVA
中，它们是：
JavaBean
，
EJB
，实用工具类，辅助类。
在
.NET
中，它们是：自定义数据对象，结构，工具类，辅助类。
一般的，在业务层都采用了
DAO
模式，实现的方式有多种。
JAVA
中，比较流行的解决方案是
Hibernate
，
JDO
。
.NET
下，一般采用
Data Access Application Block
。
关于如何根据需求为系统建模，是个专题，这里就不详细描述。
UI
由需求分析而定，但必须独立于业务逻辑的实现，即：
UI
不在意界面上显示的数据从何而来（但必须有一种实现的方式）。设计
UI
时，最终要完成以下任务：确定界面的总体布局和风格、文档描述各个
UI
元素、各个子
UI
元素（可复用元素）之间的关联图。
UI
由用例而来，包括用户界面的功能描述，与用户交互的信息，
UI
切换关系几个要素。
举例：
|
界面
|
字段
|
字段类型
|
说明
|
|
欢迎界面
index
|
无
|
无
|
显示欢迎信息，提供登陆入口
|
|
登入
logon
|
username,password
|
String
|
字段可编辑
|
|
添加记录界面
insert.
|
Name,phone,address
|
String
|
可编辑
|
|
主菜单界面
mainMenu
|
无
|
无
|
提供所有操作菜单
|
|
添加数据确认
confirm
|
无
|
无
|
向用户显示添加成功或失败信息。
|
由美工确定符合该项目的总体页面布局和配色方案，给出基础
CSS
文件。
如果采用
.NET
技术，那么建议采用模版页＋自定义控件的方式，动态载入生成
HTML
页面。
如果采用
JSP
技术，那么，可以使用
Tiles
框架。
其实，两个体系的解决方案在内部实现上，几乎是相同的，只不过
JAVA
领域成熟的开源框架多的多而已。
这一步应该确定页面关联，即每个功能页面与其它片断页面的关系。这是为了达到页面级别的最大程度复用而做的。这是值得的，因为这一步做的好，会大大缩短开发，测试的时间。
对于
JSP
项目，建议将申明标签库的语句方在一个文件中，如
taglibs.jsp
，其它文件引用它，并对特定应用使用定制标签。
对于
Struts
而言，每个页面对应一个
ActionForm
，对于
ASP.NET
而言，每个页面关联一个代码隐藏类。由于
ASP.NET
技术，微软的
IDE
给予的大量的自动化支持，且
ASP.NET
运行库给予了大量的底层支持，天生的支持
MVC
框架。这里就不详细描述如何实现
ASP.NET
的代码隐藏类。
ActionForm Bean
用于在视图组件和控制器组件之间传递
HTML Form
数据。通常，每个
HTML Form
对应一个
ActionForm Bean
，
HTML Form
中的字段和
ActionForm Bean
中的属性一一对应。
对于
Struts
应用，请采用如下表格：
|
ActionForm
名
|
属性
|
Validate
方法
|
|
LogonForm
|
username,password
|
二者不可为空
|
|
InsertForm
|
Name,phone,address
|
三者不可为空
|
注意，这里要保证
validate
方法不访问
Model
层，即：它不执行业务逻辑验证。比如，口令不匹配这个逻辑所代表的代码决不可以放在该方法中。
在需求阶段确定了事件的流，为了实现这个流控制，需要在各个页面之间切换。对于
ASP.NET
，由于代码隐藏类给予了对页面和逻辑完全的控制，并提供了类似于面向对象的编程方法，故界面切换直接根据业务的事件流处理即可。
如何在.NET下将控制流在外配置，有什么好的解决方案，希望大家讨论啊！
对于
Struts
应用，这是由
Action
和
struts-config.xm
文件联合完成。所以必须在这一步就确定好
Action
和
Action
之间的映射关系。
Action
负责单个事件的流程控制。那么，一个事件，就必然对应一个
Action
。
Action
映射决定了
Action
与其它
Web
组件之间的关联。在实际应用中，最好提供下表：
|
Action
|
入口
|
Action Form
|
出口
|
|
LogonAction
|
Logon.jsp
|
LogonForm
|
mainMenu.jsp
|
|
LogoffAction
|
mainMenu.jsp
|
无
|
Index.jsp
|
|
InsertAction
|
Insert.jsp
|
InsertForm
|
Confirm.jsp
|
|
DisplayAllAction
|
mainMenu.jsp
|
无
|
Display.jsp
|
该表如果使用图的方式给出，将更加完美。