JavaTriveni version of the Carrier Group Alarms software: Structure and Advantages

  

Figure 7: Architecture of CGA Software(left), CGA Collection Software (right)

class CGA extends Expr { CGA(CollectionSoft, DataSoft1, ..., DataSoftk) { Expr e = CollectionSoft || RENAME[CGA_DATA_1/CGA_DATA, LAST_DATA_1/LAST_DATA, FIRST_REQ_1/FIRST_REQ, NEXT_REQ_1/NEXT_REQ] IN DataSoft1 ... || RENAME[CGA_DATA_k/CGA_DATA, LAST_DATA_k/LAST_DATA, FIRST_REQ_k/FIRST_REQ, NEXT_REQ_k/NEXT_REQ] IN DataSoftk become(e); }}	class CollectionSoft extends Expr { CollectionSoft() { Expr e = VerifyReq || ServiceReq || Timers || HMMonitor become(e); }}

Our version of the CGA software consists of approximately 2500 lines of concurrent code in JavaTriveni. The functionality of this software, comprised of the CGA Collection Software and multiple instances of the CGA Data Software, is depicted in Figures 7 and 8. (The structure of the CGA Data Software is relatively simple, and hence is depicted merely as pseudo-code). Arrows emanating from Triveni processes indicate events that are emitted or flags that are set by those Triveni processes; arrows pointing to Triveni processes indicate events that are received or flags that are read by those Triveni processes. Dotted arrows represent events to or from the outside world.

The CGA Collection Software receives summary requests from the outside world. In response, it first broadcasts a message to all the instances of the CGA Data Software to start collecting their data. It then sends requests to the multiple instances of the CGA Data Software; these instances are polled sequentially. The first request from the CGA Collection Software to a given instance of the CGA Data Software is represented by the FIRST_REQ_i events, and subsequent requests are represented by NEXT_REQ_i events. The given instance of the CGA Data Software responds to a FIRST_REQ_i event by collecting a threshold amount of data from the beginning of its databases, and sending CGA data to the CGA Collection Software via the CGA_DATA_i event. It then waits for a NEXT_REQ_i event, upon which it resumes searching for more data, from the point it left off in the corresponding databases. It again sends data via the CGA_DATA_i event. The LAST_DATA_i event signifies that all relevant CGA data has been sent by this instance of the CGA Data Software. The CGA Collection Software collects all the CGA data, reformats it, and sends it to the Human-Machine Interface for printing.

  

Figure 8: Design of the CGA Data Software

  class DataSoft extends Expr {
    DataSoft() {
      Expr e = AWAIT FIRST_REQ ->
                 LOOP
                   // collect threshold amount of data
                   // from beginning of database
                   // emit CGA_DATA or LAST_DATA
                   DO
                     LOOP
                       AWAIT NEXT_REQ ->
                         // collect threshold amount of data
                         // data from rest of database
                         // emit CGA_DATA or LAST_DATA
                   WATCHING FIRST_REQ
      become(e); 
  }}

The JavaTriveni design and implementation of the top-level CGA program, the CGA Data Software, and the CGA Collection Software utilize the principles underlying JavaTriveni. In particular:

1.

The CGA sub-programs are combined freely with the JavaTriveni combinators, and the JavaTriveni tools produce an implementation that yields the correct combination of behaviors. For example, all Triveni processes (denoted by boxes in the figures) are viewed as black boxes by the rest of the program, and the design and implementation of the CGA programs is based only on the desired effects on the resulting behavior.

2.

Parallel composition is used freely for the modular decomposition of designs, and the JavaTriveni tools automatically implement the desired communication. For example, the modules in Figure 7 are composed using the JavaTriveni Parallel construct and the desired wiring depicted in the figures is realized by JavaTriveni.

3.

The preemption operators of JavaTriveni aid in program modularity and allow expressing priorities on events. For example, consider the CGA Data Collection software of Figure 8. It uses preemption to indicate that the FIRST_REQ event has higher priority than the NEXT_REQ event. Namely, the AWAIT NEXT_REQ statement occurs inside the DO ... WATCHING FIRST_REQ statement. This corresponds to the desired CGA functionality that if a FIRST_REQ event arrives -- perhaps as a result of the previous request being aborted and a new request being started -- then the database will be searched from the beginning for possible alarm data on this processor. The use of the preemption operators to express priorities avoids the pollution of the code following the AWAIT NEXT_REQ -> statement with information regarding FIRST_REQ.

4.

The combination of objects, renaming, and inheritance gives a convenient way to express variances in program components in the places they are used. For example, in Figure 7, renaming of the events passed between the CGA Collection Software and the multiple instances of the CGA Data Software allow different communication channels to be used for the different instances.

The JavaTriveni design methodology is also evident at a ``micro'' level in the the following detailed description of the JavaTriveni implementation of the CGA Collection Software.