Related work
3.2 Domain concepts
3.2.1 Cost frames
A cost frame (cf:CF) is a mapping from cost items (ci:CI) to a pair of which the first component is the cost (cost:Cost) of that cost item and the second is the sub–frame. A sub–frame is a cost frame as well. Each cost item in a cost frame (including sub–frames) uniquely identifies a record of expenses concerning work, material, man–hour payment, etc. That is, it designates the maximum amount of money that is allowed to be spend. From a cost item and cost frame, we can observe the corresponding frame name (fn:Fn) which is the name it is given in the same cost frame. Such labels are, however, not unique but can appear several places in the same cost frame.
A cost frame is wellformed if and only if each cost is non–zero (we assume that costs are not negative) and that it is equal the sum of costs in the corresponding sub–frames. Furthermore, it is required that all cost items are indeed unique (i.e. the number of cost items is equal the length of the list of frame names).
Also, all sub–frames must be wellformed.
type
CF′ =CI m→(Cost×CF′), CF={|cf:CF′ •wf(cf)|}, CI,
Cost value
zero : Cost, wf: CF′ →Bool wf(cf)≡
(∀ci:CI• ci∈domcf⇒ let (cst,cf′)=cf(ci)in
non_zero(cst)∧ cst=total(cf′)∧wf(cf′) end)∧
card frames(cf)=lenframe_names(cf),
3.2 Domain concepts 69
hobs_Fn_Frm(ci)ib frame_names(cf\ {ci})b frame_names(cf′)
zero+c≡c,
The functions iterating on sets are exhaustive because all sets are finite and elements are iteratively removed.
In empirical material like [137] we recognize the pattern that a cost frame divides into sub–structures which are also cost frames.
Letfijk range over values of CI, andcij range over values of Cost. Values of CF thus have the general form (here only expanding part of it):
An example of a value of type CF is:
Example 1
3.2 Domain concepts 71
stone_bed7→(1080000,[ ]), underbase_grouting7→(44800,[ ]), backfill7→(400000,[ ]),
concrete7→(12200000, [tremied7→(1200000,[ ]),
in_situ_reinforced7→(3000000,[ ]), precast_reinforced7→(8000000,[ ])]), ballast_fill7→(1840000,[ ])]),
piers_pylons7→(2040500, [concrete7→(2040500,
[in_situ_reinforced7→(185500,[ ]),
precast_reinforced7→(1855000,[ ])])])]), labouritems7→6700500]
⋄
3.2.2 Object aspects
We introduce the notion ofobject aspects(x:X). These are different from building components and material in the sense that an object aspect (x:X) denotes a certain aspect of an artefact to be built. In this paper it is not considered something consumed by an operation. By an object aspect, we understand a reference to a proper part of an object existing in a possible world equal or succeeding to the actual world. However, in this paper the notion of possible worlds is not important.
Examples of object aspects are: a certain wall, the collection of all exterior walls in a building, the foundation, and the top surface of the foundation. Object as-pects are referred to in construction specifications, building codes, conceptual models, requirements, and (perhaps most important) in general talk, e.g. at the construction site. We introduce this notion and distinguish it from physical resources consumed by operations. Thereby, we claim to avoid certain mereo-logical problems. In this paper, we shall not dig into the mereomereo-logical aspects here, but refer to Chapter 8 which presents a study of the notion.
3.2.3 Resources
Resource types (rn:Rn) denote resources which are consumed by operations. Re-sources can be components like pre–cast concrete walls or materials like sand.
The amount of resources are measured and represented by natural numbers.
Furthermore, resources can be personnel and tools. We do not, however, apply a principle of tool reuse (usage with replacement). The way such resources are managed in most civil engineering projects opens up for a solution, which is dif-ferent from the obvious computer science one. This obvious solution would be to order operations based on their input–output types. This ways, all components
“flow” through the project plan. However, there are a number of problems in this solution which mostly root in some mereological problems of which we shall not be concerned here.
Instead, what is measured for personnel and tools are the hours of work. Per-sonnel and tools are considered resources but are counted as man–hour and use–per–hour, respectively. After an operation has been performed, such re-sourceshas been consumed as it is the time of use that counts. A personnel resource is counted as a multiplication of the number of persons and the hours of use. Similar goes for tools. Thereby, we avoid optimisation issues and we are still true to the domain.
Definition 3.1 For an operation to “concern” an object aspect, we under-stand that the operation is or includes the construction of or the work on that object aspect.
2 We assume that resources consumed by operations concerning one object as-pect are distinct from those consumed by operations4 concerning other object aspects. The types and numbers of resources may be the same but the physical resources are not.
The distinction comes from the definition of which resources are consumed in what operations. Letxibe object aspects. On Figure 3.1, the concrete resources for casting x2 and x3 are distinct resources from the resources consumed by operations involvingx1; e.g., paint for painting x1. Similar, the resources for preparing the surfaces denoted byx4 are distinct from the resources consumed by the operation which castsx4. Also, the latter set of resources do not include the former set of resources.
This trick of not having set–based resource inclusion downwards the order of object aspects, solves the problem of uniqueness when quantifying over these.
4possibly the same.
3.2 Domain concepts 73
x1
x4(x4< x2,x4< x1) x3(x3< x1)
x2(x2< x1)
Figure 3.1: Aspects of a bridge pier object.