EL

Object-Oriented Design using UML, Java and Patterns

PT
Rajib Mall
Professor, CSE Department
N IIT KHARAGPUR

1
• RAJIB MALL About The Instructor

• B.E. , M.E., Ph.D from Indian Institute of

Science, Bangalore

EL
• Worked with Motorola (India)

PT
• Shifted to IIT, Kharagpur in 1994
N
–Currently Professor

2
 Introduction
• Object-oriented design (OOD) techniques are now extremely
popular:

EL
–Inception in early 1980’s and nearing maturity.

PT
–Widespread acceptance in industry and academics.

–Unified Modelling Language (UML) became an ISO

N
standard (ISO/IEC 19501) in 2004.

3
 Motivation
• Many learners start object-oriented programming by
learning Java, C++, etc.
• With this they write woefully bad programs

EL
• Often they write OO programs by intuitively extending
procedural program design approaches.

PT
• In this course, we discuss some essential concepts
and techniques: N
– Should help develop good OO application code.

4
 Course Plan
• UML (Unified Modelling Language)
Assumption: You
• Object-oriented design process are familiar with

EL
basic Java or C++

PT
• Arriving at better designs using programming.
design patterns
N
5
Some Basics reference- Schematic
books Object-Oriented
Solution for LIS

EL
PT
members
N issue-
register books
• A system is designed as a set of interacting objects. Objects
• Objects are often real-world entities:
• Examples: an employee, a book etc.
– Can also be conceptual objects :

EL
• Controller, manager, etc.

PT
• An object consists of data (attributes) and functions
(methods) that operate on data.
– Encapsulation.
N
 Object Modelling Using UML
UML is aLearning
• Caution: modelling language.
UML can make you no more an
expert OO design
• Not a system designer, than methodology
or development learning English
• alphabet and grammar can make youanalysis
an expert

EL
Used to document object-oriented and
story
design writer…
results.

PT
• For designing, need to learn
Independent of any specific design
N
object-oriented design methodology,
methodology.
patterns…

8
 UML Origin
• OOD in late 1980s and early 1990s:
− Different software development houses were

EL
using different notations.
− Methodologies were tied to notations.

PT
• UML developed in early 1990s:
− N
To standardize the large number of object-
oriented modelling notations that existed.

9
 UML Lineology
• Based Principally on:
− OMT [Rumbaugh 1991]

EL
− Booch’s methodology[Booch 1991]
OOSE [Jacobson 1992]

PT
−

− Odell’s methodology[Odell 1992]

−
N
Shlaer and Mellor [Shlaer 1992]

10
 Different Object
OMT Modelling
Techniques in
UML

EL
UML

PT
Booch’s
OOSE
Methodology
N
11
 UML as A Standard
• Adopted by Object Management Group (OMG) in 1997.
• OMG is an association of industries

EL
• Promotes consensus notations and techniques

PT
• UML also being used outside software
development area:
− Example
N
Build-to-order manufacturing

12
History of UML UML 2.0
Industrialization

Standardization
UML 1.1

public

EL
feedback UML
UML 0.9
0.9 && 0.91
0.91 Unification

PT
Unified method 0.8

Other methods
N
Booch'93

Booch'91
OMT-2

OMT-1 OOSE
Fragmentation

13
 Developments to UML
• UML continues to UML 2.0 2003
develop, due to: Application
to embedded

EL
– Refinements systems
UML 1.X
– Making it applicable to

PT
new contexts
N UML 1.0 1997

14
 Why are UML Models Required?
Modelling is an abstraction mechanism:
− Capture only important aspects and ignores the rest.

EL
− Different models obtained when different aspects are
ignored.

PT
− An effective mechanism to handle complexity.
N
UML is a graphical modelling technique
Easy to understand and construct
15
 Modelling vs. Designing
• Is Modelling the same as designing?
• A design is a model of the system.
– But, every model is not a design of the system.

EL
• From the requirements, an analysis model is created.

PT
(Analysis activity).
N
• Subsequently, the analysis model is
refined into the design model.
16
 UML Diagrams
Nine diagrams in UML 1.x :
− Used to capture 5 different views of a system.

EL
Views:

PT
− Provide different perspectives of a software system.
Diagrams can be refined to get the
N
actual implementation of a system.

17
Views of a system: UML Model
− User’s view Views

EL
− Structural view
− Behavioral

PT
view
− Implementation view
− Environmental
N view

18
 Diagrams
Behavioural View
- Sequence Diagram
and views
Structural View
- Class Diagram
- Collaboration Diagram
- State-chart Diagram
in UML
- Object Diagram - Activity Diagram

EL
User’s View
-Use Case
Diagram

PT
Implementation View
- Component Diagram Environmental View
- Deployment Diagram

N
19
• Class Diagram
– set of classes and their relationships.
Structural
Diagrams
• Object Diagram
– set of objects (class instances) and their relationships

EL
• Component Diagram

PT
– logical groupings of elements and their relationships
• Deployment Diagram
N
– set of computational resources (nodes) that host
each component.

20
• Use Case Diagram
– high-level behaviors of the system, user Behavioral
goals, external entities: actors
• Sequence Diagram Diagrams
– focus on time ordering of messages

EL
• Collaboration Diagram
– focus on structural organization of objects

PT
and messages
• State Chart Diagram
– event driven state changes of system
• Activity Diagram N
– flow of control between activities

21
• “UML is a large and growing beast, but you Some
don’t need all of it in every problem you Insights on
Using UML
solve…” Martin Fowler

EL
• “…when learning the UML, you need to be
aware that certain constructs and notations

PT
are only helpful in detailed design while
N
others are useful in requirements analysis …”
Brian Henderson-Sellers

22
NO Are All Views Required for
Developing A Typical System?
For a simple system:
− Use case diagram, class diagram and one of the
interaction diagrams only.

EL
State chart diagram:
− When class has significant states.

PT
− When states are only one or two, state chart
model becomes trivial.
Deployment diagram:
−
N
When system has many hardware components.

23
 EL
Use Case Modelling

PT
N
24
6/23/2020
 Use Case Model Behavioural View
Structural View - Sequence Diagram

• Consists of a set of “use cases” - Class Diagram

- Object Diagram
- Collaboration Diagram
-State-chart Diagram
- Activity Diagram
User’s View
-Use Case
Diagram

• It is the central model: Implementation View Environmental View

EL
- Component Diagram - Deployment Diagram

–Other models must conform to this model

PT
–Not really an object-oriented model,
N
it is a functional model of a system

25
• A case of use: A way in which a system can be
used by the users to achieve specific goals A Use Case
• Corresponds to a high-level requirement.

EL
• Defines external behavior without revealing

PT
internal structure of system

N
• Set of related scenarios tied together by a
common goal.

26
–Use cases for a Library information system
•issue-book Example
•query-book Use Cases

EL
•return-book

PT
•create-member
•add-book, etc.N
27
• Use cases appear independent of each other
• However, Implicit dependencies may exist Are All Use
Cases
• Example: In Library Automation System, Independent?

EL
renew-book and reserve-book are
independent use cases.

PT
–But in actual implementation of renew-book--- A
N
check is made to see if any book has been
reserved using reserve-book.

28
 First Example: Use Case Diagram

EL
Play Move

PT
Tic-tac-toe game
Player

NUse case model

29
• Serves as requirements specification. Why Develop A
• How identifying actors helps in software Use Case Diagram?
development?

EL
–Identifies different categories of users:
• Helps in implementing appropriate

PT
interfaces for each category of users.

N
• Helps in preparing appropriate documents
(e.g. users’ manual).

30
• Represented in a use case diagram Representation of
• A use case is represented by an ellipse Use Cases
• System boundary is represented by a rectangle

EL
• Users are represented by stick person Backup

icons (actor) Play Move <<external

PT
system>>
Tic-tac-toe game
Player
• Communication relationship
N
between actor and use case by a line
• External system by adding a stereotype
31
 What is a Connection?
• A connection is an association
between an actor and a use case. Play Move

EL
• Depicts a usage relationship Tic-tac-toe game

PT
• Connection does not indicate
data flow… N
32
 Relationships between Use Cases and Actors
• Association relation indicates that the actor and the
corresponding use case communicate with one another.

EL
PT
update
grades

N faculty

33
 Another Example Use Case Diagram

Video Store Information

System

EL
Rent
Videos

PT
Clerk <<external system>>
Credit Authorization
. . . Service

N
34
 Yet Another Use
Telephone Order System
Case Example
Check
Status Salesperson

Place

EL
Order

PT
Fill
Shipping
Orders
Customer Clerk

N
Establish
credit

Supervisor

35
 Factoring Use Cases
• Two main reasons for factoring:
–Complex use cases need to be factored into simpler use cases
–Helps represent common behavior across different use cases

EL
• Three ways of factoring:

PT
–Generalization
–Include
–Extend
N
36
 Generalization
• The child use case inherits the parent

behavior of the parent use case.

EL
child
–The child may add to or override some

PT
of the behavior of its parent.
N
37
 Registration
Generalization:
Example 1

EL
PT
Under-graduate Graduate
registration
N registration

38
 Generalization: Example 2

Pay membership fee

EL
PT
Pay through credit card
N Pay through library pay card

39
 <<include>> Common Factoring Use
Base use case
use case Cases Using
Include

Base use case 2 Base use case 1

EL
PT
<<include>>
<<include>>
<<include>>
<<include>>

N
Common use case 1 Common use case 2 Common use case 3

41
 Factoring Use Cases
Issue Book Renew Book Using Include:
Example

EL
<<include>>
<<include>>

PT
N
Check Reservation

42
Factoring A Use Case Using Extend:
Example

EL
Order <<extend>> Show

PT
Item Catalog

N
44
 Extension Point
• The base use case may include/extend other use cases:
– At certain points during execution, called extension points.

EL
• Note the direction of the arrow

PT
Perform Sale
After checkout N
<<extend>>
Gift wrap
Product

45
 Order
Supply Product
Customer Data Arrange
Payment
<<include>>
<<include>>
<<include>>
Place Order

EL
Cash Credit
Payment Payment
Sales Person

PT
<<extend>>

Use Case Relationships N Request

Catalog

46
• Video Store Information System supports the following
business functions: Example 1: Video Store Information System
– Entering the information about all videos that the store owns
• This database is searchable by staff and all customers

EL
– Store information about a customer’s borrowed videos
• Access by staff and customer. It involves video database searching.

PT
– Staff can record video rentals and returns by customers.
It involves video database searching.
N
– Staff can maintain customer and video information.
– Store Manager can generate various reports.

47
 Video Store Information System

Rent/Return
Example 1:
Videos Solution
«include»

Staff
Search for Customer

EL
Videos
Maintain
Customers
«include»

PT
Maintain
Videos

Manager
Generate
Reports
N
48
Name Use Case
Actors
Description
Trigger
Alistair Cockburn
Preconditions “Writing

EL
Effective Use
Post conditions Cases”

PT
Mainline Scenario

N
Alternatives flows

49
 Start use case Use Case
Scenarios
Alternative flow 3 Alternative flow 1

EL
Alternative flow 2

Alternative flow 4

PT
end use case

N
end use case

end use case

50
• Actors: Customer
ATM Money Withdraw Example
• Pre Condition:
– ATM must be in a state ready to accept transactions
– ATM must have at least some cash it can dispense

EL
– ATM must have enough paper to print a receipt
• Post Condition:

PT
– The current amount of cash in the user account is the

N
amount before withdraw minus withdraw amount
– A receipt was printed on the withdraw amount

51
 Actor Actions System Actions
1. Begins when a Customer arrives
at ATM
2. Customer inserts a Credit card 3. System verifies the customer ID
ATM Money
into ATM and status Withdraw
5. Customer chooses “Withdraw” 4. System asks for an operation
operation type Mainline

EL
7. Customer enters the cash
amount
6. System asks for the withdraw
amount
Scenario
8. System checks if withdraw
amount is legal

PT
9. System dispenses the cash
10. System deduces the withdraw

13. Customer takes the cash and

N amount from account

11. System prints a receipt

12. System ejects the cash card
the receipt
• Alternative flow of events: ATM Money Withdraw (cont.)
– Step 3: Customer authorization failed. Display an error
message, cancel the transaction and eject the card.
– Step 8: Customer has insufficient funds in its account.

EL
Display an error message, and go to step 6.
– Step 8: Customer exceeds its legal amount. Display an error

PT
message, and go to step 6.
• Exceptional flow of events:
N
– Power failure in the process of the transaction before step
9, cancel the transaction and eject the card.

53
 Actors: traveler Use Case Description: Change Flight
 Preconditions:
• Traveler has logged on to the system and selected ‘change flight itinerary’
option
 Basic course
1. System retrieves traveler’s account and flight itinerary from client account

EL
database
2. System asks traveler to select itinerary segment she wants to change; traveler
selects itinerary segment.

PT
3. System asks traveler for new departure and destination information; traveler
provides information.
4. If flights are available then


5.
6.
…
N
System displays transaction summary.
Alternative courses
4. If no flights are available then …

54
 Guidelines for Effective Use Case Writing System Actor

• Use simple sentence

Actor asks for money

System asks for amount

• Do not have both system and actor Actor gives the amount

EL
doing something in a single step
System produce the money

PT
– Bad: “Get the amount from the user and give him the receipt.”

N
• Any step should lead to some tangible progress:
– Bad: “User clicks a mouse key”

55
1. Actor-based: Identification of Use Cases

- Identify the actors.

- For each actor, identify the use cases they initiate or

EL
participate in.
2. Event-based

PT
- Identify the external events that the system must
respond to. N
- Relate the events to actors and use cases.

56
 Example 2: Use Case Model for Course Management Software
• At the beginning of each semester,
– Each professor shall register the courses that he is going to teach.
• A student can select up to four-course offerings.
– During registration a student can request a course catalogue
showing course offerings for the semester.

EL
– Information about each course such as professor, department
and prerequisites would be displayed.

PT
– The registration system sends information to the billing system,
so that the students can be billed for the semester.
• For each semester, there is a certain period of time during

•
N
which dropping of courses is permitted.
Professors must be able to access the system to see which
students signed up for each of their course offerings.

57
 Course Management Software

Register Example 2:
Course
offering
See
Model Solution
Course
Professor Show List

EL
registration
<<Extend>>

<<External>>
Register

PT
Billing System
course
Student

N
Drop
Course

Calendar

58