What is Object Oriented

Programming?

Classes
A class is a description of a set of
ClassName objects that share the same attributes,
operations, relationships, and semantics.
attributes
Graphically, a class is rendered as a
rectangle, usually including its name,
operations attributes, and operations in separate,
designated compartments.
1
Class Names
The name of the class is the only required
ClassName tag in the graphical representation of a
class. It always appears in the top-most
attributes compartment.

operations

2
Class Attributes
Person

name : String An attribute is a named property of a

address : Address class that describes the object being modeled.
birthdate : Date In the class diagram, attributes appear in
ssn : Id the second compartment just below the
name-compartment.

3
Class Attributes (Cont’d)
Attributes are usually listed in the form:
Person attributeName : Type

name : String A derived attribute is one that can be

address : Address computed from other attributes, but
birthdate : Date doesn’t actually exist. For example,
/ age : Date a Person’s age can be computed from
ssn : Id his birth date. A derived attribute is
designated by a preceding ‘/’ as in:

/ age : Date

4
Class Attributes (Cont’d)
Person

Attributes can be:

+ name : String
+ public
# address : Address
# protected
# birthdate : Date
- private
/ age : Date
/ derived
- ssn : Id

5
Class Operations
Person

name : String
address : Address
birthdate : Date
ssn : Id
eat Operations describe the class behavior
sleep and appear in the third compartment.
work
play

6
Class Operations (Cont’d)
PhoneBook

newEntry (n : Name, a : Address, p : PhoneNumber, d : Description)

getPhone ( n : Name, a : Address) : PhoneNumber

You can specify an operation by stating its signature: listing the

name, type, and default value of all parameters, and, in the case of
functions, a return type.

7
Depicting Classes
When drawing a class, you needn’t show attributes and operation
in every diagram.

Person Person Person

name : String
birthdate : Date
Person ssn : Id
name Person eat()
address sleep()
birthdate eat work()
play play()

8
Class Responsibilities
A class may also include its responsibilities in a class diagram.

A responsibility is a contract or obligation of a class to perform

a particular service.

SmokeAlarm

Responsibilities

-- sound alert and notify guard station

when smoke is detected.

-- indicate battery state

9
What is Object Oriented
Programming?

 Identifying objects and

assigning responsibilities to
these objects.
 Objects communicate to
An object is like a
other objects by sending
black box.
messages.
The internal  Messages are received by
details are
the methods of an object
hidden.

10
What is an object?

 Tangible Things as a car, printer, ...

 Roles as employee, boss, ...
 Incidents as flight, overflow, ...
 Interactions as contract, sale, ...
 Specifications as colour, shape, …

11
So, what are objects?

 an object represents an individual,

identifiable item, unit, or entity, either
real or abstract, with a well-defined role
in the problem domain.
Or
 An "object" is anything to which a
concept applies.
Etc.
12
Why do we care about
objects?

 Modularity - large software projects

can be split up in smaller pieces.
 Reuseability - Programs can be
assembled from pre-written software
components.
 Extensibility - New software
components can be written or
developed from existing ones.
13
Example: The Person class
#include<string>
#include<iostream>
class Person{
char name[20]; private
int yearOfBirth; data
public:
void displayDetails() {
cout << name << " born in "
<< yearOfBirth << endl;
}
public
//... processes
};
The two parts of an object

Object = Data + Methods

or to say the same differently:

An object has the responsibility to know and

the responsibility to do.

= +
15
Basic Terminology:
Behaviour and Messages

 The most important aspect of an object is

its behaviour (the things it can do). A
behaviour is initiated by sending a
message to the object (usually by calling
a method).

16
Interfaces
An interface is a named set of
operations that specifies the behavior
<<interface>> of objects without showing their inner
ControlPanel structure. It can be rendered in the
model by a one- or two-compartment
rectangle, with the stereotype
<<interface>> above the interface
name.

17
Interface Services

<<interface>> Interfaces do not get instantiated.

ControlPanel They have no attributes or state.
Rather, they specify the services
getChoices : Choice[] offered by a related class.
makeChoice (c : Choice)
getSelection : Selection

18
Interface Realization Relationship

A realization relationship
<<interface>>
connects a class with an
ControlPanel
interface that supplies its
specifier behavioral specification. It is
rendered by a dashed line with
a hollow triangle towards the
specifier.
implementation

VendingMachine

19
Interfaces
inputStream

FileWriter
{file must not be locked}

A class’ interface can also be

rendered by a circle
File
connected to a class by a
solid line.

{file must exist}

FileReader
outputStream

20
Encapsulation

 combination of state and behavior

 implementation details are hidden internally
 internal mechanisms can change while public
interfaces remain stable
 state may be retrieved using public methods
 behavior consists of methods activated by
receipt of messages

21
 Inheritance
 organization of classes into a hierarchical
inheritance tree
 data and behavior associated with classes
higher in the tree are accessible to those
classes lower in the tree
 terminology
 ancestor/descendant
 superclass/subclass
 generalization/specialization

22
Single Inheritance

 classes/objects inherit from only one

parent
 no ambiguity due to name clashes
 examples: Java, Smalltalk

23
Multiple Inheritance

 classes/objects may have more than one

parent
 ambiguity (name clashes) can occur
 allows abstract classes to be more specific
in characteristics (kitchen sink problem)
 examples: C++, Eiffel

24
Inheritance Diagram

25
Another Inheritance
Diagram

26
Noun analysis
Consider a simplified vending machine, which is used to dispense soft
drinks. The vending machine consists of a coin slot for inserting coins,
a return tray for returning the customer's money and three buttons
used to select Pepsi (tm), Coke (tm) or Dr. Pepper (tm). If the customer
inserts coins and does not press a button within one minute, the coins
will be returned automatically (no coin-return lever). If the customer
selects a beverage which is out-of-stock (none left), the coins will also
be returned. This vending machine does not provide change - it is up to
the customer to insert only enough money to purchase a drink. If
sufficient coins are inserted and a button with available beverages is
pressed, the appropriate drink is dispensed, the corresponding button is
illuminated for five seconds, and the coin slot moves the coins to the
general storage area (i.e. the purchase has finished).

27
 Domain Model - Initial Class
Diagram

Inserts
Contains
coins CoinSlot 1 1 0..*
into  Contains
amount 3 Shelf Drink
1 1
1
Vending Contains
1
Customer Machine 1
1
Button
Pushes Contains
id
3 Contains 1
litUp
ReturnTray

28
CRC Card Layout.

29
30
So how do you create CRC models?
 Iteratively perform the following
steps:

 Find classes.  Finding classes is fundamentally an analysis task

because it deals with identifying the building blocks for your
application. A good rule of thumb is that you should look for the
three-to-five main classes right away, such as Student, Seminar,
and Professor in Figure . I will sometimes include UI classes such
as Transcript and Student Schedule, both are reports, although
others will stick to just entity classes. Also, I'll sometimes include
cards representing actors when my stakeholders are struggling with
the concept of a student in the real world (the actor) versus the
student in the system (the entity).
 Find responsibilities.  You should ask yourself what a class does
as well as what information you wish to maintain about it.  You will
often identify a responsibility for a class to fulfill a collaboration with
another class.

31
 Define collaborators.  A class often does not have sufficient information
to fulfill its responsibilities. Therefore, it must collaborate (work) with other
classes to get the job done. Collaboration will be in one of two forms: a
request for information or a request to perform a task.  To identify the
collaborators of a class for each responsibility ask yourself "does the class
have the ability to fulfill this responsibility?".  If not then look for a class
that either has the ability to fulfill the missing functionality or the class
which should fulfill it.  In doing so you'll often discover the need for new
responsibilities in other classes and maybe even the need for a new class
or two.
 Move the cards around. To improve everyone’s understanding of the
system, the cards should be placed on the table in an intelligent manner.
Two cards that collaborate with one another should be placed close
together on the table, whereas two cards that don’t collaborate should be
placed far apart. Furthermore, the more two cards collaborate, the closer
they should be on the desk. By having cards that collaborate with one
another close together, it’s easier to understand the relationships between
classes.

32
33
Relationships
In UML, object interconnections (logical or physical), are
modeled as relationships.

There are three kinds of relationships in UML:

• dependencies

• generalizations

• associations

34
Dependency Relationships
A dependency indicates a semantic relationship between two or
more elements. The dependency from CourseSchedule to
Course exists because Course is used in both the add and
remove operations of CourseSchedule.

CourseSchedule
Course
add(c : Course)
remove(c : Course)

35
Generalization
Relationships
Person
A generalization connects a subclass
to its superclass. It denotes an
inheritance of attributes and behavior
from the superclass to the subclass and
indicates a specialization in the subclass
of the more general superclass.
Student

36
Generalization Relationships
UML permits a class to inherit from multiple superclasses,
although some programming languages (e.g., Java) do not permit
multiple inheritance.

Student Employee

TeachingAssistant

37
Association Relationships
If two classes in a model need to communicate with each other,
there must be link between them.

An association denotes that link.

Student Instructor

38
Association Relationships
We can indicate the multiplicity of an association by adding
multiplicity adornments to the line denoting the association.

The example indicates that a Student has one or more

Instructors:

Student Instructor
1..*

39
Association Relationships

The example indicates that every Instructor has one or more

Students:

Student Instructor
1..*

40
Association Relationships
We can also indicate the behavior of an object in an association
(i.e., the role of an object) using rolenames.

teaches learns from

Student Instructor
1..* 1..*

41
Association Relationships
We can also name the association.

membership
Student Team
1..* 1..*

42
Association Relationships
We can specify dual associations.

member of
1..* 1..*
Student Team
1 president of 1..*

43
Association Relationships
We can constrain the association relationship by defining the
navigability of the association. Here, a Router object requests
services from a DNS object by sending messages to (invoking
the operations of) the server. The direction of the association
indicates that the server has no knowledge of the Router.

Router DomainNameServer

44
Association Relationships
Associations can also be objects themselves, called link classes
or an association classes.

Registration
modelNumber
serialNumber
warrentyCode

Product Warranty

45
Association Relationships

A class can have a self association.

next

LinkedListNode
previous

46
Association Relationships
We can model objects that contain other objects by way of
special associations called aggregations and compositions.

An aggregation specifies a whole-part relationship between

an aggregate (a whole) and a constituent part, where the part
can exist independently from the aggregate. Aggregations are
denoted by a hollow-diamond adornment on the association.

Engine
Car
Transmission

47
Association Relationships
(Cont’d)
A composition indicates a strong ownership and coincident
lifetime of parts by the whole (i.e., they live and die as a
whole). Compositions are denoted by a filled-diamond
adornment on the association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 .. *

48