This section describes the profile enforcement concept and the model validation concept. It is important to note that both concepts are applicable only on UML2 models designed in modeling environments supporting the UML2 plug-in. Eclipse based tools (e.g Rational Software Modeler) have capabilities to integrate the UML2 plug-in, therefore they have been selected as a baseline development environment.

Approaches to Profile Enforcement

In principle, two approaches to profile enforcement are possible.

The first approach relies on the fact that users are equipped with a modeling environment that allows both a UML2 model design and a profile definition with enforcement of the profile during the modeling phase, which means that users building a UML2 model are protected from modeling uncomplaining models. Such approach offers so far only OCLE, which is however compliant only with UML version 1.5.

In the second approach users define their model in a conventional UML2 modeling environment and then invoke a profile validation utility that verifies whether the built model conforms to the profile. Naturally an intermediate solution is also possible where validation is performed automatically in the background so that users are periodically warned about deviations from the profile during the designing process.

In general, the first approach is preferable, because users will be always guided to a model that conforms to a given profile. Unfortunately, this first approach is currently poorly supported within the Eclipse environment. Essentially, its adoption could be done in one of two ways. One way would be to build a new UML2 meta-model on top of EMF but this would force users to operate within the bare EMF environment and to give up the UML2 environment altogether. The second way would be modify the UML2 editor to enforce the profile. This however would be difficult to do because the UML2 editor is not designed to be modified in this way. In both cases, the profile enforcement software would be dependent on a non-standardized interface to the UML2 plug-in and would therefore be unlikely to work with future releases of the plug-in.

The first approach will only become viable when the UML2 plug-in explicitly offers facilities for users to define their own meta-model. As already sketched out, currently, the plug-in already offers a “profile definition” support. This support however is inadequate as it is limited only to the definition of stereotypes, tags and constraints.

Hence, at the time of writing, the second approach is regarded as the most promising from a practical point of view. This is the approach that was selected for the FW Profile. Its implementation is described in the next section.

The Selected Approach to Profile Enforcement

The UML2 plug-in offers a default model validation facility whereby users can ask for model validation at any moment during the model development process. The default validator check for compliance with the standard UML2 meta-model. The validation process is designed to be extensible and to allow users to define their own additional validation rules.

The extension of the default validation process is done as follows. The default UML2 validation process is encapsulated in a single Java class, the UML2Validator. For a new UML2 profile, a new validator class should be constructed in such a way that first calls the default validator and then checks compliance with the profile-specific constraints. The new validator class is built as an extension of class UML2Validator. This makes it possible to reuse the default validation process and it will allow to easily migrate to new versions of the UML2 plug-in. The proposed extension process is illustrated in following figure.

Note that the profile validator class is built automatically by processing the definition of the profile stereotypes, tagged values and constraints. The language used to express the constraints has been described in the Model Profiling section and the process through which the validator is implemented, in reality is automatically generated, is described in detail in the following section.

Implementation Details of the Profile Enforcement and the Model Validator

Since the selected modeling tool is Eclipse based using support of the UML2 plug-in, there is only one option how to enforce validation rules in to the modeling environment. It is through the use of a specialized plug-in, a profile plug-in, that extends the UML2 plug-in. The functionality of the profile plug-in is simple, it allows to register the profile validator (implementing posterior validation) within the UML2 plug-in and it offers a special menu to to activate and to run the validator.

The extended modeling environment that is obtained by adding the profile plug-in into the Eclipse based modeling tool offers to users advantages of the UML2 plug-in to edit and manipulate their model while and at the same time using a profile-specific validator that allows them to check model compliance with their imported profile.

Figure below schematically shows how the profile definition is transformed into the customized UML2 plug-in enforcing constraints by a posterior check performed by a custom model validator. It is worth noting that the validator generator, an XSL program, has been designed to be generic and therefore reusable without any modification. The process shown in the figure has been successfully implemented for the FW Profile, but in general it can be implemented for any UML2 profile.