[TRW Logo]

Part VII -- Services and Separate Compilation


Author: H. Hildreth, 10-1-96

PART VII: SERVICES AND SEPARATE COMPILATION

Objective: The primary objective is to move from a one-layer (AIL) model to a three-layer (UIL-COL-AIL) model. Remembering the following definitions from the reference documentation:

UIL = User Interface Layer
COL = Concept of Operations Layer
AIL = Abstract Implementation Layer

Rapide Concepts Introduced: Services and separate compilation

Procedure: Each of the Rapide (.rpd) files are described separately.

PART A (uil-col.rpd)

The UIL and COL portions of the model are defined in the file: uil-col.rpd. This model introduces Rapide services as a means of organizing large numbers of interface-type actions. The best way to read the uil-col.rpd file is to first search for the UIL interface type definition (search for "type User_Interface_Layer"). This UIL interface is partially defined by out actions (e.g. "start_java") and partially defined by services ("CD" and "AAFD"). The services are also defined by interface types (e.g. "contribute_to_discussion"), which are in turn defined by combinations of actions and other services. Note that interface types for services are defined before their use; so, for example, interface-type definitions appearing before "User_Interface_Layer" contribute to its definition. The COL interface (search for "type Concepts_Of_Operation_Layer") is defined similarly. When an action is used in a behavior or connection, the full service-embedded name must be used (examples in Part B below).

The Pass_Back interface type groups actions that are generated by the AIL and "passed back" through the COL to the UIL. The signal the user that the requested operation has been completed.

NOTE: Action names used in the COL and UIL models were derived from the reference documentation; an attempt was made to preserve these names for cross reference and verification purposes.

PART B (uil-col.rpd cont'd)

User (human) behavior is modeled in "type user_interface". The following scenario is modeled. Note: (1) the user waits for the result of each request before making a new one, and (2) "dot notation" is used to name actions embedded in service definitions.

  1. start up the application (UIL.start_java)
  2. request the list of topics open for discussion (UIL.join_discussion_1)
  3. choose a topic from the list (UIL.join_discussion_2)
  4. start up the web-browsing tool (UIL.start_browser)
  5. browse (UIL.browse_information)
  6. add web-acquired information to application in-box for later use (UIL.CD.FD.PSROI.record_pointer_to_online_info)
  7. browse a little more (UIL.browse_information in loop)
  8. add web-acquired information to topic opened in (3) (UIL.CD.FD.PSROI.post_info_as_formal_statement)
  9. add relationship between newly added (8) and previous topic information (UIL.CD.FD.relate_formal_statement_to_discussion)
  10. request help from application coaching utility (UIL.AAFD.unspecified_request_for_help)
  11. revise a piece of information associated with open topic (UIL.CD.FD.revise_formal_statement)

PART C (uil-col.rpd cont'd)

COL behavior is modeled in "type concepts_of_operation_interface". COL essentially translates user actions into application-specific commands (for either the java or browser applications). So, for each action generated by the user (PART B above), a corresponding COL action is generated. Note: the java application uses directed-graph diagrams to represent discussion topics; nodes represent bits of information (or statements) and edges represent relationships.

The last few behavior rules in "type concepts_of_operation_interface" achieve the "passing back" of responses from the lower level (AIL) to the higher level (UIL).

PART D (ail.rpd)

The file ail.rpd is essentially the same as oneclient.rpd in Part 4: But ail.rpd also differs from the earlier file as follows: As an example of how uil-col services are used in the AIL, see "type JavaTools". Note: declaring a service "dual" switches the mode of all actions defined by the service; i.e., all "in" actions become "out" and vice versa (as is the case here). The COL service actions are passed through the Client interface; they are connected to the WebBrowser and JavaTools interfaces via the ClientArch connection rules.

Important Note: One of the primary motivations for using services instead of ungrouped actions is to be able to use service (or "basic") connections in the architecture definitions; i.e., to connect whole services to components rather than connecting each individual event. Unfortunately, the raptor animation tool (at the time of this development) did not properly handle service connections. Therefore, we had to comment out the brief, concise service connections (i.e., COL to JT.COL) and add in individual action connections (COL.IDA... ||> JT.COL.IDA...). (See also ail_arch (described in Part E.) This becomes particularly unfortunate in the file lrdc.rpd (described in Part F below).

PART E (ail.rpd cont'd)

The AIL model now has an associated interface type through which it communicates with the higher-level COL model (search for "type ail_interface"). The AIL architecture (ail_arch) connects client and server actions in a fashion similar to earlier versions (see lower ail_arch connections). Now, in addition, ail_arch connects COL (externally generated) actions to the client and server (first set of connections--note commented out service connection); it also connects client and server responses to the ail boundary, making them externally visible (i.e., by COL).

PART F (lrdc.rpd)

The file lrdc.rpd contains the highest-level architecture definition. It contains three "components" representing each of the three layers (User_Interface, Concepts_of_Operation, and Abstract_Implementation). Note again, that, because of a raptor bug, the few service ("to") connections are commented out and replaced by the many individual ("||>") connections.

PART G: Separate Compilation

The compilation commands follow (in order):

   rpdc -L uil-col.rpd
   rpdc -L ail.rpd
   rpdc -L -M lrdc_arch lrdc.rpd
The above commands generate an a.out file, which when executed generates an a.out.log file (renamed to lrdc.log).

Note: One of the library commands, r.mklib or r.cleanlib, may be necessary.

PART H: Viewing the poset

The poset for this three-layer model can be viewed using:

   pov lrdc.log

[ Back to the Index | Next | Prev]

© 1996 TRW Inc. All rights reserved.