INTEGRATING A PATTERN CATALOGUE IN A

BUSINESS PROCESS MODEL

Lucinéia Heloisa Thom, Cirano Iochpe

Universidade Federal do Rio Grande do Sul, Instituto de Informática

Av.Bento Conçalves, 9500, Postal Box 15064, 91501-970, Porto Alegre – RS – Brazill

Keywords: Organizational Structure Aspects,

Business Process, Pattern Catalogue, Integration and Transactional Model

of Business Process

Abstract: This paper proposes the Tra

nsactional Model of Business Process (TMBP), an extension of the

Transactional Model of Workflow Processes (TMWP) proposed in the context of the Workflow on

Intelligent Distributed database Environment (WIDE). The TMBP mainly includes elements, such as, a

Pattern Catalogue that make possible to create business sub-processes (BSP) from the reuse of BSP patterns

based on structural aspects.

1 INTRODUCTION

According to (Davis, 1996), the overall

organization should be structured according to the

Business Process (BP) it wants to carry out. The

task of structuring an organization involves the

assignment of specific values to a set of structural

aspects (e.g.: differentiation, communication

structure, scalar chain, decision-making structure

and coordination mechanism).

Once the organization’s origin is in its BP, its

structural aspe

cts are present in its BP. Thus, in

order to understand a BP it is useful to know the

structural aspects of the organization which

performs it (Iochpe, 2002).

Organizations reach their business

objectives

(products and services) by executing their BP.

Basically, a BP can be understood as a partial

order (<

) of tasks (T

, i=1, ...n), where each of

these tasks contribute in a stage of the process.

In Workflow systems, a workflow process

(WP) au

tomates the BP, which employs a WP

model to represent all singularities of BP needed

for their automation. There are many WP models

(Grefen, 1999), (Casati, 1995), (Leyman, 2000).

However, these modes present little support for the

structure aspects of an organization. This commits

the workflow project accuracy, once such WP may

not reflect the reality of BP performed in the

organization.

We have noticed the fact above mentioned

mainly during

the accomplishment of a case study

with a Brazilian Governmental Organization (BGO)

(Thom, 2003). In that case study, we have identified a

set of workflow patterns where each pattern is based

on the relationship among one or more structural

aspects of the BGO and its workflow sub-processes.

The lack of a BP model with support to

ganizational structure aspects (such as the ones

above mentioned) as well as the lack of a BP model

that enable the reuse of Business-Subprocess (BSP)

patterns were the major motivations for the

development of the Transactional Model of Business

Processes (TMBP) proposed in this paper. TMBP is

mainly an extension of the Transactional Model of

Workflow Processes (TMWP) – developed in the

context of the Workflow on Intelligent Distributed

database Environment (WIDE) project (Grefen, 1999)

– with support to structural aspects of the organization.

We have opted to extend TMWP because, from

models we studied, the Workflow Management

Coalition (WfMC) (WMC, 1995) and WIDE (Grefen,

1999) models are the ones that mostly take into

consideration structural aspects of the organization.

WfMC model, however, was created with the aim of

being a reference model that makes feasible the

interchanging of process definitions among different

workflow products.

The TMBP can be employed as a reference model

for BP m

odeling. Trough the integration of a Pattern

Catalogue of BSP, it enables the construction of BSP

from the reuse of BSP patterns based on structural

aspects organization. The BP designer would not be

compelled to begin the BP modeling from scratch,

651

Heloisa Thom L. and Iochpe C. (2004).

INTEGRATING A PATTERN CATALOGUE IN A BUSINESS PROCESS MODEL.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 651-654

DOI: 10.5220/0002619606510654

 SciTePress

once the patterns are solutions that were already

tested and used, whose efficacy was proved by

domain experts (Gamma, 1995).

The present paper is organized as it follows:

Section 2 presents the TMBP and also its

integration with a Pattern Catalogue of BSP.

Section 3 describes how the TMBP can be used in

practice. Last, but no least, Section 4 brings

conclusions as well the future works.

2 EXTENSION OF TMWP

The original TMWP can be found in (Grefen,

1999). We opted to describe the TMBP (Figure 1)

through the Unified Modeling Language (UML)

notation (Fowler, 2000) and not through the

Enhanced-Entity-Relationship (EER) notation,

originally used in the TMWP because UML has

modeling resources (OMG, 2003) necessary to

represents the BMBP in a fine-grained level.

Transact ional Business Process Model (TBPM)

PBusinessProcess

PCatalog

POrganiz ational

PResource

PRouting

Figure 1: TMBP Package

2.1 Business Process Package

In the PBusinessProcess (Figure 2), each BP

transforms an item (see Section 2.3) from an initial

state into a final state. Transformation of an item

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 done, the item reaches its final state.

Due to its possible high complexity, a BP can

be recursively decomposed in BSP, up to the

business transaction level (BT). The BT is the

smallest work logic unit of a BP. One can imagine

that each BT is responsible for one of the item

transformations. A BT can be decomposed in a

partial order of atomic tasks. Each BT is under the

responsibility of an actor and can receive as inputs

several resources used during the tasks execution.

Each BSP can involve several BTs and

different kinds of actors. However, the set of

structural aspects of the organization and their values

should remain constant in the BSP. Each BSP can

involve one or more Organizational Units (OU), since

their structural aspects do not vary. A BSP must have

only one responsible. A simple task in TMBP is

associated to skills class, once in certain stages of the

BP it may be necessary to identify which are the

minimal skills the actor responsible for the task should

have.

Task

Resource

(from PResource)

BusinessTransaction

0..*

0..n

0..*

0..n

inputs

ActorType

(from POrganizational )

0..n

responsible

It em

status

(f ro m PRe so u rce )

Busi nessProcess

0..n

work it e m

Routing

(fr om P Rou ti n g)

SimpleTask

0..n

0..1

0..n

0..1

previus

0..n

0..1

0..n

0..1 next

Si mpleTas kType

0..*

0..1

0..*

0..1

Skill

(f ro m POr ga ni z a ti on al )

0..*

Organ izationalUnit

(from POrganizational )

Subflow

SubProcess

0..*

responsible

SuperTask

Figure 2: Classes of the PBusinessProcess

2.2 Organizational Package

In the POrganization package (Figure 3) an actor is

the one that performs a task. A human actor has a

position in the organization that identifies his/her role.

Each actor is of one type and is associated to an OU.

The type of actor identifies abstractly a certain skill,

needed for the execution of a task. Each type can be

assigned to a set of actors. Note that an actor may be

of different types yet it occupies the same post.

An organization is an aggregate of OUs. Each OU

may be related to other OUs, where such relationships

may help in the identification of the organization’s

organizational chart. Every OU has a set of structural

aspects, such as the ones described in (Thom, 2003).

Machine

Hum a n

position0..1

0..*

0..1

subordinate of

0..*

ActorType

Skill

0..n

Organization

StructuralAspect s

OrganizationalUnit

Actor

0..*

Figure 3: Classes Diagram of the POrganizational

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

652

2.3 Resource Package

A resource is involved in the execution of a task.

PResource (Figure 4) distinguishes three kinds of

resources: Raw material - all that is used in the

performance of a task; Tool - an instrument the

actor uses in the task execution and; Item - while a

“work item” is a business object.

An item may be of a kind and may have a

structure (Product Structure). In the case it has a

structure, the item is recursively composed of sub-

items. For example, if the BP’s final objective is to

build a chair, the chair, per se, is the final product,

and its pieces (back, sit and legs) the items.

Resource

RawMat erial

Tool

Item

stat us

ProductStructure

ItemType

Figure 4: Classes Diagram of the PResources

2.4 Routing Package

Routing along particular branches determines

which task needs to be performed and in which

order (Aalst, 2002). The routings presented in the

PRouting are based on the WfMC (WfMC, 1995).

Routing

Sequential

Parallel

Selective

Choice

Iteration

And- Split

And- Join Or-Split

Or-Join

XOR-Split

XOR-Join

Figure 5 : Classes Diagram of the PRouting

2.5 Catalogue Package

PCatalogue package (Figure 6) describes the

main classes involved in the selection of the best

design pattern from a Catalogue of BSP patterns,

as basis to model a certain BSP one wants to

accomplish. The Catalogue manager selects a BSP

pattern based on a set of parameters (which may

vary according to the kind of BSP) that can be

obtained from the TMBP.

After the pattern selection, a BSP builder

would extend that pattern with information on the

partial order of BT and, for each BT would

include: the work item it manipulates, the input

resources its internal tasks uses, the kind of actor

responsible for tasks execution and the partial order

among them. We highlight that, in order to extend the

BSP pattern the builder would need some input

parameters.

Semantically, the PatternCatalogue class uses a

possibility of UML that is modeling “dynamic tasks”

in static diagrams such as the classes diagram. Classes

like “dynamic task” represent processes that receive

the set of input parameters and generate output data.

The PatterCatalogue class receives a sub-process as

inputs and an organizational unity involved in its

execution.

input

Catalog Manager Cat alogBuilder

SubProcess

(from PBusinessProcess) PatternCatalog

<<process>>

ge nerates

Or ganizationalUnit

(from POrganizational)

responsible

input

Figure 6: Classes Diagram of PCatalogue

3 USING THE CATALOGUE

PAKAGE IN PRACTICE

To describes how the PCatalogue package can be

used in practice let’s imagine that the patterns

Catalogue contains the Approval BSP such as the one

detailed in (Thom, 2003). Additionally, lets consider

the RUP method - Rational Unified Process (Kruchten,

2001) to demonstrate how it can be instantiated.

Initially the use cases that define the main

activities necessary to build BSP from the reuse of

BSP patterns are described.

The activities with actions diagram of UML 2.0

(OMG, 2003) was used to represent the patterns that

are expanded (contemplated) by use cases. We opted

to use this diagram mainly because it gives more

emphasis to the semantics definition rather than to the

syntax. Consequently, it makes easier future

implementation in almost every programming

language. Last, but not least, the diagram allows the

specification of the BP in a fine-grained level.

3.1 Modeling of the Approval Sub-

process Base on Design Patterns

Creation of a BSP from the reuse of approval patterns

involves the use cases Figure 7 shows. The Catalogue

manager selects the approval pattern according to the

value of the decision-making structure (Davis, 1996).

As input parameters it receives the kind of sub-process

(e.g.: approval), the value of the decision-making

structure (e.g.: centralized) and the kind of work item

(e.g.: document).

INTEGRATING A PATTERN CATALOGUE IN A BUSINESS PROCESS MODEL

653

Selects Approval P a tt ern based on t he

va lue of the decision makestructure

Generate Si gnatures Hierarchy

ExtendsApproval Subprocess Pattern

<<include>>

Figure 7: Uses Cases Diagrams for the Creation of BSP

Based On Approval Patterns Reuse

Based on the pattern selected the pattern

builder expands the BSP pattern. It uses as input

parameters: the pattern selected; the organizational

unit and; the kind of work item. As output

parameter it presents the complete pattern

(expansion) of BSP with transactions (Figure 8).

ToReviseItem

approve

disapprove

Item

ToRecordSignature

ToAnnulPreviousSignature

Superior Positions

Figure 8: Approval Pattern for the Organizational Unit

with Centralized “decision-making structure”

4 CONCLUSIONS AND FUTURE

WORKS

The organization of work, both within and between

companies, is becoming more and more complex.

This is why information systems have been

developed to support the management of process

and their automation (Aalst, 2002). Workflow

systems associated to other technologies (e.g.:

internet, electronic documents management and

database systems) make such automation feasible.

One of the most important stages in the

development of a workflow system is modeling of

BP executed in the organization. In this paper we

observed that the existents models for WP design

do not have enough support for the structural

aspects of the organization. This constraint may

commit the accuracy and efficiency of the

Workflow Project.

Aiming at approaching this constraint, we

proposed the TMBP an extension of TMWP to

support the structural aspects of the organization

and the reuse of BSP patterns.

The paper has shown that the patterns stored in

the Pattern Catalogue are selected by a Catalogue

manager and expanded by a BSP builder.

Future works could preview the development of a

wizard to support BSP modeling, based on the

semantics of the PCatalogue package. For example,

the FORO-WF (Foro, 2002) tool, based on the WIDE

model could be modified to support TMWP extension.

Last, but not least, new extensions to the TMBP may

come to be necessary, as new patterns are identified.

Patterns that would need other modeling elements for

their expansion in a BP model, besides those proposed

in the TMBP. This flexibility of TMBP if

fundamental, once as mentions in (Aalst, 2002), there

are many kinds of BPs performed in organizations,

which may be related to different structural aspects.

REFERENCES

Aalst, W. V. H., Hee, K. V. 2002. Workflow Management:

Models, Methods, and Systems. The MIT Press, London.

Casati, F. et al. 1995. Conceptual Modeling of Workflows.

In: 14

OOER, International Object-Oriented And

Entity-Relationship Modeling Conference. Australia.

341-354.

Davis, M. R., Weckler, D. A.1996. A Practical Guide To

Organization Design. Crisp Publications, Boston.

FORO. 2002. Foro-WF: A White Paper. SchlumbergerSema

Spain.

Fowler, M. Scott, K. 2000. UML Distilled : a brief guide to

the standard object modeling language.Addison-Wesley,

edition. 185 p. : il.

Gamma, H. E., Johnson, R., Vlissides, J. 1995. Design

Patterns: Elements of Reusable Object-Oriented

Software. Addison-Wesley.

Grefen,P., Pernici, B., Sánchez G., 1999. Database Support

for Workflow Mangement: The WIDE Project. Kluwer

Academic Publishers, Boston.

Iochpe, C., Thom, L. H. Inferring Aspects Of The

Organizational Structure Through Workflow Process

Analysis. 2002. In 4

International Conference On

Enterprise Information Systems. ICEIS Press, Ciudad

Real.

Kruchten, P. 2003. What is the Rational Unified Process?

Leyman, F., Roller, D. 2000. Production Workflow: concepts

and techniques. 2

edition. Prentice-Hall, New Jersey.

Mintzberg, H. 1995, Criando Organizações Eficazes:

estruturas em cinco configurações. Atlas, São Paulo.

Object Management Group. 2003. UML 2.0 Superstructure

Specification. OMG Final Adopted Especification.

Thom, L. H., Iochpe, C. 2003. Identifying Patterns o

Workflow Design Relying on Organizational Structure

Aspects. 5th International Conference On Enterprise

Information Systems. ICEIS Press Angers.

Workflow Management Coalition. 1995. The Workflow

Reference Model.

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

654