Our experience of designing a visual information processing service foruse by engineering-product designers leads us to report a conflictbetween user and computational views of physical and chemicalproperties represented in an object-oriented classification system.Physical-world representations frequently demonstrate a need forsegmenting the property descriptions of classes. A generative techniquefor depicting property commonalities, reported here, allows us toseparate sets of interconnected properties from the core object-orientedprinciple of inheritance across classes.
Introduction
In the course of a software-development project involving arepresentation of realistic engineering materials and product designs,we frequently encounter a problem with the granularity of an object-oriented classification strategy. The problem concerns the modelling ofa plurality of real-world property characteristics. While a single classmay be the appropriate inheritance-based abstraction to absorb the(structural or procedural) property knowledge, its description mayinvolve distinct bands, segments or clusters of properties which arehighly interrelated among themselves but unrelated to all others. Thereis therefore a case for a deviation from the classification mechanism.Our deviation is to use separately described property generators tosupplement the class template.
In this scheme, a completed class description guarantees theminimum (possibly zero) contents of its members. So as to constructuseful instances, the class is aided by the installation of appropriatePartial Template Objects (PTOs) which add to the properties of its
instances. Both classes and PTOs are generative and may be tailored toproduce special instance-initialization responses.
The scheme has advantages for dynamically modifying a specificpart of the characteristics of classes. Such modification is automaticallytracked by migration in the property structure of the affected instances.This approach depends on the existence of run-time classes (or classmanagers), as in the Smalltalk-80 language.
Our classification-based modelling problem
Our software application [1] involves modelling, storage-managementand visualization of materials-engineering information within a
a class total template a partial template
i' y
f"
is;
observables
ii activitiesIlll ,..., . . . . /j ....
:::",:.::
"communities"observations
"communities"observations
"community" of discrete
other inter-related
other unconnected
response to new
I'll,,,
observables
ii activities..../i ....
observationsinter-related
"community" of
t
responseto installOn
a class skeleton template
tt
particular occurrences
response to new
particular occurrences
I I A module which supplies a' ' template.
(A module may be implemented e.g. asa manager for a class or even a specialinstance object.)
Potential structure generation event.
The enclosing scope of visibility(of variable look-ups experienced bycode for activities).
Figure 1: Class templates with Partial Template Objects (see right schematic)or in standard usage without them (see left schematic).
Smalltalk-80 environment. We adopt Smalltalk's classificationtechnique for our domain model: hence, we use classes to depictfamilies (or higher abstractions) of materials, whose descriptions classifyinstances of particular grades. These grade-instances are engendered byabsorbing property information, through translation from public-domain databases. Development of the model is driven by classifyingover the property structures acquired from the raw data. When underconsultation by reception of the appropriate message formats, these(run-time managers for) materials classes function in our mechanism asuseful summarizers of property information. A related scheme is beingdeveloped for the description of engineering artefacts.
The modelling problem concerns the description of properties. Amaterials or product class embodies the description of a plurality ofengineering properties [2]. In general, we wish to abstract away theclosely interrelated properties, so as to describe them separately — butultimately in association with — the classes of instances to which theycontribute relevant property-detail. This scheme is indicated,algebraically, in Figure 1.
Classification into a hierarchy of materials and productdescriptions has advantages for model- and user-interface-construction,because we may capitalize upon (i) epistemological rules ofphysiochemical similarity of materials and processing of products [3]which translate into a specialization hierarchy, as implementablethrough an inheritance relation on classes, (ii) run-time classes providean added resource to an information system as generic summarizers.Therefore, we do not wish to overthrow classification-basedrepresentation. Instead we shall supplement classes with PTOs.
A mechanism for partial template objects
Partial templates are allied to classes in the specification andimplementation of our high-level modelling application. Both classesand PTOs are designed to be homogeneous, coherent modules in theirown right. To promote property-sharing, they are both supported by(single) inheritance, so that they may be described as extensions orspecializations of other classes or PTOs (respectively).
In our Smalltalk implementation, any instance of the classPartialTemplate or of its subclasses (used for special tailoring) is a PTO.The outline description of PartialTemplate is simply:
1. Ability to insert methods. — A PTO associates a dictionary ofinstanceMethods and a dictionary of classMethods. These arestored "partially compiled" for extra portability and efficientcompilation into any class into which the PTO is installed.instanceMethods contribute behaviours of instances of theaffected class, while classMethods contribute behaviours of theclass (manager) itself.
2. Protected scope of variable reference, local to the set of insertedmethods. — instanceScope and classScope express variabledefinitions which are accessible to the instance methods and classmethods (respectively) which have been inserted upon installation ofthe PTO. The scopes comprise (i) instance variables which are visibleto all methods of the affected class, (ii) community-pool variablesvisible to all instanceMethods and classMethods which beeninserted into the affected class, (iii) Smalltalk global variables visibleto all Smalltalk methods generally. The provision of community-pool variables implies a local enclosing scope of the behavioural"community" which has been inserted into the affected class. Theselocal variable definitions are not otherwise accessible to othermethods of the affected class.
3. A record of all classes the current PTO has been installed upon. —classeslnstalledOn stores this set of classes as part of amechanism which ensures that changes be propagated to thoseclasses when the current PTO is modified.
It will be apparent from the above specification that more than onePTO may multiply be installed upon any given class skeleton. In orderto control multiple installation, the specification of PartialTemplatealso incorporates the following:4. Prerequisites. — These are other PTOs which must be installed upon
the target class before the current PTO can also be installed. Thisattempts to provide for control over inter-module dependencieswhich arise if methods of the current PTO call methods in otherPTOs.
5. Preclusions. — These are other PTOs which must not be installedupon the same class as the current PTO, because their behaviouraldefinitions conflict with external calls of the current PTO.
This specification of PTOs supports the idea that they provide acohesive description of the partial contents of classes in our domainmodel. They attempt to provide the classes which they affect with awell composed character, in the sense that each set of installedproperties observes a scoping regime common to members of the set butotherwise private. They are flexible if the modification of PTOs, alreadyinstalled, propagates to the classes which they contribute. This, in turn,is tracked by the data migration of instances, and the storagerepresentation of our custom database management program, in ourparticular Smalltalk-extension environment, discussed in [4].
Attempts at representing engineering design properties
The partial template mechanism was developed as a result of ouranalysis of user reactions to our visual information processingenvironment. We identified a mis-match between the basecomputational view of the property of an object, supported by theSmalltalk toolkit, and product designers' expectations of engineeringproperty representations. Our experience was as follows.
Our project involves developing tools to aid the sifting of assortedmaterials classes by product design engineers. It has proved useful todevelop a hierarchy which serves to accumulate the propertyinformation of base formulations of materials, especially plastics, ingeneral or company-specific use. Looked at top-down, this arrangementis a specialization ordering. Bottom up, we see a generalization frommaterials families such as Nylon66 to descriptions of larger sets ofmaterials such as Nylon to yet more abstract categories such asThermoset. Each class in the hierarchy is expressed as a Smalltalkclass object which can respond to messages about the property contentsof the grades subsumed. Responses may thereby be compared, so as tobuild up a picture of the corresponding profiles of property valuesacross different domain classes. Such a picture, in the form of collateralbar charts for multiple different materials families against a givenproperty, is a feature of user-consultation in our mechanism.
Alongside this tool for property-information retrieval are a varietyof tools for browsing the domain-relevant hierarchies and for directretrieval of instance representations from the database, as Figure 2.
Figure 2: Our approach to presenting comparative property information,
Our first substantial attempt at a materials property representationamounted to (i) factoring of materials information into classes,(ii) providing tools for the interactive modification of the hierarchyfeaturing insertion, deletion, renaming and class re-positioning,(iii) consistency control over the promotion and demotion (i.e. "level ofgenerality" in terms of allocation in the materials class ordering) ofproperty definitions during class re-building. The user-interfaceoutcome is illustrate in Figure 3.
A shortcoming of this representation, according to the engineeringdesigners' reactions to its usefulness, was the lack of attention to therelationships holding between the domain-relevant properties.Properties were implemented primarily as methods which eithercalculated numerical value distributions from the database or lookedup pre-calculated distributions. The methods also served to retrieveannotated information such as units of measure and test conditions.However, these features did no more than palliate the fundamentalobservation that many engineering and design properties belongedtogether as a closely coupled set of entities.
In the perception of our design engineers, agglomerated sets ofmaterials properties fell into principal categories such as mechanical,thermal, electrical, tactile. A number of manufacturing process
&
A<We<J Prop&rttes fR«fnove-<l Properties
Figure 3: Repositioning a materials class with allocation control over affected properties.
categories, especially moulding and machining, also arises. A datumsuch as the cost of a volume of a material is more related to thedesigner's intended use of one category, e.g. thermal, than another, e.g.tactile. It is highly influenced by manufacturing process route. Ourdevelopment of PTOs is an attempt to better support such propertyrelationships, in the light of these observations.
Modelling issues when using partial templates
Our design modelling intention is to capture, in software, some of thesemantics of property relationships by pursuing a "sideways" factoringof properties in addition to the factoring of materials and processes.Our PTOs offer experimental and developing attempts to produce fine -grained descriptions of aggregated properties by constructingMechanicalProperty, ThermalProperty, ElectricalPropertyetc. partial templates.
An advantage of PTOs, as we have specified them, is that the samegroup of properties may be repeatedly installed across the majority ofmaterials families. We consider the redundant re-occurrences of thesame property descriptions in the "finalized" materials classes to beunimportant to the modelling principle. If the end-user conceivesproperty aggregates as an important division of the engineering domain,then the description of each property PTO provides a useful measure ofabstraction, complementing the browsable domain hierarchies.
The most far-reaching application of PTOs is to observe propertycommonalities between different parts of the hierarchy of domain-representation classes. The implication of Figure 4 is that two classes,Cl and C2, which are subclasses of S may readily be made to acquiredramatically different property structures from each other. Further,they may each resemble other classes D and E (respectively) which arenot subclasses of S.
At its most extreme, such a technique might appear to be a perversedeparture from the notion that classification secures similarity ofproperty contents supplied by classes which are closely related through
A Smalltalk class (representing minimum content of a domain entity)
A PTO (contributing a particular property commonality)
a „ i 1 y
/
Figure 4: Far reaching use of PTOs as "rubber stamps" allocating propertycommonalities to different parts of the class hierarchy.
inheritance. The extreme departure is justifiable, in general, by theanalysis that the hierarchy of domain classes connotes a navigationalresource (appropriate, here, as a well accepted materials-engineeringfactorization), whereas property allocation is dependent on property-utility criteria. The most manifest application of this extreme technique— in which we systematically "stamp out" different sets of propertycommonalities — is the division between filled and unfilled grades ofplastics. For example, '10% glass filled' versus 'unfilled* is a repeateddivision across the majority of thermoplastic families. Variousrepresentational approaches to this problem are cited in [5].
Of importance to our wish to depict property relationships, thesame property PTO may not always be appropriately applied "across theboard" to numerous materials families. The treatment of PTOs asSmalltalk objects, refinable through subclassing fromPartialTemplate, carries the advantage that more specific, tailoredproperty PTOs can be created to accommodate large-scale or small-scaledeviancy.
A subtlety in the modelling exercise concerns the extent to whicheach PTO represents a closely coupled property aggregate with fewconnections (by means of method calls) to other property aggregates. Inrealistic design modelling it is our experience that any "separation ofconcerns" of properties is unlikely to yield purely independent bands.
An extremely important feature for domain modelling using PTOsis their ability to associate initialization constraints (dispatched atinstance-creation time) with the behaviours which they install and toshare data across the properties which they organize. The followingapplication of PTOs illustrates these features.
Partial templates to structure electrical properties of materials
Figure 5 shows a working arrangement for PTOs to help organize theapplicable electrical properties available to the complete hierarchy ofmaterials. There are three principal electrical property templates, forwhich purpose we have introduced an ElectricalPropertiessubclass of PartialTemplate.
The existence of (at least) three such electrical property PTOs isjustified by (i) the different "checklist" of properties they embody, asderived from textbook descriptions and available database attributes,and (ii) by the different orders of magnitude for electrical resistivity.The property description scheme of Figure 4 illustrates how PTOs may(sometimes) help to reinforce the factoring of materials, since the PTOs— distinguished by the appropriate value intervals for theresistivity property — partition the available materials classes intometals, ceramics/semiconductors and plastics.
Two particular features of the partial template approach exploitedby this application are as follows:1. An initialization-time consistency check is supported on the
resistivity value of any instance of a class on which an electrical-
Figure 5: An application of PTOs to modelling electrical properties of materials.
property PTO is installed. This is by appeal to the resistivityRangecommunity-pool variable, local to the particular PTO. The code for(this aspect of) the property is written in Smalltalk as:
resistivity: aResistiveValue"Set the resistivity of this grade of material. Checkfirst that it is of an appropriate type and a sensiblerange for this kind of material"((aResistiveValue isKindOf: thisProperty type)and: [resistivityRange includes: aResistiveValue])
"ThisProperty is a community pool equated to a Property PTOwhich this method belongs to. resistivityRange is acommunity-pool variable equated to a Range object"
2. The properties dissipationFactor and powerFactor recorded in thelow-resistivity electrical-property PTO are both algorithmicallyrelated to resistivity and dielectric constant properties of that PTO(upon installation). This allows us to interrelate these properties soas to vet submitted values or calculate missing ones. The code for(the calculation aspect) of these properties is:
dissipationFactor"Returns the dissipationFactor for this grade of materialwhen a 60Hz field is applied"^resistivity / dielectricConstant / 60
powerFactor"Returns the powerFactor for this grade of material when a60Hz field is applied"I Y Iy := dielectricConstant * 60.^(y*y/resistivity/resistivity + 1)** -0.5
The latter feature emphasises the related character of properties that arestrongly supported in a well designed PTO.
Comparative advantages and disadvantages of partial templates
Our development of PTOs was driven by the wish to capture a more"segmented" view of those behaviours of our domain-representationclasses than was logically the outcome of a holistic class description.These behaviours are intended to convey useful information aboutrealistic engineering properties. For such real-world modellingapplications, PTOs accomplish:• An organization of properties which is descriptively separate from
the classes of instances which convey empirical entities, but whichnevertheless summarize physical information.
• Mutability with propagation of changes to affected classes andinstances, the latter as a consequence of class-building features of ourparticular Smalltalk-extension environment.
• Supposing empirically realistic property aggregates, cohesiveproperty description which is readable and consultable givensuitable browsing-style presentation tools. Such tools for viewingPTOs conveying materials property templates are shown in Figure 6.Multiple inheritance and delayed (or parameterized) class
descriptions [6] are two techniques which might be compared andcontrasted to our partial templates.
In contrast to multiple inheritance :1. Multiple inheritance is defined by an effective (non-abstract) class
which combines the properties of two or more "parent" classes.PTOs, however, work by side-effecting an existing skeletal class. Themodelling implication is that the inheritance organization is notperturbed by an orthogonal problem of "segmentation" of propertycontents.
2. PTOs always abstract collections of deferred behaviours. They areineffective, i.e. they can never create instances directly.
3. Upon installation, the behaviours stored by a PTO experience theenclosing scope of community-pool variables. This promotes the useof PTOs to represent a tightly integrated community of relatedbehaviours.
"Returns the oowerFactor for We oratfe of material whan
Property description
Property Nem@;Comments: Electrical properties of mediumresistivity materialsInstanceScope Type Unitsresistivity ResietiveVaWe o^mdielectric DielectMcVaWe F/mdlelectricStranatli ItectrioFieWalue V/m
r—-Attributes
PAPE
Browser
Figure 6: A browser window to inspect property descriptions (above) and aview of the data stored by a particular PTO (below).
The partial-template design technique, however, has a similarmotivation to multiple inheritance. Both accomplish a "marriage ofconvenience" between two or more collections of sets of properties. Theparticular marriage contract enforced by PTOs dictates that one party —the class skeleton — is the guarantor of the minimal contents of itsinstances.
In agreement with points 1 and 2, above, the partial-templatetechnique is also related to deferred classes. The two approaches differ,however, in that classes are "unaware" of the behaviours which PTOswill introduce. PTOs supply any number of deferred operations. Thenumber they supply is capable of adjustment (upwards or downwards).The operations are separately organized and changeable. Further, thechanges automatically propagate.
In practice, parameterized classes defer only singular routines. Inconsequence, the two techniques again differ in terms of an enclosingscope (offered by community-pool variables) offered by PTOs.
We suggest that PTOs are constitute a half-way step towards fuller
part-whole relationship modelling. In the construction of design-support architectures it has been cited as theoretically advantageous [ 7,8] to provide a more completely compositional property modelling, i.e.properties as fully fledged independent entities. Such an arrangementenvisages either explicit relationships or implicit references between thepart-object to the whole. While PTOs are less compositional than this,they afford a direct means of complementing a class hierarchy with anadditional generative mechanism for segregating property information.
Conclusions
The core aspiration of real-world modelling applications of object-oriented environments is to provide an information structuring of theworld being represented and reasoned about. Our Partial TemplateObjects address a representational need to segregate propertyinformation in a product-engineering information system, the better todepict property commonalities. They offer an approach whichseparates sets of interconnected property representations from the coreorganizing principle of domain classes related through inheritance.
References
1. Zucker, J., Demaid, A. & Ogden, S. Object-oriented materialsengineering information modelling and management, in TOOLS-7(ed. G. Heeg, B. Magnusson & B. Meyer), pp. 119-133, Proc. 7th Int.Con/. Technology of Object-Oriented Languages and Systems,Dortmund, Germany, 1992, Prentice Hall, 1992.
2. Katz, R.H. Information Management for Engineering Design,Springer Verlag, 1985.
3. Brydson, J.A. Plastics Materials, Butterworth Heinemann, 1989.4. Zucker, ]., Ogden, S. & Demaid, A. Access Enhancement Objects for
Storage and Visualization in a Smalltalk Information System ofEngineering Properties, in IEA/AIE-93 (ed. P. Chung, G. Lovegrove &M. Ali), pp. 148-156, Proc. 6th Int. Conf. Industrial and EngineeringApplications of Artificial Intelligence and Expert Systems,Edinburgh, Scotland, 1993, Gordon and Breach, 1993.
5. Demaid, A., Ogden, S. & Zucker, J. Materials Selection: Object-Oriented Structures for Factoring Polymer Information, in ASTM-STP-1140 (ed. T.I. Barry & K.W. Reynard), pp. 458-471, Proc. Conf.Computerization and Networking of Materials Databases, Vol. 3,American Society for Testing and Materials, Philadelphia, 1992.
6. Meyer, B. Object-oriented Software Construction — Chapter 10:Introduction to inheritance, pp. 217-254, Prentice Hall, 1988.
7. Zucker, J. & Demaid, A. Language fundamentals for design-supportarchitectures, Environment & Planning B, 1993, 20, 425-446.
8. Nguyen, G.T. & Rieu, D. SHOOD: a design object model, Part 4(2),Artificial Intelligence in Design '92, ed. J.S. Gero, pp. 221-240,Kluwer, 1992.
