Análise de Contexto

Segundo Ali [2], contexto pode ser definido como um estado do mundo que é relevante para um objetivo de um ator. Nesta etapa, o modelo de processos de negócio é analisado para identificar os contextos que podem afetar o modelo. Analisando o domínio, os contextos podem ser identificados. Estados de sistemas e também usuários podem ser descritos como contexto. O contexto pode descrever:

• O que está acontecendo? • Onde eles estão localizados?

• Quais são os recursos disponíveis para uso?

O contexto pode ser analisado através de um conjunto de fatos e statements que estão conectados [2]. Fatos podem ser avaliados, já os statements não. Para que um statement assuma um valor verdadeiro, deve existir um conjunto suficiente de evidências que realize a comprovação. Essas evidências são encontradas por meio das avaliações dos fatos [5]. A decomposição termina quando é possível descrever todas as variáveis que permitem verificar se o contexto foi ativado. O objetivo é obter uma fórmula de fatos apoiados por variáveis monitoráveis. Os seis passos abaixo são utilizados para obter o conjunto de contextos associados às variantes.

1. Selecionar uma variante do modelo de variabilidade a ser avaliado;

2. Identificar fatores que afetam a execução do fragmento de processo de negócio de uma variante;

3. Decompor os fatos e statements que apoiam o contexto; 4. Associar as variáveis monitoráveis aos fatos;

5. Validar a interferência com outros contextos; 6. Repetir os passos para outras variantes.

A Figura 2.4 exibe um exemplo de decomposição de contexto. Por exemplo, o contexto Bombeiros serem chamados automaticamente é apoiado por três fatos: Alarme de fogo está ativo, Fogo foi confirmado, e Serviços de rede está funcionando. Quando as variáveis que estão associadas a este contexto atingem o valor especificado, o contexto é ativado e a variante que está associada a este contexto pode fazer parte do processo.

40

Figura 2.4 Exemplo de decomposição de contexto. Adaptado de [48].

2.2.4

Ligar Variantes & RNF

Na abordagem BVCCoN, os requisitos não-funcionais são utilizados para representar as preferências dos stakeholders. Nesta etapa, os RNFs que são importantes para o processo são identificados e também é definido o impacto de cada variante sobre os RNFs. Assim, os RNFs são ligados às variantes do processo de negócio que foram levantadas nos passos anteriores da abordagem.

Os RNFs que serão levados em consideração são identificados e então é feito uma descrição dos RNFs e variantes. Essa elicitação pode ser realizada entrevistando pessoas que estão envolvidas no processo de negócio. Em seguida, pode-se associar os RNFs com as variantes para representar as preferências dos stakeholders sobre a seleção de possíveis variantes. RNFs representarão atributos de qualidade que os stakeholders esperam do sistema.

Uma vez identificados os RNFs, é permitido realizar as ligações entre estes e as variantes do processo. A abordagem BVCCoN utiliza a escala qualitativa proposta pelo NFRFramework [30] para realizar essas ligações. O impacto mais positivo sobre um requisito não-funcional é chamado Make, um impacto parcialmente positivo Help, um impacto parcialmente negativo é chamado de Hurt e um impacto mais negativo Break. Esses valores são mapeados respectivamente para, ++,+,-,– na escala da abordagem BVCCoN.

A Figura2.5mostra uma versão simplificada de um modelo BVCCoN. As variantes Tocar alarme de fogo manualmentee Tocar alarme de fogo automaticamente fazem parte do ponto de variação VP2, que possui o operador lógico XOR. Este operador lógico indica que apenas uma das variantes pode ser selecionada. A variante Tocar alarme de fogo automaticamenteestá relacionada com o contexto Serviços de backup estão funcionando, assim, esta variante só poderá ser selecionada se o contexto for verdadeiro. A Tabela

2.3apresenta as contribuições da Figura2.5, permitindo uma melhor visualização. Os espaços em branco são compreendidos como EqualContribution (=).

42

Tabela 2.3 Contribuição para os RNFs Confiança e Performance

Variante/RNF Confiança Performance

Procurar por fogo ou fumaça automaticamente ++ Procurar por fogo ou fumaça pessoalmente ++ -

Tocar alarme de fogo manualmente + -

Tocar alarme de fogo automaticamente ++

Chamar os serviços de segurança pública automaticamente – ++ Chamar os serviços de segurança pública por linha telefônica -

Chamar os serviços de segurança pública por telefone móvel + + Abrir saídas de emergência manualmente ++

Abrir saídas de emergência automaticamente ++

2.2.5

Realizar a Configuração

Existem duas maneiras de executar a configuração de um processo de negócio: a primeira é selecionando as variantes e a segunda é priorizando algum requisito não-funcional. Existem diversas maneiras de analisar o impacto de cada configuração sobre os RNFs, por exemplo: análise top-down e bottom-up.

A top-down é feita selecionando um RNF que terá maior prioridade, e em seguida, derivado uma configuração de processo que maximiza o RNF selecionado. Ou seja, cada ponto de variação é avaliado para identificar a variante que melhor se ajusta ao requisito não-funcional selecionado.

Na análise bottom-up, uma configuração de processo é definida selecionando um sub-conjunto de variantes e então, uma matriz de ligação é utilizada para calcular o impacto da configuração sobre o requisito não-funcional. A Figura2.6apresenta uma solução de um processo priorizando o RNF Performance.

Para descrever os conceitos de ponto de variação, variantes, requisitos não-funcionais e informações contextuais, é utilizado um mecanismo chamado de metamodelagem. Assim, através de um metamodelo, é possível definir os elementos de modelagem e seus respectivos relacionamentos [4].

2.2.6

Trabalhos Relacionados

A seguir, apresentamos uma comparação entre estudos que descrevem abordagens de configuração de modelos de processos de negócio em ambientes dinâmicos descritos na literatura.

Trabalhos Identificados

44

Figura 2.6 Exemplo de uma instância de processo. Adaptado de [48].

La Rosa [28] propôs uma abordagem para capturar variabilidade de sistemas baseada em modelos de questionário. Ela apoia a configuração com um processo e um modelo de questionário. O modelo de questionário consiste de um gráfico que define as questões a serem respondidas. Questões são respondidas em sequencia, lidando para a identificação de ações que são realizadas pela configuração.

Os modelos de processos são representados por modelos de processos configuráveis escritos em Configurable Yet Another Workflow Language (C-YAWL). Esta linguagem é uma extensão que possui a característica de descrever os pontos de variação do processo dentro do modelo de processo. O modelo de processo com a informação de variabilidade está alinhado com o modelo de questionário. A configuração do processo é realizada pelo usuário respondendo questões que levam a um novo modelo de processo.

Requirements-driven design and configuration management of business processes Lapouchnian et al. (2007) [29] apresenta uma abordagem que alinha processos de negócio com modelos de Goal. Modelos de Goal são usados para descrever os objetivos do negócio e as preferências dos usuários. Através da decomposição dos modelos, é possível obter uma estrutura de goals [objetivos] do processo de negócio. O modelo de goalssegue uma estrutura em formato de árvore na qual os goals são decompostos em subgoals.

A descrição da informação de variabilidade é adicionada a estrutura do modelo de goals. Por isso, as informações do processo está misturado com anotações. As anotações que descrevem variabilidade são baseadas em IF-THEN-ELSE, regras assim como os operadores lógicos (AND, OR). Os requisitos não-funcionais são descritos como Softgoalse as contribuições para Softgoals representam as preferências dos usuários sobre

possíveis escolhas. Os pontos de variação são os lugares onde existe uma decomposição OR. Com o objetivo de obter um modelo de fluxo de processo, eles descrevem os passos do começo da configuração com uma análise de Softgoal e seleção de variantes. Após a seleção, uma transformação gera o modelo de fluxo do processo em BPEL.

Business processes contextualisation via context analysis

De La Vara et al. (2010) [5] propôs uma metodologia para adicionar contextualização aos modelos de processos de negócio. A proposta é obter modelos de processos de negócio que são perceptíveis ao contexto. A metodologia descreve vários passos e inclui anotações de contexto que é baseada na abordagem de [2], que apoia análise contextual. Os contextos consistem de árvores com facts e statements que são avaliados para identificar quando um contexto está ativo.

As informações contextuais são requeridas para ativar mudanças no fluxo dos pro- cessos. Com o objetivo de incluir contexto, eles estenderam a notação BPMN para ter contextos embarcados nos fluxos de sequência que ligam as atividades. A descrição da variabilidade é adicionada ao modelo de processo, onde o caminho alternativo no fluxo do trabalho representa as variantes.

Discussão

As abordagens de configuração de processos de negócio são complexas e consomem muito esforço e tempo. A abordagem BVCCoN integra metamodelos de análise realizados durante os passos do processo BVCCoN, que foca em uma clara separação de interesses. De La Vara et al. (2010) [5] usa variabilidade de contexto para definir variabilidade de processos. Na BVCCoN, quando o contexto é aplicado, os pontos de variação e variantes já estão definidos. Isto reduz a análise de contexto para apenas contextos relevantes, evitando problemas com a cobertura do modelo de processo e reduzindo a análise de contexto que não será utilizada.

Quando comparado com a abordagem proposta por Lapouchnian et al. (2007) [29], podemos ver que a integração de metamodelos também é uma vantagem. Observe que em BVCCoN, a análise de requisitos é realizada independemente da análise de variabilidade. Durante a construção do modelo BVCCoN, a análise de contribuição estabelece ligações entre variantes e RNFs. Por isso, a análise de preferências pode ser refeita se uma variante é adicionada ou removida. Ao contrário, a abordagem proposta por Lapouchnian et al. (2007) mistura as informações de processo com a descrição de variabilidade e softgoals. Quando uma variante é adicionada ou removida, todo o modelo deve ser revisado.

Diferente das outras duas abordagens, La Rosa [28] propôs compartilhar menos, similar a BVCCoN. É utilizado diferentes estratégias para lidar com variabilidade e confi-

46

guração. Por esta razão, La Rosa foca na redução da intervenção do usuário na realização da configuração, a abordagem BVCCoN tenta reduzir a necessidade da interação com o usuário durante os passos da configuração.

Algumas abordagens apresentaram ferramenta de suporte, porém, os benefícios podem ser limitados devido a abrangência da ferramenta em relação as etapas das abor- dagens. A comparação foi baseada na avaliação de documentos, assim, as ferramentas de suporte não foram avaliadas. Mesmo compartilhando algumas características em comum com as outras abordagens, a BVCCoN mostra mais vantagens que desvantagens quando considerado o cenário da configuração de processos dinâmicos. BVCCoN é uma abordagem mais completa, sua ferramenta permite modelar diferentes perspectivas relaci- onadas aos processos de negócio (requisitos não-funcionais, variabilidade e informações de contexto), sem a necessidade de estender uma linguagem de modelagem existente ou utilizar uma linguagem apenas por cobrir alguma das perspectivas citadas anteriormente. A Tabela 2.4 mostra um sumário das abordagens em relação aos critérios discutidos anteriormente.

Tabela 2.4 Sumário de Critérios

Abordagem Variabilidade Configuração Modelo de Processo Ferramenta

La Rosa (2009) C-YAWL/YAWL Seleção de Nós Questionário e C-YAWL Sim

Lapouchnian et al. (2007) Modelo de Goals/BPEL Transformação de modelos Modelo de goals Sim

De La Vara et al. (2010) BPMN estendido Validação de contexto Modelo BPMN Não

BVCCoN BPMN Transformação de modelos Modelo BVCCoN Sim