JeeWiz Architect's Guide - Customizing Modelling Profiles


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 3. JeeWiz Input

3.4 Customizing Modelling Profiles

Most modelling tools, including Rational Rose and Rational Software Modeller (RSM), allow UML profiles to be defined for particular modelling domains.

For each modelling tool supported, JeeWiz creates a profile - the official UML term for a set of modelling extensions. This allows model elements - components, classes, attributes, associations and association ends - to be given profiled stereotypes (e.g. <<entity>>, <<attribute>>, <<data-view-end>>). When a stereotype is attached to a modelling element, it has additional properties ('tagged values') defined on it that can be set directly in the modelling tool.

Typically these additional properties come from the JeeWiz meta-models, but JeeWiz also provides a feature to add or remove stereotypes and properties.

3.4.1	Building Profiles
3.4.2	Filter Includes
3.4.3	Filter Additions

3.4.1 Building Profiles

Features are added or removed when the profile is built for a particular modelling tool. The building of the profile is done in the designTransform directory. For example for RSM see

jeewiz/designTransforms/RsmRsa/jw2ScreenMMPlugin

Currently the feature described here only applies to RSM but the architect will be used for future modelling tools.

The build job in this directory creates the RSM plugin, which is placed in

jeewiz/designTransforms/RsmRsa/jw2ScreenMMPlugin/output/RsmRsaMetaModel.epx

This page describes how you can adapt the generated profile by adding and removing stereotypes and properties. This is done via a filter file. For example, the RSM filter file is located at

jeewiz/designTransforms/RsmRsa/jw2ScreenMMPlugin/filter.xml

If you change this file and run 'ant' in the jw2ScreenMMPlugin directory, it will change the generated profile.

Because the profile generation uses both the meta-model information and the filter, the profile should be rebuilt when either of these changes.

3.4.2 Filter Includes

Not all properties are relevant to modellers, many being used internally within transforms rather than as inputs. To restrict the properties shown through the extensions, the design transform may use a filter. If this is the case the filter will control which classes are shown and which properties and lists are supported for them.

In the filter XML, stereotypes are created via "meta-class" elements - this is what they are called in the meta-modelling system. Each meta-class element supports an attribute called "property-include" giving a list of the properties in the meta-class which are to appear in the generated profile. It also supports an attribute called "list-include", which allows (comma separated) lists of values to be entered in the modelling tool for each of the lists in the meta-class. A common example of the latter is the style list.

<meta-class    name="entity
               uml-type="Class"
               property-include="container, generateDataViewForEntity,
                                 generateMaintenanceSession,
                                 generateMaintenancePages,
                                 generateTableSchema, screenPosition,
                                 tableName, dataSource, userNameBase,
                                 versionControl, lockOnRead"
               list-include="style, rolesReadonly, rolesAllowed, rolesBlocked"
               >
</meta-class>

3.4.3 Filter Additions

As well as showing properties and list properties from the class, it is possible to add properties and lists not in the meta-model. These can be specified by nesting a property or list definition within an add element. Values may get passed back to the meta-class base hashmap which can then be used as String values even though they don't appear in the meta-class specification.

<meta-class     name="application"
                uml-type="Component"
                property-include=". . . "
                list-include=". . . "
                >
      <add>
         <property   name ="splashImage"
                     type ="String"
                     />
         <property   name ="webAppName"
                     type ="String"
                     />
      </add>
</meta-class>

Alternatively added values may be massaged in the modelling screen to JeeWiz transform and turned into something else. For example in rsa/rsm constraints are added as properties on fields, etc., whereas the meta-model sees them as a meta-classes in their own right. This is due to the difficulty in manipulating the requisite number of property levels in rsm. So they are added as properties on the field in the extension, and in the reverse transform the properties are turned back into constraints nested under the field.

If an object is identified (using an id attribute) it can be copied into a meta-class. (See the following section for details.) Properties and lists that are added to multiple classes are typically identified once and copied using a copy element within the add.

By aliasing a meta-class, the alias stereotype becomes available to the modelling tool as well as the standard name.