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

2 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

3 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. Inception 2. Elaboration 3. Construction 4. Transition During each phase Multiple iterations of software development Development treated as mini-waterfalls Emphasis gradually shifts from specification to testing

4 Unified Software Life Cycle Model

5 Agile Software Development Model The following information is from: 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

6 Extreme Programming (XP) One of the best-know examples of an Agile Process Appropriate for environments with: Small teams Rapidly-changing requirements

7 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

8 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

9 Problem Specification Example Specification of input & output for program

10 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

11 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  L i  (L i  1)  (L i  100) Difficult to write specifications that are both readable and precise i = 0 N-1

12 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

13 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

14 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

15 Design – Decomposition Example Top-down design of banking simulator

16 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

17 Design – Comparison Example Bank simulation Functional programming Arrivals, departures, transactions Object-oriented programming Customers, lines, tellers, transactions

18 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

19 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

20 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

21 Design – Interface & Conditions Function positivePower() Calculate x n 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 x n if preconditions are met Returns –1.0 otherwise

22 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

23 Algorithms and Data Structures Example Implement list as array or linked list

24 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

25 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

26 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

27 Maintenance Goal Keep software working over time Problems Fix errors Improve features Meet changing specification Add new functionality