Designing for Extensibility:An action research study of maximizing extensibility by means of design principles

Niklas JohanssonAnton Löfgren

Bachelor of Applied Information Technology Thesis

Report No. 2009:053ISSN: 1651-4769

University of GothenburgDepartment of Applied Information TechnologyGothenburg, Sweden, May 2009

Designing for extensibility:An action research study of maximising extensibility by means of design principles.

Niklas Johansson

IT University of Gothenburg

Software Engineering and Management

Gothenburg, Sweden

jonikl@ituniv.se

Anton Löfgren

IT University of Gothenburg

Software Engineering and Management

Gothenburg, Sweden

antonl@ituniv.se

Supervisor: Carl Magnus Olsson

IT University of Gothenburg

Software Engineering and Management

Gothenburg, Sweden

carl.olsson@ituniv.se

May 29, 2009

Abstract

This paper presents an action research study on how a set of design principles applicable to object orientedlanguages can be used to counteract code rot and consequentially enhance system extensibility. The studydescribes how these principles help support the system quality attributes of modifiability, maintainability andscalability, as well as how these quality attributes correlate to extensibility. Furthermore, it also elaborates on therelationship between extensibility and code rot and how the absence of the first can lead to the latter. The studythus contributes by illustrating how a design science approach can be useful in action research.

Keywords: Action research, design science, extensibility, code rot.

1 Introduction

Our society today is overflowing with data and infor-mation about everything and nothing. The Internethas enabled us to do things with a computer whichwe could only dream of just a couple of years back.The technology we use has also evolved over this timeas new concepts emerge and become widely used. Tokeep up, developers must accept and embrace the factthat systems need to be extended in order to survive.However, not all systems developed with an intent offuture extension, extend gracefully. The concept of

designing for change has been around since the late1970s[1]. By this time, many companies were spend-ing big parts of their software budgets on maintenanceand that number has been growing ever since[2]. Par-nas suggests a set of techniques to design for changewhich include ”Information Hiding“ and the identifica-tion of subsets within the design[1]. Others have sincethen approached the problem from a more practicalpoint-of-view and have implemented libraries and ex-tensions for programming languages to tackle the prob-lem area of extensible software[3][4]. This study pro-poses a set of design principles which, when applied,

1

should have a positive effect on the way software sys-tems react to extension and modification. We also makeuse of a real life example where the application of ourdesign principles are implemented into a system whereextensibility is a primary goal in order to test the valid-ity of our proposal.

The real life example is the development of a systemnamed Metabolism. This system will be implementedby the authors to begin with. Metabolism’s main pur-pose is to map the relations between Free/Libre OpenSource Software (FLOSS) development trends and theevents that trigger them. For example, what happens tothe development within the competing desktop man-ager projects Gnome1 and KDE2, when one releasesa new stable version of their system. To do this, theidea is to collect data from the respective projects coderepositories and observe around what times the de-velopment activity peaks, and based on that, look forevents that occurred around that date. The data is thenpresented through a web-based presentation layer. Toinvolve and capture the users attention the real lifeevents will be gathered by the system, but the userswill themselves have influence on what events theyfind the most likely to have set off any fluctuation inactivity. This system is being developed in close col-laboration with the Free Software Foundation Europe(FSFE) 3 and the GNU project4. We have been workingwith people from both FSFE and GNU and communi-cation through meetings have been held on a weeklybasis. This provides a good environment in which toapply action research. Since we have been workingwith both GNU and FSFE all the software producedwithin this project will be released under the GNUGPLv3 license[5] and the system is written completelyin Python.

1www.gnome.org2www.kde.org3http://www.fsfe.org/4http://www.gnu.org/

2 Problem Area

2.1 Code Rot

A system built from a design that has not taken intoappropriate consideration the elements of evolutionand extensibility, may well become victim to the phe-nomenon known as ”code rot“ or ”design rot“ and maybecause of this ultimately be abandoned as the systembecomes too hard to maintain and extend. Having tochange a system for new features, patching old fea-tures, cleaning up obsolete features or even supply acustomer with a specified product is all costly work,and it may become even more costly as every changemay introduce new problems in the form of bugs andviolations of system design.

Martin[6] identifies the following four, non-orthogonal, symptoms of rotting design;

• Rigidity - The software tends to be difficult tochange. Changes made requires changes to bemade in dependent modules as well.

• Fragility - The software tends to break in manyplaces when it is changed.

• Immobility - The software tends to make it difficultto reuse software parts, both from other projects aswell as the same project.

• Viscosity - The software tends to make it harder toemploy design preserving methods than methodsthat do not preserve the design.

The purpose of this study is to identify and assess anumber of suitable design principles to minimise therisk for code rot, as a proof-of-concept enabling theobtaining of both practical experiences and theoreticalreflection. We are however aware of the fact that soft-ware systems can not be kept sane by the influence ofdesign principles alone, and wish to make clear that weare not suggesting this approach as a ”Silver Bullet“[7]solution. Other factors also influence the life of a soft-ware project, such as its developers dedication to fol-low the set design or its managers willingness to al-low for the design to be followed (i.e. to not stress de-velopment in ways that make it hard for developers toadhere to the design without falling behind schedule).

2

Even so, we believe that the application of and dedica-tion to a reasonable set of design principles may wellincrease the success probability of a software project interms of design and code rot avoidance.

2.2 Extensibility

In order to avoid code rot, software needs to be de-signed with the goal of extensibility in mind. We defineextensibility as the ability of a system to be extendedwith new functionality with minimal or no effects on itsinternal structure and data flow. The quality attributespresented below are the core contributing factors toextensibility as a system property. Each design prin-ciple suggested in this study is related to one or moreof those quality attributes in order to achieve the finalpurpose of extensibility.

To be able to approach the problem of identifyingsuitable design principles for extensible software, wehave started out by identifying the most importantquality attributes of such a software system. This studylooks in particular at the role of the following threequality attributes as means for the development of de-sign principles useful for acquiring extensibility;

• Modifiability

• Maintainability

• Scalability

Thus identifying that our focus would be to find andapply design principles that supported modifiability[8],maintainability[9] and scalability[10] as well as possi-ble. One could argue that there are more quality at-tributes that needs to be considered for this study inorder to cover the whole spectrum that constitutes ex-tensibility. We agree that there are several other qualityattributes that benefit extensibility in some way. Wehave however so far identified the quality attributespresented here as the primary influences on extensi-bility, and have for this reason decided to focus on onlythese three for this study. Furthermore, the time framewe have disables us from testing every possible qual-ity attribute. The sections below will further explainthe quality attributes and their definitions. It will alsopresent what design principles map to each quality at-tribute.

2.3 Modifiability

Modifiability as defined by Bass, Clements andKazman[8] is determined by how functionality is di-vided architecturally and by how coding techniques areapplied within the code. A system is modifiable whena change involves the least number of changes to theleast number of possible elements. We interpret thisas striving towards high cohesion5 and low coupling6

within the code. We chose modifiability after discus-sions with our industry contributors and what was envi-sioned about the systems characteristics. We identifiedthat one of the most important things to think aboutis that to get support from the community and to getother people contribute to the development one musthave code that is easy to modify. If the code is hard toread and understand it is less likely that other devel-opers will take interest in helping the development fur-ther. It is also of high importance to be able to conformto new standards and other new inventions. Alfonzoet al. argue that, for these reasons, FLOSS tools mustbe built so that it is as easy to modify and maintainas possible[11]. Figure 1 shows the relation betweenthe quality attribute modifiability and the set of designprinciples intended to support modifiability. The de-sign principles shown in figure 1 will be presented inSection 2.6.

Figure 1: Principles identified to support Modifiability

5Cohesion describes how well defined and focused each modulesresponsibility is.

6Coupling describes the level of dependency one program modulehas to other program modules.

3

2.4 Maintainability

Maintainability is similar to Modifiability, but we seea distinct difference between the two in their defini-tion. Maintainability as defined by Sommerville[9], isto design a system to allow for the addition of new re-quirements without risk of adding new errors. We findthat these two quality attributes used together com-plete each other rather than having the same purpose.This also requires the code to have high cohesion andlow coupling. We also interpret this as having to takeripple effects into serious consideration, as adding fea-tures and correct errors should not raise the risk ofadding new errors. Having high maintainability pro-vides a higher probability of a smoother future for thedevelopers and maintainers of a project. In this casespecifically since the code is to be released as free soft-ware, it needs to be maintainable for the project to haveany chance at all of success[11]. Figure 2 presents therelation between the quality attribute maintainabilityand the set of design principles found to support main-tainability.

Figure 2: Principles identified to support Maintainabil-ity

2.5 Scalability

Scalability as defined by Bondi[10], is ”the ability of asystem to expand in a chosen dimension without ma-jor modifications to its architecture“. As our intendedsystem implementation has a user interface that shouldbe presented as a web page, and taking the possiblegrowth of data sources into consideration, this brings

forth a set of new problems. For example, what hap-pens if the user load is higher than we had initially ex-pected or that the amount of data that the system needsto harvest is much larger than expected. This presentsan obvious need for a scalable system. Scalability istherefore deemed one of the three quality attributes ofhigh importance. Having scalability provides the sys-tem with a good possibility to grow if needed. It canbe the difference between success and failure. Kras-ner published an article about typical design problemsin Enterprise Resource Planning systems[12] in whichhe argues that users will not be pleased with havingto wait for the system to react to their input, and thatthese problems can be avoided with proper scalabil-ity. When providing a good possibility for scalability,one also opens up for better extensibility by makingthe system adaptable for many different configurations.Figure 3 presents the relation between the quality at-tribute scalability and the set of design principles in-tended to support scalability.

Figure 3: Principles identified to support Scalability

2.6 Design Principles

When we first set out to identify this particular set ofdesign principles we found that Martin[6] had pro-posed a large set of principles. Some of which are moreinteresting for use in our work than others. Thus someof the principles Martin presents have been used, butsome have been excluded. Furthermore Martin doesdiscuss the Liskov Substitution Principle[13] as well.This study will test Martin’s principles with a set ofother principles as complement. The reason we chosenot to use all of Martin’s principles is that we find theset of principles we present more suitable for the pur-pose of this study. We also find it impossible to takeinto consideration every principle available because of

4

the time frame we have available to carry out this study.The set of design principles this study proposes hasbeen chosen primarily for the purpose of providing ex-tensible software and avoid symptoms of code and de-sign rot. We see the chosen set of design principles as agood combination to design for extensibility. Below isa list of the chosen principles;

• P1: Liskov Substitution

• P2: Open-Closed

• P3: Modularity

• P4: Don’t Repeat Yourself

• P5: Dependency Inversion

• P6: Interface Segregation

• P7: Law of Demeter

These principles will be further explained in their re-spective paragraph below.

P1: Liskov SubstitutionLiskov Substitution as first presented by Barbara

Liskov[13] and refined by Martin[6], is a principle usedfor easy substitution of one class to a derived class ofthe same type. So if we want to change class A to anobject of class B, class B must be a subtype of classA and provide the necessary methods and signatures.This will for example be applied with the aim to cre-ate a plug-in like mechanism for the collection of datafrom the code repositories of the projects. The idea isthat we will create an overall interface with a standard-ised set of methods which all plug-ins of this kind mustimplement in order to function with the system. And bydoing this it will be easy to add functionality for newversion control systems. By using this we are rewardedwith both an increase of maintainability and modifia-bility through the ability to control where changes hap-pen as well as extensibility through the use of a strictdesign to make it easy to add new classes to the imple-mentation.

P2: Open-ClosedThe purpose of Open-Closed is to extend a module

without changing the already existing code, as first pro-posed by Meyer[14] and later, refined by Martin[6].Martin defines the principle as ”A module should beopen for extension but closed for modification“. Theapplication of this principle will be used to control thestability of the system in a post-release state whereworking code should not be tampered with, if not ab-solutely necessary. We argue that the only time youshould touch ”working“ code is if it is not working.Doing so anyway only increases the risk of introduc-ing unnecessary bugs and errors, thus digging a deeperhole for yourself to climb out of. Furthermore its ap-plication will strengthen the use of Liskov Substitutionby complementing its purpose to increase maintainabil-ity and modifiability, thus increasing the extensibility ofthe software.

P3: ModularityBooch defines modularity as ”[...] the property of a

system that has been decomposed into a set of cohesiveand loosely coupled modules.“[15] In addition, Lar-man suggests that ”(at object level) we achieve mod-ularity by designing each method with a clear, singlepurpose and by grouping a related set of concerns intoa class.“[16]

Even though modularity is sometimes considered aquality attribute, we have chosen to include it in our setof design principles for a couple of reasons. First off,we believe it provides developers with enough practi-cal guidance to constitute a principle in this case. Also,after consultancy with our industry collaborator, mod-ularity did not fit into the quality attributes that wererequested, which convinced us even further to includeit in our design principle set. Furthermore, the use ofmodularity also provides the system with a means ofbeing scalable, since one module can be easily replacedif needed. Not only scalability gains from the use ofmodularity, but maintainability and modifiability too.Having a system designed in a way that allows the ex-change of modules easily makes it easier to both modifyand maintain.

5

P4: Don’t Repeat Yourself (DRY)Hunt and Thomas[17] defines the DRY principle as

follows;”Every piece of knowledge must have a single, unam-

biguous, authoritative representation within a system.“The thought is that by adhering to this principle, the

system being developed will be both easier to maintainand to understand. By not having the same informationexpressed in multiple places, developers do not haveto keep track of all the places where that informationis expressed. As a consequence, developers need notworry about breaking the system by changing the in-formation. The principle applies to all aspects of a soft-ware project, including specifications and documenta-tion, processes and programs. Applying this principlelimits the places where you have to change code to cor-rect errors and lowers the risk of introducing new bugsand causing a ripple effect. Thus increasing modifia-bility and maintainability through the application of astrict code structure. Furthermore it enhances the pos-sibility to reuse the code.

P5: Dependency InversionDependency Inversion is a principle proposed by

Martin[6], which implies that one should depend uponabstractions rather than upon concretions. The strat-egy is to depend upon interfaces rather than the actualimplementation of the interface. Which provides thepossibility to easily exchange, for instance, faulty im-plementation to correct implementation without hav-ing to change the code that depends upon the inter-face. This further complements the use of both LiskovSubstitution and Open-Closed. It also provides a goodstructural basis for the treating of inheritance and ab-stract classes. Being able to exchange modules, classesand other code entities brings forth a better growingground for maintainability and modifiability.

P6: Interface SegregationMartin also proposes Interface Segregation[6],

which is used to further structure the use of interfacesand abstract classes. Martin suggests that when morethan one client class accesses the same service (thatcontains client specific methods and functions) eachclient should be assigned its own interface to this ser-

vice. The application of this principle will render thecode easier to change and maintain, thus supportingboth maintainability and modifiability. It also createsa more readable code structure which is always goodwhen you expect other people to contribute to the codebase. Furthermore it allows further support to the ap-plication of Law of Demeter (see below).

P7: Law of DemeterThe Law of Demeter as propounded by Lieberherr,

Ilolland and Riel in 1988[18] implies that software en-tities should only speak directly to their closest neigh-bour. This can be simplified into saying for example,that when you drive a car you accelerate by pressingthe gas pedal and not by telling your motor directly tothrottle. Another example would be that you use thesteering wheel to turn your car, and not by telling eachindividual wheel directly to turn a certain amount. Ap-plying the Law of Demeter, the design will be tightlyconnected to the flow of data, making it easier to iden-tify which parts of the system that should be responsi-ble for what tasks. This also makes it easier to iden-tify flaws in the design while implementing. This willof course lead to redesign, but we believe that this isa better option than to be stuck with a system that isfaulty by design.

Principle MapFigure 4 describes how the design principles are used

to support the quality attributes and how the qualityattributes ultimately is intended to support the idea ofextensibility. We can see that some of the design prin-ciples are used to support both modifiability and main-tainability. This is a result of the likeness between mod-ifiability and maintainability, where some of the designprinciples gives advantages to both purposes. Moreoverthe need for high cohesion and low coupling are strongin both these quality attributes and therefore principlesthat enable these two practical advantages all are con-sidered to support these quality attributes. The sortingof the design principles does not imply any differencein importance, but is only a means of making the mapmore readable.

To understand the importance of each branch in themap one should read from left to right. This is how we

6

have thought when developing this set of design prin-ciples. After discussions with our industry collaboratorwe came to the conclusion that we wanted a systemthat was extensible and by this we identified the qual-ity attributes that help us accomplish this. From thesequality attributes we looked at possible design princi-ples to support each of them. As mentioned above ithas been identified that some of the principles supportonly one quality attribute, whilst other support two oreven all of the quality attributes.

Figure 4: Design Principle Mapping

3 Research method

3.1 Action Research

The research was carried out in an iterative manner, inorder to allow us to refine our set of design principlesto further investigate the correctness of our choices.In short, our research model resembles that of actionresearch as defined by Susman [19]. This process isalso illustrated in figure 5. Our use of action researchhas been adapted in order to fit the rather narrow timeframe given to this research project. The practical im-pact this deviation has had is that a smaller number ofiterations has been used rather than what is usual inaction research. All cycles of the research process hasthus not be considered in our research. The advantagesgained from using the action research model has how-ever outweighed the fact that this project did not matchthe template perfectly. O’Brien states that;

”Participants in an action research project areco-researchers. The principle of collabora-tive resource presupposes that each person’s

ideas are equally significant as potential re-sources for creating interpretive categories ofanalysis, negotiated among the participants.It strives to avoid the skewing of credibilitystemming from the prior status of an idea-holder. It especially makes possible the in-sights gleaned from noting the contradictionsboth between many viewpoints and within asingle viewpoint.“[20]

This suited our research project well since a largeamount of industry collaboration comes naturallyto the research we have performed. Furthermore,Baskerville suggests that ”Action research is empiri-cal, though the collected data is typically qualitativeand interpretive“[21], thus also supporting the way inwhich we have collected and analysed our data as ispresented in section 4.

Additionally, we will present examples of how ourdesign principles have influenced the actual design ofthe system at a practical level in order to further illus-trate their impact.

Translated into terms of our research project, thephases present in the research model shown in figure 5are what we worked from. These activities are furtherdescribed in their respective subsection in this chapter.

Figure 5: Action research model (adapted from [19])

7

3.2 Diagnosing

During the diagnosing phase we had already estab-lished good interaction with our industry collaborators.We had set up weekly meetings for communicating thework that had been done and what we were currentlydoing as well as planning for the next step. These meet-ings also served as a kind of acceptance meeting for anychanges that had come up as our work progressed. Fur-thermore, we identified modifiability, maintainabilityand scalability as good quality attributes to use whendesigning for extensibility.

3.3 Action Planning

This phase was used primarily to identify which designprinciples we saw fit for the purpose of providing exten-sibility and thus counteract code rot. We spent a largeamount of time studying the related research and try-ing to come to terms with where the design principleswould fit in, and to what extent they would be useful.Moreover, we looked at possible frameworks to help usachieve the purpose of our application.

3.4 Taking Action

The taking action phase was used to create and refinethe system design, the architecture and to implementthe application. We based our design and implemen-tation upon the design principles we identified in theaction planning phase. The architecture can be seen infigure 3.4. When the design and architecture was com-plete and perceived as embodying the design principlesidentified in the action planning phase, we proceededto implement the system.

3.5 Evaluating

The evaluating phase was used for interviews. We in-vited a group of experts to assess our design and thespecific implementation of the principles. We receivedoverall positive results (described in better detail in sec-tion 4.1). Furthermore, we reflected over how well wecould see our design principles working ourselves. Asan example of this, we can highlight the bug fixing pro-cess. Mostly we only had to change code in one mod-

ule to fix bugs. Thus, showing that ripple effects hadbeen prevented in a good manner. We also reflectedupon our choice of programming language for the im-plementation. We had chosen Python, as we had someprior knowledge of the language and had found thatPython oftentimes gives a rapid development process.The time it took us to implement big parts of the sys-tem was also surprisingly short to our customer. Thisallowed us to spend more time on refactoring and re-fining the code base7.

3.6 Specifying Learning

In this phase we analysed the results from the inter-views conducted during the evaluating phase. We alsoreflected upon what we had learned throughout of allof the prior phases. We looked at what could be im-proved for the next cycle in terms of design principles.Furthermore, Walsham[22] states that there are fourdifferent types of information system research general-isations.

• Development of concepts

• Generation of theory

• Drawing of specific implications

• Contribution of rich insight

We found ourselves in between two of these fields, inparticular Drawing of specific implications and Contri-bution of rich insight. We do not contribute with richinsight directly, but most of our work is based on priorrich insight contributions from other authors. This isspecifically true for the various design principles pre-sented in this study. We do on the other hand con-tribute directly with the relationship between our de-sign principles and the system property of extensibility.

4 Analysis and Discussion

To evaluate whether our principles have had a positiveor negative impact on the system, we have conductedinterviews with potential extenders of the system. We

7Available at: http://itupw056.itu.chalmers.se/metabolism_docs/

8

Figure 6: System architecture

analysed their answers in order to find flaws in any as-sumptions we have made about what constitutes goodextensible software systems as well as any shortcom-ings in our design principle set. We have also carriedout experiments to test the extensibility of the systemin order to directly test its extension capabilities. Theseexperiments have been on a software testing level. Wehave investigated the use of other modules and pack-ages, and their effect on our system’s performance.This may also come into use when proving the mod-ularity of the system. We have made use of test-drivendevelopment (TDD) as described by Beck[23] in orderto easily detect system breakage when performing ex-tensibility experiments. Test results have thus given usadditional indications as to whether our system is easyto extend or not.

For the purpose of comprehensiveness of this study,we have chosen to analyse only a subset of the mod-ules of the system. A diagram of this subset is shown infigure 7 in Appendix A. This particular subset has beenchosen because these modules form the foundation ofthe system and are as such the most likely target for

significant extension. We see an extension as signifi-cant when it provides the system with new functional-ity that changes the scope or alters the requirements ofthe system. This module controls the interaction withproject source code repositories, and it is responsiblefor the gathering of project data.

To reiterate, we have used a mixed approach to datacollection in our research project. Both qualitative andquantitative data have been collected and analysed inorder to get a more holistic view of our results. Ourdata collection and data analysis relates to the use ofaction research in the sense that many data sources wasused. Since we were only performing one cycle of theaction research method in the scope of this project wecan make use of the information gathered from the datawhen developing the system further.

In order to minimise violations of the DRY principle,we made use of a tool, Clone Digger8, that detects andreports on duplicated and cloned code segments, e.g, acertain method being called with the same arguments

8http://clonedigger.sourceforge.net

9

from several different, unrelated points in the program.The tool achieves this by using various algorithms pre-sented in [24]. We have analysed the output from thistool regularly in order to find such violations at an earlystage, enabling us to refactor duplicate segments intocleaner methods and classes and achieving a better ad-herence to the DRY principle. Clone Digger grades theclones by a factor where one is segments that are iden-tical to each other. These identical segments have beenactively located and refactored throughout the devel-opment to adhere to the DRY principle. This is hasproven very powerful since each person contributing toa project can not have a perfect understanding of whatother developers are producing.

During the development, it became evident that theprinciple of Dependency Inversion was not applicablefor the specific implementation we present here. In ourcase, third-party tools largely handled the parts wherethis principle normally would have been applied. Wenevertheless feel that this principle is relevant for con-sideration, but it highlights an important factor still -that design principles may not all be directly applica-ble for implementation, as long as they are seriouslyconsidered.

4.1 Interviews

In order to validate that all applicable design principleshad been applied in an adequate manner, we askedthree different industry experts to evaluate the afore-mentioned module subset. As we have already dis-cussed, the principle of Dependency Inversion is notpart of this evaluation. Nor did we ask the industryexperts to evaluate the application of the Open-Closedprinciple as it is not a suitable target for static evalua-tion. Since our interpretation of the Open-Closed prin-ciple is that it should be applied once the code has beenfunctionality tested and released it is only used post-release. The system built during this study has not yetreached a state where it can be considered ready forrelease and we see Open-closed as a principle to be ap-plied in the future. For each of the applicable designprinciples, we asked the experts to rate their agree-ment level with the statement; "The design principleis applied well to the software module" on a scale fromone to five (a rating of one meaning "strongly disagree"

and a rating of five meaning "strongly agree"). The re-sults of this analysis are shown in table 1. The tableshows that the experts generally consider the designprinciples to be well implemented, even though thereare a few deviations. Expert 1 considers all of the de-sign principles except for DRY to be well implemented.The expert however comments that Liskov Substitutionmay be somewhat hard to evaluate due to ”the smallamount of inheritance on the same "level"“. Expert 1also suggests that there are hidden duplication presentin the module subset in the form of different functionsperforming the same tasks, thus violating the DRY prin-ciple.

Expert 2, on the other hand, did not find any viola-tions of the DRY principle. The expert however com-ments that he had trouble finding any examples of theimplementation of Interface Segregation. The expertalso mentions that the reason for his grading of four onModularity stems from a number of static attributes inone of the classes. He infers that this leads to a higherlevel of coupling than necessary. Additionally, this ex-pert has graded the Liskov Substitution principle lowerthan any of the other experts in this study but has notprovided any further explanation as to why this is. Ex-pert 2 furthermore proposes the future considerationof the Dependency Injection[25] principle, a principlewhich is quite similar to Dependency Inversion, as theyare both inversion of control principles.

In the light of these results, the answers given byExpert 3 may be somewhat surprising. It is hard to sayhow this deviation in grading came to be, since no com-ments on the specific design principles were provided.Expert 3 did on the other hand provide general com-ments. He states that from his own experience the useof these design principles or any design principles forthat matter, should be considered separately for eachproject you find yourself working on. Thus basing thedecisions on what the future holds for each system in-dividually. This is a good point indeed, and we fullyagree that there are no perfect set of design principlesto use for each project or product.

Two of the experts also commented on the use of de-sign principles in general and offered some insight onthe subject. Similarly to what was suggested in section2.1, they believe that the sanity and success of a soft-ware system is not solely dependent on design princi-

10

Table 1: Inquiry resultsSubject Liskov Substitution Modularity DRY Interface Segregation Law of DemeterExpert 1 5 5 3 5 5Expert 2 3 4 5 3 5Expert 3 5 5 5 5 5

ples but rather on the individual assessment of what isneeded for each project and product. There was alsocomments discussing the pace at which the field of in-formation systems development moves, and that thiswould present a problem for the application of the kindof solutions presented in this article. We do not neces-sarily agree to this statement, since this proposition isnot in any way language or system specific. Our im-plementation has been done exclusively in the Pythonprogramming language, but the theories should be ap-plicable to any object oriented language.

5 Conclusion

We find that our implementation of the proposed de-sign principles is to be considered successful. The re-sults of the expert inquiry shows that there are differentopinions to the level of how well each principle wereimplemented. But since all principles that were investi-gated by the experts have an overall result that is posi-tive we interpret the results of the inquiry as positive. Ithas also become apparent that each project and prod-uct has its own set of needs, thus rendering each projectin some way unique. This has to be considered whenmaking design decisions but the set of design principleswe propose in this article is a good starting point whenstriving towards extensibility. As has become evidentfrom the implementation presented in this paper, notall of the suggested design principles fit the scope ofall projects. However, as long as all principles are se-riously considered, this set carry several advantages byreducing the risk for code rot when developing a sys-tem that may require future extension. The researchupon which this study has been based, in particular thedesign principles have already proven the advantagesgained when the specific principles are applied. We aretherefore confident that this set of principles carry a

good ground for extensibility.The natural step for the next cycle of this research

is to look at the design principles that did not apply tothis study and study their appropriateness further, aswell as extend the application. Extension for the ap-plication would include, but are not limited to, supportfor other repository systems and an open API for ex-ternal resources. The reason for an open API is thatit would be interesting to see if the design principleswould have an effect on how well an API evolves overtime. The system that was produced during this studyis still in early development, but support for Subversionrepositories has been added and is functional. Somescreenshots of the alpha version can be found in Ap-pendix B.

References

[1] D. Parnas, “Designing software for ease of exten-sion and contraction,” IEEE transactions on soft-ware engineering, pp. 128–138, 1979.

[2] J. Koskinen, “Software MaintenanceCosts,” 2003. Acessed 2009-04-06 at:http://www.cs.jyu.fi/ koskinen/smcosts.htm.

[3] L. Tokuda and D. Batory, “Automated softwareevolution via design pattern transformations,” inProceedings of the 3rd International Symposium onApplied Corporate Computing, 1995.

[4] M. Zenger, “Evolving software with extensiblemodules,” in International Workshop on Unantici-pated Software Evolution, 2002.

[5] F. S. Foundation, “GNU General Public Li-cense,” 2007. Accessed 2009-04-06 at:http://www.gnu.org/licenses/gpl.txt.

11

[6] R. Martin, “Design principles and design pat-terns,” Object Mentor, 2000.

[7] F. Brooks, “No silver bullet: Essence and accidentsof software engineering,” IEEE computer, vol. 20,no. 4, pp. 10–19, 1987.

[8] L. Bass, P. Clements, and R. Kazman, Softwarearchitecture in practice. Addison-Wesley Profes-sional, 2003.

[9] I. Sommerville, Software Engineering 8. Addison-Wesley Professional, 2007.

[10] A. Bondi, “Characteristics of scalability and theirimpact on performance,” in Proceedings of the 2ndinternational workshop on Software and perfor-mance, pp. 195–203, ACM New York, NY, USA,2000.

[11] O. Alfonzo, K. Domínguez, L. Rivas, M. Pérez,L. Mendoza, and M. Ortega, “Quality Measure-ment Model for Analysis and Design Tools basedon FLOSS 19th Australian Software EngineeringConference (ASWEC 2008),” in Proceedings of the19th Australian Software Engineering Conference(ASWEC 2008), vol. 1, pp. 258–267.

[12] H. Krasner and K. Consulting, “Ensuring e-business success by learning from ERP failures,”IT Professional, vol. 2, no. 1, pp. 22–27, 2000.

[13] B. Liskov, “Data abstraction and hierarchy,” 1987.

[14] M. Bertrand, Object oriented software construc-tion. Prentice Hall, 1988.

[15] G. Booch, Object-oriented analysis and design.Addison-Wesley Reading, MA, 1996.

[16] C. Larman, Applying UML and patterns: an intro-duction to object-oriented analysis and design anditerative development. Prentice Hall PTR UpperSaddle River, NJ, USA, 2004.

[17] A. H. et al., The Pragmatic Programmer: FromJourneyman to Master. Addison-Wesley Profes-sional, 1999.

[18] K. Lieberherr, I. IIolland, and A. Riel, “Object-oriented programming: An objective sense ofstyle,” 1988.

[19] G. Susman, “Action research: a sociotechnical sys-tems perspective,” Beyond method: Strategies forsocial research, pp. 95–113, 1983.

[20] R. O’Brien, “An overview of the methodologicalapproach of action research,” Unpublished paperto Professor Joan Cherry, Course LIS3005Y, Facultyof Information Studies, University of Toronto. April,vol. 17, 1998.

[21] R. Baskerville, “Investigating information systemswith action research,” Communications of the AIS,vol. 2, no. 3es, 1999.

[22] G. Walsham, “Interpretive case studies in IS re-search: nature and method,” European Journal ofinformation systems, vol. 4, pp. 74–74, 1995.

[23] K. Beck, Test-driven development: By example.Addison-Wesley Professional, 2003.

[24] P. Bulychev and M. Minea, “Duplicate code de-tection using anti-unification,” in Spring YoungResearchers Colloquium on Software Engineering,SYRCoSE, vol. 2008, p. 4, 2008.

[25] M. Fowler, “Inversion of control containers andthe dependency injection pattern,” Actualizado el,vol. 23.

12

Appendix A

Figure 7: Module subset used during the inquiry

13

Appendix B

Figure 8: Metabolism presentation layer

Figure 9: Repository Language Distribution Graph

14

Figure 10: Repository Information Summary

15