D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Dealing with Known Unknowns: A Goal-based Approach 7
troduced, or objectives’ status is changed e.g., from ‘optional’ to ‘compulsory’,
or from ‘compulsory’ to ‘obsoleted’.
In an evolution-aware developing process, the selection of optimal design alternative(s)
for the implementation of an enterprise system should carefully take
into account observable evolutions, otherwise it may be incapable to support the
enterprise objectives in future.
To support decision making in dealing with the evolution of enterprise objectives,
these two kinds of evolutions are incorporated into enterprise models in
terms of evolution rules. The basic idea of evolution rules is to capture the snapshots
of enterprise objectives before and after evolutions. Evolutions rules are formally
defined as follows:
Definition 2 (Controllable rule) A controllable rule r c is a set of tuples 〈EM, EM i 〉
that consists of an original model EM and its possible design alternative EM i .
r c = [ o
nEM −→ ∗ EM i
i
Example 1 (Controllable rule) Consider again Fig. 1, the objective g 5 −Data exchanged
is refined into only one lower level objective g 9 −Data exchanged with adjacent sectors.
However an organization might chose to integrate the DMAN in the process and
thus might choose between two other goals g 12 −Basic data exchanged with DMAN and
g 13 −Advanced data exchanged with DMAN.
Definition 3 (Observable rule) An observable rule r o is a set of triples 〈EM, p i , EM i 〉
that consists of an original model EM and its potential evolution EM i . The probability
that EM evolves to EM i is p i . All these probabilities should sum up to one.
r o = [ n
EM p o
i
−→ EM i
i
Example 2 (Observable rule) Consider again Fig. 1, the objective g 5 −Data exchanged
is refined into only one lower level objective g 9 −Data exchanged with adjacent sectors.
One potential evolution for is that a regulatory body requires that the organization
should also achieve both goal g 12 −Basic data exchanged with DMAN and goal g 13 −Advanced
data exchanged with DMAN albeit for different functionalities. If this possibility actually
happens the organization should meet g 9 , g 12 , g 13 in order to meet g 5 . However, the
discussion in the regulatory body is still quite open and another option might be
to actually leave partners to chose whether to impose g 9 −Data exchanged with adjacent
sectors and g 12 −Basic data exchanged with DMAN and leave operators the choice of implementing
g 9 and g 13 −Advanced data exchanged with DMAN. This latter option, which combines
the one from Example2, is denoted by EM 1 as it is the most likely outcome,
the former we denote it by EM 2 . Obviously, there is also another possibility: EM
might not evolve and therefore remain unchanged (decision of regulatory body
is post-poned after first deployment trials of DMAN). These possibilities exclusively
happen with some uncertainties. Thus, the observable rule is would be the
following one.
j
ff
r o1 = EM p 1
−−→ EM 1 , EM p 2
−−→ EM 2 , EM 1−p 1 −p 2
−−−−−−→ EM