So this argument is about whether it's sequence2.diagram or diagram.sequence2 ? What is the impact one way or the other? Although package names look hierarchical aren't they flat from Java's point of view?
BTW, for the purposes of the discussion, it would be useful to include the current names and the new proposal so we don't have to refer to someplace else to figure out what's what. Tom On Fri, Dec 12, 2008 at 3:40 AM, Bob Tarling <[email protected]> wrote: > 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=983946 To unsubscribe from this discussion, e-mail: [[email protected]].
