AL Expression Language

AL Expression Language

Version 1.0, August 27, 2010

Primary Author: Mark H. Linehan

Additional Contributors: Elio Dammaggio, Fabiana Fournier, Fenno (Terry) Heath III, Rick Hull, Anil Nigam, Florian Pinel, Noi Sukaviriya

This document details the AL Expression Language component of Project ArtiFact™. The document supplements the AL 1.0 Tutorial [1]. It is targeted to people who want to understand the language design or apply the AL Expression Language.

The AL expression language is based upon the Object Constraint Language (OCL) of UML, as described in references [2], [3], and [4]. The motivation for basing AL on OCL, rather than a procedural language such as Java, is the collection operations of OCL. These collection operations enable declarative expressions that deal with collections as aggregates, rather than loop-based procedural handling of individual collection elements.

This language is used everywhere in AL where expressions are permitted. AL expressions are stored as strings in the Project ArtiFact XML representation, and are used as examples in papers targeted for academics, and in documentation intended for IT staff. This language is the translation target for SBVR-style business rules that are captured in “Structured English” for review by business people.

There are seven expression types, each associated with a particular AL usage. The following examples assume that 'o' is a local name that refers to an artifact named 'Order'.

1. Guard expressions define the conditions upon which stages are activated. Each guard expression evaluates aspects of the artifacts defined for a particular stage, and produces a Boolean result that indicates whether a stage can execute.
For example, the guard expression “not o.Confirmed” is true if the 'Confirmed' attribute of an 'Order' is false.

2. Milestone expressions define whether stages have completed processing. Each milestone evaluates aspects of the artifacts defined for a particular stage and produces a Boolean result that indicates whether the stage has completed. Each milestone has a name and can be tested as described in section 12.1. The value of the milestone is the result of evaluating the milestone expression.
For example, the milestone named 'Successful Order' might be defined by the expression “o.'Line Items' à forall(Availability)”. The expression tests whether the 'Availability' Boolean of all of the ‘Line Items’ of the ‘Order’ are true.

3. Iteration expressions of "Focus" statements define how a stage executes against all the members of a collection of artifacts or structures.
For example, "Static Focus Order o o.items" means that a stage operates against each member of the collection "o.items".

4. Assignments are used (1) within exit actions to assign attribute status values (e.g. stable,committed) ; and (2) within assignment tasks to assign attribute values based on expression formulae.
For example, "'Login and Set Defaults'.status := AttributeStatus.committed" assigns 'committed' as the status of the 'Login and Set Defaults' stage.
For example "o.taxes = o.'Total Cost' * o.'tax rate'" assigns the product of "o.'Total Cost'" and "o.'tax rate'" to "o.taxes".

5. Derivation expressions are specified in the information model to give the value of an attribute. Derivation expressions are evaluated as soon as any other attributes that they depend upon have assigned values. The status of any derived attribute is derived from the status of the attributes that it is dependent upon: “uninitialized” if any of those attributes is not initialized; "stale" if any of those attributes are "stale"; “stable” if some or all of those attributes are “stable” and any others are “committed”; “committed” if all those attributes are “committed”; and "invalid" if an arithmetic error (e.g. divide by zero) occurs or if a structural rule is violated or if any dependent attribute is "invalid".
For example, the 'Total Cost' attribute of the ‘Line Item’ structure may have a derivation expression “Quantity * 'Price Per Unit'”. The system automatically evaluates this expression, and sets the 'Total Cost' attribute, as soon as values are assigned to both ‘Quantity’ and “Price Per Unit’. The status of 'Total Cost' follows the statuses of the 'Quantity' and 'Price Per Unit' attributes.

6. Structural rules are associated with individual attributes in the information model. They constrain the number or value of the attributes. For example, a structural rule might require that either Address. ‘address line 1’ or Address. ‘address line 2’ must be non-blank. If a structural rule evaluates as false, then the associated attribute(s) have status "invalid".

7. Query expressions are used in query service requests to specify what artifact or structure instances to lookup in the database of artifact instances.
For example, a query using "Order.allInstances().'Line Items' à forall(Availability)" performs a lookup for 'Orders' that meet the criteria that the 'Availability' Boolean is true in all the 'Line Items'.

The term “stage expression” refers collectively to “guard expressions”, “milestone expressions”, "iteration expressions", and “assignments”. The term “attribute expression” refers to either “derivation expressions” or “structural rules”.

The following sections describe each of these major aspects of the AL expression language:

Namespaces
Expression Context for Attribute Expressions
Expression Context for Stage Expressions
Expression Context for Queries
Comments
Collections
Literals
Expression Syntax
Infix and Unary Operators
Date, Time, Timestamp, and Duration Operators
Functions
Collection Operators
Assignments

A final section discusses how the AL expression language supports standard typed first-order predicate logic with identity.

1 Namespaces

Namespaces identify a collection of names of things, where each name must be unique within the namespace. This follows the conventional programming language design.

AL supports four namespace types: "ASC namespaces", "structure namespaces", "event namespaces", and "enumeration namespaces".

1.1 ASC Namespaces

Each Artifact Service Center (ASC) has one namespace containing names for all the "top-level" concepts defined in the ASC. This includes names of:

· artifacts, structures, and enumeration types

· stages

This means that these names must be mutually unique. For example, an ASC cannot have a structure and a stage with identical names.

1.2 Structure Namespaces

Each structure and artifact has a namespace containing:

· names of attributes defined within the structure or artifact

· names of milestones defined for stages associated with an artifact

· names of events associated with an artifact by the ASC

These names may be duplicated across different structures or artifacts, because they have different structure namespaces.

1.3 Event Namespaces

Each service event has zero or more input, output, and fault parameters. Each parameter has a name and a type. Each event has a namespace containing the event parameter names. Typically, the parameter types are structures but they may also be primitive types.

1.4 Enumeration Namespaces

Each enumeration type has a namespace containing all its enumeration constants. These are referenced using "dot" notation. For example:

color.red

2 Expression Context for Attribute Expressions

Attribute expressions (derivation and structural expressions) are associated with specific artifacts or structures. These expressions can reference all attributes that are directly or indirectly accessible from their associated artifacts or structures. The expressions implicitly reference attributes in the structure namespace of the expressions.

Attribute expressions are dependent upon whatever attributes are referenced within the expressions. At runtime, the attribute expressions are evaluated whenever the dependent attributes are set. The runtime context of the attribute expressions is a particular instance of the containing structure and instances of all structures contained in or referenced by the containing structures.

For example, the "total value" attribute of the "Order" artifact might have this derivation rule: "'Line Items'.'Total Cost'àsum()", meaning that "total value" is computed as the sum of the 'Total Cost' attributes of all the 'Line Items' in a specific instance of the "Order" artifact.

3 Expression Context for Stage Expressions

Stage expressions (guards, milestones, iteration expressions, and assignments) execute in the context of specific stages. Various aspects of stages identify the context for stage expressions. These aspects include:

1. Focus Statement

2. Attribute Status and Timestamp

3. Stages

4. Milestones

5. Events and Event Parameters

6. History

7. Service Context

Each of these is described in the following subsections.

3.1 Focus Statement

Each stage may have zero or one "Focus" statement that establishes part of the context for the stage. There are two types of Focus statements: "Static Focus" and "Dynamic Focus". The semantics of each of these is described in the document Focus Statement in GSM Model [2].

Every Focus statement gives a "type" and a corresponding "local name". The "type" establishes part of the context of all stage expressions (guard expressions, milestone expressions, iteration expressions, and assignment expressions) of the stage, and also contributes to the context of any child stages. The "local name" provides an identifier that is used to reference instances of the type.

For example, given a stage defined with:

Static Focus: Order o;

... then expressions of the stage may reference artifact attributes such as "o.Confirmed" and "o.'Line Items'".

If a stage has no Focus statement, then expressions of the stage must use local names defined in parent stages.

Figure 1: Parent and Child Stage Local Names

Stages can be nested, and inner stages can reference the local names associated with parent stages. For example, in Figure 1, stage expressions of stage C can reference all attributes that are directly or indirectly accessible through both local names 'o' and 'i'. At runtime, the stage executes “against” particular instance of the 'Order' and 'Line Item' structures, and the expressions are evaluated against those instances and any inner structures available through ''o' and 'i'.

Child stages may not declare local names that conflict with the local names of parent stages.

3.2 Attribute Status and Timestamp

Every attribute has a status, which may vary among the AttributeStatus enumeration values. The status() function may be used to reference the status of any attribute that is in the context. For example, the status of the 'Customer Name' attribute may be accessed via:

o.'Customer Name'.status()

Every attribute also has a timestamp that indicates when the attribute was last changed. The timestamp may be accessed via expressions of the form:

o.'Customer Name'.timestamp()

If an attribute has never been set, then the attribute status is AttributeStatus.Uninitialized, the attribute value isEmpty(), and the attribute timestamp isEmpty().

3.3 Stages

Stages are referenced in several functions, for example to access the status of a stage:

'stage name'.status()

3.4 Milestones

Milestone are referenced as though they are Boolean attributes of the artifacts that they are associated with. For example, if artifact Order has a milestone called Completed, and o is the local name for Order in some stage, then the milestone may be referenced in that stage as:

o.Completed

3.5 Events and Event Parameters

The ASC associates each artifact with zero or more service events that reference instances of the artifact. Each service event has a name that is used in functions related to events. For example, if event Cancel is associated with artifact Order, and o is the local name for Order in some stage, then the event may be referenced using the event() function as:

o.Cancel.event()

Every event has input, output, and fault parameters, each of which has a name and associated type. These parameters may be referenced by name using the format:

… where <local name> identifies an artifact type.

If the type of the parameter is a structure type, then attributes of the structure may be referenced using the format:

Continuing the example given above, the Cancel event might have a CancelParm parameter of type Cancellation, defined as:

Cancellation: Struct [

OrderNumber: string;

Reason: string; ]

… and the Reason attribute may be referenced as:

o.Cancel.CancelParm.Reason

3.6 History

If requested in the information model definition or the ASC definition, the system may keep a history log of:

· Changes to the values of attributes (both regular and derived).

· Changes to the values of milestones.

· The arrival of events.

The history log for any of these is accessed via the history() function as described in section 12.1. These examples build upon those given above:

o.'Line Items'.history() -- collection history

o.Completed.history() -- milestone history

o.Cancel.history() -- event history

The history of individual collection elements may be accessed using collection operators as defined in section 13. The example below accesses the history of the first 'Line Item'. Note that accessing the individual collection elements is different from accessing a collection as a whole, as shown in the first example above.

o.'Line Items'àat(0).history()

Each history contains a Sequence of elements, ordered with the most recent element at index 0. The history element contents depend upon the history type:

History Type / History Element Contents
attribute / attribute value
milestone / milestone value
event / event input parameter

Element 0 of the history represents the current value of the attribute or milestone, or the input parameter of the most recent event of the specified name. Element 1 represents the previous value or event. Element 2 and successive elements represent earlier values or events.

The time that the attribute or milestone value changed, or the arrival time of the event, may be accessed using the timestamp() function, applied to a particular event entry. For example:

o.'Line Items'.history()àat(1).timestamp()

The historical status of an attribute or milestone may be obtained from the history log, using the status() function. For example:

o.'Line Items'.history()àat(1).status()

This gives the status of the milestone or attribute once it has changed to the value shown in the history log.

3.7 Service Context

When a service event arrives at an ASC, there is usually a set of system information available about the service requester or other aspects of the service event. This information might include whether the requester is authenticated or not, and if authenticated, the id, role, department, location, organization, or other aspects of the requester. The information varies among service systems, so cannot be predefined. It is defined as part of the ASC <in a manner yet to be worked out.>

This current paper assumes that the service context is defined as a structure and given a name by which it can be referenced. Each incoming service event is associated with an instance of the structure. Stages that execute in response to service events can refer to attributes of the structure to get at elements of the service context. For example: