Object Oriented Analysis &
Design
Lecture 16
Class Diagrams
Sajiya Tariq
Overview
•The class diagram is a static diagram. It
represents the static view of an application.
•The class diagram describes the attributes and
operations of a class and also the constraints
imposed on the system.
•The only UML diagrams which can be mapped
directly with object oriented languages.
•The class diagram shows a collection of classes,
interfaces, associations, collaborations and
constraints. It is also known as a structural
diagram.
2
Purpose
The purpose of the class diagram can be
summarized as:
•Analysis and design of the static view of
an application.
•Describe responsibilities of a system.
•Base for component and deployment
diagrams.
•Forward and reverse engineering.
3
Points to remember
• The name of the class diagram should be meaningful to
describe the aspect of the system.
• Each element and their relationships should be identified in
advance.
• Responsibility (attributes and methods) of each class should
be clearly identified.
• For each class minimum number of properties should be
specified. Because unnecessary properties will make the
diagram complicated.
• Use notes when ever required to describe some aspect of
the diagram. Because at the end of the drawing it should be
understandable to the developer/coder.
• Finally, before making the final version, the diagram should
be drawn on plain paper and rework as many times as
possible to make it correct.
4
UML Class Diagram
• What is a UML class diagram?
▫ UML class diagram: a picture of
▫ the classes in an OO system
▫ their fields and methods
▫ connections between the classes that interact or inherit from
each other
• What are some things that are not represented in a UML
class diagram?
▫ details of how the classes interact with each other
▫ algorithmic details; how a particular behavior is
▫ implemented
5
Diagram of one Class
• class name in top of box
▫ write <<interface>> on top of
interfaces' names
▫ use italics for an abstract class
name
• Attributes (optional)
▫ should include all fields of the
object
• Operations / methods (optional)
▫ may omit trivial (get/set) methods
 but don't omit any methods from an
interface!
▫ should not include inherited
methods
6
Class Attributes
• attributes (fields, instance variables)
▫ visibility name : type [count] =
default_value
▫ visibility: + public
# protected
- private
~ package (default)
/ derived
▫ underline static attributes
▫ derived attribute: not stored, but can be
computed from other attribute values
▫ attribute example:
 balance : - = double 0.00
7
Class Operations and Methods
8
Comments
• represented as a folded note, attached to the
appropriate class/method/etc by a dashed line
9
Relationships btwn. classes
•generalization: an inheritance
relationship
▫inheritance between classes
▫interface implementation
•association: a usage relationship
▫dependency
▫aggregation
▫composition
10
Generalization Relationship
11
Associational Relationship
12
Multiplicity of associations
13
Association types
• aggregation: "is part of"
▫ symbolized by a clear white
diamond
• composition: "is entirely made of"
▫ stronger version of aggregation
▫ the parts live and die with the
whole
▫ symbolized by a black diamond
• dependency: "uses temporarily"
▫ symbolized by dotted line
▫ often is an implementation detail,
not an intrinsic part of that
object's state
14
Composition/aggregation
example
15
Class diagram example:Video
Store
16

Ooad( class diagram)

  • 1.
    Object Oriented Analysis& Design Lecture 16 Class Diagrams Sajiya Tariq
  • 2.
    Overview •The class diagramis a static diagram. It represents the static view of an application. •The class diagram describes the attributes and operations of a class and also the constraints imposed on the system. •The only UML diagrams which can be mapped directly with object oriented languages. •The class diagram shows a collection of classes, interfaces, associations, collaborations and constraints. It is also known as a structural diagram. 2
  • 3.
    Purpose The purpose ofthe class diagram can be summarized as: •Analysis and design of the static view of an application. •Describe responsibilities of a system. •Base for component and deployment diagrams. •Forward and reverse engineering. 3
  • 4.
    Points to remember •The name of the class diagram should be meaningful to describe the aspect of the system. • Each element and their relationships should be identified in advance. • Responsibility (attributes and methods) of each class should be clearly identified. • For each class minimum number of properties should be specified. Because unnecessary properties will make the diagram complicated. • Use notes when ever required to describe some aspect of the diagram. Because at the end of the drawing it should be understandable to the developer/coder. • Finally, before making the final version, the diagram should be drawn on plain paper and rework as many times as possible to make it correct. 4
  • 5.
    UML Class Diagram •What is a UML class diagram? ▫ UML class diagram: a picture of ▫ the classes in an OO system ▫ their fields and methods ▫ connections between the classes that interact or inherit from each other • What are some things that are not represented in a UML class diagram? ▫ details of how the classes interact with each other ▫ algorithmic details; how a particular behavior is ▫ implemented 5
  • 6.
    Diagram of oneClass • class name in top of box ▫ write <<interface>> on top of interfaces' names ▫ use italics for an abstract class name • Attributes (optional) ▫ should include all fields of the object • Operations / methods (optional) ▫ may omit trivial (get/set) methods  but don't omit any methods from an interface! ▫ should not include inherited methods 6
  • 7.
    Class Attributes • attributes(fields, instance variables) ▫ visibility name : type [count] = default_value ▫ visibility: + public # protected - private ~ package (default) / derived ▫ underline static attributes ▫ derived attribute: not stored, but can be computed from other attribute values ▫ attribute example:  balance : - = double 0.00 7
  • 8.
  • 9.
    Comments • represented asa folded note, attached to the appropriate class/method/etc by a dashed line 9
  • 10.
    Relationships btwn. classes •generalization:an inheritance relationship ▫inheritance between classes ▫interface implementation •association: a usage relationship ▫dependency ▫aggregation ▫composition 10
  • 11.
  • 12.
  • 13.
  • 14.
    Association types • aggregation:"is part of" ▫ symbolized by a clear white diamond • composition: "is entirely made of" ▫ stronger version of aggregation ▫ the parts live and die with the whole ▫ symbolized by a black diamond • dependency: "uses temporarily" ▫ symbolized by dotted line ▫ often is an implementation detail, not an intrinsic part of that object's state 14
  • 15.
  • 16.