Padres de Workflow para Reuso em Modelagem de

Processos de Negcio
Lucinia Heloisa Thom1, Carolina Chiao1, Cirano Iochpe 1,2
1

Instituto de Informtica Universidade Federal do Rio Grande do Sul (UFRGS)

Caixa Postal 15.064 91.501-970 Porto Alegre RS Brasil

Empresa de Tecnologia da Informao e Comunicao de Porto Alegre (PROCEMPA) Av.

Ipiranga, 1200 Porto Alegre CEP 90160-091 RS Brasil
{lucineia,cciao,ciochpe}@inf.ufrgs.br

Abstract. For its reuse advantages, workflow patterns are increasingly

attracting the interest of both researchers and vendors. However, patterns
based on recurrent functions frequently found in business processes have not
been extensively explored. In this paper we present and classify a set of
workflow patterns where each pattern represents a recurrent business
function. Through the mining of 190 workflow processes of more than 10
different organizations we evidenced the existence of most of the workflow
patterns with high support in the workflow processes analyzed. Moreover, it
became clear through this study that the set of patterns is both necessary and
enough to design all 190 processes that were investigated.
Resumo. Devido as suas potenciais vantagens, padres de workflow tm
atrado a ateno de pesquisadores e da indstria de software. Porm,
padres com base em funes lgicas recorrentes em processos de negcio tm
sido pouco explorados. Neste artigo apresentamos e classificamos um
conjunto de padres de workflow para modelagem de processos. Cada padro
representa uma funo recorrente em processos de negcio. Atravs da
minerao de 190 processos de workflow de mais de 10 organizaes
diferentes constatamos a existncia da maioria dos padres com alto suporte
nos processos de workflow analisados. Alm disso, o estudo mostrou que o
conjunto de padres suficiente e necessrio para modelar todos os 190
processos investigados.

1. Introduo
Um processo de negcio compreende o conjunto de um ou mais procedimentos ou atividades
relacionadas, as quais, coletivamente, realizam um objetivo de negcio no contexto de uma
estrutura organizacional [WfMC 1999]. Portanto, atravs da execuo dos processos de
negcio que as organizaes realizam seus propsitos.
Nos ltimos anos, para se manterem competitivas, muitas organizaes tm explorado
tcnicas da abordagem de gesto por processos. Tal abordagem recebeu impulso adicional
atravs da norma ISO 9001:2000, a qual define que a organizao deve ser retratada por

seus processos de negcio principais e no pelo seu organograma. A gesto por processos
associada tecnologia de workflow pode trazer diversos benefcios organizao, tais como:
(a) descrio precisa e no ambgua dos processos de negcio existentes; (b) melhoria na
definio de novos processos; (c) maior eficcia na coordenao do trabalho entre diferentes
agentes; (d) obteno, em tempo real, de informaes precisas sobre o andamento dos
processos e; (e) padronizao dos processos executados, de forma manual ou automatizada,
pela organizao.
A tecnologia de workflow, atravs da automatizao dos processos de negcio
executados na organizao, proporciona no apenas a reduo de custos, tempo, erros e
redundncia na execuo dos processos, mas tambm maior controle sobre os mesmos, o
que leva ao incremento da qualidade dos processos, de seus resultados e da organizao
como um todo. Devido a estes e outros fatores crescente o interesse acadmico e cientfico
por sistemas de workflow e pelo gerenciamento de processos de negcio (BPM).
Processos de negcio e respectivos modelos de workflow frequentemente incluem
uma variedade de fragmentos, os quais podem ser entendidos como atividades de bloco com
semntica especfica e bem definida. Em particular, um fragmento (ou funo recorrente em
processo de negcio) pode ocorrer diversas vezes em uma mesma definio de processo
[Thom 2006a], [Thom 2006b). Durante a execuo do processo, por sua vez, diferentes
cpias de um mesmo fragmento podem apresentar tanto os mesmos valores de parmetros
como valores diferentes. Como exemplo, considere o processo de aprovao de empenho de
verbas de uma organizao do setor varejista na Figura 1. O processo inclui as seguintes
atividades: a) necessita aprovao complementar; b) avalia empenho de verbas e; c) avisa
administrador sobre atraso. Este processo contm fragmentos relacionados a funes
recorrentes de processos (ou padres) tais como deciso (atividades a), aprovao
(atividade b) e notificao (atividade c).

Figura 1. Exemplo de processo de aprovao

Embora estes fragmentos possam ser semanticamente caracterizados de maneira precisa,

existem poucos estudos relacionando-os com padres de workflow [Bradwhaw 2005].
Geralmente, eles so redesenhados para todas as aplicaes de workflow. Tal procedimento
pode ser considerado ineficiente, passvel de erros sob a perspectiva de manuteno.
Tambm no encontramos pesquisas evidenciando a existncia destes padres em aplicaes
reais de workflow, assim como a necessidade e completude destes para a etapa de
modelagem [Flores 1988], [Medina-Mora 1992], [Malone 2004], (Muehlen 2002],

[Bradshaw 2005]. Mais ainda, as ferramentas contemporneas para modelagem de workflow

no provm funcionalidades para definio, consulta e reuso de padres.
Neste artigo propomos um conjunto de padres de workflow. Cada padro representa
uma funo recorrente em processo de negcio (tais como as ilustradas na Figura 1). Alm
disso, apresentamos os principais resultados de um estudo de caso, onde 190 processos de
workflow executados em diferentes organizaes foram minerados. O principal objetivo da
minerao foi medir a freqncia com que cada padro de workflow ocorre no conjunto de
processos investigados. Isso foi feito para evidenciar a existncia e probabilidade de reuso
dos padres em processos de workflow reais.
O restante deste artigo est organizado como segue: A Seo 2 revisa os principais
trabalhos existentes na rea de padres de workflow, comparando-os com a abordagem
sendo proposta neste artigo. A Seo 3 descreve os principais tipos de processos de negcio
encontrados na literatura. Com base nesta descrio, na Seo 4 apresentamos um conjunto
de padres de workflow para modelagem de processos de negcio e workflow. Na Seo 5
apresentamos os principais resultados do estudo de caso realizado com o objetivo de
evidenciar a existncia e completude dos padres de workflow para modelagem de
processos. A Seo 5 conclui o artigo e apresenta perspectivas de trabalhos futuros.

2. Trabalhos Correlatos
Devido as suas potenciais vantagens, padres de workflow tm atrado a ateno de
pesquisadores e da indstria de software. Ns ltimos anos, diversas abordagens tm sido
propostas. Em [Aalst 2002] so descritos 21 padres de workflow para controle de fluxo
(e.g., seqencial, paralelo, condicional). Tais padres so teis tanto para a definio de
workflows, como para validar o poder de expresso das linguagens e ferramentas de
workflow [Aalst 2003].
Recentemente, um conjunto de 39 padres de dados foi proposto em [Russell
2004a]. Os padres descrevem diversas maneiras, atravs das quais, dados podem ser
representados em definies de workflow. Em outro trabalho, o autor prope um conjunto de
padres de recursos, onde cada padro descreve a representao e utilizao de um recurso
especfico em workflow [Russell 2004b]. Russell (2006) prope, ainda, uma framework para
classificao de padres com base em tratamento de excees em sistemas de workflow. O
framework vem sendo utilizado para verificar a habilidade de sistemas de workflow para o
tratamento de excees.
Em [Bradshaw 2005] so propostos padres de interao entre um processo BPEL
(Business Process Execution Language) e outra aplicao. Exemplos destes padres so
One-Way Message e Asynchronous Interaction with Timeout. Estes padres so similares
a alguns dos padres sendo propostos neste artigo (ex.: unidireional e bi-direcional
performativo). A Oracle BPEL Process Manager prope uma biblioteca de padres de
workflow. Com base em requisitos especficos do negcio, o usurio escolher o melhor
padro disponvel na biblioteca.
Alm destas abordagens, existem diversas outras tais como o Handbook de
Processos do Massachusetts Institute of Technology (MIT) [Malone 2004], a biblioteca de

processos desenvolvida no contexto do projeto ECOMOD [Frank 2006], as linguagens de

padres propostas em [Cooplien 2004], assim como os padres de negcio propostos por
Eriksson (2001).
A maioria das abordagens revisadas nesta Seo so relevantes tanto para a
implementao de sistemas de workflow, como para a definio de linguagens de modelagem
de workflow. No entanto, elas respondem parcialmente questo sobre quais funes (tais
como as ilustradas na Figura 1) o projetista deve considerar repetidamente em vrios modelos
de processos. Mais ainda, tais abordagens no exploram a completude e necessidade de tais
padres para a modelagem de processos de negcio e workflow.

3. Tipos de Processos de Negcio

Processos de negcio so prevalentes em praticamente todos os domnios de aplicao.
Exemplos proeminentes incluem processos logstico, financeiro e informativo,
respectivamente. Enquanto processos logsticos (ou processos materiais) so executados
com o objetivo de manipular objetos fsicos (ex.: transporte de mercadorias) [Medina-Mora
2002] ou com o objetivo de prover algum servio (ex.: manufatura de um produto, assim
como compra e venda de mercadorias), processos financeiros so executados quando
valores monetrios so trocados entre duas partes. Cada um destes processos
acompanhado de um processo informativo, o qual representa o fluxo de dados causado
pelos processos logstico e financeiro [Muehlen 2002].
Processos organizaes, dificilmente, so entidades homogneas executados por
indivduos em sua totalidade. Geralmente, diferentes partes so envolvidas em um processo. A
comunicao entre os participantes de um processo feita atravs da troca de mensagens
(processo comunicativo) [Flores 1998], [Geurts 2004], [Muehlen 2002]. Basicamente, uma
troca de mensagem envolve duas partes: um solicitante ou produtor (envia a mensagem) e um
receptor ou consumidor (recebe a mensagem).
Neste contexto, zur Muehlen (2002) classifica mensagens em unidirecional e bidirecional. Mensagens unidirecionais so utilizadas tanto por um solicitante para solicitar a
execuo de uma atividade a um receptor (tambm chamada de mensagem ou comunicao
performativa unidirecional), ou por um receptor para notificar um solicitante (mensagem
notificativa). Mensagens bi-direcionais formam um par solicita/responde, onde o solicitante
solicita a um receptor que este execute uma atividade e o responda subsequentemente
(comunicao ou mensagem bi-direcional performativa) ou um receptor solicita uma
informao ao solicitante (mensagem informativa).
No contexto deste artigo, as atividades de um processo informativo so as
mensagens, as quais implementam o fluxo de dados da organizao gerado pelos processos
logstico e financeiro nesta executados. Por exemplo, em um processo de aprovao a
atividade que solicita a reviso de um documento gera uma mensagem performativa bidirecional (um solicitante solicita que um revisor execute a atividade).
importante observar que cada processo informativo ou aplicativo pode estar
relacionado a um processo decisrio, ou seja, um processo cognitivo a partir do qual um
curso de atividades selecionado com base em um conjunto de alternativas. Em nvel de

aplicao, este se refere a uma tomada de deciso, tal como uma aprovao ou reprovao
em um processo de aprovao. Em nvel do sistema de informao este se refere a um
controle de fluxo (roteamento do workflow) [Aalst 2002].
3.1 Classificao dos Padres de Workflow
Esta Seo apresenta os processos descritos na Seo 3, os quais neste artigo so
apresentados como padres de workflow organizados em 3 categorias de padres.
Realizamos esta classificao com base em caractersticas especficas dos processos (ex.:
dependncia de aspectos da estrutura organizacional, nvel de abstrao, dependncia do
domnio da aplicao).
1. Padres com base em aspectos da estrutura organizacional. Esta categoria inclui
padres relacionados a aspectos estruturais especficos (ex.: centralizao da tomada
de deciso, padronizao de habilidades, superviso direta). Exemplos destes
padres so aprovao e retirada de dvidas.
2. Padres com base no domnio de aplicao. Esta categoria inclui padres
relacionados a domnios de aplicao especficos. Ambos, padro financeiro (com
base no processo financeiro) e padro logstico (com base no processo logstico)
so exemplos de padres desta categoria.
3. Padres com base em funes recorrentes em processos de negcio. Esta
categoria inclui padres relacionados a funes genricas e recorrentes, isto ,
qualquer processo de negcio ou workflow pode incluir tais padres,
independentemente do domnio de aplicao. Exemplos de padres desta categoria
so o padro performativo unidirecional e bi-direcional, padro informativo,
padro notificativo e padro decisrio.

4. Exemplos dos Padres de Workflow

No contexto deste artigo um padro de workflow a descrio de uma funo recorrente
encontrada com freqncia em processos de negcio (ex.: notificao, aprovao, deciso,
solicitao de execuo de tarefa) [Thom 2006a], [Thom 2006b]. O conjunto de padres de
workflow proposto neste artigo foi derivado de um estudo extensivo com base na literatura e
em um estudo sobre as relaes entre aspectos da estrutura organizacional e (sub-)processos
de workflow [Thom 2003], [Thom 2005].
Conforme os padres de definio de workflow da Workflow Management
Coalition, cada padro de workflow sendo proposto neste artigo pode ser representado
como uma atividade de bloco [WfMC 2005]. O conceito de atividade de bloco apropriado
para representar os padres, pois garante que todas as atividades definidas dentro de um
bloco devem ser executadas por completo para que o workflow continue a execuo.
Contudo, os padres requerem a representao de parmetros de entrada e sada e o
conceito de atividade de bloco no suporta parmetros, a perspectiva de transao da teoria
de seriabilizao aplicada [Bernstein 1987]. Assim, parmetros de entrada so
representados como operaes de leitura em base de dados (one-time-only) e parmetros de
sada como operaes de gravao em base de dados (one-time-only).

As prximas Sees apresentam exemplos de padres como diagramas de atividade

UML (utilizando a notao 2.0). O Visual Paradigm para a UML Community Edition, o
qual tem como base a UML 2.0 foi utilizado como editor para a modelagem dos padres. As
Figuras de 3 a 11 devem ser interpretadas conforme a legenda apresentada na Figura 2.

(a) Nodo inicial indica o

incio de um processo
(e) Join

(b) Ao
atividade atmica

(f) Controle de
Fluxo

(d) Fork

(c) Deciso
(h) Nodo Final

(g) Swimlane

(i)

Figure 2. Notao da UML 2.0

4.1 Padro Aprovao de Documentos

O padro aprovao de documentos constitudo por um conjunto de avaliaes (uma ou
mais), onde cada avaliao realizada por um papel organizacional (ex.: supervisor, gerente,
chefe de departamento). O processo de aprovao concludo quando todos os papis
organizacionais finalizarem suas revises ou um destes papis no concordar com o contedo
do documento. A figura 3 descreve o padro de aprovao como uma atividade de bloco.
Como ilustrado na figura 3, o papel organizacional revisor realiza a reviso do
documento que ir resultar na reprovao ou na aprovao deste. A atividade de reviso do
documento (Realiza reviso do documento) executada repetidas vezes (em
paralelo ou em seqncia) conforme o nmero de papis organizacionais especificados ou at
que uma reprovao ocorra. Geralmente, o nmero de papis organizacionais relativo ao
nvel de centralizao com respeito tomada de deciso.

Figure 3. Padro Aprovao de Documentos

4.2 Padro Retirada de Dvidas

Os resultados de atividades mais complexas nem sempre podem ser padronizados, fazendo
com que a organizao padronize as habilidades dos executores. Por este motivo, os mesmos
tornam-se, muitas vezes, especialistas em pontos especficos do processo de trabalho. A

padronizao de habilidades implica em uma ao de retirada de dvidas (com algum

especialista da organizao) no contexto de uma atividade complexa (Mintzberg 1995).
O padro para retirada de dvidas consiste na identificao de determinados atributos
(habilidades) para a execuo de uma atividade especfica. Com base nas habilidades
identificadas, um papel organizacional e seu ator correspondente so alocados tanto para a
execuo da tarefa quanto para responder solicitao de retirada de dvidas dentro do
contexto de execuo da atividade.
A figura 4 traz o padro de retirada de dvidas como uma atividade de bloco. Nesta,
a dvida reportada (pelo solicitante) para o autor do documento ou um especialista que
conseqentemente responde a esta.

Figure 4. Padro Retirada de Dvidas

4.3 Padro Logstico

Processos logsticos so executados com o intito de manipular objetos fsicos ou prover
servios. Exemplos de atividades logsticas so a manufatura, a compra e venda de produtos,
providncia de servios ou o transporte de mercadorias. Est fora do escopo deste trabalho
detalhar os padres para cada um destes casos, mas possvel ilustrar possveis padres
genricos para as atividades logstica. No momento, o foco nos dados principais, em termos
de troca de mensagens, que tais atividades logsticas podem gerar. A figura 5 ilustra uma viso
conceitual das principais atividades logsticas encontradas na literatura. Com base em um
pedido, por exemplo, um dos diversos tipos de atividades logsticas ser executado.

Figure 5. Padro Logstico

4.4 Padro Financeiro

Este padro representa um processo financeiro. Um processo financeiro execuado quando
um valor monetrio cambiado entre duas partes. Como mostrado na figura 6, a atividade
financeira manipula e, eventualmente, gera um novo valor monetrio (por meio de atributos
monetrios especficos).

Figure 6. Padro Financeiro

4.5 Padro Performativo Unidirecional

Este padro representa uma mensagem performativa unidirecional. A figura 7, por exemplo,
mostra a descrio de uma requisio para a execuo de uma atividade. Baseado nisso, um
item de trabalho alocado para um destinatrio (i.e., um participante de workflow especfico
responsvel pela execuo da atividade; e.g., especificado pelo papel do usurio). Aps isso,
o processo deve ter sua execuo continuada sem aguardar por uma resposta. preciso
salientar que o padro performativo unidirecional no necessita de uma resposta. As
atividades de leitura e escrita podem ser modeladas como parmetros se estes forem
permitidos em uma atividade de bloco. A atividade Escrever descrio da execuo da
atividade na base de dados tem como parmetro de sada requisio de descrio, que est
modelada na figura como operao de escrita.

Figure 7. Padro Unidirecional

4.6 Padro Performativo Bi-direcional

Este padro baseado nas mensagens performativas bi-direcionais, que formam um par de
requisio/resposta, onde o remetente solicita ao destinatrio executar uma atividade e o
destinatrio responde ao remetente.
A figura 8 mostra que a atividade de bloco tem sua execuo finalizada somente aps
o envio da notificao de atividade completada e a gravao do resultado da execuo na
base de dados (AND-Split).

Figure 8. Padro Performativo Bi-direcional

4.7 Padro Informativo

O padro informativo baseado na mensagem informativa, onde o solicitante pede
informaes ao remetente a qual suprida subseqentemente. Como ilustrado na figura 9, a
atividade de bloco inicia com a requisio de informao e termina quando a informao
requerida recebida. Este padro se difere do padro performativo bi-direcional
especialmente pelo fato de o workflow aguardar por uma resposta do usurio.

Figure 9. Padro Informativo

4.8 Padro Notificativo

Como mostrado na figura 10, este padro baseado na mensagem de notificao. Este
engloba atividades de notificao que informam sobre a finalizao de uma atividade ou que
divulgam novidades inerentes respectiva aplicao de workflow (e.g., uma notificao sobre
o resultado de um processo de aprovao). Devido ao fato de uma notificao informar sobre
o status da execuo de uma atividade, este pode ser considerado uma parte de uma
mensagem performativa bi-direcional. Nesta abordagem a atividade de notificao est sendo
tratada como uma atividade auto-contida; assume-se que uma notificao contendo o status
de uma atividade pode eventualmente ser requerida.

Figure 10. Padro Notificativo

4.9 Padro Decisrio

O padro decisrio similar ao padro de controle de fluxo de deciso proposto em
(AALST 2003). Entretanto, neste trabalho o padro decisrio formado por um padro
performativo bi-direcional seguido por um padro XOR-Split ou, com menos freqncia, um
OR-Split. A sada ser baseada no resultado da execuo de uma atividade, onde um ou mais
caminhos no fluxo sero seguidos para dar continuidade execuo do workflow.

Figure 11. Padro Decisrio

5. Evidenciando a Existncia, Necessidade e Completude dos Padres de

Workflow atravs da Minerao de Processos de Workflow Reais
Sistemas de workflow, em execuo, registram os participantes responsveis pela execuo
das atividades, assim como quando estas so executadas. Tais registros so conhecidos como
'logs' de eventos. A minerao de workflow, atravs do uso de softwares computacionais,
analisa estes 'logs', provendo um conjunto de dados estruturados. Em [Ellis 2006]
observado que a minerao de workflow tem como objetivo principal obter o modelo de
workflow atual com base em 'logs' de processos em execuo.
Com o objetivo de pesquisar a existncia dos padres de workflow em processos de
workflow de aplicaes reais foram minerados 190 processos de workflow modelados na
ferramenta Oracle Builder. Tais processos so executados por diferentes organizaes e
referem-se a diferentes aplicaes. Mais precisamente, 17 processos referem-se ao
gerenciamento de atividades internas de uma empresa de pequeno porte, descentralizada,
cujo principal ramo de atividade o desenvolvimento de software. Outros 11 processos
definem o controle de qualidade total de uma empresa de pequeno porte, descentralizada.
Aproximadamente 133 processos referem-se ao controle de acessos a software e
gerenciamento de documentos de 6 empresas de grande porte, altamente centralizadas. O
restante dos processos (29) so processos de Help Desk, Feedback de usurios e
aprovaes de 4 empresas de grande porte. Por razes confidenciais, no foi possvel obter
informaes sobre as caractersticas estruturais destas empresas.
Os principais resultados da minerao foram:
a) evidencia de constatao da existncia da maioria dos padres de workflow em
processos (modelos) de workflow reais com alta probabilidade;
b) contatao de que o conjunto de padres necessrio e suficiente para modelar
os 190 processos de workflow analisados. Isso demonstra que o conjunto de
padres adequado para modelar uma variedade significativa de processos de
workflow.

Para verificar a freqncia com que cada padro ocorre no conjunto de processos de
workflow analisados identificamos, manualmente, os padres nos processos. A Figura 12 traz
um exemplo de como a identificao foi realizada.

Padro
Notificativo

Padro
Aprovao

Padro
Performativo
Unidirecional

Figure 12. Processo real que inclui os padres de workflow

Aps, para cada padro de workflow foi calculado o valor de suporte, tal como
realizado com regras associativas [Agrawal 2006]. No contexto deste artigo, o suporte
significa o nmero de ocorrncias de cada padro de workflow nos 190 processos de
workflow analisados. Observe que para aqueles processos incluindo mais de uma ocorrncia
de um mesmo padro, considerou-se apenas uma ocorrncia deste. Procedeu-se, assim, visto
que o suporte foi calculado com base no nmero de processos e no com base no nmero de
atividades atmicas. Alm disso, em alguns casos, os padres foram identificados em ordens
parciais de atividades. A seguinte frmula foi considerada para o clculo do suporte:

S = F (AC) ;
TT

Onde:
F(AC) = freqncia de A e C juntos, sendo (A e C)
equivalentes a um padro de workflow
TT = nmero de processos analisados

5.2 Anlise dos Principais Resultados da Minerao

Esta Seo apresenta os resultados da minerao de 190 processos de workflow, a qual foi
realizada com o objetivo de verificar se os tipos de processos descritos na Seo 3 podem
ser, de fato, considerados padres com alta probabilidade de reuso na modelagem de
processos de negcio e workflow.
A Figura 13 traz a freqncia com que cada padro de workflow foi identificdo no
conjunto de processos investigados. O grfico mostra que o padro aprovao foi
identificado com alta freqncia nos processos investigados (i.e., 60%). Tal fato justifica-se
pela alta centralizao na tomada de deciso existente nas unidades organizacionais envolvidas
na execuo dos processos. Alm disso, muitos dos processos pertencem a aplicaes com
contextos de aprovao. O padro de retirada de dvidas foi identificado com menor
freqncia (i.e., 2%), pois poucos processos incluem atividades de retirada de dvidas.

O padro financeiro foi identificado em atividades, onde valores monetrios so

utilizados ou produzidos. Ainda que tal padro tenha sido identificado em apenas 6% dos
processos, todas as atividades financeiras analizadas o incluem. A baixa freqncia tanto do
padro financeiro como do padro logstico se d pelo fato de poucos processos inclurem
atividades financeiras e/ou logsticas.
Os padres performativo unidirecional e bi-direcional, assim como, os padres
decisrio e notificativo foram identificados com alta freqncia nos processos investigados
(i.e., 75%, 65%, 54% e 64%, respectivamente). Tais padres, como j mencionado neste
artigo, no esto relacionados a um domnio de aplicao especfico ou a aspectos estruturais
da organizao. Tais padres representam funes genricas sendo, portanto, passveis de
serem encontrados em qualquer tipo de processo. O padro informativo tambm um
padro genrico. Este foi identificado com menor freqncia (16%), pois o nmero de
processos incluindo solicitao de informao reduzido.
Freqncia dos Padres de Workflow nos Processos Analisados
Aprovao

60%

Retirada de Dvidas

2%

Financeiro
Logstico

8%
0%

Informativo

16%
64%

Decisrio
Notificativo

54%
65%

Performativo Bi-direcional

75%

Performativo Unidirecional
0%

10%

20%

30%

40%

50%

60%

70%

80%

Suporte

Figure 13. Freqncia dos padres em processos de workflow reais

5.3 Completude e Necessidade dos Padres para Modelagem de Processos

O que realmente nos surpreendeu com o estudo de caso foi o fato de que todos os processos
de workflow analisados podem ser definidos como uma composio dos padres
investigados (veja a Figura 14 para um exemplo). Ou seja, o conjunto de padres de
workflow mostrou-se necessrio e suficiente para modelar todos os 190 processos analisados
na minerao. Em cada processo, um padro especfico aparece zero ou mais vezes
combinado com outros padres de controle de fluxo.
Ns consideramos este fato importante, o qual deve ser investigado como parte de
trabalhos futuros. Por exemplo, como os padres de workflow podem ser teis quando
integrados em uma ferramenta de modelagem? Poderia ser desenvolvido um mdulo de
software inteligente, o qual a partir de um repositrio de padres de workflow auxiliasse o
projetista a completar a modelagem sendo desenvolvida por este.

Bi-directional
pattern

Notification
pattern

Unidirectional
Performative
pattern
Informative
pattern
Decision
pattern

Notification
pattern

Approval
pattern

Unidirectional
Performative
pattern

Notification
pattern

Figure 14. Um processo de pagamento construdo com base na combinao dos

padres

6 Concluses
Ainda que existam diversos trabalhos na rea de padres de workflow (e.g., padres de
controle de fluxo [Aalst 2003], fluxo de dados [Russell 2004a], recursos de workflow
[Russell 2004b] e tratamento de exceo [Russell 2006]), padres com base em funes
recorrentes em processos de negcio tm sido pouco explorados. Em vista disso, este artigo
apresentou o levantamento e classificao de um conjunto de padres de workflow com base
em funes recorrentes frequentemente encontradas em processos de negcio.
Atravs da minerao de 190 processos de workflow de diferentes organizaes
constatou-se, com alta probabilidade, a existncia dos padres nos processos investigados.
Atravs da anlise estrutural e do particionamento de cada processo, evidenciou-se que os
padres classificados representam o conjunto necessrio e suficiente de construtores para a
modelagem de todos os processos analisados. As principais vantagens da abordagem so:
Maior eficincia na modelagem: Com poucos padres possvel modelar uma
grande variedade de processos. Tais padres so mais prximos do vocabulrio ou nvel de
abstrao no qual o processo de negcio usualmente descrito (documentado) pela prpria
organizao. Acredita-se que o (re-)uso destes padres pode diminuir o tempo de
modelagem (eficincia) e garantir maior probabilidade de correo na automatizao do
processo.
Interoperabilidade: o (re-)uso dos padres pode contribuir para maior
interoperabilidade entre sistemas de workflow;
Aplicabilidade em diferentes nveis de abstrao: Alguns padres podem ser teis
tanto para a modelagem conceitual dos processos de negcio como em nvel de

implementao (ex.: BPEL4WS). Em um trabalho anterior demonstramos o mapeamento

entre os nveis conceitual e lgico, permitindo sua automatizao [Thom 2005].
Alm disso, existe forte indcio de que o conjunto de padres investigado completo,
ou seja, necessrio e suficiente para a modelagem de um grande nmero (seno a totalidade)
de processos de negcios distintos. Tais padres podem, eventualmente, simplificar o
processo de modelagem, visto que possuem semntica simples e bem definida. Mais ainda,
ferramentas de modelagem podem automatizar a seleo e aplicao dos padres com base
nas caractersticas dos processos sendo projetados, considerando-se diferentes aspectos (ex.:
organizacionais, dependentes da aplicao). Os padres de workflow investigados podem,
ainda, ser utilizados para teste de completude e na comparao do poder de expresso das
ferramentas e linguagens de modelagem de workflow existentes e futuras.
Como trabalhos futuros pretendemos investigar a completude do conjunto de padres
estudado para a modelagem de processos de negcio e workflow em geral. Pretendemos,
ainda, extender alguma ferramenta de modelagem de processos com os padres de workflow
propostos. Em [Thom 2007] apresentamos a primeira iniciativa neste contexto. Por fim,
verificar a utilidade e da eficincia (ex.: tempo de modelagem e correo) dos padres,
quando integrados ferramenta de modelagem de processos atravs de um catlogo

References
Aalst, W.M.P. van der; Hee, K. van. (2002) Workflow Management: models, methods,
and systems. London: The MIT Press.
Aalst, W.M.P. van der. (2003) Patterns and XPDL: A Critical Evaluation of the XML
Process Definition Language. Queensland University of Technology, Brisbane. (QUT
Technical report, FIT-TR-2003-06).
Agrawal, R.; Gunupulos, D.; Leymann, F. (1988) Mining Process Models from Workflow
Logs.
Disponvel
em:
<http://www.almaden.ibm.com/software/projects/iis/hdb/Publications/papers/edbt98_flow
mk.pdf>. ltimo acesso em Nov. 2006.
Bernstein, P. A.; Hadzilacos, V.; Goodman, N. (1987) Concurrency Control and Recovery
in Database Systems. Reading: Addison-Wesley. 370 p.
Bradshaw, D.; Kennedy, M.; West, C. Oracle BPEL Process Manager. (2005) Developers
Guide. Release 2 (10.1.2). Disponvel em: <www.oracle.org>. ltimo acesso em Out..
2006.
Cooplien, H.; Harrison, N. Organizational Patterns of Agile Software Development. (2004).
Disponvel em: <http://www.easycomp.org/cgi-bin/OrgPatterns?BookOutline>. ltimo
acesso Out. 2006.
Ellis, C. (2006) Workflow Mining: Definitions, Techniques, and Future Directions. Em:
Fischer, L. (Ed.) Workflow Handbook 2006 including business process management:
published in association with the workflow management coalition. Lighthouse Point : Future
Strategies, p. 213-228.

Eriksson H.E.; Penker, M. Business Modeling with UML. (2001) [S.l.]: John Wiley &
Sons. 459p.
Flores, F.; et al. (1998) Computer Systems and the Design of Organizational Interaction.
Disponvel em: <www.acm.og>. ltimo acesso em Jul. 2006.
Frank, U.; Lange; C. (2004) Mapping of Business Process Models to Workflow Schemata An Example Using MEMO-OrgML and XPDL. Disponvel em: <http://www.unikoblenz.de/~ecomod/php/index.php>. ltimo acesso emJun.. 2006.
Geurts, G.; Geelhoed, A. (2004) Business process decomposition and service identification
using communication patterns. ltimo acesso em: <http://msdn.microsoft.com/library/>.
Visitado em Jun. 2005.
Malone, T. W.; Crownston, K.; Herman, G. A. (2004) Organizing Business Knowledge:
The MIT Process Handbook. Disponvel em: <http://ccs.mit.edu/ph/>. ltimo acesso em
Out. 2006.
Mintzberg, H. (1995) Criando Organizaes Eficazes: estruturas em cinco configuraes.
So Paulo: Atlas.
Medina-Mora, R. (1992) The action workflow approach to workflow management
technology. Disponvel em: <www.acm.org>. ltimo acesso em Jun. 2005.
Muehlen, M. zur. (2002) Workflow-based process controlling: foundations, design, and
application of workflow-driven process information systems. Berlin: Logos Verlang. 299 p.
Russell, N.; Hofstede, A. H. M Ter; Edmond, D. (2004a) Workflow Data Patterns. Em:
INFORMATIK 2004 - Informatik verbindet (Band 1). Proceedings...[S.l. : s.n.]. p.50.
Russell, N. (2004b) Workflow Resource Patterns. Brisbane: Queensland University of
Technology (Technical report, FIT-TR-2004-01)
Russell, N.; Aalst, W.M.P. van der; HOFSTEDE, A. Ter. (2006) Workflow Exception
Patterns. Em: International Conference on Advanced Systems Engineering, CAiSE,
18. Proceedings... [S.l. : s.n.], 2006. p.288-302.
Thom, L. H.; Iochpe, C. (2003) Identifying Patterns of Workflow Design Relying on
Organizational Structure Aspects. Em: International Conference on Enterprise
Information Systems, ICEIS, 5., Angers. Proceedings Angers: ICEIS Press.
Thom, L. H.; Iochpe, C. (2006a) Applying block activity patterns in workflow modeling. Em:
International Conference on Enterprise Information Systems, ICEIS, 8., 2006,
Paphos, Chipre. Proceedings Setubal : Institute for Systems and Technologies of
Information, Control and Communication.
Thom, L. H.; Iochpe, C.; Amaral, V. L. do; Viero, D. M. de. Toward block activity patterns
for reuse in workflow design. Em: Fischer, L. (Ed.). Workflow Handbook 2006 including
business process management: published in association with the workflow management
coalition. Lighthouse Point : Future Strategies, 2006b. p. 249-260.
Thom, L. H.; Lau, J. M.; Iochpe, C.; Mendling, J. (2007) Extending Business Process
Modeling Tools With Workflow Patterns Reuse. Submetido para International

Conference on Enterprise Information Systems, ICEIS, 9., Angers. Proceedings

Madeira: ICEIS Press.
Thom, L.; Iochpe, C.; Mitschang, B. (2005) Improving the Workflow Project Quality Via
Business Process Patterns Based on Organizational Structure Aspects. Em: GI Workshop
XML for Business Process Management, 2. XML Interchange Formats for Business
Process Management: Proceedings. Karlsruhe : [S.n.], 2005. 1 CD-ROM.
Workflow Management Coalition. (1999) Terminology & Glossary. Bruxelas, 65p.
Disponvel em: <http://www.wfmc.org>. ltimo acesso em Nov. 2005.
Workflow Management Coalition. (2005) Process Definition Interface: XML Process
Definition Language. Doc. Number: WFMC-TC-1025.
Disponvel em:
<http://www.wfmc.org>. ltimo acesso em Out. 2005.