BlogJava-心无痕的博客http://www.blogjava.net/xinwuhen/zh-cnWed, 08 Oct 2008 01:10:09 GMTWed, 08 Oct 2008 01:10:09 GMT60深入Struts 1.1----转自IBM DeveloperWorkshttp://www.blogjava.net/xinwuhen/archive/2008/07/01/212013.html心无痕心无痕Tue, 01 Jul 2008 14:10:00 GMThttp://www.blogjava.net/xinwuhen/archive/2008/07/01/212013.htmlhttp://www.blogjava.net/xinwuhen/comments/212013.htmlhttp://www.blogjava.net/xinwuhen/archive/2008/07/01/212013.html#Feedback0http://www.blogjava.net/xinwuhen/comments/commentRss/212013.htmlhttp://www.blogjava.net/xinwuhen/services/trackbacks/212013.html2003 年 8 月 02 日

作为基于MVC模式的Web应用最经典框架，Struts已经正式推出了1.1版本，该版本在以往版本的基础上，提供了许多激动人心的新功能。本文就将带你走进Struts 1.1去深入地了解这些功能。

本文内容包括：
Model 2
Struts 1.1 和Model 2
模块
ActionServlet
ActionForm
Action
宣称式异常处理
taglib
Commons Logging 接口
关于作者
对本文的评价

说明：希望本文的读者能有一定的Struts使用基础。

Model 2

Struts是基于Model 2之上的，而Model 2是经典的MVC（模型－视图－控制器）模型的Web应用变体，这个改变主要是由于网络应用的特性--HTTP协议的无状态性引起的。Model 2的目的和MVC一样，也是利用控制器来分离模型和视图，达到一种层间松散耦合的效果，提高系统灵活性、复用性和可维护性。在多数情况下，你可以将Model 2与MVC等同起来。

下图表示一个基于Java技术的典型网络应用，从中可以看出Model 2中的各个部分是如何对应于Java中各种现有技术的。



在利用Model 2之前，我们是把所有的表示逻辑和业务逻辑都集中在一起（比如大杂烩似的JSP），有时也称这种应用模式为Model 1，Model 1的主要缺点就是紧耦合，复用性差以及维护成本高。


回页首


Struts 1.1 和Model 2

既然Struts 1.1是基于Model 2之上，那它的底层机制也就是MVC，下面是Struts 1.1中的MVC实现示意图：



图解说明：其中不同颜色代表MVC的不同部分：红色（控制器）、紫色（模型）和绿色（视图）

首先，控制器（ActionServlet）进行初始化工作，读取配置文件（struts-config.xml），为不同的Struts模块初始化相应的ModuleConfig对象。比如配置文件中的Action映射定义都保存在ActionConfig集合中。相应地有ControlConfig集合、FormBeanConfig集合、ForwardConfig集合和MessageResourcesConfig集合等。

提示：模块是在Struts 1.1中新提出的概念，在稍后的内容中我们将详细介绍，你现在可以简单地把模块看作是一个子系统，它们共同组成整个应用，同时又各自独立。Struts 1.1中所有的处理都是在特定模块环境中进行的。模块的提出主要是为了解决Struts 1.0中单配置文件的问题。

控制器接收HTTP请求，并从ActionConfig中找出对应于该请求的Action子类，如果没有对应的Action，控制器直接将请求转发给JSP或者静态页面。否则控制器将请求分发至具体Action类进行处理。

在控制器调用具体Action的execute方法之前，ActionForm对象将利用HTTP请求中的参数来填充自己（可选步骤，需要在配置文件中指定）。具体的ActionForm对象应该是ActionForm的子类对象，它其实就是一个JavaBean。此外，还可以在ActionForm类中调用validate方法来检查请求参数的合法性，并且可以返回一个包含所有错误信息的ActionErrors对象。如果执行成功，ActionForm自动将这些参数信息以JavaBean（一般称之为form bean）的方式保存在Servlet Context中，这样它们就可以被其它Action对象或者JSP调用。

Struts将这些ActionForm的配置信息都放在FormBeanConfig集合中，通过它们Struts能够知道针对某个客户请求是否需要创建相应的ActionForm实例。

Action很简单，一般只包含一个execute方法，它负责执行相应的业务逻辑，如果需要，它也进行相应的数据检查。执行完成之后，返回一个ActionForward对象，控制器通过该ActionForward对象来进行转发工作。我们主张将获取数据和执行业务逻辑的功能放到具体的JavaBean当中，而Action只负责完成与控制有关的功能。遵循该原则，所以在上图中我将Action对象归为控制器部分。

提示：其实在Struts 1.1中，ActionMapping的作用完全可以由ActionConfig来替代，只不过由于它是公共API的一部分以及兼容性的问题得以保留。ActionMapping通过继承ActionConfig来获得与其一致的功能，你可以等同地看待它们。同理，其它例如ActionForward与ForwardConfig的关系也是如此。

下图给出了客户端从发出请求到获得响应整个过程的图解说明。



下面我们就来详细地讨论一下其中的每个部分，在这之前，先来了解一下模块的概念。


回页首


模块

我们知道，在Struts 1.0中，我们只能在web.xml中为ActionServlet指定一个配置文件，这对于我们这些网上的教学例子来说当然没什么问题，但是在实际的应用开发过程中，可能会有些麻烦。因为许多开发人员都可能同时需要修改配置文件，但是配置文件只能同时被一个人修改，这样肯定会造成一定程度上的资源争夺，势必会影响开发效率和引起开发人员的抱怨。

在Struts 1.1中，为了解决这个并行开发的问题，提出了两种解决方案：

  1. 多个配置文件的支持
  2. 模块的支持

 

支持多个配置文件，是指你能够为ActionServlet同时指定多个xml配置文件，文件之间以逗号分隔，比如Struts提供的MailReader演示例子中就采用该种方法。

  <!-- Action Servlet Configuration -->
            <servlet>
            <servlet-name>action</servlet-name>
            <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
            <init-param>
            <param-name>config</param-name>
            <param-value>/WEB-INF/struts-config.xml, /WEB-INF/struts-config-registration.xml</param-value>
            </init-param>
            <load-on-startup>1</load-on-startup>
            </servlet>

这种方法可以很好地解决修改冲突的问题，不同的开发人员可以在不同的配置文件中设置自己的Action、ActionForm等等（当然不是说每个开发人员都需要自己的配置文件，可以按照系统的功能模块进行划分）。但是，这里还是存在一个潜在的问题，就是可能不同的配置文件之间会产生冲突，因为在ActionServlet初始化的时候这几个文件最终还是需要合并到一起的。比如，在struts-config.xml中配置了一个名为success的<forward>，而在struts-config-registration.xml中也配置了一个同样的<forward>，那么执行起来就会产生冲突。

为了彻底解决这种冲突，Struts 1.1中引进了模块（Module）的概念。一个模块就是一个独立的子系统，你可以在其中进行任意所需的配置，同时又不必担心和其它的配置文件产生冲突。因为前面我们讲过，ActionServlet是将不同的模块信息保存在不同的ModuleConfig对象中的。要使用模块的功能，需要进行以下的准备工作：

1、为每个模块准备一个配置文件

2、配置web.xml文件，通知控制器

决定采用多个模块以后，你需要将这些信息告诉控制器，这需要在web.xml文件进行配置。下面是一个典型的多模块配置：

<init-param>
            <param-name>config</param-name>
            <param-value>/WEB-INF/struts-config.xml</param-value>
            </init-param>
            <init-param>
            <param-name>config/customer</param-name>
            <param-value>/WEB-INF/struts-config-customer.xml</param-value>
            </init-param>
            <init-param>
            <param-name>config/order</param-name>
            <param-value>/WEB-INF/struts-config-order.xml</param-value>
            </init-param>

要配置多个模块，你需要在原有的一个<init-param>（在Struts 1.1中将其对应的模块称为缺省模块）的基础之上，增加模块对应的<init-param>。其中<param-name>表示为config/XXX的形式，其中XXX为对应的模块名，<param-value>中还是指定模块对应的配置文件。上面这个例子说明该应用有三个模块，分别是缺省模块、customer和order，它们分别对应不同的配置文件。

3、准备各个模块所需的ActionForm、Action和JSP等资源

但是要注意的是，模块的出现也同时带来了一个问题，即如何在不同模块间进行转发？有两种方法可以实现模块间的转发，一种就是在<forward>（全局或者本地）中定义，另外一种就是利用org.apache.struts.actions.SwitchAction。

下面就是一个全局的例子：

    ...
            <struts-config>
            ...
            <global-forwards>
            <forward name="toModuleB"
            contextRelative="true"
            path="/moduleB/index.do"
            redirect="true"/>
            ...
            </global-forwards>
            ...
            </struts-config>

可以看出，只需要在原有的path属性前加上模块名，同时将contextRelative属性置为true即可。此外，你也可以在<action>中定义一个类似的本地<forward>。

  <action-mappings>
            <!-- Action mapping for profile form -->
            <action path="/login"
            type="com.ncu.test.LoginAction"
            name="loginForm"
            scope="request"
            input="tile.userLogin"
            validate="true">
            <forward name="success" contextRelative="true" path="/moduleA/login.do"/>
            </action>
            </action-mappings>

如果你已经处在其他模块，需要转回到缺省模块，那应该类似下面这样定义，即模块名为空。

<forward name="success" contextRelative="true" path="/login.do"/>

此外，你也可以使用org.apache.struts.actions.SwitchAction，例如：

    ...
            <action-mappings>
            <action path="/toModule"
            type="org.apache.struts.actions.SwitchAction"/>
            ...
            </action-mappings>
            ...





回页首


ActionServlet

我们首先来了解MVC中的控制器。在Struts 1.1中缺省采用ActionServlet类来充当控制器。当然如果ActionServlet不能满足你的需求，你也可以通过继承它来实现自己的类。这可以在/WEB-INF/web.xml中来具体指定。

要掌握ActionServlet，就必须了解它所扮演的角色。首先，ActionServlet表示MVC结构中的控制器部分，它需要完成控制器所需的前端控制及转发请求等职责。其次，ActionServlet被实现为一个专门处理HTTP请求的Servlet，它同时具有servlet的特点。在Struts 1.1中它主要完成以下功能：

  • 接收客户端请求
  • 根据客户端的URI将请求映射到一个相应的Action类
  • 从请求中获取数据填充Form Bean（如果需要）
  • 调用Action类的execute()方法获取数据或者执行业务逻辑
  • 选择正确的视图响应客户

 

此外，ActionServlet还负责初始化和清除应用配置信息的任务。ActionServlet的初始化工作在init方法中完成，它可以分为两个部分：初始化ActionServlet自身的一些信息以及每个模块的配置信息。前者主要通过initInternal、initOther和initServlet三个方法来完成。

我们可以在/WEB-INF/web.xml中指定具体的控制器以及初始参数，由于版本的变化以及Struts 1.1中模块概念的引进，一些初始参数被废弃或者移入到/WEB-INF/struts-config.xml中定义。下面列出所有被废弃的参数，相应地在web.xml文件中也不鼓励再使用。

  • application
  • bufferSize
  • content
  • debug
  • factory
  • formBean
  • forward
  • locale
  • mapping
  • maxFileSize
  • multipartClass
  • nocache
  • null
  • tempDir

ActionServlet根据不同的模块来初始化ModuleConfig类，并在其中以XXXconfig集合的方式保存该模块的各种配置信息，比如ActionConfig，FormBeanConfig等。

初始化工作完成之后，ActionServlet准备接收客户请求。针对每个请求，方法process(HttpServletRequest request, HttpServletResponse response)将被调用。该方法指定具体的模块，然后调用该模块的RequestProcessor的process方法。

protected void process(HttpServletRequest request,
            HttpServletResponse response)
            throws IOException, ServletException {
            RequestUtils.selectModule(request, getServletContext());
            getRequestProcessor(getModuleConfig(request)).process(request, response);
            }

RequestProcessor包含了Struts控制器的所有处理逻辑，它调用不同的processXXX方法来完成不同的处理。下表列出其中几个主要的方法：

方法 功能
processPath 获取客户端的请求路径
processMapping 利用路径来获得相应的ActionMapping
processActionForm 初始化ActionForm（如果需要）并存入正确的scope中
processActionCreate 初始化Action
processActionPerform 调用Action的execute方法
processForwardConfig 处理Action返回的ActionForward





回页首


ActionForm

对于ActionForm你可以从以下几个方面来理解它：

  1. ActionForm表示HTTP窗体中的数据，可以将其看作是模型和视图的中介，它负责保存视图中的数据供模型或者视图使用。Struts 1.1文档中把它比作HTTP和Action之间的防火墙，这体现了ActionForm具有的过滤保护的作用，只有通过ActionForm验证的数据才能够发送到Action处理。
  2. ActionForm是与一个或多个ActionConfig关联的JavaBean，在相应的action的execute方法被调用之前，ActionForm会自动利用请求参数来填充自己（初始化属性）。
  3. ActionForm是一个抽象类，你必须通过继承来实现自己的类。

 

ActionForm首先利用属性的getter和setter方法来实现初始化，初始化完毕后，ActionForm的validate方法被调用，你可以在其中来检查请求参数的正确性和有效性，并且可以将错误信息以ActionErrors的形式返回到输入窗体。否则，ActionForm将被作为参数传给action的execute方法以供使用。

ActionForm bean的生命周期可以设置为session（缺省）和request，当设置为session时，记得在reset方法中将所有的属性重新设置为初始值。

由于ActionForm对应于HTTP窗体，所以随着页面的增多，你的ActionForm将会急速增加。而且可能同一类型页面字段将会在不同的ActionForm中出现，并且在每个ActionForm中都存在相同的验证代码。为了解决这个问题，你可以为整个应用实现一个ActionForm或者至少一个模块对应于一个ActionForm。

但是，聚合的代价就是复用性很差，而且难维护。针对这个问题，在Struts 1.1中提出了DynaActionForm的概念。

DynaActionForm类

DynaActionForm的目的就是减少ActionForm的数目，利用它你不必创建一个个具体的ActionForm类，而是在配置文件中配置出所需的虚拟ActionForm。例如，在下表中通过指定<form-bean>的type为"org.apache.struts.action.DynaActionForm"来创建一个动态的ActionForm--loginForm。

<form-beans>
            <form-bean name="loginForm" type="org.apache.struts.action.DynaActionForm">
            <form-property name="actionClass" type="java.lang.String"/>
            <form-property name="username" type="java.lang.String"/>
            <form-property name="password" type="java.lang.String"/>
            </form-bean>
            </form-beans>

动态的ActionForm的使用方法跟普通的ActionForm相同，但是要注意一点。普通的ActionForm对象需要为每个属性提供getter和setter方法，以上面的例子而言，我们需要提供getUsername() 和 setUsername()方法取得和设置username属性，同样地有一对方法用于取得和设置password属性和actionClass属性。

如果使用DynaActionForm，它将属性保存在一个HashMap类对象中，同时提供相应的get(name) 和 set(name)方法，其中参数name是要访问的属性名。例如要访问DynaActionForm中username的值，可以采用类似的代码：

String username = (String)form.get("username")；

由于值存放于一个HashMap对象，所以要记得对get()方法返回的Object对象做强制性类型转换。正是由于这点区别，如果你在Action中非常频繁地使用ActionForm对象，建议还是使用普通的ActionForm对象。

在Struts 1.1中，除了DynaActionForm以外，还提供了表单输入自动验证的功能，在包org.apache.struts.validator中提供了许多有用的类，其中最常见的就是DynaValidatorForm类。

DynaValidatorForm类

DynaValidatorForm是DynaActionForm的子类，它能够提供动态ActionForm和自动表单输入验证的功能。和使用DynaActionForm类似，你必须首先在配置文件中进行配置：

<form-beans>
            <form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
            <form-property name="actionClass" type="java.lang.String"/>
            <form-property name="username" type="java.lang.String"/>
            <form-property name="password" type="java.lang.String"/>
            </form-bean>
            </form-beans>

同时要定义验证的插件：

  <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
            <set-property property="pathnames"
            value="/WEB-INF/validator-rules.xml,
            /WEB-INF/validation.xml"/>
            </plug-in>

其中的validator.xml和validator-rules.xml分别表示验证定义和验证规则的内容（可以合并在一起），比如针对上例中的DynaValidatorForm，我们有如下验证定义（validator.xml）：

<?xml version="1.0" encoding="ISO-8859-1" ?>
            <!DOCTYPE form-validation PUBLIC
            "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.0//EN"
            "http://jakarta.apache.org/commons/dtds/validator_1_0.dtd">
            <!--    Validation Rules    $Id: validation.xml-->
            <form-validation>
            <!-- ========== Default Language Form Definitions ===================== -->
            <formset>
            <form name="loginForm">
            <field property="username" depends="required, minlength,maxlength">
            <arg0   key="prompt.username"/>
            <arg1   key="${var:minlength}" name="minlength" resource="false"/>
            <arg2   key="${var:maxlength}" name="maxlength" resource="false"/>
            <var>
            <var-name>maxlength</var-name>
            <var-value>16</var-value>
            </var>
            <var>
            <var-name>minlength</var-name>
            <var-value>3</var-value>
            </var>
            </field>
            <field property="password" depends="required, minlength,maxlength" bundle="alternate">
            <arg0   key="prompt.password"/>
            <arg1   key="${var:minlength}" name="minlength" resource="false"/>
            <arg2   key="${var:maxlength}" name="maxlength" resource="false"/>
            <var>
            <var-name>maxlength</var-name>
            <var-value>16</var-value>
            </var>
            <var>
            <var-name>minlength</var-name>
            <var-value>3</var-value>
            </var>
            </field>
            </form>
            </formset>
            </form-validation>

从上述定义中，我们可以看到对于字段username有三项验证：required, minlength, maxlength，意思是该字段不能为空，而且长度在3和16之间。而validator-rules.xml文件则可以采用Struts提供的缺省文件。注意在<form-bean>中定义的form是如何与validation.xml中的form关联起来的。最后，要启动自动验证功能，还需要将Action配置的validate属性设置为true。

<action path="/login"
            type="com.ncu.test.LoginAction"
            name="loginForm"
            scope="request"
            input="tile.userLogin"validate="true">

此时，Struts将根据xml配置文件中的定义来检验表单输入，并将不符合要求的错误信息输出到页面。但是你可能会想：这个功能虽然好，可是什么检验都跑到服务器端执行，效率方面和用户易用性方面是不是有些问题？你可能会怀念起那简单的JavaScript客户端验证。

不用担心，在Struts 1.1中也支持JavaScript客户端验证。如果你选择了客户端验证，当某个表单被提交以后，Struts 1.1启动客户端验证，如果浏览器不支持JavaScript验证，则服务器端验证被启动，这种双重验证机制能够最大限度地满足各种开发者的需要。JavaScript验证代码也是在validator-rules.xml文件中定义的。要启动客户端验证，你必须在相应的JSP文件中做如下设置：

  1. 为<html:form>增加onsubmit属性
  2. 设置Javascript支持

 

下表中列出了一JSP文件的示例代码，红字部分为Javascript验证所需代码。

<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
            <table bgcolor="#9AFF9A" cellspacing="0" cellpadding="10" border="1" width="100%">
            <tr>
            <td>
            <table cellspacing="0" cellpadding="0" border="0" width="100%">
            <tr bgcolor="#696969">
            <td align="center">
            <font color="#FFFFFF">Panel 3: Profile</font>
            </td>
            </tr>
            <tr>
            <td><br>
            <html:errors/>
            <html:form action="/login.do" focus="username"  onsubmit="return validateLoginForm(this);">
            <html:hidden property="actionClass"/>
            <center>
            <table>
            <tr>
            <td>UserName:</td>
            <td><html:text property="username" size="20"/></td>
            </tr>
            <tr>
            <td>Password:</td>
            <td><html:password property="password" size="20"/></td>
            </tr>
            <tr>
            <td colspan=2><html:submit property="submitProperty" value="Submit"/></td>
            </table>
            </center>
            </html:form>
            <html:javascript formName="loginForm" dynamicJavascript="true" staticJavascript="false"/>
            <script language="Javascript1.1" src="staticJavascript.jsp"></script>
            </td>
            </tr>
            </table>
            </td>
            </tr>
            </table>

其中onsubmit的值为"return validateLoginForm(this);"，它的语法为：

return validate + struts-config.xml中定义的form-bean名称 + (this);

staticJavascript.jsp的内容为：

<%@ page language="java" %>
            <%-- set document type to Javascript (addresses a bug in Netscape according to a web resource --%>
            <%@ page contentType="application/x-javascript" %>
            <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
            <html:javascript dynamicJavascript="false" staticJavascript="true"/>

如果validator-rules.xml中定义的基本验证功能不能满足你的需求，你可以自己添加所需的验证类型。


回页首


Action

我们通过继承Action类来实现具体的执行类。具体Action类的功能一般都在execute（以前是perform方法）方法中完成，其中主要涉及到以下几个方面：

  1. 辅助ActionForm进行一些表单数据的检查。
  2. 执行必要的业务逻辑，比如存取数据库，调用实体bean等。
  3. 更新服务器端的bean数据，后续对象中可能会用到这些数据，比如在JSP中利用bean:write来获得这些数据。
  4. 根据处理结果决定程序的去处，并以ActionForward对象的形式返回给ActionServlet。

 

提示：由于在Action和ActionForm中都可以实现验证方法，那么如何来安排它们之间的分工呢？一般来说，我们秉着MVC分离的原则，也就是视图级的验证工作放在ActionForm来完成，比如输入不能为空，email格式是否正确，利用ValidatorForm可以很轻松地完成这些工作。而与具体业务相关的验证则放入Action中，这样就可以获得最大ActionForm重用性的可能。

前面我们提到过，我们主张将业务逻辑执行分离到单独的JavaBean中，而Action只负责错误处理和流程控制。而且考虑到重用性的原因，在执行业务逻辑的JavaBean中不要引用任何与Web应用相关的对象，比如HttpServletRequest，HttpServletResponse等对象，而应该将其转化为普通的Java对象。关于这一点，可以参考Petstore中WAF框架的实现思路。

此外，你可能还注意到execute与perform的一个区别：execute方法简单地掷出Exception异常，而perform方法则掷出ServletException和IOException异常。这不是说Struts 1.1在异常处理功能方面弱化了，而是为了配合Struts 1.1中一个很好的功能--宣称式异常处理机制。


回页首


宣称式异常处理

和EJB中的宣称式事务处理概念类似，宣称式异常处理其实就是可配置的异常处理，你可以在配置文件中指定由谁来处理Action类中掷出的某种异常。你可以按照以下步骤来完成该功能：

  1. 实现org.apache.struts.action.ExceptionHandler的子类，覆盖execute方法，在该方法中处理异常并且返回一个ActionForward对象
  2. 在配置文件中配置异常处理对象，你可以配置一个全局的处理类或者单独为每个Action配置处理类

 

下表就定义了一个全局的处理类CustomizedExceptionHandler，它被用来处理所有的异常。

<global-exceptions>
            <exception
            handler="com.yourcorp.CustomizedExceptionHandler"
            key="global.error.message"
            path="/error.jsp"
            scope="request"
            type="java.lang.Exception"/>
            </global-exceptions>

其中具体的参数含义，可以参考ExceptionHandler.java源文件。


回页首


taglib

讲完了模型和控制器，接下来我们要涉及的是视图。视图的角色主要是由JSP来完成，从JSP的规范中可以看出，在视图层可以"折腾"的技术不是很多，主要的就是自定义标记库的应用。Struts 1.1在原有的四个标记库的基础上新增了两个标记库--Tiles和Nested。

其中Tiles除了替代Template的基本模板功能外，还增加了布局定义、虚拟页面定义和动态页面生成等功能。Tiles强大的模板功能能够使页面获得最大的重用性和灵活性，此外可以结合Tiles配置文件中的页面定义和Action的转发逻辑，即你可以将一个Action转发到一个在Tiles配置文件中定义的虚拟页面，从而减少页面的数量。比如，下表中的Action定义了一个转发路径，它的终点是tile.userMain，而后者是你在Tiles配置文件中定义的一个页面。

<!-- ========== Action Mapping Definitions ============================== -->
            <action-mappings>
            <!-- Action mapping for profile form -->
            <action path="/login"
            type="com.ncu.test.LoginAction"
            name="loginForm"
            scope="request"
            input="tile.userLogin"
            validate="true">
            <forward name="success" path="tile.userMain"/>
            </action>
            </action-mappings>

Tiles配置文件：tiles-defs.xml

<!DOCTYPE tiles-definitions PUBLIC
            "-//Apache Software Foundation//DTD Tiles Configuration//EN"       "http://jakarta.apache.org/struts/dtds/tiles-config.dtd">
            <tiles-definitions>
            <!-- =======================================================  -->
            <!-- Master definitions                                       -->
            <!-- =======================================================  -->
            <!-- Page layout used as root for all pages. -->
            <definition name="rootLayout" path="/tiles-layouts/rootLayout.jsp">
            <put name="titleString" value="CHANGE-ME"/>
            <put name="topMenu" value="/tiles-components/topMenu.jsp"/>
            <put name="leftMenu" value="/tiles-components/panel1.jsp"/>
            <put name="body" value="CHANGE-ME"/>
            <put name="footer" value="/tiles-components/footer.jsp"/>
            </definition>
            <!-- =======================================================  -->
            <!-- Page definitions 					-->
            <!-- =======================================================  -->
            <!-- User Login page -->
            <definition name="tile.userLogin" extends="rootLayout">
            <put name="titleString" value="User Login"/>
            <put name="body" value="/src/userLogin.jsp"/>
            </definition>
            <!-- User Main page -->
            <definition name="tile.userMain" extends="rootLayout">
            <put name="titleString" value="User Main"/>
            <put name="body" value="/src/userMain.jsp"/>
            </definition>
            </tiles-definitions>

而Nested标记库的作用是让以上这些基本标记库能够嵌套使用，发挥更大的作用。


回页首


Commons Logging 接口

所谓的Commons Logging接口，是指将日志功能的使用与日志具体实现分开，通过配置文件来指定具体使用的日志实现。这样你就可以在Struts 1.1中通过统一的接口来使用日志功能，而不去管具体是利用的哪种日志实现，有点于类似JDBC的功能。Struts 1.1中支持的日志实现包括：Log4J，JDK Logging API， LogKit，NoOpLog和SimpleLog。

你可以按照如下的方式来使用Commons Logging接口（可以参照Struts源文中的许多类实现）：

package com.foo;
            // ...
            import org.apache.commons.logging.Log;
            import org.apache.commons.logging.LogFactory;
            //...
            public class Foo {
            // ...
            private static Log log = LogFactory.getLog(Foo.class);
            // ...
            public void setBar(Bar bar) {
            if (log.isTraceEnabled()) {
            log.trace("Setting bar to " + bar);
            }
            this.bar = bar;
            }
            // ...
            }

而开启日志功能最简单的办法就是在WEB-INF/classes目录下添加以下两个文件：

commons-logging.properties文件：

# Note: The Tiles framework now uses the commons-logging package to output different information or debug statements.
            Please refer to this package documentation to enable it. The simplest way to enable logging is to create two files in
            WEB-INF/classes:
            # commons-logging.properties
            # org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
            # simplelog.properties
            # # Logging detail level,
            # # Must be one of ("trace", "debug", "info", "warn", "error", or "fatal").
            #org.apache.commons.logging.simplelog.defaultlog=trace
            org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog

simplelog.properties文件：

# Logging detail level,
            # Must be one of ("trace", "debug", "info", "warn", "error", or "fatal").
            org.apache.commons.logging.simplelog.defaultlog=fatal

这里我们采用的日志实现是SimpleLog，你可以在simplelog.properties文件指定日志明细的级别：trace，debug，info，warn，error和fatal，从trace到fatal错误级别越来越高，同时输出的日志信息也越来越少。而这些级别是和org.apache.commons.logging.log接口中的方法一一对应的。这些级别是向后包含的，也就是前面的级别包含后面级别的信息。



心无痕 2008-07-01 22:10 发表评论
]]>Struts配置文件详解----转载http://www.blogjava.net/xinwuhen/archive/2008/07/01/211910.html心无痕心无痕Tue, 01 Jul 2008 07:16:00 GMThttp://www.blogjava.net/xinwuhen/archive/2008/07/01/211910.htmlhttp://www.blogjava.net/xinwuhen/comments/211910.htmlhttp://www.blogjava.net/xinwuhen/archive/2008/07/01/211910.html#Feedback0http://www.blogjava.net/xinwuhen/comments/commentRss/211910.htmlhttp://www.blogjava.net/xinwuhen/services/trackbacks/211910.html相关文章:  
推荐圈子: IBM WebSphere专区
更多相关推荐 Struts应用采用两个基于XML的配置文件来配置,分别是web.xml和struts-cofig.xml文件.web.xml文件是配置所有 web应用的而struts-config.xml文件是struts专用的配置文件,事实上也是可以根据需要给这个配置文件起其他名称的.
Web应用的发布描述文件:web应用发布描述文件可以在应用开着者,发布者和组装者之间传递配置信息,Web容器在启动的时候从该文件中读取配置信息, 根据它来装载和配置web应用.文档类型定义DTD对XML文档的格式做了定义,DTD吧XML文档划分为元素,属性,实体每一种XML文档都有独自的 DTD文件.可以从网上下载.<web-app>元素是web.xml的根元素,其他元素必须嵌入在<web-app>元素之内.要注意的是子元素也是有顺序的比如必须是首先<servlet>,然后<servlet-mapping>最后< taglib>.

为Struts应用配置Web.xml文件:首先最重要的一步是配置ActionServlet,这个用<servlet>标签的 servlet-name属性起一个名字叫action,然后用servlet-class属性指定ActionServlet的类.然后用< servlet-mapping>标签的servlet-name属性指定action,在用url-pattern指定接收范围是*.do的请求.不管应用中包含了多少子应用,都只需要配置一个ActionServlet,类来出来应用中的不同的功能,其实者就是不必要的,因为Servlet本身就是多线程的,而且目前Struts只允许配置一个ActionServlet.声明ActionServlet的初始化参数:< servlet>的<init-param>子元素用来配置Servlet的初始化参数.param-name设置config参数名.param-value设置struts-config.xml的路径参数值.

配置欢迎使用清单:如果客户访问Web的时候值是访问了WEB应用的根目录URL.没有具体的指定文件,Web会自动调用Web的欢迎文件.< welcome-file-list>元素来配置的.通过其中的<welcome-file>欢迎页面</welcome- file>来配置.

配置错误处理:尽管Struts框架功能强大的错误处理机制,但是不能保证处理所有的错误或者异常.当错误发生时,如果框架不能处理这种错误,把错误抛弃给Web容器,在默认的情况下web容器会想客户端返回错误信息.如果想避免让客户看到原始的错误信息,可以在Web应用发布描述文件中配置< error-page>元素.通过<error-code>404来定义错误的类型.然后通过<location>要处理错误的JSP页面来对错误进行处理.还可以用<exception-type>来设置异常,然后通过<location>来处理异常的JSP页面来处理异常.

配置Struts标签库:这个就和以前学到的JSP自定义标签类似,配置元素为<taglib>来配置.<taglib- uri>这个指定标签库的uri,类似起一个名称.<taglib-location>这个是标签库的位置也就是实际所在的路径.通过这样的方法引入一个标签库,然后在前台JSP页面就可以通过自己定义的URI来调用标签.

Struts配置文件:struts-config.xml文件.首先研讨一下org.apache.struts.config包,在struts应用启动的时候会把Struts配置文件信息读取到内存中,并把它们存放在config包中相关的JavaBean类的实例中.包中的每一个类都和 struts配置文件中特定的配置元素对应,ModuleConfig在Struts框架中扮演了十分重要的角色,它是整个config包的核心,在 Struts运行时来存放整个应用的配置信息.如果有多个子应用都会有一个ModuleConfig对象,它和Struts文件根元素的< struts-config>对应.根元素中包含<form-bean><action><forward> 等元素.

<struts-config>元素:时Struts配置文件的根元素,和它对应的配置类ModuleConfig类,<struts -config>元素有8个子元素.他们的DTD定义是data-sources?form-bean? global-exception?global-forwards?action-mapping?controller?message-resources? plug-in*在Struts配置文件中,必须按照DTD指定的先手顺序来配置<struts-config>元素的各个子元素,如果颠倒了这些子元素的顺序,会产生错误.

<data-sources>元素:用来配置应用所需要的数据源,数据源负责创建和特定的数据库的连接.许多数据源采用连接池的机制实现.以便提高数据库访问的性能.JAVA语言提供了javax.sql.DataSource接口,所有的数据源都必须实现这个接口.许多应用服务器和Web服务器都提供了数据源组件.很多数据库厂商也提供了数据源的实现.<data-sources>元素包含多个<data- source>子元素永远配置特定的数据源.他们可以包含多个<set-property>子元素用于设置数据源的各种属性.配置了数据源以后,就可以在Action类中访问数据源,在Action中定义了getDataSource(HttpRequest)方法,用于获取数据源对象的引用.然后可以利用DataSource对象调用getConnection获取一个连接对象对数据库进行操作.在配置文件中声明多个数据源的时候需要为每一个数据源分配唯一的Key值,通过这个来表示特定的数据源.获取特定的数据源的时候可以用dataSource = getDataSource(reqeust,”A”);

<form-beans>元素:用来配置多个ActionForm,包含一个或者N个<form-bean>子元素.每个 <form-bean>元素都包含多个属性.className指定和<form-bean>匹配的类.name指定该 ActionForm的唯一标识符,这个属性是必须的以后作为引用使用.type指定ActionForm类的完整类名,这个属性也是必须的.注意包名也要加上.<form-property>是指定动态的Form的元素,以后会深入了解.

<global-exception>元素:用于配置异常处理,元素可以包含一个或者多个<exception>元素,用来设置 JAVA异常和异常处理类ExceptionHandler之间的映射.className指定和元素对应的配置类,默认的不用动.handler指定异常处理类默认是ExceptionHandler.key指定在本地资源文件中异常的消息Key,path指定当前异常发生的时候转发的路径.scope 指定ActionMessages实例存放的范围.type指定需要处理异常类的名字,必须的.bundle指定Resource Bundle.

<global-forwards>元素:用来声明全局转发,元素可以有一个或者N个<forward>元素组成,用于把一个逻辑名映射到特定的URL,通过这种方法Action类或者JSP页面无需指定URL,只要指定逻辑名称就可以实现请求转发或者重定向.这样可以减少控制组件和视图的聚合.易于维护.className对应的配置类.contextRelative如果为true表示当path属性以/开头的时候,给出的是对应的上下文URL默认是false.name转发路径的逻辑名,必须写.path转发或者重定向的URL,必须写必须是以/开头.redirect设置为true的时候表示执行重定向操作,此项为false的时候,表示执行请求转发操作.重定向与请求转发的区别以后就是重定向是把请求生成应答给客户端然后在重新发送给定向的URL,浏览器地址栏会有显示.而转发就是直接把请求转发给本应用的另一个文件,不生成应答所以客户端IE没显示.

<action-mapping>元素:包含一个或者N个<action>元素,描述了从特定的请求路径到响应的Action的映射.在<action>元素中可以包含多个<exception>和<forward>子元素,他们分别配置局部异常处理和局部转发.attribute设置Action关联的ActionForm在request或者session范围内的key.就是在 request或者session共享内的名称.className对应配置元素的类.默认的是ActionMapping.forward指定转发 URL路径include指定包含URL路径.input指定包含表单的URL,当表单验证失败的时候发送的URL.name,指定和该Action关联的Form名字.该名字必须是在form-bean中定义过的,可写可不写.path必须/开头的方位Action的路径.parameter指定 Action配置参数.在Action的execute()方法中可以调用ActionMapping的getParameter()方法来读取匹配的参数.roles指定允许调用该Action的安全角色,多个角色之间逗号格开.scope指定Form的存在范围.默认是session.tyep指定 Action的完整类名.unknown如果是true表示可以处理用户发出的所有的无效的ActionURL默认是false.validate指定是否调用ActionForm的validate方法.

<controller>元素:用于配置ActionServlet.buffreSize指定上载文件的输入缓冲大小.该属性为可选默认 4096.className指定元素对应的配置类,ControllerConfig.然后是contentType指定响应结果内容类型和字符编码, 该属性为可选,默认是text/html如果在Action或者JSP网页也设置了类型内容,会覆盖这个.locale指定是否把Locale对象保存到当前用户的session中默认false.tempDir指定处理文件上载的临时工作目录.nochache如果是true在响应结果中加入特定的头参数.

<message-resources>元素:用来配置Resource Bundle.用于存放本地文本消息文件.className元素对应的配置类.MessageResourcesConfig.factory指定消息的工厂类.key指定文件存放的Servlet对象中采用的属性Key.null指定如何处理未知消息.parameter指定消息的文件名.

<plug-in>元素:用于配置Struts插件.

配置多应用模块:所有的子应用都可以共享同一个ActionServlet实例,但是每个子应用都有单独的配置文件.把应用划分为多个子应用模块. 首先为每个应用创建单独的Struts配置文件,在web.xml的ActionServlet配置代码中添加几个子应用信息.采用< forward>元素来实现应用之间的切换.

Digester组件:是一个Apache的另一个开源代码项目.当Struts被初始化的时候,首先会读取并解析配置文件,框架采用Digester组件来且西配置文件.然后创建config包中的对象.者对象用于存放配置信息.

其实配置文件不难,只要都理其中的原理就OK了.真正实际的项目开发中,采用的工具例如Eclipse系列,提供了相应的插件,在创建一个Struts工程的时候配置文件的标签都是自动生成的,而我们只需要往里面填写属性就OK了.


心无痕 2008-07-01 15:16 发表评论
]]>用例建模指南----转自IBM DeveloperWorkshttp://www.blogjava.net/xinwuhen/archive/2008/07/01/211808.html心无痕心无痕Tue, 01 Jul 2008 01:26:00 GMThttp://www.blogjava.net/xinwuhen/archive/2008/07/01/211808.htmlhttp://www.blogjava.net/xinwuhen/comments/211808.htmlhttp://www.blogjava.net/xinwuhen/archive/2008/07/01/211808.html#Feedback0http://www.blogjava.net/xinwuhen/comments/commentRss/211808.htmlhttp://www.blogjava.net/xinwuhen/services/trackbacks/211808.html用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。用例的使用在RUP中被推崇备至，整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。

1. 什么是用例？

在介始用例方法之前，我们首先来看一下传统的需求表述方式-"软件需求规约"(Software Requirement Specification)。传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。一个典型的软件需求规约可能具有以下形式：



采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。

功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。

1.1 参与者和用例

从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成：

  • 参与者(Actor)
    参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
  • 用例(Use Case)
    用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
  • 通讯关联(Communication Association)
    通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。

这大三种模型元素在UML中的表述如下图所示。



以银行自动提款机(ATM)为例，它的主要功能可以由下面的用例图来表示。ATM的主要使用者是银行客户，客户主要使用自动提款机来进行银行帐户的查询、提款和转帐交易。



通讯关联表示的是参与者和用例之间的关系，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果你不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由通讯关联来表示的，该信息流是缺省存在的（用例本身描述的就是参与者和系统之间的对话），并且信息流向是双向的，它与通讯关联箭头所指的方向亳无关系。

1.2 用例的内容

用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。如在ATM系统中的"提款"用例可以用事件流表述如下：

提款-基本事件流

1. 用户插入信用卡

2. 输入密码

3. 输入提款金额

4. 提取现金

5. 退出系统，取回信用卡

但是这只描述了提款用例中最顺利的一种情况，作为一个实用的系统，我们还必须考虑可能发生的各种其他情况，如信用卡无效、输入密码错、用户帐号中的现金余额不够等，所有这些可能发生的各种情况（包括正常的和异常的）被称之为用例的场景(Scenario)，场景也被称作是用例的实例(Instance)。在用例的各种场景中，最常见的场景是用基本流(Basic Flow)来描述的，其他的场景则是用备选流(Alternative Flow)来描述。对于ATM系统中的"提款"用例，我们可以得到如下一些备选流：

提款-备选事件流

备选流一：用户可以在基本流中的任何一步选择退出，转至基本流步骤5。

备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。

备选流三：在基本流步骤２中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。

…

通过基本流与备选流的组合，就可以将用例所有可能发生的各种场景全部描述清楚。我们在描述用例的事件流的时候，就是要尽可能地将所有可能的场景都描述出来，以保证需求的完备性。

1.3 用例方法的优点

用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者（抽象成为Actor），这些使用者与被定义系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。

与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。

在RUP中，用例被作为整个软件开发流程的基础，很多类型的开发活动都把用例作为一个主要的输入工件(Artifact)，如项目管理、分析设计、测试等。根据用例来对目标系统进行测试，可以根据用例中所描述的环境和上下文来完整地测试一个系统服务，可以根据用例的各个场景(Scenario)来设计测试用例，完全地测试用例的各种场景可以保证测试的完备性。


回页首


2. 建立用例模型

使用用例的方法来描述系统的功能需求的过程就是用例建模，用例模型主要包括以下两部分内容：

  • 用例图(Use Case Diagram)
    确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。
  • 用例规约(Use Case Specification)
    针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。

在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。

2.1 寻找参与者

所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：

  • 系统开发完成之后，有哪些人会使用这个系统？
  • 系统需要从哪些人或其他系统中获得数据？
  • 系统会为哪些人或其他系统提供数据？
  • 系统会与哪些其他系统相关联？
  • 系统是由谁来维护和管理的？

这些问题有助于我们抽象出系统的参与者。对于ATM机的例子，回答这些问题可以使我们找到更多的参与者：操作员负责维护和管理ATM机系统、ATM机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。



2.1.1 系统边界决定了参与者

参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于ATM机本身，那么后台服务器就是一个外部的系统，可以抽象为一个参与者。



如果我们所要定义的系统边界扩大至整个银行系统，ATM机和后台服务器都是整个银行系统的一部分，这时候后台服务器就不再被抽象成为一个参与者。



值得注意的是，用例建模时不要将一些系统的组成结构作为参与者来进行抽象，如在ATM机系统中，打印机只是系统的一个组成部分，不应将它抽象成一个独立的参与者；在一个MIS管理系统中，数据库系统往往只作为系统的一个组成部分，一般不将其单独抽象成一个参与者。

2.1.2 特殊的参与者――系统时钟

有时候我们需要在系统内部定时地执行一些操作，如检测系统资源使用情况、定期地生成统计报表等等。从表面上看，这些操作并不是由外部的人或系统触发的，应该怎样用用例方法来表述这一类功能需求呢？对于这种情况，我们可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一类定时操作。从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。



2.2 确定用例

找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手（针对每一个参与者）：

  • 参与者为什么要使用该系统？
  • 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？
  • 参与者是否会将外部的某些事件通知给该系统？
  • 系统是否会将内部的某些事件通知该参与者？

综合以上所述，ATM系统的用例图可表示如下，



在用例的抽取过程中，必须注意：用例必须是由某一个主角触发而产生的活动，即每个用例至少应该涉及一个主角。如果存在与主角不进行交互的用例，就可以考虑将其并入其他用例；或者是检查该用例相对应的参与者是否被遗漏，如果是，则补上该参与者。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在，就应该考虑该参与者是如何与系统发生对话的，或者由参与者确定一个新的用例，或者该参与者是一个多余的模型元素，应该将其删除。

可视化建模的主要目的之一就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是一个团队开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合一定的命名约定，这样整个用例模型才能够符合一定的风格。如参与者的名称一般都是名词，用例名称一般都是动宾词组等。

对于同一个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方案中选择一种"最佳"（或"较佳"）的结果，一个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应该是一致的。

2.3 描述用例规约

应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：

  • 简要说明 (Brief Description)
    简要介绍该用例的作用和目的。
  • 事件流 (Flow of Event)
    包括基本流和备选流，事件流应该表示出所有的场景。
  • 用例场景 (Use-Case Scenario)
    包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
  • 特殊需求 (Special Requirement)
    描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
  • 前置条件 (Pre-Condition)
    执行用例之前系统必须所处的状态。
  • 后置条件 (Post-Condition)
    用例执行完毕后系统可能处于的一组状态。

用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。

2.3.1 基本流

基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流：

1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。

2) 用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过浏览标题来快速地了解用例的主要步骤。在用例建模的早期，我们也只需要描述到事件流步骤标题这一层，以免过早地陷入到用例描述的细节中去。

3) 当整个用例模型基本稳定之后，我们再针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向(roundtrip)描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。具体例子请参见附录。

在描述参与者和系统之间的信息交换时，需指出来回传递的具体信息。例如，只表述参与者输入了客户信息就不够明确，最好明确地说参与者输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内，可以在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。

2.3.2 备选流

备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在描述备选流时，应该包括以下几个要素：

1) 起点：该备选流从事件流的哪一步开始；

2) 条件：在什么条件下会触发该备选流；

3) 动作：系统在该备选流下会采取哪些动作；

4) 恢复：该备选流结束之后，该用例应如何继续执行。

备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容，编号前可以加以字母前缀A(Alternative)以示与基本流步骤相区别。

2.3.3 用例场景

用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。在用例规约中，场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。

2.3.4 特殊需求

特殊需求通常是非功能性需求，它为一个用例所专有，但不适合在用例的事件流文本中进行说明。特殊需求的例子包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些设计约束，如操作系统及环境、兼容性需求等，也可以在此节中记录。

需要注意的是，这里记录的是专属于该用例的特殊需求；对于一些全局的非功能性需求和设计约束，它们并不是该用例所专有的，应把它们记录在《补充规约》中。

2.3.5 前置和后置条件

前置条件是执行用例之前必须存在的系统状态，后置条件是用例一执行完毕后系统可能处于的一组状态。

2.4 检查用例模型

用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查：

  • 功能需求的完备性
    现有的用例模型是否完整地描述了系统功能，这也是我们判断用例建模工作是否结束的标志。如果发现还有系统功能没有被记录在现有的用例模型中，那么我们就需要抽象一些新的用例来记录这些需求，或是将他们归纳在一些现有的用例之中。
  • 模型是否易于理解
    用例模型最大的优点就在于它应该易于被不同的涉众所理解，因而用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。
  • 是否存在不一致性
    系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成的，所以我们要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。
  • 避免二义性语义
    好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中，应该避免定义含义模糊的需求，即无二义性。




回页首


3. 系统需求

RUP中根据FURPS+模型将系统需求分为以下几类：

  • 功能(Functionality)
  • 可用性(Usability)
  • 可靠性(Reliability)
  • 性能(Performance)
  • 可支持性(Supportability)
  • 设计约束等

除了第一项功能性需求之外的其他需求都归之为非功能性需求。

3.1 需求工件集

用例模型主要用于描述系统的功能性需求，对于其他的非功能性需要用其他文档来记录。RUP中定义了如下的需求工件集合。

  • 用例模型：记录功能性需求
    • 用例图：描述参与者和用例之间的关系
    • 用例规约：描述每一个用例的细节信息
  • 补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等
  • 词汇表：记录一些系统需求相关的术语

在实际应用中，除了这些工件之外，我们还可以根据实际需求灵活选用其他形式的文档来补充说明需求。并不是所有的系统需求都适保合用用例模型来描述的，如编译器，我们很难用用例方法来表述它所处理的语言的方法规则，在这种情况下，采用传统的BNF范式来表述更加合适一些。在电信软件行业中，很多电信标准都是采用SDL语言来描述的，我们也不必用UML来改写这些标准（UML对SDL存在着这样的兼容性），只需将SDL形式的电信标准作为需求工件之一，在其他工件中对其加以引用就可以了。总之，万万不可拘泥于用例建模的形式，应灵活运用各种方式的长处。

3.2 补充规约

补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。

  • 功能性
    功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。有些功能性需求是全局性的，适用于所有的用例，如出错处理、I18N支持等，我们不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。
  • 可用性
    记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如Windows界面风格等。
  • 可靠性
    定义系统可靠性相关的各种指标，包括：
    • 可用性：指出可用时间百分比(xx.xx%)，系统处于使用、维护、降级模式等操作的小时数；
    • 平均故障间隔时间(MTBF)：通常表示为小时数，但也可表示为天数、月数或年数；
    • 平均修复时间(MTTR)：系统在发生故障后可以暂停运行的时间；
    • 精确度：指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）；
    • 最高错误或缺陷率：通常表示为bugs/KLOC（每千行代码的错误数目）或bugs/function-point（每个功能点的错误数目）。
  • 性能
    记录系统性能相关的各种指标，包括：
    • 对事务的响应时间（平均、最长）；
    • 吞吐量（例如每秒处理的事务数）；
    • 容量（例如系统可以容纳的客户或事务数）；
    • 降级模式（当系统以某种形式降级时可接受的运行模式）；
    • 资源利用情况：内存、磁盘、通信等。
  • 可支持性
    定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。
  • 设计约束
    设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。

3.3 词汇表

词汇表主要用于定义项目特定的术语，它有助于开发人员对项目中所用的术语有统一的理解和使用，它也是后续阶段中进行对象抽象的基础。


回页首


4. 调整用例模型

在一般的用例图中，我们只表述参与者和用例之间的关系，即它们之间的通讯关联。除此之外，我们还可以描述参与者与参与者之间的泛化(generalization)、用例和用例之间的包含(include)、扩展(extend)和泛化(generalization)关系。我们利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来重用，使得用例模型更易于维护。但是在应用中要小心选用这些关系，一般来说这些关系都会增加用例和关系的个数，从而增加用例模型的复杂度。而且一般都是在用例模型完成之后才对用例模型进行调整，所以在用例建模的初期不必要急于抽象用例之间的关系。

4.1 参与者之间的关系

参与者之间可以有泛化(Generalization)关系（或称为"继承"关系）。例如在需求分析中常见的权限控制问题（如下图所示），一般的用户只可以使用一些常规的操作，而管理员除了常规操作之外还需要进行一些系统管理工作，操作员既可以进行常规操作又可以进行一些配置操作。



在这个例子中我们会发现管理员和操作员都是一种特殊的用户，他们拥有普通用户所拥有的全部权限，此外他们还有自己独有的权限。这里我们可进一步把普通用户和管理员、操作员之间的关系抽象成泛化(Generalization)关系，管理员和操作员可以继承普通用户的全部特性（包括权限），他们又可以有自己独有的特性（如操作、权限等）。这样可以显著减速少用例图中通讯关联的个数，简化用例模型，使之更易于理解。



4.2 用例之间的关系

用例描述的是系统外部可见的行为，是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息，然后通后过不同的方法来重用这部公共信息，以减少模型维护的工作量。

4.2.1 包含(include)

包含关系是通过在关联关系上应用<<include>>构造型来表示的，如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion)，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。



包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)，如下图。



在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例"打印回执"，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。



在基础用例的事件流中，我们只需要引用被包含用例即可。

查询-基本事件流

1. 用户插入信用卡

2. 输入密码

3. 选择查询

4. 查看帐号余额

5. 包含用例"打印回执"

6. 退出系统，取回信用卡

在这个例子中，多个用例需要用到同一段行为，我们可以把这段共同的行为单独抽象成为一个用例，然后让其他的用例来包含这一用例。从而避免在多个用例中重复性地描述同一段行为，也可以防止该段行为在多个用例中的描述出现不一致性。当需要修改这段公共的需求时，我们也只需要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。

有时当某一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

4.2.2 扩展(extend)

扩展（extend）关系如下图所示，基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。对于包含关系而言，子用例中的事件流是一定插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。



例如对于电话业务，可以在基本通话(Call)业务上扩展出一些增值业务如：呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下。





在这个例子中，呼叫等待和呼叫转移都是对基本通话用例的扩展，但是这两个用例只有在一定的条件下（如应答方正忙或应答方无应答）才会将被扩展用例的事件流嵌入基本通话用例的扩展点，并重用基本通话用例中的事件流。

值得注意的是扩展用例的事件流往往可以也可抽象为基础用例的备选流，如上例中的呼叫等待和呼叫转移都可以作为基本通话用例的备选流而存在。但是基本通话用例已经是一个很复杂的用例了，选用扩展关系将增值业务抽象成为单独的用例可以避免基础用例过于复杂，并且把一些可选的操作独立封装在另外的用例中。

4.2.3 泛化(generalization)

当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。



以下是一个用例泛化关系的例子，执行交易是一种交易抽象，执行房产交易和执行证券交易都是一种特殊的交易形式。

用例泛化关系中的事件流示例如下：



4.3 调整用例模型

用例模型建成之后，我们可以对用例模型进行检视，看是否可以进一步简化用例模型、提高重用程度、增加模型的可维护性。主要可以从以下检查点(checkpoints)入手:

  • 用例之间是否相互独立？如果两个用例总是以同样的顺序被激活，可能需要将它们合并为一个用例。
  • 多个用例之间是否有非常相似的行为或事件流？如果有，可以考虑将它们合并为一个用例。
  • 用例事件流的一部分是否已被构建为另一个用例？如果是，可以让该用例包含(include)另一用例。
  • 是否应该将一个用例的事件流插入另一个用例的事件流中？如果是，利用与另一个用例的扩展关系(extend)来建立此模型。




回页首


5. 管理用例模型复杂度

一般小型的系统，其用例模型中包含的参与者和用例不会太多，一个用例图就可以容纳所有的参与者，所有的参与者和用例也可以并存于同一个层次结构中。对于较复杂的大中型系统，用例模型中的参与者和用例会大大增加，我们需要一些方法来有效地管理由于规模上升而造成的复杂度。

5.1 用例包

包(Package)是UML中最常用的管理模型复杂度的机制，包也是UML中语义最简单的一种模型元素，它就是一种容器，在包中可以容纳其他任意的模型元素（包括其他的包）。在用例模型中，我们可以用构造型(Sterotype)<<use case>>来扩展标准UML包的语义，这种新的包叫作用例包(Use Case Package)，用于分类管理用例模型中的模型元素。

我们可以根据参与者和用例的特性来对它们进行分类，分别置于不同的用例包管理之下。例如对于一个大型的企业管理信息系统，我们可以根据参与者和用例的内容将它们分别归于人力资源、财务、采购、销售、客务服务这些用例包之下。这样我们将整个用例模型划分成为两个层次，在第一层次我们看到的是系统功能总共分为五部分，在第二层次我们可以分别看到每一用例包内部的参与者和用例。



一个用例模型需要有多少个用例包取决你想怎么样来管理用例模型的复杂度（包括参与者和用例的个数，以及它们之间的相互关系）。UML中的包其实就类似于文件系统中的目录，文件数量少的时候不需要额外的目录，文件数量一多就需要有多个目录来分类管理，同样一组文件不同的人会创建不同的目录结构来进行管理，关键是要保证在目录结构下每一个文件都要易于访问。同样的道理存在于用例建模之中，如何创建用例包以及用例包的个数取决于不同的系统和系统分析员，但要保证整个用例模型易于理解。

5.2 用例的粒度

我的系统需要有多少个用例？这是很多人在用例建模时会产生的疑惑。描述同一个系统，不同的人会产生不同的用例模型。例如对于各种系统中常见的"维护用户"用例，它里面包含了添加用户、修改用户信息、删除用户等操作，这些操作在该用例的事件流可以表述成为基本流的子事件流(subflow)。



维护用户-基本事件流

该基本流由三个子事件流构成：

1) 添加用户子事件流
…

2) 修改用户 子事件流
…

3) 删除用户子事件流
…

但是你也可以根据该用例中的具体操作把它抽象成为三个用例，它所表示的系统需求和单个用例的模型是完全一样的。



应该如何确定用例的粒度呢？在一次技术研讨会上，有人问起Ivar Jacoboson博士，一个系统需要有多少个用例？大师的回答是20个，当然他的意思是最好将用例模型的规模控制在几十个用例左右，这样比较容易来管理用例模型的复杂度。在用例个数大致确定的条件下，我们就很容易来确定用例粒度的大小。对于较复杂的系统，我们需要控制用例模型一级的复杂度，所以可以将复杂度适当地移往每一个用例的内部，也就是让一个用例包含较多的需求信息量。对于比较简单的系统，我们则可以将复杂度适度地曝露在模型一级，也就是我们可以将较复杂的用例分解成为多个用例。

用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。我们应该根据每个系统的具体情况，因时因宜地来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。

5.3 用例图

用例图的主要作用是描述参与者和用例之间的关系，简单的系统中只需要有一个用例图就可以把所有的关系都描述清楚。复杂的系统中可以有多个用例图，例如每个用例包都可以有一个独立的用例图来描述该用例包中所有的参与者和用例的关系。

在一个用例模型中，如果参与者和用例之间存在着多对多的关系，并且他们之间的关系比较复杂，如果在同一个用例图中表述所有的参与者和用例就显得不够清晰，这时我们可创建多个用例图来分别表示各种关系。



如果想要强调某一个参与者和多个用例的关系，你就可以以该参与者为中心，用一个用例图表述出该参与者和多个用例之间的关系。在这个用例图中，我们强调的是该参与者会使用系统所提供的哪些服务。



如果想要强调某一个用例和多个参与者之间的关系，你就可以以该用例为中心，用一个用例图表述出该用例和多个参与者之间的关系。在这个用例图中，我们强调的是该用例会涉及到哪些参与者，或者说该用例所表示的系统服务有哪些使用者。



总之在用例建模过程中，你可以根据自己的需要创建任意多个用例图，用不同的用例来强调参与者和用例之间不同的关系。但是最重要的是要考虑整个用例模型的可理解性，如果可以用一个用例图把意思表述清楚，就不要再用第二个，因为越是简洁的模型越易于理解。



参考资料

  • 样例代码



  • Jeffrey Friedl, Mastering Regular Expressions, O'Reilly

  • Mendel Cooper, Advanced Bash-Scripting Guide

  • Michael Jang, Mastering Redhat 9


关于作者

 

傅纯一，IBM中国有限公司软件部Rational中国区技术销售经理


心无痕 2008-07-01 09:26 发表评论
]]>搭建MyEclipse+Tomcat开发环境http://www.blogjava.net/xinwuhen/archive/2008/06/30/211769.html心无痕心无痕Mon, 30 Jun 2008 14:26:00 GMThttp://www.blogjava.net/xinwuhen/archive/2008/06/30/211769.htmlhttp://www.blogjava.net/xinwuhen/comments/211769.htmlhttp://www.blogjava.net/xinwuhen/archive/2008/06/30/211769.html#Feedback0http://www.blogjava.net/xinwuhen/comments/commentRss/211769.htmlhttp://www.blogjava.net/xinwuhen/services/trackbacks/211769.html本文转自:http://esoft.bokee.com/5081515.html

一、安装JDK
首先下载JDK 5.0 Update7（JDK 5.0 Update7的下载页面为：
http://java.sun.com/javase/downloads/index.jsp）；
然后运行JDK 5.0安装程序jdk-1_5_0_07-windows-i586-p.exe，安装过程中所有选项保持默认；
最后配置JDK的环境变量：在“我的电脑”上点右键—>“属性”—>“高级”—> “环境变量(N)”。

新建系统变量JAVA_HOME：C:\Program Files\Java\jdk1.5.0_06
新建系统变量CLASSPATH：.;%JAVA_HOME%\lib;（注意：点号表示当前目录，不能省略）
在系统变量Path的值的前面加入以下内容：%JAVA_HOME%\bin;(注意:这里的分号不能省略)
到这里，JDK安装完毕。
下面我们测试一下JDK是否安装成功：
将以下内容复制到记事本中：
public class HelloJAVA
{
public static void main(String srg[])
{
System.out.println("Hello JAVA!");
}
}
另存为“HelloJAVA.java”（不含引号，下同），并保存到D盘根目录下。
在命令行依次输入下图中红线所标注的命令：

如果出现上图红框中所标注的内容，则说明JDK安装成功！

注意:如果以后要安装诸如Eclipse、Borland JBuilder、JCreator、IntelliJ IDEA等集成开发环境(IDE,Integrated Development Environment),应该在IDE中编译运行一个简单的HelloWorld程序，以保证IDE可以识别出JDK的位置。

二、安装Tomcat
首先下载jakarta-tomcat-5.0.30.zip，之所以下载免安装版的好处是可以使用多个Tomcat（jakarta-tomcat-5.0.30.zip的下载页面为：
http://apache.linuxforum.net/tomcat/tomcat-5/v5.0.30/bin/）；
然后将jakarta-tomcat-5.0.30.zip直接解压到D盘根目录：

最后配置Tomcat的环境变量：在“我的电脑”上点右键—>“属性”—>“高级”—> “环境变量(N)”。
新建系统变量CATALINA_HOME：D:\jakarta-tomcat-5.0.30
在系统变量CLASSPATH的值的后面加入：%CATALINA_HOME%\common\lib;
在系统变量Path的值中"%JAVA_HOME%\bin;"的后面加入以下内容：%CATALINA_HOME%\bin;

到这里，Tomcat安装完毕。

相关链接：
Tomcat 4和Tomcat 5安装配置指南
Tomcat 5.5安装配置指南

进行完一、二两步的设置以后，各系统变量的值如下：

JAVA_HOME:C:\Program Files\Java\jdk1.5.0_06
CATALINA_HOME:D:\jakarta-tomcat-5.0.30
CLASSPATH:.;%JAVA_HOME%\lib;%CATALINA_HOME%\common\lib;
Path:%JAVA_HOME%\bin;%CATALINA_HOME%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem

三、安装Eclipse
首先下载eclipse-SDK-3.1.2-win32.zip（eclipse-SDK-3.1.2-win32.zip下载地址为：
http://www.eclipse.org/downloads/）；
然后将eclipse-SDK-3.1.2-win32.zip直接解压到D盘根目录：

到这里， Eclipse安装完毕。

四、安装MyEclipse
首先下载EnterpriseWorkbenchInstaller_4.1.1GA_E3.1.exe（EnterpriseWorkbenchInstaller_4.1.1GA_E3.1.exe 的下载地址为：
http://www.myeclipseide.com/ContentExpress-display-ceid-10.html）；
然后安装EnterpriseWorkbenchInstaller_4.1.1GA_E3.1.exe。注意：当安装到下图所示的步骤的时候要选择Eclipse的安装路径（如图），其他选项保持默认。

安装完毕之后，将MyEclipse安装目录下的features和plugins这2个