Specialized Forms of

ReusePart VII: Software Reuse Technologies

Reuse Technologies…

Implementing a reuse program entails deliberating on trade-off’s between following aspects:

-Organizational -Technical -Economical

Based on specific combinations of these aspects, finally, three techniques of Reuse came to existence.

Forms of Reuse Technology:

Component Based Software Engineering (CBSE)

Product Line Engineering (PLE)

Commercial Off-the-shelf (COTS) Based Development

Component-based software Engineering (CBSE):

• It is an emerging development paradigm that promises to accelerate software development and to reduce costs by assembling systems from prefabricated software components. (Source: http://www.idt.mdh.se/ecbse/2002/ (28th Euromicro conference)

• Component-Based Software Engineering (CBSE) is now the way to produce software fast, with less effort, of high quality- not just the first time a product is released but for its entire life. (Source: http://cseng.aw.com/book/0,3828,0201704854,00.html)

What Is a Component:

Component is an encapsulated, distributable software package,with well defined interfaces.

Reusable assets that are self contained

Independent Concrete Realizations

Requires no customization (Plug and Play)

Provide well defined services to the applications

Structure of a Component:

Components can be described in terms of interfaces that provide access to their functionality.

Component’s interfaces can be described by languages like:

Module Interface language (MIL)

Interface definition Language (IDL)

Architecture definition language (ADL)

Component’s Interfaces can be classified on the basis of their interaction with surrounding environment

Classification of Interfaces:

• Internals: Private elements, that provide the actual functionality of the component.

• Application: Define the interactions with other application artifacts

Interfaces (Other Components or applications)

• Platform: Define the component interaction with platform on which it executes.

Classification of Interfaces(contd.)

Other Component

Middleware

Platform Interface (OS and System Hardware)

Internals

Platform InterfaceA

pp

licati

on

In

terf

ace

(Hori

zon

tal C

han

nel)

Features Of a Good component:

Well Documented: It should be documented for reuse, including integration documentation.

Cohesive: A component should encapsulated at one level of abstraction exactly one nontrivial purpose, such as a function of a structure.

Independent: A component should as independent as possible from other components.

Features Of a Good component (contd.)

Useful: A component should have a set of use cases and situations in which it was previously, used or needed.

Certified: A good software component has test suites & benchmarks that can be used for independent verification.

Well defined Interfaces

Component Model

Template for defining components with the contexts of a particular software architecture.

• A component model specifies one or several components types and defines the contracts that components of these types need to satisfy to offer their services to, and use the services of, other components of system architected using this style.

• The notion of a component model is architectural in nature, within the context of component system. Component models may be defined in terms of component interfaces that are described in fairly precise and formal interface definition language - including programming languages, as is the case for the EJB component model is defined in terms of Java Interfaces.

Features Component Model Should Possess

• Data Representation: Components should agree on the representation of data they exchange i.e datatypes should be same.

• Data Transfer: Uses push/pull dichotomy,which specifies whether the component pushes the data to another or it waits for other components to pull its data. Push mode component will not work in Pull mode.

• Transfer Protocol: Determines how and in what form transfer of data takes place.

• State Resistance: Components are stateless ,such as static library and components like EJB,CORBA objects retain their states.

Features Component Model Should Possess (Contd.)

• State Scope: It defines the extent to which the internal state of the component is exposed.

• Failures: Techniques to report component failure like Exception Events raised or Global Error number generated.

• Connection Establishment: The way how the connection between the components is established and torn down like in OOP Paradigm pointers and references are used.

Component Based System Development (CBSD) With ever increasing scale and scope of software development, a need for integration process that produce component based systems was felt.

The driving forces behind CBSD are:

Large Scale Applications New Technologies Increasing Competition

In order to find efficient techniques to build component based systems an in-depth understanding of development processes is necessary.

Find Select Adapt Compose Replace

Find : The process of finding components defines how to document and create repositories of components.

Select : Specific components are selected from a repository in order to use them in CBSD.

Adapt : Customizing selected components.

Create : Develop and create new components (If required)

Compose: Assemble and integrate

Replace : Components are replaced in order to fix errors and add new functionalities.

CBSD Process: Create

Component GranularityComponents Partition Systems and System Development in various ways. Szyperski (1999) identified a number of dimensions along which components may represent units of things :

• Abstraction Dimension : Abstraction implies the levels of details encapsulated within the component. These details define functionality,resources, structure, or state. • Management Dimension : It includes the cost of the component.Many investment models divide the system into a set of components to study the cost of each and the effect of the cost on the overall system cost.

Component Granularity (Contd.)• Business Dimension : When a component based system

fails then the failure is traced to errors and falls in one or more of it’s constituting units. These lead to disputes at business levels. Components can be units for resolving such disputes.

• Compilation Dimension : In component based systems, individual units are compiled

separately and plugged into the system.

• Distribution Dimension : In a distributed component based system, components reside on

different platforms or machines, and interact with each other remotely.

Issues in Component Development

Technical Issues :

° Interfaces : To qualify a software artifact as a component, it’s interfaces to other application artifacts should be clearly defined.

° Development Process Model

• Interface-Centric : The emphasis in CBSD is component interfaces because they play an important role in integrating independently deployed components.

Issues in Component Development (Contd.)

• Programming-Language-Independent : Using of assets should be independent of the programming languages in which these are actually implemented.

• Compositional : Development process in which we assemble applications from components rather than develop and implement them from scratch.

Issues in Component Development (Contd.)

• Separation of Concerns : Required to decrease dependability between components and hence improve the system maintainability.

• Integration

- Static integration : Integration during development.- Dynamic Integration : Integration during runtime.

Issues in Component Development (Contd.)

• Integrating Legacy software : In a component based development, single component model may pervade an entire application or a major subsystem of an application. It causes backward-compatibility problems with legacy subsystems.

Product Line Engineering (PLE)

• Product-line engineering is a specialized form of reuse that promises Productivity, Quality and shorter time to market in developing similar products in the same domain.

PLE is a streamlined integration of several aspects of software reuse.

• PLE embodies domain & application engineering phases that are scoped by family of products.

Product Line Engineering (PLE) - contd.

The basic technical means to create a product line include:

Domain Analysis Software Architecture Development Process

PLE Lifecycle:

DomainAnalysis

DomainModels

ArchitectureDevelopment

DomainArchitecture

Building ReusableComponents

ReusableComponents

ProductAnalysis

ProductSpecification Product

Description

ProductSpec. Architecture Product

Development

Product

PLE Lifecycle (contd.)

Attributes of a lifecycle:

Architecture Based Economically Driven Reuse-driven Domain-Specific Process-Driven (Lifecycle is guided by

Development process)

Success Factors in PLE

Domain- specific expertise.Architectures.Configuration management.Business models.Scoping the domain.Avoid the “Least Common Denominator” concept.Managing requirements .Separate domain engineering unit.

Product-Line Practice

- PLP initiative by SEI (Software Engineering Institute) helps in facilitating and accelerating the transition to sound software engineering using a product-line approach.

-The objective of the PLP initiative is to provide organizations with an integrated business and technical approach to multi-use of software assets.

Essential Activities

Core Asset Development-Acquisition: It is a Domain Engineering Process. Core asset activities produce or acquire the following objects:

Product space: This is a description of the initial products constituting the product line.The description specifies the commonalties and the variations among the products that will Constitute the product line.

Essential Activities(contd.)

Core Assets: They include an architecture that will shared by the products in the product line and reusable software components. Development and acquisition of core assets take the following inputs: Product Constraints, which deals with the kind of commonalties and variations that exist among the products in the family. Production Constraints, which deal with production process.

Product Development Acquisition: It is an Application Engineering Process.

COTS – Commercial Off the Shelf Software

What is COTS? What constitutes COTS ? What are Lifecycle for COTS ? Salient Differences COTS and

CBSD COTS Certification Criteria

COTS Characteristics :

Executable software package

Usually Sold, Leased, or Licensed. Only Blackbox Use.

The Component prerogative lies with the Vendor.

Available in multiple Identical Copies

Advantages of COTS Products:

Gain in Cost

Gain in Operational Quality

Gain in Functionality

Gain in Time to Market

Gain in Maintenance Overhead

Lifecycle for COTS based Development

Bottom Up Design:

Acquaintance with COTS components, Analyze their relationship with proposed system.

Draw System Design which takes best advantage of these available COTS components.

Lifecycle for COTS based Development (contd.)

Top Down Design:

Acquaintance with Requirements specifications, Check for their matching with COTS products.

Start design and check at each step for existing COTS product.

COTS & CBSD

White Box vs. Black Box Resue. Copyright Privileges. Maintenance. Retrieval Criteria.

COTS Selection(Criteria):

Quality : Includes Reliability and Efficiency

Fitness : Top Down Design, Bottom up Design

Interaction: Functional requirements in Regard to

Integration into the Host System

COTS Integration

Interface Matching.

Functional Matching.

Intercomponent Communication.

Integration Testing.

V & V(Verification & Validation of COTS based System)(Contrast in Domain Engg. & Application Engg.)

Difference in requirements. Difference in Goals. Difference in Methods.

Maintenance

A key reason in Purchase vs. Develop Decision.

Software Upgrade Issues. Dynamic Nature of Market has bearing

on maintenance issue.

Certification Criteria

A major challenge – Establishing Trust. Testing and certification techniques

essential trust. Hierarchical reference model.

Certification Categories

Certification Level

Certification Agent

Certification Focus

Certification Goals

COTS Worthiness

Vendor Content Worthiness

Domain Pervasiveness

Domain Analyst

Concept Usefulness

Architecture Conformance

Domain Engineer

Context Usability

Application Adequacy

Application Engineer

Context Adequacy

COTS Certification Levels

COTS Worthiness. Domain Pervasiveness. Architecture Conformance. Application Adequacy.

COTS Worthiness

Domain Pervasiveness Architecture Conformance

Application Adequacy

COTS Worthiness

Component is worthy if its is technically and commercially sound.

It has to meet some intrinsic criteria that deal exclusively with its content.

COTS Worthiness (contd.)

Technical Soundness :

- Functional Attributes• Services

- Quality of Service

: Tolerating Failures

: Performance

: Security

: Reliability

COTS Worthiness (contd.)

- Structural Attributes

– Operational Attributes• Adaptability• Understandability

- Documentation

- Testability

COTS Worthiness (contd.)

Operational Attributes :

- Efficient Implementation

- User Interfaces

COTS Worthiness (contd.)

Vendor And Market Attributes

- Vendor Business stability

- The development process

- Obsolescence of the component

- Maintenance Contract

- Marketing Trends

- Customer Support

COTS Domain Pervasiveness

Measures for the concepts that a COTS component embodies, irrespective of its representation.

- Generality

- Retrieveability

- Usefulness

COTS Architecture Conformance

COTS component should be usable depending on the context (domain specific or Component Specific), that it is required to operate within.– Genericity– Interoperability– Portability

Compliance with Standards

COTS component should comply with architectural standards in the same domain.

Certification Criteria assess the level of compliance of a COTS component to these standards.

Compliance with Standards (contd.)

COTS Components used in DII COE must be certified against following categories :

- Runtime Environment

- Style Guide

- Architectural Compatibility

- Software Quality

Application Adequacy

Application Specific criteria deal with specific requirements for one particular application of product line.

Focus on meeting the specifications of the application.

How do I do COTS

The answer to this question involves at least three things:– Deciding whether to use COTS products– Learning how to use COTS products– Gauging the effect of using COTS

products

Deciding whether to use COTS

What are the directives?– What do the directives really say?– What is the relevant guidance to be followed?– What are the obligations for using COTS?

Are the directives applicable?– No large system can have 100% COTS – So answer question of how much COTS?

Deciding whether to use COTS

What Factors will modify my choice?– System development, System maintenance,

lifetime system cost– Government, defense, selling/internal,

platform independence, severity of bugs of COTS, unique requirements etc.,

Learning how to use COTS

Usage of COTS affect the traditional life-cycle of software. – What kinds of testing to be done?– COTS dependency on third party products– Support from vendor, COTS lifecycle

Gauging the effect of using COTS products

System engineering Business Case for use of COTS

– Open systems Vs Proprietary– Slim Vs Fat

Shift in mentality from producer to consumer

Having decided for COTS – What next?

Finding and selecting appropriate COTS– Assessing the flexibility and malleability of

system requirements– Guidelines and methods for performing

product evaluations– Evaluating the potential for integrating

with legacy system

Having decided for COTS – What next?

– Decision criteria for migration– Variance between traditional testing

approaches and COTS– Role of architecture in COTS – Developing commercial outlook on

system maintenance

Aspect CBSE COTS PLE

OrganizationalPrimary Interactions

Primary reuse skills

TechnicalIntegration

Constraints

Support service respPackaging

RetrievalImplementation tech.

EconomicalComponent AcquisitionMarket scope

Economical motivation

Involvement of component& application engineers.Library retrieval

Component engineerApplication engineerReuse librarian

Compositional with othercomponents

Components comply with component model

Appln. EngineersBinary source code maybe avail. and modifiable.

Public or domain librariesDefined by componentmodel.

AdaptDriven by ROI from anappln. Developer perspective

Common comp. Models..

Strong relationship with party

Reuse manager

Compositional only

Components comply toappln. constraints

Component vendorBinary black box components

Commercial advtNot controllable

BuyDriven by ROI from the component provider perspective.

Component market

Strong involvement ofdomain engineers

Domain engineers

Compositional intodomain architecture

Components complyto domain architect--ure constraints.Domain engineersRef. Architecture,source code.

Domain librariesDefined by referencearchitecture.

InstantiateDriven by ROI from the domain engineer perspective

Common design &architecture.

Comparison of CBSE, COTS, & PLE