Transforming UML Static Models into Object-Oriented Code

Liliana Favre * Liliana Martinez Claudia Pereira Departamento de Computacidn y Sistemas

Universidad Nacional del Centro de la Pcia. de Buenos Aires. Argentina *CZC (Comisidn de Investigaciones Cientqicas de la Pcia. de Buenos Aires)

lfavre @amet. com. ar

Abstract

In this paper we propose a reuse-based rigorous method using UML and algebraic specifications. Our contribution is towards an embedding of the object-oriented code generation within a rigorous process that facilitates reuse, evolution and maintenance of the sofnyare. In previous work we describe the GSBLoo language to cope with the formalization of UML static models, and the SpReIm model for the definition of the structure of reusable components. Our current goal is to map design artifacts to object-oriented code. We describe a rigorous process to forward engineer UML static models. The emphasis in this contribution is given to the transformation of UML class diagrams into object-oriented code. In particular, we describe how to transform OCL specifications into GSBLOO axioms.

1. Introduction

UML (Unified Modeling Language) has emerged as a de-facto standard for expressing object- oriented models. It is a graphical language "for visualizing, specifying, constructing and, documenting the artifacts of a software-intensive system" [2].

UML is not a visual programming language, but its models can be directly connected to a variety of object-oriented programming languages through forward engineering processes [2]. These processes transform UML models into code through a mapping to an implementation language. The lack of precise semantics for UML models makes it difficult to develop rigorous forward engineering processes [21]. In some cases, developers can waste considerable time resolving gaps, ambiguities and inconsistencies.

In the marketplace there are CASE tools for code generation starting from UML models. Unfortunately, the current techniques available in these tools are not sufficient for the complete automated generation of source code. In addition, there is information in UML models, that has no corresponding constructs in the code. For example, object-oriented languages do not have mechanisms to express UML associations, their cardinality and associated constraints. The existing tools do not allow transforming all the registered information in the UML models. For example, OCL specifications can be used as a basis for the refinement of a class diagram into program code but the current tools do not incorporate OCL transformations.

In this work we describe a framework that aims at covering these limitations. It is based on the combination of UML with the algebraic style. We consider this integration beneficial for both graphical and formal specification techniques. On the one hand, formal techniques have the ability to visualize language constructs allowing a great difference in the productivity of the specification process, especially when the graphical view is supported by means of good tools. They also provide guidelines for eliciting and structuring requirements. On the other hand,

170 0-7695-0918-5/00 $10.00 0 2000 EEE

171

algebraic specifications allow us to produce a precise and analyzable software specification before implementation. Rather than requiring that developers manipulate formal specifications, we want to provide formal semantics for graphical modeling notations and develop rigorous tools that allow developers to directly manipulate UML models (with OCL annotations) they have created.

The definition of the GSBLm language to cope with concepts of the UML models [l 11. The definition of the SpReZm model for the description of the structure of a reusable component

[lo]. The definition of a process with reuse that assists in the transformation of UML class diagrams

to object-oriented code. Eiffel [20] was chosen as the language to demonstrate the feasibility of our approach.

The emphasis in this presentation is given to the integration of UML class diagram with GSBLm specifications and object-oriented code. In particular, we describe how to transform OCL specifications into GSBL?

The paper has the following structure. We start by looking at related work in Section 2. In Section 3 we describe an object-oriented algebraic language (GSBL") and a model for the definition of the structure of a reusable component (SpRelm). Section 4 outlines a rigorous process to forward engineering UML static models. In Section 5 we describe how to integrate OCL specifications and GSBLm. This is followed by conclusions (Section 6).

The bases of our approach are:

2. Related Work

Among the classical references associated to the generation of object-oriented code from formal specifications we can mention FRESCO and the LARCH specification language family. FRESCO is a programming environment to develop object-oriented software from VDM specifications [24]. LarchISmalltalk was the first language with subtype and inheritance specification [7]. LARCWC++ is another language with similar characteristics.

Further works analyzed the integration of semi-formal techniques and object-oriented design with formal techniques. For example, [13] describes the formalization of FUSION models in Z. [3] introduces a method to derive LARCH algebraic specifications from class diagrams.

The UML formalization is an open problem yet and many research groups have already achieved the formalization of parts of the language. It is difficult to compare the existing results and to see how to integrate them in order to define a standard semantics since they specify different UML subset and they are based on different formalisms. [5] describes how to formalize UML models using Z, [18] using Z++, [4] using stream oriented algebraic specifications, Gogolla and Ritchers [14] do this by transforming UML to TROLL; [22] achieves it by using operational semantics and Kim and Carrington [17] do it using OBJECT-Z. [12, 151 describe advanced metamodeling and notation techniques that allow the enhancement of UML. The Precise UML Group, pUML, is created in 1997 with the goal of giving precision to UML 191. Currently there are few development methods that include OCL [21]. The most important is Catalysis [8]. The paper [l] presents an approach for specifying UML interface constraints and proving the correctness of implementation relations between interfaces and classes. Their approach includes a proposal for an interface constraint language OCL-like.

What the latter formalizations have in common is the fact that they give semantics to UML and certainly this is also another goal in our work. However it is not an end in itself, we want to give semantics to UML static models in order to transform design artifacts into code by means of a rigorous process that facilitates software and design reuse. This is an essential difference with another existing works. Algebraic specifications allow us to associate UML models with a library

172

of reusable components that can be formally manipulated to obtain not only probably correct code but also a “design history” that can support forward and reverse engineering. Our approach emphasizes reusability by manipulating components through reuse operators.

As examples of commercial CASE tools that support UML we can mention Rational Rose, Together, GDRo, StpAJML, Argo/UML, etc. On the one hand the existing tools are hardly flexible since the programmer has little participation in design decisions associated to the standard translations from the UML models into code; on the other hand, they free the programmer to such an extent that he can introduce code modification wherever adequate. It is the programmer’s responsibility to preserve integrity between code and model. In addition these tools do not support transformation of all the information captured in the UML models, (e.g. associations, their cardinality, associated constraints, and OCL specifications).

The aim of this paper is to contribute to a solution of these issues by providing a rigorous forward engineering method which is compatible with UML and OCL.

3. Background

3.1. The GSBLoo Language

The existing algebraic specification languages do not possess specific constructions to express all kinds of relations in UML (dependency, association, generalization and realization). In general, these are buried in client and inheritance relations. However, associations are semantic constructions of equal weight to the classes and generalizations in the UML models, and should not be considered just as implementation constructions. In fact, the associations allow abstracting the interaction between classes in the design on large systems and they affect the partition of the systems in modules. Since an integrated method requires common structuring mechanisms fol object-oriented models and algebraic specifications, the GSBLm language has been defined. Thi. language enriches GSBL [6] . Among the most important features of GSBL are the ability ti specify deferred and effective parts (sorts, operations and equations), inheritance relations amoni classes, and mechanisms such as implicit parameterization to support reuse of specifications ana their incremental development.

GSBLm extends GSBL with constructs that allow us to express different kinds of UML relations. It distinguishes two kinds of classes: OBJECT CLASS and ASSOCIATION CLASS for specifying classes and associations (ordinary, qualified, association-class) respectively.

GSBLoo expresses dependencies in the context of classes by means of the USES clause. The mechanisms for defining inheritance are the RESTRICT and REFINES clauses. The REFINES clause relies on the module viewpoint of classes and the RESTRICTS clause on the type viewpoint of a class. Note that both REFINES and RESTRICTS are based on subset relations, but at different conceptual levels. While the REFINES relation describes a subset relation at the level of models, the RESTRICTS relation describes a subset relation at the level of camer set containing objects. Both of them reflect IS-A relations between abstractions in the external model of any software system.

Aggregations are represented by means of the clause HAS-A. It is possible to distinguish between simple aggregation and composition. Two keywords, SHARED and NON-SHARED allow us to express them.

To specify the different kinds of associations, GSBLoo includes in its basic library a special type of reusable component: Association.

The PACKAGE is the mechanism provided by GSBLm for grouping classes, and controls its visibility. It matches the UML semantics. Most of the times we use packages to specify class diagrams. For example, we might separate classes and their relations from a system’s design into

173

a series of packages, using the GSBLo0’s import dependencies to control access among these packages.

As an example, we present in Figure 1 a computer system for a company. The central classes are Person, Company and Department. There is an association between Person and Company, specifying that managers (instances of Person) manages companies. Furthermore, every manager may manage any number of departments and every company may have only one manager. There is a qualified association between Person and Bank (accountNumber is the qualifier). In the context of Bank, we have an accountNumber that would identify a particular customer. Then, given an object Bank, we can navigate zero or one object of Person. The class Person may realize many interfaces in the roles of customer, manager, employee, member, husband and wife. In an employer/employee relation between Company and Person, there is a job that represents the properties of that relation that apply to exactly one pairing of the Person and Company. This is modeled by an Association Class. The relation between Company and Department is a composition, a Department belongs to exactly one Company. Figure 2 partially shows the GSBLoo specification of Figure 1.

A detailed description of the GSBLm language may be found in [ 111.

Information. System- Comp rny

sccountNumber : Integer

-1

manager managed Compmkr Company 1

C U S t O m ~ r 1

~

O..* Name : SVhg Person

IrYmLd : B o o k m employee IrUnDnployed : Bookm Bithdrtr :Date

mP l’Y Numb er OfEmp b ye r I : Intr g er

Numb er OfEmp byre Son 0 NumberOfM~nkdEmployet0 HirrFmployer() DropEmployeeO

Ha,

1.: Dipanmint

Age :Integer FtrtNrmr : suing LrrtNsmi :string ? I t X : sex NumbarOfSon :Intiger o*l

o..* NumberOfDcpmnrent :Intrgrr

Figure 1. Information System Company. A UML Class Diagram

3.2. The SpReIm Model

It is impossible to manage a library with a large number of components without a systematic classification scheme, which splits object domains into subdomains that can be identified. It is also convenient to reflect this division in the components. Software reusability takes many different requirements into account, some of which are abstract and conceptual, while others are concrete and bound to implementation properties. They must be specified in an appropriate way.

Considering the issues described above, we introduce the SpReIm model for the definition of the structure of a reusable component [ 10,111.

174

PACKAGE Information-System-Company OBJECT CLASS Bank

OBJECT CLASS Person END-CLASS ..I. ...

USES Date, Integer. String, Sex, Boolean <Company-Person, ASSOCIATES managedcompanies:

aManager-Department> ASSOCIATES depart-manag: <Manager-Department> ASSOCIATES manager: Person Depanment aMember-DepartmentD ASSOCIATES member: Person uMember-Department, ASSOCIATES depart-mem: ........ Department DEFERRED <Person-Bank, ASSOCIATES bank: Bank

<Marriage, ASSOCIATES wife. Person <Marriage> ASSOCIATES husband: Person DEFINED DEFERRED OPS SORT Person Name: Department + String OPS NumberOfDepartment: Department + Integer Create: Boolean x Boolean x Date x Integer x String x String EQS ($:String; i: Integer)

OBJECT CLASS Department Company USES String. Integer

SORT Department

Create: String x Integer + Department <Job> ASSOCIATES employer: Company OPS

x Sex x Integer +Person DEFINED OPS IsMarried: Person + Boolean IsUnEmployed Person +Boolean Birthdate: Person + Date Age: Person + Integer

EQS (p:Person; d:Date; b,bl:Boolean; sI,s2:String; i j:Integer; t-sex:Sex)

IsMarried(Create(b1.b ,d,i,sl,s2,t-sexj))= bl IsUnemployed(Create(bl,b ,d,i,sl ,sZ,t-sex j))= b Birthdate(Create(b1.b .d,i,sl .sZ.t-sex j))= d

END-CLASS

OBJECT CLASS Company USES String, Integer, ... <Company-Person, ASSOCIATES manager: Person cHas, HAS-A NON-SHARED dep-comp: Department <Job% ASSOCIATES employee: Person DEFERRED SORT Company OPS Create: String x Integer + Company DEFINED OPS Name: Company + String NumberOfEmployees: Company + Integer HireEmployee: Company (c) x Person (p) + Company

Pre: not includes (employee(c). p)

EQS ( c: Company; p: Person; i:Integer; ...) employee (HueEmployee(c,p))=including(emplo yee(c),p) NumberOFEmployees(HueEmployee(c,p))=

employee (DropEmployee(c.p))=excluding(employee(c),p) NumberOKimplo yees(DropEmployee(c,p))=

...

...

...

NumberOfEmployees(c)+l

NumberOfEmployees(c)-1 ... END-CLASS

Nahe(Creat2s.. i))= s- NumberOfDepartment(Create(5, i))= i END-CLASS

ASSOCIATION CLASS lob IS Bidirectional[Classl: Person; ClassZ: Company; Rolel: employee;Role2: emp1oyer;Multl: O..*;Mult2: O..*;. . . l EFFECTIVE Title: Job + Suing StartDate: Job 3 Date Salary: lob + Integer END-CLASS

ASSOCIATION CLASS Marriage

END-CLASS

ASSOCIATION Company-Person

END-CLASS

ASSOCIATION Manager-Department IS Bidirectional [Classl: Person; Class2:Department; Role1:manager; Role2:depan-manag; Mult1:l;MultZ: O..*;...] END-CLASS

ASSOCIATION Person-Bank IS Qualified-Association [Classl :Person; C1assZ:Bank; Qualifier:accountNumber;Rolel :customer; Role2:bank; Multl :l;MultZ: O.. l ; . ..I

... END-CLASS

ASSOCIATION Member-Department

END-CLASS

WHOLE-PART Has IS Composition [Whole:Company; Part:Department; Mult 1 :1 ;MultZ: 1 ..* ;.. .I

...

END-PACKAGE

Figure 2. GSBLm Specification

The SpReIm model takes advantage of the power given by algebraic formalism to describe behavior in an abstract way while respecting the domain classification principles adopted for the

175

design of the class libraries in object-oriented languages. It allows us to describe object hierarchies at three different abstraction levels: specialization, realization and implementation. The specialization level describes a hierarchy of incomplete algebraic specifications as an acyclic graph G=(V,E), where V is a non-empty set of incomplete algebraic specifications and E E V x V defines a specialization relation between specifications. In this context, it must be verified that if P(x) is a provable property about objects x of type T, then P(y) must be verified for every object y of type S , where S is a specialization of T. In order to integrate the SpReIm model with UML diagrams, the specialization level has two views. One of them is based on OCL specifications and the other on GSBLm. OCL is a formal language developed as business- modeling language within the IBM Insurance Division and it has its roots in the Syntropy method. The UML users can make use of OCL to specify constraints and other expressions associated to their models. It can also be applied to specify invariants on classes, to describe preconditions and postconditions on operations and methods, to specify constraints on associations and as a navigation language. The integration of UML models with object-oriented languages requires orienting the reuse from components library whose taxonomy is conformed to the OCL one. The specification in OCL helps the user in the component identification process without forcing it to a change of specification formalism. The algebraic view will allow early validations and to automate the components transformation.

Every leaf in the specialization level is associated with a sub-component at the realization level. A realization sub-component is a tree of algebraic specifications: the root is the most abstract definition, the internal nodes correspond to different realizations of the root and leaves correspond to sub-components at the implementation level.

If E and E l are specifications, then E can be realized by E l if E and E l have the same signature and every model of El is a model of E [16]. Every specification at the realization level corresponds to a subcomponent at the implementation level, which groups a set of implementation schemes associated with a class in an object-oriented language. There is a relation between the other two levels and the implementation level:

Every incomplete algebraic specification in the specialization level is associated with a deferred class in an object-oriented language that matches the specified incomplete behavior. Internal nodes of the realization level components, including the root, correspond to an abstract class that defers implementation in the object-oriented level.

0 Leaves in the realization level correspond to concrete classes in an object-oriented language. The implementation level can contain classes that are not related to the specifications in the

specialization and realization levels. They reflect implementation aspects.

3.2.1. The Component ASSOCIATION: A special type of SpReIm component is Association. Figure 3 partially depicts a taxonomy of associations. The specialization level describes the different relations through incomplete specifications classified according to its kind, its degree and its connectivity. The realization level describes a hierarchy of specifications associated to different realizations. For example for an association (binary, bi-directional and many- to-many) different realizations through hashing, sequences or trees could be associated. The implementation level associates each leaf of the realization level to different implementations in an object-oriented language.

Implementation sub-components express how to implement associations and aggregations. For example, a bi-directional binary association with multiplicity “one to one” will be implemented as an attribute in each associated class containing a reference to the related object. On the contrary, if the association is “many to many” the best approach is to implement the association as a different class, in which each instance represents one link and its attributes.

SPECIALIZATION LEVEL

OBJECT CLASS A REFINES S1, .... Si, ... Box[ ... :attrl ;...:attri;...:methl ;.. :methi,..]

"Aggregname-i" HAS-A SHARED B "Compos-name-i" HAS-A NON-SHARED C

Figure 3. ASSOCIATION Component

4. A Rigorous Forward Engineering Method

Immediately after, the bases of a transformation process from UML class diagrams to object- oriented code are described.

"Assoc-name-i" ASSOCIATES D

EQS (.....) <equations> END-CLASS

....

4.1. From UML class diagram to an incomplete specification in GSBLM

Given a basic UML diagram (composed by classes and relations), a PACKAGE whoss components will be OBJECT CLASS, ASSOCIATION CLASS and relation definitions, i, generated semi-automatically. For each class shown in the diagram an OBJECT CLASS is buil and for each association (ordinary, qualified or class-association) a new association is defined These specifications are obtained by instantiating reusable schemes that already exist in i GSBL"S predefined library. Each OBJECT CLASS is obtained by instantiating the followink scheme:

177

Generalizatiodspecialization relations are expressed by means of the REFINES clause. The scheme Box specifies the class interface (attributes and methods). Aggreg-name-i, Compos-name-i and Assoc-name-i are new relations defined by instantiating schemes existing in the Association hierarchy. On the other hand, preconditions, postconditions and invariants in OCL will be translated to preconditions and axioms in GSBLm. In Section 5 we describe in detail how to translate OCL specifications into GSBLm axioms.

Thus, an incomplete algebraic specification can be built semi-automatically. It contains all the information that can be extracted from the UML class diagram. It allows us to carry out a rigorous analysis of the modeled behavior as well as to create new UML models, more informative and precise.

4.2. Constructing Realizations

In this phase a more detailed specification is developed. This specification is constructed from the SpReIm library to obtain a specification “as complete as possible”. The process is based on a number of components that admit a high degree of generality and can be manipulated in order to adapt them to new applications. The library of reusable components should provide such searching mechanisms that users can find appropriate components easily. Next, we describe the steps of this sub-process.

Identification: For every OBJECT CLASS 0 in the PACKAGE obtained in the previous stage will exist, in general, classes of the SpRelm library that can be adapted to the wished behavior. As we had said, the designer has an OCL view of the SpRelm library, which can be used to identify candidate specifications associated to the diagram’s classes while it is being constructed. Let us suppose that a S specification has been identified in the component C. If S is a leaf, it will be associated to the root of a sub-component in the realization level, being CR that sub-component. Otherwise, it will be selected a leaf L in the specialization level of C, so that there is a path in the graph from S to L, as a candidate to be transformed.

Adaptation: The identification of L is correct if Rename, Hide, Extend and Combine operators can modify it to match 0 (Rename: changes the name of sorts or operations; Hide: forgets those parts of a specification that are not necessary for the actual application; Extend: adds sorts, operations or axioms to a specification and Combine: combines two or more specifications in only one).

The sorts and operations must be connected with the 0 ’ s ones by an appropriate renaming. The renamed version must be extended with sorts, operations and axioms. The visible signature must be restricted to the visible signature of 0. Let L’ be the specification obtained from transforming L by means of the sequence of operators OPI,0P2,.. .,OPk., the next step is to obtain a realization of L’. That is, a leaf R has to be selected in the realization level of C, and the sequence of operators used in the previous stage must be applied to it giving R’. As the operators preserve realizability we have that R’=OP,(. . . . . . . . .(OPK(R). . ..) is a realization of L’=OP,(. . . . . . . . .(OPK(L). . . .). The identification and adaptation of association relations is made in the same way. In this case, the specifications reused are in the component Association.

Composition: Compose the specifications of classes and associations in a specification SC. This specification allows us to carry out behavior simulations, enrich the UML class diagrams and will be the base for the code generation.

4.3. Constructing Implementations

For each subspecification R in SC an implementation scheme I in the sub-component associated to R in the implementation level of C has to be selected. If the Extend operator was

178

applied in the previous steps, the scheme should be probably extended with new relations and operations. The relations expressed in the USES clause will be translated to a client relation in an object-oriented language. The relations expressed in the REFINES and RESTRICTS clauses will be translated to inheritance relations. For each HAS-A clause an implementation scheme will be selected in the component Association and the "aggregate" and the "part" will be instantiated. For example, if the aggregation is "one-to-many'' an attribute in the "aggregate" will be instantiated with a reference to a sequence of pointers to the "part". Every new operation will be translated into a new feature Eiffel that could be deferred or effective. Preconditions and axioms are used to construct preconditions and postconditions for features and, invariants for Eiffel classes. In [ 101 the transformation process from axioms into assertions Eiffel is described. The implementation associated to R is OP1( ......... (OP,(I) .... ). The programmer intervenes in the method implementation.

Finally, for every AR Association relation, a scheme will be selected in the implementation level of the Association component and will be instantiated with the associated classes. In these cases, the implementation level's schemes suggest to include "references" attributes in the classes or to introduce an intermediate class or container. Notice that the transformation of an association not necessarily implies the existence of an associated class in the code generated, as an efficient implementation can suggest to include "references" attributes in the classes.

5. Integrating OCL Specifications and GSBLoo

To translate from OCL constraints to GSBLm specifications is one aspect to underline in this process. The specifications in OCL (preconditions, postconditions, class invariants) will be expressed by means of preconditions and axioms in GSBLoo. [ 191 have examined the expressive power of OCL in terms of navigability and computability. They have shown that OCL is less expressive than the relational calculus and they also hinted it is not equivalent to a Turing machine. However, the use of OCL is likely to gain wider acceptance because it is designed for ease and usability.

We predefine a number of types in GSBLm for dealing with collections, which conform to the OCL types. Within OCL there are four collection types: Collection, Set, Bag and Sequence. Collection is the abstract supertype of the other ones and is used to define the operations common to all collection types.

OCL is, in the same way, an assertion language. Assertions express semantic properties of the classes. They serve to express the specification of software components: indications of what a component does rather than how it does it.

Analyzing these assertions we can derive axioms that will be included in the GSBLoo specifications. Preconditions written in OCL are used to generate preconditions in GSBLoo; postconditions and invariants allow us to generate axioms in GSBLm. An operation can be specified in OCL by means of pre- and post-conditions:

Typename:: Operation name ( parameterl: Typel. ... ):Return Type pre: -some expression of selfand parameterl post.Result= - somefunction of selfandparameterl

Selfcan be used in the expression to refer to the object on which the operation was called, and the name Result is the name of the returned object, if there is any. The names of the parameter (parameterl, ...) can also be used in the expression.

In a postcondition, the expression can refer to two sets of values for each property of an object: the value of a property at the start of the operation the value of a property upon completion of the operation

179

The value of a property in a postcondition is the value upon completion of the operation. To refer to the value of a property at the start of the operation, one has to postfii the property name with "@", followed by the keyword "pre".

In Figure 4 we show the OCL specification of HireEmployee operation and its translation to GSBLm axioms (see Figure 2):

Comoanv:: HireEmDlovee (wPenon) p ~ : not employee + includes(p)

post: employee employee@pre + includ~ng(p)

OBJECT CLASS Company

OF5 HueEemployee: Company (c) x Person (p) + Company pre: not includes(employee(c), p)

EQS (c:Company; p:Person; .... employee(HueEmployee(c,p)) = including(employee(c). p)

.....

Figure 4. Translating OCL Specifications

This transformation process is supported by a system of transformation rules. Some of them are partially shown in Figure 5.

OCL

I. T + Op (tl,tZ, ..) : ReturnType Post: Result = T+ iterate (elem: Type; acc: Type2 = cexp> I <booleanexpression-withelem-and-aco)

2. T+ Op (<listpram>) : Boolean Post: Result = T+ forAU (elem: Type I <boolean- expression-withelem)

3. T+ Op (<Listgaram>) : Boolean Post: Result = T+ exists (elem: Type I <boolean- expression-with-elem)

4. T --3 Op (<listjaram>) : ReturnType Post: <expp = <expp

5. T + Op (<list-param>) : Return Type Post: Result = T ( 1 .. t+size ) + forAU (index: Integer I <exp>)

Figure 5 . Trans

+GSBL""

OPS 0p:T x t l x t2 x... + Return Type EQS (t:T, e: Type, ... ) Op ( emptyT, tl,t2,.. )= Translate(exp) Op (constdt,e), t l , t2 ,..... )= Translate(boo1eanexpression-withelem-and acc)

with [elem I+ e; acc I+:Op(t,tl,t2, ... )] OPS 0p:T x (Elem->Boolean) x.. . + Boolean EQS {t:T, e: Type,f:Elem->Boole an... ) Op (emptyT, <listgararm)= TRUE Op (c0nstdt.e). <list-param>)= Ofit. <list-param>) AND

f(e)

f(e) is true if <booleanexpression-withelem

OPS 0p:T x (Elem->Boolean) x... + Boolean EQS (t:T, e: Type,f:Elem->Boolean.. . ) Op (empty=. d i s t g a r a m ) = FALSE Op (c0nstdt.e). dist-param>)= Op(t, <list-param>) OR

f(e) ___________________________________I____-------

f(e) is true if <booleanexpression-withelem

OPS 0p:T x . . . + Return Type EQS{ ... ) Tramlale(exp1) = Tramhre(exp2)

OPS 0p:T x . . . + Return Type EQS {t:T, ... ) Op (t, <list-param>) = ( 1 5 index 5 size(t) ) =)

Tramlate( exp)

xmation Rules

180

It is worth clarifying for the axioms generation that a basic functionality: Typename:: Operation name ( parameterl: Typel, ...) :Return Type ,

it is translated into GSBLm syntax as Operation name: Typename x Typel x + RetumType . In the same way the axioms terms must be translated respecting the GSBLoo syntax, for example, not employee + includes(p) is translated to not includes(employee(c), p).

Let Translate be functions that translate logical expressions of OCL into first-order formulas in GSBLoo. The translation of expressions of the form e.op, where e is a complex expression of the form e l .opl, is recursively defined by Translute(e.op)= op(TransZate(e))

Figure 6 partially shows an OCL specification of Collection and Figure 7 how to built its GSBLoo specification. For transforming we take into account the distinction between constructor and observer operations. The programmer has to choose the adequate constructor operations. For example, in Rule 1, if T is instantiated with Collection then ConstT is instantiated with add and empty, with create (see Figure 6) .

Collection + includes ( e:T ) : Boolean post: result= Collection+iterate (elem; acc:Boolean=false I if elem=e then true else acc ) Collection + includesAll (cZ:Collection(T)) :Boolean post: result= (cZ+forAll(elem I Collection+includes(elem)) Collection+ forAll (expr:OclExpressinn) :Boolean post: result= collection+iterate (elem; acc:Boolean=true I acc and exp) Collection-, exists (expr:OclExpression) :Boolean post: result= Collection-titerate (elem; acc: Boolean=false I acc or exp) Collection +&Empty : Boolean post: result=(collection+ size=O) . . .. . . .

Figure 6. OCL Specification [21]

OBJECT CLASS Collection[Elem:ANY] USES Boolean, Nat, ... BASIC CONSTRUCTORS create, add DEFERRED SORT Collection OPS create: + Collection add Collection x Elem Collection size: Collection + Nat count: Collection x Elem + Nat EFFECTIVE OPS isEmpty: Collection + Boolean includes: Collection x Elem + Boolean includes-all: Collection x Collection + Boolean for-all : Collection x (Elem->Boolean)+ Boolean

exists: Collection x (Elem->Boolean)+ Boolean

EQS( c,cl :Collection;e:Elem;f:Elem->Boolean)

isEmpty( c) =((size(c)=O ) Rule 4

includes(creat@.e)= false includes(add(c.e),el)= if e e l Rule 1 then me else includes(c,el)

for-all (createO,f)= true for-all (add(c.e),f)= f(e) and for-all(c,f)

includes-all.(c,createO) =me includes-all (c,add (de))= includes(c,e) and includes-all (c,cl) _...... Rule 2 END-CLASS

...................... ...

Rule 1

Figure 7. GSBLm Specification

6. Conclusions

In this work we outline a rigorous framework for code generation. There are a couple of tools in the marketplace which perform the mapping of UML models to code. However, they do not allow transforming all the information contained in UML models. Our approach allows deriving knowledge from UML models with annotations in OCL, in order to support assessment of solutions and to verify implementations against specifications.

181

Although a tool prototype that assists the proposed method does not exist, key .phases of this one have been prototyped. The first results of this research were the reusable component model definition and its adaptation mechanisms. A prototype that assists in the component identification, adaptation of reusable components by means of reuse operators and in the generation of the Eiffel code from formal specifications has been implemented. The results were already introduced in [lo].

Later works introduced an integration of the proposed method with UML [ll]. Nowadays the prototyping of this phase is being implemented. An important aspect is the transformation of OCL specifications (preconditions, post conditions and invariants) into GSBLoo axioms.

The obtained results prove the feasibility of the proposed method, however we can not make an analysis of the pragmatic implications of our approach. Future works will include the integration of this approach with the Rational Rose tool [23].

7. References

[l] M. Bidoit, R. Hennicker, F. Tort, and M. Wining, "Correct Realizations of Interface Constraints with OCL, Proc. 2"' Int. Conf. (UML99), Lecture Notes in Computer Science, Vol. 1723, Springer Verlag, 1999, pp. 399415. [2] Booch, G. , J. Rumbaugh, and I. Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999. [3] R. Bourdeau, and B. Cheng, "A Formal Semantics for Object Model Diagrams", IEEE Transactions on Software Engineering, Vol. 21, N" 10, October 1995. [4] R. Breu, U. Hinkel, C. Hofmann, C. Klein, B. Paech, B. Rumpe, and V. Thurner, "Towards a Formalization of the Unified Modeling Language", TUM-I9726 Technische Universitat Munchen, 1997. [5] J. Bruel. and R. France, "Transforming UML Models to Formal Specifications", Proc. of UML'98-Beyond the Notation, Lecture Notes in Computer Science, Vol 161 8, Springer-Verlag. 1998. [6] S . Cl6rici. and F. Orejas, "GSBL an Algebraic Specification Language Based on Inheritance", Proc. of the European Conference on Object-Oriented Programming (ECOOP 88) 1988, pp. 78-92. [7] Y. Cheon, and G. Leavens, "The LarchlSmalltalk Interface Specification Language", ACM Trans. on Soft. Eng. and Meth, 3 (3), 1994, pp. 221-253. [SI D'Souza, D. and, A. Wills, Objects, Components and Frameworks with UML, Addison-Wesley, 1999. [9] A. Evans, R. France, K. Lano, and B. Rumpe, "The UML as a Formal Modeling Notation", Proc. of UML'98- Beyond the Notation, Lecture Notes in Computer Science 1618, Springer-Verlag, 1998. [lo] L. Favre. "Object-Oriented Reuse through Algebraic Specifications", Technology of Object-Oriented Languages and Systems (Tools 28) C. Mingins and, B. Meyer (eds), IEEE Computer Society, 1998, pp. 101-112. [ I l l L. Favre, and S . ClBrici, "Integrating UML and Algebraic Specification Techniques" Technology of Object- Oriented Languages and Systems (Tools 32) C. Mingins and, B. Meyer (eds), IEEE Computer Society, ISBN 07695-

[I21 D. Firesmith, and B. Henderson-Sellers, "Clarifying specialized forms of association in UML and O M L JOOP,

[13] R. France, J. Bruel, and M. Larronde-Petri, "An Integrated Objet-oriented and Formal Modeling Notations", JOOP, NovemberlDecember. 1997, pp. 25-34. [14] M. Gogolla, and M. Ritchers, "On combining Semi-formal and Formal Object Specification Techniques", Roc.

[15] B. Henderson-Sellers, "OPEN Relationships-Associations, Mappings, Dependencies, and Uses", JOOP, 10(9), 1998, pp. 49-57. [16] R. Hennicker, and M. Wirsing, "A Formal Method for the Systematic Reuse of Specifications Components", Lecture Notes in Computer Science 544, Springer-Verlag. 1992. [I71 S. Kim and D. Canington, "Formalizing the UML Class Diagram using OBJECT-Z, Proc. UML 99, Lecture Notes in Computer Science1723, 1999, pp.83-98. [18] K. Lano, "Formal Object-Oriented Development", Springer Verlag, 1995. [I91 L. Mandel, and M. Cengarle, "On the Expressive Power of the Object Constraint Language OCL" Available in : http://www.fast.de/projecktdforsoft/ocl ,1999. [20] Meyer, B., Object-Oriented Software Construction, Prentice Hall, 1997. [21] OMG Unified Modeling Language Specification, v 1.3 document ad/ 99-06-08, Object Management Group, 1999. (221 G. Overgaard, "A Formal Approach to Relationships in the Unified Modeling Language", Proc. of Workshop on Precise Semantic of Modeling Notations, Intemational Conference on Software Engineering, lCSE'98, Japan, April, 1998. [23] Quatrani, T., Visual Modeling with Rational Rose and UML, Addison-Wesley, 1998. [24] A. Wills, "Specification in Fresco", Proc. Object Orientation in 2, Workshops in Computing, Springer-Verlag. Cambridge, UK, 1992, pp. 127-135.

0462-0,1999.

11(2), 1998, pp. 47-50.

WADT97, LNCS 1376, 1997, pp. 238-252.