Class Diagram

Compiled By :Umm-e-Laila

Lecture 5
Course Instructors

 Umm-e-Laila ulaila2002@gmail.com
Assistant Professor, CED
Room Number: BS-04
Tel: 111-994-994, Ext. 536

 Aneeta Siddiqui aarshad@ssuet.edu.pk

Assistant Professor, CED
Room Number: BS-03
Tel: 111-994-994,
Course Website

 http://sites.google.com/site/ulaila206

3
 Class Diagrams

 The purpose of a class diagram is to represent

the classes within on OO model
 An UML class diagram represents three
different things:
 the attributes of a class
 the methods ( operation) of a class
 the relationships of a class with other classes
The Class Icon Example (1)

Person
- firstName : String
- lastName :String
- address : String
- tel : int
+ setPerson(String, String, String, int)
+ setName(String, String)
+ setAddress(String)
+ setTel(long)
+ getFirstName( ) : String
+ getLastName( ) : String
+ getAddress( ) : String
+ getTel( ) : int
+ toString( ) : String
Responsibilities
• A responsibility is a contract or an obligation of a class. When you create a class, you are
making a statement that all objects of that class have the same kind of state and the same kind
of behavior. At a more abstract level, these corresponding attributes and operations are just the
features by which the class's responsibilities are carried out.
The Class Icon (2)

Class Name
attribute : type

method( param1, param2, …, param n) : type

 The Class Icon (3)
 A class icon is a rectangle divided into three compartments
 The topmost compartment contains the name of the class
 The middle compartment contains a list of attributes
(member variables) followed by a colon and the variable
type
 The bottom compartment contains a list of methods
(member variables) followed by a list of parameter types
enclosed in braces, a colon and the method type
 Class members (e.g. variables and methods) could be
preceded by one of the following:
 the – sign for private members

 the + sign for public members

 the # sign for protected members

 no sign for friendly members

Operations

• An operation is a behavior associated with a

class

• An operation has three parts, operation

name, operation parameters and return type.

• An operation is the implementation of a

service that can be requested from any object
of the class

Operation name (argument1,argument2):returntype

add (X : integer, Y : Integer) : Integer
Types of Operation

• Implementor Operations
 implements some business functionality. They
can be found by examining Interaction diagram.

• Manager Operations
manage the creation and destruction of objects.

• Access Operations
set and get operation in a class to access
private attributes.

• Helper Operations
help other operation of the class, but cant be
access directly. Private operation of a class.
• Setting Operation Visibility
Public, Private, Protected, Package or Friendly
+ , - , # , no sign for package

• You can set stereotypes of Operations.

<<constructor>>
The Class Icon (4)

 In many diagrams, the bottom two compartments

are omitted
 The bottom two compartments normally do not
hold every single variable and method that
belongs to the class
 Only the variables and methods that are useful
for a particular diagram should be included in the
icon
 Constructors are not normally included in the
methods compartment
The Interface Icon (1)

<<interface>>
Interface Name
method( param1, param2, …, paramn) : type

Example:
<<interface>>
ActionListener
+ actionPerformed( ActionEvent) : void
 The Interface Icon (2)

 A class icon is a rectangle divided into two compartments

 The topmost compartment contains the word <<interface>>
(in order to differentiate between a class icon and an
interface icon) and the name of the interface
 The bottom compartment contains a list of methods
(member variables) followed by a list of parameter types
enclosed in braces, a colon and the method type
 Methods could be preceded by one of the following:
 the – sign for private members
 the + sign for public members
 the # sign for protected members
 no sign for friendly members
Stereotypes

Stereo typing is a way to categorize some thing in your

diagram.
Stereotype are the core extension mechanism of UML
• We can write a category name in between

<< and >> signs.

Three class stereotypes in UML
– Boundary Classes
– Control Classes <
– Entity Classes
Boundary Classes
Are those classes which lies between your system and real
world, form, reports and hardware interfaces printers and
scanners.
To find boundary classes check the use cases, at a minimum
one boundary class for every actor for interaction with
system.
Two actors can have same one boundary class.

Entity Classes
These classes saves the information in persistent storage.
You can create tables in your database for each entity class.
Control Classes

• The control class is responsible for

coordinating the efforts of other classes.
• Typically there is only one control class per
usecase.
• Control class delegates responsibility to other
classes.
• There may be other control classes that share
between several use cases. Security manager
for controlling security. Transaction manager
class for Database transaction.
• Minimize the impact of changes on system
Setting Class Visibility
Public, Private, Protected, Package or Friendly
+ , - , # , no sign for package.

Setting Class multiplicity

– n (default) many
– 0..0 Zero
– 0..1 Zero or One
– 0..n Zero or many
– 1..1 Only One
– 1..n One or many
– <number> Exactly <number>
– <number1>..<number2> Between <number1>and <number2>
– <number>..n <number> or more
– <number1>,<number2> <number1>or<number2>
– <number1>,<number2>..<number3>
 Exactly <number1>or between <number2> and <number3>
– <number1>..<number2>,<number3>..<number4>
 Between <number1> and <number2>
 or between <number3> and <number4>
Setting Class Persistence

• Persistent
The information in objects of the class will be saved to
a database or some other form of persistent storage.

• Transient
The information in objects will not be saved to
persistent storage

• Multiplicity
is an indication of how many objects may participate in
a given relationship.
Class Relationships

 Relationships provide a way for classes or

objects to communicate
 There exist four types of relationships in
UML diagrams
 Inheritance
 Composition
 Aggregation
 Association
Class Relationships

 Inheritance – an is-a relationship between

a superclass and its subclasses
 Composition – has-a relationship between
a class and its members that are objects
Class Relationships
 Aggregation is a form of a has-a relationship
where the relationship is between a whole
and its parts
 Aggregation is very similar to composition but
instead of one single object of a particular class it
can contain several objects of that class
 Association is a form of a has-a relationship
that indicates that one object (or class) uses
or refers to another object (or class) in some
way
Inheritance Diagrams (1)

public class Vehicle

{ … }

Vehicle
public class Car
extends Vehicle {
… }
public class Truck Car Truck Bike
extends Vehicle {
… }
public class Bike
extends Vehicle {
… }
Inheritance Diagrams (2)

public class myGUI

extends JApplet
Applet ActionListener
implements
ActionListener {
// class
variables // & myGUI
methods
// . . . Notice that the inheritance relationship
with an interface is represented using
} dashed arrow
Inheritance Diagrams (2)

 The inheritance relationship is represented by

a line and a triangular arrowhead
 The arrowhead points to the base class
Composition

• Composition is a variation of aggregation.

• In composition one class represent a larger thing (the

whole) which consist of smaller thing (the parts).

• Parts may be created after the whole, but once created they live
and die with the whole.

Whole Window

1 It is represented by a
Filled diamond.

*
Frame Part
Composition Diagrams (1)

public class myClass extends

Applet {
Button
private Button myButton;

// class variables & methods

// . . .
myClass
}
 Composition Diagrams (2)

 The black diamond

represents composition
 It is placed on the class Button
myClass because it is the
myClass that has a (is
composed of, contains an
instance of) a Button
 The arrow points to the
class Button – the class
that is contained into the myClass Applet
myClass
 Also the myClass is
derived from the Applet
class – so let’s combine
the two diagrams together
Aggregation

• Aggregation is a relationship between a whole and its part.

• Aggregation is a type of association.

• In aggregation one class represent a larger thing (the

whole) which consist of smaller thing (the parts).

• Aggregation represent a “has a” relationship.

Whole Company
1

*
Department Part
Aggregation Diagrams (1)

public class myClass extends Applet {

private Button myButtons[];
// class variables & methods
// . . .
}
* Button
myClass myButtons

15
myClass Button
myButtons
Aggregation Diagrams (2)

 An aggregation is shown as a line connecting the

related classes with an open diamond next to the
class representing the whole and an arrow
pointing to the class representing the “part of”
the whole
 The arrow is labelled with the name of the object
of the aggregated class below it and the number
of the objects above it
 If we do not know the exact number of the
aggregated objects we use a * above the arrow
to specify “many” objects
Association Diagrams (1)

 An association is shown as an arrow pointing

to the class that is contained within the
original class
 The arrow is labelled with a certain
stereotype to reflect the type of the
relationship between the original class and
the associated class
Association properties

• Name
An association can have a name. That describe the nature
of the relationship.

•Role
A role is just the face the class at the near end of the
association present to the class at the other end of the association.

•Multiplicity
It represent that how many objects of one class may
connect to the objects of another class.

• Navigation
 It represent the direction of association from one object to
another object. Unless specified the navigation is
 bi-directional. You can limit the navigation to just one direction.
 Works for
Person Company

Name

Person employee Company

employer

Role name
employee *
Person Company
1..* employer

Person Parent
2

Child *
 Association Diagrams Stereotypes

public class myClass {

public AssocClass makeIt {
myClass <<create>> AssocClass return new AccosClass();}
}

public class myClass {

public void f() {
myClass <<local>> AssocClass AssocClass a=new AccosClass();
}
}

myClass AssocClass public class myClass {

<<parameter>> public void f(AssocClass a) {
// use a }
myClass AssocClass }

public class myClass {

private AssocClass a;
myClass <<delegate>> AssocClass public void f() {
a.f(); }
}
Dependency

• An dependency is a using relationship, states that a change

in the specification of one thing may affect another thing
that uses it.
• A dependency can have a name.
• Dependency is rendered as a dashed directed line, directed
to the thing being dependent on.
• Dependency cannot be represented by a class attribute.
• It can be represented by global class, or instantiated as a
local variable inside an operation or passed as a
parameter to some operation.

Window
Event
 class Company

1 aggregation

attributes
* 1..* multiplicity 1..*

Department Office
Location address
name
0..1 * * phone

role generalization
member
1..* 1 manager Headquarters
ContractInformation
Person
address
name
employeeID
title
PersonnelRecord
getName
getID operations taxID
getContractInformation emplomentHistory
getPersonnelRecords salary
dependency
 role:chairperson

School Department
0..1
-name -name
-address
-phone
Has +addIntructor()
+addStudent() 1..* +removeInstructor()
1 1..*
+removeStudent() +getInstructor()
+getStudent() +getAllInstructor()
+getAllStudent()
+addDepartment()
+getDepartment() AssignedTo
+getAllDepartment()
1..* 0..1
1..*
1..*
Course Instructor
Member
name name
* Teaches
courseID
* 1..*
Student Attends *
*
name
studentID