#
用sonar来管理我们的代码并提高我们的代码质量，他能把cobertura，checkstyle，findbugs较为完美的结合起来，主要产生的报告特别漂亮，而且有其参考性。
http://docs.codehaus.org/display/SONAR/Install+Sonar
本文为大家介绍软件设计中的一些原则，都是经过长期经验总结出来的知识，每一个程序员都应该了解，相信对大家在进行软件设计的过程中会有很大帮助。
Don’t Repeat Yourself (DRY)
DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。
参考：
http://en.wikipedia.org/wiki/KISS_principle
Program to an interface, not an implementation
这是设计模式中最根本的哲学，注重接口，而不是实现，依赖接口，而不是实现。接口是抽象是稳定的，实现则是多种多样的。以后面我们会面向对象的SOLID原则中会提到我们的依赖倒置原则，就是这个原则的的另一种样子。还有一条原则叫 Composition over inheritance（喜欢组合而不是继承），这两条是那23个经典设计模式中的设计原则。
Command-Query Separation (CQS) – 命令-查询分离原则
查询：当一个方法返回一个值来回应一个问题的时候，它就具有查询的性质；
命令：当一个方法要改变对象的状态的时候，它就具有命令的性质；
通常，一个方法可能是纯的Command模式或者是纯的Query模式，或者是两者的混合体。在设计接口时，如果可能，应该尽量使接口单一化，保证方法的行为严格的是命令或者是查询，这样查询方法不会改变对象的状态，没有副作用，而会改变对象的状态的方法不可能有返回值。也就是说：如果我们要问一个问题，那么就不应该影响到它的答案。实际应用，要视具体情况而定，语义的清晰性和使用的简单性之间需要权衡。将Command和Query功能合并入一个方法，方便了客户的使用，但是，降低了清晰性，而且，可能不便于基于断言的程序设计并且需要一个变量来保存查询结果。
在系统设计中，很多系统也是以这样原则设计的，查询的功能和命令功能的系统分离，这样有则于系统性能，也有利于系统的安全性。
参考：
http://en.wikipedia.org/wiki/Command-query_separation
You Ain’t Gonna Need It (YAGNI)
这个原则简而言之为——只考虑和设计必须的功能，避免过度设计。只实现目前需要的功能，在以后您需要更多功能时，可以再进行添加。
如无必要，勿增复杂性。
软件开发先是一场沟通博弈。
以前本站有一篇关于
过度重构的文章，这个示例就是这个原则的反例。而，WebSphere的设计者就
表示过他过度设计了这个产品。我们的程序员或是架构师在设计系统的时候，会考虑很多扩展性的东西，导致在架构与设计方面使用了大量折衷，最后导致项目失败。这是个令人感到讽刺的教训，因为本来希望尽可能延长项目的生命周期，结果反而缩短了生命周期。
参考：
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
Law of Demeter – 迪米特法则
迪米特法则(Law of Demeter)，又称“最少知识原则”（Principle of Least Knowledge），其来源于1987年荷兰大学的一个叫做Demeter的项目。Craig Larman把Law of Demeter又称作“不要和陌生人说话”。在《程序员修炼之道》中讲LoD的那一章叫作“解耦合与迪米特法则”。关于迪米特法则有一些很形象的比喻：
如果你想让你的狗跑的话，你会对狗狗说还是对四条狗腿说？
如果你去店里买东西，你会把钱交给店员，还是会把钱包交给店员让他自己拿？
和狗的四肢说话？让店员自己从钱包里拿钱？这听起来有点荒唐，不过在我们的代码里这几乎是见怪不怪的事情了。
对于LoD，正式的表述如下：
在《Clean Code》一书中，有一段Apache framework中的一段违反了LoD的代码：
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
这么长的一串对其它对象的细节，以及细节的细节，细节的细节的细节……的调用，增加了耦合，使得代码结构复杂、僵化，难以扩展和维护。
在《重构》一书中的代码的环味道中有一种叫做“Feature Envy”(依恋情结），形象的描述了一种违反了LoC的情况。Feature Envy就是说一个对象对其它对象的内容更有兴趣，也就是说老是羡慕别的对象的成员、结构或者功能，大老远的调用人家的东西。这样的结构显然是不合理的。我们的程序应该写得比较“害羞”。不能像前面例子中的那个不把自己当外人的店员一样，拿过客人的钱包自己把钱拿出来。“害羞”的程序只和自己最近的朋友交谈。这种情况下应该调整程序的结构，让那个对象自己拥有它羡慕的feature，或者使用合理的设计模式（例如Facade和Mediator）。
参考：
http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge
面向对象的S.O.L.I.D 原则
一般来说这是面向对象的五大设计原则，但是，我觉得这些原则可适用于所有的软件开发。
Single Responsibility Principle (SRP) – 职责单一原则
关于单一职责原则，其核心的思想是：
一个类，只做一件事，并把这件事做好，其只有一个引起它变化的原因。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为一个模块实现过多的功能点，以保证实体只有一个引起它变化的原因。
Unix/Linux是这一原则的完美体现者。各个程序都独立负责一个单一的事。
Windows是这一原则的反面示例。几乎所有的程序都交织耦合在一起。
Open/Closed Principle (OCP) – 开闭原则
关于开发封闭原则，其核心的思想是：模块是可扩展的，而不可修改的。也就是说，
对扩展是开放的，而对修改是封闭的。
对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。
对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。
对于面向对象来说，需要你依赖抽象，而不是实现，23个经典设计模式中的“策略模式”就是这个实现。对于非面向对象编程，一些API需要你传入一个你可以扩展的函数，比如我们的C 语言的qsort()允许你提供一个“比较器”，STL中的容器类的内存分配，ACE中的多线程的各种锁。对于软件方面，浏览器的各种插件属于这个原则的实践。
Liskov substitution principle (LSP) – 里氏代换原则
软件工程大师Robert C. Martin把里氏代换原则最终简化为一句话：“Subtypes must be substitutable for their base types”。也就是，子类必须能够替换成它们的基类。即：子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。另外，不应该在代码中出现if/else之类对子类类型进行判断的条件。里氏替换原则LSP是使代码符合开闭原则的一个重要保证。正是由于子类型的可替换性才使得父类型的模块在无需修改的情况下就可以扩展。
这么说来，似乎有点教条化，我非常建议大家看看这个原则个两个最经典的案例——“正方形不是长方形”和“鸵鸟不是鸟”。通过这两个案例，你会明白《墨子 小取》中说的 ——“娣，美人也，爱娣，非爱美人也….盗，人也；恶盗，非恶人也。”——妹妹虽然是美人，但喜欢妹妹并不代表喜欢美人。盗贼是人，但讨厌盗贼也并不代表就讨厌人类。
这个原则让你考虑的不是语义上对象的间的关系，而是实际需求的环境。
在很多情况下，在设计初期我们类之间的关系不是很明确，LSP则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。
Interface Segregation Principle (ISP) – 接口隔离原则
接口隔离原则意思是把功能实现在接口中，而不是类中，使用多个专门的接口比使用单一的总接口要好。
举个例子，我们对电脑有不同的使用方式，比如：写作，通讯，看电影，打游戏，上网，编程，计算，数据等，如果我们把这些功能都声明在电脑的抽类里面，那么，我们的上网本，PC机，服务器，笔记本的实现类都要实现所有的这些接口，这就显得太复杂了。所以，我们可以把其这些功能接口隔离开来，比如：工作学习接口，编程开发接口，上网娱乐接口，计算和数据服务接口，这样，我们的不同功能的电脑就可以有所选择地继承这些接口。
这个原则可以提升我们“搭积木式”的软件开发。对于设计来说，Java中的各种Event Listener和Adapter，对于软件开发来说，不同的用户权限有不同的功能，不同的版本有不同的功能，都是这个原则的应用。
Dependency Inversion Principle (DIP) – 依赖倒置原则
高层模块不应该依赖于低层模块的实现，而是依赖于高层抽象。
举个例子，墙面的开关不应该依赖于电灯的开关实现，而是应该依赖于一个抽象的开关的标准接口，这样，当我们扩展程序的时候，我们的开关同样可以控制其它不同的灯，甚至不同的电器。也就是说，电灯和其它电器继承并实现我们的标准开关接口，而我们的开关产商就可不需要关于其要控制什么样的设备，只需要关心那个标准的开关标准。这就是依赖倒置原则。
这就好像浏览器并不依赖于后面的web服务器，其只依赖于HTTP协议。这个原则实在是太重要了，社会的分工化，标准化都是这个设计原则的体现。
参考：
http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
Common Closure Principle（CCP）– 共同封闭原则
一个包中所有的类应该对同一种类型的变化关闭。一个变化影响一个包，便影响了包中所有的类。一个更简短的说法是：一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。CCP原则就是把因为某个同样的原因而需要修改的所有类组合进一个包里。如果2个类从物理上或者从概念上联系得非常紧密，它们通常一起发生改变，那么它们应该属于同一个包。
CCP延伸了开闭原则（OCP）的“关闭”概念，当因为某个原因需要修改时，把需要修改的范围限制在一个最小范围内的包里。
参考：
http://c2.com/cgi/wiki?CommonClosurePrinciple
Common Reuse Principle (CRP) – 共同重用原则
包的所有类被一起重用。如果你重用了其中的一个类，就重用全部。换个说法是，没有被一起重用的类不应该被组合在一起。CRP原则帮助我们决定哪些类应该被放到同一个包里。依赖一个包就是依赖这个包所包含的一切。当一个包发生了改变，并发布新的版本，使用这个包的所有用户都必须在新的包环境下验证他们的工作，即使被他们使用的部分没有发生任何改变。因为如果包中包含有未被使用的类，即使用户不关心该类是否改变，但用户还是不得不升级该包并对原来的功能加以重新测试。
CCP则让系统的维护者受益。CCP让包尽可能大（CCP原则加入功能相关的类），CRP则让包尽可能小（CRP原则剔除不使用的类）。它们的出发点不一样，但不相互冲突。
参考：
http://c2.com/cgi/wiki?CommonReusePrinciple
Hollywood Principle – 好莱坞原则
好莱坞原则就是一句话——“don’t call us, we’ll call you.”。意思是，好莱坞的经纪人们不希望你去联系他们，而是他们会在需要的时候来联系你。也就是说，所有的组件都是被动的，所有的组件初始化和调用都由容器负责。组件处在一个容器当中，由容器负责管理。
简单的来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓“控制反转”的概念所在：
1.不创建对象，而是描述创建对象的方式。
2.在代码中，对象与服务没有直接联系，而是容器负责将这些联系在一起。
控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。
好莱坞原则就是IoC（Inversion of Control）或DI（Dependency Injection ）的基础原则。这个原则很像依赖倒置原则，依赖接口，而不是实例，但是这个原则要解决的是怎么把这个实例传入调用类中？你可能把其声明成成员，你可以通过构造函数，你可以通过函数参数。但是 IoC可以让你通过配置文件，一个由Service Container 读取的配置文件来产生实际配置的类。但是程序也有可能变得不易读了，程序的性能也有可能还会下降。
参考：
[url]http://en.wikipedia.org/wiki/Hollywood_Principle [/url]
[url]http://en.wikipedia.org/wiki/Inversion_of_Control [/url]
High Cohesion & Low/Loose coupling & – 高内聚， 低耦合
这个原则是UNIX操作系统设计的经典原则，把模块间的耦合降到最低，而努力让一个模块做到精益求精。
内聚：一个模块内各个元素彼此结合的紧密程度
耦合：一个软件结构内不同模块之间互连程度的度量
内聚意味着重用和独立，耦合意味着多米诺效应牵一发动全身。
参考：
http://en.wikipedia.org/wiki/Coupling_(computer_science)
[url]http://en.wikipedia.org/wiki/Cohesion_(computer_science) [/url]
Convention over Configuration（CoC）– 惯例优于配置原则
简单点说，就是将一些公认的配置方式和信息作为内部缺省的规则来使用。例如，Hibernate的映射文件，如果约定字段名和类属性一致的话，基本上就可以不要这个配置文件了。你的应用只需要指定不convention的信息即可，从而减少了大量convention而又不得不花时间和精力啰里啰嗦的东东。配置文件很多时候相当的影响开发效率。
Rails 中很少有配置文件（但不是没有，数据库连接就是一个配置文件），Rails 的fans号称期开发效率是 java 开发的 10 倍，估计就是这个原因。Maven也使用了CoC原则，当你执行mvn -compile命令的时候，不需要指源文件放在什么地方，而编译以后的class文件放置在什么地方也没有指定，这就是CoC原则。
参考：
http://en.wikipedia.org/wiki/Convention_over_Configuration
Separation of Concerns (SoC) – 关注点分离
SoC 是计算机科学中最重要的努力目标之一。这个原则，就是在软件开发中，通过各种手段，将问题的各个关注点分开。如果一个问题能分解为独立且较小的问题，就是相对较易解决的。问题太过于复杂，要解决问题需要关注的点太多，而程序员的能力是有限的，不能同时关注于问题的各个方面。正如程序员的记忆力相对于计算机知识来说那么有限一样，程序员解决问题的能力相对于要解决的问题的复杂性也是一样的非常有限。在我们分析问题的时候，如果我们把所有的东西混在一起讨论，那么就只会有一个结果——乱。
我记得在上一家公司有一个项目，讨论就讨论了1年多，项目本来不复杂，但是没有使用SoC，全部的东西混为一谈，再加上一堆程序员注入了各种不同的观点和想法，整个项目一下子就失控了。最后，本来一个1年的项目做了3年。
实现关注点分离的方法主要有两种，一种是标准化，另一种是抽象与包装。标准化就是制定一套标准，让使用者都遵守它，将人们的行为统一起来，这样使用标准的人就不用担心别人会有很多种不同的实现，使自己的程序不能和别人的配合。Java EE就是一个标准的大集合。每个开发者只需要关注于标准本身和他所在做的事情就行了。就像是开发镙丝钉的人只专注于开发镙丝钉就行了，而不用关注镙帽是怎么生产的，反正镙帽和镙丝钉按标来就一定能合得上。不断地把程序的某些部分抽像差包装起来，也是实现关注点分离的好方法。一旦一个函数被抽像出来并实现了，那么使用函数的人就不用关心这个函数是如何实现的，同样的，一旦一个类被抽像并实现了，类的使用者也不用再关注于这个类的内部是如何实现的。诸如组件，分层，面向服务，等等这些概念都是在不同的层次上做抽像和包装，以使得使用者不用关心它的内部实现细节。
说白了还是“高内聚，低耦合”。
参考：
http://sulong.me/archives/99
Design by Contract (DbC) – 契约式设计
DbC的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。例如：
供应商必须提供某种产品（责任），并且他有权期望客户已经付款（权利）。
客户必须付款（责任），并且有权得到产品（权利）。
契约双方必须履行那些对所有契约都有效的责任，如法律和规定等。
同样的，如果在程序设计中一个模块提供了某种功能，那么它要：
期望所有调用它的客户模块都保证一定的进入条件：这就是模块的先验条件（客户的义务和供应商的权利，这样它就不用去处理不满足先验条件的情况）。
保证退出时给出特定的属性：这就是模块的后验条件——（供应商的义务，显然也是客户的权利）。
在进入时假定，并在退出时保持一些特定的属性：不变式。
契约就是这些权利和义务的正式形式。我们可以用“三个问题”来总结DbC，并且作为设计者要经常问：
它期望的是什么？
它要保证的是什么？
它要保持的是什么？
根据Bertrand Meyer氏提出的DBC概念的描述，对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等，只有前提条件得到满足时，这个方法才能被调用；同时后续条件用来说明这个方法完成时的状态，如果一个方法的执行会导致这个方法的后续条件不成立，那么这个方法也不应该正常返回。
现在把前提条件以及后续条件应用到继承子类中，子类方法应该满足：
1.前提条件不强于基类．
2.后续条件不弱于基类．
换句话说，通过基类的接口调用一个对象时，用户只知道基类前提条件以及后续条件。因此继承类不得要求用户提供比基类方法要求的更强的前提条件，亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。同样，继承类必须顺从基类的所有后续条件，亦即，继承类方法的行为和输出不得违反由基类建立起来的任何约束，不能让用户对继承类方法的输出感到困惑。
这样，我们就有了基于契约的LSP，基于契约的LSP是LSP的一种强化。
参考：
http://en.wikipedia.org/wiki/Design_by_contract
Acyclic Dependencies Principle (ADP) – 无环依赖原则
包之间的依赖结构必须是一个直接的无环图形，也就是说，在依赖结构中不允许出现环（循环依赖）。如果包的依赖形成了环状结构，怎么样打破这种循环依赖呢？有2种方法可以打破这种循环依赖关系：第一种方法是创建新的包，如果A、B、C形成环路依赖，那么把这些共同类抽出来放在一个新的包D里。这样就把C依赖A变成了C依赖D以及A依赖D，从而打破了循环依赖关系。第二种方法是使用DIP（依赖倒置原则）和ISP（接口分隔原则）设计原则。
无环依赖原则（ADP）为我们解决包之间的关系耦合问题。在设计模块时，不能有循环依赖。
参考：
http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple
在使用ExtJs过程中，性能一直是一个比较头疼的问题，从用户的角度来看，就一个字：慢。从技术的角度来说，这个“慢”字可以分为两种，加载“慢”和渲染“慢”。想分辨这两种情况很容易：如果居于网不慢而互联网上慢，说明是加载慢；如果Chrome不慢而IE慢，就是渲染慢。还有另一种情况：越用越慢，这个“慢”通常是内存泄露造成的。
针对以下这三种情况讨论一下解决方案：
1，加载慢
1.1 减少要加载的东西
不要动不动就ext-all.js，extjs是可以定制的，如果你用不到tree，就不要包含这个组件了。ExtJs的官网上有详细的定制方法和工具。
1.2 给出合适的用户提示
把Js后置，然后前面做一个加载的提示。如果像Gmail那样给出进度条，或者像很多网游那样来点图片或者Tips啥的就更好了，说不定用户还会觉得怎么加载这么快，我还没看清楚呢，呵呵。
1.3 用的时候再加载
动态加载，参考使用ExtJs开发MIS系统（2）：Js的动态加载。
1.4 只加载一次
别用iframe了，如果你的静态内容过期做的不好，浏览器会经常再不厌其烦的从服务器下载同样的东西。
1.5 对你的Js添加过期标记
ext-base.js、ext-all.js都可以设置很长的过期时间，甚至永不过期（如果你不换extjs的版本）。这点对所有静态内容都很有用，如何设置过期标记请垂询Google。
2，渲染慢
2.1 少加载少解析、晚加载晚解析
1.1，1.3，1.4都对改善渲染慢的情况有效——加载的少了自然渲染的快了。
2.2 别用iframe
iframe不仅仅可能会使浏览器加载两遍，还一定会使浏览器解析两遍，放弃它吧，真的。
2.3 精心设计你的Js代码
例如缓存getElementByID()的结果、编译查询表达式之类的东西，这个纯看Js功力。
2.4 可能的话，让用户换个浏览器吧
Chrome比IE的Js渲染快是数量级上的差异！构造一个40列，50行的复杂GridPanel试试，你就会深有体会了……对于企业内部的MIS系统，换浏览器还是具有可能性的。
3，内存泄露
Ext性能调优方案
1. 将JS进行合并压缩。
使用yahoo的yui-compress.jar进行压缩JS，去掉过多的空格和注释，并合并，减少IO的支出。
2. 将前后台传输的数据进行GZIP压缩。
大数据量的数据传输，通过GZIP的压缩方案，可以减少到25%，有些数据可能会更多。
3. 对大量的JS分析依赖关系，进行动态加载。
这个是关键，通过分析所有的JS中的依赖关系，减少了JS加载的数量。从很大程度上提高了性能。
4. 另外对部分页面进行缓存，而非真正的关闭。
还有一个外部的因素，由于系统使用的客户机环境上的复杂，我们在多个浏览器上进行了测试，只有IE是最慢的，尤其是IE6，后来发现不是IE6要比IE7慢，是因为发现MS发布了脚本引擎cscript 5.7, 而大部分的ie6系统都装的是5.6, 这个版本上的升级，不仅仅是修改了BUG，在JS的执行速度上也有了较大的提升，于是我们在环境因素上又加上了一条，要求客户安装cscript5.7，也大大的提升了页面的打开时间。
ext-all.js这个文件都有500多k，在页面中直接引用这个js文件是很不现实的，曾经在一个大的项目中使用这个js，则直接导致页面半天出不来的后果。于是自己研究了下，目前通过下面的方法来优化提升Ext Js的性能。
使用JSVM
JSVM (JavaScript Virtual Machine的缩写)，一个JavaScript基础框架，sourceforge开源项目，由万常华（wch3116）于2003年底发起, 目前最新版本是2.05,采用的是 BSD License 授权协议。本身JSVM也提供了JSVM+Ext2的实例，看看就知道怎么在JSVM下加入ext的js库了。
我在项目中是这么用的：
<script type= "text/javascript" src= "/depporject/comjs/jsvm2/jsre.js" classpath= "dom2.gzjs;ext2p.gzjs" modules= "smartloader" ></script>
使用Gzip压缩
gzip压缩后，ext js文件的大小将只有100k左右。
只是对gzip压缩的文件需要提供filter（Java开发），为你的应用提高解压缩功能,filter的写法很简单：
public void doFilter(HttpServletRequest request,
HttpServletResponse response, FilterChain chain)
throws IOException, ServletException 
{
for (Iterator it = headers.entrySet().iterator();it.hasNext();) {
Map.Entry entry = (Map.Entry)it.next();
response.addHeader((String)entry.getKey(),(String)entry.getValue());
}
chain.doFilter(request, response);
}
public void init(FilterConfig config) throws ServletException {
String headersStr = config.getInitParameter( "headers" );
String[] headers = headersStr.split( "," );
for ( int i = 0 ; i < headers.length; i++) {
String[] temp = headers[i].split( "=" );
this .headers.put(temp[ 0 ].trim(), temp[ 1 ].trim());
}
}
}
web.xml配置
< filter >
< filter-name > addHeaderFilter </ filter-name >
< filter-class >org .common.AddHeaderFilter </ filter-class >
< init-param >
< param-name > headers </ param-name >
< param-value > Content-Encoding = gzip </ param-value >
</ init-param >
</ filter >
通过以上两步，整个页面装载速度很快了。大家可以试试。
另外在实际开发中，并不是将ext-all.js全部在jsvm中装载，只是将常用的ext js代码归到一起，由gzip压缩，然后又jsvm装载（即ext2p.js，p代表部分），剩下的ext js代码由jsvm按需装载。
概念解释
在实际的业务中，对于工作流一般是这样定义的：
定义完成某项工作需要多少个环节，每个环节由哪些人处理，完成这项工作的表单。
实际处理的时候，通常由发起人填好表单，然后去找各个环节的负责人签字审批，一直到流程结束。
在JBPM的框架中，用ProcessDefinition来描述某项工作，Activity描述各个定义的环节，Transition描述环节中的路径。
ProcessDefinitionInstance来描述实际执行的工作，可能是继承了ProcessDefinition，但又多出很多属性，如建立时间，发起人等，
Task或Excution来描述实际执行的步骤。
相应地有RespositoryService，ExcutionService，TaskService，来操作ProcessDefinition，Excution，Task，使工作一步步地往定义好的步骤往下走。
Excution表示实际流程中的当前环节，即以前的Token。
编程实务
画好流程图，即定义流程，画好一堆的步骤。
作好每个环节中要展示的JSP页面，并配到流程定义中。
写好每个环节提交后要处理的JAVA代码。
JBPM流程定义
流程定义的中间环节有两种：
一种是流程引擎碰到这种环节，会自动流转到下一环节，如Decision，Java等。
另一种是流程引擎碰到这种环节，会处于等待状态，直到程序下指令如：excuSinal才流转到下一环节，
这里面又分两种：一种是有处理人属性的Task，由处理人决定下一环节的流向，另一种是没设处理人，由程序决定下一环节的走向，如State。
实际流程中可以放变量值，以供整个流程环节存取。
如果流程定义中用了变量或表达式，则其实际值，会取实际流程中放进去的值。
如Task节点：
加一个Task节点时，将assignee设成表达式，这样在生成Task记录时，会读取绑定到流程实例中变量的值，作为assignee的值，
也可以指定一个CLASS，在生成Task记录时，会运行其中的assign方法，读取assignable中的getAssignee()的值，作为Task的分配人。
退回的解决方案
退回就是将此Task退回到上一环节的处理人处。
画图的时候不画退回的路径，但在程序处理中用代码加这一Task指向上一环节的路径，complete(taskId,newTransition)使其回到上一环节，然后再删除这一Transition。
会签的解决方案
会签指的是将同一任务同时分派给多人并行处理。
用For-each和join实现，或动态增加子任务。
1. 流程定义(Process Definition)
流程定义是记录在xml文件中的对流程的描述，它包含唯一的流程开始节点和多个流程功能节点，每个节点之间使用transition进行连接。
Process Definition使用id, key和version进行标识，jBPM中可能包含多个key值相同的Process Definition，key值相同的Process Definition会拥有不同的version值，而id是使用key-version的形式用来表示唯一的Process Definition的。
jBPM中使用RepositoryService来控制流程定义的发布，浏览，删除等操作。
2. 流程实例(Process Instance)
以流程定义为蓝本生成的流程实例，在jBPM属于Execution的一种。
当我们执行start时，会根据流程定义启动一个新的流程实例，然后它会根据流程定义里的节点运行，在遇到state或task时停顿，等待外部用户调用signal，最后会执行到end节点，结束整个流程。
jBPM中只允许有一个start节点，所以每个流程都是单一入口的，jBPM4中可以允许有多个end节点，所以我们可以在任意位置结束流程。
jBPM中使用ExecutionService来控制流程实例的启动，浏览，执行，删除等操作
3. state节点
状态结点是一个典型的等待状态。同任务结点不同的是，状态结点不会向任务列表添加任务实例。当业务进程需要等待外部系统的干预时，这种结点是很有用的。（需要外部系统干预，但又不是让人去干预）假设如下情况：在进入该结点时，通过node-enter事件向外部系统发送一个消息，然后结点进入等待状态；当外部系统完成处理，并回送一个消息，这将导致触发一个signal()方法的运行，该方法重新激活正在等待的流程继续下行
jBPM中使用ExecutionService来控制对state的signal操作。
4. task节点
任务结点（task-node）任务结点是代表由人介入的一个或多个任务。因此当流程运行到一个任务结点时，会生成“任务实例对象（task instances）”，并添加到参与人的任务列表中，之后结点会处于等待状态，直到参与人完成他们的任务，并激活流程继续向下执行。
task节点可以使用assignee, swimelane等方式为任务定义分配到某个人或者某个组，对应的用户可以执行completeTask()结束任务，并控制任务结束后流程实例向哪个方向前进。
jBPM中使用TaskService控制task的各项操作。
5. Identity身份验证
jBPM中的身份验证分为User, Group和Membership三部分，用户表示登陆用户，Group表示用户组，用户和用户组之间的关联关系保存在Membership中。User和Group与Task中的assignee和swimelane是息息相关的。
6.事件
Event反映的是流程执行中的各个时刻。在流程执行中 JBPM引擎会在计算下一个状态的时候触发各种事件。一个事件通常和流程定义中的一个元素相关联，比如流程定义本身，节点或者转移。大部分的元素能够触发不同类型的事件，比如一个节点可以触发节点进入事件，节点离开事件。事件其实是和动作连接在一起的。每个事件维护一个动作列表。当JBPM引擎触发一个事件的时候，该事件维护的动作列表中的动作将被执行。
JBPM中事件类型是写死在事件类中的，共有16种：
EVENTTYPE_TRANSITION = "transition"; // 转移
EVENTTYPE_BEFORE_SIGNAL = "before-signal"; // 发信号前
EVENTTYPE_AFTER_SIGNAL = "after-signal"; // 发信号后
EVENTTYPE_PROCESS_START = "process-start"; // 处理开始状态
EVENTTYPE_PROCESS_END = "process-end"; // 处理结束状态
EVENTTYPE_NODE_ENTER = "node-enter"; // 进入节点
EVENTTYPE_NODE_LEAVE = "node-leave"; // 离开节点
EVENTTYPE_SUPERSTATE_ENTER = "superstate-enter"; // 进入超级状态
EVENTTYPE_SUPERSTATE_LEAVE = "superstate-leave"; // 离开超级状态
EVENTTYPE_SUBPROCESS_CREATED = "subprocess-created"; // 子流程创建
EVENTTYPE_SUBPROCESS_END = "subprocess-end"; // 子流程结束
EVENTTYPE_TASK_CREATE = "task-create"; // 任务创建
EVENTTYPE_TASK_ASSIGN = "task-assign"; // 任务分派
EVENTTYPE_TASK_START = "task-start"; // 任务启动
EVENTTYPE_TASK_END = "task-end"; // 任务结束
EVENTTYPE_TIMER = "timer"; // 定时器
7.transition
关联两个节点，用于表示节点的走向
8.常用类说明
ProcessEngine：它是整个jBPM4的入口，并且是单例模式。通过它可以获取processEngine，并藉此获得工作流引擎所提供的各种服务
RepositoryService：控制流程定义的发布，浏览，删除等操作
ExecutionService：控制流程实例的启动，浏览，执行，删除等操作
IdentityService：控制身份的各项操作
*********************************************************************************************
对jBPM4.3数据库的几张表简单介绍
JBPM4_DEPLOYMENT 流程定义表
JBPM4_DEPLOYPROP 流程定义属性表
JBPM4_EXECUTION 流程实例表
JBPM4_HIST_ACTINST 流程活动(节点)实例表
JBPM4_HIST_DETAIL 流程历史详细表
JBPM4_HIST_PROCINST 流程实例历史表
JBPM4_HIST_TASK 流程任务实例历史表
JBPM4_HIST_VAR 流程变量(上下文)历史表
JBPM4_ID_GROUP 角色表
JBPM4_ID_MEMBERSHIP 用户角色表
JBPM4_ID_USER 用户表
JBPM4_JOB 定时表
JBPM4_LOB 存储表
JBPM4_PARTICIPATION 参与者表
JBPM4_SWIMLANE 泳道表
JBPM4_TASK 任务表
JBPM4_VARIABLE 上下文表
红色的表为经常使用的表.这里不使用JBPM自己的权限角色定义.
发布一个流程deploy后
jbpm4_deployment新增一条记录
jbpm4_deployprop新增三条记录
jbpm4_lob新增一条记录
开始一个流程startProcessInstanceByKey后
jbpm4_execution新增一条记录
jbpm4_hist_actinst新增一条记录
jbpm4_hist_procinst新增一条记录
jbpm4_hist_task新增一条记录
jbpm4_task新增一条记录
流程定义相关的布署信息就存储在（1） JBPM4_DEPLOYMENT、（2） JBPM4_DEPLOYPROP 及（3） JBPM4_LOB 中。上传一个包含png和jpdl.xml的zip包后，JBPM4_DEPLOYMENT多一条记录 JBPM4_DEPLOYPROP多三条， JBPM4_LOB多两条。
（4）J B PM4_HIST_PROCINST 与（5） JBPM4_HIST_ACTINST 分别存放的是Process Instance、Activity Instance的历史记录。
（6）JBPM4_EXECUTION 主要是存放JBPM4的执行信息，Execution机制代替了JBPM3的Token机制（详细参阅JBPM4的PVM机制，过段时间我也会进一步分析）。
（7）JBPM4_TASK 存放需要人来完成的Activities，需要人来参与完成的Activity 被称为Task。
（8）JBPM4_PARTICIPATION 存放Participation的信息，Participation的种类有Candidate、Client、Owner、 Replaced Assignee和Viewer。而具体的Participation既可以是单一用户，也可以是用户组。
（9）JBPM4_SWIMLANE。 Swim Lane是一种Runtime Process Role。通过Swim Lane，多个Task可以一次分配到同一Actor身上。
（10） JBPM4 _VARIABLE 存的是进行时的临时变量。
（11） JBPM4_HIST_DETAIL 保存Variable的变更记录。
（12）JBPM4_HIST_VAR 保存历史的变量 。
（13） JBPM4_HIST_TASK Task的历史信息。
（14）JBPM4_ID_GROUP （15）JBPM_ID_MEMBERSHIP （16）JBPM4_ID_USER 这三张表很常见了，基本的权限控制，关于用户认证方面建议还是自己开发一套，JBPM4的功能太简单了，使用中有很多需要难以满足。
（17） JBPM4_JOB 存放的是Timer的定义。
Repository：内容仓库，提供文件存储和搜索等。
Workspaces：仓库下面分多个Workspaces，以供存放节点。
RootNode：每个Workspace下面只有一个RootNode。
Node：节点，可包含节点或属性对象。
Property：属性对象，可存放对应的文件。
要使用仓库前必须有钥匙，开了门之后，要做存放或检索文件的入口是Session，通过Session新增节点或取得节点。
要上传实体文件，必须将实体文件关联到属性对象，再将属性对象加到节点，再将节点加到根节点中即可。
一个仓库只有一个Session，一个仓库可有多个Workspace，一个Workspace只有一个根节点。
Alfresco选择原因：
支持业界CMS内容管理系统的两大标准：
CMIS：提供了针对于内容仓库的一组标准服务，和JSR-170：对内容仓库进行交互的标准接口集；
Alfresco集群
在集群环境中的Alfresco内容应用服务器的每个结点都可以共享同样的内容仓库存储，尽管存储本身可能根据需要在不同的结点上进行复制。缓存和查询索引也同样是分布式的。
支持备份服务
备份服务器是集群部署的一个特例，当服务器失效后，一个应用服务程序可以切换到备份版本的部署栈上去。
摘要: 英文Email，第一段該寫什麼？
1. I am writing to confirm/ enquire/ inform you...
我寫信是要確認/ 詢問/ 通知你......
2. I am writing to follow up on our earlier decision on the marketing campaign in Q2.
我寫信來是為了要追蹤我們先前對於第二季行銷活動的決定。
引用稍早的談話或信件，該怎麼說？
3. With reference to our telephone conversation today......
關於我們今天在電話中的談話......
阅读全文