Skip to content
BluAge Documentation


This page explains how to configure the main logic of your RichUI application.

Minimum requirements

This section describes the minimum package requirement for any Rich UI model. Each project must have one <<PK_TARGET>> containing a <<PK_VIEW>> as shown below :


Note: Any element outside of PK_TARGET is ignored by the generator.

Each View, Component or Shell must be contained in a package stereotyped <<PK_VIEW>> and in a UseCase. See below in blue package <<PK_VIEW>> and in green the UseCase containing views.


The application may contain only one Shell and multiple Views and Components. Views, Shell or Components must have stereotypes <<View>>, <<Shell>> and <<Component>>. Views must start with a <<Panel>> type=composition and the Shell must at least contain one <<Panel>> type=composition.

Logic & Behavior processes

This chapter covers a set of basic rules for modeling client logic. There are 3 types of process to represent application logic: Service, Event and View/Component Functions.

Note: In Angular generation, services are injected and their instantiation is managed using provider.

Services and events processes

Services are defined with interfaces directly containing activity diagram stereotyped <<ProcessOperation>> which represents the code logic. Services can also own properties like classes.


Events are Activities defined within a View/Component or Shell stereotyped <<EventAction>>.


Process Operation are Activities stereotyped <<ProcessOperation>>. They can be defined within a View, Component or Shell:


Service scope

Scopes define how to instantiate services. These services can be instantiated for a View/Component or the entire Application. In order to change the scope we apply a stereotype on Interfaces as follow:

Stereotype Description
None Service is instantiated at the component level.
application Service is instantiated at the application level.
static Service is not instantiated. This case is useful for third party services.

Table Service scope's stereotypes

View, Component or Shell Events

Rich UI events are represented as Activities. The link with the widget is done by creating a Call Behavior Action on the View/Component/Shell diagram. The Call Behavior Action's name must equal the widget name. Events can be broken in 2 types: component life cycle and component behavior. In order to model an event you will need to create an activity and the first parameter will define the type of event. Finally, model the logic as standard Activity Diagram.

Event Type Category Description
EventOnLoad Life cycle Fires before the component is loading. Do not need to be added as a Call Behavior Action.
EventConstructor Life cycle Fires when the component is instantiated. Do not need to be added as a Call Behavior Action.
EventActivated Behavior Fires when component receive focus.
EventLeave Behavior Fires when component lose focus.
EventChange Behavior Fires when the view model of the component has changed.
EventClick Behavior Fires when the component is clicked.
EventDoubleClick Behavior Fires when the component is double clicked.
EventKeyDown Behavior Fires when the component has focus and a key is down.
EventKeyPress Behavior Fires when the component has focus and a key is pressed.
EventKeyUp Behavior Fires when the component has focus and a key is up.
EventRowClick* Behavior Fires when a Data Grid row is clicked.
EventRowDoubleClick* Behavior Fires when a Data Grid row is double clicked.
EventRowKeyDown* Behavior Fires when a Data Grid row has focus and a key is down.
EventRowKeyPress* Behavior Fires when a Data Grid row has focus and a key is pressed.
EventRowKeyUp* Behavior Fires when a Data Grid row has focus and a key is up.

Table Component Events



Note: (*) Will be present in a future release of Rich UI.

REST End points

REST interfaces or end points are modeled under <<PK_SERVICE>> package. They are defined by interfaces stereotyped <<JsonController>> and operations stereotyped <<JsonService>> with <<process>>. By default operation with input parameter are done in HTTP POST and operation with no input are in HTTP GET. Only one input and output parameter is permitted.



By default, it is necessary to add <<@Transaction>> stereotype to a model operation so it is generated as transactional. A workflow option exists, named autoTransactionManagement. If set, the above mentioned <<JsonService>> stereotype will imply transactionality of the backend method. This enables the usual use case where one would like all the endpoint methods to be transactional.

It is still possible to use the <<@Transaction>> stereotype in order to setup isolation level, for instance, through dedicated tagged values.

REST Mappings

By default mappings are calculated from the package stereotyped <<PK_SERVICE>> and concatenating the workflow variable "restPath". However the mapping can be overridden when using the tagged value "mapping" on stereotype <<JsonController>>. If the operation is not stereotyped <<process>> it won't be generated and if the interface does not contains any operation stereotyped <<process>>, the Interface is not generated.


REST Parameters

Input parameters consist of multiple primitive objects and only one complex object (a class). While primitive parameters are interpreted as path variable, the complex object is interpreted as request body. The return parameter can be of any type. If the an operation has a complex objet it will generate an HTTP POST operation otherwise it will be HTTP GET.


Process Modeling

Activity diagram are used to represent code logic. They must start with an "Initial Node" and always end with a "Final Node".



Parameters are defined on Activity and must be typed. We support two types of direction "in" and "return". Keep in mind return type are not required.

General rule for EventAction modeling and ProcessOperation:

  • For Process Operations no parameter are required.

  • For Events at least one type is required and it must be typed with a class <<TypeEvent>>.


Note: <<EventType>> classes are coming from the Rich UI profile and they are not customizable.

Call Action

Each Call Action Node can only have one incoming Control Flow and one outgoing Control Flow.


Note: Input Pin and Output Pin must have a parameter synchronized as the graphical representation of Pins in diagram do not represent the order of parameters. If a Pin has no Synch Element (linking the Parameter) it might result in not generating the call operation correctly.

Call Operation Action

Code will generate differently depending on the operation stereotypes or the type of container.

Types/Stereotypes Generation Specifications/Notes

Class Operations


If the class operation bears one of these stereotype, it will generate a property. Otherwise it will generate an operation call. Call Operation must be connected to a Central Buffer Node representing the instance using an incoming Object Flow.

Operation call


The service instance is automatically generated.

Table Call Behavior Action

Call Behavior Action

Call Behavior Action represents either a simple navigation or a call to an operation.

Stereotypes Generation Specifications/Notes
ProcessOperation Operation call The service instance is automatically generated.
View Navigation call This navigation is always relative. For more advanced navigation, you will need to model a specific API call.

Table Call Behavior Action

Opaque Action

Opaque Actions generates their body content as is unless the language is set to "bags" - see below.

Central Buffer Node

Central Buffer Node are used to define instances. If an operation call is not a service (represented by an Interface), the Call Operation Action must have an incoming Object Flow from the Node to the Call Action.


BAGS is a DSL representing code expression. They are modeled in bodies of Opaque Action or in guard as a Literal String Expression with language set to "bags". BAGS manages simple statements such as: assignments, logic expressions and call operation. If an expression is too complex it should be done using standard process modeling or a simple Opaque Action.

As a general rule all instances present in a BAGS must have a representation. For example "a == b", a & b must be represented as a Central Buffer Node or a Parameter.

Note: In BAGS the generator will detect if the instance is a local variable or a class member. It will add "this" automatically.

Assignment Generated Typescript Notes
a = b a = b
a = b + "5" a = b + '5' In java script it transform double quotes into single quote.
a.prop = b a.prop = b
a = b.prop a = b.prop
a.prop = b.prop + c.prop a.prop = b.prop + c.prop Complex assignments
a == b a === b
a != b a !== b
a > b a > b
a < b a < b
a >= b a >= b
a <= b a <= b

"a" must be declared as a Central Buffer Node.

"TypeA" a type must be stereotyped <<constant>>.


"TypeA" must be declared as a nameless Central Buffer Node.

"TypeA" a type must be stereotyped <<constant>>.

Utility function
a = @StringUtils.function(...) a = this.stringUtils.function(...)
Class Model operation call
myVal = @$instance.isFunc() a = instance.isFunc() "instance" needs to be declared as Central Buffer Node or a Property.

Table BAGS Operators & function sample

BAGS Operators support

Below is a list of supported operators:

  • Arithmetic operators are supported except increment and decrement.

  • Relational operators are fully supported.

  • Bitwise operator are not supported.

  • Logical operator are fully supported.

  • Assignment operator support only '='.

BAGS function

In BAGS utility functions must start with "@" followed by the service name. To represent a call operation modeled in a Class the symbols "@$" must be present before the class instance.

Note: In Typescript utility functions will generate the import and the constructor injection. The folder containing utility functions is defined by the workflow variable "bagUtilPath". By default its value is set to "services/". These functions need to be modeled as standard Rich UI Process.

Expansion Region

Expansion Region are used to represent iterations. The type of iteration is determined by the Expansion Region Node type. The iterator is represented by an Expansion Node Variable. The Expansion is treated as a sub diagram it must start with an Initial Node and end with a Final Node.

Type Iteration type

For statement.

Typed array iteration.

Note: Variable type must of the same type as the array/list.





For statement

Number iteration.

Note: Variable type must be a number type.

Boolean While statement

For in statement

Reflection iteration.

Note: The variable type must always be typed "String".

Table Types of Expansion Region Node


Decision & Merge Nodes

Conditions are represented by outgoing Control flows containing a guard coming from a Decision Node. Each outgoing Control Flow from a Decision Node must have an equivalent incoming Control Flow on a Merge Node. If multiple outgoing Control Flow are modeled, they must have a "weight" which will determine the generation order.


Note: Empty conditions are not generated. If a Control Flow is directly connected from a Decision Node to a Merge Node, it will be skipped.