4 Metode
4.8 Diskusjon av metodevalg
O processo PREF foi utilizado para apoiar algumas evolu¸c˜oes do framework GREN relacionadas a requisitos funcionais e n˜ao funcionais.
A autora utilizou o PREF para incorporar no framework GREN alguns requisitos funcionais n˜ao cobertos por ele. A ausˆencia desses requisitos foi evidenciada durante a condu¸c˜ao de alguns estudos de caso de reengenharia utilizando o PARFAIT (Cap´ıtulo 3) e, conseq¨uentemente, o arcabou¸co ARA. O PREF foi tamb´em utilizado em um trabalho de mestrado (Silva, 2004b), para incorporar ao framework GREN um sub-sistema de controle de seguran¸ca. A necessidade desse requisito n˜ao funcional foi notada desde a constru¸c˜ao do framework, mas n˜ao havia sido implementado devido `a ausˆencia de tempo e `a decis˜ao do escopo da primeira vers˜ao do framework.
Nesta Se¸c˜ao s˜ao relatadas resumidamente as evolu¸c˜oes feitas no framework GREN com o apoio do PREF. Ser´a dado enfoque apenas `as atividades que s˜ao inerentes `a evolu¸c˜ao de frameworks.
Atividade 1) Controlar a variabilidade do framework
Na Tabela 4.3 apresenta-se parcialmente o Hist´orico de Requisitos contendo alguns requisitos n˜ao cobertos pelo framework GREN durante a reengenharia, utilizando o PARFAIT, e durante o desenvolvimento de sistemas no dom´ınio de Gest˜ao de Recursos de Neg´ocios.
Portanto, esses requisitos foram implementados nos sistemas gerados a partir da instancia¸c˜ao do framework GREN (atividade “Projetar, modificar e testar o sistema para satisfazer o requisito” do PREF) e possuem situa¸c˜ao igual a “pendente”. Alguns desses requisitos poderiam ser satisfeitos n˜ao completamente pelo framework, por exemplo, os requisitos 1 a 5 poderiam ser implementados como atributos do tipo string, mas isso poderia causar problemas de inconsistˆencias e redundˆancias no futuro. A necessidade de outros requisitos (por exemplo, de controle de seguran¸ca, de suporte a diferentes tipos de bases de dados e a distribui¸c˜ao (Braga, 2003)) foi observada durante o desenvolvimento do pr´oprio framework, mas n˜ao foram implementados por falta de tempo e tamb´em devido a decis˜ao de escopo.
Para decidir sobre a evolu¸c˜ao do framework GREN, realizou-se uma an´alise dos requisitos listados no Hist´orico de Requisitos, a fim de verificar quais eram essenciais ao dom´ınio de tal framework. Essa an´alise foi feita em duas etapas: 1) analisou-se, de acordo com o conhecimento do engenheiro de dom´ınio, em quais outras situa¸c˜oes no dom´ınio de Gest˜ao de Recursos de Neg´ocios os requisitos poderiam ocorrer, conforme apresentado na Tabela 4.4; e 2) verificou-se o n´umero de ocorrˆencia de cada requisito (cuja situa¸c˜ao era igual a “pendente”) no hist´orico.
O requisito 7 foi considerado essencial ao dom´ınio de Gest˜ao de Recursos de Neg´ocios. Nesse requisito, relacionado ao sistema de reparo de buracos proposto por Pressman (2005), o recurso ´e o buraco, que ´e mantido pelo departamento de reparos da prefeitura, mas o dano em si ´e apenas um registro que n˜ao ´e considerado pelos tipos de gerenciamento tratados pela linguagem de padr˜oes GRN. Esse requisito foi adicionado ao Hist´orico de Requisitos para que pudesse ser implementado em momento oportuno.
O requisito 8, de controle de seguran¸ca, tamb´em foi analisado, embora j´a se soubesse desde a implementa¸c˜ao do GREN que seria um requisito desej´avel para o dom´ınio, mas n˜ao implementado. Esse requisito tamb´em foi adicionado ao Hist´orico de Requisitos para que pudesse ser implementado em momento oportuno. Esse ´e um requisito que deve estar presente em praticamente todas as aplica¸c˜oes do dom´ınio.
A mesma an´alise ocorreu com o requisito 9, relacionado ao desempenho. Sua ausˆencia foi notada durante a reengenharia do sistema legado de vendas (Silva, 2004a), realizado por um aluno de inicia¸c˜ao cient´ıfica, com o apoio do PARFAIT. O baixo desempenho do novo sistema foi observado quando a base de dados do sistema legado foi migrada para a do novo sistema e os registros, principalmente os relacionados aos produtos cadastrados (em torno de quarenta mil), tiveram que ser carregados na interface gr´afica. Com a an´alise realizada, concluiu-se que corrigindo esse problema no pr´oprio framework, outros sistemas criados a partir de sua instancia¸c˜ao tamb´em teriam vantagem com essa evolu¸c˜ao e n˜ao sofreriam o mesmo problema de desempenho.
6 4. 3 . Uso do Pro cesso PREF
Tabela 4.3: Hist´orico de Requisitos (Cagnin et al., 2004f) ID Requisitos Solu¸c˜ao de projeto implemen-
tada no sistema
Raz˜ao do “porque” o requisito n˜ao ´e essencial Sistema Tipo de Manut. Situa¸c˜ao Vers˜ao do fram. 01 Livros podem ter diversos autores. Implementar os autores de um li-
vro como atributo multivalorado da classe Livro.
Requisito considerado como candi- dato a ser essencial ao dom´ınio do framework. Como n˜ao havia certeza de sua generalidade, optou-se por implement´a-lo no sistema.
Biblioteca (reeng)
Perfectiva pendente –
02 Livros podem referir-se a mais de um assunto.
Implementar os assuntos de um li- vro como atributo multivalorado da classe Livro.
idem a solu¸c˜ao do requisito 1. Biblioteca (reeng)
Perfectiva pendente –
03 Aluno ´e matriculado em um curso. Implementar o curso no qual o aluno est´a matriculado na classe Aluno, como uma referˆencia `a classe Curso, por meio de um tipo enumerado.
idem a solu¸c˜ao do requisito 1. Biblioteca (reeng)
Perfectiva pendente –
04 Aluno possui estado civil (solteiro, casado, divorciado, etc), situa¸c˜ao (ativo, inativo, desistente).
Implementar o estado civil e a situ- a¸c˜ao do aluno como tipo enumerado com valores pr´e-definidos.
idem a solu¸c˜ao do requisito 1. Biblioteca (reeng)
Perfectiva pendente –
05 A cidade em que um cliente mora est´a localizada em uma determinada unidade federativa (SP, MG, RJ, ES, etc)
Implementar a unidade federativa da cidade em que um cliente reside como tipo enumerado com valores pr´e-definidos.
idem a solu¸c˜ao do requisito 1. Oficina Eletrˆonica (reeng)
Perfectiva pendente –
06 Emiss˜ao de etiquetas de mala direta. Implementar as etiquetas de mala direta a partir da cria¸c˜ao da classe Etiqueta, contendo dois tamanhos de etiquetas pr´e-estabelecidos.
idem a solu¸c˜ao do requisito 1. Oficina Eletrˆonica (reeng)
p´ı tu lo 4. PREF : Um Pro cesso de Ev o lu ¸c˜ao de F ram ew or k s de Apl ica ¸c˜ao 10 7
ID Requisitos Solu¸c˜ao de projeto implemen- tada no sistema
Raz˜ao do “porque” o requisito n˜ao ´e essencial Sistema Tipo de Manut. Situa¸c˜ao Vers˜ao do fram. 07 Um arquivo de danos ´e criado para
conter informa¸c˜ao sobre danos rela- tados por causa de buracos e incluem nome e endere¸co do cidad˜ao.
Criar uma classe danos a partir da aplica¸c˜ao sint´atica do padr˜ao 6 da GRN - Comercializar o Recurso, para controlar os danos ocorridos.
Requisito considerado essencial ao dom´ınio do framework, mas optou-se por n˜ao implement´a-lo devido a de- cis˜ao do escopo do framework.
Reparos de Buracos (desenv)
Perfectiva pendente –
08 Deseja-se autenticar os usu´arios do sistema, registrar os acessos efetua- dos e bloquear o acesso a determina- das opera¸c˜oes do usu´ario, conforme o seu papel.
– Requisito considerado essencial ao dom´ınio do framework desde o de- senvolvimento do framework GREN, mas optou-se por n˜ao implement´a-lo por falta de tempo e devido a deci- s˜ao do escopo da primeira vers˜ao do framework.
– – pendente –
09 Deseja-se resolver o problema de de- sempenho que ocorre quando grande volume de dados ´e carregado nas interfaces gr´aficas de usu´ario dos sis- temas gerados pelo framework.
Perfis foram utilizados para determi- nar o gargalo do sistema. A carga dos registros na mem´oria ´e realizada em segundo plano, com baixa priori- dade.
Requisito considerado essencial ao dom´ınio do framework mas optou-se por implement´a-lo inicialmente no sistema, a fim de propor a melhor solu¸c˜ao em um intervalo de tempo menor e com menor custo, j´a que a hierarquia de classes da aplica¸c˜ao envolve menos classes e menos recur- sos do que a hierarquia de classes do framework. Venda (re- eng) Desempe- nho pendente – . . . .
Tabela 4.4: An´alise dos requisitos n˜ao cobertos pelo framework GREN (Cagnin et al., 2004d)
ID Requisitos Situa¸c˜oes em que ele pode ocorrer novamente 4, 5 Status do pedido em uma f´abrica ou loja, status de uma
fita em uma locadora, status de um cliente, etc.
3 Especialidade de um m´edico, convˆenios atendidos por uma cl´ınica m´edica, etc.
1, 2 Telefones do cliente, do fornecedor, pessoas de contato de um determinado fornecedor, dependentes do funcion´ario, doen¸cas associadas a um paciente, etc.
6 Etiquetas de lacre, etiquetas de remetente, etiquetas de patrimˆonio, etc.
7 A maioria dos sistemas do dom´ınio de Gest˜ao de Recursos de Neg´ocios necessita registrar informa¸c˜ao sobre os eventos que ocorrem com um determinado recurso.
8 A maioria dos sistemas do dom´ınio de Gest˜ao de Recursos de Neg´ocios necessita de controle de acesso.
9 A maioria dos sistemas do dom´ınio de Gest˜ao de Recursos de Neg´ocios necessita de processamento r´apido.
A partir da an´alise realizada, observou-se que os requisitos armazenados no Hist´orico podem ocorrer mais do que duas vezes no desenvolvimento e na reengenharia de sistemas no dom´ınio de Gest˜ao de Recursos de Neg´ocios, portanto s˜ao funcionalidades inerentes a esse dom´ınio e sua ausˆencia no framework pode limitar o seu uso. Assim, s˜ao candidatos a serem implementados no framework. O requisito 7 n˜ao foi incorporado ao framework devido a decis˜ao de escopo. Os requisitos 1 a 6 e os requisitos 8 e 9 foram incorporados ao framework GREN por meio de algumas evolu¸c˜oes. No entanto, somente as evolu¸c˜oes do framework GREN que utilizaram o processo PREF (Cagnin et al., 2004d,f; Silva, 2004b) ser˜ao comentadas nesta se¸c˜ao (ou seja, evolu¸c˜oes referentes aos requisitos 1 a 6 e ao requisito 8).
Atividade 4 - Projetar, modificar e testar o framework para satisfazer o requisito Atividade 3 - Atualizar o hist´orico de requisitos
Atividade 7 - Validar o framework
As solu¸c˜oes de projeto e as implementa¸c˜oes que foram feitas diretamente nos sistemas criados a partir da instancia¸c˜ao do framework GREN para atender requisitos n˜ao cobertos por ele (como ´e o caso dos requisitos agrupados nas seis primeiras linhas do Hist´orico de Requisitos, Tabela 4.3) foram utilizadas como base para apoiar a evolu¸c˜ao do GREN. As solu¸c˜oes de projeto (descritas no Hist´orico de Requisitos) foram abstra´ıdas e generalizadas e apoiaram no projeto e na implementa¸c˜ao de cada evolu¸c˜ao do framework. A generaliza¸c˜ao foi feita a partir do conhecimento do engenheiro do dom´ınio na hierarquia de classes, na arquitetura e no dom´ınio do framework GREN.
Antes de evoluir o framework, tomou-se o cuidado de tratar do Gerenciamento de Controle de Configura¸c˜ao (atividade 8), embora feito de forma manual.
A vers˜ao original do framework GREN (vers˜ao 1.0) (Braga, 2003) foi submetida a duas evolu¸c˜oes em paralelo. Ambas evolu¸c˜oes resultaram respectivamente nas vers˜oes 1.1 e 1.2.
A primeira evolu¸c˜ao (Cagnin et al., 2004d,f) foi do tipo perfectiva e, inicialmente, trˆes requisitos n˜ao atendidos pelo framework GREN (representados pelos requisitos 1 a 5 do Hist´orico de Requisitos) foram satisfeitos. Tais requisitos s˜ao relacionados a tipos especiais de dados, ou seja, tipo enumerado com valores pr´e-definidos e com valores obtidos de outra classe, e tipo multivalorado com valores obtidos de outra classe. O Hist´orico de Requisitos foi atualizado, alterando-se a situa¸c~aodos requisitos 1 a 5 para “sendo atendido” (atividade “Atualizar o hist´orico de requisitos”).
A implementa¸c˜ao da primeira evolu¸c˜ao do GREN foi relativamente simples de ser feita e exigiu mudan¸cas tanto na estrutura fixa quanto na estrutura vari´avel do framework, pois foram adicionadas novas classes concretas e abstratas para facilitar a inclus˜ao de atributos com tipos especiais nas classes dos sistemas gerados a partir do framework. Nota¸c˜oes especiais foram criadas e sugeridas para serem incorporadas `a linguagem de padr˜oes GRN, a fim de representar os novos tipos de dados. A documenta¸c˜ao de an´alise e de projeto do framework e o seu cookbook foram atualizados (atividade “Atualizar a documenta¸c˜ao do framework”).
Outro requisito n˜ao coberto pelo framework GREN foi tamb´em atendido pela primeira evolu¸c˜ao. Esse requisito ´e o de n´umero 6 do Hist´orico de Requisitos e inclui um novo tipo de sa´ıda de relat´orio, ou seja, etiquetas. O Hist´orico de Requisitos foi atualizado, alterando-se a situa¸c~aodo requisito 6 para“sendo atendido”(atividade“Atualizar o hist´orico de requisitos”). A implementa¸c˜ao desse requisito no framework GREN implicou em mudan¸cas nas estruturas fixa e vari´avel desse framework, pois uma classe concreta foi criada na parte fixa e tornaram-se dispon´ıveis dois tipos de etiquetas na camada vari´avel. A op¸c˜ao desse novo tipo de relat´orio foi sugerida para ser inclu´ıda na linguagem de padr˜oes GRN. A documenta¸c˜ao de an´alise e de projeto do framework e o cookbook tamb´em foram atualizados (atividade “Atualizar a documenta¸c˜ao do framework”).
A segunda evolu¸c˜ao do GREN (Silva, 2004b) tamb´em foi do tipo perfectiva e o requisito relacionado ao controle de acesso (representado pelo requisito 8 do Hist´orico de Requisitos) foi incorporado ao framework GREN. O Hist´orico de Requisitos foi atualizado, alterando-se a situa¸c~ao do requisito 8 para “sendo atendido” (atividade “Atualizar o hist´orico de requisitos”). A funcionalidade desse requisito (autentica¸c˜ao, registro de acesso e de bloqueio) foi implementada com o apoio da abordagem orientada a aspectos (Kiczales et al., 1997). Dessa forma, uma s´erie de classes de AspectS 4 (Hirschfeld, 2003) foi incorporada `a hierarquia
do framework GREN. Al´em disso, foram necess´arias grandes modifica¸c˜oes na estrutura fixa do framework, uma vez que dezessete classes foram criadas e algumas modifica¸c˜oes simples foram feitas na estrutura vari´avel. Em seguida, a documenta¸c˜ao de an´alise e de projeto
4
AspectS ´e uma extens˜ao da linguagem Smalltalk, que tem por objetivo dar suporte `a Programa¸c˜ao Orientada a Aspectos.
do framework e o cookbook foram atualizados (atividade “Atualizar a documenta¸c˜ao do framework”).
Ap´os cada modifica¸c˜ao realizada no framework GREN testes de unidade foram realizados. No entanto, nenhum crit´erio de teste espec´ıfico foi utilizado. Concomitantemente aos testes de unidade, testes de regress˜ao foram feitos na atividade “Validar o framework” por meio de instancia¸c˜oes do framework. Nessas instancia¸c˜oes foram criados sistemas que possu´ıam os requisitos incorporados ao GREN, para verificar se nenhuma parte do framework havia sido danificada e se os requisitos tinham sido implementados corretamente. Os sistemas tomados como base para as instancia¸c˜oes foram aqueles registrados no Hist´orico de Requisitos e que possu´ıam os requisitos incorporados nas duas evolu¸c˜oes do framework.
A instancia¸c˜ao do framework foi feita de duas maneiras: caixa-branca e caixa-preta. A primeira permitiu, al´em de validar o framework, validar a atualiza¸c˜ao do cookbook feita na atividade “Atualizar a documenta¸c˜ao do framework”. O segundo tipo de instancia¸c˜ao permitiu validar o framework e tamb´em a ferramenta de instancia¸c˜ao GREN-Wizard, atualizada na atividade “Atualizar ferramentas associadas ao framework”.
O Hist´orico de Requisitos foi atualizado, atribuindo “atendido” ao atributo situa¸c~ao de cada requisito que foi incorporado ao framework (atividade “Atualizar o hist´orico de requisitos”).
Atividade 5) Atualizar a documenta¸c˜ao do framework
Quanto `as evolu¸c˜oes no framework GREN, as manuten¸c˜oes perfectivas resultaram em mudan¸cas na documenta¸c˜ao do framework (diagrama de classes, documenta¸c˜ao da hierarquia de classes, etc) e no processo de instancia¸c˜ao descrito no cookbook. Foram descritos os procedimentos necess´arios para adicionar os novos atributos dos tipos enumerado e multivalorado `as classes dos sistemas criados pelo framework. A possibilidade de escolher mais um tipo especial de relat´orio e a de decidir se uma instancia¸c˜ao adota ou n˜ao os requisitos de seguran¸ca foram documentadas tamb´em no cookbook. Esse ´ultimo caso funciona como se um novo padr˜ao, cuja aplica¸c˜ao ´e opcional, tivesse sido adicionado `a linguagem de padr˜oes.
Atividade 6) Atualizar ferramentas associadas ao framework
A ferramenta de instancia¸c˜ao GREN-Wizard foi evolu´ıda ap´os cada evolu¸c˜ao do framework GREN e sua evolu¸c˜ao foi baseada no cookbook atualizado, o qual indicou indiretamente quais partes do c´odigo fonte da ferramenta deveriam ser modificadas. O manual de instancia¸c˜ao da ferramenta GREN-Wizard com as novas fun¸c˜oes apresentadas na sua interface gr´afica com o usu´ario (GUI), bem como o diagrama de classes de projeto da ferramenta GREN-Wizard foram atualizados.
A preocupa¸c˜ao de tratar do Gerenciamento de Controle de Configura¸c˜ao (atividade 8) tamb´em foi considerada antes da evolu¸c˜ao da ferramenta de instancia¸c˜ao GREN-Wizard. Igualmente ao do framework GREN, tal gerenciamento tamb´em foi feito de forma manual.
Atividade 8) Tratar do Gerenciamento de Controle de Configura¸c˜ao
Como comentado anteriormente, o Gerenciamento de Controle de Configura¸c˜ao do framework GREN e da ferramenta GREN-Wizard foi feito de forma manual, sem apoio de ferramenta computacional espec´ıfica. Como as evolu¸c˜oes foram realizadas concomitantemente, existem diversas vers˜oes em paralelo, conforme apresentado na Figura 4.2. As vers˜oes da ferramenta GREN-Wizard s˜ao compat´ıveis com as suas vers˜oes correspondentes do framework GREN. O Hist´orico de Requisitos tamb´em foi atualizado nesta atividade, atribuindo o n´umero da vers˜ao do framework, em que cada requisito foi incorporado, no atributo vers~ao do framework. As linhas do Hist´orico de Requisitos correspondentes aos requisitos 1 a 6 foram atualizadas, atribuindo-se 1.1 ao atributo vers~ao do framework, enquanto que a linha correspondente ao requisito 8 foi atualizada atribuindo-se a vers˜ao 1.2.
GREN 1.0 GREN 1.2 GREN 1.1 GREN-Wizard 1.0 GREN-Wizard 1.1 GREN-Wizard 1.2 evoluído para compatível com Legenda:
Figura 4.2: Grafo do controle de vers˜oes do GREN e da ferramenta GREN-Wizard Embora exista a necessidade de manter um registro dos requisitos de cada vers˜ao do framework com os respectivos sistemas que foram gerados em cada vers˜ao, conforme ilustrado na Figura 4.3, isso ainda n˜ao foi feito. No entanto, ´e uma preocupa¸c˜ao que deve ser considerada, pois caso um sistema seja importado em uma hierarquia de classes do framework cuja vers˜ao ´e diferente daquela na qual ele foi gerado, pode haver conflito entre o c´odigo fonte do framework e o do sistema e, conseq¨uentemente, o sistema pode n˜ao fornecer o comportamento desejado.
Como o GREN ´e um framework acadˆemico, diversos pesquisadores est˜ao utilizando-o e, portanto, pode ser alterado a qualquer momento, por qualquer pesquisador, gerando
GREN 1.0 GREN 1.2 GREN 1.1 GREN-Wizard 1.0 GREN-Wizard 1.1 GREN-Wizard 1.2 Sistema 1 Sistema 2 Sistema 3 Sistema 4
Sistema 4 Sistema 5 Sistema 6
evoluído para compatível com Legenda: criado por
...
...
Figura 4.3: Grafo do controle de vers˜oes do GREN e dos sistemas gerados
diversas vers˜oes em paralelo e dificultando ainda mais o controle de suas vers˜oes. Dessa forma, o ideal ´e criar um reposit´orio em um ferramenta de controle de vers˜oes, por exemplo, CVS (Concurrent Versions System, 2004), para facilitar a integra¸c˜ao do c´odigo fonte do framework, que deve ser feita constantemente. O pesquisador, antes de submeter a nova vers˜ao do framework `a ferramenta, deve integr´a-la `a ´ultima vers˜ao do framework que est´a dispon´ıvel no reposit´orio e garantir que ela esteja funcionando adequadamente para que outros possam utiliz´a-la.
4.4
Considera¸c˜oes Finais
Neste cap´ıtulo apresentou-se um processo de evolu¸c˜ao de frameworks de aplica¸c˜ao (PREF), que ´e um dos recursos criados e associados ao arcabou¸co de reengenharia definido nesta tese. Apesar desse processo ter alguns passos que s˜ao similares a qualquer outro processo de manuten¸c˜ao de software convencional, fornece contribui¸c˜ao relacionada ao controle de variabilidade de framework. Tal controle ap´oia o engenheiro de dom´ınio decidir se um requisito n˜ao coberto pelo framework (dito variabilidade requerida por Deelstra et al. (2004)) ´e essencial ou n˜ao ao seu dom´ınio, ou seja, deve ser incorporado ao framework. Para isso, utiliza um Hist´orico de Requisitos que:
• ap´oia a decis˜ao se o requisito ´e essencial ao dom´ınio do framework;
• documenta os requisitos n˜ao cobertos pelo framework e, como mant´em a documenta¸c˜ao daqueles incorporados ao framework, ´e poss´ıvel consultar quais os hot spots do framework foram incorporados e/ou alterados em uma determinada vers˜ao;