Software Architecture Classification for Estimating the Costs of COTS Integration

1. Software Architecture Classification for Estimating the Costs of COTS Integration Yakimovich, Bieman, Basili; icse 99

2. Contents • A set of variables for cost estimation of COTS integration • A classification scheme of software architecture with respect to COTS integration

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

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

5. Continue • Component-platform interactions: on OS, CPU, etc. • Component-hardware interactions: reading from specified ports, etc. • Component-user interactions: user interface, language, etc

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

7. 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 Variables to represent assumptions

8. Definition: How a component is packaged for integration into a system. Values: Linkable vs independent. Component Packaging

9. Definition: How a system provides control flow to its components. Values: Centralized, decentralized, no assumption. Type of Control

10. 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). Information Flow

11. Definition: Whether or not a component blocks when waiting for a response. Values: Synchronous, Asynchronous. Synchronization

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

13. Software System Classification • Pipes and filters • Main program and subroutine • OO systems • Communicating process • Event systems • Blackboards • C2 architectural style • CORBA • COM

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

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

16. OO Systems • Components are objects. Connectors are invocation of objects. • Packaging: not relevant. • Control: usually centralized. • Information flow: control. • Synchronization: synchronous. • Binding: dynamic.

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

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

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

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

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

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

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