Group items tagged

Control is a stereotyped class or object that is used to model flow of control or some coordination in behavior

usually describe some "business logic"

«Entity»

Entity is a stereotyped class or object that represents some information or data, usually but not necessarily persistent.

Features of a class are

Static features are underlined

«Boundary»

«Boundary»

«Control»

«Entity»

«Control»

Interface

An interface is a classifier that declares of a set of coherent public features and obligations

specifies a contract.

Data Type

A data type is a classifier - similar to a class - whose instances are

typical use of data types would be to represent value types

«dataType»

Enumeration

An enumeration is a data type whose values are enumerated in the model as user-defined enumeration literals.

«enumeration».

Multiplicity

Multiplicity allows to specify cardinality (allowed number of instances) of described element

Visibility

UML has the following types of visibility: public package protected private

Package visibility is represented by '~' literal.

Protected visibility is represented by '#' literal.

Private visibility is represented by '-' literal.

@Inject

CDI managed beans. The @EJB annotation is removed and @Inject is used instead

Annotating the boundary (Cart) with the @Named annotation makes the Cart immediately visible for expression language (EL) expressions in JSP and JSF

@Named annotation takes the simple name of the annotated class, puts the first character in lowercase, and exposes it directly to the JSF pages (or JSP). The Cart bean can be accessed directly, without any backed or managed beans, by the JSF pages: <h:commandButton value="Check out!" action="#{cart.checkout}" />

If there is a need for abstraction, the class can be turned into an interface (or abstract class)

local implementation (with CDI events

@Inject Event<String> event;

event.fire("Order proceeded!");

remote implementation:

javax.enterprise.event.Event belongs to the CDI-implementation

class Event can be considered to be a lightweight alternative to the java.beans.PropertyChangeSupport class

@Inject Event<String> event;

event.fire("Order proceeded!");

event can be received by any managed bean and also by EJB beans

provide a method with a single @Observes annotated parameter

@Observes String event

there is no real event, just the payload:

The during attribute in the @Observes annotation allows you to select in which transactional phase the event gets delivered. The default setting is IN_PROGRESS, which causes an immediate event delivery regardless of the transaction outcome. The AFTER_SUCCESS configuration causes the delivery to occur only after successful transaction completion

Although CDI events work only inside a single process (in the default case, CDI is extensible), they are perfectly suitable for decoupling packages from modules

The method checkout() starts a transaction that gets "reused" by the OrderSystem and CustomerNotification session beans

ordering.placeOrder(); notifier.sendNotification();

EJB beans cannot be directly exposed to JSF or JSP without a little help from CDI

What is next after robustness diagrams? Robustness diagrams often act as bridge from use cases to other models.  For example, it is quite common to create sequence diagrams which represent the detailed design logic required to support the use case

Add an entity for each business concept

Add a use case whenever one is included in the scenario

Add a controller for activities that involve several other elements

Add a controller for each business rule

Add a controller to manage the overall process of the scenario being modeled

Add a boundary element for each major user interface element such as a screen or a report.

Services can remain independent

ServiceFacade combines them

If the JPA entities still do not look right, try to apply some JPA tricks like mapping a JPA-entity to several tables, or even map JPA-entities to DB-views, to improve the situation

Rename the classes into some more meaningful. The attribute, class names are in general everything but not fluent

Junit. Purpose: JPA mapping verification

Thinking In Structs Not Objects

12 Tips On JPA Domain Modelling

Execute the "Unit" tests after every change

even better get rid of them

domain objects are

injected managed beans (controls) results in the simplest possible architecture

GraniteDS validation framework provides a set of standard constraints

Constraint Description AssertFalse The annotated element must be false AssertTrue The annotated element must be true DecimalMax The annotated element must be a number whose value must be lower or equal to the specified maximum DecimalMin The annotated element must be a number whose value must be greater or equal to the specified minimum Digits The annotated element must be a number whithin accepted range Future The annotated element must be a date in the future Max The annotated element must be a number whose value must be lower or equal to the specified maximum Min The annotated element must be a number whose value must be greater or equal to the specified minimum NotNull The annotated element must not be null Null The annotated element must be null Past The annotated element must be a date in the past Pattern The annotated String must match the supplied regular expression Size The annotated element size must be between the specified boundaries (included)

must use

Note that the bundle name must always be set to "ValidationMessages".