Main Page/Resources/E-motions/PacketSwitchingExample

From Atenea

< Main Page | Resources | E-motions(Difference between revisions)
Jump to: navigation, search
(Structure)
Current revision (09:50, 11 October 2011) (edit) (undo)
(Structure)
 
(41 intermediate revisions not shown.)
Line 1: Line 1:
=Introduction=
=Introduction=
-
This Packet Switching example models a network. A user sends packages to another user by means of the network. This is composed of nodes which receive, process, and forward packages to other nodes. A node, after having processed a package, forwards it to a node which is connected to it. The node where the package is forwarded is the one which is currently processing fewer packages among the nodes connected to the former. Eventually, a package arrives to the other user after being processed by a node connected to him.
+
This Packet Switching example models a communication network. A user sends packets to another user by means of the network. This one is composed of nodes which receive, process, and forward packets to other nodes. A node, after having processed a packets, forwards it to a node which is connected to it. The node where the packets is forwarded is the one which is currently processing fewer packets among the nodes connected to the former. Eventually, a packet arrives to the server after being processed by a node connected to it.
=System Modeling=
=System Modeling=
Line 9: Line 9:
The metamodel of this system is shown here:
The metamodel of this system is shown here:
-
[[Image:PSMetamodel.png]]
+
[[Image:PSMM.png]]
-
The network is composed of components which have a specific position. Components can point to other components which play the role of neighbours. They can also contain packages. Packages have two attributes, ''is_being_processed'' and ''timeStamp''. ''is_being_processed'' is true if the package is being processed by a node and false if it is not. ''timeStamp'' stores the time at which the package get into the network. Components are of three types: Users, Nodes and Servers. Users send packages to the network and servers receive and consume them. Nodes receive packages, process them and forward them to other components. They have an attribute, ''pckPr'', which counts the packages processed. When the initial user or a node have more than one possible node to send a package, they send it to the node that is currently processing a smaller number of packages. The time a node spends when processing a package depends on the number of packages it is currently processing: the more packages being processed, the slower the processing is. There is a node's specialization, named Support Node, which can be active or not depending on the number of packages being processed by the nodes linked to the support node by the support relationship. In this way, when one of the nodes that a support node supports is processing the same number of packages as the value indicated by the ''threshold'' attribute or a higher number of them, the support node activates itself if it was not already active. On the contrary, when the support node is active and all the nodes that it supports are processing a lower number of packages than the indicated by the threshold value, it deactivates itself. The ''activations'' attribute records the time units when a support node activates/deactivates itself.
+
The network is composed of components which have a specific position. Components can point to other components which play the role of ''neighbours''. They can also contain packets. Packets have two attributes, ''is_being_processed'' and ''timeStamp''. ''is_being_processed'' is true if the packets is being processed by a node and false if it is not. ''timeStamp'' stores the time at which the packets get into the network. Components are of three types: Users, Nodes and Servers. Users send packets to the network and servers receive and consume them. Nodes receive packets, process them and forward them to other components. They have an attribute, ''pckPr'', which counts the packets processed. When an user or a node have more than one possible node to send a packet, they send it to the node that is currently processing a smaller number of packets. The time a node spends when processing a packet depends on the number of packets it is currently processing: the more packets being processed, the slower the processing is. There is a node's specialization, named Support Node, which can be active or not depending on the number of packets being processed by the nodes linked to the support node by the ''support'' relationship. In this way, when one of the nodes that a support node supports is processing the same number of packets as the value indicated by the ''threshold'' attribute or a higher number of them, the support node activates itself if it was not already active. On the contrary, when the support node is active and all the nodes that it supports are processing a lower number of packets than the indicated by the threshold value, it deactivates itself. The ''activations'' attribute records the time units when a support node activates/deactivates itself.
We associate every class of the metamodel with a picture. This graphical concrete syntax will be used for the definition of the behavioral rules.
We associate every class of the metamodel with a picture. This graphical concrete syntax will be used for the definition of the behavioral rules.
-
[[Image:PacketSwitchingGCS.png]]
+
[[Image:PSGCS.png]]
-
We are interested on monitoring the throughput and delay of the packages processed by a network as well as on the number of packages processed by each node, specially the support nodes, and the activation/deactivation frequency of the support nodes. The latter two properties can be already analyze with the pckPr and activations attributes of nodes. As for the other two, we make use of observers.
+
We are interested on monitoring the throughput and delay of the packets processed by a network as well as on the number of packets processed by each node, specially the support nodes, and the activation/deactivation frequency of the support nodes. The latter two properties can be already analyze with the ''pckPr'' and ''activations'' attributes of nodes. As for the other two, we make use of ''observers''.
An observer is an object whose purpose is to monitor the state of the system:
An observer is an object whose purpose is to monitor the state of the system:
-
the state of the objects, of the actions, or both. Observers, as any other objects, have a state and a well-defined behavior. The attributes of the observers capture their state and are used to store the variables that we want to monitor. We have defined an ''Observers metamodel'':
+
the state of the objects, of the actions, or both. Observers, as any other objects, have a state and a well-defined behavior. The attributes of the observers capture their state and are used to store the variables that we want to monitor. We have defined an Observers metamodel:
-
[[Image:ObserversMetamodel.png]]
+
[[Image:Observers.png]]
-
We have three di�fferent observers:
+
We have three different observers:
-
* ThroughputOb. It is aim to monitor the throughput of the system, consid-
+
* ThroughputOb. It is aim to monitor the throughput of the system, considered as the number of packets that are processed by the network per unit of time.
-
ered as the number of packages that are processed by the network per unit
+
 
-
of time.
+
* DelayOb. It monitors in its ''delay'' attribute the average time units spend by packets on being processed by the network. The other attribute is used to facilitate the calculation of the delay.
 +
 
 +
* CounterOb. This observer counts packets. The ''packetsServer'' attribute counts the number of packets that arrive to the server, and is used to calculate the throughput and delay of the system. The ''packetsNetwork'' attribute stores the number of packets that the users introduce in the network. Finally, ''totalPackets'' is the total number of packets that the network will process.
 +
 
 +
 
 +
The idea for analyzing the system with observers is to combine the Packet Switching metamodel with the Observers metamodel to be able to use the observers in our Domain Specific Visual Language (DSVL) for specifying communication networks. In fact, since ''e-Motions'' allows users to merge several metamodels in the definition of a DSVL behavior, we can define the Observers metamodel in a non-intrusive way, i.e., we do not need to modify the system metamodel to add observers to it. Furthermore, this approach also enables the reuse of observers across different DSVLs. Then, the behavior of the observers is specified using rules, too.
 +
 
 +
 
 +
This is the graphical concrete syntax defined for the Observers metamodel:
 +
 
 +
[[Image:ObserversGCS.png]]
=Behavior=
=Behavior=
-
We have designed four rules to model the behavior of the system, including the rule that initializes the system.
+
We have designed seven rules to model the behavior of the system, including the rule that initializes the system.
 +
 
 +
 
 +
[[Image:PSRules.png]]
 +
 
 +
 
 +
 
 +
The '''InitialRule''' creates the initial model. There are three users that will be sending packets to the network and a server that will be consuming them. Each user is connected to different nodes so packets will arrive to the network by different places. Eight normal nodes are present in the network plus two support ones which are deactivated at the beginning. These two nodes support two other nodes each one, so they will be activated/deactivated according to the number of packets being processed by those nodes and their own threshold attributes. The neighbour relationships going from nodes to support nodes will be only transmitting packets when the corresponding support node is active.
 +
We include an observer of each type in the network and we give their attributes some initial values. We can see that the network will process 500 packets.
 +
The NAC pattern forces this rule to be fired only once by forbidding its execution if a user already exists in the system.
-
[[Image:PSrules.png]]
+
[[Image:PSINITIAL.png]]
 +
The '''NewPacket''' rule simulates the arrival of packets to the users. The time interval at which packets arrive is [1,7]. It is specied by a variable, ''duration'', which determines the duration of the rule (''eMotions:random(6)'' returns a value between 0 and 6). At the moment of their arrival to the network, packets are not being processed by any node and the current time elapse is given to their timeStamp attribute.
 +
We use here the CounterOb observer to make the users not receive more packets when there have been introduced in the network as many packets as the value of the ''totalPackets'' attribute of the observer.
-
The '''InitialRule''' creates the initial model. It contains two users, one that will be sending packages and one that will be receiving them. The sender has the ''initial'' attribute set to ''true'', and its value in the receiver is ''false''. There are ten nodes. The connection of all the components forms a network whose behavior will be given with the following rules. The NAC pattern forbids the triggering of the rule if was already thrown before.
 
 +
[[Image:PSNewPacket.png]]
-
[[Image:PSInitial.png]]
 
 +
The '''Forwarding''' rule models the forwarding of packets among components and nodes. This rule is fired when sending packets from users to nodes and from nodes to nodes. To apply this rule, the packet must not being processed. Furthermore, there are two OCL expressions that have to be satisfied in order to launch the rule. They state that the node is the component's neighbour which is processing a lower number of packets and that it cannot be a deactivated support node. In the RHS pattern of the rule the packet has moved to the node and it has started being processed. The duration of this rule can be either 0 or 1 time unit.
-
The '''PackageArrival''' rule models the creation of a package in the sender, so that it will be forwarded to the network in other rule. The attribute of the package to be sent to the network is set to ''false'', as it is not being processed by any node. This rule spends two time units in its execution, so a new package appears in the sender user every two time units.
+
[[Image:Forwarding.png]]
-
[[Image:PackageArrivalPS.png]]
+
The '''PacketProcessing''' rule models the processing of a packet by a node. For this purpose, this rule modifies the ''is_being_processed'' packet attribute. The ''pckPr'' attribute of the node is increased in one unit as it has processed a new packet. The time this rule spends is directly proportional to the number of packets being processed by the node. Thus, the time spent is two times the number of packets being processed plus one.
 +
[[Image:PSPacketProcessing.png]]
-
The '''Forwarding''' rule models the forwarding of a package from a component to a neighbour one. For this rule to be triggered, the package cannot be under processing. In the LHS pattern of the rule there is a OCL condition that forbids the triggering of the rule if the neighbour ''c2'' is not the one processing fewer packages among all the neighbours of the component ''c''. In the RHS pattern we see how the package is now in the other node and the attribute ''is_being_processed'' is set to ''true'' as it is ready to be processed by the new node. The NAC pattern forbids the triggering of the rule if the component ''c'' is already forwarding the package. The time spent when forwarding a package is the Manhattan distance between both components.
 
 +
The '''PacketArrival''' rule models the arrival and consumption of a packet from a node to the server. The time this rule consumes can be either 0 or 1 unit time.
 +
The three observers are updated here. The CounterOb observer updates the number of packets arrived to the server, the DelayOb observer updates its attributes to properly compute the delay and the ThroughputOb computes the current throughput value with the arrival of the packet.
-
[[Image:ForwardingPS.png]]
 
 +
[[Image:PSPacketArrival.png]]
 +
'''ActivationSupport''' rule deals with the activation of a support node if it was deactivated and at least one of the nodes it supports is processing as many packets as the threshold value or more. '''DeactivationSupport''' rule does the opposite. It deactivates a support node if it was active and if all the nodes that it supports are processing a lower number of packets than the threshold value. In both rules, the time unit when the activation/deactivation is produced is appended to the ''activations'' sequence attribute of the support node.
 +
These rules consume zero time units in its execution, so they are instantaneous rules.
-
The '''PackageProcessing''' rule models the processing of a package by a node. In the LHS pattern of the rule the attribute ''is_being_processed'' of the package is set to ''true'', meaning that it has just arrived to the node and it is ready to be processed. In the RHS pattern the package has already been processed so its attribute is set to ''false'', so that it is ready to be forwarded again. The NAC pattern forbids the triggering of the rule if the package is already been processed. The time this rule lasts grows as the number of pacakges being processed by the node does. Thus, the time spent is two times the number of packages being processed by the node, plus one.
 
 +
[[Image:PSACTIVATION.png]]
-
[[Image:ProcessingPS.png]]
+
[[Image:PSDEACTIVATION.png]]
=Simulation=
=Simulation=
Line 72: Line 97:
-
[[Image:simPS.png]]
+
[[Image:pslauncher.png]]
 +
=Results=
-
=Data Result=
+
We have run some simulatons and have elaborated some graphs using the [[Main_Page/Resources/E-motions/PacketSwitchingExample/Results| '''results''']].
=Download=
=Download=
-
The [[Media:PS.zip‎ | PS.zip]] file contains the project with all files required to try this example: the metamodel definition, the graphical concrete syntax for the metamodel and its corresponding behavioral specifications. To import this project, right click on the navigation view ''Import...-> General -> Existing Projects into Workspace -> Select archive'' file and then select the PS.zip.
+
The [[Media:ps.zip‎ | PacketSwitching.zip]] file contains the project with all files required to try this example: both metamodel definitions, the graphical concrete syntax for the metamodels and the system's behavioral specifications. To import this project, right click on the navigation view ''Import...-> General -> Existing Projects into Workspace -> Select archive'' file and then select the PS.zip.

Current revision

Contents

Introduction

This Packet Switching example models a communication network. A user sends packets to another user by means of the network. This one is composed of nodes which receive, process, and forward packets to other nodes. A node, after having processed a packets, forwards it to a node which is connected to it. The node where the packets is forwarded is the one which is currently processing fewer packets among the nodes connected to the former. Eventually, a packet arrives to the server after being processed by a node connected to it.

System Modeling

Structure

The metamodel of this system is shown here:

Image:PSMM.png

The network is composed of components which have a specific position. Components can point to other components which play the role of neighbours. They can also contain packets. Packets have two attributes, is_being_processed and timeStamp. is_being_processed is true if the packets is being processed by a node and false if it is not. timeStamp stores the time at which the packets get into the network. Components are of three types: Users, Nodes and Servers. Users send packets to the network and servers receive and consume them. Nodes receive packets, process them and forward them to other components. They have an attribute, pckPr, which counts the packets processed. When an user or a node have more than one possible node to send a packet, they send it to the node that is currently processing a smaller number of packets. The time a node spends when processing a packet depends on the number of packets it is currently processing: the more packets being processed, the slower the processing is. There is a node's specialization, named Support Node, which can be active or not depending on the number of packets being processed by the nodes linked to the support node by the support relationship. In this way, when one of the nodes that a support node supports is processing the same number of packets as the value indicated by the threshold attribute or a higher number of them, the support node activates itself if it was not already active. On the contrary, when the support node is active and all the nodes that it supports are processing a lower number of packets than the indicated by the threshold value, it deactivates itself. The activations attribute records the time units when a support node activates/deactivates itself.

We associate every class of the metamodel with a picture. This graphical concrete syntax will be used for the definition of the behavioral rules.

Image:PSGCS.png


We are interested on monitoring the throughput and delay of the packets processed by a network as well as on the number of packets processed by each node, specially the support nodes, and the activation/deactivation frequency of the support nodes. The latter two properties can be already analyze with the pckPr and activations attributes of nodes. As for the other two, we make use of observers. An observer is an object whose purpose is to monitor the state of the system: the state of the objects, of the actions, or both. Observers, as any other objects, have a state and a well-defined behavior. The attributes of the observers capture their state and are used to store the variables that we want to monitor. We have defined an Observers metamodel:

Image:Observers.png

We have three different observers:

  • ThroughputOb. It is aim to monitor the throughput of the system, considered as the number of packets that are processed by the network per unit of time.
  • DelayOb. It monitors in its delay attribute the average time units spend by packets on being processed by the network. The other attribute is used to facilitate the calculation of the delay.
  • CounterOb. This observer counts packets. The packetsServer attribute counts the number of packets that arrive to the server, and is used to calculate the throughput and delay of the system. The packetsNetwork attribute stores the number of packets that the users introduce in the network. Finally, totalPackets is the total number of packets that the network will process.


The idea for analyzing the system with observers is to combine the Packet Switching metamodel with the Observers metamodel to be able to use the observers in our Domain Specific Visual Language (DSVL) for specifying communication networks. In fact, since e-Motions allows users to merge several metamodels in the definition of a DSVL behavior, we can define the Observers metamodel in a non-intrusive way, i.e., we do not need to modify the system metamodel to add observers to it. Furthermore, this approach also enables the reuse of observers across different DSVLs. Then, the behavior of the observers is specified using rules, too.


This is the graphical concrete syntax defined for the Observers metamodel:

Image:ObserversGCS.png

Behavior

We have designed seven rules to model the behavior of the system, including the rule that initializes the system.


Image:PSRules.png


The InitialRule creates the initial model. There are three users that will be sending packets to the network and a server that will be consuming them. Each user is connected to different nodes so packets will arrive to the network by different places. Eight normal nodes are present in the network plus two support ones which are deactivated at the beginning. These two nodes support two other nodes each one, so they will be activated/deactivated according to the number of packets being processed by those nodes and their own threshold attributes. The neighbour relationships going from nodes to support nodes will be only transmitting packets when the corresponding support node is active. We include an observer of each type in the network and we give their attributes some initial values. We can see that the network will process 500 packets. The NAC pattern forces this rule to be fired only once by forbidding its execution if a user already exists in the system.


Image:PSINITIAL.png


The NewPacket rule simulates the arrival of packets to the users. The time interval at which packets arrive is [1,7]. It is specied by a variable, duration, which determines the duration of the rule (eMotions:random(6) returns a value between 0 and 6). At the moment of their arrival to the network, packets are not being processed by any node and the current time elapse is given to their timeStamp attribute. We use here the CounterOb observer to make the users not receive more packets when there have been introduced in the network as many packets as the value of the totalPackets attribute of the observer.


Image:PSNewPacket.png


The Forwarding rule models the forwarding of packets among components and nodes. This rule is fired when sending packets from users to nodes and from nodes to nodes. To apply this rule, the packet must not being processed. Furthermore, there are two OCL expressions that have to be satisfied in order to launch the rule. They state that the node is the component's neighbour which is processing a lower number of packets and that it cannot be a deactivated support node. In the RHS pattern of the rule the packet has moved to the node and it has started being processed. The duration of this rule can be either 0 or 1 time unit.


Image:Forwarding.png


The PacketProcessing rule models the processing of a packet by a node. For this purpose, this rule modifies the is_being_processed packet attribute. The pckPr attribute of the node is increased in one unit as it has processed a new packet. The time this rule spends is directly proportional to the number of packets being processed by the node. Thus, the time spent is two times the number of packets being processed plus one.


Image:PSPacketProcessing.png


The PacketArrival rule models the arrival and consumption of a packet from a node to the server. The time this rule consumes can be either 0 or 1 unit time. The three observers are updated here. The CounterOb observer updates the number of packets arrived to the server, the DelayOb observer updates its attributes to properly compute the delay and the ThroughputOb computes the current throughput value with the arrival of the packet.


Image:PSPacketArrival.png


ActivationSupport rule deals with the activation of a support node if it was deactivated and at least one of the nodes it supports is processing as many packets as the threshold value or more. DeactivationSupport rule does the opposite. It deactivates a support node if it was active and if all the nodes that it supports are processing a lower number of packets than the threshold value. In both rules, the time unit when the activation/deactivation is produced is appended to the activations sequence attribute of the support node. These rules consume zero time units in its execution, so they are instantaneous rules.


Image:PSACTIVATION.png

Image:PSDEACTIVATION.png

Simulation

We can configure eMotions launcher to run the simulation as shown in the next figure. Please note that we do not need to specify an initial model of the system since we have a rule that creates it.


Image:pslauncher.png

Results

We have run some simulatons and have elaborated some graphs using the results.

Download

The PacketSwitching.zip file contains the project with all files required to try this example: both metamodel definitions, the graphical concrete syntax for the metamodels and the system's behavioral specifications. To import this project, right click on the navigation view Import...-> General -> Existing Projects into Workspace -> Select archive file and then select the PS.zip.

Personal tools