1 / 16

Connecting Architecture Reconstruction Frameworks

Connecting Architecture Reconstruction Frameworks. Ivan Bowman, Michael Godfrey, Ric Holt Software Architecture Group University of Waterloo CoSET ‘99 May 17, 1999. Introduction. Introduction. There is a wealth of re-engineering tools Often, we would like to combine these

layers
Télécharger la présentation

Connecting Architecture Reconstruction Frameworks

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. Connecting Architecture Reconstruction Frameworks Ivan Bowman, Michael Godfrey, Ric HoltSoftware Architecture Group University of Waterloo CoSET ‘99 May 17, 1999

  2. Introduction Introduction • There is a wealth of re-engineering tools • Often, we would like to combine these • Differences in tool storage formats and semantics makes reuse difficult • We defined an exchange format that can be used to combine several tools: • CIAO, Dali, Datrix, PBS, and Rigi

  3. Introduction Background • Recent work within CSER has identified opportunities for re-use between tools • We identified two levels of tools: • Code-Level tools provide detailed support • Architecture-Level tools identify high-level abstractions • We describe a format for connecting architecture-level tools

  4. System Artifacts Extractors View Generation Repository Scanning Source Code Visualization Manipulation Parsing Extracted Facts Executing System Profiling Architecture Change Reporting Source Control Introduction Architectural Reconstruction

  5. Model Entity-Relational Model • Entities represent source code elements such as functions, variables, or types • Relations represent associations in source code such as calls or inheritance • Attributes such as line-number record additional information • A Schema defines the allowed entities, relations, and attributes

  6. contains contains references line number Function Variable Module line number line number owner calls line number Model Example Schema

  7. Requirements Connection Format Requirements • Support multiple source languages • Scale to large systems (e.g. 10 MLOC) • Provide mapping to source code • Support static and dynamic dependencies • Incremental approach • Must be extensible, allowing new schemes to be defined as needed

  8. Problems The Naming Problem • Each entity must have unique ID • Source languages may allow two code elements to have the same name • typedef int T; • struct T { ... }; • To combine facts, we need a common naming scheme • We have defined a scheme for Java, and we are discussing possible solutions for C,C++

  9. Problems The Line-Number Problem • We require a mechanism to get from an entity back to source code • An obvious solution is to store file + line # • We want same file name on different machines • Some entities are defined on a range of lines, or non-contiguous ranges of lines (for example, namespaces)

  10. Problems The Resolution Problem • For each reference in source code, we can determine the reference target • Several resolution strategies are used: • No resolution - each reference is an entity • Resolved to declaration (in a header file) • Resolved to static definition (entity body) • Resolved to dynamic definition (virtual functions, pointers)

  11. TAXForm TAXForm • Idea: provide converters between tool-specific formats and a common format • There are two parts to an exchange format: • Syntax of data (representation in files) • Semantic structure (schemas) • We chose TA syntax (others are attractive) • We allow tool developers to define their own schemas as needed

  12. High-Level Procedural Object-Oriented PL/I C C++ Java Dali C PBS C Rigi C TAXForm Transforming Between Schemas Universal

  13. Evaluation Implementing TAXForm • We evaluated TAXForm by implementing converters for several existing re-engineering tools • The syntactic transformation was trivial • We used Tarski relational algebra to specify transformations, and executed them with grok, a relational calculator

  14. Evaluation Evaluation of TAXForm • Writing schema transformations required careful study of semantics used by each tool • Tools used different terminology with different underlying assumptions • By defining transforms between models, we formally document all of these assumptions and provide a dictionary for terminology

  15. Evaluation Systems Modeled

  16. Conclusion Summary and Future Work • We defined TAXForm as an exchange format between architecture-level tools • We validated our format by implementing converters from existing tool formats • We need to further describe the semantics of each model

More Related