Content

Directory Layout for Generated Output

In order to ensure a strict separation between generated and hand-written code and resources JEAF Generator is working with the following directories / output slots:

• src-gen
  This slot contains all generated Java classes. Every time JEAF Generator is executed all files in this directory will be at first deleted and then written again. Files in this directory must not be edited manually.
  

• src
  This slot contains all the classes that are intended to be edited manually. In case that a class does not exist in this directory then it will be written also into this directory. But JEAF Generator will never overwrite or edit any existing classes here.

  This is the slot where classes that contain any kind of business logic will be located. Usually this slot will point to your standard source code location.
  

• res-gen
  This slot contains all the generated resource files. All file in the directory and all of its sub directories will be overwritten every time when JEAF Generator will be executed. Files in this directory must not be edited manually.
  

• res
  This slot contains all the resources that are intended to be edited manually. In case that a resource does not exist in this directory then it will be written also into this directory. But JEAF Generator will never overwrite or edit any existing files here.
  

  Usually this slot will point to your standard resource location.
  

Of course it’s possible to configure a concrete directory for each of these output slots according to your project settings.

Failure Handling

JEAF Generator is supposed to work as fault tolerant as possible. When ever possible we try to avoid that the whole code generation process is aborted. In general JEAF Generator distinguishes between errors and warnings.

Both of them will be listed at the end of the generator output as a summary. So to get an overview it’s not required to check the complete log. When JEAF Generator detects a warning for a specific model element it tries to point out the exact element that caused the problem as well as an description of the identified issue. The same is done for errors. However in case of a warning code generation for the model element is still possible whereas this is not the case when an error is found. In this case the model element will be ignored and JEAF Generator will try to process the next element of the UML model.

Final Modifier for Attributes

JEAF Generator makes us of the so called builder pattern for Service Objects and POJOs. In case that attributes in the UML model are marked to be readonly, then these attributes can only be set using the builder but not directly using methods on the generated class itself.

Transient Modifier for attributes / roles

Using stereotype «Transient» it is possible to add keyword transient to generated code.

Usage of Java Collection Types

When modelling an association between classes then inside the UML model already its multiplicity will be defined. If the multiplicity is 0..* or 1..* then in the generated code some kind of Java Collection class is expected to be generated. As there are many types of Collection classes the table below will explain how the information from the model will be used the find the best matching Java Collection type.

The screenshot below show an example of an 0..* association where attributes for Java Collections are defined. According to the table above class java.util.Set will be used in the generated code.

Access Methods for Attributes and Associations

For classes with stereotypes «POJO», «ServiceObject», «DomainObject», «PersistentObject» and «QueryObject» it is not required to define access methods for attributes or associations explicitly in the UML model. JEAF Generator will generate them by default. For attributes there will be set and get methods. In case of associations depending on the multiplicity of the association ends there either will be get and set methods (0..1 or 1) or add, set, get and remove methods (1..* or 0..*).

• Attribute (e.g. name)

  • String getName( )

  • void setName(String pName)

• 0..1 or 1 Association (e.g. owner)

  • Person getOwner()

  • void setOwner(Person pOwner)

  • unsetOwner()

• 0..* or 1..* Association (e.g. bookings)

  • Set<Booking> getBookings()

  • void setBookings(Set<Booking> pBookings)

  • void addToBookings(Booking pBooking)

  • void addToBookings(Collection<Booking> pBookings)

  • void removeFromBookings(Booking pBooking)

  • void clearBookings()

Handling of Associations

UML supports a wide variety of associations between classes (associations, aggregation, directed associations and composition). All of them have a little different semantics. However when it comes to their representation in the Java code then they are all the same.

Bidirectional and Directed Associations

It is also important to know that there is a big difference between directed and bidirectional associations. From the model perspective the difference seems to be just a detail but when it comes to the generated code it has a big impact:

• Bidirectional Associations
  If a association is modeled to be bidirectional then the generated code will ensure the consistency of that association in both directions.
  Example:

  • Class A has a bidirectional many-to-many association with class B. If we now add an object of class B to A then the generated code will ensure that the association form B to A is also set accordingly.

• Directed Associations
  In case of directed associations the references are only maintained into one direction as the association is not bidirectional.

Java Bean Validation (JSR-380)

As described in Java Bean Validation JEAF and JEAF Generator also support Java Bean Validation. To make use of it operations, properties and parameters can be tagged using the matching stereotypes as described in Java Bean Validation. JEAF Generator will use this information and will generated the appropriate annotation.