Creating a simulation, part 2. the model

In the [first part](Creating a simulation, part 1. The meta model) of this tutorial, we created a meta-model file using the Eclipse Modeling Framework, thus we have represented it as an Ecore file. This file is based on meta-models provided by Zanshin, which represent the basic elements of GORE and of the ECA-based adaptation algorithm.

The meta-model declares classes that represent elements of the Meeting Scheduler model, shown once again in the figure below: goals, tasks, domain assumptions, softgoals, quality constraints, Awareness Requirements ( AwReqs ) and system parameters.

However, the meta-model does not indicate the relation between these elements. Information such as which is the root goal of the model, how is it decomposed, how are softgoals refined, which requirements are targeted by which AwReq, among others have not yet been represented.

The base meta-models of Zanshin already include the necessary attributes for this information to be represented once the meta-model is instantiated into an actual requirements model. In this part of the tutorial, we will show how to perform this instantiation using the tools provided by Eclipse. If you prefer doing things "by hand", you may want to skip to the end of this page.

Generating a customized editor for your system's model

In the [previous step](Creating a simulation, part 1. The meta model) of this tutorial, we have seen that Eclipse provides an Ecore editor that allows you to edit your meta-models using a tree-like dynamic structure and the IDE's Properties view. Once you have a meta-model, though, you can also ask Eclipse to generate a customized editor for models that comply to your meta-model. Such editors are similar to the Ecore editor, displaying your model's structure in a tree-like fashion and allowing you to edit it.

To do this, you have to create a new project for model generation, have Eclipse automatically generate plug-ins that provide an editor for your models and finally tell it to run another instance of itself with these plug-ins included. Being a somewhat complicated process, we have divided the instructions in parts:

(I) Creating the EMF project:

1. Click the menu File -> New -> Project and select EMF Project from the Eclipse Modeling Framework category. In the next step of the wizard, give any name you'd like to your project (e.g., SchedulerEMF);

2. At the Select a Model Importer step of the wizard, select Ecore model and, in the next step ( Ecore Import ), click the Browse Workspace button, choosing the Ecore file you have created for you system. The figure below shows the meta-model of the Meeting Scheduler being chosen from inside the zansin-simulations project;

3. At the last page ( Package Selection ), make sure the package related to your system is checked and click Finish;

At this point, you might get an error from Eclipse getting "resource not found" (404) errors. I think it might be trying to connect to the URIs specified as namespace of the Ecore packages, but they don't exist. If this happens, you can click OK, then Cancel the wizard, but the project should have been created and you should find it in your workspace.

(II) Generating the editor plug-ins:

1. Open the generator model file (the one with the .genmodel extension) that is inside the model folder in the newly created project;

2. Expand the root element of the generator model and set the base package of each EPackage included in the model. Use org.eeat.model for the LTL package and it.unitn.disi.zanshin.model for the Gore and Eca packages. You can use whatever package name you want for your own system (it will define the package in which classes will be generated in the next step). If you don't know what to use, use the same as the Gore and Eca packages;

3. Right-click the root element of the generator and choose the menu Generate All. Wait for Eclipse to finish the process and notice three new projects in your workspace, having the same name as your original EMF project, but with suffixes .edit, .editor and .tests. The src folder of your original EMF project should also now contain the generated classes;

4. Right-click the project with the .editor suffix (SchedulerEMF.editor in this example) and select the menu Run As -> Eclipse Application. Wait for Eclipse to launch a new instance of itself. This new instance will contain a customized editor for your models, based on the supplied meta-model;

At this point there is a problem. Although it looks like Eclipse launched the editor properly, there is a conflict between the meta-models included in the EMF project and the original ones included in Zanshin's core bundle. Moreover, since we have included the core bundle in Eclipse itself in the [first part](Creating a simulation, part 1. The meta model) of the tutorial, Eclipse loads it, together with its dependencies, and attempts to put Zanshin in operations, which at this point doesn't work. The solution is to customize the launch configuration, removing Zanshin from it, which will be done next.

(III) Fixing the editor's launch configuration:

1. Click on the menu Run -> Run Configurations;

2. At the left-hand side of the dialog, locate the item named Eclipse Application, under a category with the same name. Click on it to select it;

3. At the right-hand side of the dialog, switch the the Plug-ins tab and change the value of the Launch with drop-down menu to plug-ins selected below only;

4. In the list of plug-ins that shows up below, make sure all plug-ins from Target platform are checked and that only plug-ins related to the EMF project (in our case, SchedulerEMF, SchedulerEMF.edit, SchedulerEMF.editor, SchedulerEMF.tests) are checked under Workspace. If any Zanshin bundle is checked, uncheck them;

5. Click Apply, then Run. The new Eclipse instance with the customized editor should now run without problems.

(IV) Create the model in the customized editor:

1. In the new instance, create a new generic project by clicking the menu File -> New -> Project... and selecting the Project item inside the General category. Follow the wizard and give your generic project any name you want (e.g., SchedulerModel). Notice (and memorize) the location of this Eclipse instance's workspace. It should be something like <your-original-workspace/runtime-EclipseApplication. After you're done editing your model, you should copy it from your generic project inside this instance's workspace into the zanshin-simulations project in the original Eclipse's workspace;

2. Right-click your new project and choose New -> Other.... Expand the Example EMF Model Creation Wizards to find different types of models inside: Eca Model, Gore Model, LTL Model and your system's model. In the case of the Meeting Scheduler, there's a Scheduler Model option there. Choose the option related to your system and click Next >;

3. In the next page of the wizard, give your model a name, preserving the original extension, which relates to your target system (in our example, this extension is .scheduler). By default, we name the models in our simulations model (so, again, in our example, we have model.scheduler). Click Next >;

4. In the Model Object field, select the item Goal Model. This item represents the class in your meta-model that extends the GoalModel class in the gore package (no matter the name you gave to it, the Model Object field will display Goal Model). Click Finish.

The image below shows the new Eclipse instance with a customized editor for requirement models of the Meeting Scheduler. The current model in the editor area, as you can see, is empty. Its source code is displayed next, showing that its root element is a SchedulerGoalModel, defined in the Meeting Scheduler's meta-model.

<?xml version="1.0" encoding="UTF-8"?>
<scheduler:SchedulerGoalModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:scheduler="http://disi.unitn.it/zanshin/1.0/scheduler"/>

Defining the goal graph

The first step in creating a requirements model is representing the goal graph, i.e., the root goal and its refinements towards leaf-level tasks. For the Meeting Scheduler, the root goal is Schedule meetings, which was represented in the meta-model as the class G_SchedMeet. To set it as the root goal of the model we've just created, right-click the Goal Model element and choose the menu New Child -> GSched Meet (in your case, replace GSched Meet with the class that corresponds to your root goal). The figure below shows this selection.

Refining goals follows the same process of right-clicking the element and choosing the appropriate child from the New Child menu. This menu will show not only your system's specific elements (defined in the meta-model that you created) but also Zanshin generic elements (defined in the base meta-models). However, you should not use the base elements, only your own.

Goals are by default AND-refined. The refinement type is shown in the customized editor next to the goal's name and can be changed by selecting the goal, going to Eclipse's Properties view (if not showing, use the Windows -> Show View menu) and changing the value of the Refinement Type property. The figure below shows the change being made for the Collect timetables goal of the Meeting Scheduler.

Continue adding children and changing the refinement type until you have your system's basic goal tree. The figure below shows the result for the Meeting Scheduler and its source code can be seen below the figure. Next, we complete the base model with softgoals and quality constraints.

<?xml version="1.0" encoding="UTF-8"?>
<scheduler:SchedulerGoalModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:scheduler="http://disi.unitn.it/zanshin/1.0/scheduler">
  <rootGoal xsi:type="scheduler:G_SchedMeet">
    <children xsi:type="scheduler:T_CharactMeet"/>
    <children xsi:type="scheduler:G_CollectTime" refinementType="or">
      <children xsi:type="scheduler:T_CallPartic"/>
      <children xsi:type="scheduler:T_EmailPartic"/>
      <children xsi:type="scheduler:G_CollectAuto">
        <children xsi:type="scheduler:D_ParticUseCal"/>
        <children xsi:type="scheduler:T_CollectCal"/>
      </children>
    </children>
    <children xsi:type="scheduler:G_FindRoom" refinementType="or">
      <children xsi:type="scheduler:G_UseLocal">
        <children xsi:type="scheduler:G_FindLocal" refinementType="or">
          <children xsi:type="scheduler:T_GetSuggest"/>
          <children xsi:type="scheduler:T_ListAvail"/>
        </children>
        <children xsi:type="scheduler:D_LocalAvail"/>
        <children xsi:type="scheduler:G_BookRoom" refinementType="or">
          <children xsi:type="scheduler:T_UseAvail"/>
          <children xsi:type="scheduler:T_CancelLess"/>
        </children>
      </children>
      <children xsi:type="scheduler:T_CallPartner"/>
      <children xsi:type="scheduler:T_CallHotel"/>
    </children>
    <children xsi:type="scheduler:G_ChooseSched" refinementType="or">
      <children xsi:type="scheduler:T_SchedManual"/>
      <children xsi:type="scheduler:T_SchedSystem"/>
    </children>
    <children xsi:type="scheduler:G_ManageMeet" refinementType="or">
      <children xsi:type="scheduler:T_CancelMeet"/>
      <children xsi:type="scheduler:T_CancelMeet"/>
    </children>
  </rootGoal>
</scheduler:SchedulerGoalModel>

Adding softgoals and quality constraints

Softgoals are added to the model just like any other goal: as the child of an existing goal already in the model. Although in the figure at the beginning of the page the Meeting Scheduler's softgoals are floating around the model, disconnected from any other element but their quality constraints, in the EMF model they will be added as children of the root goal.

Another difference is the refinement relation between softgoals and their quality constraints: you'd expect this to be the same parent-child refinement relation that is used among goals or between goals and tasks, but in the base meta-models it hasn't been implemented like this. In the future, we plan to fix the base meta-models to behave as described in Section 2.1.3 (page 32) of Vítor's thesis.

Therefore, add all your softgoals and quality constraints directly as children of your root goal. Then, select each of your quality constraints, one at a time, and change the Softgoal attribute in the Properties view to point to the appropriate softgoal. Below, we show the result of adding softgoal and quality constraints to the Meeting Scheduler's model. The remainder of the goal tree is omitted, replaced by a comment with points of ellipsis <!-- ... -->.

<?xml version="1.0" encoding="UTF-8"?>
<scheduler:SchedulerGoalModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:scheduler="http://disi.unitn.it/zanshin/1.0/scheduler">
  <rootGoal xsi:type="scheduler:G_SchedMeet">
    
    <!-- ... -->
    
    <children xsi:type="scheduler:S_LowCost" constraints="//@rootGoal/@children.8"/>
    <children xsi:type="scheduler:S_GoodPartic" constraints="//@rootGoal/@children.9"/>
    <children xsi:type="scheduler:S_FastSched" constraints="//@rootGoal/@children.10"/>
    <children xsi:type="scheduler:Q_CostLess100" softgoal="//@rootGoal/@children.5"/>
    <children xsi:type="scheduler:Q_Min90pctPart" softgoal="//@rootGoal/@children.6"/>
    <children xsi:type="scheduler:Q_Sched1Day" softgoal="//@rootGoal/@children.7"/>
  </rootGoal>
</scheduler:SchedulerGoalModel>

Notice how EMF references other parts of the file: the quality constraint Q_CostLess100 refers to softgoal //@rootGoal/@children.5 which means "the 6th children tag (count starts from 0) under the rootGoal tag which is directly under the root of the XML file". If you go back to the <rootGoal /> tag and check the 6th <children /> tag directly under it, you will see that it indeed represents the softgoal S_LowCost, to which this constraint refers in the model. In the future, if you decide to write these models by hand, you should get used to this sort of XML reference.

Adding AwReqs for the chosen simulations

After the base goal graph has been defined, the next step is to add the Awareness Requirements. From this point onwards, we will focus only on two simulations that will be implemented in this tutorial. They are based on the full specification of the Meeting Scheduler provided in Table 4.3 (page 110) of Vítor's thesis, but have been slightly altered for simplification:

1. AR1 specifies that task Characterize Meeting should never fail. At runtime, this task fails and AR1's adaptation strategies are to retry the task in 5 seconds (applicable at most twice per user session) or, if that fails, abort;

2. AR4 is also a "never fail" AwReq, but targeting goal Find a suitable room. At runtime, one of its descendant leaf elements fails, propagating the failure also to the goal. AR4's adaptation strategy is to use Qualia (see Section 4.2, page 99, of Vítor's thesis) as a reconfiguration algorithm (parameters that can be changed will be provided later).

As with softgoals and quality constraints, AwReqs are added as children of the root goal. However, their configuration is a bit more complicated, as we need to specify:

• The requirement to which the AwReq refers (their target ): select the AwReq and, at the Properties view, change the Target attribute to point to one of the model's elements. For instance, in the Meeting Scheduler, AR1 points to TCaract Meet;

• Their resolution condition: the class that specifies how the ECA-based adaptation algorithm decides when an adaptation session has been resolved (i.e., previous adaptation actions in response to an AwReq failure have solved the problem). For this property, we usually refer to elements from the eca base meta-model, but users can provide their own customized implementations as well. To set a resolution condition, right-click the AwReq element in the model and select the appropriate condition from the New Child menu. For example, AR1 uses the Simple Resolution Condition, which deems the problem solved when the next evaluation of the AwReq comes successful;

• Their adaptation strategies: also from the eca base meta-model and also added as children of the AwReq elements, adaptation strategies specify what should be done when the AwReq fails. The ECA-based adaptation process will attempt them in the order they are provided in the model, so the order you add them is important. As with the resolution condition, strategies are added through the New Child pop-up menu of the appropriate AwReq element and their attributes should be set when required by the strategy. In the case of AR1 in the Meeting Scheduler, the Retry Strategy was added and its Time property was set to 5000 (milliseconds);

• The adaptation strategies' applicability condition: for each strategy of each AwReq, we should specify when they are applicable, otherwise the ECA-based adaptation process would always apply the first strategy of the list, never moving on to the next. To do it, right-click the corresponding strategy element and use the New Child menu to add the appropriate condition, setting its properties if necessary. Finalizing AR1's example, the Max Executions Per Session Applicability Condition was added under the Retry Strategy and its Max Executions property was set to 2.

Following the instructions above for the AR4 case as well, we have the following XML result for the Meeting Scheduler model. Notice that when using reconfiguration one must use the Reconfiguration Resolution Condition, the Reconfiguration Strategy (setting the Algorithm id property to qualia) and the Reconfiguration Applicability Condition. Both reconfiguration conditions allow you to specify other types of conditions as their children (in case you want to apply it a maximum of N times, for example) and default to the simple conditions.

<?xml version="1.0" encoding="UTF-8"?>
<scheduler:SchedulerGoalModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:it.unitn.disi.zanshin.model="http://disi.unitn.it/zanshin/1.0/eca" xmlns:scheduler="http://disi.unitn.it/zanshin/1.0/scheduler">
  <rootGoal xsi:type="scheduler:G_SchedMeet">
    
    <!-- ... -->
    <children xsi:type="scheduler:AR1" target="//@rootGoal/@children.0">
      <condition xsi:type="it.unitn.disi.zanshin.model:SimpleResolutionCondition"/>
      <strategies xsi:type="it.unitn.disi.zanshin.model:RetryStrategy" time="5000">
        <condition xsi:type="it.unitn.disi.zanshin.model:MaxExecutionsPerSessionApplicabilityCondition" maxExecutions="2"/>
      </strategies>
    </children>
    <children xsi:type="scheduler:AR4" target="//@rootGoal/@children.2">
      <condition xsi:type="it.unitn.disi.zanshin.model:ReconfigurationResolutionCondition"/>
      <strategies xsi:type="it.unitn.disi.zanshin.model:ReconfigurationStrategy" algorithmId="qualia">
        <condition xsi:type="it.unitn.disi.zanshin.model:ReconfigurationApplicabilityCondition"/>
      </strategies>
    </children>
  </rootGoal>
</scheduler:SchedulerGoalModel>

Notice also that the eca package has been added to the model, associated with the XML namespace it.unitn.disi.zanshin.model. You can later manually change this namespace to something easier (e.g., eca) if you'd like.

Finalizing with parameters and differential relations

In the Meeting Scheduler's second simulation, we'd like to use the reconfiguration strategy to adapt. According to the differential relations of the Meeting Scheduler (see Table 4.1, page 100, of Vítor's thesis), two parameters can help with indicator ( AwReq ) AR4: RfM (number of Rooms for Meetings) and VP2 (choice of child to satisfy goal Find a suitable room: local, partner or hotel). However, Zanshin's current implementation (v0.92) does not support enumerated parameters (and thus, Variation Points ). We will, therefore, add to the model only the RfM parameter and the differential relation that relates it to AR4.

Differently from other model elements so far, parameters and differential relations are added directly under the root of the model, i.e., the Goal Model element. Parameters, however, require that you first add a child (right-click the Goal Model element and use the New Child menu) of class Configuration, then you can add many parameters as children of this class. Be sure, however, to add instances of the parameter meta-classes that were defined in your own meta-model (e.g., for the Meeting Scheduler, CV_RfM) and not the generic Parameter class defined in the gore base meta-model.

Some parameters also require that you set their Unit and Value attributes. For example, parameter CV_RfM of the Meeting Scheduler starts with Value 5 and has as increment Unit the amount of 1 room. Moreover, in the case of numeric parameters (like RfM ), the Metric attribute should be changed from the default enumerated value to either integer or real (the former, in our case).

Relations, in their turn, can be added directly under Goal Model by selecting the Differential Relation element in the Goal Model's New Child pop-up menu. For each relation, you must specify the Indicator (an AwReq, e.g., AR4 ) and Parameter (e.g., CV_RfM) that are related. Also, check if default values gt (meaning greater than ) for Operator and 0.0 for Value are correct or need to be adjusted. Finally, if the relation contains lower and/or upper bounds, they should be specified in the appropriate attributes.

This finalizes our example and, thus, the final model for the Meeting Scheduler is provided in full below. Notice that the <relations /> tag corresponds to differential relation ∆(AR4/RfM)[0,10] > 0, which are based on the Meeting Scheduler's specification (see Table 4.1, page 100, of Vítor's thesis).

<?xml version="1.0" encoding="UTF-8"?>
<scheduler:SchedulerGoalModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:it.unitn.disi.zanshin.model="http://disi.unitn.it/zanshin/1.0/eca" xmlns:scheduler="http://disi.unitn.it/zanshin/1.0/scheduler">
  <rootGoal xsi:type="scheduler:G_SchedMeet">
    <children xsi:type="scheduler:T_CharactMeet"/>
    <children xsi:type="scheduler:G_CollectTime" refinementType="or">
      <children xsi:type="scheduler:T_CallPartic"/>
      <children xsi:type="scheduler:T_EmailPartic"/>
      <children xsi:type="scheduler:G_CollectAuto">
        <children xsi:type="scheduler:D_ParticUseCal"/>
        <children xsi:type="scheduler:T_CollectCal"/>
      </children>
    </children>
    <children xsi:type="scheduler:G_FindRoom" refinementType="or">
      <children xsi:type="scheduler:G_UseLocal">
        <children xsi:type="scheduler:G_FindLocal" refinementType="or">
          <children xsi:type="scheduler:T_GetSuggest"/>
          <children xsi:type="scheduler:T_ListAvail"/>
        </children>
        <children xsi:type="scheduler:D_LocalAvail"/>
        <children xsi:type="scheduler:G_BookRoom" refinementType="or">
          <children xsi:type="scheduler:T_UseAvail"/>
          <children xsi:type="scheduler:T_CancelLess"/>
        </children>
      </children>
      <children xsi:type="scheduler:T_CallPartner"/>
      <children xsi:type="scheduler:T_CallHotel"/>
    </children>
    <children xsi:type="scheduler:G_ChooseSched" refinementType="or">
      <children xsi:type="scheduler:T_SchedManual"/>
      <children xsi:type="scheduler:T_SchedSystem"/>
    </children>
    <children xsi:type="scheduler:G_ManageMeet" refinementType="or">
      <children xsi:type="scheduler:T_CancelMeet"/>
      <children xsi:type="scheduler:T_CancelMeet"/>
    </children>
    <children xsi:type="scheduler:S_LowCost" constraints="//@rootGoal/@children.8"/>
    <children xsi:type="scheduler:S_GoodPartic" constraints="//@rootGoal/@children.9"/>
    <children xsi:type="scheduler:S_FastSched" constraints="//@rootGoal/@children.10"/>
    <children xsi:type="scheduler:Q_CostLess100" softgoal="//@rootGoal/@children.5"/>
    <children xsi:type="scheduler:Q_Min90pctPart" softgoal="//@rootGoal/@children.6"/>
    <children xsi:type="scheduler:Q_Sched1Day" softgoal="//@rootGoal/@children.7"/>
    <children xsi:type="scheduler:AR1" target="//@rootGoal/@children.0">
      <condition xsi:type="it.unitn.disi.zanshin.model:SimpleResolutionCondition"/>
      <strategies xsi:type="it.unitn.disi.zanshin.model:RetryStrategy" time="5000">
        <condition xsi:type="it.unitn.disi.zanshin.model:MaxExecutionsPerSessionApplicabilityCondition" maxExecutions="2"/>
      </strategies>
    </children>
    <children xsi:type="scheduler:AR4" target="//@rootGoal/@children.2">
      <condition xsi:type="it.unitn.disi.zanshin.model:ReconfigurationResolutionCondition"/>
      <strategies xsi:type="it.unitn.disi.zanshin.model:ReconfigurationStrategy" algorithmId="qualia">
        <condition xsi:type="it.unitn.disi.zanshin.model:ReconfigurationApplicabilityCondition"/>
      </strategies>
    </children>
  </rootGoal>
  <configuration>
    <parameters xsi:type="scheduler:CV_RfM" unit="1" value="5" metric="integer"/>
  </configuration>
  <relations indicator="//@rootGoal/@children.12" parameter="//@configuration/@parameters.0" lowerBound="0" upperBound="10"/>
</scheduler:SchedulerGoalModel>

The model above is ready to be used in a Zanshin simulation. You can now quit the new Eclipse instance with the customized editor and return to your original Eclipse for RCP installation.

Writing the model "by hand"

As can be seen from the resulting model of the Meeting Scheduler case in the last listing above, the resulting model could also be done manually, without any support from Eclipse. Just write the XML file based on the meta-models (yours and Zanshin's), paying attention to the following details:

• The root tag of the file should refer to the class in your meta-model that extends the GoalModel class in the gore meta-model;

• In the root tag, define the appropriate namespaces: other than XMI and XSI namespaces, define one for your own classes (using the value of the nsURI property of the EPackage tag of your meta-model's XML, i.e., the .ecore file) and, if appropriate, one for the gore and eca packages (URIs are, respectively, http://disi.unitn.it/zanshin/1.0/gore and http://disi.unitn.it/zanshin/1.0/eca);

• Define goals, tasks, domain assumptions, softgoals, quality constraints and AwReqs in a tree-like structure, starting from a <rootGoal /> tag and descending using <children /> tags. Specify as xsi:type attributes the class of each requirement, using classes from your meta-model. Note that the softgoal--quality constraint relation is different (read "Adding softgoals and quality constraints" above for the explanation);

• AwReqs should specify their targets the same way quality constraints and softgoals relate to one another. Pay attention when writing links such as //@rootGoal/@children.0 as using a wrong number can cause errors that are difficult to debug;

• Specify adaptation strategies and conditions under the <children /> tags that refer to the AwReqs, remember to specify also their properties when adequate;

• Write parameters inside a <configuration /> tag directly under the root tag of the file, referring to your own parameter meta-classes and specifying their attributes when appropriate;

• Finally, write differential relations using <relations /> tags also directly under the root tag of the file, referring to an AwReq element as indicator, a parameter element as parameter and specifying other properties (such as lower and upper bound) when necessary.

Next: [create and run a simple Simulation class](Creating a simulation, part 3. A simple Simulation class)