Detecção e Análise de Cenários Implícitos como Suporte à
Manutenção de Software
Felipe Cantal de Sousa Orientador: Nabor C. Mendonça
Mestrado em Informática Aplicada – Universidade de Fortaleza (UNIFOR) Av.Washington Soares, 1321, CEP 60811-905 Fortaleza, CE
felipe_cantal@yahoo.com.br, nabor@unifor.br
Nível: Mestrado
Ano de ingresso: 2004
Data de qualificação: Abril de 2005
Data prevista de conclusão: Março de 2006
Resumo. Especificações baseadas em cenários têm sido cada vez mais utilizadas
em ambientes corporativos como um mecanismo para a descrição formal de requisitos de software. No entanto, combinações inesperadas no modo como os componentes interagem podem forçar o aparecimento de comportamentos inusitados, denominados “cenários implícitos”, que tanto podem indicar falhas na especificação do sistema, como situações indesejadas não previstas nos cenários originais. Este trabalho propõe a criação de um ambiente automatizado para auxiliar a detecção e a análise de cenários implícitos em sistemas existentes. Desse modo, pretende-se estender os benefícios do uso de cenários implícitos, inicialmente utilizados apenas na fase de especificação de requisitos, às fases de manutenção e evolução.
1. Introdução
Especificações baseadas em cenários, geralmente expressos através de notações como Message Sequence Charts (MSCs) [6] e Diagramas de Seqüência da UML [14], têm sido cada vez mais utilizadas em ambientes corporativos como um mecanismo para a elicitação e descrição formal de requisitos de software. Um cenário descreve como um ou mais componentes de um sistema, seu ambiente externo, e seus usuários interagem para oferecer um conjunto específico de funcionalidades. Dessa forma, cada cenário representa uma visão parcial do comportamento global do sistema, o qual, para ser descrito por completo, depende da combinação dessas diferentes visões. Por sua simplicidade e representação gráfica intuitiva, os cenários propiciam um maior envolvimento entre analistas de requisitos, projetistas e desenvolvedores, de maneira que cada um possa, independentemente, contribuir com sua própria visão do sistema.
Cenários são particularmente úteis para descrever o comportamento de sistemas concorrentes e distribuídos [4]. Isto porque a execução desses sistemas implica na execução simultânea, de forma concorrente ou paralela, de vários de seus componentes, cuja comunicação se dá unicamente através da troca de mensagens. Nesse contexto, modelos de comportamento baseados em cenários têm se mostrado uma forma eficaz de capturar os diversos fluxos concorrentes de mensagens entre os componentes de um sistema distribuído, oferecendo, assim, uma especificação precisa do comportamento esperado do sistema [13].
Por outro lado, modelos de comportamento baseados em cenários sofrem de uma limitação intrínseca, cujos efeitos só começaram a ser adequadamente investigados e entendidos mais recentemente. A limitação está no fato de que um modelo de comportamento de um sistema nem sempre é a soma exata do conjunto de comportamentos expressos nas especificações de seus cenários individuais. Combinações inesperadas no modo como os componentes interagem podem forçar o aparecimento de situações inusitadas, não presentes nos cenários originais. Tais situações, denominadas cenários implícitos (implied scenarios) nos trabalhos pioneiros de Uchitel et al. [10][12][11], surgem principalmente porque os componentes têm em geral uma visão local do que está acontecendo no sistema, e não uma visão do comportamento global esperado. A existência de cenários implícitos pode indicar tanto falhas ocorridas na especificação do sistema, no caso de cenários implícitos considerados válidos, mas que por algum motivo não foram originalmente especificados; ou simplesmente situações indesejadas não previstas nos cenários originais, no caso de cenários implícitos considerados inválidos do ponto de vista do comportamento esperado dos componentes. Em ambos os casos, a detecção e a análise de potenciais cenários implícitos constituem uma atividade de fundamental importância para o processo de especificação de requisitos, seja para corrigir eventuais falhas de especificação, seja para aumentar a confiança dos desenvolvedores nas especificações existentes.
O objetivo deste trabalho de pesquisa é a criação de um ambiente automatizado para auxiliar a detecção e a análise de cenários implícitos em sistemas existentes. Desse modo, pretende-se estender os benefícios das pesquisas pioneiras sobre cenários implícitos realizadas por Uchitel et al., na fase de especificação de requisitos, às fases de manutenção e evolução. Para isso, serão escolhidos diversos
cenários-chave de um sistema alvo, cujas execuções reflitam seu comportamento básico. A partir de diferentes execuções do sistema no contexto de cada um dos cenários escolhidos, serão extraídas trilhas (ou fluxos) de execução através de uma ferramenta apropriada, desenvolvida como parte do trabalho de pesquisa. Os fluxos obtidos serão relacionados a um metamodelo de fluxos de execução, e servirão de base para alimentação de uma outra ferramenta que irá detectar e apontar os cenários implícitos existentes. Por fim, os cenários implícitos encontrados serão analisados considerando o comportamento dos componentes envolvidos em relação ao comportamento esperado. A motivação é mostrar que a detecção e a análise de cenários implícitos a partir dos artefatos de implementação de um sistema, e não somente a partir de sua especificação, pode representar um importante mecanismo de auxílio às atividades de manutenção e evolução de software. Nas seções seguintes descreveremos nossa metodologia de pesquisa; as contribuições esperadas; e o estágio atual do trabalho.
2. Metodologia de Pesquisa
Nesta seção serão expostos os trabalhos relacionados ao nosso tema de pesquisa e detalhes da implementação da ferramenta para extração de cenários.
2.1 Trabalhos relacionados
Muitas ferramentas comerciais de engenharia reversa (por exemplo, Jinsight [3]) empregam a análise dinâmica do comportamento de programas em execução a fim de recuperar cenários representados como diagramas de seqüência ou MSCs. No âmbito acadêmico, Briand et al. [1] propõem uma metodologia, também baseada na análise dinâmica, para a engenharia reversa de diagramas de seqüência da UML. A proposta utiliza a programação orientada a aspecto como mecanismo de instrumentação do código da aplicação, e define metamodelos para mapear as entidades e os relacionamentos tipicamente capturados em rastros de execução em elementos correspondentes dos diagramas de seqüência. Hamou-Lhadj et al. [2] propõem um ambiente para a recuperação de modelos de comportamento a partir de trilhas de execução. Uma característica diferencial do ambiente é a remoção de componentes utilitários dos modelos recuperados através de análise fan-in. Por fim, Richner e Ducassse [7] apresentam uma ferramenta para a recuperação de informações de colaboração genéricas (que podem ser aplicadas a qualquer linguagem de programação orientada a objeto) e posterior representação dessas informações em termos de padrões pré-estabelecidos. Outros trabalhos de engenharia reversa empregam a análise estática para a recuperação de diagramas de seqüência a partir de artefatos de código. Exemplos incluem os trabalhos de Rountev et al. [8], que propõe uma maneira de mapear gráficos de controle de fluxo às recém lançadas primitivas de controle da nova geração da UML (2.0); e de Mansurov e Campara [5], que apresenta uma maneira de extrair cenários representados na forma de MSCs.
Todos os trabalhos acima focam exclusivamente na tecnologia necessária para extrair diagramas de seqüência (ou similares), que constituem a base para a recuperação de cenários, a partir da análise estática ou dinâmica de sistemas existentes. Trabalhos pioneiros na detecção e análise de cenários implícitos estão
sendo desenvolvidos há alguns anos pelo grupo de pesquisa liderado pelo Prof. Jeff Kramer, do Imperial College, Londres ([10][12][11]), com o objetivo de melhorar o processo de especificação de requisitos. A detecção de cenários implícitos é feita através de um arcabouço que fornece uma linguagem de cenários mais expressiva para compor MSCs de alto nível, visando especificar um número infinito de comportamentos do sistema, no qual cenários são modelados como Sistemas de Transição Rotulados (Labelled Transitions Systems – LTS) e expressos formalmente através da linguagem FSP (Finite Sequential Processes) [4]. Uma vez especificados os cenários, o processo de detecção dos cenários implícitos é automatizado através da ferramenta de análise de modelo LTSA [4], desenvolvida pelo próprio grupo. Conforme mencionada anteriormente, a motivação deste trabalho é estender os resultados das pesquisas desenvolvidas pelo grupo do Prof. Kramer, no âmbito da detecção de cenários implícitos como parte do processo de especificação de requisitos, às fases de manutenção e evolução. Para isso, o trabalho se beneficiará de diversas ferramentas existentes, tanto para a engenharia reversa de cenários, quanto para a detecção automática de cenários implícitos a partir dos cenários encontrados através da engenharia reversa.
2.2 Implementação
O trabalho será desenvolvido com foco em aplicações distribuídas desenvolvidas na linguagem Java. Essa decisão justifica-se por Java ser uma linguagem orientada a objeto bastante difundida, tanto no meio comercial como no meio acadêmico. Primeiramente, será definido um metamodelo de diagramas de cenários como uma adaptação do metamodelo MSC. Esse metamodelo será utilizado para definir os requisitos da ferramenta de extração de fluxos de execução, em termos do tipo de informação a ser retornada nos fluxos extraídos. O processo de detecção de cenários implícitos propriamente dito será divido em quatro etapas (Figura 1): (1) extração e representação dos fluxos de execução da aplicação alvo (passos 1 e 2); (2) utilização dos fluxos de execução coletados para a extração de cenários (passos 3 a 6); (3) detecção de cenários implícitos (passos 6 a 8); e (4) análise dos resultados obtidos. Opcionalmente, os cenários extraídos poderão ser representados em um formato compatível com o utilizado por ferramentas de modelagem comerciais XMI [15], de modo a poderem ser mais facilmente visualizados e analisados (passos 9 a 12). 2.2.1 Extração e representação dos fluxos de execução
Figura 1: Processo de detecção de cenários implícitos para aplicações Java.
3 Monitor de Eventos Aplicaçäo Java Filtro de Eventos Rastros de Execuçäo Catálogo de Descriçöes XMI Extrator de Cenários Metamodelo de Rastros de Execuçäo LTSA Cenários Implícitos Especificaçöes FSP 1 8 Catálogo de Descriçöes FSP Documentos XMI Ferramentas Case Diagramas de Sequência 8 7 11 12 Opcional 2 4 1 9 5 6 10
A extração dos fluxos de execução será realizada através da análise dinâmica da aplicação alvo por uma ferramenta denominada monitor de eventos. Sua construção será baseada na camada JDI (Java Debug Interface) da plataforma JPDA (Java
Platform Debugger Architecture) [9]. Após a geração dos fluxos de execução, os
dados gerados serão coletados e representados como rastros de execução no metamodelo previamente definido.
2.2.2 Extração dos cenários comportamentais e detecção de cenários implícitos Os elementos presentes nos rastros de execução serão mapeados pelo extrator de cenários para os elementos correspondentes nos diagramas MSCs, expressos através da linguagem FSP. Para detecção dos cenários implícitos a partir dos cenários extraídos da aplicação alvo, utilizar-se-á a ferramenta LTSA, já descrita na seção anterior. Como entrada para esta ferramenta, serão fornecidas as especificações em FSP geradas. Estas especificações serão posteriormente sintetizados no formato LTS pela ferramenta LTSA a qual detectará os cenários implícitos decorrentes dos cenários especificados no modelo comportamental da aplicação alvo.
2.2.3 Análise dos resultados obtidos
Nesta etapa, cada cenário implícito encontrado será analisado com relação ao comportamento esperado do sistema. A idéia é utilizar a informação contida nos cenários implícitos para verificar a conformidade da documentação do sistema (caso disponível) com a realidade da implementação.
3 Contribuições esperadas
Uma das principais contribuições é o uso de cenários implícitos como facilitador do processo de compreensão do comportamento da aplicação alvo, especialmente quando esta se encontra mal documentada, de forma a ajudar seus desenvolvedores a melhor planejarem as atividades de manutenção e evolução da aplicação.
Outro importante uso é ressaltado quando são utilizadas técnicas de TDD
(Test-Driven Development) para garantir uma melhor qualidade de código gerado. Dado
um conjunto de execuções geradas a partir de um conjunto de casos de teste, um cenário implícito pode ser a indicação de algo ainda não coberto por esse conjunto, ou não produzido por suas execuções. Ainda na linha de testes, poderiam ser modelados comportamentos pré-determinados do sistema que garantiriam o aparecimento de cenários implícitos já esperados. Desta forma, em momentos de integração com outros sistemas ou até alteração de código legado, a reincidência destes cenários garantiria um comportamento previsto.
4 Conclusão
Este trabalho de pesquisa visa à criação de um ambiente automatizado para dar suporte à descoberta de cenários implícitos, antes restrita à fase de especificação de requisitos, como suporte às atividades de manutenção e evolução de software. Atualmente estamos formalizando o metamodelo para representação dos rastros de execução, e implementando a ferramenta para a sua extração através da plataforma JPDA. O próximo passo será implementar a ferramenta de extração de cenários e
integrá-la à ferramenta LTSA, para realizar a detecção de cenários implícitos. Uma vez concluída a implementação e a integração dessas ferramentas, planejamos realizar uma série de experimentos com aplicações Java de portes e domínios variados, visando investigar até que ponto cenários implícitos são comuns em modelos de comportamento extraídos de sistemas existentes, e como a informação sobre sua existência pode contribuir para facilitar a manutenção de tais sistemas. 5 Referências
[1] Briand, L.C., Labiche, Y., Miao, Y., “Towards the Reverse Engineering of UML
Sequence Diagrams”, In Proc. of the 10th IEEE Work. Conf. on Reverse Engineering
(WCRE 2003), Victoria, BC, Canada, 2003.
[2] Hamou-Lhadj, A., Braun, E., Amyot, D., Lethbridge, T., “Recovering Behavioral
Design Models from Execution Traces”, In Proc. of the 9th European Conf. on
Software Maintenance and Reengineering (CSMR'05), Manchester, UK, March 2005.
[3] IBM Research, “Jinsight: visualizing the execution of java programs”, 2001. Available
at http://www.research.ibm.com/jinsight . Accessed on 20/04/2005.
[4] Magee, J. and Kramer, J. “Concurrency: State Models and Java Programs”. John Wiley
& Sons Ltd., New York, 1999.
[5] Mansurov, N., Campara, D., “Using Message Sequence Charts to Accelerate
Maintenance of Existing Systems”, In Proc. of Meeting UML: 10th International SDL Forum, Copenhagen, Denmark, June 2001.
[6] Message Sequence Chart (MSC). Z.120, ITU-T Geneva 2001.
[7] Richner, T., Ducasse, S., “Using Dynamic Information for the Iterative Recovery of
Collaborations and Roles”, In Proc. of the Int. Conf. on Software Maintenance (ICSM'02), Montreal, Quebec, Canada, 2002.
[8] Rountev, A., Volgin, O., Reddoch, M., “Control Flow Analysis for Reverse Engineering
of Sequence Diagrams”, Tech. Report OSU-CISRC-3/04-TR12, Department of Computer Science and Engineering, Ohio State University, March 2004.
[9] Sun Microsystems, “Java Platform Debugger Architecture (JPDA)”. Available at
http://java.sun.com/products/jpda. Accessed on 20/04/2005.
[10] Uchitel, S., Kramer, J., Magee, J., “Detecting Implied Scenarios in Message Sequence
Chart Specifications”, In Proc. of the Joint 8th European Software Engineering
Conference (ESEC’01) and 9th ACM SIGSOFT Symposium on the Foundations of
Software Engineering (FSE’01), pp. 74-82, Vienna, Austria, 2001.
[11] Uchitel, S., Kramer, J., Magee, J., “Incremental Elaboration of Scenario-based Specifications and Behaviour Models Using Implied Scenarios”, ACM Trans. on Software Engineering and Methodology, vol. 13, n.1, January 2004.
[12] Uchitel, S., Kramer, J., Magee, J., “Negative Scenarios for Implied Scenario
Elicitation”, In Proc. of the 10th ACM SIGSOFT Symposium on the Foundations of
Software Engineering (FSE’02), Charleston, SC, USA, 2002.
[13] Uchitel, S., Kramer, J., Magee, J., “Synthesis of Behavioral Models from Scenarios”, IEEE Trans. on Software Engineering, vol. 29, n. 2, pp. 99-115, February 2003.
[14] Unified Modeling Language (UML) Specification. Available at http://www.omg.org/ technology/documents/formal/uml.htm. Accessed on 15/09/2004.
[15] W3C, “XML Metadata Interchange (XMI)”, Available at http://www.omg.org/ docs/ad/99-10-02.pdf. Accessed on 20/04/2005.
