Avaliando modelos arquiteturais atravs de um checklist baseado em atributos de qualidade

Aluno: Rafael Ferreira Barcelos Orientador: Guilherme Horta Travassos barcelos@cos.ufrj.br ght@cos.ufrj.br

Nvel: Mestrado Programa de Engenharia de Sistemas e Computao PESC, COPPE/UFRJ Ano de ingresso: 2004 Ms/Ano previsto para concluso: Maro de 2006 Resumo: Modelos de arquitetura de software possuem um papel importante como ponte entre os requisitos e a implementao. Estes modelos representam o primeiro conjunto de decises de projeto relacionado forma como os requisitos do sistema sero atendidos pelo produto final. A avaliao de modelos arquiteturais extremamente importante visto que, de acordo com vrios estudos na rea, o custo de correo de defeitos menor se a correo tiver sido realizada durante os primeiros estgios de projeto. Visando contribuir para tal atividade, esse trabalho prope o desenvolvimento de uma abordagem para inspecionar modelos de arquiteturas de software, antes de sua implementao. Essa abordagem, baseada em checklist, possui como objetivo identificar, nos modelos arquiteturais, discrepncias no atendimento aos requisitos especificados para o software. Palavras-chave: Qualidade de software; Verificao, validao e teste de software; Arquitetura, projeto e arcabouos (frameworks).

Avaliando modelos arquiteturais atrav es de um checklist baseado em atributos de qualidade

o 1. Introduc a
es de software, e observado o Com o aumento da complexidade e do tamanho das aplicac o o e manutenc o desses surgimento de novos desaos relacionados ao desenvolvimento, avaliac a a produtos. Visando trat a-los, os engenheiros de software est ao dando cada vez mais import ancia 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 a estrutura que compreende os elementos de software, as suas propriedades computacional e descrita atrav externamente vis veis e o relacionamento entre eles. Ela e es de um conjunto de o de um processo de desenvolvimento de software e que modelos constru dos durante a execuc a representam a estrutura de um software sob diferentes perspectivas. Modelos arquiteturais possuem um importante papel como ponte entre os requisitos do o, al sistema e a sua implementac a em de serem considerados o primeiro conjunto de decis oes de projeto relacionadas ao atendimento dos requisitos no sistema [Babar et al. 2004]. o de defeitos e menor se a atividade de Estudos demonstram que o custo de correc a o se realizar durante os primeiros est correc a agios de projeto [Boehm 1981]. Portanto, devido ` import a ancia da arquitetura do software, visto sua utilidade em diferentes momentos no processo de desenvolvimento de software, a revis ao dos modelos que a comp oem se torna uma atividade importante para o sucesso do projeto e tamb em desejada pelos stakeholders1 devido a o para a melhoria da qualidade do software. sua contribuic a Visando contribuir para tal atividade, esse trabalho prop oe o desenvolvimento de uma o. abordagem para inspecionar modelos de arquiteturas de software antes de sua implementac a Essa abordagem possui como objetivo identicar, nos modelos arquiteturais, discrep ancias relacionadas ao atendimento aos requisitos especicados para o software.

2. Trabalhos relacionados
o arquitetural. Com o Existem v arios trabalhos na literatura que descrevem m etodos de avaliac a objetivo de identicar os principais m etodos, uma revis ao sistem atica foi planejada e executada [Barcelos and Travassos 2004]. Como resultado dessa revis ao, 18 m etodos que atendem a esse objetivo foram identicados. Entre esses m etodos, dois se destacaram (SAAM [Kazman et al. 1994] e ATAM o de grande parte das demais. Esses [Kazman et al. 2000]) por servirem como base para a criac a o a determinados requisitos dois m etodos buscam avaliar a arquitetura principalmente em relac a o: execuc o de cen de qualidade e utilizam uma mesma t ecnica de avaliac a a arios que represen o a uma determinada caracter tam o comportamento esperado do software em relac a stica de 2 qualidade .
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 o arquitetural, as denidas para atender aos requisitos de qualidade especicados. Sendo assim, em uma avaliac a o aos requisitos. caracter sticas s ao avaliadas em relac a
1

 o, pois Esses m etodos utilizam os requisitos de qualidade como base apara a avaliac a durante o projeto de uma arquitetura, eles s ao os que mais inuenciam nas decis oes relacionadas ` denic o e a ` organizac o dos elementos arquiteturais. Em [Bass et al. 2003], por exemplo, a a a discutido que se n e ao fosse necess ario 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 alise dos m etodos identicados e resultados obtidos por surveys ([Babar et al. 2004, Dobrica and Niemela 2002]) identicaram quatro problemas principais: o, diculdades para avaliar simulgrande subjetividade dos m etodos, elevado custo de aplicac a o taneamente o atendimento a v arios requisitos de qualidade e contexto limitado para a aplicac a de alguns dos m etodos. o. A subjetividade dos m etodos decorre do uso de cen arios como t ecnica de avaliac a causado pela impossibilidade de identicar e gerar todos os poss Esse problema e veis cen arios, obrigando os stakeholders a utilizarem subjetividade e criatividade como abordagens para de o [Dobrica and Niemela 2002]. Al nir o conjunto de cen arios de avaliac a em disso, durante o dos cen a especicac a arios, o stakeholder inconscientemente pode denir cen arios que n ao o com a arquitetura, provoavaliam a arquitetura de forma completa, devido a sua familiarizac a o nos resultados da avaliac o. cando distorc a a o est O elevado custo de aplicac a a relacionado ao fato dos m etodos terem sido desenvolvidos para projetos de grande porte, que geralmente possuem alta disponibilidade de recursos. Com isso, somente um pequeno n umero de empresas conseguem aplicar de forma correta as es [Lattanze 2005]. avaliac o a realizac o da avaliac o sob a perspectiva de um n Outra deci encia observada e a a umero o arrestrito de requisitos de qualidade. [Dobrica and Niemela 2002] sugere que uma avaliac a quitetural deve ser feita sob a perspectiva de m ultiplos requisitos, permitindo uma melhor compreens ao dos pontos fracos e fortes dos complexos sistemas atuais. ` imaturidade da a rea de Arquitetura O quarto problema identicado est a relacionado a o de Software. Devido a essa imaturidade, existe falta de consenso na comunidade em relac a ` s denic es b ` forma de representar uma arquitetura [Clements et al. 2004, tanto a o asicas quanto a o arquitetural, por exemplo, s Buschmann et al. 1996]. Os m etodos de avaliac a ao baseados em o, o que diculta a sua utilizac o em suas pr oprias e espec cas abordagens de documentac a a diferentes projetos ou contextos. o Portanto, esses problemas motivaram a busca por um m etodo que permita a avaliac a de modelos de arquiteturas de software. A abordagem proposta busca avaliar as caracter sticas o aos requisitos que foram utilizados no projeto da arquide qualidades da arquitetura em relac a tetura e foi desenvolvida com o intuito de minimizar os problemas previamente discutidos.

3. Checklist baseado em atributos de qualidade

o de cen uma das t o arquitetural, uma vez A execuc a arios e ecnicas mais usadas na avaliac a o das caracter que permite a f acil representac a sticas que se deseja avaliar [Abowd et al. 1997]. Contudo, os m etodos que utilizam essa t ecnica como base apresentam problemas, conforme o em um contexto industrial. descritos anteriormente, que dicultam a sua aplicac a Uma outra abordagem que comprovadamente benecia a melhoria da qualidade de arte a utilizac o de t o [Shull et al. 2000, Conradi et al. 2003]. fatos de software e a ecnicas de inspec a que a denic o de uma abordagem de Sendo assim, a hip otese de pesquisa desse trabalho e a o permita a avaliac o de modelos arquiteturais, durante o processo de desenvolvimento, inspec a a

 o de discrep ` adequac o da arquitetura atrav es da identicac a ancias que estejam relacionadas a a aos requisitos de qualidade especicados. o e justicada devido a ` s suas caracA escolha de checklist como t ecnica de inspec a o existentes: ter sticas quando comparada a outras t ecnicas de inspec a o formal e - Ad-hoc: Uma t ecnica ad-hoc n ao oferece apoio ou procedimento de execuc a o. Al sistem atica da inspec a em do mais, os resultados obtidos dependem principalmente da capacidade, compet encia e experi encia do inspetor [Chen et al. 2002]. um procedimento que visa guiar individu- T ecnica de leitura: Uma t ecnica de leitura e ncia, almente os inspetores no entendimento de um artefato de software e, por conseq ue o de discrep na identicac a ancias [Shull et al. 2000]. o baseadas nessa t Abordagens de avaliac a ecnica [Shull et al. 2000, Conradi et al. 2003] o de defeitos quando comparadas a outras t s ao mais ecientes na detecc a ecnicas de o, como checklists, por exemplo. Por inspec a em, para que seja utilizada, o artefato deve ser representado em uma forma espec ca e padronizada, que ainda n ao pode ser atin rea de Arquitetura de Software. gida na a Portanto, o checklist aparece como uma t ecnica adequada para ser aplicada durante a o de um modelo de arquitetura de software. inspec a o V arias abordagens baseadas em checklist j a foram denidas visando a identicac a de defeitos em modelos arquiteturas [Aeronautics and Administration 1993, Hollocker 1990]. Contudo, os itens de questionamento s ao espec cos ao dom nio do software avaliado, dicul o em um contexto diferente do qual foi projetado. tando a sua aplicac a o realizada atrav Para que a avaliac a es desse checklist minimize os mesmos problemas observados nos m etodos identicados, as seguintes caracter sticas foram denidas: - Os itens de questionamento devem ser criados a partir da an alise das abordagens de pro o principalmente a forma como os requisitos jeto arquitetural, levando em considerac a o de qualidade s ao atendidos. Com isso, pretende-se reduzir a subjetividade em relac a avaliado; ao que e - Os itens de questionamento devem ser agrupados de acordo com os atributos de qualidade que est ao relacionados. Esses atributos consistem em diferentes categorias utilizadas para classicar caracter sticas de qualidade similares [Bass et al. 2003]. Com isso, o a v os grupos de itens permitem avaliar os modelos arquiteturais em relac a arios tipos de caracter sticas de qualidade; o n - A sua aplicac a ao requer elaboradas atividades, como as necess arias para a o de cen o seja realizada com especicac a arios por exemplo, permitindo que a avaliac a baixo custos. - Os itens de questionamento devem avaliar a abordagem empregada pelo arquiteto para atender aos requisitos e n ao a forma como eles foram documentados nos modelos. Com poss isso, e vel aplicar o m etodo em modelos arquiteturais que pertencem a diferentes o; contextos e que utilizam diferentes abordagens de documentac a

4. Metodologia utilizada e estado atual do trabalho

o e O desenvolvimento da abordagem proposta seguiu quatro passos que visam a sua construc a o: avaliac a Passo 1: Identicac a a o das abordagens de avaliac o arquitetural existentes o de um estudo O primeiro passo realizado foi o planejamento e execuc a o arquitetural que identique e caracterize os m etodos existentes de avaliac a

[Barcelos and Travassos 2004]. Para executar esse estudo, uma revis ao sistem atica [Biolchini et al. 2005] foi realizada. Passo 2: An alise dos conceitos relacionados ao projeto e avaliac a o arquitetural o, foi identicado a necessidade Durante uma an alise inicial dos m etodos de avaliac a em entender como os modelos arquiteturais s ao criados e o papel dos requisitos nesse o fosse realizada. Para isso, os seguintes questioprocesso, para que ent ao a avaliac a es, descritas nos requisitos, s namentos devem ser respondidos: (1) quais informac o ao necess arias para projetar arquiteturas, (2) como se projeta arquiteturas, (3) como se documenta esses modelos e (4) como eles s ao avaliados. Ao responder essas perguntas, diversos tipos de conhecimento poder ao ser reunidos, ` forma de se projetar arquiteturas de software quanto a ` forma de se relacionados tanto a especicar requisitos sob a perspectiva do arquiteto de software. Passo 3: Denic a a o e construc o da abordagem proposta o dos m o identicados permitiu a observac o de caA caracterizac a etodos de avaliac a a es. A compreens racter sticas positivas e algumas limitac o ao desses m etodos e a an alise o como m de suas caracter sticas serviram como base para denir inspec a etodo de o. Para a denic o de checklist como t o, as caracter avaliac a a ecnica de inspec a sticas rea de Arquitetura de Software foram um fator determinante. da a o, est Atualmente, uma primeira vers ao do checklist est a sendo gerada. Para sua criac a ao es obtidas atrav sendo usadas como base informac o es da an alise sobre como a arquitetura deve ser projetada para atender ao requisitos, principalmente os de qualidade. Passo 4: Estudo de Viabilidade o do checklist, um estudo de viabilidade [Shull et al. 2001] ser Ap os a criac a a realizado. obter um retorno sobre a relev O objetivo desse estudo e ancia dos itens de questiona o de defeitos, e evolu mento na identicac a -los se necess ario. apresentado o cronograma das atividades, para o ano de 2005, que ainda Na Tabela 1, e faltam ser executadas para nalizar os passos 2, 3 e 4.
Atividades Passo 2::Entender inu encia dos requisitos na arquitetura o do checklist Passo 3::Construc a Passo 4::Estudo de Viabilidade o do checklist Passo 4::Evoluc a MAI JUN JUL AGO SET OUT NOV DEZ

Tabela 1. Cronograma das atividades dos passos 2, 3 e 4 para 2005

es 5. Conclus oes e Principais Contribuic o

o arquitetural que possuem um certo n Mesmo existindo alguns m etodos de avaliac a vel de mao turidade [Kazman et al. 1994], ainda existem v arios problemas que dicultam a sua aplicac a em empresas pequenas ou que apresentam baixa maturidade no desenvolvimento de software. o que atenda a ` s necessidades Com o objetivo de desenvolver uma abordagem de avaliac a o a denic o de desses tipos de empresas, este trabalho apresentar a como principal contribuic a a um checklist para inspecionar modelos arquiteturais. o desse trabalho, obtida atrav Uma outra contribuic a es do conhecimento adquirido na o de recomendac es an alise da inu encia dos requisitos no projeto arquitetural, est a na denic a o o de requisitos. Essas recomendac es buscam indicar para a atividade de especicac a o es u teis ao projeto da arquitetura, al o dos requisitos em informac o em de possibilitar a avaliac a o a ` s expectativas do arquiteto de software. relac a

Agradecimentos
` FAPEAM e ao CNPq pelo apoio nanceiro necess Os autores gostariam de agradecer a ario para realizar esse trabalho.

Refer encias
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: Identicando as metodologias que avaliam a sua qualidade. Monograa apresentada na disciplina de Teste Orientado a Objetos - COPPE/UFRJ. Bass, L., Clements, P., and Kazman, R. (2003). Software Architecture in Practice, Second Edition. Addison Wesley. 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 221229. 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. AddisonWesley. 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 483500. 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 8190. 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 288296. Shull, F., Rus, I., and Basili, V. (2000). How perspective-based reading can improve requirements inspections. IEEE Computer, 33(7):7379.