软考架构师（8）——软件架构设计

全文连接：http://www.javashuo.com/article/p-ofmsztfa-gz.html

一：架构模型

　　软件架构可概括为

（1）结构模型：这是一个最直观、最广泛的建模方法。这种方法以架构的构件、链接件（connector）和其余概念来刻画结构，并力图经过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质等。研究结构模型的核心是架构描述语言。

（2）框架模型：框架模型与结构模型相似，但它不太侧重描述结构的细节而更侧重于总体的结构。框架模型主要以一些特殊的问题为目标创建只针对和适应该问题的结构。

（3）动态模型：动态模型是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。例如，描述系统的从新配置或演化。动态能够指系统整体结构的配置、创建或拆除通讯通道或计算的过程。这类系统常是激励型的。

（4）过程模型：过程模型研究构造系统的步骤和过程。于是结构是遵循某些过程脚本的结果。

（5）功能模型：该模型认为架构是由一组功能构件按层次组成，下层向上层提供服务。它能够看做是一种特殊的框架模型。

5种，但各有所长，将它们有机统一块儿来也许更合适，因此有人提出了“4+1”视图模型： 

逻辑视图：逻辑视图关注功能，不只包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们多是逻辑层、功能模块等。

开发视图：开发视图关注程序包，不只包括要编写的源程序，还包括能够直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在必定的映射关系：好比逻辑层通常会映射到多个程序包等。

处理视图：处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通讯等问题。处理视图和开发视图的关系：开发视图通常偏重程序包在编译时期的静态依赖关系，而这些程序运行起来以后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。
物理视图：物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行状况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。

场景（scenarios）：能够看做是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发架构时，它能够帮助设计者找到架构的构件和它们之间的做用关系。同时，也能够用场景来分析一个特定的视图，或描述不一样视图构件间是如何相互做用的。场景能够用文本表示，也能够用图形表示。

二：架构需求与软件质量属性

1：软件质量属性

一是可在运行时肯定的系统系统质量属性，如性能，安全性，可用性和使用性

二是没法经过观察系统运行肯定的：可更改性，可移植性，可重用性，可集成性，可测试性

三是架构直接相关的：概念完整性，正确性，完整性，可构建性。

一、可用性及其实现
故障处置。
1）错误检测
日志 心跳 异常捕捉
2）错误恢复
冗余，备件，回滚，事务，降级
3）错误预防
事务等

二、可修改性及其实现
1）将修改限制在局部
高内聚低耦合，下降对其余模块的依赖；提升模块的通用性；限制变动范围等；
2）防止连锁反应
对扩展开放， 对更改关闭。
3）推迟绑定时间
配置文件，多态，注册

三、性能及其实现
1）减小及控制资源使用
2）资源管理
引入并发，缓存，增长资源
3）资源仲裁
资源调度

四、安全性及其实现
1）防护攻击
2）检测攻击
3）恢复

五、可测试性及其实现
1）输入输出
记录，接口与实现分离，用实现替代用于测试
2）内部监控

六、易用性及其实现
1）运用时
记录用户习惯，收集用户反馈
2）设计时
用户接口独立
3）支持用户主动操做

2：软件架构评估

名词解释

敏感点：敏感点是一个或多个构件（和/或构件之间的关系）的特性。研究敏感点可以使构设计师或系统分析师明确在搞清楚如何实现质量目标时应注意什么。

权衡点：权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

风险点

非风险点

质量属性效应树：

软件评估方式：

基于调查问卷（检查表）的方式

基于度量的方式

基于场景的方式：

架构权衡分析法（ATAM）

软件架构分析法（SAAM）

成本效益分析法（CBAM）

 

三：软件架构风格

架构设计的一个核心问题是能可否达到架构级的软件服用

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完成的系统

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（idiomatic paradigm）。

1：数据流风格

　　在管道/过滤器风格中，每一个构件都有一组输入和输出，构件读输入的数据流，通过内部处理，
而后产生输出数据流。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另外一个阶段的输入。

2：面向对象风格

面向对象风格创建在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操做封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。

2：调用返回风格

3：独立构件风格

4：虚拟机风格

5：仓库风格

黑板风格：语音识别的应用

6：基于事件的隐式调用

基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的全部过程，这样，一个事件的触发就致使了另外一模块中的过程的调用。

6．C2风格

C2（Component-Connector）架构风格能够归纳为：

经过链接件绑定在一块儿的按照一组规则运做的并行构件网络。C2风格中的系统组织规则以下：

（1）系统中的构件和链接件都有一个顶部和一个底部。

（2）构件的顶部应链接到某链接件的底部，构件的底部则应链接到某链接件的顶部，而构件与构件之间的直接链接是不容许的。

（3）一个链接件能够和任意数目的其它构件和链接件链接。

（4）当两个链接件进行直接链接时，必须由其中一个的底部到另外一个的顶部。从C2风格的组织规则和结构图中，咱们能够得出C2风格具备如下特色：

（1）系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一块儿。

（2）全部构件之间的通信是经过以链接件为中介的异步消息交换机制来实现的。

（3）构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。

 

6：两层 C/S 架构

C/S架构的优势主要在于系统的客户应用程序和服务器构件分别运行在不一样的计算机上，系统中每台服务器均可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，并且易于对系统进行扩充和缩小

7：三层C/S架构

8：三层 B/S 架构

不足：

B/S 架构缺少对动态页面的支持能力，没有集成有效地数据库处理功能

B/S架构的安全性难以控制

采用B/S架构的应用系统，在数据查询等响应速度上，要远低于C/S架构

B/S架构的数据提交通常以页面为单位，数据的动态交互性不强，不利于OLTP应用

9：混合架构风格

 

10：富换联网应用（RIA）

 

RIA-AJAX

11：基于服务的架构（SOA）

服务是一种为了知足某项业务需求的操做，规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

基于服务的架构（SOA）到实现方式：

1：WebService

2：ESB

12：特定领域软件架构（Domain Specific Software Architecture，DSSA）

DSSA是在一个特定应用领域中为一组应用提供组织结构参考的标准软件架构，是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标是支持在一个特定领域中多个应用的生成。

从功能覆盖的范围角度能够有两种理解方式：

（1）垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可做为系统的可行解决方案的一个通用软件架构。

（2）水平域：定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能，没法为系统提供完整的通用架构。

DSSA的基本活动包括：领域分析，领域设计，和领域实现。

其中：

领域分析的主要目的是获取领域模型，领域模型描述领域中系统之间共同的需求，即领域需求，

领域设计的主要目的是获取DSSA，DSSA描述领域模型中表示需求的解决方案，

领域实现的主要目的是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。

DSSA的参与者：主要包括领域工程人员和应用工程人员

领域工程人员：

领域专家：有经验的用户，提供关于领域中的系统需求规约和实现知识以及复审领域模型

领域分析人员：控制领域分析过程，获取领域知识，并将领域知识组织到领域模型中

领域设计人员：设计DSSA，验证DSSA的准确性与一致性

领域实现人员：根据领域模型和DSSA，开发可服用的软件架构，利用在工程技术从现有系统中提取可复用的软件构件

应用工程人员

系统分析人员：以领域模型为基础2，结合系统的个性差别，获取其应用需求

系统设计人员：以领域设计框架为基础，给出应用系统的总体架构

系统实现人员：按照真题设计框架，将构件链接起来，已建立应用系统

 

 

 四：软件产品线

软件产品线主要由两部分组成，分别是核心资源和产品集合。核心资源是领域工程的全部结果的集合，是产品线中产品构造的基础。

软件产品线开发有4个基本技术特色，即过程驱动、特定领域、技术支持和架构为中心。与其余软件开发方法相比，组织选择软件产品线的宏观上的缘由有：对产品线及其实现所需的专家知识领域的清楚界定；对产品线的长期远景进行了战略性规划。