introduction
play

Introduction Connecting Architecture There is a wealth of - PowerPoint PPT Presentation

Introduction Introduction Connecting Architecture There is a wealth of re-engineering tools Reconstruction Frameworks Often, we would like to combine these Differences in tool storage formats and Ivan Bowman, Michael Godfrey, Ric


  1. Introduction Introduction Connecting Architecture • There is a wealth of re-engineering tools Reconstruction Frameworks • Often, we would like to combine these • Differences in tool storage formats and Ivan Bowman, Michael Godfrey, Ric Holt semantics makes reuse difficult Software Architecture Group • We defined an exchange format that can be University of Waterloo used to combine several tools: – CIAO, Dali, Datrix, PBS, and Rigi CoSET ‘99 May 17, 1999 2 CoSET 1999 Introduction Introduction Background Architectural Reconstruction System Artifacts Extractors Repository View Generation • Recent work within CSER has identified Scanning opportunities for re-use between tools Source Visualization Code Parsing • We identified two levels of tools: Manipulation – Code-Level tools provide detailed support Executing Extracted Profiling System Facts – Architecture-Level tools identify high-level Architecture abstractions Source Change • We describe a format for connecting Control Reporting architecture-level tools 3 4 CoSET 1999 CoSET 1999

  2. Model Model Entity-Relational Model Example Schema • Entities represent source code elements Module such as functions, variables, or types contains contains owner • Relations represent associations in source code such as calls or inheritance references Function Variable • Attributes such as line-number record line number additional information line number line number • A Schema defines the allowed entities, calls relations, and attributes line number 5 6 CoSET 1999 CoSET 1999 Requirements Problems Connection Format Requirements The Naming Problem • Support multiple source languages • Each entity must have unique ID • Scale to large systems (e.g. 10 MLOC) • Source languages may allow two code elements to have the same name • Provide mapping to source code – typedef int T; • Support static and dynamic dependencies – struct T { ... }; • To combine facts, we need a common naming scheme • Incremental approach • We have defined a scheme for Java, and we • Must be extensible, allowing new schemes are discussing possible solutions for C,C++ to be defined as needed 7 8 CoSET 1999 CoSET 1999

  3. Problems Problems The Line-Number Problem The Resolution Problem • We require a mechanism to get from an • For each reference in source code, we can entity back to source code determine the reference target • An obvious solution is to store file + line # • Several resolution strategies are used: – We want same file name on different machines – No resolution - each reference is an entity – Some entities are defined on a range of lines, or – Resolved to declaration (in a header file) non-contiguous ranges of lines (for example, – Resolved to static definition (entity body) namespaces) – Resolved to dynamic definition (virtual functions, pointers) 9 10 CoSET 1999 CoSET 1999 TAXForm TAXForm TAXForm Transforming Between Schemas Universal • Idea: provide converters between tool- specific formats and a common format High-Level • There are two parts to an exchange format: Procedural Object-Oriented – Syntax of data (representation in files) – Semantic structure (schemas) PL/I C C++ Java • We chose TA syntax (others are attractive) • We allow tool developers to define their Dali C PBS C Rigi C own schemas as needed 11 12 CoSET 1999 CoSET 1999

  4. Evaluation Evaluation Implementing TAXForm Evaluation of TAXForm • We evaluated TAXForm by implementing • Writing schema transformations required converters for several existing re- careful study of semantics used by each tool engineering tools • Tools used different terminology with • The syntactic transformation was trivial different underlying assumptions • We used Tarski relational algebra to specify • By defining transforms between models, we transformations, and executed them with formally document all of these assumptions grok , a relational calculator and provide a dictionary for terminology 13 14 CoSET 1999 CoSET 1999 Evaluation Conclusion Systems Modeled Summary and Future Work • We defined TAXForm as an exchange System Size Language Tool format between architecture-level tools Jikes 77 KLOC C++ CIAO • We validated our format by implementing Linux 800 KLOC C Dali, PBS converters from existing tool formats • We need to further describe the semantics Mozilla 904 KLOC C Rigi of each model Nachos 10 KLOC C++ CIAO 15 16 CoSET 1999 CoSET 1999

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend