"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Model Management Use Cases

Related pages

Contents

Model Management Issues

Managing a domain model is much more that creating class definitions for concepts - it includes idenitying which parts of the domain model should be common within sub-domains and related domains, or reused patterns that have been proven elsewhere.

A domain model will evolve over time, through extension or correction, or harmonisation with related models. In fact, there are a range of model management issues that require systematic approaches,

High Level Use Cases

  • Import
  • Publish new
  • Update imported model
  • Publish new version

The versioning problem

A model (in UML) has a visible structure (package name and class name, and hidden object identifiers - GUIDS - that are used to glue the database of model components together - for example as object references in an XMI file). These references are created typically by generating diagrams or other user interactions, and stored as GUID references.

The problem is that creating a model with a class and package name with different GUIDs is quite feasible (and argualbly desirable) - but there is no connection to this model until the user makes the connections. Thus, it is possible to import the same model multiple times, or to create versions of the same model, but relationships will only exist between the objects the user has worked with.

So, it is hard to mantain versions of a model package - since all the relationships between another package and the original version or not retained by the new version - they still reference the original object GUIDs. If you edit the original model, you lose the original version.

One could save the original version with new GUIDs, at the cost of losing all the references to the original version. Or, one could clone the orginal and all referencing models, and update the GUIDS or either the new or original versions. This has problems in that it may not be possible to update original model versions, or locate referencing models and update them.

The basic Use Case required then, for versioning a model looks like it needs to support a decoupled process:
  1. Clone model to create identical model with new GUIDs for editing
  2. Edit to create new version
  3. Update client (dependent) models on a reference-by-reference basis to use new GUIDs for named objects, and identifying references broken by changes to new version

Step 3 may include versioning the client model, which is a recursive application of this process.

It should be possible to automate this process, having identified the artefacts for the models to be versioned. A registry model, with dependency information, may allow automation of the recursive process, identifying all dependent packages and "drafting" or publishing new versions of all dependent packages.

Managing MDA artefacts

Importing Legacy artefacts

 
Topic revision: r2 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).