Programming without programming
The Scenario-Design Language enables designers (TODO good role description?) to specify (distributed) system behaviors without writing code. These specifications are run as models at runtime on the target systems. This execution is done by ScenarioTools (TODO see ScenarioTools-group description or the ScenarioTools website).
How are behaviors specified?
Scenarios are specified like children understand children’s picture books: These books contain images that themself contain several situations. Imagine a picture of a farm: In one corner a dog chases a cat. In the center the farmer feeds chicken and so on. Such a picture describes what happens on a farm. Creating an intuitiv way to model system behaviors like in such picture books, motivated the Scenario-Design Language:
Eight steps are executed until a specification is done:
- Drawing the specified situation onto a whiteboard or similar.
- Specifying the involved objects into a formal object system.
- Split the Situation in smaller parts
- From the illustration and the collaboration we can split the situation in smaller parts to get a better overview.
- Part 1: Sequence of the red car
- Part 2: Sequence of the blue car.
- Part 3: Car informs driver.
- Finding out which messages are exchanged between which objects.
- From the object system and the situations we derive communication channels and messages between the cars.
- The car communicates with the driver.
- The car communicates with the construction site.
- The Environment sends messages to the car.
- The construction site mediates between car.
- Describing the situation informally in flowing text.
- To formalise a formal specification we need to specify all situations informally first. This gives a better understanding of the situation.
- Modelling the domain.
- For a formal specification a domain model is needed.
- This model describes all needed classes and functions for our system and environment objects. Also the communication channels between the objects are modeled here.
- We only model functionality, but not the sequential execution.
- In further iterations there can still be changes in the domain model to fit more functionality. So the extensibility is very important.
- Splitting the part situations into several small scenarios, that are easier to model.
- Some sequences of events can occur more often than others. Those sequences can be described in their own scenario to make the main scenarios smaller.
- Formalizing these scenarios into the Scenario-Design Language.
- Since the situation is informally described and the domain model is created, we can begin with the formal specification.
- We use the specification language Scenario Design Language (SDL). SDL builds on the semantics of the Modal Sequence Diagrams (MSD) and allows us to specify scenarios textually.
- These scenarios can be executed in an runtime environment using a play-out algorithm.
- Testing the specification.
What is SDL?
The Scenario-Design Language offers ways to define roles (similar to classes in object oriented programming) and objects that fill these roles. For example you can specify the role “car” which is filled by several concrete car objects. These objects can be involved in different scenarios or be at different positions.
For a detailed description of Scenario-Design Language see ScenarioTools.org. (At the time of writing the site still describes MSDs instead of SDL so check back soon if you cannot find SDL there.)
What are the results?
The output of this project group is three scenarios:
- A car driving on a free lane alongside a construction site.
- A car driving on a lane blocked by a construction site.
- Two cars driving on different lanes, ohne blocked by a construction site.
You can see the results in the video or on the site of the demonstrator group.