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

Slides:



Advertisements
Similar presentations
COM vs. CORBA.
Advertisements

Lecture 1: Overview of Computers & Programming
REUSABILITY, PORTABILITY,
Programming Creating programs that run on your PC
Software: Systems and Application Software
CS 501: Software Engineering Fall 2000 Lecture 16 System Architecture III Distributed Objects.
Chapter 1 Introduction to Object- Oriented Programming and Problem Solving.
Chapter 13 Physical Architecture Layer Design
1 Reusability and Portability Xiaojun Qi. 2 Reuse Concepts Reuse is the use of components of one product to facilitate the development of a different.
1 Lecture 1  Getting ready to program  Hardware Model  Software Model  Programming Languages  The C Language  Software Engineering  Programming.
Introduction to Computers and Programming. Some definitions Algorithm: –A procedure for solving a problem –A sequence of discrete steps that defines such.
Distributed Information Systems - The Client server model
Programming A Historic Perspective on Code Reuse Yingcai Xiao.
© Lethbridge/Laganière 2001 Chap. 3: Basing Development on Reusable Technology 1 Let’s get started. Let’s start by selecting an architecture from among.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
Systems Architecture, Fourth Edition1 Internet and Distributed Application Services Chapter 13.
Reusability and Portability Chapter 8 CSCI Reusability and Portability  The length of the development process is critical.  No matter how high.
Chapter 10 Application Development. Chapter Goals Describe the application development process and the role of methodologies, models and tools Compare.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 12 Slide 1 Distributed Systems Design 1.
CSE 1301 J Lecture 2 Intro to Java Programming Richard Gesick.
Principles of Programming Chapter 1: Introduction  In this chapter you will learn about:  Overview of Computer Component  Overview of Programming 
1 CSC 1401 S1 Computer Programming I Hamid Harroud School of Science and Engineering, Akhawayn University
Component Based Development
1 8/29/05CS360 Windows Programming Professor Shereen Khoja.
High thoughts must have high language. Aristophanes
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 1 Distributed Systems Architectures.
SAP R/3 System: Client Server Overview (Buck-Emden & Galimow, 1998) Dr. K. Palaniappan.
Slide 8.1 © The McGraw-Hill Companies, 2007 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach.
Quality Attributes of Web Software Applications – Jeff Offutt By Julia Erdman SE 510 October 8, 2003.
An intro to programming. The purpose of writing a program is to solve a problem or take advantage of an opportunity Consists of multiple steps:  Understanding.
OPC – OLE for PROCESS CONTROL By: Mugdha More. Swagata Bhaumik.
COM vs. CORBA Computer Science at Azusa Pacific University September 19, 2015 Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department.
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 13: Physical Architecture Layer Design Alan Dennis,
Slide 8.1 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R.
©Ian Sommerville 2000 Software Engineering, 6th edition. Slide 1 Component-based development l Building software from reusable components l Objectives.
Java Introduction Lecture 1. Java Powerful, object-oriented language Free SDK and many resources at
FALL 2005CSI 4118 – UNIVERSITY OF OTTAWA1 Part 4 Other Topics RPC & Middleware.
1 Chapter 38 RPC and Middleware. 2 Middleware  Tools to help programmers  Makes client-server programming  Easier  Faster  Makes resulting software.
Enterprise Java Beans Java for the Enterprise Server-based platform for Enterprise Applications Designed for “medium-to-large scale business, enterprise-wide.
CS 390- Unix Programming Environment CS 390 Unix Programming Environment Topics to be covered: Distributed Computing Fundamentals.
CSC 395 – Software Engineering Lecture 12: Reusability –or– Programming was Bjarne Again.
Ch 1. A Python Q&A Session Spring Why do people use Python? Software quality Developer productivity Program portability Support libraries Component.
CE Operating Systems Lecture 3 Overview of OS functions and structure.
Software Engineering, Lecture 4 Mohamed Elshaikh.
McGraw-Hill/Irwin Copyright © 2013 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 4 Computer Software.
Chapter 5 Information Systems in Business Software
CS 501: Software Engineering Fall 1999 Lecture 12 System Architecture III Distributed Objects.
A. Frank - P. Weisberg Operating Systems Structure of Operating Systems.
1 Chapter 38 RPC and Middleware. 2 Middleware  Tools to help programmers  Makes client-server programming  Easier  Faster  Makes resulting software.
Java – in context Main Features From Sun Microsystems ‘White Paper’
25 April Unified Cryptologic Architecture: A Framework for a Service Based Architecture Unified Cryptologic Architecture: A Framework for a Service.
Lecture 21: Component-Based Software Engineering
Software: Systems and Applications Software. The Importance of Software in Business time 1950today $ Software Hardware High Low.
Chapter 11  Getting ready to program  Hardware Model  Software Model  Programming Languages  Facts about C++  Program Development Process  The Hello-world.
CHAPTER 1 COMPUTER SCIENCE II. HISTORY OF COMPUTERS (1.1) Eniac- one of the worlds first computers Used more electricity than an entire city block of.
Lecture 1 Page 1 CS 111 Summer 2013 Important OS Properties For real operating systems built and used by real people Differs depending on who you are talking.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 15 System Architecture III.
Distributed Systems Architectures Chapter 12. Objectives  To explain the advantages and disadvantages of different distributed systems architectures.
CS223: Software Engineering
Component Object Model(COM)
CSE775 - Distributed Objects, Spring 2006
The Client/Server Database Environment
Ch > 28.4.
Computer Science I CSC 135.
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
Frameworks And Patterns
Component--based development
Software Engineering with Reusable Components
Tonga Institute of Higher Education IT 141: Information Systems
Tonga Institute of Higher Education IT 141: Information Systems
Presentation 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 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) COBOL logic structure 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 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 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 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