Facilitating software extension with design patterns and Aspect-Oriented Programming

Available online at www.sciencedirect.com

www.elsevier.com/locate/jss

The Journal of Systems and Software 81 (2008) 1725–1737

Facilitating software extension with design patterns andAspect-Oriented Programming

Konstantinos G. Kouskouras *, Alexander Chatzigeorgiou, George Stephanides

Department of Applied Informatics, University of Macedonia, 156 Egnatia Street, 54006 Thessaloniki, Greece

Received 20 February 2007; received in revised form 15 December 2007; accepted 27 December 2007Available online 17 January 2008

Abstract

Software products, especially large applications, need to continuously evolve, in order to adapt to the changing environment andupdated requirements. With both the producer and the customer unwilling to replace the existing application with a completely newone, adoption of design constructs and techniques which facilitate the application extension is a major design issue. In the current workwe investigate the behavior of an object-oriented software application at a specific extension scenario, following three implementationalternatives with regards to a certain design problem relevant to the extension. The first alternative follows a simplistic solution, the sec-ond makes use of a design pattern and the third applies Aspect-Oriented Programming techniques to implement the same pattern. Anassessment of the three alternatives is attempted, both on a qualitative and a quantitative level, by identifying the additional design impli-cations needed to perform the extension and evaluating the effect of the extension on several quality attributes of the application.� 2008 Elsevier Inc. All rights reserved.

Keywords: Object-oriented design; Aspect-Oriented Programming; Design patterns; Maintainability; Software metrics

1. Introduction

One of the most compelling properties of software prod-ucts is their need to continuously evolve. In the case oflarge software products/applications, both the customerand the producer endorse this characteristic, since theyboth strive to obtain the most out of their investment, topurchase or develop the products, respectively. Mainte-nance is becoming a significant part of the software prod-ucts’ life cycle, as the organizations try to keep themoperating for as long as possible (SWEBOK, 2004). Evenmore, most of the maintenance effort concerns adaptiverather than corrective adjustment of the software products(due to missed/revised requirements, customization) (Press-man, 2004). It is then evident that it is extremely importantto build software in such a way that it can easily evolve(Bengtsson et al., 2004), to the extent that evolution paths

0164-1212/$ - see front matter � 2008 Elsevier Inc. All rights reserved.

doi:10.1016/j.jss.2007.12.807

* Corresponding author. Tel.: +30 6944 790944/2310 497347.E-mail addresses: [email protected], [email protected] (K.G. Kous-

kouras).

can be foreseen. Understanding the factors that influencemaintainability (i.e. ease with which software can beenhanced or adapted) of a system can help contain mainte-nance cost.

Researchers and practitioners have contributed severalmethods for building software that meets such expecta-tions. Incorporation of design patterns when building soft-ware has been proposed as a way to improve softwarereusability and maintainability (Gamma et al., 1995).Refactoring techniques, aiming at improving code struc-ture without altering its external behavior, have also beendevised (Fowler, 1999). Lately, the Aspect-Oriented Pro-gramming paradigm (Kiczales et al., 1997) has been alsobeen presented as a possible way to enhance an object-ori-ented system, by concentrating within a single entity (theaspect) code that would otherwise be scattered among sev-eral classes, thus adversely affecting maintainability.

Several works exist in the literature, related to theabovementioned methods. Some of them present aspect-oriented implementations of design patterns. For example,Nordberg (2001) suggests that aspect-oriented implementa-

mailto:[email protected]

mailto:[email protected]

1 Since we are referring to a specific application built in Java, we will usethe equivalent term ‘package’ throughout the rest of the document.

1726 K.G. Kouskouras et al. / The Journal of Systems and Software 81 (2008) 1725–1737

tion of certain design patterns may lead to better designswith greater effectiveness in anticipating future changes.Hannemann and Kiczales (2002) present aspect-orientedimplementations of all 23 GoF patterns and comment ontheir modularity based on whether these implementationsmanifest properties like reusability and (un)plugability.Another category includes works attempting to compareobject-oriented and aspect-oriented implementations ofthe same functionality. Papapetrou and Papadopoulos(2004) identify functionalities of a web-crawler that couldbe modeled as aspects and implement them following bothapproaches. Then, they compare the two systems focusingon the amount of changes and coding needed to add thosefunctionalities. Tsang et al. (2004) report on another com-parison, on the basis of class metrics adapted to aspects.Kulesza et al. (2006) use their metric suite (based on C &K class metrics and detailed in Sant’Anna et al. (2003))in order to assess the maintainability of an object-orientedand an aspect-oriented implementation of a specific system.

Our purpose is to elaborate on the extensibility/expand-ability of software products, in relation with the two designpractices mentioned above, i.e. design patterns and Aspect-Oriented Programming. We want to evaluate the differentdesigns in terms of the ease with which a certain extensioncan be achieved and the influence this extension has on thesystem’s quality attributes. To help us reach reliable con-clusions we built a software application in Java, suitablefor our investigation purposes, on which we could experi-ment. More specifically, we built an emulator of a telecom-munications exchange, allowing the user to configure itwith commands and to perform simple traffic cases.

A specific extension scenario was investigated in the cur-rent work. We assumed that new commands and associatedparameters are added in the application. We employedthree different implementation alternatives, with regardsto the application part related to the specific extension.The first one follows obvious (at least to our minds!) andsimplistic design decisions. The second makes use of adesign pattern (the Registry Pattern (Sommerlad andRuedi, 1998)), which is proposed as a means to overcomesome limitations identified in the first alternative. In thethird alternative we implemented the Registry pattern usingAspect-Oriented Programming techniques.

After implementing the same extension on all threealternatives we attempted an assessment of theirs byexploring the implications of the extension in each one.For each alternative this exploration was twofold. Onone hand we qualitatively evaluated the ease with whichthe extension was achieved, i.e. whether the design facili-tates/promotes/encourages such an extension or makes itcumbersome (from a design point of view). On the otherhand, we quantitatively checked the effects of the extensionon several quality attributes of the application, as reflectedin metrics, in order to see whether the extension improves,preserves or has an adverse impact on these metrics.

The rest of the paper is arranged as follows. First, thereis a short description of the application and the extension

scenario chosen. In the following chapter the assessmentframework is analyzed. Then, the first alternative is pre-sented, commenting on metric results and other qualitativeobservations. In the next chapter the Registry pattern isintroduced, along with the alternative implementationresulting from its application. A short description of theAspect-Oriented Programming paradigm follows and next,the third alternative implementation is presented, with theRegistry pattern being applied using the Aspect-OrientedParadigm. Finally, some conclusive remarks aresummarized.

2. The software application and the extension scenario

We chose the field of application to be the telecommuni-cation industry because of the size and continuous evolu-tion (due to standards’ revisions and market adaptations)that systems of this area demonstrate. Furthermore, sincetelecommunication products are developed following spe-cific software engineering processes, maintenance activitiesare always foreseen.

So, the application is an emulator of an imaginary tele-phone exchange. In its current form, it enables the user to

� insert definition commands (e.g. define a connection andassign a subscriber number to it) and� emulate simple calls between subscribers.

From an implementation point of view the applicationwas built in Java. It consists of modules (packages in Java)that correspond to specific logical (functional) areas.Regarding its size, it consists of about 50 classes and1700 non-commented lines of code (before the extension).

As will be seen in the rest of the paper, we view thenotion of module of high significance, since it is quite oftenconsidered as the basic element of object-oriented softwarereuse (Booch, 1994). It is seldom the case that a single classcan be reused alone, when certain functionality is needed;most often there are closely cooperating classes thattogether fulfill the functional requirement. If the module1

contents and structure are well chosen and properlydesigned, then it can be easily reused, whenever its func-tionality is needed. Furthermore, in large software systemsthe module could be seen as a functional area with well-defined boundaries and interfaces, such that it could be del-egated as a whole to a specific group of people or organiza-tion (within one project or for all its lifetime), thusfacilitating the splitting of responsibilities.

In the simple object-oriented implementation of theapplication, the main packages, which are to their largestextent similar among the alternative implementations, areas follows:

K.G. Kouskouras et al. / The Journal of Systems and Software 81 (2008) 1725–1737 1727

� adminsub. It contains functionality for providing theuser with a certain command handling environment,for receiving and analyzing the commands and for pre-senting their outcome.� accsub. It mainly keeps the software representation of

the subscriber’s terminal equipment, including its trafficstate.� snbsub. Subscriber data are kept in this package, includ-

ing subscriber number – terminal equipmentassociations.� traffsub. This package provides the software resources in

order to establish and maintain a traffic connection.� misc. The miscellaneous package consists of classes that

implement auxiliary functionality (e.g. presenting theinitial user interface or the component representing theterminal equipment).

The extension scenario we investigate involves the addi-tion of several new commands and parameters. To betterunderstand the implications of this extension a shortdescription of how the command handling environmentoperates is necessary.

For each command accepted by the application there isone class (e.g. DEFACCESS for a command defining a newconnection) implementing command handling functional-ity. Common functionality is included in an abstract class,AbstractOAMCommand, which also implements theOAMCommand interface characterizing command handlingclasses (‘OAM’ stands for Operation And Maintenance).Each command handling class should inherit fromAbstractOAMCommand. Furthermore, there is one classrepresenting each parameter supported. Similar rules applyfor parameter classes, with common functionality providedby AbstractParameter which implements the Param-eter interface.

The command handling environment is responsible forreceiving and analyzing the user input. The syntax of thecommands follows a simple logic, with the user enteringthe command name and the necessary parameters in astring, through a console-like user interface. The outcomeof a successful analysis is the command name and a setof parameter name–value pairs. Having identified the cor-rect class names, objects of the relevant classes are instan-tiated and responsible thereafter for verifying the integrityof the command and for performing the intended opera-tion. An appropriate error message is the output if the pro-cess fails at any point.

We consider the case that new, fictional commands areneeded, which entail the addition of new fictional parame-ters. The assumption taken is that the new commands andparameters conceptually belong to the same functionalarea, hence their association with a new fictional package,fictsub. Stated otherwise, it is assumed that the new com-mands and associated parameters are related to that newpackage, their relevance being signified by the fact thattheir execution depends and/or affects data maintainedwithin the same functional area, represented by the new

package. A central class exists within the fictional package,which is supposed to maintain and manipulate these data.It must be noted that we do not have any specific require-ment on the outcome of each command. We are just inter-ested in the successful acceptance of the commands by theapplication (in other words, we are just interested in pro-ducing a valid object exiting the command handling envi-ronment functional area borders).

It should also be noted that the three implementationalternatives follow different approaches with regards todetermining whether a given string corresponds to a sup-ported command or parameter class name.

3. Assessment framework

As already mentioned, our purpose is to assess eachimplementation by exploring on two levels the implicationsthat the extension would have. The first level is qualitative,supported by observations of the design implications. Thesecond level is quantitative, supported by specific measure-ments of metric values before and after the extension. Itshould be made clear that we do not intend to comparethe three alternatives directly to one another but ratherthe effects of the extension within each alternativeseparately.

3.1. Qualitative level

The design implications to perform a specific extensioncould be divided into two categories. The first is relatedto the pure implementation of the required adaptation,i.e. of the new functionality. Obviously, these implicationscannot be avoided regardless of the design alternative andtherefore need not be taken into account when comparingthese alternatives. The second category encompasses thoseimplications necessary to import the new functionality inthe existing system. We can better understand this pointif we imagine that the new functionality is designedseparately, and then it is attempted to integrate it withthe existing system. Ideally, there should not be any suchimplications meaning that the new functionality can beplugged in and out the system without any prerequisite.

Most of the times however, design adjustments, func-tionally irrelevant to the existing classes or to the addedclasses, are needed, thus hindering the extension or smoothdeployment of the application. On a high level these impli-cations could be characterized by not directly measurableindicators, like how straightforward are these adjustmentsand what kind of knowledge would be required to discovertheir necessity and nature. Within the context of this workwe base our qualitative assessment on the existence of suchimplications.

3.2. Quantitative level

Based on specific metric values, as collected before andafter the extension for each alternative, we checked the


effects of the extension on several quality attributes of theapplication, as reflected by these metrics, in order to seewhether the extension improves, preserves or has anadverse impact on these attributes.

As already said, modules are often considered as thegranule of release and reuse. Dependencies between pack-ages are a good indicator of package quality. On packagelevel we focused on investigating the dependencies betweenthe packages and the way these dependencies were affectedby the extension. In this direction, the behavior of six spe-cific metrics was examined based mainly on Martin’s metricsuite (Martin, 2003). Before presenting the results, a shortdescription of these metrics is due.

3.2.1. Afferent coupling (Ca)Afferent Coupling counts the number of types outside

the measured package which depend upon types withinthat package (incoming dependencies). A high Ca valuewould then characterize a responsible package, in the sensethat many other types depend on its functionality.

3.2.2. Efferent coupling (Ce)

Efferent coupling counts the number of types within themeasured package which depend upon types outside thatpackage (outgoing dependencies). A high Ce value indi-cates that the package’s stability depends too much onthe stability of other packages.

3.2.3. Instability (I)

Instability is a derivative of the previous two metrics,and is defined as I = Ce/(Ce + Ca). The rationale behindthis measurement is that the more the outgoing dependen-cies for a package are than the incoming ones, the less sta-ble should the package be considered.

3.2.4. Abstractness (A)

Abstractness is the ratio of abstract classes and inter-faces to the total number of types (classes, concrete orabstract, and interfaces) of the measured package. By def-inition, abstract classes and interfaces are certain to drawincoming dependencies. Then, in combination with the dis-cussion on instability above, packages with high abstract-ness would be good to be stable (and vice versa).

3.2.5. (Normalized) Distance from main sequence (D)

Distance from the main sequence attempts to formalizethe observations that were mentioned above for Instabilityand Abstractness. The Distance from the Main Sequence isdefined as jA + I � 1j (normalized) and is an indicator ofhow ‘good’ is the Abstractness/Instability mixture for thepackage.

3.2.6. Relational cohesion (H)

Relational cohesion represents the relationship that thepackage has to all its types. It is the average number ofinternal relationships per type of the measured package.If N is the number of types within the package and R the

total number of relationships that are directed to types ofthis package, then H = (R + 1)/N.

Additionally, it was examined whether the packages ofthe application were involved in cyclic dependencies, i.e.dependencies originating from a specific package and ter-minating in the same package after traversing the depen-dency graph.

Apart from the measurements of metric values on pack-age level, we also collected metric values on class level. Sev-eral such metrics exist; however, we will not explicitly referto all of them, either because they were not affected by theextension or because their change was as expected and didnot offer any significant conclusion to our investigation.For example, adding command classes, each of which hasto inherit from AbstractOAMCommand, increases thevalue for Number Of Children for that class by the numberof commands added. Since this observation is predictable,and most important, inevitable, it does not help in deter-mining whether the extension had an adverse effect onthe quality attributes of the application.

4. Extending the simple OO implementation

Fig. 1 presents a portion of the application, where themajor components involved in the command/parameterhandling environment are included, for the first implemen-tation alternative. In this alternative, two classes placed inthe adminsub package are dedicated for providing the‘translation’ service, through static methods, one for com-mands and the other for parameters (see I in Fig. 1). Thedecision on whether a specific string corresponds to a sup-ported command or parameter name is taken with the useof RTTI (run-time type identification) techniques, in orderto avoid lengthy case or if statements. First, theClass.forName method, which takes a string as an argu-ment, is used to check if a name constitutes a valid classname within the application. The string must identify thefull path of the class required, that is including the packagewhere the class is to be found. As a result, and since all pos-sible packages that could include command or parameterclasses cannot be anticipated, a convention has to be fol-lowed, i.e. to always place such classes in the comparsubpackage which is dedicated for that purpose. Then, theClass.getInterfaces and Class.getSuperclass

methods are used to verify that the identified class indeedrepresents a valid command handling or parameter class,by checking if it extends the respective abstract class andimplements the associated interface.

4.1. Design implications

As evident from the short description of the application,when implementing the extension with the new commandsand parameters we have to follow a specific class name pat-tern for the corresponding classes. Furthermore, regardlessof the functional area that the added command or param-eter would better fit into, it always has to be placed in the

Fig. 1. Command/parameter handling details, 1st alternative.


comparsub package, whose name is hard-coded in theclass that is responsible for determining the validity ofthe name within the application.

This design limitation is reflected in a specific kind ofknowledge on internal behavior that a designer has to havein order to perform this extension to the application. It isessentially a violation of the encapsulation principle. Thismakes the design rigid and inflexible to specific extensions.Stated otherwise, it is a characteristic that does not promotethe ease of expansion. Furthermore, the choice of having thecomparsub package may result in the awkward deploy-ment of the application, in case there is a need to provide dif-ferent sets of commands/parameters for different customers.

4.2. Quantitative assessment

As shown in Table 1, change of the metric values wasobserved for adminsub and comparsub packages.

The data show that adminsub package becomes morestable (Instability is decreased) as more commands orparameters are added, since all of them have to refer to thatpackage, while its contents and therefore Efferent Coupling

and Abstractness remain unaffected. Keeping in mind thatadminsub package would probably be intended to bereused if possible, increasing its stability can be seen as apositive effect that the extension has on it. On the otherhand, the increasing trend of Distance (due to the lowand unaffected value of Abstractness) suggests that thepackage might be less abstract than it should be.

For the comparsub package, the effect of the specificextension is just to retain it at one desirable extreme

described above, i.e. totally concrete but with no incomingdependencies. Furthermore, the package becomes lesscohesive, as more classes without any type relationshipsbetween them are added to it.

Interesting conclusions can be drawn for the new pack-age, fictsub, too. It seems that as more commands con-ceptually fitting in this package are added, the package isforced to become more stable, since the relevant classeshave to be included in another package and yet dependon the central class of fictsub (see II in Fig. 1). SinceEfferent Coupling and Abstractness are not affected, thespecific extension’s effect is to make the package moreresponsible, regardless of its abstractness. Indeed, Distanceindicates that fictsub package is away from its mainsequence. Therefore, we can conclude that the specificextension has an adverse effect on the fictsub packagecharacteristics. Note that these observations are madestrictly from the viewpoint of the functionality relevant tothe specific extension. In other words, fictsub packageshould not have a responsible role in the command han-dling functionality. On the other hand, the RelationalCohesion of this package remains unaffected since thenew classes are added in a different package. It is alsoworth noticing that fictsub is not involved in any cyclicdependencies.

On class level, the metric values have indicated that theextension affected the metrics of just a few classes, in theobvious way, directly analogous to the number of newcommands and parameters introduced. For example, it isobvious that the number of classes using the interfacedefined by the AbstractParameter will increase line-

Table 1Metric values on package level, first alternative

Package Ca Ce I A D H Cycles

Base New Base New Base New Base New Base New Base New Base New

accsub 6 6 12 12 0.67 0.67 0.08 0.08 0.25 0.25 2.92 2.92 12 12adminsub 10 32 1 1 0.09 0.03 0.33 0.33 0.58 0.64 2.2 2.2 0 0comparsub 0 0 4 24 1 1 0 0 0 0 0.25 0.04 0 0misc 14 14 7 7 0.33 0.33 0.08 0.08 0.59 0.59 1.69 1.69 12 12snbsub 7 7 3 3 0.3 0.3 0 0 0.7 0.7 1 1 10 10traffsub 11 11 2 2 0.15 0.15 0 0 0.85 0.85 1 1 10 10fictsub 10 2 0.17 0 0.83 1 0


arly with the number of new parameters added. So, apartfrom inevitable implications, the characteristics of the sys-tem on class level were preserved.

5. The Registry pattern

To gain flexibility and avoid the design limitation of thefirst alternative we have adopted the Registry pattern, witha slight variation in its structure. The main idea is to have aregistry class keeping the associations between keys (com-mand/parameter names in our case) and values (commandhandling/parameter class names in our case), specific toeach registree class. This registry class is globally knownwithin the application, so that agent classes can configureit with key-value pairs and client classes can submit theirrequests. With this solution, the part of the applicationresponsible for resolving the request in fact becomes the cli-ent in the Registry pattern, and need not be modified when-

Fig. 2. Class diagram of

ever registree classes are added or removed. Consequently,such extensions are made easier, and reusability of thatpart of the application is promoted.

The class diagram in Fig. 2 shows the structure of theRegistry pattern.

The participants of the pattern, as shown in the diagramin Fig. 2, are the following:

� Registry maintains the associations between keys andvalues, and implements the interface for registering asso-ciations and returning the associated value, given a key.� AbstractRegistree implements the interface for setting

the Registry. Furthermore, it defines the interfacefor retrieving the key and associated value of a givenregistree. It is useful to note that though abstract, thisclass should have already acquired the characteristicthat would enable it to represent the specific type ofregistrees.

the Registry pattern.


� ConcreteRegistree defines the key and associated valuefor this registree and implements the relevant part ofthe AbstractRegistree interface.� Agent is responsible for choosing the appropriate Regis-

try, and configuring each ConcreteRegistree that itknows with the Registry.� Client knows which Registry to use and employs it for

retrieving the value associated with a specific key.

The above participants interact with each other in thefollowing way. The Agent acquires an instance of theRegistry it wants to use. It then configures the relevant Con-

creteRegistrees with this Registry. Each of the ConcreteReg-

istrees, when informed of the Registry to use, registers itselfto that Registry. During registration, the Registry requestsfrom the ConcreteRegistree the key and the value to associ-ate with it, and updates its association list. During opera-tion, the Client, having obtained a key, contacts theRegistry in order to find out the value associated with thekey.

With the Registry pattern, all that the Client needs toknow is which Registry to refer to. On the other hand, itis the Agents that need to know which ConcreteRegistrees

exist in the system and which Registry they should config-ure. Adding ConcreteRegistrees can be done either throughan existing Agent, or by introducing a new one (the patternallows multiple Agents). Additionally, it must be ensuredthat ConcreteRegistrees’ registration is done before anyClient submits queries to the Registry. Depending on thecase, this requirement might entail different design implica-tions on the existing and/or added classes. However,regardless of the design decisions, these implications can-not be avoided.

From the implementation point of view, it can be easilyobserved that the most convenient approach is to make theRegistry a Singleton. Another design detail is that an Agent

might need to instantiate an object of each ConcreteRegis-

tree class to register, if we assume that object instantiationis necessary for producing the unique key and value. How-ever, once the specific key and associated value have beenobtained, the just created objects can be destroyed or leftfor garbage collection. It must be noted that registering aConcreteRegistree object itself (i.e. use the object’s refer-ence as the ‘associated value’) might prove unsafe in thecase of multiple Clients.

6. Extending with Registry pattern implemented in OO

Fig. 3 presents the major components involved in thecommand/parameter handling environment for the secondimplementation alternative. In this second alternative, wehave replaced the mechanism for determining whether aspecific string corresponds to a supported command orparameter name with two instances of the Registry pattern.Two Registries, OAMCommandRegistry and Parame-

terRegistry, respectively, were created within admin-

sub package (see I in Fig. 3), extending the generic

components created in the misc package, to replace theclasses providing the ‘translation’ services and to keep theassociations of command/parameter names and classnames. It can be easily seen that the classes implementingcommand handling or parameter functionality are the Con-

creteRegistrees. Such classes can now be freely placed inany package, and therefore the dedicated comparsub

package is eliminated. Furthermore, existing commandand parameter classes are moved within their respectivepackages (accsub and snbsub). Note that Abstrac-tOAMCommand acts both as AbstractRegistree (for the firstpattern instance) and as a Client (for the second). As far asthe Agent role is concerned, for the first pattern instance itis assigned to a central class within each package for thecommands contained in that package, while for the secondinstance to each concrete OAMCommand, for the Parame-ters it accepts (see II in Fig. 3). The relevant actions aretaken in the constructors of the classes assigned the Agent

role. Note that creating an object of the central class, apartfrom executing the Agent code for the first pattern instance,has the side-effect of triggering the execution of the secondpattern instance Agent codes.


The extension scenario in this version of the applicationis equivalent to adding ConcreteRegistrees (the new com-mand and parameter classes) for each of the two instancesof the Registry pattern. The additional design implicationsto implement such an extension are relevant to the incorpo-ration of pattern related code in the classes acquiring a roleand to the consideration mentioned above, about ensuringthat the registrations precede any possible query submis-sion. For the ‘command’ instance of the pattern the systemrestart procedure (which initializes the system by invokingthe constructor of the central class of each package) in themain class (LEMonitor) of the application must beimpacted in order to encompass the central class of thenew package in its logic (see III in Fig. 3). On the otherhand, the registration of the new Parameters does notinduce any similar impact, since it is done through OAM-

Command object creation (see description in the previouschapter).

In this alternative, we do not have to follow any conven-tions regarding the command and parameter class names,or place them in a predetermined package. This improvesthe situation with different customizations mentionedabove, since the new functionality can be plugged out moreeasily. At the same time, the part of the application respon-sible for determining the correct association between acommand or parameter name and the respective class nameis not impacted at all whenever extending the applicationalong that path. With the incorporation of the Registrypattern we have achieved the goal of having the flexibilityto define the associations without limitations. On the otherhand, additional design adjustments were needed in bothexisting and new classes.

Fig. 3. Command/parameter handling details, 2nd alternative.


6.2. Quantitative assessment

In this alternative implementation, we observed an iden-tical behavior for the metrics of adminsub package (seeTable 2) as that of the first alternative. Moreover, a similarbehavior to adminsub was observed for the misc pack-age. On the other hand, adding commands or parametersfor fictsub package makes it more cohesive. This isdue to the fact that all the command classes, which havedependencies towards the parameter classes but alsotowards the central class of the package, are now in thesame package. At the same time, it can be easily seen thatInstability is increased while Abstractness remains minimalsince only concrete classes are added, which leads to adecreasing Distance. In other words, the specific extension’scontribution is to strengthen the desired view of fictsubas not a responsible package (with respect to commandhandling functionality). On the other hand, it is worthnoticing that all packages, including fictsub, participatein cyclic dependencies.

On the class level, apart from the inevitable changes inmetric values we also observed some additional effects.Coupling between Objects (CBO) was increased for themain class (LEMonitor) due to the added reference tothe new package central class. Note that this increase isattributed to the extension of the ‘command’ instance ofthe pattern. The ‘parameter’ extension branch did not haveany such effect, since the Agent role is taken over by eachrelevant OAMCommand class and not by any existing class.So, no changes in class metric values are observed as aresult of adding Parameters. On the other hand, OAM-Command classes of the second alternative have inherentlyhigher coupling metric values compared with their firstalternative counterparts.

Yet another useful observation concerns the metrics ofthe new package central class (FictData). Due to theAgent role assigned to this class, it is necessary that theclass operates on Registrees (OAMCommands). This hasthe effect of increasing the CBO value for this class as morecommands belonging to the same package are added, in

Table 2Metric values on package level, second alternative



accsub 6 6 14 14 0.7 0.7 0.07 0.07 0.23 0.23 2.71 2.71 19 19adminsub 10 32 5 5 0.33 0.14 0.33 0.33 0.33 0.53 2.33 2.33 10 11misc 21 32 7 7 0.25 0.18 0.25 0.25 0.5 0.57 1.63 1.63 22 24snbsub 6 6 5 5 0.45 0.45 0 0 0.55 0.55 1.2 1.2 17 17traffsub 11 11 2 2 0.15 0.15 0 0 0.85 0.85 1 1 15 15fictsub 1 22 0.96 0 0.04 1.45 2

02468

1012141618

1 5 10Added commands

CB

O

fictdata (simple OO) fictdata (Registry with OO)

Fig. 4. Coupling between objects vs number of added commands.


contrast to the first alternative where CBO remains unaf-fected (Fig. 4). Of course, FictData is also coupled tothe Registry class, but obviously this is not affected bythe extension. Note that this is a coupling directed to aclass outside the package. The other couplings, which con-stitute the vast majority of the measured value for Fict-Data, might not be so critical for the reuse of thepackage, since they are directed within the same package.A similar coupling towards the Registry class is also intro-duced in classes assigned the Client role.

In general, we see that the application of Registry pat-tern has increased the CBO values for participating classes.Moreover, the specific extension, which adds ConcreteReg-

istrees, increases the CBO for the class assigned the Agent

role for them (like FictData).

7. Aspect-Oriented Programming

Aspect-Oriented Programming (AOP) is a relatively newapproach, which attempts to tackle the issue of crosscuttingconcerns (Tarr et al., 1999) in a software system. AOP buildsupon OOP, which it does not intend to replace but rathercomplement. For example, AspectJ (refer to The AspectJProject (2007), for a distribution of AspectJ and develop-ment tools), which is the language we used in our work, isa simple and practical aspect-oriented extension to Java.The main idea is to gather in one entity (the aspect), the func-tionality that concerns more than one OOP entities. Forexample, one can declare that a number of classes implement

a specific interface (without this being specified in the classes’declaration). Also, we can identify points in the execution ofan OOP program (point-cuts) and define actions that shouldbe carried out before, after or instead of what was about to beexecuted. A comprehensive explanation of AspectJ conceptscan be found in Colyer et al. (2004).

A common approach in AOP, when investigating possi-ble implementations of a design pattern (Hannemann andKiczales, 2002; Garcia et al., 2005), is to try to locate spe-cific interactions between the participants of the patternand check whether they could be formulated within anaspect. The interactions are defined in terms of the rolesof the participants, where each role can be an interfacedeclared in the aspect. Additionally, point-cuts can bedefined in an abstract way, while actions to be taken rele-vant to these point-cuts can be specified in concrete formin the aspect, thus formulating the interactions mentionedabove. This way, an abstract aspect is created, whichencapsulates the common characteristics and behavior ofparticipants of the pattern. Extending the abstract aspect,specifying the participating classes through intertype decla-ration, and concretizing the abstract point-cuts can then beused to create a specific instance of the pattern.

Therefore, AOP offers us a new level of abstraction. Justlike abstract classes give us the opportunity to collect com-mon characteristics and behavior of a specific class ofobjects within a single entity and allow inheriting classesto specialize them according to their own needs, abstractaspects encapsulate similar interactions between groupsof classes and allow inheriting aspects to specialize the‘‘interaction instance” according to the participants.

An interesting property of AOP is that it may be possi-ble to introduce functionality on top of the existing system,without having to impact it. Obviously, the same function-ality can be removed even more easily. This is a very usefulprospect, especially when a specific design turns out to bedifficult to manage, but direct operation on the existingclasses with the purpose of redesign is not feasible or istoo expensive.

8. Extending with Registry pattern implemented in AOP

In the third alternative implementation we introducedthe Registry pattern functionality with AOP techniques,using the first alternative as the core OO system. The new


functionality (including the AOP implementation of theRegistry pattern) was superimposed on the application,without any attempt to adapt the relevant parts of theexisting system (e.g. eliminate the comparsub packageor relocate the existing command and parameter classes),and therefore all the packages and their contents wereretained. This was done in order to demonstrate the possi-bility that AOP offers to smoothly integrate new features.The rationale behind this design decision is that we wantedto take advantage of the positive aspects of incorporatingthe Registry pattern while at the same time avoid impactson the core system.

We first tried to collect, in an abstract aspect, thosecharacteristics that would apply to all instances of the Reg-istry pattern.

More specifically, the abstract aspect (see Fig. 5) con-tains an inner class providing the Registry behavior, as wellas a Registry member variable (lines 4–21). Two inter-face definitions specify the Registree and Client roles whilea default implementation is given for the Regis-

tree.setRegistry method (lines 23–36).If we look at the pattern from interactions’ point of

view, we can identify a few points that could be encodedin the aspect. The registration of a specific Registree canbe done as soon as its pattern-related values becomeknown. This activity is common for all Agents, so we couldcollectively refer to it as fillUpRegistry and define itas an abstract method (line 60). Since the registrationsare different for each pattern instance, a concrete sub-aspect should implement this method depending on theRegistrees participating in the instance and taking into con-sideration the appropriate procedure to follow in order to

Fig. 5. The abstract aspect implem

ensure the availability of valid ‘key’ and ‘value to register’values to insert into the associations. At the same time, theregistrations must come before any relevant request from aClient. We can encode this behavior also in the abstractaspect, by defining abstract point-cuts corresponding tothe execution of Clients’ queries and replacing the originalClient response with a response derived with the assistanceof the pattern (lines 38–58). (Note that the Agent roledoes not have to be explicitly defined and assigned, sincethe relevant functionality is incorporated in the aspectitself)

A pattern instance is obtained by extending the abstractaspect (Fig. 6). The concrete sub-aspect will create aninstance of the Registry inner class and assign it to themember variable Registry (lines 4–7). Also, it willappropriately implement the methods that provide ‘key’and ‘value to register’ values (lines 11–17). Classes assignedthe Registree or Client role are declared as imple-menting the respective interface (lines 9, 27). The fillU-pRegistry method is implemented keeping in mind theconsiderations mentioned above (lines 19–25), and finallythe Clients’ point-cuts are defined accordingly (lines29-35).

It is useful to note that the Agent role is gathered in theaspect. If we think of the Agent role as a concern scatteredin the application, AOP has enabled its complete separa-tion from other concerns. Consequently, it is no longerneeded to ensure within the application, by the adjustmentof existing classes, that the registrations are done beforerelevant requests are placed, since the aspect takes overthe responsibility to perform the registrations whenevernecessary.

enting the Registry Protocol.

Fig. 6. The concrete aspect for command Registry.



The extension scenario for this version of the applica-tion coincides again with the addition of ConcreteRegis-

trees for the two Registry pattern instances. Theadditional implications to implement the extension comefrom the appropriate update of the two concrete sub-aspects representing these two instances. More specifically,the corresponding fillupRegistry methods need to beimpacted, to cater for the registration of the newConcreteRegistrees.2

With the incorporation of the Registry pattern usingAOP paradigm we have achieved the goal of having the flex-ibility to define the associations without limitations whilelimiting the impacts in just one entity of the system, the con-crete aspect. This was achieved due to the fact that the appli-cation of AOP has enabled the gathering in one location (theaspect) of all the scattered code excerpts relevant to the var-ious concerns of the Registry pattern. As with the previousalternative, different configurations, including or excludingcommands and parameters can be easily administered. Ofcourse, different concrete sub-aspects would be needed foreach one, but the procedure to configure them accordinglyis straightforward. Another important observation is thatthese benefits were obtained without having to alter any ofthe existing classes. Note, also, that the abstract aspect canbe reused in any other application.

2 It is logical to assume that any new command or parameter added willhave the same behavior in terms of defining the ‘key’ and ‘value to register’values.

8.2. Discussion on quantitative assessment

Several attempts have been made in the direction ofdefining metrics for aspect-oriented systems. A commonapproach is the adaptation of metrics initially proposedfor object-oriented design (like C & K metric suite, Chid-amber and Kemerer, 1994) to the concepts and constructsof aspect-oriented systems (Sant’Anna et al., 2003; Tsanget al., 2004). We believe that this approach might be mis-leading, since the association of specific metrics to qualityattributes may not be the same for both paradigms. Withinthis context it is useful to note that even for design patternsit has been argued that their application deteriorates thequality of the system from C & K metrics suite point ofview (Muraki and Saeki, 2001), even though it is generallyaccepted that the application of design patterns is a goodpractice.

For example, since an aspect aims at separating (isolat-ing) a certain concern (functionality) from the rest of theconcerns within a system, it could be argued that the bestapplication of Aspect-Oriented Programming would gatherall the code excerpts relevant to that concern in one location(the aspect), which would otherwise be scattered among sev-eral classes of the pure object-oriented system. Most prob-ably, this code scattering would impose dependencies(coupling) between the respective classes. Obviously, byrelieving all those classes of the code excerpts, the associatedcoupling would be eliminated by being moved into the newentity, the aspect. In other words, instead of having thoseclasses depend on each other, it is only the aspect that hasto maintain the dependencies. If separation of the specificconcern is a significant design goal for the system, this cou-pling between the aspect and the classes that it affects can-not be regarded as bad quality indicator, even though foran object-oriented system increased coupling would nor-mally be considered undesired.

In order to investigate the effect of the extension on var-ious quality attributes of the system, one approach couldbe to perform measurements on the pure object-orientedpart instead of collecting values for some of the proposedmetrics for aspect-oriented systems. The fact that the func-tionality implemented by aspects was superimposed in thespecific application would further justify this approach.

However, within the context of this work we adopted aninterim approach in order to investigate dependenciesbetween the various packages of the aspect-oriented sys-tem. We took the assumption that an aspect depends onanother component of the system if there is an explicit ref-erence to that component within the aspect code.

Following this approach, the measurements on packagelevel (Table 3) indicate a behavior which is a mixture ofthose observed in the first and second alternatives. This isdue to the fact that incorporation of the Registry pattern,even using AOP, gives the possibility to keep commandand parameter classes in their respective packages whileavoiding pattern-specific impacts on existing or addedclasses. So, the behavior of adminsub package has not

Table 3Metric values on package level, third alternative



accsub 6 6 12 12 0.67 0.67 0.08 0.08 0.25 0.25 2.92 2.92 18 18adminsub 12 34 1 1 0.08 0.03 0.33 0.33 0.59 0.64 2.2 2.2 0 0comparsub 2 2 4 4 0.67 0.67 0 0 0.33 0.33 0.25 0.25 7 7misc 14 14 9 9 0.39 0.39 0.21 0.21 0.4 0.4 1.84 1.84 19 19snbsub 7 7 3 3 0.3 0.3 0 0 0.7 0.7 1 1 15 15traffsub 11 11 2 2 0.15 0.15 0 0 0.85 0.85 1 1 13 13fictsub 2 22 0.92 0 0.08 0.55 0

Table 4Qualitative aspects and quantitative results observed when extending the application according to the examined scenario

Qualitative aspects Quantitative results

Specific knowledge on internalbehavior needed

Awkward applicationdeployment

Change on averagedistance

New packageis cyclic

Design alternative Simple OO Yes (classes’ adaptation tonaming pattern)

Yes (classes placed inspecific package)

+ 11.6% No

Registry OO Yes (classes’ adaptation toRegistry pattern roles)

No �6.07% Yes

Registry AO No No �10.67% No


changed in this third alternative either, while, obviously,the comparsub package remained unaffected. On theother hand, fictsub inherited most of the good charac-teristics from the second alternative, though it is a bit lesscohesive due to the Agent role being moved to the aspect.At the same time, cyclic dependencies were avoided forboth adminsub and fictsub packages.

On class level, the extension had the same inevitableimplications as those observed for the first alternative. Fur-thermore, even though the Registry pattern is used, cou-pling metric values are not increased for those classesacquiring a role in the pattern. As a result, the couplingmeasurements both for base classes and for classes ofnew fictsub package are less than the respective mea-surements in the second alternative (in fact, they are thesame as those of the first alternative). Of course, the addi-tional coupling is not exactly eliminated, but rather movedto the aspect serving as Registry pattern instance. The spe-cific functionality (i.e. the Registry pattern) inevitablyintroduces coupling. The implementation of the patternusing AOP has helped to make this coupling more manage-able by constraining it to a single entity.

9. Conclusive remarks

Designing software products in such a way that futureextensions can be easily incorporated, without affectingtheir quality attributes, is very important for their main-tainability. Adopting design patterns and Aspect-OrientedProgramming techniques may prove useful in this direc-tion, depending on the foreseen extension scenarios.

The case that additional administrative commands andassociated parameters are added to an existing software

application was investigated in the current work. Threealternative implementations were adopted and examined.Each of them was assessed in terms of the ease of expan-sion and quality metrics modification.

Table 4 summarizes the most important observationsfrom extending each alternative implementation:

The first alternative, which follows a simplistic solutionto the design problem of recognizing command and param-eter names, forces any new command and parameter classto adopt a specific naming pattern and to be included in aspecific package. This limitation does not promote the easeof expansion and may result in awkward provisioning ofdifferent customizations. Furthermore, couplings betweenthe new command classes and other classes in the modulerepresenting their functional area, which should remainwithin the package, are forced to also become dependenciesbetween packages. As a result, Distance from the MainSequence is increased on average.

The Registry pattern was proposed in order to overcomethis design limitation. The second alternative adopts thispattern, offering the required flexibility. However, thenew classes have to be adapted to the pattern roles. As aresult, the coupling metrics on class level for the relevantclasses were increased. On the other hand, these couplingsdid not have any significant adverse effect on the inter-package dependencies, and as a consequence the Distancefrom the Main Sequence was decreased, on average. How-ever, cyclic dependencies were introduced, whereas no suchdependencies were present in the first alternative.

In the third alternative, the Registry pattern was imple-mented using Aspect-Oriented Programming techniques. Itwas shown that the flexibility offered by the Registry pat-tern was retained, while keeping design impacts only within


the aspect. Measurements on the packages, assumingaspects depending on components they explicitly refer to,showed that they demonstrated a combination of the desir-able characteristics from both the previous alternatives.The additional coupling induced by the Registry patternwas concentrated in a single entity, the aspect.

References

Bengtsson, P., Lassing, N., Bosch, J., Vliet, H., 2004. Architecture-levelmodifiability analysis. Journal of Systems and Software 69 (1–2), 129–147.

Booch, G., 1994. Object Oriented Analysis and Design with Applications,second ed. The Benjamin/Cummings Publishing Company.

Chidamber, S.R., Kemerer, C.F., 1994. A metrics suite for object-orienteddesign. Proceedings IEEE Transaction on Software Engineering 20 (6),476–493.

Colyer, A., Clement, A., Harley, G., Webster, M., 2004. Eclipse AspectJ:Aspect-oriented Programming with AspectJ and the Eclipse AspectJDevelopment Tools. Addison Wesley Professional, Reading MA.

Fowler, M., 1999. Refactoring Improving the Design of Existing Code.Addison Wesley, Boston, MA.

Gamma, E., Helm, R., Johnson, R., Vlissides, J., 1995. Design Patterns:Elements of Reusable Object-Oriented Software. Addison Wesley,Reading, MA.

Garcia, A., Sant’Anna, C., Figueiredo, E., Kulesza, U., Lucena, C., Staa,A., 2005. Modularizing design patterns with aspects: a quantitativestudy. In: Proceedings of the 4th International Conference on AspectOriented Software Development, Chicago, Illinois USA, pp. 3–14.

Guide to the Software Engineering Book of Knowledge (SWEBOK),Version 2004, <http://www.swebok.org>.

Hannemann, J., Kiczales, G., 2002. Design pattern implementation inJava and AspectJ. In: Proceedings of OOPSLA’02, Seattle, Washing-ton USA, pp. 161–173.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C.,Loingtier, J., Irwin, J., 1997. Aspect oriented programming. In:Proceedings of ECOOP’97, LNCS 1241, Finland, pp. 220–242.

Kulesza, U., Sant’Anna, C., Garcia, A., Coelho, R., Staa, A., Lucena, C.,2006. Quantifying the effects of aspect-oriented programming: amaintenance study. In: 22nd IEEE International Conference onSoftware Maintenance (ICSM’06), September 2006, pp. 223–233.

Martin, R.C., 2003. Agile Software Development: Principles, Patterns,and Practices. Prentice Hall, Upper Saddle River, NJ.

Muraki, T., Saeki, M., 2001. Metrics for applying GOF design patterns inrefactoring processes. In: International Conference on Software Engi-neering, Proceedings of the 4th International Workshop on Principlesof Software Evolution, Session 2, Vienna, Austria, pp. 27–36.

Nordberg, M.E., 2001. Aspect-oriented indirection – beyond object-oriented design patterns. In: OOPSLA 2001 Workshop ‘‘BeyondDesign: Patterns (mis)used”, October 2001.

Papapetrou, A., Papadopoulos, A.G., 2004. Aspect Oriented Program-ming for a component based real life application: a case study. In:Proceedings of the 2004 ACM symposium on Applied computing,SESSION: Software engineering: applications, practices tools (SE),Nicosia, Cyprus, pp. 1554–1558.

Pressman, R.S., 2004. Software Engineering, A Practitioner’s Approach,sixth ed. Mc Graw Hill Inc, New York.

Sant’Anna, C., Garcia, A., Chavez, C., Lucena, C., Staa, A., 2003. On thereuse and maintenance of aspect-oriented software: an assessmentframework. In: Proceedings of Brazilian Symposium on SoftwareEngineering (SBES’03), Manaus, Brazil, pp. 19–34.

Sommerlad, P., Ruedi, M., 1998. Do-it-yourself reflection. In: Proceedingsof the 3rd European Conference on Pattern Languages of Program-ming and Computing, Bad Irsee, Germany.

Tarr, P., Ossher, H., Harrison, W., Sutton Jr., S.M., 1999. N Degrees ofseparation: multi-dimensional separation of concerns. In: Proceedingsof the 21st International Conference on Software Engineering,ICSE’99, LA, California, pp. 107–119.

The AspectJ Project, 2007. <http://www.eclipse.org/aspectj>.Tsang, S.L., Clarke, S., Baniassad, E., 2004. An evaluation of aspect-

oriented programming for Java-based real-time systems development.In: Proceedings of the IEEE 7th International Symposium on Object-Oriented Real-Time Distributed Computing, pp. 291–300.

Konstantinos G. Kouskouras received the Diploma in Computer Engi-neering and Informatics in 1994 from University of Patras, Greece and theMS degree in Information Systems in 2003 from University of Macedonia,Thessaloniki, Greece. Since 1997 he has been with Intracom Telecom S.A.Greece as senior telecommunications software engineer. In 2004 hebecame a PhD candidate in the Department of Applied Informatics at theUniversity of Macedonia, Thessaloniki, Greece. His current researchinterests include software evaluation and quality metrics for Aspect-Ori-ented Programming.

Alexander Chatzigeorgiou received the Diploma in electrical engineeringand the PhD degree in computer science from the Aristotle University ofThessaloniki, Greece, in 1996 and 2000, respectively. He is an assistantprofessor of software engineering in the Department of Applied Infor-matics at the University of Macedonia, Thessaloniki, Greece. From 1997to 1999, he was with Intracom S.A. Greece as a telecommunicationssoftware designer. His research interests are in object-oriented design,design patterns and software metrics. He is a member of the IEEEComputer Society.

George Stephanides received the PhD degree in applied informatics fromthe University of Macedonia. He is an associate professor in theDepartment of Applied Informatics, University of Macedonia, Thessalo-niki, Greece. His current research and development activities are in theapplications of mathematical programming, security and cryptographyand application specific software. He is a member of the IEEE ComputerSociety, ACM and SIAM.

http://www.swebok.org

http://www.eclipse.org/aspectj

Documents

Facilitating software extension with design patterns and Aspect-Oriented Programming