Object Oriented Analysis and Design

Class Diagram Basics

1
Purpose of Class Diagram
 The Class Diagram shows many
key characteristics of the system
 What classes can exist
 Their attributes (data)

 Their methods (functions to get to

the data)
 How the classes see each other (like

relationship and cardinality)

2
Class Diagram Evolves
 The class diagram evolves as a
system is analyzed
 The initial conceptual class diagram
might just show classes and key
attributes, connected by associations
 The complete class diagram can show

all classes needed to complete the

system

3
Classes versus Objects
 Recall that objects are derived, or
instantiated, from classes
 Hence we assume that any class
could be used one or more times to
create objects
 Objects can be created and
destroyed, including interface
classes and temporary data

4
The Conceptual Class Diagram
 To define the conceptual class
diagram, we’ll need to determine
 Classes
 Primarily data and major control classes
 Associations
 Including label and multiplicity
 Attributes

5
Conceptual Class Diagram
 Also called a Domain Model, the
conceptual class diagram is the
simplest form of the class diagram
 It shows the classes, their
associations, and attributes
 Does not show methods or interface
classes

6
Types of Classes
 For the conceptual class diagram,
focus on data classes for significant
use cases
 Fill in the rest later

7
 Conceptual Class Diagram Excerpt

1..*
Sale 1 Contained-in SalesLineItem
-date -quantity
-time
Paid-by
Association label
1
Association

1 Multiplicity (discuss later)

Payment Conceptual class

-amount Attribute

8
Class Notation

9
Class Notation

10
Analogies to ERD
ERD has Class Diagram has
Entities Classes
Relationships Associations
Cardinality Multiplicity
Data elements or Attributes
attributes

11
Analogies to ERD
 Just because a conceptual class
diagram looks similar to an ERD,
don’t think they are the same thing!
 Classes can exist for transient data
you’d never keep in an entity

12
Class Naming Conventions
 Notice that Class and attribute
names are singular (Sale, not
Sales), and words are spelled out
 The dash before attribute names
has meaning … we’ll get to later

13
Class Naming Conventions
 Capitalization conventions:
 Class names use initial capital letters
for each word; no spaces between them
(SalesLineItem)
 Attributes use all lower case (date)

 Associations use initial capital letters

for the first word and dashes between

words (Contained-in)

14
Finding Classes

15
Identifying Classes
 Use the use case scenarios for
finding conceptual classes – look for
noun phrases, then evaluate them
 Is it an important concept for this
system?
 Is it an attribute of something bigger, or

is it a self-contained idea or thing?

16
Identifying Classes
 Consider the possibility that classes
can have other classes within them
A single Sale can have many entries,
each of which is a SalesLineItem
 A ComputerSystem can have many

ComputerParts

17
Identifying Classes
 Notice that classes can be actions,
transactions, or events, like
 BookingASeat: A controller class for
managing the process of booking a seat
on an airline
 There is not a single correct list
of classes for a problem

18
Identifying Classes
 Use terminology for class names
which is native to the system’s
environment
 Don’tmake the customer learn new
words for old ideas
 Omit things which aren’t relevant to
meeting the system’s requirements
 If in doubt, make it a separate class
 Then see if it’s needed later

19
Identifying Classes
 People’s roles might be classes
 Does the type of user require a
separate class, or is it just an
attribute?
 Might need a class if the user type
affects what data are needed
(attributes) or functions can be
performed (methods)

20
Description Conceptual Classes
 Often it is needed to have a place
for information about a thing – such
as a product description
 We tend to keep a class for such
descriptions, in case all those things
disappear (e.g. are sold)
 Many sales or manufacturing systems
will have a ProductDescription class
or ProductSpecification

21
Finding Associations

22
Adding Associations
 An association is shows that there is
a meaningful connection between
two classes
 Formally, it is: The semantic
relationship between two or more
classifiers that specifies connections
among their instances

23
Adding Associations
 Associations imply a relationship
which may be kept for a second,
or forever
 Associations are often from a need-
to-know basis – e.g. we ‘need to
know’ what line items were
associated with a given sale

24
Adding Associations
 Associations are generally needed
to trace data
 In order to find some piece of data,
what do I need to know to track it
down? (customer might need to look up
their orders, for example)
 Or, what comes first in the process? (if
I’m creating a new order, do I need to
know what customer is doing so, or can
I add that later?)

25
Adding Associations
 For a conceptual model with ‘n’
classes, there can be n*(n-1)
possible associations
 You need to determine: which
associations are significant?
 Associations are assumed
bidirectional for now – information
can go both directions

26
 Labeling Associations
 Each association has a label to
describe the association, and may
use an arrow to indicate which way
the label should be read
 In Visio, can use ‘<‘ or ‘>’ in the label
for the arrow
Register 1 Records-current > 1 Sale
-date -date
-time -time

Don’t need arrow if association is read left-right or top-bottom

27
Finding Associations
 Most common association types are
 Physical or logical types (e.g. Register
is physically located in Store)
 When information is stored, recorded or
captured (Register reports Sale)
 Classes are more critical to identify
than associations
 Avoid too many associations
 But at least one per class

28
Multiplicity
 Here ‘*’ means many, but by itself it
means ‘0, 1, or many’
 ‘1..*’ means one or many
 ‘1..40’ means a range from 1 to 40
 ‘n’ means only the value of ‘n’
 Obsolete (from UML 1.x):
 ‘a, b, c’ means only a, b, and c are
allowable values, e.g. ‘2, 5, 7’

29
Multiplicity
 To determine multiplicity, think of
what values may be true at any
one moment
 Consider what multiplicity is
meaningful from your system’s
point of view

30
Multiple Associations
 It is possible to show two
associations between the same
two classes, if the associations
are handled very differently by
the system
 E.g. Flight Flies-to Airport and
Flight Flies-from Airport

31
Cleaning up Associations
 In general, we may define
associations conceptually that
don’t get implemented (used),
or may later find associations
we missed here

32
Cleaning up Associations
 Whether an association is needed
depends heavily on the system’s
requirements
 “Sale Initiated-by Customer” may be
trivial for a gas station, but important
for a grocery store which analyzes its
regular customers

33
Cleaning up Associations
 OTOH, might want to keep
associations which reveal key
information about the problem,
even though we may never
implement them
 “Sale Initiated-by Customer” could be
kept as a reminder of who starts the
purchasing process

34
Finding Attributes

35
Adding Attributes
 Attributes are data values which
describe a class
 Following the need-to-know
concept, we want all attributes
which we need to remember for
our system
 Attributes may be described by
their type of data (particularly for
non-primitive data types)

36
Adding Attributes
 Key to finding good attributes
is to make sure each one is
A simple characteristic
 Which is uniquely defined by the

class to which it belongs

37
Attribute Form
 [visibility] [/] name [: type]
[multiplicity] [=default] [{property-
string}]
 This visibility marker indicates
whether the attribute is public (+)
or private (-)
 The name of the attribute-how the
class refers to the attribute

38
Primitive vs. Non-Primitive Data
 Primitive data types are the most
basic ways to represent data in a
computer
 Boolean (True/False, Yes/No, 0/1)
 Number (integer or real)

 String (text)

 Date

 Time (may be merged with Date)

39
Primitive vs. Non-Primitive Data
 Most complex data types are
considered non-primitive
 Phone number, SSN, money, etc.
are all non-primitive

40
Ex.

41