1 / 23

Software Architecture Classification for Estimating the Costs of COTS Integration

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.

galew
Télécharger la présentation

Software Architecture Classification for Estimating the Costs of COTS Integration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related