UML Class Diagram

Some parts adopted from slides by Zvika Gutterman and Adam Carmi
2 Objectives
 Learn about UML Class Diagrams
3
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.
 Provides a static picture of the pieces in the system
and of the relationships between them.
 Essential Elements of a UML Class
4
Diagram
 Class
 Attributes
 Operations
 Relationships
 Associations
 Aggregation
 Composition
 Generalization
 Dependency
 Realization
 Constraint Rules and Notes
5
Classes
 A class is a classifier which describes a set of objects that share:
 Similar properties (attributes)
 Example: An employee has: a name, employee#, and
department;
 Common behavior (operations)
 Example: An employee is hired, and fired;
 Common relationships to other objects, and common
meaning (“semantics”).
 Example: An employee works on one or more projects
6
Classes

Class Name
Window

size: Size
Attributes visibility: boolean

Operations display()
hide()

Enterprise Architect
7
Class Name
class Analysis View
 Every class must have a unique name

StaffMember

 Each class has instances that represent particular individuals

that have the properties of the class.
 For example: George, Nazim, Ahmed,… may be instances of
StaffMember.
8
Class Attributes
 Each class can have attributes which represent useful
information about instances of a class.
 Each attribute has a type. class Analysis View

StaffMember

- StaffID: int
- StaffName: String

 For example, StaffMember has attributes StaffID and

StaffName.
9
Class Operations
 Often derived from action verbs in use case descriptions or
problem statements.
 Operations describe what can be done with the instances of
a class.
 For example, For the class Stone, we may want to associate
operations Throw(), Kick() and WriteOn().
 Some operations will carry out processes to change or do
calculations with the attributes of an object.
 For example, we can changeclass
the password
Analysis View of a StaffMember.
StaffMember

- Password: short
- StaffID: int
- StaffName: String

+ ChangePassword()
10
Class Operations
 Each operation has a signature, which specifies the types of its
parameters and the type of the value it returns (if any).
11
Class Operations
 Attributes and operations can be declared with different visibility
modes:
+ public: any class can use the feature (attribute or operation);
# protected: any descendant of the class can use the feature;
- private: only the class itself can use the feature.
class Analysis View

private
StaffMember

- Password: short
protected # StaffID: int
+ StaffName: String

public - ChangePassword()
12
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.
 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.
 Example: “A StaffMember manages a Campaign”

manages
StaffMember Campaign
13 Associations Multiplicity
 The number of instances of the class, 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.
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..10

14
Association Multiplicity and Name
15 Association Navigation
 Sometimes we want to model explicitly the fact that
an association is unidirectional.
 In a unidirectional association, two classes are related,
but only one class knows that the relationship exists.
 Example: Given a person’s full name, you can get the
person’s telephone number, but not the other way around.
 Unidirectional Navigation Example
16

 The unidirectional association only contains the role

name and multiplicity value for the known class.
 The OverdrawnAccountsReport knows about the
BankAccount class, and the BankAccount class plays the
role of "overdrawnAccounts."
 However, the BankAccount class has no idea that it is
associated with the OverdrawnAccountsReport.
17 Associations and Roles
 We can name explicitly the role a class in an
association.
 The same class can play the same or different roles in
other associations.

Reflexive Association
18 Association Class
 Sometimes we want to treat an association between two classes, as
a class in its own right, with its own attributes and operations.
19
Another Example of Association Class

Association Name
Association Multiplicity
Association Class ( if needed)

Order
-orderQuantity: int = 0
-orderDate: Date = today
-orderTerms: Terms=NULL

order
Customer 0..* 0..* Product
20 Aggregation
 An aggregation is a stronger form of association.
 This is the Has-a or Whole/part relationship, where one object
is the “whole”, and the other (one of) the “part(s)”.
 Diamond should be towards the whole

2..* 1..*
Car Door House

Whole Part
21 Composition
 A strong form of aggregation
 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 Point

3..*
Polygon
22 Aggregation vs. Composition
23 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

 Called also specialization because the subclass is a

specialization of the more generic super class
24
Generalization (Cont.)
 Indicates that objects of the specialized class (subclass) are
substitutable for objects of the generalized class (super-class).
 “is kind of” relationship.

The child has all the

characteristics of a parent and it Student
might specialize them
Notation:

Undergrad Graduate

Master PhD
25 Examples
26 Examples
27 Dependency
 The least formal relationship between classes.
 Indicates that one class depends on another because it
uses it at some point in time.
 Example: Class A depends on Class B in some way.
28 Dependency
29 Realization
 A realization relationship indicates that one class implements
a behavior specified by another class (an interface).
 An interface can be realized by many classes.
 A class may realize many interfaces.
 A class can have an actual instance of its type, whereas an
interface must have at least one class to implement

<<interface>>
LinkedList List

LinkedList List
30
Advance Topics
31 Constraint Rules and Notes
 Constraints and notes annotate among other things
associations, attributes, operations and classes.
 Constraints are semantic restrictions noted as
Boolean expressions.

Customer 1 * may be
Order
{ total < $50 } canceled
id: long { value > 0 }

Constraint Note
 32 Expressing Constraints
 UML specification does not restrict languages
which could be used to express constraints:
 OCL, Java, natural language, etc.
 OCL is a constraint language predefined in UML

Constraint that applies to two elements (dashed lin

Constraint that applies to a single element
33 Expressing Notes
 The constraint string may be placed in a note symbol
(same as used for comments) and attached to each
of the symbols for the constrained elements by a
dashed line.
34
UML Packages
 A package is a general purpose grouping mechanism.
 Can be used to group any UML element (e.g. use cases,
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
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.
36 Packages and Class Diagrams
(cont.)
 Add package information to class diagrams

E D B

C
37 Packages and Class Diagrams
(cont.)
 Add package information to class diagrams

b a
b.a a.A

b.a.F
b.b

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

b.a.G

a.C
38 Packages and Class Diagrams
(cont.)
39 Syntactic Best Practice of Class
 Diagrams
Limit the number of classes in a single diagram.
 Divide large diagrams into smaller ones
 Naming:
 Class: domain-specific noun
 Operations: with a strong action verb
 Attributes: descriptive noun
 Level of details
 Analysis-level vs. Design-level
 Do not mix them!
 Preferable arrangement of relations
 Associations: horizontal
 Generalizations: vertical