PROCESS ENABLED INFORMATION SYSTEMS Giorgio Bruno Marco Torchiano Politecnico di Torino - Dip. Automatica e Informatica C.so Duca degli Abuzzi, 24, I-10129 Torino, Italy Fax: +39 011 564 7099 Phone: +39 011 564 7003 Phone: +39 011 564 7081 Email:
[email protected] Email:
[email protected] Abstract A major direction in information technology is represented by the object-oriented approach and enterprise integration. While current OO methodologies fit well for software design purposes, there are not so widely adopted for enterprise modeling. Extending the OO approach to deal with operational instance models is the key factor to build complete and integrated enterprise models including the software information system. The modeling approach adopted to deliver such integrated models focuses on process enabled information systems, in which processes play the role of glue for all other parts of the enterprise’s model. Workflow systems can be built on top of such models giving rise to extremely flexible model based architecture. Keywords: Workflow, Business Processes, Enterprise Models, OO Modeling.
1. Introduction
2. Overview of OPJ
The 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. Enterprise modeling is a field showing great interest in object-oriented modeling technologies. In particular the adoption of operational modeling[7] 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[5][6]. This paper presents an application of the OPJ (OPerational obJects) methodology, which extends common object-oriented methodologies in order to support the construction of operational instance models[3]. The OPJ methodology can be adopted to develop integrated enterprise models. The remainder of this paper is organized as follows: at first a brief overview of the OPJ methodology is provided, then the process enabled information system approach is described, after that its application to a workflow system is described.
OPJ enriches common object-oriented models with a precise operational semantics. An operational model contains a possibly abstract description of the system, and in addition an operational part which serves as a set of constraints in the following modeling phases. An operational model can define both what operations can be performed to build a derived model and what operations the derived model can perform. Such basic process 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 objectoriented 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. Therefore a modeling expert could analyze the problem together 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: schemas and 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. A model is a collection of diagrams that describe the system model. 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. For a production line model it means simulation, for a business process it means enactment, for a software system it means prototyping and execution. Most object-oriented methodologies are classcentered: in fact they are structured around class-relationship diagrams. Different kinds of models are instance models: they are made up of objects. 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.
3. Purchasing processes The hype OO modeling techniques recently enjoyed caused their adoption to model nonsoftware system like the enterprise environment. In such field models can be used as documentation and as communication and teaching tool. A meaningful example is a process the employees of an office have to follow in order to perform a task. The process needs to be documented for quality assurance purposes; it has to be communicated to management to enable optimization; finally, new employees must be taught the process in order to perform it. A suitable model could be the core of all these activities; in fact experience [4] has
shown the benefits of models as tools for process analysis, optimization, test and management. Enterprise models can be used to define and manage business processes and to map them to support systems such as workflow systems [4].
3.1. Processes and data One main problem in today’s information systems is the integration of the different features they need to manage. Conventional ERP have a strong focus on data and processes have been added in a successive phase, resulting in a lack of flexibility; the last trend in ERP systems is to add a degree of freedom, usually by means of scripting languages, but their essentially monolithic structure is a hurdle difficult to overcome. A different generation of enterprise systems must be developed: the Process Enabled Information Systems (PEIS). Such kind of system may very well be developed using the operational model based approach represented by the OPJ methodology. The key concepts of PEIS are processes and business objects. a business-object is an aggregated data that can be manipulated by the information system. a process describes the life cycle of a business object The proposed approach integrates various aspects of an enterprise information system as shown in the simplified schema shown in Figure 1. Process
BusinessObject Produces
PartOf
Activity
CanStart
WFRole
CanBePerformedBy
Login
Plays
Figure 1: Simplified integrated schema.
The Process[8] class represents business processes described by means of activities (Activity); a business process is linked to the BusinessObject class through the relationships Produces, meaning that a business object is
produced as described by the process. Process and business objects can serve for simple documentation purposes but they are effectively useful when they can form the basis for a model based information system. Thus the interaction with users, represented by class Login, is required. User capabilities are defined by the roles (WFRole) they play: a role can start a given set of processes and can be required to perform certain activities. Start
New_Supplier P
End
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. Purchase Requisition
GoodsAccepted
GoodsReceived SupplierInvoice InvoiceReceived
PaymentConfirmed
P
InvoiceEntered
PurchaseOrder
PaymentPrepared
Figure 2: Supplier process. GoodsChecked
An example of a business object is the one that describes a supplier of some kind of goods. It is characterized by such fields as: name, address, performance statistics, and discount policies. The simplest life cycle for a supplier business object is shown in Figure 2. The supplier process allows the insertion of a new supplier’s information into the suppliers’ database. The process is made up of just one activity, in addition to the Start and End blocks.
3.2. Purchase processes The steps required to purchase goods in a large enterprise can be very complex; many kind of information are required to fulfill this task: the relative business objects are shown in Figure 3. PurchaseRequisition Collects
RelatedTo SupplierDelivery
PurchaseOrder
Supplier
To
InReplyTo SupplierInvoice
Figure 3: Purchasing business objects.
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. Each business object has got its own life cycle, described by means of a process. The relationships among business objects are reflected into interactions among the related processes, as shown in Figure 4. The PurchaseRequisition process describes the
SupplierDelivery
Figure 4: Purchasing processes.
When the supplier deliveries the requested goods the SupplierDelivery process notifies the PurchaseOrder process which 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. When the process is started, the first activity, which is automatically carried out by the system, is the collection of similar requests that can be gathered together in a single purchase order. Then human intervention is needed to select the appropriate supplier, the resulting purchase order can then be sent to the supplier, as an example by means of some business-tobusiness electronic commerce system. After the order has been sent two parallel and autonomous paths are activated. The leftmost one manages the supplier invoices while the
Start
CollectRequests P
SelectSupplier
P P
InvoiceEntered
SendOrder
GoodsChecked
T
T P
InvoiceReceived
ReceiveInvoice
G
B1
P
ReceiveGoods P
P PaymentConfirmed
GoodsReceived
G P CollectAcceptances
CollectConfirmations
T
GoodsAccepted
T
J1 P
P P
End
PreparePayment P
PaymentPrepared
G
Figure 5: Purchase order process.
rightmost one handles the goods. Whenever an input event (InvoiceEntered) notifies the arrival of an invoice, a formal reception of the invoice is required (ReceiveInvoice) then the notification can be forwarded, by means of an output event (InvoiceReceived), to all related PurchaseRequisition processes, whose replies will be received through an input event (PaymentConfirmed) and collected (CollectConfirmations). A similar procedure is described in the other path, the rightmost one in Figure 5, to deal with the goods.
4. A workflow prototype A suitable modeling environment has been developed, which supports the OPJ methodology. Such an environment can be used to carry out all the phases of the model development process: from domain modeling to process operation. In particular model based prototypes can be developed. The great advantages of model based software applications are that every change in the model can be immediately reflected into the system and, as a consequence, the model serves as an always up-to-date documentation. We will present a brief description of the OPJ environment that enables the development of
models and prototypes. The OPJ environment comprises everything described so far and any prototype or simulator that can be based upon an OPJ model. Model Repository OPJ Object Model
Modeling Environment
'RPDLQ 6\VWHP 0RGHOHU 0RGHOHU
Workflow Server
Web Server
:RUIORZ Browser 3DUWLFLSDQW Figure 6. The global architecture.
Figure 6 shows the model centered architecture of the OPJ environment. It is a layered architecture the basic layer is represented by the model repository that contains both domain and system models. Access to the model is made possible through a software component that implements an object model: it is an object-oriented programming interface to the models. On top of this layer
many different applications can be built. The main standard application is the modeling environment (or modeler, for short) that allows the definition of domain models and system models. Two different kinds of users can interact with the modeler: the domain modeler, in charge of defining the domain model, and the system modeler, that will build one or more hierarchical instance models based on a domain model. In Figure 6, also a specific application is shown: it is the workflow enactment system[8] 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. The enactment system exhibits very generic functions such as starting a process, advancing a process to the next activity and listing pending activities for a given user. The specific functionalities and behavior of each process activity or business object are defined in the model. As an example the activities can contain the operational details needed to select a specific user required to perform the activity itself. Or, in the case of automatic activities, they can contain the code that the workflow enactment system has to execute; in Figure 5 the SendOrder activity contains the code to format and send an email to the selected supplier with the details of the order. Business-objects always contain presentationrelated operational information. The PurchaseOrder business object needs several presentation features. An example of purchase order is shown in Figure 7.
Figure 7: Purchase order presentation.
The workflow system can contain all the
information required to complete a process or simple summary information which refers to external data and tools. Thus it is possible to model legacy data and seamlessly integrate it into the workflow system.
5. Conclusions The OPJ modeling methodology has roots in the sound ground of widely used objectoriented methodologies. It adds a strong emphasis on instance models, which provide a tool to describe wide integrated enterprise models. PEIS, which enables the implementation of model based workflow systems, represents an innovative approach to enterprise models. The proposed ideas come from modeling experiences with FIAT Auto[4] leveraging the CIMOSA[5] methodology. Further work is being devoted to model and enact additional real world processes.
6. References [1] OMG, 1999. Unified Modeling Language Specification, Version 1.3. [2] Bruno, G. and Agarwal, R., 1997, Modeling the Enterprise Engineering Environment. IEEE Transactions on Engineering Management, 44(1). [3] Agarwal, R., Bruno, G. and Torchiano, M.,1999, Modeling Complex Systems: Class models and instance models. In: Proc. Int. Conf. on Information Technology (CIT’99). [4] Bruno, G., Reyneri, C. and Torchiano, M., 1997.Enterprise Integration: operational models of business processes and workflow systems. In: Proc. of ICEIMT'97. [5] Bruno, G. and Torchiano, M. 1999. Making CIMOSA Operational: the experience with the PrimeObjects Tool. Computers in Industry 40(2-3), 279-291. [6] Agarwal, R., Bruno, G. and Torchiano, M., 1998. Modeling of Distributed Workflow Systems. In: Proc. of Int. Conf. on Information Technology (CIT’98). [7] Zave, P. 1984. The operational versus the conventional approach to software development. Communications of the ACM, 27(2). [8] Hollingsworth, D., 1994. The Workflow Reference Model. The Workflow Management Coalition document TC00-1003.
