Model precise scenario-based specifications in Eclipse, using our Scenario Modeling Language (SML).
The Scenario Modeling Language (SML; formerly Scenario Design Language, SDL) is a formal textual domain specific language created with the Xtext framework for designing system specifications. It provides a user friendly editor with syntax highlighting and syntactic and semantic helper functionality. The modeling scheme and tools are briefly described in the following example.
The System Specification
The start of a specification consists of one or more import statements for importing Ecore files and their packages and models to build the specification on. You can import any Ecore file in your workspace.
Next you select packages from those imported model files to use as domains of your system.
From these domains you can choose which classes from your domains shall be controllable and uncontrollable. This distinction defines the system borders of your specified system. Controllable classes are part of your system – the part for which you want to specify required behavior. Uncontrollable classes are part of the environment – the classes whose behavior you can only make assumptions for.
Since you have defined your system borders, now you can select a set of operations from the defined classes that are non-spontaneous. We call operations of classes events or messages because they are used as communication fragments between roles. Non-spontaneous events are events that can not occur randomly, but are specified in some scenario. All other events could be sent from the environment at any time and situation.
Finally comes a set of collaborations containing all the desired system behavior.
The Collaboration
The collaboration contains a set of roles that have a collaborative behavior specified by certain scenarios.
A role is a part of the system or the environment that has a specific behavior that consists of communication with other roles from its collaboration. A role can either be static or dynamic. Static roles can be bound to one specific object in the object system of the runtime environment. It is a fixed role that can not be played by every object. Dynamic roles can be dynamically bound to any objects that is compatible with the class of the role during runtime. Multiple objects can play this role.
In a scenario you specify the desired system behavior. There are three types of scenarios:
- Requirement scenario: This is a high-level requirement … TODO
- Specification scenario: In this scenario you specify the required system behavior.
- Assumption scenario: This scenario is for modeling the behavior of the environment. These assumptions are used to simulate the behavior of the real environment for the simulation and synthesis algorithms.
The scenario is consists of a list of messages. While active the messages have to occur in the order the scenario specifies them. If the order is violated, the system shuts off or the scenario becomes invalid, depending on the modalities of the violated message.
A message can be strict or not strict. If it is strict then there must not be another message from the same scenario occurring while the system is waiting for the strict message. If it is not strict and another message from the scenario violates the message, the scenario becomes invalid. A Message can also be requested or not requested. If it is requested the system has to make sure the message occurs eventually. If it does not occur, the liveness property of the system is violated. Messages can also be parameterized and you can specify different behavior for various parameters.
You can not only specify messages in scenarios, but also loops, alternatives and parallel messages for further modelling possibilities.
You can also define variables in the scenarios and use them as counters for loops or as parameters for messages.