WO2001046798A2 - System and method for computer-aided graph-based dependency analysis - Google Patents

System and method for computer-aided graph-based dependency analysis Download PDF

Info

Publication number
WO2001046798A2
WO2001046798A2 PCT/IE2000/000160 IE0000160W WO0146798A2 WO 2001046798 A2 WO2001046798 A2 WO 2001046798A2 IE 0000160 W IE0000160 W IE 0000160W WO 0146798 A2 WO0146798 A2 WO 0146798A2
Authority
WO
WIPO (PCT)
Prior art keywords
graph
node
hinode
class
public
Prior art date
Application number
PCT/IE2000/000160
Other languages
French (fr)
Other versions
WO2001046798A8 (en
WO2001046798A3 (en
Inventor
Brendan O'reilly
Christopher Chedgey
Original Assignee
Headway Research Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Headway Research Limited filed Critical Headway Research Limited
Priority to AU22152/01A priority Critical patent/AU2215201A/en
Priority to IE20010131A priority patent/IES20010131A2/en
Publication of WO2001046798A2 publication Critical patent/WO2001046798A2/en
Publication of WO2001046798A3 publication Critical patent/WO2001046798A3/en
Publication of WO2001046798A8 publication Critical patent/WO2001046798A8/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/75—Structural analysis for program understanding

Definitions

  • the present invention is directed to methods and systems for computer-aided dependency analysis and design.
  • the invention relates to analysis of software such as C++ code.
  • UML Unified Modelling Language
  • Specialized reverse engineering tools offer the ability to parse existing source code and to provide the programmer with detailed information not readily available from the the source code. This is typically cross-reference or similar information. Although such tools sometimes claim to aid software comprehension, the information they provide is too detailed to help with "design-level” comprehension and is more suited to programming, debugging and maintenance activities.
  • Fig. 5 represents a histogram of the proportion of software developers versus the relative degree of forward- or reverse-engineering used to develop software.
  • formal specification is a rigorous forward-engineering practice used by relatively few developers.
  • Round-trip UML design is a somewhat less rigorous forward- engineering practice used by a substantial population of programmers, but not by the majority.
  • Source analysis 103 is a reverse-engineering practice only sometimes used in software development. The majority of developers representing most of the area under the histogram are under-served by existing technologies.
  • a software analysis tool comprising: means for converting software entities and their relationships into a graph having a structure of nodes interconnected by edges, and an editor comprising means for allowing a user to edit the graph, wherein the graph includes a meta node representing a child graph.
  • the conversion means comprises means for bi- directionally folding and unfolding a graph between meta and child levels.
  • the editor comprises means for automatically generating fresh graph layouts after manipulation.
  • the conversion means comprises a plurality of back-ends, each being associated with an aspect of a software system.
  • each back-end comprises means for converting the entities and the relationships of the associated aspect into nodes and edges of the graph.
  • the back-ends are associated with managers.
  • the managers comprise means for routing commands between the editor and the back-ends.
  • each manager is associated with a group of back- ends.
  • the back-ends associated with a particular manager share a common interface and set of operations.
  • the invention provides a dependency analysis system recorded on a computer-readable medium, comprising: a node class for instiating node objects in memory representing aspects of an analyzed system as nodes of a graph; a connection class for instantiating connection objects in memory representing dependencies between aspects of an analyzed system; an edge class for instantiating edge objects representing collections of one or more connections or edges
  • the system further comprises: at least one subclass of the node class, the subclass being specific to a particular category of system.
  • the invention provides a dependency analysis system recorded on a computer-readable medium, comprising: an abstraction layer for providing a uniform interface to third-party analysis tools; a graph model data structure for storing dependency information derived through the abstraction layer from third-party tools; a rendering system for providing a plurality of views of the graph model data structure.
  • Still another aspect of the invention provides a dependency analysis system comprising: a data structure stored in computer memory representing a hierarchy of graphs; a rendering system for displaying the hierarchy of graphs; a user interface responsive to a user action indicating a command to expand a displayed node, the user interface causing the rendering system to replace the displayed node with one or more child nodes in response to the user action.
  • Fig. 1 is a schematic diagram illustrating a software analysis tool of the invention
  • Fig. 2 is a diagram showing a multi-dimensional structure of a higraph
  • Fig. 3 is a sample display of an editor
  • Fig. 4 is a sample display after editor automatic layout
  • Fig. 5 is a histogram illustrating the state of the art
  • Fig. 6 is a sample higraph view of hiedges showing "depth"
  • Fig. 7 is a sample higraph view using a tree view and listview
  • Fig. 8 is a sample higraph view using a tree view and directed graph
  • Fig. 9 is a sample scratch graph view
  • Fig. 10 is a sample higraph listview with dependency viewer;
  • Fig. 11 is a sample circular layout higraph view showing clusters;
  • Fig. 12 shows the result of automatic folding of clusters
  • Fig. 13 shows a node expansion higraph view
  • Fig. 14 shows a cross-graph view
  • Fig. 15 also shows cross-graph view
  • Fig. 16 shows another cross-graph view
  • Fig. 17 shows a continuous value view of a higraph
  • Fig. 18 shows a view of a higraph comprising UML notation.
  • the present invention comprises a system and method for automatically generating and laying out directed graphs representing dependencies determined or analyzed by conventional code and system management tools, including source code, system deployment, version, and network management tools.
  • Two types of graph manipulation are supported: i) active manipulation in which changes to graph structure are propagated through the tools to change the structure of the analyzed system, and ii) passive manipulation by rearrangement and folding in which changes to graph sructure do not reflect or cause changes to the structure of the analyzed system.
  • FIG. 1 The architecture of one preferred embodiment is schematically illustrated in Fig. 1.
  • a three-layered architecture is employed.
  • a user-interface layer is provided by the higraph editor 20.
  • An abstraction layer 5 comprising a number of managers 10, 11, 12 provides a set of uniform interfaces to the higraph editor, while providing the interfaces required by conventional back-end tools 2,3,4.
  • a version manager 10 provides interfaces for manipulating source code version control systems such as Rational Clearcase, Microsoft SourceSafe, CNS, SCCS and res.
  • a deployment manager 11 provides interfaces for manipulating distributed computing systems such as Microsoft DCOM, lona Orbix, and Sun J2EE.
  • a back-end manager 12 provides interfaces for manipulating source code and integrated development environments such as C++ and Java source code, Microsoft Visual Studio, Rational Rose, and lona Orbix. Through these manager interfaces, the system extracts dependency information from the analyzed systems and presents it in the form of directed graphs rendered for viewing and for active or passive manipulation by the user through the higraph editor 20.
  • a system registry is used for back- end system discovery. Referring to Fig. 1 an analysis tool 1 of the invention is shown at a high level.
  • the tool 1 comprises three sets of back-ends 2, 3, and 4.
  • Each back-end is a conversion or translation function associated with an aspect of a software system.
  • each of the following aspects has an associated back-end:
  • a converter 5 of the tool 1 comprises the back-ends 2, 3, and 4 and also a number of managers.
  • Each backend scans the information available in its domain and represents this in the form of a graph.
  • a back end for a specific programming language scans the source code.
  • Files, packages, classes, methods and members may be represented as nodes, and dependency relationships between these language elements as edges between the corresponding nodes.
  • the back-end manager also defines the different types of nodes in its domain, and a graphical representation for each of these types.
  • the backend enacts any of the changes that pertain to its specific domain.
  • An example of this might be to move a Class from one Java Package to another in order to minimise the dependancies.
  • the user moves a node from one meta node to another in the editor 20, and the backend modifies the source code accordingly.
  • the backends invoke operations on the underlying operating system, on the APIs (Application Program Interface) of specific development tools, and interpret and modify data files that are created and read by such tools.
  • the managers serve as routers of commands between the editor 20 and the backends.
  • the editor 20 uses them in order to establish which backends are available, and to present this information to the user.
  • the managers route the corresponding commands to the correct backend.
  • user operations that require changes to the development environment are routed to the corresponding backend by the managers .
  • the backends controlled by a manager share a common interface and set of operations. Different managers are required because domains fall into different categories each providing a distinct set of capabilities. For example language specific backends may be required to move one language element to a new container, whereas version control backends may be required to provide a list of all the known versions of a particular element.
  • the converter 5 interfaces with an editor 20 which receives graph definitions from the converter 5 and represents them as multi-dimensional directed graphs. These graphs represent the entities as nodes and their relationships as edges.
  • a traditional directed graph Graph 1.
  • Graph 2 On the right hand side is an equivalent structure represented as a graph that consists of two separate directed graphs; Graph 2 and Graph 3.
  • nodes B, C and D are represented by a single meta-hinode identified as "Group" in the drawing.
  • a meta-hinode is a node that represents a child graph (in this case, Graph 3).
  • Any edges in the original directed graph that connect to or from nodes now represented by the meta-hinode are now represented by a meta-edge.
  • Each meta-edge indicates the existence of at least one relationship, and will in general represent multiple relationships.
  • the edge from node A to meta-hinode "Group” is a meta-edge that represents two edges (relationships) from A to B and A to C.
  • the editor 20 provides the user with a consistent interface with which the development environment may be viewed, analysed, comprehended and manipulated.
  • the editor 20 presents graphs to the user in a split window that shows the vertical view on the left and the horizontal view on the right.
  • Fig. 3 shows an example of an editor 20 display. Instead of a simple list of files on the right hand side of the window, the entities plus the relationships between them are displayed in the form of a directed graph.
  • the user can fold and unfold the directed graphs by simply using a mouse to select the nodes, and then selecting menu commands, clicking the toolbar, or dragging and dropping to new locations. 4. Navigation around the structure is achieved by mouse clicks and double clicks.
  • a higraph is a mapping/of a directed graph G onto a directed graph H of the same or fewer nodes, such that for every node i in G,f( ⁇ ) is a node in Hand for every arc (if) in G,f(i,j) is an arc in H.
  • a node in H may thus represent a group of nodes in G and an edge in Hmay represent a group of edges in G.
  • ⁇ igraphs may be nested, so that a higraph g mapping H to a graph I of yet fewer nodes is also a higraph.
  • a collection of higraphs ⁇ ⁇ such for each s,f s+J maps onto a graph of fewer nodes is also referred to as a higraph.
  • Such a higraph forms a hierarchy of graphs, each having fewer nodes than the last.
  • the nodes of a higraph are called hinodes. At the bottom of the hierarchy are the leafhinodes. All the leaf nodes plus the edges between them form the essential graph. A number of leaf nodes may be collected together in a higraph and represented by a single meta-hinode. Meta-hinodes may themselves be combined with other meta- hinodes and leaf nodes to form other meta-hinodes in a hierarchy. An edge between a meta-hinode and another node means that there is an edge on the essential graph between the latter and one or more of the children of the former.
  • FIG. 2 A simple example of a higraph is shown in Fig. 2.
  • Graph 1 on the left side is the essential graph of the HiGraph comprising Graph 2 and Graph 3 on the right side.
  • the 3 selected nodes on Graph 1 (B, C and D) are "folded" to create Graph 2 and Graph 3.
  • the 3 folded nodes are represented by a single meta-hinode called "Group”, and the Group node is associated with Graph 3 which contains the 3 folded nodes plus any edges between them.
  • the connections from A to B and C, and from D to E and F are retained. They are represented on Graph 2 by the edges from A to Group and from Group to E and F. Unfolding the Group node on Graph 2 will cause Graphs 2 and 3 to become Graph 1 again.
  • the system separates the logical model represented by the higraph from any specific user- visible view of that model. Views are constructed by the system from the model and presented to the user.
  • the model of a Higraph is composed of hinodes.
  • the hinodes immediately contained by a meta hinode are called its child hinodes.
  • the hinode which immediately contains another hinode is called its parent hinode.
  • All of the child hinodes and their child nodes down to the leafhinodes are called the descendants of the root hinode.
  • a leafhinode may become a meta hinode when it's children are discovered.
  • the leafhinodes preferably have a 1-1 correspondence with some entity in the environment under analysis. Many meta hinodes will also have such a 1-1 correspondence. Other meta hinodes may have a more tenuous relationship to the environment - they may be created temporarily by the user to group together other hinodes in order to assist with a specific task.
  • connections are maintained between hinodes.
  • a connection between two hinodes preferably implies that there is a 1-1 correspondence between the hinodes and some entities in the environment, and that there is some relationship between those entities. Connections are typed and there may be several different types of connections in a Higraph. Two hinodes may share more than one connection, and connections may exist between both leaf and meta hinodes.
  • a hiedge is a non-primitive relationship between two hinodes that ca ⁇ ies a definite set of connections.
  • a hiedge only exists because of the connections it carries, and does not exist on its own.
  • a hiedge exists between two hinodes if there is one or more connections between the hinodes, or if there is at least one connection between one of the hinodes or its decendants and the other hinode or one of its decendants.
  • hinodes are preferably not retained within the model, but calculated as needed from the pimitive connections and parent-child relationships.
  • higraphs are represented in computer memory as instances of Java classes corresponding to different aspects of the model as described below.
  • the HiGraph class comprises data and methods for representing and manipulating a higraph.
  • An instance of the HiGraph class provides an entry point to the hinode tree in the form of a root hinode and provides a number of utility methods for finding specific hinodes so that calling code can be shielded from recursive searching through the tree. This is facilitated by redundant storage of all hinodes in a flat collection.
  • the HiGraph class is also responsible for managing a collection of HiConnection objects defining the (direct) dependencies between individual nodes. The methods of the HiGraph class are described in Appendix 1.
  • the HiNode class is preferably an abstract class (i.e. it must be subclassed to be used) that comprises data and methods for representing and manipulating a hinode, and for navigating from hinode to hinode within a higraph. Instances of the HiNode class represent hinodes in a higraph. An instance of HiNode may or may not have children, as may be determined by the canHaveChildren method. An instance of HiNode may also be a meta-hinode, as may be determined by the isMeta method. If it is a meta-hinode, it may not carry any direct connections. The data fields and methods of the HiNode class are described in Appendix 2. Although preferably an abstract class, if DCOM compatibility is necessary, the HiNode class may preferably be a concrete class.
  • the HiNode class is also subclassed to provide a MetaNode class.
  • the MetaNode class comprises data and methods for representing and manipulating an abstract organizational meta-hinode within a higraph.
  • the methods of the MetaNode class are described in Appendix 3.
  • HiNode class is subclassed to provide hinode implementations specific particular domains of analysis. For example, for source code dependency analysis, instances HiNode subclasses ClassNode, FieldNode and MethodNode are respectively used to represent classes, data fields and methods of analyzed source code.
  • the ClassNode class comprises data and methods for representing and manipulating a hinode representing a source code class such as a Java class.
  • the methods of the ClassNode class are described in Appendix 4.
  • the FieldNode class comprises data and methods for representing and manipulating a hinode representing a data field of a source code class.
  • An instance of the FieldNode class always has an instance of the ClassNode class as its parent, and the canHaveChildren method of the FieldNode class always returns false.
  • the methods of the FieldNode class are described in Appendix 5.
  • the MethodNodeClass comprises data and methods for representing and manipulating a hinode representing a method of a source code class.
  • An instance of the MethodNode class always has an instance of the ClassNode class as its parent, and the canHaveChildren method of the MethodNode class always returns false.
  • the methods of the MethodNode class are described in Appendix 6.
  • Instances of the appropriate HiNode subclass are created using an instance of the NodeFactory class.
  • the NodeFactory class includes methods for creating new instances of available HiNode subclasses by specifying the desired type.
  • the HiEdge class is an abstract class that represents an edge between two nodes. Concrete subclasses are provided for each specific type of edge in this preferred embodiment, including a HiConnection class and a Relationship class.
  • the HiEdge class comprises constructor methods which require that the two nodes connected by the edge and the direction of the edge be specified to create an instance of the HiEdge class.
  • the data fields, constructors, and methods of the HiEdge abstract class are described in Appendix 7.
  • the HiConnection class comprises data and methods for representing and manipulating a primitive connection between hinodes.
  • the HiConnection class is a concrete subclass of the HiEdge class.
  • the HiConnection class comprises a constructor, but HiConnection objects are preferably created using the AddConnection method of a HiGraph object.
  • the Relationship class comprises data and methods for representing and manipulating a non-primitive hiedge that carries connections between hiedges.
  • the Relationship class is a concrete subclass of the HiEdge class. The methods of the Relationship class are described in Appendix 8 Rendering a Higraph Model as a View
  • a preferred interface provides the user with consistent context information so that he or she can see how the information currently displayed relates to the overall environment under analysis or control.
  • the preferred interface also allows the user to view information at the user's desired level of detail by enabling the user to group arbitrary sets of hinodes together while preserving and displaying the relationship (hiedges) of the group to the rest of the environment.
  • multiple views of a single Higraph model may be presented to the user, either simultaneously or alternatively.
  • Each view presents an identifiable subset of the Higraph information and provides user operations that change the view or model.
  • One view for presenting just parent/child relationships is the tree view shown on the left in Fig. 6, as used by many familiar file system browsers, such as the Microsoft "Windows Explorer".
  • Child hinodes are indented under the parent hinode, and the user can select how much detail is displayed by "expanding" parent nodes recursively.
  • a more expressive way to present just the hiedge relationships is to use a directed graph, where the nodes correspond to hinodes, and the edges represent hiedges.
  • a hinode is never displayed on the same directed graph as any of its ancestors or descendants. In this way, the user can "drill-down" to the level of detail required in the directed graph. This "drilling-down" operation, plus the information presented in tree view views maintains the user's sense of context.
  • FIG. 6 An important aspect to be conveyed by views is the "depth" of hinodes or edges. This is the number of connections carried by a hiedge, or the number of descendants of a meta-hinode. In the example illustrated in Fig. 6, the number of connections carried by each hiedge is displayed as a number next to the corresponding edge on the graph.
  • Fig. 7 a view similar to that of typical file browsers is illustrated. This combination of views is familiar to most computer users.
  • the view in the left panel uses a tree view to display the hierarchical aspect of the underlying logical Higraph model.
  • a list view shows the child hinodes of the currently selected hinode.
  • the two views work together so that when a node is selected on the left, the corresponding graph appears in the right. Double-clicking a node on the right causes the directed graph contained within the corresponding hinode to appear.
  • the user can re-arrange the Higraph using mouse operations to select, drag and drop nodes as with the Windows Explorer. For example, dropping one node on top of another will make the hinode corresponding to the former to be a child of that corresponding to the latter. The moved node disappears, and any hiedges that it had are merged with those shared by the new parent.
  • the columns of information provided on the right pane will be specific to the domain under analysis. Information pertaining to meta-hinodes is propagated up from descendant hinodes. It is possible to sort the rows based on any of the columns.
  • the left window functions as in Fig. 7.
  • the right window uses a directed graph to show relationships between hinodes at the currently selected level. This style is preferably restrictive to aid its function as a "base" view through which the user comprehends or modifies the structure of the underlying higraph.
  • the directed graph preferably always shows all the hinodes that share a single parent, and all of the hiedges between the displayed hinodes. Filtering may be permitted, but preferably not to the extent that the user loses the concept of a "base" view.
  • the scratch graph view illustrated in Fig. 9 gives the user flexibility to view hinodes on the same directed graph even if they do not share the same parent. This view is particularly useful for following or "chasing" dependencies across and into the higraph, cutting across the inherent higraph boundaries.
  • "+" and "-" buttons on each hinode let the user quickly expose or hide the associated hiedges. Double-clicking a meta-hinode causes just that hinode to be expanded within the current graph - the hinode disappears and is replaced by its children. The user can make the view more specific to analyzing dependencies by replacing the expanded meta-hinode with only those child nodes that have hiedges with other nodes currently on the graph.
  • the dependency viewer illustrated in the lower two panes of Fig. 10 presents a view of the higraph from the perspective of a single hinode.
  • a hinode in one of the other views such as the list view illustrated in the top pane of Fig. 10
  • all nodes connected to and from the selected node are displayed in the dependency viewer. Initially, the nodes are shown at the highest possible level (least detailed). If the user wishes to see which nodes within a meta hinode are used by the selected node, double clicking the meta node causes them to appear.
  • a number of different graph views are provided by a preferred system, including for example, hierarchical, circular, orthogonal and symmetrical.
  • the user also may rearrange nodes or sets of nodes manually, and pan and zoom to display selected areas of a graph.
  • the circular layout is particularly useful for identifying inherent "clusters" within graphs.
  • the user can easily modify the clustering parameters in order to find those most suited to the current graph.
  • the circular layout is illustrated in Fig. 11.
  • the user can instruct the system to fold the clusters shown in Fig. 11, resulting in the display illustrated in Fig. 12.
  • a user may also expand a meta-hinode and display its sub-graph nested within the current graph. Expansion is within expanded nodes is possible to an unlimited depth. Expanded nodes may also be re- collapsed. The user can also use this view to view nodes from other graphs that are connected to nodes in the current graph. Such nodes are clearly distinguishable as external to the current graph.
  • the system can also highlight nodes connected to a specific node, or in its dependency closure. In addition, the system can hide specific nodes or nodes that match certain criteria (e.g. nodes with more than a certain number of dependencies).
  • the preferred system always provides the user with the ability to rearrange the higraph to view the information most relevant to the user's task.
  • Cross-graph browsing allows the user to view dependency information that does not conform directly to the current Higraph structure, but without actually modifying the
  • Higraph For example, given the higraph view illustrated in Fig. 14, a user browsing down to Consumer, selecting the Consumer source file and issuing the command to "show usees on this graph" causes the view illustrated in Fig 15 to be displayed.
  • the "Supplier" directory is show in a distinguishable color or shape to indicate that it is from a different graph.
  • the dependency from Supplier to Notification_Receiver_Handler is also shown, and the graph is complete for all nodes shown. Selecting the Supplier directory and issuing the command "show children on this graph” results in an effect similar to Unfolding, except that the Higraph is not actually changed, as illustrated in Fig. 16.
  • the reverse of this operation is to select any of the nodes from a different graph and issue the command "show parent on this graph".
  • a meta-hinode is never displayed on the same graph as any of its descendants.
  • the system preferably permits nodes from the current graph to be hidden.
  • the view indicates that there are hidden nodes, and a command is provided to display all nodes that belong. If a node has dependencies, then selecting a + or - displayed on the node respectively causes those dependencies to be displayed or hidden. Nodes also have a fold/unfold symbol if they have children or parents.
  • the user may also create a number of different views of a single graph and store or view the multiple views simultaneously.
  • a "full" hierarchy may have a project containing a number of components each containing a number of modules each containing a number of classes. The user can choose to view the higraph for the project without the modules to show all the classes within a component, or without the modules or components to effectively see just the logical view..
  • Fig. 17 illustrates a graph that uses brightness to display the relative values - the darker the node the greater the value of the attribute. This feature can be used to enable the user to analyze such values as percent complete, lines of code, complexity, time since last modification (stability), percent changed, etc.
  • Unified Modeling Language can also be incorporated into the higraph views to add information for the UML-literate user.
  • Example Preferred Rendering Implementation The system may be implemented using any of several commercially available graphing libraries that support the rendering of directed graphs .
  • One preferred product is the Graphical Editor Toolkit (GET) from Tom Sawyer Software.
  • GET includes facilities for causing a directed graph to be displayed in a number of different layouts, specifically hierarchical, circular, orthogonal and symmetric.
  • the present system renders hinodes using GET by traversing the HiNode objects within the HiGraph object representing the higraph to be rendered, and using the information derived thereby to instantiate tsNode objects in the GET library.
  • GET uses tsNode objects to display nodes of a graph.
  • tsLables are associated with the tsEdges to indicate the "depth".
  • the specific nodes and edges are displayed in a graph is determined by the rules of the enclosing view. For example, the higraph in Fig. 8 is rendered with the Tom Sawyer GET.
  • the higraph contains all of the HiNodes returned by the GetChildren method of the HiNode object selected in the tree view. Once the nodes are displayed, a tsEdge is created for any connections returned by the getConnections method of each displayed Hinode for which both "ends" of the connection are on the graph.
  • the representations of the nodes varies according to their type. This is implemented by customizing the Tom Sawyer View Factory mechanism.
  • DoubleClickOnNode event is fired and the handler for this event checks the type of the node that was double-clicked.
  • Double-clicking on a "leaf node causes the corresponding file to be opened in the application defined for the file type (generally a back-end integrated development environment).
  • the system invokes GET to erase the selected tsDigraph, the corresponding hinode in the tree view is selected, and the tsDigraph is populated with the nodes and edges that correspond to the result of the getChildren method on the double-clicked node.
  • the directed graph illustrated in Fig. 9 is also implemented as a tsDigraph. In this case however there is no direct relationship between the tree view on the left and the tsDigraph since the Scratch Graph can display nodes from arbitrary locations in the higraph.
  • the Tom Sawyer View Factory mechanism is extended to add the "+” and "-” symbols.
  • the View Factory is also implemented so that the mouse symbol changes as it passes over these symbols, and to generate custom events when they are clicked by the user.
  • a "+" is clicked on the right of a tsNode such as the "HiGraph" tsNode in Fig. 9, the system displays all of the nodes to which this node is connected.
  • a user option to "show metanodes” specifies whether all of the connected classes are shown, or the connected meta-hinodes are shown at the highest level possible.
  • the former list of classes is obtained directly from the getConnections method of the HiNode instance corresponding to the tsNode on which the "+” was clicked.
  • the latter requires that the highest meta-hinodes be calculated as follows.
  • the findCommonAncestor method is invoked to find the lowest ancestor that is common with the selected node.
  • the displayed node is the child of the common ancestor that contains the connected node. Nodes are only displayed once, and if a connection is already represented as a tsEdge, then the "depth" of the hiedge is increased (this is displayed on the tsDigraph as a tsLabel).
  • the Tom Sawyer GET provides many parameters to fine tune each of the layout algorithms. Defaults suited to the application domain are set for most of the parameters. A small group of parameters may be usefully manipulated by the user. For example, when viewing large portions of software systems the circular layout can be useful. In this case, the most relevant parameter is the "degree" of the graph and the example implementation provides a "clustering" control just under the tool bar permitting the user to vary the degree parameter. The higher this number, the bigger the clusters. The system reads the clustering control and sets the "degree" property of the tsDigraph immediately prior to rendering a circular layout.
  • removeConnection public void removeConnection (HiConnection he, boolean flush) remove the passed HiConnection from the graph. Equivalent to calling removeO on the
  • getNodeMap public headway .util.ICollection getNodeMap returns a (readonly) collection containing all the nodes present in the graph irrespective of the nodetree structure Note that this does not include the root node findNode public HiNode findNode(long id) utility method to locate a specific node by key (equivalent to calling getElementO on the graph's NodeMap)
  • findNodeByName public HiNode findNodeByName(java.lang.String name) utility method which returns the first node found which matches the name passed or null if none found.
  • findFreeNodeName public java.lang.String findFreeNodeName(java.lang.String prefix) method which finds the first unused node name with the given prefix e.g. passing
  • cluster might return cluster 1, cluster 2, etc.
  • pathSeparator public static java.lang.String pathSeparator separation character used for path and fully qualified name
  • ID_NEW public static final long ID_NEW
  • ID_ROOT public static final long ID_ROOT
  • STATE_NO_DRIVER public static final int STATE_NO_DRIVER
  • ATTRIB_STATIC public static final int ATTRIB_STATIC
  • ATTRIB_SYNCHRONIZED public static final int ATTRIB_SYNCHRONIZED
  • ATTRIB THREADSAFE public static final int ATTRIB_THREADSAFE
  • ATTRIB_TRANSIENT public static final int ATTRIB_TRANSIENT
  • ATTRIB_NATIVE public static final int ATTRIB J .ATIVE
  • ATTRIB_ABSTRACT public static final int ATTRIB_ABSTRACT
  • setld protected void setld (long id) sets the id of this node
  • HiGraph hg setGraph protected void setGraph
  • setType public void setType (int type) sets the type of the node - the value corresponds to a constant defined in NodeFactory
  • setUML public void setUML(java.lang.String uml) sets a UML respresentation of this node
  • setAttributes public void setAttributes (int attributes) takes a bitmask value containing information on various attributes of the node, details see ACC constants
  • setParent protected void setParent(HiNode hn) sets the parent of this node
  • getType public int getType () returns the type of the node - the value corresponds to a constant defined in NodeFactory use getTypeStringO for a string version
  • setName public void setName(java.lang.String sName) sets the name of this node
  • setSourceFile public void setSourceFile(java.lang.String sourceFile) sets the source file name of this node
  • setState public void setState (int state) sets the state of this node
  • getKey public java.lang. Object getKeyO returns a string key unique to this node (stringified id) Specified by: getKey in interface headway .util.CollectionMember
  • getPath public javalang.String getPath() returns the path of this node (e.g. java.lang)
  • String getFQNameO returns the fully qualified name of this node (e.g. if the name is String and the path is /java/lang then the fully qualified name is /java/lang/ String)
  • getUserObject public java.lang.Object getUserObjectO returns a user-defined object saved with the setUserObjectO method
  • setUserObject public void setUserObject(java.lang.Object obj) used to store a reference to an arbitrary object
  • HiNode hn isSibling public boolean isSibling (HiNode hn) returns true if the passed HiNode is a sibling of this node, i.e. shares the same parent toString public java.lang.String toStringO returns the fully qualified name of the node
  • addChild public HiNode addChild creates and returns a new child node of the requested type Parameters: int - type as defined in NodeFactory long - known id of an existing object or ID_NEW (-1) for a new object
  • getRelationship public Relationship getRelationship (HiNode hn, int direction) returns a Relationship object describing the relationship between this node and the passed node for the given direction, a null relationship is signified by the isEmpty flag in the relationship object. A null pointer is returned if the passed node is itself null or if it is equal to "this" node
  • countConnections protected int countConnections (int runningTotal, int direction, HiNode ancestor) counts all connections with recursive calls if an ancestor node is supplied, connections where the referenced node is a descendant of the ancestor are ignored
  • Utility treewalking method which takes a HiNode argument which is assumed to be a descendant of this node and find the first descendant of this node which is also an ancestor of the passed node returns null if the node passed is not a descendant of this node
  • canHaveChildren public boolean canHaveChildren () Description copied from class: HiNode Returns true if this is can contain children Overrides: canHaveChildren in class HiNode
  • HiNode returns the state of this node
  • Appendix 7 Data Fields, Constructors, and Methods of HiEdge class
  • EXTENDS public static final int EXTENDS
  • HiEdge public HiEdge HiNode fromNode, HiNode toNode
  • makeKey public static java.lang.Long makeKey (HiNode hnl, HiNode hn2, int direction)
  • getNode public HiNode getNode (int direction) returns the referenced node for the given direction

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

The present invention is directed to a system and methods for analyzing dependencies. The dependencies that may be analyzed include, for example, dependencies among methods or procedures in software source code, or in system configuration or deployment. A layered system is provided, comprising a back-end layer, abstraction layer and user interface layer are used to derive dependency information from third-party tools, and present the information through uniform interfaces to a user-interface layer. The system maintains a dependency model as a hierarchical graph structure in computer memory, and provides a plurality of user views which may be manipulated actively or passively by the user. Active manipulations are propogated through the back-end layer to modify the system analyzed, and passive manipulations affect the user views without changing the analyzed system. The system provides advantages to users seeking to understand complex systems with many dependencies.

Description

SYSTEM AND METHOD FOR COMPUTER-AIDED GRAPH-BASED
DEPENDENCY ANALYSIS
Field of the Invention The present invention is directed to methods and systems for computer-aided dependency analysis and design. In one aspect, the invention relates to analysis of software such as C++ code.
Background of the Invention
One of the major problems in software development and maintenance is that of keeping track of the structure of the code so that changes may be made and, more generally, that the operation of the software may be understood.
Very often, too few developers know a particular application's source code and it's vagaries sufficiently well to be able to make changes quickly. The code itself is either poorly structured and/ or documented, usually as a result of being rushed into production, or because the code has been patched or layered too often without sufficient consideration. Even when code is properly structured and documented it can be equally difficult for someone to appreciate this fact without weeks of research. Before ever a line of code is touched, man weeks and months of effort go into understanding the application's innards. Difficult questions about which classes are grouped together as a component, which classes inherit from one another , which pieces of code pass parameters to one another, etc., all need to be answered before code is altered. The reason for this is that making a change in one part of the application can bring on changes in multiple other locations, and quite frequently unit testing of the code that has been changed may be insufficient, and more extensive regression or even system testing may be needed. This costs a lot of money, assuming that resources are available in the first instance. It also assumes that the human resources will continue in position for a sufficient period of time to understand the application so as to be able to make changes quickly. Programmers usually use text based editors to view code and make changes. Their managers normally understand the scope of developer's tasks by asking for diagrams, and discussing program source code attributes such as the number of lines of code, function points, number of classes etc. This normally takes place in meeting rooms using flip-charts which are pinned on the wall and used as references which of course change as time progresses. This is a time-consuming and inaccurate method for communication common and sharable information.
Traditional engineering practices that work well for hardware engineering have difficulty in dealing with software. Such practices involve a "top-down" (or more generally, spiral) process that produces design artifacts before manufacturing starts.
The closest analogy to "instructions for manufacturing" that applies to software are formal specifications. Formal specifications precisely define what software components should do without specifying how they are implemented. In principle this gives both programmers and testers descriptions from which to work independently.
Specification-driven development and testing is useful for applications in aerospace or the military with stable requirements, high reliability demands and few budget restrictions. This approach is not cost-effective for the majority of software projects.
The generally accepted "best practice" for mainstream software development is the spiral or iterative model used with the Unified Modelling Language (UML). This approach builds the product by incrementally analysing, designing, implementing and testing a set of use-cases. Each iteration results in an updated UML model and the corresponding executable software and test cases.
Many developers that have used the iterative/UML approach would agree that it adds a degree of rigour to the process, and that the UML diagrams serve as a useful roadmap and concise shorthand for the underlying source code. However, the cost and effort required to introduce UML may not always be justified by the benefit. It is an invasive method that requires a lot of training and change of work practices, which are not easily accomodated in gradual fashion. Models must be generated for all work in progress. The software industry is very time-sensitive, and schedule pressures mean that the delay today for a potential future gain cannot be tolerated.
The usefulness of UML models is also limited because the notion that there is a single design (albeit one that evolves) that serves all purposes throughout the life of the development is flawed. In reality each member of the development team, be they architect, designer, implementer, integrator, manager, teamleader, tester, configuration manager, project manager, product manager, etc., each require their own view of the software "design". The required view continually changes as the individual's activity changes. All these views must be accurate and consistent with some common underlying reality. Current UML tool offerings do not support such a dynamic, interactive, multi-view based usage, and this partly explains why there is not universal enthusiasm for UML modelling.
In an attempt to reduce the risks and costs while keeping the benefits, many organizations use UML as a reverse-engineering technology. This way, fewer staff need to be trained in the use of the method and tools. The diagrams are reverse engineered from the source code, and design documentation is produced after the product is implemented.
In principle this is a reasonable approach. In practice, most UML tools are really designed for forward engineering. While they do provide reverse (or "round- trip") engineering functionality, it is assumed that any changes from the model are relatively few and that the user can reasonably update the model organisation and layout manually.
This is certainly not the case for a large pre-existing or in-progress software project for which no model has ever been generated. Organising a reverse- engineered model using a forward-engineering tool is extremely laborious and is unlikely to either reflect the design intended by the developers, nor to expose an optimal inferred design.
Specialized reverse engineering tools offer the ability to parse existing source code and to provide the programmer with detailed information not readily available from the the source code. This is typically cross-reference or similar information. Although such tools sometimes claim to aid software comprehension, the information they provide is too detailed to help with "design-level" comprehension and is more suited to programming, debugging and maintenance activities.
There is clearly a rift between the available design technology and the needs of the development community. On offer is a choice between expensive, invasive, relatively static, forward-biased design tools and low-level, implementation-biased reverse-engineering tools. There is little or no tool support that addresses the status quo of mainstream software development.
The state of the art is schematically illustrated in Fig. 5, which represents a histogram of the proportion of software developers versus the relative degree of forward- or reverse-engineering used to develop software. As described above, formal specification is a rigorous forward-engineering practice used by relatively few developers. Round-trip UML design is a somewhat less rigorous forward- engineering practice used by a substantial population of programmers, but not by the majority. Source analysis 103 is a reverse-engineering practice only sometimes used in software development. The majority of developers representing most of the area under the histogram are under-served by existing technologies.
There is thus a need for a technology and notation that can be applied to existing or in-progress software development projects without the need for extensive training or change of work practices and minimal negative impact on on-going work. There is also a need for such a technology to support both large-scale reverse- engineering as well as efficient inference of relevant essential design information. A system that can provide highly interactive and dynamic views is needed, to enable individuals to expose and focus on information that pertains to the task in which they are engaged. Such a system should not simply construct static designs, but rather allow users to actively engage with the software, simultaneously exposing specific information and increasing overall comprehension.
Summaiy
According to one aspect of the invention, there is provided a software analysis tool comprising: means for converting software entities and their relationships into a graph having a structure of nodes interconnected by edges, and an editor comprising means for allowing a user to edit the graph, wherein the graph includes a meta node representing a child graph.
In another embodiment, the conversion means comprises means for bi- directionally folding and unfolding a graph between meta and child levels.
In one embodiment, the editor comprises means for automatically generating fresh graph layouts after manipulation.
In one embodiment, the conversion means comprises a plurality of back-ends, each being associated with an aspect of a software system.
In another embodiment, each back-end comprises means for converting the entities and the relationships of the associated aspect into nodes and edges of the graph.
In one embodiment, the back-ends are associated with managers.
In one embodiment, the managers comprise means for routing commands between the editor and the back-ends.
In another embodiment, each manager is associated with a group of back- ends. In one embodiment, the back-ends associated with a particular manager share a common interface and set of operations.
In another aspect, the invention provides a dependency analysis system recorded on a computer-readable medium, comprising: a node class for instiating node objects in memory representing aspects of an analyzed system as nodes of a graph; a connection class for instantiating connection objects in memory representing dependencies between aspects of an analyzed system; an edge class for instantiating edge objects representing collections of one or more connections or edges In one embodiment, the system further comprises: at least one subclass of the node class, the subclass being specific to a particular category of system.
In another aspect, the invention provides a dependency analysis system recorded on a computer-readable medium, comprising: an abstraction layer for providing a uniform interface to third-party analysis tools; a graph model data structure for storing dependency information derived through the abstraction layer from third-party tools; a rendering system for providing a plurality of views of the graph model data structure.
Still another aspect of the invention provides a dependency analysis system comprising: a data structure stored in computer memory representing a hierarchy of graphs; a rendering system for displaying the hierarchy of graphs; a user interface responsive to a user action indicating a command to expand a displayed node, the user interface causing the rendering system to replace the displayed node with one or more child nodes in response to the user action.
Brief Description of the Drawings The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings, in which.
Fig. 1 is a schematic diagram illustrating a software analysis tool of the invention;
Fig. 2 is a diagram showing a multi-dimensional structure of a higraph;
Fig. 3 is a sample display of an editor;
Fig. 4 is a sample display after editor automatic layout;
Fig. 5 is a histogram illustrating the state of the art; Fig. 6 is a sample higraph view of hiedges showing "depth";
Fig. 7 is a sample higraph view using a tree view and listview;
Fig. 8 is a sample higraph view using a tree view and directed graph;
Fig. 9 is a sample scratch graph view;
Fig. 10 is a sample higraph listview with dependency viewer; Fig. 11 is a sample circular layout higraph view showing clusters;
Fig. 12 shows the result of automatic folding of clusters;
Fig. 13 shows a node expansion higraph view;
Fig. 14 shows a cross-graph view;
Fig. 15 also shows cross-graph view; Fig. 16 shows another cross-graph view;
Fig. 17 shows a continuous value view of a higraph;
Fig. 18 shows a view of a higraph comprising UML notation.
Detailed Description The present invention comprises a system and method for automatically generating and laying out directed graphs representing dependencies determined or analyzed by conventional code and system management tools, including source code, system deployment, version, and network management tools. Two types of graph manipulation are supported: i) active manipulation in which changes to graph structure are propagated through the tools to change the structure of the analyzed system, and ii) passive manipulation by rearrangement and folding in which changes to graph sructure do not reflect or cause changes to the structure of the analyzed system.
These features allow the product to present the many software dependencies to the user in a way that enables them to quickly grasp the inherant structure of the software, and to display or abstract out details as required for the task at hand.
The architecture of one preferred embodiment is schematically illustrated in Fig. 1. A three-layered architecture is employed. A user-interface layer is provided by the higraph editor 20. An abstraction layer 5 comprising a number of managers 10, 11, 12 provides a set of uniform interfaces to the higraph editor, while providing the interfaces required by conventional back-end tools 2,3,4. A version manager 10 provides interfaces for manipulating source code version control systems such as Rational Clearcase, Microsoft SourceSafe, CNS, SCCS and res. A deployment manager 11 provides interfaces for manipulating distributed computing systems such as Microsoft DCOM, lona Orbix, and Sun J2EE. A back-end manager 12 provides interfaces for manipulating source code and integrated development environments such as C++ and Java source code, Microsoft Visual Studio, Rational Rose, and lona Orbix. Through these manager interfaces, the system extracts dependency information from the analyzed systems and presents it in the form of directed graphs rendered for viewing and for active or passive manipulation by the user through the higraph editor 20. In one preferred embodiment, a system registry is used for back- end system discovery. Referring to Fig. 1 an analysis tool 1 of the invention is shown at a high level.
The tool 1 comprises three sets of back-ends 2, 3, and 4. Each back-end is a conversion or translation function associated with an aspect of a software system. For example, each of the following aspects has an associated back-end:
(a) C++ Source files (b) Application Development Tool (one for each).
(c) A configuration management tool.
A converter 5 of the tool 1 comprises the back-ends 2, 3, and 4 and also a number of managers. In this embodiment, there is a version manager 10, a deployment manager 11, and a back-end manager 12. Each backend scans the information available in its domain and represents this in the form of a graph. For example, a back end for a specific programming language scans the source code. Files, packages, classes, methods and members may be represented as nodes, and dependency relationships between these language elements as edges between the corresponding nodes. The back-end manager also defines the different types of nodes in its domain, and a graphical representation for each of these types. If the user modifies the graph structure through the editor 20, and instructs that the corresponding change be made within the development environment, then the backend enacts any of the changes that pertain to its specific domain. An example of this might be to move a Class from one Java Package to another in order to minimise the dependancies. The user moves a node from one meta node to another in the editor 20, and the backend modifies the source code accordingly. The backends invoke operations on the underlying operating system, on the APIs (Application Program Interface) of specific development tools, and interpret and modify data files that are created and read by such tools.
The managers serve as routers of commands between the editor 20 and the backends. The editor 20 uses them in order to establish which backends are available, and to present this information to the user. When the user selects a specific domain to be imported to the editor 20, the managers route the corresponding commands to the correct backend. Likewise user operations that require changes to the development environment are routed to the corresponding backend by the managers .
There are several different managers, each responsible for a distinct set of backends. The backends controlled by a manager share a common interface and set of operations. Different managers are required because domains fall into different categories each providing a distinct set of capabilities. For example language specific backends may be required to move one language element to a new container, whereas version control backends may be required to provide a list of all the known versions of a particular element.
The converter 5 interfaces with an editor 20 which receives graph definitions from the converter 5 and represents them as multi-dimensional directed graphs. These graphs represent the entities as nodes and their relationships as edges. On the left hand side of an "equation" in Fig. 2 is a traditional directed graph, Graph 1. On the right hand side is an equivalent structure represented as a graph that consists of two separate directed graphs; Graph 2 and Graph 3. In Graph 2, nodes B, C and D are represented by a single meta-hinode identified as "Group" in the drawing. A meta-hinode is a node that represents a child graph (in this case, Graph 3). Any edges in the original directed graph that connect to or from nodes now represented by the meta-hinode are now represented by a meta-edge. Each meta-edge indicates the existence of at least one relationship, and will in general represent multiple relationships. In Fig. 2, for example, the edge from node A to meta-hinode "Group" is a meta-edge that represents two edges (relationships) from A to B and A to C.
The action of taking a number of nodes in a graph and replacing them by a meta-node, meta-edges and a corresponding child graph is called folding. The two graphs on the right hand side of Fig. 2 could be converted back to the graph on the left hand side by unfolding the meta-node in Graph 2.
The editor 20 provides the user with a consistent interface with which the development environment may be viewed, analysed, comprehended and manipulated. The editor 20 presents graphs to the user in a split window that shows the vertical view on the left and the horizontal view on the right. Fig. 3 shows an example of an editor 20 display. Instead of a simple list of files on the right hand side of the window, the entities plus the relationships between them are displayed in the form of a directed graph.
Often, when directed graphs are used in computer applications, they are difficult to manipulate and comprehend due to their inherent complexity, and the enormous amount of manual effort required to lay them out. Once the effort has been invested into laying them out, any form of significant manipulation is impractical since the layout process needs to be repeated.
However, the editor 20 allows a complex directed graph to be comprehended and manipulated. This is achieved by the following features in combination:
1. The various directed graphs in the structure are laid out automatically. Significant manipulation is now feasible since re-layout takes only seconds or less.
2. Several layout schemes and parameters are provided in order to assist the user to identify the inherent structure of the directed graphs (software development artifacts and processes). Figure 4 gives an example.
3. The user can fold and unfold the directed graphs by simply using a mouse to select the nodes, and then selecting menu commands, clicking the toolbar, or dragging and dropping to new locations. 4. Navigation around the structure is achieved by mouse clicks and double clicks.
The invention is not limited to the embodiments described, but may varied in construction and detail. Definitions
A directed graph is a finite set of nodes (also called vertices or points) N = { 1 ,2, ...m} and a set of directed arcs (also called links, branches, edges, or lines) A={(i,j),(k,l), ...,(s,t)} joining pairs of nodes in N. An arc (if) is directed from node to node/ In Fig. 2, graph 1 comprises the set of nodes N={A,B,C,D,E,F} and arcs _4={(A)B),(A,C),(B,D))(C)D))(D,E),(D)F)} .
A higraph is a mapping/of a directed graph G onto a directed graph H of the same or fewer nodes, such that for every node i in G,f(ϊ) is a node in Hand for every arc (if) in G,f(i,j) is an arc in H. Thus every node i in G corresponds to exactly one node m in H (i.e. there is only one node m in H such
Figure imgf000013_0001
but any node m in Hmay correspond to a group of more than one nodes in G (i.e. there may be more than one node {ih i^ i3,...} such that f(il)=f(i2)=f(i3)=m). H contains an edge (m,n) if and only if there is an edge (if) in G, where ^ = m a d fβ)=n. A node in Hmay thus represent a group of nodes in G and an edge in Hmay represent a group of edges in G. Ηigraphs may be nested, so that a higraph g mapping H to a graph I of yet fewer nodes is also a higraph. A collection of higraphs { } such for each s,fs+J maps onto a graph of fewer nodes is also referred to as a higraph. Such a higraph forms a hierarchy of graphs, each having fewer nodes than the last.
The nodes of a higraph are called hinodes. At the bottom of the hierarchy are the leafhinodes. All the leaf nodes plus the edges between them form the essential graph. A number of leaf nodes may be collected together in a higraph and represented by a single meta-hinode. Meta-hinodes may themselves be combined with other meta- hinodes and leaf nodes to form other meta-hinodes in a hierarchy. An edge between a meta-hinode and another node means that there is an edge on the essential graph between the latter and one or more of the children of the former.
A simple example of a higraph is shown in Fig. 2. In this example, Graph 1 on the left side is the essential graph of the HiGraph comprising Graph 2 and Graph 3 on the right side. The 3 selected nodes on Graph 1 (B, C and D) are "folded" to create Graph 2 and Graph 3. In Graph 2, the 3 folded nodes are represented by a single meta-hinode called "Group", and the Group node is associated with Graph 3 which contains the 3 folded nodes plus any edges between them. Although not explicitly shown on any graph, the connections from A to B and C, and from D to E and F are retained. They are represented on Graph 2 by the edges from A to Group and from Group to E and F. Unfolding the Group node on Graph 2 will cause Graphs 2 and 3 to become Graph 1 again.
In one preferred embodiment, the system separates the logical model represented by the higraph from any specific user- visible view of that model. Views are constructed by the system from the model and presented to the user.
The model of a Higraph is composed of hinodes. The hinodes immediately contained by a meta hinode are called its child hinodes. The hinode which immediately contains another hinode is called its parent hinode. All of the child hinodes and their child nodes down to the leafhinodes are called the descendants of the root hinode. A leafhinode may become a meta hinode when it's children are discovered.
The leafhinodes preferably have a 1-1 correspondence with some entity in the environment under analysis. Many meta hinodes will also have such a 1-1 correspondence. Other meta hinodes may have a more tenuous relationship to the environment - they may be created temporarily by the user to group together other hinodes in order to assist with a specific task.
Primitive relationships, called connections, are maintained between hinodes. A connection between two hinodes preferably implies that there is a 1-1 correspondence between the hinodes and some entities in the environment, and that there is some relationship between those entities. Connections are typed and there may be several different types of connections in a Higraph. Two hinodes may share more than one connection, and connections may exist between both leaf and meta hinodes.
A hiedge is a non-primitive relationship between two hinodes that caπies a definite set of connections. Preferably, a hiedge only exists because of the connections it carries, and does not exist on its own. A hiedge exists between two hinodes if there is one or more connections between the hinodes, or if there is at least one connection between one of the hinodes or its decendants and the other hinode or one of its decendants. As a non-primitive relationship, hinodes are preferably not retained within the model, but calculated as needed from the pimitive connections and parent-child relationships.
In one example preferred embodiment, higraphs are represented in computer memory as instances of Java classes corresponding to different aspects of the model as described below.
Example Preferred Higraph Model Java Embodiment In this preferred embodiment, the HiGraph class comprises data and methods for representing and manipulating a higraph. An instance of the HiGraph class provides an entry point to the hinode tree in the form of a root hinode and provides a number of utility methods for finding specific hinodes so that calling code can be shielded from recursive searching through the tree. This is facilitated by redundant storage of all hinodes in a flat collection. In addition to the hinode management functionality, the HiGraph class is also responsible for managing a collection of HiConnection objects defining the (direct) dependencies between individual nodes. The methods of the HiGraph class are described in Appendix 1.
The HiNode class is preferably an abstract class (i.e. it must be subclassed to be used) that comprises data and methods for representing and manipulating a hinode, and for navigating from hinode to hinode within a higraph. Instances of the HiNode class represent hinodes in a higraph. An instance of HiNode may or may not have children, as may be determined by the canHaveChildren method. An instance of HiNode may also be a meta-hinode, as may be determined by the isMeta method. If it is a meta-hinode, it may not carry any direct connections. The data fields and methods of the HiNode class are described in Appendix 2. Although preferably an abstract class, if DCOM compatibility is necessary, the HiNode class may preferably be a concrete class.
The HiNode class is also subclassed to provide a MetaNode class. The MetaNode class comprises data and methods for representing and manipulating an abstract organizational meta-hinode within a higraph. The methods of the MetaNode class are described in Appendix 3.
The HiNode class is subclassed to provide hinode implementations specific particular domains of analysis. For example, for source code dependency analysis, instances HiNode subclasses ClassNode, FieldNode and MethodNode are respectively used to represent classes, data fields and methods of analyzed source code.
The ClassNode class comprises data and methods for representing and manipulating a hinode representing a source code class such as a Java class. The methods of the ClassNode class are described in Appendix 4.
The FieldNode class comprises data and methods for representing and manipulating a hinode representing a data field of a source code class. An instance of the FieldNode class always has an instance of the ClassNode class as its parent, and the canHaveChildren method of the FieldNode class always returns false. The methods of the FieldNode class are described in Appendix 5.
The MethodNodeClass comprises data and methods for representing and manipulating a hinode representing a method of a source code class. An instance of the MethodNode class always has an instance of the ClassNode class as its parent, and the canHaveChildren method of the MethodNode class always returns false. The methods of the MethodNode class are described in Appendix 6. Instances of the appropriate HiNode subclass are created using an instance of the NodeFactory class. The NodeFactory class includes methods for creating new instances of available HiNode subclasses by specifying the desired type.
The HiEdge class is an abstract class that represents an edge between two nodes. Concrete subclasses are provided for each specific type of edge in this preferred embodiment, including a HiConnection class and a Relationship class. The HiEdge class comprises constructor methods which require that the two nodes connected by the edge and the direction of the edge be specified to create an instance of the HiEdge class. The data fields, constructors, and methods of the HiEdge abstract class are described in Appendix 7.
The HiConnection class comprises data and methods for representing and manipulating a primitive connection between hinodes. The HiConnection class is a concrete subclass of the HiEdge class. The HiConnection class comprises a constructor, but HiConnection objects are preferably created using the AddConnection method of a HiGraph object.
The Relationship class comprises data and methods for representing and manipulating a non-primitive hiedge that carries connections between hiedges. The Relationship class is a concrete subclass of the HiEdge class. The methods of the Relationship class are described in Appendix 8 Rendering a Higraph Model as a View
By providing a variety of different user-selectable renderings or views of a higraph, and allowing the user to perform both passive and active manipulations of the higraph using the views, it is possible to convey high-dimensional data of the higraph on a flat display. A preferred interface provides the user with consistent context information so that he or she can see how the information currently displayed relates to the overall environment under analysis or control.
The preferred interface also allows the user to view information at the user's desired level of detail by enabling the user to group arbitrary sets of hinodes together while preserving and displaying the relationship (hiedges) of the group to the rest of the environment. Preferably, multiple views of a single Higraph model may be presented to the user, either simultaneously or alternatively. Each view presents an identifiable subset of the Higraph information and provides user operations that change the view or model. One view for presenting just parent/child relationships is the tree view shown on the left in Fig. 6, as used by many familiar file system browsers, such as the Microsoft "Windows Explorer". Child hinodes are indented under the parent hinode, and the user can select how much detail is displayed by "expanding" parent nodes recursively. A more expressive way to present just the hiedge relationships is to use a directed graph, where the nodes correspond to hinodes, and the edges represent hiedges. Preferably, in order to maintain the user's sense of context, a hinode is never displayed on the same directed graph as any of its ancestors or descendants. In this way, the user can "drill-down" to the level of detail required in the directed graph. This "drilling-down" operation, plus the information presented in tree view views maintains the user's sense of context.
An important aspect to be conveyed by views is the "depth" of hinodes or edges. This is the number of connections carried by a hiedge, or the number of descendants of a meta-hinode. In the example illustrated in Fig. 6, the number of connections carried by each hiedge is displayed as a number next to the corresponding edge on the graph.
In Fig. 7, a view similar to that of typical file browsers is illustrated. This combination of views is familiar to most computer users. The view in the left panel uses a tree view to display the hierarchical aspect of the underlying logical Higraph model. In the right hand window, a list view shows the child hinodes of the currently selected hinode. The two views work together so that when a node is selected on the left, the corresponding graph appears in the right. Double-clicking a node on the right causes the directed graph contained within the corresponding hinode to appear. The user can re-arrange the Higraph using mouse operations to select, drag and drop nodes as with the Windows Explorer. For example, dropping one node on top of another will make the hinode corresponding to the former to be a child of that corresponding to the latter. The moved node disappears, and any hiedges that it had are merged with those shared by the new parent.
The columns of information provided on the right pane will be specific to the domain under analysis. Information pertaining to meta-hinodes is propagated up from descendant hinodes. It is possible to sort the rows based on any of the columns. In Fig. 8, the left window functions as in Fig. 7. The right window uses a directed graph to show relationships between hinodes at the currently selected level. This style is preferably restrictive to aid its function as a "base" view through which the user comprehends or modifies the structure of the underlying higraph. In particular, the directed graph preferably always shows all the hinodes that share a single parent, and all of the hiedges between the displayed hinodes. Filtering may be permitted, but preferably not to the extent that the user loses the concept of a "base" view.
Occasionally the user may find the base view too restrictive. The scratch graph view illustrated in Fig. 9 gives the user flexibility to view hinodes on the same directed graph even if they do not share the same parent. This view is particularly useful for following or "chasing" dependencies across and into the higraph, cutting across the inherent higraph boundaries. In the diagram, "+" and "-" buttons on each hinode let the user quickly expose or hide the associated hiedges. Double-clicking a meta-hinode causes just that hinode to be expanded within the current graph - the hinode disappears and is replaced by its children. The user can make the view more specific to analyzing dependencies by replacing the expanded meta-hinode with only those child nodes that have hiedges with other nodes currently on the graph.
The dependency viewer illustrated in the lower two panes of Fig. 10 presents a view of the higraph from the perspective of a single hinode. As the user selects a hinode in one of the other views, such as the list view illustrated in the top pane of Fig. 10, all nodes connected to and from the selected node are displayed in the dependency viewer. Initially, the nodes are shown at the highest possible level (least detailed). If the user wishes to see which nodes within a meta hinode are used by the selected node, double clicking the meta node causes them to appear.
A number of different graph views are provided by a preferred system, including for example, hierarchical, circular, orthogonal and symmetrical. The user also may rearrange nodes or sets of nodes manually, and pan and zoom to display selected areas of a graph.
The circular layout is particularly useful for identifying inherent "clusters" within graphs. The user can easily modify the clustering parameters in order to find those most suited to the current graph. The circular layout is illustrated in Fig. 11.
The user can instruct the system to fold the clusters shown in Fig. 11, resulting in the display illustrated in Fig. 12.
Using the view illustrated in Fig. 13, a user may also expand a meta-hinode and display its sub-graph nested within the current graph. Expansion is within expanded nodes is possible to an unlimited depth. Expanded nodes may also be re- collapsed. The user can also use this view to view nodes from other graphs that are connected to nodes in the current graph. Such nodes are clearly distinguishable as external to the current graph. The system can also highlight nodes connected to a specific node, or in its dependency closure. In addition, the system can hide specific nodes or nodes that match certain criteria (e.g. nodes with more than a certain number of dependencies).
The preferred system always provides the user with the ability to rearrange the higraph to view the information most relevant to the user's task. Cross-graph browsing allows the user to view dependency information that does not conform directly to the current Higraph structure, but without actually modifying the
Higraph. For example, given the higraph view illustrated in Fig. 14, a user browsing down to Consumer, selecting the Consumer source file and issuing the command to "show usees on this graph" causes the view illustrated in Fig 15 to be displayed.
In Fig. 15, the "Supplier" directory is show in a distinguishable color or shape to indicate that it is from a different graph. The dependency from Supplier to Notification_Receiver_Handler is also shown, and the graph is complete for all nodes shown. Selecting the Supplier directory and issuing the command "show children on this graph" results in an effect similar to Unfolding, except that the Higraph is not actually changed, as illustrated in Fig. 16. The reverse of this operation is to select any of the nodes from a different graph and issue the command "show parent on this graph". A meta-hinode is never displayed on the same graph as any of its descendants.
In addition to permitting the display of nodes that from other graphs, the system preferably permits nodes from the current graph to be hidden. The view indicates that there are hidden nodes, and a command is provided to display all nodes that belong. If a node has dependencies, then selecting a + or - displayed on the node respectively causes those dependencies to be displayed or hidden. Nodes also have a fold/unfold symbol if they have children or parents. The user may also create a number of different views of a single graph and store or view the multiple views simultaneously.
Another aspect to this capability is the ability to select the type of elements to be displayed within a hierarchy. For example, a "full" hierarchy may have a project containing a number of components each containing a number of modules each containing a number of classes. The user can choose to view the higraph for the project without the modules to show all the classes within a component, or without the modules or components to effectively see just the logical view..
The user can view any selected node attribute in such a way that the relative value of the attribute is easily discernable. Fig. 17 illustrates a graph that uses brightness to display the relative values - the darker the node the greater the value of the attribute. This feature can be used to enable the user to analyze such values as percent complete, lines of code, complexity, time since last modification (stability), percent changed, etc.
As illustrated in Fig. 18, Unified Modeling Language (UML) can also be incorporated into the higraph views to add information for the UML-literate user. Example Preferred Rendering Implementation The system may be implemented using any of several commercially available graphing libraries that support the rendering of directed graphs . One preferred product is the Graphical Editor Toolkit (GET) from Tom Sawyer Software. GET includes facilities for causing a directed graph to be displayed in a number of different layouts, specifically hierarchical, circular, orthogonal and symmetric.
The present system renders hinodes using GET by traversing the HiNode objects within the HiGraph object representing the higraph to be rendered, and using the information derived thereby to instantiate tsNode objects in the GET library. GET uses tsNode objects to display nodes of a graph. In general, there is a one-to- one correspondence between the rendered Hinodes of a Higraph and the tsNode objects in the Tom Sawyer library. Likewise, there is a correspondence between rendered Hiedges and tsEdge objects. tsLables are associated with the tsEdges to indicate the "depth". The specific nodes and edges are displayed in a graph is determined by the rules of the enclosing view. For example, the higraph in Fig. 8 is rendered with the Tom Sawyer GET.
The higraph contains all of the HiNodes returned by the GetChildren method of the HiNode object selected in the tree view. Once the nodes are displayed, a tsEdge is created for any connections returned by the getConnections method of each displayed Hinode for which both "ends" of the connection are on the graph. The representations of the nodes varies according to their type. This is implemented by customizing the Tom Sawyer View Factory mechanism.
When the user double-clicks on a node in a displayed GET tsDigraph, a DoubleClickOnNode event is fired and the handler for this event checks the type of the node that was double-clicked. Double-clicking on a "leaf node causes the corresponding file to be opened in the application defined for the file type (generally a back-end integrated development environment). When the user double-clicks on a meta-hinode, the system invokes GET to erase the selected tsDigraph, the corresponding hinode in the tree view is selected, and the tsDigraph is populated with the nodes and edges that correspond to the result of the getChildren method on the double-clicked node.
The directed graph illustrated in Fig. 9 is also implemented as a tsDigraph. In this case however there is no direct relationship between the tree view on the left and the tsDigraph since the Scratch Graph can display nodes from arbitrary locations in the higraph. The Tom Sawyer View Factory mechanism is extended to add the "+" and "-" symbols. The View Factory is also implemented so that the mouse symbol changes as it passes over these symbols, and to generate custom events when they are clicked by the user. When a "+" is clicked on the right of a tsNode such as the "HiGraph" tsNode in Fig. 9, the system displays all of the nodes to which this node is connected. A user option to "show metanodes" specifies whether all of the connected classes are shown, or the connected meta-hinodes are shown at the highest level possible. The former list of classes is obtained directly from the getConnections method of the HiNode instance corresponding to the tsNode on which the "+" was clicked. The latter requires that the highest meta-hinodes be calculated as follows. For each of the connected hinodes returned by the getConnections method of the HiNode, the findCommonAncestor method is invoked to find the lowest ancestor that is common with the selected node. The displayed node is the child of the common ancestor that contains the connected node. Nodes are only displayed once, and if a connection is already represented as a tsEdge, then the "depth" of the hiedge is increased (this is displayed on the tsDigraph as a tsLabel).
The Tom Sawyer GET provides many parameters to fine tune each of the layout algorithms. Defaults suited to the application domain are set for most of the parameters. A small group of parameters may be usefully manipulated by the user. For example, when viewing large portions of software systems the circular layout can be useful. In this case, the most relevant parameter is the "degree" of the graph and the example implementation provides a "clustering" control just under the tool bar permitting the user to vary the degree parameter. The higher this number, the bigger the clusters. The system reads the clustering control and sets the "degree" property of the tsDigraph immediately prior to rendering a circular layout.
Many variations of the preferred embodiments described in detail herein will be evident to those of skill in the art. The invention is not limited to those embodiments disclosed herein.
Appendix 1 - Methods of class HiGraph getRoot public HiNode getRoot () returns a HiNode object which forms the root of the node tree guaranteed to exist and cannot be deleted or moved
getConnectionMap public headway. util.ICollection getConnectionMap () returns a (readonly) map containing all essential connections present in the graph
addConnection public boolean addConnection(HiNode fromNode, HiNode toNode) Deprecated, create a new connection in the graph from the fromNode to the toNode
addConnection public boolean addConnection(HiConnection he) create a new connection in the graph from the fromNode to the toNode
removeConnection public void removeConnection (HiConnection he, boolean flush) remove the passed HiConnection from the graph. Equivalent to calling removeO on the
HiConnection
getNodeMap public headway .util.ICollection getNodeMap () returns a (readonly) collection containing all the nodes present in the graph irrespective of the nodetree structure Note that this does not include the root node findNode public HiNode findNode(long id) utility method to locate a specific node by key (equivalent to calling getElementO on the graph's NodeMap)
Returns the corresponding HiNode object or null if none exists
findNodeByName public HiNode findNodeByName(java.lang.String name) utility method which returns the first node found which matches the name passed or null if none found.
Since node names are not guaranteed to be unique, this method should be used with extreme care. It is also highly inefficient in that it needs to iterate all nodes in the graph doing a string compare on each.
findFreeNodeName public java.lang.String findFreeNodeName(java.lang.String prefix) method which finds the first unused node name with the given prefix e.g. passing
"cluster" might return cluster 1, cluster 2, etc.
removeNode public void removeNode (HiNode hn, boolean flush)
clear public void clear () clears the graph i.e. removes all nodes and connections
flush public void flush () clears the graph i.e. removes all nodes and connections
Specified by: flush in interface headway .util.Flushable getDirty public boolean getDirty ()
setDirty public void setDirty (boolean dirty)
setDriver public void setDriver(HGDriver driver)
getDriver public HGDriver getDriverO
Appendix 2 - Fields and Methods of class HiNode
Fields:
pathSeparator public static java.lang.String pathSeparator separation character used for path and fully qualified name
ID_NEW public static final long ID_NEW
ID_ROOT public static final long ID_ROOT
STATEJJNRESOLVED public static final int STATEJJNRESOLVED
State indicating that node has not yet been resolved (parsed)
STATE_RESOLVED public static final int STATE J.ESOLVED
State indicating that node has been successfully resolved (parsed)
STATEJJNRESOLVABLE public static final int STATEJUNRESOLVABLE State indicating that node could not be resolved
Information on the nature of the reolve failure can be obtained by calling getResolveFailureld
STATE_MISSING public static final int STATE_MISSING
Indicates that node is missing (and therefore unresolvable) STATE_WRONG_LOCATION public static final int STATE_WRONG_LOCATION
Indicates that node has no valid driver and is therefore not resolvable
STATE_NO_DRIVER public static final int STATE_NO_DRIVER
Indicates that node has no valid driver and is therefore not resolvable
ATTRIB_PUBLIC public static final int ATTRIBJPUBLIC
ATTRIB_PRIVATE public static final int ATTRIB JPRIVATE
ATTRIB JPROTECTED public static final int ATTRIB J>ROTECTED
ATTRIB_STATIC public static final int ATTRIB_STATIC
ATTRIB_FINAL public static final int ATTRIB_FINAL
ATTRIB_SYNCHRONIZED public static final int ATTRIB_SYNCHRONIZED
ATTRIB THREADSAFE public static final int ATTRIB_THREADSAFE
ATTRIB_TRANSIENT public static final int ATTRIB_TRANSIENT
ATTRIB_NATIVE public static final int ATTRIB J .ATIVE
ATTRIB JNTERFACE public static final int ATTRIB JNTERFACE
ATTRIB_ABSTRACT public static final int ATTRIB_ABSTRACT
comparator public HiNodeComparator comparator
Methods:
resolve public int resolve()
Triggers a parse of the underlying object and loading of connections
canHaveChildren public boolean canHaveChildren ()
Returns true if this HiNode can contain children
isMeta public boolean isMeta()
Returns true if this node is a metanode, i.e. cannot hold direct connections isClass public boolean isCIass()
setld protected void setld (long id) sets the id of this node
setGraph protected void setGraph (HiGraph hg) sets the graph in which this node lives
setType public void setType (int type) sets the type of the node - the value corresponds to a constant defined in NodeFactory
setUML public void setUML(java.lang.String uml) sets a UML respresentation of this node
getUML public Java. lang. String getUMLO returns a UML-style respresentation of this node
setAttributes public void setAttributes (int attributes) takes a bitmask value containing information on various attributes of the node, details see ACC constants
setParent protected void setParent(HiNode hn) sets the parent of this node
getType public int getType () returns the type of the node - the value corresponds to a constant defined in NodeFactory use getTypeStringO for a string version
getTypeString public java.lang.String getTypeStringO returns a string indicating the type of the node - the value corresponds to a constant defined in NodeFactory
getParent public HiNode getParentO returns the parent of the node (null if this is the root node)
setName public void setName(java.lang.String sName) sets the name of this node
getName public java.lang.String getNameO returns the name of this node
setSourceFile public void setSourceFile(java.lang.String sourceFile) sets the source file name of this node
getSourceFile public java.lang.String getSourceFile () returns the source file name of this node
setState public void setState (int state) sets the state of this node
getState public int getState () returns the state of this node
getAttributes public int getAttributes () returns a bitmask containing information on various attributes of the node, details see ACC constants
getAttribute public boolean getAttribute (int bit) returns a boolean indicating whether the passed attribute flag (or flags) are set in the attributes mask
getld public long getld () returns the unique id of this node
getKey public java.lang. Object getKeyO returns a string key unique to this node (stringified id) Specified by: getKey in interface headway .util.CollectionMember
isRoot public boolean isRootO returns true if this is the root node (i.e. parent is null)
getPath public javalang.String getPath() returns the path of this node (e.g. java.lang)
getFQName public java.lang. String getFQNameO returns the fully qualified name of this node (e.g. if the name is String and the path is /java/lang then the fully qualified name is /java/lang/ String)
getGraph public HiGraph getGraph () returns the graph in which this node resides
getUserObject public java.lang.Object getUserObjectO returns a user-defined object saved with the setUserObjectO method
setUserObject public void setUserObject(java.lang.Object obj) used to store a reference to an arbitrary object
equals public boolean equals (HiNode hn) true if the passed node is the same as this
isSibling public boolean isSibling (HiNode hn) returns true if the passed HiNode is a sibling of this node, i.e. shares the same parent toString public java.lang.String toStringO returns the fully qualified name of the node
Overrides: toString in class java.lang. Object
addChild public HiNode addChild (HiNode hn) creates and returns a new child node of the requested type Parameters: int - type as defined in NodeFactory long - known id of an existing object or ID_NEW (-1) for a new object
getChildren public headway.util.ICollection getChildrenO returns a JCollection of the children of this node throws an IllegalSomething exception if this node is a leaf
getChildren public headway.util.ICollection getChildren(HiNodeComparator comparator) returns a JCollection of the children of this node throws an IllegalSomething exception if this node is a leaf
moveTo public void moveTo (HiNode hn, boolean flush)
getConnections public headway.util.ICollection getConnections (int direction) returns a collection of connections for this node Parameters: int - the requested direction HiEdge.TO or HiEdge.FROM int - mode MODE CONNECTION DIRECT or MODE CONNECTION ANY
getRelationship public Relationship getRelationship (HiNode hn, int direction) returns a Relationship object describing the relationship between this node and the passed node for the given direction, a null relationship is signified by the isEmpty flag in the relationship object. A null pointer is returned if the passed node is itself null or if it is equal to "this" node
getChildRelationships public headway.util.ICollection getChildRelationships () convenience wrapper function which returns all the relationships between the child nodes of this node (which must be capable of having children)
getConnectionCount public int getConnectionCount (int direction) returns the total number of (potentially rolled up) connections which apply to this node in the given direction
countConnections protected int countConnections (int runningTotal, int direction, HiNode ancestor) counts all connections with recursive calls if an ancestor node is supplied, connections where the referenced node is a descendant of the ancestor are ignored
flush public void flush () clears the graph i.e. removes all nodes and connections
Specified by: flush in interface headwa .util.Flushable findCommonAncestor public HiNode findCommonAncestor(HiNode hn) Utility treewalking method which takes a HiNode argument and returns the (nearest) common ancestor, guaranteed to return a node (possibly root) provided that neither of this node nor the argument node passed is itself the root, in which case an IllegalArgumentException is thrown
Examples: this = rootjava.util.Nector hn = root.java.lang.String ret = root.java this = root.a.b.c.d hn = root.a.b.e.f.g.h.i ret = root.a b
findFirstDescendant public HiNode findFirstDescendant(H_Node hn)
Utility treewalking method which takes a HiNode argument which is assumed to be a descendant of this node and find the first descendant of this node which is also an ancestor of the passed node returns null if the node passed is not a descendant of this node
Examples: this = root. Java hn = root.java.lang.String ret = root.java.lang this = root.a.b hn = root.a.b.e.f.g.h.i ret = root.a.b.e
isDescendantOf public boolean isDescendantOf (HiNode hn)
setFQEntityName public void setFQEntityName(java.lang.String fqentityname) getFQEntityName public java.Iang.String getFQEntityNameO
getEntityName public java.lang.String getEntityNameO
getEntityPath public java.lang.String getEntityPathO
Appendix 3 - Methods of the MetaNode class
resolve public int resolve ()
Description copied from class: HiNode
Triggers a parse of the underlying object and loading of connections
Overrides: resolve in class HiNode
resolve public int resolve (boolean recursive)
canHaveChildren public boolean canHaveChildren () Description copied from class: HiNode Returns true if this is can contain children Overrides: canHaveChildren in class HiNode
isMeta public boolean isMetaO
Description copied from class: HiNode
Returns true if this node is a metanode, i.e. cannot hold direct connections Overrides: isMeta in class HiNode
getState public int getState ()
Description copied from class: HiNode returns the state of this node
Overrides: getState in class HiNode Appendix 4- Methods of the ClassNode class canHaveChildren public boolean canHaveChildren ()
Description copied from class: HiNode
Returns true if this is can contain children
Overrides: canHaveChildren in class HiNode
isMeta public boolean isMetaO Description copied from class: HiNode Returns true if this node is a metanode, i.e. cannot hold direct connections Overrides: isMeta in class HiNode
isClass public boolean isClass()
Overrides: isClass in class HiNode
isApplicationClass public boolean isApplicationClass ()
getFQSourceFile public java.lang.String getFQSourceFile()
resolve public final int resolve () Description copied from class: HiNode
Triggers a parse of the underlying object and loading of connections
Overrides: resolve in class HiNode Appendix 5 - Methods of the FieldNode Class canHaveChildren public boolean canHaveChildren ()
Description copied from class: HiNode
Returns true if this is can contain children
Overrides: canHaveChildren in class HiNode
isMeta public boolean isMetaO Description copied from class: HiNode Returns true if this node is a metanode, i.e. cannot hold direct connections Overrides: isMeta in class HiNode
getState public int getState ()
Description copied from class: HiNode returns the state of this node Overrides: getState in class HiNode
Appendix 6 - Methods of the MethodNode Class canHaveChildren public boolean canHaveChildren ()
Description copied from class: HiNode
Returns true if this is can contain children
Overrides: canHaveChildren in class HiNode
isMeta public boolean isMetaO Description copied from class: HiNode Returns tme if this node is a metanode, i.e. cannot hold direct connections Overrides: isMeta in class HiNode
getState public int getState ()
Description copied from class: HiNode returns the state of this node Overrides: getState in class HiNode
Appendix 7 - Data Fields, Constructors, and Methods of HiEdge class
Fields:
DEPENDENCY public static final int DEPENDENCY
AGGREGATION public static final int AGGREGATION
IMPLEMENTS public static final int IMPLEMENTS
EXTENDS public static final int EXTENDS
FROM public static final int FROM
TO public static final int TO
Constructors:
HiEdge public HiEdge (HiNode fromNode, HiNode toNode)
HiEdge public HiEdge(HiNode hnl, HiNode hn2, int direction) Methods: makeKey public static java.lang.Long makeKey (HiNode fromNode,
HiNode toNode)
makeKey public static java.lang.Long makeKey (HiNode hnl, HiNode hn2, int direction)
getNode public HiNode getNode (int direction) returns the referenced node for the given direction
getToggledNode public HiNode getToggledNode (int direction) returns the referenced node for the given direction
getKey public java.lang. Object getKeyO returns a unique key for this object implementation is a Long DWord-style long containing the fromNode id in the low word and the toNode id in the high word
Specified by: getKey in interface headway.util.CoUectionMember
getGraph public HiGraph getGraph () returns the graph in which the edge resides
toString public j ava.lang. String toString () Overrides: toString in class java.lang.Object
getType public int getType ()
setType public void setType (int type)
isDependency public boolean isDependency ()
isAggregation public boolean isAggregation ()
islmplements public boolean islmplements ()
isExtends public boolean isExtends ()
getVerboseName public java.lang.String getVerboseNameO returns a longwinded string version of the edge in the form A~>B, used mainly for debug purposes
toggleDirection public static int toggleDirection(int direction) getNodeld public long getNodeld (int direction)
Appendix 8 - Methods of Relationship Class
Methods: isMeta public boolean isMeta ()
getCarriedConnections public int getCarriedConnectionsO
isEmpty public boolean isEmptyO

Claims

Claims:
1. A software analysis tool comprising: means for converting software entities and their relationships into a graph having a structure of nodes interconnected by edges, and an editor comprising means for allowing a user to edit the graph, wherein the graph includes a meta node and edge representing a child graph.
2. A software analysis tool as claimed in claim 1, wherein the conversion means comprises means for bi-directionally folding and unfolding a graph between meta and child levels.
3. A software analysis tool as claimed in claim 1 or 2, wherein the editor comprises means for automatically generating fresh graph layouts after manipulation.
4. A software analysis tool as claimed in claim 1, 2 or 3, wherein the conversion means comprises a plurality of back-ends, each being associated with an aspect of a software system.
5. A software analysis tool as claimed in claim 4, wherein each back-end comprises means for converting the entities and the relationships of the associated aspect into nodes and edges of the graph.
6. A software analysis tool as claimed in claims 4 or 5, wherein the back-ends are associated with managers.
7. A software analysis tool as claimed in claim 6, wherein the managers comprise means for routing commands between the editor and the back-ends.
8. A software analysis tool as claimed in claims 6 or 7, wherein each manager is associated with a group of back-ends associated with a group of back-ends.
9. A software analysis tool as claimed in claim 8, wherein the back-ends associated with a particular manager share a common interface and set of operations.
10. A software analysis tool substantially as described with reference to the drawings.
11. A dependency analysis system recorded on a computer-readable medium, comprising: a node class for instiating node objects in memory representing aspects of an analyzed system as nodes of a graph; a connection class for instantiating connection objects in memory representing dependencies between aspects of an analyzed system; an edge class for instantiating edge objects representing collections of one or more connections or edges.
12. The dependency analysis system of claim 11, further comprising: at least one subclass of the node class, the subclass being specific to a particular category of system.
13. A dependency analysis system recorded on a computer-readable medium, comprising: an abstraction layer for providing a uniform interface to third-party analysis tools; a graph model data structure for storing dependency information derived through the abstraction layer from third-party tools; a rendering system for providing a plurality of views of the graph model data structure.
14. A dependency analysis system comprising: a data structure stored in computer memory representing a hierarchy of graphs; a rendering system for displaying the hierarchy of graphs; a user interface responsive to a user action indicating a command to expand a displayed node, the user interface causing the rendering system to replace the displayed node with one or more child nodes in response to the user action.
15. A software analysis tool substantially as described with reference to the drawings.
16. A dependency analysis sysetm substantially as described with reference to the drawings.
PCT/IE2000/000160 1999-12-20 2000-12-20 System and method for computer-aided graph-based dependency analysis WO2001046798A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU22152/01A AU2215201A (en) 1999-12-20 2000-12-20 System and method for computer-aided graph-based dependency analysis
IE20010131A IES20010131A2 (en) 1999-12-20 2000-12-20 System and method for computer-aided graph-based dependency analysis

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IE991070 1999-12-20
IE991070 1999-12-20

Publications (3)

Publication Number Publication Date
WO2001046798A2 true WO2001046798A2 (en) 2001-06-28
WO2001046798A3 WO2001046798A3 (en) 2002-09-12
WO2001046798A8 WO2001046798A8 (en) 2004-04-22

Family

ID=11042175

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IE2000/000160 WO2001046798A2 (en) 1999-12-20 2000-12-20 System and method for computer-aided graph-based dependency analysis

Country Status (4)

Country Link
US (2) US7409679B2 (en)
AU (1) AU2215201A (en)
IE (1) IES20010131A2 (en)
WO (1) WO2001046798A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004111841A2 (en) * 2003-06-12 2004-12-23 Symbian Software Limited A method of automatically analysing the structure of a software system
WO2009156198A1 (en) * 2008-06-27 2009-12-30 Siemens Aktiengesellschaft Method and system for generating of a control flow graph for representing a program code

Families Citing this family (103)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2355158C (en) * 1998-12-18 2010-12-07 Graham Paul Gordon A method of performing a system reverse engineering process
US20090254801A1 (en) * 2001-05-14 2009-10-08 The Mathworks, Inc. Model navigation
DE10161111A1 (en) * 2001-12-12 2003-07-03 Siemens Ag System and method for projecting transformations of object trees
US8015541B1 (en) * 2002-10-24 2011-09-06 Rage Frameworks, Inc. Business process technology for the enterprise
US20040111702A1 (en) * 2002-12-10 2004-06-10 Chan Kin Ming Method and apparatus for visual programming
US7680818B1 (en) * 2002-12-18 2010-03-16 Oracle International Corporation Analyzing the dependencies between objects in a system
US7385605B2 (en) * 2003-12-04 2008-06-10 International Business Machines Corporation Computer display system for dynamically modifying stacked area line graphs to change the order or presence of a set of stacked areas in the graph respectively representative of the proportions contributed to a total by each of a set of time dependent variables
US7469385B2 (en) * 2004-02-20 2008-12-23 Microsoft Corporation Methods and systems for abstraction of logical editing operations
US7970639B2 (en) * 2004-08-20 2011-06-28 Mark A Vucina Project management systems and methods
US7456840B2 (en) * 2004-08-31 2008-11-25 Oracle International Corporation Displaying information using nodes in a graph
US8051408B1 (en) 2004-09-13 2011-11-01 The Mathworks, Inc. Method of providing interactive usage descriptions based on source code analysis
US8984496B2 (en) * 2004-09-20 2015-03-17 The Mathworks, Inc. Extensible internal representation of systems with parallel and sequential implementations
US8812269B1 (en) * 2004-12-13 2014-08-19 The Mathworks, Inc. Dynamic range assessment in block diagram systems
US8855981B2 (en) * 2004-12-13 2014-10-07 The Mathworks, Inc. Tools for system-level design environments
WO2006091119A1 (en) * 2005-02-21 2006-08-31 Intel Corporation Method of stable incremental layout for a hierarchical graph representation
US7877350B2 (en) 2005-06-27 2011-01-25 Ab Initio Technology Llc Managing metadata for graph-based computations
US7716630B2 (en) * 2005-06-27 2010-05-11 Ab Initio Technology Llc Managing parameters for graph-based computations
WO2008121098A1 (en) * 2005-06-29 2008-10-09 Sue Kunz Software digital fingerprint
US9774699B2 (en) * 2005-09-20 2017-09-26 The Mathworks, Inc. System and method for transforming graphical models
US7376758B2 (en) * 2005-11-04 2008-05-20 Sun Microsystems, Inc. I/O dependency graphs
US7721269B2 (en) * 2005-12-23 2010-05-18 Sas Institute Inc. System and method for detecting redundant subroutine calls
US7904892B2 (en) * 2006-01-06 2011-03-08 Northrop Grumman Corporation Systems and methods for identifying and displaying dependencies
US8120610B1 (en) * 2006-03-15 2012-02-21 Adobe Systems Incorporated Methods and apparatus for using aliases to display logic
US7480712B2 (en) * 2006-03-21 2009-01-20 21St Century Technologies, Inc. Computer automated group detection
US7661076B2 (en) * 2006-03-31 2010-02-09 Microsoft Corporation Two dimensional trees to edit graph-like diagrams
US7933981B1 (en) * 2006-06-21 2011-04-26 Vmware, Inc. Method and apparatus for graphical representation of elements in a network
CN103729330B (en) 2006-08-10 2017-04-19 起元科技有限公司 Distributing services in graph-based computations
US7984426B2 (en) * 2006-12-28 2011-07-19 Sap Ag Graphical representation of dependencies between changes of source code
US7810079B2 (en) * 2007-01-23 2010-10-05 Sas Institute Inc. System and method for determining execution path difference in program
US8296741B1 (en) * 2007-03-05 2012-10-23 Google Inc. Identifying function-level code dependency by simulating runtime binding
CA2697306C (en) * 2007-07-26 2017-06-20 Craig W. Stanfill Transactional graph-based computation with error handling
US8823709B2 (en) 2007-11-01 2014-09-02 Ebay Inc. User interface framework for viewing large scale graphs on the web
US20090210750A1 (en) * 2008-02-19 2009-08-20 Sas Institute Inc. Systems And Methods For Identifying Memory Leaks In A Computer System
US8566796B2 (en) * 2008-04-04 2013-10-22 Sas Institute Inc. Systems and methods for interactions with software probes
US8549002B2 (en) * 2008-05-15 2013-10-01 Oracle International Corporation Cluster health indicator with dynamic load correlation
US8276113B2 (en) * 2008-08-11 2012-09-25 International Business Machines Corporation Dynamic highlighting of related artifacts in a UML diagram
USH2272H1 (en) * 2008-09-17 2012-11-06 The United States Of America As Represented By The Secretary Of The Navy Code framework for generic data extraction, analysis and reduction
US8307010B2 (en) * 2008-09-26 2012-11-06 Microsoft Corporation Data feature tracking through hierarchical node sets
WO2010067647A1 (en) * 2008-12-11 2010-06-17 インターナショナル・ビジネス・マシーンズ・コーポレーション Method for converting system model, computer program, and system model conversion device
JP4839424B2 (en) * 2008-12-15 2011-12-21 インターナショナル・ビジネス・マシーンズ・コーポレーション Method for supporting program analysis, and computer program and computer system thereof
US9886319B2 (en) 2009-02-13 2018-02-06 Ab Initio Technology Llc Task managing application for performing tasks based on messages received from a data processing application initiated by the task managing application
US7904754B2 (en) * 2009-03-18 2011-03-08 Sas Institute Inc. Systems and methods for automated determination of out of memory handling
US8276020B2 (en) 2009-03-18 2012-09-25 Sas Institute Inc. Systems and methods for automated determination of error handling
US8578326B2 (en) * 2009-03-26 2013-11-05 Microsoft Corporation Localized information-preserving levels in model visualization
US8875111B2 (en) * 2009-04-23 2014-10-28 Microsoft Corporation Intermediate language representation and modification
US8561015B2 (en) * 2009-06-15 2013-10-15 Microsoft Corporation Source code semantic zoom and spatial layout
US8713521B2 (en) * 2009-09-02 2014-04-29 International Business Machines Corporation Discovery, analysis, and visualization of dependencies
US8667329B2 (en) 2009-09-25 2014-03-04 Ab Initio Technology Llc Processing transactions in graph-based applications
US20110154004A1 (en) * 2009-12-23 2011-06-23 genForma Corp Installing and Configuring Software and/or Hardware Components Using Metadata Representations of Component Interdependencies
US9710355B2 (en) * 2010-01-14 2017-07-18 Microsoft Technology Licensing, Llc Selective loading of code elements for code analysis
US8875145B2 (en) 2010-06-15 2014-10-28 Ab Initio Technology Llc Dynamically loading graph-based computations
US9069559B2 (en) * 2010-06-30 2015-06-30 International Business Machines Corporation Modularizing steps within a UML user model interaction pattern
US9716632B2 (en) * 2010-08-24 2017-07-25 Hewlett Packard Enterprise Development Lp Interactive layered visualization of a layered software architecture
US9280574B2 (en) 2010-09-03 2016-03-08 Robert Lewis Jackson, JR. Relative classification of data objects
US8997024B2 (en) * 2010-12-09 2015-03-31 Microsoft Technology Licensing, Llc Navigating between views of a graph using placemarkers
US20120174068A1 (en) * 2010-12-30 2012-07-05 Sap Ag Testing Software Code
US8997084B2 (en) * 2011-04-20 2015-03-31 Hewlett-Packard Development Company, L.P. Method and apparatus for determining compatible versions of dependent entities in a computer system
US9355478B2 (en) * 2011-07-15 2016-05-31 Hewlett Packard Enterprise Development Lp Reflecting changes to graph-structured data
US9087150B2 (en) 2011-12-05 2015-07-21 International Business Machines Corporation Performance analysis system for analyzing inter-thread communications to enhance performance in multithreaded system
US8769501B2 (en) * 2011-12-07 2014-07-01 Siemens Aktiengesellschaft Method for analyzing changes in a software code and software analysis system
US10108521B2 (en) 2012-11-16 2018-10-23 Ab Initio Technology Llc Dynamic component performance monitoring
US9507682B2 (en) 2012-11-16 2016-11-29 Ab Initio Technology Llc Dynamic graph performance monitoring
US9274926B2 (en) 2013-01-03 2016-03-01 Ab Initio Technology Llc Configurable testing of computer programs
US9727635B2 (en) * 2013-02-06 2017-08-08 Abb Research Ltd. Combined code searching and automatic code navigation
US9389986B2 (en) * 2013-05-06 2016-07-12 Microsoft Technology Licensing, Llc Identifying impacted tests from statically collected data
JP6060813B2 (en) * 2013-05-20 2017-01-18 株式会社明電舎 Modeling method
US20140189652A1 (en) * 2013-05-21 2014-07-03 Concurix Corporation Filtering and Transforming a Graph Representing an Application
US9734040B2 (en) 2013-05-21 2017-08-15 Microsoft Technology Licensing, Llc Animated highlights in a graph representing an application
EP3000041A4 (en) * 2013-05-21 2017-05-10 Concurix Corporation Graph for navigating application code
US8990777B2 (en) 2013-05-21 2015-03-24 Concurix Corporation Interactive graph for navigating and monitoring execution of application code
US9280841B2 (en) 2013-07-24 2016-03-08 Microsoft Technology Licensing, Llc Event chain visualization of performance data
JP2016527254A (en) 2013-07-25 2016-09-08 リー エバーティング，シェリル Formulation for epidermis repair
US9292415B2 (en) 2013-09-04 2016-03-22 Microsoft Technology Licensing, Llc Module specific tracing in a shared module environment
US9116975B2 (en) * 2013-10-18 2015-08-25 Palantir Technologies Inc. Systems and user interfaces for dynamic and interactive simultaneous querying of multiple data stores
WO2015071777A1 (en) 2013-11-13 2015-05-21 Concurix Corporation Software component recommendation based on multiple trace runs
CA3114544A1 (en) 2013-12-05 2015-06-11 Ab Initio Technology Llc Managing interfaces for dataflow composed of sub-graphs
US10162606B2 (en) * 2013-12-09 2018-12-25 Apiosoft Aps Computer-implemented method for generating and visualizing data structures
US10275240B2 (en) 2015-05-28 2019-04-30 EntIT Software, LLC Dependency rank based on commit history
US10768925B2 (en) * 2015-06-01 2020-09-08 Microsoft Technology Licensing, Llc Performing partial analysis of a source code base
US10140120B2 (en) * 2015-06-15 2018-11-27 International Business Machines Corporation Context-specific view of a hierarchical data structure
US10657134B2 (en) 2015-08-05 2020-05-19 Ab Initio Technology Llc Selecting queries for execution on a stream of real-time data
US9323644B1 (en) 2015-09-30 2016-04-26 Semmle Limited Query-based software dependency analysis
CN105426499A (en) * 2015-11-25 2016-03-23 成都数联铭品科技有限公司 Implementation method of data visualization
AU2016377516B2 (en) 2015-12-21 2020-01-30 Ab Initio Technology Llc Sub-graph interface generation
US9760344B1 (en) * 2016-02-23 2017-09-12 Bank Of America Corporation Rules engine having an interactive, dual, side-by-side display
US20170277728A1 (en) * 2016-03-28 2017-09-28 International Business Machines Corporation Hiding nodes in a tree containing shared subtrees
US11853690B1 (en) 2016-05-31 2023-12-26 The Mathworks, Inc. Systems and methods for highlighting graphical models
US9900302B2 (en) 2016-06-22 2018-02-20 FinancialForce.com, Inc. Seamless authentication for an application development platform
US10984359B2 (en) 2016-06-23 2021-04-20 FinancialForce.com, Inc. Combining batch and queueable technologies in a salesforce platform for large volume parallel processing
US20180006897A1 (en) * 2016-06-30 2018-01-04 At&T Intellectual Property I, L.P. Systems and methods for modeling networks
US10530661B2 (en) 2016-06-30 2020-01-07 At&T Intellectual Property I, L.P. Systems and methods for modeling networks
US10437815B2 (en) * 2016-09-02 2019-10-08 Accenture Global Solutions Limited Identification of code object dependencies
US10496741B2 (en) 2016-09-21 2019-12-03 FinancialForce.com, Inc. Dynamic intermediate templates for richly formatted output
US10296439B1 (en) * 2017-11-17 2019-05-21 Amdocs Development Limited System, method, and computer program for documentation, communication, planning and control of software applications that support business needs
US11038689B2 (en) 2018-03-01 2021-06-15 FinancialForce.com, Inc. Efficient block chain generation
US10846481B2 (en) 2018-06-29 2020-11-24 FinancialForce.com, Inc. Method and system for bridging disparate platforms to automate a natural language interface
US11734480B2 (en) * 2018-12-18 2023-08-22 Microsoft Technology Licensing, Llc Performance modeling and analysis of microprocessors using dependency graphs
US11086619B2 (en) 2019-01-04 2021-08-10 Morgan Stanley Services Group Inc. Code analytics and publication platform
US11200143B2 (en) * 2019-01-08 2021-12-14 FinancialForce.com, Inc. Software development framework for a cloud computing platform
IL274981B1 (en) * 2019-05-28 2024-04-01 Apiiro Ltd System, Method, And Process For Continuously Identifying Material Changes And Calculating Risk for Applications and Infrastructure
US10922485B2 (en) 2019-07-10 2021-02-16 FinancialForce.com, Inc. Platform interpretation of user input converted into standardized input
US11120590B1 (en) 2020-04-28 2021-09-14 Robert Bosch Gmbh Hierarchy detection for block diagrams
CN111813440B (en) * 2020-07-21 2024-04-19 北京千丁互联科技有限公司 Multithreading application release method and device

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742738A (en) * 1988-05-20 1998-04-21 John R. Koza Simultaneous evolution of the architecture of a multi-part program to solve a problem using architecture altering operations
EP0528631B1 (en) * 1991-08-13 1998-05-20 Xerox Corporation Electronic image generation
US5692184A (en) * 1995-05-09 1997-11-25 Intergraph Corporation Object relationship management system
US5940083A (en) * 1997-04-01 1999-08-17 Novell, Inc. Multi-curve rendering modification apparatus and method
US6108006A (en) * 1997-04-03 2000-08-22 Microsoft Corporation Method and system for view-dependent refinement of progressive meshes
US6300957B1 (en) * 1998-07-29 2001-10-09 Inxight Software, Inc. Mapping a node-link structure to a rendering space beginning from any node
US6343376B1 (en) * 1998-10-22 2002-01-29 Computer Computer Corporation System and method for program verification and optimization
US6359635B1 (en) * 1999-02-03 2002-03-19 Cary D. Perttunen Methods, articles and apparatus for visibly representing information and for providing an input interface
US6339776B2 (en) * 1999-10-04 2002-01-15 International Business Machines Corporation Dynamic semi-structured repository for mining software and software-related information

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BAILEY D A ET AL: "PARAGRAPH: GRAPH EDITOR SUPPORT FOR PARALLEL PROGRAMMING ENVIRONMENTS" INTERNATIONAL JOURNAL OF PARALLEL PROGRAMMING, PLENUM PRESS, NEW YORK, US, vol. 19, no. 2, 1 April 1990 (1990-04-01), pages 75-110, XP000276598 ISSN: 0885-7458 *
WILSON J B: "THE C++ SOFTBENCH CLASS EDITOR" HEWLETT-PACKARD JOURNAL, HEWLETT-PACKARD CO. PALO ALTO, US, vol. 48, no. 1, 1 February 1997 (1997-02-01), pages 12-15, XP000722924 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004111841A2 (en) * 2003-06-12 2004-12-23 Symbian Software Limited A method of automatically analysing the structure of a software system
WO2004111841A3 (en) * 2003-06-12 2006-04-06 Symbian Software Ltd A method of automatically analysing the structure of a software system
WO2009156198A1 (en) * 2008-06-27 2009-12-30 Siemens Aktiengesellschaft Method and system for generating of a control flow graph for representing a program code
EP2141587A1 (en) 2008-06-27 2010-01-06 Siemens Aktiengesellschaft Method and system for generating of a control flow graph for representing a program code

Also Published As

Publication number Publication date
IES20010131A2 (en) 2001-05-30
US20080104570A1 (en) 2008-05-01
WO2001046798A8 (en) 2004-04-22
WO2001046798A3 (en) 2002-09-12
US7409679B2 (en) 2008-08-05
US20040205726A1 (en) 2004-10-14
AU2215201A (en) 2001-07-03

Similar Documents

Publication Publication Date Title
US7409679B2 (en) System and method for computer-aided graph-based dependency analysis
US20030067481A1 (en) System and method for computer-aided graph-based dependency analysis with integrated documentation
US7370315B1 (en) Visual programming environment providing synchronization between source code and graphical component objects
US5910803A (en) Network atlas mapping tool
US7114149B2 (en) Navigation links in generated documentation
US6993759B2 (en) Diagrammatic control of software in a version control system
Gansner et al. An open graph visualization system and its applications to software engineering
US7171646B2 (en) Generating source code for object oriented elements with language neutral transient meta model and correlating display of names, symbols and code
North et al. Applications of graph visualization
JP5102828B2 (en) Method and system for generating an application data editor
Elkoutbi et al. Generating user interface prototypes from scenarios
US20060150169A1 (en) Object model tree diagram
EP1290552A1 (en) Methods and systems for identifying dependencies between object-oriented elements
CA2354443A1 (en) Method and system for visually constructing xml schemas using an object-oriented model
Jäger Generating tools from graph-based specifications
US7949994B2 (en) Method and computer program product for viewing extendible models for legacy applications
EP1290550A1 (en) Diagrammatic control of software in a version control system
IE20001056A1 (en) System and method for computer-aided graph-based dependency analysis
Kremer Toward a multi-user, programmable web concept mapping" shell" to handle multiple formalisms
KR100283099B1 (en) Object-Oriented Modeling Tool and Its Logical and Graphical Information Processing Methods
Jahn et al. Remodeling to powertype pattern
Nguyen et al. Flexible fine-grained version control for software documents
EP1290553A1 (en) Methods and systems for finding and displaying linked objects
Jäger et al. UPGRADE: A Framework for Building Graph-Based Software Engineering Tools
Rose Using Rose

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DE DK DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
CFP Corrected version of a pamphlet front page
CR1 Correction of entry in section i

Free format text: IN PCT GAZETTE 26/2001 DUE TO A TECHNICAL PROBLEMAT THE TIME OF INTERNATIONAL PUBLICATION, SOME INFORMATION WAS MISSING UNDER (81). THE MISSING INFORMATION NOW APPEARS IN THE CORRECTED VERSION

NENP Non-entry into the national phase

Ref country code: JP