1. Specialized Forms of Reuse Part VII: Software Reuse Technologies

2. 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.

3. Forms of Reuse Technology:  Component Based Software Engineering (CBSE)  Product Line Engineering (PLE)  Commercial Off-the-shelf (COTS) Based Development

4. 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/ (28 th 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)

5. 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

6. 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

7. 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.

8. Classification of Interfaces(contd.) Other Component Middleware Platform Interface (OS and System Hardware) Internals Platform Interface Application Interface (Horizontal Channel)

9. 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.

10. 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

11. 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.

12. 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.

13. 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.

14. 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.

15. 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

16. Component Granularity Components 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. Product Line Engineering (PLE) - contd.  The basic technical means to create a product line include:  Domain Analysis  Software Architecture  Development Process

24. PLE Lifecycle: Domain Analysis Domain Models Architecture Development Domain Architecture Building Reusable Components Reusable Components Product Analysis Product Specification Product Description Product Spec. Architecture Product Development Product

25. PLE Lifecycle (contd.) Attributes of a lifecycle:  Architecture Based  Economically Driven  Reuse-driven  Domain-Specific  Process-Driven (Lifecycle is guided by Development process)

26. 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.

27. 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.

28. 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.

29. 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.

30. 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

31. 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

32. Advantages of COTS Products:  Gain in Cost  Gain in Operational Quality  Gain in Functionality  Gain in Time to Market  Gain in Maintenance Overhead

33. 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.

34. 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.

35. COTS & CBSD  White Box vs. Black Box Resue.  Copyright Privileges.  Maintenance.  Retrieval Criteria.

36. 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

37. COTS Integration  Interface Matching.  Functional Matching.  Intercomponent Communication.  Integration Testing.

38. V & V (Verification & Validation of COTS based System) (Contrast in Domain Engg. & Application Engg.)  Difference in requirements.  Difference in Goals.  Difference in Methods.

39. Maintenance  A key reason in Purchase vs. Develop Decision.  Software Upgrade Issues.  Dynamic Nature of Market has bearing on maintenance issue.

40. Certification Criteria  A major challenge – Establishing Trust.  Testing and certification techniques essential trust.  Hierarchical reference model.

41. Certification Categories Certification Level Certification Agent Certification Focus Certification Goals COTS Worthiness VendorContentWorthiness Domain Pervasiveness Domain Analyst ConceptUsefulness Architecture Conformance Domain Engineer ContextUsability Application Adequacy Application Engineer ContextAdequacy

42. COTS Certification Levels  COTS Worthiness.  Domain Pervasiveness.  Architecture Conformance.  Application Adequacy. COTS Worthiness Domain Pervasiveness Architecture Conformance Application Adequacy

43. 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.

44. COTS Worthiness (contd.)  Technical Soundness : - Functional Attributes Services - Quality of Service : Tolerating Failures : Performance : Security : Reliability

45. COTS Worthiness (contd.) -Structural Attributes – Operational Attributes Adaptability Understandability - Documentation - Testability

46. COTS Worthiness (contd.)  Operational Attributes : -Efficient Implementation -User Interfaces

47. COTS Worthiness (contd.)  Vendor And Market Attributes -Vendor Business stability -The development process -Obsolescence of the component -Maintenance Contract -Marketing Trends -Customer Support

48. COTS Domain Pervasiveness  Measures for the concepts that a COTS component embodies, irrespective of its representation. -Generality -Retrieveability -Usefulness

49. 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

50. 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.

51. Compliance with Standards (contd.)  COTS Components used in DII COE must be certified against following categories : -Runtime Environment -Style Guide -Architectural Compatibility -Software Quality

52. Application Adequacy  Application Specific criteria deal with specific requirements for one particular application of product line.  Focus on meeting the specifications of the application.

53. 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

54. 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?

55. 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.,

56. 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

57. 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

58. 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

59. 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

61. Aspect CBSE COTSPLE Organizational Primary Interactions Primary reuse skills Technical Integration Constraints Support service resp Packaging Retrieval Implementation tech. Economical Component Acquisition Market scope Economical motivation Involvement of component & application engineers. Library retrieval Component engineer Application engineer Reuse librarian Compositional with other components Components comply with component model Appln. Engineers Binary source code may be avail. and modifiable. Public or domain libraries Defined by component model. Adapt Driven by ROI from an appln. Developer perspective Common comp. Models.. Strong relationship with party Reuse manager Compositional only Components comply to appln. constraints Component vendor Binary black box components Commercial advt Not controllable Buy Driven by ROI from the component provider perspective. Component market Strong involvement of domain engineers Domain engineers Compositional into domain architecture Components comply to domain architect- -ure constraints. Domain engineers Ref. Architecture, source code. Domain libraries Defined by reference architecture. Instantiate Driven by ROI from the domain engineer perspective Common design & architecture. Comparison of CBSE, COTS, & PLE