软件构件与体系结构 ¶

软件复用 ¶

软件复用的概念 ¶

软件复用可划分为如下几类：

1. 代码的复用
2. 设计的复用
3. 分析的复用
4. 测试信息的复用

软件复用的实现 ¶

基本问题 ¶

1. 工程方面
   • 缺少能够清晰标识可复用模型要素的手段。
   • 缺少能够复用的构件。
   • 可复用的构件缺乏灵活性。
   • 缺乏执行复用过程的工具。
2. 过程方面
3. 组织方面
4. 资金方面

关键因素 ¶

复用依赖于软件体系结构。使用软件体系结构来规划和管理大规模可复用系统的复杂性是最好的解决方法。

软件复用与构件技术 ¶

• 从外部形态看：
  1. 独立而成熟的构件
  2. 有限制的构件
  3. 适用性构件
  4. 装配的构件
  5. 可修改的构件

构件技术 ¶

软件开发中的问题 ¶

• 技术与需求变化的问题。
• 重复不必要的工作问题。
• 应用集成的问题。
• 软件难以维护的问题。
• 软件质量和成本有效性问题等。

构件技术是目前支持软件复用的核心技术。研究内容包括：

1. 构件获取：有目的的构件生产和从已有系统中挖掘提取构件。
2. 研究模型：研究构件的本质特征和构件间的关系。
3. 构件描述语言：以构件模型为基础，解决构件的精确描述、理解、检素及组装问题。
4. 构件分类与检索：研究构件分类策略、组织模式及检素策略，建立构件库系统，支持构件的有效管理。
5. 构件复合组装：在构件模型的基础上研究构件组装机制，包括源代码级的组装和基于构件对象互操作性的组装。
6. 标准化：构件模型的标准化和构件库系统的标准化等。

软件构件的概念 ¶

1. 构件是预先构建的。
2. 构件是黑盒的。
3. 构件是可分离的。
4. 构件能用于组装和部署。
5. 构件需要称为构件容器技术的支持。

一个完整的构件应包含 6 个要素：

1. 受约束的构件标准：符合某种构件模型。
2. 规格说明：构件提供服务的抽象描述，用作服务的客户方和提供方之间的契约。
3. 实现：必须符合规格说明，各自实现。
4. 包装方法：按不同的方式分组来提供 一套可以替换的服务 ( 包 )。
5. 注册：可在构件支持环境中注册。
6. 部署方法：构件可以部署多个实例。

软件构件的规格说明 ¶

1. 构件的名称与简短描述。
2. 构件服务。
3. 构件接口信息。
4. 所需的接口。
5. 发布和接受的事件。
6. 构件特征。
7. 附加信息。

软件构件接口 ¶

软件构件模型 ¶

构件模型的概念 ¶

使用中间件，也可以使构件之间进行更好地通信。如构件之间直接进行通信，当构成系统的构件数量庞大时，其复杂程度迅速提高；如能引人中介层 ( 中间件 )，则可很好地避免构件间复杂的交互。如下图所示：

青鸟软件构件模型 ¶

青鸟软件构件模型国内许多学者在构件模型的研究方面做了不少的工作，其中较为突出的是北京大学杨芙清院士等人提出的“青鸟软件构件模型 (JBCOM)”。它由外部接又与内部结构两部分组成。如下图所示：

构件的外部接口是指构件向其复用者提供的基本信息，包括 : 构件名称、功能描述、对外功能接口，所需服务的构件和参数化属性等。外部接口是构件与外界的一组交互点，说明了构件所提供的那些服务 ( 消息、操作和变量 )。

构件的内部结构包括两方面的内容 : 内部成员以及内部成员之间的关系。其中，内部成员包括具体成员与虚拟成员，而成员关系包括成员之间的互联，以及内部成员与外部接口之间的互联。

构件模型的描述方法 ¶

构件::=〈构件规约，构件实现〉
构件规约::=〈接又部分，结构部分〉
接口部分::=〈对外提供的功能集合，对外请求的功能集合，服务集合〉
服务::=〈对外提供的功能集合，对外请求的功能集合〉
结构部分::=〈原子构件结构〉|〈复合构件结构〉
原子构件结构::=〈构件实现的引用〉
复合构件结构::=〈引用的构件类型，实例声明，实例连接，映射〉

eg. 编译器复合构件实例。

软件构件的深层理解 ¶

• 构件的粒度
• 构件的基础设施
• 构件的获取
• 构件的管理
• 组装与部署

面向构件 ¶

面向构件的概念 ¶

通过分析、设计和实现，来得到所需的构件

构件的分类 ¶

• 根据软件 3 层框架的构件分类

  • 表示层
  • 业务层
  • 数据层

  据此框架，构件可以被分为 3 类：应用软件、业务构件和数据构件

  业务构件的获取情况

  1. 定义业务对象
  2. 确定控制逻辑（业务过程）
  3. 确定业务对象与控制逻辑之间的交互
  4. 区分公司的业务逻辑和特定部门的业务逻辑
  5. 将业务对象和控制逻辑分配到相应的业务构件中去

  • 基于构件粒度大小的构件分类

    可分为：大粒度的应用构件、用户任务构件、批处理构件和子任务构件

构件的设计与实现 ¶

构件接口定义的原则 ¶

构件接口的定义的基本原则：

1. 定义一些不变的接口
2. 定义自描述的接口
3. 定义元数据性质的接口
4. 构件设计成可定制的

原子构件的制作 ¶

原子构件 Atom 是最小粒度的构件，该构件在功能等方面具有不可再拆分的性质。

• 当一个原子构件的实体对应单个对象时，可以称这个构件是单对象构件，制作流程如下：
  • 定义接口规约。
  • 制作构件实体。
• 当一个原子构件对应多个协作对象时，制作流程如下：
  • 需要引入一个控制对象。
  • 定义构件接口的规约部分。
  • 制作构件实体。

复合构件的制作 ¶

复合构件 Assemble 是由原子构件或者复合构件组装而成的。

制作流程如下：

• 定义构件的接口规约部分
• 确定所包含的成员构件
• 建立内部的成员构件之间的接口连接关系
• 将复合构件对外提供和要求的功能映射到内部成员构件相应的功能上

在建立内部成员之间的连接关系以及复合构件和成员构件的功能映射时，遵循一下规则：

• 成员构件对外要求的功能只能由一个提供者提供
• 成员构件对外提供的功能可以有多个使用者
• 复合构件对外要求的功能可以映射到多个成员构件的功能上
• 复合构件对外提供的功能只能映射到一个成员构件的功能上

构件的管理与维护 ¶

构件库是对构件实施分类和管理的机构。

构件库的组织 ¶

构件库理论研究的重点是构件分类与检索，即研究构件分类策略、组织模式、检索手段和构件相似性分析等。

领域上构件库满足的条件：

• 领域完整性
• 领域抽象性
• 领域标准化

构件库的分类模式 ¶

• 关键字分类法
• 超文本组织法

• 刻面分类法

  由一组描述构件本质特征的刻面组成，每个刻面从不同的角度对构件进行分类。

  从表示的角度来看，刻面是一颗有向树，根节点的值是该刻面的名称，根节点所有子树构成的森林称为术语空间

  特点：

  • 对构件进行了多视角下的分类描述
  • 构件分类描述的术语空间易于修改和维护

基于构件 ¶

构件组装 ¶

构件组装就是确定构件所提供的服务与接口之间的匹配和映射，并提供满足即将或将来部署的约束条件。

构件组装中的问题 ¶

任何基于构件的开发应符合以下构件：

1. 要清晰地分离构件的规格说明和设计实现
2. 重点关注于接口的实现方法
3. 形式地描述构件的语义，主要是对构件行为的描述，其核心是操作特征的语义细节
4. 严格地记录细化过程，并且加以验证

从技术角度看，构件组装过程中需考虑的问题：

1. 每个构件满足其他构件的限制条件问题
2. 构件组装中的接口匹配和映射问题
3. 构件的包装问题

构件组装的方法与技术 ¶

1. 定制
   1. 设置参数值
   2. 完成需要用户定制的代码
   3. 有时候需要重新编译构件
2. 包装
3. 适配

构件组装的内容 ¶

构件组装的实施内容：

1. 强制实现构件的限制条件
2. 处理功能和数据的不匹配
3. 管理构件间的关系

构件之间的关系类型包括拥有关系和外部关系。但从关系的表示角度来看，可分为直接链接和间接链接。

构件部署 ¶

• 提供构件运行时的配置数据
• 提供部署时用到的构件内建配置或定制服务
• 提供构件组装的辅助环境

基于构件的软件配置管理 ¶

软件配置管理 SCM 是指一套按规则管理软件开发、维护，以及其中各种中间软件产品的方法。

• 配置识别
• 变化控制
• 状态记录报告
• 审计

领域工程 ¶

领域工程与应用工程 ¶

• 应用工程：针对一组特有的需求，产生一个特定的解决方案
• 领域工程：针对一个领域中的所有系统，而不局限于某个特定的系统
• 与应用工程相比：领域工程处于一个较高的抽象级别上

领域工程的构成 ¶

• 组成：领域分析、领域设计、领域实现
• 可复用资产：领域分析、领域设计、资产获取、资产分类、资产维护

应用工程的构成 ¶

• 组成：产品空间、构件与体系结构、生产计划、需求、产品、管理

领域工程与应用工程的关系 ¶

领域共性与变化性 ¶

• 变化性的分类
• 变化性绑定
• 变化性控制
• 变化性处理技术

软件体系结构的基本内容 ¶

软件体系结构的概念 ¶

1. 冯 · 诺依曼结构
2. 基于功能模块的软件结构
3. 基于构件的软件体系结构

软件体系结构的定义 ¶

1. Garlan & Shaw 模型： SA = {Components, Connectors, Constrains}
2. Perry & Wolf 模型： SA = {Elements, Form, Rational}
3. CFRP 模型：SA = {Elements, Interfaces, COnnections, Connection Semantics}
4. Vestal 模型： SA = {Component, Idioms/Styles, Common Patterns of Interaction}
5. IEEE 510：Architecture = {Component, Connector, Environment, Principle}
6. Boehm 模型：SA = {Components, COnnections, Constrains, Stakeholders'needs, Rationals}

软件体系结构的构成要素 ¶

1. 构件
2. 连接件
3. 体系结构配置

软件体系结构的研究内容 ¶

软件体系结构描述语言 ADL ¶

体系结构构造 ¶

软件体系结构的分析、设计和验证 ¶

软件体系结构的发现、演化和复用 ¶

基于体系结构的软件开发过程 ¶

特定领域的体系结构 DSSA ¶

软件体系结构支持工具 ¶

软件体系结构模式与模式系统 ¶

模式的概念与分类 ¶

模式的定义 ¶

每个模式描述了一个在我们周围不断重复发生的问题，以及该问题解决方案的核心内容。这样，你可以一次又一次地使用该方案而不必做重复劳动。

解决策略：将模型、视图、控制器划分开。就是一个典型的模型 模型 - 视图 - 控制器模式（MVC）

模式的构成要素 ¶

• 语境：问题出现的背景
• 问题：在语境中重复出现的问题
• 解决方案：给出如何解决再现的问题，或者说如何平衡与之相关的强制条件
• 实现：就是将以上的解决方案付诸实践

模式的优势 ¶

• 设计复用
• 代码复用
• 系统组成更易于被他人理解
• 有利于系统的互操作性
• 有利于软件体系结构的分析
• 有利于特定模式软件体系结构的可视化

模式分类 ¶

• 底层模式：惯用法
• 中层模式：设计模式
• 高层模式：体系结构模式

惯用法 ¶

• 惯用法针对设计和实现方面，是针对具体特定程序设计语言的低层模式，它描述如何用给定的语言特征来实现构件的特定方面或构件之间的关系。
• 特点
  • 惯用法是与具体语言密切相关的编程经验的 , 总结。
  • 惯用法描述如何使用给定的语言特征来实现构件的特定方面及其关系。
  • 惯用法代表最底层的模式。
  • 惯用法更关注设计的实现。
  • 惯用法可能是一种特定设计模式的具体实现。
• 益处
  • 一组相关的惯用法会使程序形成一致的风格。
  • 一致的程序设计风格将加速程序设计的进程。
  • 一致的程序设计风格使程序更容易理解，有利于程序的开发和维护。 ·

设计模式 ¶

• 中等规模的模式，在规模上比体系结构模式要小，但在级别上比特定的编程语言的惯用法要高

设计模式问题类别 ¶

• 结构化分解：最普遍的模式是整体 - 部分模式
• 工作的组织：主控 - 从属模式
• 访问控制：代理设计模式、外观模式和迭代器模式
• 管理：命令处理器模式、视图处理程序模式
• 通信：转发器 - 接收器模式、客户机 - 分配器 - 服务器模式、出版者 - 订阅者模式

设计模式分类 ¶

体系结构模式 ¶

体系结构模式的定义 ¶

• 一个软件体系结构的模式描述了一个程序在特定设计语境中的特殊的再现设计问题，并为它的解决方案提供了一个经过充分验证的通用图式。解决方案图式通过描述其组成构件、它们的责任和相互关系，以及它们的协作方式来具体指定。
• 软件体系结构模式是模式系统中的最高等级模式

体系结构模式的分类 ¶

• 从混沌到结构
  • 分层模式
  • 管道 / 过滤器模式
  • 黑板模式
• 分布式系统
  • 代理模式
• 交互式系统
  • 模型 - 视图 - 控制器模式（MVC）
  • 表示 - 抽象 - 控制模式（PAC）
• 适应性模式
  • 反射模式
  • 微核模式

常用体系结构模式 ¶

1. 管道 / 过滤器
2. 基于事件的隐式调用
3. 分层风格
4. 数据抽象和面向对象
5. 仓库与黑板模式
6. 解释器
7. 代理模式
8. 微核
9. 客户 / 服务器
10. 正交软件体系结构
11. C2
12. 异构结构
13. 反射
14. 模型 - 视图 - 控制器（MVC）
15. 表示 - 抽象 - 控制（PAC）

模式系统与体系结构风格 ¶

若干定义 ¶

• 模式系统：将一个个单独的模式捆绑在一起，描述了模式之间的关系、模式的实现，以及模式怎样相互联系相互补充来有效支持软件开发的。
• 模式语言：由结构和规则构成。结构描述了模式是更小模式的模式 ; 规则描述了创建模式的方式和与其他模式的排列方式。
• SA 模式系统：是软件体系结构模式的汇集，包括模式在软件开发中的实现、组合和使用指南。
• 模式系统的演化：包括模式描述的演化、模式的采掘、新模式的集成和删除过时的模式等。

模式系统对软件开发的支持条件 ¶

• 包含足够多的基本模式
• 所有的模式应该有统一的描述形式
• 具有对模式如何组织的模式
• 支持软件构造的方法
• 支持模式系统的自我烟花

模式系统的全局分类视图 ¶

面向问题的模式选择步骤 ¶

1. 指定和精确地描述问题
2. 针对问题的规模，选择“模式类别”（不是按问题类别选取）
3. 对问题进行分类，初步选取解决问题的模式和可选模式
4. 对问题的分类和相应的解决模式进行比较（优缺点）
5. 进一步选取更合适的解决方案的变体
6. 如果发现问题难以解决，则重新进行问题分类，转至 3

软件体系结构模式与软件体系结构风格的比较 ¶

• 体系结构风格主要描述应用系统的 , 总体结构框架。体系结构模式可存在于各种应用系统规模和抽象层次上，从定义应用系统的总体结构到描述怎样用给定的编程语言实现特定问题的惯用法模式。
• 体系结构风格相对独立。各应用系统采用不同的风格后，与由其他风格构成的系统联系较少。而模式往往依赖于它所包含的较小的模式或者与它相互作用的模式。
• 模式比体系结构风格更加面向问题。体系结构风格侧重于从应用系统中抽取出它们的总体组织结构，而较少从实际设计环境水考感设计的技术。而体系结构模式通常由问题出现的语境、解决方案和适用场景组成。