Um Sistema para Controle de Desempenho de Componentes Executáveis de Negócio Rodrigo Friedrich Schütz 1, Eduardo Kroth 1 1 Departamento de Informática Universidade de Santa Cruz do Sul (UNISC) Avenida Independência, 2293, Bairro Universitário 96.815-900 Santa Cruz do Sul RS Brasil rfschutz@terra.com.br, kroth@unisc.br Resumo. Em um projeto de software, onde vários componentes interagem entre si através de invocação de métodos, o trabalho de depuração de performance pode tornar-se uma tarefa dispendiosa de tempo. Este trabalho apresenta um software que permite a apresentação através de um diagrama de seqüências do fluxo de execução de um processo, bem como o tempo de execução de cada um dos métodos envolvidos. Permite ainda o cálculo automático de com plexidades de métodos e classes, através de algumas métricas conhecidas na literatura científica. 1. Introdução Em sistemas complexos, o número de regras de negócio a serem implementadas tende a ser grande. Essas regras de negócio são implementadas a partir de métodos que compõem componentes de negócio. Os métodos de um componente podem implementar diversas funcionalidades como, por exemplo, consultas à base de dados, consistência de dados ou ainda realização de operações em outros componentes. A interação de componentes através de chamadas de métodos entre si, pode gerar uma grande cadeia de execução de métodos. Caso não se disponha de uma boa documentação do sistema, como um diagrama de seqüências por exemplo, a descoberta da ordem de execução dos métodos de um processo torna-se uma tarefa artesanal, onde o programador, através do código fonte tem que identificar que métodos são chamados. Quando uma transação passa a apresentar um tempo de execução que excede os requisitos de performance do sistema, a identificação de qual método está comprometendo o processo também é difícil e demorada, gerando uma tarefa de depuração que pode tomar bastante tempo. Esse trabalho busca soluções para estes problemas a fim de atuarem em conjunto com o ADS-UNISC (ambiente de desenvolvimento de software). A ferramenta construída permite ao programador escolher os métodos que deseja monitorar a execução, permitindo a identificação dos gargalos de desempenho do sistema. Além disso, a ferramenta também permite a classificação da complexidade de métodos e classes através de métricas que serão apresentadas no decorrer deste trabalho. Como forma de apresentação dos resultados das análises feitas para os métodos, o software implementa a construção de um diagrama de seqüências UML, que pode ser utilizado também para a simples verificação da ordem de execução de métodos. O diagrama de seqüências foi escolhido pois apresenta a
seqüência cronológica das chamadas de métodos, melhor visualizando o processo de depuração de programas. O artigo está organizado da seguinte forma. A seção 2 apresenta conceitos de reflexão computacional e algumas métricas de software. A seção 3 relaciona alguns trabalhos que tratam do mesmo contexto deste artigo. A seção 4 descreve as funcionalidades do software proposto. A seção 5 apresenta algumas ferramentas que tratam do problema contextualizado neste artigo. O artigo encerra com as conclusões deste trabalho. 2. Reflexão Computacional Reflexão computacional pode ser definida como a atividade realizada por um sistema quando faz computações sobre suas próprias computações [PIN98]. Pode ser usada para interceptar e modificar o efeito de várias operações básicas como a criação de objetos ou a invocação de métodos [FER98]. Através da reflexão computacional, um sistema pode observar sua estrutura e comportamento diante de suas próprias computações [FAB02]. Em sistemas orientados a objetos, o objetivo do uso de reflexão computacional é conseguir buscar informações referentes às classes e objetos da aplicação em execução, possibilitando assim monitorar o comportamento de um objeto ao receber uma chamada a um de seus métodos, por exemplo. Desta forma, a reflexão computacional se torna uma técnica que permite ao programador obter informações a respeito da execução do próprio programa, permitindo assim, um certo monitoramento de suas atividades [SIL01]. De acordo com Fabre (2002), uma arquitetura reflexiva possui duas partes distintas em um sistema computacional. Essas duas partes são, na verdade, dois níveis de aplicação com funcionalidades distintas, nível base e o metanível. O nível base provê a funcionalidade da aplicação. Os componentes que lidam com a funcionalidade (componentes de negócio) ficam neste nível. O domínio deste nível é o processamento realizado para que o sistema consiga atender os requisitos que levaram a sua criação. No metanível ficam as estruturas de dados e as ações executadas sobre o nível base. Permite a observação do nível base. O domínio deste nível é o sistema em si, ou seja, o processamento realizado para se obter informações a respeito da execução do sistema [DOU96]. Os componentes residentes neste nível são chamados metaobjetos [FER98]. Reflexão computacional pode ser estrutural (ocorrendo a nível de classes) ou comportamental (ocorrendo a nível de objetos) [PIN98]. Para este trabalho foi utilizada a reflexão comportamental, que permite a monitoração de chamadas a métodos de objetos do nível base. Para linguagens compiladas não reflexivas suportarem o uso da reflexão computacional, é necessário o uso de algum tipo de artifício. O mais indicado nesses casos é utilizar algum tipo de pré-processamento de código que adicione a este mecanismos de intercepção e controle, de forma que os metaobjetos sejam informados das operações que estão ocorrendo no nível base [OLI98].
3. Métricas de Complexidade de Algoritmo Em sistemas orientados a objeto, a estrutura e conseqüentemente a complexidade do código deve refletir na análise e no desenvolvimento de artefatos. A princípio, neste tipo de sistema, deveria ser possível obter medições mais precisas sobre a complexidade de um código fonte. Muitas métricas já foram propostas, porém ainda não existe um consenso sobre quais métricas oferecem melhores resultados. Uma abordagem comum para melhorar a performa nce de um sistema é medir propriedades de tempo de execução deste para encontrar gargalos que possam influir no custo de tempo. Para reduzir estes custos no desenvolvimento de software tem sido bastante utilizado a medição de complexidade dos artefatos que compõe o software [ABO97]. A medida de complexidade de software é uma medida objetiva do quão difícil é para um programador realizar tarefas comuns de programação em um artefato de software. Exemplos destas tarefas são manutenções, testes, entendimento do código etc. [LAK94]. O paradigma de orientação a objetos difere bastante do paradigma procedural, o que sugere que métricas orientadas a objetos também devam ser diferentes das métricas tradicionais. Apesar disso, não há um consenso de que métricas tradicionais não possam ser utilizadas como referência em sistemas orientados a objetos. A seguir serão apresentadas as métricas utilizadas neste trabalho. Métrica de Halstead: Métrica de paradigma procedural, também conhecida como a ciência de software de Halstead, tentam principalmente estimar o esforço na programação [KAR98]. É calculada baseada em quatro propriedades: (1) número de operadores distintos (n1); (2) número de operandos distintos (n2); (3) uso total de todos os operadores (N1); (4) uso total de todos os operandos (N2). Os operandos são constantes, variáveis ou expressões e os operadores são indicadores de operações matemáticas como +, -, / etc. A partir dessas propriedades é possível calcular o vocabulário (n1 + n2) e o comprimento (N1 + N2), e a partir do resultado destes, é possível calcular o volume de programa através da fórmula: V = comprimento * log 2 Vocabulário. Métrica de Henry & Kafura: Métrica de paradigma procedural, também conhecida como métrica dos fluxos de informação. Pressupõe que os fluxos de informação na estrutura de um programa são medidas de complexidade. Para isso baseia-se na importância dos parâmetros de entrada e de saída de um algoritmo [ABR92][KAR98]. Para calcular essa métrica é necessária a utilização de uma métrica auxiliar como, por exemplo, a LOC, que mensure o tamanho do algoritmo. Além disso, precisa-se do número de parâmetros de entrada e de saída do módulo ou algoritmo [ABR92]. Tem-se então a seguinte fórmula: Complexidade = tamanho * (par_de_entrada * par_de_saída) 2 Coupling Between Object Classes (CBO): Métrica de paradigma orientado a objetos. Essa métrica foi proposta pelos pesquisadores Chidamber e Kemerer, entre outras. Ela é dada pelo número de outras classes a que uma determinada classe está acop lada. Acoplamento aqui é definido como qualquer chamada de método de outra classe através de um objeto em um método de uma determinada classe [CAG99][ABO97].
Number of Children (NOC): Métrica também proposta por Chidamber & Kemerer orientada a objetos. É dada pelo número de classes subordinadas a uma classe específica. Isso quer dizer o número de classes que estão herdando a classe a qual se deseja medir a complexidade [CAG99][ABO97]. Number of Properties (SIZE2): O estudo dos pesquisadores Li & Henry acrescentaram mais cinco métricas às de Chidamber & Kemerer. Entre estas, está a métrica denominada SIZE2. O valor dessa métrica é dado pelo número de atributos da classe somado ao número de métodos [ABO97]. 4. Software Proposto Para o desenvolvimento do software aqui proposto, foi fundamental o uso de um metamodelo de dados que identifica os componentes, métodos e dependências de métodos de um sistema. Para isso, o metamodelodo ADS-UNISC foi estendido e adaptado. O software foi desenvolvido em C#.Net. O software aqui apresentado permite o monitoramento do tempo de execução dos métodos de negócio. Através de uma interface, o usuário define quais métodos deseja monitorar. Os métodos escolhidos e todas as suas dependências (ou seja, os métodos chamados por este método) bem como as dependências das dependências e assim sucessivamente, serão preparados para interagirem com um metaobjeto encarregado de cronometrar o tempo de execução de cada um dos métodos envolvidos no processo. Esse metaobjeto é considerado reflexivo, pois o sistema alvo realiza computações sobre suas próprias computações. Foi construído um único metaobjeto, o qual possui uma instância associada a cada uma das instâncias dos objetos do nível base que estejam sendo monitorados. Como explicado anteriormente, isso caracteriza uma reflexão do tipo comportamental. O metanível nesse caso, será composto por um único metaobjeto. A comunicação entre objetos de nível base e metaobjetos é feita de forma explícita, ou seja, o metaobjeto fornecerá interfaces de comunicação invocadas diretamente pelos objetos de nível base. O metaobjeto, deverá interceptar as chamadas feitas para o método o qual se deseja medir o desempenho, e a partir dessa interceptação, disparar um cronômetro que permanecerá ativo até o fim da execução deste. Assim será possível obter dados como o tempo de execução e quem foi o método pai ou seja, que fez a chamada ao método cronometrado. A função seguinte dele será o armazenamento dos dados referentes a esta execução para aquele método específico no banco de dados, o que será feito após a parada do cronômetro, de forma a não influenciar no tempo de execução do método. Os tempos dos métodos envolvidos, são armazenados temporariamente em memória e quando do fim do método pai de todas as dependências, estes são armazenados no banco de dados. Dessa forma, é possível fazer análises de tempos de versões diferentes do mesmo método, possibilitando assim, a identificação de versões que pioraram o desempenho do mesmo.
Figura 2.Código para Início do Cronômetro Figura 3. Código para parada do Cronômetro Os métodos a serem monitorados precisam passar por um pré-processamento de código fonte para invocarem os métodos de inicio e parada do cronômetro do metaobjeto. No início de cada um destes métodos é então colocado o código apresentado na figura 2 e no fim do método o código da figura 3. Assim, o metaobjeto é instanciado e tem o cronômetro disparado através do método start parado através do método stop. Todo o código original do método fica dentro de um bloco try-catch de forma a mesmo que ocorrer um erro o cronômetro seja parado. Uma vez os códigos fonte terem sido processados e as chamadas ao metaobjeto estabelecidas, basta compilar tais códigos e executar a aplicação normalmente. O disparo da operação que está sendo monitorada pode ser feito quantas vezes forem necessárias, sendo que o número de acessos a cada um dos métodos também é controlado. Após estes métodos terem sido processados, seu código fonte ficará armazenado no metamodelo, e a qualquer momento o usuário poderá realizar uma análise de complexidade automática sobre ele, sendo utilizadas as métricas explicadas na seção três. Para cada uma dessas métricas o usuário deverá definir quais valores são considerados complexos, simples ou qualquer outra classificação que este desejar utilizar. Essas informações são facilmente parametrizáveis na ferramenta. A principal diferença dessa ferramenta em relação as demais existentes no mercado, é a apresentação dos dados. Para isso, foi utilizado a construção de um diagrama de seqüências UML, através do auxílio de um metamodelo indicando as dependências de cada método. Esse diagrama foi adaptado em uma interface de forma a demonstrar junto aos métodos apresentados no diagrama, seu tempo de execução da última análise feita sobre seu desempenho, podendo ser consultado também os tempos das análises anteriores. Esta interface pode ser vista na figura 4. Utilizando-se do menu de componentes e métodos a esquerda, pode-se montar o diagrama de seqüências referentes dependências do método selecionado. Se houver alguma analise já existente para este método, os tempos de execução da última serão apresentados. Será possível também navegar entre as análises existentes. As datas de início e fim, bem como observações e propósitos destas são exibidas na parte inferior da tela. No canto
direito inferior é demonstrado os detalhes do método selecionado, como a sua complexidade e seus tempos máximo, médio, mínimo e total de acessos, assim como o número de acessos. 5. Trabalhos relacionados Figura 4. Interface de Apresentação dos Resultados A seguir são apresentadas algumas ferramentas com funcionalidades semelhantes ao software aqui proposto, sendo possível assim, relacionar algumas vantagens proporcionadas por este trabalho. AQTime : esta ferramenta desenvolvida pela AutomatedQA Corp., é um performance profiler para ferramentas de desenvolvimento da Borland, Microsoft, Intel, Compaq e compiladores GNU. Esta ferramenta fornece profilers de performance, alocação de memória, monitoramento de funções, acompanhamento da pilha de execução, análise estática de código, e análise da plataforma. O código fonte alvo de uma análise a partir deste software precisa ser aberto através da ferramenta e executado. Uma característica importante é que apresenta gráficos de dependências entre métodos, sem utilizar entretanto uma notação padrão como a UML, por exemplo.
Ants Profiler: a ferramenta desenvolvida pela Red-Gate Software., é um profiler para aplicações da plataforma.net. Não é necessária nenhuma compilação adicional na aplicação a ser analisada. Assim como o AQtime, a aplicação alvo precisa ser aberta através da ferramenta. Os resultados são demonstrados através de uma tabela com informações como tempo total gasto por um método, número de execuções, etc. Um ponto forte desta ferramenta é a capacidade de informar o tempo gasto por cada uma das linhas do código, permitindo uma visualização efetiva de gargalos de performance. O ponto fraco é a falta de diagramas que demons trem a interação entre métodos e classes. GPProfile: esta é uma ferramenta open source para aplicações da plataforma Borland Delphi. Este software trabalha com a inserção de algumas linhas de código no código fonte original da aplicação, sendo assim não é necessário abrir a aplicação através da ferramenta para gerar uma análise. Uma funcionalidade importante nessa ferramenta é a possibilidade de verificar quais são os métodos que chamam uma procedure e os métodos chamados por esta. Porém, assim como no ANTS Profiler este passo não é gráfico e seus resultados são apresentados de forma semelhante ao ANTS Profiler utilizando uma tabela de informações. Considerações sobre as ferramentas apresentadas: nenhuma das ferramentas possui uma forma gráfica baseada em UML para apresentar o fluxo de execução da aplicação. A proposta deste trabalho é tornar isto possível através de um diagrama de seqüências do padrão UML. Com exceção do GpProfile, as demais aplicações precisam ter seu código aberto e a execução do código através das ferramentas, o que impede de verificar a performance de um sistema já em produção, numa situação real de uso. O software aqui proposto apresenta a separação da análise do sistema da interface de visualização de seus resultados, permitindo assim que uma análise seja feita a qualquer momento. 6. Conclus ões Este trabalho apresentou um estudo sobre computação reflexiva, complexidade de algoritmo e diagramas de seqüência. Foi construída uma ferramenta de análise de performance de código que utiliza conceitos de reflexão computacional, através do uso de um metaobjeto. É possível então realizar a análise da execução dos objetos de negócio. Também permite o armazenamento de um histórico temporal dos tempos de execução de cada método ou objeto analisado permitindo assim a comparação de performance de versões diferentes de métodos ou até mesmo componentes de negócio. Um dos diferenciais desta ferramenta é a apresentação de resultados através da construção de diagramas de seqüência do padrão UML, baseando-se para isso nas dependências entre os métodos de um sistema, informações presentes em um metamodelo. Isso permitirá o acompanhamento preciso do fluxo de execução de um processo qualquer. Os tempos de execução dos métodos podem então ser visualizados de forma organizada junto a este diagrama. Isto, aliado com a análise automática de complexidade de código, permite a fácil localização de gargalos no sistema.
Referências [ABO97] ABOUNADER, Joe R. LAMB, David A. A data Model for object-oriented.1997. External Technical Report Department of Computing and Information Science, Queen s University, Kingston, Canada. [ABR92] ABREU, Fernando B. As métricas na gestão de projectos de desenvolvimento de sistemas de informação. In: 6 as jornadas para a qualidade no software, APQ, 1992, Lisboa. Atas. Disponível em: < http://ctp.di.fct.unl.pt/quasar/projects/metrics >. [BOO00] BOOCH, G.; RAUMBAUGH, J.; JACOBSON, I.. UML Guia do Usuário. Rio de Janeiro: Editora Campus, 2000. [CAG99] CAGNIN, Maria I.; PENTEADO, Rosangela A. D. Avaliação das vantagens quanto à facilidade de manutenção e expansão de sistemas legados sujeitos à engenharia reversa e segmentação. 2000. 77 p. Dissertação de mestrado. São Carlos: Universidade Federal de São Carlos. [DOU96] DOURISH, Paul. Open implementation and flexibility in CSCW toolkits, 1996, 132p. Dissertação de doutorado. Londres: University College London. [FAB02] FABRE, J.; TAIANI, F.; KILLIJIAN, M. Principles of Multi-Layer Reflection for Fault- Tolerant Architectures. In: PACIFIC RIM INTERNATIONAL SYMPOSIUM ON DEPENDABLE COMPUTING (PRDC), 2002, Tsukuba (Japão). [FER98] FERREIRA, Luciane L.; RUBIRA, Cecília M. F. Padrão State Reflexivo: Refinamento do Projeto State para uma arquitetura reflexiva. In: XII SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 1998, Maringá. Anais do XII SBES. [FUR98] FURLAN, José D. Modelagem de objetos através da UML. São Paulo: Makron Books, 1998. [KAR98] KARAKAP, Ümit; SENCER, Sultanoolu. Complexity Metrics and Models. 1998. [LAK94] LAKE, Al. Use of Factor Analysis to develop OOP software complexity metrics. In: PROC. 6TH ANNUAL OREGON WORKSHOP ON SOFTWARE METRICS, 1994, Silver Falls, Oregon. [OLI98] OLIVA, Alexandre. The reflective architeture of Guaraná. 1998. Disponível em: < http://citeseer.ist.psu.edu/349928.html >. Acesso em 25 abril 2004. [PIN98] PINTO, I. M.; PRICE, A. M. A. Um Sistema de Apoio ao teste de Programas Orientados a Objetos com uma abordagem reflexiva. In: XII SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 1998, Maringá. Anais do XII SBES. [SIL01] SILVEIRA, Fábio F. Ferramenta de Apoio ao Teste de aplicações Java baseada em reflexão computacional. Porto Alegre: UFRGS, 2001, 96p. (Dissertação, Mestrado em Ciência da Computação).