OBJECT MODELS FOR MODEL BASED APPLICATIONS *

Transcription

1 OBJECT MODELS FOR MODEL BASED APPLICATIONS * Giorgio Bruno, Marco Torchiano Dip. Automatica e Informatica, Politecnico di Torino, C.so Duca degli Abruzzi 24, Torino, Italy bruno@polito.it, torchiano@polito.it Key words: Abstract: process-driven system, operational model, object model In the enterprise information systems environment, web based systems in general, and e-commerce applications in particular, are required to face a very high pace of change. The evolution of such systems is caused both by adaptation to the customer needs and enterprise continuous improvement strategies. Such rapid change can be achieved adopting a model-based approach in which the application is customized according to a model. The concept of model proposed in this paper is more wide that the one adopted in most modeling languages such as UML. We propose an object model that allows an application access the model according to different perspectives and abstraction levels. 1. INTRODUCTION Models, in the enterprise environment, can be used as analysis and management tools or can be used to describe software systems requiring a high degree of flexibility. Enterprise models have been widely adopted by consulting firms in order to conduct Business Process Reengineering activities and Quality Assurance projects; in recent years they served as powerful tool to perform ERP customisation. Many modeling languages (Vernadat 1997) have been proposed to describe enterprise systems. The development of related software system is based on the adoption of object-oriented technologies (Manola 1999) (Bruno 2000). Often in e-commerce systems the interaction patterns between the users and the system can become quite complicate. Process-driven systems (Sheth 1999) represent a recent approach to face such complexities. Such systems are based on workflow systems, which can possibly interact with peer systems on the internet (Agarwal 2000a). The approach presented in this paper is aimed at the development of model based prototypes and applications. The model-based paradigm uses models, not only during the analysis and design phases of the system life cycle, but also as the core component of the final system. The result are flexible and integrated applications. The main advantages of using a model-based application are: a model can be understood and created also by non-experts, to change the software system, only the model needs to be modified, the model is always an up-to-date representation of the actual running system. Models can also provide the organizing framework where each component, making up a complex system, can be settled find its place. Such a unifying framework is particularly useful for web-based systems. The adoption of model-based development enhances the maintainability of the system guaranteeing an automatic coherence between the model and the running system. We begin presenting the OPJ model based approach, then we investigate the process-driven category of systems and present a sample model of such a system, finally we present the architecture of applications built using our approach. The paper s intent is to provide an overview of OPJ (OPerational objects) and to show how such methodology can be used to build model based applications. In particular we will show how OPJ can deal with domain-specific semantic issues, by means of different object-models. To pursue such purpose at * Appeared in Proceedings of 3 rd International Conference on Enterprise Information Systems, Sétubal, Portugal, July 7-10, 2001, pp

2 first we will provide an overview of the OPJ methodology. Then we will try to understand what object models (OMs) are, by providing a comprehensive overview of OMs that are widely used or supported. After that the OPJ supporting architecture is presented, which is based on different object models. 2. THE OPJ APPROACH This section provides an overview of OPJ, which is an operational object-oriented methodology to develop model-based applications. A model-based application is a software system, which not only can be derived by an automated from a model, but draws information from the model itself at run-time. OPJ is made up of two different parts: the OPJ modeling methodology and the OPJ supporting environment. The latter defines a set of features required to support the former. OPJ enriches common object-oriented models with a precise operational semantics. An operational model contains a possibly abstract description of the system, like any model, and in addition an operational part which serves as a set of constraints in the following phases of the modeling life cycle. An operational model can be used to derive a new model; the former is an abstract description of the latter. A very similar relationships exists among a class diagram and the software system, made up of objects, it describes In addition to a normal class model, an operational model can define both what operations can be performed to build a derived model and what operations the derived model can perform. The final software application is the last and most detailed model of this operational derivation chain. Building upon the fundamental capabilities of the operational models, the OPJ methodology has been define. The methodology is made up by three main phases: domain modeling, system modeling, and model operation. Domain modeling aims at providing a collection of classes of building blocks intended to address all the potential systems belonging to the domain of interest. It abstracts the general properties from the actual problems under study and defines a common approach for a whole family of similar problems. The process of defining classes and relationships in object-oriented analysis is an example of domain modeling. System modeling applies the results of the previous phase, in that its purpose is to build the model of an actual system by means of a composition of building blocks. The operations, which were defined in the previous phase, can be applied and the modeling activity can be carried on, provided the constraints defined there are satisfied. These phases can be performed by different roles. Typically an expert of modeling and of the tool could analyse the problem together with problem experts and build a sort of modeling vocabulary (the domain model), which will be used by problem experts to model an actual system. The OPJ methodology describes a system by means of two modeling artefacts: schemas and system models. A schema is a collection of class diagrams that describe the domain model of the system. It is based on the object-oriented paradigm. The authors have developed a graphical notation to describe class diagrams; anyway it can be replaced by any enough powerful notation such as UML (OMG 1999). Thus the modeling phase of the methodology is quite equivalent to what can be carried on using the UML approach. A system model is a collection of objects linked to each other, together with associated information, that is an instance model. Such a model must conform to a schema. The final phase in the life cycle is model operation; this is a quite generic term that can assume different meanings depending on the kind of the model. In its simplest meaning, model operation consists of the use of a system model as documentation provided a suitable model browser is available. For a business process it could mean enactment, for a software system it means both prototyping and application deployment and execution. The OPJ methodology is based upon an integrated environment, which supports all phases of the life cycle, as shown in Figure 1. defines USER uses Domain Model customizes modeling tool conforms to produces System Model enactment prototyping code synthesis Figure 1: The OPJ environment. A generic domain-modeling tool, as an example a UML compliant CASE tool, can be used to define a domain model. Such a model can be used to customize a suitable system-modeling tool in order to offer a friendly modeling environment, which enables the construction of a system model. Once the system model has been developed it can serve as

3 it is as documentation. In addition, if a suitable supporting architecture is provided, the system model can be the basis for a model-based system allowing both prototyping and execution of a fullfledged application. A model based application uses a model as a sort of very high level programming language, which is used to describe both the internal structure of the software system and the conceptual model that is presented to the user. OPJ adopts an approach similar to Model-Integrated Computing (MIC). The MIC (Karsai 1997) methodology develops applications in an operational fashion, according to a process that is completely centred upon models. The final system can be automatically synthesized starting from the information contained in the models, but the model is not part of the software system, as happens in OPJ. 3. OBJECT MODELS This section provides an overview of the most meaningful and widely used object models. We will use the term object model in the sense of a collection of object classes defined to model a particular system or application (Manola 1999). The Document Object Model (DOM)(W3C 2000) is an application-programming interface (API) for valid HTML and well-formed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model. OMG Meta-Object Facility (MOF)(OMG 1997) defines a basic (yet not quite simple) object model to create meta-models that are intended to be the basis of a domain specific modeling tool. MOF defines a set of generic interfaces to access model elements; in addition according to the MOF guidelines a set of domain-specific interfaces can be synthesized in order to provide access to the model. The purpose of the MOF specification is to provide a standard means of accessing virtually any kind of model, from object-oriented models to entityrelationship ones, in a consistent way. Such a capability could improve tool interoperability and foster model repositories, which can be used in a distributed environment The ODMG binding for Java(Barry 1998) is an industry standard that provides native Java object storage and Java application portability between compliant object storage products. The binding element of the standard extends Java with a full set of database programming features that allows Java application developers to build complete database applications entirely from within the Java language. The primary benefit of the ODMG binding for Java is its tight integration of application and database programming into a single, native Java data model. The Java Enterprise Architecture, defined in the Java 2 Enteprise Edition proposes an application model(sun 1999) suited for implementing services as multi-tier applications that avoid the problems of scalability, accessibility, and manageability that usually appear in such applications. The Java enterprise server represents the basic module of the architecture; it provides the naming and directory service, which allows programs to locate services and components; in addition it provides authentication services. Enterprise bean instances run within an EJB container. The container is a runtime environment that controls the enterprise beans and provides them with important system-level services. It simplifies the development of the components providing transaction management, security, remote client connectivity, life cycle management and database connection pooling. The Web container is a runtime environment for JSP files and servlets. There are two types of enterprise Beans: session Beans and entity Beans. A session Bean represents a transient conversation with a client. A session Bean might access itself the database or it might use an entity Bean to make the call. The session Bean is not persistent. An entity Bean represents data in a database and the methods to act on the data. This model can be easily used for relational databases and is not restricted to object databases. 4. OPJ ARCHITECTURE In this section we will describe the architecture of the OPJ supporting environment. Such an environment is made up of various cooperating object models. The OPJ architecture can be implemented using different communication infrastructures such as COM or EJB. The object models provide operational tools to operate on models and application data. In addition they provide both horizontal and vertical semantics needed by model-based applications. The basic OM

4 provides a horizontal, though simple, semantic level similarly to MOF. Entity objects provide a more specific semantics, customized for each specific kind of information managed by the system, in an ODMG fashion. Finally, session objects provide a vertical, process specific semantics, like Session Beans in the Java Enterprise Architecture. The OPJ Architecture is a quite generic environment, it has been implemented using particular tools and technologies, but it can be implemented by adopting any powerful enough technology. As a proof of concept two alternative implementations have been produced; one is based on the COM technology, the other is based on the Java platform. Session Objects Entity Objects Core object-model Information storage Model navigator Model Repository Figure 2: OPJ Architecture. Procurement Purchasing Core OM Application Database 4.1 Information Storage Workflow Workflow engine Application Database Two kinds of information are used in the OPJ environment: models and application data. The models developed during the first two phases of the OPJ process (domain modeling and system modeling) are hosted in a specific model repository. The application data are the operational information used by common enterprise activities; they could be found in legacy systems or generated automatically. The repository contains both a structural and a semantic description (metamodel) of the application data contained in the application database. The repository can contain models of the data structures needed by the applications; such models can be used to automatically generate database schemas and tables, for the application database and workflow database. In Figure 2 we presented under the same broad term of application data many different information, possibly legacy. As an example such data can be about orders, personnel, suppliers, and customers. 4.2 Core Object-Model The Core Object-Model provides the following advantages: an integrated view of the models during all phases of the OPJ life cycle; a simplified navigation through the models; a uniform view of both models and application data. Basically it is an interface through which a model can be accessed and manipulated. The Core OM provides access to both the domain models and the system models. Such a solution makes it possible to use a single, yet flexible enough, modeling tool for both first phases of the OPJ life cycle. The OM is based on a simple ontology, which is made up of three main concepts: classes, relationships, and containment. Classes and relationships, which form the basis of the object-oriented paradigm, are widely known concepts. Recent works (Motschnig-Pitrik 1999) focus on the importance of containment in objectoriented methodologies. In OPJ containment is used in different ways: first it forms the backbone of the models, making them well structured; then it behold a strong operational semantics. The result is a constructive semantics that defines the rules and constraints to be applied to build system models. The discussion of containment in the OPJ methodology is beyond the scope of the present paper, further details can be found in (Agarwal 2000b). The Core OM conforms to the well-known semantics of the object-oriented paradigm (Wegner 1987), adding the ability to navigate the models. Therefore it is very similar to MOF. The Core OM provides a set of operations that can be performed upon the model. In addition, the Core OM provides an operational semantics to many constructs present in the domain model. At last, the Core OM manages the persistence of model elements and application data into the model repository or application database. 4.3 Entity objects The simplified semantics exhibited by the Core OM allows the definition and manipulation of simple models only. But real-world problems require more complex models. Thus we need a more powerful and expressive category of object-models. It is not convenient to build a single large object model dealing with all the possible application domains. A better solution is to have specialized object models for different domains. This kind of

5 object models forms a new layer in the OPJ architecture. The elements of this layer are named wit term Entity Objects, which is borrowed from the Java Enterprise Architecture. The main purpose of Entity Objects is to provide a simplified access to complex information, like the DOM. In addition the persistence of information in an underlying information store is provided, in this sense Entity Objects play a role similar to ODMG classes or Java entity beans. The Entity Objects are used for application specific data, and usually interact with the application database, while the Core OM can draw data from both kinds of information stores. The persistence of the information contained in Entity Objects can be handled directly by the Entity Objects themselves or by means of the Core object model. The Entity Objects can be automatically synthesized starting from the information contained in the domain model. 4.4 Session Objects Session Objects are the elements that constitute the upper layer in the OPJ architecture shown in Figure 2. They are responsible for the specific semantics of well-defined tasks. In UML such tasks are usually specified by means of use-case diagrams. Such object models are very specialized, and manage a well-defined portion of an application domain. As an example, one of them could manage all the details of the procurement process. They embed an operational semantics, in that they control the operations required to perform a welldefined task. They play a role similar to session beans in the Java Enterprise Architecture. Some session objects are quite generic, such as the model navigator or the workflow depicted in Figure 2. They can be reused across different application domains. The Procurement object, on the contrary, belongs to a well-defined application domain. 5. SYSTEM PROTOTYPE In this chapter we will briefly describe a prototype implementation of the OPJ architecture based on the Java Enterprise platform. The Core object model has been developed by means of entity beans. The first step in deploying a specific application was the generation of a database. The schema used in such operation was drawn by the domain model. In particular we used the domain model of the procurement process, which is described in details later in this section. Then using the information provided by the domain model, a suitable set of entity beans has been synthesized, which implement the Entity Objects. These elements represent the basis on which the upper part of the prototype is founded on. Such part of the system is represented in Figure 3. Session Beans Web Browser Servlets Workflow class Login { Procurement Web Server Modeler Figure 3: Upper part of the prototype. Three different session objects have been developed for the purpose of this prototype: a workflow management engine, a modeler module, and a procurement module. The user interaction takes places by means of a web browser, which interacts with a web server. The coupling of the web server and session objects has been implemented by means of Java Servlets. 5.1 Procurement The session objects implemented in the prototype are relative to procurement. The steps required to purchase indirect goods in a large enterprise can be very complex; many kind of information are required to fulfil this task. Usually an employee that needs some kind of goods has to fill-in a formal purchase requisition; periodically a purchase order can be produced, which collects a group or requisitions. According to an approach proposed elsewhere (Bruno 2000) by the authors, each class of a business domain has got its own life cycle, described by means of a business process. The relationships among business objects are reflected into interactions among the related processes, as shown in Figure 4.

6 Purchase Requisition GoodsAccepted GoodsReceived SupplierInvoice InvoiceReceived InvoiceEntered PaymentConfirmed PaymentPrepared PurchaseOrder Enterprise Java Beans or COM/MTS, the result of such a merge would be a scalable and widely deployable solution. Future work will be devoted to: better integration with UML related standards, enlargement of the part of system synthesized from model information, integration with enterprise frameworks. GoodsChecked SupplierDelivery Figure 4: Purchasing processes. The PurchaseRequisition process describes the interaction of the employee with the homonymous business object. The PurchaseOrder process collects a number of requisitions and manages the interactions with the supplier with the help of a pair of other processes: SupplierInvoice and SupplierDelivery. When the supplier delivers the requested goods the SupplierDelivery process notifies the PurchaseOrder process that on its turn dispatches the notification to each awaiting PurchaseRequisition process, which require the employees to accept the delivered goods. The PurchaseOrder process collects all the acceptances in order to accept the whole delivery. In a similar manner are handled the supplier invoices; they are received by the SupplierInvoice process which notifies the PurchaseOrder process, which dispatch the details to all the awaiting PurchaseRequisition processes, which on their turn require the employees to confirm the payment. The PurchaseOrder process collects all confirmations, then prepares the payment and forwards it to the SupplierInvoice process, which is in charge of performing the payment. 6. CONCLUSIONS The OPJ methodology consists of an integrated approach to the analysis, design and implementation of complex systems in the area of enterprise systems and e-commerce systems. The proposed approach supports most aspects of enterprise modeling. In fact models can be used as business reengineering tools, as enterprise analysis tools or to design and develop a full-fledged application. A working prototype using Java technology has been built as a proof of concept, such system demonstrates the feasibility of the approach. Most of the elements of the prototype have been implemented using ad-hoc techniques. Though it is possible to merge the OPJ approach with a middleware enterprise framework, such as 7. REFERENCES F.B.Vernadat Enterprise Modeling Languages in Enterprise Engineering and Integration: Building International Consensus: Proceedings of ICEIMT'97, Torino, Italy, October 28-30, 1997, K.Kosanke and J.G.Nell editors, pages , Springer-Verlag, Berlin. W3C 2000, Document Object Model (DOM) Level 1 Specification (Second Edition), Version 1.0, Working Draft. ( ) G.Karsai, A.Misra, J.Sztipanovits, A.Ledeczi, M.Moore Model-Integrated System Development: Models, Architecture and Process, IEEE 21st Annual International Computer Software and Application Conference (COMPSAC) pp F. Manola 1999 Technologies for a Web Object Model, IEEE Internet Computing, 3(1), January-February. OMG 1997 Meta Object Facility (MOF) Specification. P.Wegner 1987 The Object-Oriented Classification Paradigm, in B.Shriver, P.Wegner, editors. Research Directions in Object-Oriented Programming. MIT Press. G.Bruno, M.Torchiano 2000 Process Enabled Information Systems in Proc. of 2nd International Conference on Enterprise Information Systems (ICEIS2000), Stafford, UK. G.Bruno, M.Torchiano 1999 Making CIMOSA Operational: the experience with the PrimeObjects Tool Computers in Industry 40(2-3), pages , Elsevier Science. R.Agarwal, G.Bruno, M.Torchiano 2000 An Operational Approach to the Design of Workflow Systems. Information and Software Technology 42(8), pages , Elsevier Science. OMG 1999 Unified Modeling Language Specification, Version 1.3. A.P.Sheth, W. van der Aalst, I.B.Arpinar, 1999 Processes Driving the Networked Economy, IEEE Concurrency, 7(3). R.Motschnig-Pitrik, J.Kaasboll 1999 Part-Whole Relationship Categories and Their Application in Object-Oriented Analysis, IEEE Transactions on Knowledge and Data Engineering, 11(5). RAgarwal, G.Bruno, M.Torchiano 2000 Enterprise modeling using class models and instance models. In

7 Proc. of IEEE 7th Asia-Pacific Software Engineering Conference (APSEC 2000). Singapore. Sun Microsystems Simplified Guide to the Java 2 Platform Enterprise Edition ( D.Barry, T.Stanienda 1998 Solving the Java Object Storage Problem. In IEEE Computer.