23.02.2015 Views

D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Dealing with Known Unknowns: A Goal-based Approach 17<br />

{g 5 ← {g 9 , g 12 } , g 5 ← {g 9 , g 13 }} or {g 5 ← {g 9 , g 12 , g 13 }} with a probability of 46%<br />

and 42%, respectively. The original part might stay unchanged with a probability<br />

of 12%. Similarly, in r o2 the original subpart {g 2 ← {. . .}} might also evolves to<br />

two other possibilities with probabilities of 45% and 40%. The remain unchanged<br />

probability of r o2 is 15%.<br />

Once an evolutionary goal model was transformed into a corresponding evolutionary<br />

hypergraph G〈V, E〉, every node x in G is tagged with a data structure<br />

called design alternative table (DAT), denoted as DAT(x), holding information<br />

for further calculating the max belief and residual risk. DAT(x) is a set of tuples<br />

S {〈Si , mb i , rr i , T i 〉}, where:<br />

– S i ⊆ G is a set of leaf goals necessary to fulfil this node.<br />

– mb i , rr i are the values of max belief and residual risk, respectively.<br />

– T i is a set of strings 〈r oα, i〉 which is the i th possibility of a rule r oα. This is<br />

used to keep track of the path of evolutions.<br />

Obviously, two tuples in a DAT which have a same T i are two design alternatives<br />

of an observable evolution possibility. Initially, DAT of each node is initialized<br />

as follows.<br />

8<br />

< {〈{x} , 1, 0, ∅〉} if x is a leaf goal,<br />

DAT (x) ←<br />

(5)<br />

: ∅<br />

otherwise.<br />

The DATs of leaf nodes are then propagated upward to predecessor nodes (ancestors).<br />

This propagation is done by two operators join(⊗) and concat(⊕).<br />

Also via these operations, DAT of an predecessor node is generated using their<br />

successor’s DATs.<br />

DAT(x 1 ) ⊕ DAT(x 2 ) ← DAT(x 1 ) ∪ DAT(x 2 )<br />

DAT(x 1 ) ⊗ DAT(x 2 ) ← [ i,j<br />

˘<br />

〈Si ∪ S j , mb i · mb j , 1 − rr i · rr j , T i ∪ T j 〉 ˛˛<br />

〈S i , mb i , rr i , T i 〉 ∈ DAT(x 1 ), 〈S j , mb j , rr j , T j 〉 ∈ DAT(x 2 )¯<br />

(6)<br />

Lemma 1 The operator join and concat are commutative and associative.<br />

Proof (Lemma 1) By definition,<br />

DAT(x 1 ) ⊕ DAT(x 2 ) ← DAT(x 1 ) ∪ DAT(x 2 )<br />

= DAT(x 2 ) ∪ DAT(x 1 ) → DAT(x 2 ) ⊕ DAT(x 1 )<br />

(7)<br />

`DAT(x1 ) ⊕ DAT(x 2 )´ ⊕ DAT(x 2 ) ← (DAT(x 1 ) ∪ DAT(x 1 )) ∪ DAT(x 2 )<br />

= DAT(x 1 ) ∪ (DAT(x 1 ) ∪ DAT(x 2 ))<br />

→ DAT(x 1 ) ⊕ `DAT(x 2 ) ⊕ DAT(x 2 )´<br />

From (7),(8), we conclude that concat(⊕) is commutative and associative. Similarly,<br />

we also have join(⊗) commutative and associative.<br />

(8)

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!