An Aspect Oriented Framework for Flexible

Design Pattern-based Development

Mario L. Bernardi

, Marta Cimitile

and Giuseppe A. Di Lucca

Department of Engineering, University of Sannio, Benevento, Italy

Unitelma Sapienza University, Rome, Italy

Keywords:

Software Engineering, Design Patterns, Aspect Oriented Software Development, Software Metrics.

Abstract:

The implementation of a Design Pattern (DP) may be affected by some problems due to typical deﬁciencies

of Object Oriented languages that may worsen the modularity of a software system, and thus its comprehensi-

bility, maintainability, and testability. Aspect Oriented Programming allows to implement DPs by its powerful

quantiﬁcation constructs that can handle better modularity and composition, helping to overcome some of

the OO design trade-offs in current DP implementations. In Model Driven Development system models, de-

ﬁned by a Design Speciﬁcation Language (DSL), are transformed between different levels of abstraction to

get system implementation. In this paper we propose an Aspect Oriented DSL-based framework to specify

and to apply, declaratively, Design Patterns to the system classes. The main aim driving the deﬁnition of the

proposed framework is to improve the modularity, the internal code quality, and the ﬂexibility, by allowing

software designers to specify DP models with an extensive modiﬁability thus reducing the impact of changes

related to DP adoption.

1 INTRODUCTION

The way a DP is usually implemented may heavily

impact the overall system structure, and in particular

it impacts the modularity of the system, thus affecting

its comprehensibility, maintainability, testability too.

This is mainly due to some typical deﬁciencies of Ob-

ject Oriented languages that may worsen the overall

modularity of a software system. Moreover, the inva-

sive nature of DP implementations may make it hard

to distinguish between the code of DP instances and

the code of the ’base’ system. In (Hannemann and

Kiczales, 2002; Nordberg, 2002) the authors showed

how several DPs from GoF catalog (Gamma et al.,

1995) introduce crosscutting that OO abstractions are

often unable to well modularize.

Aspect Oriented Programming (AOP) and As-

pect Oriented Software development (AOSD) (Han-

nemann and Kiczales, 2001) improves the way soft-

ware is structured, decomposed and implemented by

providing means for modularizing crosscutting con-

cerns (CCCs). CCCs are encapsulated into a new

kind of module, the Aspect, and powerful weav-

ing mechanisms support their subsequent composi-

tion with other software artifacts. The AOP con-

structs can help to overcome some of the OO design

trade-offs and indirection characterizing current DP

implementations. Composition transparency, option-

ality, and unpluggability are example of modularity

properties that can be enforced by AOP implementa-

tion of DPs and that have to be considered when as-

sessing the quality of AO designs (Hannemann and

Kiczales, 2002; Hachani and Bardou, 2003). Model-

Driven Software Development (MDSD) improves the

way software is developed by capturing key features

of a system in models which are developed and re-

ﬁned as the system is developed. During the system’s

life-cycle, models are synchronized, combined, and

transformed between different levels of abstraction.

Thus models have to be formal. Every model is an in-

stance of a meta model. The meta model deﬁnes the

Domain Speciﬁc Language (DSL) describing the ab-

stract syntax to be used to instantiate the meta model

when generating a model. While AOSD and MDSD

are different in many ways they both help the devel-

oper to reason about one concern at a time. From this

point of view AOSD and MDSD complement each

other and can be used together to improve both the

overall modularity of development of artifacts at de-

sign models down to source code, and the structure

and behaviour of run-time objects .

In this paper we exploit AOSD and MDSD fea-

528

L. Bernardi M., Cimitile M. and A. Di Lucca G..

An Aspect Oriented Framework for Flexible Design Pattern-based Development.

DOI: 10.5220/0004510305280535

In Proceedings of the 8th International Joint Conference on Software Technologies (ICSOFT-PT-2013), pages 528-535

ISBN: 978-989-8565-68-6

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

tures to propose an Aspect Oriented DSL-based

framework used to specify and to implement DPs

declaratively. The main goals behind the framework

design are: (i) modularity, to improve code internal

quality avoiding bad duplicated code, (ii) dynamic be-

haviour, to improve ﬂexibility of adopting different

pattern variants with limited impact on system source

code; and (iii) obliviousness, to increase internal co-

hesion by leaving concrete system classes as much

decoupled as possible from design pattern protocols,

abstract classes and interfaces.

The framework is centered on a generation step

that, starting from a model written by the proposed

DSL, emits aspects dynamically applying idioms and

DPs on system classes with reduced (and often no)

impact on them. The DSL code is parsed by a

template-language engine that generates Java and As-

pectJ resources to implement ﬂexible and modular

DPs involving concrete classes of the OO base sys-

tem. The overall design is more modular than a pure

Object Oriented one and beneﬁts from interesting dy-

namic properties like optionality, pluggability (the

ability to enable/disable o change DP involvement at

runtime). Moreover the performance hit, due to dy-

namic aspect introspection, is greatly reduced.

To validate the approach, a prototype framework

was built on top of the Eclipse Modeling tools (us-

ing Xpand as Model to Text - M2T - transforma-

tion engine) and AspectJ as AOP language. Quanti-

tative assessment is done comparing the AO versions

of the applied DPs against reference Object Oriented

DPs’ implementations. The comparison is performed

by means of a selected set of AOP-aware internal-

quality metrics. A qualitative discussion highlight-

ing the properties of the generative approach is also

provided. This allows to validate the results of apply-

ing the framework in terms of: (i) DSL effectiveness

and ﬂexibility to express (and change) design choices,

and (ii) internal quality of the resulting system source

code. The remaining of the paper is structured as fol-

lows. Section 2 discusses some related work. Sec-

tions 3 and 4 present and discuss the proposed DSL

for Design Pattern implementation and the architec-

ture of the AspectJ-based framework adopting it. The

section 5 reports a description of the the case study

and discusses the quantitative evalutation of the pro-

posed framework using an adequate set of AOP-aware

source code metrics. Conclusive remarks and future

works are ﬁnally presented in section 6.

2 RELATED WORK

In (Hannemann and Kiczales, 2002) authors provide

a study on crosscutting introduced by design patterns

adoption providing AOP-based implementation that

have inﬂuenced requirements for our DSL deﬁnition

and design goals.

The topic has largely discussed in the last years in

literature and several approaches to represent, trans-

form and apply design patterns were proposed (Alen-

car et al., 1997; Elaasar et al., 2006). These ap-

proaches are mainly interested in applying a code

generation approach to apply design patterns to con-

crete cases using pattern languages or models.

In (El Boussaidi and Mili, 2007) an explicit rep-

resentation of a pattern as well as the transforma-

tion inherent to its application is proposed. (Baca,

2011) shows how intrinsic aspect-oriented design pat-

terns can be used to implement object-oriented de-

sign patterns in order to achieve better composability

compared to both original implementations of object-

oriented design patterns and their aspect-oriented re

implementations. In (Zdun, 2004) a pattern language

is presented for tracing and manipulating software

structures and dependencies, with an explanation of

different, existing aspect composition frameworks as

sequences through this pattern language. Alternative

designs, common design trade-offs, and design de-

cisions for implementing aspect composition frame-

works, are also evaluated. (Soundarajan and Hall-

strom, 2004) discusses the software reuse in the de-

sign and implementation for aspect oriented design

language in general and derives the speciﬁc require-

ments for the AOSDDL (Aspect Oriented Software

Development Design Language) design language ar-

chitecture by examining the Aspect J extensions for

a distributed computing environment. All these ap-

proaches, are usually focused to apply DPs to the

existing design (by models transformations) or code

(by applying code generation). Our DSL approach

resulted from the analysis conducted on crosscutting

introduced by DPs in Object Oriented code proposed

in previous works (Arpaia et al., 2010; Bernardi et al.,

2005; Bernardi et al., 2012) . The main difference of

our approach w.r.t. cited approaches is the deﬁnition

of a dynamic DSL involving existing source code in

pattern logic in a completely dynamic fashion. Thus

instead of modifying or generating code, our engine

generate aspects that inject pattern logic at run-time,

keeping system classes oblivious. For this reason, the

proposed approach can be more ﬂexible, less inva-

sive and requires less maintenance effort since only

aspects performs interception and run-time bytecode

manipulation to apply pattern logic.

AnAspectOrientedFrameworkforFlexibleDesignPattern-basedDevelopment

529

3 THE PATTERNS

SPECIFICATION LANGUAGE

The framework is based on a meta-model used to de-

ﬁne a DSL suitable to map design patterns (along with

their roles, variants and default implementations)onto

system classes. A DSL instance is structured as an

(ordered) sequence of named Concern elements. Each

Concern has in turn an inner structure specifying its

contributions to the base system:

• provided roles (i.e. interfaces along with a con-

crete implementation)

• injection of built-in roles (in particular DP roles)

into existing types (including hierarchies)

• aggregation/composition rules among existing

classes or interfaces

• injection of behaviour into (and interception at

run-time of) existing classes

The DSL is made up of two main parts: (i) a

language part (Java in the current prototype) allow-

ing the representation of code elements (including

generic types, blocks, statements, expressions and ex-

ceptions); (ii) a second part introducing the main con-

cepts of the DSL language (concern, role deﬁnition

and role implementation) and the constructs to per-

form dynamic interception of a wide range of events

(used to involve concrete classes in DP collaboration

at run-time). The complete Java metamodel contains

113 meta-classes representing the elements, and the

relationships among them, of a Java software system

according to the abstract syntax of the Java language

speciﬁcation as speciﬁed in (Gosling et al., 1996) The

description of this part of the model is out of the scope

of this paper; it has however a key role since it is used

whenever referencing or introducing new source code

elements.

The Figure 1 shows the core excerpt of the second

part of the DSL meta-model. This part describes the

overall structure of the DSL and focuses on the main

concepts used to implement idioms and design pat-

terns (leaving base system classes oblivious and de-

coupled from pattern logic). For each idiom or DP,

the frameworkperforms a mix of injection, alterations

and introductions of the system classes. We describe

the most important ones in the remaining of the sec-

tion by means of small code examples written in the

proposed DSL.

3.1 The Concern Element

The crosscutting model represented by the proposed

DSL can be seen as the weaving of an ordered se-

quence of Concerns: each Concern can be seen as a

layer containing only the logic that is related to its

goals and responsibilities. Concerns are merged with

the base system (and to other layers) using AOP injec-

tion and interception features. The ModelRoot (that

is the root element of any DSL instance) contains an

ordered list of Concerns: this order can be changed

using the composition order statement like in:

order I de nt i f i c at i on , ∗

concern F i gu r e s Li st e ni n g { . . .

concern I de n t i f i c a t i on { . . .

In this case two concerns (FiguresListening and Iden-

tiﬁcation) are deﬁned; the ordering is ﬁxed so that

Identiﬁcation is always merged before any other con-

cerns. This is important when some alteration to

the base system are not optional: injected members

needed by all other concerns (or even by the base sys-

tem itself).

3.2 Deﬁne, Assign and Implement

Role(s) statements

These statements are the groundings for all other con-

structs that follows. They allow developer to intro-

duce a role in the system (using deﬁne role) and to as-

sign them to existing interfaces and classes (using as-

sign roles). Let us consider the following deﬁne role

statements:

concern I de n t i f i c a t i on {

def in e r o l e I d e n t i f i a b l e {

void setUUID (UUID u ) ;

UUID getUUID ( ) ;

}

def in e r o l e Named {

void setName ( S t ri n g u ) ;

St r i n g getName ( ) ;

}

assign r ol e s Id e n ti fi ab l e , Named to Figure , View ;

. . .

This fragment introduces the roles Identiﬁable and

Named into two existing roles (Figure and View). As

a consequence all the classes inheriting or implement-

ing them will be forced to provide this additional be-

haviour (the UUIDs and Name ﬁelds along with get-

ters/setters in the example). This is useful only if we

have a means to inject (or not) such behaviour in a

modular way: i.e. providing Identiﬁcation concern

default implementation for classes of the base system

but having the ﬂexibility to specify different imple-

mentations for different classes. This is exactly what

the implement role statement does. It allows to spec-

ify the implementation of a role that must be sup-

plied for a set of existing classes. The syntax is based

upon the InjectionRule nested element that must be

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

530

DSL Core Language

MethodDeclaration

BodyDeclaration

ReferenceType

Interface

Class

CrosscuttingDeclaration

CompositionOrder

CompositionImplementRole

InjectionRule

FactoryMethod

SharedMethod

Memento

SharedField

ObjectProxy

ClassProxy

Singleton

ImplementRoles

AssignRoles

-srcPath

-genPath

-uri

-lastGenereation

-ModelUUID

-SystemName

ModelRoot

DefineRole

-SimpleName

Concern

containment

+contained

+container

inheritance

0..*

assignedRoles

0..*

targetRoles

0..*

Figure 1: The DSL Core Meta-Model : an excerpt of the main stucture and elements.

followed by the source code of the role implementa-

tion. This can be an existing concrete type (in this

case partial override of the concrete type is allowed)

or a deﬁnition from scratch. In both cases the pro-

vided members should create no conﬂict with target

types members (including the ones that are weaved

from other concern elements). For instance the exam-

ple:

implement ro l e I d e n t i fi a b l e

on Abs t ract F igu re , DefaultView {

i n j e c t {

UUID

uuid ;

public UUID getUUID ( ) {

return

uuid ;

}

public void setUUID (UUID u ) {

uuid =u ;

}

uses the inject statement to provide an implementa-

tion (deﬁned from scratch) for the Identiﬁable role

seen before and apply it to the AbstractFigure and

DefaultView (existing) system classes. These classes

are by no means aware that they are “Identiﬁable”

by UUID and have no imperative dependencies on

Identiﬁable interface (since in this trivial example

the Identiﬁcation concern is completely orthogonal).

This however is not the “real world” common case.

Studies that tries to quantify the crosscutting present

in real systems reveal that most of the concerns are

crosscutting and hence they depend on each other.

To express such interleaving the implement role state-

ment allows the deﬁnition of shared ﬁelds and meth-

ods.

3.3 Shared Fields and Methods

When implementing a role for a set of concrete

classes one or more methods could be provided in

order to link, in a modular way, the concrete classes

logic to the new provided behaviour. An example will

make this more clear. Referring to the previous DSL

snippet, the UUID could be used to build the Abstract-

Figure name. In this case a shared method (the same

concept applies to shared ﬁelds) can be used. It should

be nested in the role implementation statement as fol-

lows:

implement r o l e I d e n t i f i a b l e

AnAspectOrientedFrameworkforFlexibleDesignPattern-basedDevelopment

531

on A b str a c tFi gur e + {

i n j e c t {

UUID

uuid ;

public UUID getUUID ( ) . . .

public void setUUID (UUID u ) . . .

}

St r i n g getName ( ) {

return super . getName ( ) +

”

w i t h UUID : ”+ uuid . t o S t r i n g ( ) ;

}

This excerpt injects the getName(void) method in the

complete hierarchy rooted in the AbstractFigure class

as a part of Identiﬁable concern. This means that

Identiﬁable role depends on Named role. They are

both provided (in this simple case) by the same Iden-

tiﬁcation concern but this is not required. Moreover

different method can be speciﬁed for different sub-

classes of AbstractFigure thus reusing the same be-

haviour as much as possible without loosing ﬂexibil-

ity.

3.4 Composite Example

Using the statements seen so far, we could easily im-

plement a modular and pluggable Composite imple-

mentation. Consider the following excerpts in which

a Composite DP is applied to all subclasses of Figure:

\renewcommand{\ b a s e li n es t re tc h }{ 0.96}

concern FigureComposite {

assign r ol e Component to Figu re ;

assign r ol e Figure to system cla ss Ab s tra c t Fi g ure ;

implement r o l e Component on Figure + {

i n j e c t ConcreteComponent ;

}

implement r o l e Component on

A l t e r n a t i v e F i g u r e {

i n j e c t Alt ern ative Concrete Co mpo nent ;

}

assign r ol e Composite to PanelFigure , GroupFigure ,

ZOrderedGroupFigure ;

implement r o l e Composite on PanelFigure , GroupFigure ,

ZOrderedGroupFigure {

i n j e c t ConcreteComposite {

@Override

boolean h a s C hil d re n ( void ) {

return true ;

}

Image ( Pane l | Group ) Figure . getR a s t er (){

Image i = Image . bu ild ( ) ;

for ( Component c : ge tChi ldr e n ( ) ) {

i . merge ( ( Figure ) c ) . ge t R aste r ( ) ) ;

}

return i ;

}

Some ﬁgures are leafs and hence Component

role is assigned to them. Conversely to ﬁgures that

may have internal sub-ﬁgures (like GroupFigure or

ZOrderedGroupFigure) a Composite role is assigned.

Referring to the Component role, it’s interesting to

observe that the class ConcreteComponent is used as

the default Component implementation on all Figure

hierarchy (using the plus notation). However for Al-

terativeFigure, that needs a different kind of imple-

mentation, the Component role is provided by another

class (namely AlternativeConcreteComponent). This

kind of ﬂexibility allows to inject a reasonable de-

fault implementation for a complete hierarchy and to

change default behaviour when requested. The Com-

posite case uses both shared methods and override in-

jection. The method hasChildren(...) is overridden

to return always true whereas the method getRaster()

(deﬁned on Figure interface) is implemented by wrap-

ping the default one. Since no @Runtime annotation

is provided such wrapping is static (the method are

injected at compile time by the generated aspects).

When using @Runtime the generated aspects uses in-

terception to obtain the same results. There is a trade-

off between time and space since the dynamic ver-

sion produces smaller objects but there are less opti-

mization chances and it is, usually, slower. The in-

jected getRaster() uses the getChildren() method (of

the ConcreteComposite just injected) to obtain all the

sub images returning an image containing all of them.

3.5 Other Statements

Using the statements already discussed all DPs have

been implemented and included, as built-in in the

framework(and as additional DSL statements in some

cases). Patterns requiring collaborations between sev-

eral roles (like the Observer, Builder etc.) can be

easily constructed using the statements and the prede-

ﬁned (but extensible) interfaces/classes provided with

the framework.

Interesting cases are patterns based on single role

(like Singleton, Memento, or Factory Method) for

which a concise DSL statement is implemented. For

instance consider the following excerpt:

concern FigureMemento {

memento on Figure +

for { t i t l e , c e n t e r } ;

memento on C i r c l e F i g u r e

for { t i t l e , radius , c e n t e r } ;

}

This example injects the logic that saves/restores

the Figure state into an opaque object. The frame-

work, when the getMemento() is called, dinami-

cally serializes the listed ﬁelds of the target object

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

532

Figure 2: Transactional Commands: Cloned LOC Ratio comparison.

and write them into a memento object. When set-

Memento(Memento m) is called the state ﬁelds are

restored. This statements uses static role deﬁnition

and implementation to inject memento interface into

target classes.

4 THE DESIGN PATTERNS

MODELING FRAMEWORK

(DPMF)

In our prototype framework, aspects are generated

in order to inject members implementing the pattern

logic into marker interfaces nested in the aspect it-

self. The pattern roles are often associated to concrete

classes by means of the declare parent construct using

such marker interfaces. Each Concern element can be

seen as the intermediate mapping layer of a three lay-

ers structure in which concrete system classes are in-

volved in pattern relationships by an aspect that acts

as “concern mapper”. This aspect layer is responsi-

ble of implementing a modular mapping of DPs and

idioms to concrete classes intercepting object creation

and enforcing the observer/observableprotocol for in-

stances that need it. Concrete classes, belonging to

the ”base system” layer, are oblivious of being in-

volved in a pattern and the pattern relationships can be

removed simply acting on the mapping layer. Com-

monalities among different pattern instances can be

factorized in the pattern logic concern while multiple

relationships can be easily resolved in the mapping

layer concern by associating two pattern aspects to the

same concrete class.

5 CASE STUDY OVERVIEW

To validate and assess the approach, the same sys-

tem was designed and developed by two different ex-

pert groups; one group adopted the proposed frame-

work whereas the other used a classic design patterns

based development. The system, a high performance

REST server providing dynamic content for a fam-

ily of mobile applications, is written in Java and is

comprised of 24824 LOC , 364 classes and 28 inter-

faces. The original Java system was pattern-based.

The core component is a Command-based executor

initialized by means of a Command Factory. Execu-

tors are mapped to different endpoints into industrial

application servers (Jetty in this case). The Server is

a Singleton and is responsible of managing an execu-

tor for each endpoint. We performed a metric-based

comparison between the old pure-java system and

the re-engineered version using the proposed frame-

work. The restructuring was performed by removing

patterns adoption from all system classes using the

declarative DSL to implement them.

The restructuring of the Command hierarchy was

the largest and most difﬁcult one. The command pat-

tern was implemented using a role assignment and

implementation. This generated a marker interface

inside an abstract aspect to remove indirection intro-

duced by the ”Command” role. Looking at the sys-

tem code, we found that the original design failed to

effectively modularize several concerns. Command

and Composite pattern were tangled in an explicit

way, making difﬁcult to change one aspect without

impacting the other ones. The refactored system en-

forces a clean separation between the two providing a

default role implementation for the all simple Com-

mands and a MacroCommand role implementation

that, transparently, aggregates sequence of plain com-

mands with no impact on the Command pattern struc-

AnAspectOrientedFrameworkforFlexibleDesignPattern-basedDevelopment

533

Figure 3: Transactional Commands: DOF comparison.

ture itself. Using shared methods the composite op-

erations were, in some cases, overridden to provide

custom behaviour (like in the case of Transactional-

MacroCommand that needed a @Runtime intercep-

tion to wrap the sequence execution in a transactional

context). This was a big improvement over the orig-

inal design in which transactions were not modular-

ized. Moreover in each command there were authen-

tication, logging, tracing and business logic concerns

with high level of scattering and tangling.

5.1 Quantitative Assessment

The software quality attribute of modularity was as-

sessed for both the AOP and OOP versions by evalu-

ating (i) the percentage of lines of source code related

to fault detection logic present in each module with

respect to the total Lines of Code (LOC) of the same

module, and (ii) the Degree of Scattering (DOS) and

Degree of Focus (DOF) metrics (Eaddy et al., 2007),

for each module and concern. This analysis provides

quantitative information about (i) size and dimension

; (ii) cohesion and coupling and (iii) crosscutting con-

cerns presence and distribution. The DPMF-based

software quality was evaluated in comparison with the

corresponding OOP version.

5.2 AOP Metrics Results

Results are highlighted in Figures 2 and 3. In partic-

ular, in Figure 2 the percentage LOC (%LOC) of the

Transactional concern all over the Command are com-

pared for both AOP and OOP versions. In the ﬁgure,

the ratio of the cloned LOCs in the OOP implemen-

tation, completely removed in the AOP version, is re-

ported. Of course, the cloned code makes worst the

maintainability and increases the probability of intro-

ducing bugs in the code.

In Figure 4, the level of DOS (a) and DOF (b) for

each Command module with respect to Base System

Figure 4: Transactional Commands: DOS comparison.

and Transactional concerns is reported. The results

show a radically increased modularity for the AOP

version, because each Command module is much

more focused with respect to the OOP version. More-

over, the Transactional concern is highly scattered in

the OOP version (high values of DOS), while it is very

focused in the AOP implementation (this is veriﬁed by

the low values obtained for DOS).

5.3 Performance Evaluation

The case study was aimed also at verifying experi-

mentally that the AOP-based generative architecture

would not have a negative impact on run-time perfor-

mance of the overall system (due to aspect runtime in-

terception overhead). With this aim, the AOP system

was instrumented in order to gather execution times

of the aspect overheads. The main attention was paid

to evaluate the overheads added by AOP interception

mechanism to the injected pattern logic time in or-

der to assess the effectiveness of the AOP architec-

ture, i.e. that the AOP response times are not worst

than the OOP version. The above described analy-

sis was carried out by running the two versions of

the software in the same conditions. The worst av-

erage times in several different categories of pointcut

expressions related to Transactional Macro command

and that were automatically generated by DSL state-

ments (i.e. object creation/destruction, interception of

pattern operations) were selected, and the time spent

ICSOFT2013-8thInternationalJointConferenceonSoftwareTechnologies

534

in the aspect runtime to jump to pattern logic routines

were collected.

Times needed to handle creation/destruction of

object are usually greater than those required to in-

tercept operations. Command Factories must be set

up for Command executors to being created and op-

erative. This requires more time than the other kind

of pointcuts expressions, that have only to capture

the context of an operation, issuing error or execut-

ing business logic if necessary.

In pointcut expressions related to Command de-

sign pattern operations the worst overheads due to

aspect interception mechanism are always less than

1.5% of the pattern collaboration times. Therefore,

the suitability of performance overhead was assessed,

where all the timing constraints were satisﬁed ﬂatly.

6 CONCLUSIONS AND FUTURE

WORKS

An Aspect Oriented DSL-based framework to spec-

ify and to apply, declaratively, Design Patterns to

the system classes has been proposed in this paper.

AOSD and MDSD features are exploited to improve

the modularity, the internal code quality, and the ﬂexi-

bility of DPs. The framework allows software design-

ers to specify DP models with a more extensive modi-

ﬁability thus limiting the impact of changes, related to

DP adoption, on the code of the base system. DPs are

speciﬁed by a DSL based on a meta-model where a

DP is seen and structured as an (ordered) sequence of

named Concern elements. A prototype of the frame-

work was used in a case study to assess its effective-

ness and efﬁciency. The results from the case study

showed that the AOP version of DPs dramatically im-

proved the modularity of the system with respect to

the ’traditional’ OO version. Future work will con-

sider improvements of the prototype framework and

DSL.

REFERENCES

Gamma, E., Helm, R., Johnson, R., Vlissides, J., ’Design

Patterns: Elements of Reusable Object-Oriented Soft-

ware’, Addison-Wesley (1995).

Hannemann, J., Kiczales, G., ’Design Patterns Implementa-

tion in Java and AspectJ’, Proc. of Object Oriented

Programming Systems Languages and Applications

2002 (OOPSLA ’02).

Hachani, O. , Bardou D., ’On Aspect-Oriented Technology

and Object-Oriented Design Patterns’ , Proc. of Eu-

ropean Conference on Object Oriented Programming

2003 (ECOOP 2003).

Nordberg Martin E., ’Aspect Oriented Indirection - Beyond

Object Oriented Design Patterns’ , Proc. of Workshop.

Beyond Design: Patterns (mis)used, Proc. of Object

Oriented Programming Systems Languages and Ap-

plications 2002 (OOPSLA ’02).

AspectJ web site - http://www.eclipse.org/aspectj

Hannemann, J., Kiczales, G.,’Overcoming the Prevalent

Decomposition of Legacy Code’, Workshop on Ad-

vanced Separation of Concerns at the International

Conference on Software Engineering 2001 (ICSE’01).

Eaddy, M., Aho,A , Gail C. Murphy., ’Identifying, Assign-

ing, and Quantifying Crosscutting Concerns’, Proc.

of the First International Workshop on Assessment

of Contemporary Modularization Techniques (ACoM

’07), IEEE Computer Society, Washington, 2007.

Arpaia, P., Bernardi, M.L., Di Lucca, G., Inglese, V.,

Spiezia, G.,‘An Aspect-Oriented Programming-based

approach to software development for fault detection

in measurement systems’, Comput. Stand. Interfaces

32, 2010.

El Boussaidi, G., Mili, H. , ‘A model-driven framework

for representing and applying design patterns’, Proc.

of the 31st Annual International Computer Software

and Applications Conference (COMPSAC ’07), Vol.

1. IEEE Computer Society, Washington, DC, USA,

2007.

Alencar, P.S.C., Cowan, D.D., Dong, J., Lucena, C.J.P.,

‘A transformational Process-Based Formal Approach

to Object-Oriented Design’, Formal Methods Europe,

1997

Elaasar, M., Briand, L.C., Labiche, Y., ‘A metamodeling

approach to pattern speciﬁcation’, In Proc. of the 9th

international conference on Model Driven Engineer-

ing Languages and Systems (MoDELS’06), Springer-

Verlag, Berlin, Heidelberg, 484-498, 2006.

Baca, P. Vranic, V., ‘Replacing Object-Oriented Design Pat-

terns with Intrinsic Aspect-Oriented Design Patterns’,

Proc. of the 2nd Eastern European Regional Confer-

ence on theEngineering of Computer Based Systems

(ECBS-EERC), pp.19,26, 5-6 Sept. 2011.

Zdun, U., ‘Pattern language for the design of aspect lan-

guages and aspect composition frameworks’, Soft-

ware, IEE Proc. , vol.151, no.2, pp.67,83, 5 April

2004.

Soundarajan, N., Hallstrom, J.O., ‘Responsibilities and re-

wards: specifying design patterns’, Proc. of 26th In-

ternational Conference on Software Engineering 2004

(ICSE 2004).

Gosling, J., Joy, B., Steele, G.L., ‘The Java Language Spec-

iﬁcation (1st ed.)’, Addison-Wesley Longman Pub-

lishing Co., Inc., Boston, MA, USA, 1996.

Bernardi, M.L., Di Lucca, G.A., ‘Improving Design Pattern

Quality Using Aspect Orientation’, Proc. of the 13th

IEEE International Workshop on Software Technol-

ogy and Engineering Practice, 2005.

Bernardi, M.L., Cimitile, M., Maggi, F. M., ‘Model Driven

Development of Process-centric Web Applications’,

Proc. of the 7th International Conference on Software

Paradigm Trends 2012 (ICSOFT 2012).

AnAspectOrientedFrameworkforFlexibleDesignPattern-basedDevelopment

535