The algorithm for the translation

In Section 8.3 we presented a subnet pattern for each CSM meta-class. Some of these pat- terns were obtained by composing subnets, it was for example the case for the pattern of the Branch. To this end, we proposed that each place and transition of the subnet were la- beled, then the composition would be carried out by merging places and/or transitions with equal labels. By doing so, we actually converted the GSPN into a multi-labeled GSPN (ML- GSPN). The concept of merging subnets is conceptually easy to practice, and it was formal-

8.4. Tool development 131 ELEMENT_NODE tagName: "CSM" ELEMENT_NODE tagName: "Scenario" ELEMENT_NODE tagName: "Scenario" ELEMENT_NODE tagName: "Component" NodeList

childNodes _{parent parent} parent

ELEMENT_NODE tagName: "Step" ELEMENT_NODE tagName: "Start" ELEMENT_NODE tagName: "End" NodeList childNodes

parent parent parent

ELEMENT_NODE tagName: "Step" parent ELEMENT_NODE tagName: "Refinement" NodeList childNodes _parent ELEMENT_NODE tagName: "Passive Resource" ELEMENT_NODE tagName: "Processing Resource" parent parent ELEMENT_NODE tagName: "Branch"

Figure 8.8: Example of DOM tree from a CSM file

ized in [DF96, Ber03] for the case of LGSPN, i.e., GSPN with only one label. Though strictly not necessary for the development of the tool, we have followed this rigorous practice and Appendix B presents the formalization for the case of MLGSPN.

The algorithm starts initializing two variables that hold intermediate GSPNs: par- tial mlgspn, that represents at any moment of the execution the elements of the CSM already translated; and list of Ends mlgspns. Next, the algorithm features four parts. The first one (lines 3..12) traverses each scenario in the CSM model to obtain and compose some of the subnets proposed in Section 8.3. The second part (lines 13..15) composes the subnets that represent End connectors (list of Ends mlgspns). The third part (lines 16..19) deals with the passive resources, while the last one (lines 21..24) is dedicated to the active ones. We can devise a simple and structured algorithm because of the effort we previously did:

• E1. As expected, the algorithm is absolutely aligned with the design proposed in Sec-

tion 8.4.1. Thus, the functionsCSM2GSPNandComposeimplement what modules

CSM2GSPN and Composer conceptualize, respectively.

• E2. We conceived the subnets in Section 8.3 to actually ease this algorithm, these nets

were designed so that once merged, the desired Petri net is obtained, regardless of the order in which they are composed.

In the first part of the algorithm, the fact of traversing each scenario just once is interesting because it allows to translate all children of a Scenario sequentially, which means not to care about the logical execution order of Steps in the system. Therefore, the traversal was implemented using a simple Iterator pattern[GHJV95] over the DOM tree of the CSM.

This first part deals with the VertexOperations (computational steps and acquisition and release of resources), the Workload, and the PathConnections (the start of the scenario and the

132 8. Model To Model Transformations: From CSM To GSPN Algorithm 8.1 Translation of a CSM.

Require: An XML CSM file that models a System Ensure: MLGSPN that represents this System

1: partial mlgspn ← empty mlgspn()

2: list of Ends mlgspns ← empty list()

3: for all Scenarios do

4: for all element ∈ (VertexOperation ∨ Workload ∨

PathConnection)do

5: subnet ← CSM2GSPN(element)

6: if (element.getTagName()==End) then

7: list of Ends mlgspns ← add(list of Ends mlgspns,subnet)

8: else

9: partial mlgspn ← Compose(subnet,partial mlgspn)

10: end if

11: end for

12: end for

13: for all end mlgspn ∈ list of Ends mlgspns do

14: partial mlgspn ← Compose(end mlgspn,partial mlgspn)

15: end for

16: for all element ∈ PassiveResource do

17: subnet ← CSM2GSPN(element)

18: partial mlgspn ← Compose(subnet,partial mlgspn)

19: end for

20: add-host-characteristics-to-steps(partial mlgspn)

21: for all element ∈ ActiveResource do

22: subnet ← CSM2GSPN(element)

23: partial mlgspn ← Compose(subnet,partial mlgspn)

24: end for

25: return partial mlgspn

different control flows). In line 5, it is translated each element into its corresponding GSPN according to the proposal in Section 8.3 by calling the CSM2GSPN module. Actually, all these elements constitute the structure of the scenario and only the resources -which are not part of Scenarios- are not considered yet. After the translation of an element, the algorithm checks whether it is an End (lines 6..10). Then the subnets for the Ends are simply stored in list of Ends mlgspns, while the rest of subnets are composed with partial mlgspn. The reason of delaying the composition of End elements is explained later.

The composition in line 9 has a particular. When the subnet and the partial mlgspn have no label in common, then the algorithm produces a new partial mlgspn that includes the subnet “in parallel”, as given in Appendix B. At the end of this part of the algorithm, we have a Petri net structure that links all the computational steps, according to the established control flow, with the subnet of the Workload and the Start as proposed in Figure 8.6. The subnets for the acquisition and release of the resources, Figure 8.3(d), are also linked in this Petri net

8.4. Tool development 133 to its predecessor and successor steps, however they still need to be linked to the subnets of the resources they manage, as in Figure 8.3(e).

The second part of the algorithm carries out the composition of the End connector subnets with the partial mlgspn. If we composed the Ends and the partial mlgspn in the first part of the algorithm, then partial mlgspn would be wrong, concretely in the case of sub-scenarios which refine more than one Step. Figure 8.9(a) depicts the translation and “too-early” com- position of a sub-scenario that is called by two different Steps. We observe that the result is that the sub-scenario cannot return the execution flow to the requester scenario. However, Figure 8.9(b) depicts the translation obtained by delaying the composition of the Ends, which is the expected one for the system. In fact, this was the only case in which we could not find

a solution to meetE2, so we had to delay the composition.

After the execution of this second part, partial mlgspn represents everything in the system except the resources. This is so because we are translating scenario by scenario. Not being part of a concrete scenario, the resources belong to the root CSM -as shown in the metamodel in Figure 8.1-, their position in the DOM tree is illustrated in Figure 8.8. Therefore, the third part of the algorithm translates passive resources and compose them with the partial mlgspn. The last part of the algorithm (lines 21..24) is dedicated to the translation and composition of the active resources. But prior to this task, it is called the function add-host-characteristics- to-steps (line 20). Considering that each Step executes on a processing resource, this function is responsible for discovering this target resource following the “scope rules” given in [PW07] and substitutes the generic labels host acq and host rel (recall Figure 8.2) by the actual name of the host. Thanks to this, the algorithm correctly merges each active resource with the net in this last part. At the end of the algorithm, partial mlgspn already represents the behavior of the whole CSM.

Although the tool checks the input CSM for some inconsistencies, it is worth noting that we ideally assume a “well-formed” CSM, otherwise the tool could produce an incorrect GSPN. For example, when entering a Fork, the n units of the previously acquired passive re- source may be used by at most n threads of the Fork and they will be eventually released. Fig- ure 8.10(a) depicts an erroneous CSM since 1 unit is acquired but 3 released. Figure 8.10(b) depicts the erroneous Petri net that the tool will produce.