Especificação de Workflows num Contexto de Aplicações Heterogéneas: Reflexão sobre as Técnicas Existentes

Especificação de workflows num contexto de aplicações heterogéneas:

reflexão sobre as técnicas existentes

Cristina Margarida Chuva Costa

Instituto Superior de Engenharia de Coimbra/Centro de Informática e Sistemas da Universidade de Coimbra, Coimbra, Portugal

[email protected]

Paulo Rupino da Cunha

Departamento de Engenharia Informática da Universidade de Coimbra/Centro de Informática e Sistemas da Universidade de Coimbra, Coimbra, Portugal

[email protected]

Resumo

A forte mudança ocorrida na forma dos sistemas de informação reclama novas metodologias de projecto. Uma das vertentes deste problema é a especificação de

workflows, que actualmente encontram para suporte dos processos de trabalho um

articulado de aplicações heterogéneas em que se cruzam plataformas de diferentes fornecedores, diferentes idades, diferente complexidade e diferente sofisticação tecnológica.

Com vista a criar uma base de reflexão para a elaboração de propostas que respondam a estes desafios, analisam-se de forma sucinta as técnicas actualmente mais divulgadas para o projecto de workflows.

Palavras chave: modelação, workflow, sistemas de informação, metodologias 1 Introdução

Os sistemas de informação actuais contrastam acentuadamente com a realidade de há alguns anos. De entidades fortemente monolíticas e homogéneas, resultantes de projectos assentes em massiva programação informática à medida das necessidades de cada organização, transfiguram-se em carteiras de aplicações heterogéneas, maioritariamente adquiridas já prontas num mercado de software que consegue responder à maioria das solicitações. Surge assim um novo cenário, em que soluções de diversos fornecedores se articulam entre si e com o conjunto de soluções previamente existentes na organização para dar resposta às necessidades emergentes. Simultaneamente, cresce a apetência por intranets que integrem esta rede complexa

de sistemas num todo coerente e uniforme, que não só facilite a sua utilização como também explore as potencialidades de disponibilizar em rede, para múltiplos aproveitamentos, sistemas outrora isolados [Cunha e Figueiredo 2000], [Cunha 2000].

Esta mudança drástica na natureza dos sistemas de informação conduziu à inadequação das tradicionais metodologias de projecto [Avison e Fitzgerald 1999; Baskerville, Fitzgerald e Russo 1995; Fitzgerald 2000], fortemente enraizadas no conceito de desenvolvimento integral dos sistemas necessários. Também ao nível do workflow, novos desafios se colocam, uma vez que passa a ser necessário desenhar os fluxos de trabalho tendo em atenção que as suas funções irão ser suportadas num articulado de sistemas heterogéneos nem sempre pensados para comunicar entre si.

Para melhor se perceber como abordar este problema, em termos de propostas metodológicas a apresentar futuramente, faz-se, neste artigo, uma revisão de várias técnicas actualmente utilizadas para a especificação de workflows. Não se procura realizar uma comparação directa e detalhada entre técnicas, que são consideravelmente díspares, mas antes conseguir uma visão sobre várias formas de encarar o problema da modelação de fluxos de trabalho.

Assim, na secção 2 revê-se o uso de técnicas de especificação funcional para a descrição deste tipo de sistemas; na secção 3, aborda-se a aplicação dos Grafos à modelação de fluxos de trabalho, prosseguindo-se, na secção 4, com uma descrição do uso das Redes de Petri para o mesmo fim. A secção 5 trata uma abordagem consideravelmente diferente ao problema, o Paradigma Language Action. Na secção 6 discute-se a extensão da Linguagem UML a esta nova área e, em 7, finaliza-se a revisão das técnicas de especificação de workflows com uma análise da utilização de Patterns. A secção 8, sobre interoperabilidade, e a secção 9, de conclusões, encerram o artigo.

2 Técnicas de especificação funcional

Neste ponto vão ser descritas duas técnicas distintas, mas que partilham a mesma filosofia: ƒ Modelação com Diagramas de fluxos de dados (DFD).

ƒ Modelação Integration definition for function modelling (IDEF0)

Os DFDs foram propostos no campo da análise estruturada, na engenharia de software, como uma técnica de análise de sistemas que permite organizar perspectivas, regras e procedimentos num modelo coerente e ordenado [Jones 1988]. Este tipo de diagramas tem como característica a capacidade de poder representar os vários processos (“funções”), os fluxos de dados, os repositórios de informação e as entidades externas de uma forma gráfica, como se pode ver na

Figura 1. É de realçar, porém, que os DFDs retratam os sistemas apenas do ponto de vista da circulação dos dados e não do ponto de vista do fluxo de controlo [Layzell et al. 1989].

Figura 1: Exemplo de um DFD

Não obstante os diagramas de fluxos de dados terem sido pensados para dar apoio na especificação de módulos de software a desenvolver, a proximidade entre o modo como representam um sistema e as necessidades inerentes ao projecto de workflows foi notada por investigadores desta área, conduzindo à adopção dos DFDs também para a especificação de fluxos de trabalho [Sadiq e Orlowska 2000].

Para colmatar o problema de os DFDs possuírem carências na especificação de controlo nos processos, é possível recorrer aos fluxogramas (ferramenta gráfica que possui uma correspondência bastante estreita com os algoritmos e com a sequência de execução das instruções de uma linguagem procedimental) como uma das técnicas utilizadas para realizar as descrições funcionais relativas a cada processo de um diagrama de fluxo de dados [Fisher 1988]. Os fluxogramas, ao contrário dos DFDs, colocam a ênfase na componente de controlo e não na circulação de dados. Esta característica, útil para representar decisões de encaminhamento e acções a efectuar num documento ao longo da sua circulação num sistema, fez com que também os fluxogramas conquistassem um lugar na especificação de workflows. Na Figura 2 pode ver-se um exemplo de um fluxograma.

Processo 1

Entidade Externa Processo

3 Repositório Processo 2 dados dados dados dados dados

Início

Recebe Número

Adiciona o

valor dois valor doisSubtrai o

Fim Apresenta

resultado

Verdadeiro Falso _Positivo?

Figura 2: Exemplo de um fluxograma

Os fluxogramas possuem ainda a seu favor o facto de recorrerem a uma simbologia já aceite, cuja compreensão é praticamente universal e imediata. Como desvantagens podem apontar-se a sua complexidade gráfica e ao seu baixo nível de abstracção, que obrigam a esforço adicional no redesenho dos diagramas sempre que ocorra qualquer alteração ao processo [Martin et al. 1988]. Os diagramas propostos na técnica Integration definition for function modelling (IDEF0), por sua vez, foram apresentados em 1993, pelo Computer Systems Laboratory of the National Institute of Standards and Technology, como uma norma para a modelação funcional de sistemas, tendo-se baseado na arquitectura desenvolvida pelos Laboratórios Aeronáuticos da Força Aérea dos Estados Unidos: Integrated Computer-Aided Manufacturing [Air Force Wright Aeronautical Laboratories 1981]. Esta técnica de modelação possui fortes semelhanças com os DFDs, como se pode constatar pelos tipos de informações que compõem os seus modelos:

ƒ Diagramas: constituídos por caixas, setas e relações entre as várias caixas. As caixas representam as funções principais de um subconjunto do sistema e podem ser decompostas noutras sub-funções, de modo a possibilitar uma fácil compreensão dos sistemas, especificar requisitos, suportar a análise e efectuar representações por níveis. ƒ Texto estruturado: utilizado para fornecer uma visão concisa e enfatizar

características, fluxos e relações que permitam clarificar os objectivos dos vários itens dos diagramas.

ƒ Glossário: define palavras existentes nos diagramas que devem transmitir um entendimento comum, de modo a permitirem uma correcta interpretação do conteúdo do modelo.

Na Figura 3 pode ver-se um exemplo de um diagrama IDEF0.

A1 Processo 1 A2 Processo 2 A3 Processo 3 Entrada 1 Saída 1 Controlo 1 Controlo 2 Controlo 3 Mecanismo 1

Figura 3: Exemplo de um diagrama IDEF0

Em [Yadav et al. 1988] foi desenvolvido um estudo comparativo entre a construção de DFDs e de diagramas IDEF0. Foi analisado o modelo resultante das duas técnicas, assim como todo o processo de modelação. Os resultados obtidos foram:

ƒ Os utilizadores dos DFDs, relativamente aos que recorriam a diagramas IDEF0, aprendiam mais facilmente as regras sintácticas e construíam diagramas mais expeditamente;

ƒ O número de utilizadores de IDEF0 que passariam a empregar DFDs no seu próximo projecto era bastante superior ao número de indivíduos que transitariam dos DFDs para IDEF0;

ƒ Os autores do estudo não encontraram diferenças significativas entre os modelos no que respeita à exactidão, abrangência e consistência do modelo.

Tal como nos DFDs, em que os aspectos de controlo que são importantes para o workflow são capturados através de especificações detalhadas dos processos [Barros e Hofstede 1998]. Também no caso dos diagramas IDEF0 se recorre a um procedimento semelhante para clarificar em algumas situações o funcionamento dos processos. A necessidade de recurso a estas técnicas de especificação complementares tornou o uso dos diagramas DFD e IDEF0 menos apelativos para a modelação de workflow.

3 Grafos

Outras abordagens à modelação de processos de workflow, propostas por vários investigadores e empresas, recorrem ao uso de Grafos (modelos matemáticos baseados em nós e arcos, que representam relações entre objectos), por exemplo Casati em [Casati et al. 1995] e van der Aalst em [Aalst et al. 2002].

Um trabalho particularmente importante nesta vertente é o desenvolvido por Sadiq [Sadiq et al. 1996], que complementa a proposta de utilização dos Grafos com um conjunto de passos e notações cujo objectivo é criar uma referência na aplicação desta técnica ao fluxo de trabalho nas organizações. Na sua proposta, a modelação de um sistema de workflow é dividida em cinco fases: estrutura, dados, execução, aspectos temporais e aspectos transaccionais.

A componente estrutural consiste na especificação das actividades de workflow e das suas dependências. Esta abordagem também foi utilizada por outros investigadores, por exemplo Casati [Casati et al. 1995] e Heinlein [Heinlein 2001].

Neste contexto, os nós de um grafo podem representar actividades (descritas através de um conjunto de propriedades, tais como dados, tempos de execução, recursos a atribuir e clientes) ou condições. As actividades são normalmente caracterizadas por rectângulos e utilizadas na representação de estruturas sequenciais, concorrenciais e de sincronização, enquanto que as condições possuem os círculos como simbologia e são empregadas na representação de “ou” lógicos conjuntos e disjuntos [Sadiq et al. 1999].

Em [Sadiq et al. 1996] é proposto um modelo para a representação de sistemas de workflow que se baseia na Teoria de Grafos. As suas componentes gráficas são as apresentadas na Figura 4.

Actividade Condição Sincronizador Fluxo

Figura 4: Objectos de modelação de workflow (retirada de [Sadiq et al. 1996])

Para as “actividades” (representadas na Figura 4 por um rectângulo) podem definir-se várias propriedades, tais como o grau de automação (se a actividade é manual, automática ou mista), a atomicidade (se a actividade poder ser decomposta), o alcance (se é interna ou externa ao sistema de gestão de workflow), a colocação (a ordem pela qual uma actividade é colocada num processo), a execução (garantia de execução da actividade), a importância (se a actividade é crítica) e temporalidade (se a actividade tem associadas restrições temporais).

As “condições” (representadas na Figura 4 por um circulo) são utilizadas com o intuito de especificar caminhos alternativos, recorrendo-se para tal a elementos que permitem a identificação do caminho seleccionado. Os “sincronizadores” (representados na Figura 4 por um triângulo) são, por sua vez, imprescindíveis para que vários fluxos paralelos possam convergir para um ponto, de forma a se garantir que todas as actividades anteriores a esse ponto já foram concluídas. Por fim, os “fluxos” (representados na Figura 4 por uma seta) definem a ligação entre dois objectos dos tipos anteriores, indicando o sentido de processamento.

Através dos objectos apresentados nos pontos anteriores, [Sadiq et al. 1999] define construções (constructs) que permitem modelar a forma como as actividades vão sendo executadas ao longo de um processo.

ƒ Sequência: é a estrutura mais básica de modelação de workflow (ver Figura 5). Especifica a ordem pela qual as actividades devem ser executadas, através do recurso à representação de fluxos.

A1 A2 A3

Figura 5: Actividades sequenciais (retirada de [Sadiq et al. 1996])

ƒ Selecção mutuamente exclusiva: permite modelar caminhos alternativos mutuamente exclusivos. Este processo tem como base uma condição que permite a selecção de um dos caminhos de execução possíveis. No exemplo da Figura 6, depois da actividade “A1” ser executada, a condição “C1” é verificada, identificando qual das três actividades seguintes (“A2”, “A3” ou “A4”) será executada.

ƒ Junção exclusiva: é utilizada para representar a convergência de caminhos de actividades mutuamente exclusivas num único caminho. Um exemplo deste caso pode ser visto na Figura 6, em que a actividade “A5” representa uma junção exclusiva das actividades “A2”, “A3” e “A4”.

A1 _C1

A2

A3

A4

A5

Figura 6: Selecções mutuamente exclusivas e selecção exclusiva ([Sadiq et al. 1996])

ƒ Concorrência: representa caminhos de execução concorrentes, possibilitando a execução de encaminhamento paralelo. Pode exemplificar-se com a Figura 7, na qual

depois de a actividade “A1” ter sido concluída, as actividades “A2” e “A3” começam a ser executadas concorrente e independentemente.

ƒ Sincronização: a representação gráfica da sincronização permite modelar as situações em que as actividades de vários fluxos concorrentes são colocadas em modo de espera até que todas tinham sido realizadas. Na Figura 7, a sincronização é representada por “S1”, que apenas permite que actividade “A6” comece a ser processada depois de concluídas “A4” e “A5”.

A4 A5 A6 S1 A1 A2 A3

Figura 7: Caminhos concorrentes ([Sadiq et al. 1996])

ƒ Iteração: descreve a repetição de um conjunto de actividades, dependendo do estado de uma condição. Na Figura 8, a actividade “A3” será executada repetidamente até que a condição “C1” active o fluxo que indique a execução de “A2”. Neste exemplo, sempre que “A3” é dada por terminada, envia uma nova condição para C1, de forma a decidir entre “A2” e “A3”.

A1 _C1

A2

A3

Figura 8: Iteração de actividades ([Sadiq et al. 1996])

Os dados são a segunda vertente da modelação de workflows, segundo [Sadiq et al. 1996]. Um modelo de workflow não é de grande utilidade sem uma especificação dos requisitos de dados e dos fluxos destes entre actividades. Normalmente são utilizadas duas abordagens para representar dados de workflow: ou explicitamente, através dos fluxos de dados entre os nós de um grafo, ou implicitamente, recorrendo a um armazenamento de dados global, onde as actividades podem escrever e ler informações [Sadiq et al. 2000].

Os aspectos relativos à estrutura e aos dados do modelo de workflow englobam informações que auxiliam o motor subjacente ao sistema a efectuar a atribuição de actividades aos diversos intervenientes num processo do fluxo de trabalho (execução). Porém, para cada actividade do processo, é ainda necessário especificar os seus participantes através de políticas de atribuição

[Sadiq et al. 2000]. Estas políticas podem tornar-se bastante complexas, uma vez que entram em consideração com um elevado número factores, tais como: prioridades, regras da empresa e outras actividades que os diversos intervenientes já tenham atribuídas [Sadiq et al. 2000]. A componente temporal de um processo de negócio é modelada através de um conjunto de restrições temporais que, do ponto de vista do negócio, são representadas por regras, regulamentos da empresa, políticas de funcionamento, práticas comuns, acordos mútuos e expectativas relacionadas com a eficiência ou produtividade da prática de negócio.

São estes condicionantes temporais que, uma vez capturados e integrados no modelo do workflow, definem a altura apropriada ao desencadear de cada actividade.

Por fim, a introdução da componente transaccional na especificação de processos de workflow, tem como objectivo incluir no modelo informações acerca da forma como tratar situações excepcionais. Caso existam lacunas na componente transaccional, fazendo com que as excepções não sejam convenientemente tratadas, em situações para as quais não existe um comportamento estipulado o motor de workflow não conseguirá determinar qual o comportamento a adoptar.

4 Redes de Petri

Depois dos diagramas de fluxo de dados (DFDs) e dos Grafos, outra corrente propôs a adopção das Redes de Petri para a modelação de sistemas de workflow. As Redes de Petri são assim denominadas em homenagem ao seu autor Carl Adam Petri, que na sua dissertação de doutoramento, submetida em 1962, à Faculdade de Matemática e Física da Universidade Técnica de Darmstadt, na Alemanha, apresentou um tipo de grafo bipartido com estados associados (um grafo G é bipartido quando os seus nós podem ser divididos em dois conjuntos N1 e N2, tais que nenhum nó contido em N1 ou N2 se encontra ligado a outro nó contido no

mesmo conjunto).

Os nós que compõem uma Rede de Petri podem dividir-se em dois conjuntos: lugares e transições. Os lugares são normalmente representados através de circunferências ou de elipses, enquanto que as transições recorrem à utilização de segmentos de recta, rectângulos ou barras. De uma forma bastante genérica, os lugares podem ser vistos como depósitos de recursos (os recursos são representados por círculos pretos dentro dos lugares e a cada um desses círculos atribui-se a designação de marca). As transições podem ser vistas como acções que manipulam os recursos. Os nós existentes numa Rede de Petri são ligados através de arcos, sendo que ligações entre nós do mesmo tipo (lugares com lugares e transições com transições) não são permitidas [Aalst 1999].

Um exemplo de uma Rede de Petri marcada é apresentado na Figura 9.

Figura 9: Rede de Petri marcada (retirada de [Aalst 1999])

Na maior parte das situações, não se recorre às Redes de Petri convencionais para a definição de workflows, pois, ao entrar em consideração com factores tais como os atributos relacionados com os recursos disponíveis e as questões temporais, a modelação pode tornar-se bastante complexa. Assim, recorre-se, normalmente, a Redes de Petri de alto nível, que possuem extensões relativamente à abordagem clássica, tais como a capacidade de modelação de dados e de tempo.

Segundo autores como [Aalst 1999], algumas das razões que justificam o recurso às Redes de Petri para a modelação de workflows são a sua semântica formal, a natureza gráfica das suas redes, a sua expressividade, o facto de existirem técnicas de análise estabelecidas, assim como ferramentas de modelação de processos de workflow através de Redes de Petri.

Em concreto, as actividades a realizar num processo podem ser modeladas através de transições, enquanto que as condições associadas à realização de uma determinada actividade podem ser descritas através dos lugares e dos atributos relativos a documentos, a recursos ou a participantes que podem ser inseridos nas Redes de Petri através das marcas. No que diz respeito à ordem pela qual as actividades devem ser executadas, as Redes de Petri disponibilizam esquemas de execução (como sejam, o “e” lógico associado à disjunção e à conjunção de actividades, ou o “ou” associado à disjunção e à conjunção de actividades) que possibilitam a modelação de encaminhamento sequencial, condicional, paralelo ou iterativo. O encaminhamento sequencial representa actividades em que a sua ordem de execução é seguida (ver Figura 10). Neste tipo de encaminhamento podem também adicionar-se lugares entre transições, que funcionam com pós-condições para a primeira actividade e pré-condições para a segunda.

Figura 10: Actividades realizadas sequencialmente (retirada de [Aalst 1999])

O encaminhamento paralelo é utilizado em casos em que a ordem de execução não é tão rígida, ou seja, duas actividades necessitam de ser efectuadas, mas a sua ordem é arbitrária. Para isso, recorre ao conceito de “e” lógico associado à disjunção e conjunção de actividades. Na Figura 11, a execução da actividade “A” permite que as actividades “B” e “C” sejam realizadas, enquanto que a actividade “D” funciona como um ponto de sincronização dos dois fluxos, que só é realizada depois de as actividades “B” e “C” serem dadas por concluídas.

Figura 11: Actividades realizadas em paralelo (retirada de [Aalst 1999])

O encaminhamento condicional é utilizado para modelar a selecção da realização de uma actividade em detrimento de outras. Para isso, utiliza o conceito de “ou” lógico associado à disjunção e conjunção de actividades (estes “ou” lógicos podem ter vários arcos associados). Na Figura 12, é apresentado um exemplo deste tipo de encaminhamento, em que a actividade “A” é seguida da actividade “B” ou “C”, dependendo da condição “c2“, e por fim é realizada a

actividade “D”.

Figura 12: Actividades com condições associadas (retirada de [Aalst 1999])

A iteração é muitas vezes considerada uma forma de encaminhamento indesejável, porque corresponde à repetição da execução de uma actividade sem que se façam progressos efectivos. No entanto existem situações em que é inevitável, como por exemplo no caso do preenchimento de um formulário de uma forma incompleta [Aalst 1999]. Na Figura 13 é apresentado um exemplo de iteração, onde “C” funciona como uma actividade de controlo que verifica o resultado da actividade “B”. De acordo com esta aferição, “B” pode ser executada várias vezes.

“e” conjunto “e” disjunto

Figura 13: Iteração de actividades (retirada de [Aalst 1999])

5 Paradigma Language Action

Este paradigma de modelação de processos (abordado em [Winograd e Flores 1986]; [Medina-Mora et al. 1992]) baseia-se na teoria de speach act, que foi desenvolvida a partir de áreas da linguística [Austin 1962], e possui uma filosofia relativamente diferente dos métodos apresentados atrás. É possível constatar a sua particularidade, por exemplo, através do facto de esta abordagem possuir como uma das suas assunções cruciais que a linguagem pode ser utilizada, como uma ferramenta, no planeamento e coordenação de acções e no estabelecimento de obrigações.

Através do Language Action, um processo de negócio é visto como uma conversação que ocorre entre dois intervenientes [Medina-Mora et al. 1992]. Os intervenientes funcionam como clientes e fornecedores de um serviço e o processo de negócio é representado como um ciclo fechado que é dado por terminado quando o cliente expressa explicitamente a sua satisfação [Carlsen 1997]. É assim possível constatar que, na modelação, esta abordagem dá uma importância elevada à componente cliente, nomeadamente às suas opiniões e ao cumprimento dos seus objectivos. A esquematização descrita tanto pode ser aplicada à modelação de um diálogo inicial com um cliente como à decomposição deste último em outros que o pormenorizam. Este processo é repetido para todos os ciclos existentes, até que estes representem todos os aspectos necessários à especificação de uma dada situação. Esta “explosão” de diálogos provoca a formação de uma rede de comunicação de acções e compromissos.

Os diálogos entre os clientes e os fornecedores, ilustrados na Figura 14, consistem em quatro fases [Medina-Mora et al. 1992]:

ƒ Proposta: é realizada através do pedido de um cliente ou da oferta de um fornecedor; ƒ Acordo: decorre quando as duas partes acordam as condições de satisfação para um

ƒ Desempenho: momento em que o fornecedor de serviços, após completar o seu trabalho, informa o cliente que as acções que tinha a realizar já foram dadas por terminadas;

ƒ Satisfação: o cliente é confrontado com o resultado do seu pedido e declara a sua satisfação ou insatisfação de acordo com as condições acordadas.

Condições de Satisfação Proposta Acordo Satisfação Desempenho Cliente Fornecedor

Figura 14: Paradigma Language Action (baseada em [Carlsen 1997])

Em qualquer uma das fases representadas podem ser adicionadas novas acções, como sejam clarificações, negociações adicionais acerca das condições e alterações nos compromissos estabelecidos entre os participantes [Medina-Mora et al. 1992]. A estrutura do processo é definida através dos ciclos de diálogo, que possibilitam o estabelecimento de mecanismos de coordenação, e não das acções realizadas com o intuito de atingirem as condições de satisfação dos intervenientes no processo.

Nas abordagens descritas nas secções anteriores, as acções de coordenação são vistas como actividades ou como fluxos de informação entre elas. Neste método, a estrutura centra-se essencialmente na componente de coordenação representada através dos ciclos, que permitem a definição das actividades com base nos pedidos e nos compromissos estabelecidos durante o diálogo entre os intervenientes.

Algumas das críticas apontadas a este modelo residem no facto dele assumir uma comunicação bastante explícita entre os diversos actores, como é referido em [Carlsen 1997], o que na realidade é muitas vezes difícil de alcançar.

6 Linguagem UML

Em alguma bibliografia relativamente recente têm sido apresentadas propostas que consistem em tentativas de estender e adaptar a linguagem Unified Modelling Language (UML) à modelação de workflows [Baresi e Casati 1999; Eshuis e Wieringa 2001].

Um caso concreto consiste na metodologia de modelação WIDE [Baresi e Casati 1999], que incide na fase de análise de requisitos. Descreve-se aqui como exemplo por ser aquela que tenta abordar mais aspectos na representação do processo e de estar inserida num método global que pretende abordar todas as fases de desenvolvimento de um sistema de workflow.

A metodologia WIDE aborda os processos de negócio através de três perspectivas: funcional,

organizacional e de negócio.

A perspectiva funcional aborda as estruturas operacionais do processo de negócio, englobando diagramas de casos de uso (use cases) para estabelecimento de fronteiras do sistema, identificação de intervenientes e respectivas interacções, representação de sub-processos do negócio e esquematização de relações entre os actores e os sub-processos. Usa ainda diagramas de interacção para descrever a forma como as entidades envolvidas cooperam numa determinada situação, diagramas de classes para representar informações associadas a actores ou actividades, e diagramas de actividades para facilitar a identificação de sub-processos e a representação do encadeamento que as actividades possuem ao longo do processo de workflow. A perspectiva organizacional modela aspectos relacionados com papéis (utilizados para a especificação das responsabilidades), actores (que podem ser vistos como estereótipos específicos) e unidades organizacionais envolvidas num processo de negócio (representadas através do conceito de package da linguagem UML). A organização, como um todo, pode ser representada por packages que cooperam entre si (unidades organizacionais), cada uma abrangendo os actores que lhe estão associados.

A perspectiva de negócio abarca o conjunto de objectivos que devem ser atingidos no processo de negócio, assim como no workflow que o modela. Normalmente é difícil formalizar os objectivos associados a processos de negócio, por isso a metodologia WIDE propõe que os objectivos sejam subdivididos de forma a poderem ser associados a sub-processos (associados ao conceito de actividade) do processo de negócio. Uma matriz de sub-processos e sub-objectivos pode ser utilizada para representar as relações existentes.

A metodologia WIDE defende ainda que é por vezes útil complementar a representação gráfica de um caso, obtida através da aplicação dos diagramas, com uma descrição textual. Para isso, segue a proposta de Cockburn em [Cockburn 1997], de modo a facilitar o desenvolvimento do sistema de workflow. Alguns dos aspectos focados nessa descrição textual são os objectivos do caso, o seu âmbito, as pré-condições e as condições de sucesso, as prioridades, a frequência de ocorrência, a acessibilidade e o prazo de execução.

7 Patterns

O conceito de Pattern foi criado por Christopher Alexander e amplamente apresentado no seu livro The Timeless Way of Building [Alexander 1979], como uma solução para o tratamento de problemas relativos ao planeamento urbano e à arquitectura de construção. A ideia subjacente ao conceito é a de, num dado projecto, reaproveitar soluções que já foram adoptadas em cenários idênticos e aí deram provas da sua eficiência e qualidade, permitindo assim a optimização do trabalho.

Actualmente, já existem alguns estudos publicados na área da definição de linguagens baseadas em Patterns (pattern languages) para o projecto e implementação de sistemas de workflow. Como exemplo pode apontar-se o trabalho desenvolvido por van der Aalst em [Aalst 2002]. Dois dos aspectos que impulsionaram a modelação de sistemas de workflow através do recurso a Patterns foram o facto destes proporcionarem independência relativamente à tecnologia utilizada para a sua implementação e ao domínio sobre o qual se está a trabalhar. De facto, os Patterns, ao exigirem um elevado nível de abstracção, permitem que os padrões descobertos em vários domínios sejam generalizados para que possam ser reutilizados em vários cenários [Aalst 2002].

O âmbito dos Patterns utilizados para a modelação de sistemas de workflow abrange desde construções simples, presentes em qualquer linguagem de workflow, até primitivas de encaminhamento bastante complexas que ainda não são suportadas pelos sistemas de gestão de workflow actuais. Exemplos de Patterns simples são: sequência, disjunção paralela, sincronização, escolha exclusiva e conjunção simples, anteriormente descritas e disponíveis nos produtos de workflow correntes. Na realidade, o recurso ao termo Pattern para descrever estes construtores mais simples é algo exagerado. Contudo, para construções de encaminhamento mais complexas, como aquelas propostas por van der Aalst – “escolha múltipla” (ponto no processo de workflow onde, de acordo com decisões e dados de controlo, um conjunto de ramos é seleccionado) ou “discriminador” (ponto no processo de workflow que espera que apenas um dos seus ramos esteja completo para dar início à actividade seguinte) – o recurso ao termo Pattern é já fundamentado, uma vez que são dadas soluções não triviais para problemas práticos encontrados aquando da utilização da tecnologia de workflow [Aalst 2002].

Dragos Manolescu, por sua vez, desenvolveu uma arquitectura para sistemas de workflow baseada em patterns, segundo ele porque [Manolescu 2001]:

ƒ Quem desenvolve software ambiciona sistemas de workflow que possa adaptar e integrar com as suas aplicações;

ƒ As arquitecturas de workflow monolíticas são incapazes de permitir a activação de apenas algumas das suas funcionalidades, de se adaptarem às necessidades dos utilizadores e não possuem características que facilitem a reutilização.

A arquitectura do Micro-Workflow de Manolescu, apresentada na Figura 15, é caracterizada por um pequeno núcleo que suporta as operações básicas de workflow e que pode ser estendido através de componentes adicionais, de modo a suportar características complementares. Os componentes desenvolvidos por Manolescu, tendo como base Patterns já existentes, foram apresentados na sua tese de doutoramento [Manolescu 2001] e estão representados na figura acima do núcleo da arquitectura.

_{Micro Workflow} Núcleo Registo Federado Histórico Monitorização Lista de trabalho Intervenção manual Componente X 1 Componente X 2

Figura 15: Arquitectura Micro-Workflow (baseada em [Manolescu 2001])

8 Interoperabilidade em workflow

Nesta secção são referidas algumas das iniciativas adoptadas por várias organizações com o objectivo de permitirem a interoperabilidade entre sistemas de workflow diferentes. Estas abordagens estão muito relacionadas com aspectos do dia-a-dia no ambiente empresarial, pelo que é dada uma maior ênfase às possibilidades que tecnologias proporcionam na prática do que às abordagens de projecto. Porém, actualmente, com a expectativa criada em torno de áreas como a integração de aplicações, já começa a existir algum trabalho relativo à criação de metodologias para este domínio [Themistocleous e Irani 2000]. A importância da interoperabilidade prende-se com a necessidade de integrar de forma natural as várias aplicações informáticas, de diversos fabricantes, que hoje constituem os sistemas de informação. É nestas aplicações que residem os dados irão ser usados nos processos (e fluxos) de trabalho.

Várias organizações, das quais se podem destacar a Workflow Management Coalition, o Object Management Group e a Internet Engineering Task Force, têm realizado esforços no sentido de que a interoperabilidade entre vários produtos de workflow seja uma realidade.

A Workflow Management Coalition é uma organização que estabelece e publica standards relacionados com a terminologia e a ligação entre sistemas de workflow desde 1996. Esta instituição desenvolveu um modelo de referência em que um dos aspectos contemplados é, precisamente, a interoperabilidade entre diferentes sistemas de gestão de workflow. Apresentou também o documento Interoperability Abstract Specification [WfMC 1999], que consiste numa especificação abstracta com capacidades para definir as funcionalidades requeridas ao suporte da comunicação entre motores de workflow diferentes.

Devido ao crescente interesse pela adopção de tecnologias popularizadas no contexto da Internet, grande parte do trabalho da Workflow Management Coalition está actualmente centrado na especificação da norma Wf-XML. Esta pode ser encarada como uma variante baseada em XML (eXtensible Markup Language) da interface de interoperabilidade do modelo de referência da Workflow Management Coalition, que pode trabalhar com o protocolo HTTP (Hyper Text Transfer Protocol) ou outros tipos de mecanismos de transporte: correio-electrónico, ligações TCP/IP (Transmission Control Protocol/Internet Protocol) e Message Oriented Midleware (MOM) [WfMC 2001]. Nesta norma, quando um motor de workflow envia uma mensagem codificada em Wf-XML a outro motor de workflow, o que está efectivamente a fazer é uma chamada remota a esse motor e a fornecer os parâmetros necessários à realização de uma determinada operação requerida.

O Object Management Group tem também realizado algum trabalho na área de workflow, nomeadamente no que concerne ao desenvolvimento da Object Management Architecture, que tem como base as normas desenvolvidas pela Workflow Management Coalition. Esta arquitectura estabelece a forma como os componentes orientados a objectos em ambientes heterogéneos podem interagir, permitindo a interoperabilidade entre aplicações de workflow com características bastante diferentes. Um dos componentes mais importantes desta arquitectura é o designado Object Request Broker (ORB), que funciona como um mecanismo através do qual os objectos podem efectuar pedidos ou receber respostas na mesma máquina, ou através da rede, de uma forma transparente.

Outra instituição reconhecida, a Internet Engineering Task Force (que define normas usadas na Internet) tem também realizado trabalho na área do workflow. É disso exemplo o protocolo SWAP – Simple Workflow Access Protocol – cujo objectivo é ser simples, leve e extensível para a comunicação de actividades de workflow de longa duração sobre a Internet. O SWAP foi concebido de forma a assegurar a interoperabilidade entre diferentes sistemas de workflow e as aplicações que estes suportam, permitindo a integração e interacção de sistemas e possibilitando o controlo de serviços assíncronos sobre a Internet. Para isto, recorre ao protocolo HTTP e ao

XML para a troca de informação de controlo [Swenson 1998]. A especificação deste protocolo foi proposta para a criação de uma norma. Contudo, este processo foi bastante lento, e uma vez que existia uma enorme pressão para o desenvolvimento de uma norma de interoperabilidade em XML, a Workflow Management Coalition adoptou as ideias básicas do SWAP e fundiu-as com a utilização de ligações em XML na especificação de uma das interfaces do seu modelo de referência. O resultado foi o Wf-XML.

9 Conclusão

Grande parte das metodologias apresentadas neste documento leva em consideração, essencialmente, a representação da sequência de execução das diversas actividades de um processo de workflow. Exemplos disso são os diagramas de fluxos de dados, os fluxogramas, os Grafos e as Redes de Petri. Fica relegada para segundo plano a componente organizacional onde o processo está inserido, o que impede que seja desenvolvida uma visão global do sistema sobre o qual se está a trabalhar. A metodologia WIDE (assente em UML) tenta colmatar este défice, através da incorporação de diagramas relativos à estrutura organizacional. Contudo, a forma como as diversas unidades da organização comunicam e recorrem aos serviços umas das outras não é abordada em grande pormenor.

Por outro lado, a capacidade de participação por parte dos clientes na modelação de um processo de workflow é um aspecto de extrema importância, que pode garantir uma correcta apreensão das questões relevantes para o modo de funcionamento do sistema e assim dar garantias acerca do seu grau de aceitação. O Paradigma Language Action entra em consideração com esta perspectiva, ao reconhecer que a linguagem pode ser utilizada como uma ferramenta no planeamento e coordenação de acções e ao garantir que a análise de requisitos é dada por terminada quando o cliente se dá por satisfeito.

A interoperabilidade é outro factor de extrema importância nos dias de hoje, dado que a comunicação entre diversas empresas em cadeias e redes de valor, associada à heterogeneidade de aplicações nos sistemas de informação é uma realidade cada vez mais usual. Dos métodos descritos nos pontos anteriores apenas as Redes de Petri e os Patterns entram em consideração com questões relativas à modelação da interoperabilidade entre motores de workflow diferentes. Mesmo assim, no segundo caso, tal é feito numa perspectiva mais tecnológica do que metodológica.

Tendo em consideração os pontos fortes referidos atrás para as várias técnicas de especificação de workflow, é possível estabelecer uma boa base de trabalho para o desenvolvimento de uma metodologia de análise deste tipo de sistemas, que englobe aspectos inerentes às necessidades

actuais das organizações relativamente aos sistemas de informação, como sejam a interoperabilidade e a rápida capacidade de resposta. Para além disso, é conveniente que a metodologia englobe também componentes relativas à contextualização do sistema dentro da organização, de forma a representar as suas interacções, não esquecendo ainda componentes que enfatizem a colaboração do cliente no desenvolvimento das aplicações.

10 Referências

Aalst W., “Interorganizational Workflows: An Approach based on Message Sequence Charts and Petri Nets”, Systems Analysis - Modelling – Simulation, 34, 3, (1999), pp. 335-367

Aalst W., Hirnschall A., Verbeek. H, “An Alternative Way to Analyze Workflow Graphs”, Proceedings of the 14th International Conference on Advanced Information Systems Engineering, volume 2348 of Lecture Notes in Computer Science, Berlin, (2002), pp. 535-552 Aalst W., Workflow Patterns, Technical Report, AalstEindhoven University of Technology, Eindhoven, 2002

Air Force Wright Aeronautical Laboratories, ICAM Architecture Part II-Volume IV - Function Modeling Manual (IDEF0), AFWAL-TR-81-4023, June 1981.

Alexander C., The Timeless Way of Building, Oxford University Press, 1979 Austin J., How to do things with words, Harvard University Press, 1962

Avison E., Fitzgerald G., Information Systems Development. In Rethinking Management Information Systems, W. L. Currie and B. Galliers Eds., Oxford University Press, New York, 1999

Baresi L. Casati F., WIDE Workflow Development Methodology, Technical Report, Politécnico de Milão, Itália, 1999

Barros A., Hofstede A., “Towards the Construction of Workflow-Suitable Conceptual Modelling Techniques”. Information Systems Journal, 8, 4, (1998), pp. 313-337

Baskerville R., Fitzgerald B., Fitzgerald G., and Russo N., “Beyond Systems Development Methodologies: Time to Leave the Lamppost?”, In Proceedings of the IFIP 8.2 Conference, Information Technology and Changes in Organizational Work, (G. Walsham, W. Orlikowski, and M. Jones Eds.), Cambridge University, UK, (1995), pp. 235-238

Carlsen S., Conceptual Modeling and Composition of Flexible Workflow Models, Phd Thesis, Norwegian University of Science and Technology, Norway, 1997

Casati F. Ceri S. Pernici B. Pozzi G., “Conceptual Modeling of WorkFlows”, Proceedings of the 14th International Object-Oriented and Entity-Relationship Modelling Conference, Springer Verlag, Australia, (1995), pp.341-354

Cockburn A., Structuring Use Cases with Goals, Journal of Object-Oriented Programming, September-October 1997 (edição electrónica)

Cunha, P., Projecto de sistemas de informação para a realidade emergente: proposta baseada num modelo de carteira de soluções, Tese de Doutoramento, Universidade de Coimbra, Coimbra, 2000

Cunha R., Figueiredo D., “Information Systems Design Under a Different Light”, In Proceedings of the Americas Conference on Information Systems, H. M. Chung Ed., Association for Information Systems, Long Beach, California, USA, (2000), pp. 1184-1191 Eshuis, R Wieringa R. A formal Semantics for UML Activity Diagrams – Formalising Workflow Models, Technical Report, University of Twente, Department of Computer Science, 2001 Filho R., Uma Arquitectura Baseada em Corba para Workflow de Larga Escala, Mhd Thesis, Instituto de Computação de Campinas, 2000

Fisher A., CASE: Using Software Development Tools, John Wisley & Sons Inc, New York, 1988

Fitzgerald B., “Systems Development Methodologies: The Problem of the Tenses”, Information Technology & People, 13, 2, (2000), pp. 13-22

Heinlein Ch., “Workflow and Process Synchronization with Interaction Expressions and Graphs”, Proceedings of the Int'l Conf. on Data Engineering 2001, Heidelberg, (2001), pp. 243-252

Jones, Page, The Practical Guide to structured systems design, 2nd _{Edition, Prentice-Hall, 1988}

Layzell P., Loucopoulos P., Systems Analysis and Development, Chartell-Bratt, Bromley, UK, 1989

Manolescu D., Micro-workflow: a workflow architecture supporting compositional object-oriented software development, PhD Thesis, University of Illinois, 2001

Martin J., McClure C., Structured Techniques: the basis for case, Prentice-Hall, USA, 1988 Medina-Mora R., Winograd T. Flores R. Flores F., “Approach to Workflow Management Technology”, Proceeding of the ACM Conference on Computer-Supported Cooperative Work, (1992), pp. 281-288

National Institute of Standards and Technology, Integration Definition For Function Modeling (IDEF0), 1993

Sadiq S., Orlowska M., Modelling and Verification of Workflow Graphs, Technical Report, nº 386, Department of Computer Science, University of Queensland, Australia, 1996

Sadiq S., Orlowska M., “On Capturing Process Requirements of Workflow Based Business Information Systems”, Proceedings of the 3rd International Conference on Business Information Systems (BIS '99), Poland, (1999), pp. 195-209

Sadiq S., Marjanovic O. Orlowska M., “Managing Change and Time in Dynamic Workflow Process”, The International Journal of Cooperative Information Systems, 9,1, 2000

Shazia S., Orlowska M., “On Capturing Exceptions in Workflow Process Models”, In Proceedings of the 4th International Conference on Business Information Systems. Poznan, Poland, 2000

Swenson K., Simple Workflow Access Protocol (SWAP), Internet Draft, 1998 (http://www.globecom.net/ietf/draft/draft-swenson-swap-prot-00.html)

Themistocleous M Irani Z., “Taxonomy of Factors for information system application integration”, In Proceedings of the Americas Conference on Information Systems, USA, (2000), pp. 955-959

Winograd T., Flores F., Understanding Computers and Cognition, Addison-Wesley, 1986 Workflow Management Coalition, The Workflow Reference Model, version 1.1, 1995

Workflow Management Coalition, Interoperability Abstract Specification, Version 2.0 b, 1999 Workflow Management Coalition, Workflow Standard – Interoperability Wf-XML Binding, version 1.1, 2001

Yadav, S., B., Bravoco. R., Chatfield, A., Rajkumar, T., “Comparison of analysis techniques for information requirement determination”, Communications of the ACM, 31, 9, (1988), pp. 1090--1097.