Parent Project
Overview
How-to
- Introduction
- Entities
- Relationships
- Services
- Value Objects
- Enumerations
- Queries
- Exceptions
- Security
- Tips & Tricks
Project Documentation
With entities we mean what is usually implemented using Entity Beans or Hibernate POJOs (i.e. a persistent entity like a Company or Person for example); in the Spring cartridge you will not need to worry about the underlying persistence technology, but you will probably want to know that Hibernate POJOs will be generated for the entities you model.
In order to successfully generate a single entity it is sufficient to simply model a single class and assign it the <<Entity>> stereotype, this stereotype tells the Spring cartridge to treat this class as an entity.
Let's start by modeling a package org.andromda.test and putting a class inside that package, give that class the name Car. Now make sure that entity has the <<Entity>> stereotype, it depends on your UML tool how you need to do that exactly.
You can now try to generate code from your model and take a look at what is generated. If you don't know how to generate code using AndroMDA then head on over to the getting started guide (especially the section explaining how to setup your first AndroMDA project).
If everything went well, all code related to this class will have been generated into the /core/target/src project subdirectory, no manual implementation will need to be added at this point.
The class we have modeled does not have any properties, however, we notice it having an 'id' attribute, where is it coming from ? Well, by default AndroMDA configures the Spring cartridge to generate an identifier when none have been modeled by the user, this identifier is called id, and it is of type datatype::Long. It is possible to override these settings in the namespace properties for Maven or the namespace properties for Ant. Click here if you want to know more about the default namespace properties you can set.
You may also model operations on an entity, this will generate them as methods in the resulting Java class. Operations that are classifier scoped (static in Java) will go into the corresponding DAO, in UML diagrams those operations are underlined when shown.
So far we have modeled some very basic stuff, let's add a bit of complexity in the next sections.
In case you want an entity's attribute to be unique for all instances of that entity's type you should assign the <<Unique>> stereotype to it.
It's possible to configure the multiplicity of an entity's attribute, by setting it to [0..1] an attribute is not required and is allowed to be set to null; setting the multiplicity to a value greater than 0 means the attribute is required.
Please note that some UML tools have a default multiplicity value for attributes when not specified by the user, these default values may differ from tool to tool.
If you want an operation to have a parameter which is allowed to be null then simply assign the <<Nullable>> stereotype to that parameter. By default service and DAO operations throw an exception when a null argument has been passed.
It is possible to globally disable checking for null arguments, so you will never need to specify the <<Nullable>> stereotype; to do so just specify the parameterRequiredCheck namespace property to have the false value.
In the next section we'll learn about entity relationships, click here to continue.