Avaliando Software Orientado a Aspectos:
Um Método Quantitativo Baseado em Regras
Heurísticas
Eduardo Magno Lages Figueiredo
21 de Outubro de 2005
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
2
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
3
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
4
O Método de Avaliação
Aspect-Oriented
Metrics
Single
Artifact
or
Multiple
Alternatives
SoC
Evaluation
Intra-Module
Evaluation
Aspect-Oriented
Rules
Inter-Module
Evaluation
Overall
Analysis
Final Implementation
artifacts
resource
assessment steps
Laboratório de Engenharia de Software – PUC-Rio
5
O Método de Avaliação
Aspect-Oriented
Metrics
Single
Artifact
or
Multiple
Alternatives
artifacts
SoC
Evaluation
Data
Collection
Intra-Module
Evaluation
Application of
Rules
Aspect-Oriented
Rules
Inter-Module
Evaluation
Analysis
Overall
Analysis
Refactoring
activity
resource
assessment steps
Laboratório de Engenharia de Software – PUC-Rio
Final Implementation
6
O Método de Avaliação
Aspect-Oriented
Metrics
Single
Artifact
or
Multiple
Alternatives
artifacts
SoC
Evaluation
Data
Collection
Intra-Module
Evaluation
Application of
Rules
Aspect-Oriented
Rules
Inter-Module
Evaluation
Analysis
Overall
Analysis
Refactoring
activity
resource
assessment steps
Laboratório de Engenharia de Software – PUC-Rio
Final Implementation
7
O Método de Avaliação
Aspect-Oriented
Metrics
Single
Artifact
or
Multiple
Alternatives
artifacts
SoC
Evaluation
Data
Collection
Intra-Module
Evaluation
Application of
Rules
Aspect-Oriented
Rules
Inter-Module
Evaluation
Analysis
Overall
Analysis
Refactoring
activity
resource
assessment steps
Laboratório de Engenharia de Software – PUC-Rio
Final Implementation
8
O Método de Avaliação
Aspect-Oriented
Metrics
Single
Artifact
or
Multiple
Alternatives
artifacts
SoC
Evaluation
Data
Collection
Intra-Module
Evaluation
Application of
Rules
Aspect-Oriented
Rules
Inter-Module
Evaluation
Analysis
Overall
Analysis
Refactoring
activity
resource
assessment steps
Laboratório de Engenharia de Software – PUC-Rio
Final Implementation
9
Métricas
Separação de Interesses
• 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

[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
10
Exemplo de Métricas SoC
Interesse Sombreado: Papel Observer (Observer)
interface
interface
C ha ng eS ubj ect
Ma i n
C ha ng eO bs erv er
+main:void
+addObserver:void
+removeObserver:void
+notifyObservers:void
+refresh:void
P oint
S creen
-observers:HashSet
-observers:HashSet
-name:String
+Point
+addObserver:void
+removeObserver:void
+notifyObservers:void
x:int
y:int
color:Color
+Screen
+display:void
+addObserver:void
+removeObserver:void
+notifyObservers:void
+refresh:void
CDC = 2
CDLOC = 4
NOAconcern = 0
NOOconcern = 1 + 1
LOCconcern = 3 + 4
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!");
}
}
Laboratório de Engenharia de Software – PUC-Rio
11
Métricas
Acoplamento, Coesão e Tamanho
• 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]

[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
12
Exemplo de Métricas
Interesse Sombreado: Papel Observer (Observer)
interface
interface
C ha ng eS ubj ect
Ma i n
C ha ng eO bs erv er
+main:void
+addObserver:void
+removeObserver:void
+notifyObservers:void
+refresh:void
P oint
S creen
-observers:HashSet
-observers:HashSet
-name:String
+Point
+addObserver:void
+removeObserver:void
+notifyObservers:void
x:int
y:int
color:Color
+Screen
+display:void
+addObserver:void
+removeObserver:void
+notifyObservers:void
+refresh:void
Laboratório de Engenharia de Software – PUC-Rio
CDC = 2
CDLOC = 4
NOAconcern = 0
NOOconcern = 1 + 1
LOCconcern = 3 + 4
CBC = 13 (soma)
DIT = 2 (máximo)
NOC = 2 + 1
LCOO = 16 (soma)
VS = 5
NOO = 21 (soma)
NOA = 6 (soma)
LOC = 111 (soma)
13
Exemplo de Métricas
Interesse Sombreado: Papel Observer (Observer)
CDC = 2
C ha ng eS ubj ect
C ha ng eO bs erv er
CDLOC = 4
+main:void
NOAconcern = 0
+addObserver:void
+refresh:void
+removeObserver:void
NOOconcern = 1 + 1
+notifyObservers:void
LOCconcern = 3 + 4
CBC = 13 (soma)
DIT = 2 (máximo)
• O Pque
podemos
dizer
sobre
o
sistema
a partir
oint
S creen
NOC = 2 + 1
dos valores
medidos?
-observers:HashSet
-observers:HashSet
LCOO
= “Observer”
16 (soma)
-name:String
–
E
sobre
o
código
que
implementa
o
papel
+Point
VS = 5
+addObserver:void
+Screen
do padrão
“Observer”?
+removeObserver:void +display:void
NOO = 21 (soma)
+notifyObservers:void +addObserver:void
+removeObserver:void
NOA = 6 (soma)
x:int
+notifyObservers:void
•y:intQual é o raciocínio
em relação aos valores
+refresh:void
LOC = 111 (soma)
color:Color
interface
interface
Ma i n
medidos?
Laboratório de Engenharia de Software – PUC-Rio
14
Regras Heurísticas
R01:
if CDLOC is 2 then MODULAR CONCERN
R02:
if CDLOC is bigger than 2 then (POSSIBLE) TANGLED CONCERN
Concern
R01
Modular
Concern
Laboratório de Engenharia de Software – PUC-Rio
R02
(Possible)
Tangled
Concern
15
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]
Outp utF a ca d e
+printNormal:void
+printFancy:void
+printDecoration:void
R eg ula rS creen
+print:void
+newline:void
Decora ti on
decoration:String
S tring T ra ns form er
+transformToUpper:String
+transformToLower:String
CDLOC = 2
• Pela regra R01, o padrão “Façade” é Modular
Laboratório de Engenharia de Software – PUC-Rio
16
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
(Possible)
Tangled
Concern
R03
Highly
Scattered
Concern
Laboratório de Engenharia de Software – PUC-Rio
R04
Low
Scattered
Concern
17
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
G UIC omp onentC rea tor
Ma i n
-lastFrameLocation:Point
+createComponent:JComponent
Exemplo: Papel Creator
(Factory Method) [HK, 2002]
+main:void
+showFrame:void
CDLOC = 6
CDC / VS = 4 / 4 = 1
title:String
La b el C rea tor
+createComponent:JComponent
title:String
ButtonC rea tor
+createComponent:JComponent
title:String
Laboratório de Engenharia de Software – PUC-Rio
• Pela regra R03:
Papel “Creator” é
High Scattered
18
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
Possible
Highly
R05
Primary
Scattered
Concern
Concern
R06
Low
Scattered
Concern
Laboratório de Engenharia de Software – PUC-Rio
R07
R08
Possible
Secondary
Concern
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
Exemplo: Papel “Observer” (Observer) [HK, 2002]
CDLOC = 4 (Regra 02: Possible Tangled)
CDC / VS = 2 / 5 = 0,4 (Regra 04: Low Scattered)
Component
Screen
Observer
• Pela regra R08:
Laboratório de Engenharia de Software – PUC-Rio
NOAconcern / NOA
NOOconcern / NOO
0,00
0,17
-
1,00
Papel “Observer” é Possible Secondary
20
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
Possible
Primary
Concern
R09
Possible
Secondary
Concern
R10
Laboratório de Engenharia de Software – PUC-Rio
Primary
Concern
Secondary
Concern
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
Exemplo: Papel “Observer” (Observer) [HK, 2002]
CDLOC = 4 (Regra 02: Possible Tangled)
CDC / VS = 2 / 5 = 0,4 (Regra 04: Low Scattered)
Component
NOAconcern / NOA
NOOconcern / NOO
LOCconcern / LOC
0,00
0,17
0,14
-
1,00
1,00
Screen
Observer
Regra R08: Possible Secondary
• Regra R10: Papel “Observer” é Secondary Concern
Laboratório de Engenharia de Software – PUC-Rio
22
R01: if CDLOC is 2 then MODULAR CONCERN
R01
Modular
Concern
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
R02
R04: if CDC / VS of (POSSIBLE) TANGLED CONCERN is not
high then LOW SCATTERED CONCERN
(Possible)
Tangled
Concern
R03
R04
Highly
Scattered
Concern
R05
Low
Scattered
Concern
R06
Possible
Primary
Concern
R07
R08
Possible
Secondary
Concern
R09
Primary
Concern
R05: if (NOAconcern / NOA is high) and (NOOconcern / NOO is
high) for all components of HIGHLY SCATTERED CONCERN
then POSSIBLE PRIMARY CONCERN
R10
Secondary
Concern
Laboratório de Engenharia de Software – PUC-Rio
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
23
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
24
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
25
Trabalhos Relacionados
• 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
Laboratório de Engenharia de Software – PUC-Rio
26
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
27
Bibliografia Principal
[1] Alencar, P. et. al.: A Query-Based Approach for Aspect
Understanding, Measurement and Analysis. Technical Report CS2004-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. 476493.
[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
28
Bibliografia Principal
[8] Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns:
Elements of Reusable Object-Oriented Software. AddisonWesley, (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 MultiAgent 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. 220242.
[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 AspectOriented Software: An Assessment Framework. In Proceedings
of the Brazilian Symposium on Software Engineering, Brazil, (2003),
pp. 19-34.
Laboratório de Engenharia de Software – PUC-Rio
29
Arquitetura da Ferramenta
Laboratório de Engenharia de Software – PUC-Rio
30
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
System
R01
R02
Highly
Coupling
R03
Low
Coupling
R04
R05
R06
Highly Coupling
Highly Coupling
Low Coupling
Low Coupling
Low Cohesion
Highly Cohesion
Low Cohesion
Highly Cohesion
Laboratório de Engenharia de Software – PUC-Rio
31