MODULAR BEHAVIOUR MODELLING OF

SERVICE PROVIDING BUSINESS PROCESSES

Ella Roubtsova, Lex Wedemeijer, Karel Lemmen

Open University of the Netherlands, The Netherlands

Ashley McNeile

Metamaxim Ltd, U.K.

Keywords:

Service providing business process, Requirements modelling, Standard requirements, Flexibility, Modular

model, Executable model, Composition.

Abstract:

We examine possibilities for modularizing the executable models of Service Providing Business Processes in

a way that allows reuse of common patterns across different applications. We argue that this requires that

we can create independent models for different aspects of the process, and then compose these requirements

related partial behavioral models to form a complete solution. We identify two areas of modeling that should

be separable from the main, application speciﬁc, process model: the underlying subject matter with which the

process is concerned, and standard reusable process-level behavior that is common across many processes.

Using an example of a Service Providing Business Process concerned with Accreditation of Prior Learning

we show that the Protocol Modeling approach has the capability to support modularization of functional and

non-functional requirements, when other paradigms cannot completely support it.

1 INTRODUCTION

A Service Providing Business Process (SPBP) is an

interactive process that transforms the requests of

users and the information presented in rules, law reg-

ulations or databases of ofﬁcial organizations into a

physical product or a document. A Service Providing

Business Processes (SPBP) may be either an indepen-

dent process or an elementary process of a service-

oriented business process in the context of SOA (Erl,

2004; Reisig et al., 2007).

SPBPs are subject to constant change caused by

social and technological factors. The changes have to

be reﬂected both at the modelling and the implemen-

tation level. The need to support continual change

motivates the use of modular and compositional ap-

proaches in development of SPBPs, both at the mod-

eling and implementation level.

To provide its service, any SPBP utilizes some un-

derlying subject matter implemented as databases, re-

sources of the semantic web or ofﬁcial information

sites. These provide the raw material on which the

service acts. The underlying subject matter may be

represented by an underlying model. The underlying

model has its own dynamics, because the business ob-

jects of the underlying model have own life cycle.

Conceptually separate from this, an SPBP itself

has a process model that describes how it:

(1) Uses and acts on the state and data content of the

underlying subject matter to perform tasks (such as

data transformation and analysis) speciﬁc to the ap-

plication;

(2) Provides such common (or standard) process-level

functions as registration, archiving, security, payment

and acknowledgement (of business steps and deci-

sions) to the service-consumer.

In this paper we show that the Protocol Model-

ing approach (McNeile and Simons, 2006) has the

capability to support modularization of the underly-

ing model and crosscutting functional requirements,

when other paradigms cannot completely support it.

Section 2 of this paper describes an example in the

SPBP domain. Section 3 presents the modeling se-

mantics that allows separating standard and speciﬁc

requirements for an SPBP and relate them to models

to make models manageable and ﬂexible. Section 4

draws conclusions about ﬂexibility and reuse of Pro-

tocol Models.

338

Roubtsova E., Wedemeijer L., Lemmen K. and McNeile A. (2009).

MODULAR BEHAVIOUR MODELLING OF SERVICE PROVIDING BUSINESS PROCESSES.

In Proceedings of the 11th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

338-341

DOI: 10.5220/0001949803380341

 SciTePress

2 EXAMPLE OF AN SPBP

An example of an SPBP is the process of Accredi-

tation of Prior Learning (APL)(LIFELONG LEARN-

ING, 2008).

The APL service is triggered by a student who fol-

lows an education provided by a university. The stu-

dent requests the university to grant exemptions from

the ofﬁcially listed courses of the current education.

The request form contains the student number, the of-

ﬁcial name of the current education, the ofﬁcial name

of the former education of the student and the cer-

tiﬁcate of the former education. If the former edu-

cation is not on the list of educations recognized for

exemption, the request is rejected and the student is

informed. If the former education is on the list of rec-

ognized educations, the request is registered, the stu-

dent receives an acknowledgement and a request for

payment. When payment has been received, the as-

sessment team receives the request of the student.

The assessment of the certiﬁcate of former edu-

cation is fulﬁlled by a trained assessor. If the certiﬁ-

cate is complete and valid, the student gets exemption

from a set of courses of his current education. The

student is informed by receiving an ofﬁcial document

about the exemptions. If the certiﬁcate is not valid,

the assessment is negative. If the certiﬁcation is in-

complete, the student gets one chance to send a com-

plete certiﬁcate and have the assessment repeated.

The APL process transforms a request of a stu-

dent and the information in the ofﬁcial sources into

a product: a document of assessment. The ofﬁcial

sources about Education, Exemption, Student and As-

sessor form the underlying subject matter of the ser-

vice. The APL process also implements the process-

level functions of request registration, payment, ac-

knowledgement and security.

3 MODULARIZATION OF SPBPS

In order to achieve modularization of requirements

in behavioural models we have investigated many

popular modeling techniques: Coloured Petri

Nets (Jensen, 1997), statecharts (Harel and Politi,

1998) and several UML proﬁles. We have built

executable models of our case study using all those

techniques and trying to localize requirements in the

models. Although sequential functional requirements

deﬁning the APL process (registration, payment,

assessment) are localisable, such requirements as

security, acknowledgement and archiving demand

copies of all other models and cannot be localized

in conventional modelling notations. We have found

that there are three reasons for this. The conventional

techniques do not have

- Event-refusal semantics needed to model interaction

and so do not allow behavior synchronization within

a SPBP. Synchronization is usually used to present

collaboration of SPBPs (Su. et al., 2008).

- A concept of a derived state. Without this con-

cept, handling changes in a state value that is not

represented as a single data attribute requires the

generation of artiﬁcial internal events.

- Event and state abstractions needed for speciﬁcation

of cross-cutting functional requirements.

We show that the Protocol Modelling technique (Mc-

Neile and Simons, 2006) possesses the listed concepts

and allows localization and composition of functional

and non-functional requirements in models.

Protocol Model. A unit of a Protocol Model is a Pro-

tocol Machine PM = (S, D, E, T), where

• S = {s

, s

, ...s

}, n ∈ N, is a non-empty ﬁnite set of

stored states. A stored state has a corresponding set of

attribute values, including the state name.

• D = {d

, d

, ..., d

}, k ∈ N, is a ﬁnite set of derived

states calculated using the states of the machine itself

and other protocol machines. D can be empty.

• E = {e

, e

, ..., e

}, m ∈ N is an alphabet of events,

i.e. a non-empty ﬁnite set of recognized events com-

ing from environment.

• T = {t

, ..., t

}, p ∈ N is a set of transitions. A transi-

tion t can be of types t = (s

, e, s

t = (d

, e, any state) or t = (any state, e, d

A protocol machine (Figures 1,2) may be represented

as a set protocol state diagrams, where

• a stored state is depicted as an ellipse;

• the values of attributes in a stored state are presented

near the state in a bubble;

• a derived state is presented as a double line ellipse;

• the rules of derivation of a derived state are presented

as an expression of the protocol machine;

• a transition is depicted

– as an arc, i.e. a pair states labeled by the events that

cause this transition or

– as an arrow coming from or to a derived state and

labeled by the events that cause this transition.

The semantics of a protocol state diagram is different

from the UML state diagram (OMG, 2003) and

statecharts (Harel and Politi, 1998).

Behavior of a Protocol Machine. The state diagram

of a protocol machine has the following behavioral

semantics.

• If an event does not belong to the alphabet of recog-

nized events, the machine ignores it.

MODULAR BEHAVIOUR MODELLING OF SERVICE PROVIDING BUSINESS PROCESSES

339

• If the machine is in the state that has an output arc la-

beled by the alphabet-event, it accepts the event and

transitions to another state. This is the only possible

cause of a transition.

• If the machine is in the state that has no output arc la-

beled by the alphabet-event, it refuses the event.

– If the arrow labeled by an event has no start state,

it presents the transition from any state to the given

derived state.

– If the arrow labeled by an event has no end state, it

presents a transition from the given derived state to

any state.

The ﬁnal two rules apply only to machines that have a

derived state, where the state is given by a derivation

function rather than stored by the machine.

SetUpExemption [CurrentEducation],

Modify Education,

ModifyExemption [CurrentEducation]

Request [CurrentEducation]

Education

SetUpExemption [FormerEducation]

ModifyExemtion [FormerEducation]

RegisterStudent

ModifyStudent, Request [FormerEducation]

Discontinued

Registered

Discontinue

Education

Exemption Modify Exemption

Setup

Exemption

RemovedSetUp

Remove

Exemption

ModifyAssessor

Assess

IncompleteDoc

Assessor

Archived

Registered

Archive

Assessor

Underlying model

Student

ModifyStudent,

Request.,Pay, CompleteDoc

Registered

Archive

Student

Archived

Figure 1: Underlying model of the APL system.

Composition of Protocol Machines. The rules

of the composition of protocol machines are the

CSP parallel composition rule (Hoare, 1985): If

there are several protocol machines that recognize an

event then this event will be only accepted if all those

machines can accept it.

A Protocol Model of the APL system is a compo-

sition of protocol machines shown in Figures 1,2.

SetUpExemption [CurrentEducation],

Modify Education,

ModifyExemption [CurrentEducation]

Request [CurrentEducation]

Education

SetUpExemption [FormerEducation]

ModifyExemtion [FormerEducation]

RegisterStudent

ModifyStudent, Request [FormerEducation]

Discontinued

Registered

Discontinue

Education

Exemption Modify Exemption

Setup

Exemption

RemovedSetUp

Remove

Exemption

ModifyAssessor

Assess

IncompleteDoc

Assessor

Archived

Registered

Archive

Assessor

Underlying model

Student

ModifyStudent,

Request.,Pay, CompleteDoc

Registered

Archive

Student

Archived

Figure 2: Process Model of the APL System.

The event synchronization semantics allows easy sep-

aration and composition the functionalities of the

APL service providing business process. The syn-

chronization works as follows.

- If a student initiates a request, he/she should cor-

rectly enter his password, i.e. the Security machine

should be in state Active.

- If the password corresponds to the saved password,

then student may initiate the Request event. If the

model is presented with event

Request: (StudentNumber, Password, FormerEducation,

CurrectEducation, Certiﬁcate),

the protocol machines Registration, Validity, Student,

CurrentEducation, FormerEducation, Payment, Ac-

knowledgement and Security recognize this event.

- The protocol machine Validity checks if there is an

exemption that corresponds to the current and the for-

mer education mentioned in the request. If there is

such an exemption, the request is registered. This

means that the Registration machine goes to the state

Registered, the Acknowledgement machine generates

an acknowledgement for registration, and the Pay-

ment machine goes to the state Issued, so that the

ICEIS 2009 - International Conference on Enterprise Information Systems

340

event Pay becomes possible for the student. This way

all the machines combine to produce the system be-

havior.

Event Abstractions. Protocol machines may use

generic events, i.e. the aliases of events from a set.

For example, event Acknowledge={Request, Pay, Assess,

IncompleteDoc, CompleteDoc }.

Each event that belongs to an alias causes the same

behavior of the protocol machine that reacts to the

alias. For example, each event of the last set has to

be acknowledged. A generic event is a means to sep-

arate and reuse the models of requirements.

Local Reasoning. It is proven in (McNeile and

Roubtsova, 2008) that the composition of protocol

machines results in behavior that preserves the in-

dividual behavior of its component machines. This

propertyof models allowslocal reasoning on behavior

of parts about behavior of the complete system. For

example, analyzing only the Assessment module we

can say that the sequence of events ”Pay, Incomplete-

Doc, CompleteDoc, IncompleteDoc, CompleteDoc” does

not belong to the behavior of the system, i.e. it is im-

posable to update documents more than once.

4 FLEXIBILITY AND REUSE OF

PROTOCOL MODELS

Separate models of requirements make Protocol Mod-

els manageable and allow modiﬁcation of the model

without remodeling. A new requirement may

(1) Reduce the set of models. For example, if the As-

sessment were free of charge, then the generic event

Start = {Register} and Payment protocol machine

should not be used;

(2) Modify a condition for acceptance of an existing

event in terms of the pre-state or the post-state. For

this case, modiﬁcation is needed of the machine that

embodies the state-based condition for event accep-

tance (as, for example, the Validity machine does for

the Request event);

(3) Modify the results of event acceptance in terms

of states. This means modiﬁcation of the topology

and/or state calculation of the correspondingmachine.

(4) Deﬁne a set of sequences of related reactions on

new and old events. This extension usually means

modeling additional functionality as a separate pro-

tocol machine, and synchronizing it with the rest of

the protocol model using shared events.

Each the model modiﬁcations outlined above is local,

i.e. has to be done in one protocol machine and does

not demand modiﬁcation to the states or transitions of

other protocol machines.

Protocol Models corresponding to requirements

are easy to reuse. For example, the Registration, Pay-

ment, Acknowledgement and Security machines can

be reused in a different SPBP. The same set of ma-

chines may be reused for an Examination service. The

Assessment protocol machine will be replaced with

the Examination protocol machine and the generic

events will be changedin correspondencewith service

events, i.e. Serve = {Examine}. With some extension

the same model can be used for a hotel reservation or

a conference registration services.

This means that Protocol Modelling supports

reuse of common requirements-oriented patterns and

simpliﬁes building of executable models among dif-

ferent applications in the SPBP domain.

REFERENCES

Erl, T. (2004). Service-Oriented Architecture (SOA): Con-

cepts, Technology, and Design. Prentice Hall.

Harel, D. and Politi, M. (1998). Modeling Reactive Sys-

tems with Statecharts: The STATEMATE Approach.

McGraw-Hill.

Hoare, C. (1985). Communicating Sequential Processes.

Prentice-Hall International.

Jensen, K. (1997). Coloured Petri Nets. Springer.

LIFELONG LEARNING (2008). http://ec.europa.

eu/education/llp/.

McNeile, A. and Roubtsova, E. (2008). CSP parallel com-

position of aspect models. In AOM ’08: Proceedings

of the 2008 AOSD workshop on Aspect-oriented mod-

eling, pages 13–18, New York, NY, USA. ACM.

McNeile, A. and Simons, N. (2006). Protocol Mod-

elling. A modelling approach that supports reusable

behavioural abstractions. Software and System Mod-

eling, 5(1):91–107.

OMG (2003). Uniﬁed Modeling Language: Superstructure

version 2.1.1 (with change bars) formal/2007-02-03.

Reisig, W., Bretschneider, J., Fahland, D., Lohmann, N., as-

suthe, P., and Stahl, C. (2007). Services as a Paradigm

of Computation. LNCS 4700, pages 521–538.

Su., J., Bultan, T., Fu, X., and Zhao, X. (2008). Towards a

Theory of Web Service Choreographies. LNCS 4937,

pages 1–16.

MODULAR BEHAVIOUR MODELLING OF SERVICE PROVIDING BUSINESS PROCESSES

341