Skip to content

ADOxx Query Language (AQL) ​

The ADOxx query language AQL (ADOxx Query Language) enables you to run queries on Dynamic models or Static models. The result of an AQL expression is a set of objects or connectors which meet the search criteria you specified.

AQL is used in the following places in the ADOxx Development Toolkit:

  • when editing the library attributes of D and S libraries in order to define predefined queries.
  • when editing the library attributes of D and S libraries in order to define predefined evaluation queries.
  • when entering selection criteria for model search according to model attributes in the Model Management component for the purpose of deleting models.

(See examples 1, 2, 8, 12, 13, 14 and 15 for Dynamic Models or examples 3, 4, 5, 6, 7, 9, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 and 28 for Static Models.)

The query language AQL contains static elements which can be evaluated at any time in the Analysis Component. Static elements are allowed to be assigned in the simulation only if one or more performers are removed from the used Static model. Dynamic elements are evaluated during the capacity and workload analysis via the performer assignment. Additionally the dynamic elements allow the access to variable values or performers of previous activities during the simulation.

AQL Syntax ​

Extended Backus Naur Form (EBNF) Notation

The EBNF notation specifies by so-called (production) rules which expressions meet the requirements of the AQL syntax.

Non-terminal symbols are included in <...> and serve to formulate the rules. Each rule starts with a non-terminal symbol, followed by "::=" and the symbol's definition. The non-terminal symbols occurring in the definitions are defined in other rules.

Terminal symbols (= symbols which cannot be split up further) are included by inverted commas and are interpreted directly.

The symbols {...}, [...] and | serve to formulate rules in a more compact form.

Summary of the EBNF notation:

Non-terminalDefinition
<...>non-terminal symbol
'...'terminal symbol
{...}arbitrary number of iterations (even 0-times)
[...]optional (0- or 1-time)
|alternative

Terminal Symbols and Keywords in AQL ​

The syntax of AQL requires that names of classes, objects, relations, attributes, variables and alphanumerical constants are denoted by inverted commas. White-spaces of any kind (blank, tabulator or return) are allowed in any place where they make sense.

  • '<' and '>' in this order are used to represent a class, a relation, a model, a model type, etc. (e.g. <"A"> , <"My Model 01"> , <"My Model Type"> )
  • ':' is used for specifying the class of a certain object, or the model where a specific class is included (e.g. <"A":"My Model 01":"My First Model Type"> )
  • '>' and '<' in this order are used for filtering the results of a query by a specified class (e.g.: <"A"> <<- "Relation" >"B"< has as results all objects that fullfill the query criteria **<"A"><<-"Relation" AND ** are of class B )
  • '->' , '<-' , '->>', '<<-' , '-->' , '-->>' , '<--' are used for creating AQL expressions that involve relations in the query critera (will be detailed in the future slides)
  • '{' and '}' are used to represent the object with the specified name (e.g.: {"A01"} )
  • '[' and ']' are used to introduce a criteria to an AQL expression ([?"Radius">"10"])
  • '(' and ')' are used for deciding the order in which logical operators are evaluated i.e. 'a OR b AND c' and '(a OR b) AND c ' return different results.
  • '?' is used for imposing a condition on an attribute in the query criteria (e.g.: **<"A">[?"Description" like "*OK*"] **returns all objects of class A , whose attribute "Description" contains the word "OK")
  • '!' is used for imposing a condition on a variable during the simulation (e.g.: (<"A">[!"objectCount">"10"]) OR (<"B">[!"objectCount"<="10"]) returns all objects of class A , if the variable objectCount is higher than 10 and all objects of class **B ** otherwise.

Non-terminal Symbols and Keywords in AQL ​

Names of classes, names of objects, names of relations, names of attributes, names of variables and constants are denoted by inverted commas (e.g.: "A" , "B" , "requires" , "Colour" )

  • <Class> ::= '<'class_name'>'
    • Represents a class (e.g. <"A"> )
    • If the class is not included in the current model, the class has to be denoted explicitly through model name and model type: <Class>':'<ModelName>':'<ModelType> (e.g. <"A":"My Model 01":"My First Model Type"> )
  • <Object> :: = '<'object_name'>'
    • Represents an object within a concrete model (e.g. <"A01"> )
    • Should the name of the objects be ambiguous, the name of the class has to be appended to the object's name:<Object>':'<Class> (e.g. <"A01" : "A"> )
    • If the object referenced is not part of the current model, the object has to be denoted explicitly through model name and model type:
      <Object>':'<Model name>':'<Model type> (e.g.: <"A01":"My Model 01":"My First Model Type"> ) or <Object>':'<Class>':'<Model name>':'<Model type> (e.g.: <"A01":"A":"My Model 02">:<"My First Model Type"> )
  • <Relation> ::= '<'relation_name'>'
    • Represents a relationclass (e.g. <"Relation"> )
  • <Attribute> ::= '<'attribute_name'>'
    • represents the name of an attribute (e.g. <"Color">, <"Description"> )
  • <Value> ::= <Constant> | '!' <Variable> | '?' <Attribute>
    • a value is either a constant, a variable preceded by the symbol '!' or an attribute preceded by the symbol '?'
  • <Operator> ::= '>' | '>=' | '=>' | '=' | '<=' | '=<' | '<' |'!='| 'like' | 'unlike'
    • 'like' and 'unlike' are used for alphanumerical signs
    • ? and * are wildcards:"*" substitutes for any zero or more characters and "?" substitutes for any one character or less (123??? will match 12313 or 1233, but not 1239919991)
    • the other operators are used for comparing numerical values
  • <LogicalOperator> ::= 'AND' | 'OR' | 'DIFF'
    • 'AND' : the result is the intersection set of the two expressions
    • 'OR' : the result is the union set of the two expressions
    • 'DIFF' : the result is the difference of the two expressions
    • 'AND' links more strongly than 'OR' and 'OR' more strongly than 'DIFF'
  • <AQL expression> ::= '{' [<Object>] [',' <Object>] '}'
    • the result of an AQL expression is a set of objects (0,1 or more)
  • <AQL expression> ::= '(' <AQL expression> ')'
    • expressions may contain parentheses
  • <AQL expression> ::= <AQL expression> {<LogicalOperator> <AQL expression>}
    • expressions can be linked to one or more expressions by logical operators
  • <AQL expression> ::= <AQL expression> '>'<Class>'<'
    • expression results can be filtered by a specific class
Non-terminalDefinition
<Class> ::=The name of a class or relation. The classes and relations such as "Process start", "Activity", "Decision", "Subsequent" and so on are available to the user via the modelling panel in the model editor, so that he can design dynamic models. The model, that contains a class or relation, arises from the context of the analysed or simulated models. If another model is desired (i.e. because a class or relation should be referenced in particular model), it has to be entered explicitly (through names and model types): <Class>':'<Model name>':'<Model type> Hint: With <""> all objects of a model are listed.
<Object> ::=The name of an object within a concrete dynamic or static model. "Write letter", for example, could be the name of an object of the class "Activity". Should objects be ambiguous within a model, the name of the class has to be appended to the object's name as in <Object>':'<Class>.The model, that contains a class or relation, arises from the context of the analysed or simulated models. If another model is desired (i.e. because a class or relation should be referenced in particular model), so it has to be entered explicitly (through names and model types): <Object>':'<Model name>':'<Model type>, or <Object>':'<Class>':'<Model name>':'<Model type>
<Relation> ::=The name of a relation, e.g. "Subsequent" in dynamic models or "Has role" in static models.
<Attribute> ::=The name of an attribute, e.g. the class "Activity" has - among others - the attribute "Execution time".
<Operator> ::='>' | '>=' | '=>' | '=' | '<=' | '=<' | '<' | '!=' | 'like' | 'unlike' | 'ilike' | 'iunlike'
are comparison operators. 'like' and 'unlike' are used for alphanumerical signs, are case-sensitive and allow the use of wild cards (? and/or *) in symbol chains. 'ilike' and 'iunlike' have the same functionality, except they are not case-sensitive. The other operators are used for comparing numerical values. The operator 'contains' is available where complex attribute values (e.g. intermodel-references) can be interrogated. The operator represents on the one hand, in the sense of a set operation, something comparable with a set inclusion (subset feature), on the other hand the adherence will be expressed this way in the sense of a subtext. However this operator is not an AQL key word!
<Value> ::=<Constant> | '!' <Variable> | '?' <Attribute>
<Constant> ::=A constant expression such as 1000, Yes or others.

Logical Operators serve to link two (or more) AQL expressions:

Non-terminalDefinition
<Logical Operator> ::='AND' | 'OR'
  • 'AND' links two AQL expressions. The result is the intersection set of the two expressions, i.e. the result consists of all those objects which are both the result of the first and the result of the second expression.
  • 'OR' links two AQL expressions. The result is the union set of the two expressions, i.e. the result consists of all objects which are either the result of the first or the result of the second expression or both.
  • 'DIFF' links two AQL expressions. The result is the difference of the two expressions, i.e. the result consists of all those objects which are the result of the first expression, but not the result of the second expression.

'AND' links more strongly than 'OR' and 'OR' more strongly than 'DIFF', i.e. the expression "a DIFF b OR c AND d" is evaluated correctly like this: a DIFF (b OR (c AND d)).

Rules for formulating AQL expressions ​

The following rules are used while formulating AQL expressions (Analysis Component and static performer assignment of the Simulation Component) or dynamic performer assignment (Simulation Component):

RuleDefinitionDescription
Rule 1:<AQL expression> ::= <AQL expression> {'AND' | 'OR' | 'DIFF' <AQL expression>}Each expression can be linked to one or more expressions by logical operators. See examples 16,20, 29,30, 31,32 and 34.
Rule 2:<AQL expression> ::= '(' <AQL expression> ')'Expressions can have parentheses. See examples 12, 16,20, 22,29, 30,31, 32 and 34.
Rule 3:<AQL expression> ::= '{' <object> [ ',' <object> ] '}'The result is a set of objects. These are not necessarily derived from a class. See examples 1, 2. As far as the allocation of resources to activities is concerned, see example 36.
Rule 4:<AQL expression> ::= '<' <class> '>'The result is all objects of the class specified. See examples 3, 4, 5, 17, 18, 19, 20, 21, 23, 27, 28, 31, 33, 39 and 40.
Rule 5:<AQL expression> ::= <AQL expression> '->' <Class>The result is all objects which are of the specified class. See example 11.
Rule 6:<AQL expression> ::= <AQL expression> '->' <Relation>The result is all objects which are linked as direct targets of the given relation with at least one object from the AQL expression. See example 6.
Rule 7:<AQL expression> ::= <AQL expression> '<-' <Relation>The result is all objects which are linked as a direct start object of the relation specified with at least one object from the AQL expression. See examples 7 and 8.
Rule 8:<AQL expression> ::= <AQL expression> '->>' <Relation>The result is all objects which are linked transitively as a target object of the relation specified with at least one object from the AQL expression. See example 12.
Rule 9:<AQL expression> ::= <AQL expression> '<<-' <Relation>The result is all objects which are linked transitively as a start object of the relation specified with at least one object from the AQL expression. See examples 9, 10 and 11.
Rule 10:<AQL expression> ::= <AQL expression> '->' '<' <Relation> '>'The results are all connectors of the specified relation which have one of the specified objects as a start object. See example 13.
Rule 11:<AQL expression> ::= <AQL expression> '<-' '<' <Relation> '>'The results are all connectors of the specified relation which have one of the specified objects as an end point. See example 14.
Rule 12:<AQL expression> ::= <AQL expression> '[' <Value> <Operator> <Value> ']'The result is all objects of the start query, which attributes fulfil the defined criteria. Constants (numbers, string constants) can only be at the right of the operator. At the left of the operator, there are only attributes or variable references. See examples 17,18, 19,20, 31 and 33. Note: Queries with variable references as dynamic components in the performer assignment are only allowed in the simulation. See example 16.
Rule 13:<AQL expression> ::= <AQL expression> '[' <Value> ']' '[' <Value> <Operator> <Value> ']'The result is all objects of the start query where their record attribute profile attribute fulfils the defined criteria. The first value is an attribute reference and specifies the name of the record or attribute profile attribute. In the second expression, constants (numbers, string constants) can only be at the right side of the operator. At the left side of the operator, there are only attributes or variable references. Note: In case of a record attribute, the criteria is always fulfilled, if at least a table row of the record attribute meets the defined criteria. See example 21 for record attributes and 41 for attribute profile attributes.
Rule 14:<AQL expression> ::= 'done by' <Activity>Performer assignment. The result is the performer who has carried out the activity during a simulation run. This way, you will ensure, that an activity will be carried out by the same performer as defined in the performer assignment for this activity. The dynamic performer assignment is useful only for the simulation and is only possible within a Dynamic model. See example 15.
Rule 15:<AQL expression> ::= 'done by' <Variable>Performer assignment. This dynamic performer assignment can be used in an intermodel assignment . The result is the performer who has carried out the activity referenced through the variable during a simulation run. To use this construct it is necessary to enter the name of the variable in the attribute "done by" of the referenced activity. See example 35.
Rule 16:<AQL expression> ::= 'current performer' '->' <Resources relation>Resources assignment. This way you will ensure that the performer who carries out the current activity uses the resources given to him (resources assignment to performer). See example 37.
Rule 17:<AQL expression> ::= <AQL expression> '-->' <Attribute>The result is all objects which are referenced in the specified attribute of the object. See example 39.
Rule 18:<AQL expression> ::= <AQL expression> '-->>' <Attribute>The result is all objects which are transitively referenced in the specified attribute of the class.
Rule 19:<AQL expression> ::=<AQL expression> '<--'The result is all objects which refer the specified object. See example 40.

AQL Statements ​

  • '<' <class> '>'
    • the result is all objects of the specified class
    • Examples:
      • <"A">
      • <"Square":"SecondModel001":"My Second Model Type">
      • <"A"> [?"Name" like "????e?"]
      • <"B"> <- "requires"
  • <AQL expression> '->' | '<-' | '->>' | '<<-' <Relation>
    • The result contains all objects which are linked through the he given relation with at least one object from the AQL expression
    • '->' returns all direct targets of the relation
    • '<-' returns all direct start objects of the relation
    • '->>' returns all transitive targets of the relation
    • '<<-' returns all transitive start objects of the relation
    • Examples:
      • {"A1"}->"rel_out"
      • {"A4"}<-"rel_in"
      • <"A">->"rel_out"
      • <"A"><-"rel_in"
      • {"A01"}<-"rel_in"
      • ({"A2"}->>"trans_rel_out") -> "rel_out"
      • {"A4"}<<-"trans_rel_in"
      • <"A"><<-"trans_rel_in"
      • <"A">->"rel_out" >"B"<
  • <AQL expression> '->' | '<-' '<' <Relation> '>'
    • The result contains all connectors of the specified relation which have as start or target object one of the objects in the AQL expression
    • '->' returns all connectors originating from the objects of the AQL expression
    • '<-' returns all connectors ending in the objects of the AQL expression
    • Please note similarities and differences with before: if you use the '<' and '>' symbols, the result contains the connectors and if you don't use them, it contains the objects
    • Examples:
      • <"B">-><"rel_out">
      • <"A"><-<"rel_in">
      • {"B3"} <- <"rel_in">
      • {"A1"} -> <"rel_in">
  • <AQL expression> '-->' | '-->>' <InterRef_Attribute>
    • The result contains all objects which are referenced in the specified attribute of any of the objects in the AQL expression
    • The '-->>' operator returns is all objects which are transitively referenced in the specified attribute of any of the objects in the AQL expression
    • Examples:
      • <"A"> --> "IsRunBy"
      • <"A"> -->> "IsRunBy"
      • {"A5"} --> "IsRunBy"
      • {"A5"} -->> "IsRunBy"
      • {"A5"} -->> "IsRunBy" >"Rectangle"<
  • <AQL expression> '<--'
    • The result contains all objects which refer any of the objects in the AQL expression
    • Example:
      • <"Rectangle"> <--
  • <AQL expression> '[' <Value> <Operator> <Value> ']'
    • The result contains all objects, whose attributes fulfill the defined criteria
    • Constants (numbers, strings) can only be at the right of the operator
    • To the left of the operator there are only attributes or variable references
    • Note: Queries with variable references as dynamic components in the performer assignment are only allowed in the simulation
    • Examples:
      • (<"A">[?"attr_name" like "a*"]) AND (<"A">[?"a1" >= 0])
      • (<"A">[?"attr_name" = "a1"]) AND (<"A">[?"attr_name" >= 0])
      • <"A">[?"Name" like "????a?"]
  • <AQL expression> '['<Value>']' '['<Value> <Operator> <Value>']'
    • The result contains all objects of the start query where their record attribute or attribute profile fulfills the defined criteria
    • The first value specifies the name of the record attribute or attribute profile.
    • See above the rules for the second expression
    • Note: In case of a record attribute, the criteria is always fulfilled, if at least a table row of the record attribute meets the defined criteria.
    • Examples:
      • record attribute: <"A">[?"attr_name"][?"column_name" = "column_value"]
      • attribute profile: <"A"> [?"attr_name"][?"AP_attr_name" >= 0]