Main Page/Resources/E-motions/PLSObModExample

From Atenea

Jump to: navigation, search

This webpage shows the observers' rules and weaves for the Production Line System case study. At the same time, it presents the approach based on AWM for the weave between system's rules and observers' rules.

Contents

Modular Approach for the Specification of Observers in the PLS Example

Observers' Rules and Weaves

For illustration purposes, weaving links are graphically depicted in the figure as thick lines, although in practice the textual Eclipse AWM weaving editor is used to specify these links. The duration of the resulting rules is that of the system rules.

TimeStampOb Observer

The observer's rules defining the behavior of the TimeStampOb observer associated to heads and handles are the following.

Image:BirthTS.png Image:ProcTS.png Image:DeathTS.png

The rules below show the weaving links for the TimeStampOb observer associated to handles. The observer's rules (in the lower part of the figures) specify its life-cycle. The generic object in the IndividualBirthTS rule to which the TimeStampOb observer is associated is linked to the Handle in the GenHandle rule. Such a link inserts the observer associated to the handle in the GenHandle rule. The initial values of the attributes of the observer for this system are specified in the weaving link (graphically shown in the box attached to the line that represents the binding). In the second figure we can see how the generic objects in the IndividualProcessingTS rule are linked to the Part objects in the Carry rule (remember that the Part class is a generalization of the Handle one). The weaving link will make the TimeStampOb be inserted in the Carry rule and associated to the Part object. Finally, the observer has to disappear from the system when its associated Handle object disappears. For that purpose, we link the generic object in the IndividualEndTS rule with the Handle object in the Assemble rule, since the latter disappears in that rule.

Image:weaveTS1.png Image:weaveTS2.png Image:weaveTS3-1.png

TimeBusyOb Observer

The observer's rules defining the behavior of the TimeBusyOb observer associated to machines are the following.

Image:BirthTB.pngImage:ProcTB.pngImage:OngTB.png

The rules below show the weaving links for the TimeBusyOb observer associated to any machine, although here it is shown for the handles generator. The generic object in the IndividualBirthTP rule to which the TimeBusyOb observer is associated is linked to the GenHandle in the InitialRule rule. Such a link inserts the observer associated to the handles generator in the model from the beginning. There is another binding which makes the TimeBusyOb be associated with the GenHandle in the GenHandle rule. Finally, an ongoing rule is included to keep the value of the tIdle attribute updated.

Image:weaveTB1.png Image:weaveTB2.png Image:weaveTB3.png

ThroughPutOb Observer

The observer's rules defining the behavior of the ThroughPutOb observer are the following.

Image:BirthTP.png Image:RecTP.png Image:OngTP.png

The figures below show the weaving links between the rules specifying the behavior of the ThroughPutOb observer and the system rules where we want the observer to be woven. Two weaving links are defined in order to include the ThroughPutOb observer in the system. The first one is defined between the InitialRule and GeneralBirthTP rules. The former is a system rule, which has the initial configuration of the system without observers in its RHS and the latter is an observer rule. We only show the headings of both rules for making the figure simpler. The aim of this binding is to include the observer in the initial configuration of the system. The second weaving link is defined between the Hammer object in the Collect rule of the system and the generic object in the RecordLeaveTP rule (the NAC of the former rule is not shown for simplicity). The effect of this binding is to include the ThroughPutOb observer in both the LHS and RHS of the Collect rule. Note that the expression used to calculate the value of the collected attribute in the RHS of the observer rule has been superseded with a new expression (this is indicated in the figure inside the box between the two woven rules). Finally, the ContinuousUpdateTP rule is added to the system's rules (it becomes a new rule in the system).

Image:weaveTP1.pngImage:weaveTP2-3.pngImage:weaveTP3.png

MTBOb Observer

The observer's rules defining the behavior of the MTBOb (Mean Time Busy) observer are only two. The number of machines is three for this particular example, although it can be easily changed for a different example.

Image:BirthMTB.png Image:OngMTB.png

The figures below show the weaving links between the rules specifying the behavior of the MTBOb observer and the system rules where we want the observer to be woven. In fact, there is only one weaving link: between the GeneralBirthMTB and the InitialRule. It makes the MTBOb observer be present in the system from the beginning. The other rule is the ongoing rule available at the library with MTBOb observer's rules.

Image:weaveMTB1.png Image:OngMTB.png

MTBFOb Observer

The observer's rules defining the behavior of the MTBFOb (Mean Time Between Failures) observer are only two. The first one creates the observer and initializes its attributes. The RecordLeaveMTBF rule increases the defective attribute when a generic object leaves the system. The mtbf attribute is updated accordingly.

Image:BirthMTBF.png Image:RecMTBF.png

The figures below show the weaving links between the rules specifying the behavior of the MTBFOb observer and the system rules where we want the observer to be woven. Two weaving links are defined in order to include the MTBFOb observer in the system. The first one is defined between the InitialRule and GeneralBirthMTBF rules. The former is a system rule, which has the initial configuration of the system without observers in its RHS and the latter is an observer rule. The aim of this binding is to include the observer in the initial configuration of the system. The second weaving link is defined between the Hammer object in the Collect rule of the system and the generic object in the RecordLeaveMTBF rule (the NAC of the former rule is not shown for simplicity). The result of this binding is to include the MTBFOb observer in both the LHS and RHS of the Collect rule. Note that the expressions used to calculate the value of the defective and mtbf attributes in the RHS of the observer rule have been superseded by new expressions (this is indicated in the figure inside the box between the two woven rules).

Image:weaveMTBF1.png Image:weaveMTBF2.png

DelayOb Observer

There are two observer's rules defining the behavior of the DelayOb observer. The first one creates the observer and initializes its attributes. Since the way the DelayOb observer updates its attributes depends on other observers, there are two generic objects added to the RecordLeaveD rule. They represent other kinds of observers.

Image:BirthD.png Image:RecD2.png

The figures below show the weaving links between the rules specifying the behavior of the DelayOb observer and the system rules where we want the observer to be woven. Two weaving links are defined in order to include the DelayOb observer in the system. The first one is defined between the InitialRule and GeneralBirthD rules. The former is a system rule, which has the initial configuration of the system without observers in its RHS and the latter is an observer rule. The aim of this binding is to include the observer in the initial configuration of the system. The second weaving link is defined between the Hammer object in the Collect rule of the system and the generic object in the RecordLeaveD rule (the NAC of the former rule is not shown for simplicity). The effect of this binding is to include the DelayOb observer in both the LHS and RHS of the Collect rule. Regarding those generic objects representing observers, it is not necessary to match them with any object in the system rule. In fact, the DelayOb observer is to be included in the system's rules once the TimeStampOb and ThoughPutOb observers have been introduced in the rule, since the former depends on these two. The fact that the two generic objects representing both observers are present in the observer's rule helps modelers in the definition of the bindings and the use of the DelayOb observer library, since they realize that both observers should have previously been included in the system rule.


Image:weaveD1.png Image:weaveD2-1.png

MCTOb Observer

There are two observer's rules defining the behavior of the MCTOb (Mean Cycle Time) observer. The first one creates the observer and initializes its attributes. Since the way the MCTOb observer updates its attributes depends on other observers, there are two generic objects added to the RecordLeaveCT rule. They represent other kinds of observers.

Image:BirthCT.png Image:RecCT2.png

The figures below show the weaving links between the rules specifying the behavior of the MCTOb observer and the system rules where we want the observer to be woven. Two weaving links are defined in order to include the MCTOb observer in the system. The first one is defined between the InitialRule and GeneralBirthCT rules. The former is a system rule, which has the initial configuration of the system without observers in its RHS and the latter is an observer rule. The aim of this binding is to include the observer in the initial configuration of the system. The second weaving link is defined between the Hammer object in the Collect rule of the system and the generic object in the RecordLeaveCT rule (the NAC of the former rule is not shown for simplicity). The effect of this binding is to include the MCTOb observer in both the LHS and RHS of the Collect rule. Regarding those generic objects representing observers, it is not necessary to match them with any object in the system rule. In fact, the MCTOb observer is to be included in the system's rules once the TimeStampOb and ThoughPutOb observers have been introduced in the rule, since the former depends on these two. The fact that the two generic objects representing both observers are present in the observer's rule helps modelers in the definition of the bindings and the use of the MCTOb observer library, since they realize that both observers should have previously been included in the system rule.

Image:weaveCT1.png Image:weaveCT2-1.png

Model Composition with AMW

The AtlanMod Model Weaver (AMW) [1] supports the creation of different kinds of links between model (or metamodel) elements. The links are saved in a weaving model. The weaving model conforms to an extensible weaving metamodel. There exists a set of application scenarios where it is necessary to establish different kinds of links between model elements [2]. Thus, links can be used to capture the semantic heterogeneities in tool interoperability scenarios, to describe model composition operations and they are also used in traceability and model alignment scenarios.

From all of the mentioned application scenarios, we are interested in model compositions, since we want to merge two models into one. One model is composed of system's rules (those rules without observers), and the other model is composed of the library with observers' rules.

In the following, we first present an extension of the generic core weaving metamodel and then we present an excerpt of the weaving operation, whcih is interpreted in the ATL engine.

Extended Weaving Metamodel

Since we want to establish links among elements conforming to the Behavior metamodel of e-Motions (concretely, among Objects and Rules), the generic core weaving metamodel has to be extended with such concepts. We also need to know the Behavior metamodel when defining the ATL transformation. Such metamodel is shown below:

Image:behMM.png

In the following we define the extensions to the generic core weaving metamodel shown in [1].

  • The models to be woven are defined as extensions of the WModel class. We want to weave two models, those with the system's and observers' rules:

Image:WModel3.png

  • The different kinds of links are extensions of WLink. There are two kinds of links in our case: those that define a matching among rules and those defining matchings among objects. In the latter links, it can be specified the new slot value that supersedes the slot value in the observer of the observer's rule:

Image:WLink2.png

  • The elements that can be woven are defined as extensions of WElementRef. We can weave Objects and Rules:

Image:WElementRef2.png

Weaving Operation

Here we present an excerpt of the weaving operation, interpreted by the ATL engine. An ATL transformation matches every type of link (there are two of them in our case) and executes the appropriate weaving operation. Thus, the ATL transformation takes the weaving model, the system's rule model and the observers' rules model as input and produces a new woven model composed by behavioral rules.

An excerpt of the rule dealing with the weaves among rules is the following:

Image:MergeRules.png

The MergeRules rule receives as input a link among rules that has been previously identified by the modeler who wants to weave the rules models. From that link, we can access its endpoints, which are a system rule and an observer rule. This ATL rule creates a behavioral rule which is the result of putting the elements from both (the system and the observer) rules into one. The value of the attributes name, soft, lowerBound, upperBound and maxDuration are those of the system rule, which is the second (and last) element in the end reference of the MergeRuleLink. For the objects and variables to be present in the resulting rule, the OCL collect operation is used in order to gather the elements from both rules together.

An excerpt of the rule dealing with the weaves among objects is the following:

Image:MergeObjects.png

This rule is similar to the previous one, but now the link received as input is of type MergeObjLink. It means that the end references are the objects being matched. Now, when we want to access all the elements of a rule, we navigate from the object to the rule that contains it, and from there we access all its elements. Regarding the observer to be included in the rule, we take into account that a different value for some slots of the observer may have been specified. For that reason, we treat that object (the observer) independently from the rest of the objects. We identify it as o.

References

[1] The AtlanMod Model Weaver, http://wiki.eclipse.org/AMW

[2] Didonet Del Fabro, M, B├ęzivin, J, and Valduriez, P. Weaving Models with the Eclipse AMW plugin. In: Eclipse Modeling Symposium, Eclipse Summit Europe 2006, Esslingen, Germany, 2006.

Personal tools