Services

A common strategy to shield the presentation tier from the persistence tier is to model the services in between, they will be used to implement the business logic in the application tier. The technology behind is of little interest to the developer (that's one of the good points of MDA right!), but it's good to know Spring POJOs are being used (optionally wrapped with EJBs: more specifically EJB Session Beans).

In order to model such services you would just create another class, but this time you will give this class the <<Service>> stereotype.

Generally speaking it is sufficient to only model operations in these services, they represent the operations that can be called remotely, consider these operations the API of your application's back-end.

Notice how we have modeled dependencies from the service to the entities, this will render accessors to the DAOs of both entities in the service. You will need to draw such dependencies when you need access to the persistent storage of entities. This is similar to the dependencies drawn between entities, as we have seen before.

howto/org/andromda/test/3/uml.gif

  • 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

There are a few other things you can do with these services, these features will be presented in the sections ahead.

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.

Next

In the next section we'll learn about value-objects, click here to continue.