CMSC 132:
Object-Oriented Programming II
Nelson Padua-Perez
William Pugh
Department of Computer Science
University of Maryland, College Park
1
Lecture Overview
Software Development
Choosing a software development process
Algorithm and Data Structures
Coding and Debugging
Testing and Verification
Documentation Support
Maintenance
Object-oriented design
Goals
Techniques
Object-oriented view
Examples
2
Choosing a software development
process
Which software life cycle is appropriate when?
For projects like 132 programming projects,
just code and test probably suffices
But the world isn’t like 132 programming
projects
3
Big questions
Do you understand what you are trying to
build?
What is the cost of change?
How easy is it to get the entire thing in your
head?
How many people have to interact with the
design?
4
Do you understand the problem?
In many cases, the things we want software to
do are not well understood:
provide a web interface for students applying for the
PhD program
build software that allows users to view and
manipulate photographs
Build a better search engine
You have to understand the real-world
constraints/interactions
May have to build prototype to understand how
users can effectively use it
5
What is the cost of change?
Say you’ve already completed much of the
coding, and realize you need to change
something in the design or even the
requirements
how expensive is that?
If it is hugely expensive, you better get the
requirements and design right before you start
most of the coding
6
Has the cost of change changed?
Some people have said that recent software
development techniques have substantially
changed the cost of change
safe programming languages
(e.g., not C/C++/assembly language)
OO design programming
test driven development
7
Sometimes, change is still expensive
Key nexus in a large system
Stuff that interacts with hardware that is being
co-designed
Stuff that interacts with software being
developed externally
can’t change an API once it is published
8
How easy is it to understand?
When building and developing software, you
need to understand it (at least, parts of it)
For 100 lines of code, just read the code
That doesn’t work for 100,000 lines of code
Need to have ways of documenting the
requirements and design at a higher level
9
How many people interact with
design?
How many people interact with the design?
Part of the cost of change
if you make a change, how many people need to be
aware of or consulted on the design change
Design changes that interact with a lot of
people are expensive and need to be minimized
try to get these design choices right early and
document them
10
Algorithms and Data Structures
Goal
Select algorithms and data structures to implement
each component
Problems
Functionality
Provides desired abilities
Efficiency
Provides desired performance
Correctness
Provides desired results
11
Algorithms and Data Structures
Example
Implement list as array or linked list
12
Coding and Debugging
Goal
Write actual code and ensure code works
Problems
Choosing programming language
Functional design
Fortran, BASIC, Pascal, C
Object-oriented design
Smalltalk, C++, Java
Using language features
Exceptions, streams, threads
13
Testing and Verification
Goal
Demonstrate software correctly match specification
Problem
Program verification
Formal proof of correctness
Difficult / impossible for large programs
Empirical testing
Verify using test cases
Unit tests, integration tests, alpha / beta tests
Used in majority of cases in practice
14
Documentation and Support
Goal
Provide information needed by users and technical
maintenance
Problems
User documentation
Help users understand how to use software
Technical documentation
Help coders understand how to modify, maintain
software
15
Maintenance
Goal
Keep software working over time
Problems
Fix errors
Improve features
Meet changing specification
Add new functionality
16
Object-Oriented Design
Goals
Improve software design
Reduce implementation effort
Scalable to large software projects
Try to take advantage of two techniques
Abstraction
Encapsulation
17
Techniques – Abstraction
Abstraction
Provide simple high-level model of
Physical entity
Activity
Helpful for managing complexity
Enables information hiding
Can change implementation & representation
Will not affect other software components
18
Types of Abstraction
Procedural abstraction
Specify what actions should be performed
Hide algorithms
Data abstraction
Specify data objects for problem
Hide representation
19
Abstraction Example
Abstraction of a Student Roster
Data
List of student names
Actions
Create roster
Add student
Remove student
Print roster
STUDENT
ROSTER
List of names
Create()
AddStudent()
RemoveStudent()
Print()
20
Techniques – Encapsulation
Encapsulation
Confine information so it is only visible / accessible
through an associated external interface
Approach
For some entity X in program
Abstract data in X
Abstract actions on data in X
Collect data & actions on X in same location
Protects and hides X
21
Encapsulation
Extension of abstraction
Always abstract data & function together
Encapsulated entity  Abstract Data Type (ADT)
Examples
List ADT
May be implemented as array, linked list, etc…
Java collections library
22
Benefits of Encapsulation
Easier to make code modifications
Due to information hiding
Promotes code reuse
Interface to data structure clearly defined
Easier to reuse code
Code reuse increases productivity
23
Object-Oriented Design
View software as
A collection of entities (objects)
Functions associated with each object
Communication between objects
Exploits abstraction & encapsulation
Can rely on programming language support
24
Object-Oriented View
Example problem description
Thermostat uses dial setting to control a heater to
maintain constant temperature in room
Thermostat
(dial)
getTemperature()
Room
heaterOn()
Heater
25
History of Object-Oriented Design
Preceded by procedure-oriented view
Earliest approach to programming
Uses procedure abstraction
Similar to actual machine instructions
Focus on control flow, program scope
Examples: Fortran, Cobol, Pascal, Basic
Example
Thermostat()
1. Get room temperature
2. If (temperature < setting) turn heater on
3. Else turn heater off
4. Goto step 1
26
OO Programming Languages
Development history
Simula (Dahl & Nygaard, 1962)
Modeling discrete event simulation
Smalltalk (Kay, 1972)
General programming
C++ (Stroustrup, 1979)
Manage complexity in huge software projects
Java (Gosling, 1991)
Designed for embedded processors
27
Factors in Success of OO Design
Growing demand
More experience with large software projects
Improvements in language design
Made OO programming easier
Improvements compiler technology
Support more language features efficiently
Improvements in hardware
Handled inefficiencies in OO programming
Made performance less critical
28
Elements of Object-Oriented Design
Objects
Entities in program
Methods
Functions associated with objects
Classes
Groups of objects with similar properties
Inheritance
Relationship between classes
29
Objects
Definition
Entity that has state, behavior, and identity
State (data)
Properties possessed by object
Current values of those properties
Behavior (methods)
How objects react to changes in state
How objects interact with each other
Identity (references)
Mechanism to distinguish between objects
30
Object Example
Thermostat
State
DesiredTemp
CurrentTemp
HeaterState
Behavior
SetDesiredTemp()
TurnHeaterOn()
TurnHeaterOff()
Identity
this
31
Object Example
Thermostat
State
DesiredTemp
Property
integer
Value
o
78
o
CurrentTemp
integer
72
HeaterState
boolean
ON
32
Object State
Properties
Static, unchanging
May view as types
Values
Dynamic, changes
Within bounds set by properties
33
Methods
Definition
Procedures associated with object
Specify behavior of objects
Invocation  sending message to object
Example
myThermostat.setDesiredTemp(78)
myThermostat.turnHeaterOn()
myThermostat.turnHeaterOff()
34
Method Types
Accessor
Return state information
Mutator
Modify state information
Constructor
Create & initialize new object
Destructor
Remove object & free up resources
35