Dissertaç ˜ao de Mestrado Mestrado em Engenharia Informática Jo ...

More documents

Recommendations

Info

3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.1. Architectural Requirements 3.1 Architectural Requirements Before approaching the proposal of a framework for the automatic application configuration, the tool requirements must be identified. This section presents the functionalities which the tool is expected to provide, in the form of use cases. A use case defines a goal-oriented set of interactions between external actors and the tool. Following is a list of functional and non- functional requirements: 1. The user must be able to convert a configuration file syntax from its original syntax to a generic one, independently of the application. Description: The user must be able to try parsing the configuration file with the available parsers. Non-functional requirements: Performance: The generated file with the generic syntax must be as simple as possible. 2. The user must be able to define grammars for configuration file languages. Description: If there are no suitable parsers for a given configuration file, the user must be able to define a grammar that recognizes the new configuration file language. Non-functional requirements: Usability: The grammar definition syntax should be a broadly adopted one. Usability: To ease the parser generation process, the user must be able to iterate through the previously built grammars so as to rollback any change made on a grammar. 3. The user must be able to produce a parser from a grammar. Description: When the user builds a grammar for a new configuration file language, there must be a means to compile that grammar in order to generate a parser. Non-functional requirements: Usability: The user must be able to add parsers built outside the tool. 4. The user must have access to the parser compilation trace. Description: When a grammar is compiled, the user should be able to check on the parser compilation trace to see if it was successfully compiled or whether any error persists in the grammar declaration. 22
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.1. Architectural Requirements Non-functional requirements: Usability: The error messages must clearly identify the source of the error. 5. The user must receive information relative to the grammar fitness with a given configuration file. Description: When the user attempts at parsing a configuration file with a given parser, he/she must be informed if the parsing was successful or not, as well as the quantity of file recognized by that parser. Non-functional requirements: Usability: The sections of the configuration file that were parsed and those that were not must be clearly identified. 6. The user must be able to store a functional parser generated by the tool, in order to be used on later tool runs. Description: When the user checks a new parser to parse a configuration file entirely, he/she must be able to store it in a repository so it can be reused. Non-functional requirements: Security: The user must be able to see the parsing outcome in order to check if the parser is indeed operating as intended to. 7. The user must be able to reconvert a configuration file syntax from generic syntax to the original one. Description: Given a configuration file in generic syntax, the user must be able to convert it into its original syntax, keeping its functionality unharmed. 8. File conversion must not eliminate comments. Description: On the original to generic syntax conversion, the comments should be stored in order to show up in the final file. 9. The user must be able to halt the tool execution at some point and continue the configuration process later. Description: In the middle of the configuration process (i.e., right after the original to generic syntax conversion), the administrator should be able to halt the execution flow, have the necessary data stored, such as the file in the generic syntax or the tentative 23
Page 1: Universidade Nova de Lisboa Faculda
Page 5: To my family and friends, who suppo
Page 9: Sumário Entre os sectores de tecno
Page 12 and 13: CONTENTS 3.5 Modifying the Configur
Page 15: List of Figures 2.1 Virtual applian
Page 19 and 20: List of Listings 1.1 Apache configu
Page 21 and 22: 1 Introduction This dissertation pr
Page 23 and 24: 1. INTRODUCTION 1.2. Problem Descri
Page 29: 1. INTRODUCTION 1.5. Document Organ
Page 32 and 33: 2. STATE OF THE ART AND RELATED WOR
Page 41: 3 An application reconfiguration fr
Page 45 and 46: 3. AN APPLICATION RECONFIGURATION F
Page 55: 3. AN APPLICATION RECONFIGURATION F
Page 58 and 59: 4. AN IMPLEMENTATION 4.2. Parser Ge
Page 60 and 61: 4. AN IMPLEMENTATION 4.4. Data Stru
Page 62 and 63: 4. AN IMPLEMENTATION 4.4. Data Stru
Page 64 and 65: 4. AN IMPLEMENTATION 4.5. Original
Page 66 and 67: 4. AN IMPLEMENTATION 4.6. Generatio
Page 68 and 69: 4. AN IMPLEMENTATION 4.7. Generic t
Page 71 and 72: 5 Framework Evaluation Chapter 3 pr
Page 73 and 74: 5. FRAMEWORK EVALUATION 5.2. Operat
Page 83 and 84: 5. FRAMEWORK EVALUATION 5.3. Perfor
Page 85: 5. FRAMEWORK EVALUATION 5.3. Perfor
Page 88 and 89: 6. INTEGRATION WITH VIRTU 6.2. VIRT
Page 90 and 91: 6. INTEGRATION WITH VIRTU 6.3. VIRT
Page 92 and 93:
6. INTEGRATION WITH VIRTU 6.3. VIRT
Page 94 and 95:
6. INTEGRATION WITH VIRTU 6.4. SmAR
Page 96 and 97:
6. INTEGRATION WITH VIRTU 6.4. SmAR
Page 98 and 99:
6. INTEGRATION WITH VIRTU 6.5. Summ
Page 100 and 101:
7. CONCLUSION AND FUTURE WORK 7.1.
Page 103 and 104:
A.1 OGC sequence diagram A Appendix
Page 105 and 106:
B.1 MySQL Configuration file # # Th
Page 107 and 108:
B. APPENDIX - EVALUATION B.1. MySQL
Page 109 and 110:
B. APPENDIX - EVALUATION B.2. Apach
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
B. APPENDIX - EVALUATION B.3. Eclip
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
B. APPENDIX - EVALUATION B.4. Perfo
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Bibliography [Ama09] Amazon. Amazon
Page 181:
BIBLIOGRAPHY [Sol09a] Evolve Space
show all

Dissertaç ˜ao de Mestrado Mestrado em Engenharia Informática Jo ...

Create successful ePaper yourself

Delete template?

Save as template?