软件架构设计
软件架构的概念：
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成
软件架构4+1视图：
- 逻辑视图：主要是整个系统的抽象结构表述，关注系统提供最终用户的功能，
- 开发视图；关注编程人员的软件管理
- 物理视图: 系统工程人员，关注系统拓扑、安装、通信等
- 处理视图: 系统集成人员，关注性能、可扩充性、吞吐量等
- 场景：关注最终用户需求，通常用UML用例图和活动图描述
软件架构风格的概念：
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式，定义了用于描述系统的术语表和一组指导构建系统的规则反映了领域中众多系统所共有的结构和语义特征，并指导如何将各个构件有效的组织成一个完整的系统
软件架构风格分类：
1.数据流风格
批处理序列： 组件为一系列固定顺序的计算单元，组件间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递。
管道-过滤器: 每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流，经过处理，产生输出数据流。
2.调用/返回风格
主程序/子程序: 单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于子程序的正确性
面向对象: 构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的操作被封装起来，对象的行为体现在其接受和请求的动作，连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的
层次结构: 构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义，每层为上层提供服务，使用下一层的服务，智能看到与自己邻接的层。通过层次机构将大问题分解为若干小问题，隐藏问题复杂度，修改某层最多影响相邻的两层
3.独立构件风格
进程通信: 构件是独立的过程，连接件是消息传递，构件通常是命名过程，消息传递的方式可以是点对点、异步或同步的方式，以及远程过程调用等
事件驱动（隐式调用）: 构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中过程的调用
4.虚拟机风格
解释器： 解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率较低
基于规则的系统: 基于规则的系统包含规则集、规则解释器、规则/数据选择器以及工作内存
5.仓库风格
数据库风格： 数据库架构是库风格最常见的形式。构件主要有两大类，一个是中央共享数据源，保存当前系统的数据状态，另一个是多个独立处理元素，处理元素对数据元素进行操作
黑板风格： 黑板架构风格包含知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识，知识源响应黑板上的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介； 知识源响应是通过黑板状态的变化来控制的。黑板系统通常是应用在对于解决问题没有确定性算法的软件中（信号处理、语音识别、问题规划和编译器优化等）
超文本： 构件以网状链接方式相互连接，用户可以在构件之间按照人的思维方式任意跳转到相关构件。
6.闭环控制风格（过程控制）
当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈循环通过接收一定的输入，确定一系列的输出，最终使环境达到一个新的状态
7.C2风格
是一种常见得层次体系架构风格。概括而言，该风格是由连接件绑定的按照一定规则运行的并行构件网络，各构件之间只能通过连接件的异步通信机制进行交互，使得构件的替换或更新不影响架构，这种方式体现了高内聚、低耦合的设计思想
8.两层C/S
分为表示层和数据层,业务逻辑处理放在了表示层，数据层只进行数据处理与存储。缺点是：开发成本高，客户端设计复杂，信息内容形式单一，用户界面风格不一，移植困难，维护与升级困难，新技术不容易应用
9.三层C/S
分为表示层、功能层、数据层。功能层可能与表示层都放在客户机上，也可能放在服务器上
10.三层B/S
分为客户端、应用服务器、数据库服务器。缺点是：
- 缺乏对动态页面的支持，没有集成有效的数据库处理能力
- 安全性难以控制
- 在数据查询等响应速度上弱于C/S架构
- 数据提交一般以页为单位，动态交互性不强，不利于OLTP应用
11.混合架构风格
内外有别：
概念：企业内部用户通过局域网直接访问数据库服务器，软件系统采用C/S架构，企业外部用户通过Internet询问Web服务器，通过Web服务器再访间数据库服务器，软件系统采用B/S架构
优点：外部用户不直接访问数据库服务器，能保证企业数据库的相对安全
缺点：企业外部用户修改和维护数据时，速度较慢，较烦琐，数据的动态交互性不强
查改有别：
概念：不管用户是通过什么方式(局域网或Internet)连接到系统，凡是需执行维护和修改数据操作的，就使用C/S架构；如果只是执行一般的查询和浏览操作，则使用B/S架构
优点：体现了B/S架构和C/S架构的共同优点
缺点：外部用户能直接通过Internet连接到数据库服务器，企业数据容易暴露给外部用户，给数据安全造成了一定的威胁
12.MVC架构风格：
M: model，是应用程序中用于处理应用程序数据逻辑的部分，通常负责在数据库中存取数据
V：view，是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的
C：controller，是应用程序中处理用户交互的部分，通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据
13.MVP架构：
MVP是MVC的变种，实现了V与M的解耦（V不直接使用M, 修改V不会影响M），MVP更好的支持单元测试，V要处理界面事件（在MVC中界面事件由C处理），业务逻辑由P处理
14.基于服务的架构（SOA）
定义：面向服务架构(SOA)是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来，接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互
SOA服务构件与传统构件的对比：
- 服务构件粗粒度，传统构件细粒度居多
- 服务构建的接口是标准的，主要是WSDL接口，传统构件常以具体API形式出现
- 服务构件的实现与具体语言无关，传统构件绑定某种特定语言
- 服务构件可以通过容器提供QoS的服务，传统构件完全由程序代码直接控制
SOA关键技术：
- 发现服务：UDDI，提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便该服务被发现和使用，同时它也定义了一种编程接口。该技术规范主要包括数据模型、API和注册服务三部分
- 描述服务：WSDL，基于XML语法对服务进行描述的语言，包括服务实现定义和服务接口定义
- 消息格式层： SOAP,定义了服务请求者和服务提供者之间的消息传输规范，该协议通过HTTP承载XML格式化的消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用(RPC）
- REST,是一种针对Web服务的设计和开发方式，通常使用HTTP、XML、URI和HTML等流行协议或标准，可以有效降低开发的复杂性，提高系统的可伸缩性
实现方式之 WebService:
服务提供者将服务注册到服务注册中心，服务请求者通过服务注册中心获取服务的真实地址。
实现方式之 ESB:
概念：将企业中各个不同的服务连接在一起。因为各个服务是异构的，没有统一的标准，各个异构系统对外提供的接口是各式各样的，SOA使用ESB来屏蔽异构系统对外提供的不同接口，以此来达到服务间高效的互联互通
特点：提供位置透明性的消息路由和寻址服务、提供服务注册和命名的管理、支持多种消息规范、支持多种传输协议、支持多种数据格式及其相互转换、提供日志和监控功能
15.微服务
概念：微服务架构提倡将单一应用程序划分成一组小的服务，服务之间相互协调、配合，为最终用户提供最终价值，每个服务运行在其独立的进程中，服务之间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构件，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据服务的上下文，选择合适的语言、工具对其进行构建。
特点：专注于某一个具体的业务，轻量级的通信机制，松耦合、独立部署
优点：技术异构性、弹性、扩展、简化部署、与组织结构相匹配、可组合性、对可替代性的优化
缺点：系统复杂、运维成本高、服务间的依赖难以管理
微服务与SOA的对比：
微服务实现与SOA实现对比：
16.MDA模型驱动架构
使用模型完成软件的分析、设计、构建、部署、维护等开发活动
主要目标：可移植性、互通性、可重用性
架构描述语言ADL：
定义： ADL是这样一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体现结构建模提供了具体语法和概念框架。基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持
三个基本元素：
构件：计算或数据存储单元
连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则
架构配置：描述体系结构的构件与连接件的连接图
特定领域软件架构（DSSA）：
基本活动：
领域分析：建立领域模型
领域设计：获得DSSA
领域实现：开发和组织可复用的信息
参与角色：
- 领域专家： 有经验的用户、有经验的软件工程师等，提供该领域中系统的需求规约和实现知识
- 领域分析人员：分析特定领域软件架构需求，由由知识工程背景的有经验的系统分析
- 领域设计人员；有经验的软件设计人员
- 领域实现人员：有经验的程序员
基于构件的软件开发（Component Based Software Development,CBSD）：
利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。CBSD模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。
CBSD模型由软件的需求分析和定义、架构设计、构件库的建立、应用软件构建、测试和发布5
个阶段组成
基于架构的软件设计（ABSD）：
特点：
- ABSD方法是架构驱动，即强调业务、质量和功能需求的组合驱动架构设计
- 使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没完成，就开始了软件设计
- ABSD方法有三个基础。第一个是功能的分解，第二个是通过选择架构风格来实现质量和业务需求，第三个是软件模板的使用
- ABSD方法是递归的，且迭代的每一个步骤是清晰定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构的随意性
- 视图和视角：从不同的视角来检查，所以会有不同的视图
- 用例用来捕获功能需求，特定场景用来捕获质量需求
过程：架构需求 -> 架构设计 -> 架构文档化 -> 架构复审 -> 架构实现 -> 架构演化
