Control Link Technical Guide
Section 3 - <CONTROL LINK> INSTANCES AND <EXPRESSION> INSTANCES

3.1 Overview

The basic idea of control links is that the abstract class <Control Link> provides a connection between <Expression> trees and the fields of other SEDRIS objects, called target objects. For each class of target object, there shall be a matching, specialized subclass of <Control Link>, the definition of which specifies how it's ordered <Expression> components are used to determine the values of the fields of the target object (called target fields). The target object shall aggregate an instance of the specialized <Control Link>.

In general, a specialized <Control Link> will contain at least one field, called a link field, for each field in the target object. The link field is a 1-based index into the ordered list of <Expression> components, and is used to select the specific <Expression> that controls the value of the target field. The specialization may also contain "constraint" fields that are used to constrain the values of the target field. These constraint fields are indexes into the ordered list of <Expression> components.

<Expression> is an abstract class used to represent places in a transmittal where the consuming system is required to perform an evaluation in order to get the exact value of a target field. An <Expression> tree is composed of other <Expression> trees, nesting to an arbitrary level. Together, the set of <Expression> trees connected to a <Control Link> defines the desired relationship and behaviour of controlling inputs to values, which will be applied to the fields of other SEDRIS objects (called target objects and target fields). The application of <Expression> instances to target fields is defined by a specialization of the <Control Link> class, which associates the values of the <Expression> instances to the fields of the target object(s).

For example, the <State Related Geometry> class has an optional relationship with the <State Control Link> subclass of <Control Link>. This specialization defines which of the <State Control Link>'s ordered <Expression> components are to be applied to the fields of the <State Related Geometry>.

There are 3 subclasses of <Expression>: <Literal>, <Variable>, and <Function>.

 
3.2 The <Literal> and <Variable> Classes

A <Literal> is the simplest <Expression>; it is merely a constant value.

A <Variable> is a surrogate for a value that will be supplied by way of an <Interface Template>. <Interface Template> instances, which are aggregated by <Environment Root> and <Model> instances, specify the "hooks" that may be controlled within the parent <Environment Root> or <Model> by the consuming system. An <Interface Template> instance is associated with one or more <Variable> instances. <Geometry Model Instance> and <Feature Model Instance> aggregate <Expression> components, indicating their relationship with the appropriate <Interface Template> (that of the <Model> being instanced).

Essentially, a <Variable> exists to connect an <Interface Template> to points within <Expression> where outside control may be exerted.

For a <Variable> contained within a <Model>, evaluation is valid only for a specific model instance. The value is determined by an <Expression> aggregated by the specific <Feature Model Instance> or <Geometry Model Instance>.

For <Variable> instances contained within an <Environment Root>, evaluation can only be performed within the context of values that shall be supplied by the consuming system.

When the general constraints <<Constraints On Components>> and <<Constraints On Associates>>, some practical consequences arise. Since a <Variable> must be associated by an <Interface Template> to be syntactically valid, and a <Variable> within a <Model> cannot be associated by any <Interface Template> outside that <Model>'s composition tree, it follows that any <Model> containing <Variable> instances must have an <Interface Template> component. Further, a <Model>'s <Interface Template> associates to the <Variable> instances - and only the <Variable> instances - of that particular <Model>. This combination of constraints guarantees that when a model is instanced, the end application can determine for that instance what <Variable> instances must be supplied with values to fully specify the model instance, and that the control system specified by the model's internal <Control Link> instances affects that <Model>, without side effects on unrelated <Model>s.

Another consequence of these constraints is that a <Variable> instance cannot belong to the component tree of more than one <Model>. This is only logical - the rotation of an airplane propeller and that of a ceiling fan are both rotational quantities, but they are not driven by the same control system.

A <Variable> instance cannot be a component of both a <Model> and an <Environment Root>. A <Variable> within a <Model> specifies a controlling variable for that one construct, while an environmental variable expresses a more 'global' quantity, such as prevailing wind direction or air temperature.

Since a <Control Link> always (in practice) uses an <Expression> containing a <Variable>, <Control Link> instances only appear within the context of <Model> and <Environment Root> component trees.

The <Interface Template> component of a <Model> has ordered associations to every <Variable> within that <Model>. This ensures that the end user does not have to search the entire <Model> to find all the <Variable> instances. The mechanism can be described by a lock-and-key analogy. An <Interface Template> defines the 'lock' - all the <Variable> instances that must be supplied with values when the <Model> is instanced in a playbox. Each model instance must supply its own 'key' - a set of <Expression> instances to be plugged into that set of &<Variable>s.

In practice, every <Control Link>; instance either has a <Variable> as its controlling <Expression>, or a <Function> that is in turn controlled by a <Variable>. If the <Control Link> value could never change state, then the target fields' values would be fixed, and there would be no need for a controlling <Expression> to be present.

 
3.3 The <Function> Class
3.3.1 Overview

<Function> instances are used as <Expression>s for which the value is determined by evaluating arguments and passing them through some function. A <Function> aggregates its arguments as a set of ordered <Expression> components, where the exact interpretation of each argument is defined by the specific function. The arguments, together with the definition of the function, determine the value "returned" by the <Function>. The abstract class <Function> has 2 concrete subclasses: <Predefined Function> and <Pseudo-Code Function>.

 
3.3.2 The <Predefined Function> Class

The <Predefined Function> class specifies the function from the SE_Predefined_Function enumeration. These functions fall into various categories.

  • Mathematical Constants.

    An example of this category is SE_PREDEFFN_PI.

  • Unary Mathematical Functions

    These functions take a single argument. Examples of these include such trigonometric functions as sine and cosine.

  • Unary Logical Functions

    These functions take a single argument. An example of this is the NOT function.

  • Binary Mathematical Functions

    These functions take two arguments. Examples of these include such arithmetic functions as ADDITION and SUBTRACTION.

  • Binary Logical Functions

    These functions take two arguments. Examples of these include such functions as AND and OR.

  • Other

    A variety of other useful functions are provided, although not all are currently capable of static evaluation by the SEDRIS API at this time. Some are applicable only at run-time; see SE_Predefined_Function for specifics.

The number and type of arguments required for a <Predefined Function> therefore depends upon the function. The arguments of a <Predefined Function> are specified by attaching them as component <Expression> instances to the <Predefined Function> itself. The components of a <Predefined Function> are always its arguments, and are ordered so that the assignment of each to its specific corresponding argument is unambiguous. A corollary is that functions that require no arguments have no components, and a further corollary is that the number of <Expression> components should not exceed the number of arguments for the given function.

 
3.3.3 The <Pseudo-Code Function> Class

<Pseudo-Code Function> is used to represent functions that are too complex to use <Expression> trees, or that require looping, branching, or other complex operations. These instances contain fields that describe the desired behaviour in human-readable form.

<Pseudo-Code Function> is supported for 3 reasons. First, it is nearly impossible to capture every possible function that could be used to defined the behaviour of control-linked objects. Second, <Expression> instances cannot define functions that require looping, branching, and so on. Finally, given the first two points, it is recognized that many functions, while relatively simple when viewed as pseudo-code or code fragments, would become overly complicated if converted to <Expression> trees.

The reader is asked to keep in mind that while any valid <Expression> can be converted into executable code or structures that can be directly used by a consuming system, most systems will not use them that way. Currently, most consuming systems require that an <Expression> be re-coded into the consuming functions. For complex functions, pseudo-code may be easier to convert.


Return to:Top of this Page, Table of Contents

Last updated: July 26, 2006 Copyright © 2006 SEDRIS