National University of Computer

and Emerging Sciences

Software Design and Analysis

Majid Hussain
Class Diagram and Grasp pattern
 Revision Up till Now
High- System
Set of Use
Level Domain Model Sequenc
Requireme Case e
and
nts Diagram Diagram
Expanded
Use cases
Use case
Identification Main
Non- Functional • Boss test Success
Functional Requiremen • Elementary Business Scenarios
Requiremen ts Process
ts • Size Test
 Represent feature/functions/user goals

Class Diagram Sequence

Diagram & in parallel
Class Diagram
• A class consists of
• properties (attributes),
• behavior (operations),
• relationships to other objects,
• Examples
• Employee: has a name, employee# and department; an
employee is hired, and fired; an employee works in one or
more projects
 Class Diagram Notation

Attribute
type Name of the class
Attribute
name Student

+ name: string = “Anon”

+ registeredIn: Course [*]
Visibility: Default value
+, -, #
+ register (c: Course) Multiplicity
+ isRegistered (c: Course) : Boolean

Operation
name Return value
Parameters
 Navigability

Order
+ dateReceived: Date [0..1]
+ isPrepaid: Boolean
+ lineItems: OrderLine [*]
Bidirectional Association

How implement it?

Person Car
+ carsOwned: Car [*] + Owner: Person [0..1]
Generalization/Specialization
• Generalization hierarchies may be created by generalizing
from specific things or by specializing from general things.
Inheritance
• Class inheritance is implicit in a generalization relationship
between classes.
• Subclasses inherit attributes, associations, & operations
from the superclass

What is the
inheritance
mechanism in Java?
Inheritance

Java Inheritence
• A subclass may override an inherited aspect
• e.g. AdminStaff & CreativeStaff have different
• methods for calculating bonuses
• A Subclass may add new features
• qualification is a new attribute in CreativeStaff
• Superclasses may be declared {abstract}, meaning
they have no instances
• Implies that the subclasses cover all possibilities
• e.g. there are no other staff than AdminStaff and
CreativeStaff
 Aggregation
• This is the “Has-A” relationship
aggregation

Club Member
* *

:Car :Train
0..1 0..1
:Person 0..*
driver 1 passengers
aggregation
Aggregation and Composition
• Composition is strong form of aggregation that
implies ownership:
• if the whole is removed from the model, so is the part.
• the whole is responsible for the disposition of its parts
• Note: Parts can be removed from the composite (where allowed) before
the composite is deleted

Polygon {ordered} Point centre Circle

3..* 1
 Aggregation and Composition

1 :Engine

composition
:Locomotive1..*
1 0..1
:Car :Train
0..1 0..1
:Person 0..*
driver 1 passengers
aggregation
 UML CLASS DIAGRAM ACTIVITY

A hockey league is made up of at least four hockey teams. Each hockey team is
composed of six to twelve players, and one player captains the team. A team has
a name and a record. Players have a number and a position. Hockey teams play
games against each other. Each game has a score and a location. Teams are
sometimes lead by a coach. A coach has a level of accreditation and a number of
years of experience, and can coach multiple teams. Coaches and players are
people, and people have names and addresses.
Draw a class diagram for this information, and be sure to label all associations
with appropriate multiplicities that are required to develop the above system.

13
14
Object-Oriented Design
• “After identifying your requirements and creating a
domain model, then add methods to the software
classes, and define the messaging between the
objects to fulfill the requirements.”

• But how?
• How should concepts be implemented by classes?
• What method belongs where?
• How should the objects interact?
• This is a critical, important, and non-trivial task
 Why Patterns?

• A Design Model may have hundreds or even thousands of software classes and
hundreds or thousands of responsibilities to be assigned.

• During object design, when interactions between objects are defined; we make
choices about the assignment of responsibilities to software classes..

• Let’s look at a few Grasp Patterns…

16
17
Design Patterns - GRASP A design pattern is a general
repeatable solution to a
commonly occurring problem
in software design

• Responsibility Driven Development Design patterns can speed up

the development process by
providing tested, proven
development paradigms
• General Responsibility Assignment Software Patterns

• Information Expert
• Creator
• High Cohesion
• Low Coupling
• Controller
 Controller
• A simple layered architecture has a user interface layer (UI) and a
business logic layer.
• Actors, such as the human user, generate UI events (such as clicking a
button).
• The UI software objects (such as a JFrame window and a JButton) must
process the event.
• When objects in the UI layer pick up an event, they must delegate the
request to an object in the domain layer.

• Problem: What first object in the business logic layer should receive the
message from the UI layer?
OR in other words
• Who should be responsible for handling system events ?
Controller
• The Controller is also an important idiom in modern web
development frameworks, in forming a pillar of the Model-
View-Controller architectural pattern. Controllers are used
in AngularJS, Ruby on Rails, Sails and more.

20
Problem: What first object in the
business logic layer should
receive the message from the UI
layer?

Solution:
Façade Controller to hide the
complexity
• Works as a wrapper
• Should not contain
business logic
Controller
• Which class will receive the first system call?

• 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.
Façade Controller

• All system operations are assigned to one

controller.
 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).
• Benefits
– can reuse this controller class.
– Can use to maintain the state of the use case.
– Can control the sequence of the activities
Bloated Controller
• Controller class is called bloated, if
– The class is overloaded with too many responsibilities.
– Solution: Add more controllers

• The responsibility of controller class is to delegate

things to others.
• It will not perform any kind of business logic/ calculations.
Example

System Sequence Diagram

Domain Model

Sequence Diagram

26
Controller Demo

27
28
Information Expert
• Problem : What is general principle of assigning
responsibilities to Objects?

• Solution : Assign Responsibility to class that has the

information to fulfil the responsibility

• Decision of which class to call? The class that has relevant

data
• Can be current class or some other class
Benefits
• Information encapsulation is maintained since objects use
their own information to fulfill tasks.

• This usually supports low coupling, which leads to more

robust and maintainable systems.

• Behavior is distributed across the classes that have the

required information, thus encouraging more cohesive
"lightweight" class definitions that are easier to understand
and maintain.
Example
• 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.
Creator
• Problem: Who should be responsible for creating new instances of
a class?
• “Container” object creates “contained” objects.
• Decide who can be creator based on the objects association and
their interaction.

• Solution: B creates If,

• B aggregates A
• B contains A
• B records A
• B closely uses A
• B initializes A
Sequence Diagram – illustrates Creator Pattern
Low Coupling
• Problem: How to support Low dependency, low change impact, increase re-
use ?
Coupling
• How dependent one element (e.g. class) is on other High coupling
elements (e.g. classes)

• Coupling is a measure of how strongly one element is

connected to, has knowledge of, or relies on other
elements.

• High coupling is problematic

Problems with High Coupling
• High coupling would mean that your class knows the way too much
about the inner workings of other classes.

• classes that know too much about other classes make changes hard to
coordinate and make code brittle and difficult to reuse.

• If class A knows too much about class B, changes in class B may break
the functionality in class A.
Low Coupling
• Problem: How to achieve low dependency, low change
impact, increase re-use ?

• Solution : Assign responsibilities so that coupling

remains low.
Low Coupling
Low coupling is an evaluative pattern that dictates how to High
assign responsibilities for the following benefits: coupling

• lower dependency between the classes

• change in one class having a lower impact on other
classes
• higher reuse potential.

Low
coupling
Coupling

39
Example (High Coupling)
Example (Low Coupling)
 Example
Domain Model System Sequence Diagram

Sequence Diagram
Design Alternative

o r
o
P si g n
D e
High Cohesion
• Cohesion refers to how the functions of a class belong
together. Related code should be close to each other to
make it highly cohesive.

• Problem: How to keep complexity manageable ?

• Solution : Assign responsibilities so that cohesion remains high.
• Note low cohesion and high coupling often go together.
Cohesion

44
 High Cohesion
• How are the operations of any element
functionally related?

• Related responsibilities in to one manageable

unit

• Prefer high cohesion

• Clearly defines the purpose of the element

• Benefits
• Easily understandable and maintainable.
• Code reuse
• Low coupling
Example of Low Cohesion
Example of High Cohesion
Pure Fabrication
• If domain model provides no reasonable concept to
assign responsibility without violating
cohesion/coupling -> create a new abstraction (e.g.,
PersistantStorage).

• Assign a highly cohesive set of responsibilities to

an artificial or convenience class that does not
represent a problem domain concept—something
made up, to support high cohesion, low coupling,
and reuse
47
GRASP Pattern
Initial Domain Model Sequence Diagram Software Class

Sale
date
time

Contains
:Sale
*
Product date
SalesLineItem Specification t := getTotal()
: Sale time
* 1
Described by description getTotal()
quantity
price
itemID
Domain Model

49
System Sequence Diagram

50
makeNewSale()

Controller ?

Information Expert ??

Creator ??

51
Explanation
 Register may be thought of as recording a Sale
• Register is a reasonable candidate for creating a Sale.
• By having the Register create the Sale, the Register can easily be
associated with it over time,
• During future operations within the session, the Register will have a
reference to the current Sale instance.

 When the Sale is created

• it must create an empty collection (container) to record all
future SalesLineItem instances that will be added.
• This collection will be contained within and maintained by
the Sale instance,

 Therefore:
• the Register creates the Sale
• the Sale creates an empty collection, represented by a multiobject in the
interaction diagram.
52
enterNewItem(itemID, quantity)

First step: access ProductDescription based on the itemID

ProductCatalog is information expert of ProductDescriptions

53
54
Code level
view

55
Class Diagram, So far

56
endSale – Design Decisions
• Sale is to be completed
• Total with tax calculated is presented

57
endSale()

58
59
getTotal()

60
makePayment(cashTendered)

61
62
63