A key problem early in the cycle of developing an application is how to understand and document abstract information. We usually understand information through the user interfaces that create it, but it is usually not practical in the early stages of the application development cycle to begin by documenting interfaces. Also, later in the life of that application, when an additional installation desires to reuse all or some its components, we need to document the data and data structures of that application in a way that can easily be understood and reused. Further, when we have two versions of the same application, we need a way to analyze and document the information differences between those two versions.

What we are particularly looking for is a high-level, pictorial representation of complex information that assists us in understanding and analyzing its effectiveness and provides the foundation against which business rules and human interfaces can be easily defined. It is also critical that the information representation, along with the rules and interfaces, can be enhanced and modified so that the design of the system can grow from its early inception to its final state and beyond.

The LOD is the AOA component that fulfills this requirement. Working relative to the ER Diagram, which documents persistent data in general, the LOD documents “data in context,” meaning data that is used to address a particular functional need.

For example, within the development and maintenance of OpenCUAS, it is important to understand all the components that make up class information and how they are structured. A class in an academic ERP is a course offered for a particular college term, at a time, in a room, taught by a professor and taken by a specific group of students. The LOD, shown to the right, is a diagram of what these components are and how they’re related in an abbreviated version of the Class LOD in OpenCUAS.

If we further refine the context to say that we want the class information to be used in a maintenance interface, we add further information to the object diagram to define how components are built in creating the whole. For example, in the diagram, a Class entity and its attributes are to be created as a part of the creation of a class object instance. However, the Course entity, which is an import part of the class information, is not created here but is “included” from course information created elsewhere.

As a definition of abstract information (i.e., information not tied to an interface), the LOD is used both in the early stages of analyzing and constructing data and in the later stages of documenting the result of that thinking. As a bonus, the LOD is also used during application execution for evaluating the effectiveness of rules and interfaces transforming that information.

In addition, the LOD is a vehicle for tying rules (i.e., operations or methods) to abstract information structures. In this respect, the LOD is very compatible with the traditional definition of an object. There is also a major difference, however, as the LOD “exposes” the logical structure of data, even while it “hides” its physical structure. That logical structure is represented in graphical form in the diagram.

It should be noted that an important advantage of using the LOD for documentation purposes is that it can never get out of sync with the executing system, because that system is generated from the LOD. One way of looking at this is that the “documentation drives the system.”