东南大学-软件体系结构-期末复习笔记

概述

软件架构的思想和特征

软件架构的主要思想：将注意力集中在系统总体结构的组织上

特征：

• 注重可重用性
  • 实现方式：组件及架构级重用
  • 作用：提高软件质量
• 利益相关者较多
  • 实现方式：满足各利益相关者需求
  • 作用：平衡需求
• 关注点分离
  • 实现方式：分而治之、模块化
  • 作用：简化复杂性
• 质量驱动
  • 实现方式：使用软件架构来处理质量属性需求、控制复杂性
  • 作用：由功能、数据流驱动向质量驱动转变
• 概念完整性
  • 实现方式：强调设计决策是一个持续的过程
  • 作用：每个决策都要在其前面设计决策的基础上进行
• 循环风格
  • 实现方式：架构风格、架构模式
  • 作用：用标准方法来处理反复出现的问题

软件架构定义

组成派定义

软件架构={元素，组成，原理}

• 架构元素是指具有一定形式的结构化元素，包括处理元素（processing elements）、数据元素（data elements）和连接元素（connecting elements）。
• 架构组成由加权的属性（weighted properties）和关系（weighted relationships）构成。属性用来约束架构元素的选择，关系用来约束架构元素的放置（placement）。
• 架构原理捕获在选择架构风格、架构元素和架构形式的选择动机。

组件可以是一组代码，也可以是独立的程序；连接件可以是过程调用、管道和消息等，用于表示组件之间的相互关系；约束一般为组件连接时的条件。

软件架构是某一系统的基本组织结构，其内容包括软件组件、组件间的联系、组件与其环境间的联系，以及指导上述内容设计与演化的原理。

决策派定义

软件架构是一系列重要决策的集合，这些决策关于：软件系统的组织；组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；如何组合这些元素，使它们逐渐合成为更大的子系统；架构风格；这些元素以及它们的接口、协作和组合。

软件架构是架构层次上所有设计决策的集合体，这些设计决策与以下内容有关：架构改造的影响、原理、设计准则、设计约束以及附加需求。

软件架构是“设计决策+设计”，这里的设计指的是设计决策的推理过程。

参考定义框架(一般性定义)

软件架构一般由如下五种元素构成： 组件（component）、连接件（connector）、配置（configuration）、端口（port）和角色（role）。

• 组件：具有某种功能的可重用的软件模块单元，表示了系统中主要的计算单元和数据存储。组件有两种：复合组件和原子组件。复合组件由其它复合组件和原子组件通过连接而成。
• 连接件：表示了组件之间的交互。
  • 简单的连接件有：管道（pipe）、过程调用（procedure call）、事件广播（event broadcast）等。
  • 复杂的连接件有：客户－服务器（client-server）通信协议，数据库和应用之间SQL连接等。
• 配置：表示了组件和连接件的拓扑逻辑和约束 （constraint）。
• 端口：组件作为一个封装的实体，只能通过其接口与外部交互，组件的接口由一组端口组成，每个端口表示了组件和外部环境的交汇点。
  • 通过不同的端口类型，一个组件可以提供多重接口。
  • 端口可以很简单，如过程调用；也可以很复杂，如通信协议。
• 角色：连接件作为建模软件体系结构的主要实体，同样也有接口，连接件的接口由一组角色组成，连接件的每个角色定义了该连接件表示的交互的参与者。
  • 二元连接件有两个角色，如：RPC的角色为 caller 和callee， pipe 的角色是reading 和writing，消息传递的角色是sender 和receiver等。
  • 有的连接件有多于两个的角色，如事件广播有一个事件发布者角色和任意多个事件接收者角色。

软件架构模型

软件架构建模的五类方法

基于非规范的图形表示的建模方法(可视化)

图形可视化是将软件架构按照图形的方式进行表达，需要便于涉众阅读、理解和交流，使之不会因图形过于复杂而难以把握软件架构的概况。

• 正式图形表示：有严格定义的结构
  • 树形结构
  • 树地图
  • 改进的树地图
  • 冰块图
  • 旭日图
  • 双曲树
• 非正式图形表示：不具有严格的标准，较为随意，具有一定方便交流的作用。如：盒线图、pointpower风格图形

基于UML的建模方法

UML定义了一组丰富的模型元素以建模组件、接口、关系和约束。UML作为一个工业化标准的可视化建模语言，支持扩展，并有强大的工具支持。可以把UML看作一种架构建模语言。

• UML提供了对架构中组成要素建模的支持

  架构元素	UML模型元素
  组件	分类器(如类、组件、节点、用例等)
  接口	接口
  关系(连接器)	关系(如泛化、关联、依赖等)
  约束(规则)	规则

• 为了降低架构建模的复杂度，软件设计人员可以利用UML从多个不同的视角来描述软件架构

  • 逻辑视图

    关注功能，可以采用UML用例图来实现

  • 开发视图

    关注软件的静态组织结构，使用UML的类图、对象图和组件图来表示模块，用包来表示子系统，利用连接表示模块或子系统之间的关联

  • 过程视图

    关注软件的流程特征，可以采用UML的状态图、顺序图、活动图来实现

  • 物理视图

    关注功能单元的分布状况，可以使用UML的配置图来实现

  • 场景视图

    关注用户需求，可以使用用例或场景来描述

• 使用UML表示软件架构的具体实现如下

  • 软件架构仅由其组件元素构成
  • 组件具有两个标记值(tagged value)：kindofComponent表示它是原子组件或组合组件，而sub-Component表示它是子组件
  • 组件只能通过Port与其他连接件相关联，而不能直接与其他组件相关联；每个组件都有一个或多个Port；一个Port至多只能与一个连接件关联
  • 每一个连接件至少与两个组件相连，且组件和连接件不参加其语义范围以外的任何关联
  • 组合组件的子组件只能是由连接件连接起来的组合组件或原子组件
  • 原子组件不能再包含其他组件(原子组件或子组件)

• UML对软件架构建模的主要优点

  • 通用的模型表示法、统一的标准，便于理解和交流
  • 支持多视图结构，能够从不同角度来刻画软件架构，可以有效地用于分析、设计和实现过程
  • 有效利用模型操作工具(支持UML的工具集)，可缩短开发周期，提高开发效率
  • 统一的交叉引用模型信息的方法，有利于维护开发元素的可处理性，避免错误的产生

• UML虽然可以对软件架构进行较好的描述，但它只是针对特定的面向对象的架构，比如对架构缺少形式化的支持，使用UML建模存在着一些问题

  • 对架构的构造性建模能力不强，还缺乏对架构风格和显式连接件的直接支持
  • 虽然UML使用交互图、状态图和活动图描述系统行为，但语义的精确性不足
  • 使用UML多视图建模产生信息冗余和不一致
  • 对架构的建模只能到达非形式化的层次，不能保证软件开发过程的可靠性，不能充分表现软件架构的本质

• 用UML对架构进行建模的三种途径

  • 将UML看作是一种软件架构描述语言直接对架构建模
  • 通过扩展机制约束UML的元模型以支持软件架构建模的需要
  • 对UML的元模型进行扩充

• 将UML模型转换为架构模型步骤

  • 建立基于UML的应用领域模型
  • 建立非形式化的架构图
    1. 定义类接口，来表示架构中的主要组件元素——消息接口
    2. 定义连接件connectors类。每个连接件可以认为是一个简单类，将接收到的消息发送到合适的组件
    3. 建立表示架构风格的UML类图，主要描述类之间接口关系。这步主要是建立精化的类图
    4. 使用协作图描述类的实例，表达拓扑内容

• 基于UML的性能模型

  作用

  • 在软件开发早期对软件模型的性能进行研究
  • 对软件架构设计方案进行定量的预测和评价
  • 对各种设计决策进行比较，从而选择更优的软件架构设计方案

  为使UML模型能够描述系统性能需求，一种叫做SPT

基于形式化规格说明语言的建模

基本思想是利用一些已知特性的数学抽象来为目标软件系统的状态特征和行为特征构造模型

• Z语言
• Petri网
• B语言
• VDM
• CSP

基于UML形式化的建模

基本思想是利用形式化与UML结合的建模方法研究成果，对UML图形赋予形式化语义，然后就可以利用已有的形式化语言和工具对UML模型进行推理验证。

• UML不是一种形式化的语言

  尽管UML可以用于描述软件架构，对各种软件系统或离散型系统进行建模，并且通过相应支持工具的配合进行架构的文档化和部分目标语言代码的生成。然而，UML不是一种形式化的语言，不能精确的描述系统的运行语义。

  形式化方法和UML存在很大的互补性，二者的结合研究对提高软件架构的建模质量有着非常重要的意义。

  形式化与UML结合的建模过程和UML统一建模过程有明显的不同，它的目标是希望能够直接构造出尽可能正确的系统。

• UML的形式化

  • 类图的形式化

    UML类图是由类、联系和泛化组成的。在类图中，类的名称是唯一的并且联系和泛化涉及到的类应该是在同一个类图中。

    类的形式化

    • 名称

    • 属性

      名称、可见性、类型和多重性

    • 操作

      名称、可见性

      参数操作的每个参数有名称和类型

    关联形式化

    • 类之间的关系用关联来表示，通常是二元关联，有一个关联名和两个关联端。
    • 二元关联有一个名字并且恰好有两个关联端

    泛化形式化

    • 泛化描述了对象之间的分类关系
    • 超类对象描述了通用的信息，子类对象描述了特定的信息
    • 该约束表示不允许循环继承

  • 用例图的形式化

    角色形式化

    • 角色是与系统交互的外部实体(人或事)，代表的是一类能使用某个功能的人或事
    • 假设类A和类B使用系统的功能时具有角色C，则角色C可以表示成Actor C == A ∪ B

    用例形式化

    系统形式化

  • 状态图的形式化

    迁移形式化

    • 迁移模式表征一个迁移所引起的状态变化，关联迁移前的变量值与迁移后的变量值。
    • 迁移具有触发事件、迁移条件、动作、源状态和目标状态。

    状态形式化

    • 状态模式包含变量声明和使用声明变量的谓词集。
    • 动态属性由迁移模式描述，而静态属性则由属性模式和操作模式来描述。

  • 顺序图的形式化

    UML顺序图用于描述对象间动态的交互关系，着重体现对象间消息传递的时间顺序

    水平轴表示不同的实例

    垂直轴表示时间

    实例形式化、消息形式化

UML与Z结合的建模过程是在目前软件规模和复杂性不断增大的情况下提出的，它是对现在工业界软件架构建模过程做了一 些改进，并提出了一些新的思路和构想。

其他的形式化方法也可以将非形式化的UML图形转换为具有精确语义的形式化规范，在非形式化的图形表示与形式化定义之间建立映射关系。

UML中的类图、用例图、状态图以及顺序图较适合形式化描述，其他的图用形式化的描述方法反而使得描述过程变得更加复杂，容易降低效率。

其他建模方法

文本语言建模方法

通过文本文件描述架构，这些文本文件通常需要符合某些特殊的句法格式

• 可用方法
  • 语法高亮显示
  • 文本的静态检查
  • 自动补全
  • 代码折叠
• 优势
  • 单个文档中描述整体架构，并且存在众多文本编辑器方便用户与文本文档的交互
  • 许多工具能够生成程序库来对使用该语言的文本文档进行句法分析和检查
  • 许多编辑器附带额外的开发支持工具
• 缺陷
  • 用文本语言建模方法表示类图形结构就不易理解
  • 文本编辑器通常限于显示连续满屏的文本，很难以另外的方式组织文本

模型驱动的架构建模方法(MDA)

MDA不是一个实现分布式系统的软件架构，而是一个模型技术进行软件开发的方法。

致力于将软件开发从以代码为中心提高到以模型为中心，使模型不仅被作为设计文档和规格说明来使用，更成为一种能够自动转换为最终可运行系统的重要软件制品。

在MDA中，将模型区分为PIM和PSM

• 平台无关模型(PIM)

  是一个系统的形式化规范，它与具体的实现技术无关。

• 平台相关模型(PSM)

  基于某一具体目标平台的形式化规范。模型不再仅仅是描绘系统、辅助沟通的工具，而是软件开发的核心和主干。

他的核心思想是抽象出与实现技术无关、完整描述业务功能的平台独立模型。

软件架构建模方法的发展趋势

• 第一层次：文本模型

  从原始的自然语言文档化到以XML为代表的有固定规范、结构的文档化。

• 第二层次：图形可视化模型

  将软件架构按照图形的方式进行表达，需要便于涉众阅读、理解和交流，使之不致因图形过于复杂而难以把握软件架构的概况。

• 第三层次：UML模型

  使用单一的集成的表示法来对系统的多个方面进行建模，模型范畴包括从系统的静态结构到动态行为特征、从系统的逻辑功能到物理部署。

• 第四层次：形式化模型

  	兴起时间	理论基础	研究方法	缺点
  形式化建模	90年代初期	形式化规格说明语言	基于模型的方法	规范难以确认
  			代数方法	难以理解，扩展性差
  UML模型的形式化	90年代后期	UML模型和形式化规格说明语言	核心语法形式化	难以和各种UML图形匹配
  			约束语言方法	难以获得元模型数据
  			形式化转换	受到形式语言技术制约

软件架构风格

什么是软件架构风格

软件架构风格又称软件架构惯用模式，是描述某一特定应用领域中系统组织方式的惯用模式，作为“可复用的组织模式和习语”，为设计人员的交流提供了公共的术语空间，促进了设计复用与代码复用。

使用架构风格的好处

• 可以极大地促进设计的重用性和代码的重用性，并且使得系统的组织结构易被理解。

  即使没有给出具体实现细节，依然可以通过“客户/服务器”架构风格大致推测出系统的组成结构和工作方式

• 使用标准的架构风格可较好地支持系统内部的互操作性以及针对特定风格的分析

  如：“管道/过滤器”风格可用来分析调度、吞吐量、延迟，和死锁等问题。

下列经典体系结构风格的特点、优缺点、适用范围

管道过滤器风格

基本思想

• 在管道过滤器风格下，每个功能模块都有一组输入和输出。

• 功能模块称作过滤器（filters）；功能模块 间的连接可以看作输入、输出数据流之间 的通路，所以称作管道（pipes）。

• 管道-过滤器风格的特性之一在于过滤器的 相对独立性，即过滤器独立完成自身功能， 相互之间无需进行状态交互。

特点

• 过滤器是独立运行的组件
  • 非临近的过滤器之间不共享状态
  • 过滤器自身无状态
• 过滤器对其处理上下连接的过滤器“无知”
  • 对相邻的过滤器不施加任何限制
• 结果的正确性不依赖于各个过滤器运行的 先后次序
  • 各过滤器在输入具备后完成自己的计算。完整 的计算过程包含在过滤器之间的拓扑结构中。

优点

• 由于每个组件行为不受其他组件的影响，整个系统的行为易于理解

  使得软件组件具有良好的隐蔽性和高内聚、 低耦合的特点，允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成。

• 管道-过滤器风格支持功能模块的复用

  任何两个过滤器，只要它们之间传送的数 据遵守共同的规约，就可以相连接。每个过滤器都有自己独立的输入输出接口，如果过滤器间传输的数据遵守其规约，只要用管道将它们连接就可以正常工作。

• 基于管道-过滤器风格的系统具有 较强的可维护性和可扩展性

  旧的过滤器可以被替代，新的过滤器可以添加到已有的系统上。软件的易于维护和升级是衡量软件系统质量的重要指标之一， 在管道-过滤器模型中，只要遵守输入输出数据规约，任何一个过滤器都可以被另一 个新的过滤器代替，同时为增强程序功能， 可以添加新的过滤器。这样，系统的可维护性和可升级性得到了保证。

• 支持一些特定的分析，如吞吐量 计算和死锁检测等

  利用管道-过滤器风格的视图，可以很容易 得到系统的资源使用和请求的状态图。然后，根据操作系统原理等相关理论中的死锁检测方法就可以分析出系统目前所处的状态，是否存在死锁可能及如何消除死锁等问题。

• 管道-过滤器风格具有并发性

  每个过滤器作为一个单独的执行任务，可以与其它过滤器并发执行。过滤器的执行是独立的，不依赖于其它过滤器的。在实际运行时，可以将存在并发可能的多个过滤器看作多个并发的任务并行执行，从而大大提高系统的整体效率，加快处理速度。

缺点

• 管道-过滤器风格往往导致系统处理过程的成批操作。

• 根据实际设计的需要，设计者也需要对数据传输进行特定的处理（如为了防止数据泄漏而采取加密等手段，或者使用了底层公共命名），导致过滤器必须对输入、输出管道中的数据流进行解析或反解析，增加了过滤器具体实现的复杂性。

• 交互式处理能力弱

  管道-过滤器模型适于数据流的处理和变换， 不适合为与用户交互频繁的系统建模。在这种模型中，每个过滤器都有自己的数据， 这些数据或者是从磁盘存储器中读取来，或者是由另一个过滤器的输出导入进来，整个系统没有一个共享的数据区。这样， 当用户要操作某一项数据时，要涉及到多个过滤器对相应数据的操作，其实现较为复杂。由以上的缺点，可以对每个过滤器增加相应的用户控制接口，使得外部可以对过滤器的执行进行控制。

适用范围

1. UNIX的shell中编写的程序
2. 传统编译器
3. 信号处理领域
4. 并行计算
5. 功能编程
6. 分布式系统

面向对象风格

是80年代初期提出的一种新型的程序设计方法， 它彻底改变了过去数据流、事物流分析方式的缺点，采用直接对问题域进行自然抽 象的方法，并逐渐发展成包括面向对象分析、设计、编程、测试、维护等一整套内容的完整体系。

该架构风格从现实世界中客观存在的事物出发，强调直接以问题域中的事物为中心来思考问题、认识问题，根据这些事物的本质特征，将其抽象为系统中的对象，并作为系统中的基本构成单位。

特点

• 对象负责维护其表示的完整性（通常是通过保持其表示上的一些不变式来实现的）

• 对象的表示对其他对象而言是隐蔽的。 抽象数据类型的使用，以及面向对象系统的使用已经非常普遍。

优点

• 对象隐藏了其实现细节，所以可以在不影响其它对象的情况下改变对象的实现， 不仅使得对象的使用变得简单、方便，而且具有很高的安全性和可靠性。

• 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

缺点

当一个对象和其它对象通过过程调用等方式进行交互时，必须知道其它对象的标识。 无论何时改变对象的标识，都必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。

适用范围

事件驱动风格

基本思想

不直接调用一个过程，而是发布或广播一个或多个事件。系统中的其它组件通过注册与一个事件关联起来的过程，来表示对某一个事件感兴趣。当这个事件发生时， 系统本身会调用所有注册了这个事件的过程。这样一个事件的激发会导致其它模块中过程的隐式调用。

事件：是指可以被系统识别的、发生在界面上的用户动作或者状态变化。

一般步骤

1. 确定响应事件的元素；
2. 为指定元素确定需要响应的事件类型；
3. 为该元素的相应事件编写事件处理程序；
4. 将事件处理程序绑定到指定元素的指定事件。

特点

• 事件发布者不知道哪些组件会受到事件的影响；组件不能对事件的处理顺序，或者事件发生后的处理结果做任何假设。

• 从架构上来说，事件驱动系统的组件提供了一个过程集合和一组事件。

• 过程可以使用显示的方法进行调用，也可以由组件在系统事件中注册。当触发事件时，会自动引发这些过程的调用。

• 连接件既可以是显示过程调用，也可以是一种绑定事件声明和过程调用的手段。

优点

• 事件声明者不需要知道哪些组件会影响事件，组件之间关联较弱。

• 提高软件复用能力。只要在系统事件中注册组件的过程，就可以将该组件集成到系统中。

• 系统便于升级。只要组件名和事件中所注册的过程名保持不变，原有组件就可以被新组件替代。

缺点

• 组件放弃了对计算的控制权，完全由系统来决定。
• 存在数据交换问题。
• 该风格中，正确性验证成为一个问题。

适用范围

隐式调用

断点处理

事件及消息机制win32

数据库管理系统中一致性约束

用户界面中数据表示与管理数据的应用程序的分离

语法导向的增量语义检查

黑板系统风格

黑板系统（Blackboard System）是传统上被用于信号处理方面进行复杂解释的应用程序，以及松散耦合的组件访问共享数据的应用程序。

黑板架构实现的基本出发点是已经存在一个对公共数据结构进行协同操作的独立程序集合。

组成部分

1. 知识源
2. 黑板数据结构
3. 控制器

优点

• 便于多客户共享大量数据，他们不关心数据何时有的、谁提供的、怎样提供的。

• 既便于添加新的作为知识源代理的应用程序，也便于扩展共享的黑板数据结构。

• 知识源可重用。

• 支持容错性和健壮性。

缺点

• 不同的知识源代理对于共享数据结构要达成一致，而且，这也造成对黑板数据结构的修改较为困难——要考虑到各个代理的调用。
• 需要一定的同步/加锁机制保证数据结构的完整性和一致性，增大了系统复杂度。

适用范围

起源于人工智能领域，经典应用领域有自然语言处理、语音处理、模式识别、图像处理等

C2风格

通过连接件 绑定在一起的按照一组规则运作的并行组件网络。该规则规定了所有组件之间的交互必须通过异步消息机制来实现

C2是一种基于组件和消息的架构风格， 适用于GUI软件开发，构建灵活和可扩展的应用系统。

C2风格的系统组织规则：

• 组件之间不能直接连接；

• 组件和连接件都有一个顶部和一个底部；

• 组件的顶部应连接到某连接件的底部，组件的底部则应连接到某连接件的顶部；

• 一个连接件可以和任意数目的其他组件和连接件连接；

• 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

优点

• 可使用任何编程语言开发组件，组件重用和替换易实现；

• 由于组件之间相对独立，依赖较小，因而该风格具有一定扩展能力，可支持不同粒度的组件；

• 组件不需共享地址空间；

• 可实现多个用户和多个系统之间的交互；

• 可使用多个工具集和多种媒体类型，动态更新系统框架结构。

缺点

不太适合大规模流式风格系统，以及对数据库使用比较频繁的系统。

适用范围

主要用于具有图形化用户界面的应用程序

客户机/服务器风格

客户机/服务器（Client/Server)是20世纪90年代开始成熟的一项技术，主要针对资源不对等问题而提出的一种共享策略。

客户机和服务器是两个相互独立的逻辑系统，为了完成特定的任务而形成一种协作关系。

• 客户机(前端，front-end)：业务逻辑、与服务器通讯的接口；

• 服务器(后端：back-end)：与客户机通讯的接 口、业务逻辑、数据管理。

两层C/S架构优点

• 客户机组件和服务器组件分别运行在不同的计算机上，有利于分布式数据的组织和处理。

• 组件之间的位置是相互透明的

• 客户机程序和服务器程序可运行在不同的操作系统上，便于实现异构环境和多种不同开发技术的融合。

• 软件环境和硬件环境的配置具有极大的灵活性，易于系统功能的扩展。

• 将大规模的业务逻辑分布到多个通过网络连接的低成本的计算机上，降低了系统的整体开销。

两层C/S架构缺点

• 开发成本较高（客户机的软硬件要求高）。

• 客户机程序的设计复杂度大，客户机负荷重。

• 信息内容和形式单一。

• C/S架构升级需要开发人员到现场更新客户机程序，对运行环境进行重新配置，增加了维护费用。

• 两层C/S结构采用了单一的服务器，同时以局域网为中心，难以扩展到Internet。

• 数据安全性不高。

三层C/S架构相比于两层的优点

• 合理地划分三层结构的功能，可以使系统的逻辑结构更加清晰，提高软件的可维护性和可扩充性。

• 在实现三层C/S架构时，可以更有效地选择运行平台和硬件环境，从而使每一层都具有清晰的逻辑结构、良好的负荷处理能力和较好的开放性。

• 在C/S架构中，可以分别选择合适的编程语言并行开发。

• 系统具有较高的安全性。

在使用三层C/S架构时需注意以下两个问题：

• 如果各层之间的通信效率不高，即使每一层的硬件配置都很高，系统的整体性能也不会太高。
• 必须慎重考虑三层之间的通信方法、 通信频率和传输数据量，这和提高各层的独立性一样也是实现三层C/S架构的关键性问题。

适用范围

数据和处理分布在一定范围的多个组件上，组件之间通过网络连接。

浏览器/服务器风格

浏览器/服务器风格是三层C/S风格的一 种实现方式。

主要包括浏览器，Web服务器和数据库服务器。

与三层C/S结构的解决方案相比，B/S架构在客户机上采用了WWW浏览器， 将Web服务器作为应用服务器。

B/S架构核心是Web服务器，数据请求、 网页生成、数据库访问和应用程序执行全部由Web服务器来完成。

在B/S架构中，系统安装、修改和维护全在服务器端解决，客户端无任何业务逻辑。

优点

• 客户端只需要安装浏览器，操作简单， 能够发布动态信息和静态信息。

• 运用HTTP标准协议和统一客户端软件，能够实现跨平台通信。

• 开发成本比较低，只需要维护Web服务器程序和中心数据库。客户端升级可以通过升级浏览器来实现。

缺点

• 个性化程度比较低，所有客户端程序的功能都是一样的。

• 客户端数据处理能力比较差，加重了Web服务器的工作负担，影响系统的整体性能。

• 在B/S架构中，数据提交一般以页面为单位，动态交互性不强，不利于在线事物处理（Online Transaction Processing，OLTP）。

• B/S架构的可扩展性比较差，系统安全性难以保障。

• B/S架构的应用系统查询中心数据库，其速度要远低于C/S架构。

面向服务架构风格

SOA 是一个组件模型，它将应用程序的不同功能单元（服务）通过这些服务之间定义良好的接口和契约联系起来。

• 服务(service)是一个粗粒度的、可发现的软件实体。

• 接口是采用中立的方式进行定义的，应独立于实现服务的硬件平台、操作系统和编程语言， 便于不同系统中的服务以一种统一和通用的方式进行交互。

服务请求者：可以是服务或者第三方的用户， 通过查询服务提供者在服务注册中心发布的服务接口的描述，通过服务接口描述来通过RPC 或者SOAP进行绑定调用服务提供者所提供的业务或服务。

服务提供者：作为服务管理者和创建者，必须将服务描述的接口发布到服务注册中心才能被潜在的服务请求发现，能够为合适的服务请求者提供服务。

服务注册中心：相当于服务接口的管理中心， 服务请求者能够通过查询服务注册中心的数据库来找到需要的服务调用方式和接口描述信息。

发布：为了便于服务请求者发现，服务提供者将对服务接口的描述信息发布到服务注册中心上。

发现：服务请求者通过查询服务注册中心的数据库来找到需要的服务，服务注册中心能够通过服务的描述对服务进行分类， 使服务提供者更快定位所需要的服务范围。

绑定和调用：服务请求者在查询到所需要服务描述信息，根据这些信息服务请求者能够调用服务。

面向服务软件架构风格在于具有基于标准、松散耦合、共享服务和粗粒度等优势，表现为易于集成现有系统、具有标准化的架构、提升开发效率、降低开发维护复杂度等。

通过采用SOA架构，在进行一次开发成本急剧减少的同时，由于系统具有松散耦合的特征使得维护成本也大大减少。

优点

• 灵活性，根据需求变化，重新编排服务。

• 对IT资产的复用。

• 使企业的信息化建设真正以业务为核心。业务人员根据需求编排服务，而不必考虑技术细节。

缺点

• 服务的划分很困难。
• 服务的编排是否得当。
• 如果选择的接口标准有问题，如主流的Web service之类，会带来系统的额外开销和不稳定性。
• 对IT硬件资产还谈不上复用。
• 目前主流实现方式接口很多，很难统一。
• 目前主流实现方式只局限于不带界面的服务的共享。

适用范围

金蝶EAS

模型-视图-控制器风格

模型-视图-控制器风格（Model- View-Controller，MVC）主要是针对编程语言Smalltalk 80所提出的一种软件设计模式。

MVC结构主要包括模型、视图和控制器三部分。

• 模型(Model, M)：模型是应用程序的核心，它封装了问题的核心数据、逻辑关系和计算功能，提供了处理问题的操作过程。

• 视图(View,V)：视图是模型的表示， 提供了交互界面，为用户显示模型信息。

• 控制器(Controller, C)：控制器负责处理用户与系统之间的交互，为用户提供操作接口。

优点

• 多个视图与一个模型相对应。变化——传播机制确保了所有相关视图都能够及时地获取模型变化信息，从而使所有视图和控制器同步，便于维护。

• 具有良好的移植性。由于模型独立于视图，因此可以方便的实现不同部分的移植。

• 系统被分割为三个独立的部分，当功能发生变化时，改变其中的一个部分就能满足要求。

缺点

• 增加了系统设计和运行复杂性。
• 视图与控制器连接过于紧密，妨碍了二者的独立重用。
• 视图访问模型的效率比较低。由于模型具有不同的操作接口，因此视图需要多次访问模型才能获得足够的数据。
• 频繁访问未变化的数据，也将降低系统的性能。

适用范围

MVC被广泛的应用于用户交互程序的设计中。spring

软件架构与敏捷开发

敏捷开发的基本理念

1. 强调个体和互动比强调过程和工具更好（Individuals and interactions over processes and tools）；
2. 强调获得可运行的软件比强调完成详尽的文档好（Working software over comprehensive documentation）；
3. 强调与客户合作比强调进行详细的合同谈判好（Customer collaboration over contract negotiation）；
4. 强调响应变化比强调遵循既定的计划好（Responding to change over following a plan）

十二条原则

1. 尽早并持续地交付有价值的软件以满足顾客需求；
2. 敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势；
3. 经常交付可用的软件，发布间隔可以从几周到几个月，能短则短；
4. 业务人员和开发人员在项目开发过程中应该每天共同工作；
5. 选择有进取心的人作为项目核心人员，充分支持并信任他们；
6. 无论团队内外，面对面的交流始终是最有效的沟通方式；
7. 可用的软件是衡量项目进展的主要指标；
8. 敏捷流程应能保持可持续的发展。责任人，开发者和用户应该能够保持一个长期的、恒定的开发速度；
9. 不断关注技术和设计会增强敏捷能力；
10. 保持简明（尽可能简化工作量的技艺）极为重要；
11. 最好的构架、需求和设计出自于自组织的团队；
12. 时时总结如何提高团队效率, 并付诸行动；

敏捷开发与架构设计的关系

1. 软件架构与敏捷开发的出发点是一致的。

• 软件架构与敏捷开发都是一个权衡的过程：软件架构设计需要权衡涉众们的各种需求，在众多的解决方案中确定唯一的架构设计方案，从而保证软件开发的有效性。敏捷开发是在软件开发过程混沌和大量开发管理活动加入的两个极端中做出的一种权衡。
• 软件架构与敏捷开发目的都是为了提高软件开发效率、提高软件质量、降低软件成本，将开发团队的价值最大化。

1. 敏捷开发也需要重视软件架构。

• 在敏捷开发的支持者看来，传统的软件架构设计与敏捷思想相违，因为过多的预先设计使得软件开发过程在面对变化时缺乏灵活性，其管理成本极有可能由于后续的重构而成为无用功。
• 根据学术界与企业界的研究和调查，发现软件架构设计对于敏捷开发来说也是必要的。两者在软件开发实践中能够共同存在，且互相促进。

1. 敏捷开发改变了软件架构的设计方式。
   • 敏捷开发非常重视软件的架构设计，但是轻架构的详细设计。
   • 敏捷思想中将传统的架构设计分成：种子架构设计+详细架构设计。
   • 种子架构设计关注软件系统的骨架或轮廓的设计。
   • 敏捷开发将详细架构设计转移到Code编码阶段、重构阶段、单元测试阶段等。
   • 分离后，敏捷软件种子架构的内容包括：软件的架构层次，重要模块、重要类的说明（无须设计全部的类和方法）等。
   • 敏捷开发中架构设计的原则
     • 重要、关键的设计决策必须在软件开发前确定，对于其他详细的设计决策，则需要时再做。
     • 开发过程中，所有的利益相关者都必须全程在一起，便于充分的交流和权衡。
     • 将需求文档化，重视需求，明确表示出不同需求之间的权衡过程。
     • 开发人员要及时的验证架构。
     • 如果必须要进行修改，改动越早越好。
     • 不要突发奇想的修改架构，修改架构需要大家一起深思熟虑。

敏捷开发过程中的软件架构设计

敏捷开发把传统软件开发前期的详细架构设计，分散到了整个敏捷开发软件过程中，以达到提高效率、减少风险的目的。

• 需求分析
  • 敏捷开发中的需求分析引入了架构设计的理念，分为初始阶段需求分析和迭代阶段需求分析。
  • 初始阶段的需求分析中摒弃了具体的细节，仅仅抓住软件最高层的概念。
  • 迭代阶段需求分析是随着项目的进展逐步完善的，具有高适应性。
• 初始设计
  • 初始阶段的目标是在所有涉众之间达成关于项目的生命周期目标的协议，在项目进行之前确定重要的业务和需求风险。
  • 初始设计需要对软件系统的设计进行全局抽象层次上的考虑。
  • 包括系统的基本处理流程、系统的组织结构、模块划分、功能分配等。
• 迭代过程
  • 针对需求的不可预见性，在敏捷开发中使用了迭代过程。
  • 长期的计划通常是不稳定的，单次迭代的短期计划是稳定的。
  • 迭代开发都是基于上次迭代的结果，每次迭代都有一个坚实的基础。
  • 迭代设计：是根据当前迭代过程需要完成的工作任务来进行需求分析、设计和编码等。
  • 重构：迭代过程中的重构往往发生在编码阶段，重构是对软件架构的持续改进。
  • 确定架构：迭代过程中生产出的软件（或组件）经过测试后确实能达到预期的要求，生产出了可交付的软件产品。
  • 客户交流：根据交付的可用软件，与客户进行充分交流。通过客户反馈的信息，快速有效地适应变化，在后续的迭代过程中完成客户的新要求。

敏捷开发中如何改变了软件架构的设计方式

架构驱动的软件开发

架构驱动的软件开发步骤

1. 架构需求获取；
2. 基本架构设计；
3. 架构记录文档化；
4. 架构评估；
5. 架构实现；
6. 架构维护。

质量场景

架构需求要用质量场景进行描述。

• 抽象场景：根据软件的使用进行一定层面的分类（如：软件流水线方式、三层结构等），这些分类就会对相应软件提出一定的需求，此类需求即为架构需求的抽象场景。
• 架构需求要用质量场景进行描述。
  • 对于架构师和领域专家来说，需要做的是从抽象场景描述中获得特定的质量属性场景。
  • 通常来说，我们考虑的特定的质量场景是对性能、可移植性、可替换性、可重用性等质量属性产生影响时的质量场景。

软件架构设计和实现

成功的软件架构的品质

成功的软件架构应具有以下品质

（1）良好的模块化

（2）适应功能需求的变化，适应技术的变化

（3）对系统的动态运行有良好的规划

（4）对数据的良好规划

（5）明确、灵活的部署规划

软件架构设计原则有一般设计原则和关键设计原则两类

一般原则

包含商业原则、数据原则、应用程序原则、技术原则等；

关键设计原则

关注分离点、单一职责原则、最少知识原则等。

将软件架构的概念和原则引入软件需求阶段的好处和不引入的问题

软件架构和软件需求如何协同演化

软件架构映射到详细设计遇到的问题及解决方案

MDA的基本思想及应用MDA的好处

软件体系结构评估

质量属性、质量场景

质量属性：

• 可修改性 度量软件系统变化的成本。变化包括功能扩展、容量扩展、结构更新等。
• 可用性 是指软件能够正常运行的时间比例。可用性=平均工作时间/(平均工作时间+平均修复时间)
• 性能 性能表征软件系统的响应速度或者由响应速度决定的其它度量。
• 可测试性 可测试性表明软件系统在多大程度上容易被测试检查出缺陷。
• 易用性 易用性表明软件系统完成后用户的体验和效率。
• 安全性 安全性代表软件对未授权和非法操作的防卫能力。

体系结构权衡分析方法(ATAM)的相关概念、评估过程(步骤)、优缺点

基本概念

• 敏感点（Sensitivity point）
  • 敏感点是一个或多个构件的特征
  • 敏感点可以使设计师搞清楚实现质量目标时应该注意什么
• 权衡点（Tradeoff point）
  • 权衡点是影响多个质量属性的特征
  • 是多个质量属性的敏感点
  • 权衡点需要进行权衡

敏感点影响一个质量属性，权衡点影响多个质量属性

• 风险承担者、涉众、牵涉到的人（Stakeholders）
  • 体系结构设计师
  • 开发人员
  • 维护人员
  • 集成人员
  • 测试人员
  • 标准专家
  • 性能工程师
• 场景
  • 在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。我们把为得出这些目标而采用的机制叫做场景。
  • 场景是从风险承担者的角度对与系统的交互的简短描述。
  • 在体系结构评估中，一般采用刺激、环境和响应三方面来对场景进行描述

刺激是场景中解释或描述风险承担者怎样引发与系统的交互部分。例如，用户可能会激发某个功能，维护人员可能会做某个更改，测试人员可能会执行某种测试等，这些都属于对场景的刺激。 环境描述的是刺激发生时的情况。例如，当前系统处于什么状态？有什么特殊的约束条件？系统的负载是否很大？某个网络通道是否出现了阻塞等。 响应是指系统是如何通过体系结构对刺激作出反应的。例如，用户所要求的功能是否得到满足？维护人员的修改是否成功？测试人员的测试是否成功等。

步骤

1. 陈述，包括通过它进行的信息交流

   1. ATAM方法的陈述：评估负责人
   2. 商业动机的陈述：项目经理或系统客户
   3. SA的陈述：系统设计人员

2. 调查与分析，包括对照体系结构方法评估关键质量属性需求

   1. 确定体系结构方法：系统设计人员
   2. 生成质量属性效用树（utility tree）：说明构成系统“效用” 的质量属性（性能、有效性、安全性、可修改性、可用性） ，具体到场景层次，标注刺激/反应，并区分不同的优先级
   3. 分析体系结构方法：基于步骤5识别出的高优先级的场景，说明和分析针对这些场景的体系结构方法。在这一步骤中，体系结构风险、非风险、敏感点和权衡点被识别出来

3. 测试，包括对照所有相关人员的需求检验最新结果

   1. 集体讨论并确定场景优先级

   2. 分析体系结构方法：针对步骤7的高等级场景

4. 形成报告，包括陈述ATAM的结果

   1. 结果的表述：包括方法、场景、特定属性的问题、效用树、有风险决策、无风险决策、敏感点和权衡点

以时间为维度，评估分为4个阶段，

• 第0阶段：建立阶段
  • 合作关系的建立——评估客户和评估人员之间
  • 准备工作——组建评估小组，召开开工会议，进行准备
• 第1阶段：第1~6步
  • 以体系结构为中心
  • 重点是获取体系结构信息并对其进行分析
• 第2阶段：第7~9步
  • 以相关人员为中心
  • 重点是获知相关人员的观点，并验证第1阶段的结果
• 第3阶段：后续阶段
  • 形成最终报告、对后续活动（如果有的话）做出规划
  • 评估小组在此阶段实现文档和经验的更新

软件体系结构分析方法(SAAM)的评估过程(步骤)、优缺点

SAAM (Software Architecture Analysis Method)主要分析体系结构的可修改性；也可以对系统属性及系统功能进行分析

• 评估方法
  • 描述场景、划分优先级、分析体系结构问题
• SAAM评估的输入
  • 一组场景
• SAAM评估的输出
  • 将代表了未来可能做的更改的场景与体系结构对应起来，显示出体系结构中未来可能具有较高复杂性的地方，估计预期工作量
  • 理解系统功能，比较多个体系结构支持的功能数量

步骤

1. 场景的形成
2. 描述软件体系结构
3. 场景的分类和优先级划分
4. 间接场景的单独评估
5. 评估场景交互
6. 形成总体评估

SAAM基于场景的评估需要大量专家知识，主观性强，没有对软件架构提供清晰的度量，适用于粗粒度的评估

ATAM从不同角度探究系统特性，对架构的完整性及风险决策提供支持，探讨质量属性权衡，但未对质量属性深入分析缺乏定量数据