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 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

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 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

11 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

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

13 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

14 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

15 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

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

17 Object-Oriented Design Goals Improve software design Reduce implementation effort Scalable to large software projects Try to take advantage of two techniques Abstraction Encapsulation

18 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

19 Types of Abstraction Procedural abstraction Specify what actions should be performed Hide algorithms Data abstraction Specify data objects for problem Hide representation

20 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()

21 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

22 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

23 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

24 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

25 Object-Oriented View Example problem description Thermostat 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 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

27 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

28 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

29 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

30 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

31 Object Example Thermostat State DesiredTemp CurrentTemp HeaterState Behavior SetDesiredTemp() TurnHeaterOn() TurnHeaterOff() Identity this

32 Object Example Thermostat StatePropertyValue DesiredTempinteger78 o CurrentTempinteger72 o HeaterStatebooleanON

33 Object State Properties Static, unchanging May view as types Values Dynamic, changes Within bounds set by properties

34 Methods Definition Procedures associated with object Specify behavior of objects Invocation  sending message to object Example myThermostat.setDesiredTemp(78) myThermostat.turnHeaterOn() myThermostat.turnHeaterOff()

35 Method Types Accessor Return state information Mutator Modify state information Constructor Create & initialize new object Destructor Remove object & free up resources