Edition: 1.0
(path:[an error occurred while processing this directive] file:javabdeSM.shtml)
The following is a summary description using state models of some of the operations in bde2java or javaBde. The diagrams are modeled after standard FA notation. The purpose of this type of documentation is to support the documentation supplied by the javadoc facility. While the javadoc facility provides a means of defining code elements, it is not necessaraly representative of its operation. It is hoped that the creation and maintenance of this document will permit greater understanding for future developers of javaBde.
The document is organized around a graphical representation of the some of the operations within javaBde. Each figure is followed by explanatory text. Paths to original idraw images are to be stated.
Following this section will be a textual analysis of the states. This differs in being more an identification of the branching conditions within the class methods defined in javaBde.
This text will only refer to "some" operations because as of the time of this writing it cannot be claimed that a complete picture of the states and transition rules of for javaBDE can be drawn. It is also to identify a single alphabet on which to define transition rules as pre-conditions are not necessaraly identified and assigned to any one variable. It is often the case that method calls and actions are set into motion by identification of several conditions (such as if (cond1 && cond2 && cond3)). Many of the rules for transitions are located in specific methods and not readaly available as case statements.
Machines were described using finite state machine notation. Strict interpretation of these models is not recommended as they describe operations over class definitions, almost as if the class definitions themselves are representative of a higher level state definition. This is not the case with the current implementation. While a common entry is defined, it is only meant to represent that the transitions described will only be pertinent to the states of one particular flag variable (the alphabet). Interpretation of the notation at this point should be flexible as they are more representative of the structures of classes.
These descriptions could be expanded upon if a clearer description of the preconditions for entry to a particular method of a class be better defined. Figure 2 comes closest to illustrating the event cycle that defines the process. It is hoped that this will be done in future work and this document will accordingly be ammended.
Breakdown of states:
If it is an event setting evt.id to the above states, then Navigator checks to see if it is a node hotspot event. If so it will print out a new graph and then reinitialize that graph before returning to an event wait state.
Non hotspot events are then passed to an event handler that determines whether UpperCheckBoxSelect(US) is on (=1) and then check if LowerCheckBoxSelect(LS) is on (=1). If both are true event is handled otherwise it loops back to wait event. After event is handled process loops back to wait event.
The most important operation within this class appears to be that within StateSelector as it appears to be the closest parallel to the original bde's case switch on state. It switches on the operation of the value of UpperCheckBoxIndex which can take on the following values:
NODE: call nodeFunction()
LINK: call linkFunction()
TEXT: call textFunction()
BENDPOINT: call bendpointFunction()
GRAPH: call graphFunction()
CAPTION: call captionFunction()
DEFAULT: print error message.
Two points of note: 1) that within Delete, a branching condition exists on deletion based on whether or not the mouse is currently over the selected node when the Mouse Up event occurs. 2) that within Restyle, the process of restyling is controlled by whether the current node is the first or second node selected.
Create requires existing link. Restyle allows for 3 different kinds of styles.
Text operations within the bdeText.java class are somewhat involved in that they operate over GraphCaptionText, CaptionText, and Node. Also Create involves the operation of GraphBox, but whether it returns from Graph Box was not clear.
Additional remards: Move() contains branching to select if movement involves node (set node selected), or GraphCaptionText (set graphCaptionText selected), or neither(return) Delete3() operates strictly over CaptionText. Delete() over node or GraphCaptionText by branching whether one or the other is selected.
Hopefully the tracking of mouse events illustrated in the "Event Handling Outline" figure should act as guidance with respect to transition on events.
(excerpted from $case/96f523/bde2java/jli/state.3)
1. DisplayFrame.java:
Method: handleEvent()
evt.target = scrollbarV --> get offset Y --> repaint;
evt.target = scrollbarH --> get offset X --> repaint.
2. bdeAppletFrame.java:
Method: handleEvent()
evt.target = MenuItem {Exit --> exit system;
New --> not implemented;
Print --> print PS file;
Open --> read in a bde data file and show
on the Applet Frame;
Save --> save file to current filename;
Save As --> save file to the filename specified;
About BDE --> print bde message;
}
3. bde2JavaApplet.java:
Method: handleEvent()
evt.target = Graphlist --> get GraphName --> repaint the Graph.
// this is a (choice) java event. The choice items are graph names.
// Selecting one choice item will make corresponding graph painted. -jie
evt.id = WINDOW_DESTROY{if inApplet --> dispose the window;
else --> exit system;
}
4. bdeToolBox.java
Method: handleEvent()
evt.target = NODE --> show node related attributes
evt.target = LINK --> show link related attributes
evt.target = TEXT --> show text related attributes
evt.target = BENDPOINT --> show bendpoint related attributes
evt.target = GRAPH --> show graph related attributes
evt.target = CAPTION --> show caption related attributes
5. bdeGraphSelectionBox.java:
evt.target = OKbutton --> set flag from ACTION_PENDING to ACTION_OK.
evt.id = Event.WINDOW_DESTROY --> hide window and set flag to
ACTION_CANCEL
6. bdeNodeAttributesBox.java
Method: action() // the action clears OK button
evt.target = OKbutton --> hide the OK_button
set status = ACTION_OK
Method: handleEvent()
evt.id = WINDOW_DESTORY --> hide window
7. menutest.java
Method: mouseEnter() --> set bSelected = true in terms of mouse (x,y)
repaint
Method: mouseExit() --> set bSelected = false in terms of mouse (x,y)
repaint
Method: mouseDown() --> set nSelectedNode = -1
reaint
// i.e. set nSelectedNode = NOT_FOUND (file: bdeRefrence.java)
Method: mouseUp() --> set bMouseDown = false
repaint
Method: mousedrag() --> set bdeMouseItemText = "Test"
repaint
set bMouseDown = true
For a full listing consult the files
$case/96f523/bde2java/jli/state.1, and
$case/96f523/bde2java/jli/state.3.
A seperate analysis of operational states only from the interface (as opposed to the way the method calls are implemented) may help in more clearly identifying the flags used to verify preconditions before executing an operation.
Finally, it is hoped that test suites can be developed from the information gathered from these references.
[an error occurred while processing this directive]/javabdeSM.shtml
Last updated: Friday, 20-Dec-1996 21:26:58 EST