A Model Transformation Tool : PMIF + to QNAP

An extension to the Performance Model Interchange Format (PMIF+) to move models among tools has been recently introduced. The original PMIF was limited to models solvable with efficient, exact solution methods such as mean value analysis and product form solutions. The extensions allow models with features that require simulation or analytical approximation solutions, such as passive resources, workloads that fork into multiple concurrent workloads, etc. This paper presents a tool for the automated transformation from PMIF+ to Qnap, and explains some of the challenging transformations required by the new PMIF+ features.


INTRODUCTION
The Performance Model Interchange Format (PMIF) is a common representation of input required by all tools that provide Queueing Network Models (QNM) solutions [7].More generally, MIFs (Model Interchange Formats) provide the basis for easily transferring the model information among modeling tools with either one import/export interface per tool, or by an automated transformation from the MIF to a tool's input language.The QNM models may be created by translating design models into performance models [1,6].They may be created by a tool that provides a graphical user interface for specifying the model topology and parameters then creates model interchange files.They may also be ex-ported by one modeling tool in order to compare results to other modeling tools.
The original PMIF was limited to models that could be solved by efficient, exact algorithms (e.g., mean value and product form solutions) to focus on the feasibility of the model interoperability approach.Once feasibility was established, PMIF+ [2] extended the scope to allow analytical approximations or simulation solutions.Qnap [4,5] is one of the few modeling tools that solves models with all of the features in PMIF+.Some of the new features can be quite challenging to represent in QNM, such as workloads that fork into multiple concurrent workloads, and requests for passive resources that may require queueing for the resource but no active service from it.Demonstrating the viability of PMIF+ requires creating and solving models with these complexities.This paper presents a tool that transforms models from PMIF+ to Qnap's input format and illustrates how to transform models with these complex features.This information is also useful for anyone who would like to create an import/export or transformation for other modeling tools.
The PMIF+ meta-model is specified using the Eclipse Modelling Framework (EMF) which allows for Model-to-model (M2M) and Model-to-Text (M2T) transformations.The PMIF+2Qnap transformation is developed using Acceleo [3] which is a code generator based on templates that implements the OMG's M2T specification.

PMIF+
The PMIF+2Qnap transformation tool's input is a PMIF+ [2]   3. Allocate/Deallocate Resource -When access to a passive resource is restricted, a workload may request access and wait in a queue until the resource is Allocated.
When access to the resource is no longer needed the workload Deallocates the resource.A scheduling policy determines the next workload to receive the Allocation.
4. Wait/Queue/Set Event -An Event may be Set or Cleared.Workloads may Wait or Queue for an event to be Set.When an event is Set, all waiting workloads and one queued workload may proceed.
Items 2-4 are examples of features that use PassiveEntities: resources that are required for execution but provide no active service themselves.
A broader set of arrival and service distributions as well as queue scheduling disciplines, including priorities, is included.The complete list is defined and represented in the PMIF+ meta-model in [2].An excerpt presenting the new PMIF+ features is shown in A QueueingNetworkModel now has zero or more PassiveEntities in addition to Nodes, Workloads and ServiceRequests.
There is a new Node called ForkJoin to handle Fork and Join operations.When willJoin = T , it is a Fork and the parent waits for all children (ForkWorkloads, see below) to complete and return to the same node for Join.When willJoin = F , it is a Split; the parent continues execution and the children workloads exit the system upon completion.The Server has an extended schedulingPolicy as shown in Fig. 1.There is also a new type of Workload, ForkWorkload that represents a child workload with a maximum population that is created by its parent at a ForkJoin node.
A new ServiceRequest, ServiceRequestPlus, specifies a combination of active and passive service requests that can be made at any node with an optional sequenceNumber which specifies their order of execution when ordering is required (sequence numbers are increasing but need not be consecutive).
ActiveService requests specify a service time similar to the TimeServiceRequest.They may use a special Probability-Distribution or a load dependent service time.The latter is specified as a string which will be interpreted by the tool.
PassiveService requests specify the command, the quantity, and reference the PassiveEntity.Table 1 shows the types of PassiveEntity and the commands associated with each.
Note that PassiveService does not normally block the server, it only blocks the workload.It has an optional attribute, blocksServer which is set to True when the server needs also to be blocked.

COMPLEX TRANSFORMATIONS
The PMIF+2Qnap tool (Fig. 2) uses the Eclipse Modeling Framework (EMF).The tool takes a model that conforms to the PMIF+ meta-model and transforms it into the Qnap input language.The transformations are implemented with Acceleo [3] which is a code generator based on templates that implement the OMG's M2T specification.Acceleo is also fully integrated in the EMF framework.Therefore the transformation specification is created as a file with extension mtl.Fig. 2 shows how to execute a transformation with Acceleo, with part of the mtl specification file for the transformation also on the screen.
The ServiceRequestPlus is the key element that extends the scope of supported models.The ForkJoin and ForkWorkload are key to synchronization features of models.Therefore, these two transformations are described next.

ServiceRequestPlus
A ServiceRequestPlus (SRP) can contain several Service elements which can be active or passive.The PassiveService elements can also be blocking or non-blocking (which is an attribute).Figure 3 summarizes the main steps of a Ser-viceRequestPlus transformation.
The way that Qnap can implement a PassiveService is using an extra station for each server where the customers will go while the PassiveService occurs.A PassiveService is the execution of a Command on a PassiveEntity.Table 1 shows the types of PassiveEntity and the commands associated with each of them.Table 2 shows how Qnap can implement the different passive entities and commands and so the way it is implemented by the transformation.
In order to develop a correct transformation, several approaches were studied.Fig. 4 shows the final approach.The transformation generates two Qnap stations for each Ser-viceRequestPlus, one for the active services and one for the

ForkJoin
For a ForkJoin node, the transformation generates (as shown in Fig. 6):

Fig 1 .
The elements that are added for PMIF+ are yellow in the figure (or not shaded gray if viewed in black and white), some of the original PMIF elements are shown in green (or shaded grey) for the comprehension of the diagram, others are missing due to lack of space.We describe a few of the new features in detail in this section as background for the description of the transformation in the next section.

Figure 2: Execution of a transformation with Acceleo Passive Entity Qnap entity Commands in Qnap
fork station to model the exit of the ForkJoin.When the WillJoin attribute is true, a Qnap MATCH operation is performed at the fork station.If WillJoin is