Software Architecture Classification for Estimating the

Costs of COTS Integration Yakimovich, Bieman, Basili; icse 99

Contents

• A set of variables for cost estimation of COTS integration

• A classification scheme of software architecture with respect to COTS integration

Techniques for COTS integration

• Change the component being integrated. Possible if source code is available, etc

• Use glueware = integration software. It is software that provides proper interface for the component (like wrappers) or serves as a mediator.

• >> Both techniques can lower system quality.

Interaction Protocol Mismatch

• Mismatch between assumptions by component on interaction with the environment and assumptions of the system.

• 4 types of interactions:– Component-platform interactions– Component-hardware interactions– Component-user interactions– Component-software interactions

Continue

• Component-platform interactions: on OS, CPU, etc.

• Component-hardware interactions: reading from specified ports, etc.

• Component-user interactions: user interface, language, etc

Component-software interactions

• Assumptions about nature of components: infrastructure, control model, data model.

• Assumptions about nature of connectors: protocols, data model.

• Assumptions about the global architecture: topology, etc

• Assumptions about the construction process

Variables to represent assumptions

• Component packaging• Type of control• Type of information

flow• Synchronization• Binding

• A=B; Values are equal.

• A>=B; The value of A is greater than B.

• A=< B, The value of A is greater than B.

• A ~ B, A and B are not comparable

Component Packaging

• Definition: How a component is packaged for integration into a system.

• Values: Linkable vs independent.

Type of Control

• Definition: How a system provides control flow to its components.

• Values: Centralized, decentralized, no assumption.

Information Flow

• Definition: What type of information flows between components.

• Values: Control flow (invocation of some routines), data flow (exchange of data as message passing, shared memory), mixed (accepts both and can convert).

Synchronization

• Definition: Whether or not a component blocks when waiting for a response.

• Values: Synchronous, Asynchronous.

Component Binding

• Definition: How components are attached to connectors and how the participants in an interaction are determined.

• Values: static (predetermined), dynamic (compile time or run-time), mixed.

Software System Classification

• Pipes and filters• Main program and subroutine• OO systems• Communicating process• Event systems• Blackboards• C2 architectural style• CORBA• COM

Pipes and Filters

• Filters have input and output. Pipes are connectors.

• Packaging: not relevant.

• Control: not relevant.

• Information flow: data.

• Synchronization: not relevant.

• Binding: dynamic.

Main Program and Subroutines

• Components are procedures and functions. Connectors are calls between them.

• Packaging: not relevant. All linked together.

• Control: centralized.

• Information flow: control.

• Synchronization: synchronous.

• Binding: static.

OO Systems

• Components are objects. Connectors are invocation of objects.

• Packaging: not relevant.

• Control: usually centralized.

• Information flow: control.

• Synchronization: synchronous.

• Binding: dynamic.

Communicating Process

• Components are independent processes. Connectors are messages, RPC, shared memory, etc.

• Packaging: not relevant.• Control: decentralized.• Information flow: not relevant (in fact both).• Synchronization: not relevant.• Binding: not relevant.

Event systems

• A component register for an event and is called back.

• Packaging: not relevant.

• Control: decentralized.

• Information flow: control.

• Synchronization: not relevant.

• Binding: dynamic.

Blackboards

• Components are blackboards that stores the state of the system and other components have access to it. Actions are triggered by specific states.

• Packaging: not relevant.• Control: not relevant.• Information flow: data.• Synchronization: not relevant.• Binding: static. Everything is attached to the

blackboard.

C2 Architectural Style

• An OO framework with few assumptions.• Limitations: Message-based communication (provides

wrappers as well), layered architecture.• Packaging: depends on whether the language is

supported.• Control: all types.• Information flow: data.• Synchronization: all types.

• Binding: dynamic.

CORBA

• For distributed OO architectures. Language and platform independent.

• Packaging: depends on whether the language is supported.

• Control: decentralized.• Information flow: control (like RPC).• Synchronization: all types.• Binding: run-time dynamic using Naming service.

COM

• Binary, objects make RPC, language independent, multiple interfaces for an object.

• Packaging: depends on whether the language is supported.

• Control: decentralized.• Information flow: control (like RPC).• Synchronization: all types.• Binding: run-time dynamic using QueryInterface.

Estimating Integrating Costs

• Fine the interaction vector of the system (Vs) and the COTS (Vp) and compare:– Vs=Vp; match. – Vs >= Vp; still compatible.– Vs <= Vp; some assumptions are not compatible.A

common upper element Vc is found and the cost of modifying the system and the COTS towards Vc is estimated.

• Example in the article