Object-Oriented Software Design

1
Functional oriented software design

2
 Object oriented design approach

• System is viewed as the collection of objects i.e. entities.

• Each object has own state and behaviour.

• STATE: Built in characteristics or properties of objects.

e.g. TV has size.

• Behaviour: Predefined functions.

e.g. TV can show picture, change the channel etc.
Person can walk , person can sleep.

3
• Similar features objects are kept inside a class

4
 Object-oriented Concepts

Basic Mechanisms:
– Objects: All the entities involved in the design are known
as objects
• A real-world entity.

• A system is designed as a set of interacting objects.

• Consists of data (attributes) and functions (methods)

that operate on data

• Hides organization of internal information (Data

abstraction)
Examples: an employee, a book etc.
5
 Object-oriented Concepts

m8 m7
mi are methods
of the object

m1 m6
Data
m2 m5

Object

m3 m4
Model of an object

6
 Object-oriented Concepts

Class:
Class defines all the attributes + methods to
perform.
• Instances are objects
• Template for object creation
• Examples: set of all employees, different types of book

7
 Object-oriented Concepts

Methods and message:

Objects communicates via message. Messages are implemented as
procedure or function call .

• Operations supported by an object

• Means for manipulating the data of other

objects
Invoked by sending message
Examples: calculate_salary, issue-book,
member_details, etc. 8
 Object-oriented Concepts

Inheritance:

One class inherits the attributes and methods from another class.
• Allows to define a new class (derived class) by extending or modifying
existing class (base class)

• Represents Generalization-specialization relationship

• Allows redefinition of the existing methods ( method overriding)

9
 Object-oriented Concepts

–Multiple Inheritance:
• Subclass can inherit attributes and methods from more than one base
class

• Multiple inheritance is represented by arrows drawn from the subclass

to each of the base classes

10
 Object-oriented Concepts

LibraryMember Base Class LibraryMember Base Class

Derived
Faculty Students Staff Faculty Students Staff
Classes
Multiple
Inheritance

UnderGrad PostGrad Research UnderGrad PostGrad Research

11
 Object-oriented Concepts

Abstraction:
Used for handling complexity. It removes irrelevant data and shows
only essential data.

Note :(We have so many features in a system so rather than showing all the features, we only make
visible important features and remove the irrelevant data.)

• Consider aspects relevant for certain purpose

• Suppress non-relevant aspects
• Supported at two levels i.e. class
level where base class is
an abstraction & object level where object is a
data abstraction entity

12
 Cont…

Advantages of abstraction:
• Reduces complexity of software
• Increases software productivity

– It is shown that software

productivity is inversely
proportional to software complexity

13
 Object-oriented Concepts

Encapsulation:
It is the concept of information hiding.
e.g. Mobile app: (we never shows to the user about the
programming used for the application development)

It clubs essential information together and restricts access to the data

and method from outside world.

• Objects communicate outside world through messages

• Objects data encapsulated within its methods

14
 Object-oriented Concepts

Polymorphism: (One name with many forms)

Denotes to poly (many) morphism (forms).

e.g. Dog cat duck

speak(operation) (woof) (meow) (quack)
so, same operation may have diff. meaning in different situation

• Same message result in different actions by different

objects (static binding)
e.g. operation of addition
3+4=7
Rama + Krishna= Ramakrishna 15
 Cont…..

• Operator Overloading: The process of making operator to

exhibit different behaviour in different instances.

• Function Overloading: Using a single function name to

perform different type of task is known as function
overloading.

16
 Object-oriented Concepts

–Dynamic binding:
• In inheritance hierarchy, an object can be assigned to another object of its
ancestor class

• A method call to an ancestor object would result in the invocation of

appropriate method of object of the derived class

17
 Object-oriented Concepts

–Dynamic binding:
• Exact method cannot be known at compile time

• Dynamically decided at runtime

18
 Object-oriented Concepts

– Composite objects:
• Object containing other objects

19
 Advantages
of Object-oriented design

–Code and design reuse

–Increased productivity
–Ease of testing & maintenance
–Better understandability
–Its agreed that increased productivity is
chief advantage

20
 Advantages
of Object-oriented design

–Initially incur higher costs, but after

completion of some projects reduction in
cost become possible
–Well-established OO methodology and
environment can be managed with 20-
50% of traditional cost of development

21
 Object
modelling using UML

UML is a Unified modelling language

Note: Blueprint or model is important before creation of website/app
–Not a system design or development
methodology
–Used to document object-oriented analysis
and design
–Independent of any specific design
methodology

22
 UML Diagram

Dynamic Aspects Static

Aspects

23
 Structure Diagram: (static aspects)
• Focuses on static aspects of a system. (including its component
and their relationships).

• Describe the system’s architecture, entities and their properties

e.g. CAR
- component (engine, wheel, seat etc.)

- attribute(car color, size, engine power, seat material)

- relation (relation b/w component and attribute)

24
 Behavior Diagram
• Focus on dynamic aspects of a system. And describes the system’s
functionalities, interactions and state transitions.

• Describes how system responds and behaves in different scenarios.

• How user interact?

• What actions needs to be performed.
e.g. In case of CAR
Activities are: engine start, engine stop, Race, break.

25
26
 Why UML is required?

–Model is required to capture only important

aspects

–UML a graphical modelling tool, easy to

understand and construct

–Helps in managing complexity

27
 UML diagrams

–Nine diagrams to capture different views of a

system

–Provide different perspectives of the

software system

–Diagrams can be refined to get the actual

implementation of the system

28
 UML diagrams

Views of a system
• Structural view
• Behavioral view
• User’s view
• Implementation view
• Environmental view

29
 UML diagrams

Behavioural View
Structural View - Sequence Diagram
- Class Diagram - Collaboration Diagram
- Object Diagram
- State-chart Diagram
- Activity Diagram
User’s View
-Use Case
Diagram

Implementation View Environmental View

- Component Diagram - Deployment Diagram

Diagrams and views in UML

30
 UML User’s View: Use Case model

– In UML we are trying to design the system.

– Use Case diagram model the behavior of the system.

– Consists of set of “use cases”.

– Used to illustrate the functional requirements of the

system and its interaction with external agent(actors).

– A use case diagram gives us a high level view of the

system without going into the implementation details.
31
 Representation of Use Cases

use case diagram

–Use case is represented by ellipse

–System boundary is represented by rectangle

–Users are represented by stick person icon (actor)

–Communication relationship between actor and use

case by line

–External system by stereotype 32

 e.g. Book my show website

• Two functions: <<include>> and <<extend>>

• extend: It is the explicit function. Adding extra functionalities

to the system

• Include: It is a implicit function.

33
 Use Case diagram: Book my show

It gives us a high level view of what the system or a part of

the system does without going to the implementation detail

34
 Example of
Use Cases

Play Move

Player Tic-tac-toe game

Use case model

35
 Factoring Use Cases

– Complex use cases need to be factored into simpler use cases

– Represent common behavior across different use cases

Three ways of factoring

•Generalization
•Includes
•Extends

36
 Factoring Using
Generalization

Pay membership fee

Pay through credit card Pay through library pay card

Use case generalization

37
38
39
 Factoring Using
Includes

<<include>> Common
Base use case
use case

Use case inclusion

Base use case Base use case

<<include>>
<<include>>
<<include>> <<include>>

Base use case Base use case Base use case

Paralleling model 40
 Factoring Using
Extends

Base <<extends>> Common

use case use case

Use case extension

41
 Class diagram: Structure diagram

– Describes static structure of a system

– Main constituents are classes and their relationships:
• Generalization
• Association
Class name
• Aggregation, Composition

Class attribute

Class operations
42
Class and ObjecDaigram

43
Class and Object Diagram

44
Class and ObjecDaigram

45
 Class diagram

– Entities with common features, i.e. attributes and operations

– Classes are represented as solid outline rectangle with

compartments

– Compartments for class name, -attributes & operations

Three terms: (Access specifier)

+ public (attribute is accessible by all the classes)

- private (attribute is only accessible within the class)
# protected (attribute is accessible for same class as well as
inherited class) 46
 Cardinality
Class Diagram

has a

Current

47
Object Diagram

48
 Example of Class diagram

LibraryMember LibraryMember LibraryMember

Member Name Member Name

Membership Number Membership Number
Address Address
Phone Number Phone Number
E-Mail Address E-Mail Address
Membership Admission Date Membership Admission Date
Membership Expiry Date Membership Expiry Date
Books Issued Books Issued

issueBook( );
findPendingBooks( ); Compartments for class: name, -attributes & operations
findOverdueBooks( );
returnBook( );
findMembershipDetails( );

49
Different representations of the Library Member class
• These relationships, which we setup between classes.

• Association
• Dependency
• Aggregation
• Composition
• Generalization.

50
 Relation: Generalisation

• e.g.

Employee Student

Manager HR PG UG

So student is the general version of PG

and UG student.

51
 Relation : Association

Library Member
1 borrowed by * Book

Association between two classes

• Association are the semantic

connections between classes.
Association

Aggregation Composition
(has a relationship)
52
 Aggregation Relationship

– Represent a part of relationship

– Represented by diamond symbol at the composite end

– Cannot be reflexive(i.e. recursive)and Not symmetric.

– It can be transitive

53
 cont. ……..Aggregation Relationship

1 * 1
Document Paragraph * Line

Representation of aggregation

Note: Many paragraphs are the part of document

54
 Composition Relationship

e.g.
1 *
WhatsApp Whatsapp group

e.g.
1 *
Bank Branches

Representation of composition

55
56
 Class Dependency

Dependent Class Independent Class

Representation of dependence between class

57
Class Diagram: LMS

58
Cont.

59
Cont.

60
 Object diagram

LibraryMember LibraryMember LibraryMember

Mritunjay Mritunjay
B10028 B10028
C-108, Laksmikant Hall C-108, Laksmikant Hall
1119 1119
Mrituj@cse Mrituj@cse
25-02-04 25-02-04
25-03-06 25-03-06
NIL NIL

IssueBook( );
findPendingBooks( );
findOverdueBooks( );
returnBook( );
findMembershipDetails( );

Different representations of the LibraryMember object

61
 Interaction Diagram
– Models how groups of objects collaborate to realize some behaviour

– Typically each interaction diagram realizes behaviour of a single use

case

– Two kinds: Sequence & Collaboration

– Two diagrams are equivalent but portrays different perspective

– These diagram play a very important role in the design process

62
 Sequence Diagram: Behavioural Diagram
– Shows interaction among objects as two-dimensional chart

– Objects are shown as boxes at top

– If object created during execution then shown at appropriate place

– Objects request are shown with solid arrow line and responses are
shown with dotted arrow line.

– Objects existence are shown as dashed lines (lifeline)

– Objects activeness, shown as vertical rectangle on lifeline

63
Cont. Sequence Diagram

– Messages are shown as arrows

– Message labelled with message name

– Message can be labelled with control information

– Events are shown in timely order

64
 Menu
Cont. Sequence diagram: Restaurant System

65
Cont. Sequence diagram: Library System

66
67
 Time ordering matters

Collaboration diagram Message Interaction

– Shows both structural and behavioural aspects

– Objects are collaborator, shown as boxes

– Messages between objects shown as a solid line

– Message is shown as a labelled arrow placed near the

link

– Messages are prefixed with sequence numbers to

show relative sequencing

68
LMS: Collaboration Diagram

69
 Behavioural Diagram: Activity diagram

– It represents the flow of action.

– New concept, possibly based on event diagram of Odell [1992]

– Represent processing activity, may not correspond to methods

– Activity is a state with an internal action and one/many outgoing

transition

– Can represent parallel activity and synchronization aspects

– Swim lanes enable to group activities based on who is performing them

70
Activity diagram: ATM Transaction System

Start : Filled circle

Action : Rectangle with

rounded corner

Condition : Diamond shape

Arrow: Flow/ direction of

system

Fork: Occurrence of parallel

processes

Join: output of all concurrent

processes

End: filled circle with empty

circle.

71
Example of Activity diagram for student admission procedure

Academic Section Accounts Section Hostel Office Hospital Department

check
student
records
receive
fees

allot create
hostel hospital
record
register
receive
in
fees
course
conduct
allot medical
room examination

issue
identity card

72
Behavioural Diagram : State Chart diagram

– It defines the states, it is used to model the lifetime of the

object.

– Based on the work of David Harel [1990]

– Model how the state of an object changes in its lifetime

– Based on finite state machine (FSM) formalism

73
 Elements of state chart diagram

– Initial State: Filled circle

– Final State: Filled circle inside larger circle

– State: Rectangle with rounded corners

– Transitions: Arrow between states, also Boolean logic

condition (guard)

74
Order Management System: State Diagram

75
Cont. Order Management System

76
 Example of State Chart diagram

order received
Unprocessed
Order
[reject] checked [accept] checked

Rejected Accepted
Order Order
[some items available]
[some items not processed / deliver
available] processed

[all items
Pending available] Fulfilled
Order newsupply Order

Example: State chart diagram for an order object

77
 Design Patterns

– Standard solutions to commonly recurring problems

– Provides a good solution to model
– Pattern has four important parts
• The problem
• The context (problem)
• The solution
• The context (solution)

78
THANKS YOU

79
EXTRA EXAMPLES

80
 Example Pattern

• Expert
– Problem: Which class should be responsible for doing certain
things
– Solution: Assign responsibility to the class that has the
information necessary to fulfil the required responsibility

81
 Example Pattern

• Creator
– Problem: Which class should be responsible for creating a new
instance of some class?
– Solution: Assign a class C1 the responsibility to create class C2 if
• C1 is an aggregation of objects of type C2
• C1 contains object of type C2

82
 Example Pattern

• Controller
– Problem: Who should be responsible for handling the actor
requests?
– Solution: Separate controller object for each use case.

83
 Example Pattern

• Facade
– Problem: How should the services be requested from a service
package?
– Context (problem): A package (cohesive set of classes),
example: RDBMS interface package
– Solution: A class (DBfacade) can be created which provides a
common interface to the services of the package

84
Example 1: Tic-Tac-Toe Computer Game
• A human player and the computer make alternate
moves on a 3 3 square.
• A move consists of marking a previously
unmarked square.
• The user inputs a number between 1 and 9 to
mark a square
• Whoever is first to place three consecutive marks
along a straight line (i.e., along a row, column, or
diagonal) on the square wins.

85
Example 1: Tic-Tac-Toe Computer Game
• As soon as either of the human player or the
computer wins,
– a message announcing the winner should be displayed.
• If neither player manages to get three consecutive
marks along a straight line,
– and all the squares on the board are filled up,
– then the game is drawn.
• The computer always tries to win a game.

86
Example 1: Use Case Model

Play Move

Player Tic-tac-toe game

87
 Example 1: Sequence Diagram

:playMove :playMove
:board
Boundary Controller

acceptMove checkMoveValidity
move
[invalidMove] [invalidMove]
announceInvalidMove
announceInvalidMove
checkWinner
[game over]
[game over] announceResult
announceResult
playMove
checkWinner

[game over] [game over]

announceResult announceResult

displayBoardPositions getBoardPositions

[game not over]

promptNextMove

Sequence Diagram for the play move use case

88
 Example 1: Class Diagram

Board PlayMoveBoundary

int position[9]

checkMove Validity announceInvalidMove

checkResult announceResult
playMove displayBoard

Controller

announceInvalidMove
announceResult

89
Example 2: Supermarket Prize Scheme
• Supermarket needs to develop software to encourage
regular customers.
• Customer needs to supply his residence address,
telephone number, and the driving licence number.
• Each customer who registers is assigned a unique
customer number (CN) by the computer.

90
Example 2: Supermarket Prize Scheme
• A customer can present his CN to the staff when he makes
any purchase.
• The value of his purchase is credited against his CN.
• At the end of each year, the supermarket awards surprise
gifts to ten customers who make highest purchase.

91
Example 2: Supermarket Prize Scheme
• Also, it awards a 22 carat gold coin to every customer
whose purchases exceed Rs. 10,000.
• The entries against the CN are reset on the last day of
every year after the prize winner’s lists are generated.

92
 Example 2: Use Case Model

register
Customer customer Clerk

register
sales

Sales Clerk
select
winners

Supermarket
Prize scheme
Manager

93
 Example 2: Sequence Diagram for the Select
Winners Use Case

:SelectWinner :SelectWinner :Sales :Sales :Customer :Customer

Boundary Controller History Record Register Record

Select
SelectWinners
Winners
SelectWinners
*computeSales

*browse

[for each winner]

find WinnerDetails [for each winner]
announces
browse

Sequence Diagram for the select winners use case

94
 Example 2: Sequence Diagram for the
Register Customer Use Case

:SelectWinner :SelectWinner :Customer :Customer

Boundary Controller Register Record

register
register
checkDuplicate
*match

[duplicate]

showError
generateCIN

create
register :Customer
Record
displayCIN

Sequence Diagram for the register customer use case

95
 Example 2: Sequence Diagram for the Register
Sales Use Case

:Register :Register
:Sales
Sales Sales
History
Boundary Controller

RegisterSales registerSales
registerSales

create :Sales
Record

confirm
confirm

Sequence Diagram for the register sales use case

96
Example 2: Sequence Diagram for the Register
Sales Use Case

:Register
:Sales
Sales
History
Boundary

registerSales
RegisterSales

create :Sales
Record

confirm

Refined Sequence Diagram for the register sales use case

97
Example 1: Class Diagram

SalesHistory CustomerRegister

selectWinners findWinnerDetails
registerSales register

1 1

* *
SalesRecords CustomerRecord

salesDetails name
address
computerSales browse
browse checkDuplicate
create create

98
 Summary

• We discussed object-oriented concepts

– Basic mechanisms: Such as objects, class, methods,
inheritance etc.
– Key concepts: Such as abstraction, encapsulation,
polymorphism, composite objects etc.

99
 Summary

• We discussed an important OO language UML

– Its origin, as a standard, as a model
– Use case representation, its factorisation such as
generalization, includes and extends
– Different diagrams for UML representation
– In class diagram we discussed some relationships
association, aggregation, composition and
inheritance

100
 Summary

– Some more diagrams such as interaction diagrams

(sequence and collaboration), activity diagrams, state
chart diagram
• We discussed OO software development process and
patterns
– In this we discussed some patterns example and domain
modelling

101