D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

6 F. Massacci and L.M.S. Tran Table 1 Notions and concepts Term Notion Definition Enterprise model EM is a set of entities and relations to model enterprise objectives (or system requirements). Subpart SM is a sub set of an enterprise model. SM α is the original model of the α th observable rule. SMi α is the i th evolution possibility of the α th observable rule. SMi,j α is the j th design alternative of SMi α . Enterprise model evolution (evolution) is a set of changes in the enterprise model, including addition, remove of objectives. Objective modification is treated as a series of remove and delete. Evolution rules r o, r c is a set of evolution possibilities. r oα is the α th observable rule. r cαi is the controllable rule applied to the i th possibility of the observable rule r oα Evolution possibility (possibility) is a potential evolution. In a same evolution rule, only one possibility is able to happen. Evolution probability p is the belief of stakeholder about the likelihood by which an evolution possibility will happens. Design alternative (alternative) DA is a set of elements of an enterprise model that are necessary to fulfil all objectives. Design alternative set SDA(C) is a set of design alternatives that are supported by a configuration C. Final choice (configuration) C is a set of elements in the enterprise model that are chosen to implement an enterprise system. A configuration can comprise one or more design alternatives. Smaller words in parentheses are short names (or aliases) of the terms in normal text. Definition 1 (Enterprise model) An enterprise model EM is a tuple 〈E, R〉 where E is set of entities, and R is set of relations among them. Evolution of enterprise objectives refers to changes of objectives of an enterprise, basically falling into two categories, controllable evolution and observable evolution. This justification is based on the factor (both human and non-human factor) that initiate the changes. – Controllable evolutions are subject to system designers who intentionally change the system design in order to fulfil high level enterprise objectives. In other words, they are designers’ moves to identify design alternative to implement an enterprise system. Later, the most “optimal” alternative is chosen to the next development phases. Such decision are based on tool-support analyses (both qualitative and quantitative) and expertise experiences. – Observable evolution, whereas, are out of control of “inside people” i.e. who directly involve in the development process such as domain experts, designers and so on. However, these evolutions can be forecasted with a certain level of confidence. As the impact of the observable evolutions, new objectives are in-
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
Page 1 and 2:
D.3.3 ALGORITHMS FOR INCREMENTAL RE
Page 3 and 4:
1.14 19 January Final 1.15 23 Janua
Page 5 and 6:
Index DOCUMENT INFORMATION 1 DOCUME
Page 7 and 8:
1 Introduction This deliverable pre
Page 9 and 10:
(Clause 6.4.3) processes of ISO/IEC
Page 11 and 12:
3 Orchestrating Requirements and Ri
Page 13 and 14:
grey. The ADS-B introduction requir
Page 15 and 16:
The security risk manager identifie
Page 17 and 18:
are supported by the argumentation
Page 19 and 20:
ADS-B Manage ADS-B signal ADS-B sig
Page 21 and 22:
the stagnation suite (i.e. obsolete
Page 23 and 24:
5 A framework for modeling and reas
Page 25 and 26:
sectors. And there is 42% of probab
Page 27 and 28:
SDA(C) = {DA 2 , DA 4 , DA 8 , DA 1
Page 29 and 30:
application contexts is saved if th
Page 31 and 32:
Figure 14. ATM model state after qu
Page 33 and 34:
References [1] Yudis Asnar, Fabio M
Page 35 and 36:
Managing Changes with Legacy Securi
Page 37 and 38:
Failure in the provisioning of corr
Page 39 and 40: propagated to the system designer a
Page 41 and 42: APPENDIX B D.3.3 Algorithms for Inc
Page 43 and 44: is sometimes difficult, especially
Page 45 and 46: Tactical Monitor air R controller t
Page 47 and 48: protected from harm. Since in CORAS
Page 49 and 50: CModel. The postcondtion checks the
Page 51 and 52: of ADS-B signal and Availability of
Page 53 and 54: extensions to i* to model and analy
Page 55 and 56: 3. Bzivin, J., Dup, G., Jouault, F.
Page 57 and 58: APPENDIX C D.3.3 Algorithms for Inc
Page 59 and 60: steps. Section V demonstrates the R
Page 61 and 62: that should be mitigated by the sys
Page 63 and 64: CPU value PINconfirmed(PIN, card-de
Page 65 and 66: TABLE IV PRIORITIZATION OF RISKS FO
Page 67 and 68: context. We believe that the Common
Page 69 and 70: Managing Evolution by Orchestrating
Page 71 and 72: 1.1 The Contribution of this Paper
Page 73 and 74: Fig. 3. Integrated Change Managemen
Page 75 and 76: The requirement analysis is an iter
Page 77 and 78: Table 1. Conceptual Interface Requi
Page 79 and 80: Legend: Goals surrounded by dashed
Page 81 and 82: Table 5. Test Suite for GP-2.2 Tran
Page 83 and 84: 6. P. K. Chittimalli and M. J. Harr
Page 85 and 86: Noname manuscript No. (will be inse
Page 87 and 88: Dealing with Known Unknowns: A Goal
Page 89: Dealing with Known Unknowns: A Goal
Page 113 and 114: Understanding How to Manage Require
Page 115 and 116: Chatzoglou et al. [4] conducted a s
Page 117 and 118: Evolution Elicitation Probability E
Page 119 and 120: Table 2. Participants Background Pa
Page 121 and 122: for the defined success criteria. O
Page 123 and 124: Fig. 3. Codes Coverage ATM systems,
Page 125 and 126: The feedbacks provided by the ATM e
Page 127 and 128: 3. P. Carlshamre, K. Sandahl, M. Li
Page 129 and 130: Quick fix generation for DSMLs Ábe
Page 131 and 132: • extensibility: the supported li
Page 133 and 134: Fig. 7. Overview of the Quick fix g
Page 135 and 136: Fig. 9. Evaluation results (|V(M I
show all

D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Create successful ePaper yourself

Delete template?

Save as template?