第3章struts应用的需求分析与设计概要.docx

第 3 章 Struts 应用的需求分析与设计 软件开发过程通常包括五个阶段：分析、设计、编码、测试和发布。如果在 Web 应用 开发中套用现成的 Struts 框架，则可以简化每个开发阶段的工作，开发人员可以更加有针 对性地去分析应用需求， 不必重新设计框架， 而只需在 Struts 框架的基础上， 设计 MVC 各 个模块包含的具体组件。在编码过程中，可以充分利用 Struts 提供的各种实用类和标签库， 简化编码工作。 本章以电子通讯簿 addressbook应用为例，讲述了对Struts应用进行需求分析和设计的 方法，它包括以下步骤： 收集和分析应用需求 设计数据库 设计客户界面 设计 ActionForm 设计 Action 设计应用的业务逻辑组件 尽管在 Web 应用的设计阶段不涉及编码，但本章为便于讲解设计思路，提供了某些组 件的代码实现 。 本章样例位于配套光盘的 sourcecode/addressbook/version1 目录下，发布和运行步骤参 见本书附录 C。 3.1 收集和分析应用需求 软件开发过程的起点是获得对客户业务过程的理解，分析员在和具有业务知识的客户 交谈中，可以发现需求，了解系统功能，然后用 UML用例（UseCase）来描述这些需求。 下面分析电子通讯簿 addressbook应用的需求。当用户登入到这个应用中后， 将执行添 加或查询好朋友联系地址等操作。这个应用包含以下用例： 安全登入 添加好朋友联系地址 根据特定条件查询好朋友联系地址 列出所有好朋友联系地址清单 安全登出 接下来展开每个用例的细节和逻辑流程，以文档的形式来描述用例。用例文档中应包 含以下内容： 前置条件：开始使用这个用例之前必须满足的条件。 主事件流：用例的正常流程。 精通Struts :基于 MVC的Java Web设计与开发 其他事件流：用例的非正常流程，如错误流。 后置条件：用例的执行结果必须为真的条件，并不是每个用例都有后置条件。 F面分析addressbook应用中每个用例的细节。 用例1 ：安全登入 前置条件：无。 主事件流：用户输入正确的用户名和密码，安全登入到应用中，向用户返回 主操作菜单。 其他事件流A1 :如果用户未输入用户名或密码，则显示错误提示信息：用户 名和密码不允许为空。 其他事件流A2 :如果用户输入非法的用户名或密码，则显示错误提示信息： 用户名或密码不正确。 用例2 :添加好朋友联系地址 前置条件：用户已经安全登入到应用中。 主事件流：接收用户输入的好朋友联系地址信息（姓名、电话和地址） ，把信 息保存到数据库中，返回提示信息：记录已经被成功保存到数据库。 其他事件流A1 :如果用户未输入姓名、电话或地址，则显示错误提示信息： 姓名、电话或地址不允许为空。 用例3:根据特定条件查询好朋友联系地址 前置条件：用户已经安全登入到应用中。 主事件流：用户输入模糊查询条件（如姓名、电话和地址信息） ，返回符合查 询条件的所有记录 其他事件流A1 :如果用户没有输入任何查询条件，则显示错误提示信息：必 须至少提供一个查询条件。 用例4 :列出所有好朋友联系地址清单 前置条件：用户已经安全登入到应用中。 主事件流：返回所有的通信地址信息。 用例5:安全登出 前置条件：用户已经安全登入到应用中。 主事件流：结束当前 HTTP会话，重新返回到 Welcome页面。 3.2设计数据库 接下来分析应用中的数据流 数据从何而来，保存在什么地方。对于 addressbook 应用，用户输入好朋友联系地址信息，包括姓名、电话号码和通信地址，服务器端把这些 信息保存在数据库中。因此，可以在数据库中创建一张表： ADDRESSBOOK_TABLE ，来 存放以上信息。表 ADDRESSBOOK_TABLE 的结构如表3-1所示。 Sun ONE 表 3-1 ADDRESSBOOK_TABLE 表的结构 字 段 类 型 说 明 ID int (4) 记录ID，能自动增长，为主键 NAME char (25) 朋友姓名 PHONE char (10) 电话号码 ADDRESS char (50) 地址 addressbook应用的用例1提供了验证用户身份的功能。可以把所有合法用户信息（用 户名和密码）也保存在数据库中。不过，在本例中为了演示解析 XML数据的方法，把用 户信息保存在 XML文件userdatabase.xml中。假定本应用的初始合法用户为 guest,密 码为guest,在userdatabase.xml文件中包含如下初始数据： database user userName=guest password=guest v/user v/database 3.3设计应用的业务逻辑 JavaBean E