Wilson, David
A Framework for the Definiton of a Generative Design Pattern
Original Citation
Wilson, David (2008) A Framework for the Definiton of a Generative Design Pattern. Post
Doctoral thesis, University of Huddersfield.
This version is available at http://eprints.hud.ac.uk/id/eprint/6969/
The University Repository is a digital collection of the research output of the
University, available on Open Access. Copyright and Moral Rights for the items
on this site are retained by the individual author and/or other copyright owners.
Users may access full items free of charge; copies of full text items generally
can be reproduced, displayed or performed and given to third parties in any
format or medium for personal research or study, educational or notforprofit
purposes without prior permission or charge, provided:
•
The authors, title and full bibliographic details is credited in any copy;
•
A hyperlink and/or URL is included for the original metadata page; and
•
The content is not changed in any way.
For more information, including our policy and submission procedure, please
contact the Repository Team at: [email protected].
DavidWilson
Adissertation submittedinpartialfulllment
of therequirementsforthedegree of
Dotorof Philosophy
The Shoolof Computing and Engineering
The UniversityofHudderseld
Supervisor
DrGary Allen
Dr AdrianJakson
Helen,thybeautyistome LikethoseNieanbarksof yore, That gently,o'er aperfumed sea, Theweary,way-worn wandererbore Tohisownnativeshore.
Ondesperateseaslongwonttoroam Thyhyainthhair, thylassifae, ThyNaiadairshavebrought mehome Totheglorythat wasGreee,
Andthegrandeurthat wasRome.
Lo! inyonbrilliantwindow-nihe Howstatue-like Iseethee stand, Theagate lampwithinthyhand! Ah,Psyhe,from theregionswhih AreHoly-Land!
In presenting this dissertation in partial fulllment of the requirements for the degree of Dotor of
Philosophy at the University of Hudderseld, I delare that this work has not been submitted for a
degree at thisoranyother University,andthat unlessotherwisestated, itis entirely myownwork.
DavidWilson
First and foremost I would like to thank my supervisor, Dr. Gary Allen for his advie, support and
feedbakthroughoutthisprojet.
I would also like to thank Professor Lee MCluskey and Dr. Christopher Newman for their support,
advie andoasionalfeedbak.
IamgratefultotheUniversityofHudderseldandtheaademistaintheDepartmentofComputing
andEngineeringfortheirsupportandoasionaladvie,and tothetehnialdepartment forproviding
theresoures onwhihto developmyresearh work.
Muhofmytimewasspentinthemainresearhers oÆeintheComputingandMathematisbuilding,
andIwouldliketoextendmyappreiationtomyfellowresearhersformakingmystaythereapleasant
one.
Most of all, I would like to thank Dr Adrian Jakson, who provided me with the opportunity and
fundingto studyforthisprojet andthe opportunityitgave me to pursuea areerinaademia.
MydeepestappreiationgoestomywifeHelen,who'ssupportthroughoutmydegreeandthisresearh
projethas beeninvaluable. I would like to thank her forher time, her nanialsupport and forher
unwaveringommitment when timeswerehard.
Andnally,Iwouldliketothank myhildrenKelly,Skye andAilsajustforbeingthere whenIneeded
Conventionaldesignpatternsfoundinmanypatternataloguesarestatiomponentsofreusabledesign
knowledge. They are fully desriptive of the problems they willsolve, but the desriptive knowledge
and design they provide does not desribe how they an work with other patterns in a design and
development proess. Therefore, the ontention of this thesis is that the knowledge ontained within
stati design patterns is inadequate for the purpose of applying the patterns to generate a software
arhiteture withtheintention of developing software systems.
ThefousofthisresearhhasbeentheinvestigationofDesignPatternsandtheirpotentialontribution
toagenerativedevelopmentpatternlanguage. Generativedesignpatternsareativeanddynami: they
desribehow toreate somethingand an be observedinthe resultingsystems they helpto reate.
To this end, a framework is presented that identies the notational qualities that an be applied to
a design pattern for the benet of implementing arhitetural design. The impratiality of stati
design patterns for arhitetural design is addressed by revising the standard design pattern with a
notationthat desribesthepatternasagenerativeomponent. Thenotation requiredforthisrevision
is abstratedinpartfrom therih setof designnotations and knowledge ontained within:
(a)thequalitydrivenproessesontainedindevelopmentmethodsthatontributedtothenowstandard
UniedModellingLanguage (UML),
(b)the desriptiveontent oftwo distintpattern lassiations
iDesign Patterns: Elementsof ReusableObjet-OrientedSoftware[45℄,
iiA Catalogueof General-PurposeSoftwareDesign Patterns[104℄ and
() aknownstudyof relationshipsbetween designpatterns
List of Figures vi
List of Tables ix
Chapter 1: Introdution 1
Chapter 2: ExploringTheLinkBetweenSoftwareDevelopmentMethodsAnd
Pat-terns 6
2.1 Introdution. . . 6
2.1.1 Pattern/ Method Analogy . . . 6
2.2 Objet-OrientedSoftwareDevelopment Methods . . . 7
2.3 ContemporarySoftware Development Methods . . . 9
2.3.1 RationalUniedProess . . . 9
2.3.2 AgileMethods . . . 14
2.3.3 Model Driven Arhiteture (MDA) . . . 22
2.4 Summary . . . 25
Chapter 3: Understanding Design Pattern Notation 27 3.1 Introdution. . . 27
3.2 Patternsin Objet-OrientedSoftware. . . 27
3.2.1 ThePatternConept. . . 27
3.2.2 Idioms . . . 28
3.2.5 APatternLanguage . . . 32
3.2.6 DesignPatternStruture . . . 35
3.2.7 Narrative Form (Portland) . . . 37
3.3 Deninga Template . . . 40
3.4 Summary . . . 55
Chapter 4: Relationships Between Patterns 56 4.1 Introdution. . . 56
4.2 Classiation ofDesign Patterns . . . 57
4.2.1 HighLevelClassiation. . . 57
4.2.2 Low Level Classiation . . . 59
4.3 IndividualRelationships . . . 64
4.4 PatternMap . . . 68
4.5 DesribingRelationships . . . 69
4.5.1 Classiation . . . 70
4.5.2 ProblemSolving . . . 71
4.5.3 Assoiation Type . . . 74
4.6 Summary . . . 76
Chapter 5: Pattern Modelling 77 5.1 Introdution. . . 77
5.2 Sequene Diagrams . . . 78
5.3 ClassDiagrams . . . 82
6.1 Introdution. . . 90
6.2 Generative Proess . . . 91
6.2.1 SummaryofChapter Two . . . 91
6.2.2 SummaryofChapter Three . . . 91
6.2.3 SummaryofChapter Four . . . 91
6.2.4 SummaryofChapter Five . . . 92
6.3 Generative PatternFormat . . . 92
6.4 CompositeasaGenerative Design Pattern. . . 94
6.5 Conlusion . . . 104
6.6 Summary . . . 105
Chapter 7: Evaluation 106 7.1 Introdution. . . 106
7.1.1 EvaluationStrategy . . . 107
7.2 Metris . . . 108
7.3 Stati vs. Generative Patterns . . . 110
7.3.1 Introdution . . . 110
7.3.2 ASimpleCaseStudy usingCompositeand Deorator . . . 112
7.3.3 ASimpleCaseStudy usingComposite, Commandand Builder . . . 115
7.3.4 ACase StudyusingComposite, Command, Deorator and Builder . . . 119
7.3.5 AnAlternativeCase StudyusingComposite, Command, Deorator and Builder 124 7.4 Conlusion . . . 130
Chapter 9: Future Work 135
9.1 Introdution. . . 135
9.2 Tolabelpatterns bytheir Classiation,Problem and Assoiation type . . . 136
9.2.1 Problemtype . . . 136
9.2.2 Classiationtype . . . 136
9.2.3 Relationaltype . . . 137
9.3 A denitivestandardorformulaforombiningorexludingombinationsofpatterns . . 138
9.4 Develop aase toolfordesignusinggenerative patterns . . . 139
9.5 Formal Mathematial Speiationof generative patterns . . . 139
9.6 Considerationof designpatternsfordenitionand usability . . . 140
Bibliography 141 Appendix A: Composite ombines Command 150 Appendix B: Composite ombines Builder 158 Appendix C: Builder ombines Command ombines Composite 166 Appendix D: Builder Uses Command 177 Appendix E: Relationship Trees 186 E.0.1 Strutural . . . 186
E.0.2 Creational. . . 187
E.0.3 Behavioural . . . 188
F.2 Senario 2 . . . 193
F.3 Senario 3,basedon Ekel[39℄ . . . 199
Appendix G: SoftwareMetri Suite 208 G.1 Basi[16℄. . . 208
G.2 Cohesion[16℄. . . 209
G.3 Complexity[16℄ . . . 210
G.4 Coupling[16℄. . . 213
G.5 Enapsulation[16℄ . . . 218
G.6 Halstead[16℄ . . . 219
G.7 Inheritane[16 ℄ . . . 220
G.8 Inheritane-BasedCoupling[16℄ . . . 220
G.9 Maximum[16 ℄ . . . 223
G.10Polymorphism[16℄. . . 223
G.11Ratio[16℄. . . 224
G.12TestCoverage[16℄ . . . 225
Appendix H: Additional Case-Studies 226 H.1 A SimpleCaseStudyusingCompositeand Builder . . . 226
H.2 A SimpleCaseStudyusingCommand andBuilder . . . 229
H.3 A SimpleCaseStudyusingCompositeand Command . . . 232
2.1 MDA Development Lifeyle[66℄ . . . 23
2.2 MDA TransformationProess[66 ℄ . . . 24
4.1 Relationships Between DesignPatterns. . . 58
4.2 CreationalPatternInformationHierarhy . . . 61
4.3 BehaviouralPatternInformationHierarhy . . . 62
4.4 Relationships Between DesignPatterns (Basedon Zimmer[119℄). . . 65
4.5 PatternX uses,is usedby . . . 66
4.6 PatternsRelated to Composite . . . 69
4.7 RelationshipbetweenCompositeand Deorator . . . 75
5.1 Sequene DiagramfortheBroker Pattern . . . 78
5.2 Sequene DiagramfortheBroker Pattern . . . 79
5.3 Sequene DiagramfortheDispatherView Pattern . . . 80
5.4 Dispather inControllerStrategy . . . 80
5.5 Dispather inViewStrategy . . . 81
5.6 CompositeClassDiagram . . . 83
5.7 Grand'sCompositeClassDiagram[48 ℄ . . . 84
5.8 Reverse EngineeredCompositeClassDiagram[48 ℄. . . 85
5.9 CompositePattern . . . 86
5.10 Grand'sDeorator Class Diagrams . . . 87
6.2 RelationshipbetweenCompositeandDeorator . . . 100
6.3 Use-Case Diagram- CompositeombinesDeorator . . . 101
6.4 ClassDiagram- CompositeombinesDeorator . . . 102
7.1 Generative vs. Stati{ Compositeand Deorator . . . 112
7.2 Generative vs. Stati{ Command+Composite+Builder. . . 115
7.3 Generative vs. Stati{ Command+Composite+Builder+Deorator . . . 119
7.4 ExampleAppliationusingStatiDesignPatterns . . . 124
7.5 ExampleAppliationusingDynamiDesignPatterns. . . 125
A.1 RelationshipbetweenCompositeandCommand. . . 151
A.2 Use-Case Diagram- CompositeombinesCommand . . . 151
A.3 ClassDiagram- CompositeombinesCommand . . . 152
A.4 Sequene Diagram- CompositeombinesCommand . . . 153
B.1 RelationshipbetweenCompositeandBuilder . . . 159
B.2 Use-Case Diagram- CompositeombinesBuilder . . . 159
B.3 ClassDiagram- CompositeombinesBuilder . . . 160
B.4 Sequene Diagram- CompositeombinesBuilder . . . 161
C.1 RelationshipbetweenBuilder, Commandand Composite. . . 167
C.2 Use-Case Diagram- BuilderombinesCommandombinesComposite . . . 168
C.3 ClassDiagram- CompositeombinesCommand . . . 169
C.4 Sequene Diagram- CompositeombinesCommand . . . 170
D.3 ClassDiagram- Builderuses Command . . . 179
D.4 Sequene Diagram- BuilderusesCommand . . . 180
E.1 Strutural Hierarhy . . . 186
E.2 CreationalHierarhy . . . 187
E.3 BehaviouralHierarhy . . . 188
F.1 Use-Case Diagram- CompositeombinesDeorator . . . 193
F.2 ClassDiagram- CompositeombinesDeorator . . . 194
F.3 Use-Case Diagram- CompositeombinesDeorator . . . 199
F.4 ClassDiagram- CompositeombinesDeorator . . . 200
G.1 The relationamong thedierenttypesofsupplierlasses . . . 217
H.1 Generative vs. Stati{ Compositeand Builder . . . 226
H.2 Generative vs. Stati{ Commandand Builder . . . 229
H.3 Generative vs. Stati{ Commandand Composite. . . 232
I.1 Faade asan Interfae . . . 235
3.1 Design Patterns' Notation[45℄ . . . 29
3.2 Bushmann's Pattern Notation[20℄ . . . 31
3.3 Bushmann's alternative ategoriesof Notation[19℄ . . . 32
3.4 Alexander's PatternNotation[3℄. . . 33
3.5 Coplien'sPatternNotation foraGenerative Development-Proess[29℄ . . . 34
3.6 Meszaros' Criteria onPatternStruture[79℄ . . . 36
3.7 Varying Uses ofNotation . . . 41
3.8 Amalgamating Notation . . . 45
3.9 Rejeted Notation . . . 49
3.10 Rejeted Amalgamated Notation . . . 51
3.11 Aepted Notation . . . 53
4.1 Design Pattern Classiation[45℄ . . . 57
4.2 Logial Informationfora GenerativeDesign Pattern- Iteration1 . . . 59
4.3 Logial Informationfora GenerativeDesign Pattern- Iteration2 . . . 62
4.4 Logial Informationfora GenerativeDesign Pattern- Iteration 3 . . . 67
4.5 ConreteInformationfor aGenerative Design Pattern- Iteration 1 . . . 71
4.6 ConreteInformationfor aGenerative Design Pattern- Iteration 2 . . . 74
4.7 ConreteInformationfor aGenerative Design Pattern- Iteration 3 . . . 74
7.1 Generalstatistis fortheGenerative and Stativersionsof Compositeand Deorator . . 113
7.4 IndividualstatistisfortheGenerativeandStativersionsofCommand,Compositeand Builder . . . 118
7.5 CodestatistisfortheGenerativeand StativersionsofCommand, Composite,
Deora-tor and Builder . . . 121
7.6 Individual statistis for the Generative and Stati versions of Command, Composite,
Deorator andBuilder . . . 123
7.7 Code statistisfortheGenerative and Stativersionsof a touh sreenashregister . . 127
7.8 Individual statistis for the Generative and Stati versions of Command, Composite,
Deorator andBuilder . . . 130
H.1 Generalstatistis fortheGenerative and Stativersionsof Compositeand Builder . . . 227
H.2 Individualstatistis fortheGenerative and Stativersionsof Compositeand Builder . . 228
H.3 Generalstatistis fortheGenerative and Stativersionsof Commandand Builder . . . 230
H.4 Individualstatistis fortheGenerative and Stativersionsof Commandand Builder . . 231
H.5 Generalstatistis fortheGenerative and Stativersionsof Commandand Composite. . 233
Chapter 1
INTRODUCTION
Generative programming is a onept familiar to software engineers and is an ideologial goal for
software development. Generative programming has attrated a onsiderable amount of researh and
developmentovertheyearsulminatinginanumberofsophistiatedCASEtools. Czarneki[37 ℄denes
generative programmingas:
A software engineering paradigm based on modelling software system families suh that
givenapartiular requirementsspeiation, ahighly ustomized andoptimizedend-produt
an be automatially manufatured on demand from elementary, reusable implementation
omponents by means of onguration knowledge.
Czarneki goes on to dene a Generative Domain Model that onsists of a problem spae, a solution
spae andonguration knowledge, whihmaps the twotogether.
Thesolutionspaeonsistsoftheimplementationomponentswithallpossibleombinations. The
implementationomponentsmaximizeompatibility,maximizereuseand minimizeredundany.
Theproblemspaeonsistsoftheappliation-orientedoneptsandfeaturesthatarerequiredto
fullaspeiation.
The onguration knowledge speies default ombinations, illegal ombinations, development
rules,dependeniesandoptimizations[37℄.
Theonept ofgenerativeprogrammingmapsadequatelyto theonept ofgenerative designpatterns,
whih have a problem / solution pair held together by the ontext in whih the pair an be applied
(the ongurationknowledge).
The onguration knowledge is partiularly usefulin that there may be default ombinations, illegal
However, in the sheme of life-yle development, programming is edging towards the output phase
of development. Prior to development omesanalysis and design, yet generative design has attrated
less researh and development than generative programming. The amount of researh into generative
designthroughdesignpatterns isextremely limitedbyomparisonto designpatterns ingeneral.
Thedesignspatternfoundinsoftwareengineering(AnexampledesignpatternanbeseeninAppendix
I) are analogous to those desribed in arhiteture by Christopher Alexander[2, 3 , 4℄. Patterns, like
thosedenedbyAlexander,aredesribedasbeinggenerative,mainlybeausetheywillgenerate
stru-tures. That is, a olletion of patterns an be brought together to reate a new struture. Software
designpatterns,likethoseofAlexander,areadevelopmentpriniplethatontainstheknowledgeof
ex-pertswhohave usedreurringdesignonstrutsindevelopmentprojets. Theseexpertshavereorded
neessary informationaboutthese patterns forothersto use intheirown development projets.
How-ever, although these designpatterns areabstrated from appliationdesign, they are notdesribed in
suh a way that they an be used to design appliations. Expert knowledge desribesthem as being
onstruts that an be slotted into an appliation, but the knowledge to do that is missing from the
patterns. The fat is that design patterns annot be used to generate the arhitetures from whih
theyareabstrated. Theydo notdesribehowpatternA willollaboratewithpatternB. Theydo not
desribe how separate patterns may share resoures or design omponents. There is a need to
intro-dueadditionalknowledge into designpatternsto empowerthem withtheabilityto generate systems.
The majorityof designpatternsusedinsoftwaredevelopmentarestati,they desribea problemthat
exists, butdonotdesribe muhbeyond theirown environment |they willmention a relationshipto
other patterns butlittleelse. Inother words, theyare notadequate forgeneratingnew environments.
Appleton[6℄ providesa simpleaountof generative and non-generative patterns:
Generative patterns are ative and dynami: they tell us how to reate something and an
beobserved in theresulting system arhitetures theyhelped shape. Non-generativepatterns
are stati and passive: they desribe reurring phenomena without neessarily saying how
to reprodue them. Weshould strive todoument generative patterns beause they not only
show us the harateristis of good systems, they teah us how to build them!
Assuh,theuseofstati designpatterns asameansof developing systemsis problemati,inthat the
designpatternisstatiand needstobegenerative. Therefore,theaim ofthisthesis istoontribute to
themethodologyofsoftwaresystemsdevelopmentbyintroduingintodesignpatternsdesignknowledge
Fundamental to thisaim istheassertion that:
Generativedesignpatterns willassistinimprovingsoftwaredesignwhenompared tousingstatidesign
patterns.
In supportof this assertion,both generative and stati design patterns are ompared and assessed in
a number of appliation development ase-studies. From the ase-studies a further assertion is made
that:
Generative design patterns provide a more eÆient software solution to that of stati design patterns
when ommuniation betweenseparate design patterns isrequired.
This assertion is supported by the metris alulatedin omparative studies on generative and stati
design patterns. The metris onrm that there is an overall improvement in systems design and
softwareeÆieny forthegenerative patterns examined.
The main ontribution to this thesis, and to generative design patterns, is a notation that has been
abstrated from a range of pattern styles. A means of pattern lassiation has been inluded in the
generative pattern desriptionto identifytheirontributionto systemsfuntionality. Problem solving
notation has been added to the patterns to identify appropriate development ontexts in whih the
patterns an be applied. Andnally,relational notation hasbeenadded to thegenerative pattern to
identifyhow separatepatterns willommuniate.
The re-engineered notation has been applied to four dierent design patterns as examples of how to
usethenotation, andareinludedwithinthethesisinChapterSixand AppendiesA,B,CandD.An
exampleof astati designpatternfrom theDesign Patterns[45℄atalogue an beseen inAppendixI.
Thisthesis isorganisedas follows:
ChapterTwoonsiderssoftwaredevelopmentmethods,whihhavebeenstudiedasameansofnding
qualitiesthatouldbeappliedto thenotationof agenerative designpattern. Althoughtherearelarge
numbersofdierentdevelopmentmethods, theyallhave aommongoalandthatisaqualityprodut.
Manyusesimilartehniquesto ahievetheirgoalwhilstothersusealternativetehniquesorarespei
to a partiularphase inthedevelopment life-yle.
Chapter Three looks at pattern notation with a view to understanding where the notation omes
fromandhowitisappliedinspeitypesandstylesofpatterns. Beausesoftwaredesignpatternsare
notdened asgenerative, there are no guidelineson how to doumentthem asgenerative. Therefore,
inorderto ndasuitabledoumentnotationforgenerativedesignpatterns,multiplepatternnotations
Chapter Four onsiders the funtionality and the relationships between patterns. Dierent types
of patterns have dierent funtions; therefore some property of the pattern needs to desribe the
relationshipthat existsbetween dierent funtionaltypes. Some ofthese patternsform the bodyof a
system whilst others perform some operationalrequirement of the system. Whatever type of pattern
they maybe,all dierenttypesneedto denehowthey ollaborate.
Chapter Fivelooks at themodellingnotationthat is used withinpatterns. Manysoftware patterns
use onlya lass diagram inthenotation of a pattern althoughthere are manymodellingnotations in
the UniedModellingLanguage that ould be usedto help desribe theusabilityof a designpattern.
Quiteoften,patternwriterswhoreproduethepatternsoriginallydesribedintheDesignPatterns[45℄
atalogue will modify the design notation in their interpretation of the pattern to meet the needs of
their example. However, what is evident from some of these interpretations is that theexample ode
they providedoesnotmath thedesignnotationthat they use.
Chapter Six integrates the work desribed in Chapters Two to Five. The work from the previous
haptersis summarisedand a generative pattern isdened fromthe desirednotation and the
require-ments of the dened relationships. Three separate examples of generative design are provided with
dierent ongurationsof design. Further examplesare providedintheAppendies.
Chapter Seven evaluates theapproah taken indeninga generative pattern, reetingon the
on-strutionproessusedfortheframeworkandtheexamplesthatwereproduedtosupportthegenerative
patternonept.
Chapter Eight onsiders the work still to be done in the area of ommuniation between spei
lassiations of patterns. A ustomised Computer Aided Software Engineering tool is proposed as
wellassome alternative researh thatan beondutedin relationto generative designpatterns.
Chapter Nineonludes thework undertaken indeningagenerativepattern.
Appendix Aprovidesan exampleofa Composite ombinesCommand designpattern.
Appendix B providesan exampleof aComposite ombinesBuilderdesignpattern.
Appendix C provides an example of a Builder ombines Command ombines Composite design
pat-tern. This pattern also ombines withthe Composite patternand is also an exampleof a Creational,
Behaviouraland Struturalpatternworking together.
Appendix D providesan exampleof aBuilderuses Command designpattern.
Appendix Fontainsthesoure ode forthegenerative patternsdesribed inChapter Six.
Appendix Gdesribesthemetristhat areavailableforassessing softwarequality.
Appendix H ontains three sets of pairedpatterns that have beenused in the evaluation proess of
generative designpatterns.
Chapter 2
EXPLORING THE LINK BETWEEN
SOFTWARE DEVELOPMENT METHODS AND PATTERNS
2.1 Introdution
Inthishapteranoverviewofsoftwaredevelopmentmethodsispresentedwiththepurposeofexploring
theexpertknowledgeand qualitydrivenaspetsontainedwithinthemethods. Considerationisgiven
to development methods as a means of determining if expert knowledge ontained within methods
an be appended to the expert knowledge ontained within design patterns. From this study it has
beendetermined that there aresimilarities betweenmethods and patterns. It is foundthat there are
qualitiesinsome methods,mainlydesignaspetsand odingpriniples,whihan be usedto enhane
thequalityof a designpattern.
InSetion 2.2arepresentativeseletion ofearly Objet-Orienteddevelopment methodsislisted,
oer-ing an historial insight into the evolving pratie of quality driven software development. Several of
the methodslistedrepresentthe drivingfore behindthe UniedModellingLanguage[15,54 ℄ (UML),
elements of whih feature in design pattern notation. The authors of the original methods that
on-tributed to the UML are seen as experts in the eld of software engineering and the methods they
devised have been a signiant inuene in the development of modern methods. The same experts
that devisedtheUML made a signiant ontributionto IBM's
1
Rational UniedProess[89 ℄(RUP),
a ontemporary development method,whih isexploredfurtherinSetion 2.3.
Setion 2.3 examines several ontemporary methods: RUP, Extreme Programming[9, 10 ℄ (XP) and
Srum[12℄ as well as the Objet Management Group's[53 ℄ (OMG) Model Driven Arhiteture[55℄
(MDA).
2.1.1 Pattern / Method Analogy
The priniple of a software development method is to impose disipline,preditabilityand eÆieny
on a projet. In most ases, the methods that are used to develop a software system often follow
some life-yle proess, whih in many ases will expand upon the subjets of Analysis, Design and
Development. By followingthese methods, whih areoften denedbyexperts intheireld,who have
tried, tested and rened the proesses that failitate the eetiveness of the method, the likelihood
of projet failure is often redued. In this respet, there is a simple omparison that an be applied
betweena methodand a designpattern:
Expertknowledge: designpatterns arethedoumentationof expertknowledge.
Failure redution: designpatterns aretriedand testedexamples ofqualitydesign.
The onept of software design patterns and the expert knowledge that they ontain are desribed in
greater detailinChapter Three.
By examining design pattern atalogues and the patterns ontained within, it is not obvious to the
reader that the patterns ontain simple methodial priniples of software development. The simple
reason for this is that patterns are not methods and no evidene has been obtained to suggest that
they were everintendedto bemethods. However, theanalogy isthere. Forexample:
Manypatterns ontain the setionsProblem and Fores, whih analyse the situationin whih a
patternan be applied{(Analysis).
Inmanysoftwaredesignpatternsthereisoftensomeformofdesignusingalass, sequeneand/or
other diagrams{ (Design).
And,quiteoftentherewillbeimplementationdetailsintheformofsampleode{(Development)
Working on this priniple,it an be seenthat methods and patterns share some ommon ground and
in taking advantage of this ommon ground it is oneivable that methods and patterns ould work
eetivelyas auniedsubjet intheeldof softwaredevelopment.
2.2 Objet-Oriented Software Development Methods
Withtheemergene oftheobjet-orientedsoftwareparadigm amemanyobjet-orienteddevelopment
methods. Intheperiod1988{1995 atleast19objet-orientedmethodshadbeenproposedinbookform
and many more were proposed in onferene and journal papers[115 ℄. To abstrat good pratie for
ould be applied in order to obtain the best and most appropriate aspets of these methods.
How-ever, this line of researh would be extensive and would detrat from the main purpose of deninga
generative pattern. In addition, during thisperiod 1988{1995, manystudies were onduted into the
state of objet-oriented development methodsandomparisons madebetweenthem | A Comparison
ofObjet-OrientedDevelopment Methodologies[13 ℄byBerardofTheObjetAgeny[1℄listssevensuh
studies whilst being a study in its own right. Brighton University[107 ℄ douments signiantly more
omparative studies, whih itself inludes a list of development methods. Therefore, onduting yet
another omparative study is unlikely to provide any new and usable information that would be of
beneialusewithintheurrentresearhprogram. However, byexaminingpreviousstudies,aninsight
into some of themore ommonand populardevelopment methodshasbeenestablished.
The list below hasbeen onstruted primarilyfrom the list presented by Berard[13 ℄, although not in
its entirety, and represents some of the early, more ommon objet oriented methods | asertained
throughtheirrepeatedinlusioninomparative studies.
ObjetModellingTehnique[97℄(OMT).OMTwasoriginallyreatedasamethodfordeveloping
objet-oriented systems. It usesmanyof thedesigntehniquesthatbeame partof theUML.
Objet-OrientedSoftware Engineering[63℄ (OOSE). OOSE is very similarto OMTand employs
Use-Cases to drive design. OOSE Beame one of the key omponents of the UniedModelling
Language.
Objet-OrientedAnalysisandDesign[14 ℄(OOAD).OOADonentratesontheanalysisanddesign
phasesbutexempliestheproesseswithexistingappliations. OOADrepresentsagoodexample
ofapplyingexpertknowledge |aommonthemeindesignpatterns. OOADSisanother
design-orientedmethod thatevolved into theUniedModellingLanguage.
BerardObjet-OrientedMethod[100℄(BOOM).BOOM isasetof integratedmethodologiessuh
asOOSEand OOADamong others.
BusinessObjetNotation[113℄(BON). BONwasdesignedto work seamlesslywiththe
program-minglanguageEiel[80℄ and hasbeenusedsuessfully withother programminglanguages.
Objet-OrientedAnalysis,Objet-OrientedDesign,Objet-OrientedProgramming
[23 , 24 , 25 ℄ (OOA, OOD, OOP). OOA / OOD / OOP overs the priniples of objet-oriented
Shlaer-Mellor[101℄. Shlaer and Mellor devised an OOA / OOD method to ompensate for the
pereiveddeieniesinthestruturedanalysisandstrutureddesigntehniquesthatwerebeing
usedin thelate1980s, suhas SSADM[47 ℄and YSM[117,118℄.
Wirfs-Brok[116℄. Wirfs-Broks method is a design proess that an be applied to both
objet-orientedand non objet-oriented development.
Fusion[28℄. Fusionisan objet-orientedanalysisanddesignmethod thatintegratesfeaturesfrom
existingmethods suhas OMTandOOAD.
Severalof these methodsfouson designand therefore have a strongdesign ontent,whihis aprime
feature of design patterns. Three of the methods listedabove have between them reeived over 2200
knownitations[86 ℄andweretheforerunnersoftheUniedModellingLanguage[15,54 ℄(UML)namely,
OOAD, OOSEand OMT.It isdesignelementsfromthese traditionalmethodsthathave beenapplied
todesignpatterns. However,onlylimitedelementshavebeenutilisedinadesignpattern,namely,lass
and interationdiagrams.
Asaresultofontinuousdevelopmentandrevision someoftheabove listedmethodshave evolved into
ontemporary working praties that an be found inmethods suh as the RUP.Agile methods suh
asXP an also beonsidered asontemporary butthese too have longrootedhistories[26℄. Although
not based on Objet-Oriented methods suh as those above, Agile methods were a reation to rigid,
heavyweightmethodsoftheday[44℄,whihoftenadaptedthelifeyleframeworkoftheWaterfallmodel
devisedRoye[96℄. The RUP and other ontemporarymethodsaredisussedin setion2.3 below.
2.3 Contemporary Software Development Methods
2.3.1 Rational Unied Proess
About the Rational Unied Proess
The Rational UniedProess is a life-yle proess that provides a disiplined approah to assigning
tasks and responsibilities within a development team. Its aim is to ensure the development of
qual-ity driven software that meets the requirements of end-users[62, 67 ℄. The RUP provides every team
member with aess to a knowledge base. By having all team members aess the same knowledge
base, irrespetive of whether a team member is working with requirements, design, testing, projet
om-RUP emphasizes thedevelopment and maintenane of models. That is,the Rational Unied Proess
isa guideon howto usetheUniedModellingLanguage,whih wasdevelopedbythesame teamthat
reatedtheRUP.Likedesignpatterns,whihwillbedisussedinChapterThree,theRUPistheresult
ofexpertknowledgeand,aswillbeshowninthefollowingtext,denesanumberofsimilaritiesbetween
the two onepts and ontainsmodellingelements that an ontribute to an appropriate notation for
generative designpatterns,
Four Phases of the Proess
The Rational UniedProess attempts to apturewhat is onsidered to be best praties in modern
softwaredevelopment withina fourphase strategy:
Ineptionphase
Elaborationphase
Construtionphase
Transition phase
Ineption
During theineption phase a businessase for thesystem is proposed and the sope of the projetis
identied. Inthis,allexternalentitieswithwhihthesystemwillinteratareestablished(ators). The
interationwithexternalentitiesinvolvesidentifyingprominentuseasesanddesribingthosethatwill
have a signiant impat on the system[62 , 67 ℄. The outome of the ineption phase is, among other
things:
A doument of theprojet'srequirements, keyfeatures, and mainonstraints. (Analysis)
An initialuse-ase model. (Design)
An optionaldomain model. (Design)
One orseveral prototypes. (Implementation)
Elaboration
The purpose of the elaboration phase is to analyze the problem domain, establish an arhiteture,
developtheprojetplan,andeliminatehighriskelementsoftheprojet. Arhiteturaldeisionshaveto
bemadewithanunderstandingofthewholesystem: its sope,majorfuntionalityandnon-funtional
requirementssuhas performanerequirements.
At the endof thisphase, theanalysis and design aspets areonsidered to be ompleteand deisions
are made on whether or not to ommit to the onstrution and transition phases. While the proess
must alwaysaommodate hanges, theelaboration phaseensures that thearhiteture, requirements
and plansarestable, and riskshave beenassessed.
In theelaborationphase,an exeutableprototype isbuiltinone ormore iterations,dependingon the
saleof theprojet, whihat minimumshouldaddress theritialuse-ases identiedintheineption
phase. Whilsta prototype of a prodution-qualityomponent is always the goal, one or more
throw-awayprototypes maybeprodued asameansof testing designand requirementstrade-os.
The outomeof theelaborationphase is:
A use-asemodelwhereall useases and atorshave beenidentied,and mostuse-ase
desrip-tionshave beendeveloped.
Identiationof supplementaryrequirementsthat arenotassoiatedwithspeiuse-ases.
A software Arhiteture.
An exeutableprototype.
A revisedrisklist and businessase.
A development plan.
An optionaluser manual.
Constrution
During the onstrution phase, all remaining omponents and appliation features are developed and
integratedinto theprodut,and allfeaturesarethoroughlytested. Theonstrutionphaseisaproess
Often,projetsarelargeenoughthatonurrentonstrutionplansanbeimplemented. Theseparallel
ativities an hasten the availability of deployable releases; however, they an also inrease the
om-plexity of resoure management and workow synhronization. This is one reason why the balaned
development of thearhiteture andtheplan isstressedduringtheelaboration phase.
The outome of the onstrution phase is a produt ready to put in the hands of its end-users. At
minimum, itonsistsof:
A software produtonguredfor desiredplatforms.
User manuals.
A desriptionofurrent releases.
Transition
The transition phase is onerned with plaing the software into the hands of the users. One the
produt has been given to the end user, issues usually arise that require the team to develop new
releases, orret problems,orompleteanyfeatures thatwerepostponed.
The transition phase is entered when a produt is suÆiently robust that it an be deployed in the
end-user domain. This typially requires that a prototype of the system has been ompleted to an
aeptable levelof qualityand thatuser doumentationisavailable. Thisinludes:
Testing; to validate thenew systemagainstuser expetations.
Paralleloperationwitha legaysystem thatit maybereplaing.
Conversionof operationaldatastores.
Training of usersand thoseinvolvedwith maintenane.
Roll-outtheprodutto themarketing, distribution,and salesteams.
Typially,thisphasemayinludeseveraliterations,inludingbetareleases,generalavailabilityreleases,
maintenane releasesand enhanement releases. At this point, eortwill be putinto developing user
The primaryobjetivesof thetransition phaseinlude:
Ahievingself-supportfrom theuser.
Ahievingstakeholderagreementthatdeployment requirementsareompleteandonsistentwith
theevaluation riteria.
Ahievinganal produtasrapidlyand ost eetivelyaspratial.
This phase an range from being simple to omplex, depending on the produt. For example, a new
release of an existing desktop produt may be very simple, whereas developing a nation's medial
reords systemwould be very omplex.
Conlusion
AordingtoDeMaro[38℄,\Analysisisthestudyofaproblem, priortotakingsomeation"-afamiliar
onept in terms of design pattern notation in that a problem is identied and a solution provided.
Aording to Coad[24 ℄ Analysis is a proess of extrating system requirements from the major
stake-holdersinthesystemunderdevelopment. Therefore,themainonernofanalysisistodeterminewhat
is required inorder to develop thesystem that is beingommissioned. On investigating the Rational
UniedProess itanbeseenfromtheauthoritativetextsthattheproessisheavilyweightedtowards
analysiswithemphasisonanalysingthebusinessproessesinvolvedinsystemsdevelopment. However,
the RUP does not dwell heavily on problems but onentrates signiantly on a generi solution to
quality driven systems development. In this respet there are few similarities between the RUP and
designpatterns asthere areinmanyof theearlyObjet-Orientedmethodssuh asOOAD, OMTand
OOSE, whih ontributedtowards the UML. However, the onept of Solution, whih is a signiant
aspet ofRUP,isalso asigniant aspetof designpatterns,whih presentsinone aspeta similarity
betweenthispartiular methodand designpatterns.
What an be seen in the RUP, whih stands out signiantly against other aspets of the proess is
the use-ase. The originators of the RUP have put great emphasis on the use-ase, whih is used
throughout the early stages of proess in most aspets of the analysis and design lifeyle. This is
baked up by the authors of the RUP who desribe the Unied Proess as being \Use-Case Driven,
Arhiteture-Centri, Iterative and Inremental[62 ℄. In this respet, the authors of the method are
puttingarhitetureandhowtheyrealisethatarhitetureat theforefrontoftheRUP.Oneofthekey
goalsinRUPandthedesigngoalsofgenerativedesignpatterns. ThisnotionissupportedbytheUnied
Software Development Proess[62 ℄ (USDP), an early version of RUP, that looks at arhiteture from
various viewpoints. This aspet is similarto one of the quality aspets ontained within the Pattern
OrientedSoftwareArhiteture[20℄(POSA)atalogue of design patterns inthat alternative views of a
solution are onsidered. Given this orrelation between these quality aspets of RUP and the POSA
design patterns it is oneivable that multiple viewsof generative designshould be inorporated into
generative designpatterns. The dynamiaspets of thePOSA designpatterns and how these aspets
an be inorporated into a generative design pattern willbe disussedfurther in ChaptersThree and
Five.
2.3.2 Agile Methods
About Agile Methods
A ritiism of early objet-oriented methodsdesribed them as beingtoo bureaurati. As a reation
to thisritiismanumberofnewmethodsappeared. Thesenewmethodsarereferredto aslightweight
or agile methods[44℄. The new agile methods are a onession between no proess and too muh
proess, providing just enough proedure to gain a reasonable ompromise. The result is that agile
methodshave some signiant hanges inemphasisfrom lifeylemethods. One ofthe oreaspets of
agile software development is the use of light butsuÆient rules of projet behaviour and the use of
humanandommuniation-orientedrules[26℄. Oneofthemostvisibleaspetsofthisisthattheyareless
doument-oriented,usuallyemphasizingasmalleramountofdoumentationforagiventask. Aording
to Fowler[44℄,theyareratherode-oriented: followingaroutethatsays thekeypartofdoumentation
is soure ode. whilst some methods an be quite rigid, agile methods enourage exibility in their
proedures. What may be suitable forone projet may not be the right proess for every projet or
situation. Therefore, the agile team is enouraged to rene and reet as it goes along, onstantly
improvingits praties initsloalirumstanes.
Extreme Programming (XP)
About XP
IntheearlydaysofXP themethodwasdenedwiththedistintsetionheadingsofProblem,Solution
and Implementation | ommon notation used in many design patterns. The method looked at the
problems of software development, proposed some solutions to those problems and desribed how to
implementthe method. There werefourvalues,fteen basipriniples,andtwelvepraties[9 ℄. In the
innamewhilsttheoreaspets ofvalues, priniplesandpratiesthatunderpinthemethodhavebeen
redened. The very basi XP paradigm of adaptation and hange has been applied to XP itself[10℄.
There are now ve values, fourteen priniples, thirteen primary praties and eleven onsequential
praties. Ofthetwelve originalpraties, two have beenabandoned, whih givesthe revisedmethod
fourteen new praties with whih to apply the method[10℄. In fat, whilst the newer version of XP
retainsitsoriginalvalues,thewholemethodhasbeenrenedintermsofitspriniplesanditspraties.
Just asit is expeted that patterns will evolve, and as willbe shown they an evolve into generative
patterns, XP has evolved and may ontinue to evolve, whih demonstrates a similarity that patterns
havewiththispartiularmethod. The originaloneptofXPwasdividedintothreefoundingsetions:
1. Problem: where thevaluesandpriniplesof XP areexplainedand ativities dened.
2. Solution: where good pratiesareapplied followingtheguidingvaluesand priniples.
3. Implementation: how thestrategies disussedinthesolutionan be putinto pratie.
Althoughthese oneptsare removed inname,theunderlyingessene ofthe methodis stillevident in
that thebasiontent ofthe methodthat underpinnedthese three setionsisstillevident. Referenes
arestillmade to problemsbuttheemphasisof wherethe problemlies hasbeenredened. Whenone
theproblemwasdenedinterms ofwhereweaknesses maybeevident inthedevelopmentproess,the
problemis now denedin termsof a developer'sinabilityto ope withhange[10℄, and thesolutionis
XPitself. Thesolutioninregardsof XPbeginsbyrst understandingtheoreoneptsofthemethod
whiharerepresentedbyvalues,priniplesand praties.
Five Values
The basiroot elements of XP are ve ore valuesthat are deemed to be strategially important for
the suessful development of software. These ore values are guidelines for XP as a method and a
foalpoint fordevelopment itself. Therst fourvaluesare retainedfrom theoriginal XP,and respet
is addedasan additionalvalue. The valuesfortheontemporaryversion of XPare:
1. Communiation: Most problemsand errorsare aused bylakofommuniation.
2. Simpliity: Themainguidelineistokeepthesystemsimpleanddonotplantoofarahead. New
3. Feedbak: Feedbak is seen as being an important omponent of ommuniationin that when
you ommuniateyou are inapositionto gain feedbak. Feedbakalso ontributesto simpliity
inthat thesimplera system, theeasierit isto getfeedbakaboutit.
4. Courage: Iffear isexpressed abouta projet, then theburden of takling theprojet beomes
muh bigger. However ourage alone is notenough to takle a projet and shouldbe baked up
byommuniation,simpliityand feedbak.
5. Respet: If members of a team do not are about eah other and their work, the hanes of
development failureare muhgreater.
The ve valuesthatsupportXP asa method do notgive spei advieon howto manage aprojet,
or how to write software. To this end, what are required are praties. However, bridging the gap
betweenvaluesand pratiesarepriniples[10℄.
Fourteen Priniples
1. Humanity: Software isdeveloped bypeople forpeople,sohumanfatorsare taken into
onsid-erationin attemptingto deliverqualitysoftware.
2. Eonomis: Ensurethat what is being developed has businessvalue,meets businessgoals and
meetsbusinessneeds. Someone hasto pay andthey want value formoney.
3. Mutual benet: All ativities should benet both developers and lients alike, both in the
present and inthefuture
4. Self-Similarity: Try opyingthestrutureof one solutioninto anew ontext, even at dierent
sales.
5. Improvement: XPasksforexelleneinsoftwaredevelopmentthroughontinuousimprovement.
6. Diversity: Teams shouldinludea varietyofskillsattitudesand viewpointsinorderto identify
problemsand providesolutions.
7. Reetion: An eetive team should ask themselves how they are working, and why they are
working in thatway. They needto analyze thereasons behindsuess or failurewithout hiding
8. Flow: The praties of XP assume a ontinuous ow of software by engaging in all ativities
simultaneously,ratherthan asequene of disretephases.
9. Opportunity: Problems mustbeseen asan opportunityforlearningand improvement.
10. Redundany: Critialand diÆultproblems shouldbe solved in several dierent ways. Thus,
ifone solutionfails, anothersolutionmayprevent adisaster.
11. Failure: Failure shouldnot beviewed as failure butan opportunityfor learning. Failure is not
a waste ifitimpartsknowledge.
12. Quality: Sariing quality is not an eetive means of ontrol. Projets do not go faster by
aepting lower standards. Inaddition,team membersneed todo workthey areproud of.
13. Baby Steps: One of the reasons behind baby stepsis that a small step inthe wrongdiretion
is easier to reover. A big step that fails an damage a projet. It is more prudent to proeed
iterativelyinbabysteps. Baby stepsdo notmeanproeedingslowly. Ateam proeedinginbaby
stepsan take alot ofthem ina shortperiodoftime.
14. Aepted Responsibility: Aepted Responsibilityis aboutbeingresponsible. Responsibility
shouldonlybetaken ifyou areondentenough to aept it.
Priniplesareameansofprovidingabetterunderstandingofpratiesandtoimproviseomplementary
praties when a pratie annot be foundfor a given purpose. They also give a better idea of what
thepratie is intendedto aomplish[10℄.
Twenty Four Praties
The updated version of XP denes thirteen primary praties, and eleven orollary (onsequential)
praties. The primarypraties mustbe appliedrst, and eah of them may add to animprovement
in the software development proess. Consequential praties require expertise in primary praties,
andmaybediÆulttoapplywithoutrsthavingonsideredtheprimaryones. Alltwentyfourpraties
areanintegralpartofthemethod,andshouldbefullyappliedinordertoobtainthemaximumbenet
of XP.
Thirteen Primary praties
2. Whole Team: Ateam shouldbeomposedofmembersthathave alltheskillsneessaryforthe
projetto sueed.
3. Informative Workspae: The workspae shouldbe suppliedwithinformationonthestatusof
theprojetand thetasks to be performed.
4. Energized Work: Theteam mustrespetawork {lifebalane,sothatthey an fouson their
job and be produtive.
5. Pair Programming: Code shouldbewritten by twoteam members at one workstation.
6. Stories: The system should be desribed using short desriptions of funtionalities that are
aessible to theustomer.
7. Weekly Cyle: Atthebeginningoftheweek ameeting shouldtakeplae wherethe
funtional-ities (Stories)to developinthe weekare hosen bytheustomer.
8. Quarterly Cyle: Development is planned on a lager time sale. This onsiders feedbak on
theteam, theprojetand whatprogress is beingmade.
9. Slak: Avoid making promises that annot be fullled. Consider tasks that an be dropped if
theplan fallsbehind shedule.
10. Ten-Minute Build: Thebuildand testing ofa systemshouldonlytake minutes.
11. Continuous Integration: Teams shouldbeintegrating hanges regularly.
12. Test-First Programming: Beforeupdatingoraddingode,testsshouldbewritteninorder to
verify theode.
13. InrementalDesign: XP isopposedto produingaompletedesignpriorto development and
suggests thatdesignshouldbe doneinrementallyduring oding.
Eleven Corollary Praties
1. Real Customer Involvement: Stakeholders who are aeted by the system must beame a
2. Inremental Deployment: When replainga system,start byreplaingsome of the
funtion-alityand graduallyreplae all thesystem.
3. TeamContinuity: Development teamsshouldremain intat throughoutseveral projets.
4. Shrinking Teams: Asa team beomesmore produtive,graduallyredue its size, sendingfree
membersto form newteams.
5. Root-Cause Analysis: When a defet is deteted, ndthe ausesof thedefet and eliminate
them.
6. Shared Code: Any member of the development team must be able to hange any part of
development at anytime.
7. Code and Tests: Codeand tests arepermanent artefats andhave to bepreserved.
8. Single CodeBase: Thereshouldbeonlyone versionofthesystem. Temporarysystemsanbe
reatedbutmust notbepreserved.
9. Daily Deployment: New software shouldbe putinto prodution every night. A gap between
what ison a programmer's deskandwhat is inprodutionisa risk.
10. Negotiated Sope Contrat: Contratsshouldbewrittenforsoftwaredevelopment thathave
xed time,ostsand quality,but allforanongoing negotiation ofthesope ofthe system.
11. Pay-Per-Use: The ustomerusuallypaysforeah release of thesoftware.
Aording to Bek[10℄, the primary and orollary praties are not everything that is needed to
su-essfullydevelopsoftware. Theyarehowever,oreelementsofexellene insoftwaredevelopment. Ifa
problemarisesthat isnotovered byone ofthepraties thenone shouldlookbakat thevaluesand
priniplesto ome upwith asolution.
Conlusion
WhatisevidentwithXPandpartiularlytheupdatedversionisthatthereisastrongemphasisapplied
to themanagement of the method. The method does notgo into detail about analysis ordesign and
how to ondut these aspets of software development. Appliation of knowledge and how to apply
Onething thatstandsoutintheoriginalversionofExtremeProgramming[9℄istheemphasisthatwas
put on dening the method in terms of Problem and Solution. In thisrespet, XP had very obvious
similaritieswithdesignpatterns,inthatProblemandSolutionisrepresentativeoftheexpertknowledge
ontainedwithinthem.
AnothersigniantaspetofXP inbothnewandolderversionsisthatodingisseenasakeyativity
of the method. This, from the point of view of the authors of the method, is one of the strengths of
XP.What willbe shown inChapter Sixisthat thegenerative designpatternwillutilise thisstrength
to demonstrate oded examples of generative design. The onept of oded examples is supported by
theonludingommentsonRUP inSetion2.3.1,whereitisnotedthatmultipleviewsanbeapplied
to a generative pattern. Inthisrespet,multipleviewsrefer to multipleodedexamples.
Srum
About Srum
Srumisanagileproessthatan beusedto manageand ontrolprodutdevelopment usingiterative
andinrementalpraties. Themethodisapableofproduingasetoffuntioningartefatsattheend
of every iteration. Srum failitates the development of the best possiblesoftware from theavailable
resoureswithaeptablequalitywithinrequiredreleasedates. Produtfuntionalityisdeliveredatthe
endofwhat is knownasa sprint,whihmaylastbetweenfteento thirtydays,dependingon thesize
of the projet. As requirements and design areevolving sothe produt willevolve. The name Srum
refers to the srum in rugby { a tight formation of forwards who bind together in spei positions
when asrum down isalled.
Roles
Thereare three primaryrolesinthe Srumdevelopment proess:
TheSrumteam: Theteamnormallyonsistsof5-9people. Theteammembersdeidehowthe
work isarranged and how assignmentsare distributed. Thereare no setprojet roles, everyone
shouldbe ableto swap taskswithanothermember. Theteam isself-organizedand themembers
have ajointresponsibilityfortheresults.
Produt owner: Theprodutownerrepresentstheustomerand ensuresthattheSrumTeam
is working eetively from a business perspetive. The Produt Owner administers a Produt
Baklog, a to-do list, whereall the speiations fora produtare listedand prioritised. Before
of theprodut.
Srum master: The SrumMaster meets withthe team every day inbriefmeetings known as
daily srums. When someone from outside the projet has an issue to disuss with the team,
the SrumMaster ensures that the team are disturbed as little aspossiblein their work. After
eah Sprint, theSrumMaster holdsan evaluation meeting withthe Srumteam, duringwhih
experienesand onlusions are reviewed. The purposeof the evaluation meeting is to raise the
teamslevel ofknowledgeand strengthenmotivationprior to thenext Sprint.
The Srum Proess
Creating a baklog: The Produt Owner ompiles requests and speiations that are the
basis of the produt, suh as anynew funtionalityor bug xes. After goals have been dened,
thespeiation isbroken down into hunksof work ahievable inasprint. TheProdutOwner
makesato-dolistarrangedaordingtohowmarketdemandsandustomerrequestsmayhange
over time and deides in what order any hanges should be made and delivered. Eah sprint
shouldreate in-partaworkingsub-setion oftheprodut. WhenitistimetostartanewSprint,
theProdutOwnerfreezesthe leadingitems on theto-do listand summonsthe SrumTeam to
a meeting.
The sprint phase: Ofthe Sprints15 to 30 days period,the rst one ortwo days are set aside
to reate a Sprint Baklog. When the tasks have been determined,the Produt Ownerreleases
work to thedevelopment team. From thatpoint, theteamworksunderits own responsibility. If
theteam hasbeenproperly omposed, theworkshouldbeself organising.
Daily Srum: Every day,usually at the same time inthe morning,the SrumMaster and the
Srum Team have a brief meeting. The purpose is to try and eliminate any restritions that
mayhave developedwithinthegroup. Eah ofthepartiipantsshouldinsomewayanswerthree
questions:
1. What have youdone sinethelastmeeting?
2. What willyou do betweennow and thenext meeting?
3. Is there anythingpreventingyoufrom doing whatyouhave planned?
organizational hanges at theompany. Anyone mayattend and listenat the meeting, butonly
theSrumMasterand theteam membersmayhave some input.
Demonstration and evaluation: Eah Sprint nishes with a demonstration of funtioning
software. Attending at the demonstration will be the Produt Owner, users and possibly
rep-resentatives of orporate management. This is in eet an evaluation meeting and the starting
point forthenext Sprint.
Conlusion
LikeXP,thefousofSrumissigniantlydiretedtowardsfailitationofthemethodandtheativities
oftheteam,whilstleavingtheproessesofanalysis,designanddevelopmentinthehandsoftheexperts
that areusing themethod. This pratie an be seen inmostof the agilemethods. Beause thisand
othersimilarmethodsaremoreonernedwiththeirownproessesthey havelittleto oerintermsof
expertontent that an be appendedto a designpattern.
2.3.3 Model DrivenArhiteture (MDA)
About MDA
TheObjetManagementGroup'sModelDrivenArhitetureisastandardsdrivenproesstobuild
sys-temsfrom modelsusingmodeltransformations. A ompleteMDA speiationonsistsof a
platform-independentmodel(PIM),oneormoreplatform-speimodels(PSM)andasetofinterfaedenitions,
eah desribing howthe PIM isimplemented on a dierentplatform. MDA development looks at the
funtionalityand behaviourof a system, independent of theplatformorplatforms on whih itwillbe
implemented. Thus, it is notneessary to repeatthe proess of deninga system's funtionality and
behaviourwhennewplatformsortehnologiesaredeveloped. WithMDA,funtionalityand behaviour
aremodelledonlyone[55℄.
The whole ethos of the MDA is to design an arhiteture and generate an appliation or system
from that arhiteture. Therefore, MDA models must be extremely detailed: the appliation willbe
generatedfrom it, and willinludeonlythose funtionalomponentsthat areexpliitlyrepresentedin
the model. MDA works by separating the businesslogi of an appliation (the ode that implements
itsfuntionality)fromtheinfrastrutureinwhihitisdeployed. Oneaptured, thebusinesslogian
be reused in other ways with other appliations, as long as they adhere to thestandards. The MDA
The metadata isthenused bytheMDA tools to generateand deploytheappliation.
MDA Development Life Cyle
The MDA development lifeyle is not muh dierent from the traditional life yle of many
devel-opment methods. Requirements are gathered and analysed, a design is reated, ode is written and
thesystem istested and deployed. The majordierene liesinthe nature ofthe omponentsthatare
reated during thedevelopment proess. The omponents are formal modelsthat an be understood
byomputers[66 ℄. Figure 2.1belowillustratestheMDA development lifeyle.
Requirements
Analysis
Low-level
Coding
Testing
Deployment
design
Document
PIM
PSM
Code
Code
Figure 2.1: MDA Development Lifeyle[66 ℄
The formalmodelsof theMDA are:
PIM- desribesa software systemthat supports some business.
PSM - foreahspeitehnology platforma separatePSM isgenerated.
Code- eah PSM istransformed into ode thattstheplatformtehnology.
The PIM, PSM and Code are shown in Figure 2.1 as artefats of dierent steps in the development
lifeyleand representdierent abstration levelsinthesystem speiation.
Models
The UMLontains bothstati anddynamimodellingnotationand an beusedto providestati and
dynami views a software system. However, MDA makes no distintion between stati and dynami
models. MDA regards dierent diagrams in UML as being a view of the same model, if they are all
written in the same language. That is, the MDA will make no distintion between a retangle that
model ould be used to desribe a system[66℄. If a partiular modelling language is not apable of
dening a spei aspet of a system then more than one model will have to be used to dene the
system.
Transformations
TheMDA proess asdesribedinFigure2.1 isverysimilartotraditionaldevelopment where
transfor-mationsfrommodelto modelormodeltoode aredonebyhand. WithMDA thetransformationsare
done by tools. Transferring a PSM to ode is nothingnew, there are several very sophistiated, and
notsosophistiated,toolsonthemarketthatwilldothis(Together[16℄,VisualParadigm[85 ℄,Rational
Rose[61 ℄). What is new is transferringPIMsto PSMs. Figure 2.2 below shows the three major steps
intheMDA transformation proess.
PIM
Transformation
Tool
PSM
Code
Transformation
Tool
Figure2.2: MDA Transformation Proess[66 ℄
A transformation tool takes as input a PIM and returns as output a PSM. A seond transformation
tool, orthe same tool dependingon the level of sophistiation, transforms the PSM to ode. Within
thetool(s) there isa transformationdenitionthatdesribeshowthemodelshouldbetransformed.
Conlusion
What stands out about MDA is that it is driven by design, but more signiantly it uses tools to
transform designs and generate ode. MDA is not so muh a method, but a proess to be used
in generating systems and any well-written modelling language an be used to model a system. A
meta-modelling language is used to transform models to modelsand models to ode. So long as the
meta-modellinglanguageiswell-writteninthesamelanguageasthemodel,amodelanbetransformed
bythe transformation tool. MDA itself makes no distintion about how to analyse orput together a
model ofasystem, itleaves thatupto theexpert. However, MDA an beusedwiththeRUP orother
agile methodssuh as XP.Indeed, beause hanginga modelmeans hanging thesoftware, the MDA
approah helpssupportagilesoftware development[66 ℄.
MDA is a step loser to the utopian goal of generating systems from reusable omponents but is
workingmostlyatthegenerativeprogramminglevelasdisussedbyCzarneki[37 ℄,and notatalevelof
design for a proposed system, whih is then fed into a transformation tool. A tool designed to build
arhitetures from generative design patterns ould be used to reate the models that are fed into a
transformation tool.
2.4 Summary
In the study on methods it is shown that a method is a way of using an ordered set of instrutions
to selet and applya numberof tehniquesand tools to identifyandanalyse a problem and onstrut
a solution to that problem. It is also shown that there are numerous development methods from
whihtohoose. Manyofthemethodsviewedrepresentwhat theirauthorsseeasbeinggoodsoftware
developmentpratie. Thestudyprovidedasummaryofthosemethodsthatgavebirthtothestandard
design notation, the UML. What is evident in many of the older Objet-Oriented methods is that
the design notations from these methods, and the UML, are not used to their fullest extent within
designpatterns,partiularlystate,objetinterationanduse-ase diagrams. The summaryon
objet-oriented methods found that there are signiant similarities between patterns and methods. Both
Objet-Orientedmethods and patterns have analysis, designand implementation detailsontained in
theirdoumentation. Withmodernagilemethodsthesimilaritiesbetweenpatternsandmethodsisnot
as strong as it is with the older methods. Where a pattern has analysis, design and implementation
detailontainedinitsdoumentation,whihfollows thelifeyledetailofsome oldermethods,modern
methodsdo notonernthemselveswithhowto analyse ordesigna system.
However, modern methods do have something to oer in providing quality aspets for a generative
pattern. The followingpoints represent pratiesfrom these ontemporarymethods thatan be used
to doument generative patterns:
Setion 2.3.2 omments on developers who found older methods too bureaurati. As a result,
manyofthemoderndevelopmentmethodsareode-orientedratherthandoument-oriented. This
aspet an be appliedto a generative designpatternin that disussionsaboutthe Problem and
Solution aspets of a pattern ould be kept to a minimum. More emphasis an be put into
designandimplementation,ratherthananalysis. Inthisrespet,generativepatternsouldmove
towards a more graphial notation than textual notation { however, this aspet is an issue for
furtherinvestigation.
One aspet that stands out with agile methods is soure ode. Again, as ommented upon in
oding. Borrowingfromthis, moreemphasisould beputinto usingsoureode to demonstrate
theusabilityofa generative pattern.
Providing more examples ofsoure ode supports useof the qualityaspets of USDP/RUP
dis-ussedinSetion 2.3.1 inthat dierent viewsof an arhiteturean be used to demonstrate the
generative onept of a pattern. In this respet, several dierent examples of soure-ode ould
beused to explainhowseveral patterns an work together.
Designisa keyaspetof designpatterns andis usedtoemphasisethestrutureof apattern, yet
designisusedsparinglyinmanydesignpatterns. TheRationalUniedProessmakesonsiderable
use of designtehniques, partiularlytheuse-ase diagram. From thisit an be onsideredthat
theuse-ase is a usefulmodellingaspet thatan be usedin a designpattern. The use-ase an
be used to illustrate a business aspet that is being demonstrated in a soure ode example of
ollaborating designpatterns.
One of the funtional aspets of agile methodsis exibility, inthat methods an be adapted to meet
the needs of dierent projet situations. Based on the idea of thinking in terms of dierent projet
situations and adapting to those, whih aounts for some of the exibility of agile methods, it is
oneivable that the same generative design patterns an be redened with alternative examples to
over a spei software domain. For example, patterns that are aimed at desktop appliations an
be dened witha dierent set of examples to patterns that are aimed at, for instane,lient / server
Chapter 3
UNDERSTANDING DESIGN PATTERN NOTATION
3.1 Introdution
Withinthe designpattern ommunitythere have ome several stylistiforms of patterns | the most
ommon being thestyle usedinthe DesignPatterns[45℄atalogue. Thisformat isoften referred to as
the GoF Format (Gang of Four), whih is a referene to the four authors of the Design Patterns[45℄
atalogue. Anotherformat is referred to as AlexandrianForm | the style of pattern written by the
ArhitetChristopherAlexander[2℄,whosepatternlanguagehasinspiredmuhofthegrowthinwriting
design patterns. Yet another form, and one that is often used in non-software patterns and patterns
that areonlydisussedinbrief,is thePortlandForm,whihis purelynarrative.
How patterns are written is only one fator in understanding the nature of the pattern itself. This
hapterisanexplorationofdesignpatterns,explainingtheirorigins,theirpurposeandtheirdistintions.
Inattemptingtounderstandthenatureofdesignpatterns,fourdierentpatternoneptsaredisussed:
Idioms,DesignPatternCatalogues,PatternSystemsandPatternLanguages. Alsowithinthishapter,
the rationale behind pattern notation and how that notation shouldreet the ontext in whih the
patternis desribed isdisussed. Knowing whya pattern isdesribed ina given way isimportant for
desribing newpatterntypes orrefatoringexisting patterns.
This hapter ontinues with a look at how elements of good pratie from within a diverse range of
design pattern types and styles an be abstrated for the benet of dening a generative pattern. A
seletionofpatternwritersfromdierentsoftwaredisiplinesandpatternoneptsisseletedforstudy.
Fromthisstudythemostfundamentalnotationisdeterminedandseletedasbeingthetypeofnotation
that anbe usedina generative patternwithoutluttering thepatternwithunneessary detail.
3.2 Patterns in Objet-Oriented Software
3.2.1 ThePattern Conept
Theurrentuseoftheterm`pattern'withinthesoftwareommunityispopularisedfromthewritingsof
planning. Although these books are ostensibly about arhiteture and urban planning, many of the
onepts apturedthereinareappliable to manyother disiplines,inludingsoftwaredevelopment[6 ℄.
Alexander proposed that urban development should be based on a olletion of reusable patterns. In
thesoftware domain,olletionsofpatternsanbeategorizedbytheirstrutureandintent. Basedon
strutureandintent,aPatternSystem isdierentto aPatternCatalogueorPatternLanguage,whih
aredened by theirspeiedrelationshipsexpressed withinthepatternolletions.
Eah pattern desribed by Alexander represents a single element in a hierarhy known as a pattern
language. Alexander's notionof apatternisthata patterndesribesa problemwhihoursoverand
over again inour environment, and then desribestheore of thesolutionto that problem,in suh a
way that you an use thissolution a milliontimes over, withoutever doing it thesame way twie[3 ℄.
Thisindiatesthatapatternisnotaxedentityand willprovide,ifrequired,auniquesolution. What
this implies is that the patterns an be modied to suit individual needs without losing the essene
that isentralto thepattern.
3.2.2 Idioms
Whilstdesignpatternsdesribegeneralstruturalproblems,idiomsarelessportablewhenviewedatthe
levelof a programminglanguage. Idiomsarethe lowest levelof abstrationin apattern lassiation.
Beause idioms are at a low level of abstration they are spei to a programming language. They
desribe how to implementpartiular omponents, theirfuntionality,and theirrelationshipsto other
omponents in the language itself. They may also depend upon, or represent, features that are not
present in other programming languages. For example, the pointer mehanism in C++ that has no
orresponding feature in the Java programming language. Beause idioms are at the lowest level of
abstration anddeal withsoureode, they represent a linkbetweendesignand implementation.
3.2.3 Pattern Catalogues { (Design Patterns)
A pattern atalogue is typiallya olletion of related patterns. It subdividesthe patterns into
sepa-rate ategories and may inlude some amount of ross-referening between them[6 ℄. Design Patterns:
Elements of ReusableObjet-Oriented Software[45℄isabenhmarkexampleofa patternatalogue and
typiesthe onept oftheDesign Patterninsoftware.
The motivation fordesign patterns and/or the pattern atalogue is the onept of software reuse. A
softwaredesign patternnames, abstrats, and identiesthe keyaspetsof a ommondesign struture
areorganisedbytherelationshipsbetweenthepatterns,whilstinapatternatalogue thepatternsare
organised by some lassiation sheme[84℄. The patterns in the Gamma[45℄ atalogue are divided
into Creational, Struturaland Behavioural. Theseare subdividedbysope asbeing ClassorObjet.
The design pattern identies partiipating lasses and instanes, their roles and ollaborations and
the distribution of responsibilities. The notation of the pattern desribeswhen it applies, whether it
an be applied in view of other design onstraints and the onsequenes and trade-os of its use[45 ℄.
The patternprovides graphialsolutionsusingabstrat modellingand exempliessolutions withode
fragments (whih might be thought of as being equivalent to reommending the type of briks and
mortar to use inan Alexandrian solution). Unlike Alexander'spattern language, the DesignPatterns
ataloguewasnotwithoutpreedent. ItfollowsAlexander'spriniplesonpatternsbutadaptsthegenre
forthesoftware domain.
Gamma's patternatalogue onsistsof 23 patterns,whih onformto a thirteen-pointstruture:
Rule Desription
Name Anamebywhihthepatternisknown
Intent Thepurposeofthepattern
AlsoKnownAs Apatternofasimilarnaturebutwithadierentname
Motivation Asenariothatillustratesthedesignproblem
Appliability Thesituationsinwhihthepatternanbeapplied
Struture Astandardmodellingnotation,e.g. UML
Partiipants Thedierentlassesandobjetsinvolvedinthedesign
Collaborations Howthepartiipantsollaborate
Consequenes Thewayinwhihthepatternsupportsitsobjetives
Implementation Pros,ons,hints,tehniques,languagespeiissues
SampleCode Anillustrationofhowthepatternmaybeimplemented
KnowUses Wherethepatternhasbeenappliedintherealworld
Related Patterns Otherpatternsthatanbeuse
