December 2008 [Cradle 5.7]

Item Hierarchies

Hierarchies of items are very common in all Systems Engineering processes. They arise in many situations, including:

Requirements
System breakdown structures
Product breakdown structures
Operational, functional and behavioural models
Data definitions

In general, Cradle considers a hierarchy to be a collection of items that are connected by cross references in which an item that is considered to be higher-level than other related items has cross references from it to the related items. These related items that have the cross references to them are considered lower-level items:

In a hierarchy, the item at the from end of a cross reference is called the parent of the item at the to end of the cross reference, and the item at the to end of the cross reference is a child of the item at the from end of the cross reference:

The term sibling is used for items that have the same parent, that is, items that are all children of the same item. By definition, in a hierarchy, an item can only have one parent, but a parent can have many children:

For a set of items to be connected in a hierarchy, they should be:

All the same type of item
Connected by the same type of cross reference

Cradle enforces the first of these rules, but not the second. However, it is a good idea if you follow both rules; in particular that the same type of cross reference (called a link type in Cradle) is used between all items in the hierarchy. To make this easy to achieve, specify a link rule in your project’s schema that only allows cross references with one link type between the items of the item type used in the hierarchy.

Cradle databases have two fundamental types of cross reference:

Cross references
Pseudo cross references

These are discussed below, followed by notes on the creating, querying and viewing of hierarchies of items.

Cross References

Cross references are created to record a dependency between two items in the database. They exist only if someone specifically creates them, unlike pseudo cross references (see below) that are created automatically by another operation.

Each cross reference has a link type, user-defined attributes, a creator, last modifier, and creation and last modification dates and times. You typically create them by drag-and-drop between items in trees in WorkBench. Cross references can optionally be created between items in models (discussed below) depending on the settings of your user preferences. The default, out-of-the-box, settings for user preferences mean that cross references will be automatically created between model elements, even if you do not knowingly create them.

You can create cross references in either direction between a pair of items, and so you can create cross references in both directions:

This is generally a bad idea, and is one reason that you should define link rules in your project schema to permit only one of these cross references to exist.

You can find and fix instances of this cross reference duplication from the Cross Reference Integrity dialogue accessed from Admin → Utilities → Cross Reference Integrity…:

You can create multiple cross references between the same pair of items provided that the cross references have different link types. This is not common, but can be useful:

Cross references can be shown in many different ways, including:

Expanding an item in a tree shows the items linked to that item by cross references, the linked items’ descriptions are coloured black, and the cross references can be shown by clicking a linked item and choosing Link Details:

Items linked by cross references can be shown in a nested table, and details of the cross references between the items can also be shown in the table
The existence of, or contents of, cross references between one, two or three sets of items can be shown in a matrix
Cross references between items are shown as lines connecting the items drawn in a Hierarchy Diagram (HID)
In lists of linked items, such as from the Linked Items → By Navigation and Linked Items → All options:

When you work with cross references, you are working in the current cross reference set. A baselined set of cross references is created by copying the current cross reference set each time a baseline is closed. The set of cross references logged for each baseline can be restored if you restore that baseline.

Pseudo Cross References

Pseudo cross references are not explicitly created in a Cradle database. They do not have a link type, nor attributes, and they do not have a creator, last modifier, creation or last modification dates and times. They do not exist in the database at all as explicit pieces of information that can be modified. Rather, their existence is inferred from the contents of other items in the database.

Pseudo cross references only exist between items that form part of a model:

Diagrams
Specifications
Data definitions

They exist between two items in a model as a result of one of them being included in, or shown in, the other item.

For example, a pseudo cross reference automatically exists between a diagram and a data definition or specification if that data definition or specification is shown as a symbol in the diagram. Examples are:

Between the specification for a use case and a Use Case Diagram (UCD) if the use case appears as a symbol in the UCD
Between the data definition for an interface and a Physical Architecture Diagram (PAD) if the interface is shown as a symbol in the PAD

There are many different types of pseudo cross reference:

Between a diagram and the data definitions for symbols shown in the diagram
Between a diagram and the specifications for symbols shown in the diagram
Between a data definition and the diagrams where it is shown as a symbol
Between a data definition and the specifications to which it is an input in one or more diagrams
Between a data definition and the specifications from which it is an output in one or more diagrams
Between a specification and the diagrams where it is shown as a symbol
Between a specification and the data definitions that are its inputs in the diagrams where the specification is shown as a symbol
Between a specification and the data definitions that are its outputs in the diagrams where the specification is shown as a symbol

Pseudo cross references can be shown in many different ways, including:

Expanding an item in a tree shows the items linked to that item by pseudo cross references, the linked items’ descriptions are coloured blue:
Items at the next level shown in a nested table
In lists of linked items, such as from the Linked Items → By Navigation and Linked Items → All options:

Since pseudo cross references do not exist as explicit information in the database, they are not explicitly copied when a baseline is created. However, since pseudo cross references exist because of the content of model information, they are effectively baseline-specific as the contents of models is (as for any other item) specific to each baseline. As such, when a baseline is closed, all of the pseudo cross references are effectively copied and tagged with that baseline’s name, just as happens with explicit cross references as described in the previous section.

Creating a Hierarchy

There are two methods for creating hierarchies of items:

Create the items (or load / import them from an external source) and manually link the items into a hierarchy using drag-and-drop
Build the new items and the hierarchical links between them at the same time

To build a hierarchy of new items and the hierarchical links between them, use the New → Child…, New → Sibling…, and New → Hierarchy… operations in the Item pulldown menu and the right click menus:

All of these operations:

Create a new item of the same type as the item selected
Set an attribute in the new item to show its hierarchical relationship to the selected item
Create a link from the selected item to the new item

Except for the second step (updating an attribute in the new item) the steps are the same as the New → Linked Item… operation. The Linked Item operation does not set attributes in the item that it creates, and lets you specify the type of item created. So the Linked Item operation is not normally used to create hierarchies, but to create a new item of another type linked to the selected item, for example:

Create a verification linked to a selected requirement
Create a test case linked to a selected test plan

So, starting with an Item A, to create a hierarchy below it, you could:

Select the item and use New → Child… to create the first child:
Repeat this operation to create the second child:
As an alternative, you can create a third child by selecting any of the existing children and selecting New → Sibling…:
To create a grandchild item (a child of one of the children), select one of the existing children and select New → Child… again:

Repeat these steps to create the size and depth of hierarchy needed. Alternatively, if you know the approximate size of the hierarchy that you want to create, you can use the New → Hierarchy… option to create a hierarchy below a selected item:

Enter the number of levels and the number of children to be created at each step, click OK, and the whole hierarchy of grandchildren, great grandchildren (and so on) will be created for as many levels as you specified:

You can delete items, or add any further items, as necessary.

Running Queries on Hierarchies

When you run a query on a hierarchy of items then, by default, you will see all of the items that form the hierarchy, not just the part of the hierarchy of interest. This may not be what you want.

In the Links tab in the Query Details dialogue, there are options to filter the items returned based on their position in an item hierarchy:

There are various options, whose effects are:

Of these options, Top-level is the most common filter, which limits the query to just those items at the top(s) of the hierarchies, the items that have cross references from them to other items of the same type, but not to them from other items of the same type.

Viewing a Hierarchy

The simplest way to view a hierarchy in WorkBench is to run a query for the item type:

and then show the results in Tree style and double click any item to see its children:

By default, a query does not only show top-level items. So items may appear more than once in the tree, in the main list and as a child of another item, such as item 1.1 above.

It is usual for the query to only show Top-level items, those at the top of the hierarchies, which can be expanded by double-clicking these top level items to show their children:

You can view items in a hierarchy through a nested table view, such as:

The simplest way to show a hierarchy is a recursive view definition, such as:

You can use Hierarchy Diagrams (HIDs) to show hierarchies. HIDs have either a vertical or horizontal orientation, this HID is vertical:

You can optionally change the orientation of the HID at a particular level in the decomposition, such as:

You can control many aspects of HIDs, including:

Which type(s) of items are shown at each level in the hierarchy
Which cross reference link types are shown at each level in the hierarchy (when the lines in the HID are coloured based on the colours that may have been defined for the link type in the schema)
Which attributes are shown inside the boxes drawn for each item type

These, and many other, HID settings can be saved into standard formats called hierarchy definitions that can be applied to any HID.

Numbering in a Hierarchy

In the previous sections, all of the items in the hierarchy have numbers that reflected their position in the hierarchy. We started with an item 1, and created children with numbers 1.1, 1.2 and 1.3. This is as we would intuitively expect, and is the second of the three steps that we listed in the earlier section describing how to create hierarchies using the New → Child, New → Sibling, and New → Hierarchy operations.

You can choose which attribute will contain these hierarchical numbers:

The Identity of the items, unless the items are being auto-numbered
The Key attribute of the items
Any single-value category assigned to the item type that does not have a pick-list of pre-defined values defined for it

You make this choice as part of the project’s schema, by selecting the item type and then selecting Numbering in the Project Setup tool to display the Numbering Options Setup dialogue:

If auto-numbering has been enabled for the item type, then the Identity attribute of items of the type will be pre-determined by the auto-numbering, and so Identity is not available for hierarchical numbers:

You can control the separator used in the hierarchical numbers, either Dot, which produces hierarchical numbers such as:

1.1
1.2
1.2.1

or Hyphen, which produces hierarchical numbers such as:

1-1
1-2
1-2-1

Control over the hierarchical numbers is only possible if the Enable Hierarchical Options checkbox is selected. If not selected, then you cannot specify the attribute to contain the hierarchical numbers, nor the form of these numbers. More significantly, however, is if this checkbox is not selected, then you cannot build hierarchies of items of the item using the New → Child, New → Sibling, and New → Hierarchy operations, as they will be disabled whenever you select an item of this type.

Numbering in Model Hierarchies

Cradle allows any number of models to be created in each of two domains, Essential and Implementation, in a project. Each model contains diagrams of one or more diagram types ( notations), together with the specifications and data definitions that provide the description of the symbols in the diagrams.

Some diagram types are hierarchical, and have symbols that can be expanded into lower-level diagrams, for example:

Functions in extended Function Flow Block Diagrams (eFFBDs) can be expanded into lower level eFFBDs or other diagram types
Data processes in Data Flow Diagrams (DFDs) can be expanded into DFDs and control processes can be expanded into State Transition Diagrams (STDs)
Use cases in Use Case Diagrams (UCDs) can be expanded into UCDs and other diagram types

All diagrams have a number as their Identity attribute. Expandable diagram symbols are numbered. The number of a diagram symbol is the diagram number with a trailing .N. The number of a child diagram is the same as the symbol that expands to the diagram.

Symbols that expand to child diagrams can be described by a specification, and so have a specification, or a child diagram, or both. The numbers of a symbol’s specification and its child diagram are the same as the symbol’s number.

So:

Specifications numbers: nnnn.1 and nnnn.2
- Are linked to diagram nnnn
Diagram number: nnnn
- Is linked to specifications numbers: nnnn.1 and nnnn.2

simply because their numbers are related. There is no need for cross references to make these linkages, pseudo cross references automatically exist that make the linkages for you. These linkages create parent – child relationships, so:

1.1 and 1.2 are children of 1
fred.2.1 is a child of fred.2

and:

1 is the parent of 1.1 and 1.2
fred.2 is the parent of fred.2.1

This means that a model can, and usually does, contain two hierarchies:

A hierarchy of diagrams
A hierarchy of specifications

Cradle does not need cross references to navigate up and down the specification and diagram hierarchies in a model. You can navigate up these hierarchies using the Collapse operation and you can navigate down the hierarchy by using the Expand operation.

However, Hierarchy Diagrams (HIDs) that show the model’s hierarchy cannot be produced without cross references between the model’s specifications.

So that HIDs can be produced, Cradle’s modelling tools automatically create specifications for diagrams and symbols, and automatically create hierarchical cross references between these specifications. These actions are controlled by user preferences accessed in Cradle Toolset by Tools → Customise → UI Control → Editors:

These user preferences are enabled by default, so all users will automatically create cross references within models unless they have disabled these options in their personal settings.

So the numbering of diagrams and specifications in models is, of itself, enough to create hierarchies that are understood by the modelling tools. Explicit cross references are also created between the models’ specifications, to allow HIDs to be produced and to allow the model hierarchies to be viewed and manipulated (such as in a WorkBench tree) as for any other hierarchy in a Cradle database.

In this issue:

Back to the newsletter archive.

Request Password Form

Login Form

Register