ADMEMS软件架构设计方法设计方案

1、ADMEMS件架构设计方法设计方案方法体系作为方法体系，ADMEMS法通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计 完整工作容。其中“ 3个阶段”是指预备架构阶段（PA阶段）、概念架构阶段（CA阶段）、细化架构阶段（RA阶段），“1个贯穿环节”是指对非功能目标的考虑。PA阶段的任务是全面理解需求，从而把握需求特点，进而确定架构设计驱动力。其中，ADMEMS阵居于方法的核心；CA阶段必须考虑包括功能、质量、刍束在的所有方面的需求，ADMEMS法有自己的概念架构设计步骤和做法；RA阶段的总体方法为5a图方法，涉及逻辑架构、物理架构、开发架构、运行架构和数据架构。浅相架构 职责划分

2、 职责同怫作数据架柄持久裁据惟元 祖期存憧格式物理架构 物理节点 询理节点跖扑而向丁老腐戒文件文档模板（下载全套模板）ADMEMS法为软件架构设计提供了整套文档模板，涉及文档简介、架构描述方式、架构设计目标、架构设计原则、逻辑架构视图、开发架构视图、运行架构视图、物理架构视图、数据架构视图、关键质量属性的设计。在架构设计实践中，架构师可以直接使用这套文档模板来设计架构，以及对架构进行描述。坦墉要点计苒和通信用R小，通少计声和通值时 内有暧盘fCPW 阴楮冲突量将科悚,投资与雉护成 串营理，特定性能目标经济性 技术可行性昂维护性性能持续可用性一可伸缩性标层通信开制计尊升耨网络争用内存争用CPU引

3、用硬施争用数据争用I软件单元网络数据单元物理节点思维层结果层? B-ill*fc-ili * - fuirutttwPASS）；普二(Tier! J前辈推荐晋兴（中航集团公司631研究所研究员，前系统软件室主任）：ADMEMS当前软件架构设计领域先进的 方法体系，在论述架构设计不同阶段的分析方法与设计技术的同时，给出了相应的实践策略、 实践套路及有用的设计案例。本方法具有极强的实用性，不但是一线架构师及希望成为软件架构师者的福音，对我国软件业界在软件架构相关方面的研究工作也有一定的推动作用。周伯生（北航计算机学院教授、博士生导师，美国SDP舞会院士）： ADMEMS构设计方法学既是提出者亲身的

4、实践总结，又概括了业界的有效实践；不仅生动地反映提出者的创造性思维和对学术的刻苦耕 耘，又反映出提出者对架构学的崇高历史责任感；不仅对架构师们有很好的参考价值，而且对推动架构学界的深入研究具有重要意义。黄绍良（清华大学创新研究会成员，南开大学软件学院教授）：软件工程的架构师犹如建造工程的建筑师一样，一些建筑师能够最终成为“大师”，主要是他们的建筑设计除了能够满足应用需求外，还能结合周边环境，拥有独特的组合理念和创意。 把握软件的架构设计技巧和方法，才能够带出软件创新的成果。ADMEMS从业人员理解如何才能够客观地为客户设计高效和优质的计算机软件，是成为真正软件 工程师的第一步，是未来软件大师的

5、实践指南。划分子系统，分局的细化 划分子系统豺E的引入 划分子系就：机制的提就 接口的定里：卧作决定搂口选用序列图:牡鼬汾件IE包-接口第：从塔前耦行为的标 及盒笆凰：描逑关W子系统储序渐进的培康朋缎设计楔式:包内第枸 设计模式T包间秋性及景国己的请,蜡物方面也切升狗年由该跖第分阶也+Mt.专家评价宋英（西门子公司资深IT专家）：ADMEMS法深入浅出，对中大型系统的架构设计起到了航标灯的作 用，不仅解决了资深架构师的困惑，而且对新手具有重大的指导意义。它把抽象的理论落实到实际的可 操作的围，令人折服。泳萍（中国软件评测中心技术总监）：ADMEMS法是架构设计实践领域的突破。宋兴烈（起步科技总

6、工程师）：ADMEMS成了关于架构设计方面的核心主，并且提出了非常具有指导和实践意义的方法体系。细细体会这些核心主和ADMEMS法，发现似曾相识，特别有共鸣。原来我们在平时的架构设计中，竟不知不觉地在使用这些主和方法，但是没有总结出来。我非常愿意向业人士推荐ADMEMS法,因为ADMEMS从实践中来的，自然可以很好地运用到实践中去，具有很高的实践指南价 值。靳向阳（加拿大 旧M软件工程师）：ADMEM浅法由浅入深地给出了架构设计相应的对策，实战性极强。本人认为ADMEMS法实乃业界相关技术中的一朵奇葩，强烈建议新老架构设计人员掌握ADMEMS法。董振江（中兴通讯业务研究院副院长）：ADMEMS

7、法是一套实用性强、非学院式的体系，对做好架构设 计富有指导价值。ADMEMS法的三阶段理论、结构化需求与约束分析等不少概念一经指出让人有茅塞 顿开之感。ADMEMS法中有很实用的操作技巧，值得每一个架构师反复学习和操练，领会之后定会让 您的架构设计更上一层楼。徐锋（独立咨询顾问，需求过程框架 SERU&J始人，CSAI首席顾问）：ADMEMS架构领域的指路明灯， 它架构在成熟方法论这一巨人上，构建在提出者多年来跨不同领域、不同平台的架构设计经验的基础上。罗景文（IBM developerWorks中国）：ADMEMS法的原理和实践经验对指导架构设计实践具有非常实用的参考价值。哲洙（东软

8、集团电信事业部研发二部部长，资深咨询顾问，东北大学客座讲师）：ADMEMS在架构设计的方法论方面、设计细节量化方面、设计应采取的原则方面都做了针对性总结和概括， 具有重大的实践 指导意义和推广价值，为一线架构师不可多得的理论和实践指导。培训课程课程名称：提升架构设计能力的四堂课（经典课程）培训特色： 以业界实践精华和落地的技能为主体容，为客户一线实践提供有针对性的帮助 每个环节，从流行谬误的分析切入，“拉”您进入主动学习状态 贯穿的【实战案例】，边学边练，以练带讲架构新手实戏需求列表呗“冉号矩阵方法咤凄需求的技巧X制定方向性、 决策的技巧/应对非功能需求的技巧多觇图拽能课程名称：业务框架规划与

9、设计（高端课程）培训特色：重视识别可变性、确定变化点和选择变化点支持策略等业务框架规划与设计核心技能的“讲”与“练”帮助学员建立业务框架规划与设计的大局观、以及系统化思维框架.专业.专注.实用的重点技巧成体系的实践步骤贯穿的实战第快定Sc。或笫2米：Y别可变性化点物明对耐购第5步：选技术第咯第3步：&错误！未指定书签。Software Architecture DocumentVersion <1.0>Revision HistoryDateVersionDescriptionAuthor< yyyy-mm-dd ><x.x><details&

10、gt;<name>说明：本文档模板由 CSAI架构设计专家组荣耀发布，详细技术支持请访问.csai./admems/1. 文档简介111.1 文档目的111.2 文档围111.3 定义、缩写词和缩略语111.4 参考资料112. 架构描述方式112.1 架构视图阅读指南112.2 图表与模型阅读指南113. 架构设计目标123.1 关键功能123.2 关键质量属性123.3 业务需求和约束因素124. 架构设计原则134.1 架构设计原则134.2 备选架构设计方案及被否原因134.3 架构设计对后续工作的限制（详设，部署等）135. 逻辑架构视图135.1 职责划分与职责确定14

11、5.2 接口设计与协作机制155.3 重要设计包176. 开发架构视图186.1 Project 划分186.2 Project 1186.2.1 Project目录结构指导196.2.2 程序单元组织196.2.3 框架与应用之间的关系（可选）196.3 Project 2 206.4 Project n 207. 运行架构视图207.1 控制流组织207.2 控制流的创建、销毁、通信207.3 加锁设计218. 物理架构视图218.1 物理拓扑218.2 软件到硬件的映射22238.3 优化部署9. 数据架构视图 239.1 持久化机制的选择239.2 持久化存储方案249.3 数据同步与

12、复制策略2410. 关键质量属性的设计原理24.专业 .专注 .1 .文档简介帮助读者对本文档建立基本印象，并为阅读后续容扫清障碍。1.1 文档目的文档目的，非项目目的。否则造成同一项目多个文档之间的容重复，不利于文档维护。本小节应指明文档针对的读者对象，最好列出各种读者角色，并说明每种读者角色应该重点阅读的章节。1.2 文档围文档的Scope,非项目的Scope。否则造成同一项目多个文档之间的容重复，不利 于文档维护。1.3 定义、缩写词和缩略语集中列举文档中的定义、缩写词和缩略语。1.4 参考资料本项目经审核的计划书、合同、上级批文；本项目的其他已发表文件；本文档引用 的文件资料，如软件开

13、发标准。具体而言，应包括参考资料的题目（必须）、编号、版本号（必须）、发表日期、发布方，必要时还可以说明如何使用这些资料。2 .架构描述方式为了让读者更好地理解架构文档，在本节应当说明文档涉及的架构视图，并指明为了描述设计决策用到了哪些图表和模型。2.1 架构视图阅读指南以多视图的方式来组织架构文档是大势所趋。视图方法，如卜图所示。辑架f0职责划分/7面向对象，职各同协作或结构牝 X，生发架桎u'程巴单元1、程用熔元瞥, 二"持久效据甲元、4府司T皿疑存储格力一、薮.卜、，2.2图表与模型阅读指南对后续文档容中所用到白建模语言（例如UML、ADMEMSt荐的是经过优化的 5行

14、姐、，控制流、控制流组限厂'尸,、附向控割流Xji”物理架构、工杨谡节点.物理节点谕用面向节点表格（例如目标-场景-决策表）等进行说明。3 .架构设计目标功能、质量、约束，一个都不能少。3.1 关键功能对架构设计至关重要的功能，包括如下4类：核心功能、必做功能、高风险功能、独特功能。所谓独特功能，指这个功能覆盖了上述3类功能没有涉及到的职责。3.2 关键质量属性人之所以痛苦，很多时候是因为追求错误的东西。下图是ADMEMS法确定关键质量的5大原则的整体思路图。3.3 业务需求和约束因素ADMEMST法创造性地提出约束需求的4大类型，这是一种极为实用的分类方式。特别是业务需求对架构设计而

15、言是一种约束的观点，解决了很多架构师的现实困惑。下图标明了 4类约束在“需求层次-需求方面矩阵（又称 ADMEMS阵）”中的位置, 可以帮助我们理解产生约束需求的根源。.专业.专注.广义功能质量黔束各批实施旁争氏姜后飞4 .架构设计原则投标时经常讲“架构设计原则”，但到了架构文档，这些着眼大局的考虑却“丢 了"。ADMEMS法推荐的本文档模板，认为应当把它们“找回来” 。4.1 架构设计原则着重描述重大的权衡取舍考虑。4.2 备选架构设计方案及被否原因在概念架构一级，对备选架构设计方案进行描述，并阐述它们未被采用的原因。这有利于团队了解当前架构设计方案的来龙去脉，提高团队对当前架构设

16、计方案的认 可度。4.3 架构设计对后续工作的限制（详设，部署等）架构设计不仅应该包含“指导”，也应该包含重要的“限制”。例如，一份只是说明 “性能和可扩展性都重要”的架构文档，实际上忽视了 “可扩展性和性能之间存在的矛盾关系”。此时，最有效的办法就是在架构文档中明确说明“任何提升可 扩展性的架构设计和详细设计，都应通过架构团队的评审才能引入，以确保性能目 标不受重大影响”。说明：本文档模板由CSAI架构设计专家组荣耀发布，详细技术支持请访问.csai./admems/ 。5 .逻辑架构视图关注点：此架构设计视图的关注点是职责划分。注意：逻辑架构视图无疑是最重要的，但同时也应避免“架构 =模块

17、+接口”等 以偏概全的认识。参考：任何复杂系统的架构设计都不是一蹴而就的,所以架构师需要理性思维过程的指导。针对逻辑架构设计这个关键环节, 条建议：一是“以质疑驱动的螺旋思维” 和“行为方面的定义”。下图所示即为一线架构师实践指南一书给出了2,二是相对分离地考虑“结构方面的切分”ADMEMS法推荐的逻辑架构设计理性思维过5.1 职责划分与职责确定容：将系统切分成更小的单元，并明确这些单元的职责。具体而言，职责单元可以早 TH,层、子系统、模块、关键类等。意义：一句话，职责划分不合理，功能和质量都会受到影响。也就是说，功能需求和质量需求无一不和职责划分相关：一方面，每个功能都是由一条职责协作链完

18、成 的；另一方面，职责划分方式也影响着质量，于是需要职责模型针对特定质量属性 要求做出相应调整和优化。很多人认为架构设计就是职责划分的艺术，虽略显片面,但足以表明职责划分的重要性。参考：基于对业界大量案例的研究，ADMEM昉法梳理出了 “模块划分的3种必用手段”，如下图所示，更多容可参考一线架构师实践指南一书。5.2 接口设计与协作机制容：本节描述接口的定义，以及协作的方式和规。意义：恰恰是因为有了各模块之间“未来合作的契约”，分头开发各模块才有了基本保证。参考：ADMEMS"法推荐利用“包-接口”图，来识别接口。下图为一个“包 -接口 图的示例。进度展现回调接IFacade命令描述

19、能冲接口智能按冲帆制内容於冲达"断定向1 ,容/ ”对相应接口进行回调对越出题定mu容量的 内杵边疗智能保存接口接口参考：ADMEMSf法推荐使用序列图，建议少用、甚至杜绝使用协作图。下图为 个序列图的示例。说明：本文档模板由CSAI架构设计专家组荣耀发布，详细技术支持请访问.csai./admems/5.3 重要设计包容：对重要子系统的设计进行“灰盒”级描述。 意义：“每个子系统在架构设计中都应保持黑盒子”的观点，过于理想化了。对于业务层、通用协作机制而言，经常需要在架构设计期间就引入“灰盒”级描述。参考：类图和灰盒包图，在本节中较多出现。下图为一灰盒包图示例。履现层clt调用Un

20、Wrfag)GnnnChartI Ad”恒膜式）GanttChartlmpI调用1中来自第三方的H.特图绘制包6 .开发架构视图关注点：此架构设计视图的关注点是程序单元组织。注意：此架构设计视图是必须的、不应“剪裁”掉的。但实际情况却是，很多架构 师不关注开发架构视图，导致很多程序开发人员抱怨“架构师就知道高来高去，架 构对编程工作没什么指导性”。6.1 Project 划分容：本节说明整个系统将划分成哪几个 Project来开发，其中，Project指开发环 境所感知到的“工程”。意义：基本好处是，有利于开发的组织；而对一些大型的集成系统而言，由于同时涉及了 Web应用、桌面应用、嵌入式应用

21、等软件形态，所以此时Project划分其实是不得不做的；最后，我们推荐核心代码应主动地切分到单独的 Project以进行独 立的软件配置管理（SCM,以降低核心代码外泄的风险。 参考：Project划分必然是属于“架构设计”的工作，严格来讲仅靠“需求分析” 划分的业务域（Business Area）直接映射到 Project经常意味着工作容的遗漏。其 实，业界不少有见地的专家已经认识到WBS（工作分解结构）做得太早太草率危害很大，就与"Project划分不到位”不无关系。6.2 Project 1容：对Project划分后的每个Project进行目录结构、 程序单元组织、框架与应用

22、关系的说明。6.2.1 Project目录结构指导容：关于该Project 一级目录、二级目录等基本目录结构的约定。意义：为团队并行开发提供必要基础，让不同程序小组看到自己应该负责的程序目录。参考：不要把所有程序目录的约定都定义得太细，否则这份架构文档就要天天 更新了。6.2.2 程序单元组织容：源码、程序库、框架、目标码等类型程序单元之间的编译依赖关系。意义：或许有人认为这没什么技术含量，但架构设计本来就不是只关心技术含量最高问题的。君不见，很多软件工程师跳槽到新的企业之后，竟然连一个能正常编译 源码的开发环境都建不起来一一其实，他们“不知道Project所依赖的Library 有哪些”是其

23、中重要原因一一这本应在架构文档中给出明确描述的。6.2.3 框架与应用之间的关系(可选)容：框架(Framework)。意义：既然不适用Framework的开发越来越少了， 既然程序员犯的很多错误都和对 Framework理解不到位有关，架构师就有责任明确说明Framework和待开发系统之间的关系。参考：下图描述了 JGraph框架和待开发应用的关系。参考：下图描述了 Struts框架和待开发应用的关系。6.3 Project 2 容：对Project划分后的每个Project进行目录结构、 程序单元组织、框架与应用 关系的说明。6.4 Project n 容：对Project划分后的每个P

24、roject进行目录结构、 程序单元组织、框架与应用 关系的说明。7 .运行架构视图关注点：此架构设计视图的关注点是控制流组织。注意：进程和线程是广为人知的控制流实现技术，但在架构设计思维当中，对于系统软件和嵌入式软件极为重要的中断服务程序也是控制流，这样利于架构师统一利用不同控制流手段设计并行和并发。7.1 控制流组织容：控制流有哪些，每条控制流各是何种形式（例如进程、线程、中断服务程序） 哪些软件单元是控制流的起点，整条控制流中分别调用了哪些软件单元。意义：这是对系统运行时结构的刻画，主要反映系统的动态结构。7.2 控制流的创建、销毁、通信容：描述进程、线程和中断服务程序的创建和销毁，以及

25、多条控制流之间的通信关系的定义。意义：一旦引入了多条控制流，附加工作就产生了一一此时控制流的创建和销毁、以及控制流之间的通信关系往往是必须考虑的。7.3 加锁设计7.4 系统中有多条控制流在同时运行的情况下，一个经典问题是多于一条控制流可能会同时修改某些数据结构，而造成数据的不一致。为此，架构师需要关注加锁设计，合理引入临界区或同步机制。意义：加锁设计事关系统的正确性。值得注意的是，忽略加锁设计造成的问题往往以“不易重现的Bug”的形式出现，困惑的程序员会对测试人员说，“你看你报的Bug在我机器上根本就不存在呀"。参考：对通用组件、通用模块的设计而言，加锁设计应予以专门关注，思维要点

26、是研究未来通用模块的各种可能使用场景。8 .物理架构视图关注点：此架构设计视图的关注点是物理节点（Node）分布，以及软件到硬件的具体映射关系。注意：物理节点即可以是 PC机或服务器，也可以是单片机、单板机或专用机，从 而物理架构视图既适用于描述企业信息系统，也适合于描述嵌入式软件系统。1.1 物理拓扑容：一为硬件选型，二为硬件之间的拓扑连接关系。意义：对于分布式系统的设计，此节极为重要、而且是必须的。参考：下图是某企业级系统的物理拓扑图。说明：本文档模板由CSAI架构设计专家组荣耀发布，详细技术支持请访问.csai./admems/参考：下图是某嵌入式系统的物理拓扑图。1.2 软件到硬件的映

27、射容：明确每个物理节点上有哪些（一到多个）软件的目标单元，并说明具体的“映 射方式”是安装、是部署、还是烧写、抑或是下载。 意义：如果把此节漏了，就无法表明本文档的主题一一软件系统一一和上述硬件、 硬件拓扑的关系。参考：下图所示为设备调试系统中，软件到硬件的映射关系。调试机匚最人部分:' tsxLhex1.3 优化部署容：为达降低成本、提高性能和可靠性等等目标，应特别关注的部署考虑。意义：物理架构设计的优劣，造成的成本差异和质量差异，可能是天壤之别。所以 必须重视。参考：下图展示的，是 ADMEMS法重点推荐的“物理架构设计思维要点”，更多容戢终目标投资与娃护成 本合理特定性能目标 的满旦思雄要占计馨和通信笄需小减少计算和遢信时 内存/硬盘/CPW 朗绪冲突设加g容节点选择份布布扑软件单元和数据单 元的职责与分布增加C自由巳等设计经济性技木可行性易维护性性靛持续可用性可伸缩性通信开销计算开销旗盘争用网络争用目标层思维层CPU争用数据争用软件隼元数据单元网络物理节点结果层 可参考一线架构师实践指南一书。 9 .数据架构视图关注点：此架构设计视图的关注点是持久化。具体而言，场景化可以借助扁平文件、关系数据库、实时数据库、Flash等方式中的一种或多种完成。注意：本视图单独归档时，请在此节注