link, the text colors of the process and the object names in OPL match their colors in the OPD. Since graphics is more amenable to cognitive processing than text, modelers favor modeling the system graphically in the OPD pane, while the textual interpretation is continuously updated in the OPL pane and can also be continuously referenced to verify that the modeler’s intent is captured.

The OPL sentences constructed or modified automatically in response to linking graphical symbols on the screen provide immediate feedback to a modeler, as well as to his/her audience. This real-time human-like response “tells” the modeler what the modeling environment “thinks” he/she meant to express in the most recent graphic-editing operation. When the text does not match the modeler’s intention, the modeler can take corrective action. Such feedback is indispensable for spotting and correcting errors at an early stage in any system’s life cycle, before they have a chance to propagate and cause costly downstream damage. Any correction of the graphics changes the OPL script; changes can be applied iteratively until a result satisfactory to all stakeholders is obtained. While generating text from graphics is the prevalent working mode, OPCAT also generates graphics from text.

The System Diagram is constructed such that it contains a central process, which in this case carries out the system’s main function and delivers its main value to the beneficiary for whom the system is built. In the case of anti-lock braking, Emergency Braking is the process that provides value to the Car-

Driver System, the beneficiary.

Having established this basic conceptual design, we can now be more specific. In Figure 1(b), I specify the two states—speeding and stopped—of Car-Driver System. This specification triggers generation of the OPL sentence “Car-Driver System can be speeding and stopped.”

Figure 2. Top-level OPD (system diagram) resulting from adding Car, which consists of an ABS, and characterized by Speed and the effect of Emergency Braking on changing Speed from high to zero.

By replacing the effect link with an input-output link pair consisting of an input link (from speeding to Emergency Braking) and an output link (from Emergency Braking to stopped), Figure 1(c) explicitly shows that “Emergency Braking changes Car-Driver System fromspeeding to stopped,” as specified (equivalently) in the OPL

sentence at the bottom of the figure.

The System Diagram is elaborated further in Figure 2. First, the modeler “unfolds,” or speci-fies, the parts of the whole Car-Driver System. The black triangle is the aggregation-par-ticipation symbol, specifying that “ Car-Driver System consists of Car and Driver.” Driver is linked to Emergency Braking via an agent (human enabler) link (the line ending with a black circle), and ABS, a part of Car, via an instrument (nonhuman enabler) link (the line ending with a blank circle). The rela-

tionship between Driver and Car is expressed by the “is inside” tagged structural relationship between Driver and Car, and the states speeding and stopped are marked respectively as initial and final.

To aid active processing, humans use pencil and paper to flesh out their thoughts. OPCAT accepts pencil strokes as graphic input for objects, processes, states, and links. Pattern-recognition techniques help it recognize these graphical elements, even for sketchy pencil strokes.

 

LIMITED CAPACITY

Figure 2 is the final System Diagram, the bird’s-eye-view model of the system. This OPD contains about seven entities and seven links, pushing the limit of our cognitive capacity, as determined by the “magic number seven plus or minus two” concept [ 10]. However, we have not yet specified the subprocesses comprising the Emergency Braking process or the parts of ABS. Addressing our limited human capacity, OPM advocates keeping each OPD simple enough to enable the diagram reader to quickly grasp the essence of the system by inspecting the