Modelos OO-Method Gerados

Como resultado da aplicação das diretrizes ou regras de transformação especificadas na seção 4.3 anterior, são gerados os modelos objeto (ver seção 3.2.1.3) do OO-Method. Para gerar esses modelos, o Processo Núcleo OOM-NFR recebeu como entrada os modelos i* refatorados na etapa final de Pré-processamento apresentados nas seções 4.2.2, 4.2.3 e 4.2.4. Com isso, o principal objetivo do processo OOM-NFR foi alcançado, ou seja, a partir da análise, tratamento e priorização dos requisitos não-funcionais especificados em i* wiki, obteve-se, como resultado do processo transformativo, diferentes modelos objeto do OO- Method. As figuras a seguir mostram esses modelos com os respectivos comentários.

Na seção de apêndice deste trabalho, está listado o código fonte em QVT (QVT, 2009) e os respectivos comentários da automatização dessas transformações realizadas. Esse esforço em automatizar o processo transformativo OOM-NFR na linguagem de transformação de modelos QVT teve como vantagem tornar a atividade de gerar modelos objeto OO-M a partir do i* mais rápida, menos propensa a erros humanos, entre outras vantagens, citadas na introdução deste trabalho, quando se aborda os objetivos de um processo MDD.

113 Como descrito no apêndice, esta linguagem de transformação de modelos, baseia-se nos metamodelos ECORE das abordagens de origem e destino; recebe uma instância do modelo de origem no formato XMI e gera outra instância do modelo destino também em XMI. Como não havia disponibilidade de editor gráfico para ler e editar o modelo OO- Method gerado no formato XMI através da linguagem de processamento de modelos QVT, os construtores do OO-Method gerados foram desenhados ou editados graficamente através do Eclipse UML2 (ECLIPSE, 2010).

A figura 64 representa o modelo OO-Method gerado a partir da configuração 1 da seção 4.2.2 (primeira análise NFR) denominada:

Configuração 1: Prioriza-se Segurança, Usabilidade e Rapidez (Análise Backward)

114

Nesta figura 64, percebe-se que foram removidos os serviços:

Control Judgment Delay by Manual Form da Classe Work Request Use CAPTCHA da Classe Photo Agency System

A figura 65 a seguir representa o modelo OO-Method gerado a partir da configuração 2 da seção 4.2.3 (segunda análise NFR) denominada:

Configuração 2: Prioriza-se Segurança, mas Quebra-se Usabilidade e Rapidez Julgamento (Análise Forward)

Figura 65. Modelo OO-Method gerado a partir da Configuração 2

Nesta figura 65, observa-se que foram removidos do modelo os seguintes serviços da classe Work Request:

115 To Send Email for Jugdes after elapsed delay

Set maximum delay of X days for jugdment

Entretanto o serviço use CAPTCHA da Classe Sistema PAS foi mantido, pois é responsável por quebrar a usabilidade.

Por fim, a figura 66 representa o modelo OO-Method gerado a partir da configuração 3 da seção 4.2.4 (terceira análise NFR) denominada:

Configuração 3: Quebra-se Segurança, Prioriza-se Usabilidade e Rapidez Julgamento (Análise Forward)

Figura 66. Modelo OO-Method gerado a partir da Configuração 3

116 Estão removidos do modelo os serviços da Classe Photo Agency System:

Use CAPTCHA

By Login and Restrict password To Use a Cluster of Servers

Estão removidos da classe WorkRequest: Control Judgment Delay by Manual Form

Estão removidos da classe User (Usuário): Serviço: Define User Profile

Atributo: Profile

Como se observa em todos os modelos as classes geradas estão com os devidos relacionamentos: associação e agent link. Nota-se também que a maior parte das classes que representam usuários do sistema tem relacionamentos de agent link para com as classes Photo Agency System (ator sistema em i* wiki) e Work Request (principal recurso físico processado pelo modelo). Isso se dá pelo fato dessas classes serem clientes, ou seja, terem visibilidade para os serviços dessas principais classes servidoras Photo Agency System e Work Request.

A geração desses três modelos distintos em OO-Method só foi possível porque o processo OOM-NFR trata, analisa e prioriza os softgoals (requisitos não-funcionais relacionados a produto e interno ao ator sistema) em i* wiki. Isso não ocorre na abordagem de (ALENCAR, 2009), nem nas demais abordagens, conforme mencionado na seção 3.3, onde se faz essa mesma transformação sem contemplar softgoals e se gera apenas um único modelo OO-M a partir do qual não se é capaz de se afirmar se esses softgoals estão satisfeitos (prioridades) e também estão sem conflitos.

Não fosse o pré-processamento (Análise NFR) realizado pelo OOM-NFR, seria gerado apenas um único modelo objeto do OO-Method com todos os serviços gerados a partir das tarefas de i*, pois não seriam considerados os softgoals do modelo de entrada em i*.

4.5 Considerações Finais

Este capítulo apresentou a proposta deste trabalho de pesquisa condensada através do processo OOM-NFR e que objetiva a transformação de um modelo i* para o modelo OO- Method com foco em softgoals. Inicialmente, na seção 4.1 foi ilustrada a visão geral do

117 processo OOM-NFR e seus principais componentes: o Pré-processamento e o Processo Núcleo.

No Pré-processamento (seção 4.2), foram elencadas as atividades responsáveis por realizar a análise dos requisitos não-funcionais. A primeira atividade é verificar se há softgoals no modelo i* a ser processado. Para exemplificar as etapas do processo OOM-NFR foi escolhido, como modelo de entrada, o sistema de agência fotográfica. A principal atividade do pré-processamento é a análise NFR onde é realizada a julgamento dos requisitos não-funcionais, verificando quais deles devem ser priorizados e satisfeitos. Nessa etapa, o analista pode escolher entre a análise “Forward” ou “Backward” (HORKOFF et al. 2010), conforme sua necessidade (ver vantagens e desvantagens na seção 2.4.1) e interage com mecanismo de resolução de fórmulas formalizadas em i* através de um SAT-Solver implementado na ferramenta OpenOME (OPENOME, 2010). Nessa interação, conflitos são resolvidos, prioridades são analisadas, resultando numa configuração final de modelo i* satisfatória. A atividade final do pré-processamento é refatorar essa configuração final para remover os elementos negados e que não vão ser passados para a próxima etapa do processo OOM-NFR: o processo núcleo.

Para demonstrar esse Pré-processamento foram dados três exemplos de análise NFR baseados no modelo i* agência fotográfica. Cada exemplo analisado tinha prioridades distintas (diferentes) em termos dos softgoals, sendo geradas configurações finais também diferentes para atender a cada conjunto de prioridades definida pelo analista.

O Processo Núcleo, seção 4.3, tem como principal atividade transformar o modelo i* para o modelo OO-Method através da aplicação das diretrizes de transformação. O processo núcleo transformativo do OOM-NFR é dividido basicamente em quatro atividades: geração de classes, geração de atributos, geração de serviços e geração de relacionamentos.

Cada uma dessas quatro atividades são decompostas em diretrizes que definem quais elementos i* serão transformados nos elementos semanticamente equivalentes em OO- Method e também como é realizada essa transformação. Ao longo da definição dessas diretrizes são dados exemplos do modelo i* agência fotográfica em que elas podem ser aplicadas.

A atividade final do processo OOM-NFR é um refinamento do modelo OO-Method incialmente gerado, pois como foi mencionado há transformações que dependem da intervenção do analista para ser concluída.

No próximo capítulo 5, será estudada mais detalhadamente, a aplicação do processo OOM-NFR através de um exemplo de sistema de controle de acesso modelado em i*.

119

CAPÍTULO 5