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