Constructing an enterprise viewpoint: evaluation of four business modelling techniques

Constructing an enterprise viewpoint: evaluation of four business modelling techniques

Computer Methods and Programs in Biomedicine 55 (1997) 11 – 30 Constructing an enterprise viewpoint: evaluation of four business modelling techniques...

459KB Sizes 0 Downloads 6 Views

Computer Methods and Programs in Biomedicine 55 (1997) 11 – 30

Constructing an enterprise viewpoint: evaluation of four business modelling techniques Pieter J. Toussaint a,*, Albert R. Bakker a, Luuk P.J. Groenewegen b b

a HISCOM b6, Schipholweg 97, 2316 XA, Leiden, The Netherlands Department of Computer Science, Leiden Uni6ersity, PO Box 9512, 2300 RA, Leiden, The Netherlands

Received 10 March 1997; received in revised form 20 August 1997; accepted 22 August 1997

Abstract Business process modelling is presented as an important first step in the process of designing a distributed system by integrating pre-existing components. The elements describing a business process are derived from the ODP-enterprise viewpoint language. One of the viewpoints distinguished in the Open Distributed Processing standard is the enterprise viewpoint. This viewpoint describes the organizational context in which the distributed system to be constructed will be used. In this paper we will review four business modelling techniques and their suitability for expressing the enterprise viewpoint is evaluated. © 1998 Elsevier Science Ireland Ltd. Keywords: ODP; Business process modelling; SOCCA; OOSE; Zachman Framework; Petri Nets

1. Introduction The distributed computing paradigm comes to age. After the client/server revolution (decomposing systems into two or three tier systems) we now enter the distributed objects era [1,2]. As is noted by Mowbray et al. [2] system development slowly changes from custom programming to systems integration from pre-existing components. Two major problems to be solved in the component integration approach are: how to pick the right

* Corresponding author.

components, and how to integrate them? There are several perspectives from which these questions can be addressed. The Open Distributed Processing standards initiative (ODP, [3–6]) defines five perspectives, called viewpoints. ODP has as its main objective: ‘…to enable the construction of distributed systems in a multi-vendor environment through the provision of a general architectural framework that such systems must conform to’ [7]. This architectural framework offers, amongst other things [3]: “ a division of an ODP system specification into viewpoints, in order to simplify the description of complex systems;

0169-2607/98/$17.00 © 1998 Elsevier Science Ireland Ltd. All rights reserved. PII S 0 1 6 9 - 2 6 0 7 ( 9 7 ) 0 0 0 5 0 - 3

12 “

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

a set of general concepts for the expression of those viewpoint specifications; The five viewpoints from which the questions regarding the right components and the way to integrate them can be addressed, are: “ the enterprise viewpoint which is concerned with the business environment in which the system has to operate; “ the information viewpoint which is concerned with the information to be stored and processed by the system; “ the computational viewpoint which is concerned with a description of the system as a set of objects that interact at interfaces; “ the engineering viewpoint which is concerned with the mechanisms supporting system distribution; “ the technology viewpoint which is concerned with the detail of components from which the distributed system is constructed. Each of these viewpoints has its own viewpoint language. This viewpoint language consists of some concepts and structuring rules. These viewpoint languages are abstract specifications of the content of each viewpoint. Several formal description techniques can be used for specifying an instance of such a viewpoint, however, ODP does not prescribe any formal description techniques for modelling the viewpoints. The issue of systems or component integration is dealt with in the literature from the different perspectives. However, we observe a major difference in the formal description techniques available for describing the different viewpoints. Especially, for the enterprise viewpoint the availability of formal description techniques is meagre [7]. In our view this is a major problem when addressing the questions mentioned above. Both finding the right components and the best way to integrate them, should be based on a thorough analysis of the business process to be supported by these components. That is; components should be derived from the tasks identified making up the business process, and relations between components should be derived from relations between these tasks. How well components are integrated can only be assessed within the context of the business process(es) supported by those components.

So, if we want to transform the industry of developing information systems for health care from a custom programming based industry into an integration of pre-existing components based industry, we must have the means for modelling the business processes to be supported by the systems. How do we model a business process? The definition of the enterprise language can be taken as a definition of the phrase ‘organizational structure’. Below we list the main elements put forward by ODP to be included in the enterprise language [5]1.

1.1. Concepts Agent: An object fulfilling an one or more agent roles. Agent Role: A service offered by the agent to its environment (other agents). This service is a set of actions taken by the agent, possibly involving the use of one or more resources. Artefact: An object fulfilling an artefact role. This is a special type of agent, namely, an agent that does not use roles from other agents. It only offers roles. Artefact Role: A role involving use of resources, but not able to initiate actions with respect to those resources. A service offered by an artefact. Resource: An object to be used in the execution of one or more roles2.

1.2. Structuring rules 3 Obligation: A prescription that a particular behavior is required. An obligation is fulfilled by the occurrence of the prescribed behavior. We understand obligations to define the static co-operation 1 We have left out administrator, community, BX\ -federation and performative action. The administrator is a special type of agent, a performative action is a special type of role and both community and BX\ -federation are constructs for grouping agents and resources. For our purposes these refinements could be left out. Furthermore, we have used more specific definitions than those provided in the ODP document. This is needed for our evaluation of several modeling techniques below. 2 The definition in [3] defines resource with reference to an administrator. 3 We have taken obligations and policies as the most important types of structuring rules. Definitions are taken from [2].

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

pattern between agents. An obligation states which roles are offered to which other agents. Policy: A set of rules related to a particular purpose. A rule can be expressed as an obligation, a permission or a prohibition. We understand policies to define the behaviour restriction patterns between agents. The execution of an obligation can be restricted by a policy to certain states of the process in which the agents involved in the obligation participate. So, an important aspect of the organisational structure to be mirrored in the distributed system architecture is a business process, described as a set of agents co-operating by means of using each others services (as specified in the static co-operation pattern). The behaviors of each of the agents can be restricted as a result of the co-operation (as specified in the dynamic co-operation pattern). Now back to our second premise: the means to express the organizational structure. These elements can be expressed in an enterprise model. We will assume that an Enterprise Viewpoint is expressed as a business process model. That is; the enterprise viewpoint defines the business process(es) that will be supported by the distributed system to be constructed. As noted above, ODP does not prescribe any formal description technique for a viewpoint. In this paper we will review four techniques for modelling business processes. These four were picked because they are all explicitly advocated as suited for enterprise modelling, and because they all focus on a specific modeling aspect, where we distinguish between: a functional, a static and a dynamical aspect [17]. The four methodologies are: “ SOCCA: this methodology described in [8,9] is an extension of OMT. It introduces a more elaborated technique for expressing the dynamic model, and pays special attention to the co-ordination of dynamic behavior. Therefore, it covers both the static and dynamic aspect in depth. “ OOSE: described in [10,11]. Introduces a more functional oriented approach in a OO-based methodology. So, strong in both static and functional aspect. It is closely related to the approach elaborated in the Unified Modelling Language [12].



Zachman Framework: this methodology described in [13,14] focuses on the functional model and offers the information matrix as its main construct. The model is expressed as a set of relations between functions and data sets. “ Petri Nets: described in [15,16]. Main focus on dynamic aspect and on the process and the steps or activities out of which it is constructed. At forehand, we should note that our evaluation is not a formal exercise. Only the Petri Net approach has a thorough mathematical foundation. The others are not formalized. This makes it impossible to assess the expressive power of each of the methodologies formally. However, if that would have been possible the outcome would probably be that all elements needed for describing a business process, can be modelled in each of the methodologies. Much more important than the formal expressiveness is the ease of use because of the specific focus of a methodology. As we will see, the different methodologies focus on different elements of the business process. This often results in less clear specifications of the other elements. So, we will investigate which elements are highlighted, and to what extent other elements are blurred. The methodologies reviewed are evaluated by working out a small example. This example is the shared care for diabetic patients by the General Practitioner and the internist4. The process can be described as follows. A patient makes an appointment with the general practitioner. Reason for the consult can be a physical problem (patient can be diagnosed or undiagnosed as suffering from diabetes) or the need to monitor the patient’s physical condition (in this case the patient was earlier diagnosed as suffering from diabetes). In the case of an undiagnosed patient consulting the General Practitioner, a second opinion can be asked (often by means of a telephone call) from the Internist on the possible diagnosis or the treatment plan. This example is a strongly simplified version of the real process. In the real process of providing shared care for diabetic patients, more health care professionals are involved and their interactions 4 This work was partly funded by the European Union, as part of the Health Telematics Project SYNAPSES (HC 1046).


P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

are more complicated. In order not blur our discussion with too much details, we have restricted our example to the interaction between General Practitioner and Internist in arriving at a diagnosis and planning a treatment for a patient consulting the General Practitioner. This small example are enables us to cover all concepts and structuring rules listed above. This small example was derived from a more elaborated case study. Below we indicate which enterprise language elements are covered in our small example.

1.3. Concepts Agents: We distinguish three agents; Patient, General Practitioner (GP) and Internist. Agent Roles: there are several roles associated with each agent: Patient: make appointment, visit GP; GP: consult, diagnose, plan treatment; Internist: consult, diagnose, plan treatment; Artefact: We will distinguish one artefact, namely Case. A Case manages all information related to a specific patient with a specific problem. This element represents the distributed system to be constructed. Artefact Roles: Create case, delete case, open case, close case, associate (or update) diagnosis with case, associate (or update) treatment plan with case, indicate when treatment has started Resources: We distinguish between information resources and physical resources. Physical resources will not be considered in our example. As information resources we take the elements specified in the Diabcare Dataset [19].

1.4. Structuring rules Obligations: The following obligations are distinguished: 1. A case can only be created and deleted by the GP. 2. The GP must enable a Patient to make an appointment and make a visit. In other words, the GP must perform consult on request by the Patient 3. The Internist must perform diagnose and plan treatment on request by the GP

1.5. Policies 1. If a case is opened by a health care provider it cannot be opened again until it is closed. 2. A case must be diagnosed before a treatment can be planned (note however, that a treatment can be adjusted because the effects are not satisfactory, without changing the diagnosis) In this paper we will model the example using each of the four modelling techniques mentioned above. In Section 2 we review SOCCA. In Section 3 we review OOSE. In Section 4 we review the Zachman Framework. Finally, in Section 5, we review an approach based on Petri Nets. In Section 6 we present and evaluate the suitability of each of the modeling techniques reviewed.

2. Using SOCCA for modelling the enterprise viewpoint

2.1. SOCCA SOCCA is a modelling technique based on OMT as described by Rumbaugh et al. [17]. An OMT model has three components: an object model (static view), a dynamical model (dynamic view) and a functional model (functional view). The main extension of OMT offered by SOCCA is with regard to the dynamic view. SOCCA offers a formalism based on State Transition Diagrams (STD’s), for modelling class behaviors and the interactions between these behaviors. Two recent publications describing SOCCA are [8] and [9]. In what follows we will model our example using SOCCA. In deriving the model, the following steps are taken: “ derive class diagram of the domain and define uses-relations between classes; “ for each class model the external behavior is described by ordering the calls to exported operations in a STD; “ for each exported operation model the internal behavior is described by ordering imported or private operations invoked in the execution of this operation in a STD;

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30


Fig. 1. Class diagram of business process. “

co-ordination between internal behaviors associated with a class is modelled by imposing restrictions on the internal behaviors, managed by the external behavior.



2.2. Enterprise Language concepts expressed using SOCCA constructs In step 1 we derive a class diagram. The Agents and the Artefact are modelled as classes. Their roles are modelled as operations. Obligations between agents correspond to the uses-relations distinguished in Fig. 1. Finally, the resources (elements of the Diabcare data set [19]) are modelled as attributes (not explicitly indicated) of the class Case. The uses-relations distinguished in Fig. 1 should be read ‘in the direction of the arrow’. Therefore, the arrow between Patient and GP reads as: Patient uses from the GP the operations in uses1. Note that an agent can also use operations exported by himself. This models the observation that for example diagnose from the Internist can be invoked by the GP but also by the Internist from Internist.consult. The operations contained in each of the uses-relations are: uses1: uses2:

GP.consult GP.diagnose GP.plan – treatment



Internist.consult Internist.diagnose Internist.plan – treatment Case.create Case.delete Case.close Case.associate – diagnosis Case.associate – therapy Case.close Case.associate – diagnosis Case.associate – therapy Internist.diagnose Internist.plan – treatment

These uses-relations model the obligations distinguished in our example, but more than that. The extra’s modelled thus, correspond to obligation-like constraints that have been chosen for this model. As an example: the Internist can also perform diagnose and plan – treatment on request of himself, as from the consult task. This type of reciprocal obligation was not listed as an obligation in the introduction. We will illustrate one of the policies distinguished in the introduction using behavior co-ordination constructs from SOCCA. We will show how to model the restriction that a Case can only


P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

Fig. 2. Internal behavior of GP.consult modelled as a State Transition Diagram. Transitions labelled ‘call – …’ model calls to operations exported by other classes. The transitions labelled ‘act – consult’ models the act of starting the behavior.

be opened (for updating) by only one health care provider at a time. First we will give the state diagrams for the internal behaviors of GP.consult and Internist.consult. Then we will give the external behavior of the Artefact Case as a state diagram. Finally, we will show how the SOCCA constructs of sub-process and trap can be used to restrict both internal behaviors in the required way. The left side in Fig. 2 models the activities of creating/deleting and opening/closing cases. When a case is opened either a diagnosing activity or a planning treatment activity is started. Note that the Internist does not have the possibility of creating or deleting a case (Fig. 3). From Fig. 4 we can see that during its lifetime, a number of iterative paths are possible through the state diagram. When a case is diagnosed, it can be closed because no therapy is needed or available. The case returns to its state closed, and can be reopened for adjusting the diagnosis in a later stadium. When a therapy is provided a case is closed. However, it does not have to be deleted (signifying that it will never be reopened again). It will be reopened for assessing the effects of a therapy. If these effects are not satisfying, a new therapy can be proposed. This is modelled by means of the arrow going from the state opened to

the state therapy – associated labelled with associate – therapy. The external behaviour modelled in Fig. 4 will now be used as manager of the behaviors modelled in Figs. 2 and 3. First we will divide the behavior for GP.consult into three sub-behaviors. These are given below (Fig. 5). The three sub-behaviours are respectively: create a case, open or delete a case, and close a case. The shaded boxes encapsulate so-called traps. These are states that can not be left unless explicit permission is given by the manager, which is the class Case. The sub-behaviors of Internist.consult are given below (Fig. 6). The Internist cannot create or delete a Case in our example, so the sub-behaviors are slightly different from those for the General Practitioner. Fig. 7 presents the external behavior of Case as the manager of the sub-behaviors given above. Each state is labelled with the name of the sub-behavior permitted, and each arrow is labelled with the name of a trap. As can be seen, only one health care provider at a time can open a Case. If it is opened all other health care providers willing to open that Case will be restricted to the sub-behavior open a Case, waiting in the trap wait till open started.

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30


Fig. 3. Internal behavior for Internist.consult. Note that the Internist does not have the possibility of creating or deleting a Case.

3. Using OOSE for modelling the Enterprise Viewpoint

3.1. OOSE The modelling technique reviewed in this section is the one developed by Ivar Jacobson. The approach is described in [10,11]. In [10] the focus is on the application of the method to software engineering. In [11], Jacobson et al. argue for the applicability of the method to business modelling. Comparing Jacobson’s method (called OOSE — Object Oriented Software Engineering) with OMT, the major difference is the role of the functional model. Where in OMT the functional model is a separate model, not very well integrated with the object model and the dynamical model, OOSE takes the functional model as its starting point. The steps taken in making an OOSE model of a business process, are: “ derive use cases, describing the main functions the business process offers its environment; “ for each use case objects are identified that implement the use case; “ the way these objects interact in the execution of the use case is modelled by means of an Object Interaction Diagram (OID); “ complicated objects can be described by means of a State Diagram. So,theusecaseisacentral concept in this approach to business modelling. In [11] it is defined as:

‘‘A use case is a sequence of transactions in a system whose task is to yield a result of measurable value to an individual actor of the system.’’ An actor represents a role that someone or something in the environment can play in relation to the business. Therefore, actors are not restricted to human users. An information system receiving information from the business, but not considered to be part of the business, is also modelled as an actor. For each use case an object model is constructed. OOSE uses another object modelling technique thaen OMT. The most important difference is the distinction of three types of objects: interface objects, control objects and entity objects. The definitions for each type are: “ an interface object models a task (set of operations) that involves communication with the business process environment (one or more of the actors); “ a control object also models a task, but this task does not involve communication with one or more of the actors; “ an entity object represents occurrences of such products and things that are handled in the business.

3.2. Enterprise Language concepts expressed using OOSE constructs The first step in the OOSE modelling effort is the construction of the use cases. Fig. 8 provides the use cases for our example case.


P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

Fig. 4. External behavior of artefact Case. This State Transition Diagram models the ‘life-cycle’ of a Case.

Therefore, one of the Agents (Patient) is modelled here as an actor interacting with the business process. The next step will be the refinement of the use case perform GP consult. This refinement is modelled as an object model. This model is given below using the OOSE modelling conventions (Fig. 9). The role consult of the General Practitioner is modelled as an interface object. It takes care of all communication with the patient involved in conducting the consult task. This models the first obligation distinguished in the introduction. GP.consult uses other roles from the General Practitioner and

roles from the other agent, the Internist. These roles are modelled as control objects: GP.diagnose, GP. plan treatment, Internist.diagnose, Internist.plan treatment. The relations between GP.consult and Internist roles model the second obligation. The first entity object is the artefact Case, as described in Section 1. The resources (the Diabcare data elements) are also modelled as an entity object. Finally, we will model the policies distinguished in Section 1. This is done by means of an Object Interaction Diagram for the use case perform GP consult. This OID is given below.

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30


Fig. 5. Sub-behaviors for GP.consult modelling the different actions to be performed with a Case in the process of performing a consult.

Fig. 6. Sub-behaviors for Internist.consult when managed by Case.


P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

Fig. 7. The allowed sub-behaviors as determined by the life-cycle of the class Case.

Obligation 1, stating that a case can only be created and deleted by the GP, is modelled by only including create/delete actions in the refinement of GP.consult. Policy 1 is modelled by checking whether the Case has been already opened. Only if this is not the case, processing can take place. Policy 2 is modelled by means of the flow of control of the algorithm given in the OID.

4. Using the Zachman Framework for modelling the Enterprise Viewpoint

4.1. The Zachman Framework The Zachman framework was first described in a paper ‘A Framework for Information Systems Architecture’ [13]. It presents a methodology for

Fig. 8. Use cases for the process of shared care for diabetic patients.

constructing an Information System Architecture working from the business perspective down to the technological (implementation) perspective. Within each perspective three aspects can be distinguished: a Data aspect (which we referred to earlier as the static view), a Process aspect (which we referred to earlier as the functional view), and a Technology aspect. This latter aspect was not considered by us. In fact, Cook goes even further and argues for the irrelevance of this aspect at the level of business modelling [14]. The levels to be passed along the way are represented in Fig. 10 (taken from [14]): We will not go into the details of each of these levels. In this section we will restrict ourselves to the parts that are shaded in Fig. 10. These comprise of what Cook [14] calls the business view. As we will see, they provide a business model that is strongly functionally biased. The methodology is in fact a functional decomposition approach, where the decomposition process (leading to the Process description) is guided by the Data model. The functional (or process) model is finished when there is a one-to-one relationship between data elements in the data model and functions in the functional model, where the relationship indicates that the data element is created by that specific function. Relations between functions can be established because one function needs to read or update data elements created by the other function. The so-called CRUD-matrix (Create Read Update Delete) is used for indicating relations between functions and data elements.

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30


Fig. 9. Object model for the use case perform GP consult. For the sake of clarity we have left out communication relations between the control objects and the entity object Case. All control objects communicate with the object Case.

Fig. 10. Levels distinguished in the framework described by Zachman.




P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

The steps in deriving the business model are: Ball park view: (1) Start with defining the enterprise business functions; (2) Brainstorm potential data classes for each enterprise business function; (3) Look for similarities and generalize the potential data classes into first-pass global data classes; (4) Use data modelling techniques to refine the global data classes; Business owner’s view: (5) Identify per enterprise business function which entities are created; (6) For each global data class of which not all entities are covered, do either: – move entity covered to other global data class that is (more widely) covered; – create a new global data class for the covered entity; – decide that entity is not covered by the enterprise business function; (7) Split enterprise business function into as much functions as global data classes covered. This will result in a one-to-one mapping between enterprise business functions and global data classes; (8) For each entity in a global data class a primitive business function must be defined. This step results in a more detailed description of Information Systems within the business views (both ball park and business owner’s view). Each information systems is described by means of a CRUD-matrix, indicating for each of the primitive business functions contained in that information system which data elements are related (either created, read, updated or deleted by that function).

4.2. Enterprise Language concepts expressed using constructs from the Zachman Framework The Zachman Framework focuses on the functions and data sets making up the business process. Therefore, agents are not modelled. One could interpret an enterprise function as an agent role, but this is not the way they are presented in [14].

However, for the sake of our investigation we will interpret the agent roles identified in Section 1 as enterprise functions in the Zachman sense. This gives us as a result of step 1 in the ball park view the following set of enterprise functions (the labels fi are used in the list below) f1 f2 f3 f4 f5 f6 f7 f8

Make appointment Visit GP GP consult GP diagnose GP plan treatment Internist consult Internist diagnose Internist plan treatment

The global data classes, that are the result of step 3, are taken from the Diabcare data set [19]. This data set is the result of standardization effort at a European level, aimed at defining the minimal data set for monitoring the condition of diabetic patients. The classes listed below are conformant with the grouping applied in the Diabcare data set. s1 s2 s3 s4 s5 s6 s7 s8 s9

Basic patient data Reasons for consultation/admission Pregnancies Risk factors (smoking, alcohol consumption) Self-monitoring Symptoms within the last 12 months Examinations Diabetes treatment Additional treatment (for complications)

Table 1 indicates for each of the enterprise functions which (parts of which) data sets are created. Lets first look at the entities created by the enterprise business function make appointment. This function creates seven out of the 13 entities included in the global data class basic patient data (s1) as defined in the Diabcare Dataset [19]. When we take a close look at the global data class, we see that it contains both administrative data and diabetes related data. We will place all entities created by make appointment into a separate class administrative patient data.

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30 Table 1 Creation matrix

s1 s2 s3 s4 s5 s6 s7 s8 s9
















The function visit GP creates (parts of) the same sets as make appointment. We decide to fuse both functions into one new function: go to GP. The functions GP consult and Internist consult both create a number of data sets. This reflects the fact that these functions are complicated. First we observe that the global data class pregnancies (s3) is completely covered. These entities either have been registered in the past, when delivery took place, or they are registered now when the patient is being admitted for delivery or relates past occurrences. We will split off a new enterprise business function register pregnancies, that covers the global data class Pregnancies in that it creates all its entities. The global data class Risk factors (s4) is also covered by GP consult and Internist consult. A new enterprise business function is split off: register risk factors. The global data classes: Self-monitoring (s5), Symptoms (s6), and Examinations (s7), are all covered by Examine. According to the Zachman approach we should split off three enterprise business functions, one per global data class. The enterprise functions GP diagnose and Internist diagnose create two entities within the global data class Basic patient Data. As remarked above, this data class is reduced in size by moving the seven entities created by make appointment. Both type of diabetes and year of diagnosis are moved to a new global data class diagnosis information. The enterprise business functions GP plan treatment and Internist plan treatment create a


number of entities in the global data classes diabetes treatment (s8) and additional treatment (s9). We will derive four new enterprise business functions: GP/Internist plan diabetes treatment and GP/Internist plan additional treatment. We cannot solve the problem that the functions consult, diagnose and plan treatment for the GP and the Internist overlap. This reflects the fact that both agents can co-operate in these activities in a non predetermined way. It depends on the actual situation who will create which data set. In fact the Zachman approach does not offer the means for distinguishing between different agents, and therefore it is appropriate to remove the distinction from the roles. Therefore, we will merge GP consult and Internist consult, etc. We end up with C-matrix in Table 2. We have: f1 f2 f3 f4 f5 f6 f7 f8 f9

Go to GP Register pregnancy Register risk factors Check self monitoring Check symptoms Examine Diagnose Plan diabetes treatment Plan additional treatment

And the new data sets are: s1 Administrative patient data and reasons for consultation/admission s2 Pregnancies s3 Risk factors (smoking, alcohol consumption) s4 Self-monitoring s5 Symptoms within the last 12 months s6 Examinations s7 Diagnosis information s8 Diabetes treatment s9 Additional treatment (for complications) All obligations listed in Section 1 are given in terms of agents. Although these agents are not explicitly modelled, it is not possible to model the obligations between them. The policies are all related to co-ordinating the performance of activi-

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30


Table 2 Resulting creation matrix f1 s1 s2 s3 s4 s5 s6 s7 s8 s9










ties within the process to be modelled. This too cannot be modelled. 5. Using Petri Nets for modelling the Enterprise Viewpoint

5.1. The Petri Net approach In [15,16] van der Aalst and van Hee present the application of Petri Nets to the modelling of business processes. They use an extension of the classical Petri Net as introduced by C.A. Petri in 1962. This extension adds color, time and hierarchy to the classical concepts. A classical Petri Net is a directed bipartite graph with two node types called places and

transitions. We will use the graphical convention used in the cited references, and we will present a place by a circle and a transition by a rectangle with a marked corner. A place can contain zero or more tokens, which are represented by black dots. Fig. 11, which is taken from [15], represents a clerk processing documents. The distribution of tokens over the places determines the state of the net. The state represented in Fig. 11 is the start state, in which the clerk can start processing. In the next state one of the tokens from d – in will be removed as well as the token from c – free. Places c – busy and d – proc will now contain a token. The final state is reached when c – free contains one and d – out contains three tokens. Processing then finishes. The extension with color, time and hierarchy adds some more descriptive power to the modelling technique. The concept of color is used to designate the introduction of attributes that are associated with tokens. Therefore, in a coloured Petri Net, tokens are seen as data elements having attributes with specific values. Tokens can also have a time stamp. This time stamp determines when they can be consumed. Using time stamps, processing delays can be modelled. Finally, the mechanism of nesting Petri Nets is used to reduce complexity. Thus, instead of a transition a sub-net can be inserted in a figure. This sub-net is itself a Petri Net which can be further refined in a sub-se-

Fig. 11. Classical Petri Net representing a clerk processing documents.

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30


Fig. 12. The business process ‘provide diabetic care’.

quent modelling step. A sub-net is designated by a rectangle. The steps to be taken in modelling a business process according to van der Aalst and van Hee, are: (1) What: In this step we determine the boundaries of the business process to be modelled. This is done by modelling the process as a sub-net, and specify the interactions with the environment by means of indicating which tokens are exchanged with this environment. (2) How: We now identify the steps to be taken within the process. A task is considered to be atomic in the sense that it is seen as an indivisible amount of work. Tasks are modelled as transitions. They are ordered by their relation with places in the Petri Net modelling the process. The Petri Net constructed defines how the process should work. (3) By Whom: Although the process is now specified as a set of partially ordered steps, it is not yet clear how the resources are allocated. This is determined in this last step. It is modelled by using a sub-net for each resource type used in the process. This sub-net implements the resource management task for that type of resource. It communicates with transitions in the process Petri Net by means of two places that are called execute – task and task – completed. Below we will illustrate this mechanism when we model our example case using Petri Nets.

5.2. Enterprise Language concepts expressed using Petri Net constructs The first step is quite similar to the first step in the OOSE approach. We have to identify a boundary between the business Provide Diabetic Care and the environment. Again, we will assume that the Patient is outside the business process we want to model. The business process can be decomposed into two business processes: schedule appointment and perform consult. Below we give the high level Petri Net. The net in Fig. 12 is in its start state. There are three requests for consult in the in-place. These can be consumed by the sub-net ‘make appointment’. This sub-net produces an appointment (at a specific date/time, with a specific health care provider) and a Case. This can either be a new (new patient, new problem) or an existing one. Both appointment and Case are consumed by the sub-net ‘perform consult’. This sub-net produces an updated Case (results are registered in the Case file) and consult results communicated to the Patient. These consult results are identical to or a summary of the results registered in the Case file. So, our Agent Patient is left outside the net, and is not explicitly modelled. Only the effect of its interaction via the in-place consult-request is shown, as the number of tokens in the in-place. The artefact Case is modelled as a place.


P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

Fig. 13. ‘Perform consult’ refined.

In what follows we will refine the sub-net ‘perform consult’. Note that we have left out the steps of creating and deleting a Case of the perform consult process. This is different from the models presented in the previous sections, where this activity was included in the GP.consult specification. Although we will not further refine the sub-net ‘make appointment’ we can say that it consists of two main steps: scheduling the appointment and creating/opening the Case. The resource GP is allocated to the step of creating a Case. The INTERNIST cannot be allocated to this step. So, the difference between the consult operations for GP and Internist, will be modelled here by different allocation strategies. This will be clarified further in the disscusion on the third modelling step By Whom below. The process ‘perform consult’ consists of several steps. We assume here that two steps are making up this process: diagnose, and plan treatment. The Petri Net modeling of this business process is given below. The start situation for this process is given in Fig. 13. Two appointments are waiting in the place ‘appointment’. There are also two cases available. A token in appointment can be uniquely associated with a token in Case by means of the value of some of its attributes. The attributes (not specified here) of Appointment and Case are also used to decide which transition will fire. If a Case is new the transition Diagnose will fire. If a Case has already been diagnosed and a treatment has been planned, the conduct treat-

ment transition will fire. If a case has been diagnosed, but no treatment is needed or available, the consult process can be finished. If a treatment has been started (indicated in an attribute of Case) consult can also be finished. The differences between these various cases— being, e.g. new, or diagnoses and treatment planned, or diagnosed and no treatment available—are indicated through attribute values. In these Petri Nets this is reflected through the colour of the tokens. This enables the modelling of policy 2; diagnose before planning a treatment. So, we use the mechanism of coloring extensively to derive decision rules for firing transitions. As a result the place Case co-ordinates the way the process is conducted. By modelling a specific Case as a token, it is guaranteed that only one task can be performed to for a Case at the same time. The roles associated with the agents GP and Internist are modelled as sub-nets (consult) and transitions (diagnose and plan treatment). We have now specified the business process ‘perform consult’ by means of a colored Petri Net. We have not used time stamps. Now we will finalize our model by allocating resources to the tasks identified. The Petri Net resources model the ODP agents. The resource manager in the Petri Net sense allocates roles to agents. We have two resource types: GP and Internist. Based on the resource type needed the resource manager allocates a resource to a task. For this purpose a resource manager is added to the model

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30


Fig. 14. Resource manager added to the business process.

of the business process. This is illustrated in Fig. 14. A transition places a token in the execute task place connected to the resource manager. This token has attributes for identifying: “ The job: this consists of the Case which has to be diagnosed, and the appointment information that triggered the firing of the transition. “ The task: all tasks are connected to the same resource manager. This is done because we want to guarantee that a resource is only allocated to one task at the same time. Although the resource type needed depends on the task, it is necessary to identify from which task a token originates. “ The resource class: an explicit identification of the resource class needed for conducting this task. In our example tasks will always be allocated to resources with which the appointment for the consult was made. Therefore, the resource type is determined by the job identification attributes. The fact that cases can be referred to other

health care providers is modelled here rather implicit. If, for example a GP decides that he is unable to arrive at a diagnosis, the perform consult process is finished and the consult result is a referral note for the Internist. The Patient has to make a new appointment, which will trigger a new perform consult processing by the Internist. The ODP resources were not yet discussed. They can be incorporated as attributes of the token Case. The obligations are modelled by means of the resource manager that can allocate resources (the Agents in ODP) to tasks suited for such a resource. Thus, the fact that the Internist must conduct diagnose on request by the GP (obligation 3) is modelled by making the perform consult as performed by the GP, result in a token with as value ‘refer to internist’. This token is consumed by the Patient (not modelled) and this produces an appointment request for the Internist. This token is consumed by the ‘make appointment’ process, and transformed to an appointment with the Internist. The process


P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

‘perform consult’ consumes this token. Diagnose fires, and the token passed to the resource manager indicates that the Internist must be allocated. The policy stating that a case can only be opened by one health care provider at the same time is modelled by making Case a place (or token type). An instance of this type, or a specific token, is consumed by a transition. At one moment in time a token can only be consumed by one transition. This guarantees that the this policy is met.

6. Evaluation The four methodologies were reviewed by working out a small-scale example, covering all elements listed in the business process description. The main difference between the methodologies is a difference in focus. For example, the Petri Net approach focussed very much on the roles (transitions) making up the business process, leaving agents and their interaction somewhat unspecified. However, agents and their interaction can be modelled using Petri Nets. In Table 3 we have indicated this by means of ‘ 9 ’. A ‘+ ’ means that the element is clearly specified by means of a special construct. A ‘ − ’ indicates that there is no construct available to specify the element. In Table 3 below we summarize our evaluation of the four methodologies for modeling the Enterprise Viewpoint. We have used a simple ordinal scale for indicating the modeling possibilities of the methodology: a ‘−’ means ‘not possible’, a ‘+ ’ means ‘possible’ and ‘ 9 ’ means ‘possible, but not very clear’. SOCCA is relatively weak in modelling the resources. They can be added as attributes of classes, or as classes themselves, but there is no separate modelling construct introduced for resources. In OOSE resources were represented as entity objects, in Petri Nets as places and in Zachman as information sets. For all the other components SOCCA offers good modelling con-

Table 3 Summary of the four modelling approaches

Agents Agent roles Artefact Artefact roles Resource Obligation Policy


Zachman OOSE

Petri net

+ + + + 9 + +

− + − + + − −

9 + 9 + + 9 9

+ + + + + + 9

structs. Especially for modelling policies (interpreted in this survey as behavior co-ordination) SOCCA is very well suited. The only drawback is that SOCCA models tend to get very complicated. A way to reduce complexity could be to use co-ordination patterns [18]. Zachman is definitely the weakest of the four methodologies reviewed. It offers no constructs for modelling agents and for co-operation between agents. In fact, one could say that the Zachman case clearly shows that a modelling technique suited for modelling the information viewpoint is not necessarily suited for modelling the Enterprise Viewpoint. Different constructs are needed. So, we do not agree with Cook that the Zachman framework extends to the business level. The constructs put forward in the Zachman approach are not suited for business modelling. OOSE is somewhat complementary to SOCCA. The strong point of SOCCA (modelling co-ordination between agents) is a weak point of OOSE. As was shown in Section 3.1, co-ordination is expressed by using a selectionstatement on a Boolean expression in the specification of a use case. For complicated co-ordination structures this results in algorithmic specifications which are hard to read. In fact, this component of a business model is modelled at a much too detailed level in OOSE. Strong point is the distinction between actors and resources (control objects and entity objects). The Petri Net approach is focused on the process seen as a system of activities and resources. Agents are not part of the net modelling the business process. They are introduced in a sepa-

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30

rate net describing the resource manager. So, the roles to be played by agents and the mutual relations between them, are modelled in a distributed fashion. The information is partly contained in attributes of the tokens passed to the resource manager, indicating the type of resource needed, and partly in the internal structure of the resource manager net. Therefore, all components of a business model in which agents play a role are not very well supported in the Petri Net approach.

7. Future work As we noted in Section 1, the new systems development approach of integrating pre-existing components raises two important problems: how to pick the right components, and how to integrate them. Our thesis is that the right components and the right way of integrating them can be derived from a model of the business to be supported by those components. A business process is described as a set of co-operating agents. Co-operation is specified by means of the obligations these agents have to each other, which are constrained by policies. The model of the business process plays a pivotal role in our approach. It guides integration between components because it specifies the functional requirements for this integration, derived from the relations distinguished between tasks performed by the agents participating in the process. Therefore, we need a sufficiently rigorous modelling methodology. From our evaluation we can conclude that a combination of OOSE and SOCCA offers the best possibilities for modelling a business process covering the elements we required. This partly coincides with the Unified Modelling Language effort [12], in which OMT, OOSE and the BOOCH approach are combined. From OOSE the Use-Case concept is taken. We argue for a further extension by including the dynamic behavior modelling constructs from SOCCA. This enables a clear way of modelling policies. Summarizing, OOSE and SOCCA offer good possibilities, but must be combined in order to .


get the best of both. We propose an approach for modelling the Enterprise Viewpoint, based on the following steps: (1) Construct use-cases for the business processes to be investigated (OOSE). (2) Derive class diagram per use-case and define uses-relations between classes. The class diagram must explicitly distinguish between control and entity objects (SOCCA and OOSE). (3) Give for the objects participating in a usecase the external behaviors (STD’s with operations exported within the context of that use case) (SOCCA and OOSE). (4) For each of the exported operations the internal behavior is modelled. (SOCCA). (5) Model co-ordination of behaviors using traps. Where possible co-ordination patterns are to be used (SOCCA).

References [1] R. Orfali, D. Harkey, J. Edwards, The Essential Distributed Objects Survival Guide, Wiley, New York, 1996. [2] T.J. Mowbray, R. Zahavi, The essential CORBA: Systems Integration Using Distributed Objects, Wiley, New York, 1995. [3] ODP, ISO/IEC DIS 10746-1, Part 1: Overview [4] ODP, ISO/IEC DIS 10746-2, Part 2: Descriptive Model [5] ODP, ISO/IEC DIS 10746-3, Part 3: Prescriptive Model [6] ODP, ISO/IEC DIS 10746-4, Part 4: Architectural Semantics [7] H. Bowman, J. Derrick, P. Linington, M. Steen, FDTs for ODP, Comput. Stand. Interfaces 17 (1995) 457 – 479. [8] G.L. Engels, P.J. Groenewegen, SOCCA: specifications of coordinated and cooperative activities, in: A. Finkelstein, J. Kramer, B.A. Nuseibeh (Eds.), Software Process Modelling and Technology, Research Studies Press, Taunton, MA, 1994. [9] T. de Bunje, G. Engels, L.P.J. Groenewegen, A. Matsinger, M. Rijnbeek, Industrial Maintenance Modelled in SOCCA: an Experience Report. [10] I. Jacobson, M. Christerson, P. Johnson, G. O8 vergaard, Object-Oriented Software Engineering — A Use Case Driven Approach, Addison-Wesley, New York, 1992. [11] I. Jacobson, M. Ericsson, A. Jacobson, The Object Advantage: Business Process Reengineering with Object Technology, Addison-Wesley, New York, 1994. [12] G. Booch, J. Rumbaugh, Metamodel Guide in the Unified Method for Object-Oriented Development, Documentation Set Version 0.8, Rational Software Corporation, 1995. [13] J.A. Zachman, A framework for information systems architecture, IBM Syst. J. 26 (3) (1987).

P.J. Toussaint et al. / Computer Methods and Programs in Biomedicine 55 (1998) 11–30


[14] M.A. Cook, Building Enterprise Information Architectures: Reengineering Information Systems, Prentice Hall, Englewood Cliffs, NJ, 1996. [15] W.M.P. van der Aalst, K.M. van Hee, Framework for business process redesign, in: J.R. Callahan (Ed.), Proceedings of the 4th Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 95), IEEE Computer Society Press, Berkeley Springs, 1995. [16] W.M.P. van der Aalst, K.M. van Hee, Business process redesign: a Petri-net-based approach, Comput. Ind. 1995.

. .

[17] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, NJ, 1991. [18] L.P.J. Groenewegen, G. Engels, Coordination by behavioral views and communication patterns, in: W. Scha¨fer (Ed.), Software Process Technology (EWSPT’95, Noordwijkerhout), LNCS 913, Springer, Berlin, 1995. [19] Information on this data set and the project Diabcare Q-net can be found on the world wide web at: http://