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 (f) Controle de Fluxo

(b) Ao atividade atmica

(c) Deciso (h) Nodo Final (i)

(d) Fork

(g) Swimlane
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 Retirada de Dvidas Financeiro Logstico Informativo Decisrio Notificativo Performativo Bi-direcional Performativo Unidirecional 0% 10% 20% 30% 40% Suporte 50% 60% 70% 54% 65% 75% 80% 0% 16% 64% 2% 8% 60%

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

Notification pattern

Decision 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 P rocess 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.