Contents   Introduction   Concepts   User Help   Modeler Help   Browser Help
Administrator Help   Developer Help    Utility Help   Visio   Graphical Modeler

Hierarchical and Inferred Relationships

Hierarchical Relationships

EVA Netmodeler lets us define relationships from a node type to itself. This feature enables us to create models in which the items of any given type can relate to other items of the same type, forming hierarchies or networks. This is a common structure that we can see in everyday life around us. For example:

• Hierarchies
• Business units contain other (often, but not necessarily smaller) business units to make up an organization structure
• Classification schemes are usually based on a hierarchy of classes of things, with each successive layer becoming more specific than its parent
• Networks
• Project tasks often precede or follow other project tasks

Sometimes an item can have both a hierarchical and a network relationship to other items of the same type. For example:

• An artifact, say a book or a project deliverable, can be both part of some other artifact (hierarchical relationship) and it may be a prerequisite for or be dependent on another artifact (network relationship)

The default hierarchy relationship for each node type is set in the node type definition in the Type Browser.

Hierarchical relationships can be exploited in numerous ways in EVA Netmodeler, a few of which are explained below.

Hierarchical relationships in the item and domain tree browsers

From the examples above we can see that we often use hierarchies to help us organize information and focus on a subset of information that is relevant at a point in time. EVA Netmodeler supports this paradigm by presenting various list of items as nested hierarchies. For example, the Item Tree browser shown below displays a list of Node Types in the left hand pane when you use the Node Type Tree Selector. When you select a node type EVA Netmodeler builds a hierarchy of the items of that type based on the default hierarchy relationship for that type. In the example below that is the includes parts relationship. Items that have other items below them in the hierarchy that are not currently displayed are indicated with a [+] on the left of the item name. Clicking on the [+] displays the list of lower level items and changes the indicator to the left of the item to a [-]. Items that have no other items below them in the hierarchy are indicated with a [.] on the left of the item name. In this way you can navigate down the hierarchy to the desired item

Hierarchical relationships in reports

Often the position of an item in a hierarchy is an indicator of its importance or possible implied relationships to other items. For instance if Mary is employed by the Sales Department of XYZ Manufacturing, the direct relationship is to the Sales Department, but the indirect relationship is to XYZ Manufacturing. Both of these aspects can be leveraged in the EVA Netmodeler reporting environment by:

• Showing an item's hierarchy in the report, rather than merely the item on its own
• Using a Hierarchy Filter to select items for the report based on a relationship to any of the items in a hierarchy.

Refer to the Report Browser section for more information on these features. 

Hierarchical relationships in the Graphical Browser

The Graphical Browser displays items and their directly related items in a graph. However, when you limit the display to a specified hierarchical relationship, the Graphical Browser displays all of the items related to the focus item via that relationship type, and all the items related to those items via the same relationship type, and so forth. The resulting display is a fully expanded hierarchy of items based on the specified relationship. This feature is useful whenever you are dealing with a a composition of some sort where the items making up the composition may be of different types. You can view them as a hierarchical collection so long as they are all related via the same relationship type.

In the example below the Air Apparent Application System was selected as the focus item, and the relationships limited to the includes parts relationship. The resulting display shows the Air Apparent Application System with all of the application systems that it includes, and so forth. It also shows the item of other types that are related to Application System via the includes parts relationship type - System Function in this example.

Inferred Relationships

Relationships between items are a key part of the way EVA Netmodeler helps us manage information. However, sometimes we are more interested in the indirect relationships between items. For example, an Application exposes an Interface, and another Application uses the Interface. The indirect relationship between the two Applications can be inferred by the fact that the one uses an interface provided by another.

There are a number of features in EVA Netmodeler that enable you to use inferred relationships.

Inferred relationships in the Cross Reference browser

The Cross Reference browser is used to generate a cross reference matrix based on the relationships that exist between two item types. The relationships do not have to be direct - EVA Netmodeler can infer relationships between items that have up to two intervening items. In the example below, the cross reference will show any Application Systems that has an API that belongs to a System Software Component that is part of another Application System. EVA Netmodeler analyses the meta model and provides a list of the possible inferred relationships for the user to choose from.

Filtering repository content based on Inferred relationships

EVA Netmodeler enables you to define a filter based on an inferred relationship to an item which occurs somewhere in a hierarchy of items. For example, you could define a filter to show only items of type Application System that are Governed By any Business unit that is part of Air Apparent. This is show below:

Inferred relationships in the Graphical Modeler

The EVA Netmodeler Graphical Modeler is a rich and flexible graphical modeling environment which can support a variety of notations and model types.

It is sometimes useful to be able to hide detail in a model. An example would be where we have Application systems interfaced to other Application systems via a variety of intermediate items, including Files, Databases and Interfaces. We might want to see a picture of just which Applications talk to which others, without the detail of how. To achieve this, we define a model type with Application and the intervening types. When we retrieve a model, we will get the full set of items displayed, but we can hide those we do not wish to see by clicking the "hide" decoration on the icon for the relevant type on the icon strip. In this way we can see the "inferred" relationship between applications without worrying about the intervening detail.