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 behavioural constraints
Overview
Behavioural constraints in the context of behaviour definitions constrain model elements to which they are attached or related to in a declarative way. They consist of a set of parameters and a statement about how these parameters are related to each other. Typically they are written in a textual notation language which is capable to express different kinds of constraints (e.g. mathematical). The parameters are then related to properties of the model elements.
Characteristics
Basically they are the most declarative approach of behaviour definition since they contain only behavioural statements over the properties of the considered model element. A usage would be that a constraint defines the valid relationship(s) between inputs and outputs, without defining how the outputs are achieved with avoiding more complex behaviours as kind of a solution (e.g. of how the properties are held or are achieved). However they might be more challenging to be read in comparison of more intuitive approaches (e.g. imperative statements if-else or setting outputs with assignment statements like in programming languages). One could interpret those more formal constraints like a translation from natural-language-style requirements to amore formal text notation (with focusing on "what" rather than an abstract implementation).
They are corresponding to constraint blocks in SysML v1 with a notation language for the statement of the constraint (e.g. Object Constraint Language OCL) or with constraint definitions in SysML v2. In Capella they can be modelled with the constraint element, but there is currently no satisfying and sufficient built-in tool support inside Capella for an additional notation language for the opaque expressions of these constraints.
Types
In general, two main types of behavioural constraints can be identified.
Mathematical equations (analytical constraint)
Mathematical equations are proper for describing behaviour dealing with continuous parameters. A corresponing function will become then a mathematical function in the sense of calculation purposes. Inputs and outputs of the function are then bound to the constraint parameters. The relations between the parameters are expressed through the constraint statement which uses e.g. arithmetic operations between the operands. In general, there are different typical or more complex equations available to solve different problems.
One area of mathematical equations are those ones which are used for transfer functions. They are mathematical formulas describing the input/output relationship of Linear Time-Invariant (LTI) systems. Four variants of transfer functions may be identified:
- Differential equations in the continuous time domain (t). This variant is suitable for mathematical processing by humans but not for computer processing as computers cannot deal directly (only simulate) continuous time behavior up to a certain level of time granularity.
- Laplace transforms of the differential equations in the complex frequency s = σ+jω domain which are also referring to continuous time domain signals but in a form that is suitable for processing using software. Such Transfer Functions have the form Y(s) = H(s)*X(s) and are aaplicable for describing Control Systems.
- Related to Laplace transforms, Fourier transforms of the differential equations in the real frequency ω domain, also referring to continuous time domain signals. Such transfer functions have the form Y(ω) = H(ω)*X(ω) and are applicable for describing communication and A/C power systems.
- Digital system transfer functions in the complex frequency domain z of the form Y(z) = H(z)*X(z) which relate to the discrete time domain i.e. representation of signals as periodically collected samples with discretized values. This form is applicable to digital processing systems which interact with the physical world through A/D and D/A converters.
Boolean expression (boolean-valued constraint)
Boolean expressions are a condition in the form of a parameterised boolean expression which can evaluated to true or false. These treat inputs and outputs both as parameters in which the resulting value of the constraint's boolean expression does not correspond to a output (e.g. of a function) but instead is a kind of a non-causal relation of inputs to outputs. They can be build from a truth table (e.g. through disjunctive normal form "ORs of ANDs") and provides therefore a textual form of the essence of the truth table. For purposes of efficiency, a truth table and especially its Boolean output may be expressed as a simplified boolean expression using boolean algebra. The general form of the simplified input/output relationship is y=f(x1, x2, ... xk) with assigning a single value to return value y as kind of bit more imperative type.
Applicablity
Behavioural constrains are suitable to be used for the following model elements.
- regarding abstraction levels: system level, logical level, physical level
- regarding structural entities: system, subsystem, logical component, interface layer component
- regarding data: data elements of exchange items
- regarding functions: behaviour definition of function (which means a leaf level or atomic function, which means it is not subdivided into further subfunctions)
- regarding other behavioural models: pre- and postconditions and invariants (e.g. in of lifelines in interactions, i.e. sequence diagrams)
- regarding purpose: combinational logic, calculations, data transformations, mathematical transformations
Examples
Calculations and equations
The following example shows a simple mathematical function doing a very basic calculation.
/* calculation definition with a single result value */ calc def SimpleCalculation (a : Integer, b : Integer, c : Integer) : Integer { a * b + c } /* function defined with a simple action which relates calculation parameters to exchange item elements (input/outputs of the function) */ action def MathematicalFunction (in e1 : ExchangeItem1, out e3 : ExchangeItem3) { calc simplecalc : SimpleCalculation (a = e1.Element1, b = e2.Element1) return c = e3.Element1; }
Two further simple examples written in a pseudo expression language are a*x^2 + b*x + c = 0. The mathematical function y = f(x) = x*2 (single-valued) assigns the result to the single return value y.
Boolean expressions
A simple example is the following one which contains a statement about two boolean and two numeric parameters.
constraint def SimpleBooleanExpression (b1 : Boolean, i1 : Integer, b2 : Boolean, i2 : Integer) { b1 == true & i1 >= 3 | b2 == false & i2 <= 10 }
This example shows a boolean-valued constraint which could be used for a function which determines a required point position state based on DPS states.
constraint def RequiredPointPositionState (dps1state : DPSState, dps2state : DPSState, ReqPointPosState : PointPositionState) { /* SysML v2 syntax for operators: & <-> And, | <-> Or, == <-> conditional comparison */ /* types of the constraint parameters are all enumerations */ dps1state == DPSState::None & dps2state == DPSState::Full & ReqPointPosState == PointPositionState.RightEndPosition | dps1state == DPSState::Full & dps2state == DPSState::None & ReqPointPosState == PointPositionState.LeftEndPosition | dps1state == DPSState::Full & dps2state == DPSState::Full & ReqPointPosState == PointPositionState.NotAllowed | dps1state == DPSState::None & dps2state == DPSState::None & ReqPointPosState == PointPositionState.NotAllowed }
The same constraint in disjunctive normal form (DNF) derived from a truth table in pseudo code style could be expressed as: (DPS1 == NONE And DPS2 == FULL And Point Position == Right end position) Or (DPS1 == FULL And DPS2 == NONE And Point Position == Left end position). A corresponding mathematical table would like this:
FULL | NONE | Left end position |
NONE | FULL | Right end position |
The next example is a try-out and possible option that uses Capella's constraint element to model and visualise the behaviour definition for a logical function "LogicalFunction". It uses an opaque expression inside the constraint as the statement and provides the rules to transform inputs to outputs (continuous data) transferred by exchange items (ExchangeItem2 is left out here in the example to reduce complexity).
/* This constraint defines a boolean expression over inputs and outputs. */ constraint def LogicalFunctionConstraint (inValue1 : Integer, inValue2: Boolean, outValue1 : Integer, outValue2 : Boolean) { inValue1 == false & inValue2 <= 3 & outValue1 == true & outValue1 == 12 & outValue2 == true | inValue1 == true & inValue2 > 3 & outValue1 == false & outValue1 == 7 & outValue2 == false } /* This action definition (corresponds to SysML v1 activity) here links the constraint parameters to the exchange item elements. */ /* It also provides an additional assert statement that the used constraint as defined above must be true in the context of the logical function. */ action def LogicalFunction (in e1 : ExchangeItem1, out e3 : ExchangeItem3) { assert constraint lfc : LogicalFunctionConstraint (inValue1 = e1.Element1, inValue2 = e1.Element2, outValue1 = e3.Element1, outValue2 = e3.Element2) }