The system described above is operational. Users may download and install the WSAD and/or RAD plugins in their systems. They may also login to the Project Manager system, create and save multiple application and implementation descriptions, and download them to their local machines. After that, they may start their development environments, invoke the plugin, and generate a project structure for their application. Once that is done, they must perform the manual steps, outlined above, to produce a running system. For a simple three or four object application, this should take some 10 to 15 minutes, perhaps a bit longer the first few times one does it. To add "niceties" such as welcome and logoff pages, to refine generated JSP pages, etc. will take additional time. But the process should be an order of magnitude faster than building the application from scratch.Work Completed
Work will continue on the present, operational components, particularly to reduce the number of manual steps required for cleanup. We also plan to have a half-dozen users work with the system in the near future and will evaluate and refine it in response to their experiences. However, our main focus will shift to the activities described next.
Once one has descriptions for several applications, a natural progression might be to combine them into a composite description in order to then generate a system that includes the features of the constituents. For example, consider the following scenario. A user develops the description for an application that supports an online addressbook. It wouldn't be a very practical application since all users would share the same data. But then suppose the user develops a second application that handles user registration and login. This second application could be implemented and run independently from the first. But suppose they could be combined: the composite application might then allow users to register and login, but each could then be provided with an entirely separate addressbook for his or her own personal data. Now, imagine a third application that, like the original addressbook application, supported a music catalog. If it could be combined with the user management and addressbook applications, users would also be able to manage both their music and their personal contacts in the same application. Etc. for other forms of data, such as photographs, recipes, calendars.Composing Applications
The underlying concept here is to think of building applications from a library of simple component descriptions. These descriptions would, of course, be extremely light weight. Tools included in the project manager would allow users to store these component descriptions and to compose them to build up descriptions of larger, more complex applications. Since each of these composites would, itself, be a legitimate application description, each could be down loaded and used to generate an implementation for that application or it could be used incrementally in another composition to build a still larger application. We have built a few simple compositional tools and are currently exploring their use and implications.
As one combines smaller applications to form larger ones, the process begins to feel a bit "mathematical." That is, combining two applications may seem like an "addition" operation. If one provides an inverse composition function, whereby one can remove a constituent from a combined application formed earlier, that process may seem like a "subtraction" operation. In both of these cases, we have defined composition functions that either simply add to the description of one application the data objects in the second or the reverse. But in some instances, if one combined the data objects, one might wish to not just include them as independent objects but to define a relationship, in the database sense, between them. Doing so might seem like a "multiplication" operation, whereas undoing such a composition might be thought of as a "division" operation.Algebra of Applications
Thus, we are finding that certain compositional operations have a seemingly natural correspondence to simple algebraic operations. This is leading us to ask the question:
Can we develop an algebra of applications that would describe, formally, a set of rules for building valid, more complex applications from simpler constituent applications and would let us reason about the results?
An area of math that includes the four basic arithmetic operators and seems relevant is Field Theory. Examples of fields include the rational numbers, real numbers, and complex numbers. We are currently trying to define an algebra of applications as a mathematical field.
A third area in which we are working is trying to apply our ideas to the notion of patterns. Design patterns have, of course, made a dramatic impact on software engineering. Is there a comparable notion of pattern that can be applied at the application level? Martin Fowler's work on Analysis Patterns makes us think this may be so. We are interested in exploring this possibility, but have not delved deeply into the idea yet.Application Patterns