Design moves

[consistency]

axiom∀θ:Θ, x,x^′:X, a:AP, vs, vs^′:VP-infset, a^′,AR, vs^′′,vs^′′′:VR-infset^• ((a,vs)∈properties(x,θ)∧(a,vs^′)∈properties(x,θ)⇒vs=vs^′)∧ (((x,x^′),(a^′,vs^′′))∈relations(θ)∧((x,x^′),(a^′,vs^′′′))∈relations(θ)⇒

vs^′′=vs^′′′)

The algebraic laws of Section 6.4 ensure non–cyclicity of decompositions. Sub–

objects which are introduced by decompositions, are new objects and cannot be objects already existing in the model.

6.3 Design moves

We shall follow the distinction between design moves by aspect and design moves by configuration, as defined in Chapter 5.

6.3.1 Design move by aspect

Design moves of the first class are: (i) Adding an object to a model, (ii) ascribing a property to an object in a model, and (iii) adding a relation between two objects to a model. These are common in the sense that their application, contribute with knowledge of the artefact in mind. We see this “adding of knowledge” as restriction on the scope of possible interpretations of the model into reality. Thus, we shall talk of specialisation. Adding an object makes the design more specialised as we then require the existence of such an object.

Adding a property to an object makes the design more specialised as we then require the object to possess that property. Adding a relation between two objects makes the design more specialised as we then require these objects to be related in this way.

Each of the described design moves is modelled as a generator function:

value

add_object: X×Θ→^∼ Θ, add_property: P×X×Θ→^∼ Θ, add_relation: R×(X×X)×Θ→^∼ Θ,

All three generator functions are partial. Adding an object to a model in which

that object already exists yields problems in determining what properties that resulting object should have. It seems most reasonable that observing the pro-perties of a newly added object gives the empty set. For adding an object, it is thus required that the object is not already present in the model. On the other hand, ascribing a property to an object requires existence of that object in the argument model. For adding relations, we require that both objects are present in the argument model. We thus define the following guards:

value [guards]

is_object_present: X×Θ→Bool is_object_present(x,θ)≡x∈objects(θ),

is_property_attribute_present: AP×X×Θ→Bool is_property_attribute_present(a,x,θ)≡

(∃vs:VP-infset^• (a,vs)∈properties(x,θ)),

is_relation_attribute_present: AR×(X×X)×Θ→Bool is_relation_attribute_present(a,(x,x^′),θ)≡

(∃vs:VR-infset^•((x,x^′),(a,vs))∈relations(θ)),

6.3.2 Design move by configuration: Lattice operations

The two lattice operations are generator function which apply to pairs of artefact models:

value

meet: Θ×Θ→Θ, join: Θ×Θ→Θ

It is convenient, explicitly to overload similar operations for sets of properties and relations. For relations, we need to include pairs of related objects. We have:

value

meet: P-set×P-set→P-set, join: P-set×P-set→P-set,

6.3 Design moves 161

join(ps,ps^′)≡ {(a,vs)|(a,vs):AP×VP-infset^•

(∃vs^′,vs^′′:VP-infset^• (a,vs^′)∈ps ∧(a,vs^′′)∈ps^′ ∧vs=vs^′∪vs^′′)},

We see that lattice meet applied on two property sets (ps:P-set) and (ps^′ :P-set), gives the property set which is the union set of property attributes from psandps^′. For common property attributes ofps andps^′ the set of property values is the intersection set of values taken frompsandps^′. A similar account applies to relations. Lattice join applied on two property sets (ps:P-set) and (ps^′:P-set) is the property set which is the common property attributes of ps and ps^′′. For common property attributes of ps and ps^′, the set of property values is the union set of values frompsandps^′.

6.3.3 The design move of decomposition

In addition to the three design moves described in Section 6.3.1, we introduce a generator function for the design move of decomposition. The reason for in-cluding this design move is to accommodate top–down designing where artefact models are specialised by decomposing objects into sub–objects. Such a design move contributes with knowledge of an objects parts.

The design move of decomposition is declared as the generator function:

value

decompose: X×(AP m→(X m→VP-infset))×Θ→^∼ Θ

The second argument defines a kind of rule for the decomposition. For each property attribute (a:AP) of the argument object, we get a map from the new sub–objects to their individual value sets. The rule is a way of specifying how the sub–objects derive properties from the object which is decomposed. However, it is only a convenient way of comprising a sequence of specialisation operations.

To make this clear, we introduce a number of terminological definitions:

Definition 6.1 An objectxp is called a parent object of another objectxs

ifxp has been decomposed into a set of objects including xs. xs is then called asub–object ofxp.

A sub–object may get a number of attributes from properties of its parent object. The reason is that knowledge of an object may also say something about the parts of which that object consists. Such knowledge is expressed by the decomposition rule.

Definition 6.2 An objectxis said toderivea property(a, vs)from another objectx^′ ifxis a sub–object ofx^′ andais an attribute ofxas well as ofx^′.

If a table is described as possessing the property of being made of wood this property contains an attributematerial. The property is also possessed by the various parts of the table. However, it may be the case that only the attribute is the same for sub–object and parent object. E.g. for the property of having a certain length. Decomposing a beam into parts conceptually ascribes different length values to the sub–objects, though the attribute “length” is maintained (see Section 6.3.3). However, as argued in Section 6.2.2, we cannot in general state a relation between the properties of a sub–object and the properties of

6.3 Design moves 163

a parent–object. The decomposition rule is therefore to be understood in a constructive sense.

Three issues are important in context of decomposition rules. First: we allow that objects are not decomposed at once into all their parts. We call thispartial decomposition. Second: Although we allow for partial decompositions, we do not allow for an object to be decomposed several times in distinct operations (if following the same path in the design lattice). This may seem strange, however, the argumentation is similar to the one for not allowing an object to be ascribed a property with the same attribute twice, following the same path in the design lattice. We want dogmatically to maintain a principle of incrementality. If an object needs to be decomposed in two steps we see these as alternative decompositions of the same object, belonging to parallel paths of the design lattice. The two decomposition configurations can then be combined using lattice meet as shown on Figure 6.3. Stepwise decomposition can thus be modelled as applying lattice meet on alternative (partial) decompositions.

Figure 6.3: Stepwise decomposition using lattice meet.

As a special case of this issue, we allow for sub–objects to “overlap” spatially.

The reason for this is that it can be convenient to talk about the same object in context of its decomposition relation to different parent objects (see Figure 6.3).

Third, we have an issue concerning what happens if an already decomposed object is ascribed properties. For the parent object the situation is similar to when an object is ascribed a property with add_property. For the sub–objects, however, the status maintains the same as we do not require a relation between properties of parent objects and properties of sub–objects.

A decomposition is valid if and only if the argument object is in the argument model, the argument object is not designated as a sub–object, and each property attribute in the rule is an attribute of a property which is ascribed the argument object.

is_valid_decomp: X×(AP m→(X m→VP-infset))×Θ→Bool is_valid_decomp(x,am,θ)≡

x∈objects(θ)∧

(∀a:AP^• a∈domam⇒x6∈domam(a))∧

(∀a:AP^• a∈domam⇒(∃vs:VP-infset^• (a,vs)∈properties(x,θ)))

In addition to the consistency axiom defined in Section 6.2.3, we require that if an object is a sub–object in a decomposition, it cannot be an object in the previous artefact model:

value

[decomp−consistency]

∀x, x^′:X, am:AP m→(X m→VP-infset),θ:Θ^• x∈decomposition(x^′,decompose(x^′,am,θ))∧

(∃a:AP^• a∈domam∧x∈domam(a))⇒x6∈objects(θ)

When defining decomposition algebraically, we need a function which given a decomposition rule and a sub–object, gives the properties that the sub–object derives according to the rule.

value [misc]

derive: AP →m (X →m VP-infset)×X →P-set derive(am,x)≡

{(a,vs)|(a,vs):P^• a∈domam∧x∈am(a)∧vs=am(a)(x)}