US20100077340A1

Movatterモバイル変換

Info

Publication number: US20100077340A1
Application number: US12/233,993
Authority: US
Inventors: Paul B. French; Mark J. Lucas; Kieran Moynihan
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2008-09-19
Filing date: 2008-09-19
Publication date: 2010-03-25
Also published as: US8225230B2

Abstract

Supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects by limiting one or more object instances in the object model and filtering one or more attributes associated with one or more of the object instances. The limiting and filtering is performed by utilizing a plurality of windows, panels, or sub-windows to display a corresponding list of one or more objects for a dimension, along with one or more attributes associated with each of the one or more objects; and updating a second window, panel, or sub-window in response to receiving a selection of an item from a first window, panel, or sub-window according to a relationship defined in the object model, wherein the updating is performed in a hierarchical manner.

Description

BACKGROUND

This invention relates to the field of computing and, in particular, to methods, computer program products, and hardware products for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects.

In a system with an object model in which multiple dependencies exist between objects, it is difficult to provide a visualization mechanism for a single filtered display of the instances and attributes of that model. For example,FIG. 1 sets forth an illustrative prior art multidimensional model. A first dimension, shown asdimension A101, represents a plurality of customers. Dimension A101 includes one or more attributes denoted as a₁-a_i. If only one attribute is employed, it is denoted as a₁, whereas if one or more attributes are employed in addition to a₁, they are denoted as a_iwhere i represents a positive integer greater than one. Each of the plurality of customers subscribes to one or more services represented by a second dimension,dimension B103.Dimension B103 includes one or more attributes denoted as b1-bj. If only one attribute is employed, it is denoted as b₁, whereas if one or more attributes are employed in addition to b₁, they are denoted as b_jwhere j represents a positive integer greater than one.

Each of the plurality of services is implemented by one or more networks or network elements represented by a third dimension,dimension C105. Dimension C103 includes one or more attributes denoted as c₁-c_k. If only one attribute is employed, it is denoted as c₁, whereas if one or more attributes are employed in addition to c₁, they are denoted as c_kwhere k represents a positive integer greater than one. Each of the plurality of networks or network elements is supported by one or more devices represented by a fourth dimension,dimension D107.Dimension D107 includes one or more attributes denoted as d₁-d_h. If only one attribute is employed, it is denoted as d₁, whereas if one or more attributes are employed in addition to d₁, they are denoted as d_hwhere h represents a positive integer greater than one. Each of the plurality of devices is used by one or more customers represented by the first dimension,dimension A101.

Considering the multidimensional model ofFIG. 1, it is apparent that there is a high cardinality of both object instances and inter-dependencies of models. Unfortunately, existing object models do not provide any mechanism by which a user can obtain a filtered display of related objects and their attributes to allow navigation between such objects. For example, presently existing object models do not provide a consolidated view of Operational Support System (OSS) data in a fixed mobile converged telecommunications service assurance environment. Rather, current OSS's for use in service assurance environments are stove-piped, such that the OSS's only examine one or more data sets associated with the network, the customer, services, or devices. However, many different OSS systems are required for service management, such as Network Fault Management, Network Performance Management (PM), Network Inventory Systems, Service Inventory, Service Quality Management (SQM), Service Level Management (SLM), Customer Experience Management (CEM), Device Management Systems, and Customer Relationship Management (CRM). Relating information between these systems is a manual process and subject to error. Errors are attributable to different naming schemes for objects, incomplete coverage, duplication, as well as a variety of other causes.

SUMMARY

A method supports a visualization of an object model in which multiple dependencies exist between each of a plurality of objects by limiting one or more object instances in the object model and filtering one or more attributes associated with one or more of the object instances. The limiting and filtering is performed by utilizing each of a plurality of respective windows, panels, or sub-windows to display a corresponding list of one or more objects for a dimension of a plurality of dimensions, along with one or more attributes associated with each of the one or more objects. At least a second window, panel, or sub-window of the plurality of respective windows, panels, or sub-windows is updated in response to receiving a selection of an item from a first window, panel, or sub-window of the plurality of respective window, panels, or sub-windows according to a first relationship defined in the object model. The updating is performed in a hierarchical manner wherein at least a third window, panel, or sub-window of the plurality of respective windows, panels, or sub-windows is updated in response to receiving a selection of an item from the second window, panel, or sub-window according to a second relationship defined in the object model. A filtering procedure is performed across the plurality of dimensions to restrict one or more instances of the one or more objects to be displayed in the plurality of respective windows, panels, or sub-windows to thereby control and manage the visualization of the object model wherein the object model provides a high cardinality of objects.

Computer program products and hardware products corresponding to the above-summarized methods are also described and claimed herein. Other methods, hardware products, and/or computer program products according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional methods, hardware products, and/or computer program products be included within this description, be within the scope of the present invention, and be protected by the accompanying claims.

Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. For a better understanding of the invention with advantages and features, refer to the description and to the drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

FIG. 1 is a block diagram setting forth an illustrative prior art multidimensional model in which multiple dependencies exist between each of a plurality of objects.

FIG. 2 is a flowchart setting forth a first illustrative operational sequence for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects.

FIG. 3 is a block diagram of an illustrative hierarchical filtered dashboard system for use with the procedure ofFIG. 2.

FIG. 4 is a block diagram of an illustrative multi-dimensional dependency model for use with the hierarchical filtered dashboard system ofFIG. 3.

FIG. 5 is a diagram of an illustrative hierarchical dashboard display prepared using the method ofFIG. 2.

FIG. 6 is a diagram showing exemplary metadata for defining hierarchical dashboard displays.

FIG. 7 shows an illustrative hierarchical dashboard display constructed using the method ofFIG. 2.

FIG. 8 is a flowchart setting forth a second illustrative operational sequence for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects.

FIG. 9 is a block diagram setting forth an illustrative computer program product or hardware product for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects.

The detailed description explains the preferred embodiments of the invention, together with advantages and features, by way of example with reference to the drawings.

DETAILED DESCRIPTION

FIG. 2 is a flowchart setting forth an illustrative operational sequence for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects. The operational sequence ofFIG. 2 commences atblock201 where one or more object instances in the object model are limited to provide one or more limited object instances, and one or more attributes associated with one or more of the limited object instances are filtered. Atblock203, the limiting and filtering is performed by utilizing each of a plurality of respective windows, panels, or sub-windows to display a corresponding list of one or more objects for a dimension of a plurality of dimensions, along with one or more attributes associated with each of the one or more objects. Next, atblock205, at least a second window, panel, or sub-window of the plurality of respective windows, panels, or sub-windows is updated in response to receiving a selection of an item from a first window, panel, or sub-window of the plurality of respective window, panels, or sub-windows according to a first relationship defined in the object model.

Atblock207, the updating is performed in a hierarchical manner wherein at least a third window, panel, or sub-window of the plurality of respective windows, panels, or sub-windows is updated in response to receiving a selection of an item from the second window, panel, or sub-window according to a second relationship defined in the object model. Then, atblock209, a filtering procedure is performed across the plurality of dimensions to restrict one or more instances of the one or more objects to be displayed in the plurality of respective windows, panels, or sub-windows to thereby control and manage the visualization of the object model wherein the object model provides a high cardinality of objects.

Consider an illustrative hierarchical filtereddashboard system300 as shown inFIG. 3. Thedashboard system300 includes amulti-dimensional dependency model302 operatively coupled to an application program interface (API)305. A hierarchical dashboardsub-window management system304 is operatively coupled to theAPI305. The hierarchical dashboardsub-window management system304 is in communication with adashboard sub-window configuration306. Ahierarchical dashboard display308, operatively coupled to the hierarchical dashboardsub-window management system304, includes amulti-dimensional filter component310.

Themulti-dimensional dependency model302 provides information for driving thehierarchical dashboard display308. Themulti-dimensional dependency model302 itself (and theAPI305 to the model) provides the abilities to: (a) query related instances of one object with others in a dependency chain, and (b) query a value of attributes for objects in the dependency chain.

FIG. 4 is a block diagram of an illustrative multi-dimensional dependency model302 (FIGS. 3 and 4) for use with the hierarchical filtereddashboard system300 ofFIG. 3. The multi-dimensional filter component310 (FIGS. 3 and 4) allows a user to filter one or more instances of related objects to be displayed. Themulti-dimensional filter component310 takes into account one or more relationships between objects. This filter is used by the hierarchical filtereddashboard system300 to limit one or more object instances that are displayed in each of a plurality of sub-windows (to be described in greater detail hereinafter with reference toFIG. 5) by themultidimensional filter component310.

FIG. 5 is a diagram of an illustrativehierarchical dashboard display308 prepared using the method ofFIG. 2. Thehierarchical dashboard display308 includes a plurality of sub-windows such as a first sub-window designated as sub-window1511, a second sub-window designated as sub-window2512, and a third sub-window designated as sub-window3513. At least one ofsub-window1511, sub-window2512, or sub-window3513 display related objects and attributes for one or more dimensions such as Dimension A101 (FIGS.1 and5)—Customers,Dimension B103—Services,Dimension C105—Network andDimension D107—Devices. There are two types of sub-windows: anchor sub-windows502 (FIG. 5) accessed from ananchor panel504, and subordinate sub-windows, examples of which are sub-window1511, sub-window2512, and sub-window3513 (to be described hereinafter with reference toFIG. 6) that are accessed from theanchor sub-windows502.Anchor panel504 is controlled by alist control514 mechanism.List control514 operates such that, when a list item is selected, at least one ofsub-window1511, sub-window2512, or sub-window3513 are populated with details of an item selected from theanchor panel504.

The hierarchical dashboard display (FIG. 5) includes a plurality ofdashboard tabs506. Each respective dashboard tab ofdashboard tabs506 launches a corresponding dashboard. The corresponding dashboard may, but need not, correspond with one or more of the dimensions described previously in conjunction withFIG. 1, such asDimension A101—Customer,Dimension B103—Service,Dimension C105—Network, andDimension C107—Device. Thus, ifdashboard tabs506 are to be used in an illustrative environment of a fixed mobile converged service assurance telecommunications system, thesedashboard tabs506 may include a first tab labeled “Customer”, a second tab labeled “Service”, a third tab labeled “Network”, and a fourth tab labeled “Device”, along with an optional performance management (PM) tab.

Thehierarchical dashboard display308 includes a plurality ofrespective problem indicators508 each associated with a corresponding dashboard tab ofdashboard tabs506. Illustratively, a respective problem indicator ofproblem indicators508 is displayed in a color that is indicative of whether a corresponding dashboard tab ofdashboard tabs506 is experiencing any problem. Thehierarchical dashboard display308 also includes afiltering component510. Thefiltering component510 implements a filtering process on related instance data.

FIG. 6 is a diagram showing exemplary metadata for defining hierarchical dashboard displays. More specifically,FIG. 6 shows an illustrative set of sub-windows that are displayed in thehierarchical dashboard display308 ofFIG. 5. As previously discussed, there are two types of sub-windows. A first type of sub-window is theanchor panel504. A second type of sub-window includes subordinate sub-windows such as sub-window1511 (FIGS. 5 and 6), sub-window2512, sub-window3513, sub-window4524, and sub-window6525. The anchor panel504 (FIGS. 5 and 6) is a sub-window, illustratively at the top left corner of the hierarchical dashboard display308 (FIG. 5), that may be conceptualized as the driving window of the dashboard display and containing data which is the primary focus of the dashboard display. Selection of a row in the anchor panel504 (FIGS. 5 and 6) sub-window, such as a first row530 (FIG. 5) or a second row531 (FIG. 5) causes what is displayed in (some or all) subordinate sub-windows to update accordingly.

As indicated previously, the dashboard display308 (FIG. 5) may contain one or more subordinate sub-windows such as sub-window1511 (FIGS. 5 and 6), sub-window2512, sub-window3513, sub-window4524, and sub-window6525. Selection of one ormore rows530,531 (FIG. 5) in theanchor panel504 sub-window causes the data in other sub-windows to update. The list of subordinate sub-windows which get triggered to update themselves when the selection of the anchor panel504 (i.e., parent window) changes is termed the ‘scope of control’ of the parent window. This scope of control is hierarchical. This means that a parent window has scope of control over sub-windows at the next level of scope, which in turn can have scope of control over other sub-windows in a hierarchical manner (i.e. no overlap).

For example, thedashboard display308 ofFIG. 6 contains

anchor panel

504 and6 sub-windows. The dashboard may be configured to have sub-window1511, sub-window2512, and sub-window3513 change when theanchor panel504 changes. However, sub-window4524 is triggered to update only when sub-window3513 is changed, and sub-window6525 is triggered to updated only when sub-window4524 is updated.

FIG. 7 shows an illustrative dashboard display708 constructed using the method ofFIG. 2. The sample dashboard display708 is constructed such that an anchor panel called Ranked Alarms704 affects a first sub-window called Related Services705. The Related Services705 sub-window, in turn, affects a second sub-window called Key Ranking/Priority Statistics706. Attributes for one or more objects in the anchor panel, or the sub-windows, or the anchor panel and the sub-windows, are displayed. The specification of what attributes are displayed for each object class/dimension are part of a configuration for the dashboard sub-window.

Dashboard tabs506 (FIG. 5) are graphical user interface elements that are used to launch different dashboards.Filtering component510 controls thehierarchical dashboard display308. The hierarchical filtereddashboard display308 maintains a mapping between related instances. The nature of these relationships is system-specific. However, in summary: The cardinality of these relationships may be high. Some relationships will be one-to-one (e.g. one Customer Premise Equipment [CPE] is owned by one Customer). Some relationships will be one-to-many (e.g. more than one service can run over the same network segment, the same device can be used to access more than one service, etc.). Some relationships will be many-to-many (e.g. many Customers will subscribe to many services). Therefore, a common mechanism is provided that can be used for all dashboards to filter what object instances will be displayed in eachdashboard display308 and in each sub-window oranchor panel504. Note that the purpose of thefiltering component510 is to limit instances, not the information (attributes) of instances. Filtering what information (about each instance) is displayed may be the purpose of a different type of filter.

FIG. 8 is a flowchart setting forth a second illustrative operational sequence for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects. Basically,FIG. 8 describes the operational sequence that is executed when a user elects to display a hierarchical dashboard such as thedashboard display308 ofFIG. 5. The operational sequence ofFIG. 8 commences atstep1 where the hierarchical dashboard sub-window management304 (FIGS. 3 and 8) system reads dashboard metadata from metadata stored in thedashboard sub-window configuration306 database. This metadata includes a definition of the dashboard display308 (FIG. 5) and its chained relationships between sub-windows. Thedashboard display308,anchor panel504, sub-windows511,512,513 and their associated metadata are illustrated inFIG. 5. Some key (but not exhaustive) attributes of a sub-window metadata are:

ID: A globally unique identifier for the sub-window.

Anchor Panel (Y/N). This indicates whether or not a sub-window511,512,513 is in ananchor panel504 or not. There can only be oneanchor panel504 in ahierarchical dashboard display308.

Scope Level: This is level of the sub-window511,512,513 within a window hierarchy.Level0 is theanchor panel504.Level1 are those sub-windows511,512,513 directly dependent on theanchor panel504.Level2 are those sub-windows524,525 (FIG. 6) directly dependent on theLevel1

sub-windows

511,512,513 (FIGS. 5 and 6).

Scope Chain: This is the class chain from the anchor panel504 (FIG. 5) to a particular sub-window511, e.g. DimA-DimB. It is used to scope the object instances to be displayed in the sub-window.

Parent ID: Identifier of a parent sub-window which qualifies this sub-window.

Dimension/Class: Instances of one class are displayed in a sub-window. This is the Class identifier.

Instance Order: This specifies the order in which instances of the class are displayed. It is an expression-based mechanism used to provide a unique list, e.g. maximum value of a particular attribute, etc.

Attribute List: This is the list of attribute identifiers of the Class defined above to be displayed in a sub-window511,512,513.

UI Attributes: The position, widgets, etc to be used to display the instances and attributes.

Data Store Query Mechanism: This information will allow a client construct an appropriate query to a multi-dimensional dependency model302 (FIGS. 3 and 8) data store.

Returning toFIG. 8, atstep2, the hierarchical dashboardsub-window management304 system (FIG. 3) reads ALL the object instances and attributes as specified in the metadata for the anchor panel504 (FIG. 5) from the multi-dimensional dependency model302 (FIGS. 3 and 8) data store. The hierarchical dashboardsub-window management304 system uses the Data Store Query Mechanism metadata to construct a query API forAPI305.

Next, at step3 (FIG. 8), a filtering algorithm is performed. The hierarchical dashboard sub-window management304 (FIGS. 3 and 8) reads filter information from the multi-dimensional filter component310 (FIGS. 3 and 8). This information is used to filter the instances of the objects of all dimension classes in the anchor window504 (FIG. 5) and

sub-windows

511,512,513 which may be a subset of that retrieved from themulti-dimensional dependency model302 data store (FIGS. 3 and 8).

The operational sequence ofFIG. 8 progresses to step4 where the hierarchical dashboardsub-window management304 system (FIGS. 3 and 8) renders the dashboards using the following algorithm: First, dashboard container metadata is read. This metadata contains the metadata for the dashboard itself and all its sub-windows511,512,513 (FIG. 5) including theanchor panel504. The algorithm then renders the dashboard container and standard widgets (File, Edit, View, etc.). Second, display the anchor panel sub-window in a location using a visualization mechanism defined in the metadata. The instances of the classes specified in theanchor panel504 metadata that are displayed are limited by the filter specified in the multi-dimensional filter component310 (FIGS. 3 and 8). Third, the order in which the instances are displayed use the “Instance Order” metadata of the anchor panel504 (FIG. 5). This could, for example, be the highest value of an attribute, e.g. max(Rank). Fourth, thefirst row530 of theanchor panel504 is highlighted. This provides the qualifier for instances to be displayed in

sub-windows

511,512,513 of the next Scope Level,e.g. Scope Level2.

Next, the following algorithm is performed on every subwindow whose parent window is the Anchor Panel: (a) The hierarchical dashboardsub-window management304 system (FIGS. 3 and 8) reads ALL the object instances and attributes as specified in the metadata for the sub-window from themulti-dimensional dependency model302 data store, qualified by the relationship to the selected instance of the anchor panel504 (FIG. 5) and the filter. The hierarchical dashboardsub-window management304 system (FIGS. 3 and 8) uses the data store query mechanism metadata to construct the query API forAPI305. An example of this query (not exact SQL but more for clarification purposes) is as follows: (Assume Anchor Panel Class is DimA and Subwindow Class is DimB with attributes b1, b2 and b3. Also assume that selected instance in Anchor Panel is ‘A1’:

SELECT ID, b1, b2, b3 from DimB

WHERE ScopeChain=‘A1’

Translated, the foregoing expressions mean “Select instance Identifier, Attributes b1, b2 and b3 from DimB instances where the scoped chain relationship between DimA and DimB matches instance ‘A1’. (b) Once it has retrieved all this data, the hierarchical dashboardsub-window management304 again filters this list using the filter set in the Multi-Dimensional Filter Component. In essence, all the instances in the sub-window are in scope in this case because they are all related to the instance selected in the anchor window504 (FIG. 5). The UI should somehow highlight the chain between theanchor window504 and the sub-window511,512, or513. Because of the potential complexity of the inter-relationships between objects, the Scope Chain concept and the UI artifacts used to highlight the scope chain in the UI allow a user to understand the context of what is being displayed. A row in the sub-window513 may then be highlighted which, in turn, may cause one or more sub-windows524,525 (FIG. 6) in the next level to populate.

The foregoing mechanism is repeated for sub-windows at all subsequent levels in the chain in a recursive manner. For example, assume instance ‘A1’ was selected in the anchor window504 (FIG. 5); instance ‘B1’ was selected in aLevel1

sub-window

513, then the scoped query to populate subwindow of Class DimC is something like:

SELECT ID, c1, c2, c3 from DimC

WHERE ScopeChain=‘A1-B1’

Translated, the foregoing expression means “Select instance Identifier, Attributes c1, c2 and c3 from DimC instances where the relationship chain between DimA and DimB is ‘A1-B1’

FIG. 9 is a block diagram setting forth an illustrative computer program product or hardware product for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects. The system includes acomputer300 operatively coupled to a signal bearing medium340 via an input/output interface (I/O)330. The signal bearing medium340 may include a representation of instructions for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects, and may be implemented as, e.g., information permanently stored on non-writeable storage media (e.g., read-only memory devices within a computer, such as CD-ROM disks readable by a CD-ROM drive), alterable information stored on a writeable storage media (e.g., floppy disks within a diskette drive or hard disk drive), information conveyed to a computer by a communications medium, such as through a computer or telephone network, including wireless or broadband communications networks, such as the Internet, etc.

Thecomputer300 includes aprocessor310 that processes information for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects, wherein the information is represented, e.g., on the signal bearing medium340 and communicated to thecomputer300 via the I/O330, wherein theprocessor310 saves information as appropriate into amemory320. This information may also be saved into thememory320, e.g., via communication with the I/O330 and the signal bearing medium340.

Theprocessor310 executes a program comprising instructions for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects by limiting one or more object instances in the object model and filtering one or more attributes associated with one or more of the object instances. The limiting and filtering is performed by utilizing each of a plurality of respective windows, panels, or sub-windows to display a corresponding list of one or more objects for a dimension of a plurality of dimensions, along with one or more attributes associated with each of the one or more objects. At least a second window, panel, or sub-window of the plurality of respective windows, panels, or sub-windows is updated in response to receiving a selection of an item from a first window, panel, or sub-window of the plurality of respective window, panels, or sub-windows according to a first relationship defined in the object model. The updating is performed in a hierarchical manner wherein at least a third window, panel, or sub-window of the plurality of respective windows, panels, or sub-windows is updated in response to receiving a selection of an item from the second window, panel, or sub-window according to a second relationship defined in the object model. A filtering procedure is performed across the plurality of dimensions to restrict one or more instances of the one or more objects to be displayed in the plurality of respective windows, panels, or sub-windows to thereby control and manage the visualization of the object model wherein the object model provides a high cardinality of objects. The foregoing steps may be implemented as a program or sequence of instructions within thememory320, or on a signal bearing medium, such as the medium340, and executed by theprocessor310.

The capabilities of the present invention can be implemented in software, firmware, hardware or some combination thereof. As one example, one or more aspects of the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately. Additionally, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.

The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention

The foregoing exemplary embodiments may be provided in the form of computer-implemented processes and apparatuses for practicing those processes. The exemplary embodiments can also be provided in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the exemplary embodiments. The exemplary embodiments can also be provided in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the exemplary embodiments. When implemented on a general-purpose microprocessor, the computer program code segments execute specific microprocessor machine instructions. The computer program code could be implemented using electronic logic circuits or a microchip.

While the invention has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiments disclosed for carrying out this invention, but that the invention will include all embodiments falling within the scope of the claims. Moreover, the use of the terms first, second, etc. do not denote any order or importance, but rather the terms first, second, etc. are used to distinguish one element from another. Furthermore, the use of the terms a, an, etc. do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item.

Claims

1. A computer-executable method for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects, the method comprising:

limiting one or more object instances in the object model and filtering one or more attributes associated with one or more of the object instances, wherein the limiting and filtering is performed by:

utilizing each of a plurality of respective windows, panels, or sub-windows to display a corresponding list of one or more objects for a dimension of a plurality of dimensions, along with one or more attributes associated with each of the one or more objects;

updating at least a second window, panel, or sub-window of the plurality of respective windows, panels, or sub-windows in response to receiving a selection of an item from a first window, panel, or sub-window of the plurality of respective window, panels, or sub-windows according to a first relationship defined in the object model, wherein the updating is performed in a hierarchical manner such that at least a third window, panel, or sub-window of the plurality of respective windows, panels, or sub-windows is updated in response to receiving a selection of an item from the second window, panel, or sub-window according to a second relationship defined in the object model; and

performing a filtering procedure across the plurality of dimensions to restrict one or more instances of the one or more objects to be displayed in the plurality of respective windows, panels, or sub-windows to thereby control and manage the visualization of the object model wherein the object model provides a high cardinality of objects.

2. The method ofclaim 1 further comprising displaying the first, second, and third windows, panels, or sub-windows on a hierarchical dashboard display.

3. The method ofclaim 2 further comprising generating the hierarchical dashboard display using a multi-dimensional dependency model operatively coupled to an application program interface (API), a hierarchical dashboard sub-window management system operatively coupled to the API, a dashboard sub-window configuration database in communication with the hierarchical dashboard sub-window management system, wherein the hierarchical dashboard sub-window management system is operatively coupled to the hierarchical dashboard display.

4. The method ofclaim 3 further comprising providing the hierarchical dashboard display with a multi-dimensional filter component.

5. The method ofclaim 4 further comprising the multi-dimensional dependency model providing information for driving the hierarchical dashboard display.

6. The method ofclaim 5 further comprising using the multi-dimensional dependency model to query related instances of a first object with a plurality of other objects in a dependency chain.

7. The method ofclaim 6 further comprising using the multi-dimensional dependency model to query a value of attributes for the other objects in the dependency chain.

8. A computer program product comprising a storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for facilitating a method for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects, the method comprising:

9. The computer program product ofclaim 8 further comprising instructions for displaying the first, second, and third windows, panels, or sub-windows on a hierarchical dashboard display.

10. The computer program product ofclaim 9 further comprising instructions for generating the hierarchical dashboard display using a multi-dimensional dependency model operatively coupled to an application program interface (API), a hierarchical dashboard sub-window management system operatively coupled to the API, a dashboard sub-window configuration database in communication with the hierarchical dashboard sub-window management system, wherein the hierarchical dashboard sub-window management system is operatively coupled to the hierarchical dashboard display.

11. The computer program product ofclaim 10 further comprising instructions for providing the hierarchical dashboard display with a multi-dimensional filter component.

12. The computer program product ofclaim 11 further comprising instructions for the multi-dimensional dependency model providing information for driving the hierarchical dashboard display.

13. The computer program product ofclaim 12 further comprising instructions for using the multi-dimensional dependency model to query related instances of a first object with a plurality of other objects in a dependency chain.

14. The computer program product ofclaim 13 further comprising instructions for using the multi-dimensional dependency model to query a value of attributes for the other objects in the dependency chain.

15. A hardware product comprising a storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for facilitating a method for supporting a visualization of an object model in which multiple dependencies exist between each of a plurality of objects, the method comprising:

performing a filtering procedure across the plurality of dimensions to restrict one or more instances of the one or more objects to be displayed in the plurality of respective windows, panels, or sub-windows to thereby control and manage the visualization of the object model wherein the object model provides a high cardinality of objects.9. The computer program product ofclaim 8 further comprising instructions for displaying the first, second, and third windows, panels, or sub-windows on a hierarchical dashboard display.

16. The hardware product ofclaim 15 further comprising instructions for displaying the first, second, and third windows, panels, or sub-windows on a hierarchical dashboard display; and

providing the hierarchical dashboard display with a multi-dimensional filter component.

17. The hardware product ofclaim 16 further comprising instructions for generating the hierarchical dashboard display using a multi-dimensional dependency model operatively coupled to an application program interface (API), a hierarchical dashboard sub-window management system operatively coupled to the API, a dashboard sub-window configuration database in communication with the hierarchical dashboard sub-window management system, wherein the hierarchical dashboard sub-window management system is operatively coupled to the hierarchical dashboard display.

18. The hardware product ofclaim 17 further comprising instructions for the multi-dimensional dependency model providing information for driving the hierarchical dashboard display.

19. The hardware product ofclaim 18 further comprising instructions for using the multi-dimensional dependency model to query related instances of a first object with a plurality of other objects in a dependency chain.

20. The hardware product ofclaim 19 further comprising instructions for using the multi-dimensional dependency model to query a value of attributes for the other objects in the dependency chain.