概述
ADMENS(Architectural Design Method has been Extended to Method Eystem)方法体系：（3个阶段，1个贯穿）
1. PA阶段（预备架构）
2. CA阶段（概念架构）
3. RA阶段（细化架构）
l 非功能目标的考虑（贯穿）
（需求+质疑）驱动架构设计
质疑驱动：通过“质疑”引入更多质量属性和特殊功能场景
需求=功能+质量+约束
1. 功能需求：更多体现各级直接目标
2. 质量属性：运行期质量+开发期质量
3. 约束需求：业务环境因素+使用环境因素+构建环境因素+技术环境因素
PA阶段（预备架构）
任务：
1. 需求结构化---全面理解需求, 把握需求特点
2. 分析约束影响---发现非功能需求
3. 确定关键质量---发现非功能需求
4. 确定关键功能---概念设计的驱动力
方法：放弃需求列表，运用二维需求观，避免遗漏需求并进一步理清需求间关系和发现衍生需求（主要是非功能需求）。
二维需求表格式：
|
| 功能需求 | 质量 | 约束 |
| 业务级需求 （包含客户或出资者要达到的业务目标、预期投资、工期要求，以及符合哪些标准、对哪些遗留系统进行整合等约束条件） | 业务目标 | 快、好、省 | 技术性约束 法规性约束 技术趋势 竞争因素与竞争对手 遗留系统集成 标准性约束 分批实施 |
| 用户级需求 （用户使用系统来辅助完成哪些工作？对质量有和要求？用户群及所处的使用环境方面有何特殊要求？） | 用户需求 | 运行期质量 | 用户群特点 用户水平 多国语言 |
| 开发级需求 （开发人员需实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？） | 行为需求 | 开发期质量 | 开发团队技术水平 开发团队分布情况 开发团队磨合程度 开发团队业务知识 管理：产品规划 维护 |
质量属性关系矩阵：
“+”表示行促进列；“-”表示行影响列；“”表示行列两种质量属性之间影响不明显
|
| 持续可用性 | 性能 | 可扩展性 | 安全性 | 可互操作性 | 可维护性 | 可移植性 | 可靠性 | 可重用性 | 鲁棒性 | 可测试性 | 易用性 |
| 持续可用性 |
|
|
|
|
|
|
| + |
| + |
|
|
| 性能 |
|
| - |
| - | - | - | - |
| - | - | - |
| 可扩展性 |
| - |
| - |
| + | + | + |
|
| + |
|
| 安全性 |
| - |
|
| - |
|
|
| - |
| - | - |
| 可互操作性 |
| - | + | - |
|
| + |
|
|
|
|
|
| 可维护性 | + | - | + |
|
|
|
| + |
|
| + |
|
| 可移植性 |
| - | + |
| + | - |
|
| + |
| + | - |
| 可靠性 | + | - | + |
|
| + |
|
|
| + | + | + |
| 可重用性 |
| - | + | - | + | + | + | - |
|
| + |
|
| 鲁棒性 | + | - |
|
|
|
|
| + |
|
|
| + |
| 可测试性 | + | - | + |
|
| + |
| + |
|
|
| + |
| 易用性 |
| - |
|
|
|
|
|
|
| + | - |
|
实践
不同需求影响架构的不同原理，才是架构设计思维的基础
| 需求 | 基本原理 | 对架构设计的影响 |
| 功能 | 功能是发现职责的依据 | 每个功能都是一条“职责协作链”完成的，架构师通过为功能规划职责协作链、将职责分配到子系统、为子系统界定接口、确定基于接口的交互机制，来推动架构设计的进行 |
| 质量 | 质量是完善架构设计的驱动力 | l 基于当前的架构设计中间成果，进一步考虑具体质量要求，对架构设计中间成果进行细化、调整、甚至推到重来，一步步使架构设计完善起来。
l 质量和功能共同影响架构设计，抛开功能，单依据质量要求设计架构是不可能的。 |
| 约束 | 约束对架构设计的影响分为几类 | 直接制约设计决策的约束（如;“系统运行于unix平台上”） 转化为功能需求的约束（如“本银行系统执行现行利率”引出“利率调整”功能） 转化为质量属性需求的约束（如：“柜员平均计算机水平不高”引出“易用性”需求） |
二维需求观
具体参看上述二维需求观表
关键需求决定架构，其余需求验证架构
1. 功能需求做减法（挑选关键需求）；确定关键功能的法则：
l 核心功能
l 必做功能
l 高风险功能
l 独特功能
2. 质量属性需求做加法；确定关键质量的5大原则：
l 分类合适+必要扩充
l 考虑多方涉众
l 检查性思维
l 识别矛盾+划分优先级
l 严格程度符合领域与规模特点
3. 约束性需求做加法
l 业务环境因素
l 用户群及使用环境因素
l 开发及构建环境因素
l 业界当前技术因素
约束分析法则：
1. 按二维需求表从上至下、从左至右分析
2. 查漏法则：重点是质量属性遗漏
延伸阅读：RUP提倡的需求分类方法：需要（need）、特性(feature)、软件需求
RUP的优点：特性技术作为从需要向软件需求过渡的跳板
RUP的缺点：太依赖用例技术
CA阶段（概念架构）
任务：
1. 界定系统的高层组件以及它们之间的关系。
2. 对系统进行适当分解，而不陷入细节。
3. 规定每个组件的非正式规约及架构图，但不涉及接口细节
方法：
1. 基于关键功能，进行初步设计
2. 综合初步设计，确定高层分割
3. 考虑非功能需求，做出相应决策
实践：
概念架构设计分3个步骤：
1. 初步设计。基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计。
a) 鲁棒图的三种元素（涵盖MVC，比MVC更全面）
i. 边界对象（远程调用接口、设备、用户界面【对应View】）
1. 系统与外部“人”的交互
2. 系统和外部“系统”的交互
3. 系统和外部“设备”的交互
ii. 控制对象（应用逻辑【对应Controler】、业务逻辑【对应Model】、数据访问逻辑）
iii. 实体对象（数据【持久化对象+内存中的对象】）
b) 鲁棒图建模的10条经验
i. 语法：遵守建模规则（UML用例驱动对象建模方法）
ii. 语法：简化建模语法
iii. 思维：遵循3种元素的发现思路（用例=N个场景）
iv. 思维：增量建模
v. 思维：实体对象不等于持久化对象（还有内存中的对象）
vi. 技巧：只对关键功能（用例）画鲁棒图
vii. 技巧：每个鲁棒图有2至5个控制对象（如果只含有1个控制对象，则明显设计不足，如果过多，可能考虑过多细节，应进行归并）
viii. 注意：勿关注细节
ix. 注意：勿过分关注UI，除非辅助或验证UI设计
x. 注意：鲁棒图不等于用例规约的可视化
2. 高层分割。对系统这个黑盒子进行高层切分，如切分复杂系统为多个二级系统，或者直接切分为具体子系统。
a) “架构=模块+接口”的不足
i. 忽视了多视图，架构=模块+接口仅是逻辑架构设计视图的核心内容。
ii. 忽略了概念架构设计。对于大系统，必须先根据重大风险，有针对性地制定包括“高层分割”在内的设计决策，然后才是建模一级的设计。
b) 两种实践套路
i. 切系统为系统
1. 系统比较复杂，须进行两级高层切分
2. 先把系统切成更小一级的系统，每个更小一级的系统都可以有单独的需求、设计、实现。。。
3. 之后，对每个“更小一级的系统”进行“切系统为子系统”
ii. 切系统为子系统（4层架构方式）
1. 展现层（界面部分）
2. 业务层（业务逻辑部分）
3. 数据层
4. 集成层（访问外部系统、接口、交换数据的格式）
c) 分层式概念架构方法
i. 逻辑层
1. 重视职责的划分，职责之间的上下层级关系。不关心上下层是否“能分布”在不同的机器上。
ii. 物理层
1. 指“能分布”在不同机器上的软件单元，不同物理层之间必须有跨机器访问的能力，可以通过远程调用、或通信协议等方式。如Java EE分层架
2. 几层架构是看“能分布”的能力，不是看“实际部署情况”。
iii. 按通用性分层
1. 将通用性不同的部分划归不同的层，以此作为系统的总体切分方式。
2. 如：应用特定层、业务相关层、中间件层、系统软件层
iv. 技术堆叠
1. 不是独立的架构模式，而是基于分层架构提供的进一步说明。
d) 注意点
i. 高层分割很重要，但不是概念架构的全部。
ii. 概念架构还包括技术选择、权衡策略等种类决策。如支持各种相互矛盾的非功能需求，仅调整切分方式是远远不够的。
3. 考虑非功能需求。采用admens的“目标-场景-决策表”
a) “目标-场景-决策表”看上面的介绍
b) 作为概念架构的进一步完善和调整。
RA阶段（细化架构）
功能：
针对概念架构进行细化架构设计
方法：五视图法
逻辑架构
a) 功能
i. 职责划分
ii. 职责间协作
b) 策略（三维思维）
i. 分层细化（对概念架构的逻辑层进一步细化分层）
ii. 分区引入（分区是一个单元，它位于某个层的内部，以支持迭代式开发）
iii. 机制提取（基于抽象角色的协作方式和协作流程。如消息机制）
c) 划分子系统的4个重要原则
i. 职责不同的单元划归不同子系统
ii. 通用性不同的单元划归不同子系统
iii. 需要不同开发技能的单元划归不同子系统
iv. 兼顾工作量的相对均衡，进一步切分太大的子系统
d) 整体思路
i. 质疑驱动（不断设计中间成果à不断质疑中间成果à不断调整完善细化中间成果）
ii. 结构设计（手段就是分层细化、分区引入、机制提取）和行为设计（让切分出来的职责协作起来，验证能否完成功能。可用时序图实现）相分离
e) 逻辑架构设计的10条经验
i. 划分子系统：分层的细化
ii. 划分子系统：分区的引入
iii. 划分子系统：机制的提取
iv. 接口的定义：协作决定接口
v. 选用序列图：杜绝协作图
vi. 包-接口图：从结构到行为的桥
vii. 灰盒包图：描述关键子系统
viii. 循序渐进的螺旋思维
ix. 设计模式：包内结构
x. 设计模式：包间协作
数据架构
f) 内容
i. 持久数据单元
ii. 数据存储格式
g) 数据分布的6中策略
i. 独立（划分的应用程序不同。尽量采用该分布策略，以减少系统之间的无谓影响）
ii. 集中（一个系统支持不同地点的访问）
iii. 分区（相同的应用程序、不同的应用程序部署实例、相同的数据模型、不同的数据值）
iv. 复制
v. 子集（通过数据“本地化”，提升数据访问性能；数据的专门副本，利于有针对性地进行优化；数据的专门副本，便于提高可管理性，加强安全机制；减少跨机器进行数据传递的开销；降低了数据冗余，节省了存储成本）
vi. 重组
h) 数据分布策略的3条原则
i. 把握系统特点，确定分布策略（合适原则）
ii. 不同分布策略，可以综合运用（综合原则）
iii. 从“对吗”、“好吗”两方面进行评估优化（优化原则）
|
| 对吗？ （功能方面） | 好吗？ （非功能方面） | 备注 |
| 分区 | 100 | 30 |
|
| 复制 | 100 | 20 |
|
| 子集 | 30 | 90 |
|
| 集中 | 100 | 50 |
|
| 独立 | 100 | 30 |
|
如上图：则采用子集+集中策略
物理架构
i) 功能
i. 硬件选择与物理拓扑
ii. 软件到硬件的映射关系
iii. 方案的优化
j) 关注
i. 数据短缺
ii. 数据争用
iii. 增加硬件=增加计算能力 不等于软件的实际服务能力增强
iv. 如何配置硬件和网络来满足软件系统的可靠性、持续可用性、性能、安全性等方面要求
k) 设计思维（攻与守）
i. 高性能（攻）
ii. 持续可用性（攻）
iii. 可伸缩性（攻）
iv. 经济性（守）
v. 技术可行性（守）
vi. 易维护性（守）
vii. 。。。
viii. 降低开销和避免争用是核心，实现高性能、高可伸缩性等最终目标。
1. 如何降低物理节点“内”的计算开销
2. 如何降低物理节点“间”的通信开销
3. 如何避免物理节点“内”cpu、内存、硬盘等资源争用？
4. 如何避免物理节点“间”网络的带宽资源冲突？
运行架构
l) 内容
i. 确定引入哪些控制流
ii. 确定每条控制流的任务
iii. 处理相关问题：控制流的创建、销毁、通信机制等
iv. 进一步考虑：控制流之间的同步关系，若有资源争用还要引入加锁机制
m) 需考虑
i. 物理架构的每个节点之上至少有一条控制流
ii. 为了实现节点之间的通信，通常做法是引入一条控制流来专门负责
iii. 节点是具有主动行为的设备，通常做法是引入专门的控制流（如;中断服务程序）
iv. 在需求一级的描述中（如用例规约）就是并行或并发的，引入多条控制流
v. 来自用户或外部系统的并发访问，常要求后端服务支持多控制流
vi. 如果控制流复杂，可考虑引入对其控制流进行协调的控制流
n) 输出
i. 控制流图
o) 手段
i. 进程
ii. 线程
iii. 中断服务程序
开发架构
p) 内容
i. 将“逻辑职责”映射为“程序单元”
1. 要自主编写的源程序
2. 可重用的库、框架
3. 其他方式（如shell脚本、平台支持下的配置文件）
ii. 开发技术选型
1. 开发语言
2. 开发工具
iii. “程序单元”间关系
1. 程序project划分
2. 程序project目录结构
3. 编译依赖关系
非功能目标的考虑（贯穿）
使命：贯穿三阶段设计充分考虑非功能目标
方法：“目标-场景-决策”表法
| 目标 | 场景 | 决策 |
| 性能 | 重复请求页面，web服务器请求数多负载压力大 | 代理服务器 |
| 重复请求页面，页面生成逻辑重复执行 | Html静态化 | |
| 大量请求图片资源，web服务器压力大 | 图片服务器 |
1. 核心手段是场景技术。（发现场景、评估场景）
2. 设计更有针对性
3. 可操作性强
4. 避免过度设计（权衡场景发生的几率、支持场景带来的价值、遗漏场景的代价等因素）
5. 便于系统升级时参考（避免系统产生新需求时，架构师过多否定原架构，新架构也许能满足新需求，但同时也失去了已有架构的优点）
场景5要素
1. 影响来源。来自系统外部或内部的触发因素
2. 如何影响、影响来源施加了什么影响
3. 受影响对象。默认为本系统
4. 问题或价值。受影响对象因此出现什么问题，或者需要体现什么价值
5. 所处环境。此时，所处的环境或上下文为何
场景发现工具：
| 场景卡 | |||
| if | then | ||
| 程序 | 大量更新数据 | 数据复制开销 | 非常大 |
| Context:已部署了多个dbms实例以增加数据处理能力 | |||
场景评估：（某些场景可决定不支持）
1. 价值大小
2. 代价大小
3. 开发难度高低
4. 技术趋势
5. 出现几率
最后
以上就是舒适树叶为你收集整理的《一线架构师》读书笔记ADMENS(Architectural Design Method has been Extended to Method Eystem)方法体系：（3个阶段，1个贯穿）（需求+质疑）驱动架构设计PA阶段（预备架构）CA阶段（概念架构）RA阶段（细化架构）非功能目标的考虑（贯穿）的全部内容，希望文章能够帮你解决《一线架构师》读书笔记ADMENS(Architectural Design Method has been Extended to Method Eystem)方法体系：（3个阶段，1个贯穿）（需求+质疑）驱动架构设计PA阶段（预备架构）CA阶段（概念架构）RA阶段（细化架构）非功能目标的考虑（贯穿）所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复