Page Comparison

3.1

Documentation

all

It’s strongly recommended to add documentation to all classes, interfaces, attributes, associations, operations, parameters etc. When ever possible the comment should explain what is the semantics of an model element. To ensure high quality of comments also meaningful examples are very helpful.

Please be aware that JEAF Generator will use to comments from the UML model also for the generated code. Due to that documentation should also be compatible with Javadoc guidelines.

3.2

Primitive Types

Properties

We strongly recommend to either only use primitive types or only Java wrapper types. There are pro’s and con’s for both approaches. So most important is that your model is consistent

3.3

Primitive Types

Operations of business objects

We strongly recommend to not use primitive types nor its Wrappers as parameters / return types for business operations. Instead whenever possible real objects that represent the business should be used.

3.4

Primitive Types

Service operations

We strongly recommend to not use primitive types nor its Wrappers as parameters / return types for service operations. Instead whenever possible real objects that represent the business should be used.

3.5

Enumerations

Properties

We strongly recommend to use enumerations instead of primitive types / wrappers in case that you have lists of possible values.

3.6

Exceptions

We recommend to make use of JEAF’s Exception Handling concept. It distinguishes between technical and business exceptions. They can be easily modeled using stereotypes «ApplicationException» and «SystemException».

Please also refer to How to model Exceptions

3.7

Deprecations

Any model element

Over time software changes and some functionality may be outdated. It’s still there but it should not be used any longer and it will be removed sooner or later. In this case you should make use of so called deprecations.

Deprecations are markers that indicate that a specific model element should not be used any longer. To do so, you just have to apply the stereotype «Deprecated» to the model element. This can be anything from a whole class or interface to an parameter of an operation.

JEAF Generator will also mark the generated code as deprecated.

Remark:

• Please be aware that in MagicDraw UML there is an build in stereotype «deprecated» and stereotype «Deprecated» one of the from JEAF Meta Model. Even though re JEAF Generator supports both of them we recommend to use the stereotype from JEAF Meta Model JEAF Generator supports both of them.

3.8

Source Code Management

Any

Even though source code is generated, it is best practice that it is managed by a version control system like Git, SVN etc.

If you do so, you have the following benefits:

• Developers are able to identify and detect changes in the generated source as there are diffs to the previous version

• Analyzing of the behavior of the existing application is way simpler as also the generated code is always present.

3.9

Code Generation as part of build

Any

It's strongly recommended that code generation is always a mandatory part of the build process. This way manual changes to the generated code can be prevented very effectively.

To support this as much as possible JEAF Generator is provided as Maven Plugin for a seamless integration (Integrate JEAF Generator into Maven Build ).