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.
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.
- start up the application (UIL.start_java)
- request the list of topics open for discussion (UIL.join_discussion_1)
- choose a topic from the list (UIL.join_discussion_2)
- start up the web-browsing tool (UIL.start_browser)
- browse (UIL.browse_information)
- add web-acquired information to application in-box for later use
(UIL.CD.FD.PSROI.record_pointer_to_online_info)
- browse a little more (UIL.browse_information in loop)
- add web-acquired information to topic opened in (3)
(UIL.CD.FD.PSROI.post_info_as_formal_statement)
- add relationship between newly added (8) and previous topic information
(UIL.CD.FD.relate_formal_statement_to_discussion)
- request help from application coaching utility
(UIL.AAFD.unspecified_request_for_help)
- 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).
The file ail.rpd is essentially the same as oneclient.rpd in Part 4:
- it contains only one client
- it does not contain a resource manager
But ail.rpd also differs from the earlier file as follows:
- it does not contain a driver with file I/O
- many action names were shortened and simplified
- the behavior was changed to respond to externally generated commands
(i.e., from the COL)
- the behavior was changed to more closely represent actual AIL operation
- services defined in uil-col.rpd are used
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).
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]