The paper describes the first steps taken in the search for a central object model presenting all possible data, concepts and operations concerning the architectural design process.  From the early design stage, an architectural model can be built on computer.  A central object model of this process is essential: a model describing geometrical shapes, spaces, building elements and user activities, together with all the basic operations these entities can undertake.  The model could provide the necessary information for the performance of tests to assist the designer (energy calculation, stability check, costs ...).  Appropriate interfaces between the object model and existing software packages allow different actors in the design process to make use of the model’s data.
First, the conceptual model for CAAD in the design process is described. The second part deals with the methodology used for developing the object model: M.E.R.O.DE (Model-driven Entity-Relationship Object-oriented Development) proves to be a firm base to start our design.  Finally, we present some aspects of the first prototype for such a central object model.

 A conceptual model for CAAD
 The M.E.R.O.DE methodology for object-oriented conceptual design
 Elaboration of the core object model for architectural design
 Conclusion
 References

Keywords: object model, CAAD, object oriented, M.E.R.O.DE

Architects use a great variety of concepts while designing: geometrical shapes, spaces, building elements, user activities, structure, etc.  Within this vocabulary, different design approaches are possible. Some designers follow a top-down procedure, others proceed according to a bottom-up strategy.  Whatever the approach, it goes without saying that commitments made in the first stage of the design process have the biggest impact and are the hardest to undo later.
Until now software packages offer a broad range of computational tests to evaluate an architect’s creation in the final stage: adequate tests capable of handling rough data and estimates are rare, where exactly thóse tests could help steer the design process in the first stages.  Additionally, we should not ignore the fact that in today’s practice the computer only comes into play when the design is more or less completed.  Thus, calculation programmes and the drawing packages themselves should concentrate more on this first stage of sketching and exploring possibilities.  At least the unproductive translation of a design made by hand into a digital version would be avoided.

Fig. 1. The conceptual framework designed by Neuckermans [1].

A crucial element in this framework is a central information structure to glue everything together.  Currently there seems to be an agreement  that if any modelling technique would be able to solve this complex problem, it
would be an object-oriented one.  Already a considerable amount of research on building models has been done.  But, as stated by Marcel De Waard [2] ’How can product models and product type models help a designer during the design stage?’.  A lot of models describe a building at the end of the design stage, where it is not subject to change anymore.  From this point of view, modelling on a high semantic level in the early design stage becomes necessary.  With the described conceptual framework in mind, it became quite a challenge.

This central object model is to be used by several actors.  On the one hand, CAD packages use it to hold track of all data and operations concerning the design and the design process.  Tools to instantiate the "empty" object model and to collect information from it later on are to be constructed.  On the other hand, software packages to compute tests on the architectural model and every building partner’s software must be able to get the appropriate data from it and, if necessary, put adapted data back into the central model.  Interfaces to this ‘external’ software make the necessary links.
The core object model itself is not seen by the user. In the core object model only elementary operations are defined and data consistency is the top priority.  For this reason, all redundant information that can cause inconsistencies is avoided.  Appropriate views on the object model provide a protecting shell between the model itself and the end user, who can be any actor in the design process. Smooth handling of data, complex operations consisting of elementary ones and user-friendliness are concentrated in this shell.  At the moment, research is focusing on construction of the core object model.

An extra reason for developing a core object model mastering architectural design, was found in the final year dissertations at our department of architecture.  Every year, students contribute to the CAAD research by means of elaborating a creative idea concerning the design process.  In the last years, students explored aspects as the use of  3-dimensional grids, all kind of computational tests, stereolithografy, virtual reality, case based reasoning and so on.  By providing these students with a basic object model, a lot of redundant work can be avoided and the different efforts can be more easily combined and fitted into our conceptual framework.
 

2. THE M.E.R.O.DE METHODOLOGY FOR OBJECT-ORIENTED CONCEPTUAL DESIGN

We have chosen to work with M.E.R.O.DE, a methodology for designing object models on a conceptual level that has been recently developed [3,4].  The acronym M.E.R.O.DE stands for Model-driven Entity-Relationship Object-oriented Development.  Originating from JSD (Jackson System Development), the ideas that make the methodology a model-driven and object-oriented one have been borrowed from it.

Firstly, it makes a clear distinction between the specification phase and the implementation phase.
The specification phase is entirely object-oriented.  It makes no assumptions whatsoever about technology which will be used for implementing the system. This means that specification is completely conceptual and therefore completely independent of technological aspects of the system.  Both ‘traditional’ implementations and object-oriented ones are still possible.  Thus, tough choices about relative or object-oriented databases, CAD packages and so on are avoided at this stage of the design.  And more important, research is not limited by the chosen hardware and software or delivered to the arbitrariness of a certain software developer.
During the conceptual specification phase, reliability, corrigibility and flexibility are the relevant quality measures, whereas during implementation they are performance, efficiency and user-friendliness.  Persons specifying M.E.R.O.DE systems even need to have no knowledge whatsoever about computer-related matters.  After specification, implementation can be carried out by a computer specialist with minimal effort. This way, the idea that implementation is achieved by transforming the specification and not by elaborating it, is supported.

Secondly, a distinction is made between ‘business objects’ and ‘function objects’.
Business objects correspond to objects which exist in the real world.  Business rules are enforced by defining methods attached to the business objects.  Thus, the business subsystem simulates the real world system (e.g. a car rental company).  When real world rules are modified, only the business subsystem has to be changed.  It can never be influenced by changes in information needs (subject matter of the output subsystem) or by changes in business organisation (subject matter of the input subsystem). In the car rental company ‘car’ and ‘customer’ are examples of business objects.  Next to this business objects, function objects can be of three kinds:

• Input objects gather the necessary information relating to the actual system and send messages to the business objects.
• Output objects gather information from the business objects and present it to the user in an appropriate way, e.g. printing an invoice.
• Information objects hold track of an object’s history.   Because the business model only simulates the real-time situation, this information is necessary e.g. when you need to know how many times a car has been rented in the past in order to perform a car check.

Fig. 2. Different objects in M.E.R.O.DE                       Fig. 3. All possible existent dependent relations
and their connection with the real world.                       in the simplified notation for the ER-scheme

Object type A is existence dependent from object type B, if and only if each object of type A,during its entire life-cycle,
engages in a mandatory relationship with one, only one and always the same object of type B.

As a matter of fact, all relationships in the ER-model should denote existence dependency. In our car rental company, ‘car’ and ‘customer’ can therefore not be linked directly: a car can exist without being rented by a customer and a person does not only exist by means of his renting a car.  Thus, the need of existence dependency should involve the creation of a new object ‘rental’, existence depended both of ‘car’ and ‘customer’.  Why this is so important is made clear in [5].  Next to simplifying consistency checking in the model, existence dependency is a valuable alternative for the sometimes vague concept of the Part-Of relation.
Finally, special attention is given to specification of business constraints.  A distinction is made between two different types of constraints.  Sequence constraints (e.g. a car cannot be rented before it is bought) are expressed by sequence diagrams (as in the JSD method) or by finite state machine charts.  Data constraints (e.g. a client can only rent 3 cars at the same time) are expressed in a declarative way.  By modelling constraints, the object model itself will be able to maintain integrity, as advocated for building models by Galle [6].  For each phase in the modelling process, notation techniques are well documented in the methodology.

Looking at our conceptual framework for architecture with the M.E.R.O.DE concepts in mind, following accordance can already be found:

• building programmes (upper left): refers to the scope of the problem to be modelled
• design entities and possibly grids (first columns): they define the elements for the business model.  The business objects are on the one hand composed of these elements and on the other hand of the basic operations these elements can undertake.
• tests (third column): function objects gather the necessary information out of the business model and put this information in the appropriate form for handling by an ‘external’ software application, or the function objects themselves perform a test upon the business model and present the output to the user.

The M.E.R.O.DE methodology was considered a firm base in order to start the research on the construction of the central object for architectural design in the early design phase.  In the first stage, constructing the business model is started.  Due to the strict distinction between business modelling and the rest of the model, user input (by using a CAD package), output (architectural drawings, data for computational tests, etc.) and creation of information objects (essential for version control) come in to play in a later research phase.  Different views on the model, depending on the different members of a collaborative design group, do not influence this business model and can be specified later.
 

3. ELABORATION OF THE CORE OBJECT MODEL FOR ARCHITECTURAL DESIGN

In the paper we concentrate on the first, important phase of identifying business object types and constructing an entity-relationship model.  In the ER-model, the static aspects i.e. the objects or entities in the model and the relationship between them are established. From now on, the term object will be used, describing a set of data about something in the modeling domain.   An object may correspond to ‘a physical object, a class of objects such as the concept ‘door’, complex properties of objects, such as shape, or data corresponding to an abstract concept, such as the economic objectives of a project’ [13].
Although incomplete at the moment, some aspects we believe to be important while handling architectural data can be found in this model.  Many of these aspects are also covered in the very enlightening articles by Björk [9], Ekholm [10] and Eastman [11].

3.1. Starting a design

For the moment, we consider a building project at the level of spaces separated by building elements.  Thus, we abstract away the ‘higher’ level (whole building, town-planning ...) and ‘lower’ level that describes construction in detail, HVAC etc.  However, it will become clear that those aspects can and will be covered by the model.  Our aim is not to steer the architectural design process by imposing a certain way of design, nor hamper it by delimiting possibilities.
We think architects must be able to reason on spaces and physical building objects as well as on drawing elements.  It should be noted that a space can exist without the obligation to define its enclosing entities right away.  Vice versa, physical building elements can be placed without defining a closed space.  To say it the M.E.R.O.DE way: the possible objects ‘space’ and ‘physical building element’ denote no existence dependency.  Equally, in the sketching phase of the design, architects can explore possibilities by using mere ‘shape’ objects without connecting them from the beginning with physical building elements or spaces, an idea we find also in the articles by Ekholm[10], Clayton et al. [12].  Globally, the problem and more specifically the exact moment in time for ascribing a sense to drawn elements should be considered carefully: when exactly does a line become a wall for an architect?  Since this question deserves an investigation on its own, we leave it to the designer to define this moment of transformation.

Fig. 4. Main objects of the presented model.

3.2. Space, space boundaries and physical building elements

Existence dependency between objects is obtained by creating so-called contract objects: they establish the necessary links between object space, physical building element, drawing element and activity.  A fine example is the ‘space establishing link’, which links a space and the primary elements that are in one way or another related with it.
A space can be defined by primary elements (space dividing element, vertical circulation, column or beam).  This defining can be explicit (walls, roof and floor around a room make a physical boundary) or rather implicit (four columns denote a sitting area).  The definition of existence dependency is clear: a physical space boundary makes the link between only one and always the same space and only one and always the same space dividing element. From this point of view, a facade is a special case of a physical space boundary that links a space dividing entity with the predefined space instance ‘outside’. The boundary itself can be subdivided into smaller areas: the surface object describes an area made from a homogeneous material.
In addition to the ‘physical space boundary’, the ‘imaginary space boundary’ makes spaces with different ‘degrees of enclosure’ possible [15].   The ‘imaginary space boundary’ is an abstract area, that has no physical counterpart in the real world. Defining a space as ‘a locus of homogeneous activity’ [9] becomes possible.

Fig. 5. From implicit to explicit space, as defined by Von Meiss [14].  The notion of  'imaginary space boundary' supports these implicit spaces.

Fig. 6. Connection between the object 'primary element' (wall, roof, floor, beam etc.) and the object 'space'

Fig. 7. An example of an hierarchy of spaces, made possible by the subspace link.

3.3. Representation of objects

As to drawing elements, it has already been mentioned that they should be offered to the architect designer, without the obligation to assign a ‘meaning’ to them. They also come in to play when a building element receives a geometric description.  Firstly, every building has one or more architectural representations.  In contrast to the space object, the representation for physical building elements differs according to the current design phase.  A wall in sketch design can be represented as a 2D line or a 3D face, whereas further in the design process the same wall will be composed of different layers representing brick, insulation and so on.  In addition to this level-bound representation, other views on the model (plan, cross-section, 3D view etc.) can require other representations.
Thus, a number of  architectural representations are defined as existence dependent objects to a building element type. The object ‘building element type’ refers to a general architectural solution for a building element, without referring to a concrete object in the current design project.  You can consider this as a library of construction types and physical translations of building elements.  Every ‘building element type’ has at least one architectural representation e.g. a parametric cube representing a space or a combination of different line types representing a certain type of insulated wall.

Fig. 8. Architectural and geometric representation of a building element.

In this paper a still developing conceptual model for architectural design in the early design stage was presented.  The purpose was not to present a complete building model, but to show the approach taken, especially the use of the conceptual object-oriented design method M.E.R.O.DE.  Although promising, further investigation and elaboration of the proposed model is necessary. At the moment we are working at the validation of it by means of existing and new architectural designs. Moreover, the possible integration or collaboration with ongoing efforts on international standardisation will be explored.
 

REFERENCES
 
[1] NEUCKERMANS, H., A conceptual model for CAAD, in Automation in Construction, vol. 1, nr 1, pp.1-6, 1992.
[2] DE WAARD, M., Computer aided conformance checking: checking residential building designs against building regulations with the aid of computers, Thesis Technische Universiteit Delft, Den Haag, 1992.
[3] DEDENE, G., SNOECK, M., M.E.R.O.DE.: A Model-driven Entity-Relationship Object-oriented Development, in ACM SIGSOFT Software Engineering Notes, vol. 19, nr 3, 1994.
[4] VERHELST, M., Object-oriented application development with M.E.R.O.DE, course text, Department of Applied Economics, Leuven, 1996.
[5] SNOECK, M., DEDENE, G., Bestaansafhankelijkheid: conceptueel modelleren "volgens contract" (Existence Dependency: Conceptual modelling by contract), in BeleidsInformaticaTijdschrift, vol. 22, nr 4, pp.1-36, 1996.
[6] GALLE, P., Towards integrated, "intelligent", and compliant computer modeling of buildings, in Automation in Construction, vol. 4, pp.189-211, 1995.
[7] ZACHMAN, J.A., A framework for information systems architecture, in IBM Systems Journal, vol. 26, nr 3, pp. 276-292, 1987.
[8] MAES, R., DEDENE, G., Reframing the Zachman Information System Architecture Framework, Tinbergen Institute discussion paper TI 96-32/2, Rotterdam, 1996.
[9] BJÖRK, B.C., A conceptual model of spaces, space boundaries and enclosing structures, in Automation in Construction, vol. 1, pp. 193-214, 1992.
[10] EKHOLM, A., FRIDQVIST, S., Modelling of user organisations, buildings and spaces for the design process, paper CIB W78 workshop "Construction on the Information Highway", 10-12 June, 1996, Bled, Slovene.
[11] EASTMAN, C.M., SIABIRIS, A., A generic building product model incorporating building type information, in Automation in Construction, vol. 3, pp.283-304, 1995.
[12] CLAYTON, M.J., KUNZ, J.C., FISCHER, M.A., TEICHOLZ, P., First Drawings, Then Semantics, in HARFMANN, A. and FRASER, M., (ed.), Reconnecting: ACADIA '94, pp.13-26, 1994.
[13] EASTMAN, C.M., Modeling of buildings: evolution and concepts, in Automation in Construction, vol. 1, pp.99-109, 1992.
[14] VON MEISS, P., Elements of architecture. From form to place, Van Nostrand Reinhold, London, 1990.
[15] THIEL, Ph., Notes on the Description, Scaling, Notation, and Scoring of Some Perceptual and Cognitive Attributes of the Physical Environment, in PROSHANSKY, H.M.,  ITTELSON, W.H., RIVLIN, L.G., Environmental Psychology, man and his physical setting, pp.593-619, Holt, Rinehart and Winston Inc., New York, 1970.
[16] BB/SfB Tabellen 1990, Belgian adaptation of the "CI/SfB Construction indexing manual 1976 revision", Regie der gebouwen, Brussel, 1990.