The abstraction notion is central to understanding the representational requirements of Design activities. Put very simply, the use of abstractions during design gives the designer freedom to ignore certain details, for the time being, and to determine or design the "big picture" aspects of his design. The use of abstractions allows the designer to freely shift its focus from one part of the design to another or from one Level of Detail (LoD) to a different one.
An abstraction is simply an entity's representation with some of the details omitted. The omitted details can be attributes, relationships among sub-entities or sub-entities. For instance an abstraction of a column could be just the shaft with the capitel and base omitted.
While the use of abstractions is invaluable in any Engineering or Architecture field its explicit formulation was achieved in Software Engineering (SE). This was the case for two reasons:
The SE technology that handles abstractions is known as "Object Oriented Programming" (OOP) and its data management aspects as "Object Oriented DataBase Management" (OODBMS) whose databases being denoted as OODBs. Unfortunately the Smalltalk team, which pioneered the use of these techniques in the US, chose the term object to refer to such abstractions. The choice is very unfortunate since the word object has many meanings or semantics in English and many other languages. This causes many people to draw many erroneous implications and associations regarding such objects. One particularly pernicious confusion, exploited for marketing reasons, is between systems which are superficially object oriented and those which are the real thing. The best way to clearly and correctly understand the object oriented technology is to remind oneself that we are talking about Abstraction Oriented Programming (AOP) and Abstraction Oriented DataBases (AODBs).
Abstractions in OOP and OODBMSs are represented by the class concept. A class is a data structure together with its methods. The latter are software algoritms which specify the legitimate manipulations or operations that can be performed on the class' data structure.
The class' data structure (DS) can have attributes, that is variables with specific values: other sub-components names or links (pointers) to sub-components. That is, either class specific variables or sub-components referenced by either name or address. Some or all the elements of a class DS can be undefined or even missing. A class with a DS fully defined is called a concrete class. One with a DS fully undefined is called an abstract class. In practice, especially in the early stages of design, all classes will be partly abstract. That is have one or more undefined DS components.
A given class data structure can be populated with distinct sets of values. The entities generated by plugging in the distinct sets of values in the class definition are referred to as class instances or briefly as instances. The instances are the objects of OOP.
In order to get tools that would meet with enthusiastic acceptance by the Architecture Engineering & Construction (AEC) community we need to formulate sound Systems Architectures and make sure that while doing so Built Environment Architects be extensively and intensively involved.
It has been known for at least the last four decades that the foundation of a good Systems Architecture (SA) is a "good" conceptualization of the intended application area.
In the last three decades it has become clear that a conceptualization of an application area is a set of classes, in the object oriented programming sense, expressing the application's concepts or abstractions.
It is very important that such conceptualizations be minimal and complete. A conceptualization is complete if its collection of classes allows the expression of all the functions (functionality) specific to the particular application area. That is, the conceptualization "covers" the application area. A conceptualization is minimal if it uses the smallest number of independent class taxonomies (class inheritance hierarchies) that span or cover the application area.
According to modern object oriented programming & database notions the formal expression of a conceptualization is the Object Oriented DataBase (OODB) schema. I.e. a formal statement of the classes and their inheritance hierarchies. The latter are taxonomies of the conceptual types involved. Besides the inheritance mechanisms OODB technology provides a powerful construction or aggregation mechanism which allows the creation of "collection" classes. The latter are particularly useful in modeling Architectural designs.
An OODB schema defines as well the relationships among the different objects involved. This schema coupled with the notion of object identity, establishes object relationships "by reference" --I.e. using pointers to other objects--, which yields a particular structure with three fundamental features:
Several authors (Hongley Zeng et al.) in "Natural Language Processing" define the term ontology as "the specification of a conceptualization" where the conceptualization involves the class taxonomies as above. This definition of ontology is closely related to the traditional philosophical definition of ontology as a definition of a set of terms providing a consistent view of reality. The reality involved in information systems is the limited and constrained one chosen by the systems designer.
We can then say that a Systems Architecture for tools in a specific application area will be good if it is based on a compact ontology, such an ontology will be expressed or codified by an OODB schema which is both complete & minimal. Completion being the property of the OODB schema to completely span the application "universe of discourse". I.e. to allow posing and answering all well formed questions for the application field.
Some of the reasons why Systems Architectures based on such compact ontology (ontology for short) are good architectures are:
We are now able to specify a program for greatly ameliorating the quality of the CAD tools that can be made available to the AEC community. The first step of this program is to formulate an ontology for Architecture. The slide presentation given in the next section presents an OODB schema, proposed in a recent GSD thesis, which is a promising candidate for a powerful ontology for built environment Architecture. This ontology could be a good base for AEC Industry CAD tools.
Finally, before leaving this topic let us say a few words, on why current CAD systems which, in general, rely on Relational DB schemas, can not possibly be good tools for the Design phase. The fundamental difficulty with Relational databases is also their fundamental advantage. Namely, Relational systems rely on keys to establish connectivity among the entities of the database. Keys are concatenation of one or more attributes of the entity being addressed. This method of addressing is, from a strictly computer programming point of view, superior since it prevents application programs from gaining direct unsupervised access to the computer memory hierarchy. It, therefore, eliminates a large class of program malfunctions. Key based addressing can not be used if the abstractions represented by the database entities are partially defined. In fact, partially defined entities will have some undefined attributes. These in turn, will result in undefined keys. In particular relational DBMSs have algorithms which check for key acceptability. Such algorithms do not accept null value keys which result from undefined attributes. In other words a CAD system that relies on a Relational DBMS will require that all entities in the database be fully specified in order to work. This means that the DB representing the design must correspond to a complete design. Therefore CAD systems based on Relational DBMSs can only handle the final phase of design, that is, document production.
A description of the Sola-Morales AEC Ontology, as refined in GSD-6306 Spring 2004, is found at AEC Ontology
Copyright Ugo O. Gagliardi 2008 - 2009