Objects, Classes, and
Basic Class Diagrams
Classifier
Generalizable
Element
isRoot
Model
Element
Namespace
name
visibility
isSpecification
CS/SWE 421
Introduction to Software Engineering
Dan Fleck
(Slides adapted from Dr. Stephen Clyde with permission)
Constraint
Body
Introduction to Objects


Objects are the fundamental building blocks
of object-oriented systems
What is an object?
– It represents any “thing”
– It has a boundary in space and time
– It is an abstraction
– It encapsulates state and/or behavior
– It has identity
Introduction to Objects

What aren’t objects?
– Events (sometimes)
– Relationships between objects (most of the
time)
– Behavior (most of the time)
– Constraints (most of the time)
Exercise - Object Hunt


Part 1 - List examples of objects in the
Third National Bank Elevator System
Part 2 - List some concepts from this
system that would not typically be modeled
as objects
Introduction to Classes


Most systems have large numbers of
objects that come and go throughout the
systems’ lifetimes
Humans naturally classify similar things by
their observable properties
– Watch how little children reference things

Classes are abstractions that allow us to
deal with whole collections of objects that
share some commonalties
Introduction to Classes

Examples of classes in a Student Records
Management System
Student
Class
Section
Course
Semester
College
Instructor
Department
Class
Grade
Major
Three Perspectives


Objects and classes, as well as all other
modeling components in UML, can be
interpreted from different perspectives:
Three common perspectives:
– Analysis - description of the problem
domain
– Specification - logical description of
software system
– Implementation - description of software
components and their deployment
Classes from different Perspectives

Meaning from three perspectives
– Analysis: sets of objects
– Specifications: interfaces to encapsulated
software representations of objects
– Implementations: abstract data types
Analysis
Specification
Implementation
Student
Student
Student
Interface Student
{…}
class Student
{…}
{Joe, Sue, Mary,
Frank, Tim, …}
Class Syntax

A box divided into
compartments
– Name
– Attributes
– Operations
– Responsibilities
– Used-defined
compartments
Student
major: String
gpa: Real
standing: String
add(Class Section)
drop(Class Section)
-- The set of students
known to the
registration system
-- An exception occurs if
gpa falls below 2.0
Class Names



The name should be a noun or noun phrase
The name should be singular and
description of each object in the class
The name should be meaningful from a
problem-domain perspective
– “Student” is better than “Student Data” or
“S-record” or any other implementation
driven name


Avoid jargon in the names
Try to make the name descriptive of the
class’s common properties
Class Name Syntax



A class name may be text consisting of any
numbers, letters, and punctuation marks
(except “:”)
Capitalize each word that makes up the
name
A class name can include a path
specification, if the class is part of a
package.
– “Records Management Package::Student”
– More on packages later
Exercise – Class Identification

Identify meaningful classes in the Elevator
System
Return to Objects – Object Syntax

Object syntax is
similar to class syntax,
except
– the name identifies
specific or generic
object
– the name includes the
class that the object
belongs to

Remember, individual
objects are instances
of classes
joe: Student
major: String = “CS”
gpa: Real = 4.0
standing: String = “”
add(Class Section)
drop(Class Section)
Object Name Syntax





The name includes an the instance name
and a class path, separated by a “:”
The instance name is typically lower case
The instance name be may blank,
meaning an arbitrary object from the
designated class
The class path name may include a path
The whole name is underlined
Attributes





Attributes represent characteristics or
properties of objects
They are place holders or slots that hold
values
The values they hold are other objects
The name of an attribute communicates its
meaning
An attribute can be defined for individual
objects or classes of objects
– If defined for a class, then every object in
the class has that attribute (place holder)
Attributes from an Analysis
Perspective


An attribute relates an object to some other
object
It has the same semantics as an association
joe: Student
name: String = “Joe Jones”
joe: Student
name
1
Is basically the
same as ...
Joe Jones : String
Attributes from a Specification
Perspective

An attribute represents an obligation to
provide or manage a certain (single) piece
of information

For example, each
Student object must
be able to
encapsulate a
major, a GPA, and a
standing
Student
major: String
gpa: Real
standing: String
Attributes from an
Implementation Perspective




Attributes from an implementation
perspective are similar data members in
C++ or Java
They are place holders with value
semantics
Each object can have different values
Constraints can be placed on the attributes
to restrict how and when the values can be
changed
Attribute Syntax
[visibility] name [multiplicity] [:type] [=initial-value]
[{property-string}]
visibility: public “+”, protected “#”, or private “-”
name: capitalize first letter of each word that
makes up the name, except for the first
multiplicity: number, range, or sequence of
number or ranges.
type: build-in type or any user-defined class
initial-value: any constant and user-defined object
property-string: e.g, changeable, addOnly, frozen
Operations

Meaning from three perspectives
– Analysis: Ways in which objects interaction
– Specification: An obligation to provide a
service
– Implementation: A function member, a
method
Operations
Student
major: String
GPA: Real
standing: String
add(Class Section)
drop(Class Section)
Course
Class Section
takes>
name: String
capacity: Integer
add(Student)
drop(Student)
checkPrerequisites(Students)
Prerequisite
Operation Syntax
[visibility] name [(parameter-list)] [:return-type]
[{property-strong}]
visibility: “+”, “#”, “-”
name: verb or verb phase, capitalize first
letter of every word, except first
parameter-list: coma separated list of
parameters
return-type: primitive type or user-defined type
property-string: isQuery, sequential, guarded,
concurrent
Type of Relationships in Class
Diagrams
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Binary Association
Aggregation
Dependency
N-ary Association
Associations


An association is a structural relationship
that specifies that objects of class may be
connected to objects of another class
Meaning from three perspectives
– Analysis: Links between objects
– Specification: Obligation to provide a
connection between objects
– Implementation: Object pointers,
references, linking structures, etc.
Associations
is registered for>
Student
<works for
Instructor
Department
Semester
teaches>
Class
Section
sponsors>
Course
Association Names

Associations may be named
– The names should communicate the
meaning of the links
– The names are typically verb phases
– The words that make up the name are
typically all lowercase
– The name should include an arrow
indicating the direction in which the name
should be read

Some kinds of associations have implied
names
Navigation

The navigation of associations can be
– uni-directional
– bi-directional
– unspecified
<works for
Instructor
Department
teaches>
Class
Section
sponsors>
Course
Navigation
Bi-directional navigation means more than
just being able to traverse the association in
both directions
Instructor
<works for

Department
If instructor x is
associated with
department y, then
department y must be
associated with
instructor x
Navigation


The navigation of association without an
arrowhead is assumed to be undefined
Navigation has little value when modeling
from a conceptual perspective
– Why?

Navigation is more important from
specification and implementation
perspectives
– Why?
N-ary Associations


Associations can connect more than one class
Notation:
Student
Advisor
Major

How should we go about naming an n-ary
association?
Generalization


Generalization is another kind of
relationship in UML – see Meta Model
From an analysis perspective, it is a pure
generalization/specialization concept, i.e.,
the specialization is a subset of the
generalization
Person
Student
Graduate
Student
Generalization

From a specification perspective,
generalization can represent sub-typing,
interface inheritance, type capability, and
substitutability
Student
Person
name: String
address: String
changeAddress(new_address)
major: String
GPA: Real
standing: String
add(Class Section)
drop(Class Section)
Generalization

From an implementation perspective, a
generalization can represent
implementation inheritance (depending on
developing environment)
Student
Person
name: String
address: String
changeAddress(new_address)
major: String
GPA: Real
standing: String
add(Class Section)
drop(Class Section)
Exercise – Simple Associations

From an analysis perspective:
– Identify meaningful associations and
generalization/specializations among
classes in the Elevator System
Class Diagrams

Class Diagrams describe
– the types of objects in a system
– their properties (attributes and operations)
– relationships between objects

Class Diagrams are similar to entityrelationship (ER) data models, but show
classes instead of data entities
Class Diagrams

Class diagrams are collections of
– Classes and individual objects
– Associations, generalizations, and other
kinds of relationships

They can also include
– Grouping concepts like packages
– Constraints
– Various kinds of annotations
Class Diagrams

Class Diagrams are like the paragraphs of
a technical paper
– each diagram should focus on a specific
topic
– a diagram provides supporting detail for the
main concept(s) that it is trying to
communicate
– the level of the abstraction used in the
diagrams should be consistent

Together, all the diagrams for a system
comprise a “model” of that system
Class Diagrams

Pitfalls of Class Diagrams:
– Using class diagrams alone can cause
developers to focus too much on structure
and ignore behavior
– Using the wrong (or a mixed) perspective
can lead to misunderstanding
– Using the wrong level of abstraction can be
confusing to the target audience
– Using mixed levels of abstraction can
reduce the usefulness of diagram
Multiplicity Constraints for
Associations


Multiplicity constraints define how many
objects a given object can be linked to for a
given association
A multiplicity constraint is placed near the
connection of an association to an object
class
Multiplicity Constraints
is registered for>
Student
1..*
0..*
1
0..8
teaches>
<works for
Instructor
1..*
1
Department
Semester
1..3
1
0..6
sponsors>
1..*
Class
Section
1..*
Course
Multiplicity Constraints

A multiplicity constraint can be
– a single number
– a “*”, meaning an arbitrarily large number or
simply “many”
– a range, denoted by “min..max”
– a sequence of single numbers and ranges
Dependencies
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Binary Association
Aggregation
Dependency
N-ary Association
Dependencies



A dependency is a type of relationship
It says that one modeling component “uses”
another.
If the later changes then, the former may
have to change as well
Student
add(Course)
drop(Course)
Prerequisite
Dependencies

Meaning from three perspectives
– Analysis: physical or logical dependency
between the connected classes
– Specification: a “uses” relationship at an
interface level
– Implementation: a “uses” relationship at an
implementation level.

Some kinds of dependencies can be
inferred if the component definitions are
complete
Dependencies

Syntax:
– a dashed link with an straight-line
arrowhead point to a component on which
there is a dependency



Dependencies can be defined among:
classes, notes, packages, and other types
of components
Can dependencies go both ways?
Any problems with having lots of
dependencies?
Aggregations (is part of)
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Binary Association
Aggregation
Dependency
N-ary Association
Aggregation


Aggregation: is a special kind of association
that means “part of”
Aggregations should focus on single type of
composition (physical, organization, etc.)
Crust
1
1
Sauce Serving
1
1
Cheese Serving
Topping Serving
*
Pizza
1..3 1
1
0..9 1
4..*
Slice
1
Order
Questions




What do classes and associations in class
diagrams really mean?
What’s the difference between an attribute
and an association with another class? For
example, should “grade” be an attribute or a
link to another class called “Grade”?
How can we show relationships involving
more than two classes?
When during the software engineering life
cycle should you build classes diagrams?
More Questions




How does one choose a level of abstraction
for modeling the objects of a system?
How does one decide how to break up the
responsibilities of a system into meaningful
classes?
How do you know if you have identified the
best classes for a system?
How do you know where in a class
hierarchy a particular attribute or operation
bests fit?
More Questions




How do you know when a class diagram is
complete?
How can you make the information
captured in a class diagram more
understandable? maintainable? reusable?
How can you manage change control on all
the class diagrams for project?
What do you do with class diagrams after a
system has been built and delivered?