Lecture 12

ReengineeringComputer-aided Software EngineeringCleanroom Software Engineering

Reengineering

Business Process ReengineeringBusinessdefinition

Processidentification

ProcessEvaluation

ProcessSpecificationand Design

Prototyping

Refinement&

Instantiation

BPR PrinciplesOrganize around outcomes, not tasks. Have those who use the output of the process perform the process.Incorporate information processing work into the real work that produces the raw information. Treat geographically dispersed resources as though they were centralized. Link parallel activities instead of integrated their results.Put the decision point where the work is performed, and build control into the process.Capture data once, at its source.

Software Reengineeringinventoryanalysis

documentrestructuring

datarestructuring

reverseengineeringcode

engineering

restructuring

forward

Inventory Analysisbuild a table that contains all applicationsestablish a list of criteria, e.g.,

name of the applicationyear it was originally creatednumber of substantive changes made to ittotal effort applied to make these changesdate of last substantive changeeffort applied to make the last changesystem(s) in which it residesapplications to which it interfaces, ...

analyze and prioritize to select candidates for reengineering

RestructuringDocument Restructuring

options range from doing nothing to regeneration of all documentation for critical system

Reverse Engineeringthe intent here is to achieve design recovery

Code Restructuringrebuild spaghetti bowl code

Data Restructuringdata architecture

Reverse Engineeringdirty source code

restructurecode

extractabstractions

refine&

simplify

clean source code

initial specification

final specification

processing

interface

database

Forward Engineering1. Redesign using modern design concepts, can

greatly facilitate future maintenance.2. Because a prototype of the software already

exists, development productivity should be much higher than average.

3. The user now has experience with the software. Therefore, new requirements and the direction of change can be ascertained with greater ease.

4. CASE tools for reengineering will automate some parts of the job.

5. A complete software configuration will exist upon completion of preventive maintenance.

Computer-Aided Software Engineering

CASE… in its idealized form, CASE combines a set of software development tools that are integrated with a database to form an environment …

… the tools address each important step in the software engineering process …

… the tools increase insight thereby improving quality; reduce drudgery thereby improving productivity; and enhance control, thereby leading to on-time projects …

CASE Environment Model

Operating System

Portability Services

CASE Tools

Hardware Platform

Operating System

Portability Services

CASE Tools

Environment Architecture

Integration Framework

Challenge: Putting it Together

OperatingSystem

PortabilityServices

IntegrationFramework

IPSECASETools

An Integration Frameworkuser interface layer

object management layer

shared repository layer

tools layer

interface tool kitpresentation protocol

tools management services

CASE tool

integration servicesconfiguration management services

CASE databaseaccess control functions

Data Integration:The CASE Repository

CASE Database

Objects

Object Management Layer

integration services SCM services

Shared Repository Layer

database access control functions

A Taxonomy of CASE Toolsbusiness systems planning

project management

support

analysis and design

integration &testing

re–engineering

prototyping/simulation tools

CASEDatabase

programming

framework

Cleanroom Software Engineering

The Cleanroom Process Model

RequirementsGathering

Box StructureSpecification

FormalDesign

CorrectnessVerification

CodeInspection

StatisticalUse

Testing

Cerfification

Test Planning

SystemEngineering

RequirementsGathering

Box StructureSpecification

FormalDesign

CorrectnessVerification

CodeInspection

StatisticalUse

Testing

Cerfification

Test Planning

RequirementsGathering

Box StructureSpecification

FormalDesign

CorrectnessVerification

CodeInspection

StatisticalUse

Testing

Cerfification

Test Planning

Increment #1

Increment #2

Increment #n

The Cleanroom Strategy-IIncrement Planning—adopts the incremental strategy

Requirements Gathering—defines a description of customer level requirements (for each increment)

Box Structure Specification—describes the functional specification

Formal Design—specifications (called “black boxes”) are iteratively refined (with an increment) to become analogous to architectural and procedural designs (called “state boxes” and “clear boxes,” respectively).

Correctness Verification—verification begins with the highest level box structure (specification) and moves toward design detail and code using a set of “correctness questions.” If these do not demonstrate that the specification is correct, more formal (mathematical) methods for verification are used.

The Cleanroom Strategy-IICode Generation, Inspection and Verification—the box structure specifications, represented in a specialized language, are transmitted into the appropriate programming language.

Statistical Test Planning—a suite of test cases that exercise of “probability distribution” of usage are planned and designed

Statistical Usage Testing—execute a series of tests derived from a statistical sample (the probability distribution noted above) of all possible program executions by all users from a targeted population

Certification—once verification, inspection and usage testing have been completed (and all errors are corrected) the increment is certified as ready for integration.

Box Structure Specification

BB1

BB1.1

BB1.2

BB1.n

BB1.1.1

BB1.1.2

BB1.1.3

SB1.1.1

CB1.1.1.1

CB1.1.1.2

CB1.1.1.3

black box

state box

clear box

Box Structures

f:S* RS R

black box

state box

clear box

S Rblack box, g

State

T

S R

StateT

g11

g12

g13

cg1

Design Refinement & VerificationIf a function f is expanded into a sequence g and h, the

correctness condition for all input to f is:

• Does g followed by h do f?

When a function f is refined into a conditional (if-then-else), the correctness condition for all input to f is:

• Whenever condition <c> is true does g do f and whenever <c> is false, does h do f?

When function f is refined as a loop, the correctness conditions for all input to f is:

• Is termination guaranteed?

• Whenever <c> is true does g followed by f do f, and whenever <c> is false, does skipping the loop still do f?

Advantages of Design Verification

It reduces verification to a finite process. It lets cleanroom teams verify every line of design and code. It results in a near zero defect level. It scales up. It produces better code than unit testing.

Cleanroom Testing

statistical use testingtests the actual usage of the program

determine a “usage probability distribution”analyze the specification to identify a set of stimulistimuli cause software to change behaviorcreate usage scenariosassign probability of use to each stimulitest cases are generated for each stimuli according to the usage probability distribution

Certification

Usage scenarios must be created.A usage profile is specified.Test cases are generated from the profile.Tests are executed and failure data are recorded and analyzed.Reliability is computed and certified.

Certification ModelsSampling model—Software testing executes m random test cases and is certified if no failures or a specified numbers of failures occur. m is derived mathematically to ensure that required reliability is achieved.Component model—A system composed of n components is to be certified and enables the analyst to determine the probability that component i will fail prior to completion.Certification model—The overall reliability of the system is projected and certified.