6.3 MODEL STATICS
Let us for the moment reconsider the representational requirements of the elements in L' and L''. For purposes of authoring, the definition of the language was approached as a constraining of a universal space. For purposes of evaluation, the language definition can better be posed as a construction along different dimensional lines. This approach has considerable ramifications for computational processing.
At this point, the morphological space has been defined as consisting of links and objects, while the syntactical space encompasses the valid connections of these objects. For evaluation, the elements of the morphological level, links and objects, can be discerned as separate points in the same morphological dimension. Set processing, characteristic of 4GLs operate best on such, where all elements equally available for list processing.
The syntactic space, with connections between objects and links, increases the morphology dimensionality by one. Computation analysis within this syntactic space depends on an exploration of the connectedness as well as the values of objects and links. This type of processing is best modeled with such imperative languages as C and Pascal.
To provide for the data requirements of declarative 4GLs, within both Onedim and parts of the DFM system, all data is stored in and/or retrieved from a single list of tuples of the form:
<object, property, value>
Each element of the entire modeling system is stored in the format of the tuple, with each object unique within the system. The major elements of an object are its name, type, nodes, and links. Given these basics, it is possible to construct any of the models of Figure 74. The model of Figure 74 can be built from the following list of data tuples, called the "Onedim_List" here:
{{flange001 name Flange} {flange001 type Complex_Features} {flange001 node rib_A} {flange001 node rib_B} {flange001 node base_A}
{rib001 name rib_A} {rib001 type Rib} {rib001 node rib001_height} {rib001 node rib001_width} {rib001 node rib001_draft} {rib001 node rib001_thick}{rib001 open format}
{rib002 name rib_A} {rib002 type Rib} {rib002 node rib002_height} {rib002 node rib002_width} {rib002 node rib002_draft} {rib002 node rib002_thick}{rib001 open format}
{base001 name base_A} {base001 type Base}
{rib001_width name width} {rib001_width type Real} {rib001_width node 1.00}
{rib001_height name width} {rib001_height type Real} {rib001_height node 1.00}
{rib001_draft name width} {rib001_draft type Real} {rib001_draft node 1.00}
{rib002_width name width} {rib002_width type Real} {rib002_width node 1.00}
{rib002_height name width} {rib002_height type Real} {rib002_height node 1.00}
{rib002_draft name width} {rib002_draft type Real} {rib002_draft node 1.00}}
In practice, the object identification that holds the first position in the tuple, takes on the value of the name. However, the object identifiers are meant to be unique within the system and the notation is therefore different for illustration here.
Only two routines are required to retrieve and query the data list: db_select_all and db_where. Both are styled after SQL.
The routine db_select_all opens a data file and reads its contents, creating a data tuple list. The parameters for routine db_select_all are as follow:
db_select_all datafile [format] [object] [property]
datafile: unix ascii file name
format: table or list option
object: object name
property: property name
If all parameters are filled, all records match the object and property are returned. If property is left blank, then all the records for the object are returned. If the object parameter is left blank, the entire data file is returned as the data tuple list. The format option allows specification for a table format (specifically the data base table format used by Nexpert Object) or the list format (the spreadsheet format).
The routine db_where allows queries on the data tuple list. Its arguments are as follow:
db_where list [property] [value]
list: data tuple list
property: tuple property name
value: tuple value
Given a value, all objects with a tuple matching the value of the property are returned. Given a property with no value, just the tuple with that property is returned. If there are no parameters after the list, just the values in the list (the third item in the tuples) are returned.
To retrieve a list of tuples of the object with the name rib_A, given a data tuple list "Onedim_List", the following statement:
db_where $Onedim_List name rib_A
will return the following is a list of the tuples concerning the elements of rib_A.
{{rib001 name rib_A} {rib001 type Rib} {rib001 node rib001_height} {rib001 node rib001_width} {rib001 node rib001_draft} {rib001 node rib001_thick}{rib001 open format}}
The tuple list above indicates object rib001 is named "rib_A", is of type "Rib", and contains three node objects: rib001_height, rib001_width, and rib001_draft. Additionally, the final tuple indicates that when the rib object is opened, it is to open as a form. This will be discussed later.
Each node property for rib_A holds the name of another unique object. The node objects of rib_A have entire tuple sets of their own. For example, one of the nodes is rib001_height. A list of tuples concerning the elements of rib001_height is as follows:
{{rib001_height name height} {rib001_height type Real} {rib001_height node 2.4}}
The tuple list above indicates the object named "height" is of type "Real" and contains the value of 2.4. The type is important to include because it dictates how the node or nodes are used and presented. The node in this case is not another object model, but rather an actual numeric value, although the retrieval mechanism is the same for both.
Onedim has demonstrated that this data representation coupled with rudimentary, 4GL list parsing routines for data retrieval is sufficient to describe a complex modeling system.