On Tue, Dec 18, 2018 at 4:51 AM Stefan Günther <[email protected]> wrote:
> Hi all! > > I'm currently working on a PyDia Code Generator für Finite State > Machines (target Code is C), based on Dia UML diagrams. I've looked into > existing solutions, but could not find anything that suited all of our > needs, so I decided to go for a new one. > > As we need some compatibility with our old system (that needs to be > replaced sometime), we need to use "nested" diagrams. As there's no > native support for that in Dia (if I understand correctly), I decided > to use UML-Objects in the diagrams to provide a name and a filename (or > path) for a diagram that should be embedded in the StateMachine. > > To do that, I would need to parse a (previously not opened) file from > the PyDia Interpreter, so that I could pass the 'data' object to a > recursive call to begin_render() in my Generator. Unfortunately neither > the code (implementation and plugins) nor the documentation I found > could answer my question. Is there a way to do that? > > I appreciate any comment that helps with the solution I asked for or > other useful hints on using PyDia or Dia in general for this purpose. I > really see great potential using Dia for FSM Code Generators (especially > in the field of embedded electronics or machine controllers, that are > often still written in plain C) as there are only few alternatives that > all have their own drawbacks. > > Thanks, > Stefan > Hi Stefan, I would advise you to take a look at the source code for dia2code original C code (not the new C++ port), especially at the logic for SQL DDL generation. It will show you how to traverse a class diagram with associations and you can probably extrapolate that to your needs with state machines. Moreover, the dia2code C code already has some routines that are common amongst the different code generation options. One interesting feature you will notice is that objects are traversed first and then the associations on a second round for ALTER statements. It’s a practical solution which does not require to figure out the associations beforehand. One unintended feature of this which I think you will find interesting (and that we use extensively) is splitting the class diagram into different DIA files. So for example if we have a 400 table database, we can split the diagram into “realms” of tables. By putting an empty class (just the class name with no attributes) we can “connect” to the actual class defined in another diagram, because the generator will not generate DDL code for the empty class but will pick up the association, thus generating the foreign key. I noticed this “ feature” whilst I was contributing to some patches to the SQL DDL part of the dia2code project. May I suggest that instead of starting off a new project, that you reach out to the dia2code guys and contribute to that project instead. Best, Alex > -- > Stefan Günther <[email protected]> > _______________________________________________ > dia-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/dia-list > FAQ at http://live.gnome.org/Dia/Faq > Main page at http://live.gnome.org/Dia > >
_______________________________________________ dia-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
