In Model Xtractor we treat UML “dependency” relationships between containers or groups just like the “usage” relationships between types, because they mean essentially the same thing: one entity requires the presence of another entity (of the same kind) and uses it in some way. We also call “dependencies” only the unidirectional relationships from one entity to another, when first entity “depends” in some way of the other (inheritance, implements, usage etc).
“Uses” dependencies are determined based on the external types included in an entity: whenever a container, group or type “uses” types from another container, group or type, an expandable “uses” dependency item appears under the Dependency shape folder. Container and group dependencies are automatically expanded, based on the shapes already added to the diagram. Whenever a bidirectional dependency is manually or automatically expanded, its reverse dependency is also expanded, sharing the same connector link.
Container Dependency Diagrams
In Auto-Expand mode, most “uses” dependency items from the diagram below are automatically expanded each time you add a new assembly shape to the drawing area. For instance, you may start with mscorlib and add System.Xml. While second shape depends on mscorlib, a straight dash connector item will appear between them. Continue adding the other assemblies and the dependency diagram will get built by itself.
The only remaining “uses” dependency items are for shapes not already added to the diagram, like System.Transactions and System.EnterpriseServices, in System.Data. You can eventually further continue manually dragging these items and dropping them in the drawing area. Or adding the dependent shapes from the Metadata tree, in which case the dependencies will be automatically expanded.
Just for a better layout and clear visual understanding of these relationships, we can move around all these shapes and make some connectors not straight (by double-click on their lines). Leave System.Data with the Dependencies folder expanded, to see the unexpanded “uses” items. You get a nice symmetrical diagram, that shows bidirectional (reverse) dependencies between some entities.
All assemblies depend on mscorlib, which it makes sense to keep in the middle. An interesting fact is you may already know from practice there is a bidirectional dependency between mscorlib and System (i.e. mscorlib also uses System), but it does not appear here. Why? Because Model Xtractor imports, works on and shows only the external model, with exported types and methods. mscorlib may internally use System and require this assembly at compile time, but it has no exported public type with method parameter types from System. We may say mscorlib doesn’t externally require or use the System assembly.
Imported database containers are abstractions for database connections, exposing one or more schemas or catalogs. For each specific vendor and DBMS type (MS Access, SQL-Server, Oracle, MySQL), Model Xtractor also created a unique and specific <<dbms>> catalog with the primitive data types (use in table columns and stored procedures). Any custom database product “uses” this last specific entry, the DBMS itself:
Group Dependency Diagrams
These Model Xtractor diagrams are similar to the UML Package diagrams. For .NET assemblies, one namespace “uses” another namespace if it has (in its attributes, generics, member parameters or return types) types defined in the last namespace. While same namespace can be implemented by more than one assembly, you may encounter, in a shape, more than one “uses” item pointing to namespaces with the same name, but they will however belong to different assemblies.
This NET namespace dependency diagram shows some namespaces with types defined in mscorlib v4.0. In Auto-Expand mode, each time you add a namespace shape, all “uses” dependencies between this shape and the shapes already added to the diagram are automatically expanded (including the reverse dependencies, which share the same connector and have arrows at both ends). We left in the expanded shapes only the Dependencies folder unexpanded, to show all other “uses” dependencies that can be further manually or automatically expanded:
Similar diagrams can be created for Flash ActionScript packages. The dependency diagram below shows dependencies for MXML Charts packages:
Database schemas or catalogs are also represented by Model Xtractor as “groups”. When metadata of an imported database product shows more than one schema or catalog, there may be inter-dependencies between them represented also by “uses” items. For instance, when one table has foreign keys propagated from a table defined in another schema, the database schema the first table belongs to “uses” tables from the second schema.
Type Dependency Diagrams
Types frequently depend on other types, in the sense they pass or return as method parameters instances of external types. The “uses” dependency for types is similar to the UML “uses” relationship, but Model Xtractor uses the same acronym and concept for containers or groups. Model Xtractor automatically determines and shows all “uses” dependencies of a type, by looking at its member signatures (parameters and return types, inherited members excluded). Very frequently used types – such as primitive types (int, bool etc) and some basic types (string, Array, DateTime, void) – are also excluded.
The type dependency diagram below has some “uses” dependency items manually expanded (unlike containers and groups, type dependencies are never automatically expanded). We left some uses items in DirectoryInfo unexpanded, but they can be dragged outside the shape and translated into similar connectors. We kept visible only those member items with the dependent types in their signatures, as parameter types or returned types:
Model Xtractor also generates “uses” dependency items for database tables (which are similar to component types). One table depends on another table if it has foreign keys within, as propagation of the primary keys from the other table. Do not confuse these dependencies with table relationships, because they are more restrictive and have different meaning.
Take this dependency diagram, for all tables of the MS Access Northwind database. Orders may appear as an independent table, but each order requires a customer, shipper and employee, and Orders actually depends on the other tables. As an intersection table, Order Details is required for a many-to-many relationship between Orders and Products, and so depends on or “uses” these tables:
Normally, when an IDL type is used from a different module, it has to appear with a fully qualified name. For instance, AbstractView, when used by TimeEvent, should be views::AbstractView. However, IDL modules usually typedef external types like “typedef views::AbstractView AbstractView”. In Model Xtractor, these definitions are however transparent and we never prefix types with their module name, for simplicity.
IDL interface <<uses>> dependencies will not consider the primitive and basic types defined in the Web IDL Types <<core>> module. DOMString or long, used by smil::TimeEvent, do not generate “uses” dependencies, because they are basic core types. However, other types, such as views::AbstractView and views::DocumentView will generate using dependencies, whether or not the interfaces are in the same module or component, or not:
Leave a Comment