Ch 1 in Data Structure

8/12/2019 Ch 1 in Data Structure

1/31

1

C++ Plus Data Structures

Nell Dale

Chapter 1

Software Engineering Principles


2/31

2

Software Design Process


3/31

3

Programming Life CycleActivities

Problem analysis understand the problem

Requirements definition speci fy what program w i l l do

High- and low-level design how i t meets requirements

Implementation of design code it

Testing and verification detect errors, show correct

Delivery turn over to customer

Operation use the prog ram

Maintenance change the prog ram


4/31

4

Software Engineering

A disciplined approach to the design,

production, and maintenance of

computer programs that are developed on time and within

cost estimates,

using tools that help to manage the

size and complexity of the resulting

software products.


5/31

5

Toolboxes:

Hardware.

Software

Ideaware (focus of the course!): the

shared body of knowledge that

programmers have collected over

time, including algorithms, data

structures, programming

methodologies, tools


6/31

6

An Algorithm Is . . .

A logical sequence of discrete steps

that describes a complete solution to

a given problem computable in a finiteamount of time.


7/31

7

Goals of Quality Software

It works.

It can be read and understood.

It can be modified.

It is reusable.

It is completed on time and within budget.


8/31


9/31

9

Writing Detailed Specifications

Detailed Program Specification Includes:

Inputs

Outputs

Processing requirements

Assumptions


10/31

10

Program Design

Software design use some ideaware tools such

as abstraction , information hiding , stepwise

refinement and visual tools.


11/31

11

Abstraction

A model of a complex system that

includes only the details essential to

the perspective of the viewerof the

system. (consider the essential

characteristics of the system only;

ignore minor or relative details )


12/31

12

Information Hiding

Hiding the details of a function or data

structure with the goal of controlling

access to the details of a module orstructure.

PURPOSE: To prevent high-level designsfrom depending on low-level design details

that may be changed.


13/31

13

Two Approaches to BuildingManageable Modules

Divides theproblem

intomore easily handled

subtasks,until the

functional modules(subproblems) can

be coded.

Identifies various

objects composed of

data and operations,

that can be usedtogether to solve

the problem.

FUNCTIONAL

DECOMPOSITION

OBJECT-ORIENTED

DESIGN

FOCUS ON: processes FOCUS ON: data objects


14/31


15/31

15

Object-Oriented Design

A technique for developing a program in which

the solution is expressed in terms of objects --

self- contained entities composed of data and

operations on that data.

Private data

>

get

ignore

cin cout


16/31

16

More about OOD

Languagessupporting OOD include: C++, Java,

Smalltalk, Eiffel, and Object-Pascal, C,

Aclassis a programmer-defined data type andobjects are variables of that type.

In C++, cinis an object of a data type (class) named

istream, and cout is an object of a class ostream.

Header files iostream.h and fstream.h containdefinitions of stream classes.

ifi i f S f


17/31

17

Verification of SoftwareCorrectness

Testing

Debugging

Program verification


18/31

18

Program Verification is the process of

determining the degree to which a

software product fulfills its specifications.

Program Verification

PROGRAM

SPECIFICATIONS

Inputs

Outputs

Processing

Requirements

Assumptions


19/31

19

Verification vs. Validation

Program verification asks,

Are we doing the job right?

Program validationasks,

Are we doing the right job?


20/31

20

Program Testing

Testing is the process of executing a

program with various data sets

designed to discover errors.

DATA SET 1

DATA SET 2

DATA SET 3

DATA SET 4

. . .


21/31

21

Origin of Bugs

Various Types of Errors:

Design errorsoccur when specificationsare wrong

Compile errorsoccur when syntax is wrong

Run-time errorsresult from incorrectassumptions, incomplete understanding ofthe programming language, or

unanticipated user errors.


22/31

22

Design for Correctness


23/31

23

Robustness

Robustness is the ability of a program to

recover following an error; the ability of a

program to continue to operate within its

environment.


24/31

24

An Assertion

Is a logical proposition that is either true or

false (not necessarily in C++ code).

EXAMPLES

studentCount is greater than 0

sum is assigned && count > 0

response has value y or n

partNumber == 5467


25/31

25

Preconditions and Postconditions

The precondition is an assertion describing

what a function requires to be true before

beginning execution.

The postcondition describes what must be

true at the moment the function finishes

execution.

The cal leris responsible for ensuring the

precondition, and the func t ion codemust

ensure the postcondition. FOR EXAMPLE . . .


26/31

26

Design Review Activities

Deskchecking: tracing an execution of adesign or program on paper (checklistFig1.5, pg32).

Walk-through: a verification method in whicha team performs a manual simulation of theprogram or design.

Inspection: a verification method in whichone member of a team reads the program ordesign line by line an the others point outerrors.


27/31

27

Program Testing

Unit Testing: testing a module or

function by itself

Data Coverage: testing all possibleinput values (Black Box Testing)

Code Coverage: testing program paths

(Clear/White Box Testing) Statement coverage

Integration Testing


28/31

28

Tasks within each test case:

determine inputs that demonstrate the goal.

determine the expected behaviorfor the

input.

run the program and observe resu l ts.

compareexpected behavior and actualbehavior. If they differ, we begin debugging.


29/31

29

Integration Testing

Is performed to integrate program modules

that have already been independently unit

tested.

Find

Weighted

Average

Print

Weighted

Average

Main

Print Data

Print Heading

Get DataPrepareFile for

Reading


30/31

30

Practical Considerations

Life C cle Verification


31/31

31

Life-Cycle VerificationActivities:

Analysis

Design

Code

Test

Delivery

Maintenance

It s From Bekham To All

Documents

Ch 1 in Data Structure