软件架构的概念及其相关知识点（软件架构包括哪三点）

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

二、软件架构设计重要性

1. 软件架构设计能够满足系统的性能、安全性、可维护性等品质

2. 软件架构设计能够帮助项目干系人(Stakeholder)更好地理解软件结构

3. 软件架构设计能够有效地管理系统的复杂性，并降低系统维护费用

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

三、将系统需求模型转换为架构模型是软件系统需求分析阶段的一项重要工作，如何采用表格或用例映射保证转换的可追踪性是在转换过程中需要关注的问题。

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

1、如何根据需求模型构建软件架构模型；

2、如何保证模型转换的可追踪性。

四、软件系统架构是关于软件系统的结构、行为和属性的高级抽象。

在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件的交互关系。

在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或者对象。软件系统架构不仅指定了软件系统的组织和拓扑结构，而且显示了系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理。

五、软件架构的主要作用：

1. 在设计变更相对容易的阶段，考虑系统结构的可选方案

2. 便于技术人员与非技术人员就软件设计进行交互

3. 展现软件的结构、属性与内部交互关系

软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。

六、ANSI/IEEE 147l1-2000 是对软件密集型系统的架构进行描述的标准。在该标准中，视图这一概念主要用于描述软件架构模型。在此基础上，通常采用视角描述某个利益相关人（Stakeholder）所关注架构模型的某一方面。架构则是对所有利益相关人关注点的响应和回答。

在 ANSI/IEEE 1471-2000 标准中，系统是为了达成利益相关人（Stakeholder）的某些使命（Mission），在特定环境（Enviroment）中构建的。每一个系统都有一个架构（Architecture）。架构（Architecture）是对所有利益相关人的关注点（Concern）的响应和回答，通过架构描述（Architecture Description）来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其它方面相关的利益。架构描述（Architecture Description）本质上是多视图的。每一个视图（View）是从一个特定的视角（Viewpoint）来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。视角（Viewpoint）的选择，基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或者分析技术。一个视图（View）包括一个或者多个架构模型（Model），一个模型也可能参与多个视图。模型较文本的表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。

七、1995 年 Kruchten 提出了著名的“4+1”视图，用来描述软件系统的架构。在“4+1”视图中，逻辑视图用来描述设计的对象模型和对象之间的关系；开发视图描述了软件模块的组织与管理；过程视图描述设计的并发和同步特征。

“4+1”视图中的“4”，指的是：逻辑视图、开发视图、过程视图、物理视图，“1”指的是场景视图。

场景视图又称为用例视图，显示外部参与者观察到的系统功能。

逻辑视图从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能。

开发视图又称为实现视图，显示的是源代码以及实际执行代码的组织结构。

处理视图又称为过程视图，显示程序执行时并发的状态。

物理视图展示软件到硬件的映射。

八、在 RUP 中采用“4+1”视图模型来描述软件系统的体系结构。在该模型中，最终用户侧重于逻辑视图，系统工程师侧重于部署视图。

在 RUP 中采用“4+1”视图模型来描述软件系统的体系结构。“4+1”视图包括逻辑视图、实现视图、进程视图、部署视图和用例视图。

分析人员和测试人员关心的是系统的行为，因此会侧重于用例视图；

最终用户关心的是系统的功能，因此会侧重于逻辑视图；

程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图；

系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程视图；

系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署视图。

九、基于构件开发中的构件（Component）是一个独立可交付的功能单元，外界通过接口访问其提供的服务。

在基于构件的开发中，构件包含并扩展了模块化程序设计中子程序、面向对象系统中对象或类和系统模型中包的思想，它是系统设计、实现和维护的基础。构件定义为通过接口访问服务的一个独立可交付的功能单元。

十、对象管理组织（OMG）基于 CORBA 基础设施定义了四种构件标准。其中，会话构件的状态信息是由构件自身而不是由容器维护。

对象管理组织（OMG）基于 CORBA 基础设施定义了四种构件标准:

1、实体（Entity）构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。

2、加工（Process）构件同样需要容器管理其持久化，但没有客户端可访问的主键。

3、会话（Session）构件不需要容器管理其持久化，其状态信息必须由构件自己管理。

4、服务（Service）构件是无状态的。

十一、软件架构是降低成本、改进质量、按时和按需交付产品的关键因素。以下关于软件架构的描述:

软件架构是降低成本、改进质量、按时和按需交付产品的关键因素，

1、 软件架构设计需要满足系统的质量属性，如性能、安全性和可修改性等

2、软件架构设计需要确定组件之间的依赖关系，支持项目计划和管理活动

3、软件架构能够指导设计人员和实现人员的工作

4、一般在设计软件架构之初，会根据用户需求，确定多个候选架构，并从中选择一个较优的架构，并随着软件的开发，对这个架构进行微调，以达到最佳效果。

十二、软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程。以下关于软件架构设计活动的描述：

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