OPDs without being overwhelmed by an overly complicated layout. Overloading the System Diagram or any other OPD with more artifacts would put the viewer’s comprehension at risk, so showing additional detail is deferred to lower-level OPDs.

When an OPD approaches the limit of human comprehension, the model must be refined to manage the system’s inherent complexity. Figure 3 outlines the newly generated OPD, labeled

System from speeding to
stopped. The time within a
zoomed-into process flows from
top to bottom, so Braking hap-
pens first, Boosting and Signal ^{Figure 3. The
Detecting are executed in paral- Emergency Braking} process, revealing five
lel, and Actuating is last. ABS is subprocesses and two
unfolded to reveal its constituent ^{interim objects. This}
snapshot of the
parts (such as Brake Assembly system’s animated
and Mechanical Subsystem), simulation serves as a
making it possible to express proce- ^{design-level visual} _{debugging tool.}
dural relations between the sub- Shown by red dots
process _{Emergency Braking} and (indicating the flow of
^{the parts of the control), Braking has ABS.} just changed the state
of Brake Assembly

“SD1—Emergency Braking in-zoomed.” In it, in-zooming Emergency Braking reveals five subprocesses and an interim object. This view is expressed in the OPL sentence “Emergency Braking zooms into Braking, Signal

Detecting, Boosting, Anti-

locking, and Actuating, as well as Signal Set.” The modeler is now able to specify that Driver is the agent (in charge) of the Braking subprocess, and the Actuating subprocess is the one that actually changes Car-Driver

 

_{ACTIVE PROCESSING} from passive to active.

Boosting and Signal

The active-processing assumption _{Detecting are} is tacitly accounted for during the ^{executed in parallel,} conceptual modeling process in ^{while Signal Set is} _{generated by Signal} that each and every modeling step Detecting. requires the complete engagement of the user—the system architect carrying out the conceptual modeling activity. When modeling, the architect places the conceived elements on the screen (possibly through the pencil tool), linking them and inspecting the OPL textual interpretation that is continuously created in response to new graphic inputs. The architect must from time to time rearrange the graphic layout to make it more comprehensible through such actions

as grouping entities and moving links to avoid crossings. If the current OPD is too busy, that means it is approaching our limited channel capacity, in which case a new OPD must be created via in-zooming or unfolding.

Animated simulation is another aspect of active processing. Humans have been observed to mentally animate mechanical diagrams to aid comprehension.

 

Using a gaze-tracking procedure, [ 7] found that inferences were made about a diagram of ropes and pulleys by imagining the motion of the rope along a causal chain. Similarly, an active-processing aspect of OPCAT is its ability to simulate the system by animating it. This animation enables the modeler to simulate the system and see it “in action” at each point in time during its design. Like a program debugger, the modeler carries out “design-time debugging” by running the animation stepwise or continuously (back and forth), inserting breakpoints where necessary.

Figure 3 is a snapshot of the animated simulation. Objects in green exist at this point; the white ones (such as Actuating Pulse Set) were either consumed already or are not yet created. Blue processes (such as Anti-Locking with Boosting and Signal Detecting within it) are now taking place. The active participation of the modeler (as system behavior is inspected) has proved highly valuable in communicating action and pinpointing logical design errors (corrected early on), saving precious time and avoiding costly trouble downstream.

 

CONCLUSION

Technological limitations can no longer be cited as an excuse for a lack of human-centered design. A