Model Xtractor - Online Class Diagram Editor
Model Xtractor - Online Class Diagram Editor User Account   
    RSS Posts | Model Xtractor
  • Diagrams
  • Metadata
  • Blog
  • Support
  • Tutorial

Items

Leave a Comment » Feb 22, 2010
Bookmark and Share
Categories: Tutorial

Items are diagram elements, listed as members of a shape. The Metadata tree or the Diagrams list show nodes, with similar layout and structure. Items can be hidden or highlighted, change order, expanded into relationship connectors, collapsed back to their original shapes etc. The Model Xtractor navigation is actually achieved by expanding items, by moving them outside the shape, where they are delegated to connectors to other shapes. Connectors can be removed, or their items moved back to the initial shape, collapsed. Same item cannot appear twice in a diagram: it is either part of the items area in its shape, or delegated to a connector. Any connector (except the comment link) is created from one such item delegation. New shapes are initially collapsed and don’t show their items.

Classification

  1. Category Items – folder-like items, to group items into collapsible sections. Appear only when Show Categories layout option is on.
  2. Dependency Items – Model Xtractor specific expandable items, to represent different relationships of an entity with other entities. Always on top, in the Dependencies folder.
  3. Nested Items – for child entities defined within parent entities, in a hierarchical or aggregate nesting relationship. In a Nested folder or under category items with specific names.
  4. Regular Items – for typical type members, like properties, fields, methods etc, that usually expand into associations. Under categories with different names.

Click for the published entry of the diagram
EditViewPrint

Dependency Items

Model Xtractor detects and extracts from all relationships those where the entity depends on others, and shows them as dependency items., in a top Dependencies category. Dependency items start by a <<…>> verb that describes the kind of dependency and “returns” the type it depends on. When a dependency item is dragged outside the shape, it will be delegated to a typical connector you may be already familiar with from UML (generalization, realization, nesting, usage etc).

Click for the published entry of the diagram
EditViewPrint

Dependency items are Model Xtractor specific and their advantage is both structural and relational description of any metadata object is represented in a similar manner and is handled in a similar way. For instance, there is no need to later obtain the representation of a generalization connector or an association connector in different ways: both the <<extends>> dependency item or the type member item showing an association can be dragged outside and create only a different kind of connector.

Item Expansion and Navigation

The main method to achieve Model Xtractor navigation is by shape item expansion, using a manual drag and drop technique, combined with automatic auto-expansion. Shapes are initially created as collapsed, but they can expand, to show their items area. Minimize them, to focus only on connectors. Shape items can expand into connector items: this way, they are temporarily moved outside the shape and determine creation of relationship connectors between shapes. We can collapse back an item, to its original shape, through different techniques (including the deletion of its connector).

It is so easy to create a complex and rich model by simple item drag and drops, starting from one single shape. Make sure the Auto-Expand switch is off (look for the menubar icon), and let’s manually expand the Dictionary<TKey,TValue> shape presented before into this new layout:

Click for the published entry of the diagram
EditViewPrint

  1. Drag and drop the <<implements>> –> ISerializable item on shape’s header. This will move it as an implementor, for implemented interfaces. Drag and drop the other visible <<implements>> item (you’ll see other hidden items when you select the shape), but outside the shape this time: the item expanded not into an implementor, but into a realization to a new IDeserializationCallback shape.
  2. Expand the new shape and drop the <<parent>> item on shape’s header. The parent item will be added at shape’s header, just below its title (if dropped outside, it would expand into a nesting connector to its containing namespace). When you unselect the shape (click anywhere on the drawing area), the Dependencies folder automatically disappears, because it is now empty.
  3. Drop the contructor of the first shape in the drawing area: it became an instantiator. Reposition the expanded item.
  4. Expand the same way the Count property and the ContainsValue method. They expanded into association (first also a composition) to primitive types.
  5. Select Int32 shape and click on the small top-left blue circle: the shape has been minimized. Select Boolean shape and click on the small top-right empty circle: the shapes became transparent.
  6. Multiple select all nested items and drop them outside: they expanded into nesting connectors and new shapes have been added. Select them all and, using the toolbar icons, align them to the left and make them same width.
  7. Drag a note from the Metadata tab and drop it into diagram’s area: you added a comment shape. Type something like “Nested Types”, then drag it over the last added shapes. Resize the comment shape, so all nested shapes are fully included in comments area: the shape became a nesting shape.

All this and much, much more, can be achieved in just a couple of seconds with the Model Xtractor editor. Click Edit and continue playing with the expansion features by yourself.

Auto-Expand Mode

This editor option (by default on) provides for you additional item expansions on each new added shape or item expansion, as it follows:

  1. A new shape will be created as transparent if it is not the first shape of that kind in the diagram, but it’s a first shape added from a different context, or all other shapes from the same context are transparent. See how transparent shapes limit the auto-expansion context.
  2. Transparent type shapes will automatically expand the hierarchical parent item in shape’s header. Or, if the parent shape is already in the diagram, into a nesting connector to that shape.
  3. All <<implements>> dependencies expand into implemented interfaces. Or, if some interface shapes are already in the diagram, into realization connectors to each of those shapes.
  4. The <<extends>> dependency item of the new shape will auto-expand, but only if the base type belongs to the same namespace.
  5. The <<template>> dependency item of the new shape will auto-expand.
  6. All type nested children and type nesting <<parent>> dependency items to type parents auto-expand. In other words, each time you add a non-transparent nested type shape, or type shape with nested types, the whole type nesting hierarchy will appear in full.
  7. All bidirectional or reverse <<uses>> dependencies between the new non-transparent container or group shape and other non-transparent container or group shapes will auto-expand.
  8. The array or collection <<elements>> dependency will auto-expand, except for the .NET System.String type (which is also a collection of System.Char, but this is never automatically expanded).
  9. The <<alias>> dependency of a typedef type will auto-expand.
  10. On item expansion, any reverse <<uses>> dependency will auto-expand, sharing the same connector.
  11. For nested children or <<parent>> dependencies, the always present reverse dependency will auto-expand, sharing the same connector.
  12. Expanded associations or database relationships with a reverse item in the other type shape will auto-expand it as well, sharing the same connector.
  13. Any added array or collection type shape (other than System.String) will be created as minimized and will automatically expand its <<elements>> dependency item.

Layout Options

This combination of flags determine how items appear in a shape, how nodes are listed in the Metadata tree, how the Information pane presents the documentation. New shapes from nodes use default layout options, but they can be later changed, by shape or for all selected shapes, in the Properties – Shapes pane. When a shape item expands into a new shapes, this last shape inherits the layout options. For the Metadata tree they are set in the search mask. The Information pane, by default collapsed, just below the diagrams area, presents documentation on a metadata object, either from a selected Metadata node, or diagram element (shape or item). The generated diagram image from the Viewer has also hotspots, which can be clicked for synchronized documentation (the Information pane will expand automatically).

Sort, Show Categories and Inherited Members determine the structural topology of children in the hierarchy. Return Types, Parameter Types and Parameter Names determine items signatures. Unlike what you might see in the contextual documentation, which may use the specific syntax of a programming language, Model Xtractor signatures in the diagrams are generic to all platforms.

Layout Options

  • Sort:
    1. (no sort) – Children appear in the order they have been found in metadata.
    2. By Name – Children are sorted by the names of related objects.
    3. By Type – Children are sorted by names, but within groups based on their kind, such as Enumerations, Events, Classes etc.
    4. By Access – Children are sorted by names, but within groups based on their visibility, such as Public, Private etc.
  • Show Categories – Children appear within group category items, which act like folders. Empty categories, or with all their items hidden, will either not appear at all, or will become automatically hidden in a shape.
  • Inherited Members – Derived type shapes will add inherited member items, with name prefixed by the base type name.
  • Return Types – Navigable member items will end in arrow follow by the returned type. In Metadata, instantiable type names will end in arrow, and collection type names in [*].
  • Parameter Types – Member parameter lists will have parameter type names.
  • Parameter Names – Member parameter lists will have parameter names.

When both Parameter Types and Names are checked, a member item will follow the “name : type” notation and also show parameter default values, if any. When none of them is set, several members with similar signatures can be combined into a single overloaded member, with the number of additional overloads as parameter list: “(+n overloads)”.

The following diagram presents items from three expanded shapes, each configured with different layout options:

Click for the published entry of the diagram
EditViewPrint

Highlights

A double-click on an item, or on a metadata shape title text, will highlight that element: it will appear on a yellow background, it doesn’t matter if you use the colored, monochrome or black and white theme for the diagram. Another double-click will make the highlight to disappear:

Click for the published entry of the diagram
EditViewPrint

Leave a Comment

Accepts [code lang=".."] .. [/code], where lang is one of: csharp/vbnet/java/js/c/cpp/xml/sql/as3/php/ruby

E d i t   D i a g r a m s   O n l i n e !
Advertisement
Last Recommended Diagrams
  • WCF Binding
  • Membership (System.Web.Security Namespace)
  • System.ServiceModel.Syndication Namespace
  • System.Configuration: Sections and Groups
  • System.Configuration: Specific Sections
  • mx.utils
  • mx.preloaders
  • mx.controls.menuClasses
  • mx.controls.listClasses
  • mx.controls.dataGridClasses
Last Recommended Diagram
WCF Binding
WCF Binding
© 2010 Model-Xtractor.com - All Rights Reserved.
  • Terms of Use
  • Privacy Policy
  • News
  • About Us
  • Contact Us