Abstract:
A method and system for visualizing process flows for business and manufacturing processes are described that includes a first view of the process as a tree showing the process elements and their interconnections, and a second view of the process in the form of a zoomable interface that displays selected nodes at magnifications that are continuously variable at the user&#39;s option. A selected node in the tree view opens the same node in the zoomable node view. When a second node is selected in the tree view, the zoomable node view zooms from the first selected node to the second selected node through each node intermediate between the first and second selected nodes. This enables a process analyst to view the content of selected process nodes in the context of nodes with which the selected nodes are associated and thus to have a thorough understanding of the process.

Description:
FIELD OF THE INVENTION 
     The present invention relates to visualizers for process flows. More particularly, the present invention relates to improvements in visualizers that facilitate viewing of large process and software entities and promote examination and understanding of large and small portions thereof in context. 
     BACKGROUND OF THE INVENTION 
     Flow diagrams are graphical descriptions of the flows of data and control in software systems. They are made up of nodes interconnected through arrowed lines. Nodes denote actions or components. The lines identify the data flow and the control flow between the actions or components. Several commercially available tools implement some forms of flow diagrams; WebSphere®, MQIntegrator®, Lotus® Workflow™ and more recently WebSphere Studio Application Developer Integration Edition are examples of such tools. 
     There are many specific kinds of technical flow diagrams, for example, Petri nets, data flow diagrams, state charts, process dependency diagrams activity diagrams, and workflows. In addition, several software developers produce middleware products that also have specific kinds of flow diagrams associated with them. In these products, the programmer, business analyst or system integrator, draws flow diagrams that are executed by associated runtime environments. The flows in these products are classified as nano-flows, micro-flows and macro-flows (also known as workflows). An example of tool and engine for micro-flow is MQIntegrator®, a program product of IBM Corporation for message routing and content reformatting, that allows the programmer to draw message-flow diagrams that describe the movement of data between information systems. The associated runtime environment executes these diagrams: i.e. combines, transforms, and delivers the messages. MQIntegrator is typically used to integrate information systems when large corporations merge with former competitors. Macro-flows use large-scale granular activities and are deployed by large-scale software components such as applications. Workflow products that model and implement business processes are examples of macro-flows. Nano-flows are flows of data and control that take place inside an object or object method. In many products, nano-flows model and implement the wiring of Java classes into programs that access legacy applications. Nano-flow, micro-flow, and macro-flow diagrams can be modelled with an extension of Meta Object Facility (MOF), called Flow Composition Model, as was previously reported by Litoiu et al. in “Flow Composition Modeling with MOF”, Proceedings of ICIES, 2001, Setubal, July 2001. Flow Composition Model is in the process of becoming an Object Management Group (OMG) standard. Meta Object Facility and Flow Composition Model are typically serialized in the XML Metadata Interchange (XMI) format based on eXtensible Markup Language (XML). 
     A second type of charting is frequently used for describing technical, business and other processes. This type of chart can describe parallel process steps, for example a credit granting process that includes steps of, for example, reviewing credit history, examining collateral and preparing account information, which can be carried out at the same time and which do not necessarily have dependencies each upon the other. This type of chart is typically in the form of a hierarchical tree, and includes nodes that usually contain multiple steps, each step being a child node that contains more detailed steps, and so on down to the simplest part of the process which usually contains text or code defining the process at its most detailed level. This lowest type of node is called a leaf node. A leaf node has no child nodes. 
     Flow diagrams are hierarchically composed. That is, a node in a flow diagram can itself be a flow diagram. There can be many levels in the hierarchy. Understanding hierarchically composed diagrams is difficult, especially with the current tools. For example, to understand what a node is really doing, the user has to open a new session or new window of the editor and then look at the flow implemented by that node. Given that there might be tens or hundreds of nodes, to see all these nodes, the user has to open as many sessions or windows. Further, the known prior art methods provide no convenient way of navigating through the large number of nodes that are present in a complex business or manufacturing process, or a complex software package. 
     North and Shneiderman, in “Snap-Together Visualization: A User Interface for Coordinating Visualizations via Relational Schemata”, Proceedings of the Working Conference on Advanced Visual Interfaces, ACM, 2000, pp 128-135, describe a flow visualization method with display of multiple panes of information including tree and hierarchical information. Naps and Bressler, in “A multi-windowed environment for simultaneous visualization of related algorithms on the World Wide Web”, SIGSE 1998, pp 277-281, describe a program visualization method using multiple windows. In De Pauw et al, U.S. Pat. No. 6,219,826 B1, a method is described for visualizing the execution of an object-oriented program wherein each node in a tree represents an object, and each edge between nodes represents a message between objects. Lopez, in US Patent Application Publication US2002/007483 A1, describes a flow structure markup language used for flowchart program editing and navigation for a range of programming languages. Other forms of visualization are described in U.S. Pat. Nos. 6,278,464 B1 and 5,751,288. 
     Despite various methods known in the art for depicting program flows, process flows and general flow illustration, there is a need for flow depiction that enables more complete understanding, particularly of complex business and industrial process flows. It would be desirable to have a viewer for manufacturing, technical and business process flows that permitted the user to view a selected portion of a flow diagram at any desired magnification, to view selected nodes in closed or in open mode, and to view a hierarchy of nodes in order to understand the depth and complexity of the process flow. 
     SUMMARY OF THE INVENTION 
     Accordingly, the present invention provides a method and system for examining a business or technical process that enables the user, viewing a flow diagram, to focus on the large picture or a small set of details in any desirable level of magnification, by zooming in or out in the same manner as a zoom camera lens, to see simultaneously the position in the process occupied by the details being viewed, and to cause the system to zoom automatically to display in a zoomable node view of the process, nodes selected by a user from a hierarchical view. The present invention further provides a method and system for examining a business or technical process that enables the user to view any selected node at each level in a hierarchy of nodes in the process by simple means. The present invention further provides a method and system for examining a business or technical process that depicts the depth of a hierarchy of nodes in the process. The present invention further provides a computer readable memory containing software code that implements a system for examining a business or technical process, the system having the characteristics listed above. The present invention further provides a computer readable memory containing software code that implements a method for examining a business or technical process, the method having the characteristics listed above. 
     The invention can be implemented on a computer system at least as powerful as a typical desktop or laptop, having a central processing unit, a display, a program and data storage device such as a disk drive, and input devices including keyboard and pointer controls. As such computer systems are well known, no further description will be given herein. 
     The invention is typically used in combination with one or more process abstraction tools that prepare lists of the process components and how the components interact. Such tools include WebSphere Studio Application Developer Integration Edition, a product of IBM Corporation. The lists and files prepared by the tools provide the raw material for process analyser software to depict the process components and their interactions. Such software is sometimes called fact extractor software, (especially in the software reverse engineering community). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A preferred embodiment of the invention will now be described by reference to the accompanying drawings, in which: 
         FIG. 1  illustrates a preferred embodiment of the invention including a three-pane representation of a diagrammed process; 
         FIG. 2  depicts a preferred embodiment of the invention illustrating closing and opening of nodes, and manual zooming of a zoomable node view of a diagrammed process; 
         FIGS. 3   a ,  3   b ,  3   c , and  3   d  illustrate a multi-stage zooming activity of a preferred embodiment of the invention; 
         FIG. 4  is a block diagram of components of a preferred embodiment of a flow viewer system that provides interaction between a hierarchical view and a zoomable node view of a process; 
         FIG. 5  is a flow chart of a method of manual zooming of a zoomable node view of a process; and 
         FIG. 6  is a flow chart of a preferred method of automatically viewing and zooming through several nodes in a zoomable node view of a process. 
     
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Essentially, the method and system of the invention incorporates a system comprising a viewer including two panes. A first pane is a main view of the process being examined, which will be described herein as a zoomable node view. The zoomable node view includes a parent node and each child node that stems from the parent. A parent node can be presented as closed, that is, effectively a black box, or as open, in which the child nodes for the parent are visible within the parent node. Thus the user has the power to control the complexity of the zoomable node view for better understanding of the process. Each of the child nodes can be viewed with its own children, by a zooming technique to be described in detail below, which can be initiated by any convenient means, for example, by positioning a cursor over the desired node and clicking with a mouse or other convenient device. The user&#39;s action repositions the zoomable node view on the desired child node, and a similar action can be used to view each child node in turn until a leaf node is viewed. A leaf node is a child node that has no further children, and usually contains code or text relating to a lowest level item in the process being analysed. Conversely, when positioned on a child node, the system can be made to move up to the immediate parent node by an appropriate user interface action, for example, clicking or double-clicking a mouse button. The system then shows the parent node, and the user can move to its parent in turn, or to other child nodes, as desired to understand the process being analysed. 
     A second pane in the preferred embodiment shows a tree diagram, which will be called herein a hierarchical view, which illustrates a hierarchy of items in a process being analysed, and their relationship to each other. In particular, their parent-child relationships are visible in the hierarchical view. In the preferred embodiment, the parent in the hierarchical view is the overall process, and the children at various levels illustrate the sub-processes that are incorporated into the overall process. 
     An essential element in the invention is the coupling between the first pane showing the zoomable node view of a process and the second pane showing the hierarchical view of the process. The second pane is coupled to the zoomable node view such that if the user positions a cursor over a specific node in the tree view, and takes an action, for example, a mouse click, then the zoomable node view opens the node selected in the hierarchical view. Further, if the user clicks on a second node in the hierarchical view, the zoomable node view zooms out through each node in turn up to the nearest parent node from which the second node can be reached, then down to the second node. Optionally, the zooming action pauses at each intermediate node during the view transition from first node to second node, thus enabling the user to see the environment of each node in turn and better understand the process flow. Optionally, the system can be set to stop a zooming action at any point by means of a user action, for example a right-click of a mouse button, or pressing a particular key on a keyboard. 
     It is possible within the scope of the invention, to display the hierarchical view in a separate window from the window that displays the zoomable node view. While the underlying implementing mechanisms will be substantially the same as if the two views are displayed in two panes in the same window, a user would have to toggle between the two views, and thus the usability and convenience for the user would be degraded. Thus it is preferred to display both panes in the same window. 
     In a preferred embodiment, each of the changes of view in the main pane is accomplished by smooth, that is substantially continuous, zooming. Thus the image shown on a display grows larger or smaller in small increments until the desired node becomes the focus of the display. The speed of the zooming action can be varied to accommodate differing user preferences. Optionally, pauses can be built into the system which briefly stop the zooming action either as a result of or in the absence of a particular user action. That is, the default can include or exclude a pause, using default selection means well known in the art. Pauses are particularly useful to a user who wants to maintain an understanding of the relationship of the node contents to other nodes. Zooming can be accomplished by any appropriate user signal, for example pressing a mouse button when the pointer is placed over a node on which the user wishes to zoom in. A different user action can be employed to zoom out, for example pressing a third mouse button or pressing a function key. 
     Zooming may be considered as a special form of computerized animation, and can be performed using several approaches known to the person skilled in the art, for example geometric zooming, semantic zooming and fisheye zooming. In geometric zooming, the entire image is scaled around a specific point in the view. In semantic zooming, a selected non-leaf node will open to display its children nodes if they are not already visible, and a selected leaf node will open to show the related code segments or text annotations automatically. Fisheye zooming provides for a selected portion of a flow diagram to be magnified to any desired degree while maintaining focus on the selected portion, while at the same time portions of the flow diagram surrounding the selected portion shrink to a corresponding desired degree around the selected portion of the flow diagram. For convenience, this disclosure assumes, without loss of generality, that geometric zooming is being used. 
     An optional third pane illustrates aspects of the process being analysed in a format similar to the showing of folders in a disk drive as is common on personal computers and workstations. This can be used as a navigator pane, for example, for showing parts of a larger process, as will be discussed in more detail below. 
       FIG. 1  depicts an example of a simultaneous display  100  of a Credit Approval process in a Hierarchical View pane  120 , and occupying substantially the entire display space in Zoomable Node View pane  101 , and listed in an optional navigator pane  140 . Zoomable Node View  101  displays nested views of nodes that comprise a portion of the process flow depicted in Hierarchical View pane  120 . The highest level node is overall credit approval  102 , whose components include a start step  104 , in which input data are supplied including an applicant&#39;s name, address, amount of credit requested, and other data that are important to granting credit approval in a business sense. Data supplied in start step  104  are analysed in risk assessment node  106 . Within risk assessment node  106  are several child nodes that contain details to accomplish a risk assessment, namely nodes  108 ,  110 ,  112  and  114 . The arbitrary symbols on nodes  108  to  114  are used merely to distinguish one node from another node, and are not intended to have inherent meaning. Following completion of risk assessment at node  106 , business flow for the described process ends at step  116 , wherein information is output, including the applicant&#39;s name, whether or not approved and the amount approved. 
     Also in  FIG. 1 , Hierarchical View pane  120  depicts the entire process being analysed, including a credit approval node  122  that corresponds to node  102  in Zoomable Node View  101  pane  101 . An icon in the form of a square box hovering over credit approval node  122  indicates that credit approval node  122  is the node that is active in Zoomable Node View  101 . Other nodes in Hierarchical View pane  120  correspond to nodes in Zoomable Node View  101 , for example risk assessment node  124  corresponds to node  106  in Zoomable Node View  101 . The tree representation can depict the entire business process; however, in the case of very complex processes, the tree itself can be a view of part of a process. Nodes  126 ,  128 ,  130  and  132  correspond to other nodes not shown in Zoomable Node View  101 . 
     The functions of optional navigator pane  140  can be performed by any convenient means, for example a list of flows or processes can be placed in a separate window that, upon receiving a suitable signal from the user, opens a Zoomable Node View  101  and a Hierarchical View  130  in a program window. Systems that perform similar functions are known. In the system using the optional navigator pane  140 , the navigator pane includes a summary item, Flows  142 , and subsidiary items for each flow to be analysed, including in this example Credit Approval  102  and Risk  146 . The user normally begins by selecting a process in the navigator pane  140 , for example Credit Approval  102 . Selecting the process to be examined can be performed by any convenient means, for example positioning a cursor over the word defining the desired process and clicking a mouse button. In a preferred embodiment, that action causes the Zoomable Node View pane  101  to display the Credit Approval flow  102  as described above. 
       FIGS. 2   a  and  2   b  together depict the illustration of nodes in closed and open formats, respectively. “Open” and “closed” modes of a node will be described briefly. These two are the main modes. The “closed” mode typically displays an image or icon that represents what kind of node a particular node is. The “open” mode shows the “child” or sub-nodes. There may be, optionally, other modes that display other information about the node; for example, a prose description of what the node does. In  FIG. 2   a , Risk Assessment node  106  is shown, containing nodes  108 ,  112  and  114 , together with Decision node  110 . The symbols on nodes  108 - 114  merely indicate that each node is distinct from the other nodes within Risk Assessment node  106 . Decision node  110  is shown in closed format, in which no internals of Decision node  110  are visible. Upon receipt of a suitable signal from the user, the system opens Decision node, now shown in  FIG. 2   b  as node  110 . A suitable signal can be any signal indicating which node is selected and what action is desired, for example positioning a mouse pointer over node  110  on a display and clicking on a mouse button. Opened Decision node  210  shows its internals which here include five subnodes and several edges, which will be described below. 
     An important aspect of the invention is the combination of continuous zooming in a process flow analysis system with selection of one or more nodes to be viewed at a desired zoom level. While it is difficult to illustrate continuous zooming in a static document,  FIGS. 2   b  and  2   c  depict a node before and after zooming, respectively. Risk Assessment node  106  includes subnodes  108 ,  112  and  114  as described with respect to  FIG. 2   a . Node  106  in  FIG. 2   b  also includes Decision node  110 . As described in  FIG. 2   a , Decision node  110  is displayed in closed mode, that is it is shown without the internal specifics of any subnodes. In  FIG. 2   b , Decision node  110  is shown in open mode, illustrating the internal subnodes. Prior to zooming in, Risk Assessment node  106  occupies substantially the entire display space. Upon receiving a signal from the user, the system zooms in to increase the size of node  106  so that now the internals are not only visible but also large enough to be labelled and their relationships shown. The zooming can be stopped at any magnification by the user; preferably the system includes a pause mechanism that stops the zooming at the point when the node  210  occupies substantially the entire display space. Where a node changes form between figures, in this disclosure the node is given a new but similar number, for example,  110  and  210 , to distinguish the second form of the node from the first form of the node. In  FIG. 2   c , subnodes within Decision node  210  can now be viewed and read, including a Start position  220 , an Assess node  222 , which has output edges for High Risk  221  and Low Risk  223 . High Risk  221  leads to a Reassess node  224 , which has output edges for Reject  225  and Accept  227 . Low Risk  223  and Accept  227  lead to Send Money node  228 . Reject edge  225  leads to Send Rejection node  226 , and both Send Money  228  and Send Rejection  226  have output edges leading to End  230 . Any of the nodes within Decision node  210  can have further child nodes, which for clarity are not shown. 
       FIGS. 3   a  to  3   d  depict sequentially an embodiment of the invention in which the selecting of two nodes in the Hierarchical View causes the main Zoomable Node View to zoom sequentially from a first selected node through intermediate nodes to a second selected node. In  FIG. 3   a , node A was selected first in Hierarchical View  305  by the user, and node B was selected second. 
     After the selection of node A, Zoomable Node View  300  shows the Create Account node including several subnodes shown in closed form. Following the selection of node B in Hierarchical View  305 , the system first searches the process information in a manner to be described below with reference to  FIGS. 4 and 5 , and determines which nodes are in a most direct path from node A to node B. The system then moves an icon in Hierarchical View  315  in  FIG. 3   b  to a first node in a path from the first-selected node A to the second-selected node B. In the example, the first node in the path is the highest level node C, and the system substantially simultaneously zooms out in the Zoomable Node View to show node C, which is Credit Approval node  310 . Create Account node  302 , which formerly occupied substantially the entire display space, has become node  312  in the higher level view now depicted in Zoomable Node View  310 . Risk Assessment node  314  is shown as a closed node in Zoomable Node View  310 , together with other nodes. The system pauses at this zoom level, and optionally the user can signal the system to hold, for example by a mouse click, or can allow the system to proceed to the next zooming action. 
     In  FIG. 3   c , the icon in Hierarchical View  320  has moved to node D, and the Zoomable Node View  320  now shows Risk Assessment node  314  opened and expanded. Inside Risk Assessment node  314 , now shown occupying the entire display, are several nodes including Decision node  322 . The system again pauses at this zoom level, and in the absence of a signal to hold, the system proceeds to the next zooming action. 
     In  FIG. 3   d , the icon in Hierarchical View  325  has moved to node B, the node selected originally by the user, and, as described with respect to  FIG. 2 , the Zoomable Node View  330  now shows Decision node  322  expanded and occupying substantially the entire display. The component nodes within Decision node  330  are Start  220 , Assess node  222  having output edges High Risk  221  and Low Risk  223 . High Risk  221  is input to Reassess node  224 , which has output edges Reject  225  and Accept  227 . Reject edge  225  is input to Send Rejection node  226  which has the sole output edge leading to End  230 . Accept edge  227  leads to Send Money node  228 . Low Risk edge  223  leads to Send Money node  228 , which in turn leads through sole output edge  231  to End node  230 . 
       FIG. 4  is a block diagram illustrating the components of a preferred embodiment of an overall flow viewer system. Data element  400  is stored on any convenient storage unit, for example a disk drive, and it includes information about the process that is to be viewed, comprising artifacts and the relationships among artifacts, prepared by a data gathering system. As described above, several data gathering systems are known in the art that can collect information to feed the viewing system of the invention. Data element  400  feeds information to and receives information from Flow Model  402 . Flow Model  402  also sends data to Path Controller  404 . 
     Flow Model  402  contains the data of interest to the user; in this case a flow diagram. There may be many views of a flow model. In the context of this invention there are two main views, the Zoomable Node View and the Hierarchy View. The kind of model preferably used to represent flow diagrams in this invention is a directed, typed, multi-graph. This is a graph in the mathematical or graph-theoretic sense, and not a visual representation. Visual representations are handled by the views. “Directed” means that edges go from a “source” node to a “target” node. “Typed” means that the nodes and edges each have a type. “Multi” means that there may be more than one edge between any pair of nodes. The elements in the model keep track of their parent nodes and child nodes in the hierarchy as well as other information that is preferably stored in only one place. A view shows at least some of the things that are in Flow Model  402 . Although Flow Model  402  can in practice be frequently updated, for the purposes of the invention fow model  402  can be assumed to be static. Ordinary updates to Flow Model  402  can be readily adapted by persons skilled in the art. 
     Path Controller  404  is the element of the invention that controls the zooming from a first selected node in Hierarchical View  305 ,  315 ,  320 ,  325  in  FIGS. 3   a  to  3   d . Path Controller  404  receives user signals from User Input Device  414 , for example pointer positions and mouse clicks that identify a source node and a target node for which the user desires to see zoom views, and for which the user desires to see each node in a most direct path between the source node and the target node. Path Controller  404  also receives information from Zoomable Node View  410  about the information currently displayed, and sends instructions to Zoomable Node View  410  to display the selected node. As will be clear to the person skilled in the art, the information in Hierarchical View  406  that does not appear on the display space must be retained off-screen, and Hierarchical View  406  includes logic that performs that function. Hierarchical View  406  receives information from Flow Model  402  relating to the elements and relationships of the process being analysed, and creates a Hierarchical View as displayed in pane  120  of  FIG. 1 . Zoomable Node View  410  accepts information about the process being analysed from Flow Model  402 , and creates the display by node shown in pane  101  of  FIG. 1 . Zoomable Node View  410  is more complicated than a regular (non-zooming) view. It is composed of two closely related parts, which we call the “logical view” and the “physical view” (following a long-standing use of these terms in the art). In essence, zooming or magnification is a computation that projects the logical view onto the physical view. Magnifier  412  is closely associated with Zoomable Node View  410 , and causes the node displayed in Zoomable Node View  410  to zoom sufficiently that the selected node occupies substantially the entire display space, more fully described below with reference to  FIG. 5 . 
       FIG. 5  depicts a preferred embodiment of a navigation method that provides manual zooming of the Zoomable Node View depicted in pane  101  of  FIG. 1  and element  410  of  FIG. 4 . The first step is to detect a user action at  500 . Decision step  502  determines whether the user action is “magnify”. If Yes, then the method proceeds to step  504  and detects the target in the Model component. If No, then the system returns to step  500 . After detecting the target at step  504 , the system gets in step  506  all nodes and connections of the target from the Flow Model, and proceeds to step  508  to open the selected node and draw that node in Zoomable Node View  410 . The system then in step  510  magnifies by increments, conveniently by 1 percent increments, the target node. The system tests in decision step  512  whether the target node has filled the display space, also termed the pane, and if Yes, then proceeds to Stop  416 . If No, the system tests at decision step  514  whether the user still requests “magnify”. If Yes, the system returns to step  510  and increases the target node size by a further increment. If No, the system goes to Stop  416  and ceases adjusting the size of the target node. A similar set of activities occurs when the target node size is larger than desired, that is, when the user input returns a “demagnify” command. 
       FIG. 6  depicts a preferred embodiment for determining which nodes are on a most direct path between a user-selected first node and a user-selected second node. At step  610 , the system saves both a selected first node, called for convenience a source node, and a selected second node, called for convenience a target node. In step  620 , the system then sets the parent node equal to the source node. Then in step  620 , the system tests whether the parent node is an ancestor of both the source and the target nodes. If No, then at step  640  the system resets parent node to the parent of the parent node. Then at step  650  the system updates the Hierarchical View to display an icon over the reset parent node and updates the Zoomable Node View to display the reset parent node in zoomed format occupying substantially the entire display space as described above with reference to  FIG. 2 . Preferably, the system pauses in step  650  to allow the user to view the new parent node in the Zoomable Node View. Then the system recycles to decision step  630  where it determines whether the newly set parent node is an ancestor of both the source and target nodes. If No, the loop continues with the objective of finding the first common ancestor for both the source and target nodes. If Yes, then in step  660  the system displays the newly set common ancestor node in both the Hierarchical View and the Zoomable Node View in the manner described above. In order to determine which nodes are intermediate between the common ancestor node and the target node, the system must check each parent of the target node in turn until it finds that the selected parent is the common ancestor node. Thus at step  670  the system sets a parent node equal to the target node. At step  675  the system tests whether the newly set parent node is the common ancestor node determined at step  630 . If No, then at step  680  the system saves the parent node and sets a parent node equal to the parent of the parent node and recycles to decision step  675 . The system continues the cycling until the newly set parent node is the common ancestor node. When the common ancestor node is reached, the system determines a Yes at decision step  675  and proceeds to step  685  in which the system updates the Hierarchical View and the Zoomable Node View to show each saved parent node from the common ancestor node to the parent of the target node, and preferably pauses at each updated set of views. Then at step  690 , the system updates the views as above to show the target node and reaches the end step  699 . Preferably the system then waits for further user input. 
     While we have described a preferred embodiment of the invention, it will be understood that persons skilled in the art may make various changes that will be within the scope of the appended claims. In particular, it is not necessary to use a specific Model-View-Controller architecture to build the invention, although it is highly convenient to do so. Therefore these claims are intended to cover all modifications that fall within the spirit of the invention.