The Application Automation Layer: Introduction And Design

The Application Automation Layer: Introduction And Design

This introduction lays the foundation for the concepts behind the Application Automation Layer (AAL). Because this article is long enough just discussing concepts, there is no example code here--a considerable amount of code already exists in other articles that I've written. I am currently setting up a SourceForge site for public access. Future articles will discuss the AAL implementation itself and use a demonstration project (photo album organizer) to illustrate its use.

What Is Wrong With Object Oriented Development?

Objects are often interconnected. It makes for a pretty object model diagram, but class re-use is all but impossible because of the interdependencies between objects. This results in slow builds, cascading side effects when code is changed, and complex testing.

In many designs, objects insufficiently abstract the concepts that they are trying to represent. This introduces “rigidity” into an application. The less abstract an object is, the more difficult it becomes to change its behavior. Applications become inflexible to requirement changes and new technologies, and become unresponsive to market changes.

Why Do We Need An Application Automation Layer?

1. Design, development and testing of large scale applications is too expensive;
2. The longer a development effort takes, the more likely the requirements will have changed, either as a result of customer requirement changes, technology changes, or competition;
3. Design and implementation methodologies vary greatly across a multi-team project, resulting in code sharing and maintenance problems. A framework that promotes a consistent design and implementation philosophy reduces this difficulty;

Does The AAL Benefit Small-Scale Application Development?

1. Many small-scale, single developer applications embrace multiple technologies. The AAL reduces the time it takes to hook these technologies together and to add a new technology that interfaces with existing ones.
2. By starting with a framework that promotes re-use, an application that appears to be small-scale can migrate to a large-scale effort without redesigning and rewriting code;
3. Rapid prototyping.

What Are The Advantages Of The Application Automation Layer?

1. Build projects with debugged and tested components;
2. Built in instrumentation allows tracing of all events;
3. Component-based development;

Has This Concept Been Implemented And Tested In The Real World?

Yes. A brief description of three projects (of many) that currently use the AAL as implemented in C++/MFC:

1. Automation Of Satellite Design: A large-scale, multiple developer, three year project to automate the design of communication relay satellites.
2. Boat Yard Workflow Management: A medium-scale, single developer, multi-year project to manage the workflow of boat yard operations—work orders, job tracking, inventory, payroll and customer billing. The AAL framework allows the support of custom data representation and workflow processes for different boat yards, while retaining the same code base.
3. Club Management: A medium-scale, single developer, multi-year project managing the income of adult entertainment clubs and entertainers. This system utilizes complex scheduling, threading and inter-process communication.

What Does The Application Automation Layer Do?

Primarily, the AAL consists of several technologies:

1. A Data Hub
2. A Process Manager
3. A Component Manager
4. Instrumentation Package

Additional features of the AAL are considered “technology components” and are not discussed in this article. These include:

1. GUI Controls
2. Database Interface
3. State Manager
4. Additional technology component interfaces

Data Hub

The data hub provides a common data exchange mechanism between technologies that have different data representation schemes. The classical approach is illustrated in this figure:

Here, the application has an application-to-technology specific interface for data. Using the AAL, the data exchange occurs as follows:

For example, a typical application is responsible for reading a record set in to a database and reformatting it for a particular GUI control. If instead the AAL concept is used, the application instructs the database technology to load the record set. This record set is translated, by the database technology, into a common data representation. The application then instructs the GUI control to display this information. The GUI control extracts the common data representation and formats it to the particular requirements of the control.

Furthermore, the concept of loading a record set has been sufficiently abstracted by the database technology that it can handle a generic record set specified by a SQL statement, for example. Many applications seem to embed record specific functionality. This makes the application inflexible to requirement changes. The point here is that while the programmer can still do it “the wrong way”, there is now a technology that promotes (if not enforces) a better approach.

The concept of a common data representation is also used by the C#, Visual Basic and other compilers—all code is compiled into a common code language.

Process Manager

The process manager decouples unrelated objects by using a meta-interface. This reduces build time dependencies and problems related to changes in object designs, as described above. The process manager is implemented as a script engine that directs the acquisition, exchange, manipulation and deposition of data.

Processes are typically initiated by events, and of those, typically GUI events such as clicking on a button or selecting a list. Therefore, to take full advantage of the process manager, the Forms plug-in technology interfaces with the process manager in response to GUI initiated events. And as illustrated in the above diagram, the Forms plug-in interfaces with the Data Hub. These two concepts create a powerful combination that decouples GUI driven processes from the specific GUI. This is one of the fundamental steps in designing a program to be more flexible to requirement changes. I’ve seen too many applications where the “processing” is part of the “OnClick” handler of a button!

For example, consider the typical process flow that an application takes to load a GUI control with a record set, as illustrated in this diagram:

Versus the process flow an application would take with the AAL:

Notice that in this diagram, the “application” (in the literal sense, any C# specific code) is not used. The process manager is based on the event manager described in my article An instrumented synchronous/asynchronous event manager [^].

Component Manager

The component manager promotes component-based development. The application itself is considered another technology which is merely another plug-in to the framework. The component manager is responsible for loading and unloading of technology components and the registration of the component’s public interface.

Instrumentation

A fallout of this scheme is that an application is automatically instrumented—data exchanges, event invocation, object to object messaging all include instrumentation, so that it is very easy to trace an application. The AAL includes an instrumentation package (see my article on C# Debug And Trace Classes [^]).

What About Agile Programming and eXtreme Programming?

The AAL is an implementation of a framework that supports these project development styles. AP and XP are excellent ideals that can only be achieved by implementing a framework such as the AAL. The AAL has been proven to be effective in its goals, even before the concepts of AP and XP existed.

Conclusion

In the next couple of articles, I will present the implementation for the four components I discussed above. I hope no one gets upset that there isn’t any code in this article. I intended this article to present the foundational design concepts without getting mired in specific implementation issues. As a side note, I am also planning to integrate the concepts that I presented in my Organic Programming article [^] with the concepts in the AAL.

As I mentioned before, I am currently in the process of setting up a SourceForge site to support this effort. However, if you want a sneak peak at some prototype code, see my recent article on Fractal Trees [^].

Given this overview, I am interested in feedback from the programming community. And anyone who is interested in working on this project, please let me know!