An architecture for the design entity

An architecture for the design entity

C. A. M. Barbosa^I; M. Dreux^II; B. Feijó^III

^IUFG – Universidade Federal de Goiás, Institute of Computing, 74001-970 Goiânia, GO. Brazil. E-mail: [e-mail] ^IIPUC – Pontifícia Universidade Católica do Rio de Janeiro / ICAD, Department of Mechanical Engineering, 22453-900 Rio de Janeiro, RJ. Brazil. E-mail: [e-mail] ^IIIPUC – Pontifícia Universidade Católica do Rio de Janeiro / ICAD, Department of Computing, 22453-900 Rio de Janeiro, RJ. Brazil. E-mail: [e-mail]

ABSTRACT

This paper proposes a new model for the representation of design processes based on the evolutionary aspect of this activity. Also this work presents an innovative approach to object-oriented design processes and a new pragmatic view of the Design Problem Space (DPS). Furthermore, the principles underlying the model are derived from a working CAD system in furnace design developed during the present research work. The information related to the artifact form (space representation), as well as those associated to the functions (rules and nature laws) that the form should attend to, are incorporated by the model. The proposed model is structured in terms of a small number of object types which are capable of building an efficient and robust hierarchical tree. This tree incorporates all the requirements associated with the artifact from the conceptual stage up to the stage of the artifact complete specification.

Keywords: Design, engineering design, product modeling, assembly modeling, object modeling

Introduction

In the past, the use of CAD systems as drafting tools and solid modelers represented the main focus of research. More recently, it has been influenced by the broader concept of design. This view has led to the development of a new generation of CAD systems.

There are many definitions to the term design. Gero (1990) defines design as "a goal oriented, constrained, decision making, exploration, and learning activity that operates within a context that depends on the designer's perception of the context". Design Problem Space (DPS) is described in (Goel and Pirolli, 1989) as "a problem space with major invariant characteristics across all design situations". The proposal of design as exploration is understood by Feijó et al (1996) as "a meta-search process within the design problem space". In (Bento, 1992) design is described as "An evolutionary process that starts with a set of input specifications (S_o), generates a kernel idea in the early stages of the process (S₁) and refines it towards the artifact specification (S_g). Each one of these states (S_i) in DPS consist of a set of entities, i.e. S_i = {e₁, ..., e_n}, where each entity is described in terms of functional specifications and physical attributes".

The model presented in this article is such that some theoretical concepts are produced during the product development stage. That model intends to represent, in a computational environment, the properties that describe an artifact. The artifact characteristics are described and classified. A comparison with related work is made and a case study is presented.

Attribute Representation

The attribute (Prates, 1993) is considered the smallest information element. The attribute represents an unique artifact characteristic and has an unique representation. This representation is given by (1) a desired function, (2) an expected behavior or (3) artifact constraints. The proposed approach considers an attribute as a specific representation of a certain artifact characteristic. It means that, for a set of artifacts that have a common characteristic, they refer to the same DPS attribute representation.

This approach generates a dependency network among the attributes, such that their respective values are defined as a function of other attributes. The attributes that are independent of other attributes are called primitives and are at the root of the dependency tree.

Attribute as an Object

Qualitative and quantitative information (Maher and Li, 1994) are incorporated to the model by means of the Attribute object (Fig. 1²). There is a value associated with its representation and if it is a quantitative information there is also a correspondent unit.

As an example, consider an Attribute to characterize heat flow³, with its definition as in Fig. 2(a). In that figure the heat flow () is defined as a function of the rate of heat (q), the time interval (t) and with unit KJ/h. In Fig. 2(b) the same fluid characteristic, to conform to a different situation, is defined as a function of mass flow (), the specific heat (c) and the fluid temperature variation (T'' - T'), and naturally with the same unit. Although there are two different characteristic representations they share, as expected, some common points (e.g. the unit parameter). There is, therefore, a heat flow class (e.g. Fig 2(a)), and the characteristic definition of Fig. 2(b) can inherit the properties common to both representations. It is not necessary to redefine some parameters, such as unit, and some methods already specified in the ancestral representation.

In order to handle the Attribute according to the object-oriented paradigms (Rumbaugh et al., 1994), it is necessary to be aware of some details. The Attribute does not aggregate components to itself (i.e. there is no Attribute which is PART_OF another Attribute). Nevertheless, it has its own hierarchical tree and inherits and transfers some of its properties.

When there is a request to an Attribute to represent a new characteristic it is either created a new class or an existent class is instantiated. The instances are views of a chosen property, where the value parameter is related to different situations. The instances, therefore, establish a specific characteristic for a certain situation. The Attribute inheritance, however, represents another characteristic, where part of its representation is inherited from its ancestral.

Figure 3⁴ shows an example of an Attribute hierarchical tree for the situation presented in Fig. 2. Note that Attribute_Q'' inherits properties related to its ancestors (e.g. unit, method, etc.), in order to set up its own characteristics. Figure 3 also shows that Attribute_Q'' transmits its properties to its children, referenced by ChiAttribute.

Another important issue is related to the status of the represented characteristic. There are three possible situations: (1) the characteristic stays at the knowledge base (the status has the value CURRENT); (2) the designer is no longer using it (the status has the value ABANDON); or (3) the status is related to the characteristic integrity (the status receives an identifier of the type NOT_CONVERGE, FAIL_OPERATION, etc.).

Design Entities

The proposed entity model does not present a new nomenclature for the terms function, form and behavior (Bento, 1992). It is a representation to support artifact evolution in a computational environment.

It is proposed to divide the artifact evolution in three phases:

(1) Initial phase, where the artifact is described by: (a) a set of functions, that have to be attended; (b) a set of constraints, that have to be fulfilled and (c) its behavior, once it is materialized (i.e. inserted in the real world);

(2) Intermediate phase, where some constraints defined in (1) are transformed into artifact specification; and

(3) Once established the final specification, the artifact is ready to accomplish its objectives.

The following sections consider a bolt as an artifact, in order to elucidate the proposed concepts. This artifact is used since it has cognitive aspects of clear perception (Scheer, 1993) and relatively simple characterization.

Groups of Characteristics

The term entity is defined in a dictionary (Oxford, 1969) as "That which constitutes the essence of a thing". The approach adopted in the proposed model can adequately represent the designer's objects through the object Entity. The proposed model represents the Entity object by a set of characteristics, specified by their Attributes. Since there are many different characteristics in an Entity representation, it is convenient to organize those characteristics in smaller groups (i.e. to establish Entity decomposition). Some situations must be taken into consideration:

(1) In the early stages of the design activity, some established specifications do not necessarily correspond to physical properties of the artifact;

(2) A large number of developed products do not have a specific geometrical form (e.g. fluids); and

(3) There are cases where a single physical form corresponds to different properties and vice versa. (e.g. an artifact, with a certain physical form, is made of a material in a situation and is made of another material in a different situation).

Thus, a natural representation of the Entity object comprises Conceptual and Structural characteristics (Fig. 4⁵). Fig. 5⁶ shows how those objects are related to Entity. In the left column are the Attributes related to the rules that describe the Entity object. In the right column are the Attributes related to its spatial representation.

The Entity object form is represented by its Structural characteristics. However, the Entity object functions and behavior are observed through the interaction of its spatial information with the world where it is inserted. Then, a lower level of the Entity object decomposition is a set of characteristics related to its spatial information (i.e. its Geometrical characteristics). The Geometrical characteristic is treated as the spatial aspect of a certain Structural definition which is grounded on Conceptual characteristics relative to imposed rules and constraints. The Conceptual and Structural parameters of an Entity object are perceived through the Entity object Geometrical characteristic.

The Entity object and its Conceptual and Structural objects do not have Attributes. Those objects have no values associated to them, whereas the Attribute has a value and other information related to it.

Besides the Geometrical object, the set of Conceptual characteristics are also divided in ConceptualOptional and Essential. The Structural characteristics are also divided in another two objects: Topological and StructuralOptional (Fig. 6⁷).

Entity Conceptual Characteristics

The set of Conceptual characteristics of an Entity object, in some cases, represent the entire Entity specification. It is explained by the fact that many products do not have a solid representation. The following sections describe how Conceptual characteristics could be decomposed in Essential and ConceptualOptional (Fig. 6).

Essential

This model considers Essential characteristics of an Entity object as those not related to the physical aspects of the object. They are always present and are represented by a set of Attributes. They are responsible for describing materials, physical and mechanical laws, etc.

Consider the Entity object of Fig. 7(a), to exemplify⁸ some characteristics of the Essential object:

(Ex.1) Bolt material: Steel X. Note that the Entity has to be made of some material and this characteristic does not depend on the bolt form; and

(Ex.2) Maximum torque: Y N m. It refers to a property that justifies the object form. Entity objects possess properties of this kind, related to a certain object class (e.g. bolt).

ConceptualOptional

Like the Essential characteristics, the ConceptualOptional Entity object characteristics are also not directly related to the object form and represent specific characteristics of a certain Entity object. An Entity object, represented by at least some Essential characteristics, assumes different aspects according to the set of ConceptualOptional characteristics added to it. This approach allows a set of Essential characteristics to be considered as basic properties to many descendants. Thus, they incorporate some ConceptualOptional characteristics in order to adequately represent a particular Entity object.

Observe the Entity object of Fig. 7(a) and some examples of ConceptualOptional characteristics:

(Ex.3) Superficial Treatment: Treatment against corrosion J. This characteristic is not directly dependent on the object form. A single Entity object can contribute with its properties to represent different descendants which have specific superficial treatment; and

(Ex.4) Inspection and tests: Procedure K. As in (Ex.3), this characteristic does not establish aspects related to the object form. It is concerned with general Entity properties, sometimes also related to the object form, although not necessarily to define its form.

Most of the times, the Conceptual Attributes represent the majority of characteristics in an Entity specification, since there are a number of laws, rules, processes etc. that an object form has to conform to.

Entity Structural Characteristics

The set of Structural characteristics are a representation of the physical form specification of the Entity object (Fig. 6). Its Topological and StructuralOptional characteristics are explained below.

Topological

The proposed model considers the Topological characteristics as being the spatial relations that describe the Entity form, without considering its dimensional aspects. They usually refer to vertices, edges, faces and other structures that are present in Solid Modelers. A detailed explanation about topological representations is presented in (ACIS, 1998) and (Mäntylä, 1988).

The above mentioned structures have Attributes to represent their Topological characteristics. Those structures are parts of the solids that form the Entity object. The solids are structured as object classes, with Attributes and Methods.

Some examples of the Topological characteristics of Fig. 7(a) are shown below:

(Ex.5) Hexagonal bolt head. This characteristic is related to the Entity form and is completely independent of spatial dimensions (e.g. the head is composed of six sequentially connected edges); and

(Ex.6) Bolt body. Its representation is a cylinder (a basic solid) which is formed by two opposite circular faces and a lateral face which joins them. They are, again, dimensionless information.

StructuralOptional

These characteristics are directly related to the Entity object form. Analogous to the ConceptualOptional characteristics, the Structural aspects can be represented without considering the StructuralOptional characteristics. However, they are important to represent specific properties of a certain Structural form class.

The examples below are related to the StructuralOptional characteristics of the Entity object of Fig. 7(a).

(Ex.7) Bolt thread length: Total thread ⁹. This characteristic is directly related to the Entity form. It establishes a spatial dimension. It specifies that this class has bolt thread along the whole bolt body; and

(Ex.8) Bolt length: Tolerance ± L. This example has properties analogous to (Ex. 7). In this case, however, the Entity Structural definition allows a tolerance range of ± L to the bolt length.

The particularities of a certain Structural parameter are represented by the StructuralOptional characteristics. Starting from a certain Structural object specification, it is possible to derive a new set of characteristics (not too important to the Structural representation), called StructuralOptional, to appropriately represent a specific situation.

Geometry Dynamics

The study of artifact geometry is known to be a problem during the design activity since it concerns both the function and the form of the object (Feijó and Fischer, 1992) and (Bento, 1992). The artifact geometry is represented by the Geometrical object. The Entity form is usually presented in a three-dimensional space. This form is a representation of the Structural characteristics, which are based on rules and laws related to Conceptual parameters. Thus, a Structural aspect usually requires a correspondent Conceptual definition.

Usually, during the initial design phase there is not a physical form to represent the artifact being developed. The Geometrical representation only exists after significant evolution of the Entity object. On the other hand, there are many products that do not require Geometrical parameters to represent them (e.g. liquids, gases, pastes etc.).

An Entity with a well defined spatial form has a Geometrical representation, which is an element of both the Conceptual and Structural objects. It means that the rules related to the Geometrical aspects are common to those two characteristic groups.

The Geometrical characteristics are usually simple to be identified. The Entity object of Fig. 7(a) presents some of those characteristics:

(Ex.9) Bolt length. That characteristic relates to the Entity form and is associated to the space occupied by the object; and

(Ex.10) Bolt thread: Standard Z¹⁰. This example presents the same Geometrical aspects of (Ex.9). Nevertheless, it is represented by another set of Geometrical characteristics (e.g. pitch, mean diameter, thread angle, etc).

The Geometrical characteristics are associated to the Structural spatial definition of a certain Entity. They are very important to the design activity, since they show the designer the physical aspects of the developed product. However, the Geometrical characteristics expose particularities of both Conceptual and Structural definitions, which are intimately related. In many situations, a careful analysis of Conceptual aspects, even by experienced designers, is not sufficient to fully understand the artifact being developed. Hence, it is necessary to have a correspondent Structural representation. The inverse situation also happens, i.e. sometimes a Structural representation will only be well grounded with a correspondent Conceptual description.

Entity Objects Tree

The examples of Fig 7(a) (i.e. (Ex. 1) to (Ex. 10)) show that sets of characteristics are joined to represent a specific Entity object. It can be observed that by varying the ConceptualOptional or StructuralOptional characteristics another Entity is generated. Variations on an Entity set of characteristics are represented by its descendants. Figure 5 illustrates that situation where ParEntity and ChiEntity objects represent the Entity ancestors and descendants, respectively. Note, also, that the Conceptual and Structural objects have a behavior similar to Entity (i.e. they also inherit characteristics to form its representation). Figure 5 shows ParConceptual and ChiConceptual objects as the Conceptual ancestors and descendants. Analogously, it shows ParStructural and ChiStructural objects as the Structural ancestors and descendants. Figure 6 extends that idea to all the other objects.

Consider the situation where Entity objects are aggregated to form a new Entity object, as in the example of Fig. 7(b). Entity objects are grouped and treated as a single object. Fig 7(b) shows an Entity to represent a bolt and another Entity to represent its nut. They are aggregated to form a single object (bolt with nut). This new Entity object has its structure presented in Fig. 5, which is also formed by Entity aggregation (e.g. DecEntity). Similarly, the Conceptual and Structural objects have their structures formed by object aggregation (e.g. DecConceptual and DecStructural, respectively). This idea is also extended to the ConceptualOptional, Essential, Geometrical, Topological and StructuralOptional objects (Fig. 6).

The proposed structure, based on Essential and Optional sets of characteristics, addresses the Entity object tree to avoid knowledge redundancy within the DPS. Once a set of characteristics are defined, their properties can be inherited, and their redefinition is minimized. Another important fact is that smaller objects are easier to be incorporated as other object components. The proposed structure allows multiple inheritance and also objects composed by aggregation of several other objects (Bento, 1992), as shown in Figs. 3 and 4, where there are double arrow head. An Entity not only inherits and transfers its characteristics, but also is composed of other objects and contributes to compose other objects.

Object Linking

The proposed model treats Entity, or any other object, with a private representation, in a sense that its existence is defined independent of the other objects in the world around it. Nevertheless, the object interacts with the surrounding world and, in certain situations, it contributes with its representation to compose other Entity objects. Those interactions are provided by the Link object, which are created either dynamically by a designer interaction or automatically by SAE (Synthesis, Analysis and Evaluation) model cycles (Feijó, 1988). Conceptually, the associations represented by the Link object are specialization or decomposition cases (i.e. IS_A and HAS_A). Situations such as term_of, transformation_of, etc. usually present in Solid Modelers ((Fischer, 1991) and (Feijó et al., 1991)) are treated as approximations of the mentioned cases and are conveniently represented. An interesting Link feature concerns the ability of the objects to view their neighborhood. Each object around a Link knows the other objects it is associated with.

The task of establishing the association between its pair of objects is assigned to the Relation object. The Relation defines which object is source or target and the relation type (i.e. IS_A establishes a specialization and HAS_A relates to object decomposition). Additionally, the Link between two objects activates the target representation whenever the status Relation is assigned to CURRENT. This mechanism allows the objects involved in the Link to observe their respective neighborhoods, even if not belonging to the CURRENT representation. The described situation is presented in Fig. 8 where Entity pairs share the same Link. The Links are represented by the line that connects the pair of Entity objects.

Consider Entity_R (reference) object of Fig. 8 to exemplify the Link Relations of the four possible situations.

Link_RA: Entity_R inherits Entity_A (ancestral) characteristics. Entity_A is an object independent of its descendants, while Entity_R needs its ancestral characteristics in order to establish its own characteristics. Thus: (1) Entity_R is the source, (2) Entity_A is the target and (3) IS_A is the relation;

Link_RC: Entity_C (component) contributes to compose Entity_R. Entity_C is an object independent of those objects it contributes to establish their specification, while Entity_R needs its components characteristics to establish its specification (which are also part of its characteristics). Thus: (1) Entity_R is the source, (2) Entity_C is the target and (3) HAS_A is the relation;

Link_DR: It is analogous to Link_RA. Entity_D (descendant) inherits Entity_R characteristics. However, Entity_R is an object independent of its descendants. Thus, (1) Entity_R is the target, (2) Entity_D is the source and (3) IS_A is the relation; and

Link_OR: Is analogous to Link_RC. Entity_R contributes to compose Entity_O (owner). However, Entity_R is an object independent of those objects which it is part of. Thus, (1) Entity_R is the target, (2) Entity_O is the source and (3) HAS_A is the relation.

Note that Entity_R is the source in Link_RA and Link_RC, while it is the target in Link_DR and Link_OR. The object that participates as the source object is predominant in the Link (i.e. it is the object that incorporates the target characteristics to establish its own representation). The Entity participation in a Link, or of one of its objects, is determined by a pair of information. (i.e. whether it is a source or target object and the relation type, IS_A or HAS_A).

Figures 5 and 6 show some Link examples. In Fig. 5 it can be observed the Link between an Entity and the objects represented by its DecEntity. The Entity object has as part of its representation many other Entity objects, referenced by the double arrow head to DecEntity. The section below presents other features of the Link object.

Link Scope

Entity, or one of its objects, has a specific representation within the knowledge base. However, the Link allows the Entity to participate in the composition of many other objects and to contribute with its characteristics to establish specific characteristics to the requiring object. Often a particular Entity participates with its representation to compose other different objects. As an example, consider in Fig. 9(a) the object Entity_O1. Note that Entity_R is a component of object Entity_O1. Note that Entity_R is also an Entity_O2 component. However, Entity_O2 is not an object being studied since it is not within the Entity_O1 current scope. Thus, Link allows Entity abstraction (e.g. Entity_R), by defining which Entity object Entity_R contributes with its representation. Entity_R and its components, Entity_C1 and Entity_C2, can contribute to represent many other Entity objects.

Objects Assembly

In the case where the objects around a Link have Structural representation the interface region needs special attention. The Link incorporates the Assembly object properties in order to deal with the interaction among those objects spatial form. Sometimes it is necessary to apply geometrical transformations in order to guarantee a proper interface. Those transformations do not affect the Entity, which keeps its own coordinate system and geometrical form.

Assembly stores the spatial properties related to a union of Entity objects, by using the Link position_target and direction_target vectors¹¹. Thus, the Assembly rules are stored in the Entity object formed by the union.

Each Entity has its own origin and spatial orientation. The Assembly adopts as its origin the source Entity (i.e. the object that contains the component). For instance, consider the example of Fig. 10, where Entity_R is the source and Entity_C is the target related to the Link_RCRelation. The origin of the pos_target vector, which determines the Entity_C position relative to Entity_R, has the same Entity_R origin and its extremity is the Entity_C origin. The dir_target vector, which indicates the Entity_C direction relative to Entity_R, has the Entity_C origin. Entity_C is subjected to geometrical transformations in order to match its orientation with dir_target vector. Assembly does not take into account the Topological or Geometrical aspects of the Entity objects being considered. Assembly is the spatial representation of two solids that share a common part (e.g. face, edge, etc.). Both solids keep, thus, their Topological and Geometrical definitions as they had before the Assembly. The pos_target and dir_target vectors have to comply with certain StructuralOptional dimensional rules, relative to Entity_R and/or Entity_C.

Active Entity Contexts

The preceding sections describe the ability of Entity, or other object, to represent a set of specific characteristics. In order to guarantee the objects integrity, there are means of treating the interactions among them. However, there are still some open questions. They are related to the properties organization that the Entity object has to represent its characteristics in a friendly manner. Thus, selective behaviors, relative to set of characteristics, are added to the Entity representation and, to cope with this problem, the Link incorporates the Context object. It guarantees a complete organization of the object characteristics, according to the desired semantic. The following topics show in more detail the importance of the Context object.

Context Scope

Context is an object that allows the designer to organize the Entity components according to specific knowledge areas, different building processes, technical standards, etc. Thus, the designer has freedom to organize the Entity according to different Contexts. However, an excessive number of groups within the Context can jeopardize the design process. Figure 11 illustrates Context examples in some situations. Each Context represents an abstraction layer relative to the objects present in the Link.

Entity Context

The Link Contexts between an Attribute and an object are associated with the Attribute value (and unit). The Entity Contexts are present in the Links it has with its ancestors and components (i.e. those Links where the Entity object is the Relation source). This situation is illustrated in Link_RA and Link_RC of Fig. 8. Each of those Links presents a Context group, which contribute to determine the Context relative to Entity_R.

Another interesting feature about the Entity Context concerns the situations where a set of characteristics are related to a specific Context. In this case, the Entity object behaves according to that specific Context. Consider, for instance, MANUFACTURING as the Context of interest in Fig. 11. The status of this specific Context is CURRENT and all the others have a WAIT status. Only the properties relative to MANUFACTURING are represented. It means that a certain Entity performs only valid operations within a specific Context. Note that, for this Context, there are no Conceptual parameters.

Set of Entities Context

It is quite important to have Context associated to a set of Entity objects. An object representation could be required to compose an Entity within a Context, while in another Context could contribute to compose different objects of that Entity.

In a set of connected Entity objects the CURRENT Context determines the active properties within each Entity. Consider, for instance, Entity_O1 in Fig. 9(a), which has Entity_R in its composition. Entity_R has Entity_C1 and Entity_C2 as its components. Taking the Context of interest in Entity_O1, Entity_R is also CURRENT, however among its objects only Entity_C1 contributes to Entity_O1 representation within the active Context. Although Entity_C2 contributes to compose Entity_R, it is not CURRENT, as Entity_C2 does not have any characteristic relative to the active Context. A similar situation is shown in Fig. 9(b) but considering the Context of interest in Entity_O2. In this case only Entity_C2 contributes to Entity_O2 representation. Thus, a certain Entity_Y object is CURRENT in a Link, only if: (1) it is component or ancestor of another object in the Link (e.g. Entity_X); (2) it contributes to Entity_X representation; and (3) one of those characteristics is CURRENT in Entity_X.

Consider the Entity set of Fig. 7(b) and the representation of Fig. 9. Take Entity_O1 as the bolt and Entity_O2 as the nut (Fig. 9(b)). Consider also that Entity_R represents the thread characteristics (e.g. pitch, mean diameter, etc.)¹² relative to Entity_O1 and Entity_O2 (i.e. a standard that defines the thread dimensions common to both Entity objects). Entity_C1 could represent the tolerance characteristics (MANUFACTURING Context) to the bolt, while Entity_C2 could represent the nut equivalent characteristics (same MANUFACTURING Context). Therefore, if MANUFACTURING is the CURRENT Context, Entity_O1 and Entity_O2 properties are represented as in Fig. 9(a) and Fig. 9(b), respectively.

Context object allows the designer to consider the Entity object within a specific Context. Hence, an Entity process or activity is visible by all other objects within the Context. This situation is illustrated in Fig. 12 where continuous lines, both to Entity and to Link, represent the objects that have CURRENT status (e.g. ELECTRIC Context relative to Entity_A). Entity inheritance is represented as a characteristic of the Entity itself. Even if an object (e.g. Entity_G) does not have Conceptual or Structural characteristics, related to the CURRENT Context, it could belong to the process (e.g. ELECTRIC), if one of its objects, Entity_I, has those characteristics. Therefore, a Context is heavily represented by Entity objects that have in their Conceptual or Structural object, Attributes that belong to the CURRENT Context.

Conclusion

The proposed Entity structure represents artifact characteristics in a robust object network. However, its specification is achieved with the reduced number of available network object types. The artifact characteristics are described by the Attribute object. Its properties are transferred through inheritance mechanisms, thus establishing a dependency network of represented properties.

The proposed architecture presents the Entity object, to treat the artifact characterization, which is decomposed in other objects, where essential and optional aspects are specified. These aspects are stored in the Conceptual and Structural parameters.

The objects that are part of a hierarchical and decomposition tree are associated among themselves through the Link. It treats the type of Relation between pair of objects. Assembly deals with the spatial aspects of a Relation between components that have Structural definitions. The Context object is responsible for the Entity contextual organization.

The model incorporates the characteristics proposed by Goel and Pirolli (1989). These characteristics are represented by objects which are treated as intelligent nodes (Brooks, 1991), where the tree resulting from those nodes' union forms a consistent platform to the development of the design activity. This object tree is broad and flexible, as suggested by Prates (1993). It also presents a consistent proposal to the "functions vs. form" dilemma, which was argued by Bento (1992). Hence, the model is adequate to explore the DPS design cases, e.g. design types defined by Gero (1990).

The model described in this article (Barbosa, 1996) has been inferred from the developments of a real application (GerLay – A System for Furnace Layout Generation), which makes use of many of the presented ideas (Barbosa, 1997a) (Barbosa, 1997b) (Barbosa et al., 1997). The model is being used as a basis to the design activity in a distributed environment (Barbosa et al., 1999).

Acknowledgement

The authors are grateful to CNPq, and CAPES, Brazilian research councils, to CENPES/Petrobrás, the Brazilian Oil Company and also FCT and ICCT from Portugal, for their financial support.

Paper accepted December, 2002. Technical Editor: Atila P.Silva Freire

• ACIS, 1998, "ACIS 4.0 Online Help CD-ROM", Spatial Technology Inc., Colorado, USA.
• Barbosa, C.A.M., 1996, "Um Modelo para a Representação do Aspecto Evolutivo do Processo de Design" (in portuguese), MSc Thesis, Mechanical Engineering Department, PUC-Rio, Brazil.
• Barbosa, C.A.M., 1997a, "GerLay Manual do Sistema" (in portuguese), Petrobrás/CENPES, Rio de Janeiro, Brazil.
• Barbosa, C.A.M., 1997b, "GerLay Manual do Usuário" (in portuguese), Petrobrás/CENPES, Rio de Janeiro, Brazil.
• Barbosa, C.A.M., Feijó, B. and Dreux, M., 1997, "Um Tratamento para História de Design em Sistemas de CAD" (in portuguese), XVIII CILAMCE 97, Vol. IV, pp. 1925-1932, Brasilia, Brazil.
• Barbosa, C.A.M., Feijó, B., Dreux, M., Bento, J., Melo, R. and Scheer, S., 1999, "Distributed Data Model for Collaborative CAD Environments Based on Design History", Computer Science Monograph, PUC-RioInf.MCC22/99, Rio de Janeiro, Brasil.
• Bento, J., 1992, "Intelligent CAD in Structural Steel: A Cognitive Approach", PhD Thesis, Civil Engineering Department, Imperial College of Science, Technology and Medicine; London, UK.
• Brooks, R.A., 1991, "Intelligence Without Representation", Artificial Intelligence, 47(1-3), pp. 139-159, North-Holland, The Netherlands.
• Feijó, B., 1988, "Fundamental Steps Towards An Intelligent CAD System In Structural Steel", PhD Thesis, Civil Engineering Department, Imperial College of Science, Technology and Medicine; London, UK.
• Feijó, B., Fischer, R. and Dreux, M., 1991, "Better Criteria for the Development of Solid Modelling Software", 2th International Conference on Reliability and Robustness of Engineering Software, RRES 91, Milano, Italy.
• Feijó, B. and Fischer, R., 1992, "Cognição e Percepção 3D em Modeladores de Sólidos" (in portuguese), Brazilian Symposium in Computer Graphics and Image Processing, VI SIBGRAPI, pp. 97-103, Brazil.
• Feijó, B., Lehtola, N., Bento, J. and Scheer, S., 1996, "Reactive Design Agents in Solid Modelling"; Artificial Intelligence in Design'96, pp. 61-75, Kluwer Academic Publishers, The Netherlands.
• Fischer, R., 1991, "GeneSys, Sistema Híbrido para Modelagem de Sólidos" (in portuguese), MSc Thesis, Computer Science Department, PUC-Rio, Brazil.
• Gero, J.S., 1990, "Design Prototypes: A Knowledge Representation Scheme for Design", AI Magazine, 11(4), pp. 27-36, American Association for Artificial Intelligence, CA, USA.
• Goel, V. and Pirolli, P., 1989, "Design Within Information-Processing Theory: The Design Problem Space", AI Magazine, pp. 19-36, American Association for Artificial Intelligence, CA, USA.
• Kern, D. Q., 1950, "Process Heat Transfer", McGraw-Hill Book Company.
• Maher, M.L. and Li, H., 1994, "Learning Design Concepts Using Machine Learning Techniques", Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 8(2), pp. 95-111, Cambridge University Pres, Cambridge, USA.
• Mäntylä, M., 1988, "An Introduction to Solid Modeling", Computer Science Press, Maryland, USA.
• Oxford, 1969, "The Oxford English Dictionary", Oxford University Press, London, UK.
• Prates, A. J., 1993, "Fundamentos e Especificações de Um Ambiente de Design Baseado em Lógica e Objetos" (in portuguese), MSc Thesis, Civil Engineering Department, PUC-Rio, Brazil.
• Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W., 1991, "Object-Oriented Modeling and Design", Prentice Hall.
• Scheer, S., 1993, "Uma Análise Crítica Sobre o Tratamento Cognitivo de Design em Sistemas de CAD" (in portuguese), DSc Thesis, Computer Science Department, PUC-Rio, Brazil.
• Shigley, J.E. and Mischke, C.R., 1989, "Mechanical Engineering Design", McGraw-Hill Book Company, New York, USA.

2

Notation adopted in

Fig. 1: (1)

Identification identifies the object

Attribute; (2)

Method stores

Attribute processes and (3)

Link corresponds to

Attribute associations.

3

More information about thermal processes can be found in (Kern, 1950).

4

Notation adopted in

Fig. 3: (1) Chi

Attibute is an abbreviation of Children

Attribute, which represents the

Attribute that inherits the

Attribute

_Q'' characteristics and (2) the arrows indicate

Link association direction; in the case of double-arrow head, more than one element could be referenced.

5

The

History object in

Fig. 4 represents the

Entity object evolution..

6

Notation of

Fig. 5: (1) Dec

Entity is an abbreviation of Decomposition

Entity, which represents the set of

Entity objects that form a certain

Entity object; and (2) Par

Entity is an abbreviation of Parent

Entity, which corresponds to the

Entity set that transfers its characteristics to a certain

Entity object. They are better explained later in this article.

7

ConOptional e

StrOptional, in

Fig. 6, are abbreviations of

ConceptualOptional and

StructuralOptional, respectively.

8

The examples are sequentially numbered along this article (Ex.1 to Ex.10).

9

The bolt thread length may have the following values: Total Thread (i.e. the whole body length of the bolt has thread) and Partial Thread (i.e. only part of the body length has thread). More technicalities about it can be found in (Shigley and Mischke, 1989).

10

Details about these technical standard are found in (Shigley and Mischke, 1989).

11

In this model the vectors are treated as objects.

12

Details can be found in (Shigley and Mischke, 1989).

Publication Dates

• Publication in this collection
  18 Mar 2004
• Date of issue
  Mar 2003

History

• Received
  Dec 2002