1 / 70

Advanced OOSA State of the Art on Software Architecture Declarative Meta Programming

Advanced OOSA State of the Art on Software Architecture Declarative Meta Programming. Session 5: Lightweight Architectural Tools Nantes, EMOOSE 2000–2001 Dr. Kim Mens, PROG, VUB. Course overview. Introduction Software Architecture Declarative Meta Programming Software Classification

brady-sosa
Download Presentation

Advanced OOSA State of the Art on Software Architecture Declarative Meta Programming

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. Advanced OOSAState of the Art on Software Architecture Declarative Meta Programming Session 5: Lightweight Architectural Tools Nantes, EMOOSE 2000–2001 Dr. Kim Mens, PROG, VUB

  2. Course overview • Introduction • Software Architecture • Declarative Meta Programming • Software Classification • Lightweight Architectural Tools • Automated Architectural Conformance Checking • An Architecture-driven Software Development Tool • Assignments State of the Art on Software Architecture — Declarative Meta Programming

  3. Session overview • Lightweight architectural tools • Lightweight source-model extraction • Software reflexion models • Conceptual module querying • Summary • Lightweight architectural tools • Lightweight source-model extraction • Software reflexion models • Conceptual module querying • Summary State of the Art on Software Architecture — Declarative Meta Programming

  4. Lightweight architectural tools • Lightweight source-model extraction • automatically reverse engineer high-level source models from implementation • Software reflexion models • automatically check conformance of extracted source models to desired high-level models • Conceptual module querying • support reengineering • allows software engineers to perform queries simultaneously about both existing and desired source structure • a conceptual module is a set of lines of source that are treated as a logical unit State of the Art on Software Architecture — Declarative Meta Programming

  5. RECAP References • Lecture “Connecting Task to Source” by Gail Murphy. • Murphy, Notkin & Sullivan. Software Reflexion Models: Bridging the Gap Between Source and High-Level Models. In Proceedings of the FSE’95 Symposium, pp. 18-28. ACM Press, 1995. • Murphy & Notkin. Reengineering with Reflexion Models: A Case Study. In IEEE Computer 30, 8, pp. 29-36, 1997. • Reflexion Model tool: http://www.cs.ubc.ca/~murphy/software/rmtool/index.html • Murphy & Notkin. Lightweight Lexical Source Model Extraction.ACM Transactions on Software Engineering and Methodology, vol. 5, no. 3, July 1996, pp. 262-292. • Lightweight Source Model Extraction tool: http://www.cs.ubc.ca/~murphy/software/lsme/index.html • Baniassad & Murphy. Conceptual Module Querying for Software Reengineering. In Proceedings of the 20th International Conference on Software Engineering, pp. 64-73. IEEE, 1998. State of the Art on Software Architecture — Declarative Meta Programming

  6. Session overview • Lightweight conformance checking techniques • Lightweight source model extraction • Software reflexion models • Conceptual module querying • Summary Reference: • Murphy & Notkin 1996. Lightweight Lexical Source Model Extraction.ACM Transactions on Software Engineering and Methodology, vol. 5, no. 3, July 1996, pp. 262-292. State of the Art on Software Architecture — Declarative Meta Programming

  7. Lightweight source-model extraction • Source-model extraction • automatically extract high-level info from implementation • call graphs, file dependencies, event interactions, cross-reference lists, program-dependence graphs, … • independent of implementation language • C, C++, CLOS, Eiffel, … • information can be extracted from • source code, macros, comments, … • Lightweight • small and easy to write specifications of desired source model • lexical specifications State of the Art on Software Architecture — Declarative Meta Programming

  8. Lexical approach • Scan only for constructs relevant to the source model • for example: extracting a call graph • only look for calls in the source code • skip all data declarations, control constructs, … • Similar to lexically-based tools like ‘grep’ • But additional support for • matching source constructs in context • and across multiple lines • Alternative approach: parsing • more precise • but places syntactic constraints on the source code • and building/modifying parsers is not trivial State of the Art on Software Architecture — Declarative Meta Programming

  9. Approximate information • Extracted information is approximate • not all intended constructs may be extracted • some unintended constructs may be extracted • Approach trades precision in extraction for increased • efficiency • more efficient than parsing but less precise • false positives and missing information • flexibility • information can be extracted from code, macros, comments, … • tolerance • information can be extracted from non-compilable code, code that is not linked, … State of the Art on Software Architecture — Declarative Meta Programming

  10. Generate Generate Scanner Analyser Source Code Source Model Intermediate Representation Architecture of thesource-model extraction system Source-model specification State of the Art on Software Architecture — Declarative Meta Programming

  11. Pattern definitions: the patterns of interest in the source code Action definitions: actions to execute when a pattern is matched in the code are used to generate a Post-processing analysis operations: operations that combine local info extracted from individual source code files into a global source code model are used to generate an defines Source-model specification Source model specification Scanner Analyser State of the Art on Software Architecture — Declarative Meta Programming

  12. Source model specification:pattern definitions • Code patterns are described as regular expressions • For example: extracting function names from C source [<type>] <functionName> \( [ { <formalArg> }+ ] \) [ { <type> <argDecl> ; }+ ] \{ • optional type specification, followed by • name of the function and left parenthesis, followed by • optional list of formal arguments and right parenthesis, • optional list of declarations of the formal argument types, • and finally a curly brace to start the function body • This pattern does not capture all function definitions • e.g. it misses type declarations of the form int * x; • but can be refined to capture 99% of the cases State of the Art on Software Architecture — Declarative Meta Programming

  13. Source model specification:action definitions • Attach action code to patterns to be executed when the pattern is matched in the source code • For example: print names of extracted functions [<type>] <functionName> @ write ( functionName ) @ \( [ { <formalArg> }+ ] \) [ { <type> <argDecl> ; }+ ] \{ State of the Art on Software Architecture — Declarative Meta Programming

  14. Generate Generate Scanner Analyser The generated tools • More info on the generated scanner and analyser, see Murphy & Notkin 1996 State of the Art on Software Architecture — Declarative Meta Programming

  15. Session overview • Lightweight conformance checking techniques • Lightweight source model extraction • Software reflexion models • Conceptual module querying • Summary Reference: • Murphy, Notkin & Sullivan. Software Reflexion Models: Bridging the Gap Between Source and High-Level Models. In Proceedings of the FSE’95 Symposium, pp. 18-28. ACM Press, 1995. • Murphy & Notkin. Reengineering with Reflexion Models: A Case Study. In IEEE Computer 30, 8, pp. 29-36, 1997. Slides mainly based on lecture “Connecting Task to Source” by Gail Murphy. State of the Art on Software Architecture — Declarative Meta Programming

  16. Software reflexion models • A typical estimation scenario • Software reflexion model • Software reflexion model technique • Experiences • A typical estimation scenario • Software reflexion model • Software reflexion model technique • Experiences State of the Art on Software Architecture — Declarative Meta Programming

  17. You are asked to provide, within 5 days, an estimate of the effort required to modify an implementation of a Unix operating system to page over a distributed network A typical estimation scenario Slide taken from lecture “Connecting Task to Source” by Gail Murphy NetBSD Kernel Source Code State of the Art on Software Architecture — Declarative Meta Programming

  18. Software visualization Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  19. Practical problems • Difficult to understand software structure directly from the (very large) source code • Visualisation tools suffer from essentially the same problem • Software reflexion models • limit the scope by comparing a (small) desired diagram with the source code • do not work on the source code directly but on an extracted source model State of the Art on Software Architecture — Declarative Meta Programming

  20. Software reflexion models • A typical estimation scenario • Software reflexion model • Software reflexion model technique • Experiences State of the Art on Software Architecture — Declarative Meta Programming

  21. High-level model of a Unix virtual memory subsystem drawn by a domain expert High-level model Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  22. Software reflexion model • After comparing the high-level model with an (extracted) source model, a software reflexion model is generated • This is an annotated version of the high-level model • convergences • discovered interactions in the source that were expected by the high-level model • divergences • discovered interactions that were not expected • absences • interactions that were expected but were not found • Each of the lines is annotated with a number indicating the number of discovered interactions State of the Art on Software Architecture — Declarative Meta Programming

  23. Software reflexion model Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  24. Software reflexion models • A typical estimation scenario • Software reflexion model • Software reflexion model technique • Experiences State of the Art on Software Architecture — Declarative Meta Programming

  25. Reflexion 4 Model 3 Model 1 RM Mapping Tools Extraction Source Tool Model Software System 2 Artefacts Software reflexion model technique Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  26. Syntactic Multiple relations “everyone has one or more” 1. State a high-level model Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  27. 2. Extract a source model Slide taken from lecture “Connecting Task to Source” by Gail Murphy • Use existing tools (e.g., cflow, Field, etc.) • Lightweight lexical source model extractor (Murphy/Notkin) • May contain multiple relations State of the Art on Software Architecture — Declarative Meta Programming

  28. 3. State a declarative mapping Source Model EntitiesHigh-Level Model Entitiesfile=pager.c Pager file=vm_map.* VirtualAddressMaint. dir=vm func=active VMPolicy Slide taken from lecture “Connecting Task to Source” by Gail Murphy • Name source model entities using: • physical and logical software structure • regular expressions • Many-to-many mapping State of the Art on Software Architecture — Declarative Meta Programming

  29. 4. Investigate a reflexion model Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  30. Iteration • Want to investigate the data relationships? • augment the source model • update the mapping: var=queue.*active VMPolicy • recompute... Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  31. Refined reflexion model Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  32. Software reflexion models • A typical estimation scenario • Software reflexion model • Software reflexion model technique • Experiences State of the Art on Software Architecture — Declarative Meta Programming

  33. Experience Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  34. Excel: experimental reengineering • A Microsoft engineer computed reflexion models several times a day for four weeks • 120,000 calls and global variable references • map file with over 1000 entries • high-level model with 15 entities and 96 interactions • 4 minutes to compute on a 486 • Some lessons learned: • map files evolved to be larger than expected • scale places pressure on managing the information Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  35. Session overview • Lightweight conformance checking techniques • Lightweight source model extraction • Software reflexion models • Conceptual module querying • Summary Reference: Elisa L. A. Baniassad & Gail. C. Murphy. Conceptual Module Querying for Software Reengineering. In Proceedings of the 20th International Conference on Software Engineering, pp. 64-73. IEEE, 1998. Slides mainly based on lecture “Connecting Task to Source” by Gail Murphy. State of the Art on Software Architecture — Declarative Meta Programming

  36. Conceptual module querying • Goal • A typical reengineering scenario • Different reengineering approaches • Conceptual module approach • Querying about conceptual modules • Experiences with conceptual modules • Goal • A typical reengineering scenario • Different reengineering approaches • Conceptual module approach • Querying about conceptual modules • Experiences with conceptual modules State of the Art on Software Architecture — Declarative Meta Programming

  37. Goal • Support software reengineering • reengineering is more than source code analysis • reengineering requires reasoning about source code… • identification and extraction of new software components from existing source code • …but also about desired source structure • interactions of new components with remaining source code • interactions among newly-formed components • Allow software engineer to simultaneously perform queries about the existing and desired source structure • A conceptual module is a set of lines of source that are treated as a logical unit State of the Art on Software Architecture — Declarative Meta Programming

  38. Conceptual modules are like software classifications Both conceptual modules and software classifications • group a set of related source code entities • represent some logical or conceptual unit • may cross-cut the source code • e.g., code lines included in a CM may be split across existing procedure boundaries State of the Art on Software Architecture — Declarative Meta Programming

  39. Conceptual module querying • Goal • A typical reengineering scenario • Different reengineering approaches • Conceptual module approach • Querying about conceptual modules • Experiences with conceptual modules State of the Art on Software Architecture — Declarative Meta Programming

  40. A typical reengineering scenario Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  41. Reengineering scenario... main procedure: Slide taken from lecture “Connecting Task to Source” by Gail Murphy Input Pipe sort procedure: State of the Art on Software Architecture — Declarative Meta Programming

  42. Conceptual module querying • Goal • A typical reengineering scenario • Different reengineering approaches • Conceptual module approach • Querying about conceptual modules • Experiences with conceptual modules State of the Art on Software Architecture — Declarative Meta Programming

  43. Different reengineering approaches • Five different program understanding tools: • xrefdb (part of Field) • cross-reference database tool • Unravel • slicing tool • Lackwit tool • based on type-inferencing • Software reflexion model • Conceptual module tool • Task: • create an input pipe component from the GNU sort program. State of the Art on Software Architecture — Declarative Meta Programming

  44. Cross-reference database • Identify variables of interest • For each variable • where is the variable declared? • where is the variable referenced? • Collate results • Repeat • Result: Using Field’s xrefdb, 126 lines were returned of which only 30% were relevant Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  45. Slicer • Compute backward slices on variables in pre-identified lines of code • Slice computation took several hours; only partial were viewed • Result: Slices computed with Unravel were > 750 nodes in size and included many irrelevant procedures Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  46. Type inferencer • Compute which procedures affect the values of particular variables • The Lackwit tool produces graphs summarizing how values are transmitted through a program • Provides information on relevant procedures but not on relevant source code lines • Result: Lackwit graphs are often large and are reported in terms of the existing structure Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  47. Software reflexion model • Difficult to ascertain interface of the module • No support for querying the source model • Syntactic comparison Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  48. Conceptual module querying • Goal • A typical reengineering scenario • Different reengineering approaches • Conceptual module approach • Querying about conceptual modules • Experiences with conceptual modules State of the Art on Software Architecture — Declarative Meta Programming

  49. Source code Source Model Source Model Extraction Tool Form a CM Conceptual Module Tool Interface Analysis Query Query Results Conceptual module approach Slide taken from lecture “Connecting Task to Source” by Gail Murphy State of the Art on Software Architecture — Declarative Meta Programming

  50. Source code Source Model Source Model Extraction Tool Source model • Instead of reasoning directly about source code, the approach reasons about an extracted source model • Source model is directed towards a procedural language and consists of three relations: • variable dependence relation • uses and definitions of variables (described by line number) • control transfer relation • procedure calls (line number of call site and called procedure) • procedure start relation • source line number on which a procedure starts State of the Art on Software Architecture — Declarative Meta Programming

More Related