• 软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。
• 软件工程的三个要素：方法、工具和过程。
  • 软件工程方法是完成软件工程项目的技术手段
  • 软件工具为软件工程方法提供自动或半自动的软件制成环境
  • 软件工程过程是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的

软件体系结构 = 组件 + 连接件 + 约束

Software Architecture = Components + Connectors + Constrains

Architectural Styles

• A style is determined (described) by

  1. a set of component types 组件类型（例如：数据容器，过程，对象）

  2. a set of connector types/interaction mechanisms

     连接件类型/交互机制（例如：过程调用，事件，管道）

  3. a topological layout of these components 组件的拓扑分布

  4. a set of constraints on topology and behavior

     拓扑和行为的约束（例如：数据容器不能自己改变数据，管道不能是循环的）

  5. an informal description of the costs and benefits of the style

     风格的代价和益处（相当于优缺点）

• Taxonomy（分类法） of Styles/Idioms

  Taxonomy.png

Software Architecture Style

Data Flow 数据流风格

• 特点

  - A data flow system is one in which 
    - the availability of data controls the computation 由数据控制计算
    - the structure of the design is dominated by orderly motion of data from process to process    系统结构由数据在处理之间的有序移动决定
    - the pattern of data flow is explicit  数据流系统的结构是比较明显的
  - In a pure data flow system, there is no other interaction between processes  在纯数据流系统中，处理之间除了数据交换，没有任何其他的交互 
  

• 组成

  - Components: Data Flow Components 
    - Interfaces are input ports and output ports
       组件的接口是输入端口和输出端口
    - Computational model: read data from input ports, compute, write data to output ports
       计算模型：从输入中读取数据，计算，然后写到出口
  - Connectors: Data Streams
    - ★Uni-directional（单向）
    - usually asynchronous, buffered （通常是异步的，有缓冲）
  
  - Systems
    - Arbitrary graphs（任意拓扑结构）
    - Computational model: functional composition（不同组件完成不同的功能）
  

• 模式

​ 我们主要研究近似线性数据流或者是在限度内的循环数据流

​ 如果一个软件系统的数据流的流向无序很可能说明该系统不应采用数据流的体系结构

• Three Examples

Batch Sequential 批处理

• Model

  • Processing steps are independent programs

    每个处理步骤是一个独立的程序

  • Each step runs to completion before next step starts

    每一步必须在前一步结束后才能开始（有次序）

  • Data transmitted as a whole between steps

    数据必须是完整的，以整体的方式传递

• Example

  • Compilers

Pipe-and-Filter 管道-过滤器

• 概念 (管道-过滤器风格是批处理的进化)

 每个组件都有一组输入和输出，组件读取输入的数据流，经过内部处理，产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成。   
 这里的组件被称为过滤器，这种风格的连接件像是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入.

• 管道过滤器的通用结构：

  • 管道（Pipelines）：限制了系统的拓扑结构，只能是过滤器的线性序列
  • 有界管道（Bounded Pipes）：限制了在管道中能够容纳的数据量
  • 类型定义管道（Typed Pipes） ：要求定义在两个过滤器间传出的数据类型

• 过滤器 filters

  - Role of (“pure”) filters
    - 读取数据流作为输入，把处理后的数据流作为输出
  - performs stream-to-stream transformations
    1. enrich data by computation and adding information
     通过计算和增加信息来丰富数据
    2. refine by distilling data or removing irrelevant data
     通过浓缩和删除来精炼数据
    3. transform data by changing its representation
     通过改变表现形式的方式来转化数据
    4.递增地转化数据，数据“边到来边处理”，不是先收集好再处理
    5.不同过滤器之间是独立的
  

• 管道

  - Role of (“pure”) pipes
    - move data from a filter output to a filter input (or to a device or file)
        移动数据，从一个过滤器的输出到另一个过滤器的输入
    - data moves in one direction, upstream flow control is allowed 单向
    - pipes form data transmission graphs 
  - Overall Operation
    - system action is mediated by data delivery 数据传送引起系统动作
    - pipe-and-filter systems run until no more data is available and no more computations possible 当没有数据可用并且没有更多的计算的时候，管道过滤器系统才停止工作
  

• 过滤器对数据流的五种变换类型 ：

  • 增加/丰富(a → a+b)
  • 删减/浓缩(a→ a-b)
  • 转换(a → a')
  • 合并(a、b→ a+b)
  • 分解(a+b → a、b)

• 过滤器读取与处理数据流的方式

  • 递增地读取和消费数据流
  • 在输入被完全处理之前，输出便产生了

• 优点 Advantages

  - 使软件具有良好的隐蔽性和高内聚，低耦合的特点（过滤器可以看做是黑盒）
  - 可将整个系统的I/O特性，理解为各个过滤器功能的简单合成（多个低级过滤器可以合并成一个高级过滤器）
  - 支持功能模块的重用（任意两个过滤器只要在相互所传输的数据格式上达成一致，就可以连接在一起）
  - 系统易于维护和扩展（新的过滤器容易加入到系统中，旧的过滤器也可以被改进的过滤器替换）
  - 支持某些特性属性的分析（入吞吐量和死锁检测）
  - 支持多个过滤器的并发执行（适合多核/多线程环境）
  
  注：理想情况下是组件之间只有数据依赖
  

• 缺点 Disadvantages

  - 通常导致进程成为批处理的结构 (将每个过滤器看成一个完整的从输入到输出的转换)
  - 不适合在交互性很强的应用
  - 在数据传输上没有通用的标准，每个过滤器都增加了解析数据的工作
  - 处理两个独立但相关的数据流可能会遇到困难
  - 某些过滤器可能需要大尺寸的cache
  

• Batch Sequential vs Pipe & Filter

  二者无法从拓扑上区分
  
  - 相同点：把任务分解成为一系列固定顺序的计算单元(组件)；组件间只通过数据传递来进行交互
  
  - 不同点
  批处理：  全部   高延迟    输入随机访问      没有并发性     没有交互性          
  管道过滤器： 增量  立即有结果 输入的处理是局部的 可能有反馈回路  有交互性
  

• Guidance for Selecting a Data Flow Style

  • 任务是数据主导
  • 事先知道数据的确切流向

Process Control 过程控制

• 适用场合：软硬件结合的系统，以硬件为主

• 开环控制：系统无反馈、由人进行反馈

• 闭环控制：系统有反馈，不需要人进行反馈

  • 两种形式：
    • 反馈控制：根据受控变量的测量值来调整过程
    • 前馈控制：通过测量其他过程变量，来预计输入变量对被控变量将产生的影响。前馈控制这些变量来调整过程

• 当软件系统的运行受到外部干扰（软件不可见或不可控的力量或事件）的影响时，需要为软件体系结构考虑一种过程控制方式

• 和许多线性的数据流体系结构不同，控制环路体系结构需要有循环的拓扑结构。

• Guidance for Selecting a Control Style

  - 任务包含连续的动作、行为、状态的改变
  - 不适合人参与的情况
  - 一般是软硬件结合的系统（适用场合）
  

Call/Return 调用/返回

Main program and subroutines 主程序和子程序

• hierarchy of procedure definitions (存在层次结构)
• nested collections of procedures（过程的嵌套）

• Pipes vs Procedures

Object-Oriented

• OO是对现实中离散事件和个体交互的仿真，最适合模拟现实。

• Elements of Object Architectures

  - Encapsulation: Restrict access to certain information
    封装：限制对某些信息的访问
  - Interaction: Via procedure calls or similar protocol
    交互：通过过程调用或类似的协议
  - Polymorphism: Choose the method at run-time
    多态：在运行时选择具体的操作
  - Inheritance: Shared definitions of functionality 
    继承：对共享的功能保持唯一的接口
  - Reuse and maintenance: Exploit encapsulation and locality to increase productivity 复用和维护：利用封装和聚合提高生产力
  
  注:严重依赖于具体使用的语言
  

• 缺点

  - Managing many objects （大量对象需要额外的结构来容纳）
  - Managing many interactions
  - Distributed responsibility for behavior
  - Capturing families of related designs
  

Layered hierarchies

• 层次风格特点

  - 每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层
    - 适当时候(迫不得已时)，可以允许一定的越层操作
  - 大的问题分解为若干个渐进的小问题，逐步解决，隐藏了很多复杂度
  - 修改一层，最多影响两层，通常只会影响上层。若层之间接口稳固，则不会造成其他影响
  - 上层必须知道下层的身份，不能调整层次之间的顺序
  - 层层相调，影响性能
  

两层Client/Server

两层Client/Server .png

• Workstations包含显示层与业务层，Server只有数据

  C/S是基于资源不对等，且为实现共享而提出的，20世纪90年代成熟起来
  C/S有三个主要组成部分：数据库服务器、客户端和网络
  服务器（后台）负责数据管理，客户端（前台）完成与用户的交互任务。“胖客户端，瘦服务器”
  

• 缺点

  1. 对客户端软硬件配置要求较高
  2. 客户端程序设计复杂
  3. 数据安全性不好，客户端程序可以直接访问数据库服务器
  4. 信息内容和形式单一
  5. 用户界面风格不一，使用繁杂，不利于推广使用
  6. 软件维护与升级困难，每个客户机上的软件都需要维护
  

三层Client/Server ( Client-Application-Server )

Client-Application-Server.png

与二层C/S结构相比，增加了一个应用服务器。
整个应用逻辑驻留在应用服务器上，只有表示层存在于客户机上（“瘦客户端”）
应用功能分为三层：表示层、功能层(业务逻辑层)、数据层

B/S

- B/S是三层C/S的特例
- 客户端为http浏览器
    - 为增强功能，往往还需要安装flash、jvm及一些专用插件
    - 使用标准http/https协议
    - 要考虑浏览器兼容的问题
- 早期只能“拉”不能“推”，现在已有较多的推送
- 客户之间的通信只能通过服务器中转
- 安全性较难控制（SQL注入攻击等）
- 数据查询等响应速度低于C/S体系结构
- 服务器的负荷大，客户机的资源浪费
    - 用RIA等技术解决，主流浏览器也对硬件逐步利用

Data Centered / Shared Data

• 这种风格描绘很多种系统 (共同特点是共享数据)
• 收集、操作、存储大量的数据
• 数据库是一个典型的例子

DataRepository.png

• 星型结构简化了拓扑
• 优点-- –很容易增加数据的生产者和消费者

Repository Architecture

• 除数据库外，剪贴板、注册表是典型的仓库风格的例子

• 种类：

  1. 设计者预先定义好   编译器
  2. 输入流的信息类型决定      数据库事物系统
  3. 系统其他部分的新信息决定   Scratchboard（刮板）
  4. 机会主义：计算的状态决定   Blackboard
  

Blackboard

• “黑板”属于“仓库”的变种，黑板的作用相当于“共享内存”

• 如同多位不同专长的专家在同一黑板上交流思想，每个专家都可以获得别的专家写在黑板上的信息，同时也可以用自己的分析去更新黑板上的信息，从而影响其它专家

• 解决无确定性求解策略问题（边走边看，摸着石头过河）

• Blackboard的组成

  - 知识源（专家）
    - 包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。一个知识源只能解决问题的一部分（一个方面）
          - 提供解决问题的知识
          - 变现为过程、规则、逻辑断言
          - 仅能修改黑板，无法与其他知识源交互
          - 知道何时能发挥作用
          - 低耦合的子任务，或者有特别的能力
  
  - 黑板数据结构
    - 按照与应用程序相关的层次来组织的解决问题的数据，知识源利用黑板的接口对黑板进行读写，通过不断地改变黑板数据来解决问题。
        - 保存知识源要使用的数据
          - 保存来自解空间的数据
          - 分层；同层或者不同层的对象的之间的关联
          - 与仓库的区别：
            - 黑板：黑板的状态触发进一步的操作
            - 仓库：操作的执行次序是预先确定的
  
  - 控制（仲裁者）
    - 控制完全由黑板的状态驱动，监控黑板的变化，决定下一步选用哪个知识源进行工作
        - 让知识源响应偶然事件
          - 连接各个知识源的能力，决策解决问题的步骤
          - 控制机制是与时俱进、随机应变的
  
  

• The Blackboard Model

  - Knowledge Sources
    - Problem-appropriate knowledge partitioned into separate, independent computations   把问题分成几个部分，每个部分独立计算
    - React to changes in blackboard 对黑板的变化做出反应
  
  - Blackboard Data Structure
    - Global database containing entire state of problem solution 
        全局数据库包含解决方案的全部状态
    - Only means by which knowledge sources interact
        知识源互相关联的唯一媒介
  
  - Control
    - 完全由黑板的状态驱动，黑板的状态的改变决定使用的特定知识
    - Knowledge sources respond “opportunistically” 让知识源响应偶然事件
  
  

• Blackboard Problem Characteristics

  - 没有直接的算法可解
    - 多种方法都可能解决问题
    - 需要多个领域的专门知识协作解决
  - 不确定性 uncertainty
    - 数据和解决方法可能错误或变化
    - 数据中信噪比的变化
    - 算法接口的变化
  - 问题没有唯一个解答，或者“正确”答案会变化
  

Virtual Machine

• 一种软件、创建了虚拟的环境、屏蔽了底层平台

• 分类

  – 系统级（硬件虚拟机）：可以把一台电脑虚拟为运行不同OS的多台电脑
  – 进程级（应用程序虚拟机）：JVM
  – 机器聚合：云计算
  

Interpreter.png

• 优点

  - 功能性 Functionality
    - 可以仿真非本地的功能
  - 测试性 Testing
    - 能够仿真灾难的模式
  - 灵活性 Flexibility
    - 多用途的工具
  

• 缺点

  - 效率 Efficiency
    - 比硬件效率慢的多
    - 比编译系统慢
  - 测试性 Testing
    - 增加了软件要去验证的层数
  

• 解释器和编译器的区别

  - 解释器的执行速度慢于编译器产生的目标代码的执行速度，但低于“编译+链接+执行”的总时间
  - 每次解释执行时，都需要分析程序结构，而编译器只需一次性编译代码
  

Rule-based system

Rule-based system.png

• 解决的问题

  - 业务规则很复杂时，并且规则总是发生变化，不宜用if-else结构
  - 按照OCP（开放/封闭原则），应把可变部分与不变部分进行分离，在前者变化时不影响后者
  

• 基于规则的系统：一种特殊的虚拟机，使用模式匹配搜索来寻找规则，并在正确时机应用正确的规则

• 特点

  - 1个引擎
    - Interpretation engine (rule interpreter)
  - 3个存储区
    - Code to be executed (knowledge base)
    - Control state of interpreter (rule/data selection)
    - Current state of the code (working memory)
    
  注：仍然是 1引擎+3存储区 的结构，构件与解释器风格类似 
  

• 优点

  - 降低修改业务逻辑的成本与风险
  - 缩短开发时间
  - 规则可在多个应用中共享
  

• 与解释器风格的不同

  - 解释器：在高级程序语言与OS/硬件平台间建立虚拟机
  - 基于规则的系统：在自然语言/XML规则和高级程序语言建立虚拟机
  

• 常见的规则

  - 用户界面输入的合法性检查
  - 安全规则/权限控制规则
  - 业务策略（如VIP折扣策略等,与“Strategy模式”类似）
  

Independent Component

• Communicating Processes

  CommunicatingProcesses.png

  • 完成任务需要多个proc协同，prco间的协同通过msg完成。msg是“显性”的，即需要指明“源”和“目的地”

  • 组件间相对独立，依靠发消息通信

  • Model

    - 系统模型：独立的通信的(communicating)进程
    - 组件：收发消息的过程
    - 连接件：消息
    - 控制结构：每一个进程有自己的控制线程
    

  • Design Considerations

    - 消息长了错误率高，消息短了效率低
    

• Event Systems

  • 隐式调用

    基于事件的隐式调用风格的思想：
    - 构件不直接调用一个过程，而是触发一个或者多个事件
    - 其他构件中的过程注册一个或多个事件，当一个事件被触发，系统自动调用在这个事件中注册的所有过程
    - 构件是一些模块（过程，或者事件的集合）
    - 主要特点是：事件的触发者并不知道哪些构件会被这些事件影响
      - 不能假定构件的处理顺序，甚至不知道哪些过程会被调用
      - 许多隐式调用的系统也包含显示调用作为构建交互的补充形式
    

  • 优点

    - 问题分解：
      - 为软件重用提供了强大的支持。当需要将一个构建加入现存系统中时，只需将它注册到系统的事件中。新的关注者不对现有的关注者构成任何影响
    - 系统维护和重用
      - 为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其他构件的接口。
    - 性能
      - 调用可以是并行的
    - 鲁棒性
      - 一个构件的故障不会影响其它构件
    - 核心思想：系统分解为多个低耦合的模块
    

  • 缺点

    - 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。
    - 数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。
    - 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。
    

C2 Architecture Style

• 通过连接件绑定在一起的按照一组规则运行的并行构件网络。

• 系统组织规则

  - 系统中的构件和连接件都有一个顶部和一个底部
  - 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的
  - 一个连接件可以和任意数目的其他构件和连接件连接
  - 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
  

• 特点

  - 系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起
  - 所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的
  - 构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。
  

• HMB (Hierarchy Message Bus)

Heterogeneous Architectures

• 随着系统越来越复杂，不可能都在单一的结构上进行设计

• 多种体系结构的组合方式

  - 聚合方式
    - 组件的体系结构。例如：编译器中的文法分析组件
  - 联合放式
    - 某一个组件或连接件成为两种以上体系机构联系的纽带
    - 可能是聚合方式的展开
    - 例如：视频点播系统
  - 混合方式
    - 把多种体系结构的优点，混合使用。主要体现在连接件的混合使用。
    - 例如：事件驱动的CASE系统。
  

• B/S与C/S混合软件体系结构 是一种典型的异构体系结构

  - 内外有别模型
  - 查改有别模型
  

对等网(P2P)

• 特点

  - 整体稳定，不会因为一点的错误影响全局
  - 资源共享，任务分摊
    - 我为人人，人人为我
    - 每点还要承担一定量的中转负荷    
    - 对网络带宽占用极大
  - 内容很难有效控制
  

质量属性

• 质量属性场景

  - 刺激源 - 刺激    - 制品    - 环境    - 响应    - 响应量度
  

• 系统质量属性：U-STAMP

  1. 可用性 availability
  2. 可修改性 modifiability
  3. 性能 performance
  4. 安全性 security
  5. 可测试性 testability
  6. 易用性 usability
  

设计体系结构

• Tactics：满足特定质量属性的具体设计手段

Availability tactics

• 尽可能降低“故障”所造成的影响

  1. 故障检测 Fault Detection
  2. 故障恢复：备份的方法 Fault Recovery 
  3. 错误避免： Fault Prevention
  

  availability tactics.png

modifiability tactics

• 关注的是：时间和花费

1. 局部化修改
   1. 保持语义的一致性
   2. 预期期望的变更
   3. 一般化模块
   4. 限制可能的选项
2. 阻止连锁反应
   1. 隐藏信息
   2. 维护已存在的接口
   3. 限制通信路径
   4. 使用中间人
   5. location of A
      1. 每次搬家把新地址告诉父母，朋友联系不到你，也可以通过父母知道你的住址
   6. existence of A
   7. A的资源的行为/A的资源的控制
      1. 由资源管理器来调配资源
3. 延迟绑定时间
   1. 运行时注册
   2. 发布/订阅
   3. 配置文件
   4. 多态
   5. 构件更换
   6. 定义协议

modifiability tactics.png

performance tactics

1. 资源申请：干的事少一点
   1. 提高计算的效率
   2. 降低计算的开支
   3. 管理事件的速率
   4. 控制采样的频率
   5. 控制执行的时间
   6. 控制队列的等待人数的多少
2. 资源管理：牛一点
   1. 引入并发机制
   2. 提高可用的资源
3. 资源仲裁：获取资源快一点
   1. 先进/先出
   2. 固定优先级调度
   3. 动态优先级调度
   4. 静态调度（顺序不能改变）

performance tactics.png

security tactics

• 关注点：合法用户可以用，非法用户不能使用

  1. 抵抗攻击
     1. 认证用户
     2. 对用户进行授权
     3. 维护数据的私密性
     4. 维护完整性
     5. 限制曝光
     6. 限制访问
  2. 检测攻击
     1. 存储状态
     2. 攻击者的识别
  3. 从攻击中恢复
     1. 审查跟踪
  

  Tactics for Security.png

testability tactics

• 关注点：测试成本，是不是容易在测试的时候，发现错误

  1. 黑盒
     1. 记录/重放
     2. 实现与接口分离
     3. 特殊化访问线路/接口
  2. 白盒
     1. 设置断点
  

  Testability Tactics.png

usability tactics

1. 运行时
   1. 维护系统的模型
   2. 维护用户模型
   3. 维护任务的模型
2. 设计时
   1. 用户界面与其他部分分开

Usability Tactics.png

tactics summary

• 从涉众处了解要达到的质量属性要求（如教务系统和银行关于安全的设置的不同）

• pattern/style和tatics分别处理高层和具体细节

答卷要点

• 选择这个架构为什么可以满足需求，以及为什么该架构的缺点是可容忍的

  
  
  效用树

image.png