Tutorial/Model Generator

This page describes the eclipse plugin ModelGenerator. The ModelGenerator is a generator which modifies entered uml model files using special algorithms called Generators. Technically it is a recursive algorithm walking through the whole model tree for each generator. So it can take some time using this plugin on big model files. Warning!! - always backup your model files before using the generator. The generator overwrites your model, so we give no guarantee that there will be always no damage on your model.

Usage of the ModelGenerator
Please always save your diagram before using the genrator to avoid possible loss of data!
To start the ModelGenerator you have to right click an uml model file (*.uml) in your eclipse IDE. In the now appearing context menue use the entry Model Generator (which has a symbol with a G on the left side - have a look at picture 1). You will now see a new inner window in your eclipse IDE which will show you the ModelGenerators current state as a view of log entries. You can pause and stop and resume the running generation process by using the buttons on the right side of this window.

Picture 1 : Start the ModelGenerator

Picture 2 : ModelGenerator in action

After succeasful Generation of the model elements, the you have to refresh the UML editor view (close and open again).


<<Domain>> stereotypes, <<connection>> stereotypes and <<generated>> stereotypes were loaded at the startup of the generation run from the ProblemFrames profile. So new added sterotypes have not to be added into the code of the model generator plugin.


Creates abbreviations for domains not having one. For example the domain StaffMember will get the abbreviation SM. The generator uses camelcase-like the upper case symbols of a domains name to create the abbreviation. If already another domain has the new generated abbreviation it will not give a abbreviation to the current domain. The generator will log that it does not create the abbreviation because it is used by another one. The user now has to manually create a abbreviation.


This generator creates interface classes for the lists of phenomenons between two domains. All phenomenons will be used to create methods on the corresponding interface. It will assign the phenomenons to the domain if it finds the correct abbreviation in the list of the phenomenons. Names of these interface classes will be also generated using the lists of phenomenons belonging to the domains. The interface classes will be connected to the domains by using <<controls>> and <<observes>> stereotypes.


We have two domains. The Machine and the User. The generator analyses both and notices that the machine has the abbreviation M and the user the abbreviation U. So it also analyses the phenomenons between the domains now. The phenomenons are "M!{fu,bar} U!{bu,xu}". So the generator knows that the interface class of the machine gets the methods fu and bar because these belong to M!. It also knows that the interface class for the user will get bu and xu. The interface class of the machine will get the name "M!{fu,bar}" and the interface class for the user will get the name "U!{bu,xu}".
ATM Example:

It is possible to use phenomena lists as shown in the following figure:

From this diagram, the model generator generates the following interface.


This generator is a really simple one. It will delete all model elements which have a <<generated_...>> stereotype. It will not delete <<generated_interface>> Interfaces which have a <<concretizes>> or <<refines>> dependency pointing at these and it will also not delete interfaces which are already used as types.


The IsPart Generator creates associations with <<isPart>> stereotype for each model element and connect it to the diagram (Package) where it is used. This is needed for some validation steps using the OCLValidator. Some elements, like classes for example, which are physically located in a package of an UML model, but also is used in another package, gains a <<isPart>> only, if there exists relations between the class and other classes. The relations (for example dependencies or associations) are always located in the package where they are drawn. So the Generator uses this knowledge to create an <<isPart>> dependeny for those classes.


This generator is a helper generator. It walks through the whole model and saves all used abbreviations, interface classes and dependencies. The result of this generator is given to the AddDomainAbbrevationsGenerator so that it will not create abbreviations twice. It is also given to the CreateInterfacesGenerator so that it will not create dependencies (and their operations) twice.