首先什么是Pre-architecture?

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

  一名软件架构师,需要理解的大局观,是有效处理互相矛盾的需求目标;识别重大需求、特色需求、高风险需求;在相对短的时间内设计出一套正确且有效的架构等等。不仅需建立需求大局观还要学会降低架构失败风险,因为作为架构师,我们往往在需求的理解、权衡、取舍和补充这些方面能力严重不足。从概念架构到细化架构,先设计概念架构,构思关键问题的解决策略;再进行细化架构的设计,以保证为开发提供足够的指导和限制。简单理解,细化架构就是分割,将大问题化成小问题,将概念架构中的设计进行实现,概念架构难以支持并行开发,所以要有细化架构的过程,将概念具体化,用代码进行实现,细化架构和概念架构之间的典型差异。

  架构设计仅仅进行到概念架构层面,对支持团队的并行开发而言是远远不够的。书中有这样一个例子,在《方案书》确定之后,架构师觉得方案书被认可说明架构已经很明确,无需“再”架构,但是程序员并没有在实际开发中得到足够的指导和限制,这就是在第一个名言中所描述的“项目的系统架构尚未确定”,及概念架构之后没有进行深一层次的“规约”设计,及细化架构,细化架构及概念架构的区别如下表。

 
细化架构
概念架构
接口
核心地位
不关心明确的接口定义,只有抽象的组件和抽象的交互机制
子系统
通过子系统和模块来分割整个系统,并且子系统往往有明确的接口
只有抽象的组件,这些组件没有接口,只有职责,一般是处理组件、数据组件或连接组件中的一种。(有大组件分解成小组件的设计决策,非子系统的含义)
交互机制
“实在”的交互机制,如基于接口编程、消息机制或远程方法调用
概念化的

  在做任何架构设计时都要记住尽早开始架构设计,Pre-architecture阶段的好处:能够在需求没有“全面完成”的情况下开始架构设计。为了尽早开始架构设计,需要做好:让架构师参与需求分析工作;不能被动地等待完善的《软件需求规则说明书》出现的那一刻。在只要满足下面3个条件就可以开始架构设计工作:

  (1)有了明确的业务需求:必须保证甲、乙双方就建设系统的目标达成共识,《愿景文档》经过正式评审,并且明确了投资、工期标准、整合等约束条件;

  (2)了解全面的用户需求:系统能帮助用户干什么、不能干什么已经非常明确。如果采用用例技术,表现为“用例图”比较完善,没明显遗漏;

  (3)有了典型的行为需求;如果采用用例技术,表现为核心功能的《用例约束》已经定义。

  确定关键质量目标意义是:指定错误的质量属性目标(包括遗漏重要的质量属性),将面临客户不满、项目返工、同事抱怨……而确定关键质量主要完成以下两点:

  (1)根据系统所在领域的特点及系统规模等因素,确定架构设计重点支持哪些质量属性(例如高性能、可扩展性…)

  (2)分析上述质量属性之间的制约关系,第一时间指定权衡折衷的具体策略(例如明确高性能是第一位,可扩展性和高性能相矛盾时应照顾高性能要求,是否引入支持可扩展性的涉及需经过架构组评审)

  确定关键质量我们必须遵守的5大原则:

  (1)分类合适+必要扩充

  (2)考虑多方涉众

  (3)检查性思维

  (4)识别矛盾+划定优先级

  (5)严格程度符合领域和规模特点

  划分子系统的三种方法:

  (1)分层的细化

  (2)分区的引入(架构中引入分区,支持深度优先的迭代开发)

  (3)机制的提取(基于接口(或抽象类)的协作是机制,基于具体类的协作则算不上机制;实现不同的最终功能可以重用同一个机制),及“总-分-总”

   

  简单理解,细化架构就是分割,将大问题化成小问题,将概念架构中的设计进行实现,概念架构难以支持并行开发,所以要有细化架构的过程,将概念具体化,用代码进行实现,细化架构和概念架构之间的典型差异。

 

posted on 2020-04-12 21:24  雨过山  阅读(180)  评论(0编辑  收藏  举报