This invention relates to legacy software applications, and particularly to genetically visualizing and navigating extendible application models for legacy software applications in a unified diagram.
There are many “legacy” software applications that are utilized by businesses. These applications tend to be large, monolithic in structure, and lacking in documentation. The first step in maintaining and reusing these applications is to understand their architecture. Generating models and using graphical diagram tools to visualize application structure can be an effective way to help in understanding the applications.
However, it is expected that, for many legacy applications, these generated models will be quite large, consisting of thousands of nodes and connections. In this situation, user interface complexity becomes a big issue. For example, how should the model be displayed such that it provides meaningful information to the user and is easily navigable, without overwhelming the user with large volumes of information and user interface (UI) complexity. This becomes more of an issue in the modern Integrated Development Environment (IDE) which divides the screen window into many small views.
The traditional approach in commercial IDEs to display a large model is to provide filtering capability on top of the model to either include or exclude a subset of the model in the UI. Usually, this takes the form of the user specifying a name or attribute filter that is compared to each artifact. This can be useful if the artifacts follow a standard naming convention, but is ineffective if a name pattern cannot be derived that filters only the artifacts the user is interested in. Another drawback to such filtering is that connections between artifacts that are showing and artifacts that are filtered out are not shown. This forces the user to make a trade-off between a simpler UI and a loss of information being shown.
The traditional approach to displaying models that contain multiple levels of detail is to have the user specify which level of detail the user wants to see and only show details for that level. This is usually accomplished by providing a menu option to select the level of details. There are a couple drawbacks to this approach. First, the lower levels of detail may have thousands of nodes and connections and may contain so much information that the user and the UI hardware are both overwhelmed. Second, the approach described above causes each artifact type to determine how many levels of details are available, so some artifact types may have only two levels of details while others may have five. However, the user may want to see the second level of details for some artifacts, the third level of details for some artifacts, and the fourth level of details for others.
A second approach, the full-zoom approach, may reveal different level of details in datasets according to the zoom level chosen by user, i.e., the full-zoom approach provides details only on a current zoom level without higher level data. The problem is that the user does not have enough context when the user is zoomed in.
A third approach is to show details for the part that the user selected while showing less detail for other parts of the structure. The third approach uses a degree of interest function to decide which part should be shown in details.
The second and third approaches, however, do not define a unified semantic model which can be visualized consistently across different types of input to the modeling tool. In order to apply the second and third approaches, the diagram user interface developer has to understand the particular application and apply the approach case by case which is tedious and inefficient.
It would be desirable to have an approach which generically and effectively navigates very large extensible application models in an IDE, which would greatly improve the usability of the diagram tool, and which would make it easy for an IDE tool developer to build the navigation function generically.