8/14/2019 schach5-chap15-14[1]

1/38

Slide 15.1

The McGraw-Hill Companies, 2002

Object-Oriented andClassical Software

Engineering

Fifth Edition, WCB/McGraw-Hill, 2002

Stephen R. Schachsrs@vuse.vanderbilt.edu

8/14/2019 schach5-chap15-14[1]

2/38

Slide 15.2

The McGraw-Hill Companies, 2002

CHAPTER 15

IMPLEMENTATION ANDINTEGRATION PHASE

8/14/2019 schach5-chap15-14[1]

3/38

Slide 15.3

The McGraw-Hill Companies, 2002

Overview

q Implementation and integration

q Testing during the implementation and

integration phase

q Integration testing of graphical user interfaces

q Product testing

q Acceptance testing

q CASE tools for the implementation and

integration phaseq CASE tools for the complete software process

8/14/2019 schach5-chap15-14[1]

4/38

Slide 15.4

The McGraw-Hill Companies, 2002

Overview (contd)

q Integrated environments

q Environments for business applications

q Public tool infrastructures

q Potential problems with environments

q Metrics for the implementation and integration

phase

q Air Gourmet Case Study: Implementation and

integration phaseq Challenges of the implementation and

integration phase

8/14/2019 schach5-chap15-14[1]

5/38

Slide 15.5

The McGraw-Hill Companies, 2002

Implementation and Integration Phase

q Up to now: Implementation followed by integration

Poor approach

q Better

Combine implementation and integration methodically

8/14/2019 schach5-chap15-14[1]

6/38

Slide 15.6

The McGraw-Hill Companies, 2002

Product with 13 Modules

8/14/2019 schach5-chap15-14[1]

7/38

Slide 15.7

The McGraw-Hill Companies, 2002

Implementation, Then Integration

q Code and test each module separately

q Link all 13 modules together, test product

as a whole

8/14/2019 schach5-chap15-14[1]

8/38

Slide 15.8

The McGraw-Hill Companies, 2002

Drivers and stubs

q To test module a, modules b, c, d must be stubs

Empty module, or

Prints message ("Procedure radarCalc called"), or

Returns precooked values from preplanned test cases

q To test modulehon its own requires a driver,which calls it

Once, or

Several times, or

Many times, each time checking value returned

q Testing moduledrequires driver and two stubs

8/14/2019 schach5-chap15-14[1]

9/38

Slide 15.9

The McGraw-Hill Companies, 2002

Implementation, Then Integration (contd)

q Problem 1

Stubs and drivers must be written, then thrown away

after module testing is complete

q Problem 2

Lack of fault isolation A fault could lie in anyof 13 modules or 13 interfaces

In a large product with, say, 103 modules and 108

interfaces, there are 211 places where a fault might lie

q Solution to both problems Combine module and integration testing

Implementation and integration phase

8/14/2019 schach5-chap15-14[1]

10/38

Slide 15.10

The McGraw-Hill Companies, 2002

Top-down Implementation and Integration

q If module m1 calls module m2,

then m1 is implemented andintegrated before m2

q One possible top-downordering is a, b, c, d, e, f, g, h, i, j, k, l, m

q Another possible top-downordering is a

[a] b, e, h [a] c, d, f, i

[a, d] g, j, k, l, m

8/14/2019 schach5-chap15-14[1]

11/38

Slide 15.11

The McGraw-Hill Companies, 2002

(contd)

q Advantage 1: Fault isolation

Previously successful test case fails when mNew is

added to what has been tested so far

q

Advantage 2: Stubs not wasted Stub expanded into corresponding complete module at

appropriate step

8/14/2019 schach5-chap15-14[1]

12/38

Slide 15.12

The McGraw-Hill Companies, 2002

(contd)

q Advantage 3: Major design flaws show up early

Logic modules include decision-making flow of

control

In the example, modules a, b, c, d, g, j

Operational modules perform actual operations of

module

In the example, modules e, f, h, i, k, l, m

q Logic modules are developed before

operational modules

8/14/2019 schach5-chap15-14[1]

13/38

Slide 15.13

The McGraw-Hill Companies, 2002

(contd)

q Problem 1

Reusable modules are not properly tested

Lower level (operational) modules are not tested

frequently

The situation is aggravated if the product is welldesigned

q Defensive programming (fault shielding)

Example:

if (x >= 0)y = computeSquareRoot (x, errorFlag);

Never tested with x < 0

Reuse implications

8/14/2019 schach5-chap15-14[1]

14/38

Slide 15.14

The McGraw-Hill Companies, 2002

Bottom-up Implementation and Integration

q If module m1 calls

module m2, then m2 isimplemented andintegrated before m1 One possible bottom-up

ordering isl, m, h, i, j, k, e, f, g, b, c, d, a

Another possible bottom-up ordering is

h, e, b

i, f, c, d

l, m, j, k, g [d]

a [b, c, d]

8/14/2019 schach5-chap15-14[1]

15/38

8/14/2019 schach5-chap15-14[1]

16/38

Slide 15.16

The McGraw-Hill Companies, 2002

(contd)

q Difficulty 1

Major design faults are detected late

q Solution

Combine top-down and bottom-up strategies makinguse of their strengths and minimizing their weaknesses

8/14/2019 schach5-chap15-14[1]

17/38

Slide 15.17

The McGraw-Hill Companies, 2002

Sandwich Implementation and Integration

q Logic modules

are implementedand integratedtop-down

q Operational

modules areimplemented andintegrated bottom-up

q Finally, theinterfacesbetween the twogroups are tested

8/14/2019 schach5-chap15-14[1]

18/38

Slide 15.18

The McGraw-Hill Companies, 2002

Sandwich Implementation and Integration (contd)

q Advantage 1

Major design faults are caught early

q Advantage 2

Operational modules are thoroughly tested

They may be reused with confidenceq Advantage 3

There is fault isolation at all times

8/14/2019 schach5-chap15-14[1]

19/38

Slide 15.19

The McGraw-Hill Companies, 2002

Summary

8/14/2019 schach5-chap15-14[1]

20/38

Slide 15.20

The McGraw-Hill Companies, 2002

Object-Oriented Implementation and Integration

q Object-oriented implementation and integration

Almost always sandwich implementation and integration

Objects are integrated bottom-up

Other modules are integrated top-down

8/14/2019 schach5-chap15-14[1]

21/38

Slide 15.21

The McGraw-Hill Companies, 2002

Management Issues during Implem. and Int.

q Example

Design document used by Team 1 (who coded module

m1) shows m1 calls m2 passing 4 parameters

Design document used by Team 2 (who coded module

m2) states clearly that m2 has only 3 parameters

q Solution

The implementation and integration. process must be

run by SQA

8/14/2019 schach5-chap15-14[1]

22/38

Slide 15.22

The McGraw-Hill Companies, 2002

Testing during Implem. and Integration Phase

q Product testing

Performed to ensure that the product will not fail its

acceptance test

q Failing the acceptance test is a disaster for

management The client may conclude that the developers areincompetent

Worse, the client may believe that the developers tried

to cheatq The SQA team must ensure that the product

passes its acceptance test

8/14/2019 schach5-chap15-14[1]

23/38

Slide 15.23

The McGraw-Hill Companies, 2002

Integration Testing of Graphical User Interfaces

q GUI test cases:

Mouse clicks

Key presses

And so on

q

Cannot be stored in the usual wayq We need special CASE tools

q Examples:

QAPartner

XRunner

8/14/2019 schach5-chap15-14[1]

24/38

Slide 15.24

The McGraw-Hill Companies, 2002

Strategy for Product Testing

q The SQA team must try to approximate the

acceptance test

q Black box test cases for the product as a whole

q Robustness of product as a whole

Stress testing (under peak load) Volume testing (e.g., can it handle large input files?)

8/14/2019 schach5-chap15-14[1]

25/38

Slide 15.25

The McGraw-Hill Companies, 2002

Strategy for Product Testing (contd)

q Check all constraints

Timing constraints

Storage constraints

Security constraints

Compatibilityq Review all documentation to be handed over to

the client

q Verify the documentation against the product

q The product (software plus documentation) is now

handed over to the client organization for

acceptance testing

8/14/2019 schach5-chap15-14[1]

26/38

Slide 15.26

The McGraw-Hill Companies, 2002

Acceptance Testing

q The client determines whether the product

satisfies its specificationsq Performed by

The client organization, or

The SQA team in the presence of client representatives,

or An independent SQA team hired by the client

8/14/2019 schach5-chap15-14[1]

27/38

Slide 15.27

The McGraw-Hill Companies, 2002

Acceptance Testing (contd)

q Four major components of acceptance testing

Correctness

Robustness

Performance

Documentationq (Precisely what was done by developer during

product testing)

8/14/2019 schach5-chap15-14[1]

28/38

Slide 15.28

The McGraw-Hill Companies, 2002

CASE tools for the Implem. and Integ. Phase

q Bare minimum:

Version control tools

Examples:

rcs, sccs, PCVS, SourceSafe

8/14/2019 schach5-chap15-14[1]

29/38

Slide 15.29

The McGraw-Hill Companies, 2002

CASE Tools for the Complete Software Process

q A large organization needs an environment

q A medium-sized organization can probably

manage with a workbench

q A small organization can usually manage with

just tools.

8/14/2019 schach5-chap15-14[1]

30/38

Slide 15.30

The McGraw-Hill Companies, 2002

Integrated Environments

q Usual meaning of integrated

User interface integration

Similar look and feel

Most successful on the Macintosh

q

There are also other types of integration

8/14/2019 schach5-chap15-14[1]

31/38

Slide 15.31

The McGraw-Hill Companies, 2002

Process Integration

q Environment supports one specific process

q Subset: Technique-based environment Formerly: method-based environment

Supports specific technique

Examples:

Structured systems analysis Petri nets

Usually comprises Graphical support for specification, design phases

Data dictionary

Some consistency checking

Some management support

Support and formalization of manual processes

Examples:

Analyst/Designer, Rose, Rhapsody (for Statecharts)

8/14/2019 schach5-chap15-14[1]

32/38

Slide 15.32

The McGraw-Hill Companies, 2002

Technique-Based Environments (contd)

q Advantage of technique-based environment

Forced to use specific method, correctly

q Disadvantages of technique-based environment

Forced to use specific method

Inadequate support of programming-in-the-many

8/14/2019 schach5-chap15-14[1]

33/38

Slide 15.33

The McGraw-Hill Companies, 2002

Environments for Business Application

q The emphasis is on ease of use

GUI

Standard forms for input, output

Code generator

Detailed design is lowest level of abstraction

Expect productivity rise

q Examples:

Foundation, Bachman Product Set

f

8/14/2019 schach5-chap15-14[1]

34/38

Slide 15.34

The McGraw-Hill Companies, 2002

Public Tool Infrastructure

q PCTEPortable common tool environment

NOT an environment

An infrastructure for supporting CASE tools (similar to

the way an operating system provides services for

user products)

Adopted by ECMA (European Computer

Manufacturers Association)

q Example implementations:

IBM, Emeraude

P t ti l P bl ith E i t

8/14/2019 schach5-chap15-14[1]

35/38

Slide 15.35

The McGraw-Hill Companies, 2002

Potential Problems with Environments

q No one environment is ideal for all organizations

Each has its strengths and weaknesses

q Warning 1

Choosing the wrong environment can be worse than no

environment Enforcing a wrong technique is counterproductive

q Warning 2

Shun environments below CMM level 3

We cannot automate a nonexistent process

A CASE tool or CASE workbench is fine

M t i f th I l d I t Ph

8/14/2019 schach5-chap15-14[1]

36/38

Slide 15.36

The McGraw-Hill Companies, 2002

Metrics for the Implem. and Integ. Phase

q The five basic metrics, plus

q Complexity metrics

q Number of test cases, percentage which

resulted in failure

q Total number of faults, by types

Ai G t C St d I l d I t Ph

8/14/2019 schach5-chap15-14[1]

37/38

Slide 15.37

The McGraw-Hill Companies, 2002

Air Gourmet Case Study: Impl. and Integ. Phase

q Complete C++ implementation,

q Complete Java implementation,

at www.mhhe.com/engcs/compsci/schach

Ch ll f th I l d I t ti Ph

8/14/2019 schach5-chap15-14[1]

38/38

Slide 15.38Challenges of the Implem. and Integration Phase

q Management issues are paramount here

Appropriate CASE tools

Test case planning

Communicating changes to all personnel

Deciding when to stop testing