Modelling architectural design information by features : an approach to dynamic product modelling for application in architectural design

ion mechanisms By definition, a model is an abstraction of reality. A.bstraction means leaving out details of information that are irrelevant for the context in which we look at reality. In order to acquire a more structured representation of reality, several mechanisms are used to enhance the abstraction of reality with concepts that derive from the way we think about reality. These abstraction mechanisms generally define relationships between types of objects. Three such relationships are briefly explained here. Generalisation is the abstraction of object-types which leads to the definition of a more general type of object by eliminating attributes from the object-type definition. The car object-type could be generalised into the type of object that we call vehicle. If we want the object-type vehicle to be defined general enough to include nonmotorised vehicles as weU, we would have to eliminate the attribute fuel from its definition. The relationship between the two object-types is an 'is a' relationship, so that any object of type car is an object of type vehicle. Specialisation is the reverse mechanism of generalisation, meaning that by adding attributes to an object-type's definition, a new, specialised object-type can be defined. For instance by adding an attribute woman_or_man to the definition of vehicle we could define a new objectModelli11g Architectural Desig11 lnjormatiotl by Features Concepts of prod11ct modelling 2.2 type for the concept of 'bicycle', with the result that, like cars, any object of type bicycle is also an object of type vehicle. The object-type vehicle is called the super-type (or parent) of the object-types car and bicycle, which in turn are the vehicle's sub-types (or children). The attributes that cars and bicycles have in common are defined in the vehicle object-type, and are derived from it by its subtypes. This derivation of properties is called inheritance, and applies to attributes describing an objects state as well as to attributes describing behaviour. Many 00 methodologies allow an object-type to inherit attributes from more than one super-type. This is called multiple inheritance. Recent developments, however, show an increasing understanding that multiple inheritance will easily lead to over-complexity in software and data-models. For this reason, the newly defined 00 programming-language Java, for instance, supports only single inheritance, which is generally not regarded as a shortcoming. Another abstraction mechanism is called aggregation. Aggregations are used to indicate how parts compose into a whole. Its reversed mechanism is called decomposition. Both abstraction mechanisms help dividing the complexity of a given concept into manageable parts, allowing both a bottom-up (aggregation) and top-down (decomposition) approach to structure the information in the hierarchy of entities. In the above, the term attribute has already been used; defining the attributes of an object-type, where these attributes represent the parts of the object-type, is an act of decomposition. The creation of a new entity definition by collecting a number of entity-types and defining them as the 'part-of attributes of a new concept, is an act of aggregation. Examples of this kind of abstractions can easily be given based on our daily environment. Wherever the phrase 'is part of can be used, an aggregation can be defined. When 'has a' is applicable, a decomposition relationship can often be used: a book has pages; a page has two sides. However, care should be taken with the decision to call each 'has a' relationship a decomposition. The cover of the book has a colour, yet the colour is not part of the book. Usage of a decomposition relationships is only valid when the reverse, the aggregation relationship, can also be applied. Finally, the relationships between object-types that are not generalisationor aggregation-relationships, are called associations between object-types. This type of abstraction mechanism helps ordering information by allowing the specification of logical relationships between groups of information defmed in object-types. The example of the book and the colour is such an association relationship, where the book can be associated with the colour and vice versa. An architectural example is the association between spaces and walls. Relationships between object-types are labelled by means of a name for the role of the relationship. This role name is often a verb: the walls bound the space. This implies a direction of the relationship, which depends on the verb chosen to name it. However, an association relationship can often be reversed: the space is bounded by the walls. This inverse relationship is sometimes modelled explicitly, but in many approaches implicitly available from the product data model. Modelli11g Architectllral Design Information by Feat11res 2 The Product Modelling Approach 2.3 Research and developments in Building & Construction Product modelling research-projects In the last two decades of this century, many national and international research projects have been investigating and developing the possibilities of product modelling methodologies in the domain of the Building & Construction industry. These projects had varying backgrounds and objectives. Among the first of these developments were the Finnish RAT AS project [Bjork 1989] and the General AEC Reference Model (GARM) [Gielingh 1988]. The GARM was one of the ftrst attempts to define an international standard for product modelling. Its main contributions to the field were the distinction of functional unit and technical solution as individual elements in the product model, and the notion of stages of product data giving data a particular status, like 'as designed', 'as constructed', 'as used', etcetera. In the first half of this decade, a number of EC funded projects have been developed on the basis of these early concepts. Each of these projects departed with a specific objective for modelling building information and with limited scope. The ATLAS project [Tolman and Poyer 1995] was developed within the problem context of large scale engineering. The COMBINE 1 and 2 projects [Dubois et a!. 1995; Augenbroe 1995] started from the domain of energy and HV AC engineering, developing the Integrated Data Model. CIMSTEEL [Watson and Crowley 1994, 1995], as the name suggests, developed its Logical Product Model for structural steelwork frames . The COMBI project [Scherer 1995] mainly focused on information modelling for the support of structural engineering and foundation design. The work of Eastman et al. [1995a] on the Engineering Data Model (EDM) is also to be classified as a product modelling development. Because this research, like the project described in this thesis, addresses more deeply the specific requirements of design support, it is discussed in chapter 3, after these requirements have been outlined. Also the BAS-CAAD project [Ekholm and Fridqvist 1997] develops a new approach to product modelling in a design context that is discussed at the end of chapter 3. Efforts and results in standardisation The international standardisation efforts in the area of product modelling have been concentrated in the last two decades in the developments in the ISO 10303 project, also known as STEP: STandard for the Exchange of Product data. Recently, another development has been started with a similar objective, but initiated by the CAD industry, under the name IFC: Industry Foundation Classes. STEP develops its standard conceptual data models at two levels: Integrated Resources and Application Protocols. The Application Protocols (APs) are conceptual models containing data deftn.itions that facilitate the modelling and exchange of data Modelling Architectural Design Information by Feature.< Research and developmwls in B11ilding & Conslmdion 2.3 between a particular range of applications5 in varjous engineering processes. Such an AP is specific for the domain formed by the range of applications; it forms a common basis for exchange of data only between the applications that fall in this range. In contrast to the APs, the Integrated Resources (IRs) are designed to be application independent. They are designed to serve as a common basis for the APs, in order to facilitate data exchange between the various ranges of application. Because the IRs are independent of a particular application domain, they are semantically poorer. All definitions of data that represent domain specific knowledge are included in the A.Ps. Apart from the development of the conceptual data definition models, the STEP developments have delivered three other categories of results. Firstly, the conceptual data models in STEP are formally specified by means of a data definition language, developed in STEP, called EXPRESS [ISO TC184 1994c]. This language has a graphical counterpart, called EXPRESS-G, which is also one of the notation techniques used in this thesis (see appendix A for the syntax of this graphical notation technique) . Secondly, the actual data models based on the data definitions specified in EXPRESS must be stored in a neutral file format that can be read by the communicating computer applications. For this format another language is defined, called the STEP Physical File format (SPF) [ISO TC184 1994a]. Finally, the SDAI is the Standard Data Access Interface. It specifies an implementation method for a functional interface to data models that are defined using the EXPRESS language. These methods are specified in a manner that is independent of any programming language. Implementation of the methods is called language binding and is being developed in languages like C, C++, and Fortran. The co-ordination between the definition of the APs for the various domains in a discipline, e.g. AEC, is currently not well developed. For exchange of data from one AP to another, applications must rely either on the usage of the Integrated Re