InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for Graph-Based Model-Driven Modeling Tool Development

IP.com Disclosure Number: IPCOM000200043D
Publication Date: 2010-Sep-24
Document File: 2 page(s) / 24K

Publishing Venue

The IP.com Prior Art Database


The invention addresses how to reduce the SOA development tooling development cost. Rather than developing a tooling environment by embedded the domain-specific details into the tooling environment, this solution externalize such domain-specific details into configuration files. We use the graph theory to define the meta-model of SOA model as combination of a placement meta-graph and a relationship meta-graph. The configuration files are used to describe the two meta-graphs. The tooling environment at runtime will parse the configuration files and generate the context-aware tooling environment. In high level, the innovation involves following steps: · Defining the elements of the meta model · Defining the placement graph for the meta model · Defining the relationship graph for the meta model · Representing the placement graph and the relationship graph into implementation specific configuration files · Generating the tool UI from the model/configuration files

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Method for Graph-Based Model-Driven Modeling Tool Development

We provide such coding-free enablement framework through first map the SOA meta-model into two types of meta-graphs. The first meta-graph, placement graph, specifies the location of design elements in a tree structure. This type of meta-graph is used to define the user interface (UI) actions to support the creation and validation of design elements. The second meta-graph, relationship graph, is used to capture the relationships among various design elements. This type of meta-graph is used to dictate the UI actions for creating relationships, and it provides a base for completeness and impact analysis for an SOA model. This abstraction formalizes the SOA modeling logic and semantics, and also guides the implementation of an extensible and customizable tooling environment.

Here is the advantage of applying this method into the tooling environment development. We can dramatically reduce the programming code development, and enhance the code reusing. We shift the challenge from the tooling enabling from programming language (say Java) coding to develop the model itself.

Meta Models Definitions

We abstract the legitimate physical locations of design elements as a placement tree (a meta-graph). Combined with cardinality constraints, such a graph can be used for preliminary validity checking of a model when design elements are created. In addition, a relationship meta-graph is used to specify relationships among the design elements. Such relationships could be logical or physical depending on the nature of the SOA model. The relationship meta-graph provides a preliminary check to enforce constraints on the valid relationships among the design elements. A design model is then defined as a union of two instance graphs (specifying the locations and relationships of design elements) with semantic meaning, annotated by the two meta-graphs described above.

Step 1: Model Placement Abstraction

Both for modeling consistency and to enforce correctness, it is important to constrain the valid locations of design elements within an SOA model. We represent these constraints using a placement meta-model, which is a tree whose structure mirrors the desired package structure of the SOA model (e.g. a modeling template). There are two types of nodes in the placement meta-model - a) container-type nodes which map to fixed entities in the SOA model, and b) stereotype nodes which correspond to design elements created by a designer/architect when a model is built. The edges of placement tree model the containment relationships of design element. Each edge includes a cardinality property which defines the number of design elements allowed for a package or a parent design element.

Step 2: Placement Design Model Abstraction
We view a placement design model as an...