SML Semantic

import

import "model.ecore"

Make the ecore packages that are contained in the file model.ecore available as domain packages (see below).

specification

system specification SystemSpec{ ... }

This defines the specification body. Each specification is made up of scenarios that are grouped into usecases.

domain

domain mydomain

States that the ecore package mydomain is used as a domain model in this specification.

System-Environment partition

define Controller as controllable
define TableSensor as uncontrollable

Controller and TableSensor are classes from the productioncell meta model. The controller should be part of the system and is hence declared as controllable. The sensor on the other hand is part of the environment and therefore is uncontrollable. A class cannot be both uncontrollable and controllable.

UseCase.

usecase ProductionCellIntegrated{}

Holds the description of one usecase

role

static role TableSensor ts
dynamic role Press availablePress

Usecases do not refer to objects to carry out procedures. Instead they declare roles that are assumed, or played, by objects over the time of a system run. An object may assume a role, if it's type is equal to, or a subtype of the role's type. For example a cat may assume the role "Animal pet", but a ginkgo may not, because it is not an animal. If a role is always played by a particular object, it should be declared static. Otherwise, it should be declared dynamic. Dynamic roles can, in principle, be played by any object, as long as it's type is fitting. However, it is also possible to impose so called role binding constraints, limiting which objects may play a dynamic role.

scenarios

A scenario models an exchange of messages or, more general, information between objects. There are three kinds of scenarios, specification scenarios, requirement scenarios and assumption scenarios. The terminology is based on the ideas of Zave & Jackson.

specification scenarios

Specification scenarios define the behaviour of the designed system(...)

requirement scenarios

(...)

assumption scenarios

Assumption scenarios state knowledge about the behaviour of the environment. As the environment cannot be controlled, it would be possible for it to send any message at any time to the system, which makes consistency checking and simulation impossible. In order to solve this problem, the designer must define assumptions about how the environment will actually behave. By defining assumption scenarios, she can limit the possible environment behaviour to the actual behaviour. However, it is of critical importance, that no over-optimistic assumptions are stated. An assumption is over-optimistic, if it states that some event will not happen, although it is possible to happen in the real world. For example, the assumption "A pedestrian will only cross the street while the traffic light is green" is over-optimistic(?).

scenario assumption s1{ }

A description of behavior for the environment.

scenario requirement s1{ }

A description of behavior for the system.

message

message cold  monitored  ts -> c.blankArrived()
message hot   monitored  ts -> c.blankArrived()
message cold  executed   ts -> c.blankArrived()
message hot   executed   ts -> c.blankArrived()

A message is send from ts to c. ts calls the blankArrived() method from c.
hot and cold describes the behavior in case of violation.
+ hot means safety violation and ends the simulation
+ cold means cold violation and exits the scenario.
executed and monitored describes the importance of an message in simulation for execution. The simulation consider if the sender is an environment or system object.
In case of an system object:
+ execute means the system must execute the message
+ monitored means the system may execute the message
In case of an environment object:
+ execute means the environment mast execute the message when the system is ready
+ monitored means the environment may execute the message when the system is ready

Wiki

scenariotools-sml / SML Semantics