07 Class Diagrams
07 Class Diagrams
07 Class Diagrams
Agenda
What is a Class Diagram? Essential Elements of a UML Class Diagram Packages and Class Diagrams Analysis Classes Approach Tips
A central modeling technique that runs through nearly all object-oriented methods. The richest notation in UML.
UML Class Diagrams 3
Classes
A class is the description of a set of objects having similar attributes, operations, relationships and behavior.
Class Name
Window
size: Size visibility: boolean display() hide()
5
Attributes
Operations
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 (possibly the same) class. Example: An Employee works for a Company
Employee
Department
Company
6
Associations (cont.)
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.
Associations (cont.)
Role name
instructor Association name
StaffMember
1..*
instructs
Navigable (uni-directional) association
Student
Role * pre requisites 0..3
Multiplicity
Courses
Reflexive association
UML Class Diagrams
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.
Associations (cont.)
Multiplicity
The number of instances of the class, next to which the multiplicity expression appears, that are referenced by a single instance of the class that is at the other end of the association path. Indicates whether or not an association is mandatory. Provides a lower and upper bound on the number of instances.
UML Class Diagrams 10
Associations (cont.)
Multiplicity Indicators
Exactly one 1
* (0..*)
1..* 0..1 2..4
2, 4..6, 8
11
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.
Car 2..*
Door
1..*
House
Whole
Part
12
Aggregation (cont.)
Aggregation tests:
Is the phrase part of used to describe the relationship?
A door is part of a car
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 13
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.
Circle Polygon
Point
3..*
Circle
Point
14
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
Generalization
tagged value that indicates that the class is abstract. The name of an abstract class should be italicized
Shape
{abstract}
Super Class
Circle
Sub Class
15
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
Dependency
A dependency indicates a semantic relation between two or more classes in which a change in one may force changes in the other although there is no explicit association between them. A stereotype may be used to denote the type of the dependency.
Iterator
<<friend>>
Vector
17
Realization
A realization relationship indicates that one class implements a behavior specified by another class (an interface or protocol). An interface can be realized by many classes. A class may realize many interfaces.
LinkedList
<<interface>>
List
UML Class Diagrams
LinkedList
List
18
Order
Constraint
UML Class Diagrams
Note
19
TVRS Example
TrafficPoliceman 1 issues * TrafficReport id : long description : String occuredAt : Date reports of 1..* Policeman id : long name : String rank : int <<abstract>> 1..* 1 Offender name : String id : long
Violation
id : long description : String
20
UML Packages
A package is a general purpose grouping mechanism.
Can be used to group any UML element (e.g. use case, actors, classes, components and other packages.
Commonly used for specifying the logical distribution of classes. A package does not necessarily translate into a physical sub-system. Name
21
Logical distribution of classes is inferred from the logical architecture of the system.
UML Class Diagrams 22
23
a
a.A
b.b
b.b.E b.b.D a.B
b.a.G a.C
24
Analysis Classes
A technique for finding analysis classes which uses three different perspectives of the system:
The boundary between the system and its actors The information the system uses The control logic of the system
25
Boundary Classes
Models the interaction between the systems surroundings and its inner workings
User interface classes
Concentrate on what information is presented to the user Dont concentrate on user interface details Example:
ReportDetailsForm ConfirmationDialog
26
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 Example: Violation, Report, Offender.
UML Class Diagrams 27
Controls and coordinates the behavior of the system Delegates the work to other classes
A control class should tell other classes to do something and should never do anything except for directing
Control Classes
TVRS Example
ReportDetailsForm <<boundary >> 1 1 Of f endersDBProxy <<boundary >> Of f endersDB EditReportController <<control>> Clerk Conf irmationDialog <<boundary >> 1 1 Traf f icReport 1 PolicemanDBProxy <<boundary >> PolicemenDB
Violation
Of f ender
Traf f icPoliceman
29
Tips
Dont try to use all the various notations. Dont draw models for everything, concentrate on the key areas. Draw implementation models only when illustrating a particular implementation technique.
30