This documentation is intended for language engineers using or extending the SD languages. A detailed documentation for modelers who use the sequence diagram (SD) languages is located here. We recommend that language engineers read this documentation for modelers before reading this documentation.

Sequence Diagrams (UML/P SD)

The module described in this document defines a MontiCore language for UML/P SDs. UML/P SDs are an SD variant that is suited e.g. for the modeling of tests and (in combination e.g. with OCL) for desired and unwanted behavior interactions. UML/P SDs are defined in [Rum16], [Rum17].

This module contains

two grammars,
context conditions,
a symbol table infrastructure including functionality for creating symbol tables and (de-)serializing symbol tables, and
pretty-printers.

An Example Model

Figure 1: The graphical syntax of an example SD.

Figure 1 depicts the SD bid in graphical syntax. In textual syntax, the SD is defined as follows:

sequencediagram Bid {

  kupfer912:Auction;
  bidPol:BiddingPolicy;
  timePol:TimingPolicy;
  theo:Person;

  kupfer912 -> bidPol : validateBid(bid) {
    bidPol -> kupfer912 : return BiddingPolicy.OK;
  }
  kupfer912 -> timePol : newCurrentClosingTime(kupfer912,bid) {
    timePol -> kupfer912 : return t;
  }
  assert t.timeSec == bid.time.timeSec + extensionTime;
  let int m = theo.messages.size;
  kupfer912 -> theo : sendMessage(bm) {
    theo -> kupfer912 : return;
  }
  assert m + 1 == theo.messages.size;
}

This was for us the most intuitive textual representation of SDs, which was not easy to define, because SDs are inherently two dimensional with their objects, activity bars and interactions in time.

Command Line Usage

The class SD4DevelopmentTool provides typical functionality used when processing models. To this effect, the class provides methods for parsing, pretty-printing, creating symbol tables, storing symbols, and loading symbols.

The class provides a main method and can thus be used from command line. Building this gradle project yields the executable jar MCSD4Development, which can be found in the directory target/libs. The usage of the MCSD4Development tool and detailed instructions for building the tool from the source files are described here.

Grammars

This module contains the two grammars SDBasis and SD4Development.

SDBasis

The grammar SDBasis contains the basic constituents to define textual representations of UML/P SDs. A detailed documentation of the grammar can be found in the artifact defining the grammar.

The grammar SDBasis defines the syntax for

SD artifact,
SD match modifiers (a UMLP extension [Rum16]),
objects, and
interactions for sending messages
including (optional) activity bars.

The grammar SDBasis extends the grammars

[MCBasicTypes][XXX] for adding the possibility to define objects typed as MCObjectTypes, to be able to use symbols of kind Variable, and to enable typechecking. Objects and local variables are added as variable symbols to the symbol table.
BasicSymbols for using symbols of kind Diagram und Variable.
ExpressionsBasis to be able to reuse visitors for typechecking.
UMLStereotype for adding UMLStereotypes as possible extension points to the grammar.

SD4Development

The grammar SD4Development extends the grammar SDBasis with advanced concepts used in object-oriented programming and embeds OCL for defining local variables and stating conditions. A detailed documentation of the grammar can be found in the artifact defining the grammar.

The grammar SD4Development defines the syntax for

method calls,
constructor calls,
returns,
the throw of an exception,
interactions representing the end of method calls,
classes as targets of interactions to model static method calls,
conditions, and
local variable declarations.

The grammar SD4Development extends the grammars

SDBasis to reuse the basic constituents of SDs,
MCCommonLiterals to be able to use common literals in expressions.
CommonExpressions to be able to use simple expressions, e.g. a == b.
OCLExpressions for embedding OCL expressions as conditions and to be able to use OCL expressions for the definition of local variables.
OOSymbols to be able to import OOType Symbols.

Context Conditions

This section lists the context conditions for the SDBasis grammar and the context conditions for the SD4Development grammar.

SDBasis Context Conditions

The implementations of the context conditions for the SDBasis grammar are located here.

The context condition CommonFileExtensionCoco checks if an artifact containing an SD model has the common file ending ".sd" of SD artifacts.
The context condition ObjectNameNamingConventionCoco checks the naming convention for objects in an SD, i.e., every object name is not empty and starts with a lower case letter.
The context condition PackageNameIsFolderNameCoco checks if the package names of SD artifacts corresponds to their actual locations in the file system.
The context condition ReferencedObjectSourceDeclaredCoco checks if used source objects are declared before they are used.
The context condition ReferencedObjectTargetDeclaredCoco checks if used target objects are declared before they are used.
The context condition SDNameIsArtifactNameCoco checks if the names of SDs are equal to the file names of the artifacts containing the SDs.
The context condition SendMessageHasSourceOrTargetCoco checks if SDSendMessage interactions have a source or a target.
The context condition UniqueObjectNamingCoco checks if every object defined in an SD has a unique name.

SD4Development Context Conditions

The implementations of the context conditions for the SD4Development grammar are located here.

The context condition CorrectObjectConstructionTypesCoco checks if the type declared for an object instantiated with an SDNew interaction and the object's initialization type are compatible.
The context condition EndCallHasSourceOrTargetCoco checks if EndCall interactions have a source or a target.
The context condition MethodActionRefersToCorrectTargetCoco checks if a method action refers to a correct target, i.e., that static methods are only called on classes and that all other methods are called on objects.
The context condition MethodActionValidCoco checks if a method action is valid, i.e., whether a method with a corresponding signature is defined for the type of the target of the interaction. The name of the method as well as the number and types of the method parameters must be equal.
The context condition ReturnOnlyAfterMethodCoco checks if return actions only appear after corresponding method calls.

Symbol Table

The SD language uses the build-in symbol types VariableSymbol and DiagramSymbol as well as the type symbol types of MontiCore.

Each SD may define objects. Therefore, SDs may export VariableSymbols containing the information about the name and the type of the object. Possible types for objects are MCObjectTypes. Further, it is possible to dynamically instantiated variables via SDVariableDeclarations by using OCL expressions.
Interactions may call methods of objects. Therefore, for checking whether the types of objects and variables are defined and for checking whether methods used in interactions are defined, SDs may import TypeSymbols and OOTypeSymbols.

Symbol Table Data Structure

Figure 3: The data structure of the symbol table of the SD language.

Figure 3 depicts the symbol table data structure of the SD4Development grammar. The SD4DevelopmentGlobalScope is associated to an SD4DevelopmentArtifactScope for each artifact defining an SD. In each of these artifacts, at most one SD can be defined and each SD introduces a DiagramSymbol. Therefore, each SD4DevelopmentArtifactScope is associated to exactly one DiagramSymbol. The SD4DevelopmentArtifactScope scope contains exactly one subscope, which is spanned by SDBody. The SD4DevelopmentArtifactScope contains a VariableSymbol for each object that is defined inside the SD. The scope spanned by SDBody contains a VariableSymbol for each object that is dynamically instantiated via SDNew and for each variable that is instantiated via SDVariableDeclaration.

Figure 4: The SD defines two objects and dynamically instantiated an object as well as a variable.

Figure 4 depicts the simple example SD Size. The SD defines the two objects kupfer912:Auction and theo:Person. Additionally, it dynamically instantiated the object bm:BidMessage and the variable int m. The following depicts the textual syntax of the SD:

sequencediagram Size {

  kupfer912:Auction;
  theo:Person;

  kupfer912 -> BidMessage bm = new BidMessage(...);
  let int m = theo.messages.size;
  kupfer912 -> theo : sendMessage(bm);
  theo -> kupfer912 : return;
  assert m + 1 == theo.messages.size;
}

Figure 5 depicts the symbol table instance for the SD Size. Figure 5 abstracts from the SD4DevelopmentGlobalScope instance. The two objects kupfer912:Auction and theo:Person correspond to the VariableSymbol instances linked to the SD4DevelopmentArtifactScope. The object :DiagramSymbol is linked to the SD4DevelopmentArtifactScope and has the same name as the SD defining the symbol. The dynamically instantiated object bm:BidMessage and the variable int m correspond to the VariableSymbols of the SD4DevelopmentScope, which is introduced by SDBody.

Figure 5: Symbol table instance of the SD depicted in Figure 3.

The handwritten extensions of the scopes genitor of the SDBasis grammar can be found in the class SDBasisScopesGenitor. The handwritten extensions of the scopes genitor of the SD4Development grammar can be found in the class SD4DevelopmentScopesGenitor. Instances of class SD4DevelopmentSymbolTableCompleter are responsible for calculating the type attributes of variable symbols and, thereby, for checking whether used types are defined.

Symbol kinds used by the SD language (importable or subclassed):

The SD language uses symbols of kind TypeSymbol, VariableSymbol, and DiagramSymbol as well as the symbols that are used by these symbols (e.g. FunctionSymbol is used by TypeSymbol).

Symbol kinds defined by the SD language (exported):

None.

Symbols imported by SD models:

SDs import VariableSymbols. The objects represented by imported VariableSymbols can be used as sources or targets of interactions.
SDs import TypeSymbols. The imported types can be used as types for objects and variables introduced via inline declarations.

Symbols exported by SD models:

SD models export VariableSymbols. For each object defined in an SD, the SD exports a corresponding VariableSymbol.
Each SD exports exactly one DiagramSymbol corresponding to the SDArtifact.

Serialization and De-serialization of Symbol Tables

The SD language uses the DeSer implementations as generated by MontiCore without any handwritten extensions. The objects that are dynamically instantiated with interactions via SDNew interactions and the local variables introduced via SDVariableDeclaration by using statements are not exported (they are defined in an unnamed inner scope introduced with SCBody). Therefore, the corresponding variable symbols are not serialized, i.e., they are not part of the corresponding symbol file. For example, the following depicts an excerpt of the symbol file obtained from serializing the symbol table instance depicted in Figure 4:

{
  "name": "Bid",
  "package": "examples.correct",
  "kindHierarchy": [
    [
      "de.monticore.lang.sd4development._symboltable.FieldSymbol",
      "de.monticore.symbols.basicsymbols._symboltable.VariableSymbol"
    ],
    [
      "de.monticore.lang.sd4development._symboltable.TypeVarSymbol",
      "de.monticore.symbols.basicsymbols._symboltable.TypeSymbol"
    ],
    [
      "de.monticore.lang.sd4development._symboltable.MethodSymbol",
      "de.monticore.symbols.basicsymbols._symboltable.FunctionSymbol"
    ],
    [
      "de.monticore.lang.sd4development._symboltable.OOTypeSymbol",
      "de.monticore.symbols.basicsymbols._symboltable.TypeSymbol"
    ]
  ],
  "symbols": [
    {
      "kind": "de.monticore.symbols.basicsymbols._symboltable.VariableSymbol",
      "name": "kupfer912",
      "type": {
        "kind": "de.monticore.types.check.SymTypeOfObject",
        "objName": "Auction"
      },
      "isReadOnly": false
    },
    {
      "kind": "de.monticore.symbols.basicsymbols._symboltable.VariableSymbol",
      "name": "theo",
      "type": {
        "kind": "de.monticore.types.check.SymTypeOfObject",
        "objName": "Person"
      },
      "isReadOnly": false
    },
    {
      "kind": "de.monticore.symbols.basicsymbols._symboltable.DiagramSymbol",
      "name": "bid"
    }
  ]
}

Further Information

Project root: MontiCore @github
MontiCore documentation
List of languages
MontiCore Core Grammar Library
Best Practices
Publications about MBSE and MontiCore
Licence definition

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sd4development.md

sd4development.md

Sequence Diagrams (UML/P SD)

An Example Model

Command Line Usage

Grammars

SDBasis

SD4Development

Context Conditions

SDBasis Context Conditions

SD4Development Context Conditions

Symbol Table

Symbol Table Data Structure

Symbol kinds used by the SD language (importable or subclassed):

Symbol kinds defined by the SD language (exported):

Symbols imported by SD models:

Symbols exported by SD models:

Serialization and De-serialization of Symbol Tables

Further Information

Files

sd4development.md

Latest commit

History

sd4development.md

File metadata and controls

Sequence Diagrams (UML/P SD)

An Example Model

Command Line Usage

Grammars

SDBasis

SD4Development

Context Conditions

SDBasis Context Conditions

SD4Development Context Conditions

Symbol Table

Symbol Table Data Structure

Symbol kinds used by the SD language (importable or subclassed):

Symbol kinds defined by the SD language (exported):

Symbols imported by SD models:

Symbols exported by SD models:

Serialization and De-serialization of Symbol Tables

Further Information