DESIGN

PRINCIPLES
Dr. Salome Maro
12th June 2023
RECAP
 Collaboration diagrams:
is a graph showing a
number of objects and the
links between them, which
in addition shows the
messages that, are passed
from one object to
another.
OBJECT/CLASS
RESPONSIBILITIES
 What responsibility should a certain object do?

 A responsibility can be accomplished by a single object, or a group of objects

collaboratively.

 Two types of responsibilities:

 Doing – creating, computing or coordinating tasks
 Knowing – having access to object data or object references
GRASP
 Design principles intended to make software designs more understandable,
flexible and maintainable.
 General Responsibility Assignment Software Patterns (GRASP)
 9 principles of GRASP:
1. Information Expert
2. Creator
3. Low Coupling
High Cohesion
GRASP
4.
5. Controller
6. Polymorphism
7. Pure Fabrication
8. Protected Variations
9. Indirection
INFORMATION EXPERT
 Given an object o, which responsibilities can be assigned to o?

 Principle of “Information Expert”: Assign a responsibility to the class that has

the information needed to fulfil it.

 So, assign those responsibilities to o for which o has the information to fulfil
that responsibility
INFORMATION EXPERT
 Expert leads to designs where a software object does those operations which
are normally done to the real-world (or domain) object it represents; this is
called the “DO it Myself” strategy.

 Fundamentally, objects do things related to information they know.

 The use of the Expert pattern maintain encapsulation, since objects use their
own information to fulfill responsibilities.
INFORMATION EXPERT –
EXAMPLE
 Consider VideoStore and Video in that store.
 VideoStore has an aggregation association with Video. I.e, VideoStore is the
container and the Video is the contained object.
 Assume we need to get all the videos of a VideoStore.
 Since VideoStore knows about all the videos, we can assign this responsibility
of giving all the videos can be assigned to VideoStore class.
 VideoStore is the information expert.
INFORMATION EXPERT
EXAMPLE
 SuppD o c s
do c ID 1 ...* uplo ad Ve nue
CV *
do c D e s c
D ate U plo ade d ve nue N am e L o c atio n
1
Inte rvie we e lo c atio nN am e
C e rtific a te s 1 ...* 1
Sys U s e r fN am e H as
m N am e 1
fN am e SirN am e
m N am e 1 ...* Inte rvie w
Inte rvie we r G e nde r
SirN am e inte rvie wN o Inte rvie wN o
G e nde r P as s wo rd Inte rvie wD e s rp
Sys Adm in U s e rnam e e m ail 1 c re ate dD ate J o bD e s c riptio n
P as s wo rd pho ne inte rvie wC re ato r 1
I n terv iew er e m ail Tim e jo bID
pho ne 1 de s c riptio n
1
Ans we rM arks Inte rvie wQ ue s t 1
Q ue s tAns we rs 1...*
m arks Q ue s tN o
1 Ans we r 1
D ate C re ate d Q ue s tD e s c *
D ate C re ate d
Q ue s tio nC re at D ate C re ate d
1 Ans we rC re ato r 1 ...* Spe c ializatio n
or Q ue s tio nC re ato r
Q ue s tio nType
Spe c ializatio nID
type ID D e s c riptio n
D e s c riptio n
Inte rvie wG rade
grade
rank
CREATOR
 The creation of objects is one of the most common activities in an OO system.
 Who creates an Object? Or who should create a new instance of some class?
 “Container” object creates “contained” objects.
 Decide who can be creator based on the objects’ association and their
interaction.
CREATOR
Pattern Name Creator

Solution Assign class B the responsibility to create an instance of class A if one of these is true:
1. B aggregates A
2. B contains A
3. B records A
4. B closely uses A
5. B has the initializing data for A
Thus, B is an expert with respect to creating A objects

Problem What should be responsible for creating a new instance of some class?
CREATOR EXAMPLE
 Consider VideoStore and Video in that store.
 VideoStore has an aggregation association with Video. I.e, VideoStore is the container, and the
Video is the contained object.
 So, we can instantiate video object in VideoStore class
CREATOR EXAMPLE
LOW COUPLING
 Coupling is a measure of how strongly one class is connected to, has knowledge of, or relies
on other classes.

 A class with low (or weak) coupling is not dependent on too many other classes.

 When we assign a responsibility to a class, we would like to assign responsibilities in a way so

that coupling between classes remains low.

 A class with high (or strong) coupling relies upon many other classes.
 LOW COUPLING
m a ke P a ym e nt 1:c re a te ()
 The second design is preferable :P O S T p :P aym e n t
because it does not need an extra
2:a ddP a ym e nt(p)
link formed between POST and :S ale
Payment.

 This assignment of responsibility is m a ke P a ym e nt() 1:m a ke P a ym e nt()

also justifiable as it is reasonable to :P O ST :Sale
think that a Sale closely uses a
1.1:c re a te ()
Payment.

:P aym e nt
LOW COUPLING
 Classes with high (or strong) coupling are undesirable; they suffer
from the following problems:
 Changes in related classes force local changes, i.e. changes in this class.
 Changes in this class force the changes in many other related classes.
 Harder to understand in isolation.
 Harder to reuse as its reuse requires the use of the related class.

Pattern Low Cohesion

Name
Solution Assign a responsible so that coupling remains low
Problem How to support low dependency an increased reuse?
LOW COUPLING
 Coupling may not be that important if reuse is not a goal, and there is not
absolute measure of when coupling is too high.

 While high coupling makes it difficult to reuse components of the system, a

system in which there is very little or no coupling between classes is rare.
HIGH COHESION
 Cohesion or coherence is the strength of dependencies within a subsystem.
 Cohesion is a measure of how strongly related and focused the responsibilities
of a class are.
 A component is cohesive if all its elements are directed towards a task and the
elements are essential for performing the same task.
 If a subsystem contains unrelated objects, coherence is low.
 High cohesion is desirable.
HIGH COHESION
 A class with low cohesion is undesirable as it suffers from the following
problems:
 hard to comprehend;
 hard to reuse;
 hard to maintain;
HIGH COHESION
 A class with high cohesion has highly related functional responsibilities and
does not do tremendous amount of work.
 Such classes have a small number of methods with simple but highly related
functionality.
 In a good object-oriented design, each class should not do too much work.
 Assign few methods to a class and delegate parts of the work to fulfill the
responsibility to other classes.
HIGH LiftC o ntro lle r

COHESION –
ge tFlo o r()
EXAMPLE m o ve Lift()
se tTrip()
e m e r g e nc yP r o c e dur e ()
r ai se Al ar m ()
update L e d()
o pe nD o o r s ()
c l o se D o o r s ()
re se t()
startU p()
shutD o wn()
di spl ayL o g ()
HIGH COHESION – EXAMPLE
 Note that a class should represent Alarm
one “thing” from the real would. c a n ra ise rais e ()

L ift c a n w rite to
 Key separate abstractions from m o ve ()
liftController are: update L e d()
c a n w rite to
Log
 An Alarm ge tFlo o r()
dis play()
 Lift Door c le ar()

 Doors o pe n()
 Logs c lo s e ()
HIGH COHESION
 The benefits from the use of the High Cohesion Pattern include:
 Clarity and ease of comprehension of the design is increased.
 Maintenance and enhancements are simplified.
 Low coupling is often supported.
 Supports reuse.
CONTROLLER
 Deals with how to delegate the request from the UI layer objects to domain layer objects.
 When a request comes from UI layer object, Controller pattern helps us in determining what is
that first object that receive the message from the UI layer objects.
 This object is called controller object which receives request from UI layer object and then
controls/coordinates with other object of the domain layer to fulfill the request.
 It delegates the work to other class and coordinates the overall activity.
CONTROLLER
 We can make an object as Controller, if
– Object represents the overall system (facade controller)
– Object represent a use case, handling a sequence of operations (session
controller).
CONTROLLER
 Introduce a new class, and make it sit between the actor and the business
classes.
 The name of this controller is usually called <name>Handler.
 Handler reads the commands from the user and then decides which classes the
messages should be directed to.
 The handler is the only class that will be allowed to read and display.
CONTROLLER EXAMPLE
BLOATED CONTROLLERS
 Controller class is called bloated, if
 The class is overloaded with too many responsibilities.
 Solution – Add more controllers

 Controller class also performing many tasks instead of delegating to other

class.
 Solution – controller class has to delegate things to others.
POLYMORPHISM
 How to handle related but varying elements based on element type?

 Polymorphism guides us in deciding which object is responsible for handling

those varying elements.

 Benefits: handling new variations will become easy.

POLYMORPHISM EXAMPE
The getArea() varies by the type of
shape, so we assign that
responsibility to the subclasses.

By sending message to the Shape object,

a call will be made
to the corresponding sub class object –
Circle or Triangle.
PURE FABRICATION
 Fabricated class/ artificial class – assign set of related responsibilities that
doesn't represent any domain object.
 Provides a highly cohesive set of activities.
 Behavioural decomposed – implements some algorithm.

 Benefits:
 High cohesion,
 low coupling and can reuse this class
PURE FABRICATION –
EXAMPLE
 Classes in a domain model of a banking application:
 Account,
 Branch,
 Cash,
 Check,
 Transaction, etc.
 The domain classes need to store information about the customers.
PURE FABRICATION –
EXAMPLE
 The domain classes need to store information about the customers.
 Option 1: delegate data storage responsibility to domain classes.
 This option will reduce the cohesiveness of the domain classes (more than
one responsibility).
 Option 2: Introduce another class which does not represent any domain
concept.
 Introduce a class called, PersistenceProvider.
 This class does not represent any domain entity.
 The purpose of this class is to handle data storage functions.
 Therefore PersistenceProvider is a pure fabrication.
PURE FABRICATION EXAMPLE
 In e-commerce systems we often have need to convert one currency to another.

 Sometimes it is hard to say where this behavior should be placed so the best
option is to create new class called currencyConverter whose only job is to
make conversions
INDIRECTION
 How can we avoid a direct coupling between two or more elements.
 Indirection introduces an intermediate unit to communicate between the other
units, so that the other units are not directly coupled.
 Benefits: low coupling

Question: How to de-couple objects so that low coupling is supported, and

reuse potential remains higher?
INDIRECTION EXAMPLE
 Technology encapsulation
PROTECTED VARIATION
 Similar to the open-closed principle, which states that software entities should be
open for extension but closed for modification.
 How to avoid impact of variations of some elements on the other elements.
 It provides a well-defined interface so that the there will be no affect on other
units.
 Provides flexibility and protection from variations.
 Provides more structured design.
 Question: How to design objects, subsystems, and systems so that the variations
or instability in these elements does not have an undesirable impact on other
elements?
PROTECTED VARIATION –
EXAMPLE
 Examples:
 Strategies to hide different APIs
 Strategies to hide different algorithms
PROTECTED VARIATION –
EXAMPLE
GRASP
 GRASP principles are interrelated and should be considered as a together.
 Example:
 Indirection, low coupling, and high cohesion are clearly interlinked.
 Pure fabrication is also related with low coupling and high cohesion
MODELLING TOOLS
 Using a modelling language as complex and extensive as UML requires the
support of tools.

 Even if the first sketches of a model are done using a whiteboard (drawing the
models manually), the work of maintaining, synchronizing, and providing
consistency in a number of diagrams is almost impossible without a tool.
WISH LIST FOR MODELLING
TOOLS
 Wish list for features of a modelling tool:
 Drawing
 Repository
 Navigation
 Provide multi-user support
 Generate code
 Reverse engineer
 Integrate with other tools
 Cover models of all abstraction levels
 Interchange models

Read the UML2 Book page 45 -- 53

COMMON UML MODELLING
TOOLS
 Agro UML
 Diagrams.net (Google)
 Microsoft visio
 StarUML
 LucidChart
 Eclipse Papyrus
 Etc.

A more comprehensive list from Wikipedia:

https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
QUESTIONS?
TEST 2
 Monday 22nd June 2023.