Software Design and Analysis

CS-3004
Lecture#10

Dr. Javaria Imtiaz,

Mr. Basharat Hussain,
Mr. Majid Hussain
Quiz # 4

Write code for the given sequence diagram.

:Runner
createMVC
create :

create :

create :

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

• Often make Sequence diagram and Class Diagram in

parallel using the domain model and SSD
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

5
Class Diagram Notation

Attribute
type Name of the class
Attribute
name Student

+ name: string = “Anon”

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

Operation
name Return value
Parameters

6
Navigability

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

7
Bidirectional Association

How implement it?

Person Car
+ carsOwned: Car + Owner: Person
[*] [0..1]

8
Generalization/Specialization
• Generalization hierarchies may be created by generalizing from
specific things or by specializing from general things.

9
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?

10
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

11
Aggregation
• This is the “Has-A” relationship
aggregatio
n
Memb
Club
er
* *

:Car :Train
0.. 0..
1 :Person 0..
driv 1 * passenger1
aggregatio er s
n

12
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

Polygo {ordere Point centr Circle

d} e
n 3.. 1
*
13
Aggregation and Composition

:Engin
1
e
compositi :Locomoti
on 1..
1
ve *
0..
:Car 1 :Train
0.. 0..
1 :Person 0..
driv 1 * passenger1
aggregatio er s
n

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
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

• Controller
• Information Expert
• Creator
• Low Coupling
• High Cohesion
• Pure Fabrication

16
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 ?

17
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.

18
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

24
Controller Demo

25
26
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

27
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.

28
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.

29
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
30
Sequence Diagram – illustrates Creator Pattern
Low Coupling
• Problem: How to support Low dependency, low change impact, increase re-
use ?

32
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.

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

• lower dependency between the classes

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

Low coupling
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
39
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.

40
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

43
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

45
System Sequence Diagram

46
makeNewSale()

Controller ?

Information Expert ??

Creator ??

47
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.
48
enterNewItem(itemID, quantity)

First step: access ProductDescription based on the itemID

ProductCatalog is information expert of ProductDescriptions

49
50
Code level
view

51
Class Diagram, So far

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

53
endSale()

54
55
getTotal()

56
makePayment(cashTendered)

57
58
59