Developing a Superset Language of Smalltalk for Modeling Mechanical Systems -- ADTmag

Developing a Superset Language of Smalltalk for Modeling Mechanical Systems

By Deyi Xue
July 13, 2001

This article presents an experience of developing a superset language of Smalltalk for modeling mechanical systems. Limitations of current OO programming languages and requirements for the new language in modeling mechanical systems are discussed first. Development of this new language, which is a superset of Smalltalk, is then introduced. Implementation of this new language is subsequently explained. Lastly, a mechanical system modeled using this developed language is given to show the effectiveness of this language.

With the advances of computer technology, many engineering design and manufacturing activities have been modeled by developing computer-based systems such as Computer-Aided Design (CAD) and Computer-Aided Manufacturing (CAM).¹ Presently, these computer-based mechanical design and manufacturing systems are primarily used for modeling 3D geometry-related information. Because geometry is only part of the whole product information, more advanced mechanical modeling systems must be developed.

The recent development of OO programming languages provides tools for modeling mechanical systems with a wider variety of information.² Due to its special characteristics compared with other types of programming languages, the OO programming approach has been used for modeling mechanical systems. Abstraction classifies objects into two levels, class level and instance level, corresponding to generic product library and special product data respectively. Encapsulation prevents the internal data of an object from being accessed by other objects directly to improve system modularity. Inheritance allows a subclass to acquire all the properties defined in its superclass. Polymorphism makes it possible for different objects to react in different ways after receiving the same message.

Despite these advantages, the present OO programming languages are primarily used for modeling two aspects of objects: data, and functions to access these data. Because mechanical systems are too sophisticated to be modeled by only data and functions, new languages with more powerful modeling capabilities should be developed.

The objective of this research is to develop a language that is a superset of Smalltalk,^3,4 an OO programming language, for modeling mechanical systems. The data and functions of Smalltalk objects can be modeled by this language. In addition, qualitative relations, quantitative relations, etc., can also be modeled. The capability of present computer-based product modeling systems can be improved by developing this language, and it can also conduct various product modeling activities, such as describing design candidates for conceptual design and maintaining the consistency of a product database.

REQUIREMENTS FOR MODELING MECHANICAL SYSTEMS
The requirements for modeling mechanical systems were achieved by extensive study of the activities of mechanical engineering design and manufacturing. The requirements are summarized as follows:

A mechanical system is composed of primitives, including mechanisms and components such as a gear-pair and a shaft. Each type of primitive has its own properties and behaviors. By using these primitives as building blocks, efficiency of mechanical system modeling can be improved considerably.
The mechanical primitives should be described at two different levels, class level and instance level, corresponding to standard library and actual data respectively. Class primitives serve as templates for generating instance primitives. Change of instance primitives doesn't influence the class primitive definitions. For instance, the concept of gear is a class primitive, while the two gears in an actual mechanical system are instance primitives.
The class primitives should be organized in a hierarchical data structure. All the properties and behaviors defined in a superclass primitive should be inherited by its subclass primitives. For instance, the gear class primitive can be modeled by its tooth number, module, diameter, and their relations. These descriptions should be inherited by its subclass primitives such as spur-gear and worm-gear.
A mechanical primitive can be composed of other primitives. For instance, a gear-pair mechanism is composed of gears, keys, shafts, etc. Using this data structure, a complex mechanical system can be represented by a hierarchical data structure of primitives.
A primitive has a number of attributes. Each attribute is associated with a value. For instance, tooth number, module, diameter, and material type are attributes of a gear.
The relations among primitives, for instance, the connection relation between two gears in a gear-pair mechanism are declarative relations. These declarative descriptions provide a good data structure for knowledge-based reasoning.
The relations among attributes are used to keep the consistency of these attributes. Each relation has a number of input attributes and one output attribute. For instance, the relation to calculate the diameter attribute of a gear by multiplying the attributes of its module and tooth number is such a relation.
Each primitive should also provide functions to accomplish complicated calculation tasks. These functions are the same as those used in the conventional programming languages.
Each mechanical primitive should also be able to describe its geometric information. The geometry of a primitive is represented by its shape and position (location and orientation).

Requirements 1–3 and 8 can be implemented by OO programming directly. To satisfy the rest of the requirements, new languages have to be developed. In this research, a new language called Feature-based Product Modeling Language (FPML), which is a superset of Smalltalk, has been developed and implemented. In this system, the mechanical primitives are modeled by features. The concept of feature was originally used as a primitive for modeling the component geometry to be produced by a certain manufacturing process.⁵ In my previous research, the concept of feature was extended to the primitives to model design, geometry, and manufacturing database.^6,7 The mechanical system modeling environment developed based upon FPML is called Feature-based Product Modeling System (FPMS).

SMALLTALK
Smalltalk is one of the pioneer OO programming languages.³ It was originally developed at Xerox Palo Alto Research Center (PARC). Its first commercial version, Smalltalk-80, was the first language to introduce windows programming. Many concepts of this language have been adopted by subsequent OO programming languages such as C++ and Java. Its latest version, called VisualWorks, has been used for implementing FPML and FPMS.

Each component of Smalltalk, including language compiler, debugger, interface elements, and data structure library, is described by objects, including classes and instances. A snapshot of Smalltalk is given in Figure 1.

The classes of Smalltalk are defined using System Browser. The latest version of Smalltalk, VisualWorks, provides over 900 classes that are organized in a hierarchical data structure. The top class is called Object. A new class is created using an existing class as its superclass. An example class definition is given in Listing 1. A class has two types of variables: class variables and instance variables. A class variable is shared by all the instances generated from the class, while an instance variable is specific to a particular instance. The functions of Smalltalk, called methods, are also classified into two types, class methods and instance methods, executed by classes and instances respectively. The classes are grouped in categories due to their large number.

Execution of a Smalltalk program is conducted by evaluating Smalltalk expressions. For instance, Listing 2 shows a piece of a program to calculate the volume of a cylinder using the methods defined in Listing 1.

Smalltalk also provides excellent debugging tools to improve programming efficiency. If an error is detected during the execution of the Smalltalk program, a debugging window, as shown in Figure 1, is created to list all the methods executed so far and variable values for these methods. The user can modify the methods using this debugging window and resume the execution from a modified method without starting the execution from the very beginning.

The weakness of Smalltalk is its slow computation speed and large memory requirements. Due to its large class library and excellent programming environment, Smalltalk is often used for developing prototype software systems.

FEATURE-BASED PRODUCT MODELING SYSTEM
In this research, a superset of Smalltalk, FPML, has been developed for modeling mechanical systems. FPMS was developed using FPML as the core language.

Interface environment
Many windows have been developed for modeling the components of FPML, as shown in Figure 2. In FPML, the mechanical primitives are described by features. Features are represented at two different levels, class level and instance level, corresponding to standard libraries and actual product data respectively. Instance features are generated using class features as the templates. Class features and instance features are modeled using Class Feature Browser and Instance Feature Browser respectively, as shown in Figure 2. In addition, a 2-D Geometry Browser has also been developed for displaying the geometric information preserved in instance features.

Class features
A class feature is defined using an existing class feature as its superclass. Each class feature has a number of instance variables and class variables. The definition of a class feature Gear is shown as follows:


<Feature> subclass: <Gear>
instanceVariableNames: <density strength>
classVariableNames: <Pi>
category: <Mechanical-Application>

Class features are organized in categories. Each class feature is defined by different types of feature elements. A class feature is created using Class Feature Browser, as shown in Figure 2. The four top views of this browser are used to show category names, class feature names, feature element types, and feature element names respectively. The bottom text view is used to define the class feature and its elements.

A class feature is defined by the following types of feature elements:

Element features: An element feature is a feature that composes the feature currently being defined. In a class feature, an element feature is defined by a variable and its class feature type. A variable is a string starting with ?. For instance, the two gears in the class feature GearPair are defined by:
```
?gear1
  Gear

?gear2
  Gear
```
The variables can be used in other parts of the class feature definitions.
Attributes: An attribute is defined by a pair comprised of attribute name and attribute value. Example attributes for class feature Gear are:
```
toothNumber
  30

material
  wood
```
Attributes are used in other parts of feature definitions in the form of attribute[feature], such as toothNumber[?gear1] and material[?gear2].
Feature relations: Relations among features are described by predicates in the form of (p1, p2, ..., pn). For example, the relations among the two gears and the two shafts in the class feature GearPair are defined by:
```
(pair, ?gear1, ?gear2)
(connect, ?gear1, ?shaft1)
(connect, ?gear2, ?shaft2)
```
Attribute relations: A relation among attributes is defined by a function with a number of input attributes and one output attribute. Example attribute relations defined in the class feature GearPair are:
```
i[?self]
  := n[?gear1]/n[?gear2]

d[?gear1]
  := ?gear1 diameterWithM: m[?gear2] z: 30
```
The variable ?self is used to represent the feature currently being defined. The message diameterWithM:z: is an instance method of class feature Gear.
Class methods: A class method in a class feature is the same as a class method defined in a Smalltalk class.
Instance methods: An instance method of a class feature is the same as an instance method defined in a Smalltalk class. In addition, element feature variables and attributes are allowed in the instance method definitions. An example instance method to calculate the weight of a cylinder is defined as:
```
getWeight
| weight density volume |
material[?self] == #wood
  ifTrue: [density := woodDensity].
material[?self] == #aluminum
  ifTrue: [density := aluminumDensity].
volume := Pi * r[?self] * r[?self] *       
          height[?self].
weight := density * volume.
^weight
```
In this instance method, ?self is a feature variable; material, r, and height are attributes; woodDensity and aluminumDensity are instance variables; Pi is a class variable; and weight, density, and volume are temporary variables.
Feature geometry: The geometry of a class feature is defined by a special instance method called drawingOn:from:. Two types of geometric descriptions are preserved in a feature: (1) shape and (2) position (location and orientation).

Hierarchy of class features
Class features are organized in a hierarchical data structure, as shown in Figure 3. Each property defined in a superclass feature is inherited by its subclass features automatically. The top-class feature is a built-in class feature called Feature. For instance, the attributes defined in class feature Gear are automatically inherited by its subclass features SpurGear and WormGear.

Generation of instance features
Instance features are generated using class features as their templates for modeling actual mechanical systems. When a class feature is selected for generating an instance feature, each description in the class feature and its superclass features is inherited to this new instance feature automatically. In addition, the element features should also be generated according to the class types defined in the class feature. A spur-gear-pair mechanism, generated using the class features defined in Figure 3, is shown in Figure 4. In this example, two element feature variables in SpurGearPair are replaced by instance features g1 and g2 respectively. The instance feature spurGearPair1 inherits all the descriptions defined in class feature SpurGearPair and its superclass feature GearPair. The instance features g1 and g2 inherit all the descriptions defined in class feature SpurGear and its superclass feature Gear.

The descriptions of the generated instance features can be modified, added, and deleted to reflect the actual mechanical system. The instance feature database can be manipulated by developing special modules. Presently, two modules have been implemented to access the instance feature database. The two modules are:

Product geometry display module: This module uses the geometric information, including shapes and positions, preserved in instance features to show the geometry of the created mechanical system using an interface environment called 2-D Geometry Browser, as shown in Figure 2.
Attribute relation maintenance module: This module uses the attribute relations to keep the consistency of the database. When the value of an attribute is changed, the relevant attributes should be updated using the attribute relations.

SYSTEM IMPLEMENTATION
The compiler of FPML, the superset of Smalltalk, was implemented using the latest version of Smalltalk: VisualWorks. FPMS was also implemented using VisualWorks.

Implementation of classes
Class features are translated into Smalltalk classes, as shown in Figure 5. The Feature is a built-in class feature that cannot be modified by the users. Each common property of a class feature is defined in the corresponding Smalltalk class called FPMLFeature. Because each class feature has a corresponding Smalltalk class, each Smalltalk description, including instance variables, class variables, instance methods, and class methods, can be described in a class feature. Therefore, FPML is a superset of Smalltalk.

A special Smalltalk class, ClassFeature, has been developed to preserve the class feature definitions, including class name, superclass name, instance variables, class variables, category, element features, attributes, feature relations, attribute relations, class methods, instance methods, and feature geometry, using its instance variables. Each class feature is associated with an instance of ClassFeature to preserve its descriptions. Class feature definitions are preserved in a Smalltalk global variable called ClassFeatureDictionary, as shown in Figure 6.

One characteristic of this superset of Smalltalk language is that the element feature variables and attributes can be used to define instance methods. This characteristic was implemented by developing a compiler to translate the instance methods of class features into the instance methods of Smalltalk classes. The compiler reads the instance method and changes the expressions related to element feature variables and attributes into Smalltalk programs. Examples of this translation are shown in Table 1. Because two instance methods, getElementFeature: and getAttribute:fromElementFeature:, were implemented in the Smalltalk class FPMLFeature, these two methods can be executed by any instance features.

Table 1. Examples of instance method translation.
Items	FPML	Smalltalk
Element Feature	?X	(self getElementFeature: '?X')
Attribute	m[?Y]	(self getAttribute: 'm' fromElementFeature: '?Y')

Implementation of instance features
An instance feature is generated using a class feature as its template and is described by a Smalltalk instance, which is generated using a Smalltalk class corresponding to the class feature. For instance, if a class feature Gear is selected to generate an instance feature, the instance feature is a Smalltalk instance generated using the Smalltalk class FPMLGear.

Many instance variables are defined in the Smalltalk class FPMLFeature to preserve the instance feature descriptions, including instance feature name, class feature name, element features, attributes, feature relations, attribute relations, and feature geometry. Because each feature is translated as a subclass of FPMLFeature in Smalltalk, these instance variables can be used by the instances of the corresponding classes.

All the descriptions in the selected class feature and its superclass features are inherited by the generated instance feature. This inheritance mechanism was implemented by searching the descriptions of class features from the selected class feature up to the class feature Feature. When a piece of class feature description (such as an element feature or an attribute) is accessed, this mechanism checks whether this description has already been copied to the instance feature. If the answer is no, this description is then copied to the instance feature. Otherwise, no action is conducted. When all the descriptions of a class feature have been accessed, the search goes to its superclass feature. This process is carried out continuously until the class feature Feature has been accessed.

Because the class feature at a lower level is accessed prior to its superclass features, the description at a lower level has priority to be copied to the instance feature. For example, if two different descriptions with the same name (such as two different functions to calculate the same attribute) are defined in a class feature and its superclass feature, only the description in the subclass feature is copied to the instance feature.

The instance features are preserved in a Smalltalk global variable called InstanceFeatureDictionary, as shown in Figure 7. Instance features are organized by categories. Each category usually represents one product that is composed of several instance features.

Implementation of modules to access instance feature database
Presently, two modules have been developed to manipulate the instance feature database:

Geometry display module: The geometric information of an instance feature is described by its shape and position. In a 2D world, the position is described by three parameters: the x and y coordinates, and orientation θ. For instance, the shape of a pulley is described by a rectangle or a circle. The shape of an instance feature is determined by its attribute values, while the position of the instance feature is determined using the relations with other instance features in the mechanical system. For each class feature with geometric shape, an instance method drawingOn:from: is implemented to draw the 2D geometry. When a number of instance features are generated, the 2-D Geometry Browser asks all the instance features to execute the instance method drawingOn:from: to display the geometry of all these instance features, as shown in Figure 2.
Attribute relation maintenance module: An attribute relation is defined by a number of input attributes and one output attribute. When an attribute value is modified, the attribute relations that use the modified attribute as an input attribute are put on the agenda to be evaluated. When an attribute relation is evaluated, the output attribute is again considered as another modified attribute and all the attribute relations that use this attribute as an input attribute should be put on the agenda to be evaluated. This process is continued until each attribute relation on the agenda has been evaluated.

MECHANICAL SYSTEM MODELING EXAMPLE
This example models a mechanism shown in the 2-D Geometry Browser of Figure 2. This mechanism is composed of a motor, two gear-chain boxes, a worm-gear pair, and a pulley-belt pair. A gear-chain box consists of four gears and three shafts. A worm-gear pair consists of a worm, a worm-gear, and a shaft. A pulley-belt pair consists of two pulleys and a belt. The descriptions of class features for this mechanism are shown in Table 2.

Table 2. Partial descriptions of class features.
Class Features	Feature Elements	Attributes	Attribute Relations
Gear		z: tooth number d: diameter n: speed w: width
Shaft		d: diameter l: length n: speed
GearChainBox	?g1: Gear ?g2: Gear ?g3: Gear ?g4: Gear ?s1: Shaft ?s2: Shaft ?s3: Shaft		n[?s1]:=inN[?self] n[?g1]:=n[?s1] n[?g2]:=n[?g1]z[?g1]/z[?g2] n[?s2]:=n[?g2] n[?g3]:=n[?s2] n[?g4]:=n[?g3]z[?g3]/z[?g4] outN[?self]:=n[?g4]
Motor		h: height l: length n: speed
Worm		d: diameter l: length n: speed
WormGear		d: diameter z: tooth number n: speed
WormGearPair	?w: Worm ?g: WormGear ?s: Shaft		n[?w]:=inN[?self] n[?g]:=n[?w]/z[?g] n[?s]:=n[?g] outN[?self]:=n[?s]
Pulley		d: diameter w: width n: speed
Belt		l: length
PulleyBeltPair	?p1: Pulley ?p2: Pulley ?b: Belt		n[?p1]:=inN[?self] n[?p2]:=n[?p1]*d[?p1]/d[?p2] outN[?self]:=n[?p2]
MechanismA	?m: Motor ?gb1: GearChainBox ?gb2: GearChainBox ?wg: WormGearPair ?pb: PulleyBeltPair		inN[?gb1]:=n[?m] inN[?gb2]:=outN[?gb1] inN[?wg]:=outN[?gb2] inN[?pb]:=outN[?wg]

When the class feature MechanismA is used to create an instance feature mechanismA1, the five element features defined in MechanismA should also be created as instance features. The generated instance features for this mechanical system are shown in Figure 8. A total of 26 instance features have been generated.

The 2D geometry of each class feature is determined by its attributes. For instance, the geometry of a gear is described by a rectangle with the width and diameter attributes of the feature as the lengths of the two sides of the rectangle. The 2-D Geometry Browser is used to display the geometry of each generated instance feature.

The attribute relations in instance features are used to keep the consistency of the database. For instance, if the rotational speed of the motor or the tooth number of a gear is changed, the rotational speed n of the pulley2 should also be updated using the attribute relations.

CONCLUSION
In this research, a superset of Smalltalk, FPML, has been developed and implemented for modeling mechanical systems. The advantages of FPML are summarized as follows:

By developing FPML, a superset of Smalltalk, all the properties of Smalltalk objects, including instance variables, class variables, instance methods, and class methods, can be used in FPML.
Many new schemes have been developed in FPML to model mechanical systems. The new schemes include element features, attributes, feature relations, attribute relations, and feature geometry.

The developed language provides a new approach for modeling mechanical systems. This language can describe both geometric and nongeometric product information, therefore paving the way for developing next-generation CAD systems with conceptual design functions.

Acknowledgments
I thank my students, Z. Feng and S. Yadav at University of Calgary, for implementing the latest version of FPML and FPMS. In addition, I thank Prof. D. H. Norrie at University of Calgary for his collaboration in developing an industrial application using FPMS. The early support from Prof. T. Tomiyama at University of Tokyo and Prof. Z. Dong at University of Victoria is also acknowledged.

References

Singh, N. Systems Approach to Computer-Integrated Design and Manufacturing, John Wiley & Sons, New York, 1995.
Bourne, J. R. Object-Oriented Engineering: Building Engineering Systems Using Smalltalk-80, Aksen Associates Incorporated Publishers, Homewood, IL, 1992.
Goldberg, A. and D. Robson. Smalltalk-80: The Language and Its Implementation, Addison–Wesley, Reading, MA, 1983.
Hopkins, T. and B. Horan. Smalltalk: An Introduction to Application Development Using VisualWorks, Prentice–Hall, Englewood Cliffs, NJ, 1995.
Shah, J. J. and M. Mantyla. Parametric and Feature-Based CAD/CAM, John Wiley & Sons, New York, 1995.
Xue, D. and Z. Dong. "Feature Modeling Incorporating Tolerance and Production Process for Concurrent Design," Concurrent Engineering: Research and Applications, 1: 107–116, 1993.
Xue, D. and Dong, Z. "Developing a Qualitative Intelligent System for Implementing Concurrent Engineering Design," Journal of Intelligent Manufacturing, 5: 251–267, 1994.