A Software Development Model for the Automatic Generation of Classes

In this paper it is presented a software development model based on transformations that allows to derive, in an automatic way, classes in object-oriented programming languages (Ada 95, C++, Eiffel and Java) starting from formal specifications. The set of transformations that conforms the software development model are a systematic steps, which starts from the algebraic specification of a type. This algebraic specification describes the abstract behavior of a type (type of interest) by means of other type, previously specified and implemented (representation type). In a progressive way, the transformations steps allow get a program (class) nearby to the initial specification (type of interest). These transformations obtain -in the first stepan intermediate specification (class specification) that it describes the operations of the type of interest by means of pre and post-conditions. Then, the intermediate specification is used to obtain imperative code in language-independent notation (pseudo-class); and finally the pseudo-class is transformed to any objectoriented programming language for which it has been defined transformations.


Introduction
In this article is presented a software development model based on transformations whose main objective is to obtain the concrete implementation of a type (class) starting from the algebraic specification of the type by means of an abstract representation.
A software development model based on transformations has as main objective to build a program P that is equivalent to a specification SP (Mod(P) ⊆ Mod(SP), where Mod(A) is the group of models that validates the sentences of A).The construction of the program P starting from the specification SP consists on a sequence of refinement steps: SP 0 ¡ SP 1 ¡ ¬ ¡ SP n In this chain, SP 0 is the original specification, SP n is the program P and SP i-1 ¡ SP i for i = 1,...,n is a refinement step.These successive steps guarantee that the derived program is equivalent to the original specification if the refinement steps have been proved; in other words, SP i-1 is refined as SP i (denoted SP i−1 ¡ SP i ) if all model of SP i is a model of SP i-1 .These steps can be described in a systematic way by means of transformation rules that are correct if the conditions of the rules are satisfied.This avoids to prove the correctness from each transformation step to each problem, since it is enough to prove the correctness of the transformations and to guarantee in each step that the conditions are satisfied [10].The transformations associated to each step can be described in an algorithmic or formal way, indicating the inputs, their transformations and the output.These ideas of successive transformations for the automatic production of code are the basis of the software development method that is presented in this article.
In this work we select an algebraic approach because it is suitable to the transformation model and it provides a formal base to prove that the class obtained by the transformations its correct with respect to the original specification.There are others approaches that uses the notions of executable specifications like rapid prototyping or even the automatic generation of functional programs starting from formal specifications.Another way to specify the system is using a object-oriented vocabulary by means of UML models (i.e. using Rational Rose, Enterprise Architect, etc.); and starting from these models, it can be generated the code of the classes.
The software development model presented here is an extension of a method for the automatic construction of imperative programs proposed in [15], which was optimized and implemented in [11].The main extensions consist on obtaining a multi-language software development model with support of generic abstractions; also taking into account that the destination languages are object-oriented.The initial advances of this work were presented in [13].The details of the software development model (as well as its theoretical justification) are presented in [12].The work described in this paper CLEI ELECTRONIC JOURNAL, VOLUME 4, NUMBER 2, PAPER 2, JANUARY 2002 also has a formal definition of the semantics aspects of the specification formalism that was used; but it is not detailed in this paper.This paper is structured as follows: Section 2 presents the objects that take part of the software development method as well as the relationships among them.Sections 3 and 4 presents the two blocks of transformation steps that conform the model.Finally, Section 5 presents the conclusions of this paper.

Model's Objects
In this section, the objects that are part of the software development method are described shortly.It is important to point out that the concepts of type and classes used in this work are based on the definitions presented in UML [9].In this context, a type allows to specify the abstract objects and the behavior of the external operations, while the class is used to describe objects with concrete states and implementation of the operations (methods).According to these definitions, a type specifies a class and reciprocally, a class implements a type.
In the Figure 1, it is presented a UML class diagram that shows the relationships between the objects that take part of the software development model.The objects presented are: type interface, algebraic specificaction, class specification and class.
With respect to the relationships between the objects, we have: − There is a modeling relationship between a type interface and multiple algebraic specifications.Indeed, any type can be modeled by several abstract implementation specifications, depending on the base type used for the implementation.
− A class specification inherits from a type interface the information of the operations headers and the auxiliary types.On the other hand, an algebraic specification allows to generate the pre and post-conditions of a class specification.To carry out this generation, it is applied a process of successive transformations on the axioms of the algebraic specification.
− Applying a process of automatic derivation of programs in object-oriented languages, a concrete class is generated starting from class specifications.This class implements or refines the operations indicated in a given type interface.
− The classes can be expressed in diverse object-oriented programming languages, such as: C++, Java, Eiffel and Ada 95.

Type Interface
A type interface is the signature or public part of a data type; defined by a finite set of types (one type is distinguished as a special type, called the type of interest) and a set of operations with their respective profile.The profile of an operation is represented by means of a function or procedure header.
The type interface is the starting point to obtain the implementation of a type of interest, because this has the general aspects of the type of interest, such as: the operations of the type and the auxiliary types that are required.This information is useful for the users of the type and for the transformation processes, especially the process of automatic derivation of code, for which the type interface defines the "protocol" or the way that the operations should be implemented (functions or CLEI ELECTRONIC JOURNAL, VOLUME 4, NUMBER 2, PAPER 2, JANUARY 2002 procedures/modifiers).The interface type also defines the information about the formal parameters (order, type, parameterpassing methods, etc.).
As an example, in the Figure 2 is presented the interface of generic sets (GEN_SET[ELEM]).The clause interface name has the name of the type interface; it may contain optionally a list of generic components.The clause type of interest indicates the name of the type defined by the interface (type of interest).The clause types indicate the auxiliary types needed for the definition of the type of interest.Additionally, there is an optional clause inherits, used to create new types interfaces by means of the inheritance mechanism (specialization); by this way it is possible to enrich the super-type and even to redefine operations.In the clause operations are defined the header of the operations by means of selective operations (functions) and modifier operations (procedures).In the case of modifier operations, they can modify just one parameter and this is expressed by the keyword 'mod'.

Algebraic Specification
An algebraic specification ALG spec is a 3-tuple <S,Σ,Ax>, where S is the set of sorts, Σ is the set of operations and Ax is the set of axioms.The axioms of the specification express the abstract properties of the data type.In general, the axioms can be equations, conditional equations, formulas in first order logic, etc.

The algebraic specifications can be of two types:
− A descriptive algebraic specification that describes the abstract properties of the data type that is defined − An abstract implementation specification, which describes the properties that characterize the implementation of the type of interest by means of another type that is supposed to be specified and implemented.
The model presented in this paper is based on the abstract implementation approach, specifically [2].
Additionally, in this model we use a subset of PLUSS [3] as the specification language that permits to build complex, structured, modular and generic specifications.
There are some properties that the algebraic specifications used must accomplish: − The axioms must be in constructive style − There are operations that are inverse with respect to the constructors (called selectors) − There are predicates to distinguish the values generated by the constructors.
− The axioms of a specification can be expressed as conditional equations.
In the Figure 3, it is presented the generic algebraic specification SET(ELEM), which defines the abstract behavior of the set type (SET) by means of a generic list (LIST).The clause generic spec indicates the name of the algebraic specification module (generic in this case).The clause use list the default and auxiliary sorts imported by the module.The PLUSS language allows several clauses use, we add a second clause use to indicate which sort is the implementation sort.The clause sort is used to indicate the sort defined by the specification.The remaining clauses allows to define the profiles of the constructors (clause generated by) and not constructors (clause operations), the pre-conditions of the partial operations (clause preconditions), the axioms of the operations expressed as: equations, assertions or conditional equations (clause axioms) and the variables used in the axioms (clause where).

Class Specification
A class specification is a specification style where the operations of a class are specified by means of pre and postconditions, based on a data abstraction.The precondition expresses the hypothesis related to the operations arguments and defines the conditions that have to be satisfied in order to apply the operation; the postcondition expresses the effect of the  operation.The class specification formalism is a part of the software development model presented in this paper; the details of this formalism as well as its semantics are presented in [12] and [14].
A class specification is defined by the tuple: CLASS SPEC = (<∑ interface , ALG SPEC , R>,℘), where: ∑ interface is a type interface, ALG SPEC is the reference algebraic specification, R is a mapping between the signatures Sig(ALG SPEC ) and ∑ interface .The pre and post-conditions of the operations in ∑ interface are denoted by ℘.
The operations of a class specification are conformed by a header (inherited from the type interface), a precondition and a postcondition.The pre and post-conditions are functional terms with variables, derived from the axioms of the reference specification, by means of a transformation process presented in Section 3.
The operations of a class specification can be partial or total and depending on this, the precondition term can be optional.The postcondition term can have two possibilities depending if the operation is function or modifier.If the operation is a modifier, the post-condition is post: x'=t, where x is the reference parameter in the operation (mod parameter, in this model) and t is the value of the postcondition term.If the operation is a function, the postcondition is: post: result=t.
A class specification is the input of a process of automatic generation of code in diverse object-oriented languages (Ada 95, C++, Eiffel, Java, etc.), presented in Section 4.
In the Figure 4, it is presented the class specification of the type SET[ELEM] whose algebraic specification is presented in Section 2. The transformations that are part of the software development model applied to the objects presented in this Section are presented in Section 3 and 4.

Class Specification Generation
As it was indicated to the beginning of this article, the aim of this paper is to present a set of transformations that conform a software development model.The general process of transformation can be denoted by: where, ALG spec is an algebraic specification of a data abstraction by means of a representation abstraction; CLASS spec is a class specification (with pre and post-conditions) obtained from ALG spec and CLASS is the implementation (class) of the abstraction expressed in an object-oriented language.
In this section it is presented the first transformation steps applied to the axioms of the algebraic specification ALG spec .The output of these transformations is a class specification CLASS spec , equivalent to the original algebraic specification.The class specification has the notion of state, which is not present in the axioms of the algebraic specification; also it is the main input of the transformation that is used to generate the code or implementation by means of a class (see Section 4).
The transformation process applied to derive the class specifications is composed by two basic transformations: the transformation of the axioms of the reference algebraic specification from constructive style to functional style (TR 1 ) and the transformation from the axioms in functional style to the class specification (TR 2 ).This can be expressed by means of the following transformation steps: where [ALG spec ] f is the original specification with axioms in functional style.

TR 1 : Constructive Style to Functional Style
As it was indicated in the Section 2.2, the software development model uses abstract implementation specification as input, whose axioms are expressed in the constructive style; this is, the axioms of the non constructor operations are defined completely by means of the constructors.
The general idea of this transformation is to express the axioms of the operations by means of the operation arguments; then, each axiom will be defined by: f(x 1 ,...,x n ) = t, where f is an operation of the specification and t is a term where the only used variables are x 1 ,...,x n .
The steps of this transformation depends on the kind of axioms from each operation; the general case is the operations with a complete equational definition and then its axioms in the constructive style are: where, for simplicity f it is assumed an unary operation, c 1 ,...,c n are the constructors of the specification and each term t i (i ∈ 1..n) is a term with variables.This is the definition of a total operation, but may exist operations that can't be defined to a constructor (partial operations).
The transformation process for the axioms of an operation f (denoted Ax f ) can be expressed as: where, the transformations cf 1 ,...,cf 4 are: where x is a new variable (that doesn't appear in the original axiom A) whose sort is compatible with the constructor c i .As a result of this step, we obtain the set of axioms equivalent to Ax f , where the constructors are substituted by a variable, which is denoted by where, the term with variables t si that are different than the variables introduced by cf 1 , were substituted by the appropriate selectors.The set of axioms resultant is denoted [Ax f ] v .The selector of each constructor is obtained by its profile; if there is no selector for a particular constructor, it must be added to the specification.
where Pc i is the predicate for the constructor c i (...).The set of conditional axioms obtained by this transformation is denoted [Ax f ] p .− cf 4 : The conditional axioms from the set [Ax f ] p are joined in one axiom for the operation f, using the if_then_else operation, then: then ts 1 else if Pc 2 (x) then ts 2 . . .else ts n If the operation f is a partial operation, there is at least one constructor c i ∈ {c 1 ,...,c n } such that the operation is not defined; then, the set of axioms of f are transformed using cf 1 ,...,cf 4 and for each precondition: f(x) is-defined iff x ≠ c i (...) it is applied the transformation cf 1 obtaining the axiom: f(x) is-defined iff Pc 1 (...) = false.

TR 2 : Functional Style to Class Specification
The transformation TR 2 assembles the operations of the class specification CLASS spec , where each operation is defined by means of a pre and a post-condition expressed in functional style.
TR 2 can be interpreted as an assembling function of the header with the pre and post-condition, using as input the specification [ALG spec ] f obtained applying TR 1 .This can be expressed as: The function fcl 1 obtains the header of the operation and fcl 2 obtain the pre and post-condition result of applying the transformation TR 1 .In this transformation it is used the mapping R between the signatures Sig(ALG SPEC ) and ∑ interface .This CLEI ELECTRONIC JOURNAL, VOLUME 4, NUMBER 2, PAPER 2, JANUARY 2002 mapping makes a link between the operations in the algebraic specification and the operations of the type interface.This mapping is also defined to variables and sorts.In this work we use a syntactic convention to differentiate elements of Sig(ALG SPEC ) (lower-case letters) and ∑ interface (upper-case letters).Below is presented an example of applying the transformations TR 1 y TR 2 to the axioms in constructive style of an operation height.It is assumed that the operation pop is the selector for the constructor push: In this example, pop is the selector of the operation push; this is established by examining the operation's profile or by means of an user interaction 1 .Additionally, we can see the use of the mapping R for operations (HEIGHT) and sorts (STACK, NAT).
In [14] we use the notion of institution [5] to show the semantics of the class-specification and to establish the relation between the models that validates algebraic specifications and class-specifications models.

Class Generation
In this section the transformations needed to complete the software development model are described.These transformations obtain a class in an object-oriented language starting from its class specification; this transformation completes the chain of systematic steps to obtain a class starting from an algebraic specification of a data abstraction.
The abstract implementation approach allows to describe the abstract behavior of a type of interest T by means of a base type TB, which is specified and implemented.This relation is established in the specification module of the sort t (which defines the type T) indicating that the specification of the representation is the specification module of tb (syntactically, the clause use: TB).When the transformations presented in Section 3 are applied, in the class specification this relation is represented by means of an inheritance clause (inherits: TB), which indicates the supertype of T.
From the viewpoint of the object-oriented paradigm, it is established a simple inheritance relation between the type of interest (implemented by means of a class) and its representation type.The transformations presented in this section use this notion and they establish the single inheritance relation according to the features of the target programming languages (Ada 95, C++, Eiffel or Java).
The process used to generate a class is separated in two transformations: transformation from the class specification to a class in a language-independent notation or pseudo-class (TR 3 ) and the transformation from the pseudo-class to a concrete class (TR 4 ).Then, the transformation steps of this process are: where [CLASS] p-c is the pseudo-class obtained from the class specification CLASS spec and TYPE int is the set of type interfaces imported in the class specification CLASS spec .

TR 3 : Class Specification to Pseudo-Class
The aim of this transformation is to obtain a pseudo-class [CLASS] p-c starting from the class specification CLASS spec that is obtained by means of the transformations TR 1 and TR 2 presented in Section 3. The pseudo-class is a class independent of the target language and it is introduced with the purpose of establish a generic process of class generation, so that this can be extended or adapted to other target programming languages.
The transformation TR 3 is applied to each operation of the class specification, allowing to transform the pre and postconditions of each operation in an equivalent imperative code.Then, this code is transformed to the syntax of the target language by means of the transformation TR 4 .Basically, the transformation translates the term of the pre and post-condition from functional style to imperative style, taking into account the information of how are implemented the operations used in the terms.This information is taken from the type interface of the auxiliary types imported from the class specification (clauses type of interest, types and inherits).Then, TR 3 can be expressed as: available abstraction.Even, the new abstractions generated with the process can be used as base to define more complex abstractions, based on the sub-types and inheritance relationship.
Another advantage of the software development model is the possibility to define generic abstractions, which is useful to define abstract containers, whose elements are generic.Also, the model takes into account that the target language can't define generic abstraction, in such case, the transformation TR 4 allows to instantiate the generic components with concrete class/types.
Another important feature is that the software development model presented is programming-language independent.The definition of the transformation of the pseudo-class to a class in a programming language (TR 4 ) as a transformations family, allows that this family can be extended, adding a new transformation TR 4 i to any language i (object-oriented and imperative).
Although the class specifications used in this work are derived in an automatic way starting from the axioms of an algebraic specification, the class-specification formalism can be used independently, as an alternative way to specify classes formally.
The success of a software development model with formal base generally is related with the software tools that support it, as a way to decrease the complexities of the formal aspects.The AEsCoP environment [1] has as main objective to apply, in an automatic way, the transformations presented here and additionally, it provides friendly tools used to create the inputs of the process (algebraic specifications, type interfaces) in an assisted way.In spite of this, the user still needs to know the general aspects of algebraic types, but the edition is less complex.
In general, the proposed approach is different from other approaches such as Larch [4] and VDM [6] in the fact that the steps that are applied are systematic and the final code obtained (object-oriented and imperative) is derived from successive transformations over the axioms of the original algebraic specification.
As possible extensions of this work, it is necessary to supplement the class specification formalism with object-oriented features not contemplated here, such as: multiple inheritance, abstract classes, etc.
Finally, it is important to point that there are many works like this but in the context of functional languages or executable specifications; but in the field of procedural and object-oriented languages there are a little number of works (like [7], [8] and others).

Fig. 1 .
Fig. 1.-UML Class Diagram of the objects that conform the software development model

2 .
Each class specification module has a name (clause class-spec).Additionally, if the class specification is derived of a generic algebraic specification, the generic components are indicated in the clause generic.The type of interest is indicated in the clause type of interest.The auxiliary types used in the operations of the type of interest are indicated in the clause types.The clause inherits indicates the super-type used to model the type of interest.The name of the class specification module associated to the representation type is indicated in the clause ref-spec.The clause operations contain the definitions of each operation, conformed by a header and the terms of the pre and post-condition (expressed as functional terms).