In the Interface View the designer only needs to specify some details while others are automatically derived from the specification by the model transformation logic.

1. The designer creates the Interface View by specifying AP-level containers (APLC in the sequel). One essential part of this specification is the inclusion of specific functional components from the Functional View into designated APLC. The criteria for inclusion of functional components in APLC may follow those used for designing UML components (in particular via the UML2 Component Diagram). As we noted in chapter 4, however, not all UML models can be imported in the Interface View, but only those which proceed from a UML Profile compliant with the RCM metamodel (hence with the restrictions and constraints that the RCM imposes on Functional models off that profile).
   

2. After this inclusion, the HRT-UML/RCM tool automatically generates port clusters within APLC, that is, homogeneous groups of either elementary PI or RI. (See for example Figure 5.3, TMTC.)

3. The designer decorates all PI and RI with semantic decorations, which specify the concurrent behavior to occur upon invocation of the relevant elementary interface and then sets the desired visibility attribute for port clusters (and thus not on elementary interfaces individually).

4. The designer creates the desired instances of the APLC classes just specified and completes the specification of the interface attributes by setting instance-specific values such as criticality (per APLC) and worst-case execution time, WCET (per elementary interface).

5. The designer interconnects APLC instances in order that RI are bound to PI which are semantically and contractually compatible with one another. Semantic compatibility follows from type matching whereas contractual compatibility is based on value matching (for example, the WCET set on a PI must not exceed the WCET set on the interconnected RI, where the latter is a contractual specification).

Expected values are attribute values set by the designer on APLC types or RI types or instances, such as Memory Size, WCET, etc. The final system may not fully conform to those values: it is for the designer to decide whether compliance should be warranted for all values mandatorily or else some required values could only be taken to steer the design process in a non-prescriptive manner. Every expected value will eventually be matched by a measured value when the PSM corresponding to the designer-specified PIM will be available from model transformation for various forms of static analyses to be performed.

What We Mean by Interface View

A model in the Interface View is composed by interconnected APLC. The following table summarizes the set of APLC attributes.

An elementary port wraps a single method and decorates it with execution semantics. An elementary port and an elementary interface thus designate the same concept. In the literature, both names are used interchangeably: which name to use in a given context depends on the chosen point of view. The term "elementary interface" is used when discussing the methodology from a theoretical point of view, as opposed to the term "elementary port". This term belongs to UML2 terminology and has been borrowed together with the concept it describes in order to realize in practice the "elementary interface" concept.

In the Interface View an elementary port is decorated with concurrent semantic. In the Interface View an elementary port is decorated with concurrent semantics. The following table explains some of the allowable attributes.

immediate

An immediate elementary PI provides a service whose execution is to be carried on by the calling thread. It may be either protected or unprotected.

unprotected

An unprotected elementary PI provides an immediate service with no mutual exclusion guarantees.

protected

A protected elementary PI provides an immediate service with mutual exclusion guarantees. Mutual exclusion is guaranteed only on the data accessed by the operation and encapsulated within the APLC providing the port.

deferred

A deferred elementary PI provides a service whose execution is carried on by a dedicated thread. It may be either nominal or modifier.

nominal

A nominal elementary PI is a deferred elementary PI. It may be either cyclic or sporadic.

modifier

A modifier elementary PI is a deferred elementary PI which represents an alternative behaviour of the thread designated to the carry on the execution of a specific nominal PI.

cyclic

A cyclic elementary PI is a nominal PI. The operation associated with the PI is periodically executed by a dedicated thread. Whenever a modifier of the cyclic PI is invoked, the next time the cyclic PI is executed, the thread carries on the operation associated with the modifier PI instead, subsequently the thread resumes its nominal behaviour.

sporadic

A sporadic elementary PI is a nominal PI. The operation associated with the PI is executed by the dedicated thread whenever the PI is invoked. The operation associated with a modifier of the sporadic PI is executed by the same dedicated thread whenever the modifier PI is invoked.

The Distributed Toy Example: Interface View

Figures 5.2 and 5.3 show the Interface View for the Distributed Toy Example.

PRO_AP

PRO_AP is an APLC which encapsulates the data and the functional behaviour of a PRO. All the methods of PRO are provided by the PRO_AP APLC through a port cluster which has "private" visibility. Since the visibility of that port cluster is private, the tool editor shows it inside the PRO_AP APLC box. The Boost_Order port is also provided within a public port cluster and consequently it is shown outside the PRO_AP, too. Private port clusters are shown inside their container APLC, attached to the state that provides data and functionality. Nevertheless, methods within private port clusters are delegated to the APLC just like all other methods of every encapsulated functional entity.

PRO implements the PRO_Boost interface: all the methods declared by this interface are also provided by the PRO_AP through an other port cluster which instead has "public" visibility. The only port accessible outside the APLC is Boost_Order, since it is the only port contained inside a public port cluster.

All the ports of an APLC must be decorated with concurrent semantics. PRO_op is declared as "cyclic", i.e. PRO_AP executes operation PRO_op at a fixed rate specified as an attribute of the corresponding port. The PI of PRO also includes the Boost_Order elementary port, which is declared in PRO_AP as a behavior modifier: the modifier attribute can be set on a port only in conjunction with another elementary PI in the same APLC which is tagged cyclic or sporadic. The modifier attribute specifies that when the corresponding elementary interface is invoked, it is executed once in place of the nominal operation.

POS_AP

POS_AP encapsulates the data and the functional behaviour of a POS. It provides three port clusters, one of them private. All the ports of POS_AP are "protected", since POS has to be accessed in mutual exclusion. (The HRT-UML/RCM editor does not allow yet the designer to distinguish between read-mode and write-mode mutual exclusion attributes.) POS_AP also features a RI which requires a Compute method from a Computer interface. The problem specification requires GNC to have transactional access on POS to perform Read, Compute and Write. HRT-UML/RCM currently addresses this need at the supplier side and not (as it should conceptually be) at the client side. In the example, POS exhibits a PI (Read_X_Write) which requires Read, Compute and Write: marking Read_X_Write as "protected" grants that every invocation of Read_X_Write (which actually operates as an "envelope" operation) shall execute the Read, Compute and Write operations sequence continually holding mutually exclusive access on POS. More details on this issue appear in appendix 1.

GNC_AP

GNC_AP encapsulates the data and the functional behaviour of a GNC defined in the Functional View. GNC_AP provides two ports: one for the Compute operation and one for the GNC_op operation, grouped together in a private cluster. GNC_AP provides an unprotected Compute port through a port cluster with the Computer interface. In the Functional View, GNC_op requires a Read_X_Write operation on a POS_Reader_X_Writer, which is provided by POS with transactional access rights. An RI has therefore been created to this effect for GNC_AP inside a required port cluster attached to it.

TMTC_AP

TMTC_AP encapsulates the Dispatcher functional state together with a POS_Sender functional state. The only public port cluster of TMTC_AP is the one for Dispatcher, which provides the Dispatch elementary PI. In the example both the Dispatch and the Send PI within Write_Sender have been marked as sporadic. Since the execution of Write on POS is computationally intensive, modeling the Send port as immediate would cause Dispatcher to delay the dispatching of subsequent commands until completion of the whole Read-Compute-Write procedure. Conversely, the execution of Send in POS_Sender is computationally intensive, since it involves the execution of Read, Compute and Write. Dispatching a Boost_Order command received from a TC is far less expensive, since Boost_Order is provided as a deferred service: for this reason Boost_Order is immediately invoked by Dispatch.

In Figures 5.2 and 5.3 lots of boxes are used which seem to clutter the design space. However, when we consider realistic systems, all these boxes will arguably simplify the system. For example, elementary ports are grouped in port clusters which mirror the structure of the classes defined in the Functional View.