7.1 ANÁLISIS DE LOS CUESTIONARIOS
8. CONCLUSIONES FINALES
In a session, the DFA is determined by the instantiation of the collaboration entity and its inputs later on. In some DFA, all their states are built at early stage; in the others, some of their states are built up on the fly because of interactive inputs. For example, in the example above, all the states of the DFA are decided as early as when the
collaboration client is instantiated (state q0) and loads the presentation file (state q1), as δ
(q0, a0) = q1. At this stage, all the states are known and also the relationships between
them (decided by the presentation file itself), as shown by the labeled arcs between states in the transition diagram in Figure 2.1.
As for the DFA with Collaborative ReviewPlus, some of its states are decided at early stage (e.g. the states related to the original menus and sub-menus of the interfaces when the application is first started), and the others, especially those related to interactive input requirements, are built up dynamically. In such cases, we might as well think the DFA is extended stepwise with the collaboration steps.
Collaboration here is all about the synchronization of the interfaces between the Master and Participant clients at each step. In IDL, the interface consists of all kinds of widgets such as buttons, lists, sliders, tabs, and text fields. The constitution, configuration, and layout of the widgets in the interfaces of an application are coded in its widget
programs. The states of the DFA in question are based on the widgets. The relationships between the widgets and the states may be one-to-one correspondence, such as simple button widget (one button click causes the DFA to transit to the next state), or it may be one-to-many, in which one widget corresponds to many states, such as the text field widget. For example, if the text field widget is configured using keyword “/all_events” that means an event is fired whenever the contents of the text field have changed, then it is associated with all the states. Each of the states is the result of an event.
Hence, when the collaboration entity is instantiated (the application is invoked), the initial states associated with the widgets in the interfaces of menus and sub-menus are built up with the instantiation; these are the original states which are determined by the widget programs with their initial values. More states are built up on the fly with new context, contents, and inputs.
We list some parts of the interfaces in ReviewPlus below in Figure 2.2 and 2.3. The widgets in these parts are of the type of one-to-one correspondence; each widget
Figure 2.2 Widgets captured from the interfaces of ReviewPlus that each corresponds to the transition to one state of the DFA when it is triggered at a step of
a session.
Example 1: If we click on the “Set Signals” button from the sub-menu of “Edit” in the main menu, the DFA goes from the current state to the next state, which brings up an input table.
Example 2: Suppose we are in the context of a selected signal of the display of ReviewPlus. If we click on the “Derivative” button from the sub-menu of “Transform” in the main menu, the DFA goes from the current state to the next state, which shows the derivative of the signal.
Figure 2.3 Widgets captured from an interface of ReviewPlus that each corresponds to the transition to one state of the DFA when it is triggered by the event of the
carriage return.
Example 3: All the “cw_field” widgets in Figure 2.3 above are configured with the
keyword “return_events” in the widget program, which means that an event is fired when the carriage return key is pressed in the text field. The fields that are titled “Plot Title:,” “X axis label:,” “Y axis label:,” and “Subtitle:” are of string type. Any string content typed in the field is reflected in the event structure as a single string value after the pressing of the return key, and the DFA transits to the next state with this value. The same is true for the last two fields titled “Symbol size:” and “Character size:” except that they are of floating-point type.
Next we list in Figure 2.4 some parts of the interfaces in ReviewPlus where the widgets are of the type of one-to-many correspondence; each widget corresponds to the transition to one or more states when the input is finished.
Figure 2.4 Widgets captured from the interfaces of ReviewPlus that each corresponds to the transition to one or more states of the DFA when the input is
finished.
Example 4: All the input cells of the widgets above are configured in the widget programs with the keyword “all_events”, which means an event is fired whenever the contents of the text field have changed. The field that is titled “Half-width of smooth window (ms):” is of long integer type, and the final value is 2000 before clicking the “Done” button below it. Each input character triggers an event, including the ending hexadecimals “0a” and “0d” for line feed and carriage return, if there are some. If we look at the values only, the DFA transits through the states with the values 2, 20, 200, and 2000, one by one before reaching the final value 2000. The same is true for the fields with the string value “ip” and the long integer value “104276” under the titles “Z Data Signal” and “Shot”, respectively. They are used to define a signal display in ReviewPlus. This feature of “all_events” for a widget makes it possible to show more detailed process in collaboration, as opposed to the case with the feature “return_events” in Example 3,
where only the final values in the fields are collaborated, without showing the details of the inputs in the participant clients.