Structuring a Model

How to Structure a Model

A model's structure is determined by how the elements are linked by relationships. Owner relationships for the elements are essential for this as the model's hierarchy is determined by them and they set that each model element must have precisely one owner, regardless of its other relationships. Profiles used in your model determine the structuring options of a concrete model structure. The configuration specifies e.g. whether an element can be created in a container, i.e. whether the container can own it.

Certain element types are available for structuring a model, in particular packages and components. Create defaults, which are modeled as a special dependency, are used to direct elements to a particular container on creation. You can create the best overview of the create defaults in the model using the appropriate component diagram.

Element	Icon Example	Use
System Model		System models define a software system, provide common profiles for their partial models and form their root. Innovator models can contain multiple system models if required.
Model		Submodels enable structuring at the top-most level within a system, e.g. in various areas of business or modeling phases.
Package		Packages are a structuring element without further semantic. They correspond to a folder in a file system. It is possible that packages only contain references so that you can create any number of compilations (e.g. for documentation).
Component		Components are a semantic grouping of elements which belong together and show an entity in their own right; often a software component.
Diagram		Diagrams are the essential structure element for modeling relationships between model elements. (Due to their exceptional position as a means for visualizing, they are offered separately and not as normal elements in the ribbon. This is why they do not appear in the Model Structure submenu.)
Create Default		In Innovator, create defaults are modeled as a special dependency between packages or components. They are used to redirect elements into another container (package or component) and thus to a particular owner upon creation.

You basically structure your model using packages and components; system and submodels are special packages. For packages and components, you can use the create default to redirect specific elements – on creation only – to other packages or components, and thus to a particular owner. In Innovator, create defaults are modeled as a special dependency.

You can e.g. structure your model by grouping its elements according to certain criteria and combining them in a respective package. You can specify the criteria which you structure your model by as desired. This means that you can e.g. sort elements according to their type, thereby combining all of a type's diagrams in one package. If you already want to display your model's architecture, you can also set up a package for various components from your system. Of course, any combinations of these approaches are also possible.

You can view the model's existing structure in the Model Contents tool window (Model Structure view).

The example shows the structure of a business model which has multiple subpackages, e.g. one for assigning processes, one for use cases etc.

When working with structure elements, the following properties must be taken into consideration:

• Hierarchical Structure
  Structure elements can be structured hierarchically. Each structure element can contain as many other structure elements as required.
• Model Root
  A model's topmost structure element - the model root - is automatically there. It contains the name of the current model and cannot be deleted.
• Identifying an Element
  Each model element has an owner. The element is identified by its path in the model structure, its name and its element type. An owner cannot have two elements with the same name and type (in spite of Universally Unique Identifier).
  This also applies for the structure element itself.
  

Mode of Operation for Create Defaults

Create defaults are used to redirect elements into another container and thus to a particular owner. The container for a new element is normally based on the selection. This means that e.g. the class diagram's container is always actually used as the class' container as standard when a new class is created in a class diagram.

It may be the case that you want to use another container. You can e.g. collect all primitive types in one container that the selection should choose, regardless of the container. Create defaults are used for this.

A create default is created between two packages or components. The Redirected Stereotype property is set for each create default. The is Default property can be used to set whether this redirected stereotype should be used as the default.

The evaluation differentiates between whether the stereotype of the element to be created is known or not. If you create an element directly using a menu item, then a create template for a particular stereotype is evaluated and the stereotype is known. However, there is also the case that an element is only indirectly created. If this is the case, the stereotype is not normally known.

Let us initially assume that the stereotype is known. Based on a selected element, a possible container is evaluated when a new element is created. The configuration then checks for this container whether the new element can be created in it. If this is the case, this container is used and any create default present will not take effect.

If the container cannot be used, then outflowing create defaults are searched for, starting from this container and working back to the root. The first create default that has the Redirected Stereotype property set for it or one of its super-stereotypes sets the container to be used by using its target element. It is sufficient to redirect the common super type if you want to redirect multiple stereotypes of one element type.

If the stereotype is not know, the is Default property is used. A create default is also looked for in this case starting at the selection's container in the direction of the root. The first create default which has the is Default property activated and a stereotype for the desired element type set is used. In this case, the create default initially provides the stereotype of the element to be created. The process for creating an element is then carried out using the known stereotype. i.e. the selection's container could theoretically be considered as the new element's container if this allows the stereotype as content. In this case, a create default does not necessarily take effect as container redirection, but first of all as stereotype allocation.

The container identified using the create default should permit elements with the selected stereotype as content. Otherwise this will lead to an error message when creating the element.

Changing the create defaults normally collides with the configuration on the modeling side of things; this then has an effect on the implemented intentions of the model. The configured owner relationships determine the permissible targets of a create default. The main aspect on the modeling side of things is to maintain storage transparency of directly or indirectly newly-created elements.