Sistema de Gerenciamento de Workflows

...

a arquitetura

utilizada, algumas decis˜oes de implementa¸c˜ao, e a organiza¸c˜ao adotada durante o desenvolvimento

do projeto.

1.2 Defini¸c˜oes

Antes de come¸car, ´e importante estabelecer algumas defini¸c˜oes que ser˜ao essenciais para o

entendimento do projeto:

• Workflow (WF): automa¸c˜ao de um processo de neg´ocio, por inteiro ou em parte,

durante o qual informa¸c˜oes, tarefas e documentos s˜ao passados de um participante

para outro, respeitando um conjunto de regras procedurais.

• WorkItem: chamamos de WorkItem uma atividade isolada de um processo definido.

Uma instˆancia de um processo ´e uma cole¸c˜ao de WorkItems (um por atividade executada

ou em execu¸c˜ao).

• Agentes: chamamos de agentes usu´arios ou pap´eis. Os pap´eis s˜ao estruturas hier´arquicas

que foram utilizadas para a representa¸c˜ao de grupos de usu´ario. Cada usu´ario deve pertencer

a pelo menos um papel.

2

1.3 Caso de uso

Aqui, o intuito ´e mostrar um exemplo de como este sistema poderia ser utilizado, ou seja,

uma situa¸c˜ao em que um Sistema Gerenciador de Workflows pode ser bastante ´util.

Empresa de desenvolvimento de software:

Em uma empresa de desenvolvimento de software, temos uma s´erie de etapas que devem

ser seguidas para come¸carmos a desenvolver um software.

Estas etapas s˜ao constitu´ıdas por diferentes atividades e exercidas por v´arias pessoas.

Algo importante a ser notado ´e que essas etapas s˜ao interdependentes, isto ´e, as informa¸c˜oes

geradas em uma etapa s˜ao, muitas vezes, utilizadas nas outras. O fluxo de informa¸c˜oes tem,

portanto, vital importˆancia neste processo.

Basicamente, temos o seguinte fluxo: Tudo come¸ca com o encontro de um funcion´ario

da empresa com o cliente, que dir´a o que quer como resultado do desenvolvimento. Este

funcion´ario tem como objetivo extrair o que ´e realmente importante das informa¸c˜oes que

foram passadas a ele. Em seguida entrar´a com os dados do projeto e do cliente no sistema

interno da empresa.

A seguir, estes dados ir˜ao para as m˜aos de um projetista, que ser´a respons´avel por desenvolver

uma solu¸c˜ao para o projeto, ou seja, fazer uma modelagem do sistema a ser desenvolvido.

Posteriormente, esta modelagem dever´a ir para as m˜aos de outro funcion´ario, respons´avel

por apresent´a-la ao cliente, de um modo que seja f´acil de entender e que fa¸ca o cliente

perceber se ´e isso o que ele realmente quer. Neste ponto, o cliente tem duas escolhas. Ou ele

aceita o projeto, ou ele o rejeita. Caso ele aceite, esta informa¸c˜ao ir´a ao gerente da empresa,

que far´a um contrato com o cliente e dar´a o aval para o in´ıcio do desenvolvimento. Caso o

cliente rejeite, esta informa¸c˜ao tamb´em ir´a ao gerente, que decidir´a se este projeto volta para

as m˜aos do projetista para ser modificado ou se a empresa desistir´a do desenvolvimento,

acabando por aqui o processo. Percebe-se aqui que houve um fluxo de trabalho entre os

diversos participantes.

Um sistema gerenciador de workflows seria perfeito para ser utilizado como sistema interno

desta empresa, pois ele tem justamente a fun¸c˜ao de mostrar para os participantes

corretos quais atividades devem desempenhar e o momento certo em que devem agir. Al´em

disso, o gerente poderia ter um controle completo sobre o andamento do projeto, sobre a produtividade

de cada funcion´ario ou de um grupo de funcion´arios, fazer auditorias, encontrar

poss´ıveis gargalos no processo de produ¸c˜ao entre v´arias outras vantagens.

Vamos supor que a empresa quer, agora, criar um novo departamento: controle de qualidade.

Agora, antes da modelagem ir parar nas m˜aos do funcion´ario que a apresenta ao

cliente, o modelo deve ir para um funcion´ario do controle de qualidade. O que temos aqui ´e

uma mudan¸ca no processo de produ¸c˜ao da empresa. Um sistema gerenciador de workflows

tem tamb´em, como uma de suas caracter´ısticas, tornar f´acil este tipo de atualiza¸c˜ao e at´e

mesmo a cria¸c˜ao de novos processos.

3

2 Arquitetura do sistema

2.1 Vis˜ao geral

A arquitetura utilizada ´e baseada em thin client, que imp˜oe poucos requisitos sobre os clientes

(apenas um navegador que suporte HTML), e dividida em 3 camadas: camada de

apresenta¸c˜ao, camada de neg´ocio e camada de dados. Os clientes comunicam-se apenas com

a camada de apresenta¸c˜ao. A l´ogica de neg´ocios encontra-se no servidor, ´unico que tem

acesso `a base de dados.

Atrav´es da escolha dessa arquitetura, conseguiu-se atingir alguns objetivos, tais como

a facilidade para desenvolver um sistema distribu´ıdo, que fosse