如今但凡提到软件工程，必言软件架构。软件架构对于软件界来虽说是舶来之词，它对于软件工程的发展意义非凡。对于一般的架构师而言，他们或多或少会面临着这样的困惑：
1. 如何将系统划分为模块
2. 大系统架构设计该如何起步
3. 总觉得需求很糟糕，影响了架构设计
4. 非功能需求很重要，但是如何发现这些新功能需求并应用到设计当中去
等等。
虽然就目前而言，软件架构远没有我们所期望的和建筑上的架构那样完善，但也出现不少的方法论来试图帮我们解决上面提到的一些普遍性问题，如ADD指导如何划分系统为模块、ZAEMAN Framework为大系统特别是大的信息系统的架构提供参考、TOGAF是目前比较流行的用于信息系统的架构方法论等。这篇文章要说的就是ADMES，是Architectural Design Method has been Extended to Method System的缩写。ADMEMS方法不是单一方法，而是由多个各具特点的方法组成的方法体系，它不同于其他的方法论，它试图提供一种方法体系来供我们的架构师参考来解决上面的这些问题。
ADMENS方法通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工作内容。3个阶段分别是：Pre-architecture、Conceptual Architecture、Refined Architecture。PA阶段是架构实践中常见的短板，CA阶段是大型系统成败的关键，RA阶段是大规模开发的基础。总体说来，PA阶段的工作就是运用ADMEMS矩阵将需求结构化，建立二维的需求，并视图找出系统的重大的功能需求和质量属性；CA阶段的工作就是根据PA阶段的结果运用分析图、目标-场景-决策表来构建出一个尽量合理的架构；RA阶段的工作就是运用UML、目标-场景-决策表等方法来构建出系统的5个视图（实践中不是5个视图都需要）。
PA阶段强调重大需求的获取和质量属性的确定，分为四个阶段：
1. 需求结构化（需求分类）
2. 分析约束影响（ADMEMS矩阵方法）
3. 确定关键质量（安全性、高性能、高可用、互操作等）
4. 确定关键功能（核心功能、必做功能、高风险功能、独特功能等）
我们一般认为需求分为三个层次，分别是业务需求、用户需求和功能需求（RUP的分类法则分为Need、Feature和软件需求）。不同的需求从层面去影响架构。
1. 功能需求是发现职责的依据，是CA阶段进行的基础
2. 质量需求是架构的驱动力
3. 约束是架构必须考虑的因素
（功能需求但并不一定是划分模块的唯一依据，划分模块需要综合三者，往往质量需求是划分模块最首先要考虑的因素）
ADMEMS方法提供了ADMEMS矩阵方法来进行需求的分析和推导，借助这个方法，把多而杂的架构影响因素梳理清楚，建立全面有序的理解。
架构新手和有经验的架构师的区别之一在于是否懂得并能有效地进行概念架构设计。有经验的架构师不会一上来就关注如何定义结构，他们在典型系统架构设计的早期比较注重识别重大需求、特色需求、高风险需求并识别质量属性来设计概念架构。CA强调重大需求塑造架构，这里的需求既包括功能、约束、质量属性。概念架构界定系统的高层组件，以及他们之间的关系。概念性架构意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正式规约和架构图，但不涉及接口细节。进行CA，首先及需要构建出自己的架构场景（即一部分业务用例）从而发现不同的系统组件。CA可分为三个步骤：
1. 初步设计（通过业务用例和序列图发现职责，得到系统分析设计图，包括实体、控制对象、界面对象、接口等）
2. 高层分割（切割/聚合初步设计得到的系统为多个层次【可按照不同的维度来划分，如技术、业务等】或/和多个子系统【一般按照业务来划分】）
3. 考虑非功能需求（如可按照ADD方法）
RA关注的是具体的接口、模块和连接件了，当然还有其它很多的工作，如进程、线程设计、接口定义、系统选型、数据架构等等。ADMEMS推荐使用5视图方法来进行架构设计，这5个视图分别是运行视图、逻辑视图、物理视图、开发视图、数据视图。每个视图描述系统的一个侧面。
（如逻辑架构的目标就是划分模块，定义接口，其实践方法包括细化分层、提取机制、划分垂直子系统，可采用职责分离、通用专用分离、技能分离、工作量均衡等策略进行设计）。
总而言之，ADMEMS为我们提供了一个很好的思路来进行指导我们的架构。
参考资料
1. 软件架构实践
2. 软件架构设计
3. 架构之美
4. 一线架构师指南