框架师详细资料

第一章:架构概述

1.1简介

1. 此处将架构作为一种名词,以为这一组“工件”,包括像蓝图或构件规范这样的文档。

2. 架构,就是所构建系统的计划,确保由此得到期许的特性,同时也是所构建系统的描述。

3. 当代架构师可能会说,待构件的对象或系统应具有以下特性:

l 具备客户要求的功能。

l 能够在要求的工期内安全的构建。

l 性能足够好

l 安全的

l 可靠地

l 可用的,并且使用时不会造成伤害

l 成本是可接受的

l 符合法律规范

l 将超越强人及竞争者。

我们从来没有见过一个复杂的系统能够很好的满足上述特性,架构是一种折中——改进上述的某一方面往往会对其他方面造成影响。架构师需要决定如何做需要好,方法就是发现特定系统中的重要关注点,以及充分满足这些关注点的条件。

4. “架构”意味着不变的深层次结构。

5. 架构师必须做出许多设计决定,要想有用,这些决定必须用文档记录下来,供后续复审,讨论,修改,批准,然后作为后续决定和构建时的约束。对于软件系统,这些决定可能是行为上的和结构上的。

6. 我们使用“架构”这个词来代指一组有标注的图纸,他说明了描述和构建一个系统时所使用的结构。

7. 架构是系统设计的一部分,它突出了某些细节,并通过抽象省略掉了另一部分细节。关注系统组件实现的开发者可能不会关注这些组件如何装配在一起,而是关注少数组件的设计和开发,包括他们必须遵循的架构约束和可以应用的规则。

1.2创建软件架构

1. 软件架构师的首要关注点不是系统的功能

2. 成功架构师的两项关键实践:1.让利益相关人员参与 2.同时关注功能和品质。

3. 典型的利益相关人及他们的关注点:

l 投资人:关注项目是否在给定的资源和进度约束下完成。

l 架构师,开发,测试人员:关注最初的构建及以后的维护与演进

l 项目经理:组织团队,制定计划

l 市场人员:通过品质的特点实现竞争中的差异化

l 用户:包括最终用户,系统管理员,安装,部署人员,配置人员。

l 技术支持人员:关注帮助平台电话的呼入数目及复杂性。

4. 架构师了解相关利益人员的关注点后,下一步应考虑折中。例如:信息加密将增强安全性,但会损失性能。利用配置文件将增强可变性,但会降低可用性。创建系统的架构涉及许多这样艰难的折中。

5. 架构师的第一项任务,就是与相关利益关注人合作,理解这些品质关注点和约束,并为它们排列优先

6. 概念完整性是架构的重要特征:“最好是让系统……反映一组设计思想,而不是让系统包含许多好的思想,而这些思想却相互独立不协调”。这种概念完整性可以让开发者知道了一部分系统后,迅速的了解系统的另一部分。

7. 架构师通常在项目中需要考虑的关注点:

n 功能性(Functionality)

u 产品向他的用户提供哪些功能?

n 可变性(Changeability)

u 软件将来需要哪些改变?哪些改变太可能发生

n 性能(Performance)

u 产品将达到怎样的性能?

n 容量(Capacity)

u 多少用户将并发使用该系统?该系统将为多少用户保存数据?

n 生态系统(Ecosystem)

u 在部署的生态环境中,该系统将与其他系统进行哪些交互?

n 模块化(Modularity)

u 如何将编写软件的任务分解为工作指派(模块),特别的这些模块可以独立的开发,并能够准确而容易的满足彼此的需求

n 可构建性(Buildability)

u 如何将软件构建为一组组件,并能够独立实现和验证这些组件?哪些组件应该复用其他的产品,哪些应该从外部供应商处获得

n 产品化(Producibility)

u 如果产品以几种变体的形式存在,如何开发一个产品线,并利用这些变体的共性?产品线中的产品以怎样的步骤开发?

n 安全性(Security)

u 产品是否需要用户认证,或者必须限制对数据的访问?数据的安全性如何得到保证?如何抵挡攻击?

1.3架构结构

1. 架构师的主要关注点就是对系统进行组织(组织成一些结构),让每种结构有助于解答一个关注点所定义的问题。关键的结构决定将产品划分为组件,并定义了这些组件之间的关系。

2. 信息隐藏结构(整体—部分,包含,依赖):

a) 组件与关系:主要组件是一些“信息隐藏模块”,每个模块都是针对一组开发人员的工作指派,每个模块包含了一种设计决定。

b) 如果一种设计决定可以改变,同时又不影响其他模块,我们就说这项设计决定是一个模块的秘密。

c) 模块间最基本的关系:整体—部分。如果”信息隐藏模块A”的秘密是”信息隐藏模
块B”的秘密的一部分,则A就是B的一部分(必须能在改变A的秘密的同时,不改变B的其他部分)

d) 每个模块都是一个工作指派,包含一组要写的程序。第二种信息隐藏模块结构是基于程序和模块之间的包含关系。如果模块M的一部分工作指派是要编写程序P,则M包含P。

e) 如果改变B的接口就需要A也发生改变,则我们就说A“依赖”B的接口。

f) 整体部分结构 和 包含结构 是层次状的,依赖不一定。

3. 使用结构:

a) 使用结构的组件是一些可以单独调用的程序(可以相互调用或被硬件调用,或被其他命名空间的程序调用)

b) 如果程序B必须存在并满足其规格说明,程序A才能满足其规格说明,则称为A使用了B。(也就是B必须存在 且操作正常,A才能操作正常)

c) 具有层次使用结构的系统可以同时构造一层或几层。

4. 进程结构:

a) 信息隐藏结构和使用结构是静态结构,存在于设计时和编码时,进程结构是运行时结构。

b) 参与进程结构的组件是进程。进程是运行时的事件序列,由程序控制。

c) 每个程序都作为一个或多个进程的一部分执行,一个进程中的事件序列的执行独立于另一进程中的事件序列,除非这两个进程彼此同步(例如一个进程等待来自另一个进程的信号或消息)

5.访问结构

a) 系统中的数据可能划分成为具有属性的段,如果程序对段中的任何数据拥有访问权,就对该段中的所有数据拥有了访问权。

6. 结构小结:

结构 组件 关系 关注点
信息隐藏结构 信息隐藏模块 整体—部分

包含

可变性

模块化

可构建性

使用结构 程序 使用 产品化

生态系统

进程结构 进程(任务,线程) 提供工作

取得资源

共享资源

包含在模块中

……

性能

可变性

容量

数据访问结构 程序和数据访问 有权访问 安全性,生态系统

1.4好的架构

1. 对于一组给定的功能需求和品质需求,没有唯一的正确架构。应对架构进行评估,确定其是否满足需求。

2. 架构评估常见的两种方式:

i. 第一种是确定架构的属性,通常通过建模或模拟系统的一个或多个方面。如:通过性能建模来评估吞吐量和伸缩性。通过失效树模型评估可靠性和可访问性。

ii. 第二种方式是通过对架构师提出质询来评估该架构(使用最广泛)。

1. 架构折中分析方法(ATAM,是质询方法的变体),他寻找架构不能满足品质关注点的风险。ATAM使用场景分析,每种场景模拟了不同利益相关人员对系统的品质关注点,架构师分别解释该架构如何支持每一种场景。

2. 主动复审是另一种质询方法,他要求架构师向复审者提供架构师认为重要且需要回答的问题,然后复审者利用已有的架构文档和描述来回答这些问题。

1.5 美丽的架构

1. 判断架构是否足够好:是否有可能指导开发者和测试者构建一个系统,并满足利益相关人的功能和质量关注点。

2. 超越足够好的架构:

i. 实用性:每天被许多人使用

ii. 可构建性:具有定义良好的使用结构的架构,支持增量式构建,具有定义良好的模块接口,本来就很好测试的架构。

iii. 持久性:经历了时间考验,预期到变更的需要,允许期望的修改能够容易而有效的进行。避免“衰老地平线”。

iv. 架构特征,使得使用,构建,测试这些架构的开发人员和测试人员 及由它而形成的系统的使用者感到愉悦。

标签