The GSPN models derived from the automatic translation of UML behavioral models, in particular StateCharts, can be reused in the context of the DepAuDE methodology and inserted in the layered structure proposed in Section 4.1 of part I. This is the case, for example, of the watchdog GSPN model presented in the previous section that has been reused in the example of Subsection 4.3.1 in order to obtain a final analyzable model of an automation system.
One of the main issues concerning the reuse of GSPN models obtained from the automatic translation of
State-CHAPTER 6. JOINT ANALYSIS OF THE TRANSLATED UML DIAGRAMS 137
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
0 1 2 3 4 5
Pdf of TTR
t (ms.)
tr2=1 tr2=2 tr2=3 tr2=4
Figure 6.7: Comparison of the Pdf of Time To Reset under different transmission rates.
Charts is their different interface with respect to the models placed in the layered structure: indeed the translation of StateCharts produces place interface models while in the layered structure models interact through transition interface. In this section we describe how to adapt a GSPN model derived from the translation of a StateChart in order to insert it within the layered structure of Section 4.1.
In Figure 6.8, the transformation of the place interface of a GSPN model produced by the automatic translation of a StateChart into a transition interface is exemplified. In the upper part, the sender and the receiver models communicating through place interface are shown. In case of asynchronous communication the sender model is characterized by a transition t1, labeled with the name of the action performed, with output place mbx, labeled as e event, where event is the name of the event generated by the interaction. In case of synchronous communication the transition representing the action execution is expanded in the sequence: transition t1- place - transition t2, where transition t1 is relabeled as S action and transition t2 is labeled as E action. Moreover, a place mbx0 labeled as ack event is added as input place of t2to represent the mailbox of the acknowledgement of the event occurrence. The receiver model is characterized, instead, by a transition t3, labeled as e event, representing the dispatching of the event event, with an input place labeled as e event. In case of synchronous communication, a place labeled as ack event is added and the firing of transition t3generates the acknowledgement for the sender.
To obtain sender and receiver models with transition interface is sufficient to remove the mailbox places, i.e., places labeled as e event and ack event and, in case, to carry out an expansion of a transition in a sequence of two causally connected transitions providing to label the new transitions as shown in Figure 6.8, middle part, that is in the following way:
sender model (asynchronous communication) the transition t1 labeled as action, after its expansion in the pairs of transitions t1, t2, is relabeled as S action, while the new added transition t2is labeled as E action;
receiver model the transition t3labeled as e event, after its expansion in the pairs of transitions t3, t4, is relabeled as S e event, while the new added transition t4is labeled as E e event.
e_event
Place-interfaceTransition-interface within the layered structure
S_action
E_action
S_e_event
E_e_event Process levelService level
e_event
Figure 6.8: Transformation of models with place interface into models with transition interface.
Note that there is a unique sender model with transition interface for both synchronous and asynchronous communication. Indeed, the sender and receiver models with transition interface are two process models that interact with each others, indirectly, through the use of communication service models, placed at lower level in the PSR structure described in part I, Section 4.1; the type of communication is discriminated at service level, where two different kinds of communication service models are possible as depicted in Figure 6.8, bottom part. On the bottom left part of Figure 6.8, the asynchronous communication service model is depicted. It consists of four causally connected transitions ts, t0s, tr, t0r labeled, respectively, as S action, E action, S e event and E e event; transitions tsand t0srepresents the execution of the action action carried out by the sender process, while transitions tr and t0r represent the dispatching of the event event, generated by the action, carried out by the receiver process. On the bottom right part of Figure 6.8, the synchronous communication service model is shown. It consists of a pair of causally connected transitions t and t0, both multi-labeled: t is characterized by labels S action and S e event, and its firing represents the start of the interaction between the sender and the receiver processes, t0 is characterized by labels E action and E e event and its firing represents the termination of the communication between the two processes.
Chapter 7
Conclusion
The topic of this thesis has been the construction of Stochastic Petri Net models for the quantitative assessment of complex software systems from the early stages of the software development process. We have assumed a software system specified with UML, which is nowadays the semi-formal language that has found the major agreement in the software engineering community and in the industry. UML provides different kind of diagrams that allow to represent different aspects of the system, such as its functionalities, its static structure, the dynamic behavior of each system component and their interaction, and the physical details. There is not a general rule that establishes which diagrams have to be used in which stages of the software life-cycle and, from the quantitative evaluation point of view, all of them carry information about the system.
Among the UML diagrams, in this thesis we have considered: 1) Class Diagrams, because they provide a first (static) view of the system at a high level of abstraction since they allow to represent the main system components together with their relations; 2) StateCharts, because they represent the behavior of the system (or component) in response to the occurrence of events and they are closer to the Petri Net formalism; 3) Sequence Diagrams, because they allow to emphasize some of the interactions among the system components and they provide a mean to detect, through the qualitative analysis, the non-wanted system behaviors and to focus the quantitative analysis on specific system behavioral patterns. The role played by the other UML diagrams in the context of quantitative evaluation of systems and their integration to get SPN analyzable models will be matter of our future research studies.
When several UML notations are used in combination to obtain formal models, it is necessary to check the con-sistency of the information present in the different diagrams: in this thesis, we have suggested concon-sistency checks when each system component participating to an interaction modeled by a Sequence Diagram is represented by a StateChart in order to get a final analyzable GSPN model from the StateCharts and Sequence Diagram specifi-cations. Consistency problems regarding, for example, the joint use of Class Diagrams, described in the first part of the thesis, and the StateCharts and Sequence Diagrams, considered in the second part, have not been tackled yet: we plan to deal with these issues more in-depth by reusing the approaches proposed in the literature, e.g.,
139
[84].
We have adopted Stochastic Petri Nets as target modeling formalism because of our experience in modeling with SPNs but also because SPNs allow to carry out a preliminary correctness analysis before performing the quantitative evaluation of the system and they are suitable for both performance and dependability assessments.
We have mainly used Generalized Stochastic Petri Nets, since we have assumed that, in the early stages of the software life-cycle, the system is specified at class level: in the first part of the thesis we have given some guide-lines on how to transform GSPN models in their colored version (i.e., SWN models) in order to take into account of the object identities. Concerning the GSPN translations of StateCharts and Sequence Diagrams described in the second part, the next step will be their SWN extension to consider the use of these two behavioral notations for object level specification.
The translations of StateCharts and Sequence Diagrams into GSPNs allow to obtain not only models for the quantitative assessment of systems but also provides a formal semantics for a significant subsets of UML State Machines and Interaction Diagrams, being the Common Behavior, State Machines and Collaborations UML metamodels the starting point of the proposed translation.
Other works have been devoted to give formal semantics to State Machines and Interaction Diagrams, such as [55] and [15]. In particular, in [55] a formalization of State Machines is proposed and it consists of two steps: in the first step, the structure of a state machine is translated into a term rewriting system which allows to specify the states and the transitions; in the second step, the operational semantics of the state machine is defined and the run-to-completion step algorithm is implemented. In [15], instead, a formal translation of UML Sequence Diagrams into untimed Petri Nets is proposed: it is focused on the formalization of the precedence relation existing between messages belonging to a simple SD.
The works refer to the State Machines ([55]) and to the Collaborations ([15]) metamodels but the formalizations are meant for correctness assessment of the modeled system while our objective is its quantitative evaluation.
Concerning our approach to the construction of SPN models from the UML CD schemes presented in the first part of the thesis, we have been inspired by the work [12] where skeleton dependability SPN models are derived from UML high level models, enriched with information regarding faults behavior, system failure modes and metrics of interest to be computed. In [12] the general class of SPNs is considered and a compositional approach is followed, although the composition rules of the SPN subnets are not explicitly stated. Unlike [12] we have not used intermediate models to filter the information from UML specifications and we have used the specific class of GSPNs together with their colored version (SWNs).
We have heavily used net-composition both in the derivation of SPN models of dependable automation systems, within the DepAuDE methodology, and in the translations of Sequence Diagrams and StateCharts. The main reasons are that net-composition allows to master the complexity of modeling fault-tolerant systems, it supports the reuse of models and it should facilitate the implementation of the translation, since only the basic concepts of state machines and interaction diagrams need to be translated while tools that implement the composition
CHAPTER 7. CONCLUSION 141 operators already exist, e.g., algebra[7] associated to the GreatSPN tool[69].
Net-composition has been used, for example, in [50] to obtain SPN models from combined UML behavioral diagrams. The basic idea is similar to the work presented in this thesis: the system is specified by a set of StateCharts that represent the behavior of its components but, instead of using a Sequence Diagram to emphasize a particular interaction among the components, a Collaboration Diagram is used. However, with respect to our work, the construction of the final SPN model is described only at an intuitive level, through an example, no translation procedure is given and no composition rules are defined. In [72] the same combined UML behavioral diagrams, i.e., a set of StateCharts together with a Collaboration Diagram, are used to obtain SPA models: also in this case no translation procedure is given although the composition of SPA component models is well-stated.
A necessary condition for the GSPN translations of StateCharts and Sequence Diagrams to eventually become a useful modeling practice is their implementation. We plan to start the implementation from the standard exchange format for the UML diagrams (i.e., XMI), although the current UML tools supporting this format generate XMI files that do not contain all the UML features characterizing the UML models.
The implementation of the GSPN translations is a first step toward the development of a design environment for the modeling, the qualitative and quantitative analysis of software systems through the combined use of UML and SPNs that conforms to the Model Processing approach suggested by the UML Profile for Schedulability, Performance and Time Specification [65]. Indeed, according to the Model Processing approach, the only effort required to the modeler is to enrich the UML models with performance annotations following the indications given by the Profile: the annotated UML model is then passed to the quantitative analysis tool, in our context a SPN tool, where it is analyzed and the results are returned back to the modeler. The fundamental aspect is that the exchange between the UML tool and the quantitative analysis tool is automated and the details of the quantitative analysis on formal models are made transparent to the user.
A recent work along these lines has been published in [14] that uses UML as a way to describe PEPA [41]
performance models in an user-friendly manner: the characteristics of UML considered are the one that most naturally translate into PEPA models (a subset of StateCharts and Collaboration Diagrams). UML models can constructed and enhanced with performance annotation by using the Argo UML tool; the annotated models are then mapped to PEPA [41] models which are solved by using the PEPA workbench [37]. Finally, the performance results obtained are fed back to the UML modeler that can visualize them on the original UML models: the exchange of information between Argo tool [82] and the PEPA workbench is carried out by using the XMI format.
As any automatically produced model also the GSPN models produced from the translation of StateCharts and Sequence Diagrams contain a number of unnecessary elements from the point of view of the stochastic behavior:
additional work is needed to define equivalent models [77] of reduced size in terms of vanishing markings [18], lumped states [19] and in terms of net elements (places/transitions).
7.1 Comparison with the HIDE approach
In [12, 13, 11, 10] the problem of deriving Timed Petri Net models (TPNs) from UML models has been dealt extensively and the proposed solution contributed to the construction of an integrated environment, developed within the HIDE project1, of UML-based design augmented with validation and analysis techniques [9]. Herein, we analyze the similarities and the differences of our work with respect to the approach to the derivation of dependability formal models for quantitative analysis followed in HIDE.
A first comment is about the application domain considered: the solution proposed in HIDE addresses to gen-eral complex software and hardware systems, specified with UML, as our proposal of automatic translation of UML Sequence Diagrams into GSPNs and of joint analysis of the translated UML Statecharts and Sequence Diagrams. Concerning instead our proposal of construction of SPN models taking into account of dependabil-ity requirements extracted from a set of UML Class Diagrams, we have focused on the domain of automation systems for which a suitable fault-tolerance strategy has to be defined by using dependability software mecha-nisms belonging to a predefined library or by adopting ad-hoc mechamecha-nisms, that is the target applications of the DepAuDE project.
In HIDE a transformational approach has been followed and an automatic model transformation technique was elaborated in order to produce from UML models dependability TPN models. The transformation is basically carried out in three steps: in the first one, the relevant dependability information of the system are extracted from UML models and an intermediate model, i.e., an hyper-graph, is built. In the second step from the intermediate model a TPN is generated and, finally, in the last step the TPN model is translated into the input format of PANDA tool [67] that allows to analyze different classes of TPN models (e.g., GSPNs and stochastic Petri nets characterized by generally distributed firing times).
Our work is aimed at obtaining GSPN models, or their colored version (SWN), in a semi-automatic way, that is providing to the modeler a library of predefined GSPN component models, a suggested structure for the final model and guidelines for its construction. The part of the construction that can be made automatic is related to the derivation of GSPN models when UML behavioral specification of system components are available and to the composition of the identified set of GSPN/SWN component models to derive the final model of the system. The translation of UML Sequence Diagrams and Statecharts into GSPNs has not been implemented yet and it will be matter of future work, while compositionality has been implemented in the GreatSPN tool [81], that supports the analysis of GSPN and SWN models.
Although net-composition operators are not formally defined, also in HIDE a compositional approach is adopted to obtain the final TPN model from the set of TPN subnets generated from the intermediate model.
In HIDE all UML structural diagrams are considered for the derivation of high-level TPN models, which can be augmented with more detailed information coming from UML behavioral models of the identified critical parts
1HIDE (High-level Integrated Design Environment for Dependability) ESPRIT Project 27439
CHAPTER 7. CONCLUSION 143 of the system, e.g., components belonging to redundant structures. The scheme we have proposed as a support for collecting dependability and timing requirements of automation systems consists instead of only class dia-grams. Integration of other diagrams in the scheme will be matter of future research work. In particular, among them good candidates are: deployment diagrams that allow to represent explicitly the mapping between soft-ware components and hardsoft-ware resources, behavioral diagrams to give an explicit specification of dependability mechanisms, in particular their interactions with the automation system. Some of the mechanisms provided by DepAuDE are of common usage in fault-tolerance, their design patterns have already been defined in the litera-ture [31] and commercial UML tools, e.g., Rhapsody [43], include these patterns in their demo-libraries, so that these patterns can be easily integrated in the scheme.
In HIDE extension mechanisms of UML are prescribed in order to capture dependability aspects: stereotypes are introduced for identifying the redundancy structures, for discriminating hardware elements from software elements as well as state-full elements from stateless ones, for identifying error propagation among components, and, concerning UML behavioral models, failure states and particular events. Tags associated to stereotypes allow to introduce dependability input parameters, together with their values, and metrics to be computed in the corresponding stereotyped elements as tagged-values. Discrimination between input parameters and metrics to be computed is based on the number of values assigned to the tagged-values, i.e., one or two values for input parameters and zero values for output results.
We have not used stereotypes nor tagged-values in our scheme but simply the basic elements of standard Class Diagrams; we did not actually need to use these types of extension mechanisms, since the generic CD scheme has been conceived as an analysis pattern for capturing dependability and timing requirements of automation systems and for identifying the most appropriate fault-tolerance strategy to be applied rather than a profile for modeling generic dependable software systems.
Considering the UML layered architecture, the proposed scheme belongs to the model layer in which infor-mation concerning dependability parameters and measures of interest to be computed are represented by class attributes that are discriminated by prefixing their names with a different symbol depending on their type of usage (i.e., input parameters, measures to be computed or bounds to be verified).
Another reason because we have not used stereotypes is that tags and constraints defined in the stereotypes must be present, the former as tagged-values, in the corresponding stereotyped elements. The usage of stereotyping in the customization process of the generic CD scheme has the same drawback of using specialization relationship,
Another reason because we have not used stereotypes is that tags and constraints defined in the stereotypes must be present, the former as tagged-values, in the corresponding stereotyped elements. The usage of stereotyping in the customization process of the generic CD scheme has the same drawback of using specialization relationship,