![](bg7.png)
Similarly, only in the Dishwasher (Controller) statechart it is evident what happens
when the door is opened.
What happens or should happen to the subsystems when the door is opened?
The absence of an answer on the diagrams stimulates the stakeholders to think
about what they want. As a corollary of this question, if we decide that some but not
all of the subsystems should stop operating when the door opens, what happens when
the door is closed and operation of the entire system resumes. Will there be a syn-
chronization problem?
6 Discussion
In a previous paper based on the same case study, a heuristic was proposed to facili-
tate stakeholder comprehension of overall system behavior and identification of prob-
lems regarding interaction of different behaviors.
The heurisitic imposed some degree of structure to the process by recommending
top-down traversal of the model and its statecharts. However the process of problem
identification proposed, based on a taxonomy of graphical cues was very impression-
istic and intuitive.
Reengineered PFA, to a large extent, replaces intuitive meandering with a highly
focused teleos. As the stakeholder traverses the model, a model reverse engineer-
ing/reinvention occurs. At each stage of the reversal, decomposition (two types) oc-
curs and afterwards recomposition.
Insofar a UML model organized according to behavioral hierarchy will have struc-
ture similar to a PFA hierarchy, two separate notations to depict approximately the
same hierarchy may sow confusion. Until more experience is gained with complex
systems, we would recommend beginning by confining the project to the UML mod-
el, supplemented by stereotypes and tagged values to indicate mappings to PFA ele-
ments and structural correspondences.
With respect to recombination, this requires consideration of collaborations, these
can be captured with UML Sequence diagrams or interaction diagrams. Here we have
a conflict between cognitive and workload issues.
Cognitively, it is easier to contemplate interactions between two behaviors if they
are captured in the same diagram as separate orthogonal components of a single
statechart.
However, if we wish to capture this interaction in a UML Sequence diagram or in-
teraction diagram, we have two choices: either we can manually draw such a diagram,
treating these behaviors as if they were encapsulated in distinct objects, each with its
own statechart, or we can actually decompose the object whose statechart contains the
two orthogonal components into two objects each of which encapsulates a single
behavior in a separate statechart.
The latter approach, imposes a cognitive burden (context switching between two
diagrams) but reduces workload: using an executable modeling tool such as Rhapso-
dy, the collaboration can be automatically generated during graphical simulation as an
animated statechart.
77