• No results found

4.3 A Model of Decision Processes

4.3.2 Embedding Decisions Results

Decision outcomes do not exist in a vacuum. They are part of a design process that is ultimately driven by a goal, namely to meet a set of requirements within the constraints of time and budget. As a result, the decisions made at each stage (and their supporting arguments) have an effect on subsequent decisions.

Our definition of decision outcomes (Definition 52) can express such correlations only in a limited way: Because each individual decision outcome is conflict-free, argu- ments may be re-used in later stages, but only in the same polarity (that is, the system cannot express the phenomenon that an argument in favour of one decision outcome can also act as an argument against another decision outcome). Nonetheless, Defini- tion 52 is a suitable representation of design documents, as seen in Section 4.5.1. The decision processes introduced in this section should therefore seen as a second layer on top of the individual decision stage. The purpose of this layer is to draw connections between decisions, and the purpose of the lower (decision making) layer is to assess individual decisions.

4.3.2.1

Embeddings by Example

Let us look at a bigger example to illustrate the points made above.

Example 34. The decision outcome Res2 documents a decision that was made after Res1.

Res2= {⇒ al, ⇒ bolts, ⇒ shim, r1, r4, r5}

r4= bolts ⇒ ¬hal ⇒ non corrosivei

r5= shim, bolts ⇒ good EMC

4.3. A Model of Decision Processes 119 spected in the design, but rule r2 is missing from Res2. This indicates that, with the additional knowledge available at stage 2, arguments based on r2 are defeated. The new rule r4 in fact deactivates rule r2 so arguments that use it are not (sceptically or credulously) acceptable.

Suppose the result Res1 from Example 33 is not followed by Res2, but by Res3 (below) instead, after the choice of adding bolts, shim was rejected because it resulted in attacks on arguments based on rule r2. In Res3, we choose not to apply a coating because aluminium is corrosion-resistant without coating. Also we use screws instead of bolts for attaching the structure.

Res3= {⇒ al, ⇒ no coating, ⇒ screws, r1, r2, r3, r6, r7} with

r6= al, no coating ⇒ corrosion resistant r7= al, screws ⇒ good EMC

Independently of decisions one to three (with results Res1 to Res3), the length of the component s2(cf. Figure 3.1 on page 52) was decided:

Res4= {⇒ length(s2, 25cm), r8}

r8= length(s2, 25cm) ⇒ weight(s2, 450g)

And, lastly, the two separate decision sequences (Res1, Res2, Res3 and Res4) are

combined in the final decision Res5.

Res5= {⇒ length(s2, 25cm), ⇒ al, ⇒ no coating, ⇒ screws, r1, r2, r3, r6, r9}

r9= length(s2, ≤ 30cm) ⇒ ¬good EMC

Note that the conclusion of r9 is ¬good EMC, which directly contradicts the claim of a12(good EMC). Therefore a12and a15attack each other, so they cannot be in the same

conflict-free set, so at most one of the two arguments can be part of a decision outcome. For the outcome Res5in particular, a15 is included so a12is excluded.

4.3. A Model of Decision Processes 120

Table 4.1: Arguments in the example decision process. The column “Decision Results” gives the decision results in which an argument is included.

Name Argument Decision Results

a1 [⇒ al; al] Res1, Res2, Res3, Res5 a2 [a1; al ⇒ strong; strong] Res1, Res3, Res5

a3 [a1; al ⇒ non corr.; non corr.] Res1, Res3, Res5

a4 [a1; al ⇒ high weight; high weight] Res1, Res3, Res5

a5 [⇒ bolts; bolts] Res2

a6 [a5; bolts ⇒ ¬hr2i; ¬hr2i] Res2

a7 [⇒ shim; shim] Res2

a8 [a5, a7; shim, bolts ⇒ good EMC; good EMC] Res2

a9 [⇒ no coating; no coating] Res3, Res5

a10 [a1, a9; r6; corrosion resistant] Res3, Res5

a11 [⇒ screws; screws] Res3, Res5

a12 [a1, a11; r7; good EMC] Res3

a13 [⇒ length(s2, 25cm); length(s2, 25cm)] Res4, Res5 a14 [a13; r8; weight(s2, 450g)] Res4

a15 [a13; r9; ¬good EMC] Res5

produced at any stage. The column “Decision Results” gives the decision results in which an argument is included (that is, the decision results from which the argument can be formed). Many arguments appear in more than one decision result.

The knowledge on which decisions are based often increases monotonically dur- ing the design process. In Example 34, options and rules of Res1are a subset of those

of Res3 and therefore args(Res1) ⊆ args(Res3). This is not the case for all decision

results as earlier arguments may disappear. For example a12 ∈ args(Res3), but a12 ∈/

args(Res5), even though the knowledge base representing the actual design – as deter-

mined by the option function – increased monotonically, option(Res3) ⊆ option(Res5).

How can the apparent disappearance of knowledge conform with our claim that knowledge increases monotonically in decision processes? The answer to this question lies in our definition of decision outcomes in Section 4.3.1. There, we defined decision outcomes as the logical equivalent of design documents, which means that they only contain enough knowledge to justify (make arguments for) the current decision, not all previous decisions. However, even though some knowledge is not written down in a design document, it is not lost to the designers. In our formal model we are free to include additional knowledge. This inclusion of background knowledge is the idea behind the definition of embeddings (Definition 54).

4.3. A Model of Decision Processes 121

4.3.2.2

Properties of Embeddings

In the rest of this section we will state the conditions we would like to hold for a embeddings, and in the next section (Section 4.3.3) we will address the question of how to construct an embedding for a given decision sequence.

We first need to define the concept of increasing knowledge formally. A sequence of ASPIC+ knowledge bases is monotonically increasing if each element is a subset of its successor.

Definition 53 (Monotonically Increasing). A sequence (k1, . . . , kn) of ASPIC+ knowl-

edge bases ismonotonically increasing if and only if for all 1 ≤ i < n, ki⊆ ki+1.

Even if a sequence of knowledge bases is montonically increasing, the set of (scep- tically or credulously) acceptable arguments at each stage may not be increasing, be- cause new counter-arguments may be introduced.

A monotonically increasing sequence of ASPIC+ knowledge bases is an embed- ding of a sequence of decision results (of the same length) if the arguments of the i-th decision result are sceptically acceptable in the graph of the i-th knowledge base. Since this requires both sequences (the monotonically increasing sequence of knowl- edge bases, and the sequence of decision results) to have the same length, we represent embeddings as functions from decision results to ASPIC+ knowledge bases with the

following properties:

Definition 54 (Embedding of Decision Results). Let S = (Res1, . . . , Resn) be a sequence

of decision outcomes (Definition 52). Anembedding E of S is a function from decision outcomes toASPIC+ knowledge bases such that

1. For all i≤ n, Resi⊆ E(Resi),

2. For all i≤ n, args(Resi) ⊆ Σgr(argGraph(E(Resi))) and

3. For all i< n, E(Resi) ⊆ E(Resi+1)

Let us look at the conditions of Definition 54 in detail. The first one says that every decision result Resi in S must be subsumed by its corresponding result

E(Resi). Condition 2 ensures that, at every stage i in the design process, the ar-

4.3. A Model of Decision Processes 122 also. Since every decision outcome Resi is conflict-free, its argument graph contains

no attacks, so Σgr(Resi) = args(Resi), and the condition could alternatively be stated

as “For all i ≤ n, Σgr(Resi) ⊆ Σgr(argGraph(E(Resi))).” Finally, Cond. 3, states that

(E(Res1), . . . , E(Resn)) is monotonically increasing, that is, no rules are lost when pro-

gressing from E(Resi) to E(Resi+1).

A consequence of conditions 2 and 3 for our example (Example 34) is that any embedding E of (Res3, Res5) must contain attacks in argGraph(E(Res5)), even though

Res3and Res5 on their own are conflict-free. This is because argument a15 from Res5

attacks argument a13 from Res3, and by Definition 54 Cond. 3, a13 is also an argu-

ment of E(Res5). More generally, we find that embeddings of decision outcomes may

introduce conflict even though each outcome on its own is conflict-free:

Proposition 27. Let S = (Res1, . . . , Resi, . . . , Resk, . . . , Resn) be a decision sequence

with i< k ≤ n such that the argument graph G = (A, Att) = argGraph(Resi∪ Resk)

has a non-empty set of attacks, Att 6= /0. Let E be an embedding of S. Then, argGraph(E(Resk)) is not conflict-free.

Proof. Let a ∈ args(Resi), b ∈ args(Resk) such that (a, b) ∈ Att (the proof for (b, a) ∈

Att proceeds similarly). Let G0= (A0, Att0) = argGraph(E(Resk)). By Definition 54 Cond. 2, a ∈ args(E(Resk)), and by Definition 54 Cond. 1, b ∈ args(E(Resk)). Since b

attacks a, (b, a) ∈ Att0so Att 6= /0.

Embeddings are mappings of individual ASPIC+ knowledge bases (see Definition 2.3.2.1 on page 33), but every embedding E also defines a mapping of sequences of knowledge bases, obtained by applying E to each element in the sequence. We will use embeddings mostly in the latter (sequence) sense, but define them in the former (ele- ment) sense, because it simplifies proofs and it enforces the property that embeddings of sequences of decision outcomes are really embeddings of their constituent parts.

With embeddings we can describe the relationship between individual design doc- uments that are conflict-free and the aggregated knowledge in a design process that may have conflicts. The remainder of this chapter will be spent constructing embed- dings and exploring them from different angles.

4.3. A Model of Decision Processes 123