PDF

Entities

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.

  • Auto-generated source that does not need manual editing
  • Auto-generated source that should be edited manually
  • File that is affected by the modifications applied in this section

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.

  • Auto-generated source that does not need manual editing
  • Auto-generated source that should be edited manually
  • File that is affected by the modifications applied in this section

So far we have modeled some very basic stuff, let's add a bit of complexity in the next sections.

Unique Attributes

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.

Attribute Multiplicity

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.

Nullable Parameters

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.

Next

In the next section we'll learn about entity relationships, click here to continue.