Proof Preservation in Component Generalization - CiteSeerX

0 downloads 0 Views 260KB Size Report
Formal speci cations can provide signi cant support for software component ... statement of semantic properties of a component that are considered \impor- ... the framework of this work, presenting the used notation; in Section 3 we de ne ... and semantic; in Section 5, we show how to generalize in such a way that known.
Proof Preservation in Component Generalization Anamaria Martins Moreira Universidade Federal do Rio Grande do Norte | UFRN Departamento de Informatica e Matematica Aplicada | DIMAp Campus Universitario de Lagoa Nova 59072-970 Natal, RN, Brazil URL: http://www.dimap.ufrn.br/~anamaria

* Contact author

email: [email protected] phone: +55 842153814 fax: +55 842153781

Other informations

Stream: Foundations and Methodology Areas: Fundamentals, Languages and Tools Mini-track: AMAST

Proof Preservation in Component Generalization Abstract. Formal speci cations can provide great support for software

component reuse, as they allow tools to \understand" the semantics of the components they are manipulating. In our work we propose the theorectical basis of a tool for the generation of reusable components by generalization (parameterization) of existing ones. The underlying idea is, given a component and a set of semantic properties that it satis es and that we want to preserve, to nd a parameterized component satisfying the following conditions: the original component is one of its possible instantiations, and we can guarantee that any of its instantiations satisfy the stated properties. In this paper we concentrate on the problem of preserving proofs of these properties in the generalized component. This technique provides a simple way to nd sucient conditions for the preservation of the corresponding properties.

Keywords. algebraic speci cations, component parameterization and reuse, proof generalization.

1 Introduction Formal speci cations can provide signi cant support for software component reuse, as they allow tools to \understand" the semantics of the components they are manipulating. Tools that manipulate programing code can easily deal with sintactic features of components (e.g., renaming operations) but usually have a hard time when it comes to semantics. Formal speci cations, with their \simpler" and precisely de ned semantics and associated veri cation tools, contribute to the veri cation of the validity of semantic properties of components in the di erent steps of the reuse process. For instance, they can be of great help on the generation of reusable components through the parameterization of more speci c ones, supporting the process of creation and maintenance of libraries of reusable components. Among speci cation formalisms, algebraic speci cations are well suited for our work, being adequate to the speci cation of components and given their strong links with the object oriented programming paradigm, largely associated with reuse in the literature. Works associating algebraic speci cations and object orientation are many (e.g. [18, 14]), and we can hope to use them in a future application of the theory that we present here, specially concerning implementation of the speci cation components in the library. Additionally, the genericity mechanism encountered in most algebraic speci cation languages provides great

exibility in the desired abstraction level and the means to require semantic properties of potential instantiation parameters, facts that are of the greatest importance to our work. In this paper, we concentrate on the generalization of algebraic speci cation components by their parameterization. The main diculty when trying to generalize by parameterization is to identify the \good" level of generalization for

each component. Highly speci c ones have small chances of being reused, but on the other hand, if a component is too general, its reuse will often be useless. Formal speci cations can contribute to the solution of this problem by the statement of semantic properties of a component that are considered \important" somehow (the component would lose its raison d'^etre if these properties were not satis ed). So, we propose means to identify the requirements that a formal parameter should satisfy in order to preserve part of the original component semantics (a set of stated properties) in the generalization. To reach this goal, we consider proofs for these properties in the original (non-generalized) context and identify the conditions under which these proofs are reproducible in the generalized context. When these known proofs are rewrite proofs, a set of equations can be extracted from them and added to the formal parameter so that they are preserved in the process. This simple technique provides sucient conditions for the validity of the considered properties in the models of the more general speci cation, with the advantage of being easily computed by a simple algorithm. Brie y, this paper proposes a contribution that can be applied to the area of programming for reuse. However, instead of creating components explicitly for a future reuse, we propose to create reusable components from an already developed application. Both choices have their pros and cons, and the second one presents as main advantage that the generated component has already been used at least once (in its original version), as advocated by M. Wirsing in [21]. In this case, the main diculty is to transform components that were developed for a particular application into e ectively reusable components. This must be done through their generalization, and this is where our work ts. This paper is structured as follows: in Section 2 we give a brief overview of the framework of this work, presenting the used notation; in Section 3 we de ne a generalization by parameterization operator and its dual, the instantiation operator1; we then present in Section 4 two kinds of generalization | syntactic and semantic; in Section 5, we show how to generalize in such a way that known rewrite proofs for the semantic properties we want to preserve are still valid after generalization; and we nally conclude in Section 6.

2 Framework and Notation In this section we present the framework of this work with the main goal of de ning the notation we use in the following. In the examples we use a language which is strongly inspired from the LPG language [5], a logical and functional speci cation language supporting genericity and Horn clause logic with disequations. However, we only consider its functional part, implemented through conditional equations and what we propose here could be applied to most existing algebraic speci cation languages (e.g. OBJ3 [13] or Larch [9]). 1

We only present here the generalization and instantiation operators. Other operators have been de ned in [17], and are similar to many others found in the literature (e.g. [19, 20, 3]).

The syntax of our speci cations is based on multi-sorted signatures ( = (S; Op)),  -terms (noted by small s; t) and  -equations (noted by small e). Equations may be simple (t1 == t2 ) or conditional (t1 == t2 if e1 ^ ::: ^ en ). The semantics of our speci cations are classes of  -algebras that verify a given set of equations (noted Eq). The class of all algebras that satisfy Eq is noted Alg(; Eq) and the isomorphic class of initial  -algebras is noted Init(; Eq). Speci cation components allow us to de ne classes of algebras ranging from Init(; Eq) to Alg(; Eq). It is often the case that a speci cation is seen as a collection of components connected by dependency (inclusion) links. Here, we abstract from the concrete structure of this component graph to concentrate on the class of models it de nes, much as we if were working with equivalence classes of component graphs modulo the corresponding classes of models. We then call speci cations the abstract entities consisting of a signature and a class of models over this signature (signature, class of models). These abstract entities are realized by their concrete counterpart, speci cation components, as described below. In our language, we have two kinds of components, distinguished by their semantics: types and properties2 . In both cases, they are composed of:

{ a local part | sorts and operators de ned by the component through local equations. { an imported part | speci cations realized by other components and used in the speci cation of local objects. Imports may be xed abstract data types or formal parameters.

A component can be represented by

Co = (hspI ; spF i; Co ; Eq) where is T or P, depending on the intended component semantics (type or property); spI , the xed imported speci cation; spF , the formal parameter speci cation; Co, the component signature (local + imported), and Eq, the equations introduced in the component. Component semantics is de ned through free and forgetful functors in a usual way. Models for a type component are freely generated from the imported models, provided that the persistence condition is satis ed. Models for a property component are the models of new presentation (Co ; Eq) that can be forgotten into one of the imported models. Through these semantics, a class of models (modCo ) can be assotiated to a component Co. The speci cation realized by Co is then (Co ; modCo ). Because each component realizes one unique speci cation, we often use the name of a component to designate the corresponding speci cation. It is furthermore important to notice that these semantics are such that the theory assotiated to each component (i.e., the set of equations that are valid in all of its models) always includes the theory corresponding to imported 2

These components can be found with slight variations in most algebraic speci cation languages, e.g. Objects and Theories in the OBJ family of languages.

speci cations (either xed imports or formal parameters). This monotonicity is essential to the validity of the work in this paper. Finally, we have speci cation morphisms, derived from signature morphisms as usual: given speci cations sp1 = (1 ; mod1 ) and sp2 = (2 ; mod2 ) and a signature morphism m : 1 ! 2 , there is a derived speci cation morphism m from sp1 to sp2 if 8A 2 mod2 ; Um (A) 2 mod1 . When there is a speci cation morphism from a property CoP to an abstract data type CoT , we say that CoT is a model of CoP , although there is a class of models associated to CoT .

3 Instantiation and Generalization In this section, we formally de ne the generalization and the instantiation operators, which are the keys for preparing a component to be kept in a library in order to be reused and its actual reuse, respectively. Their main e ect is to transform xed initially interpreted input speci cations into parameters (generalization) and vice versa (instantiation), \enlarging" (respectively, \reducing")3 the class of models associated to a speci cation. To present things in an order of increasing complexity, we start by the best known instantiation operator.

3.1 Instantiation The main e ect of the instantiation operator is to substitute the formal parameter of a generic component by a more specialized speci cation. This speci cation may be a xed import speci cation (which may itself be a generic one) or a more specialized formal parameter. The instantiation operator (instantiate) is de ned by Co00 = instantiate Co by Co0 via m = if Co = T (hspI ; spF i; Co; Eq) ^ Co0 = 0 (hsp0I ; sp0F i;  0 ; Eq0 ) realizes sp0 ^ m 2 HomSpec(spF ; sp0 ) then if 0 = T then T (hm(spI ) [ sp0 ; sp0F i; mi (Co) [  0 ; m#i (Eq)) else T (hm(spI ); sp0 i; mi (Co ) [  0 ; m#i (Eq)) else ? That is: if Co is a generic type, and if the proposed morphism m is a speci cation morphism from the formal parameter of Co into the speci cation sp0 which is implemented by Co0 ; then the instantiation operation is well de ned. Then, if Co0 is a type, sp0 is added as imported speci cation and its formal parameter takes the place of the original formal parameter of Co; on the other 3

We use this intuitive notion of enlarging or reducing a class of models, although the di erences in the underlying signatures make the comparison not straitforward.

hand, if Co0 is a property, sp0 is simply used as the formal parameter of the new component. In both cases, the signature of sp0 will be added to the component exported signature and formal identi ers all around will be renamed according to m (mi is an extension of m to Co and m#i is the corresponding term translation function, as de ned in [7, 8]). Let spR = (R ; modR ) = spI [ spF and s , the free functor responsible for the semantics of Co (and corresponding speci cation sp). Then, the semantics for instantiation as de ned above constitutes a pushout as usual (c.f. Fig 1), provided that s is persistant in the class of models modR . In Fig 1, sp00 is the speci cation realized by Co00 and sp00R , its resulting imported speci cation. mR is the extension of the operation parameter m to spR as described below. mR is:

{ m(s); 8s 2 F and m(!); 8! 2 F { s; 8s 2 (R ? F ) and !; 8! 2 (R ? F ) spR mR

?

spR 00

s +

s

00

-sp inst

-sp? 00

Fig. 1. Instantiation pushout

3.2 Generalization Operator The generalization operator that we treat here has as main e ect the safe substitution of part of the imported speci cation of a component by a formal parameter from which the substituted speci cation is a specialization (a model). This corresponds to \enlarging" the class of models over which we construct our speci cation, consequently \enlarging" the class of models of the new component. It is dual to the instatiation operator de ned above, which aims to \reduce" it. The de nition of this operator is given below, followed by an informal explanation. The generalization operator (generalize) is de ned as: Co00 = generalize Co via m with Co0 = if Co = T (hspI ; spF i; Co; Eq) (1) ^ Co0 = P (hsp0I ; sp i;  0 ; Eq0 ) realizes sp0 (2) ^ m 2 HomSpec(sp0; spR ) and is a monomorphism (2) ^ (8s 2 R ; 8op 2 ImpOps(Co), s 2 m( 0 ) ^ s 2 sorts(op) ) op 2 m( 0 )) (3) then

if 8s 2 R ; s 2 sorts(OpL [ ImpOps(Co)) ) s 2 m( 0 ) (4) then T (hsp ; sp0 i;  0 [ mg (L ); m#g (Eq)) else if 8s; op 2  0 \ R ; m(s) = s; m(op) = op (5) then T (hspI ; spF [ sp0 i; R [  0 [ mg (L ); m#g (Eq)) else ? I.e.: given a component Co to generalize, a generalization morphism m, and a candidate component Co0 for realizing the formal parameter; if (1) Co is a well de ned type; if (2) the proposed morphism m is an injective speci cation morphism from sp0 , realized by the property Co0 , into spR , the total imported speci cation of Co (spR = (R ; modR ) = spI [ spF ); and if (3) this morphism reaches all operators that contain generalized sorts in their pro les4, so that the component equations are still well formed after renaming, then: 1. if (4) m satis es a generalization condition, sp0 becomes the formal parameter of the new component, substituting any previous imports, with corresponding changes in the component's signature (the generalization condition guarantees that the new component does not refer to parts of the previously imported speci cation that do not have a correspondence in the formal parameter)5 . 2. if (5) the generalization condition is not satis ed, but the inclusion of sp0 as formal parameter does not introduce name clashes, sp0 is included without any changes to previously imported speci cations. 3. in case none of the situations above apply, the generalization operation is unde ned. In the cases where the operation is de ned, the objects in the image of m (in the local presentation of the component) have their names modi ed according to the inverse morphism m?1 (mg is an extension of m?1 to Co , and m#g is the corresponding term translation function, as de ned in [7, 8]). It is important to stress that, albeit the complex appearance of the above formula, most of the tested conditions are syntactical and easily veri ed through simple algorithms. The potential complexity is the veri cation of the morphism, which is actually an undecidable problem in general. We assume that this veri cation is executed once and for all by the system or stated by the user and results are internally kept by the system. Let sp00R = (R00 ; mod00R ) be the resulting imported speci cation of Co00 and  00 s , the free functor responsible for the semantics of Co00 (and corresponding speci cation sp00 ). Then, the semantics for this generalization operator is given by a pushout complement (c.f. Fig 2), provided that s00  is persistant in the class of models mod00R . In Fig 2, sp is the speci cation realized by Co and spR , its resulting imported speci cation. mR is the extension of the operation parameter m to sp00R as described below. mR is 4 ImpOps(Co) stands for the set of imported operators that occur in Eq. 5 The index L is used to indicate the local part of the component's signature, in contrast with its imported part.

{ m(s); 8s 2  0 and m(!) : m(s1 ); :::; m(sn) ! m(s); 8! 2  0 { s; 8s 2 (R00 ?  0) and ! : mR(s1); :::; mR (sn) ! mR(s); 8! 2 (R ?  0) spR 00

mR

?

spR

s

00

+

s

-sp

00

gen

-sp?

Fig. 2. Generalization pushout complement The usual persistancy property of s00  in the class of models mod00R also guarantees that gen is indeed a speci cation morphism and, consequently, that all models of the original speci cation sp are also models of the generalized speci cation sp00 (modulo the forgetful functor Ugen application). This is an important property, as it means that we don't lose any models in the generalization process, as we would want it to be.

4 Generalizing Components The generalization operator de ned above (section 3.2) is basically a tool for, once the desired generalization is de ned, safely executing the corresponding transformation of the component. The most delicate part in the process is however the de nition of the desired generalization. To provide some support on this step, we proposed [17, 16] a syntactic generalization algorithm and techniques for semantic generalization. In Sections 4.1 and 4.2 respectively we brie y present what we understand by syntactic and semantic generalization.

4.1 Syntactic Generalization The most delicate point in the generalization process is probably the choice of the desired level of generality. If we take it to the extreme, any component could be generalized up to the empty speci cation. Obviously, this kind of result is of no interest, so, we need to x more reasonable limits. The adopted convention, used in the de nition of the generalization operator seen in section 3.2, is that we can only abstract from imported objects, de ning a dual operation to instantiation. But we still have the choice of how much of the imported speci cation we want to generalize. First we can determine which sorts and operations should be generalized, de ning a signature. Once this signature is de ned, we can decide on the semantic properties of the original speci cation that we want to keep or lose. If no requirements are made to preserve any semantic properties, the corresponding generalization is called a syntactic generalization. The syntactic

generalization is uniquely de ned by the generalized signature. Let PSYNT be the property corresponding to the syntactical generalization of a set of sorts GS in a component Co. PSYNT is of the form PSYNT = P (hsp ; sp i; PSYNT ; ) I.e., it introduces formal sorts and operators with loose semantics and no equations to be satis ed (spPSYNT = (PSYNT ; Alg(PSYNT))). In [17, 16] we proposed an algorithm for, given a set of imported sorts that we want to generalize in a component, de ne the morphism that corresponds to the maximum generalization that we can obtain. We also showed that this is always possible, given that the set of syntactic generalizations constitutes a complete lattice. Syntactic generalization is often too strong because we lose all semantic properties that depend on the generalized sorts. However, it presents two interesting characteristics: rst, it serves as a starting point for semantic generalization (section 4.2); and second, it is this kind of genericity that can be found in programming languages like Ada [1].

4.2 Semantic Generalization

The problem of generalization of a component with preservation of semantic properties represented by equations (theorems) can be stated as: to generalize a set of imported sorts of a component Co, preserving the validity of a given set Teo of theorems, in such a way that the original component can be obtained from the generalized one by re-instantiation. In [17] there is a broad discussion on this subject. Here, however, we concentrate in a more restricted problem that can be stated as: to generalize a set of imported sorts of a component Co, preserving the validity of a given set P of proofs of a set Teo of theorems, in such a way that the original component can be obtained from the generalized one by re-instantiation. This second condition (proof preservation) is obviously stronger than required by the original problem: the validity of a proof implies the validity of a theorem, but the converse is not always true. With this technique we obtain sucient but not necessary conditions to the validity of the stated theorems. The main advantage of this technique is its simplicity of implementation, as we substitute the problem of nding a proof for a theorem to the one of validating a known proof. Independently of the considered problem, including a given set of axioms in the required formal parameter of a component makes them valid in all models of the speci cation that this generic component realizes (guaranteed by the semantic of components). These axioms can then be used to prove the required theorems. In section 5 we propose an algorithm to generate this set of axioms in the case of rewrite proofs.

5 Preserving Proofs As stated above, we want to nd a property such that: it can syntactically substitute a given imported speci cation in a speci cation component Co; and its requirement as formal parameter in the generalized component Co00 is enough to guarantee that a given set of proofs for some selected semantic properties of Co is still valid for Co00 . These proofs can be of di erent kinds (rewrite, structural induction, by cases, or others). We concentrate here on rewrite proofs. Because rewrite proofs are intrinsically equational, they are the easiest to preserve. As shown below, it is enough to add a set of equations to the formal parameter so that the proof is still valid after generalization. With other kinds of proofs, as for instance proofs by induction, non-equational (e.g., constructor based) properties of the generalized sorts may be required for the validity of the proof and more sophisticated mechanisms are needed to generalize them.

5.1 Rewrite Proofs Rewrite Systems [6] are often used as a tool to prove theorems in equational systems and also as implementation of an operational semantics for algebraic speci cations of abstract data types (e.g. [4]). In this section, we rst introduce our notation for rewrite proofs and some basic properties that we use when we consider the preservation of these proofs and then show how these proofs can be preserved in the generalized speci cation. Finally, we give an algorithm to construct a formal parameter and the corresponding morphism so that these proofs are preserved. A rewrite proof for a theorem s == t in a rewrite system R is constructed by rewriting both s and t into a common term v, i.e. s

 v ? t ?! R R

When we want to explicitly show the whole derivation, the rewrite proof is represented by

?!s1?!:::?!v ?::: ?t1 ? t

s

lr1

lr2

lrn

rrm

rr2

rr1

where the identi ers that appear below an arrow indicate the rule that has been used in the step. In our context, R is a set of rules derived from the local axioms of a component Co and the axioms of any imported speci cations spI and formal parameters spF of Co, perhaps enriched with already proven theorems of any of these speci cations. Consistence of deduction by rewriting guarantees that a theorem s == t is valid in all models of the class Alg (; ER ), noted Alg (; ER ) j= s == t if   s ?! v ? t and ER is the set of equations corresponding to R. This is obviR R ously also true for all sub-classes mod  Alg(; ER ), speci ed by speci cation components.

In general, many conditions are imposed on these rules so that R can correspond to a decision procedure for the validity of theorems in a speci cation (e.g. termination, con uence, etc.). For this reason, algebraic speci cation languages sometimes impose conditions on equations so that execution or proofs are feasible in the system. For our purposes, however, these conditions are not relevant, since we consider already known proofs. For instance, it is known that commutativity is, among others, a problematic equation for rewrite systems, leading to the de nition of extensions such as class-rewrite systems [15]. Here, if two terms are equal modulo commutativity, this information will have been taken into account in the original proof and the commutativity equation will have been used with one of its possible orientations and it is this orientation that will be considered in the generalized proof. Generalizing Rewrite Proofs For a rewrite proof p of a theorem s == t in a system R to be valid in a system R00 all rules that are e ectively used in p must be present in R00 . In our context, R and R00 are derived from the axioms and already proved theorems of the speci cations sp (realized by the original component Co) and sp00 (realized by the generalized component Co00 ). For that reason, if P is the set of proofs we want to preserve, equations corresponding to all rules that are used in all p 2 P need to be present in the new speci cation. If they are local equations, this is always true, because the local presentation of the component is not changed (except for possible renamings) by the generalization operator of section 3.2. However, if any equations corresponding to previous imports of Co are used, they may be lost in the generalization process. They have to be added to the formal parameter so that they will be valid in all models of the new speci cation (this is guaranteed by the use of persistent free functors in the semantics of generic components). So, let PSYNT = P (hsp ; sp i; PSYNT ; ) be the property corresponding to the syntactical generalization of a set of sorts GS in a component Co. Also, let Eq(p) be the set of all equations used in a proof p to be preserved in this generalization. Eq(p) may be split into two sub-sets Eqg (p) and Eqng (p), corresponding to generalized (lost) equations and non-generalized equations, respectively. Adding the equations in Eqg (p) to the property PSYNT, will allow us to reproduce p in the generalized speci cation. If these equations contain sorts and operators that were not in the signature PSYNT, this signature must be expanded. Obtaining the Generalization Morphism Given a set GS = fs1; ::; sn g of sorts to generalize in a component Co = (hspI ; spF i; Co ; Eq) with preservation of a set of proofs P , the generalization morphism (and the generalization formal parameter) can be found by the following algorithm:

1. Obtain PSYNT, the syntactical generalization property of GS in Co and the corresponding speci cation morphism

mSYNT : PSYNT[s01 ; ::; s0m operators op01 ; ::; op0l ] ! spR [s1 ; ::; sm operators op1 ; ::; opl ] by the syntactical generalization algorithm [16]6 2. Let GSSYNT = fs1 ; ::; sm g  GS be the set of generalized sorts after the de nition of the syntactical generalization. And let GOSYNT = fop1 ; ::; opl g be the set of generalized operators. 3. List the set Eq(P ) of equations used in P . 4. Identify the subset Eqg (P ; GSSYNT ) of equations from Eq(P ) that are lost by generalization (external equations that refer to sorts in GSSYNT ).

Eqg (P ; GSSYNT ) = fe 2 Eq(P ) ? Eqjsorts(e) \ GSSYNT 6= g = fe1; ::; ek g 5. Identify any dangling references Pend(Eqg (P ; GSSYNT)) in equations fe1; ::; ek g.

Pend(Eqg (P ; GSSYNT)) = sorts(Eqg (P ; GSSYNT )) ? GSSYNT 6. If Pend(Eqg (P ; GSSYNT)) = , then generalization is de ned for the morphism

mSEM : PSEM[s01 ; ::; s0m operators op01 ; ::; op0j ] ! spR [s1 ; ::; sm operators op1 ; ::; opj ] that associates the property PSEM below to the imported speci cation of Co. property PSEM 0m sorts 01 0 operators 1 equations 01

s ; :::; s op ; :::; op0j e ; :::; e0k

notes: { fop1; :::; opj g = GO [ operators(Eqg (P ; GS )) and  is well formed because sorts(operators(Eqg (P ; GS ))) = sorts(Eqg (P ; GS )) and Pend(Eqg (P ; GS )) = . { The objects speci ed by PSEM are the generalized sorts and operators with new, fresh, names, and the equations are the ones in Eqg (P ; GS ) SYNT

SYNT

SYNT

PSEM

SYNT

SYNT

SYNT

with the corresponding renamings. 7. If Pend(Eqg (P ; GSSYNT)) 6= , add it to the set of sorts to generalize and re-execute the algorithm until this set of dangling references is empty and the generalization, de ned. 6

The syntactic generalization algorithm is quite similar to this one, with the di erence that iterations only aim to construct a valid signature. It also corresponds to a xpoint calculation.

It is clear that it will be always possible to get a well formed semantic generalization property such that no dangling references remain; this would correspond to include all of the imported sorts and operators (i.e. R ) in its signature. Another property that we want this algorithm to have is that generalization is indeed de ned for the obtained property and morphism. To show it, we refer to the conditions in the de nition of the generalize operator in Section 3.2. 1. The property component (PSEM) must be well-formed (well-formed signature and equations over this signature). proof: The syntactic algorithm guarantees that (GSSYNT; GOSYNT) is a well formed signature in any iteration of the semantic generalization algorithm. Furthermore, fop1 ; :::; opj g = GOSYNT [ operators(Eqg (P ; GSSYNT)), so, all operators used in the equations belong to the component's signature. Finally, all sorts in the pro le of operators(Eqg (P ; GSSYNT )) are also in GSSYNT , because Pend(Eqg (P ; GSSYNT )) = sorts(Eqg (P ; GSSYNT )) ? GSSYNT = . 2. mSEM must be a speci cation monomorphism from spPSEM to spR = SPI [ spF . proof: The corresponding signature morphism is clearly a signature monomorphism from PSEM to R (by construction). Additionnaly, because the set of equations fe01; :::; e0k g is obtained by translation (with respect to this morphism) from the set fe1; :::; ek g that was valid in spR , it is also a speci cation morphism. 3. The condition that every imported operator that occurs in any of Co's equations and have a generalized sort in its pro le must also be generalized,

8s 2 R ; 8op 2 ImpOps(Co):s 2 m( 0 ) ^ s 2 sorts(op) ) op 2 m( 0 ) is also guaranteed by the syntactical generalization algorithm and the inclusion of new operators in the generalized signature does not alter this result. 4. Finally, the fact that all names in PSEM are fresh names, makes PSEM \ R = , which trivially satis es condition on line (5) in the operator de nition

8s; op 2  0 \ R ; m(s) = s; m(op) = op

thus assuring that the operation is de ned.

5.2 An Example Let's consider the speci cation of sequences of natural numbers Seq Nat below with a product operator which gives the product of all elements of a sequence. type Seq_Nat imports Nat sorts seq_nat constructors nil: -> seq_nat cons: (nat,seq_nat) -> seq_nat operators prod: seq_nat -> nat

equations eq1: prod(nil) == 1 eq2: prod(cons(x,s)) == prod(s) * x theorems th1: prod(cons(x,nil)) == x

We want to generalize from the sort nat, to specify generic sequences, but preserving theorem th1. Suppose then that the following rewrite proof for it is available (eq? represent equations that come from the Nat speci cation):

p : prod(cons(x; nil)) ?! prod(nil)  x ?! 1  x ?! succ(0)  x ?! eq2 eq1 eq? eq?

?! x + (0  x) ?!? x + 0 ?!? x eq

eq

The syntactical generalization of nat in Seq Nat de nes the signature SYNT = (fsg; fk :! s; bin : (s; s) ! sg), corresponding to the sort nat and operators 1 and * respectively. The generalized equations (with their original signature) are: (a) (b) (c) (d)

1 == succ(0) succ(m) * n == n + (m * n) 0 * n == 0 n + 0 == n

These equations contain not only 1 and * but also 0, succ and +. However, none of these operators refer to sorts other than nat. Consequently, Pend(fa; b; c; dg) =  and the generalization is de ned for the property and morphism below. property PSEM sorts s operators k1, k2: -> s op1, op2: (s, s) -> s un: s -> s equations eqa: k2 == un(k1) eqb: op1(un(x), y) == op2(y, op1(x,y)) eqc: op1(k1, x) == k1 eqd: op2(x, k1) == x

mSEM : PSEM[s operators k1; k2; op1;op2; un] !

; ; ; +; succ]

Nat[nat operators 0 1

5.3 Other Proofs The procedure proposed above applies to rewrite proofs, but other kinds of proofs can be partially treated this way. As an example, consider a proof by cases of an equational theorem s == t with n proved cases. For this proof to be valid, an extra step is needed: the proof of completeness of the n cases or

_n casei

i=1

where 8i 2 f1; ::; ng, casei is the formula that caracterizes the ith case. This completeness property may not be true in the generalized speci cation and it is not expressible in conditional logic, so, we cannot generate one or more axioms to include in the formal parameter and preserve it. However, supposing that the proof for each case is by rewriting, it is possible to use the algorithm above to guarantee the validity of n conditional lemmas of the kind s == t if casei . A similar reasoning can be used for inductive proofs.

6 Conclusions This paper presents part of our work concerning the generalization by parameterization of algebraic speci cation components for reuse. The main result presented here is the proposal of an algorithm to identify the formal parameters that guarantee the validity of some semantic properties through their rewrite proofs. This algorithm is to be applied in conjunction with the generalization operator (also de ned in this paper) that safely e ectivates the generalization transformations in the component. This combination provides the means to obtain a more general speci cation component from which the original one is a specialization and that still satis es a given set of equational properties with their rewrite proofs. We also show that more complex proofs can bene t from this result, although only partially. One of the next steps in this work is to improve the treatement of these other kinds of proofs. One possible direction to take is the use of order sorted algebras [10, 12], so that some constructor based properties can be preserved in the generalization of a sort into a super sort. We can also study how \inductionless" inductive proofs and other similar techniques [11, 2] can be incorporated to this work. On a completely di erent direction, we also need to develop a prototype for a speci cation component manipulation tool using these ideas and produce a case study. This case study should be the starting point for the proposal of a methodology of support to the creation of component libraries, which is the practical main goal of this work.

References 1. Alsys. Reference Manual for the Ada programming language, 1983. 2. J.-P. Jouannaud ans E. Kounalis. Automatic proofs by induction in equational theories without constructors. In Proc. od the 1st IEEE Symposium on Logic in Computer Science, 1986. 3. J.A. Bergstra, J. Heering, and R. Klint. Module algebra. JACM, 37(2):335{372, 1990. 4. D. Bert and R. Echahed. On the operational semantics of the algebraic and logic language LPG. In Recent Trends in Data Types Speci cation, number 906 in Lecture Notes in Computer Science, pages 132{152. Springer-Verlag, 1995. Selected paper from 10th Workshop on Speci cation of Abstract Data Types.

5. D. Bert, R. Echahed, and J.C. Reynaud. Reference manual of the LPG speci cation language and environment (release with disequations). Technical report, LGIIMAG, June 1994. ftp available | site ftp.imag.fr. 6. N. Dershowitz and J.-P. Jouannaud. Rewrite systems. In Handbook of Theorectical Computer Science, chapter 15. Elsevier Science Publishers B.V., 1990. 7. H. Ehrig and B. Mahr. Fundamentals of algebraic speci cation 1. Equations and initial semantics, volume 6 of EATCS Monographs on Theoretical Computer Science. Springer-Verlag, 1985. 8. H. Ehrig and B. Mahr. Fundamentals of algebraic speci cation 2. Module Speci cations and Constraints, volume 21 of EATCS Monographs on Theoretical Computer Science. Springer-Verlag, 1990. 9. S.J. Garland and J.V. Guttag. An overview of Larch. In Peter E. Lauer, editor, Functional Programming, Concurrency, Simulation and Automated Reasoning, number 693 in LNCS, pages 329{348. Springer-Verlag, 1993. 10. J.A. Goguen. Order-sorted algebra. Technical Report TR14, UCLA Computer Science Department, 1978. 11. J.A. Goguen. How to prove inductive hypothesis without induction. In 5th CADE, number 87 in Lecture Notes in Computer Science. Springer-Verlag, 1980. 12. J.A. Goguen and J. Meseger. Order-sorted algebra I. Technical Report SRI-CSL89-10, SRI International, Menlo Park, 1989. 13. J.A. Goguen and T.C. Winkler. Introducing OBJ3. Technical Report SRI-CSL88-9, SRI International, 1988. 14. R. Hennicker and C. Schmitz. Object-oriented implementation of abstract data type speci cations. In M. Wirsing and M. Nivat, editors, AMAST'96, number 1101 in LNCS. Springer-Verlag, 1996. 15. J. Hsiang. Topics in Automated Theorem Proving and Program Generation. PhD thesis, University of Illinois, 1982. 16. P. Jacquet and A. Martins. Proposals for a methodic approach to generalization of speci cation components. In Proceedings of the XXI SEMISH, pages 193{207. Sociedade Brasileira de Computaca~o, 1994. 17. A. Martins. La Generalisation : un Outil pour la Reutilisation. PhD thesis, INPG, March 1995. 18. F. Parisi-Presicce and A. Pierantonio. Reusing object oriented design: An algebraic approach. In E. Bertino and S. Urban, editors, Object-Oriented Methodologies and Systems, number 858 in Lecture Notes in Computer Science. Springer-Verlag, 1994. 19. D. Sannella and A. Tarlecki. Toward formal development of programs from algebraic speci cations: Implementations revisited. Acta Informatica, (25):233{281, 1988. 20. J. Souquieres. Aides au Developpement de Speci cations. PhD thesis, Universitte de Nancy I, Jan. 1993. These d'E tat. 21. M. Wirsing. Algebraic description of reusable software components. Technical Report MIP-8816, Fakultat fur Mathematik und Informatik - Universitat Passau, 1988.

Suggest Documents