The OO-method approach for information systems modeling: from object-oriented conceptual modeling to automated programming

Information Systems 26 (2001) 507–534

The OO-Method approach for information systems modeling: from object-oriented conceptual modeling to automated programming b ! Oscar Pastora,*, Jaime Gomez , Emilio Insfra! na, Vicente Pelechanoa a

! ! Universidad Politecnica ! Depto de Sistemas Informaticos y Computacion, de Valencia, Camino de Vera, s/n 46022 Valencia, Spain b ! Depto de Lenguajes y Sistemas Informaticos, 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 implementation in 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 both approaches. The OO-Method makes a clear distinction between the problem space (centered on what the system is) and the solution space (centered on how it is implemented as a software product). It provides a precise, conventional graphical 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 system specification. An abstract execution model determines how to obtain the software representations corresponding to 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 understood to be a true engineering activity, a comprehensive view of the set of phases involved must be introduced. This view should be global, in the sense that a clear relation between the different steps must be defined. We are concerned with how to improve the system development

process in order to solve the problems detailed below [1]: *

*

*

*Corresponding author. E-mail address: [email protected] (O. Pastor).

Moving out from the chaotic level associated with conventional methods, where contradictions, ambiguities, incompleteness and mixed levels of abstractions occur in a natural way. Improving understanding at the problem space level. Designing flexible methods and better computer-aided software engineering (CASE)/computer-aided requirements engineering (CARE)

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

508

*

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

support, with the objective of reaching the solution space with a final software product which is compliant with the problem space description. Providing guidance in order to be able to deal with the entire software production process in a structured way.

To overcome these shortcomings, we should move from traditional systems engineering to advanced requirements engineering, where the distinction between the problem space (what the problem is) and the solution space (how it is to be implemented in a particular software development environment) must be clearly established. The conversion of the conceptual modeling constructs (which are included in the resultant conceptual model) into the final software components should also be clearly determined. It is obvious that the problem space imposes strong requirements on the software production process. Taking into account that the Requirement Engineering process is complex, knowledge-intensive, experience-based, and requires highly intellectual and creative activity, it is essential to provide a clear way of capturing those requirements considered relevant in order to build a correct conceptual model. The first decision to make is to determine the model to be used for dealing with the conceptual modeling process. From our point of view, the object-oriented model is the best choice, due to its proximity to human cognitive mechanisms, due to the encapsulation of structural and behavioral aspects provided by the object notion and due to the fact that the transition from the problem space to the solution space is smooth. We can specify objects in the conceptual model and implement objects in the final software representation. The object-oriented model introduces modularization in the problem space, making reuse a good practice in the conceptual modeling process. If we look at the current approaches that deal with object-oriented conceptual modeling, we can distinguish two main categories: *

Those conventional methods such as WirfsBrock [2], Rumbaugh [3], Jacobson [4], Booch

[5], Coleman [6], inheriting what we could call traditional CASE problems:1 * an excessive number of models that have overlapping semantics, * difficult and lossy transformations between models, languages and tools, * variable quality in system implementation under similar quality designs, * lack of comprehensiveness due to needless complexity. Methods that are created using a formal framework such as Kush [8], Clyde [9], Jackson [10], Liddle [11], Liu [12] to define concepts in a precise way, and where for every behavioral pattern captured in the conceptual modeling step (problem space), there is a corresponding construct in the software representation used at the solution space.

*

We argue that future developments in Software Engineering lie within this second approach, and the last few years we have been working in this direction. Our contribution to this state of the art is the OO-Method approach [13,14], which is basically built on a formal object-oriented model (OASIS [15]). Its main feature is that developers efforts are focused on the conceptual modeling step, where system requirements are captured in accordance with a predefined, finite set of conceptual modeling constructs that are the representation of relevant concepts at the problem space level. The final implementation is obtained in an automated way by programming the corresponding mappings between those conceptual model constructs and their representation in a particular software development environment. This architecture provides the pattern for obtaining software components which can be dynamically combined to build a software prototype that is functionally equivalent to the specification collected in the conceptual model step. The 1

In 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–534

current software development environments where code is generated include Visual C++, Delphi, Visual Basic and Java. However, it is important to note that the approach is conceptually independent of any target development environment. Concrete implementations of the execution model are obtained by programming the corresponding mappings between conceptual modeling constructs and their corresponding software representations in the selected software development environment. This document is organized as follows: Section 2 presents a short description of the main OOMethod features describing the diagrams that are used to capture the system properties in order to produce what we call a conceptual model. This section also introduces the underlying OO OASIS formal specification that is obtained when the conceptual model step is finished, as well as showing how to represent this OASIS formal specification in any target software development environment, according to an abstract execution model. Section 3 describes the component-based architecture in order to produce the software components that allow us to link the conceptual model with the abstract execution model in an automated way. The programming language used in the examples of this section is Java. Section 4 describes related work, and Section 5 presents conclusions and suggestions for future work.

2. The OO-Method The OO-Method was created on the formal basis of OASIS, an object-oriented formal specification language for Information Systems. Basically, we can distinguish two modeling components in the OO-Method: the conceptual model and the execution model. 2.1. Conceptual model Two main aspects must be clearly stated when introducing a conceptual modeling approach: (1) which conceptual modeling constructs are provided by the method,

509

(2) which notation is provided to properly capture those conceptual modeling constructs. Before introducing the specific set of modeling constructs and notations, it should be pointed out that in the OO-Method proposal, the combination of formal specification techniques with conventional, widely-used OO modeling techniques has been a basic feature since the very beginning. Another important objective was to avoid the complexity which is traditionally associated with the use of formal methods, by making designers view the method as being compliant to industrial standards. This is why we adopted the well-known OO strategy of dividing the conceptual modeling process into the three complementary views, that of the object view, the dynamic view and the functional model view. However, there is a big difference: in the OO-Method, when the designer is specifying the system, what he is really doing is capturing a formal specification of the system ‘‘on the fly’’, according to the OASIS formal specification language. This feature allows us to introduce a well-defined expressiveness in the specification, which is often lacking in the conventional methodologies. The use of such a formal specification provides the context to validate and verify the system in the solution space, obtaining a software product that is functionally equivalent to the specification as we will show later on in this paper. Naturally, we have had to introduce relevant information to address specific features of OASIS in these diagrams (object model, dynamic model and functional model). Nevertheless, this is always done preserving this external view which is compliant with the most extended modeling techniques (as stated above). Only the information which is relevant for filling a class definition in OASIS must be introduced. In this way, the arid formalism is hidden from the modeler when he is describing the system by making him feel comfortable using another (more!) conventional modeling notation. With respect to the notation, conceptual modeling in the OO-Method uses UML-compliant diagrams. According to the previous arguments, a main interest in the design of the OO-Method

510

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

was to keep modelers from having to learn another graphical notation in order to model an information system. Having a formal basis allows us to provide a modeling environment where the set of needed diagrams is clearly established. Let us introduce the corresponding OO-Method set of modeling constructs and diagrams. The OOMethod collects the system requirements using three complementary models. 2.1.1. Object model The object model (OM) is a graphical model where system classes including attributes, services and class relationships (aggregation and inheritance) are defined. Additionally, agent relationships are specified to state the services that objects of a class are allowed to activate. The corresponding UML base diagram is the class diagram, where the additional expressiveness could be introduced by using the needed stereotypes which is a useful UML facility. Fig. 1 shows an example of an OM instance (a conventional library system with readers, books

and loans). It can be seen that classes and their relationships are basically depicted using the wellknown UML class diagram notation. For instance, the arrow between reader and unreliable reader denotes that unreliable reader is a specialization of reader. And the loan composite class represents an aggregation between the component classes book and reader. Agent relationships are represented by using an agent stereotype connecting the associated client class and server class services. In the example, the objects of the reader class can activate the services loan() and return() of the book class. The specific server class services that can be activated by a given client class must be introduced as additional agent stereotype information. Shared services (those that are included in the specification of more than one class, representing a synchronous communication mechanism between the objects involved in their occurrence) are represented by using a shared stereotype connecting the associated services with the corresponding classes. In the example, the services loan() and

Fig. 1. Object model for the library system.

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

return() are shared between the classes book and reader. We must specify additional information in the OM to complete the formal description of the reader class. Specifically, for each class the OM captures: attributes: to indicate if the attribute is constant, variable or derived, services: name of the services with their corresponding arguments, distinguishing the new and destroy class services, derivations: derivation expressions for the derived attributes (those whose value is dependent on other attributes), constraints: well-formed formulas stating conditions that objects of a class must satisfy, relationships: specific information associated to aggregation and inheritance hierarchies. More precisely, * for aggregated classes, to specify if we have an association or a composition (following the UML characterization),2 and if the aggregation is static or dynamic. * for inheritance hierarchies, to specify if a specialization is permanent or temporal. In the former case, the corresponding condition on constant attributes must characterize the specialization relationship; in the latter, a condition on variable attributes or the carrier service that activates the child role must be specified.

*

*

*

*

*

2.1.2. Dynamic model The system class architecture has been specified using the OM. Additionally, basic features, such as which object life cycles can be considered valid, and which interobject communications can be established, have to be introduced in the system specification. To do this, the OO-Method proposes a 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 for every class. By valid life, we mean an appropriate sequence of states that characterizes the correct behavior of the objects that belong to a specific class. Fig. 2 shows a simple STD for the reader class. The corresponding UML base diagram is the state diagram. Every service occurrence (i.e. new reader()) is labeled by the agent (LIB)rarian that is allowed to activate it. In this example, the * denotes that any valid agent class can activate the transition. As the only valid agents for newreader() are objects of class LIBRARIAN, both representations are equivalent. Transitions represent valid changes of state that can be constrained by introducing conditions. They follow the syntax shown in Fig. 3. Preconditions are those conditions defined on the object attributes that must hold for a service to occur. Control conditions are conditions defined on object attributes to avoid the possible nondeterminism for a given service activation. In the example, once a reader is in the state labeled reader0, if a loan service is activated, the object will move to the reader1 state. Here, if a return service occurs, the selected transition will be the one satisfying the corresponding condition control (book number ¼ 1 or book number > 1). Interaction diagram. The interaction diagram (ID) specifies the interobject communication. We define two basic interactions: triggers, which are

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

2

In this way, the concept of aggregation in OO-Method includes the concepts of association and composition provided by UML as special cases.

511

Fig. 3. Syntax for transitions in the STD.

512

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

object services that are activated in an automated way when a condition is satisfied, and global interactions, which are transactions involving services of different objects. There is a STD diagram for every class, but only one ID for the whole system, where the previous interactions will be graphically specified. Fig. 4 shows a simple interaction diagram for our example. In this case, the UML base diagram used to capture this expressiveness is the collaboration diagram. In the example, we have one trigger indicating that a triggered action (reader.punish()) must be activated when the book number attribute of a reader is equal to 10. Trigger specifications follow the syntax shown in Fig. 5. The first component is the destination (the object(s) to which the triggered event is addressed). This trigger destination can be the same object where the condition is satisfied (self), or a specific object (specifying the oid involved) or the entire class population if we are broadcasting the event (class). Finally, the triggered service and its corresponding triggering relationship are declared. Global interactions are graphically specified by connecting the services involved in the declared interaction. These services are represented as solid lines linking the objects (boxes) that provide them. 2.1.3. Functional model A correct functional specification is a shortcut for many of the most extended OO Methods.

Sometimes, the model used breaks the homogeneity of the OO models, as happened with the initial versions of OMT, which proposed using the structured DFDs as a functional model. The use of DFD techniques in an object modeling context has been criticized for being imprecise, mainly because it offers a perspective of the system (the functional perspective), which differs from the other models (the object perspective). Other methods leave the free-specification of the system operations in the hands of the designer. The OOMethod functional model (FM) is quite different with respect to these conventional approaches. In this model, the semantics associated to any change of an object state is captured as a consequence of a service occurrence. To do this, it is declaratively specified how every service changes the object state depending on the arguments of the service involved, and the object’s current state. A clear and simple strategy is given for dealing with the introduction of the necessary information. The relevant contribution of this functional model is the concept of the categorization of attributes. Three types are defined: push-pop, state-independent and discrete-domain based. Each type will fix the pattern of information required to define its functionality. In short Push-pop attributes are those whose relevant services increase, decrease or reset their value, State-independent attributes are those having a value that depends only on the latest service that has occurred, and Discrete-domain valued attributes are those that take their values from a limited domain. The object reaches a specific state, where the attribute value can be specified, through the activation of carrier or liberator services. To illustrate, Fig. 6 shows the functional model for the attribute book number of the reader class.

Fig. 4. Interaction diagram showing a triggered action.

Fig. 5. Syntax for trigger specification.

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

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

513

This attribute is categorized as a push-pop because its relevant services increase or decrease their value by a given quantity. In the example, reader:loan() has the increasing action and reader:return() has the decreasing action (reader is a variable indicating which event agents are the valid ones). This categorization of the attributes is a contribution of the OO-Method that allows us to generate a complete OASIS specification in an automated way, where a service functionality is completely captured. More detailed information can be found in [13]. 2.2. The OASIS formal specification Taking the three previous models as a starting point, a corresponding formal and object-oriented OASIS specification is obtained in an automatic way. The resultant specification acts as a high-level system repository. This is a main feature in the OO-Method approach: each piece of information introduced in the conceptual modeling step has a corresponding formal counterpart, which is represented as an OASIS concept. We could view the graphical modeling environment associated to the OO-Method as an advanced graphical editor for OASIS specifications. Therefore, an introductory presentation of the OASIS specification language is needed in order to have a complete view of the presented approach. Fig. 7 shows the OASIS specification for the reader class which is automatically obtained from the conceptual model. The mapping from conceptual modeling constructs to OASIS concepts will be introduced in the Subsection 2.3. Before this, let us take a look at the reader class specification to explain the meaning of the different sections that integrate its formal description. 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 all the instances share. The identification function (by reader code), characterizes the naming mechanism used by objects. It gives a set of surrogates belonging to a predefined sort or to a sort defined by the user

Fig. 7. OASIS specification for the reader class.

(the so-called domains in OASIS). They are imported in the class definition. The most usual are predefined as int, nat, real, bool, char, string and date. They represent numbers, Boolean values, characters, strings and dates in a particular format. New domains can be introduced in a specification by defining the corresponding abstract data type. A type is the template that collects all the properties (structure and behavior) which are shared by all the potential objects of the class

514

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

being considered. Syntactically, it can be formalized as *

*

*

a signature, which contains sorts, functions, attributes (constant, variable and derived, see constant attributes and variable attributes sections in Fig. 7) and events to be used private events and shared events as can be seen in Fig. 7, a set of axioms, which are formulas in a dynamic logic, a process query as a set of equations with variables of a sort process that are solved in a given process algebra. When these variables are instantiated, we have the ground terms that represent possible lives of instances (objects).

they constitute the core of the information used as input to undertake the automated software production process. In OASIS, we have the following kinds of dynamic formulas (set of class axioms) *

Valuations are formulas of the form F½aF0 whose semantics is given by defining a r function that, from a ground service a returns a function between possible worlds rðaÞAW-W:

In other words, as any valid state is a possible world for an object, the r function determines which transitions between object states are valid after the execution of a service a: In the example of Fig. 7, we have the following valuations: ½loanðÞ book number ¼ book number þ 1;

The semantics of OASIS is defined by means of Kripke [16] structures ðW; t; rÞ which include an universe of states w: We associate an accessibility relation r to each class in such a way that a pair of states ðs; tÞ is in that relation if and only if there is a transition going from the state s to the state t: Let us call W the set of all possible worlds reachable by an object. Let us call F the set of state well formed formulae (wff) being evaluated over the current state of the object. Let A be the set of ground actions of the object template and 2A% the set of all possible instantiated steps. In the formal OASIS framework a step is a set of consistent services that occur in a given instant of an object life. The functions t and r are defined as follows:

ð2Þ

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

*

*

W

t : F-2 ; r : 2A% -ðW-WÞ: The function t indicates in which worlds a state formula (in first order predicate logic) is true. The function r is a binary relation between worlds (declarative semantics of the language). Given a step mA2A% ; w; w0 AW then ðw; w0 ÞArðmÞ if and only if the occurrence of m implies the transition between the worlds w and w0 : After introducing the OASIS syntax and semantics, we are going to briefly introduce the quoted set of axioms and the process query that formalize a OASIS type. This is specially relevant because

ð1Þ

It is important to realize that, within this dynamic logic environment, the formula F is evaluated in sAW; and F0 is evaluated in rðaÞ; with rðaÞ being the world represented by the object state after the execution in s of the service considered. Derivations are formulas of the type F-F0 : They allow us to define derived attributes ðF0 Þ in terms of the given derivation expression (stated in F). They basically differ from the valuation formulae in the fact that this derived valuation is done in a unique state. In our example there are no derivations. Integrity constraints are formulas that must be satisfied in every world. We distinguish between static and dynamic. Static integrity constraints are those defined for every possible world. They must always hold. In the example: static book numbero10:

*

ð4Þ

On the other hand, dynamic integrity constraints are those that relate different worlds. They require the use of a temporal logic, with the corresponding temporal logic operators. Preconditions are formulas with the template :F½a false; where F is a formula that must hold in the world previous to the execution of service a: Only in the worlds where F holds, is a

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

allowed to occur. If :F holds, the occurrence of a gives no state as successor. We have the following precondition in the reader specification: :ðbook number ¼ 0Þ ½librarian : destroy readerðÞ false; ð5Þ or, in a more convenient way for specification purposes, 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 holds and a service other than a occurs, then there is no successor state. This forces a to occur or the system remains in a blocked state. For instance, using the appropriate dynamic formula (where we include information about the destination in the triggered service, according to the trigger expressiveness presented when the OO-Method ID was introduced), we will declare: book number ¼ 10 ½:ðSelf :: punishðÞÞ false: ð7Þ Once more, we will write in an equivalent but more conventional way for specification purposes: Self :: punishðÞ if book number ¼ 10:

ð8Þ

Thus, triggers are services which are activated when the condition stated in F holds. The main difference between preconditions and triggers comes from the fact that in triggers there is an obligation to activate a service as soon as the given condition is satisfied. In this way triggers, allow us to introduce internal activity in the object society that is being modeled. In any of these dynamic formulas, F; F0 are well-formed formulas in a first order logic that refer to a given system state characterized by the set of values attached to attributes of objects in the state or world considered. 3 It means that a does not occur, and what does occur is not specified.

515

In OASIS, an object is defined as an observable process [17]. The process specification in a class allows us to specify object dynamics and determines the access relationship between the states of instances. Processes are constructed by using events as atomic services. However, the designer also has the choice of grouping events in execution units, which are called transactions. The molecular units that are the transactions have two main properties: (1) they follow an all-or-nothing policy with respect to the execution of the involved events: when a failure happens during a transaction execution, the resultant state will be the initial one, (2) the non-observability of intermediate states. We will finish this section introducing the process 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 terms in a well-defined algebra of processes, which is based on the approach presented in [18]. It allows us to declare possible object lives as terms whose elements are transactions and events. Every process can be rewritten to a term in a basic process algebra BPAde ; with the K (sequence) and þ (alternative) process operations. This provides an implementation of concurrence based on arbitrary interleaving. This is a short introduction of the current formal features of OASIS. The reader can find a more detailed description of previous OASIS versions in [15,19].

516

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

2.3. The formal specification as the system repository After having presented the OO-Method conceptual constructs and the OASIS formal concepts associated to them, we are going to introduce the mappings that generate a textual system representation (that is a specification in OASIS) taking as input the graphical information introduced in any OO-Method conceptual model. This formal specification has in fact been obtained using conventional techniques, and constitutes a solid system documentation to obtain a final software product which is compliant with the initial requirements, as represented in the source conceptual model. According to the class template introduced in the previous section, let us identify the set of OOMethod conceptual constructs and their corresponding OASIS representation. The system classes are obtained from the object model. 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 (those defined by using the provided aggregation and inheritance class operators), the object model also provides the particular characteristics specified for the corresponding complex aggregated or specialized class. With the information given by the object model, we basically have the system class structure, where the signatures of the classes are precisely declared. As we have seen above, the dynamic model uses two kind of diagrams: STD and ID. From the STD, we obtain: *

*

* *

trigger relationships, global transactions (those involving services of different class objects).

Finally, the functional model gives the dynamic formulas related with evaluations, where the effect of services on attributes is specified. Having clearly defined the set of relevant information that can be introduced in an OOMethod conceptual model, the formal specification corresponding to it provides a precise system repository where the system description is completely captured, according to the OASIS objectoriented model. This allows us to undertake the implementation process (execution model) from a well-defined starting point, where the pieces of information involved are meaningful because they come from a finite catalog of conceptual modeling constructs, which, furthermore, have a formal counterpart in OASIS. 2.4. Execution model The OASIS specification is the source for an execution model that must accurately state the implementation-dependent features associated to the selected object society machine representation. In order to easily implement and animate the specified system, we predefine a way in which users interact with system objects. The template presented in Fig. 8 is used to achieve this behavior. The process starts by logging the user into the system (step 1) and providing an object system view (step 2) determining the set of object attributes and services that it can see or activate. After the user is connected and has a clear object

service preconditions (those formulas labeling the service transitions), the process definition of a class, where the template for valid object lives is fixed.

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

Fig. 8. The execution model template process.

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

517

system view, he can then activate any available service in his worldview. Among these services, there will be observations (object queries) or local services or transactions served by other objects. Any service activation (step 3) has two steps: build the message and execute it (if possible). In order to build the message, the user has to provide information to identify the object server4 (step 3.1). Subsequently, he must introduce service arguments (step 3.2) of the service being activated (if necessary). Once the message is sent (step 3.3), the service execution is characterized by the occurrence of the following sequence of actions in the server object: check state transition (step 3.4) which is the process of verifying that a valid transition exists in the OASIS specification for the selected service in the current object state, the precondition satisfaction (step 3.5) indicates that the precondition associated to the service must hold.

*

*

If any of these actions do not hold, an exception will arise and the message is ignored. Otherwise, the process continues with: the valuation fulfillment (step 3.6) where the induced service modifications take place in the involved object state, the verification of integrity constraints in the final state (step 3.7), to assure that the service execution leads the object to a valid state. If the constraint does not hold, an exception will arise and the previous change of state is ignored, the verification of the set of condition-action rules that represents the internal system activity after a valid change of state (step 3.8). If any of them hold, the specified service will be triggered.

*

*

*

The previous steps guide the implementation of any program to assure the functional equivalence between the object system specification collected in the conceptual model and its reification in an imperative programming environment.

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

Now we are going to describe how to link the formal specification captured in the conceptual modeling step with the abstract execution model presented above.

3. A tiered component architecture for the execution model The architecture for the execution model is based on the common three-tiered architecture [20]. We propose a multi-tiered architecture that includes the separation of responsibilities implied by the classic three-tiered architecture.5 These responsibilities are assigned to software objects. This architecture, which is organized in terms of software classes, is shown in Fig. 9. In this figure there are three basic layers. The user interface is composed of components that handle the presentation of information between the user and the application. The application logic is itself composed of the following layers: *

application logicFproblem domain objects: objects representing domain concepts that fulfill

4

The existence of the object server is an implicit condition for executing any service, unless we are dealing with the service new.

5 As we will see later on in this paper, the application logic is broken down into finer layers.

518

*

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

application requirements according to the OASIS specification, application logicFservices objects: non-problem domain objects that provide support services, such as interfacing with a database (commonly called mediators [21] and/or database brokers [22]). Specifically, we have proposed two mediators: * a mediator for database interaction called database mediator. It transforms object operations to the corresponding database calls and vice versa, * a mediator for system repository interaction called repository mediator. It provides access to the metainformation stored in the repository of the specification.

The persistence layer represents the selected persistent object system. We work with relational data 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 the structure of these tiers, showing the components, their interfaces, and the dependencies between them. 3.1. User interface The user interface is composed of three main visual components: the access control, the system view and the service activation components. The access control component (see Fig. 10) constitutes the software representation of the first step of the execution model (identify the user). It provides the interface IAccess which allows users to identify themselves in the system as was explained in Section 2.4. Specifically, this interface

Fig. 10. Interface specification of the access control component.

offers the service validateAccess that gets the Object Identifier and Class Name properties to properly identify an object as a member of the system that is being prototyped. In our library example, the implementation of this component will produce the interface shown in Fig. 11: The system view component constitutes the software representation of the second step of the execution model (obtain the object system view). It is important to note that the agent relations specified in the OM give us the needed information to generate this component in an automated way. This is done by defining the interface ISystem that provides the services needed to obtain an object system view. In other words, these services provide the functionality to obtain the classes that the user is allowed to interact with (getList of Classes service in Fig. 12), and they provide the functionality to obtain the services that the user can activate for each class (getList of Services service in Fig. 12). The visual representation of the component is a typical frame with a menu bar for classes and menu items for services. The implementation of this component in the library example produces the interface shown in Fig. 13. Finally, the service activation component constitutes the software representation of steps 3.1 (identify the object server) and 3.2 (introduce service arguments). The service declaration

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

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

519

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

3.2. Application logic This section provides two important contributions: *

*

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

included in the OM for every class provides the information that permits the generation of the component in an automated way. More precisely, this component provides the interface IServices which offers the service needed to obtain the arguments for a service activation (getList of Arguments service in Fig. 14). The specific implementation of this component for our example is shown in Fig. 15. Besides creating edit controls for introducing the corresponding service arguments, the process of generating the component includes the creation of three control buttons with the intention of executing the service (the OK button), cancelling it (the CANCEL button) or providing some help information (the HELP button). The user interface presented above is used for proper interaction between the user and the application. Having presented the user framework, the next step is the application logic layer.

a specific strategy to translate the formal specification of the system into an objectoriented software implementation, a set of services to address the persistence of the domain objects.

3.2.1. Application logicFproblem domain objects A concrete class is generated for each domain class specified in the conceptual modeling step. Its responsibilities are to encapsulate the application logic according to the underlying OASIS specification. This step includes a specific strategy to translate the formal specification that represents a domain class into an object-oriented software implementation. The translation process has two parts. The first one deals with how the domain classes can implement the algorithm to activate a service according to the execution model philosophy. The second one deals with how to map the OASIS specification to the code of the resultant specific classes. 3.2.1.1. Implementing the algorithm to activate services. The design of the domain classes to implement the algorithm used to activate a service is based upon the Template method pattern [23] (see Fig. 16). In this figure, the most important public method in the OASIS abstract class is activateService, a template method which takes the name of the service, the object identifier and the arguments of the service as parameters and returns a Boolean value that indicates whether the

520

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

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

*

*

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

service has been successfully activated. When a message is sent to an object server, a corresponding activateService must be executed. This activateService call constitutes the implementation of step 3.3 of the execution model. The activateService template method implements the rest of the OO-Method execution model through the activation of the following methods: *

*

*

*

*

loading the involved object in memory from its storage media (method mediator.materialize), checking that a valid transition exists for the service in the current object state. This is done by the method checkStateTransition (step 3.4 of the execution model), checking the corresponding service precondition through the method checkPreconditions (step 3.5 of execution model), execution of the corresponding service modifications, which is done by the method valuations (step 3.6 of the execution model), checking the integrity constraints in the final state. This task is performed by the method

checkIntegrityConstraints (step 3.7 of the execution 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 (method mediator.dematerialize).

The activateService template method defines varying parts of the algorithm. Specifically, the particulars of how the activation of a service can vary depending on the service that is being activated. These responsibilities are left as primitive operations that the subclasses must define. We will have such a subclass for every domain class. The structure of these subclasses can be seen in Fig. 17. For instance, checkPreconditions is a primitive operation for the template method activateService. Consequently, each domain class has to define how to implement the corresponding body of this primitive operation.6 In this case, the body of this operation must be implemented according to the preconditions associated to the domain class in the OASIS specification for that particular service. The concrete implementation of this checkPreconditions method will be shown later on. Having presented the design pattern that implements the algorithm to activate a service, the next step is to describe the design of the domain classes in order to implement every section of the OASIS specification (i.e. how the primitive operations proposed in the algorithm presented above are implemented). 6 Obviously, we will declare a primitive operation for every checking process in the execution model.

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

521

Fig. 16. The OASIS abstract class.

Fig. 17. The domain classes.

3.2.1.2. Mapping an OASIS specification to an OO implementation. We are going to present the general mapping algorithms, and then we will apply them to the library example using Java as the programming language.

Mapping preconditions. A checkPreconditions method has to verify if given a service e; its precondition holds. The generation process defines a protected method checkPreconditions with ServiceName as an argument. The body of this

522

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

method must be generated according to the following steps: (1) For each class service e having a precondition pð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 of service e has been violated. Coming back to our library example, let us take another look at the section of the OASIS specification that represents the preconditions associated to the class reader. Fig. 18 shows three different views for the preconditions. The OOMethod and OASIS views are views in the problem space. The OO programming language view is the view in the solution space. In this way, Fig. 18 illustrates how a precondition 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 labels a transition in the STD according to the syntax that was presented in Fig. 3. From the viewpoint of the OASIS formal specification language, a precondition is the wff representing the corresponding dynamic formula in a textual manner. From the viewpoint of object-oriented programming, a precondition is a conditional sentence that must be tested. In conclusion, preconditions are mapped to an object-oriented programming language using a conditional test. If the condition does not hold then an exception will arise. The error message can be customized to any particular service, declaring it when specifying a precondition in the conceptual modeling step. This is why in Fig. 18 the customized error message ‘‘Precondition violation. The reader has books’’ appears: it has been specified for the 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–534

verification of a valid state transition: conditional logic, the state pattern [23], or a state machine interpreter that runs against a set of state transition rules. It has been recognized that the applicability of the state pattern may not be suitable if there are many states in the system [23]. The implementation of a state machine interpreter is beyond the scope of our proposal. Consequently, we have chosen the use of conditional logic. An STD belonging to a given class C could be seen as a directed graph G ¼ ðS; TÞ such that: *

*

S is a set of possible object states that are represented by graph nodes, and T is a set of state transitions represented by labelled 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 transition t:

In order to generate the checkStateTransition method that verifies if a valid transition exists for any service in the current object state, we define a protected method checkStateTransition with ServiceName as an argument. The body of this method must be generated according to the following steps:

(1) For each state si=i¼0::n A S we have to generate: (a) A conditional structure that checks if the current 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 current object state, we have to generate a conditional sentence that checks if ServiceName is equal to e and the control condition cc of e holds. (i) Define an assignment sentence that assigns the sj value to the current object state if the conditional sentence defined in step (b) holds.

523

(ii) An exception sentence must be generated to determine whether a valid transition exists in the STD, meaning by valid that the conditions defined in step (b) hold. The generated error message is ‘‘state transition violation’’. It is important to note that in the structure of the class that implements this method we must define an additional attribute (which is not present in the signature of the class) to store the current object state in the STD. This attribute will have its counterpart in the data layer in order to make the object state in the STD persistent. Fig. 19 shows how state diagrams are mapped in the solution space using conditional logic. For each concrete state specified in the STD (in the example of the reader class, these states are nonexistence, reader0, reader1 and post-mortem), we must declare a conditional structure. This structure must ensure that a valid transition exists for the service that is being activated. If this process succeeds, the corresponding change of state is carried out. Otherwise, an exception will arise. For example, let us suppose that the current state of a reader object is reader0 and that the service that is being activated is the service loan(). The checkStateTransition method determines that this is a valid transition and sets the new state of the reader object to reader1. Mapping valuations. The valuations are mapped in the solution space as a method of the domain class called valuations. This method implements the change of the object attribute values according to their categorization in the FM. Valuations in the FM are defined by using formulas of the form F½aF0 where F and F0 are wff whose semantics is the following: if service a is activated and the object is in the state F; the effect of a service execution will leave the object in the state F0 : The formula F must be true in the object state previous to the occurrence of service a: The formula F0 specifies the effect that the service executed has over object attribute values. The generation process defines a protected method valuations with ServiceName and Parameters(that are the arguments of ServiceName)

524

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

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

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

as arguments. The body of this method must be generated 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. This structure will check if ServiceName is equal to e: (b) A call to a method that must have the same name as the service declared in the system specification. This method has to be a protected method that implements

525

the for has (i)

semantics of the valuation formulas service e: The body of this method to be built generating the following: 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 the way that the formula F0 specifies.

An example is introduced in Fig. 20. Conditional logic is used to determine which service must be activated. The execution of the corresponding

Fig. 20. Mapping valuations for the reader class.

526

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

service (loan or return) is carried out according to the effect specified in the FM. Let us suppose that the service loan() has been activated for a reader object. The effect of this service activation in the attribute book number will be an increment in its value. Mapping integrity constraints. A checkIntegrityConstraints method has to verify if the valuations execution leads the object to a valid state. The generation process defines a protected method checkIntegrityConstraints with no arguments. The body of this method must be generated according to the following steps: (1) For each integrity constraint formula F; we have 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 constraint has been violated. In the example, the method checkIntegrityConstraints (see Fig. 21) will check whether the

conditional expression book numbero10 is satisfied. Dynamic constraints are more complex to implement. They must be evaluated throughout the entire life of an object. For implementation purposes, this complex mapping is based on the work presented in [24], that provides a mechanism to support the implementation of dynamic constraints in imperative environments which lack the power of temporal logic. The particular implementation of the previous algorithm adapted for the OO-Method dynamic integrity constraints can be seen in detail in [25]. Mapping triggers. The effect of a triggering action has traditionally been a singular research topic in the database community, specially in the context of active DBMS. A common proposal of a knowledge model for active systems has been the event-condition-action (ECA) rules mechanism. These rules are composed of an event that triggers the rule, a condition that describes a specific situation, and an action to be performed if the condition is satisfied. In this context, various

Fig. 21. Mapping constraints for the reader class.

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

proposals have been presented to include this rule mechanism in active systems. For our purposes, we only consider a subset of ECA rules. We define an OASIS trigger as an active rule where; the event is the current service that is being activated, the condition is the wff that must be evaluated, and the action is the OASIS action that must be activated if the condition is satisfied. We also consider that the effect of the trigger acts in the context of the object society that is being specified. Taking into account these limitations, we propose a simple strategy of implementation. A checkTriggers method has to check whether the condition associated to the trigger holds, in this case the corresponding service is activated. The generation process defines a protected method checkTriggers with no arguments. The body of this method must be generated according to the following steps: (1) For each trigger formula F½:a false; we have to 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 to throw an exception if the service a is not available (because the object server does not exist, the precondition and the state transition do not hold or the integrity constraints are not verified). We can see in Fig. 22 the code generated to implement the checking of the trigger specified in class Reader. In this case, if the condition book number¼10 holds, the corresponding service (activateService(’’Punish’’)) is activated. This is how the code of the domain classes is generated starting from the formal OASIS specification following a specific strategy. It is important to note that the use of this strategy to generate code is not attached to any particular programming language. This is possible because the final implementation is obtained in an automated way by programming the corresponding mappings between conceptual model constructs and their

527

Fig. 22. Mapping triggers for the reader class.

representation in a particular software development environment (Java in this paper). Having obtained the full object-oriented implementation, the next step is how to provide persistent facilities to the domain classes. The application logicFservices objects layer is responsible for this task. 3.2.2. Application logicFservices objects This layer encompasses non-problem domain objects to ensure the persistence of the domain classes. Independently of the DBMS selected for the persistence layer (relational, object-relational or object-oriented), software components intended to interact with the database engine must be provided. The components that provide services of this kind are normally called mediators. They act as the middleware that provides the needed interface for accessing data, manipulates them as temporary objects, and make them finally persistent after a service execution has been completed. For instance, if we work in a relational DB environment (see Fig. 23), an object/relational mediator converts database table rows in instances of objects where the services that we have introduced in the previous sections are applied. For our purposes, we have designed two mediators. The first one, called database mediator, ensures that the domain classes have persistent facilities. This component provides the

528

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

Fig. 23. Object/Relational mediator.

services needed to materialize and dematerialize objects. The second one, called repository mediator ensures that the components of the user interface can be properly customized. To do this, the repository mediator component provides services to make queries to the system repository. These queries allow for the customization in runtime of the User Interface framework according to the specification stored in the system repository. In this way, the user interface can be completely reused as a standard component UI framework for all prototype sessions. 3.3. Data model At this level we have the data and the system repository. The former represents the data model of the system that is being prototyped. The latter contains the metainformation of the specification. It constitutes the data dictionary of the system. It is important to note that both databases are generated in an automated way once the conceptual modeling step has been completed. How to do this in a Relational Data Base environment is a well-known process of translation, which can be done in an automated way as shown in [3,26]. Extensions to Object-Relational DB can also be accomplished following a similar strategy, making use of the extended object-oriented DB features ([27] shows how to implement an OASIS specification in an Oracle 8i DB).

4. Related work From a global viewpoint, two approaches can be distinguished when looking at the OO software specification methods to model an information system:

the conventional OO methods, the OO formal specification languages.

In both cases, the techniques used for representing properties of software involve some kind of natural language, formal languages and diagram techniques. Conventional, non-formal methods have been proposed for the specification of software systems over the past twenty years. First following the structured approach, later following the OO approach. Normally, they provide a set of easy-to-use diagram techniques with overlapping or ambiguous semantics and no formal support to use them. In general, one cannot tell by looking at a diagram what it represents (see [28] to find wellfounded arguments on this topic). The meaning of a diagram is given by a set of interpretation rules, which must be defined elsewhere. If these interpretation rules are not based on a precise formalism, the diagram becomes meaningless. By this we mean that without such a precise definition, the notation may be used to give a rough sketch of vague ideas but not to communicate a meaning unambiguously to others. In contrast, the use of formal specification languages provides a solid mathematical background and deducible formal properties such as soundness and completeness. However, their use tends to be too complex and unfriendly: their application requires significant abstraction and mathematical skills, and what happens in practice is that existing tools do not satisfactorily support the entire formal software development process. In accordance with these arguments, a research issue that comes up is that current and future notations should provide a precise semantics to take advantage of the positive features of both the conventional and the formal approaches. In recent years, there has been increasing attention given to how these approaches can be combined. We find attempts to achieve integration even within structured analysis proposals. For instance, Statemate is a software kit and a notation for structured analysis that, in the interest of executability of specifications, defines actions performed by statecharts imperatively. The execution semantics of Statemate is formally defined [29,30]. The main problem is that Statemate does not contain a

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

notation corresponding to a data model. There is only a partial system view based on processes. Also, the way in which activity charts and statecharts are put together into a coherent model must be clearly established to avoid inconsistencies. Various proposals within the OO paradigm, have appeared in the literature with the objective of recognizing opportunities in order to advance the state of the art beyond the conventional-formal dichotomy by picking the best ideas from both approaches. These global proposals can be classified depending on the philosophy of how to integrate the formal models in those well-known conventional methods. Most approaches consider the integration process in terms of how to capture the information needed to build the formal specification of the system from the conceptual model level. The objective of the OMTROLL approach [31] is to assist designers with an OMT-compliant graphical notation to build the formal specification of the system. This specification is based on the TROLL specification language [32]. The textual specification has to be refined to a complete system specification. The formal nature of TROLL (which uses a distributed temporal logic called DTL [33]) helps to achieve concise and unambiguous systems specifications as well as to develop better CASE tools. In particular, OMTROLL has a CASE support called TrollWorkbench [8,34]. TBench provides a prototyping process that allows for generating an independently executable prototype from a graphical conceptual specification. The prototype generated is a Cþþ program that includes the static/dynamic aspects of the system and uses an Ingres database as a repository of the specification. This approach shares the underlying OO formal specification language (OASIS for OO-Method, Troll for OMTROLL) with the OO-Method. The main difference is that the Troll-WorkBench focuses on the validation of specifications and on the development of a tool for model checking, while the OO-Method provides an implementation of an abstract execution model to obtain a software product which is ready for execution. Another difference arises which is related to modularization concepts: OMTROLL

529

works only with object classes. The OO-Method provides the notion of cluster to group classes in order to deal with system complexity. OBLOG [35] is another object-oriented approach for software development that represents the convergence of many efforts within the scope of the European ESPRIT project information systems-correctness and reusability (IS-CORE). The OBLOG semantics is formalized in the context of the theory of categories. A CASE tool [36,37] for OBLOG specifications has been introduced, sharing the objective of going from system specification to code generation using a formal specification language as its basis (OBLOG in this case). As in the OO-Method, this precise definition makes it possible to translate OBLOG specifications to production code. Besides the particular differences in expressiveness between OBLOG and OASIS, OBLOG case views the automated generation process as a transformation process based on rewrite rules. Rules are written using a specific language that must be known by designers, because the ability to customize the generated output through the rules is a key issue. The approach of the OO-Method is closer to the idea of a general code generator, where the key feature is the well-defined software representation of a predefined, finite catalog of conceptual modeling constructs. An approach that focuses more on levels of formalism is the object system analysis (OSA) model [9]. Its aim is to develop a method that enables system designers to work with different levels of formalism, ranging from informal to mathematically rigorous formalisms. In this context, this kind of tunable formalism makes it possible for both theoreticians and practitioners to work with the same model. This proposal also explores the difficulties encountered in making model and languages equivalent [11] and resolves these difficulties in the context of OSA for a particular language. OSA also has a CASE support called IPOST [10], which generates a prototype from an OSA model in an automatic way. The prototype generated is used to validate the requirements. Our approach provides a different kind of tunable formalism: the OASIS expressiveness is fully preserved, but it is presented

530

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

to analysts according to a well-known conventional graphical notation (UML compliant). The OO-Method also enforces the idea of having a model-equivalent language (a language with a oneto-one correspondence to an underlying, executable model) by implementing the system specification in an automated way according to the execution model provided by the OO-Method. This functional equivalence, which has been established between specification and automated generated code, constitutes an alternative operational implementation of the model-equivalent language metaphor. A different approach is proposed by structuredobject-based-formal language (SOFL), in [12]. Its aim is to address the integration of formal methods into established industrial software processes using an integration of formal methods, structured analysis and specifications, and an object-based method. SOFL facilitates transformation from requirements specifications in a structured style to a design in an object-based style and from designs to programs in the appropriate style. In accordance with the previous arguments, the proposal attempts to overcome the fact that formal methods have not been widely used in industry, by finding mechanisms to link OO and structured techniques with formal methods (VDM style semantics for its specification modules). In our opinion, combining structured and OO techniques in a single method is not the best idea because it makes it difficult to clarify the method semantics. An effective tool support becomes necessary for checking consistency. Furthermore, an automated transformation of process specification into programs has not yet been provided. The toolkit for requirements and design engineering (TRADE) approach [38] provides a conceptual framework that distinguishes external system interactions from internal components. TRADE contains techniques from structured and OO specification and design methods. A graphical editor called techniques for conceptual modeling (TCM) supports the TRADE framework. The most interesting contribution is the ability of introducing techniques in a method-independent way: based on its conceptual framework, TRADE

shows that structured and OO analysis offers specification techniques that can be combined to obtain a coherent software design specification. What the OO-Method provides is a precise subset of those techniques provided by TRADE. The techniques chosen have a formal semantics given by the OASIS object model. We go further in the sense that, once the techniques have been chosen, a catalog of conceptual modeling constructs is created to guide the process of generating code which is functionally equivalent to the source OASIS specification. Another important contribution of the OOMethod is the clear separation between conceptual modeling (problem space) and final software representation (solution space). We would like to point out the existence of previous work in this direction. In JSD [39] and Syntropy [40], the distinction between a universe of discourse decomposition and a software specification is made fully explicit: the decomposition done in terms of the problem space expressiveness is modeled separately from the decomposition of the software product, and the link between them is made explicit. As we have already argued, the OOMethod enforces this idea from a formal OO point of view. Furthermore, the final software representation is obtained in an automated way from the source conceptual model. To close this section, two well-known approaches with industrial tool support providing some kind of code generation features are compared with the OO-Method, in order to fix the original characteristics of the OO-Method from a pragmatic point of view. The selected approaches are Rational/UML [41] and Catalysis [42]. Generally speaking, the Rational/UML approach towards modeling, as stated by J. Rumbaugh at a keynote speech in the OOPSLA’97 in Atlanta, is to provide users with a tool to make graphical OO models using a variety of diagrams and notations. This allows users to work at an informal level, writing down several views of the system, even if they are inconsistent. The UML notation is a reference notation, allowing the same UML specification to be understood differently by different people. In that sense, UML is assumed to be non-compu-

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

table. All the methods based in some way in UML share this basic problem. Any attempt of going from the specification (Problem Space) to the final software product (Solution Space) is presented in terms of a help for the unavoidable process of programming. In other words, after the modeling process, some programming activities must be undertaken. All the approaches based on the use of UML such as Rational, share the belief that in a real project the ability to customize the generated output by hand, is a key issue. The expression ‘‘automated code generation’’ is used in the general sense of automatically producing any written information from models which are already built. This typically includes source code and several kinds of documentation, with the assumption that it is not reasonable to think that a general code generator will allow us to obtain a final software product by just compiling the conceptual model. The OO-Method introduces a basic new idea: going from the conceptual model to the final software product, following a precise and automated process of translation of conceptual model constructs into their corresponding software representations. This constitutes a step further when compared with the UML based modeling tools such as Rational/Rose, because the resultant software components that reificate the conceptual modeling constructs used by the method are clearly identified and generated in an automated way. In this context, Catalysis is a UML-compliant methodology for component and framework based development; some underlying concepts from this approach have been contributed by the authors to the definition of the unified modeling language (UML) 1.0, as submitted to the OMG in January 1997. This makes the Catalysis approach close in a natural way to those approaches based in some way on UML, and it shares with them the problems commented above. In order to highlight the most original Catalysis contributions, the following four key features must be considered: * *

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

*

*

531

collaborations: abstracting joint behavior and dialogue, frameworks: a foundation for design composition and reuse.

There are important improvements in the approach such as: *

*

*

the use of a clear semantics for the diagrams included in the methodology, the introduction of the conformance check concept, to prove that each of the abstract operations specified at a higher abstraction level is mapped to the corresponding implementation operations, the generalization of the framework concept, permitting construction of specification and design models by composition.

However, the software production process is still viewed in the classical way of going from analysis to design to implementation in a non-automated way and following a continuous process of refinement that relies completely on the modeler’s skills. Once again, a design review must focus its entire attention on the refinement: firstly, the finer actions must be related to the more abstract ones, resolving the question of which sequences of finer actions induce each abstract one. Secondly, at a finer level of detail, more detailed type-models are needed. Furthermore, the models used at the Problem Space level are type models (based on the UML class diagrams syntax) and interaction diagrams (to indicate particular processing aspects). Following the UML tradition, the precise set of conceptual modeling constructs needed to obtain a correct and complete Conceptual Schema is unclear. Finally, frameworks are said to be one of the most relevant notions of the tool. A minimum set of frameworks that are used in the code generation process must be provided in order to use the method. This set of frameworks does not guarantee a complete code generation. The particular characteristics of the final software product must be added by hand at the Solution Space level, using low-level code constructions that must be included in some way in the diagram

532

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

expressiveness provided by the method. This is again a basic difference with the automated software production process provided by the OO-Method. As has been stated in this paper, the OOMethod takes a more formal approach towards specification, facing the problem of going from specification to code generation in some kind of automated way. What is new in the OO-Method approach is to consider that the process of programming can be completely done at the conceptual model (Problem Space), where a precise system specification is generated according to the OO-Method repository, (which is based on a formal OO model (OASIS)). The OO-Method introduces the idea of compiling the specification to obtain a final software product ready to be executed (Solution Space).

nent-based systems. The implementation of these mappings from problem space concepts to solution space representations opens the door to the generation of executable software components in an automated way. These software components together constitute a software product that is functionally equivalent to the requirements specification collected in the conceptual modeling step. Summarizing, the most relevant contributions of this paper are the following: *

*

*

5. Conclusions Conventional object-oriented methodologies have to provide a well-defined software development process by which the community of software engineers can properly derive executable software components from requirements in a systematic way. Our purpose has been to address these problems in the context of a conceptual modeling approach that has been introduced. The OOMethod can be seen as a environment computedaided requirements engineering (CARE), where in order to manage the whole software production process, we focus on how to properly capture the system requirements. The resultant conceptual model specifies what the system is (problem space). Then, an abstract execution model is provided to guide the representation of these requirements in a specific software development environment (solution space, which is centered on how the system will be implemented). The abstract execution model is based on the concept of Conceptual Modeling Constructs. The OO-Method provides a well-defined software representation of these constructs in the solution space. A concrete execution model based on a component-based architecture has been introduced to deal with the peculiarities of compo-

*

The detailed presentation of the OO-Method approach as a successful attempt to cover the entire software production process from an OO point of view in order to get the best from conventional and formal methods. A process to support Component-based development within the OO-Method methodological approach. A specific strategy to generate code based on a clear separation of component specification and component implementation to enable technology-independent application design. A well-defined component-based framework to execute the specification in the solution space.

These ideas are being applied in the context of a component-based development tool that has been called JEM. JEM is a Java-based implementation for the OO-Method Execution Model. The basic purpose of JEM is to animate conceptual models captured with the OO-Method, over distributed internet/intranet environments. JEM fulfills the requirements with respect to the model and the architecture proposed in this paper for the execution model. A beta version of JEM can be reached at: http://oomethod.dlsi.ua.es:8080/jem. 5.1. Research directions and further work Our current line of research is focused on improving the quality of the final software product that is generated. This includes advanced features such as a better user interface framework, optimized database access mechanisms for dealing with distributed computing as well as how the structure of the generated code affects the performance of the system.

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

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, PrenticeHall, 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 prototyping environment, in: Proceedings of DEXA’95 International 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 International 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, objectoriented, model-equivalent programming language, in: M.P. Papazoglou (Ed.), Proceedings of OOER’95 International 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 environment 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.

533

! [14] O. Pastor, V. Pelechano, E. Insfr!an, J. Gomez, From object oriented conceptual modeling to automated programming in Java, 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. 183–196. [15] O. Pastor, F. Hayes, S. Bear, OASIS: an object-oriented specification language, in: P. Loucopoulos (Ed.), Proceedings 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 conceptual models, Ph.D. Thesis, Vrije Universiteit, Amsterdam, 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 beyond, 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, Implementing 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 University, 1997, pp. 101–116. [26] O. Pastor, E. Insfr!an, G. Quiles, J. Barber!a, Objectoriented 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.

534

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

[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 ADBIS’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, Englewood Cliffs, NJ, 1983. [40] S. Cook, J. Daniels, Designing Object Systems: ObjectOriented Modelling with Syntropy, Prentice-Hall, Englewood 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.