REUSABILITY, PORTABILITY, AND INTEROPERABILITY,

Overview Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies , Interoperability.

Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies, Interoperability.

Reuse Introduction If reinventing the wheel were a criminal offense, many SW engineers would languish in jail, How many different COBOL payroll programs does the world need? There are tens of thousands (if not hundreds of thousands) of these, Why SW Eng delight in reinventing the wheel over and over again? (Ego?) ,

Taxonomy SW is portable if it is significantly easier to modify it in order to run it over another compiler / hardware / operating system than to recode it from scratch, Reuse refers to taking components of one product in order to facilitate another , We might reuse a module, a code fragment, a design, a part of manual, a set of test data or duration and cost estimate.

Reuse Types Accidental reuse: Planned reuse: First, product is built. Then, parts put into other products for reuse , Planned reuse: First, reusable parts are constructed, Then, products are built using these parts.

“Planned” components are: More likely to be easy and safe for reuse, Generally – well documented and thoroughly tested, Display uniformity of style, Making maintenance easier , Probably more expensive to implement (Really?).

Reuse Chronicles … In the beginning… there was no reuse – as there was nothing already written, Than, subroutine libraries appeared – square root or sine procedures, Run time support routines, managing the stack etc. , Large scale statistical libraries – e.g. SPSS.

Reuse Chronicles (Cont’d) Class libraries – Eiffel, CASE tools which assist libraries scanning, C++ Standard Template Library (STL) , Application programming interface (API) – win32 etc.

Why Reuse? … Minor reasons: It is expensive to design, implement, test, and document SW, Only 15% of new code serves an original purpose (average) , Reuse of parts saves: Design costs, Implementation costs, Testing costs, Documentation costs.

Maintenance! Maintenance consumes two-thirds of SW cost. Why Reuse? (Cont’d) Major reason: Maintenance! Maintenance consumes two-thirds of SW cost.

How much reuse can we expect? Theoretical – the maximum rate is 85% , What can we get in practice? (~40%).

Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies, Interoperability.

Impediments to Reuse … NIH: (Not Invented Here) syndrome, Solutions: Awareness, management awareness and action, Quality: Concerns about faults in potentially reusable routines, Solution: Exhaustive testing to reuse routines , Storage – retrieval: Solution: technical issue, (discipline?).

Impediments to Reuse (Cont’d) Cost of reuse: It costs to make something usable, (60% more, 200% more. 480% more… depends whom we ask…), It cost to re-use it, It costs to define and manage the reuse process , Solution: research – does it worth the investment? (ROI) , Legal issues: The product might belongs to the client, Solution: legal / contract issue.

Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies, Interoperability. Consider the next case studies (1975 through 2000).

1 – Raytheon Missile Div. [1976] - Data-processing SW, Over 5,000 COBOL products were analyzed and classified, Reuse of: Program logic structure. Functional module, Reuse rate 60% (1976–1982)! Code was obtained by copy (similar to C #include), Template usage, Real benefit: maintenance became much easier ,

2 – Toshiba Fuchu Works, Tokyo [1984] - Fuchu works: industrial process control systems. Develops for electric power networks, nuclear power generators, factory automation and traffic control. Develops SW for the above: staff of 2,300 SW employees. 1.8 MLOC/year (or 7.2 MEASL/year), Products size – 1 – 21 MEASL. Accidental reuse of: specifications, designs, modules, contracts, manuals and standards, Reuse committee: Which components are suitable for reuse DB, Increase of annual productivity of 8%-9%, Reuse: 33% in new design , Reuse: 48% in new code.

Functional Cohesion? 3 – NASA SW [1989] - Ground system for unmanned spacecraft control, Management permitted (but did not encourage) accidental reuse, there was no process nor tools to support the reuse methodology, Accidental reuse of modules, Reuse rate (1982): 28% reused unchanged. 10% reused with minor changes, Main Result: In general, the reused modules were small, well documented, with simple interfaces and little input/output processing, and tended to be terminal nodes in a module interconnection diagrams… , Functional Cohesion?

4 – GTE Data Services [1988 – 1993] Data-processing SW, Strongly encouraged by management: Cash incentives when module was accepted for reuse. Cash incentive when module was reused (royalties). “Reuse of the month” award, Accidental reuse of modules, Reuse rate, (1988) 15% reused code, $1.5 million saved. (Est. 1989) 20% reused code. (Est. 1993) 50% reused code , Reuse library dropped from 190 [’88] to 128 [’90]!

5 – Hewlett-Packard [1983 – 1992] … Implemented in many divisions of the company , 5A. SW technology division: Accidental reuse of resource planning SW, 4.1 faults per KLOC of new code, 0.9 for reused code, Overall fault rate decreased 51%, Productivity increased 57% (to 1.1 KLOC person/month), Cost $1 million, savings $4.1 million (1983–92), The project broke even in its second year!

Hewlett-Packard (Cont’d) 5B. 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, Time delivery for a product decreased in 24%, Cost of developing reusable firmware — only 11% more! , Cost of reusing it — 19% of developing from scratch!

6 – European Space Agency [4.6.1996] - Ariane 5 rocket blew up 37 seconds after lift-off, Cost: $500 million, Reason: attempt to convert 64-but integer into 16-bit unsigned integer, without Ada exception handler, On-board computers crashed, so did rocket, Conversion was unnecessary! Computations on the inertial reference system (IRS) can stop 9 seconds before lift-off. But, if there is a hold in countdown, it takes several hours to reset the inertial reference system. Thus, computations continue 50 sec. into flight ,

European Space Agency (Cont’d) 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. SW was used, unchanged and untested, on Ariane 5. But, the assumptions for the Ariane 4 no longer held , Lesson: SW developed in one context needs to be retested when integrated into another context.

Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies, Interoperability.

Objects and Reuse … Claim of Composite/Structure Design C/SD: Ideal module has functional cohesion ((אחדות, Self-contained and independent, hence, Problem: What about the data on which the module operates?, If the module is to be reused – so its data , We cannot reuse a module unless the data are identical.

Objects and Reuse (Cont’d) … Claim of CS/D: Next best module has informational cohesion, This is an object (an instance of a class), An object comprises both data and action , This promotes reuse!

Objects and Reuse (Cont’d) … Phenomena with the OOD: The first time anything new is done, it take longer than on subsequent occasion. This initial period is sometimes referred to as the learning curve,

Objects and Reuse (Cont’d) Shifting to OOP – things might take even longer, Under the OOP – products are becoming larger. Later – things will improve greatly, Inheritance problem: any change to a class will affect its descendants. Objects lower in the inheritance hierarchy can quickly get large – resulting storage problems. Use inheritance whenever appropriate , Polymorphism and dynamic binding are adding to the OOD complexity.

Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies, Interoperability.

Reuse During Design and Implementation Reuse of previous designs: Probably when developing a product-line, Accelerates the design phase, Will lead to reuse code , Design reuse – approach extensions: Library or toolkit. (Mathematical lib, GUI lib etc.), Application framework, Design pattern, SW architecture.

Design Reuse (DR) – Library or Toolkit Set of reusable routines, Examples: Scientific SW, GUI class library or toolkit, The user is responsible for the control logic, Problem: libraries are presented as a set of subroutines, rather than reusable designs. Problem might be alleviated by the usage of CASE tools displaying the inheritance tree ,

DR – Application Framework Control logic of the design, Examples: Classes for a compiler design. The design team will have to provide classes specific to the language and the target machine, Design of an ATM machine, Faster than reusing a toolkit, More of design is reused, The logic is usually harder to design than the operations, MacAPP, Microsoft Foundation Class – MFC, ,

DR – Design Pattern … Christopher Alexander (architect): “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that can use this solution a million times over, without ever doing it the same way twice.”

DR – Design Pattern (Cont’d) A solution to a general design problem in the form of a set of interacting classes that need to be customized (white in figure), The shaded boxes – the interacting classes ,

DR – Example: Widget Generator We want to build a “GUI generator”, Tool that uses the set of classes created by the widget generator, Problem: each GUI has his own “touch and feel”, What GUI shall we “hard-coded” into our tool? , How can we port it to another GUI?

DR – Abstract Factory Pattern … The solution: Abstract classes and abstract methods, An abstract class is a call that cannot be instantiated, but can be used a base class, The interfaces between client and program and generator are abstract , The application program is uncoupled from the specific operating system.

DR – Abstract Factory Pattern (Cont’d)

DR – Design Pattern Pattern can interact with other patterns , If a design pattern is used, the implementation of that design can probably be used as well.

DR – SW Architecture … How do we describe SW architecture? Object-oriented, pipes and filters, client-server, etc. , Encompasses a wide variety of design issues, including: Organization in terms of components, product-level control structure, how those components interact, data-base and data-access, the physical distribution of the components, performance, choice of design alternatives, and more.

DR – SW Architecture (Cont’d) Shaw & Garlan: “Abstractly, SW architecture involves the description of elements from which systems are built, interaction among those elements, patterns that guide their composition, and constrains on those patterns.”

Reuse of SW Architecture Architecture reuse can lead to large-scale reuse, One mechanism: SW product lines , Case study: HP printers: 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.

Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies, Interoperability.

Reuse and Maintenance Reuse impacts maintenance more than development, Assumptions: Total of 40% from a previous product / products are reused, 30% of entire product reused unchanged, 10% reused changed, Savings during development are about 9.3% , Savings during maintenance are nearly 18%.

Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies , Interoperability.

Portability Reminder: SW is portable if it is significantly easier to modify it in order to run it over another compiler / hardware / operating system than to recode it from scratch, More formal: product P: machine M1 op. Sys. OS1 compiler C1 need P': machine M2 op. Sys. OS2 compiler C2 P is portable if it is cheaper to convert P into P’ than to write P' from scratch, Yet another … ,

Portability – Example An numerical integration package, written in FORTRAN and implemented on VAX 10000 running under the VAX/VMS OS, The package is to be ported to a SPARC 20 workstation under the UNIX OS , Issues: Does the package include system call? Are VAX FORTRAN and SPARC FORTRAN identical? What are the incompatibilities?

Incompatibilities – חוסר התאמות Hardware: Disk, tape, Characters EBCDIC vs. ASCII, Parity, ZIP usage, Operating system: JCL, virtual memory, segments allocation , Numerical SW: Word size (integer is 16 or 32 bit length?, Representation of floating point data..), Possible solution: Ada – range definition. In java – all types definition include range and size.

Compiler – Is There a Standard One? … FORTRAN – no standard FORTRAN: FORTRAN – FORmula TRANslator, ISO/IEC FORTRAN (FORTRAN 90), Language may be expanded or not fully supported, Cobol: COBOL – COmmercial and Business Oriented Language, COBOL standards do not promote portability. A COBOL standard has 5 years lifetime with no full compatibility guarantee, Pascal: There are several Pascal standards…Jensen and Wirth – 1975, ISO – 1980, ANSI – 1983 ,

Compiler – …Standard One? (Cont’d) … Original specification – Kernighan and Ritchie - 1978. Standard - ANSI – 1989 approved by ISO – 1990. Pcc, standard front end of the c compiler Johnson, 1979. C++, ISO/IEC/ANSI standard 1998. Java , It seems that SUN will enforce standard. Sun chose a name a name for their new language that could be copyrighted. In 1997 sun ran the ‘pure java’ campaign.

Compiler – …Standard One? (Cont’d) Ada: The only truly successful language standard, No subsets or supersets, Mechanism for compiler approval, Instead of some 450 languages used in DoD projects… A worldwide competition in 1975, approved in 1980, ANSI/mil-std-1815a, 1983, The DoD-1 / green code names… were replaced by… Ada, countess of Lovelace, lord Byron daughter. She wrote programs for Babbage’s analytic engine, the first computer in the first half of the 19’ century. So, Ada was the world first programmer.

Why Portability? … If it is so difficult – why bother? Selling SW multiple variants may not be possible… Product might be highly specialized… (no market) Client might won’t let reuse (in case that SW gives him a competitive advantage) Why bother?, Portability saves money! Lifetimes of SW is longer than hardware, thus you will be enforced to port!, And even if the HW will be fully compatible – what about the competitors? Hardware incompatibility, Multiple copy SW , Port the documentation as well!

Why Portability? (Cont’d) The most successful line of computers up to date was the IBM system/360-370. The various machines are full compatible. A product that runs on IBM system/369 model 30 built in 1964, will run unchanged on IBM S/390 model 1C5 built in 1998!

Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies, Interoperability.

Portability Strategies … Plan!, We may forbid programmers to use any machine-dependent code , So – how can we make a portable OS? Or a portable compiler, Is that feasible?

Portability Strategies (Cont’d) … Portable system SW: Isolate implementation-dependent pieces, UNIX: 9,000 LOC written in C, 1,000 LOC – kernel (HW dependent), 1’000 device-drivers (HW dependent) , Levels of abstraction Graphics, communication (see next slide).

Portability Strategies (Cont’d) … Levels of abstraction. Graphics layers, User Application , Machine Independent Code Machine dependent Code HW Communication SW: The seven layers of abstraction of the ISO-OSI model ,

Portability Strategies (Cont’d) … Use popular language, Not all character set are supported by all computer, What about uppercase and lowercase usage?, Use popular OS. (UNIX / windows) , POSIX – ( Portable OS Interface for Computer Environment – developed for this need.

Portability Strategies (Cont’d) … Strictly adhere to language standards. Set a list of ‘restricted features’ whose usage needs approval, Avoid numerical incompatibilities, Use standard portable GUI (Motif, X11…) , Excellent documentation. (Who is going to read these? What does he know? Etc.)

Portability Strategies (Cont’d) … Portable data: If the product is portable to a new environment – does that include its data? , Example: format of indexed-sequential file is determined by the operating system.

Portability Strategies (Cont’d) Safest way: unstructured (sequential) file One routine X: covert source file into unstructured file (running under the source environment) One routine Y : covert unstructured file into structured file (running under the target environment). (remember compiler front-end and back-end?). Source File Unstructured File Target File X Y

Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies, Interoperability.

Interoperability – יכולת פעולה הדדית … Suppose we want regularly to create a document: Doc should include some budget statistics, Announcement from chief-financial-officer, Doc should be updated and printed on command , Use e-spreadsheet (lotus 1-2-3) and an editor (word). Update the data and recreate the doc.

Interoperability (Cont’d) … Improve1: utilize import/export mechanism – so spreadsheet update are automatically reflected in the doc. Drawback – we still have to open two different tools , Improve2: enable to open the spreadsheet within the doc.

Interoperability (Cont’d) …

Interoperability (Cont’d) The mutual cooperation of object code: From different vendors, Written in different languages, Running on different machines, Example: nation-wide network of ATMs: Server, mainframe, runs database SW, COBOL, Clients (ATMs) run C++, Communications SW, Security , Several interoperability standards have been put out: OLE/COM/ActiveX and CORBA.

OLE – Object Linking and Embedding MS OLE released in 1990 as part of windows 3.0, Was designed to support compound documents (spreadsheet within document), Partial solution to a larger problem , Once COM was developed , OLE was used to denote anything used com-based technology.

COM – Component Object Model The underlying technology supporting interoperability: A model for binary code developed by Microsoft, The COM model enables programmers to develop objects that can be accessed by any com-compliant application , Both OLE and ActiveX are based on COM.

COM Mechanism SW component Q supplies service to component P, P is a client of Q, IF P and Q are: … parts of the same process: – P can invoke Q, … running on the same machine: – P and Q can communicate through interprocess communication mechanism , … running on different machines: – A remote process call (RPC) can be used.

How COM Is Implemented Each piece is implemented as a COM component (“object”), Each component has one or more interfaces, Each interface supports one or more functions (“methods”), The client calls the COM library and specifies: The class of the component, The specific interface , The COM library instantiates the COM component, and returns a pointer to the chosen interface.

COM – Warning COM uses object-oriented terminology: Class, Object, Method , However, COM is currently only object-based, not object-oriented, COM does not support inheritance.

CORBA … Common Object Request Broker Architecture, International standard for OO systems. [1989] , CORBA supports the interoperability of SW application running on different machines within a distribute heterogeneous environment.

CORBA (Cont’d) ORB (Object request broker) allows client to invoke a method of any object in the system, ORB - “the mother of all client/server middleware”, Supports interoperability across vendors, networks, languages and operating systems, CORBA implementations: HP ORB+, DEC object-broker, Visigenic ORB ,

Comparing OLE/COM VS CORBA … Both OLE/COM and CORBA provide equivalent support for interoperability, CORBA is an international standard: Implemented on a wide variety of platforms , OLE/COM is a Microsoft product: Hard to use with non-Microsoft products.

OLE/COM VS CORBA (Cont’d) … “Many people perceive OLE programming to be overwhelming. With the several hundred new APIs required to learn OLE, this is understandable. In addition, OLE requires a new way of thinking. The programmer is required to think of everything in the OLE environment as an object from a disk file, a data item, or an application to hardware or operating systems. In addition, OLE requires the programmer to follow a strict set of rules that is independent of computer language, the OS, or even the HW platform. This book is your introduction into this world. Over the next 21 days you will learn the rules to program in this environment, building on the base that you already know: C++ and windows. In fact, within the first few days you will be able to take many of your existing applications and make them into OLE applications.” Teach yourself OLE Programming in 21 days, Lawrence Harris.

OLE/COM VS CORBA (Cont’d) CORBA is independent on underlying communication mechanism, OLE/COM communication mechanism is Microsoft proprietary, Integration of COTS SW is easier with OLE/COM: Most COTS SW is supplied by Microsoft , CORBA is much simpler than COM: OLE/COM documents > 2,000, win32 knowledge is required as well, CORBA Pages ~ 178.

Future Trends in Interoperability … OLE/COM and CORBA are currently the “big two.”, Other interoperability products may succeed, such as JavaBeans (SUN & IBM), JavaBeans – Fully portable, compact, architecturally neutral and platform neutral API ,

Future Trends in Interoperability (Cont’d) Web-based applications need to be integrated into client–server products, XML (extensible markup language) will probably play a major role, Whatever, interoperability will be easier to achieve in the future ,

Summary Introduction, Impediments to reuse, Reuse case studies, Objects and reuse, Reuse during design and implementation phases, Reuse and maintenance, Portability, Portability strategies, Interoperability.

REUSABILITY, PORTABILITY, AND INTEROPERABILITY The End