class diagrams elements and description with examples..

1. Object Oriented Analysis &
Design
Lecture 16
Class Diagrams
Sajiya Tariq

2. 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

3. 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

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 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

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. Class Operations and Methods
8

9. Comments
• represented as a 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. Generalization Relationship
11

12. Associational Relationship
12

13. Multiplicity of associations
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. Composition/aggregation
example
15

16. Class diagram example:Video
Store
16