|Constructing a state machine as part of the code generator [message #1769892]
|Fri, 04 August 2017 16:10
| reza ahmadi
Registered: September 2016
In one scenario I need to fill an empty state machine before code generation. Currently I do that before I generate code, which means I change the model, which is not the perfect solution for many reasons. For instance, I want the model to remain intact. In addition, the model gets too heavy as it is likely that a state machine gets too long. Also to avoid an extra step for users.
So, in which phase of the code generation I can modify a state machine. By modify I mean I construct a state machine from an empty state machine with an initial structure.
My scenario is for testing. I create a long state machine as a string of states and transitions that communicates with a model bidirectionally for testing purposes. I'd prefer change the code generation so my test cases state machine is generated by code generation (of course in a step before actual C++ code generation) rather than by changing the model and storing data in model.
[Updated on: Fri, 04 August 2017 16:16]
Report message to a moderator
|Re: Constructing a state machine as part of the code generator [message #1770030 is a reply to message #1769892]
|Mon, 07 August 2017 15:43
| Ernesto Posse
Registered: March 2011
I'm not entirely sure I understand what exactly you are trying to do, but it sounds like you want to be able to create a Capsule's state machine automatically and generate code for this automatically constructed state machine. If this is indeed what you want, Papyrus-RT does not directly support this, but it is open-source, so you can extend or modify it. I think you have several options:
1) No modification of Papyrus-RT: create a separate plugin that is activated, for example, when you click on a Capsule or empty State Machine in the Model Explorer, and generates the state machine contents (based on whatever parameters you have, possibly other model elements). This modifies the model in memory. Then you can invoke the normal code generator. In this scenario, your plugin would be working with the UML model, but you could use the UML-RT façade which is an API that helps you create UML-RT model elements like states and transitions (see the org.eclipse.papyrusrt.umlrt.uml plugin). This API provides methods to create façade model elements from existing UML elements, or new façade model elements.
2) Create your own state machine generator extension without modifying Papyrus-RT: in theory this should be used only if you want to customize the generated code. If you want to generate code normally you shouldn't need to create a state machine generator extension, but it could be used to create your own state machine during generation. There is a guide in the wiki on writing such extensions (at https://wiki.eclipse.org/Papyrus-RT/Developer/Design/0.8/Codegen_Extension). It may be a bit outdated, but I think it should still work. In this case, the state machine generator extension doesn't work directly with the UML model, but rather with an intermediate representation which we call "XtUML-RT" (it's metamodel is in the org.eclipse.papyrusrt.xtumlrt.*.model plugins). This representation also provides a factory to create UML-RT elements.
3) Modify the Papyrus-RT code generator: I would not recommend this, but here you have more options, depending on whether you want to create or modify your state machines in the UML model or in the XtUML-RT model. The current version of Papyrus-RT doesn't provide a mechanism to "inject" additional phases in the code generation process, so you would have to override the existing workflow. There are several classes and methods where this could take place. The "main" class of the code generator is "AbstractUMLRT2CppCodeGenerator" in the org.eclipse.papyrusrt.codegen.cpp plugin. The "main" method is called "generate", and it receives as input a list of UML model elements. Later, in the "doGenerate" method, these are translated to the intermediate XtUML-RT representation. So you could add calls to whatever method you write to create the state machine, either as a UML model element or as an XtUML-RT model element.
I've recommend to do option #1 and keep your own state machine creation as a separate task, and do option #2 only if you need to generate different code than what is already generated. Option #3 should be only a last resort, if you are unable to do it with options #1 or #2.
Powered by FUDForum
. Page generated in 0.02811 seconds