Designing a UML profile is a technically simple task, but should be done with great care nonetheless. Essentially, the UML profile for your project is just a set of possible stereotypes and tagged values that model elements can be annotated with. Their role, though, is very important, since they define the language you can work with as you model your domain.

You should strive to enable the creation of models that are simple enough to be understood, yet formal enough to enable code generation. In your iQgen templates, you can use this information to map model constructs to system artifacts. Because of this, having a large set of stereotypes and tagged values to finely control what kind of output to generate makes building templates easy, but burdens you (or whoever creates the model) with having to decide which element to chose for a given purpose.

From applying an MDA approach in a significant number of projects, our experience is that it's best to err on the side of too few stereotypes and tagged values and accept having to write more complicated templates. While this will increase the effort in setting up the infrastructure, templates can almost always be changed easier than a complex model.

It's also a good idea not to clutter your UML profile with low-level, technical details. This cannot be avoided completely. Still, it makes sense to e.g. not introduce a stereotype such as “EntityBean”, but rather opt for “Entity” - although you might consider a J2EE Entity Bean to be the best match in a given scenario, it should be possible to change this to some other mechanism (such as a non-J2EE persistence framework) without having to modify the model. Of course the name does not have any inherent meaning for iQgen, so it would be possible to generate, say, a C# class from a model element stereotyped with “MessageDrivenBean”, but this clearly does not make things any clearer.