Software Component Integration Lecturer Ayelet Kaidar Supervisor Ron

Software Component Integration Lecturer : Ayelet Kaidar Supervisor: Ron Pinter

Introduction: l l l CBSD COTS ESAM

COTS: l l l Commercial-Off-The-Shelf (COTS) The term “COTS” is meant to refer to things that one can buy, ready-made, from some manufacturer’s virtual store shelf (e. g. , through a catalog or from a price list ). It carries with it sense of getting, at a reasonable cost, something that already does the job.

CBSD l l Component-Based Software Development (CBSD) focuses on building large software systems by integrating previously-existing software components. CBSD embodies the “buy, don’t build” philosophy.

CBSD (cont. ) l l l At the foundation of this approach is the assumption that: common parts should written once, rather than many times, and that common systems should be assemble through reuse rather than written over and over.

CBSD (cont. ) l l By enhancing the flexibility of systems, this approach can potentially be used to: Reduce software development costs, Assemble systems rapidly, and reduce the spiraling maintenance burden associated with the support and upgrade of large systems.

CBSD (cont. ) l l Component-based systems encompass both COTS products and component acquired through other means, such as non developmental items (NDIs). Developing component-based systems is becoming feasible due to the following:

CBSD (cont. ) l l l The increase in the quality and variety of COTS products. Economic pressures to reduce system development and maintenance costs. The emergence of component integration technology.

CBSD (cont. ) l l In CSBD, the notion of building a system by writing code has been replaced with building a system by assembling and integrating existing software components. In contrast to traditional development, where system integration is often the tail end of implementation effort, component integration is the centerpiece of the approach.

Four major activities: l l Component qualification Component adaptation Assembling components into systems System evaluation

Component Qualification l l It is a process of determining “fitness for use” of previously-developed components that are being applied in a new system context. It is also a process for selecting component when a marketplace of competing products exists.

Component Qualification (cont. ) l l l There are two phases of Component Qualification: Discovery Evaluation

Component Qualification (cont. ) l l In the discovery phase, the properties of a component are identified. Component functionality (what services are provided) and other aspects of a component’s interface (such as the use of standards). These properties also include quality aspects that are more difficult to isolate, such as component reliability. It is also reasonable to discover “non-technical” component properties, such as the vendor’s market share and past business performance.

Component Qualification (cont. ) l l l There are some relatively mature evaluation techniques for selecting from a group of peer products. For example, the International Standards Organization (ISO) describes general criteria for product evaluation (ISO 91). These evaluation approaches typically involve a combination of paper-based studies of the components, discussion with other users of those components.

Component Adaptation l l Because individual components are written to meet different requirements , and are based on differing assumptions about their context, components often must be adapted when used in a new system. Components must be adapted based on rules that ensure conflicts among components are minimized.

Component Adaptation (cont. ) l l The degree to which a component's internal structure is accessible suggests different approaches to adaptation: White box, where access to source code allows a component to be significantly rewritten to operate with other components Grey box, where source code of a component is not modified but the component provides its own extension language or API. Black box, where only a binary executable form of the component is available and there is no extension language or API.

Assembling Components Into Systems l l Components must be integrated through some well-defined infrastructure. This infrastructure provides the binding that forms a system from the disparate components. For example, in developing systems from COTS components , several architectural styles are possible:

Assembling Components Into Systems (cont. ) l l Database, in which centralized control of all operational data is the key to all information sharing among components in the system Blackboard, in which data sharing among components is opportunistic. Message bus, in which components have separate data stores coordinated through messages announcing changes among components. Object Request Broker (ORB) mediated, in which the ORB technology provides mechanisms for language-independent interface definition and object location and activation

System Evaluation l l l At first glance, component-based systems may seem relatively easy to evolve and upgrade since components are the unit of change. To repair an error and upgraded component is swapped for its defective equivalent, treating components as plug-replaceable units. Similarly, when additional functionality is required, it is embodied in a new component that is added to the system.

System Evaluation (cont. ) l l However, this is a highly simplistic and optimistic view of system evaluation. Replacement of one component with another is often a time-consuming and a hard task since the new component will never be identical to its predecessor and must be thoroughly tested, both in isolation and in combination with the rest of the system.

COTS l l Commercial-off-the-shelf (COTS) software is developed by a third party and intended to be part of a new software system. Usage of COTS products is growing, because developers hope that it will increase their systems quality and reduce development time.

COTS (cont. ) l l Integration of software component into a system can be hindered by incompatibilities between the component and the system. To predict the possible incompatibilities and the ways to overcome them during the integration activities, a classification of incompatibilities can be useful for software developer.

COTS (cont. ) l l l The existence of mismatch between the COTS product being integrated and the system is possible due to their different architectural and functional constrains. And also mismatches in the required functionality, nonfunctional constrains, and software developers expertise level. Selecting suitable COTS products for a project can require finding a trade-off between different mismatches.

Inter-Component Interactions and Classification l l There are three aspects of inter-component interactions and incompatibilities: Type of interacting component Layer (syntax or semantic-pragmatic) Number of components participating in the interaction

Type of interacting component l l The components interact with other system components, and with the system environment. System components can be either software or hardware (excluding everything related to the environment, such as CPU and memory, but including devices directly controlled by the system, such as on-board devices) that are used by the software system.

Type of interacting component (cont. ) l l The environment can be of the development phase, which includes compilers, debuggers and other development tools, or it can be the environment of the target system, which includes Operating systems, virtual machines (like Java), interpreters (like Basic). The parts of both environments can also be considered components.

Two main layers l l Syntax, defines the representation of the syntax rules of the interaction, e. g the name of the invoked function; the names, types and the order of the parameters or data fields in the message, etc. For instance, float SQRT(float x) represents a C notation for a function called “SQRT” returning a real result and with one argument, a real number x.

Two main layers (Cont. ) l l Semantic-pragmatic, defines the functional (semantic and pragmatic) specifications of the interaction, i. e. , what functionality is preformed by the component. e. g. , invoking the function “SQRT” calculates the square root of its only argument and returns it to the caller.

Number of components participating in the interaction l l Finally, an incompatibility can occur in an interaction involving a certain number of participating components. A syntax incompatibility can occur because of syntactic difference between two components, but a semantic-pragmatic incompatibility can be caused by one, two or three mismatching components.

Types of semantic-pragmatic incompatibilities: l l 1 -order semantic-pragmatic incompatibility or an internal problem, if a component alone has incompatibility disregarding the components it is interacting with. It means that the component either does not have required functionality (not matching the requirements) or its invocation cause a failure (an internal fault)

Types of semantic-pragmatic incompatibilities (cont. ): l l l 2 -order semantic-pragmatic incompatibility, or a mismatch, if an incompatibility is caused by interaction of two component. Both components may not have 1 -order incompatibilities and can work correctly in order contexts. For example, a procedure that calculates the square root of a real number receives a negative argument from a caller that supposes that this is a valid input.

Types of semantic-pragmatic incompatibilities (cont. ): l l l N-order semantic-pragmatic incompatibility, or a conflict, if an incompatibility is caused by interactions of several components. There may not be semantic-pragmatic 1 -order and 2 order incompatibilities for those components, but their cumulative interaction cause a failure. For example, several processes together require more memory than the available amount, although each of them can be satisfied independently.

Example: l l A 3 D-graphics engine is being chosen for a real -time system. The system being developed imposes the following high-level requirements for the graphics engine:

Example (cont. ): l l Functionality: drawing 3 -dimensional objects, including input and output 3 D images from files. Non-functional issues (portability): MAC. Architectural issues (development platform): Ada 95. Interfaces (example of a function): procedure RECT(x, y, w, h: Real); where (x, y) – the coordinates of the left bottom corner of the rectangle; w-its width; h-its height; output – drawing a rectangle.

Example (cont. ): l l The possible candidate COTS products are Open. GL, Quick. Draw 3 D, and Direct. X. Matching them against the requirements gives the following data:

Open. GL l l l Functionality: the drawing functions are provided, input and output from files is not supported – 1 -order semantic-pragmatic incompatibility. Non-functional issues: Mac platform is supported. Architectural issues : an ADA implementation is available.

Open. GL (cont. ) l l Interface: procedure gl. Rectf(x 1, y 1, x 2, y 2: Glfloat); where (x 1, y 1) – the coordinates of one vertex of the rectangle; (x 2, y 2) – the coordinates of the opposite vertex of the rectangle. There are syntax incompatibility (different procedure names) and 2 - order semantic-pragmatic incompatibility (different interpretations of the arguments) with software components.

Quick. Draw 3 D l l l Functionality: drawing provided, input and output from files is supported. Non-functional issues: Mac platform is supported. Architectural issues: Ada 95 implementation is not available – 2 -order semantic-pragmatic incompatibility with the development platform.

Direct. X l l l Functionality: drawing provided, input and output from files is supported. Non functional issues: Mac platform is not supported – 2–order semantic-pragmatic incompatibility with the target platform. Architectural issues: Ada 95 implementation is not available – 2 -order semantic-pragmatic incompatibility with the development platform.

Conclusion: l l l The result of this comparison is that Open. GL is the best candidate, despite certain incompatibilities that can be overcome using glueware and re-implementation. Use of C-implemented Quick. Draw 3 D would require changing the system’s architecture. Use of Direct. X would require porting it to Mac, which is hardly a real option.

The Enterprise Software Asset Management Paradigm l l l Enterprise Software Asset Management (ESAM) is a paradigm for the management of software assets in the enterprise. ESAM leverage these assets in order to provide developers with search and reuse, collaboration, impact analysis, knowledge management and other capabilities. ESAM is based on an automated mechanism which integrates with existing development processes and systems to provide a low-cost, low-maintenance solution.

ESAM (cont. ) l l l At the heart of the ESAM paradigm lies a Central Repository capable to persist and maintain meta-data about software artifacts that needs to be managed. The Central Repository should be able to support the large amount of assets that typically exist in the enterprise. Based on the Central Repository, ESAM further defines the following major phases:

1. Discovery: l l l Involves discovery of software assets from enterprise repositories and systems, and collection of relevant information from these repositories. This type of activity is complex because the assets may be distributed among multiple locations and exist in various formats. The process must insure that the Central Repository is kept in sync with the discovered domain as assets are constantly being added, deleted and modified.

2. Analysis: l l l Entails extraction of textual semantic features (meta-data) from the discovered assets. For ESAM to be effective, it is essential to properly identify the relevant meta-data for each asset type so that it can be leveraged for different use (e. g. search, impact analysis). The meta-data and analysis results are persisted in the Central Repository.

3. Repository Analysis l l Provides additional types of analysis that take into consideration a global view of the entire domain. Repository analysis works on the meta-data that has been collected and can include finding relationships between assets, finding duplications, accumulating statistics, performing data mining, enforcing coding convention, etc. In some cases user input can be required. The result is also stored in the Central Repository.

4. Service Implementation l l Encapsulates implementation of capabilities as services that leverage the information accumulated in the Central Repository. For example, this may include a search interface for finding reusable code, navigation interfaces for exploring the enterprise repositories, etc.

5. Service Integration l l Entails integration of the implemented services into existing processes and tools such as IDEs, Portals, knowledge management systems, etc. This phase often includes implementation of client side component that utilize the Service Implementation via APIs/Protocol.

Asset Locator Architecture l l Asset Locator is a low cost, low maintenance, extensible and scalable solution that has been developed in IBM, Haifa Research Lab, as a first step towards achieving ESAM. Asset Locator Central Repository is implemented using the DB 2 relational database and an index server that maintains the indexed textual information.

Asset Locator (cont. ) l l l Asset Locator is comprised of two major modules: The Information Gathering module which implements the first three ESAM phases And the Service Provider module which implements the last two phases.

The Information Gathering Module l l Asset Locator Discovery – Asset Locator uses a set of autonomous crawlers that can crawl into enterprise repositories to discover files that play role in the software development process (e. g design documents, source files, test suites). The Asset Locator Discovery is scheduled to be preformed automatically at predefined time slots, e. g at nights.

The Information Gathering Module (cont. ) l l It identifies new development resources in the repositories, as well as, maintaining previously crawled resources in sync with the crawled domain via time stamp comparison. AL ships with built in Crawlers for file system and Configuration Management (CM) systems like Clear. Case and Team. Connection.

The Information Gathering Module (cont. ) l l l Asset Locator Analysis – each file is recognize as corresponding to a specific type, usually identified by its extension or via content analysis. The Analysis phase is carried out by a set of Analyzers, each being responsible for analyzing resources of a certain type. Each analyzer extracts class name, super classes/interfaces, defined/used methods, comments, etc.

The Information Gathering Module (cont. ) l l This lays the necessary foundations for the search engine, facilitating free-text search as well as search for semantic information. Asset Locator ships with built in Analyzers for Java, COBOL, C/C++, JSP, HTML, XML, and text files, and more.

The Information Gathering Module (cont. ) l l l Asset Locator Repository Analysis – the meta-data populated in the ALCR is further analyzed in this phase. AL provides two basic repository analysis: Categorization of development resources into predefined (yahoo-like) domain taxonomies. AL ships with support for Java, HTML and XML taxonomies. Main categories in the Java taxonomy include Applets, Data Structures, I/O, GUI, Multimedia, Networking, Security.

The Information Gathering Module (cont. ) l Dependency Analysis that is preformed against entire ALCR and discovers relationships between the resources, both within assets that conform to the same type (e. g. hierarchy and reference relationships between Java classes) and between distinct types of resources.

The Service Provider Module l l Asset locator Service Implementation – a semantic Search Service enables clients, users or applications, to invoke queries against the information resides in the ALCR. This service enables to search for assets using both linguistic free-text constrains, as well as semantic constrains which correspond to the semantic features that were extracted for each type of resources.

The Service Provider Module (cont. ) l l A set of Result Formatters are provided to support a variety of formats for presentation and integration of query results. Asset Locator is shipped with built-in Result Formatters for general XML, HTML, etc.

The Service Provider Module (cont. ) l l l Asset Locator Service Integration – AL services are integrated with a set of clients systems: An integrated view in the client component of Team. Connection, IBM’s CM system. A web client based on HTML, Java. Script and SVG that supports various repository search and exploration views.

References: l l A classification of software components incompatibilities for COTS integration – Daniil Yakimovich, guilherme H. Travassos and Victor R. Basili COTS and open systems – An overview – Trica Oberndorf , SEI Component-based software development /COTS integration – Capt Gary haines, AFMC SSSG, David Carney, SEI and John Foreman, SEI Asset Locator – a framework for enterprise software asset management : IBM, Haifa Labs