模块分析

　　首先，强调一下，模块分析前提一定是流程已经梳理清楚；即业务层面和实现层面已经有了比较明确的思路，之后再进行模块化分析。

　　首先是经典的输入输出模型，学过PMP的人应该对于这模型非常熟悉；分析模块首先就是分析他的触发场景是什么，输入（参数）是什么，通过分析触发场景，了解他是被动的还是主动的，发起方都有哪些；比如对于交付器而言，他的调用方是总控，那么交付器的触发就是被动调用；输入参数就是文件的文件夹，单位以及四属性，入口参数在分析初期可以先笼统的考虑，因为输入参数在分析模块内部流程的时候会不断进行细化；但是通过分析参数能够确立一种意识：模块就有独立性，接收参数可以内部进行运作；设计模块的基本思路就是低耦合，高内聚；对于外部依赖越小越好。至于输出的是一个反馈（比如一次RPC调用）。

　　第二步是分析模块内部处理，首先是分析流程的步骤以及数据，数据是用来驱动支持流程进展的，流程是由步骤组成，分析清楚步骤，以及每个步骤所需要的数据；数据就是要识别出来的对象；如果多个分支，考虑是否需要多个对象来表明用意，比如加密是一个分支，解密是一个分支，那么作为任务可能需要设计为加密任务，解密任务；

　　对于数据需要分析数据的结构是怎样的，比如是List，还是BlockingQueue等；这个是基于对于数据操作来设计的；在对数据分析的时候，还要对数据的来源进行分析，这个存在了模块交互（比如内存模块，数据库模块），还会影响输入参数，因为有的数据会考虑有输入进行处理；

　　分析完了数据，就要考虑一下完成该步骤资源问题，就是完成这些步骤/流程所需要的资源，什么是资源？首先资源是有限的，其次是资源是可申请而且每申请一次就会减少。资源包括线程（CPU），内存（队列，直接内存存储byte字节），硬盘（保存文件）；还包括业务资源，比如任务上限，最多同时处理多少任务。比如对于流程流转，是通过多线程，从线程池中申请线程完成的，那么就需要线程；通过对资源的考虑，首先可以促使对程序的设计进行考虑，其次，可以对于资源的限制和判断，来让系统更加健壮。

　　接着就是识别类，识别类之前要识别对象，什么是对象？行为和状态载体。就是要完成步骤中的任务，需要哪些行为，然后为这些行为以及这些行为导致的状态，在逻辑上进行组织，对象的抽象以及归类就是类；比如一个业务任务对象，其实在程序运行过程中会有很多业务任务对象，然后，对这些业务对象进行抽象，抽象出来了业务任务类；但是注意这些对象之间的区别，有的需要压缩，有的不需要进行压缩，你就需要进行权衡他们是否需要进行剥离，压缩任务以及不压缩任务，你可以选择通过一个字段来做区别，但是关键是看差别到底多大，是否还有的不同药进行区分；就是尽量减少if分支，而是通过不同的业务对象（类）来进行区分。因为if分支的意图复杂，需要深入细节，如果在类上面做区分，意图明显，而且能够在一个较高的角度对流程做梳理。

　　然后，考虑一下内部流程是自驱的（链式的，一个调一个），还是需要中间来一个调度的，本质是控制权的归属，步骤完成之后，就是步骤之间可以自己进行下一步处理，将控制权交给调度类进行下一步调度。

　　以上都是正常系，一定要先把正常系梳理清楚了，最后，要对于每个节点做异常分析（异常有哪些）以及异常处理（发生异常怎么办）。

　　最后，再强调一下，一定要在模块分析之前，已经有了清晰的流程轮廓。