Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
Method for definition of scenarios
RCAMT-704
-
Extent method page for scenarios
Finished
Table of content
- 1. Overview
- 2. General guidance for a scenario
- 3. Applicability
- 3.1. Specific guidance for scenarios applicable at the operational analysis
- 3.2. Specific guidance for scenarios applicable at the system analysis
- 3.3. Specific guidance for scenarios applicable at the logical architecture
- 3.4. Specific guidance for scenarios applicable at the subsystem architecture
1. Overview
The system is designed to carry out missions that require a set of capabilities in order to be accomplished. Each of these capabilities is described by a sequence of functions that use dependencies between them in a given context. Depending on the implementation conditions (pre and post-conditions), it can be formalised in different ways, in particular via scenarios (or functional chains described in Method for definition of functional chains). The scenario adds a chronological dimension and focuses mainly on the temporal positioning of the activity of the functions and their exchanges. It can be described by placing exchanges on a time axis or by precedence links between functions. Beware, these links are only intended for contextualisation of capabilities and should not be confused with functional exchanges. Their purpose is to represent, at least, one complete sequence of functional exchanges (output of a function of interest) that is navigable from the start conditions to the end conditions. There are alternative terms often used for scenarios like interactions (e.g. in SysML v1) or sequence diagram as its common graphical notation. Here the term scenario is used in context of this method.
2. General guidance for a scenario
Scenarios are used in each level of the model, but the possibilities of representation are similar.
2.1. Definition of the concepts
2.1.1. Main concepts
- Lifeline: it is the representation of an existence of a model element that participates in the scenario. It has the same name that the model element referenced and is represented graphically with a dotted vertical line. In the case of exchange scenarios, lifelines are the system/actors/components.
- Performed behaviour: Blocks displayed in a scenario on a lifeline are called "performed behaviours" and represent functions (or activities). They can only be created to represent functions that already exist, so it is helpful to have other diagrams opened where you can create new functions (or activities) and functional exchanges if you need them (like a SDFB at the system level). When they are deleted, they do not delete the element they represent. They are placed on a lifeline preceding incoming and/or outgoing messages and their outputs change in line with changes to their inputs.
- Message: it is a unidirectional exchanged item between lifelines that triggers a behaviour in the receiver. In the case of exchange scenarios, messages are functional exchanges.
- Execution element: This can be a label with a shape of a rectangle notating the time in which a performed behaviour is actually active. This is the case for example for an incoming message as long as the duration in which the outputs of a performed behaviour can change within a lifeline. This means as long as new messages with a changed value to another lifeline are happening as depicted in the scenario.
Note: The representation of a function as a performed behaviour is done only if it had value for the reader.
2.1.2. Control sequence
Some combined fragments can be defined as areas to express different cases and changes:
- OPT: used when a message takes place under certain conditions with no alternative. It is a representation of the common "if".
- LOOP: used when a sequence needs to have iterations under certain conditions.
- PAR: used if at least two messages occur in parallel which means that there is no implied order between occurrences in the different operands
- ALT: usually this possibility should not be needed since alternative paths are usually modelled in separate scenarios. But in several cases, it can represent the "if-then-else" construction of messages, under certain conditions (which must be mutually exclusive) with alternative messages.
- REF: used to reduce the complexity of a scenario within one capability, it should be well justified and really only used where it makes sense. Also, the reference object must be laid on the diagram in such a way those non-involved lifelines are not covered by the reference object.
Note: where possible, guard conditions should be expressed in terms of the states of entities, actors or abstract concepts.
2.1.2.1. If a capability includes another capability
When one capability includes another capability with the "include"-relationship then the scenarios of the included one are referenced using the REF combined fragment. No lifelines in the scenarios are shown which do not have any interaction which another lifeline. If another scenario is referenced where the omitted lifeline is then involved, its involvement is only shown in the referenced one, but not the referencing one (done for practical reasons and tool constraints deviating from common practice (e.g. SysML) to show every lifeline involved in the capability (i.e. the including capability and the included one)).
2.1.2.2. If a capability extents another capability
When one capability extents another capability with the "extent"-relationship then the scenarios of the extended one are referenced using the REF combined fragment and OPT combined fragment. The OPT fragment includes the condition when the extension is applicable. No lifelines in the scenarios are shown which do not have any interaction which another lifeline. If another scenario is referenced where the omitted lifeline is then involved, its involvement is only shown in the referenced one, but not the referencing one (done for practical reasons and tool constraints deviating from common practice (e.g. SysML) to show every lifeline involved in the capability (i.e. the including capability and the included one)).
2.1.3. Pre and postconditions
The owning capability has conditions and if they are fully applied to the scenario, then they should appear. It is possible and allows to add additional pre- and postconditions in the scenario to refine or have more concrete and specific constraints. Nevertheless, in some cases, the conditions of the owning capability do not apply to the scenario. If it appears, then we have to mention it in the scenario to warn the users.
2.1.4. Invariants for states
Statements about modes and states (called "state invariants") can be displayed in a scenario to express the current state of a lifeline or a change as a result of an interaction. Invariants express some conditions of the lifeline at a certain point of time of the scenario. Dependent on the tool, a state invariant can be shown on the lifeline refering to a state of a state machine (e.g. of the structural entity). State changes of entities/actors (i.e. by their state machines) should be visualised on the lifelines using the provided tool, to aid understanding; this is not mandatory but is helpful to the reader. Be careful, the trigger of the state transition should be consistent with the interaction depicted in the scenario.
Note: if there is no state or specific conditions in the scenario, it is assumed that the function is "always-on" or at least "always-on in a particular system state".
2.1.5. Exchange content
It is used to illustrate the content of a message and it is displayed as a constraint linked to the message.
2.1.6. Summary of the concepts
The picture below provides a global view with all the mentioned concepts:
3. Applicability
Scenarios are suitable to be used for the following model elements:
- regarding abstraction levels: operational level, system level, logical level, physical level
- regarding structural entities: system, subsystem, logical component, interface layer component
- regarding functions: behaviour definition of function (how functions of structural entities exchange data through exchange items)
- regarding other behavioural aspects: pre and postconditions and invariants as start ot end condition as well as state invariants of the scenario
- regarding purpose: represent, at least, one complete sequence of functional exchanges on a time axis
3.1. Specific guidance for scenarios applicable at the operational analysis
3.1.1. Purpose of the operational exchange scenarios
At the operational layer, scenarios describe the behaviour of entities and operational activities in a context of an operational capability with a vertical axis representing time. They should be used to:
- Visualise a sequence of activities, derived from operational needs with or without risk control measures.
3.1.2. Guidance
For a specific scenario, if the person creating it knows enough about how the system works with actors, then he can create the sequence directly with his own knowledge. If it is necessary to gather information from others, we should gather people to represent the concerns of all the involved actors and functional areas of the system. A brainstorming workshop should be held to identify sufficient external interactions to get from the starting conditions to the ending conditions.
The table below indicates the correspondance between the concepts of a generic scenario and the concept used at operational layer:
Scenario main concepts | Adaptation to operational layer |
---|---|
Lifelines | Operational entities |
Performed behaviours | Activities |
Messages | Interaction |
Note: for the lifelines, operational entities should be chosen with care. The entities "wider environment", "environment", and "wider system of interest/WSOI" should not normally be used - these entities exist to provide some categories for other entities and actors, not to be treated as a real interacting thing. Use the most specific possible operational entities given the known responsibilities. Where an operational entity represents an organisation, and there are some operational actors inside it, but it is not clear which of them has a particular involvement in a scenario, then it is appropriate to use the operational entity itself (this is analogous to saying "we know this organisational unit has a responsibility, but we don't know precisely which role within that unit is actually going to do it".
3.2. Specific guidance for scenarios applicable at the system analysis
3.2.1. Purpose of the system exchange scenarios
At the system layer, scenarios describe how the system and the actors interact in the context of a system capability with a vertical axis representing time. They should be used to:
- Visualise an initial sequence to achieve a system capability's outcome.
- Visualise interactions between entities to achieve the system capability with an acceptable level of risks.
- Describe an interface layer (e.g. a protocol) that is a constraint on the system.
- Visualise system black-box behaviour or system interaction behaviour with actors.
3.2.2. Guidance
For a specific scenario, if the person creating it knows enough about how the system works with actors, then he can create the sequence directly with his own knowledge. If it is necessary to gather information from others, we should gather people to represent the concerns of all the involved actors and functional areas of the system. A brainstorming workshop should be held to identify sufficient external functional exchanges to get from the starting conditions to the ending conditions. Be careful about the number of internal exchanges (functional exchanges between pairs of functions that are both allocated to the System of Interest), it should be kept to a minimum.
The table below indicates the correspondance between the concepts of a generic scenario and the concept used at system layer:
Scenario main concepts | Adaptation to system layer |
---|---|
Lifelines | System/Actors |
Performed behaviours | System functions |
Messages | Functional exchanges |
Note: where behaviour is expected of an actor in order to reach the end conditions of a system capability, actor functions should be modelled, but these can be captured at a more abstract/placeholder level than the system functions.
3.2.2.1. Particular case of external interface behaviour
In some cases, it is possible that that there is a need to model interface-specific behaviours. For example, any sequences associated with link setup/closure, link management, error detection/correction, etc. In these cases, a segregation these scenarios to only model on one interface layer at a time is needed (see Method for definition of system interfaces to find more guidance and rules). The following picture describes an example of the basic concept of interface-specific behaviours:
3.3. Specific guidance for scenarios applicable at the logical architecture
3.3.1. Purpose of the logical exchange scenarios
At the logical layer, scenarios describe how the logical components and the actors interact in the context of a realised system capability with a vertical axis representing time. They should be used to:
- Visualise interactions between and within logical components to reveal potential weaknesses in the logical architecture.
- Describe an interface layer (e.g. a protocol) that is a constraint on the system.
- Visualise system black-box behaviour or system interaction behaviour with actors.
3.3.2. Guidance
No model element should be created or added in a scenario of this layer. The Exchange Scenario diagram only displays model elements that already exist. The process of creating the Exchange Scenario diagram is intended to reveal missing or superfluous functional exchanges or weaknesses in decomposition. The table below indicates the correspondance between the concepts of a generic scenario and the concept used at the logical layer:
Scenario main concepts | Adaptation to logical layer |
---|---|
Lifelines | Logical components/Logical actors |
Performed behaviours | Logical functions |
Messages | Functional exchanges |
Note: It is possible that functional exchanges have different start/end components based on their configurations. An example would be the Grade of Automation (GoA). In such a case the system capability may have to be modeled as a set of variants. The variants then have different scope definitions for the system functionality. If the set of variants is not an option, then such functional exchanges should be modeled within the usual logical fragments (ALT, PAR etc.).
3.4. Specific guidance for scenarios applicable at the subsystem architecture
3.4.1. Purpose of the physical exchange scenarios
At the physical layer, scenarios describe how subsystems interact with other subsystems or actor / external systems. They should be used to:
- Visualise subsystem black-box behaviour or subsystem interaction behaviour with actors (or external systems) or other subsystems.
- Describe interface layer black-box behaviour (e.g. of a protocol) between interface layer components which is then part of the overall subsystem behaviour.
- Describe subsystem exchanges.
3.4.2. Guidance
In this process step only additional model elements shall be created or added if necessary which means that the exchange scenarios only display model elements that already exist (e.g. functional exchanges) or required new ones on physical level.
The table below indicates the correspondance between the concepts of a generic scenario and the concept used at the physical layer:
Scenario main concepts | Adaptation to physical layer |
---|---|
Lifelines | Logical components/Subsystems/ Physical Actors |
Performed behaviours | Physical functions |
Messages | Functional exchanges |
3.4.2.1. Guidance for interface layer exchange scenario
These interactions are a way to define behaviour in a black-box style where only exchanges between them are visible and in which order over time. Interface layer components serve as lifelines in the exchange scenario. As a consequence, the functional exchanges in the exchange scenario are displayed between interface layer components.
The purpose of creating the exchange scenarios is also to reveal missing or superfluous functional exchanges or weaknesses in decomposition. In addition, the task is also to generate exchange scenarios which illustrate the complete set of functional exchanges that are required to achieve consistent exchange of data.
In this process step, no additional model elements shall be created or added which means that the exchange scenarios only display model elements that already exist (e.g. functional exchanges).