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]].
