Representação de Workflow Flexível

Sobre representação para workflow flexível podemos citar Sadiq et al.(2001), Mangan & Sadiq (2002) e Sadiq et al.(2005) que apresentam um conjunto de características importantes sobre as formas de modelagem de sistemas de workflow flexíveis, conforme descrito a seguir:

• Flexibilidade por Definição: a flexibilidade pode ser construída no modelo

quando são definidas todas as possíveis ocorrências do fluxo de trabalho. As limitações da flexibilidade por definição ficam evidentes, pois resultariam em um modelo altamente complexo que em alguns casos pudesse ainda estar incompleto, devido ao fato de ser praticamente impossível capturar a totalidade de necessidades de um domínio.

• Flexibilidade por Granularidade: a flexibilidade pode ser alcançada

encapsulando detalhes das atividades dentro das tarefas do fluxo de trabalho e mantendo sub-atividades internas flexíveis, sendo somente a parte externa controlada diretamente pelo sistema de workflow. Esta idéia pode ser aplicada a uma extensão limitada, mas não pode ser usada em um nível genérico sem comprometer a finalidade da tecnologia do workflow em coordenar e controlar o fluxo de atividades do processo. Porém, na definição das atividades atômicas é importante definir a granularidade mais apropriada para cada atividade, de modo que os usuários não repitam ciclos desnecessários de atividades.

• Flexibilidade por Templates: a flexibilidade pode ser obtida fornecendo

modelos separados para um determinado tipo de fluxo de trabalho. Isto melhora ligeiramente a legibilidade e conseqüentemente a manutenibilidade do modelo. Contudo, escolhendo um tipo de fluxo de trabalho em um conjunto de modelos podemos estar restritos a um número razoavelmente pequeno de opções.

Com base nestas características os autores apresentam uma representação de sistemas de workflow flexível que consiste em uma seqüência de atividades, organizada por quatro tipos de operadores para determinar o fluxo da execução (choice, merge, fork e synchronizer) e uma atividade especial de configuração denominada “build activity”.

Na definição do modelo de workflow, a atividade de configuração consiste em um conjunto de atividades denominadas fragmentos, que podem dar forma a uma composição válida para o processo. A build activity pode representar ainda um sub- processo dentro do workflow.

A flexibilidade do workflow é representada nesta atividade de configuração, pois dentro do conjunto de atividades definidas na atividade de configuração, podem ocorrer vários fluxos de execução que têm sua variação justamente neste momento. A Figura 27 apresenta um exemplo de definição de processo, com a notação proposta pelos autores para um workflow flexível.

Figura 27: Representação de um workflow flexível (adaptada de SADIQ et al. 2001) A seqüência das atividades B, C e D indica que uma atividade só pode ser executada após a conclusão da anterior, mostrando dependência entre as atividades. O operador fork indica a execução simultânea no processo, permitindo que um único fluxo de execução seja dividido em múltiplos fluxos que podem ser executados em paralelo. As atividades B, C e D podem ser executadas simultaneamente as atividades E e F.

O synchronizer consiste na junção dos fluxos paralelos numa única linha do controle. A atividade G será executada somente após a junção do fluxo das atividades B, C e D com o fluxo das atividades E e F. O choice representa um ponto no processo do

workflow onde uma das diversas possibilidades é escolhida conforme o resultado de

uma atividade anterior. Isto significa que a atividade E ou a atividade F será executada dependendo da atividade A. O merge permite que, a partir de vários fluxos diferentes, continue sem necessidade de sincronização. A conclusão da atividade E ou da atividade F provocará a seqüência do fluxo.

Finalmente o build é um conjunto de atividades que representa um sub-processo configurável que pode ser executado conforme uma regra pré-estabelecida, ou

fork synchronizer merge choice begin end

A

B

C

D

E

F

G

H

I

J

simplesmente não ser executado. A Figura 28 mostra as opções de execução do build conforme a seguinte regra: “as atividades H e/ou I devem ser executadas seqüencialmente, antes da atividade J”.

Figura 28: Opções de execução do build

Como a regra define que as atividades H e I devem ser executadas em seqüência, elas podem ser instanciadas conforme os build1 ou build2, antes da atividade J. Os

build3 e build4 representam a instanciação da atividade H ou da atividade I. E

finalmente, o build5 representa uma situação onde nenhuma das atividades é executada.

3.3 Workflow na Educação

Sistemas de workflow já vêm sendo utilizados em âmbito acadêmico para auxiliar nos mais diversos processos. Destacam-se trabalhos de coordenação em

groupware, baseados em mecanismos do workflow e ferramentas para concepção e

administração de cursos.

O foco no trabalho colaborativo, desenvolvido nas pesquisas de CSCW, derivou o conceito de aprendizagem colaborativa apoiada por computador (CSCL), onde a aplicação de sistemas de workflow tem sido estudada. Os dois conceitos, apesar de semelhantes, apresentam algumas características distintas. O CSCW possui a finalidade de facilitar a comunicação e a produtividade do grupo de trabalho, com foco no produto das interações. A CSCL almeja sustentar uma aprendizagem eficaz em grupo e seu foco é no processo de interação (CAMPOS et al., 2003) (FISCHER et al., 2007).

H I J build1 I H J build2 I J build3 H J build4 build5

No contexto de CSCL, Raposo et al. (2004), Fuks et al. (2004b) e Lucena et al. (2006) apresentam os serviços de colaboração do ambiente AulaNet, que são organizados em serviços de comunicação, de coordenação e de cooperação (Figura 29).

Figura 29: Classificação dos serviços do ambiente AulaNet (LUCENA et al., 2006) Os serviços de coordenação são baseados em workflow e envolvem serviços de pré-articulação do fluxo de atividades, seu gerenciamento e serviços de pós-articulação. A pré-articulação envolve as ações que são necessárias para se preparar a coordenação, devendo ser concluídas geralmente antes do início da cooperação. Consiste na identificação dos objetivos, tradução destes objetivos em tarefas, seleção dos participantes e distribuição das tarefas entre eles. A pós-articulação ocorre após o fim das tarefas e envolve a avaliação e a análise das tarefas resumidas na documentação do processo colaborativo. Já a gerência das tarefas que estão sendo realizadas é o ato de controlar as interdependências entre as tarefas que são realizadas para alcançar um objetivo.

Gonzalez et al. (2002) explicam que os sistemas de gerência do workflow já são utilizados em ambientes de CSCL há alguns anos para organizar execução das tarefas e atribuições da seqüência do trabalho do grupo de aprendizagem. Nesse contexto, ainda segundo os autores, a literatura a respeito de sistemas de workflow salienta a falta de flexibilidade nas situações que requerem modificações na definição do modelo de processo do workflow.

Santoro (2001) e Santoro et al. (2002) propõem um modelo de infra-estrutura para suporte à aprendizagem baseada em projetos com a utilização de um sistema de

workflow onde as tarefas são planejadas e acompanhadas pelos usuários aprendizes. Os

autores explicam que o desenvolvimento de um projeto pode ser definido como um processo, dividido em etapas ou eventos, que por sua vez são relacionados uns aos outros formando um fluxo de trabalho. Cada etapa é concretizada através da execução de uma ou mais atividades, as quais possuem objetivos específicos e geram algum tipo de produto. O modelo tem o Servidor de Processos como um dos componentes chaves da arquitetura do ambiente cooperativo (Figura 30), pois é responsável pela execução do processo de trabalho dos estudantes (workflow) e uma ferramenta para edição de processos é o ponto de partida para o uso dos ambientes instanciados a partir da infra- estrutura proposta.

Figura 30: Arquitetura do Ambiente Cooperativo (SANTORO, 2001)

Santoro et al. (2002) comentam a existência de um grande número de ambientes computacionais que propõem o desenvolvimento de projetos em grupo, porém a maioria não disponibiliza suporte à definição de processos e a todas as suas etapas. Para isso os autores utilizam o modelo de cooperação para aprendizagem baseada em projetos,

desenvolvida por Santoro (2001), que contempla esses aspectos e apóia o desenvolvimento destes sistemas.

Esse modelo foi testado e seus resultados mostraram melhorias em relação à cooperação (participação e contribuições significativas) em projetos com processo definido para outros sem processo definido. A utilização de processos, definidos explicitamente, apresentou melhores resultados em termos de cooperação do que os que não tiveram processos definidos. Processos bem estruturados auxiliam na produção de produtos finais com mais qualidade, resultantes da quantidade e do nível das contribuições dos participantes do trabalho. Com base nesse estudo, Santoro et al. (2002) observam que os resultados mostraram indícios de que os mecanismos para a definição e o acompanhamento do processo ajudam a estimular a cooperação em grupos de aprendizagem desenvolvendo projetos, porém, os meios de interação através das novas tecnologias ainda estão em fase de exploração.

Santoro & Santos (2006) apresentam uma proposta de um ambiente para suporte à aprendizagem organizacional apoiado na definição explícita dos processos de trabalho e na integração destas atividades com processos de aprendizagem. A arquitetura do ambiente é composta por: um sistema de workflow para apoio à definição e execução dos processos de trabalho; ferramentas colaborativas para apoio à aprendizagem vinculada às atividades do processo de trabalho; programas de e-learning baseados em cenários do processo de trabalho e comunidades de prática no contexto da organização para compartilhar conhecimento gerado em projetos e permitir o acesso a especialistas.

Cesarini et al. (2004) apresentam uma arquitetura em rede para os sistemas de gerência de aprendizagem. Nessa arquitetura as atividades dos estudantes são guiadas por um motor de workflow, que deve ser capaz de interpretar as descrições de processos pouco estruturados, definidos pelos autores como processo de aprendizagem ad-hoc. O motor deve criar as instâncias de processo e permitir que elas possam ser ativadas, suspendidas ou encerradas. Além disso, deve permitir interações com as aplicações externas, controlar a execução utilizando dados de controle do workflow e dados do negócio, bem como permitir aos administradores controlar a execução do fluxo do processo.

Ainda segundo Cesarini et al. (2004), cada usuário (estudante e professor) do sistema tem uma worklist que lhe apresenta um conjunto de atividades (manuais ou automáticas) a serem executadas a fim de satisfazer as necessidades de colaboração que o processo de aprendizagem pode envolver. O serviço de controle do workflow pode ser considerado como uma máquina de transição de estados onde uma atividade muda de estado em resposta aos eventos externos (a conclusão de uma atividade) ou as decisões específicas do controle efetuadas por um motor de workflow (cancelar uma atividade dentro de um processo). As transições entre estados ocorrem em resposta aos comandos particulares enviados ao motor de workflow, ou em conseqüência das condições de transição definidas no processo que está sendo executado (condição dependente de tempo ou de dados).

Sizilio (1999) e Botev et al. (2005) apresentam trabalhos onde conceitos e tecnologias de workflow são utilizados para automatizar atividades de processos administrativos das instituições de ensino. Dentre alguns fluxos de trabalho identificados, destacam-se a formulação de turmas e a definição das grades de horários, além de disponibilizar funcionalidades de acompanhamento e notificação das atividades para os atores envolvidos.

Dahmer et al. (2006), apesar de não tratarem de sistemas de workflow, apresentam uma proposta de um modelo para processos de cursos à distância, embasados na área de Tecnologia de Processo de Software, cujos conceitos foram empregados na definição do “Processo de Curso”. O modelo de Processo de Curso é constituído pelas atividades que compõem um curso a distância (projeto, execução, avaliação e outras). Os agentes que realizam as atividades, que geram os produtos e que controlam os recursos necessários para a realização da atividade, são definidos no modelo de processo proposto.

Em Yong (2005) é descrita uma experiência na condução do processo de ensino/aprendizagem e das atividades de uma universidade (University of Southern

Queensland) utilizando uma plataforma de sistemas baseada em sistemas de workflow.

O workflow foi utilizado como mecanismo para analisar e implementar os processos do sistema de aprendizagem em ambiente de e-Learnig, que é dividido pelo autor em

quatro sub-sistemas de workflow ou sub-processos: sub-workflow de ensino, sub-

workflow de aprendizagem, sub-workflow de administração e sub-workflow de infra-

estrutura.

Yong (2005) explica ainda que uma análise coerente do co-relacionamento entre as principais atividades dos quatro sub-sistemas de workflow, permite identificar algumas atividades como os elementos chaves para o processo de aprendizagem. Estes elementos chaves quando bem modelados e gerenciados aumentam o desempenho de todo o workflow de aprendizagem indicando uma melhoria significativa no processo de ensino/aprendizagem como um todo.

Pereira (2003) explica que os ambientes de aprendizagem eficazes devem promover uma elevada cooperação e as técnicas de workflow podem contribuir para esta eficácia porque, nestes ambientes, a criação e a entrega de índices de aprendizagem são realizadas tipicamente por indivíduos com a execução de seqüências específicas e pré- definidas das atividades. Para isso, o autor propõe um ambiente de suporte para uma aplicação colaborativa e interativa no processo de ensino/aprendizagem orientado a Objetos de Aprendizagem reutilizáveis Reusable Learning Objects – RLOs. São apresentados estudos preliminares a respeito da definição de uma infra-estrutura baseada na web e em sistemas de gerência do workflow para suportar um ambiente de aprendizagem colaborativo.

As atividades administrativas permitem um tratamento mais simples, quando da utilização de tecnologias de workflow para implementar soluções desta natureza. Isso ocorre devido à facilidade de definição dos processos de negócio, que geralmente possuem um considerável grau de estruturação e são pouco suscetíveis a alterações. Entretanto, conforme observado por Gonzalez et al. (2002), estas características não se apresentam como válidas para aplicações que envolvam atividades didáticas ou colaborativas, pois nestes casos o processo não pode, ou não deve ser pré-definido, permitindo a sua flexibilização.