Nof S.Y. Springer Handbook of Automation

Подождите немного. Документ загружается.

365

Modeling and

22. Modeling and Software for Automation

Alessandro Pasetti, Walter Schaufelberger (Δ)

Automation is in most cases done through the use

of hardware and software. Software-related costs

account for a growing share of total development

costs for automation systems. In the automation

ﬁeld, containment of software costs can be done

either through the use of model-based tools

(e.g., Matlab) or through a higher level of reuse.

This chapter argues that both technologies have

their place. The ﬁrst strategy can be used for the

design of software for a large number of identical

installations or for the implementation of only

part of the software (i. e., the control algorithms).

The second strategy is advantageous in the case

of industrial automation systems targeting niche

markets where systems tend to be one-of-a-kind

and where they can be organized in families

of related applications. In many applications,

a combination of the two approaches will produce

the best results. Both approaches are treated

in the paper. The main focus of the chapter is

on developing software for automation. As such

software will often be implemented for slightly

different processes, it is highly appropriate that the

production process is at least partly automated.

As space is limited, this chapter can not cover

all aspects of the design and implementation

of software for automation, but we claim that

themethodsdiscussedhereintegrateverywell

with traditional methods of software and systems

engineering.

22.1 Model-Driven Versus Reuse-Driven

Software Development.......................... 366

22.2 Model-Driven Software Development ..... 368

22.2.1 The Matlab Suite

(Matlab/Simulink/Stateﬂow,

Real-Time Workshop Embedded

Coder)......................................... 368

22.2.2 Synchronous

and Related Languages................. 369

22.2.3 Other Domain-Speciﬁc Languages .. 370

22.2.4 Example: Software for Autonomous

Helicopter Project......................... 371

22.3 Reuse-Driven Software Development...... 371

22.3.1 The Product Family Approach......... 371

22.3.2 The Software Framework Approach. 372

22.3.3 Software Frameworks

and Adaptability .......................... 373

22.3.4 An Example: The OBS Framework.... 375

22.4 Current Research Directions ................... 376

22.4.1 Automated Instantiation

Environments .............................. 376

22.4.2 Model-Level Reuse ....................... 377

22.5 Conclusions and Emerging Trends .......... 379

References .................................................. 379

Experience from contributions to various re-

search projects recently performed at Swiss Federal

Technical university (ETH) are also summarized.

Software plays an increasing role in the design and

implementation of automation systems. The efﬁcient

construction of reliable software is therefore a general

goal in many automation projects. Automation projects

are demanding and multifunctional, and nonfunctional

(timing, reliability, testability etc.) requirements have to

be satisﬁed. From the early days of the development

of computers, their use in automation was investigated,

even ifthe costof thecomputer was inmany cases much

higher than the cost of the plant in the early 1970s.

From these early days, two competing develop-

ments emerged. One linedeveloped from the imperative

programming languages used at the time (Fortran, later

C and Pascal) and the other from the control engineer-

Part C 22

366 Part C Automation Design: Theory, Elements, and Methods

C PROGRAMM ZUR DIGITALEN REGELUNG MIT EINEM P-I-REGLER (DIGREG)

EXTERNAL PIREG

COMMON R,S

CALL STRT

CALL IGNORE (17)

CALL SMOD (5,I ND)

PAUSE 1

CALL SMOD (3,I ND)

CALL DLAYS (1)

CALL CNCT (18,PIREG,I ND)

READ (4,100) R

WRITE (4,200) R

READ (4,101) K

WRITE (4,201) K

S = 0

PAUSE 2

CALL SMOD (1.I ND)

CALL EARM

CALL EENA

CALL SPIG (K,3,2,I ND)

1 CONTINUE

GO TO 1

100 FORMAT (F7.5)

200 FORMAT (10X, 5HR = ,F7.5)

101 FORMAT (13)

201 FORMAT (10X,5HDT = ,I3)

STOP

END

SUBROUTINE PIREG

DIMENSION X(1),U(1)

COMMON R,S

CALL RIDC (1,1,X,I ND)

S = S + R-X(1)

U(I) = R-X(1) + .0075*S

CALL SDIC (1,1,U,I ND)

RETURN

END

Fig. 22.1 Fortran program for a PI controller in 1970

ing approach of describing systems in a declarative way

by block diagrams or similar means. Both of these ways

were continued and led to solutions widely accepted

today in industry.

A Fortran program for a proportional–integral (PI)

controller on the hybrid computer available at the time

to test ideas of digital control is shown in Fig.22.1.

This is clearly an imperative style. In a text of the

mid 1980s on real-time programming of automation

systems [22.1], conventional programming was still the

only way to program real-time systems, and the real-

time industrial language PORTAL (similar to Pascal)

was used for practical experiments, implementing PI

and adaptive controllers.

A program we developed in the late 1980s for

educational purposes with a graphics environment on

a personal computer (PC) [22.2, 3] is shown next

in Fig.22.2 as controller for a small heating system.

Simulink was not yet available at the time. At the time,

Gem by Digital Research was found to be better suited

than Windows forsuch tasks, theprogram was therefore

written in Gem.

A block diagram is drawn interactively on screen

as the declarative description of the control algorithm,

which can be directly executed to produce experimental

results. This is declarative in nature; the order of execu-

tion is not evident from the drawing. A major problem

when realizing such programs at the time in Modula-

2 was the fact that the language is strongly typed and

that lists of function blocks had to be kept. Obviously,

these function blocks are of differing types. Program-

ming tricks had to be used to overcome this. A redesign

in the object-oriented language Oberon [22.4] demon-

strates how easily such programs can be designed with

the appropriate mechanisms such as subclassing. In

the object–processmethodology (OPM) function, struc-

ture, and behavior are integrated into a single, unifying

model, OPM signiﬁcantly extends the system modeling

capabilities of current object-oriented methods [22.5].

These earlyattempts to efﬁcient program design and

implementation clearly aimed at producing a program

for a given task. Graphical and textual libraries were

created, but essentially an individual program was the

goal of the design. Though quite different in terms of

the approach taken, these early attempts were all model

based in the sense that a modeling or programming en-

vironment was available and that models were used in

all stages of the development process.

This changed with the introduction of object-based

and object-oriented techniques into software engineer-

ing. It became possible to design adaptive programs or

programs for families of systems with better orientation

on reuse. This is an issue we want to look at in more

detail in the following sections.

First versions of Matlab became available in the late

1970s, and Matlab quickly became a de facto standard

for control engineers, especially for system design.

22.1 Model-Driven Versus Reuse-Driven Software Development

The fundamental problem of software engineering

is to translate a set of user requirements into

executable code that implements them in a man-

ner that is as cost effective as possible. There

are several ways to solve this problem which, at

least conceptually, can be arranged along a con-

tinuous spectrum that has at its two extremes

the so-called model-driven and reuse-driven ap-

proaches. These two approaches are illustrated in

Fig.22.3.

Part C 22.1

Modeling and Software for Automation 22.1 Model-Driven Versus Reuse-Driven Software Development 367

Fig. 22.2 An early programming and experiment environment

Although most projects will take an intermediate

or mixed approach, it is useful to consider brieﬂy the

two extreme approaches in isolation from each other as

a way to clarify their distinctive features.

In the model-driven approach (left-hand side of

Fig.22.3), the user requirements are expressed in

a modelingenvironment that is capable ofautomatically

generating the application code. The prototypical ex-

ample of such an environment is the Matlab tool suite.

The cost and schedule savings arise from the fact that

the software designand implementationphases arefully

automated.

In the reuse-driven approach (right-hand side of

Fig.22.3), the user requirements are implemented by

conﬁguring and composing a set of predeﬁned software

building blocks. The cost and schedule savings in this

case originate from the possibility of reusing existing

software artifacts (modules, components, code frag-

ments, etc.). Traditionally, the reuse-driven approach

was implemented by developing libraries of reusable

modules. More recently, software frameworks have

emerged as a more effective alternative to achieve the

same aim of minimizing software development costs by

leveraging reuse.

Each approach has its strengths and weaknesses.

The model-driven approach holds the promise of com-

pletely automating the software development process,

but is in reality limited by the expressive power of

the selected modeling language. Thus, for instance,

Matlab provides powerful modeling facilities for de-

scribing transfer functions and state machines but it

does not support well modeling of other functionali-

ties that are equally important in embedded applications

(such as management of external units, generation of

housekeeping data, processing of operator commands,

management and implementation of failure detection

and recovery mechanisms, etc.).

The reuse approach can be more ﬂexible both be-

cause reusable building blocks can, in principle, be

provided to cover as wide a range of functionalities as

desired, and because it can be applied in an incremental

way with repositories of reusable building blocks being

built up over time. The main drawback of this approach

is that the selection, conﬁguration, and composition of

Part C 22.1

368 Part C Automation Design: Theory, Elements, and Methods

Requirement

modeling

environment

Application

code

Component

composition

environment

Application

code

User

requirements

Model-driven

approach

Reuse-driven

approach

Repository of

reusable building blocks

Fig. 22.3 Model-driven versus reuse-driven approach

the building blocks is difﬁcult to automate and, if done

by hand, remains a tedious and error-prone task.

In practice, no application is entirely reuse or model

driven. Instead, the two approaches are complementary

and are applied to different parts of the same applica-

tion. Consider,for instance,the caseof a typical satellite

on-board application. A model-driven approach is ide-

ally suited to cover the modeling and implementation of

the control algorithms of the application. This is appro-

priate because there are very good modeling techniques

for expressing control algorithms and there are very

powerful tools for translating models into code-level

implementations. The existence and high level of ma-

turity of the modeling techniques and of the tools is in

turn a consequence of the wide range of applications

that need control algorithms.

A model-driven approach would, however, be un-

suitable to cover functionalities suchas themanagement

of satellite sensors or the processing commands from

the ground station. These functionalities are entirely

speciﬁc to the satellite domain and this domain is too

narrowto justifythe effort required todevelop dedicated

modeling techniques and support tools. In these cases,

a reuse-driven approach offers the most effective means

to improve the efﬁciency of the software development

process.

In general, the reuse-driven approach is appropri-

ate wherever there is a need to model and implement

functionalities that are speciﬁc to a particular domain.

This is due to the high cost of developing industrial-

quality model-driven environments. This type of tools

only makes economic sense for functionalities that are

widely used, namely for functionalities where there is

a sufﬁciently large base of potential users to justify

their development costs. In other cases, reuse-driven

approaches remain the only viable option.

The model- and reuse-driven paradigms are con-

sidered in greater detail in the next two sections

(Sects. 22.2 and 22.3). The model- and reuse-driven ap-

proaches represent the state of the practice. Section 22.4

extends the discussion to consider some current re-

search trends.

22.2 Model-Driven Software Development

22.2.1 The Matlab Suite

(Matlab/Simulink/Stateﬂow,

Real-Time Workshop Embedded

Coder)

The prototypical example of model-driven develop-

ment in the control and automation ﬁeld is the

Matlab tool suite. This consists of Simulink and

Stateﬂow as toolboxes for programming of continu-

ous time, discrete-time systems, and state machines

in graphical form and of the Real-Time Workshop

to generate C code from Simulink and Stateﬂow

models. This is a well-known solution, well covered

on the World Wide Web (WWW) with many ex-

Part C 22.2

Modeling and Software for Automation 22.2 Model-Driven Software Development 369

+ +

–

+ +

Delay

lob hib

s01

K–

K– 1/s

×10

1/T1

K–

Te/Ti1

kp1

yeamp

m2_×16_formD

re1re z1z

Fig. 22.4 Simulink diagram

amples and will for this reason not be treated in

any detail here (see http://www.mathworks.com/ and

http://www.mathworks.com/products/rtwembedded/).

A very useful fact worth mentioning here is

that Simulink/Stateﬂow diagrams are stored in tex-

tual form and can be analyzed independently of the

interpreter, which can also be replaced by other com-

pilers or interpreters. One such case will be mentioned

later.

Figure 22.4 shows a typical Simulink diagram of

a nonlinear sampled data control system from [22.6].

22.2.2 Synchronous and Related Languages

Behind any model-driven environment there is a lan-

guage that provides high-level abstractions allowing the

designer to express his design. In the case of the Matlab

tool suite, this language is hidden from the user, who

only interacts with a graphical interface. In other cases,

the designer is instead expected to make direct use of

the modeling language.

Synchronous languages are one of the most suc-

cessful families of modeling languages for control and

automation systems. Their main strength is that the syn-

chronous paradigm makes it easier to build veriﬁcation

engines that can automatically verify that a model sat-

isﬁes certain functional properties. The development

process then becomes as follows. The designer ﬁrst

builds a model that is intended to satisfy certain require-

ments. He then translates his initial requirements into

functional properties expressed in a suitable formalism.

The veriﬁcation engine can then verify that the model

does indeed implement the requirements. After success-

ful veriﬁcation, a code generator is used to translate the

model into source code in a general-purpose language

(typically C).

Several imperative and declarative synchronous lan-

guages have been developed following a data ﬂow

model of computation [22.7]. This is well adapted to

the way in which control engineers model their systems

by block diagrams. All the languages must have special

constructs for time, concurrency, sequences of values

(signals, ﬂows), shift operators etc.

The language Lustre and its industrial version

SCADE use data ﬂow models well known to control en-

gineers and all calculations are based on ﬂows (signals).

Esterel is an imperative language in the same domain,

and Signal is another language more suitable for the

design of systems.

Efforts are under way to generate Lustre pro-

grams automatically from subsets of Simulink and

Stateﬂow descriptions [22.8]. This makes programs in

Simulink/Stateﬂow accessible to formal analysis.

SCADE from Esterel Technologies [22.9] offers

tools for the design and veriﬁcation in the area of safety

critical systems. A very simple example of a standard

Part C 22.2

370 Part C Automation Design: Theory, Elements, and Methods

Controller Process

null

Pre

–

const

Fig. 22.5 SCADE environment with a very simple example

control loop in a SCADE development environment is

showninFig.22.5.

A slightly different approach is taken by Giotto,

a time-triggered language for embedded program-

ming [22.10]. Here, the focus is to specify exactly the

real-time interactions between the software components

and the physical world.

22.2.3 Other Domain-Speciﬁc Languages

A more general version of the model-driven approach

is the following: Given a problem area, design and

implement a speciﬁc modeling language for this area,

including an environment for editing, compilation etc.

This procedure has special relevance at ETH, where

Wirth designed and implemented many languages of

general (Pascal, Modula, Oberon) and also of a more

speciﬁc nature (Lola, a logic language). Worth men-

tioning here is Active Oberon by Jürg Gutknecht, an

object-oriented language where every object can have

an integrated thread of control. This high parallelism is

of special interest for reactive systems. The next exam-

ple will provide more information on this approach.

The IEC 61131 languages have been designed

for use in automation. IEC 61131 is an Interna-

tional Electrotechnical Commission (IEC) standard for

programmable logic controllers (PLCs). IEC 61131

speciﬁes the syntax and semantics of a uniﬁed suite

of programming languages for programmable con-

trollers (PCs). These consist of two textual languages,

IL (instruction list) and ST (structured text), and two

graphical languages, LD (ladder diagram) and FBD

(function block diagram). Sequential and parallel pro-

cessing are possible. The standard is developed at

http://www.plcopen.org/, where more information can

be found.

Part C 22.2

Modeling and Software for Automation 22.3 Reuse-Driven Software Development 371

22.2.4 Example: Software

for Autonomous Helicopter Project

The autonomous helicopter project of ETHZ [22.11]

is a typical example of a system where special lan-

guages were developed by Wirth and Sanvido for

several tasks of the onboard processor. The operat-

ing system uses threads instead of tasks [22.12]for

speed-up, the logic language Lola [22.13]isusedfor

the design of ﬁeld-programmable gate arrays (FPGAs),

and the mission control language is used for mis-

sions. An excerpt from a program in the mission

control language is easily readable, as shown in

Fig.22.6.

The controller for the helicopter has also been im-

plemented in Giotto [22.14].

22.3 Reuse-Driven Software Development

22.3.1 The Product Family Approach

Within the reuse-driven paradigm, software product

families have emerged as the most successful form of

software reuse. A software product family [22.15]is

a set of applications that can be constructed from a set of

shared software assets. The shared assets can be seen as

generic building blocks from which applications in the

family can be built. Usually, a product family is aimed

at facilitating the instantiation of applications within

a narrow domain. Figure 22.7 illustrates the concept

of product family. On the left-hand side, the building

blocks offered by the product family are shown. These

building blocks are used during the family instantiation

process to construct a particular application within the

family domain.

Product families are characterized by two distinct

development processes (Fig. 22.8). In the family cre-

ation process, the family’s reusable assets are designed

and developed. In the family instantiation process,the

reusable assets offered by the family are used to con-

struct a speciﬁc application within the family domain.

The family creation process is in turn divided into

three phases. In the domain analysis phase,thesetof

applications that must be covered by the family are

identiﬁed and characterized. The output of this phase

is a domain model. In the domain design phase,the

reusable assets that are to support the instantiation of

applications within the family are designed. The output

of this phase is one or more models of the family as-

sets. The models express various aspects of the domain

design (e.g., there may be functional models, timing

models, etc.) In the domain implementation phase,the

family assets are implemented as concrete building

blocks that can be used towards the construction of fam-

ily applications.

Often, the implementation of the family assets is

done automatically by processing the models deﬁned in

the domain design phase.

Three matching phases can be identiﬁed in the fam-

ily instantiation process (bottom half of Fig.22.8). In

the requirement deﬁnition phase, the family domain

model is used to verify whether the target application

falls within the family domain. This decides whether the

family assets can be used to help build the application.

If this is the case, a sizable proportion of the application

requirements can be expressed in terms of the domain

model, for instance by identifying the features in the

family domain that are needed by the target applica-

tion. In the tailoring phase, the software assets required

for the target application are selected from among those

PLAN Example;

VAR phi, theta, psi: REAL; LandOK*: BOOLEAN;

PROCEDURE LiftOff; (* TakeOff Procedure *)

BEGIN

ACCELERATE(1.0, 0.0, 0.0, 0.0, -0.5);

TRAVEL(9.0, 0.0, 0.0, 0.0, -0.5);

ACCELERATE(1.0, 0.0, 0.0, 0.0, 0.5);

END LiftOff;

PROCEDURE Hovering(time: REAL); (* Hovering Procedure *)

BEGIN

TRAVEL(time, 0.0, 0.0, 0.0, 0.0);

END Hovering;

PROCEDURE Landing; (* Landing Procedure *)

BEGIN

ACCELERATE(1.0, 0.0, 0.0, 0.0, 0.25);

TRAVEL(19.0, 0.0, 0.0, 0.0, 0.25);

ACCELERATE(1.0, 0.0, 0.0, 0.0, -0.25)

END Landing;

BEGIN

GETATTITUDE(phi, theta, psi);

LiftOff;

Hovering(3.0);

BROADCAST("READYTOLAND");

LandOK := FALSE;

WHILE ~LandOK DO SLEEP() END;

Landing

END Example.

Fig. 22.6 Code for helicopter control

Part C 22.3

372 Part C Automation Design: Theory, Elements, and Methods

Repository of

building blocks

Application in

the family

Fig. 22.7 Software product families

offered by the family. They are then adapted and con-

ﬁgured to match the needs of the target application.

Depending on how the family assets are organized and

implemented, adaptation and conﬁguration can be done

either at the level of the asset models, or at the level of

the implemented assets. Finally, in the integration and

testing phase, the target application is constructed by

assembling the conﬁgured and adapted building blocks

offered by the framework. Usually, some integration

with building blocks that are external to the family is

also required in this phase.

22.3.2 The Software Framework Approach

The product family concept is very general and does not

imply any assumptions about the nature of the build-

ing blocks (Are they components? Procedures? Code

fragments? Design models?) or about their mutual re-

lationships (Can they be used independently of each

Domain model Asset models

Domain

needs

Family

assets

Application

Family creation process

Family instantiation process

Integration

and testing

Requir.

definition

Tailoring

of family assets

Non-family

building blocks

Domain

analysis

Domain

design

Domain

implementation

Fig. 22.8 Development process for software product families

other or are they embedded within a higher-level struc-

ture?). The software framework concept particularizes

the family concept. A software framework [22.16]is

a kind of product family where the reusable build-

ing blocks consist of software components embedded

within an architecture optimized for the target domain

of the framework. Thus, a software framework is a par-

ticular way of organizing the shared assets of a software

product family in the sense that it deﬁnes the type of

building blocks that can be provided by the product

family and it deﬁnes an architecture within which these

building blocks are to be used.

Figure 22.9 recasts Fig.22.7 to illustratethe concept

of software framework. The ﬁgure highlights the fact

that the family reusable assets (the building blocks in

the repository) are now organized as a set of interacting

entities embedded within an architecture that is itself

reusable. The framework approach, in other words, al-

lows the reuse not only of the individual items but also

of their mutual interconnections (the latter being an im-

portant and often neglected added value).

Frameworks are component based in the sense that

the reusable building blocks consist of software com-

ponents. The term component is used to designate

a software entity with the following characteristics:

•

It can be deployed as a stand-alone unit (hence it

owns a clear speciﬁcation of its required interface).

•

It provides an implementation for one or more in-

terfaces (hence it owns a clear speciﬁcation of its

provided interface).

•

It interacts with other components exclusively

through these (required and provided) interfaces.

Part C 22.3

Modeling and Software for Automation 22.3 Reuse-Driven Software Development 373

The architecture predeﬁned by the framework is de-

ﬁned by the set of interfaces that are implemented by

the framework components. Thus, a software frame-

work could also be deﬁned as a product family whose

reusable building blocks consist of components and in-

terfaces. The interfaces deﬁne the architecture within

which the components are to be used. The components

encapsulate behavior that is factored out from all (or at

least a sizable proportion of) applications in the frame-

work domain.

Still another view is possible of what constitutes

a building block of a software framework. This view

sees a building block as a unitofreuse. At its most

basic, the unit of reuse of a component-based frame-

work is a component. This follows from the fact that

one of the distinctive features of a component is that

it is deployable as a stand-alone unit. The components

providedby a softwareframework, however, areembed-

ded within an architecture (which is also deﬁned by the

framework). Hence, users of the framework are likely

to focus their attention not on individual components

but on groups of cooperating components that, taken

together, support the implementation of some function

that is important within the framework domain. In fact,

well-designed frameworks encourage this higher gran-

ularity of reuse by being organized as a bundle of

functionalities that users (the application developers)

can choose to include in their applications. Inclusion of

such functionality implies that a whole set of cooper-

ating components and interfaces are imported into the

application. The true unit of reuse – and hence, accord-

ing to this view, the true building block – is precisely

such a set of components and interfaces.

An example may help clarify the above concept.

Consider a software framework for satellite onboard ap-

plications. One typical functionality that is often found

in such systems is the storage of key housekeeping data

on a mass-memory device. Accordingly, the software

framework would implement default mechanisms for

managing such devices. This would probably be done

through a set of cooperating components and interfaces.

Application developers who need the mass-memory

functionality for their target application and who decide

to implement it with the help of the assets provided by

the framework will import the entire set of components

and interfaces. Use of individual components or inter-

faces is unlikely to make sense because the components

and interfaces are speciﬁcally designed to work together

within a certain architecture. The building block in this

case is the set of components and interfaces that support

the implementation of the mass-memory functionality.

Reusable SW assets

embedded within an architecture

optimized for a target domain

Target application

instantiated

from the framework

Fig. 22.9 The software framework concept

Reusable

components

Application-specific infrastructure

Application based on

library of reusable components

Application-specific

components

Reusable framework infrastructure

Application based on

software framework

Fig. 22.10 Software frameworks and libraries of reusable compo-

nents

Figure 22.10 provides another view of the soft-

ware framework concept that illustrates the difference

from the more traditional forms of software reuse

based on libraries of reusable software components.

An application instantiated from a framework con-

sists of a reusable architectural skeleton which has

been customized with application-speciﬁc components

(right-hand side in the ﬁgure). An application con-

structed with the help of items from libraries of reusable

components (left-hand side in the ﬁgure) consists in-

stead of an application-speciﬁc architectural skeleton

that uses (calls) the services offered by the reusable

components. The framework approach thus places em-

phasis on the reuse of entire architectures.

22.3.3 Software Frameworks

and Adaptability

Software frameworks fall within the reuse-driven

paradigm. To reuse a software asset (a component,

a fragment of code, a design model, etc.) means to use

it in different operational contexts. In practice, differ-

Part C 22.3

374 Part C Automation Design: Theory, Elements, and Methods

Reusable SW assets

embedded within an architecture

optimized for a target domain

Reusable SW assets

are specialized for the

target application

Adaptation

process

Target application

instantiated

from the framework

Fig. 22.11 Software frameworks and adaptability

ent operational contexts will always impose differing

requirements on the reusable assets. Hence, effective

reuse requires that the reusable assets be adaptable

to different requirements. In this sense, adaptability is

the key to reusability and the availability of software

adaptability techniques isthe necessaryprecondition for

software reusability [22.17].

The framework representation shown in the pre-

vious section should therefore be modiﬁed as in

Fig.22.11. The items that are selected from the reposi-

tory are passed through an adaptation or tailoring stage

before being integratedto build the targetapplication. In

the tailoring stage, the characteristics of the reusable as-

sets are modiﬁed to make them match the requirements

of the target application.

Software reuse is perhaps the oldest approach to the

reduction of software costs and has often been tried in

Modifies behavior of

template T by providing

new implementation of

hook H

Modify behavior of

template T by providing

new implementation of

hook H

Reusable class

T(...)

H(...)

Reusable class

Helper h

T(...)

Adapted class

H(...)

Helper

H(...)

Concrete helper_1

H(...)

Concrete helper_2

H(...)

void T(...) {

...

H(...);

...

}

void T(...) {

...

h.H(...);

...

}

Fig. 22.12 Adaptability through inheritance (left) and object composition (right)

the past. Past attempts however had only mixed success

primarily because they either ignored the adaptation

phase shown in Fig.22.11 or because the state-of-the-

practice adaptation techniques available at the time

were not sufﬁciently powerful to model the extent of

variability in the target domain.

A software framework is deﬁned as a repository

of reusable building blocks embedded within an ar-

chitecture optimized for applications within a certain

domain. The quality of a software framework largely

depends on the ease with which the artifacts it of-

fers – components and interfaces – can be adapted

to the requirements of its users. Software frame-

works are therefore categorized on the basis of the

adaptation technology they use. Virtually all frame-

works built in recent years are object oriented in the

sense that they use inheritance and object composi-

Part C 22.3