Index: /reasoner/approach.tex =================================================================== --- /reasoner/approach.tex (revision 144) +++ /reasoner/approach.tex (revision 144) @@ -0,0 +1,23 @@ +\section{Approach}\label{sectApproach} + +IVML is a textual variability and configuration modeling language. The syntax of IVML, which is mostly out of scope here (please refer to~\cite{IVML-LS} for the complete specification), is based on well known (programming) language concepts and can be used to express the (meta-)model of a configuration as well as individual configurations. The main concept of IVML is the \emph{typed variable}, which may have a default value expression. For short, IVML offers basic types (Boolean, Integer, Real, String), user-defined compound types (groups of variables, can be subject to multi-inheritance), container types (set, sequence), derived types (constraining or aliasing another type) and constraint types, i.e. variables holding a constraint so that it can be overridden by assigning a new constraint. IVML variables can be further detailed by and interrelated with other variables through constraints. The constraint (expression) language is largely inspired by concepts (and notation) of the Object Constraint Language (OCL)~\cite{OCL24}, but, in contrast to OCL, allows side-effect to enable the definition of configurations as well as the propagation of configuration values. IVML models (given in terms of so called \IVML{projects}), can be imported, staged~\cite{CzarneckiHelsenEisenecker05a} and conditionally frozen, in particular to enable partial instantiation of code, including removal of variation points. + +Over the last years, we approached the analysis and reasoning for IVML from different perspectives, including traditional reasoning mechanisms or rule engines~\cite{QMD42}. Although these mechanisms are powerful in their own respect and typically available as implementation, using them for IVML requires translating an IVML model and its constraints into the model of the respective reasoning mechanism and executing that mechanism on the translated model. In the past, we identified in particular this transformation as performance bottleneck as well as an obstacle to achieve IVML-completeness, i.e., we were often not able to express all IVML concepts in the respective reasoner model. While traditional reasoners allow for completing a model through feasible ground instances, they typically also perform a kind of constrained state space exploration. Considering the size of usual configuration models (currently the largest IVML model we are aware of has more than 16.000 variables~\cite{EichelbergerQinSizonenko+16, EichelbergerQinSchmid17a}), we experienced that just applying a traditional reasoner to usual IVML models is an inefficient approach. Other related mechanisms such as rule engines can be applied to some degree, however, according to our experience~\cite{EichelbergerQinSizonenko+16, QMD42, QMD43} lead to a significant and infeasible runtime overhead. Moreover, traditional reasoners as well as rule engines are limited as they typically do not support the range of OCL operations required for IVML, in particular container iterators, quantifiers and user-defined constraint operations. Further, also specific reasoning approaches, e.g., for the Object Web Language (OWL)~\cite{KahnPorres15, KolliaGlimmHorrocks11} might be an option as they partially support quantification, but they are similarly limited regarding the range of OCL operations. Moreover, OCL-based approaches such as~\cite{DemuthLoecherZschaler04, ClavelEgea06} typically also focus on forward-chaining, but would require deep extensions, as OCL does not allow for side-effects or value propagation as required by IVML. + +Due to these experiences, we decided to pursue a \emph{mixed reasoning approach}, which attempts to reduce / simplify the reasoning problem towards an instance that (if needed) can finally be handled by a traditional reasoning approach. In our case, the basis for a mixed approach is \emph{forward-chaining}, i.e., evaluation of a given constraint base as long as no constraints are left over, while re-scheduling constraints that depend on a variable changed during reasoning. The SSE IVML reasoner as described in this document realizes this basis, while the actual mixed approach is part of future work. Other work also combine multiple reasoning approaches to achieve advanced reasoning capabilities, e.g., evolutionary algorithms with SAT-solving to realize many-objective optimization for feature modeling~\cite{XiangZhouZheng+2018}. + +It is important to notice that IVML~\cite{IVML-LS} supports declarative specification of constraints, i.e., modeling concepts and constraints can be specified regardless of their actual evaluation sequence. To ensure that values for variables are uniquely determined, in particular in presence of default values, IVML allows changing the value of a variable only once within a project scope. Otherwise the reasoning mechanism must issue an error. Thus, reasoning must happen project-wise, in a depth-first traversal along the project import dependencies. Moreover, to speed up reasoning in specific situations, some form of sequence of the constraints can be indicated through the concept of partial evaluations, i.e., eval-blocks stated within a project or a compound. An eval-block consists of constraints or nested eval-blocks, while nested eval-blocks implicitly define an evaluation sequence. In other words, a project is the outermost (implicit) eval-block and nested eval-blocks shall be evaluated in their nesting sequence, while eval-blocks on the same nesting level do not imply any evaluation sequence. + +However, not all IVML constraints can be directly used for reasoning. This is in particular true for constraints defined in compound types, i.e., these constraints must hold for all instances, or, indirectly, through types used within collections, i.e., these constraints must hold for the respective collection elements. Such constraints typically utilize local variables defined within the compound including the special pre-defined variable \IVML{self} pointing to the actual compound instance. Allowing such implicit constraints rather than requiring that all constraints are defined directly on the configuration variables increases consistency and helps reducing model sizes and complexity. +%Cross-references to other types are required to be specified through an explicit accessor, i.e., an expression mentioning the variable and the respective nested variable(s). +As a consequence, the reasoning mechanism must relate type-based constraints to the correct underlying configuration variables. In our approach, we perform first a \emph{constraint translation} to instantiate the constraints for configuration variables based on the actual type of the variable or its value. An alternative could be reasoning over type constraints and modifying the mapping to the variables on demand before evaluation. This may save memory and runtime (required for constraint translation / creation), but, however, also increases the complexity of managing the actual constraints to be evaluated. + +Based on our experience~\cite{EichelbergerQinSizonenko+16, QMD42, QMD43} and taking into account the specific requirements of the default values, project scopes, eval-block scopes, we are convinced that (at least the first step in a mixed reasoning approach) shall directly operate on an IVML model, also to achieve a high runtime performance. In particular, model transformations such as the constraint translation shall happen only if required to reduce overhead on the reasoning time. After the required constraint translation, constraint evaluation and forward-chaining is executed on the collected constraint base. Besides the resulting configuration, \emph{detained reasoning output} is required, so that subsequent reasoners in a reasoning chain can continue on the results. For this purpose, reasoning error messages shall not only contain the failed constraint, but also additional information such as failing sub-expressions. Based on such output, we can imagine that more advanced reasoning engines such as SMT-reasoners could complement the described approach. Translating the information about failed constraints into a model that is suitable for sophisticated reasoning approaches could enable advanced capabilities, such as value determination, instance creation or configuration completion / repair. However, such chained reasoning is out of the scope of this document. + +Basically, reasoning over all variables of a project including all constraints is needed. This may differ for certain use cases where considering all constraints neither required nor efficient in terms of reasoning time. The first use case is \emph{incremental reasoning}, i.e., starting with a given configuration and just analyzing the changes made by the user. The idea is to provide immediate reasoning results, so that reasoning even on complex and large models can happen upon every change made by the user. The second use case is \emph{runtime reasoning}, e.g., reasoning for validity of a configuration at runtime of a system to identify validations and to trigger re-configuration or adaptation~\cite{Eichelberger16}. In this case, we may assume that the underlying IVML model is not changed, so that initially translated constraints can be re-used. This assumption may does not hold in the incremental reasoning case. For supporting these two cases, we introduce two main \emph{reasoning modes}, namely complete (full) reasoning and incremental reasoning, while incremental reasoning can be achieved through the following two techniques. +\begin{itemize} + \item \emph{Creation of a partial constraint base:} Constraints assigning already processed default values or constraints over variables that cannot change anymore (frozen variables) are not added to the constraint base. The remaining configuration variables are assumed to be properly initialized or shall be instantiated by the reasoner if possible. Thus, reasoning focuses on non-frozen variables\footnote{In EASy-Producer, this technique can be enabled through the reasoner configuration.}, in particular changed variables. In our experiments, this mechanism can save up to 65\% reasoning time. + \item \emph{Re-using a previously created constraint base:} The initial constraint base created by the constraint translation is stored in memory and re-stored when applying the reasoner again to the same (structurally unchanged) model, i.e., we require that no new types or variables are added between two reasoning runs. This technique\footnote{This technique can be applied by requesting a re-usable reasoner instance from the EASy-Producer reasoner core and by using that instance instead of the default interface provided by the static reasoning fronted.} trades off reasoning time for memory consumption and can even be combined with creating a partial constraint base, saving up to further 75\% reasoning time. +\end{itemize} + +To implement the IVML reasoner, we first designed and realized an \emph{expression evaluation mechanism}, which is able to evaluate individual IVML expressions. The evaluation mechanisms covers constraint expressions (expressions evaluating to a Boolean value) as well as general default value expressions. The reasoner relies on that mechanism, i.e., in the algorithms described in this document, we just refer to the evaluation mechanism without further detailing it. We assume that the mechanism either returns the correctly evaluated value of an expression with respect to a given model / configuration or that it indicates that the evaluation result is undefined, e.g., as configuration variables used in the evaluated expression are undefined. Index: /reasoner/conclusion.tex =================================================================== --- /reasoner/conclusion.tex (revision 144) +++ /reasoner/conclusion.tex (revision 144) @@ -0,0 +1,3 @@ +\section{Conclusion}\label{sectConclusion} + +\TBD{We are better than before, we are now more IVML-complete, but not reasoning-complete. Future, integrate with SMT or other solvers for left-over reasoning problems or configuration completion/instance creation (potential student work).} Index: /reasoner/consRescheduling.tex =================================================================== --- /reasoner/consRescheduling.tex (revision 144) +++ /reasoner/consRescheduling.tex (revision 144) @@ -0,0 +1,103 @@ +\section{Constraint Re-scheduling}\label{sectTopLevelConstraintsRescheduling} + +When variable $v$ is changed as side effect of a constraint evaluation during reasoning, Algorithm \ref{algVarChange} is called. + + +If the changed variable is not local, i.e., neither a parameter of a user-defined function, an iterator of a container operation nor a local variable defined in a let-expression, the variable is relevant for re-scheduling. First, Algorithm \ref{algVarChange} registers in line \ref{algVarChangeScope} the change of $v$ within the actual project scope if the value of $v$ actually has been affected by reasoning. This scope information is used by the evaluator prior to a variable assignment to check for illegal duplicate assignments within the same scope. Then, if the value actually changed, we identify constraints that must be added to or removed from the constraint base. This may be due to nested constraint values (line \ref{algVarChangeRescheduleConstraintVariables}) in the new value as well as a type change of a compound value along the refinement hierarchy, which may require more or less constraints to be considered (line \ref{algVarChangeRescheduleValueTypeChange}). All these cases may affect the relevant constraints. When adding or removing constraints, new constraints are added to $\relevantConstraintVariables$ and $\relevantConstraintsPerDeclaration$, while now now irrelevant constraints are identified via $\relevantConstraintVariables$ and also removed from $\relevantConstraintVariables$ and $\relevantConstraintsPerDeclaration$. Finally , parent (line \ref{algVarChangeRescheduleParents}) and nested (line \ref{algVarChangeRescheduleNested}) constraints may need to be re-scheduled, too, if the related variables aside from constraint variables changed. This happens through a lookup to $\relevantConstraintsPerDeclaration$, implying that previously added / removed constraints due to value type changes are not re-scheduled. + +If the changed variable is local and there is a mapping in $\variableMapping$, e.g., as the variable is used as iterator in the evaluation of a quantor expression, we adjust the mapping\footnote{Technically, a local decision variable wraps either a value (if the evaluation runs over constants) or a decision variables. To allow for (call-by-reference) propagation on nested slots and attributes, changing the context registration actually refers to the actually wrapped decision variable, but this is not detailed here.}. + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{decision variable $v$, old value $val_o$} + \KwData{scope assignments $\scopeAssignments$, relevant constraints $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$} + + \If{$\neg isLocal(v)$}{ + $addAssignment(\scopeAssignments, v)$\; \label{algVarChangeScope} %addScopeAssignment + $val_n \assng value(v)$\; + \If{$val_n \neq val_o$} { + $rescheduleValueChange(v, v, true)$\; \label{algVarChangeRescheduleConstraintVariables} + \If{$isValueTypeChange(v, val_n, val_o)$ \MISSING{!}} { + $rescheduleValueTypeChange(v, val_n, val_o)$ \MISSING{!}\; \label{algVarChangeRescheduleValueTypeChange} + } + } + $base \assng base \addSeqNoDupl \seqWith{\relevantConstraintsPerDeclaration[p]}{p\in allParents(v)}$\; \label{algVarChangeRescheduleParents}%constraintsForParent + $base \assng base \addSeqNoDupl \seqWith{\relevantConstraintsPerDeclaration[n]}{n\in allNested(v)}$\; \label{algVarChangeRescheduleNested}%constraintsForParent +% $base \assng base \addSeqNoDupl \bigcup_{c\in alNested(v)}\relevantConstraints[c]$\; \label{algVarChangeRescheduleNested}%constraintsForChilds, nested geht für alle variablen + }\ElseIf{$getMapping(\variableMapping, decl(v)) \neq \undef$}{ + $registerMapping(\variableMapping, decl(v), v)$\; + } + \caption{Adjusting the constraint base (\IVML{notifyChanged}).}\label{algVarChange} +\end{algorithm} + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{parent variable $v_p$, decision variable $v$, old value $val_o$, clear flag $clear$} + + $t_n \assng type(value(v)))$\; + \uIf{$isConstraint(t_c)$} { + $rescheduleConstraintValue(v_p, v, clear)$\; + } \uElseIf{$isCompound(t_c)$}{ + $rescheduleCompoundValue(v, val_o)$\; + } \uElseIf{$isContainer(t_c)$}{ + $rescheduleContainerValue(v, val_o)$\; + } + + \caption{Reschedule a value change (\IVML{rescheduleValueChange}).}\label{algRescheduleContainerValue} +\end{algorithm} + + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{parent variable $v_p$, decision variable $v$, clear flag $clear$} + \KwData{scope assignments $\scopeAssignments$, relevant constraints $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$} + + \If{$isConstraint(type(v)$} { + $cs \assng obtainConstraints(v_p, clear, \undef)$ \MISSING{!}\; + $ex \assng getConstraintValueConstraintExpression(value(v))$ \MISSING{!}\; + \If{$ex \neq \undef$}{ + \lIf{$cs = \undef \vee |cs|=0$}{$p\assng parent(decl(v))$}\lElse{$parent(cs[0])$} + $ex_p \assng createParentExpression(v)$\; + $c \assng createConstraintVariableConstraint(ex, ex_p, \undef, p, v_p)$ \MISSING{!}\; + $setValue(v, c)$\; + $base \assng base \addSeq \otherConstraints$\; + \ForAll{$p\iterAssng allParents(v)$}{ % variablesMap.addAll(variable, otherConstraints); + $\relevantConstraintsPerDeclaration \assng \relevantConstraintsPerDeclaration \addMap \mapEntry{p}{\relevantConstraintsPerDeclaration [v] \cup \otherConstraints}$\; + } + $\otherConstraints \assng \emptySet$\; + } + } + \caption{Reschedule a constraint value (\IVML{rescheduleConstraintValue}).}\label{algRescheduleConstraintValue} +\end{algorithm} + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{decision variable $v$, old value $val_o$} + \KwData{scope assignments $\scopeAssignments$, relevant constraints $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$} + + \If{$isCompound(v)$}{ + \ForAll{$s\iterAssng slots(value(v))$}{ + \If{$value(s) \neq \undef$}{ + $rescheduleValueChange(s, s, value(s), true);$\; + } + } + } + \caption{Reschedule a compound value (\IVML{rescheduleCompoundValue}).}\label{algCompoundValue} +\end{algorithm} + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{decision variable $v$, old value $val_o$} + \KwData{scope assignments $\scopeAssignments$, relevant constraints $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$} + + $val_n \assng value(v))$\; + \If{$isContainer(type(val_n)) \wedge isContainer(type(val_o))$}{ + $first \assng true$\; + \ForAll{$c \iterAssng elements(val_n), o \iterAssng elements(val_o)$} { + $rescheduleValueChange(v, c, o, first)$\; + $first \assng false$\; + } + } + + \caption{Reschedule a container value (\IVML{rescheduleContainerValue}).}\label{algContainerValue} +\end{algorithm} Index: /reasoner/consTranslation.tex =================================================================== --- /reasoner/consTranslation.tex (revision 144) +++ /reasoner/consTranslation.tex (revision 144) @@ -0,0 +1,566 @@ +\section{Constraint translation}\label{sectTranslation} + +The constraint translation analyzes constraints defined for a given IVML model, instantiates those constraints for which reasoning cannot happen directly and fills the constraint base accordingly. In particular, constraints defined over types rather than qualified variable access expressions must be instantiated. We distinguish three main types of constraints, for which the top-level constraint translation algorithm (Algorithm \ref{algTranslateConstraints}) already indicated the subsequent translation calls: + +\begin{enumerate} + \item \emph{Constraints for default values}. To achieve uniformity of the constraint evaluation and re-scheduling upon value changes (cf. Section \ref{sectReasoning}), we also translate default value assignments to assignment constraints and add them to the constraint base. In more detail, an IVML declaration \IVML{\textit{Type} v = ex;} is translated to a constraint $\createConstraint{v = ex}$. We add assignment constraints to the constraint base with higher priority, i.e., at a lower sequence position than other constraints to ensure that default values are assigned first. For value assignment constraints, we must consider that default value expressions assigning complex values shall have higher priority than default values for individual slots or sequence positions. Otherwise, the value for an individual slot or position may accidentally be overridden by the complex value\footnote{This is partially caused by legacy behavior of the implementation, which cleans the target variable before assigning a complex value. However, re-assignment of values for individual slots or positions in the same scope leads to a reasoning error as required.}. Moreover, default value assignments can change the actual (value) type of a variable implying that a refined set of constraints must be evaluated. Creation of assignment constraints is part of translating variable declarations (called in Algorithm \ref{algTranslateConstraints} in line \ref{algTranslateConstraintsTranslationDeclaration}). + \item \emph{Top-level constraints} are defined using only top-level variables or fully qualifying accessor expressions. Top-level constraints include constraints in top-level eval blocks as well as constraints in top-level annotation assignment-blocks. Top-level constraints are ready for reasoning, i.e., they do not need further translation and can directly be taken over into the constraint base (Algorithm \ref{algTranslateConstraints}, lines \ref{algTranslateConstraintsAdd} - \ref{algTranslateConstraintsTopLevelEvals}). Annotation assignments are processed by Algorithm \ref{algTranslateAnnotationAssignments}. We use that algorithm also for translating annotation assignments in compound types. + \item \emph{Constraints in type definitions}, e.g., in compound types, typedefs with constraints or collections. These constraints must be instantiated, i.e., use of (local) variables and slots defined by a type must be substituted by fully qualifying accessor. We use top-level variables as entry point and perform a (recursive) constraint instantiation based on the type of the variable. Identifying constraints in types happens also during the translation of declarations (Algorithm \ref{algTranslateConstraints} line \ref{algTranslateConstraintsTranslationDeclaration}). +\end{enumerate} + +We detail now the constraint translation in the remainder of this section. We start in Section \ref{sectTranslationDeclarationTypesDefaults} with the translation of variable declarations, which delegates the translation to further algorithms and is called recursively during the translation of compound and collection variables. Then we follow the algorithms called while processing a variable declaration, i.e., the call graph shown in Figure \ref{figStructure}. Thus, the following sections focus on derived types in Section \ref{sectDerivedTypes}, annotation assignments in Section \ref{sectAnnotationDefaults} (as already used in (Algorithm \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelAnnotationAssignments}), compound types in Section \ref{sectCompoundDefaults}, container types in Section \ref{sectContainerDefaults}, and, constraint variables in Section \ref{sectConstraintVariables}. Finally, we discuss the algorithms for building the constraint base in Section \ref{sectContainerBase}. + +\subsection{Variable Declarations}\label{sectTranslationDeclarationTypesDefaults} + +As introduced in Section \ref{sectNotationVarDecls}, an IVML variable declaration consists of a type, a variable name and an optional default value expression. At its core, the translation of a variable declaration creates an assignment constraint for the default value expressions and instantiates all constraints defined by the variable type. If known, the translation considers the actual type of the variable defined by the configured value, which may in particular have a refined (compatible) compound type and, thus, a refined set of constraint. However, due to the complex structure of IVML types, identifying the constraints defined by a type may require a transitive or even recursive traversal over refined or underlying base types, e.g., in case of a typedef or a container. + +\grayPara{ +\begin{gather*} + \patternDerivation{T \text{ } v = deflt\IVML{;}}{access(v) = deflt} \\ + \patternDerivation{\IVML{annotate } a = deflt \IVML{ to} *\IVML{;} T \text{ } v\IVML{;}}{access(v.a) = deflt} \\ +\end{gather*} +} + +Let $v$ be a variable with default value expression $deflt$. The first transformation pattern above turns $deflt$ into an assignment constraint. If $v$ is nested in a compound or a sequence, a qualified access expression is required in the resulting constraint. In the transformation pattern, we indicate this by $access(e)$ on the right side, which returns the given expression $e$ if $e$ is an access to a top-level variable and prefixes $e$ appropriately if $e$ expresses an access to a nested variable. The second pattern refers to annotations. As introduced in Section \ref{sectNotationVarDecls}, annotations are variables represent an an orthogonal configuration dimension on top of 'ordinary' variables. Thus, an annotation $a$ is translated similarly to an ordinary variable, but requires in addition a qualification through the respective ordinary variable $v$. + +Algorithm \ref{algTranslateDeclaration} translates all constraints related to a given variable $v$ (and its declaration $d$) based on the actual type of $v$. As complex types such as compounds may occur, Algorithm \ref{algTranslateDeclaration} delegates such types to more specialized algorithms, which then use Algorithm \ref{algTranslateDeclaration} recursively for nested variable declarations (with a respective access expression $ca$ and an adequately prepared variable mapping $\variableMapping$). These specialized algorithms will be discussed in the following sections. Assignment constraints created in Algorithm \ref{algTranslateDeclaration} are stored either in the global set for default constraints $\defaultConstraints$ or the set for deferred default constraints $\deferredDefaultConstraints$. + +Algorithm \ref{algTranslateDeclaration} consists of three parts: identifying the actual type and preparing the variable mapping (lines \ref{algTranslateDeclarationInitStart}-\ref{algTranslateDeclarationInitEnd}), translating the default value expression (lines \ref{algTranslateDeclarationDefaultStart}-\ref{algTranslateDeclarationDefaultEnd}) and translating complex types (lines \ref{algTranslateDeclarationComplexStart}-\ref{algTranslateDeclarationComplexEnd}). + +In the first part, Algorithm \ref{algTranslateDeclaration} first declares some local variables in line \ref{algTranslateDeclarationDecl}, including the default value expression $e_d$ (ignored in incremental mode), the actual value of self $f$ (for compound types only, overridden in line \ref{algTranslateDeclarationTranslateSelf1}) and the compound translation mode ($c_m$, overridden in line \ref{algTranslateDeclarationRegisterCompound} for use in line \ref{algTranslateDeclarationTranslateCompound}). + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{declaration $d$, variable $v$, access $ca$} + \KwData{variable mapping $\variableMapping$, default (deferred) constraints $\defaultConstraints$ and $\deferredDefaultConstraints$, incremental flag $inc$} + + $e_d \assng \closedCases{\undef & \text{if } inc \\ default(d) & \text{else}}$; $f \assng \undef$; $c_m\assng NONE$\; \label{algTranslateDeclarationDecl}\label{algTranslateDeclarationInitStart} + $t \assng \closedCases{type(value(v)) & \text{if } v \neq \undef \wedge\text{ } value(v) \neq \undef \\ type(e_d) & \text{if } e_d \neq \undef \\ type(d) & \text{else}}$\; \label{algTranslateDeclarationRefinedType} + \uIf{$isCompound(t)$}{ + $f \assng d$\; \label{algTranslateDeclarationTranslateSelf1} + $c_m \assng translateCompoundDeclaration(d, v, ca, t, REGISTER)$\; \label{algTranslateDeclarationRegisterCompound} + }\label{algTranslateDeclarationInitEnd} + + \If{$e_d \neq \undef \wedge \neg(isAttribute(d) \wedge isAnnotationAssng(parent(d)))$}{ \label{algTranslateDeclarationDefaultStart} + $e_f \assng compound(ca)$\; \label{algTranslateDeclarationTranslateInCompound} + \uIf{$isConstraint(type(d))$}{ \label{algTranslateDeclarationTranslateConstraintDefaultStart} + $createConstraintVariableConstraint(e_d, e_f, v)$\; \label{algTranslateDeclarationConstraintVariableConstraint} + }\label{algTranslateDeclarationTranslateConstraintDefaultEnd} + \uIf{$isAnnotation(v)$}{\label{algTranslateDeclarationCreateACStart} + $ac\assng \closedCases{\IVMLMeta{acc}(d,a), & \text{if } ca = \undef \\ \IVMLMeta{acc}(ca,a), &\text{else}}$\;\label{algTranslateDeclarationTranslateAnnotationAccess} + }\uElse{ + $ac \assng \closedCases{ca, & \text{if } e_f \neq \undef \\ d, &\text{else}}$\; \label{algTranslateDeclarationTranslateUsualAccess} \label{algTranslateDeclarationTranslateSelf2} + }\label{algTranslateDeclarationCreateACEnd} + \leIf{$\IVMLself{} \in var(e_d) \vee isOverridenSlot(d)$}{$c_{e_d} \assng \deferredDefaultConstraints$}{$c_{e_d} \assng \defaultConstraints$} \label{algTranslateDeclarationTranslateSelf3} + $add(c_{e_d}, \createDefaultConstraint{\varSubstitutionSelfVarMapping{\IVML{assign}(ac, e_d)}{f}}, true, v)$\; \label{algTranslateDeclarationTranslateDefault} + }\label{algTranslateDeclarationDefaultEnd} + + \lIf{$\neg inc$} {$translateAnnotationDeclarations(d, v, \undef)$}\label{algTranslateDeclarationAnnotationDefault}\label{algTranslateDeclarationComplexStart} + $translateDerivedDatatypeConstraints(d, type(d))$\; \label{algTranslateDeclarationDerivedDatatype} + \uIf{$isCompound(t)$}{ + $translateCompoundDeclaration(d, v, ca, t, c_m)$\; \label{algTranslateDeclarationTranslateCompound} + } \uElseIf{$ isContainer(t) $}{ \label{algTranslateDeclarationHasDefault} + $translateContainerDeclaration(d, v, ca, t)$\; \label{algTranslateDeclarationTranslateContainer} + }\label{algTranslateDeclarationComplexEnd} + \caption{Translating declarations (\IVML{translateDeclaration}).}\label{algTranslateDeclaration} +\end{algorithm} + +In line \ref{algTranslateDeclarationRefinedType}, the actual type of the variable is determined, either based on the declaration, the default value expression or the actual value if defined. If $t$ is a compound type, we set in line \ref{algTranslateDeclarationTranslateSelf1} the value of self $v$ to the actual variable declaration $d$ and create the variable mapping for all slots in line \ref{algTranslateDeclarationRegisterCompound} by calling Algorithm \ref{algTranslateCompoundDeclaration}. Typically, this creates a new context frame in the variable mapping $\variableMapping$, which must be correctly cleaned up at the end of Algorithm \ref{algTranslateDeclaration}. We indicate this by the compound mode $c_m$, which is adjusted here and considered in the translation call in line \ref{algTranslateDeclarationTranslateCompound}. + +A remaining default value expression $e_d$ is turned into an assignment constraint if $d$ is not an attribute used within an assignment block (this may otherwise collide with default values defined by the assignment block). If the $v$ variable is a constraint variable, we also have to add $e_d$ to the constraint base. This is done by calling Algorithm \ref{algCreateConstraintVariableConstraint} (cf. Section \ref{sectConstraintVariables}). Then, we turn the default value expression into an assignment expression. However, the creation of the sub-expression $ac$ representing the variable $v$ technically depends on whether $d$ is a (nested) annotation or 'ordinary' variable (lines \ref{algTranslateDeclarationCreateACStart}-\ref{algTranslateDeclarationCreateACEnd}). Further, we must determine the constraint set for adding the assignment constraint (line \ref{algTranslateDeclarationTranslateSelf3}): We add the constraint to $\deferredDefaultConstraints$ if the assignment may override a previous value assignment through a complex value. This is (potentially) the case if \IVML{self} is used in $e_d$ or if $d$ is an overridden slot that may be overriden accidentally by a complex compound value. Else, we add the constraint to the set of default constraints $\defaultConstraints$. Ultimately, we create an expression assigning $e_d$ to $ac$, substitute \IVML{self} and the actual variable mapping in this assignment expression, turn the result into a default constraint and add it to the respective constraint set in line \ref{algTranslateDeclarationTranslateDefault}. + +Akin to default value expressions, orthogonal annotation declarations are only translated in full (non-incremental) reasoning mode in line \ref{algTranslateDeclarationAnnotationDefault} using Algorithm \ref{algTranslateAnnotationDeclarations}. +Finally, we translate constraints induced by the actual type of $v$. This can happen through derived, compound or container types. If $t$ is a derived data type, type-defined constraints are translated by Algorithm \ref{algTranslateDerivedDatatypeConstraints} in line \ref{algTranslateDeclarationDerivedDatatype}. If $t$ is a compound type, we call Algorithm \ref{algTranslateCompoundDeclaration} with the actual compound mode $c_m$ in line \ref{algTranslateDeclarationTranslateCompound}. If $t$ is a container type, we call Algorithm \ref{algTranslateContainerDeclaration} in line \ref{algTranslateDeclarationTranslateContainer}. + + +\subsection{Derived types}\label{sectDerivedTypes} + +As introduced in Section \ref{sectNotationDerivedTypes}, a derived datatype $t$ is defined as a restriction or an alias of its base type $base(t)$. A derived type $t$ is a type restriction of $base(t)$, if $t$ defines restricting constraints over $base(t)$ using the local variable $decl(t)$ representing $t$. Type $t$ is a type alias, i.e., a type with the same constraints as the base type but different type name, if $constraints(t) = \emptySet$. The base type of a derived type can in particular be another derived type, but, of course, also any other IVML type. If a variable $v$ is declared to be of a derived type $t$, all constraints defined for $t$ over $base(t)$ must hold for $v$. In particular, if $base(t)$ is a derived type, all constraints over all base types $allBase(t)$ of $t$ must hold transitively. Whether these constraints are fullfilled depends on the actual value of $v$. + +The constraint translation follows this chained type structure and instantiates all constraints defined along the nesting as shown in the following translation pattern. + +\grayPara{ +\begin{gather*} + \patternDerivation{\IVML{typedef } t_i \IVML{ with }(c_i); T v\IVML{;}}{\bigcup_{t_i \in allBase(T)} \varSubstitution{c_i}{decl(t_i)=deref(t_i, v), \variableMapping}} +\end{gather*} +} + +Given a variable $v$ of derived type $T$, all constraints induced by the derived type and all its base types are turned into instantiated constraints. During instantiation, we appy a substitution, which replaces the respective local variable by $v$ or an accessor expression to $v$ and, if applicable, any cross-referenced variables in $\variableMapping$. It is important to mention that just substituting the respective local variable by $v$ is not sufficient, as also reference types can be used as base type. A reference type requires then de-referencing of $v$, e.g., to permit access to the slots of a compound variable. This is indicated in the translation pattern by the function $deref(t, v)$, which either dereferences $v$ with respect to $t$ or returns $v$ if no de-referencing is needed. + +For a given variable $v$ (in terms of declaration $d$ and for technical reasons its type $t$), Algorithm \ref{algTranslateDerivedDatatypeConstraints} instantiates all constraints defined for all dereferenced transitive base types. However, we must consider whether we perform this instantiation for a container variable\footnote{The actual implementation receives the iterator variable causing the creation of the quantifier constraint and the parent model element for creating the constraints.}. If $v$ is a container variable, we create an all-quantifying constraint over all container elements, whereby the iterator variable $i$ of the quantifier substitutes $decl(t)$. If the derived type $t$ is defined based on some reference type, we must dereference the iterator variable $i$ appropriately. If $v$ is not a container variable, we substitute $decl(t)$ by the actual variable $d$. It is important to note that this substitution is transitive if $d$ is a compound slot, i.e., if $d$ is also mentioned in $\variableMapping$, the previously collected compound accessor for $d$ (in Algorithm \ref{algTranslateCompoundDeclaration}) is used to substitute $decl(t)$. The respective composite expression for $i$ is created through the function $deref(t, ex)$ shown below. The resulting constraints are stored in the set of top-level constraints $\topLevelConstraints$ as the variables in the resulting constraints are then fully qualified and in IVML derived types can only be defined on top level. % shall not make a difference for nested variables as they are already initialized + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{declaration $d$, type $t$} + \KwData{derived type constraints $\topLevelConstraints$} + $cs \assng \bigcup_{t \in deref(allBase(t))} constraints(t)$\; + \If{$isContainer(t)$}{ + $cs \assng \setWith{\createConstraint{\varSubstitutionOtherVarMapping{\IVML{forAll(i:}c\IVML{)}}{decl(t)=deref(t, i)}}}{c\in cs}$\; + }\Else{ + $cs \assng \setWith{\createConstraint{\varSubstitutionOtherVarMapping{c}{decl(t)=deref(t, v)}}}{c\in cs}$\; + } + $add(\topLevelConstraints, cs, true, \undef)$\; + \caption{Translating constraints for derived types (\IVML{translateDerivedDatatypeConstraints}).}\label{algTranslateDerivedDatatypeConstraints} +\end{algorithm} +% +The dereferencing operation\footnote{The actual implementation performs the dereferencing in an iterative manner when explicitly adding a variable mapping in addition to $\variableMapping$ to the substitution visitor.} for Algorithm \ref{algTranslateDerivedDatatypeConstraints} takes a type $t$ and a basis expression $ex$. For each reference base type in the chain of base types, it adds a call of the (internal) IVML dereferencing operation \IVML{refBy} around $ex$ or the recursively built up expression to $ex$. Other types than derived types immediately lead to $ex$ as result. +% +$$deref(t, ex)=\begin{cases} deref(base(t), ex), & \text{if } isDerived(t) \wedge \neg isReference(base(t)) \\ \IVML{refBy}(deref(base(base(t)), ex)), & \text{if } isDerived(t) \wedge isReference(base(t))\\ ex, & \text{else}\\\end{cases}$$ +% +\subsection{Compound types}\label{sectCompoundDefaults} + +For a compound variable, in IVML one can define constraints in two different ways: 1) Constraints nested within compound type definitions or sub-structures with the same scope such as annotation assignments or eval blocks. Both, unqualified slots (implicitly qualified through the containing scope) or qualified variable access expressions can be used. Nested constraints imply all-quantification over all instances of the respective compound type~\cite{IVML-LS}. 2) Top-level constraints using qualified slot access expressions only. We translate tese two ways using the following schema: + +\grayPara{ +\begin{gather*} + \patternDerivation{\IVML{compound } C \IVML{\{} T s\IVML{; } c(s)\IVML{\}; } C\ v \IVML{;}}{\varSubstitution{c(s)}{\IVML{self}=access(v), s=access(v.s),\variableMapping}}\\ + \patternDerivation{\IVML{compound } C \IVML{\{} T s \IVML{\}; } C\ v \IVML{; } c(v.s)\IVML{;}}{\varSubstitution{c(v.s)}{\variableMapping}}\\ +\end{gather*} +} + +The first pattern indicates that an IVML compound type $C$ with declared slot $s$ and contained constraint $c(s)$ over slot $s$. The translation is applied if a variable $v$ of type $T$, i.e., a concrete instance of a compound type is declared and, however, receives a value. In this case, each contained constraint is instantiated by qualifying all relevant variable occurrences, i.e., replacing \IVML{self} with the actual variable $v$, the slot $s$ with the respective qualified access $v.s$ as well as all other known variable mappings, in particular including qualified access expression known for other slots in $C$. More complex access expressions also allow for translating nested compounds. The second case indicates a top-level constraint defined over the compound variable $v$. In contrast, this translation can happen as part of translating all top-level constraints, as due to the use of only qualified slot access expressions, just the (top-level) variable mapping is relevant for the substitution. The patterns show, that in both cases, the respective variable mapping including top-level and type-level cross-reference accesses must be created before the respective translation (including annotations, to handle constraints on annotations similarly). However, compounds may contain assignment and eval blocks. Assignment blocks are discussed in Section \ref{sectAnnotationDefaults}, but mainly differ in the treatment of the default value assignments rather than the contained constraints. Constraints in eval blocks can be transformed as shown by the patterns, but require different constraint evaluation priority. Moreover, compound instances may occur in containers, which we will discuss in more detail in Section \ref{sectContainerDefaults}. We will now focus on the first pattern and discuss the respective translation Algorithm \ref{algTranslateCompoundDeclaration}. + +For slots and annotations we can resort to Algorithm \ref{algTranslateDeclaration}, i.e., compound types, derived types, constraint variables and collections, while for the remaining constraints, we must visit these structures, instantiate and collect the respective constraints. Reference types do not need specific treatment as constraints are translated for the target variable of the reference. Basic types cannot define own containers. In particular, if the IVML keyword \IVMLself{} is used within a constraint, it must be substituted by the actual variable of the respective compound type. Moreover, it is important to recall that a variable $v$ of type $type(v)$ can contain instances of any refined type $allRefines^+(t)$, and in this case the translation must consider the default values of the potentially larger slot, additional constraints and nested structures. + +Algorithm \ref{algTranslateCompoundDeclaration} collects and translates the constraints for a compound variable $v$ with declaration $d$, potential compound accessor $ca$ and (default value) type (or $type(d)$ if no default expression is defined for $d$). No translation happens if type $t$ was already processed, e.g., in case of recursive compound types. The types are related by $type(d) = type(v) \in allRefines^+(t)$. Algorithm \ref{algTranslateCompoundDeclaration} creates a context frame and pushes it onto the variable mapping stack $\variableMapping$\footnote{For optimizing constraint rescheduling (see Section \ref{sectTopLevelConstraintsRescheduling}), the algorithm applies type exclusions to the actual context by transferring them and storing the causing type $t$ in the current context}. Used types are registered only if there is no variable $v$ given, e.g., we process constraints according to a potentially recursive type structure. If a variable $v$ is given, the nested variables are initialized correctly, in particular recursively nested variables terminate correctly based on configured values, i.e., we do not have to take care of recursion in this case. + +The main two steps are detailed in Algorithm \ref{algRegisterCompoundMapping} and \ref{algTranslateCompoundContent} as both Algorithms are reused with different arguments during the translation of compounds in Section \ref{sectCompoundDefaults}. Algorithm \ref{algRegisterCompoundMapping} registers all compound slots and annotations in the variable mapping, using $ca$ or $d$ as basis for access expressions for slots and annotations and casts to the type of the actual value in $v$ if available (else $\undef$ is passed in as argument). Now Algorithm \ref{algTranslateCompoundContent} can translate the entire compound content including slots, annotations, constraints, annotation-blocks and eval-blocks. +%As the context with the compound mapping is only valid during Algorithm \ref{algRegisterCompoundMapping}, default value expressions must be translated within the actual context, i.e., if $deflt$ has been passed in, lines \ref{algTranslateCompoundSubstStart}-\ref{algTranslateCompoundSubstEnd} perform the respective substitution, which will be returned as result of Algorithm \ref{algRegisterCompoundMapping}. Finally, Algorithm \ref{algTranslateCompoundDeclaration} removes the actual context frame for this compound from $\variableMapping$. + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{declaration $d$, variable $v$, compound access $ca$, default value type $t$, mode $m$} + \KwData{constraints $\otherConstraints$, variable mapping $\variableMapping$} + + $next \assng NONE$\; + \If{$\neg alreadyProcessed(\variableMapping, t)$} { + \If{$m = ANYWAY \vee m = REGISTER$}{ + $recordProcessed(\variableMapping, t)$\; + $pushContext(\variableMapping, d, v \neq \undef)$\; + $transferTypeExcludes(\variableMapping, t)$\; + $e \assng \createExpression{d}$\; + $registerCompoundMapping(t, ca, v, e, type(value(v)))$\; + $next \assng TRANSLATE$\; + } + \If{$m = ANYWAY \vee m = TRANSLATE$}{ + $translateCompoundContent(d, v, t, ca)$\; + $popContext(\variableMapping)$; + $next \assng NONE$\; + } + } + \Return{$next$} + \caption{Translating compound declarations (\IVML{translateCompoundDeclaration}).}\label{algTranslateCompoundDeclaration} +\end{algorithm} + +Algorithm \ref{algRegisterCompoundMapping} visits all slots and annotations, creates access expressions for them and registers them with the current context frame in the variable mapping $\variableMapping$. The compound type $t_c$ indicates the type to be processed, i.e., where to take slot and annotation definitions from. The access expressions $ca$ is optional as usual and, if given, utilized as prefix to create access expressions for slots and annotations. Finally, a target type $t_t$ is given if the access via $ca_s$ or $ca_t$ requires a type cast so that specific slots of $t_t$ can be accessed. Type casts are required if if the actual value is of a refined type of $t_c$, as otherwise slots defined on the more specific type are not accessible and access is rejected by static type checking of IVML expressions. + +Let +% +$$slots^-(t) = \setWith{s \in slots(t)}{\neg isTypeExcluded(\variableMapping, type(parent(s)))} $$ +% +be the slots of $t$ for which the containing type is not excluded \footnote{Excluded types only occur as an optimization in constraint re-scheduling (cf. Section \ref{sectTopLevelConstraintsRescheduling}} in the actual context of $\variableMapping$. Algorithm \ref{algRegisterCompoundMapping} iterates over all slots accessible for the given compound type $t_c$ and creates for each slot a respective accessor. If a preceding compound access expression for the slots $ca_s$ is not given, it creates a static accessor based on $v$. If an accessor is given, we create an accessor based on $ca_s$ and include a type cast to $t_t$\footnote{The type cast can be omitted if $t=type(value(v))$. This is done by the implementation, but not detailed here as a type cast to the actual type does not have an effect.}. The created accessor is then registered with $\variableMapping$. Similarly, we iterate over all annotations for the current slot, create an accessor expression based on $ca_a$ and register the result with $\variableMapping$. + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{compound type $t_c$, acccess $ca$, variable $v$, declaration expression $e_d$ target type $t_t$} + \KwData{constraints $\otherConstraints$, variable mapping $\variableMapping$} + + \ForAll{$s \iterAssng \setWithFlat{slots(t)}{t\in allRefines^+(t_c)}$} { \label{algRegisterCompoundMappingVarMappingStart} %actual slots + $x \assng \createExpression{\closedCases{\IVMLMeta{acc}(e_d, s), & \text{if } ca = \undef \\ \IVMLMeta{acc}(\IVML{asType}(ca, t_t), s), &\text{else}}}$\; \label{algRegisterCompoundMappingVarMapping} + $registerMapping(\variableMapping, s, x)$\; + \ForAll{$a \iterAssng annotations(s)$}{ + $registerMapping(\variableMapping, a, \createExpression{\IVMLMeta{acc}(ca,a)})$\; \label{algRegisterCompoundMappingAnnotationMapping} + } + }\label{algRegisterCompoundMappingVarMappingEnd} + \ForAll{$a \iterAssng annotations^+(decl(e_d))$}{ + $x \assng \createExpression{\closedCases{\IVMLMeta{acc}(e_d,a), & \text{if } ca = \undef \\ \IVMLMeta{acc}(\IVML{asType}(ca, t_t), a), &\text{else}}}$\; \label{algRegisterCompoundMappingCreateExpression} + $registerMapping(\variableMapping, a, x)$\; % left out origins + } + + \caption{Registering the compound mapping (\IVML{registerCompoundMapping}).}\label{algRegisterCompoundMapping} +\end{algorithm} + +Given a complete mapping for a compound type, we can apply Algorithm \ref{algTranslateCompoundContent}. The algorithm performs a transitive / recursive translation of the default values of all (not excluded) slots using the respective accessor calling Algorithm \ref{algTranslateDeclaration} in line \ref{algTranslateCompoundDeclarationTranslateSlotsV} if $v$ is defined ($slots(v)$ also includes all slots for $v$\footnote{This also holds for $slots^-(v)$ if the parent type of $v$ is not excluded.}) or all 8not excluded) slots for type$t$. It is important to note that in both cases, the second occurs in container translations, we call Algorithm \ref{algTranslateDeclaration}, which dispatches for all types and also considers annotations. + +In line \ref{algTranslateCompoundDeclarationSelf}, we determine the actual expression for self, i.e., the access expression $ca$ if given or the declaration $d$. Then, due to their specific priorities, we first translate all eval constraints defined along the type hierarchy for $t$ in lines \ref{algTranslateCompoundDeclarationEvalStart}-\ref{algTranslateCompoundDeclarationEvalEnd}. Afterwards, we include all remaining compound constraints, i.e., type constraints and annotation constraints in lines \ref{algTranslateCompoundDeclarationAllStart}-\ref{algTranslateCompoundDeclarationAllEnd}. + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{declaration $d$, variable $v$, compound type $t$, access $ca$} + \KwData{constraints $\otherConstraints$, variable mapping $\variableMapping$} + + \uIf{$v\neq\undef$}{\label{algTranslateCompoundDeclarationTranslateSlotsStart} + \ForAll{$s \iterAssng slots^-(v)$} { + $translateDeclaration(s, decision(v, s), \variableMapping[s]))$\; \label{algTranslateCompoundDeclarationTranslateSlotsV} + } + } \Else { + \ForAll{$s \iterAssng \setWithFlat{slots^-(u)}{u\in allRefines^+(t)}$ } { + $translateDeclaration(s, \undef, \variableMapping[s]))$\; \label{algTranslateCompoundDeclarationTranslateSlotsT} + } + }\label{algTranslateCompoundDeclarationTranslateSlotsEnd} + \If{$\neg inc$} { + \ForAll{$a \iterAssng assignments(t)$}{ + $translateAnnotationAssignments(a, v, \undef, ca)$\; \label{algTranslateCompoundDeclarationCompoundAssignments} + } + } + \leIf{$ca \neq \undef$}{$f\assng ca$}{$f\assng d$}\label{algTranslateCompoundDeclarationSelf} +\MISSING{Register constraints for creating compound constraints (value is constraint value) }\; + $eval \assng \setWithFlat{allEvalConstraints(r)}{r\in allRefines^+(t) \text{ } \setminus \text{ } excludedTypes(t)}$\;\label{algTranslateCompoundDeclarationEvalStart} + $add(\otherConstraints, \setWith{attach(\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}, currentType(\variableMapping))}{c\in eval}, true, v)$\;\label{algTranslateCompoundDeclarationEvalEnd} + $cmp \assng \setWithFlat{allCompoundConstraints(r)}{r\in allRefines^+(t) \text{ } \setminus \text{ } excludedTypes(t)}$\;\label{algTranslateCompoundDeclarationAllStart} + $add(\otherConstraints, \setWith{attach(\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}, currentType(\variableMapping))}{c\in cmp}, true, v)$\;\label{algTranslateCompoundDeclarationAllEnd} + + \caption{Translating compound content (\IVML{translateCompoundContent}).}\label{algTranslateCompoundContent} +\end{algorithm} + +As stated above, we defer all constraint translation work to a recursive execution of Algorithm \ref{algTranslateDeclaration}. However, correctly initializing compounds can be tricky, as both, default slot values and compound initializer expressions, i.e., complex value assignments to compounds must be considered while reasoning. We solve this as follows: Algorithm \ref{algTranslateDeclaration} is triggered by a compound variable declaration. If a default value for the compound variable is defined, Algorithm \ref{algTranslateDeclaration} creates a respective constraint and then continues with the creation of the slot defaults and the compound constraints in Algorithm \ref{algTranslateCompoundContent}. Mixing both happens behind the scenes through the constraint evaluator: Assigning a value to a compound variable (or a slot) causes the creation of a compound instance with the desired values for the specified slots. The following assignment constraints for the default values are executed if no other value has been assigned (otherwise they are ignored) and finally removed by the main constraint evaluation loop in Algorithm \ref{algEvalLoop}. Dependent default values are evaluated as soon as the required variables have values assigned. + +\subsection{Container types}\label{sectContainerDefaults} + +Per se, a container variable can only declare the contained type and the respective element values through its default, i.e., there is no direct opportunity to define constraints for a container. However, constraints are indirectly defined through the contained type and the types used for the individual elements. Here, compounds, derived types, constraint types and, transitively, nested containers can introduce constraints further characterizing (the contents of) a container variable. Reference types do not need specific treatment as constraints are translated for the target variable of the reference. Basic types cannot define own containers. Due to refinement, all relevant types may be more specific than the (generic) container type given for the initial container variable. + +Containers differ from the other IVML types as a container may contain an arbitrary number of elements. Thus, for specifying a constraint over a container, we must apply all-quantification or, as an alternative, unroll the container, create constraints for the individual container entries and take care of the changes of the elements. Currently, unrolling is not possible for all IVML container types, e.g., set-based types do not offer index-based access. Thus, for the translation pattern, we generically use quantification. + +\grayPara{ +\begin{gather*} + \patternDerivation{\IVML{containerOf(}T\IVML{) } v\IVML{;}}{\bigcup_{t\in usedTypes(v), c\in constraints(t)}f(v, t)\rightarrow \IVML{forall}(w:\varSubstitution{c(x)}{x=w.x, \variableMapping})}\\ + \patternDerivation{\IVML{containerOf(}T\IVML{) } v\IVML{;} c(v)\IVML{;}}{\varSubstitution{c(v)}{\variableMapping}} +\end{gather*} +} + +There are two basic translation patterns for containers, 1) constraints induced by used types and 2) top-level constraints for collection variables. We will focus here on the first pattern, as the second pattern comes for free as part of the translation of the top-level constraints. + +As shown for the first pattern, given a container variable $v$, we consider all potential (declared) as well as used types in the actual value and create for each constraint implied by these types an all-quantified constraint over $v$. Please note that individual constraints are needed to provide detailed error messages, but also to keep the re-evaluation effort low. However, if the container is nested, i.e., $T$ is again a container over a certain type, we must take flattening into account to apply the constraints to the individual elements. Moreover, if $\subTypeOf{t}{T)}$, accessing specific properties such as compound slots requires some form of type casting / selection on the elements of the container. These additional container transformations depend on the actual container type and are represented in the schema by $f(v, t)$. For short, $f(v, t)$ turns a sequence into a set to avoid duplicated constraints, flattens a nested container and applies type selects to enable access to slots defined in refined compounds. We will detail $f(v, t)$ below in this section. Finally, the constraint must be substituted adequately, using the quantifier iterator to access the elements, including slot access expressions for compound element types as well as known access expressions to other variables and slots. + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{declaration $d$, variable $v$, access $ca$, type $t$} + \KwData{configuration $cfg$, constraint $base$, variable mapping $\variableMapping$, constraint variables $\otherConstraints$, default (deferred) constraints $\defaultConstraints$ and $\deferredDefaultConstraints$, incremental flag $inc$} + + $pushContext(\variableMapping, false)$\; + $t_n \assng nested^*(t); t_b \assng base^*(t_n); used\assng\emptySet$\; + $val\assng relevantValue(d, v, inc)$\; + \uIf{$isConstraint(t_b)$} { + $add(\otherConstraints, \setWith{\createConstraint{\varSubstitutionSelfVarMapping{e}{ca}}}{e \in allElements(val)}, true, v)$\; \label{algTranslateContainerDeclarationConstraintContainer} + } \ElseIf{$isCompound(t_b)$} {\label{algTranslateContainerDeclarationCompoundContainerStart} + \uIf{$val \neq \undef$} { + $used \assng \setWithFlat{base(u)}{u \in usedTypes(val) \wedge isContainer(base(u))}$\; \label{algTranslateContainerDeclarationUsedTypesDefault} + $used \assng used \setminus \setWithFlat{allRefines(u)}{u \in used}$\; \label{algTranslateContainerDeclarationUsedTypesPrune} + } \Else { + $used \assng \set{t_b}$\; \label{algTranslateContainerDeclarationUsedTypesFallback} + } + \ForAll{$u \iterAssng used$}{\label{algTranslateContainerDeclarationCompoundContainerDefaultsStart} + $translateCompoundContainer(d, u, t_n, ca)$\; + }\label{algTranslateContainerDeclarationCompoundContainerDefaultsEnd}\label{algTranslateContainerDeclarationCompoundContainerEnd} + % $used \assng used \setminus \setWith{allRefines(u)}{u \in used}$\; + % \lIf{$|used| = 0$}{$used \assng \set{base(contained(d))}$} + % \ForAll{$u \iterAssng used$} {\label{algTranslateContainerDeclarationCompoundContainerUsedCompoundsStart} + % $add(\otherConstraints, translateCompoundContainer(u, t_n, d, ca), true)$\; + % }\label{algTranslateContainerDeclarationCompoundContainerUsedCompoundsEnd} + } + \uIf{$isDerived(t_n)$}{ + $translateDerivedDatatypeConstraints(t_n, d)$\; \label{algTranslateContainerDeclarationDerivedTypes} + } + $popContext(\variableMapping)$\; + \caption{Translating declaration default value expressions to constraints (\IVML{translateContainerDeclaration}).}\label{algTranslateContainerDeclaration} +\end{algorithm} + +We detail now the generic translation schema, i.e., the function $f(v, t)$ mentioned above by using the IMVL \IVML{flatten} and the \IVML{selctByKind} operations: Let $d$ denote the variable declaration containing the compound (may alternatively be a compound or container accessor). The \IVML{flatten} resolves all nested containers and implicitly provides access even to deeply nested container entries. \IVML{selectByKind} is needed if we translate for slots of a specific given type $t$ with $\subTypeEqOf{t}{s}$, as otherwise the slots defined on specific types are not accessible. Finally, we apply an all quantor over the elements of the collection using the temporary iterator variable $l$ to the respective constraint $c$ after appropriate variable substitution, in particular replacing \IVMLself{} by $l$. +% +\begin{displaymath} +d\rightarrow \underbrace{\IVML{flatten()}\rightarrow}_{\text{if nested}}\underbrace{\IVML{selectByKind}(t)\rightarrow}_{\text{if } \subTypeOf{t}{nested^*(c)}}\IVML{forAll}(l:c(l)) +\end{displaymath} +% +Thus, the core idea of this algorithm is to consider all elements over all used types. If no value is available, we resort to the static type of the declaration of the containser variable. We create all-quantized constraints for all used types and distinguish between constraint containers, where the values directly turn into constraints, compound containers, where slots, constraints and annotations lead to further constraints, and derived types. + +Algorithm \ref{algTranslateContainerDeclaration} performs the transformation for a container variable declaration $d$ of variable $v$, if nested with given access expression $ca$ and specific type $t$ (due to a known default value). However, if $isCompound(t)$ and $t$ is also recursively used as slot type, Algorithm \ref{algTranslateContainerDeclaration} may cause an endless recursion. Thus, we translate constraints for $t$ only if $t$ was not already processed as flattening of the container elements used below requires considering each used type exactly once. + +For translating constraints, we first determine the innermost nested type $t_n$ and its base type $t_b$ (i.e., ignoring intermediate derived types) as well as the relevant value $val$. If $v$ is a constraint container, i.e., the innermost nested base type is a constraint, we collect and translate all constraints constituted by all (flattened) element values in line \ref{algTranslateContainerDeclarationConstraintContainer}. If $v$ is a compound container, i.e., the innermost nested base type is a compound, we consider the used types. If there is a value, we determine the used contained compound types in line \ref{algTranslateContainerDeclarationUsedTypesDefault} and prune more general refined types in line \ref{algTranslateContainerDeclarationUsedTypesPrune}, as the following algorithm must anyway iterate over the refinement hierarchy. If there is no value, the only used type is the innermost nested base type $t_b$, actually a compound (line \ref{algTranslateContainerDeclarationUsedTypesFallback}). The, we iterate over all (pruned) used types and apply Algorithm \ref{algTranslateCompoundContainer}. Independently of constraint or compound container, we finally translate and collect all constraints stemming from derived type definitions in line \ref{algTranslateContainerDeclaration}. + +Algorithm \ref{algTranslateCompoundContainer} creates constraints for compound values utilized in compounds, e.g., through a container initialize, in IVML like \IVML{seq = \{\{i=1\}, \{i=2\}\}}, assuming that \IVML{seq} is a sequence of compounds, which have an integer slot \IVML{i}. As these compounds are created implicitly within a container initializer, so far no default value constraints, nested constraints, annotation assignments etc. are scheduled to the constraint base, i.e., these compounds would remain uninitialized and their constraints not considered. + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{declaration $d$, (specific) type $t$, declared type $u$, access $ca$, mode $m$} + \KwData{deferred default constraints $\deferredDefaultConstraints$} + + \If{$\neg alreadyProcessed(\variableMapping, t)$}{ + $recordProcessed(\variableMapping, t)$\; + + $l\assng \createExpression{\IVMLMeta{var}(t)}$\; + + $e\assng\closedCases{ca, & \text{if } ca \neq \undef\\\createExpression{d}, &\text{else}}$\; \label{algTranslateDefaultsCompoundContainerInitE} + \uIf{$isSequence(type(d))$} { + $e\assng\createExpression{\IVML{asSet}(e)}$\; \label{algTranslateDefaultsCompoundContainerAsSet} + } + \uIf{$isNested(type(d))$} { + $e\assng\createExpression{\IVML{flatten}(e)}$\; \label{algTranslateDefaultsCompoundContainerFlatten} + } + \uIf{$u\neq t$} { + $e\assng\createExpression{\IVML{selectByKind}(e, t)}$\; \label{algTranslateDefaultsCompoundContainerCast} + } + + $pushContext(\variableMapping, \undef, e, l, true)$\; + $registerCompoundMapping(t, l, \undef, d, t)$\; \label{algTranslateDefaultsCompoundContainerMapping} + + $translateCompoundContent(l, \undef, t, \closedCases{\undef, & \text{if } ca = \undef\\l & \text{else}})$\; \label{algTranslateDefaultsCompoundContainerContent} + $popContext()$\; + } + \caption{Translating constraints for compound containers (\IVML{translateCompoundContainer}).}\label{algTranslateCompoundContainer} +\end{algorithm} + +Algorithm \ref{algTranslateCompoundContainer} targets this by creating all-quantized constraints over all elements of the container, mostly be reusing Algorithm \ref{algRegisterCompoundMapping} to create a compound mapping and Algorithm \ref{algTranslateCompoundContent} to translate the compound content. Initially, we a local variable $l$ as later iterator variable for the quantifier expressions. Then, we create a prefix expression $e$ of the quantor constraint expression, i.e., we determine in line \ref{algTranslateDefaultsCompoundContainerInitE} the access expression to the collection either using $ca$ or just holding the variable of the container $d$. If the container is a sequence that may contain duplicates, we first turn it into a set to avoid accidentally duplicated constraints (line \ref{algTranslateDefaultsCompoundContainerFlatten}). If the container is nested, we flatten it in line \ref{algTranslateDefaultsCompoundContainerFlatten} as constraints only need to be created for the elements (no specific constraints can be attached to a container type except for derived values, which are handled by Algorithm \ref{algTranslateDeclaration}). If the actual type $t$ is not the same as the type of the declaration $u)$, we must consider that the slot $s$ only exists for the specific refined type $t$. Then, the instantiation shall apply only to container elements of type $t$ (or of refined types), i.e., we insert in line \ref{algTranslateDefaultsCompoundContainerCast} an element selection by projecting the container to all elements of type $t$ (and refined types). + +Now we create a context for the container on the stack of $\variableMapping$. In contrast to compound translations, we also register the prefix expression $e$ and the iterator variable $l$. This will be taken up by the $add$ operation, which completes the full constraint from the given information on the stack, i.e., the full creation of the constraint is prepared but not shown in Algorithm \ref{algRegisterCompoundMapping}. As for compounds, we create now the compound mapping using Algorithm \ref{algRegisterCompoundMapping}. Please note that slot access now happens via the iterator variable $l$, while annotation access happens through $ca$. Specifying $t$ also as target type avoids unnecessary type casts here. Then, we call Algorithm \ref{algTranslateCompoundContent} to translate the compound slots, implying translation of annotations as well as recursion over further compounds and containers. Thereby, we replace a given access expression by the iterator variable $l$ or leave the access undefined as it is implicity given in and used from the actual context. + +By storing constraint information on the stack of $\variableMapping$ and assembling the information in one place, we can even handle recursive compound containers, which leads to a recursive creation of constraints. The formula below indicates the constraint that we must create in case of a compound container nested into a compound container. +% +\begin{displaymath} +\underbrace{\underbrace{ca}_{1: ca}\rightarrow \IVML{flatten}}_{1:e}\rightarrow\IVML{forAll}(\underbrace{l}_{1:l}:\underbrace{\underbrace{l.s}_{2: ca}\rightarrow\IVML{flatten}}_{2:e}\rightarrow\IVML{forAll}(\underbrace{l_2}_{2:l}:c(l_2))) +\end{displaymath} +% +In the first iteration, we start with $ca$ (indicated by $1:ca$, may also be some $d$) and append flatten/typeSelect as needed to form $e$ (indicated by $1:e$, i.e., recursion level and parameter/variable name). In the first iteration, we also create a temporary variable $l$ as iterator variable. We store $l$ and $e$ on the stack of $\variableMapping$ and pass $l$ on as accessor to the translation of compound content in Algorithm \ref{algTranslateCompoundContent}. There, we create an accessor for a slot, let's say $s$, i.e. $l.s$, which is then passed on in line \ref{algTranslateCompoundDeclarationTranslateSlotsV} or \ref{algTranslateCompoundDeclarationTranslateSlotsT}, respectively, to the translation of declarations in Algorithm \ref{algTranslateDeclaration}. As a further compound container is nested into the initial compound container, we end up again in Algorithm \ref{algTranslateCompoundContainer}. Now $l.s$ is considered as accessor (indicated by $2:ca$), flatten(typeSelect are added as needed to form $e$ (now $2:e$), which is stored along with the temporary iterator variable $l_2$ on the stack. In this context, we apply the constraint $c$ within an all-quantor (after appropriate variable substitution, in particular \IVMLself{} by $l_2$). The quantor expressions for completing the full constraint are created by the $add$ algorithm (details in Section \ref{sectContainerBase}). + +Let us assume that $stack(\variableMapping)$ returns the contex frames of the stack starting with the top frame, $container(s)$ returns the container expression assigned to context frame $s$ and $iterator(s)$ the iterator variable for $s$. The, Algorithm \ref{algComposeExpression} creates a constraint of the form shown above inside out, starting with $c$ after correct variable substation. For each stack element that has a container (we assume also an iterator variable) assigned, which is not the case for context frames created for compounds, we surround the actual $c$ by an all-quantor, running over $container(s)$ using $iterator(s)$ as iterator variable and $c$ as quantor expression. + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{constraint $c$} + \KwOut{composed constraint $c$} + \KwData{variable mapping $\variableMapping$} + + \ForAll{$s \iterAssng stack(\variableMapping)$} { + \If{$container(s) \neq \undef$} { + $c \assng \createExpression{container(s)\rightarrow\IVML{forAll}(iterator(s):c)}$\; + } + } + \Return $c$\; + \caption{Composing constraints from $\variableMapping$ (\IVML{composeExpression}).}\label{algComposeExpression} +\end{algorithm} + +Utilizing quantor constraints here implies that default initializations, which remain undefined if some dependent variables have not been determined so far, cause a re-evaluation for all elements of the container. Here, unfolding the implicit loop of such a quantor may be a solution, as then only individual constraints are triggered. However, this only works for sequences, as sets do not provide element-wise/index-based access and unfolding the constraint for a large container also may create a huge number of constraints. Currently, we stay with the compromise of creating a single quantized constraint for all slots with default values. + +\subsection{Annotations}\label{sectAnnotationDefaults} + +In IVML, annotations are orthogonal typed variables that can be attached to a variable. For all those orthogonal variables, the reasoner must create constraints to perform the evaluation and assignment of the default values before all other constraints are considered for reasoning. It is important to recall that IVML annotations are not recursive~\cite{IVML-LS}, although the reasoner algorithms could support this. Moreover, we must translate assignment-blocks, i.e., blocks assigning specific values to all variables declared within that block. In this section, we discuss first the translation of annotations, then the translation of annotation blocks. + +The first transformation pattern for the direct translation of annotations is the second pattern from Section \ref{sectTranslationDeclarationTypesDefaults}. More specifically, Algorithm \ref{algTranslateDeclaration} from \ref{sectTranslationDeclarationTypesDefaults} calls the algorithms in this section, which in turn call Algorithm \ref{algTranslateDeclaration}, i.e., the algorithms here prepare the application of Algorithm \ref{algTranslateDeclaration} by composing specific accessor expressions. The second pattern relates to annotation blocks, i.e., specific assignment constraints (accessor expression $ca$ is determined by the top-level or compound context of the annotation block) is created for the variables declared in the assignment block for values mentioned in the assignment data (clause). It is important to note that annotation blocks may be nested in order to indicate orthogonal annotations, i.e., the constraint translation must take this nesting and the respective precedence of the assignment data due to their nesting into account. + +\grayPara{ +\begin{gather*} + \patternDerivation{\IVML{annotate } a = deflt \IVML{ to } *\IVML{;} T \text{ } v\IVML{;}}{ca.v.a = deflt}\\ + \patternDerivation{\IVML{assign (} a = deflt \IVML{) to \{} T v \IVML{ assign} \ldots \IVML{\}}}{ca.v.a = deflt \ldots} +\end{gather*} +} + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{declaration $d$, variable $v$, compound access $ca$} + \KwData{constraints $\otherConstraints$} + + $ca\assng \closedCases{d, & \text{if } ca = \undef \\ ca, &\text{else}}$\;\label{algTranslateAnnotationDeclarationsCa} + \uIf{$v \neq \undef$}{\label{algTranslateAnnotationDeclarationsTranslateVStart} + \ForEach{$a\in annotations(v)$}{ + $ac\assng \closedCases{\IVMLMeta{acc}(ca,a), & \text{if } qualifyAnnotation(v, a, ca)\\ ca, &\text{else}}$\; + $translateDeclaration(decl(a), a, ac)$\;\label{algTranslateAnnotationDeclarationsTranslateDeclV} + } + }\Else{\label{algTranslateAnnotationDeclarationsTranslateVEnd}\label{algTranslateAnnotationDeclarationsTranslateDStart} + \ForEach{$a\in annotations(d)$}{ + $ac\assng \closedCases{\IVMLMeta{acc}(ca,a), & \text{if } qualifyAnnotation(v, a, ca)\\ ca, &\text{else}}$\; + $translateDeclaration(a, \undef, ac)$\;\label{algTranslateAnnotationDeclarationsTranslateDeclD} + } + }\label{algTranslateAnnotationDeclarationsTranslateDEnd} + +%isContextsRegistering(\variableMapping) + + \caption{Translating annotation defaults (\IVML{translateAnnotationDeclarations}).}\label{algTranslateAnnotationDeclarations} +\end{algorithm} + +with +% +\begin{align*} +qualifyAnnotation(v, a, & ca) = ca \neq \undef \wedge \neg isContextRegistering(\variableMapping) \wedge \\ &(size(\variableMapping) > 1 \vee isCompound(base^*(type(v)))) +\end{align*} +% +which requests creating an extended accessor expression if we are translating a nested annotation block (implying context registering) or if we are translating an annotation of a compound type. + +Algorithm \ref{algTranslateAnnotationDeclarations} receives the declaration of the actual variable and a potential compound access expression $ca$ to $d$ if the algorithm is called for slots of a compound value. The actual access expression is either $ca$ if given or $d$ if $ca$ is not given (line \ref{algTranslateAnnotationDeclarationsCa}). Annotations are translated based on $v$ if given (lines \ref{algTranslateAnnotationDeclarationsTranslateVStart}-\ref{algTranslateAnnotationDeclarationsTranslateVEnd}), for configuration initialization also based on $d$ if $v$ is not given (lines \ref{algTranslateAnnotationDeclarationsTranslateDStart}-\ref{algTranslateAnnotationDeclarationsTranslateDEnd}). + +For all annotations of $v$ +%(as for $v$ here all inherited annotations are available) +, the algorithm creates the respective constraints by creating a specific access expression according to $qualifyAnnotation(v, a, ca)$ through calling Algorithm \ref{algTranslateDeclaration}. For top-level annotation assignments , no specific access expressions except for the one created in line \ref{algTranslateAnnotationDeclarationsCa} are needed, as they are created in Algorithm \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateAnnotationAccess}. + +We turn now to the translation of annotation assignment-blocks. In IVML, an assignment-block is used on top-level or within compounds to declare compound slots with an implicit assignment of a value to each declared annotation. Further, assignment-blocks can be nested and the assignments defined for the outer blocks must be applied also to the inner blocks. + +The translation of assignment-blocks on top-level is triggered by Algorithm \ref{algTranslateConstraints} in line \ref{algTranslateConstraintsTopLevelAnnotationAssignments}. The translation of assignment-blocks within compounds is caused by Algorithm \ref{algTranslateCompoundDeclaration} in line \ref{algTranslateCompoundDeclarationCompoundAssignments} (variable mapping in Algorithm \ref{algRegisterCompoundMapping} line \ref{algRegisterCompoundMappingVarMapping} and slot translation in line \ref{algTranslateCompoundDeclarationTranslateSlotsV} or \ref{algTranslateCompoundDeclarationTranslateSlotsT} in Algorithm \ref{algTranslateCompoundDeclaration} along with the decision variables of the compound value). In both cases, Algorithm \ref{algTranslateAnnotationAssignments} is called. + +Algorithm \ref{algTranslateAnnotationAssignments} first builds up (incrementally) the set of effective assignments data $ea$ that is relevant for the actual assignment-block $a$ (initially $ea=\emptySet$ for a top-level assignment-block). However, only the innermost assignment is relevant in case of nested assignment blocks~\cite{IVML-LS}, so that we build a mapping based on the annotation names overriding assignments inherited from the containing assignment blocks. +For a given assignment-block $a$, the algorithm performs then the transformation of each individual assignment and collects the created constraints in $\otherConstraints$. If the type of the slot (if available the dynamic type of the value) is a compound, the algorithm performs the same transformation on all compound slots with respective accessors (either using the slot variable $d$ or the compound accessor $ca$ if given). It is important to note that we temporarily activate a context frame of $\variableMapping$ for each declaration $d$ if a context has been created/registered before during compound translation. This is required as the constraints are actually created after the translation of the types and otherwise we would still use the original variables specified in the model rather than the instantiated ones needed for reasoning. Finally, the algorithm recursively processes contained assignment-blocks. + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{assignment-block $a$, variable $v$ effective assignment data $ea$, compound access $ca$} + \KwData{constraints $\otherConstraints$} + + $ea \assng ea \addMap \setWith{\mapEntry{name(a)}{a}}{a \in assignmentData(a)}$\; + \ForAll{$\mapEntry{n}{e} \iterAssng ea$}{ + \ForAll{$d \iterAssng slots(a)$} { + $activate(\variableMapping, d)$\; + $add(\otherConstraints, \set{translateAnnotationAssignment(e, d, ca)}, false, \undef)$\; + $t \assng type(d)$\; + $ac \assng \closedCases{ + \createExpression{\IVMLMeta{acc}(ca, d)}, & \text{if } ca \neq \undef \\ + \createExpression{\IVMLMeta{acc}(\IVMLMeta{var}(decl(v)), d)}, & \text{if } var \neq \undef \\ + \createExpression{\IVMLMeta{var}(s)}, & \text{else} + }$\; + \If{$v \neq \undef$}{ + $w \assng nested^*(v, name(d))$\; + \uIf{$n \neq \undef \wedge\text{ } value(w) \neq \undef$} { + $t \assng type(value(w))$\; + } + } + \If{$isCompound(t)$} { + \ForAll{$s \iterAssng slots(t)$} { + $add(\otherConstraints, translateAnnotationAssignment(e, s, v, \createExpression{\IVMLMeta{acc}(a, s)}), false, \undef)$\; + } + } + $deactivate(\variableMapping, d)$\; + } + } + + \ForAll{$b \iterAssng assignments(a)$} { + $translateAnnotationAssignments(b, ea, ca)$\; + } + + \caption{Translating annotation assignments (\IVML{translateAnnotationAssignments}).}\label{algTranslateAnnotationAssignments} +\end{algorithm} + +Algorithm \ref{algTranslateAnnotationAssignments} relies on the translation of an individual assignment data object. The translation of a single assignment from an assignment data $a$ leads to the creation of an assignment constraint as shown below. If a compound accessor $ca$ is given, the annotation is accessed through $ca$ and the respective annotation defined for the given variable declaration $d$ through ($annotation(d, name(a))$. If no accessor is given and the declaration $d$ is not in the variable mapping $\variableMapping$, $d$ is taken as accessor, else the actual accessor in $\variableMapping$. The accessor is used as the left side of an IVML assignment, the right side (value) is made up of the default value expression given by the assignment data $a$. + +\begin{align*} + translate&AnnotationAssignment(a, d, ca) = \\ + \createConstraint{\varSubstitutionSelfVarMapping{\IVML{assign}&(\IVMLMeta{ann}(\closedCases{ca, & \text{if } ca \neq \undef\\ d, & \text{if } ca = \undef \wedge \text{ }vm[d] = \undef \\ vm[d] &\text{else}}, \\ + &findAnnotation(d, name(a))), default(a))}{ca}} +\end{align*} + +\subsection{Constraint variables}\label{sectConstraintVariables} + +In IVML, the type \IVML{Constraint} exists, which allows defining variables, compound slots or containers of constraints. As for usual variables, the value of such a constraint variable can change unless frozen, i.e., the configuration process can influence the actual set of constraints to be checked on an IVML model. The important difference in translating + +There are four basic translation patterns, three are shown below. The basic idea is to translate the (default) value, a constraint expression, directly into a constraint performing appropriate variable substitutions. For constraint containers, we translate the element values, which represent constraint expressions. If either pattern is nested within a compound (not shown for constraint containers below), the translation substitution must particularly replace \IVML{self} by the actual compound variable. + +\grayPara{ +\begin{gather*} + \patternDerivation{\IVML{Constraint } v = ex\IVML{;}}{\varSubstitution{ex}{\variableMapping}}\\ + \patternDerivation{\IVML{containerOf(Constraint)} v = \IVML{\{}ex_1 , \ldots, ex_n\IVML{\}}\IVML{;}}{\varSubstitution{ex_1}{\variableMapping}, \ldots, \varSubstitution{ex_n}{\variableMapping}}\\ + \patternDerivation{\IVML{Compound } C = \IVML{ \{Constraint } s = ex \IVML{\}}\IVML{; } C v\IVML{;}}{\varSubstitution{ex}{\IVML{self}=v, \variableMapping}} +\end{gather*} +} + +In more details, Algorithm \ref{algCreateConstraintVariableConstraint} translates a constraint (if not undefined, including the IVML \IVML{null} case, i.e., a de-configured constraint variable). Algorithm \ref{algCreateConstraintVariableConstraint} creates constraints through variable substitution with $\variableMapping$ and, if available, a respective value for \IVMLself (here $f$), turning the resulting expression into a constraint and adding it to the set of other constraints $\otherConstraints$. Moreover, the relationship between the underlying variable $v$ and the constraint must be recorded for efficient update of the constraint base upon value change (cf. Algorithm \ref{algVarChange}). + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{constraint expression $c$, actual value for \IVMLself{} $f$, variable $v$} + \KwData{other constraints $\otherConstraints$} + \If {$c \neq \undef$} { + $c \assng \createConstraintConstraint{\varSubstitutionSelfVarMapping{c}{f}}$\; + $add(\otherConstraints, \set{c}, \neg isConst(c), v)$\; + $registerConstraint(v, c)$\; + } + \caption{Creating constraints for constraint variables (\IVML{createConstraintVariableConstraint}).}\label{algCreateConstraintVariableConstraint} +\end{algorithm} + +It is important to note that the constraint translation for collection leads to quantor expressions for initializing constraint variables. This is per se dangerous, as due to the variable substitutions, a constraint acting as a value may then relate to the quantor iterator variable(s). Evaluating such a constraint leads to undefined expressions, as the iterator variables are unbound and shall be substituted by appropriate variables (in most cases \IVMLself{}). When utilizing quantor expressions, defining individual substitutions based on the involved instances does not work (as this is the purpose of the quantor). So one solution is to unfold the implicit loop as discussed in Section \ref{sectContainerDefaults}. However, as quantor expressions over variable assignments are valid IVML and may be utilized in a model, the reasoner and the constraint evaluation must be able to work with them anyway. + +As solution, we perform the variable replacement when changing the constraint value, i.e., during constraint re-scheduling (Section \ref{sectTopLevelConstraintsRescheduling}). For short, we utilize the quantor expressions as discussed in this section, during quantor evaluation we register also the temporary iterator variables in the actual context, let the quantor evaluation assign the constraints to the variables, and consider this dynamically modified context during constraint re-scheduling. Constraint re-scheduling is anyway notified about the variable change and utilized to replace the old constraint by the new one in the constraint base. Thereby, we perform a variable substitution to bind the constraint to the actual variable taking into account the actual context including the iterator variables, i.e., we accept a temporary inconsistent constraint with unbound variables for the short time between assigning the constraint variable value and the directly subsequent constraint re-scheduling for this value change. However, this finally corrected constraint must be stored in the configuration so that saving the configuration can happen with the actual (consistent) constraint. + +\subsection{Constraint base operations}\label{sectContainerBase} + +In this section, we detail specific support operations to create and maintain the constraint based, most notably the $add$ function\footnote{\IVML{addConstraint} in the implementation, in this document $add$ for short due to layout reasons.}, which we used throughout this document to describe the individual translation algorithms. Besides adding a constraint $c$ to a given constraint sequence $s$, the $add$ function performs several important operations: + +\begin{itemize} + \item It filters out irrelevant constraints, in particular simple (default value) assignment constraints during incremental reasoning, are assumed to be already processed during previous iterations. Also constraints with all variables frozen or local (used for iterator variables in quantors) are filtered out ($isFrozen(c)$) if enabled, e.g., to speed up runtime reasoning. + \item It serves as the central place to finally compose constraints for nested compound containers using Algorithm \ref{algComposeExpression} and the variable mapping $\variableMapping$. + \item It analyzes the given constraint $c$ for the use of compound or container initializers. As explained above, these structures only occur in value assignments and actually must be analyzed for constraint variables, which must be turned into individual constraints. We perform this through the two recursive helper operations for expressions $checkContainerInitializer$ and $checkCompoundInitializer$ and two similar helper functions for values $checkContainerValue$ and $checkCompoundValue$ shown below\footnote{The implementation utilizes a visitor for this purpose.}. + \item Appends the constraint to the given sequence, except for constraints from eval-blocks, which are prepended to the sequence of top-level constraints $\topLevelConstraints$ if the target sequence is other $\otherConstraints$ or top-level constraints $\topLevelConstraints$ in order to enforce the priority of eval-constraints. + \item Registers the constraint with its used variables to enable re-scheduling of constraints during reasoning in Algorithm \ref{algVarChange}. +\end{itemize} + +Thus, the functiondoes not only add a given constraint, it completes it and scans it for further contained constraints. Let $ex$ be a constraint expression. Then we have to consider two specific assignment operations not transformed so far. + +\grayPara{ +\begin{gather*} + \patternDerivation{v = \IVML{\{}\ldots, ex,\ldots\IVML{\}}}{\ldots, \varSubstitution{ex}{\variableMapping}, \ldots}\\ + \patternDerivation{v = \IVML{\{} s = ex \IVML{\}}}{\varSubstitution{ex}{\IVML{self}=v, \variableMapping}} +\end{gather*} +} + +When unconditionally assigning a value to a variable, the right side may be a complex expression determining the actual value of a collection or a compound. In both cases, the contained values may be constraint values (not handled in \ref{sectConstraintVariables}), but also deeply nested values may be constraint values, e.g., a constraint value in a compound in collection used in a compound. These constraints contribute to the initial constraint base and may cause certain value changes that cannot just be achieved as a consequence of changing values in constraint re-scheduling (cf. Section \ref{sectTopLevelConstraintsRescheduling}). As the $add$ function is also called as part of re-scheduling, dynamic constraints discovered there and their initializers and values are treated similarly. + +\begin{algorithm}[H] + \KwIn{constraint sequence $s$, constraint $c$, perform initializers $check$, variable $v$} + \KwData{top level and other constraints $\topLevelConstraints, \otherConstraints$, variable mapping $\variableMapping$, relevant constraints $\relevantConstraintsPerDeclaration$ , incremental flag $inc$, evals flag $inEvals$} + $c = composeExpression(\variableMapping, c)$\; + \If{$check$}{ + \ForAll{d\iterAssng check(rightSide(c), \variableMapping)} { + $createConstraintVariableConstraint(d, \undef, \undef)$\; + } + $e\assng check(rightSide(c), \variableMapping)$ + $add(\otherConstraints, e, const(e) \neq \undef, v$\; + } + \If{$\closedCases{\neg isAssignment(c) \vee \neg isFrozen(c) & \text{if } inc\\ true & \text{else}}$}{ + \If{$inEvals \wedge (s=\otherConstraints \vee s = \topLevelConstraints)$} { + $\topLevelConstraints = c \addSeq \topLevelConstraints$\; + }\Else{ + $s \assng s \addSeq c$\; + } + \If{$\neg isSimpleConstraint(c)$}{ + $\relevantConstraintsPerDeclaration \assng \relevantConstraintsPerDeclaration \cup \setWith{\mapEntry{w}{c}}{w\in variables(c)}$\; % assignConstraintsToVariables + } + } + \caption{Adds a constraint to the constraint base ($add$).}\label{algAddConstraint} +\end{algorithm} + +To identify constraint variable values in containers and compounds, we define the following helper function: +\begin{align*} +check&(c, \variableMapping) =\\ + &\seqWith{\closedCases{check(e, \variableMapping), & \text{if } isContainerInitializer(e) \\ + check(e, \variableMapping), & \text{if } isContainer(type(e)) \\ + check(e, \variableMapping) & \text{if } isCompoundInitializer(e) \\ + check(e, \variableMapping) & \text{if } isCompound(type(e)) \\ + \createConstraintConstraint{\varSubstitutionVarMapping{e}}, &\text{if } isConstraint(e) \\ + \createConstraintConstraint{\varSubstitutionVarMapping{value(e)}}, &\text{if } isConstraintValue(e) \\ + \createConstraintConstraint{e}, &\text{if } Boolean(e) \\ + \emptySet, &\text{else} + }}{e\in expr(c) \cup elements(c)} +\end{align*} +The function $check$ either iterates over the constituting expressions if $c$ is a container or compound initializer or the contained values if $c$ is a container or compound value\footnote{Technically, we must make the distinction between initializer and constraint, as the IVML object model supports both types of elements here and the IVML parser creates a value if all contained elements are constant or otherwise an initializer expression}. If the contained element $e$ is a further container or compound initializer / iterator, then we continue iterating through recursion. If $e$ is a constraint expression (from an initializer), we apply the actual variable substitution and create a respective constraint. Similarly, for a constraint value $e$ obtained from a container or compound value. Finally, in case of container or compound values, we may have boolean constants, which can simply be turned into a constant constraint. + +%\begin{algorithm}[H] +% \KwIn{constraint sequence $s$, constraint sequence $c$, perform initializers $check$} +% \KwData{variable mapping $\variableMapping$} +% \ForAll{$d \iterAssng c$} { +% $add(s, d, c)$\; +% } +% \caption{Records and analyzes a constraint sequence.}\label{algAddConstraints} +%\end{algorithm} + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{variable $v$, constraint expression $c$} + \KwData{other constraints $\otherConstraints$, relevant constraints $\relevantConstraintVariables$}, relevant constraints copy $base_{\relevantConstraintVariables}$ + + \If{$v \neq \undef$}{ + $\relevantConstraintVariables \assng \relevantConstraintVariables \addMap \mapEntry{c}{v}$\; + $\relevantConstraintVariables[v] \assng \relevantConstraintVariables[v] \cup \set{c}$\; + \If{$base_{\relevantConstraintVariables} \neq \undef$} { + $base_{\relevantConstraintVariables} \assng base_{\relevantConstraintVariables} \addMap \mapEntry{c}{v}$\; + $base_{\relevantConstraintVariables}[v] \assng base_{\relevantConstraintVariables}[v] \cup \set{c}$\; + } + } + + \caption{Registering constraints originating fom constraint variables (\IVML{registerConstraint}).}\label{algRegisterConstraint} +\end{algorithm} +% +Recording happens only if $v$ is defined, which may not be the case if this algorithm is called while processing container values. Then, we recorder the relation of the variable $v$ to its Index: /reasoner/evaluation.tex =================================================================== --- /reasoner/evaluation.tex (revision 144) +++ /reasoner/evaluation.tex (revision 144) @@ -0,0 +1,12 @@ +\section{Evaluation}\label{sectEvaluation} + +\TBD{Keep or remove that section. However, some basic performance evaluations should not be so difficult. All executions need multiple runs, in particular to even out JIT compilation. It seems that this is done during/after the second reasoning run. Potential topics: + +\begin{itemize} + \item Artificial models of some size/variable/constraint ratio. Christian had a generator for that and Roman typically did some evaluations using these models. Compare to known results where available. + \item QualiMaster full, incremental, runtime reasoning (full, no defaults, no frozen, reuse constraint base). Runtime vs. full reasoning seems to behave rather linearly, at around 23 constraints evaluated per ms. Compare to known results where available. + \item All test cases involving reasoning as an overview map. + \item Eclipse 4.7/Java9 runs tests with asserts!!! +\end{itemize} + +} Index: /reasoner/introduction.tex =================================================================== --- /reasoner/introduction.tex (revision 144) +++ /reasoner/introduction.tex (revision 144) @@ -0,0 +1,18 @@ +\section{Introduction} + +In Product Line Engineering, a \emph{variability model} defines the options to customize a software system, while a \emph{configuration} specifies the choices made for a specific instance / product of the product line. Customization options can depend on each other, e.g., the choice made for an option determines, restricts or even excludes the selection for another customization option. Such dependencies are typically expressed using different forms of \emph{constraints}. For instantiating a software system, a configuration must be valid, i.e., all (relevant) constraints must be fulfilled. To analyze a configuration for validity, for figuring out the number of remaining configuration options or for propagating derivable values, various forms of \emph{reasoning mechanisms} are utilized, such as SAT-solvers in~\cite{BakDiskinAntkiewicz+16, BenavidesTrinidadRuiz-Cortes05, MendoncaBrancoCowan09} or SMT-reasoners in~\cite{BakDiskinAntkiewicz+16}. For some models, specific forms of reasoning were even shown to be efficient, e.g., SAT-solving on feature models~\cite{MendoncaWasowskiCzarnecki09}. However, the expressiveness of the modeling concepts affect the analyzability of the model~\cite{EichelbergerKroeherSchmid13}, and, thus, limit also the feasibility of applying (existing) reasoning mechanisms. + +Besides traditional variability modeling approaches, such as feature modeling~\cite{CzarneckiHelsenEisenecker05, KangCohenHess+90} or decision modeling~\cite{CzarneckiGruenbacherRabiser+12, SchmidJohn04}, in recent time several approaches with more powerful modeling concepts have been proposed, e.g., supporting non-Boolean variability, sets of variabilities or advanced types of constraints, e.g., first-order logic. One rather popular form of approaches is textual variability modeling, as analyzed in more details in~\cite{EichelbergerSchmid15a}. Such more powerful modeling approaches require also adequate reasoning mechanisms, while the expressiveness of modeling concepts trades off with analyzability~\cite{EichelbergerKroeherSchmid13}. For short, typically more powerful modeling concepts imply limitations of the analysis capabilities, e.g., non-Boolean configuration options typically prevent determining the actual number of possible configurations (in contrast to the number of configuration options that remain to be configured to achieve a complete configuration). + +The \emph{Integrated Variability Modeling Language (IVML)}~\cite{IVML-LS} is a textual variability modeling language providing rather powerful modeling concepts, among them a type system inspired by object-orientation, multiple-inheritance, container types, configuration references, imports, orthogonal annotations (e.g., for binding times), quantification constraints, or user-defined constraint functions. The core idea of IVML is to represent a variability, i.e., a configuration option, as a typed variable. IVML even allows for modeling topological variability, i.e., configuring and reasoning over graph structures~\cite{EichelbergerQinSizonenko+16}. + +In this document, we discuss the approach and the design of the reasoning mechanism for IVML as well as its realization in EASy-Producer~\cite{EichelbergerEl-SharkawyKroeher+14, El-SharkawyKroeherEichelbergerSchmid15}, an Open Source product line toolset implementing IVML. At its core, the reasoner focuses on translating / creating specifically instantiated constraints for the various IVML concepts and on forward-reasoning, i.e., evaluating the constraints and performing value propagation as much as possible. On the one hand side, this allows for performing typical validation and propagation tasks, but, on the other hand side, this currently does not support advanced reasoning functionality such as configuration completion. This document is mainly intended to summarize the actual state, the ideas behind individual steps of the reasoning process and the decisions made for realizing the reasoning. Besides the pure technical documentation, our specific contributions are: + +\begin{itemize} + \item An IVML-complete reasoning mechanism, i.e., translation and reasoning for a complex, rich and typed variability modeling language. + \item Support for IVML type refinements, which can cause implicit effects on the application of constraints. IVML allows defining a type hierarchy, and so the potential types for a configuration option, i.e., a typed variable, can change along the type hierarchy. As types can introduce constraints, the actual constraint base considered during reasoning can change, i.e., constraints must be added or removed as an effect of a value type change. + \item Support for IVML constraint variables, i.e., variables that hold constraints (including sets or sequences) and be changed by the configuration. Through constraint variables, IVML explicitly allows introducing, adding, removing and disabling constraints. Consequently, such changes can affect the constraint base considered during reasoning. + \item Instantiation of type-based constraints to variable-based constraints as a basis for a subsequent reasoning chain. For such subsequent reasoners, the IVML reasoner provides a solid basis, detailed error messages including the failed instantiated constraints so that a chained reasoner can directly continue with these constraints. We envision for future work, that further reasoning steps may add complementing reasoning functions such as identifying a value from narrowing constraints. +\end{itemize} + +This document is structured as follows: Section \ref{sectApproach} provides an overview to our approach. Section \ref{sectNotation} introduces the notation that we use throughout this document to specify the algorithms, i.e., we introduce notations for sets, sequences, substitutions as well as relevant parts of the IVML object model realizing the various IVML concepts, here in terms of notations for accessing (derived) properties of the IVML model. In Section \ref{sectReasoning}, we discuss the top-level algorithms for transforming constraints and reasoning. In Section \ref{sectTranslation}, we detail the translation of constraints for all IVML modeling concepts. The result is a set of instantiated constraints that can be used for reasoning. Section \ref{sectTranslation} includes also the mechanism for re-scheduling constraints when value types or constraint variables change, as this mechanism heavily relies on the constraint translations discussed before. In Section \ref{sectCompleteness}, we analyze the translations in order to assess their completeness with respect to IVML concepts and indicate the state of the validation, i.e., regression test cases checking that the constraint translations are applied correctly for specific modeling situations. In Section \ref{sectEvaluation}, we present an evaluation of the actual performance of the reasoning approach for different kinds of IVML models. In Section \ref{sectPerformance}, we summarize performance issues, findings and resolutions we made while revising the reasoner, in particular to avoid that future modifications violate already resolved performance anti-patterns. Finally, in Section \ref{sectConclusion} we conclude and provide an outlook on future work. Index: /reasoner/ivmlCompleteness.tex =================================================================== --- /reasoner/ivmlCompleteness.tex (revision 144) +++ /reasoner/ivmlCompleteness.tex (revision 144) @@ -0,0 +1,217 @@ +\section{IVML-Completeness}\label{sectCompleteness} + +In this section, we discuss the completeness of the reasoner with respect to IVML concepts. Reasoning completeness, e.g., involving advanced reasoning capabilities such as narrowing down value instances by limiting constraints or instance creation, is not topic of this section and may be targeted by future work. + +\begin{table*}[!h] +%\begin{adjustbox}{angle=90} +\centering +\begin{tabular}{|p{3cm}|c||p{4cm}|p{2,3cm}|} +\hline +\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation Path} & \textbf{Test}\\ +\hline + \multicolumn{4}{|c|}{Types (Top-level concepts)}\\ +\hline + +Decision variable & 2.1.4 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTranslationDeclaration}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & \textit{all} \\ + +Constraint & 2, 3 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTopLevelConstraints} & B2, ...\\ + +Constraint variable & 3.1.10 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTranslationDeclaration}\tabAlgFollow\tabAlgLines{algTranslateDeclaration}{algTranslateDeclarationTranslateConstraintDefaultStart}{algTranslateDeclarationTranslateConstraintDefaultEnd}, change \tabAlg{algVarChange}\TBD{addLine} & Cs1, Cs2, CsCtCn1 \\ + +Annotation & 2.2.2 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTranslationDeclaration}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationAnnotationDefault}\tabAlgFollow\tabAlgLine{algTranslateAnnotationDeclarations}{algTranslateAnnotationDeclarationsTranslateDeclV} or \tabAlgLine{algTranslateAnnotationDeclarations}{algTranslateAnnotationDeclarationsTranslateDeclD} \tabAlgFollow Table \ref{tab:completenessAnnotations} & A1, A2, A3\\ + +Assignment block & 2.2.2 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTopLevelAnnotationAssignments}\tabAlgFollow\tabAlg{algTranslateAnnotationAssignments} & CnAI1 \\ +$\triangleright$ constraints & 2.2.2 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTopLevelAnnotationConstraints} & AI2 \\ + +Partial evaluation & 2.2.5.3 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTopLevelEvals} & Ev1\\ + +Interfaces & 2.2.4.3 & no specific support needed & If1, If2\\ + +re-assignment & 2.1.4, 3.1.4 & \tabAlgLine{algVarChange}{algVarChangeScope}, \tabAlgLines{algEvalLoop}{algEvalLoopClearScope}{algEvalLoopSetScope} & Sc1, Sc2, Sc3\\ + +\hline + \multicolumn{4}{|c|}{Non-complex types (typed decision variable, starting in \tabAlg{algTranslateDeclaration})}\\ +\hline + +Integer type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & I1, I2\\ + +Real type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & R1, R2\\ + +Boolean type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & B1, B2, B3 \\ + +String type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & S1, S2\\ + +Enum type & 2.1.3.2 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & E1, E2\\ + +Reference type & 2.2.3.2 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & BF1, EF1\\ + +Derived type & 2.1.3.4 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationDerivedDatatype}\tabAlgFollow\tabAlg{algTranslateDerivedDatatypeConstraints} +& IT1, IT2 \\ + +Constraint type & 3.10.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationConstraintVariableConstraint}\tabAlgFollow\tabAlg{algCreateConstraintVariableConstraint} & Cs1, Cs2\\ + +\hline +\end{tabular} +%\end{adjustbox} +\caption{Translations for top-level and non-complex types.} +\label{tab:completenessTopLevelTypes} +\end{table*} + + +To indicate the IVML completeness, we enumerate all relevant IVML concepts, their definition in the IVML specification~\cite{IVML-LS}, the transformation path along the algorithms presented in this document and the test cases validating the transformation and the reasoning results. We separate the argumentation into four parts and present for each path the relation of specification entry, transformation path and test cases in terms of a summarizing table. The four parts are 1) top-level concepts / basic types (Table \ref{tab:completenessTopLevelTypes}), compound types (Table \ref{tab:completenessCompounds}), container types (Table \ref{tab:completenessContainers}) and annotations (Table \ref{tab:completenessAnnotations}). Test cases are referenced by ids in order to indicate that all relevant combinations are subject to regression testing in the continuous build process of EASy-Producer. The referenced test cases are detailed in Appendix \ref{appendixTestCases}. + +\pagebreak + +\TBD{Check quantized instance constraints.} + +\begin{table*}[!h] +%\begin{adjustbox}{angle=90} +\centering +\begin{tabular}{|p{3cm}|c||p{4cm}|p{3cm}|} +\hline +\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation Path} & \textbf{Test}\\ + +\hline + \multicolumn{4}{|c|}{Compound types}\\ +\hline + +Integer type & 2.1.3.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & ICo1, ICo2\\ + +Real type & 2.1.3.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & RCo1, RCo2\\ + +Boolean type & 2.1.3.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & BCo1, BCo2, BCo3 \\ + +String type & 2.1.3.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & SCo1, SCo2\\ + +Enum type & 2.1.3.2 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & ECo1, ECo2\\ + +Derived type & 2.1.3.4 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationDerivedDatatype}\tabAlgFollow\tabAlg{algTranslateDerivedDatatypeConstraints} & CnTCt1, CnTCt2, CnTF1 \\ + +Reference type & 2.2.3.2 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & FCn1, FCn2, FCn3, CnTF1 \\ + +Compound type & 2.1.3.5 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateCompound}\tabAlgFollow\tabAlg{algTranslateCompoundDeclaration} $\ldots$ & Cn2, Cn3 \\ + +Container type & 2.1.3.3 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateContainer}\tabAlgFollow Table \ref{tab:completenessContainers} & CnCt3, CnCt4 \\ + +Constraint type & 3.10.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLines{algTranslateDeclaration}{algTranslateDeclarationTranslateConstraintDefaultStart}{algTranslateDeclarationTranslateConstraintDefaultEnd}, change \tabAlg{algVarChange}\TBD{addLine} & CsCn1, CsCn2, CsCtCn1 \\ + +Constraints & & \tabAlgLines{algTranslateCompoundDeclaration}{algTranslateCompoundDeclarationAllStart}{algTranslateCompoundDeclarationAllEnd}& Cn1, CnCs1 \\ + +\IVML{self} & 3.1.6 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateSelf1}, \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateSelf2}, \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateSelf3} & CnA3 \\ + +Annotation & 2.2.2 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$, cf. Table \ref{tab:completenessTopLevelTypes} & CnA3\\ + +Assignment blocks & 2.2.2 & \tabAlgLine{algTranslateCompoundContent}{algTranslateCompoundDeclarationCompoundAssignments}\tabAlgFollow\tabAlg{algTranslateAnnotationAssignments} & CnAI2, CnAI3 \\ +$\triangleright$ constraints & 2.2.2 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationAllStart}{algTranslateCompoundDeclarationAllEnd} & CnA4 \\ + +Partial evaluation & 2.2.5.3 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationEvalStart}{algTranslateCompoundDeclarationEvalEnd} & CnEv1 \\ + +\hline +\end{tabular} +%\end{adjustbox} +\caption{Compound translations, starting with \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateCompound}\tabAlgFollow\tabAlg{algTranslateCompoundDeclaration} and \tabAlg{algRegisterCompoundMapping}.} +\label{tab:completenessCompounds} +\end{table*} + +\pagebreak + +\TBD{No annotation, assignment blocks and partial evaluation possible from IVML syntax. Accessor-based access handled by \tabAlg{algTranslateDeclaration}.} + +\begin{table*}[!h] +%\begin{adjustbox}{angle=90} +\centering +\begin{tabular}{|p{3cm}|r||p{6cm}|p{3cm}|} +\hline +\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation Path} & \textbf{Test}\\ + +\hline +% \multicolumn{4}{|c|}{Compound types}\\ % disabled due to page break/moving tables to the end +%\hline + +Integer type & 2.1.3.1 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & ICt1, ICt2\\ + +Real type & 2.1.3.1 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & RCt1, RCt2\\ + +Boolean type & 2.1.3.1 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & BCt1, BCt2 \\ + +String type & 2.1.3.1 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & SCt1, SCt2\\ + +Enum type & 2.1.3.2 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & ECt1, ECt2 \\ + +Derived type & 2.1.3.4 & \tabAlgLine{algTranslateContainerDeclaration}{algTranslateContainerDeclarationDerivedTypes}\tabAlgFollow\tabAlg{algTranslateDeclaration} & ITCt1, ITCt2 \\ + +Compound type & 2.1.3.5 & \tabAlgLines{algTranslateContainerDeclaration}{algTranslateContainerDeclarationCompoundContainerStart}{algTranslateContainerDeclarationCompoundContainerEnd}\tabAlgFollow\tabAlgLines{algTranslateCompoundContainer}{algTranslateDefaultsCompoundContainerMapping}{algTranslateDefaultsCompoundContainerContent}\tabAlgFollow\tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & CnCt3, CnCt4 \\ + +Derived compound type & 2.1.3.3 & \tabAlgLine{algTranslateContainerDeclaration}{algTranslateContainerDeclarationDerivedTypes} \tabAlgFollow \tabAlg{algTranslateDerivedDatatypeConstraints} & ITCnCt1, ITCnCt2 \\ + +Container type & 2.1.3.3 & \tabAlgLines{algTranslateContainerDeclaration}{algTranslateContainerDeclarationCompoundContainerStart}{algTranslateContainerDeclarationCompoundContainerEnd}\tabAlgFollow\tabAlgLines{algTranslateCompoundContainer}{algTranslateDefaultsCompoundContainerMapping}{algTranslateDefaultsCompoundContainerContent}\tabAlgFollow\tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & CnCt2, CtTF1 \\ + +Derived container type & 2.1.3.3 & \tabAlgLine{algTranslateContainerDeclaration}{algTranslateContainerDeclarationDerivedTypes}\tabAlgFollow\tabAlg{algTranslateDerivedDatatypeConstraints} & CtTCt1, CtTF1 \\ + +Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & CnFCt1, CnTFCt1 \\ + +Constraint type & 3.1.10 & \tabAlgLine{algTranslateContainerDeclaration}{algTranslateContainerDeclarationConstraintContainer}, change \tabAlg{algVarChange}\TBD{addLine} & CnCt1, CnCt2, CsCtCn1 \\ + +Annotation & 2.2.2 & top-level only, see Table \ref{tab:completenessTopLevelTypes} & TFCnCtCsA1 \\ + +Assignment blocks & - & - & - \\ + +Partial evaluation & - & - & - \\ + +\hline +\end{tabular} +\caption{Translation of containers, starting with \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateContainer}\tabAlgFollow \tabAlg{algTranslateContainerDeclaration}} +\label{tab:completenessContainers} +%\end{adjustbox} +\end{table*} + +\pagebreak + +\TBD{Recursive annotations are not supported by IVML, add section number below. A*1 means all annotation-related tests, which focus on one specifc type used in the annotation, e.g., ACn1 for a compound used in an annotation, but always applied to all relvant types.} + +\begin{table*}[!h] +%\begin{adjustbox}{angle=90} +\centering +\begin{tabular}{|p{2.5cm}|r||p{4cm}|p{2cm}|p{2cm}|} +\hline +\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation Path} & \textbf{Test as annotation} & \textbf{Test anotate to}\\ +\hline + \multicolumn{5}{|c|}{Annotations (starting with \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationAnnotationDefault}\tabAlgFollow\tabAlgLine{algTranslateAnnotationDeclarations}{algTranslateAnnotationDeclarationsTranslateDeclV} or \tabAlgLine{algTranslateAnnotationDeclarations}{algTranslateAnnotationDeclarationsTranslateDeclD} cf. see Table \ref{tab:completenessTopLevelTypes})}\\ +\hline + +Integer type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & CnAI1, AI1 & CnAI1, A*1 \\ + +Real type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & AR1 & A*1 \\ + +Boolean type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & AB1 & A*1 \\ + +String type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & AS1 & A*1\\ + +Enum type & 2.1.3.2 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & AE1 & A*1\\ + +Derived type & 2.1.3.4 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationDerivedDatatype}\tabAlgFollow\tabAlg{algTranslateDerivedDatatypeConstraints} & ATCn1 & A*1 \\ + +Compound type & 2.1.3.5 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateCompound}\tabAlgFollow\tabAlg{algTranslateCompoundDeclaration}\tabAlgFollow\tabAlgLine{algRegisterCompoundMapping}{algRegisterCompoundMappingAnnotationMapping}\tabAlgFollow\tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess} & ACn1 & CnAI1, A*1 \\ + +Container type & 2.1.3.3 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & ACt1 & A*1 \\ + +Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & AFCn1 & A*1 \\ + +Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers}& ACs1 & A*1 \\ + +Annotation & - & - & - & -\\ + +Assignment blocks & - & - & - &- \\ + +Partial evaluation & - & - & - &- \\ + +\hline +\end{tabular} +\caption{Translation of annotations starting with \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationAnnotationDefault}} +%\end{adjustbox} +\label{tab:completenessAnnotations} +\end{table*} + +\TBD{annotation on typedef-ref, ref-typedef, variable on typedef-ref, ref-typedef} + +\pagebreak Index: /reasoner/notation.tex =================================================================== --- /reasoner/notation.tex (revision 144) +++ /reasoner/notation.tex (revision 144) @@ -0,0 +1,290 @@ +\section{Notation and Terminology}\label{sectNotation} + +In this section, we define the notation and terminology that we use for explaining the reasoning process and the constraint translation. + +\subsection{General notation}\label{sectGeneralNotation} + +In general, we use $\undef$ to denote an \emph{undefined result/value}. Unless stated otherwise, we assume, that operations return a meaningful result even if $\undef$ is passed in as parameter. + +As usual, we denote a \emph{set} of elements by $s=\set{1, 2, ...}$ with no duplicates allowed. \emptySet{} is the empty set. We denote the derivation of set $s_1$ from another set $s$ by $s_1=\setWith{i+1}{i\in s}$, i.e., $s_1$ is derived from $s$ by iterating over and determining a new value for all elements $i$ in $s$, here through $i+1$. In this notation, conditions / projections may apply to the source set $s_1$. Further, $s_2 = s \cup s_1$ denotes the union of the two sets $s$ and $s_1$, i.e., $s_2$ contains all elements from $s_1$ and $s_2$ without duplicates. For convenience, we assume for a set $s_3$ that $s_3\text{ } \cup \undef = s_3$. + +For some parts of the reasoning algorithm, in particular to prioritize the evaluation of different constraint types and eval-blocks, we need \emph{sequences}, i.e., structures that hold elements in a given sequence as well as potentially duplicates of the elements. The the order is defined when adding / inserting elements to a sequence. We denote a sequence by $q=\seq{2, 1, ...}$ and \emptySeq{} as the empty sequence. Akin to sets, we denote the derivation of a sequence $q_1$ from another sequence $q$ preserving the order of elements in $q$ by $q_1=\seqWith{i+1}{i \in q}$. Accessing the $i$-th element in sequence $q$ is expressed by $q[i]$. Further, we denote the sequence concatenation by $q_2=q \addSeq q_1$, i.e., $q_2$ contains all elements (including duplicates) from $q$ and $q_1$, first the elements from $q$ in the sequence of $q$, then the elements from $q_1$ in their sequence of $q_1$. Moreover, we use $q_3=q \addSeqNoDupl q_d$ to denote a sequence concatenation of $q$ and $q_d$ omitting all occurring duplicates. + +In some cases, we also need to express a \emph{mapping} between key elements and associated value elements. We denote such a mapping as a set of pairs $\mapEntry{k}{v}$ relating a key $k$ to a value $v$. Within a mapping, key-value pairs are unique with respect to the key. We denote adding a key-value pair to a map by $m \addMap \mapEntry{k}{v}$, assuming that an existing entry for $k$ (accessed by $m[k]$) is overridden by the new entry. If there is no mapping for a certain key, $m[k]$ is $\undef$. Iterating over a map means iterating over the entries of a map. + +As this document is intended to detail the actual implementation and to ease mapping from code to algorithms and back, we use for the \emph{algorithms} (where feasible from the space / layout point of view) the actual name from the implementation. Further, we use parameters and return values as done in the implementation. If global, static or instance data is used, we indicate this in `data' section of the respective algorithm description. For simplifying the reading, we treat null values that may occur in the implementation either through $\undef$ or just omit null pointers and the respective checks needed in the code, i.e., unless stated otherwise, functions return then $\undef$ or, in case of set or sets or sequences $\emptySet$ or $\emptySeq$, respectively. + +\subsection{IVML elements} +In this section, we discuss the IVML elements and types that are relevant for IVML reasoning. For these elements and types we introduce functions to access their respective properties. We focus here on functions that are used for specifying the reasoning algorithm rather than all functions that are defined in the IVML object model. + +As a convention to ease reading the algorithms presented later, we use $d$ for variable declarations, $v$ for configuration variables, $t$ for types, $val$ for a values, $c$ for constraints and $cfg$ for configurations consisting of decision variables and their assigned values. For temporary/local variables, we typically use a name close by, e.g., $w$ for an iterator variable (instead of $v$) etc. If not indicated otherwise, all operations introduced below that are bound to a certain type, e.g., an IVML compound, return $\undef$ if the operation is used with another type, e.g., an IVML basic type. + +For all IVML elements introduced in the following subsections, we denote the set of constraints\footnote{Duplicates do not matter in this document as constraints are usually rather unique structures. The only effects of duplicates could be unintended re-evaluations or unintended multiple error messages for the duplicated constraints.} defined for element $e$ by $constraints(e)$. Let $s$ be a set of elements, then $constraints(s) = \setWith{constraints(t)}{t\in s}$. Further, for a model element $e$, $parent(e)$ denotes the model element $e$ is nested within, typically, a compound or a project. + +\subsubsection{Variable Declarations}\label{sectNotationVarDecls} + +An IVML \emph{variable declaration} $d$ is defined through a $name(d)$ and a $type(d)$.~$default(d)$ is an optional expression specifying the default value of $d$, whereby $default(d)$ must evaluate to a value of a type compatible with $type(d)$. $isDeclaration(d)$ is true for a variable declaration $d$. + +$annotations(d)$ denotes the set of (orthogonal) IVML annotation (variable) declarations for $d$ and $isAnnotation(d)$ returns whether a variable declaration is an annotation. $annotations(d)=\emptySet$ if $d$ does not define any annotations. Further, $annotation(d, n)$ indicates whether for declaration $d$ an annotation $a$ with name $n$ is defined. +% +$$ + annotation(d, n) = \begin{cases}a & \text{if }annotations(d) \wedge name(a)=n\\ + \undef & \text{else}\end{cases} +$$ +% +\begin{multline*} + annotations^+(e) = \begin{cases} + annotations(e) &\text{if } parent(e) = \undef \\ + annotations(e)\text{ } \cup\\\text{ }annotations(parent(e)) &\text{else} +\end{cases} +\end{multline*} +returns all declared annotations for an arbitrary model element $e$. + +\subsubsection{Configuration Variables}\label{sectNotationConfigVars} + +While variable declarations as introduced in Section \ref{sectNotationVarDecls} as well as types as introduced below allow defining (a meta-model of) configuration options, \emph{configuration variables} are part of the configuration of a specific product and hold the actual configured value for a variable declaration. A configuration variable $v$ (representing a decision, inspired by decision modeling~\cite{CzarneckiGruenbacherRabiser+12, SchmidJohn04}) is defined through a variable declaration $d$, but for a single variable declaration $d$ in a model, multiple configuration variables can exist in different configurations. + +Let $v$ be a configuration variable with declaration $d$ as part of a certain configuration $cfg$, i.e., $decision(cfg, d)=v$ and $parent(v)=cfg$. For such a combination of declaration $d$ and variable $v$, we define $declaration(v) = d$ as well as $type(v) = type(declaration(v))$. For a variable $v$, the function $isVariable(v)$ returns $true$, for any other IVML element/type $false$. + +$value(v)$ denotes the actual value of $v$ and $type(value(v))$ compliant with $type(v)$. Please note, that $type(value(v))$ can be a subtype of $type(v)$, in particular if $type(v)$ is a refined type through inheritance (cf.~\cite{IVML-LS} for details on the IVML type compliance rules and the IVML type hierarchy). We will detail some relevant properties of values below in Section \ref{sectNotationValues}. + +As some IVML types allow a nesting of configuration variables, we generically define $nested(v)$ as the set of all variables nested in $v$. Of course, $nested(v)=\emptySet$ if no nested variables are defined on $v$, $type(v)$ or $type(value(v))$. For a variable $v$, $\forall_{w\in nested(v)}\text{ } parent(w)=v$ must hold. Moreover, let $nested(v, n)$ be the nested variable in $v$ with name $n$, while $nested(v, n)=\undef$ if no such variable is defined. For convenience, we also define +% +\begin{multline*} +allNested(v) = \begin{cases} + \emptySet, & \text{if } |nested(v)| = 0 \\ + \begin{aligned}\set{&nested(v)}~\cup\\ &\setWith{allNested(w)}{w\in nested(v)},\end{aligned} & \text{else}\\ \end{cases} +\end{multline*} +% +\begin{multline*} +allParents(v) = \begin{cases} + \emptySet, & \text{if } \neg isVariable(parent(v)) \\ + \begin{aligned}\set{&parent(v)} \cup\\ &allParents(parent(v)),\end{aligned} & \text{else}\\ \end{cases} +\end{multline*} +% +Akin to variable declarations, $annotations(v)$ returns the set of actual annotation variables for variable $v$. Please note that there is a significant difference between $annotations(d)$ for a variable declaration $d$ and\linebreak[4]$annotations(decision(cfg,d))$, as a declaration only holds the specifically declared attributes for $d$, while a variable is instantiated with all annotations potentially inherited from containing project or variables (in case of compounds or containers). + +Due to the specific semantics of default or frozen variables, IVML variables have an \emph{assignment state} that be accessed via $state(v)$. The state of individual variables is changes (indirectly) when values are assigned, e.g., as as a side effect of constraint evaluation. The following states are defined: + +\begin{itemize} + \item \IVML{UNDEFINED}: No value has been assigned so far or the value was cleared intentionally through assigning the IVML constant value \IVML{null}. + \item \IVML{DEFAULT}: A type compatible default value has been assigned by evaluating the default value expression of the underlying variable declaration. Default values can be changed unless frozen, but not more than once within the same project scope. + \item \IVML{ASSIGNED}: A type compatible value has been assigned (by some EASy-Producer component). The value can still be changed, but not more than once within the same project scope. + \item \IVML{USER\_ASSIGNED}: A type compatible value has been assigned by the user and shall not be overridden, e.g., by the reasoner. + \item \IVML{DERIVED}: A type compatible value has been assigned as a side effect of reasoning and constraint evaluation. + \item \IVML{FROZEN}: The variable was frozen through the IVML \IVML{freeze} statement to avoid further changes of the actual value (including no value in state \IVML{UNDEFINED}). Further assignments are not allowed and cause an assignment error irrespective of the actual scope. +\end{itemize} + +Variables can be \emph{local}, e.g., as they are used in the IVML model as parameters of a user-defined constraint function, as variable in a let let-expression or as an iterator of a collection function. Such variables have the same properties as usual configuration variables, but they just hold a temporary value, may be re-assigned within a certain scope, e.g., iterator variables, typically have the state \IVML{ASSIGNED} and cannot be frozen. Local variables can be identified using $isLocal(v)$, which returns $true$ if $v$ is a local variable. + +%For simplifying the descriptions of algorithms, we ignore here the fact that IVML variables can have the IVML value \IVML{null}, i.e., explicitly undefined (and different from a null pointer). While the underlying implementation must contain explicit checks, we just assume here that the functions lead to $\undef$, \emptySet or \seq{\text{}}, respectively. + +\subsubsection{Project}\label{sectNotationProject} + +A \emph{project} is a named scope, which can contain variable declarations, type declarations, assignment-blocks and eval-blocks. $decls(p)$ denotes the set of all variable declarations introduced in project $p$. $isProject(p)$ returns $true$ for a project $p$. + +$evals(p)$ is the set of (potentially nested) \emph{eval-blocks} in project $p$. If $e\in evals(p)$ then $constraints(e)$ returns the constraints listed in $e$, whereby $constraints(e)$ may be empty, in particular if $e$ is an arbitrary model element. Similarly, $evals(e)$ returns the nested eval-blocks. Subsequently, the function $allEvalConstraints(e)$ returns all constraints in eval-block $e$ including all nested eval-blocks. +% +\begin{align*} +all&EvalConstraints(e) = \\ + &constraints(e) \cup \setWith{allEvalConstraints(f)}{f \in evals(e)} +\end{align*} +% +In IVML, an \emph{annotation assignment} is a kind of block, which allows assigning annotation values to the variables defined within the block, i.e., the specified annotation values shall be applied to all contained variable declarations. The declared variables shall behave as if they are defined in the innermost containing element that is not an annotation assignment. For convenience, also constraints relating to the contained variable declarations can be stated within an annotation assignment. To indicate orthogonal combinations of annotation assignments in IVML models, annotation assignments can be nested referring to different annotations. For convenience, only the innermost annotation value assignment shall be applied in nested assignment blocks in order to avoid accidental multiple assignments to the same annotation within the same project scope. + +$assignments(p)$ is the set of (potentially nested) annotation assignments of project $p$. If $a\in assignments(p)$ then $decls(a)$ returns the variables declared in $a$ and $constraints(a)$ the constraints declared within $a$. Further, $assignments(a)$ returns the annotation assignments nested within $a$. All three results may be empty. Further, $assignmentData(a)$ provides access to the affected annotations and the intended values values, i.e., if $f \in assignmentData(a)$ then $name(f)$ is the name of the affected attribute and $default(f)$ the intended default value expression that shall be assigned to all attributes with name $name(f)$ for all declarations within the containing assignment-block. $isAnnotationAssng(a)=true$ and for an arbitrary model element $e$, $isAnnotationAssng(e)$ returns whether $e$ is an assignment block. + +Using these functions, $allAssignmentConstraints(a)$ determines all assignment constraints within an assignment $a$ considering potentially further nested annotation assignments: +% +\begin{align*} +all&AssignmentConstraints(a) = \\ + &constraints(a) \cup \setWith{allAssignmentConstraints(b)}{b \in assignments(a)} +\end{align*} +% +In some algorithms we need to determine an attribute attribute declaration with name $n$ that is directly attributed to variable $v$ or one of the containing scopes of $v$. While for nested variables, we can just take the parent variables into account, this ends with the containing project. For ease of access, we (internally) represent a project as a (pseudo-)variable $variable(p)$ containing all variables declared by the project as nested variable. Then +% +\begin{multline*} +findAnnotation(v, n) = \\ \ \ \begin{cases} + annotation(v, n) &\text{if } annotation(v, n) \neq \undef\\ + findAnnotation(parent(v), n) &\text{if } isVariable(parent(v))\\ + findAnnotation(variable(parent(v)), n) &\text{if } isProject(parent(v))\\ + \undef & \text{else} \\ + \end{cases} +\end{multline*} +% +returns the innermost annotation for variable $v$ with name $n$. +% +\subsubsection{Constraints}\label{sectNotationConstraints} + +In IVML, a \emph{constraint} is a Boolean expression that must always evaluate to $true$. Otherwise, reasoning shall either fail. After a change of at least one of the values of the variables involved in the constraint, the constraint may be re-evaluated successfully, causing a cleanup of previous reasoning errors for that constraint. + +Technically, a constraint is an expression, which may consist of several (sub-)expressions, such as constants, variable uses, or function calls. An expression $e$ evaluates to a value of some IVML type, i.e., $type(e)$ returns the static value type of an expression. In particular, let $c$ be a constraint then $type(c) = \IVML{Boolean}$. Expressions are used to determine the default value of variables. Let $v$ be a variable then we denote by $e(v)$ that expression $e$ is using variable $v$ and by $var(e)$ the set of variables used in $e$. Moreover, if $c$ is an assignment constraint representing $x = y$, the $rightSide(c) = y$ returns the right side expression $y$, else $\undef$. If $e$ represents a constant, $const(e)$ returns the constant value, else $\undef$. + +Moreover, \IVML{Constraint} is an IVML type, indicating that a variable actually holds a constraint. From the reasoning point of view, a constraint stored as a value of a constraint variable is extracted and then evaluated as any other constraint. However, the value in such a variable may, as for all other variables, be undefined, frozen, or re-defined (once per project scope) implying that the old constraint must be discarded or even replaced by the new constraint value and considered in the subsequent reasoning process. $isConstraint(t)$ indicates whether type $t$ is a constraint type. %$isAssignmentConstraint(c)$ indicates whether constraint $c$ is supposed to unconditionally change the value of a variable through an assignment, e.g., for an integer variable \IVML{x} the constraint \IVML{x = 25;} in IVML notation is an assignment Constraint. + +During the constraint instantiation, variables must be substituted by other variables or expressions. Let $c$ be a constraint and \IVML{y} be some IVML variable. Then $\varSubstitution{c}{x = y}$ leads to the substitution of all variables named \IVML{x} by \IVML{y}. For example, if the constraint $c$ was before the substitution \IVML{x = 25}, it will be \IVML{y = 25} after the substitution. The right side of a substitution can be a variable or, more generally, an expression. Substitutions are transitive, i.e., in $\varSubstitution{c}{x=y,y=z}$ $x$ will be replaced by $z$. If the right side of a substitution is $\undef$, no substitution happens, e.g., in $\varSubstitution{c}{x = \undef}$. Substitutions can also be expressed in terms of a mapping to express multiple substitutions or to create up / reuse the substitution specification for several constraints. Let $\variableMapping=\set{\mapEntry{x}{e}}$ be a mapping, then $x$ is the variable to be replaced, $e$ the replacing variable/expression and $\varSubstitutionVarMapping{c}$ denotes the respective substitution. Both notations can be combined, e.g., to $\varSubstitutionOtherVarMapping{c}{x = y}$. + +During the constraint instantiation, also new constraints must be created. For this purpose, we use a specific notation to indicate constraint creation and the construction of sub-expressions. This notation combines algorithm elements, e.g., variables, carrying actual values/elements (written in mathematical notation) and IVML expression constructors (stated in teletype). For example, for creating the IVML constraint \IVML{x = 25;} we write $\createConstraint{\IVML{assign(x, 25)}}$. The angle brackets indicate a constraint creation, the contents of the brackets the creation of the expression making up the constraint. Here, \IVML{assng} is the constructor for the assign operation defined by IVML (actually implementing the assignment in \IVML{x = 25}) returning a Boolean value indicating whether the execution of the operation succeeded. In an algorithm, we may generically denote $\createConstraint{\IVML{assign}(x, 25)}$, with $x$ being determined by the algorithm. + + +As usual in IVML, we denote the creation of collection operations using the arrow and iterator notation. However, as we use the '$|$' symbol for variable substitutions, also using the same symbol in IVML quantor expressions may be confusing. Thus, we use in this document ':' instead of '$|$', e.g., we denote \IVML{forall(x:$c(x)$)} to indicate the construction of an all-quantized expression over a constraint using the quantor iterator variable $x$ instead of \IVML{forall(x|$c(x)$)}. In summary, let \IVML{o} be an IVML collection of Integers, then \IVML{o->forall(i:i>20);} requires that all values in $o$ must be greater than 20. To create such a constraint with $o$ being an algorithm variable, we denote $\createConstraint{o\IVML{->forall(i:i>20)}}$. + +To perform specific instantiations, the reasoning mechanism must classify constraints, in particular default value assignments over usual constraints. We indicate default value constraints by `$d$' in the constraint creation notation. For example, for creating a default constraint, we denote $\createDefaultConstraint{\IVML{assign}(x, 25)}$ for which the operation $\isDefaultConstraintName$ returns $true$. Further, we allow attaching additional information to a constraint, e.g., the type it was created for. Let $c$ be a constraint, then $attach(c, t)$ is an operation that attaches $t$ to constraint $c$ and returns $c$. The operation $attached(c)$ return the respective attachment. +%Similarly, we denote creating a constraint originating from a constraint variable by `$c$', e.g., $b \assng \createConstraintConstraint{\IVML{assign}(x, 25)}$ for which $\isConstraintConstraint{b} = true$ holds. + +In some cases, constraints cannot be created in terms of a single step, i.e., sub-expressions are created iteratively. To indicate this, we denote the creation of an expression by $\createExpression{expr}$, e.g., $\createExpression{\IVML{add}(x, 25)}$ for the IVML expression \IVML{x + 25}. When creating expressions, in particular in an incremental fashion, sometimes a temporary (local) IVML variable is needed, e.g., for an IVML let-expression or a container iterator. We state the creation of such a variable by $\IVMLMeta{var}(t)$, i.e., request the creation of a temporary variable\footnote{We don't care for the variable name in this document.} of type $t$. For a variable $v=\IVMLMeta{var}(t)$ holds $isLocal(v) = true$. + +Before reasoning over the constraints given in an IVML project, several kinds of constraints must be transformed, in particular to instantiate constraints defined for types through qualifying access expressions based on top-level variables. To illustrate the transformations performed by an algorithm in this document, we apply constraint transformation patterns. A \emph{constraint transformation pattern} indicates how a certain IVML model fragment is instantiated to a corresponding constraint given in IVML constraint notation rather than the algorithm notation for creating constraints introduced in this section. The model fragment acting as prerequisite is given on the left side of the derivation symbol $\patternDerivationSymbol$, the corresponding constraint on the right side of $\patternDerivationSymbol$. In such a pattern, variable parts are given in italics to indicate the information flow between both sides. Constant parts are given in normal font, IVML syntax in \IVML{teletype}. One or more transformation patterns are displayed in a gray box. For example, the pattern below indicates that an IVML declaration for variable $v$ (with type $T$ and default value expression $deflt$) is translated into an assignment constraint, which assigns the (value of the) default expression $deflt$ to $v$. + +\grayPara{ +\begin{gather*} + \patternDerivation{T \text{ } v = deflt\IVML{;}}{v = deflt} \\ +\end{gather*} +} + + +\subsubsection{Compounds}\label{sectNotationCompounds} + +A \emph{compound} is an IVML type, which consists of nested variable declarations, called slots. Let $t$ be a compound type, then $isCompound(t)$ returns $true$ and $false$ for all other types. The declared slots of a compound $t$ can be accessed through $slots(t)$. Akin to a variable declaration, for slot $s$ $name(s)$, $default(s)$ and $type(s)$ are defined. + +Compounds can form an inheritance hierarchy. $refines(t)$ represents the set of compound types directly refined by compound $t$ through multi-inheritance, returning an empty set if there are no such compounds or if $t$ is not a compound type. Individual slots from parent compounds can thereby shadowed / redefined by slots of the same or more specific type. We define +% +$$allRefines(t) = + \begin{cases} + \emptySet, & \text{if } refines(t) = \emptySet \\ + \begin{aligned}all&Refines(t)~\cup\\ &\bigcup_{u\in refines(t)} allRefines(u),\end{aligned} & \text{else} + \end{cases} + $$ +% +as the set of all refined compounds along the compound refinement hierarchy of $t$ and +% +$$allRefines^+(t) = + \begin{cases} + allRefines(t) \cup \set{t}, & \text{if } isCompound(t) \\ + \emptySet, & \text{else} + \end{cases}$$ +% +as the set of all refined compounds along the compound refinement hierarchy of $t$ including $t$ itself. Let $t$ and $s$ be compound types. Then we denote $\subTypeOf{t}{s}$ if $t\in allRefines(s)$, i.e., $s$ is a subtype of $t$. Similarly, $\subTypeEqOf{t}{s}$ if $t\in allRefines^+(s)$. Based on these functions, the set of all slots for compound type $t$ can be obtained by +% +$$slots^+(t) = \setWith{slots(r)}{r\in allRefines^+(t)}$$ + +A compound $t$ can define own nested assignment blocks $assignments(t)$ (related functions are defined for compounds akin to Section \ref{sectNotationProject}) and constraints $constraints(t)$. All declared compound constraints +%\footnote{The implementation unifies $allCompoundConstraints(t)$ with $allVariableConstraints(t)$ distinguished by a boolean parameter. We differentiate them here to indicate the sets to be transformed more clearly.} +for compound type $t$ are +% +\begin{align*} +all&CompoundConstraints(t) = \\ + &\setWith{constraints(s) \cup allAssignmentConstraints(s)}{s \in allRefines^+(t)} +\end{align*} +% +%and all constraints stemming from constraint variables for $t$ +%% +%\begin{align*} +%all&VariableConstraints(t) = \setWith{\createConstraint{s}}{s\in slots^+(t) \wedge isConstraint(type(s))}\text{ } +%\end{align*} +%% + +Let $v$ be a compound variable, i.e., a variable of a compound type $t$. Then $decision(v, s)$ returns the configuration variable representing slot $s$ in the compound variable $v$. As in the implementation, $slots(v)$ returns also all slots inherited from refined compounds including those defined in nested assignment blocks. +% +%For convenience, we introduce a function returning all default slots of a variable $v$ +%% +%$$dfltSlots(v) = \setWith{s}{s\in slots(v) \wedge default(s) \neq \undef}$$ %, compound slots of $v$ having default value expressions, empty for all non-compound types +%% + +% +In some constraint transformations it is important to determine, whether a compound slot is overridden. Let $d$ be a declaration, in particular $d\in slots(t) \wedge isCompund(t)$, then the parent compound of $d$ skipping potentially enclosing nested assignment blocks is +% +\begin{align*} +parent&Compound(d) = \\ + &\begin{cases} + parent(d), & \begin{aligned}\text{if }& parent(d) \neq \undef \wedge{}\\ &isCompound(parent(d)) \end{aligned}\\ + parentCompound(parent(d)), & \text{if } parent(d) \neq \undef \\ + \undef, & \text{else} + \end{cases} +\end{align*} + +and we can determine whether $d$ is overridden / also defined by a refined compound by +% +$$isOverridden(d) = d \in \setWith{slots(r)}{r\in allRefines(parentCompound(d))}$$ + +Akin to projects in Section \ref{sectNotationProject}, $evals(t)$ is defined for a compound type $t$ and returns all eval-blocks nested in $t$. Further, all constraints defined by all nested eval-blocks of $t$ can be obtained using +% +\begin{equation*} + allEvalConstraints(t) = \bigcup_{e\in evals(t)}{allEvalConstraints(e)} +\end{equation*} +% +\emph{Accessors} to compound variables define a path to access a certain slot within a compound variable, i.e., an accessor specifies the variable and the slot / nested slot path to access. Let \IVML{cmp} be an IVML variable of compound type, then an accessor to slot \IVML{slot} defined in \IVML{cmp} looks in IVML notation like \IVML{cmp.slot}. If \IVML{slot} is in turn of compound type, also nested accessors may occur, e.g., \IVML{cmp.slot1.slot2}. For creating such expressions in the constraint translation, we use the IVML access constructor \IVML{acc}. Then, following the expression creation notation from Section \ref{sectNotationConstraints}, creating the first accessor expression can be expressed by $\createExpression{\IVMLMeta{acc}\IVML{(cmp, slot)}}$, while for the second accessor we use $\createExpression{\IVMLMeta{acc}(\IVMLMeta{acc}(\IVML{cmp}, \IVML{slot}),\IVML{slot2})}$. Let $ce$ be an accessor expression, then $compound(e)$ returns the part referring to the compound if $e$ is a compound accessor, $\undef$ else. + +The value of a compound variable can be defined, e.g., as a default value expression or as an assignment constraint, using a complex value expression, a so called \emph{compound initializer}, essentially a name-value mapping. As slots can be in turn of a complex type, e.g., of a compound type, a compound initializer can also contain nested complex values, e.g., nested compound initializers. + +\subsubsection{Containers}\label{sectNotationContainers} + +An IVML \emph{container} is a parametrized type representing a structure that holds an arbitrary number of variables / values. IVML defines two default container types, namely \emph{sequence} (duplicates allowed, order important) and \emph{set} (no duplicates allowed, order irrelevant). The type parameters of a container are not relevant for reasoning, as we can assume that the static type compliance is checked by the IVML object model or the IVML parser before reasoning. + +Let $c$ be a container, then $elements(c)$ denotes the set or sequence of all element values in $c$, respectively. Let type $t$ be a container type, then $isContainer(t)$ returns $true$. Further, $contained(t)$ returns the directly contained type, e.g., for a \IVML{setOf(setOf(Integer))} in IVML notation, $contained(t)$ returns \IVML{setOf(Integer)}. + +We define $isNested(t) = isContainer(contained(t))$ and +% +$$nested^*(t)=\begin{cases}nested^*(contained(t)), & \text{if } isNested(t) \\ contained(t), & \text{else} \\ \end{cases}$$ +% +returning the (innermost) nested type, i.e., for \IVML{setOf(setOf(Integer))} $nested^*(t)$ returns \IVML{Integer}. If $isNested(c)$ is $true$ for a container $c$, $elements(c)$ contains values of the nested type. In some situations, the flattened container is needed, i.e., for nested collections preferrably with the same innermost nested type only the innermost contained values are relevant. For this purpose, $allElements(c)$ returns the transitively flattened elements of the respective container, i.e., set or sequence, i.e., all leaf elements of a depth-first traversal of the containment tree. + +During the constraint translation, we must identify whether a container consists of constraints, i.e., +% +$$isConstraintContainer(t) = isNested(t) \wedge isConstraint(nested^*(t))$$ +% +In other situations, we need to know all actual innermost nested types that are used in a container, i.e., the set +% +$$usedTypes(c) = \setWith{contained(type(e))}{e\in allElements(c)}$$ +% +This is in particular important if $isCompound(nested^*(type(c)))$ holds for a container $c$, as then also values of refined types of $nested^*(type(c))$ may occur in $usedTypes(c)$. + +For containers, \emph{access expressions} usually occur either in quantorized expressions utilizing the iterator variable or if the collection is a sequence (typically of compounds). Then accessing an element by an index happens through the IVML index access function for sequences. For example, let \IVML{seq} be a sequence of compounds, all having a common slot \IVML{slot}. Then \IVML{seq[1]} accesses the second element in the container\footnote{In contrast to OCL, IVML indexes are 0-based.} and accessing \IVML{slot} on the first element happens through \IVML{seq[1].slot}. For creating the respective expression within an algorithm, we denote $\createExpression{\IVMLMeta{acc}(\IVML{seq[1]}, \IVML{slot})}$. + +Akin to compounds, containers can be initialized by complex values, so called \emph{container initializers}, here as a listing of possible complex values. If the container is a sequence, the given order of values in the container initializer used as (initial) order of the sequence elements. + +\subsubsection{Derived types}\label{sectNotationDerivedTypes} + +In IVML, a \emph{derived type} denotes a new type based on an existing type. A derived type can restrict the base type by specifiying constraints. Further, without constraints, a derived type can act as an alias of a type, e.g., a complex container type. + +For a derived type $t$, $isDerived(t)$ returns true and $base(t)$ returns the type $t$ is derived from. For specifying constraints, a derived type $t$ implicitly declares a variable $decl(t)$ of type $base(t)$. Constraint expressions may use $decl(t)$, which must be substituted by a concrete variable during constraint instantiation, as well as any other variable accessible in the actual scope. + +In particular, derived types can be defined based on already existing derived types. In this case, a chain of dependent base types is created, whereby for reasoning typically the most basic type $base^*(t)$ is relevant. +% +$$base^*(t) = \begin{cases}base(t), & \text{if } isDerived(t) \wedge \neg isDerived(base(t)) \\ base^*(base(t)), & \text{if } isDerived(t) \wedge isDerived(base(t)) \\ \undef, & \text{else}\\ \end{cases}$$ +% +For the constraint translation it is relevant to iterate over all base types of such a chain, e.g., and to instantiate their declared constraints. Therefore, we define +% +$$allBase(t) = \begin{cases}\set{base(t)}, & \text{if } isDerived(t) \wedge \neg isDerived(base(t)) \\ \set{base(t)} \cup allBase(base(t)), & \text{if } isDerived(t) \wedge isDerived(base(t))\\ \emptySet, & \text{else}\\ \end{cases}$$ +% +\subsubsection{Other IVML Types}\label{sectNotationOthers} + +No specific constraint translation is needed for \emph{basic types} (Boolean, Integer, Real, String), the constraint type introduced in Section \ref{sectNotationConstraints} as well as for enums, because IVML does not support directly attaching constraints to these types. Constraints for these types can only be defined indirectly as global constraints for variable declarations, as nested compound constraints for compound slots or via derived types as introduced in Section \ref{sectNotationDerivedTypes}. Thus, no specific functions for these types must be discussed here. The available IVML functions and operations for these types, such as adding two integer values, are subject of the creation of expressions / the IVML model, e.g., through the IVML parser as well as of the IVML expression evaluation mechanism, rather than the reasoning algorithms discussed in this document. + +However, IVML \emph{configuration references} require a specific treatment in some situations. In IVML, a configuration reference points to a variable defined in the same or another imported project. A configuration reference is a generic type $t$ defined for the base type $base(t)$ of the variable the reference points to. If $t$ is a reference, $isReference(t)$ returns true. + +As the actual IVML specification~\cite{IVML-LS} does not define specific properties or operations for reference types, we can safely assume that variables of reference types are transparent and just provide access to the referenced variable. In particular, this holds even if constraints are defined on that variable, as they are translated for / evaluated on the referenced variable. For this purpose, we must be able to (sliently) dereference a type $t$ +% +$$deref(t)=\begin{cases} base(t), & \text{if } isDerived(t) \wedge \neg isDerived(base(t))\\ deref(base(t)), & \text{if } isDerived(t) \wedge isDerived(base(t))\\ t, & \text{else}\\\end{cases}$$ +% +and in some cases even a set $s$ of types through +% +$$deref(s)=\setWith{s\in t}{deref(t)}$$ +% + +\subsubsection{IVML Values}\label{sectNotationValues} + +In the IVML object model, IVML types have corresponding typed values, in particular to correctly represent potentially nested complex structured types such as compounds and containers. As the IVML expression evaluator is operating on values, in particular by retrieving them from a configuration, applying IVML operations and storing them back to a configuration, we can mostly neglect the specific properties of IVML values. However, some specific properties must be taken into account for reasoning, which we introduce in this section. + +A value $val$ is typed and, thus, always provides access to its type $type(val)$. In case of a compound variable $v$, the value determines the actual type of $v$, as $\subTypeEqOf{type(value(v))}{type(v)}$. One specific value is \IVML{null}, which is compliant with all types, i.e., can be assigned to any variable to indicate that a variable is (explicitly) not configured. \IVML{null} is certainly different from the undefined value $\undef$: $\undef$ indicates in this context that so far no value has been assigned to a variable and the variable shall have either assignment state \IVML{UNDEFINED} or \IVML{FROZEN}. \IVML{null} wipes out a previously assigned, replaces $\undef$ and the assignment state of a variable with value \IVML{null} shall not be \IVML{UNDEFINED}. + +As introduced in Section \ref{sectNotationConstraints}, a constraint expression may just represent a constant value. This constant value can be obtained from an expression $e$ using $const(e)$, which returns $\undef$ for any expression that is not a constant expression. Further, complex values can consist of nested values, which are accessible through $elements(val)$. In case of a collection value, $allElements(val)$ returns the values of the flattened collection, respectively. To ease the notation of some algorithms, we just assume here that for a non-complex value $val$, $elements(val)=\set{val}$ and, in case of a collection value, $allElements(val)=\set{val}$ else $\set{}$. Further, we assume that $elements(\undef)=\emptySet$ and $allElements(\undef)=\emptySet$. + +In some situations we must either rely on the actual value of a variable (if available) or the default value of the variable, the latter in particular for initializing a configuration through the reasoner. Thus, for a variable $v$ and its declaration $d=decl(v)$, we define\footnote{We follow the style of the implementation for documentation purposes. There, $d$ is typically available via a parameter or a local variable to avoid repeated method calls.} +% +$$ +relevantValue(v, d, inc) = \begin{cases}value(v), & \text{if } value(v) \neq\undef\\ const(default(d)), & \text{if } default(d) \neq\undef \wedge \neg inc\\ \undef, & \text{else}\end{cases} +$$ +% +returning the relevant value of variable $f$ either in terms of its assigned value or its default value, the latter only if we are not in incremental reasoning mode $inc$. +% Index: /reasoner/performance.tex =================================================================== --- /reasoner/performance.tex (revision 144) +++ /reasoner/performance.tex (revision 144) @@ -0,0 +1,21 @@ +\section{Performance Considerations}\label{sectPerformance} + +In this section, we briefly collect some observations seen/refactored/solved/left over during the improvement of the reasoner. Although the considerations may appear rather reasoner specific or specific to the IVML object model, they typically stem from more general Java performance optimization knowledge typically hidden behind constraints, reasoner or model data structures. \TBD{The individual texts may be pretty short, and are currently just intended for remembering/recording the obstacles.} + +\begin{itemize} + \item For lists of unknown size and for the expected capacity of IVML models, use \textbf{linked lists} instead of array lists. Main operations are adding, iterating over all, lookup of and removing elements to clean up memory incrementally, i.e., linked lists can avoid performance-impacting resizing effects. To speed up removal and lookup, we combined a linked list and a hashtable in a special constraint base class. Index-based access is not needed, constraints are just added and one iteration is needed to build up the constraint base or to perform reasoning. Pre-calculation of the expected size of the data structures per model seems to be unfeasible as this requires a second run over all model elements. + \item Process the \textbf{constraint base} iteratively and remove processed constraints directly after processing. This again requires a linked list as otherwise incremental resizing effects can affect the performance. In summary, building the constraint base and reasoning causes peak memory effects that are better from a performance point of view than (re-)allocating big array memory blocks. + \item Avoid having too many unneeded \textbf{partitions of the constraint base} being stored during the translation in different lists, that are finally added to the constraint base. Try to directly add constraints where possible to the constraint base, e.g., for default constraints to avoid iterating over the complete constraint base before reasoning. However, due to the prioritization of the constraint types and their required sequence, this is not always possible. One alternative, a numeric prioritization of the individual constraints would require sorting the constraint base, at the new parts not the left-over constraints to be re-evaluated from a previous reasoning steps. However, implicit sorting on insertion according to priorities could help here. To speed up operations for such constraint lists, we use a specific linked constraint list, which transfers the nodes the linked nodes upon adding the constraints to the constraint base (based on this specific linked list). + \item Create/translate a \textbf{constraint in one step}, if required in compounds split into filling the variability mapping and then creating the constraints based on the actual mapping. + \item Try to figure out whether a certain \textbf{constraint (type) is actually needed} for reasoning and avoid its translation/creation wherever feasible. \TBD{Can we move the decision about keeping a constraint from adding it to the constraint base before constraint creation. However, this requires changes/additional alternatives for different code parts.}. Thus, don't re-process or filter certain constraint types at the end (done in the initial version for default and derived type constraints), as this implies iterating multiple times over the (partial) constraint base and re-creating/throwing away constraint instances in memory. + \item \TBD{Avoid storing constraints that can be \textbf{processed immediately}, e.g., default constraints without dependencies. However, if a default constraint fails, it must be added to the constraint basis for later possible re-evaluation if dependent values become available/right.} + \item For identifying whether constraints are already in the constraint base, use a \textbf{fast look-up structure} instead of an iteration over the constraint base. Although the initial implementation utilized here reference equality (faster than the equals method), the current lookup structure is significantly faster (approx. 600 ms on large models, at that time around 25\% of runtime) than the original approach trading off execution speed for (peek) memory. Here a lookup structure based on reference equality could further speed up reasoning, which, however, may in the end be slower than the built in collections due to JIT compilation and JVM optimization effects. This is even true for the stack-based variable mapping $\variableMapping$, which performs as fast as a flat map, which may roughly serve for the main purpose of $\variableMapping$, but not for composing complex constraints from nested compunds and containers. + \item Incremental reasoning using a \textbf{stored constraint base} may speed up reasoning but only achieves this through large memory allocations. Ensure initializing the model through default constraints so that the actual stored constraint base only contains really needed constraint types, i.e., no default constraints and, if possible, no constraints for which all depending variables are already frozen. + \item \textbf{Reuse visitor instances} if applied more than once, in particular reasoners with more complex internal data structures such as maps or lists. This required some refactoring of the IVML model implementation. + \item \textbf{Avoid temporary instances}, e.g., iterators, temporary constraint creation, temporary data structures wherever possible. One option replacing a collection structure is to define a functor for processing the elements and to create a reusable instance of that functor. If permitted by the Java environment settings (EASy often compiles against JDK 1.6), also a lambda-function instead of a heavy-weight functor class may be appropriated. + \item \textbf{Avoid multipe variable substitutions} per constraint expressions, i.e., join variable substitutions wherever possible. Variable substitution copies the expression. Initially, performing a substitution multiple time on the same expression caused creating multiple copies of all nodes in memry, i.e., a follow-up copy usually was used instead of the original copy making the previous copies effectively superfluous. As sometimes multiple substitutions can only be avoided with additional (not straightforward) code, e.g., for a sequential call of Algorithm \ref{algTranslateCompoundDeclaration} and \ref{algTranslateDeclaration}, we revised the IVML expression copy mechanism to create instances of expression tree nodes only if a substitution happend, i.e., new expression trees are absolutely required. + \item \textbf{Use instance pooling} if datastructures are temporarily used, e.g., variable accessors in expression evaluation or sets of compounds in reasoning (20-30 ms on larger models, at that time around 10\% of runtime). +\item visitor is faster than (IVML-)instanceof +\end{itemize} + +There are still opportunities for further speeding up the reasoning operations. On an Intel core i7, the reasoner reaches around 15-43 constraint evaluations in average per millisecond - runtime vs. full reasoning on the latest QualiMasster test model, currently reasoning time includes translation and evaluation time \TBD{Sepearte timing}. This is already an improvement over the initial version, which operated at around 10 evaluations per millisecond in average (also with a higher number of constraint evaluations due to unneeded and uneffective constraints). The constraint evaluation time probably suffers from the immutable structured values in EASy-Producer, which are created for each assignment. Knowing that most of the assignments in this model are done for basic IVML datatypes, a fast track for setting integer, double, boolean and String values could increase the number of evaluations, but requires careful extension, as changing values shall only be allowed via decision variables, which take care of the current assignment state, e.g., \IVML{FROZEN}. Index: /reasoner/reasoner.tex =================================================================== --- /reasoner/reasoner.tex (revision 143) +++ /reasoner/reasoner.tex (revision 144) @@ -11,4 +11,5 @@ \usepackage{xcolor} \usepackage{adjustbox} +\usepackage{float} \newcommand\TBD[1]{{\color{blue}TBD: #1}} @@ -72,1497 +73,14 @@ Automatically analyzing and reasoning about interdependent configuration settings can be a difficult task, in particular if the configuration modeling approach provides complex modeling concepts or a highly expressive constraint language~\cite{EichelbergerKroeherSchmid13}. In this document, we give an overview on the current state of reasoning for the Integrated Variability Modeling Language (IVML)~\cite{IVML-LS}, a variability and configuration modeling language that contains several advanced and complex modeling concepts as well as an expressive constraint language allowing for first-order logic. We discuss the approach to reasoning for IVML, in particular, the translation of types and constraints for reasoning, the reasoning algorithm, the validation of the approach and its performance for different kinds of models. -\section{Introduction} - -In Product Line Engineering, a \emph{variability model} defines the options to customize a software system, while a \emph{configuration} specifies the choices made for a specific instance / product of the product line. Customization options can depend on each other, e.g., the choice made for an option determines, restricts or even excludes the selection for another customization option. Such dependencies are typically expressed using different forms of \emph{constraints}. For instantiating a software system, a configuration must be valid, i.e., all (relevant) constraints must be fulfilled. To analyze a configuration for validity, for figuring out the number of remaining configuration options or for propagating derivable values, various forms of \emph{reasoning mechanisms} are utilized, such as SAT-solvers in~\cite{BakDiskinAntkiewicz+16, BenavidesTrinidadRuiz-Cortes05, MendoncaBrancoCowan09} or SMT-reasoners in~\cite{BakDiskinAntkiewicz+16}. For some models, specific forms of reasoning were even shown to be efficient, e.g., SAT-solving on feature models~\cite{MendoncaWasowskiCzarnecki09}. However, the expressiveness of the modeling concepts affect the analyzability of the model~\cite{EichelbergerKroeherSchmid13}, and, thus, limit also the feasibility of applying (existing) reasoning mechanisms. - -Besides traditional variability modeling approaches, such as feature modeling~\cite{CzarneckiHelsenEisenecker05, KangCohenHess+90} or decision modeling~\cite{CzarneckiGruenbacherRabiser+12, SchmidJohn04}, in recent time several approaches with more powerful modeling concepts have been proposed, e.g., supporting non-Boolean variability, sets of variabilities or advanced types of constraints, e.g., first-order logic. One rather popular form of approaches is textual variability modeling, as analyzed in more details in~\cite{EichelbergerSchmid15a}. Such more powerful modeling approaches require also adequate reasoning mechanisms, while the expressiveness of modeling concepts trades off with analyzability~\cite{EichelbergerKroeherSchmid13}. For short, typically more powerful modeling concepts imply limitations of the analysis capabilities, e.g., non-Boolean configuration options typically prevent determining the actual number of possible configurations (in contrast to the number of configuration options that remain to be configured to achieve a complete configuration). - -The \emph{Integrated Variability Modeling Language (IVML)}~\cite{IVML-LS} is a textual variability modeling language providing rather powerful modeling concepts, among them a type system inspired by object-orientation, multiple-inheritance, container types, configuration references, imports, orthogonal annotations (e.g., for binding times), quantification constraints, or user-defined constraint functions. The core idea of IVML is to represent a variability, i.e., a configuration option, as a typed variable. IVML even allows for modeling topological variability, i.e., configuring and reasoning over graph structures~\cite{EichelbergerQinSizonenko+16}. - -In this document, we discuss the approach and the design of the reasoning mechanism for IVML as well as its realization in EASy-Producer~\cite{EichelbergerEl-SharkawyKroeher+14, El-SharkawyKroeherEichelbergerSchmid15}, an Open Source product line toolset implementing IVML. At its core, the reasoner focuses on translating / creating specifically instantiated constraints for the various IVML concepts and on forward-reasoning, i.e., evaluating the constraints and performing value propagation as much as possible. On the one hand side, this allows for performing typical validation and propagation tasks, but, on the other hand side, this currently does not support advanced reasoning functionality such as configuration completion. This document is mainly intended to summarize the actual state, the ideas behind individual steps of the reasoning process and the decisions made for realizing the reasoning. Besides the pure technical documentation, our specific contributions are: - -\begin{itemize} - \item An IVML-complete reasoning mechanism, i.e., translation and reasoning for a complex, rich and typed variability modeling language. - \item Support for IVML type refinements, which can cause implicit effects on the application of constraints. IVML allows defining a type hierarchy, and so the potential types for a configuration option, i.e., a typed variable, can change along the type hierarchy. As types can introduce constraints, the actual constraint base considered during reasoning can change, i.e., constraints must be added or removed as an effect of a value type change. - \item Support for IVML constraint variables, i.e., variables that hold constraints (including sets or sequences) and be changed by the configuration. Through constraint variables, IVML explicitly allows introducing, adding, removing and disabling constraints. Consequently, such changes can affect the constraint base considered during reasoning. - \item Instantiation of type-based constraints to variable-based constraints as a basis for a subsequent reasoning chain. For such subsequent reasoners, the IVML reasoner provides a solid basis, detailed error messages including the failed instantiated constraints so that a chained reasoner can directly continue with these constraints. We envision for future work, that further reasoning steps may add complementing reasoning functions such as identifying a value from narrowing constraints. -\end{itemize} - -This document is structured as follows: Section \ref{sectApproach} provides an overview to our approach. Section \ref{sectNotation} introduces the notation that we use throughout this document to specify the algorithms, i.e., we introduce notations for sets, sequences, substitutions as well as relevant parts of the IVML object model realizing the various IVML concepts, here in terms of notations for accessing (derived) properties of the IVML model. In Section \ref{sectReasoning}, we discuss the top-level algorithms for transforming constraints and reasoning. In Section \ref{sectTranslation}, we detail the translation of constraints for all IVML modeling concepts. The result is a set of instantiated constraints that can be used for reasoning. Section \ref{sectTranslation} includes also the mechanism for re-scheduling constraints when value types or constraint variables change, as this mechanism heavily relies on the constraint translations discussed before. In Section \ref{sectCompleteness}, we analyze the translations in order to assess their completeness with respect to IVML concepts and indicate the state of the validation, i.e., regression test cases checking that the constraint translations are applied correctly for specific modeling situations. In Section \ref{sectEvaluation}, we present an evaluation of the actual performance of the reasoning approach for different kinds of IVML models. In Section \ref{sectPerformance}, we summarize performance issues, findings and resolutions we made while revising the reasoner, in particular to avoid that future modifications violate already resolved performance anti-patterns. Finally, in Section \ref{sectConclusion} we conclude and provide an outlook on future work. - -%----------------------------------------------------------------------------------------------------------------- - -\section{Approach}\label{sectApproach} - -IVML is a textual variability and configuration modeling language. The syntax of IVML, which is mostly out of scope here (please refer to~\cite{IVML-LS} for the complete specification), is based on well known (programming) language concepts and can be used to express the (meta-)model of a configuration as well as individual configurations. The main concept of IVML is the \emph{typed variable}, which may have a default value expression. For short, IVML offers basic types (Boolean, Integer, Real, String), user-defined compound types (groups of variables, can be subject to multi-inheritance), container types (set, sequence), derived types (constraining or aliasing another type) and constraint types, i.e. variables holding a constraint so that it can be overridden by assigning a new constraint. IVML variables can be further detailed by and interrelated with other variables through constraints. The constraint (expression) language is largely inspired by concepts (and notation) of the Object Constraint Language (OCL)~\cite{OCL24}, but, in contrast to OCL, allows side-effect to enable the definition of configurations as well as the propagation of configuration values. IVML models (given in terms of so called \IVML{projects}), can be imported, staged~\cite{CzarneckiHelsenEisenecker05a} and conditionally frozen, in particular to enable partial instantiation of code, including removal of variation points. - -Over the last years, we approached the analysis and reasoning for IVML from different perspectives, including traditional reasoning mechanisms or rule engines~\cite{QMD42}. Although these mechanisms are powerful in their own respect and typically available as implementation, using them for IVML requires translating an IVML model and its constraints into the model of the respective reasoning mechanism and executing that mechanism on the translated model. In the past, we identified in particular this transformation as performance bottleneck as well as an obstacle to achieve IVML-completeness, i.e., we were often not able to express all IVML concepts in the respective reasoner model. While traditional reasoners allow for completing a model through feasible ground instances, they typically also perform a kind of constrained state space exploration. Considering the size of usual configuration models (currently the largest IVML model we are aware of has more than 16.000 variables~\cite{EichelbergerQinSizonenko+16, EichelbergerQinSchmid17a}), we experienced that just applying a traditional reasoner to usual IVML models is an inefficient approach. Other related mechanisms such as rule engines can be applied to some degree, however, according to our experience~\cite{EichelbergerQinSizonenko+16, QMD42, QMD43} lead to a significant and infeasible runtime overhead. Moreover, traditional reasoners as well as rule engines are limited as they typically do not support the range of OCL operations required for IVML, in particular container iterators, quantifiers and user-defined constraint operations. Further, also specific reasoning approaches, e.g., for the Object Web Language (OWL)~\cite{KahnPorres15, KolliaGlimmHorrocks11} might be an option as they partially support quantification, but they are similarly limited regarding the range of OCL operations. Moreover, OCL-based approaches such as~\cite{DemuthLoecherZschaler04, ClavelEgea06} typically also focus on forward-chaining, but would require deep extensions, as OCL does not allow for side-effects or value propagation as required by IVML. - -Due to these experiences, we decided to pursue a \emph{mixed reasoning approach}, which attempts to reduce / simplify the reasoning problem towards an instance that (if needed) can finally be handled by a traditional reasoning approach. In our case, the basis for a mixed approach is \emph{forward-chaining}, i.e., evaluation of a given constraint base as long as no constraints are left over, while re-scheduling constraints that depend on a variable changed during reasoning. The SSE IVML reasoner as described in this document realizes this basis, while the actual mixed approach is part of future work. Other work also combine multiple reasoning approaches to achieve advanced reasoning capabilities, e.g., evolutionary algorithms with SAT-solving to realize many-objective optimization for feature modeling~\cite{XiangZhouZheng+2018}. - -It is important to notice that IVML~\cite{IVML-LS} supports declarative specification of constraints, i.e., modeling concepts and constraints can be specified regardless of their actual evaluation sequence. To ensure that values for variables are uniquely determined, in particular in presence of default values, IVML allows changing the value of a variable only once within a project scope. Otherwise the reasoning mechanism must issue an error. Thus, reasoning must happen project-wise, in a depth-first traversal along the project import dependencies. Moreover, to speed up reasoning in specific situations, some form of sequence of the constraints can be indicated through the concept of partial evaluations, i.e., eval-blocks stated within a project or a compound. An eval-block consists of constraints or nested eval-blocks, while nested eval-blocks implicitly define an evaluation sequence. In other words, a project is the outermost (implicit) eval-block and nested eval-blocks shall be evaluated in their nesting sequence, while eval-blocks on the same nesting level do not imply any evaluation sequence. - -However, not all IVML constraints can be directly used for reasoning. This is in particular true for constraints defined in compound types, i.e., these constraints must hold for all instances, or, indirectly, through types used within collections, i.e., these constraints must hold for the respective collection elements. Such constraints typically utilize local variables defined within the compound including the special pre-defined variable \IVML{self} pointing to the actual compound instance. Allowing such implicit constraints rather than requiring that all constraints are defined directly on the configuration variables increases consistency and helps reducing model sizes and complexity. -%Cross-references to other types are required to be specified through an explicit accessor, i.e., an expression mentioning the variable and the respective nested variable(s). -As a consequence, the reasoning mechanism must relate type-based constraints to the correct underlying configuration variables. In our approach, we perform first a \emph{constraint translation} to instantiate the constraints for configuration variables based on the actual type of the variable or its value. An alternative could be reasoning over type constraints and modifying the mapping to the variables on demand before evaluation. This may save memory and runtime (required for constraint translation / creation), but, however, also increases the complexity of managing the actual constraints to be evaluated. - -Based on our experience~\cite{EichelbergerQinSizonenko+16, QMD42, QMD43} and taking into account the specific requirements of the default values, project scopes, eval-block scopes, we are convinced that (at least the first step in a mixed reasoning approach) shall directly operate on an IVML model, also to achieve a high runtime performance. In particular, model transformations such as the constraint translation shall happen only if required to reduce overhead on the reasoning time. After the required constraint translation, constraint evaluation and forward-chaining is executed on the collected constraint base. Besides the resulting configuration, \emph{detained reasoning output} is required, so that subsequent reasoners in a reasoning chain can continue on the results. For this purpose, reasoning error messages shall not only contain the failed constraint, but also additional information such as failing sub-expressions. Based on such output, we can imagine that more advanced reasoning engines such as SMT-reasoners could complement the described approach. Translating the information about failed constraints into a model that is suitable for sophisticated reasoning approaches could enable advanced capabilities, such as value determination, instance creation or configuration completion / repair. However, such chained reasoning is out of the scope of this document. - -Basically, reasoning over all variables of a project including all constraints is needed. This may differ for certain use cases where considering all constraints neither required nor efficient in terms of reasoning time. The first use case is \emph{incremental reasoning}, i.e., starting with a given configuration and just analyzing the changes made by the user. The idea is to provide immediate reasoning results, so that reasoning even on complex and large models can happen upon every change made by the user. The second use case is \emph{runtime reasoning}, e.g., reasoning for validity of a configuration at runtime of a system to identify validations and to trigger re-configuration or adaptation~\cite{Eichelberger16}. In this case, we may assume that the underlying IVML model is not changed, so that initially translated constraints can be re-used. This assumption may does not hold in the incremental reasoning case. For supporting these two cases, we introduce two main \emph{reasoning modes}, namely complete (full) reasoning and incremental reasoning, while incremental reasoning can be achieved through the following two techniques. -\begin{itemize} - \item \emph{Creation of a partial constraint base:} Constraints assigning already processed default values or constraints over variables that cannot change anymore (frozen variables) are not added to the constraint base. The remaining configuration variables are assumed to be properly initialized or shall be instantiated by the reasoner if possible. Thus, reasoning focuses on non-frozen variables\footnote{In EASy-Producer, this technique can be enabled through the reasoner configuration.}, in particular changed variables. In our experiments, this mechanism can save up to 65\% reasoning time. - \item \emph{Re-using a previously created constraint base:} The initial constraint base created by the constraint translation is stored in memory and re-stored when applying the reasoner again to the same (structurally unchanged) model, i.e., we require that no new types or variables are added between two reasoning runs. This technique\footnote{This technique can be applied by requesting a re-usable reasoner instance from the EASy-Producer reasoner core and by using that instance instead of the default interface provided by the static reasoning fronted.} trades off reasoning time for memory consumption and can even be combined with creating a partial constraint base, saving up to further 75\% reasoning time. -\end{itemize} - -To implement the IVML reasoner, we first designed and realized an \emph{expression evaluation mechanism}, which is able to evaluate individual IVML expressions. The evaluation mechanisms covers constraint expressions (expressions evaluating to a Boolean value) as well as general default value expressions. The reasoner relies on that mechanism, i.e., in the algorithms described in this document, we just refer to the evaluation mechanism without further detailing it. We assume that the mechanism either returns the correctly evaluated value of an expression with respect to a given model / configuration or that it indicates that the evaluation result is undefined, e.g., as configuration variables used in the evaluated expression are undefined. - -%----------------------------------------------------------------------------------------------------------------- - -\section{Notation and Terminology}\label{sectNotation} - -In this section, we define the notation and terminology that we use for explaining the reasoning process and the constraint translation. - -\subsection{General notation}\label{sectGeneralNotation} - -In general, we use $\undef$ to denote an \emph{undefined result/value}. Unless stated otherwise, we assume, that operations return a meaningful result even if $\undef$ is passed in as parameter. - -As usual, we denote a \emph{set} of elements by $s=\set{1, 2, ...}$ with no duplicates allowed. \emptySet{} is the empty set. We denote the derivation of set $s_1$ from another set $s$ by $s_1=\setWith{i+1}{i\in s}$, i.e., $s_1$ is derived from $s$ by iterating over and determining a new value for all elements $i$ in $s$, here through $i+1$. In this notation, conditions / projections may apply to the source set $s_1$. Further, $s_2 = s \cup s_1$ denotes the union of the two sets $s$ and $s_1$, i.e., $s_2$ contains all elements from $s_1$ and $s_2$ without duplicates. For convenience, we assume for a set $s_3$ that $s_3\text{ } \cup \undef = s_3$. - -For some parts of the reasoning algorithm, in particular to prioritize the evaluation of different constraint types and eval-blocks, we need \emph{sequences}, i.e., structures that hold elements in a given sequence as well as potentially duplicates of the elements. The the order is defined when adding / inserting elements to a sequence. We denote a sequence by $q=\seq{2, 1, ...}$ and \emptySeq{} as the empty sequence. Akin to sets, we denote the derivation of a sequence $q_1$ from another sequence $q$ preserving the order of elements in $q$ by $q_1=\seqWith{i+1}{i \in q}$. Accessing the $i$-th element in sequence $q$ is expressed by $q[i]$. Further, we denote the sequence concatenation by $q_2=q \addSeq q_1$, i.e., $q_2$ contains all elements (including duplicates) from $q$ and $q_1$, first the elements from $q$ in the sequence of $q$, then the elements from $q_1$ in their sequence of $q_1$. Moreover, we use $q_3=q \addSeqNoDupl q_d$ to denote a sequence concatenation of $q$ and $q_d$ omitting all occurring duplicates. - -In some cases, we also need to express a \emph{mapping} between key elements and associated value elements. We denote such a mapping as a set of pairs $\mapEntry{k}{v}$ relating a key $k$ to a value $v$. Within a mapping, key-value pairs are unique with respect to the key. We denote adding a key-value pair to a map by $m \addMap \mapEntry{k}{v}$, assuming that an existing entry for $k$ (accessed by $m[k]$) is overridden by the new entry. If there is no mapping for a certain key, $m[k]$ is $\undef$. Iterating over a map means iterating over the entries of a map. - -As this document is intended to detail the actual implementation and to ease mapping from code to algorithms and back, we use for the \emph{algorithms} (where feasible from the space / layout point of view) the actual name from the implementation. Further, we use parameters and return values as done in the implementation. If global, static or instance data is used, we indicate this in `data' section of the respective algorithm description. For simplifying the reading, we treat null values that may occur in the implementation either through $\undef$ or just omit null pointers and the respective checks needed in the code, i.e., unless stated otherwise, functions return then $\undef$ or, in case of set or sets or sequences $\emptySet$ or $\emptySeq$, respectively. - -\subsection{IVML elements} -In this section, we discuss the IVML elements and types that are relevant for IVML reasoning. For these elements and types we introduce functions to access their respective properties. We focus here on functions that are used for specifying the reasoning algorithm rather than all functions that are defined in the IVML object model. - -As a convention to ease reading the algorithms presented later, we use $d$ for variable declarations, $v$ for configuration variables, $t$ for types, $val$ for a values, $c$ for constraints and $cfg$ for configurations consisting of decision variables and their assigned values. For temporary/local variables, we typically use a name close by, e.g., $w$ for an iterator variable (instead of $v$) etc. If not indicated otherwise, all operations introduced below that are bound to a certain type, e.g., an IVML compound, return $\undef$ if the operation is used with another type, e.g., an IVML basic type. - -For all IVML elements introduced in the following subsections, we denote the set of constraints\footnote{Duplicates do not matter in this document as constraints are usually rather unique structures. The only effects of duplicates could be unintended re-evaluations or unintended multiple error messages for the duplicated constraints.} defined for element $e$ by $constraints(e)$. Let $s$ be a set of elements, then $constraints(s) = \setWith{constraints(t)}{t\in s}$. Further, for a model element $e$, $parent(e)$ denotes the model element $e$ is nested within, typically, a compound or a project. - -\subsubsection{Variable Declarations}\label{sectNotationVarDecls} - -An IVML \emph{variable declaration} $d$ is defined through a $name(d)$ and a $type(d)$.~$default(d)$ is an optional expression specifying the default value of $d$, whereby $default(d)$ must evaluate to a value of a type compatible with $type(d)$. $isDeclaration(d)$ is true for a variable declaration $d$. - -$annotations(d)$ denotes the set of (orthogonal) IVML annotation (variable) declarations for $d$ and $isAnnotation(d)$ returns whether a variable declaration is an annotation. $annotations(d)=\emptySet$ if $d$ does not define any annotations. Further, $annotation(d, n)$ indicates whether for declaration $d$ an annotation $a$ with name $n$ is defined. -% -$$ - annotation(d, n) = \begin{cases}a & \text{if }annotations(d) \wedge name(a)=n\\ - \undef & \text{else}\end{cases} -$$ -% -\begin{multline*} - annotations^+(e) = \begin{cases} - annotations(e) &\text{if } parent(e) = \undef \\ - annotations(e)\text{ } \cup\\\text{ }annotations(parent(e)) &\text{else} -\end{cases} -\end{multline*} -returns all declared annotations for an arbitrary model element $e$. - -\subsubsection{Configuration Variables}\label{sectNotationConfigVars} - -While variable declarations as introduced in Section \ref{sectNotationVarDecls} as well as types as introduced below allow defining (a meta-model of) configuration options, \emph{configuration variables} are part of the configuration of a specific product and hold the actual configured value for a variable declaration. A configuration variable $v$ (representing a decision, inspired by decision modeling~\cite{CzarneckiGruenbacherRabiser+12, SchmidJohn04}) is defined through a variable declaration $d$, but for a single variable declaration $d$ in a model, multiple configuration variables can exist in different configurations. - -Let $v$ be a configuration variable with declaration $d$ as part of a certain configuration $cfg$, i.e., $decision(cfg, d)=v$ and $parent(v)=cfg$. For such a combination of declaration $d$ and variable $v$, we define $declaration(v) = d$ as well as $type(v) = type(declaration(v))$. For a variable $v$, the function $isVariable(v)$ returns $true$, for any other IVML element/type $false$. - -$value(v)$ denotes the actual value of $v$ and $type(value(v))$ compliant with $type(v)$. Please note, that $type(value(v))$ can be a subtype of $type(v)$, in particular if $type(v)$ is a refined type through inheritance (cf.~\cite{IVML-LS} for details on the IVML type compliance rules and the IVML type hierarchy). We will detail some relevant properties of values below in Section \ref{sectNotationValues}. - -As some IVML types allow a nesting of configuration variables, we generically define $nested(v)$ as the set of all variables nested in $v$. Of course, $nested(v)=\emptySet$ if no nested variables are defined on $v$, $type(v)$ or $type(value(v))$. For a variable $v$, $\forall_{w\in nested(v)}\text{ } parent(w)=v$ must hold. Moreover, let $nested(v, n)$ be the nested variable in $v$ with name $n$, while $nested(v, n)=\undef$ if no such variable is defined. For convenience, we also define -% -\begin{multline*} -allNested(v) = \begin{cases} - \emptySet, & \text{if } |nested(v)| = 0 \\ - \begin{aligned}\set{&nested(v)}~\cup\\ &\setWith{allNested(w)}{w\in nested(v)},\end{aligned} & \text{else}\\ \end{cases} -\end{multline*} -% -\begin{multline*} -allParents(v) = \begin{cases} - \emptySet, & \text{if } \neg isVariable(parent(v)) \\ - \begin{aligned}\set{&parent(v)} \cup\\ &allParents(parent(v)),\end{aligned} & \text{else}\\ \end{cases} -\end{multline*} -% -Akin to variable declarations, $annotations(v)$ returns the set of actual annotation variables for variable $v$. Please note that there is a significant difference between $annotations(d)$ for a variable declaration $d$ and\linebreak[4]$annotations(decision(cfg,d))$, as a declaration only holds the specifically declared attributes for $d$, while a variable is instantiated with all annotations potentially inherited from containing project or variables (in case of compounds or containers). - -Due to the specific semantics of default or frozen variables, IVML variables have an \emph{assignment state} that be accessed via $state(v)$. The state of individual variables is changes (indirectly) when values are assigned, e.g., as as a side effect of constraint evaluation. The following states are defined: - -\begin{itemize} - \item \IVML{UNDEFINED}: No value has been assigned so far or the value was cleared intentionally through assigning the IVML constant value \IVML{null}. - \item \IVML{DEFAULT}: A type compatible default value has been assigned by evaluating the default value expression of the underlying variable declaration. Default values can be changed unless frozen, but not more than once within the same project scope. - \item \IVML{ASSIGNED}: A type compatible value has been assigned (by some EASy-Producer component). The value can still be changed, but not more than once within the same project scope. - \item \IVML{USER\_ASSIGNED}: A type compatible value has been assigned by the user and shall not be overridden, e.g., by the reasoner. - \item \IVML{DERIVED}: A type compatible value has been assigned as a side effect of reasoning and constraint evaluation. - \item \IVML{FROZEN}: The variable was frozen through the IVML \IVML{freeze} statement to avoid further changes of the actual value (including no value in state \IVML{UNDEFINED}). Further assignments are not allowed and cause an assignment error irrespective of the actual scope. -\end{itemize} - -Variables can be \emph{local}, e.g., as they are used in the IVML model as parameters of a user-defined constraint function, as variable in a let let-expression or as an iterator of a collection function. Such variables have the same properties as usual configuration variables, but they just hold a temporary value, may be re-assigned within a certain scope, e.g., iterator variables, typically have the state \IVML{ASSIGNED} and cannot be frozen. Local variables can be identified using $isLocal(v)$, which returns $true$ if $v$ is a local variable. - -%For simplifying the descriptions of algorithms, we ignore here the fact that IVML variables can have the IVML value \IVML{null}, i.e., explicitly undefined (and different from a null pointer). While the underlying implementation must contain explicit checks, we just assume here that the functions lead to $\undef$, \emptySet or \seq{\text{}}, respectively. - -\subsubsection{Project}\label{sectNotationProject} - -A \emph{project} is a named scope, which can contain variable declarations, type declarations, assignment-blocks and eval-blocks. $decls(p)$ denotes the set of all variable declarations introduced in project $p$. $isProject(p)$ returns $true$ for a project $p$. - -$evals(p)$ is the set of (potentially nested) \emph{eval-blocks} in project $p$. If $e\in evals(p)$ then $constraints(e)$ returns the constraints listed in $e$, whereby $constraints(e)$ may be empty, in particular if $e$ is an arbitrary model element. Similarly, $evals(e)$ returns the nested eval-blocks. Subsequently, the function $allEvalConstraints(e)$ returns all constraints in eval-block $e$ including all nested eval-blocks. -% -\begin{align*} -all&EvalConstraints(e) = \\ - &constraints(e) \cup \setWith{allEvalConstraints(f)}{f \in evals(e)} -\end{align*} -% -In IVML, an \emph{annotation assignment} is a kind of block, which allows assigning annotation values to the variables defined within the block, i.e., the specified annotation values shall be applied to all contained variable declarations. The declared variables shall behave as if they are defined in the innermost containing element that is not an annotation assignment. For convenience, also constraints relating to the contained variable declarations can be stated within an annotation assignment. To indicate orthogonal combinations of annotation assignments in IVML models, annotation assignments can be nested referring to different annotations. For convenience, only the innermost annotation value assignment shall be applied in nested assignment blocks in order to avoid accidental multiple assignments to the same annotation within the same project scope. - -$assignments(p)$ is the set of (potentially nested) annotation assignments of project $p$. If $a\in assignments(p)$ then $decls(a)$ returns the variables declared in $a$ and $constraints(a)$ the constraints declared within $a$. Further, $assignments(a)$ returns the annotation assignments nested within $a$. All three results may be empty. Further, $assignmentData(a)$ provides access to the affected annotations and the intended values values, i.e., if $f \in assignmentData(a)$ then $name(f)$ is the name of the affected attribute and $default(f)$ the intended default value expression that shall be assigned to all attributes with name $name(f)$ for all declarations within the containing assignment-block. $isAnnotationAssng(a)=true$ and for an arbitrary model element $e$, $isAnnotationAssng(e)$ returns whether $e$ is an assignment block. - -Using these functions, $allAssignmentConstraints(a)$ determines all assignment constraints within an assignment $a$ considering potentially further nested annotation assignments: -% -\begin{align*} -all&AssignmentConstraints(a) = \\ - &constraints(a) \cup \setWith{allAssignmentConstraints(b)}{b \in assignments(a)} -\end{align*} -% -In some algorithms we need to determine an attribute attribute declaration with name $n$ that is directly attributed to variable $v$ or one of the containing scopes of $v$. While for nested variables, we can just take the parent variables into account, this ends with the containing project. For ease of access, we (internally) represent a project as a (pseudo-)variable $variable(p)$ containing all variables declared by the project as nested variable. Then -% -\begin{multline*} -findAnnotation(v, n) = \\ \ \ \begin{cases} - annotation(v, n) &\text{if } annotation(v, n) \neq \undef\\ - findAnnotation(parent(v), n) &\text{if } isVariable(parent(v))\\ - findAnnotation(variable(parent(v)), n) &\text{if } isProject(parent(v))\\ - \undef & \text{else} \\ - \end{cases} -\end{multline*} -% -returns the innermost annotation for variable $v$ with name $n$. -% -\subsubsection{Constraints}\label{sectNotationConstraints} - -In IVML, a \emph{constraint} is a Boolean expression that must always evaluate to $true$. Otherwise, reasoning shall either fail. After a change of at least one of the values of the variables involved in the constraint, the constraint may be re-evaluated successfully, causing a cleanup of previous reasoning errors for that constraint. - -Technically, a constraint is an expression, which may consist of several (sub-)expressions, such as constants, variable uses, or function calls. An expression $e$ evaluates to a value of some IVML type, i.e., $type(e)$ returns the static value type of an expression. In particular, let $c$ be a constraint then $type(c) = \IVML{Boolean}$. Expressions are used to determine the default value of variables. Let $v$ be a variable then we denote by $e(v)$ that expression $e$ is using variable $v$ and by $var(e)$ the set of variables used in $e$. Moreover, if $c$ is an assignment constraint representing $x = y$, the $rightSide(c) = y$ returns the right side expression $y$, else $\undef$. If $e$ represents a constant, $const(e)$ returns the constant value, else $\undef$. - -Moreover, \IVML{Constraint} is an IVML type, indicating that a variable actually holds a constraint. From the reasoning point of view, a constraint stored as a value of a constraint variable is extracted and then evaluated as any other constraint. However, the value in such a variable may, as for all other variables, be undefined, frozen, or re-defined (once per project scope) implying that the old constraint must be discarded or even replaced by the new constraint value and considered in the subsequent reasoning process. $isConstraint(t)$ indicates whether type $t$ is a constraint type. %$isAssignmentConstraint(c)$ indicates whether constraint $c$ is supposed to unconditionally change the value of a variable through an assignment, e.g., for an integer variable \IVML{x} the constraint \IVML{x = 25;} in IVML notation is an assignment Constraint. - -During the constraint instantiation, variables must be substituted by other variables or expressions. Let $c$ be a constraint and \IVML{y} be some IVML variable. Then $\varSubstitution{c}{x = y}$ leads to the substitution of all variables named \IVML{x} by \IVML{y}. For example, if the constraint $c$ was before the substitution \IVML{x = 25}, it will be \IVML{y = 25} after the substitution. The right side of a substitution can be a variable or, more generally, an expression. Substitutions are transitive, i.e., in $\varSubstitution{c}{x=y,y=z}$ $x$ will be replaced by $z$. If the right side of a substitution is $\undef$, no substitution happens, e.g., in $\varSubstitution{c}{x = \undef}$. Substitutions can also be expressed in terms of a mapping to express multiple substitutions or to create up / reuse the substitution specification for several constraints. Let $\variableMapping=\set{\mapEntry{x}{e}}$ be a mapping, then $x$ is the variable to be replaced, $e$ the replacing variable/expression and $\varSubstitutionVarMapping{c}$ denotes the respective substitution. Both notations can be combined, e.g., to $\varSubstitutionOtherVarMapping{c}{x = y}$. - -During the constraint instantiation, also new constraints must be created. For this purpose, we use a specific notation to indicate constraint creation and the construction of sub-expressions. This notation combines algorithm elements, e.g., variables, carrying actual values/elements (written in mathematical notation) and IVML expression constructors (stated in teletype). For example, for creating the IVML constraint \IVML{x = 25;} we write $\createConstraint{\IVML{assign(x, 25)}}$. The angle brackets indicate a constraint creation, the contents of the brackets the creation of the expression making up the constraint. Here, \IVML{assng} is the constructor for the assign operation defined by IVML (actually implementing the assignment in \IVML{x = 25}) returning a Boolean value indicating whether the execution of the operation succeeded. In an algorithm, we may generically denote $\createConstraint{\IVML{assign}(x, 25)}$, with $x$ being determined by the algorithm. - - -As usual in IVML, we denote the creation of collection operations using the arrow and iterator notation. However, as we use the '$|$' symbol for variable substitutions, also using the same symbol in IVML quantor expressions may be confusing. Thus, we use in this document ':' instead of '$|$', e.g., we denote \IVML{forall(x:$c(x)$)} to indicate the construction of an all-quantized expression over a constraint using the quantor iterator variable $x$ instead of \IVML{forall(x|$c(x)$)}. In summary, let \IVML{o} be an IVML collection of Integers, then \IVML{o->forall(i:i>20);} requires that all values in $o$ must be greater than 20. To create such a constraint with $o$ being an algorithm variable, we denote $\createConstraint{o\IVML{->forall(i:i>20)}}$. - -To perform specific instantiations, the reasoning mechanism must classify constraints, in particular default value assignments over usual constraints. We indicate default value constraints by `$d$' in the constraint creation notation. For example, for creating a default constraint, we denote $\createDefaultConstraint{\IVML{assign}(x, 25)}$ for which the operation $\isDefaultConstraintName$ returns $true$. Further, we allow attaching additional information to a constraint, e.g., the type it was created for. Let $c$ be a constraint, then $attach(c, t)$ is an operation that attaches $t$ to constraint $c$ and returns $c$. The operation $attached(c)$ return the respective attachment. -%Similarly, we denote creating a constraint originating from a constraint variable by `$c$', e.g., $b \assng \createConstraintConstraint{\IVML{assign}(x, 25)}$ for which $\isConstraintConstraint{b} = true$ holds. - -In some cases, constraints cannot be created in terms of a single step, i.e., sub-expressions are created iteratively. To indicate this, we denote the creation of an expression by $\createExpression{expr}$, e.g., $\createExpression{\IVML{add}(x, 25)}$ for the IVML expression \IVML{x + 25}. When creating expressions, in particular in an incremental fashion, sometimes a temporary (local) IVML variable is needed, e.g., for an IVML let-expression or a container iterator. We state the creation of such a variable by $\IVMLMeta{var}(t)$, i.e., request the creation of a temporary variable\footnote{We don't care for the variable name in this document.} of type $t$. For a variable $v=\IVMLMeta{var}(t)$ holds $isLocal(v) = true$. - -Before reasoning over the constraints given in an IVML project, several kinds of constraints must be transformed, in particular to instantiate constraints defined for types through qualifying access expressions based on top-level variables. To illustrate the transformations performed by an algorithm in this document, we apply constraint transformation patterns. A \emph{constraint transformation pattern} indicates how a certain IVML model fragment is instantiated to a corresponding constraint given in IVML constraint notation rather than the algorithm notation for creating constraints introduced in this section. The model fragment acting as prerequisite is given on the left side of the derivation symbol $\patternDerivationSymbol$, the corresponding constraint on the right side of $\patternDerivationSymbol$. In such a pattern, variable parts are given in italics to indicate the information flow between both sides. Constant parts are given in normal font, IVML syntax in \IVML{teletype}. One or more transformation patterns are displayed in a gray box. For example, the pattern below indicates that an IVML declaration for variable $v$ (with type $T$ and default value expression $deflt$) is translated into an assignment constraint, which assigns the (value of the) default expression $deflt$ to $v$. - -\grayPara{ -\begin{gather*} - \patternDerivation{T \text{ } v = deflt\IVML{;}}{v = deflt} \\ -\end{gather*} -} - - -\subsubsection{Compounds}\label{sectNotationCompounds} - -A \emph{compound} is an IVML type, which consists of nested variable declarations, called slots. Let $t$ be a compound type, then $isCompound(t)$ returns $true$ and $false$ for all other types. The declared slots of a compound $t$ can be accessed through $slots(t)$. Akin to a variable declaration, for slot $s$ $name(s)$, $default(s)$ and $type(s)$ are defined. - -Compounds can form an inheritance hierarchy. $refines(t)$ represents the set of compound types directly refined by compound $t$ through multi-inheritance, returning an empty set if there are no such compounds or if $t$ is not a compound type. Individual slots from parent compounds can thereby shadowed / redefined by slots of the same or more specific type. We define -% -$$allRefines(t) = - \begin{cases} - \emptySet, & \text{if } refines(t) = \emptySet \\ - \begin{aligned}all&Refines(t)~\cup\\ &\bigcup_{u\in refines(t)} allRefines(u),\end{aligned} & \text{else} - \end{cases} - $$ -% -as the set of all refined compounds along the compound refinement hierarchy of $t$ and -% -$$allRefines^+(t) = - \begin{cases} - allRefines(t) \cup \set{t}, & \text{if } isCompound(t) \\ - \emptySet, & \text{else} - \end{cases}$$ -% -as the set of all refined compounds along the compound refinement hierarchy of $t$ including $t$ itself. Let $t$ and $s$ be compound types. Then we denote $\subTypeOf{t}{s}$ if $t\in allRefines(s)$, i.e., $s$ is a subtype of $t$. Similarly, $\subTypeEqOf{t}{s}$ if $t\in allRefines^+(s)$. Based on these functions, the set of all slots for compound type $t$ can be obtained by -% -$$slots^+(t) = \setWith{slots(r)}{r\in allRefines^+(t)}$$ - -A compound $t$ can define own nested assignment blocks $assignments(t)$ (related functions are defined for compounds akin to Section \ref{sectNotationProject}) and constraints $constraints(t)$. All declared compound constraints -%\footnote{The implementation unifies $allCompoundConstraints(t)$ with $allVariableConstraints(t)$ distinguished by a boolean parameter. We differentiate them here to indicate the sets to be transformed more clearly.} -for compound type $t$ are -% -\begin{align*} -all&CompoundConstraints(t) = \\ - &\setWith{constraints(s) \cup allAssignmentConstraints(s)}{s \in allRefines^+(t)} -\end{align*} -% -%and all constraints stemming from constraint variables for $t$ -%% -%\begin{align*} -%all&VariableConstraints(t) = \setWith{\createConstraint{s}}{s\in slots^+(t) \wedge isConstraint(type(s))}\text{ } -%\end{align*} -%% - -Let $v$ be a compound variable, i.e., a variable of a compound type $t$. Then $decision(v, s)$ returns the configuration variable representing slot $s$ in the compound variable $v$. As in the implementation, $slots(v)$ returns also all slots inherited from refined compounds including those defined in nested assignment blocks. -% -%For convenience, we introduce a function returning all default slots of a variable $v$ -%% -%$$dfltSlots(v) = \setWith{s}{s\in slots(v) \wedge default(s) \neq \undef}$$ %, compound slots of $v$ having default value expressions, empty for all non-compound types -%% - -% -In some constraint transformations it is important to determine, whether a compound slot is overridden. Let $d$ be a declaration, in particular $d\in slots(t) \wedge isCompund(t)$, then the parent compound of $d$ skipping potentially enclosing nested assignment blocks is -% -\begin{align*} -parent&Compound(d) = \\ - &\begin{cases} - parent(d), & \begin{aligned}\text{if }& parent(d) \neq \undef \wedge{}\\ &isCompound(parent(d)) \end{aligned}\\ - parentCompound(parent(d)), & \text{if } parent(d) \neq \undef \\ - \undef, & \text{else} - \end{cases} -\end{align*} - -and we can determine whether $d$ is overridden / also defined by a refined compound by -% -$$isOverridden(d) = d \in \setWith{slots(r)}{r\in allRefines(parentCompound(d))}$$ - -Akin to projects in Section \ref{sectNotationProject}, $evals(t)$ is defined for a compound type $t$ and returns all eval-blocks nested in $t$. Further, all constraints defined by all nested eval-blocks of $t$ can be obtained using -% -\begin{equation*} - allEvalConstraints(t) = \bigcup_{e\in evals(t)}{allEvalConstraints(e)} -\end{equation*} -% -\emph{Accessors} to compound variables define a path to access a certain slot within a compound variable, i.e., an accessor specifies the variable and the slot / nested slot path to access. Let \IVML{cmp} be an IVML variable of compound type, then an accessor to slot \IVML{slot} defined in \IVML{cmp} looks in IVML notation like \IVML{cmp.slot}. If \IVML{slot} is in turn of compound type, also nested accessors may occur, e.g., \IVML{cmp.slot1.slot2}. For creating such expressions in the constraint translation, we use the IVML access constructor \IVML{acc}. Then, following the expression creation notation from Section \ref{sectNotationConstraints}, creating the first accessor expression can be expressed by $\createExpression{\IVMLMeta{acc}\IVML{(cmp, slot)}}$, while for the second accessor we use $\createExpression{\IVMLMeta{acc}(\IVMLMeta{acc}(\IVML{cmp}, \IVML{slot}),\IVML{slot2})}$. Let $ce$ be an accessor expression, then $compound(e)$ returns the part referring to the compound if $e$ is a compound accessor, $\undef$ else. - -The value of a compound variable can be defined, e.g., as a default value expression or as an assignment constraint, using a complex value expression, a so called \emph{compound initializer}, essentially a name-value mapping. As slots can be in turn of a complex type, e.g., of a compound type, a compound initializer can also contain nested complex values, e.g., nested compound initializers. - -\subsubsection{Containers}\label{sectNotationContainers} - -An IVML \emph{container} is a parametrized type representing a structure that holds an arbitrary number of variables / values. IVML defines two default container types, namely \emph{sequence} (duplicates allowed, order important) and \emph{set} (no duplicates allowed, order irrelevant). The type parameters of a container are not relevant for reasoning, as we can assume that the static type compliance is checked by the IVML object model or the IVML parser before reasoning. - -Let $c$ be a container, then $elements(c)$ denotes the set or sequence of all element values in $c$, respectively. Let type $t$ be a container type, then $isContainer(t)$ returns $true$. Further, $contained(t)$ returns the directly contained type, e.g., for a \IVML{setOf(setOf(Integer))} in IVML notation, $contained(t)$ returns \IVML{setOf(Integer)}. - -We define $isNested(t) = isContainer(contained(t))$ and -% -$$nested^*(t)=\begin{cases}nested^*(contained(t)), & \text{if } isNested(t) \\ contained(t), & \text{else} \\ \end{cases}$$ -% -returning the (innermost) nested type, i.e., for \IVML{setOf(setOf(Integer))} $nested^*(t)$ returns \IVML{Integer}. If $isNested(c)$ is $true$ for a container $c$, $elements(c)$ contains values of the nested type. In some situations, the flattened container is needed, i.e., for nested collections preferrably with the same innermost nested type only the innermost contained values are relevant. For this purpose, $allElements(c)$ returns the transitively flattened elements of the respective container, i.e., set or sequence, i.e., all leaf elements of a depth-first traversal of the containment tree. - -During the constraint translation, we must identify whether a container consists of constraints, i.e., -% -$$isConstraintContainer(t) = isNested(t) \wedge isConstraint(nested^*(t))$$ -% -In other situations, we need to know all actual innermost nested types that are used in a container, i.e., the set -% -$$usedTypes(c) = \setWith{contained(type(e))}{e\in allElements(c)}$$ -% -This is in particular important if $isCompound(nested^*(type(c)))$ holds for a container $c$, as then also values of refined types of $nested^*(type(c))$ may occur in $usedTypes(c)$. - -For containers, \emph{access expressions} usually occur either in quantorized expressions utilizing the iterator variable or if the collection is a sequence (typically of compounds). Then accessing an element by an index happens through the IVML index access function for sequences. For example, let \IVML{seq} be a sequence of compounds, all having a common slot \IVML{slot}. Then \IVML{seq[1]} accesses the second element in the container\footnote{In contrast to OCL, IVML indexes are 0-based.} and accessing \IVML{slot} on the first element happens through \IVML{seq[1].slot}. For creating the respective expression within an algorithm, we denote $\createExpression{\IVMLMeta{acc}(\IVML{seq[1]}, \IVML{slot})}$. - -Akin to compounds, containers can be initialized by complex values, so called \emph{container initializers}, here as a listing of possible complex values. If the container is a sequence, the given order of values in the container initializer used as (initial) order of the sequence elements. - -\subsubsection{Derived types}\label{sectNotationDerivedTypes} - -In IVML, a \emph{derived type} denotes a new type based on an existing type. A derived type can restrict the base type by specifiying constraints. Further, without constraints, a derived type can act as an alias of a type, e.g., a complex container type. - -For a derived type $t$, $isDerived(t)$ returns true and $base(t)$ returns the type $t$ is derived from. For specifying constraints, a derived type $t$ implicitly declares a variable $decl(t)$ of type $base(t)$. Constraint expressions may use $decl(t)$, which must be substituted by a concrete variable during constraint instantiation, as well as any other variable accessible in the actual scope. - -In particular, derived types can be defined based on already existing derived types. In this case, a chain of dependent base types is created, whereby for reasoning typically the most basic type $base^*(t)$ is relevant. -% -$$base^*(t) = \begin{cases}base(t), & \text{if } isDerived(t) \wedge \neg isDerived(base(t)) \\ base^*(base(t)), & \text{if } isDerived(t) \wedge isDerived(base(t)) \\ \undef, & \text{else}\\ \end{cases}$$ -% -For the constraint translation it is relevant to iterate over all base types of such a chain, e.g., and to instantiate their declared constraints. Therefore, we define -% -$$allBase(t) = \begin{cases}\set{base(t)}, & \text{if } isDerived(t) \wedge \neg isDerived(base(t)) \\ \set{base(t)} \cup allBase(base(t)), & \text{if } isDerived(t) \wedge isDerived(base(t))\\ \emptySet, & \text{else}\\ \end{cases}$$ -% -\subsubsection{Other IVML Types}\label{sectNotationOthers} - -No specific constraint translation is needed for \emph{basic types} (Boolean, Integer, Real, String), the constraint type introduced in Section \ref{sectNotationConstraints} as well as for enums, because IVML does not support directly attaching constraints to these types. Constraints for these types can only be defined indirectly as global constraints for variable declarations, as nested compound constraints for compound slots or via derived types as introduced in Section \ref{sectNotationDerivedTypes}. Thus, no specific functions for these types must be discussed here. The available IVML functions and operations for these types, such as adding two integer values, are subject of the creation of expressions / the IVML model, e.g., through the IVML parser as well as of the IVML expression evaluation mechanism, rather than the reasoning algorithms discussed in this document. - -However, IVML \emph{configuration references} require a specific treatment in some situations. In IVML, a configuration reference points to a variable defined in the same or another imported project. A configuration reference is a generic type $t$ defined for the base type $base(t)$ of the variable the reference points to. If $t$ is a reference, $isReference(t)$ returns true. - -As the actual IVML specification~\cite{IVML-LS} does not define specific properties or operations for reference types, we can safely assume that variables of reference types are transparent and just provide access to the referenced variable. In particular, this holds even if constraints are defined on that variable, as they are translated for / evaluated on the referenced variable. For this purpose, we must be able to (sliently) dereference a type $t$ -% -$$deref(t)=\begin{cases} base(t), & \text{if } isDerived(t) \wedge \neg isDerived(base(t))\\ deref(base(t)), & \text{if } isDerived(t) \wedge isDerived(base(t))\\ t, & \text{else}\\\end{cases}$$ -% -and in some cases even a set $s$ of types through -% -$$deref(s)=\setWith{s\in t}{deref(t)}$$ -% - -\subsubsection{IVML Values}\label{sectNotationValues} - -In the IVML object model, IVML types have corresponding typed values, in particular to correctly represent potentially nested complex structured types such as compounds and containers. As the IVML expression evaluator is operating on values, in particular by retrieving them from a configuration, applying IVML operations and storing them back to a configuration, we can mostly neglect the specific properties of IVML values. However, some specific properties must be taken into account for reasoning, which we introduce in this section. - -A value $val$ is typed and, thus, always provides access to its type $type(val)$. In case of a compound variable $v$, the value determines the actual type of $v$, as $\subTypeEqOf{type(value(v))}{type(v)}$. One specific value is \IVML{null}, which is compliant with all types, i.e., can be assigned to any variable to indicate that a variable is (explicitly) not configured. \IVML{null} is certainly different from the undefined value $\undef$: $\undef$ indicates in this context that so far no value has been assigned to a variable and the variable shall have either assignment state \IVML{UNDEFINED} or \IVML{FROZEN}. \IVML{null} wipes out a previously assigned, replaces $\undef$ and the assignment state of a variable with value \IVML{null} shall not be \IVML{UNDEFINED}. - -As introduced in Section \ref{sectNotationConstraints}, a constraint expression may just represent a constant value. This constant value can be obtained from an expression $e$ using $const(e)$, which returns $\undef$ for any expression that is not a constant expression. Further, complex values can consist of nested values, which are accessible through $elements(val)$. In case of a collection value, $allElements(val)$ returns the values of the flattened collection, respectively. To ease the notation of some algorithms, we just assume here that for a non-complex value $val$, $elements(val)=\set{val}$ and, in case of a collection value, $allElements(val)=\set{val}$ else $\set{}$. Further, we assume that $elements(\undef)=\emptySet$ and $allElements(\undef)=\emptySet$. - -In some situations we must either rely on the actual value of a variable (if available) or the default value of the variable, the latter in particular for initializing a configuration through the reasoner. Thus, for a variable $v$ and its declaration $d=decl(v)$, we define\footnote{We follow the style of the implementation for documentation purposes. There, $d$ is typically available via a parameter or a local variable to avoid repeated method calls.} -% -$$ -relevantValue(v, d, inc) = \begin{cases}value(v), & \text{if } value(v) \neq\undef\\ const(default(d)), & \text{if } default(d) \neq\undef \wedge \neg inc\\ \undef, & \text{else}\end{cases} -$$ -% -returning the relevant value of variable $f$ either in terms of its assigned value or its default value, the latter only if we are not in incremental reasoning mode $inc$. -% - -%----------------------------------------------------------------------------------------------------------------- - -% trim={ } -\begin{figure}[h] -\center -%\frame{...} -\includegraphics[scale=0.48,trim={5.1cm 6.2cm 26.5cm 0.3cm},clip]{figures/structure.pdf} -\caption{Structuring blocks, algorithms and sections.} -\label{figStructure} -\end{figure} - -\section{Reasoning algorithm}\label{sectReasoning} - -\newcommand\defaultConstraints[0]{c_d} -\newcommand\deferredDefaultConstraints[0]{c_{dd}} -\newcommand\otherConstraints[0]{c_{o}} -\newcommand\topLevelConstraints[0]{c_{t}} -\newcommand\relevantConstraintsPerDeclaration[0]{r_d} -\newcommand\relevantConstraintVariables[0]{r_c} -\newcommand\scopeAssignments[0]{a} -%\newcommand\usedVariables[0]{u} -\newcommand\problemRecords[0]{m} - -The reasoner performs forward reasoning, i.e., it identifies relevant constraints according to the reasoning mode, translates the constraints, stores constraint relations, evaluates the translated constraints in a loop until all constraints are processed and adjusts/extends the constraint set upon variable value changes. Figure \ref{figStructure} shows the call graph of the reasoner algorithms and the sections where we will discuss them in more detail. Some algorithms call others recursively due to the potentially recursive structure of some IVML types, in particular compounds and containers. Algorithm \ref{algAddConstraint} and \ref{algComposeExpression} appear disconnected, but are called by most of the translation algorithms to populate the constraint base and to compose complex constraints from recursive nesting of containers and compounds. - -This section introduces the top-level reasoning algorithms, in particular the main reasoning loop in Section \ref{sectTopLevelMainReasoningLoop}, the reasoner data structures in Section \ref{sectDataStructures}, the top-level constraint translation in Section \ref{sectTopLevelConstraintsTranslation}, and the top-level constraint evaluation in Section \ref{sectTopLevelConstraintsEvaluation}. The algorithms for constraint translation will be discussed in detailed in Section \ref{sectTranslation} and the algorithms for re-scheduling constraints in Section \ref{sectTopLevelConstraintsRescheduling}. - -\subsection{Main Reasoning Loop}\label{sectTopLevelMainReasoningLoop} - -The main reasoning loop implements the overall control for the IVML reasoning process. The reasoning loop receives a configuration $cfg$ as input and utilizes various global data structures. - -First, Algorithm \ref{algMainLoop} sets up the global configuration variable $cfg$ and the expression evaluator\footnote{In the implementation, the listener for changed variables triggering constraint re-scheduling (Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling}) as well as recording of assigned variables are registered with the expression evaluator. These details are omitted here.} in lines \ref{algMainLoopSetupVar}-\ref{algMainLoopSetupEval} for use with the configuration $cfg$ and the scope assignments $\scopeAssignments$. In line \ref{algMainLoopStartTime} it stores the start time to terminate potentially endless loops induced by ping-pong assignments among constraints within a given maximum time. The remainder of the algorithm is separated into two parts, the full execution (lines \ref{algMainLoopFullStart}-\ref{algMainLoopFullEnd}), and the incremental part (lines \ref{algMainLoopIncStart}-\ref{algMainLoopIncEnd}) utilizing a constraint base prepared and stored while running the first part. - -As shown in Algorithm \ref{algMainLoop}, first structures are created to store constraints for reuse (if $reuse$ is enabled), here for copying the constraint base ($base_c$), the relevant constraints per declaration ($base_{\relevantConstraintsPerDeclaration}$, a mapping of declarations to using constraints) and the relevant constraint variables per decision variable ($base_{\relevantConstraintVariables}$, bidirectional mapping between constraint values assigned to configured decision variables). Then, the reasoner\footnote{In the implementation, translation and reasoning happen in \class{Resolver.java}.} must take the structure of IVML models into account, which is determined by the top-level IVML project making up $cfg$ and a cycle-free traversal of the imports of the top-level project. $discoverProjects(cfg)$ (line \ref{algMainLoopDiscover}, not further detailed in this document), performs a depth-first traversal of the import structure, ignores already seen cyclic imports and returns the processing sequence of all projects involved in $cfg$, i.e., the imported projects sorted in ascending manner according to their number of import dependencies. The loop processes this project sequence as long as no timeout occurred (global flag $hasTimeout$) or the user requests a stop of the reasoning (global flag $stop$). - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{configuration $c$} - \KwData{configuration $cfg$, expression evaluator $e$, scope assignments $\scopeAssignments$, start time $startTime$, $reuse$ flag, constraint relations $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$, constraint base copy $base_c, base_{\relevantConstraintsPerDeclaration}, base_{\relevantConstraintVariables}$, $projects$ sequence, $hasTimeout$ and $stop$ flags}%, problem records $\problemRecords$ - \KwResult{Reasoning result $r$} - - $cfg\assng c$\; \label{algMainLoopSetupVar} - %evaluator.init()\; - %evaluator.setResolutionListener(Algorithm \ref{algVarChange})\; - %evaluator.setScopeAssignments(sAssng)\; - $setup(e, cfg, \scopeAssignments)$\; \label{algMainLoopSetupEval} - $startTime = now()$\;\label{algMainLoopStartTime} - \uIf{$base_c = \undef$}{ \label{algMainLoopFullStart} - \If{$reuse$}{ - $base_c = \emptySeq{}$\; %sequence? - $base_{\relevantConstraintsPerDeclaration} = \emptyMap{}$\; - $base_{\relevantConstraintVariables} = \emptySet{}$\; %map? - } - $projects \assng discoverImports(cfg)$\; \label{algMainLoopDiscover} - \ForAll{$p \iterAssng projects \wedge \neg hasTimeout \wedge \neg stop$}{ \label{algMainLoopStart} - $translateConstraints(p)$\; \label{algMainLoopTranslate} - $evaluateConstraints(p)$\; \label{algMainLoopEvaluate} - $freeze(cfg, p)$\; \label{algMainLoopFreeze} - } \label{algMainLoopEnd}\label{algMainLoopFullEnd} - }\Else {\label{algMainLoopIncStart} - $\relevantConstraintsPerDeclaration \assng base_{\relevantConstraintsPerDeclaration}$\;\label{algMainLoopResetRelStart} - $\relevantConstraintVariables \assng base_{\relevantConstraintVariables}$\;\label{algMainLoopResetRelEnd} - \ForAll{$i \in \set{0, \ldots, |base_c|} \wedge \neg hasTimeout \wedge \neg stop$}{ - $base \assng base_c[i]$\; - $evaluateConstraints(projects[i])$\; - $freeze(cfg, projects[i])$\; - } - }\label{algMainLoopIncEnd} - $r \assng createReasoningResult(m, hasTimeout, stop)$\; \label{algMainLoopResult} - \caption{Main reasoning loop (\IVML{resolve}).}\label{algMainLoop} -\end{algorithm} - - -For each project $p$, the main loop (lines \ref{algMainLoopStart} - \ref{algMainLoopEnd}) translates the constraints in $p$ and populates the constraint base as a side effect of the constraint translation called in line \ref{algMainLoopTranslate} (detailed in Section \ref{sectTopLevelConstraintsTranslation}). If enabled through $reuse$, the constraint translation stores the respective population of constraints in $base_c$ and their relations in $base_{\relevantConstraintsPerDeclaration}$ and $base_{\relevantConstraintVariables}$. Then the algorithm performs a forward-chaining evaluation of the constraint base in line \ref{algMainLoopEvaluate} (explained in Section \ref{sectTopLevelConstraintsEvaluation}). If a constraint changes a configuration variable as a side effect, the constraints related to that variable are re-scheduled for evaluation (detailed by Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling}). As last step for a project $p$, the algorithm freezes the actual values according to the (conditional) freeze-block specifications in $p$ in line \ref{algMainLoopFreeze}. - -In incremental execution (lines \ref{algMainLoopIncStart}-\ref{algMainLoopIncEnd}), it is sufficient to reset the constraint relations in lines \ref{algMainLoopResetRelStart}-\ref{algMainLoopResetRelEnd}, i.e., the mapping of constraints per declaration $\relevantConstraintsPerDeclaration$ and the mapping between constraint variables and decision variables $\relevantConstraintVariables$, to iterate over all stored projects in $base_c$. For each project, the algorithm takes over the respective constraints from $base_c$ into the actual constraint base, and, as before, evaluates the constraints and freezes the variables. - -Finally, after all projects have been considered or the main reasoning loop has been terminated prematurely, the algorithm composes\footnote{In the implementation, this is done in \class{Engine.java}, the actual reasoner instance, which creates and utilizes instances of \class{Resolver.java}.} in line \ref{algMainLoopResult} a detailed reasoning result based on recorded evaluation problems. This reasoning result also indicates a successful or failed execution, in particular whether a timeout occurred or a user-requested cancellation was requested. - -\subsection{Data Structures}\label{sectDataStructures} - -This section introduces the most important data structures needed to describe the operations of the IVML reasoner, namely the variable mapping structure (Section \ref{sectVarMapping}) and the scope assignments structure (Section \ref{sectScopeAssignments}). - -\subsubsection{Variable Mapping}\label{sectVarMapping} - -During the constraint translation, top-level constraints can directly be evaluated over involved top-level variables. As already mentioned in Section \ref{sectNotationConstraints}, constraints defined on compound slots or indirectly through use of compound instances in containers must be translated before evaluation. The particular issue here is that these constraints can be defined in an IVML model over types (for which no values can be assigned in a configuration) rather than over top-level variables. A solution is to rewrite these constraints by substituting type-local variables by appropriate accessors starting at top-level variables. To manage the various lots and access expressions, the translation utilizes a stack-based data structure, onto which we push/pop a context frame for each IVML project and each contained compound type, container type or combinations of both used in variables of a project. A context frame links all currently relevant variables to the correct accessor expressions, which are created before the respective variable substitutions are applied. - -However, a simple stack is not sufficient for two reasons, namely nested complex types, excluded types and assignment blocks. As we will detail below, nested complex types require constraint rewriting through a prefix composed of nested all-quantifiers. Therefore, the stack frames can store the information needed to create the respective quantifier expression. When adding a constraint to the constraint base, we visit the stack frames and, if such information is available, incrementally qualify the expression by the described quantifier. The constraint rescheduling re-uses the constraint transformation. However, performing a complete transformation of all types related to certain value change is typically not needed, so that excluding types from the translation speeds up the re-scheduling operations. Moreover, IVML projects and compounds can contain nested assignment blocks. An assignment block implicitly defines assignment constraints for its contained variable declarations including containers or compounds. If we translate first variable declarations and then the related constraints, these constraints are outside their actual scope and, thus, relevant access expressions are not available, i.e., wrong constraints would be added to the constraint bae. Intermingling compund/container translation with annotation-block translation would be a potential solution, which increases the algorithm / code complexity. Thus, we opted to register a declaration with its context frame (which is then implicitly registered with its parent frame for proper cleanup) and to activate/deactivate such a frame, although it is not on top of the stack, when translating the implicit assignment constraints in an assignment block. Such stack frames are also removed from the stack when popping the respective parent context frame. - -In summary, the variable mapping stack structure $\variableMapping$ of the IVML reasoner provides the following operations: - -\begin{itemize} - \item $setRegisterContexts(\variableMapping, b)$ enables automatic registration of context frames within the parent frame. The operation returns the previous state of the registration flag. - \item $isContextsRegistering(\variableMapping)$ returns whether context registering is currently active. - \item $pushContext(\variableMapping, d, r)$ creates and pushes a new context frame for declaration $d$ to the stack. If registration of contexts is enabled, $r$ indicates whether the new frame shall be registered with the parent frame and whether already processed types (for handling nested complex types) shall be recorded by this context. - \item $pushContext(\variableMapping, d, c,v, r)$ works like $pushContext(\variableMapping, d, r)$, but registers also information for creating an all-quantified constraint prefix for all constraints added to the constraint base as long this frame is on the stack. The information includes the container expression $c$ and the typed iterator variable $v$ over the element type of $c$. We will apply this function in Section \ref{sectContainerDefaults}. - \item $popContext(\variableMapping)$ removes the top-most context frame. The initial frame, which is created by default and devoted to the enclosing IVML project, is not removed by this operation. - \item $registerMapping(\variableMapping, d, ca)$ registers the access expression $ca$ with the given variable declaration $d$ in the top-most context frame. Essentially, a context frame contains a mapping $m$ and the operation performs $m \assng m \addMap \mapEntry{d}{ca}$. - \item $getMapping(\variableMapping, d)$ returns the mapping for $d$. If no mapping was registered for the actual context frame, all context frames in stack order are considered. If no mapping is registered, the result is $\undef$. - \item $recordProcessed(\variableMapping, t)$ records a processed type with the closest containing context having processed type registration enabled. If \linebreak[4] $isCompound(t)$, this function registers $allRefined^+(t)$. - \item $alreadyProcessed(\variableMapping, t)$ returns whether $t$ was already registered as a processed type in one of the enclosing context frames. - \item $activate(\variableMapping, d)$ re-activates, i.e., pushes the registered stack frame for $d$ taken from the current context frame. As long as the current context frame exists, this operation can be called again and again. If no context frame is registered for $d$, the stack is not modified. - \item $deactivate(\variableMapping, d)$ de-activates the registered context frame for $d$, i.e., pops it from the stack but leaves it registered with its parent context frame so that it is available for further activations as long as the parent context frame exists on the stack. - \item $setTypeExcludes(\variableMapping, s)$ defines a set of types to be marked as excluded from constraint transformations. Excluding types is important for a fast processing of re-scheduled constraints in Section \ref{sectTopLevelConstraintsRescheduling}. - \item $transferTypeExcludes(\variableMapping, t)$ transfers excluded types into this context and stores the causing type $t$ in the current context. Transferring excluded types binds them to the actual (usual top-most) type and avoids applying them some nested type. - \item $currentType(\variableMapping)$ returns the type $t$ stored in the current context by $transferTypeExcludes(\variableMapping, t)$. The result is $\undef$ if no transfer happened for the current context. - \item $isTypeExcluded(\variableMapping, t)$ returns whether $t$ is excluded in the current context. $excludedTypes(\variableMapping)$ returns all excluded types for the current context or an empty set. - \item $size(\variableMapping)$ the number of contexts on the stack. There is always at least one context on the stack representing the enclosing project. - \item $clear(\variableMapping)$ clears the stack and cleans up the default context frame dedicated to the IVML project so that $\variableMapping$ is ready for the translation of the next IVML project. -\end{itemize} - -From a black-box perspective, $\variableMapping$ can be considered as a usual map as discussed in Section \ref{sectGeneralNotation}, but performing some stack-based lookup operations. Thus, we just use $\variableMapping$ in the variable substitution notation as introduced in Section \ref{sectNotationConstraints}, e.g., let $e$ be an expression, then $\varSubstitutionVarMapping{e}$ replaces all variables in $e$ having a mapping (through the $getMapping$ operation) in at least on context frame of $\variableMapping$. - -%For translating containers, context frames can store additional information. We will provide details along with the translation of containers in Section \ref{sectContainerDefaults}. - -\subsubsection{Scope Assignments}\label{sectScopeAssignments} - -Due to the potentially nested nature of IVML projects, the knowledge about when an assignment for a variable has been made cannot be maintained by a simple flat mapping. This requires a data structure, which stores information about assignments per project (scope). This structure is important to detect invalid variable re-assignments, i.e., to figure out whether a variable assigned more than once per scope~\cite{IVML-LS}. - -The scope assignments structure of the IVML reasoner (usually named $\scopeAssignments$ for assignments) provides the following operations: - -\begin{itemize} - \item $setAssignmentScope(\scopeAssignments, c)$ defines the scope of constraint $c$ as the actual assignment scope. Adding and checking assignments rely on the actual scope. Here, the scope of $c$ is the top-level parent of $c$, i.e., the containing project. - \item $addAssignment(\scopeAssignments, v)$ indicates that variable $v$ was changed through an assignment within the actual scope. - \item $wasAssigned(\scopeAssignments, v)$ returns whether variable $v$ was assigned in the actual scope. This operation is used to validate an assignment before it is performed out by the expression evaluator. - \item $clearAssignments()$ clears all assignments in all scopes. -\end{itemize} - -\subsection{Top-level Constraints Translation}\label{sectTopLevelConstraintsTranslation} - -The core idea of the constraint translation is to collect the constraints following the structure of an IVML model and to replace each type-related variable by the correct accessor expression for a global variable in the current scope. According to the IVML specification~\cite{IVML-LS}, the relevant top-level elements are variable declarations, global constraints, annotation assignment blocks and eval-blocks. Type definitions are considered when when processing variable declarations, as the individual type of a variable indicates the specific constraints to be collected and instantiated. - -Algorithm \ref{algTranslateConstraints} illustrates the top-level constraint translation. As a side effect, the constraint translation identifies and translates the constraints in the respective project\footnote{The top-translation steps in this algorithm are realized in the implementation by an IVML model visitor implicitly identifying and handling the types without iterating over the project multiple times as the notation here might suggest.}. To prioritize the constraints correctly, the reasoner uses four global sets, which are populated during the constraint translation and, finally, in Algorithm \ref{algTranslateConstraints} added to the constraint base. In more details, the reasoner maintains the following temporary constraint sets - -\begin{enumerate} - \item \emph{Default constraints $\defaultConstraints$} containing constraints setting the default values of all variables. In particular, this set can contain constraints that assign compound and container initializers, i.e., modify multiple values at once. - \item \emph{Deferred default constraints $\deferredDefaultConstraints$} containing default initialization constraints to be evaluated after all constraints in $\defaultConstraints$, but before the remaining two constraint sets below. $\deferredDefaultConstraints$ is required as setting individual variables may be accidentally overridden by compound and container initializers assigned through constraints in $\defaultConstraints$. - \item \emph{Top level constraints $\topLevelConstraints$}, i.e., constraints directly specified in a project, in top-level eval-blocks, in top-level assignment blocks as well as constraints attached to top-level variables, e.g., through derived types. These constraints originating from the top-level scope shall take precedence over constraints in nested scopes~\cite{IVML-LS}. - \item \emph{Remaining other constraints $\otherConstraints$} in particular in in nested structures, including compound types used in containers, nested assignment blocks or constraint variables. -\end{enumerate} - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{project $p$} - \KwData{configuration $cfg$, constraint $base$, constraint base copy $base_c$, constraint sets $\defaultConstraints,\deferredDefaultConstraints, \topLevelConstraints, \otherConstraints$, eval-blocks flag $inEvals$} - - \tcp{start of model visitor}%>ConstraintTranslationVisitor - \ForAll{$d \iterAssng decls(p)$}{ \label{algTranslateConstraintsTranslationStart} - $translateDeclaration(d, decision(cfg, d), \undef)$\; \label{algTranslateConstraintsTranslationDeclaration} - } - $add(\topLevelConstraints, constraints(p), true, \undef)$\; \label{algTranslateConstraintsAdd} \label{algTranslateConstraintsTopLevelConstraints} - \ForAll{$a \iterAssng assignments(p)$}{ - $add(\topLevelConstraints, constraints(a), true, \undef)$\; \label{algTranslateConstraintsTopLevelAnnotationConstraints} - $translateAnnotationAssignments(a, \undef, \undef, \undef)$\; \label{algTranslateConstraintsTopLevelAnnotationAssignments} - } \label{algTranslateConstraintsTranslationEnd} - $inEvals \assng true$\; - $add(\topLevelConstraints,\seqWith{constraints(e)}{e\in evals(p)}, true, \undef)$\;\label{algTranslateConstraintsTopLevelEvals} - $inEvals \assng false$\; - \tcp{end of model visitor}% 0 \wedge \neg hasTimeout \wedge \neg stop$} { \label{algEvalLoopLoopStart} - $c \assng pop(base)$\; \label{algEvalLoopPop} - $setAssignmentScope(\scopeAssignments, c)$\; \label{algEvalLoopSetScope} - %$\usedVariables \assng \emptySet$\; \label{algEvalLoopClear} - $setAssignmentState(e, \isDefaultConstraint{c})$\; \label{algEvalLoopAssngState} - $analyzeEvaluationResult(\problemRecords, evaluate(e, c))$\; \label{algEvalLoopAssngEval} - \If{$constraintFulfilled(e) \wedge \isDefaultConstraint{c}$}{\label{algEvalLoopClearStart} - $\relevantConstraintsPerDeclaration \assng \relevantConstraintsPerDeclaration \cap \setWith{\mapEntry{v}{c}}{v\in var(c)}$\; - }\label{algEvalLoopClearEnd} - $hasTimeout \assng checkForTimeout()$\; \label{algEvalLoopTimeout} - } \label{algEvalLoopLoopEnd} - \caption{Constraint evaluation loop (\IVML{evaluateConstraints}).}\label{algEvalLoop} -\end{algorithm} - -The main loop (lines \ref{algEvalLoopLoopStart}-\ref{algEvalLoopLoopEnd}) runs as long as there are constraints for evaluation in the constraint $base$, no timeout and no user cancellation request occurred. The (size of the) constraint base changes dynamically during reasoning as Algorithm \ref{algEvalLoop} removes processed constraints and value (type) changes may add constraints, e.g., those involving the changed variable (see Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling} for details). If no value assignment cycles occur, which ultimately lead to a timeout, the evaluation loop either terminates when all constraints are successfully evaluated or failing constraints do not induce the evaluation of further constraints. - -In each iteration of the main loop, the algorithm pops a constraint for evaluation from $base$ (line \ref{algEvalLoopPop}). % and clears the records about used variables (line \ref{algEvalLoopClear}). Recording used variables is required as detailed information for recording reasoning problems and later for creating the detailed reasoning report (last step of Algorithm \ref{algMainLoop}). -To assign values with the correct assignment state (cf. Section \ref{sectNotationConfigVars}), Algorithm \ref{algEvalLoop} registers the actual assignment state for the current constraint $c$ (line \ref{algEvalLoopAssngState}). If $c$ is a default constraint, all subsequent value assignments during the evaluation of $c$ happen with state \IVML{DEFAULT}, else state \IVML{DERIVED}. Next, constraint $c$ is evaluated (line \ref{algEvalLoopAssngEval}) by passing it to the constraint evaluator. %If configuration variables are changed as part of the constraint evaluation, the variables are recorded (not shown in Algorithm \ref{algVarChange}) and their constraints are re-scheduled for reasoning (cf. Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling}). -Then, the evaluation result is analyzed (still line \ref{algEvalLoopAssngEval}) and, if needed, problem records are created. We distinguish three cases: - -\begin{enumerate} - \item Constraint $c$ is evaluated successfully so that either no problem record is created or potentially existing problem records for $c$ from previously failed evaluations can be removed from $\problemRecords$. - \item Constraint $c$ is evaluated as undefined. As specified by IVML~\cite{IVML-LS}, a constraint is also considered undefined, if at least one involved variable or expression is evaluated as undefined. This does not lead to the creation of a problem record, as the constraint can either be ignored or will be re-scheduled if one of the (currently undefined) variables is changed through the evaluation of another constraint. - \item The constraint evaluation fails and a problem record for detailed error reporting or further (external) analysis is created. -\end{enumerate} - -Successfully evaluated default constraints must not stay in the constraint base as their initialization work has been done. As the evaluation of individual constraints cleans up the constraint base, we just have to avoid that they are accidentally re-scheduled. Therefore, we remove them from $\relevantConstraintsPerDeclaration$, the mapping between variable declarations and constraints in lines \ref{algEvalLoopClearStart}-\ref{algEvalLoopClearEnd}. Please note that no modification of $\relevantConstraintVariables$, the mapping between decision variables and constraints, is needed, as no change of constraint variables or their values occurred here. - -Finally, Algorithm \ref{algEvalLoop} checks for a potential timeout in line \ref{algEvalLoopTimeout} comparing the global $startTime$ set in Algorithm \ref{algMainLoop} with a configured reasoning timeout. If a timeout occurred (not further detailed in this document), the global $hasTimeout$ flag is set to $true$. This flag is also relevant for creating the overall reasoning report as explained for Algorithm \ref{algMainLoop}. - - -\section{Constraint translation}\label{sectTranslation} - -The constraint translation analyzes constraints defined for a given IVML model, instantiates those constraints for which reasoning cannot happen directly and fills the constraint base accordingly. In particular, constraints defined over types rather than qualified variable access expressions must be instantiated. We distinguish three main types of constraints, for which the top-level constraint translation algorithm (Algorithm \ref{algTranslateConstraints}) already indicated the subsequent translation calls: - -\begin{enumerate} - \item \emph{Constraints for default values}. To achieve uniformity of the constraint evaluation and re-scheduling upon value changes (cf. Section \ref{sectReasoning}), we also translate default value assignments to assignment constraints and add them to the constraint base. In more detail, an IVML declaration \IVML{\textit{Type} v = ex;} is translated to a constraint $\createConstraint{v = ex}$. We add assignment constraints to the constraint base with higher priority, i.e., at a lower sequence position than other constraints to ensure that default values are assigned first. For value assignment constraints, we must consider that default value expressions assigning complex values shall have higher priority than default values for individual slots or sequence positions. Otherwise, the value for an individual slot or position may accidentally be overridden by the complex value\footnote{This is partially caused by legacy behavior of the implementation, which cleans the target variable before assigning a complex value. However, re-assignment of values for individual slots or positions in the same scope leads to a reasoning error as required.}. Moreover, default value assignments can change the actual (value) type of a variable implying that a refined set of constraints must be evaluated. Creation of assignment constraints is part of translating variable declarations (called in Algorithm \ref{algTranslateConstraints} in line \ref{algTranslateConstraintsTranslationDeclaration}). - \item \emph{Top-level constraints} are defined using only top-level variables or fully qualifying accessor expressions. Top-level constraints include constraints in top-level eval blocks as well as constraints in top-level annotation assignment-blocks. Top-level constraints are ready for reasoning, i.e., they do not need further translation and can directly be taken over into the constraint base (Algorithm \ref{algTranslateConstraints}, lines \ref{algTranslateConstraintsAdd} - \ref{algTranslateConstraintsTopLevelEvals}). Annotation assignments are processed by Algorithm \ref{algTranslateAnnotationAssignments}. We use that algorithm also for translating annotation assignments in compound types. - \item \emph{Constraints in type definitions}, e.g., in compound types, typedefs with constraints or collections. These constraints must be instantiated, i.e., use of (local) variables and slots defined by a type must be substituted by fully qualifying accessor. We use top-level variables as entry point and perform a (recursive) constraint instantiation based on the type of the variable. Identifying constraints in types happens also during the translation of declarations (Algorithm \ref{algTranslateConstraints} line \ref{algTranslateConstraintsTranslationDeclaration}). -\end{enumerate} - -We detail now the constraint translation in the remainder of this section. We start in Section \ref{sectTranslationDeclarationTypesDefaults} with the translation of variable declarations, which delegates the translation to further algorithms and is called recursively during the translation of compound and collection variables. Then we follow the algorithms called while processing a variable declaration, i.e., the call graph shown in Figure \ref{figStructure}. Thus, the following sections focus on derived types in Section \ref{sectDerivedTypes}, annotation assignments in Section \ref{sectAnnotationDefaults} (as already used in (Algorithm \ref{algTranslateConstraints}, line \ref{algTranslateConstraintsTopLevelAnnotationAssignments}), compound types in Section \ref{sectCompoundDefaults}, container types in Section \ref{sectContainerDefaults}, and, constraint variables in Section \ref{sectConstraintVariables}. Finally, we discuss the algorithms for building the constraint base in Section \ref{sectContainerBase}. - -\subsection{Variable Declarations}\label{sectTranslationDeclarationTypesDefaults} - -As introduced in Section \ref{sectNotationVarDecls}, an IVML variable declaration consists of a type, a variable name and an optional default value expression. At its core, the translation of a variable declaration creates an assignment constraint for the default value expressions and instantiates all constraints defined by the variable type. If known, the translation considers the actual type of the variable defined by the configured value, which may in particular have a refined (compatible) compound type and, thus, a refined set of constraint. However, due to the complex structure of IVML types, identifying the constraints defined by a type may require a transitive or even recursive traversal over refined or underlying base types, e.g., in case of a typedef or a container. - -\grayPara{ -\begin{gather*} - \patternDerivation{T \text{ } v = deflt\IVML{;}}{ca.v = deflt} \\ - \patternDerivation{\IVML{annotate } a = deflt \IVML{ to} *\IVML{;} T \text{ } v\IVML{;}}{ca.v.a = deflt} \\ -\end{gather*} -} - -Let $v$ be a variable with default value expression $deflt$. The first transformation pattern above turns $deflt$ into an assignment constraint. If $v$ is nested in a compound or a sequence, a qualified access expression is required in the resulting constraint. In the transformation pattern, we indicate this by a generic access expression ($ca.$) on the right side, which is empty for top-level variables. The second pattern refers to annotations. As introduced in Section \ref{sectNotationVarDecls}, annotations are variables represent an an orthogonal configuration dimension on top of 'ordinary' variables. Thus, an annotation $a$ is translated similarly to an ordinary variable, but requires in addition a qualification through the respective ordinary variable $v$. - -Algorithm \ref{algTranslateDeclaration} translates all constraints related to a given variable $v$ (and its declaration $d$) based on the actual type of $v$. As complex types such as compounds may occur, Algorithm \ref{algTranslateDeclaration} delegates such types to more specialized algorithms, which then use Algorithm \ref{algTranslateDeclaration} recursively for nested variable declarations (with a respective access expression $ca$ and an adequately prepared variable mapping $\variableMapping$). These specialized algorithms will be discussed in the following sections. Assignment constraints created in Algorithm \ref{algTranslateDeclaration} are stored either in the global set for default constraints $\defaultConstraints$ or the set for deferred default constraints $\deferredDefaultConstraints$. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{declaration $d$, variable $v$, access $ca$} - \KwData{variable mapping $\variableMapping$, default (deferred) constraints $\defaultConstraints$ and $\deferredDefaultConstraints$, incremental flag $inc$} - - $e_d \assng \closedCases{\undef & \text{if } inc \\ default(d) & \text{else}}$; $f \assng \undef$; $c_m\assng NONE$\; \label{algTranslateDeclarationDecl}\label{algTranslateDeclarationInitStart} - $t \assng \closedCases{type(value(v)) & \text{if } v \neq \undef \wedge\text{ } value(v) \neq \undef \\ type(e_d) & \text{if } e_d \neq \undef \\ type(d) & \text{else}}$\; \label{algTranslateDeclarationRefinedType} - \uIf{$isCompound(t)$}{ - $f \assng d$\; \label{algTranslateDeclarationTranslateSelf1} - $c_m \assng translateCompoundDeclaration(d, v, ca, t, REGISTER)$\; \label{algTranslateDeclarationRegisterCompound} - }\label{algTranslateDeclarationInitEnd} - - \If{$e_d \neq \undef \wedge \neg(isAttribute(d) \wedge isAnnotationAssng(parent(d)))$}{ \label{algTranslateDeclarationDefaultStart} - $e_f \assng compound(ca)$\; \label{algTranslateDeclarationTranslateInCompound} - \uIf{$isConstraint(type(d))$}{ \label{algTranslateDeclarationTranslateConstraintDefaultStart} - $createConstraintVariableConstraint(e_d, e_f, v)$\; \label{algTranslateDeclarationConstraintVariableConstraint} - }\label{algTranslateDeclarationTranslateConstraintDefaultEnd} - \uIf{$isAnnotation(v)$}{\label{algTranslateDeclarationCreateACStart} - $ac\assng \closedCases{\IVMLMeta{acc}(d,a), & \text{if } ca = \undef \\ \IVMLMeta{acc}(ca,a), &\text{else}}$\;\label{algTranslateDeclarationTranslateAnnotationAccess} - }\uElse{ - $ac \assng \closedCases{ca, & \text{if } e_f \neq \undef \\ d, &\text{else}}$\; \label{algTranslateDeclarationTranslateUsualAccess} \label{algTranslateDeclarationTranslateSelf2} - }\label{algTranslateDeclarationCreateACEnd} - \leIf{$\IVMLself{} \in var(e_d) \vee isOverridenSlot(d)$}{$c_{e_d} \assng \deferredDefaultConstraints$}{$c_{e_d} \assng \defaultConstraints$} \label{algTranslateDeclarationTranslateSelf3} - $add(c_{e_d}, \createDefaultConstraint{\varSubstitutionSelfVarMapping{\IVML{assign}(ac, e_d)}{f}}, true, v)$\; \label{algTranslateDeclarationTranslateDefault} - }\label{algTranslateDeclarationDefaultEnd} - - \lIf{$\neg inc$} {$translateAnnotationDeclarations(d, v, \undef)$}\label{algTranslateDeclarationAnnotationDefault}\label{algTranslateDeclarationComplexStart} - $translateDerivedDatatypeConstraints(d, type(d))$\; \label{algTranslateDeclarationDerivedDatatype} - \uIf{$isCompound(t)$}{ - $translateCompoundDeclaration(d, v, ca, t, c_m)$\; \label{algTranslateDeclarationTranslateCompound} - } \uElseIf{$ isContainer(t) $}{ \label{algTranslateDeclarationHasDefault} - $translateContainerDeclaration(d, v, ca, t)$\; \label{algTranslateDeclarationTranslateContainer} - }\label{algTranslateDeclarationComplexEnd} - \caption{Translating declarations (\IVML{translateDeclaration}).}\label{algTranslateDeclaration} -\end{algorithm} - -Algorithm \ref{algTranslateDeclaration} consists of three parts: identifying the actual type and preparing the variable mapping (lines \ref{algTranslateDeclarationInitStart}-\ref{algTranslateDeclarationInitEnd}), translating the default value expression (lines \ref{algTranslateDeclarationDefaultStart}-\ref{algTranslateDeclarationDefaultEnd}) and translating complex types (lines \ref{algTranslateDeclarationComplexStart}-\ref{algTranslateDeclarationComplexEnd}). - -In the first part, Algorithm \ref{algTranslateDeclaration} first declares some local variables in line \ref{algTranslateDeclarationDecl}, including the default value expression $e_d$ (ignored in incremental mode), the actual value of self $f$ (for compound types only, overridden in line \ref{algTranslateDeclarationTranslateSelf1}) and the compound translation mode ($c_m$, overridden in line \ref{algTranslateDeclarationRegisterCompound} for use in line \ref{algTranslateDeclarationTranslateCompound}). In line \ref{algTranslateDeclarationRefinedType}, the actual type of the variable is determined, either based on the declaration, the default value expression or the actual value if defined. If $t$ is a compound type, we set in line \ref{algTranslateDeclarationTranslateSelf1} the value of self $v$ to the actual variable declaration $d$ and create the variable mapping for all slots in line \ref{algTranslateDeclarationRegisterCompound} by calling Algorithm \ref{algTranslateCompoundDeclaration}. Typically, this creates a new context frame in the variable mapping $\variableMapping$, which must be correctly cleaned up at the end of Algorithm \ref{algTranslateDeclaration}. We indicate this by the compound mode $c_m$, which is adjusted here and considered in the translation call in line \ref{algTranslateDeclarationTranslateCompound}. - -A remaining default value expression $e_d$ is turned into an assignment constraint if $d$ is not an attribute used within an assignment block (this may otherwise collide with default values defined by the assignment block). If the $v$ variable is a constraint variable, we also have to add $e_d$ to the constraint base. This is done by calling Algorithm \ref{algCreateConstraintVariableConstraint} (cf. Section \ref{sectConstraintVariables}). Then, we turn the default value expression into an assignment expression. However, the creation of the sub-expression $ac$ representing the variable $v$ technically depends on whether $d$ is a (nested) annotation or 'ordinary' variable (lines \ref{algTranslateDeclarationCreateACStart}-\ref{algTranslateDeclarationCreateACEnd}). Further, we must determine the constraint set for adding the assignment constraint (line \ref{algTranslateDeclarationTranslateSelf3}): We add the constraint to $\deferredDefaultConstraints$ if the assignment may override a previous value assignment through a complex value. This is (potentially) the case if \IVML{self} is used in $e_d$ or if $d$ is an overridden slot that may be overriden accidentally by a complex compound value. Else, we add the constraint to the set of default constraints $\defaultConstraints$. Ultimately, we create an expression assigning $e_d$ to $ac$, substitute \IVML{self} and the actual variable mapping in this assignment expression, turn the result into a default constraint and add it to the respective constraint set in line \ref{algTranslateDeclarationTranslateDefault}. - -Akin to default value expressions, orthogonal annotation declarations are only translated in full (non-incremental) reasoning mode in line \ref{algTranslateDeclarationAnnotationDefault} using Algorithm \ref{algTranslateAnnotationDeclarations}. -Finally, we translate constraints induced by the actual type of $v$. This can happen through derived, compound or container types. If $t$ is a derived data type, type-defined constraints are translated by Algorithm \ref{algTranslateDerivedDatatypeConstraints} in line \ref{algTranslateDeclarationDerivedDatatype}. If $t$ is a compound type, we call Algorithm \ref{algTranslateCompoundDeclaration} with the actual compound mode $c_m$ in line \ref{algTranslateDeclarationTranslateCompound}. If $t$ is a container type, we call Algorithm \ref{algTranslateContainerDeclaration} in line \ref{algTranslateDeclarationTranslateContainer}. - - -\subsection{Derived types}\label{sectDerivedTypes} - -As introduced in Section \ref{sectNotationDerivedTypes}, a derived datatype $t$ is defined as a restriction or an alias of its base type $base(t)$. A derived type $t$ is a type restriction of $base(t)$, if $t$ defines restricting constraints over $base(t)$ using the local variable $decl(t)$ representing $t$. Type $t$ is a type alias, i.e., a type with the same constraints as the base type but different type name, if $constraints(t) = \emptySet$. The base type of a derived type can in particular be another derived type, but, of course, also any other IVML type. If a variable $v$ is declared to be of a derived type $t$, all constraints defined for $t$ over $base(t)$ must hold for $v$. In particular, if $base(t)$ is a derived type, all constraints over all base types $allBase(t)$ of $t$ must hold transitively. Whether these constraints are fullfilled depends on the actual value of $v$. - -The constraint translation follows this chained type structure and instantiates all constraints defined along the nesting as shown in the following translation pattern. - -\grayPara{ -\begin{gather*} - \patternDerivation{\IVML{typedef } t_i \IVML{ with }(c_i); T v\IVML{;}}{\bigcup_{t_i \in allBase(T)} \varSubstitution{c_i}{decl(t_i)=deref(t_i, v), \variableMapping}} -\end{gather*} -} - -Given a variable $v$ of derived type $T$, all constraints induced by the derived type and all its base types are turned into instantiated constraints. During instantiation, we appy a substitution, which replaces the respective local variable by $v$ or an accessor expression to $v$ and, if applicable, any cross-referenced variables in $\variableMapping$. It is important to mention that just substituting the respective local variable by $v$ is not sufficient, as also reference types can be used as base type. A reference type requires then de-referencing of $v$, e.g., to permit access to the slots of a compound variable. This is indicated in the translation pattern by the function $deref(t, v)$, which either dereferences $v$ with respect to $t$ or returns $v$ if no de-referencing is needed. - -For a given variable $v$ (in terms of declaration $d$ and for technical reasons its type $t$), Algorithm \ref{algTranslateDerivedDatatypeConstraints} instantiates all constraints defined for all dereferenced transitive base types. However, we must consider whether we perform this instantiation for a container variable\footnote{The actual implementation receives the iterator variable causing the creation of the quantifier constraint and the parent model element for creating the constraints.}. If $v$ is a container variable, we create an all-quantifying constraint over all container elements, whereby the iterator variable $i$ of the quantifier substitutes $decl(t)$. If the derived type $t$ is defined based on some reference type, we must dereference the iterator variable $i$ appropriately. If $v$ is not a container variable, we substitute $decl(t)$ by the actual variable $d$. It is important to note that this substitution is transitive if $d$ is a compound slot, i.e., if $d$ is also mentioned in $\variableMapping$, the previously collected compound accessor for $d$ (in Algorithm \ref{algTranslateCompoundDeclaration}) is used to substitute $decl(t)$. The respective composite expression for $i$ is created through the function $deref(t, ex)$ shown below. The resulting constraints are stored in the set of top-level constraints $\topLevelConstraints$ as the variables in the resulting constraints are then fully qualified and in IVML derived types can only be defined on top level. % shall not make a difference for nested variables as they are already initialized - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{declaration $d$, type $t$} - \KwData{derived type constraints $\topLevelConstraints$} - $cs \assng \bigcup_{t \in deref(allBase(t))} constraints(t)$\; - \If{$isContainer(t)$}{ - $cs \assng \setWith{\createConstraint{\varSubstitutionOtherVarMapping{\IVML{forAll(i:}c\IVML{)}}{decl(t)=deref(t, i)}}}{c\in cs}$\; - }\Else{ - $cs \assng \setWith{\createConstraint{\varSubstitutionOtherVarMapping{c}{decl(t)=deref(t, v)}}}{c\in cs}$\; - } - $add(\topLevelConstraints, cs, true, \undef)$\; - \caption{Translating constraints for derived types (\IVML{translateDerivedDatatypeConstraints}).}\label{algTranslateDerivedDatatypeConstraints} -\end{algorithm} -% -The dereferencing operation\footnote{The actual implementation performs the dereferencing in an iterative manner when explicitly adding a variable mapping in addition to $\variableMapping$ to the substitution visitor.} for Algorithm \ref{algTranslateDerivedDatatypeConstraints} takes a type $t$ and a basis expression $ex$. For each reference base type in the chain of base types, it adds a call of the (internal) IVML dereferencing operation \IVML{refBy} around $ex$ or the recursively built up expression to $ex$. Other types than derived types immediately lead to $ex$ as result. -% -$$deref(t, ex)=\begin{cases} deref(base(t), ex), & \text{if } isDerived(t) \wedge \neg isReference(base(t)) \\ \IVML{refBy}(deref(base(base(t)), ex)), & \text{if } isDerived(t) \wedge isReference(base(t))\\ ex, & \text{else}\\\end{cases}$$ -% -\subsection{Compound types}\label{sectCompoundDefaults} - -A compound can define constraints in two differnt places, 1) nested within compound type definitions using qualified slot access expressions or unqualified slot names, and 2) as top-level as constraints with qualified slot access expressions. Both types of constraints imply all-quantification over all instances of the respective compound types~\cite{IVML-LS}. We translate compound constraints using the following schema: - -\grayPara{ -\begin{gather*} - \patternDerivation{\IVML{compound } C \IVML{\{} T s\IVML{; } c(s)\IVML{\}; } C v \IVML{;}}{\varSubstitution{c(s)}{\IVML{self}=v, s=v.s,\variableMapping}}\\ - \patternDerivation{\IVML{compound } C \IVML{\{} T s \IVML{\}; } C v \IVML{; } c(v)\IVML{; }}{\varSubstitution{c(v)}{\variableMapping}}\\ -\end{gather*} -} - -The first pattern indicates that an IVML compound type $C$ with declared slot $s$ and contained constraint $c(s)$ over slot $s$. The translation is applied if a variable $v$ of type $T$, i.e., a concrete instance of a compound type is declared and, however, receives a value. In this case, each contained constraint is instantiated by qualifying all relevant variable occurrences, i.e., replacing \IVML{self} with the actual variable $v$, the slot $s$ with the respective qualified access $v.s$ as well as all other known variable mappings, in particular including qualified access expression known for other slots in $C$. More complex access expressions also allow for translating nested compounds. The second case indicates a top-level constraint defined over the compound variable $v$. In contrast, this translation can happen as part of translating all top-level constraints, as due to the use of only qualified slot access expressions, just the (top-level) variable mapping is relevant for the substitution. The patterns show, that in both cases, the respective variable mapping including top-level and type-level cross-reference accesses must be created before the respective translation (including annotations, to handle constraints on annotations similarly). However, compounds may contain assignment and eval blocks. Assignment blocks are discussed in Section \ref{sectAnnotationDefaults}, but mainly differ in the treatment of the default value assignments rather than the contained constraints. Constraints in eval blocks can be transformed as shown by the patterns, but require different constraint evaluation priority. Moreover, compound instances may occur in containers, which we will discuss in more detail in Section \ref{sectContainerDefaults}. We will now focus on the first pattern and discuss the respective translation Algorithm \ref{algTranslateCompoundDeclaration}. - -For slots and annotations we can resort to Algorithm \ref{algTranslateDeclaration}, i.e., compound types, derived types, constraint variables and collections, while for the remaining constraints, we must visit these structures, instantiate and collect the respective constraints. Reference types do not need specific treatment as constraints are translated for the target variable of the reference. Basic types cannot define own containers. In particular, if the IVML keyword \IVMLself{} is used within a constraint, it must be substituted by the actual variable of the respective compound type. Moreover, it is important to recall that a variable $v$ of type $type(v)$ can contain instances of any refined type $allRefines^+(t)$, and in this case the translation must consider the default values of the potentially larger slot, additional constraints and nested structures. - -Algorithm \ref{algTranslateCompoundDeclaration} collects and translates the constraints for a compound variable $v$ with declaration $d$, potential compound accessor $ca$ and (default value) type (or $type(d)$ if no default expression is defined for $d$). No translation happens if type $t$ was already processed, e.g., in case of recursive compound types. The types are related by $type(d) = type(v) \in allRefines^+(t)$. Algorithm \ref{algTranslateCompoundDeclaration} creates a context frame and pushes it onto the variable mapping stack $\variableMapping$\footnote{For optimizing constraint rescheduling (see Section \ref{sectTopLevelConstraintsRescheduling}), the algorithm applies type exclusions to the actual context by transferring them and storing the causing type $t$ in the current context}. Used types are registered only if there is no variable $v$ given, e.g., we process constraints according to a potentially recursive type structure. If a variable $v$ is given, the nested variables are initialized correctly, in particular recursively nested variables terminate correctly based on configured values, i.e., we do not have to take care of recursion in this case. - -The main two steps are detailed in Algorithm \ref{algRegisterCompoundMapping} and \ref{algTranslateCompoundContent} as both Algorithms are reused with different arguments during the translation of compounds in Section \ref{sectCompoundDefaults}. Algorithm \ref{algRegisterCompoundMapping} registers all compound slots and annotations in the variable mapping, using $ca$ or $d$ as basis for access expressions for slots and annotations and casts to the type of the actual value in $v$ if available (else $\undef$ is passed in as argument). Now Algorithm \ref{algTranslateCompoundContent} can translate the entire compound content including slots, annotations, constraints, annotation-blocks and eval-blocks. -%As the context with the compound mapping is only valid during Algorithm \ref{algRegisterCompoundMapping}, default value expressions must be translated within the actual context, i.e., if $deflt$ has been passed in, lines \ref{algTranslateCompoundSubstStart}-\ref{algTranslateCompoundSubstEnd} perform the respective substitution, which will be returned as result of Algorithm \ref{algRegisterCompoundMapping}. Finally, Algorithm \ref{algTranslateCompoundDeclaration} removes the actual context frame for this compound from $\variableMapping$. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{declaration $d$, variable $v$, compound access $ca$, default value type $t$, mode $m$} - \KwData{constraints $\otherConstraints$, variable mapping $\variableMapping$} - - $next \assng NONE$\; - \If{$\neg alreadyProcessed(\variableMapping, t)$} { - \If{$m = ANYWAY \vee m = REGISTER$}{ - $recordProcessed(\variableMapping, t)$\; - $pushContext(\variableMapping, d, v \neq \undef)$\; - $transferTypeExcludes(\variableMapping, t)$\; - $e \assng \createExpression{d}$\; - $registerCompoundMapping(t, ca, v, e, type(value(v)))$\; - $next \assng TRANSLATE$\; - } - \If{$m = ANYWAY \vee m = TRANSLATE$}{ - $translateCompoundContent(d, v, t, ca)$\; - $popContext(\variableMapping)$; - $next \assng NONE$\; - } - } - \Return{$next$} - \caption{Translating compound declarations (\IVML{translateCompoundDeclaration}).}\label{algTranslateCompoundDeclaration} -\end{algorithm} - -Algorithm \ref{algRegisterCompoundMapping} visits all slots and annotations, creates access expressions for them and registers them with the current context frame in the variable mapping $\variableMapping$. The compound type $t_c$ indicates the type to be processed, i.e., where to take slot and annotation definitions from. The access expressions $ca$ is optional as usual and, if given, utilized as prefix to create access expressions for slots and annotations. Finally, a target type $t_t$ is given if the access via $ca_s$ or $ca_t$ requires a type cast so that specific slots of $t_t$ can be accessed. Type casts are required if if the actual value is of a refined type of $t_c$, as otherwise slots defined on the more specific type are not accessible and access is rejected by static type checking of IVML expressions. - -Let -% -$$slots^-(t) = \setWith{s \in slots(t)}{\neg isTypeExcluded(\variableMapping, type(parent(s)))} $$ -% -be the slots of $t$ for which the containing type is not excluded \footnote{Excluded types only occur as an optimization in constraint re-scheduling (cf. Section \ref{sectTopLevelConstraintsRescheduling}} in the actual context of $\variableMapping$. Algorithm \ref{algRegisterCompoundMapping} iterates over all slots accessible for the given compound type $t_c$ and creates for each slot a respective accessor. If a preceding compound access expression for the slots $ca_s$ is not given, it creates a static accessor based on $v$. If an accessor is given, we create an accessor based on $ca_s$ and include a type cast to $t_t$\footnote{The type cast can be omitted if $t=type(value(v))$. This is done by the implementation, but not detailed here as a type cast to the actual type does not have an effect.}. The created accessor is then registered with $\variableMapping$. Similarly, we iterate over all annotations for the current slot, create an accessor expression based on $ca_a$ and register the result with $\variableMapping$. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{compound type $t_c$, acccess $ca$, variable $v$, declaration expression $e_d$ target type $t_t$} - \KwData{constraints $\otherConstraints$, variable mapping $\variableMapping$} - - \ForAll{$s \iterAssng \setWithFlat{slots(t)}{t\in allRefines^+(t_c)}$} { \label{algRegisterCompoundMappingVarMappingStart} %actual slots - $x \assng \createExpression{\closedCases{\IVMLMeta{acc}(e_d, s), & \text{if } ca = \undef \\ \IVMLMeta{acc}(\IVML{asType}(ca, t_t), s), &\text{else}}}$\; \label{algRegisterCompoundMappingVarMapping} - $registerMapping(\variableMapping, s, x)$\; - \ForAll{$a \iterAssng annotations(s)$}{ - $registerMapping(\variableMapping, a, \createExpression{\IVMLMeta{acc}(ca,a)})$\; \label{algRegisterCompoundMappingAnnotationMapping} - } - }\label{algRegisterCompoundMappingVarMappingEnd} - \ForAll{$a \iterAssng annotations^+(decl(e_d))$}{ - $x \assng \createExpression{\closedCases{\IVMLMeta{acc}(e_d,a), & \text{if } ca = \undef \\ \IVMLMeta{acc}(\IVML{asType}(ca, t_t), a), &\text{else}}}$\; \label{algRegisterCompoundMappingCreateExpression} - $registerMapping(\variableMapping, a, x)$\; % left out origins - } - - \caption{Registering the compound mapping (\IVML{registerCompoundMapping}).}\label{algRegisterCompoundMapping} -\end{algorithm} - -Given a complete mapping for a compound type, we can apply Algorithm \ref{algTranslateCompoundContent}. The algorithm performs a transitive / recursive translation of the default values of all (not excluded) slots using the respective accessor calling Algorithm \ref{algTranslateDeclaration} in line \ref{algTranslateCompoundDeclarationTranslateSlotsV} if $v$ is defined ($slots(v)$ also includes all slots for $v$\footnote{This also holds for $slots^-(v)$ if the parent type of $v$ is not excluded.}) or all 8not excluded) slots for type$t$. It is important to note that in both cases, the second occurs in container translations, we call Algorithm \ref{algTranslateDeclaration}, which dispatches for all types and also considers annotations. - -In line \ref{algTranslateCompoundDeclarationSelf}, we determine the actual expression for self, i.e., the access expression $ca$ if given or the declaration $d$. Then, due to their specific priorities, we first translate all eval constraints defined along the type hierarchy for $t$ in lines \ref{algTranslateCompoundDeclarationEvalStart}-\ref{algTranslateCompoundDeclarationEvalEnd}. Afterwards, we include all remaining compound constraints, i.e., type constraints and annotation constraints in lines \ref{algTranslateCompoundDeclarationAllStart}-\ref{algTranslateCompoundDeclarationAllEnd}. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{declaration $d$, variable $v$, compound type $t$, access $ca$} - \KwData{constraints $\otherConstraints$, variable mapping $\variableMapping$} - - \uIf{$v\neq\undef$}{\label{algTranslateCompoundDeclarationTranslateSlotsStart} - \ForAll{$s \iterAssng slots^-(v)$} { - $translateDeclaration(s, decision(v, s), \variableMapping[s]))$\; \label{algTranslateCompoundDeclarationTranslateSlotsV} - } - } \Else { - \ForAll{$s \iterAssng \setWithFlat{slots^-(u)}{u\in allRefines^+(t)}$ } { - $translateDeclaration(s, \undef, \variableMapping[s]))$\; \label{algTranslateCompoundDeclarationTranslateSlotsT} - } - }\label{algTranslateCompoundDeclarationTranslateSlotsEnd} - \If{$\neg inc$} { - \ForAll{$a \iterAssng assignments(t)$}{ - $translateAnnotationAssignments(a, v, \undef, ca)$\; \label{algTranslateCompoundDeclarationCompoundAssignments} - } - } - \leIf{$ca \neq \undef$}{$f\assng ca$}{$f\assng d$}\label{algTranslateCompoundDeclarationSelf} -\MISSING{Register constraints for creating compound constraints (value is constraint value) }\; - $eval \assng \setWithFlat{allEvalConstraints(r)}{r\in allRefines^+(t) \text{ } \setminus \text{ } excludedTypes(t)}$\;\label{algTranslateCompoundDeclarationEvalStart} - $add(\otherConstraints, \setWith{attach(\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}, currentType(\variableMapping))}{c\in eval}, true, v)$\;\label{algTranslateCompoundDeclarationEvalEnd} - $cmp \assng \setWithFlat{allCompoundConstraints(r)}{r\in allRefines^+(t) \text{ } \setminus \text{ } excludedTypes(t)}$\;\label{algTranslateCompoundDeclarationAllStart} - $add(\otherConstraints, \setWith{attach(\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}, currentType(\variableMapping))}{c\in cmp}, true, v)$\;\label{algTranslateCompoundDeclarationAllEnd} - - \caption{Translating compound content (\IVML{translateCompoundContent}).}\label{algTranslateCompoundContent} -\end{algorithm} - -As stated above, we defer all constraint translation work to a recursive execution of Algorithm \ref{algTranslateDeclaration}. However, correctly initializing compounds can be tricky, as both, default slot values and compound initializer expressions, i.e., complex value assignments to compounds must be considered while reasoning. We solve this as follows: Algorithm \ref{algTranslateDeclaration} is triggered by a compound variable declaration. If a default value for the compound variable is defined, Algorithm \ref{algTranslateDeclaration} creates a respective constraint and then continues with the creation of the slot defaults and the compound constraints in Algorithm \ref{algTranslateCompoundContent}. Mixing both happens behind the scenes through the constraint evaluator: Assigning a value to a compound variable (or a slot) causes the creation of a compound instance with the desired values for the specified slots. The following assignment constraints for the default values are executed if no other value has been assigned (otherwise they are ignored) and finally removed by the main constraint evaluation loop in Algorithm \ref{algEvalLoop}. Dependent default values are evaluated as soon as the required variables have values assigned. - -\subsection{Container types}\label{sectContainerDefaults} - -Per se, a container variable can only declare the contained type and the respective element values through its default, i.e., there is no direct opportunity to define constraints for a container. However, constraints are indirectly defined through the contained type and the types used for the individual elements. Here, compounds, derived types, constraint types and, transitively, nested containers can introduce constraints further characterizing (the contents of) a container variable. Reference types do not need specific treatment as constraints are translated for the target variable of the reference. Basic types cannot define own containers. Due to refinement, all relevant types may be more specific than the (generic) container type given for the initial container variable. - -Containers differ from the other IVML types as a container may contain an arbitrary number of elements. Thus, for specifying a constraint over a container, we must apply all-quantification or, as an alternative, unroll the container, create constraints for the individual container entries and take care of the changes of the elements. Currently, unrolling is not possible for all IVML container types, e.g., set-based types do not offer index-based access. Thus, for the translation pattern, we generically use quantification. - -\grayPara{ -\begin{gather*} - \patternDerivation{\IVML{containerOf(}T\IVML{) } v\IVML{;}}{\bigcup_{t\in usedTypes(v), c\in constraints(t)}f(v, t)\rightarrow \IVML{forall}(w:\varSubstitution{c(x)}{x=w.x, \variableMapping})}\\ - \patternDerivation{\IVML{containerOf(}T\IVML{) } v\IVML{;} c(v)\IVML{;}}{\varSubstitution{c(v)}{\variableMapping}} -\end{gather*} -} - -There are two basic translation patterns for containers, 1) constraints induced by used types and 2) top-level constraints for collection variables. We will focus here on the first pattern, as the second pattern comes for free as part of the translation of the top-level constraints. - -As shown for the first pattern, given a container variable $v$, we consider all potential (declared) as well as used types in the actual value and create for each constraint implied by these types an all-quantified constraint over $v$. Please note that individual constraints are needed to provide detailed error messages, but also to keep the re-evaluation effort low. However, if the container is nested, i.e., $T$ is again a container over a certain type, we must take flattening into account to apply the constraints to the individual elements. Moreover, if $\subTypeOf{t}{T)}$, accessing specific properties such as compound slots requires some form of type casting / selection on the elements of the container. These additional container transformations depend on the actual container type and are represented in the schema by $f(v, t)$. For short, $f(v, t)$ turns a sequence into a set to avoid duplicated constraints, flattens a nested container and applies type selects to enable access to slots defined in refined compounds. We will detail $f(v, t)$ below in this section. Finally, the constraint must be substituted adequately, using the quantifier iterator to access the elements, including slot access expressions for compound element types as well as known access expressions to other variables and slots. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{declaration $d$, variable $v$, access $ca$, type $t$} - \KwData{configuration $cfg$, constraint $base$, variable mapping $\variableMapping$, constraint variables $\otherConstraints$, default (deferred) constraints $\defaultConstraints$ and $\deferredDefaultConstraints$, incremental flag $inc$} - - $pushContext(\variableMapping, false)$\; - $t_n \assng nested^*(t); t_b \assng base^*(t_n); used\assng\emptySet$\; - $val\assng relevantValue(d, v, inc)$\; - \uIf{$isConstraint(t_b)$} { - $add(\otherConstraints, \setWith{\createConstraint{\varSubstitutionSelfVarMapping{e}{ca}}}{e \in allElements(val)}, true, v)$\; \label{algTranslateContainerDeclarationConstraintContainer} - } \ElseIf{$isCompound(t_b)$} {\label{algTranslateContainerDeclarationCompoundContainerStart} - \uIf{$val \neq \undef$} { - $used \assng \setWithFlat{base(u)}{u \in usedTypes(val) \wedge isContainer(base(u))}$\; \label{algTranslateContainerDeclarationUsedTypesDefault} - $used \assng used \setminus \setWithFlat{allRefines(u)}{u \in used}$\; \label{algTranslateContainerDeclarationUsedTypesPrune} - } \Else { - $used \assng \set{t_b}$\; \label{algTranslateContainerDeclarationUsedTypesFallback} - } - \ForAll{$u \iterAssng used$}{\label{algTranslateContainerDeclarationCompoundContainerDefaultsStart} - $translateCompoundContainer(d, u, t_n, ca)$\; - }\label{algTranslateContainerDeclarationCompoundContainerDefaultsEnd}\label{algTranslateContainerDeclarationCompoundContainerEnd} - % $used \assng used \setminus \setWith{allRefines(u)}{u \in used}$\; - % \lIf{$|used| = 0$}{$used \assng \set{base(contained(d))}$} - % \ForAll{$u \iterAssng used$} {\label{algTranslateContainerDeclarationCompoundContainerUsedCompoundsStart} - % $add(\otherConstraints, translateCompoundContainer(u, t_n, d, ca), true)$\; - % }\label{algTranslateContainerDeclarationCompoundContainerUsedCompoundsEnd} - } - \uIf{$isDerived(t_n)$}{ - $translateDerivedDatatypeConstraints(t_n, d)$\; \label{algTranslateContainerDeclarationDerivedTypes} - } - $popContext(\variableMapping)$\; - \caption{Translating declaration default value expressions to constraints (\IVML{translateContainerDeclaration}).}\label{algTranslateContainerDeclaration} -\end{algorithm} - -We detail now the generic translation schema, i.e., the function $f(v, t)$ mentioned above by using the IMVL \IVML{flatten} and the \IVML{selctByKind} operations: Let $d$ denote the variable declaration containing the compound (may alternatively be a compound or container accessor). The \IVML{flatten} resolves all nested containers and implicitly provides access even to deeply nested container entries. \IVML{selectByKind} is needed if we translate for slots of a specific given type $t$ with $\subTypeEqOf{t}{s}$, as otherwise the slots defined on specific types are not accessible. Finally, we apply an all quantor over the elements of the collection using the temporary iterator variable $l$ to the respective constraint $c$ after appropriate variable substitution, in particular replacing \IVMLself{} by $l$. -% -\begin{displaymath} -d\rightarrow \underbrace{\IVML{flatten()}\rightarrow}_{\text{if nested}}\underbrace{\IVML{selectByKind}(t)\rightarrow}_{\text{if } \subTypeOf{t}{nested^*(c)}}\IVML{forAll}(l:c(l)) -\end{displaymath} -% -Thus, the core idea of this algorithm is to consider all elements over all used types. If no value is available, we resort to the static type of the declaration of the containser variable. We create all-quantized constraints for all used types and distinguish between constraint containers, where the values directly turn into constraints, compound containers, where slots, constraints and annotations lead to further constraints, and derived types. - -Algorithm \ref{algTranslateContainerDeclaration} performs the transformation for a container variable declaration $d$ of variable $v$, if nested with given access expression $ca$ and specific type $t$ (due to a known default value). However, if $isCompound(t)$ and $t$ is also recursively used as slot type, Algorithm \ref{algTranslateContainerDeclaration} may cause an endless recursion. Thus, we translate constraints for $t$ only if $t$ was not already processed as flattening of the container elements used below requires considering each used type exactly once. - -For translating constraints, we first determine the innermost nested type $t_n$ and its base type $t_b$ (i.e., ignoring intermediate derived types) as well as the relevant value $val$. If $v$ is a constraint container, i.e., the innermost nested base type is a constraint, we collect and translate all constraints constituted by all (flattened) element values in line \ref{algTranslateContainerDeclarationConstraintContainer}. If $v$ is a compound container, i.e., the innermost nested base type is a compound, we consider the used types. If there is a value, we determine the used contained compound types in line \ref{algTranslateContainerDeclarationUsedTypesDefault} and prune more general refined types in line \ref{algTranslateContainerDeclarationUsedTypesPrune}, as the following algorithm must anyway iterate over the refinement hierarchy. If there is no value, the only used type is the innermost nested base type $t_b$, actually a compound (line \ref{algTranslateContainerDeclarationUsedTypesFallback}). The, we iterate over all (pruned) used types and apply Algorithm \ref{algTranslateCompoundContainer}. Independently of constraint or compound container, we finally translate and collect all constraints stemming from derived type definitions in line \ref{algTranslateContainerDeclaration}. - -Algorithm \ref{algTranslateCompoundContainer} creates constraints for compound values utilized in compounds, e.g., through a container initialize, in IVML like \IVML{seq = \{\{i=1\}, \{i=2\}\}}, assuming that \IVML{seq} is a sequence of compounds, which have an integer slot \IVML{i}. As these compounds are created implicitly within a container initializer, so far no default value constraints, nested constraints, annotation assignments etc. are scheduled to the constraint base, i.e., these compounds would remain uninitialized and their constraints not considered. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{declaration $d$, (specific) type $t$, declared type $u$, access $ca$, mode $m$} - \KwData{deferred default constraints $\deferredDefaultConstraints$} - - \If{$\neg alreadyProcessed(\variableMapping, t)$}{ - $recordProcessed(\variableMapping, t)$\; - - $l\assng \createExpression{\IVMLMeta{var}(t)}$\; - - $e\assng\closedCases{ca, & \text{if } ca \neq \undef\\\createExpression{d}, &\text{else}}$\; \label{algTranslateDefaultsCompoundContainerInitE} - \uIf{$isSequence(type(d))$} { - $e\assng\createExpression{\IVML{asSet}(e)}$\; \label{algTranslateDefaultsCompoundContainerAsSet} - } - \uIf{$isNested(type(d))$} { - $e\assng\createExpression{\IVML{flatten}(e)}$\; \label{algTranslateDefaultsCompoundContainerFlatten} - } - \uIf{$u\neq t$} { - $e\assng\createExpression{\IVML{selectByKind}(e, t)}$\; \label{algTranslateDefaultsCompoundContainerCast} - } - - $pushContext(\variableMapping, \undef, e, l, true)$\; - $registerCompoundMapping(t, l, \undef, d, t)$\; \label{algTranslateDefaultsCompoundContainerMapping} - - $translateCompoundContent(l, \undef, t, \closedCases{\undef, & \text{if } ca = \undef\\l & \text{else}})$\; \label{algTranslateDefaultsCompoundContainerContent} - $popContext()$\; - } - \caption{Translating constraints for compound containers (\IVML{translateCompoundContainer}).}\label{algTranslateCompoundContainer} -\end{algorithm} - -Algorithm \ref{algTranslateCompoundContainer} targets this by creating all-quantized constraints over all elements of the container, mostly be reusing Algorithm \ref{algRegisterCompoundMapping} to create a compound mapping and Algorithm \ref{algTranslateCompoundContent} to translate the compound content. Initially, we a local variable $l$ as later iterator variable for the quantifier expressions. Then, we create a prefix expression $e$ of the quantor constraint expression, i.e., we determine in line \ref{algTranslateDefaultsCompoundContainerInitE} the access expression to the collection either using $ca$ or just holding the variable of the container $d$. If the container is a sequence that may contain duplicates, we first turn it into a set to avoid accidentally duplicated constraints (line \ref{algTranslateDefaultsCompoundContainerFlatten}). If the container is nested, we flatten it in line \ref{algTranslateDefaultsCompoundContainerFlatten} as constraints only need to be created for the elements (no specific constraints can be attached to a container type except for derived values, which are handled by Algorithm \ref{algTranslateDeclaration}). If the actual type $t$ is not the same as the type of the declaration $u)$, we must consider that the slot $s$ only exists for the specific refined type $t$. Then, the instantiation shall apply only to container elements of type $t$ (or of refined types), i.e., we insert in line \ref{algTranslateDefaultsCompoundContainerCast} an element selection by projecting the container to all elements of type $t$ (and refined types). - -Now we create a context for the container on the stack of $\variableMapping$. In contrast to compound translations, we also register the prefix expression $e$ and the iterator variable $l$. This will be taken up by the $add$ operation, which completes the full constraint from the given information on the stack, i.e., the full creation of the constraint is prepared but not shown in Algorithm \ref{algRegisterCompoundMapping}. As for compounds, we create now the compound mapping using Algorithm \ref{algRegisterCompoundMapping}. Please note that slot access now happens via the iterator variable $l$, while annotation access happens through $ca$. Specifying $t$ also as target type avoids unnecessary type casts here. Then, we call Algorithm \ref{algTranslateCompoundContent} to translate the compound slots, implying translation of annotations as well as recursion over further compounds and containers. Thereby, we replace a given access expression by the iterator variable $l$ or leave the access undefined as it is implicity given in and used from the actual context. - -By storing constraint information on the stack of $\variableMapping$ and assembling the information in one place, we can even handle recursive compound containers, which leads to a recursive creation of constraints. The formula below indicates the constraint that we must create in case of a compound container nested into a compound container. -% -\begin{displaymath} -\underbrace{\underbrace{ca}_{1: ca}\rightarrow \IVML{flatten}}_{1:e}\rightarrow\IVML{forAll}(\underbrace{l}_{1:l}:\underbrace{\underbrace{l.s}_{2: ca}\rightarrow\IVML{flatten}}_{2:e}\rightarrow\IVML{forAll}(\underbrace{l_2}_{2:l}:c(l_2))) -\end{displaymath} -% -In the first iteration, we start with $ca$ (indicated by $1:ca$, may also be some $d$) and append flatten/typeSelect as needed to form $e$ (indicated by $1:e$, i.e., recursion level and parameter/variable name). In the first iteration, we also create a temporary variable $l$ as iterator variable. We store $l$ and $e$ on the stack of $\variableMapping$ and pass $l$ on as accessor to the translation of compound content in Algorithm \ref{algTranslateCompoundContent}. There, we create an accessor for a slot, let's say $s$, i.e. $l.s$, which is then passed on in line \ref{algTranslateCompoundDeclarationTranslateSlotsV} or \ref{algTranslateCompoundDeclarationTranslateSlotsT}, respectively, to the translation of declarations in Algorithm \ref{algTranslateDeclaration}. As a further compound container is nested into the initial compound container, we end up again in Algorithm \ref{algTranslateCompoundContainer}. Now $l.s$ is considered as accessor (indicated by $2:ca$), flatten(typeSelect are added as needed to form $e$ (now $2:e$), which is stored along with the temporary iterator variable $l_2$ on the stack. In this context, we apply the constraint $c$ within an all-quantor (after appropriate variable substitution, in particular \IVMLself{} by $l_2$). The quantor expressions for completing the full constraint are created by the $add$ algorithm (details in Section \ref{sectContainerBase}). - -Let us assume that $stack(\variableMapping)$ returns the contex frames of the stack starting with the top frame, $container(s)$ returns the container expression assigned to context frame $s$ and $iterator(s)$ the iterator variable for $s$. The, Algorithm \ref{algComposeExpression} creates a constraint of the form shown above inside out, starting with $c$ after correct variable substation. For each stack element that has a container (we assume also an iterator variable) assigned, which is not the case for context frames created for compounds, we surround the actual $c$ by an all-quantor, running over $container(s)$ using $iterator(s)$ as iterator variable and $c$ as quantor expression. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{constraint $c$} - \KwOut{composed constraint $c$} - \KwData{variable mapping $\variableMapping$} - - \ForAll{$s \iterAssng stack(\variableMapping)$} { - \If{$container(s) \neq \undef$} { - $c \assng \createExpression{container(s)\rightarrow\IVML{forAll}(iterator(s):c)}$\; - } - } - \Return $c$\; - \caption{Composing constraints from $\variableMapping$ (\IVML{composeExpression}).}\label{algComposeExpression} -\end{algorithm} - -Utilizing quantor constraints here implies that default initializations, which remain undefined if some dependent variables have not been determined so far, cause a re-evaluation for all elements of the container. Here, unfolding the implicit loop of such a quantor may be a solution, as then only individual constraints are triggered. However, this only works for sequences, as sets do not provide element-wise/index-based access and unfolding the constraint for a large container also may create a huge number of constraints. Currently, we stay with the compromise of creating a single quantized constraint for all slots with default values. - -\subsection{Annotations}\label{sectAnnotationDefaults} - -In IVML, annotations are orthogonal typed variables that can be attached to a variable. For all those orthogonal variables, the reasoner must create constraints to perform the evaluation and assignment of the default values before all other constraints are considered for reasoning. It is important to recall that IVML annotations are not recursive~\cite{IVML-LS}, although the reasoner algorithms could support this. Moreover, we must translate assignment-blocks, i.e., blocks assigning specific values to all variables declared within that block. In this section, we discuss first the translation of annotations, then the translation of annotation blocks. - -The first transformation pattern for the direct translation of annotations is the second pattern from Section \ref{sectTranslationDeclarationTypesDefaults}. More specifically, Algorithm \ref{algTranslateDeclaration} from \ref{sectTranslationDeclarationTypesDefaults} calls the algorithms in this section, which in turn call Algorithm \ref{algTranslateDeclaration}, i.e., the algorithms here prepare the application of Algorithm \ref{algTranslateDeclaration} by composing specific accessor expressions. The second pattern relates to annotation blocks, i.e., specific assignment constraints (accessor expression $ca$ is determined by the top-level or compound context of the annotation block) is created for the variables declared in the assignment block for values mentioned in the assignment data (clause). It is important to note that annotation blocks may be nested in order to indicate orthogonal annotations, i.e., the constraint translation must take this nesting and the respective precedence of the assignment data due to their nesting into account. - -\grayPara{ -\begin{gather*} - \patternDerivation{\IVML{annotate } a = deflt \IVML{ to } *\IVML{;} T \text{ } v\IVML{;}}{ca.v.a = deflt}\\ - \patternDerivation{\IVML{assign (} a = deflt \IVML{) to \{} T v \IVML{ assign} \ldots \IVML{\}}}{ca.v.a = deflt \ldots} -\end{gather*} -} - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{declaration $d$, variable $v$, compound access $ca$} - \KwData{constraints $\otherConstraints$} - - $ca\assng \closedCases{d, & \text{if } ca = \undef \\ ca, &\text{else}}$\;\label{algTranslateAnnotationDeclarationsCa} - \uIf{$v \neq \undef$}{\label{algTranslateAnnotationDeclarationsTranslateVStart} - \ForEach{$a\in annotations(v)$}{ - $ac\assng \closedCases{\IVMLMeta{acc}(ca,a), & \text{if } qualifyAnnotation(v, a, ca)\\ ca, &\text{else}}$\; - $translateDeclaration(decl(a), a, ac)$\;\label{algTranslateAnnotationDeclarationsTranslateDeclV} - } - }\Else{\label{algTranslateAnnotationDeclarationsTranslateVEnd}\label{algTranslateAnnotationDeclarationsTranslateDStart} - \ForEach{$a\in annotations(d)$}{ - $ac\assng \closedCases{\IVMLMeta{acc}(ca,a), & \text{if } qualifyAnnotation(v, a, ca)\\ ca, &\text{else}}$\; - $translateDeclaration(a, \undef, ac)$\;\label{algTranslateAnnotationDeclarationsTranslateDeclD} - } - }\label{algTranslateAnnotationDeclarationsTranslateDEnd} - -%isContextsRegistering(\variableMapping) - - \caption{Translating annotation defaults (\IVML{translateAnnotationDeclarations}).}\label{algTranslateAnnotationDeclarations} -\end{algorithm} - -with -% -\begin{align*} -qualifyAnnotation(v, a, & ca) = ca \neq \undef \wedge \neg isContextRegistering(\variableMapping) \wedge \\ &(size(\variableMapping) > 1 \vee isCompound(base^*(type(v)))) -\end{align*} -% -which requests creating an extended accessor expression if we are translating a nested annotation block (implying context registering) or if we are translating an annotation of a compound type. - -Algorithm \ref{algTranslateAnnotationDeclarations} receives the declaration of the actual variable and a potential compound access expression $ca$ to $d$ if the algorithm is called for slots of a compound value. The actual access expression is either $ca$ if given or $d$ if $ca$ is not given (line \ref{algTranslateAnnotationDeclarationsCa}). Annotations are translated based on $v$ if given (lines \ref{algTranslateAnnotationDeclarationsTranslateVStart}-\ref{algTranslateAnnotationDeclarationsTranslateVEnd}), for configuration initialization also based on $d$ if $v$ is not given (lines \ref{algTranslateAnnotationDeclarationsTranslateDStart}-\ref{algTranslateAnnotationDeclarationsTranslateDEnd}). - -For all annotations of $v$ -%(as for $v$ here all inherited annotations are available) -, the algorithm creates the respective constraints by creating a specific access expression according to $qualifyAnnotation(v, a, ca)$ through calling Algorithm \ref{algTranslateDeclaration}. For top-level annotation assignments , no specific access expressions except for the one created in line \ref{algTranslateAnnotationDeclarationsCa} are needed, as they are created in Algorithm \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateAnnotationAccess}. - -We turn now to the translation of annotation assignment-blocks. In IVML, an assignment-block is used on top-level or within compounds to declare compound slots with an implicit assignment of a value to each declared annotation. Further, assignment-blocks can be nested and the assignments defined for the outer blocks must be applied also to the inner blocks. - -The translation of assignment-blocks on top-level is triggered by Algorithm \ref{algTranslateConstraints} in line \ref{algTranslateConstraintsTopLevelAnnotationAssignments}. The translation of assignment-blocks within compounds is caused by Algorithm \ref{algTranslateCompoundDeclaration} in line \ref{algTranslateCompoundDeclarationCompoundAssignments} (variable mapping in Algorithm \ref{algRegisterCompoundMapping} line \ref{algRegisterCompoundMappingVarMapping} and slot translation in line \ref{algTranslateCompoundDeclarationTranslateSlotsV} or \ref{algTranslateCompoundDeclarationTranslateSlotsT} in Algorithm \ref{algTranslateCompoundDeclaration} along with the decision variables of the compound value). In both cases, Algorithm \ref{algTranslateAnnotationAssignments} is called. - -Algorithm \ref{algTranslateAnnotationAssignments} first builds up (incrementally) the set of effective assignments data $ea$ that is relevant for the actual assignment-block $a$ (initially $ea=\emptySet$ for a top-level assignment-block). However, only the innermost assignment is relevant in case of nested assignment blocks~\cite{IVML-LS}, so that we build a mapping based on the annotation names overriding assignments inherited from the containing assignment blocks. -For a given assignment-block $a$, the algorithm performs then the transformation of each individual assignment and collects the created constraints in $\otherConstraints$. If the type of the slot (if available the dynamic type of the value) is a compound, the algorithm performs the same transformation on all compound slots with respective accessors (either using the slot variable $d$ or the compound accessor $ca$ if given). It is important to note that we temporarily activate a context frame of $\variableMapping$ for each declaration $d$ if a context has been created/registered before during compound translation. This is required as the constraints are actually created after the translation of the types and otherwise we would still use the original variables specified in the model rather than the instantiated ones needed for reasoning. Finally, the algorithm recursively processes contained assignment-blocks. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{assignment-block $a$, variable $v$ effective assignment data $ea$, compound access $ca$} - \KwData{constraints $\otherConstraints$} - - $ea \assng ea \addMap \setWith{\mapEntry{name(a)}{a}}{a \in assignmentData(a)}$\; - \ForAll{$\mapEntry{n}{e} \iterAssng ea$}{ - \ForAll{$d \iterAssng slots(a)$} { - $activate(\variableMapping, d)$\; - $add(\otherConstraints, \set{translateAnnotationAssignment(e, d, ca)}, false, \undef)$\; - $t \assng type(d)$\; - $ac \assng \closedCases{ - \createExpression{\IVMLMeta{acc}(ca, d)}, & \text{if } ca \neq \undef \\ - \createExpression{\IVMLMeta{acc}(\IVMLMeta{var}(decl(v)), d)}, & \text{if } var \neq \undef \\ - \createExpression{\IVMLMeta{var}(s)}, & \text{else} - }$\; - \If{$v \neq \undef$}{ - $w \assng nested^*(v, name(d))$\; - \uIf{$n \neq \undef \wedge\text{ } value(w) \neq \undef$} { - $t \assng type(value(w))$\; - } - } - \If{$isCompound(t)$} { - \ForAll{$s \iterAssng slots(t)$} { - $add(\otherConstraints, translateAnnotationAssignment(e, s, v, \createExpression{\IVMLMeta{acc}(a, s)}), false, \undef)$\; - } - } - $deactivate(\variableMapping, d)$\; - } - } - - \ForAll{$b \iterAssng assignments(a)$} { - $translateAnnotationAssignments(b, ea, ca)$\; - } - - \caption{Translating annotation assignments (\IVML{translateAnnotationAssignments}).}\label{algTranslateAnnotationAssignments} -\end{algorithm} - -Algorithm \ref{algTranslateAnnotationAssignments} relies on the translation of an individual assignment data object. The translation of a single assignment from an assignment data $a$ leads to the creation of an assignment constraint as shown below. If a compound accessor $ca$ is given, the annotation is accessed through $ca$ and the respective annotation defined for the given variable declaration $d$ through ($annotation(d, name(a))$. If no accessor is given and the declaration $d$ is not in the variable mapping $\variableMapping$, $d$ is taken as accessor, else the actual accessor in $\variableMapping$. The accessor is used as the left side of an IVML assignment, the right side (value) is made up of the default value expression given by the assignment data $a$. - -\begin{align*} - translate&AnnotationAssignment(a, d, ca) = \\ - \createConstraint{\varSubstitutionSelfVarMapping{\IVML{assign}&(\IVMLMeta{ann}(\closedCases{ca, & \text{if } ca \neq \undef\\ d, & \text{if } ca = \undef \wedge \text{ }vm[d] = \undef \\ vm[d] &\text{else}}, \\ - &findAnnotation(d, name(a))), default(a))}{ca}} -\end{align*} - -\subsection{Constraint variables}\label{sectConstraintVariables} - -In IVML, the type \IVML{Constraint} exists, which allows defining variables, compound slots or containers of constraints. As for usual variables, the value of such a constraint variable can change unless frozen, i.e., the configuration process can influence the actual set of constraints to be checked on an IVML model. The important difference in translating - -There are four basic translation patterns, three are shown below. The basic idea is to translate the (default) value, a constraint expression, directly into a constraint performing appropriate variable substitutions. For constraint containers, we translate the element values, which represent constraint expressions. If either pattern is nested within a compound (not shown for constraint containers below), the translation substitution must particularly replace \IVML{self} by the actual compound variable. - -\grayPara{ -\begin{gather*} - \patternDerivation{\IVML{Constraint } v = ex\IVML{;}}{\varSubstitution{ex}{\variableMapping}}\\ - \patternDerivation{\IVML{containerOf(Constraint)} v = \IVML{\{}ex_1 , \ldots, ex_n\IVML{\}}\IVML{;}}{\varSubstitution{ex_1}{\variableMapping}, \ldots, \varSubstitution{ex_n}{\variableMapping}}\\ - \patternDerivation{\IVML{Compound } C = \IVML{ \{Constraint } s = ex \IVML{\}}\IVML{; } C v\IVML{;}}{\varSubstitution{ex}{\IVML{self}=v, \variableMapping}} -\end{gather*} -} - -In more details, Algorithm \ref{algCreateConstraintVariableConstraint} translates a constraint (if not undefined, including the IVML \IVML{null} case, i.e., a de-configured constraint variable). Algorithm \ref{algCreateConstraintVariableConstraint} creates constraints through variable substitution with $\variableMapping$ and, if available, a respective value for \IVMLself (here $f$), turning the resulting expression into a constraint and adding it to the set of other constraints $\otherConstraints$. Moreover, the relationship between the underlying variable $v$ and the constraint must be recorded for efficient update of the constraint base upon value change (cf. Algorithm \ref{algVarChange}). - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{constraint expression $c$, actual value for \IVMLself{} $f$, variable $v$} - \KwData{other constraints $\otherConstraints$} - \If {$c \neq \undef$} { - $c \assng \createConstraintConstraint{\varSubstitutionSelfVarMapping{c}{f}}$\; - $add(\otherConstraints, \set{c}, \neg isConst(c), v)$\; - $registerConstraint(v, c)$\; - } - \caption{Creating constraints for constraint variables (\IVML{createConstraintVariableConstraint}).}\label{algCreateConstraintVariableConstraint} -\end{algorithm} - -It is important to note that the constraint translation for collection leads to quantor expressions for initializing constraint variables. This is per se dangerous, as due to the variable substitutions, a constraint acting as a value may then relate to the quantor iterator variable(s). Evaluating such a constraint leads to undefined expressions, as the iterator variables are unbound and shall be substituted by appropriate variables (in most cases \IVMLself{}). When utilizing quantor expressions, defining individual substitutions based on the involved instances does not work (as this is the purpose of the quantor). So one solution is to unfold the implicit loop as discussed in Section \ref{sectContainerDefaults}. However, as quantor expressions over variable assignments are valid IVML and may be utilized in a model, the reasoner and the constraint evaluation must be able to work with them anyway. - -As solution, we perform the variable replacement when changing the constraint value, i.e., during constraint re-scheduling (Section \ref{sectTopLevelConstraintsRescheduling}). For short, we utilize the quantor expressions as discussed in this section, during quantor evaluation we register also the temporary iterator variables in the actual context, let the quantor evaluation assign the constraints to the variables, and consider this dynamically modified context during constraint re-scheduling. Constraint re-scheduling is anyway notified about the variable change and utilized to replace the old constraint by the new one in the constraint base. Thereby, we perform a variable substitution to bind the constraint to the actual variable taking into account the actual context including the iterator variables, i.e., we accept a temporary inconsistent constraint with unbound variables for the short time between assigning the constraint variable value and the directly subsequent constraint re-scheduling for this value change. However, this finally corrected constraint must be stored in the configuration so that saving the configuration can happen with the actual (consistent) constraint. - -\subsection{Constraint base operations}\label{sectContainerBase} - -In this section, we detail specific support operations to create and maintain the constraint based, most notably the $add$ function\footnote{\IVML{addConstraint} in the implementation, in this document $add$ for short due to layout reasons.}, which we used throughout this document to describe the individual translation algorithms. Besides adding a constraint $c$ to a given constraint sequence $s$, the $add$ function performs several important operations: - -\begin{itemize} - \item It filters out irrelevant constraints, in particular simple (default value) assignment constraints during incremental reasoning, are assumed to be already processed during previous iterations. Also constraints with all variables frozen or local (used for iterator variables in quantors) are filtered out ($isFrozen(c)$) if enabled, e.g., to speed up runtime reasoning. - \item It serves as the central place to finally compose constraints for nested compound containers using Algorithm \ref{algComposeExpression} and the variable mapping $\variableMapping$. - \item It analyzes the given constraint $c$ for the use of compound or container initializers. As explained above, these structures only occur in value assignments and actually must be analyzed for constraint variables, which must be turned into individual constraints. We perform this through the two recursive helper operations for expressions $checkContainerInitializer$ and $checkCompoundInitializer$ and two similar helper functions for values $checkContainerValue$ and $checkCompoundValue$ shown below\footnote{The implementation utilizes a visitor for this purpose.}. - \item Appends the constraint to the given sequence, except for constraints from eval-blocks, which are prepended to the sequence of top-level constraints $\topLevelConstraints$ if the target sequence is other $\otherConstraints$ or top-level constraints $\topLevelConstraints$ in order to enforce the priority of eval-constraints. - \item Registers the constraint with its used variables to enable re-scheduling of constraints during reasoning in Algorithm \ref{algVarChange}. -\end{itemize} - -Thus, the functiondoes not only add a given constraint, it completes it and scans it for further contained constraints. Let $ex$ be a constraint expression. Then we have to consider two specific assignment operations not transformed so far. - -\grayPara{ -\begin{gather*} - \patternDerivation{v = \IVML{\{}\ldots, ex,\ldots\IVML{\}}}{\ldots, \varSubstitution{ex}{\variableMapping}, \ldots}\\ - \patternDerivation{v = \IVML{\{} s = ex \IVML{\}}}{\varSubstitution{ex}{\IVML{self}=v, \variableMapping}} -\end{gather*} -} - -When unconditionally assigning a value to a variable, the right side may be a complex expression determining the actual value of a collection or a compound. In both cases, the contained values may be constraint values (not handled in \ref{sectConstraintVariables}), but also deeply nested values may be constraint values, e.g., a constraint value in a compound in collection used in a compound. These constraints contribute to the initial constraint base and may cause certain value changes that cannot just be achieved as a consequence of changing values in constraint re-scheduling (cf. Section \ref{sectTopLevelConstraintsRescheduling}). As the $add$ function is also called as part of re-scheduling, dynamic constraints discovered there and their initializers and values are treated similarly. - -\begin{algorithm}[H] - \KwIn{constraint sequence $s$, constraint $c$, perform initializers $check$, variable $v$} - \KwData{top level and other constraints $\topLevelConstraints, \otherConstraints$, variable mapping $\variableMapping$, relevant constraints $\relevantConstraintsPerDeclaration$ , incremental flag $inc$, evals flag $inEvals$} - $c = composeExpression(\variableMapping, c)$\; - \If{$check$}{ - \ForAll{d\iterAssng check(rightSide(c), \variableMapping)} { - $createConstraintVariableConstraint(d, \undef, \undef)$\; - } - $e\assng check(rightSide(c), \variableMapping)$ - $add(\otherConstraints, e, const(e) \neq \undef, v$\; - } - \If{$\closedCases{\neg isAssignment(c) \vee \neg isFrozen(c) & \text{if } inc\\ true & \text{else}}$}{ - \If{$inEvals \wedge (s=\otherConstraints \vee s = \topLevelConstraints)$} { - $\topLevelConstraints = c \addSeq \topLevelConstraints$\; - }\Else{ - $s \assng s \addSeq c$\; - } - \If{$\neg isSimpleConstraint(c)$}{ - $\relevantConstraintsPerDeclaration \assng \relevantConstraintsPerDeclaration \cup \setWith{\mapEntry{w}{c}}{w\in variables(c)}$\; % assignConstraintsToVariables - } - } - \caption{Adds a constraint to the constraint base ($add$).}\label{algAddConstraint} -\end{algorithm} - -To identify constraint variable values in containers and compounds, we define the following helper function: -\begin{align*} -check&(c, \variableMapping) =\\ - &\seqWith{\closedCases{check(e, \variableMapping), & \text{if } isContainerInitializer(e) \\ - check(e, \variableMapping), & \text{if } isContainer(type(e)) \\ - check(e, \variableMapping) & \text{if } isCompoundInitializer(e) \\ - check(e, \variableMapping) & \text{if } isCompound(type(e)) \\ - \createConstraintConstraint{\varSubstitutionVarMapping{e}}, &\text{if } isConstraint(e) \\ - \createConstraintConstraint{\varSubstitutionVarMapping{value(e)}}, &\text{if } isConstraintValue(e) \\ - \createConstraintConstraint{e}, &\text{if } Boolean(e) \\ - \emptySet, &\text{else} - }}{e\in expr(c) \cup elements(c)} -\end{align*} -The function $check$ either iterates over the constituting expressions if $c$ is a container or compound initializer or the contained values if $c$ is a container or compound value\footnote{Technically, we must make the distinction between initializer and constraint, as the IVML object model supports both types of elements here and the IVML parser creates a value if all contained elements are constant or otherwise an initializer expression}. If the contained element $e$ is a further container or compound initializer / iterator, then we continue iterating through recursion. If $e$ is a constraint expression (from an initializer), we apply the actual variable substitution and create a respective constraint. Similarly, for a constraint value $e$ obtained from a container or compound value. Finally, in case of container or compound values, we may have boolean constants, which can simply be turned into a constant constraint. - -%\begin{algorithm}[H] -% \KwIn{constraint sequence $s$, constraint sequence $c$, perform initializers $check$} -% \KwData{variable mapping $\variableMapping$} -% \ForAll{$d \iterAssng c$} { -% $add(s, d, c)$\; -% } -% \caption{Records and analyzes a constraint sequence.}\label{algAddConstraints} -%\end{algorithm} - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{variable $v$, constraint expression $c$} - \KwData{other constraints $\otherConstraints$, relevant constraints $\relevantConstraintVariables$}, relevant constraints copy $base_{\relevantConstraintVariables}$ - - \If{$v \neq \undef$}{ - $\relevantConstraintVariables \assng \relevantConstraintVariables \addMap \mapEntry{c}{v}$\; - $\relevantConstraintVariables[v] \assng \relevantConstraintVariables[v] \cup \set{c}$\; - \If{$base_{\relevantConstraintVariables} \neq \undef$} { - $base_{\relevantConstraintVariables} \assng base_{\relevantConstraintVariables} \addMap \mapEntry{c}{v}$\; - $base_{\relevantConstraintVariables}[v] \assng base_{\relevantConstraintVariables}[v] \cup \set{c}$\; - } - } - - \caption{Registering constraints originating fom constraint variables (\IVML{registerConstraint}).}\label{algRegisterConstraint} -\end{algorithm} -% -Recording happens only if $v$ is defined, which may not be the case if this algorithm is called while processing container values. Then, we recorder the relation of the variable $v$ to its - -\section{Constraint Re-scheduling}\label{sectTopLevelConstraintsRescheduling} - -When variable $v$ is changed as side effect of a constraint evaluation during reasoning, Algorithm \ref{algVarChange} is called. - - -If the changed variable is not local, i.e., neither a parameter of a user-defined function, an iterator of a container operation nor a local variable defined in a let-expression, the variable is relevant for re-scheduling. First, Algorithm \ref{algVarChange} registers in line \ref{algVarChangeScope} the change of $v$ within the actual project scope if the value of $v$ actually has been affected by reasoning. This scope information is used by the evaluator prior to a variable assignment to check for illegal duplicate assignments within the same scope. Then, if the value actually changed, we identify constraints that must be added to or removed from the constraint base. This may be due to nested constraint values (line \ref{algVarChangeRescheduleConstraintVariables}) in the new value as well as a type change of a compound value along the refinement hierarchy, which may require more or less constraints to be considered (line \ref{algVarChangeRescheduleValueTypeChange}). All these cases may affect the relevant constraints. When adding or removing constraints, new constraints are added to $\relevantConstraintVariables$ and $\relevantConstraintsPerDeclaration$, while now now irrelevant constraints are identified via $\relevantConstraintVariables$ and also removed from $\relevantConstraintVariables$ and $\relevantConstraintsPerDeclaration$. Finally , parent (line \ref{algVarChangeRescheduleParents}) and nested (line \ref{algVarChangeRescheduleNested}) constraints may need to be re-scheduled, too, if the related variables aside from constraint variables changed. This happens through a lookup to $\relevantConstraintsPerDeclaration$, implying that previously added / removed constraints due to value type changes are not re-scheduled. - -If the changed variable is local and there is a mapping in $\variableMapping$, e.g., as the variable is used as iterator in the evaluation of a quantor expression, we adjust the mapping\footnote{Technically, a local decision variable wraps either a value (if the evaluation runs over constants) or a decision variables. To allow for (call-by-reference) propagation on nested slots and attributes, changing the context registration actually refers to the actually wrapped decision variable, but this is not detailed here.}. - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{decision variable $v$, old value $val_o$} - \KwData{scope assignments $\scopeAssignments$, relevant constraints $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$} - - \If{$\neg isLocal(v)$}{ - $addAssignment(\scopeAssignments, v)$\; \label{algVarChangeScope} %addScopeAssignment - $val_n \assng value(v)$\; - \If{$val_n \neq val_o$} { - $rescheduleValueChange(v, v, true)$\; \label{algVarChangeRescheduleConstraintVariables} - \If{$isValueTypeChange(v, val_n, val_o)$ \MISSING{!}} { - $rescheduleValueTypeChange(v, val_n, val_o)$ \MISSING{!}\; \label{algVarChangeRescheduleValueTypeChange} - } - } - $base \assng base \addSeqNoDupl \seqWith{\relevantConstraintsPerDeclaration[p]}{p\in allParents(v)}$\; \label{algVarChangeRescheduleParents}%constraintsForParent - $base \assng base \addSeqNoDupl \seqWith{\relevantConstraintsPerDeclaration[n]}{n\in allNested(v)}$\; \label{algVarChangeRescheduleNested}%constraintsForParent -% $base \assng base \addSeqNoDupl \bigcup_{c\in alNested(v)}\relevantConstraints[c]$\; \label{algVarChangeRescheduleNested}%constraintsForChilds, nested geht für alle variablen - }\ElseIf{$getMapping(\variableMapping, decl(v)) \neq \undef$}{ - $registerMapping(\variableMapping, decl(v), v)$\; - } - \caption{Adjusting the constraint base (\IVML{notifyChanged}).}\label{algVarChange} -\end{algorithm} - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{parent variable $v_p$, decision variable $v$, old value $val_o$, clear flag $clear$} - - $t_n \assng type(value(v)))$\; - \uIf{$isConstraint(t_c)$} { - $rescheduleConstraintValue(v_p, v, clear)$\; - } \uElseIf{$isCompound(t_c)$}{ - $rescheduleCompoundValue(v, val_o)$\; - } \uElseIf{$isContainer(t_c)$}{ - $rescheduleContainerValue(v, val_o)$\; - } - - \caption{Reschedule a value change (\IVML{rescheduleValueChange}).}\label{algRescheduleContainerValue} -\end{algorithm} - - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{parent variable $v_p$, decision variable $v$, clear flag $clear$} - \KwData{scope assignments $\scopeAssignments$, relevant constraints $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$} - - \If{$isConstraint(type(v)$} { - $cs \assng obtainConstraints(v_p, clear, \undef)$ \MISSING{!}\; - $ex \assng getConstraintValueConstraintExpression(value(v))$ \MISSING{!}\; - \If{$ex \neq \undef$}{ - \lIf{$cs = \undef \vee |cs|=0$}{$p\assng parent(decl(v))$}\lElse{$parent(cs[0])$} - $ex_p \assng createParentExpression(v)$\; - $c \assng createConstraintVariableConstraint(ex, ex_p, \undef, p, v_p)$ \MISSING{!}\; - $setValue(v, c)$\; - $base \assng base \addSeq \otherConstraints$\; - \ForAll{$p\iterAssng allParents(v)$}{ % variablesMap.addAll(variable, otherConstraints); - $\relevantConstraintsPerDeclaration \assng \relevantConstraintsPerDeclaration \addMap \mapEntry{p}{\relevantConstraintsPerDeclaration [v] \cup \otherConstraints}$\; - } - $\otherConstraints \assng \emptySet$\; - } - } - \caption{Reschedule a constraint value (\IVML{rescheduleConstraintValue}).}\label{algRescheduleConstraintValue} -\end{algorithm} - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{decision variable $v$, old value $val_o$} - \KwData{scope assignments $\scopeAssignments$, relevant constraints $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$} - - \If{$isCompound(v)$}{ - \ForAll{$s\iterAssng slots(value(v))$}{ - \If{$value(s) \neq \undef$}{ - $rescheduleValueChange(s, s, value(s), true);$\; - } - } - } - \caption{Reschedule a compound value (\IVML{rescheduleCompoundValue}).}\label{algCompoundValue} -\end{algorithm} - -\begin{algorithm}[H] - \SetAlgoLined - \KwIn{decision variable $v$, old value $val_o$} - \KwData{scope assignments $\scopeAssignments$, relevant constraints $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$} - - $val_n \assng value(v))$\; - \If{$isContainer(type(val_n)) \wedge isContainer(type(val_o))$}{ - $first \assng true$\; - \ForAll{$c \iterAssng elements(val_n), o \iterAssng elements(val_o)$} { - $rescheduleValueChange(v, c, o, first)$\; - $first \assng false$\; - } - } - - \caption{Reschedule a container value (\IVML{rescheduleContainerValue}).}\label{algContainerValue} -\end{algorithm} - -\section{IVML-Completeness}\label{sectCompleteness} - -In this section, we discuss the completeness of the reasoner with respect to IVML concepts. Reasoning completeness, e.g., involving advanced reasoning capabilities such as narrowing down value instances by limiting constraints or instance creation, is not topic of this section and may be targeted by future work. - -\begin{table*}[ht] -%\begin{adjustbox}{angle=90} -\centering -\begin{tabular}{|p{3cm}|c||p{4cm}|p{3.5cm}|} -\hline -\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation Path} & \textbf{Test}\\ -\hline - \multicolumn{4}{|c|}{Types (Top-level concepts)}\\ -\hline - -Decision variable & 2.1.4 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTranslationDeclaration}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & \textit{all} \\ - -Constraint & 2, 3 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTopLevelConstraints} & B2, ...\\ - -Constraint variable & 3.1.10 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTranslationDeclaration}\tabAlgFollow\tabAlgLines{algTranslateDeclaration}{algTranslateDeclarationTranslateConstraintDefaultStart}{algTranslateDeclarationTranslateConstraintDefaultEnd}, change \tabAlg{algVarChange}\TBD{addLine} & Cs1, Cs2, CsCtCn1 \\ - -Annotation & 2.2.2 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTranslationDeclaration}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationAnnotationDefault}\tabAlgFollow\tabAlgLine{algTranslateAnnotationDeclarations}{algTranslateAnnotationDeclarationsTranslateDeclV} or \tabAlgLine{algTranslateAnnotationDeclarations}{algTranslateAnnotationDeclarationsTranslateDeclD} \tabAlgFollow Table \ref{tab:completenessAnnotations} & A1, A2, A3\\ - -Assignment block & 2.2.2 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTopLevelAnnotationAssignments}\tabAlgFollow\tabAlg{algTranslateAnnotationAssignments} & CnAI1 \\ -$\triangleright$ constraints & 2.2.2 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTopLevelAnnotationConstraints} & AI2 \\ - -Partial evaluation & 2.2.5.3 & \tabAlgLine{algTranslateConstraints}{algTranslateConstraintsTopLevelEvals} & Ev1\\ - -Interfaces & 2.2.4.3 & no specific support needed & If1, If2\\ - -re-assignment & 2.1.4, 3.1.4 & \tabAlgLine{algVarChange}{algVarChangeScope}, \tabAlgLines{algEvalLoop}{algEvalLoopClearScope}{algEvalLoopSetScope} & Sc1, Sc2, Sc3\\ - -\hline - \multicolumn{4}{|c|}{Non-complex types (typed decision variable, starting in \tabAlg{algTranslateDeclaration})}\\ -\hline - -Integer type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & I1, I2\\ - -Real type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & R1, R2\\ - -Boolean type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & B1, B2, B3 \\ - -String type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & S1, S2\\ - -Enum type & 2.1.3.2 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & E1, E2\\ - -Reference type & 2.2.3.2 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault}, cf. Sect. \ref{sectNotationOthers} & BF1, EF1\\ - -Derived type & 2.1.3.4 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationDerivedDatatype}\tabAlgFollow\tabAlg{algTranslateDerivedDatatypeConstraints} -& IT1, IT2 \\ - -Constraint type & 3.10.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationConstraintVariableConstraint}\tabAlgFollow\tabAlg{algCreateConstraintVariableConstraint} & Cs1, Cs2\\ - -\hline -\end{tabular} -%\end{adjustbox} -\caption{Translations for top-level and non-complex types.} -\label{tab:completenessTopLevelTypes} -\end{table*} - -To indicate the IVML completeness, we enumerate all relevant IVML concepts, their definition in the IVML specification~\cite{IVML-LS}, the transformation path along the algorithms presented in this document and the test cases validating the transformation and the reasoning results. We separate the argumentation into four parts and present for each path the relation of specification entry, transformation path and test cases in terms of a summarizing table. The four parts are 1) top-level concepts / basic types (Table \ref{tab:completenessTopLevelTypes}), compound types (Table \ref{tab:completenessCompounds}), container types (Table \ref{tab:completenessContainers}) and annotations (Table \ref{tab:completenessAnnotations}). Test cases are referenced by ids in order to indicate that all relevant combinations are subject to regression testing in the continuous build process of EASy-Producer. The referenced test cases are detailed in Appendix \ref{appendixTestCases}. - -\pagebreak - -\TBD{Check quantized instance constraints.} - -\begin{table*}[ht] -%\begin{adjustbox}{angle=90} -\centering -\begin{tabular}{|p{3.5cm}|c||p{6cm}|p{3.5cm}|} -\hline -\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation Path} & \textbf{Test}\\ - -\hline - \multicolumn{4}{|c|}{Compound types}\\ -\hline - -Integer type & 2.1.3.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & ICo1, ICo2\\ - -Real type & 2.1.3.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & RCo1, RCo2\\ - -Boolean type & 2.1.3.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & BCo1, BCo2, BCo3 \\ - -String type & 2.1.3.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & SCo1, SCo2\\ - -Enum type & 2.1.3.2 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & ECo1, ECo2\\ - -Derived type & 2.1.3.4 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationDerivedDatatype}\tabAlgFollow\tabAlg{algTranslateDerivedDatatypeConstraints} & CnTCt1, CnTCt2, CnTF1 \\ - -Reference type & 2.2.3.2 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & FCn1, FCn2, FCn3, CnTF1 \\ - -Compound type & 2.1.3.5 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateCompound}\tabAlgFollow\tabAlg{algTranslateCompoundDeclaration} $\ldots$ & Cn2, Cn3 \\ - -Container type & 2.1.3.3 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateContainer}\tabAlgFollow Table \ref{tab:completenessContainers} & CnCt3, CnCt4 \\ - -Constraint type & 3.10.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLines{algTranslateDeclaration}{algTranslateDeclarationTranslateConstraintDefaultStart}{algTranslateDeclarationTranslateConstraintDefaultEnd}, change \tabAlg{algVarChange}\TBD{addLine} & CsCn1, CsCn2, CsCtCn1 \\ - -Constraints & & \tabAlgLines{algTranslateCompoundDeclaration}{algTranslateCompoundDeclarationAllStart}{algTranslateCompoundDeclarationAllEnd}& Cn1, CnCs1 \\ - -\IVML{self} & 3.1.6 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateSelf1}, \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateSelf2}, \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateSelf3} & CnA3 \\ - -Annotation & 2.2.2 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$, cf. Table \ref{tab:completenessTopLevelTypes} & CnA3\\ - -Assignment blocks & 2.2.2 & \tabAlgLine{algTranslateCompoundContent}{algTranslateCompoundDeclarationCompoundAssignments}\tabAlgFollow\tabAlg{algTranslateAnnotationAssignments} & CnAI2, CnAI3 \\ -$\triangleright$ constraints & 2.2.2 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationAllStart}{algTranslateCompoundDeclarationAllEnd} & CnA4 \\ - -Partial evaluation & 2.2.5.3 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationEvalStart}{algTranslateCompoundDeclarationEvalEnd} & CnEv1 \\ - -\hline -\end{tabular} -%\end{adjustbox} -\caption{Compound translations, starting with \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateCompound}\tabAlgFollow\tabAlg{algTranslateCompoundDeclaration} and \tabAlg{algRegisterCompoundMapping}.} -\label{tab:completenessCompounds} -\end{table*} - -\pagebreak - -\TBD{No annotation, assignment blocks and partial evaluation possible from IVML syntax. Accessor-based access handled by \tabAlg{algTranslateDeclaration}.} - -\begin{table*}[ht] -%\begin{adjustbox}{angle=90} -\centering -\begin{tabular}{|p{4cm}|r||p{6cm}|p{3cm}|} -\hline -\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation Path} & \textbf{Test}\\ - -\hline -% \multicolumn{4}{|c|}{Compound types}\\ % disabled due to page break/moving tables to the end -%\hline - -Integer type & 2.1.3.1 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & ICt1, ICt2\\ - -Real type & 2.1.3.1 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & RCt1, RCt2\\ - -Boolean type & 2.1.3.1 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & BCt1, BCt2 \\ - -String type & 2.1.3.1 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & SCt1, SCt2\\ - -Enum type & 2.1.3.2 & no action in \tabAlg{algTranslateContainerDeclaration}, cf. Sect. \ref{sectNotationOthers} & ECt1, ECt2 \\ - -Derived type & 2.1.3.4 & \tabAlgLine{algTranslateContainerDeclaration}{algTranslateContainerDeclarationDerivedTypes}\tabAlgFollow\tabAlg{algTranslateDeclaration} & ITCt1, ITCt2 \\ - -Compound type & 2.1.3.5 & \tabAlgLines{algTranslateContainerDeclaration}{algTranslateContainerDeclarationCompoundContainerStart}{algTranslateContainerDeclarationCompoundContainerEnd}\tabAlgFollow\tabAlgLines{algTranslateCompoundContainer}{algTranslateDefaultsCompoundContainerMapping}{algTranslateDefaultsCompoundContainerContent}\tabAlgFollow\tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & CnCt3, CnCt4 \\ - -Derived compound type & 2.1.3.3 & \tabAlgLine{algTranslateContainerDeclaration}{algTranslateContainerDeclarationDerivedTypes} \tabAlgFollow \tabAlg{algTranslateDerivedDatatypeConstraints} & ITCnCt1, ITCnCt2 \\ - -Container type & 2.1.3.3 & \tabAlgLines{algTranslateContainerDeclaration}{algTranslateContainerDeclarationCompoundContainerStart}{algTranslateContainerDeclarationCompoundContainerEnd}\tabAlgFollow\tabAlgLines{algTranslateCompoundContainer}{algTranslateDefaultsCompoundContainerMapping}{algTranslateDefaultsCompoundContainerContent}\tabAlgFollow\tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & CnCt2, CtTF1 \\ - -Derived container type & 2.1.3.3 & \tabAlgLine{algTranslateContainerDeclaration}{algTranslateContainerDeclarationDerivedTypes}\tabAlgFollow\tabAlg{algTranslateDerivedDatatypeConstraints} & CtTCt1, CtTF1 \\ - -Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & CnFCt1, CnTFCt1 \\ - -Constraint type & 3.1.10 & \tabAlgLine{algTranslateContainerDeclaration}{algTranslateContainerDeclarationConstraintContainer}, change \tabAlg{algVarChange}\TBD{addLine} & CnCt1, CnCt2, CsCtCn1 \\ - -Annotation & 2.2.2 & top-level only, see Table \ref{tab:completenessTopLevelTypes} & TFCnCtCsA1 \\ - -Assignment blocks & - & - & - \\ - -Partial evaluation & - & - & - \\ - -\hline -\end{tabular} -\caption{Translation of containers, starting with \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateContainer}\tabAlgFollow \tabAlg{algTranslateContainerDeclaration}} -\label{tab:completenessContainers} -%\end{adjustbox} -\end{table*} - -\pagebreak - -\TBD{Recursive annotations are not supported by IVML, add section number below. A*1 means all annotation-related tests, which focus on one specifc type used in the annotation, e.g., ACn1 for a compound used in an annotation, but always applied to all relvant types.} - -\begin{table*}[ht] -%\begin{adjustbox}{angle=90} -\centering -\begin{tabular}{|p{4cm}|r||p{4cm}|p{2.5cm}|p{2.5cm}|} -\hline -\textbf{IVML concept} & \textbf{Spec} & \textbf{Transformation Path} & \textbf{Test as annotation} & \textbf{Test anotate to}\\ -\hline - \multicolumn{5}{|c|}{Annotations (starting with \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationAnnotationDefault}\tabAlgFollow\tabAlgLine{algTranslateAnnotationDeclarations}{algTranslateAnnotationDeclarationsTranslateDeclV} or \tabAlgLine{algTranslateAnnotationDeclarations}{algTranslateAnnotationDeclarationsTranslateDeclD} cf. see Table \ref{tab:completenessTopLevelTypes})}\\ -\hline - -Integer type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & CnAI1, AI1 & CnAI1, A*1 \\ - -Real type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & AR1 & A*1 \\ - -Boolean type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & AB1 & A*1 \\ - -String type & 2.1.3.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & AS1 & A*1\\ - -Enum type & 2.1.3.2 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & AE1 & A*1\\ - -Derived type & 2.1.3.4 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationDerivedDatatype}\tabAlgFollow\tabAlg{algTranslateDerivedDatatypeConstraints} & ATCn1 & A*1 \\ - -Compound type & 2.1.3.5 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateCompound}\tabAlgFollow\tabAlg{algTranslateCompoundDeclaration}\tabAlgFollow\tabAlgLine{algRegisterCompoundMapping}{algRegisterCompoundMappingAnnotationMapping}\tabAlgFollow\tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess} & ACn1 & CnAI1, A*1 \\ - -Container type & 2.1.3.3 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateAnnotationAccess}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateDefault} & ACt1 & A*1 \\ - -Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & AFCn1 & A*1 \\ - -Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers}& ACs1 & A*1 \\ - -Annotation & - & - & - & -\\ - -Assignment blocks & - & - & - &- \\ - -Partial evaluation & - & - & - &- \\ - -\hline -\end{tabular} -\caption{Translation of annotations starting with \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationAnnotationDefault}} -%\end{adjustbox} -\label{tab:completenessAnnotations} -\end{table*} - -\TBD{annotation on typedef-ref, ref-typedef, variable on typedef-ref, ref-typedef} - -\pagebreak - -%----------------------------------------------------------------------------------------------------------------- - -\section{Evaluation}\label{sectEvaluation} - -\TBD{Keep or remove that section. However, some basic performance evaluations should not be so difficult. All executions need multiple runs, in particular to even out JIT compilation. It seems that this is done during/after the second reasoning run. Potential topics: - -\begin{itemize} - \item Artificial models of some size/variable/constraint ratio. Christian had a generator for that and Roman typically did some evaluations using these models. Compare to known results where available. - \item QualiMaster full, incremental, runtime reasoning (full, no defaults, no frozen, reuse constraint base). Runtime vs. full reasoning seems to behave rather linearly, at around 23 constraints evaluated per ms. Compare to known results where available. - \item All test cases involving reasoning as an overview map. - \item Eclipse 4.7/Java9 runs tests with asserts!!! -\end{itemize} - -} - -%----------------------------------------------------------------------------------------------------------------- - -\section{Performance Considerations}\label{sectPerformance} - -In this section, we briefly collect some observations seen/refactored/solved/left over during the improvement of the reasoner. Although the considerations may appear rather reasoner specific or specific to the IVML object model, they typically stem from more general Java performance optimization knowledge typically hidden behind constraints, reasoner or model data structures. \TBD{The individual texts may be pretty short, and are currently just intended for remembering/recording the obstacles.} - -\begin{itemize} - \item For lists of unknown size and for the expected capacity of IVML models, use \textbf{linked lists} instead of array lists. Main operations are adding, iterating over all, lookup of and removing elements to clean up memory incrementally, i.e., linked lists can avoid performance-impacting resizing effects. To speed up removal and lookup, we combined a linked list and a hashtable in a special constraint base class. Index-based access is not needed, constraints are just added and one iteration is needed to build up the constraint base or to perform reasoning. Pre-calculation of the expected size of the data structures per model seems to be unfeasible as this requires a second run over all model elements. - \item Process the \textbf{constraint base} iteratively and remove processed constraints directly after processing. This again requires a linked list as otherwise incremental resizing effects can affect the performance. In summary, building the constraint base and reasoning causes peak memory effects that are better from a performance point of view than (re-)allocating big array memory blocks. - \item Avoid having too many unneeded \textbf{partitions of the constraint base} being stored during the translation in different lists, that are finally added to the constraint base. Try to directly add constraints where possible to the constraint base, e.g., for default constraints to avoid iterating over the complete constraint base before reasoning. However, due to the prioritization of the constraint types and their required sequence, this is not always possible. One alternative, a numeric prioritization of the individual constraints would require sorting the constraint base, at the new parts not the left-over constraints to be re-evaluated from a previous reasoning steps. However, implicit sorting on insertion according to priorities could help here. To speed up operations for such constraint lists, we use a specific linked constraint list, which transfers the nodes the linked nodes upon adding the constraints to the constraint base (based on this specific linked list). - \item Create/translate a \textbf{constraint in one step}, if required in compounds split into filling the variability mapping and then creating the constraints based on the actual mapping. - \item Try to figure out whether a certain \textbf{constraint (type) is actually needed} for reasoning and avoid its translation/creation wherever feasible. \TBD{Can we move the decision about keeping a constraint from adding it to the constraint base before constraint creation. However, this requires changes/additional alternatives for different code parts.}. Thus, don't re-process or filter certain constraint types at the end (done in the initial version for default and derived type constraints), as this implies iterating multiple times over the (partial) constraint base and re-creating/throwing away constraint instances in memory. - \item \TBD{Avoid storing constraints that can be \textbf{processed immediately}, e.g., default constraints without dependencies. However, if a default constraint fails, it must be added to the constraint basis for later possible re-evaluation if dependent values become available/right.} - \item For identifying whether constraints are already in the constraint base, use a \textbf{fast look-up structure} instead of an iteration over the constraint base. Although the initial implementation utilized here reference equality (faster than the equals method), the current lookup structure is significantly faster (approx. 600 ms on large models, at that time around 25\% of runtime) than the original approach trading off execution speed for (peek) memory. Here a lookup structure based on reference equality could further speed up reasoning, which, however, may in the end be slower than the built in collections due to JIT compilation and JVM optimization effects. This is even true for the stack-based variable mapping $\variableMapping$, which performs as fast as a flat map, which may roughly serve for the main purpose of $\variableMapping$, but not for composing complex constraints from nested compunds and containers. - \item Incremental reasoning using a \textbf{stored constraint base} may speed up reasoning but only achieves this through large memory allocations. Ensure initializing the model through default constraints so that the actual stored constraint base only contains really needed constraint types, i.e., no default constraints and, if possible, no constraints for which all depending variables are already frozen. - \item \textbf{Reuse visitor instances} if applied more than once, in particular reasoners with more complex internal data structures such as maps or lists. This required some refactoring of the IVML model implementation. - \item \textbf{Avoid temporary instances}, e.g., iterators, temporary constraint creation, temporary data structures wherever possible. One option replacing a collection structure is to define a functor for processing the elements and to create a reusable instance of that functor. If permitted by the Java environment settings (EASy often compiles against JDK 1.6), also a lambda-function instead of a heavy-weight functor class may be appropriated. - \item \textbf{Avoid multipe variable substitutions} per constraint expressions, i.e., join variable substitutions wherever possible. Variable substitution copies the expression. Initially, performing a substitution multiple time on the same expression caused creating multiple copies of all nodes in memry, i.e., a follow-up copy usually was used instead of the original copy making the previous copies effectively superfluous. As sometimes multiple substitutions can only be avoided with additional (not straightforward) code, e.g., for a sequential call of Algorithm \ref{algTranslateCompoundDeclaration} and \ref{algTranslateDeclaration}, we revised the IVML expression copy mechanism to create instances of expression tree nodes only if a substitution happend, i.e., new expression trees are absolutely required. - \item \textbf{Use instance pooling} if datastructures are temporarily used, e.g., variable accessors in expression evaluation or sets of compounds in reasoning (20-30 ms on larger models, at that time around 10\% of runtime). -\item visitor is faster than (IVML-)instanceof -\end{itemize} - -There are still opportunities for further speeding up the reasoning operations. On an Intel core i7, the reasoner reaches around 15-43 constraint evaluations in average per millisecond - runtime vs. full reasoning on the latest QualiMasster test model, currently reasoning time includes translation and evaluation time \TBD{Sepearte timing}. This is already an improvement over the initial version, which operated at around 10 evaluations per millisecond in average (also with a higher number of constraint evaluations due to unneeded and uneffective constraints). The constraint evaluation time probably suffers from the immutable structured values in EASy-Producer, which are created for each assignment. Knowing that most of the assignments in this model are done for basic IVML datatypes, a fast track for setting integer, double, boolean and String values could increase the number of evaluations, but requires careful extension, as changing values shall only be allowed via decision variables, which take care of the current assignment state, e.g., \IVML{FROZEN}. - - -%----------------------------------------------------------------------------------------------------------------- - -\section{Conclusion}\label{sectConclusion} - -\TBD{We are better than before, we are now more IVML-complete, but not reasoning-complete. Future, integrate with SMT or other solvers for left-over reasoning problems or configuration completion/instance creation (potential student work).} - -%----------------------------------------------------------------------------------------------------------------- +\input{introduction} +\input{approach} +\input{notation} +\input{reasoningAlg} +\input{consTranslation} +\input{consRescheduling} +\input{ivmlCompleteness} +\input{evaluation} +\input{performance} +\input{conclusion} \section*{Acknowledgements} Index: /reasoner/reasoningAlg.tex =================================================================== --- /reasoner/reasoningAlg.tex (revision 144) +++ /reasoner/reasoningAlg.tex (revision 144) @@ -0,0 +1,218 @@ +% trim={ } +\begin{figure}[h] +\center +%\frame{...} +\includegraphics[scale=0.48,trim={5.1cm 6.2cm 26.5cm 0.3cm},clip]{figures/structure.pdf} +\caption{Structuring blocks, algorithms and sections.} +\label{figStructure} +\end{figure} + +\section{Reasoning algorithm}\label{sectReasoning} + +\newcommand\defaultConstraints[0]{c_d} +\newcommand\deferredDefaultConstraints[0]{c_{dd}} +\newcommand\otherConstraints[0]{c_{o}} +\newcommand\topLevelConstraints[0]{c_{t}} +\newcommand\relevantConstraintsPerDeclaration[0]{r_d} +\newcommand\relevantConstraintVariables[0]{r_c} +\newcommand\scopeAssignments[0]{a} +%\newcommand\usedVariables[0]{u} +\newcommand\problemRecords[0]{m} + +The reasoner performs forward reasoning, i.e., it identifies relevant constraints according to the reasoning mode, translates the constraints, stores constraint relations, evaluates the translated constraints in a loop until all constraints are processed and adjusts/extends the constraint set upon variable value changes. Figure \ref{figStructure} shows the call graph of the reasoner algorithms and the sections where we will discuss them in more detail. Some algorithms call others recursively due to the potentially recursive structure of some IVML types, in particular compounds and containers. Algorithm \ref{algAddConstraint} and \ref{algComposeExpression} appear disconnected, but are called by most of the translation algorithms to populate the constraint base and to compose complex constraints from recursive nesting of containers and compounds. + +This section introduces the top-level reasoning algorithms, in particular the main reasoning loop in Section \ref{sectTopLevelMainReasoningLoop}, the reasoner data structures in Section \ref{sectDataStructures}, the top-level constraint translation in Section \ref{sectTopLevelConstraintsTranslation}, and the top-level constraint evaluation in Section \ref{sectTopLevelConstraintsEvaluation}. The algorithms for constraint translation will be discussed in detailed in Section \ref{sectTranslation} and the algorithms for re-scheduling constraints in Section \ref{sectTopLevelConstraintsRescheduling}. + +\subsection{Main Reasoning Loop}\label{sectTopLevelMainReasoningLoop} + +The main reasoning loop implements the overall control for the IVML reasoning process. The reasoning loop receives a configuration $cfg$ as input and utilizes various global data structures. + +First, Algorithm \ref{algMainLoop} sets up the global configuration variable $cfg$ and the expression evaluator\footnote{In the implementation, the listener for changed variables triggering constraint re-scheduling (Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling}) as well as recording of assigned variables are registered with the expression evaluator. These details are omitted here.} in lines \ref{algMainLoopSetupVar}-\ref{algMainLoopSetupEval} for use with the configuration $cfg$ and the scope assignments $\scopeAssignments$. In line \ref{algMainLoopStartTime} it stores the start time to terminate potentially endless loops induced by ping-pong assignments among constraints within a given maximum time. The remainder of the algorithm is separated into two parts, the full execution (lines \ref{algMainLoopFullStart}-\ref{algMainLoopFullEnd}), and the incremental part (lines \ref{algMainLoopIncStart}-\ref{algMainLoopIncEnd}) utilizing a constraint base prepared and stored while running the first part. + +As shown in Algorithm \ref{algMainLoop}, first structures are created to store constraints for reuse (if $reuse$ is enabled), here for copying the constraint base ($base_c$), the relevant constraints per declaration ($base_{\relevantConstraintsPerDeclaration}$, a mapping of declarations to using constraints) and the relevant constraint variables per decision variable ($base_{\relevantConstraintVariables}$, bidirectional mapping between constraint values assigned to configured decision variables). Then, the reasoner\footnote{In the implementation, translation and reasoning happen in \class{Resolver.java}.} must take the structure of IVML models into account, which is determined by the top-level IVML project making up $cfg$ and a cycle-free traversal of the imports of the top-level project. $discoverProjects(cfg)$ (line \ref{algMainLoopDiscover}, not further detailed in this document), performs a depth-first traversal of the import structure, ignores already seen cyclic imports and returns the processing sequence of all projects involved in $cfg$, i.e., the imported projects sorted in ascending manner according to their number of import dependencies. The loop processes this project sequence as long as no timeout occurred (global flag $hasTimeout$) or the user requests a stop of the reasoning (global flag $stop$). + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{configuration $c$} + \KwData{configuration $cfg$, expression evaluator $e$, scope assignments $\scopeAssignments$, start time $startTime$, $reuse$ flag, constraint relations $\relevantConstraintsPerDeclaration$ and $\relevantConstraintVariables$, constraint base copy $base_c, base_{\relevantConstraintsPerDeclaration}, base_{\relevantConstraintVariables}$, $projects$ sequence, $hasTimeout$ and $stop$ flags}%, problem records $\problemRecords$ + \KwResult{Reasoning result $r$} + + $cfg\assng c$\; \label{algMainLoopSetupVar} + %evaluator.init()\; + %evaluator.setResolutionListener(Algorithm \ref{algVarChange})\; + %evaluator.setScopeAssignments(sAssng)\; + $setup(e, cfg, \scopeAssignments)$\; \label{algMainLoopSetupEval} + $startTime = now()$\;\label{algMainLoopStartTime} + \uIf{$base_c = \undef$}{ \label{algMainLoopFullStart} + \If{$reuse$}{ + $base_c = \emptySeq{}$\; %sequence? + $base_{\relevantConstraintsPerDeclaration} = \emptyMap{}$\; + $base_{\relevantConstraintVariables} = \emptySet{}$\; %map? + } + $projects \assng discoverImports(cfg)$\; \label{algMainLoopDiscover} + \ForAll{$p \iterAssng projects \wedge \neg hasTimeout \wedge \neg stop$}{ \label{algMainLoopStart} + $translateConstraints(p)$\; \label{algMainLoopTranslate} + $evaluateConstraints(p)$\; \label{algMainLoopEvaluate} + $freeze(cfg, p)$\; \label{algMainLoopFreeze} + } \label{algMainLoopEnd}\label{algMainLoopFullEnd} + }\Else {\label{algMainLoopIncStart} + $\relevantConstraintsPerDeclaration \assng base_{\relevantConstraintsPerDeclaration}$\;\label{algMainLoopResetRelStart} + $\relevantConstraintVariables \assng base_{\relevantConstraintVariables}$\;\label{algMainLoopResetRelEnd} + \ForAll{$i \in \set{0, \ldots, |base_c|} \wedge \neg hasTimeout \wedge \neg stop$}{ + $base \assng base_c[i]$\; + $evaluateConstraints(projects[i])$\; + $freeze(cfg, projects[i])$\; + } + }\label{algMainLoopIncEnd} + $r \assng createReasoningResult(m, hasTimeout, stop)$\; \label{algMainLoopResult} + \caption{Main reasoning loop (\IVML{resolve}).}\label{algMainLoop} +\end{algorithm} + + +For each project $p$, the main loop (lines \ref{algMainLoopStart} - \ref{algMainLoopEnd}) translates the constraints in $p$ and populates the constraint base as a side effect of the constraint translation called in line \ref{algMainLoopTranslate} (detailed in Section \ref{sectTopLevelConstraintsTranslation}). If enabled through $reuse$, the constraint translation stores the respective population of constraints in $base_c$ and their relations in $base_{\relevantConstraintsPerDeclaration}$ and $base_{\relevantConstraintVariables}$. Then the algorithm performs a forward-chaining evaluation of the constraint base in line \ref{algMainLoopEvaluate} (explained in Section \ref{sectTopLevelConstraintsEvaluation}). If a constraint changes a configuration variable as a side effect, the constraints related to that variable are re-scheduled for evaluation (detailed by Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling}). As last step for a project $p$, the algorithm freezes the actual values according to the (conditional) freeze-block specifications in $p$ in line \ref{algMainLoopFreeze}. + +In incremental execution (lines \ref{algMainLoopIncStart}-\ref{algMainLoopIncEnd}), it is sufficient to reset the constraint relations in lines \ref{algMainLoopResetRelStart}-\ref{algMainLoopResetRelEnd}, i.e., the mapping of constraints per declaration $\relevantConstraintsPerDeclaration$ and the mapping between constraint variables and decision variables $\relevantConstraintVariables$, to iterate over all stored projects in $base_c$. For each project, the algorithm takes over the respective constraints from $base_c$ into the actual constraint base, and, as before, evaluates the constraints and freezes the variables. + +Finally, after all projects have been considered or the main reasoning loop has been terminated prematurely, the algorithm composes\footnote{In the implementation, this is done in \class{Engine.java}, the actual reasoner instance, which creates and utilizes instances of \class{Resolver.java}.} in line \ref{algMainLoopResult} a detailed reasoning result based on recorded evaluation problems. This reasoning result also indicates a successful or failed execution, in particular whether a timeout occurred or a user-requested cancellation was requested. + +\subsection{Data Structures}\label{sectDataStructures} + +This section introduces the most important data structures needed to describe the operations of the IVML reasoner, namely the variable mapping structure (Section \ref{sectVarMapping}) and the scope assignments structure (Section \ref{sectScopeAssignments}). + +\subsubsection{Variable Mapping}\label{sectVarMapping} + +During the constraint translation, top-level constraints can directly be evaluated over involved top-level variables. As already mentioned in Section \ref{sectNotationConstraints}, constraints defined on compound slots or indirectly through use of compound instances in containers must be translated before evaluation. The particular issue here is that these constraints can be defined in an IVML model over types (for which no values can be assigned in a configuration) rather than over top-level variables. A solution is to rewrite these constraints by substituting type-local variables by appropriate accessors starting at top-level variables. To manage the various lots and access expressions, the translation utilizes a stack-based data structure, onto which we push/pop a context frame for each IVML project and each contained compound type, container type or combinations of both used in variables of a project. A context frame links all currently relevant variables to the correct accessor expressions, which are created before the respective variable substitutions are applied. + +However, a simple stack is not sufficient for two reasons, namely nested complex types, excluded types and assignment blocks. As we will detail below, nested complex types require constraint rewriting through a prefix composed of nested all-quantifiers. Therefore, the stack frames can store the information needed to create the respective quantifier expression. When adding a constraint to the constraint base, we visit the stack frames and, if such information is available, incrementally qualify the expression by the described quantifier. The constraint rescheduling re-uses the constraint transformation. However, performing a complete transformation of all types related to certain value change is typically not needed, so that excluding types from the translation speeds up the re-scheduling operations. Moreover, IVML projects and compounds can contain nested assignment blocks. An assignment block implicitly defines assignment constraints for its contained variable declarations including containers or compounds. If we translate first variable declarations and then the related constraints, these constraints are outside their actual scope and, thus, relevant access expressions are not available, i.e., wrong constraints would be added to the constraint bae. Intermingling compund/container translation with annotation-block translation would be a potential solution, which increases the algorithm / code complexity. Thus, we opted to register a declaration with its context frame (which is then implicitly registered with its parent frame for proper cleanup) and to activate/deactivate such a frame, although it is not on top of the stack, when translating the implicit assignment constraints in an assignment block. Such stack frames are also removed from the stack when popping the respective parent context frame. + +In summary, the variable mapping stack structure $\variableMapping$ of the IVML reasoner provides the following operations: + +\begin{itemize} + \item $setRegisterContexts(\variableMapping, b)$ enables automatic registration of context frames within the parent frame. The operation returns the previous state of the registration flag. + \item $isContextsRegistering(\variableMapping)$ returns whether context registering is currently active. + \item $pushContext(\variableMapping, d, r)$ creates and pushes a new context frame for declaration $d$ to the stack. If registration of contexts is enabled, $r$ indicates whether the new frame shall be registered with the parent frame and whether already processed types (for handling nested complex types) shall be recorded by this context. + \item $pushContext(\variableMapping, d, c,v, r)$ works like $pushContext(\variableMapping, d, r)$, but registers also information for creating an all-quantified constraint prefix for all constraints added to the constraint base as long this frame is on the stack. The information includes the container expression $c$ and the typed iterator variable $v$ over the element type of $c$. We will apply this function in Section \ref{sectContainerDefaults}. + \item $popContext(\variableMapping)$ removes the top-most context frame. The initial frame, which is created by default and devoted to the enclosing IVML project, is not removed by this operation. + \item $registerMapping(\variableMapping, d, ca)$ registers the access expression $ca$ with the given variable declaration $d$ in the top-most context frame. Essentially, a context frame contains a mapping $m$ and the operation performs $m \assng m \addMap \mapEntry{d}{ca}$. + \item $getMapping(\variableMapping, d)$ returns the mapping for $d$. If no mapping was registered for the actual context frame, all context frames in stack order are considered. If no mapping is registered, the result is $\undef$. + \item $recordProcessed(\variableMapping, t)$ records a processed type with the closest containing context having processed type registration enabled. If \linebreak[4] $isCompound(t)$, this function registers $allRefined^+(t)$. + \item $alreadyProcessed(\variableMapping, t)$ returns whether $t$ was already registered as a processed type in one of the enclosing context frames. + \item $activate(\variableMapping, d)$ re-activates, i.e., pushes the registered stack frame for $d$ taken from the current context frame. As long as the current context frame exists, this operation can be called again and again. If no context frame is registered for $d$, the stack is not modified. + \item $deactivate(\variableMapping, d)$ de-activates the registered context frame for $d$, i.e., pops it from the stack but leaves it registered with its parent context frame so that it is available for further activations as long as the parent context frame exists on the stack. + \item $setTypeExcludes(\variableMapping, s)$ defines a set of types to be marked as excluded from constraint transformations. Excluding types is important for a fast processing of re-scheduled constraints in Section \ref{sectTopLevelConstraintsRescheduling}. + \item $transferTypeExcludes(\variableMapping, t)$ transfers excluded types into this context and stores the causing type $t$ in the current context. Transferring excluded types binds them to the actual (usual top-most) type and avoids applying them some nested type. + \item $currentType(\variableMapping)$ returns the type $t$ stored in the current context by $transferTypeExcludes(\variableMapping, t)$. The result is $\undef$ if no transfer happened for the current context. + \item $isTypeExcluded(\variableMapping, t)$ returns whether $t$ is excluded in the current context. $excludedTypes(\variableMapping)$ returns all excluded types for the current context or an empty set. + \item $size(\variableMapping)$ the number of contexts on the stack. There is always at least one context on the stack representing the enclosing project. + \item $clear(\variableMapping)$ clears the stack and cleans up the default context frame dedicated to the IVML project so that $\variableMapping$ is ready for the translation of the next IVML project. +\end{itemize} + +From a black-box perspective, $\variableMapping$ can be considered as a usual map as discussed in Section \ref{sectGeneralNotation}, but performing some stack-based lookup operations. Thus, we just use $\variableMapping$ in the variable substitution notation as introduced in Section \ref{sectNotationConstraints}, e.g., let $e$ be an expression, then $\varSubstitutionVarMapping{e}$ replaces all variables in $e$ having a mapping (through the $getMapping$ operation) in at least on context frame of $\variableMapping$. + +%For translating containers, context frames can store additional information. We will provide details along with the translation of containers in Section \ref{sectContainerDefaults}. + +\subsubsection{Scope Assignments}\label{sectScopeAssignments} + +Due to the potentially nested nature of IVML projects, the knowledge about when an assignment for a variable has been made cannot be maintained by a simple flat mapping. This requires a data structure, which stores information about assignments per project (scope). This structure is important to detect invalid variable re-assignments, i.e., to figure out whether a variable assigned more than once per scope~\cite{IVML-LS}. + +The scope assignments structure of the IVML reasoner (usually named $\scopeAssignments$ for assignments) provides the following operations: + +\begin{itemize} + \item $setAssignmentScope(\scopeAssignments, c)$ defines the scope of constraint $c$ as the actual assignment scope. Adding and checking assignments rely on the actual scope. Here, the scope of $c$ is the top-level parent of $c$, i.e., the containing project. + \item $addAssignment(\scopeAssignments, v)$ indicates that variable $v$ was changed through an assignment within the actual scope. + \item $wasAssigned(\scopeAssignments, v)$ returns whether variable $v$ was assigned in the actual scope. This operation is used to validate an assignment before it is performed out by the expression evaluator. + \item $clearAssignments()$ clears all assignments in all scopes. +\end{itemize} + +\subsection{Top-level Constraints Translation}\label{sectTopLevelConstraintsTranslation} + +The core idea of the constraint translation is to collect the constraints following the structure of an IVML model and to replace each type-related variable by the correct accessor expression for a global variable in the current scope. According to the IVML specification~\cite{IVML-LS}, the relevant top-level elements are variable declarations, global constraints, annotation assignment blocks and eval-blocks. Type definitions are considered when when processing variable declarations, as the individual type of a variable indicates the specific constraints to be collected and instantiated. + +Algorithm \ref{algTranslateConstraints} illustrates the top-level constraint translation. As a side effect, the constraint translation identifies and translates the constraints in the respective project\footnote{The top-translation steps in this algorithm are realized in the implementation by an IVML model visitor implicitly identifying and handling the types without iterating over the project multiple times as the notation here might suggest.}. To prioritize the constraints correctly, the reasoner uses four global sets, which are populated during the constraint translation and, finally, in Algorithm \ref{algTranslateConstraints} added to the constraint base. In more details, the reasoner maintains the following temporary constraint sets + +\begin{enumerate} + \item \emph{Default constraints $\defaultConstraints$} containing constraints setting the default values of all variables. In particular, this set can contain constraints that assign compound and container initializers, i.e., modify multiple values at once. + \item \emph{Deferred default constraints $\deferredDefaultConstraints$} containing default initialization constraints to be evaluated after all constraints in $\defaultConstraints$, but before the remaining two constraint sets below. $\deferredDefaultConstraints$ is required as setting individual variables may be accidentally overridden by compound and container initializers assigned through constraints in $\defaultConstraints$. + \item \emph{Top level constraints $\topLevelConstraints$}, i.e., constraints directly specified in a project, in top-level eval-blocks, in top-level assignment blocks as well as constraints attached to top-level variables, e.g., through derived types. These constraints originating from the top-level scope shall take precedence over constraints in nested scopes~\cite{IVML-LS}. + \item \emph{Remaining other constraints $\otherConstraints$} in particular in in nested structures, including compound types used in containers, nested assignment blocks or constraint variables. +\end{enumerate} + +\begin{algorithm}[H] + \SetAlgoLined + \KwIn{project $p$} + \KwData{configuration $cfg$, constraint $base$, constraint base copy $base_c$, constraint sets $\defaultConstraints,\deferredDefaultConstraints, \topLevelConstraints, \otherConstraints$, eval-blocks flag $inEvals$} + + \tcp{start of model visitor}%>ConstraintTranslationVisitor + \ForAll{$d \iterAssng decls(p)$}{ \label{algTranslateConstraintsTranslationStart} + $translateDeclaration(d, decision(cfg, d), \undef)$\; \label{algTranslateConstraintsTranslationDeclaration} + } + $add(\topLevelConstraints, constraints(p), true, \undef)$\; \label{algTranslateConstraintsAdd} \label{algTranslateConstraintsTopLevelConstraints} + \ForAll{$a \iterAssng assignments(p)$}{ + $add(\topLevelConstraints, constraints(a), true, \undef)$\; \label{algTranslateConstraintsTopLevelAnnotationConstraints} + $translateAnnotationAssignments(a, \undef, \undef, \undef)$\; \label{algTranslateConstraintsTopLevelAnnotationAssignments} + } \label{algTranslateConstraintsTranslationEnd} + $inEvals \assng true$\; + $add(\topLevelConstraints,\seqWith{constraints(e)}{e\in evals(p)}, true, \undef)$\;\label{algTranslateConstraintsTopLevelEvals} + $inEvals \assng false$\; + \tcp{end of model visitor}% 0 \wedge \neg hasTimeout \wedge \neg stop$} { \label{algEvalLoopLoopStart} + $c \assng pop(base)$\; \label{algEvalLoopPop} + $setAssignmentScope(\scopeAssignments, c)$\; \label{algEvalLoopSetScope} + %$\usedVariables \assng \emptySet$\; \label{algEvalLoopClear} + $setAssignmentState(e, \isDefaultConstraint{c})$\; \label{algEvalLoopAssngState} + $analyzeEvaluationResult(\problemRecords, evaluate(e, c))$\; \label{algEvalLoopAssngEval} + \If{$constraintFulfilled(e) \wedge \isDefaultConstraint{c}$}{\label{algEvalLoopClearStart} + $\relevantConstraintsPerDeclaration \assng \relevantConstraintsPerDeclaration \cap \setWith{\mapEntry{v}{c}}{v\in var(c)}$\; + }\label{algEvalLoopClearEnd} + $hasTimeout \assng checkForTimeout()$\; \label{algEvalLoopTimeout} + } \label{algEvalLoopLoopEnd} + \caption{Constraint evaluation loop (\IVML{evaluateConstraints}).}\label{algEvalLoop} +\end{algorithm} + +In each iteration of the main loop, the algorithm pops a constraint for evaluation from $base$ (line \ref{algEvalLoopPop}). % and clears the records about used variables (line \ref{algEvalLoopClear}). Recording used variables is required as detailed information for recording reasoning problems and later for creating the detailed reasoning report (last step of Algorithm \ref{algMainLoop}). +To assign values with the correct assignment state (cf. Section \ref{sectNotationConfigVars}), Algorithm \ref{algEvalLoop} registers the actual assignment state for the current constraint $c$ (line \ref{algEvalLoopAssngState}). If $c$ is a default constraint, all subsequent value assignments during the evaluation of $c$ happen with state \IVML{DEFAULT}, else state \IVML{DERIVED}. Next, constraint $c$ is evaluated (line \ref{algEvalLoopAssngEval}) by passing it to the constraint evaluator. %If configuration variables are changed as part of the constraint evaluation, the variables are recorded (not shown in Algorithm \ref{algVarChange}) and their constraints are re-scheduled for reasoning (cf. Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling}). +Then, the evaluation result is analyzed (still line \ref{algEvalLoopAssngEval}) and, if needed, problem records are created. We distinguish three cases: + +\begin{enumerate} + \item Constraint $c$ is evaluated successfully so that either no problem record is created or potentially existing problem records for $c$ from previously failed evaluations can be removed from $\problemRecords$. + \item Constraint $c$ is evaluated as undefined. As specified by IVML~\cite{IVML-LS}, a constraint is also considered undefined, if at least one involved variable or expression is evaluated as undefined. This does not lead to the creation of a problem record, as the constraint can either be ignored or will be re-scheduled if one of the (currently undefined) variables is changed through the evaluation of another constraint. + \item The constraint evaluation fails and a problem record for detailed error reporting or further (external) analysis is created. +\end{enumerate} + +Successfully evaluated default constraints must not stay in the constraint base as their initialization work has been done. As the evaluation of individual constraints cleans up the constraint base, we just have to avoid that they are accidentally re-scheduled. Therefore, we remove them from $\relevantConstraintsPerDeclaration$, the mapping between variable declarations and constraints in lines \ref{algEvalLoopClearStart}-\ref{algEvalLoopClearEnd}. Please note that no modification of $\relevantConstraintVariables$, the mapping between decision variables and constraints, is needed, as no change of constraint variables or their values occurred here. + +Finally, Algorithm \ref{algEvalLoop} checks for a potential timeout in line \ref{algEvalLoopTimeout} comparing the global $startTime$ set in Algorithm \ref{algMainLoop} with a configured reasoning timeout. If a timeout occurred (not further detailed in this document), the global $hasTimeout$ flag is set to $true$. This flag is also relevant for creating the overall reasoning report as explained for Algorithm \ref{algMainLoop}.