a software tool to illustrate graph...

StudentVlad-FlorinChitaru

ASOFTWARETOOLTOILLUSTRATEGRAPHCOLOURING

SupervisorDr.RizosSakellariou

Vlad-FlorinChitaru

May2016

AprojectreportfortheThirdYearProjectsubmittedto The University of Manchester for the degree ofBachelorinScienceintheSchoolofComputerScience

2

ABSTRACT

Graph colouring represents one of the best-known subjects in the field of graph theory,having a broad rangeof real life applications, such as timetabling, register allocation andscheduling.MainlyduetoitsNP-completecomputationalcomplexity,graphcolouringanditssub-tasks such as edge colouring represent an active field of study and a challenge foracademics. Lastly, sequential algorithms represent one of the most popular solution forsolvinggraphcolouring.

In this report the development process of a software tool capable of illustrating graphcolouringispresented.Thefirstsectionoffersabriefintroductiontothetopicandhighlightstheapplicabilityofgraphcolouring in solving real life tasks.Thesecondpartmoveson todescribing the hybrid requirements gathering process, followed by an analysis of theextensiblesystemdesign.Furthermore,thereportillustratestheimplementationstageandemphasises the usefulness of the considered external libraries. The following chapter isdividedintotwopart.ThefirstpartdiscussestheBack-EndandFront-Endtesting,whilethesecondpartpresentstheresultsofthealgorithmsevaluation.Lastly,thefinalchapterofthereportenclosestheconclusion,theproject’slimitationsandfutureareasofimprovement.

3

ACKNOWLEDGMENTS

I would like to express my appreciation to all those who provided me the possibility tocompletethisreport.AspecialgratitudeIgivetomyThirdYearProjectsupervisor,Dr.RizosSakellariou,forbothhiscontinuedmentoringandguidancethroughouttheproject.Iwouldalso like to thank Dr. Liping Zhao for her feedback on the project deliverables. Last, butdefinitely not least, I want to praise Luiza and my parents for their support andencouragementsthroughoutmyUniversitystudies.

4

TABLEOFCONTENTS

Listoffigures.....................................................................................................................7

Listoftables......................................................................................................................9

Chapter1:Introduction...................................................................................................10

1.1Overview............................................................................................................................10

1.2Motivation.........................................................................................................................10

1.3Scopeandaims...................................................................................................................10

1.4Achievements.....................................................................................................................11

1.5Reportstructure.................................................................................................................11

Chapter2:Background....................................................................................................12

2.1Overview............................................................................................................................12

2.2Introductiontographcolouring..........................................................................................12

2.2.1Graphs................................................................................................................................12

2.2.2Vertexcolouring.................................................................................................................12

2.3Graphcolouringalgorithms................................................................................................14

2.3.1GreedyColouringalgorithm...............................................................................................14

2.3.2Smallest-LastColouringalgorithm......................................................................................14

2.3.3ConnectedSequentialColouringalgorithm........................................................................15

2.3.4RandomSequentialColouringalgorithm............................................................................16

2.3.5Largest-FirstColouringalgorithm.......................................................................................17

2.3.6SaturationLargest-FirstColouringalgorithm.....................................................................17

2.4Reallifeapplicationsofgraphcolouring.............................................................................18

2.4.1Timetabling.........................................................................................................................18

2.4.2Registerallocation..............................................................................................................20

2.5Concludingremarks............................................................................................................21

Chapter3:Requirementsengineering.............................................................................22

3.1Overview............................................................................................................................22

3.2Graphcolouringalgorithmsanalysis...................................................................................22

3.3Requirementsengineering..................................................................................................23

3.3.1Methodology......................................................................................................................23

3.3.2Usecasediagram................................................................................................................25

3.3.3Functionalrequirements....................................................................................................26

5

3.3.4Non-Functionalrequirements............................................................................................26

3.3.5Userstories.........................................................................................................................27


Chapter4:Design............................................................................................................29

4.1Overview............................................................................................................................29

4.2Designoverview.................................................................................................................29

4.3Back-Enddesign..................................................................................................................31

4.3.1Modularity..........................................................................................................................31

4.3.2Abstraction.........................................................................................................................32

4.3.3Encapsulation.....................................................................................................................33

4.4Front-Enddesign................................................................................................................34

4.4.1Model-View-Controllerdesignpattern...............................................................................34

4.4.2User-Interfacedesign.........................................................................................................36


Chapter5:Implementation.............................................................................................38

5.1Overview............................................................................................................................38

5.2Methodology......................................................................................................................38

5.3Implementationframeworkandexternallibraries..............................................................39

5.4Back-Endimplementation...................................................................................................40

5.4.1Graphcolouringalgorithms................................................................................................41

5.4.2Reportgenerator................................................................................................................42

5.5Front-Endimplementation.................................................................................................44


Chapter6:Testingandevaluation...................................................................................47

6.1Overview............................................................................................................................47

6.2Testing................................................................................................................................47

6.2.1Back-Endtesting.................................................................................................................47

6.2.2Front-Endtesting................................................................................................................48

6.3Evaluation..........................................................................................................................50


Chapter7:Conclusion......................................................................................................53

7.1Overview............................................................................................................................53

7.2ReportSummary................................................................................................................53

6

7.3Achievements.....................................................................................................................53

7.4Limitationsandfutureimprovementareas.........................................................................54


ReferenceList..................................................................................................................55

Appendixlist...................................................................................................................59

AppendixA:Sampledocumentationofiterationplanningandreviewsessions........................59

AppendixB:Iterativeandincrementalsoftwareimplementation.............................................61

AppendixC:Toolsanddevelopmentplatform..........................................................................63

AppendixD:Samplereport......................................................................................................64

AppendixE:Graphcolouringillustrationtoolwalkthrough......................................................65

7

LISTOFFIGURES

Figure1.SimplegraphG. ………………….…………… 12

Figure2.10-colouringofgraphG. ………………….…………… 13

Figure3.3-colouringofgraphG. ………………….…………… 13

Figure4.Greedycolouringpseudo-code. ………………….…………… 14

Figure5.Smallest-Lastalgorithm. ………………….…………… 15

Figure6.Smallesthard-to-colourgraphforSLmethod. ………………….…………… 15

Figure7.Connectedsequentialalgorithm. ………………….…………… 16

Figure8.Smallesthard-to-colourgraphforCSmethod. ………………….…………… 16

Figure9.RandomSequentialalgorithm. ………………….…………… 16

Figure10.SmallestHard-to-colourgraphforRSmethod.………………………….…… 16

Figure11.Largest-Firstalgorithm. ………………….…………… 17

Figure12.Smallesthard-to-colourgraphforLFmethod.……………….……………… 17

Figure13.SaturationLargest-Firstalgorithm. ………………….…………… 18

Figure14.Smallesthard-to-colourgraphforSLFmethod………………….…………… 18

Figure15.Timetablingusinggraphcolouring. ………………….…………… 20

Figure16.Sampleinterferencegraph. ………………….…………… 21

Figure17.Requirementsengineeringhybridapproach. ………………….…………… 24

Figure18.Use-casediagram. ………………….…………… 25

Figure19.Userstoriesboard. ………………….…………… 28

Figure20.Systemworkflow. ………………….…………… 30

Figure21.Hierarchicaltaskanalysis. ………………….…………… 30

Figure22.Sampleimplementationofmodularity. ………………….…………… 32

Figure23.Sampleimplementationofabstraction. ………………….…………… 33

Figure24.Sampleimplementationofencapsulation. ………………….…………… 35

Figure25.MVCsampleimplementation. ………………….…………… 35

Figure26.Samplewireframe. ………………….…………… 36

Figure27.LFalgorithmpseudo-code. ………………….…………… 41

Figure28.ReportGeneratorclasspseudo-code. ………………….…………… 43

Figure29.Snippetofadynamicgeneratedreport. ………………….…………… 44

Figure30.AlgorithmTutorialPanel. ………………….…………… 45

Figure21.SampleUItestingscenarios. ………………….…………… 48

Figure32.SampleUIautomatedtest. ………………….…………… 49

8

Figure33.Chromaticnumber. ………………….…………… 51

Figure34.Executiontime. ………………….…………… 51

Figure35.DIMACSevaluation. ………………….…………… 52

Figure36.Iteration0planningmeeting. ………………….…………… 59

Figure37.Iteration0reviewmeeting. ………………….…………… 59

Figure38.Iteration5planningmeeting. ………………….…………… 60

Figure39.Iteration5reviewmeeting. ………………….…………… 60

Figure40.InputPanelv1.0. ………………….…………… 61




Figure44.Samplereport. ………………….…………… 64

Figure45.InputPanel. ………………….…………… 65

Figure46.AlgorithmPanel. ………………….…………… 65

Figure47.ColouringPanel. ………………….…………… 66

Figure48.ComparePanel. ………………….…………… 66

Figure49.TutorialPanel. ………………….…………… 67

Figure50.DocumentationPanel. ………………….…………… 67

9

LISTOFTABLES

Table1.Essentialtimetablingconditions. ………………………………………….. 17

Table2.Preferentialtimetablingconditions. ………………………………………….. 17

Table3.Sequentialgraphcolouringalgorithms. ………………………………………….. 21

Table4.Samplefunctionalrequirements. ………………………………………….. 24

Table5.Samplenon-functionalrequirements. ………………………………………….. 25

Table6.Sampleuserstories. ………………………………………….. 25

Table7.Sampleprototypes. ………………………………………….. 37

Table8.Evaluationexperiments. ………………………………………….. 48

10

CHAPTER1:INTRODUCTION

1.1OVERVIEW

Theaimofthissectionistopresentthescopeoftheproject,followedbyabriefdescription

oftheachievementsandthereport’sstructure.

1.2MOTIVATION

Graphsaremathematicalmodelsthatcanbeusedinordertosuccessfullyanalysereal-world

problems(BalakrishnanandRanganathan,2000).Specifically,thegraphicalrepresentationof

a graph is useful in better understanding and illustrating both theoretical and practical

concepts(BondyandMurty,1976,p.2).Furthermore,Deo(1974)supportsthisstatementby

claimingthatagraphcanbeusedtorepresentalmostanyphysicalsituationinvolvingdiscrete

objects and a relationship among them. Lastly, graph theory is regarded as a continuous

research area and one of the fundamental issues in several hundred classical computer

scienceproblems(CrescenziandKann,1998).

According to Kubale (2004) graph colouring represents one of the most important and

best-knownproblemsofgraphtheory.InitiallyintroducedbyCayleyin1878,edge-colouring

of a graph is considered an NP-complete problem (Holyer, 1981). Furthermore, a graph

colouringalgorithmcanbeevaluatedtakingintoaccountbothquantityandqualityaspects:

thecomputationalcomplexityandthechromaticnumber(tobedefinedlater).Finally,the

project’saimwastodeliveranillustrationtoolthatwouldallowuserstoevaluateandanalyse

differentheuristicmethodsofgraphcolouring.

1.3SCOPEANDAIMS

Themainpurposeoftheprojectwastodeliverauser-friendlysoftwarecapableofillustrating

andcomparingvariousgraphcolouringtechniques.Secondly,athoroughanalysisofseveral

greedyalgorithmswasperformedbyevaluatingdifferentheuristicsandbenchmarkingthem

usinglargesetsofrandomlygeneratedgraphs.Morespecifically,theproject’saimswere:

11

• To analyse several greedy graph colouring algorithms by discussing their time and

spacecomplexity;

• Todesign,implementandtestanillustrationtoolabletoi)visuallyrepresentastep-

by-steptutorialofgraphcolouringii)comparedifferentgreedyalgorithmsproposed

bytheresearchedliteratureandiii)generateareportcontainingcomparativetesting

usinglargesetsofgraphsasinput;

• To thoroughly evaluate the performance of the implemented algorithms using

DIMACSgraphsandcomparetheresultswithbenchmarkinstances.

1.4ACHIEVEMENTS

Thedeliveredillustrationtooloffersausefullearningexperiencethatprovidesuserswithan

insightintoseveralgreedygraphcolouringalgorithms.Thesoftware’sintuitiveuserinterface

andcomplexfeaturesreceivedpositivefeedbackfromusers.Moreover,anexhaustivetesting

processwascompletedinordertoensureanindustrylevelqualityofthefinalartifact.

Secondly, the project’s evaluation stage highlighted that the implemented algorithms

generated similar colouring results. However, due to the different heuristics and the

algorithms’implementations,anoticeabledifferenceoftheexecutiontimewasobservedand

explained.

1.5REPORTSTRUCTURE

Theremainingofthereportisstructuredasfollows:

• Chapter2offersan insight intographcolouring, followedbyananalysisofseveral

greedyalgorithms.

• Chapter3presentstherequirementsgatheringprocessbyofferinganoverviewofthe

illustrationtool’slistoffeaturesanditsfunctionalandnon-functionalrequirements.

• Chapter 4 describes the software’s flexible architecture and highlights important

designfeatures.

• Chapter5discussestheagileimplementationprocessandpresentstheincorporated

externallibraries.

• Chapter6incorporatesdetailsregardingtestingandevaluation.

• Chapter7includesthereport’sconclusion.

12

CHAPTER2:BACKGROUND

2.1OVERVIEW

Thissectionintroducestheconceptofgraphcolouring,followedbytheanalysisoftwogreedy

algorithms proposed by the researched literature. Lastly, real life applications of graph

colouringarebrieflydiscussed.

2.2INTRODUCTIONTOGRAPHCOLOURING

2.2.1GRAPHS

AlineargraphasG=(V,E)consistsofasetofobjectsV={v1,v2,…,vn}calledvertices,and

anothersetE={e1,e2,…,em}whoseelementsarecallededges,suchthatedgeekisdefined

withanorderedpair(vi,vj)ofvertices(Deo,1974).Moreover,simplegraphscanbedefined

asgraphsthatdonotcontaindirectededges,loopsormultipleedgesbetweentwoconnected

vertices(Lehmanetal.,2012,p.315).

Figure1.SimplegraphG.

Figure 1 illustrates a simple graphG = (V, E), where V = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9} and

E={(0,2),(0,3),(1,3),(3,5),(3,4),(4,7),(5,6),(6,7),(8,9)}.

2.2.2VERTEXCOLOURING

Havet(2007)definesa(vertex)colouringofagraphGasamappingc:V(G)àS,wherethe

elements of S are called colours. A k – colouring of graphG is an assignment of integers

{1,2,…,k}(thecolours)totheverticesofGinsuchawaythatneighboursreceivedifferent

13

values(Marx,2003).Furthermore,thesmallestnumberkforwhichthereexistsak–colouring

ofgraphGiscalledthechromaticnumberofgraphG(Kubale,2004,p.3).Lastly,graphGis

hard-to-colourforalgorithmAifany implementationofalgorithmAleadstoasuboptimal

colouringofG(Kubale,2004,p.5).

AsseeninFigure2colouringtheverticesofgraphGdoesnotrepresentachallenge,aseach

vertexvcanbeassignedauniquecolour,resultinginatotalnumberofusedcoloursequal

withthenumberofvertices.

Figure2.10-colouringofgraphG.

However,thescopeoftheprojectistocomputethek-colouringofgraphbyidentifyingthe

graph’s chromatic number. Specifically,Figure 3presents a proper colouring of the same

graphGusingonly3colours.

Figure3.3-colouringofgraphG.

14

2.3GRAPHCOLOURINGALGORITHMS

2.3.1GREEDYCOLOURINGALGORITHM

Kubale (2014) defines greedy colouring of graph G using a sequence of vertices

K={v1,v2,…,vn}astheprocedureofcolourassignmentdescribedinFigure4.

algorithmGreedy-Colour(G,K);begin forv=v1tovndo givevertexvthesmallestpossiblecolour;end;

Figure4.Greedycolouringpseudo-code(Kubale,2014,p.8).

Duetothehighcomputationalcomplexityofgraphcolouring,astandardgreedycolouring

approach does not produce the lowest value for the chromatic number. Furthermore, a

sequential colouring algorithm improves the colouring process by initially determining a

colouringsequenceKofverticesofgraphGandthenapplyingagreedycolouringapproach

takingintoaccountthecomputedK(ClarkandHolton,1991).

Thescopeoftheprojectcoveredtheanalysisandimplementationoffivegreedycolouring

algorithms: Random Sequential (RS), Largest-First (LF), Smallest-Last (SL), Connected

Sequential (CS) andSaturation Largest-First (SLF). Thenext subsectionsof the reportwill

introduce the mentioned algorithms by discussing the pseudo-code, implementation

complexityandthesmallesthard-to-colourgraphforeachoneofthem.

2.3.2SMALLEST-LASTCOLOURINGALGORITHM

IntroducedbyMatulaetal.(1972),theSmallest-Last(SL)methodisbasedontheobservation

that verticeswith lower degrees need to be coloured last. Consequently, vertices of high

degreearecolouredinfirstpriority.Moreover,Kubale(2014)claimsthattheSLmethodcan

beimplementedtoruninO(m+n)timeandthatforplanargraphs,themethodwillnever

usemorethan6colours.PleaseseeFigure5foradetaileddescriptionoftheSLalgorithm.

15

algorithmSL-Colour(G);begin K=Ø; whileV\K≠Ø appendtoKthethevertexvwiththesmallestdegreeinthesubgraph generatedbyV\K; Greedy-Colour(G,𝐾);{𝐾representstheinversionoforderofsequenceK}end;

Figure5.Smallest-Lastalgorithm(Kubale,2014,p.11).

Furthermore, Figure 6 illustrates the smallest hard-to-colour graph (also known as

prismatoid)fortheSLmethod(Kubale,2014,p.11).

Figure6.Smallesthard-to-colourgraphforSLmethod(Kubale,2014,p.11).

2.3.3CONNECTEDSEQUENTIALCOLOURINGALGORITHM

SuggestedbyHertzandWerra(1989),theConnectedSequential(CS)algorithmimpliesthat

arandomvertexisselectedatthebeginningandthen,ateachstep,thealgorithmselectsany

nodewhich is adjacent to at least one already coloured node. Specifically, this colouring

sequence can be achieved with the aid of breadth-first or depth-first graph traversal

techniques.Furthermore,accordingtoKubale(2014),theCSmethodcanbeimplementedto

runinO(m+n)time.Asuggestedpseudo-codeoftheCSmethodispresentedinFigure7.

16

algorithmCS-Colour(G);begin K=verticesofGorderedinsuchawaythateachvertex(exceptthefirstone) hasatleastoneneighbourintheprecedingpartofthesequence; Greedy-Colour(G,K);end;

Figure7.Connectedsequentialalgorithm(Kubale,2014,p.12).

Furthermore,thesmallesthard-to-colourgraphfortheCSmethodisillustratedinFigure8

(Kubale,2014,p.13).

Figure8.Smallesthard-to-colourgraphforCSmethod(Kubale,2014,p.13).

2.3.4RANDOMSEQUENTIALCOLOURINGALGORITHM

The Random Sequential (RS) colouring algorithm, also known as the naivemethod, is a

sequential colouring method which does not include the sequence-building stage of the

algorithm(Kubale,2014).Moreprecisely,theverticesofthegrapharecolouredinarandom

order. Therefore, themethod can be implemented to run inO(m + n) time. A suggested

pseudo-codeoftheRSmethodispresentedinFigure9.

algorithmRS-Colour(G);begin K=arandomsequenceofverticesofgraphG; Greedy-Colour(G,K);end;

Figure9.RandomSequentialalgorithm(Kubale,2014,p.9).

Thesmallesthard-to-colourgraphfortheRSmethodisillustratedinFigure10(Kubale,2014).

Figure10.Smallesthard-to-colourgraphforRSmethod(Kubale,2014,p.13).

17

2.3.5LARGEST-FIRSTCOLOURINGALGORITHM

TheLargest-First(LF)colouringalgorithmisoneoftheoldestandsimplestgraphcolouring

sequentialalgorithms.AccordingtoKubale(2014)themethodisbasedontheobservation

thatverticesoflowdegreeallowforamoreflexiblechoiceofcolour.Asaresult,thevertices

of high degree need to be coloured first. The LFmethod can be implemented to run in

O(m+n)time.Asuggestedpseudo-codeoftheLFmethodispresentedinFigure11.

algorithmLF-Colour(G);begin K=verticesofGarrangedinnon-increasingorderofdegree; Greedy-Colour(G,K);end;

Figure11.Largest-Firstalgorithm(Kubale,2014,p.9).

Pleasefindthesmallesthard-to-colourgraphfortheLFmethodenclosedinFigure12(Kubale,

2014,p.13).

Figure12.Smallesthard-to-colourgraphforLFmethod(Kubale,2014,p.13).

2.3.6SATURATIONLARGEST-FIRSTCOLOURINGALGORITHM

TheSaturationLargest-First(SLF)colouringalgorithmrepresentsasensiblemodificationof

theLFmethodbasedontheobservationthattheconstraintsincolourassignmentresultfrom

the number of uniquely coloured neighbours of the coloured vertex (Kubale, 2014). This

methodcanbeimplementedtoruninO((m+n)log(n))time.Asuggestedpseudo-codeofthe

SLFmethodispresentedinFigure13.

18

algorithmSLF-Colour(G);begin whilenotallverticesofGhavebeencoloureddobegin v=thevertexwiththehighestsaturationdegreeq(v)inG; assignthesmallestpossiblecolourtov; endend;

Figure13.SaturationLargest-Firstalgorithm(Kubale,2014,p.9).

Furthermore,thesmallesthard-to-colourgraphfortheSLFmethodisillustratedinFigure14

(Kubale,2014,p.15).

Figure14.Smallesthard-to-colourgraphforSLFmethod(Kubale,2014,p.15).

Thenextpartofthereportmovesontodiscussthereallifeapplicationsofgraphcolouring.

2.4REALLIFEAPPLICATIONSOFGRAPHCOLOURING

Althoughgraphcolouringseemstobejustatheoreticalproblem,therearemultiplereallife

applications of scheduling or assignment such as timetabling (Clerc and Kennedy, 2012),

register allocation (Chaitin, 1982), scheduling (Xhafa and Abraham, 2008), frequency

assignment(Abrahametal.,2006)andmanymore(Zhongetal.,2005). Furthermore,the

reportwilldescribeacoupleofthementionedgraphcolouringapplications.

2.4.1TIMETABLING

According to Xhafa and Abraham (2008) the timetabling task is known as an NP-hard

representative of the multi-constrained class. Astarian and deWerra (2002) support the

statementbyclaimingthatthegraphcolouringproblemrepresentsageneralisationofthe

timetablingproblem.Furthermore,thetimetablingtaskhasseveralvariations,includingthe

coursetimetablingproblem(CTP).

Thecoursetimetablingproblem(CTP)requirestheassignmentofasetofevents(e.g.classes)

toasetofresources(e.g.rooms)andtimeslotsbysatisfyingasetofconstraints(Xhafaand

19

Abraham,2008).Therestrictionsinvolvedincreatingatimetableofcoursesmaybedivided

intotwocategories:essentialandpreferentialtimetablingconditions(Redl,2004).

ID Description

E1 Twoormorecoursestaughtbythesameinstructorcannotbescheduledforthesametimeslot(Trick,1994).

E2 Twoormorecoursesthatrequirethesameclassroomcannotbescheduledforthesametimeslot(Trick,1994).

E3 Theinstructors’availabilitiesneedtobetakenintoaccount(Gotlieb,1963).

E4 Eachcoursemustbescheduledintoavailableclassroomcapableofaccommodatingthenumberofenrolledstudents(Burkeetal.,1993).

Table1.Essentialtimetablingconditions.

Essential timetabling conditions represent mandatory restrictions required in order to

produce a legal or feasible timetable. Table 1 includes sample essential timetabling

conditions.

Ontheotherhand,preferentialtimetablingconditionsdonotnecessarilyneedtobesatisfied

inordertogeneratealegaltimetable,butifsatisfiedmayverywellproduceamoretolerable

timetableforstudentsand/orfacultymembers(Redl,2004).Table2 includesexamplesof

preferentialtimetablingconditions.

ID Description

P1Aclassroomassignedtoacourseshouldbejustlargeenoughtoaccommodatetheenrolledstudents,inordertominimisethenumberofunusedemptyseats(ErbenandKeppler,1995).

P2 Teachingstaffmighthavepreferencesregardingthetimeandlocationofacourse(Redl,2004).

P3 Assigneachcourseaclassroomlocatedinorclosetothecourse’sdepartmentand/orclosetotheinstructor’soffice(ErbenandKeppler,1995).

Table2.Preferentialtimetablingconditions.

Furthermore, an example illustrated by Miner et al. (1995) is used to demonstrate the

applicabilityofgraphcolouringinthecontextoftimetabling.Supposefourcoursesmustbe

scheduled:P101,P234,P300andP300LAB,andthesameinstructorteachesP101,P234and

20

P300,whileasecondinstructorteachesP300LAB.Moreover,studentsenrolledinP300must

beenrolledinP300LABconcurrently.

ThetimeconstraintscanberepresentedinagraphasseeninFigure15.Moreprecisely,an

edgebetweentwodifferentcoursessignalsthefactthatthecoursescannotbeassignedthe

sametimeslot.Figure15alsoillustratesapropercolouringofthegraph,whereeachcolour

representsadifferenttimeslot.Asaresult,onlythreedifferenttimeslotsarerequiredto

scheduleP101,P234,P300andP300LABcourses.

Figure15.Timetablingusinggraphcolouring(Mineretal.,1995).

2.4.2REGISTERALLOCATION

AccordingtoShamiziandLotfi(2011)registerallocationisoneofthemostimportantcompiler

optimisationtechniques.Registerallocationinthecontextofcompilerscanbedefinedasthe

processofdecidingwhichvalues tokeep in registersateachpoint in thegeneratedcode

(Briggs et al., 1994).Moreover, the goal is to keep asmany computations as possible in

registers than in storage (Chaitin et al., 1981). Although Lavrov (1961) proposed the

abstractionofregisterallocationtoagraphcolouringtask,thefirstimplementationofagraph

colouringregisterallocatorwasdevelopedbyChaitinandhiscolleaguesfortheexperimental

PL/IcompilerfortheIBMSystem/370(Chaitinetal.,1981).

Chaitin(1981)claimsthatinordertoallocateregisters,aregisterinterferencegraphisbuild

foreachprocedureinthesourceprogramanda17-colouringofthegeneratedgraphsneeds

to be obtained. More precisely, for each procedure P in the source program a graph is

21

generated inwhichnodesrepresent the17machineregistersandall computations in the

procedurePwhichreside inmachineregisters,andedgesstandforregister interferences.

PleaseseeFigure16(Topcuogluetal.,2007)forasampleinterferencegraph.Lastly,register

allocation is achieved if the chromatic number of the graph is 17. However, if the graph

requiresmore than17colours tobeproperlycoloured, "spill codemustbe introduced to

store and reload registers in order to obtain a programwhose chromatic number is 17"

(Chaitinetal.,1981,p.48).

Figure16.Sampleinterferencegraph(Topcuogluetal.,2007).

2.5CONCLUDINGREMARKS

Thischapterofferedabriefintroductiontothetheoreticalaspectsofgraphcolouring.More

precisely,thegreedygraphcolouringapproachwasdiscussed,followedbytheanalysisoftwo

sequential algorithms. Lastly, the importance of graph colouring was emphasised by

highlightingtwoofitsreallifeapplications.

22

CHAPTER3:REQUIREMENTSENGINEERING

3.1OVERVIEW

Theaimofthischapteristopresentthescopeoftheprojectbydiscussingtwodistinctstages:

algorithmsanalysisandthedevelopmentofthegraphcolouringillustrationtool.Thefirstpart

ofthechapteroffersasummaryoftheanalysedalgorithmsandmotivatesthedecisionof

including the selectedones into the illustration tool. Lastly, the requirementsengineering

neededforthedevelopmentofthegraphcolouringillustrationtoolispresented.

3.2GRAPHCOLOURINGALGORITHMSANALYSIS

Thefirststageoftheprojectcomprisedofanexhaustiveanalysisofdifferentgraphcolouring

algorithmsinorderto identifysuitablecandidatesforthegraphcolouring illustrationtool.

Initially, both sequential and distributed graph colouring algorithms were considered.

However, the limitations of distributed algorithms (Shamir and Upfal, 1982) and the

attractivenessofexploringdifferentheuristicsmotivatedthedecisionoffocusingthe later

stagesoftheprojectonimplementingsequentialalgorithms.

ThefivealgorithmsincludedinTable3wereselectedfromtheresearchedliteraturebased

onthedifferentimplementedheuristicsandtimecomplexity(Kubale,2014).Furthermore,

thealgorithms’performancewasanalysedfromtheperspectiveofthechromaticnumberand

executiontime.Basedonthisanalysis,thedecisionofimplementingthealgorithmsintothe

graphcolouringillustrationtoolwastaken.Inordertovisualiseandquantifythefindingsof

theresearchstage,adynamicreportgeneratortoolwasdeveloped.Moreover,theflexibility

ofthistoolalloweditsintegrationintothegraphcolouringillustrationtoolasitwilllaterbe

explainedinthereport.

23

Algorithmname Rationale

RandomSequential “Naivemethodlackingthesequence-buildingstage”(Kubale,2014,p.10).

LargestFirst “Themethodprovedthatitiseffectiv,despiteitssimplicity”(Kubale,2014,p.10).

SmallestLast “Optimallycolourstrees,cycles,unicyclicgraphs,wheelsandcompletebipartitegraphs”(Kubale,2014,p.11).

ConnectedSequential “Theapproachavoidssuboptimalcolouringandtrivialgraphsarealwayscolouredinanoptimalway”(Kubale,2014,p.12).

SaturationLargestFirst“AsensiblemodificationoftheLargestFirstmethodthattakesintoaccountthenumberofuniquelycolouredneighboursofeachvertex”(Kubale,2014,p.13).

Table3.Sequentialgraphcolouringalgorithms.

Theresearchstageoftheprojectwasfollowedbythedevelopmentofasoftwaretoolcapable

ofillustratingthedifferencesbetweentheimplementedgraphcolouringalgorithms.

3.3REQUIREMENTSENGINEERING

Oncethegraphcolouringalgorithmsanalysisstagewascompleted,theprojectfocusedon

developingthegraphcolouringillustrationtool.Thenextsectionofthereportdescribesthe

requirementsengineeringprocessbyhighlightingboth the involvedmethodologyand the

documentationgeneratedduringtheplanningsessions.

3.3.1METHODOLOGY

Thecomplexityofthegraphcolouring illustrationtoolmotivatedthedecisionofanalysing

andadoptingdifferentrequirementsengineeringtechniques,asacademics(Geambașuetal.,

2011)claimthattherateofsuccessofasoftwaredevelopmentprojectdependsontheteam’s

ability of choosing amethodology that is adequate for the specific characteristics of the

project. Based on the researched literature and the advantages and disadvantages of

different software developmentmethodologies (Boehm and Turner, 2004; Nilsson, 2005;

Cohenaetal.,2004),thedecisionofadoptingbothabig-upfrontmethodandanagilemethod

wastaken.

Initially thebigup-front requirements (BUFR)approachwas considered, as themethod is

recommendedforapredictablesmallproject(Larman,2003).BUFRassumesthat:1)there

24

existsareasonablewell-definedsetofrequirementsand2)laterchangestorequirementsare

small enough to be implementedwithout substantially revising the implementationplans

(Leffingwell,2007).However,themethod’sinabilityofadaptingtochangeenforceditsusage

onlyduringtheinitialphaseoftheproject.Asaresult,theinitialsetofrequirementscovered

onlyhighleveldetailsregardingthetool’simplementation.

Furthermore, an Agile requirements gathering method was implemented. Compared to

BUFR,theAgileapproachallowedtheadoptionofaniterativeandincrementaldevelopment

modelopentochangesandfeedback(Sommerville,2007).Asaresult,theBUFR–Agilehybrid

approach allowed a thorough initial requirements elicitation, followed by continuous

requirementsspecificationandvalidation.Furthermore,Figure17illustratetherequirements

gatheringapproachadoptedforthedevelopmentofthegraphcolouringillustrationtool.

Figure17.Requirementsengineeringhybridapproach.

Thehybridselectedmethodcanbedescribedbythefollowingstages:

1) Requirementselicitation–initialhigh-levelrequirementsaredefinedbytakinginto

accounttheprojectproposalandusers’input.

2) Requirements specification – system requirements are gathered during the

developmentprocessandconvertedintouserstories.

3) Requirementsvalidation – continuousprocess thatensures that the requirements

elicitationstagecapturedtheaimoftheprojectwhilstsatisfyingusers’needs.

Finally,theresultofthementionedrequirementgatheringmethodwasdocumentedasuse

casediagrams,functionalrequirements,non-functionalrequirementsanduserstories.

25

3.3.2USECASEDIAGRAM

Use casediagrams areutilised in order to illustrate theuser-system interaction scenarios

(Jacobson, SpenceandBittner, 2011).Moreover, Shenand Liu (2003) claim thatuse case

diagramsrepresentanimportantroleduringsoftwaredevelopment,asuserscanunderstand

iftheproposedsoftwaresolutionsatisfiestheirneeds.Moreprecisely,softwaredevelopers

gain a better understating of the link between the identified actors and the proposed

features.

Figure18.Use-casediagram.

Figure18 illustrates theuse-casediagramproducedby taking intoaccount functionaland

non-functional requirements. Itneedstobementionedthat theactor"ReportGenerator"

representsastandalonetooldevelopedduringthealgorithmsanalysisstageoftheproject.

However,thecomponent’sfunctionalitywaslaterreplicatedintotheillustrationtoolasitwill

beexplainedinChapter4.Lastly,thenecessityofacohesiveuserinterfacecapableofoffering

auser-friendlyexperiencewasmotivatedby themultitudeofuses cases and interactions

betweenthem.

26

3.3.3FUNCTIONALREQUIREMENTS

Afunctionalrequirementcanbedefinedas"astatementofapieceofrequiredfunctionality

orabehaviourthatasystemwillexhibitunderspecificconditions"(Wieger,2003,p.21).In

ordertohighlightandtracktheillustrationtool’sfeatures,alistoffunctionalrequirements

wascomposedandrefinedthroughouttheproject.Samplefunctionalrequirementsofthe

graphcolouringillustrationtoolareenclosedinTable4.Furthermore,theproject’sopenness

was considered a challenge, as numerous ideas were produced during the requirements

elicitationstage.Inconsequence,therequirementswereprioritisedusingtheMoSCoWscale

(Moran,2015)inordertoensuretheproject’scompletionwithinthegiventimeframe.

ID Description Priority

FR1 Allowtheusertocolouragraphusingtheselectedalgorithm. MUST

FR2 Allowtheusertocomparetwographcolouringalgorithms. MUST

FR3 Allowtheusertovisualiseawalkthroughoftheselectedalgorithm. SHOULD

FR4 Allowtheusertogeneratearandominputgraph. MUST

FR5 Allowtheusertomanuallydrawaninputgraph. SHOULD

FR6 Allowtheuseruploadaninputgraph. COULD

FR7 Allowtheusertoexportagraph. WON’T

FR8 Allowtheusertosaveacaptureofthegraph. COULD

FR9 Allowtheusertomass-comparegraphcolouringalgorithms. SHOULD

FR10 Allowtheusertogenerateagenerateareportcontainingtheresultsofthealgorithms’mass-comparison. COULD

FR11 Allowmultipleusersinteract(usingdifferentmachines)interactwiththeapplication. WON’T

FR12 Thesystemvalidatesuserinputandsignalsanyfindingswithanwarningtextlabel. SHOULD

FR13 Allowtheusertointeractwiththegraphdisplayedinthe"canvas"anddynamicallyre-positiontheverticesandedges. COULD

Table4.Samplefunctionalrequirements.

3.3.4NON-FUNCTIONALREQUIREMENTS

Jacobson, Booch and Rumbaugh (1999) define a non-functional requirement as "a

requirement that specifies systemproperties, such as environmental and implementation

27

constraints, performance, platform dependencies, maintainability, extensibility and

reliability. Moreover, Glinz (2007, p.25) claims that "a non-functional requirement is an

attributeoforaconstraintonasystem".Basedontherecommendationssuggestedbythe

researched literature, non-functional requirements were proposed in order to improve

memory usage, performance, flexibility and usability. Moreover, the embraced agile

implementation model (to be discussed later) motivated the refinement of existing

non-functionalrequirementsandtheproposalofnewones.Lastly,Table5illustratessample

non-functionalrequirementsofthegraphcolouringillustrationtool.

ID Description Motivation

NFR1 Efficientuseofspaceandtimeresources.

Generateconsistentcolouringresultsandofferagooduser-experience.

NFR2 Developaflexiblesystemarchitecture.

Allowimplementationsofdifferentgraphtheoryalgorithms.

NFR3 Clearlydisplaygraphscontaining1to1000nodes.

Allowtheexplorationofbothsmallandlargegraphs.

NFR4 Generatebenchmarkreportusingbetween2to500,000graphs. Ensuresuccessfullargescaletesting.

Table5.Samplenon-functionalrequirements.

3.3.5USERSTORIES

The agile iterative requirements gathering process implies the use of user stories. More

precisely,auserstorydescribesfunctionalitythatwillbevaluabletothesoftwareuser(Cohn,

2004).Moreover,thequalityconsistenceoftheproposeduserstorieswasachievedbyusing

the Connextra Template (Adzic and Evans, 2014) and by ensuring that each user story

describesathinend-to-endsliceoffunctionality(Rees,2002).PleaseseeTable6forsample

userstoriesformulatedthroughouttheproject.

UserStoriesAsauser,Iwanttobeabletogeneraterandomgraphs,sothattimecanbesavedduringthegraphinputprocess.

Asauser,Iwanttobeabletoselectagraphcolouringalgorithm,sothatmultiplealgorithmscanbestudied.

Asauser,Iwanttocontrolthecurrentstepofthegraphcolouringtutorial,sothatabetterunderstandingofthealgorithmsisachieved.

Table6.Sampleuserstories.

28

Requirementsmanagementrepresentedoneoftheproject’sadministrativechallenges.Asa

result, the agile practice of iterations was implemented as described by the researched

literature (ShoreandWarden,2008).Moreprecisely,user storieswere formulatedduring

iterationplanningsessionsandtheirprogressreviewedduringtheiterationreviewsessions.

PleaseseeAppendixAforsampledocumentationgatheredduringthementionedsessions.

Following the explained agile requirements specification and validation technique, a

continuousdeliveryofpriorityfeatureswasachieved.

Figure19.Userstoriesboard.

Lastly,Figure19illustratesthetaskboardusedtotrackuserstoriesprogress.


Thischapterdiscussedtwodistinctstages.Firstly,theaimofthealgorithmsanalysisstagewas

to identify suitable candidates for implementing into the illustration tool.Once the listof

graphcolouringalgorithmswasdefined,thedevelopmentofthegraphcolouringillustration

tools debuted with the requirements gathering process. Furthermore, the researched

methodology was briefly analysed, followed by details around the functional and non-

functionalrequirements.Lastly,theimportanceofuserstorieswasemphasisedandsample

userstorieswerepresented.

29

CHAPTER4:DESIGN

4.1OVERVIEW

Thispartofthereportdiscussesthedesigndecisionstakenbeforetheimplementationstage.

The initial sub-section offers a bird’s-eye view of the software design. Furthermore, the

Back-Enddesignispresentedbyhighlightingtheconsideredcoredesignprinciplesandtheir

impactonthesystem’sstructure.Finally, the lastpartof thechapterdescribestheuseof

designpatternsinstructuringtheFront-Enddesign.

4.2DESIGNOVERVIEW

Themaingoaloftheproject’sdesignstagewastodevelopageneralisedsolutioncapableof

illustratingabroadrangeofgraphtheoryalgorithms.Althoughacademics(Glass,2012)claim

thatitismoredifficulttobuildreusablecomponents,thedecisionofdesigninganadequate

systemformultiplealgorithmswasmotivatedbytheopportunityofexploringdifferentdesign

principles and patterns. As a result, the system design process debutedwith a thorough

analysisofthedesignmethodology(Vlissidesetal.,1994)andtheinfluenceoftheresearched

approacheswillbe furtheremphasised throughout thechapter. Furthermore,ahigh level

overviewofthesystemwascreated.

As was pointed out in the previous chapter, the algorithms analysis stage required the

development of a dynamic report generator tool capable of comparing graph colouring

algorithmsusinga largenumberofgraphs.Althoughthementionedtoolwascreatedasa

standalone application, the design proposal of incorporating it into the graph colouring

illustrationtoolwasconsideredappropriate.Inconsequence,thereportgeneratortoolwill

beregardedintheremainingofthereportasafeatureoftheillustrationtool.Furthermore,

asystemworkflowdiagramwascomposedinordertoeasethesystemdesignprocess.

AsillustratedinFigure20,thesystemofferstheusertheabilityto1)visualisegraphcolouring

algorithmsand2)comparealgorithmsandsummarisetheresults intoageneratedreport.

Firstly,thesystemallowstheusertoinputagraph,selectagraphcolouringalgorithmand

finallyvisualisethecolouredgraph.Secondly,theuserneedstoinputtheparametersofthe

30

largescalealgorithmstesting,sothatthesystemcangenerateadynamicreportbasedonthe

findingsofthesimulation.

Figure20.Systemworkflow.

Furthermore, based on the system workflow diagram enclosed in Figure 20 and the

requirements illustrated in the previous chapter, a Hierarchical Task Analysis (HTA) was

produced in order to obtain a lower level granulation of the system’s features. As the

researchedliteraturesuggests,anHTAisusedtohierarchicallyrepresentthetasksandthe

system’sfeatures(Jordan,1996).Moreover,HTAcanimproveclassdesignbyhighlightingthe

flowoftaskswithinthesystem(Hollnagel,2003).

Figure21.Hierarchicaltaskanalysis.

31

Figure21illustratesanHTAdevelopedduringtheearlystagesofsystemdesign.Aspreviously

explained, the HTA builds on top of the system workflow diagram by including details

enclosedby therequirements.Asaconsequence, theHTApresented inFigure21offered

valuabledetailsaroundapossiblesystemdesign.Lastly,itneedstobementionedthatthe

diagramevolvedduringtheproject’sdevelopmentasmorefeatureswereimplemented.

Furthermore,thesystemdesigndiscussionissplitintotwodistinctparts.Thenextsub-section

discussesdetailsaroundtheBack-Enddesign,whilethelastpartofthechapteranalysisthe

Front-Enddesign.

4.3BACK-ENDDESIGN

Sofarthischapterhasfocusedonahigh-leveloverviewofthesystemdesign.Thefollowing

sub-sectionwilldiscusstheresearcheddesignprinciplesandtheirapplicabilityinthecontext

oftheBack-Enddesign.Aspreviouslystated,theaimofprojectwastodeliveramaintainable

and reusable solution that to could be easily adapted to illustrate any graph theory

algorithms.Asaresult,thedesignoftheBack-Endwasdevelopedusinganobjectoriented

programming style andbyapplying severaldesignprinciples suggestedby the researched

literature. Furthermore, the reportwill introduce and illustrate the use of three of these

designprinciples.

4.3.1MODULARITY

Academics claim thatmodularity is "apropertyofamulticomponent system inwhich the

componentsareindependentbutcompatiblewithoneanother"(TracyandBouthoorn,1996,

p.27).Moreprecisely,thesystemisdesignedasacollectionofuniquemodules,ratherthan

asasingle,monolithicentity.Moreover,modularityisconsideredakeyaspectofaflexible

systemas it facilitates thedesignof loosely coupledmodules. Lastly, thisdesignprinciple

enablesfunctionalitytestinginisolationandthereforeimprovingefficiency(Hanson,2015).

32

Figure22.Sampleimplementationofmodularity.

Figure22highlights thesystemdesign’smodularityusingClassResponsibilityCards (CRC).

ThegoaloftheillustratedCRCwastoofferabasicunderstandingofthesystem’smodules

andtherelationshipbetweenthem.Onceaninitialhigh-leveloverviewoftheBack-Enddesign

was completed using CRC, other researched design principles were considered and

implemented.

4.3.2ABSTRACTION

LiskovandGuttag(2000,p.23)defineabstractionas"awaytododecompositionproductively

bychangingthelevelofdetailtobeconsidered".Moreover,WaiteandLafore(1998)claim

thatabstractionistheprocessofignoringanyirrelevantdetailssoastofocusontheessential

information.Abstractionisacoredesignprincipleofreusablesoftwareandasaresult,ithas

stronglyinfluencedtheBack-Enddesign.

33

Figure23.Sampleimplementationofabstraction.

Figure23enclosesaclassdiagramillustratingtheuseofabstractionintheBack-EndDesign.

TheAlgorithminterfaceoffersastructureonwhichtheGraphColouringclassisbuilt

on top.Also,eachgraphcolouringalgorithmclassextendsGraphColouringbyadding

algorithm specific logic. Please note that Figure 23 represents a simplified class diagram

developedinordertoillustratetheuseofabstractionintheBack-Enddesign.

4.3.3ENCAPSULATION

Encapsulationcanbedefinedas"adesignmechanismthatbindstogethercodeandthedata

itmanipulates, and that keeps both safe from outside interferences andmisuse" (Schild,

2003,p.9).Asaresult,theonlywaytointeractwithaclass’attributesisviathemethodsof

the class (Chartan and Kans, 2009). Lastly, encapsulationwas considered into the system

designinordertoimprovedataprotectionandtoavoidaccidentaldataalteration.

34

Figure24.Sampleimplementationofencapsulation.

Figure24highlights a simplified representationof theGraph class. By encapsulating the

private class attributes and implementing getter and setter methods, the system design

allowed the implementationofa read-only,write-onlyorwrite-read access todata.Asa

result,anaccidentalmodificationofGraph’sattributesbyanyoftheconnectedentitieswas

avoided.

This section analysed the Back-End design and has emphasised the importance of the

considereddesignprinciples.ThenextpartofthechapterwilldiscusstheFront-Enddesign

by introducing the considered design patterns and by presenting the User-Interface (UI)

designprocess.

4.4FRONT-ENDDESIGN

Asexplainedinthepreviouschapter,thegraphcolouringillustrationtoolwastheproject’s

main deliverable. As a result, the Front-End represented the project’smain focus, as the

importanceoftheUI isemphasisedbytheresearchedliterature.AccordingtoStoneetal.

(2005,p.23), theUI is a vital partof almost all computer systems.Moreprecisely, theUI

enablesaproductiveand intuitive interactionbetweentheuserandthecomputer(Galitz,

2007).Becauseofitscomplexity,theFront-Enddesignrequiredtheanalysisandadoptionof

severaldesignpatterns,twoofwhichwillbeintroducedinthenextsub-sections.

4.4.1MODEL-VIEW-CONTROLLERDESIGNPATTERN

The researched software design methodology classifies design patterns as: creational,

partitioning,structuralandbehavioural(Grand,2003).Inordertodesignasystemcapableof

35

deliveringthefeaturesdiscussedinChapter3,abroadrangeofdesignpatternshadtobe

considered such as: Model-View-Controller, interface, factory model, builder, façade,

flyweight,decoratorandmediator(Grand,2003).Furthermore,oneofthemostimportant

implementeddesignpatternswillbediscussedandillustrated.

TheModel-View-Controller(MVC)designpatternhelps"todecoupledataaccessandbusiness

logicfromthemanneritisdisplayedtotheuser"(Eckstein,2007).Itmanagestoachievethis,

bydividingthesystem’scomponentsintothreeentities:

1) Model –mainly representedby theBack-End, themodelmanages thedata in the

programbyperformingalldatamanipulationandtransformation(Weitzman,2006).

2) View–itisresponsibleforillustratingtheModeltotheuserthroughtheUI.

3) Controller–ittranslatestheuser’sinteractionswiththeViewintodatamanipulations

thattheModelperforms(Eckstein,2007).

Figure25.MVCsampleimplementation.

Figure25presentsasimplifiedillustrationofhowMVCwassuccessfully implementedinto

theFront-Enddesign.TheGraphInputUIcomponentintheViewsendsanotificationtothe

Controllerwhenever the usermakes a change to a graph using theUI. Furthermore, the

Controller redirects thenotificationcontainingtheuser’sactionstotheModel,wherethe

graph ismanipulated and the input is validated. Once theModel finishes thementioned

36

processes, theupdatedgraphoranyerrornotifications,aresentbacktotheViewviathe

Controller. Lastly,because theMVCmodeldoesnotallowanygraphdata tobestoredor

manipulatedbytheFront-End,theUIperformanceandreliabilityareimproved.

HavingillustratedtheimportanceofdesignpatternsintotheFront-Enddesign,thelastpart

ofthissub-sectionintroducestheprocessofdesigningtheUI.

4.4.2USER-INTERFACEDESIGN

TheUIdesignrepresentedthelaststageoftheFront-Enddesign.However,theprocessof

decidingthelookandfeelofthegraphcolouringillustrationtoolwasacontinuousprocess

throughouttheproject’sduration.Duetotheauthor’slackofpriorUIdesignexperience,the

research process conducted for this task was considered difficult, mainly because of the

topic’s subjective factor. The researched literature (Microsoft.com, 2016) highlighted the

importance of following certain UI design principles such as: intuitiveness, simplified

recognition with icons, consistency and feedback. Despite the challenge of following the

mentionedprinciples,theUIdesignprocessproducedqualitywireframesthatwerelaterused

duringtheimplementationstage.

Figure 26 includes a wireframe produced during the UI design stage. The use of a non-

electronicsolutionfordrawingthewireframeswasmotivatedbytheinitialdecisionofusing

aphysicallogbookforkeepingtrackoftheproject’sprogress.

Figure26.Samplewireframe.

37


Thispartofthereportdiscussedtheproject’sdesignstage.Firstly,abird’s-eyeviewofthe

designwasoffered, followedby theanalysisof theBack-Enddesign.Lastly, theFront-End

designwaspresentedbyhighlightingtheimplementationofMVCandbyillustratingtheUI

designprocess.Also,itworthmentioningthatallthedecisionstakenduringtheinitialdesign

stagewerefurtherrefinedthroughouttheprojectasitwillbeexplainedinthenextchapter.

38

CHAPTER5:IMPLEMENTATION

5.1OVERVIEW

Theaimofthischapteristodiscusstheimplementationstageoftheproject.Initially,abrief

overview of the researchedmethodology is offered, followed by the presentation of the

implementation frameworkandtheconsideredexternal libraries.Furthermore, thereport

analysestheBack-Endbyofferingdetailsabouttheimplementationofthereportgenerator

componentandofthegraphcolouringalgorithms.Lastly,theFront-Endimplementationis

discussed.

5.2METHODOLOGY

AlthoughtherequirementsgatheringprocessimplementedaBUFR-agilehybridmethodas

explained earlier in the report, the project’s implementation stage adopted a strict agile

softwareengineeringmodel.TheresearchprocessdebutedwiththeunderstatingoftheAgile

Manifesto (Agilemanifesto.org, 2016). Furthermore, the decision of adopting an agile

approachwasmotivatedbythebenefitshighlightedbytheresearchedliterature:effective

response to change, incremental delivery of software and the heavy emphasis on

development activities (Pressman, 2009). As a result, the agile practices of iterations and

prototypingwereconsideredduringtheimplementationstageoftheproject.

Sprints,alsoknownasiterations,aretheheartbeatofanagileproject(ShoreandWarden,

2008). The duration of an iteration is called “timebox” and the ideal iteration length is

debatedbyacademicstobeonetothreeweeks(Cobb,2011),twotofourweeks(Cohn,2006)

or oneweek (Shore andWarden, 2008). Based on the author’s past experience and the

project’scomplexity,itwasdecidedtoadoptone-weeklongiterations.Moreover,theaimof

each iteration was to enforce a continuous incremental software delivery. Please see

AppendixBforanillustrationoftheincrementaldevelopmentoftheUI.

The second agile practice considered during the implementation stage was prototyping.

According toRamamoorthyetal. (1984),aprototypedoesnotusuallymeetall theuser’s

requirements as it only implements the most important aspects of the system. Once a

39

prototype is developed, user feedback is gathered and the suggested modifications are

plannedfor implementation(Pressman,2004).Therefore,multiple incrementalprototypes

were necessary in order to deliver a fully-functional graph colouring illustration tool that

incorporatesallthefunctionalandnon-functionalrequirementsdiscussedin3.3.3and3.3.4.

ID Description

PR1 DisplayarandomgeneratedgraphandapplytheGreedyalgorithm.

PR2 Implementtheremaininggraphcolouringalgorithms.

PR3 Enablegraphuploadusinginputfile.

PR4 Implementadynamicgraphpanelthatallowsinteractionswiththenodes.

PR5 Separatefunctionalityindifferentpanelsandimplementanavigationpanel.

Table7.Sampleprototypes

Table 7 contains details of sample prototypes developed throughout the project. The

mentionedprototypesrepresentedincrementalversionsofthesoftwareandweredelivered

every couple of iterations. The prototypes’ implementation required the adoption of a

specific framework and the integration of several external libraries as it will be further

discussed.

5.3IMPLEMENTATIONFRAMEWORKANDEXTERNALLIBRARIES

Theimplementationframeworkwasdecidedbytakingintoaccountthefactthatmostofthe

functional requirements discussed in 3.3.3were related to the Front-End development.

Moreover,theextensiblesystemdesignillustratedinChapter4enforcedthedecomposition

of the system and adoption ofmodularity. Therefore, Java™ 8was selected as themain

development programming language, because it is object-oriented and platform-

independent(IBM.com,2016).Furthermore,thedecisionwasinfluencedbythebroadrange

offreelyavailableJava™librariesandnumerousrelatedtechnologies.

Furthermore, although the identified programming language offered basic support for

representing graph objects and allowed UI development, the illustration tool’s visual

complexitymotivatedtheimplementationofseverallibrariessuchas:

40

• Graphics2D–representsthefundamentallibraryforrendering2-dimensionalshapes,

textandimagesontheJava™platform(Oracle.com,2016).

• JGraphT–providesgraph-theoryobjectsandalgorithms(Jgrapht.org,2016).

• JUNG–includesextendiblelanguagecapableofrepresentinggraphs(Jung.net,2016).

• SwingX–containsextensionsoftheSwingGUItoolkit(Swingx.java.net,2016).

• GraphStream–providesgraphillustrationsupport(Graphstream-project.org,2016).

• DynamicReports–createsdynamicreportdesigns(Dynamicreports.org,2016).

• FEST–enablesUIautomatedtesting(Code.google.com,2016).

• Log4j–offersloggingfunctionality(Appache.org,2016).

Thedecisionof incorporatingexternal libraries intotheapplication’s implementationswas

motivatedbythe limitedvisualdevelopmentcapabilitiesofthevanillaversionof Java™8.

Althoughthecoordinationofa largenumberofexternal librariesrepresentedachallenge,

the explicit artefacts produced during the design stage eased the illustration tool’s

implementation. Moreover, the adoption of existing solutions enabled the successful

implementationofawiderangeoffeaturesarticulatedduringtherequirementsgathering

process.Lastly,alistoftoolsanddetailsregardingthedevelopmentplatformareprovidedin

AppendixC.

Oncethepreferredprogramminglanguagewasdecidedandalistofexternal librarieswas

composed, the actual system implementation started. Furthermore, the report discusses

details of the Back-End implementation, followed by an analysis of the Front-End

development.

5.4BACK-ENDIMPLEMENTATION

Althoughmostoftheproject’srequirementsfocusedonUIfeatures,itwasvitaltodevelop

anefficientBack-Endcapableofmanipulatinggraphobjects.Moreover,thegraphcolouring

algorithms implementation required a deep understanding of different efficiency

improvement techniques and data structures. This sub-section will firstly illustrate the

implementationofagraphcolouringalgorithm,followedbyadiscussionaroundthereport

generatorcomponent.

41

5.4.1GRAPHCOLOURINGALGORITHMS

Becauseoftherestrictions imposedbytheMVCdesignmodeloftheFront-End(Kortright,

1997),eachalgorithmwasimplementedtwice:anobject-orientedapproachsuitableforthe

graph illustration andahigh-performance implementation required for benchmarking the

differentgraphcolouringheuristics.However,bothapproachesfollowedasimilarpatternand

thepseudo-codesdiscussedin2.3.PleaseseeFigure27forasimplifiedpseudo-codeofthe

Largest-Firstgraphcolouringalgorithm.

1. colourGraph() { 2. initialise(); 3. compute(); 4. } 5. 6. initialise() { 7. colouringSequence = generateColouringSequence (); 8. } 9. 10. compute() { 11. for each node in colouringSequence { 12. colour node with the smallest available colour; 13. } 14. } 15. 16. generateColouringSequence() { 17. colouringSequence = new empty list; 18. for index = 1 -> number of nodes in graph { 19. largestNode = compute node with largest degree 20. and not in the colouringSequence; 21. add largestNode to colouringSequence; 22. } 23. }

Figure27.LFalgorithmpseudo-code.

AsseeninFigure27,thealgorithm’simplementationwasbrokendownintoseveraldistinct

methods, so that different software components could request a certain information

containedbytheobject.Forexample,aFront-Endcomponentthatillustratesthecolouring

sequence would request the information from the controller, which would only call the

generateColouringSequence method, not the more complex colourGraph

method.Lastly,becauseeveryalgorithmimplementationfollowedthedescribedstructure,

codeduplicationwasavoidedthroughoutthecode-base.

In addition to the object-oriented approach, the implementation of the graph colouring

algorithmsalsofocusedondevelopingamoretimeandspaceefficientversion.Althoughthe

42

classstructuredescribedin4.4.3allowedgoodperformanceinthecaseofsmalltomedium

graphs,differenttechniqueshadtobeconsideredinthecaseoflargeinputs.Theresearched

literaturesuggestedacoupleofmodifications:

• DataStructure– ifthe initial implementationconsideredaListofNodeandEdge

objectsinordertorepresentaGraph,thesecondapproachinvolvedstoringgraph

data using an adjacency matrix. Despite that this approach required a sensible

alteration of the algorithms, the space required to store large dense graphs was

reducedbyalmost30percent(Haray,1962).

• Multi-threading–itallowstheapplicationtodelivermaximumprocessingpowerby

running multiple threads concurrently (Javaworld.com, 1996). A graph colouring

multi-threadedsolutionwasimplementedbyusinglocksassuggestedbySinghaletal.

(2015).However,becauseoftheinstabilityandmarginalperformanceimprovements

of the multi-threaded implementation, the algorithms incorporated into the final

graphcolouringtooladoptedtheoriginalsingle-threatedsolution.

Althoughchallenging,thedevelopmentofamoreefficientimplementationofthealgorithms

allowedanaccuratecomparisonoftheimplementedgraphcolouringheuristics.Therefore,

theimprovedimplementationofthealgorithmswasconsideredappropriateforthereport

generatorfeatureofthetool,asitwillbefurtherdiscussedinthechapter.

5.4.2REPORTGENERATOR

The report generator feature allows the user to compare implemented graph colouring

algorithms by running them on a large data set of graphs. Although the componentwas

initiallyusedexclusivelyforresearchpurposes,itwaslaterdecidedtoincludeitintothegraph

colouringillustrationtool.

43

1. generateReport(noOfGraphs; sizeOfGraph) { 2. 3. for index = 1 -> noOfGraphs { 4. graph = generateRandomGraph(sizeOfGraph); 5. for each algorithm { 6. algorithm.colourGraph(graph); 7. results.add(k and execution time); 8. } 9. } 10. 11. createReport (results); 12. }

Figure28.ReportGeneratorclasspseudo-code.

In order to better understand the component’s flow, the simplified pseudo-code of the

generateReportmethodispresentedinFigure28.Themethod’sinputiscomposedof

thesimulation’sparameters:thenumberofgraphsandsizeofeachgraph.Furthermore,the

methodgeneratesarandomgraphandrunseachalgorithmonthegeneratedgraph.Lastly,

theresultsofthesimulationarestoredintoalist,whichisthensentasaparametertothe

createReportmethod.

Oneoftheimplementationchallengesofthereportgeneratortoolwasrepresentedbythe

format of the output. Initially, a non-formatted text file was considered appropriate.

However,oncethefeaturewasincorporatedintothegraphcolouringillustrationtool,amore

visually appealing solution was implemented using the DynamicReports external library

(Dynamicreports.org,2016).Moreover,amulti-threadedsolutionwasimplementedinorder

toensurethattheuserisabletousethegraphcolouringillustrationtoolduringthelengthy

reportgenerationprocess.PleaseseeFigure29forasnippetofadynamicgeneratedreport

analysing5graphswith100nodeseach.Moreover,thefullgeneratedreportisenclosedin

AppendixD.

44

Figure29.Snippetofadynamicgeneratedreport(5graphs;100nodeseach).

Furthermore,theremainingofthechapteranalysestheFront-Endimplementationprocess.

5.5FRONT-ENDIMPLEMENTATION

As emphasised throughout the report, the Front-End implementation represented the

project’s core aspect. The main challenge of implementing a UI that would deliver the

requirements discussed in 3.3 was represented by the limited graphical capabilities of

standardJava™.However,theresearchprocesshighlightedabroadrangeoffreelyavailable

externallibrariesthatwouldenhancethevisualappearanceoftheillustrationtool.Moreover,

theimplementationofthetool’sfeaturesrequiredtheincorporationofseveralUIlibrariesin

thesameJFrame1.Forexample,theAlgorithmTutorialPanelillustratedinFigure30required

the implementation and coordination of four libraries: GraphStream for the graph’s

visualisation,SwingXforthenavigationbuttonsinthebottom-rightcorner,whilethepanel

containingthealgorithm’sdetailsrequiredtheuseofGraphics2DandJGraphT.

1 “An extended version of java.awt.Frame that adds support for the JFC/Swingcomponentarchitecture”(Oracle.com,2016).

45

Figure30.AlgorithmTutorialPanel.

TheinitialversionsoftheUIenclosedseveralstepsoftheapplicationworkflowintothesame

frame.However,itwaslaterdecidedtoimplementadistinctscreenforeachoneofthetool’s

stages. Therefore, the main UI frame encloses a Container2 that switches the displayed

JPanel3accordingtotheuser’sprogressthroughouttheapplication.Moreprecisely,theUIis

composedofthefollowingscreens:

• InputPanel–allowstheusertoinputagraph.

• AlgorithmPanel–allowstheusertoselectthealgorithmandtherunmode:simple

algorithm,comparealgorithmsoralgorithmtutorial.

• DocumentationPanel–detailsthetheoreticalaspectsofthealgorithms.

• Colouring Panel – illustrates the coloured graph and offers information about the

executiontimeandthechromaticnumber.

• ComparePanel–visuallycomparestwographcolouringalgorithms.

• TutorialPanel–offerstheuserawalkthroughofthegraphcolouringalgorithm.

• ReportGeneratorPanel–allowstheusertoinputthesimulationparameters.

PleaseseeAppendixEforadetailedwalkthroughofthegraphcolouringillustrationtool.

2“AgenericAbstractWindowToolkit(AWT)containerobjectisacomponentthatcancontainotherAWTcomponents”(Oracle.com,2016).3“JPanelisagenericlightweightcontainer”(Oracle.com,2016).

46

ThecoreelementoftheUIisrepresentedbythepanelillustratingthegraph,namedinthis

projectas“graphcanvas”.ImplementedusingtheGraphStreamexternallibrary,thegraph

canvas representsadynamiccomponent thatallows theuser todirectly interactwith the

displayednodesandedges.However,thevisualbenefitsofintegratingthisexternallibrary

broughtupthedisadvantageofahighmemoryusage.Therefore,theflyweightdesignpattern

mentioned in 4.4.1 allowed an efficient reuse of the same graph canvas throughout the

application.Morespecifically,thegraphcanvaswasimplementedasaUIcomponentshared

byseveralscreens,factwhichallowedtheapplicationtosaverenderingtimeandlowerthe

memoryusage.


This chapter has reviewed the key aspects of the implementation stage. The first section

offeredabriefoverviewoftheagilesoftwareengineeringmethodology.Furthermore,the

implementationframeworkandtheconsideredexternallibrarieswereanalysed.Lastly,the

Back-EndandFront-Endimplementationswerediscussed.

47

CHAPTER6:TESTINGANDEVALUATION

6.1OVERVIEW

Thischapterdescribesanddiscussesthemethodsusedinthetestingandevaluationstages

of theproject.The first sectionexplains the testingprocessofboth theBack-Endandthe

Front-End.Thesecondpartmovesontodescribeindetailtheevaluationphaseoftheproject.

6.2TESTING

AccordingtoMyers,SandlerandBadgett(1979)testingaddsvaluebyraisingthequalityand

reliability of the program.Whittaker (2000) also highlights the importance of testing and

characterisesthispartofsoftwaredevelopmentasdifficultandtime-consuming.Moreover,

AmmannandOffutt(2008)claimthatseverallevelsofsoftwaretestingarerequiredinorder

to cover specific development activities: acceptance testing, system testing, integration

testing, module testing and unit testing. The advantages of testing illustrated by the

researched literature motivated the decision to exhaustively test the graph colouring

illustrationtool.Furthermore,thetestingprocesswillbeanalysedbydiscussingtheBack-End

andFront-Endtesting.

6.2.1BACK-ENDTESTING

TheaimofBack-Endtestingwastoensurethattheimplementedgraphcolouringalgorithms

producecorrectresultsandthatthedifferentsystemcomponentscommunicateefficiently

betweenthem.Asaresult,an80percentcodecoveragewasachievedbyimplementingunit,

integrationandfunctionaltests:

• Unittestingcanbedefinedas“testingofindividualunitsorgroupsofrelatedunits”

(Runeson,2006).Moreover,KoomenandPol(1999)claimthatunittestingneedsto

becompletedbytheapplicationdevelopertodemonstratethattheprogrammeets

the user requirements. In the case of the graph colouring illustration tool, the

implementedunittestscoveredbothtrivialusecasessuchastheadditionofanode

toagraphandmorecomplexcasessuchasensuringthatanimplementedalgorithm

colourstheinputgraph.

48

• Integration testing aims to identify if the link between the different system

componentsiscorrectlyimplemented(Hartmann,ImoberdorfandMeisinger,2000).

Forexample,anintegrationtestwasimplementedinordertocheckifarandomgraph

canbecreatedduringthereportgenerationprocess.However,thistypeoftestinghas

limitedcapabilitiesinevaluatingifuserrequirementsaremet.

• Functionaltestingaimstoevaluateifacomponentproducesvalidoutputbytesting

its logic (Beizer, 1995). More precisely, tests were implemented to check if the

algorithmsproducedvalidcolouredgraphsaccordingtotheimplementedheuristics.

6.2.2FRONT-ENDTESTING

Front-End testing represented themost challenging aspect of the project’s testing stage,

mainlybecauseofthelimitedsolutionssuggestedbytheresearchedliterature.Consequently,

takingintoaccounttheadviceofseveralindustryrepresentativesitwasdecidedtodividethe

Front-EndtestingprocessintomanualandautomatedUItesting.

ManualUItestinginvolvedanexhaustiveuseoftheapplication.Moreover,inordertoensure

asystematictestingofthebroadrangeofUIfeatures,alistofscenariosastheoneillustrated

in Figure 31was created. The testing scenarioswere developed during the requirements

gathering sessions.Oncea certain featurewas implemented, thecorresponding scenarios

wereexecutedand the testing resultswere recorded. Lastly, auser storywas considered

completedonlywhenallthetestscenarioswerepassed.

Figure31.SampleUItestingscenarios

Themaindisadvantageofmanualtestingwasrepresentedbythelongperiodoftimerequired

fortestingall the278UItestscenarios.Asaresult,automatedUItestingwasconsidered.

AccordingtoUhrig(2012),FESTrepresentsasimpleandintuitivecontext-sensitivetesting-

49

framework.Moreover, theframework’seasysetupprocessandtheabilitytoruncomplex

functionaltestsmotivatedthedecisionofimplementingit.Asaresult,thetimerequiredto

runandverifyalltheUIscenarioswasreducedby95percent.

IntheexampleenclosedinFigure32,thetestAddNodemethodteststhefunctionalityof

the“Addnode”buttonontheInputPanel.Theaimofthetestistosimulate500“Addnode”

buttonclicksandtocheckifthegraphdisplayedbythegraphcanvascontains500nodes.If

the test fails, the testing frameworkprovides the stack traceanda screen captureof the

applicationinordertounderstandtherootcauseoftheerror.

1. public class InputPanelTesting { 2. 3. private FrameFixture demo; 4. private MainFrame mainFrame; 5. 6. private void addNodesUsingButton(int noOfNodes) { 7. String startButton = WelcomePanel.startButton.getName(); 8. demo.button(startButton).click(); 9. 10. String addNodeButton = InputPanel.btnAddNode.getName(); 11. 12. for (int index = 1; index <= noOfNodes; index++) { 13. demo.button(addNodeButton).click(); 14. } 15. } 16. @Before 17. public void setUp() throws InterruptedException { 18. mainFrame = new MainFrame(); 19. demo = new FrameFixture(mainFrame); 20. } 21. 22. @After 23. public void tearDown() { 24. demo.cleanUp(); 25. } 26. 27. @Test 28. public void testAddNodes() { 29. int numberOfNodes = 500; 30. addNodesUsingButton(numberOfNodes); 31. Assert.assertEquals(InputPanel.getGraph().getNumberOfNodes(), 32. numberOfNodes); 33. } 34. }

Figure32.SampleUIautomatedtest.

Inthissub-section,ithasbeenarguedthatthetestingprocessvalidatedtheimplementation

of the requirements discussed in 3.3.3 and 3.3.4. However, the efficiency of the graph

50

colouringalgorithmswasnotevaluated.Whatfollowsisadescriptionoftheevaluationstage

oftheproject.

6.3EVALUATION

Theevaluationphaseoftheprojectfocusedoncomparingtheimplementedgraphcolouring

algorithmsusingrandomlygeneratedgraphsandDIMACSbenchmarkgraphinstances.While

thefirstsimulationcomparedthedifferentheuristics,thesecondtypeofevaluationaimedto

comparetheimplementedalgorithmswiththesolutionsproposedbythespecialityliterature.

ID Numberofgraphs Graphsize(nodes)

E1 10,00010E2 100,000

E3 1,000,000E4 10,000

100E5 100,000E6 1,000,000E7 10,000

1,000E8 100,000E9 1,000,000

Table9.Evaluationexperiments.

In order to evaluate the considered graph colouring heuristics several experiments were

conductedasillustratedinTable8.Theevaluationconsideredgraphscontaining10,100and

1,000nodes.Moreover,threesimulationswithdifferent-sizeddatasetswereconductedfor

eachgraphsize.TheresultsoftheevaluationareillustratedinFigure33andFigure34.

Figure33.Chromaticnumber.

3.7

7.5

18

3.7

7.5

17

3.46.3

10

3.46.3

9.8

3.46.7

16

3.46.3

10

02468101214161820

10nodes 100nodes 1000nodes

Chromaticnum

ber

Chromaticnumber(k)

Greedy

RS

LF

SL

CS

51

Figure34.Executiontime.

Asexpected,thealgorithmsproducedsimilarresultsinthecontextofsmallgraphs.However,

adifferencewasobservedinthecaseofgraphswith100and1000nodes.TheSLalgorithm

produced the best average chromatic number results, closely followed by LF and SLF.

Nevertheless,thealgorithmsabletocolourthegraphwiththeminimumnumberofcolours

hadthelargestexecutiontimes.Moreover,whencomparingtheSL,LFandSLFalgorithmsa

noticeableexecutiontimedifferencecanbeobserved.Lastly,itneedstobementionedthat

the choice of a particular algorithm for completing a certain task should take into

consideration a balance between the chromatic number result and the execution time.

Therefore, the algorithms evaluation stage identified the SL algorithm as the best overall

sequentialgraphcolouringalgorithmwhencomparedwiththeotherresearchedoptions.

The last part of the evaluation stage proposed running similar simulations using DIMACS

benchmarkgraphs.Figure35summarises theassessmentofSLalgorithm’sefficiency.The

algorithm was evaluated using several DIMACS benchmark graph instances: dsjc250.5,

dsjc500.1,etc.Furthermore,theresultedchromaticnumber(k)wasthencomparedwiththe

best knownkvalue.The implementedSLalgorithmmanaged tomatch thebest k for the

dsjc250.5graphandtoobtaincloseresultsforfourotherbenchmarkgraphs.However,due

to the technical limitations of the chosen programming language, the number of colours

0.1 0.4

25.6

0.1 0.4

27.5

0.1 0.7

140.8

0.2 1

32.4

0.1 0.5

26.2

0.2 4.4

201.1

020406080

100120140160180200220

10nodes 100nodes 1000nodes

Executiontim

eAverageexecutiontime(milliseconds)

Greedy RS LF SL CS SLF

52

requiredtoproperlycolourabenchmarkgraphwereinaverage20percentlargercompared

withthebestvalues.

Figure35.DIMACSevaluation.

Once the algorithms evaluation stage was completed, the UI evaluation was conducted

throughausertestingprocess.Moreprecisely,20technicalandnon-technicalstudentswere

askedtoevaluatetheoveralluser-experienceofferedbythegraphcolouringillustrationtool.

17intervieweeclaimedthatsoftware’sintuitiveUIdeliversagoodlearningexperience,while

the remaining3 stated that theapplication required further improvements. Thegathered

feedback acted as a foundation for the future improvement areas discussed in the next

chapter.


Thechapterbeganbyhighlightingtheimportanceofsoftwaretesting.Itwentontodiscuss

anddescribetheconsideredtestingmethods in thecasetheBack-EndandtheFront-End.

Lastly,theresultsoftheevaluationstagewereanalysed.

2812

48

126

20

85

223

66

98

234

84

122

25 25 282815

57

130

35

102

239

68

110

248

105

159

36 38 29

020406080

100120140160180200220240

K

DIMACSgraph

DIMACSevaluation

bestK K

53

CHAPTER7:CONCLUSION

7.1OVERVIEW

Thepurposeofthischapteristosummarisethedevelopmentprocessofthegraphcolouring

illustration tool.More precisely, the project’s achievements are discussed, followed by a

presentationofapplication’slimitationsandfutureimprovementareas.

7.2REPORTSUMMARY

Firstly,thereportofferedabrief introductiontographcolouringbydiscussingacoupleof

algorithmsandillustratingreallifeapplicationsofgraphcolouring.Thesecondpartdiscussed

the requirements engineeringprocess anddescribed theadopted requirements gathering

methodology. Furthermore, the system design decisions weremotivated, followed by an

illustrationoftheimplementationprocess.Lastly,thereportemphasisedtheimportanceof

softwaretestingandexaminedtheresultsoftheevaluationstage.

7.3ACHIEVEMENTS

Theaimoftheprojectwastodevelopagraphcolouringillustrationtool.Duetotheproject’s

openness,anincrementalsoftwaredevelopmentapproachwasadoptedinordertoensurea

continuousdeliveryoffeatures.Asaresult,animprovedversionwasreleasedeverycouple

ofweeks as described earlier in the report. The final version (4.1) of the illustration tool

includedabroadrangeoffeatures,suchas:

• threedifferentgraphinputmethods(drawgraph,uploadgraph,generategraph)

• threerunningmodes(singlecolouring,comparealgorithms,algorithmtutorial)

• adynamicreportgeneratortool

• dynamicgraphcanvas

• abilitytosaveagraph’svisualrepresentation

• documentationpaneldetailingtheimplementedalgorithms.

Furthermore, the implementedUI received good feedback fromapool of 20 interviewed

technicalandnon-technical students.Lastly, theefficiencyof the implementedalgorithms

54

wasdemonstratedbyevaluatingthemusingbothrandomlygeneratedgraphsandDIMACS

benchmark graph instances.However, theproduced graph colouring tool has a couple of

limitations.

7.4LIMITATIONSANDFUTUREIMPROVEMENTAREAS

Thelimitationsoftheimplementedgraphcolouringtoolcanbeclassifiedas:

• UIlimitations–althoughthegraphcanvascandisplayagraphwithasmanyas30,000

nodes,graphswithmorethan2,000nodescannotbedisplayedinanappealingvisual

manner.

• Algorithms limitations – as previously explained in 5.4.1, the object-oriented

implementationisnotefficientinthecaseoflargegraphs.

• Platform limitations – because of the considered programming language and

implementationframework,theillustrationtoolcannotbeusedonmobiledevicesor

computersnotrunningJava™8.

Furthermore, future improvementareascanbederived fromthetool’s limitations.Please

findbelowalistofsuchimprovements:

• Alargersetofgraphcolouringalgorithms.

• Amoreflexiblegraphcanvasthatwouldallowuserstochangetheviewpoint.

• Allowmultipleuserstousetheplatformatthesametime.Forexample,a lecturer

remotelyofferingagraphcolouringalgorithmtutorialonastudent’smachine.

• Amoreefficientobject-orientedmulti-threadedimplementationofthealgorithms.

• Aweb-basedinterfacethatwouldallowcross-platformuse.

• Morestatisticsofferedbythedynamicreport.


This final chapter has offered an overview of the project’s achievements, followed by a

discussion around the graph colouring illustration tool’s limitations and possible future

improvementareas.

55

REFERENCELIST

1) AbrahamA.,LiuH.,andChangT.G.,VariableNeighbourhoodParticleSwarmOptimizationAlgorithm,GeneticandEvolutionaryComputationConference(GECCO-2006),Seattle,USA,2006.

2) Adzic,G.andEvans,D. (2014).Fiftyquick ideas to improveyouruser stories. London:NeuriConsultingLLP.

3) Agilemanifesto.org.(2016).ManifestoforAgileSoftwareDevelopment.[online]Availableat:http://agilemanifesto.org[Accessed28Apr.2016].

4) Ammann,P.andOffutt,J.(2008).Introductiontosoftwaretesting.NewYork:CambridgeUniversityPress.

5) Asratian, A. and de Werra, D. (2002). A generalized class–teacher model for sometimetablingproblems.EuropeanJournalofOperationalResearch,143(3),pp.531-542.

6) Balakrishnan,R.andRanganathan,K.(2012).ATextbookofGraphTheory.7) Beizer,B.(1995).Black-boxtesting.NewYork:Wiley.8) Boehm, B. and Turner, R. (2004). Balancing agility and discipline. Boston: Addison-

Wesley.9) Bondy, J. andMurty, U. (1976).Graph theorywith applications. New York: American

ElsevierPub.Co.10) Briggs,P.,Cooper,K.andTorczon,L. (1994). Improvements tographcoloring register

allocation.ACMTransactionsonProgrammingLanguagesandSystems,16(3),pp.428-455.

11) Burke,E.,Elliman,D.andWeare,R.(1993).AUniversityTimetablingSystembasedonGraph Colouring and Constraint Manipulation. Journal of Research on Computing inEducation,26.

12) Chaitin,G.(1982).Registerallocation&spillingviagraphcoloring.ACMSIGPLANNotices,17(6),pp.98-101.

13) Chaitin,G.,Auslander,M.,Chandra,A.,Cocke,J.,Hopkins,M.andMarkstein,P.(1981).Registerallocationviacoloring.ComputerLanguages,6(1),pp.47-57.

14) Charatan,Q.andKans,A.(2009).Javaintwosemesters.Maidenhead,Berks.:McGraw-HillEducation.

15) Clark,J.andHolton,D.(1991).Afirstlookatgraphtheory.Singapore:WorldScientific.16) Clerc, M. and Kennedy, J. (2002). The Particle Swarm-explosion, Stability, and

Convergence inAMultidimensionalComplexSpace. IEEETransactionsonEvolutionaryComputation.

17) Cobb,C.(2011).Makingsenseofagileprojectmanagement.Hoboken,N.J.:Wiley.18) Cohena, D., Lindvalla, M. & Costa, P. (2004) “An Introduction to Agile Methods”,

AdvancesinComputers,no.62:1-66.19) Cohn,M.(2004).Userstoriesapplied.Boston:Addison-Wesley.20) Cohn,M.(2006).Agileestimatingandplanning.UpperSaddleRiver,NJ:PrenticeHall

ProfessionalTechnicalReference.21) Crescenzi,P.andKann,V. (1998).Howtofindthebestapproximationresults.SIGACT

News,29(4),pp.90-97.22) Deo,N. (1974).Graph theorywith applications to engineering and computer science.

EnglewoodCliffs,N.J.:Prentice-Hall.

56

23) Drake, D. (1996). Introduction to Java threads. [online] JavaWorld. Available at:http://www.javaworld.com/article/2077138/java-concurrency/introduction-to-java-threads.html[Accessed28Apr.2016].

24) Eckstein,R.(2007).JavaSEApplicationDesignWithMVC.[online]Oracle.com.Availableat: http://www.oracle.com/technetwork/articles/javase/index-142890.html [Accessed28Apr.2016].

25) Erben,W.andKeppler,J.(1995).Ageneticalgorithmsolvingaweeklycourse-timetablingproblem.ProceedingsoftheFirstInternationalConferenceonthePracticeandTheoryofAutomatedTimetabling.

26) Galitz,W.(2007).Theessentialguidetouserinterfacedesign.Indianapolis,IN:WileyPub.27) GEAMBAŞU,C.,JIANU,I.,JIANU,I.andGAVRILA,A.(2011).INFLUENCEFACTORSFORTHE

CHOICEOFASOFTWAREDEVELOPMENTMETHODOLOGY.AccountingandManagementInformationSystems,10.

28) Glass, R. (2002). Facts and fallacies of software engineering. Boston, MA: Addison-Wesley.

29) Glinz,M.(2007).OnNon-FunctionalRequirements.15thIEEEInternationalRequirementsEngineeringConference(RE2007).

30) Goers, R.,Gregory,G. andDeboy, S. (2016). Log4j – Log4j 2Guide - Apache Log4j 2.[online]Apache.org.Availableat:http://logging.apache.org/log4j/2.x/[Accessed28Apr.2016].

31) Google.com.(2016).GoogleCodeArchive-Long-termstorageforGoogleCodeProjectHosting.. [online] Available at: https://code.google.com/archive/p/fest/ [Accessed 28Apr.2016].

32) Gotlieb,C.(1963).Theconstructionofclass-teachertime-tables.Proc.IFIPCongress.33) Grand,M.(2003).PatternsinJava.Indianapolis,Ind.:WileyPub.34) Hanson, J. (2015).Modularity in Java9:StackingupwithProject Jigsaw,Penrose,and

OSGi. [online] JavaWorld. Available at:http://www.javaworld.com/article/2878952/java-platform/modularity-in-java-9.html[Accessed28Apr.2016].

35) Harary,F.(1962).TheDeterminantoftheAdjacencyMatrixofaGraph.SIAMRev.,4(3),pp.202-210.

36) Hartmann,J.,Imoberdorf,C.andMeisinger,M.(2000).UML-Basedintegrationtesting.ProceedingsoftheInternationalSymposiumonSoftwareTestingandAnalysis-ISSTA'00.

37) Havet,F.(2007).Graphcolouringandapplications.38) Hertz,A.anddeWerra,D.(1989).Connectedsequentialcolorings.DiscreteMathematics,

74(1-2),pp.51-59.39) HollnagelE.,2003,HandbookofCognitiveTaskDesign,(CRCPress:1Jun2003)p17-33.40) Holyer,I.(1981).TheNP-CompletenessofEdge-Coloring.SIAMJ.Comput.,10(4),pp.718-

720.41) Ibm.com. (2016). IBM Knowledge Center. [online] Available at:

http://www.ibm.com/support/knowledgecenter/#!/ssw_aix_72/com.ibm.aix.performance/advantages_java.htm[Accessed28Apr.2016].

42) Jacobson, I., Booch, G. and Rumbaugh, J. (1999). The unified software developmentprocess.Reading,Mass:Addison-Wesley.

43) JacobsonI.,SpenceI.,BittnerK.,Dec2011,UseCase2.0TheGuideToSucceedingWithUseCases,p5-10.

57

44) Jgrapht.org.(2016).WelcometoJGraphT-afreeJavaGraphLibrary.[online]Availableat:http://jgrapht.org[Accessed28Apr.2016].

45) Jordan,P.(1996).Usabilityevaluationinindustry.London:Taylor&Francis.46) Jung.sourceforge.net.(2016).JUNG-JavaUniversalNetwork/GraphFramework.[online]

Availableat:http://jung.sourceforge.net[Accessed28Apr.2016].47) Koomen, T., Pol M., Test Process Improvement—A Practical Step-by-Step Guide to

StructuredTesting,Addison-Wesley,1999.48) Kortright,E.(1997).ModelingandsimulationwithUMLandJava.Proceedingsof1997

SCSSimulationMulticonference.49) Kubale,M.(2004).Graphcolorings.Providence,R.I.:AmericanMathematicalSociety.50) Larman, C. (2003). Agile and iterative development. Boston, Mass. [u.a.]: Addison-

Wesley.51) Lavrov, S. (1961). Store economy in closed operator schemes. USSR Computational

MathematicsandMathematicalPhysics,1(3),pp.810-828.52) Leffingwell,D.(2007).Scalingsoftwareagility.UpperSaddleRiver,NJ:Addison-Wesley.53) Lehman,E.,Leighton,F.andMeyer,A.(2012).MathematicsforComputerScience.54) Liskov,B.andGuttag,J.(2000).ProgramdevelopmentinJava.Boston:Addison-Wesley.55) Marx,D.(2003).Graphcolouringproblemsandtheirapplicationsinscheduling.56) Matula,D.,Marble,G.andIsaacson,D.(1972).Graphcoloringalgorithms.GraphTheory

andComputing.57) Microsoft.com. (2016). User Interface Principles (Windows). [online] Available at:

https://msdn.microsoft.com/en-us/library/windows/desktop/ff728831(v=vs.85).aspx[Accessed28Apr.2016].

58) MinerS.K.,ElmohamedS.,andYauH.W.,Optimizingtimetablingsolutionsusinggraphcoloring.1995NPACREUprogram,NPAC,SyracuseUniversity,1995.

59) Moran,A.(2015).ManagingAgile.60) Myers,G.andBadgett,T.(1979).Theartofsoftwaretesting.Hoboken,NJ:Wiley.61) Nilsson, A. (2005). Advances in information systems development. New York, NY:

Springer.62) Docs.oracle.com. (2016). Container (Java Platform SE 7 ). [online] Available at:

https://docs.oracle.com/javase/7/docs/api/java/awt/Container.html [Accessed 29 Apr.2016].

63) Oracle.com. (2016). Graphics2D (Java Platform SE 7 ). [online] Available at:https://docs.oracle.com/javase/7/docs/api/java/awt/Graphics2D.html [Accessed 28Apr.2016].

64) Oracle.com. (2016). JFrame (Java Platform SE 7 ). [online] Available at:https://docs.oracle.com/javase/7/docs/api/javax/swing/JFrame.html [Accessed29Apr.2016].

65) Docs.oracle.com. (2016). JPanel (Java Platform SE 7 ). [online] Available at:https://docs.oracle.com/javase/7/docs/api/javax/swing/JPanel.html [Accessed 29 Apr.2016].

66) Pohl,K.(2010).Requirementsengineering.Heidelberg:Springer.67) Pressman,R.(2004).Softwareengineering.68) Pressman,R.(2009).Softwareengineering.NewYork:McGraw-HillHigherEducation.69) Ramamoorthy, Prakash, Wei-Tek Tsai, and Usuda, (1984). Software Engineering:

ProblemsandPerspectives.Computer,17(10),pp.191-209.

58

70) REDL,T.(2004).OnUsingGraphColoringtoCreateUniversityTimetableswithEssentialandPreferentialConditions.

71) Rees,M.(2002).Afeasibleuserstorytoolforagilesoftwaredevelopment?.ProceedingAPSEC'02ProceedingsoftheNinthAsia-PacificSoftwareEngineeringConference.

72) Runeson,P.(2006).ASurveyofUnitTestingPractices.73) Schildt,H.(2003).C++fromthegroundup.NewYork:McGraw-Hill/Osborne.74) Shamir,E.andUpfal,E.(1984).Sequentialanddistributedgraphcoloringalgorithmswith

performanceanalysisinrandomgraphspaces.JournalofAlgorithms,5(4),pp.488-501.75) Shamizi, S. and Lotfi, S. (2011). Register allocation via graph coloring using an

evolutionaryalgorithm.76) Shen,W.andLiu,S.(2003).Formalization,TestingandExecutionofaUseCaseDiagram.77) Shore,J.andWarden,S.(2008).Theartofagiledevelopment.O'ReillyMedia,Inc.78) Singhal, N., Peri, S. and Kalyanasundaram, S. (2015). Multi-threaded Graph Coloring

AlgorithmforSharedMemoryArchitecture.79) Sommerville,I.(2007).Softwareengineering.Boston:Pearson.80) Stone,D.(2005).Userinterfacedesignandevaluation.Amsterdam:Elsevier.81) Swingx.java.net. (2016). SwingLabs :: Swing Component Extensions — Project Kenai.

[online]Availableat:https://swingx.java.net[Accessed28Apr.2016].82) Topcuoglu,H.R.,Demiroz,B.,Kandemir,M.:SolvingtheRegisterAllocationProblemfor

Embedded Systems Using a Hybrid Evolutionary Algorithm. IEEE Transaction onEvolutionaryComputation11(5)(October2007)

83) Tracy,K.andBouthoorn,P.(1996).Object-orientedartificialintelligenceusingC++.NewYork:ComputerSciencePress.

84) Trick,M. (1994).Network Resources for Coloring aGraph. [online]Mat.gsia.cmu.edu.Availableat:http://mat.gsia.cmu.edu/COLOR/color.html[Accessed28Apr.2016].

85) Uhrig, T. (2012). Automated UI testing with Swing & FEST – Thomas Uhrig. [online]Tuhrig.de. Available at: http://tuhrig.de/automated-ui-testing-with-swing-fest/[Accessed28Apr.2016].

86) User, S. (2016).DynamicReports - Free and open source Java reporting tool. [online]Dynamicreports.org. Available at: http://www.dynamicreports.org [Accessed 28 Apr.2016].

87) Vlissides,J.(1994).Designpatterns:elementsofreusableobject-orientedsoftware.88) Waite,M.andLafore,R.(1999).Object-orienteddesigninJava.89) Weitzman, L. (2006).Patent US7114127 -Method, system and program product in a

model-view-controller(MVC)programmingarchitectureforinter-objectcommunicationwith transformation. [online] Google Books. Available at:https://www.google.com/patents/US7114127[Accessed28Apr.2016].

90) Whittaker,J.(2000).Whatissoftwaretesting?Andwhyisitsohard?.IEEESoftw.,17(1),pp.70-79.

91) Wiegers,K.(2003).SoftwareRequirements,2ndedition.MicrosoftPress.92) Xhafa, F. and Abraham, A. (2008). Metaheuristics for scheduling in industrial and

manufacturingapplications.Berlin:Springer.93) ZhongN.,HuJ.,MotomuraS.,WuJ.,andLiuC.“BuildingAData-miningGridforMultiple

HumanBrainDataAnalysis”.ComputationalIntelligence,2005,21(2),pp.177.

59

APPENDIXLIST

APPENDIXA:SAMPLEDOCUMENTATIONOFITERATIONPLANNINGANDREVIEWSESSIONS

Iteration0

Figure36.Iteration0planningmeeting.

Figure37.Iteration0reviewmeeting.

60

Iteration5

Figure38.Iteration5planningmeeting.

Figure39.Iteration5reviewmeeting.

61

APPENDIXB:ITERATIVEANDINCREMENTALSOFTWAREIMPLEMENTATION

Figure40,Figure41,Figure42andFigure43illustratetheevolutionoftheInputPanelduring

severaliterations.

Figure40.InputPanelv1.0.


62



63

APPENDIXC:TOOLSANDDEVELOPMENTPLATFORM

Hardware:

• Model:MacBookPro

• CPU:2.4GHzIntelCorei5

• Memory:8GB1600MHzDDR3

Software:

• OperatingSystem:OSXElCapitan

• IDEs:EclipseLuna,IntelliJIDEA15CE

• IDEPlugin:AbstractWindowsBuilder

• VMarguments:-Xmx4096m

64

APPENDIXD:SAMPLEREPORT

Figure44.Samplereport

65

APPENDIXE:GRAPHCOLOURINGILLUSTRATIONTOOLWALKTHROUGH

1)Graphinput

Figure45.InputPanel.

Figure45illustratestheInputPanel.Theapplicationallowstheuserto:1)manuallydrawa

graph2)generaterandomgraphor3)inputgraphusingfileupload.Onceagraphisdefined

asinput,theusercanproceedtothenextscreenbypressingtherightfacingarrowinthe

bottom-rightcorner.

2)SelectAlgorithm

Figure46.AlgorithmPanel.

66

TheAlgorithmPanelpresentinFigure46allowstheusertoselectoneofthethreeavailable

runmodes:1)simplealgorithm2)comparealgorithmsor3)algorithmtutorial.Moreover,the

userneedstoselectanalgorithmusingtheprovideddropdownmenus.

3)Colourgraph

3.1)SimpleAlgorithm

Figure47.ColouringPanel.

3.2)Comparealgorithms

Figure48.ComparePanel.

67

3.2)AlgorithmTutorial

Figure49.TutorialPanel.

4) Documentation

Figure50.DocumentationPanel.

Figure50illustratestheDocumentationPanelthatenclosesdetailsabouttheimplemented

algorithms.

a software tool to illustrate graph...

Documents