SKCET- LECTURE

Course: 23CD202 - OBJECT ORIENTED ANALYSIS AND DESIGN

Topic : Class Diagram

www.skcet.ac.in
 Module 2 Use Case Modelling

❖ Use Case Modeling: Modeling Requirements - Components –

Use Case Identification and Description –
❖ Use Case Relationships - Relating Use
cases – include - extend - generalization.
❖ Class Diagram – Elaboration –
❖ Domain Model – Finding conceptual classes and description
classes – Associations – Attributes –
❖ Domain Modeling using class diagrams - Domain Model
Refinement - Finding conceptual class hierarchies –
❖ Aggregation and Composition.
❖ Application Case study: E- Commerce Application in Lucid
Chart and Astah
 Introduction

• UML (Unified Modeling Language) is a graphical

language for modeling the structure and behavior of
object-oriented systems.
• UML is widely used in industry to design, develop
and document complex software.

• Focus on creating UML class diagrams, which

describe the internal structure of classes and
relationships between classes.

UML Class Diagrams 3

 What is a Class Diagram?

• A Class Diagram is a diagram describing

the structure of a system
• shows the system's
• classes
• Attributes
• operations (or methods),
• Relationships among the classes.

UML Class Diagrams 4

 UML Class Diagram - Essential Elements

• Class
• Attributes
• Operations
• Relationships
– Associations
– Generalization
– Realization
– Dependency
• Constraint Rules and Notes
UML Class 5
Diagrams
 Class
• Describes a set of objects having similar:
– Attributes (status)
– Operations (behavior)
– Relationships with other classes
• Attributes and operations may
– have their visibility
Class
marked: Name Window
– "+" for public size: Size visibility:
Attributes boolean
– "#" for protected
display() hide()
– "−" for private Operations

– "~" for package

UML Class Diagrams 6
 Classes:

A class diagram contains a rectangle for each class. It is

divided into three parts.

1. The name of the class.

2. The names and types of the fields.
3. The names, return types, and parameters of the
methods.
For example, a Person class and a Book class
might be modeled like this.

This indicates that a Person object has private fields named name
and birthDate, and that it has public methods named getName,
setName and isBirthday.

A Book object has private fields named title and authors. A Book
object also has public methods named getTitle, getAuthors and
addAuthor.
Use Relationships
• Often, objects and/or methods of one class use objects/methods
from another class.
• For example, a person might read and/or own a book, and these
relationships might be modeled in the UML diagram, so that
they will be implemented in the corresponding program.
• UML class diagrams include the following types of
use-relationships, in order from weakest to strongest.
□ Dependency
□ Unidirectional Association
□ Bidirectional Association
□ Aggregation
□ Composition
Dependency:
An object of one class might use an object of another class in the code of
a method.

If the object is not stored in any field, then this is modeled as a

dependency relationship.

For example, the Person class might have a hasRead method with a Book
parameter that returns true if the person has read the book (perhaps by
checking some database).
 Associations
In object-oriented analysis and design (OOAD), association is a
relationship between objects or classes. It can be a one-way or
two-way relationship.
Examples of association
•A doctor and a patient: A doctor can have multiple patients,
and a patient can have multiple doctors.
•A student and a library card: A student can have a library card,
but a library card doesn't need to know about the student.
•A person and a dog: A person can own a dog, and a dog can
be a pet of a person.
•A teacher and a student: A teacher can have multiple students,
and a student can have multiple teachers.
•A customer and an account: A customer can own one or more
accounts.

UML Class Diagrams 11

 Associations (cont.)
• To clarify its meaning, an association may be named.
– The name is represented as a label placed midway
along the association line.
– Usually a verb or a verb phrase.
• A role is an end of an association where it connects
to a class.
– May be named to indicate the role played by the class
attached to the end of the association path.
• Usually a noun or noun phrase
• Mandatory for reflexive associations

UML Class Diagrams 12

 Associations (cont.)
• Multiplicity
– the number of objects that participate in the association.
– Indicates whether or not an association is mandatory.

Multiplicity Indicators

Exactly one 1
Zero or more (unlimited) * (0..*)
One or more 1..*
Zero or one (optional association) 0..1
Specified range 2..4
Multiple, disjoint ranges 2, 4..6, 8
UML Class Diagrams 13
 Associations (cont.)

Role name

Association
name
instructor
StaffMember Student
1..* instructs *
Role
Navigable
Multiplicity (uni-directional)
associatio
* pre -
n

0..3
Reflexive rCeoquuir
association
ssietess
UML Class Diagrams 14
 Unidirectional Association:
An object might store another object in a field.

For example, people own books, which might be

modeled by an owns field in Person objects.

However, a book might be owned by a very large number of

people, so the reverse direction might not be modeled.

The *'s in the figure indicate that a book might be owned any
number of people, and that a person can own any number of
books.
 Bidirectional Association:
Two objects might store each other in fields.

For example, in addition to a Person object listing all the books

that the person owns, a Book object might list all the people
that own it.

bi-directional association, both classes know about each

other and with uni-directional association only one of the
classes is aware of the relationship.
 Aggregation

• A special form of association that models a

whole-part relationship between an aggregate
(the whole) and its parts.
–
Models a “is a part-part of” relationship.

2..* 1..* D
Car House
o
o
r
Whole

Part
15
UML Class Diagrams
 Aggregation (cont.)
Aggregation tests:
–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?
• A door is part of a car. A car is not part of a door.

UML Class Diagrams

 Aggregation:
One object A has or owns another object B, and/or B is part of A.

For example, suppose there are different Book objects for different
physical copies.
Then the Person object has/owns the Book object, and, while the
book is not really part of the person, the book is part of the
person's property.
In this case, each book will (usually) have one owner. Of course, a
person might own any number of books.
 Composition:
A composition in the Unified Modeling Language (UML) is a special case
of association that describes a relationship between a whole and its
existential parts. Put simply, in a composition, a part can never be larger
than the whole. An example: A building consists of rooms.

Aggregation implies a relationship where the child can exist

independently of the parent. Example: Class (parent) and
Student (child). Delete the Class and the Students still
exist. Composition implies a relationship where the child
cannot exist independent of the parent. Example: House
(parent) and Room (child).
 Composition

• A strong form of aggregation

– The whole is the sole owner of its part.
• The part object may belong to only one whole
– Multiplicity on the whole side must be zero or one.
– The life time of the part is dependent upon the whole.
• The composite must manage the creation and
destruction of its parts.

1 Circle
Circle Point

3..* Point
Polygon
UML Class Diagrams 22
 Generalization
• Indicates that objects of the specialized class
(subclass) are substitutable for objects of the
generalized class (super-class).
–
“is kind of” relationship.

{abstract} is a Shape
An abstract Super
{abstract}
tagged value that class Class
indicates that the class
is abstract. Generalization
The name of an relationship
Sub
abstract class should be Circle Class
italicized

UML Class Diagrams 24

 Inheritance Relationships

The inheritance relationships in UML match up very

closely with inheritance in Java.

Generalization:
A class extends another class.

For example, the Book class might extend the Document class,
which also might include the Email class. The Book and Email
classes inherit the fields and methods of the Document class
(possibly modifying the methods), but might add additional
fields and methods.
 Realization:
A realization relationship exists between the two classes
when one of them must realize, or implement, the behavior
specified by the other. For example, a realization
relationship connects an interface to an implementing.
class.
For example, the Owner interface might specify methods for
acquiring property and disposing of property. The Person and
Corporation classes need to implement these methods, possibly in
very different ways.
 Generalization

• A sub-class inherits from its super-class

– Attributes
– Operations
– Relationships
• A sub-class may
– Add attributes and operations
– Add relationships
– Refine (override) inherited operations
• A generalization relationship may not be
used to model interface implementation.

UML Class Diagrams 29

 Constraint Rules and Notes

• Constraints and notes annotate among other things

associations, attributes, operations and classes.

• Constraint are semantic restrictions noted as

s Boolean
expression
– s. offers many pre-defined
UML
constraints.
Customer
1 * may be
Order
{ total < $50 } canceled
id: long { value > 0 }

Constraint Note

UML Class Diagrams 30

 Traffic Violation Report System Example

TrafficReport Offender
TrafficPolicema 1 id : long 1.. 1
issues name :
n description : String *
* String id :
occuredAt : Date long

reports
of 1..*
Policeman
id : long Violation
name : String id : long
rank : int
description : String
<<abstract>
>

UML Class Diagrams 31

 Analysis Classes Elicitation

Consider main perspectives of the system

• Interface between the system and its actors
– Protocols for information exchange
– Don’t concentrate on visual aspects
• Data the system uses
– The core of the system, key concepts
• The system logic
– Controls and coordinates the behavior
– Delegates the work to other classes
– Decouples interface and data classes

UML Class Diagrams 32

 Analysis Classes

□A technique for finding analysis classes which uses three

different
perspectives of the system:
• The boundary between the system and its actors
(Boundary)
• The information the system uses (Entity)
• The control logic of the system (Control)

UML Class Diagrams 33

 Boundary Classes
• Models the interaction between system’s
the surroundings and its inner
workings
• Concentrate
– User interfaceonclasses
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

UML Class Diagrams 34

 Boundary Classes (cont.)
• Boundary classes are environment
dependent:
– UI dependent
– Communication protocol dependent

UML Class Diagrams 35

 Entity Classes

• Models the key concepts of the system

• Usually models information that is persistent
• Contains the logic that solves the system problem
• Is environment independent
• Can be used in multiple use cases

For example: Violation, Report, Offender.

UML Class Diagrams 36

 Control Classes
• Controls and coordinates the behavior of a use
case
• Delegates the work of the use case to classes
–Acontrol class should tell other classes to do
something and should never do
anything except for directing
• Control classes decouple boundary and entity
classes
• Often, there is one control class per use case

UML Class Diagrams 37