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

Recommend


More recommend