软件复用课件

软件复用

•人们开始认识到，要真正实现软件的工业化生

产方式，保证软件生产的高效率和高质量，软

件复用是一条现实可行的途径

•软件复用的概念是在1968年NATO软件工程会

议上由McIlroy第一次提出的

•所谓软件复用是指在开发新的应用系统时使用

以前开发的软件资源，如设计、代码、文档等,

从而提高系统开发效率及软件质量

•在较长的一段时间内，软件复用仅限于程序代

码段的复用，这仅是一种较低层次的复用

•人们开始认识到，软件开发并不仅仅是编程，

而是一个从系统需求获取、分析、设计到实现、

测试、运行、维护的过程。理论和实践表明，

在软件生存期中，需求、设计阶段是开发过程

的关键和瓶颈。软律复用的概念也随之扩展到

对软件开发过程中各阶段产品和文档的复用，

其中更为重要的是对需求规约和设计的复用。

•面向对象技术为软件复用提供了更强有力的支

持，带来了更多的复用机会

面向对象技术对软件复用的支持优势

•面向对象技术对软件复用的支持优势在

于：

-OO模型比传统过程型模型更为稳定；

-00分析更适合于领域工程；

-OO构件具有更好的封装性；

-00方法学支持无缝的工程，可实现分析、

设计、编码的一致复用。

日常生活中的复用概念

•在人们的日常生活中，复用概念的存在随处可

见。

•传统工业如机械、建筑等行业中，标准规格的

零部件、设计模式等无不体现了复用的思想。

计算机产业虽然是年轻的产业，其成功同样是

由于实现了将标准的集成电路芯片、插件板、

主板、外设等直接组装的工业化生产方式。可

以说，符合标准的构件、基于标准构件的产品

生产（组装）是产业工程化、工业化的必由之

路，而其中构件是核心和基础，复用是必需的

手段。这种成功的模式是软件产业发展的良好

借鉴，有柞多看益的启示

软件构件技术

•软件构件技术已成为研究的热点，其研究内容

包括构件标准和模型、构件的生产和获取、构

件的规约和描述、构件的分类和组织、构件的

检索和组装、基于构件的价格分析，以及软件

体系结构、软件复用支持工具和管理手段、基

于复用的软件开发过程等方面。

•研究工作有很大进展和众多成果，而且还出现

了一些产W构件标准，如Microsoft的OLE-

COM、OMG的CORBA/OM等。这标志着软件

复用已进入蓬勃发展的时期

产品复用

•软件复用通常可分为两类：产品复用和过程复

用

•产品复用指对软件开发过程中生成的各种产品

（需求规约、设计、程序、测试计划和数据等）

构件的复用，这涉及可复用构件的建造（从现

有系统中获取及有目的的生产）及可复用构件

的使用（对知识性资源的参考和对程序代码级

资源的复合组装）两个方面，通过专业性的构

件开发和基于构件复用的系统集成实现软件的

工业化生产。

过程复用

•过程复用指通过采用自动化技术，复用关于软

件系统生成或变换的，从而使得可以从需

求描述出发，通过生成或变换，自动生成最终

所需的系统，应用生成器、程序变换器和可执

行规约语言均是过程复用的例子。

•完全通用的过程复用意味着软件生产的自动化,

这在目前还是不现实的想法，因此过程复用难

度大、投资大、不易实施。

•当前过程复用的实践大多和领域相关，如特定

领域的应用生成器。过程复用是非常理想的软

件复用方式，但在目前技术发展水平下，仍是

难以企及的目标，产品复用成为主要的研究课

题。

产品复用分类

•产品复用可分为直接复用和间接复用两类

•直接复用是指对那些可表示为某种程序设计语

言代码的构件的复用，这类构件的复用及其通

过一定机制的复合（组装）可直接产生可执行

的应用程序，这是我们开发软件的最终目标。

•间接复用是指对需求规约、功能规约、设计思

想、测试计划等文档型知识的复用，这类非代

码构件的复用虽然不能直接得到最终可运行的

系统，但可以对系统开发的效率和质量带来极

大的好处，这类构件的复合（组装）缺乏形式

化和机械化的机制，通常只能有开发者在分析

理解后进行手工复合。

黑盒复用和白盒复用

•对已有软件资源的复用存在两种情形，一是不

作修改的全部采用，这类构件恰好能满足使用

者的需求，这种复用称为黑盒复用；

•另一情形是所复用的构件只能满足使用者部分

需求，需要对构件进行适应性修改才可采用，

这种复用称为白盒复用。

•在大多数情况下，对构件的复用均是白盒复用。

基于复用的软件开发方式

・对照传统的成熟产业，我们可以发现，

专业性的分工是社会化、工业化生产的

基本前提，专业化的零部件生产和使用

零部件的整机生产是主要的生产方式。

•我们有理由认为理想的软件生产方式是:

专业化的构件生产，基于构件复用的应

用系统集成（组装）。

・

一种工厂化的软件生产方式

•Caldieri和Basili提出了一种工厂化的软件

生产方式

青鸟工程简介

•青鸟工程是国家重点支持的科技攻关课题，已

有十余年的发展历程。“七五”、“八五”期

间，青鸟工程面向我国软件产业基础建设的需

求，以实用的软件工程技术为依托，研究开发

具有自主版权的软件工程环境，为软件产业提

供基础设施一软件工具、平台和环境，建立工

业化生产的基本手段，促进我国软件开发由手

工作坊式转向用计算机辅助开发，以提高软件

开发效率，改善软件产品质量。大型软件开发

环境青鸟系统便是这一阶段攻关工作的成果。

・“九五”期间，青鸟工程的任务是在前

期攻关工作的基础上，为形成我国软件

产业规模提供技术支持。重点是研究软

件的工业化生产技术，开发软件工业化

生产系统——青鸟软件生产线系统，即

基于构件一构架模式的软件开发技术及

系统，为软件开发提供整体解决方案，

推行软件工业化生产模式，促进软件产

业规模的形成。

青鸟HI型(JB3)系统

•作为研究成果之一，青鸟工程开发了基于异构

平台、具有多信息源接口的应用系统集成(组

装)环境青鸟III型(JB3)系统。青鸟III型系统研

制的目标是针对软件工业化生产的需求，完善

并初步实现青鸟软件生产线的思想，制定软件

工业化生产标准和规范，研究基于“构件一构

架”模式的软件工业化生产技术，研制支持面

向对象技术，支持软件复用的，基于异构平台、

具有多信息源接口的应用系统集成(组装)环境。

其最终目标是要构造如下图示意的软件生产线

系统。

青鸟软件生产线

构件生产车间

标唯规范与质量保证

­软件的生产过程划分为三类不同的生产车间，

即应用构架生产车间、构件生产车间和基于构

件、构架复用的应用集成（组装）车间，从而形

成软件产业内部的合理分工，实现软件的工业

花圣产。

•软件开发人员被划分成三类：构件生产者、构

件库管理者和构件复用者。这三种角色所需完

成的任务是不同的，构件生产者负责构件的生

产、描述；构件库管理者负责构件分类以及构

件库的管理工作；而构件复用者负责进行基于

构件的软件开发，包括构件查询、构件理解、

适应性修改、构件组装以及系统演化。

复用带来了软件开发过程的变革

•由于复用活动的存在使得传统的软件生

存期模型不再适用，软件开发过程分为

两个相互关联的过程，即开发可复用资

源的过程和根据可复用资源开发应用系

统的过程，REBOOT计划中将其称为

DEVELOPINGFORREUSE和

DEVELOPINGWITHREUSE

■

青鸟山型系统的体系结构

基于复用的

胡友工具集

厂■向琳4

激博工具

西•自对八

警总工只

尸面白对蒙、

ttiMM

k而R时拿、

分析工具P

规范

,规范包括：

-青鸟可复用构件制作指南

-青鸟领域工程方法指南

-青鸟构件模型

-青鸟构件描述语言

-青鸟构件库概念模型

-基于复用的软件开发过程

青鸟构件模型设计原则

1.表达能力足够强

2.简单性

3.支持构件的复合

4.模型和方法学关系的考虑

5.一致性和完备性

6.实用性考虑

7.扩展性考虑

8.对软件开发过程的考虑

表达能力足够强

•模型是对客观对象的抽象）合适的抽象

层次是十分重要的，必须既能抓住本质，

又不陷入细节。从表达能力考虑，青鸟

构件模型首先必须遵循3c模型

•3c模型由构件的三个不同方面的描述组

成,即概念（concept）、内容（content）

和语景（context）三个方面

3c模型

•概念：关于“构件做什么”的抽象描述，可以通过概

念去理解构件的功能。概念包括接口规约和语义描述

两个部分，语义描述和每个操作相关联(至少表示为

前后置谓词形式)。

•内容：概念的具体实现，描述构件如何完成概念所刻

划的功能。

•语景：描述构件和外围环境在概念级和内容级的关系。

语景刻划构件的应用环境，为构件的选用和适应性修

改提供指导。语景进一步可分为:、秩念语景

(ConceptualContext)描述构件间接口和语义方面的

关系；操作语景(OperationalContext)刻划构件中法

操作数据的特征(如类型和操作)；、实现将景、、

(ImplementationContext)描述构件间在实现方面的依

赖关系。

简单性

•简单性是各种模型必须予以考虑的重要

性质，简单意味着易于掌握和理解。简

单性和强的表达能力是一对矛盾，必须

合理权衡。

•青鸟构件模型应在具有足够强的表达能

力的前提下尽可能简单，因为构件被很

好地复用的前提是必须能够被充分的理

解。

支持构件的复合

•构件模型仅仅作为构件的抽象和描述是不够的,

必须能够描述构件间的关系及构件的复合，这

样才有实用的价值和完整性。

•青鸟构件模型考虑了直接复用构件的复合问题,

在源代码级上提供了构件复合的机制。同时，

也支持目标码级构件的复合，当前的考虑是将

青鸟构件转换为符合某种规范的目标码构件

（如OLE构件），通过相应的构件互操作机制

来实现复合。

模型和方法学关系的考虑

­构件模型的确立和具体的软件方法学有

着密切关系，不同范型的方法学必然导

致不同的模型。

•青鸟构件模型遵循00范型，其构件结构

符合00风范。如此考虑是因为00技术

能对软件复用提供更有力的支持。对于

基于传统范型的构件，如模块类构件，

可考虑将其通过再工程封装成00类构件。

一致性和完备性

•模型必须具有对内的一致性和对外的完

备性。

・所谓一致性是指构件作为一个封装体必

须具有一致的对外接口、一致的组成结

构以及一致的交互方式。

•完备性是指不存在模型所不能描述的构

件（在00范型内）。

实用性考虑

•实用性是青鸟构件模型所考虑的主要因

素之一。

•从实用性角度来看，构件模型应易于理

解、支持复合、方便分类和检索。

•青鸟构件模型应作为青鸟构件库概念模

型的核心。

扩展性考虑

•模型的可扩展性是指在保持模型本身的一致性

和完备性的前提下，模型可以随着应用需求的

增长而演化。为此，在模型设计初期，能适应

扩展的设计考虑是必需的。

•青鸟构件模型目前主要考虑工程实用性，进一

步的考虑是结合形式化规约技术，给出构件的

形式化功能规约，一方面可用于支持基于形式

化功能规约的构件分类和检索策略，通过规约

匹配查找所需的构件；另一方面支持更有效、

更自动地复用非代码类构件，通过形式规约变

换技术，实现产品复用和过程复用在一定程度

上的结合

对软件开发过程的考虑

•软件复用可以发生在软件开发过程的任

意阶段，各个阶段的产品均是可复用的

目标，越早阶段的复用可带来更好的效

血。

•青鸟构件模型描述的对象是多层次、多

阶段的构件，层次刻划构件的抽象程度。

层次和开发阶段是密切关联的，开发阶

段越早，构件抽象层次也就越高

构件的形态、层次和表示

•青鸟构件模型从三个不同的、相互正交

的视角来看待构件，每个具体的构件都

是形态、层次和表示构成的三维空间中

的一个点。

构件的形态

•构件呈现不同的形态（Form），形态的差异体

现在构件的结构组织方式和依赖的方法学范型

上。青鸟构件可分为如下几种形态：

-类（Class）:以类为单位进行封装而得到的构件，

这是最基本的构件单元

-类树（ClassTree）:以一个抽象类为根，若干继承

该抽象类的具体子类（也可能有抽象子类）为节点

的一棵类树。这样的一棵类树被封装为构件，对外

实现了具体子类的隐蔽，抽象根类提供了该类树的

对外接口规约，对具体子类的操作（删除或增加）

以及子类对象的创建均由抽象类控制，该类树的客

户无需知道类树结构和具体子类。

一个类树的例子

•类树作为构件的优点在

于：

a.类树比类具有更多的独

立性，对外界依赖少，

更易于复用；

b.类树封装使得用户只需

关心所需功能的抽象和该类树被封装为构件，类树

规约而忽略具体子类细的客户只知道抽象类Graph,

下；并不关心类树中有多少子类,

所有操作都是针后Graph类

C.类树封装后其结构变化

和具体子类的增删对客进行，通过条件限制实现对

户不会产生影响。子类对象的匿名创建和操作

框架

•框架(Framework):一个框架由一组协作构

件组成，阐明了整个设计、构件间依赖及成员

构件的责任分布。

•这些成员构件通常是子框架、类树或类，大多

以抽象的形式出现，实现细节放在具体子类中,

构成了一个抽象设计，不同的具体子类可产生

对设计的不同实现。

•框架作为构件使得用户可以复用设计，用户通

过具体子类的嵌入而在框架中加入特殊功能。

一个框架的例子

•GraphResizer称为图形变

形器，它既是Graph的子

类，又是Graph对象的操

作者(变形器)，每一

种具体图形对象都宥对

应的具体图形变形器，

GraphEditor用于屏幕上

•图中箭头线表示客户关画卤，每一种具体图形

系(Clientship)，带△类都有对应的编辑器。

的线表示继承关系。这用户复用这个框架，通

是一个由三个抽象类组过加入具体子类，即可

成的框架得到处理不同图元的应

用程序。

设计模式

•设计模式(DesignPattern):设计模式

是对经验的显式表示，每个设计模式描

述了一个反复出现的问题以及该问题解

法的核心内容，它命名、抽象并标识了

一个通用设计结构的关键部分，使得它

可以用来创建一个可复用的面向对象的

设计。设计模式作为可复用构件体现了

较高层次的设计思想复用。

模式的四个基本要素

-1）模式名称：是一个助记名，他用一两个词来描述模式

的问题、解决方案和效果。

•2）问题：描述了应该在何时使用模式。它解释了设计

问题和问题存在的前因后果，它可能描述特定的设计

问题，如怎样用对象表示算法，也可能描述了导致不

灵活设计的类或对象结构，有时候，问题部分还会包

括使用模式必须满足的一系列先决条件。

•3）解决方案：描述了一个设计的各个组成成分（结

构），以及它们之间的相互关系及各自的职责和协作

方式。

•4）效果：描述了模式使用的效果及使用模式应注意的

问题。

设计模式的分类

■创建型模式

-AbstractFactory（抽象工厂）、Builder（生成器）、

FactoryMethod（工厂方法）、Prototype（原型）、

Singleton（单件）

•结构型模式

-Adapter（适配器对象）、Bridge（桥接）、

Composite（组合）、Decorator（装饰）、Facade

（外观）、Flyweight（享元）、Proxy（代理）

•行为型模式

-ChainofReponsibility（职责链）、Command（命

令）、INTERPRETER（解释器）、Iterator（迭代

器）、Mediator（中介者5、Memento（备忘录）、

Observer（观察者）、state（状态）、strategy（策

略）、TEMPLATEMETHOD（模板方法）、visitor

（访问者）.........................

构架

•构架(Architecture):应用系统体系结

构的显式表示。构架具有领域相关性，

构件根据构架进行复合而生成可运行的

系统。构架是一类特殊的构件，可视为

框架用于描述一个应用系统时的极限状

态。

各类形态构件间的关系

•通常，一个构架由若干框架所构成，框架又可

包含子框架、类树、抽象类和具体类，类树由

抽象类和具体子类构成，类是最基本的构件单

元。在这个意义上，构件的形态体现了构件粒

度上的差异。一个框架通常含有多个设计模式

的采用，每个设计模式都有若干个框架作为它

在不同领域的具体实现。

•这里讨论的构件形态均和00方法范型相依赖，

对于传统范型的构件可以通过再工程替其转换

为00构件，如传统的模块、模块簇可以转换

封装为00的类、类树和框架，并按照00的方

式进行复合组装。

构件的层次

•可复用构件根据其产生于开发过程的不

同阶段而处于不同的抽象层次。青鸟构

件模型考虑将构件分为四个层次。

•分析件：指系统需求规约和功能规约。

•设计件：指系统体系结构和设计方案。

•编码件：由具体程序设计语言编制的源

代鸡构件。

•测试件：测试计划和测试案例。

构件的表示

•不同层次的构件具有不同的表示媒介和

手段,如：

-图形

-复合文档

—正文

-伪码

-编程语言

—目标

青鸟构件模型

•青鸟构件模型从九个方面来描述构件，

更多地关心构件的易理解性、封装性及

构件间关系，通过给构件提供明确的对

外接口实现服务提供者和其服务请求者

的分离，模型更多地关心构件及其使用

者间的交互，特别是对构件使用者有意

义的部分。

(1)概念

•这是对构件功能的抽象描述，多采用名

词来表示。如堆栈(Stack)、银行帐号

(Account)等,这类名词术语应尽可能

采用同领域内的公认词汇，以便于直观

的理解和相互交流。

(2)操作规约

・用来指称构件对外提供的、可被请求的服务。

•Operation=Name+Signature+Axiom+Exception

+Context

•Signature给出了操作的类型声明，由参数类

型和结果类型构成，操作参数有in、out.

in&out三种模式(Modei;Axiom以前后置断

言的形式给出操作的功能规约；Exception描述

操作的例外处理；Context描述操作使用的语景。

•对收到的服务请求，操作的执行有两种方式：

-at-most-once如执行成功，则恰好执行一次；如出

现例外，则执行一次或0次

-best-effort:不需返回结果，不等待执行

(3)接口

•接口给出了构件的对外行为描述，分入接口(in-

interface)和出接口(out-interface)。

•入接口：每个人接口刻划一个操作集合，接口可以具

有用一对访问函数(获取或设置属性值)表示的属性。

一个构件可拥有多个人接口，客户(Client)可通过一

个或多个人接口请求构件服务。

­出接口：描述构件对外界的请求。当构件完成某一功

能时，可能需要其他构件的协作，出接口指明了这种

对外关泵。

•构件间存在入接口继承关系(子类型关系)，这种关

系指明：凡是父构件能响应的请求，其继承者同样可

以响应。子类型关系是造成多人接口的原因。

(4)类型

­类型用于定义“什么值可用作为操作参数”。

在00程序也操作参数可分为三类：

•基本类型值：这是一般程序语言中都提供的基

本类型，如整数、字符、字符串等。

•对象索引：指对象的名或地址，凭此将对象作

为参数传递。

•构造值：由对象和基本值混合构造成的结构。

（5）实现体

•这是构件的具体实现部分，是实际完成

被请求服务的系统。不同层次的构件有

不同的实现（表示）方式，具有不同实

现体的构件可能拥有相同的接口和功能

规约。

(6)构件复合

­构件通过复合组成系统。模型中的复合

关系仅限于可表示为程序代码的构件，

复合的方式是服务请求(消息传递)。

构件间出、入接口的关联建立起构件的

复合关系。

•服务请求=请求的操作+目标对象+参

数表+语景选项

构件性质、注释和语景

•(7)构件性质

指明构件的形态、层次和表示。

•(8)构件注释

描述和构件库相关的其他性质，这些性质

是构件库管理所必需的信息，如构件作者、制

作时间、修改限制、修改影响等等。

•(9)构件语景

描述构件的软、硬件使用环境和实现依赖。

其他关于构件的模型

OMG的CORBA/OM

MICROFOFT的OLE/COM

DEC的COM

REBOOT模型

RESOLVE模型

青鸟构件模型和构件描述语言

•青鸟构件模型是以对象计算模型为基础进行设计的，

它支持多种不同构件形态：类、抽象类、类簇、类树、

框架(framework)和构架(architecture)。

•类构件、类簇构件和类树构件的引入为代码复用提供

了三种不同粒度的支持。

■抽象类构件的引入为设计复用提供了一定的支持。

•框架构件的引入则对面向对象设计的复用提供了充分

的支持。

­而构架作为一种系统级的框架，为系统级构件组装提

供了支持。

•青鸟构件模型具有自包含性，即要求构件组装而成的

构件子系统仍是一个可以继续进行复合的构件。这使

得原有的构件一构架两层结构扩展为构件一构件子系

统一构架多层结构，从而拓展了该模型的表达能力。

・••••••

软件复用的优势

•软件工程界普遍认为软件复用具有以下优势：

1.提高软件生产率

2.提高软件产品质量

3.缩短开发周期

4.降低维护费用

5.便于软件移植和实现互操作性

6.支持快速原型开发

7.降低程序员和端用户(EndUser)培训费用

■在工业界推行复用取得成功的范例有HP、IBM、Unisys、

NEC、BNR、富士通、Raytheon导弹系统、GTE数据服务、

SofTech公司、Universal防务系统(UDS)、Bofors电

气公司等等。许多著名的企业内部也建立了复用机制，

但是尚未对外公开。从管理上和技术上采纳软件复用

已经是大势所趋。

软件复用的困难

1.系统开发者缺乏软件复用的观念。

2.制作和整理可复用构件需要增加额外的投资。

3.构件不易理解和学习。

4.缺乏有效的构件库。

5.缺乏足够选用的构件或者构件的质量不佳。

6.构件不完全符合需求时，不容易修改。

7.构件紧密依赖其原有开发平台，难以在其他平台上使用。

8.构件依赖于某一程序语言，无法与其他语言的构件集成。

9.复用别人制作的构件有心理上的障碍(NotInventedHere和Not

InventedThere综合症)。

10.与软件复用有关的版权问题、合同问题和成本分配问题。

11.缺乏理解、修改和组装构件的支持工具。

12.复用的收益难于估计和度量。

•其中的2.5.6.7.8几点表明对高质量的可复用构件存在着很大

的需求，而4.io.n等几点表明在构件开发者与复用者之间缺

乏有效的交流，限制了构件制作者的创作积极性。

构件一般性制作指南

•分析、设计和测试阶段的成果本身都有被复用

的潜力，应被当作RSC；

•在新系统中复用前期的软件工程成果往往带来

对相应后期产品的复用。

•可复用RSC应该以方便复用的方式被表示，易

于识别，易于独立提取，与系统特定的和易变

的成分分隔；在组织内部采用一致的机器可读

的记号表示分析和设计RSC,以便进行自动的

信息提取和转换。从分析到设计到编码的转换

应该遵循上一阶段的复用考虑、保持相邻阶段

RSC之间的良好映射和可跟踪性质。

建立一个鼓励复用现有软件的需求

•需求规约必须认识到复用的必要性并鼓励软件复用。好的

需求规约应该只规定所需的功能和性能指标，允许开发者

决定操作上和实现上的细节。一个极端明细的规约是很难

与任何现有软件相匹配的，不必要的系统需求将限制软件

复用。将软件复用作为需求之一，在规约中规定所有必须

的(Required)和期望的(Expected)复用活动。

•建议：要逐条检查每一需求的必要性，确信其中不包括进

一步的设计选择。

•建议：给承包商以复审需求规约的机会。改变以往将需求

规约在招标之前定住不变的做法，向潜在的承包商提供需

求规约的草稿，让开发者参与进来，标识出他们认为可以

修改并将促进复用的地方，由客户和承包商共同完成项目

的规约文档。

•建议：复用需求必须解释什么是复用和如何评估复用。为

开发者指定一个复用目标，比如复用的代码、函数的数量

等，在合同中为复用制定奖励措施以鼓励复用。

将可复用软件的开发列入需求

•如果希望所开发的系统是可复用的，就应该在

需求中显式声明出来，并且应该使这种项月需

求在客观上是可测试的。

•建议：这种需求必须定义什么是可复用性和如

何评估RSC的可复用性，应该规定对RSC所期

望的复用范围（在项目内部或者跨项目的复用,

在不同的OS上复用等等），规定与某一复用标

准的符合程度，规定RSC所必须具备的文档，

要求对软件的可复用性进行测试，以及要求开

发者对RSC进行维护等。

领域

•领域(Domain)被定义为“一类相关或相似的软

件应用系统"O从复用的角度看来，面向领

域的构件具有较高的可复用性。如果组织所关

注的领域足够成熟，能够建立起领域构件库，

那么即使构件库的规模不大也照样会有相当大

的作用。领域分析(DomainAnalysis)的成果

不仅在复用者生成应用系统时有用，而且可以

用来组织软件产品线(ProductLine),管理用

户需求和辅助构件库进行构件的分类等。

制作面向领域的可复用构件

•领域分析和领域工程是应用系统开发过

程中最需要经验也最缺乏方法和工具支

持的阶段之一，领域知识在分析和设计

阶段有十分重要的作用。如果能够将领

域知识和模型与本领域的构件结合，将

大大提高应用系统的开发效率

领域分析的作用

•领域分析活动不同于通常对特定系统进行的需

求分析，它是对特定应用领域中已有的系统、

预期的需求变化和技术演化进行分析，目的是

标识出整个领域中通用的构架和相同的功能与

接口。领域分析的结果将影响到系统需求的取

舍，由此构造出的系统由于更适应变化的需求,

日后被复用的可能性也更大。

•建议：要评估领域分析的必要性和可行性。在

适当的时机进行领域分析或者采用现有的分析

成果。在利用现有领域分析成果时应该评价其

适用性，即使整个构架未必可用，仍有可能复

用某些标准的构件和接口。

领域分析的建议

■建议：在评估领域分析的必要性时有以下评价准则，

对这些问题的回答应该大多数为“是”：

-本组织还会在同一领域建造其他系统并由此从一个标准

的构架和适合该构架的构件集合中获益吗？

-在本领域中建造系统的技术已经足够成熟并能够产生一

个令人满意的标准构架了吗？

-开发者是否建造过类似系统，是否获得了足够的经验以

保证所得的领域分析结果是可用的呢？

-是否有一种要求和确保领域分析的结果被实际应用了的

机制呢？比如，一个小组受命开发标准的构架后，是否

有一种方式让其它开发小组获知并采用领域分析的成果

呢？

-有否一种方式在受益于领域分析结果的小组之间分摊领

域分析的成本？

领域分析的建议

建议：在评估领域分析的必要性时有以下评价

准则，对这些问题的回答应该大多数为“是”

-要建造的系统是该领域的一个代表吗？领域构架会

适用吗？

-到底什么是可用的？如果只有一个构架模型和部件

列表而没有可复用的详细设计或者代码构件，也许

就不会节省很多成本了。

-如果详细设计和代码构件是可用的，它们提供了多

少要求的功能呢？

-构架达到了哪个层次的标准？为了组织内部有更多

共同之处而使用这个构架和（或）接口会获益吗？

-分析结果在实践中被证明了吗？有多少可信度？

领域分析的建议

•建议：即使没有时间或能力进行完整的

领域分析，仍然可以快速标识出本领域

中可复用的子系统和接口（比如标准设

备、通信协议、用户接口、应用算法

等），为今后的开发储备“零部件”。

•建议：在应用领域分析成果时，应该及

时提供反馈，补充或改进其成分，促进

领域模型随实际领域的演化而演化。

构件库的管理流程

图1.构件库的韶渊g

构件的登记表格

•构件的登记表格中有下列属性：

1.名称：每个构件都必须有一人确定的名称，该名称

必须完整地标识了该构件的本质。如stack,resource

manager等。

2.作者：即制作或提供该构件的单位或个人的名称，

以及联络地址等相关信息。

3.制作日期：即构件制作的完成日期。

4.入库日期：即构件进入构件库的日期。

5.版本号：即该构件在一组构件演化系列中相应的版

一号。

6.使用环境：即使用（包括理解/组装/修改）该构件时

必须提供的硬件和软件平台。如所需的特定的硬件

环境、操作系统、数据库平台和网络环境等。

7.应用领域：即该构件原来或可能被使用到的应用领域

(及其子领域)的名称。如MIS,CAI等。

8.用途：即该构件在被应用的领域中所发挥的作用。

9.功能：即该构件在原有或可能的软件系统中所提供的

软件功能集。

10.表示方法：即用来描述该构件内容的语言形式或媒体。

如源代码构件所用的编程语言等。

11.形态：即该构件的组成成分及其相互关系。如类、类

树、框架、模块等。

12.层次：即该构件相对于软件开发过程阶段的抽象层次。

如分析、设计、编码等。

13.上下文环境：即该构件在组装时系统所必须提供的程

序级上下文环境。

14.尺寸(size)：即该构件的大小。

15.创作工具：即构件的制作者在制作该构件时所使用的

软件工具。

构件库的分类策略

•一个刻面分类模式由一组描述构件本质特征的

刻面所组成，每个刻面从不同的侧面对构彳牛库

中的构件进行分类。

•例如，这组刻面可以是构件的应用领域、功能、

操作对象、使用环境等。

•每个刻面是由一组基本的术语（即关键词）所构

成的（称为术语空间termspace）。一个构件可以

被每个刻面中的一个或多个术语所刻划（刻面术

语是一个确定的集合），而每个刻面则反映了对

库中构件的一种划分，因此用户可以直观地从

不同的角度指明待检索的构件，也有利于用户

对构件的理解。

刻面分类策略的特性

1.刻面必须充分并明确地描述构件库中全体构件，即每一

个构件都可以用该刻面来分类。

2.每一个刻面与一个术语空间相关联。任意两个刻面的术

语空间是正交的，即一个刻面的术语发生变化不会影响

到另一个刻面的术语空间。

3.一个刻面的术语空间为有限的不定空间（finite&indefinite

space）,即可以随时间的演进而动态地增加和删除术语。

4.每一个构件的所有刻面必须予以定义，不允许在对构件

分类时有未定义的刻面；但查询时，用户可以利用任意

数目的刻面来查询。

5.构件库管理者对构件进行分类时，应该针对每一个刻面，

从术语空间中选择适当的（多个）术语，以完成构件的封装

工作。

6.在一个术语空间中的术语按一般/特殊关系形成树状的层

次结构，每一个术语附带有不定数目的同义词（术语间可

以具有同义词关系）。...........................

刻面分类策略的好处

•构件库管理者通过将刻面与对应的术语

相联结，可以在构件间建立复杂的联系。

与一般的层次分类策略相比，刻面分类

策略更易于修改，更富有弹性，因为对

一个刻面的修改不会影响到其它的刻面。

同时，每个刻面对应一个结构化佰术语

空间，避免了一般的关键词分类策略的

杂乱无章，使得对关键词的管理更为方

彳更和有序。

属性与刻面的区别

刻面是构件属性的一个子集。属性绝大部分是

由构件的制作者或提供者提供的，而刻面则完

全是由构件库的管理者规定的，构件的制作者

或提供者完全不需要了解它们。

刻面是构件的复用者在查询构件时最感兴趣的

构件属性。在查询时复用者通过选择刻面的术

语，可以明确地限定构件的范畴，不会有遗漏

的构件。

术语空间

•在刻面分类策略中，每个刻面关联了一

个合法术语的结构化集合-术语空间，在

构件的分类和查找中用到的术语均来自

于这些术语空间。

•术语空间的结构反映了术语间的语义关

系，因此术语空间可以看做是一种语义

网，而构件从外部来看，都是一组刻面

术语的集合。

术语的两种关系

•即一般/特殊关系和同义词关系，这是基于以下

两个目的：

-简化术语的定位。用户可以沿着术语间的关系迅速对术

语进行定位。同时，用户要查找的术语可能不够精确，

由于习惯不同，使用的术语也不尽相同，因而查找时容

易出现术语的不匹配(mismatch)。利用这两种关系，既

可以统一用户间术语使用上的差异，又可以帮助用户将

自己的检索需求进一步修正和细化，这也是一个逐步求

精的过程

-检索到所需改动最少的构件。若没有发现刻面术语与用

户要查找的术语正好匹配的构件，那么构件库管理系统

就会让用户检查那些刻面术语与用户要查找的术语相接

近的构件。这种找到相似构件的机制称为“松驰查

找”(relaxationofsearch)。这样用户可以在构件库现有

的构件中找到所需改动最少的构件，提高复用的效率。

青鸟构件库的刻面

•刻面的定义

-1.使用环境(ApplicationEnvironment)

-2.应用领域(ApplicationDomain)

-3.功能(Functionality)

-4.层次(LevelofAbstraction)

-5.表示方法(Representation)

构件库的实体-关系图

构件间的关系

(1)被实现关系(Refinement)

(2)版本关系

(3)包含关系

(4)相关关系

⑸协作关系

(6)继承关系

构件库的查询策略

•使用者可以按刻面进行查询。即通过选择任意刻面的一个

或多个术语，就可以迅速限定构件的范畴。

­除了刻面查询外，使用者可根据构件的任意属性进行辅助

查询。

•使用者在查询构件过程中，可随时通过超文本(hypertext)浏

览器对库中构件进行有层次地浏览。

•构件库提供了类似“服务台”的机制。使用者在查询构件

过程中，可以向“服务台”求助，也可以向它提出自己的

意见和建议。

•使用者找到一个构件时，构件库可以显示出与该构件有某

种关系的所有构件。

­较为熟练的使用者可以用类似SQL查询语句的形式，以构件

的属性和刻面作为条件变量，并允许查询条件的与、或、

非的任意组合。

•上面提到的查询方法可以任意组合，逐步求精，并允许查

询过程的回溯...........................

构件库的管理过程

•项目中每个开发者都应在构件库中建立帐户

•尽量避免复用还没有进入构件库的构件

•为构件库提供对构件和构件库支持工具的使用

经验和反馈

•将复用构件时遇到的所有问题通知构件库

•将构件的更新版本和增强版本提交给构件库

对构件的选择和提取

•使用构件库提供的材料决定构件的选取

-在选取构件前检查构件的相关信息

-检查构件的质量和可复用性等级，以及构件的推荐

意见

•提取完整的构件

-提取一个代码构件时应尽量提取出它的分析构件和

设计构件等

-构件间可能存在继承、协作和包含关系

-提取每个构件时，构件库会将构件的构件描述语言、

摘要、使用样例、分类信息等作为构件的一部分一

起提取出来

•提供反馈日期等信息

-反馈日期通常在提取后的三个月内

需求分析

•需求分析时，应首先查询构件库，根据用户需求确定

构件库中是否有相似的构架和子系统，或在该领域中

是否有对应的领域分析构件

需求分析

建立复用需求并尽早发现复用的机会

•在提交具体需求前，要检查构件库中是

否有可以复用的构件

・避免在需求分析阶段将需求过分细化

•要参照构件库的分类模式指定系统需求

•尽量选择支持复用程度更高的开发方法

和工具

对领域分析构件的复用

领域分析过程采取的主要步骤

1.知识获取(KnowledgeAcquisition)---收集和分析

与问题域相关的信息，并将这种信息用该领域内部

和外部的对象来描述。

2.领域定义(DomainDefinition)---对知识获取阶段

标识出的对象进行分析，以便定义出领域的范围和

具体边界。

3.模型建立(ModelFormulation)---对领域定义阶段

标识为领域内部的对象进行建模，以便进一步地理

解它们在领域中扮演的角色。

4.模型演化(ModelEvolution)——将模型进行进一步

地分析和精化，以开发出该领域的分类(taxonomic)

模型，用于表示出该模型的组织结构和语义

领域分析过程的产品

•功能层次(FunctionalHierarchy)---一个功能需求的层

次性模型。

,实体一关系模型(Entity-RelationshipModel)----显示领

域内各对象间关系和接口的模型。

•类属的软件构架(GenericSoftwareArchitecture)---以

软件构件的形式表示出的E-R模型中的对象。

•分类(Taxonomy)——提供了一个用于定义领域内对象的分

类模式。

•标准需求(StandardRequirements)---涉及该问题域的系

统都必须满足的一套类属性的需求。

,领域特定的语言(Domain-SpecificLanguage)----用于描

述和分类领域特定构件的词汇。

•设计和开发准则(DesignandDevelopment

Guidelines)——基于组成该领域的构架和构件的一个类属

性的开发框架。

复用已有的构架和子系统

•检查构件库中可复用的构架和子系