Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

More documents

Recommendations

Info

Chapter 9. openETCS Generator Application 9.5.2. libDSM Implementation Since the base class CSyntaxTransformer only provides general attributes and methods for all concrete transformer classes, the implementation of CGOPPRRTransformer is explained in detail. The converting process starts with the parsing of a GOPPRR XML file by the m_XMLParser object, which delivers the content of the file as DOM. Furthermore, the XML file is validated according to the GOPPRR XSD from Section 4.3 to ensure that only valid GOPPRR instances are used. Since the DOM is mainly a representation of the XML file in a certain C++ class or rather object structure, the whole document object model has to be processed by the CGOPPRRTransformer. Due to the structure of the GOPPRR C++ abstract syntax model and the XSD, concrete instances of GOPPRR elements are only used on the project level while on lower levels for graphs, objects, ports, properties, roles, and relationships other elements are only referenced. For the implementation in C++, those are class instances and pointers [79] to them. In the XSD, a special XML element is defined for references to elements, which uses the OID (see Section 4.2) instead of memory addresses [79] for pointers. A certain issue is the fact that graphs structures can be defined in a quasi unlimited way by decompositions and explosions. Therefore, the first approach was also a recursive implementation of the CGOPPRRTransformer. This means if a reference to any element type was encountered in the DOM, this reference was followed (by the OID) until a concrete instance was met. The big advantage of this approach is that it is ensured that all references are resolved for the GOPPRR C++ abstract syntax model. Unfortunately, this also caused severe performance problems. Mainly, not by the recursion itself but by the usage of methods in the libxml++ library to resolve XPath [42] expressions to find directly the referenced element. To handle this problem, a certain condition of the GOPPRR C++ abstract syntax model and XSD was used to implement the conversion in an iterative way: Since every GOPPRR element instance must exists in the parent project, all concrete instances can be created in the project by a single iterative step through the complete DOM while all references are left unset. In only one further iterative step, all references can be then easy initialised because all instances are guaranteed to exist, which is enforced by the GOPPRR XSD. This implementation approach provides a much better performance than the recursive one and is finally used in the CGOPPRRTransformer class. Additionally, it implicitly solves a problem with recursive sub-graph relations if a GOP- PRR object has a decomposition to a GOPPRR graph in which this object is again present. Proceeding such a relation in a recursive way would directly lead to an endless execution without termination. Of course, such recursive sub-graph relations are explicitly forbidden for a openETCS model by the static semantics in Subsection 7.5.2, but it must be emphasised that according to the tool chain and the integration of the OCL in Chapter 4, the corresponding constraints are checked on the GOPPRR C++ abstract syntax model. Thus, the GOPPRR XML file can always hold such an invalid relation. Nevertheless, the recursive implementation is still available for references purposes. The issue to insure that the whole intermediate XML model is used is also related to Req.9. The CGOPPRRSyntaxTree mainly encapsulates a CProject instance and does not have to 170
9.5. Implementation be discussed in certain detail. 9.5.3. openETCS Generator Implementation Obviously, CCPPGenerator is the most complex generator class for creating the source code, which instantiates the classes of the openETCS domain framework. Since nearly all objects in the openETCS C++ abstract syntax model are relevant for the domain framework instantiation, the complete C++ model must be traversed. Furthermore, the order of the class instantiations is not arbitrary because some classes need other classes directly during their construction [79]. For example, each CEVCState object needs its parent CEVCStateMachine instance to register itself as new state. Also, for other classes, it is necessary to primary create a vector of pointers to other already existing class instances, which are then used during the object construction. This is the case, for example, for CDataFlow objects, which need a vector of CFunctionBlock pointers, which defines the objects used in the data flow. Therefore, several helper methods were implemented to separately handle the generation of different model parts and to provide a better structured implementation. For clarification, the whole generation process is shown as UML interaction diagram from the view of the CMain class. In the first step, the GOPPRR C++ abstract syntax model is created by CreateSyntax- FromFile() method of the transformation class. This creates the CGOPPRRSyntaxTree object m_pTree, which additionally creates the underlying m_pProject with the GOPPRR C++ abstract syntax model. Directly afterwards, the underlying CProject instance is returned by the GetProject() method and checked for validity according to the static semantics because the generation process should only be executed for valid models. CCPPGenerator Implementation The generation of the C++ source code for the openETCS domain framework instantiation is started by the Generate() method of the m_CppGenerator object. Initially, the GenerateRootGraph() method generates all sources for the instantiation of the parent CEVCStateMachine object after the source file’s initial part 5 was added by the GenerateHeader() method. This is followed by the generation of all other objects by the related helper methods. All instantiations are generated surrounded by a main() function block [79] in order that the source code file can be directly compiled as executable binary. Since only valid models are used for generation, the CCPPGenerator methods do not need a special error handling for faults related to the model. Only general faults, as segmentations, should be handled or, even better, avoided. Thus, most of the implementation of the CCPPGenerator methods is mostly the iteration over GOPPRR C++ abstract syntax model objects and does not need to be discussed here in more detail or by examples. More complicate is the generation of the execution order of function block objects, which importance was derived and explained in Section 7.6 and Section 7.7. Simplified expressed, function block objects should be executed in the order of the direction of the data flow. In cases of open loops, this means starting from the objects that only have outputs. For closed loops, the start and end object cannot be defined in a general manner if they do not have any element 5 with comments about creation time, model name, etc. 171
Page 1:
Open Source Software for Train Cont
Page 4 and 5:
Datum des Promotionskolloquiums: 21
Page 7 and 8:
Acknowledgments I would like to tha
Page 9:
Abstract This document describes th
Page 12 and 13:
Contents 3.3.3. Rascal . . . . . .
Page 14 and 15:
Contents 8.4. Behavioural Design .
Page 16 and 17:
Contents D.3. Domain Framework Mode
Page 18 and 19:
List of Figures 6.4. Simple CORBA u
Page 20 and 21:
List of Figures 10.27. General read
Page 22 and 23:
Chapter 1. Introduction Railway Con
Page 24 and 25:
Chapter 1. Introduction MontiCore M
Page 26 and 27:
Chapter 1. Introduction ERTMS Forma
Page 29:
Part I. Background 9
Page 32 and 33:
Chapter 2. Concepts for Safe Railwa
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
Chapter 3. Domain-Specific Modellin
Page 44 and 45:
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
Page 54 and 55:
Page 56 and 57:
Page 59 and 60:
4The GOPPRR Meta Meta Model - An Ex
Page 61 and 62:
4.1. Concrete Syntax Description Fo
Page 63 and 64:
4.2. GOPPRR C++ Abstract Syntax Mod
Page 65 and 66:
4.2. GOPPRR C++ Abstract Syntax Mod
Page 67 and 68:
4.5. The Object Constraint Language
Page 69 and 70:
4.5. The Object Constraint Language
Page 71 and 72:
4.6. Tool Chain where artefacts are
Page 73 and 74:
4.7. Conclusion External Artefacts
Page 75:
Part II. Dependability 55
Page 78 and 79:
Chapter 5. Verification and Validat
Page 80 and 81:
Page 82 and 83:
Page 85 and 86:
6Security in Open Source Software A
Page 87 and 88:
6.1. Memory Management Open Meta Me
Page 89 and 90:
6.2. Hardware Virtualisation a fixe
Page 91 and 92:
6.2. Hardware Virtualisation in a v
Page 93 and 94:
6.2. Hardware Virtualisation Again,
Page 95 and 96:
6.2. Hardware Virtualisation the fa
Page 97:
Part III. openETCS Case Study 77
Page 100 and 101:
Chapter 7. openETCS Meta Model far
Page 102 and 103:
Chapter 7. openETCS Meta Model gEVC
Page 104 and 105:
Chapter 7. openETCS Meta Model gEVC
Page 106 and 107:
Chapter 7. openETCS Meta Model gMai
Page 108 and 109:
Chapter 7. openETCS Meta Model Outp
Page 110 and 111:
Chapter 7. openETCS Meta Model thei
Page 112 and 113:
Chapter 7. openETCS Meta Model gSub
Page 114 and 115:
Chapter 7. openETCS Meta Model The
Page 116 and 117:
Chapter 7. openETCS Meta Model can
Page 118 and 119:
Chapter 7. openETCS Meta Model The
Page 120 and 121:
Chapter 7. openETCS Meta Model List
Page 122 and 123:
Chapter 7. openETCS Meta Model 5 s
Page 124 and 125:
Chapter 7. openETCS Meta Model 7.5.
Page 126 and 127:
Chapter 7. openETCS Meta Model 12 )
Page 128 and 129:
Chapter 7. openETCS Meta Model 7.5.
Page 130 and 131:
Chapter 7. openETCS Meta Model Thus
Page 132 and 133:
Chapter 7. openETCS Meta Model In t
Page 134 and 135:
Chapter 7. openETCS Meta Model Valu
Page 136 and 137:
Chapter 7. openETCS Meta Model This
Page 138 and 139:
Chapter 7. openETCS Meta Model and
Page 140 and 141: Chapter 7. openETCS Meta Model 7.8.
Page 142 and 143: Chapter 8. openETCS Domain Framewor
Page 180 and 181: Chapter 9. openETCS Generator Appli
Page 200 and 201: Chapter 10. openETCS Model No Power
Page 202 and 203: Chapter 10. openETCS Model c4 bool
Page 204 and 205: Chapter 10. openETCS Model c1 c8 c1
Page 206 and 207: Chapter 10. openETCS Model Applicat
Page 208 and 209: Chapter 10. openETCS Model c1 c25 c
Page 210 and 211: Chapter 10. openETCS Model Initiali
Page 212 and 213: Chapter 10. openETCS Model Reverse
Page 214 and 215: Chapter 10. openETCS Model 0 (CONST
Page 216 and 217: Chapter 10. openETCS Model Current
Page 218 and 219: Chapter 10. openETCS Model c7 bool
Page 220 and 221: Chapter 10. openETCS Model Current
Page 222 and 223: Chapter 10. openETCS Model The purp
Page 224 and 225: Chapter 10. openETCS Model 10.3.3.
Page 226 and 227: Chapter 10. openETCS Model be expla
Page 228 and 229: Chapter 10. openETCS Model 10.4.4.
Page 231 and 232: 11 openETCS Simulation Generally, a
Page 233 and 234: 11.2. Platform Specific Model for t
Page 239 and 240: 11.3. Simulation Model Figure 11.6.
Page 241 and 242:
11.3. Simulation Model 11.3.2. CDMI
Page 243 and 244:
11.3. Simulation Model sets the Boo
Page 245 and 246:
11.3. Simulation Model Entering_Dri
Page 247 and 248:
11.3. Simulation Model The states o
Page 249 and 250:
11.3. Simulation Model Figure 11.13
Page 251 and 252:
Page 253 and 254:
Page 255:
11.6. Conclusion about warnings, fa
Page 258 and 259:
Chapter 12. Conclusion and Outlook
Page 261:
Part IV. Appendix 241
Page 264 and 265:
Appendix A. GOPPRR to MOF Transform
Page 266 and 267:
Appendix B. openETCS Meta Model Con
Page 268 and 269:
Page 270 and 271:
Page 273 and 274:
DopenETCS Domain Framework D.1. Dom
Page 275 and 276:
D.2. Domain Framework Source Code 8
Page 277:
D.3. Domain Framework Model 32 m_pT
Page 280 and 281:
Appendix E. openETCS Generator 39 <
Page 282 and 283:
Appendix E. openETCS Generator 200
Page 284 and 285:
Appendix E. openETCS Generator 46 4
Page 287 and 288:
FMetaEdit+ Generators F.1. GOPPRR X
Page 289:
GopenETCS Unit Testing G.1. Unit Te
Page 292 and 293:
Appendix H. openETCS Simulation 14
Page 294 and 295:
Page 296 and 297:
Page 299 and 300:
Glossary ANTLR ANother Tool for Lan
Page 301 and 302:
Glossary EVC An European Vital Comp
Page 303 and 304:
Glossary OEM An original equipment
Page 305:
Glossary XML The Extensible Markup
Page 308 and 309:
Bibliography [12] “EN 50128 - Rai
Page 310 and 311:
Bibliography [39] ——, ““Ope
Page 312 and 313:
Bibliography [69] T. J. Parr and R.
Page 315 and 316:
Index Artefact, 51 Automatic train
Page 317 and 318:
Index Linux, 149 Memory management,
show all

Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

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

Delete template?

Save as template?