1 / 13

ARCHITECTURAL MISMATCH

ARCHITECTURAL MISMATCH. Heather T. Kowalski September 5, 2000. Article Details. “Architectural Mismatch: Why Reuse Is So Hard” By David Garlan, Robert Allen, & John Ockerbloom CMU Professor & Graduate Students IEEE Software, November 1995. Context. ABLE Project

chacha
Télécharger la présentation

ARCHITECTURAL MISMATCH

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 Heather T. Kowalski September 5, 2000

  2. Article Details • “Architectural Mismatch: Why Reuse Is So Hard” • By David Garlan, Robert Allen, & John Ockerbloom • CMU Professor & Graduate Students • IEEE Software, November 1995

  3. Context • ABLE Project • Architecture-Based Languages & Environments • To develop “foundations for an engineering discipline for software architecture” • Aesop System • Tool designed to “experiment with architectural development environments”

  4. Aesop • Inputs of Style Description & Shared Infrastructure • Aesop’s black box Manipulation • Result: Custom Design Environment • www.cs.cmu.edu/afs/cs/project/able/www/aesop/aesop_home.html

  5. Software Architecture • Motivation • Depict a Complex System in Manageable Format • Identify & Exploit Recurring Elements

  6. Software Architecture, con’t • Research Areas • Architectural Description • Formal Underpinnings • Design Guidance • Domain Specific Architecture • Architecture in Context • Role of Tools & Environments

  7. Harsh Realities • Excessive Code • Poor Performance • Modify External Packages • Need to Reinvent Existing Functions • Unnecessarily Complicated Tools • Error-Prone Construction

  8. Conflicting Assumptions -- Taxonomy • Nature of Components • Nature of the Connectors • Global Architectural Structure • Construction Process

  9. Nature of Components • Infrastructure • Control Model • Data Model

  10. Nature of Connectors • Protocols • Event Broadcast • Request/Reply pair • Data Model • C Constructs & Arrays • ASCII Strings

  11. Global Architectural Structure • Role of Tools • Independent Tools • Concurrency = Conflict

  12. Construction Process • Existing Infrastructure • Application Code • Reuse/Integration Code • Code Generated by other Packages

  13. Future • Design of Components • Codify Notations, Mechanisms, and Tools • Steps: • Explicitly Document Architectural Assumptions • Orthogonal Subcomponents • Sources of Design Guidance • Techniques for Bridging Mismatches

More Related