OO analysis_Lecture12.ppt

Object-Oriented
Analysis and Design
Lecture 12
Reusability, Portability, and
Interoperability
(from Schach, “O-O and Classical Software Engineering”)

Why Reinvent the Wheel?
 Portability: Easier to move an existing
product to a new platform than to
rewrite it for the new platform.
 Reuse: Using part of one product when
building a new product.
 Can reuse code, designs, documentation
 Accidental reuse
 Deliberate reuse

Deliberate Reuse
 Code written for reuse will likely be
 More robust
 Better documented
 More thoroughly tested
 Have a uniform style (maintenance easier)
 More expensive
 May never be reused…

Why So Little Software Reuse?
 “Every new machine is different.”
 Rewrite multiplication and other math routines,
I/O, function calling, everything.
 But most new machines today reuse an
existing instruction set.
 So build and reuse a basic API (basic
operating system calls, like Win32)
 We do reuse function and class libraries.

 On average, only 15% of any software
product does something new (Capers
Jones).
 Examples of 40% reuse have been
reported.
 Why doesn’t everyone reach this level?

 Not invented here syndrome. Solution?
 Reused bugs are still bugs. Solution?
 How to find the right component to reuse?
Solution?
 Reuse is expensive. Solution?
 Legal issues with contract software. Solution?
 COTS software isn’t source code. Solution?
?? Kangaroos and Stinger missiles ??

Case Study: Raytheon, 1976
 Study if deliberate reuse of designs and code
possible.
 5000 COBOL programs examined; conclude
business programs have only six basic
actions:
 Sort data
 Edit/manipulate data
 Combine data
 Explode data
 Update data
 Report on data

Raytheon Study Results
 Identified 3200 reusable functional
modules (sequential update, edit
routine, tax computation,…)
 New apps have 60% reuse rate
 More reliable, less testing
 Added to a program using copy (like
import or #include)
 Shorter code, easier maintenance

 Identified COBOL
program logic
structures (like
sequential update)
 Functionality is
inserted (from the
library modules) COBOL
logic
structure
Library

 7 years later, logic structures reused 5500
times.
 60% of code inserted into logic structures
came from library.
 50% increase in productivity.
 Hoped for 70% reduction in maintenance
costs.
 Maintenance data never collected; division
closed…

Case Study: Toshiba, 1985…
 Industrial process control software, for
 Electric power networks
 Nuclear power generation
 Factory automation
 Traffic control
 2300 technical & managerial folks
 Very serious production management!

Toshiba: Measurements
 60% FORTRAN, 20% assembler-like,
20% other.
 Productivity measured in equivalent
assembler source lines.
 One line of 3GL = 4 EASL.
 Output in 1985: 7.2 million EASL.
 Projects: 1M to 21M EASL

Toshiba: Measurements
 Waterfall model, productivity measured in
EASL, by project and by programmer.
 Productivity gains 8-9% per year.
 Fault rate by programmer; expected to
decrease yearly (no numbers given).
 Reuse:
 Documentation: 32%
 Design: 33%
 Code: 48%

Toshiba: Reuse
 All “accidental”
 Designs, spec, contracts, manuals…
 Committee selects components to enter
“software components database,”
keyword indexed.
 Statistics kept on every aspect of reuse.

NASA Software
 25 products studied, ground support for
unmanned missions.
 3,000 to 112,000 lines of source code.
 7188 component modules, classified
 Group 1: reused with no changes
 Group 2: reused with slight revisions
 Group 3: reused with major revisions
 Group 4: developed from scratch

NASA
 2954 FORTRAN components examined in
detail.
 Group 1: 28%
 Group 2: 10%
 Group 3: 7%
 Reused modules were small, well
documented, simple interfaces, little I/O,
terminal nodes in a module interconnection
diagram.

GTE Data Services
 Management incentives for reuse: $50-
$100 paid for module accepted for
possible reuse; royalties too.
 Managers’ budgets increased when
their projects showed high reuse levels.
 Reuser of the Month award!

GTE
 1988: 14% reuse, saved $1M.
 1989: 20% reuse
 …
 1993: predicted 50% reuse, predicted $10M
savings
 Reuse library: 190 components in 1988, 128
in 1990.
 Emphasis on large modules: 10,000 lines or
more.

Hewlett-Packard
 Manufacturing productivity section:
 Fault rate for new code: 4.1 per KLOC
 Fault rate for reused code: 0.9 per KLOC
 Overall fault rate dropped to 2.0 per KLOC
 Program cost $1M, saved $4.1M
 Technical Graphics division:
 A single product - 20,000 lines of C - developed
over 3 years, then reused many times.
 Productivity up 40%, delivery time down 24%

European Space Agency
 In 1996, ESA launches first Ariane 5
rocket.
 A software fault caused it to crash 37
seconds into its flight ($500M loss).
 The cause: attempt to convert 64-bit
integer into 16-bit unsigned integer.
 An Ada exception occurred, but no
exception handler.

ESA
 Why no exception handler?
 To save space, conversions that “couldn’t
possibly result in overflow” weren’t given
handlers.
 The code was 10 years old, from Ariane 4.
 The troublesome (!) conversion was
checked for Ariane 4, but not for Ariane 5.
 Moral: retest reused code when used in a
new context!

Design Reuse
 Think of a library as a set of related reusable
routines (e.g., C standard library, Java AWT).
 If the library is O-O, these can really be
reusable designs.
 Choose the class you want to use, then reuse that
class and the entire design above it in the class
hierarchy.
 Here, the designer is responsible for the logic
that glues the reused parts together.

Design Reuse
 An application framework incorporates
the control logic of the design.
 The designer reuses the framework,
plugging application-specific operations.
 Examples:
 Application classes in MFC
 Classes for ATM software

Design Reuse
 O-O Patterns (Gang of Four).
 Abstract Factory
 Decorator
 Singleton
 Software Architecture
 Object-oriented
 Pipes and filters
 Client-server

Reuse and Maintenance
 Suppose 40% reuse of the entire
product.
 Suppose 3/4 of the reused components
are used unchanged.
Activity % of total cost over
product lifetime
% savings over product
Lifetime due to reuse
Development
Maintenance
33%
67%
9.3%
17.9%

Portability
 Cutting costs:
 Write a product so that can be run on
multiple platforms
 Sell the product for multiple platforms
 But the biggest issue is that clients
change hardware every 4 years or so.
 A product is portable if it’s less
expensive to adapt rather than rewrite.

Hardware Incompatibilities
 Different character codes (ASCII, EBCDIC,
unicode)
 Different formatting conventions (Mac vs. PC)
 Different byte sizes/word lengths
 There is an economic incentive for some of
this.
 A program that runs on an IBM System 360
machine built in 1964 will run on an S/390
built in 2001 (bit won’t run on a Sun
machine!).

Other Incompatibilities
 Differences in job control language
 Virtual memory vs. overlays
 How big is an int? If you assume 32 bits, you
can’t port to a 16 bit machine.
 Does a compiler for the target machine exist?
 Has the source platform’s compiler been
“enhanced”?
 Is there really a language standard?

Why Portability?
 How many platform/OS combinations
will you want to move to? Maybe not
many right now, but:
 Software has a longer life than hardware
 A business may buy upwardly compatible
hardware, or it may not.

Achieving Portability
 Write in a standard high-level language
 But what about portable system
software? Ex: localization of UNIX
 Originally 10,000 lines of code
 The kernal (1000 lines) written in
assembler.
 9000 lines in C, 1000 lines machine
dependent.

Interoperability
 Think of a word processor document that
includes a table of numbers, taken from a
spreadsheet program.
 How can the numbers be kept consistent as
they change?
 One way would be to have the word
processor invoke the spreadsheet program.
 Interoperability: the mutual cooperation of
object code from different vendors, running
on different platforms.

COM
 Started as object linking and embedding
(OLE), to do the word processor/spreadsheet
thing.
 Became Component Object Model, then
ActiveX
 COM specifies a common mechanism for
interprocess communication, through a
component library.
 COM components have public interfaces.

CORBA
 Uses an object request broker (ORB)
 This is middleware
 Independent of the communications
mechanism between platforms
 Several different implementations
 Much simpler than COM (what wouldn’t
be?)

Trends
 JavaBeans
 Enterprise JavaBeans
 Microsoft’s Distributed interNet
Architecture
 .NET
 XML

OO analysis_Lecture12.ppt

More Related Content

Similar to OO analysis_Lecture12.ppt (20)

Recently uploaded (20)

OO analysis_Lecture12.ppt