软件架构设计 ADMEMS方法体系

公司软件架构培训：

听得很累有几个原因：

一是虽然这次算是有史以来时间最长的专题培训，但要讲清楚软件架构设计方法体系这么大一个主题，受时间所限对一些概念名词的交待老师只能口头一带而过，这些词可能在老师创建的ADMEMS方法里是有清楚定义的，或者是在老师的著作里有交待，可惜事先没有读过，温昱老师的《软件架构设计》据说可以做为大学研究生教材；

二是老师之所以创建自己的一套方法，自然是认为业界的很多做法或概念存在问题（讲课过程中也时不时提到），所以一方面对刚讲的概念需要消化理解，一方面又要竖起耳朵听，生怕漏掉了重要的东西更不好理解后续内容。

直到最后一个半小时，老师对本次培训做总结时，才觉得整个事情被理清楚了，原来前面颠来倒去得讲了三天半，就是为整个ADMEMS方法体系的推出做铺垫。

 

总体而言，对于老师的ADMEMS软件架构设计方法，持认同的态度；对于是否通过本次培训能在恒生落地发挥作用，持怀疑态度。如果只是介绍ADMEMS软件架构设计方法，我觉得一天的培训就够了；如果要让ADMEMS软件架构设计方法在恒生落地，四天的培训显然还是不够的。

之所以认同，是因为我觉得老师的ADMEMS方法体系提炼的确实全面、到位，也是以架构师的思维方式看待“软件架构设计”本身(要有大局观、要作准确分解、要有决策)，提出的一套完整的实践体系也是我们所缺的。在恒生的标准软件过程中，我们没有显式提出软件架构师这个角色，当然并不是说我们不做架构，而是把多项职责笼统地交给了技术经理，后果是不利于技术经理在架构经验上的积累和传承(基本上我们主要靠使用专用的公共技术平台和开发工具，来对行业应用的软件架构进行固化和传承，同时我们也依靠对行业应用的专注和熟悉来保证技术平台在行业应用中的适用性)，土生土长的恒生技术经理在自己长年工作的领域内可以做的很顺手，但换一领域，估计就不能保证有一致的效果，原因是没有清楚地理出一套系统的软件架构设计方法，一旦公司要进入一个全新的业务领域，架构好坏全凭技术经理的个人素质。

 

下面根据我的理解，简单对比我们常用的做法，看看我们在软件架构设计过程中漏了什么，哪些方法可以从ADMEMS中借鉴的，欢迎参加过本次培训的同事拍砖。

 

ADMEMS从过程角度总体分析软件架构设计中存在的三大典型难题：需求混乱、架构设计过程混乱、架构输出混乱，然后针对性地提出一套实践方法体系。不管是ISO9000,还是CMMI，均是面向过程来分析问题，提出解决方案的：需求是架构设计的输入，架构文档是架构设计的输出（比如概要设计文档，4+1架构视图文档），中间就是架构设计过程本身。总体而言，架构设计是需求入，架构出，ADMEMS将架构设计过程再细分为三步：Pre-Architecture（PA）、Conceptual Arch(概念架构CA)、Refined Arch(细化架构RA)。其中，PA是ADMEMS专门引入，CA和RA是业界已有的概念。

一、PA阶段：引入PA主要就是解决当输入的需求混乱时，怎么防止错过影响架构稳定的关键需求

主要方法就是采用结构化分析需求(ADMEMS矩阵)，识别出关键需求是要作为概念架构CA的输入。

ADMEMS矩阵对需求除了按我们常用的类别维度分为功能、质量（非功能）、约束外，还引入另一个维度：组织级、用户级、开发级，从而形成二维矩阵。

对需求的多维度分类，便于更准确识别出关键需求，防止遗漏；ADMEMS为关键非功能性需求识别提出五个原则，对关键功能需求提出四个规则；对于约束性需求，提出四种分类挺到位的。

ADMEMS分析了不同类需求对架构设计的影响： 

         功能：职责与协作

         质量：架构完善的动力

         约束：架构设计的上下文

思维方式实际上与模式语言类似：在特定上下文环境下（约束），针对问题（功能与质量），提出解决方案（架构设计）。

这里要注意，ADMEMS对需求的分类，与国标和UP中的FURPS+略有不同，容易引起一些概念性问题，不过无伤大雅，接受他的说法就是。

 

二、CA阶段：主是用来对付复杂的大系统，一般不关注细节

主要方法是对系统功能做高层分割，对重要非功能性需求做出决策。我们在投标ppt上一般会展示这些内容；CA阶段的方法是：

        1、对关键功能，使用UML中的鲁棒图进行初步设计，进行初步设计，然后对通过鲁棒图识别出来的对象做高层分割(包括物理分层，逻辑分层，按通用性分层，技术堆叠)，并考虑备选方案；

        2、对关键非功能性需求，采用“目标-场景-决策”表作出决策；

培训中有同事提出，按老师的做法，对于非功能性需求的处理貌似只要一套模版按统一套路去处理就行了，不用分析了。好象老师没有正面回答这个问题，其实我觉得这个感觉是正常的，因为对于非功能性需求的处理，业界确实存在大量架构模式可以套用，上回UML培训老师推荐的一套书《面向模式的软件架构》大部分上是针对非功能性需求的。

 

 

三、RA阶段：是为了后续进行团队的并行开发，是架构设计的主要内容

        一般采用多视图做法。我们一般就是写概要设计文档，部分内容也会在项目计划中体现(比如源代码目录结构、风险分析、开发约定等)

ADMEMS在RA阶段提创迭代，认为“质疑驱动架构进步”。ADMEMS提倡的是五视图架构：

       逻辑架构：对系统进行分层、分区、机制提取（可以简单理解成与具体应用无关的通用框架提取）。根据切分后的模块之间的协作关系，确定模块接口；这一步一般可采用的UML工具（包图、顺序图），并要多次迭代。

       开发架构：实际上就是在SDF上Source目录结构进行规划，确定要开几个project之类的事。

       运行架构：主要是对进程、线程等主动对象的设计

       物理架构：物理部署节点设计，系统软硬件要求；

       数据架构：持久化相关的数据库、文件设计等；

 

对于五视图的应用，ADMEMS提出了一些最佳实践,比如：

       “尽早入手”：比如从逻辑、物理二个视图开始，尽早入手细化架构设计；

       “保持一致”：视图之间是相互影响的，短板决定质量；

       “务实为先”：视图可以混用，数量要合适；

        “综合”：要采用多种方法；

        在逻辑架构设计时，提出系统切分四个原则：职责分离，通用专用分离，技术分离，工作量均衡；