D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange
D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange
D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
10 F. Massacci and L.M.S. Tran<br />
[5] Data exchanged<br />
12%<br />
42%<br />
[12] Basic data<br />
exchanged with<br />
DMAN<br />
DMAN<br />
[13] Advanced<br />
data exchanged<br />
with DMAN<br />
12% 42% 46%<br />
[5] Data exchanged<br />
[9] Data<br />
exchanged with<br />
adjacent sectors<br />
[5] Data exchanged<br />
[5] Data<br />
exchanged<br />
[5] Data<br />
exchanged<br />
[9] Data<br />
exchanged with<br />
adjacent sectors<br />
[5] Data exchanged<br />
[12] Basic data<br />
[13] Advanced<br />
exchanged with<br />
data exchanged<br />
DMAN<br />
with DMAN<br />
[9] Data<br />
exchanged with<br />
adjacent sectors<br />
[12] Basic data<br />
exchanged with<br />
DMAN<br />
[9] Data<br />
exchanged with<br />
adjacent sectors<br />
[13] Advance data<br />
exchanged with<br />
DMAN<br />
[12] Basic data<br />
exchanged with<br />
DMAN<br />
[9] Data<br />
exchanged with<br />
adjacent sectors<br />
[13] Advance data<br />
exchanged with<br />
DMAN<br />
46%<br />
[9] Data<br />
exchanged with<br />
adjacent sectors<br />
(a) Tree-like representation<br />
(b) Swimlane-based representation<br />
Fig. 3 Visualization of evolution rules.<br />
The tree-like representation, Fig. 3(a), basically is a tree-like directed graph,<br />
where a node represent a subpart in the goal model. The directional connection<br />
between two nodes means the source node evolves to target node. In other words,<br />
the source node is the original model (or subpart), and target node is the evolved<br />
model (subpart). A connection is labeled with an evolution probability p i . In two<br />
validation sessions with ATM experts the tree-like model was found more intuitive<br />
and we have therefore decided to implement it in our modelling CASE tool.<br />
5 Game-Theoretic Approach Accounting for Evolution Probability<br />
Our notion of observable rules includes an associated probability. Probabilities are<br />
often taken for granted by engineer and scientists but in our setting it is important<br />
to understand the exact semantics of this notion.<br />
Basically, there are two broad categories of probability interpretation, called<br />
“physical” and “evidential” probabilities. Physical probabilities, in which frequentist<br />
is a representative, are associated with a random process. Evidential probability,<br />
also called Bayesian probability (or subjectivist probability), are considered to<br />
be degrees of belief, defined in terms of disposition to gamble at certain odds; no<br />
random process is involved in this interpretation.<br />
To account for probability associated with an observable rule, we can use the<br />
Bayesian probability as an alternative to the frequentist because we have no event<br />
to be repeated, no random variable to be sampled, no issue about measurability<br />
(the system that designers are going to build is often unique in some respects).<br />
However, we need a method to calculate the value of probability as well as to<br />
explain the semantic of the number. Since probability is acquired from the requirements/objectives<br />
eliciting process involving the Domain Experts, we propose<br />
using the game-theoretic method in which we treat probability as a price. It seems<br />
to be easier for Domain Experts to reason on price (or cost) rather than probability.<br />
The game-theoretic approach, discussed by Shafer et al. [35] in Computational<br />
Finance, begins with a game of three players, i.e. Forecaster, Skeptic, and Real-