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
and putting a class
inside that package, give that class the name
. Now make sure that entity
has the <<Entity>> stereotype, it depends on your UML tool how you need to do
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
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
, and it is of type
. It is possible to override these
settings in the
properties for Maven or the
namespace properties for Ant. Click
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 (
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
an attribute is not required and is allowed to be set to
; setting the multiplicity to a value greater than
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
assign the <<Nullable>> stereotype to that parameter. By default service and DAO
operations throw an exception when a
argument has been passed.
It is possible to globally disable checking for
arguments, so you will never
need to specify the <<Nullable>> stereotype; to do so just specify the
namespace property to have the
In the next section we'll learn about entity relationships, click here to continue.