A THEORY OF SOFTWARE REUSABILITY

M . C . G A U D E L 1 a n d T h . M O I N E A U 1,2

(1) Laboratoire de Recherche en Informatique

Unit6 assocWe au CNRS UA 410

Bat. 490, Universit6 Paris-Sud

91405 ORSAY CEDEX

FRANCE

(2) SEMA-METRA

16 Rue Barb,s

92126 MONTROUGE

FRANCE

A b s t r a c t : Software reusability is a topic of first practical importance. Most of the

current approaches are based on empirical methods and there is no general approach

to this problem. This paper suggests a definition for software reusability based on algebraic specifications and modularity. This criterion is not completely constructive,

but it provides a guideline to find out reusable software components and prove their

reuse. Moreover, we state how to exploit reusability in hierarchical specifications.

K e y - w o r d s : reuse, abstract data types, formal specifications, modularity, PLUSS.

I n t r o d u c t i o n

Software reusability is a topic of first practical importance. Most of the current approaches are

based on empirical methods such as key words or descriptions in natural language. For some specific

fields there exist good libraries of software components, and the description of the component is

given in the terminology of the application area (mathematics, management, . . . ) . However, there is no general approach to this problem.

To reuse a piece of software is only possible if w h a t this piece of software does is precisely stated.

It means that a specification of this software component is available. In this paper, we consider the

case of software components which are formally specified using algebraic specifications. We deal

with the following problem : given a specification SP' to be implemented, and a specification SP of an already implemented software component, is this component reusable for the implementation

of SP' ? Thus we are not considering reusa.bility of software design, or reusability of specification (which are also important problems) but reusability of code. A software component library should,

at least, contain couples of the form . Our claim is that the use of formal and structured specifications is fundamental for reusability. We define rigorously, in the case of algebraic structured specifications, the relations "is reusable for" and "is efficiently

reusable for" between two specifications, the first one being already implemented. Moreover, it turns out that these definitions fit well with the primitives of our specification language.

We consider partial algebraic data types [GH 78,BW 82] and hierarchical specifications [WPPDB 83]. The specification language we use for our examples is PLUSS [Gau 85,Bid 87] which

116

is based on the ASL primitives [Wir 83]. The first part of the paper is a short presentation of these

basic concepts. In par t 2 we define, following [Bid 87], the semantics of the use of predefined

specifications. Par t 3 is an informal introduction of our definitions of reusability. Par t 4 states

precisely these definitions. Part 5 explores the relationship between reusability and hierarchy :

several theorems are given which show that our definitions are compatible both with the classical

definitions of hierarchical specifications and with the practical aspects of software reusability.

Thus this paper suggests a criterion for software reusability which is theoretically founded. This

criterion is not completely constructive, bu t it provides a guideline to find out reusable software

components and prove their reuse. Moreover, the theorems of part 5 state how to exploit reusability

in hierarchical specifications.

1 Bas ic def init ions

A s i g n a t u r e E = (S, F) consists of a set S of sort names and a set F of operation symbols,

for each of which a profile s l . . . s~ ~ s~+l with s~ E S is given.

A E - a l g e b r a A is a family (sA)~es of carrier sets together with a family of partial functions

(fa)fEg , such that the profiles of the operation names f E F coincide with the profiles of the

functions fA. A (total) E - m o r p h l s m ¢ from A to B is a family (¢,) ,es of (total) applications ~, : ~A ~ s B

such that for all operation name ( f : s t . . . s , - -~ s) E F and all objects al E s¢ . . . . . a , E s A the

following holds : if fA(al . . . . . a,,) is defined then ¢~(fA(al . . . . . an)) = fB(¢ , , (a l ) . . . . . ¢ , . ( a , ) ) . Two E-algebra A and B are isomorphic, writ ten A ~- B, iff there is an isomorphism (bijective

E-morphism) between them. T~ is the well-known t e r m - a l g e b r a . The interpretation t A of a term t in a E-algebra A is

specified by : - if t = e E F, then t A =de/c A. - if t = f t l . . . t , , then t A =d¢y fa( t¢ . . . . . t A) provided that all the interpretations t a and

f ( t ¢ , . . . , t~) are defined; otherwise t A is undefined.

Tsuv is the free E-algebra of terms with variables in V.

PALG(E) is the category of the partial ~-algebras with E-morphisms, P G E N ( E ) is the cat-

egory of finitely generated E-algebras (i.e. a l l elements of the carrier sets can be obtained by the

interpretation t A of a term t E Tz). A spec i f i ca t ion S P = (E,E) consists of a signature E and a set E of positive conditional

axioms on E : ¢1 A . . . A ~ , ==~ ¢,+x, where ¢i are either equations (tl = t2) or definedness

predicates D(t) where tl , t2 and t are terms of Truv (a E-algebra A satisfies D(t) iff t A is defined

for all assignments of its variables). P A L G ( S P ) is the category of all the models of S P (the E-algebras satisfying all axioms of

E). P G E N ( S P ) is those of finitely generated models. Tsp is the initial model of P A L G ( S P ) and

P G E N ( S P ) . If A E P A L G ( S P ) , IA is the unique E-morphism IA : Tsp ---* A.

We use the abbreviation SPo C__ S P for E0 C E (So C_ S and F0 C F) and E0 C E. We write

S P = SPoU A S P for E = EoU AE (S = SoU A S and F = FoU AF) and E = EoU AE" A S P is

called an e n r i c h m e n t . Note that these definitions are purely syntactic (union of presentations). If SPo C S P , we note U : PALG(E) ~ PALG(Eo) the fo rge t fu l f u n c t o r defined by :

s U(A} = s A for s E So and re(A} = fA for f E Fo. U(A) corresponds to the Eo-reduct of A as

defined in [WPPDB 83].

t t 7

As mentioned in the introduction, we will deal with hierarchical specifications denoted by

S P = SPo + A S P (this corresponds to the ENRICH construct of ASL).

2 Hierarchical models, implementations, realizations

2.1 Hierarchical models

As a preliminary to any study of reusability, it is necessary to define what is a correct im-

plementation of a specification. This definition is dependent on the semantics considered for the

specifications, i.e. the models associated with the specification. There are several approaches :

1. the models are those isomorphic to Tsp; such a semantics is called i n i t i a l s e m a n t i c s .

2. the models are those isomorphic to the terminal algebra; such a semantics is called t e r m i n a l

s e m a n t i c s .

3. the models are all the models in PALG(SP) , such a semantics is called " loose" s e m a n t i c s .

4. a loose semantics may consider only finitely generated models, those in P G E N ( S P ) [WPPDB 83].

Loose semantics makes it possible to give a simple definition of implementations [SW 82] :

an algebra is an implementat ion of a specification SP, if, via some forgetting, restriction and

identification, it is a model of SP,

However, loose semantics without hierarchy introduces trivial algebras among the models :

the solution is to start from some basic specifications (such as booleans~ naturals) with initial

semantics, and to consider enrichments of specifications with hierarchical constraints.

Most of the time, it is convenient to consider finitely generated models : all the values are

denotable by a term and thus are computable in a finite number of steps. Non finitely generated

models are sometimes useful, bu t as we are concerned with reusability, it seems sound to choose

finitely generated models : it means that the specification of a software component is supposed to

mention all the functions of this components.

Thus we consider that the semantics of a specification SP is a subclass of P G E N ( S P ) noted

H M O D ( S P ) of hierarchical finitely generated models, where the hierarchical constraints ensure

that any model (implementation) of S P = S P o + A S P restricts into a model of SPo. More precisely the forgetful functor from S P into SPo applied to a hierarchical model of SP gives a hierarchical model of SPo.

D e f i n i t i o n 2.1 The class of the h i e r a r c h i c a l m o d e l s of a specification is :

- HMOD(SPo) = {Tsp,} if SPo is a basic specification (Zo, Eo). - H M O D ( S P ) = {A C P G E N ( S P ) I U(A) E HMOD(SPo)} if S P is a hierarchical specifi-

cation : S P = SPo + A S P (U is the forgetful functor from PALG(E) into PALG(Eo)).

H M O D ( S P ) is a full sub-category of P G E N ( S P ) , The existence of initial or terminal model is not ensured ( Tsp is not always a hierarchical model [Ber 87]).

Of course, the class of models of a specification depends of its hierarchy; for instance :

HMOD((SPo + ASP1) + ASP:) C_ HMOD(SPo + (ASPI u ASPs)) But the reverse is not always true. This will turn out to be quite important for reusability aspects.

We do not restrict the class of models to minimally defined ones [BW 82]. It means that an

operation can be implemented in such a way that it is more defined than what is specified. This seems interesting in the framework of reusability.

118

2.2 Realization

As stated in introductlon~ we consider couples , where the pro- gram is correct with respect to the specification. In the algebraic specification framework

[EKMP 80,SW 82,BBC 86] it means that the program is a model of the specification modulo

some forgettings, restrictions and identifications.

However, as soon as software is modular, we are concerned mainly with pieces of software

which use other pieces of software. For instance, a module implementing a specification of the sets

of integers includes some code for the operations insert and is-a-member, and uses some already

existing implementat ion of the operations on integers. Thus, given a structured specification

SP = SPo + A S P we call a "realization" of A S P a piece of software such that when coupling it with a hierarchical model (implementation) of SPo, one gets a hierarchical model of SP. In order

to be reusable, a realization of A S p must accept any model of SPo : no assumptions can be made on the implementat ion of SPo. This property is not only important for reusability, but also in large software projects where several programmers are working concurrently on various modules.

These considerations lead to the following definition :

D e f i n i t i o n 2.2 A r e a l i z a t i o n of enrichment A S P of SPo is a functor A from HMOD(SPo)

into HMOD(SPo + ASP) such tha$ : VAo e HMOD(SPo), U(A(Ao)) ~- Ao. The class of realizations of A S P on the top of SPo is noted REALspo(ASP).

As stated above, this functor must be conservative. For instance, if SPo is an implementation of the integers by 8 bits strings, A will provide an implementat ion of SP where integers are implemented by 8 bits strings, not by 16 bits strings : there is no recoding of the integers by the

realization of~ for instance, the sets of integers.

Composit ion of realizations works well :

T h e o r e m 2.1 Let SP1 = SPo + ASPI, SP2 = SP1 + ASP~ and ASP3 = ASP1 u ASP2. IrA1 E REALsp,(ASPI) and A~ C REALspi(ASP2), then A2 o A~ E REALsp~,(ASPs).

P r o o f : The forgetful functor 0"3 from ALG(SPs) into ALG(SPo) is equal to UI o Us where U1 et U2 are the forgetful functors from ALG(SP1) into ALG(SPo) and from ALG(SP2) into ALG(SPI). Thus VAo e HMOD(SPo) : U3(A2 o AI(Ao) ) = U1 o (U2 o A2) o AI(Ao) ~- U1 oAI(A0) - A0. []

It is important to note that there does not always exist a realization for a ASP. If A S P removes some models from HMOD(SPo), assuming for instance some implementation choices of SPo, there exist no realization. However SP = SPo + A S P may have hierarchical models, thus global implementations. The existence of a realization means that the implementation choices in

A S P and in SPo are completely independent.

3 W h a t is r e usab i l i t y ?

3.1 I n t u i t i v e i n t r o d u c t i o n

This part is an intuitive introduction to the formal definitlons which are given in part 4.

Let us consider an example : suppose we have in a software components library a program

corresponding to the specification INT of figure 1; we want to develop a program corresponding

119

SPEC : NAT

USE : BOOL

SORT : Nat

OP :0 , s + , , , fact, <

AXIOMS : 0 + y = y s(x) + y = s ( x + y )

0 * y = 0

s(x) * y = ( x , y ) + y fact(O) = s(O)

fact(s(x)) = s(x) * fact(x)

0 < 0 = t rue s(x) < 0 = false

0 < s(x) = t rue

s(x)

S P

120

P - S ~

S P'

Figure 2: Scheme of reuse.

functions of SP, and hidden functions are forgotten : VA~ e HMOD(SP~), U'(A~) • HMOD(SP')

4. In order to ensure that sorts and operations of Err are actually reused from SP, Z~ must be a renaming of a subsignature of E.

However condition 3 is too restrictive in some cases : if we consider the example of figure 1,

implementing NAT by reuse of INT, the result of the forgetful functor is not a (hierarchical)

finitely generated model of NAT, since the negative integers are kept. Thus we need a "stronger"

forgetful functor than the classical one : by the way, it is a forget-restrict functor in the sense

of [EKMP 80,SW 82]. Other problems arise if some functions are more defined in SP than in SP t. Part 4 gives the corresponding definitions.

3 .2 R e u s a b i l i t y v s a b s t r a c t i m p l e m e n t a t i o n

Reuse is a special, simpler case of abstract implementation of algebraic data types

[EKMP 80,SW 82,BBC 861. In this paper we are concerned by direct reuse. It means that the

"abstraction functions" of [BBC 86] or the "copy functions" of [EKMP 80] are just identities, and

that the "identify function" is no more necessary to get a model of SP ~.

4 R e u s a b i l i t y : d e f i n i t i o n s

As mentioned above, we have a reusability definition in three steps : extension, equivalence

modulo a renaming, and forget-restricting. We study each of them successively.

4 . 1 E x t e n s i o n

The extension phase consists in giving an enrichment ASP1 on the top of SP, which must be

realizable :

Def in i t ion 4.1 ASP1 is real izable on the top of SPo iff REALspo(ASP) # 0.

This property is noted SPo ~ SP or SP = SPo • ASP.

Remark .

REALsp,,(ASP) is the semantics of the USE construct of the PLUSS specification lan- guage [Bid 87]. PLUSS makes a distinction between the USE construct, which corresponds to the modular structure of the software, and the ENRICH construct which expresses the incremen-

tal development of specifications and which has the same semantics as in ASL.

121

S P = SP0 (9 A S P corresponds to the following construct in PLUSS :

SPEC : SP

USE : SPo A S P

Realizability is a transitive relation :

T h e o r e m 4.1 If SP1 = SPo (9 ASP1 and SP2 = SP1 (9 ASP~ then SPa = SPo (9 (ASP1 U ASPz) .

Proof : Let ASP3 = ASPI u ASP2. One can take A t E REALspo(ASP1) and A2 e REALsp,(ASP2). From theorem 2.1, A2 o ~1 E REALspo(ASPa), and thus REALsI, o(ASP3) ¢ O. []

Note that H M O D ( S P a ) is generally different from H M O D ( S P 2 ) . SPz and SPa are equal if

they are considered as non hierarchical specifications, but are different as hierarchical ones.

The definitions above does not cope with parameterization : A may perfectly take into account

some properties of the specification SPo. It must not take into account properties of the implemen-

tat ion of SPo. Parameterized specifications and generic modules introduce additional difficulties

and are not considered in this paper.

4 . 2 E q u i v a l e n c e o f h i e r a r c h i c a l s p e c i f i c a t i o n s m o d u l o a r e n a m i n g

A renaming between two signatures Et and E~ is a signature isomorphism p : E1 - - ~ E2

[EM 85]. Some authors define renamings as injective signature morphisms [Pro 82]. Since we are

interested in equivalence of specifications, we consider bijective renamings. Signature renamings

easily extend into term renamings, algebra renamings, and (hierarchical) specification renamings.

The classical notion of specification equivalence is that S P and SP ' are equivalent iff E = Et

and Tsp ~ Tsp,. For hierarchical specifications, the definition is :

D e f i n i t i o n 4.2 : h i e r a r c h i c a l e q u i v a l e n c e .

Two basic specifications SPo and SP~ are hierarchically equivalent iff Eo = E~o and Tsp. ~ Tsp,~.

Two hierarchical specifications S P = SPo + A S P and S P t = SP~ + A S P ~ are hierarchically

equivalent i f f :

- SPo and SP~ are hierarchically equivalent

- A E = AE I.

- H M O D ( S P ) = H M O D ( S P ' ) .

Hierarchical equivalence is denoted by S P =- S P t. It means that two hierarchical specifications

are hierarchically equivalent iff they have the same (unfolded) signature, the same hierarchy, the

same hierarchical models. Only the axioms can differ.

P r o p o s i t i o n 4.2 Let S P = SPo + A S P and S P ~ = SP~ + A S P ~. I] SPo - SPg, A Z = AE ~ and

TsPo "~ Tspj, then H M O D ( S P o + ~xSP) = H M O D ( S P g + ASP ' ) and thus S P - S P t.

Proof : by induction on the hierarchy.

From the definitions above, it comes :

D e f i n i t i o n 4.3 Two hierarchical specifications S P and SP ' are h i e r a r c h i c a l l y e q u i v a l e n t

m o d u l o a r e n a m i n g p ( S P p=- S P ' ) iff p (SP) =- SP' .

122

4 . 3 F o r g e t - r e s t r i c t f u n c t o r

As noted above, we need a forget-restrict functor in order to get finitely generated models of

SP' (see fig. 2).

Def in i t i on 4.4 Let SP' C SP~ two specifications. The f o r g e t - r e s t r i c t f u n c t o r V : PALG(SP~) ~ PGEN(SP') is defined by :

• VA e PALG(SP[), - VS e S ' , 8 V(A) = [ IuCA}I , ( sTsp ' ) .

- V ( / : s l . . . s , ~ s ) e F',

/d(A}(al ..... an) iffU(A)(a, .... ,an.) e S V(A) fV(A) (al . . . . a ,) = undefined otherwise

• V¢: A ~ B, V(¢) is the restriction of U(b) to V(A).

As defined above, IV(A) is the unique morphism from Tsp, into U(A).

V(A) is the finitely generated part of U(A) with respect to E' (s v(A) = {a E s A] 3t E TsP,, a = ta}). By the way, the sorts of SP' are subsorts of those of SP[ [FGJM 85]. It 's easy to prove that V is a functor from PALG(SP[) into PGEN(SP') , and that composition of forget-restrict functors works well : if V2 is the forget-restrict functor from SP~ to SP1 and V1 is the forget-restrict functor from SPt to SPo then VI o V2 is the forget-restrict functor from SP~ to SPo.

Besides, by definition, the forget-restrict functor restricts the domain of functions in such a

way that only finitely generated objects can be got as result.

4 . 4 R e u s a b i l i t y

We now put together the three steps and define reusability.

Def in i t ion 4.5 SP is r e u s a b l e for SP' w . r . t , a s i g n a t u r e ZJr m o d u l o a r e n a m i n g p (SP p'--~ SP'[E',]) iff there exist two specifications SP1 and SP~ such that:

[R,] SP, = S P • a S P , .

[R2] S P, p==- S P~.

JR3 t S P' C_ S P I.

[R4a] VA~ E HMOD(SP[), V'(A~) E HMOD(SP').

[RsI s', c__ s' and p-l(~,) c S.

where Y' is the forget-restrict funetor from PALG(SP~) into PGEN(SP') .

Note that in A~, some functions can be more defined than what is required by SP'. It does not matter since HMOD(SP') is not limited to minimally defined models (as defined in [BW 82}).

Def in i t ion 4.6 SP is eff ic ient ly r eusab l e for SP' w. r . t , a s i g n a t u r e E~ m o d u l o a r e n a m - ing p (SP p,~z Sp'[~tr}) iff there exist two specifications SP1 and SP~ such that:

JR1] SP1 = SP @ ASP1.

JR2} s P~ p--- s P~.

123

[R3] SP' C_ SP~.

[R4b] VA i E HMOD(SP~) , U(AI) e H M O D ( S P ' ) .

[as] E', c r? and p-l(~,) c ~.

where V # is the forgetful funetor from PALG(SP~) into PALG(SP ' ) .

The intuitive notion behind efficient reusability is that the carriers of S P are finitely generated with respect to SP' : there are no useless values.

At the practical level, our definition of reusability in three steps will result in specifications of

the form :

S P E C : X F O R G E T . . .

( U S E : SP ASPI) R E N A M I N G . . . I N T O . . .

E N D X

Note that X is an abstract implementat ion of SP' : H M O D ( X ) C HMOD(SP ' ) .

The second step (equivalence modulo a renaming) can be skipped : SP1 and SP; can be embedded in an unique but more complex specification SP2 :

T h e o r e m 4.3 S P is reusable ( resp. efficiently reusable} for SP' w.r.t. E'r modulo a renaming p

iff there exists a specification SP2 such that :

[1] SP2 = S P ~ ASP2.

[2] SP' C p(SP~).

f3] VA2 E HMOD(SP2) , V'(p(A2)) E H M O D ( S P ' ) (resp. U'(p(A2)) E HMOD(SP' ) } .

I4] r? c_ r~, and p-'(~',) c_ ~.

P r o o f : ~ Take SP1 : SP~ and SP~ = p(SP2). ==~ Take SP2 = (~1, E1 U p-I(E~)). Since SPI p=- SP~ the axioms or SP~ (renamed by p- l ) do not change the hierarchical models of SP1. []

This approach is less close to reality, but easier to deal with theoretically. Consequently, in

the rest of this paper we will consider reuses in two steps. Besides, we ignore renaming, since

it is only a mat te r of syntactic sugar. However, the results still hold in the case of reuse with a

renaming. Reusabili ty and efficient reusability without renaming are noted ~ and ,'~. We will

denote a specific reuse of S P for S P ' by the scheme : S P --~ SP1 .~v Sp,[z,r] ' and an efficient reuse by S P ~ SP1 ~tr Sp,[z,r]"

P r o p e r t i e s .

- if S P is efficiently reusable for SP' w.r.t. ~'r then S P is reusable for SP' w.r.t. Z'.. - if S P ~ SP' then S P is efficiently reusable for SP' w . r . t . E .

124

E x a m p l e .

The following example i l lustrates these definitions. We consider four specifications and look at

the re la t ions of reusabil i ty be tween them.

SPEC : NAT1

USE : BOOL

SORT : Int

OP : 0, s, + , *

AX : ...

SPEC : NAT2

USE : BOOL

SORT : Int

OP : 0, s, _<

AX : ...

SPEC : INT1

USE : BOOL

SORT : In t

OP : 0, s, p

AX : . .

SPEC : INT2

USE : BOOL

SORT : Int

O P : 0, s, p,

125

S P SPEC : NAT

U S E : BOOL

SORT : Int

OP : 0, suet ,

AX : . . .

S p t

SPEC : LIST

U S E : NAT

S O R T : List

OP : nil, cons, car

error

AX :

car (cons(n,l)) = n

car (nil) = error

SP~

SPEC : SP1 U S E : BOOL

S O R T : Nat, List

OP : 0, succ, error

nil, cons, car

AX :

car ( c o n s ( n , l ) ) = .

car (nil) = error

S P is reusable for S P ~ w.r.t. ~NAT, but SPo is not reusable for S P t w.r.t. ~BOOL via SP1. For the Et-algebra A1 such that Int A' = N u {error} and (error

126

5.1 : 5.2 : 5.3 : 5P~ SP~

S P' S P'

sP I SPo SP~

S .pll aPl

S p t SP

Figure 3: Situations of fact 5.1 and theorems 5.2 and 5.3

P r o o f : See [GM 87]. O

As noted by a referee, this theorem is a generalization of the extension lemma given in [EM 85]

for equational specifications and total, initial algebras.

Figure 3 shows the difference between the situations studied in fact 5.1 and theorem 5.3. By

the way theorem 5.3 deals with another kind of reusability : those of the realization of ASP".

Moreover it shows that ASP" can be realized independently of the reuse done for SP'.

The proof of the theorem 5.3 is constructive : it shows how to get a realization of ASP" on the top of SP1 given a realization of A S P " on the top of SP' : just putting together the carriers and the operations of A1 (which is an implementation of SP1) and of A". Practically it corresponds to putting together type declarations and code of operations.

This result is important : it allows to consider a program as a set of pieces, the bodies of which

can be replaced or developed in an independent way. For instance, let us suppose that we have to

develop the components below :

SPEC : L_NAT [SPEC : NAT l

USE : NAT 1 USE : BOOL

SORT : List I SORT : Nat

OP : nil, cons, . . . OP : 0, succ, +, *, <

AX : . . . AX : . . .

and we already have programs implementing :

SPEC : L_NAT1

USE : NAT1

SORT : List

OP : nil, cons, . . .

AX : . . .

SPEC : NAT1

USE : BOOL

SORT : Nat

OP : 0, suet, <

AX : . . .

SPEC : NAT2

USE : BOOL

SORT : Nat

OP : 0, succ~ -F, *, ~_

AX : . . .

We know, from theorem 5.3, that it is possible to replace the NAT1 component by the NAT2

component in L_NAT1, and to use LANAT1 (with NAT2) to implement L_NAT. This avoids to

implement addit ion and multiplication on naturals.

R e m a r k . The condition ~ I n A E " = 0 is essential; it is not a problem to satisfy it using appropriate

renaming of what is forgotten from SP1 to SP'. []

127

SFEC : SET

USE : NAT

SORT : Set

OP : empty, insert, is-in

AX :

(1) is-in(x,empty) = false (2) x = y =~ is-in(x,insert(y,s)) = true

(3) x # y ==~ is-in(x,insert(y,s)) = is-in(x,s)

(4) is-in(x,s) = true ~ insert(x,s) = s

(5) (is-in(x,s) = false) A (x

128

R e m a r k .

A discriminant predicate is the characteristic function of the finitely generated part of s v(A).

If SP and SPo have free generators C and Co (Co C C), the definition of the p~ predicates is

straightforward :

- Ps(eo) = true for all constant (co :---~ s) E Co.

- p ,~(= , ) = t rue A . . . A p , o ( x , ) = trn~ ~ p , ( f o ( ~ , . . . :~,,)) = true for aH (fo : s , . . . s,,

s) ~ c 0 .

- p . ( c ) = f a l s e for all c o n s t a n t (e : - - ~ s) C C \ C o .

- p , ( f ( x l . . . x n ) ) = false for all ( f : s l . . . S n ~ s) C C\Co.

If it is not the case, the definition of these predicates is highly dependent on the rest of the

specification. []

Def in i t ion 5.:1 : ex tended en r i chmen t .

Let SPo C SP1 be two specifications, A S P an enrichment of SPo, such that E1N AE = O, and

(P,),es~ the diserimant predicates between SPo and SPI.

An extended enrichment of A S P from SPo to SPx, is the enrichment A S P = (AE, A'E U Paz)

where :

* Pa~ s)

, A E

is the set of axioms : D ( f ( x l . . . . . xi . . . . . x , ) ) ~ p,,(xi) = true, where ( f : s l . . . s . - -~

A F and s~ E So.

is obtained from A E by the following transformations :

- If an axiom is of the f o r m : 0(01) A . . . A D(O,~) A (tl = t~) A . . . A (t~ = t~) ~ (t = t'),

it b e c o m e s : ~ A D ( O , ) A , . . A D(O~,) A ( t , = t'~) A . . . A (t~ = t',) : = * (t = t ') w h e r e :

gP = A,[p,,(O,) = true] A Aj[ps~(t/) = true A p,,j(t~) = true] A [p~(t) = true A p~(t') = true]

is the sort of tj et F i, s is the sort of t and t ~. Moreover, in order (si is the sort of 0~, sj to simplify the transformation, we define, for s E A S , Ps(X) = true, Vx; these predicates

are useless but for the transformation.)

- If an axiom is of the form :

D(O,) A . . . A D(Om) A (t, : t~) A .. . A (t,~ : t~) ~ D(f( t~ . . . . . tg)), it becomes:

. . . D~ rQ" . . . . t~)) where: C A D ( O , ) A . . . A D ( O , ~ ) A ( t l = t ~ ) A A ( t , , = t ~ ) ~ , , ~ 1,

¢ = A,[p~,(O,) = true] A Aj[p,~(ti) = true A p~}(t)) = truel A Ak[P,,(t~) = true]

(with the same conventions as above, and s~ is the sort of t~)

The P~r axioms express that the operations of A S P , when SP1 is used instead of SPo, must

be restricted to the parts of the sorts of SPI which are finitely generated by Z0. Similarly, the @

premisses added to the axioms AE express that these axioms are valid on these parts of the sorts.

Examples of this transformation can be found in [GM 87].

We have a theorem similar to theorem 5.3 :

T h e o r e m 5.4 Reusability of enrichment.

H M O D ( S P 2 ) V~' . H M O D ( S P " )

H M O D ( S P , ) V] . H M O D ( S P ' )

129

Let S P , SPI et S P ' be specifications such that S P ~ SP1 .. v S I ~ (SP is reusable for S P s

w.r.t, some Z~), and SP" = $1 ~ ~ A S P " , with ~ t f3 AF," = 0.

Then SP~ = SP1 $ A S P " , and/or all realization A E R E A L s e , ( A S P " ) , there is a realization

E R E A L s p I ( ~ , such that the diagram above commutes, i.e. :

VAx e HMOD(SP1) , V~' o "A(At) "~ A o V;(A1)

P r o o f : See [GM 87]. []

C o n c l u s i o n s a n d fur ther re searches

We have given a criterion for "efficient" software reusability, and proved that this notion of

reusability fits well for hierarchical specifications. We have introduced "non efficient reusability"

(such as integer for naturals) in order to be more permissive. However, the results on this kind of

reusability are slightly disappointing since they seem rather complex to apply.

It is interesting to note that non efficient reusability is not exactly what we have called "direct

reusability", and is a step forward implementation. These results enforce our opinion that the

kind of reusability we are studying, i.e. code reusability using its specification, should be done on

as-it-is bases whenever possible. This is quite coherent with practice.

This study was devoted to structured specification and modular programs. It is clear that it

must be extended to parameterized specifications and generic programs.

A c k n o w l e d g e m e n t s

Our thanks to Michel Bidoit and Giites Bernot for numerous fruitful discussions and friendly

encouragements.

This work is partially funded by ESPRIT (Meteor Project) and by the PRC-Greco "Program-

motion et outils pour l'intelligence artificielle'. Th. Moineau's grant is funded by Sema-Metra.

R e f e r e n c e s

IBBC 86]

[Ber 87]

ISid 871

[BW 82]

[EKMP 80]

G. Bernot, M. Bidoit and C. Choppy, "Abstract implementation and correctness proofs", in Proe. 3rd STACS, Jan. 1986, Springer-Verlag LNCS 210, Jan. 1986.

G. Bernot, "Good functors ... are those preserving philosophy ! ' , in Proe. 2nd

Summer Conference on Cotegory Theory and Computer Seienee, Edinburgh,

Sept. 1987.

also LRI report No. 354, June 1987.

M. Bidoit, "The stratified loose approach : A generalization of initial and loose semantics", to appear.

M. Broy and M. Wirsing, "Partial abstract types", Aeta Informatiea, No. 18,

1982.

H. Ehrig, H. Kreowski, B. Mahr and P. Padawitz, "Algebraic implementation of abstract data types", Theoretical Computer Science, Oct. 1980.

130

[EM 85]

[FGJM 85]

[Gnu 851

[GM 871

[GH 781

[Pro 821

[SW 821

[Wir 831

[WPPDB 83}

H. Ehrig and B. Mahr, "Fundamentals of algebraic specification", Springer Verlag, Berlin-Heidelberg-New York-Tokyo, 1985.

K. Futatsugi, J.A. Goguen, J-P. Jouannaud and J. Meseguer, "Principles of OBJ2", in proe. 12th A CM Symposium on Principles of Programming Languages, Jan. 1985.

M.C. Gaudel, "Towards structured algebraic specifications", ESPRIT'85 - Status Report, Part I, pp. 493-510, North Holland, 1986.

M.C. Gaudel and Th. Moineau, "A theory of software reusability", LRI report No. 380, Oct. 1987.

J.V. Guttag and J.J. Horning, "The algebraic specification of abstract data types." Aeta Informatica, No. 10, 1978.

K. Proch, "ORSEC : Un Outil de Recherche de Sp6cifications Equivatentes par Comparaison d'exemple", Th6se de 3eme cycle, Nancy I, Dec. 1982.

D. Sanetla and M. Wirsing, "Implementation of parametrized specifications", Re- port CSR-102-82, Department of Computer Science, University of Edinburgh.

M. Wirsing, "Structured a|gebraic specifications : a kernel language", Habilitation Thesis, Technische Universit~it Miinchen, Sept. 1983.

M. Wirsing, P. Pepper, H. Partsch, W. Dosch and M. Broy, "On hierarchy of abstract data types", Acta Informatica, No. 20, 1983.