12,065,756 members (44,426 online)
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.
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.
Yes. A brief description of three projects (of many) that currently use the AAL as implemented in C++/MFC:
Primarily, the AAL consists of several technologies:
Additional features of the AAL are considered “technology components” and are not discussed in this article. These include:
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.
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 [^].
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.
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 [^]).
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.
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!