© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.1 10(b). Tool Integration Why Integrate Tools? Which Tools to Integrate? Tool Integration Issues The “Help yourself” approach  How to Obtain Data?  API Examples (Java, Rational/Rose) Exchange Standards  MOF & XMI  UML shortcomings

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.2 The Reengineering Life-Cycle Requirements Designs Code (0) requirement analysis (1) model capture (2a) problem detection (3) problem resolution (4) Code Transformation (1) Model Capture (2) Code transformation issues Different tools Model exchange (2b) Reverse Engineering

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.3 Why Integrate Tools? Tool Adage  Tools are necessary to improve productivity. Tool Principle  Give Software Tools to Good Engineers. “Bad” engineers should produce less, not more, poor-quality software [Davi95a]. Towards CARE  CAD/CAM: Computer Aided Design / Manufacturing – Late 70’s Create and validate design diagrams & steer manufacturing processes  CASE: Computer Aided Software Engineering — Late 80’s Support (parts of) the Software Engineering Process  CARE: Computer Aided Reengineering — Mid 90’s Support Software Reengineering Activities Y2K tools Round-trip engineering

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.4 Tool Integration Issues Reengineering vs. forward engineering  Forward engineering tools are chosen deliberately.  Reengineering tools must integrate with what’s already in place.  Tool integration in reengineering is harder ... but we can rely on forward engineering experience  “Help yourself” approach Tools must work together  share data  repository  synchronize activities  API  different vendors  interoperability standards

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.5 TraditionalTool Architecture “Most tools for reverse engineering, restructuring and reengineering use the same basic architecture.” [Chik90a], [Chik90b]

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.6 RoadMap Why Integrate Tools? Which Tools to Integrate? Tool Integration Issues The “Help yourself” approach  How to Obtain Data?  API Examples (Java, Rational/Rose) Exchange Standards  MOF & XMI  UML shortcomings

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.7 Help Yourself — Parser Technique: Use parser generator to build a parser for the language Advantage  Full control (dialects, pre-compilers) Disadvantage  Experts only (formal syntax grammars)  Costly  Uncertain about reliability and scalability  Build your own = Maintain your own  Tools to integrate with require source code or API Remarks  C++ requires full control (lots of dialects + pre-compiling tricks)  Extremely complex

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.8 Help Yourself - File Formats Technique: Build gateways between existing tools by translating import/export file formats Advantage  Relatively cheap (assuming formats are documented)  Offers reasonable integration  Reasonable scalability (limited by file system) Disadvantage  Faith in external tools  Maintenance is difficult (future releases change file-formats)  Effort to be duplicated for every tool Remarks  Works only when few gateways must be build  Standardization efforts are under way (CDIF, MOF)  tackles “maintenance” and “duplication of efforts” problems  improves scalability and allows multiple tools

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.9 Help Yourself - API Technique: Build gateways between existing tools using wrappers that extract info via APIs Advantage  Cheap  Good integration  Good scale-up (limited by wrapping tool)  Maintenance effort is reasonable (API’s don’t change that frequently) Disadvantage  Faith in external tools  Effort to be duplicated for every tool  Robustness Remarks  Works only when few gateways must be build  May be combined with “Translate between file-formats”

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.10 API Example - Java A piece of Java-code using the reflection facilities to inspect class elements import java.lang.reflect.*; public class ClassInspector {... /* definition of auxiliary methods Print... */ public static void Inspect (Class c) { System.out.println(“Contents of class “ + c.getName()); PrintFields (c.getFields()); PrintConstructors(c.getConstructors()); PrintMethods(c.getMethods()); }

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.11 API Example — Rational/Rose Pieces of VisualBasic-code to generate elements into the Rational/Rose repository Sub GenerateClassIn (theClassName As String, theCategory As Category) Dim theClass As Class Set theClass = theCategory.AddClass(theClassName) End Sub Sub GenerateInheritanceIn (theSubclassName As String, theSuperclassName As String, theCategory As Category) Dim theSub As Class Dim theInherit As InheritRelation Set theSub = theCategory.GetAllClasses().GetFirst(_ theSubclassName) Set theInherit = theSubclass.AddInheritRel("", _ theSuperclassName) End Sub

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.12 RoadMap Why Integrate Tools? Which Tools to Integrate? Tool Integration Issues The “Help yourself” approach  How to Obtain Data?  API Examples (Java, Rational/Rose) Exchange Standards  MOF & XMI  UML shortcomings

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.13 Exchange Standards Standardization Efforts  CDIF (CASE data interchange format) - see Mature standard (was approved by ISO) Death influenced by XMI  MOF (Meta-Object Facility) from OMG - see Approved by OMG late 1997 Major commitment from tool vendors to be expected Builds on UML and CORBA/IDL XMI :=XML + MOF eMOF

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.14 Exchange Standards — Reference Format How can tools exchange information without being aware of each other? Answer:  Tools agree on a single reference model reference model = meta model Analogy  How can French, German and Italian exchange documents? They agree to write their documents in Esperanto.

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.15 Exchange Standards — Reference Format (ii) Advantage:  Only need for one translation dictionary Disadvantage  Centralised reference models do not work in practice  Need for specialised constructs (i.e., jargon)  Cannot predict future specialization  Tools must negotiate about their reference model (meta model)

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.16 Exchange Standards — Openness How can tools extend the meta model with specialised constructs? Answer:  Each tool includes an extra glossary, explaining the specialised constructs in terms of a core reference model. core reference model = meta meta model Multiple Standards  How can tools deal with future extensions? Answer:  All glossaries (=meta model extensions) define mapping with the core reference model (= meta meta model)

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.17 Meta Models Exchange standards community cultivated specialized terminology: the Four Layer Metamodeling Architecture LayerDescriptionExample Meta Meta Model Defines the core ingredients sufficient for defining languages for specifying meta-models (CDIF) MetaEntity, MetaAttribute (MOF) Class, MofAttribute Meta Model Defines a language for specifying Models (UML) Class, Attribute, Association (Database) Table, Column, Row Model Defines a language to describe an information domain. Student, Course, enrolledin User Objects Describes a specific situation in an information domain. Student#3, Course#5, Student#3.enrolledin.Course# 5

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.18 MOF Sample (XML syntax)

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.19 CDIF (Old) Meta-Meta-Model: ER Syntax: ( ) + -TRUE- Example: (Class FM567 (name “Button”) (belongsTo “UIPackage”))

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.20 Be careful XML is standard but heavy, Not really readable by human Either you have a tool  XMI  Else be careful (MOF, eMOF, + XML + DTD + Validating rules + …)

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.21 UML 1.3 Shortcomings Current standardization efforts are geared towards UML.  not enough for reengineering (UML 1.3)  need “Invocation” & “Access” Use extension mechanisms on the meta-model  how standard is standard?(See [Deme99d] in UML’99)

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.22 Moose Our own reengineering platform -- as open source CDIF/XMI FAMIX meta-model for code representation  Metrics engine,  Evolution analysis  Program Visualization (CodeCrawler)

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.23 Conclusion Reengineering requires Tools  Much in common with forward engineering  Must integrate with what’s already in place “Help yourself” approach  Don’t build your own parser  Translate between file-formats  Communicate via APIs Standardization Efforts  MOF & XMI  Extensibility via Meta models (4 layer architecture)  UML has shortcomings

© S. Demeyer, S. Ducasse, O, Nierstrasz Tools.24 License Attribution-ShareAlike 2.5 You are free: to copy, distribute, display, and perform the work to make derivative works to make commercial use of the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. Attribution-ShareAlike 2.5 You are free: to copy, distribute, display, and perform the work to make derivative works to make commercial use of the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.