Categoria: Object Dependencies

Zim contains a number of fixed object types. The objects in any application depend on each other in various ways. These dependencies among objects form a network of interrelationships.

An EntitySet, for example, depends on its fields. If the definition of a field changes, then the definition of the EntitySet changes. A relationship object depends on the EntitySets that it is relating. A relationship object can also use constants, variables, and form fields, and so depend on those objects as well. A program can reference any object, including other programs. These references create dependencies between the program and the objects referenced.

ZOM tracks dependencies between objects. There are two basic kinds of dependencies:

• Creation Dependency
• Program Call Dependency

A Creation Dependency occurs when an object references another object in its definition (i.e., when the object is created).

A Program Call Dependency occurs when a document object references another object in its program code.

The diagram below shows the objects in a hypothetical application. The lines between objects illustrate dependencies between objects. This diagram is called the object dependency tree. Program that call dependencies are shown as solid black lines, while creation dependencies are shown as dotted lines.

The sample application represented here has four program objects: pMainMenu, pEditCust, pFindOrder, and pEditOrder. pEditCust and pFindOrder are called from pMainMenu. pEditOrder is called from pFindOrder. Each of these programs uses a different display object (whose names all start with “d”). The display objects, in turn, depend on form objects (whose names all start with “f”). As well, there are three EntitySets, Customers, Orders and Inventory, and two relationships, Place and Require, the latter with fields.

If we look at the object dOrder, we can see that dOrder depends on (i.e., uses) both fOrder and fFrame (via creation references). On the other hand, dOrder is depended on (i.e., used) by the program pFindOrder (via a program reference). The object fOrder depends on no other objects, but is depended on by dOrder and pFindOrder.

Example Object Dependency Tree

ZOM enables you to query the dependencies between objects and use this information to process dependent objects. You can also use this information to detect unreferenced objects that are not dependent on any other object.

There are two ways to query object dependencies:

1. A Dependency Explosion finds the objects that depend on (i.e., use) a given object. Dependency explosion begins with an object and works up the dependency tree finding objects that use the given object. You can limit the explosion to one level up the tree (i.e., immediate ancestors) or recursively retrieve dependent objects all the way back to the root of the tree.
2. A Dependency Implosion finds the objects that are depended on (i.e., used) by a given object. Dependency implosion begins with an object and works down the dependency tree finding objects that are used by the given object. You can limit the explosion to one level down the tree (i.e., immediate descendants) or recursively retrieve dependent objects all the way to the leaves of the tree.

The dependency information tracked by ZOM leads to some of the most powerful uses of the ZOM services in developing, maintaining, and analyzing your applications.

The object dependency information can also be used to select un-referenced objects that are not used by any other object. In our example, there are three un-referenced objects: pMainMenu, PlacedBy and vJunkVar. Un-referenced objects can be selected using the “u” selection criteria, as shown in the following example:

ZOMList +p u

Objects Found by Unreferenced Criteria “+p u”

Often, objects that are not referenced are no longer in use by the application and can be destroyed. This is not always the case as shown above where the unreferenced pMainMenu, which is the root of the dependency tree, is a very significant object to this application. Another object, the role PlacedBy, could have been created in the application as a convenience to users entering ad hoc queries.

Dependency implosion is the process of finding the objects which depended on (i.e., used) by a given object, and so on down the dependency tree. There are three different kinds of implosion: immediate, creation, and program.

As an example, to list all of objects that are used by pMainMenu, enter

ZOMList pMainMenu +i

The result is the list of objects that are used by pMainMenu directly, regardless of whether the dependency is creation or program. The diagram below highlights the selected objects:

Objects Selected by “pMainMenu +i”

This selects only objects that are used by pMainMenu explicitly by means of a creation dependency or a program dependency. The objects that use these depended on objects are ignored.

Similar to dependency explosions, you can implode by either creation dependencies (using the ‘t’ option) or program dependencies (using the ‘p’ option). Now suppose we want to list only the objects that are used by pMainMenu by means of a program dependency:

ZOMList pMainMenu +i p

The diagram below highlights the selected objects:

Objects Selected by “pMainMenu +i p”

This selects only objects that are used by pMainMenu by means of a program dependency, as well as any objects that have program dependencies on these dependent objects, and so on all the way down to the leaves of the tree. Creation dependencies are ignored.

 Next suppose we want to list only the objects that are used by pMainMenu by means of either creation or program dependencies and recursively search all the way down to the leaves of the tree:

ZOMList Customers +i pt

The diagram below highlights the selected objects:

Objects Selected by “pMainMenu +i pt”

This selects objects that are used by Customers by means of any dependency, as well as any objects that have a dependency on these dependent objects, and so on all the way down to the leaves of the tree.

To list only the objects that are used by pMainMenu by means of either creation or program dependencies and recursively search all the way forward to the leaves, but not include the pMainMenu object, enter

ZOMList pMainMenu +i pth

The diagram below highlights the selected objects:

Objects Selected by “pMainMenu +i pth”

This selects only objects that are used by pMainMenu by means of any dependency, as well as any objects that are used by these dependent objects, and so on all the way down to the leaves of the tree, but not the set of objects that were used as the starting point of the implosion. This is called a hollow implosion.

In a hollow implosion, the selected object set does not contain the original objects that fed the implosion algorithm in the first place.

Dependency Explosion is the process of finding the objects which depend on (i.e., uses) a given object, and so on up the dependency tree. There are three different kinds of explosion: immediate, creation, and program.

As an example, let’s suppose we want list all of the objects that use Customers:

ZOMList Customers +x

The result is the set of objects which use Customers directly, regardless of whether the dependency is a creation dependency or a program dependency. The diagram below highlights the selected objects:

Objects Selected by “Customers +x”

This selects only objects that use Customers explicitly by means of a creation dependency or a program dependency. The objects that use these dependent objects are ignored.

Now suppose we want to list only the objects that use Customers by means of a creation dependency:

ZOMList Customers +x t

The diagram below highlights the selected objects:

Objects Selected by “Customers +x t”

This selects only objects that use Customers by means of a creation dependency, as well as any objects that have creation dependencies on these dependent objects, and so on all the way up to the root of the tree. Program dependencies are ignored.

 Next suppose we want to list only the objects that use Customers by  means of a program dependency:

ZOMList Customers +x p

The diagram below highlights the selected objects:

Objects Selected by “Customers +x p”

This selects only objects that use Customers by means of a program dependency, as well as any objects that have program dependencies on these dependent objects, and so on all the way up to the root of the tree. Creation dependencies are ignored.

 Next suppose we want to list only the objects that use Customers by means of either creation or program dependencies and recursively search all the way back to the root:

ZOMList Customers +x pt

The diagram below highlights the selected objects:

Objects Found by “Customers +x pt”

This selects only objects that use Customers by means of any dependency, as well as any objects that have a dependency on these dependent objects, and so on all the way up to the root of the tree.

 Now suppose we want to list only the objects that use Customers by means of either creation or program dependencies and recursively search all the way back to the root, but not include the Customers object:

ZOMList Customers +x pth

The diagram below highlights the selected objects:

Objects Selected by “Customers +x pth”

This selects objects that only use Customers by means of any dependency, as well as any objects that have a dependency on these dependent objects, and so on all the way up to the root of the tree. However, this does not select the set of objects that were used as the starting point of the explosion. This is called a hollow explosion.

In a hollow explosion, the selected object set does not contain the original objects which fed the explosion algorithm in the first place.