软件架构设计

软件架构设计

概念

本质

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

作用

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

架构的4+1视图

架构的发展历程

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

软件架构设计_第1张图片

软件架构设计_第2张图片

五大架构风格

1.数据流风格

  • 批处理、管道-过滤器

2.调用/返回风格

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

3.独立构件风格

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

4.虚拟机风格

  • 解释器、规则系统

5.仓库风格

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

数据流风格

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

优点

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

缺点

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

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

子风格

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

    • 关键字:整体
  • 管道-过滤器:流式数据,将数据看成一个流,弱用户交互

    • 关键字:流式

调用/返回风格

特点:主函数(系统)调用子函数(系统),子函数(系统)返回执行结果

子风格

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

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

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

    • 优点

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

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

独立构件风格

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

软件架构设计_第3张图片

优点

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

缺点

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

虚拟机风格

概念

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

软件架构设计_第4张图片

子风格

  • 解释器

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

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

优点

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

缺点

  • 复杂度较高

仓库风格

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

子风格

  • 数据库系统

    • 以数据为中心
  • 黑板系统(例如:语音识别、知识推理)

    • 在以数据为中心的基础上,使用中心数据出发业务逻辑部件
      软件架构设计_第5张图片

    • 优点

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

      • 测试困难,不能保证有好的解决方案,难以建立好的控制策略,低效,开发困难,缺乏并行机制
    • 应用场景:语音识别、场景识别、图像处理、知识推理等

  • 超文本系统

闭环风格

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

软件架构设计_第6张图片

应用:空调温控,定速巡航

C2风格

软件架构设计_第7张图片

基本规则

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

CS与BS架构风格

CS:APP,BS:浏览器访问网站

两层CS架构

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

三层CS架构

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

三层BS架构

  • 数据层 + 表示层(浏览器) + 功能层

  • 当前很多系统的主流架构
    软件架构设计_第8张图片

  • 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

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

软件架构设计_第9张图片

软件架构设计_第10张图片

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

典型技术

  • Web Service

    软件架构设计_第11张图片

    • 服务注册中心 + 服务提供者 + 服务请求者,Web Service 构建服务提供者和服务请求者之间的联系
  • ESB(企业服务总线)

    软件架构设计_第12张图片

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

微服务

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

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

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

    • 与SOA的对比:
      软件架构设计_第13张图片

      软件架构设计_第14张图片

MDA

模型驱动架构(Model Driven Architecture)

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

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

三个部分

  • 平台无关模型(PIM)

    • 独立于技术实现的,焗油膏抽象层次的模型
  • 平台相关模型(PSM)

    • 技术实现上用来描述系统的模型,由PSM映射而来
  • 源代码(Code)

    • 对系统的代码描述

ADL(架构描述语言)

三个基本要素

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

DSSA(特定领域软件架构)

软件架构设计_第15张图片

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

几个角色

  • 领域专家

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

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

    • 有经验的软件设计人员
  • 领域实现人员

    • 有经验的程序设计人员

三层次模型:

软件架构设计_第16张图片

你可能感兴趣的:(软考_架构师,架构,软件工程)