Specification and Design

Approach

To generate an application, the programmer must define two descriptions of the system, represented as XML files. One describes the application semantics. The other describes a particular layered implementation that can meet the application's performance and design requirements. We refer to these descriptions as the appl.xml and impl.xml files. Whereas the programmer may create either file by hand, we provide on-line tools, described below, that greatly simplify and speed-up the process.

Application Description

The application description includes the following components:

user types
data objects, including properties and methods
interactions between user types and data objects
relationships between data objects.

The first two of these are self-evident. The third -- interactions between user types and data objects -- constitutes object method level access control. That is, it describes which methods for a given object a particular user type may or may not execute. The last, relationships, conforms to the familiar dbms notion of relations. In an object-oriented system, relations are normally expressed as getter and setter methods on objects, such that one may use a get or set method on one object to access a second object. We have followed this convention for implementing relationship-related methods in our generated code.

Example: application description.

Implementation Description

The same application description could be used to generate solutions implemented in several different ways, based on which technical resources are/are not used. For example, an application that includes just a few pages filled with content obtained from a database could be implemented as PhP pages served from an HTTP container. However, an application that includes more complex and/or dynamic page navigation and one for which a more substantial object-oriented language is desired might be more appropriately implemented in Java, using JavaServer pages served from a Java Server or so-called Web Container. A still more complex application that requires transactions, asynchronous messaging, and, especially, scaling and load balancing, would be implemented more appropriately using J2EE resources and one or more EJB Container(s).

More specifically, five different layered options are supported:

a seven layer J2EE implementation that includes model, view, and control layers in the Web container; EJB Session, domain model, and Entity EJB layers in the EJB container; and a DBMS persistence layer;
a five layer J2EE implementation intended for early testing that concludes with a domain model stub layer and no Entity EJB or DBMS layers;
a four layer implementation that includes only the three Web container layers and a DBMS persistence layered accessed through JDBC;
a three layer implementation intended for early testing that includes the three Web container layers but concluding with a model stub layer and not DBMS layer;
a two layer implementation intended for an HTTP container that includes a PhP view layer and a DBMS persistence layer.

The particular implementation that would appear to be be best suited for a given application is inferred by a project tool, described below, based on user input. The resulting implementation description includes the following components:

containers (HTTP, WEB, and/or EJB)
layers within container (view, control, model, etc.)
within-container objects (e.g., Struts ActionForms)
between-container objects (e.g., databeans)
parameters (e.g., dbms access parameters)

Example: implementation description

Tools

To facilitate defining and editing the appl and impl descriptions, we have developed a tool we call ProjectManager. It is a J2EE application that runs within a WebSphere application server. Mulltiple usrs may register, login, and form access groups. Members of these groups may then invoke a Java Applet that includes panels for defining the following parts of an appl xml file:

user types
data objects, included properties/variables and methods
interactions between user types and data object methods
relations between data objects

A screen image of the Applet overview panel is shown below:

Figure 2: Application Description Tool

An image of the data object tab is also shown:

Figure 3: Application Tool -- Data Object Tab

In this example, the applcation includes three data objects: user, login, and ab. The login data object includes two properties, loginName and loginPassword. In addition to the five CRUDS methods, it also includes createLogin and login methods.

To facilitate creating the implication description, we provide a checkbox questionnaire. Based on the answers to these non-independent questions, we try to infer the simplest simplest layered implementation that satisfies all of the constraints. A portion of the questionnaire is shown, below:

Figure 4: Implementation Description Questionnaire

On the basis of a user's answers to these and some fifteen additional questions, we deduced that the most appropriate architecture for this application would be a seven-layer J2EE one intended for deployment in WebSphere.

Once defined or generated, the appl.xml and impl.xml files may be stored in the ProjectManager's database, after which they may be edited and/or downloaded via the Web to be saved in the user's file system.