Location: Welcome > RAL language > RAL concrete syntax

RAL concrete syntax


In this section we present the EBNF notation of RAL and its detailed description.


Expression := IS PersonConstraint

| HAS GroupResourceType GroupResourceConstraint

| SHARES Amount GroupResourceType WITH PersonConstraint

| HAS CAPABILITY CapabilityConstraint

| IS ASSIGNMENT IN ACTIVITY activityName

| RelationshipExpression

| CompoundExpression


RelationshipExpression := ReportExpression

| DelegateExpression


ReportExpression := REPORTS TO PositionConstraint Depth

| IS Depth REPORTED BY PositionConstraint


DelegateExpression := CAN DELEGATE WORK TO PositionConstraint

| CAN HAVE WORK DELEGATED BY PositionConstraint


CompoundExpression := NOT (Expression)

| (Expression) OR (Expression)

| (Expression) AND (Expression)

| (Expression) AND IF POSSIBLE (Expression)


PersonConstraint := personName

| PERSON IN DATA FIELD dataObject.fieldName

| PERSON WHO DID ACTIVITY activityName HistoryExpression

| PERSON WHO HAS PARTICIPATED IN BPHistoryExpression


GroupResourceConstraint := groupResourceName

| IN DATA FIELD dataObject.fieldName


CapabilityConstraint := capabilityName

| CapabilityRestriction


PositionConstraint := POSITION name_position

| POSITION OF PersonConstraint


HistoryExpression := IN CURRENT INSTANCE

| IN ANY INSTANCE

| IN ANOTHER INSTANCE

| FROM startDate TO endDate


BPHistoryExpression := CURRENT PROCESS INSTANCE

| ANY PROCESS INSTANCE

| ANOTHER PROCESS INSTANCE

| A PROCESS INSTANCE BETWEEN startDate AND endDate


Amount := SOME

| ALL


GroupResourceType := POSITION

| ROLE

| UNIT


Depth := DIRECTLY

| λ


RAL allows expressing the following assignments:

  • Individual resource assignments. RAL allows expressing that an activity must be performed by someone indicated in a PersonConstraint: (i) a specific person; (ii) the person who did another activity; or (iii) the person indicated in a data field. For the last option, information about the process instance in which the activity has been executed must be provided, specifically:
    • The same process instance currently running.
    • Any instance of the process (including the ongoing one). 
    • Any previous process instance (excluding the ongoing one). 
    • Those process instances in which the activity has been completed between two given dates (regardless of whether the process instance itself is over or not).
  • Process-oriented history-aware assignments. The same history-aware assignments previously defined can be specified at process level, that is, without detailing a concrete activity.

  • Assignments based on group resource constraints. It allows assigning an activity to a given position, role or organizational unit, or to one read from a field of a data object.

  • Assignments based on commonalties. Expression SHARES Amount GroupResourceType WITH PersonConstraint is used to assign persons that share some or all position(s), role(s) or organizational unit(s) with the person indicated in a PersonConstraint.

  • Assignments based on personal capabilities. Constraints based on the capabilities of individual resources, such as years of experience or reputation can be expressed with RAL. These constraints may consist of the existence of certain capability or of the holding of certain condition on the value of a capability.

  • Equivalent assignments. RAL uses expression IS ASSIGNMENT IN ACTIVITY activityName to indicate that an activity has the same RAL expression as another activity. This avoids having to re-write several times the same assignment, as the same time as it helps saving time and effort and prevents making writing mistakes.

  • Assignments based on hierarchical relationships. According to the relationships between positions of an organizational model described by Russell et al., a position can report work to one position and can delegate work to one or more positions. Using these relationships we can construct contraints such as ``activity Fill Travel Authorization must be performed by someone that reports to the Project Coordinator''.

  • Compound assignments. Combination and negation of the aforementioned expressions are allowed. Furthermore, the conditional expression AND IF POSSIBLE has been included to let the modeller express preferences/priorities. For instance, by stating that, if possible, an activity has to be carried out by certain role, we are meaning that that is the first assignment we have to try when actually allocating the activity to an individual resource (at runtime). In case preferences are not fulfilled, they are just ignored.