object-oriented modelling and integrated cad

Automation in Construction 1 (1993) 323-337 323 Elsevier

Object-oriented modelling and integrated CAD Ziga Turk

Unit:ersity of Ljubljana, Cicil Engineering Department, Jamoca 2, Ljubljana, SIot,enia

In integrated CAD different techniques are used to model various features (informations, activities, data and data flow) of the problem domain. Because they model the same real world topic, all aspects developed using different techniques must be compatible and able to cooperate. Since most modelling techniques were developed independently, co-operation is not encouraged. We propose an object oriented modelling approach borrowed from object oriented software design that offers methods and notations for both static and dynamic aspects of state and behaviour of the models and yields smoother development into implementations with object-oriented languages and databases. The paper discusses the motives, the details of the OO modelling approaches and an example from the domain of standards representation. It has been found out that particularly the introduction of the mechanism concept enables and forces us to think about new features of our models.

Keywords: Object-oriented; information modelling; integrated CAD; standards representation.

I. Introduct ion

Lately the advances in the field of integrated CAD seem to be driven by two key technologies, the conceptual modelling approach in the analysis phase and the object orientation (OO) in the implementation phase. This chapter will state the problem that arises when the two are combined and suggest a solution.

1.1. Modelling techniques

Over the last decade the notion that CAD and even computer graphics is in fact a database problem has been gaining support in all fields of engineering [1]. One of the essential steps in developing a database is information analysis or conceptual modelling. The belief that formal techniques are needed is particularly strong in the fields where larger portions of the product design activities had to be considered, as integrated computer aided design (CAD), data exchange, computerisation of standards, automated design...

* Discussion is open until August 1993 (please submit your discussion paper to the Editors on Architecture and Engi- neering, G. Smeltzer and H. Wagter).

These formal techniques include notation for the presentation of the models and may assume a kind of data model type for the instantiation of the model• The techniques used in the modelling process now are not universal, but specialise into certain domains. Different approaches are suggested [2] for the modelling of: • data (EXPRESS [3]);

information (E-R [4], IDEF1X [5], NIAM [6], EXPRESS-G [3]); data flow (DFD [7]);

• activities (SADT,IDEF0 [8]). Current practice would choose the technique

best suited for a particular problem and try to capture all features of the model using the selected technique. In the field of integrated CAD, the modelling of the design process would use SADT or IDEF0 and the modelling of what is being designed will use one of the information modelling techniques. This shows that the reality has several aspects. Some could be better modelled with one, some with some other technique. With the exception of the IDEF* set, the techniques were developed for stand-alone usage. But, at least during implementation the solutions based on these distinct models need to be integrated.

This lets us state the first problem: "How difficult is it, to integrate models that were made

0926-5805/93/$06.(10 © 1993 - Elsevier Science Publishers B.V. All rights reserved

324 Z. Turk / Ohiect-oriented modeUiptg and integrated CAD

O0 modelling O0 browsers • method and shells O0 GUI

[conceptual class and O0 data .I reality J c°nceptual Im°de ~ object mode ,~ CAD

modeltype-- ~ ~ O0 datal~ m°delllng definitions i.] -~;

end user, programmer end user programmer

Fig. 1. The modelling process.

O0 data

t , 7 2 : ' o o

using different modelling techniques, and that are only different aspects of one real world object ?".

1.2. Object orientation

Over the past few years there have been clear indications that OO technology (programming languages, data bases, development shells, operating systems, user interfaces), developed early in the eighties [9,10] will eventually be used for the implementation of integrated CAD systems of this decade. In architecture, engineering and construction (AEC), object orientation has been used for finite element analysis, architectural modelling, building standards representation, draft- ing. . . Commercial object-oriented databases are raising high hopes in the engineering community to providc storage for the complicated technical data structures [ 11 ].

Object oriented paradigm introduces radical changes to the programming environments, which brings us to the next question: "Are traditional modelling methods, deceloped Jor the procedural languages and relational databases most appropri- ate ]'or object oriented implementations ?".

1.3. Unified approach

Motivated by the demands of the computer integrated construction (CIC), Bjork [12] proposed a unified approach implemented as a framework model for the overall information management in a construction project and suggested an information modelling technique as a unification factor. IDEFIX was used for the modelling of construction process entity.

Wc agree with argumcnts that a unified approach is needed. According to the first two

subsections we intend to explore the usage of OO software design methods and OO modelling in the phase of information analysis. Object orientation will be one of the key factors of unification and will be pursued throughout the process of modelling. It should improve the consistency between the analysis, design and implementation phase of our models. It should provide expressive power to model both the static (stressed by information modelling) and the dynamic (,stressed in process and data flow modelling) features of our models.

Finally we want to know: "is it possible to replace traditional modelling methods with O 0 design methods', and if so, what are the benefits and the drawbacks?".

Section 2 discusses the modelling process, the object model ~, the modelling methods and notations. Section 3 presents an example.

2. Object oriented modelling

First, a model of the modelling process will be shown and the role of the OO technique marked. Key elements of object models will be discussed. Finally the method of OO modelling and the corresponding technique will be presented.

2.1. The modelling process

We understand the modelling process as shown in Fig. 1. On the basis of the reality and the selected data model type, the analyst and the

E As wc do not use the adjective "oriented" in other models (relational. network), the term "object model" is preferred to "'object oriented model".

Z. Turk / Object-oriented modelling and integrated CAD 325

end-user use information modelling techniques to build a conceptual model of the problem domain. Its (usually graphic) representation is used to simplify the communication between the experts of the domain and computer experts. Based on this model, a data model is defined. If the type of that model is relational, the programmer would define the structures of tables, the keys. . . For the OO model, detailed descriptions of classes and objects would be defined. Finally, the end user would create an instance of the model and populate the empty database with values.

In Fig. 1 the acronym " O O " is used exten- sively to denote that we hope to be oriented towards objects throughout the process.

2.2. The model

The object oriented paradigm has become well known and publicised over last few years. The key concepts of object models are abstraction, hierarchy, encapsulation, modularity, concurrency and persistence. This chapter will only point out some of the features that distinguish object models from traditional models that are derived from the entity-relationship data model type•

2.2.1. Objects t,s. entities In the context of traditional modelling meth-

ods, the terms object and entity were used inter- changeably to describe real world concepts about which we wish to have information. Entities would be associated with attributes and related to other entities with relations• The E - R , IDEFIX and NIAM data model types are all versions of such an understanding of an entity.

In the context of human cognition an object can be informally defined as a tangible entity that exhibits some well-defined behaL'iour [13]. In the context of object oriented modelling an object has the same role as an entity and is the basic building block of object models. More information, however, is associated with an object, which has three kinds of properties: • state;

behaviour; identity. State includes static and dynamic properties of

the object. The static properties of objects roughly correspond to relations in entity-relationship (E - R) models. The fact that a beam is supported by

columns may be considered such a static property• By which actual column the beam is supported, how long, wide and deep it is, are dynamic properties that correspond to attributes in E - R models•

Behat'iour includes information on how the object acts upon other objects and how it reacts to messages from other objects• The reactions may include state changes or actions (messages)• In a model of a structure, a reaction to the message "compute" may result in state changes of internal forces inside the beam. A reaction to the message "'check" in a conformancc checking context would result in a reply "conforms" or "does- not-conform" being returned to the sender. Mes- sages can bc divided into five groups:

modifiers change object's state; selcctors query object's state;

• itcrators; • constructors;

destructors. The last three become important during the

implementation• On a conceptual level, query messages (selectors) could also be called derived static properties or attributes, since they would return a value, and the user of the value would feel no difference whether the value was stored in the object or was just computed from other attributes.

Identity is a property that distinguishes the object from all other objects [14]. Implementations of object data models could add special ID's to object's state (common in object data bases) or resolve identity from object's address in memory. Identity is a built-in feature of objects and is not our concern during the analysis.

Static state and behaviour of similar objects can be defined in their class. Particularly the behaviour property of objects introduces the difference between objects and entities. Objects also become things you do something to and not only things you know something about.

A collection of objects that exchange messages exhibit behaviour. Such a collection is called a mechanism• We could understand a mechanism as a dynamic extension of the system/subsystem concept that is used in AEC information models [15]. We feel that the mechanism concept is essential for object oriented modelling and is the concept that enables the modelling of both the static and the dynamic features of models.

326 Z. l'urk / Object-oriet,ted modelling and integrated (',4I)

2•2.2. Relations The relations can be di(,ided into the following

categories: object to object: object to class: class to class;

Models are built of objects that may be related to each other in two ways: • an object uses another object;

an object contains another object. The using relation gives an object one of the

following three roles. An object may be an actor (1) which means that it uses the other object but is never used. An object is a sert,er (2) if it is only used by the other object and is an agent (3) if it can act both as an actor or as a server.

Object 's rcsponse to messages reveals its synchronisation aspect. From this point of view an object may bc sequential, blocking or concurrent.

The rc[ation "'contains" creates aggregate objects where an objcct becomes a part of another object. As there is a dilemma in E - R type of modelling, whether something is an attribute or a related separated entity, there is a dilemma between understanding somc information as a us#zg or as a containing relation. The first relation rcsults in more loosely, the second in tightly coupled systems.

Class to class relations include single or multi- pie inheritance (the well-known a-kind-of relation ), using (a class may use another class in its interface or its implementation), instantiation (used in container classes) and meta-class (used if a class itself is considered an object). For intormation modelling only the first two rclations seem to bc useful.

2.2•3. Associations Originating from the different treatment of

cncapsulation, some authors identify a special set of relations called associations. They are defined as a group of links between objects, with common structure and common semantics [16] and are well known from the design of database systems. The "'strong encapsulation" approach states that all information concerning an object should be en- capsulatcd within an object. The "weak encapsulation" approach discovers relations between objects that could not be attached to a single object. For instance if a column rests-on foundation, then the force applied by the column to the

foundation and all related actions and calcula- tions can not be attached either to the column or to the foundation. An association then obtains similar features to a class. It may have attributes and operations of its own which leads us to representing associations as separate objects. In our previous example a node object of some sort has no physical existence, would bc introduced between the column and the foundation.

Association and relations can bc described in greater detail by giving it a name (like rests-on), showing its multiplicity, identifying the role each objcct plays in an association and by spccifying the qualification and ordering. Somc of these features will be discussed below.

2.3 The approach

We have bccn considering two object oriented modelling and design techniques, Booch's Object Oriented Design [13] and the Object Modelling Technique (OMT) [16]. The approaches are in many ways similar and will be presented in parallel. Two separate subchapters will present the details of each method. The discussion at the end will present a synthesis that was found useful for conceptual modelling•

Object oriented modelling and design is a software development method. Booch understands it as a waterfall like development extended with backlt~ps (Fig. 2(top)) and stresses flexibility (the evolution and the modification phase). The stages of the OMT are more conventional and pay more attention to the starting phases (analysis and design)•

Caused by the very nature of object models, there seems to be a very vague and inexactly defined boundary between object oriented analysis and object oriented design•

ANALYSIS < ..... . ~ D E s I G ~ - - , . . . . . . . .

...... J----=-~ EVOLUTION ~ " ~1 ........ J )~ MODIFICATION

ANALYSIS ~ - - . . . . . . . . > sYs~M DESIGN ~ . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . J----" .......... - - -~OBJECT DESIGN ~ - - - - ' . . . . . . . . . . . . . . . . . . . ~ IMPLEMENTATION

Fig. 2. The software development life cycle: (top) Lk~och: ( b o t t o m ) O M T .

Z. li~rk / Object-oriented modelling and integrated C4D 327

2•3.1• O 0 analysis Object oriented analysis should identify the

objects and classes that form the vocabulary of the universe of discourse (UoD). It is being pcr- formed in close co-operation with the field experts and must be understood by them. It may build a model of the real world showing its esscn- tial properties--what the model does (not how it does it). This may overlap with what is somctimes done during the dcsign phase•

Analysis can either be performed on the prob- lcm in question or on the whole domain of problems (domain analysis)• Product modelling approach corresponds to the second. Some authors [17] suggest things that are candidate classes• Other possible analysis methods include the In- formal English Description and the Structured Analysis methods [18], which are well supported by cxisting CASE tools•

2.3.2. O 0 des&n Object oricnted design should invent abstrac-

tions and mechanisms that provide the behaviour of the model. During system design high-level decisions about the software system are made and design strategies adopted• Object design uses the strategies to translate concepts of the analysis phase into objects and adds details like data structures and algorithms to these objects.

OO Design process is a fuzzy, iterative process (contrary to top-down or bottom up classical de- signs) which develops solutions through refine- ment. According to Booch, the process can be broken into thc following steps (applied at different levels of abstraction):

• Discot'ery of key abstractions and mechanisms• Classes and objects on a certain level of abstraction are identified based on the classes and objects discovered during the analysis•

• Identification of the semantics (meaning) of classes and objects• The particular interest should bc in the interface of thc object/class that define the properties visible (and usablc) by other objects/classes.

• Identification of the relationships among classes and objects that can be of static and of dynamic nature•

• Implementation is concentrating on the representation of classes and objects, grouping them into modules and processes. To use these software dcveiopment methods in

conceptual modelling, we will be only interested in analysis and the phases of design not con- cerncd with programming dctails.

During the process, thc attributes of quality design should be followed• These include coupling, cohesion, sufficiency, completcness and primitivenes.s. One of the key methods to achieve that within object oriented systems is classification.

2.3.3. Classification Classification provides means to organisc ob-

jccts and classes• It can be broken into two sub problems:

the discovery of key abstractions and mechanisms; the invention of generalised abstractions.

Table 1 The six types of diagrams used in OO design

Static features Dynamic features

Logical class diagrams show relations between classes object diagrams show objects and mechanisms they participate in

Physical module diagrams show the allocation of class and object definitions in modules process diagrams show the allocation of processes to processors

state transition diagrams show state-space of an object, events that cause the transitions and actions.that result from a state change

timing diagrams show dynamic interactions among various objects in object diagrams

328 7,. Turk / Object-oriented modelling and integrated ('AI)

It is considered to be an incremental and itera- tivc process where it is rarely possible to find thc "'right" or the "best" solution. The suggested methods for the classification of objects arc:

classical classification (usc propcrties as a crite- ria for sameness among objects); conceptual clustering (formulate conceptual descriptions of classes, then classify); prototype theory (define concepts by examples), cxisting classification systems in areas wherc thcy exist. As thc namc implies, thc result of classifica-

tion are classes. They can be used to create new classes by derication (derivc new specialised classcs from existing ones) with its inverse abstraction (group classes with a commonalty into super classes) and factorisation (split a class into sevcral classcs) with its inverse composition (join several classcs into one class).

2.4. 7he Booch notation

Table 1 shows the six diagram types needcd to capture OO design. Four are used to capture the static, two to capture the dynamic aspects, three to capture the logical and three the physical aspects of the design.

2.4.1. Class diagrams The graphic vocabulary of the class diagrams

consists of classes and various kinds of relationships. The shape of a class should indicate that it is of an irregular form, but has clear boundaries (Fig. 3 (left)). The boundary, however, is dashed, because most operations are usually performed on the instances of the class. Large projects would require many class diagrams. Booch introduces a concept of class categories to group and relate similar classes. In-depth explanation of classes in the diagrams is provided in class templates-- forms with several fields describing different aspects of the class.

An example of a template is in Fig. 5. Darker fields arc not important for the modelling stage. The braces in the "field" and "uses" lists are an

( class name/'

Fig. 3. Class icon (left) and object icon (right).

c x label x us~s ( ~ , mm'taco) 0 zoto

x i , ~ x u s u (for ~otem~mtalion) 1 one

. . . . .W~.. I . . . , , Ins tan~tes (t:onglatlble type) , zero or more

-l- - -L~- - I- - - ~. irlslanKltes (new type) • one or more

label I in l le#~ (oonloatW~ type) ? zero or one

: label - in tm¢~ (new type] n n

label ~_ r n e t J c t a l ~

m . . , m D e o m o

Fig. 4. Icons uscd to show relations in class diagrams (from 113]).

extension and show the relations betwecn an object of this class and other classes, to which they are also hyper-linked. The distinction between "field" and "uscs" becomes important during the implementation.

Thc relations between classes arc shown by connccting lines (Fig. 4). Name, direction and multiplicity of the relation may be shown on the diagram. An example of a class diagram is in Fig. 16.

2.4.2. State transition diagrams Since state transitions of objects arc caused by

actions (messages), the finite state machine of Mealy type is used to capture statc transitions. Icons include circles to represent states (double line for start state and thick line for cnd statc), and arrows to represent actions. The details of actions could be explained in a PDL (Program Design Language) or in object diagrams. The example is depicted in Fig. 18.

2.4.3. Object diagrams Object diagrams should capture the mecha-

nisms and their primary goal is to capture the message passing between the objects. The shape of the object icon is the same as of the class icon, except that the line is not dashed (Fig. 3 (right)). Notation is provided for different kinds of message synchronisation (simple, synchronous, balk- ing, time-out, asynchronous) and object visibility. The letter is of interest in detailed design. For an example of an object diagram see Fig. 17.

2.4.4. Timing diagrams Both object and state transition diagrams do

not capture the dynamic nature of collaborating


[ l ie Edit Text B i l e Help

I I building ]

m

Fig. 5. A page from a Class Book (Developed with Toolbook hypertext system) showing the fields that describe a class.

objects. The firsts are static while the second capture only state transitions within a single object. We could add dynamics to object diagrams by adding ordinal numbers to messages. These would then show the sequence in which messages are sent. Another suggested approach is using a PDL for each object diagram, or using the timing diagrams borrowed from hardware design, similar to electronics timing charts. The method also captures multi-threaded events that will become a common programming practice on operating systems like OS/2.

Table 2 Models and diagrams of the OMT method

Model Diagrams

Object model. Describes the structure of objects, their name, links and associations, attributes and operations.

Dynamic model. Describes time related aspects of the model like concurrency, sequence and timing.

Functional model. Describes the transformation of data within the model.

Class diagram Instance diagram

Event trace diagram State diagram

Data flow diagram

i c,...,,.,_. ,I Cl,,==Name . . . . . . !

attdbuteNamel :attributeType [ attdbuteName2:attributeType = defaultValue2 =

.M. eth°dName(parameters) :returnedType J

Fig. 6. Class symbols.

2.5. The OMT notation

During the analysis stage, the OMT method [16] builds three models. Diagram types associated with each model are shown in Table 2. All the diagrams are of interest for conceptual modelling.

2.5.1. Object model The class diagram is a graph consisting of

classes and relations between them. The icon for a class is rectangle shaped (Fig. 6). In its short form it may only consist of the class name (Fig. 6 (left)). In the verbose form it may also show features of the class. In the middle rectangle are the attributes with its name, type and possible default value and in the bottom rectangle the

3311 Z. Turk / Object-oriented rm)delling and integrated CAD

• ' ! ObectName. . ! ObjectName ' 0bjectValue

Fig. 7. Object symbols.

methods with name, parameters and the return value (Fig. 6 (right)).

The symbol for an object is a rounded rectangle. It contains the information of the object type (all objects in Fig. 7). It may also contain a name or an ID (middle) and the value (right).

The relations between classes are binary associations or links, special 3-ary associat ions-- qualified associations, general n-ary associations, hierarchies and aggregations.

L i n k s or binary associations are represented by a line connecting the two classes (Fig. 8). Information on the line contains name of thc relation in italic ( i s - suppor t ed -by ) . It may contain the role the two classes play (e.g., the role of the foundation is to suppor t ) . The multiplicity of the relation may bc exactly one (symbol 1), zero or one (a white circle symbol), one or more (1 + or a black circle symbol). A loop on a link may specify link attributes (in our case the joint type between the column and the foundation, and the matrix containing the forces between the column and the foundation).

General n-aD, assoc ia t ions arc represented by a network of three or more classes connected to a diamond. Figure 9 shows such an association between an element (in a FEM program), the loading case and the calculation method. Each unique combination of these three items pro- duccs different internal forces in the element. The loop for the association attributes is connected to that diamond.

Qual i f i ed assoc ia t ions are a special kind of 3-ary associations (Fig. 10) and connect two classes with an attribute that reduces the selec- tion of associated objects. In general, an clement

Element

' Load ing C " - ~

i i . . . . . . . ' i , , . . . . . . .

~ e m a l Forcesl _ J

Fig. 9. N-ary associat,on.

Calcu la t ion M e t h o d

] 5 . . . .

Element i _node I l e t ~ connected to O N o d e . . . . . i . . . . .

Fig. 10. Qualified association.

I Tag

i

. . . . . . . . . . . T . . . . . . . . . .

. . . . i . . . . . . . . . .

Q u o t e ~ i E x p r e s s l o n Llnk

Fig II. A hierarchy.

m a FEM program is connected to some nodes. An attribute node-list reduces the association only to those nodes present in the list.

Hierarchies show the kind-of relations between classes. In Fig. 11 there is a part of the hierarchy from Fig. 16. The ancestor and the descendants are connected through a triangle. The notation is provided for special mark-up of single and multi- ple inheritance.

P a r t - o f re la t ions are very popular and natural in the modelling community. The O M T provides special notation for this relation. A small diamond is drawn near the class related to another class with a part of relation. Another section of Fig. 16 is presented in OMT notation in Fig. 12.

i Column q. _ is supported by 11 Foundat ion , . . . . . . . . - ~ - ' - sd~6h~.

I t . - -

, loin:join type t foreeLmatrix

Fig. 8. Link symbols representing the joint of a column to a foundation.

i - D e i g n e d i.-. i D e s i g n e d i p roduct "-~-- - - Object ,

I

i

, - -De~gnet i - ' haLl~" 13eelgned i part t - attr ibute

Fig. 12. Part-of relation between a designed product and a designed object.


- - - - - ~ . o b ~ s

I O b l ~ t 1 Object 2 Oblect 3 J ;_ event 1 - . , ~

event 2 "

event 3 .j.~.

t ime ~ _ _ e v e n t 4 _~

Fig. 13. Scenario.

2.5.2. Dynamic model Two types of diagrams are used to show the

dynamic model - -event trace and state diagram. The event trace shows the scenario of actions. Figure 13 shows the notation for the scenario.

OMT and Booch both use the same type of state diagrams, but use a different notation. Fig- ures 14 and 18 represent the same mechanism. States are connected by lines representing events. Notation is provided to specify conditions, attributes and actions (not shown).

2.5.3. Functional model Functional models display the data transfor-

mations within a system. Classical data flow diagram (DFD) icons are used to represent inputs and outputs (arrows), transformations (ovals), data stores (parallel lines), actors (rectangles) and control flows (dotted lines).

2.6 Comparison

We find the OMT method more convenient to draw with conventional drawing tools. Drawing clouds and double lines is more difficult than drawing rectangles, but a specialised tool makes the observation obsolete. The OMT approach to specify attributes and methods within classes may not be useful in non trivial cases. The list of attributes may be quite long making it impossible to show more than a few classes on one A4 sheet. The idea to include some essential attributes and methods into the diagram, however, is appealing. Since there may be different attributes important in different contexts and sheets, the possible am-

biguities force us to have the class definition stored in one place. Therefore a template seems to be a good solution. Booch diagrams clearly lack expressive power regarding the associations and the association attributes. But it could bc argued these could be modelled as separate classes.

OMT seems weaker in displaying dynamic features. It builds on techniques devised by the relational world and in many ways ignores the notion of messages that should be the mechanism for passing control in an object oriented environment. We find Booch object diagram showing mechanisms essential for any not-static OO system. Within methods, however, data flow diagrams could be useful to describe the algorithms. Timing diagrams and state machine arc very similar in both approaches.

Generally Booch is better suited for detailed design and implements a more rigorous definition of the meaning of object orientation. OMT ex- tends traditional techniques and is stronger in modelling static features.

To make conceptual models, we suggest the usage of:

class diagrams (OMT) and templates (Booch); mechanism (object) diagrams (Booch);

• state machine diagrams (Booch or OMT); detailed timing diagrams (Boot or OMT). Such a combined object modelling technique

(COMT) is at least as strong in modelling the static features as ER or IDEF1X. EXPRESS and EDM [19] claim to have objects with operators, but the graphic notation of EXPRESS-G does not support them while EDM does not have a graphic representation. For the modelling of dynamic features, COMT implements powerful message passing mechanism, more powerful than constraints. Object modelling techniques are quite new and were not available during the develop- mcnt of the STEP [20] standard. None is recom- mended by this standard, which may be their drawback in environments integrated around STEP.

checkPart~.? finishe~) checkPm't (finished) ,~ "", .......... ~-* ~ ) OK ~.~ ~ . . . . . . .

Start ~ - - ~ '~chockqKI / '~ . .__- - . . . . . . ~"

Fig. 14. O M T state diagram.

3. Example

The Booch OO design method has been used for a more detailed design of the layered standards representation.

332 Z,. Turk / Object-oriented modelling and integrated CAD

Table 3 The layers of the layered representation. The top to bottom ordering of the layers is the same as in Fig. 15

Name Description Function; Tool used for representation usage

product objects, classes and relations provides data to be checked: OO database graph between them as designed

standard graph

knowledge

(not part of the standard)

objects, classes and relations between them as defined in the standard

declarative and procedural knowledge embedded in the standard

CAD, conformance checking

uses knowledge and tagged text layer in methods

uses layers below to collect data, provides further layers with low level methods:

OO database or KBS shell

hybrid expert system tool, programming language

primitive interactive conformance checking

tagged Tags selected parts of the stan- enables the ab(wc layers to same as text layer, text dard. Tags have name, type access data in the standard: hypertcxt or

and contents. Types are hypcrmedia with machine usable expressions, guided electronic browsing typed links quoted text, go-to links, anchors, kcywords, titles . . . .

text machine readable form of the passive, at best stores constant standard as we are used to see data - the contents of tags of it (m paper, includes pictures the layer above and tables

electronic browsing

SGML, TeX, some word-processor text file

3.1. The layered representation of standards

The idea of the layered representation is based on the assumption that computeriscd standards 2 representation is limited with two boundary conditions: the paper version of the standard on one end, and with a product to which provisions in the standard apply, on the other. In normal practice, the intellectual distance between the two is bridged by a knowledgeable engineer. Computer representation of standards should give him con- siderable help. The prerequisite is that both the standards and the products arc stored in a com- puterised form. As the name implies, the layered representation bridges the distance by introduc- ing several layers between a computcriscd "on the paper representation'" and the product data (Fig. 15).

The form and function of the layers are briefly presented in Table 3.

2 The term "s tandard" is used to denote various kinds of regulations and provisions on different legislative or profes- sional levels.

3.2. Classes

To makc an object model of the layered rcpre- sentation, information in all levels should bc modelled as classes and objects. They are shown in Fig. 15. Detailed classes for the representation of products are being defined as a result of the

. . . . . . . . . . P E ~ D U C T GRAPH LAYER

/J /

/gF/I~F"

, ' . . . . . . . . . . . . /

Fig. 15. The layers of the layered representation of standards.


reference model development. The classes for standards representation have been proposed by Garret [21] and modified in [22] to fit into the layered representation scheme. The knowledge layer treats procedural and declarative knowledge in a similar way. The knowledge island technique providing object oriented shell around both procedural and rule-based knowledge [23] is suggested for the representation. Finally, the tag

layer provides an intelligent interface to various information found in the standard text.

3.3. Objects and mechanL~ms

The relations between objects originating in different layers are "using" rather than "'containing" because we want to keep the layers only loosely couplcd. Thc objects on the layers above

"designed . : ' . . - . " " - p a r t ;

. ' d e s i g n e d o 1 hall part n ' d e s i g n e d , : 4 r ~ ( . ...... , \ \ ' - p r o d u c t ~ " - - , ob jec t ~ : . na$) j

. , - J " . . . , , \ \ ..___.__--------I". part ! % ...... 1 " ' - , o b j e c t ~ .....__ ".'.:.. ,. • na~ , )

standard G nas part n ' required . '4 [ -"~ ! . . . ' - . . . , \ \

L .askable ' .checkable~ . . g iven . .} 1 . } } +

/ • , ,,'

. constant :" ;....., math :" :. table :" ':. graph .. ! ... ! ... i . ...... • ...... ....... , _ . . . ....... , ,_ . ........

Fig. 16. Class relations for the layered representation.

T P R O D U C T LAYER

S T A N D A R D LAYER

- i -

K N O W L E D G E LAYER

TAG LAYER

334 Z. Turk / Object-oriented modelling and integrated CAD

use the objects on layers below. Objects on layers below serve objects on layers above. The relation of objects in standard graph layer to those in the product graph layer is generally that of an agent (they are both used by and use objects in the product layer). Hierarchies are a form of tight coupling and span only through a single layer.

In Fig. 16 one can see that the designed product consists of several objects. Specialisation of these objects are physical parts or attributes. Parts have attributes, but not vice versa. Objects (parts or attributes) are related to each other which forms a kind of a semantic nctwork.

There may be more than one standard used by the product. The structure of the standard is compatible with that of the product. There is deliberate symmetrs' between the classes in the product and the standard layer. A similar semantic net is present within the standard as within the product, while same relations would be different. Also. the standard objects would inherit properties from askable (its value could bc determined by the user), checkabh" (the value could be determined from the provisions of the standard) or git'en (the value can be obtained from the product).

Askable object need a quote object to provide explanation why the question was asked. Check- abh, object may use objects from the knowledge layer (knowledge island or a function) and given objects necd to be able to get their value from the product layer.

Objects from the knowledge layer use tags to get values from the particular part of the standard. The possible subtypes of tags are quotes, expressions and links. Exprcssions have further subtypes.

Fhc mechanism for checking thc design is shown in Fig. 17. Lines represent message paths between objects and arrows above them the direction of messages from the sender to the re- ceiver. Timing is defined by numbers accompany- ing messages. Wc have decided to choose the product objects as active which means that their messages initiate the checking process. First a static match, a pattern recognition process is at- tempted between the semantic network surround- ing the designed object and the semantic network of the standard. It is performed only on static properties of objects. If such a match exists, wc can proceed with the dynamic match, performed on the dynamic properties. A match indicates

/ t o t , / j

/ a l a g g e a 2 ~ , . - ~ - : ~ . ( _^ . . . . . / go ( aLink / I ' .- .

Fig. 17. Object graph illustrating the messages of design verification.

Z,. Turk / Object-oriented modelling and integrated CAD

checkPart$

Fig. 18. Stale machine for the designed object.

335

that there exist provisions in the standard related to the designed object and the checking process can begin. The check message asserts the object into the standard. The actual check is later performed by declarative (aKl) or procedural (aPro-

gram) objects, which may use information from the standard, designed product, the user or standard text. Querying of designed or other required objects, of knowledge islands or functions is used to get the necessary values. Quotes and links are

Die Edit ~lew Insert Formal TRois TAble ~Indow Help

[] Calculnt¢ K

[] show rule

The total seisrr~ ~ K ~ be c~cul~ed frcxn the ~ e s s ~ :

K = Ko * Ks" Kd * Kp. where: F~Ko is the coe~ of bu@c@-~ categoq4

I ~ K s Is t ~ cod'flclert of se~r~c ~maCL'y, [ ] Kd is the coefflde¢l: of dyr-tamic response, ~c l r ~ K p is the ooeffi~¢l: of ductit-y and darnping.

The total ~ coeffic~ert K shall have a rn/'imLrn value d O.O2.

DRULE. / l . i . l I I l l . l - i l l i . l - i ~ l l - l . l R i l - l l l I I l l , l ~ I I l..m l . l i l l . l - l l l I H l . l l m T - -

~ - RULE: &23_k / I ~ H I ! ~ l l H ~ ! l l H ~ l ! l t l ! ! t l ! l i t ! l t l l i t ! l i / |

l la.,ke~zle( A23_K. []" / SC:Ko And SC:Ks And SC:Kd And SC:Kp.

!

~ : K " SC:Ko * SC:Ks * SC:Kd * SC:~p; i . 002 ) /

Fig. 19. Hypermedia connection between the standard text and part of the knowledge island.

336 Z. Turk / Object-oriented modelling and integrated CAD

used for the explanation and tagged expressions for evaluation of the expressions present in the standard.

3.4. liming and state machine

The state machine of a designed object (Fig. 18) shows the transition from the unchecked to checked state. Timing during checking is not criti- cal. If the checking process does not alter other states of the object, the checking processes may run in parallel.

3.5. hnplementation

To instantiate the model described above we arc using DOS PCs running Microsoft Windows. At present, the whole prototype is being built using hypertext authoring system Toolbook [24], a hybrid expert shell Kappa [25] and text processing program Word for Windows [26]. Hyper link feature of the Windows system, the Dynamic Data Exchange (DDE), is used to connect the three tt~ls.

In Fig. 19 a screen showing a part of a the standard text [27] in the upper Word window is presented. The text is extended with hyper buttons (sidebar and instead of bullets). The buttons with an arrow are go buttons and are used for navigation in the standard. Other buttons have a more sophisticated procedure behind them. The show rule button, for instance, opened the bottom window that is displaying the Kappa rule that has the same meaning as the standard in its text form.

4. Conclusions

O 0 analysis and design are relatively new top- ics. Two methods were described and a combination of the two was suggested for use in conceptual modelling. Further developments in the field must be closely monitored, as further improve- ments of the techniques can be expected, particularly when the usage of O 0 databases will become more widespread and the w)lume of users will increase.

We have found the COMT to have equal of better expressiveness of the static features. In addition O 0 design forces us to think about active and passive elements (in our case of the

standard and the product model) in terms of mechanisms that combine the objects and which may be overlooked using traditional techniques. We therefore find it superior to the traditional techniques. Some of the key classes and key mechanisms of standards representation and usage have been identified. It has been shown that OO design methods can be applied to standards modelling. Further research is needed to quantify its advantages and disadvantages over other information modelling methods.

Current efforts in integrated CAD arc tar- geted towards the exchange of information, i.e. data + the semantics defined in standardised schemes. In true OO environment we would ex- pect the exchange of whole objects. New problems concerning the exchange of code providing object's behaviour, across platforms, will emerge. The exchange of objects with well-defined status and behaviour could be the solution for many problems of the domain of integrated CAD.

Acknowledgement

The present work is a part of the PhD project sponsored by the Ministry of Science and Tech- nology of the Republic of Slovenia.

References

[1] P. Robinson, CIM's missing link: object-oriented databases, Comp. Graphics World, (October 1988) 53-58.

[2] J. Fowler. STEP modelling methods, CAD-CAM Data Exchange Technical Centre, University of I,eeds, UK, 1991.

[3] ISO, The STEP standard, International orgranisation of standards, ref.no. ISO 103(13.

[41 P.P. ( 'hen, The entity relationship model--toward a unified view of data, A.C.M. Trans. l)atab. 5~wtems, 1(1) (1976).

[5] Information modeling manual IDEF-I extended. D. Ap- pleton Company Inc.. Report, 110p., 1988.

[6] G.M. Nijssen and T.A. Halpin, Conceptual Schema and Relational Database Design, a Fact Oriented Approach, Prentice-Hall, Sydney, Australia (1989).

{71 R.S. Pressman, Software Engineering, McGraw-Hill, New York, USA (1987).

[81 D.A. Marca and C.L. McGowan, SADT--Structured Analysis and Design Technique, McGraw-i till, New York, USA (1987).

[9] A. Goldberg, Smalltalk-80: The language and its Imph'- mentation, Addison-Wesley, Reading, USA ( 19831.


[10] B. Stroustrup, The C + + Programming Language', Addi- son-Wesley, Reading. USA (1986).

[11] R. Gupta and E. Horowitz, (editors), Object-Oriented Databases with Applications to CASE, Networks and VLSI CAD, Prentice-Hall, Englewood Cliffs, USA (1991).

[12] B-C. Bjork, A unified approach for modelling construction information, accepted paper in Building and t-nt'i- ronment, special issue on databases for project integra- tion (19911.

[13] G. Booch, Object Oriented Design with Applications, The Benjamin/Cummings Publishing Company, Inc., Red- wood City, USA (19911.

[14] S. Koshafian and G. Copeland. Object Identity, SIG- P l A N Notices, 21 (11).

[15] W. Gielingh. General AEC Reference model (GARM), in Christiansson, P., Karlsson, H. (editors), Conceptual Modelling of Buildings, CIB Proceedings, Publication 126, pp. 65-178, W74 + W78 Seminar, Lund, October 1988.

[16] J. Rumbaugh, M. Blaha, W. Premcrlani, F. Eddy and W. Lorensen, Obje<'t Oriented Modelling and Design, Pren- tice-tlall, New Jersey. USA (1991).

[17] S. Shlaer and S. Mcllor, Object-Oriented Systems Analysis: Modelling the World in Data, Yourdon Press, Englew(x)d Cliffs, USA (19881.

[18] E. Yourdon, Modern Structured Analysis, Yourdon Prcss, Englewood Cliffs, USA (19881.

[19] C.M. Eastman, A.H. Bond and S.C. Chase, A data model for design data bases. UCLA, Los Angeles, 1991.

[20] 1SO, The STEP standard, International orgranisation of standards, ref.no. 1SO 10303.

[21J Garret, J.H., An object oriented representation of desing standards, in Proceedings of the ASCF 5th Conference: Computing In ('it il Engineering. American Society of Civil Engineers, New York, 1990.

[22] Z. Turk, Building model standard as a foundation for computer integrated design, in ('omputers and Building Regulations, VTT-Technical Research Centre of Finland, Esp~x), Finland, ( 1991 ) 181 - 194.

[23] Z,. Turk, J. Duhovnik, Using knowledge islands in an object oriented framework for integrated structural design, in Artificial Intelligence and Structural Engineering, CiviI-Comp Press, Edinburgh, United Kingdom (19911 157-163.

[24] Aymetrix, Toolbook software construction sct Ior Win- dows, Asymetrix corporation, USA (1989).

[25J Intellicorp GmbH, Kappa, Intcllicorp, MiJnchcn, Ger- many ( 19901.

[26] Microsoft, Microsoft word for windows, Microsoft ('orpo- ration. USA ( 1991 ).

[27] Code of Technical Regulations tor the Design and Con- struction of Buildings in Seismic Regions, Official Gazzete of the S.F.R. Yugoslavia, No. 31/81 (19811.

object-oriented modelling and integrated cad

Documents