Modeling

ScenarioTools supports the modeling of MSD specifications via the Papyrus UML editor in Eclipse and a number of extension to Papyrus and UML. Furthermore, we support a modeling scheme where the MSD specification can be modularized in packages, for example one package per use case. This allows us for example to flexibly re-compose specification parts to model variants. The modeling scheme and tools are briefly described in the following.

Papyrus and UML Extensions

ScenarioTools extends UML via a profile that for example adds temperature and execution kind attributes for messages and allows users to mark MSDs as assumptions. The Papyrus editor is extended by a plug-in that colors hot messages red and cold messages blue, and renders monitored messages as a dashed arrow instead of a solid arrow for executed messages. The figure below shows a screenshot of the MSD editor. Below the diagram editor, the property view shows the additional attributes that the Stereotype ModalMessage supplies for messages.

Modeling Specifications of Static Systems

MSD specifications can be modeled for static systems and dynamic systems. Static systems are systems that consist of a fixed, predefined number of objects, for example the production cell. Dynamic systems are systems for which many different possible instance exist, and where the communication relationships between objects can change, for example the RailCab system (see the previous page for more information). MSD specifications are modeled differently for these two kinds of systems.

The two figures below shows the ScenarioTools modeling scheme for static systems for the production cell example. The first figure overviews the possible package structure: First, a base package specifies the structure of the system by a a class diagram and a collaboration diagram (composite structure diargam). Then the interaction behavior of the system can be specified by MSDs in different packages that merge the base package. This allows us to model different use cases, concerns, or features in separate packages.In this example, the MSDs concerning the arm A, the press, and arm B of the production cell are modeled in separate packages. Finally, to create a specification that contains all or a subset of these part specifications, these are merged into an integrated package.

The following figure shows in more detail the contents of the base package and the contents of the Press package where the behavioral concerns of the Press are specified. Note also that the messages are typed over operations defined in the classes of the receiving object.

Modeling Specifications of Dynamic Systems

The ScenarioTools modeling scheme for dynamic systems is shown in the two figures below. First, optionally, a base package can be specified that contains a class model of the system. In the RailCab example, we can for example model the basic structure: a RailCab has a current track section control, a track section control can have a next track section control, etc (see second figure below). Then, the behavior of the system is specified in further packages that merge the base package, and, finally, an integrated package again merges all these packages.

The packages that specify the behavior contain MSDs where the lifelines bind dynamically to objects in an object system. (We explain shortly how to model a concrete object system.) We advocate the following modeling scheme: We propose that each use case is modeled in a separate package. Use cases typically refer to a specific situation within a bigger, dynamic system and describe how the objects play different roles in this situation to achieve the desired functionality. The behavior is then described by one or multiple scenarios.

Therefore, a package that contains the specification of a use case should have the following structure: First, the package can specify additional classes or additional attributes, associations, or operations for classes that are already specified in the base package or other depending use case specification packages. Second, the package contains a collaboration (composite structure) that defines the roles participating in the use case and, optionally, their communication channels. Third, for the specification of the behavior, the package contains MSDs where the lifelines refer to the roles in the collaboration.

The advantage of this modeling scheme is that the use case specification package can also be considered as an MSD specification for a static system, as explained above. Then, synthesis techniques can be applied more efficiently to check the consistency of a single use case specification. (Click here for more information).

The UML package merge merges packages so that classes, attributes, associations, and operations with the same name in merged package are merged into the same element in the merging package. The figure below illustrates this.

The figures below show the package overview diagram, class diagram, and a collaboration diagram of the production cell example in the Papyrus editors. See that ScenarioTools also provides an extra stereotype for roles, which allows the user to specify whether a role represents an environment or system object.

Configuring Executable Specifications

In order to simulate MSD specifications or to synthesize controllers from MSD specifications, we require a concrete object system, which, however, is not explicitly defined in the case of an MSD specification for dynamic systems. ScenarioTools uses the Eclipse Modeling Framework (EMF) to allow users to create concrete instance models, based upon which the MSDs can then be interpreted. We also call this the execution object model. The figure below illustrates this process: (1) The specification of a dynamic system is created as explained above. (2) The class model in the packages is merged and transformed into an ECore (class) model. (3) from this class model, the user can create an object model. (4) Based on this object model, the MSDs are then interpreted for simulation (i.e., play-out) or controller synthesis.

For this interpretation of the MSDs in an EMF object model, it is crucial to know which MSD lifeline can bind to which object. An MSD lifeline represents a role and thus indirectly refers to a UML class that types the role. But how do we find out whether an object in the EMF object model is, conceptually, an instance of this class? To determine this, we interpret the UML-to-ECore mapping, which maps ECore classes to UML classes, and thus bridges this gap.

The same principle applies also when interpreting an MSD specification for a static system. The only difference is that in this case, there exists only one possible execution object model, and lifelines do not bind dynamically to the objects, but the binding is predefined. For this reason, in addition to the steps above, also a role-to-object mapping is created.

ScenarioTools supports the user in the automated generation of the ECore class model, the UML-to-ECore mapping. In the case of a dynamic system, the user creates the execution object model manually. In case of a specification for a static system, the execution object model and the role-to-object mapping can also be created automatically.

All the involved models can be stored in different file. The user can create a configuration model, called the scenario run configuration, to specify which models belong together. The figure below shows a screenshot of the files created in this process.