Reusability, Portability, and Interoperability

1
Reusability, Portability, and Interoperability

• Chapter 8

2
Portable vs. Reusable

• A product is portable if it is easier to modify
  the product so that it runs on another platform
  (compiler, hardware, OS configuration) than to
  recode it from scratch.
• A product is reusable if it can be used to
  facilitate development of a different product
  with different functionality.

3
Reuse Concepts

• Reuse
• Using components of one product to facilitate the
  development of a different product with different
  functionality.
• Study has shown that only 15 of a software
  serves a truly original purpose. The remaining
  85 can be standardized and reused in future
  products.
• What is reusable?
• Module, code fragment, design, sections of a
  manual, set of test data, cost estimates, etc.
• Why reuse?
• Speeds up software development
• Reused software are easier to maintain

4
Types of Reuse

• Accidental
• Also known as opportunistic reuse
• If developers of a new product realize that a
  component of a previously developed product can
  be reused in the new product
• Deliberate
• Also known as systematic reuse
• Use of software components constructed
  specifically for possible future reuse

5
Accidental vs. Deliberate Reuse

• Advantages of components developed specifically
  for deliberate reuse versus accidental reuse are
• Easier and safer to use
• More robust, well-documented and thoroughly
  tested
• Easier to maintain
• Disadvantages of components developed
  specifically for deliberate reuse versus
  accidental reuse are
• More expensive to develop
• Takes more time to specify, design, implement,
  test and document
• No guarantee that the components will ever be
  reused

6
Examples of Reusable Codes

• C
• Standard Template Libraries (vector, list, map,
  etc.)
• C
• System Classes (Convert, Array, Math, etc.)
• Application Programming Interfaces (API)
• Win32 API, Mackintosh Toolbox

7
Impediments to Reuse (1)

• Not Invented Here Syndrome
• Many software professional feel that if they did
  not write a component, it cannot be any good
• Solution management can offer incentives to
  encourage developers to practice reuse.
• Fear of faulty components
• Fear that reused software will introduce faults
  to the new product
• Solution subject all potentially reusable
  software to exhaustive testing

8
Impediments to Reuse (2)

• Problems with storage and retrieval of reusable
  components
• There may be no accurate record of reusable
  software. If there are records, they may be
  difficult to retrieve
• Solution use a well-organized database with
  sufficient documentation

9
Impediments to Reuse (3)

• Reuse is expensive
• Three reuse costs
• Cost of making something reusable
• Cost of reusing it
• Cost of defining and implementing the reuse
  process
• Reuse cost can vary from 11 percent to 480
  percent.
• The only solution to this problem is for software
  developers to realize that in spite of the cost,
  reuse will result in development and maintenance
  savings.

10
Impediments to Reuse (4)

• Legal issues with contract software
• When the client is a different organization than
  the developer, the client owns the developed
  software product and as such owns the software.
  This situation precludes the developer from
  reusing the software.
• Reuse of COTS software is limited
• COTS typically provide no source code making them
  difficult to extend and modify.

11
Types of Design Reuse
(c)
(d)
(a)
(b)

• Reuse of a library or toolkit
• Reuse of a framework
• Reuse of a design pattern
• Reuse of a software architecture

12
Reuse During the Design Phase (1)

• Library or toolkit
• Libraries or toolkits are sets of reusable
  routines
• The designer is responsible for the control logic
  of the product as a whole while the libraries
  and/or toolkits supply parts of the design that
  incorporate the specific operations of the
  product.
• Examples
• C STLs
• Java Abstract Windowing Toolkit

13
Reuse During the Design Phase (2)

• Framework
• Types of framework
• Application framework
• Code framework
• Application framework
• Incorporates the control logic of the design
• When reusing an application framework, developers
  are responsible for the design of the
  application-specific operations of the product.
• Example
• set of classes for software controlling an ATM

14
Reuse During the Design Phase (3)

• Framework
• Application framework (cont.)
• Results in faster development than reusing a
  library or toolkit because
• More of the design is reused with a framework so
  theres less to design from scratch
• Control logic is harder to design. When a
  framework is reused, the control logic is already
  designed so the resulting overall design will be
  of higher quality

15
Reuse During the Design Phase (4)

• Framework
• Code framework
• MacApp, framework for writing application
  software on the Macintosh
• Microsoft foundation classes (MFC), framework for
  building GUIs in Windows-based applications.
• Borlands Visual Component Library, framework
  with similar functionality as MFC

16
Reuse During the Design Phase (5)

• Design pattern is a recurring solution to a
  standard problem. When related patterns are woven
  together they form a language'' that provides a
  process for the orderly resolution of software
  development problems.

17
Reuse During the Design Phase (6)

• A solution to a general design problem in the
  form of a set of interacting classes that have to
  be customized to create a specific design.
• Refer to figures 8.3 and 8.4 in the text.
• Figure 8.4 is a general design pattern for an
  abstract factory
• Figure 8.3 is an instance of the pattern given in
  figure 8.4

18
Reuse During the Design Phase (7)

• Software architecture
• Applies to the product as a whole
• Comprised of a variety of design issues
• Communication and synchronization
• Databases and data access
• Physical distribution of components
• Performance
• Choice of design alternatives
• May incorporate toolkits, frameworks and design
  patterns
• Reuse of software architectures may be achieved
  with software product lines
• Example HPs firmware architecture for the
  manufacture of printers

19
Portability

• A product is portable if it is significantly less
  expensive to adapt the product to run on a new
  computer than to write a new product from
  scratch.
• Note a new computer can mean new hardware and/or
  new operating system

20
Why is portability desirable?

• Larger market for the product
• If the product can run on more computer hardware
  types, its potential market is larger
• Clients typically upgrade their hardware every 4
  years
• With each upgrade, clients also need to adapt
  their existing software to the new hardware. If
  the software is not portable, these upgrade will
  be very costly

21
Issues in making a product portable

• Hardware incompatibilities
• Operating system incompatibilities
• Numerical software incompatibilities
• Compiler incompatibilities

22
Hardware Incompatibilities

• Started because of parallel development efforts
  in competing companies resulting in different
  hardware products
• Persists because of economic reasons
• New hardware must be compatible with the old one.

23
Operating System Incompatibilities

• Examples of possible differences are
• Difference in system calls used to access OS
  services
• Support for virtual memory
• Products developed for an OS that support virtual
  memory may be too large to port to one that does
  not support virtual memory. In this case, the
  product will have to be rewritten and linked
  using overlay techniques

24
Numerical Software Incompatibilities

• Arithmetic computations in a software product is
  affected by how the hardware represents the data
  as 16-bit, 32-bit or 64-bit
• Computation than run perfectly in a system that
  represents data as 32-bit will not perform well
  on those that represents the same data as 16-bit.

25
Compiler Incompatibilities

• Programs written and compiled by one compiler may
  not run on another compiler
• Compilers for the same language such as C/C or
  FORTRAN may not be identical
• Although compiler standards exist, compiler
  manufacturers are not required to follow the
  standard
• The only exception to this is Ada and possibly
  Java.

26
Techniques for achieving portability (1)

• in system software (OS and compilers)
• Isolate any necessary hardware-dependent sections
• Use levels of abstraction
• Protects the application level code from changes
  in hardware-dependent sections of the code

27
Techniques for achieving portability (2)

• In application software
• Use a programming language that is more portable,
  i.e. with less restrictive features
• Develop the product to run on the more popular
  operating system available
• Use POSIX to standardize the interface between an
  application program and a UNIX operating system

28
Techniques for achieving portability (3)

• In application software (cont.)
• Write the program strictly adhering to language
  standards
• Use standard GUI languages
• Plan for potential future numerical
  incompatibilities
• Eg. Limit integer range to 32767
• Plan for lack of future OS incompatibility
• Isolate and document well every OS system calls
• Supply adequate documentation to assist in future
  porting

29
Techniques for achieving portability (4)

• In data
• Avoid the use of structured files and headers.
  These are typically compiler specific.
• Use unstructured files

30
Interoperability

• Mutual cooperation of object code from different
  vendors, written in different languages and
  running on different platforms.
• Eg. Running a spreadsheet tool within a word
  processing document

31
Support of Interoperability

• Requires that software component services be
  available to another software component
  regardless of whether the two are
• Parts of the same process (invoke)
• Different processes running on the same machine
  (interprocess communication)
• Or, different processes running on different
  computers in a network (remote procedure call)
• Available technology
• COM and CORBA

32
COM

• Common Object Model
• OLE ? COM ? DCOM ? ActiveX
• Software implemented as COM has one or more
  interface that supports one or more functions

33
COM (cont.)

• COM use mechanism
• A client software calls the COM library
  specifying the class of the component and a
  specific interface of the component
• The COM library instantiates a COM component of
  that class and returns a pointer to the chosen
  interface
• The client software can now invoke functions of
  available in the interface

34
CORBA

• Developed by the Object Management Group, a
  consortium of about 800 vendors of
  object-oriented technology
• International standard architecture for OO
  systems

35
CORBA (cont.)

• CORBA use mechanism
• Provides for an object request broker that allows
  a client to invoke a method of an object

36
COM versus CORBA

• COM
• Microsoft product
• Limited to MS Windows platform
• Communication mechanism is a proprietary
  Microsoft product
• Easy to use with 80 percent of available COTS
  software since these are MS products
• Highly complex

• CORBA
• International standard
• Implemented on a wider variety of platforms
• Independent of underlying communication mechanism
• Difficult to integrate COTS software to
  CORBA-based product
• simple