1.0版本
目录
5.2 确定界面布局（layerout）和风格（style）
1 解决方案框架
|
设计页面对象组件ActionForm |
|
设计操作流 |
|
设计业务逻辑组件组件 |
|
收集和分析应用需求 |
|
设计数据库 |
|
设计客户UI |
收集基本用例：基本用例即系统功能。每个功能都是独立的或基本独立。这里的独立是指某个功能一旦实现并运作起来，那么就与系统的其它功能耦合系数很低，一般的讲，只有入的关系而无出的关系，那么该功能就可以算是个独立的功能，否则，就是一个功能的子功能而非独立功能，不算基本用例。
每个功能都是一个用例，包含细节和逻辑流程。
2 用例文档
一般的讲，大型系统采用UML UserCase表达客户需求。UML建模
除了UML图，还需要文档描述，文档描述建议以下格式：
前置条件：开始使用这个用例之前，必须满足的条件。非必需
主事件流：用例的正常流程。必需
其它事件流：用例的非正常流，如：错误流
后置条件：用例执行结果“必须”为真的条件，也称为“附加条件”，非必需
举例：“安全登入”就是一个用例。
Ø 前置条件：无
Ø 主事件流：用户输入正确的用户名和密码，安全登入到Web应用中。向用户返回欢迎页，包括可操作的菜单，提示登陆成功。
Ø 其它事件流1：未输入用户名或密码，显示出错信息：用户名或密码不可为空
Ø 其它事件流2：用户名和密码不匹配，显示出错信息：用户名或口令错误
Ø 后置条件：该用例不是必须为真，无
3 设计数据库
数据库设计的最终目标是完整的回答：“数据从何处来，保存在什么地方”。
在这一步，应该给出数据库表的UML描述和XML文档示例。UML描述的文档说明格式建议如下（举例说明）：
/*
设计说明
设计人：Sun Duction
时间：
目标数据库：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>
4 业务逻辑
业务逻辑是独立于系统实现的。采用JAVA，还是采用.NET，那时实现的体系结构问题。业务逻辑描述系统中各个数据实体之间的关系。
MVC框架下：Model实现业务逻辑。
在JAVA中，它们是：JavaBean，EJB，实用工具类，辅助类。
在.NET中，它们是：自定义数据对象，结构，工具类，辅助类。
一般的，在业务层都采用了DAO模式，实现的方式有多种。JAVA中，比较流行的解决方案是Hibernate，JDO。
.NET下，一般采用Data Access Application Block。
关于如何根据需求为系统建模，是个专题，这里就不详细描述。
5 设计UI
UI由需求分析而定，但必须独立于业务逻辑的实现，即：UI不在意界面上显示的数据从何而来（但必须有一种实现的方式）。设计UI时，最终要完成以下任务：确定界面的总体布局和风格、文档描述各个UI元素、各个子UI元素（可复用元素）之间的关联图。
5.1 UI文档描述
UI由用例而来，包括用户界面的功能描述，与用户交互的信息，UI切换关系几个要素。
举例：
|
界面 |
字段 |
字段类型 |
说明 |
|
欢迎界面index |
无 |
无 |
显示欢迎信息，提供登陆入口 |
|
登入logon |
username,password |
String |
字段可编辑 |
|
添加记录界面insert. |
Name,phone,address |
String |
可编辑 |
|
主菜单界面mainMenu |
无 |
无 |
提供所有操作菜单 |
|
添加数据确认confirm |
无 |
无 |
向用户显示添加成功或失败信息。 |
5.2 确定界面布局（layerout）和风格（style）
由美工确定符合该项目的总体页面布局和配色方案，给出基础CSS文件。
5.3 页面复用技术
如果采用.NET技术，那么建议采用模版页＋自定义控件的方式，动态载入生成HTML页面。
如果采用JSP技术，那么，可以使用Tiles框架。
其实，两个体系的解决方案在内部实现上，几乎是相同的，只不过JAVA领域成熟的开源框架多的多而已。
这一步应该确定页面关联，即每个功能页面与其它片断页面的关系。这是为了达到页面级别的最大程度复用而做的。这是值得的，因为这一步做的好，会大大缩短开发，测试的时间。
对于JSP项目，建议将申明标签库的语句方在一个文件中，如taglibs.jsp，其它文件引用它，并对特定应用使用定制标签。
6 设计页面处理组件
对于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层，即：它不执行业务逻辑验证。比如，口令不匹配这个逻辑所代表的代码决不可以放在该方法中。
7 设计操作流
在需求阶段确定了事件的流，为了实现这个流控制，需要在各个页面之间切换。对于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 |
该表如果使用图的方式给出，将更加完美。
