This is a summary with definitions of specific terms used in Model Xtractor.

Metadata

• entities -preloaded imported Model Xtractor metadata is hierarchically structured and organized into products, containers, groups, types, members and parameters, referred to as entities. The well-defined and consistent hierarchy of products –>containers –> groups –> types –> members –> parameters is the main object-oriented nested chain of metadata in Model Xtractor. You’ll find no type without a group, no container which is not part of a product node etc. The metadata tree can also group entities in categories, which act like folders. Entities can be represented as nodes, in the Metadata tree, or diagram elements (shapes, items, connectors). Products, containers, group and types may be represented as shapes or nested items. Type members with their parameters translate into regular items. Items can later be expanded and delegated to connectors.
• product – component API or library, framework, group of interconnected assemblies, database management system etc.
• container – usually a physical entity like a component, assembly, executable with compiled code, database or XML file.
• group – usually a logical entity like a package or namespace, or database schema.
• type – object-oriented entity like a class, interface, enumeration, database table or view, or XML element.
• member – method or function, property, field, constant, event, database table column or index, or XML attribute.
• parameter – argument to a method or function, or indexed property.
• surrogate – specific Model Xtractor entity, which may not exist as such in the imported metadata. It may have been created from the need to respect the hierarchical object-oriented structure of the metadata tree, when a procedural language defines global functions or constants, outside of any type. Or to offer more grouping granulation, when many types are defined outside of any group. Or simply to provide a top-level clean product-container-group encapsulation, when their physical implementation doesn’t matter much. Dependency items are also surrogates, that offer a visual representation of relationships even when they are not expanded into connectors.
• combined namespace – specific Model Xtractor entity, that collects all types defined in .NET namespaces with the same name, across different assemblies. See an example here.
• hierarchical nesting – parent-child relationship in which entities include other entities of a different kind: products include containers, which in turn include groups, with types and type members.
• aggregate nesting – parent-child relationship in which entities include other entities of the same kind: groups can be defined or declared within other groups, and types can define nested types. See more about nesting in Model Xtractor.
• template definition – generic type definition, with at least one generic parameter.
• template substitution – specific Model Xtractor internal type, generated on-the-fly from a template definition, with a different list of parameters. It’s similar to a template construct, to those actual types generated at the compile time only, when they are created from abstract template definitions. The difference is in Model Xtractor  a type like List<T> generates no template substitution if it is used the way it was declared, but List<TValue> generates one, even if TValue is just another generic parameter alias. See more about generics in Model Xtractor.
• alias – alternative name for a metadata entity, usually a type. Global simple nicknames, available as such to any other using entity, appear as a “(…)” suffix appended to the entity name (ex: “Int32 (int)”). Typedefs will create a separate metadata entity, with an <<alias>> dependency item that automatically expands to the referred type. More about Model Xtractor aliases here.

Shapes

• comment – user note. Not internally linked to any metadata object. No items. Created by drag and drop of the “Drag to add a note” node of the Metadata tab in the diagram area. Can be connected, through user-defined comment links, to any other shapes.
• implementor – small white empty circle, connected to a related shape, to expand and show all implemented interfaces of a type.
• instantiator – small black filled-in circle, connected to a related shape, to expand and show all public instance constructors of a type.
• metadata – shape generated from a product, container, group or type node.
• collapsed – metadata shape with only its header visible, that hides the items area. Can be expanded by click on the top-right corner chevron icon, which becomes visible when the shape is selected or the mouse moves over its header area.
• expanded – metadata shape showing its items area. Can be collapsed back by click on the top-right corner chevron icon.
• minimized – specific Model Xtractor alternative state of a metadata or comment shape, in which the metadata shape appears as a circle with just the icon inside, and the comment as a small yellow filled-in circle, acting like an annotation. Minimized metadata shapes can show object scenarios, and bypassing arrays or collection types.
• transparent – specific Model Xtractor alternative visual representation of a shape, with no borders and colors. Transparent shapes may appear as secondary as importance in diagram’s context. Or it may lead to alternative simplified diagram themes.
• nesting – expanded containing shape that fully includes at least one other shape within its items area. Nesting metadata shapes will hide their items and will act like holding containers for their included shapes. Nesting comments change their look and text style, and act like sidebars.

Items

• categories – category items are folder-like items used for grouping, shown only when Categories switch is selected for a shape. They automatically disappear when empty and, unlike other items, when they collapse they simply hide their child items. Category nodes are similar and appear only when the Categories switch is selected for the Metadata tree.
• regular – regular items are usual type member items (methods, functions, properties, fields, table columns etc), with optional parameters and return type, that may expand into associations. Particular regular items, generated by Model Xtractor as surrogate properties on import, are the expandable pairs of database table relationships.
• nested – nested items are hierarchical or aggregate nested children. Products show all theirs containers as nested items, containers have groups, groups have types. Types may have aggregate nested types. Each nested item can get expanded into a nesting connector to the child shape, shared by the reverse <<parent>> dependency item found in this shape.
• dependencies – dependency items are Model Xtractor specific surrogates, generated either on import or on-the-fly, to represent relationships from one entity to another. They are always expandable and are listed first, in the Dependencies category folder, in «…» → … format. Right below there are all kinds of dependency items used by Model Xtractor.
• «parent» – dependency item for parent-child hierarchical or aggregate nesting. Expandable into a nesting connector to either a parent of the same kind (for aggregate nesting, like type nested inside another type), or different kind (for hierarchical nesting, like product of a container, container of a group, group of a type). Products have no hierarchical parent, but any container, group or type will have one and only one hierarchical parent. The aggregate parent, if any, can be one only. Any <<parent>> dependency item comes in pair with a nested item in the parent entity. When one item gets expanded, the related item is also usually automatically expanded, on the same nesting connector.
• «extends» – dependency item for generalization or inheritance, usually just for types. Interfaces may have multiple inheritance and more than one <<expands>> item. Model Xtractor also generates such a redundant item for different database tables with one-to-zero/one relationships.
• «implements» – dependency item for realization, for each implemented interface. When dropped over shape’s header, it expands into an implementor, shared by all implemented interfaces of that type. When dropped outside the shape, it expands into a realization connector to the implemented interface shape.
• «uses» – dependency item determined by Model Xtractor for an entity, when it is using in some way another entity of the same kind and requires its presence.  The concept is similar to UML’s both “depends” and “uses“. Expansion of this kind of dependency items may lead to what you know from UML as deployment diagrams (for products), component diagrams (for containers), package diagrams (for groups) or simply dependency diagrams (for types). Types depend or use other types if they appear in their members’ signatures. Dependencies on primitive and very frequently used types are not usually generated. For products, containers and groups, dependencies are also based on type usage, rather than on implementation details: if from imported metadata we determine that one entity has types using types from another entity, first entity is using the other. When bidirectional, expanded items share the same dependency connector, with arrows at both ends.
• «template» – dependency item for template substitutions. Expands into a specific connector to the template definition type, the generic type used in the definition of the derived generic type. For instance, List<Collection<T>> (a list of generic collections) would be a template substitution of List<T>, where the generic parameter T has been replaced by Collection<T>.
• «param» – dependency item for single parameter from a template substitution or definition, that can be represented as shape. For instance, the List<Collection<T>> template substitution will have a <<param>> dependency item expandable to Collection<T>. However, the T generic parameter of Collection<T> cannot expand as shape, and so this last type will present no <<param>> items.
• «alias» – dependency item for types declared as typedef of another type or combination of types. It’s usually the only item of its shape, and gets automatically expanded into a typedef connector to its related type.
• «elements» – dependency item for the type of elements contained in an array or collection type. Model Xtractor can either build on-the-fly array types such as FileInfo[ ], or detect on import and mark some types as collections. Dynamic arrays usually have one single item, with their element type (FileInfo[ ] has elements of FileInfo type). Collection types may also have one <<elements>> item, if their element type could be determined. When regular items expand into an array or collection type, this last shape will usually automatically be minimized and the <<elements>> item expanded. This is the most consistent representation of multiple associations to elements part of an array or collection.
• «throws» – dependency item expandable into a specific connector to an exception class. It shows a type, or members of that type, can throw that kind of exception.
• hidden – hidden items do not appear in generated diagram images and are shown, with strike though text, only when their parent shape or connector is selected. The visibility status can be turned on and off on selected items by the Ins key. Some items are automatically made totally invisible when expanded into specific connectors: generalization, realization, nesting etc.
• highlighted – turn on and off an item or shape title highlight by a double-click on its text area. Highlighted text appears with yellow background, even in monochrome themes.

Connectors

• nesting – link between two different shapes, with a + sign on parent’s side. Result of either a nested item or <<parent>> dependency item expansion.
• generalization – directed link between two different shapes, with an empty big triangle pointing to the base type. Result of an <<expands>> dependency item expansion.
• realization – directed dash link between two different shapes, with an empty big triangle pointing to the implemented interface type. Result of an <<implements>> dependency item expansion.
• implementation – link between a shape and its implementor (a small empty circle, that moves with the related shape). Result of an <<implements>> dependency item expansion (drop item on shape’s header, not outside). Shared by all implemented interfaces of a type.
• instantiation – link between a shape and its instantiator (a small filled-in circle, that moves with the related shape). Result of a public instance constructor item expansion. Shared by all expandable constructors of a type.
• dependency – directed dash link to another shape, with open arrow as end point, or arrows at both ends (if bidirectional). Result of <<uses>> dependency item expansions.
• association – directed link to another shape, or to the shape itself (if reflexive), with single arrow as end point. Result of a regular item expansion, other than database table relationship. If property or field, the starting point can show a composition or aggregation.
• aggregation – association connector with empty diamond as starting point. This is when a type contains a reference to another type, exposed as either a property or field.
• composition – association connector with filled-in diamond as starting point. This is when a type contains the value of another type, exposed as either a property or field.
• elements – directed dash link to another shape, with multiple arrow at end point, to show the type of elements from an array or collection. The starting point show always either an aggregation or composition, depending on the type of elements. Result of an <<elements>> dependency item expansion.
• relationship – specific database connector between two tables, or reflexive on the same table. Shows one-to-zero/one, one-to-many and even many-to-many cardinality and multiplicity, in either IDEF1X notation or (when Simplified) Crow’s Foot notation.
• template substitution – directed dash link between a template substitution shape and its template definition (or substitution) shape, with big filled-in triangle as end point. Result of a <<template>> dependency item expansion, from a generic type.
• template parameter – directed dash link between a template substitution shape and the type used for one of its generic parameters, with big open arrow as end point. Result of a <<param>> dependency item expansion, from a generic type.
• typedef – directed dash link to a base type shape, with = sign as starting point. Result of an <<alias>> dependency item expansion, from a typedef type. There could be only one such connector between two shapes.
• exception – directed dash link to an exception type shape, with specific adornment as starting point. Result of a <<throws>> dependency item expansion, from a type. There could be only one such connector between two shapes.
• comment link – manually created dash link from a comment shape to any other shape, by holding and dragging the small triangle selector from the bottom edge of comment shape’s selection frame. There could be one such link only between two shapes. This is the only kind of Model Xtractor connector not being created from an item delegation.