Modeling for AndroMDA
Andromeda is an automatic tool that has a medium amount of intelligence that is built into it. This kind of tool has to rely on various clearly, define preconditions. In this case, these preconditions are called modeling conventions. This defined means that a UML model that one uses with AndroMDA cannot be structured randomly but it needs to maintain a certain structure which can be interpreted by AndroMDA.
However, not too many constraints should be imposed on a modeler. A model should represent the conceptual reality of a customer's requirements and the structure of an application domain. To summarize try to keep the number of rules low in order to keep your freedom to model high. Remember modeling standards and or requirements will be dependent on the implementation of the cartridges you employ at the time you build. Each cartridge requires properties and modeling conventions that must be followed. Generally there are rules to follow when you start sketching a design model and you want AndroMDA to generate your components smoothly.
General modeling rules:
Stereotypes drive cogeneration: UML stereotypes are a kind of label that you attached to modeling elements to classify them. Andromeda can generate code from templates that are based on properties of any model element found in the XMI, so one can generate code without even using stereotypes. For example, you tag a customer service class with a "service" stereotype. Andromeda sees the stereotype looks into its internal dictionary of available code generation components or in other words cartridges, and finds the EJB cartridge. In this cartridge to templates correspond to the "service" stereotype. SessionBean.vsl and SeesionBeanImpl.vsl. AndroMDA uses the internal representation of customer service loaded from the model, calls the processing engine twice, and to output files are generated. CustomerServiceBean.java and CustomerServiceBeanImpl.java.
Even though modeling depends primarily on how the cartridges implemented, there are some standard ways of modeling which must be followed to make sure the model is syntactically and semantically complete. This means that the cartridge performing generation has enough information on which to generate from. These will be listed below.
Names: a general rule for all names is to capitalize the first letter of the concatenated word. This applies to all model element names.
Specify the type of all attributes and operation parameters: some tools will allow you to specify an attribute or operation without making you specify its type. Make sure you specify this, as a cartridge performing generation will expect this information.
Specify visibility were visibility counts: attributes on generated output will always be private, however the accessor and mutate are of each attribute will have the visibility that you will do fine in the model. For example, if you define the name attribute in your person element to have a visibility of public, then the accessor and mutate or for that element will be public as well. The same is true with private.
Specify the multiplicities of both ends of all associations. Cartridges use and require all multiplicity information.
Make sure names of association ends making up an association are unique within the Association. However if there is more than one association with the same name there will be conflicts of the generated output.
Do not leave unused elements dangling in your model. A big cause of syntactic incompleteness is the existence in the model of partially defined elements that go undetected by the modeler because they do not reside in any model diagram. Do not make the mistake of deleting the element from the diagram and then forget to delete it from the model as well.
If an element cannot exist without another element, define the association and of the owning element as a composite aggregation. An association between a house and a room is a good example of composite aggregation.
Specify ordering were ordering matters. When using multivalued attributes and association ends be sure to specify whether these are ordered in the modeling tool. Be sure to specify if ordering does matter for these multivalued properties since cartridges should be able to take advantage of this specification.
Do not add getter and setter operations for attributes. The cartridge will generate any required accessor and mutate or operations needed at generation time.
Define and use data types for simple types. Use UML datatypes for simple types such as String, Collection, Set etc. instead of using the language specific types which a tool may implement by default (i.e. java.lang.String). Try to keep the model as language independent as possible. Cartridges are using mapping files a generation time to map Datatypes to specific language types. For example for Java, these could be: Collection —>java.util.Collection, Blob —>java.sql.Blob,etc.