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.