Avaliando Software Orientado a Aspectos: Um Método Quantitativo Baseado em Regras Heurísticas Eduardo Magno Lages Figueiredo 21 de Outubro de 2005

Laboratório de Engenharia de Software – PUC-Rio 2 Tópicos da Apresentação 1.Motivação 2.Método de Avaliação 3.Métricas Separação de Interesses Acoplamento, Coesão e Tamanho Exemplo de Aplicação das Métricas 4.Regras Heurísticas Exemplo de Aplicação das Regras 5.Trabalhos Futuros 6.Trabalhos Relacionados 7.Conclusões

Laboratório de Engenharia de Software – PUC-Rio 3 Motivação Como fazer medições de forma sistemática e seguindo passos para alcançar os resultados? Como interpretar os resultados das medições de tal forma a refletir a qualidade do projeto? Como avaliar sistemas complexos de forma automatizada?

Laboratório de Engenharia de Software – PUC-Rio 4 Motivação Como fazer medições de forma sistemática e seguindo passos para alcançar os resultados? –Método de Avaliação Como interpretar os resultados das medições de tal forma a refletir a qualidade do projeto? –Regras Heurísticas Como avaliar sistemas complexos de forma automatizada? –Ferramenta de Suporte

Laboratório de Engenharia de Software – PUC-Rio 5 O Método de Avaliação Multiple Alternatives Aspect-Oriented Rules Single Artifact or Intra-Module Evaluation Inter-Module Evaluation Aspect-Oriented Metrics SoC Evaluation Final Implementation Overall Analysis artifacts resource assessment steps

Laboratório de Engenharia de Software – PUC-Rio 6 O Método de Avaliação Multiple Alternatives Aspect-Oriented Rules Single Artifact or Intra-Module Evaluation Inter-Module Evaluation Aspect-Oriented Metrics SoC Evaluation Final Implementation Overall Analysis artifacts activity resource assessment steps Application of Rules Analysis Data Collection Refactoring

Laboratório de Engenharia de Software – PUC-Rio 7 O Método de Avaliação Multiple Alternatives Aspect-Oriented Rules Single Artifact or Intra-Module Evaluation Inter-Module Evaluation Aspect-Oriented Metrics SoC Evaluation Final Implementation Overall Analysis artifacts activity resource assessment steps Application of Rules Analysis Data Collection Refactoring

Laboratório de Engenharia de Software – PUC-Rio 8 O Método de Avaliação Multiple Alternatives Aspect-Oriented Rules Single Artifact or Intra-Module Evaluation Inter-Module Evaluation Aspect-Oriented Metrics SoC Evaluation Final Implementation Overall Analysis artifacts activity resource assessment steps Application of Rules Analysis Data Collection Refactoring

Laboratório de Engenharia de Software – PUC-Rio 9 O Método de Avaliação Multiple Alternatives Aspect-Oriented Rules Single Artifact or Intra-Module Evaluation Inter-Module Evaluation Aspect-Oriented Metrics SoC Evaluation Final Implementation Overall Analysis artifacts activity resource assessment steps Application of Rules Analysis Data Collection Refactoring

Laboratório de Engenharia de Software – PUC-Rio 10 Concern Diffusion over Components (CDC) [14] –conta o número de componentes principais de um interesse e os outros componentes que fazem referência à estes Concern Diffusions over Lines of Code (CDLOC) [14] –conta o número de pontos de transição entre o interesse avaliado e os outros interesses do sistema através das linhas de código NOAconcern –conta para cada componente o número de atributos do interesse NOOconcern –conta para cada componente o número de operações do interesse LOCconcern –conta para cada componente o número de LOC do interesse Métricas Separação de Interesses [14] SantAnna, C. et al. On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. Proc. of Brazilian Symposium on Software Engineering, Brazil, (2003), pp

Laboratório de Engenharia de Software – PUC-Rio 11 Exemplo de Métricas SoC Interesse Sombreado: Papel Observer (Observer) public interface Observer { public void update(Subject s); } public class Screen implements Subject, Observer { private HashSet observers; private String name;... public void update(Subject s) { display(Update received!"); } CDC = 2 CDLOC = 4 NOAconcern = 0 NOOconcern = LOCconcern = 3 + 4

Laboratório de Engenharia de Software – PUC-Rio 12 Acoplamento –Coupling Between Components (CBC) [14] –Depth Inheritance Tree (DIT) [14] –Number of Children (NOC) Coesão –Lack of Cohesion in Operations (LCOO) [14] Tamanho –Vocabulary Size (VS) [14] –Number of Operations (NOO) –Number of Attributes (NOA) [14] –Lines of Code (LOC) [14] Métricas Acoplamento, Coesão e Tamanho [14] SantAnna, C. et al. On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework. Proc. of Brazilian Symposium on Software Engineering, Brazil, (2003), pp

Laboratório de Engenharia de Software – PUC-Rio 13 Exemplo de Métricas Interesse Sombreado: Papel Observer (Observer) CDC = 2 CDLOC = 4 NOAconcern = 0 NOOconcern = LOCconcern = CBC = 13 (soma) DIT = 2 (máximo) NOC = LCOO = 16 (soma) VS = 5 NOO = 21 (soma) NOA = 6 (soma) LOC = 111 (soma)

Laboratório de Engenharia de Software – PUC-Rio 14 Exemplo de Métricas Interesse Sombreado: Papel Observer (Observer) CDC = 2 CDLOC = 4 NOAconcern = 0 NOOconcern = LOCconcern = CBC = 13 (soma) DIT = 2 (máximo) NOC = LCOO = 16 (soma) VS = 5 NOO = 21 (soma) NOA = 6 (soma) LOC = 111 (soma) O que podemos dizer sobre o sistema a partir dos valores medidos? –E sobre o código que implementa o papel Observer do padrão Observer? Qual é o raciocínio em relação aos valores medidos?

Laboratório de Engenharia de Software – PUC-Rio 15 Regras Heurísticas R01: if CDLOC is 2 then MODULAR CONCERN R02: if CDLOC is bigger than 2 then (POSSIBLE) TANGLED CONCERN Concern (Possible) Tangled Concern R01R02 Modular Concern

Laboratório de Engenharia de Software – PUC-Rio 16 Regras Heurísticas R01: if CDLOC is 2 then MODULAR CONCERN R02: if CDLOC is bigger than 2 then (POSSIBLE) TANGLED CONCERN Exemplo: Padrão Façade [HK, 2002] CDLOC = 2 Pela regra R01, o padrão Façade é Modular

Laboratório de Engenharia de Software – PUC-Rio 17 Regras Heurísticas R03: if CDC / VS of (POSSIBLE) TANGLED CONCERN is high then HIGHLY SCATTERED CONCERN R04: if CDC / VS of (POSSIBLE) TANGLED CONCERN is not high then LOW SCATTERED CONCERN R03 R04 (Possible) Tangled Concern Highly Scattered Concern Low Scattered Concern

Laboratório de Engenharia de Software – PUC-Rio 18 Regras Heurísticas R03: if CDC / VS of (POSSIVEL) TANGLED CONCERN is high then HIGHLY SCATTERED CONCERN R04: if CDC / VS of (POSSIVEL) TANGLED CONCERN is not high then LOW SCATTERED CONCERN Exemplo: Papel Creator (Factory Method) [HK, 2002] CDLOC = 6 CDC / VS = 4 / 4 = 1 Pela regra R03: Papel Creator é High Scattered

Laboratório de Engenharia de Software – PUC-Rio 19 Regras Heurísticas R05: if (NOAconcern / NOA is high) and (NOOconcern / NOO is high) for all components of HIGHLY SCATTERED CONCERN then POSSIBLE PRIMARY CONCERN R06: if (NOAconcern / NOA is not high) and (NOOconcern / NOO is not high) for one or more components of HIGHLY SCATTERED CONCERN then POSSIBLE SECONDARY CONCERN R07: if (NOAconcern / NOA is high) and (NOOconcern / NOO is high) for all components of LOW SCATTERED CONCERN then POSSIBLE PRIMARY CONCERN R08: if (NOAconcern / NOA is not high) and (NOOconcern / NOO is not high) for one or more components of LOW SCATTERED CONCERN then POSSIBLE SECONDARY CONCERN R05 R06 Highly Scattered Concern Low Scattered Concern Possible Secondary Concern Possible Primary Concern R07 R08

Laboratório de Engenharia de Software – PUC-Rio 20 Regras Heurísticas R05: if (NOAconcern / NOA is high) and (NOOconcern / NOO is high) for all components of HIGHLY SCATTERED CONCERN then POSSIBLE PRIMARY CONCERN R06: if (NOAconcern / NOA is not high) and (NOOconcern / NOO is not high) for one or more components of HIGHLY SCATTERED CONCERN then POSSIBLE SECONDARY CONCERN R07: if (NOAconcern / NOA is high) and (NOOconcern / NOO is high) for all components of LOW SCATTERED CONCERN then POSSIBLE PRIMARY CONCERN R08: if (NOAconcern / NOA is not high) and (NOOconcern / NOO is not high) for one or more components of LOW SCATTERED CONCERN then POSSIBLE SECONDARY CONCERN CDLOC = 4 (Regra 02: Possible Tangled) CDC / VS = 2 / 5 = 0,4 (Regra 04: Low Scattered) ComponentNOAconcern / NOANOOconcern / NOO Screen0,000,17 Observer-1,00 Exemplo: Papel Observer (Observer) [HK, 2002] Pela regra R08: Papel Observer é Possible Secondary

Laboratório de Engenharia de Software – PUC-Rio 21 Regras Heurísticas R09: if (LOCconcern / LOC is high) for all components of POSSIVEL PRIMARY CONCERN then PRIMARY CONCERN R10: if (LOCconcern / LOC é baixo) for one or more components of POSSIVEL SECONDARY CONCERN then SECONDARY CONCERN R09 Possible Secondary Concern Possible Primary Concern R10 Secondary Concern Primary Concern

Laboratório de Engenharia de Software – PUC-Rio 22 Regras Heurísticas CDLOC = 4 (Regra 02: Possible Tangled) CDC / VS = 2 / 5 = 0,4 (Regra 04: Low Scattered) ComponentNOAconcern / NOANOOconcern / NOOLOCconcern / LOC Screen0,000,170,14 Observer-1,00 Exemplo: Papel Observer (Observer) [HK, 2002] Regra R08: Possible Secondary Regra R10: Papel Observer é Secondary Concern R09: if (LOCconcern / LOC is high) for all components of POSSIVEL PRIMARY CONCERN then PRIMARY CONCERN R10: if (LOCconcern / LOC é baixo) for one or more components of POSSIVEL SECONDARY CONCERN then SECONDARY CONCERN

Laboratório de Engenharia de Software – PUC-Rio 23 Highly Scattered Concern (Possible) Tangled Concern Low Scattered Concern Secondary Concern Primary Concern R01 R02 R03R04 R05R06R07R08 Possible Secondary Concern Possible Primary Concern R10R09 Modular Concern R01: if CDLOC is 2 then MODULAR CONCERN R02: if CDLOC is bigger than 2 then (POSSIBLE) TANGLED CONCERN R03: if CDC / VS of (POSSIBLE) TANGLED CONCERN is high then HIGHLY SCATTERED CONCERN R04: if CDC / VS of (POSSIBLE) TANGLED CONCERN is not high then LOW SCATTERED CONCERN R05: if (NOAconcern / NOA is high) and (NOOconcern / NOO is high) for all components of HIGHLY SCATTERED CONCERN then POSSIBLE PRIMARY CONCERN R06: if (NOAconcern / NOA is not high) and (NOOconcern / NOO is not high) for one or more components of HIGHLY SCATTERED CONCERN then POSSIBLE SECONDARY CONCERN R07: if (NOAconcern / NOA is high) and (NOOconcern / NOO is high) for all components of LOW SCATTERED CONCERN then POSSIBLE PRIMARY CONCERN R08: if (NOAconcern / NOA is not high) and (NOOconcern / NOO is not high) for one more components of LOW SCATTERED CONCERN then POSSIBLE SECONDARY CONCERN R09: if (LOCconcern / LOC is high) for all components of POSSIBLE PRIMARY CONCERN then PRIMARY CONCERN R10: if (LOCconcern / LOC is not high) for one or more components of POSSIBLE SECONDARY CONCERN then SECONDARY CONCERN

Laboratório de Engenharia de Software – PUC-Rio 24 Trabalhos Futuros Aplicar as regras heurísticas em outros sistemas (e diferentes interesses) –Portalware (Colaboração, Adaptação, Mobilidade) –Health Watcher (Persistência, Distribuição) Propor regras heurísticas envolvendo tamanho, acoplamento e coesão (em andamento) –Aplicar tais regras em estudos de caso. Implementar uma ferramenta de suporte ao método (medição e regras heurísticas) (em andamento)

Laboratório de Engenharia de Software – PUC-Rio 25 Trabalhos Relacionados Tekinerdogan propôs um método de análise orientado a aspecto –Seu objetivo é avaliar arquitetura de software em relação a cobertura de cenários SantAnna et al. define um framework de avaliação para DSOA em termos de reusabilidade e manutenibilidade –Este framework não inclui um conjunto explícito de passos, nem regras heurísticas

Laboratório de Engenharia de Software – PUC-Rio 26 Alencar et al. apresenta uma abordagem para análise e medição de software orientado a aspecto utilizando uma linguagem de consulta –Esta abordagem não apresenta um método definido por passos, nem regras heurísticas Ceccato e Tonella propõe uma ferramenta de medição de software orientado a aspectos –Sua ferramenta não é baseado em nenhum método de avaliação Trabalhos Relacionados

Laboratório de Engenharia de Software – PUC-Rio 27 Conclusões Apenas medições podem não ser suficientes para revelar qualidades e problemas em um sistema –Métodos de avaliação (e regras heurísticas) podem ajudar, especialmente em sistemas complexos O método proposto (em especial, as regras heurísticas) podem encontrar bad smells e consequentemente, oportunidades para refactoring

Laboratório de Engenharia de Software – PUC-Rio 28 Bibliografia Principal [1]Alencar, P. et. al.: A Query-Based Approach for Aspect Understanding, Measurement and Analysis. Technical Report CS , School of Computer Science, University of Waterloo, Canada, (2004). [2]Cacho, N. et al.: Composing Design Patterns: A Scalability Study of Aspect-Oriented Programming. Submitted to AOSD06, Bonn, Germany, (2006). [3]Ceccato, M. and Tonella P. Measuring the Effects of Software Aspectization. In Proceedings of the 1st Workshop on Aspect Reverse Engineering (CD-ROM), The Netherlands, (2004). [4]Chidamber, S., Kemerer, C.: A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, (1994), pp [5]Fenton, N., Pfleeger, S.: Software Metrics: A Rigorous Practical Approach. London: PWS, (1997). [6]Figueiredo, E. et. al.: Assessing Aspect-Oriented Artifacts: Towards a Tool-Supported Quantitative Method. In Proceedings of the ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE'05), [7]Figueiredo, E., Staa, A.: Avaliação de um Modelo de Qualidade para Implementações Orientadas a Objetos e Orientadas a Aspectos. Technical Report nº 14/05, 29 pages. Informatic Department, PUC-Rio, 2005.

Laboratório de Engenharia de Software – PUC-Rio 29 [8]Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison- Wesley, (1995). [9]Garcia, A. et al.: Modularizing Design Patterns with Aspects: A Quantitative Study. In Proceedings of the AOSD05, Chicago, USA, (2005), pp [10]Garcia, A. et al.: Separation of Concerns in Multi-Agent Systems: An Empirical Study. In Software Engineering for Multi- Agent Systems II, Springer, LNCS 2940, (2004). [11]Hannemann, J., Kiczales, G.: Design Pattern Implementation in Java and AspectJ. In Proceedings of the OOPSLA02, (2002), pp [12]Kiczales, G. et al.: Aspect-Oriented Programming. In Proceedings of the ECOOP97, LNCS 1241, Springer, Finland, (1997), pp [13]Kulesza et. al.: Aspectization of Distribution and Persistence: Quantifying the Effects of AOP. Submitted to IEEE Software (Special issue on AOSD), [14]SantAnna, C. et al.: On the Reuse and Maintenance of Aspect- Oriented Software: An Assessment Framework. In Proceedings of the Brazilian Symposium on Software Engineering, Brazil, (2003), pp Bibliografia Principal

Laboratório de Engenharia de Software – PUC-Rio 30 Arquitetura da Ferramenta

Laboratório de Engenharia de Software – PUC-Rio 31 R01: Se ( CBC / VS é alto ) e (( DIT / VS é alto ) ou ( NOC / VS é alto )) para o SYSTEM então HIGHLY COUPLING SYSTEM R02: Se ( CBC / VS é baixo ) e (( DIT / VS é baixo) ou ( NOC / VS é baixo)) para o SYSTEM então LOW COUPLING SYSTEM R03: Se ( LCOO / VS é alto ) para o HIGHLY COUPLING SYSTEM então HIGHLY COUPLING AND LOW COHESIVE SYSTEM R04: Se ( LCOO / VS é baixo ) para o HIGHLY COUPLING SYSTEM então HIGHLY COUPLING AND HIGHLY COHESIVE SYSTEM R05: Se ( LCOO / VS é alto ) para o LOW COUPLING SYSTEM então LOW COUPLING AND LOW COHESIVE SYSTEM R06: Se ( LCOO / VS é baixo ) para o LOW COUPLING SYSTEM então LOW COUPLING AND HIGHLY COHESIVE SYSTEM Highly Coupling System Low Coupling R01 R02 R03R04R05R06 Highly Coupling Highly Cohesion Highly Coupling Low Cohesion Low Coupling Highly Cohesion Low Coupling Low Cohesion