软件架构概述
从需求分析到软件设计之间的过渡过程称为软件架构。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。
架构设计就是需求分配，将满足需求的职责分配到组件上。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成。
软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。
解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。
软件架构设计包括提出架构模型，产生架构设计和进行设计评审等活动，是一个选代的过程。架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。
软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。
软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
软件架构设计与生命周期【软件架构（Software Architecture）】
-
需求分析阶段。需求分析和SA设计面临的是不同的对象：一个是问题空间；另一个是解空间。从软件需求模型向SA模型的转换主要关注两个问题：如何根据需求模型构建SA模型。如何保证模型转换的可追踪性。
-
设计阶段。是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：SA模型的描述SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为3个层次：SA的基本概念（构件和连接子）、体系结构描述语言ADL、SA模型的多视图表示。
-
实现阶段 。最初SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现SA设计向实现的转换，实现阶段的体系结构研究表现在以下几个方面。
（1）研究基于SA的开发过程支持，如项目组织结构、配置管理等。
（2）寻求从SA向实现过渡的途径，如将程序设计语言元素引I入SA阶段、模型映射、构件组装、复用中间件平台等。
（3）研究基于SA的测试技术。
- 构件组装阶段 。在SA设计模型的指导下，可复用构件的组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。研究内容包括如下两个方面。
（1)如何支持可复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持。
（2)在组装过程中，如何检测并消除体系结构失配问题。
在构件组装阶段的失配问题主要包括：由构件引起的失配、由连接子引起的失配、由于系统成分对全局体系结构的假设存在冲突引起的失配等。
- 部署阶段 。SA对软件部署作用如下。
（1）提供高层的体系结构视图来描述部署阶段的软硬件模型。
（2）基于SA模型可以分析部署方案的质量属性，从而选择合理的部署方案。
- 后开发阶段 。是指软件部署安装之后的阶段。这一阶段的SA研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。
（1）动态软件体系结构。现实中的软件具有动态性，体系结构会在运行时发生改变。运行时变化包括两类：软件内部执行所导致的体系结构改变；软件系统外部的请求对软件进行的重配置。包括两个部分的研究：体系结构设计阶段的支持、运行时刻基础设施的支持。
（2）体系结构恢复与重建。对于现有系统在开发时候没有考虑SA的情况，从这些系统中恢复或重购体系结构。从已有的系统中获取体系结构的重建方法分为4类：手工体系结构重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其他技术（如数据挖掘等）。
构件
构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务。
构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但是它也能够被单独部署。
构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署尽管它们可以被单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。
一个模块是不带单独资源的原子构件。
一个单独的包被编译成多个单独的类文件一一每个公共类都有一个。
模块是一组类和可能的非面向对象的结构体，比如过程或者函数。
构件的特性是：
（1）独立部署单元；
（2）作为第三方的组装单元；
（3）没有（外部的）可见状态。
一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。
将一个类拆分进行部署通常没什么意义。
对象的特性是：
（1）一个实例单元 ，具有唯一的标志。
（2）可能具有状态 ，此状态外部可见。
（3）封装了自己的状态和行为。
构件接口
接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。
面向构件的编程(COP)
关注于如何支持建立面向构件的解决方案。面向构件的编程需要下列基本的支持:
（1）多态性（可替代性）；
（2）模块封装性（高层次信息的隐藏）；
（3）后期的绑定和装载（部署独立性）；
（4）安全性（类型和模块安全性）。
构件技术
构件技术就是利用某种编程手段，将一些人们所关心的，但又不便于让最终用户去直接操作的细节进行了封装，同时对各种业务逻辑规则进行了实现，用于处理用户的内部操作细节。目前国际上常用的构件标准主要有三大流派：
EJB(EnterpriseJava Bean)规范由Sun公司制定，有三种类型的EJB，分别是会话Bean(Session Bean)、实体Bean(EntityBean)和消息驱动Bean(Message-driven Bean)。EJB实现应用中关键的业务逻辑，创建基于构件的企业级应用程序。
COM、DCOM、COM+COM是微软公司的。DCOM是COM的进一步扩展，具有位置独立性和语言无关性。COM+并不是COM的新版本，是COM的新发展或是更高层次的应用。
COBRA标准主要分为三个层次：对象请求代理、公共对象服务和公共设施最底层是对象请求代理ORB，规定了分布对象的定义（接口）和语言映射，实现对象间的通讯和互操作，是分布对象系统中的"软总线"；
在ORB之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种各样的服务；
最上层的公共设施则定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。
软件架构风格
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。
架构设计的一个核心问题是能否达到架构级的软件复用。
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
数据流风格：面向数据流，按照一定的顺序从前向后执行程序，代表的风格有批处理序列、管道-过滤器。
调用/返回风格：构件之间存在互相调用的关系，一般是显式的调用，代表的风格有主程序/子程序、面向对象、层次结构。
独立构件风格：构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行，代表的风格有进程通信、事件驱动系统（隐式调用）。
虚拟机风格：自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表的风格有解释器、基于规则的系统。
仓库风格：以数据为中心，所有的操作都是围绕建立的数据中心进行的，代表的风格有数据库系统、超文本系统、黑板系统。
数据流风格
批处理序列：构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。
管道-过滤器：每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为后一个构件的输入，前后数据流关联。过滤器就是构件，连接件就是管道。
早期编译器就是采用的这种架构，要一步一步处理的，均可考虑此架构风格。
二者区别在于批处理前后构件不一定有关联，并且是作为整体传递，即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入，前面执行到部分可以开始下一个的执行。
调用/返回风格
主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块==。过程调用作为交互机制，充当连接件的角色==。
面向对象：构件是对象，对象是抽象数据类型的实例。连接件即使对象间交互的方式对象是通过函数和过程的调用来交互的。
层次结构：构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。修改某一层，最多影响其相邻的两层（通常只能影响上层） 。
层次结构优点：
1、支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
2、不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高。
3、由于每层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。
缺点
1、并不是每个系统都可以很容易的划分为分层的模式。
2、很难找到一个合适的、正确的层次抽象方法。
独立构件风格
进程通信：构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程（方法）调用等。
事件驱动系统（隐式调用）：构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。
主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便；缺点是构件放弃了对系统计算的控制。
虚拟机风格
解释器：通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，缺点是执行效率低。
基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。
仓库（数据共享）风格
数据库系统：构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。
黑板系统：包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中（信号处理、问题规划和编译器优化等）。
超文本系统：构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。是一种非线性的网状信息组织方法它以节点为基本单位，链作为节点之间的联想式关联。通常应用在互联网领域。
现代编译器的集成开发环境一般采用数据仓库（即以数据为中心的架构风格）架构风格进行开发，其中心数据就是程序的语法树。
闭环控制
当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。
C2体系结构风格
C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：
（1）系统中的构件和连接件都有一个顶部和一个底部；
（2）构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
（3）一个连接件可以和任意数目的其它构件和连接件连接；
（4）当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
层次架构风格
两层C/S架构
两层C/S架构：客户端和服务器都有处理功能，现在已经不常用，原因有：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。
三层C/S架构
三层C/S架构：将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上。即将两层C/S架构中的数据从服务器中独立出来了。其优点下面四点：
各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性；
允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性；
各层可以并行开发，各层也可以选择各自最适合的开发语言。
功能层有效的隔离表示层与数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理可控制。
三层C/S架构设计的关键在于各层之间的通信效率，要慎重考虑三层间的通信方法、通信频度和数据量，否则即使分配给各层的硬件能力很强，性能也不高。
三层B/S架构
是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为O客户端架构，虽然不用开发客户端，但有很多缺点：
B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
安全性难以控制；
在数据查询等响应速度上，要远远低于C/S架构；
数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。
混合架构风格
内外有别模型：企业内部使用C/S，外部人员访问使用B/S。
查改有别模型：采用B/S查询，采用C/S修改。
混合架构实现困难，且成本高。
MVC架构
（1）控制器（Controller）：是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
（2）模型（Model）：是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。
（3）视图（View）：是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行任何实际的业务处理。
MVP架构
MVP：MVP是把MVC中的Controller换成了Presenter（呈现)，目的就是为了完全切断View跟Model之间的联系，由Presenter充当桥梁，做到View-Model之间通信的完全隔离。
MVP特点:
1、M、V、P之间双向通信。
2、View与Model不通信，都通过Presenter传递。Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。
3、View非常薄，不部署任何业务逻辑，称为"被动视图"(Passive View)，即没有任何主动性，而Presenter非常厚，所有逻辑都部署在那里。
4、Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，这样就可以重用。
面向服务的架构风格
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。
在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理。
实施SOA的关键目标是实现企业IT资产重用的最大化，在实施SOA过程中要牢记以下特征：可从企业外部访问、随时可用（服务请求能被及时响应）、粗粒度接口（粗粒度提供一项特定的业务功能，而细粒度服务代表了技术构件方法）、服务分级、松散耦合（服务提供者和服务使用者分离）、可重用的服务及服务接口设计管理、标准化的接口(WSDL、SOAP、XML是核心)、支持各种消息模式、精确定义的服务接口。
从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。
基于服务的构件与传统构件的区别有四点：
（1）服务构件粗粒度，传统构件细粒度居多；
（2）服务构件的接口是标准的，主要是WSDL接口，而传统构件常以具体API形式出现；
（3）服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；
（4）服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码直接控制。
SOA应用的关键技术：
| 功能 | 协议 |
| 发现服务 | UDDI，DISCO |
| 描述服务 | WSDL，XML Schema |
| 消息格式层 | SOAP，REST |
| 编码格式层 | XML（DOM，SAX） |
| 传输协议层 | HTTP，TCP/IP，SMTP |
UDDI：是一套基于WEB的、分布式的、为WebService提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的webService注册，以使别的企业能够发现的访问协议的实现标准，用于WEB服务注册统一描述、发现及集成。
WSDL(WebService描述语言）：将Web服务描述定义为一组服务访问点，客户端可以通过这些服务访问点对包含面向文档信息或面向过程调用的服务进行访问（类似远程调用）用于描述服务。
SOAP（简单对象访问协议）：是用于交换XML编码信息的轻量级协议，用于传递信息。
XML（可扩展标记语言）：是WebService平台中表示数据的基本格式，用于数据交换。
WEB Service
服务提供者、服务注册中心（中介，提供交易平台，可有可无）、服务请求者。服务提供者将服务描述发布到服务注册中心，供服务请求者查找，查找到后，服务请求者将绑定查找结果。如图
服务注册表
（1）服务注册：应用开发者（服务提供者）在注册表中公布服务的功能。
（2）服务位置：服务使用者（服务应用开发者），帮助他们查询注册服务，寻找符合自身要求的服务。
（3）服务绑定：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，以及与它们实现互动。
企业服务总线ESB
企业服务总线ESB：简单来说是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。包括：客户端（服务请求者）、基础架构服务（中间件）、核心集成服务（提供服务）。
ESB特点:
1、SOA的一种实现方式/ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合；
2、描述服务的元数据和服务注册管理；
3、在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等；
4、发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。
软件架构的复用
软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。
软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。
可复用的资产包括：需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。
复用的基本过程主要包括3个阶段：首先构造/获取可复用的软件资产，其次管理这些资产（构件库），最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统。
特定领域软件架构
DSSA就是专用于一类特定类型的任务（领域）的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。
DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。
垂直域：在一个特定领域中的通用的软件架构，是一个完整的架构。
水平域：在多个不同的特定领域之间的相同的部分的小工具（如购物和教育都有收费系统，收费系统即是水平域）。
DSSA三个基本活动
领域分析 ：这个阶段的主要目标是获得领域模型（领域需求）。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。
领域设计 ：这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。
领域实现：这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。
参与DSSA的四种角色人员
领域专家 ：包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品，等等。
领域分析人员 ：由具有知识工程背景的有经验的系统分析员来担任。控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中。
领域设计人员 ：由有经验的软件设计人员来担任。根据领域模型和现有系统开发出DSSA，并对DSSA的准确性和一致性进行验证。
领域实现人员：由有经验的程序设计人员来担任。根据领域模型和DSSA，开发构件。
建立DSSA的过程
定义领域范围 ：领域中的应用要满足用户一系列的需求。
定义领域特定的元素 ：建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同的元素。
定义领域特定的设计和实现需求的约束 ：识别领域中的所有约束，这些约束对领域的设计和实现会造成什么后果。
定义领域模型和架构 ：产生一般的架构，并描述其构件说明。
产生、搜集可复用的产品单元 ：为DSSA增加复用构件，使可用于新的系统。
以上过程是并发的、递归的、反复的、螺旋型的。
三层次模型
领域开发环境 ：领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具
领域特定的应用开发环境 ：应用工程师根据具体环境来将核心架构实例化。
应用执行环境：操作员实现实例化后的架构。
基于构件的软件开发
ABSD方法是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求（或侧重于非功能需求）。
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。
ABSD方法有三个基础。第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。
基于架构的软件开发过程可以分为以下六步：
（1）架构需求：重在掌握标识构件的三步。
（2）架构设计：将需求阶段的标识构件映射成构件，进行分析。
（3）架构（体系结构）文档化：主要产出两种文档，即架构（体系结构）规格说明，测试架构（体系结构）需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。
（4）架构复审：由外部人员（独立于开发组织之外的人，如用户代表和领域专家等）参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。
（5）架构实现：用实体来显示出架构。实现构件，构件组装成系统。
（6）架构演化：对架构进行改变，按需求增删构件，使架构可复用。
软件系统的质量属性
可以将软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分。
- 开发期质量属性主要指在软件开发阶段所关注的质量属性，主要包含6个方面。
（1）易理解性：指设计被开发人员理解的难易程度。
（2）可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。
（3）可重用性：指重用软件系统或某一部分的难易程度。
（4）可测试性：对软件测试以证明其满足需求规范的难易程度。
（5）可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
（6）可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
- 运行期质量属性主要指在软件运行阶段所关注的质量属性，主要包含7个方面。
（1）性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
（2）安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
（3）可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
（4）互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
（5）可靠性：软件系统在一定的时间内持续无故障运行的能力。
（6）可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。
（7）鲁棒性：是指软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力，也称健壮性或容错性。
质量属性场景
质量属性场景是一种面向特定质量属性的需求。它由6部分组成：
o 刺激源（Source）：这是某个生成该刺激的实体（人、计算机系统或者任何其他刺激器）。
o 刺激(Stimulus)：该刺激是当刺激到达系统时需要考虑的条件。
o 环境(Environment)：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
o 制品（Artifact）：某个制品被激励。这可能是整个系统，也可能是系统的一部分。
o 响应(Response)：该响应是在激励到达后所采取的行动。
o 响应度量(Measurement)：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。
软件架构评估
质量属性
1、性能：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。
设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
2、可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF、MTTR。
设计策略：心跳、Ping/Echo、冗余、选举。
3、可用性：是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。
设计策略心跳、Ping/Echo、冗余、选举。
4、安全性：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。
设计策略：入侵检测、用户认证、用户授权、追踪审计。
5、可修改性：指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。
设计策略：接口-实现分类、抽象、信息隐藏。
6、功能性：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7、可变性：指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
8、互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。
o 敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
o 权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
o 风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能==引起风险的因素，可称为风险点。==某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的可接受的，则为非风险点。
o 软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。
三种常用的评估方式
o 基于调查问卷（检查表）的方式：类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
o 基于度量的方式：制定一些定量指标来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射要求评估人员对架构熟悉。
o 基于场景的方式：主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景（即4+1视图中的场景），最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。从三个方面对场景进行设计：刺激（事件）；环境（事件发生的环境）；响应（架构响应刺激的过程）。
基于场景的架构分析方法SAAM
SAAM是一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。
特定目标。SAAM的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。
质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。
架构描述。SAAM用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。
功能、结构和分配被定义为描述架构的3个主要方面。
方法活动。SAAM的主要输入是问题描述、需求声明和架构描述。下图描绘了SAAM分析活动的相关输入及评估过程。包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。
权衡分析法ATAM
架构权衡分析法ATAM，让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。
ATAM被分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。整个评估过程强调以属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
成本效益分析法CBAM
成本效益分析法CBAM，用来对架构建立的成本来进行设计和建模，让决策者根据投资收益率来选择合适的架构，可以看做对ATAM的补充，在ATAM确定质量合理的基础上，再对效益进行分析。有下列步骤：
整理场景（确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析）；
对场景进行细化（对每个场景详细分析，确定最好、最坏的情况）；确定场景的优先级（项目干系人对场景投票，根据投票结果确定优先级）；
分配效用（对场景响应级别确定效用表，建立策略、场景、响应级别的表格）;
形成"策略-场景-响应级别的对应关系"；
确定期望的质量属性响应级别的效用（根据效用表确定所对应的具体场景的效用表)
计算各架构策略的总收益；
根据受成本限制影响的投资报酬率选择架构策略（估算成本，用上一步的收益减去成本，得出收益，并选择收益最高的架构策略）。
中间件技术
中间件：在一个分布式系统环境中处于操作系统和应用程序之间的软件，可以在不同的技术之间共享资源，将不同的操作系统、数据库、异构的网络环境以及若干应用结合成一个有机的协同工作整体。
中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通信，有如下特点
（1）中间件是一类软件，而非一种软件;
（2）中间件不仅仅实现互连，还要实现应用之间的互操作；
（3）中间件是基于分布式处理的软件，最突出的特点是其网络通信功能。
中间件的任务是使应用程序开发变得更容易，通过提供统一的程序抽象，隐藏异构系统和分布式系统下低级别编程的复杂度。
主要的中间件
主要的中间件有五类：
o 数据库访问中间件：通过一个抽象层访问数据库，从而允许使用相同或相似的代码访问不同的数据库资源。典型的技术如Windows平台的ODBC和Java平台的JDBC等。
o 远程过程调用（RPC）：是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来"远程"执行大个位于不同地址空间内的过程，从效果上看和执行本地调用相同。
o 面向消息中间件（MOM）：利用高效可靠的消息传递机制进行平台无关的数据交流，并可基于数据通信进行分布系统的集成。通过提供消息传递和消息排队模型，可在分布环境下扩展进程间的通信，并支持多种通信协议、语言、应用程序、硬件和软件平台。典型的产品如IBM的MQSeries。
o 分布式对象中间件：随着对象技术与分布式计算技术的发展，两者相互结合形成了分布式对象技术，并发展成为当今软件技术的主流方向。典型的产品如OMG的CORBA、Sun的RMI/EJB、Microsoft的DCOM等。
o 事务中间件：也称事务处理监控器（TPM）最早出现在大型机上。事务处理监控程序位于客户和服务器之间，完成事务管理与协调、负载平衡、失效恢复等任务，提高系统的整体性能。
典型应用架构
J2EE平台采用了多层分布式应用程序模型，实现不同逻辑功能的应用程序被封装到不同的构件中，处于不同层次的构件被分别部署到不同的机器中。四层结构：
o 客户层组件：J2EE应用程序可以是基于web方式的，也可以是基于传统方式的静态的HTML（标准通用标记语言下的一个应用）页面和Applets是客户层组件
o web层组件：J2EEweb层组件可以是JSP页面或Servlet。
o 业务层组件：业务层代码的逻辑用来满足特定领域的业务逻辑处理。
o 信息系统层：企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划(ERP)，大型机事务处理，数据库系统，和其它的遗留信息系统.例如，J2EE应用组件可能为了数据库连接需要访问企业信息系统。
JSP+Servlet+JavaBean+DAO
o JSP：用于显示、收集数据的部分。作为MVC中的视图V。
o Servlet：作为业务逻辑层，用于处理复杂的业务逻辑，如验证数据、实例化JavaBean、调用DAO连接数据库等。作为MVC中的控制器C。在其中会调用Service方法处理服务。
o JavaBean：用于数据的封装，方便将查询结果在servlet与jsp页面之间进行传递等。
o DAO：用于连接数据库及进行数据库的操作如：查询、删除、更改等。
DAO与JavaBean合在一起为MVC中的模型M。
o 基本流程：JSP发一个数据到servlet，servlet收到后做下解析再根据数据调用相应的service去服务，service如果有要调用数据库就通过DAO跟数据库交互，使用javaBean完成封装，返回结果给servlet，servlet再返回给JSP。