Information Systems 26 (2001) 507–534

The OO-Method approach for information systems modeling:from object-oriented conceptual modeling

to automated programming

Oscar Pastora,*, Jaime G !omezb, Emilio Insfr!ana, Vicente Pelechanoa

aDepto de Sistemas Inform !aticos y Computaci !on, Universidad Polit !ecnica de Valencia, Camino de Vera,

s/n 46022 Valencia, SpainbDepto de Lenguajes y Sistemas Inform !aticos, Universidad de Alicante, 03690 Alicante, Spain

Abstract

Current and future (conventional) notations used in Conceptual Modeling Techniques should have a precise (formal)semantics to provide a well-defined software development process, in order to go from specification to implementationin an automated way. To achieve this objective, the OO-Method approach to Information Systems Modeling presented

in this paper attempts to overcome the conventional (informal)/formal dichotomy by selecting the best ideas from bothapproaches. The OO-Method makes a clear distinction between the problem space (centered on what the system is) andthe solution space (centered on how it is implemented as a software product). It provides a precise, conventionalgraphical notation to obtain a system description at the problem space level, however this notation is strictly based on a

formal OO specification language that determines the conceptual modeling constructs needed to obtain the systemspecification. An abstract execution model determines how to obtain the software representations correspondingto these conceptual modeling constructs. In this way, the final software product can be obtained in an automated way.

r 2001 Elsevier Science Ltd. All rights reserved.

1. Introduction

If the software production process is under-stood to be a true engineering activity, a compre-hensive view of the set of phases involved mustbe introduced. This view should be global, inthe sense that a clear relation between thedifferent steps must be defined. We are concernedwith how to improve the system development

process in order to solve the problems detailedbelow [1]:

* Moving out from the chaotic level associa-ted with conventional methods, wherecontradictions, ambiguities, incompletenessand mixed levels of abstractions occur in anatural way.

* Improving understanding at the problem spacelevel.

* Designing flexible methods and better compu-ter-aided software engineering (CASE)/compu-ter-aided requirements engineering (CARE)

*Corresponding author.

E-mail address: opastor@dsic.upv.es (O. Pastor).

0306-4379/01/$ - see front matter r 2001 Elsevier Science Ltd. All rights reserved.

PII: S 0 3 0 6 - 4 3 7 9 ( 0 1 ) 0 0 0 3 5 - 7

support, with the objective of reaching thesolution space with a final software productwhich is compliant with the problem spacedescription.

* Providing guidance in order to be able to dealwith the entire software production process in astructured way.

To overcome these shortcomings, we shouldmove from traditional systems engineering toadvanced requirements engineering, where thedistinction between the problem space (what theproblem is) and the solution space (how it is to beimplemented in a particular software developmentenvironment) must be clearly established. Theconversion of the conceptual modeling constructs(which are included in the resultant conceptualmodel) into the final software components shouldalso be clearly determined.

It is obvious that the problem space imposesstrong requirements on the software productionprocess. Taking into account that the RequirementEngineering process is complex, knowledge-inten-sive, experience-based, and requires highly intel-lectual and creative activity, it is essential toprovide a clear way of capturing those require-ments considered relevant in order to build acorrect conceptual model. The first decision tomake is to determine the model to be used fordealing with the conceptual modeling process.From our point of view, the object-oriented modelis the best choice, due to its proximity to humancognitive mechanisms, due to the encapsulation ofstructural and behavioral aspects provided by theobject notion and due to the fact that thetransition from the problem space to the solutionspace is smooth. We can specify objects in theconceptual model and implement objects in thefinal software representation. The object-orientedmodel introduces modularization in the problemspace, making reuse a good practice in theconceptual modeling process.

If we look at the current approaches that dealwith object-oriented conceptual modeling, we candistinguish two main categories:

* Those conventional methods such as Wirfs-Brock [2], Rumbaugh [3], Jacobson [4], Booch

[5], Coleman [6], inheriting what we could calltraditional CASE problems:1

* an excessive number of models that haveoverlapping semantics,

* difficult and lossy transformations betweenmodels, languages and tools,

* variable quality in system implementationunder similar quality designs,

* lack of comprehensiveness due to needlesscomplexity.

* Methods that are created using a formalframework such as Kush [8], Clyde [9], Jackson[10], Liddle [11], Liu [12] to define concepts in aprecise way, and where for every behavioralpattern captured in the conceptual modelingstep (problem space), there is a correspondingconstruct in the software representation used atthe solution space.

We argue that future developments in SoftwareEngineering lie within this second approach, andthe last few years we have been working in thisdirection. Our contribution to this state of the artis the OO-Method approach [13,14], which isbasically built on a formal object-oriented model(OASIS [15]). Its main feature is that developersefforts are focused on the conceptual modelingstep, where system requirements are captured inaccordance with a predefined, finite set of con-ceptual modeling constructs that are the represen-tation of relevant concepts at the problem spacelevel. The final implementation is obtained in anautomated way by programming the correspond-ing mappings between those conceptual modelconstructs and their representation in a particularsoftware development environment.

This architecture provides the pattern forobtaining software components which can bedynamically combined to build a software proto-type that is functionally equivalent to the specifi-cation collected in the conceptual model step. The

1In this context, industry trends attempt to provide unified

notations such as the UML proposal [7], which was developed

to standardize the set of notations used by the most well-known

existing methods. Even if the attempt is commendable, this

approach still has the implicit danger of providing users with an

excessive number of diagrams that have overlapping semantics

without a methodological approach.

O. Pastor et al. / Information Systems 26 (2001) 507–534508

current software development environmentswhere code is generated include Visual C++,Delphi, Visual Basic and Java. However, it isimportant to note that the approach is concep-tually independent of any target developmentenvironment. Concrete implementations of theexecution model are obtained by programmingthe corresponding mappings between conceptualmodeling constructs and their corresponding soft-ware representations in the selected softwaredevelopment environment.

This document is organized as follows: Section 2presents a short description of the main OO-Method features describing the diagrams that areused to capture the system properties in order toproduce what we call a conceptual model. Thissection also introduces the underlying OO OASISformal specification that is obtained when theconceptual model step is finished, as well asshowing how to represent this OASIS formalspecification in any target software developmentenvironment, according to an abstract executionmodel. Section 3 describes the component-basedarchitecture in order to produce the softwarecomponents that allow us to link the conceptualmodel with the abstract execution model in anautomated way. The programming language usedin the examples of this section is Java. Section 4describes related work, and Section 5 presentsconclusions and suggestions for future work.

2. The OO-Method

The OO-Method was created on the formalbasis of OASIS, an object-oriented formal speci-fication language for Information Systems. Basi-cally, we can distinguish two modeling compo-nents in the OO-Method: the conceptual modeland the execution model.

2.1. Conceptual model

Two main aspects must be clearly stated whenintroducing a conceptual modeling approach:

(1) which conceptual modeling constructs areprovided by the method,

(2) which notation is provided to properly capturethose conceptual modeling constructs.

Before introducing the specific set of modelingconstructs and notations, it should be pointed outthat in the OO-Method proposal, the combinationof formal specification techniques with conven-tional, widely-used OO modeling techniques hasbeen a basic feature since the very beginning.Another important objective was to avoid thecomplexity which is traditionally associated withthe use of formal methods, by making designersview the method as being compliant to industrialstandards.

This is why we adopted the well-known OOstrategy of dividing the conceptual modelingprocess into the three complementary views, thatof the object view, the dynamic view and thefunctional model view. However, there is a bigdifference: in the OO-Method, when the designer isspecifying the system, what he is really doing iscapturing a formal specification of the system ‘‘onthe fly’’, according to the OASIS formal specifica-tion language. This feature allows us to introducea well-defined expressiveness in the specification,which is often lacking in the conventional meth-odologies. The use of such a formal specificationprovides the context to validate and verify thesystem in the solution space, obtaining a softwareproduct that is functionally equivalent to thespecification as we will show later on in this paper.Naturally, we have had to introduce relevantinformation to address specific features of OASISin these diagrams (object model, dynamic modeland functional model). Nevertheless, this is alwaysdone preserving this external view which iscompliant with the most extended modelingtechniques (as stated above). Only the informationwhich is relevant for filling a class definition inOASIS must be introduced. In this way, the aridformalism is hidden from the modeler when he isdescribing the system by making him feel comfor-table using another (more!) conventional modelingnotation.

With respect to the notation, conceptual model-ing in the OO-Method uses UML-compliantdiagrams. According to the previous arguments,a main interest in the design of the OO-Method

O. Pastor et al. / Information Systems 26 (2001) 507–534 509

was to keep modelers from having to learn anothergraphical notation in order to model an informa-tion system. Having a formal basis allows us toprovide a modeling environment where the set ofneeded diagrams is clearly established. Let usintroduce the corresponding OO-Method set ofmodeling constructs and diagrams. The OO-Method collects the system requirements usingthree complementary models.

2.1.1. Object modelThe object model (OM) is a graphical model

where system classes including attributes, servicesand class relationships (aggregation and inheri-tance) are defined. Additionally, agent relation-ships are specified to state the services that objectsof a class are allowed to activate. The correspond-ing UML base diagram is the class diagram, wherethe additional expressiveness could be introducedby using the needed stereotypes which is a usefulUML facility.

Fig. 1 shows an example of an OM instance (aconventional library system with readers, books

and loans). It can be seen that classes and theirrelationships are basically depicted using the well-known UML class diagram notation. For in-stance, the arrow between reader and unreliable

reader denotes that unreliable reader is a specia-lization of reader. And the loan composite classrepresents an aggregation between the componentclasses book and reader.

Agent relationships are represented by using anagent stereotype connecting the associated clientclass and server class services. In the example, theobjects of the reader class can activate the servicesloan() and return() of the book class. The specificserver class services that can be activated by agiven client class must be introduced as additionalagent stereotype information.

Shared services (those that are included in thespecification of more than one class, representing asynchronous communication mechanism betweenthe objects involved in their occurrence) arerepresented by using a shared stereotype connect-ing the associated services with the correspondingclasses. In the example, the services loan() and

Fig. 1. Object model for the library system.

O. Pastor et al. / Information Systems 26 (2001) 507–534510

return() are shared between the classes book andreader.

We must specify additional information in theOM to complete the formal description of thereader class. Specifically, for each class the OMcaptures:

* attributes: to indicate if the attribute is con-stant, variable or derived,

* services: name of the services with theircorresponding arguments, distinguishing thenew and destroy class services,

* derivations: derivation expressions for thederived attributes (those whose value is depen-dent on other attributes),

* constraints: well-formed formulas stating con-ditions that objects of a class must satisfy,

* relationships: specific information associated toaggregation and inheritance hierarchies. Moreprecisely,* for aggregated classes, to specify if we have

an association or a composition (followingthe UML characterization),2 and if theaggregation is static or dynamic.

* for inheritance hierarchies, to specify ifa specialization is permanent or temporal.In the former case, the correspondingcondition on constant attributes must char-acterize the specialization relationship; in thelatter, a condition on variable attributes orthe carrier service that activates the child rolemust be specified.

2.1.2. Dynamic modelThe system class architecture has been specified

using the OM. Additionally, basic features, such aswhich object life cycles can be considered valid,and which interobject communications can beestablished, have to be introduced in the systemspecification. To do this, the OO-Method proposesa dynamic model. It uses two kinds of diagrams.State transition diagrams. The state transition

diagram (STD) is used to describe correct beha-

viour by establishing valid object life cycles forevery class. By valid life, we mean an appropriatesequence of states that characterizes the correctbehavior of the objects that belong to a specificclass.

Fig. 2 shows a simple STD for the reader class.The corresponding UML base diagram is the statediagram. Every service occurrence (i.e. new read-

er()) is labeled by the agent (LIB)rarian that isallowed to activate it. In this example, the *denotes that any valid agent class can activate thetransition. As the only valid agents for new-

reader() are objects of class LIBRARIAN, bothrepresentations are equivalent.

Transitions represent valid changes of state thatcan be constrained by introducing conditions.They follow the syntax shown in Fig. 3. Precondi-tions are those conditions defined on the objectattributes that must hold for a service to occur.Control conditions are conditions defined onobject attributes to avoid the possible non-determinism for a given service activation. In theexample, once a reader is in the state labeledreader0, if a loan service is activated, the objectwill move to the reader1 state. Here, if a returnservice occurs, the selected transition will be theone satisfying the corresponding condition control(book number ¼ 1 or book number > 1).Interaction diagram. The interaction diagram

(ID) specifies the interobject communication. Wedefine two basic interactions: triggers, which are

Fig. 2. State transition diagram for the reader class.

Fig. 3. Syntax for transitions in the STD.

2 In this way, the concept of aggregation in OO-Method

includes the concepts of association and composition provided

by UML as special cases.

O. Pastor et al. / Information Systems 26 (2001) 507–534 511

object services that are activated in an automatedway when a condition is satisfied, and globalinteractions, which are transactions involvingservices of different objects.

There is a STD diagram for every class, but onlyone ID for the whole system, where the previousinteractions will be graphically specified. Fig. 4shows a simple interaction diagram for ourexample. In this case, the UML base diagramused to capture this expressiveness is the colla-boration diagram. In the example, we haveone trigger indicating that a triggered action(reader.punish()) must be activated when thebook number attribute of a reader is equal to10. Trigger specifications follow the syntax shownin Fig. 5. The first component is the destination(the object(s) to which the triggered event isaddressed). This trigger destination can be thesame object where the condition is satisfied (self),or a specific object (specifying the oid involved) orthe entire class population if we are broadcastingthe event (class). Finally, the triggered serviceand its corresponding triggering relationship aredeclared.

Global interactions are graphically specifiedby connecting the services involved in thedeclared interaction. These services are repre-sented as solid lines linking the objects (boxes)that provide them.

2.1.3. Functional modelA correct functional specification is a shortcut

for many of the most extended OO Methods.

Sometimes, the model used breaks the homogene-ity of the OO models, as happened with the initialversions of OMT, which proposed using thestructured DFDs as a functional model. The useof DFD techniques in an object modeling contexthas been criticized for being imprecise, mainlybecause it offers a perspective of the system (thefunctional perspective), which differs from theother models (the object perspective). Othermethods leave the free-specification of the systemoperations in the hands of the designer. The OO-Method functional model (FM) is quite differentwith respect to these conventional approaches. Inthis model, the semantics associated to any changeof an object state is captured as a consequence of aservice occurrence. To do this, it is declarativelyspecified how every service changes the object statedepending on the arguments of the serviceinvolved, and the object’s current state.

A clear and simple strategy is given for dealingwith the introduction of the necessary informa-tion. The relevant contribution of this functionalmodel is the concept of the categorization ofattributes. Three types are defined: push-pop,state-independent and discrete-domain based.Each type will fix the pattern of informationrequired to define its functionality.

In short Push-pop attributes are those whoserelevant services increase, decrease or reset theirvalue, State-independent attributes are thosehaving a value that depends only on the latestservice that has occurred, and Discrete-domainvalued attributes are those that take their valuesfrom a limited domain. The object reaches aspecific state, where the attribute value can bespecified, through the activation of carrier orliberator services.

To illustrate, Fig. 6 shows the functional modelfor the attribute book number of the reader class.

Fig. 5. Syntax for trigger specification.

Fig. 6. Functional model for the attribute book number of the

reader class.

Fig. 4. Interaction diagram showing a triggered action.

O. Pastor et al. / Information Systems 26 (2001) 507–534512

This attribute is categorized as a push-popbecause its relevant services increase or decreasetheir value by a given quantity. In the example,reader:loan() has the increasing action and read-er:return() has the decreasing action (reader is avariable indicating which event agents are the validones).

This categorization of the attributes is acontribution of the OO-Method that allows us togenerate a complete OASIS specification in anautomated way, where a service functionality iscompletely captured. More detailed informationcan be found in [13].

2.2. The OASIS formal specification

Taking the three previous models as a startingpoint, a corresponding formal and object-orientedOASIS specification is obtained in an automaticway. The resultant specification acts as a high-levelsystem repository. This is a main feature in theOO-Method approach: each piece of informationintroduced in the conceptual modeling step has acorresponding formal counterpart, which is repre-sented as an OASIS concept. We could view thegraphical modeling environment associated to theOO-Method as an advanced graphical editor forOASIS specifications. Therefore, an introductorypresentation of the OASIS specification languageis needed in order to have a complete view of thepresented approach.

Fig. 7 shows the OASIS specification for thereader class which is automatically obtained fromthe conceptual model. The mapping from con-ceptual modeling constructs to OASIS conceptswill be introduced in the Subsection 2.3. Beforethis, let us take a look at the reader classspecification to explain the meaning of thedifferent sections that integrate its formal descrip-tion.

A class in OASIS is made up of a class name(reader), an identification function for instances(objects) of the class and a type or template that allthe instances share.

The identification function (by reader code),characterizes the naming mechanism used byobjects. It gives a set of surrogates belonging toa predefined sort or to a sort defined by the user

(the so-called domains in OASIS). They areimported in the class definition. The most usualare predefined as int, nat, real, bool, char, stringand date. They represent numbers, Boolean

values, characters, strings and dates in aparticular format. New domains can be introducedin a specification by defining the correspondingabstract data type.

A type is the template that collects all theproperties (structure and behavior) which areshared by all the potential objects of the class

Fig. 7. OASIS specification for the reader class.

O. Pastor et al. / Information Systems 26 (2001) 507–534 513

being considered. Syntactically, it can be forma-lized as

* a signature, which contains sorts, functions,attributes (constant, variable and derived, seeconstant attributes and variable attributes sec-tions in Fig. 7) and events to be used private

events and shared events as can be seen inFig. 7,

* a set of axioms, which are formulas in adynamic logic,

* a process query as a set of equations withvariables of a sort process that are solvedin a given process algebra. When thesevariables are instantiated, we have the groundterms that represent possible lives of instances(objects).

The semantics of OASIS is defined by means ofKripke [16] structures ðW ; t;rÞ which includean universe of states w: We associate an accessi-bility relation r to each class in such a way thata pair of states ðs; tÞ is in that relation if and onlyif there is a transition going from the state s tothe state t: Let us call W the set of all possibleworlds reachable by an object. Let us call F the setof state well formed formulae (wff) being evaluatedover the current state of the object. Let A be the setof ground actions of the object template and 2%

A

the set of all possible instantiated steps. In theformal OASIS framework a step is a set ofconsistent services that occur in a given instantof an object life. The functions t and r are definedas follows:

t : F-2W ;

r : 2%A-ðW-WÞ:

The function t indicates in which worlds a stateformula (in first order predicate logic) is true. Thefunction r is a binary relation between worlds(declarative semantics of the language). Given astep mA2%

A; w;w0AW then ðw;w0ÞArðmÞ if and onlyif the occurrence of m implies the transitionbetween the worlds w and w0:

After introducing the OASIS syntax and seman-tics, we are going to briefly introduce the quotedset of axioms and the process query that formalizea OASIS type. This is specially relevant because

they constitute the core of the information used asinput to undertake the automated software pro-duction process.

In OASIS, we have the following kinds ofdynamic formulas (set of class axioms)

* Valuations are formulas of the form F½a�F0

whose semantics is given by defining a rfunction that, from a ground service a returnsa function between possible worlds

rðaÞAW-W : ð1Þ

In other words, as any valid state is a possibleworld for an object, the r function determineswhich transitions between object states are validafter the execution of a service a: In the exampleof Fig. 7, we have the following valuations:

½loanðÞ� book number ¼ book numberþ 1; ð2Þ

½returnðÞ� book number ¼ book number� 1: ð3Þ

It is important to realize that, within thisdynamic logic environment, the formula F isevaluated in sAW ; and F0 is evaluated in rðaÞ;with rðaÞ being the world represented by theobject state after the execution in s of the serviceconsidered.

* Derivations are formulas of the type F-F0:They allow us to define derived attributes ðF0Þ interms of the given derivation expression (statedin F). They basically differ from the valuationformulae in the fact that this derived valuationis done in a unique state. In our example thereare no derivations.

* Integrity constraints are formulas that must besatisfied in every world. We distinguish betweenstatic and dynamic. Static integrity constraintsare those defined for every possible world. Theymust always hold. In the example:

static book numbero10: ð4Þ

On the other hand, dynamic integrity con-straints are those that relate different worlds.They require the use of a temporal logic, withthe corresponding temporal logic operators.

* Preconditions are formulas with the template:F½a� false; where F is a formula that musthold in the world previous to the execution ofservice a: Only in the worlds where F holds, is a

O. Pastor et al. / Information Systems 26 (2001) 507–534514

allowed to occur. If :F holds, the occurrence ofa gives no state as successor. We have thefollowing precondition in the reader specifica-tion:

:ðbook number ¼ 0Þ ½librarian :

destroy readerðÞ� false; ð5Þ

or, in a more convenient way for specificationpurposes, we can write

librarian : destroy readerðÞ if book number ¼ 0:ð6Þ

* Triggers are formulas of the form F½:a� false;where :a is the service negation.3 If F holdsand a service other than a occurs, then thereis no successor state. This forces a to occur orthe system remains in a blocked state. Forinstance, using the appropriate dynamic for-mula (where we include information about thedestination in the triggered service, according tothe trigger expressiveness presented when theOO-Method ID was introduced), we willdeclare:

book number ¼ 10 ½:ðSelf :: punishðÞÞ� false:ð7Þ

Once more, we will write in an equivalent butmore conventional way for specification pur-poses:

Self :: punishðÞ if book number ¼ 10: ð8Þ

Thus, triggers are services which are activatedwhen the condition stated in F holds. The maindifference between preconditions and triggerscomes from the fact that in triggers there is anobligation to activate a service as soon as thegiven condition is satisfied. In this way triggers,allow us to introduce internal activity in theobject society that is being modeled.

In any of these dynamic formulas, F; F0 arewell-formed formulas in a first order logic thatrefer to a given system state characterized by theset of values attached to attributes of objects in thestate or world considered.

In OASIS, an object is defined as an observableprocess [17]. The process specification in a classallows us to specify object dynamics and deter-mines the access relationship between the states ofinstances. Processes are constructed by usingevents as atomic services. However, the designeralso has the choice of grouping events in executionunits, which are called transactions.

The molecular units that are the transactionshave two main properties:

(1) they follow an all-or-nothing policy withrespect to the execution of the involved events:when a failure happens during a transactionexecution, the resultant state will be the initialone,

(2) the non-observability of intermediate states.

We will finish this section introducing theprocess specification of the reader class.

reader ¼ librarian : new readerðÞKreader0;

reader0 ¼ librarian : destroy readerðÞ

þ loanðÞKreader1;

reader1 ¼ if book number ¼ 1 returnðÞKreader0

þ ðif book number > 1 returnðÞ

þ if book numbero10 loanðÞÞKreader1;

þ punishKreader1:

ð9Þ

The execution of processes is represented by termsin a well-defined algebra of processes, which isbased on the approach presented in [18]. It allowsus to declare possible object lives as terms whoseelements are transactions and events. Everyprocess can be rewritten to a term in a basicprocess algebra BPAde; with the K (sequence) andþ (alternative) process operations. This providesan implementation of concurrence based onarbitrary interleaving.

This is a short introduction of the currentformal features of OASIS. The reader can find amore detailed description of previous OASISversions in [15,19].

3 It means that a does not occur, and what does occur is not

specified.

O. Pastor et al. / Information Systems 26 (2001) 507–534 515

2.3. The formal specification as the systemrepository

After having presented the OO-Method con-ceptual constructs and the OASIS formal conceptsassociated to them, we are going to introduce themappings that generate a textual system represen-tation (that is a specification in OASIS) taking asinput the graphical information introduced in anyOO-Method conceptual model. This formal speci-fication has in fact been obtained using conven-tional techniques, and constitutes a solid systemdocumentation to obtain a final software productwhich is compliant with the initial requirements, asrepresented in the source conceptual model.

According to the class template introduced inthe previous section, let us identify the set of OO-Method conceptual constructs and their corre-sponding OASIS representation.

The system classes are obtained from the objectmodel. For each class, we have

* its set of (constant, variable or derived)attributes,

* its set of services, including (private and shared)services and local transactions,

* the integrity constraints specified for the class,* the derivation expressions corresponding to the

derived attributes.

If we are dealing with a complex class (thosedefined by using the provided aggregation andinheritance class operators), the object model alsoprovides the particular characteristics specified forthe corresponding complex aggregated or specia-lized class.

With the information given by the object model,we basically have the system class structure, wherethe signatures of the classes are precisely declared.As we have seen above, the dynamic model usestwo kind of diagrams: STD and ID. From theSTD, we obtain:

* service preconditions (those formulas labelingthe service transitions),

* the process definition of a class, where thetemplate for valid object lives is fixed.

And from the ID, we complete two otherfeatures of an OASIS class specification:

* trigger relationships,* global transactions (those involving services of

different class objects).

Finally, the functional model gives the dynamicformulas related with evaluations, where the effectof services on attributes is specified.

Having clearly defined the set of relevantinformation that can be introduced in an OO-Method conceptual model, the formal specifica-tion corresponding to it provides a precise systemrepository where the system description is com-pletely captured, according to the OASIS object-oriented model. This allows us to undertake theimplementation process (execution model) from awell-defined starting point, where the pieces ofinformation involved are meaningful because theycome from a finite catalog of conceptual modelingconstructs, which, furthermore, have a formalcounterpart in OASIS.

2.4. Execution model

The OASIS specification is the source for anexecution model that must accurately state theimplementation-dependent features associated tothe selected object society machine representation.In order to easily implement and animate thespecified system, we predefine a way in which usersinteract with system objects. The template pre-sented in Fig. 8 is used to achieve this behavior.

The process starts by logging the user into thesystem (step 1) and providing an object systemview (step 2) determining the set of objectattributes and services that it can see or activate.After the user is connected and has a clear object

Fig. 8. The execution model template process.

O. Pastor et al. / Information Systems 26 (2001) 507–534516

system view, he can then activate any availableservice in his worldview. Among these services,there will be observations (object queries) or localservices or transactions served by other objects.Any service activation (step 3) has two steps: buildthe message and execute it (if possible). In order tobuild the message, the user has to provideinformation to identify the object server4 (step3.1). Subsequently, he must introduce servicearguments (step 3.2) of the service being activated(if necessary). Once the message is sent (step 3.3),the service execution is characterized by theoccurrence of the following sequence of actionsin the server object:

* check state transition (step 3.4) which is theprocess of verifying that a valid transition existsin the OASIS specification for the selectedservice in the current object state,

* the precondition satisfaction (step 3.5) indicatesthat the precondition associated to the servicemust hold.

If any of these actions do not hold, an exceptionwill arise and the message is ignored. Otherwise,the process continues with:

* the valuation fulfillment (step 3.6) where theinduced service modifications take place in theinvolved object state,

* the verification of integrity constraints in thefinal state (step 3.7), to assure that the serviceexecution leads the object to a valid state. If theconstraint does not hold, an exception will ariseand the previous change of state is ignored,

* the verification of the set of condition-actionrules that represents the internal system activityafter a valid change of state (step 3.8). If anyof them hold, the specified service will betriggered.

The previous steps guide the implementation ofany program to assure the functional equivalencebetween the object system specification collected inthe conceptual model and its reification in animperative programming environment.

Now we are going to describe how to link theformal specification captured in the conceptualmodeling step with the abstract execution modelpresented above.

3. A tiered component architecture for the

execution model

The architecture for the execution model isbased on the common three-tiered architecture[20]. We propose a multi-tiered architecture thatincludes the separation of responsibilities impliedby the classic three-tiered architecture.5 Theseresponsibilities are assigned to software objects.

This architecture, which is organized in terms ofsoftware classes, is shown in Fig. 9. In this figurethere are three basic layers. The user interface iscomposed of components that handle the pre-sentation of information between the user and theapplication. The application logic is itself com-posed of the following layers:

* application logicFproblem domain objects:objects representing domain concepts that fulfill

Fig. 9. An n-tiered architecture for the execution model.

4The existence of the object server is an implicit condition for

executing any service, unless we are dealing with the service

new.

5As we will see later on in this paper, the application logic is

broken down into finer layers.

O. Pastor et al. / Information Systems 26 (2001) 507–534 517

application requirements according to theOASIS specification,

* application logicFservices objects: non-pro-blem domain objects that provide supportservices, such as interfacing with a database(commonly called mediators [21] and/or data-base brokers [22]). Specifically, we have pro-posed two mediators:* a mediator for database interaction calleddatabase mediator. It transforms objectoperations to the corresponding databasecalls and vice versa,

* a mediator for system repository interactioncalled repository mediator. It provides accessto the metainformation stored in the reposi-tory of the specification.

The persistence layer represents the selectedpersistent object system. We work with relationaldata bases (RDB), object-relational data bases(ORDB) and object-oriented data bases (OODB)as is usual in current industrial environments.

Now, we are going to provide an overview of thestructure of these tiers, showing the components,their interfaces, and the dependencies betweenthem.

3.1. User interface

The user interface is composed of three mainvisual components: the access control, the sys-tem view and the service activation components.

The access control component (see Fig. 10)constitutes the software representation of the firststep of the execution model (identify the user). Itprovides the interface IAccess which allows usersto identify themselves in the system as wasexplained in Section 2.4. Specifically, this interface

offers the service validateAccess that gets theObject Identifier and Class Name properties toproperly identify an object as a member of thesystem that is being prototyped.

In our library example, the implementation ofthis component will produce the interface shown inFig. 11:

The system view component constitutes thesoftware representation of the second step ofthe execution model (obtain the object systemview). It is important to note that the agentrelations specified in the OM give us the neededinformation to generate this component in anautomated way. This is done by defining theinterface ISystem that provides the servicesneeded to obtain an object system view. Inother words, these services provide the function-ality to obtain the classes that the user isallowed to interact with (getList of Classesservice in Fig. 12), and they provide the function-ality to obtain the services that the user canactivate for each class (getList of Servicesservice in Fig. 12). The visual representation ofthe component is a typical frame with a menu barfor classes and menu items for services.

The implementation of this component in thelibrary example produces the interface shown inFig. 13.

Finally, the service activation component con-stitutes the software representation of steps 3.1(identify the object server) and 3.2 (introduceservice arguments). The service declaration

Fig. 10. Interface specification of the access control compo-

nent.

Fig. 11. An instance of the access control component for the

library example.

O. Pastor et al. / Information Systems 26 (2001) 507–534518

included in the OM for every class provides theinformation that permits the generation of thecomponent in an automated way.

More precisely, this component provides theinterface IServices which offers the service neededto obtain the arguments for a service activation(getList of Arguments service in Fig. 14).

The specific implementation of this componentfor our example is shown in Fig. 15.Besides creating edit controls for introducingthe corresponding service arguments, theprocess of generating the component includesthe creation of three control buttons withthe intention of executing the service (the OKbutton), cancelling it (the CANCEL button) orproviding some help information (the HELPbutton).

The user interface presented above is used forproper interaction between the user and theapplication. Having presented the user framework,the next step is the application logic layer.

3.2. Application logic

This section provides two important contribu-tions:

* a specific strategy to translate the formalspecification of the system into an object-oriented software implementation,

* a set of services to address the persistence of thedomain objects.

3.2.1. Application logicFproblem domain objectsA concrete class is generated for each domain

class specified in the conceptual modelingstep. Its responsibilities are to encapsulate theapplication logic according to the underlyingOASIS specification.

This step includes a specific strategy to translatethe formal specification that represents a domainclass into an object-oriented software implementa-tion. The translation process has two parts. Thefirst one deals with how the domain classes canimplement the algorithm to activate a serviceaccording to the execution model philosophy.The second one deals with how to map the OASISspecification to the code of the resultant specificclasses.

3.2.1.1. Implementing the algorithm to activateservices. The design of the domain classes toimplement the algorithm used to activate a serviceis based upon the Template method pattern [23](see Fig. 16). In this figure, the most importantpublic method in the OASIS abstract class isactivateService, a template method which takesthe name of the service, the object identifier andthe arguments of the service as parameters andreturns a Boolean value that indicates whether the

Fig. 12. Interface specification of the system view component.

Fig. 13. An instance of the system view component for the

library example.

O. Pastor et al. / Information Systems 26 (2001) 507–534 519

service has been successfully activated. When amessage is sent to an object server, a correspond-ing activateService must be executed. This acti-vateService call constitutes the implementation ofstep 3.3 of the execution model. The activateSer-vice template method implements the rest of theOO-Method execution model through the activa-tion of the following methods:

* loading the involved object in memory from itsstorage media (method mediator.materialize),

* checking that a valid transition exists for theservice in the current object state. This is doneby the method checkStateTransition (step 3.4of the execution model),

* checking the corresponding service precondi-tion through the method checkPreconditions

(step 3.5 of execution model),* execution of the corresponding service modifi-

cations, which is done by the method valuations(step 3.6 of the execution model),

* checking the integrity constraints in the finalstate. This task is performed by the method

checkIntegrityConstraints (step 3.7 of theexecution model),

* verifying if any trigger relationship is satisfied,task performed by the method checkTriggers

(step 3.8 of the execution model),* making the involved object persistent in the

corresponding data storage media (methodmediator.dematerialize).

The activateService template method definesvarying parts of the algorithm. Specifically, theparticulars of how the activation of a service canvary depending on the service that is beingactivated. These responsibilities are left as primi-tive operations that the subclasses must define. Wewill have such a subclass for every domain class.The structure of these subclasses can be seen inFig. 17. For instance, checkPreconditions is aprimitive operation for the template methodactivateService. Consequently, each domain classhas to define how to implement the correspondingbody of this primitive operation.6 In this case, thebody of this operation must be implementedaccording to the preconditions associated to thedomain class in the OASIS specification for thatparticular service. The concrete implementation ofthis checkPreconditions method will be shownlater on.

Having presented the design pattern that imple-ments the algorithm to activate a service, the nextstep is to describe the design of the domain classesin order to implement every section of the OASISspecification (i.e. how the primitive operationsproposed in the algorithm presented above areimplemented).

Fig. 14. Interface specification of the service activation component.

Fig. 15. An instance of the service activation component for

the library example.

6Obviously, we will declare a primitive operation for every

checking process in the execution model.

O. Pastor et al. / Information Systems 26 (2001) 507–534520

3.2.1.2. Mapping an OASIS specification to an OOimplementation. We are going to present thegeneral mapping algorithms, and then we willapply them to the library example using Java asthe programming language.

Mapping preconditions. A checkPreconditions

method has to verify if given a service e; itsprecondition holds. The generation process definesa protected method checkPreconditions withServiceName as an argument. The body of this

Fig. 17. The domain classes.

Fig. 16. The OASIS abstract class.

O. Pastor et al. / Information Systems 26 (2001) 507–534 521

method must be generated according to thefollowing steps:

(1) For each class service e having a preconditionpðeÞ we have to generate:(a) A conditional structure that checks

whether pðeÞ holds,(b) an exception sentence for showing an

error message when the precondition ofservice e has been violated.

Coming back to our library example, let us takeanother look at the section of the OASISspecification that represents the preconditionsassociated to the class reader. Fig. 18 shows threedifferent views for the preconditions. The OO-Method and OASIS views are views in theproblem space. The OO programming languageview is the view in the solution space.

In this way, Fig. 18 illustrates how a precondi-tion can be viewed from various points of view.From the viewpoint of the OO-Method a pre-

condition is a well-formed formula (wff) that labelsa transition in the STD according to the syntaxthat was presented in Fig. 3. From the viewpointof the OASIS formal specification language, aprecondition is the wff representing the corre-sponding dynamic formula in a textual manner.From the viewpoint of object-oriented program-ming, a precondition is a conditional sentence thatmust be tested.

In conclusion, preconditions are mapped to anobject-oriented programming language using aconditional test. If the condition does not holdthen an exception will arise. The error message canbe customized to any particular service, declaringit when specifying a precondition in the conceptualmodeling step. This is why in Fig. 18 the custo-mized error message ‘‘Precondition violation. Thereader has books’’ appears: it has been specified forthe destroy-reader service precondition.Mapping state transition diagrams. There are

basically three different ways to implement the

Fig. 18. Mapping preconditions for the reader class.

O. Pastor et al. / Information Systems 26 (2001) 507–534522

verification of a valid state transition: conditionallogic, the state pattern [23], or a state machineinterpreter that runs against a set of statetransition rules.

It has been recognized that the applicability ofthe state pattern may not be suitable if there aremany states in the system [23]. The implementa-tion of a state machine interpreter is beyond thescope of our proposal. Consequently, we havechosen the use of conditional logic.

An STD belonging to a given class C could beseen as a directed graph G ¼ ðS;TÞ such that:

* S is a set of possible object states that arerepresented by graph nodes, and

* T is a set of state transitions represented bylabelled arrows.

A state transition tA T is a tuple ðsi; sj ; e; p; ccÞwhere

* si is the initial state of t;* sj is the final state of t;* e is a service of class C signature,* p is an optional precondition attached to e; and* cc is an optional control condition of transitiont:

In order to generate the checkStateTransitionmethod that verifies if a valid transition exists forany service in the current object state, we define aprotected method checkStateTransition with Ser-viceName as an argument. The body of thismethod must be generated according to thefollowing steps:

(1) For each state si=i¼0::nA S we have to generate:

(a) A conditional structure that checks if thecurrent object state is equal to si;

(b) for each service e such that (tAT=t ¼ðsi; sj ; e; ; ccÞ and si is equal to the currentobject state, we have to generate aconditional sentence that checks if Servi-ceName is equal to e and the controlcondition cc of e holds.(i) Define an assignment sentence that

assigns the sj value to the currentobject state if the conditional sen-tence defined in step (b) holds.

(ii) An exception sentence must begenerated to determine whether avalid transition exists in the STD,meaning by valid that the conditionsdefined in step (b) hold. The gener-ated error message is ‘‘state transi-tion violation’’.

It is important to note that in the structure of theclass that implements this method we must definean additional attribute (which is not present in thesignature of the class) to store the current objectstate in the STD. This attribute will have itscounterpart in the data layer in order to make theobject state in the STD persistent.

Fig. 19 shows how state diagrams are mapped inthe solution space using conditional logic. Foreach concrete state specified in the STD (in theexample of the reader class, these states are non-existence, reader0, reader1 and post-mortem),we must declare a conditional structure. Thisstructure must ensure that a valid transition existsfor the service that is being activated. If thisprocess succeeds, the corresponding change ofstate is carried out. Otherwise, an exception willarise. For example, let us suppose that the currentstate of a reader object is reader0 and that theservice that is being activated is the service loan().The checkStateTransition method determines thatthis is a valid transition and sets the new state ofthe reader object to reader1.Mapping valuations. The valuations are mapped

in the solution space as a method of the domainclass called valuations. This method implementsthe change of the object attribute values accordingto their categorization in the FM. Valuations inthe FM are defined by using formulas of the formF½a�F0 where F and F0 are wff whose semantics isthe following: if service a is activated and theobject is in the state F; the effect of a serviceexecution will leave the object in the state F0: Theformula F must be true in the object state previousto the occurrence of service a: The formula F0

specifies the effect that the service executed hasover object attribute values.

The generation process defines a protectedmethod valuations with ServiceName and Para-meters(that are the arguments of ServiceName)

O. Pastor et al. / Information Systems 26 (2001) 507–534 523

Fig. 19. Mapping the state diagram for the reader class.

O. Pastor et al. / Information Systems 26 (2001) 507–534524

as arguments. The body of this method must begenerated according to the following steps:

(1) For each class service e we have to generate:(a) A conditional structure to determine

which service has been activated. Thisstructure will check if ServiceName isequal to e:

(b) A call to a method that must have thesame name as the service declared in thesystem specification. This method has tobe a protected method that implements

the semantics of the valuation formulasfor service e: The body of this methodhas to be built generating the following:(i) A conditional sentence that checks if

the object is in the state F:(ii) A set of assignment sentences that

change the object attributes in theway that the formula F0 specifies.

An example is introduced in Fig. 20. Condi-tional logic is used to determine which service mustbe activated. The execution of the corresponding

Fig. 20. Mapping valuations for the reader class.

O. Pastor et al. / Information Systems 26 (2001) 507–534 525

service (loan or return) is carried out according tothe effect specified in the FM. Let us suppose thatthe service loan() has been activated for a readerobject. The effect of this service activation in theattribute book number will be an increment in itsvalue.Mapping integrity constraints. A checkIntegrity-

Constraints method has to verify if the valuationsexecution leads the object to a valid state. Thegeneration process defines a protected methodcheckIntegrityConstraints with no arguments. Thebody of this method must be generated accordingto the following steps:

(1) For each integrity constraint formula F; wehave to generate the following:(a) A conditional structure that checks if F

holds,(b) an exception sentence for showing an

error message when the integrity con-straint has been violated.

In the example, the method checkIntegrityCon-

straints (see Fig. 21) will check whether the

conditional expression book numbero10 is satis-fied.

Dynamic constraints are more complex toimplement. They must be evaluated throughoutthe entire life of an object. For implementationpurposes, this complex mapping is based on thework presented in [24], that provides a mechanismto support the implementation of dynamic con-straints in imperative environments which lack thepower of temporal logic. The particular imple-mentation of the previous algorithm adapted forthe OO-Method dynamic integrity constraints canbe seen in detail in [25].Mapping triggers. The effect of a triggering

action has traditionally been a singular researchtopic in the database community, specially in thecontext of active DBMS. A common proposal of aknowledge model for active systems has been theevent-condition-action (ECA) rules mechanism.These rules are composed of an event that triggersthe rule, a condition that describes a specificsituation, and an action to be performed if thecondition is satisfied. In this context, various

Fig. 21. Mapping constraints for the reader class.

O. Pastor et al. / Information Systems 26 (2001) 507–534526

proposals have been presented to include this rulemechanism in active systems.

For our purposes, we only consider a subset ofECA rules. We define an OASIS trigger as anactive rule where; the event is the current servicethat is being activated, the condition is the wff thatmust be evaluated, and the action is the OASISaction that must be activated if the condition issatisfied. We also consider that the effect of thetrigger acts in the context of the object society thatis being specified.

Taking into account these limitations, wepropose a simple strategy of implementation. AcheckTriggers method has to check whether thecondition associated to the trigger holds, in thiscase the corresponding service is activated. Thegeneration process defines a protected methodcheckTriggers with no arguments. The body ofthis method must be generated according to thefollowing steps:

(1) For each trigger formula F½:a� false; we haveto generate:(a) A conditional structure that checks if F

(triggering condition) holds,(b) a sentence that calls service a when F

holds. This sentence has to be prepared tothrow an exception if the service a is notavailable (because the object server doesnot exist, the precondition and the statetransition do not hold or the integrityconstraints are not verified).

We can see in Fig. 22 the code generatedto implement the checking of the triggerspecified in class Reader. In this case, if thecondition book number¼10 holds, the corre-sponding service (activateService(’’Punish’’))is activated.

This is how the code of the domain classes isgenerated starting from the formal OASIS speci-fication following a specific strategy. It is impor-tant to note that the use of this strategy to generatecode is not attached to any particular program-ming language. This is possible because the finalimplementation is obtained in an automated wayby programming the corresponding mappingsbetween conceptual model constructs and their

representation in a particular software develop-ment environment (Java in this paper).

Having obtained the full object-oriented imple-mentation, the next step is how to providepersistent facilities to the domain classes. Theapplication logicFservices objects layer is re-sponsible for this task.

3.2.2. Application logicFservices objectsThis layer encompasses non-problem domain

objects to ensure the persistence of the domainclasses. Independently of the DBMS selected forthe persistence layer (relational, object-relationalor object-oriented), software components intendedto interact with the database engine must beprovided. The components that provide services ofthis kind are normally called mediators. They actas the middleware that provides the needed inter-face for accessing data, manipulates them astemporary objects, and make them finally persis-tent after a service execution has been completed.For instance, if we work in a relational DBenvironment (see Fig. 23), an object/relationalmediator converts database table rows in instancesof objects where the services that we haveintroduced in the previous sections are applied.

For our purposes, we have designed twomediators. The first one, called database med-

iator, ensures that the domain classes havepersistent facilities. This component provides the

Fig. 22. Mapping triggers for the reader class.

O. Pastor et al. / Information Systems 26 (2001) 507–534 527

services needed to materialize and dematerialize

objects. The second one, called repository med-

iator ensures that the components of the userinterface can be properly customized. To do this,the repository mediator component providesservices to make queries to the system repository.These queries allow for the customization inruntime of the User Interface framework accord-ing to the specification stored in the systemrepository. In this way, the user interface can becompletely reused as a standard component UIframework for all prototype sessions.

3.3. Data model

At this level we have the data and the systemrepository. The former represents the data modelof the system that is being prototyped. The lattercontains the metainformation of the specification.It constitutes the data dictionary of the system. Itis important to note that both databases aregenerated in an automated way once the con-ceptual modeling step has been completed. How todo this in a Relational Data Base environment is awell-known process of translation, which can bedone in an automated way as shown in [3,26].Extensions to Object-Relational DB can also beaccomplished following a similar strategy, makinguse of the extended object-oriented DB features([27] shows how to implement an OASIS specifica-tion in an Oracle 8i DB).

4. Related work

From a global viewpoint, two approaches canbe distinguished when looking at the OO softwarespecification methods to model an informationsystem:

* the conventional OO methods,* the OO formal specification languages.

In both cases, the techniques used for represent-ing properties of software involve some kind ofnatural language, formal languages and diagramtechniques. Conventional, non-formal methodshave been proposed for the specification of soft-ware systems over the past twenty years. Firstfollowing the structured approach, later followingthe OO approach. Normally, they provide a set ofeasy-to-use diagram techniques with overlappingor ambiguous semantics and no formal support touse them. In general, one cannot tell by looking ata diagram what it represents (see [28] to find well-founded arguments on this topic). The meaning ofa diagram is given by a set of interpretation rules,which must be defined elsewhere. If these inter-pretation rules are not based on a preciseformalism, the diagram becomes meaningless. Bythis we mean that without such a precise defini-tion, the notation may be used to give a roughsketch of vague ideas but not to communicate ameaning unambiguously to others. In contrast, theuse of formal specification languages provides asolid mathematical background and deducibleformal properties such as soundness and comple-teness. However, their use tends to be too complexand unfriendly: their application requires signifi-cant abstraction and mathematical skills, and whathappens in practice is that existing tools do notsatisfactorily support the entire formal softwaredevelopment process.

In accordance with these arguments, a researchissue that comes up is that current and futurenotations should provide a precise semantics totake advantage of the positive features of both theconventional and the formal approaches. In recentyears, there has been increasing attention given tohow these approaches can be combined. We findattempts to achieve integration even within struc-tured analysis proposals. For instance, Statemateis a software kit and a notation for structuredanalysis that, in the interest of executability ofspecifications, defines actions performed by state-charts imperatively. The execution semantics ofStatemate is formally defined [29,30]. The mainproblem is that Statemate does not contain a

Fig. 23. Object/Relational mediator.

O. Pastor et al. / Information Systems 26 (2001) 507–534528

notation corresponding to a data model. There isonly a partial system view based on processes.Also, the way in which activity charts andstatecharts are put together into a coherent modelmust be clearly established to avoid inconsisten-cies.

Various proposals within the OO paradigm,have appeared in the literature with the objectiveof recognizing opportunities in order to advancethe state of the art beyond the conventional-formaldichotomy by picking the best ideas from bothapproaches. These global proposals can be classi-fied depending on the philosophy of how tointegrate the formal models in those well-knownconventional methods. Most approaches considerthe integration process in terms of how to capturethe information needed to build the formalspecification of the system from the conceptualmodel level.

The objective of the OMTROLL approach [31]is to assist designers with an OMT-compliantgraphical notation to build the formal specifica-tion of the system. This specification is based onthe TROLL specification language [32]. Thetextual specification has to be refined to a completesystem specification. The formal nature of TROLL(which uses a distributed temporal logic calledDTL [33]) helps to achieve concise and unambig-uous systems specifications as well as to developbetter CASE tools. In particular, OMTROLL hasa CASE support called TrollWorkbench [8,34].TBench provides a prototyping process that allowsfor generating an independently executable proto-type from a graphical conceptual specification.The prototype generated is a Cþþ program thatincludes the static/dynamic aspects of the systemand uses an Ingres database as a repository of thespecification. This approach shares the underlyingOO formal specification language (OASIS forOO-Method, Troll for OMTROLL) with theOO-Method. The main difference is that theTroll-WorkBench focuses on the validation ofspecifications and on the development of a tool formodel checking, while the OO-Method providesan implementation of an abstract execution modelto obtain a software product which is ready forexecution. Another difference arises which isrelated to modularization concepts: OMTROLL

works only with object classes. The OO-Methodprovides the notion of cluster to group classes inorder to deal with system complexity.

OBLOG [35] is another object-oriented ap-proach for software development that representsthe convergence of many efforts within the scopeof the European ESPRIT project informationsystems-correctness and reusability (IS-CORE).The OBLOG semantics is formalized in thecontext of the theory of categories. A CASE tool[36,37] for OBLOG specifications has been intro-duced, sharing the objective of going from systemspecification to code generation using a formalspecification language as its basis (OBLOG in thiscase). As in the OO-Method, this precise definitionmakes it possible to translate OBLOG specifica-tions to production code. Besides the particulardifferences in expressiveness between OBLOG andOASIS, OBLOG case views the automated gen-eration process as a transformation process basedon rewrite rules. Rules are written using a specificlanguage that must be known by designers,because the ability to customize the generatedoutput through the rules is a key issue. Theapproach of the OO-Method is closer to the ideaof a general code generator, where the key featureis the well-defined software representation of apredefined, finite catalog of conceptual modelingconstructs.

An approach that focuses more on levels offormalism is the object system analysis (OSA)model [9]. Its aim is to develop a methodthat enables system designers to work withdifferent levels of formalism, ranging frominformal to mathematically rigorous formalisms.In this context, this kind of tunable formalismmakes it possible for both theoreticians andpractitioners to work with the same model.This proposal also explores the difficultiesencountered in making model and languagesequivalent [11] and resolves these difficulties inthe context of OSA for a particular language. OSAalso has a CASE support called IPOST [10], whichgenerates a prototype from an OSA model in anautomatic way. The prototype generated is used tovalidate the requirements. Our approach providesa different kind of tunable formalism: the OASISexpressiveness is fully preserved, but it is presented

O. Pastor et al. / Information Systems 26 (2001) 507–534 529

to analysts according to a well-known conven-tional graphical notation (UML compliant). TheOO-Method also enforces the idea of having amodel-equivalent language (a language with a one-to-one correspondence to an underlying, execu-table model) by implementing the system specifica-tion in an automated way according to theexecution model provided by the OO-Method.This functional equivalence, which has beenestablished between specification and automatedgenerated code, constitutes an alternative opera-tional implementation of the model-equivalentlanguage metaphor.

A different approach is proposed by structured-object-based-formal language (SOFL), in [12]. Itsaim is to address the integration of formalmethods into established industrial software pro-cesses using an integration of formal methods,structured analysis and specifications, and anobject-based method. SOFL facilitates transfor-mation from requirements specifications in astructured style to a design in an object-basedstyle and from designs to programs in theappropriate style. In accordance with the previousarguments, the proposal attempts to overcome thefact that formal methods have not been widelyused in industry, by finding mechanisms to linkOO and structured techniques with formal meth-ods (VDM style semantics for its specificationmodules). In our opinion, combining structuredand OO techniques in a single method is not thebest idea because it makes it difficult to clarify themethod semantics. An effective tool supportbecomes necessary for checking consistency.Furthermore, an automated transformation ofprocess specification into programs has not yetbeen provided.

The toolkit for requirements and design en-gineering (TRADE) approach [38] provides aconceptual framework that distinguishes externalsystem interactions from internal components.TRADE contains techniques from structured andOO specification and design methods. A graphicaleditor called techniques for conceptual modeling(TCM) supports the TRADE framework. Themost interesting contribution is the ability ofintroducing techniques in a method-independentway: based on its conceptual framework, TRADE

shows that structured and OO analysis offersspecification techniques that can be combined toobtain a coherent software design specification.What the OO-Method provides is a precise subsetof those techniques provided by TRADE. Thetechniques chosen have a formal semantics givenby the OASIS object model. We go further in thesense that, once the techniques have been chosen, acatalog of conceptual modeling constructs iscreated to guide the process of generating codewhich is functionally equivalent to the sourceOASIS specification.

Another important contribution of the OO-Method is the clear separation between conceptualmodeling (problem space) and final softwarerepresentation (solution space). We would like topoint out the existence of previous work in thisdirection. In JSD [39] and Syntropy [40], thedistinction between a universe of discourse decom-position and a software specification is made fullyexplicit: the decomposition done in terms of theproblem space expressiveness is modeled sepa-rately from the decomposition of the softwareproduct, and the link between them is madeexplicit. As we have already argued, the OO-Method enforces this idea from a formal OO pointof view. Furthermore, the final software represen-tation is obtained in an automated way from thesource conceptual model.

To close this section, two well-known ap-proaches with industrial tool support providingsome kind of code generation features are com-pared with the OO-Method, in order to fix theoriginal characteristics of the OO-Method from apragmatic point of view. The selected approachesare Rational/UML [41] and Catalysis [42].

Generally speaking, the Rational/UML ap-proach towards modeling, as stated by J. Rum-baugh at a keynote speech in the OOPSLA’97 inAtlanta, is to provide users with a tool to makegraphical OO models using a variety of diagramsand notations. This allows users to work at aninformal level, writing down several views of thesystem, even if they are inconsistent.

The UML notation is a reference notation,allowing the same UML specification to beunderstood differently by different people. Inthat sense, UML is assumed to be non-compu-

O. Pastor et al. / Information Systems 26 (2001) 507–534530

table. All the methods based in some way inUML share this basic problem. Any attempt ofgoing from the specification (Problem Space) tothe final software product (Solution Space) ispresented in terms of a help for the unavoidableprocess of programming. In other words, after themodeling process, some programming activitiesmust be undertaken. All the approaches based onthe use of UML such as Rational, share the beliefthat in a real project the ability to customize thegenerated output by hand, is a key issue. Theexpression ‘‘automated code generation’’ is used inthe general sense of automatically producing anywritten information from models which arealready built. This typically includes source codeand several kinds of documentation, with theassumption that it is not reasonable to think that ageneral code generator will allow us to obtain afinal software product by just compiling theconceptual model.

The OO-Method introduces a basic new idea:going from the conceptual model to the finalsoftware product, following a precise and auto-mated process of translation of conceptual modelconstructs into their corresponding software re-presentations. This constitutes a step further whencompared with the UML based modeling toolssuch as Rational/Rose, because the resultant soft-ware components that reificate the conceptualmodeling constructs used by the method are clearlyidentified and generated in an automated way.

In this context, Catalysis is a UML-compliantmethodology for component and frameworkbased development; some underlying conceptsfrom this approach have been contributed by theauthors to the definition of the unified modelinglanguage (UML) 1.0, as submitted to the OMG inJanuary 1997. This makes the Catalysis approachclose in a natural way to those approaches basedin some way on UML, and it shares with them theproblems commented above.

In order to highlight the most original Catalysiscontributions, the following four key features mustbe considered:

* types: abstracting behavior using type models,* refinement: explicit mappings between levels of

abstraction.

* collaborations: abstracting joint behavior anddialogue,

* frameworks: a foundation for design composi-tion and reuse.

There are important improvements in theapproach such as:

* the use of a clear semantics for the diagramsincluded in the methodology,

* the introduction of the conformance checkconcept, to prove that each of the abstractoperations specified at a higher abstraction levelis mapped to the corresponding implementationoperations,

* the generalization of the framework concept,permitting construction of specification anddesign models by composition.

However, the software production process is stillviewed in the classical way of going from analysisto design to implementation in a non-automatedway and following a continuous process ofrefinement that relies completely on the modeler’sskills. Once again, a design review must focus itsentire attention on the refinement: firstly, the fineractions must be related to the more abstract ones,resolving the question of which sequences of fineractions induce each abstract one. Secondly, at afiner level of detail, more detailed type-models areneeded.

Furthermore, the models used at the ProblemSpace level are type models (based on the UMLclass diagrams syntax) and interaction diagrams(to indicate particular processing aspects). Follow-ing the UML tradition, the precise set ofconceptual modeling constructs needed to obtaina correct and complete Conceptual Schema isunclear.

Finally, frameworks are said to be one of themost relevant notions of the tool. A minimum setof frameworks that are used in the code generationprocess must be provided in order to use themethod. This set of frameworks does not guaran-tee a complete code generation. The particularcharacteristics of the final software productmust be added by hand at the Solution Spacelevel, using low-level code constructions thatmust be included in some way in the diagram

O. Pastor et al. / Information Systems 26 (2001) 507–534 531

expressiveness provided by the method. This isagain a basic difference with the automatedsoftware production process provided by theOO-Method.

As has been stated in this paper, the OO-Method takes a more formal approach towardsspecification, facing the problem of going fromspecification to code generation in some kind ofautomated way. What is new in the OO-Methodapproach is to consider that the process ofprogramming can be completely done at theconceptual model (Problem Space), where aprecise system specification is generated accordingto the OO-Method repository, (which is based on aformal OO model (OASIS)). The OO-Methodintroduces the idea of compiling the specificationto obtain a final software product ready to beexecuted (Solution Space).

5. Conclusions

Conventional object-oriented methodologieshave to provide a well-defined software develop-ment process by which the community of softwareengineers can properly derive executable softwarecomponents from requirements in a systematicway. Our purpose has been to address theseproblems in the context of a conceptual modelingapproach that has been introduced. The OO-Method can be seen as a environment computed-aided requirements engineering (CARE), where inorder to manage the whole software productionprocess, we focus on how to properly capture thesystem requirements. The resultant conceptualmodel specifies what the system is (problem space).Then, an abstract execution model is provided toguide the representation of these requirements in aspecific software development environment (solu-tion space, which is centered on how the systemwill be implemented).

The abstract execution model is based on theconcept of Conceptual Modeling Constructs. TheOO-Method provides a well-defined softwarerepresentation of these constructs in the solutionspace. A concrete execution model based on acomponent-based architecture has been intro-duced to deal with the peculiarities of compo-

nent-based systems. The implementation of thesemappings from problem space concepts to solutionspace representations opens the door to thegeneration of executable software components inan automated way. These software componentstogether constitute a software product that isfunctionally equivalent to the requirements speci-fication collected in the conceptual modeling step.

Summarizing, the most relevant contributions ofthis paper are the following:

* The detailed presentation of the OO-Methodapproach as a successful attempt to cover theentire software production process from an OOpoint of view in order to get the best fromconventional and formal methods.

* A process to support Component-based devel-opment within the OO-Method methodologicalapproach.

* A specific strategy to generate code based on aclear separation of component specification andcomponent implementation to enable technol-ogy-independent application design.

* A well-defined component-based framework toexecute the specification in the solution space.

These ideas are being applied in the context of acomponent-based development tool that has beencalled JEM. JEM is a Java-based implementationfor the OO-Method Execution Model. The basicpurpose of JEM is to animate conceptual modelscaptured with the OO-Method, over distributedinternet/intranet environments. JEM fulfills therequirements with respect to the model and thearchitecture proposed in this paper for the execu-tion model. A beta version of JEM can be reachedat: http://oomethod.dlsi.ua.es:8080/jem.

5.1. Research directions and further work

Our current line of research is focused onimproving the quality of the final software productthat is generated. This includes advanced featuressuch as a better user interface framework, opti-mized database access mechanisms for dealingwith distributed computing as well as how thestructure of the generated code affects the perfor-mance of the system.

O. Pastor et al. / Information Systems 26 (2001) 507–534532

References

[1] C. Rolland, A comprehensive view of process engineering,

in: B. Pernici, C. Thanos (Eds.), Proceedings of CAiSE’98

International Conference, Vol. 1413 of LNCS, Springer,

Berlin, 1998, pp. 1–24.

[2] R. Wirfs-Brock, B. Wilkerson, L. Wiener, Designing

Object Oriented Software, Prentice-Hall, Englewood

Cliffs, NJ, 1990.

[3] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W.

Lorensen, Object Oriented Modeling and Design, Prentice-

Hall, Englewood Cliffs, NJ, 1991.

[4] I. Jacobson, M. Christerson, P. Jonsson, G. Overgaard,

OO Software Engineering, a Use Case Driven Approach,

Addison-Wesley, Reading, MA, 1992.

[5] G. Booch, Object Oriented Analysis and Design with

Applications, 2nd Edition, Addison-Wesley, Reading,

MA, 1994.

[6] D. Coleman, P. Arnold, S. Bodoff, S. Dollin, H. Gilchrist,

F. Hayes, P. Jeremes, Object-Oriented Development: The

Fusion Method, Prentice-Hall, Englewood Cliffs, NJ,

1994.

[7] G. Booch, J. Rumbaugh, I. Jacobson, UML v1, Technical

report, Rational Software Corporation, 1997.

[8] J. Kush, P. Hartel, T. Hartmann, G. Saake, Gaining a

uniform view of different integration aspects in a proto-

typing environment, in: Proceedings of DEXA’95 Interna-

tional Conference, Vol. 978 of LNCS, Springer, Berlin,

1992, pp. 35–42.

[9] S.W. Clyde, D.W. Embley, S.N. Woodfield, Tunable

formalism in object-oriented systems analysis: meeting

the needs of both theoreticians and practitioners,

in: Proceedings of the OOPSLA’92 Conference on

Object-Oriented Programming Systems, Languages and

Applications, 1992, pp. 452–465.

[10] R.B. Jackson, D.W. Embley, S.N. Woodfield, Automated

support for the development of formal object-oriented

requirements specification, in: G. Wijers, S. Brinkkemper,

T. Wasserman (Eds.), Proceedings of CAiSE’94 Interna-

tional Conference, Vol. 811 of LNCS, Springer, Berlin,

1994, pp. 135–148.

[11] S. Liddle, D.W. Embley, S.N. Woodfield, Unifying

modeling and programming through an active, object-

oriented, model-equivalent programming language, in:

M.P. Papazoglou (Ed.), Proceedings of OOER’95 Inter-

national Conference, Vol. 1021 of LNCS, Springer, Berlin,

1995, pp. 55–64.

[12] S. Liu, A.J. Offutt, C. Ho-Stuart, Y. Sun, M. Ohba, SOFL:

A formal engineering methodology for industrial

applications, IEEE Trans. Software Eng. 24 (1) (1998)

24–45.

[13] O. Pastor, E. Insfr!an, V. Pelechano, J. Merseguer, J.

Romero, OO-Method: an OO software production envir-

onment combining conventional and formal methods, in:

A. Oliv!e, J.A. Pastor (Eds.), Proceedings of CAiSE’97

International Conference, Vol. 1250 of LNCS, Springer,

Berlin, 1997, pp. 145–158.

[14] O. Pastor, V. Pelechano, E. Insfr!an, J. G !omez, From

object oriented conceptual modeling to automated pro-

gramming in Java, in: T.W. Ling, S. Ram, M.L. Lee (Eds.),

Proceedings of 17th International Conference on Con-

ceptual Modeling (ER’98), Vol. 1507 of LNCS, Springer,

Berlin, 1998, pp. 183–196.

[15] O. Pastor, F. Hayes, S. Bear, OASIS: an object-oriented

specification language, in: P. Loucopoulos (Ed.), Proceed-

ings of CAiSE’92 International Conference, Vol. 593 of

LNCS, Springer, Berlin, 1992, pp. 348–363.

[16] S. Kripke, Naming and Necessity, Basil Blackwell, 2nd

Edition, 1980.

[17] I. Ramos, O. Pastor, J. Cuevas, J. Devesa, Objects as

observable processes, in: Proceedings of 3rd Workshop on

the Deductive Approach to Information System Design,

1992.

[18] R.J. Wieringa, Algebraic foundations for dynamic con-

ceptual models, Ph.D. Thesis, Vrije Universiteit, Amster-

dam, 1990.

[19] O. Pastor, I. Ramos, OASIS 2.1.1: A Class-Definition

Language to Model Information Systems Using an

Object-Oriented Approach, 3rd Edition, Servicio de

Publicaciones, Universidad Polit!ecnica de Valencia,

1995.

[20] R. Schulte, Three-tier computing architectures and be-

yond, Technical report, Gartner Group, 1995.

[21] G. Wiederhold, Mediators in the architecture of

future information systems, IEEE Comput. 25 (3) (1992)

38–49.

[22] K. Brown, B. Whitenack, Crossing Chasms, Pattern

Languages of Program Design, Vol. 2, Addison-Wesley,

Reading, MA, 1996.

[23] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design

Patterns: Elements of Reusable Object-Oriented Software,

Addison-Wesley, Reading, MA, 1994.

[24] U.W. Lipeck, G. Saake, Monitoring dynamic integrity

constraints based on temporal logic, Inform. Systems 12

(3) (1987) 255–269.

[25] V. Pelechano, O. Pastor, N. Garcia, S. Ramirez, Imple-

menting dynamic integrity constraint checking in object

oriented programming environments, in: O. Diaz, J.

Iturrioz (Eds.), Proceedings of the Second Software

Engineering Symposium (JIS-97), Basque Country Uni-

versity, 1997, pp. 101–116.

[26] O. Pastor, E. Insfr!an, G. Quiles, J. Barber!a, Object-

oriented conceptual modeling techniques to design and

implement a sound and robust ORACLE environment, in:

ORACLE (Ed.), Proceedings of European Oracle Users

Group Conference, 1997.

[27] R. L!opez, Automated prototyping in a Oracle 8i/developper

software environment using OO-Method, Master

Thesis, Technical report, DSIC, Valencia University of

Technology, 2000 (in spanish; extended abstract available

in English).

[28] R.J. Wieringa, A survey of structured and object-oriented

software specification methods and techniques, ACM

Comput. Surveys 30 (4) (1998) 459–527.

O. Pastor et al. / Information Systems 26 (2001) 507–534 533

[29] I-Logics Inc., The languages of statement, Technical

report, I-Logics Inc., 22 Third Avenue, Burlington, MA

01803 USA, 1991.

[30] D. Harel, A. Naamad, The STATEMATE semantics of

statecharts, ACM Trans. Software Eng. Meth. 5 (4) (1996)

293–333.

[31] R.J. Wieringa, R. Jungclaus, P. Hartel, G. Saake, T.

Hartmann, OMTROLL: object modeling in troll, in: U.W.

Lipeck, G. Koschorreck (Eds.), Proceedings of IS-CORE

93 Workshop, 1993, pp. 267–283.

[32] A. Grau, J.K. Filipe, M. Kowsari, S. Eckstein, R. Pinger,

H.D. Ehrich, The TROLL approach to conceptual

modelling: syntax, semantics and tools, in: T.W. Ling, S.

Ram, M.L. Lee (Eds.), Proceedings of 17th International

Conference on Conceptual Modeling (ER’98), Vol. 1507 of

LNCS, Springer, Berlin, 1998, pp. 277–290.

[33] H.D. Ehrich, C. Caleiro, A. Sernadas, G. Denker, Logics

for specifying concurrent information systems, in: J.

Chomicki, G. Saake (Eds.), Logics for Database and

Information Systems, Kluwer Academic, Dordrecht, 1998,

pp. 167–198.

[34] A. Grau, M. Kowsari, A validation system for object

oriented specifications of information systems, in: R.

Manthey, V. Wolfengagen (Eds.), Proceedings of AD-

BIS’97 Symposium, 1997, pp. 277–290.

[35] A. Sernadas, C. Sernadas, H.D. Ehrich, OO Specification

of databases: an algebraic approach, in: P.M. Stocker, W.

Kent (Eds.), Proceedings of VLDB’87 International

Conference, 1987, pp. 107–116.

[36] Oblog, The OBLOG software development approach,

Technical report, OBLOG Software, 1999.

[37] L.F. Andrade, J.C. Gouveia, P.J. Xardonne, Architectural

concerns in automating code generation, in: OOPSLA

Midyear Conference, 1998.

[38] R.J. Wieringa, Postmodern software design with NYAM:

not yet another method, Technical report, Faculty of

Mathematics and Computer Science, Vrije Universiteit,

Amsterdam, 1998.

[39] M. Jackson, System Development, Prentice-Hall, Engle-

wood Cliffs, NJ, 1983.

[40] S. Cook, J. Daniels, Designing Object Systems: Object-

Oriented Modelling with Syntropy, Prentice-Hall, Engle-

wood Cliffs, NJ, 1994.

[41] J. Rumbaugh, I. Jacobson, G. Booch, The Unified

Modeling Language Reference Guide, Addison-Wesley,

Reading, MA, 1998.

[42] Desmond D’Souza, Alan Wills, Objects, Components

and Frameworks With UML: The Catalysis Approach,

Addison-Wesley, Reading, MA, 1998.

O. Pastor et al. / Information Systems 26 (2001) 507–534534