COURSE NAME

OBJECT ORIENTED CHAPTER 3

ANALYSIS AND
DESIGN CLASS DIAGRAM
CSC 2210
SOFTWARE
(UNDERGRADUATE)
ENGINEERING
(UNDERGRADUATE
)
Object Oriented Analysis and Design: Class Diagram
S.2

WHAT IS CLASS?
 A class describes a group of objects with
 similar properties (attributes),
 common behavior (operations),
 common relationships to other objects,
 and common meaning (“semantics”). Student
Name Name (mandatory)
Attributes
(optional) ID #
 Examples Department
 Employee: Registration()
Assignment() Operations
- has a name, employee id, and department;
Exam Result() (optional)
- an employee works in one or more projects
Object Oriented Analysis and Design: Class Diagram
S.3

CLASS DIAGRAM
 The Class diagram represents classes, their component parts, and the way in
which classes of objects are related to one another.
 The Class diagram includes:
 Attributes describe the appearance and knowledge of a class of objects (e.g.,
birds have wings).
 Operations define the behavior that a class of objects can manifest (e.g., dog
is barking).
 Stereotypes help you understand this type of object in the context of other
classes of objects with similar roles within the system’s design.
 Properties provide a way to track the maintenance and status of the class
definition
(e.g., properties of a class attribute can be public/private/protected)
 Classes are used to represent objects. Objects can be anything having
properties and responsibility.
Object Oriented Analysis and Design: Class Diagram
S.4

DRAWING CLASS DIAGRAM : ATTRIBUTE

 An attribute describes a piece of information that an object owns or knows
about itself.
 Attribute visibility:
 Public (+) visibility allows access to objects of all other classes. Default
accesses specifier.
 Private (-) visibility limits access to within the class itself except friend
function.
For example, only operations of the class have access to a private attribute.
 Protected (#) visibility allows access by subclasses. In case of generalizations
(inheritance), subclasses must have access to the attributes and operations
of the super-class or they cannot be inherited.
 Package (~) visibility allows access to other objects in the same package.
Object Oriented Analysis and Design: Class Diagram
S.5

DRAWING CLASS DIAGRAM : ATTRIBUTE

visibility / attribute name : data type = default value
{constraints}

 Visibility (+, -, #, ~): Required before code generation. The programming

language will typically specify the valid options. For example, the minus sign
represents the visibility “private” meaning only members of the class that
defines the attribute may see the attribute.
 Slash (/): The derived attribute indicator is Optional. Derived values may be
computed or figured out using other data and a set of rules or formulas.
Consequently, there are more design decisions that need to be addressed
regarding the handling of this data. Often this flag is used as a placeholder
until the design decisions resolve the handling of the data (C = A* B).
 Attribute name: Required. Must be unique within the class. It is recommended
that attribute name should be a meaningful name with the value it stores,
i.e., at least three character long.
Object Oriented Analysis and Design: Class Diagram
S.6
 Data type: Required. During analysis, the data type should reflect how the
DRAWING CLASS DIAGRAM : ATTRIBUTE
client sees the data. You could think of this as the external view. During
design, the data type will need to represent the programming language data
type for the environment in which the class will be coded. These two pieces of
information can give the programmer some very specific insights for the
coding of get and set methods to support access to the attribute value.
 Assignment operator and default value: Optional. Default values (usually
zero) serve two valuable purposes.
- First, default values can provide significant ease-of-use improvements for
the client.
- Second and more importantly, they protect the integrity of the system from
being corrupted
by missing or invalid values.
- A common example is the tendency to let numeric attributes default to
zero. If the application
ever attempts to divide using this value, you will have to handle resulting
errors that could
have been avoided easily with the use of a default.
Object Oriented Analysis and Design: Class Diagram
S.7

DRAWING CLASS DIAGRAM : ATTRIBUTE

 Constraints: Constraints express all the rules required to guarantee the
integrity of this piece of information. Any time another object tries to alter
the attribute value, it must pass the rules established in the constraints. The
constraints are typically implemented/enforced in any method that attempts
to set the attribute value, e.g. {ID is assign by the system}
 Static Class level attribute (underlined attribute declaration): Optional.
Denotes that all objects of the class share a single value for the attribute.
(This is called a static value in Java.)
 Object Oriented Analysis and Design: Class
S.8

DRAWING CLASS DIAGRAM : OPERATION

 Objects have behaviors, things they can do and things that can be done to
them. These behaviors are modeled as operations.
 Operations require a name, arguments, and sometimes a return.
 Arguments, or input parameters, are simply attributes, so they are specified
using the attribute notation (name, data type, constraints, and default),
although it is very common to use the abbreviated form of name and data
type only.
 Object Oriented Analysis and Design: Class
S.9

DRAWING CLASS DIAGRAM : OPERATION

visibility operationName ( argname : data type
{constraints}, ...) : return data type {constraints}
 Visibility (+, -, #, ~): Required before code generation. The visibility values
are defined by the programming language, but typically include public (+),
private (-), protected (#), and package (~).
 Operation name: Required. Does not have to be unique, but the combination
of name and parameters does need to be unique within a class.
 Arguments/parameters: Parameter is the list of arguments. Any number of
arguments is allowed in the parameter. Each argument requires an identifier
and a data type. Constraints may be used to define the valid set of values
that may be passed in the argument. But constraints are not supported in
many tools and will not be reflected in the code for the operation, at least not
at this point.
 Object Oriented Analysis and Design: Class S.
10

DRAWING CLASS DIAGRAM : OPERATION

 Argument name: Required for each parameter, but parameters are optional.
Any number of arguments is allowed.
 Argument data type: Required for each parameter, but parameters are
optional.
 Constraints: Optional. In general, constraints express rules that must be
enforced in the execution of the operation. In the case of parameters, they
express criteria that the values must satisfy before they may be used by the
operation. You can think of them as operation level pre-conditions.
 Return data type: Required for a return value, but return values are optional.
The UML only allows for the type, not the name, which is consistent with most
programming languages. There may only be one return data type, which
again is consistent with most programming languages.
Object Oriented Analysis and Design: Class S.
11
DRAWING CLASS DIAGRAM

Name Compartment

Attribute Compartment
visibility / attribute name :
data type
= default value
{constraints}
Operation Compartment

visibility operationName
( argname : data type
{constraints}, ...) : return data
type {constraints}
 Object Oriented Analysis and Design: Class S.
12

CLASS DIAGRAM RELATIONSHIPS

 Association is just a formal term for a type of relationship that this type of
object may participate in. Associations may come in many variations,
including simple, aggregate and composite, and Reflexive (e.g.,
relationships among objects of the same classes).
 Association Class encapsulates information about relationship
 Inheritance allows you to organize the class definitions to simplify and
facilitate their implementation.
 Although other diagrams are necessary, but their primary purpose is to
support the construction and testing of the Class diagram.
 Whenever another diagram reveals new or modified information about a
class, the Class diagram must be updated to include the new information. If
this new information is not passed on to the Class diagram, it will not be
reflected in your code.
 Object Oriented Analysis and Design: Class S.
13
ASSOCIATIONS
 A semantic relationship between two or more classes that specifies
connections among their instances.
 A structural relationship, specifying that objects of one class are connected
to objects of a second class.
 Example: “An Employee works for a Company”

Works for
Employee Company
 An association between two classes indicates that objects at one end of an
association “recognize” objects at the other end and may send messages to
them.
 This property will help us discover less trivial associations using interaction
diagrams.
 Qualified association in class diagram indicates a qualifier to be used for
Indexing
Object Oriented Analysis and Design: Class S.
14

ASSOCIATIONS
Associations may optionally have the following:
 Association name
 Small black arrowhead to indicate the direction in which the name should
be read
 Should be a verb or verb phrase;
 Role names
 on one or both association ends;
* *
 should be a noun or noun phrase describing the semantics of the role;
 Multiplicity
 The number of objects that can participate in an instantiated relation
 Navigability
 The direction of Arrows
 Object Oriented Analysis and Design: Class S.
15
ASSOCIATION
 Association multiplicity MULTIPLICITY
limits the number of objects that can participate in an
association.
 Provides a lower and upper bound on the number of instances (at opposite end)
 Indicates whether an association is mandatory

Ask questions about the associations: 1 * .. 0

Company Employee
 Can a company exist without any employee?
 If yes, then the association is optional at the Employee end - zero or more
(0..*)
 If no, then it is not optional - one or more (1..*)
 If it must have only one employee - exactly one (1)
 What about the other end of the association? Can an employee work for more
than one company?
 If no, the correct multiplicity is 1.
Object Oriented Analysis and Design: Class S.
16

MULTIPLICITY INDICATOR

Exactly one 1
Many *
Zero or more 0..*
One or more 1..*
Zero or one (optional association) 0..1
Specified range 2..4
Multiple, disjoint ranges 2, 4..6, 8
Object Oriented Analysis and Design: Class S.
17

AGGREGATION
 A special form of association that models a whole- part relationship between
an aggregate (the whole) and its parts (shared class i.e., Part by Whole
class)
 Models a “is a part-part of” “has-a” relationship.

2..* 1..*
Car Door House

Whole Part Whole

Object Oriented Analysis and Design: Class S.
18

AGGREGATION
 Is the phrase “part of” used to describe the relationship?
 A door is “part of” a car

 Are some operations on the whole automatically applied to its parts?

 Move the car, move the door.

 Are some attribute values propagated from the whole to all or some of its
parts?
 The car is blue; therefore, the door is blue.

 Is there an intrinsic asymmetry to the relationship where one class is

subordinate to the other (inheritance) ?
 A door is part of a car. A car is not part of a door.
Object Oriented Analysis and Design: Class S.
19

COMPOSITION

 A strong form of aggregation

 The whole is the sole (only) owner of its part.
- The part object may belong to only one whole
 The lifetime of the part is dependent upon the whole.
- The composite must manage the creation and destruction of its parts.
- if the whole is removed from the model, so is the part.
- the whole is responsible for the disposition of its parts
Object Oriented Analysis and Design: Class S.
20

AGGREGATION & COMPOSITION

 Person has relationships
with both Car and Train, but
Engine has only one
1 :Engine relationship with Car
 Whole side can not be zero
composition in composition

:steam engine 1..*

1
1
:Car :Train
0..1
:Person 0..1
0..*
driver 1 passengers
aggregation
Object Oriented Analysis and Design: Class S.
21

ASSOCIATION CLASS

ENCAPSULATES INFORMATION ABOUT AN ASSOCIATION

Object Oriented Analysis and Design: Class S.
22

REFLEXIVE ASSOCIATION
Reflexive association is a fancy expression that says objects in the same
class can be related to one another. The entire association notation you’ve
learned so far remains exactly the same, except that both ends of the
association line point to the same class.
Object Oriented Analysis and Design: Class S.
23

QUALIFIED ASSOCIATION
Object Oriented Analysis and Design: Class S.
24

GENERALIZATION
 Generalization is a relationship between a more general thing and a more
specific thing:
 The more specific thing is consistent in every way with the more general
thing.
 The substitutability principle states that you can substitute the more
specific thing anywhere the more general thing is expected.
 Generalization is a bottom-up process
 Generalization hierarchies may be created by generalizing from specific
things or by specializing from general things.
 “is kind of” or “is type of” relationship.
Object Oriented Analysis and Design: Class S.
25

GENERALIZATION

More general element Parent  {abstract} is a tagged

Superclass
Ancestor value
Base Class that indicates that the
“is a kind of”
class is
Child abstract (no object).
Subclass  The name of an abstract
Descendant
More specific element Leaf / Derived class should be italicized

Shape Super
A class
Class

Generalization
relationship
Circle Sub Class
 Object Oriented Analysis and Design: Class S.
26

INHERITANCE
 A sub-class inherits from its super-class
 Attributes
 Operations
 Relationships
 A sub-class may
class A2 extends B2
 Add attributes and operations
 Add relationships
 Refine (override) inherited operations

Super classes may be declared {abstract}, meaning they have no instances

 A generalization relationship may not be used to model interface
implementation (realization)
Object Oriented Analysis and Design: Class S.
27

REALIZATION
 A realization relationship indicates that one class implements a behavior
specified by
another class (an interface).
 An interface can be realized by many classes. In another words, a class
may realize many
interfaces.

class A3 implements B3
Object Oriented Analysis and Design: Class S.
28

DEPENDENCY
 A dependency indicates a semantic relation between two or more classes
in which a change in one may force changes in the other.

Car depends on wheel

Object Oriented Analysis and Design: Class S.
29

CONSTRAINT RULES AND NOTES

 Constraints and notes annotate among other things, e.g., associations,
attributes, operations, and classes.
 Constraints are semantic restrictions noted as Boolean expressions.
 UML offers many pre-defined constraints.

Customer 1 * may be
Order canceled
{ total < $50 }
id: long { value > 0 }

Note
Constraint
Object Oriented Analysis and Design: Class S.
30

LOGICAL DISTRIBUTION OF CLASSES

 Add package information to class diagram

b a
b.a a.A

b.a.F
b.b

b.b.E b.b.D a.B

b.a.G

a.C
Object Oriented Analysis and Design: Class S.
31

CLASSES
 Boundary Classes CATEGORIZATION
 Models the interaction between the system’s surroundings and its inner
workings
 User interface classes, Concentrate on what information is presented to
the user,
don’t concentrate on user interface details
 System / Device interface classes, concentrate on what protocols must be
defined.
don’t concentrate on how the protocols are implemented
 Entity Classes
 Models the key concepts of the system
 Usually models information that is persistent
 Contains the logic that solves the system problem
 Can be used in multiple behaviors
Object Oriented Analysis and Design: Class S.
32

CLASSES CATEGORIZATION

 Control Classes
 Controls and coordinates the behavior of the system
 A control class should tell other classes to do something and should never
do anything except for delegating (directing) the work to other classes
 Control classes separate boundary and entity classes
Object Oriented Analysis and Design: Class S.
33

CLASSES CATEGORIZATION

ReportDetailsForm 1 Of f endersDBProxy
<<boundary >> 1 <<boundary >>
Of f endersDB

EditReportController
<<control>>
Clerk

Conf irmationDialog 1 1 PolicemanDBProxy

<<boundary >> 1 <<boundary >>
PolicemenDB
Traf f icReport

Violation Of f ender Traf f icPoliceman

Object Oriented Analysis and Design: Class S.
34

CRC CARD

 Class Responsibility Collaboration

 CRC goals: provide the simplest possible conceptual introduction to OO design

Class:
Class:
Description:
Class:
Description:
Class:FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera
 Object Oriented Analysis and Design: Class S.
35

CRC CARD
A CRC card is a 3-x-5" or 4-x-6" lined index card.
The physical nature of the cards emphasizes the division of responsibility
across objects.
The physical size of the cards also helps to establish limits for the size and
complexity of the classes.
The CRC card technique does not use the UML, instead it is used to
discover information about classes that is then placed into a UML Class
diagram.
The body of the card is divided in half.
 The left column/half lists the responsibilities of the class
 The right column/half lists the other objects that it works with, the
collaborators,
to fulfill each responsibility.
Object Oriented Analysis and Design: Class S.
36

CLASS VS. OBJECT DIAGRAM

 The class defines the rules; the objects express the facts. The class defines
what can be; the object describes what is.
 If the Class diagram says, “This is the way things should be” but the Object
diagram graphically demonstrates that “it just ain’t so” then you have a
very specific problem to track down.
 The Object diagram can confirm that everything is working as it should.
 Object Oriented Analysis and Design: Class S.
37

REFERENCES

 Booch, G., Rumbaugh, J. & Jacobson, I. (2005). The unified modeling language user
guide. Pearson Education India.
 Object Oriented Analysis and Design: Class S.
38

CASE STUDIES
 Case 1: Draw the Class notation for Class Named ‘Book’.
Private attributes of the class are:
bookID ->Numeric; assigned by system, default value: none,
bookName. ->String,
authorName->String ,
bookCopy->Numeric,
totalBook->Static and numeric
Public methods of this class are:
setBookID(Numeric; assigned by system, default value: none),
setBookName(String),
setAuthorName(String) ,
addBookCopy(Numeric ,default value: zero),
deleteBookCopy(Numeric ),
showBookInfo (void)
 Object Oriented Analysis and Design: Class S.
39

CASE STUDIES
 Case 2: Draw the Class notation for Class Named ‘Movie’.
A movie is a collection of visual pictures that tell a story and are displayed on a screen, generally with
sound. A film producer produces movies in a different category. Every movie category has some
attributes. For example, MovieID, Name, ReleaseDate, Rating, DurationTime, Actor and Actress.
All attributes are private. DurationTime and Rating is Double in data type. MovieID is an integer
and other attributes are String in data type. There might be six methods for almost every movie
category. All methods are public. They are: setScriptTitle(String Title), setMovieName(String
Name), getReleaseDate(). All methods return String value without getReleaseYear(). Only
getReleaseYear() methods return an integer value.
 Object Oriented Analysis and Design: Class S.
40

CASE STUDIES
 Case 3: Draw the Class diagram for the following scenario.
Student may attend any number of courses
Every course may have any number of students
Instructors teach courses
For every course there is at least one instructor
Every instructor may teach zero or more courses
A school has zero or more students
Each student may be a registered member of one or more school
A school has one or more departments
Each department belongs to exactly one school
Every instructor is assigned to one or more departments
Each department has one or more instructors
For every department there is exactly one instructor acting as the department chair
 Object Oriented Analysis and Design: Class S.
41

CASE STUDIES
 Case 4: Draw the Class diagram for the following scenario.

A building is owned by one person

A person may own more than one building
Each building is either a house or an apartment
An apartment contains two or more Rental Units
It is possible to buy a house, and rent or vacate a Rental Unit
 Object Oriented Analysis and Design: Class S.
42

CASE STUDIES
 Case 5: Draw the Class diagram for the following scenario.

A company has one or more divisions

A division has one or more departments
A company can have one or more persons working as employees
A person is associated with the company as an employee
A department can have one or more persons assigned to it
A person is assigned to one department
 Object Oriented Analysis and Design: Class S.
43

CASE STUDIES
 Case 6: Draw the Class diagram for the following scenario.

The library contains books and journals. It may have several copies of a given book. Some of
the books can be reserved for short-term loans and others for long-term. Member of library
can borrow books. There is a special type of member- Member of Staff, who can borrow the
journals. The system must keep track of when books and journals are borrowed.
 Object Oriented Analysis and Design: Class S.
44

CASE STUDIES
 Case 7: Draw the Class diagram for the following scenario.

A nonprofit organization depends on a number of different types of persons for its

successful operation. Three types of persons are of greatest interest: employees,
volunteers, and donors. Employees and volunteers work on various projects organized
by the organization. One project consists of many sections. A volunteer works under
the supervision of an employee. An employee is responsible to write reports on the
project at the completion of the project. To become a recognized donor, a donor must
have donated one or more items, and an item may have no donors, or one or more
donors. Projects and events are also sponsored by sponsors. Sometimes a single
project or event is sponsored by multiple sponsors. An event is made of various
activities.