AndroMDA is an automatic tool with a medium amount of intelligence built into it. Such a tool always has to rely upon some clearly defined preconditions; in the case of AndroMDA, these preconditions are modeling conventions. This means that a UML model for use with AndroMDA cannot be structured arbitrarily but has to adhere to a certain structure that can be interpreted by AndroMDA.
On the other hand, not too many constraints should be imposed on the modeler - after all, a model should represent the conceptual reality of the customer's requirements and the structure of the application domain.
To sum up it all up, we've tried to keep the number of rules low in order to keep your freedom of modeling high. Keep in mind: modeling standards/requirements will ultimately be dependantant on the implementation(s) of the cartridge(s) you employ at build time. Each cartridge has required properties and modeling conventions that must be followed. See Cartridges for more information. In general, there are rules to follow (seen below) when you start sketching a design model and you want AndroMDA to generate your components smoothly.
Stereotypes drive code generation!: UML Stereotypes are a kind of "label" that you attach to modeling elements in order to classify them.
Please note that AndroMDA can now also generate code from templates based on properties of any model element found in the XMI, so theoretically it is possible to generate code without even using stereotypes.
Example: You tag a CustomerService class
with a
<<Service>>
stereotype.
AndroMDA sees this stereotype, looks into its internal
dictionary of available code generation components (called
"cartridges") and finds the EJB cartridge. In the EJB
cartridge, two templates correspond to the
<<Service>>
stereotype: SessionBean.vsl and SessionBeanImpl.vsl. AndroMDA uses the
internal representation of CustomerService loaded from the model,
calls the processing engine twice, and two output files are generated:
CustomerServiceBean.java and CustomerServiceBeanImpl.java.
A small model, containing an element tagged with the
<<Service>>
stereotype,
can be seen in this picture:
Even though modeling will depend primarily on how the cartridge is implemented. There are some standard ways of modeling which MUST be followed to ensure the model is syntantically and semantically complete, meaning the cartridge performing generation has enough information on which to generate from.
These are listed here.
composite aggregation
.
An association between a house and a room is a good
example of composite aggregation
. Destruction of the house
implies destruction of all rooms that the house contains.
Therefore the association end of the house to a room would be
defined as composite aggregation
(i.e. a black diamond).
java.util.Set
instead of a
java.util.Collection
(if it was left
unspecified or defined as unordered).
Datatypes
for simple types.
Use UML Datatypes
for simple types such as String,
Collection, Set, etc. instead of using the language
specific types which the tool may implement by default
(i.e. java.lang.String). You want to keep the model as
language independant as possible. Cartridges use mapping
files at generation time to map Datatypes to specific
language types (i.e. for Java, these could be: Collection -->
java.util.Collection, Blob --> java.sql.Blob, etc.)