软件架构设计

概念

本质

• 对软件系统的关于结构、行为和属性的高级抽象
• 软件架构风格是特定领域的惯用模式，软件架构定义了一个词汇表和一组约束

作用

• 方便项目干系人的交流，将满足需求的职责分配到组件上
• 引入可传递和可复用的模型，使软件的质量具备可预见性
• 服务于循序渐进的原型设计，简化推理和控制的更改过程

架构的4+1视图

架构的发展历程

• 无架构阶段–汇编语言
• 萌芽阶段–程序结构设计
• 初级阶段–统一建模语言
• 高级阶段–4+1视图

五大架构风格

1.数据流风格

• 批处理、管道-过滤器

2.调用/返回风格

• 主程序/子程序、面向对象、层次结构

3.独立构件风格

• 进程通信、事件驱动系统（隐式调用）

4.虚拟机风格

• 解释器、规则系统

5.仓库风格

• 数据库系统、黑板系统、超文本系统

数据流风格

数据驱动–前一步处理的结果是后一步的输入内容

优点

• 松耦合
• 良好的重用性、可维护性
• 良好的可扩展性（标准接口适配）
• 良好的隐蔽性
• 支持并行

缺点

• 交互性差
• 复杂性较高
• 性能较差（每个过滤器都需要解析与合成数据）

典型实例：传统编译器、网络报文处理

子风格

• 批处理序列：大量整体数据，将数据看成整体，无需用户交互

  • 关键字：整体

• 管道-过滤器：流式数据，将数据看成一个流，弱用户交互

  • 关键字：流式

调用/返回风格

特点：主函数（系统）调用子函数（系统），子函数（系统）返回执行结果

子风格

• 主程序/子程序：面向过程

• 面向对象：对象的方法调用

• 分层：层与层之间的方法调用

  • 优点

    • 良好的重用性
    • 良好的可维护性
    • 良好的可扩展性，支持递增设计

  • 缺点

    • 并不是所有系统都适合分层
    • 很难找到一个合适且正确的层次抽象方法
    • 不同层次之间耦合度高的系统很难实现
    • 层次多了会影响效率，层次少了各层职责不明确

独立构件风格

构件之间不直接交互，一般采用消息队列的方式就是一种独立构件风格

优点

• 松耦合，良好的可重用性、可修改性、可扩展性

缺点

• 不能确认是否会得到相应，不能保证调用的顺序，正确性的推理存在问题，数据交换存在某些问题

虚拟机风格

概念

• 虚拟机根据字节码文件和既定语义，翻译得到对应的系统指令

子风格

• 解释器

  • 适用于需要“自定义规则”的场景

• 规则为中心

  • 在解释器的基础上增加经验规则，适用于专家系统

优点

• 可以灵活应对自定义场景

缺点

• 复杂度较高

仓库风格

特点：形成数据仓库，所有构件都是基于这个数据仓库进行业务处理，

子风格

• 数据库系统

  • 以数据为中心

• 黑板系统（例如：语音识别、知识推理）

  • 在以数据为中心的基础上，使用中心数据出发业务逻辑部件
    

  • 优点

    • 可修改性和可维护性，可重用的知识源，容错性和健壮性

  • 缺点

    • 测试困难，不能保证有好的解决方案，难以建立好的控制策略，低效，开发困难，缺乏并行机制

  • 应用场景：语音识别、场景识别、图像处理、知识推理等

• 超文本系统

闭环风格

过程控制，常见于嵌入式系统中，用于解决简单闭环控制问题

应用：空调温控，定速巡航

C2风格

基本规则

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

CS与BS架构风格

CS：APP，BS：浏览器访问网站

两层CS架构

• server（数据层） + client（表示层）构成
• 开发成本较高，程序设计复杂，信息内容和形式单一，用户界面风格不一致，软件移植、维护、升级困难，对新技术的应用不友好

三层CS架构

• 数据层 + 表示层 + 功能层（可以放在server，也可以放在client）
• 相对两层CS更加灵活，逻辑不写在表示层，而是放在功能层进行处理

三层BS架构

• 数据层 + 表示层（浏览器） + 功能层

• 当前很多系统的主流架构
  

• MVC、MVP、MVVM

  • MVC = Model + View + Controller

    • 对应的几项技术：
      View~JSP
      Controller~Servlet
      Model~EJB

  • MVP = Model + View + Presenter

    • 是MVC的变种，实现了V和M之间的解耦，更加符合分层的思想，更好支持单元测试，V需要处理界面时间，P处理业务逻辑

  • MVVM = Model + View + ViewModel

    • V和VM做双向的数据绑定

      • 对应技术：
        View~HTML、CSS
        ViewModel~JS、compiler
        Model~EJB等

混合架构

• 企业内外有区别的场景，内部采用CS，外部采用BS

• 数据查改需求有区别的场景，查询用BS，修改用CS

• RIA架构风格

  • 了解几项技术：HTML5、Ajax
  • 结合了CS反应速度快、交互性强的特点，以及BS传播范围广的特点，简化并改进BS的用户交互
  • 典型场景：网页小游戏

SOA

基于服务的架构，服务的标准化程度更高，经典场景：历史遗留系统的集成

特点：松散耦合、粗粒度、标准接口、语言无关、WSDL接口

典型技术

• Web Service

  

  • 服务注册中心 + 服务提供者 + 服务请求者，Web Service 构建服务提供者和服务请求者之间的联系

• ESB（企业服务总线）

  

  • 把各个服务通过ESB连接起来

微服务

• 微服务架构提倡将单一应用程序划分成一组更小的服务，服务之间相互协调、配合，可以独立部署，松散耦合

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

  • 劣势：复杂性高，运维成本高，服务间依赖测试复杂，服务间依赖管理较难

  • 与SOA的对比：
    

    

MDA

模型驱动架构（Model Driven Architecture）

• 主要目标：可移植性、互通性、可重用性

• 使用模型完成软件的分析、设计、构件、部署、维护等开发活动，是一种形式化的开发方法，基于数学公理，不需要测试，正确性比较高，可移植性强

三个部分

• 平台无关模型（PIM）

  • 独立于技术实现的，焗油膏抽象层次的模型

• 平台相关模型（PSM）

  • 技术实现上用来描述系统的模型，由PSM映射而来

• 源代码（Code）

  • 对系统的代码描述

ADL（架构描述语言）

三个基本要素

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

DSSA（特定领域软件架构）

• 所谓的领域就是行业相关通用的东西，包括需求、设计、实现等

几个角色

• 领域专家

  • 提供关于领域中系统的需求规约和实现的知识，可以是有经验的用户、工程师等

• 领域分析人员

  • 有相关领域经验的分析员

• 领域设计人员

  • 有经验的软件设计人员

• 领域实现人员

  • 有经验的程序设计人员

三层次模型：