Instance modeling – beyond object-oriented modeling
Instance modeling – beyond object-oriented modeling Rakesh Agarwal, Giorgio Bruno, Marco Torchiano Abstract – Most object-oriented methodologies assign to instance models a minor role, using them to depict behavior scenarios and to show examples. For a large number of applications, among which enterprise models represent an outstanding example, traditional class-based models are not sufficient as tools. An enhanced object-oriented modeling methodology has to be devised in order to face the problems that instance models present. The main problem with using instance models to describe large and complex systems, such an enterprise, is the size of the resulting model. Thus the model needs to be organized and managed in an effective way. In addition CASE tools are needed, which provide a valid support to the construction of instance models. In particular the conformance of an instance model to a class model must be guaranteed. The OPJ approach is presented which tries to solve both organization and tool-oriented problems. A case study concerning enterprise modeling is used to show the main features of the proposed approach. The proposed methodology requires a suitable visual modeling environment, which implements the operational concepts that make up the methodology. Keywords – OOA, Operational Models, Enterprise Models, Workflow.
with class models, which describe a system from an abstract point of view. Typically the model of a system consists of a class diagram[1], which describes the classes and their relationships. Such methodologies make use of instance model only to depict behavioral scenarios and to show examples. Many modeling problems, in particular those involving non-exclusively software systems, can be effectively solved by means of instance models. Current methodologies lack a sound support for instance models. Class models should be enriched with operational semantic, which could drive the construction of instance models. Enterprise modeling is a field showing great interest in object-oriented modeling technologies. In particular the adoption of operational modeling[8][12] allows the use of enterprise models to go far beyond descriptive purposes; in fact, such models can play a major role in defining and managing business processes and in mapping business processes to support systems such as ERPs and workflow systems[11]. Usually instance models, representing such systems as enterprises or parts of them, consist of a large number of objects. This number can be much larger that the number of classes of a corresponding class model. Thus a strong organizing principle is needed. Hierarchy is a natural and widely adopted organization policy[9][12]. This paper presents the basic ideas for extending current object-oriented methodologies in order to support the construction of large hierarchical instance models. In particular OPJ (OPerational obJects) is presented, which is an object oriented operational modeling methodology developed by the authors. It is based on the widely accepted object orientation principles but adds two key features: it deals with operational models and has a strong focus on instance models. The remainder of this paper is organized as follows. At first the OPJ[3][4] methodology and the basic concepts underlying this approach are presented, in particular instance models are examined. Then a case study dealing with enterprise models is presented; in particular attention is focused on a simple business processes. After that an operational environment supporting the OPJ methodology is presented. At last a comparison with related work is provided, followed by a summary of the main contributions of this paper.
I. INTRODUCTION object-oriented paradigm has gained a wide range of applications both in software engineering and in related fields. In particular, UML[1] provides a common notation and semantics for object-oriented models and poses itself as a new form of communication. The key step of the object-oriented paradigm is to identify the classes that compose a system. A class describes the common characteristics of a set of similar objects; it identifies a well-defined category of basic blocks that make up the system. An object that conforms to a class is said to be an instance of that class or, as an alternative, the object is said to belong to that class. Class models provide an abstract description of a system; a more concrete perspective can be found in instance models. An instance model depicts a system as a collection of objects together with their associations. Common object-oriented methodologies [1] deal mostly HE
R.Agarwal is with Infosys Technologies, Bhubaneswar, India, Email:
[email protected] G.Bruno and M.Torchiano are with Automatica e Informatica Dept, Politecnico di Torino, Torino, Italy, Email: {bruno,torchiano}@polito.it Published in Proceedings of 3 India, December 21-23, 2000.
rd
II. MODEL BASED PROCESS PJ enriches common object-oriented models with a precise operational semantics. We define the operational
International Conference on Information Technology (CIT 2000). Bhubaneswar,
-1-
Instance modeling – beyond object-oriented modeling semantics in relation to process used to develop a model. We consider a simplified modeling process similar to the waterfall process: different modeling phases produce artifacts that describe the system to be modeled. An operational model contains a possibly abstract description of the system, and in addition a part of it that assumes an operational semantics. Such a part serves as a set of constraint in the following phases. An operational model can define both what operations can be performed to build a derived model and what operations the model, or a derived one, can perform, either when carrying on simulation or actual execution. The basic process adopted in the OPJ approach is made up of three main phases: •= domain modeling, •= system modeling, •= 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. These phases can be performed by different roles: a modeling expert could analyze the problem with problem experts and build a sort of modeling vocabulary, which will be used by problem experts to model an actual system. The OPJ methodology describes a system by means of two modeling artifacts: schema and model. The schema is a collection of class diagrams that describe the domain model of the system. It is based on the objectoriented paradigm. The model is a collection of diagrams that describe the system model. The final phase in the life cycle is model operation; this is a generic term that can assume different meanings depending on the kind of the model. For a production line model it means simulation, for a business process it means enactment, for a software system it means prototyping and execution. In widespread object-oriented modeling methodologies [1] instance models are used only to show examples of data structures or to describe the behavior in particular scenarios. OPJ, instead, makes a large use of instance models to describe systems in their details. Class models provide an abstract description of a system; a more concrete perspective can be found in instance models. An instance model depicts a system as a collection of objects together with their associations. An instance model is made up of objects and associations and is based on a class model. Each object is an instance of a class defined in the class model and each association
-2-
between objects is an instance of a relationship defined in the class model between the corresponding classes. Frequently, instance models are made up of a large number of objects; thus a strong organizing principle is needed. Part-whole hierarchies[10] are a natural and widely adopted organization policy, and indeed they play an important role in human thought process[9]. The hierarchical structure of models should be adopted mainly for model organization purposes. It is not necessarily intended to represent semantic composition or aggregation in the semantic of the system or domain; that is a hierarchical link may or may not represent containment in the real system. An instance model is a valid model[1] for a schema if it conforms to the schema that is if it contains only instances of entities defined in the schema. As a consequence, the construction of hierarchical instance models requires a suitable domain model, which defines the appropriate constraints. The OPJ methodology defines a few simple guidelines, which a domain model must adhere to: •= every class but one (the root class of the model) must be “PartOf” another class, •= the set of “PartOf” links must form a DAG. An alternative approach to the construction of an inheritance-based hierarchy is adopted here: the class hierarchy if founded on PartOf links, i.e. a partonomy[9], is constructed. Not all the elements that make up a partonomy need to represent a real concept of the modeled system, many elements can play only model organization roles. Usually the result of an object-oriented analysis does not produce a class model having a single root. It is viable enough to modify a model in order to obtain conformance with the above rules. The main advantage in adopting a hierarchical structure in models is to give a precise definition of model composition rules. The adoption of the above defined guidelines make it possible both to build the hierarchical structure of the model on sound foundations and to define a personalized model editing environment. The PartOf relationships can effectively help the definition of the components of a container object. The concrete classes, which are part of the container’s class, either directly or indirectly, form a sort of palette the components can be chosen from. A suitable CASE tool can leverage such a property in order to present the user a customized environment for each container class. The system model is not the last step in the model based development process. The system model can be used as the basis for a software application. The behavior of the system is driven by the information contained in the model: it is a data-driven approach. The objects that form the system model can host executable scripts, which define the details of the system behavior.
Instance modeling – beyond object-oriented modeling
III. CASE STUDY
In addition to the classification described above, Figure 1 defines also a PartOf link between the Abstract_Activity class and the ProcessDefinition[11] class. This latter class represents a business process as a whole. A process has a purpose to fulfill which the activities, represented by the object contained in the process, have to be performed described. The PartOf relationship is inherited through the inheritance relationship (IsA) by all kind of activities, thus a particular ProcessDefinition instance can contain any of the activity classes. Corporate policy states that any employee who needs to travel should fill in a standard mission form, which has to be signed and approved by the manager of the department the employee belongs to. The form contains information about the mission such as destination, cost, departure date, itinerary and travel preferences. After the form has been signed, it is sent to the Travel Office, which makes travel reservations. Then it is the task of the mission’s originator to perform the mission; when the employee comes back he/she has to fill in a report field in the mission form. As the last step of the process, the Travel Office will make the final payments and reimbursements.
HIS section describes an enterprise model, containing the travel-approval business process, using the OPJ modeling language. The adopted approach is based on techniques widely used in enterprise modeling[2][4] and workflow systems[11]. The portion of the schema that controls how a business process can be defined, in terms of component activities, is shown in Figure 1. This schema shows a number of inheritance relationships and three associative relationships, i.e. P, Y and N. The base class Abstract_Activity factorizes the properties common to all building blocks that make up the definition of a process. A business activity can be preceded (through relationship P) by a plain activity (Activity). Further an activity that requires a choice (Choice) can precedes any other business activity either by a Y or by an N relationship. Abstract_Activity
ProcessDefinition PartOf
N Y
P
IsA
IsA
Activity
Fill_in
Choice If IsA
IsA
N
Is_manager
IsA Approve
N
P
Auto_Activity
Y
Man_Activity
Approve
Y
Reservations
IsA
Figure 1. The process schema. The schema presents two subclasses of plain activity, which represent particular cases: •= plain activities that must be performed by a human user of the workflow system (Man_Activity), •= activities that can be performed automatically by the workflow enactment system (Auto_Activity). The class representing the activity with a choice has two subclasses too, they are: •= class Approve that represents decision to be taken by a human workflow user, •= class If representing decisions that can be automatically taken by the workflow enactment service. In the classification so far described, only the last four classes, i.e. Auto_Activity, Man_Activity, If and Approve, are concrete classes, being the other three abstract classes used only for classification purposes and to gather common features of subclasses.
Details
Payment
Figure 2. The travel-approval business process. A part of the instance model forms a flowchart representing the travel approval business process; its graphical representation is shown in Figure 2. Such a flow chart consists of a number of activities, represented by the paper sheet being written icon, and two decision points depicted using a yellow diamond with a question mark and a municipal policeman. Starting from the top of Figure 2, we can see the activity (Fill_in) of filling in the form activity preceding (P) a test
-3-
Instance modeling – beyond object-oriented modeling (Is_manager); the result of such test can be taken automatically by the workflow enactment service: it has to decide whether the employee who started the process is the manager of its department. If the test result is false (N), that is the process originator is a common employee, then an approval activity (Approve) must be undertaken. If the approval is positive (Y) then the reservation can be placed (Reservations). Otherwise (N) the mission request needs to be filled in again with modified information. If the result of the Is_manager test is true (Y) then the approval is skipped and the flow directly goes to the reservation placing activity. When the request originator comes back from the mission the details of the mission, such as the total amount of expenses, must be defined (Details). This activity precedes (P) the final payment activity (Payment). Business process work on information entities called business objects (BOs); in fact a process describes the life cycle of a business object. Under such a perspective, business processes and objects should be modeled together, thus an approach similar to the previous one is proposed, which can be used to model business objects. The domain model related to BOs is presented in Figure 3. A BusinessObject, represented by a gem, is made up of attributes (Attribute), which can host values and executable code fragments (Script). Scripts can be used to define the behavior of business objects in the following phases of the model life cycle; as an example they can be used to build a workflow prototype.
Root PartOf
PartOf
BusinessObjects ProcessGroup PartOf
BusinessObject
PartOf
ProcessDefinition
Figure 4: The integration schema. The BusinessObjects and ProcessGroup classes do not represent any well-defined concept in the enterprise domain. They only serve for presentation purposes: when exploring a large model they make the navigation of the information easier. They define preferential navigation paths; as such they hold an operational semantic that cannot be used in the final system but only in the model.
IV. THE OPERATIONAL ENVIRONMENT HE life cycle described, based upon the OPJ methodology, can be implemented in a suitable operational environment. Such environment can be used to carry on all the phases of the model development process: from domain modeling to process operation. The authors have developed a prototypal application that implements the concept of the OPJ methodology, making it available for real-world cases. This section provides an overview of such environment. Two different activities make up the operational model based life cycle: modeling and prototyping. The first activity encompasses the construction of both domain and system models; while the second aims at building a model-based software application.
Attribute PartOf BusinessObject Script PartOf
A. Modeling environment
Figure 3: Business-objects schema.
The first phase in the life cycle produces a domain model and it can adopt well-known object-oriented analysis techniques. While this phase can be carried on using a UML modeling CASE tool, it is better to perform it by means of a tool that supports an integrated view of the different steps of the OPJ methodology. An integrated tool turns out to be very useful in the following phase: the system modeling. In this phase a model of a system is built assembling objects and linking them. The links between objects in the system model are called associations, an association being an instance of a relationship appearing in a schema. Each association has a label referring to the corresponding relationship. In fact a schema defines a modeling paradigm suitable for representing a system located in the problem domain. It sets
The fragments of schema presented so far can be used to produce a single integrated model, but in order to do this the various parts must fit into a unique hierarchy. For this purpose a further integration schema is needed, which completes the domain model, it is shown in Figure 4. In order to have a domain model that allows the construction of a hierarchical instance model, a single root class (Root) must be defined that can contain, directly or indirectly, all the other classes. In fact all the container classes, ProcessGroup, which is a container of business processes, and BusinessObjects, which contains the business objects, are contained (PartOf) in the root class.
-4-
Instance modeling – beyond object-oriented modeling constraints on which building blocks can be used and on how they can be connected to each other. The domain-modeling phase define a schema that defines the rules that will be applied during the system-modeling phase. Thus the schema can be used to customize a suitable system-modeling tool to provide a very specific editing environment. Such an environment enforces the constraints defined by the domain model partonomy; that is, when defining the components of a container the only objects that can be used are instances of concrete classes connected through a PartOf relationship to the container’s class. The classes that are part of a given container class form a palette the user can draw components from. The domain-modeling phase defines the guidelines that must be followed in the system-modeling phase. In fact a schema contains two different semantics levels: •= a conventional semantic, shared with the class diagrams of usual object-oriented methodologies, which depicts an abstract view of instance models, •= an operational semantic, which describes how instance models can be built. The partial partonomy shown in Figure 3 defines a custom modeling environment. When editing the contents of a business object, the toolbar of the modeling tool is customized according to such a figure. In the same way as the system model is operationally based upon the domain model, a model based application can be developed, which is operationally based upon the system model. The most important feature of model based software applications is the coherence between the model and the application itself. In fact every change that is made to the model can be immediately reflected into the system and, as a consequence, the model serves as an always up-to-date documentation. The capability, offered by the OPJ methodology, of developing model based software application can be applied to obtain a fast prototyping approach. The OPJ methodology is model centered; this can easily be understood looking at Figure 5 that depicts the global architecture of the OPJ environment. It is a layered architecture the basic layer at the core of the system is represented by the model repository. The model repository is the storage layer responsible for holding both the domain and the system models. The access to the model is mediated by the successive layer, the OPJ Object Model (OM for short). It is a software module implemented by means of a component technology. It implements an object model[14], which is an object-oriented programming interface to the models. The main OM purpose is to provide a controlled and easy programmable access to the model repository. The repository is a very complex database and as such must be used very carefully to avoid problems: this is under the responsibility of the OM. A well-defined object model proved a very effective way of interacting with a complex structure.
-5-
Model Repository OPJ Object Model
Modeling Environment
Do m ai n Sy s te m Mo d el e r M od e le r W or f lo w Pa r ti c ip a nt
Workflow Server
Web Server
Browser
Figure 5. The global architecture. The capabilities of the OM can be extended in order to integrate external and legacy databases. The OM provides a unified and coherent view of the model and external data. Such feature makes it possible to seamlessly integrate existing data into an OPJ model. As show in Figure 5, the applications that form the OPJ operational environment are built on top of the OM. Both standard and custom applications can be developed, which make use of the features provided by the OM. The main standard application is the modeling environment that allows the definition of both domain models and system models. The elements depicted with a shadow in Figure 5, that is the modeling environment, the OM and the repository, are the standard components of the OPJ supporting environment. While the modeling environment is implemented as a single component in the above-described architecture, it provides two different sets of functions. Two different kind of user can interact with the modeling environment: the domain modeler, in charge of defining the domain model, and the system modeler, that will build one or more hierarchical instance model based on a domain model. Aside the standard applications, several custom applications can be developed, all based upon the OM. As far as the case study is concerned a prototypal workflow management system will be presented. Such application is shown in Figure 5 also a specific application is shown: it is the workflow management system that can be used to enact business processes. In particular a web based architecture for such an application is shown. In this case the user of the application is an employee participating in the workflow.
V. RELATED WORKS importance of hierarchy and aggregation in objectoriented models is proved by a large number of works dealing with the semantics of composition, part-of and partHE
Instance modeling – beyond object-oriented modeling whole relationships. In [5] a survey of part-whole relations and their use in object-oriented methodologies is presented. Another recent work [9] focuses on the importance of aggregation in object-oriented methodologies and stresses the various different meanings that aggregation can have. In our work hierarchy plays an different role: it forms the backbone of any instance model, its main purpose it to make an instance model well structured; in addition in certain cases PartOf relationships can assume a more specific semantics. Harel and Gery present [6] an approach for building executable object-oriented models. They poorly address the instance model problem: the authors attempt to solve the problem forcing object instantiation to be constrained by a cardinality defined at a class level. Such an approach is not affordable for a complex model: if we think of a business process, we cannot say how many activities make up a generic BP nor can we say which relationships exists between each other. Our approach is more focused on instance models and presents effective techniques for building large models. Seiter, Palsberg and Lieberherr present [7] an approach, which supports dynamic evolution of objects. They propose an extension to UML in order to provide a class-level support and an extension to Java, which provides an instance-level support. They identify problems rooted in the class-centered approach of current object-oriented methodologies. They find out that the basic problem with class-based models is the lack of adequate constructs for modeling dynamic behavior. We address a different problem: the construction of large instance models. The two approaches are complementary in extending current object-oriented techniques.
supporting environment for domain-specific modeling practices such as CIMOSA[4]. An software application implementing the modeling environment which supports the OPJ methodology has been developed and is currently being test on complex case studies in order to further validate the basic underlying ideas. The development of model based software applications showed promising results in the field of enterprise information system integration. Which is one of the main research threads the OPJ methodology is currently adopted in. Further study will be devoted to operational issues deriving from the real use of instance tools. Such issues will provide the basis for new extensions to mainstream objectoriented methodologies.
REFERENCES [1] [2] [3] [4]
[5] [6] [7]
VI. CONCLUSIONS HE main feature of common object-oriented methodologies lies in their class-centered approach; but for a large number of applications, among which enterprise models represent an outstanding example, traditional classbased models are not sufficient and instance models are required. The OPJ modeling methodology is based on the sound ground of widely used object-oriented methodologies. It adds a strong emphasis on instance model and adopts an operational approach to provide a well-founded set of guidelines for tools. At first a set of requirements for class models has been defined; the compliance with such requirements enables the construction of a hierarchical instance model. The proposed ideas are the result of several years of research mainly in the area of enterprise modeling. They are currently being implemented and tested in a modeling environment. They proved to be very effective in handling complex models, in particular modeling a number of business processes[4]. The OPJ methodology proved a high rate of flexibility. Our approach served as the basis for implementing a
[8] [9]
[10] [11] [12]
[13]
[14]
-6-
OMG, Unified Modeling Language Specification, Version 1.3, June 1999. G.Bruno, R.Agarwal “Modeling the Enterprise Engineering Environment”, IEEE Transactions on Engineering Management, 44(1), February 1997. R.Agarwal, G.Bruno and M.Torchiano. Developing Operational Models using O3ML, in Computer Science and Informatics, 27(2), Computer Society of India, June 1997. G. Bruno, M. Torchiano, Making CIMOSA Operational: the experience with the PrimeObjects Tool. Computers in Industry 40(2-3), pages 279-291, Elsevier Science, November 1999. A.Artale, E.Franconi, N.Guarino, L.Pazzi, “Part-Whole Relations in Object-Centered Systems: An Overview” in Data and Knowledge Engineering (20), October 1996. D.Harel, E.Gery, "Executable Object Modeling with Statecharts", in IEEE Computer 30(7), July 1997. L.M.Seiter, J.Palsberg, K.J.Lieberherr, “Evolution of Object Behavior Using Context Relations”, IEEE Transactions on Software Engineering, 24(1), January 1998. P.Zave, “The operational versus the conventional approach to software development”, in Communications of the ACM, 27(2), February 1984. Motschnig-Pitrik R., Kaasboll J. “Part-Whole Relationship Categories and Their Application in Object-Oriented Analysis”, IEEE Transactions on Knowledge and Data Engineering, 11(5), September/October 1999. Winston, Morton, R.Chaffin, D.Herrmann, "A Taxonomy of Part-Whole Relations," Cognitive Science, 11, 1987. Hollingsworth D. “The Workflow Reference Model” The Workflow Management Coalition document TC00-1003, November 1994. R. Agarwal,G. Bruno and M. Torchiano. Object-Oriented architectural support for developing complex systems” in Proc. of IEEE 23rd Annual Int.Computer Software and Applications Conf. (COMPSAC’99), pages 259-264, Phoenix, AZ, USA, October 27-29, 1999. R. Agarwal,G. Bruno and M. Torchiano. Modeling Complex Systems: Class models and instance models. in Proc. of International Conference on Information Technology (CIT’99), Bhubaneswar, India, December 20-22, 1999. F.Manola. “Technologies for a Web Object Model” in IEEE Internet Computing (3)1, January/February 1999.
