1 cmsc 132: object-oriented programming ii nelson padua-perez william pugh department of computer...
Post on 19-Dec-2015
214 views
TRANSCRIPT
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
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()