object-oriented (OO) model as a software production paradigm that covers all ..... component classes of the Java Execution Model, we introduce a Rent-a-Car ...
Linking Object-Oriented Conceptual Modeling with Object-Oriented Implementation in Java Oscar Pastor, Emilio Insfrán, Vicente Pelechano, Susana Ramírez Departament de Sistemes Informàtics i Computació Universitat Politècnica de València Camí de Vera s/n 46071 Valencia (Spain) {opastoreinsfranpele}@dsic.upv.es
Abstract Nowadays, if we want to obtain a sound and correct final software product it is very important to be able to properly join modern OO programming environments, which are built for the new Internet architectures, with the OO methodologies produced over the last few years in order to deal properly with the Conceptual Modeling process. Our contribution to this objective is the OO-Method [Pas96] proposal. OOMethod is an OO Methodology that allows analysts to introduce the relevant system information by means of a set of graphical models to obtain the conceptual model through a requirement collection phase, so that an OO formal specification in OASIS [Pas95] can be generated at any given moment. This formal specification acts as a high-level system repository. Furthermore, a Java software prototype, which is functionally equivalent to the OASIS specification, is also generated in an automated way. This is achieved by defining an execution model that gives the pattern to obtain a concrete implementation in the selected target software development environment. A CASE workbench [Pas97] supports the methodology.
1. Introduction Software technology has undergone, over the last few years, considerable transformation. One of the main reasons for this transformation is the emergence of the object-oriented (OO) model as a software production paradigm that covers all the traditional analysis, design and implementation steps. We have OO methodologies [Boo94, Col94, Jac92, Rum95], OO databases, OO programming languages, etc. However, we consider that there is still not a clear understanding of what an object is. Or, better explained, everyone understands perfectly what his/her objects are. The problems come from the fact that often objects in conceptual modeling are not the same as in programming or database environments. Consequently, ambiguities appear everywhere. The OO approach is still a loosely defined term, even if some salient
features constitute a minimum basis (complex objects, object identity, methods, encapsulation, inheritance) The source of this confusion can be found in the lack of a standard and universal formal approach for the OO model. Many attempts have been made in the OO logic area [Jun91, Kif96] and research continues. OO logic attempts to provide a unified logical formalism for modeling objects and other aspects of the OO paradigm [Dub94, Har94]. However, the situation reached with the relational model, from the formal point of view, has not yet been reached in the OO model. In this context, Inter/Intranet architectures and web environments are starting to be widely used, and this has been announced as a software computing revolution. The common software development environment for such an environment is claimed to be a Java-based one. Of course, Java [Arn96,Gos95,Kra95,Lem96,Tit95] is presented as an OO programming language. At the same time, continuous efforts are being made in the area of OO conceptual modeling, especially in terms of OO methodologies that have their corresponding CASE workbench [Boo97,Pas97] in order to provide reliable and productive software production environments. The lack of a precise connection between the conceptual modeling world and the software development tools in web environments is, in our opinion, one of the most interesting problems. We have to close this gap to be able to properly design and implement organizational systems [Fri90] using three-tiered architectures based on simple and easy-to-use client stations, web servers and database servers. Our contribution to this state of the art is presented in this paper. With our OOMethod proposal, we provide an OO methodology that covers the phases of Analysis
and Design, obtaining a formal specification in a formal and OO specification language called OASIS. It acts as a high-level data dictionary, where all the relevant system information is captured. A Java prototype, including both static and dynamic properties, is obtained in an automated way starting from the OASIS specification. The static properties are represented in a relational database schema and the dynamic properties are represented by generating Java applets and web interfaces that include the dynamic behaviour of the component system classes. The main features of this approach are the following: 1. The formal system specification is obtained in an automated way from the graphical information introduced during the OO-Method analysis process. 2. The Java implementation is also obtained in an automated way from the formal system specification. This is done implementing a precise mapping between formal specification concepts and Java components. We have divided the paper into the following sections: after the introduction, in section 2, we present the most important OO-Method features. In section 3, we give a quick overview on the actual proposals related to Java development environments. Next, in section 4, we explain how the OO-Method analysis models are translated to a Java environment. This is done by determining the exact architecture of the concrete execution model implementation, developed in Java, which is attached to the conceptual model (built in the OO-Method analysis step). We finish this paper with conclusions and a list of references.
2. The OO-Method Proposal
OO-Method is an Object-Oriented Software Production Methodology based on two essential models: the conceptual model and the execution model. The software production process in OO-Method starts with the conceptual modeling step where we have to determine the relevant system properties without being worried about any implementation details. Once we have an appropriate system description, a well-defined execution model determines all the implementation-dependent properties of the final software product in terms of user interface, access control, service activation, etc. The conceptual model describes the Information System within a well-defined OO framework using three complementary point of views: •
Object Model: is a graphical model where system classes including attributes, services and relationships (aggregation and inheritance) are defined. Additionally, agent relationships are introduced to specify who can activate each class service.
•
Dynamic Model: is another graphical model to specify valid object life cycles and interobjectual interaction. We use: •
State Transition Diagrams to describe correct behaviour by establishing valid object life cycles. By valid life, we mean a right sequence of states that characterizes the correct behaviour of the objects for every class.
•
Object Interaction Diagram: represents interobjectual interactions. We define two basic interactions: • Triggers, which are object services that are activated in an automated way when a condition is satisfied.
• Global interactions, which are transactions involving services of different objects. Interobjectual transactions can be defined with these global interactions. • Functional Model: is used to capture semantics attached to any change of an object state as a consequence of an event occurrence. We specify declaratively how every event changes the object state depending on the involved event arguments (if any) and object’s current state. We give a clear and simple strategy (classification of attributes [Pas96]) for dealing with the introduction of the necessary information. This is a contribution of this method that let us to be able to generate a complete OASIS specification in an automated way. From these three models, a corresponding formal and OO OASIS [Pas95] specification is obtained using a well-defined translation strategy. The resultant OASIS specification acts as a complete system repository where all the relevant properties of the component classes are included. Once all the relevant system information has been collected, the execution model accurately states a pattern used to implement object properties in any target software development environment. The phases of the methodology can be seen in Figure 1. At this point, we give an abstract view of an execution model for dealing with the task of implementing the conceptual model. According to the execution model, a prototype, which is functionally equivalent to the OASIS specification, is built in an automated way. The code generation strategy is independent of any concrete target development environment.
A CASE Tool [Pas97] that provides an operational environment that simplifies the analysis, design and implementation of Information Systems from an object-oriented perspective supports OO-Method. The contribution of this CASE environment is its ability to generate code in well-known industrial software development environments (Java, Visual C++, Delphi, Visual Basic and PowerBuilder) from the system specification. It constitutes an operational approach to the ideas of the automated programming paradigm [Bal83]: collection of system information properties, automated generation of a formal OO system specification, and a complete (including static and dynamics) software prototype which is functionally equivalent to the quoted system specification.
OO-Method Object Model
Conceptual Model
Dynamic Model
Functional Model
Automated Translation
OASIS Execution
Automated Translation
Model PowerBuilder RDB
Java RDB
Visual C++ RDB
Delphi RDB
Figure 1. Phases of OO-Method.
3. Java as a Software Development Environment Nowadays the Internet and Web have become the new frontier for application developers. In this context, Java is playing an important role due to its promising features: architecture independence, portability, multithreading, soundness, security and so on. That means that new needs arise: Java tools, methodologies, CASE tools supporting Java code generation, etc.
Most of the products developed in this area are RAD-oriented, visual development tools (Symantec’s Café, Borland’s Latté, Visual J++, IBM’s Visual Age for Java, etc.). In the methodology field there are some well-known analysis/design CASE tools for example Rational’s ROSE/Java, Platinum’s Paradigm Plus, and Forté that provide the developers with limited support to fully implement Internet/Intranet applications. These proposals share a common weakness: when the development step is reached, the conceptual modeling efforts are unclear, mainly because it is not possible to produce an accurate code that is functionally equivalent to the specification of the system requirements. We should be able to produce code which includes statics and dynamics in an interactive way from the very beginning of the requirement specification step, and not generate only static templates for the component system classes as most OO CASE tools do. OO-Method solves these problems allowing analysts and designers to build conceptual models of information systems following a methodology that is oriented to generating Internet/Intranet applications based on Java in an automated way.
4. Implementing an OO Conceptual Model in a Java Environment In this section, we explain how to implement an OO Conceptual Model in an Internet/Intranet development environment. We use Java as a programming language and a relational database [Pas97-2] as a persistent object repository as illustrated in Figure 2. For this purpose OO-Method uses an abstract execution model based on the conceptual model. This execution model is used to generate a sound and robust implementation of a system specification in any target environment. The generation process is carried out binding the execution model and the specific features of the selected programming environment, in this case Java. First, we present the basic
features of the OO-Method execution model and then we explain the actual Java implementation of this execution model by showing the set of Java classes that make up the prototype.
User Browser enabled for Java (Hot Java, Comunicator, Explorer, Mosaic,...)
World Wide Web
IBM Compatible
Web Server Relational Database
HTML Documents & Applet element
Applets Relational DataBase Server
JDBC CASE Tool Generates
Java Applets HTML Documents Relational Tables
Figure 2.Global Architecture of the proposed Internet/Intranet prototype in Java.
4.1 The OO-Method Abstract Execution Model The OO-Method execution model explains a pattern to be used to implement all the system properties collected during the analysis phase, in any target software development environment. The code generation process will use this execution model as a guide in order to implement the conceptual model in the selected target environment. This execution model has three main steps:
1. access control: first, as users are also objects, the object logging in the system has to be identified as a member of the corresponding object society. 2. object system view: once an object is connected, it must have a clear representation of which classes it can access. In other words, its object society view must be clearly stated, exactly determining the set of object attributes and services that it can see or activate. 3. service activation: finally, after being connected and having a clear object system view, an object will be able to activate any available service in its worldview. Among these services, we will have event or transaction served by other objects or system observations (object queries). Any service execution is characterized as the following sequence of actions: 1. object identification: as a first step, the object acting as server has to be identified. This object existence is an implicit condition for executing any service unless if we are dealing with a new1 event. At this point, the object attribute values (those that characterize its current state) are retrieved. 2. introduction of event arguments: the rest of the arguments of the event being activated must be introduced. 3. state transition correctness: we have to verify in the object State Transition Diagram (STD) that a valid state transition exists for the selected service in the current object state. 4. precondition satisfaction: the precondition associated to the service that is going to be executed must hold. If not, an exception will arise, informing that the service cannot be activated because its precondition has been violated.
5. valuation fulfilment: once the precondition has been verified, the induced event modifications are effective in the selected persistent object system. 6. integrity constraint checking in the new state: to assure that the service activation leads the object to a valid state, we must verify that the (static and dynamic) integrity constraints hold in this final resulting state. 7. trigger relationships test: after a valid change of state, and as a final action, the set of rules condition-action that represent the internal system activity have to be verified. If any of them hold, the corresponding service activation will be triggered. It is the analyst’s responsibility to assure the termination and confluence of such triggers. The previous steps guide the implementation of any program to assure the functional equivalence between the object system description collected in the conceptual model and its reification in a software-programming environment according to the execution model. 4.2 An Architecture for implementing the Execution Model in Java The strategy adopted in our work is based on the development of Java applets that implement the full functionality of the system modeled. The architecture of an OO implementation in Java that corresponds to an OO Conceptual Model is shown in Figure 3. The components are the following classes: • System class • Menu_Page class • Parameter_Request class
• set of Analysis classes that corresponds to the classes detected in the analysis phase • Database class
System
Menu_Page
Param_Req
DataBase Analysis Clases
Figure 3. Class Diagram of the Java Prototype The System class is the main class of the architecture. This class is composed of the Menu_Page, the Parameter_request, the set of Analysis classes and the Database class. The System class implements the three main steps of the execution model: •
control user access to the system looking for the existence of an authorized object in the database. This way of accessing control allows any system object to be an active user of the object society and is only restricted by the agent relationships defined in the conceptual model (client/server relationship).
•
create a new Menu_Page instance (this page will show a typical web menu page in the client browser) with as many options as classes are visible to the connected user. When the user selects one class, the services that the user is able to activate are shown.
•
facilitate the activation of services requested by the user. For this purpose the System instance creates a new Parameter_Request object to capture all the required argument values for the quoted service activation.
We have as many Analysis classes in the Java prototype as system component classes are in our source Conceptual Model. The Database class acts as a bridge between the relational database storage of the Analysis class objects and their corresponding Java objects managed by the user’s web browser. The main features of this object class include services to retrieve and update the database according to the object changes of state during the prototype execution. All the classes described above have attributes and methods (services) that support the whole execution model. In this paper, we are not going to show every complete class specification (methods and attributes). 4.3 Linking an OO Conceptual Model to an implementation in Java In order to better understand the architecture and behaviour of the previous component classes of the Java Execution Model, we introduce a Rent-a-Car case study as a brief example: “A company is involved in the rented of vehicles without drivers as a principal activity. The vehicles are bought at the beginning of the season and are usually sold when the season is over. When a customer rents a car, a contract is generated and it remains open until the customer returns the vehicle. At that time, the total amount to be pay or refunded to the customer (in the case of surety) is calculated. After this step, the car is ready to be rented again”.
First, we construct the Conceptual Model (object, dynamic and functional models) identifying the classes and specifying their relationships and all the static and dynamic properties. The classes identified in this problem domain are the following: Contract, Customer, Vehicle and Company. Based on the Execution Model proposed above, the architecture of the Java applet attached to the conceptual model is shown in Figure 4. In this figure, we are representing a particular Class Diagram for the Rent-a-car case study where the System class has every analysis class as components.
System
Menu_Page
Param_Req
Analysis Classes
DataBase Company
Contract
Customer
Vehicle
Figure 4. Class diagram for the Java prototype of the Rent-a-car case of study. Next, we are going to describe an illustrative scenario for the Rent-a-Car prototype generated. This scenario will show the interaction between Java objects and their behaviour when a user enters into the object system. When a client loads the main HTML page that calls the Java applet, an instance
of the System class is created and User identification is required (see Figure 5). Figure 5. A User Access Control Page. After a User connects to the Rent-a-Car system, a menu page with an option for every class will appear (see Figure 6). If the user clicks in a class option, a new menu page associated with the selected class will be generated (including one option for every class event or transaction).
Figure 6. Rent a Car System option page. In our example, when the user selects the Car class, the service list offered by this class is shown, as can be seen in Figure 7.
Figure 7. Car Class Services Menu Page. Every service option activation will generate a new request parameter page, as can be seen Figure 8. This page will ask the user for the parameters needed to execute the event/transaction. The Ok control button has a code associated to it that will call to a class method that implements the effect of the event on the object state. This method will check the state transition correctness and method preconditions. If this checking process succeeds, the object change of state is carried out according to the functional model specification. We finish the method execution by verifying integrity constraints and trigger condition satisfaction in the new state. Object state updates in the selected persistent object system became valid through the services offered by the Database object.
Figure 8. Parameter Request Page for the Create Service of the Car Class. This execution model assures the functional equivalence between the conceptual model and its reification in a Java-programming environment. This feature opens up the
possibility of creating a CASE tool which could generate a Java prototype implementation, starting from a set of graphical OO models obtained during the conceptual modeling step (according to OO-Method), in an easy and unambiguous way.
5. Conclusions and future work In the next few years, advanced web applications will depend on object technology to make them feasible, reliable and secure. To achieve this goal, welldefined methodological frameworks must be introduced, properly connecting OO conceptual modeling and OO software development environments, including programming languages and databases. Our contribution is to provide just such an environment to obtain a functionally equivalent Java prototype in an automated way starting from a conceptual model that captures all the relevant system properties. The most relevant features are the following: •
it provides an operational implementation of an automated programming paradigm, where a concrete execution model is obtained from a process of conceptual model translation
•
it uses a precise object-oriented model, where the use of a formal specification language as a high-level data dictionary is a basic characteristic
This is done within the next-generation web development environments, making use of the Inter/Intranet architectures by using Java as software development environment. Research work is still being undertaken to improve the quality of the final software product that is generated, and to include advanced features such a schema evolution or optimized data base access mechanisms.
References [Arn96] Arnold K., Gosling J. The Java Programming Language. Sun MicroSystems. Addison-Wesley, 1996. [Bal83] Balzer R. et al. Software Technology in the 1990s: Using a New Paradigm. IEEE Computer, Nov. 1983. [Boo94] Booch G. OO Analysis and Design with Applications. Addison-Wesley, 1994. [Boo97] Booch G., Rumbaugh J., Jacobson I. Unified Modeling Language. Version 1. Rational Software Co., 1997. [Col94] Coleman D., Arnold P., Bodoff S., Dollin S., Gilchrist H., Hayes F., Jeremes P. Object-Oriented Development. The Fusion Method. Prentice-Hall, 1994. [Dub94] Dubois E., Du Bois Ph., Petit M., Wu S. ALBERT: A Formal Agent-Oriented Requirements Language for Distributed Composite Systems. Proc. CAiSE’94. Workshop on Formal Methods for Information System Dynamics, pags: 25-39, University of Twente, Technical Report 1994. [Fri90] Lindgreen P. ed. A Framework of Information System Concepts. FRISCO Interim Report. IFIP WG8.TG.90, 1990. [Gos95] Goshling J., McGilton H. The Java Language Environment. A White Paper. Sun MicroSystems. 1995. [Har94] Hartmann T., Saake G., Jungclaus R., Hartel P., Kusch J. Revised Version of the Modelling Language Troll (Troll version 2.0). Technische Universitat Braunschweig, Informatik-Berichte, 94-03. 1994. [Jac92] Jacobson I., Christerson M., Jonsson P., Overgaard G. Object Oriented Software Engineering. A Use Case Driven Approach. Reading, Massachusetts. Addison-Wesley. 1992. [Jun91] Jungclaus R., Saake G., Sernadas C. Formal Specification of Object Systems. Eds. S. Abramsky and T. Mibaum Proceedings of the TapSoft´s 91, Brighton. Lncs. 494, pags. 60-82, SpringerVerlag. 1991. [Kif96] Kifer M. Deductive and Object Data Languages: A Quest for Integration. DOOD96. pags: 187212. 1996. [Kra95] Kramer D. The Java Platform. Sun MicroSystems. Addison-Wesley. 1995. [Lem96] Lemay L., Perkins C., Cadenhead R. SunSoft Java Workshop. Sams.Net Publishing 1996. [Pas95] Pastor O., Ramos I., Canós J. Oasis v2: A Class Definition Language. Proc. DEXA95, SpringerVerlag. 1995. [Pas96] Pastor O., Pelechano V., Bonet B., Ramos I. An OO Methodological Approach for Making Automated Prototyping Feasible. Proc. DEXA96. Springer-Verlag. September 1996. [Pas97-1] Pastor O., Insfrán E., Pelechano V., Romero J., Merseguer J. OO-METHOD: An OO Software Production Environment Combining Conventional and Formal Methods.CAiSE97. June 1997. Accepted for presentation. [Pas97-2] Pastor O., Insfrán E., Quiles G., Barberá J. Object-Oriented Conceptual Modeling Techniques to Design and Implement a Sound and Robust Oracle Environment. EOUG97. 1997. Accepted for presentation. [Rum91] Rumbaugh J., Blaha M., Permerlani W., Eddy F., Lorensen W. Object Oriented Modeling and Design. Englewood Cliffs, Nj. Prentice-Hall. 1991. [Tit95] Tittel E., Gaither M. 60 Minute Guide to Java. IDG Books WorldWide, Inc. 1995.
