In this section, we first introduce the UML domain model and the profile that leverages the Publish/Subscribe paradigm (described in Sect. 2.1) we propose to annotate UML models. Then, we describe the metamodel used for CPN and the model transformation patterns from UML models annotated with our profile to timed colored petri nets.
Description of the profile
The Unified Modeling Language (UML) [4]—a standard modeling language in the software development industry—is a powerful language that allows representing from architectural to behavioral aspects of systems.
UML can be tailored for specific purposes through profiling [6]. A UML profile provides a set of stereotypes and tagged values that are added into UML models to extend its semantics. To build a UML profile, a domain model shall be modeled in first place. This model captures all intrinsic characteristics of the domain under consideration. In our case, we defined a domain model for the PS paradigm. Then, following the rules given in Lagarde et al. [7] and Selic [6], a UML profile conformed by a set of stereotypes and its tags is obtained. Stereotypes define concepts in the domain under study, while tags are the attributes of a stereotype.
For instance, the modeling and analyzing of real-time embedded systems (MARTE) UML profile—actually, a standard promoted by the Object Management Group [20]—enables schedulability and performance analysis for real-time and other application domains. A specialization of MARTE, the non-standard dependability analysis and modeling (DAM) UML profile [21], enables to express dependability issues in UML models. Similarly, the non-standard security analysis and modeling (SecAM) profile [22] allows to express security characteristics into UML models.
Figure 3 depicts the UML domain model for the publish/subscribe paradigm. A Service can publish one or more Resources, while a Resource can only belong to a Service. A service can update both the lifetime and value of its resources (association class TimedSetter), in which both the operation to be applied over the resource value and a new expiring time are indicated. This operation can also be delayed as indicated by the optional argument Delay. A Client can perform different actions on a Resource, such as subscribing to the resource (specifying the minimum and maximum value of interest to the client and the subscription time, association class Subscription), getting the resource value and storing it into a variable (association class Getter), or updating the resource value (association class Setter). Finally, a Client can also assign values to local variables (association class Assignments).
UpdateOperation and AssignmentOperation are defined as complex data types. UpdateOperation has two attributes, operator and value. The operator values are specified as an enumeration type (SignKind), which consists of the arithmetic operators that allow us to update a resource value. AssignmentOperation has also two attributes, property and value.
The corresponding UML profile that maps the contents of the publish/subscribe domain model is depicted in Fig. 4. Since we need to identify the UML sequence diagram (UML-SD) scenarios in which the publish/subscribe paradigm is being used, we have incorporated the PublishSubscribeScenario stereotype that extends the Interaction metaclass. This stereotype indicates the UML-SD in which the subscription from a client to some resources are expressed.
Service, Resource, and Client classes have been modeled with stereotypes. The Service stereotype extends the Node UML metaclass, which belongs to the Deployments UML package. The Resource stereotype extends the Artifact UML metaclass (which also belongs to the Deployments UML package). Both stereotypes are related through an association, indicating that a Service may publish an arbitrary number of resources, while a resource only belongs to a single service. To verify the correctness of the annotated UML model, we added an OCL expression [23] into the Resource stereotype to check whether the container of the UML artifact is indeed stereotyped with Service. Finally, the Client stereotype extends the Lifeline metaclass, from the Interactions UML package.
The association classes related to the interactions between services and clients with resources have been modeled as stereotypes extending the Message metaclass. The tagged values of these stereotypes match with the attributes of the corresponding associated classes. The optional attribute delay of the class TimedSetter has also been transformed to a stereotype, also extending the Message metaclass. Furthermore, we have also included an AbstractSetter stereotype, which defines the operation attribute as an UpdateOperation complex type. This complex type is used to update the value of a Resource and thus it defines a tuple with the operation to apply (indicated by operator) and the value of interest (indicated by variable).
Finally, the association class Assignments has been modeled as the AssignmentExecution stereotype, which extends the ExecutionSpecification metaclass and enables us to indicate the initial assignment of Clients’ attributes.
A metamodel for Colored Petri nets
Figure 5 shows the metamodel for Timed Colored Petri nets, which has been defined by extending a previous work [24]. The metamodel has been designed in such a way that it captures all the specifities of CPN Tools. This design poses two main advantages (at the cost of being tied to this specific tool): first, it allows us to deal with all the interesting concepts of this simulation and analysis tool from a single M2M transformation, without the need of any kind of preprocessing; and second, it eases the serialization of the final XML file that needs to be fed into the analysis and simulation tool, because the metamodel is a close representation of the schema that native CPN Tools net files must validate.
Cpnet is the main class of the model (see Fig. 5), and elements in the model can be differentiated into two groups. On the right-hand side of the figure, and contained within the Globbox class, we find the elements to declare color sets, variables, etc., while on the left-hand side of the figure, and contained within a Binder, we find the elements that visually represent a Petri net.
More specifically, declarations can be grouped in nested Blocks, and can be formed by color sets (ColorSet) (either simple or compound—SimpleColorSets or CompoundColorSets, respectively), variables (Var), reference variables (Globref), or CPN ML expressionsFootnote 5 (Ml). Examples of SimpleColorSet are basic datatypes, such as Unit, Integer, Real, String, etc., while for CompountColorSet are complex types, such as Cartesian Product, disjoint Union, etc.
On the other hand, graphical elements are placed inside Pages, which may be grouped in Binders. All graphical elements inherit from the DiagramElement class, and can be organized in different Groups. Thus, a Page can hold places (Place), transitions (Trans), arcs (Arc), annotations (Annot), etc. Places must have an associated color set, which must be defined in the declarations part. The relationship between the place and its color set is represented by means of the type role from the class Place to the class ColorSet. The InitMark determines the initial marking of a given place, i.e., the tokens owned by the place before starting the simulation. Transitions may have different inscriptions attached, such as firing conditions (TransCond), priorities (TransPriority), and transition delays (TransTime). Arcs link a place to a transition and have an orientation (from place to transition, or vice versa).
Finally, places can be fused via the Fusion class. Fused places act as a single place, thus allowing reuse, and making easier the partitioning of a single CPN in different pages (every page contains a CPN model).
Model transformation: from UML models to CPN
In the following, we detail the transformation of the UML models annotated with the profile into TCPN. We first describe the UML parts, annotated with the profile, and then how the transformation is carried out for each part. To illustrate the transformation process, we have adapted the online purchase process example already introduced in Valero et al. [26] and used it as a running example. A detailed explanation regarding the patterns of the model transformation is given in https://github.com/abelgomez/publish-subscribe/blob/master/plugins/io.github.abelgomez.ps.transformer/doc/README.md.
PS core net
Figure 6 illustrates the TCPN of the PS core net model. This core net rules the resource publication, resource subscription, notifications, and resource expiration. The PS core net model generated by our model transformation is (slightly) simplified with regard to the previous model introduced in Valero et al. [26]. This modification was needed to cope with all automatic transformation contributed in this paper an later explained for the following stereotypes. A single core net is generated for each UML sequence diagram stereotyped as PublishSubscribeScenario. PublishSubscribeScenarios should include the initialization of resources, the subscription messages of the different clients, and the additional interactions which are triggered when notifications are sent. In the core net, the initial marking of the Roles and Resources places—which are explained below—are the only variable parts.
In this TCPN, the resources to be published are represented by tokens on the Resources place, which contain their EPR, tag, value and lifetime. Resources are then published by firing the Publish_ok transition, but if we try to publish a resource with an existing EPR, this operation fails (by firing publish_fail). Published resources are written to the ResourceRegistry place. Clients’ behaviors are represented by tokens on place Roles, where we indicate a client’s identifier, a resource tag and the subscription conditions for the indicated resource. The Discover transition is then fired to find published resources and write the corresponding subscription conditions into the SubscriptionRequest place. The Subscribe transition is then fired to submit the subscriptions, which are written on the SubscriptionRegistry place.
When the lifetime of a resource expires, the ResourceExpire transition is fired, which removes the resource token from ResourceRegistry, as well as its current subscriptions (transition RemoveSubscription). Furthermore, subscriptions can also expire. In that case, the SubscriptionTime-Out transition will be fired, thus removing the corresponding token from SubscriptionRegistry. Finally, notifications occur as soon as the associated conditions hold, which is captured by transition Notify, which has the greatest priority (P1).
Publish/Subscribe scenarios
Figure 7 (left side) illustrates the UML-DD (left side) and the UML-CD (right side, annotated with the PublishSubscribeScenario stereotype) of the running example. There exists a client who is willing to buy a laptop using her credit card. She is waiting for a good offer due to her limited amount of money, though. The artifact CR in the UML-DD diagram represents her current budget, as maintained by her personal bank. She also disposes of some cash, as indicated by the attribute m of Client class. Surfing on the Internet, the client finds two offers from two different online shops. However, both laptop prices still overrun her budget. Services Shop1, Shop2, and resources L1, L2, represent the online shops and the laptops, respectively.
Figure 8 depicts the actions of the client with the resources in a UML-SD annotated with PublishSubscribeScenario stereotype. Consider that the client has some cash (for instance, 2000€). Since she wants to pay by credit card, she first decides to subscribe to her bank deposit during 1 year to let her know when her credit is lower than 1000€ and then make a deposit to increase it (triggering UML-SD Deposit). After that, she decides to subscribe to both resources during 1 year to keep posted as soon as some offer in the laptop price comes up (triggering UML-SD Purchase L1 and Purchase L2, respectively).
A UML-SD stereotyped with PublishSubscribeScenario creates a place Start Subscription and two transitions (Acquire Locks and End Subscription) into the generated TCPN. Additionally, every Client and Resource lifelines have an associated place which is used to avoid race conditions issues when handling client/resources attributes.
These places are in fact fusioned places, i.e., places that act as a single one although they are drawn multiple times in different parts of the CPN. The Acquire Locks and End Subscription transitions represent respectively the beginning and the ending of the UML-SD. In particular, the first transition also has as input places the client/resource lock places that represent the client/resources involved into the UML-SD. Similarly, the ending transition has as output places the same client/resource lock places, ensuring the conservativeness of the tokens (i.e., the acquired locks are eventually released). The subnet resulting from all the interactions described in the UML-SD lifelines is then enclosed between these two transitions. This internal subnet is built in a compositional way, by applying the rest of the patterns explained in this section. The places that serve to connect these patterns have UNIT as color set.
A PublishSubscribeScenario SD should be accompanied by a DD describing the allocation of Services and Resources (a node Service1 and an artifact Resource1 in this case). Note that the association between resources and services is directly taken from the node-artifact relationship. Finally, let us also note that both Service1 and Resource1 are also included in the UML-SD.
As introduced in Sect. 3, in addition to UML-DD, UML-CD are also used to provide the static view of the system under analysis. Recall that Fig. 7 (right side) shows the Client class of the running example. In this case, it has two attributes, a boolean-type brought and a real-type m. The transformation of this part is straightforward. The Client class is directly transformed into a timed product color set. The first component is a single string used to unequivocally identify every instance of the class (i.e., to identify the class objects), while the rest of the components are each of the class attributes). For the sake of simplicity, our transformation algorithm also defines a set of variables following the attributes defined within the class (e.g., “var att1: DATATYPE1”, “var att2: DATATYPE2”, etc.). Therefore, the existence of a lifeline in a UML-SD stereotyped as Client is straightforwardly transformed to a colored place having the previously mentioned timed product color set as color set and an initial token with the values of object Client1.
The set of variables and color sets in the CPN model generated by the annotations in the UML-SD PublishSubscribe scenario, the UML-CD, and the UML-DD are collected in Listing 1. Note that it also sets the initial marking of the PS core CPN model introduced previously.
The TCPN generated by our approach is depicted in Fig. 9. The “Fusion n” tag in some places of the net means that they are Fusion places, and thus they correspond to a same place that is used in several CPN pages. For instance, this is the case of the Resource Registry place, which also appears in the PS core net model shown in Fig. 6. In the following, we describe each part of the net considering the transformation of the stereotypes shown in Fig. 8. For the sake of readability, we have added dashed boxes in the figure to highlight from which stereotype comes each part of the net.
The Subscription stereotype. Once the basic elements have been transformed (core net, client definitions, and external structure of the Subscription PN), let us explain the transformation for subscription interactions (Subscription stereotype). Consider the resource L1, owned by Shop1 and having (1, ’RL’, 950.0, 365) as attribute values. Consider also the Client who subscribes to such a resource by means of a Subscription stereotyped message, as depicted in Fig. 8 (third subscription message). Note that Client subscribes for a time frame of 365 days, triggering the UML-SD named Purchase L1 once the values of L1 are in the interval of [0, 850.0]. As shown in Listing 1, both Resource and Subscription stereotypes are transformed into the corresponding initial colored tokens in the PS core CPN. Let us remark that the Resource stereotype serves us to populate the Resources place, whereas the Subscription stereotyped message serves us to populate the Roles place.
The AssignmentExecution stereotype. This stereotype is used in a UML-SD stereotyped with PublishSubscribeScenario to indicate when the attributes of a Client object are modified.
Our transformation tool automatically verifies the correctness of the model, i.e., it checks whether every property specified in each AssignmentOperation matches to some attribute of the Client class. Any datatype error in the specified values is indicated by the tool, indicating a mismatch data type error in the corresponding arc inscription.
Regarding the transformation, every execution specification in the annotated UML-SD generates a branch in the sequential Colored Petri net that represents the execution of the overall UML-SD. Then, each execution specification annotated with AssignmentExecution generates a transition for each of the AssignmentOperation attributes. This transition is connected to the place that stores the current status (values) of the object Client through an input and output arc. As input arc, it receives a tuple of the form \((client_1, att_1, att_2,\dots \mathbin {,} att_i, \dots , att_n)\), which represents the particular instance of Client and the values of its set of attributes. As output arc, it returns a colored token conformed by \((client_1, att_1, att_2, \dots , att_i, \dots ,att_n)\). The only value that is modified in the tuple of the output arc inscription is the one specified in the attributes of the stereotype.
For instance, in the UML-SD depicted in Fig. 8 the Client assigns the values of false and 2000.0 to its attributes brought and m, respectively. This execution specification, annotated with AssignmentExecution, generates the part of the net depicted in the second dashed box (from the top) in Fig. 9, following the aforementioned pattern. Note that the transformation model follows the assignment operations from left to right (that is, first the value of brought is set, and then the value of m).
Moreover, let us remark that since this action occurs inside a PublishSubscribeScenario UML-SD, the Client lock was acquired at the beginning (first dashed box) and hence no race conditions arise.
The TimedSetterand Delayedstereotypes. Let us recall the running example as depicted in Fig. 8. The client was subscribed to both resources to be aware if some changes were produced in their prices for a year. Let us consider now that a few days later after the subscription (consider for instance 10 days), the sales period begins so both shops simultaneously reduce their laptop prices. In particular, Shop1 offers a 30% off for Laptop1 during 30 days, while Shop2 offers a 20% off for Laptop2 during 15 days. Note that both resource subscriptions and the update of the laptop prices occur inside a parallel combined fragment. These actions have been annotated with TimedSetter and Delayed stereotypes in the UML-SD Subscription.
Recall that the TimedSetter stereotype allows us to update the value of a resource as indicated by the operator attribute. This stereotype also allows us to update the resource lifetime. In the running example, the current value of the resource L1 is multiplied by 0.7, representing the 30% off of the sales offer. The generated subnet of TimedSetter stereotype (red dashed box in the central part of Fig. 9) contains two places and one transition (SET_L1_0), which is connected to the Resource Registry place. The arc inscription of the arc from the transition to the Registry place is used to update the value of the resource, taking into account the operation to perform and the value specified as stereotype attribute values. For instance, the incoming arc of SET_L1_0 is (EPR, “L1”, v, cr), while the output arc is \((EPR, ``L1'', v \times 0.7, 30\)). (See the attribute values of the TimedSetter stereotype in Fig. 9.)
The Delayed stereotype allows us to specify a delay on a given message. Let us remark that the transformation pattern for the Delayed stereotype will be inserted before any other pattern produced by other stereotypes also applied on the same message (see the green dashed boxes in 9). Its transformation follows a similar scheme to the TimedSetter stereotype. Recall that the update of the price of L1 was done 10 days after the client subscription, as specified by the Delayed stereotype in Fig. 8. In this case, two places and a new transition connected to them are generated. These new places represent the beginning and ending of the delay operation, and thus they are connected to the sequential CPN representing the evolution of the whole UML-SD. The transition is connected to the Resource Registry place through input/output arcs that do not change the resource attributes, but serve us to check that it is already published. The value of the Delayed::delay attribute is the time that the new transition generated takes to fire (see the annotation @+10 under the transition in Fig. 9).
Transformation of parallel combined fragments. Combined fragments are UML structural components whose transformation is not directly linked to any stereotype of the UML profile. Consider the parallel combined fragment of the UML-SD as depicted in Fig. 8 (bottom side). The transformation of this fragment is as follows (third dashed box in the figure). First, a fork transition creates a new branch of execution, separate from the sequential execution of the overall UML-SD, which terminates with a corresponding join transition. This branch corresponds in the figure with the part indicated in the right-hand side of the enclosing box. Notice that two places are also produced as the output of this fork transition. Then, for the new branch a new fork transition splits the execution into the parts indicated in the parallel fragment (two in this case), creating the initial and final places for each one. A join transition is also created in order to link the termination of the parallel branches with the original sequential flow (penultimate dashed box). Then, each part of the parallel fragment is transformed into its corresponding TCPN, following the patterns explained along this section.
Triggered sequence diagrams
Triggered sequence diagrams (triggeredSDs) are those UML-SD describing the interactions happening when the value of a Resource is between the minimum and maximum values specified by a subscribed Client. That is, they represent the UML-SD that takes place when the given conditions are fulfilled.
Let us illustrate how the transformation of a triggeredSD is carried out by means of the UML-SD Deposit. Recall that this UML-SD was triggered when the credit of the client is lower than 1000€ (see the first Subscription message in Fig. 8). The UML-SD Deposit of the running example is depicted in Fig. 10, while the TCPN generated is shown in Fig. 11. As before, we have highlighted with dashed boxes the interesting parts of the generated net.
The transformation into TCPN is very similar to the one of a UML-SD stereotyped with the PublishSubscribeScenario. In particular, two places Start Deposit and Finish Deposit, and two transitions are created. The first transition works similar to the previous Acquire Locks transition: as input arc, it consumes tokens from the Start Deposit place, from all places that represent the client and resource locks of the clients and resources which interact in the UML-SD, and from the Notifications place. As initial marking, the Start Deposit place contains a string-typed token with the “Deposit” value.
The Notifications place is then used to activate this subnet when a notification occurs. As an illustration, in our running example the input arc of the initial transition and the Notifications place has as inscription the tuple (EPR, “CR_USER”, “Client”, v, “Deposit”), which indicates the participants of the UML-SD stereotyped (“Client” and “CR_USER”) and the name of the triggered SD (“Deposit”).
Transformation of alternative combined fragments. Notice now the use of an alternative combined fragment in Fig. 10 to specify a conditional flow in a sequence diagram. With this alternative combined fragment, we indicate an interaction between a Client and a CR that only occurs if the condition \(m > 1000.0\) is fulfilled.
The transformation of this fragment is similar to the parallel combined fragment. First, a branch is created by the transition below the Start Deposit place, which separates the sequential Petri net that represents the execution of the overall UML-SD from the new branch for the combined fragment (on the right). The part produced for the alternative combined fragment is enclosed in the dashed boxes at the top and bottom of the figure. The combined fragment has its own sequential flow, so a new fork transition is used to separate this flow from the alternatives, which are started by transitions labeled with the corresponding guards. These transitions are connected with the Client place so as to obtain the attribute values (m and bought) required in their guards. Only one of these transitions can fire (see the conflict place in the right-hand side), and they must fire before the transition corresponding to the default condition, so they have a higher priority than the transition representing the default condition.
Finally, each part in the alternative combined fragment is individually transformed into its corresponding TCPN following the rules explained in this section. In our running example the default case is empty, so its transformation is straightforward. Thus, there are two branches in the generated TCPN (see Fig. 11), one branch without any activity (left branch) and the other branch having the condition \(m > 1000.0\) (right branch). Furthermore, this branch contains the generated TCPN of the contents shown in the alternative fragment (the transformation of an AssignmentExecution stereotype and a Setter stereotype, explained later).
The Setter stereotype. The UML-SD depicted in Fig. 10 also shows a message stereotyped with Setter. The Client is modifying the value of resource CR by operating on its current value (in particular, its value is being incremented in 1000 units).
The transformation of this stereotyped message follows a similar approach to the TimedSetter stereotype (see the dashed box in the central part of Fig. 11). The generated subnet contains two places and one transition (SET_CR_USER_0), which is also connected to the Resource Registry place in order to modify the resource property value.
Let us now see the UML-SD Purchase L1 depicted in Fig. 12, which corresponds to the triggeredSD for the third client’s subscription in the UML-SD Subscription (see Fig. 8). The generated TCPN for this UML-SD Purchase L1 is shown in Fig. 13. In this UML-SD, the Getter stereotype is used in order to get the values of the resource properties.
The Getter stereotype. The Getter stereotype is used in the UML-SD to indicate the variable in which the value of a resource is stored. Note that in the UML-SD depicted in Fig. 12 there are two messages stereotyped with Getter, getting the values of the resources L1 and CR in the client’s variables PPL1 and balance. These variables are then used as part of the guard condition in the subsequent alternative combined fragment.
The transformation of the Getter stereotype is enclosed in a dashed box in Fig. 13. As in the previous cases, input and output arcs are produced to link the transition starting the corresponding branch with the Resource Registry place, so as to obtain the property values and assign the client’s variables with the values obtained (PPL1 and balance).