LECTURE 2 : CLASS MODELLING

•Class representation in UML

•Relationship
•Class diagram

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14

 LEARNING OUTCOMES
• At the end of this course the student would be able to :-
– Describe the class using UML notation
– Define class relationship
– Model the classes using UML class diagram

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 2

 OBJECTS – A RECAP
• Something that make sense to the application
– US Version Monopoly Board
– iPod Token
– Board Walk title deed

• All objects have identity, state and behavior.

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 3

 CLASS – A RECAP
• A collection of objects with similar states/characteristics and behavior.
• Can you identify class from this monopoly board game?

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 4

 DIAGRAMMING CLASS

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 5

 CLASS DIAGRAMS
• Represents the basics of Object Oriented System.
– Identify what classes they are, how they interrelate and interact.
• Capture structure of object oriented system
– Support architectural system

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 6

 CASE STUDY – MONOPOLY GAME

Community
chest card

Property Deeds
Banker

Hotel
Monopoly
Board
Supply Money

Dices
Chance card Tokens

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 7

 CLASS DIAGRAM AT GLANCE

Class
Association

TitleDeed
Token 1 1 Player
+selectedTokenpicks +player +player 1
1
+titleDeed Role
has
Generalization buy

+ownProperty +property
PropertyOwner 1
0..*
Composition
Aggregation Property

develop

+buildings 1..*
builds on
Building Street Utility RailwayStation
1..*

House Hotel Multiplicity

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 8

 HOW??
• What is/are the tangible object(s) that you can identify from the Monopoly
Game?
• What is/are the intangible object(s) that you can identify from the Monopoly
Game?
• What are the classes that you can identify from the Monopoly game?

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 9

 CLASS
• A group of objects that have something in common.
– Similar properties
– Common behavior
– Common relationships to other classes
• Class is blueprint for a set of objects.
– Objects are instance of class

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 10

 STRUCTURE OF CLASS

Class Name Class name

+Attribute1
+Attribute2
Attributes
+Attribute3
Visibility +Attribute4
+Operation1()
+Operation2() Operations
+Operation3()
+Operation4()

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 11

 CASE STUDY : CLASS CARD

Player
-name: String
-selectedToken: Token
-totalSupplyMoney: Float = 0
+setName(playerName: String): void
+getName(): String
+setSelectedToken(Token: token): void
+getToken(): Token
+setSupplyMoney(money: Float): void
+getSupplyMoney(): Float
+updateSupplyMoney(amount: Float): void

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 12

 ATTRIBUTES
• Describe property of a class.
• Full form of attribute

visibility name : type = default-value

- totalSupplyMoney : float = 0

• The attribute do not have multiplicity if the multiplicity is not specified.

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 13

 OPERATIONS
• Actions that a class knows how to carry out.
• Full form of operations

visibility name (parameter-list) : return-type

+ updateSupplyMoney (float money) : void

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 14

 VISIBILITY
• Private (–)
– Only this class can see this.
• Package (~)
– Only class from the same package can see this Public
• Protected (#)
Protected
– Only subclasses can see this.
• Public (+) Package
– Every other class can see this.

Private

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 15

 GETTER AND SETTER METHODS
• Applies on private attributes.
• To allow accessing private data in a ‘special way’
• Setter – to put value into a field
• Getter – return a value from a field

Player
-name: String
-selectedToken: Token
-totalSupplyMoney: Float = 0
+setName(playerName: String): void
+getName(): String
+setSelectedToken(Token: token): void
+getToken(): Token
+setSupplyMoney(money: Float): void
+getSupplyMoney(): Float

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 16

 CONNECTING OBJECTS

1
DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 7
 ASSOCIATION
• Association represents conceptual relationships between classes.

Player selects the available token.

Player selects Token

associations

• In UML, association is represent using a solid thick line.

• Common usage for domain modeling
• Usually excluded (but still legal though)

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 18

 NAVIGABILITY
• Association indicates an instance one class must know about the other one in
order to perform its work.
• Two types of navigability
– Unidirectional association
– Bidirectional association

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 19

 UNIDIRECTIONAL ASSOCIATION
• Unidirectional represented using solid arrow.
• One end is aware of the other

Player picks Token

Interpreted as :-

•Player has the responsibility to tell which token he pick but

token no corresponding ability to tell which player it has.

•Player is aware of token existence.

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 20

 BIDIRECTIONAL ASSOCIATION
• Bidirectional is represent using solid arrow at both end.
• Both ends are aware of each other existence.

owning
Player Token

Interpreted as :-

•Player has the responsibility to tell which token he owns and

token has the ability to tell which player is owning it.

•Player and Token is aware of each other existence.

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 21

 MULTIPLICITY
• Multiplicity indicates how many object participate in the relationship

Player picks Token

1 1

Interpreted as :-
One player object can picks only one token object.

Player buy
Property
1 0..*

Interpreted as :-
One player object buys no property or more property.

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 22

 RANGE OF MULTIPLICITY
• Single
– Any single number
– * indicate infinity
• Range
– Example : 2...4, 0 ... *, 1 .. *
• A discrete set
– Example : 2,4

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 23

 ROLE NAMES
• Attached name to the end of the association to clarify its name

role role

Player +player picks +selectedToken Token

1 1

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 24

 OBJECT AS CLASS ATTRIBUTE
• Primitive type : int, double, float, char, boolean (in some language)
• String – not primitive.
• Object can be class property
class

Player
Token
-name: String
-name: String
-selectedToken: Token
-currentSpace: Integer
-totalSupplyMoney: Float = 0

object

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 25

 OBJECT MEMBER MULTIPLICITY
• How do you represent object member multiplicity for the case below?

Player +player buy +ownProperty

Property
1 0..*

Player
-name: String
-selectedToken: Token
-totalSupplyMoney: Float = 0
-ownProperty: Property[0..*]

+setName(playerName: String): void

+getName(): String
+setSelectedToken(Token: token): void
+getToken(): Token
+setSupplyMoney(money: Float): void
+getSupplyMoney(): Float

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 26

 SUPER MODELLING

2
DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 7
 GENERALIZATION
• A relationship between general object to more specialized object.
• Realization of inheritance
• General object -> super class, base class
• Specialized object -> sub class, derived class
• is-a relationship
– is-kind-of relationship

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 28

 ANATOMY OF GENERALIZATION

Player
Super class

is-a relationship

PropertyOwner Sub class

Interpreted as :-
•PropertyOwner is a kind of Player.
•PropertyOwner can develop property.
•PropertyOwner inherits all public (package and protected)
attributes and methods from Player.
•Every PropertyOwner is a Player.

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 29

 GENERALIZATION

Player
-name: String
-selectedToken: Token
-totalSupplyMoney: Float = 0 Interpreted as :-
+setName(playerName: String): void
+getName(): String
+setSelectedToken(Token: token): void •Player can buy property.
+getToken(): Token
+setSupplyMoney(money: Float): void •When Player buy property, he
+getSupplyMoney(): Float
+updateSupplyMoney(amount: Float): void is a PropertyOwner.
•Only PropertyOwner can
develop House or Hotel on the
street.
•Only PropertyOwner can
PropertyOwner
mortgage house, hotel, utilities
-house: House[1..*]
-hotel: Integer[0..1] and/railroad.
-utilities: Utility[0..*]
-railroad: Railroad[0..*] •PropertyOwner is-a Player.
+developHouse(noOfHouses: Integer): void
+developHotel(): void
+mortgageHouse(street: Street): Float
+mortgageHotel(street: Street): Float
+mortgageUtilities(): Float
+mortgageRailroad(): Float

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 30

 RICHER RELATIONSHIP

3
DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 1
 Variants of Relationships
• Relationships is not limited to directional association and
generalization.

• Each type of relationship bring different meaning to the

model.

• Some of the object may function if we remove it from the

other object. Some may not.
– Can you remove your legs and the legs still function by it self?

3
2
DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14
 Advanced Relationship
• Therefore, a richer relationship is needed to describe the
model precisely.

• This topic covers

– Aggregation
– Composition
– Dependency

3
3
DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14
 Part and Whole
• Some object is made up from many objects.
• In this case there are part-of object and whole-object.
• For example, a Car is made of Window, Door, Tire, Engine
etc.

Whole Object Part-of Object

3
4
DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14
 AGGREGATION
• is-part-of relationship (or is-made-of)
• Represent by solid line and hollow diamond-end
• Part-object and whole-object relationship

Owner Station
-name: String 1..* -location: String
-capital: float
-stationOwned: Station[1..*] -stationOwned +setLocation(String location): void
+getLocation(): String
+setName(String name): void owns
+getName(): String
+setCapital(float capital): boolean
+getCapital(): float

Whole-object Aggregation
Part-object

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 35

 COMPOSITION
• Stronger version of aggregation
• Represent by solid line and filled diamond-end
• The part may belong to only one whole object.
• The part-object may live and die with the whole object.

Property
-Name: String
-Price: Float Interpreted as :-
-Group: String
+DisplayProperty() Player buy a Property and the
+property
TitleDeed is given to the player.
1
When PropertyOwner mortgage the Property
has to the bank, the TitleDeed is given to the
Bank.
+titleDeed 1

TitleDeed The existance of TitleDeed is fully

-RentalRate: Float[1..*] depends on Property. If the owner of the
-MortgageRate: Float[1..*]
Property changed, so will the TitleDeed.
+getRentalRate(noOfProperty: Integer): Float
+getMortgageRate(noOfProperty: Integer): Float

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 36

 DEPENDENCY
• At time, we need to use other object but not as member of the class.
• An object can be passed as a parameter of a methods.
• This can be modeled using Dependency in UML
• Using relationship and indicated with dotted arrow.
• Change of the specification of one thing may affect another thing that uses it.

Queue
-player: Player[0..*] Player

+push(player: Player): void

+pop(): Player

Interpreted as :-
The Player is visible to push() method. Thus, this is
some kind of dependency.

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 37

 SUMMARY OF CLASS RELATIONSHIPS

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14 38

 What Have You Learn Today?
Learning Outcomes Check Yourself Checked
i. Model objects and classes i. Create other classes in Monopoly
using UML notation Game using UML notation.
(Complete with instance variables
and methods)
ii. Model relationships of i. Connects all classes using
objects and classes using relationship.
UML notation ii. Give name and degree for the
relationship.
iii. Produce UML class i. Refine classes, relationships and
diagram produce class diagram.

3
9
DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14
END OF LECTURE 2

DITP 3113 OBJECT ORIENTED PROGRAMMING SEM I 13/14