Architecture Modeling - SPES 2020

Architecture Modeling
or their implementation, in terms of an executable model or even code, is deliberately left open
in the meta model, in order to provide flexibility in using aspect-specific modelling formalisms.
The formal foundation assumes, that – whatever modelling method is used – the capability to
associate with such models a what is often called trace-based semantics, which, for each interface
object, defines for each point in time the value of such interface objects. Implementations
are allowed to be non-deterministic, hence yielding sets of such traces as their formal representation,
but would typically be input-deterministic and responsive, i. e. yield for each valuation
of an interface object under control of the components environment a uniquely determined valuation
of interface objects under control of the component. Note that in particular modelling
approaches such as AutoFocus, which come with a formal semantics, meet this requirement.
When using commercial-off-the-shelf (COTS) tools for modelling the realization of a component,
a strictly formal development process requires the ability to verify compliance of such
models against contracts, requiring a formal definition of their semantics. Such formal semantics
have been given for a plurality of COTS tools [17, 19, 3]. Less formalized development
processes can use test cases automatically derivable from contract specifications to demonstrate
compliance of component realizations and specifications.
Within the generic landscape characterized by perspectives and abstraction layers, the emphasis
is on supporting the major phases of system development, from product requirements
to a specification of the technical architecture of the system. In particular, the transition to the
geometric perspective, which is served by tools like CATIA 1 or the Siemens PLM suite 2 , is
not elaborated in the current version of this document. In other project contexts, the role of
contracts as an interface between the geometric and the technical perspective has been demonstrated,
such as the impact of physical allocation decisions and routing of cables on the safety
case [4] has already been demonstrated.
This document is organized as follows. A quick tour in Section 2 elaborates on an informal
level the key concepts of perspectives, abstraction layers and Heteregenous Rich Components,
by way of example, providing first indications as to their possible role in design processes.
This is complemented by a detailed specification on the conceptual level of the architecture
meta-model.
The ensuing section adds more detail on the syntax of the meta-model and how design artifacts
are to be represented. It is thus technical in nature and could be skipped on first reading.
Section 4 presents primitive steps in component-based design. It introduces on an informal level
the main concepts underlying contract-based design — contract syntax and semantics, properties,
their usage in specification, verification and virtual integration testing — and how they are
applied to perform the design task from requirement definition to deployment. While this section
provides a bottom-up view of design, Section 5 on using the architecture meta-model adds
the top-down perspective, painting the broad picture of applying contract-based design in the
industrial context. In fact, readers with an industrial background may prefer to read this section
after the quick tour before delving into the more detailed sections 3 and 4.
The annex, finally, provides the formal underpinning of this approach. In particular, it provides
a reference manual for the proposed requirement specification language, a formal semantics
of contracts, a formal semantics of HRC components, and the formal foundations for
primitive design steps in component based design.
This document thus provides guidance in using the release of the architecture meta-model,
1 http://www.3ds.com/de/products/catia
2 http://www.plm.automation.siemens.com/en us/products/teamcenter/ , http://www.3ds.com/plm
2/ 156