CS8592

OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT II - STATIC UML DIAGRAMS

Class Diagram - Elaboration - Domain Model -
Finding conceptual classes and description classes -
Associations - Attributes - Domain model refinement
- Finding conceptual class Hierarchies - Aggregation
and Composition - Relationship between sequence
diagrams and use cases – When to use Class
Diagrams.
Class Diagrams
⚫ A Class is a Description of Set of Objects
that Share the Same Attributes,
Operations, Methods, Relationships, and
Semantics
⚫ Classes are Graphically Represented as

Boxes with Compartments for

⚫ Class Name, Private Attributes, and
Public Operations

2
Class Diagram (Rumbaugh/Booch)
⚫ Class Diagram Describes
– Types of Objects in Application
– Static Relationships Among Objects
– Temporal Information Not Supported
⚫ Class Diagrams Contain
– Classes: Objects, Attributes, and Operations
– Packages: Groupings of Classes
– Subsystems: Grouping of Classes/Packages
⚫ Main Concepts: Class, Association,
Generalization, Dependency, Realization,
Interface 3
Classes
TariffSchedule
Table zone2price
Enumeration getZones()
Name
Price getPrice(Zone)
TariffSchedule
zone2price Attributes
getZones()
Signature
getPrice()
Operations TariffSchedule

A class represent a concept

A class encapsulates state (attributes) and behavior
(operations).
Each attribute has a type.
Each operation has a signature.
The class name is the only mandatory information.
4
UML Class Notation
A class is a rectangle divided into three parts
– Class name
– Class attributes (i.e. data members, variables)
– Class operations (i.e. methods)
Employee
Modifiers
-Name : string
– Private: - +ID : long
#Salary : double

– Public: + +getName() : string

+setName()

– Protected: # -calcInternalStuff(in x : byte, in y : decimal)

– Static: Underlined (i.e. shared among all members of the class)

Abstract class: Name in italics

• An abstract class has one or more
abstract/pure virtual functions.
• An abstract class cannot be used to instantiate
objects.
• An abstract class can contain data members. 5
 UML Class Notation
Lines or arrows between classes indicate relationships
– Association
• A relationship between instances of two classes, where one class
must know about the other to do its work, e.g. client communicates to
server
• indicated by a straight line or arrow
– Aggregation
• An association where one class belongs to a collection, e.g. instructor
part of Faculty
• Indicated by an empty diamond on the side of the collection
– Composition
• Strong form of Aggregation
• Lifetime control; components cannot exist without the aggregate
• Indicated by a solid diamond on the side of the collection
– Inheritance
• An inheritance link indicating one class a superclass relationship, e.g.
bird is part of mammal
• Indicated by triangle pointing to superclass
6
Binary Association

Binary Association: Both entities “Know About” each other

myB.service(); myA.doSomething();

Optionally, may create an Associate Class

7
Unary Association

A knows about B, but B knows nothing about A

myB.service(); Arrow points in direction

of the dependency

8
 Aggregation

Aggregation is an association with a “collection-member” relationship

void doSomething() Hollow diamond on

aModule.service(); the Collection side

9
 Composition
Composition is Aggregation with:
Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object

Employee
Team
-Name : string
-members : Employee +ID : long
1 #Salary : double
-adfaf : bool
*
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
members[0] =
new Employee();
… Filled diamond on
delete members[0]; side of the Collection

10
Inheritance
Standard concept of inheritance

Base Class

Derived Class

class B() extends A

…

11
Generalization and Associations
*
Item
GroceryOrder

1
Customer NonPItem PerishItem

DeliItem DiaryItem ProduceItem

*
1 contains
DeliOrder

Supermarket example 12
 UML Multiplicities

Links on associations to specify more details about the relationship

Multiplicities Meaning
zero or one instance. The notation n . . M
0..1
indicates n to m instances.
no limit on the number of instances
0..* or *
(including none).
1 exactly one instance
1..* at least one instance

13
UML Class Example

14
Supermarket Example in Detail

15
Elaboration
Objectives
⚫ Elaboration is the initial series of
iterations during which the team does the
following
⚫ Serious investigation
⚫ Discover & stabilize major requirements

⚫ Mitigate/retire risks ( business value )

⚫ Build core architecture elements

⚫ Estimate overall schedule and resources

⚫ Establish a supporting environment

16
Elaboration - Key Ideas

⚫ Not a waterfall model !

⚫ Two to six weeks for each iteration
⚫ Timeboxed iterations (deadlines should
be strictly maintained)
⚫ Each iteration products ends in a stable
and tested release

17
Best Practices

⚫ Start programming early

⚫ Adapt based on feedback from tests,
users, developers
⚫ Design, implement and test adaptively
⚫ Test early and realistically
⚫ Requirements and use case details
through series of workshops (once per
iteration)

18
 Artifacts starting in Elaboration (this will not
be completed rather refined over iterations)

⚫ Domain Model (conceptual class diagram)

⚫ Design Model
(logical design: class diagram, object oriented diagram, etc.)
⚫ Software Architecture Document
(summary of ideas and motivations)
⚫ Data Model (database schemas..)
⚫ Test Model
⚫ Implementation Model (source code, databases and so on. )
⚫ Use-Case Storyboards and UI Prototypes (description of
user interfaces, navigations etc.

19
You didn’t Understand Elaboration When …

⚫ No Timeboxed schedule
⚫ Single Iteration
⚫ Most requirements already defined
⚫ No Risk mitigation/resolution
⚫ No Executable Architecture
⚫ Requirements Phase
⚫ Attempt full and careful design

20
You didn’t Understand Elaboration When (2)...

⚫ Minimal feedback and adaptation

⚫ No early and realistic testing
⚫ Frozen Architecture
⚫ No Proof-of-concept programming
⚫ No multiple requirements workshops

21
 Domain Model Relationships

Business Model
Domain Model
Classes, attributes, associations

Elaboration on some terms

Domain
objects
Use Case Model Glossary

Requirements

Interaction Diagrams
Design

22
A Domain Model

⚫ illustrates meaningful conceptual classes in a problem

domain.
⚫ is a representation of real-world concepts, not software
components.
⚫ is NOT a set of diagrams describing software classes, or
software objects and their responsibilities.
⚫ It may show:
▪ concepts
▪ associations between concepts
▪ attributes of concepts

23
Domain Model - UML Notation

⚫ Illustrated using a set of class diagrams for which no operations

are defined.
▪A Domain Model is a description of
things in the real world.
▪A Domain Model is not a description
of the software design.
▪A concept is an idea, thing, or object.

24
A Domain Model is not a Software Artifact

A Conceptual class Software Artifacts

Sale Sales Database

Date vs. Sale

Time
Date
Time
Print()

25
Identify Conceptual Classes by Noun Phrase:

⚫ Identify Nouns and Noun Phrases in

textual descriptions of the domain.
⚫ Fully dressed Use Cases are good for this
type of linguistic analysis.
It’s not strictly a mechanical process:
⚫ Words may be ambiguous
⚫ Different phrases may represent the same
concepts.
26
Steps to create a Domain Model

⚫ Identify Candidate Conceptual classes

⚫ Draw them in a Domain Model
⚫ Add associations necessary to record the
relationships that must be retained
⚫ Add attributes necessary for information
to be preserved
⚫ Apply existing Analysis Patterns

27
Apply the Mapmaker Strategy

⚫ Use existing names for things, the

vocabulary of the domain
⚫ Exclude irrelevant features
⚫ Do not add things that are not there

28
A Common Mistake -
Classes as Attributes

⚫ Rule: If we do not think of a thing as a

number or text in the real world, then it is
probably a conceptual class.
⚫ If it takes up space, then it is likely a
conceptual class.
Examples:
⚫ A Store is not an attribute of a Sale
⚫ A Destination is not an attribute of a flight
29
Specification or Description
Conceptual Classes

⚫ A Class that records information about an

item.
⚫ Even if all Instances of the item are sold
out, the description remains.
⚫ Avoids duplication of recording the
descriptive information with each instance
of the item.

30
Description of a Service Example (Flight)

Flight
Date Airport
Flies-to
Time Name
Number vs.

Flight Flight Desc Airport

Date Described Date Describes
Name
-by -flights-to
Time Time

31
The NextGen POS (partial) Domain Model

32
Associations

An association is a relationship between

instances of types that indicates some
meaningful and interesting connection

33
Introduction

⚫ Identify associations of conceptual classes

needed to satisfy the information
requirements of current scenarios.
⚫ Also identify the aid in comprehending the
domain model.

34
Associations

association

Records-current
Register Sale
1 1

Fig 1.Associations

35
Useful Associations

⚫ Associations for which knowledge of the

relationship needs to be preserved for
some duration.
⚫ Associations derived from the Common
Associations List.

36
UML Association Notation

⚫ An association is represented as a line

between classes with an association
name.
⚫ Associations are inherently bidirectional.
⚫ Optional reading direction arrow is only an
aid to the reader of the diagram.

37
UML Association Notation
- “reading direction arrow”
- it has no meaning except to
indicate direction of reading the
association label
- often excluded

Records-current
Register Sale
1 1

association name multiplicity

38
Finding Associations-Common
Associations List

The common categories that are worth

considering are:
⚫ A is a physical part of B . Eg: Wing-Airplane
⚫ A is a logical part of B. Eg: SalesLineItem-
Sale.
⚫ A is physically contained in B . Eg: Register-
Store.

39
Common Associations List 2

⚫ A is logically contained in B.
Eg:ItemDescription-Catalog.
⚫ A is a description of B. Eg:ItemDescription-
Item.
⚫ A is a line item of a transaction or report B.
Eg:SalesLineItem-Sale.
⚫ A is a member of B. Eg: Cashier-Store.
⚫ A uses or manages B. Eg:Cashier-Register.

40
Common Associations List 3

⚫ A is known/logged/recorded/reported/captured in
B. Eg: Sale-Register.
⚫ A is an organizational subunit of B .
Eg:Department-Store.
⚫ A communicates with B. Eg:Customer-Cashier.
⚫ A is next to B. Eg:City-City.

41
Common Associations List 4

⚫ A is related to a transaction B. Eg:

Customer-Payment.
⚫ A is a transaction related to another
transaction B. Eg:Payment-Sale.
⚫ A is next to B. Eg:City-City.
⚫ A is owned by B. Eg:Register-Store.
⚫ A is an event related to B. Eg:Sale-Customer.

42
High-Priority Associations

⚫ A is a physical or logical part of B.

⚫ A is physically or logically contained in/on B.
⚫ A is recorded in B.

43
Associations Guidelines

⚫ The knowledge of the relationship needs

to be preserved for some duration.
⚫ Identifying conceptual classes is more
important than identifying associations.
⚫ Avoid showing redundant or derivable
associations.

44
Roles

⚫ Each end of an association is called a role.

⚫ Roles may have
⚫ name

⚫ multiplicity expression

⚫ navigability

45
Multiplicity
⚫ Multiplicity defines the number of
instances of a class A, that can be
associated with one instance of class B, at
a particular moment.

⚫ Eg: In countries with monogamy laws, a person

can be married to 1 person at any particular
time. But over a span of time one person can be
married to many persons.

46
Multiplicity

Stocks
Store Item
1 *

multiplicity of the
role

Fig 3 Multiplicity on an association.

47
Multiplicity
*
T zero or more;
“many”

1..*
T one or more;

1..40
T one to 40

5
T exactly 5

3,5,8
T exactly 3,5 or 8

48
Fig 4. Multiplicity values.
Naming Associations

⚫ Name an association based on

TypeName-VerbPhrase-TypeName format.
⚫ Names should start with a capital letter.
⚫ Legal formats are:
⚫ Paid-by
⚫ PaidBy

49
Associations Names
Store

1
Contains
1..*
Register Captures Sale Paid-by Payment
1 1..* 1 1

Airline

1
Employs
1..*
Person Assigned-to Flight Assigned-to Plane
1 * * 1
1 *

Supervises

Fig 5.Association names. 50

Multiple Associations
• Two types may have multiple associations
between them.
Flies-to
* 1
Flight Airport
* Flies-from 1

Fig 6. Multiple associations.

51
Implementation

⚫ The domain model can be updated to

reflect the newly discovered associations.
⚫ But,avoid updating any documentation or
model unless there is a concrete
justification for future use.
⚫ Defer design considerations so that
extraneous information is not included and
maximizing design options later on.
52
ATTRIBUTES

⚫ After establishing classes based on the

concepts of use case scenarios, the scenarios
are examined to discover attributes
⚫ Attributes are logical data values of an object

53
UML Attribute Notation

SALE Attributes

Date: startTime: Time

54
Valid Attribute Types

⚫ Keep attributes simple

⚫ Distinguish between conceptual and
implementation perspectives
⚫ Identify data types

55
Relate with associations, not attributes

NOT A “SIMPLE”
ATTRIBUTE

CASHIER
Worse
Worse

NAME :
current register

Better CASHIER 1 USES 1

REGISTER
Better
NAME
Number

56
Avoid Representing Complex Domain Concepts
as Attributes

DESTINATION IS A
COMPLEX CONCEPT

FLIGHT
Worse
Worse

DESTINATION

1 Flies 1
Better
Better Flight Airport

57
Non Primitive Data Type

Represent what may be considered a primitive

data type (such as a number or string) as a non
primitive class if:
⚫It is composed of separate sections.
• Eg: phone number, name of person
⚫There are operations usually associated with it,
such as parsing or validation.
• Eg: social security number
⚫It has other attributes
• promotional price could have a start date and end date

58
Non Primitive Data Type

⚫ It has a quantity with a unit

Eg: payment amount has a unit of currency
⚫ It has abstraction of one or more types with
some of these qualities.
Eg: item identifier in the sales domain is a
generalization of types such as Universal product
code(UPC) or European Article Number(EAN)

59
Non primitive data Types

Applying these guidelines to the POS domain

model yields the following analysis:
⚫The item identifier is an abstraction of various
common coding codes schemes, including
UPC-A, UPC-E, and the family of EAN
schemes.
⚫These numeric coding schemes have
subparts identifying the manufacturer, product
and EAN

60
Attribute box

If the attribute class is a data type, it may be shown in the attribute box

1 1
Product 1 1
ItemID Store Address
Specification

Product Specification Store

address:
Id: Item ID
Address

61
 No attributes as Foreign Key

A “simple” attribute but

being used as a foreign
key to relate to another
object.

Worse
Worse
CASHIER

Name:
currentRegisterNumber

Better
Better
1 USES 1 Register
CASHIER
number
NAME

62
Modelling Attribute Quantites and Units

Payment
Not useful
Amount:
Number

Payment Has amount Is in Unit

Quantity

* 1
Amount:Number * 1

Payment Quantities are pure data values,

so suitable to show in attribute
section

Amount:Quantity
better

Payment Variation: Money is a specialized

Quantity whose unit is a currency

Amount: Money

63
Domain Model Refinement
When to make generalization hierarchies?
Why is the following a good example?
superclass - more general
Payment concept

these are conceptual

classes, not software
Figure 31.1
classes
subclass - more
Cash Credit Check specialized concept
Payment Payment Payment

Guidelines:
• Identify superclasses and subclasses when they help us
understand concepts in more general, abstract terms
and reduce repeated information.
• Expand class hierarchy relevant to the current iteration
and show them in the Domain Model.
64
 100% and Is-a rules
Payment
Pays-for Sale
amount : Money 1 1

Cash Credit Check

Payment Payment Payment

100% rule: Subclasses must conform to 100% of superclass’s

attributes and associations.
Is-a rule (informal test): “Subclass is a Superclass”

65
 What about this hierarchy?

Customer Correct subclasses.

But useful?

Male Female
Fig. 31.6
Customer Customer

Guidelines for creating conceptual subclasses:

• Subclass has additional attributes or associations of interest
• Subclass behaves or is operated on, or handled or
manipulated differently than superclass or other subclasses

66
 Is this hierarchy OK? What does it add to our
understanding of the domain?
Authorizes-payments-of
* Store

*
superclass justified by AuthorizationService
common attributes and
associations address
name additional associations
phoneNumber

Credit Check
Authorization Authorization
Service Service

1 1
Authorizes Authorizes
* *
Credit Check
Payment Payment Fig. 31.8

Models transactions with external services which are important in POS domain 67
 When to design Association classes?
a better model, but not
yet as useful as possible
AuthorizationService
Store
Authorizes-payments-via address
address 1..* name
name * phoneNumber

Purchases ServiceContract
Sells
Fig. 31.15
1..* merchantID *
ServiceContract records merchantID—good.
But ServiceContract is dependent on relationship between two classes
AuthorizationService
Store
Authorizes-payments-via address
address 1..* name
name * phoneNumber

an association class
Fig. 31.16 ServiceContract
its attributes are related to the association
merchantID
its lifetime is dependent on the association
68
What about this hierarchy? (Why not?)
Payment
not useful

these subclasses are

changing states of the
Unauthorized Authorized
superclass
Payment Payment

* Is-in 1
Payment PaymentState better

Unauthorized Authorized
Fig. 31.13 State State

• Classes should be invariant

• Classes can maintain state information as attributes
• Rather than subclasses, model changing states with state charts

69
 More Association classes
Employs
Company * * Person

a person may have Employment

employment with several
companies salary

1 Incarcerates
Jail * Person

JailTerm

dateOfIncarceration

Married-to

0..1 0..1 Fig. 31.17

Person
70
When to add Composition notation?
Sale SalesLineItem
1 1..*

Product Product
Catalog 1 1..* Description

Fig. 31.18

Guidelines for drawing Composition (whole-part) relationships:

• Obvious whole-part physical or logical assembly
• Lifetime of part is bound within lifetime of whole
(create-delete dependency)
• Some properties of whole propagate to parts, e.g., location
• Operations of whole propagate to parts, e.g., movement
• But: If in doubt, leave it out.

71
Higher order package for POS domain

Domain

Core/Misc Payments Products Sales

Authorization
Transactions

Fig.
31.29
What does this higher order package contain?

72
 Core/Misc package
Core/Misc

Store
Houses
Register Manager
address 1 1..*
name
1..*
1
Employs

Fig. 31.30

Why call this package Core for the POS domain?

73
 Payments
A rich package
1 Authorizes-payments-of
1..*

Payment Core::Store AuthorizationService

ServiceContract
amount address
merchantID name
phoneNumber

Paid-by
Check
1
1
Check Credit
CashPayment Credit Check Authorized-by Authorization Authorization
Payment Payment 1
amountTendered
* Service Service
* * * * 1
Authorized-by
Logs 
Establishes- Establishes-
credit-for  identity-for 
Authorization Transactions::
1 1 1
PaymentAuthorizationReply
Accounts CreditCard DriversLicense
Receivable
expiryDate number
number - CheckPayments have
1
Identifies CheckPaymentReplies
1 1
Abused-by - CreditPayments have
Sales::Customer
1 CreditPaymentReplies

Fig. 31.31
74
Note: Composition and tie to Core package
Products

Sales::
SalesLineItem 0..1

Described-by *
1

Product
Description
ProductCatalog description
1 1..*
price
itemID
1
Records-sale-of
Describes

*
Core:: Stocks Item
Store 1 1
*
Fig. 31.32 75
Iteration-3 of Monopoly domain model

76
Conceptual Class Hierarchies
● Organizing classes into hierarchies facilitates
the reuse of code and the reuse of solutions
to design problems that have already been
solved.
● Class hierarchies as sets - supersets
(referred to as superclasses or base classes),
and subsets (referred to as subclasses or
derived classes).
Conceptual Class Category
Conceptual Class Category Examples
Physical or tangible objects Register, Airplane
Specifications, deigns or descriptions of ProductSpecification, FlightDescription
things
Places Store, Airport
Transactions Sale, Payment, Reservation
Transaction line items SalesLineItem
Roles of people Cashier, Pilot
Containers of other things Store, Bin, Airplane
Things in a container Item, Passenger
Other computer or electro-mechanical CreditPaymentAuthorizationSystem
systems external to the system AirTrafficControl
Organizations SalesDepartment, ObjectAirline
Events Sale, Payment, Meeting, Flight, Crash,
Landing
Rules and policies RefundPolicy
CancellationPolicy
Catalogs ProductCatalog, PartsCatalog
Records of finance, work, contracts, Receipt, Ledger, EmploymentContract,
legal matters MaintenanceLog
Financial instruments and services LineOfCredit, Stock
Manuals, documents, reference papers, DailyPriceChangeList , RepairManual
books
Example:
Design of Class Hierarchies
⚫ Design a system of classes, put common
data and functionality in a superclass,
which you then use to derive subclasses.
⚫ The subclasses inherit the data and
functionality of the superclass and define
only aspects that are unique to their
particular purposes.
Class Hierarchies advantages:
⚫ Avoid duplicating code that is common to
all classes.
⚫ Add or change subclasses at any time
without modifying the superclass or
affecting other subclasses.
⚫ If the superclass changes (for example,
all employees are assigned a number),
then subclass automatically get these
changes.
Aggregation and Composition

⚫ Aggregation is a kind of association

used to model whole-part relationships
between things.
⚫ The whole is called Composite.
⚫ For instance, physical assemblies are
organized in aggregation relationships
such as a Hand aggregates Fingers.
Aggregation in the UML

⚫ Aggregation is shown in the UML with a

hollow or filled diamond symbol at the
composite end of whole-part association.
⚫ Aggregation is a property of an
association role.
Aggregation Notation
Example Composition Aggregation

⚫ A finger is a part of at most one hand (we

hope!), thus the aggregation diamond is
filled to indicate composite aggregation.
Multiplicity At Composite End

⚫ If the multiplicity at the composite end is

exactly one, the part may not exist separate
from some composite.
⚫ For Example : if the finger is removed from the
hand, it must be immediately attached to
another composite object (another hand, a
food,…); at least, that is what the model is
declaring, regardless of the medical merits of
this idea!
Multiplicity At Composite End (2)

⚫ If the multiplicity at the composite end is

0…1,then the part may be removed from
the composite, and still exist apart from
membership in any composite.
⚫ So in previous example if you want
fingers floating around by themselves,
use 0…1.
Shared Aggregation – Hollow Diamond

⚫ Means that the multiplicity at the composite

end may be more than one.
⚫ It is signified with Hollow Diamond.
⚫ Implies that the part may be simultaneously in
many composite instances.
⚫ Shared aggregation seldom exists in physical
aggregates, but rather in nonphysical
concepts.
Shared Aggregation : Example

⚫ A UML package may be considered to

aggregate its elements. But an element
may be referenced in more than one
package.
How To Identify Aggregation

⚫ In some cases, the presence of

aggregation is obvious.
⚫ Usually in physical assemblies.

⚫ But sometimes, it is not clear.

⚫ On Aggregation : If in doubt,leave it out.
Aggregation In The POS Domain Model

⚫ In the POS domain, the SalesLineItems

may be considered a part of a composite
Sale; in general, transaction line items
are viewed as parts of an aggregate
transaction.
Aggregation In The POS Domain Model (2)

⚫ In addition to conformance to that pattern,

there is create – delete dependency of the line
items on the Sale – their lifetime is bound
within the lifetime of the sale.
⚫ By similar justification , Product Catalog is an
aggregate of Product Specifications.
⚫ No other relationship is a compelling
combination that suggests whole – part
semantics, a create – delete dependency, and
“If in doubt, leave it out.”
Aggregation In POS Application
System Sequence Diagrams

⚫ Class diagrams represent static

modeling.
⚫ What about modeling dynamic behavior?
⚫ Interaction diagrams (Sequence and
communication diagrams) model how
groups of object collaborate to perform some
behavior
➢ Typically captures the behavior of a single
use case
System Sequence Diagram (SSD)

For a use case scenario, an SSD shows:

⚫ The System (as a black box) :System
⚫ The external actors that interact with System
⚫ The System events that the actors generate ,
their temporal order.
System Sequence Diagram (SSD)
How to construct an SSD from a use case

System Sequence Diagrams

⚫ Draw a line representing the system as ablack box.

⚫ Identify each actor that directly operates on the system.

⚫ Draw a line for each such actor.

⚫ From detailed (expanded) use case identify system events that

each actor generates.

 Relationship SSD and Use case
Develop SSDs for the main success scenario of a selected use
case, then frequent alternative scenarios
Process Sale
system as black box

the name could be "NextGenPOS" but "System" keeps it

simple

the ":" and underline imply an instance, and are explained in a

later chapter on sequence diagram notation in the UML

external actor to Process Sale Scenario

system

: Cashier :System

makeNewSale

a UML loop loop [ more items ]

interaction enterItem(itemID, quantity)
frame, with a
boolean guard
expression description, total

endSale a message with

parameters
return value(s)
associated with the it is an abstraction
previous message total with taxes
representing the
system event of
an abstraction that entering the
ignores presentation makePayment(amount)
payment data by
and medium some mechanism
the return line is change due, receipt
optional if nothing is
returned
When to use Class Diagrams?

• Class diagrams are the backbone of

nearly all OO methods so, it will be
used in all the time.
 Ref: Text Book-1
Craig Larman, Applying UML and Patterns: An Introduction to Object Oriented Analysis and
Design and Iterative Development, Third Edition, Pearson Education, 2005.