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 –Architecture-Based Languages & Environments –To develop “foundations for an engineering discipline for software architecture” Aesop System –Tool designed to “experiment with architectural development environments”

Aesop Inputs of Style Description & Shared Infrastructure Aesop’s black box Manipulation Result: Custom Design Environment aesop_home.html

Software Architecture Motivation –Depict a Complex System in Manageable Format –Identify & Exploit Recurring Elements

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

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

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

Nature of Components Infrastructure Control Model Data Model

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

Global Architectural Structure Role of Tools –Independent Tools Concurrency = Conflict

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

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