UML Class Diagrams

Agenda
What is a Class Diagram? Essential Elements of a UML Class Diagram Packages and Class Diagrams Analysis Classes Approach Tips

UML Class Diagrams

What is a Class Diagram?

A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them.
A graphical representation of a static view on declarative static elements.

A central modeling technique that runs through nearly all object-oriented methods. The richest notation in UML.
UML Class Diagrams 3

Essential Elements of a UML Class Diagram

Class Attributes Operations Relationships
Associations Generalization Dependency Realization

Constraint Rules and Notes

UML Class Diagrams 4

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

Attributes
Operations

UML Class Diagrams

UML Class Diagrams

Names
A class name must be unique within its enclosingpackage, as discussed in Chapter 12. Every class must have a name that distinguishes it from other classes. A name is a textual string. That name alone is known as a simple name; a path name is the class name prefixed by the name of the package in which that class lives. A class may be drawn showing only its name.

UML Class Diagrams

Names

UML Class Diagrams

Names
A class name may be text consisting of any number of letters, numbers, and certain punctuation marks (except for marks such as the colon, which is used to separate a class name and the name of its enclosing package) and may continue over several lines. Class names are short nouns or noun phrases drawn from the vocabulary of the system you are modeling. Capitalize the first letter of every word in a class name, as in Customer or TemperatureSensor.
UML Class Diagrams 9

Attributes
Attributes arerelated to the semantics ofaggregation. An attribute is a named property of a class that describes a range of values that instances of the property may hold. A class may have any number of attributes or no attributes at all. An attribute represents some property of the thing you are modeling that is shared by all objects of that class. For example, every wall has a height, width, and thickness; you might model your customers in such a way that each has a name, address, phone number, and date of birth. An attribute is therefore an abstraction of the kind of data or state an object of the class might encompass. At a given moment, an object of a class will have specific values for every one of its class's attributes. Graphically, attributes are listed in a compartment just below the class name.
10

UML Class Diagrams

UML Class Diagrams

11

 An attribute name may be text, just like a class name. In practice, an attribute name is a short noun or noun phrase that represents some property of its enclosing class. Typically, you capitalize the first letter of every word in an attribute name except the first letter, as in name or loadBearing.
UML Class Diagrams 12

You can specify other features of anattribute, such as marking it read-only or shared by all objects of the class You can further specify an attribute by stating its class and possibly a default initial value, as shown

UML Class Diagrams

13

Operations
An operation is the implementation of a service that can be requested from any object of the class to affect behavior. An operation is an abstraction of something you can do to an object and that is shared by all objects of that class. A class may have any number of operations or no operations at all. Graphically, operations are listed in a compartment just below the class attributes. Operations may be drawn showing only their names,
UML Class Diagrams 14

An operation name may be text, just like a class name. In practice, an operation name is a short verb or verb phrase that represents some behavior of its enclosing class. Typically, you capitalize the first letter of every word in an operation name except the first letter, as in move or isEmpty.

UML Class Diagrams

15

UML Class Diagrams

16

 When drawing a class, you don't have to show every attribute and every operation at once. In fact, in most cases, you can't (there are too many of them to put in one figure) and you probably shouldn't (only a subset of these attributes and operations are likely to be relevant to a specific view). For these reasons, you can elide a class, meaning that you can choose to show only some or none of a class's attributes and operations. An empty compartment doesn't necessarily mean there are no attributes or operations, just that you didn't choose to show them. You can explicitly specify that there are more attributes or properties than shown by ending each list with an ellipsis ("...").
UML Class Diagrams 17

UML Class Diagrams

18

Responsibilities

UML Class Diagrams

19

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

UML Class Diagrams

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

UML Class Diagrams

21

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

22

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 23

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 24

Associations (cont.)
Multiplicity Indicators
Exactly one 1

Zero or more (unlimited)

One or more Zero or one (optional association) Specified range

* (0..*)
1..* 0..1 2..4

Multiple, disjoint ranges

UML Class Diagrams

2, 4..6, 8
25

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

UML Class Diagrams

26

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 27

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
28

UML Class Diagrams

 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

An abstract class Generalization relationship

Shape
{abstract}

Super Class

Circle

Sub Class
29

UML Class Diagrams

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 30

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
31

UML Class Diagrams

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
32

Constraint Rules and Notes

Constraints and notes annotate among other things associations, attributes, operations and classes. Constraints are semantic restrictions noted as Boolean expressions.
UML offers many pre-defined constraints.
Customer
id: long { value > 0 } 1 { total < $50 } * may be canceled

Order

Constraint
UML Class Diagrams

Note
33

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

UML Class Diagrams

34

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

UML Class Diagrams

35

Logical Distribution of Classes

Emphasize the logical structure of the system (High level view)
Higher level of abstraction over classes. Aids in administration and coordination of the development process. Contributes to the scalability of the system.

Logical distribution of classes is inferred from the logical architecture of the system.
UML Class Diagrams 36

Packages and Class Diagrams (cont.)

Add package information to class diagrams
A F E G C D B

UML Class Diagrams

37

Packages and Class Diagrams (cont.)

Add package information to class diagrams
b
b.a
b.a.F

a
a.A

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

b.a.G a.C

UML Class Diagrams

38

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

UML Class Diagrams

39

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

System / Device interface classes

Concentrate on what protocols must be defined. Dont concentrate on how the protocols are implemented UML Class Diagrams

40

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 41

 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

Control classes decouple boundary and entity classes Example:

EditReportController AddViolationController
UML Class Diagrams 42

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

UML Class Diagrams

43

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.

UML Class Diagrams

44