软件架构的概念

软件架构是降低成本、改进质量、按时和按需交付产品的关键因素，软件架构设计需要满足系统的质量属性，如性能、安全性和可修改性等，软件架构设计需要确定组件之间的依赖关系，支持项目计划和管理活动，软件架构能够指导设计人员和实现人员的工作。一般在设计软件架构之初，会根据用户需求，确定多个候选架构，并从中选择一个较优的架构，并随着软件的开发，对这个架构进行微调，以达到最佳效果。

1.软件架构演化

为了适应用户的新需求、业务环境和运行环境的变化等，软件架构需要不断地进行自身的演化，也就是说软件架构的演化就是为了维持软件架构自身的有用性。 本质上讲，软件架构的演化就是软件整体结构的演化，演化过程涵盖软件架构的全生命周 期，包括软件架构需求的获取、软件架构建模、软件架构文档、软件架构实现以及软件架构维护等阶段。

什么软件架构演化如此重要？

首先，软件架构作为软件系统的骨架支撑着整个软件系统，是软件系统具备诸多好的特性的重要保障。因为最终软件系统的性能、可靠性、安全性和易维护性等是软件系统最重要的质量和功能属性，是决定软件系统是否被用户接受、是否具有市场竞争力、是否具有进一步改造升级的可能性、是否具有较长生命周期的重要因素；软件架构自身的好坏直接影响着它们是否满足用户需求，而软件架构演化正是为了保障这些方面向人们预期的方向发展的重要措施。 

2.两个层次（数据设计和体系结构设计）

软件体系结构的设计通常考虑到设计金字塔中的两个层次——数据设计和体系结构设计。

数据设计体现传统系统中体系结构的数据构件和面向对象系统中类的定义(封装了属性和操 作），体系结构设计则主要关注软件构件的结构、属性和交互作用。

3.软件架构复用的类型（机会复用和系统复用）

软件架构复用的类型包括机会复用和系统复用，机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。

4.视角（perspective)

当考虑架构时，重要的是从不同的视角（perspective)来检查，这促使设计师考虑具体架构的不同属性。例如：展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。

在ABSD（基于架构的软件设计）方法中，使用不同的视角来观察设计元素，一个子系统并不总是一个静态的架构元素，而是可以从动态和静态视角观察的架构元素。

将选择的特定视角或视图与Kruchten提出的类似，也就是逻辑视图、进程视图、实现视图和配置视图。使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能性能等。进程视图也称为并发视图，使用并发视图来检查系统多用户的并发行为。使用“并发”来代替“进程”，是为了强调没有对进程或线程进行任何操作，一旦这些执行操作，则并发视图就演化为进程视图。使用的最后一个视图是配置视图，配置视图代表了计算机网络中的节点，也就是系统的物理结构。

5.软件架构设计

软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程，在建立软件架构的初期，一般需要选择一个合适的架构风格，并将架构分析阶段已标识的构件映射到架构中，并分析这些构件之间的关系，一旦得到了详细的软件架构设计，需要邀请独立于系统开发的外部人员对系统进行评审。一般来说，软件架构设计活动将已标识构件集成到软件架构中，设计这些构件，但不予以实现。

软件架构设计不能捕获需求，软件架构设计是在需求捕获并进行分析之后开展的工作。

软件架构设计的主要目标是，确保体系架构能够为设计人员和实现人员所承担的工作提供可靠的框架。

软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和（ 交互作用 ），并通过多种（ 视图 ）全面描述特定系统的架构。

6.ANSI/IEEE 1471-2000标准

ANSI/IEEE 1471-2000是描述软件架构的第一个标准，其中要素的关系如下：

第一层：mission

第二层：Environment,System,Architecture

第三层：Stakeholder,Architectural Description,Rationale

第四层：Concern,Viewpoint,View

第五层：Library Viewpoint,Model

Mission：翻译成中文就是任务，使命。也就是为什么我们要做这个系统。可能的原因是为了更大的赢利，市场占有率更高，完善产品系列等等。

System：翻译成中文就是系统。具体的定义是：一系列组件，组织在一起，相互作用从而完成一个或者一些特殊的功能。

Model：直译成模型。就是用来表达视图的方法。直白地说，就是系统中各种元素是如何组织在一起发挥作用。用图形化的表示把看到的东西表达出来。

Architecture：系统架构。每个系统有一个架构。是对所有利益相关人的关注点（Concern）的响应和回答，通过架构描述（Architecture Description）来说明。

在ANSI/IEEE 1471-2000标准中，系统是为了达成利益相关人（Stakeholder）的某些使命（Mission），在特定环境（Enviroment）中构建的。每一个系统都有一个架构（Architecture）。架构（Architecture）是对所有利益相关人的关注点（Concern）的响应和回答，通过架构描述（Architecture Description）来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其他方面相关的利益。

架构描述（Architecture Description）本质上是多视图的。每一个视图（View）是从一个特定的视角（Viewpoint）来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。

视角（Viewpoint）的选择，基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或者分析技术。一个视图（View）包括一个或者多个架构模型（Model），一个模型也可能参与多个视图。模型较文本的表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。

7.架构风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

8.软件系统架构的描述

软件系统架构是关于软件系统的结构、行为和属性的高级抽象。在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件之间的交互关系。在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或者对象。软件系统架构不仅指定了软件系统的组织结构和拓扑结构，而且显示了系统需求和构成组件之间的对应关系，包括设计决策的基本方法和基本原理。

9.架构级的软件重用

软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。也就是说，能否在不同的软件系统中，使用同一架构。基于这个目的，学者们开始研究和实践软件架构的风格和类型问题。

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

对软件架构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。架构风格的不变部分使不同的系统可以共享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的架构。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

9.转换需要关注的问题

从本质上看，需求和软件架构设计面临的是不同的对象：一个是问题空间；另一个是解空间。保持两者的可追踪性和转换，一直是软件工程领域追求的目标。
从软件需求模型向SA模型的转换主要关注两个问题：
1、如何根据需求模型构建软件架构模型；
2、如何保证模型转换的可追踪性。