Figure 10.1:
The Code View

10. The Code View

Although the Concurrency View is a platform-specific model which fully specifies the system in terms of the run-time entities supported by the RCM Virtual Machine, some further transformation steps have to be taken to obtain code ready for deployment: first source code generation and then compilation. All of the source code generated from the Concurrency View is currently in Ada 2005. In this tutorial, we chose to consider the source code as yet another instance of a platform-specific view, at the same level as the Concurrency and the Analysis View. This conceptual decision places emphasis on the following facts:

  • the generated code is not intended for the inspection and editing of the designer (only the classes that feed the Functional View are; cf. Architecture)
  • n an MDA approach, the more specialized models ought to contain all the information of all the "higher level" models, but at a low level of subject-matter abstraction[Mel05]; the Code View is no exception and thus it should be expected to contain all of the information specified by the designer in the PIM with no omission and/or distortion: if the transformation logic is considered trustworthy, the designer can satisfy themselves with the PIM
  • once the code is generated from the Interface View (via the required extent of weaving with the Deployment View) and the system is ready for use, not much else should be required to the designer in the way of system validation. Since the run-time preservation of the temporal, spatial, communication (and, prospectively, dependability) properties stipulated in the model is guaranteed by the HRT-UML/RCM methodology by construction, the final product of the transformation process should not need to be qualified by observing operational behaviour in test runs. This vision however assumes that the code which proceeds from the Functional View has been subject to prior verification so that the designer (and the transformation process) can place justified trust on its ability to compute the correct values.

Architecture

The code is automatically generated in the Ada 2005 programming language in conformance to the Ravenscar Profile restrictions. The extent of automation is 100% for the Interface View and the Concurrency View, while the code from the Functional Model may be either generated, in part, for models produced with the ETH FWProfile or else incorporated in the form of prefabricated code components which however need to be asserted to comply with the RCM restrictions and must also have an Interface View description of them.

Figure 10.2 shows a Threaded VMLC, The OPCS represents its functional code. The OBCS and the THREAD represent its structural, or concurrent, side. The THREAD and the OBCS can be factored out in artefacts (called "archetypes") reusable across all VMLC instances of that type.

Figure 10.2: Breakdown of a threaded VMLC with archetype and OPCS

Consider the Distributed Toy Example discussed in the Concurrency View. Figure 10.3 below shows the architecture of the generated code for that example.

Figure 10.3: Architecture of the generated source code

The source code is (currently) placed under three directories respectively named: Common, Lib, N1 (for the 1st node in the system topology) as follows:

Common

encloses the code which implements all the types specified in the model and all of their instances:

  • the primitive types which have been specified in the Functional View, with the generated source code located in common/basic_types.ads;
  • the Classes which have been specified in the Functional View, with the generated source code located in Common/Classes;
  • the APLC and their instances as specified in the Interface View, with the generated source code located in Common/Containers/APLC;
  • the VMLC and their instances as specified in the Concurrency View (produced off fully automated transformation, with the generated source code located in Common/Containers/VMLC.

In the absence of fully-automated code generation capabilities from the Functional View, the designer needs to implement all the methods specified in the Functional View by directly editing the source code in Common/Classes. The HRT-UML/RCM methodology forbids modifications in any other directories.

Lib

encloses the prefabricated archetypes which the HRT-UML/RCM transformation and code generation engines need to build up the VMLC which populate the Concurrency View The generated code which is recurrent across implementations is factored into reusable basic entities like Request Descriptor, Thread and OBCS: VMLC are formed from suitable aggregations of those archetypal components.

N1

represents the product of the automated generation of the application-specific parts of the software system (targeted for node N1 as identified in the Deployment View) and encloses

  • identifiers for every software entity composing the system, i.e. for every computational node, for every partition, for every APLC and VMLC instance;
  • all the deployment information, e.g., which APLC and VMLC instances are deployed in which partition;
  • the initialization procedures, which bind instances to their designated node, following the specification of the Concurrency View.

The Partitioned Toy Example: Code

01   procedure Read_And_Write (This : in out POS) is
02      --Invoked required interfaces--
03      --+ This.Read : 1 invocation
04      --+ This.Write : 1 invocation
05      --+ C.Compute : 1 invocation
06      Res : Boolean := False;
07   begin
08      --#BlockStart number=3
09      --id=RCMoperation@eb77b0{file:/path_to_my_model/
10      --my_model.rcm#//@rootPackage/@ownedMember.11/@ownedOperation.2
11      -- User-defined code here --
12      declare
13         R : Integer := This.Read;
14      begin
15         This.C.Compute (R);
16         This.Write (R);
17      end;
18      --#BlockEnd number=3
19   end Read_And_Write;

Code fragment 10.1: The copde for the Read_And_Write operation in common/classes/poss.adb

Code fragment 10.1 is a sample implementation for the method Read_And_Write found in Common/Classes/poss.adb. The generated code includes comments which help the user provide an implementation conformant with the functional specification. By way of example, the comments on lines 2-5 advise the designer that Read_And_Write was designed to invoke methods Read, Write and Compute exactly once. The other comments are needed by the generation facility to preserve the user-defined implementation when the code is regenerated.

The final source code is generated in such a way that the designer need not concern themselves about the infrastructure which realizes the concurrent behaviour to be obtained at run time. Three abstraction levels are crossed in the generation of the final source code: the Functional View (the most abstract); the Interface and the Concurrency Views (more specialized). Consider method Compute: it is specified by the designer in the Functional View as a provided method. In the Interface View, it is designated as a provided method of the GNC APLC. In the Concurrency View it appears as a provided method of the GNC VMLC. In all those views method Compute always provide one and the same signature, but with different semantic specializations. For this reason, the designer may content themselves with assuming that the command at line 15 in code fragment 10.1 should be a direct invocation of the Compute method specified in the Functional View while in actual fact, before getting there, the execution of it will first travel across the overriding layers added up by the code generation process to realize the concurrency semantics specified in the Interface View for that method.

The final version of this Tutorial (to be released by the end of the project) will contain, in annex, a representative sample of the source code automatically generated from the model for the examples discussed in this document.