object-oriented analysis and design lecture 12 reusability, portability, and interoperability (from...
Post on 20-Dec-2015
220 views
TRANSCRIPT
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
Raytheon Study Results Identified COBOL
program logic structures (like sequential update)
Functionality is inserted (from the library modules)
CO
BO
L lo
gic
str
uct
ure
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 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 productLifetime 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?)