COS3611 OBJECT ORIENTED

PROGRAMMING I

PROF.
DR.RAFAEL
ADOLFORODRÍGUEZ PUENTE
DIAZ SARDINAS
COMPUTER SCIENCE
COMPUTER SCIENCEDEPARTMENT
DEPARTMENT
UNIVERSITY OFNAMIBIA
UNIVERSITY OF NAMIBIA
ADIAZ@UNAM.NA
RPUENTE@UNAM.NA

Lecture 1: Introduction
Topics

• Course Introduction.
• Brief overview about OOP.
• Conclusions.

Lecture 1: Introduction
Course Introduction

Course details and evaluation system:

• 7 hours per week:
• F~2~F lectures (4 hours).
• Face to face practical sessions (3 hours).
• 2 middle-term examinations and 1 final
examination
• Continuous assessments: all practical sessions
and 2 assignments

Lecture 1: Introduction
 On completing the module students should
be able to:

• Describe the OOP principles.

• Solve medium complexity problems using OOP concepts: class,
objects, etc. and basic algorithms.
• Apply basic principles of object-oriented program design
differentiate specifications of abstract data types from particular
implementation techniques.
• Develop implementations of classes using a particular programming
languagecreate robust  implementations by using exception
handling.
• Save data to and read data from files.
Course content:
• OOP Design.
• Classes.
• Objects and Methods.
• Interfaces and Abstract classes.
• Exceptions and I/O Streams.
• Vectors and Iterators.
• Introducing Abstract Data (ADT).
Prescribe book:
• Timothy Budd (2001). An Introduction to Object
Oriented Programming, third edition. ISBN:
0201760312.
• Meyer, Bertrand (1997). Object-Oriented Software
Construction, second edition. Prentice Hall. ISBN 0-
13-629155-4.
• Meyer Bertrand (2009). Touch of Class. Springer-
Verlag Berlin Heidelberg. 978-3-662-51907-3.
Introduction

• What is an algorithm?
• What this is Object Oriented Programming?
• Which is the main concept in OOP?
• What is a data structure and ADT?
• Which are the main authors related to OOP?

Lecture 1: Introduction
Concepts

Object Oriented Programming and algorithm.

Lecture 1: Introduction
Concepts

Abstract data type (ADT):

• An ADT is a mathematical model of a data
structure that specifies the type of data stored, the
operations supported on them, and the types of
parameters of the operations. 
• An ADT specifies what each operation does, but
not how it does it. 
• Typically, an ADT can be implemented using one of
many different data structures. 

Lecture 1: Introduction
Concepts

Abstract data type (ADT):

• TYPES.
• FUNCTIONS.
• AXIOMS.
• PRECONDITIONS.

Lecture 1: Introduction
ADT specification of stacks

TYPES
– STACK [G]
FUNCTIONS
– push: STACK [G] ´ G ® STACK [G]
– pop: STACK [G] STACK [G]
– top: STACK [G] G
– empty: STACK [G] ® BOOLEAN

Lecture 1: Introduction
ADT specification of stacks

AXIOMS
– For any x: G, s: STACK [G]
– A1 item (push (s, x)) = x
– A2 pop(push (s, x)) = s
– A3 empty (new)
– A4 not empty (push (s, x))
PRECONDITIONS
– pop (s: STACK [G]) require not empty (s)
– top(s: STACK [G]) require not empty (s)
Lecture 1: Introduction
Concepts

Data structure:
• Any method of organising a collection of data
to allow it to be manipulated effectively.

Lecture 1: Introduction
Concepts

Class
• A class is an abstract data type equipped with
a possibly partial implementation.

Lecture 1: Introduction
Concepts

Object:
• Instance of a class

Lecture 1: Introduction
OOP

• It is used for modeling the real world

• Describe the behaviour of real world
processes and things (objects) through a
programming language

Lecture 1: Introduction
An overview of OOSE development activities
and their products
problem statement

Requirements
elicitation

nonfunctional functional use case

requirements model diagram

Analysis

class diagram analysis

statechart diagram
object model
dynamic
System design model sequence diagram
Activities during Object Modeling
Main goal: Find the important abstractions
• Steps during object modeling
1. Class identification
• Based on the fundamental assumption that we can find abstractions
2. Find the attributes
3. Find the methods
4. Find the associations between classes
• Order of steps
– Goal: get the desired abstractions
– Order of steps secondary, only a heuristic
• What happens if we find the wrong abstractions?
– We iterate and revise the model
Class Identification
Class identification is crucial to object-oriented
modeling
– Helps to identify the important entities of a system
• Basic assumptions:
1. We can find the classes for a new software system
(Forward Engineering)
2. We can identify the classes in an existing system
(Reverse Engineering)
• Why can we do this?
– Philosophy, science, experimental evidence.
Class Identification
• Approaches
– Application domain approach
• Ask application domain experts to identify relevant abstractions
– Syntactic approach
• Start with use cases
• Analyze the text to identify the objects
• Extract participating objects from flow of events
– Design patterns approach
• Use reusable design patterns
– Component-based approach
• Identify existing solution classes.
Class identification is a Hard Problem
• One problem: Definition of the system boundary:
– Which abstractions are outside, which abstractions are inside
the system boundary?
• Actors are outside the system
• Classes/Objects are inside the system.
• An other problem: Classes/Objects are not just found by
taking a picture of a scene or domain
– The application domain has to be analyzed
– Depending on the purpose of the system different objects
might be found
• How can we identify the purpose of a system?
• Scenarios and use cases => Functional model
There are different types of Objects
• Entity Objects
– Represent the persistent information tracked by the
system (Application domain objects, also called “Business
objects”)
• Boundary Objects
– Represent the interaction between the user and the
system
• Control Objects
– Represent the control tasks performed by the system.
Example: 2BWatch Modeling
To distinguish different object types
in a model we can use the
UML Stereotype mechanism

Year Button
ChangeDate

Month
LCDDisplay

Day

Entity Objects Control Object Boundary Objects

 Naming Object Types in UML
• UML provides the stereotype mechanism to introduce new types of modeling
elements
– A stereotype is drawn as a name enclosed by angled double-quotes (<<, >>) and
placed before the name of a UML element (class, method, attribute, ….)
– Notation: <<String>>Name

<<Entity>> <<Boundary>>
Year <<Control>> Button
ChangeDate
<<Entitity>>
Month <<Boundary>>
<<Entity>> LCDDisplay
Day

Entity Object Control Object Boundary Object

Object Types allow us to deal with Change

• Having three types of objects leads to models that

are more flexible to change
– The interface of a system changes more likely than the
control
– The way the system is controlled changes more likely
than entities in the application domain
• Object types originated in Smalltalk:
– Model, View, Controller (MVC)
Model <-> Entity Object
View <-> Boundary Object
Controller <-> Control Object
 Finding Participating Objects in Use Cases
• Pick a use case and look at flow of events
• Do a textual analysis (noun-verb analysis)
– Nouns are candidates for objects/classes
– Verbs are candidates for operations
– This is also called Abbott’s Technique

• After objects/classes are found, identify their types

– Identify real world entities that the system needs to keep
track of (FieldOfficer  Entity Object)
– Identify real world procedures that the system needs to keep
track of (EmergencyPlan  Control Object)
– Identify interface artifacts (PoliceStation  Boundary Object).
Example for using the Technique
Flow of Events:
• The customer enters the store to buy a toy.
• It has to be a toy that his daughter likes and it must
cost less than 50 Dollars.
• He tries a videogame, which uses a data glove and a
head-mounted display. He likes it.
• An assistant helps him.
• The suitability of the game depends on the age of the
child.
• His daughter is only 3 years old.
• The assistant recommends another type of toy,
namely the boardgame “Monopoly".
Mapping parts of speech to model components (Abbot’s
Technique)
Example Part of speech UML model component
“Monopoly” Proper noun object
Toy Improper noun class
Buy, recommend Doing verb operation
is-a being verb inheritance
has an having verb aggregation
must be modal verb constraint
dangerous adjective attribute
enter transitive verb operation
depends on intransitive verb constraint, class,
association
Generating a Class Diagram from Flow of Events
Customer Flow of events:
customer enters
• The customer enters the store store
to buy a buy
toy. It
toy
store
? has to be a toy that his daughter likes and it less
daughter
must 50 less than 50 Euro. Hevideogame
than cost tries a
enter()
videogame, which uses a data glove and a
daughter
daughter
head-mounted display. He likes it.
age

suitable
An assistant helps him. The suitability of the
*Toy depends
game depends on the age of the child. His
toy
price daughter isage
only 3 years old. The assistant
buy()
buy()
like() recommends another type of toy, namely a
boardgame. The customer buy the game and
type ofthe
leaves toystore boardgame
videogame boardgame
 Ways to find Objects
• Syntactical investigation with Abbot‘s technique:
– Flow of events in use cases
– Problem statement

• Use other knowledge sources:

– Application knowledge: End users and experts know the
abstractions of the application domain
– Solution knowledge: Abstractions in the solution domain
– General world knowledge: Your generic knowledge and
intuition
 Steps in Generating Class Diagrams

1. Class identification (textual analysis, domain expert)

2. Identification of attributes and operations
(sometimes before the classes are found!)
3. Identification of associations between classes
4. Identification of multiplicities
5. Identification of roles
6. Identification of inheritance
Who uses Class Diagrams?
• Purpose of class diagrams
– The description of the static properties of a system
• The main users of class diagrams:
– The application domain expert
• uses class diagrams to model the application domain (including
taxonomies)
– during requirements elicitation and analysis
– The developer
• uses class diagrams during the development of a system
– during analysis, system design, object design and implementation.
Who does not use Class Diagrams?
• The client and the end user are usually not
interested in class diagrams
– Clients focus more on project management issues
– End users are more interested in the functionality of the
system.
Developers have different Views on Class
Diagrams
• According to the development activity, a developer
plays different roles:
– Analyst
– System Designer
– Object Designer
– Implementor

• Each of these roles has a different view about the

class diagram (the object model).
The View of the Analyst
• The analyst is interested
– in application classes: The associations between classes are
relationships between abstractions in the application domain
– operations and attributes of the application classes
• The analyst uses inheritance in the model to reflect the
taxonomies in the application domain
• Taxonomy: is-a-hierarchy of abstractions in an application domain
• The analyst is not interested
– in the exact signature of operations
– in solution domain classes
 The View of the Designer
• The designer focuses on the solution of the problem, that
is, the solution domain
• The associations between classes are now references
(pointers) between classes in the application or solution
domain
• An important design task is the specification of
interfaces:
– The designer describes the interface of classes and the interface
of subsystems
– Subsystems originate from modules (term often used during
analysis):
• Module: a collection of classes
• Subsystem: a collection of classes with an interface
• Subsystems are modeled in UML with a package.
 Goals of the Designer
• The most important design goals for the designer
are design usability and design reusability
• Design usability: the interfaces are usable from as
many classes as possible within in the system
• Design reusability: The interfaces are designed in a
way, that they can also be reused by other (future)
software systems
=> Class libraries
=> Frameworks
=> Design patterns.
The View of the Implementor
• Class implementor
– Must realize the interface of a class in a programming language
– Interested in appropriate data structures (for the attributes) and
algorithms (for the operations)
• Class extender
– Interested in how to extend a class to solve a new problem or to
adapt to a change in the application domain
• Class user
– The class user is interested in the signatures of the class
operations and conditions, under which they can be invoked
– The class user is not interested in the implementation of the class.
 Summary
• System modeling
– Functional modeling+object modeling+dynamic modeling
• Functional modeling
– From scenarios to use cases to objects
• Object modeling is the central activity
– Class identification is a major activity of object modeling
– Easy syntactic rules to find classes and objects
– Abbot’s Technique
 Summary cntd
• Class diagrams are the “center of the universe” for
the object-oriented developer
– The end user focuses more on the functional model and
usability.
• Analysts, designers and implementors have different
modeling needs
• There are three types of implementors with different
roles during
– Class user, class implementor, class extender.
Conclusions

• What we can do with OOP?

• Which are the main concepts in OOP?
• What is a Class?
• What is an Object?

Lecture 1: Introduction
 QUESTIONS?

Tuesday 28 February 2023