1 CMSC 132: Object-Oriented Programming II Nelson Padua-Perez William Pugh Department of Computer Science University of Maryland, College Park.

1

CMSC 132: Object-Oriented Programming II

Nelson Padua-Perez

William Pugh

Department of Computer Science

University of Maryland, College Park

2

Lecture Overview

Software DevelopmentChoosing a software development processAlgorithm and Data StructuresCoding and DebuggingTesting and VerificationDocumentation SupportMaintenance

Object-oriented design GoalsTechniquesObject-oriented viewExamples

3

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

4

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?

5

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

6

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

7

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

8

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

9

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

10

How many people interact with design?

How many people interact with the design?

Part of the cost of changeif 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

11

Algorithms and Data Structures

GoalSelect algorithms and data structures to implement each component

ProblemsFunctionality

Provides desired abilities

Efficiency

Provides desired performance

Correctness

Provides desired results

12

Algorithms and Data Structures

ExampleImplement list as array or linked list

13

Coding and Debugging

GoalWrite actual code and ensure code works

ProblemsChoosing programming language

Functional designFortran, BASIC, Pascal, C

Object-oriented designSmalltalk, C++, Java

Using language features

Exceptions, streams, threads

14

Testing and Verification

GoalDemonstrate software correctly match specification

ProblemProgram verification

Formal proof of correctness

Difficult / impossible for large programs

Empirical testing

Verify using test casesUnit tests, integration tests, alpha / beta tests

Used in majority of cases in practice

15

Documentation and Support

GoalProvide information needed by users and technical maintenance

ProblemsUser documentation

Help users understand how to use software

Technical documentation

Help coders understand how to modify, maintain software

16

Maintenance

GoalKeep software working over time

ProblemsFix errors

Improve features

Meet changing specification

Add new functionality

17

Object-Oriented Design

GoalsImprove software design

Reduce implementation effort

Scalable to large software projects

Try to take advantage of two techniques

Abstraction

Encapsulation

18

Techniques – Abstraction

AbstractionProvide simple high-level model of

Physical entity

Activity

Helpful for managing complexity

Enables information hidingCan change implementation & representation

Will not affect other software components

19

Types of Abstraction

Procedural abstractionSpecify what actions should be performed

Hide algorithms

Data abstractionSpecify data objects for problem

Hide representation

20

Abstraction Example

Abstraction of a Student RosterData

List of student names

Actions

Create roster

Add student

Remove student

Print roster

STUDENT ROSTER

List of names

Create()

AddStudent()

RemoveStudent()

Print()

21

Techniques – Encapsulation

EncapsulationConfine information so it is only visible / accessible through an associated external interface

ApproachFor 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

22

Encapsulation

Extension of abstractionAlways abstract data & function together

Encapsulated entity Abstract Data Type (ADT)

ExamplesList ADT

May be implemented as array, linked list, etc…

Java collections library

23

Benefits of Encapsulation

Easier to make code modificationsDue to information hiding

Promotes code reuseInterface to data structure clearly defined

Easier to reuse code

Code reuse increases productivity

24

Object-Oriented Design

View software asA collection of entities (objects)

Functions associated with each object

Communication between objects

Exploits abstraction & encapsulation

Can rely on programming language support

25

Object-Oriented View

Example problem descriptionThermostat uses dial setting to control a heater to maintain constant temperature in room

Room

Thermostat(dial)

Heater

getTemperature() heaterOn()

26

History of Object-Oriented Design

Preceded by procedure-oriented viewEarliest approach to programming Uses procedure abstractionSimilar to actual machine instructionsFocus on control flow, program scopeExamples: Fortran, Cobol, Pascal, Basic

ExampleThermostat()

1. Get room temperature

2. If (temperature < setting) turn heater on

3. Else turn heater off

4. Goto step 1

27

OO Programming Languages

Development historySimula (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

28

Factors in Success of OO Design

Growing demandMore experience with large software projects

Improvements in language designMade OO programming easier

Improvements compiler technologySupport more language features efficiently

Improvements in hardwareHandled inefficiencies in OO programming

Made performance less critical

29

Elements of Object-Oriented Design

ObjectsEntities in program

MethodsFunctions associated with objects

ClassesGroups of objects with similar properties

InheritanceRelationship between classes

30

Objects

DefinitionEntity 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

31

Object Example

ThermostatState

DesiredTemp

CurrentTemp

HeaterState

Behavior

SetDesiredTemp()

TurnHeaterOn()

TurnHeaterOff()

Identity

this

32

Object Example

ThermostatState Property Value

DesiredTemp integer 78o

CurrentTemp integer 72o

HeaterState boolean ON

33

Object State

PropertiesStatic, unchanging

May view as types

ValuesDynamic, changes

Within bounds set by properties

34

Methods

DefinitionProcedures associated with object

Specify behavior of objects

Invocation sending message to object

ExamplemyThermostat.setDesiredTemp(78)

myThermostat.turnHeaterOn()

myThermostat.turnHeaterOff()

35

Method Types

AccessorReturn state information

MutatorModify state information

ConstructorCreate & initialize new object

DestructorRemove object & free up resources