=Paper=
{{Paper
|id=Vol-341/paper-5
|storemode=property
|title=Meta-model Tailoring for Situation-aware Business Process Modelling
|pdfUrl=https://ceur-ws.org/Vol-341/paper5.pdf
|volume=Vol-341
|dblpUrl=https://dblp.org/rec/conf/caise/SaidaniN08a
}}
==Meta-model Tailoring for Situation-aware Business Process Modelling==
https://ceur-ws.org/Vol-341/paper5.pdf
Meta-model Tailoring for Situation-aware Business
Process Modelling
Oumaima Saidani1, Selmin Nurcan 1,2
1
Université Paris 1 - Panthéon - Sorbonne, Centre de Recherche en Informatique
90, rue de Tolbiac 75013 Paris France,
2
IAE de Paris - Sorbonne Graduate Business School
Université Paris 1 - Panthéon - Sorbonne 21, rue Broca 75005 Paris France
{Oumaima.Saidani, Selmin.Nurcan}@univ-paris1.fr
Abstract. Current environments are dynamic. For surviving, organisations
should be adaptable to and interoperable with these environments; their
Business Processes (BPs) have to provide means to suit the effectiveness
requirements. The most important success factors are flexibility and
adaptability. Situational engineering has proved its effectiveness, in terms of
flexibility and reuse, in many engineering domains such as software and IS
development. So reasoning on a situational approach is a challenging research
work which can contribute to increase flexibility of models and their
adaptability to different organisation settings. The paper deals with creating
meta-models for BP modelling which adapt to the situation at hand.
Keywords: BP Modelling, Meta-modelling, Flexibility, Adaptability.
1 Introduction
Current researches on business process (BP) modelling stress the importance of the
flexibility and the adaptability support for BP (see for instance [8], [28], [33]). [20]
provides a survey on the flexibility requirements related to BPs and modelling
artefacts. Reasoning on variability in modelling artefacts can meet the flexibility and
context-awareness requirements by offering alternative solutions depending on the
context and on the points-of-view of the decision-makers. We argue that flexible and
adaptable process modelling may help to assure the flexibility and the adaptability of
the BP. Since organisation settings and users objectives and viewpoints are divergent
and even conflicting, a single BP formalism is still insufficient. A promising idea is to
propose an approach for adapting and configuring existing formalisms according the
organisation settings and users objectives, rather than to advice for a single one which
can be of high quality for specific requirements and inadequate for others. The
formalisms can be described by meta-modelling. The meta-model allows defining the
process model and its concepts (e.g. activity, role). It corresponds to the level 2 of the
OMG four-level-architecture for the processes [2]. The process model instantiates the
Proceedings of MoDISE-EUS 2008 47
meta-model in order to represent a process. An instance represents an actual BP.
Thus, we focus on the flexibility at the BP meta-model level.
BPs are of various kinds and are defined in different levels of abstraction using
various artefacts depending on the organisation settings and the purpose of the
modelling. For instance, in mechanistic or production organisations, BPs are often
prescribed in a very detailed level since they shall be executed. On contrary, in
adhocracies organisation, more freedom can be left to business actors for choosing
how to perform the underlying business objectives. Accordingly, since formalisms are
proposed for various purposes, none of them captures all the mentioned aspects. They
may be dissimilar and based on different techniques. While activity-oriented
approaches [2] focus on executability by software tools and translation into
executable languages such as BPEL4WS or ebXML, intention-oriented approaches
aim to capture business goals, human reasoning, decision making, and interaction
between actors [22], [21], [23], [39], [40].
Nonetheless, even if these formalisms capture different views of the business,
sometimes their interrelationships could or should be taken into consideration and
their complementarity needs to be expressed. That is, in some situations, activity-
oriented and product-oriented approaches need to be matched in order to determine
which activity influences on which product and on which step of the process. Also,
strategy-oriented meta-models require to be made operational using activity-oriented
models [21]. As well, [37] combines intention-oriented and state-based process
modelling. One can say that there is need of a comprehensive formalism that captures
all mentioned aspects. Nevertheless, as mentioned, these requirements are often
situation-aware and not universal. Each aspect may or may not be relevant for a given
organisation and a particular situation. In other words, according to usage conditions,
some aspects have to be captured in a process meta-model and not the others. What is
required in not an exhaustive meta-model, but mechanisms for adapting existing ones
to specific requirements. Note that none of existing formalisms offer extension or
adaptation mechanisms. Our aim in this paper is to propose the study of such
mechanisms. We will not compare process meta-models neither to recommend
particular ones. These issues have been dealt with in many studies (See for instance
[32], [36]). Our motivation behind this proposal is that a formalism which is used for
modelling BP in a specific organisation setting is not necessarily adequate for others;
and since several formalisms have proved their effectiveness in many business areas,
it does not seem necessary to develop new ones.
In the community of information systems development (ISD), the field of method
engineering (ME) has been introduced as a response to the need for methods adapted
to specific ISD project situations, and to the failure of the methods known as
"universal" [29]. One area of ME, is the Situational Method Engineering (SME),
which aims to construct new methods and the associated tools or to adapt existing
ones to every ISD project [13]. We highlight that the ISD requirements on flexibility
and adaptability that are behind the ME emergence in the ISD field are similar to
those currently observed in the BPM field. We will thus base our reasoning on SME
mechanisms. The reminder of the paper is structured as follows. Section 2 presents
background and discusses related works. Section 3 introduces our approach with an
illustrative example. Section 4 concludes the paper.
48 Proceedings of MoDISE-EUS 2008
2 Background and Related Work
2.1 Process Modelling
BP modelling consists in capturing processes and highlighting significant
organisational and operational aspects of the business. It may serve two distinct
purposes: descriptive or prescriptive [4], [14]. The descriptive perspective aims at
recording and providing a trace of what happens during the development process (see
for example [7], [27]. The prescriptive perspective is used to describe "how things
must/should/could be done" and is often used as ways-of-working [35]. BPs can be
roughly classified into two categories depending on their nature. The first one
concerns well-defined and -often- repetitive processes having important coordination
and automation needs. The second one concerns ill-defined processes. For many
organisations, well-defined and ill-defined processes coexist and must be handled in
the final BP model [20].
There exists a number of process modelling formalisms, e.g. activity-oriented
modelling (like [15], [12]. They focus on the activities and their ordering. Product-
oriented process approaches combine the product state with the activity generating
this product state (e.g. statecharts [9] and the state-transition diagram (state machines)
[17]). A product-oriented model defines the manner a product translates from one
state to another, i.e. by what transition. The more recent approaches for process
modelling are goal-oriented [19], decision-oriented [21], and intention-oriented [31].
They capture the Why in addition the What and How issues.
2.2 Method Engineering
Method engineering (ME) is the discipline to study engineering techniques for
constructing, assessing, evaluating and managing tools for developing ISD Methods
[30]. Situational method engineering (SME) promotes the construction of a method
by assembling reusable method chunks stored in some method base [26]. The method
elements are often represented using meta-modelling approaches. For details about
SME related research, refer for instance to [5], [10], [16]. There exist four well-known
principles of ME which are: meta modelling, flexibility, reuse and modularity [30].
[18] introduces a faceted framework to understand and classify issues in system
development SME.
2.3 Context-awareness
The context plays an important role in several disciplines like natural language
semantics and artificial intelligence knowledge management, and web systems
engineering [1], [3]. In the domain of BP modelling, context awareness is relatively
new field of research. However, some papers on this subject have already been
Proceedings of MoDISE-EUS 2008 49
published [32], [34]. In this paper, we mean by the context the knowledge which
captures the situation of use of the chunk.
3 Situation-aware Meta-models for Flexible BP Modelling
We argue that a BP may be considered according different points of views and
different abstraction levels according to the situation at hand and the decision-maker
vision. Building the adequate meta-model can be done following several manners, for
instance, (i) by assembling relevant concepts, which belong to different meta-models,
(ii) by constructing a core meta-model and enhancing it with required concepts, (iii)
by choosing one basic meta-model from the existing ones, and extending it, if
necessary, with the appropriate concepts, (iv) by choosing a meta-model that captures
most relevant aspects (for instance activity and product related aspects), and adapting
it by deleting and/or adding concepts. With analogy to the method in the ISD field, we
introduce the concept of business method which consists on a set of reusable
components that we name business chunks. A business method is composed of a
product model and a process model; in this paper we consider only the product model.
In the reminder, we denote by chunk a business chunk. Chunks are stored in a chunk
repository in order to enable operations of research, comparison and extraction on
them. They can be reused and combined in order to build new chunks or extending or
adapting existing ones. A chunk can be simple or composed of other chunks. In the
reminder, we formally define chunks and as well as some functions which are
relevant for building chunks. We are inspired from some operators defined in [5] and
[25]. Our belief is that instead of defining a complete set of features in a single meta-
model, a taxonomy of independent features can be defined and captured into various
chunks depending on the situation. Thus, in a given situation, the process engineer
can select or build the appropriate meta-model.
We define a chunk chi as followed: chi = (id_chi, pmi, ci, ai), where id_chi is the
identifier of the chunk chi, pmi is the product meta-model of chi, ci is the context of
use of chi, i.e. in which situation chi can be used. ai is an annotation describing it.
E is a finite set of elements, E = {e1, e2… en}.
R is a finite set of relationships between the elements, R = {r1, r2… rm}, where
ri=(name_ri, type_ri, ej, ek ), type_ri∈{“association”, “aggregation”, “inheritance”}.
P is a finite set of properties, P={p1, p2, …, pn}, where pi=(name_pi, ej, domain).
PM is the set of product models, PM ⊆ ExRxP.
We define the following functions:
pm: CH → PM is a function mapping each chunk chi to the product meta-model of
the concerned chunk (chi).
elements: CH → 2 n is a function mapping each chunk chi to the set of the elements of
chi, where n = card (E ) .
relationships: CH → 2 m is a function mapping each chunk chi to the set of
relationships of. chi, where m = card (R) .
properties: E → 2l is a function mapping each element ei to the set of properties of ei,
where l = card (P) .
50 Proceedings of MoDISE-EUS 2008
Formulas (1), (2), (3) and (4) present some functions which allow respectively (i)
to add an element to an existing chunk, (ii) to add a relationship between two
elements that belong to two different chunks, (iii) to add a property to an element, and
(iv) to rename an element. In fact, in some cases, even if two concepts of different
models are semantically similar, they are named differently. For instance, the
concepts of task in BPMN, stage in VPL [38] and activity in ICN [6] have the same
semantic. As well as the concepts of procedure [6] and plan [38]; and business
intention and business goal (see Fig 1).
add − element : CHxExR → CH (1)
{ }
( ch i , e j , rk ) → ch i ' elements (ch i ' ) = elements (ch i ) ∪ e i
add − relationship : CH 2 xE 2 xR → CH (2)
(ch i , ch j , e i , e j , r ) → ch k
pm ( ch i ) ⊆ pm ( ch k ), relationsh ips ( ch k ) = relationsh ips (ch j ) ∪ r
add − property : ExP → E (3)
(ei , p j ) → e i ' p j ∈ properties (ei ' )
rename − element : E → E (4)
(ei ) = ei name _ e(ei ) = new _ name
Illustrative example. Let us consider two chunks ch1 and ch2 (see Fig 1).
Fig 1 (Ch1) represents the meta-model of the intentional view of the BP modelling
framework defined in [22], [23]. According to Nurcan et al., business maps aim to
provide an intention/decision-oriented definition of BPs [23]. The intentional view is
based on the map model defined by Rolland et al. [31]. We will briefly recall the map
model. A map is a labelled directed graph with intentions as nodes and strategies as
edges between intentions. It consists of a number of sections each of which is a triplet
. An intention is defined as a
goal that can be achieved by the performance of a process. A strategy is defined as a
manner to achieve an intention. A map has associated guidelines for the selection of
the next intentions and strategies on the one hand as well as for the achievement of
the selected strategies on the other hand. Guidelines take into consideration the
situation at hand. According to Nurcan et al., business intention and strategy selection
guidelines describe the know-how of the business decisional level [23].
Fig. 2 (Ch2) represents the meta-model of a role-based BP modelling approach
which is based on and keeps a minimal set of features of the approach proposed in
[33]. The purpose of the latter [33] was to overcome the limitations of the classical
techniques by providing a set of extension mechanisms around the concept of role. In
Ch2, organizations are structured as networks of BPs in order to achieve their
business goals. BPs can be first analysed in terms of roles played by actors. Each
actor belongs to one or more organisational units and is assigned to appropriate roles
based on his/her responsibilities and qualifications. An actor represents a human
being or autonomous agents. The central concept of Ch2 is the role. A role is a
semantic construct about which business rules and other concepts can be formulated.
Proceedings of MoDISE-EUS 2008 51
It can represent a competency to realise particular functions, e.g. “engineer”, and can
embody authority and responsibility, e.g. “project supervisor”. Each actor belongs to
at least one organisational unit and is assigned to appropriate roles based on his/her
responsibilities and qualifications. A business goal is reached by performing one or
more BPs. Ch2 can be suitable to stable organisations where changes are minor. For
more details see [33].
Business Map 1 Strategy
^ 0,1
Is refined by
1 2,*
1,* 1,*
Guideline Section
Has for source Has for target
1 1
Strategy Intention Intention Business Intention
Selection Achievement Selection
Guideline Guideline Guideline
* Ch1
*
Makes-
operational
* Reachs
BPFragment
BP chunk
*
Organizational Ch2
Unit
*
Belongs to
* Can play Can hold
Actor Role Operation
* * *
1
* * *
* Participates
Includes * Business
Process * Comprises
*
Acts on
* *
* Business
Business goal object
Fig. 1. Example of application of functions on chunks ch1 (top) and ch2 (bottom)
In order to make ch1 executable, we need to assemble the two chunks, to do this,
we can use the function add_element (ch2, BP fragment, includes) (formula (1)) in
order to add a new element BP fragment and the relationship includes between the
elements Business process (of ch2) and BP fragment in order to make operational a
section following the associated intention achievement guideline. Next, we use the
function add_relationship (ch1,ch2, Intention_Achievement_Guideline, BP fragment,
Makes-operational) (formula (2)) in order to create the relationship Makes-
52 Proceedings of MoDISE-EUS 2008
operational between the elements Intention_Achievement_Guideline (of ch1) and BP
fragment (added to ch2). After that, since the elements Business goal (of ch2) and
Business intention (of ch1) have the same semantic, one of the elements should be
renamed. Thus rename_element(Business goal) (formula (4)) could rename Business
goal (of ch2) Business intention.
4. Conclusion and Future Work
This paper provides a start point towards an approach for configuring and adapting
meta-models for BP modelling that are customised to the situation at hand. We have
introduced the concepts of business method and business chunk. The proposed
approach allows capturing in the meta-model different aspects of business processes
and defining relationships between them by using business chunks. We promote the
idea that the final meta-model has to be created from the set of proposed chunks in
order to suit to a particular organisation setting. This approach aims to make easier the
definition of flexible customised meta-models.
The work presented in this paper is the first attempt for the situational process
meta-modelling for flexible BPs. Dealing with situation-awareness raises many
questions which need further research such as the contexts influencing the selection of
the adequate chunks, the definition of a comprehensive set of assembly, adaptation
and extending functions, the description of the process of meta-model building, the
definition of rules for extending meta-models.
References
1. Bouquet P., Ghidini C., Giunchiglia F., Blanzieri E., “Theories and Uses of Context in
Knowledge Representation and Reasoning”. Journal of Pragmatics – Special issue on
context, 2003.
2. BPMI.org, “OMG: Business Process Modeling Notation Specification”. Final Adopted
Specification. Object Management Group, 2006.
3. Coutaz, J., Crowley, J., Dobson, S., Garlan, D., “Context is key”, Communications of the
ACM, vol. 48, n° 3, 2005.
4. Curtis, B., Kellner, M., Over, J., “Process Modeling”, Communications of ACM, vol. 35 n°
9, 1992, p. 75-90.
5. Deneckere, R.., Approche d’extension de méthodes fondée sur l’utilisation de composants
génériques, PhD thesis, University of Paris 1-Sorbonne, 2001.
6. Ellis, C.A., WAINER, J., “Goal-based models of collaboration”, in: Collaborative
Computing, vol. 1, n° 1, 1994.
7. Gotel, O., Finkelstein, A., “An Analysis of the Requirements Traceability Problem”. Proc. of
the 1st IEEE International Conference ICRE, Colorado Springs, USA, 1996.
8. Green, S., Regev, G., Soffer, P., Zdravkovic, J., “Business processes and support systems:
design for flexibility”. Special Issue on Design for Flexibility, 2007.
9. Harel, D., “STATEMATE: A working environment for the development of complex reactive
systems”. IEEE Transactions on Software Engineering, vol. 16, n° 4, 1990, p.403-414.
10. Harmsen A.F., “Situational Method Engineering”. Moret Ernst & Yong, 1997.
11. Humphrey, W. S., “Managing the Software Process”, Addison Wesley, 1989.
Proceedings of MoDISE-EUS 2008 53
12. Joeris, G. and Herzog, O., “Towards Flexible and High-Level Modeling and Enacting of
Processes”. Proc. of CAISE’99, 1999, p. 88-102.
13. Kumar, K., Welke, R.J., “Methodology engineering: a proposal for situation-specific
methodology construction, Challenges and Strategies for Research in Systems
Development”, John Wiley & Sons Ltd, 1992, p. 257-269.
14. Lonchamp, J., “A structured Conceptual and Terminological Framework for Software
Process Engineering”. Proceedings of the International Conference on Software Process,
1993.
15. Marca, D.A. and McGowan, C.L., “IDEF0/SADT: Business Process and Enterprise
Modeling”. San Diego: Eclectic Solutions, Inc. 1993.
16. Mirbel, I., Ralyte, J., Situational method engineering: combining assembly-based and
roadmap-driven approaches”, Requirement Engineering Journal, vol. 11, n° 1, 2006.
17. MOF Meta-Object-Facility (MOF) specification, Version 1.4 (2002)
18. Nehan, Y. R., Deneckere, R., “Component Based Situational Methods: A framework for
Understanding SME”. In IFIP International Federation for Information Processing, Vol. 244,
Situational Method Engineering: Fundamentals and Experiences, 2007. p. 161-175.
19. Neiger, D. and Churilov, L., “Goal-Oriented Business Process Modeling with EPCs and
Value-Focused Thinking”. LNCS, vol. 3080, 2004, p. 98-115.
20. Nurcan, S., “A survey on the flexibility requirements related to business processes and
modeling artefacts”, Proc. of HICSS’08, Big Island, Hawaii, USA, 2008.
21. Nurcan, S., Etien, A., Kaabi, R., Zoukar, I. and Rolland, C., “A strategy driven Business
Process Modelling Approach”. Business Process Management Journal, vol. 11, n° 6, 2005.
22. Nurcan, S., “Business Process Modelling for developing Process Oriented IT Systems”,
IRMA’04, 2004.
23. Nurcan, S., Edme, M.E., “Intention-Driven Modelling for Flexible Workflow
Applications”, Software Process Improvement and Practice. 2005, vol. 10, p. 363-377.
24. Ralyté, J., Ingéniérie des méthodes à base de composants. PhD thesis, University of Paris 1-
Sorbonne, 2001.
25. Ralyté, J., Rolland C., “An Assembly Process Model for Method Engineering”, Proc. of the
13th CAISE, Springer, 2001, p.267-283.
26. Ralyté, J., Deneckere, R and Rolland, C., “Towards a Generic Model for Situational
Method Engineering”, CAISE’03, Springer Verlag, Velden, Austria, 2003.
27. Ramesh, B., A Model of Requirements Traceability for Systems Development. Tech.
report, Naval Postgraduate School, Monterey, CA, September, 1993.
28. Regev, G., Wegmann, A., “A Regulation-Based View on Business Process and Supporting
System Flexibility”, Proceedings of the CAiSE’05 Workshop, 2005, p. 91-98.
29. Rolland, C., « L’ingénierie des méthodes : une visite guidée », e-TI - la revue électronique
des technologies d'information, Premier Numéro, 25 octobre 2005.
30. Rolland, C., “Method Engineering: Trends and Challenges”. In IFIP International
Federation for Information Processing, Situational Method Engineering: Fundamentals and
Experiences, Boston Springer, vol. 244, 2007.
31. Rolland, C., Prakash, N.: Benjamen, A., “A Multi-Model view of Process Modelling”,
Requirements Engineering, vol. 4, 1999, p. 169-187.
32. Rosemann, M., Recker, J. Indulska, M., Green, P., “A Study of the Evolution of the
Representational Capabilities of Process Modeling Grammars”, CAISE’06, 2006.
33. Saidani, O. and Nurcan, S., “A Role-Based Approach for Modelling Flexible Business
Processes”. In proc. of BPMDS’06. 2006.
34. Saidani, O., Nurcan, N., “Towards Context Aware Business Process Modelling”, in proc.
of. BPMDS’07, Trondheim, Norway, 2007.
35. Seligmann, P. S., Wijers, G. M., Sol, H. G., “Analysing the structure of I. S. methodologies,
an alternative approach”, Proc. of the 1st Conference on Information Systems, The
Netherlands, 1989.
54 Proceedings of MoDISE-EUS 2008
36. Söderström, E., Andersson, B., Johannesson, P., Perjons, E., Wangler, B., “owards a
Framework For Comparing Process Modelling Languages” AISE’02. Toronto, Canada,
2002.
37. Soffer, P., Rolland, R., “Combining Intention-Oriented and State-Based Process Modeling”.
ER 2005, p. 47-62.
38. Swenson, K.D., “Visual Support for Reengineering Work Process”, in Proc. of the
Conference on Organizational Computing Systems, ACM, Milpitas, California, 1993.
39. Su, Onur, Business Process Modeling Based Computer-Aided Software Functional
Requirements Generation, MS. Thesis. METU, Informatics Institute, 2004.
40. Yu, E. S. K., Mylopoulos, J., “From E-R to “A-R” – Modelling Strategic Actor
Relationships for Business Process Reengineering”. In ER’04, Manchester, U.K., 1994.