=Paper=
{{Paper
|id=Vol-161/paper-33
|storemode=property
|title=TMBP: A Transactional Metamodel for Business Process Modeling Based on Organizational Structure Aspects
|pdfUrl=https://ceur-ws.org/Vol-161/FORUM_32.pdf
|volume=Vol-161
|dblpUrl=https://dblp.org/rec/conf/caise/ThomIM05
}}
==TMBP: A Transactional Metamodel for Business Process Modeling Based on Organizational Structure Aspects==
https://ceur-ws.org/Vol-161/FORUM_32.pdf
195
TMBP: A Transactional Metamodel for Business Process
Modeling Based on Organizational Structure Aspects
Lucinéia Heloisa Thom1, Cirano Iochpe1, Bernhard Mitschang2
1Institute of Informatics, Federal University of Rio Grande do Su, Av. Bento Gonçalves, 9500,
90610 Porto Alegre, Brazil
{lucineia, iochpe}@inf.ufrgs
2Institute for Parallel and Distributed Systems , University of Stuttgart, Universitätstrasse 38,
70569, Stuttgart, Germany
Abstract: Business processes executed in organization are automated through a
workflow system. Currently, there are several metamodels for business process and
workflow process modelling. However, the limitations of these metamodels are
twofold: First, the use of organizational structure aspects is limited and second they
don’t support business (sub)process patterns based on organizational structure
aspects. These limitations may restrict the accuracy, efficiency, and productivity of
the workflow project. This paper addresses the Transactional Metamodel of
Business Processes (TMBP). TMBP links organizational structure aspects with
business (sub)process and makes it feasible to create business (sub)process from
the reuse of business (sub)process patterns based on organizational structure
aspects. An additional feature of TMBP supports the generation of business
subprocess patterns through the Business Process Execution Language for Web
Services (BPEL4WS).
1 Introduction
Any organization should be modelled according to the business process1 it must perform.
Therefore, first the business process must be defined and after this the organization must
be modelled to best operate it. To model an organization involves the assignment of
values to a set of organizational structural aspects2 (OSA) concerning the business
process executed by the organization.
Modern organizations have performance demands related at least to both the execution
time and resource consumption of their business process. Within this context, the
workflow technology has shown to be very effective, mainly in the business process
automation. In workflow systems, a business process is automated through a workflow
process. A workflow process uses a workflow process metamodel to represent all
singularities of a business process needed for its automation.
1
A business process is as a partial order of tasks, where each of these tasks contributes in a stage of the
process. A business sub-process is a process integrated to as well as controlled by another business process.
2
E.g., scalar chain, the work coordination mechanism and the decision-making structure [1].
Proceedings of the CAiSE'05 Forum - O. Belo, J. Eder, J. Falcão e Cunha, O. Pastor (Eds.)
© Faculdade de Engenharia da Universidade do Porto, Portugal 2005 - ISBN 972-752-078-2
196 Lucineia Heloisa Thom, Cirano Iochpe, Bernhard Mitschang
Recently, different consortia including the Business Process Management Initiative
(BPMI) as well as the Workflow Management Coalition (WfMC), the World Wide Web
Consortium (W3C) and the Organization for the Advancement of Structured Information
Standards (OASIS) proposed metamodels for business process and workflow process
modelling. However, their submodels for OSA representation show limited power of
expression. This fact restricts whole workflow project accuracy since the workflow
process may not represent the real business process as it is executed in the organization.
The lack of a business process metamodel linking business (sub)process with OSA was
one of the major motivations for the development of the Transactional Metamodel of
Business Processes (TMBP) proposed in this paper. TMBP is an extension of the
Transactional Model of the Workflow Processes – TMWP [2] with support to OSA. It
can be employed as a metamodel for business process modelling from the reuse of
business (sub)process patterns based on OSA. This should improve not only the quality
but also the performance of whole workflow project.
The rest of the paper is structured as follow. Section 2 describes TMBP and Section 3
addresses conclusions and research directions.
2 A Transactional Metamdel for Business Process Modelling (TMBP)
TMBP is described through the Unified Modelling Language (UML) notation [3]. We
opted for UML because it provides a wide range of modelling resources, such as class
diagram, use case diagram and activities with actions diagram [4] required to represent
all singularities of TMBP. Accordingly, the metamodel is a package composed of five
subpackages: PBusinessProcess, POrganizational, PResource,
PRouting and PCatalogue (see Figure 1).
Transactional Model of Business Process (TMBP)
POrganizational PResource
PCatalog PBusinessProcess PRouting
Fig. 1. Transactional metamodel of business process
2.1 Organizational Package
Roles (as illustrates Figure 2) can be differentiated between functional (e.g., to
formulate rules; to review and approve documents) and organizational roles (e.g.,
manager, director, president of a company) [5]. An organizational role is linked with
197
actor (task performer). Additionally, it is associated with organizational unit
(e.g., department, division). Nevertheless, it is a generalization of functional role. A
functional role is associated with skill (e.g., to know how to program in Java) and
competence (e.g., may sign orders > than $ 20.000).
An organization is an aggregate of organizational units. Each
organizational unit may be related to other organizational units. The cardinality (0,*)-
(0,*) in the auto-relationship in the OrganizationalUnit class is feasible, hence it
express multi-dimensional organizations (e.g., matrix-structures). Finally, every
organizational unit has a set of OSA.
Actor Organization StructuralAspect
subordinated of 0..* 0.. *
0..*
0..* 0..*
OrganizationalRole OrganizationalUnit
0..* 0..* 0..*
Competence Functional 0..* 0..* Skill
0..* 0.. *
Fig. 2. Organizational package
2.2 Resource Package
A resource (see Figure 3) is an artifact required for a task execution. It can be: a
tool (e.g., word processor, printer) or an or an item type of some item type (e.g.,
document). Depending on its type an item can have a more complex structure (class
SructuredItemType in Figure 3). In this case it is recursively composed of sub-
items ņ e.g., an environment process composed of several documents (sub.itens).
Resource
Tool ItemType StructuredItemType
Fig. 3. Resource package
2.3 Routing Package
Routing along particular branches determines which task needs to be performed and in
which order. There are several proposals concerning routings between tasks/activities
(e.g. [6], [7], [2]). We apply the Wil van der Aalst workflow patterns in the TMBP
Routing Workflow patterns [6]. Due to space limitation in this paper we don’t present all
UML diagrams concerning the routings proposed by Aalst. A detailed explanation can
be found in [8]).
198 Lucineia Heloisa Thom, Cirano Iochpe, Bernhard Mitschang
2.4 Business Process Package
In Figure 4 each business process transforms an item type from an initial
state into a final state. Transformations may be decomposed in smaller transformations,
where each of them corresponds to a change in the item state. When there are no more
transformations to be performed, the item reaches its final state and the organization
reaches the aim of its business.
Each business subprocess can involve several business transactions, hence
also several actors. However, the set of organizational structure aspects (obtained
through the OrganizationalUnit class) and their values should remain constant in
the business subprocess. A business subprocess can involve one or more
organizational units if their structural aspects do not vary. Each business
subprocess has only one responsible. The abstract class subflow is just a modelling
structure.
Due to its possible high complexity, a business process can be recursively decomposed
in to business subprocess, up to the business transaction level. Under the organization’s
point of view, a business transaction is the smallest business process unit of work. Each
business transaction is responsible for one of the item transformations. A business
transaction can be decomposed in to a partial order of atomic tasks and its whole
execution is under the responsibility of a single actor. Nevertheless, a business
transaction can receive as inputs several resources to be used in task executions.
Additionally, it is a generalization of task. A task is a description of a piece of work that
forms one logical step within a process. It can be a simple task or a supertask (a
composition of simple tasks).
BusinessProcess work item ItemType
(from PResource)
0..*
1
Actor
Subflow (from POrganizational)
1
responsible
0..*
SubProcess
BusinessTransaction inputs
0..*
0..* 0..*
responsible
0..* Resource
OrganizationalUnit (from PResource)
(from POrganizational)
Task
Skill
SimpleTaskType
(from POrganizational)
0..* 0..* 0..1
0..*
Routing
0..1 next SimpleTask SuperTask
(fro m PRo uting )
0..*
msg
0..1 0..*
previous
Manual Automatic
Fig. 4. Business process package
199
2.5 Catalogue Package
Catalogue package (see Figure 5) describes the classes used by a catalogue manager in
the selection of the best design pattern from a catalogue of business suprocess patterns
(The patterns are available in [9]), as basis to model a certain business process. The
selection concerns the identification of a set of parameters obtained from TMBP, such
as: kind of business subprocess, value of OSA (obtained via
OrganizationalUnit class and its associated classes) on which this business
subprocess depends and kind of work item (ItemType class) used in the business
subprocess. Note that the set of parameters may vary according to the kind of business
subprocess.
After this, a catalogue builder adapts the selected pattern to the specific workflow
model being developed. For each business transaction it must include: the work item
manipulated, the input resources its internal tasks use, the actor responsible for tasks
execution and the partial order among them.
requires
SubProcess <>
(from PBusinessProcess) generates PatternCatalog
0..*
responsible requires
0..*
<> <>
OrganizationalUnit
CatalogManager CatalogBuilder
(f ro m POrgani za ti ona l)
Fig. 5. Catalog package
3 Conclusions and Future Work
This paper presented a transactional metamodel for business process modelling based on
OSA. With the metamodel we expect to provide a bridge between OSA and business
(sub)process, minimizing the complexity of business process modelling and at the same
time improving the efficiency and quality of it. Furthermore, through business pattern
reuse, we expect to increase the productivity within the workflow modelling process.
Due to space limitation, in this this paper we don’t present in details the TMBP
methodology for business process modelling. Information about is in [10]. The
methodology is composed by tree steps:
(1) creation of business process models based on TMBP. The task of this step is the
creation of business process models as described in section 2.5.
200 Lucineia Heloisa Thom, Cirano Iochpe, Bernhard Mitschang
(2) automatic generation of BPEL4WS processes corresponding to the business
process models defined in step 1. Explanation about why we decided by BPEL4WS
in favor of other languages as well as an example of a TMBP business process
described as BPEL4WS process can be found in [10]. We developed some mapping
rules between the business process patterns represented through activity with action
diagram from UML and BPEL4WS. This rules are also presented in [10].
(3) execution of BPEL4WS process through workflow engine. This Step is still under
research.
As future work we consider to extend TMBP with process decomposition aspects in
order to better identify to which organizational aspects different parts of the business
process are related to. E.g., technology dependent subprocess versus informational
subprocess. Additionally, investigate deeper the way patterns should be represented as
well as stored, and queried in the pattern catalogue as well as to look for adequate
inference engines that can answer queries to the catalogue with minimum human
interference. Furthermore, we are looking forward to validate TMBP in real case studies.
References
1. Davis, M. R.; Weckler, D. A. A Practical Guide To Organization Design. Boston: Crisp
Publications, 1996.
2. Grefen, P.; Pernici, B.; Sànchez, G. Database Support for Workflow Mangement: The WIDE
Project. Boston: Kluwer Academic, 1999.
3. Fowler, M.; Scott, K. UML Distilled: a brief guide to the standard object modelling language.
2nd ed. Reading: Addison-Wesley, 2000. 185 p.
4. Object Management Group. UML 2.0 Superstructure Specification. OMG. Final Adopted
Especification, Aug. 2003. Available at:
. Visited on Oct. 2004.
5. Neumann, Gustaf; Strembeck, Mark. A Scenario-driven Role Engineering Process for
Functional RBAC Roles. 2002. Available at: . Visited on Nov. 2004.
6. Aalst, W. van der et al. Et al. Advanced Workflow Patterns. In: International Conference On
Cooperative Information Systems, COOPIS, 7., 2000. Proceedings… Berlin: Springer-
Verlag, 2000. p. 18-29. (Lecture Notes in Computer Science, v. 1901).
7. Workflow Management Coalition. Terminology &Glossary. Bruxelas, Feb. 1999. 65p.
Available at: . Visited on Nov. 2004.
8. Thom, Lucineia H. TMPB: A Transactional Model for Business Processes Modeling With
Support To Organizational Structure Aspects. Porto Alegre: PPGC-UFRGS. 2004. (Technical
Report).
9. Thom, L.H.; Iochpe, C. identifying Patterns Workflow Design Relying on Organizational
structure Aspects. In: International Conference On Enterprise Information Systems, 5., 2003,
Angers. 6., 2004. Proceedings… Porto (Portugal): ICEIS, 2004.
10. Thom, Lucineia; Iochpe, Cirano, Mitschang, Bernhard. Improving the Workflow Project
Quality Via Business Process Patterns Based on Organizational Structure Aspects. Proc. of
the 1st GI Workshop XML4BPM 2005 - XML for Business Process Management at BTW
2005, Karlsruhe Germany, March 2005.