The recent discussions on the SPL project has inspired me to want to discuss this again.
We now have the sequence diagram successfully distributed as a module. I am hoping that in time the other diagrams can also go the same way. In fact is there any reason to delay with that? I'd like to go further than just moving all the existing classes in their existing package structure into modules I think that would mean we'd end up with packages being shared across different modules and possible name clashes. We also historically have our packages too fine-grained which has resulted in us having to make classes public that should not be. So I'd prefer to mimic the sequence2 packages structure where we have org.argouml.xxxx as the main package name for the module and org.argouml.xxxx.diagram where all the diagram specific classes are kept. With the other diagrams will will have different things to consider than we did for sequence diagrams. With the sequence diagram the figures are not used in any other diagram type and are unique for that diagram. For other diagrams that is mostly not the case. So for example FigClass should not be in the class diagram module as it is required for various diagrams. So I would suggest a separate module for common Figs that has some factory to return the required Fig. The question that comes to mind for me is whether that module actually contains all Figs whether or not they are used in multiple places. If so that would leave each diagram module only containing the graph model and diagram class in which case is the separation really worthwhile? Maybe just one diagram module for everything would do us. The options and advantages/disadvantages I see are as follows 1. One big module with all diagram code Advantage - extreme encapsulation, almost everything can be package scope. Disadvantage - One massive package. The module loader does not control availability of individual diagrams. 2. Split diagram modules with one module containing all figs Advantage - Encapsulation still good. Easy pluggable diagram types. Enforces dependencies (Figs don't know about concrete Diagrams and GraphModels). Disadvantage - Relatively little code in each module. Package in main diagram module is still large. 3. Split diagram modules with one module containing common Figs Advantage - Easy pluggable diagram types. Main diagram module only contains what is needed and code is more evenly distributed between modules. Disadvantage - Encapsulation must be broken to allow specific diagram types to access ancestor classes and common classes from common diagram module. I favour option 2 but I'd like to hear the opinion of others. Part of me wants to put this off as its not really giving the user anything new but on the other hand it should be a fairly easy process to move the relevant classes and the result I think will be a modularized ArgoUML that will be a lot easier for new developers to get in and understand where the responsible parts lie. Once this is done then I'd like to see a process of tidying up argouml-app to remove all direct references to tigris-GEF classes. All tigris-GEF classes should be encapsulated in the diagram modules and we will have put ourselves into a position where it would be possible for someone to start to develop a diagram in eclipse-GEF if they choose. Regards Bob. ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2595136 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
