Query Configuration

The query functionality in ADOxx can be configured to support predefined queries and relation tables. This pre-configuration supports the implementation of modelling method dependent query functionality as presets in the tool.

Predefined queries

Professional queries, which are business or method specific defined. For the execution of these, no AQL knowledge required.

Relationtables

Relationtables make relations (connectors or references) between two objects of same or different models.

Characteristics

• Queries on models, model content and dependencies of models
• Session-independent
• Defined by the user and therefore easy to use
• Specific for the used model and their modelling language
• A configuration of the basic functionalities of the ADOxx Platform.
  These queries can be:
  • Defined for models of a specific type
  • Combined into groups (topics)

Steps to Create predefined Queries in ADOxx:

1. Start ADOxx Development Toolkit and select Library/Sublibrary

2. Define Query Functionality by following the steps below:

• Define menu item
• Define input fields
• Define AQL queries
• Define result attributes

1. Start ADOxx Development Toolkit

Choose Library (D- or S-Library) "Predefined analysis queries"

In order to edit the analysis queries you can use selection dialogs in the library management.

2. Define Query Functionality

Available functions:

• New: Create a new menu item or a new query
• Edit: Edit an existing query
• Delete: Delete an existing query from the library
• Search entries: Call of the ADOxx search function
• Save tree-structure: Save the content of the text file
• Show/close: Various view options

These functions are available in the context menu of the list items.

Steps to Definition of Relation Tables

1. Start ADOxx Development Toolkit and select Library/Sublibrary 2. Define a Relation Table

1. Start ADOxx Development Toolkit

Choose Library (D- or S-Library) "Library attributes"

In order to define relation tables select "Analysis" dialogue

2. Define a Relation Table

The language that describes the definition of the relation tables is based on the following grammar:

| Tabledefinition : ||| { Table } | | ||| RELATIONTABLE "Tablename" | | ||| [ modeltype:"Modeltype-name" ] | | ||| fromclass:"Fromclass-name" | | Table : ||| fromattribute:"Fromattribute-name" | | ||| [ tomodeltype:"ToModeltype-name" ] | | ||| toclass:"Toclass-name" | | ||| toattribute:"Toattribute-name" | | ||| Aql | Rel . | | Rel : ||| relation:"Relation-name" | | ||| [ attribute:"Relationattribute-name" ] . |
| Aql : ||| relation:"Relation-name" |
| ||| |

Relation tables show which relations between two instances exist and which not. They are based on AQL, that means to compute which relations exists, AQL is used. The result is shown in the ADOxx browser. The relation tables come with two alternative definitions.

2.1. Definition of Relation Table with Relation Name

Here the semantic is as follows:
A relation table shows for exactly one model (of a certain modeltype) all existing connectors of the given relation between the instances of two classes (fromclass and toclass). If no modeltype is given, the default modeltype of the library is used. The value of each instance that is shown in the table (first column for the fromclass and title row for the toclass) is given by fromattribute and toattribute respective. This allows to show other attributes than 'Name', too. The existence of a
connector between two instances is represented by the character 'x'; if attribute is given the value of this attribute of the connector is shown instead.

Example:

RELATIONTABLE "Activity-Resource Table"
fromclass:"Activity"
fromattribute:"Name"
toclass:"Resource"
toattribute:"Name"
relation:"Uses"

This definition will show each connector of the relation 'Uses' that exists between a certain activity instance and a certain resource instance in any selected model.

2.2. Definition of Relation Table with AQL Expression

Here any AQL expression can be used to show a (maybe transitive and interref) relation between instances of two (maybe different) classes.
This classes can lay in different modeltypes. The following picture illustrates the general meaning of relation in this case

Here relations between instances in Model 1 and Model 3 should be displayed.

Note: The 'intermediate' Model 2 and its instances will not appear in the result table.

Using AQL in a direct way will not work as the result of an AQL expression always is a set (of instances) without any further information. In the picture above that would mean that a query starting with the instances a1, a2 and a3 in Model 1 and following the displayed (interref) relations would yield the set of instances o1, o2 and o3, but give no information between which instances relations really exist! But in the example above one would expect the relation table to yield the following informations:

a1 is related to both o1 and o2.
a3 and o3 are related (the bold connection in the picture).
a2 has no relation to any of the instances in Model 3.

Therefore when creating the AQL expression to generate the relation table do not define one, fixed expression (which would only give one result set with no further information), but better think of the resulting table as being put together from the rows:

As each row represents exactly one instance from the starting set (the fromclass), the according AQL expression for one specific row will yield the result (the existing relations) for that specific instance and therefore contain the instance name (e.g. "a1"). But because the table is meant to work in a more general case (for any model, independent of its content) of course the row specific AQL expression can not be the general solution. To make the relationtable work generally, no
fixed AQL expression is used, but it is rather created dynamically, depending on the (varying) content of the starting model. This AQL expression is dynamically (i.e. at runtime) put together from the customized FOREACHFROM and EXPR parts and is evaluated for each instance of the given fromclass.

A FOREACHFROM element represents a reference to an instance of the fromclass and is dynamically filled with the fromclass instance names (somehow it works like a wildcard). EXPR elements on the contrary represent those aql parts that are fixed and to not depend on changing instance names. Like in the Rel - case a toclass gives the upperset of the resulting instances. If the toclass is not within the same modeltype as the fromclass, a tomodeltype has to be given to identify the toclass correctly by name. Here also exists the possibility of showing any attribute (fromattribute, toattribute) of the given classes in the result browser. Furthermore the modeltype semantic is the same as in the Rel - case, i.e. gives the modeltype of the fromclass and the investigated model.

2.2.1 How to define a relationtable using FOREACHFROM and EXPR

To define a relationtable using the FOREACHFROM and the EXPR parts, first start with an AQL expression that gives the result you want for a specific instance of the fromclass. This corresponds to determine a specific row of the relation table. Using the Uses example above, to determine what resources are used by Activity-4711 the following AQL expression would solve the problem:

{"Activity-4711"} -> "Uses"

or alternatively

{"Activity-4711":"Activity"} -> "Uses"

Now as the relationtable should be generated for all activities of a certain model, that part of the AQL expression that contains the name (maybe with the classname) of the specific instance has to be replaced by a part that allows that the names of all activities are filled in dynamically at runtime. Therefore
{"Activity-4711"}
or
{"Activity-4711":"Activity"}
is replaced by the wildcard-like FOREACHFROM and the remaining part of the AQL expression above is put within an EXPR part.
This yields (the first LEO elements being the same as in the Rel - case):

RELATIONTABLE "Activity-Resource Table"
fromclass:"Activity"
fromattribute:"Name"
toclass:"Resource"
toattribute:"Name"
FOREACHFROM
EXPR "-> \"Uses\""

If a table should be generated to show which performer manages whom within an organisational unit, again start with an AQL expression that solves the problem for a certain performer:
{"Performer-4711"} -> "Is Manager" <- "Belongs to"

If we assume that the manager is also modelled as belonging to the organisational unit, then it makes sense to demand that the manager is not managing himself, therefore we subtract this performer:
{"Performer-4711"} -> "Is Manager" <- "Belongs to" DIFF {"Performer-4711"}

Replacing the dynamical parts by FOREACHFROM (in this case we have two such parts!), and putting the rest in one EXPR part yields:

RELATIONTABLE "Managertable"  
fromclass:"Performer"  
fromattribute:"Name"  
toclass:"Performer"  
toattribute:"Name"  
FOREACHFROM  
EXPR "-> \\"Is Manager\\" <- \\"Belongs to\\" DIFF "  
FOREACHFROM

Examples:

To show the transitive relation between variables and activities (via randomgenerator), use the following definition:

RELATIONTABLE "Variable-Activity Table"
fromclass:"Variable"
fromattribute:"Name"
toclass:"Activity"
toattribute:"Name"
FOREACHFROM
EXPR "<- \"Sets variable\" -> \"Sets\""

To restrict the table above to all variables whose random generator is distributed according to a discrete distribution use the following definition:

RELATIONTABLE "Variable-Activity Table"
fromclass:"Variable"
fromattribute:"Name"
toclass:"Activity"
toattribute:"Name"
FOREACHFROM
EXPR "<- \"Sets variable\" [?\"Value\" like \"Discrete*\"] -> \"Sets\""

RELATIONTABLE "Activity-Organisation Table"
fromclass:"Activity"
fromattribute:"Name"
tomodeltype:"Working Environment Model"
toclass:"Organisational unit"
toattribute:"Name"
FOREACHFROM
EXPR " --> \"Organisational unit\""

**NOTE:
As the relationtables are defined by their name, the names have to be unique within the whole library! **

Theory: AQL Notation

Extended Backus Naur Form (EBNF) notation is used for describing the AQL syntax

Terminal symbols are symbols which cannot be split up further and are included by inverted commas ' … '

Non-terminal symbols are included by < ... >
Symbols { ... }, [ ... ] and | serve to formulate rules in a more compact form :

• {...} arbitrary number of iterations (even 0-times)
• [...] optional (0- or 1-time)
• | alternative

Rules start with a non-terminal symbol, followed by "::=" and the symbol's definition

Keep in mind that AQL is cAse sEnsiTivE

AQL Terminal symbols

' <' and ' >' in this order are used to represent a class, a relation, a model, a model type, etc. (e.g. <"Rectangle"> , <"My Model 01"> , <"My First Model Type"> )

' :' is used for specifying the class of a certain object, or the model where a specific class is included (e.g. <"Red Rectangle 01">:<"Rectangle"> , <"Rectangle">:<"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.: <"B">«-"requires" AND are of class A has as results all objects that fullfill the query criteria <"B">«-"requires" AND are of class A )

' ->' , ' <-' , ' -»', ' «-' , ' –>' , ' –»' , ' <–' 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.: {"Rectangle"} )

'[' 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.

AQL Non-terminal symbols and key words

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" , "Rectangle" , "requires" , "Colour" )

<Class> ::= '<'class_name'>'

• Represents a class (e.g. <"requires">)
• If the class is not included in the current model, the class has to be denoted explicitly through model name and model type: ':'':'</span> (e.g. <"Rectangle">:<"My Model 01">:<"My First Model Type">)

<Object> :: = '<'object_name'>'

Represents an object within a concrete model (e.g. <"Red Rectangle 01">)

• Should the name of the objects be ambiguous, the name of the class has to be appended to the object's name:
• If the object referenced is not part of the current model, the object has to be denoted explicitly through model name and model type:

<Relation> ::= '<'relation_name'>'

• Represents a relationclass (e.g. <"requires">)

::= '<'attribute_name'>'

• represents the name of an attribute (e.g. <"Color">, <"Description">)

::= | '!' | '?'

• a value is either a constant, a variable preceded by the symbol '!' or an attribute preceded by the symbol '?'

::= '>' | '>=' | '=>' | '=' | '<=' | '=<' | '<' |'!='| '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

::= '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> ::= '{' [

• the result of an AQL expression is a set of objects (0,1 or more)

<AQL expression> ::= '(' ')'

• expressions may contain parentheses

<AQL expression> ::=

• expressions can be linked to one or more expressions by logical operators

<AQL expression> ::= '>''<'

• expression results can be filtered by a specific class

AQL Statements

'<' '>'

• 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"}->"requires "
  • {"A4"}<-"requires"
  • <"A">->"requires"
  • <"A"><-"requires"
  • {"Rectangle01"}<-"owns"
  • ({"A2"}-»"requires") -> "has list"
  • {"A4"}«-"requires"
  • <"Rectangle">«-"owns"
  • <"A">->"requires" >"B"«/span>

<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">-><"requires">
  • <"A"><-<"requires">
  • {"List003"} <- <"has list">
  • {"A1"} -> <"has list">

<AQL expression> '–>' | '–»'

• 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"«/span>

<AQL expression> '<–'

• The result contains all objects which refer any of the objects in the AQL expression
• Example:
  • <"Rectangle"> <–

<AQL expression> '[' ']'

• 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"> [?"Description" like ""]) AND (<"A"> [?"A_cost" >=10])
  • <"A">[?"Description" like "Test"]
  • (<"Rectangle">[?"Name" like "M*"]) AND (<"Rectangle">[?"Area" <= 20])
  • <"A">[?"Name" like "????e?"]

<AQL expression> '['']' '[' ']'

• 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: <"List">[?"Classification"][?"State" = "Authorized"]
  • attribute profile: <"A"> [?"Availability"][?"Days per week" >= 3]