To begin let's clear up the "RAD" bit. RAD stands for Rapid Application Development. Nowadays this might be confused with "XP" - which stands for "eXtreme Programming". The idea tho' is simply that you should be able to develop applications "rapidly" - while the "eXtreme" approach adds feelings of free climbing to make it all sound more eXciting.
The "Model-based" bit indicates that the process is "based" on the development of a "model". Maybe that's not too clear yet, but hopefully things will improve.
The Model describes the kind of data that the application should manage. It should also detail the properties that each "element" (object) contains and very importantly should describe the nature of the associations between the objects. Here is the Model definition for a simple Library application:
<orm name='Library' package='alchemy.library' copyright="Actionflux Ltd 2004">
<class name='Library' isroot='true'>
<attr label='Name' type='java.lang.String' default='The Library' islabel='true'/>
<attr label='Address' type='java.lang.String' guihint='rows:6'/>
<attr label='EMail' type='java.lang.String' guihint='email' restriction='email'/>
<attr label='WebSite' type='java.lang.String' guihint='url' restriction='url'/>
<attr label='TelNo' type='java.lang.String' restriction='telNo'/>
</class>
<class name='Author'>
<attr label='Name' type='java.lang.String' required='true' islabel='true'/>
</class>
<assoc>
<one src='Library' owner='true'/>
<many src='Author' classified='Name:alpha'/>
</assoc>
<class name='Book'>
<attr label='Title' type='java.lang.String' required='true' islabel='true'/>
<attr label='ISBN' type='java.lang.String'/>
</class>
<assoc>
<one src='Library' owner='true'/>
<many src='Book' classified='Title:alpha'/>
</assoc>
<assoc>
<one src='Author'/>
<many src='Book'/>
</assoc>
</orm>
The Alchemist does not generate a model based on a database schema.
Moreover, the resulting objects generated from the model cannot be used to access objects from a relational database.
Instead the Alchemist can process a model defined using XML or can
also be used "programattically" - not the best option to be honest.
The Alchemist has always used the defined model to generate a persistent data model based on the Generic Persistent Object model. This is a positive achievement in its own right. The generated model allows applications written to access the model to be written eXtremely productively, safe in the knowledge that the model will function correctly.
[Incidentally, the data model that the Alchemist uses to store the model was itself generated by the Alchemist]
Later on the Alchemist code generation included support for a MetaData interface
that enables object instances to provide access to the data model that defined them.
If you have used or are aware of the BeanInfo java class then you will have some idea
about the benefits of this kind of data.
The MetaData objects supported by the GPO objects are potentially
far more descriptive than BeanInfo. For example, they can indicate validation
restrictions and object association semantics among others.
Just as the Alchemist is able to identify practical patterns from a relatively
simple model, so it should be possible to use appropriate MetaData to
infer practical application interactions.
This is the basis of both the web and standalone application distributions available.
Both "application" approaches use the same MetaData. The web application
allows further customisation - for example to define reports.
But all the general interactions are inferred dynamically as the objects are interacted with.
How about five minutes? Yep, that's probably the record so far - to define a simple model to manage users and license keys for Cut The Crap licensee's. The only thing that slowed me down was the generation of a custom form defining the email sent to welcome the new users. Within five minutes I had defined the model and generated and installed a tomcat-based web application.
This is a point that may be missed. Since there is little to no input required other than the model itself, so the application can be developed solely by modifying the model. There is no inertia added to the process by other annotations - which is not true with approaches that require GUIs to be drawn that reference the model.
Visit the Cut The Crap Website and read more about the technology there, then download the distribution and follow the tutorial documentation.
Please let me know what you think!