Checking the validity of scenarios in UML models

Abstract. In the UML, sequence diagrams are used to state scenarios, i.e., examples of interactions between objects. As such, sequence diagrams are being developed in the early design phases where requirements on the system are being captured. Their intuitively appealing character and conceptual simplicity makes them an ideal tool for formulating simple properties on a system, even for non-experts. Besides guiding the development of a UML model, sequence diagrams can thus furthermore be used as a starting point for the verification of the UML model. In this paper, we show how the requirements on the system as stated in sequence diagrams can be (semi-automatically) validated for UML models consisting of class diagrams, state machines and structure diagrams. The sequence diagrams that we consider can be universally or existentially quantified or negated, i.e., state scenarios that should always, sometimes or never occur. For validating them in a UML model, we translate both model and sequence diagrams into a formal specification language (the process algebra CSP), and develop procedures for employing the standard CSP model checker (FDR) for checking their validity

A graph-based aspect interference detection approach for UML-based aspect-oriented models

Aspect Oriented Modeling (AOM) techniques facilitate separate modeling of concerns and allow for a more flexible composition of these than traditional modeling technique. While this improves the understandability of each submodel, in order to reason about the behavior of the composed system and to detect conflicts among submodels, automated tool support is required. Current techniques for conflict detection among aspects generally have at least one of the following weaknesses. They require to manually model the abstract semantics for each system; or they derive the system semantics from code assuming one specific aspect-oriented language. Defining an extra semantics model for verification bears the risk of inconsistencies between the actual and the verified design; verifying only at implementation level hinders fixng errors in earlier phases. We propose a technique for fully automatic detection of conflicts between aspects at the model level; more specifically, our approach works on UML models with an extension for modeling pointcuts and advice. As back-end we use a graph-based model checker, for which we have defined an operational semantics of UML diagrams, pointcuts and advice. In order to simulate the system, we automatically derive a graph model from the diagrams. The result is another graph, which represents all possible program executions, and which can be verified against a declarative specification of invariants.\ud To demonstrate our approach, we discuss a UML-based AOM model of the "Crisis Management System" and a possible design and evolution scenario. The complexity of the system makes con°icts among composed aspects hard to detect: already in the case of two simulated aspects, the state space contains 623 di®erent states and 9 different execution paths. Nevertheless, in case the right pruning methods are used, the state-space only grows linearly with the number of aspects; therefore, the automatic analysis scales

Incremental Consistency Checking in Delta-oriented UML-Models for Automation Systems

Automation systems exist in many variants and may evolve over time in order to deal with different environment contexts or to fulfill changing customer requirements. This induces an increased complexity during design-time as well as tedious maintenance efforts. We already proposed a multi-perspective modeling approach to improve the development of such systems. It operates on different levels of abstraction by using well-known UML-models with activity, composite structure and state chart models. Each perspective was enriched with delta modeling to manage variability and evolution. As an extension, we now focus on the development of an efficient consistency checking method at several levels to ensure valid variants of the automation system. Consistency checking must be provided for each perspective in isolation, in-between the perspectives as well as after the application of a delta.Comment: In Proceedings FMSPLE 2016, arXiv:1603.0857

Testing M2T/T2M Transformations

Presentado en: 16th International Conference on Model Driven Engineering Languages and Systems (MODELS 2013). Del 29 de septiembre al 4 de octubre. Miami, EEUU.Testing model-to-model (M2M) transformations is becoming a prominent topic in the current Model-driven Engineering landscape. Current approaches for transformation testing, however, assume having explicit model representations for the input domain and for the output domain of the transformation. This excludes other important transformation kinds, such as model-to-text (M2T) and text-to-model (T2M) transformations, from being properly tested since adequate model representations are missing either for the input domain or for the output domain. The contribution of this paper to overcome this gap is extending Tracts, a M2M transformation testing approach, for M2T/T2M transformation testing. The main mechanism we employ for reusing Tracts is to represent text within a generic metamodel. By this, we transform the M2T/T2M transformation specification problems into equivalent M2M transformation specification problems. We demonstrate the applicability of the approach by two examples and present how the approach is implemented for the Eclipse Modeling Framework (EMF). Finally, we apply the approach to evaluate code generation capabilities of several existing UML tools.Universidad de Málaga. Campus de Excelencia Internacional Andalucía Tech. Proyecto TIN2011-2379

Teaching Model Views with UML and OCL

The specification of any non-trivial system is normally composed of a set of models. Each model describes a different view of the system, focuses on a particular set of concerns, and uses its own notation. For example, UML defines a set of diagrams for modelling the structure and behavior of any software system. One of the problems we perceived with our students is that they are able to understand each one of these diagrams, but they have problems understanding how they are related, and how the overall system specifications work when composed of a set of views. This paper presents a simple case study that we have developed and successfully used in class, which permits students developing the principal views of a system, simulate them, and check their relations.Universidad de Málaga. Campus de Excelencia Internacional Andalucía Tech