How to model Components
Components
Components are, according to JEAF Architecture, self-contained, reusable pieces of software. They provide their functionality as one or more services.
The diagram above shows an example model for a component. As you can see there component Accounting implements the services AccountingService and AccountingBasicDataService. In addition the component also depends on services SchufaService of component SCHUFA and SwiftAccountingService of component SWIFTAccounting.
When modelling components it is also very important that components are marked with stereotype «JEAFComponent». In section “Required / Provided Interfaces” of the component specification the services shown in the diagram above need to defined.
Also tagged values of the component have to be set, at least if you do not want to work with the defined default values.
It is important to define all these information as part of your UML model as JEAF Generator will make use of the when generating code for components.
For further information please also refer to:
Properties for Components
As you can see from the diagram directly above it is also possible to define properties for components. When using JEAF and JEAF Generator these properties will be treated as configuration parameters for the component (aka Dynamic Properties). As for any other property also here it is possible to define a default value.
Currently the following types can be used for component properties:
Java Primitive Types or the corresponding wrappers
java.lang.Stringjava.lang.Classjava.utilCalendarjava.util.Locale
For further information about component configuration and dynamic properties please refer to: Configuration Component Configuration
Usage of UML Ports
UML standard also defines so called ports. Ports are access points for the functionality that is provided by a component. A port, like a component, can provide one or more services.
As you can see from the diagram above JEAF and JEAF Generator also support ports. The big benefit of ports in combination with JEAF arises from the fact, that in this case a shared base class for the port will be generated. This class will be the base class for all service implementations. This offers the opportunity to move common functionality of all services to a shared location.
When working with ports then a class for the port has to be defined in the UML model. In the example below this would be InternalServicePort. We propose to put the port class into the same package as the component.
Usage of persistence units
In case that a component has persistent objects then, due to requirements from Java Persistence API and how it is integrated with JEAF, it is required that the component defines the persistence unit to which it belongs to. To do so just a regular dependency from the component to its persistence unit is required. JEAF and JEAF Generator will take care about the rest.
For further information please also refer to: