Architecture Modeling - SPES 2020

4.3 Satisfaction
Architecture Modeling
Although implementation aspects are not considered here 2 , implementing identified components
is a primitive design step, and thus the necessary proof obligations shall be discussed.
Formally, the contracts of a component characterize allowed behavior of the component. Thus,
any implementation of a component must satisfy its contracts. In other words, an implementation
of a component satisfies its specification if its behavior does not violates its specified one,
or, it must not behave other than proposed by its specification. That way, the behavior of a
component defined by its implementation can be seen as a refinement which has to be shown:
M is a correct implementation of C if and only if [[M]] ⊆ [[C]]
where M denotes an implementation of the respective component.
SPESMM provides concepts to specify implementations for components employing the same
underlying formal semantics as for contracts. This is however convenient only for some special
cases and thus SPESMM does not rely on it. It rather provides an open and extensible approach
to integrate any kind of implementations such as Real-Time StateCharts, MatLab models and
even C-Code. That way, it is left to the needs of the respective design processes to reason
about satisfaction, and to define sufficient and necessary conditions based on the needs, e.g., for
certification.
4.3.1 Establishing Functional Specifications
At least two different approaches can be distinguished to establish functional specification:
formal verification due to model-checking, and testing.
4.3.1.1 Establish functional specifications with model-checking
Formal verification of functional behavior is a well-established research area, and various formalisms
and model-checking techniques have been developed so far. The AutoFocus and the
FUJABA Real-Time tool suites for example provide effective functional verification. Formal
verification techniques for Real-Time StateCharts and also for MatLab Simulink models exist.
Exhaustive verification is indeed a challenging task due to complexity reasons. There are however
industrial relevant approaches. For example, C-Code verification by model-checking is
known to be effectively applicable for a number of years.
4.3.1.2 Establish functional specifications with testing
Another way to establish functional contracts is due to HIL-testing. To this end, the implementation
is executed on a prototyping platform, and execution traces are captured while running
the system. In a subsequent hosted simulation, the traces are checked against the (executable)
contract specifications. Indeed also other ways exist for testing, such as the implementation of
the specification which runs in parallel to the implementation code. Also often more abstract
implementations are considered, which is the domain of simulation.
2 see for example Sections 3 and 6.2
60/ 156