Exemplos de Utilização

Nesta seção, são apresentados dois exemplos de aplicação da abordagem PREViA: um deles possui foco de visualização na aderência da implementação (representada pela arquitetura emergente) à arquitetura conceitual, enquanto o outro possui foco na visualização da evolução de um sistema em termos da implementação. Os cenários apresentados retratam situações específicas e são apenas exemplos; acredita-se que haja outros cenários em que o uso da abordagem PREViA também pode ser útil.

2 _{Na Matemática, o complemento de um subconjunto A’ (pertencente a um conjunto A) é o conjunto de}

42

É importante ressaltar que, para fins didáticos e de ilustração, estes exemplos apresentam cenários relativamente simples. Sabe-se, no entanto que, em cenários reais, a verificação da aderência e a percepção da evolução são tarefas difíceis e complexas, em função do tamanho do sistema e do número de modificações e manutenções feitas durante o tempo, dentre outros fatores.

4.4.1 Exemplo 1 – Foco de Visualização da Aderência

O primeiro exemplo faz uso de um projeto fictício, denominado HotelSystem, adaptado de PRUDÊNCIO (2008). A equipe do projeto é formada por um engenheiro de software (responsável por gerenciar todo o processo de desenvolvimento), um arquiteto de software e três desenvolvedores. Toda a equipe utiliza um sistema de controle de versões para gerenciar a evolução dos artefatos gerados em suas atividades no processo.

Com base nos documentos de especificação dos requisitos, o arquiteto de software elabora um modelo conceitual que, em sendo inspecionado e aprovado, é repassado para os desenvolvedores, que iniciam a etapa de implementação. O modelo conceitual, elaborado na ferramenta UML2Tools (ECLIPSE FOUNDATION, 2010a), é exibido na Figura 4.3.

Figura 4.3 – Modelo conceitual do projeto HotelSystem

Em um determinado momento do desenvolvimento, um engenheiro de software deseja examinar o andamento do processo de desenvolvimento. Para isto, é efetuado o

check-out do código fonte do projeto. Em seguida, de posse de uma versão do modelo

43

código fonte, o engenheiro de software verifica a aderência da versão mais recente da implementação ao que foi inicialmente planejado no modelo conceitual. Ao utilizar a abordagem PREViA, é exibido o modelo representado na Figura 4.4.

Figura 4.4 – Visualização de aderência do projeto HotelSystem

A partir desta visão, é possível observar que a classe Guest não foi

implementada (e foi criado um atributo client, do tipo Client, na classe

Reservation). Além disso, os atributos da classe RoomType (que também não foi

implementada) parecem ter sido implementados diretamente na classe Room.

Percebe-se, nesta situação, que o modelo conceitual já não representa mais o que está sendo implementado no sistema. Cabe ao engenheiro de software decidir se (i) o modelo conceitual deverá ser atualizado com as informações modificadas pelos desenvolvedores, ou (ii) a equipe de desenvolvimento deverá ser alertada da detecção do desvio do planejamento inicial, efetuando ações corretivas nas próximas versões.

A Figura 4.5 exibe o valor de precisão e cobertura calculado para cada elemento do modelo, segundo o algoritmo descrito no Apêndice A.

44

Resultado da comparação Precisão Cobertura nci nc ni nii

Em ambos os modelos 0,7 0,53846154 Apenas no conceitual 1 0

Herança de "Cliente" Apenas no conceitual 1 0 0 1 0 0 Atributo "email" Apenas no conceitual 1 0 0 1 0 0

Apenas no conceitual 1 0

Atributo "name" Apenas no conceitual 1 0 0 1 0 0 Atributo "price" Apenas no conceitual 1 0 0 1 0 0

Em ambos os modelos 0,33333333 0,5

Atributo "number" Em ambos os modelos 1 1 1 1 1 0 Atributo "type" Apenas no emergente 0 1 0 0 1 0 Atributo "price" Apenas no emergente 0 1 0 0 1 0 Atributo "roomType" Apenas no conceitual 1 0 0 1 0 0

Em ambos os modelos 1 1

Atributo "name" Em ambos os modelos 1 1 1 1 1 0 Atributo "rooms" Em ambos os modelos 1 1 1 1 1 0 Atributo "reservation" Em ambos os modelos 1 1 1 1 1 0

Em ambos os modelos 0,66666667 0,66666667

Atributo "room" Em ambos os modelos 1 1 1 1 1 0 Atributo "code" Em ambos os modelos 1 1 1 1 1 0 Atributo "guest" Apenas no conceitual 1 0 0 1 0 0 Atributo "client" Apenas no emergente 0 1 0 0 1 0

Em ambos os modelos 1 1

Atributo "name" Em ambos os modelos 1 1 1 1 1 0 Classe "Reservation" Classe "Client" Pacote "hotel" Elemento Classe "Guest" Classe "RoomType" Classe "Room" Classe "Hotel"

Figura 4.5 – Valores de precisão e cobertura para elementos do projeto HotelSystem

4.4.2 Exemplo 2 – Foco de Visualização da Evolução

O segundo exemplo foi baseado no projeto Floggy (FLOGGY OPEN SOURCE GROUP, 2010), um framework de persistência de dados J2ME disponível em código aberto. Os modelos utilizados no exemplo são derivados do código fonte deste projeto, mas os dados de caracterização do cenário são fictícios.

O projeto é desenvolvido por uma equipe cujos membros estão geograficamente distantes, e é composta de um gerente de projetos, dois arquitetos de software e dez desenvolvedores. Toda a equipe utiliza um sistema de controle de versões para gerenciar a evolução dos artefatos gerados em suas atividades no processo.

Um dos membros da equipe (desenvolvedor) viajou de férias por 15 dias e, ao retornar, deseja verificar a situação ou estado atual de um módulo do projeto em questão. De posse da abordagem PREViA, o desenvolvedor seleciona o intervalo de versões que deseja visualizar (no caso, o intervalo compreende desde a última versão na qual trabalhou até a versão mais atual disponível no repositório). Em seguida, a abordagem PREViA exibe um diagrama representando a primeira versão do intervalo (ou seja, a versão na qual ele trabalhou antes de sair de férias), representada na Figura 4.6.

45

Figura 4.6 – Primeira versão do intervalo selecionado do projeto Floggy

Em seguida, por meio de uma linha do tempo, o desenvolvedor visualiza o andamento do projeto, e chega ao instante representado pelo diagrama exibido na Figura 4.7.

Figura 4.7 – Visualização de evolução do projeto Floggy

A partir desta visão, é possível notar que, desde a última versão na qual o desenvolvedor trabalhou, surgiram três classes (CollectorFactory, JarPackager e

NoOpCollector), sendo que duas destas classes implementam uma interface recém-

46

SetAddDefaultConstructorAction foi removida, e foi criado um atributo log, do tipo EclipseLog, na classe JarPackager. Como neste cenário o desenvolvedor já estava anteriormente alocado ao projeto, é possível que, em função do conhecimento prévio, ele consiga avaliar quais foram as possíveis razões para tal evolução.

Caso o desenvolvedor necessite de mais informações, ele pode procurar o(s) autor(es) das modificações e direcionar questões mais específicas, opcionalmente fazendo uso da visão gerada pela abordagem PREViA, por se tratar de uma visão em mais alto nível quando comparada ao código fonte, e cujo foco está voltado para as diferenças existentes.

Os valores de precisão e cobertura entre estes modelos são 0,522 e 0,973, respectivamente. Como o projeto possui muitos elementos, o cálculo detalhado se encontra na Figura A.1 do Apêndice A.