Using UML Action Semantics for Executable Modeling and Beyond

Abstract

Abstract. Software developers spend most of their time modifying and maintaining existing products. This is because systems, and consequently their design, are in perpetual evolution before they die. Nevertheless, dealing with this evolution is a complex task. Before evolving a system, structural modifications are often required. The goal of this kind of modification is to make certain elements more extensible, permitting the addition of new features. However, designers are seldom able to evaluate the impact, on the whole model, of a single modification. That is, they cannot precisely verify if a change modifies the behavior of the modeled system. A possible solution for this problem is to provide designers with a set of basic transformations, which can ensure behavior preservation. These transformations, also known as refactorings, can then be used, step by step, to improve the design of the system. In this paper we present a set of refactorings and explain how they can be designed so as to preserve the behavior of a UML model. Some of these refactorings are illustrated with examples.

Human Comprehensible and Machine Processable Specifications of Operational Semantics

“…We recycled the idea of using OCL for expressive model navigation in our approach. In [12] Gerson Sunyé et al explore the possibility of UML action semantics [13] to create executable UML models and already suggest the use of activities with action semantics for meta-modelling.…”

Designing and Weaving Aspect-Oriented Executable UML Models.

“…Sunyé et al [30] presented a framework for modelling aspect-oriented applications. It serves to construct aspect-oriented executable models, but the weaving is postponed until the implementation phase and thus, the execution of the complete model, including aspects, is not possible at modelling time.…”

Refactoring OCL annotated UML class diagrams

“…The refactoring of artifacts that are more abstract than implementation code is a relatively new research topic that became urgent with the success of the UML. Some initial catalogs of refactoring rules for UML diagrams are presented in [2,31,33]. However, neither these catalogs nor any of the existing UML refactoring tools [8,9,29] support -apart from some simple Rename-refactorings -the refactoring of attached OCL constraints once the underlying UML class diagram has changed.…”

“…Unlike other approaches that describe refactoring rules formally [12,15,31,33], we do not use OCL pre-/postconditions for this purpose. The formalism of our choice is the graph-grammar inspired notation proposed by the QVT Merge Group in an early submission for the OMG standard Query/View/Transformation (QVT) [25].…”