Skip to content
BluAge Documentation

Views and Component

This chapter describes a detailed view of all elements used for modeling Views, Components or Shell.

Rich User Interface diagrams

Rich UI Diagram uses a custom Activity diagram to represent the UI. This diagram comes with a tool palette containing all basic widgets.


As HTML usually displays HTML in a flow layout, Rich UI diagrams are generated using two concepts: containment and order. This implies that all elements are either contained or have an order.


Note: The tagged value “order” is not required. If no order is provided, it will be generated in the UML creation order.

Shell, View or Component modeling

The UI modeling starts by defining a Shell (template page of the application) and a set of Views/Components.

Here is a generic composition:

  • A Shell
  • Views and Components containing.
    • Controls and components
    • Event Action definitions
    • Process Operation factorizes code into service or a reusable

      operation in a View or a Component.

The Shell

The shell represents the view which will contain all other views of the application. It must be unique within the entire model.

Creating the shell is just like creating a view, except that the stereotype to be applied is <<Shell>> instead of <<View>>.


The Shell is composed of presentation elements and one composition. A Composition defines parts which are redefined by views. This is done by creating a Structured Activity stereotyped <<Panel>> with the property "type=composition".

Application Exception

In order to catch exceptions on UI client model an Activity stereotyped <<UiException>> name and parameter are fixed and not generated. However the operation will always have one parameter “error” typed “any”. This Activity can only modeled once and must be placed directly under the package stereotyped <<PK_VIEW>>. This process supports service injection. However these services must have a global scope.

Component and View

Components are reusable UI parts, intended to be shared by the views. Views are UI parts, designed to be the user interface of a complete application use case; views are built using components and controls.


Components and views are very close in terms of modeling. What can be done for a component, can also be done for a view. The conceptual differences are a view can be reached via an URL or a navigation as a Component must be contained in a View. From a modeling point the view must always start with Panel/type=composition and the Component can start with any element. As a general rule both views and components must be contained in a use case.


Component usage

When referencing a Component in a View the stereotype <<ComponentLayout>> must be applied as it contains additional information such as “order”.


Rich UI modeling has 2 main category of bindings:

  • Static value bindings
  • Domain model bindings
    • Simple binding
    • List binding

The stereotypes and tagged values are organized in hierarchy. By default all widgets stereotypes are inherited from <<UiBinding>> or <<UiBindingList>>. UiBinding binds single elements such as TextBox, Label, CheckBox, etc. UiBindingList is used for Data Grid, Select (drop down), Repeater, etc.

Domain model bindings always specify instances defined in the component (View, Shell or Component) to the widget. The component’s instance can be an Activity owned Property or a Parameter. I.e. see Figure 30 Instances in Data Grid/Repeater.

UiElement – static bindings

UiElement contains the list of basic properties. These properties are accessible on any widget and cannot be bound on instances.

<<UiElement>> tagged value Scope Description
tabIndex All The tab order is the order in which a user moves focus from one control to another by pressing the TAB key. Setting a value of -1 will prevent the control from obtaining a focus.
order All Layout order, determine in which order the element are rendered.
text All Text property of the element.
styleClassName All Sets the CSS style class used by a control.
causeValidation Panel Sets a value indicating if the validation will be performed on any element that requires validation when it receives focus.
defaultValue Form control (TextBox, Select, Radio Button, CheckBox, etc.) Sets the default value of a control.
disabled Form control Disables a widget.
visibility All Renders or not a widget.
headerText Widget connected to a Data Grid Defines the header column. The widget needs to be a DataGrid.
styleCSS All Style CSS.
elementWidth All Widget width.

Table UiElement tagged values

UiBinding – data binding

UiBinding is used for simple controls or single value controls such as TextBox, Label, single CheckBox, etc.

<<UiBinding>> tagged values Type Description
colProperty UML:TypedElement Name of the object property to which the element is bound.
instance UML:TypedElement Name of the instance to which the element is bound.
visibleProperty UML:TypedElement Defines the visibility state of the current component.
disabledProperty UML:TypedElement Defines the disabled state of the current component.
nestedProperty String Describes the associations path "." separated to the object containing the property to bind.
instanceDisabledProperty UML:TypedElement Name of the instance to which the enable state is bound.
nestedPropertyDisabledProperty String Describes the associations path "." separated to the object containing the disabled property to bind.
instanceVisibleProperty UML:TypedElement Name of the instance to which the visibility state is bound.
nestedPropertyVisibleProperty String Describes the associations path "." separated to the object containing the visible property to bind.

Table UiBinding tagged values

UiBindingList – Data binding

UiBindingList is used for list type controls such as DataGrid, Select, Check Box, Radio Buttons, etc.

<<UiBindingList>> tagged values Scope Description
value Select, Radio Button, Check Box Value bound to a list control (DropDown, CheckBox, RadioButton)
key Select, Radio Button, Check Box Identifies the label to display in a list element (DropDown, CheckBox, RadioButton)
selectedInstance Deprecated? Instance of the selected object from a control list.
listInstance Select, Radio Button, Check Box, Repeater, DataGrid Instance or property representing the list.
values Select, Radio Button, Check Box

List of allowed values, must be written in the specific format : <VALUE1>TAB<KEY1>/<VALUE2>TAB<KEY2>

Note: the property “values” is only available for Check Box, Radio Button, Select and Multi Select.

instanceSelectedInstance Deprecated? Base instance to specify the selected instance property.
nestedPropertySelectedInstance Deprecated? Nested property for the selectedInstance property.
instanceSelection Deprecated? Base instance to define the selection property.
instanceListInstance Deprecated? Base instance to define the listInstance property.
nestedPropertyListInstance Select, Radio Button, Check Box, Repeater, DataGrid Describes the associations path "." separated to the object containing access to the listInstance property.
nestedPropertySelection Deprecated? Nested binding to access the selection property.

Table <<UiBindingList>> tagged values

Specific binding rules: Grid and Repeater

When an element is connected to a Data Grid or contained within a Repeater, the instance should not be specified as it will be taken from the iterator value. In case the instance is specified it will override the iterator value. As shown below Figure 30 Instances in Data Grid/Repeater in green the instance is the Data Grid iterator value and in orange it’s an instance passed as a Parameter to the component.



Out of the box Widgets

Below is a complete list of all available widgets without any customization.

Widgets with binding capacity

Widgets Usage context Sample

List binding with object selection.

Note: In that case the property “value” is not specified.

List binding with primitive value.

List binding with static values

Note: In this case the widget “dpdVehicule” “colProperty’s” must be type=List as the widget allows multi selection.

List binding

Note: Inside a Repeater or a DataGrid, widget do not need to specify an instance unless it points to an instance outside of the repeated value.

Standard binding
Standard binding
Standard binding

Tableau 14 Widgets list with binding


TextBox are used to represent user input. They can be typed to accept different kind of inputs. Check browser capability to see if the type of inputs is supported.

Type Description
text Standard text input.
password User typed text is replace by *.
submit Button submitting the form.
reset Button resetting the form input values to their original values.
radio Displays a “radio” button.
checkbox Displays a “checkbox”.
color User input displays a color. When user clicks it will open a color picker.
date User input change to a date picker.
datetime-local User input change to a date/time picker.
email Will display a keyboard mail oriented on some device.
month Displays a month picker.
number Input will only allow number values.
search Text input, it will apply different styles depending on the browser.
tel Text input displays telephone keyboard depending on devices.
time Time picker.
url Text input check for a valid URL.
week Displays week picker.

Table TextBox types


Panels have 2 roles: containment and navigation (see chapter 5.8.3.) In its containment role it allows to define a “form” (in an HTML way), link or just simple panel. Panels also support bindings.

Panel type Sample

Table Panels

Data Grid

Data Grids display data in a grid. By default the grid support basic operations, more advanced operations such as filtering, order or line selection have to be done at the project level by either obtaining a third party library or by designing a component.


From a modeling perspective the DataGrid comes in two parts. The first part defines the grid’s own id and list instance. The second part represents the columns. The columns need to be connected to the grid definition using Object Flow as shown below.

If a column needs more than one component it needs to be contained in a <<DataColumn>>.

Form Validation

The chapter below describes the validation from a UI, data and behavior point of view.

UI behavior

In order to perform validation all widgets must be contained in a panel type form. Each form control must be contained in a panel with causeValidation enabled. From a CSS style perspective, we respect Bootstrap approach, which implies - when the container has the CSS “has-errors” - all children must behave accordingly. The validation is fired when form control is in a dirty state. Validation messages are displayed using <<Message>>/forId = [the form control].




Data validation

Rich UI supports 4 types of validation: min, max, pattern and required.

Type validation Description
valMin Minimum value, applies on text length
valMax Maximum value, applies on text length
valRequired True/False, specifies if the form control is required.
valPattern Regular expression.
valMessage Displayed message for the validation.

Tableau 17 Type of validation

Behavior validation


The validation behavior consists of enabling a control on success or setting up a condition in an event. In the sample below “appForm” is the form containing form controls.


In order to test the validity of a form in an event the “Form” control must be a property of the activity.

Navigation is represented in a drill down approach. The application is broken into views and each view can imbricate a set of views. Breaking up the application in sub views allows navigation and the definition of modules.

Modules are autonomous functional unit and, from a packaging perspective, a module is bundled as a single file. Furthermore, those modules are loaded asynchronously.


In the model, navigations are defined with composition panels (a Structured Activity Node with <<Panel/type=composition>>). The shell must contain one composition panel, and the views must always start with a panel composition and may contain another panel composition in case they define another level of navigation.

Note: Modules are defined by Use Cases and sub compositions. It is a requirement that all sub navigation views are contained within the same Use Case.

In the example below we will obtain the following URL:

We use the stereotype <<panel>>/type=composition to define modules and navigation throughout the application.



The Shell is the starting point for the navigation and it must contain a panel composition. This panel name is used in the view. It is possible to define default views for navigation by applying the stereotype <<START_VIEW>>.

Each navigation URL may contain a set of parameters. These parameters can only be primitive values and are defined on views as activity input parameters.

The example below will produce the following URL:


Widgets handling

This chapter focuses on how to access the widgets in Typescript. Widgets can be access with their properties bound to data in the Typescript class component or they can be accessed directly in the component class.

In order to access the widget in Typescript, the widget must be modeled in the activity as an Activity Node and as a property of the Activity. The property must be typed, Object being the default type.

Views47Example on “appForm”:




In Rich UI, the view containing the login information (user & password) needs to be stereotyped <<LOGIN_PAGE>>. This allows the system to redirect to this page in case of authorization or authentication failure.

Roles definition & usages

Roles are represented by Actors and they must be contained in a package stereotyped <<PK_ROLE>>. These Actors can inherit from another Actor. The less secure actor is the most general. See the example below:



By default all REST end points are unsecured. Authorization is applied to Packages, Interfaces, and Operation by connecting an Actor with a dependency. Connecting Operations will override Interfaces and Interfaces will override Packages. Also when connecting an Actor to a package, all elements and sub packages contained will use that Actor/role.

Specific components or directive

Custom components or directives are supported by extending existing stereotypes from the Rich UI profile. Each “custom” stereotype must have “toTag” and each tagged value must have “to” stereotypes applied.


Note: All stereotype must be created inside a Profile Package.

Stereotypes Meta UML (applied to)
Button [ObjectStructuredActivityNode]
CheckBox [ObjectStructuredActivityNode]
ComponentLayout [CallBehaviorAction, ObjectNode]
DataColumn [ObjectStructuredActivityNode]
DataGrid [CallBehaviorAction, ObjectStructuredActivityNode]
DropDown [ObjectStructuredActivityNode]
Label [ObjectNode]
MultiSelect [ObjectStructuredActivityNode]
Panel [CallBehaviorAction, ObjectStructuredActivityNode]
Password [ObjectNode]
PictureBox [ObjectNode]
RadioButton [ObjectStructuredActivityNode]
Repeater [CallBehaviorAction, ObjectStructuredActivityNode]
TextBox [ObjectNode]
UiElement [ObjectNode]

Table Extensible stereotypes

Stereotype <<toTag>> for project components

The stereotype <<toTag>> is used to specify a custom component or a directive. The tagged value contains the component tag name, path and module name.

toTag tagged values Description
  • If true the generated tag will close itself i.e. <… />

  • If false the generated tag will have a closing tag i.e. <..> … </..>

tagImplementation Name of the component implementation. In Angular we use the module name.
tagName Name of the tag i.e. “button-component”. This tag name will be used in the generated HTML i.e. <button-component …>

Path pointing to the tag implementation.

Note: It must be an absolute path and does not start or end with a “/” i.e. “custom/button.component”

Note: For an external library the value see

Table <<toTag>> tagged values

Stereotype <<toTag>> for external libraries

External libraries can be used in Rich UI with the following constraint:

  • They must have a standard initialization.

  • They must be installable via Node Package Manager (NPM.)


The library must be referenced in the workflow dependencies and in the model as a Package with the stereotype <<elementsLibrary>> applied. The package name must be identical to the name of the library. Finally, this package will contain all stereotypes referencing the library components.

Stereotype <<to>>

The stereotype <<to>> is used to specify the tag properties and must be applied on each tagged values.

<<to>> tagged values Description

This tagged value manages the generation of the tagged value “to”. This allows the definition of static attributes or behavior in the generated tag.

  • If set to “true”, the property is generated when the custom property receives a value.

  • If set to “false”the content of “to” is always generated. .


Represents the generated property. It will always be generated as follows: value=”…”

Note: When using Angular you will need to respect the sugar template syntax see

Table <<to>> tagged values

In the example below:

  • “myDirective” has isHtmlProperty=false and will always generate.

  • “anotherDirective” has isHtmlProperty=false and will always generate.

  • “autoFocus” has isHtmlProperty=true and will generate when “autoFocus” receive a value.


Extending stereotype

A basic tag “BaseTag” which by itself does not do anything can be use when creating a Rich UI custom stereotype.

To extend a specific tag you need specific knowledge on the generated tag attributes. For example TextBox generates an “input” tag with the attribute “type”. Extending “TextBox” will change the tag name but all previous generated attributes will remain.