Evolution of the UML Interactions Metamodel

Abstract

Abstract. UML Interactions represent one of the three different behavior kinds of the UML. In general, they specify the exchange of messages among parts of a system. Although UML Interactions can reside on different level of abstractions, they seem to be sufficiently elaborated for a higher-level of abstraction where they are used for sketching the communication among parts. Its metamodel reveals some fuzziness and imprecision where definitions should be accurate and concise, though. In this paper, we propose improvements to the UML Interactions' metamodel for Message arguments and Loop CombinedFragments that make them more versatile. We will justify the needs for the improvements by precisely showing the shortcomings of the related parts of the metamodel. We demonstrate the expressiveness of the improvements by applying them to examples that current Interactions definition handles awkwardly.

Behavior Modeling with Interaction Diagrams in a UML and OCL Tool

“…In [13], the synthesis of test cases from UML interaction diagrams by a systematic interpretation of flow of controls is discussed. Improvements to the UML interaction metamodel concerning message arguments and loops are proposed and demonstrated in [18]. The approach in [10] is strongly related to the USE approach because of the emphasis on protocol modeling.…”

Scenario-based specification of security protocols and transformation to security model checkers

“…As motivated in the introduction, scenario-based notations comprehensibly represent message-based interaction requirements, and UML Interactions [30,Clause 17] provide such a notation as a visual modeling language by means of the notion of sequence diagrams. However, UML Interactions lack precise semantics regarding universal/existential properties [17] and provide no adequate modeling constructs for the specification of temporal variables and of references to them or to parameter values [35]. The latter point leads to the problem that one cannot specify conditional behavior that depends on the values of temporal variables (typically storing computation results) or on parameter values (e.g., "if (<someComputationResult> ≥ <someValue>) then <someMessage-Sequence> else <anotherMessageSequence>").…”