22 F. Massacci and L.M.S. Tran Table 2 Samples in the DAT table of the root node g 1 Design Alternative (DA) MB RR Trail (T) 1 {g 9, g 6, g 7, g 10, g 11} 1.80% 98.20% {〈ro1, 0〉 , 〈ro2, 0〉} 2 {g 9, g 6, g 7, g 11, g 15} 5.40% 94.60% {〈ro1, 0〉 , 〈ro2, 1〉} 3 {g 9, g 6, g 7, g 11, g 15, g 16, g 17} 5.40% 94.60% {〈ro1, 0〉 , 〈ro2, 1〉} 4 {g 9, g 6, g 7, g 11, g 15, g 16, g 17, g 19, g 20} 4.80% 95.20% {〈ro1, 0〉 , 〈ro2, 2〉} 5 {g 9, g 6, g 7, g 11, g 15, g 16, g 17, g 19, g 21} 4.80% 95.20% {〈ro1, 0〉 , 〈ro2, 2〉} 6 {g 9, g 6, g 7, g 11, g 15, g 16, g 17, g 19, g 20, g 21} 4.80% 95.20% {〈ro1, 0〉 , 〈ro2, 2〉} 7 {g 9, g 12, g 6, g 7, g 10, g 11} 6.30% 93.70% {〈ro1, 1〉 , 〈ro2, 0〉} 8 {g 9, g 12, g 6, g 7, g 11, g 15} 18.90% 81.10% {〈ro1, 1〉 , 〈ro2, 1〉} 9 {g 9, g 12, g 6, g 7, g 11, g 15, g 16, g 17} 18.90% 81.10% {〈ro1, 1〉 , 〈ro2, 1〉} 10 {g 9, g 12, g 6, g 7, g 11, g 15, g 16, g 17, g 19, g 20} 16.80% 83.20% {〈ro1, 1〉 , 〈ro2, 2〉} . . . . . . . . . . . . . . . 23 {g 9, g 12, g 13, g 6, g 7, g 11, g 15, g 16, g 17, g 19, g 21} 18.40% 81.60% {〈ro1, 2〉 , 〈ro2, 2〉} 24 {g 9, g 12, g 13, g 6, g 7, g 11, g 15, g 16, g 17, g 19, g 20, g 21} 18.40% 81.60% {〈ro1, 2〉 , 〈ro2, 2〉} Bold lines (2–4, 8–10) are design alternatives supported by configuration C= {g 9, g 12, g 6, g 7, g 11, g 15, g 16, g 17, g 19, g 20}. – Identify design alternatives supported by C. Look at Table 2, line 2–4, 8–10 refer to alternatives supported by C. SDA(C) = {DA 2 , DA 3 , DA 4 , DA 8 , DA 9 , DA 10 } – Remove alternatives that have duplicated trail (T). Among selected alternatives, DA 2 , DA 3 have a same trail, and DA 8 , DA 9 also have a same trail. Thus we remove DA 3 , DA 9 from DA(C): SDA(C) = {DA 2 , DA 4 , DA 8 , DA 10 } – Calculate the max belief and residual risk. MaxB(C) = max {5.4%, 4.8%, 18.9%, 16.8%} = 18.9% RRisk(C) = 1 − (1 − 94.6%) + (1 − 95.2%) + (1 − 81.1%) + (1 − 83.2%) = 54.1% A weak part of the algorithm is the dependence on the number of not-dominated design alternatives. If the design alternatives form a k-ary tree, then the number of leave is about L ≈ n + 1 , where n is number of alternative task nodes. Then the k number of design alternatives would be a power set of L. So in worst case, we need to join two DATs with 2 L/2 elements each, the complexity of join thus is O(2 n ) Such huge number of alternatives cannot found in practice. Indeed we can simply discard the alternatives that are dominated by other in both max belief and residual risk. The worst case scenario can only materialize in the case of perfect uncertainty: all observable alternatives have exactly the same probability and each design alternative is mutually not compatible with some observable alternative. The discussion with experts from ATM domains that we carried out in the <strong>SecureChange</strong> project showed that AND decomposition and observable rules form the bulk of the graph with very few design alternatives. Further, some of the design alternatives distinguish between the vanilla or rich version of a solution so that
Dealing with Known Unknowns: A Goal-based Approach 23 one alternative works for both. This further reduces the number of truly alternative configurations. For example in the goal model of the AMAN system provided by ATM experts, there are 54 goals (36 are leaves), 23 AND-decomposition, but only 6 design alternatives. It means that the complexity of the join operator in this real world case is less far than the number of nodes. 9 Related Works Boyd [6] was one of the first who mentioned the term “enterprise model”. He introduced many essentially concepts which later became pervasive in the area of Enterprise Modeling (EM). Vernadat [40] defines EM as the process of building models of the whole or part of an enterprise (e.g., process models, data models, resource models, etc.) There exists several techniques, frameworks, languages and tools for representation of enterprise and its processes. They includes SADT, Data Flow Diagrams (DFDs), IDEF0 and IDEF [32], activity diagrams in the UML, IEM [22], GRAI/GIM [9], ARIS/EPC [34], UEML [39], CIMOSA [7], GERAM [5]. Besides those, i* modeling framework [41] was introduced to support the modeling of strategic relationships among organizational actors. It provides sets of concepts that complement other approaches for organizational modeling (such as CIMOSA and GERAM) to address the need for expressing complex organizational issues as well as technology ones in an enterprise. However, these models do not cater for the possibility of evolution. Evolution was considered initially by Ba et al. [3] in their conceptual Enterprise Modeling System (EMS). Their framework automatically builds and executes task-specific models as needed in response to queries from users. The EMS was designed to support strategic decision-making such as predicting the effects of changes in business policies, analyzing possible reactions to internal and external threats, and exploring new business opportunities. In general, the framework tried to address the “what if”, “what should we do”, and “where should we go”-type of questions. However, this framework was at high abstract level. Loucopoulous and Kavakli [20] described an approach involving the explicit modeling to express enterprise views in terms of the technical, social and teleological dimensions and their relationship to information system goals. They also illustrated their approach by a case study about Air Traffic Control. In another work [21], they emphasized Enterprise Knowledge Management as the most important factor to address the turbulent changes in many industry sectors. They proposed an enterprise knowledge meta model which consisted of three main elements: ‘enterprise goals’ which are realized by ‘enterprise processes’ and implemented by ‘information system components’. Each element has its own meta model. The purpose of this enterprise knowledge was the improvement of the enterprise in order to deal with changes. They recommended that enterprise change management should be seen as a process of identifying business goals and relating business processes to these goals. Though the authors did not have any concrete
- 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 and 90: Dealing with Known Unknowns: A Goal
- Page 91 and 92: Dealing with Known Unknowns: A Goal
- Page 93 and 94: Dealing with Known Unknowns: A Goal
- Page 95 and 96: Dealing with Known Unknowns: A Goal
- Page 97 and 98: Dealing with Known Unknowns: A Goal
- Page 99 and 100: Dealing with Known Unknowns: A Goal
- Page 101 and 102: Dealing with Known Unknowns: A Goal
- Page 103 and 104: Dealing with Known Unknowns: A Goal
- Page 105: Dealing with Known Unknowns: A Goal
- Page 109 and 110: Dealing with Known Unknowns: A Goal
- Page 111 and 112: 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