转载自：http://hi.baidu.com/parryblog/blog/item/2d1ae59a72b043bcc9eaf4a0.html
本篇开始之前先扯点闲话，商业应用系统开发经历了三个阶段：
第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。90年代的大学课程讲的都是这些。
第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。
第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。这也就是现在的面象对象分析模式。
使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全了解了用户需求，可以进入系统建模阶段了。
书归正传，上篇笔者归纳了一些典型的涉众类型及他们的普遍期望。接下来，就是要将他们这些期望定义出来。这个过程，就是业务用例获取的过程。笔者可以跟大家分享的经验是通过以下步骤进行，这些步骤并非唯一正确，对于经验不多的系统分析员来说，这些步骤很有指导意义。
笔者做了一个建模实例，有需要有读者请到笔者的BLOG资源中心下载，实例以上一篇所述网上图书馆需求为蓝本建立了业务用例模型，之后的概念模型、系统模型则抽取了其中的借阅过程作为例子。不记得了可以后头找找。
建模第一步，从涉众中找出用户。并定义这些用户之间的关系。在ROSE中，应该使用business actor 类型。参考上一篇的需求描述，下载实例
第二步，找出每个用户要做的事，即业务用例，在ROSE中应使用Business use case类型。请参考《用例的类型与粒度》一文以帮助确定用例的粒度。笔者强烈建议为每一个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的参与者的担心，可以在第四步中得到消除。下载实例
第三步，利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图Activity diagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的 business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否 business actor 和 business use case定义不完善或错误。如果不是所有的business actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。下载实例
第四步，绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。笔者仍然强烈推荐使用activity diagram。在用例场景图的绘制中，必须使用第一步中定义的业务用户作为泳道。必须这么做的原因是，它能帮助你发现在定义业务用例图时的错误，比如是否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。下载实例
第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型。应该使用business entity 类型。下载实例
第六步，在上述过程中，随时补充词汇表Glossary。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。
第七步，根据上一篇中提到的业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。那些不打算纳入建设范围内的业务用例有两种情况，一种是该业务用例是被调用一方，那么应该把它改为 boundary 类型，意味着将来它是一个外部接口。另一种是该业务用例主动调用系统内业务用例，那么应该将它改为business actor类型。与普通business actor不同的是，由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的business use case 应当对应的生成一个 business use case realization， 以后的设计工作将归纳到这些实现用例中。但笔者觉得这一步并非很关键的，实际中本人也经常省略这一步，而将协作图，象活动图，类交互图等直接在business usecase下说明。不过本实例中笔者还是按照正规方法来建模的。下载实例
需要说明的是，上述的步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到尾再执行一次。这也是RUP倡导的迭代开发模式。
经过以上的步骤，我们已经建立了一个完整的业务模型。但这决不是建模工作的全部，以上过程只说明了建立一个完整业务模型的过程，不能说这样就建立了一个很好的业务模型。因为上述的过程中并没有提及业务分析过程。分析过程全凭系统分析员的经验，对OO的理解和对行业业务的把握能力，对原始业务模型进行归纳，整理，抽象，重构，以建立一个更高效，合理，扩展性更强的模型。这个过程无法以步骤说明。或许以后笔者会专门针对模型分析写点东西。另外除了模型，还至少需要写业务架构文档、用例规约和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构，但很不好表达业务规则和非业务需求，这些需要在文档中说明。例如用例的前置条件和后置条件就是一种业务规则。读者可以在RUP文档中找到这些文档的模板。
将处理业务的流程拆分成一个一个链，前面处理完，再派给下一个，类似HTTP中的FILTER
不用安装服务器，内嵌在SPRING容器中，对外支持多种格式的数据，外部系统如要和SPRING INTERGRATION整合，不需要再进行开发
处理流程一般就是，ADAPTER去读取外部数据，转换后放到CHANNEL中，ENDPOINT处理CHANNEL中的数据，委派给下一个CHANNEL，下一个ENDPOINT处理，通过ADAPTER写到外部接口中。
- ADAPTER
外部系统与CHANNEL之间的桥梁，获取外部数据将其放到CHANNEL去，有FTP，JMS，文件系统的
CHANNEL
里面放MESSAGE对象，MESSAGE里面可以放自定义对象，以提供消费者使用
ENDPOINT
CHANNEL的消费者，CHANNEL与ENDPOINT是一对一的关系，所以如果想在一个CHANNE下对应多个ENDPOINT，是做不到的，只能增加CHANNEL
Service Activators：从INPUT CHANNEL中取出一个对象作为参数，调用设置的POJO的方法，将结果放到OUTPUT CHANNEL中
Transformers：对CHANNEL中的对象进行类型转换
决定流向的ENDPOINT：Routers，SPLITER
- 例子
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/integration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:stream="http://www.springframework.org/schema/integration/stream"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/integration
http://www.springframework.org/schema/integration/spring-integration.xsd
http://www.springframework.org/schema/integration/stream
http://www.springframework.org/schema/integration/stream/spring-integration-stream.xsd">
<gateway id="cafe" service-interface="org.springframework.integration.samples.cafe.Cafe"/>
<channel id="orders"/>
<!-- 此处orders里面的对象是一个一个Message，调用payload则取到Order
调用items则得到OrderItem List，拆分成OrderItem以一个为单位放到
drinks中
-->
<splitter input-channel="orders" expression="payload.items" output-channel="drinks"/>
<channel id="drinks"/>
<!-- 此处drinks里面的对象是一个一个OrderItem，调用iced则取到布尔值
如果是true则放到coldDrinks中，如是false则放到hotDrinks中
-->
<router input-channel="drinks" expression="payload.iced ? 'coldDrinks' : 'hotDrinks'"/>
<channel id="coldDrinks">
<queue capacity="10"/>
</channel>
<service-activator input-channel="coldDrinks" ref="barista" method="prepareColdDrink" output-channel="preparedDrinks"/>
<channel id="hotDrinks">
<queue capacity="10"/>
</channel>
<!-- 将输入通道中的OrderItem转成Drink -->
<service-activator input-channel="hotDrinks" ref="barista" method="prepareHotDrink" output-channel="preparedDrinks"/>
<channel id="preparedDrinks"/>
<!-- 将通道中的Drink按一个Order进行合并成一个List<Order>-->
<aggregator input-channel="preparedDrinks" method="prepareDelivery" output-channel="deliveries">
<beans:bean class="org.springframework.integration.samples.cafe.xml.Waiter"/>
</aggregator>
<stream:stdout-channel-adapter id="deliveries"/>
<beans:bean id="barista" class="org.springframework.integration.samples.cafe.xml.Barista"/>
<poller id="poller" default="true" fixed-delay="1000"/>
</beans:beans>
Hibernate Tools是由JBoss推出的一个Eclipse综合开发工具插件，该插件可以简化ORM框架Hibernate，以及JBoss Seam，EJB3等的开发工作。Hibernate Tools可以以Ant Task以及Eclipse插件的形式运行。
Hibernate Tools Eclipse插件的特征
Hibernate Tools Eclipse插件具有以下特征或功能：
Mapping Editor（映射文件编辑器）：该编辑器可以用来编辑Hibernate XML映射文件，提供代码自动补全，语法高亮功能。
- 类名的自动补全
- 属性/表的列名自动补全
Hibernate Console（Hibernate控制台）：它提供一个全新的Eclipse Perspective窗口，可以执行HQL，并查看查询的结果。这是一个非常便利的工具，可以用来验证HQL的语法是否正确。
Configuration Wizards and Code generation（Hibernate配置文件hibernate.cfg.xml创建导航，以及代码生成器）：支 持完全反向生成功能，可以从已有的数据库生成Hibernate配置文件hibernate.cfg.xml，同时支持"click-and- generate"方式生成Java代码(Hibernate POJOs)，DAO，XML映射文件（.hbm.xml），以及schema 文档（.hml）等文件。
Eclipse JDT integration（代码补全）：该工具支持Java代码中的HQL输入补全，以及对Java代码中的HQL语法加以合法性验证。
Hibernate Tools的使用
- Hibernate的配置文件hibernate.cfg.xml的生成 步骤：
1）Eclipse的菜单：选择[File] -> [New] -> [Other] -> [Hibernate/Hibernate Configuration file (cfg.xml) ]，“Next”按钮
2）输入 [Database dialect] ，[Driver Class]，[Connection URL]，以及[DB用户名]，[密码]等
3）按下[Finish]按钮，则自动生成hibernate.cfg.xml文件。
** "Create Console Configuration" checkbox默认为选择状态。被选择的情况下，则进入“Hibernate Console Configuration ”（Hibernate Console）设置/创建页面。
- 设置Hibernate Console Hibernate Tools支持创建多个Hibernate Console。
1）Eclipse菜单：选择[File] -> [New] -> [Other] -> [Hibernate/Hibernate Console Configuration]，“Next”按钮
2）在所显示的画面上输入Hibernate Console的名称[Name]，目标项目名[Project]，Hibernate配置文件（hibernate.cfg.xml）的路径[Configuration file]
3）按[Finish]按钮，则创建Hibernate Console，同时显示在"Hibernate Configurations"视图中。
- Reverse engineering and code generation：利用"click-and-generate" Reverse Engineering以及代码生成功能自动生成所需代码。
※使用Hibernate code generation（Hibernate代码生成器）之前，需要先配置/创建Hibernate Console。
1）可以从Hibernate 的Tool Bar，或"Run/Hibernate Code Generation"菜单启动Hibernate代码生成器。
2）在所显示的画面上，输入 创建好的Hibernate控制台名称[Console Configuration]，输出路径「Output directory」等信息。
** 其它可以实际情况加以设置。
3）打开Explore标签，设置需要生成的代码类型（Domain code, DAO等）
4）设置完成之后，按下[Run]按钮
根据不同的配置，将自动生成Hibernate关联文件，EJB3，JBoss Seam等文件。
Hibernate Tools其它参考资料
Hibernate Tools Reference Guide [官方文档]
Hibernate Tools Eclipse Plugins [官方文档，Hibernate Tools Eclipse插件]
完善api-doc，用eclipse生成javadoc的时候发生“编码 GBK 的不可映射字符 ”，很是恼火。其实是字符编码问题。
打开eclipse，project -> Generate javadoc 一项一项的选你要输出javadoc的项目，在VM设置中加入以下代码 -encoding utf-8 -charset utf-8
这次操作，输出的html代码不会发生“编码 GBK 的不可映射字符 ”问题，而且html字符编码都设为了UTF-8，问题彻底解决。
对应的ant target 如下
<target name="javadoc">
<echo>+---------------------------------------------------+</echo>
<echo>| Building Doc File |</echo>
<echo>+---------------------------------------------------+</echo>
<javadoc access="protected"
additionalparam="-encoding utf-8 -charset utf-8 "
author="true"
classpath="${classes.dir}"
destdir="${doc.dir}/api"
nodeprecated="false"
nodeprecatedlist="false"
noindex="false"
nonavbar="false"
notree="false"
packagenames="org.xxx.common.web.tag.go"
source="1.6"
sourcepath="${src.dir}"
splitindex="true"
use="true"
version="true"
>
<link href="http://java.sun.com/javase/6/docs/api/" />
</javadoc>
</target>
WEB程序调优
1.纯JSP比JSF性能要好
2.树形数据的显示如果用JSF性能要差，不如用低层次的JAVASCRIPT
WEB SERVICE调优
1.性能不太好，尤其依赖于传输的SOAP大小，因为在XML与JAVA OBJECT的转换中消耗太多
2.加缓存在SOAP上
3.JBOSS的WEB SERVICE有三个实现，原生的、CXF和METRO，性能最好的是METRO，最差是原生的
JBOSS中的TOMCAT调优
1.CONNECTOR参数
当进入JBOSS的请求到达maxThreads，且又高于acceptCount的时候，用户就会收到Connection refused的错误信息，当HTTP请求的线程空闲了maxIdleTime时，系统就会杀掉这些线程，直到到达minSpareThreads数为止
2.如何计算程序就需的线程数
CPU数*200，如4核的设800
可以通过域名为jboss.web，name=http-127.0.0.1-8080,type=ThreadPool的MBEAN观察实际的线程数
3.处理周期长的WEB线程
WEB线程处理请求时，并不会马上结束，还会继续传递到EJB层，这样如果EJB层处理周期长，会导致WEB层请求数增长来处理新进来的请求
4.如何增大线程最大处理数
这完全依赖于CPU、RAM和SOCKET数
5.使用APACHE PORTABLE RUNTIME
增加APR包能提高性能20%，如果是WINDOWS系统则不建议
6.整合APACHE WEBSERVER与JBOSS SERVER
使用APACHE WEBSERVER作为JBOSS的前端，以达到HA的效果，又能提高20%的性能
结合方式是使用mod_jk mod_proxy_ajp mod_proxy_http
7.三种方式的比较
mod_proxy_ajp要高于其他两种
8.引入mod_cluster
9.web.xml中关于JSP的调优
development=false，避免访问前的检查
checkInterval=0，避免JSP需要重新编译
trimSpaces=true，删除JSP中的空格
genStringAsCharArray=true
JBOSS中SERVICE的调优
SESSION BEAN
1.stateless session bean在池中数量大小的配置
每建一个SESSION BEAN，就会在jboss.j2ee域下建一个MBEAN，通过查看其信息得知BEAN的处理统计时间来调整BEAN数量大小，配置文件：/deploy/ejb3-interceptors-aop.xml
2.stateful session bean
SFSB是被JBOSS缓存在容器中，因此客户端的每个请求都会立即响应，同样也是通过SLSB的方式查看并调整CACHE的数量大小
3.SFSB与 SLSB的比较
SFSB性能要差10%
4.事务
EJB与普通RMI SERVICE相比，就是有完整的事务支持，如果EJB采用CMT，则可以保证其方法是在全局的事务上下文中被执行的，但开启事务的成本太高，如果不需用到事务的方法需将事务关闭
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)5.自定义EJB容器
JBOSS是以拦截器的方式运行EJB的，如果EJB中不需要事务的支持，可将这个INTERCEPTOR注释掉
<interceptor-ref name="org.jboss.aspects.
tx.TxPropagationInterceptor"/> 6.比较软的方式自定义EJB容器
将定义写在新的XML文件中，以覆盖原先的设定
<?xml version="1.0" encoding="UTF-8"?>
<aop xmlns="urn:jboss:aop-beans:1.0">
<domain name="Non Tx Stateless Bean" extends="Intercepted Bean"
inheritBindings="false">
<bind pointcut="execution(public * *->*(..))">
<interceptor-ref name="org.jboss.ejb3.stateless.
StatelessInstanceInterceptor"/>
<interceptor-ref name="org.jboss.ejb3.
AllowedOperationsInterceptor"/>
<stack-ref name="EJBInterceptors"/>
</bind>
</domain>
</aop>JMS
1.基本概念
JMS provider：JMS系统
Messages：客户端交流的载体
Connection factories：产生链接的工厂
Destinations:有Queues和Topics
Queues：含有一堆Messag的队列，只能发给一个客户端
Topics：可以发给多个客户端
JMS clients：生产和消费Message的东西
MDB：一个特殊的consumer
2.JMS架构
如果客户端和服务器端同一个JBOSS，则通过JCA作通讯，通过调整deploy/jca-jboss-beans.xml中的WorkManagerThreadPool的参数来调优,
如果不在一个JBOSS内，则通过远程框架进行通讯，通过调整deploy\messaging\remoting-bisocket-service.xml中的org.jboss.remoting.transport.Connector里的参数大小来调优
3.调优JBoss Messaging Connectionfactory
deploy\messaging\connection-factories-service.xml
4.调优JBoss Messaging destinations
在deploy/messaging中增加*–service.xml文件，从而增加MBEAN，来增加队列，再调整其参数
5.HornetQ
是JBOSS 6.0之后的JMS服务器，没有依赖于任何JBOSS包，可以嵌于任何程序中。
调优主要针对deploy/hornetq/hornetq-configuration.xml文件中的journal和transport参数
journal:journal-directory-存放message的地方，如果与其他文件夹共享，则会降低性能；journal-min-files：生成文件的个数，如果发现新文件建立的次数非常频繁，则考虑加大此数值来避免
6.JMS调优基本原则
减少message的大小；使用DUPS_OK_ACKNOWLEDGE；重用JMS资源，如connections, sessions, consumers, and producers；可以不持久化message的就不持久化。
持久层的调优数据库设计调优
1.减少表所占的空间
这样IO读速度会加快，更少的内存；列的数据类型选少的；表设计要正规化（如果是报表类型的程序则非正规化的表速度要好）
2.数据库分割
如果某个表数据量太大，可将此表按某种逻辑分割成若干个小表，如按月份分成不同的表，不同月份的数据就放于不同的表中；
如果某个表中字段数太多，可将某些字段分组，不同的组建不同的表，如将BLOB类型的字段分割到新表中；
3.增加索引
对查询中用得比较锪WHERE字段做索引，索引数据是被抽出来，进行排序后单独存放的，如果不加索引，排序的动作只能在SQL被执行的时候做；
如果做了索引的字段被修改，则该字段的索引同样也要被修改，重新排序，这也会带来性能问题，因此一个表中最多只能放4－5个索引；
但如果这个表是只读的，则索引可以随意增加；
如果有组合索引，则UNIQUE的，值比较大的字段放在前面会比较好；
索引可以加在HIBERNATE的注释中
JDBC的调优
1. 使用链接池来链接数据库
数据链接的建立和关闭是一个非常昂贵的操作，能重用就重用，客户端从PreparedStatement Cache中取得对象，PreparedStatement再从链接池中取得链接，从而得以进行对数据库的操作
2.设置正确的fetch大小
如果设置了fetch大小为100，则JDBC会从数据库中取回100条记录，这样从ResultSet中读取next()是，是从内存中返回数据，超过了100再从数据库中取100以备用；
此数值一般设为当次查询总量的一半或1/4，但如果随便设高，性能反而下降；
JBOSS中设置全局大小：<connection-property name="defaultFetchSize">50</
connection-property>
3.INSERT和UPDATE使用批量操作
4.使用PreparedStatement而不使用Statement
PreparedStatement能避免SQL语句重复解释；使用PreparedStatement cache来缓存PreparedStatement对象
5.JDBC网络调优
<connection-property name="tcpSndBuf">65534</connection-property>
<connection-property name="tcpRcvBuf">65534</connection-property>
<connection-property name="tcpNoDelay">true</connection-property> JPA/HIBERNATE调优
使用JDBC的限制:
由于是使用了原生的SQL语句，但不同的数据库SQL语句也是不同的，如果换数据库的时候SQL语句改动量大；
多表关联时，需维护JAVA OBJECT与数据表的对应关系；
加缓存时，工作量也比较大。
JPA与HIBERNATE的区别：JPA是JAVA的一个标准，HIBERNATE是JPA的一个实现
1.优化对象获取
HIBERNATE的N+1总量，如果有两个表是一对多的关系，查询父表的时候，子表的数据是不会被查出来的，直到调用查询子表的方法时子表的数据才被查出来，因此而多出一个SQL语句
使用LEFT OUTER JOIN来达到只用一个SQL语句就查出父表和子表的数据
Query q = entityManager.createQuery("from Customer c left outer join
fetch c.items order by c.id"); 2.以分页的方式限制一次性获取数据的数量
q.setFirstResult(page*100).setMaxResults(100); 3.不能同时使用分页和FETCH的方式
HIBERNATE的分页，是首先取出所有的数据再在内存中分页，以避免不同数据库中分页语句的不同
4.使用BatchSize
@BatchSize(size = 50)
加载相关联的实体集合的个数，注意个数的对象是集合，不是集合里的单个元素
5.使用named queries作查询
这样会使用到PreparedStatement中的绑定参数
6.使用批量更新与插入
Session session =HibernateUtil.getSessionFactory().openSession();
session.beginTransaction();
for (int index = 0; index <1000;index++) 
{
Person person = new Person();
book.setCountry("Usa");
book.setCity("NY");
person.setName("Inhabitant n." + index);
session.save(person);
// Flush every 50 records
if (index % 50== 0) {
session.flush();
session.clear();
}
}
session.getTransaction().commit();
session.close(); 7.使用HIBERNATE CACHE
一级缓存，在SESSION关闭前都可以使用；
二级缓存，HIBERNATE使用第三方CACHE框架来做缓存
<property name="hibernate.cache.use_second_level_cache"
value="true"/>
<property name="hibernate.cache.region.factory_class"
value="org.hibernate.cache.jbc2.
JndiMultiplexedJBossCacheRegionFactory"/>
<property name="hibernate.cache.region.jbc2.cachefactory"
value="java:CacheManager"/>
<property name="hibernate.cache.region.jbc2.cfg.entity"
value="mvcc-entity"/>
<property name="hibernate.cache.region.jbc2.cfg.collection"
value="mvcc-entity"/> 启用缓存
@Entity
@Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL, region =
"customers")
public class Customer implements Serializable {
} 查询缓存
<property name="hibernate.cache.use_query_cache" value="true"/> 启用查询缓存
@NamedQueries(
{
@NamedQuery(
name = "findCustomersByName",
query = "FROM Customer c WHERE c.name = :name",
hints = { @QueryHint(name = "org.hibernate.cacheable", value =
"true") }
) 使用缓存的策略：静态数据可以考虑，但查询和更新频率很高的、查询条件非常复杂的不建议用