Welcome to CSIS 10B Overview of Course Software Design (from Nyhoff)

Welcome to CSIS 10B Overview of Course Software Design (from Nyhoff)
Problem Solving Example (from CUNY) Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

This Course Covers, using C++
Abstract data types Design, what you want them to do (OOD) Techniques, used in implementation (class) Example: integers, strings, lists, etc Data structures Ways of organizing large quantities of data in computer’s memory Vector lists, linked lists, trees, hash tables Problem solving Solving problems in managing data structures Using data structures to solve real problems Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Some examples of data structures
Arrays, 2D Arrays Vector Lists, Linked Lists Algorithms for processing lists Stacks, Queues Trees Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

An example Array of Readings stored in memory starting at address x
Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

A two-dimensional array with four rows and five columns stored in row major order

Storing names in memory as a contiguous list (vector list)

Storing names in a linked list

Algorithm for Deleting an entry from a linked list

Algorithm for Inserting an entry into a linked list

Algorithm for printing a linked list

Using a stack to print a linked list in reverse order (continued)

Using a stack to print a linked list in reverse order

A procedure (using an auxiliary stack) for printing a linked list in
A procedure (using an auxiliary stack) for printing a linked list in reverse order Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

A queue implemented with head and tail pointers

A queue “crawling” through memory

A circular queue (a) containing the letters F through O as actually stored in memory

A circular queue (b) in its conceptual form
A circular queue (b) in its conceptual form in which the last cell in the block is “adjacent” to the first cell Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

An example of an organization chart

The structure of a node in a binary tree

The conceptual and actual organiza-
The conceptual and actual organization of a binary tree using a linked storage system Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

A tree stored without pointers (in an array)

Software Development Nyhoff, Chapter 1

Chapter Contents 1.1 Problem Analysis and Specification 1.2 Design
1.3 Coding 1.4 Testing, Execution, and Debugging 1.5 Maintenance Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Chapter Objectives Introduce software development approaches
Contrast software development in programming course with real world Study top-down, objected oriented approaches Introduce design aspects Select or build data types Develop algorithms for operations on data Investigate error types Emphasize importance of testing Note time and effort devoted to maintenance Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

5 Phases of Software Life Cycle
Waterfall Model Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

5 Phases of Software Life Cycle
Realistic Waterfall Model Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Problem Analysis and Specification
CS courses small systems few hundred lines of code simple, straightforward self-contained “Real” world large systems thousands of lines of code complex many components problem initially poorly defined Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved 28

Problem Analysis and Specification
The specification or "contract" will include Purpose Precondition Postcondition Real world contracts Must be precise May be required to prove end product meets these precise specifications Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Top Down Design Original problem partitioned into simpler subproblems
Each of these subproblems likewise subdivided Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

OOD: Object-Oriented Design
Identify the objects in the problem's specification and their types. Identify the operations or tasks to manipulate the objects Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved 31

OOD: Object-Oriented Design
UML class diagram Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Data Types of the Objects
Simple Structured arrays structures class objects Think of them as Containers Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Algorithms Pseudo code Must be
Definite, unambiguous Simple Finite correct and efficient well structured Cannot separate data structures from algorithms Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Algorithms Structured while loop switch stmt Unstructured goto's
if-else's Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Coding Select language of implementation Encode the design Example
Figure 1.9 Financial-aid update function Figure 1.10 Test-driver for Financial-aid update function Figure 1.11 Header file for FinancialAidAward class Figure 1.12 Implementation file for FinancialAidAward class Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved 36

Coding Verify integration
combining program units into a complete software system. Insure quality programs must be correct, readable, and understandable well-structured, documented, formatted for readability Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Testing, Execution, and Debugging
Validation: "Are we building the right product?" check that documents, program modules, etc. match the customer's requirements. Verification: "Are we building the product right?" check that products are correct, complete, consistent with each other and with those of the preceding phases. Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved 38

Different Kinds Of Tests Required
Unit tests: Each individual program unit works? Program components tested in isolation Integration tests : Units combined correctly? Component interface and information flow tested System tests: Overall system works correctly? Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved 39

Types of Errors Syntax errors Run-time errors Logic errors
errors in the grammar of the programming language Run-time errors happen during program execution Logic errors errors in algorithm design Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved

Black Box or Functional Test
Outputs produced for various inputs Checked for correctness Do not consider structure of program component itself. Program unit is viewed as a black box Accepts inputs and produces outputs, Inner workings of the box are not visible. Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved 42

White Box or Structural Test
Performance is tested examine code’s internal structure. Test data is carefully selected specific parts of the program unit are exercised. Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved 43

Maintenance Large % of Because … Computer center budgets
Programmer's time Software development cost Because … Includes modifications and enhancements Poor structure, poor documentation, poor style Bug finding and fixing is tougher Impedes implementation of enhancements Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved 44

Life Cycle of Software Specifications Design Analysis Coding Testing
Production Maintanance

Specifications, Design & Implementation
Specification is a precise description of the problem Specify Input/Output (I/O) Design – formulating the steps to solve the problem Design data structures and algorithms Describe in pseudocode Design Technique: Decomposing the problem Modularity, reusability, divide-and-conquer Information hiding Implementation – the actual C++ code that solves the problem

Preconditions and Postconditions
An important topic: preconditions and postconditions. They are a method of specifying what a function accomplishes without describing the how Support information hiding This is the first of several lectures which accompany the textbook Data Structures and Other Objects Using C++. Each lecture chooses one topic from the book and expands on that topic - adding examples and further material to reinforce the students' understanding. This first lecture covers the topic of Preconditions and Postconditions from Chapter 1. Precondition and Postcondition Presentation copyright 1997, Addison Wesley Longman For use with Data Structures and Other Objects Using C++ by Michael Main and Walter Savitch.

Preconditions and Postconditions
Frequently a programmer must communicate precisely what a function accomplishes, without any indication of how the function does its work. Throughout the book, preconditions and postconditions are used to specify precisely what a function does. However, as we will see, a precondition/postcondition specification does not indicate anything about how a function accomplishes its work. This separation between what a function does and how the function works is extremely important - particularly for large programs which are written by a team of programmers. Can you think of a situation where this would occur ?

Example You are the head of a programming team and you want one of your programmers to write a function for part of a project. HERE ARE THE REQUIREMENTS FOR A FUNCTION THAT I WANT YOU TO WRITE. I DON'T CARE WHAT METHOD THE FUNCTION USES, AS LONG AS THESE REQUIREMENTS ARE MET. As an example, suppose that you are the head of a programming team. Your team is writing a large piece of software, perhaps with millions of lines of code. Certainly nobody can keep all those lines of code in their head at once (not even me!). So, the large problem is broken into smaller problems. Those smaller problems might be broken into still smaller problems, and so on, until you reach manageable problems. Each of the manageable problems can be solved by a function - but you won't be writing all these functions. The functions are written by members of your team. As each team member is given a function to write, you will specify the requirements of the function by indicating what the function must accomplish. But most of the details about how a function works will be left up to the individual programmers.

What are Preconditions and Postconditions?
One way to specify such requirements is with a pair of statements about the function. The precondition statement indicates what must be true before the function is called. The postcondition statement indicates what will be true when the function finishes its work. There are many ways to specify the requirements for a function. In this class, and in the textbook, we will use a pair of statements for each function, called the function's precondition and postcondition. As we will see, the two statements work together: The precondition indicates what must be true before the function is called. The postcondition indicates what will be true when the function finishes its work. An example can clarify the meanings...

... Example void write_sqrt( double x) // Precondition: x >= 0.
// Postcondition: The square root of x has // been written to the standard output. ... This is an example of a small function which simply writes the square root of a number. The number is given as a parameter to the function, called x. For example, if we call write_sqrt(9), then we would expect the function to print 3 (which is the square root of 9). What needs to be true in order for this function to successfully carry out its work? Since negative numbers don't have a square root, we need to ensure that the argument, x, is not negative. This requirement is expressed in the precondition: Precondition: x >= 0. The postcondition is simply a statement expressing what work has been accomplished by the function. This work might involve reading or writing data, changing the values of variable parameters, or other actions. Notice that the information shown on this slide is enough for you to use the function. You don't need to know what occurs in the function body.

// Postcondition: The square root of x has // been written to the standard output. ... } The precondition and postcondition appear as comments in your program. They are usually placed after the function’s parameter list. The precondition and postcondition are not actually part of the program. It is common to place the precondition/postcondition pair in a comment immediately after the function's parameter list.

// Postcondition: The square root of x has // been written to the standard output. ... } In this example, the precondition requires that x >= 0 be true whenever the function is called. Here again you see the precondition of the example. The right way to read this is as a warning that says: "Watch Out! This function requires that x is greater than or equal to zero. If you violate this condition, then the results are totally unpredictable."

Example Which of these function calls meet the precondition ?
write_sqrt( -10 ); write_sqrt( 0 ); write_sqrt( 5.6 ); So, here are three possible function calls. Two of the calls meet the precondition and have predictable results. In one of the calls, the precondition fails, and the result of the function call is unpredictable. Which function call is the trouble maker?

write_sqrt( -10 ); write_sqrt( 0 ); write_sqrt( 5.6 ); The second and third function calls are fine. The second call has an argument of zero, but that's acceptable since the precondition only requires that x is greater than or equal to zero. The second and third calls are fine, since the argument is greater than or equal to zero.

write_sqrt( -10 ); write_sqrt( 0 ); write_sqrt( 5.6 ); But the first function call causes trouble. This function call, which violates the precondition, must never be made by a program. In a few minutes you'll see exactly how much trouble can arise from such a violation. For now, just take my word, do not violate preconditions. But the first call violates the precondition, since the argument is less than zero.

// Postcondition: The square root of x has // been written to the standard output. ... } The postcondition always indicates what work the function has accomplished. In this case, when the function returns the square root of x has been written. Before we continue, take one more quick look at the postcondition: As you know, it states what the function will accomplish between the time the function starts executing and the time the function finishes executing. One more important point which isn't written on the slide: Provided that the precondition is valid, then the function is also required to finish executing. Infinite loops are not permitted, and neither is crashing the computer.

... Another Example bool is_vowel( char letter )
// Precondition: letter is an uppercase or // lowercase letter (in the range 'A' ... 'Z' or 'a' ... 'z') . // Postcondition: The value returned by the // function is true if letter is a vowel; // otherwise the value returned by the function is // false. ... Here's one more example, which demonstrates how you can use ordinary English to express the precondition and postcondition. The writing of these expressions should be clear and concise. The goal is to communicate to another programmer two things: 1. What must be true in order for that programmer to use the function; and 2. What work the function will accomplish. In this example, the "work accomplished" is nothing more than computing a value which the function returns. Again, notice that there is enough information for you to use the function without knowing a thing about the implementation details.

Another Example What values will be returned by these function calls ?
is_vowel( 'A' ); is_vowel(' Z' ); is_vowel( '?' ); Another quick quiz: What values will these function calls return? If you think this is a "trick question" you are right. . .

Another Example What values will be returned by these function calls ?
true is_vowel( 'A' ); is_vowel(' Z' ); is_vowel( '?' ); false The first two function calls are fine, returning true (since 'A' is a vowel) and false since 'Z' is not a vowel. But the third function call might return true, or it might return false, nobody really knows since the precondition has been violated. In fact, the situation is worse than that. Recall that I said to never violate a precondition. The reason is that the result of violating a precondition is totally unpredictable, including the possibility of . . . Nobody knows, because the precondition has been violated.

Consequence of Violation
Who are responsible for the crash ? write_sqrt(-10.0); is_vowel( '?' ); . . . crashing the computer. Now, if I had written the is_vowel function, and the argument was a question mark, I would try to not crash the machine, I would try to not destroy files on the hard drive, I would try my best to not cause power outages across New York. But you never know for sure. Violating the precondition might even crash the computer.

Always make sure the precondition is valid . . .
The programmer who calls the function is responsible for ensuring that the precondition is valid when the function is called. So, let's look at the use of preconditions and postconditions in a typical situation. The programmer who calls the function is responsible for ensuring that the precondition is valid when the function is called. If she fails in this responsibility, then all bets are off. There is no telling what might occur. AT THIS POINT, MY PROGRAM CALLS YOUR FUNCTION, AND I MAKE SURE THAT THE PRECONDITION IS VALID.

. . . so the postcondition becomes true at the function’s end.
The programmer who writes the function counts on the precondition being valid, and ensures that the postcondition becomes true at the function’s end. THEN MY FUNCTION WILL EXECUTE, AND WHEN IT IS DONE, THE POSTCONDITION WILL BE TRUE. I GUARANTEE IT. On the other hand, if she keeps her end of the bargain, and calls the function with a valid postcondition, then the function has a responsibility of its own. The function must complete its execution (no infinite loops), and when the function finishes, the postcondition will be true. In some ways, you can think of the precondition/postcondition statements as a contract between two programmers: One programmer (who uses the function) is guaranteeing that she will make sure that the precondition is valid before the function is called. The other programmer (who writes the function) is going to bank on the precondition being true. This other programmer is responsible for making sure that the postcondition becomes true when the function finishes execution.

A Quiz Suppose that you call a function, and you neglect to make sure that the precondition is valid Who is responsible if this inadvertently causes a 40-day flood or other disaster? You The programmer who wrote that torrential function Noah Time for another quiz . . .

A Quiz Suppose that you call a function, and you neglect to make sure that the precondition is valid Who is responsible if this inadvertently causes a 40-day flood or other disaster? You The programmer who calls a function is responsible for ensuring that the precondition is valid. Somehow I think this quiz was too easy.

On the other hand, careful programmers also follow these rules:
When you write a function, you should make every effort to detect when a precondition has been violated. If you detect that a precondition has been violated, then print an error message and halt the program. Well, there's no way of getting around it: The programmer who calls a function is responsible for making sure the precondition is valid. However, when you are writing a function with a precondition, you should make every attempt to try to detect when a precondition is violated. Such detections make things easier on other programmers - easier for them to debug, for example.

On the other hand, careful programmers also follow these rules:
When you write a function, you should make every effort to detect when a precondition has been violated. If you detect that a precondition has been violated, then print an error message and halt the program... ...rather than causing a disaster. And such detections can also avoid disasters.

Example void write_sqrt( double x) // Precondition: x >= 0. // Postcondition: The square root of x has // been written to the standard output. { assert(x >= 0); ... Here's an example of how you would write a friendly function which detects when its precondition is violated. There is no need for anything fancy when the precondition fails: just print an informative error message and halt the program. In this example, I have used the C++ assert function, which has a logical expression as its argument. If the expression is true, then the assert function does nothing. But if the expression is false, the assert function prints a useful message and halts the program. You can read about the full details of the assert function in Section 1.1 of the text. The assert function (described in Nyhoff p26-27) is useful for detecting violations of a precondition.

Advantages of Using Pre- and Post-conditions
Concisely describes the behavior of a function... ... without cluttering up your thinking with details of how the function works. At a later point, you may reimplement the function in a new way ... ... but programs (which only depend on the precondition/postcondition) will still work with no changes. Succinctly describes the behavior of a function... Here are the primary advantages to using a method such as preconditions/postconditions to specify what a function accomplishes without giving details of how the function works. One of the important advantages has to do with reimplementations. Often a programmer will think of a better method to accomplish some computation. If the computation is part of a function that includes a precondition/postcondition pair, then the function can be rewritten and the new, better function used instead. Any program which uses the function (and which only depends on the precondition/postcondition contract) can use the new improved function with no other changes.

Summary of pre- and post-conditions
Precondition The programmer who calls a function ensures that the precondition is valid. The programmer who writes a function can bank on the precondition being true when the function begins execution. Postcondition The programmer who writes a function ensures that the postcondition is true when the function finishes executing.

Welcome to CSIS 10B Overview of Course Software Design (from Nyhoff)

Similar presentations

Presentation on theme: "Welcome to CSIS 10B Overview of Course Software Design (from Nyhoff)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Welcome to CSIS 10B Overview of Course Software Design (from Nyhoff)

Similar presentations

Presentation on theme: "Welcome to CSIS 10B Overview of Course Software Design (from Nyhoff)"— Presentation transcript:

Similar presentations

About project

Feedback