Reducing Static Dependences Exploiting a Declarative Design Patterns

Framework

Mario Luca Bernardi

and Marta Cimitile

Giustino Fortunato University, Benevento, Italy

Unitelma Sapienza University, Rome, Italy

Keywords:

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

Abstract:

Object Oriented Design Patterns (DPs) are recurring solutions to common problems in software design aiming

to improve code reusability, maintainability and comprehensibility. Despite such advantages, the adoption of

DPs causes the presence of crosscutting code increasing, signiﬁcantly, the code duplication and the dependen-

cies between systems. The main idea of this research is that code crosscutting can be reduced by the integration

of Model Driven Development (MDD) techniques with Aspect Oriented Programming (AOP). According to

this, an approach based on a Domain Speciﬁcation Language (DSL) to to deﬁne declaratively the structure of

DPs and their adoption on classes to declarative, is proposed. The approach aims to support aspects deriva-

tion to compose, at run time, AOP-based version of the speciﬁed DPs. The approach has been applied in

a case study where the developed supporting framework was used in a concrete refactoring scenario, and a

subsequent maintenance task. The results from the case study are presented and discussed.

1 INTRODUCTION

DPs are general repeatable solutions to recurring

problems of software implementation improving ef-

fectiveness and efﬁciency in software development.

Despite such advantages, the usage of DPs have

also some disadvantages like an increasing number

of static dependencies among components, an higher

code crosscutting (this should introduce some defects

in the system) and in some case greater code duplica-

tion (Hannemann and Kiczales, 2002). More in gen-

eral, the adoption of multiple DPs may have an im-

pact on the system modularity affecting its maintain-

ability, comprehensibility and testability (Hannemann

and Kiczales, 2002; Bernardi et al., 2016). Aspect-

Oriented Software Development (AOSD) is a soft-

ware development technology that achieves to im-

prove the modularity of the developed software (Han-

nemann, 2001) giving more emphasis to the separa-

tion of crosscutting concerns (CCs). Consequently,

AOSD represents a valid solution to reducing cross-

cutting resulting from DPs adoption. It performs

an advanced separation of concerns and encapsulates

CCs in separate modules, called aspects. Aspects are

composed with other software artifacts through pow-

erful weaving mechanisms enforcing transparency,

optionality, and unpluggability modularity (Hanne-

mann and Kiczales, 2002). Moreover, software de-

velopment can be also improved by the adoption of

Model Driven techniques achieving to increase the

overall system modularity of design models, source

code, structure and behaviour of run-time objects

(Bernardi et al., 2013a). Model Driven Software De-

velopment (MDSD) models all the relevant system

knowledge and the obtained models are used in for-

mal transformations to produce all needed artifacts

(i.e., source code and documentation). These mod-

els are also synchronized, combined, and transformed

across different levels of abstraction introducing some

meta models that characterize a set of models as their

instances and are instantiated using a DSL to de-

scribe their abstract syntax and to generate a model.

This paper proposes an approach based on a MDSD

techniques and an Aspect Oriented DSL-based frame-

work to deﬁne declaratively the structure of DPs im-

proving modularity, dynamic behaviour and oblivi-

ousness. Moreover, the proposed approach allows to

improve ﬂexibility permitting to adopt different pat-

tern variants with limited impact on system source

code and achieves a greater internal cohesion leav-

ing concrete system classes as decoupled as possible

from the components of the DPs code. Another ad-

vantage of the proposed approach is that it is com-

pletely declarative. This permits to apply any change

154

Bernardi, M. and Cimitile, M.

Reducing Static Dependences Exploiting a Declarative Design Patterns Framework.

DOI: 10.5220/0006009401540160

In Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) - Volume 2: ICSOFT-PT, pages 154-160

ISBN: 978-989-758-194-6

to the DP implementations and their corresponding

concrete classes changing only the DSL speciﬁca-

tions without any direct impact on the system source

code. The approach was implemented using a frame-

work, called Declarative Design Pattern Framework

(DDPF), built on the Eclipse Modeling tools using

Xpand as Model to Text (M2T) transformation en-

gine and AspectJ as AOP language. The generation

step is performed starting from a model written by

the DSL and dynamically generates aspects applying

idioms and DPs on system classes with null (or very

reduced) impact on them. A template-language en-

gine is used to parse the DSL DSL code generating

some Java and AspectJ resources to implement ﬂexi-

ble and modular DPs using the concrete classes of the

system. To validate the effectiveness of the proposed

approach a real world system, the Korsakow editor

system, is refactored using DDPF and both DDPF and

OOP versions are analyzed using modualrity metrics

(DOS and DOF deﬁned in (Eaddy et al., 2007)). The

comparison was performed evaluating the quality of

modularization and the impact of required changes on

system classes involving DPs. This in order to as-

sess the the framework adoption in terms of: (i) DSL

effectiveness to express (and change at run-time) de-

sign choices, and (ii) internal structure quality of the

resulting system source code.

The remaining of the paper is structured as fol-

lows. Section 2 reports some related work. Section 3

presents and discusses the proposed approach and the

architecture of the AspectJ-based framework adopt-

ing it. The section 4 reports a description of the the

case study and discusses the quantitative evaluation

of the proposed framework using an adequate set of

AOP-aware source code metrics. Conclusive remarks

and future works are ﬁnally presented in section 5.

2 RELATED WORK

Several DPs description languages and DPs imple-

mentation approaches are proposed. In (Eden, 2001),

a formal language for DPs representation is reported.

It allows the designer to reﬁne and customize the

descriptions of canonical DPs or to deﬁne new DPs

from scratch. Another pattern language is also pro-

posed in (Zdun, 2004). It allows to trace and manipu-

late software components and their dependencies. In

(Elaasar et al., 2006), the DPs are applied to concrete

classes using pattern languages or models. Moreover,

in (Boussaidi and Mili, 2007) authors propose an ex-

plicit DPs representation as well as the transformation

embodied in their application.

Several studies are also focused on the adoption

of aspect oriented techniques to implement object-

oriented DPs: in (Baca and Vranic, 2011) intrin-

sic aspect-oriented DPs are used to improve com-

posability with respect to the original implementa-

tions of object-oriented DPs and their aspect-oriented

re-implementations. In (Soundarajan and Hallstrom,

2004), aspect oriented design language is used to sup-

port software reuse deriving the speciﬁc requirements

for the Aspect Oriented Software Development De-

sign Language architecture by examining the AspectJ

extensions for a distributed computing environment.

Respect to the above discussed approaches (that

apply DPs to the existing design or code), in this

paper we propose a DSL approach aiming to re-

duce crosscutting introduced by DPs in Object Ori-

ented code (Bernardi et al., 2013c; Bernardi et al.,

2013b; Bernardi et al., 2014). Moreover, an approach

for support application that uses DPs into an aspect-

based version refactoring is proposed in (Giunta et al.,

2012). Here, with respect to our declarative approach,

a lower ﬂexibility in modifying patterns application

is obtained thought an explicit refactoring of exist-

ing source code. Differently from this, in the pro-

posed approach the system is developed from scratch

using a declarative language that is more suitable in

a forward engineering context. Finally, the proposed

approach differs from the other ones for the deﬁni-

tion of a dynamic DSL that involves, in a completely

dynamic manner, the existing source code in a pat-

tern logic. According to this, the proposed engine in

the place to modify or generate code, generates as-

pects that inject pattern logic at run-time while sys-

tem classes are oblivious. Since only aspects perform

interception and a run-time bytecode manipulation is

performed to apply pattern logic, an higher ﬂexibility,

a lower invasivity and a reduction of the maintenance

effort is obtained.

3 PROPOSED APPROACH

The proposed approach is focused on the deﬁnition of

a DSL based on an OO system meta-model and al-

lowing to map DPs (along with their variants, roles

and default implementations) on the system classes.

The DSL is composed by two main parts: i) the rep-

resentation of the source code elements and ii) the

representation of all the elements (pattern, role deﬁni-

tion and implementation) aiming to perform dynamic

interception of a wide set of events that are used to

involve, at run-time, the concrete classes in pattern

collaboration. The source code elements are modeled

using the programming language syntax of the imple-

mented system. In particular, the proposed DSL is

Reducing Static Dependences Exploiting a Declarative Design Patterns Framework

155

implemented considering Java as the target program-

ming language and it is deﬁned according to the ab-

stract syntax of the Java language speciﬁcation. The

system elements are represented by 113 meta-classes

and the relationships among them. The system el-

ement meta model also include generic types, state-

ments, blocks, exceptions and expressions.

In (Bernardi et al., 2014) the core excerpt of the

second part of the DSL meta-model is shown. It de-

scribes the overall structure of the DSL and focuses

on the main concepts used to implement idioms and

DPs (leaving base system classes oblivious and de-

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

the framework performs a mix of crosscutting in-

jection, alterations and introductions on the system

classes. In the following, there are some simple code

examples describing the most important elements in

the meta-model using the proposed DSL.

The Pattern Declaration Element. Each pattern

declaration can be seen as a layer containing only the

logic related to its goals and responsibilities. Patterns

are merged with the base system (and to other layers)

using AOP injection and interception features. The

ModelRoot (that is the root element of any DSL in-

stance) contains an ordered list of patterns. In the

following example two patterns (a Decorator and an

Observer) are deﬁned:

1 o r d e r S im p l e O bs e r v e r , ∗

2 p a t t e r n D r a w a b l e s D e c o r a t o r { . . .

3 p a t t e r n D e f a u l t S u b j e c t { . . .

4 p a t t e r n S i m p l e O b s e r v e r { . . .

The ordering is ﬁxed (using the composition order

statement) so that Identiﬁcation is always merged

before any other pattern. This is important when

some alterations to the base system are not optional

(i.e., the case of dependencies that require a role to

be granted in order to apply a pattern deﬁnition).

Deﬁne, Implement Pattern and Role(s) Elements.

The DSL statement deﬁne role allows a developer to

introduce a role in the system, while the statement im-

plement pattern is used to assign a pattern to a set

of concrete classes. The block implement role as

allows to deﬁne a named implementation of a role

that can be used for subsequent registration using the

framework static entry point. In the following exam-

ple, a CacheStrategy pattern, made of two roles (i.e.

CacheKeyStrategy and CachingContext), is declared:

1 p a t t e r n C a c h e S t r a t e g y <T> {

2 d e f i n e r o l e C a c h e K e y S t r a t e g y {

3 p u b l i c S t r i n g g etCac heK ey (

4 Re so ur ce UR I u r i ,

5 Map<S t r i n g , O b j e c t > pa ram s ) ;

6 }

7 d e f i n e r o l e C ac h i n g C o n t e x t <T> {

8 C a c h e S t r a t e g y <T> c a c h e K e y S t r a t e g y

;

9 <T> r e q u e s t ( ResourceURI u r i ) ;

10 }

11 implement r o l e C a c h e Ke ySt r a t e g y <

F i g u r e >

12 As F i g u r e C a c h e S t r a t e g y { . . . }

13 implement r o l e C a c hi n g C o n te x t <

F i g u r e >

14 As F i g u r e C a c h i n g C o n t e x t { . . . }

15 . . .

16 }

17 Fi g u r eMa n a g e r fm = new

F i g u r e M a n g e r ( ) ;

18 DDPF . g r a n t ( F i g u r e C a c h e S t r a t e g y .

c l a s s , fm , F i g u r e . c l a s s ) ;

19 DDPF . r ev o ke ( F i g u r e C a c h e S t r a t e g y .

c l a s s , fm ) ;

There are two ways to apply a pattern. The ﬁrst one

exploits a static entry point of DDPF framework. It is

shown in line 18 of the above DSL excerpt: in this

case the DDPF framework is requested to bind the

pattern to a single instance. This approach allows to

apply the pattern directly to a set of objects in order

to involve them, dynamically, in a patterns collabora-

tion. When such collaboration is completed and the

instances do not need anymore to be linked together,

it can be destroyed by revoking pattern adoption as

shown in line 19. The other way requires the usage

of dynamic inheritance by implementing, behind the

scenes, the ExtensionObjectsPattern (Gamma et al.,

1995) at class load time. As a consequence, all

the classes inheriting or implementing them will be

forced to provide this additional behavior (the strat-

egy context and the actual caching key strategy). The

DSL language construct allowing to do this is the im-

plement role on statement. It allows to specify the im-

plementation of a role that must be supplied to a set

of existing classes (the role implementation is hence

anonymous). The syntax is based upon the Injec-

tionRule nested element that must be followed by the

source code of the role implementation. 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 provided members should

create no conﬂict with the target types members (in-

cluding the ones that are weaved from other pattern

elements). In the next example, the inject statement

is used to provide an implementation (deﬁned from

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

156

scratch) of the CachingContext role introduced in the

previous example and to apply it to the a FigureMan-

ager (existing) system class:

1 implement p a t t e r n C a c h e S t r a t e g y <

F i g u r e > On F i g u r e Man a g e r {

2 i n j e c t r o l e C a c h i n g C o n t e x t {

3 F i g u r e r e q u e s t ( Res ou rc eU RI

u r i ) { . . . }

4 }

5 }

These classes have no references to the pattern

CachingContext implementation and have no imper-

ative dependencies on Identiﬁable interface (since in

this example the Identiﬁcation pattern is completely

orthogonal). However, studies that try to quantify the

crosscutting present in real systems, show that most of

the patterns are crosscutting and hence they depend on

each other. The implement role statement just allows

the deﬁnition of shared ﬁelds and methods to express

such an interleaving.

Shared Field and Shared Method Elements.

When a role is implemented for a set of concrete

classes, one or more methods/ﬁelds can be provided

to link the logic of concrete classes to the new be-

haviour. In the following DSL example, the UUID

can be used to build the name of AbstractFigure,

as shown in the following example, where a shared

method is nested in the role implementation statement

(a similar way can be used for a shared ﬁeld):

1 i n j e c t r o l e I d e n t i f i a b l e

2 on A b s t r a c t F i g u r e + {

3 UUID u u i d ;

4 p u b l i c UUID getUUID ( ) { . . . }

5 p u b l i c v o i d setUUID (UUID u ) { . . .

}

6 @Ov er rid e

7 p u b l i c S t r i n g getName ( ) {

8 r e t u r n s u p e r . getName ( ) + ” w i t h

UUID : ” + u u i d . t o S t r i n g ( ) ;

9 }

10 }

This DSL excerpt allows to inject the getName(void)

method in the complete hierarchy rooted in the class

AbstractFigure as a part of an Identiﬁable role, mak-

ing it dependent on a Named role providing the get-

Name() behavior. They could be both provided by

a single pattern deﬁnition, but this is not required.

Moreover, different methods can be speciﬁed for dif-

ferent sub-classes of AbstractFigure, thus reusing the

common behaviors as much as possible without loos-

ing ﬂexibility.

3.1 Specifying DPs by the DSL

DPs can be deﬁned by using the DSL elements shown

in the previous examples. The following example

shows an excerpt of the deﬁned DSL to implement

a modular Observer over Figure and View classes:

1 p a t t e r n O b s e r v e r {

2 d e f i n e r o l e S u b j e c t {

3 v o i d a d d S u b j e c t ( L i s t e n e r l ) ;

4 v o i d r e m o v e S u b j e c t ( L i s t e n e r l ) ;

5 v o i d n o t i f y ( ) ;

6 }

7 d e f i n e r o l e L i s t e n e r {

8 v o i d u p d a t e ( S u b j e c t s ) ;

9 }

11 implement r o l e S u b j e c t On F i g u r e +

{

12 L i s t <L i s t e n e r > l i s t = new

A r r a y L i s t ( ) ;

13 v o i d a d d S u b j e c t ( L i s t e n e r l ) {

14 l i s t . add ( l ) ;

15 }

16 v o i d r e m o v e S u b j e c t ( L i s t e n e r l ) {

17 l i s t . remove ( l ) ;

18 }

19 v o i d n o t i f y ( ) {

20 f o r ( L i s t e n e r l : l i s t ) l .

u p d a t e ( t h i s ) ;

21 }

22 }

23 implement r o l e L i s t e n e r On View+

{

24 v o i d u p d a t e ( S u b j e c t s ) {

25 t a r g e t . r e f r e s h ( ) ;

26 }

27 }

28 @O verri de

29 v o i d F i g u r e . s etName ( S t r i n g name ) {

30 t a r g e t . s etNa me ( name ) ;

31 n o t i f y ( ) ;

32 }

33 }

In this example the two observer roles (Subject and

Listener) are deﬁned and injected respectively in all

Figure and View hierarchies using the implement role

on statement. The methods deﬁned within role imple-

mentation can exploits the target reference in order

to access the public and protected interface of the type

the role is bound to (Figure and View in the example).

To support and evaluate the approach, the DDPF was

developed. In the prototype, 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 us-

ing such marker interfaces. Each pattern element can

Reducing Static Dependences Exploiting a Declarative Design Patterns Framework

157

be seen as the intermediate mapping layer of a three

layers structure in which concrete system classes are

involved in pattern relationships by an aspect that acts

as “pattern mapper”. This layer is responsible of im-

plementing a dynamic mapping of DPs and idioms to

concrete classes intercepting object creation and en-

forcing the pattern protocol for instances that need

it. Concrete classes, belonging to the ”base system”

layer, are oblivious of being involved in a pattern and

the pattern relationships can be removed simply act-

ing on the mapping layer. Commonalities among dif-

ferent pattern instances can be factorized in the pat-

tern logic pattern, while multiple relationships can be

easily resolved in the pattern mapping layer by asso-

ciating two aspects to the same concrete class.

4 CASE STUDY

To assess the effectiveness and the validity of the ap-

proach, a real world Java system, the Korsakow editor

, was redesigned by adopting the proposed frame-

work. The assessment of the DDPF approach takes

into account the quality of the modularization in terms

of pattern logic decoupling from concrete classes.

To evaluate the improvement in the quality of the

modularization, a crosscutting comparison between

two versions of the system (original and refactored

with ddpf), has been performed. In order to quan-

tify scattering and tangling of DPs code within system

classes, DOF and DOS metrics (Eaddy et al., 2007)

are used; this allowed to compare crosscutting across

two different systems. Moreover, in order to evalu-

ate the impact of a requirement change, a composite

Macro Command was introduced mixing Command

pattern hierarchy implementation with a Composite

pattern. Several metrics are evaluated (the number

of #changed LOC and modules and DOS/DOF varia-

tion).

4.1 Command Pattern Analysis

The analyzed system is editor to build layout support-

ing several languages. It has a big command hierarchy

interleaved with several other concerns (persistence,

parsing, text manipulation just to name few).

The Korsakow command hierarchy is rooted in a

ICommand interface. This interface can be refactored

easily as the DDPF role and this allow to remove sev-

eral LOC from the entire hierarchy as shown in the

quantitative analyses. Each editor instance is asso-

ciated to a set of Commands interleaved by a Fac-

tory and exposed to the IDE by means of an action

https://github.com/korsakow/korsakow-editor

framework. As shown in the ﬁgure, the command

processors are created by the main instance and fol-

lows the request/response model. Each factory is also

responsible to inject its context object to the set of

its commands. Most commands work on document

model (not shown in the ﬁgure). Document model is

centered on composites, as can be simple items (of

several kind of items, e.g. Keyword, Media, Pattern,

Predicate, Resource, Text, Sound) associated to a sin-

gle ﬁle. The OOP version of the Command pattern is

heavily interleaved with several secondary concerns

as stated by requirements. In each Command there are

explicit fragments linking it to security, logging and

tracing concerns (increasing scattering and tangling).

In the DDPF version the entire command hierarchy

has been implemented using role assignment and role

implementation constructs. This implements the Ex-

tensionObjectsPattern inside an abstract aspect and

adds the ”Command” role extension to all the class

hierarchy. Analyzing the system code, we found that,

with respect to the plain OOP version, DDPF with the

adoption of ExtensionObjectsPattern allowed to mod-

ularize several concerns (making system classes not

aware of being linked to the pattern) with comparable

level to the marker interface implementation having

the additional advantage of being totally dynamic. In

the refactored system every command class can be-

come a command associating it a speciﬁc logic that

exploits its internal state.

4.2 Discussion

The modulariry assessment for DDPF and OOP ver-

sions has been perfomed by calculating: (i) the ra-

tio of lines of source code related to DP code in each

class or module with respect to the total LOC of the

same class or module, and (ii) the Degree of Scat-

tering (DOS) and Degree of Focus (DOF) metrics

(Eaddy et al., 2007), for each module and pattern.The

section also provides quantitative information about:

(i) size and dimension ; (ii) code clones and (iii) pat-

tern code presence and distribution.

Results are reported in ﬁgure 1. In particular, in

Figure 1 the LOC ratio (%LOC) of each design pat-

tern concern over the cloned LOC ratio are compared

for each module in both DDPF (AOP) and OOP ver-

sions for the command hierarchy. The results show

that the ratio of the average cloned LOCs in the OOP

implementation is signiﬁcantly greater than the DDPF

system. In this case the DDPF usage improved the

maintainability decreasing the probability of intro-

ducing bugs during maintenance. This is conﬁrmed

by looking at the Degree of Focus (DOF) of the mod-

ules reported (only for Items implementing Compos-

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

158

Figure 1: LOC/cloned-LOC ratio by module for OOP and DDPF (left) - Affected LOC/modules for Commands Hierarchy

and Macro Command (on the right).

ite and Command hierarchy) in Figure 1. Modules of

the OOP version have a worse DOF since they explic-

itly implement design patterns protocols in addition to

other secondary concerns while in DPMF system the

DP logic is better modularized in the aspects that are

derived by the framework from the DSL statements.

4.3 Macro Commands

This section studies how changes to a pattern prop-

agates to base system classes and requires a source

code modiﬁcation. Such requirement change impacts

very differently on OOP and DDPF versions. In the

OOP version, the needed changes is much higher than

the DDPF version. In the DDPF system concrete

commands were not impacted by the command aggre-

gation. The only required changes are related to the

DSL statements and to the addition of new modules

for additional commands. DOS and DOF were evalu-

ated after the maintenance task and provide evidence

that the resulting modularity for the DDPF system in-

creases over the OOP version.

4.4 Performance Evaluation

The case study also veriﬁed that the AOP-based archi-

tecture does not have a negative run-time performance

impact (due to aspect runtime interception overhead).

With this aim, the AOP system was instrumented in

order to gather execution times of the aspect over-

heads. The worst average times in several different

categories of pointcut expressions, as automatically

generated by DSL statements (i.e. object creation/de-

struction, interception of pattern operations), were se-

lected and the time spent in the aspect runtime to jump

to pattern logic was collected. We found that time

needed to handle creation/destruction of object is usu-

ally greater than the time required to intercept opera-

tions. In pointcut expressions related to the design

patterns operations the worst overheads due to aspect

interception mechanism are resulted always less than

5% of the pattern collaboration times.This shows the

suitability of performance overhead introduced by the

aspect declarations generated from DSL statements.

5 CONCLUSIONS AND FUTURE

WORKS

AOSD and MDSD features have been used to develop

a design pattern adoption approach and a supporting

framework allowing:

• the declarative speciﬁcation of DPs by a DSL;

• an AOP based implementation of the speciﬁed

DPs.

The goal is to improve the modularity, the internal

code quality, and the ﬂexibility of DPs. DPs are spec-

iﬁed by a DSL based on a meta-model where a DP

is seen and structured as an (ordered) sequence of

named design pattern elements. An improved proto-

type of the framework, adopting an AOP version of

the ExtensionObjectsPattern, was used in a case study

to assess its effectiveness and efﬁciency. The results

from the case study showed that the AOP implemen-

tation of DPs signiﬁcantly improved the modularity

of the system with respect to traditional OO version.

Future work will consider improvements of both the

prototype framework and DSL.

REFERENCES

Baca, P. and Vranic, V. (2011). Replacing object-oriented

design patterns with intrinsic aspect-oriented design

patterns. In Eastern European Regional Confer-

ence on the Engineering of Computer Based Sys-

tems, ECBS-EERC ’11, pages 19–26, Washington,

DC, USA. IEEE Computer Society.

Bernardi, M. L., Cimitile, M., and Distante, D. (2013a).

Web applications design recovery and evolution with

RE-UWA. Journal of Software: Evolution and Pro-

cess, 25(8):789–814.

Reducing Static Dependences Exploiting a Declarative Design Patterns Framework

159

Bernardi, M. L., Cimitile, M., and Lucca, G. A. D. (2013b).

An aspect oriented framework for ﬂexible design

pattern-based development. In ICSOFT 2013 - Inter-

national Joint Conference on Software Technologies,

Reykjav

ık, Iceland, 29-31 July, 2013, pages 528–535.

Bernardi, M. L., Cimitile, M., and Lucca, G. A. D. (2013c).

A model-driven graph-matching approach for design

pattern detection. In 20th Working Conference on Re-

verse Engineering, WCRE 2013, Koblenz, Germany,

October 14-17, 2013, pages 172–181.

Bernardi, M. L., Cimitile, M., and Lucca, G. A. D. (2014).

Declarative design pattern-based development using

aspect oriented programming. In Symposium on Ap-

plied Computing, SAC 2014, Gyeongju, Republic of

Korea - March 24 - 28, 2014, pages 1625–1630.

Bernardi, M. L., Cimitile, M., and Lucca, G. A. D. (2016).

Mining static and dynamic crosscutting concerns: a

role-based approach. Journal of Software: Evolution

and Process, 28(5):306–339.

Boussaidi, G. E. and Mili, H. (2007). A model-driven

framework for representing and applying design pat-

terns. In Computer Software and Applications Con-

ference, 2007., volume 1, pages 97–100.

Eaddy, M., Aho, A., and Murphy, G. C. (2007). Identify-

ing, assigning, and quantifying crosscutting concerns.

In International Workshop on Assessment of Contem-

porary Modularization Techniques, ACoM ’07, pages

2–, Washington, DC, USA. IEEE Computer Society.

Eden, A. H. (2001). Formal speciﬁcation of object-oriented

design. In International Conference on Multidis-

ciplinary Design in Engineering CSME-MDE 2001,

pages 21–22.

Elaasar, M., Briand, L. C., and Labiche, Y. (2006). A

metamodeling approach to pattern speciﬁcation. In

International Conference on Model Driven Engineer-

ing Languages and Systems, MoDELS’06, pages 484–

498, Berlin, Heidelberg. Springer-Verlag.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns: Elements of Reusable

Object-oriented Software. Addison-Wesley Longman

Publishing Co., Inc., Boston, MA, USA.

Giunta, R., Pappalardo, G., and Tramontana, E. (2012).

Aodp: Refactoring code to provide advanced aspect-

oriented modularization of design patterns. In ACM

Symposium on Applied Computing, SAC ’12, pages

1243–1250, New York, NY, USA. ACM.

Hannemann, J. and Kiczales, G. (2002). Design pattern

implementation in java and aspectj. In ACM SIG-

PLAN Conference on Object-oriented Programming,

Systems, Languages, and Applications, OOPSLA ’02,

pages 161–173, New York, NY, USA. ACM.

Hannemann, J., K. G. (2001). Overcoming the prevalent

decomposition of legacy code. In Workshop on Ad-

vanced Separation of Concerns at the International

Conference on Software Engineering, ICSE.

Soundarajan, N. and Hallstrom, J. O. (2004). Responsibili-

ties and rewards: specifying design patterns. In Inter-

national Conference on Software Engineering, 2004.,

pages 666–675.

Zdun, U. (2004). Pattern language for the design of aspect

languages and aspect composition frameworks. IEE

Proceedings - Software, 151(2):67–83.

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

160