There are relationships (design abstractions) to be considered.
Within each relationship used in such-that clauses, there are a few arguments that are allowed in each relationship.
_
Synonyms of design entities can appear as relationship arguments, and should match the design entity defined for the relationship.
Parent(arg1, arg2)
, if arg1
is a synonym, then arg1
must be a statement synonym, or a subtype of a statement synonym (read, print, assign, if, while, call).Modifies(arg1, arg2)
, if arg2
is a synonym, then arg2
must be a variable synonym.Assign, read, print, if, while, call synonyms can appear in place of statement synonyms, and vice-versa, and the query will still be semantically valid. However, there may not be results for some relationships. Let us use Parent
as illustration:
Parent(w, _)
, where w
is a while synonym: Semantically valid, and may have answers.Parent(a, _)
, where a
is a assign synonym: Semantically valid, but will not have any answers (since assignment is not a container statement).Parent(proc, _)
, where proc
is a procedure synonym: Semantically invalid because procedure synonym cannot be substituted as statement synonym.In addition, wildcard _
can appear as relationship arguments.
Modifies(arg1, arg2)
and Uses(arg1, arg2)
, where arg1
cannot be _
, as it leads to ambiguity whether _
refers to a statement or procedure.A character string in quotes (e.g., "xyz"
) can appear as relationship arguments if an instance of the design entity can be identified by that string.
Modifies(arg1, arg2)
, if arg1
is "xyz"
, then it will be interpreted as a procedure.Modifies(arg1, arg2)
, if arg2
is "xyz"
, then it will be interpreted as a variable.An integer (e.g. 23
) can also appear as relationship arguments if an instance of the design entity can be identified by the integer.
Modifies(arg1, arg2)
, if arg1
is 23
, then it will be interpreted as a statement.Do refer to example queries with one such-that clause.