SPP Tool Chain
5.1 Input Interface model

There are three different basic terms: Space, Domain, and Property.

Spaces

By space we mean an AND-OR-LEAF tree of elements. This, from the constraint satisfaction tool's point of view means that the OR nodes are variables, and their possible values are their children. The type of the node it's controlled by it's decomposition (Boolean) attribute and the number of sub-elements(children) of a node in the following way:}

• If the number of children is = 0, then the type is LEAF
• If the number of child ren is > 0 and decomposition, then the type is AND
• If the number of children is > 0 and not decomposition, then the type is OR

Constraintsets are there just for the reason to provide a mechanism for grouping the Constraints in several categories, which are specific to application. Well, partially true: There is one special Constraintset, the one with name "Implicit Constraints". The Constraints in this constraint set are automatically applied and not shown on the DESERT user interface. The expression attribute is the constraint expression, in an extended OCL language. This will be discussed later in this document.

ElementRelations are permitted between the element to pass some extra information to the tool. These relations might be used when composing Properties.

DesertBase is an abstract base class; each class in the input interface model is directly or indirectly inherited from this class. The value of the id attribute should be unique for each UDM object passed to DESERT. The name attribute is used in the constraint expression; so, they should be unique as well at a certain level in the hierarchy. The externalID attribute may carry extra information throughout DESERT about the object, which is application specific. The values if these attributes are preserved through DESERT, so this is how the application can identify and match the objects when reading them back from DESERT.

DesertSystem is just a container for everything in the input model. This is needed because of the nature of the UDM, which require everything to be contained in a "RootObject".

Properties

As mentioned above, leaf nodes can have Properties. These Properties then can be used to express constraints. A property is owned by an element and always belongs to a domain. This is the set of members that can be assigned to properties as values. The property values can be composed in the AND-OR-LEAF tree, if the Property to be composed is defined for all the leaf nodes in the sub-tree rooted at the node at which the property should be evaluated.

The PCM_STR attribute specifies how a Property should be composed, when the constraint engine needs to evaluate it at an AND or an OR compound node. The possible values for this attribute are:

• PCM_ADD -specifies that the property is additive.
• PCM_MUL  - specifies that the property is multiplicative.
• PCM_AMED -specifies that the property value of the compound node is equal to the arithmetic median of the same property values of the children.
• PCM_GMED -specifies that the property value of the compound node is equal to the geometric median of the same property values of the children.
• PCM_MIN -specifies that the property value of the compound node is equal to the minimum of the same property values of the children.
• PCM_MAX -specifies that the property value of the compound node is equal to the maximum of the same property values of the children.
• PCM_NONE -specifies that the property is it not a composable property. Thus, forcing the constraint engine to evaluate it at a compound node by adding such a constraint at a compound node will generate an error.
• PCM_CUST - specifies that there will be a custom function linked against DESERT, which will compose this property whenever is needed. The CUSTName attribute will hold the name of the custom function.

There are two kinds of properties: Variable property and Constant property.

As one would easily guess, Variable Properties will be the variables of the constraint engine, thus, they may be assigned to more than one member. The assignments are done by the association class Assigned values, which are contained in elements. Each Assigned value object points to a member with it's values pointer and to a Variable property with it's properties pointer.

Constant properties are there to define Properties that are constant for a leaf node. Even if this is not used directly by the constraint engine, it's still needed when one needs to evaluate a property at a compound node, which implies that a certain property must be defined for each leaf node in the sub tree.

Again, everything is derived from the DesertBase abstract base class. One should pay extra attention to the id and externalID attributes of the Assigned values, because DESERT will return with set of Configurations which will contain a set of valid Assignments. In most of the cases the application will need to match the Assignment objects in the output data network with the Assigned Values objects in the input data network. This will be possible, since the Assignment object will preserve the ids of the Assigned values objects.

The abstract base class Property captures the common functionalities in Variable properties and Constant Properties, that these are contained in the owner Element, they operate on a Domain.

Domains

A domain is basically a set of values, which properties may be assigned to. There are two kinds of domains: Custom domains and Natural Domains.

The Custom Domain is again an AND-OR-LEAF tree and it has the same syntax as Space. However, the decomposition attribute is currently not used in the DESERT. The nodes of this tree are the Custom members, which act exactly the same way as elements in the space.

Member relations are there for the same reason element relations are there. One could use this information in a custom function when composing properties.

The Natural Domain is a set of natural numbers, which is defined by its attributes minimum and maximum. However, if one wants to actually assign a value from a natural domain, then o ne would need to create a natural member with that value in the natural domain.

The abstract base class member captures the common functionality of Custom members and Natural members. Members can be assigned as values to Properties.

The abstract base class Domain captures the common functionality of Custom domains and Natural domains that there are Properties assigned to them.

Next Up: 5.2 Output Interface model