As mentioned above, the LOD is the most important component in AOA and lies at the heart of most of the automation and also the modifiability and portability capabilities. It should be seen as an extension of the object in OOP to the logical design level. All rules and external interfaces process data using LOD objects. In fact, it is impossible in an AOA application to access any external data except through such an object. Thus, from this point on in the presentation, the word, “object” or “AOA Object” will always refer to an instance of a LOD, unless it is preceded by a qualifying adjective. The term LOD will always refer to the definition of an object.

A LOD is composed of one or more entities, which may be a combination of database (persistent) and work entities and attributes. Those entities are tied to each other through their ER relationships for persistent entities or through “imagined” relationships for work entities, the result forming a “super tree” of entities. It is a tree because the relationships between entities always have a direction from the parent entity to the child entity. The super refers to extensions from a normal tree structure to support recursive relationships and parallel relationships (ie., the capability for two paths in the tree to lead to the same entity instance).

The two diagrams to the right display two parts of a Person LOD. The first shows the Address entity, with cardinality 0-to-m, and the PrimaryAddress entity, with cardinality 1-to-1. It also shows the two relationships that tie one person to another through a family relationship. Because this object presents both directions of the family relationship, we see one direction represented by the entity, DescendentRole, and the other by the entity, ParentRole. Because users don’t expect familty relationships to be displayed through a bi-directional relationship, the second diagram shows the derived subobject, FamilyRole, which is built as a combination of DescendentRole and ParentRole during the Activate Constraint, explained below.

As mentioned earlier, the physical structure of data is encapsulated but the logical structure is fully exposed. This is accomplished by a set of run-time routines called the Object Engine, which can be looked at as a class library for the LOD structure. Any element in an object is always referred to by three-level name, composed of a View, Entity and Attribute, such as “mPerson.PrimaryAddress.DateOfBirth”. Whether data in an object is referenced from an interface definition or from a rule, it is always reference by a combination of those three components.

LODs are primarily comprised of persistent data from the database, specified through the ER Diagram. However, it is very common for LODs to also contain work data, both work entities comprised totally of work attributes and work attributes that are added to persistent entities.

Multiple positions (called “cursor positions”) can be maintained for the same object at run-time, with each group of cursor positions being defined by a View. Thus a reference to mPerson.PrimaryAddress.DateOfBirth identifies a position within the tree structure for an object defined by the view, “mPerson”, a particular entity within the tree named “PrimaryAddress”, and a particular attribute within the entity named “DateOfBirth.” Note that this naming convention requires that a persistent entity appearing more than once in a LOD must have a modified name for at least one of them. Actually, this is common, as the name of an entity in a LOD often specifies its use. Thus, “PrimaryAddress” is used to define to denote that the Address entity in this LOD is the primary address, as opposed to just one of the multiple addresses that a person can have.

This naming convention is in contrast to a common naming convention used relative to XML and some object structures, where an entity is defined as a concatenation of parent entities within the tree structure. But the AOA naming convention is simpler than the parent concatenation and, more importantly, allows greater reusability by the rules that reference it, since those rules don’t require a knowledge of the parent structure, but only the names of entities actually being referenced.

There are a number of application development problems that need to be solved to allow a logical definition of an application to be “rich enough” to generate a complete, executing system. On the surface, it is not clear that these problems are even solvable at the design level. It seems particularly unlikely that they could be solved via a single, logical structure. And yet, that is the claim made about the LOD in this presentation. The LOD is the vehicle through which a number of application requirements can be defined at the logical level and then automated in the generated system. These are described in the section, “Application Development Challenges.”

Similar to objects in other languages, LODs have methods or operations. However, unlike OOP, those operations are primarily organized into three groups, Transformations, Object Constraints and Derived Attributes, described below. In all cases, the operations are comprised of VML statements defined further in this presentation. The diagram to the right displays the Operations from the mPerson LOD. As is commonly the case, most of the Operations are Derived Attributes, while there are several Transformations, as well as both an Object and an Entity Constraint.

Transformations are very similar to traditional OOP methods, in that they have parameters and are always triggered from another operation. As their name suggests, they are usually used for transforming data from one form or another. Usually, most of that data is defined in the LOD. However, views to other objects can be parameters in the operation and such operations regularly manipulate data in a variety of objects.

Object Constraints are triggered automatically during the work flow of an object, commonly at the activate point, when an object is read from the database, and at the commit point, when data that has been created or modified in an object is written to the database. A common use of an object constraint on commit is the triggering of rules to validate the state of the data and abort the process if errors occur. A common use of an object constraint on activate is to build work data from persistent data to display that data in a different form. A good example of this is an academic transcript, which organizes the data for presentation in a very different manner than that stored in the database.

Derived attributes allow an attribute to be defined that is really the result of a rule applied to other attributes. A simple example of a derived attribute is “FullNameLFM”, which concatenates the attributes LastName, FirstName, MiddleInitial and NameSuffix into a single name for display purposes. A complex example is “GPA”, which executes extensive rules on several entities of the Transcript object. It should be noted that a derived attribute can be used like any other attribute and included in any user interface or used in other rules.