Hi Thomas To a certain extent its up to the reveng developer. I'm not likely to be doing this work and it's only a suggestion from me.
As I stated further up this thread I don't actually see any language specific reverse engineering code in the diagrams but I do think there should be a diagram builder that the reverse engineering GUI should call. So the reverse engineering process becomes 2 stage 1) Build the UML model elements by interpreting the Java code (java module) 2) Build a diagram from a set of model elements (seq2 module) What I like about this is that - it requires the same interface to the diagram for all diagram types having done class reverse engineering call diagram.build(namespace, listofmodelelements) having done sequence reverse engineering call diagram.build(interaction, listofmodelelements) - it provides reuse of code for other language types When trying to reverse engineer sequence diagrams for C#, C++ etc it is only step 1 that needs to be rewritten. Step 2 is fully reusable. - it provides further reuse After exporting XMI it would be very useful to have this reusable functionality to build a sequence diagram It could also be used to create a sequence diagram after the user had drawn a collaboration diagram. - there are no module dependencies With the pattern I describe no modules rely on or know of each other. They only depend on core argouml and it is the ArgoUML framework that calls them. If you have working code that doesn't follow this pattern then don't abandon it. I know you've been working on functionality for sequence reverse engineering that relies on diagram knowledge. However it would be good to see if you can adjust it over time to fit what I suggest and offer more reuse to ArgoUML and other modules. Regards Bob. 2008/12/17 Thomas Neustupny <[email protected]>: > Hi Bob, > > sorry I had no time last days to add my comment to your proposal. > > I feel not comfortable if the package org.argouml.sequence2.reveng provides > the complete engineering of seq diagrams from source code (or method bodies > in the model), but maybe this is not what you meant. The theoretical > possibility that this could alternatively go into a package > org.argouml.[...].reveng.sequence2 shows that it depends on the point of > view: is reveng or seq2 the top category? > > My idea for reveng is, that it depends on package org.argouml.sequence2 (or > appropriate subpackages) which act as supplier(s) of the needed seq2 > functionality, e.g.: > - create a seq2 diagram > - add a classifierRole (or in UML2: classifier) to it > - add a message at the end or at some specified position > > etc., all or some of these used either by GUI or by a reveng process. With > this, I'd see no need of a reveng package inside the sequence2 subsystem, > because there is no reveng specific code in sequence2 then. > > Or, can you explain what you expect to be in that reveng package? (Same maybe > applies to other subpackages for other processes like code generation.) > > Thomas > > -------- Original-Nachricht -------- >> Datum: Tue, 16 Dec 2008 09:48:42 -0800 >> Von: Mark Fortner <[email protected]> >> An: [email protected] >> Betreff: Re: [argouml-dev] Reverse engineering inside a diagram subsystem > >> Hi Bob, >> >> On Tue, Dec 16, 2008 at 9:33 AM, Bob Tarling <[email protected]> >> wrote: >> > 2008/12/16 Mark Fortner <[email protected]>: >> >> Hi Bob, >> >> I meant generation in general, as opposed to code generation >> >> specifically. Although I hope at one point there won't be a >> >> programmatic distinction between them. >> > >> > I think they're very different as one is generated from the model and >> > the other from the diagram. >> > >> >> Actually, ArgoPrint uses both the diagram and the model to generate >> documentation. My thought was that at some point the user would be >> able to select a series of templates and say "generate selected", and >> both documentation, code, deployment scripts, perhaps even an >> application monitoring tool would be generated. >> >> >> >> >> FYI, there are two SVGWriter classes (one called SVGWriter the other >> >> called SvgWriter). It's the latter one that we currently use in >> >> ArgoPrint. Which one are you thinking about eliminating? >> > >> > SVGWriter is deprecated. Its about time I deleted that anyway. >> > >> > SvgWriter is what I was considering dropping but only in the very long >> > term and if batik really has proved itself. There's no reason why I >> > shouldn't still hold onto SvgWriter in GEF as a fallback for batik >> > errors. >> > >> > The advantage of the batiks version is it is an extension of >> > Graphics2D whereas SvgWriter is just an extension of Graphics. So it >> > is far more functionally rich. >> > >> > For batik see - >> > >> http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/svggen/SVGGraphics2D.html >> > and - http://xmlgraphics.apache.org/batik/using/svg-generator.html >> > >> > It may be that batik could be an alternative to generate some of our >> > other graphics formats. >> >> I'll take a look at this. Thanks! >> >> Mark >> >> ------------------------------------------------------ >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985124 >> >> To unsubscribe from this discussion, e-mail: >> [[email protected]]. > > -- > Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL > für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985613 > > To unsubscribe from this discussion, e-mail: > [[email protected]]. > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985636 To unsubscribe from this discussion, e-mail: [[email protected]].
