[TRW Logo]

Part I -- A Simple Rapide Model

Michael Chen
August 27, 1996
Rewritten: H. Hildreth, 9-16-96
Revised: H. Hildreth, 9-30-96

PART I: A simple Rapide specification derived from a boxes and arrows graphical representation.

Objective: Given a graphical representation of the Abstract Implementation Layer (AIL), construct a Rapide specification that models the structure and behavior of the AIL.

Rapide concepts introduced: component (module, or object) interface types, architecture generators (component-connecting constructs), behavior rules, connection rules, and posets (viewed using the pov tool).

Refer to the file ail.rpd when reading this lesson.

Image of ail architecture

  1. WWW Documents (request/reply)
  2. Reference This
  3. Action Requests (add node, open graph, ...)
  4. Server Responses
  5. Queries and Updates
  6. Query Results and Return Codes
  7. Coach Notification of Actions
  8. Coach Queues
  9. Query Results
  10. Help Returned to Client
  11. Action Notification
  12. Graph Update Notification
Procedure: The specification of this Rapide model was divided into four steps:
  1. Define a Rapide interface type for each AIL component; i.e., each box in the diagram.
  2. For each interface type, define actions for events (or messages) that are observed by the component type (in actions) and for events that are generated by the component type (out actions)--action names were derived from the labeled arrows in the diagram.
  3. Specify a Rapide architecture that declares components (or objects) of each type and connection rules that enable intercomponent communication. The rules connect out actions from one component to in actions of another--they correspond to arrows in the diagram. (Note that this specification models a two-level architectural hierarchy, described below.)
  4. For each interface type, specify behavior rules that cause the generation of events (out actions) upon the observance of events (in actions) as appropriate.
The AIL architecture (ail) contains two subcomponents, a client (C) and a server (S). C and S are defined by their interface types (Client and Server, respectively) and by their architecture definitions (ClientArch and ServerArch, respectively). The high-level architecture, ail, describes connections between the client and server only (see Additional Notes (1) below). An alternative "flat" architecture containing eight components (web browser, java application, http server, etc.) would lose the client/server distinction represented in the diagram.

ClientArch contains (or declares) two client subcomponents, WB of the WebBrowser type and JT of the JavaTools type. ClientArch contains connection rules that enable communication between the WB and JT subcomponents. ClientArch also contains rules that connect WB and JT actions (i.e., their corresponding events) to the client boundary, making them externally observable (via the client interface type).

ServerArch contains six server subcomponents, each declared to be of the appropriate interface type: HTTPServer, WWWLogfile, WWWTracker, Postgres, StudentModelingCoaching, and ConnectionManager. Like ClientArch, ServerArch contains connection rules that enable both internal (between subcomponents) and external communication (via the server interface type).

During execution, "start" events are automatically generated for each object (each of the components in the AIL architecture and subarchitectures). These start events may or may not be used to trigger behavior rules in the component interface type definitions. In this case, start events are used as triggers in the WebBrowser and JavaTools interface types. In future versions, externally generated events (outside the AIL) will trigger AIL behavior. The following statements describe the general behavior of this model. Concerns about this behavior being unrealistic should be set aside for now.

  1. A client requests a web document and the server delivers it.
  2. Concurrent with the document request, an address location is sent to the WWW logfile and tracker.
  3. The client sends a request to the server (e.g., add node, open graph) and the server in turn sends events to the postgres database, the coaching tutor and the connection manager. These actions ultimately result in the client receiving a response from the server as well as coaching advice from the tutor.

Through the execution of (interface) behavior and (architecture) connection rules, a causal ordering of events is generated. This partially ordered set of events (poset) is contained in the file, ail.log. To view ail.log, type the following command (making sure DISPLAY environment variable is set appropriately): 
   pov ail.log
When viewing ail.log using the pov tool, note that the threads correspond to the three primary event sequences described above. Nodes represent events and edges represent causal relationships (see Additional Notes (2) below). Information about the pov tool is contained in the "pov" man page (not yet available as of 9-17-96---use the pov help menus instead).

The ail.log file can be regenerated from the ail.rpd file by using the following commands (a man page for "rpdc" does exist): 
   rpdc -L -M ail ail.rpd
   a.out
The first command generates the a.out file. The second command executes the a.out file and generates the a.out.log file. The a.out.log file can be renamed to ail.log (mv a.out.log ail.log); alternatively the a.out file can be renamed before execution (mv a.out ail.out) and its execution (ail.out) will generate the ail.log file.

If library errors occur, one of the following commands may be necessary: 
   r.cleanlib
   r.mklib
The first command "cleans out" the existing library. The second command creates a library if one does not exist. The library is contained in the .rpdlib subdirectory. Note that this subdirectory can become large, but can be "cleaned out" after log-file generation.

ADDITIONAL NOTES:

(1) Note that no interface type is defined for the "ail" architecture (in contrast to the client and server architectures) and, thus, no communication between the AIL and external components is possible. Alternatively, an AIL interface type might have been defined. Then, in addition to connecting the client and server to each other, AIL connection rules would connect client and server actions to AIL interface actions, making their corresponding events observable by non-AIL components. This approach is taken in later examples.

(2) The long and diverse action names may make the tracing of this poset somewhat difficult, primarily because the student/trainee chose to give each action a different and very descriptive name (i.e., not taking advantage of the scoped, or "dot notation," naming). Additionally, prefixes such as "In," "Out," "Send," "Receive" seem excessive.

[ Back to the Index | Next | Prev]

© 1996 TRW Inc. All rights reserved.