D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

Recommendations

Info

Legend: Dotted arrows correspond to transitions that were part of GP 2.1.1 test model and has been removed in the model of GP 2.2, bolded arrows represent new transitions, dashed arrows correspond to modified transitions, while full arrows correspond to transitions not impacted by evolution of requirements. Fig. 7. Test Model for GP specifications 2.1.1 and 2.2 Legend: OCL code for the transition setStatusApp from CARD-LOCKED to TERMINATED requested by an Application with cardTerminate privilege. The code is annotated with the identifiers of the goals G5 (@REM G5) and G12 (@REM G12) covered by the test cases Test 3 and Test 5. Fig. 8. OCL code for SetStatus APDU command setting card state to TERMINATED With respect to the completion of the change propagation process, we can see that the changes in the card life cycle related to the state TERMINATED has been propagated from the requirement model to the test model: two new test cases Test 4 and Test 5 and two updated test cases Test 2 and Test 3 corresponding to G5 and its subgoals has been included in the evolution test suite. Test 4 and Test 5 correspond to an Application executing setStatus command without and with Terminate privilege respectively, while Test 2 and Test 3 are related to the execution of the setStatus command performed by a Security Domain without and with Terminate privilege. 8 Related Works Change management is well known for being a difficult and costly process. However, only some requirement engineering proposals provide support for handling change propagation and for change impact analysis. Goal-oriented approaches such as KAOS, 12
Table 5. Test Suite for GP-2.2 Transition Covered Test Requirement Status SetStatusForb Test 1 G 6, G 11 Re-executed SetStatusNopSD Test 2 G 5, G 8, G 11 Updated SetStatusSD Test 3 G 5, G 8, G 12, G 15, G 16 Updated SetStatusNopApp Test 4 G 5, G 11, G 15 New SetStatusApp Test 5 G 5, G 12, G 15, G 16 New Secure Tropos, and Secure i* [24, 11, 18] provide good support for change propagation because they are based on goal models which explicitly show relationships and dependencies between goals, and also support the modeling and the analysis of dependencies between agents. Tanabe et al. [22] propose an approach to requirements change management that supports version control for goal graphs and impact analysis of adding and deleting goals. UMLsec [15] is a model-based approach to security engineering which supports change impact analysis by using model-checking and theorem proving techniques. Problem-oriented approaches also support change impact analysis to some extent. Haley et al. [13] use argument satisfaction as a way of verifying that a specification satisfies a requirement in a given context. Lin et al. [16] do not provide explicit support for change impact analysis, but this can be achieved by using problem analysis when new security problems are identified. Chechik et al. [4] propose a model-based approach to propagate changes between requirements and design models that utilize the relationship between the models to automatically propagate changes. Hassine et al. [14] present an approach to change impact analysis that applies both slicing and dependency analysis at the Use Case Map specification level to identify the potential impact of requirement changes on the overall system. Lin et al. [17] propose capturing requirement changes as a series of atomic changes in specifications and using algorithms to relate changes in requirements to corresponding changes in specifications. With respect to change management in test engineering, several works about regression testing have been proposed.There are two kinds of regression testing: code-based regression testing and specification-based regression testing. Code-based testing is limited to unit testing, and is mainly applied to concurrent programs ([7]). At program level, in [6], the authors describe how to select a tests’ subset to be used for regression testing. This subset is defined by using data coverage of the test w.r.t. the changes that occurred in a program. In the specification-based regression testing field, a variety of techniques can be found, based on various selection criteria, such as requirement coverage [5]. In [23] the authors use EFSM models for safe regression technique based on dependence analysis. They select test cases and compute the regression test suite by identifying three types of elementary modifications applicable to a machine (addition, deletion, modification of a transition). Our approach is grounded on these principles, but improves them by keeping the test history. In addition, we consider three test suites fulfilling different purposes. In [8] the authors propose a methodology to identify impacted part of the model. A list of all depending operations is created for each operation modification. They identify all parts of dynamic UML diagrams in which the behaviour of this operation can 13
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: Legend: Goals surrounded by dashed
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 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

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

Delete template?

Save as template?