software architecture classification for estimating the costs of cots integration yakimovich,...
TRANSCRIPT
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