Chapter 1Software

Engineering

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.

2

The Software Life Cycle

• Problem analysis• Requirements definition• Software specification• High- and low-level design• Implementation• Testing and Verification• Delivery• Operation • Maintenance

3

Goals of Quality Software

• It works.• It can be modified without excessive time

and effort.• It is reusable.• It is completed on time and within budget.

4

Software Specification

• A detailed description of the function, inputs, processing, outputs, and special requirements of a software product.

• It provides the information needed to design and implement the product

• Tells what the program must do, but not how it does it.

5

Abstraction

• A model of a complex system that includes only the details essential to the perspective of the viewer of the system.

• Programs are abstractions.

6

Information Hiding

• The practice of hiding the details of a module with the goal of controlling access to the details from the rest of the system.

• A programmer can concentrate on one module at a time.

• Each module should have a single purpose or identity.

7

Stepwise Refinement

• A problem is approached in stages. • Similar steps are followed during each

stage, with the only difference being the level of detail involved.

• Some variations:– Top-down– Bottom-up– Functional decomposition– Round-trip gestalt design

8

Two Approaches to Building Manageable Modules

Object-Oriented Design

FunctionalDecomposition

Divides the problem into more easily handled subtasks, until the functional modules (subproblems) can be coded.

Identifies variousobjects composed of data and operations,that can be used together to solve the problem.

Focus on: processes Focus on : data objects

9

Functional Design Modules

10

Object-Oriented Design

On

Off

Oven Egg

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.

SetSeparate

Crack

Private data Private data

11

Object-Oriented Design

• Class– A class describes a set of objects with the

same properties, behavior, and relationships– A class definition includes

• Attributes (properties)• Operations (behaviors)• Relations to other classes

– A class is similar to a data type with the addition of relations to other classes

12

Classes in Ada

• To build a class in Ada we use – the package along with – a special type called a tagged type

• To keep an object's data private we use– a special type called a private type

13

Packages

• Package A group of logically related entities that may include types and subtypes, objects of those types and subtypes, and subprograms with parameters of those types and subtypes.

• Package Specification The visible portion of a package; specifies what resources are supplied by the package.

• Package Body The implementation of a package.

14

Package Specificationfor Date Class

Dale and McCormick page 15• Simple types for class attributes• A type for the class (Date_Type)• Operations for the class

– Functions and Procedures• Private part that describes each object's

private data

15

UML Class Diagram for the Date Class

16

Classification of Operations

• Constructor An operation used to create new values of a class

• Observer An operation that returns an observation on the state of an object.

• More later…

17

Inheritance

• A powerful reuse tool. – Allows programmers to create a new class

that is a specialization of an existing class.– The new class is called a subclass of the

existing class.– The existing class is the superclass of the

new class.

18

UML Class Diagram Showing Inheritance

19

Classification of Operations

• Constructor An operation used to create new values of a class

• Observer An operation that returns an observation on the state of an object.

• Transformer An operation that changes the internal state of an object

20

Package Specificationfor Holiday Date

Dale and McCormick page 20• Child packages are used for subclasses

– Holiday is a child of package Date– Holiday_Date_Type is a subclass of Date_Type

• Operations for Holiday_Date objects include those defined in Date plus– New operations defined in Holiday.Date– Overridden operations that replace operations in the

superclass• New member data is added in the private part

21

Program Verification

Specifications• Inputs• Outputs• Processing

Requirements• Assumptions

The process of determining the degree to which a software product fulfills its specification.

Program

22

Verification (cont.)

Static verification Verifying a program without executing it.

Dynamic verification Verifying a program by executing it with a set of test data.

23

Verification vs. Validation

Program verification asks,“Are we doing the job right?”

Program validation asks,“Are we doing the right job?”

B.W. Boehm, Software Engineering Economics, 1981.

24

Types of Errors

• Specification• Design• Coding

25

Cost of a Specification Error Based on When It Is Discovered

26

Review Activities

Deskchecking Tracing an execution of a design or program on paper.

Walk-through A verification Method in which a team performs a manual simulation of the program or design

Inspection A verification method in which one member of a team reads the program or design line by line and the other point out errors.

27

Static Verification

Assertion A statement that is true or false but not both.

Preconditions Assertions of what must be true on entry into an operation for the postconditions to be guaranteed.

Postconditions Assertions that describe what results are expected at the exit of an operation, assuming that the preconditions were true.

Loop Invariant Assertion of what must be true at the start of each loop iteration and on exit from the loop.

28

Testing

The process of executing a program with data sets designed to discover errors.

Data Set 1

Data Set 2

Data Set 3

Data Set 4

29

Types of Testing (1)

Black-box testing Testing a program or operation based on the possible input values, treating the code as a “black-box.”

Clear (white)-box testing Testing a program or operation based on covering all of the branches or paths of the code.

30

Black-Box Testing(Data Coverage)

Functional Domain The set of valid input data for a program or operation.

Exhaustive Testing Testing with all the inputs in the functional domain.

31

Black-Box Testing(Example)

Develop a design and write a program to classify grapefruits received by a grocery wholesaler. The data for this program will be entered at the keyboard and consists of one line per grapefruit. Each line contains the grapefruit's diameter (in inches) and its condition (Excellent, Good, Fair, or Poor). The grapefruit's diameter is the first characteristic to consider in the classification as shown in the following table

Diameter GradeGreater than or equal to 4" ALess than 4" and greater than or equal to 3.5" BLess than 3.5" C

The above grades are for fruit in excellent condition. A fruit in Good condition is downgraded one level and a fruit in Fair condition is downgraded two levels. A fruit that is in Poor condition is downgraded three levels. Any grapefruit below grade C is rejected. 32

Black-Box Testing forClassification Program

Exhaustive Testing• All possible sizes (infinite number)• Four conditions

Impossible to do exhaustive testing of the grapefruit classification domain

33

Black-Box Testing forClassification Program

Subset of Functional Domain 12 tests• Three diameters (3 equivalence classes)• Four conditions (exhaustive)

34

Black-Box Testing forClassification Program

Boundary testing 6 tests

4.01” 3.51”4.00” 3.50”3.99” 3.49”

Run program 6 times with a single grapefruit in excellent condition

35

Clear-Box Testing(Code Coverage)

Branch A code segment that is not always executed; for example a case statement has as many branches as there are case alternatives.

Path A combination of branches that might be traversed during a single execution of a program or operation.– Path Testing A testing technique whereby

the tester tries to execute all possible paths in a program or operation.

36

A Flow Graph forPath Testing

37

Types of Testing (2)

Unit testing Testing a class or operation by itself.Integration testing Testing that is performed on

combined program modules that already have been independently tested.

Acceptance testing The process of testing the system in its real environment with real data.

Regression Testing Re-execution of program tests after modifications have been made in order to ensure the program still works correctly.

38

Integration Testing

• Is performed to integrate program modules that have already been independently unit tested.

FindWeighted Average

PrintWeighted Average

Main

Print Data

Print Heading

Get DataPrepare File for Reading

39

Integration Testing Approaches

Ensures correct overall design logic.

Ensures individual moduleswork together correctly, beginning with the lowest level.

TOP-DOWN BOTTOM-UP

USES: placeholder USES: a test driver to callmodule “stubs” to test the functions being tested.the order of calls.

40

Test Plan

• Document showing the test cases planned for a program, class, or operation; their goals, inputs, expected outputs and criteria for success.

• For program testing to be effective, it must be planned.

• Ideally written simultaneously with the program specification.

41

Life-Cycle Verification Activities

Analysis Make sure that requirements are completely understood.Understand testing requirements.

Specification Verify the identified requirements.Perform requirements inspections with your client.Write test plan system functionality.

Design Design for correctness (using assertions such as preconditions, postconditions, and loop invariants).

Perform design inspections.Plan testing approach.

Code Understand programming language well.Perform code inspections.Add debugging output statements to the program.Write test plan for unit testing of modules.Construct test drivers.

Test Unit test according to test plan.Debug as necessary.Integrate tested modules.Retest after corrections.

Delivery Execute acceptance tests of complete product.

Maintenance Execute regression test whenever delivered product is changed to add new functionality or to correct detected problems.

42