Tool Integration Why Integrate Tools Which Tools to

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

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

Important Tool Adage • Tool Adage +Tools are necessary to improve productivity. • Tool Principle +Give Software Tools to Good Engineers. +You want bad engineers to produce less, not more, poor-quality software [Davi 95 a]. © S. Demeyer, S. Ducasse, O. Nierstrasz 3

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 Process (parts of) the Software Engineering • CARE: Computer Aided Reengineering - Mid 90’s +Support Software Reengineering Activities +Y 2 K tools © S. Demeyer, S. Ducasse, O. Nierstrasz +Round-trip engineering 4

Which Tools to Integrate? © S. Demeyer, S. Ducasse, O. Nierstrasz 5

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 6

Traditional. Tool Architecture “Most tools for reverse engineering, restructuring and reengineering use the same basic architecture. ” [Chik 90 a], [Chik 90 b] © S. Demeyer, S. Ducasse, O. Nierstrasz 7

Help Yourself - Parser • (Don’t) build your own parser! • But if you are forced +Use a parser generator to build a parser for the language • Remarks +C++ requires full control (lot’s of dialects + pre-compiling tricks) +Extremely complex +Java AST is LARGE +C# is fairly complex to simply parse © S. Demeyer, S. Ducasse, O. Nierstrasz 8

Parser • Advantage +Full control (dialects, pre-compilers) • Disadvantage +Experts only (formal syntax grammars) +Costly +Uncertain about reliability and scalability +Build your own = Maintain your own +Java changes continously +Tools to integrate with require source code or API © S. Demeyer, S. Ducasse, O. Nierstrasz 9

Help Yourself - File Formats Build gateways between existing tools by translating import/export file formats • Remarks +Works only when few gateways must be build +Standardization efforts are under way (XMI, MOF) +tackles “maintenance” and “duplication of efforts” problems +improves scalability and allows multiple tools © S. Demeyer, S. Ducasse, O. Nierstrasz 10

File Formats • Advantage +Relatively cheap (assuming formats are documented) +Offers reasonable integration +Reasonable scalability (limited by file system) • Disadvantage +Faith in external tools +Often not documented +Maintenance is difficult (future releases may change file-formats) +Effort to be duplicated for every tool © S. Demeyer, S. Ducasse, O. Nierstrasz 11

Help Yourself - API Technique: Build gateways between existing tools using wrappers that extract info via API’s • Remarks +Works only when few gateways must be build +May be combined with “Translate between fileformats” © S. Demeyer, S. Ducasse, O. Nierstrasz 12

API • Advantage +Usually 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 © S. Demeyer, S. Ducasse, O. Nierstrasz 13

Assumptions • Tools will give broken information +Missing instance variables still having accesses to it • Your system should be +Robust +Work with partial information © S. Demeyer, S. Ducasse, O. Nierstrasz 14

Help Yourself - Execution Trace • Collect Execution Traces • Technique: Acquire traces of sequences of method invocations +(code instrumentation, method wrapping, debugger, virtual machines) • Advantage +Good insight in the ‘real’ execution trace • Disadvantage +Expensive with current state of the art +Relies on reliable usage scenarios +Explosive data-growth • Remarks © S. Demeyer, S. Ducasse, O. Nierstrasz +Currently not often used, but gives spectacular 15

API Example - Java using the reflection facilities to inspect class import java. lang. reflect. *; public class Class. Inspector {. . . /* definition of auxiliary methods Print. . . */ public static void Inspect (Class c) { System. out. println(“Contents of class “ + c. get. Name()); Print. Fields (c. get. Fields()); Print. Constructors(c. get. Constructors()); Print. Methods(c. get. Methods()); } } © S. Demeyer, S. Ducasse, O. Nierstrasz 16

About Java Reflective API • Easy to use • But Limited +No accesses +Invocations © S. Demeyer, S. Ducasse, O. Nierstrasz 17

API Example - SNi. FF+ A piece of C-code which accesses the SNi. FF+ API to query the symbol table int main ( int argc, char *argv[] ) { SNi. FFACCESS slot; . . /*other declarations */ Parse. Args( argc, argv, &host, &proj, &session ); __si__module__init( ); slot = si_open(session, host); if( slot && si_open_project( slot, proj ) ) {full = si_Query(e. QImpl. Files, e. SGlobal, 0); . . /* enumerate pointer structure in ‘full’ */ si_close_project( slot, proj ); } si_exit(slot); © S. Demeyer, return 0; S. Ducasse, O. Nierstrasz } 18

API Example - Rational/Rose Pieces of Visual. Basic-code to generate elements into the Rational/Rose repository Sub Generate. Class. In (the. Class. Name As String, the. Category As Category) Dim the. Class As Class Set the. Class = the. Category. Add. Class(the. Class. Name) End Sub Generate. Inheritance. In (the. Subclass. Name As String, the. Superclass. Name As String, the. Category As Category) Dim the. Sub As Class Dim the. Inherit As Inherit. Relation Set the. Sub = the. Category. Get. All. Classes(). Get. First(_ the. Subclass. Name) Set the. Inherit = the. Subclass. Add. Inherit. Rel("", _ the. Superclass. Name) End Sub © S. Demeyer, S. Ducasse, O. Nierstrasz 19

Exchange Standards Standardization Efforts +CDIF (CASE data interchange format) - see http: //www. eigroup. org/ • Mature standard (being approved by ISO) • Dead influenced XMI +MOF (Meta-Object Facility) from OMG - see http: //www. omg. org/ • • Currently immature (approved by OMG late 1997) Major commitment from tool vendors to be expected Builds on UML and CORBA/IDL XMI : =XML + MOF © S. Demeyer, S. Ducasse, O. Nierstrasz 20

Exchange Standards Reference Format • How can tools exchange information without being aware of each other? • Answer: Tools agree on a single 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 21

Issues • Advantage: +Only need for one translation dictionary • Disadvantage +Centralized reference models do not work in practice +Need for specialized constructs (i. e. , jargon) +Cannot predict future specialization +Tools must negotiate about their reference model (meta model) © S. Demeyer, S. Ducasse, O. Nierstrasz 22

• Exchange Standards Openness How can tools extend the meta model with specialized constructs? • Answer: Each tool includes an extra glossary, explaining the specialized constructs in terms of a core reference model = 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 model) © S. Demeyer, S. Ducasse, O. Nierstrasz 23

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

CDIF sample (propriety syntax) © S. Demeyer, S. Ducasse, O. Nierstrasz 25

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

CORBA Interface for MOF interface Mof. Attribute. Class : Structural. Feature. Class { readonly attribute Mof. Attribute. UList all_of_kind_mof_attribute; readonly attribute Mof. Attribute. UList all_of_type_mof_attribute; Mof. Attribute create_mof_attribute ( /* from Model. Element */ in : : Model: : Name. Type name, . . . }; // end of interface Mof. Attribute. Class interface Mof. Attribute : Mof. Attribute. Class, Structural. Feature { boolean is_derived () raises (Reflective: : Structural. Error, Reflective: : Semantic. Error); © S. Demeyer, S. Ducasse, O. Nierstrasz void set_is_derived (in boolean new_value) 27

UML shortcomings • Current standardization efforts are geared towards UML. +not enough for reengineering +need “Invocation” & “Access” • Use extension mechanisms on the meta-model => how standard is standard? (See [Deme 99 d] in UML’ 99 Proceedings) © S. Demeyer, S. Ducasse, O. Nierstrasz 28

Conclusion • Reengineering requires Tools + Much in common with forward engineering + Must integrate with what’s already in place • “Help yourself” approach + Build your own parser + Translate between file-formats + Communicate via API’s + Collect Execution Traces • Standardization Efforts + CDIF is mature but dead / MOF & XMI are safest bets for future + Extensibility via Meta models (4 layer architecture) + UML has shortcomings © S. Demeyer, S. Ducasse, O. Nierstrasz 29

Moose We provide Moose -- our own tool integration platform -- as open source http: //www. iam. unibe. ch/~famoos © S. Demeyer, S. Ducasse, O. Nierstrasz 30