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
MultipleAlternatives
Aspect-OrientedRules
SingleArtifact
or Intra-ModuleEvaluation
Inter-ModuleEvaluation
Aspect-OrientedMetrics
SoCEvaluation
Final Implementation
OverallAnalysis
artifacts
resource
assessment steps
Laboratório de Engenharia de Software – PUC-Rio 6
O Método de Avaliação
MultipleAlternatives
Aspect-OrientedRules
SingleArtifact
or Intra-ModuleEvaluation
Inter-ModuleEvaluation
Aspect-OrientedMetrics
SoCEvaluation
Final Implementation
OverallAnalysis
artifacts
activity
resource
assessment steps
Application ofRules
AnalysisData
CollectionRefactoring
Laboratório de Engenharia de Software – PUC-Rio 7
O Método de Avaliação
MultipleAlternatives
Aspect-OrientedRules
SingleArtifact
or Intra-ModuleEvaluation
Inter-ModuleEvaluation
Aspect-OrientedMetrics
SoCEvaluation
Final Implementation
OverallAnalysis
artifacts
activity
resource
assessment steps
Application ofRules
AnalysisData
CollectionRefactoring
Laboratório de Engenharia de Software – PUC-Rio 8
O Método de Avaliação
MultipleAlternatives
Aspect-OrientedRules
SingleArtifact
or Intra-ModuleEvaluation
Inter-ModuleEvaluation
Aspect-OrientedMetrics
SoCEvaluation
Final Implementation
OverallAnalysis
artifacts
activity
resource
assessment steps
Application ofRules
AnalysisData
CollectionRefactoring
Laboratório de Engenharia de Software – PUC-Rio 9
O Método de Avaliação
MultipleAlternatives
Aspect-OrientedRules
SingleArtifact
or Intra-ModuleEvaluation
Inter-ModuleEvaluation
Aspect-OrientedMetrics
SoCEvaluation
Final Implementation
OverallAnalysis
artifacts
activity
resource
assessment steps
Application ofRules
AnalysisData
CollectionRefactoring
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étricasSeparação de Interesses
[14] Sant’Anna, 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. 19-34.
Laboratório de Engenharia de Software – PUC-Rio 11
Exemplo de Métricas SoCInteresse Sombreado: Papel Observer (Observer)
Screen
-observers:HashSet-name:String
+Screen+display:void+addObserver:void+removeObserver:void+notifyObservers:void+refresh:void
Point
-observers:HashSet
+Point+addObserver:void+removeObserver:void+notifyObservers:void
x:int y:int color:Color
Main
+main:void
interfaceChangeSubject
+addObserver:void+removeObserver:void+notifyObservers:void
interfaceChangeObserver
+refresh:void
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 = 2CDLOC = 4NOAconcern = 0NOOconcern = 1 + 1LOCconcern = 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étricasAcoplamento, Coesão e Tamanho
[14] Sant’Anna, 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. 19-34.
Laboratório de Engenharia de Software – PUC-Rio 13
Exemplo de MétricasInteresse Sombreado: Papel Observer (Observer)
Screen
-observers:HashSet-name:String
+Screen+display:void+addObserver:void+removeObserver:void+notifyObservers:void+refresh:void
Point
-observers:HashSet
+Point+addObserver:void+removeObserver:void+notifyObservers:void
x:int y:int color:Color
Main
+main:void
interfaceChangeSubject
+addObserver:void+removeObserver:void+notifyObservers:void
interfaceChangeObserver
+refresh:void
CDC = 2CDLOC = 4NOAconcern = 0NOOconcern = 1 + 1LOCconcern = 3 + 4CBC = 13 (soma)DIT = 2 (máximo)NOC = 2 + 1LCOO = 16 (soma)VS = 5NOO = 21 (soma)NOA = 6 (soma)LOC = 111 (soma)
Laboratório de Engenharia de Software – PUC-Rio 14
Exemplo de MétricasInteresse Sombreado: Papel Observer (Observer)
Screen
-observers:HashSet-name:String
+Screen+display:void+addObserver:void+removeObserver:void+notifyObservers:void+refresh:void
Point
-observers:HashSet
+Point+addObserver:void+removeObserver:void+notifyObservers:void
x:int y:int color:Color
Main
+main:void
interfaceChangeSubject
+addObserver:void+removeObserver:void+notifyObservers:void
interfaceChangeObserver
+refresh:void
CDC = 2CDLOC = 4NOAconcern = 0NOOconcern = 1 + 1LOCconcern = 3 + 4CBC = 13 (soma)DIT = 2 (máximo)NOC = 2 + 1LCOO = 16 (soma)VS = 5NOO = 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)TangledConcern
R01 R02
ModularConcern
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]
OutputFacade
+printNormal:void+printFancy:void+printDecoration:void
RegularScreen
+print:void+newline:void
Decoration
decoration:String
StringTransformer
+transformToUpper:String+transformToLower:String
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 CONCERNR04: if CDC / VS of (POSSIBLE) TANGLED CONCERN is not high
then LOW SCATTERED CONCERN
R03 R04
(Possible)TangledConcern
HighlyScatteredConcern
LowScatteredConcern
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 CONCERNR04: if CDC / VS of (POSSIVEL) TANGLED CONCERN is not high then
LOW SCATTERED CONCERN
GUIComponentCreator
-lastFrameLocation:Point
+createComponent:JComponent+showFrame:void
title:String
LabelCreator
+createComponent:JComponent
title:String
ButtonCreator
+createComponent:JComponent
title:String
Main
+main:void
Exemplo: Papel Creator (Factory Method) [HK, 2002]
CDLOC = 6CDC / 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 CONCERNR06: 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 CONCERNR08: 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
HighlyScatteredConcern
LowScatteredConcern
PossibleSecondaryConcern
PossiblePrimaryConcern
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 CONCERNR06: if (NOAconcern / NOA is not high) and (NOOconcern / NOO is not high) for one or
more components of HIGHLY SCATTERED CONCERN then POSSIBLE SECONDARY CONCERNR07: if (NOAconcern / NOA is high) and (NOOconcern / NOO is high) for all components
of LOW SCATTERED CONCERN then POSSIBLE PRIMARY CONCERNR08: 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)
Component NOAconcern / NOA NOOconcern / NOO
Screen 0,00 0,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 CONCERNR10: if (LOCconcern / LOC é baixo) for one or more components
of POSSIVEL SECONDARY CONCERN then SECONDARY CONCERN
R09
PossibleSecondaryConcern
PossiblePrimaryConcern
R10 SecondaryConcern
PrimaryConcern
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)
Component NOAconcern / NOA NOOconcern / NOO LOCconcern / LOC
Screen 0,00 0,17 0,14
Observer - 1,00 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 CONCERNR10: 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
HighlyScatteredConcern
Concern
(Possible)TangledConcern
LowScatteredConcern
SecondaryConcern
PrimaryConcern
R01
R02
R03 R04
R05 R06 R07 R08
PossibleSecondaryConcern
PossiblePrimaryConcern
R10R09
ModularConcern
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
• Sant’Anna 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-2004-13, 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 AOSD’06, 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. 476-493.
[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), 2005.
[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 AOSD’05, Chicago, USA, (2005), pp. 3-14.
[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 OOPSLA’02, (2002), pp. 161-173.
[12] Kiczales, G. et al.: Aspect-Oriented Programming. In Proceedings of the ECOOP’97, LNCS 1241, Springer, Finland, (1997), pp. 220-242.
[13]Kulesza et. al.: Aspectization of Distribution and Persistence: Quantifying the Effects of AOP. Submitted to IEEE Software (Special issue on AOSD), 2005.
[14]Sant’Anna, 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. 19-34.
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
HighlyCoupling
System
LowCoupling
R01 R02
R03 R04 R05 R06
Highly CouplingHighly Cohesion
Highly CouplingLow Cohesion
Low CouplingHighly Cohesion
Low CouplingLow Cohesion
Top Related