Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
ARCH.M.020 Method for definition of behaviour
- [DRAFT] Set of examples
- Method for definition of actions
- Method for definition of behavioural constraints
- Method for definition of functional chains
- Method for definition of lookup tables
- Method for definition of scenarios
- Method for definition of state machines
- Method for definition of truth tables
This page contains a collection of what has been defined so far including realisation options and examples. It is intended to extend and improve this method further.
Overview
This overall method for the definition of behaviour consists of a set of different methods to cover different kinds of behaviour definitions.
Behaviour definitions are intended to describe what a considered entity does or how it behaves. They can be expressed and modelled in a more formal way (e.g. semi-formal) with increased mathematical precision and are a basis for functional requirements. Together with the approach of model-derived requirements for specification documents these functional requirements a then spelt out as e.g. textual requirements. The behaviour definitions are also used by simulations where the simulation provides a prototypical implementation of them.
Characteristics
The approach of behaviour definitions is to focus on a more formal definition of what should be achieved rather than how it should be done. This means in general that with every behavioural model and modelling language chosen, the goal is to express a behaviour definition focussed on the problem to solve rather than an abstract solution like a prototypical implementation of it. In more practical words, a specification (what, declarative) is not equal to an abstract prototypical implementation and execution (how, imperative). Therefore instead of giving an implementation or strategy which would look like code for computing outputs based on inputs, behaviour definitions provide rules for checking that correct outputs based on the inputs are provided. A prototypical implementation would be done by e.g. simulation following the behaviour definition.
A simple example is the following situation:
- A behaviour definition should not include some concrete or arbitrary sorting algorithm, but instead a formal definition of a constraint that the outgoing list of items is sorted from small to big. This means if there is a sorting function defined that sorts a list of numbers in ascending order it is only necessary to specify that the constraint "element[n] <= element[n+1]" of the then sorted list is always true. In a simulation environment like Simulink then it would be then required to specify a suitable sorting algorithm which satisfies this constraint and would already be a solution. Therefore a simulation is extremely helpful for validating and trying things out. But at least for more complex problems, it is not pure requirements anymore.
Guidance
Before performing steps to define the behaviour it is helpful to outline first what should be achieved by the behaviour in an informal way as preparation. This can be done for example with natural language, drawings, tables or simple sketches. The goal here is to focus more on content and the intended purpose rather than formalising it directly. Afterwards, a behavioural model is chosen where the following aspects shall be taken into account:
- incoming exchange items and their data elements
- outgoing exchange items and their data elements
- informal description (e.g. from the preparation step)
After that, a suitable notation has to be chosen which fits the best or is most suitable for the behavioural model. Decide there which kind of notation (i.e. modelling language or notation/expression language) shall be used for the behavioural model.