Captura e Geração de Diagramas de Sequência

A captura dinâmica do sistema foi implementada tirando partido do weaving da tecnologia dos aspectos. Estando na posse de parte ou da totalidade do sistema a analisar, em código fonte ou binário, é possível entrelaçar o sistema com o

ReModeler e efectuar uma captura. Por cada execução do sistema vão sendo

recolhidas as mensagens, e respectiva marcação temporal, que correspondem às invocações de métodos entre objectos. Estes dados são depois armazenados na base de dados do ReModeler e são posteriormente usados para gerar um conjunto de artefactos que permitem a compreensão, manutenção e teste do sistema. Um desses artefactos gerados é o diagrama de sequência temporizado, uma extensão do existente em UML. Esse diagrama é exportado para um ficheiro em formato XMI, para permitir a visualização numa ferramenta de UML externa. De modo a permitir a escolha da informação relevante a analisar, é dada a possibilidade ao utilizador de usar um mecanismo de filtragem, que também ele fica guardado na base de dados, para futuras utilizações. O quadro da Figura 116 representa esquematicamente o resultado da implementação desta captura e consequente geração do diagrama, usando os mesmos critérios definidos na revisão do estado da arte.

Figura 116. Quadro de classificação dos componentes de capturas e geração de diagramas de sequência face à taxionomia apresentada.

Actualmente, muitos dos sistemas desenvolvidos usam facilidades de paralelismo (multithreading). No entanto, a implementação da captura não prevê este tipo de mensagens. Futuramente considero que seja importante adicionar esta particularidade, refinando os aspectos já implementados, de modo a melhorar a captura já realizada e de modo a incluir a captura deste tipo de eventos.

ReModeler2008 - Extended CRC Cards 4 4 3 2 Granularidade Critérios Fase de desenvolvimento Geração Origem

Para além disso, devido ao consumo de tempo e recursos que pode ter uma captura, este deveria ser o componente mais independente dos restantes constituintes do ReModeler, criando como foi referido atrás uma aplicação independente que apenas capturasse e guardasse os dados na base de dados de forma persistente.

Outro ponto que requer alguns melhoramentos é o sistema de filtragem. É especialmente vantajoso incluir nas opções de filtragem informação estatística das invocações, de modo a melhor guiar o processo do utilizador.

Faz também sentido conseguir identificar, através da inclusão de informação no XMI, as partes de cada diagrama de sequência que correspondem a cada passo (oriundos da descrição dos cenários), como por exemplo apresentar cores diferentes dos elementos sempre que se muda de passo.

7.3.4 Cartões CRC

Também os cartões CRC estendidos são gerados automaticamente a partir das informações que foram recolhidas da captura do sistema e que foram posteriormente armazenadas na base de dados. Estes cartões representam, para cada classe, quais os cenários em que ela participa e quais as outras classes que a auxiliam a implementar cada cenário. No quadro da Figura 117 são apresentados os resultados da análise dos cartões CRC propostos face aos critérios presentes na revisão do estado da arte.

Este artefacto também tem alguns melhoramentos previstos para realização futura. Neste momento os cartões são gerados em formato HTML estático. Deixo para trabalho futuro a adaptação da construção actual para uma construção dinâmica usando JavaServer Pages (JSPs) [Sun Microsystems, 2008] que lêem os dados directamente da base de dados e que conseguem, por exemplo, mostrar de forma ligada as descrições de cada cenário ou outras informações relevantes.

Figura 117. Quadro de classificação do componente de geração dos cartões CRC face à taxionomia apresentada.

7.3.5 Matrizes CRUD

As matrizes propostas nesta dissertação são geradas nas fases mais tardias do ciclo de vida do software, quando já existe pelo menos parte do sistema desenvolvido. Isto permite a captura de informações provenientes da execução do sistema em análise, permitindo a geração automática das matrizes, o que garante um elevado grau de fiabilidade. A granularidade destas matrizes é variável, sendo dada a possibilidade ao utilizador de escolher a visão que deseja analisar, mais ou menos detalhada.

As matrizes CRUD também foram implementadas de modo estático, recorrendo à tecnologia de HTML. Tal como acontece para os cartões CRC, a adaptação da implementação actual para uma mais dinâmica, tirando partido da tecnologia de JSPs, é deixada para trabalho futuro. Este modo iria permitir a granularidade fosse escolhida, através de uma estrutura em árvore, à medida que se processava a actividade de análise da matriz, podendo diminuir ou aumentar.

7.3.6 Relatórios Estatísticos

A análise de cobertura tem uma representação qualitativa, mas num processo de desenvolvimento mais controlado é necessária informação quantitativa, tal como a que podemos encontrar descrita dos níveis mais altos de frameworks de processos como o CMMI ou a ISO 15504 (SPICE). Prevejo a criação de relatórios que apresentem não só as percentagens de cobertura, já presentes sob o formato de diagramas coloridos, e utilização média de recursos (CPU e memória), mas também um conjunto de estatísticas e métricas do processo de captura do cenário em diferentes níveis de abstracção.

7.3.7 Estimação de Custos

Embora alguns dos artefactos gerados permitam ter uma ideia das dependências geradas pela alteração de um determinado requisito, como as matrizes CRUD e os cartões CRC, não existe um real planeamento de esforço/custos, para o conseguir. Penso que seria interessante analisar as informações já existentes, de modo a criar um grafo de dependências (incluindo as indirectas) que permita criar um modelo de estimação. Este modelo de estimação permitiria estimar o esforço,

bem como os custos, necessários para a concretização de alterações, que apoiariam as decisões dos responsáveis pela gestão do projecto e pela gestão de alterações.

7.3.8 Diagramas coloridos

Os diagramas propostos nesta dissertação mostram a cobertura de capturas de cenários do sistema, usando para isso os diagramas de casos de utilização coloridos e mostram a cobertura da estrutura na execução do sistema, através dos diagramas de classes coloridos. No entanto, pode ser interessante ver a análise de cobertura a outros níveis de abstracção. Os intervenientes podem querer saber, para além da cobertura da captura, quais os casos de utilização que já estão documentados, ou seja, quais os casos de utilização que têm os seus cenários devidamente descritos. Para demonstrar isso, é possível criar um diagrama de casos de utilização que, também através de uma escala de cores, indique a cobertura da descrição dos cenários.

Por outro lado, os programadores e engenheiros de teste podem querer identificar que partes do sistema estão a ser usadas no contexto de um dado cenário, caso de utilização ou bateria de testes. Em parte, tal já é possível, através do diagrama de classes colorido, mas se o sistema em análise for muito grande ou complexo, eles podem necessitar de ver a cobertura de execução do sistema com uma granularidade ao nível do pacote. Para isso, é interessante criar futuramente diagramas de pacotes coloridos que mostrem a cobertura de execução, de acordo com a percentagem das classes que o constituem e que foram executadas

Anexo A

Tecnologias Usadas na Implementação do

ReModeler

Conteúdo

a. Java Database Connectivity Application Program Interface... 176 b. AspectJ... 176 c. SAX ... 177