CMSC 132:
Object-Oriented Programming II
Nelson Padua-Perez
William Pugh
Department of Computer Science
University of Maryland, College Park
1
Waterfall Model
Simple model
Proceed from
one step to next
Result of step
flow into next
In reality
May need to
return to
previous step
Steps may be
more integrated
Steps may occur
at same time
2
Unified Software Life Cycle Model
Iterative development (iteratively add incremental
improvements)
Takes advantage of what has been learned during
earlier versions of the system
Development divided into phases (iterations)
1.
2.
3.
4.
Inception
Elaboration
Construction
Transition
During each phase
Multiple iterations of software development
Development treated as mini-waterfalls
Emphasis gradually shifts from specification to testing
3
Unified Software Life Cycle Model
4
Agile Software Development Model
The following information is from:
http://www.webopedia.com/TERM/E/Extreme_Programming.html
http://www.wikipedia.org
Agile Model
Built on top of the ideas associated with the Unified
Software Life Cycle model
Adds a more people-centric viewpoint
Relies on feedback rather than planning as the
primary control mechanism
5
Extreme Programming (XP)
One of the best-know examples of an Agile Process
Appropriate for environments with:
Small teams
Rapidly-changing requirements
6
Extreme Programming (XP)
Some of the principles XP is based on are:
Small Releases - Software developed in stages that are
updated frequently
Simple Design – Implement code needed to achieve customer’s
results without emphasis on future versions
Testing – Done throughout the whole development process.
Tests are design first, before writing the software
Pair Programming – Code written in pairs working at the same
computer
40-Hour Week – Ensures team remains well-rested and alert
On-Site Customer – Customer is available at all times to answer
questions
7
Problem Specification
Goal
Create complete, accurate, and unambiguous
statement of problem to be solved
Problems
Description may not be accurate
Description may change over time
Difficult to specify behavior for all inputs
Natural language description is imprecise
Formal specification languages limited and difficult
to understand
8
Problem Specification
Example
Specification of input & output for program
9
Problem Specification Problems
Description may not be accurate
Problem not understood by customer
Description may change over time
Customer changes their mind
Difficult to specify behavior for all inputs
Usually only covers common cases
Hard to consider all inputs (may be impossible)
Example
Bart Miller was able to crash most UNIX utilities
with randomly generated inputs
10
Problem Specification Problems
Description may be ambiguous
Natural language description is imprecise
Why lawyers use legalese for contracts
Formal specification languages are limited and
may be difficult to understand
Examples
Find sum of all values in N-element list L
between 1 and 100
N-1
Li  (Li  1)  (Li  100)
i=0
Difficult to write specifications that are both
readable and precise
11
Program Design
Goal
Break software into integrated set of components
that work together to solve problem specification
Problems
Methods for decomposing problem
How to divide work
What work to divide
How components work together
12
Design – How To Divide Work
Decomposing problem
Break large problem into many smaller problems
Cannot solve large problems directly
Divide and conquer
1. Break problem up into simpler sub-problems
2.
Repeat for each sub-problem
3.
Stop when sub-problem can be solved easily
13
Design – How To Divide Work
Functional approach
Treat problem as a collection of functions
Techniques
Top-down design
Successively split problem into smaller problems
Bottom-up design
Start from small tasks and combine
14
Design – Decomposition Example
Top-down design of banking simulator
15
Design – How To Divide Work
Object-oriented approach
Treat problem as a collection of data objects
Objects
Entities that exist that exist in problem
Contain data
Perform actions associated with data
16
Design – Comparison Example
Bank simulation
Functional
programming
Arrivals, departures,
transactions
Object-oriented
programming
Customers, lines,
tellers, transactions
17
Design – Comparing Approaches
Functional approach
Treat problem as a collection of functions
Functions perform actions
Think of functions as verbs
Object-oriented approach
Treat problem as a collection of data objects
Objects are entities that exist in problem
Think of objects as nouns
18
Design – Comparing Approaches
Advantages to object-oriented approach
Helps to abstract problem
Simpler high-level view
Helps to encapsulate data
Hides details of internals of objects
Centralizes and protects all accesses to data
Seems to scale better for larger projects
In practice
Tend to use a combination of all approaches
19
Design – Components
Components must work together easily
Each component requires
Interface
Specifies how component is accessed & used
Specifies what functions (methods) are available
A contract between designer & programmer
Pre-conditions
What conditions must be true before invocation
Post-conditions
What conditions will be true after invocation
20
Design – Interface & Conditions
Function positivePower()
Calculate xn for positive values of x & n
Interface
public static float positivePower(float x, int n)
Pre-conditions
x has positive floating point value > 0.0
n has positive integer value  0
Post-conditions
Returns xn if preconditions are met
Returns –1.0 otherwise
21
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
22
Algorithms and Data Structures
Example
Implement list as array or linked list
23
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
24
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
25
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
26
Maintenance
Goal
Keep software working over time
Problems
Fix errors
Improve features
Meet changing specification
Add new functionality
27