1 / 17

Architectural Mismatch: Why reuse is so hard?

Architectural Mismatch: Why reuse is so hard?. Garlan, Allen, Ockerbloom; 1994. Low level problems of interoperability as: incompatibilities in programming languages/platforms/data bases More discussed. Architectural mismatch: mismatch assumptions on the architecture of the system.

daisy
Download Presentation

Architectural Mismatch: Why reuse is so hard?

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. Architectural Mismatch: Why reuse is so hard? Garlan, Allen, Ockerbloom; 1994

  2. Low level problems of interoperability as: incompatibilities in programming languages/platforms/data bases More discussed Architectural mismatch: mismatch assumptions on the architecture of the system. Two kinds of mismatch

  3. Project: Aesop System • Environment generator for architecture styles • Input: Style and a shared infrastructure • Output: An environment which consists of: • tools that access the design database (OO) • GUI for modifying and creating new designs • repository of previous designs

  4. Requirements for interaction with DB • Tools may access the DB through RPC (invoking methods on objects in the DB) • Support for event broadcasting: Tools can register to be notified about changes in DB or announce events to other tools.

  5. Wishes on reusable parts • An OO Database -> OBST • A toolkit for constructing GUIs -> InterViews from Stanford University • An event-based tool-integration mechanism -> SoftBench from HP • An RPC mechanism -> Mach RPC Interface Generator • All in C++ or C, available source code.

  6. Discovered Integration Problems • Excessive code • Poor performance: save took several minutes, start overhead • Need to modify external packages to work together. • Need to reinvent existing functions • Unnecessarily complicated tools • Error-prone construction process: recompilation took time, code dependencies

  7. Architectural overview of the system • A system is a configuration of components and connectors. • Components: Entities of the system as tools, DB, servers, filters, etc • Connectors determine the interaction between components as client-server protocols, RPC, pipes.

  8. Four main assumptions that can lead to arch.mismatch • Nature of components • Nature of connectors • Global architectural structure • Construction process

  9. Nature of components • Infrastructure: Nature of the underlying support they need, additional infrastructure that they provide or use. Here all components provided additional. • Control model: Assumptions on what part of the system holds the main thread of control. • Data model: Nature of the data that components manipulate. E.g. InterViews has a hierarchical data structure where one object is part of another and can be modified only by the parent.

  10. Nature of Connectors • Protocols: E.g. SoftBench forces the clients to implement multiple threads of control; one for each request. • Data model: Assumptions about data that is communicated over connectors. E.g. MAC RPC supports data passes through procedures while SoftBench assumes passing of files.

  11. Global structure • E.g. OBST requires that tools are totally independent of each other. In Aesop, tools can delegate part of their computation to other tools.

  12. Construction Process • Dependencies between packages to compile, assumptions in each component on the structure of the code

  13. Solutions • Make architectural assumptions explicit • Construct large systems using orthogonal subcomponents • Provide bridging • Develop architectural design guidelines

  14. Make Assumptions Explicit • Document assumptions • Develop description vocabulary and languages for software architecture

  15. Use Orthogonal Subcomponents • Components with clear dependencies, easy to replace with other modules, easy to reconfigure

  16. Bridging Techniques • Mediators components that take over some of the tasks. • Smart connectors that translate data in multiple protocols. • Wrapper around a component or connector to offer a convenient interface • Negotiated interfaces: Components and connectors that handle several styles and can configure themselves dynamically.

  17. Design Guidance • Find rules and principles for composition • Develop guidance for certain application domains

More Related