dryr

系统架构分析设计方法

    最近几天一直都在想着系统架构的事情，想着如何才能更好的描绘出一个业务以及支撑系统的情况，过程中也不乏向一些前辈请教，慢慢的形成了一些自己的想法或做法。
    今天下班回家的公交车上，脑子中还在不停的想着系统架构的事情，忽然有了一个念头，将之前涉及的一些方法串联了起来。下面描述一下这个从用例和业务流程出发分析得出系统架构的构想。
    首先，我们要将业务流程分层描述，业务流程不需要指明执行角色（在较高层次业务流程中也无法确定执行角色），然后逐层细化，可以将业务流程细化到可以根据业务流程编写出伪代码的程度。在各层的业务流程图中，我们需要识别出能表述单一功能的流程点（这个可能需要经验来判断），这些识别出的功能点在之后可以作为验证用例图完整性的依据。
    然后通过对不同业务角色人员操作的不同功能，以及边界外系统与本系统的一些交互功能，以及本系统的处理功能，画出用例图，将此用例图使用之前从业务路程中识别出的功能点进行完整性的验证，以防止用例遗漏。再针对每个用例图，给予一个简单的说明，将用例中的事件流等说清楚，最后形成用例描述文档（也就是功能说明文档），另外还应该产出一个补充文档用来说明非功能性需求。
    从用例推导出类图，就是采用领域模型（domain modeling），就是第一步将用例描述中的名词识别为域对象，然后再根据用例描述识别出对象的属性，最后将用例描述中此对象名词的动词再识别出对象的方法（这一步也可以通过先根据用例画出用例序列图，然后将序列图中的序列动作转化为对象的方法），按照此种方法推导出的是最原始的类，在此基础上，再补充相关的一些类，还需要识别出这些类之间的包含、关联关系，同时将一些类的共同点进行抽象（将抽象出的抽象对象作为一个新对象，被抽象对象从抽象对象泛化），最后就形成了完整的类图。在推导类图时，还需要注意系统的技术架构，因为技术架构确定了类图的依赖层次关系，比如技术架构中分为jsp，action，service，dao，db这几层，那么在类图中也必然有这些层次。
    在类设计时，必须根据技术架构将整体框架设计完成，划分好类层次结构；然后先对底层模块进行设计，比如先设计权限模块、通讯模块、日志记录模块等，然后再对业务模块进行设计。在设计业务模块时可以通过局部设计技术，对某个或某几个功能点进行局部设计，多使用设计模式。
    在类设计完成后，最好能进行业务驱动的功能推导（可以借助完善用例的序列图来推导），以验证类图设计的完整性和是否存在矛盾的地方。

---------------------------------------------------------------------------------------------------------------------------------------------------------------

向公司的一位大神请教了一下关于系统架构方面的思想和方法，他的想法值得借鉴：
我们做一个系统，需要解决两件事情：做什么，和怎么做。
那我们在做系统架构时，能有什么资料，我们手中唯一的资料就是需求说明书，这就是系统架构的输入资料。我们不要妄想这需求说明书是写的非常清晰非常详细的，大部分的情况下拿到手的都是写的很烂很糟糕的，可能只是很笼统的说明了要做什么，更清晰的需求需要我们自己去挖掘。
做什么是对功能职责的定义和描述，做什么是从业务出发的，即是业务要求系统做什么，在这一步骤中，我们只从业务角度谈论功能职责定义，不考虑功能具体的实现（具体实现之后步骤中会考虑，这里如果考虑具体实现容易陷入具体实现中而不能全面整体的发现和定义功能职责）。
一般采用从上到下，从子系统到模块再到功能点的分解步骤来进行。具体做法如下：
1、项目开始阶段，我们根据拿到的需求说明书以及我们所了解的需求情况，确定系统包含的子系统（在这个阶段按照我们所了解的需求程度也只能给出子系统级别粒度的应用架构），定义各个子系统的功能职责（子系统包含哪些功能模块，各子系统职责划分的原则），以及各子系统之间和与外部系统之间的交互（存在哪些数据的交互，存在哪些功能调用）。画出应用架构图，描绘各子系统之间及与外部系统间的关系。
2、应该说一般情况下，我们在划定子系统的时候，大致已经可以确定各子系统的模块。但识别出子系统的模块还不够，还需要对模块进行分析识别出公共模块以及模块间的交互关系，这步需要花费大量的分析和对需求的深入了解。针对每个子系统，分解为各个模块，定义各个模块的功能职责（模块包含哪些功能点，各模块职责划分原则），以及各模块之间的交互（数据交互和功能调用）。此步骤中需要识别出公共模块，以及公共模块给其他模块提供的服务（这是模块间交互关系的一部分）。
3、在完成模块划分后，接下去就是针对每个模块，分解为每个功能点，定义每个功能点的需求描述，以及对外提供的服务接口（或者将服务接口也看成是功能点，归并到功能点中），定义每个服务接口的需求描述。一般我们都在说推荐使用用例的方式来描述需求，如果这里使用了用例方式来描述需求，那这个功能还是比较好识别的，每个用例就是一个功能点，定义功能的输入和输出（包括数据和接口的输入和输出，在开始阶段数据和接口定义可以适当模糊，随着需求清晰再将数据和接口描述清晰），再在此基础上分析合并，识别出公共功能点。
完成了以上3个步骤，就将整个系统需要做什么分析的比较清楚透彻了，在此基础上，可以再进行业务推导，找出遗漏或重复的功能点（补充或删除），以及进行功能点的抽象等，最终形成系统完整的应用架构，完整功能点视图。

在完成应用架构和功能点分析梳理后，我们需要考虑怎么做的问题了，怎么做是对功能点的实现方式的考虑。实现方面需要考虑的几个方面：1、技术架构（实现的层次结构），2、部署架构（应用的实际部署情况），3、开发设计需遵循的规范和原则（开发规范等），4、系统框架搭建（框架功能的开发搭建）
我们在确定做什么这个方面我们是通过逐步细化的方式来最终得到结果的，同样道理，在系统实现方面也是分阶段的，不可能一开始就想清楚系统是怎么实现的。在项目初期，我们可以根据经验和所了解的需求，子系统级别的应用架构等，初步整理出系统的技术架构和部署架构。需求分析+子系统级别的应用架构+技术架构+部署架构就构成了系统方案，是粗粒度的系统架构。随着项目进展，对需求的了解和分析越来越深，会形成越来越清晰的系统方案，对应用架构进行细化，对技术架构和部署架构进行完善，最终形成完整的系统架构。因为系统的建设不是一个人或几个人的事情，一个大的系统的建设往往需要很多团队很多人的参与，不同团队及人都会有不同的开发习惯和方式，这就需要从项目或系统层面出一个规范和原则，来约束所有参与的团队和人都遵循，统一的规范对项目和系统来讲有很多的好处。另外，系统开发需要分工，但其中有些公共的功能必须要有人统一来开发和维护，这就需要搭建系统框架，在系统框架中统一实现公共功能。

系统架构并不一定是一个人或一个团队一直持续分解细化的，可能系统架构师完成了子系统级别的应用架构、技术架构和部署架构，然后就交给各个团队自己完成各子系统的模块分解和功能点分解，以及局部的设计，但系统架构的思想必须层层传递，不能出现曲解和误解，所以系统架构文档就显得极为的重要，系统架构文档除了必须说明系统架构情况外，一定还要说明清楚系统架构如此设计的思想和意图，以让其他设计者或开发者能明白所以然。

这里有几个问题：
1、数据库这块如何融入应用架构？
2、用例（usercase）这个方法何时使用？如何无缝应用到系统架构设计中？
3、在分解为模块时，会识别出公共模块，按照这种思路，在分解子系统时应该也会识别出公共子系统（比如Portal系统，流程管理子系统，规则管理子系统等），在与业务人员交流应用架构时，这些公共子系统是否需要展示给业务人员，业务人员是否理解这些公共子系统？个人认为如果不将这些公共子系统识别展示给业务人员，将难以将完整的系统全貌展现给业务人员，比如不识别和展示出Portal系统，将会让业务人员难以理解所有子系统都是通过Portal系统统一登录和展现的，比如不识别出流程管理子系统，将会让业务人员难以理解所有的流程都是集中管理的，所以个人还是认为这些公共子系统应该被识别出并且展示在应用架构中，对应用架构配以一定的说明将使业务人员有足够的智慧来理解这些公共子系统。
4、当在项目（尤其是存在旧系统的项目）前期，有部分需求或关系还比较模糊，比如A子系统需要使用B子系统的某类数据，但却并不知道具体是什么数据，而且A子系统是否还需要B子系统其他的数据这些都比较模糊，这种情况下该如何处理？是在应用架构中只体现模糊关系，到之后AB两个子系统关系清晰后再修改，还是先去全面了解AB两个子系统的关系后，在应用架构中给出一个相对清晰的关系？另外，处于项目前期时，对子系统的内部模块的划分以及模块之间的关系（数据和服务接口的关系）很难清洗的识别出来，只有一个模糊的大概关系时，模块分解该如何进行？如果只描述模糊关系，那何时修改清晰？