Required behavior of sequence diagrams

Abstract

Many reusable software artifacts such as design patterns and design aspects make use of UML sequence diagrams to describe interaction behaviors. When a pattern or an aspect is reused in an application, it is important to ensure that the sequence diagrams for the application conform to the corresponding sequence diagrams for the pattern or aspect. Reasoning about conformance relationship between sequence diagrams has not been addressed adequately in literature. In this article, we focus on required behaviors specified by a UML sequence diagram and provide a semantic-based formalization of conformance relationships between sequence diagrams. A novel trace semantics is first given that captures precisely required behaviors. A refinement relation between sequence diagrams is then defined based on the semantics. The refinement relation allows a sequence diagram to be refined by changing its structure so long as its required behaviors are preserved. A conformance relation between sequence diagrams is finally given that includes the refinement relation as a special case. It allows one to introduce and rename lifelines, messages, and system variables when reusing sequence diagrams. Properties of the semantics, refinement, and conformance relations are studied. Two case studies are provided to illustrate the efficacy of semantic-based conformance reasoning. ACM Reference Format:Lunjin Lu and Dae-Kyoo Kim. 2014. Required behavior of sequence diagrams: Semantics and conformance.

Equivalence of Denotational and Operational Semantics for Interaction Languages

“…Most formal approaches rely on translations towards other formalisms [3] or consist in denotational semantics [23] that are most often based on partial order sets. The extent to which UML-SDs are formalised may vary [17]: some works formalize loops [12], others do not [9], and some only allow finitely many iterations [23]. In all cases where there are loops, only one loop operator is proposed and may correspond to either loop H or loop W .…”

A structural operational semantics for interactions with a look at loops

“…As mentioned in the introduction, most approaches rely on translations towards other formalisms [3] or consist in denotational semantics [19] that are most often based on partial order sets. The extent to which UML-SDs are formalised may vary [15]; some works formalize loops [10], others do not [7], and some only allow finitely many iterations [19]. In all cases where there are loops, only one loop operator is proposed and may correspond to either loop H or loop S .…”