Open Tool Integration Framework Gabor Karsai Institute for Software-Integrated Systems PO.Box 1829B Vanderbilt University Nashville, TN 37235, USA

Overview Tool Integration problem domain Meta-model driven integration Architecture Protocols Example Conclusions

Tool Integration Problem Domain An engineering process supported by many tools. How to facilitate model interchange? FMECA Diagnostics JLME SafetyF. Impact Assumptions: Tools are the primary holders of documents (=models) Integration should be supported by an architecture that can be instantiated for specific tools Architecture elements interoperate via well-defined protocols

Tool Integration Problem Domain Tool-A Tool-B Tool-CTool-D Tool-E Assumptions: The engineering process defines a work flow, which imposes dependencies among the tools. Each edge is a (potential) place for a translation on models. The Tool Integration Framework should provide the infrastructure to construct tool chains consisting of arbitrary tools and translators. Tools can reside on different hosts, possibly as web services.

Meta-model driven integration Assumptions: The integration happens through a translation process that connects various tools into a tool chain. Tools manage their “own” data – it is not the task of the framework. Tools are described using meta-models capturing the abstract syntax of the models. Tool-A Tool-B Tool-CTool-D Tool-E Metamodel A input Metamodel A output Metamodel C input Metamodel C output Metamodel D input Metamodel D output Metamodel B input Metamodel B output Metamodel E input Metamodel E output

Meta-model driven integration What meta-data? 1.Abstract syntax: entities, attributes, relationships of the tool’s data. 2.Well-formedness constraints  UML class diagrams + OCL expressions Why meta-data? Allows a general, tool-independent, canonical form for models that can be used in the communication protocols Provides for type-checking on models Provides help in developing translators Translators: model-to-model transformation engines Allows generic tools for archiving, visualizing, manipulating, etc. models

Architecture Message routing, metadata repository, workflow engine Direct tool interface Syntactic translation of tool data Semantic translation of tool data Management interface

Architecture Example Tool-A Tool-B Tool-CTool-D Tool-E Backplane Tool-ATool-CTool-BTool-DTool-E A adaptorB adaptorC adaptorD adaptorE adaptor A2CA2BA2EB2DB2EC2D Tool chain: As implemented:

Protocols Data transfer Metamodel: a1:Ac1:Cc2:Cb1:Br1:Rel Typing Metamodels are instances of (UML-)meta classes reside in the backplane accessed via object references Similar to MOF Model elements (i.e. data) are instances of structures tagged with a type ID (from the corresponding meta model) Relationships are implemented via instance Ids BLOB-s are also supported Transferred in a container Model (data):

Protocols Data transfer – Meta-metamodel

Protocols Data transfer – Objects and Containers // Data object struct Obj { TypeGUID tId; // TypeId of meta object (Class) objectId id; // Unique object id timeStamp created;// Creation time timeStamp modified;// Last modification time string creator;// Creator's name string modifier;// Last modifier's name AttrValue_S attrs; // Attribute values ParentRole parent; // Parent object AssocRole_S assocs;// Associations of this object any userData; // Add'l, impl-spec data }; typedef sequence Obj_S; // Network of data objects struct DataNetwork { TypeGUID tId; // TypeId of meta object (Diagram) objectId root; // Root object Obj_S objects; // All objects };

Protocols Backplane Interface Information services: – Current metamodels,translators, active documents and tool adaptor types – Locking, fetching, unlocking a metamodel – Tool adaptor information – Current timestamp – Upload configuration Session services – Login/logout a manager – Login/logout a tool adaptor

Protocols Session Interfaces Manager session: – Register/unregister metamodel – Register/unregister translator – Modify attributes of/destroy document – Change password/shutdown backplane Tooladaptor session: – Publish document – Subscribe to new document/change notifications – Fetch documents – Retrieve information about document

Protocols Translator Interfaces Translator activation command: %FeedURI %SinkURI TranslatorFeed interface – Subscribe to / Fetch documents TranslatorSink interface – Publish documents Backplane Translator Feed Sink Notify() Fetch() Publish()

AIF XML CONFIG XML Example A practical system: ESML Toolsuite Rational Rose ESML/GME ESCM2ESML Analysis Tool(s) ESML2AIF AIF2ESML ESML2CONF CONF2ESML Execution Platform Instrumentation CONF2ESML Build Tool Component Development System Development System Analysis System Generation Legacy Reverse Engineering Analysis feedback Model update from instrumentation

Example A practical system: ESML Toolsuite Workflow: Prescribes the correct sequencing of tool operations Workflow model: Tools and their adaptors Document types and flows Translation operations Workflow: Prescribes the correct sequencing of tool operations Workflow model: Tools and their adaptors Document types and flows Translation operations AIF XML CONFIG XML Rational Rose ESML/GME ESCM2ESML Analysis Tool(s) ESML2AIF AIF2ESML ESML2CONF CONF2ESML Execution Platform Instrumentati on CONF2ESML Build Tool

Example A practical system: ESML Toolsuite ESML/GME Rational Rose AnalysisTool(s) Backplane escm2esmlesml2confconf2esml esml2aif ESCM (XML) Exporter T/A ESML (MGA) ESML (MGA) T/A CONF (XML) Buildprocess T/A AIF (XML) IIF (XML) T/A iif2aif T/A aif2esml

Summary Architecture and protocols defined Prototype implementations exists – OTIF (incl. Eclipse Generic Tool Adaptor) Next steps: – MOF compliant data layer – Fine-grain change notification Event-based integration – Object traceability