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

A Solution for Appling Naming Change in MDA Process

IP.com Disclosure Number: IPCOM000201671D
Publication Date: 2010-Nov-18
Document File: 6 page(s) / 152K

Publishing Venue

The IP.com Prior Art Database


This article introduces a solution for renaming in MDA development process. This solution is a combination of a) model template definition b) naming profile definition, and c) a process for applying naming profile into UML model, which can be implemented as tools. To use the solution in MDA process, firstly the user selects a model template as the start point according to the industry and domain; secondly, the user chooses a naming profile and applies it on the selected model to change the element name; after this step, optinally, the user may modify the element name manually for additional cusomization; at last, the user runs code generation using MDA tool. Model template and profile definition are the foundation of model renaming. The process (implemented as toolkit) helps user to apply the domain vocabulary to model template and work out the specific model with user’s naming preference. In general, this solution helps users to reduce time for adoption of existing model template, as well, reduce the posibile human error during the naming modificiation. Detailed advantages are: 1) Model template reusability is enhanced. 2) This facility automatically apply name changes to the related model elements based on naming rules and the domain vocabulary. It improves the productivity and reduce the posibility of mistakes. 3) This solution provides a mechanism to represent the naming constraints at concept level. These naming constraints can be reused in various projects. 4) When renaming model elements, naming validation is possible. Notice that, this solutionis not designed to replace the current MDA tool or any existing improvement solutions. It is an option to fulfill the requirements for rapid MDA approach and provide benefits with that. It will be useful for architect, and helpful for software reusability improvements, as well as other areas.

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

Page 01 of 6

A Solution for Appling Naming Change in MDA Process

Model Driven Architecture (MDA) is a methodology of designing, developing applications, and documenting specifications. It uses the platform-independent models as the major forms of description of requirements and design, and then use the code generation technologies to translate the models into source code or deployable components. The model is often described in Unified Modeling Language (UML)

which is an industry standard

(like RSA), RSA provides limited validation points, but could not validate naming consistence of UML model, so problem #4

As described above, none of the existing solution resolves all the problems gracefully which is the intention of the invention where additional benefits will be offered.

This article introduces a solution for renaming in MDA development process. This solution is a combination of a) model template definition b) naming

modeling language for specifying, visualizing, constructing, and documenting the artifacts of software systems.

In practice, a typical MDA process has the following steps:
1) Requirements analysis: gather requirements via communications with customer and translate business requirements to technical requirements.
2) Modeling system with UML: design the models from the business and technical requirements, each model is representing by UML.
3) Code generation: use tools to generate codes / artifacts based on UML model.
4) Code customization: optionally but often, if UML model could not fully expressed business context, the developers have to modify the codes generated fill in the missing business logics.

There are several problems people are facing for current MDA approach:
1) UML model is hard to be reused from one project to another, even when their models are similar or same at the conceptual level. One of the reasons is that different projects may have different business context and different vocabulary. For generating the code that makes sense to the designers and developers, the naming of the model must correspond the vocabulary.
2) To resolve previous problem, the designers have to either re-create the model, or rename the model (both field names and value names). However, UML naming customization is not only time consuming, but also easy to make inconsistency issue, for there might be complex hidden inter-relationships between names among the models.
3) There's no standard and central mechanism to manage the naming constraints, as the constraints' rule may differ among various projects.
4) Since the models are modified on a case by case base, overtime the service team may accumulate many versions of the same conceptual model that based on different context and vocabularies with minor delta. It is hard to manage and maintain.

There are some existing solutions to solve parts of the problems:
1) Industry standard model (like IAA) has a kind of reusability, user could create own model by reference industry standard mode, but customi...