UNIVERSIDADE LUTERANA DO BRASIL CURSO DE CIÊNCIA DA COMPUTAÇÃO CÂMPUS GRAVATAÍ

UNIVERSIDADE LUTERANA DO BRASIL CURSO DE CIÊNCIA DA COMPUTAÇÃO CÂMPUS GRAVATAÍ MODELAGEM E IMPLEMENTAÇÃO DE UM PROTÓTIPO DE WORKFLOW PARA ACOMPANHAMENTO DE TRABALHOS DE CONCLUSÃO DE CURSO Alexsandra Siqueira da Rosa Monografia desenvolvida durante a disciplina de Trabalho de Conclusão de Curso em Informática II e apresentada ao Curso de Ciência da Computação da Universidade Luterana do Brasil, câmpus Gravataí, como pré-requisito para a obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Roland Teodorowitsch Gravataí, dezembro de 2003.

2 Universidade Luterana do Brasil ULBRA Curso de Ciência da Computação Câmpus Gravataí Reitor: Pastor Ruben Eugen Becker Vice-Reitor: Eng. Leandro Eugênio Becker Diretor do Câmpus Gravataí: Prof. Felício Korb Coordenador do Curso de Ciência da Computação (Câmpus Gravataí): Prof. José Luiz Andrade Duizith Coordenador das Disciplinas de Trabalho de Conclusão de Curso (Câmpus Gravataí): Prof. Roland Teodorowitsch Banca Avaliadora composta por: Data da defesa: 11/12/2003. Prof. Roland Teodorowitsch (Orientador) Prof. Rafael Gastão Coimbra Ferreira Prof. Carlos Mário Dal Col Zeve CIP Catalogação na Publicação Rosa, Alexsandra Siqueira da Modelagem e implementação de um protótipo de workflow para acompanhamento de trabalhos de conclusão de curso / Alexsandra Siqueira da Rosa; [orientada por] Roland Teodorowitsch. Gravataí: 2003. 68 p.: il. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação). Universidade Luterana do Brasil, 2003. 1. Workflow. 2. Web. 3. Trabalho de Conclusão de Curso. 4. Software Livre. I. Teodorowitsch, Roland. II. Título. Endereço: Universidade Luterana do Brasil Câmpus Gravataí Estrada Itacolomi, 3.600 Bairro São Vicente CEP 94170-240 Gravataí-RS Brasil

SUMÁRIO LISTA DE FIGURAS...5 LISTA DE QUADROS...7 LISTA DE ABREVIATURAS E SIGLAS...8 RESUMO...9 ABSTRACT...10 1 INTRODUÇÃO...11 1.1 MOTIVAÇÃO E OBJETIVOS...11 1.2 ORGANIZAÇÃO DO TRABALHO...12 2 WORKFLOW...13 2.1 O CONCEITO DE WORKFLOW...13 2.1.1 Definição de processos...13 2.1.2 Atividades...14 2.1.3 Participantes do workflow...14 2.1.4 Papel...14 2.2 TIPOS DE WORKFLOW...15 2.2.1 Ad-hoc...15 2.2.2 Produção...16 2.2.3 Administrativo...17 3 MODELAGEM DE WORKFLOW...18 3.1 MODELAGEM BASEADA EM ATIVIDADES...18 3.1.1 Redes de Petri...18 3.1.2 Modelo de gatilhos...19 3.1.3 Modelo de Casati/Ceri...21 3.2 MODELAGEM BASEADA EM COMUNICAÇÃO...24 3.2.1 Modelo Action Workflow...24 4 PADRÕES PARA WORKFLOWS...26 4.1 MODELO DE REFERÊNCIA...26 4.2 PADRÕES PARA DEFINIR PROCESSOS...27 4.3 FERRAMENTAS LIVRES PARA WORKFLOW...30 4.3.1 Open Business Engine (OBE)...30 4.3.2 Openflow...30 4.3.3 Open For Business (OFBiz)...31 5 ESTUDO DE CASO: TRABALHO DE CONCLUSÃO DE CURSO...32

4 5.1 DESCRIÇÃO DO PROCESSO A SER INFORMATIZADO...32 5.2 MODELO ENTIDADE-RELACIONAMENTO (E-R)...34 5.3 MODELAGEM DO WORKFLOW...34 6 IMPLEMENTAÇÃO DO PROTÓTIPO...38 6.1 UTILIZAÇÃO DO WORKFLOW...38 6.1.1 Login...38 6.1.2 Trocar senha...40 6.1.3 Logout...41 6.1.4 Acessos disponíveis para usuários alunos e professores...41 6.1.5 Acessos disponíveis para usuários administradores...43 6.2 TIPOS DE PENDÊNCIAS...45 6.2.1 Definir orientador...45 6.2.2 Aceitar ou não a orientação...45 6.2.3 Submeter proposta...46 6.2.4 Avaliar a proposta...47 6.2.5 Definir banca...48 6.3 ESTRUTURA DE DIRETÓRIOS DO WORKFLOW...49 6.4 ESTRUTURA PARA CRIAR UMA PÁGINA...49 7 CONCLUSÃO...51 ANEXO A DICIONÁRIO DE DADOS...53 ANEXO B CRIAÇÃO DAS TABELAS...60 REFERÊNCIAS...66

LISTA DE FIGURAS Figura 1 Participantes de um workflow...15 Figura 2 Exemplo de um workflow ad-hoc...16 Figura 3 Exemplo de um workflow de produção...17 Figura 4 Exemplo de um workflow administrativo...17 Figura 5 Exemplo de modelagem utilizando redes de Petri...19 Figura 6 Simbologia básica do modelo de gatilhos...20 Figura 7 Exemplo de modelagem utilizando o modelo de gatilhos...20 Figura 8 Símbolos utilizados na linguagem de especificação...22 Figura 9 Tipos de bifurcação (fork)...23 Figura 10 Tipos de entroncamento (join)...23 Figura 11 Exemplo de modelagem utilizando o modelo de Casati/Ceri...24 Figura 12 Estrutura do laço de workflow...25 Figura 13 Exemplo de modelagem utilizando o modelo de ações...25 Figura 14 Modelo de referência de workflow componentes e interfaces...26 Figura 15 Exemplo da estrutura de um arquivo em XPDL (WfMC, 2002)...28 Figura 16 Esquema do modelo de interoperabilidade da WfMC (2002)... 28 Figura 17 Metamodelo proposto pela WfMC (BARROS, 1997)...29 Figura 18 Exemplo da estrutura de um arquivo de definição de workflows, utilizando pacote (WfMC, 2002)...30 Figura 19 Modelo entidade-relacionamento...34 Figura 20 Processo define orientador...35 Figura 21 Processo submeter à proposta...35 Figura 22 Processo elabora artigo seminário de andamento...36 Figura 23 Processo elabora monografia...36 Figura 24 Processo elabora resumo para defesa do projeto...37 Figura 25 Página de login...39 Figura 26 Página inicial do aluno...39 Figura 27 Página inicial de um usuário administrador...40 Figura 28 Página para trocar senha...41 Figura 29 Página para alterar cadastro...42 Figura 30 Lista pendências...42 Figura 31 Página que lista todos os alunos cadastrados...43 Figura 32 Página para associar alunos na turma...44 Figura 33 Página onde lista as pendências de todos os tipos de usuários...44 Figura 34 Página para definir orientador...45 Figura 35 Página de resposta para aceitar ou não ser orientador...46 Figura 36 Página para submeter proposta...47

6 Figura 37 Página para avaliar proposta...48 Figura 38 Página para definir banca...49 Figura 39 Estrutura para criar página...50 Figura 40 Tabela usuarios...60 Figura 41 Tabela professores...60 Figura 42 Tabela alunos...61 Figura 43 Tabela urls...61 Figura 44 Tabela telefones...61 Figura 45 Tabela endereço...61 Figura 46 Tabela campi...62 Figura 47 Tabela disciplinas...62 Figura 48 Tabela areas_de_interesse...62 Figura 49 Tabela areas_int_prof...62 Figura 50 Tabela titulos...62 Figura 51 Tabela turmas...63 Figura 52 Tabela etapas...63 Figura 53 Tabela pendencias...64 Figura 54 Tabela subetapas...64 Figura 55 Tabela banca_subetapa...64 Figura 56 Tabela banca_etapa...65 Figura 57 Tabela areas_etapa...65 Figura 58 Inserir admin...65

LISTA DE QUADROS Quadro 1 Tabela usuarios...53 Quadro 2 Tabela professores...53 Quadro 3 Tabela alunos...54 Quadro 4 Tabela endereco...54 Quadro 5 Tabela urls...54 Quadro 6 Tabela telefones...54 Quadro 7 Tabela campi...55 Quadro 8 Tabela disciplinas...55 Quadro 9 Tabela areas_de_interesse...55 Quadro 10 Tabela areas_int_prof...55 Quadro 11 Tabela titulos...55 Quadro 12 Tabela turmas...56 Quadro 13 Tabela etapas...57 Quadro 14 Tabela banca_etapa...57 Quadro 15 Tabela areas_etapa...57 Quadro 16 Tabela subetapas...58 Quadro 17 Tabela banca_subetapa...58 Quadro 18 Tabela pendencias...59

LISTA DE ABREVIATURAS E SIGLAS API CSCW DTML E-R OBE OFBiz TCC WAPI WfMC WFMS WIDE XPDL XML ZOPE Application Programming Interface Computer Supported Cooperative Work Document Template Markup Language Entidade-Relacionamento Open Business Engine Open For Business Trabalho de Conclusão de Curso Workflow API and Interchange Formats Workflow Management Coalition WorkFlow Management System Workflow on Intelligent and Distributed database Environment XML Process Definition Language extensible Markup Language Z Object Publishing Environment

RESUMO Este trabalho descreve a modelagem e implementação de um protótipo de workflow para controle de Trabalhos de Conclusão de Curso (TCCs). O principal objetivo deste trabalho é planejar e iniciar o desenvolvimento de uma ferramenta que permita agilizar os procedimentos relacionados a TCCs. Para viabilizar isto, inicialmente foi necessário fazer um estudo sobre a tecnologia de workflow (conceitos, técnicas de modelagem, padrões para workflow e ferramentas baseadas em software livre) e um estudo de caso sobre o gerenciamento de Trabalhos de Conclusão de Curso, com a finalidade de se conhecer o processo a ser automatizado. Após este estudo foi feita a modelagem do workflow utilizando uma das técnicas estudadas e iniciou-se o desenvolvimento de um protótipo do workflow usando software livre. Palavras-chaves: Workflow; Web; Trabalho de Conclusão de Curso; Software Livre.

ABSTRACT Title: The modeling and implementation of a workflow prototype for accompaniment of Course Concluding Works This work describes the modeling and implementation of a workflow prototype for supervision of Course Concluding Works (in Portuguese, TCC Trabalhos de Conclusão de Curso). The main objective of this work is to design ant to start the development of a tool that allows to speed up procedures related to Course Concluding Works. To make that possible, initially it was necessary to make a study about the workflow technology (concepts, modeling techniques, patterns for workflow and tools based on free software) and a case study about the management of Course Concluding Works, with the purpose of knowing the process to be automated. After this study workflow was modeled using one of the studied techniques and the development of workflow prototype was started using free software. Key-words: Workflow; Web; Course Concluding Work; Free Software.

1 INTRODUÇÃO A tecnologia de workflow não é muito recente. Sua evolução se deu durante a década de 70, onde se iniciou a construção de muitos sistemas de workflow. Alguns desses sistemas tinham especificações relativamente complexas. Estes workflows eram formados por uma seqüência de procedimentos que compõem um processo a ser executado e pelos dados que seriam utilizados durante o fluxo de trabalho. Tinha-se grande otimismo em relação à produtividade e à eficiência desta nova tecnologia. Quando os programas para auxiliar a coordenação das tarefas foram introduzidos nas organizações, as pessoas ficaram limitadas a obedecer. Os sistemas de workflow dos anos 70 acabaram interferindo nas rotinas de trabalho em vez de auxiliar a sua execução (NICOLAO, 1998). A partir da década de 80 deu-se maior ênfase à modelagem dos processos de negócios, a groupware e a programas de apoio ao trabalho cooperativo (Computer Supported Cooperative Work CSCW). Durante este período, houve uma reação negativa sobre a automação dos processos de negócios e sistemas de gerenciamento de workflow (NICOLAO, 1998). A partir da década de 90 começaram a aparecer questões e estudos sobre workflow na área de CSCW. A partir destas pesquisas verificou-se a aplicabilidade do workflow no processo de reengenharia, pois tanto a reengenharia quanto o workflow trabalham com o conceito de processo. A diferença é que a reengenharia procura reconstruir o processo da melhor forma e o workflow busca automatizá-lo, transferindo para o computador uma série de responsabilidades que antes eram de funcionários, tais como o trâmite de documentos e a transferência de trabalho, entre outros (NICOLAO, 1998). Observando-se os sucessos e as falhas no decorrer da evolução da tecnologia de workflow, verificou-se a necessidade de pesquisas em sistemas de workflow para as próximas gerações e, conseqüentemente, aumentar a utilização das tecnologias de workflow através do desenvolvimento de terminologias comuns e padrões (NICOLAO, 1998). Para isso foi criado o Workflow Management Coalition (WfMC), uma entidade que visa padronizar os produtos de workflow (HOLLINGSWORTH, 1995). 1.1 MOTIVAÇÃO E OBJETIVOS Este trabalho tem a finalidade de apresentar um estudo sobre a tecnologia de workflow. Iniciando-se pelo estudo dos principais conceitos envolvidos com workflows, técnicas de modelagem, padrões para workflows e ferramentas baseadas em software livre. Este estudo servirá para entender, analisar e melhorar o processo a ser informatizado, a fim de desenvolver um protótipo de um sistema de workflow. Este protótipo permitirá o

12 acompanhamento automático de todo o processo dos Trabalhos de Conclusão de Curso (TCCs). Será modelado para a web e serão utilizadas soluções baseadas em software livre. Atualmente todo o controle do processo de gerência de TCCs, que é feito manualmente, é centralizado na figura do coordenador das disciplinas de TCC. Algumas tarefas típicas do coordenador de TCCs são: controle dos prazos para a entrega de toda a documentação necessária para iniciar o TCC, envio de um aviso aos alunos que estão com o prazo de entrega dos documentos estourado, encaminhamento da proposta para os professores da banca, etc. Utilizando um sistema de workflow a carga de trabalho durante o processo certamente será reduzida, pois o controle passará a ser automático. Isto facilitará o trabalho do professororientador e do coordenador das disciplinas, agilizando a entrega de documentos pelos alunos e, conseqüentemente, reduzindo a utilização de papéis e a necessidade de assinaturas manuscritas, pois os formulários impressos passam a ser eletrônicos. Workflows executados através da web podem também evitar deslocamentos desnecessários até a sede da instituição de ensino, por exemplo. O objetivo principal deste trabalho é, portanto, agilizar o processo de controle de Trabalhos de Conclusão de Curso, utilizando ferramentas de software livre, o que permitirá que o trabalho seja implementado sem nenhum custo. 1.2 ORGANIZAÇÃO DO TRABALHO No capítulo 2, é apresentada a tecnologia de workflow. São explicados brevemente alguns de seus principais conceitos e são apresentados também os tipos de workflows. No capítulo 3, são descritas duas metodologias para a modelagem de workflows, e quais são as técnicas de modelagem que se enquadram nestas metodologias, a fim de que se possa escolher uma das técnicas para fazer a modelagem do workflow de TCCs. No capítulo 4, são apresentados o modelo de referência e os padrões para definição de processos desenvolvidos pela WfMC e algumas ferramentas livres para workflow que procuram seguir os padrões estabelecidos pela WfMC. O capítulo 5 apresenta o estudo de caso sobre o processo de Trabalhos de Conclusão de Curso, com a finalidade de se conhecer o processo a ser informatizado. O capítulo 6 apresenta a implementação do protótipo do workflow para trabalhos de conclusão de curso. No último capítulo, será apresentada a conclusão deste trabalho.

2 WORKFLOW Este capítulo destina-se a dar uma visão geral sobre o que é workflow, e conceituar alguns termos utilizados. 2.1 O CONCEITO DE WORKFLOW A tecnologia de workflow (tradução literal: fluxo de trabalho) evolui a cada dia e sua principal característica é a automatização parcial ou total de processos de acordo com um conjunto de regras e objetivos definidos, que envolvem combinações de atividades humanas e/ou de máquinas, principalmente as atividades de interação com tecnologia de informação, aplicações e ferramentas (HOLLINGSWORTH, 1995). Existem várias visões sobre workflow entre os pesquisadores da área. E, portanto, diferentes ferramentas e ambientes de trabalho, já que cada desenvolvedor interpreta o conceito de workflow de uma forma diferente (TRAMONTINA, 2002). Por não existir um consenso absoluto sobre esta tecnologia, em 1993, foi criado o Workflow Management Coalition (WfMC). Este órgão é formado por um grupo de companhias que se uniram para evitar uma introdução ininterrupta de produtos no mercado sem que houvesse uma padronização. Sem essa preocupação a tecnologia poderia evoluir em várias direções, resultando em incompatibilidades de automatização de processos (HOLLINGSWORTH, 1995). Para Hollingsworth (1995), a definição de workflow é: apoio ou automação computadorizada de um processo de negócio, em seu todo ou em parte. Pode-se dizer que um sistema de workflow é um meio para visualizar, analisar e melhorar processos, a fim de buscar a automatização com organização e tecnologia (TRAMONTINA, 2002). 2.1.1 Definição de processos Para compreender melhor a tecnologia de workflow é necessário saber um pouco mais sobre a definição de processos. Um processo consiste em uma cadeia de atividades que, ao serem executadas, atingem um objetivo de trabalho. Possui condições para indicar o seu início e o seu fim, regras para sua execução, informações individuais sobre as atividades, aplicações a serem utilizadas, participantes, etc. (ALLEN, 2001).

14 Para Barthelmess (1996), um processo é a seqüência de passos que são necessários para que se consiga atingir um objetivo de negócio de uma organização. Uma definição de processo normalmente inclui inúmeros passos de atividades, podendo associar computadores e/ou operações humanas com regras a serem seguidas pelas atividades. Pode ser expressa de várias maneiras, em forma textual, gráfica ou em notação de uma linguagem formal (HOLLINGSWORTH, 1995). Um processo, segundo Ruschel (2000), é uma visão formal de um processo de negócio, sendo representado como um conjunto parcial de atividades. Os sistemas de workflow têm sido indicados como ferramenta para o apoio computacional a processos de negócio, já que estão diretamente relacionados à área de negócios em organizações. Um processo de negócio é um conjunto de uma ou mais atividades relacionadas onde documentos, informações e tarefas são transferidos entre os participantes (RUSCHEL, 2000). Essa transmissão ocorre de acordo com um conjunto de regras definidas para se chegar ao objetivo do negócio (MARSHAK, 1995 apud ARAÚJO e BORGES, 2001; CRUZ, 2000 apud ARAÚJO e BORGES, 2001). 2.1.2 Atividades Uma atividade é um passo lógico a ser dado dentro de um processo (ALLEN, 2001). Pode envolver interação manual ou automatizada. Ou seja, exige recursos humanos e/ou computacionais a fim de suportar a execução do processo. Quando é exigido um recurso, a atividade específica é alocada a um participante do workflow (RUSCHEL, 2000). Segundo Hollingsworth (1995), uma atividade é um passo lógico ou descrição de um pedaço de trabalho que contribui para a realização de um processo. Uma atividade de processo pode incluir uma atividade manual e/ou atividade de workflow automatizada. Pode-se dizer que as atividades são grupos de procedimentos que são executados para alcançar um determinado resultado. 2.1.3 Participantes do workflow Os participantes do workflow podem ser quaisquer indivíduos dentro de uma organização, desde que tenham acesso como usuários ao sistema de workflow (ARAÚJO e BORGES, 2001). Segundo Ruschel (2000), o participante do workflow é o recurso que desempenha o trabalho de uma atividade de workflow. Também denominado como ator ou agente. Pode ser um ser humano, um recurso computacional ou uma unidade organizacional. 2.1.4 Papel Quando se deseja criar uma abstração em torno dos participantes, pode-se utilizar o conceito de papel. Isso evita que nomes de usuários façam parte do modelo de processo (THOM, 2001). Quando um indivíduo é cadastrado como usuário em um sistema de workflow, ele pode ser associado a papéis. O usuário passará então a ter a responsabilidade de execução das atividades que estão relacionadas aos papéis correspondentes em cada processo. Os

15 indivíduos podem estar associados a mais de um papel, ou seja, podem participar de um mesmo processo ou em processos distintos sob diferentes papéis (ARAÚJO e BORGES, 2001). Segundo Araújo e Borges (2001), as atividades ou tarefas em um workflow são realizadas por papéis que estão associados a cada atividade. Os papéis são associados a atores que podem ser indivíduos ou algum agente automatizado. Estes atores executam as atividades (manipulam dados, formulários ou documentos) conforme os papéis assumidos. A Figura 1 mostra a relação entre os participantes de um workflow, papéis e atividades. Figura 1 Participantes de um workflow 2.2 TIPOS DE WORKFLOW Para facilitar o emprego do tipo correto de workflow para cada caso de aplicação, costuma-se classificá-los em três tipos de acordo com suas funcionalidades (TRAMONTINA, 2002). São eles: ad-hoc, administrativo e de produção. Estes tipos não podem ser analisados individualmente. Os processos reais podem apresentar combinações destas três categorias no decorrer de sua execução (MARSHAK, 1995 apud ARAÚJO e BORGES, 2001; CHAFFEY, 1998 apud ARAÚJO e BORGES, 2001). 2.2.1 Ad-hoc Sistemas de workflow ad-hoc são utilizados quando não existe um formato padrão para transferência de informações entre as pessoas (GEORGAKOPOULOS, 1995 apud MOECKEL, 2000). Estes sistemas são pouco estruturados. As tarefas que os compõem geralmente são imprevisíveis ou desconhecidas até o momento de sua execução. Geralmente envolvem coordenação, colaboração ou co-decisão humana (SETTI, 1999 apud MOECKEL, 2000). A ordenação e a coordenação de tarefas não são automatizadas, mas sim controladas pelas pessoas (NICOLAO, 1996). Os usuários finais tornam-se os desenvolvedores e gerentes de seus próprios processos (MARSHAK, 1995 apud ARAÚJO e BORGES, 2001; CHAFFEY, 1998 apud ARAÚJO e BORGES, 2001). Este tipo de workflow é mais flexível do que os outros, dando mais liberdade ao usuário. Possui bom controle do processo, sendo que as definições de processos podem ser modificadas de maneira fácil e rápida, a fim de se adequarem aos problemas que venham a surgir durante sua execução (TRAMONTINA, 2002). Este tipo de sistema também é classificado, por alguns autores, como workflow colaborativo (ULTIMUS, 1998 apud ARAÚJO e BORGES, 2001). Isto porque pode trabalhar em grupo para se chegar a um objetivo comum. Ou seja, um grupo de pessoas se reúne e colaboram entre si para a execução de cada tarefa de um processo (TRAMONTINA, 2002).

16 Um exemplo de workflow ad-hoc é a revisão de trabalhos, onde os revisores não são conhecidos previamente e colaboram na produção de uma revisão em conjunto. Este exemplo, definido por Georgakopoulos (1995) apud Nicolao (1996), pode ser visto na Figura 2. Figura 2 Exemplo de um workflow ad-hoc 2.2.2 Produção Sistemas de workflow de produção são orientados para o gerenciamento de processos bem estruturados e repetitivos. A ordem e a coordenação das tarefas pode ser automatizada (SETTI, 1999 apud MOECKEL, 2000). A intervenção humana no processo é reduzida e o tempo necessário para tais intervenções também é menor. Com isso, ganha-se produtividade sobre a execução de tarefas repetitivas (TRAMONTINA, 2002). Em sistemas de produção não há nenhuma negociação sobre quem fará o trabalho ou como será dirigido (PLESUMS, 2002). As regras e o encadeamento do processo são conhecidos previamente e portanto facilmente determinadas através de uma análise básica do processo corrente. Geralmente os sistemas de produção são processos com poucas mudanças e que ficam localizados em um departamento ou setor (MARSHAK, 1995 apud ARAÚJO e BORGES, 2001; CHAFFEY, 1998 apud ARAÚJO e BORGES, 2001). Workflow de produção engloba um processo de informações complexas, onde existe a necessidade de acesso a múltiplos sistemas de informação (NICOLAO, 1996). Neste tipo de workflow pode-se fazer a integração com os sistemas já existentes com mais facilidade (TRAMONTINA, 2002). Um exemplo de workflow de produção é o processo de requisição de seguros sugerido por Georgakopoulos (1995) apud Nicolao (1996), que pode ser visto na Figura 3.

17 Figura 3 Exemplo de um workflow de produção 2.2.3 Administrativo Sistemas de workflow administrativo são orientados para o gerenciamento de processos com maior grau de estruturação (SETTI, 1999 apud MOECKEL, 2000). O workflow administrativo não abrange processos de informações complexas, e também não requer acesso para múltiplos sistemas de informação (NICOLAO, 1996). Sua principal característica é a facilidade em se definir os processos, podendo ser repetido sem muitas alterações (TRAMONTINA, 2002). A ordem e a coordenação das tarefas pode ser automatizada (SETTI, 1999 apud MOECKEL, 2000). Os sistemas de workflow administrativo, apesar de possuírem diversas características dos sistemas de workflow de produção, são direcionados para atividades administrativas internas da organização. Este tipo é menos exigente em relação a confiabilidade, correção e integração com sistemas externos do que os de produção (BARROS, 1997). Apóiam processos administrativos das organizações, tais como: ordens de compra, pedidos de férias, admissão de funcionários, etc. (MARSHAK, 1995 apud ARAÚJO e BORGES, 2001; CHAFFEY, 1998 apud ARAÚJO e BORGES, 2001). Um exemplo de workflow administrativo é a revisão de trabalhos, onde os revisores são conhecidos previamente e não colaboram na produção de uma revisão em conjunto. Ou seja, eles produzem revisões individuais e um editor combina todas elas gerando a avaliação final. Este exemplo, também apresentado por Georgakopoulos (1995) apud Nicolao (1996), pode ser visto na Figura 4. Figura 4 Exemplo de um workflow administrativo Pode-se classificar o workflow para Trabalhos de Conclusão de Curso como um workflow administrativo.

3 MODELAGEM DE WORKFLOW A modelagem é uma das etapas mais importantes da implementação de um workflow. Para efetuar a modelagem é necessário ter um bom conhecimento sobre o processo a ser modelado. Este conhecimento é adquirido através de entrevistas com os especialistas que conhecem o processo que será automatizado. Quando a obtenção de todo o conhecimento estiver completa, gera-se um modelo de workflow. Existem duas metodologias para a modelagem de workflow. São elas: baseada em atividades e baseada em comunicação (GEORGAKOPOULOS, 1995 apud NICOLAO, 1998). 3.1 MODELAGEM BASEADA EM ATIVIDADES Os modelos de workflow baseados em atividades compartilham conceitos de estruturas dos tipos pré-condições, atividades e pós-condições, além de serem os mais utilizados (RUSCHEL, 2000). Não é necessário ter uma ordem predefinida entre as atividades; o projetista pode modelar o fluxo da maneira que achar melhor (NICOLAO, 1998). Nesta metodologia o trabalho é visto como uma seqüência de atividades a serem executadas. Sendo que nestas atividades há um conjunto de procedimentos iniciais que ao serem executados geram um conjunto de saída (NICOLAO, 1998). A seguir serão apresentados alguns modelos baseados em atividades. São eles: redes de Petri, modelagem por gatilhos e o modelo de Casati/Ceri. 3.1.1 Redes de Petri As redes de Petri foram desenvolvidas a partir do trabalho de Carl Adam Petri. Desde então o seu uso e o seu estudo aumentaram consideravelmente. Em modelagem de workflow, as redes de Petri foram mais utilizadas através de adaptações e extensões. Um exemplo disto é o modelo de gatilhos que utiliza elementos das redes de Petri (RUSCHEL, 2000). Uma forma comum de representar redes de Petri é através de um gráfico composto por elementos de dois tipos: lugares e conexões (transições). No gráfico a representação de lugares é feita através de círculos, e as conexões entre os lugares são representadas através de retângulos ligados por setas aos círculos, que representam os lugares conectados. Os lugares podem ser considerados como entrada ou saída de uma transição. Dentro dos lugares pode haver zero ou mais fichas. Estas fichas representam trabalhos que devem ser processados (AALST, 1995). Segundo Amaral (1997), em uma rede de Petri as atividades de um workflow são modeladas como transições e as dependências entre atividades são modeladas como arcos.

19 Segundo Barros (1997), as redes de Petri não representam explicitamente o conceito de papel. Isso se dá pelo fato deste modelo não ser voltado exclusivamente para a modelagem de workflow. O exemplo mostrado na Figura 5 representa uma parte de um workflow de TCCs, onde um aluno define o tema de seu trabalho e indica um professor para ser seu orientador durante a execução do trabalho. O professor analisa a indicação, e deverá responder para o aluno se aceita ou não ser seu orientador. Se aceitar este deve enviar resposta para que o aluno inicie a próxima etapa, ou seja, iniciar a elaboração da proposta. Caso não aceite o aluno deverá indicar outro professor. Figura 5 Exemplo de modelagem utilizando redes de Petri 3.1.2 Modelo de gatilhos O modelo de gatilhos é uma técnica simples que visa auxiliar a análise e projeto de workflows, com a finalidade de automatizar processos (RUSCHEL, 2000). Esta técnica foi proposta por Stef Joosten (JOOSTEN, 1994 apud AMARAL, 1997). Através de um mapeamento estabelecido pelos próprios idealizadores do modelo, é possível converter o modelo de gatilhos para redes de Petri, isso no seu nível mais baixo de abstração (AMARAL, 1997). Um gatilho é o disparo de uma atividade de workflow pelo fato de uma atividade anterior ter terminado a sua execução (MÖBUS, 2001). Segundo Barros (1997), uma modelagem de workflow, quando envolve analistas e usuários, deve ter um enfoque voltado para atividades, papéis e gatilhos, utilizando apenas retângulos e setas. Mas em estágios mais avançados, o enfoque deve ser apenas para as atividades, podendo seguir a simbologia básica do modelo de gatilhos, conforme mostra a Figura 6.

20 No modelo de gatilhos, cada atividade é representada por um retângulo que contém o nome da atividade (utilizada para representar uma atividade complexa). Um círculo representa uma atividade atômica ou básica, ou seja, não possui estrutura interna (BARROS, 1997). Um exemplo de atividade básica é uma decisão (MÖBUS, 2001). O triângulo é a representação de um ponto de sincronização para gatilhos, ou seja, direcionar gatilhos para várias atividades ou acumular vários gatilhos em um gatilho apenas. Uma seta ou arco aponta para a próxima atividade a ser executada, isso representa que esta atividade é disparada por um evento que ocorreu como resultado da atividade de onde o arco está partindo. O modelo de gatilhos é dividido em colunas, onde cada uma contém as atividades associadas a um papel específico, ou seja, representa cada papel responsável por atividades dentro do modelo de gatilhos (BARROS, 1997). Figura 6 Simbologia básica do modelo de gatilhos A Figura 7 mostra o mesmo exemplo modelado com redes de Petri na Figura 5, porém usando o modelo de gatilhos. Figura 7 Exemplo de modelagem utilizando o modelo de gatilhos

21 Segundo Nicolao (1998), o modelo de gatilhos está habilitado para suportar workflows do tipo ad-hoc e administrativo. Já workflows de produção são difíceis de serem gerenciados neste modelo, visto que para todo evento excepcional, um responsável (humano) precisa ser notificado para seu tratamento. 3.1.3 Modelo de Casati/Ceri O modelo Casati/Ceri foi desenvolvido para o projeto WIDE (Workflow on Intelligent and Distributed database Environment). Este modelo é considerado um dos mais completos para a especificação de workflows (RUSCHEL, 2000). Entre as suas características estão (BARROS, 1997): descrição formal do comportamento interno do workflow, com a definição, interação e cooperação de atividades; relacionamentos entre workflow e seu ambiente, como a alocação de atividades a atores (possibilita a modelagem de papéis); acesso a bases de dados externas (através de comandos SQL); noções de modularização de tarefas (supertarefas); prevê a representação do tratamento de exceções. Para especificar o workflow e seu relacionamento com bancos de dados definiu-se uma linguagem de descrição composta por símbolos (CASATI et al., 1995 apud BARROS, 1997). Estes símbolos podem ser vistos na Figura 8. Os principais elementos que compõem o modelo de Casati/Ceri, são os seguintes: Tarefas: são unidades de trabalho elementares, entregues à execução por um ator, que em conjunto alcançam o objetivo da especificação do workflow. Cada tarefa possui as seguintes características: nome (identifica a tarefa); descrição (apresenta o propósito da tarefa em linguagem natural); pré-condição (condições de início da tarefa); ações (definem como os dados são manipulados pela tarefa); exceções (um conjunto de pares <exceção, reação> usados para indicar que atitude tomar na ocorrência de eventos anormais; toda vez que uma exceção ocorrer, a reação correspondente é executada). Conexões: descrevem interações entre tarefas que permitem o caso fluir da tarefa inicial a final (GUTIÉRREZ, 1997). Duas tarefas A e B podem ser diretamente conectadas, o que indica que quando A terminar B estará pronta para execução. Em outros casos, conexões entre tarefas são executadas por uma tarefa de roteamento ou direcionamento. Pode-se ter uma bifurcação (fork) para iniciar a execução concorrente de tarefas, ou um entroncamento (join) para sincronizar as tarefas depois de uma execução concorrente. As bifurcações (Figura 9) podem ser dos seguintes tipos: - total (depois do término da tarefa predecessora, todas as tarefas sucessoras estão prontas para execução); - não determinística (a bifurcação é associada a um valor k, após o término da tarefa predecessora, k tarefas sucessoras são selecionadas de forma não determinística e estão prontas para execução); - condicional (cada tarefa sucessora está associada a uma condição; depois do término da tarefa predecessora, as condições são avaliadas e somente as tarefas sucessoras com a condição verdadeira estará apta para execução);

22 - condicional com exclusão mútua (agrega à situação anterior a restrição de que somente uma condição pode ser verdadeira, portanto somente uma tarefa sucessora estará apta para a execução). Os entroncamentos (Figura 10) podem ser dos seguintes tipos: - total (a tarefa sucessora torna-se pronta somente depois do término de todas as tarefas predecessoras); - parcial (o entroncamento é associado a um valor k, após o término de k tarefas predecessoras, a tarefa sucessora está apta para execução); - interativo (o entroncamento é associado a um valor k, a tarefa sucessora fica apta toda vez que k predecessores terminam). Símbolos de início e fim: possibilitam a criação e a finalização de uma execução do workflow. Cada workflow possui um símbolo de começo e vários símbolos de término. O símbolo de começo possui somente uma tarefa sucessora (possivelmente uma tarefa de conexão) e os símbolos de término possuem vários símbolos predecessores. Quando qualquer símbolo de término estiver pronto, indica que o workflow está completo. As tarefas que ainda estiverem executando são canceladas. Supertarefas: são utilizadas para agrupar inúmeras tarefas que são relacionadas, bem como para introduzir a noção de modularização, visando diminuir a complexidade do workflow, e para definir pré-condições e exceções comuns para um grupo de tarefas. Elas possuem as características tanto do workflow como das tarefas, e são internamente decompostas em tarefas. Multitarefas: servem para definir um conjunto de tarefas que vão executar o mesmo trabalho em paralelo, mas serão alocadas para diferentes agentes. Cada multitarefa possui um valor j que indica o número de tarefas aptas a serem executadas, quando o antecessor termina. Para especificar quando uma multitarefa dever ser considerada completa, basta comparar com o quórum (valor de referência). Quando o número de componentes finalizado alcança o valor de quórum a multitarefa é finalizada e o sucessor se torna apto a ser executado. Figura 8 Símbolos utilizados na linguagem de especificação

23 Figura 9 Tipos de bifurcação (fork) Figura 10 Tipos de entroncamento (join) A Figura 11 mostra o mesmo exemplo modelado com redes de Petri na Figura 5 e com o modelo de gatilhos na Figura 7, porém usando o modelo de Casati/Ceri.

24 Figura 11 Exemplo de modelagem utilizando o modelo de Casati/Ceri Segundo Nicolao (1998), o modelo de Casati/Ceri também permite a representação de workflows do tipo ad-hoc e administrativo. Os workflows de produção podem ser gerenciados neste modelo, visto que, todo o evento excepcional para o workflow pode ser verificado por um mecanismo de tratamento de exceções definido na própria tarefa de trabalho. 3.2 MODELAGEM BASEADA EM COMUNICAÇÃO Os modelos de workflow baseados em comunicação enxergam o trabalho como um conjunto de interações humanas bem definidas, representando compromissos realizados entre as pessoas envolvidas (SIZILIO, 2000). Uma técnica de modelagem baseada em comunicação é o modelo Action Workflow, que será descrito a seguir. 3.2.1 Modelo Action Workflow Para o modelo Action Workflow (modelo de ações) o processo tem o objetivo de aumentar a satisfação do cliente. As ações que são realizadas no workflow são reduzidas a um conjunto limitado de atos da fala. Este conjunto é classificado e ordenado de forma que possa representar as interações possíveis entre o cliente e o executor (AMARAL, 1997). O modelo de ações é baseado na comunicação entre as pessoas, a fim de representar a coordenação entre elas. Esta metodologia reduz toda a ação de um workflow em quatro fases, baseadas na comunicação entre um cliente e um executor. Estas fases têm o propósito de fazer com que duas ou mais pessoas concordem com relação à execução de determinada ação. O significado de cada fase é descrito a seguir (AMARAL, 1997): requisição: um cliente faz a requisição para que uma ação seja executada ou um executor se oferece para executar alguma ação;

25 negociação: um cliente e um executor concordam sobre a ação a ser executada e definem as condições da negociação; execução: a ação é executada de acordo com os termos estabelecidos. Ao final da tarefa o executor declara ao cliente que a tarefa está pronta; aceitação: o cliente relata sua satisfação (ou insatisfação) com a ação. Caso haja insatisfação, até o final do laço, a situação deve ser resolvida. Um laço de workflow é um conjunto completo destas quatro fases, como pode ser visto na Figura 12. Cada laço de workflow pode ser ligado a outros laços de workflow para completar um processo de negócios. Um executor em um laço de workflow pode ser um cliente em outro (AMARAL, 1997). Segundo Barros (1997), o modelo de ações possibilita a modelagem de papéis. Figura 12 Estrutura do laço de workflow A Figura 13 mostra o mesmo exemplo modelado usando redes de Petri na Figura 5, porém agora usando o modelo Action Workflow. Figura 13 Exemplo de modelagem utilizando o modelo de ações

4 PADRÕES PARA WORKFLOWS Este capítulo destina-se a apresentar o modelo de referência e os padrões para definição de processo desenvolvido pela WfMC. Estes padrões foram definidos para que haja uma padronização da área de workflow, a fim de permitir a especialização dos produtos existentes (AMARAL, 1999). 4.1 MODELO DE REFERÊNCIA O modelo de referência, como pode ser visto na Figura 14 (AMARAL, 1999), estabelece os principais componentes de uma arquitetura de workflow e identifica as interfaces e formatos de intercâmbio para permitir a interoperabilidade entre os produtos. Estas interfaces foram identificadas pelo WfMC para um serviço de workflow como parte de seu programa de padronização (WfMC, 2002). Figura 14 Modelo de referência de workflow componentes e interfaces No modelo de referência são definidas cinco interfaces entre componentes, além de uma interface sobre o sistema de gerência de workflow, denominada WAPI (Workflow API and Interchange Formats). Esta interface representa um conjunto de construções pelas quais os serviços relacionados a sistemas de workflow podem ser acessados. Com isso, pode-se implementar os serviços de workflow de diferentes formas, desde que as interfaces traduzam a

27 implementação particular de cada produto de workflow para a interface padronizada pela WfMC (AMARAL, 1999). O modelo de referência suporta workflows dos tipos ad-hoc e administrativo, assim como o gerenciamento de workflows de produção (SIZILIO, 2000). Para se ter uma visão geral sobre cada interface do modelo de referência, será apresentada uma breve descrição de cada uma. A interface 1 inclui um metamodelo comum para descrever a definição de processos e também um esquema de XML (extensible Markup Language) para o intercâmbio dessas definições (WfMC, 2002). A interface 2 envolve a comunicação com uma aplicação cliente de workflow, realizando operações como a ativação e término de atividades, e a manipulação de listas de trabalho (AMARAL, 1999). A interface 3 trata da comunicação com aplicações externas, invocadas pelo serviço de gerência de workflow para a realização de atividades automatizadas. Esta interface envolve a padronização de interfaces com outros sistemas, o que inclui aspectos como a passagem e retorno de parâmetros (AMARAL, 1999). A interface 4 trata da comunicação entre os sistemas de gerência de workflow (WorkFlow Management System WFMS), desde que estejam envolvidos na administração de partes de um mesmo processo. Com a utilização desta interface, torna-se possível a execução de um processo através de vários WFMS diferentes (AMARAL, 1999). Finalmente, a interface 5 envolve ferramentas de administração e monitoramento dos processos (AMARAL, 1999). 4.2 PADRÕES PARA DEFINIR PROCESSOS Pode-se utilizar diferentes ferramentas para analisar, modelar, descrever e documentar um processo de negócio. A interface de definição de processo de workflow define um formato de intercâmbio que apóia a transferência de definições de processo de workflow entre produtos diferentes (WfMC, 2002). A interface 1 provê um método comum para ter acesso e descrever uma definição de processo de workflow, para isto estabeleceu-se um metamodelo. Utiliza-se este metamodelo para definir objetos e atributos dentro de uma definição de processo. A gramática de XPDL (XML Process Definition Language) está relacionada a estes objetos e atributos. E, baseado neste modelo, qualquer ferramenta de modelagem de workflow pode fazer, através do modelo de interoperabilidade, a importação da definição de workflow e a exportação dos modelos nela gerados para XPDL (WfMC, 2002). O modelo de interoperabilidade utiliza XML como mecanismo para intercâmbio da definição de processo, e uma forma padrão para o intercâmbio é o XPDL. Um exemplo da estrutura de um arquivo XPDL pode ser visto na Figura 15 (WfMC, 2002).

28 <?xml version="1.0" encoding="us-ascii"?> <Package xmlns="http://www.wfmc.org/2002/xpdl1.0" xmlns:xpdl="http://www.wfmc.org/2002/xpdl1.0" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xyz="http://www.xyzeorder.com/workflow" xsi:schemalocation="http://www.wfmc.org/2002/xpdl1.0 http://wfmc.org/standards/docs/tc-1025_schema_10_xpdl.xsd" Id="0" Name="sample workflow process"> <PackageHeader /> <ConformanceClass GraphConformance="NON_BLOCKED" /> <Script Type="text/javascript" /> <TypeDeclarations /> <Participants /> <Applications /> <DataFields /> <WorkflowProcesses> <WorkflowProcess Id="1" Name="EOrder" AccessLevel="PUBLIC" /> <WorkflowProcess Id="2" Name="CreditCheck" AccessLevel="PRIVATE"> <ProcessHeader /> <FormalParameters /> <DataFields /> <Participants /> <Applications /> <Activities /> <Transitions /> </WorkflowProcess> </WorkflowProcesses> </Package> Figura 15 Exemplo da estrutura de um arquivo em XPDL (WfMC, 2002) Pode-se utilizar vários mecanismos diferentes para transferir os dados de definição de processo entre sistemas de acordo com as características dos negócios. Em todos os casos a definição de processo deve ser expressa em uma forma derivada de um conjunto de objetos, relações e atributos que expressam seus conceitos. O conceito de intercâmbio da definição de processo pode ser visto no modelo de interoperabilidade conforme mostra a Figura 16 (WfMC, 2002). Modelos de Workflow DECLARE WORKFLOW PROCESS <CREDIT> READ APPLICATION IF FIELDS = ALL CALL EXTRACT OTHERWISE... END; > < > < > > < < XPDL Padrão para o intercâmbio de definições de workflows CAMADA DE IMPORTAÇÃO/EXPORTAÇÃO Representação interna do WFMS específico WFMS (Motor de Workflow) Figura 16 Esquema do modelo de interoperabilidade da WfMC (2002) O metamodelo apresenta os conceitos de um sistema de workflow e seus relacionamentos, como pode ser visto na Figura 17. Para dar uma visão geral sobre o

29 metamodelo, serão descritas algumas das entidades deste modelo (AMARAL, 1999). São elas: Definição do processo de workflow: sua função é fornecer informações para outras entidades dentro do processo. É um recipiente para o próprio processo e provê informação associada com administração (data de criação, autor, etc.) ou pode ser utilizado durante a execução do processo (parâmetros de iniciação, prioridade de execução, prazos a serem conferidos, etc.), ou seja, serve para indicar o processo de workflow. A definição do processo de workflow define os elementos que compõem um workflow. É possível definir vários processos de workflow dentro de um pacote, a fim de compartilhar as mesmas ferramentas e participantes. A Figura 18 mostra o exemplo da estrutura de um arquivo de definição de workflow, utilizando pacote (WfMC, 2002). Atividade de processo de workflow: sua função é identificar as diversas atividades que compõem o workflow. Pode-se destacar alguns atributos desta entidade, tais como: o responsável pela execução da atividade, a ferramenta invocada, bem como as pré-condições e as pós-condições de sua execução (WfMC, 2002). Informação de transição: serve para armazenar os relacionamentos de dependência entre as atividades. Os atributos desta entidade, são: atividades predecessoras, atividades sucessoras e condições para a transição (AMARAL, 1999). Definição de participante de workflow: define os participantes e papéis que executam o processo. Pode ser um ser humano ou um recurso computacional. Alguns atributos desta entidade, são: estratégia de alocação de atividade, capacidade de execução e custo (WfMC, 2002). Definição de aplicação de workflow: serve para descrever as ferramentas disponíveis para serem invocadas pelo WFMS. Os principais atributos desta entidade são: aplicação e parâmetros utilizados (AMARAL, 1999). Dados relevantes para o processo de workflow: são os dados gerados por uma determinada ação e que serão necessários para as outras atividades, ou para uma transição, ou para uma ferramenta. Seus atributos principais são: tipo de dado e valor (AMARAL, 1999). Figura 17 Metamodelo proposto pela WfMC (BARROS, 1997)

30 <xsd:element name="workflowprocess"> <xsd:complextype> <xsd:sequence> <xsd:element ref= xpdl:processheader"/> <xsd:element ref= xpdl:redefinableheader" minoccurs="0"/> <xsd:element ref= xpdl:formalparameters" minoccurs="0"/> <xsd:group ref="xpdl:datatypes"/> <xsd:element ref= xpdl:datafields" minoccurs="0"/> <xsd:element ref= xpdl:participants" minoccurs="0"/> <xsd:element ref= xpdl:applications" minoccurs="0"/> <xsd:element ref="xpdl:activitysets" minoccurs="0"/> <xsd:element ref= xpdl:activities" minoccurs="0"/> <xsd:element ref= xpdl:transitions" minoccurs="0"/> <xsd:element ref= xpdl:extendedattributes" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:nmtoken" use="required"/> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="accesslevel"> <xsd:simpletype> <xsd:restriction base="xsd:nmtoken"> <xsd:enumeration value="public"/> <xsd:enumeration value="private"/> </xsd:restriction> </xsd:simpletype> </xsd:attribute> </xsd:complextype> </xsd:element> <xsd:element name="workflowprocesses"> <xsd:complextype> <xsd:sequence> <xsd:element ref= xpdl:workflowprocess" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> </xsd:element> Figura 18 Exemplo da estrutura de um arquivo de definição de workflows, utilizando pacote (WfMC, 2002) 4.3 FERRAMENTAS LIVRES PARA WORKFLOW Esta seção destina-se a apresentar uma visão geral sobre algumas ferramentas livres para workflow. As ferramentas consideradas são as seguintes: Open Business Engine (OBE), Openflow e Open For Business (OFBiz). Estas ferramentas foram selecionadas, pois são as que de alguma forma procuram seguir os padrões da WfMC. 4.3.1 Open Business Engine (OBE) OBE é uma biblioteca de classes Java que implementa um ambiente completo de workflow, seguindo os padrões da WfMC. O sistema é composto por uma série de módulos, cada um formado por um conjunto de classes Java (VIERO, 2002). O modelo de objetos de OBE é baseado na especificação XPDL da WfMC. XPDL provê meios para definir processos de workflow em XML, podendo ser criado em qualquer editor de texto. A unidade básica estabelecida em XPDL é um pacote, que provê meios para definir aplicações, participantes e dados que são acessíveis a todas as definições de processos dentro do documento de XPDL (EDEN, 2002). 4.3.2 Openflow O Openflow é um projeto realizado pela empresa italiana ICube. Esta empresa define o Openflow como um sistema de gerenciamento de workflow baseado em atividades. Este

31 projeto busca uma solução com arquitetura aberta e interoperável, além de funcionar em um ambiente que possibilite a portabilidade entre diferentes plataformas (VIERO, 2002). O propósito do Openflow é seguir todas as diretrizes estabelecidas pela WfMC. Esta ferramenta possui integração com o ambiente ZOPE (Z Object Publishing Environment), a fim aproveitar a sua versatilidade (OPENFLOW, 2002). ZOPE é um servidor de aplicação para web, que permite criar e gerenciar objetos através da Internet. ZOPE utiliza uma linguagem de marcação para modelos de documentos (Document Template Markup Language DTML) para construir as páginas web (LATTEIER e PELLETIER, 2003). O Openflow é visto como um objeto do ZOPE, ou seja, é composto por objetos instalados como um produto agregado ao ZOPE. Cada um desses objetos disponibiliza uma API (Application Programming Interface), que deve ser acessada pelas aplicações que farão uso do Openflow (VIERO, 2002). 4.3.3 Open For Business (OFBiz) O projeto Open For Business (OFBiz) é mais amplo que um sistema de gerenciamento de workflow (VIERO, 2002). David E. Jones e Andy Zeneski são os desenvolvedores responsáveis por este projeto. Atualmente está disponível para download a versão 2.0 beta 3. A idéia do projeto OFBiz é permitir flexibilidade e portabilidade, dando suporte a inúmeros servidores de aplicação, banco de dados, sistemas operacionais e ambientes de desenvolvimento (VIERO, 2002). Todas as entidades do OFBiz são definidas em arquivos XML, baseados nas especificações da WfMC. A linguagem para definição de processos é a XPDL (VIERO, 2002). O OFBiz possui um conjunto de aplicações web prontas. A principal delas é chamada WebTools, onde é possível gerenciar configurações do ambiente e realizar tarefas administrativas do OFBiz. Outra aplicação, chamada WorkEffort, implementa um ambiente cliente para as aplicações de workflow (VIERO, 2002). Para se utilizar o workflow é necessário ter a definição da XPDL do processo a ser executado. O OFBiz não possui uma ferramenta de modelagem de processos. A definição de processos deve ser escrita em XPDL para que seja importado para o repositório de entidades do workflow. O motor de workflow do OFBiz não implementa laços (loops) (VIERO, 2002).