ASD:Suite - Code Generation 2013 Verum 1

Transcription

1 ASD:Suite - Code Generation 2013 Verum 1

2 The generated ASD component in code is actually the component factory. This component factory is used to generate component instances. ASD component creation is done automatically by generating the correct plumbing: used components are created automatically, application interfaces are queried, notification interfaces are registered, etc. The same applies for component destruction. ASD:Suite - Code Generation 2013 Verum 2

3 The following is a list of general model properties available for each model created by the ASD:Suite: Filename: contains the full path to the ASD model. This information is readonly. Version: specifies the (user-defined) version of the ASD model. Project: specifies the project name. Author: specifies the author(s) of the ASD model. Component Type: designates whether the component is a singleton or a multiple. This property is only present for design models. Implements: shows the implemented service. This information is entered automatically and is read-only. Dates these values are automatically entered by the ASD:Suite client and are not editable: Created: ASD model creation date. Modified: date of last model modification. Description: a free-format text area allowing a user to provide a detailed description of the component. ASD:Suite - Code Generation 2013 Verum 3

4 The following can be set as general code generation properties: Language: the target programming language for the generated code. Version: identifies the ASD:Suite version to be used when generating code. This has a twofold purpose: 1. Specifies the version of the code generator you wish to use 2. Specifies the verification version to be used for model checking Note - Each version of a code generator is automatically linked to a verification version which is in turn linked to a specific ASD:Runtime version. This is why you must select a Code Generator version number before running a verification on a model for the first time. Code generator version = Verification version = ASD:Runtime version ASD:Suite - Code Generation 2013 Verum 4

5 For each target language, the following code generation options are present: Generate debug info: when checked (default value), this will add trace statements in the code. Output paths: specifies the location where the generated source code will be stored. If the browse function is used to select an output location, the saved path will be the relative path to the location of the interface/design model if this is on the same disk or media as the ASD:Suite client. If another disk or drive is specified, the saved path will be absolute. If the browse function is not used but a path is copied or typed in, the saved path will be exactly what you have input, even if it is invalid If the defined path is not present, it will be created for you. If the path is left empty the same location as the source model files is used If a generated source code file exists and has not been renamed or made read-only, this previous file will be overwritten during subsequent code generation without any warning. If a generated source code file is set to read-only, subsequent code generation stops and reports that it cannot overwrite the existing file. Header and Footer Information: this is the path and name of a file containing pre-defined header and footer information for code customisation. Include/import: specifies the file(s) where the data types used in the method calls of the application interfaces will be resolved. This should be entered in language specific format. Syntax checks are done on the Include/import field content. C & C++ - #include statements, one per line. Java - import statements, one per line. ASD:Suite - Code Generation 2013 Verum 5

6 If the Generate Debug Info checkbox is checked, the ASD:Suite will add tracing information to the generated code. This information contains: The component name The state name The trigger name This information is reported every time a trigger function is entered prefixed with "-->" and every time this trigger function is exited, prefixed with "<--". The trace information is passed to a language specific tracing mechanism: For C++, this is asd::diagnostics::info, defined in a trace handler in the ASD:Runtime header file diagnostics.h. There is a default implementation using std::cout, but this trace handler can be overridden. For C, the generated code uses the tracing mechanism implemented by the OSAL. This is customisable by overriding the default OSAL implementation of the print function, or by redefining the trace macros. ASD:Suite - Code Generation 2013 Verum 6

7 The trace information is passed to a language specific tracing mechanism. For C#, the generated code uses the.net System.Diagnostics.Trace facility. This can be customized by overriding the default supplied trace handler with your own customised trace handler. For Java: Diagnostics.trace(new DiagnosticsInfo(DiagnosticsInfo.DirType.exit, "TestCD", name, "ITestUCCB", "n")); // example trace statement in generated code class RegisterCBHandler implements DiagnosticsTraceListener { // example trace handler class public void tracehandler( DiagnosticsInfo info ) {} } RegisterCBHandler ih = new RegisterCBHandler(); // example override trace handler Diagnostics.setIllegalHandler(ih); ASD:Suite - Code Generation 2013 Verum 7

8 When generating C++ code, the following files are generated: Each interface model results in a C++ header file <modelname>interface.h with the following: At least one application interface Optional notification interface(s) An ASD component factory interface with GetInstance(), ReleaseInstance(), a GetAPI() for each application interface. If notifications are present, a RegisterCallback() for each notification interface is also included. Each design model results in a C++ source file <modelname>component.cpp with an implementation of the above mentioned interfaces based on the state pattern. ASD:Suite - Code Generation 2013 Verum 8

9 When generating C code, the following files are generated: Each interface model results in a C header file <modelname>interface.h with the following: At least one application interface Optional notification interfaces(s) An ASD component factory interface with GetInstance(), ReleaseInstance(), a GetAPI() for each application interface, and, if notifications are present, a RegisterCallback() for each notification interface Each design model results in a C include file <modelname>componentimpl.h and source file <modelname>component.c with an implementation of the above mentioned interfaces based on the state pattern. ASD:Suite - Code Generation 2013 Verum 9

10 When generating C# code, the following files are generated: Each interface model results in two C# header files: 1. <modelname>interface.cs with the following: At least one application interface Optional notification interface(s) 2. modelname>partialcomponent.cs with the following An ASD component factory interface with GetInstance(), ReleaseInstance(), a GetAPI() for each application interface, and, if notifications are present, a RegisterCallback() for each notification interface. The interfaces are kept separate to allow pure interface assemblies. Each design model results in a C# source file <modelname>component.cs with an implementation of the above mentioned interfaces based on the state pattern. The component factory is based on the partial class (i.e. the rest) as defined in the header file. For hand-written components, this partial class needs to be completed. ASD:Suite - Code Generation 2013 Verum 10

11 When generating Java code, the following files are generated: Each interface model results in several Java files: 1. <modelname>interface.java 2. For each application interface <application_interface>.java 3. For each notification interface <notification_interface>.java Each design model results in: 1. An ASD component factory interface <modelname>component.java with GetInstance(), ReleaseInstance(), a GetAPI() for each application interface, and, if notifications are present, a RegisterCallback() for each notification interface. The interfaces are kept separate to allow pure interface assemblies. 2. Component implementation Component.java with an implementation of the above mentioned interfaces based on the state pattern. ASD:Suite - Code Generation 2013 Verum 11

12 Each generated component has the same structure based on well known patterns: A component has a proxy that enters as the entry point of all normal application interface triggers and notification triggers. It is the proxy where notifications are posted into a decoupled queue. A component also uses a state pattern: Per state machine there is one context and abstract state class. Per SBS state there is also one concrete state. The abstract state also contains the default implementation for each trigger, which is an assertion. This default behaviour is overridden and an implementation is generated only for triggers in transitions that produce a true action. ASD:Suite - Code Generation 2013 Verum 12

13 The structure of the generated code maps onto the internal structure of the component: First, all client threads are synchronized to preserve the monitor semantics. Once a client thread has passed this first synchronization barrier, it also needs to synchronize with the DPC thread to preserve the monitor semantics. Either the DPC thread or the client thread then has access to the state machine and can perform the requested action. If necessary, context calls are then made to the used service from the same thread. When we map this to the generated items, then we can see that: The proxy is the entry point for both the implemented application interface(s) as well as the implemented notification interface(s). The calls on the implemented application interface(s) are forwarded to the context, and calls on the notification interface are queued. The context is where the client calls on the implemented application interface(s) are synchronized with the DPC thread. The state is where the actual processing is done. ASD:Suite - Code Generation 2013 Verum 13

14 The code generator allows insertion of user provided text such as copyright statements or namespace specification in the generated source code. The text file containing this text is specified for each ASD model file via the ASD:Suite code generation properties dialog as shown earlier. The following rules apply with respect to generation of headers and footers: The header and footer text file can contain a mixture of directives and plain text lines in any order. This enables it to serve as a template controlling the generated output source file contents. Plain text lines are simply copied through to the generated output file without modification. This means that these plain text lines may lead to the compiler errors during the build process. One or more optional <include> directives can be specified in any order anywhere in the text file. The contents of these text files are then copied into the generated file. You should specify only one <include> directive per line. If the specified file in an <include> directive cannot be opened for whatever reason when generating source code, the directive is completely ignored and has no effect. One or more optional <generate/> directives can be specified, which designates the point at which the generated code is inserted into the output file. If omitted, the generated code is added to the output file after the last line in the specified text file. If multiple <generate/> directives are present in the file, only the first one is processed; the others are ignored as though they were not present. Both DOS and UNIX style line-endings are allowed. All include files must be 8-bit ASCII encoded. Examples are given in the following slides. ASD:Suite - Code Generation 2013 Verum 14

15 This is an example of how the header/footer information can be used. At the point of the statement <include>copyrightblock.txt</include> in the header and footer include file the text of the CopyRightBlock.txt file is inserted in the generated code. At the point of the <generate/> statement the generated code is inserted. ASD:Suite - Code Generation 2013 Verum 15

16 This is how the generated code will look using the header and footer information from the previous page. ASD:Suite - Code Generation 2013 Verum 16