On the Modularity Assessment of Aspect- Oriented Multi-Agent Systems Product Lines: a Quantitative Study Camila Nunes [email protected]

On the Modularity Assessment of Aspect-Oriented Multi-Agent Systems Product

Lines: a Quantitative Study

Camila Nunes

[email protected]

© LES/PUC-Rio

Summary

• Introduction/Motivation

– Aspect-Oriented Programming (AOP)

• Study Settings

• Modularity Analysis

• Discussions and Lessons Learned

• Related Work

• Final Remarks

© LES/PUC-Rio

Introduction

• Aspect-oriented programming (AOP) techniques to improve the modularization of features in SPLs, object-oriented frameworks, and multi-agent systems

• The increasing complexity of modern applications motivates the use of AOP

© LES/PUC-Rio

Introduction

• Improve separation of concerns

• Improve maintainability and reuse of classes and crosscutting concerns

“Crosscutting Concerns”

OO Solution Aspect-Oriented Solution

Aspect

Classes

JoinPoints

© LES/PUC-Rio

Introduction

• Problem– There are recent research and empirical studies

exploring the use of AOP to modularize features– However, none of them analyzes the impact of

adding agency features in evolution scenarios of a MAS-PL.

– How to deal with the MAS-PL evolution?• Evolution in SPLs requires appropriate mechanisms to

lead with invasive changes. • Implementation of variability mechanisms:

– Conditional Compilation– Aspect-Oriented Programming (AOP)

© LES/PUC-Rio

Introduction

• Our work

– This work presents an empirical study of development and evolution of an MAS-PL

– The aim is to compare the modularity of object-oriented (OO) and aspect-oriented (AO) different implementations of the MAS-PL.

– Our study is based on a suite of modularity attributes and change impact metrics.

© LES/PUC-Rio

Introduction

• Our goal is to answer some questions, such as:

– (1) Which technique is more appropriate to allow superior stability in the implementation of agency features?

– (2) Which technique required less intrusive modifications following the Open-Closed principle?

– (3) Which technique supports the construction of reusable and maintainable MAS?

© LES/PUC-Rio

Summary


– Software Product Lines (SPL)


– Multi-agent Systems Product Line (MAS-PL)

• Study Settings



• Related Work

• Final Remarks

© LES/PUC-Rio

The ExpertCommittee Web based System

• Conference Management System

• Typical web-based application

• Functionalities to support the complete process of the management of conferences and workshops

– Paper submission

– Reviewing processes

• Examples

– EasyChair (http://www.easychair.org/)

– JEMS (https://submissoes.sbc.org.br/)

© LES/PUC-Rio

Generation of the MAS-PL Releases

• First it was implemented the SPL base architecture of the EC.

• A series of change scenarios, adding optional and alternative features in the SPL architecture.

• Seven new releases of the EC MAS-PL were generated

• Each release of our MAS-PL was always implemented in two different versions: – (i) one codified in Java with conditional compilation

– (ii) the other one codified in AspectJ

© LES/PUC-Rio


Releases Description Change Type

R1 ExpertCommittee core

R2 Addition of the Reviewer role. Inclusion of optional feature.

R3 New feature added to include user agents including the author and chair roles. New feature to allow the suggestion of conferences to the authors.

Inclusion of optional feature.

R4 Addition of a Notifier agent to send messages to the system users through email and SMS.

Inclusion of optional and alternative feature.

R5 Addition of the Deadline agent. This agent is responsible for monitoring the conference deadlines.

Inclusion of optional feature.

R6 Addition of a feature that allows the chair to automatically assign papers to reviewers. Extension of the deadline agent to allow reminder deadlines.

Inclusion of alternative feature and extension of deadline monitoring feature.

R7 Addition of a Task agent. Inclusion of optional feature.

© LES/PUC-Rio


• MAS-PL Features Types:

– (i) new conference management features:• typical kind of feature addressed in SPL

– (ii) new autonomous behavior: • Introduction of agents

– (iii) new behaviors and roles for an agent:• Features that have impact inside of agents, internal

variabilities

© LES/PUC-Rio

MAS-PL Object Design

© LES/PUC-Rio


© LES/PUC-Rio


© LES/PUC-Rio

MAS-PL Aspect Oriented Design

© LES/PUC-Rio


© LES/PUC-Rio


© LES/PUC-Rio

The Metrics

Attributes Metrics Definition

Separation of Concerns

Concern Diffusion over Components (CDC)

It counts the number of classes and aspects whose main purpose is to contribute to the implementation of a concern and the number of other classes and aspects that access them.

Concern Diffusion over Operations (CDO)

It counts the number of methods and advices whose main purpose is to contribute to the implementation of a concern and the number of other methods and advices that access them.

Concern Diffusion over LOC (CDLOC) It counts the number of transition points for each concern through the lines of code. Transition points are points in the code where there is a “concern switch”.

InteractionBetweenConcerns

Component-level Interlacing Between Concerns (CIBC)

It counts the number of other concerns with which a given concern shares at least a component.

Size Lines of Code (LOC) It counts the lines of code.

Number of Components (NOC) It counts the number of components.

Number of Operations (NOO) It counts the number of operations of a given component.

© LES/PUC-Rio

The Metrics

Attributes Metric Definition

Coupling Coupling Between Components (CBC)

Counts the number of other classes and aspects to which a class or an aspect is coupled.

Cohesion Lack of Cohesion Operations (LCCO)

Measures the lack of cohesion of a class or an aspect in terms of the amount of method and advice pairs that do not access the same instance variable.

© LES/PUC-Rio

Summary





• Study Settings



• Related Work

• Final Remarks

© LES/PUC-Rio

Separation of Roles and Agents Concerns

• Concern Diffusion over Operations (CDO)

• Concern Diffusion over Lines of Code (CDLOC)

Reviewer

010203040

5060708090

1 2 3 4 5 6 7

Releases

Co

nce

rn D

ifu

sio

n o

ver

LO

C

Java

AspectJ

Reviewer

0

10

20

30

40

50

60

1 2 3 4 5 6 7

Releases

Co

nce

rn D

ifu

sio

n o

ver

Op

erat

ion

s

Java

AspectJ

© LES/PUC-Rio

SoC – Reviewer Feature

• Concern Diffusion over Components (CDC)

Reviewer

0

5

10

15

20

1 2 3 4 5 6 7

Releases

Co

nce

rn D

ifu

sio

n o

ver

Co

mp

on

ents

Java

AspectJ

© LES/PUC-Rio

SoC – User Agents Feature

• Concern Diffusion over Operations (CDO)

User Agents

0

10

20

30

40

50

60

70

80

1 2 3 4 5 6 7

Releases

Co

nce

rn D

ifu

sio

n o

ver

Op

erat

ion

s

Java

AspectJ

© LES/PUC-Rio



User Agents

0

5

10

15

20

25

30

1 2 3 4 5 6 7

Releases

Con

cern

Difu

sion

ove

r C

ompo

nent

s

Java

AspectJ

© LES/PUC-Rio


• Concern Diffusion over Lines of Code (CDLOC)

User Agents

0

10

20

30

40

50

60

1 2 3 4 5 6 7

Releases

Co

nce

rn D

ifu

sio

n o

ver

LO

C

Java

AspectJ

© LES/PUC-Rio

SoC – Notifier Agent


NotifierAgent

0

5

10

15

20

25

1 2 3 4 5 6 7

Releases

Co

nce

rn D

ifu

sio

n o

ver

Co

mp

on

ents

Java

AspectJ

© LES/PUC-Rio

Size Metrics

ExpertCommittee

0

2000

4000

6000

8000

10000

12000

14000

1 2 3 4 5 6 7

Releases

Lin

es o

f C

od

eJava

AspectJ

ExpertCommittee

0

200

400

600

800

1000

1200

1400

1 2 3 4 5 6 7

Releases

Nu

mb

er o

f O

per

atio

ns

Java

AspectJ

© LES/PUC-Rio

Size Metrics

ExpertCommittee

0

50

100

150

200

250

1 2 3 4 5 6 7

Releases

Nu

mb

er o

f C

om

po

nen

ts

Java

AspectJ

© LES/PUC-Rio

Interaction between Concerns

Reviewer

0

2

4

6

8

10

1 2 3 4 5 6 7

Releases

CIB

C Java

AspectJ

User Agents

0

1

2

3

4

5

6

7

8

9

1 2 3 4 5 6 7

Releases

CIB

C Java

AspectJ

© LES/PUC-Rio

Coupling Between Components (CBC)

Coupling Between Components (CBC)

0,0

1,0

2,0

3,0

4,0

5,0

6,0

7,0

8,0

9,0

10,0

1 2 3 4 5 6 7

Releases

Java

AspectJ

© LES/PUC-Rio

Lack of Cohesion over Operations (LCOO)

Lack of Cohesion over Operations (LCOO)

-

0,05

0,10

0,15

0,20

0,25

1 2 3 4 5 6 7

Releases

Java

AspectJ

© LES/PUC-Rio

Change Propagation Metrics

R2 R3 R4 R5 R6 R7

Added Components OO 3 27 11 3 3 26

OA 9 35 20 6 8 34

Changed Components

OO 9 6 8 8 7 13

OA 0 0 0 0 0 0

Added Operations OO 32 103 31 29 20 128

OA 43 112 35 49 27 145

Changed Operations OO 4 2 15 2 2 31

OA 0 0 0 0 0 0

Added Pointcuts OA 5 7 9 1 1 19

Changed Pointcuts OA 0 0 0 0 0 0

Added LOC

OO 418 1134 639 391 249 2203

OA 511 1202 784 470 496 2166

© LES/PUC-Rio

Summary





• Study Settings



• Related Work

• Final Remarks

© LES/PUC-Rio

Discussions and Lessons Learned

• Aspects as “glue” between Roles and Agents:

– several aspects in our MAS-PL worked as a “glue” code.

• Feature Management:

– Some agency features, such as: User Agents and Notifier Agent, caused a high number of new components (classes and aspects) in the AO solution.

– Although the use of aspects increases the number of components in these cases, it was also useful to reduce the tangling and coupling between the concerns/features.

© LES/PUC-Rio


• Code Understanding:

– In our study, it was observed that the AO solution exhibits higher values for all the size metrics (LOC, NOC, and NOO).

– This was a negative finding of the AO implementation

© LES/PUC-Rio


• Recent research has pointed AOP as a good technique for implementation and management of variabilities in SPL.

• The aspect-oriented approach required less modification and extension of the selected MAS

• The implementation of variabilities with AOP also brings another benefit: the capacity of pluging/unpluging aspects from the SPL core implementation.

© LES/PUC-Rio

Summary





• Study Settings



• Related Work

• Final Remarks

© LES/PUC-Rio

Related Work

• Figueiredo, E. et al (2008). Evolving software product lines with aspects: An empirical study on design stability – Empirical study focusing on evolution requirements of

two product-lines.– Analyzes the evolution of product lines in terms of

metrics for modularity, change propagation and feature interaction.

• Apel, S. and Batory, D. (2006). When to use features and aspects?: a case study. – A study comparing the feature-oriented programming

(FOP) and aspect-oriented programming (AOP)

• Kastner, C. et al. (2007). A case study implementing features using aspectj. – Refactoring legacy application into an SPL using aspects

to implement features.

© LES/PUC-Rio

Summary





• Study Settings



• Related Work

• Final Remarks

© LES/PUC-Rio

Final Remarks

• Exploratory study of development and evolution of a MAS-PL

– Traditional web-based system

• Support conference management process

– Incorporation of a series of new agency features

• We compared two different versions of the MAS-PL

implemented using the following technologies: – (i) OO with conditional compilation using the Java

language

– (ii) AO programming using the AspectJ language.

© LES/PUC-Rio

Final Remarks

• AO implementation exhibits a better separation of concerns/features (CDLOC metric) and interaction between concerns, but in terms of the CDC and CDO metrics the AO implementation presented superior

values.

• The NOC, NOO and LOC increased in the AO implementation, bringing complexity to manage the

new aspects that modularize some agency features.

© LES/PUC-Rio

Final Remarks

• Separation of Concerns

– Aspects (and classes) encapsulate the agency features of interest

• Reusability

– Reuse of Aspects and Classes

• Maintainability

– Obliviousness

– Quantification

© LES/PUC-Rio

Questions?

Documents

On the Modularity Assessment of Aspect- Oriented Multi-Agent Systems Product Lines: a Quantitative Study Camila Nunes [email protected]