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