Inheritance is a very important concept in AOA, but its structure is significantly different from that used in Object Oriented Programming. In OOP, there is no logical structure to inherit and exposure to the object is only through the operations defined for it. AOA, on the other hand, with its emphasis on logical data structure, introduces a modification called “Structural Inheritance”. In structural inheritance, most of an object is hidden (or is at least of no consequence) to an operation rule or interface control that references data within the object. Instead, the operation rule or control works only with a logical subobject (i.e., a substructure of the larger object) within the object. Significant reusability of the operation and control are thus gained as they function against any object that contains the valid subobject structure.

Structural inheritance is applicable from the simplest of problems to the most complex, with the simplest examples working on a single entity within an object. Three single entity examples follow.

Combo boxes and tables: Two very common human interface techniques used in MS Windows and the web are combo boxes and tables. In a combo box, one entity is selected from many through the presentation of a single attribute. In tables, one or more entities are selected from many through the presentation of multiple attributes. These functions occur automatically (i.e., they are inherited) for an entity within any object.

Combination names: In support of many interface displays, names are combined in various ways for display, such as “Williams, John H.”, “John H. Williams”, “Mr. John H. Williams” or “Dr. John H. Williams”. The operations supporting this functionality work on any object entity with the necessary attributes, such as LastName, FirstName, MiddleName, Title and Gender.

Combination addresses: The operation to format the attributes from an address into another single, multi-line attribute is similar to the name example above, except that it throws in the extra twist of being able to handle variations in the attributes contained in the entity. Some address entities contain more than one line of street, as well as an optional Attention attribute. AOA allows the operation formatting the address to ask the object if it contains a particular attribute and modify the formatting accordingly.

A typical example of a multiple entity inheritance is found in the OpenCUAS operation to generate charges for a student. The rules to generate charges use a fairly complex set of subobject data, including enrollment entries and prior charges. The primary object for this purpose is mSAProf, part of which is displayed to the right. However, there are other situations where those billing rules need to be applied to another object with a similar structure, such as in mSAProfE, part of which is also shown to the right. The two subobject structures look quite different, but they both have the same sub-structure necessary to execute the billing rules.

 

Though there are dozens of examples in OpenCUAS of reusability using single entity inheritance, and several using multiple entity inheritance, it is expected that structural inheritance will see its greatest benefit in supporting reusability through universal design objects in the cloud. One likely reusability option will be in support of complex composite controls working on special subobject structures. An example appears in OpenCUAS in support of a student/class survey interface.

It is a common practice for colleges to have students fill out a survey rating their satisfaction with a class just taken. OpenCUAS supports an online survey interface for capturing that data and reporting the results. However, that interface uses web controls organized in a manner not supported by the standard AOA control painter. Thus, a special control was created that works against the LOD subobject of SurveyQuestion and SurveyMultiChoiceOption, generating special HTML at execution time based on the data content of the subobject. The results of the web interface are shown in the first diagram above, followed by the mStuSurv object, containing the SurveyQuestion subobject. The final diagram shows the painter interface, with a simple control that looks like a box in the background and the detail for the control in the foreground. Note that the only specifications of the latter are the web control property, “SurveyGroup”, and the view/entity pair, “mStuSurv/SurveyQuestion”, identifying the subobject.

The advantage of structural inheritance in this case is that the control works with any AOA object having the SurveyQuestion subobject structure. This doesn’t have a great advantage within OpenCUAS, as it’s unlikely that other functional areas will require a similar survey interface. However, if the control existed within a group of reusable controls out on the cloud, it could easily be applied to surveys in any industry.