一线架构师实践指南总结（二）—— Pre-architecture

深藏阁楼爱情的钟 2022-05-08 02:36 260阅读 0赞

## 什么是Pre-architecture ##

Pre-architecture就是架构设计的最前期阶段，其工作目标包括：理解需求、建立需求大局观、确定架构设计方向等。

## 实际意义 ##

**需求理解的大局观**  
有效处理互相矛盾的需求目标；  
识别重大需求、特色需求、高风险需求；  
相对短的时间内设计架构；  
等等

**降低架构失败风险**  
架构师在需求的理解、权衡、取舍和补充这些方面能力严重不足。

**尽早开始架构设计**  
Pre-architecture阶段的好处：能够在需求没有“全面完成”的情况下开始架构设计。  
为了尽早开始架构设计，需要做好：让架构师参与需求分析工作；不能被动地等待完善的《软件需求规则说明书》出现的那一刻。  
只要满足下面3个条件就可以开始架构设计工作：  
1.有了明确的业务需求：必须保证甲、乙双方就建设系统的目标达成共识，《愿景文档》经过正式评审，并且明确了投资、工期标准、整合等约束条件；  
2.了解全面的用户需求：系统能帮助用户干什么、不能干什么已经非常明确。如果采用用例技术，表现为“用例图”比较完善，没明显遗漏；  
3.有了典型的行为需求；如果采用用例技术，表现为核心功能的《用例约束》已经定义；

**明确架构设计的“驱动力”**  
除了需要关注《软件需求规格说明书》之外，必须关注其他很多因素，最终理性地确定真正的架构设计“驱动力”。

## 实践要领 ##

**不同需求影响架构的不同原理，才是架构设计思维的基础**  
“需求决定架构”是对的，但不同需求影响架构的不同原理，才是架构设计思维的基础。  
不同需求是如何以不同原理影响架构设计：  
![在这里插入图片描述][70]

**二维需求观与ADMEMS矩阵方法**  
ADMEM方法提倡的“二维需求观：  
![在这里插入图片描述][70 1]  
观念是行为的向导，有怎样的观念存在，就有怎样的行为方式产生。

**关键需求决定架构，其余需求验证架构**  
关键需求决定架构：功能需求做减法；质量属性需求做加饭；约束性需求做加法；

**Pre-architecture阶段的4个步骤**  
![在这里插入图片描述][70 2]

## 需求结构化 ##

需求结构化可以将复杂的需求集合梳理得井井有条，为进一步分析不同需求之间的联系、识别遗漏的重要需求打下坚实的基础。

**需求结构化要怎么做？**  
1.超越《软件需求规则说明书》  
需求文档往往不够全面；  
需求经常变更，仅依赖需求文档往往使架构设计工作非常被动；  
架构师通过需求结构化真正全面地“鸟瞰”需求大局，就必须超越《软件需求规则说明书》；  
能够摆脱对《软件需求规则说明书》提交时间、文档质量、内容变更的“呆板依赖”；

2.ADMEMS矩阵  
![在这里插入图片描述][70 3]  
业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。  
用户级需求：用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？  
开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？

需求还要从下面3个方面考虑：  
功能需求：更多体现各级直接目标要求。  
质量属性：运行期质量 + 开发期质量。  
约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素

## 分析约束影响 ##

约束性需求中隐藏了大量的风险因素。有经验的架构师都懂得主动分析约束影响，识别架构影响因素，以便在架构设计中引入响应决策予以应对（尽早识别风险）。

**分析约束影响的方法**  
1.约束分类方式  
ADMEMS对约束分类方式进行革新，使它更符合实践的需要。不仅注意到约束对架构设计的重大影响，还强调约束分类理论应该直接体现“这些约束来自于哪些涉众”。  
如下图所示，4类约束在ADMEMS矩阵中表明：业务环境、使用环境、构建环境应分别考虑客户、用户、开发方这3类涉众，技术环境则与3类涉众都有关。  
![在这里插入图片描述][70 4]

2.使用Big Picture理解约束  
![在这里插入图片描述][70 5]

3.使用ADMEMS矩阵方法辅助约束分析  
从本质讲，分析约束影响就是分析各个需求项之前的关系，并发现被遗漏的需求。所以，将需求“化复杂为清晰”的ADMEMS矩阵方法可以作为分析约束影响的基础——即在需求项清晰定位的前提下，找到不同需求之间的关系、发现遗漏需求。  
ADMEMS矩阵方法应用法则：  
推导法则：从上到下，从右到左。  
查漏法则：重点是质量属性遗漏。

## 确定关键质量 ##

**确定关键质量目标意义**  
指定错误的质量属性目标（包括遗漏重要的质量属性），将面临客户不满、项目返工、同事抱怨……

**确定关键质量主要完成**  
1.根据系统所在领域的特点及系统规模等因素，确定架构设计重点支持哪些质量属性（例如高性能、可扩展性…）  
2.分析上述质量属性之间的制约关系，第一时间指定权衡折衷的具体策略（例如明确高性能是第一位，可扩展性和高性能相矛盾时应照顾高性能要求，是否引入支持可扩展性的涉及需经过架构组评审）

**确定关键质量的5大原则**  
1.分类合适+必要扩充  
2.考虑多方涉众  
3.检查性思维  
4.识别矛盾+划定优先级  
5.严格程度符合领域和规模特点  
![在这里插入图片描述][70 6]

## 确定关键功能 ##

**为什么不是“全部功能作为驱动因素”**  
功能影响架构具体原理：职责协作链：  
![在这里插入图片描述][70 7]  
不同功能的职责协作链之间可能有职责的重叠；在功能数量比较多的时候，职责重叠将是不可避免的。既然如此，没必要将所有功能都一视同仁地研究一遍。相反，在所有功能中筛选一个功能子集，研究功能子集中每个功能的职责协作链，从而识别出组成系统的所有职责单元。

## 确定关键功能的4条规则 ##

1.核心功能  
2.必做功能  
3.高风险功能  
4.独特功能  
另外，确定关键功能子集时，必须注意：  
1.“关键功能子集”的确定并不存在“标准答案”；  
2.值得专门说明的还有“关键功能所占比例”的问题；

![在这里插入图片描述][70 8]

[70]: /images/20220508/da654867c8bc4b0eb7e8878749fa4b78.png
[70 1]: /images/20220508/9ae103f244b34a1e8c5140d7b29b33da.png
[70 2]: /images/20220508/73b20adba89e445caa497e3f7685891a.png
[70 3]: /images/20220508/84cff814a6394fda920a234b01405589.png
[70 4]: /images/20220508/4db60f0fbc17488b84a5aadc23379a30.png
[70 5]: /images/20220508/5fe0d7cef9ae47688e4bd16ff688bdc7.png
[70 6]: /images/20220508/a53f45256b2144b1ad226e095ff26ab4.png
[70 7]: /images/20220508/0e12dac96287475ea1f5cff7c2222899.png
[70 8]: /images/20220508/9e26561caa2a43e0afb7f8a1f19c45cf.png