Object-Oriented Software Design

2
 • Basic Mechanisms:
• Objects:
• A real-world entity.
Object- • A system is designed as a set of interacting objects.
oriented • Consists of data (attributes) and functions (methods)
that operate on data
Concepts • Hides organization of internal information (Data
abstraction)
• Examples: an employee, a book etc.

3
 m8 m7
mi are methods
of the object
Object-oriented Concepts

m1 m6
Data
m2 m5

Object

m3 m4
Model of an object

4
 • Class:
• Instances are objects
• Template for object creation
Object- • Examples: set of all employees,
oriented different types of book

Concepts

5
Object-oriented Concepts

• Methods and message:

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

6
Object-oriented Concepts
• Inheritance:
• 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)

7
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

8
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

9
Object-oriented
Concepts

• Key Concepts:
• Abstraction:
• 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

10
Object-oriented
Concepts

• Advantages of abstraction:
• Reduces complexity of
software
• Increases software
productivity
• It is shown that software
productivity is inversely
proportional to software
complexity
11
Object-oriented
Concepts

• Encapsulation:
• Objects communicate
outside world through
messages
• Objects data
encapsulated within its
methods

12
Object-oriented
Concepts

• Polymorphism:
• Denotes to poly (many)
morphism (forms)
• Same message result in different
actions by different objects
(static binding)

13
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

14
 • Dynamic binding:
• Exact method cannot
be known at compile
Object-oriented time
Concepts
• Dynamically decided
at runtime

15
Object-oriented
Concepts

• Composite objects:
• Object containing other objects

16
 Code and design Increased
reuse productivity

Advantages
Ease of testing & Better
of Object- maintenance understandability
oriented design
Its agreed that
increased
productivity is
chief advantage
17
Advantages
of Object-oriented design

Well-established OO
Initially incur higher costs, methodology and
but after completion of environment can be
some projects reduction in managed with 20-50% of
cost become possible traditional cost of
development

18
Object
modelling using UML

UML is a modelling language

Not a system design or

development methodology
Used to document object-
oriented analysis and design
Independent of any specific
design methodology
19
 Model is required to capture only
important aspects
Why UML is UML a graphical modelling tool,
required? easy to understand and construct

Helps in managing complexity

20
 Nine diagrams to capture different
views of a system

Provide different perspectives of the

UML diagrams software system

Diagrams can be refined to get the

actual implementation of the system

22
UML diagrams

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

23
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

24
Use Case model
Consists of set of “use cases”

An important analysis and design artifact

Other models must confirm to this model

Not really an object-oriented model

Represents a functional or process model

25
Representation of Use Cases
• Represented by 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

26
Example of
Use Cases

Play Move

Player
Tic-tac-toe game

Use case model

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

Represent common behavior across

Factoring different use cases
Use Cases
Three ways of factoring

• Generalization
• Includes
• Extends

29
 Factoring Using Generalization

Pay membership fee

Pay through credit card Pay through library pay card

Use case generalization

30
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 31
Factoring Using Extends

Base <<extends>> Common

use case use case

Use case extension

32
Class diagram

Describes static structure of a system

Main constituents are classes and their relationships:

• Generalization
• Aggregation, Composition
• Association
• Various kinds of dependencies

33
Class diagram
Entities with common features, i.e. attributes and
operations

Classes are represented as solid outline rectangle with

compartments

Compartments for name, attributes & operations

Attribute and operation compartment are optional for

reuse purpose

34
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( );
findOverdueBooks( );
returnBook( );
findMembershipDetails( );

Different representations of the LibraryMember class

35
Symbol meaning
• 1: This symbol typically denotes a multiplicity of one. In other words,
one instance of the class on the left-hand side can be associated with
exactly one instance of the class on the right-hand side.

• *: This symbol typically denotes a multiplicity of many. In other

words, one instance of the class on the left-hand side can be
associated with zero or more instances of the class on the right-hand
side.
 Association Relationship
1 borrowed by * Book
Library Member

Association between two classes

LibraryMember can borrow one or more Book s

a Book can also be associated with the LibraryMember that borrowed it.

there is no limit on the number of Books that a LibraryMember can borrow.

38
Aggregation Relationship
• Represent a whole-part relationship
• Represented by diamond symbol at the composite
end
• Cannot be reflexive(i.e. recursive)
• Not symmetric
• It can be transitive
• where one class (the whole) is composed of one or
more instances of another class (the part)
• For example, a car is composed of wheels, an engine,
and other parts.

39
Aggregation Relationship

1 * 1
Document Paragraph * Line

Representation of aggregation

40
Composition relationship
• The "whole" class (owner) cannot exist without its "part" class
(member). The part is essentially an integral component of the whole
and doesn't have a meaningful existence outside of it.

• The lifecycle of the part is dependent on the whole. When the whole
object is destroyed, so are its associated part objects.
Important points to remember:
• Composition is a stronger form of aggregation, where the part has
even more dependency on the whole.
• The part cannot be shared by multiple "whole" objects.
• Deleting the whole object automatically deletes its associated part
object(s).
Composition Relationship
• Life of item is same as the order

1 *
Order Item

Representation of composition

43
Class Dependency

Dependent Class Independent Class

Representation of dependence between class

44
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

45
Interaction diagram

Models how groups Typically each

of objects interaction diagram
collaborate to realize realizes behaviour of
some behaviour a single use case

46
Interaction diagram

Two kinds: Sequence & Collaboration

Two diagrams are equivalent but portrays different

perspective

These diagram play a very important role in the design

process
47
Sequence 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 existence are shown as dashed lines
(lifeline)
• Objects activeness, shown as rectangle on
lifeline

48
Sequence diagram
• Messages are shown as arrows
• Message labelled with message name
• Message can be labelled with control
information
• Two types of control information: condition ([])
& an iteration (*)

49
Example of
Sequence diagram
:Library
:Library
:Library Book :Library
Book :Book
Boundary Renewal Member
Register
Controller

1. renewBook find MemberBorrowing

displayBorrowing
selectBooks bookSelected
* find
[reserved]
[reserved] apology
update
apology

confirm

confirm
updateMemberBorrowing

Sequence Diagram for the renew book use case

51
Example of
Sequence diagram
:Library
:Library
:Library Book :Library
Book :Book
Boundary Renewal Member
Register
Controller

1. renewBook 2. find MemberBorrowing

3.displayBorrowing
4. selectBooks 5. bookSelected
6. * find
7. [reserved]
7.1 [reserved] apology
8. update
apology

9. confirm

11. confirm
10. updateMemberBorrowing

Sequence Diagram for the renew book use case

52
Collaboration diagram
• 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

53
Example of
Collaboration diagram
6: * find
:Library
Book :Book
[reserved] Register
9: update
8: apology 5: book 10: confirm
Selected
1: renewBook :Library [reserved]
:Library Book 7: apology
Boundary 3: display Renewal
Borrowing Controller

4: selectBooks
2: findMemberBorrowing

12: confirm
:Library
Member

updateMemberBorrowing

Collaboration Diagram for the renew book use case

54
Activity diagram
• 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

55
Activity diagram
• Can represent parallel activity and synchronization
aspects

• Swim lanes enable to group activities based on who

is performing them

• Example: academic department vs. hostel

56
Activity diagram
• Normally employed in business process modelling

• Carried out during requirement analysis and specification

• Can be used to develop interaction diagrams

57
Example of
Activity diagram
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
Activity diagram for student admission procedure at IIT
58
State Chart diagram
• 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

59
State Chart diagram
• 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)

60
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

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

62
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

63
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

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

65
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

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

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

68
Example 1: Use
Case Model
Play Move

Player
Tic-tac-toe game

69
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

70
Example 1: Class Diagram

Board PlayMoveBoundary

int position[9]

checkMove Validity announceInvalidMove

checkResult announceResult
playMove displayBoard

Controller

announceInvalidMove
announceResult

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

72
Example 2: Supermarket Prize Scheme
• A customer can present his CN (Customer Number) 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.

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

74
Example 2: Use Case Model

register
Customer customer Clerk

register
sales

Sales Clerk
select
winners

Supermarket
Prize scheme
Manager

75
 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

76
 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

77
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

78
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

79
Example 1: Class Diagram

SalesHistory CustomerRegister

selectWinners findWinnerDetails
registerSales register

1 1

* *
SalesRecords CustomerRecord

salesDetails name
address
computerSales browse
browse checkDuplicate
create create

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

81
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

82
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

83