Element associations

Once the structures from Chapter 4 have been established, the elements of the

supplementary models can be linked directly with each other. This means that information can be exchanged directly between the different elements.

To demonstrate how elements can be linked directly with each other, take the example shown in Figure 18. Say the northern wall on the top floor of the building is represented by the core-model element "WallTN", which is a member of the "Wall" family. The Bill of Quantities has an item "Two-brick walls", and consequently the supplementary BoQModel

53

has a "TwoBrickWall" element. Furthermore, the user added a LineComponent object in an electronic drawing to an IntelligentComponent object. This object is supposed to be a 2- dimensional plan-view representation of e.g. the northern wall of the top and lower floor. In the real world, a wall entity has properties length and height. The "WallTN" object therefore requires two features, length and height.

The quantity of the item "Two-brick walls" is based on the surface area of the wall, equal to the product of the length and height. The quantity of object "TwoBrickWalls" therefore depends on the length and height of object WallTN. The length of object WallTN must be retrieved from the "NorthWallsPlan" object. These dependencies are depicted with dashed lines in Figure 18. Clearly the objects NorthWallsPlan, WallTN and TwoBrickWall must somehow be associated with each other. Somehow therefore, BoQElement objects must be associated with core-model Element objects, which in turn must be associated with

IComponent objects.

Elements associated with the northern top floor wall of project Boschendal Street

BoschendalStreet : Model WallTN : Element FloorPlan : Drawing NorthWallsPlan : IComponent BoschendalStrBoQ : BillOfQuantities TwoBrickWalls : BillOfQuantities length : Feature length : Feature quantity : Feature height : Feature

elements elements elements

Figure 18 Element-Element dependencies

Due to the third abstraction process6 _{these objects are all specialised types of Element} objects. The BoQElement-Element association as well as the Element-BoQElement association can therefore all be described as Element-Element associations. A structure is therefore required that allows different elements to be associated with each other. This will not only cater for Item-Element, or Element-BoQElement associations, but for all Element- Element associations. This means that any Element object can be associated with any other Element object, which allows more flexibility than a structure that only cater for say an items and its associated core-model elements.

It is useful for the association between elements to be bidirectional. This, for example, allows a BoQElement object to reach an associated Element object, while at the same time

54

allowing the Element object to reach the BoQElement objects. The problem is that one Element object can be associated with more than one BoQElement object, while a

BoQElement object can be associated with more than one Element object. Take for example the WallTN object. The TwoBrickWalls object is already associated with it; however a "Paint" item must also be associated with the same WallTN object. Furthermore, the WallTN object is not the only object that contributes to the quantity of the TwoBrickWall object.

As with child-parent relationships, due to the associations between different Element objects being bidirectional, inconsistencies can occur if not managed correctly. However, unlike one-to-many child-parent relationships, these associations are many-to-many relationships. They can therefore not be controlled using mappings. Consider the objects in Figure 19. The associations between them are indicated with arrows. Each object is also listed together with its associated objects below the diagram.

WallTN WallTInner WallUnpaintedIn TwoBrickWalls OneBrickWalls WallPaint

WallTN : WallPaint, TwoBrickWalls

TwoBrickWalls : WallTN

WallTInner : OneBrickWalls, WallPaint OneBrickWalls : WallTInner, WallUnpaintedIn WallUnpaintedIn : OneBrickWalls

WallPaint : WallTN, WallTInner

Figure 19 Many-to-many Element-Element relations

Adding an association or removing it is in every case a two step process. Say, WallTInner has to be associated with TwoBrickWalls instead of OneBrickWalls. OneBrickWalls can be removed from WallTInner's set of associated elements, and TwoBrickWalls can be added to it. However, OneBrickWalls will still have WallTInner in its set of associated elements, and TwoBrickWalls not.

Clearly then, if the association are not handled properly, inconsistencies can easily occur in the structure. As with child-parent relationships, these associations form part of the core structure and should be controlled in such a way that inconsistencies cannot occur. Similarly to child-parent relationships, an object has to be used that controls Element-Element

55

many relationships required by these associations. A special class was created for this purpose – the JunctionTable.

A JunctionTable instance manages many-to-many associations between objects of the same type. Associations can be added or removed from a JunctionTable object. In both cases the JunctionTable object will ensure the different sets associated objects are synchronised. Since one JunctionTable instance will have to control all Element-Element associations, this object has to be kept in a central location. The Workspace class therefore contains this JunctionTable object that controls all Element-Element associations.