OOAD Session2

Elaboration
Oded Lachish
DepartmentofComputerScience
andInformationSystems
Birkbeck ,UniversityofLondon

Email: oded@dcs.bbk.ac.uk
WebPage: http://www.dcs.bbk.ac.uk/~oded

BBChttp://www.bbc.co.uk/news/ukpolitics12616777
Ministersaccusedof'circleoffailure'overITcosts

OnerecommendationisthatnewITsystemsshouldbebuiltpieceby
pieceandtestedbythosewhousethem.

TheTreasuryestimatesthatgovernmentITcostsapproximately16bn
peryear.

LordAdonis,theformerLabour ministerwhoisdirectoroftheInstitute
forGovernment,said:"ThebillionsspentoncancelledITprojects,such
asIDcardsandNationalProgramme forIT,demonstratepreciselywhy
weneedamuchmoreflexible approachtogovernmentIT.

LastTimeonOOAD
InthebeginningtherewasCHAOS
Waterfall
Agile
Iterative,Incremental,Interactive

UnifiedProcess(UP)
Inception
SupplementarySpecifications,Vision,Glossary
UseCaseModel

RemarksonInception

Mostusecaseswritteninbriefformat;1020%of
caseswritteninfullydressedformat
Mostinfluentialandriskyqualityrequirements
identified
FirstversionoftheVisionandSSdocuments

RemarksonUseCaseModel

Itistheinterfacepointwiththecostumerssokeepit
simple
Helpsuncoverstructurewhichmightbehiddenby
afeaturelist
NotjustastartingpointforAnalysisandDesign,but
alsoforverification

Usecasemodelandthenextstage
Use Case Model

Brief: oneparagraphdescribingthemainsuccessscenario
Casual: multipleparagraphsthatcovervariousscenarios
Fullydressed: ColemansUseCaseTemplate
SystemSequenceDiagram
Verification
UserManual

DomainModel

Elaboration

ElaborationOverview

ProgramandTest,coreandcriticalparts
oftheproject
Achieveastableversionofthemajorityof
therequirements
Mitigateorretiremajorrisks

23iterations

Artifacts at the beginning of Elaboration

Artifact

Description

Domain Model

Visualrepresentationofthedomain
model

DesignModel

LogicalDesign Diagrams

SoftwareArchitectureDocument
DataModel

UseCaseStoryboards, UIPrototypes

Summaryofkeyarchitecturalissuesand
theirresolution
Databaseschemas, mappingstrategies
betweenobjectandnonobject
representation
Userinterfacedescription,usability
models...

Fromrequirementsandanalysistodesign
ProcessSale

UPUsecaseModel

UPDomainModel
System sequence diagram

Sale
amount

Paidby
1

Payment
1 date

time
Sale
amount

Paidby
1

Payment
1 date

Time
getBalance():Money
getTotal():Money

UPDesignModel

System
Sequence
Diagrams

Whatelsecanwelearnfromtheusecases
Wehaveseenthatthroughtheusecaseswelearnwhatarethe
actorsthatinteractwithoursystem

Nowwewanttostudywhataretheinteractionsbetweenthe
actorsandthesystem

WeuseSystemSequenceDiagramstofindwhataretheevents
oursystemneedstodealwith
Thisgetsusalmostascloseaspossibletotheborderofthesystem,
afterwardswedotheinternals.

Systemsequencediagrams(SSDs)
Usecasesdescribehowactorsinteractwiththesoftware
system
UMLnotationforillustratingactorinteractions.
Givenascenarioofausecase,anSSDshows:
theexternalactorsthatinteractdirectlywiththesystem,
thesystemasablackboxand
thesystemeventsthattheactorsgenerate.
Theorderingofeventsshouldfollowtheirorderintheuse
case.
SSDsarepartoftheusecasemodel.
SSDsarevisualizationsofinteractionsimpliedintheusecases.

NextGenPOSsystem
UseCase

1.Process_Sale

Descirption

AuserarrivesataPOSsalespointandtriestopurchaseanitem.

Actors

Cashier(Primary)

Assumptions

Cashierisidentifiedandauthenticated

Steps

1. CustomerarrivesatPOScheckoutwithgoodstopurchase.
2. Cashierstartsanewsale.
3. WHILEmoreitemsDO
1. Cashierentersitemidentifier.
2. Systemrecordssalelineitemandpresentsitem
description,priceandrunningtotal.
ENDWHILE
4. Systempresentstotalwithtaxescalculated.
5. CashiertellsCustomerthetotal,andasksforpayment.
6. CustomerpaysandSystemhandlespayment.
7. Systempresentsreceipt.
8. Customerleaveswithreceiptandgoods(ifany).

AnSSDexample
:System

:Cashier
makeNewSale()
enterItem(itemID, quantity)
description, total
* [more_items]
endSale()
total with taxes
makePayment(amount)
change due, receipt

DomainModel

DomainModel
Avisualrepresentationofconceptualclassesorrealworld
objectsinadomainofinterest
ISNOT avisualizationofsoftwarecomponents
IS
Classdiagrams (UMLnotation)show:
conceptualclasses
attributesofconceptualclasses
associationsbetweenconceptualclasses

Conceptual classes
Threewaysofviewingaconceptualclass:
Symbol
Intension
Extension
Inadomainmodel,weareinterestedinboththesymbol
andtheintensionofaconceptualclass.

Sale
date
time

Asalerepresentsthe
eventofapurchase
transaction.Ithasadate
andatime.

sale-1

sale-3

sale-2
sale-4

Howtoidentifyconceptualclasses

1. Reuseandmodifyexistingmodels

2. Useacategorylist

3. Identifynounphrases

Category list

Conceptualclasscategory
Businesstransaction
Transaction lineitems

Examples
Sale,Payment, Reservation
SalesLineItem

Productorservicerelatedtoa
transactionortransactionlineitem

Item
Flight,Seat, Meal

Whereisthetransactionrecorded

Register, Ledger

Placeoftransaction

Store,Airplane, Seat

NextGenPOSsystem
UseCase

1.Process_Sale

Descirption

AuserarrivesataPOSsalespointandtriestopurchaseanitem.

Actors

Cashier(Primary)

Assumptions

Cashierisidentifiedandauthenticated

Steps

1. CustomerarrivesatPOScheckoutwithgoodstopurchase.
2. Cashierstartsanewsale.
3. WHILEmoreitemsDO
1. Cashierentersitemidentifier.
2. Systemrecordssalelineitemandpresentsitem
description,priceandrunningtotal.
ENDWHILE
4. Systempresentstotalwithtaxescalculated.
5. CashiertellsCustomerthetotal,andasksforpayment.
6. CustomerpaysandSystemhandlespayment.
7. Systempresentsreceipt.
8. Customerleaveswithreceiptandgoods(ifany).

Howtoidentifyconceptualclasses
Linguisticanalysis:Identify
nounphrasesintheusecases.

Useaconceptualclass
categorylist.

Process Sale

physicalobjects

Main Success Scenario:

specifications,descriptions

1. Customer arrives at a POS

checkout with goods to
purchase.

places
transactions

2. Cashier starts a new sale.

transactionlineitems

3. Cashier enters item

identifier.

rolesofpeople

4. System records sale line

item and presents item
description, price and total.

containersorcontaineditem
event
catalogetc.

Howtoidentifyassociations
Anassociationisarelationshipbetweenobjectinstances
thatindicatessomemeaningfulandinterestingconnection
worthremembering
derivedfromtheCommonAssociationsList
- Aisaphysical(orlogical)partofB
- Aisphysically(orlogically)containedin
- AisadescriptionofB
- Aisknown/captured/logged/recordedinB
- AusesormanagesB
- AisrelatedtoatransactionB
- Etc.

Candidateassociations
Relationshipsthatneedtoberemembered:
RegisterRecords Sale(why?)
SalePaidby Payment(why?)
ProductCatalog Records ProductSpecification (why?)
RelationshipsderivedfromtheCommonAssociationsList
SalesLineItem Iscontainedin Sale
StoreContains Item
ProductSpecification Describes Item
CashierIsmemberof Store
CashierUses/Manages Register
Customer/CashierMakes/Receives(Isrelatedto)Payment
Etc.

Multiplicity of associations
*

T
Attention!

1..*

1..2

1,2,5

T
T
T
T

The multiplicity value of a

relationship indicates
how many object
instances can be validly
associated with another,
at a particular moment,
rather than over a span
of time.

Adding associations (names/multipl.)

Product Catalog
SalesLineItem
Store

Sale

Captured-on
1
1

Register

Product Specification

Item

Manager

Cashier
Payment

Customer

Howtoidentifyattributes
Attributesinadomainmodelshouldpreferablybesimple
attributes ordatatypes
Commontypes:boolean,date,number,string,text,time
Othertypes:address,color,geometrics,phonenumber,
nationalinsurancenumber,universalproductcode,postal
codes
Donotrelateconceptualclasseswithanattribute!
Representadatatypeasanonprimitiveclassif:
Itiscomposedofseparatesections
Operationsareassociatedwithit(e.g.parsing)
Ithasotherattributes
Itisanabstractionofoneormoretypes

Adding attributes
1

ProductCatalog Contains

SalesLineItem
quantity

1 Used-by
*

1..*

Store

Contained-in

1
Paid-by

Captured-on
1
1

Register

Payment

Item

Started-by
1

Initiated-by

ProductSpecification

Stocks

Sale

1..*

Manager

1
Records-sale-on

Customer

Cashier

Pitfalls
Why?
Sale
store

Item
serial no
description
price
prodId

Store should
be a
separate
class

A
specification
or
description
class is
needed

Improved object model

Sale

Item
serial no

Store

Product
Specification
description
price
prodId

More pitfalls
Why?
Product Specification
description
prodID

Item

Describes
1

Payment
amount:Number

Cashier
name:String
currentRegister:Register

serial no
prodID

prodIDinclass
Itemisaforeign
key.Foreignkeys
mustnotbe
added.
amountisjusta
number.Where
isthecurrency?

currentRegisterisnotavalid
attribute.Theconnection
betweenCashierandRegister
shouldbedenotedwitha
relationship

LogicalArchitecture

LogicalArchitecture
Largescaleorganizationofsoftwareclassesinto
Layersthatareacoarsegraingroupingof
Classes
Packages
Subsystems

Logical because,thereisnodecisionofhowtheseelements
aredeployed

ExampleLayers
UI
Swing

Web

Domain
Sales

Payments

Taxes

Logging

RulesEngine

Technical Services
Persistence

Layers?
UI userinterface

ApplicationlogicandDomainObjects
Softwareobjectrepresentingdomainconceptsthatfulfil
applicationrequirements

TechnicalServices
Generalpurposeobjectsandsubsystemsprovidingsupporting
technicalservices.

LayerInteraction
UI

Strict,
Relaxed
Swing

Web

Domain
Sales

Payments

Taxes

Logging

RulesEngine

Technical Services
Persistence

DesignModel

DomainModel,DesignModelwhatsthedifference?
Bothusetheobjectorientedparadigm
DomainModeldescribestheproblemathand(doesthe
rightthing),whereastheDesignModeldesignsagood
solutionfortheproblem(doesthethingright)
DomainModelprovidesastaticviewofconceptual
classes,whereastheDesignModelprovidesbothastatic
andadynamicviewofsoftwareobjectsandclasses.

Interaction
Diagrams

Interactiondiagrams
InteractiondiagramsaretheheartoftheDesignModel
Theyillustratehowobjectsinteractviamessagesand
collaboratetofulfill therequirements
Theyprovideadynamicviewtothesystem
Manydesigndecisionsaretakenintheprocessof
generatinginteractiondiagrams
=>theircreationrequiresstrongdesignskills
But,firstletslookatthenotation!

Interactiondiagrams
Communication diagram

Sequence diagram

msg1()
:ClassAInstance
1.msg2()
2.msg3()

:ClassAInstance

:ClassBInstance

msg1()
msg2()

:ClassBInstance
msg3()

Commoninteractiondiagramnotation
Classesandinstances
classexample:

Payment

instanceexamples:

:Payment

p1:Payment

Messageexpressionsyntax
return:=message({parameter:parameterType}):
returnType
messageexample:
spec:=getProductSpec (id:ItemID):ProductSpec
(typeinformationcanbeomitted)

Sequencediagramnotation
Sequenceisinferredbyorderofarrowedlines(topbottom)
Activationboxesshowmessagenesting
Returnsareillustratedwithdottedlines
:ClassA
msg0()

:ClassB
msg1()
msg2()

create()

msg3()

msg4()

msg5()

:ClassC

Sequencediagramnotation(cont.)
Conditionalmessages
Messagestoclassobjects

:ClassA

:ClassB

msg0()
[day=Sunday] msg1()

opt

[day=workday]

msg2()
msg3()

:ClassC

Sequencediagramnotation(cont.)
Conditionalmessages
Mutuallyexclusiveconditionalmessages
Messagestoclassobjects
:ClassA

:ClassB

msg0(int amount)

alt

calculate()

[amount<10]
[else]

calculate()

:ClassC

Sequencediagramnotation(cont.)
Iterationofamessage
Iterationofmultiplemessages
IterationovertheitemsofaCollectionobject
:ClassAInstance

:ClassBInstance

msg0()
*[condition] msg1()

loop

msg2()
msg3()
*[i:=1..N]

:CollClassInst

Asynchronouscall
publicclassClockStarter{
publicvoidStartClock()
{
//Clockimplementstherunnableinterface
Threadt=newThread(newClock());
t.start();//asynchronouscalltotherunmethodonclock
}}

:ClockStarter
startClock()

System
create()

:Clock

run()
stopClock()

runFinalisation()

destroy()

Example:Cellularphone
Considerthesoftwarethatcontrolsaverysimplecellular
telephone.

Suchaphonehasbuttonsfordiallingdigits,andasend
buttonforinitiatingacall.

Ithasdiallerhardwareandsoftwarethatgathersthe
digitstobedialledandemitstheappropriatetones.

Ithasacellularradiothatdealswiththeconnectiontothe
cellularnetwork.

Ithasamicrophone,aspeaker,andadisplay.

CellularphoneUseCase
Usecase:MakePhoneCall
1.Userpressesthedigitbuttonstoenterthephonenumber.
2.Foreachdigit,thedisplayisupdatedtoaddthedigittothephonenumber.
3.Foreachdigit,thediallergeneratesthecorrespondingtoneandemitsitfromthe
speaker.
4.UserpressesSend
5.Theinuseindicatorisilluminatedonthedisplay
6.Thecellularradioestablishesaconnectiontothenetwork.
7.Theaccumulateddigitsaresenttothenetwork.
8.Theconnectionismadetothecalledparty.

CellularPhone:Connection
Anasynchronousmessageisamessagethat
returnsimmediatelyafterspawninganew
threadinthereceivingobject.TheConnect
message,forinstance,returnsimmediatelyto
theCellularRadioobject.Yetyoucanseeby
theactivationrectangleontheconnection
lifelinethattheConnectmethodcontinuesto
execute.TheConnectmethodisexecutingin
aseparatethread.Thisdemonstratesthe
powerthatsequencediagramshavefor
showingconcurrentmultithreaded
interactions.

Polymorphism
Payment {abstract}
authorise(){abstract}

DebitPayment
authorise()

CreditPayment
authorise()

Inheritance
:Register

Payment {abstract}

doX()
authorise()

:DebitPayment

:Foo

:CreditPayment

authorise()

doA()
doB()

authorise()

doX()

:Bar

Communicationdiagramnotation
Messagenumbersequencing
Messagedirection
Creationmessages
Selfmessages

2.create()

msg()
:ClassA

1.msg1()

:ClassB

Communicationdiagramnotation(cont.)
Nestingofmessages
Conditionalmessages
Mutuallyexclusiveconditionalpaths

1.msg1()

msg()
:ClassA

:ClassB
1.1 [cond1]:msg2()

2.msg3()
2b[not cond2].msg5()
:ClassC

2a[cond2].msg4()

:ClassD

Communicationdiagramnotation(cont.)
Iterationorlooping
Iterationoveracollection
Messagestoaclass,ratherthananinstance
ClassD
1.2: staticMsg()
1.msg1()

msg()
:ClassA
2*: msg3()

:ClassB
1.1 * [i=1..N]:msg2()

*
:ClassE

:ClassC

Asynchronousinvocation

startClock
:ClockStarter
1.create
2. run
:Clock

3.runFinalisation

System:Class

SequenceDiagram Vs.CommunicationDiagram

DiagramType

Strength

Weakness

Sequence

1. Forcesaclearexposition
oforderofmessages
2. Richnotations

1. Spaceconsuming
2. Rigid formatconstraints

1. SpaceEconomical
2. Flexibilitytoaddnew
objects

1. Lessnotationaloptions
2. Maygetmessy

Communication

DesignClass
Diagrams

DesignClassDiagrams(DCDs)
DCDs,DesignClassDiagrams,provideastaticviewofthe
DesignModel
DCDsarecreatedinparallelwithInteractiondiagrams
ExampleDCD:

Sale

Register

Captures
1

enterItem()

date
time
isComplete:Boolean
makeLineItem()

DesignClassDiagrams(DCDs)
DCDsillustrate:
Classesandinterfaces
Associations(andnavigability)
Attributesandoftentheirtypes
Methods,theirparameters,andoftenparameterand
methodresulttypes
HowareDCDsdifferentfromclassdiagramsoftheDomain
Model?
HowareDCDsdifferentfrominteractiondiagrams?

HowtogenerateDCDs
IdentifysoftwareclassesbylookingattheInteractiondiagrams
ortheDomainModelclassdiagrams.Someoftheclassesinthe
DomainModelmaybeomitted.
Addattributesbasedontheattributesoftheclassesinthe
DomainModel(ortheattributesofobjectsintheInteraction
diagrams).IntheDesignModel,additionalattributesmaybe
added(thatarenotdefinedintheDomainModel).Typesof
attributesmayalsobeadded.
AddmethodsbyanalyzingtheInteractiondiagrams.Ifa
messageissenttoaninstanceofaclassA,thenclassAinaDCD
mustdefineamethodwiththesamename.
AddassociationsbydrawinginspirationfromtheDomain
Modelandconsideringvisibility betweenobjects

AssociationsinDCDs
AssociationsinDCDsareformedbasedonattribute
visibility:
Navigabilityarrowsindicateattributevisibilityfromthe
sourcetothedestinationclass.Attributespointingto
visibleobjectsareusuallyomitted.

Register
(Can be
omitted)

currentSale:Sale 1
enterItem()

Sale
Captures
1

date
time
isComplete:Boolean
makeLineItem()

Parametervisibility:makeLineItem(ProductSpecification spec,int qty)

Dependency

InUMLmodelling,adependencyrelationship
isarelationshipinwhichchangestoone
modelelement(thesupplier)impactanother
modelelement(theclient).Youcanuse
dependencyrelationshipsinclassdiagrams,
componentdiagrams,deploymentdiagrams,
andusecasediagrams.
client

supplier

Addingdependencyrelationships

Dependencyrelationshipindicatesthatone
element(ofanykind,includingclasses,use
cases,andsoon)hasknowledgeofanother
element.

Adependencyisa using relationshipthat

statesachangeinspecificationofonething
mayaffectanotherthingthatusesit,but
notnecessarilythereverse.

Continue

Thedependencyrelationshipisusefulto
depictnonattributevisibilitybetween
classes.

Parameters
Globalorlocalvisibility
Adashedarrowline
Adasheddirectedline

DependencyrelationshipsinDCDs
Dependencyrelationshipsindicatenonattributevisibilityand
areillustratedwithdashedarrowlines.
Register

Sale
Captures
1

enterItem()
1
Looks-in

date:Date
time:Time
isComplete:Boolean
makeLineItem()

ProductSpec

ProductCatalog
Contains

getSpec ()

1..*

description:Text
price:Money
prodId:Integer

Creatingmethodsfrominteractiondiagrams
Aninteractiondiagramshowsmessagessentinresponsetoa
methodinvocation.
2:makeLineItem(spec,qty)

enterItem(prodId,qty)

:Register
1:spec:=getSpecification(prodId)

catalog:Product
Catalog
public void enterItem (prodId id, int qty)
{
ProductSpec spec = catalog.getSpecification(prodId);
sale.makeLineItem (spec, qty);
}

sale:Sale

Dependency relationships
non-attribute visibility

Implementation
Model

Codechangesandtheiterativemodel
Iterative Cycles of Development

Requirements
Analysis

Requirements
Analysis

Design

Design

Implementation

Implementation
Time

Implementationmodel
InteractiondiagramsandDCDs:inputtocodegeneration
TheImplementationModelincludes:
sourcecodeforclasses
databaseschema
XML/HTMLpages
etc.
WritingcodeinanOOprogramminglanguage(likeJava)isnot
consideredpartofOOA/D
MostofthecreativeworktookplaceduringOOA/D.Transition
toimplementationismostlymechanical
Expectdeviationsfromthedesignduringprogramming

CreatingclassdefinitionsfromDCDs
Straightforwardmappingofattributedefinitionsandmethod
signatures.Dontforgettoaddconstructors.
ProductSpec

SalesLineItem
quantity:Integer

Described-by
*

description:Text
price:Money
itemID:prodId

getSubtotal():Money

public class SalesLineItem

{
private int quantity;
public SalesLineItem(ProductSpec spec, int qty) { }
public Money getSubtotal() { }
}

Referenceattributes
Areferenceattributeisanattributethatreferstoanother
object,nottoaprimitivetypesuchasString,Numberandso
on.
ProductSpec
SalesLineItem
Described-by
description:Text
1

quantity:Integer

productSpec

price:Money
itemID:ItemID

getSubtotal():Money

public class SalesLineItem

{
private int quantity;
private ProductSpec productSpec;
public SalesLineItem(ProductSpec spec, int qty) { }
public Money getSubtotal() { }
}

Creatingmethodsfrominteractiondiagrams
Aninteractiondiagramshowsmessagessentinresponsetoa
methodinvocation.
2:makeLineItem(spec,qty)

enterItem(prodId,qty)

:Register
1:spec:=getSpecification(prodId)

catalog:Product
Catalog
public void enterItem (ItemID prodId, int qty)
{
ProductSpec spec = catalog.getSpecification(prodId);
sale.makeLineItem (spec, qty);
}

sale:Sale

Nowwhat?

Maindesignconsideration
AcriticaltaskintheDesignModelistoassign
responsibilitiestoobjects.
Theusecasesdescribedifferenttasksthatmustbe
performedintheircontext.Whoisresponsiblefor
performingthesetasks?Aretheygoingtobeperformedby
oneelement(object)ordelegatedto(sharedamongst)
manyelements?
Responsibilitiesareobligationsofanobjectintermsofits
behaviour.Therearetwokinds:
knowing
doing

Objectresponsibilities
Doing responsibilitiesofanobjectinclude:
creatinganobject,doingacalculation,initiatingactionin
otherobjects,coordinatingactivitiesinotherobjects
Knowingresponsibilitiesofanobjectinclude:
knowingaboutprivatedata,aboutrelatedobjects,about
thingsitcanderiveandcalculate
Examples:
ASaleisresponsibleforcreatingSalesLineItem
ASaleisresponsibleforknowingitstotal

Responsibilitiesandmethods
Ingeneral,responsibilitiesareimplementedusingmethods.
Methodseitheractaloneorcollaboratewithotherobject
methods.
Dependingonitsgranularity,aresponsibilitymay
correspondtoasinglemethodinaclass,oritmayinvolve
manymethodsacrossmanyclassespackagedina
subsystem.

Responsibilitiesandinteractiondiagrams
Howdoweassignresponsibilities(implementedas
methods)toobjects?Interactiondiagramsshowchoicesin
assigningresponsibilities.
:Sale

makePayment(cashRcvd)

create(cashRcvd)

:Payment

It implies Sale objects have a responsibility to create Payments. This

responsibility is invoked with a makePayment message and handled with
a corresponding makePayment method.

Responsibilitiesandmethods
Ingeneral,responsibilitiesareimplementedusingmethods.
Methodseitheractaloneorcollaboratewithotherobject
methods.
Dependingonitsgranularity,aresponsibilitymay
correspondtoasinglemethodinaclass,oritmayinvolve
manymethodsacrossmanyclassespackagedina
subsystem.
Objectcollaborationoftenresultsindependencies.

Responsibilitiesandinteractiondiagrams
Howdoweassignresponsibilities(implementedas
methods)toobjects?Interactiondiagramsshowchoicesin
assigningresponsibilities.
:Sale

makePayment(cashRcvd)

create(cashRcvd)

:Payment

It implies Sale objects have a responsibility to create Payments. This

responsibility is invoked with a makePayment message and handled with
a corresponding makePayment method.

Patterns
Patternsguideobjectorienteddevelopersinthecreationof
software.
Theycodifyexistingtriedandtrueknowledgeand
principles;themorewidelytheyareused,thebetter.
Theyareexpressedinastandardformat:
PatternName:
Solution:
ProblemItSolves:

PatternExample:TheInformationExpert
PatternName:InformationExpert
Solution:Assignaresponsibilitytotheinformationexpert
theclassthathastheinformationnecessarytofulfill the
responsibility.
ProblemItSolves: Whatisageneralprincipleofassigning
responsibilitytoobjects?
Consequences:Thesearetheresultsandtradeoffsof
applyingthepattern.Criticalforevaluatingdesigndecisions
intermsofreusability,flexibility,portability.

Whyarepatternsuseful?
Patternsareverysimpletouse.
Theyareapplicableinmanycontexts;infact,thenotionof
anewpatterncouldbeconsideredanoxymoron.
Ifonelearnshowtoapplythemproperly,s/hewillgenerate
designsthatareeasytounderstand,maintainandreuse.
Byreferringtopatternnames,designerscancommunicate
easilyandexplainthereasonsbehindtheirdesignchoices.
Patternsprovideaformalframeworkforgeneratinggood
designs=>avoidhandwaving.