Component Model. Our approach is based on a component model that delimits the broad out- line of what constitutes a component, exposing its necessary related technical concepts and constraints. Both, components and connectors, as well as their interaction semantics, are characterised in this component model that defines the building blocks of our systematic development approach. A component contract1, whose definition is presented below, encapsulates a component in our approach. They are defined in terms of their behaviour (represented as a CSP process), ports (represented as channels) and respective inter- faces (types).
3.1 ( Component contract) A component contract Ctr com- prises an observational behaviour B, a set of communication channels C, a set of interfaces I, and a total function R : C → I between channels and interfaces of the contract (Ctr : (B, R, I, C)), such that: • B is an I/O process as defined below; • Let c ∈ C: 1In the COMPASS project contracts are described in CML. Here, a contract is a tuple that includes a behavioural specification (originally described in CSP, but lifted here to CML), and other elements that describe the ports and their types. – outputs(c, B) = {out.x : R(c) • c.out.x }, and; – inputs(c, B) = {in.x : R(c) • c.in.x } R Intuitively, the component describes the component’s channels and their respective types. Our approach follows approaches like that of [All97b] in which component models have a higher-level granularity by complementing the syntactical in- formation of a component with behaviour. In our case, we explicitly sepa- rated inputs and outputs. The behaviour of these components are represented by I/O processes, which are CSP processes P that satisfy five conditions, which are formally presented in [Ram11]: •
Component Model. Our approach is based on a component model that delimits the broad out- line of what constitutes a component, exposing its necessary related technical concepts and constraints. Both, components and connectors, as well as their interaction semantics, are characterised in this component model that defines the building blocks of our systematic development approach. A component 2assert is not currently a CML keyword, but could be included as a means to provide text commands to the CML model-checker that could be included in the CML specification itself. In particular, assert P [= Q asks the model checker if the process P is refined by the process Q.
