软件设计与体系结构复习

软件设计与体系结构复习

第一章：软件工程与软件设计

1.1软件工程

1.1.1 软件概述
  1. 计算机软件是与计算机系统操作有关的程序、规程、规则及任何与之有关的文档及数据，计算机软件=程序+数据+文档
  2. 软件由两部分组成：一是机器可执行的程序及有关数据；二是机器不可执行的，与软件开发、运行、维护、使用、培训有关的文档。
  3. 软件是逻辑产品而不是物理产品
  4. 软件分为：系统软件、实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件、个人计算机软件
1.1.2 软件危机

产生软件危机的原因：

  1. 用户对软件需求的描述不精确，可能存在遗漏、二义性、错误等。在软件开发过程中，用户甚至还提出修改软件功能、界面、支撑环境等方面的要求，导致需求不断变更。
  2. 软件开发人员对用户需求的理解与用户的期望有所差异，这种差异必然导致开发出来的软件产品与用户要求不一致。
  3. 大型软件项目需要组织一定的人力共同完成，但多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面额经验。各类人员的信息交流不及时、不准确，有时还会产生误解。
  4. 软件项目开发人员不能有效、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。
  5. 缺乏有力的方法学和工具方面的支持，过分依靠程序设计人员在软件开发过程中的技巧和创造性，加剧了软件产品的个性化。
  6. 软件产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。一旦人们采用先进的组织形式、开发方法和工具提高了软件的开发效率和能力，新的、更大且复杂的问题又出现在人们面前。
1.1.3 软件工程的概念
  1. 软件工程的定义包括：
    1. 软件工程是将系统的、规范的、可度量的方法应用于软件的开发、运行和维护过程，以及对上述方法的研究
    2. 软件工程是用工程、科学和数学的原则和方法，研制、维护计算机软件的有关技术及管理方法
  2. 一般认为，软件工程由方法、工具和过程三个要素组成。
1.1.4 软件工程的目标与原则
  1. 软件工程的目标是：在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可复用性、可适应性、可移植性和可追踪性，并满足用户需求的软件产品。
    1. 可修改性：可修改性是指允许对系统进行修改而不增加原系统的复杂性。
    2. 有效性：有效性是指软件系统能最有效的利用计算机的时间资源和空间资源，一般将系统的时空开销作为衡量软件质量的一项重要技术指标。
    3. 可靠性：可靠性是指软件在给定环境和时间下不发生故障的概率。
    4. 可理解性： 可理解性是指系统具有清晰的结构，能直接反应问题的需求。
    5. 可维护性： 可维护性是指软件产品交付用户使用后能够方便地对它进行修改，已改正潜在的错误以及改进性能和其他属性，是软件产品适应环境的变化等。
    6. 可复用性：概念或功能相对独立的一个或一组相关模块定义为一个软部件，软部件可在多种场合应用的程度成为部件的可复用性。
    7. 可适应性：可适应性是指软件在不同的系统约束条件下，使用户需求得到满足的难易程度。
    8. 可移植性：可移植性是指软件冲一个计算机系统或环境移植到另一个计算机系统或环境的难易程度。
    9. 可追踪性： 可追踪性是指根据软件需求对软件设、程序进行正向追踪，或根据程序、软件设计对软件需求进行一行追踪的能力。
  2. 软件工程原则：抽象、信息隐藏、模块化、局部化、一致性、完全性、可验证性
    1. 抽象：抽象指抽取事务最基本的特性和行为，忽略非基本的细节。
    2. 信息隐藏：信息隐藏是将模块中的软件设计决策封装起来的技术。
    3. 模块化：模块是程序中逻辑上相对独立的成分，它是一个独立的变成单位，应有良好的接口定义。模块化有助于信息隐藏和抽象，有助于表示复杂的软件系统。
    4. 局部化：局部化要求在一个物理模块内集中逻辑上相互关联的计算资源，从物理和逻辑两个方面保证系统模块之间具有松散的耦合关系，而在模块内部有较强的内聚性，这样有助于控制设计的复杂性。
    5. 一致性：一致性指整个软件系统(包括文档和程序)的各个模块均应嚼规格说明与系统
      和术语;程序内部接口应保持一致;软件与硬件接口应保持一致；系统机
      行为应保持一致;用于形式化规格说明的公理系统应保持一致等。
    6. 完全性: 完全性指软件系统不丢失任何重要成分，达到完全实现系统所需功能的程度；当系统处于出错或非预期状态时，系统行为保持正常的能力。
    7. 可验证性:开发大型软件系统需要对系统逐步分解，系统分解应该遵僦案容易检查、测试评审的原则，以便保证系统的正确性。

1.2软件的生存周期

软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程称为软件生存周期

  1. 可行性研究
  2. 需求分析：
    1. 需求分析的任务是确定待开发软件的功能需求、性能需求和运行环境约束，编制软件需求规格说明、软件系统的确认测试准则和用户手册概要
    2. 软件的功能需求应指明软件必须完成的功能；软件的性能需求包括软件的安全性、可靠性、可维护性、精度、错误处理、适应性、用户培训等
    3. 软件系统在运行环境方面的约束指待开发的软件系统必须满足的运行环境方面的需求。
    4. 软件需求不仅是软件开发的依据，也是软件验收的标准。
  3. 概要设计
  4. 详细设计
  5. 软件构造
  6. 单元测试
  7. 集成测试
  8. 确认测试
  9. 使用与维护
  10. 退役

1.3软件开发过程模型

1.3.1 瀑布模型

  1. 什么是瀑布模型

    它根据软件生存周期各阶段的任务从可行性研究开始，逐步进行阶段性变换，直至通过确认测试并得到用户确认的软件产品为止

  2. 优点

    1. 瀑布模型在软件工程出现的早期占有重要的地位，它提供了软件开发的基本框架。
    2. 有利于大型软件开发过程中人员的组织、管理
    3. 有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率

  3. 缺点

    1. 瀑布模型在需求分析阶段要求用户和系统分析员必须指明软件系统的全部需求才能开展后续阶段的工作，因此难以适应大规模、复杂软件系统的开发
    2. 需求确定后，用户和软件项目负责人要等相当长的时间才能得到一份软件的最初版本。如果用户对这个软件提出比较大的修改意见，那么整个软件项目将会蒙受巨大的人力、财力和时间方面的损失。
1.3.2快速原型模型

快速开发原型的途径有三种

  1. 利用个人计算机模拟软件系统的人机界面和人机交互方式
  2. 开发一个工作原型实现软件系统的部分功能，而这部分功能是重要的，也可能是容易产生误解的
  3. 找来一个或几个正在运行的类似软件，利用这些软件想用户展示软件需求中的部分或全部功能
1.3.3 螺旋模型
  1. 由四部分组成： 需求定义、风险分析、工程实现和评审
  2. 适用场合：

1.4 软件设计

1.4.1 软件设计的重要性
  1. 软件设计是对软件需求的直接体现
  2. 软件设计为软件实现提供直接依据
  3. 软件设计将综合考虑软件系统的各种约束条件并给出相应方案
  4. 软件设计的质量将决定最终软件系统的质量
  5. 及早发现软件设计中存在的错误将极大减少软件修复和维护所需的成本。
1.4.3 软件设计的要素
  1. 目标描述
  2. 设计约束
  3. 产品描述
  4. 设计软则
  5. 开发规划
  6. 使用描述

1.5 软件体系结构

1.5.1软件体系结构的定义
  1. 软件体系结构是软件系统的结构，包括软件元素、软件元素外部可见的属性以及这些软件元素之间的关系
  2. 软件体系结构是软件系统的基本组织，包含构件、构件之间、构建与环境之间的关系，以及相关的设计与演化原则

第二章 统一建模语言UML

2.1UML概述

2.1.2 UML 的特点和用途

UML 在表达能力、对新技术的包容能力和拓展性等方面有显著优势

  1. 为使用者提供了统一的、表达能力强大的可视化建模语言，以描述应用问题的需求模型、设计模型和实现模型
  2. 提供对核心概念的拓展机制，用户可加入核心概念中没有的概念和符号，可为特定应用领域提出具体的概念、符号表示和约束
  3. 独立于实现语言和方法学，但支持所有的方法学，覆盖率面向对象分析和设计的相关概念和方法学
  4. 独立于任何开发过程，但支持软件开发全过程
  5. 提供对建模语言进行理解的形式化基础，用元模型描述基本语义，OCL描述良定义规则，自然语言描述动态语义
  6. 增强面对对象工具之间互操作性，便于不同系统间的集成
  7. 支持较高抽象层次开发所需的各种概念，便于系统的重用
2.1.3 UML2.0的建模机制
  1. 结构建模：
    1. 类图： 描述系统的静态逻辑结构，即构成系统的抽象元素以及元素间的关系
    2. 包图：是一种特殊类型的类图，描述类和接口如何进行逻辑上的划分，常用来描述软件系统的体系结构
    3. 对象图： 可以看作类图的一个实例
    4. 构件图： 描述了系统实现中的结构和依赖关系，可以用来表示软件开发、编译、链接、部署或执行时构件之间的关系
    5. 组合结构图： 用于描述较为复杂的系统元素以及元素间的关系
    6. 部署图： 描述系统硬件的物理拓扑结构以及在此结构上运行的构件
  2. 行为建模：
    1. 活动图： 描述行为或活动的流程，与传统的流图类似，但表达能力更强
    2. 顺序图：描述对象在其生存周期内的交互活动
    3. 通信图： 描述特定行为中参与交互的对象及其连接关系
    4. 交互概览图： 活动图的简化版本，强调执行活动所涉及的元素
    5. 时序图： 强调小的详细时需说明，常用来对实时系统进行建模
    6. 状态图： 刻画一个元素内部的状态迁移，也常用来对嵌入式系统、协议规范及实现进行建模
    7. 用例图： 通过用力来描述系统的功能性需求，从用户的角度以一种与实现无关的方式刻画系统将能作什么，还能描述用力之间的关系。

2.2 面向对象开发方法

2.2.1 基本概念

面向对象方法学包含以下核心概念

  1. 对象：对象是现实世界中个体或事物的抽象表示，是其属性和相关操作的封装
  2. 类： 类 是某些对象的共同特征的表示
  3. 继承： 类之间的继承关系是现实世界中遗传关系的直接模拟，它表示类之间的内在联系以及对属性和操作的共享
  4. 聚集： 在剧集关系下，部分类的对象是整体类对象的一个组成部分
  5. 多态： 多态指在弗雷继器子类中，对外结构的定义形式相同，却可以对应多种结构的实现形态
  6. 消息： 消息传递是对象及其外部世界相互关联的唯一途径
2.2.2 面向对象方法的优势
  1. 简化软件开发过程
  2. 支持软件复用
  3. 改善软件结构

2.3UMl2.0结构建模

结构建模常常也被称为静态建模，主要用来描述系统中包含的元素以及元素之间的关系

2.3.1类图

  1. 类

    类用来描述具有相同特征、约束和语义的一类对象，这些对象具有共同的属性和操作

  2. 抽象类

    抽象类指一个类只提供操作名，而不对其进行实现

  3. 接口

    接口用来声明一些属性或方法，但并不实现他们。接口能够用来规定一种契约，对接口进行实现的元素必须遵循该契约

  4. 依赖关系

    两个类之间存在依赖关系，表明一个类使用或需要知道另一个类中包含的信息

  5. 关联关系

    两个类之间存在关联关系，表明这两个类的实例之间存在语义上的联系

  6. 聚集关系

    聚集关系表明两个类的实例之间存在一种拥有或属于关系，可以看作一种较弱的整体-部分关系，或是一种逻辑上的隶属关系。

  7. 构成关系

    构成关系表明两个类的实例之间存在一种包含关系，是一种比聚集关系更强的整体-部分关系

  8. 泛化（继承）关系

    泛化关系就是指两个类之间存在继承关系，即一个是父类，一个是子类

  9. 实现关系

    实现关系表示一个元素是另一个元素的实现

  10. 关联类

    关联类用来记录与关联有关的信息，提供与关联有关的操作

2.3.2包图

包用来对一组元素进行划分，是对复杂模型的一种分而治之的层次划分，因此也常常用来描述一个复杂系统逻辑上的子系统划分。包图主要是由宝玉包之间的关系组成

  1. 包
  2. 依赖关系
  3. 导入关系
  4. 合并关系
2.3.3对象图

对象是类的实例，对象图可以看作类图的实例，对象之间的连接是类之间关联关系的实例。

2.3.4 构件图

  1. 构件

    构件是系统中一个具有良好封装、可替换的模块，一个简单构建由带有《component》构造型的方框表示

  2. 接口

  3. 装配连接子

2.3.6部署图

部署图用来描述软件开发过程中生成的物理文件形式的软件或信息，运行平台的物理节点和通信，以及软件文件到相应硬件节点的部署或映射。

部署图很重要的一点就是描述制品怎样在节点上部署，以及节点如何连接起来形成一个完整的系统

第三章 软件设计基础

3.1 软件设计的基本概念

3.1.1 抽象与逐步求精

抽象是管理、控制复杂性的基本策略

逐步求精是一个与抽象密切相关的概念，可视为一种早期的自顶向下设计策略，主要思想是，针对某个功能的宏观描述用逐步求精的方法不断分解，逐步确定过程细节，直至该功能用程序语言描述的算法实现为止。

3.1.2 模块化与信息隐藏
  1. 模块化： 把软件划分为可独立命名和访问的部件，每个部件成为一个模块，当把所有模块组装到一起时则获得了满足问题需要的一个解。
  2. 信息隐藏： 采用信息隐藏原理指导模块设计的好处十分明显：不仅支持模块的并行开发，而且还可以减少测试和后期维护的工作量
3.1.3内聚和耦合

  1. 内聚

    内聚是信息隐藏和局部化概念的自然扩展，他标志一个模块内部各成分彼此结合的紧密程度。

    1. 低等级内聚
      1. 偶然性内聚
      2. 逻辑内聚
      3. 时序内聚
    2. 中等级内聚
      1. 过程内聚
      2. 通信性内聚
    3. 高等级内聚
      1. 顺序性内聚
      2. 功能性内聚

  2. 耦合

    耦合是对软件结构中模块间关联程度的一种度量。耦合的强弱取决于模块间接口的复杂性、进入或调用模块的位置以及通过接口传送数据的多少等。

    1. 如果两模块中任意个都不依赖对方而能够独立工作，称这两模块为非直接耦合，这类耦合的耦合度最低
    2. 如果两模块之间通过参数交换信息，而信息仅限于数据，则称这两模块为数据耦合
      1. 特征耦合
      2. 外部耦合
      3. 公共耦合
    3. 最该耦合度为内容耦合： 出现内容耦合的情形包括
      1. 一个模块使用另一个模块内部的数据或控制信息
      2. 一个模块直接转移到另一个模块内部等

3.2软件设计过程

3.2.1软件设计的一般过程

软件设计可分为概要设计和详细设计。

  1. 概要设计是根据需求确定软件和数据的总体框架
  2. 详细设计是将其进一步精化称软件的算法表示和数据结构
  3. 在技术上，概要设计和详细设计又由若干活动组成，主要包括软件体系结构设计、界面设计、模块、子系统设计、数据模型设计、过程、算法设计
3.2.2 软件设计的主要活动

  1. 软件设计计划

    软件设计计划的任务是，明确设计过程的输入制品并使其处于就绪状态，定义设计过程的目标，输出制品及其验收准则，确定覆盖设计过程中各个阶段的全局性设计策略，分配设计过程相关人员的职责，针对设计过程中的活动制定工作计划。

  2. 体系结构设计

    对软件结果进行评价时，常用的几个概念

    1. 一个软件的”深度“和”宽度“分别说明其控制的层数和跨度
    2. 一个模块的”扇出率“指该模块直接控制的其他模块数，一个模块的”扇入率“指能够直接控制该模块的模块数

3.4 软件体系结构设计

3.4.1 软件体系结构设计方法概述

  1. 软件体系结构的多视图建模（4+1建模）

    1. 逻辑视图

      该视图关注功能需求，即系统应该为最终用户提供什么服务，它与应用领域紧密相关。

    2. 进程视图

      该视图捕获设计中关于并发和同步的内容，重现一些非功能需求

    3. 开发视图

      该视图主要描述软件在开发环境中的静态结构，开发人员和项目经理对此都会感兴趣

    4. 物理视图

      该视图描述软件到硬件的映射关系，反映了软件的分布特征

    5. 场景

      可以使用一组重要场景，也就是用力的实例，将四种视图紧密联系起来。场景通常是最重要的需求，一方面作为设计中发现体系结构元素的驱动器，另一方面在设计完成后，充当确认和验证的依据

3.4.2软件体系结构设计的步骤

  1. 软件体系结构设计过程中的数据为软件需求规格说明和软件设计计划，最终输出为软件体系结构设计文档
3.5.7 嵌入式和实时软件设计
  1. 嵌入设软件具有以下主要特征
    1. 嵌入设软件一般用于单一任务
    2. 嵌入式软件有多种类型的处理器体系结构支撑
    3. 嵌入式软件的资源约束更加严格
    4. 嵌入式软件的需要更高的可靠性和安全性
    5. 嵌入式软件对反应性和实施性要求很高
    6. 嵌入式软件通常固化存储

第四章面向对象的软件设计方法

4.1 基于UML的分析与设计过程

  1. 顶层架构设计：

    顶层架构设计的主要目的是为后续的分析和设计活动建立一种结构和划分，一边开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。

4.2 用例分析与设计

4.2.2 生成用例图

参与者与用例之间的关系有两种：触发执行与信息交换

4.3 概念模型与顶层架构设计

4.3.1 概念模型设计
  1. 关键概念的来源包括
    1. 业务需求描述、用例说明
    2. 业务领域中的相关规范、标准、术语定义
    3. 反映业务领域只是的既往经验
  2. 描述概念模型的UMl类图主要由分析类组成。分析类是指直接服务于用户功能性需求的概念层面的类，他们与待开发软件系统的具体实现技术无关。三种分析类
    1. 边界类：负责目标软件系统与参与者之间的交互
    2. 控制类： 作为完成用例任务的责任承担者，负责协调、控制其他类共同完成用例规定的功能或行为
    3. 实体类：是体力负责保存目标软件系统中具有持久意义的信息项并向其他类提供读、写信息项内容的必要操作接口，一般不涉及业务逻辑处理

4.5数据模型设计

  1. 持久数据模型设计主要包括以下几个步骤
    1. 确定设计模型中需要持久保存的类的对象及其属性，其中实体类是主要关注对象
    2. 确定持久存储的数据之间的组织方式
    3. 确定数据模型中的操作行为
    4. 进一步优化持久数据操作的性能

4.8 部署模型设计

  1. 部署图对于复杂的分布式软件系统尤其有用，因为最终软件可能分为不同的子系统和制品形式，并部署在不同的物理节点中。此外，部署图还可以用来描述对整个系统结构的一些特殊需求。

  2. 部署模型设计一般需要考虑以下几点

    1. 最终开发完成的软件包括哪些制品形式
    2. 软件运行环境存在哪些类型的物理节点
    3. 不同节点之间的连接和通信形式是什么
    4. 软件制品应该如何在物理节点上进行部署，即它们的部署映射关系

第五章 面向数据流的软件设计方案

5.1 数据流图与数据字典

数据流图就是用来刻画数据流和转换的信息系统建模技术

5.2实体关系图

  1. 数据对象、属性与关系
    1. 命名性属性： 对数据对象的实例命名，其中必含有一个或一组关键数据，以便唯一的标识数据对象的实例
    2. 描述性属性： 对数据对象实例的性质进行描述
    3. 引用性属性： 将自身与其他数据对象的实例关联起来
  2. 规范化规则
    1. 数据对象的任何实例对每个属性必须有且仅有一个属性值
    2. 属性是原子数据项，不能包含内部数据结构
    3. 如果数据对象的关键属性多于一个，那么其他的非关键属性必须表示整个数据对象而不是部分关键属性的特征
    4. 所有的非关键属性必须表示整个对象而不是部分属性的特征。

5.4 面向数据流的设计过程

5.4.1变换流与事务流
  1. 面向数据流的方法能方便的将数据流图转换为软件结构，其过程分为5步
    1. 确定信息流的类型
    2. 划定流界
    3. 将数据流图映射为程序结构
    4. 提取层次控制结构
    5. 通过设计复审和使用启发式策略进一步精化所得到的结构
  2. 信息流一般可以分为变换流和事务流两种类型
    1. 变换流： 在基本系统模型中信息通常以”外部世界“所具有的形式进入系统，经过处理后又以这种形式离开系统
    2. 事务流： 由于基本系统模型呈变换流，故任意系统中的信息均可用变换流描述。

5.5 启发式设计策略

启发式设计策略式人们从长期的大量软件开发过程中集类总结的经验

  1. 改造程序结构、减小耦合度，提高内聚度
  2. 改造程序结构，减少高扇出，在增加程序深度的前提下追求高扇入
  3. 改造程序结构，使任一模块作用域在其控制域之内
  4. 改造程序结构，减少接口的复杂性和冗余程度，提高协调性
  5. 模块功能应该可语言，避免对模块施加过多限制
  6. 改造程序结构，追求单入口单出口的模块
  7. 为满足设计或可移植性的要求，把某些软件用包的形式封装起来

第六章 用户界面设计

6.1 界面设计的基本原则

  1. 设计人员要考虑的重要因素
    1. 人只有有限的短暂记忆能力，通常人只能够瞬时记忆七条左右信息
    2. 人都会犯错，热别实在必须处理大量信息或承受压力的情况下，
    3. 人们都有不同程度的生理特征
    4. 人都有不同程度的交互和喜好
  2. 设计原则
    1. 用户熟悉程度：界面应该采用经常使用系统的用户所熟悉的术语和概念
    2. 一致性： 界面必须一致，在任何可能的情况下，相同的操作应以同样的方式被激活
    3. 使惊讶最小化：尽量避免是用户对系统的行为感到惊讶
    4. 可恢复性：界面应该为用户提供错误恢复机制
    5. 用户帮助：界面应该错误发生时提供有意义的反馈，并且提供上下文敏感的用户帮助系统
    6. 用户多样性：界面应该为不同类型的用户提供恰当的交互方式

6.2 设计良好界面的主要途径

  • 使系统处于用户控制之中
  • 减少用户的记忆负担
  • 保持界面的一致性
6.5.2界面设计需要考虑的问题

系统响应时间、用户帮助、错误信息处理、命令标记、友好性、国际化

6.6 用户界面原型

两个阶段

  1. 早期必须构建出纸上的原型，包括屏幕设计的实体模型，然后和用户进行商讨
  2. 之后可以开始对设计进行精化，并且开发逐渐复苏的界面原型，然后把它们提供给用户来进行测试和动作模拟

第七章 软件体系结构风格与设计模式

7.1 基本概念

  1. 软件设计模式：在类和对象的层次描述的可重复使用的软件设计问题解决方案
  2. 软件体系结构风格： 是软件体系结构设计上的模式，可以看作一种广义的软件设计模式，但一般不认为是狭义的软件设计模式。
  3. 两者的区别：
    1. 软件体系结构风格描述系统整体结构框架上的特点，粒度更大
    2. 软件设计模式则更加面向具体问题，指出的是一个在更小的粒度上的设计特点

7.3软件体系结构风格

  1. 3种常用的体系结构
    1. 管道/过滤器风格
    2. 层次风格
    3. 客户/服务器风格
  2. 如何刨析
    1. 核心特征
    2. 应用场合
    3. 注意问题

7.4 设计模式

具有代表性的7个设计模式

  1. 创造型设计模式
    1. Factory Method
    2. Abstract Factory
    3. Singleton
  2. 结构型设计模式
    1. Composite
    2. Proxy
  3. 行为型设计模式
    1. Iterator
    2. Observer

对于每个设计模式，从模式的动机和实例、适用场合、结构以及核心思想四个方面进行介绍

第八章 基于分布构件的体系结构

8.1 EJB分布构件框架

8.1.1 EJB简介

  1. EJB分布构件框架由SUN公司主导指定，基于Java语言，面向企业界的分布式系统开发。

  2. 3种分布构件

    1. 绘画Bean(Session Bean)
    2. 消息驱动Bean（Message-Driven Bean）
    3. 实体Bean（Entity Bean）

  3. EJB构件容器提供了EJB构件生存的环境，控制了EJB构件的生存周期，并提供了许多企业级应用所需的中间件服务，如事务服务、持久化服务和安全服务等

  4. EJB3.0标准规定了EJB构件容器和EJB构件之间的契约关系，对EJB构件容器和EJB构件的开发都做了约束。因此，原则上符合EJB标准的EJB构件就能够在所有符合EJB标准的应用服务器上运行

8.2.DCOM分布构件框架

DCOM 分布构件对象模型是一个二进制代码层面的构建模型。

  1. DCOM客户

    泛指所有与DCOM构件交互的程序片段

小结

构件框架使用的难易程度

  1. EJB最简单
  2. CORBA次之
  3. DCOM难

第九章 软件体系结构评估

软件体系结构是一个软件系统的基础，他影响到系统的很多质量属性,如可变性、性能、安全性、可用性、可靠性等

9.1 软件体系结构评估概述

软件体系结构是早期设计阶段的产物，它对系统和项目的影响比较深远。如果软件体系结构不合适，将可能导致软件项目的灾难，系统的性能目标也得不到满足。此外，客户将由于正当功能的不可用而变得不爱饭，但如果要修改系统来添加或修复这项功能也会很困难

9.1.1 评估时机和参与人员

  1. 早评估

    早评估对已做出和正在考虑的软件体系结构决策都使用。它不需要完整的软件体系结构描述，可以在软件体系结构创建过程中的任何阶段使用评估方法，对已做出的软件体系结构决策进行检查，或者确定还没有决定的软件体系结构选项。

  2. 迟评估

    迟评估的时间是软件体系结构已明确并且实现已完成的时候，这种情况在某个组织继承某些遗留系统时发生，这些遗留系统可能是在市场中购买的，也可能是从本组织现有的存档中发掘的。

9.2 软件体系结构评估方法

  1. 软件体系结构这种分析方法（Architecture Tradeoff Analysis Method, ATAM）
  2. 软件体系结构分析方法（Software Architecture Analysis Method, SAAM）
  3. 中间设计的积极评审（Active Reviews for Intermediate Designs,ARID）
9.2.1 ATAM方法
  1. ATAM方法能够反映出一个软件体系结构满足某些特定质量目标的程度，同时还能给出这些质量目标之间的交互方式，即它们之间的这种方案。在遗留系统需要进行大的改动、与其他系统继承或者重大升级时，也可以用ATAM方法对一六系统进行分析
  2. 主要步骤
    1. 介绍ATAM方法
    2. 商业动机的介绍
    3. 软件体系结构介绍
    4. 确定软件体系结构方案
    5. 产生质量属性效果树
    6. 分析软件体系结构方案
    7. 集中讨论并确定场景的优先级
    8. 进一步分析软件体系结构方案
    9. 展示结果
9.2.2 SAAM方法
  1. SAAM方法基于以下观察： 实践人员会定期对他们的软件体系结构有所声明，如这个系统比之前的版本更加健壮、使用CORBA将会是系统更易于修改和升级、MVC模式能够保证整个软件体系结构的可维护性等等
  2. 主要步骤：
    1. 场景的形成
    2. 描述软件体系结构
    3. 场景的分类和优先级划分
    4. 间接场景的单独评论
    5. 评估场景交互
    6. 形成总体评价

第十章 软件设计的进化

10.2.1 进化策略的分类

  1. 完全放弃该软件

    当遗留软件对于用胡德业务过程起不到任何贡献时，可采用

  2. 不改变该软件系统并继续进行常规的维护

    当软件系统依然是需要的，并且运行相当稳定，系统使用者只有相对较少的变更需要时，可采用

  3. 对软件系统实时再工程以提高可维护性

    当系统由于经常的变更而质量下降，并且依然需要对系统进行经常变更时，可采用

  4. 用新系统替换遗留软件系统的全部或其中一部分

    当某些其他因素出现时，例如使用信息硬件是的已有软件系统无法继续运行，或存在第三方软件系统使得可以在合理成本的基础上开发新系统时，可采用

10.3软件再工程

优点

  1. 减少风险： 对关键软件完全进行重新开发具有很高的风险

  2. 减少成本： 根据以往的实践经验和统计，再工程的成本要明显比开发一个全新的软件低。

posted @ 2021-05-15 17:03  CNPolaris  阅读(2541)  评论(1)  编辑  收藏  举报