（九）软件架构设计

星源

1、软件架构的概念

1.1 架构的本质

（1）软件架构为软件系统提供了一个结构、行为和属性的高级抽象；
（2）软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。
1.2 架构的作用

（1）软件架构是项目干系人进行交流的手段；
（2）软件架构是可传递和可复用的模型，通过研究软件架构可预测软件的质量；
（3）软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
软件架构即软件体系结构，架构设计就是需求分配，即将满足需求的职责分配到组件上。
2、架构的“4+1”视图



3、软件架构风格

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统；
架构风格定义了用于描述系统的术语表和一组指导系统构建的规则；


3.1 数据流风格

优点	缺点	典型实例
1、松耦合（高内聚-低耦合） 2、良好的重用性/可维护性 3、可扩展性（标准接口适配） 4、良好的隐蔽性 5、支持并行	1、交互性较差 2、复杂性较高 3、性能较差（每个过滤器都需要解析与合成数据）	传统编译器网络报文处理

批处理序列：大量整体数据、无需用户交互
管道-过滤器：流式数据、弱用户交互
3.2 调用-返回风格



主程序/子程序：面向过程；面向对象：对象的方法调用；分层：层一层之间的方法调用

优点	缺点	特点
1、良好的重用性，只要接口不变可用在其他处 2、可维护性好 3、可扩展性好，支持递增设计	1、并不是每个系统都方便分层 2、很难找到一个合适的、正确的层次抽象方法 3、不同层次之间耦合度高的系统很难实现	1、各个层次的组件形成不同功能级别的虚拟机 2、多层相互协同工作，而且实现透明

3.3 独立构件风格

优点	缺点	特点
1、松耦合 2、良好的重用性、可修改性、可扩展性	1、构件放弃了对系统计算的控制，一个构件触发一个构件时，不能确定其他构件是否会响应它，而且即使它知道事件注册了哪些构件过程，它也不能保证这些过程被调用的顺序； 2、数据交换的问题； 3、既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题	系统由若干子系统构成且成为一个整体，系统有统一的目标，子系统有主从之分，每一子系统有自己的事件收集和处理机制

3.4 虚拟机风格

子分类	优点	缺点	特点	适合领域
解释器	可以灵活应对自定义场景	复杂度较高	/	适用于需要“自定义规则”的场合
规则为中心	可以灵活应对自定义场景	复杂度较高	在解释器的基础上增加经验规则	适用于专家系统

3.5 仓库风格

架构风格	子分类	优点	缺点	特点	典型实例
仓库风格	数据库系统	以数据为中心
仓库风格	黑板系统	可更改性和可维护性；可重用的知识源；容错性和健壮性；	测试困难；不能保证有好的解决方案；难以建立好的控制策略；低效；开发困难；缺少并行机制；	在以数据为中心的基础上，使用中心数据触发业务逻辑部件	语音识别 模式识别 图像处理 知识推理

3.6 闭环控制架构（过程控制）



适用于嵌入式系统，用于解决简单闭环控制问题
经典应用：空调温控，定速巡航
3.7 C2风格



基本规则：

• 构件和连接件都有一个顶部和一个底部
  
• 构件的顶部要连接到连接件的底部，构件的底部要连接到边接件的顶部，构件之间不允许直连
  
• 一个连接件可以和任意数目其他构件和连接件连接
  
• 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部
  

4、 层次架构风格



4.1 两层C/S架构



4.2 三层C/S架构





4.3 B/S架构





4.4 混合架构风格



4.5 MVC架构风格

• Model(模型)：应用程序中用于处理应用程序数据逻辑的部分，通常模型对象负责在数据库中存取数据
  
• View(视图)：应用程序中处理数据显示的部分，通常视图是依据模型数据创建的
  
• Controller(控制器)：应用程序中处理用户交互的部分，通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据
  

在J2EE体系中

• 模型：Entity Bean、Session Bean
  
• 视图：JSP
  
• 控制器：Servlet
  

4.6 MVP架构风格

• MVP是MVC的变种
  
• MVP实现了V与M之间的解耦（V不直接使用M，修改V不会影响M）
  
• MVP更好的支持单元测试（业务逻辑在P中，可以脱离V来测试这些逻辑；可以将一个P用于多个V，而不需要改变P的逻辑）
  
• MVP中的V要处理界面事件，业务逻辑在P中，MVC中的界面事件由C处理
  

4.7 MVVM架构风格



4.8 RIA架构风格

• RIA结合了C/S架构反应速度快、交互性强的优点，以及B/S架构传播范围广及容易传播的特性
  
• RIA简化并改进了B/S架构的用户交互
  
• 数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面
  

5、 基于服务的架构(SOA)

服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持

• 服务构件粗粒度，传统构件细粒度居多
  
• 服务构件的接口是标准的，主要是WSDL接口，传统构件常以具体API形式出现
  
• 服务构件的实现与语言无关，传统构件绑定某种特定语言
  
• 服务构件可以通过构件容器提供QoS的服务，传统构件完全由程序代码直接控制
  

SOA的实现方式-ESB


关键技术

功能	协议
发现服务	UDDI、DISCO
描述服务	WSDL、XML Schema
消息格式层	SOAP、REST
编码格式层	XML（DOM,SEX）
传输协议层	HTTP、TCP/IP、SMTP等

WSDL就是WebService接口对应的WSDL文件，该文件通过xml格式说明如何调用，可以看作WebService的接口文档（使用说明书）
5.1 微服务

微服务，顾名思义就是很小的服务，所以它属于面向服务架构的一种。
微服务是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTfulAPI）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应该根据上下文，选择合适的语言、工具对其进行构建。
特点：

• 小，且专注于做一件事
  
• 轻量级的通信机制
  
• 松耦合、独立部署
  

微服务的优势：

• 技术异构性
  
• 弹性
  
• 扩展
  
• 简化部署
  
• 与组织结构相匹配
  
• 可组合性
  
• 对可替代性的优化
  

微服务面临的挑战：

• 分布式系统的复杂度
  
• 运维成本
  
• 部署自动化
  
• DevOps与组织结构
  
• 服务间依赖测试
  
• 服务间依赖管理
  

5.2 微服务与SOA

微服务	SOA
能拆分的就拆分	是整体的，服务能放一起的都放一起
纵向业务划分	是水平分多层
由单一组织负责	按层级划分不同部门的组织负责
细粒度	粗粒度
两句话可以解释明白	几百字只相当于SOA的目录
独立的子公司	类似大公司里面划分了一些业务单元（BU)
组件小	存在较复杂的组件
业务逻辑存在于每一个服务中	业务逻辑横跨多个业务领域
使用轻量级的通信方式，如HTTP	企业服务总线（ESB）充当了服务之间通信的角色

微服务架构实现	SOA实现
团队级，自底向上开展实施	企业级，自顶向下开展实施
一个系统被拆分成多个服务，粒度细	服务由多个了系统组成，粒度粗
无集中式总线，松散的服务架构	企业服务总线，集中式的服务架构
集成方式简单（HTTP/REST/JSON）	集成方式复杂（ESB/WS/SOAP）
服务能独立部署	单块架构系统，相互依赖，部署复杂

5.3 MDA

MDA起源于分离系统规约和平台实现的思想，MDA的主要目标：Protability（可移植性）、Interoperability（互通性）、Reusability（可重用性）
MDA的3种核心模型：

• 平台独立模型(PIM)：具有高抽象层次、独立于任何实现技术的模型
  
• 平台相关模型(PSM)： 为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型，PIM会被变换成一个或多个PSM
  
• 代码Code：用源代码对系统的描述（规约），每个PSM都将被变换成代码
  

5.4 ADL

ADL是一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架，如Aesop、MetaH、C2、Rapide、SADL、Unicon等
ADL的三个基本元素

• 构件：计算或数据存储单元
  
• 连接件：用于构件之间交互建模的体系结构构造块及其支配这些的交互的规则
  
• 架构配置：描述体系结构的构件与连接件的连接图
  

5.5 特定领域软件架构（DSSA）

基本活动


领域分析机制


建立过程


三层次模型


6、基于架构的软件开发方法

6.1 概念

• ABSD架构方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计
  
• ABSD方法有三个基础，第一个基础是功能的分解，在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务的需求；第三个基础是软件模板的使用
  
• 视角与视图：从不同的视角来检查，所以会有不同的视图
  
• 用例用来捕捉功能需求、特定场景用来捕获质量需求
  

6.2 开发过程







7、软件架构评估

7.1 质量属性



（1）性能


（2）可用性


（3）安全性


（4）可修改性


（5）易用性
易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类
（6）可测试性
软件可测试性是指通过测试揭示软件缺陷的容易程度


7.2 架构评估方法

• 基于调查问卷（检查表）的方式
  
• 基于度量的方式
  
• 基于场景的方式
  

质量效用树


8、软件产品线

8.1 概念



8.2 双生命周期模型



8.3 建立方式



8.4 组织结构

组织结构类型

• 设立独立的核心资源小组
  
• 不设立独立的核心资源小组
  
• 动态的组织结构
  

要成功实施产品线，主要取决于以下因素

• 对该领域具备长期和深厚的经验
  
• 一个用于构建产品的好的核心资源库
  
• 好的产品线架构
  
• 好的管理（软件资源、人员组织、过程）支持
  

9、构件与中间件技术

9.1 概念

构件的定义
定义1：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖，软件构件可以被独立地部署并由第三方任意地组装
定义2：构件是某系统中有价值的、几乎独立的并可替换的一部分，它在良好定义的体系结构语境内满足某清晰的功能
定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务


构件系统架构特性

• 构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成
  
• 构件框架是一种专用的体系结构（通常围绕一些关键的机制），同时，也是一组固定地作用于构件层次机制的策略
  
• 概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则
  
• 构件是一组通常需要同时部署的原子构件，构件和原子构件之间的区别在于，大多数原子构件永远不会被单独部署，尽管它们可以被单独部署
  
• 一个原子构件是一个模块和一组资源
  
• 模块是一组类和可能的非面向对象的结构体，比如过程或者函数
  
• 资源是一个类型化的项的固定集合
  
• 资源这个概念可以包含代码资源，进而包含模块，问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其他的资源，在“纯对象”的方法中，资源是外部化的不可改变的对象，不可改变是因为构件没有持久化的标志，而且复制不能被区分
  

9.2 构件的复用











9.3 构件标准

红尘路上

LZ帖子不给力，勉强给回复下吧