Part VIII -- Advanced Animation Techniques

Michael Chen
August 29, 1996
Editted: H. Hildreth, 10-1-96

PART VIII: ADVANCED ANIMATION TECHNIQUES

Objective: Create an .arch file that animates the multi-level model from Part VII. Use advanced Raptor features to clarify model animation.

PART A: Event Aliases

Because we used embedded services to organize the UIL and COL actions, they have very long names that are undesirable (and unnecessary) for animation purposes. We set up aliases to shorten those that appear in this animation (i.e., those generated by executing the model); e.g., UIL.START_JAVA is aliased to START_JAVA.

PART B: Adding Another Hierarchical Layer

A box ("architecture") for the lrdc_arch had to be created. It contains one box ("mod") for the user interface, one for the concepts of operation interface, and one for the abstract implementation architecture. To view the layout of the lrdc_arch boxes and arrows ("path"s), type:

   raptor -a lrdc.arch

The abstract implementation box can be opened (by double-clicking on it) to reveal its client and server components, both of which, in turn, can be opened to reveal their components. (New windows can be dragged for better viewing.) The AIL layout is similar to earlier examples.

PART C. Disambiguating Event Paths

A problem arose when events within the client were not following designated paths because the paths were ambiguous. We wanted events moving from client subcomponents to the COL (via the AIL interface) to travel upward within the client box, and we wanted events moving from client subcomponents to the Server to travel downward. An ambiguity existed because two paths run from each of the client subcomponents to the client boundary (see arrows within client box). To resolve the ambiguity, the four paths were first distinctly named (note that -name is an option for path definition); e.g.

    path WebBrowser:1 ClientArch:1 {1.5 1.75} {2.75 2.375} {2.75 3.0} \
	-twoway both -width 2 -name WebAndServer

Next, the set EVENT_PATHS feature was used to assign particular events to particular named paths; e.g.:

   set EVENT_PATHS {
        {ClientArch:1 WebBrowser:1 GET_URL WebFromArch}
        {ClientArch:1 JavaTools:1 NEW_INQUIRY_DIAGRAM JavaFromArch}

PART D. Event Coloring

The entire modeled behavior is composed of four primary scenarios, each involving different interactions between Server subcomponents. We wanted to distinguish these separate scenarios in the animation. We decided to set event colors for different sequences using the proc_per_event feature. All events within a particular scenario were assigned the same color (event aliases are used to identify events); e.g.

   proc per_event {id name params caller} {
      global smE_boxcolor
         case $name {
            HELP_REQUEST            {set smE_boxcolor "red"}
            REQUEST_ADVICE          {set smE_boxcolor "red"}
            .
            .
            BROWSE_INFO             {set smE_boxcolor "black"}
            GET_URL                 {set smE_boxcolor "black"}

For several of the events with parameters, such as SERVER_REQUEST, we had to use parameters to distinguish events within separate scenarios (i.e., (i.e., $params indicates the parameters associated with the event, $name (used above) indicates the name associated with the event (aliases in this case)); e.g.

	SERVER_REQUEST {
	    if {$params == {2 REQUEST_ADVICE} } {
		set smE_boxcolor "red"
		}
	    if {$params == {1 DOCUMENT_REQUEST} } {
		set smE_boxcolor "black"
		}

PART E. Disappearing and Reappearing Components

Because client subcomponents receive explicit start commands, we wanted them to not appear within the client architecture until startup. This is accomplished by first making the components disappear at initialization (or startup of the encompassing architecture). Then we make them reappear when the client receives (observes) their respective start commands (note that these user-generated start commands are different from the start events generated by Rapide for each object during execution). The rpChangeState function is used within the proc_per_event structure. (Note that the raptor man pages described both "proc_per_event" and "rpChangeState".)

   if {$name=="START"} {
	if {$caller=="CLIENTARCH:1"} {
	     rpChangeState CLIENTARCH:1 WEBBROWSER:1 invisible -p

FINALLY, to view event coloring and disappearing/reappearing components, run raptor with the log file:

   raptor -a lrdc.arch lrdc.log

If raptor is already running, you can load the log file using the "Load Log File" option of the "File" menu.

[ Back to the Index | Next | Prev]