Am 08.04.2013 um 08:36 schrieb Tudor Girba <[email protected]>: > Hi Norbert, > > You should indeed look at Roassal. > > Could you give us an example of the data you have? Perhaps we can get you > started with an example. > Did you take a look at the document I mentioned in my last mail? ([2]) It is a huge state machine that needs to be done. I'm in the progress to figure out how I should write the code and analyze it in order to get the right data to be able to produce a diagram that is close to the document. I had the idea to use pragmas for annotating specific code parts. But then it leads to have a lot of pragmas that do kind of a documentation of the process. This would double the code which is the documentation of the process. And it will drift away like documentation always does. Not to do annotations means I need to execute code in order to solve the ambiguity of senders when analyzing code. So the current approach will be something like using object as method wrappers to record flow (or use moose instead). Use annotations in methods to filter the important flow points and write a detailed set of test case to solve amount of case/branch possibilities. Last but not least I need to do extra annotations to assign flows to processes.
Does this answer your question? I just need to find a good mapping from code to the elements of a state diagram. The rest will be struggeling with layouts (I hope) Norbert > On Apr 4, 2013, at 11:28 AM, Norbert Hartl <[email protected]> wrote: > >> Hi Stephan, >> >> Am 04.04.2013 um 10:48 schrieb Stephan Eggermont <[email protected]>: >> >>> Hi Norbert, >>> >>> Could you get some inspiration from the PetitParser browser? >>> What would you need more? Roassal could do with some >>> more shapes, but is pretty good for something like that. >>> >> with PetitParser browser you mean the PetitParser UI? And what aspect you >> are referring to? The linked node diagram of productions? >> >> Can you elaborate on the capabilities of Roassal? I had a look at Roassal. >> As far as I understand it is suited for larger distributions of rather >> homogenous shapes. I know you can choose different shapes for different >> views. But my case would be more a "constructing" of an diagram image. >> >> Ok, the real plan. I'm implementing an communication stack [1] where the >> central behavior is a huge state machine / flow chart description [2] (the >> state machine / flow chart is described on page 30 to 60). This is a task >> that is hard to do right without any guidance. My idea is to figure out a >> way to annotate the sources in a way to get the right points in control flow >> from code. From this I like to create a diagram that is semantically >> equivalent to the description in the spec. I'll need therefor things to >> create state machine / flow charts, meaning shapes, directed arrows, >> branches etc.. Well, my dream would be to inject a real data packet into the >> communication layer and get a diagram where the path taken is highlighted :) >> >> The best approach I have til now is to generate a graphviz dot file for the >> diagrams but using anything from Moose would indeed be nicer. >> >> Norbert >> >> [1] http://en.wikipedia.org/wiki/Transaction_Capabilities_Application_Part >> [2] >> http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.774-199706-I!!PDF-E&type=items > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > >
