Avaliando modelos arquiteturais através de um checklist baseado em atributos de qualidade Aluno: Rafael Ferreira Barcelos barcelos@cos.ufrj.br Orientador: Guilherme Horta Travassos ght@cos.ufrj.br Nível: Mestrado Programa de Engenharia de Sistemas e Computação PESC, COPPE/UFRJ Ano de ingresso: 2004 Mês/Ano previsto para conclusão: Março de 2006 Resumo: Modelos de arquitetura de software possuem um papel importante como ponte entre os requisitos e a implementação. Estes modelos representam o primeiro conjunto de decisões de projeto relacionado à forma como os requisitos do sistema serão atendidos pelo produto final. A avaliação de modelos arquiteturais é extremamente importante visto que, de acordo com vários estudos na área, o custo de correção de defeitos é menor se a correção tiver sido realizada durante os primeiros estágios de projeto. Visando contribuir para tal atividade, esse trabalho propõe o desenvolvimento de uma abordagem para inspecionar modelos de arquiteturas de software, antes de sua implementação. Essa abordagem, baseada em checklist, possui como objetivo identificar, nos modelos arquiteturais, discrepâncias no atendimento aos requisitos especificados para o software. Palavras-chave: Qualidade de software; Verificação, validação e teste de software; Arquitetura, projeto e arcabouços (frameworks).
Avaliando modelos arquiteturais através de um checklist baseado em atributos de qualidade 1. Introdução Com o aumento da complexidade e do tamanho das aplicações de software, é observado o surgimento de novos desafios relacionados ao desenvolvimento, avaliação e manutenção desses produtos. Visando tratá-los, os engenheiros de software estão dando cada vez mais importância para os modelos de projeto que representam a arquitetura do software. De acordo com [Bass et al. 2003], arquitetura de software de um programa ou sistema computacional é a estrutura que compreende os elementos de software, as suas propriedades externamente visíveis e o relacionamento entre eles. Ela é descrita através de um conjunto de modelos construídos durante a execução de um processo de desenvolvimento de software e que representam a estrutura de um software sob diferentes perspectivas. Modelos arquiteturais possuem um importante papel como ponte entre os requisitos do sistema e a sua implementação, além de serem considerados o primeiro conjunto de decisões de projeto relacionadas ao atendimento dos requisitos no sistema [Babar et al. 2004]. Estudos demonstram que o custo de correção de defeitos é menor se a atividade de correção se realizar durante os primeiros estágios de projeto [Boehm 1981]. Portanto, devido à importância da arquitetura do software, visto sua utilidade em diferentes momentos no processo de desenvolvimento de software, a revisão dos modelos que a compõem se torna uma atividade importante para o sucesso do projeto e também desejada pelos stakeholders 1 devido a sua contribuição para a melhoria da qualidade do software. Visando contribuir para tal atividade, esse trabalho propõe o desenvolvimento de uma abordagem para inspecionar modelos de arquiteturas de software antes de sua implementação. Essa abordagem possui como objetivo identificar, nos modelos arquiteturais, discrepâncias relacionadas ao atendimento aos requisitos especificados para o software. 2. Trabalhos relacionados Existem vários trabalhos na literatura que descrevem métodos de avaliação arquitetural. Com o objetivo de identificar os principais métodos, uma revisão sistemática foi planejada e executada [Barcelos and Travassos 2004]. Como resultado dessa revisão, 18 métodos que atendem a esse objetivo foram identificados. Entre esses métodos, dois se destacaram (SAAM [Kazman et al. 1994] e ATAM [Kazman et al. 2000]) por servirem como base para a criação de grande parte das demais. Esses dois métodos buscam avaliar a arquitetura principalmente em relação a determinados requisitos de qualidade e utilizam uma mesma técnica de avaliação: execução de cenários que representam o comportamento esperado do software em relação a uma determinada característica de qualidade 2. 1 Stakeholder: grupo ou indivíduo envolvido, de forma direta ou indireta, em um projeto de software ou que possue algum interesse no resultado obtido por esse projeto. 2 No contexto desse trabalho, características de qualidade consistem em propriedades da arquitetura que foram definidas para atender aos requisitos de qualidade especificados. Sendo assim, em uma avaliação arquitetural, as características são avaliadas em relação aos requisitos.
Esses métodos utilizam os requisitos de qualidade como base apara a avaliação, pois durante o projeto de uma arquitetura, eles são os que mais influenciam nas decisões relacionadas à definição e à organização dos elementos arquiteturais. Em [Bass et al. 2003], por exemplo, é discutido que se não fosse necessário atender a esse tipo de requisito, a arquitetura de um software seria monolítica. Sendo assim, avaliar o atendimento aos requisitos funcionais consiste somente em determinar o seu correto mapeamento em um ou mais elementos arquiteturais. Contudo, a análise dos métodos identificados e resultados obtidos por surveys ([Babar et al. 2004, Dobrica and Niemela 2002]) identificaram quatro problemas principais: grande subjetividade dos métodos, elevado custo de aplicação, dificuldades para avaliar simultaneamente o atendimento a vários requisitos de qualidade e contexto limitado para a aplicação de alguns dos métodos. A subjetividade dos métodos decorre do uso de cenários como técnica de avaliação. Esse problema é causado pela impossibilidade de identificar e gerar todos os possíveis cenários, obrigando os stakeholders a utilizarem subjetividade e criatividade como abordagens para definir o conjunto de cenários de avaliação [Dobrica and Niemela 2002]. Além disso, durante a especificação dos cenários, o stakeholder inconscientemente pode definir cenários que não avaliam a arquitetura de forma completa, devido a sua familiarização com a arquitetura, provocando distorção nos resultados da avaliação. O elevado custo de aplicação está relacionado ao fato dos métodos terem sido desenvolvidos para projetos de grande porte, que geralmente possuem alta disponibilidade de recursos. Com isso, somente um pequeno número de empresas conseguem aplicar de forma correta as avaliações [Lattanze 2005]. Outra deficiência observada é a realização da avaliação sob a perspectiva de um número restrito de requisitos de qualidade. [Dobrica and Niemela 2002] sugere que uma avaliação arquitetural deve ser feita sob a perspectiva de múltiplos requisitos, permitindo uma melhor compreensão dos pontos fracos e fortes dos complexos sistemas atuais. O quarto problema identificado está relacionado à imaturidade da área de Arquitetura de Software. Devido a essa imaturidade, existe falta de consenso na comunidade em relação tanto às definições básicas quanto à forma de representar uma arquitetura [Clements et al. 2004, Buschmann et al. 1996]. Os métodos de avaliação arquitetural, por exemplo, são baseados em suas próprias e específicas abordagens de documentação, o que dificulta a sua utilização em diferentes projetos ou contextos. Portanto, esses problemas motivaram a busca por um método que permita a avaliação de modelos de arquiteturas de software. A abordagem proposta busca avaliar as características de qualidades da arquitetura em relação aos requisitos que foram utilizados no projeto da arquitetura e foi desenvolvida com o intuito de minimizar os problemas previamente discutidos. 3. Checklist baseado em atributos de qualidade A execução de cenários é uma das técnicas mais usadas na avaliação arquitetural, uma vez que permite a fácil representação das características que se deseja avaliar [Abowd et al. 1997]. Contudo, os métodos que utilizam essa técnica como base apresentam problemas, conforme descritos anteriormente, que dificultam a sua aplicação em um contexto industrial. Uma outra abordagem que comprovadamente beneficia a melhoria da qualidade de artefatos de software é a utilização de técnicas de inspeção [Shull et al. 2000, Conradi et al. 2003]. Sendo assim, a hipótese de pesquisa desse trabalho é que a definição de uma abordagem de inspeção permita a avaliação de modelos arquiteturais, durante o processo de desenvolvimento,
através da identificação de discrepâncias que estejam relacionadas à adequação da arquitetura aos requisitos de qualidade especificados. A escolha de checklist como técnica de inspeção é justificada devido às suas características quando comparada a outras técnicas de inspeção existentes: - Ad-hoc: Uma técnica ad-hoc não oferece apoio ou procedimento de execução formal e sistemática da inspeção. Além do mais, os resultados obtidos dependem principalmente da capacidade, competência e experiência do inspetor [Chen et al. 2002]. - Técnica de leitura: Uma técnica de leitura é um procedimento que visa guiar individualmente os inspetores no entendimento de um artefato de software e, por conseqüência, na identificação de discrepâncias [Shull et al. 2000]. Abordagens de avaliação baseadas nessa técnica [Shull et al. 2000, Conradi et al. 2003] são mais eficientes na detecção de defeitos quando comparadas a outras técnicas de inspeção, como checklists, por exemplo. Porém, para que seja utilizada, o artefato deve ser representado em uma forma específica e padronizada, que ainda não pode ser atingida na área de Arquitetura de Software. Portanto, o checklist aparece como uma técnica adequada para ser aplicada durante a inspeção de um modelo de arquitetura de software. Várias abordagens baseadas em checklist já foram definidas visando a identificação de defeitos em modelos arquiteturas [Aeronautics and Administration 1993, Hollocker 1990]. Contudo, os itens de questionamento são específicos ao domínio do software avaliado, dificultando a sua aplicação em um contexto diferente do qual foi projetado. Para que a avaliação realizada através desse checklist minimize os mesmos problemas observados nos métodos identificados, as seguintes características foram definidas: - Os itens de questionamento devem ser criados a partir da análise das abordagens de projeto arquitetural, levando em consideração principalmente a forma como os requisitos de qualidade são atendidos. Com isso, pretende-se reduzir a subjetividade em relação ao que é avaliado; - Os itens de questionamento devem ser agrupados de acordo com os atributos de qualidade que estão relacionados. Esses atributos consistem em diferentes categorias utilizadas para classificar características de qualidade similares [Bass et al. 2003]. Com isso, os grupos de itens permitem avaliar os modelos arquiteturais em relação a vários tipos de características de qualidade; - A sua aplicação não requer elaboradas atividades, como as necessárias para a especificação de cenários por exemplo, permitindo que a avaliação seja realizada com baixo custos. - Os itens de questionamento devem avaliar a abordagem empregada pelo arquiteto para atender aos requisitos e não a forma como eles foram documentados nos modelos. Com isso, é possível aplicar o método em modelos arquiteturais que pertencem a diferentes contextos e que utilizam diferentes abordagens de documentação; 4. Metodologia utilizada e estado atual do trabalho O desenvolvimento da abordagem proposta seguiu quatro passos que visam a sua construção e avaliação: Passo 1: Identificação das abordagens de avaliação arquitetural existentes O primeiro passo realizado foi o planejamento e execução de um estudo que identifique e caracterize os métodos existentes de avaliação arquitetural
[Barcelos and Travassos 2004]. Para executar esse estudo, uma revisão sistemática [Biolchini et al. 2005] foi realizada. Passo 2: Análise dos conceitos relacionados ao projeto e avaliação arquitetural Durante uma análise inicial dos métodos de avaliação, foi identificado a necessidade em entender como os modelos arquiteturais são criados e o papel dos requisitos nesse processo, para que então a avaliação fosse realizada. Para isso, os seguintes questionamentos devem ser respondidos: (1) quais informações, descritas nos requisitos, são necessárias para projetar arquiteturas, (2) como se projeta arquiteturas, (3) como se documenta esses modelos e (4) como eles são avaliados. Ao responder essas perguntas, diversos tipos de conhecimento poderão ser reunidos, relacionados tanto à forma de se projetar arquiteturas de software quanto à forma de se especificar requisitos sob a perspectiva do arquiteto de software. Passo 3: Definição e construção da abordagem proposta A caracterização dos métodos de avaliação identificados permitiu a observação de características positivas e algumas limitações. A compreensão desses métodos e a análise de suas características serviram como base para definir inspeção como método de avaliação. Para a definição de checklist como técnica de inspeção, as características da área de Arquitetura de Software foram um fator determinante. Atualmente, uma primeira versão do checklist está sendo gerada. Para sua criação, estão sendo usadas como base informações obtidas através da análise sobre como a arquitetura deve ser projetada para atender ao requisitos, principalmente os de qualidade. Passo 4: Estudo de Viabilidade Após a criação do checklist, um estudo de viabilidade [Shull et al. 2001] será realizado. O objetivo desse estudo é obter um retorno sobre a relevância dos itens de questionamento na identificação de defeitos, e evoluí-los se necessário. Na Tabela 1, é apresentado o cronograma das atividades, para o ano de 2005, que ainda faltam ser executadas para finalizar os passos 2, 3 e 4. Atividades MAI JUN JUL AGO SET OUT NOV DEZ Passo 2::Entender influência dos requisitos na arquitetura Passo 3::Construção do checklist Passo 4::Estudo de Viabilidade Passo 4::Evolução do checklist Tabela 1. Cronograma das atividades dos passos 2, 3 e 4 para 2005 5. Conclusões e Principais Contribuições Mesmo existindo alguns métodos de avaliação arquitetural que possuem um certo nível de maturidade [Kazman et al. 1994], ainda existem vários problemas que dificultam a sua aplicação em empresas pequenas ou que apresentam baixa maturidade no desenvolvimento de software. Com o objetivo de desenvolver uma abordagem de avaliação que atenda às necessidades desses tipos de empresas, este trabalho apresentará como principal contribuição a definição de um checklist para inspecionar modelos arquiteturais. Uma outra contribuição desse trabalho, obtida através do conhecimento adquirido na análise da influência dos requisitos no projeto arquitetural, está na definição de recomendações para a atividade de especificação de requisitos. Essas recomendações buscam indicar informações úteis ao projeto da arquitetura, além de possibilitar a avaliação dos requisitos em relação às expectativas do arquiteto de software.
Agradecimentos Os autores gostariam de agradecer à FAPEAM e ao CNPq pelo apoio financeiro necessário para realizar esse trabalho. Referências Abowd, G., Bass, L., Clements, P., Kazman, R., Northrop, L., and Zaremski, A. (1997). Recommended Best Industrial Practice for Software Architecture Evaluation. Technical Report CMU/SEI-96-TR-025, SEI, Carnegie Mellon University. Aeronautics, N. and Administration, S. (1993). Software Formal Inspection Guidebook. Technical Report NASA-STD-2202-9, NASA. Babar, M., Zhu, L., and Jeffery, R. (2004). A framework for classifying and comparing software architecture evaluation methods. In Proceedings of the Australian Software Engineering Conference,, pages 309 318. Barcelos, R. F. and Travassos, G. H. (2004). Arquitetura de Software: Identificando as metodologias que avaliam a sua qualidade. Monografia apresentada na disciplina de Teste Orientado a Objetos - COPPE/UFRJ. Bass, L., Clements, P., and Kazman, R. (2003). Edition. Addison Wesley. Software Architecture in Practice, Second Biolchini, J., Mian, P. G., Natali, A. C. C., and Travassos, G. H. (2005). Systematic review in software engineering. Technical Report ES-679/05, COPPE / UFRJ. Boehm, B. W. (1981). Software Engineering Economics. Number ISBN 0-13-822122-7. Prentice-Hall. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M. (1996). Pattern-Oriented Software Architecture: A System of Patterns. Jon Wiley and Sons. Chen, T. Y., Poon, P. L., and Tang, S. F. (2002). Towards a Problem-Driven Approach to Perspective-Based Reading. In Proceedings of the seventh IEEE Inernational Symposium on High Assurance Systems Engineering (HASE 2002), pages 221 229. Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., and Stafford, J. (2004). Documenting Software Architectures. SEI Series in Software Engineering. Addison- Wesley. Conradi, R., Mohagheghi, P., and Arif, T. (2003). Object-Oriented Reading Techniques for Inspection of UML Models - An Industrial Experiment. In Proceedings of the European Conference on Object-Oriented Programming, pages 483 500. Dobrica, L. and Niemela, E. (2002). A survey on software architecture analysis methods. In IEEE Transactions on Software Engineering, volume 28, pages 638 653. Hollocker, C. P. (1990). Software Reviews and Audits Handbook. John Wiley & Sons, Inc, New York. Kazman, R., Bass, L. J., Webb, M., and Abowd, G. D. (1994). SAAM: A Method for Analyzing the Properties of Software Architectures. In Proceedings of the 16th International Conference on Software Engineering, pages 81 90. Kazman, R., Klein, M., and Clements, P. (2000). ATAM: Method for Architecture Evaluation. Technical Report CMU/SEI-2000-TR-004, CMU/SEI. Lattanze, A. J. (2005). The Architecture Centric Development Method. Technical report, Carnegie Mellon University. Shull, F., Carver, J., and Travassos, G. H. (2001). An Empirical Methodology for Introducing Software Processes. In Proceedings of European Software Engineering Conference, pages 288 296. Shull, F., Rus, I., and Basili, V. (2000). How perspective-based reading can improve requirements inspections. IEEE Computer, 33(7):73 79.