CSC 330 Object-Oriented Software Design - City … 330 Object-Oriented Software Design REUSABILITY 2...

51
1 CSC 330 Object-Oriented Software Design REUSABILITY REUSABILITY

Transcript of CSC 330 Object-Oriented Software Design - City … 330 Object-Oriented Software Design REUSABILITY 2...

1

CSC 330 Object-Oriented Software Design

REUSABILITYREUSABILITY

2Overview

Reuse conceptsImpediments to reuseReuse case studiesObjects and reuseReuse during the design and implementation phasesReuse and maintenance PortabilityTechniques for achieving portability

3Reuse Concepts

Two types of reuse– Accidental reuse

» First, product is built» Then, parts put into part database for reuse

– Planned reuse» First, reusable parts are constructed» Then, products are built using these parts

4Why reuse?

Minor Reason– It is expensive to design, implement, test, and

document software – Only 15% of new code serves an original purpose

(average)– Reuse of parts saves

» Design costs» Implementation costs» Testing costs» Documentation costs

Major Reason– Maintenance

Maintenance consumes two-thirds of software cost

5Raytheon Missile Systems Division

Data-processing softwarePlanned reuse of– Designs

» 6 code templates

– COBOL code» 3200 reusable

modules

Reuse rate 60% (1976–1982)

6Toshiba Fuchu Works, Tokyo

Industrial process control systemsAccidental reuse of– Specifications– Designs– Modules– Contracts– Manuals– Standards

Reuse rate (1985)33% design48% code

7NASA Software

Ground support system for unmanned spacecraft controlManagement permitted (but did not encourage) accidental reuseAccidental reuse of– Modules

Reuse rate (1982)– 28% reused unchanged– 10% reused with minor changes

8GTE Data Services

Data-processing softwareStrongly encouraged by management– Cash incentives when module was accepted for reuse– Cash incentive when module was reused

Accidental reuse of – Modules

Reuse rate– (1988) 15% reused code, $1.5 million saved – (est. 1989) 20% reused code– (est. 1993) 50% reused code

9Hewlett-Packard

Implemented in many divisions of the companySoftware Technology Division– Accidental reuse of resource planning software– 4.1 faults per KLOC of new code, 0.9 for reused

code– Overall fault rate decreased 51%– Productivity increased 57%– Cost $1 million, savings $4.1 million (1983–92)

10Hewlett-Packard (contd)

San Diego Technical Graphics (STG)– Planned reuse of firmware for printers– Cost $2.6 million, savings $5.6 million (1987–94)– 24% reduction in faults– 40% increase in productivity– Cost of developing reusable firmware—11% more– Cost of reusing it—19% of developing from scratch

11European Space Agency

Ariane 5 rocket blew up 37 seconds after lift-offCost: $500 millionReason: attempt to convert 64-but integer into 16-bit unsigned integer, without Ada exceptionhandlerOn-board computers crashed, so did rocketConversion was unnecessary– Computations on the inertial reference system can stop

9 seconds before lift-off– But, if there is a subsequent hold in countdown, it takes

several hours to reset the inertial reference system– Computations therefore continue 50 seconds into flight

12European Space Agency (contd)

Cause of problem– Ten years before, it was mathematically proven that

overflow was impossible—on the Ariane 4– Because of performance constraints, conversions that

could not lead to overflow were left unprotected– Software was used, unchanged and untested, on

Ariane 5– But, the assumptions for the Ariane 4 no longer held

Lesson– Software developed in one context needs to be

retested when integrated into another context

13Size of Reused Components

NASA– Most reused components were small

Toshiba– Many large components were reused

GTE– Many large components were reused

Reason– A strong managerial commitment for reuse is needed

14Reuse During Design and Implementation

Design reuse– Library or toolkit– Framework– Design pattern– Software architecture

15Library or Toolkit

Set of reusable routinesExamples:– Scientific software– GUI class library or toolkit

The user is responsible for the control logic (white in figure)

16Application Framework

Control logic of the design“Hot spots” (white in figure)Faster than reusing toolkitMore of design is reusedThe logic is usually harder to design than the operations

17Design Pattern

A solution to a general design problemIn the form of a set of interacting classesThe classes need to be customized (white in figure)

18Widget Generator

Tool that uses the set of classes created by the widget generator

19Abstract Factory Pattern

Abstract classes and abstract (virtual) methodsThe interfaces between client and program and generator are abstractThe application program is uncoupled from the specific operating system

20Software Architecture

Encompasses a wide variety of design issues, including:– Organization in terms of components– How those components interact

21Reuse of Software Architecture

Architecture reuse can lead to large-scale reuseOne mechanism:– Software product lines

Case study: – Hewlett-Packard printers (1995 to 1998)

» Person-hours to develop firmware decreased by a factor of 4» Time to develop firmware decreased by factor of 3» Reuse has increased to over 70% of components

22Reuse and Maintenance

Reuse impacts maintenance more than developmentAssumptions– 30% of entire product reused unchanged– 10% reused changed

Savings during maintenance are nearly 18% Savings during development are about 9.3%

23Objects and productivity

Reuse achieved– Not via modules with functional cohesion,– but via objects (informational cohesion)

[classes]In general– Software costs have decreased– Overall quality has improved– Large products are essentially collection of

smaller products

24Difficulties and Problems

Learning curve– Particularly noticeable with GUI

Problems with inheritance– New subclass does not affect its superclass– But, any change to a superclass affects all its

subclasses– Subclasses low in the inheritance tree can be huge

(inherited attributes)Polymorphism and dynamic binding– Maintenance problems were already discussed

25Incompatibilities

Hardware (disk, tape, characters, parity)Operating system (JCL, virtual memory)Numerical software (word size, Ada)Compiler– FORTRAN – Pascal – COBOL – C– Ada – C++– Java

26Why Portability?

Difficulties hampering portability– One-off software– Hardware incompatibility– Lifetimes of software, hardware– Multiple copy software

Portability saves money!

27Portability strategies

Portable system software– Isolate implementation-dependent

pieces» UNIX kernel, device-drivers

– Levels of abstraction» Graphics

28Object-Oriented Principles

OOP

Encapsulation(class)-- Information Hiding-- Separation of

Interface and Implementation-- Standardization-- Access Control mechanisms

(private /public)

Inheritance-- Hierarchy-- Reusability-- Extensibility-- Expressive power-- Reflects many real-world problems

Polymorphism--Many forms of same function-- Virtual functions-- Abstract Base

Classes

29Why Object-oriented paradigm?

Separation of interface and implementation: – Any implementation change should not affect user

interface.– To ease design process: Separation of Design

definition, Implementation, Usage through data encapsulation.

Software reuse :– To allow (1) sharing, (2) upgrades (3) modification

using inheritance and polymorphism.– Parameterized classes in templates.

30From problem to OO solution

Identify the objects (“nouns”) in the problem.Define and implement classes to represent the objects.– Class name– Data members : public, private, (protected)– Function members

» Service functions (usually public)» Utility functions (usually private)» Predicate functions. Example: warnings, status

indicators, error indicators, etc. Write a driver that carries out the interaction among the objects.

31Basic syntax : class definition

class class_name{public:

list of class attributes (variables, types, constants, and so on) that may be accessed by name from outside the class.

list of prototypes for each member function that may be accessed by name from outside the class.

private: list of class attributes (variables, types, constants, and so on) that are intended

to be hidden for reference from outside the class.list of prototypes for each member function intended to be hidden from outside

of the class.};

32

Object-Oriented Principles

Using inheritance to promote software reusabilityUse multiple inheritance to derive a class from several base classes

33Inheritance

Software reusability.Create new (derived) class from existing (base) class or classes.New derived class is to inherit the data members and member functions of a previous defined base class.New derived class can have its own members (attributes and behaviors) .

34Inheritance

In addition, new class can embellish the members (attributes and behaviors) of base class.Derived class can be large, but more specific.Derived class can also be a base class for future derived class.Single inheritance: derived from one base classMultiple inheritance: derived from multiple base classes.

35Example InheritanceExample Inheritance

Inheritance forms tree-hierarchical structureExamples:

Shape

TwoDimensionalShape ThreeDimensionalShape

circle square triangle sphere cube tetrahedron

How to define a derived class?

class TwoDimensionalShape : public Shape {… };

This is public inheritance.

36

Multiple Inheritance

37Definition of Class Base1

class Base1 {public:

Base1(int x) { value = x; }int getData( ) const { return value; }

protected:int value;

};

38Definition of Class Base2

class Base2 {public:

Base2(char c) { letter = c; }char getData( ) const {return letter; }

protected:char letter;

};

39Definition of Class Derived

// multiple inheritanceclass Derived : public Base1, public Base2{ friend ostream &operator << (ostream &

const Derived &);public:

Derived(int, char, double);double getReal( ) const;

private:double real;

};

40Member Function Definitions for Class Derived

Derived::Derived(int i, char c, float f): Base1(i), Base2(c)

{ real = f; }double Derived::getReal( )const { return real; }ostream &operator<<(ostream &output,

const Derived &d){

output << “ Interger: ” << d.value << endl<< “ Character: ” << d.letter << endl<< “Real number: ” << d.real;

return output;}

41Driver for Multiple Inheritance Example

int main( ){

Base1 b1( 10 ), *base1Ptr = 0;Base2 b2( ‘z’ ), *base2Ptr = 0;Derived d(7, ‘A’, 3.5 );cout<<“Object b1 contains integer”< b1.getData()

<<“\nObject b2 contains char ”<< b2.getData( )<<“\nObject d contains:\n”<< d << “\n\n”;

cout<<“Data members of Derived can be”<<“ accessed individually:”<<“\n Integer: ” << d.Base1::getData( )<<“\n Character:”<< d.Base2::getData( )<<“\nReal number: ”<< d.getReal( ) << “\n\n”;

42Driver for Multiple Inheritance Example

cout << “Derived can be treated as an ”<< “object of either base class:\n”;

base1Ptr = &d;cout << “base1Ptr->getData( ) yields ”

<< base1Ptr->getData( ) << ‘\n’;

base2Ptr = &d;cout << “base2Ptr->getData( ) yields ”

<< base2Ptr->getData( ) << endl;return 0;

}

43

Points to Remember

Software Engineering Observations

44Software Engineering Observations

A derived class cannot directly access private members of its base class.

45Software Engineering Observations

Suppose we create an object of a derived class where both the base class and the derived class contain objects of other classes.

When an object of that derived class is created, first the constructors for the base class’ member objects execute, then the base-class constructor executes, then the constructors for the derived class’ member objects execute, then the derived class constructor executes.

Destructors are called in the reverse of the order in which their corresponding constructors are called.

46Software Engineering Observations

In inheritance, base-class constructors are called in the order in which inheritance is specified in the derived-class definition. The order in which the base-class constructors are specified in the derived-class member initializerlist does not affect the order of construction.

47Software Engineering Observations

Creating a derived class does not affect it’s base class’s source code or object code; the integrity of a base class is preserved by inheritance.

48Software Engineering Observations

In an object-oriented system, classes are often closely related. “Factor out” common attributes and behavior and place these in a base class. Then use inheritance to form derived classes.

49Software Engineering Observations

A derived class contains the attributes and behaviors of its base class.

A derived class can also contain additional attributes and behaviors.

With inheritance, the base class can be compiled independent of the derived class. Only the derived class’s incremental attributes and behaviors need to be compiled to be able to combine these with the base class to form a derived class.

50Software Engineering Observations

Modifications to a base class do not require derived classes to change as long as the publicand protected interfaces to the base class remain unchanged. Derived classes may, however, need to be recompiled.

51Software Reusability

Focus on use of classes (object oriented programs) make possible general classes that are applicable to other projectsClass libraries exist and may be searched for classes which you can use or adapt for your project