Figure 8.1: The Concurrency View
8. The Concurrency View
The Concurrency View describes the concurrent infrastructure of the system realized in compliance with the RCM[BDV03, VZd05]. In ASSERT-related publications the Concurrency View is also referred to as "Timing View" (cf. eg. [CEPV06]). The Concurrency View describes the components that realize the provided interfaces specified by the designer in the Interface View. Those components are termed VMLC, which we have introduced in section 2. VMLC are the sole run-time entities supported by the RCM Virtual Machine and thus the sole entities that may populate a legal ASSERT system. The VMLC are typed and their legal types are as follows.
Figure 8.2: Passive VMLC
- Passive
- It realizes the services specified in its provided interface by warranting no access protection to its local functional state. The execution of the PI services of a passive VMLC is performed by the caller. The passive VMLC is defined by: PI; RI (which may be empty); OPCS. (See figure 8.2.)
Figure 8.3: Protected VMLC
- Protected
- It realizes the services specified in its provided interface by warranting access protection (whether mutually exclusive or transactional) to its local functional state. The execution of the PI services of a protected VMLC is performed by the caller. The protected VMLC is defined by: PI; RI (which may be empty); OBCS (which provides access protection); OPCS. (See figure 8.3.)
Figure 8.4: Threaded VMLC
- Threaded
- It realizes the services specified in its provided interface and has an internal thread of control execute them on behalf of the caller. The thread of control is released by either the arrival of an external invocation of a PI service or, with a fixed rate, by the system clock. In the former case the threaded VMLC is called sporadic (and a minimum interarrival time attribute is to be specified in order for the RCM VM to enforce it at run time) whereas cyclic in the latter case. (See figure 8.4.)
The PI attributed to a VMLC by model transformation from a source APLC determines the RI exhibited by that same VMLC.
Model Transformation
The model transformation supported by the HRT-UML/RCM tool (which is also known as vertical transformation in the ASSERT-related literature) transforms the PIM in the PSM. It is a fully automated process that takes individual APLC and generates all the VMLC and the interconnections between them which are necessary to realize the source APLC.
Every APLC is transformed independently from other APLC. Elementary interfaces are grouped and every single group is transformed into a single VMLC following a set of production and semantic rules (the operation of which is briefly illustrated in the Toy Example section).
The model transformation preserves the interconnection between APLC so that some of the VMLC which result from the transformation of the interconnected APLC are themselves interconnected. Port clusters, which we have discussed in the Functional View where they have been introduced to simplify the design space, do not add any other semantics to the system model than visibility attributes. Since every elementary PI inherits the visibility attribute of the port cluster it belongs to then model transformation only considers the visibility attribute of port clusters. The model transformation engines embedded by HRT-UML/RCM are realized on the basis of a mathematical formalization which provably guarantees that no semantics distortion may occur in the PIM to PSM transformation.
Model transformation starts from the output of the Weaving stage of the HRT-UML/RCM development process. In the present version of the tutorial, we omit the description of the transformation rules and their mechanics; we give instead a single example of application, on the Partitioned Toy Example as well as on the Distributed Toy Example.