Hierarchical nesting is when entities include other child entities of a different kind: products include containers, which in turn include groups with types and type members. Aggregate nesting is when entities include child entities of the same kind: groups can be defined or declared within other groups, and types can define nested types. A child is always a different entity from its parent.
Hierarchical Nesting
In hierarchical nesting, an entity includes child entities of a different kind. Model Xtractor metadata has a well-defined hierarchical structure, following the parent-child main inclusion chain products –> containers –> groups –> types –> members –> parameters, as represented by the diagram below. The .NET Framework 2.0 product contains multiple assemblies, as containers. The System v2.0 expanded nested assembly contains several namespaces, as groups. System.Collections.Generic namespace defines multiple .NET types:
Aggregate Nesting
In aggregate nesting, an entity includes child entities of the same kind. The SortedDictionary<TKey,TValue> generic type from the previous diagram has three nested types, each with two different nesting parents: one given by the hierarchical nesting (the System.Collections.Generic namespace), and the other by the aggregate nesting (the SortedDictionary<TKey,TValue> type).
Nested types always expand automatically, when either the child or the parent is added as shape to the diagram. If we consider separately the previous nested generic types, drop any of them in a new diagram, and Model Xtractor will automatically expand and add the whole type nesting structure, in auto-expand mode:
Nested relationship are represented in Model Xtractor shapes by pairs of nested items (int the parent entity) and <<parent>> dependency items (in the child entity). Most items in a product, container or group represent nested entities. When either a nested or <<parent>> item expands, its paired reverse item, from the other related entity, auto-expands as well, sharing the same connector. The + sign always appears close to the parent shape, the one with the nested child. Any metadata entity (except products) has one hierarchical parent, and zero or one aggregate parent, when it is also part of another entity of the same kind.
The hierarchical <<parent>> dependency item can be also dropped on the shape header, in which case the name of the parent will appear under the shape title. This is what we did for the SortedDictionary<TKey,TValue> shape before. When new shapes are created in a diagram, this item will be automatically delegated in shape’s header if none of existing shapes is from the same context, or all shapes from the same context have also this dependency item delegated. Combined with transparency, this creates an auto-expansion boundary context and stops further auto-expansion. With the shape expanded, drop it back in the shape items area or outside the shape, for the typical collapse/expand behavior.
Nesting Shapes
When you fully include at least one shape within a comment shape or inside the items area of an expanded metadata shape, the containing shape becomes a nesting shape, and acts differently. Its background or items area background becomes transparent. Its shape items, connectors, shadow and scroll bars become invisible. Comment nesting shapes get a dash border and act like a grouping sidebar: their text appears in bold, on top, like a title.
When the nesting shape is moved, all fully included shapes will move with it. When selected, they never hide or leave their included shapes behind. Select a nesting shape and double-click on one of the resizing selectors: its size will adjust to have all included shapes centered inside. When a nesting shape is deleted, its included shapes are not. Drag all included shapes outside their nesting shape area, and previous normal behavior is restored.
The diagram below has both System.IO metadata shape and “Folders and Files” comment acting as nesting shapes:
Dictionary<TKey,TValue> has a similar aggregate nesting structure to SortedDictionary<TKey,TValue>, presented before. Here is how this cound be alternatively represented, using nesting shapes:
There is no restriction on which kind of shapes can be nested this way, so it is up to you to provide something logical and consistent with metadata. It’s strongly recommended that you use nesting metadata shapes only the way the composition, through parent-child nesting relationships, is defined for them. For instance, here below is the alternative consistent representation for the diagram presented at the Hierarchical Nesting:
And here is how hierarchical (namespace-types) and aggregate nesting (between types) can appear in the same diagram, using a combination of nesting connectors with nesting shapes:
Leave a Comment