Title of Invention

A METHOD FOR MDD TOOL INTEGRATION

Abstract

A method and a toolset for MDD tool integration by way of Abstracting the problem of integration of purpose-specific MDD tools as a problem, of integration of kinds of MDD tools, Building integration bridges between different kinds as opposed to specific tools, Plugging in a specific MDD tool in the MDD integration bus by building a tool-specific adapter, and an adapter to the integration bus for every specific MDD tool where the tools create models corresponding to the viewpoints of interest where a viewpoint is specified as a metamodel with well-defined semantics and wellformedness constraints.

Full Text

FORM-2 THE PATENTS ACT. 1970 (39 of 1970) COMPLETE SPECIFICATION (Section 10, rule 13) “A method and a toolset for MDD tool integration” Tata Research Development and Design Center a division of Tata Consultancy Services Limited, with our Corporate office at 11th Floor, Air India Building, Nariman Point, Mumbai 400 021, Maharashtra. an Indian Company registered under the provisions of the Companies Act, 1956. The following specification particularly describes the nature of the invention and the manner in which it is to be performed: - Dated this 1st August, 2005 For Tata Consultancy Services Limited S. H. RAJADHYAKSHA Company Secretary The present invention relates to the integration of specific Model Driven Development (hereinafter MDD) tools by abstracting it as a problem of integration of kinds of MDD tools and by proposing a generic solution based on an architecture pattern that enables quick integration of MDD tools with reduced effort. More particularly the present invention relates to building integration bridges between different tool kinds which collectively can be seen as an MDD integration bus into which an individual MDD tool (of a kind) can plug-in by using a tool-specific adapter. Still particularly, it relates to a modelling architecture that provides a set of guidelines for structuring specifications expressed as models catering to the concerns of multiple stakeholders and it relates to the standards that support the architecture that allows the specified system functionality to be realized on multiple platforms through a set of mappings thus enabling easy system evolution as platform technologies come and go. MDD defines an approach to IT system specification that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform. To this end, the MDD defines an architecture for models that provides a set of guidelines for structuring specifications expressed as models. A system typically needs to cater to the concerns of multiple stakeholders. These concerns are specified as models using appropriate modeling languages. The complete system specification can be seen as a set of such related models. A typical MDD toolkit comprises of the following kinds of tools: a. Modeling tool supporting a particular modeling language e.g., Unified Modelling Language, Common Warehouse Model, Business Process Modelling Language etc. b. Model based code generators translating the application models to the various text artifacts namely code, configuration files, documents etc. c. Integrated development environment supporting the development process d.. Configuration management tools for managing and tracking application evolution e. Tools to support various SDLC phases like requirements management, testing, change management etc. f. Tools to validate conformance of specifications to standards e.g. modeling standards, coding standards etc. Many vendors offer tools in each of the above-mentioned areas. However, no single vendor offers tools covering all the system development needs of the wide range of enterprise applications. Therefore, it becomes necessary to integrate the best-of-breed tools offered by different vendors in order to support the specific system development endeavor. Building point-to-point integration bridges between the tools of interest is time consuming and effort intensive. Standards exist for various modelling languages such as UML, CWM, BPML etc. There exists, in XMI [7], a standard interchange format for exchanging models of a given modelling language between different modelling tools for that language offered by different vendors. Also, standards exist for specifying transformations between the various standard modelling languages. These standards enable one to build a point-to-point bridge between two specific MDD tools. Exporting the source model in XMI format, transforming the model if required and then importing the model into the target tool typically realize such a bridge. Construction of such a point-to-point bridge is effort intensive and time consuming. For a variety of reasons, different enterprises will have different choices for MDD tool of each kind. Thus it is difficult to conceive of a single configuration of MDD tools that can address the needs of many, if not all, enterprise system development endeavours. At present, there is no better handle on addressing this need of integrating MDD tools than building point-to-point bridges for each such tool pair. Integrating specific tools using point-to-point bridges results in excessive set-up and maintenance costs and makes the development process less agile for any change in tool configuration. Although these problems are rapidly becoming more acute, they have been acknowledged by the technicians for many years. The problem of integration of specific MDD tools thereby needs a quick and feasible solution and it is the object of this invention to effectively address it as a problem of integration of kinds of MDD tools. Summary of the invention We address the problem of integration of specific MDD tools by abstracting it as a problem of integration of kinds of MDD tools. A specific MDD tool can be seen as a variant of its kind. In the proposed approach, integration bridges are built between different kinds (of tools) as opposed to individual tools. A set of such integration bridges together can be seen as an MDD integration bus into which an individual MDD tool (of a kind) can plug-in using a tool-specific adapter. Consider MDD toolkit comprising of two kinds of tools each having individual tools as shown in figure 1. Integration using point-to-point bridge approach will require construction of k*m bridges. Addition of a new tool of kind l will necessitate construction of m additional bridges. The proposed approach would necessitate construction of a single bridge integrating the two kinds and an adapter each for every specific tool to the integration bus as shown in figure 2. Addition of a new tool of kind l will necessitate construction of just one additional adapter for that specific tool. MDD enables various stakeholders to create models corresponding to their viewpoints where a viewpoint is specified as a metamodel with well-defined semantics and wellformedness constraints. Relationships between viewpoints are specified in terms of associations and constraints between the corresponding metamodels. All these metamodels are defined using a single standard meta modelling language and relationships between them are also specified using a single standard language. However, in our approach, a tool kind corresponds to a viewpoint i.e., tools belonging to that kind, possibly from different vendors, manage models of that viewpoint. Integration requirements between tools can be specified in terms of the relationships between the corresponding viewpoints i.e. corresponding metamodels. Our approach addresses the tool integration in two steps namely integration of the viewpoints corresponding to their tool kinds and adaptation of a tool to its viewpoint as shown in figure 3. Viewpoint1MetaModel and Viewpoint 2 MetaModel correspond to the two viewpoints managed by two tool kinds that need to be integrated. UnifiedNormalizedMetaModel is the minimally sufficient metamodel that can represent all viewpoints of interest. In figure 3, Viewpoint 1MetaModel and Viewpoint 2MetaModel are projections of UnifiedNormalizedMetaModel. Relation 12 specifies the relationships that should hold between the model instances of metamodels Viewpoint 1 MetaModel and Viewpoint 2MetaModel. The relation can be used to check consistency between model instances of Viewpoint1 MetaModel and Viewpoint! MetaModel, and to transform a model instance of one into a model instance of the other in a bi-directional manner [5]. There can be many tools to manage models for a viewpoint. In figure 3, tools Tooll and Tool! are specific tools that manage models corresponding to viewpoint 1 metamodel. These tools produce models corresponding to the metamodels Tooll MetaModel and Tool2MetaModel respectively. RelationTooll and RelationTool2 specify the relationships that should hold between the model instances of the metamodels of the tools and the model instances of their corresponding viewpoints. The relation RelationTooll can be used to check consistency between model instances of ToollMetaModel and Viewpoint1MetaModel, and to transform a model instance of one into a model instance of the other in a bi-directional manner; and similarly for RelationTooll. Addition of a new tool, say Tool3, will only necessitate specification of the relationship between the metamodel of Tool3 and the meta model of the corresponding viewpoint as shown in figure 3. The integration scenarios can be broadly classified into two: Peer-to-peer scenario where models have overlapping content and are simultaneously produced by two tools. In this scenario, we need to first check if the models are consistent with each other and resolve inconsistencies, if any, by propagating appropriate model content from one tool to the other. For example, relation Relationl2 of figure 3 enables consistency checking of model instances Viewpoint 1 model and Viewpoint2model; and transformation Transformation 12 enables transformation of appropriate subset of model instance Viewpoint 1model to Viewpoint2model and vice versa. Producer-consumer scenario where models produced by one tool are consumed by another tool either of the same or a different kind. The present invention has been illustrated with the help of drawings: There are total of 4 figures. Fig.l : Point-to-point integration of MDA tools. Fig 2: Proposed approach of MDA tool integration. Fig 3: Architecture pattern for the proposed MDA tool integration approach. Fig 4: A tool integration scenario. Advantages of the invention Some of the benefits of the proposed approach for integrating MDD tools are: 1. Difficult to construct point-to-point bridges between two interacting tools are replaced by a generic bridge between tool kinds 2. The approach provides for implementation of a generic framework to realize bridges between interacting tool kinds into which specific tools can be plugged in by implementing suitable transformations 3. The proposed generic framework is extensible and does not restrict the user to a priority defined tool kinds. Additional tool kinds can be easily plugged in. 4. The proposed approach can be realized using standard MDD technologies. We Claim: 1. A method and a toolset for MDD tool integration comprising the steps of: Abstracting the problem of integration of purpose-specific MDD tools as a problem of integration of kinds of MDD tools, Building integration bridges between different kinds as opposed to specific tools, Plugging in a specific MDD tool in the MDD integration bus by building a tool-specific adapter, and an adapter to the integration bus for every specific MDD tool where the tools create models corresponding to the viewpoints of interest where a viewpoint is specified as a metamodel with well-defined semantics and wellformedness constraints. 2. The system recited in claim 1, wherein the said integration of MDD tools is achieved in two steps comprising of integration of the viewpoints corresponding to their tool kinds and adaptation of a tool to its viewpoint. 3. The system recited in claim 1, wherein the said tool kind corresponds to a viewpoint for which there could be multiple tools from different vendors. 4. The system recited in claim 2, wherein the relationships between viewpoints are specified in terms of associations and constraints between the corresponding metamodels. 5. The system recited in claim 3, wherein metamodels are defined using a single standard meta modeling language and relationships between them are also specified using a single standard language. 6. The system recited in claim 2, wherein the said integration requirements between a tool and its tool kind can be specified in terms of the relationship between the corresponding metamodels, i.e. the tool-specific metamodel and the viewpoint-specific metamodel representing the tool kind.. 7. The system recited in claim 1, wherein the integration scenario further comprise of Peer-to-peer scenario where models have overlapping content and are simultaneously produced by two tools and Producer-consumer scenario where models produced by one tool are consumed by another tool either of the same or a different kind. Dated this 1st August, 2005 For Tata Consultancy Services Limited S. H. RAJADHYAKSHA Company Secretary Tata Research Development and Design Center Total No. of sheets 4 Sheet No. I k*m point-to-point bridges Fig. 1. Point-to-point integration of MDA tools Dated: 19th June, 2005 Tata Research Development and Design Center Total No. of sheets 4 Sheet No. 2 Point-to-point bridge integrating tool kinds Tool-specific adapter Tool-specific adapter Fig. 2. Proposed approach of MDA tool integration Dated: 1st August, 2005 Tata Research Development and Design Center Total No. of sheets 4 Sheet No. 3 Tata Research Development and Design Center Total No. of sheets 4 Sheet No. 4 Fig. 4. A tool integration scenario ABSTRACT A method and a toolset for MDD tool integration by way of Abstracting the problem of integration of purpose-specific MDD tools as a problem, of integration of kinds of MDD tools, Building integration bridges between different kinds as opposed to specific tools, Plugging in a specific MDD tool in the MDD integration bus by building a tool-specific adapter, and an adapter to the integration bus for every specific MDD tool where the tools create models corresponding to the viewpoints of interest where a viewpoint is specified as a metamodel with well-defined semantics and wellformedness constraints.

Documents:

1010-mum-2005-abstract.doc

1010-mum-2005-abstract.pdf

1010-mum-2005-cancelled pages (19-12-2007).pdf

1010-mum-2005-claim(ganted)-(19-12-2007).doc

1010-mum-2005-claims(granted)-(19-12-2007).pdf

1010-mum-2005-claims.doc

1010-mum-2005-claims.pdf

1010-mum-2005-correspondance-received-ver-080306.pdf

1010-mum-2005-correspondance-received-ver-220805.pdf

1010-mum-2005-correspondance-send.pdf

1010-mum-2005-correspondence (19-12-2007).pdf

1010-mum-2005-correspondence(ipo)-(04-02-2008).pdf

1010-mum-2005-description (complete).pdf

1010-mum-2005-drawing(19-12-2007).pdf

1010-mum-2005-form 1(25-08-2005).pdf

1010-mum-2005-form 18(08-03-2006).pdf

1010-mum-2005-form 2(ganted)-(19-12-2007).doc

1010-mum-2005-form 2(granted)-(19-12-2007).pdf

1010-mum-2005-form 26(01-08-2005).pdf

1010-mum-2005-form 3(01-08-2005).pdf

1010-mum-2005-form 9(08-03-2006).pdf

1010-mum-2005-form-1.pdf

1010-mum-2005-form-18.pdf

1010-mum-2005-form-2.doc

1010-mum-2005-form-2.pdf

1010-mum-2005-form-26.pdf

1010-mum-2005-form-3.pdf

1010-mum-2005-form-9.pdf

abstract1.jpg