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've used batik before to create SVG diagrams and to serialize them as PNG, or JPGs. I haven't tried writing Java2D objects to an SVG graphics object in batik and getting it to create an SVG diagram from that. But that would be an interesting approach. 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? Mark On Tue, Dec 16, 2008 at 8:28 AM, Bob Tarling <[email protected]> wrote: > Hi Mark > > I don't consider SVG generation as being code generation. Its not > generating code as a basic framework from which to execute the model. > > Although SVG could be considered a program language I just view it as > a graphic output format and there is nothing new required in a diagram > modules for graphic output. > > All custom Figs, Diagrams, Layers, Selections etc extending the GEF > classes contain a paint(Graphics) method. > > In normally operation that Graphics object is the screen display. > > For generating SVG that Graphics object is SVGWriter. > > I have been considering whether to drop support for SVGWriter in GEF > in favour of apache batik (I forget the equivilent class but I know > they have the same). The advantage is that SVG generation is left to > the experts. The disadvantage is there will then be nothing we can do > if a defect is discovered. > > For the moment I'm doing nothing until I see a clearer need to change. > > It might be worth making comparisons with batik though just to see if > there is any difference in performance or size of SVG generated. > > Regards > > Bob. > > > > 2008/12/15 Mark Fortner <[email protected]>: >> Hi Bob, >> You're right about step 1 being language dependent and step 2 being >> model dependent. >> >> The mechanism you suggest for reveng sounds pretty workable. >> >> With respect to generation, I'm wondering if there are any chances >> that a diagram type would introduce new "attributes" to a model. For >> example, currently in argoprint we rely on SvgWriter to generate an >> SVG version of the diagram. Would you use a similar callback >> mechanism in SvgWriter to get the position and shapes of various Fig >> elements needed to create the diagram? >> >> Mark >> >> On Mon, Dec 15, 2008 at 10:48 AM, Bob Tarling <[email protected]> wrote: >>> >>> Hi Mark >>> >>> I changed the subject for the specific point. I imagine a chat about >>> reverse engineering could go into detail not relevant to the main >>> thread. >>> >>> Reverse engineering was just given as an example. In fact I'm not so >>> sure it is required. I just wanted to demonstrate that the need to >>> split out the subsystems of a module may go beyond what is currently >>> implemented in seq2. >>> >>> For reverse engineering whether classes or sequence there are two >>> steps that I see. >>> >>> 1. Build the UML model from the language code. >>> >>> 2. Build a diagram from the UML model. >>> >>> I imagine (1) being within the language module and then (2) done from >>> some interface to the diagram module. >>> >>> However by stage 2 there should no longer be any dependency on the >>> original language. >>> >>> Maybe in future, rather then "reveng", we have something like >>> "builder" as a package in a diagram module. It should have some common >>> interface so that it can be plugged into and recognised by the central >>> reverse engineering subsystem. >>> >>> So the central reverse engineering process first calls the language >>> module and then the diagram module. >>> >>> I'd have thought code generation would be entirely from the UML model >>> with no knowledge of diagram layout. So I see no need for the diagram >>> modules to have any support for this. >>> >>> This is a view from someone of very little experience of CG/RE. >>> >>> Bob. >>> >>> >>> >>> 2008/12/15 Mark Fortner <[email protected]>: >>> > Hi Bob, >>> > As a "tinkerer", I find this reorganization easier to follow than trying >>> > to >>> > figure out what packages contain seq2-related code. I'm assuming that the >>> > end-goal of this will be to allow developers to create support for new >>> > diagram types by simply dropping the appropriate JAR (and any >>> > dependencies) >>> > into the classpath and restarting argouml. >>> > >>> > You mention that the reveng package would contain classes for reverse >>> > engineering a diagram. Presumably generation classes would have a similar >>> > package. How would these two packages work, given that they are both very >>> > language dependent? For example, if you create a grails domain object >>> > generator/reveng pair, would you need to create subpackages to deal with >>> > each language? Something like this: >>> > >>> > ...seq2.reveng.grails >>> > ...seq2.generator.grails >>> > ...classdiag.reveng.grails >>> > ...classdiag.generator.grails >>> > ... >>> > >>> > Regards, >>> > >>> > Mark Fortner >>> > >>> > >>> > On Mon, Dec 15, 2008 at 9:11 AM, Bob Tarling <[email protected]> >>> > wrote: >>> >> >>> >> Hi Tom >>> >> >>> >> Currently the seq2 packages have the following structure. Some of this >>> >> was a reflection of the packaging from the original implementation. >>> >> Notation has been added since. >>> >> >>> >> I give a number in brackets to highlight where I suggest a package is >>> >> moved. >>> >> >>> >> The is the current package structure of seq2 in SVN >>> >> >>> >> org. >>> >> argouml. >>> >> proppanel. >>> >> sequence2. // The property panel factory and >>> >> implementation (1) >>> >> notation // The UML notations for sequence diagram >>> >> (2) >>> >> uml. >>> >> diagram. >>> >> sequence2. // The sequence graph model only (3) >>> >> module // The class for registering the module >>> >> (4) >>> >> ui // The sequence diagram, Figs etc (5) >>> >> >>> >> Below is the structure I would like to move to and become the common >>> >> structure as further diagrams are split out. >>> >> Explanation given below. >>> >> >>> >> org. >>> >> argouml. >>> >> sequence2. // top level package for seq2 module >>> >> module // The class for registering the module (4) >>> >> diagram // The actual diagram implementation graph >>> >> model, diagram Figs etc (3 & 5) >>> >> notation // The UML notations for sequence diagram (2) >>> >> proppanel // The property panel factory and implementation >>> >> (1) >>> >> critics // Nothing yet - reserved for critics >>> >> regarding sequence diagram layout >>> >> reveng // Nothing yet - reserved for generating >>> >> sequence diagrams from code >>> >> >>> >> Actually everything in the above is to allow sequence diagrams which >>> >> is why I suggest sequence2 as the top level package name under >>> >> org.argouml. Otherwise we're crosscutting packages in core ArgoUML. >>> >> >>> >> Having notation as a subpackage of proppanel is confusing it suggests >>> >> some relationship where there is none. >>> >> >>> >> A package for uml seems fairly redundant to me in a UML tool. >>> >> >>> >> There seems little point to me in having a hierarchy of packages that >>> >> contain only the graph model in one and the Figs (sequence2 and >>> >> sequence2.ui). Such a hierarchy really means nothing in java but it >>> >> does imply some relationship. That hierarchy tends to suggest that the >>> >> ui is used by the model rather than the other way around. I have >>> >> simply combined these as the graph model an ui together into >>> >> (org.argouml.sequence2.diagram) >>> >> >>> >> > If the modules and subsystems match, should we redefine the subsystems >>> >> > to >>> >> > improve on the understanding of the system? >>> >> >>> >> I'm not sure what you mean by "If the modules and subsystems match". >>> >> There are no new subsystem here so that requires no new change to >>> >> subsystem descriptions. >>> >> >>> >> Maybe what needs clarifying is my view of modules as components. I >>> >> think in the past it has been assumed that a module would be a >>> >> subsystem. However seq2 proves that a module actually needs to extend >>> >> and integrate to various subsystems of the main application. >>> >> >>> >> Bob. >>> >> >>> >> >>> >> 2008/12/14 Linus Tolke <[email protected]>: >>> >> > Hello Bob! >>> >> > >>> >> > If the modules and subsystems match, should we redefine the subsystems >>> >> > to >>> >> > improve on the understanding of the system? >>> >> > >>> >> > /Linus >>> >> > >>> >> > 2008/12/12 Bob Tarling <[email protected]> >>> >> >> >>> >> >> Hi Linus >>> >> >> >>> >> >> To my mind a module is not a system. It is a component that contains >>> >> >> extensions of our subsystems. I'm trying to highlight what those >>> >> >> subsystems are by separating the packages and also use that to enforce >>> >> >> we don't get cycles back in (I've never used jdepend, I may need some >>> >> >> help). >>> >> >> >>> >> >> I saw this when the sequence diagram came out as it was clear that it >>> >> >> was not just the diagram itself that needs to be pluggable but as that >>> >> >> module is registered or not we want to plug in/out the property panel >>> >> >> for the diagram and any critics for the diagram etc. The module became >>> >> >> more than just the sequence diagram subsystem. >>> >> >> >>> >> >> I think that you're suggesting that I could put everything inside one >>> >> >> package in the module. This mixes up property panels classes and >>> >> >> diagram classes in the same package. Critics will later be added and >>> >> >> maybe some support for reverse engineering. >>> >> >> >>> >> >> Maybe I'm trying to be too purist in this separation. I'm interested >>> >> >> in further views. Please take a look at the current layout of the seq2 >>> >> >> module and my previous proposal on refactoring package layout. >>> >> >> >>> >> >> You are correct on how I'm trying to get the subsystems apart. >>> >> >> Separating individual diagrams first should make it clear what those >>> >> >> diagrams require as a common interface. >>> >> >> >>> >> >> The last to come out would be some common-diagram subsystem containing >>> >> >> things like FigClass that can be used in many diagram types and >>> >> >> FigNodeModelElement etc. >>> >> >> >>> >> >> Details pane is similar. We have just the properties panel in >>> >> >> Christians last GSOC project but others will come out into other >>> >> >> modules in time or may actually belong to some other module. >>> >> >> >>> >> >> For example it could be that the style panel is something that is >>> >> >> sensibly a part of the common-diagram module. If we have argouml with >>> >> >> no diagrams but just being used by someone as a model explorer the >>> >> >> style panel makes no sense. >>> >> >> >>> >> >> Regards >>> >> >> >>> >> >> Bob. >>> >> >> >>> >> >> >>> >> >> 2008/12/12 Linus Tolke <[email protected]>: >>> >> >> > Hello Bob! >>> >> >> > >>> >> >> > This question is partly about how to organize ArgoUML into >>> >> >> > subsystems. >>> >> >> > You >>> >> >> > seem to have done this in the other way. This is mostly in your list >>> >> >> > of >>> >> >> > subpackages. Let me explain. >>> >> >> > >>> >> >> > The current plan is to have subsystems grouped by where things are >>> >> >> > showing >>> >> >> > on the screen: >>> >> >> > >>> >> >> > diagrams >>> >> >> > property panels >>> >> >> > todo >>> >> >> > explorer >>> >> >> > code generation / reverse engineering >>> >> >> > >>> >> >> > Your suggestion seems to first split on the type of diagram: >>> >> >> > >>> >> >> > use case >>> >> >> > sequence >>> >> >> > ... >>> >> >> > >>> >> >> > and then split on diagrams, property panels, critics, etc. >>> >> >> > >>> >> >> > Leaving that my question is about how many classes are we talking >>> >> >> > about? >>> >> >> > Is >>> >> >> > it really necessary to split in more than two packages? Like this: >>> >> >> > org.argouml.sequence2 (for main classes and module stuff) >>> >> >> > org.argouml.sequence2.diagram (for classes that are internal to the >>> >> >> > sequence >>> >> >> > diagrams implementation). >>> >> >> > >>> >> >> > If any of these would contain more than 40 classes then I understand >>> >> >> > that >>> >> >> > you would want to split it further but with my limited knowledge, it >>> >> >> > looks >>> >> >> > like that is not the case. >>> >> >> > >>> >> >> > /Linus >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > 2008/12/8 Bob Tarling <[email protected]> >>> >> >> >> >>> >> >> >> Hi All >>> >> >> >> >>> >> >> >> I'd appreciate some feed back on this. Renaming the package >>> >> >> >> structure >>> >> >> >> again will be painful so I'd hope to get this right on first >>> >> >> >> release. >>> >> >> >> >>> >> >> >> My intention is to define a common package structure not only for >>> >> >> >> the >>> >> >> >> new sequence diagrams but also something for other diagram types to >>> >> >> >> adhere to as they split out of ArgoUML into their own plug-in >>> >> >> >> module. >>> >> >> >> >>> >> >> >> The package structure of a module is designed to match with our >>> >> >> >> subsystems. >>> >> >> >> >>> >> >> >> org >>> >> >> >> argouml >>> >> >> >> core >>> >> >> >> diagrams >>> >> >> >> sequence2 -- top level package for seq2 module >>> >> >> >> module -- contains class that registers module >>> >> >> >> diagram -- contains the actual diagram >>> >> >> >> implementation >>> >> >> >> proppanel -- contains the property panel >>> >> >> >> implementation >>> >> >> >> for sequence diagram >>> >> >> >> critics -- nothing yet - reserved for critics >>> >> >> >> regarding sequence diagram layout >>> >> >> >> reveng -- nothing yet - reserved for generating >>> >> >> >> sequence diagrams from code >>> >> >> >> >>> >> >> >> The hierarchy of packages I took to match with the current eclipse >>> >> >> >> project name argouml-core-diagrams-sequence2 >>> >> >> >> >>> >> >> >> However, what do we mean by core here? This is a module but it is >>> >> >> >> argouml owned. Should this be module or core? >>> >> >> >> >>> >> >> >> If we have a namespace of org.argouml then is core/module useful? >>> >> >> >> >>> >> >> >> Do we need the first level of diagrams separation? The seq2 module >>> >> >> >> primarily exists to provide diagrams but it also extends other >>> >> >> >> subsystems such as proppanels. >>> >> >> >> >>> >> >> >> Is this better or something else inbetween? >>> >> >> >> >>> >> >> >> org >>> >> >> >> argouml >>> >> >> >> sequence2 -- top level package for seq2 module contains >>> >> >> >> class >>> >> >> >> to register >>> >> >> >> module -- contains class that registers module >>> >> >> >> diagram -- contains the actual diagram implementation >>> >> >> >> proppanel -- contains the property panel implementation >>> >> >> >> for >>> >> >> >> sequence diagram >>> >> >> >> critics -- nothing yet - reserved for critics >>> >> >> >> regarding sequence diagram layout >>> >> >> >> reveng -- nothing yet - reserved for generating >>> >> >> >> sequence diagrams from code >>> >> >> >> >>> >> >> >> >>> >> >> >> Regards >>> >> >> >> >>> >> >> >> Bob. >>> >> >> >> >>> >> >> >> 2008/12/4 Bob Tarling <[email protected]>: >>> >> >> >> > Just a reminder before I go ahead and do this before the seq2 >>> >> >> >> > module >>> >> >> >> > goes live I intend to rearchitect the packages as such >>> >> >> >> > >>> >> >> >> > org.argouml.core.diagrams.sequence2.module - The module class to >>> >> >> >> > register with framework >>> >> >> >> > org.argouml.core.diagrams.sequence2.diagram - The sequence2 >>> >> >> >> > extension >>> >> >> >> > of the diagrams subsystem >>> >> >> >> > org.argouml.core.diagrams.sequence2.proppanel - The sequence2 >>> >> >> >> > proppanel >>> >> >> >> > >>> >> >> >> > The intention is that at a later date there is likely to be >>> >> >> >> > org.argouml.core.diagrams.sequence2.cognitive - Critics for >>> >> >> >> > sequence2 >>> >> >> >> > org.argouml.core.diagrams.sequence2.reveng - Reverse engineering >>> >> >> >> > code >>> >> >> >> > for sequence diagrams >>> >> >> >> > >>> >> >> >> > This keeps our subsystems clearly separated within the seq2 >>> >> >> >> > module. >>> >> >> >> > >>> >> >> >> > Regards >>> >> >> >> > >>> >> >> >> > Bob. >>> >> >> >> > >>> >> >> >> > 2008/5/2 Bob Tarling <[email protected]>: >>> >> >> >> >> I've just come across another subsystem that diagram modules >>> >> >> >> >> will >>> >> >> >> >> want >>> >> >> >> >> to plug in to. Toms recent commit to RESequenceDiagramDialog >>> >> >> >> >> reminded >>> >> >> >> >> me. >>> >> >> >> >> >>> >> >> >> >> When class diagrams are extracted they will also need to plugin >>> >> >> >> >> to >>> >> >> >> >> the >>> >> >> >> >> reverse engineering subsystem. We'll need some common way for >>> >> >> >> >> diagram >>> >> >> >> >> modules to extend and allow themselves to built as part of the >>> >> >> >> >> reverse engineering process. I was planning on leaving class >>> >> >> >> >> diagrams >>> >> >> >> >> till last anyway so we have some time to think about that. >>> >> >> >> >> >>> >> >> >> >> Again, using sequence2 as an example we currently require >>> >> >> >> >> >>> >> >> >> >> org.argouml.core.diagrams.sequence2.module - The module class to >>> >> >> >> >> register with framework >>> >> >> >> >> org.argouml.core.diagrams.sequence2.diagram - The sequence2 >>> >> >> >> >> extension >>> >> >> >> >> of the diagrams subsystem >>> >> >> >> >> org.argouml.core.diagrams.sequence2.proppanel - The sequence2 >>> >> >> >> >> proppanel >>> >> >> >> >> org.argouml.core.diagrams.sequence2.cognitive - Critics for >>> >> >> >> >> sequence2 >>> >> >> >> >> org.argouml.core.diagrams.sequence2.reveng - Reverse engineering >>> >> >> >> >> code >>> >> >> >> >> for sequence diagrams >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> Bob. >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> 2008/5/2 Bob Tarling <[email protected]>: >>> >> >> >> >>> I'll rename the sequence2 package soons so let me know if >>> >> >> >> >>> anyone >>> >> >> >> >>> disagrees with my suggestion. >>> >> >> >> >>> >>> >> >> >> >>> I've just realised that some diagram modules will want to >>> >> >> >> >>> register >>> >> >> >> >>> critics so we will in theory also need >>> >> >> >> >>> org.argouml.core.diagrams.sequence2.cognitive >>> >> >> >> >>> >>> >> >> >> >>> Are we happy that this pattern is used for packages as other >>> >> >> >> >>> diagrams >>> >> >> >> >>> are extracted? >>> >> >> >> >>> >>> >> >> >> >>> Bob. >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> 2008/5/1 Bob Tarling <[email protected]>: >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> > The new sequence diagram implementation proves how easy it is >>> >> >> >> >>> > to >>> >> >> >> >>> > keep >>> >> >> >> >>> > a particular diagram type within its own clear subsystem as >>> >> >> >> >>> a >>> >> >> >> >>> separate >>> >> >> >> >>> > eclipse project loaded at runtime as a plugin. >>> >> >> >> >>> > >>> >> >> >> >>> > I'd like to go ahead and do this with the other diagram >>> >> >> >> >>> types. >>> >> >> >> >>> I >>> >> >> >> >>> think >>> >> >> >> >>> > the more we begin to move stuff out of argouml-app the >>> >> >> >> >>> clearer >>> >> >> >> >>> it >>> >> >> >> >>> will >>> >> >> >> >>> > be how to move the rest. >>> >> >> >> >>> > >>> >> >> >> >>> > Initially I'd just like to move the packages in their >>> >> >> >> >>> current >>> >> >> >> >>> > structure but eventually I'd like to refactor into a >>> >> >> >> >>> flatter >>> >> >> >> >>> package >>> >> >> >> >>> > structure. >>> >> >> >> >>> > >>> >> >> >> >>> > The sequence diagrams I should be able to refactor sooner >>> >> >> >> >>> rather >>> >> >> >> >>> than >>> >> >> >> >>> > later though. I'll use that as an example of what I'd like >>> >> >> >> >>> to >>> >> >> >> >>> see >>> >> >> >> >>> > >>> >> >> >> >>> > First of all I'd like the base package structure to echo >>> >> >> >> >>> our >>> >> >> >> >>> new >>> >> >> >> >>> > naming convention >>> >> >> >> >>> > >>> >> >> >> >>> > So we will have >>> >> >> >> >>> > >>> >> >> >> >>> > org.argouml.core.diagrams.sequence2 >>> >> >> >> >>> > >>> >> >> >> >>> > In that base package I would expect no classes >>> >> >> >> >>> > >>> >> >> >> >>> > The subpackages would contain the implementations >>> >> >> >> >>> > >>> >> >> >> >>> > org.argouml.core.diagrams.sequence2.plugin - The module >>> >> >> >> >>> class >>> >> >> >> >>> > org.argouml.core.diagrams.sequence2.diagram - The sequence2 >>> >> >> >> >>> extension >>> >> >> >> >>> > of the diagrams subsystem >>> >> >> >> >>> > org.argouml.core.diagrams.sequence2.proppanel - The >>> >> >> >> >>> sequence2 >>> >> >> >> >>> > extension of the proppanels subsystem >>> >> >> >> >>> > >>> >> >> >> >>> > >>> >> >> >> >>> > We seem to use the term module and plugin interchangeably. >>> >> >> >> >>> Could >>> >> >> >> >>> we >>> >> >> >> >>> > settle on one. I would suggest plugin as it tends to fit >>> >> >> >> >>> eclipse >>> >> >> >> >>> > terminology better. >>> >> >> >> >>> > >>> >> >> >> >>> > Bob. >>> >> >> >> >>> > >>> >> >> >> >>> >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> >>> >> >> >> ------------------------------------------------------ >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=981309 >>> >> >> >> >>> >> >> >> To unsubscribe from this discussion, e-mail: >>> >> >> >> [[email protected]]. >>> >> >> > >>> >> >> > >>> >> >> >>> >> >> ------------------------------------------------------ >>> >> >> >>> >> >> >>> >> >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=983285 >>> >> >> >>> >> >> To unsubscribe from this discussion, e-mail: >>> >> >> [[email protected]]. >>> >> > >>> >> > >>> >> >>> >> ------------------------------------------------------ >>> >> >>> >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=984568 >>> >> >>> >> To unsubscribe from this discussion, e-mail: >>> >> [[email protected]]. >>> > >>> > >>> > >>> > -- >>> > Mark Fortner >>> > >>> > blog: http://feeds.feedburner.com/jroller/ideafactory >>> > >>> >>> ------------------------------------------------------ >>> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=984608 >>> >>> To unsubscribe from this discussion, e-mail: >>> [[email protected]]. >> >> >> >> -- >> Mark Fortner >> >> blog: http://feeds.feedburner.com/jroller/ideafactory >> >> ------------------------------------------------------ >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=984691 >> >> To unsubscribe from this discussion, e-mail: >> [[email protected]]. >> > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985076 > > To unsubscribe from this discussion, e-mail: > [[email protected]]. > -- Mark Fortner blog: http://feeds.feedburner.com/jroller/ideafactory ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=985105 To unsubscribe from this discussion, e-mail: [[email protected]].
