The message model
The message model is called that way to distinguish it from the envelope model. The message model contains the actual building and construction data. For actually sending over data, a more simplified version of the model (a "view") is used
This section starts with a discussion outlining the difference between a model and a view. This is done first in order to place the message model in the right perspective. The section also describes why both a model and a view are needed to describe the actual message. Next, both the model and the view are presented.
Difference between a model and a view
A model, as the two previous sections showed, is a way to describe something in a standardised manner. A Business Process consists of one or more Business Process steps, as you can see in Figure 6-4.
A view is best described by saying that it is a view on a model. Let's explain it by drawing an analogy with databases. Databases are an application area where views are used a lot. An entire database is quite complicated and consists of many items[1] . Many items only serve a database-internal function and aren't meant to be seen by the users. A view in database technology terms means a selection of the items, needed for a specific purpose. A user of that view can do exactly what he needs to do, without being bothered by the underlying complexity. A view (now in the context of this document!) is a simplification of the actual model which can be exchanged losslessly with the model[2].
The need for both a model and a view
Reality is complex. Civil engineering works are complex. In order to describe them accurately, the model should be able to accommodate the complexity. Stated differently, the model should be able to describe the reality accurately. When a model only allows you to talk about walls and floors, you can describe a building. But you're already missing the foundation, the windows, etc. Reality in this case is definitely more complex than the model can accommodate.
To handle complexity, one of the most important steps is to categorise reality. This means to split up reality in multiple categories, e.g. floors, walls, foundation, services, etcetera. A wall can then be categorised further in concrete wall, wooden wall, etcetera. There are two ways to accommodate complexity through categorisation:
Make a complex model. Model as much specific characteristics of the reality as feasible, categorising within the model itself.
Make a generic model. Capture the characteristics of the reality, phrasing them in a limited set of generic terms, leaving the actual categorisation work to one who uses the model.
For example, the first model would have a loadbearingfunction element, the second model would have a function with a name of load_bearing.
The requirement (the section called Requirements) that the model has to be simple excludes the first (the complex) model. The problem with the second model, however, is that the generic terms used (which are perfectly well suited to describe reality) are less usable from a user point of view. As an analogy, a database's internal structure, which probably will be the best and most efficient way to represent the information stored in it, most probably will not correspond to the way the user looks at the information. In the same way, a generic model does not represent the user's viewpoint most of the time. So, a view will be used to accommodate certain specific uses. The model itself will be used for generic storage and to facilitate exchange.
An additional bonus of using a view is that it constrains the user. This may sound negative, but by allowing only a limited view on the total model, the amount of possible errors also is reduced. To illustrate this, look again at the database example. In his view the user only sees the fields he needs. If he would have access to all database fields, it would be easy for him to type in a wrong customer_number in the order database that does not correspond to the intended customer. In a view, he would have selected a specific customer and the system would have taken care of filling in the correct customer_number.
As a conclusion, a generic model will be used to describe reality, but for specific uses, a view will be used to simplify the use of the model.
The model
The model I use is based on the LexiCon meta-model (Figure 5-5). Below, I will explain the resulting model. This also serves as an explanation of the original LexiCon meta-model.
First off, we start with a builtobject. That is an item which stands for one part of a civil engineering object. Like, for instance, a wall, a door, a tunnel. Nothing keeps you from using it to indicate a service, like paint-work (as applied on/for an object). But since it will most often be used to describe a "touchable" object, I stick with the naming of the LexiCon. A builtobject is the base building block, to which all other information is connected, like names, characteristics and sub-parts.
Secondly, I add two things. The builtobject on the one side has characteristics[3] of it's own and on the other side it serves as a category for other builtobjects. The characteristics will be explained later on. The fact that the builtobject serves as a category is because all the builtobjects, one way or another, have to be categorised in categories of builtobjects. Everything below this category still is a, say, door, but then a more specialised one. A sliding door, a revolving door, a armoured door. This is central to the LexiCon meta-model this model is based upon. All builtobjects which serve as a category, together form a tree-like structure. They are categorised in one big hierarchy according to specialisation (see Figure 6-7.
So, the specialisation can be used to build a hierarchy of builtobjects, while the characteristics are listed separately, they are characteristics of that specific type of builtobject.
Next, the characteristics are fleshed out. The builtobject can have an amount, quantifications and functions associated with it through it's characteristics. An amount is used to indicate the number of builtobjects. This is used when describing that something consists of amount items of this builtobject.
Quantification is used to describe measurable characteristics of the builtobject, like weight, length, height.
Functions are used to describe features one desires from or who are associated with the builtobject. For example load_bearing or fire_resistance.
Through the subparts-relation, also builtobjects are connected to the characteristics, this is a means to identify parts which are directly related (though not in the sense of specialisation!), such as a doorknob on a door or glass in a window.
Added to this is one new object, unit. Unit is a unit as in millimetre or pound per square inch.
Two relations are added. a function has an optional quantification, so the function fire-resistance can be quantified with time to failure. A quantification can have an amount (50) and a unit (minutes), for instance. This can be used for a fire-resistance function which has a TTF (time to failure) of 50 minutes.
Lastly, all objects (except characteristics and amount) have one or more names for identification and presentation purposes. Each name has an attribute language to indicate the language. This way, multi-linguality is achieved. A door can both have an English name door and a Dutch name deur. It is the same built object, but it can be identified both in Dutch and in English.
The only elements without a name are amount (which is just a number) and characteristics (which only serves as a container to the elements below it).
The view
As indicated before, the model is good for storing a hierarchy and ordering the different built objects, but for simple uses it is too awkward to use. In order to prove the concept of views (explained in the section called The need for both a model and a view), one simple view is enough. The two Use Cases can help determine the view. Both Use Cases are repeated in Figure 6-12 for convenience.
The left-hand Use Case is mostly about simple parts. The contractor wants 500 rooftiles with a certain performance and 4 concrete beams with a span of 4 meter. He gets as a response 7 possible types of rooftiles and beams. He orders 500 items of one type of roof-tile.
The right-hand Use Case first needs an entire project hierarchy to be transmitted, but after that only single pieces of information are needed.
A useful view in both cases is to have a simple list of items with no hierarchy and substructures: just a one-dimensional list of single items. This means a very simple view with no need for much structure. The information that is contained within the model for one specific builtobject (like function) should be available too within the view. But here lies a possibility for more ease of use. In the model, the information is represented by items that have names. In the view, when you select only a single language, the function-with-a-name duo can be changed into a single item named after the name of the function. And instead of communicating a builtobject with a name of roof-tile, you can communicate a roof-tile. In this way, no information is lost, but the usability has risen considerably. The result of an example view can be seen in Figure 6-13 and Figure 6-14.
Figure 6-14. Initial version of the example view - XML version
<door>
<amount>..</amount>
<height>
<amount>..</amount>
<meter/>
</height>
<fire-resistance>
<time-to-failure>
<amount>..</amount>
<minutes/>
</time-to-failure>
</fire-resistance>
etcetera
</door>
|
This can be done even simpler by using attributes, which does away with the unit and amount items. This results in Figure 6-15 and Figure 6-16.
