Pseudo Code Function

The SEDRIS Data Representation Model APPENDIX A - Classes Pseudo Code Function

Class Name: Pseudo Code Function

Superclass - <Function>

Subclasses

This DRM class is concrete and has no subclasses.

Definition

An instance of this DRM class specifies the behaviour of a function that does not correspond to an entry of SE_Predefined_Function.

Primary Page in DRM Diagram:

Secondary Pages in DRM Diagram:

This class appears on only one page of the DRM class diagram.

Example

Consider a <Translation> instance representing the current position of a lift cage in a lift shaft. Since the translation_amount varies, the <Translation> instance has a <Translation Control Link> component with a <Pseudo Code Function> component specifying the translation_amount. The name field of the <Pseudo Code Function> component is set to {SE_LOCALE_DEFAULT, 26, "lift cage control function"} and the pseudo_code field content is "Let B be the <Variable> component representing the button that summons the lift cage. If B is on and the lift cage is present, open the door. If B is on and the lift cage is not present, translate the lift cage into position at a speed of one metre per second and open the door when the lift cage is in position."

FAQs

Why is <Pseudo Code Function> needed? Doesn't this leave room for ambiguity?: The decision to support <Pseudo Code Function> was based on three primary concerns. First, we felt that it would be nearly impossible to capture every possible function that would be used to define the behaviour of <Control Link> instances. Second, <Expression> instances lack the expressive power to define functions that require looping, branching, etc. Finally, given the first two, it is recognized that many functions that are relatively simple when viewed as pseudo code or code fragments, would become overly complicated when converted into an expression tree. It is important to keep in mind, that while any valid <Expression> instances could be converted into executable code or structures that could be directly used by a consuming system, most systems will not use them that way. Currently, the majority of consuming systems would require that the expression be recoded into the consuming system. For complex functions, pseudo code may be easier to convert.

Constraints

Composed of (two-way) (inherited)

zero or more {ordered} <Expression> instances¹

Component of (two-way) (inherited)

zero or more <Control Link> instances
zero or more <Feature Model Instance> instances, each through the use of a <Model Instance Template Indices> link object
zero or more <Function> instances
zero or more <Geometry Model Instance> instances, each through the use of a <Model Instance Template Indices> link object

Inherited Field Elements

EDCS_Attribute_Value_Type	value_type;	²

Field Elements

SE_String	name;	³
SE_String	pseudo_code;	⁴

Notes

Composed of Notes

The <Expression> components of a <Function> instance, if any, represent the arguments of the function being represented, so a <Function> instance has <Expression> components if that <Function> instance takes arguments. The <Expression> components are ordered so as to unambiguously specify which <Expression> component is being supplied for each argument of the <Function> instance. The exact interpretation of each argument is defined by the specific function.

Last updated: July 26, 2006