Index: /reasoner/reasoner.tex =================================================================== --- /reasoner/reasoner.tex (revision 90) +++ /reasoner/reasoner.tex (revision 91) @@ -76,9 +76,9 @@ \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 to express the (meta-) model of a configuration as well as individual configuration instances. 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, allows 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 and interrelated with other variables through constraints. The constraint (expression) language is largely inspired by OCL concepts (and notation), 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 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 mechanism and executing that mechanism on the translated model. While traditional reasoners allow for completing the model through feasible ground instances, they typically also perform a kind of constrained state space evaluation. Considering the size of usual configuration models (currently the largest IVML model we are aware of has more than 16.000 variables), 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, these both kinds of approaches are limited as they typically do not directly support the breadth of OCL operations, in particular container iterators, quantifiers and user-defined constraint operations. In contrast, specific reasoning approaches, e.g., for OWL partially support quantification, but are similarly limited. Moreover, relying on OCL reasoning mechanisms could be a feasible approach, but would require significant extension to enable value propagation and IVML-specific operations. - -Due to these experiences, we decided to realize 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. The basis is \emph{forward-chaining}, i.e., evaluation of a given constraint set as long as no constraints are left over, while re-scheduling constraints attached to a variable if the variable changes during reasoning. It is important to notice that IVML \cite{IVML-LS} supports a declarative specification of constraints, i.e., they can be given regardless of their actual evaluation sequence. To ensure that values are uniquely determined, IVML allows changing the value of a constraint only once within a project scope, otherwise requiring that a reasoning mechanism issues an error. Thus, reasoning must happen project-wise, in a depth-first traversal along the project import dependencies. Moreover, to speed up reasoning in certain cases, some form of sequence of the constraints can be indicated through partial evaluations, i.e., eval-blocks within a project or a compound. An eval-block consists of constraints or nested eval-blocks. IVML \cite{IVML-LS} considers project as outermost (implicit) eval-scope, then eval-blocks are evaluated in their nesting sequence (whereby eval-blocks on the same nesting level do not imply any sequence). +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 to express the (meta-) model of a configuration as well as individual configuration instances. 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, allows 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 and interrelated with other variables through constraints. The constraint (expression) language is largely inspired by OCL concepts (and notation), 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 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 mechanism and executing that mechanism on the translated model. While traditional reasoners allow for completing the model through feasible ground instances, they typically also perform a kind of constrained state space evaluation. Considering the size of usual configuration models (currently the largest IVML model we are aware of has more than 16.000 variables), 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, these both kinds of approaches are limited as they typically do not directly support the breadth of OCL operations, in particular container iterators, quantifiers and user-defined constraint operations. In contrast, specific reasoning approaches, e.g., for OWL partially support quantification, but are similarly limited. Moreover, relying on OCL reasoning mechanisms could be a feasible approach, but would require significant extension to enable value propagation and IVML-specific operations. + +Due to these experiences, we decided to realize 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. The basis is \emph{forward-chaining}, i.e., evaluation of a given constraint set as long as no constraints are left over, while re-scheduling constraints attached to a variable if the variable changes during reasoning. It is important to notice that IVML~\cite{IVML-LS} supports a declarative specification of constraints, i.e., they can be given regardless of their actual evaluation sequence. To ensure that values are uniquely determined, IVML allows changing the value of a constraint only once within a project scope, otherwise requiring that a reasoning mechanism issues an error. Thus, reasoning must happen project-wise, in a depth-first traversal along the project import dependencies. Moreover, to speed up reasoning in certain cases, some form of sequence of the constraints can be indicated through partial evaluations, i.e., eval-blocks within a project or a compound. An eval-block consists of constraints or nested eval-blocks. IVML~\cite{IVML-LS} considers project as outermost (implicit) eval-scope, then eval-blocks are evaluated in their nesting sequence (whereby eval-blocks on the same nesting level do not imply any sequence). However, not all IVML constraints can be directly used for reasoning. This is in particular true for constraints defined directly on compound types, or indirectly, through types used within collections. Specifying IVML constraints on types, such as compounds, rather than variables (where applicable) simplifies the model (for a compound such constraints are automatically valid for all instances without explicit quantification), supports consistency and helps reduces the model size and complexity. Such constraints typically utilize local variables defined within the compound including the special pre-defined variable \IVML{self} pointing to the actual compound instance. 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). During reasoning, constraints over types cannot be evaluated, as the actual values are not available. Thus, we perform first a \emph{constraint translation step} to instantiate the constraints for configuration variables based on the actual type of the variable or its value. An alternative here could be reasoning over the type constraints and modifying the mapping on demand before evaluation. This could save memory and runtime (for constraint translation / creation), but, however, increases complexity in managing the actual constraints to be evaluated. So we opted for instantiating the constraints and keeping only the new, failed or recently affected ones in the constraint base. @@ -127,5 +127,5 @@ An IVML \emph{configuration variable} $v$ is an instance of a variable declaration $d$ as part of a certain configuration $cfg$, i.e., $decision(cfg, d)=v$. 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$, with $type(value(v))$ compliant with $type(v)$. Please note, that $type(value(v))$ can be a subtype of $type(v)$ (cf. \cite{IVML-LS} for details on the IVML type compliance rules and the IVML type hierarchy). +$value(v)$ denotes the actual value of $v$, with $type(value(v))$ compliant with $type(v)$. Please note, that $type(value(v))$ can be a subtype of $type(v)$ (cf.~\cite{IVML-LS} for details on the IVML type compliance rules and the IVML type hierarchy). As types like container or compound require a nesting of configuration variables, we generically define $nested(v)$ as the set of all variables nested in $v$ and $nested(v, n)$ the nested variable with name $n$ in $v$ ($nested(v, n)$ may be undefined). Of course, $nested(v)=\setEmpty$ if no nested variables are defined on $v$, $type(v)$ or $type(value(v))$. We define $parent(v)$ as the object $v$ is nested within, which is either the containing configuration if $v$ is a top-level variable or the parent variable, i.e., $\forall_{n\in nested(v)}:parent(n)=v$. For convenience, we also define @@ -305,5 +305,5 @@ No specific constraint translation is needed for \emph{basic types} (Boolean, Integer, Real String), the constraint type as well as for enums as IVML does not support modifying these types or does not allow attaching constraints directly to these types. Constraints can be attached indirectly through variable declarations / compound slots or derived types. The available functions for these types, such as adding two integer values, are subject to the creation of the IVML model, e.g., through a parser, and are, therefore, if specified, already part of constraint expressions before reasoning. -In IVML, a \emph{configuration reference} points to a variable defined in the same or another project (if made available through imports). 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. +In IVML, a \emph{configuration reference} points to a variable defined in the same or another project (if made available through imports). 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. \subsubsection{Values}\label{sectNotationValues} @@ -440,9 +440,9 @@ \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 initializer, 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 other usual constraints in $\topLevelConstraints$ and $\otherConstraints$. $\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, constraints in top-level eval-blocks and their derived type constraints. These constraints, in particular project constraints as (virtual) top-level eval-block and top-level eval-block constraints shall take precedence over nested constraints \cite{IVML-LS}. + \item \emph{Top level constraints $\topLevelConstraints$}, i.e., constraints directly specified in a project, constraints in top-level eval-blocks and their derived type constraints. These constraints, in particular project constraints as (virtual) top-level eval-block and top-level eval-block constraints shall take precedence over nested constraints~\cite{IVML-LS}. \item \emph{Remaining usual constraints $\otherConstraints$} in nested structures, including compound types used in containers, constraint variables, or annotation constraints. \end{enumerate} -These constraint sets are filled through the top-level calls in line \ref{algTranslateConstraintsTranslationStart}-\ref{algTranslateConstraintsTranslationEnd} including subsequent calls, prioritizing eval-blocks \cite{IVML-LS}. Please note that adding constraints to a constraint set (currently) requires filtering out unneeded constraints as well as indexing used variables. This is done by the $add$ function (e.g., in line \ref{algTranslateConstraintsAdd}), which we will detail below in Section \ref{sectTranslation}. This algorithm also takes into account the $inEval$ flag prioritizing eval-block contents. According to the priority of the constraint sets introduced above, Algorithm \ref{algTranslateConstraints} composes the constraint base (keeping remaining constraints from prior project evaluations of the same configuration) in line \ref{algTranslateConstraintsCompose}. Finally, Algorithm \ref{algTranslateConstraints} clears the temporary constraint sets in lines \ref{algTranslateConstraintsClearSetsStart}-\ref{algTranslateConstraintsClearSetsEnd} and copies the constraint $base$ in the first run of the incremental reasoning mode with re-used constraint base. +These constraint sets are filled through the top-level calls in line \ref{algTranslateConstraintsTranslationStart}-\ref{algTranslateConstraintsTranslationEnd} including subsequent calls, prioritizing eval-blocks~\cite{IVML-LS}. Please note that adding constraints to a constraint set (currently) requires filtering out unneeded constraints as well as indexing used variables. This is done by the $add$ function (e.g., in line \ref{algTranslateConstraintsAdd}), which we will detail below in Section \ref{sectTranslation}. This algorithm also takes into account the $inEval$ flag prioritizing eval-block contents. According to the priority of the constraint sets introduced above, Algorithm \ref{algTranslateConstraints} composes the constraint base (keeping remaining constraints from prior project evaluations of the same configuration) in line \ref{algTranslateConstraintsCompose}. Finally, Algorithm \ref{algTranslateConstraints} clears the temporary constraint sets in lines \ref{algTranslateConstraintsClearSetsStart}-\ref{algTranslateConstraintsClearSetsEnd} and copies the constraint $base$ in the first run of the incremental reasoning mode with re-used constraint base. Adding constraints or sets of constraints to the constraint base involves constraint filtering in order to respect the incremental reasoning mode as well as constraints that initialize compounds and containers through respective initializer expressions. This is done by a specific operation, which we will discuss in Section \ref{sectContainerBase}. During algorithm discussion, we ill just use the respective function $add(s, c, b)$, which adds constraint $c$ to constraint set $s$, considering compound and container initialization expressions if $b = true$. Compound and container initialization expressions are a specific and relevant case here, as they represent complex compound or container values containing (interrelating) expressions that can only be evaluated during reasoning in contrast to constant values, which are already resolved by the IVML parser (or by a simple configuration initialization mechanism). These expressions are particularly important to correctly consider constraints stemming from constraint variables. While most translation algorithms rely on default values or actual values (e.g., through the $relevantValue$ function defined in Section \ref{sectNotationValues}, compound and container initializers can only be obtained from assignment constraints, i.e., completed and instantiated constraints, which are only available when adding constraints to a constraint set or the constraint base. Thus, We will skip container and compound initializers in the translation algorithms, focus on actual or constant default values, and finally consider these specific cases in Section \ref{sectContainerBase}. @@ -638,5 +638,5 @@ \KwData{constraints $\otherConstraints$, variable mapping $\variableMapping$} - \uIf{$v\neq\undef$}{ + \uIf{$v\neq\undef$}{\label{algTranslateCompoundDeclarationTranslateSlotsStart} \ForAll{$s \iterAssng slots(v)$ } { $translateDeclaration(s, decision(v, s), \variableMapping[s]))$\; \label{algTranslateCompoundDeclarationTranslateSlotsV} @@ -646,5 +646,5 @@ $translateDeclaration(s, \undef, \variableMapping[s]))$\; \label{algTranslateCompoundDeclarationTranslateSlotsT} } - } + }\label{algTranslateCompoundDeclarationTranslateSlotsEnd} \If{$\neg inc$} { \ForAll{$a \iterAssng assignments(t)$}{ @@ -764,5 +764,5 @@ \subsection{Annotations}\label{sectAnnotationDefaults} -In IVML, annotations are orthogonal typed variables that can be attached to a variable. For all those ortogonal 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. +In IVML, annotations are orthogonal typed variables that can be attached to a variable. For all those ortogonal 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. 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. For all annotations of $v$ (as for $v$ here all inherited annotations are available), the algorithm creates the respective constraints through calling Algorithm \ref{algTranslateDeclaration}. Plase note that no specific variable accessors are handled for such top-level annotation assignments through a specific constraint syntax tree node, which is created through \IVMLMeta{acc()} in Algorithm \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateAnnotationAccess}. @@ -949,5 +949,5 @@ & IT1, IT2 \\ -Constraint type & 3.10.1 & \TBD{no specific constraints, cf. Section \ref{sectNotationOthers}, constraint value in \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationConstraintVariableConstraint}} & \TBD{tests} \\ +Constraint type & 3.10.1 & \tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationConstraintVariableConstraint}\tabAlgFollow\tabAlg{algCreateConstraintVariableConstraint} & Cs1, Cs2 \TBD{chg}\\ \hline @@ -958,5 +958,5 @@ \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}. +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 @@ -971,30 +971,27 @@ \hline -Integer type & 2.1.3.1 & \tabAlgLine{algTranslateCompoundDeclaration}{algTranslateCompoundDeclarationTranslateSlotsV}\tabAlgFollow -\tabAlg{algTranslateDeclaration} & ICo1, ICo2\\ - -Real type & 2.1.3.1 & \tabAlgLine{algTranslateCompoundDeclaration}{algTranslateCompoundDeclarationTranslateSlotsV}\tabAlgFollow -\tabAlg{algTranslateDeclaration} & RCo1, RCo2\\ - -Boolean type & 2.1.3.1 & \tabAlgLine{algTranslateCompoundDeclaration}{algTranslateCompoundDeclarationTranslateSlotsV}\tabAlgFollow -\tabAlg{algTranslateDeclaration} & BCo1, BCo2, BCo3 \\ - -String type & 2.1.3.1 & \tabAlgLine{algTranslateCompoundDeclaration}{algTranslateCompoundDeclarationTranslateSlotsV}\tabAlgFollow -\tabAlg{algTranslateDeclaration} & SCo1, SCo2\\ - -Enum type & 2.1.3.2 & \tabAlgLine{algTranslateCompoundDeclaration}{algTranslateCompoundDeclarationTranslateSlotsV}\tabAlgFollow -\tabAlg{algTranslateDeclaration} & ECo1, ECo2\\ - -Derived type & 2.1.3.4 & \tabAlgLine{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsV} or \tabAlgLine{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsT}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationDerivedDatatype}\tabAlgFollow\tabAlg{algTranslateDerivedDatatypeConstraints} & CnTCt1, CnTCt2 \\ - -Compound type & 2.1.3.5 & \TBD{Alg. \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationTranslateCompound} $\rightarrow$ Alg.\ref{algTranslateCompoundDeclaration}} & \TBD{tests} \\ - -Container type & 2.1.3.3 & \TBD{??} & \TBD{tests} \\ - -Reference type & 2.2.3.2 & \TBD{no specific constraints, cf. Section \ref{sectNotationOthers}} & \TBD{tests} \\ - -Constraint type & 3.10.1 & \TBD{no specific constraints, cf. Section \ref{sectNotationOthers}, constraint value in \ref{algTranslateDeclaration} line \ref{algTranslateDeclarationConstraintVariableConstraint} via compound access line \ref{algTranslateDeclarationTranslateInCompound}} & \TBD{tests} \\ - -Annotation & 2.2.2 & top-level see Table \ref{tab:completenessTopLevelTypes}, nested usage \tabAlgLine{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsV} or \tabAlgLine{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsT}\tabAlgFollow\tabAlg{algTranslateDeclaration} & \TBD{tests}\\ +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 \\ + +Compound type & 2.1.3.5 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateCompound}\tabAlgFollow\tabAlg{algTranslateCompoundDeclaration} $\ldots$ & \TBD{tests} \\ + +Container type & 2.1.3.3 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLine{algTranslateDeclaration}{algTranslateDeclarationTranslateContainer}\tabAlgFollow Table \ref{tab:completenessContainers} & \TBD{tests} \\ + +Reference type & 2.2.3.2 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & \TBD{tests} \\ + +Constraint type & 3.10.1 & \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlgLines{algTranslateDeclaration}{algTranslateDeclarationTranslateConstraintDefaultStart}{algTranslateDeclarationTranslateConstraintDefaultEnd} & CsCn1, CsCn2 \TBD{chg} \\ + +Constraints & & \tabAlgLines{algTranslateCompoundDeclaration}{algTranslateCompoundDeclarationAllStart}{algTranslateCompoundDeclarationAllEnd}&\TBD{tests}\\ + +Annotation & 2.2.2 & top-level see Table \ref{tab:completenessTopLevelTypes}, nested usage \tabAlgLines{algTranslateCompoundContent}{algTranslateCompoundDeclarationTranslateSlotsStart}{algTranslateCompoundDeclarationTranslateSlotsEnd}\tabAlgFollow\tabAlg{algTranslateDeclaration} $\ldots$ & \TBD{tests}\\ Assignment blocks & 2.2.2 & \tabAlgLine{algTranslateCompoundContent}{algTranslateCompoundDeclarationCompoundAssignments}\tabAlgFollow\tabAlg{algTranslateAnnotationAssignments} & \TBD{tests} \\ @@ -1044,5 +1041,5 @@ Reference type & 2.2.3.2 & no specific constraints, cf. Section \ref{sectNotationOthers} & \TBD{tests} \\ -Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers} \TBD{constraint value} & \TBD{tests} \\ +Constraint type & 3.10.1 & no specific constraints, cf. Section \ref{sectNotationOthers} \TBD{constraint value} & \TBD{tests}\\ Constraint Container& \TBD{??} & \TBD{??} & \TBD{CnCt1, CnCt2} \\ @@ -1175,7 +1172,7 @@ B & Boolean \\ -Co & Compound \\ -Cr & Container\\ -Cn & Constraint\\ +Cn & Compound \\ +Ct & Container\\ +Cs & Constraint\\ A & Annotation, AssignmentBlock\\ Ev & Eval\\ @@ -1265,4 +1262,8 @@ A2 & \class{attributes/IndividualAssign.ivml}\\ A3 & \class{attributes/IndividualAssignNested.ivml}\\ +Cs1 & \class{constraintVariables/constraintAssigned.ivml}\\ +Cs2 & \class{constraintVariables/constraintDefault.ivml}\\ +CsCn1 & \class{constraintVariables/constraintCompoundAssigned.ivml}\\ +CsCn2 & \class{constraintVariables/constraintCompoundDefault.ivml}\\ Ev1 & \class{evals/SimpleEval.ivml}\\ Ev2 & \class{evals/NestedEval.ivml}\\