Flexibilidade na Execução de Processos

Modelos de processos de software possuem características peculiares porque envolvem pessoas realizando tarefas criativas. Não é possível prever antecipadamente todo o desenvolvimento de software. Assim, o processo deve poder ser construído aos poucos e o mecanismo de processos deve lidar com processos incompletos. Além disso, processos de software envolvem incerteza e não-determinismo. Escolhas entre caminhos alternativos devem ser permitidas durante a execução, e essas escolhas podem depender de resultados de atividades anteriores. Esses são requisitos gerais que, quando atendidos, podem aumentar a flexibilidade da execução de processos.

Flexibilidade é uma característica bastante citada na literatura sobre ambientes de gerência de processos, sejam processos de software ou de negócios (workflow). Maior atenção foi dedicada ao tema em decorrência da constatação de que processos são executados por pessoas, e que falhas no tratamento dado a esses usuários podem inviabilizar a utilização da tecnologia e ainda ocultar seus benefícios. Além disso, flexibilidade tem sido requerida por todas as fases da evolução de processos de software, não se restringindo somente à fase de execução. Cugola (1998) discute o problema da baixa adoção de PSEEs pela indústria e aponta a falta de flexibilidade dos PSEEs como a mais provável causa para o problema. Por isso, várias abordagens para tratamento de flexibilidade em PSEEs têm sido propostas, tais como: (HEINL et al., 1999; BIDER; KHOMYAKOV, 2000; SLISKI, 2001; JOERIS; HERZOG, 1999; AALST, 1999; HAGEN; ALONSO, 2000).

Apesar das propostas existentes, não há um consenso sobre a definição de flexibilidade na área de processos. Em ambientes de gerência de workflow, segundo Heinl et al (1999), flexibilidade consiste em permitir modificações dinâmicas no processo e a escolha de diferentes caminhos alternativos de execução. Já em propostas para PSEEs, segundo Arbaoui et al. (2002), uma linguagem de modelagem de processos multiparadigma é considerada flexível, assim como é considerado flexível o PSEE que fornece diferentes paradigmas de interação com o usuário dependendo da atividade do processo. A flexibilidade de um PSEE também pode ser interpretada como a possibilidade de integrar diferentes ferramentas em sua arquitetura (GRUNDY, 2002) ou ainda como a possibilidade de criar novos fluxos de controle para a linguagem de modelagem (JOERIS; HERZOG, 1999). Porém, é comum encontrar a mudança

dinâmica de processos⁴ (ou suporte a evolução de processos) como uma característica de flexibilidade (por exemplo, em (HEINL et al., 1999; BOGIA; KAPLAN, 1995; AALST, 1999)).

A partir do que foi encontrado na literatura sobre o assunto, constata-se que o conceito de flexibilidade de execução de processos de software é usado para definir a propriedade de mecanismos de execução que toleram a informalidade, o envolvimento humano e processos incompletos sem deixar que os processos tornem-se inconsistentes. E, sendo o mecanismo de execução o componente que interpreta um modelo descrito em uma PML, pode-se dizer que a PML contribui com a flexibilidade de execução através de construtores adequados que facilitem o uso da mesma.

2.4.1 Aspectos Gerais da Flexibilidade na Execução de Processos

Este trabalho considera que a flexibilidade da execução é uma propriedade que atende ao usuário de um PSEE e não aos desenvolvedores do PSEE, e que requer:

• Modificação dinâmica durante a execução: Deve ser possível alterar o processo, seja o conteúdo de atividades ou o fluxo de controle durante a execução, sendo que essa modificação deve ser tratada para que o estado do processo se mantenha consistente. A partir dessa possibilidade são derivadas as seguintes:

− Execução de processos incompletos: Como é possível modelar o processo enquanto está sendo executado, então é possível que o processo inicie incompleto. Segundo Fuggetta (2000) as PMLs devem permitir que sejam modelados processos incompletos e informais que possam ser posteriormente detalhados se necessário;

− Instanciação das atividades do processo durante a execução: As informações sobre pessoas e recursos para atividades poderão estar disponíveis somente após o início da execução de um processo. Esta característica permite que seja iniciada a execução de um processo com partes abstratas que serão instanciadas somente quando estiverem aptas a executar. Dessa forma, a alocação de pessoas e recursos pode ser adiada.

• Escolhas entre caminhos alternativos: Essa escolha geralmente é prevista na modelagem, se a linguagem usada fornecer recursos para tal. O projetista de processo pode prescrever alguns caminhos alternativos no processo e condições lógicas a serem satisfeitas para que o caminho correto seja escolhido. Essas condições somente serão verificadas no momento em que o caminho tiver que ser escolhido. Portanto, dependendo da situação corrente, o processo pode mudar de rumo sem que o projetista tenha que monitorar essa situação;

• Possibilidade de adaptação ao usuário desenvolvedor: Essa adaptação possui foco na interação com o usuário e corresponde a reconhecer e agir de acordo com o perfil do mesmo durante a execução. Utilizando-se de

4

métricas, informações gerenciais e informações fornecidas pelo próprio usuário, o ambiente pode representar as atividades do processo de maneira diversa e adequar a orientação ao processo em função desse perfil;

• Gerência e tratamento de eventos com possibilidade de modificação automática do processo: Ao invés de monitorar exaustivamente a execução do processo, o gerente pode programar o mecanismo de execução para agir em determinadas situações de forma automática. Para isso, o mecanismo de execução deve manter o registro de todos os eventos ocorridos e ainda deve possibilitar a definição de estratégias para tratamento desses eventos. Com isso, é possível que o próprio mecanismo de execução seja capaz de modificar o processo durante a execução em resposta a algum evento. Essa característica também foi citada por Fuggetta (2000) quando afirma que os PSEEs devem ser tolerantes e gerenciar inconsistências e desvios no modelo de processo.

Já que a modelagem pode ocorrer durante a execução, considera-se que qualquer recurso que aumente a flexibilidade da modelagem contribui com a flexibilidade da execução, como por exemplo, o uso de técnicas de reutilização de processos. Por ser de grande importância para o conceito de flexibilidade na execução de processos, o tópico sobre mudanças dinâmicas será tratado na seção seguinte.

2.4.2 Mudanças Dinâmicas

Mudanças ocorrem com freqüência em um modelo de processo de software. Algumas mudanças são pré-planejadas ou não alteram tanto a execução do processo enquanto outras podem alterar toda a estrutura do processo. Existem mudanças estáticas, ou seja, realizadas antes da execução. Por exemplo, normalmente as definições de um processo necessitam ser especializadas, generalizadas, adaptadas a diferentes classes de projetos (reutilização de processo) ou aperfeiçoadas de acordo com mudanças organizacionais ou experiências anteriores. Outras mudanças são dinâmicas, alterando definições enquanto os processos são executados em função de falhas detectadas, necessidade de aperfeiçoamento ou simplesmente porque alguns aspectos da execução de processos não puderam ser determinados antecipadamente.

As mudanças dinâmicas durante a execução de processos são bastante comuns e difíceis de tratar, necessitando de suporte adequado por parte da linguagem de modelagem e do mecanismo de execução. Além de afetar a execução e a continuação do processo, as mudanças dinâmicas podem requerer modificações compensatórias na realização do processo (isto é, para tratar a ocorrência de possíveis efeitos colaterais). Por exemplo, pode ser necessário apagar informações, desfazer operações, retirar itens da lista de tarefas dos usuários, ou cancelar tarefas que causarão efeitos externos (como por exemplo, cancelar reuniões com o cliente).

A necessidade de permitir mudanças dinâmicas implica na inclusão de recursos específicos no formalismo de modelagem e no mecanismo de execução. Ferramentas de inspeção e análise podem ser necessárias para que o gerente de processo seja capaz de inspecionar o estado da execução do processo e de analisar o impacto de mudanças.

Em ambientes de workflow são geralmente tratados processos de negócio ou de manufatura, onde cada atividade ocorre para vários casos, sendo que um caso é, por exemplo, uma compra ou a fabricação de um item. Portanto, quando ocorre mudança no processo, é necessário pensar sobre como isso afetará os casos que ainda não chegaram no ponto da mudança. Além disso, deve ser decidido se a mudança afetará somente os casos novos ou também os que estão em andamento. A mudança que ocorre em um processo que afeta vários casos é chamada de evolucionária (AALST, 1999), pois tem origem na necessidade de aperfeiçoamento ou otimização do processo em questão para vários casos. Várias abordagens para tratar mudanças dinâmicas em workflow restringem-se a mudanças evolucionárias, como por exemplo, os trabalhos de Sadiq et al. (2000a; 1999; 2000c), Aalst (1999), e Bider e Khomyakov (2000).

Ao contrário da maioria das abordagens de workflow, onde mudanças dinâmicas devem tratar vários casos executando em um processo, a tecnologia de processos de software lida com mudanças para casos específicos, o que é chamado de mudança ad-hoc (AALST, 1999). Processos de software são, em geral, específicos para um software sendo desenvolvido (ARBAOUI et al., 2002), e cada processo sendo executado corresponde a um caso. As mudanças buscam prover soluções específicas para atender ao usuário de um caso ou para tratar exceções. Um dos principais problemas com mudanças ad-hoc é tratar a consistência de uma instância específica de processo, evitando mudanças que possam introduzir deadlocks ou afetem atividades anteriores.

O que se observa dos PSEEs existentes na literatura é que a maioria adota um paradigma particular de gerência de mudanças (como por exemplo (JØRGENSEN, 2001; SLISKI et al., 2001; KRAPP, 1998; SADIQ et al., 2000a)) ou não possui facilidades para isso.

Arbaoui et al. (2002) propõe uma comparação entre PSEEs onde um dos requisitos a serem comparados é o suporte à evolução de processos. A capacidade de lidar com mudanças dinâmicas faz parte desse suporte à evolução. As estratégias para tratar mudanças são duas: evolução off-line e on-line. Na off-line a mudança ocorre antes da execução, enquanto na on-line ocorre durante a execução. Quando um processo necessita de mudança on-line, as seguintes situações são possíveis (ARBAOUI et al., 2002):

• Caso 1: A modificação está sendo realizada em um fragmento que ainda não está em execução. Nesse caso, o processo aceita a mudança realizada; • Caso 2: A modificação está sendo realizada em um fragmento anterior ao

ponto em que o processo está sendo executado, mas o estado do processo é coerente com as modificações. Portanto não há necessidade de modififcar o estado atual;

• Caso 3: A modificação está sendo realizada em um fragmento anterior ao ponto em que o processo está sendo executado, porém o estado do processo não é consistente com a mudança realizada, o que ocasiona um desvio do processo. Duas abordagens são possíveis: tolerar a mudança e gerenciar o desvio ou reexecutar o processo para que o processo observado volte a um estado consistente;

• Caso 4: A modificação está sendo realizada no fragmento de processo que está em execução. Nesse caso os estados do processo observado e do processo modelado podem estar inconsistentes e recai na mesma situação do caso 3.

Em (ARBAOUI et al., 2002) são mostrados três tipos de solução para evolução on-line considerando os casos apresentados:

• Solução A (Interfragment on-line evolution support): Trata os dois primeiros casos de propagação de mudança. O fragmento de processo sendo modificado ainda não está sendo executado e pode ser modificado ou substituído (casos 1 e 2);

• Solução B (Interfragment on-line evolution support with interfragment reenactment): O fragmento de processo pode ser modificado (após sua execução) e reexecutado (caso 3);

• Solução C (as duas soluções anteriores com Internal-fragment reenactment): Permite a modificação do fragmento de processo mesmo que esteja sendo executado. A execução é suspensa, o fragmento é modificado e reexecutado (caso 4).