Uploaded by mfa_1976

OO analysis Lecture12

advertisement
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.
Why So Little Software Reuse?



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?
Why So Little Software Reuse?






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
Raytheon Study Results
Library
Raytheon Study Results





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
Group
Group
Group
1:
2:
3:
4:
reused with no changes
reused with slight revisions
reused with major revisions
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
Development
Maintenance
% of total cost over
product lifetime
33%
67%
% savings over product
Lifetime due to reuse
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
Download