Application Cases

Use

The following uses examples to explain the application cases that were covered by the model data transfer tool ( MDTT). The functions are only active if the preconditions for the application case are met.

Mapping Between New and Old Model Roles

Example 1

Create mapping between a new model role ROL_NEW and an old model role ROL_OLD.

  • Preconditions

    A new role model ROL_NEW is available that was created in the view cluster. There is no mapping for ROL_NEW. A ROL_OLD model role is available in the old model data.

  • Procedure:

    1. The 'role types' tabstrip is selected in the MDTT. ROL_NEW is selected either by double-clicking or by selecting 'include in mapping' from the list of new model roles. The information on the roles then appears in the mapping view. Step 2: In the same way, ROL is transferred from the list of old model roles to the mapping view.

    2. In the same way, ROL_OLD is transferred from the list of old model roles to the mapping view. The order of step 1 and step 2 has no significance.

    3. By using the 'transfer mapping' pushbutton, the mapping is transferred to the local memory of the MDTT and can be considered when mapping or generating model relationships.

  • Subsequent conditions:

    The mapping is available in the local memory of the MDTT and is marked as 'New'. ROL_NEW appears next to ROL_OLD in the list of new model roles and is removed from the list of old model roles at the same time. The object types assigned to new object roles are extended by the object types assigned to the old model roles.

Example 2

Revoke mapping between new model role ROL_NEW and old model role ROL_OLD.

  • Preconditions

    A mapping between ROL_NEW and ROL_OLD exists in the local memory MDTT and there is no mapping between model relationships where the mapping between ROL_NEW and ROL_OLD is a prerequisite. The new model role must also not appear in any generated relationship type.

  • Procedure:

    1. The 'role types' tabstrip is selected in the MDTT. Select the entry from the list of the new model roles. The 'Cancel Mapping' button is then set to active.

    2. Press 'Cancel Mapping'.

  • Subsequent conditions:

    Mapping is removed from the local memory of MDTT. The lists with the new and old model roles are updated.

Generation of New Model Relationships

Example 1

Generation of new model relationship from the old model relationship ROL_OLD.

  • Preconditions:

    A ROL_OLD model relationship is available in the old model data.

  • Procedure:

    1. ROL_OLD has been selected from the list of old model relationships.

    2. Press "Generate New Model Relationship".

  • Subsequent conditions:

    The generated new model relationship ROL_OLD is transferred to the local memory MDTT and marked as new. It appears in the list of new model roles and is now included in the generation of model relationships. The old model role is removed from the relevant list. If a model role already exists with the name ROL_OLD before generation, the suffix '_NEW' is atatched to the name of the generated model role, that is, ROL_OLD_NEW. Object types that were assigned to the old model role are automatically assigned to the new model role.

Example 2

Remove generated model role ROL_OLD.

  • Preconditions

    A ROL_OLD model relationship is available in the new model data. It is marked internally as generated.

  • Procedure:

    1. Select ROL_OLD.

    2. Press "Remove Generated Model Role".

  • Subsequent conditions:

    The generated role is removed and the lists are updated.

Mapping Between New and Old Model Relationships

Example 1

Create mapping between new model relationship REL_NEW and old model relationship REL_OLD.

  • Preconditions

    A new model relationship REL_NEW is available that was created in the view cluster. There is no mapping for REL_NEW. A REL_OLD model relationship is available in the old model data. There are not role mappings or generated roles that affect the mapping. This is the case if generated or mapped new model roles exist for the old model roles of REL_OLD which are different from the relevant model roles of REL_NEW.

  • Procedure:

    1. The 'Relationship Types' tab is selected in the MDTT. REL_NEW is selected either by double-clicking or by selecting 'include in mapping' from the list of new model relationships. The information on the relationships then appears in the mapping view.

    2. In the same way, REL_OLD is transferred from the list of old model relationships to the mapping view. The order of step 1 and step 2 has no significance.

    3. The mapping is started by pressing the "Accept Mapping" button. If not mappings or generated new model roles exist for one or both role types from REL_OLD, the user is asked if a mapping is to be created for the missing roles automatically. If the user does not answer with "Yes", the process is canceled. This also applies if role inconsistencies exist.

  • Subsequent conditions:

    If step 3 was completed successfully, the new mapping can be seen in the list of the new model relationships and the old model relationship is removed from the relevant list. The mapping is flagged as "New" in the memory of MDTT. If role mappings were also created in step 3, the subsequent conditions from Example 1 in 3.1 also apply for each mapping.

Example 2

Cancel mapping between new model relationship REL_NEW and old model relationship REL_OLD.

  • Preconditions

    A mapping between REL_NEW and REL_OLD exists in the local memory of MDTT. The procedure and subsequent conditions are the same as those in Example 2 in 3.1. No role mappings or generated model roles are involved in this.

Generation of New Model Relationships

Example 1

Generation of new model relationship from the old model relationship REL_OLD.

  • Preconditions

    A REL_OLD model relationship is available in the old model data.

  • Procedure:

    1. The 'Relationship Types' tab is selected in the MDTT. REL_OLD has been selected from the list of old model relationships.

    2. Press "Generate New Model Relationship".

    3. The mapping is started by pressing the "Accept Mapping" button. If not mappings or generated new model roles exist for one or both role types from REL_OLD, the user is asked if a mapping is to be created for the missing roles automatically. If the user does not answer with " Yes", the process is canceled. This also applies if role inconsistencies exist.

  • Subsequent conditions:

    If step 3 was completed successfully, the generated relationship can be seen in the list of the new model relationships and the old model relationship is removed from the relevant list. The generated relationship is flagged as "New" in the memory of MDTT. If a model relationship already exists with the name REL_OLD before generation, the suffix '_NEW' is attached to the name of the generated model relationship, that is, REL_OLD_NEW. If role generations were also executed in step 3, the subsequent conditions from Example 1 in 3.2 also apply for each generation. If attributes exist for the old relationshop type, a warning is displayed that no autoamtic migration can be executed for relationship attributes. A note is also displayed that states that the name of the runtime table has to be manually entered in the viewcluster for generated model relationships.

Example 2

Delete generated model relationship REL_NEW.

  • A generated model relationship exists between REL_NEW and REL_OLD in the local memory of MDTT. The procedure and subsequent conditions are the same as those in Example 2 in 3.2. No role mappings or generated model roles are involved in this.

Saving the Results

After the mappings or generations have been performed, these can be transferred by selecting 'Save' in the view cluster. Object types that might be available are also considered when role mappings and generated roles are involved. When mapping takes place, these are added to the object types of the new roles (so far unavailable) and when generations take place, they are completely transferred. As soon as an API is available for BOR migration, the business classes are entered automatically, if a BOR object has been migrated.