【软考系统架构设计师】软件架构的概念

软件架构的概念

1.1、架构设计概述

从需求分析到软件设计之间的过渡过程称为软件架构。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。

架构设计就是需求分配，将满足需求的职责分配到组件上。

软件架构为软件系统提供了一个结构、行为、属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成

软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。

解决好软件的服用、质量和维护问题，是研究软件架构的根本目的。

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

1.2、架构设计作用

软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、熟悉与内部交互关系。

软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量熟悉。

软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。

软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。

1.3 软件架构的重要性

软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。
1.架构设计能够满足系统的品质
系统的功能性是软件构架师通过组成体系架构的多种元素之间的交互作用来支持的。架构设计用于实现系统的品质，如性能、安全性和可维护性等。通过架构设计文档化，可以尽早的评估项目的这些品质。
2.架构设计使受益人达成一致的目标
架构设计的过程使得不同的受益人达成一致的目标，体系架构的过程需要确保架构设计被清楚地传达与理解。一个被有效传达的体系架构使得涉众们可以辩论决议和权衡反复讨论，最终达成共识。文档化体系架构是非常重要的，这是软件构架师的主要职责。
3构设计能够支持计划编制过程
架构设计将确定组件之间的依赖关系，直接支持项目计划和项目管理的活动，例如，细节化分，日程安排，工作分配，成本分析，风险管理和技能开发等；构架师还能协助估算项目成本，例如，体系架构决定使用第三方组件的成本，以及支持开发的所有工具的成本；构架师支持技术风险的管理，包括制定每一个风险的优先次序，以及确定一个当的风险缓解策略。
4.架构设计对系统开发的指导性
架构设计主要目标就是确保体系架构能够为设计人员和实现人员所承担的工作提供可靠的框架。很明显，这比简单的传送一个体系架构视图要复杂的多。为了确保最终体系架构的完整性，构架师必须明确的定义体系架构，因为它确定了体系架构的重要元素，例如系统的组件，组件之间的接口以及组件之间的通信。
构架师同时还必须定义当的标准和指导方针，它们将会引导设计人员和实现人员的工作。对开发过程活动采取怡当的架构回顾和评估，能够确保体系架构的完整性。这些QA（Quality Assurance，质量保障）活动的任务是确定体系架构的标准和指导方针的。
== 5，架构设计能够有效地管理复杂性==
如今的系统越来越复杂，这种复杂性需要我们去管理。体系架构通过构件及构件之
间关系，描述了一个抽象的系统，因而提供了高层次的复杂管理的方法。同样，架构设计过程考虑组件的递归分解。这是处理一个大的问题的很好的一个方法，它可以把这个大问题分解成很多的小问题，再逐个的解决
6.架构设计为复用定了基础
架构设计过程可以同时支持使用和建立复用资源。复用资源可以降低一个系统的成
本，并且可以改进系统的质量，这些好处已经被证明。一个体系架构的建立，能够支持
大粒度的资源复用。例如，体系架构的重要组件和它们之间的接口和质量，能够支持现
货供应的组件，存在的系统和封装的应用程序等的选择，从而可以用来实现这些组件。
7.架构设计能够降低维护费用
架构设计过程可以在很多方面帮助我们降低维护费用。首先最重要的是架构设计过
程要确保系统的维护人员是一个主要的涉众，并且他们的需求被作为首要的任务满足。
一个被当文档化的体系架构不应该仅仅为了减轻系统的可维护性；构架师还应该确保结合了怡当的系统维护机制，并且在建立体系架构的时候还要考虑系统的适应性和可扩充性。
8.架构设计能够支持冲突分析
构设计的一个重要的好处是它可以允许我们在取改变之前推断它所产生的影
响。一个软件构架确定了主要的组件和它们之间的交互作用，两个组件之间的依赖性以
及这些组件对于需求的可追性。有了这个信息，例如需求的改变等可以通过组件的影
响来分析。同样的，改变一个组件的影响可以在依靠它的其他组件上分析出来。

1.4、构件

构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务。

构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模板和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组的部署，但是他也能被单独的部署。

构件和原子构件之间的区别 在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。

一个模块是不带单独资源的原子构件。

一个单独的包被编译成多个单独的类文件–每一个公共类都有一个。

模块是一组类和可能的非面向对象的结构体，比如过程或者函数

1.5、构件和对象

构件的特性是：
1、独立部署单元；
2、作为第三方的组装单元；
3、没有外部的可见状态。一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。

对象的特性是：
1、一个实例单元，具有唯一的标志。
2、可能具有状态，此状态外部可见。
3、封装了自己的状态和行为。

1.6、构件接口

接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。

1.7、面向构件的编程

关注于如何支持建立面向构件的解决方案。面向构件的编程需要下列基本的支持：
1、多态性（可替代性）
2、模块的封装性
3、后期的绑定与装载
4、安全性

1.8、软件架构建模五大模型

• 结构模型：以架构的构件、连接件和其他概念来刻画结构；并试图以结构模型来反应整个系统的配置、内在逻辑等。
• 框架模型：不太侧重描述结构的细节而更侧重于整体的结构：主要是针对具体的问题为目标，来设计适应这个问题的模型。
• 动态模型：系统的大颗粒的行为性质；对结构模型和框架模型的补充，描述系统的演化
• 过程模型：构建系统的步骤和过程。
• 功能模型：由一组功能构件按层次组成，下层向上层提供服务

1.9、4+1视图

• 逻辑视图。主要支持系统的功能需求，即系统提供给最终用户的服务。用类图来描述
• 开发视图。也称为模块视图，在UML中被称为实现视图，它主要侧重于软件模块的组织和管理。通过系统V/0关系的模型图和子系统图来描述
• 进程视图。侧重于系统的运行特性，主要关注一些非功能性需求，例如系统的性能和可用性等。强调并发性、分布性、系统集成性和容错能力。定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。
• 物理视图。在UML中被称为部署视图，它主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。
• 场景。可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。对于于UML中的用例视图