![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEuxCEyWSGNjZkCPmQFDvpHlzLVGMi1aiVTYwHmxL9IjLz_nChIUuaEFE_kto0NKa7VHTheT_ueRrURN8aTvVhn3dLEYaz-dgof-XFfiGhhwrDOkPxibS45ANbLeSPIs3qiahV-IkrFEE/s320/gaphor_checkmetamodel_dialog.png)
When the checkmetamodel plugin validates the UML model, there are three functions involved. These functions are check_associations(), check_association_ends(), and check_association_end_subsets(). The check_association_end_subsets() function is important when validating association ends. It is the only validation that actually takes place on associations. The check_associations() and check_association_ends() functions exist for infrastructure purposes. If new functionality were to be added to Gaphor association or Gaphor association end checking, it would be placed in one of these functions. As the same suggests, the check_association_end_subsets() function will make sure that any association ends that are subsets of the opposite association end are consistent with one another. There are two basic tests to make this happen. First, the plugin will make sure that a given association end that is a subset of the opposite association end, contains names that actually exist in the opposite set. There can't be a subset property which contains elements that do not exist in the referenced set. Next, all multiplicity upper bounds in the subset need to be consistent with the upper bounds of the opposite set. This will ensure a multiplicity consistency amongst association end subsets.
With Gaphor, these meta model consistency checks are especially important because the meta model is loaded into Gaphor as any other UML model would be. If the core Gaphor UML meta model fails, there isn't much hope for any models created by users. The checkmetamodel plugin also offers potential for adding additional checking functionality.
Hi Adam,
ReplyDeleteThanks for the outline of the checkmetamodel plugin. This plugin has been written as aid when extending the meta model (e.g. when implementing new functionality). It has been written with the functionality of the code generator (the one that creates gaphor/UML/uml2.py out of gaphor/UML/uml2.gaphor) in mind.
The code generator does quite some stuff to figure out what to write based on the model. It relies on the descriptors (properties) defined in gaphor/UML/properties.py, since those are the classes that provide the behaviour for the meta model (such as sending events on changes).
There is also a uml2.override file, which is used to fill in the gaps (like derived attributes).
Regards,
Arjan