I'm coming to the conclusion of forgetting about a diagram module
split by each diagram type.
Originally I thought of this based on a diagram in the UML
certification guide and thought by having a module for each diagram it
would group the classes into small manageable packages.
UML Diagram
|
|--Structure Diagram
| |--Class Diagram
| |--Component Diagram
| |--Composite Structure Diagram
| |--Package Diagram
| |--Deployment Diagram
| |--Object Diagram
|
|--Behavior Diagram
|--Activity Diagram
|--Use Case Diagram
|--State Machine Diagram
|--Interaction Diagram
|--Sequence Diagram
|--Communication Diagram
|--Interaction Overview Diagram
|--Timing Diagram
However breaking down by concrete diagram doesn't work because
everything that is available in a class diagram is available in any
other structure diagram. So I thought to have all structure diagrams
in one module and behavior diagrams in another.
However their are still some classes that would be shared by both.
Creating a separate shared module means creating more public classes
than I'd like (we've had far too much exposed in the past).So I'm
starting to think that we just have one module/package for all
diagrams and concrete Figs.
Does this sound reasonable to others?
Starting this way at least gives us more options. We can expose more
later if we like. But as we know from experience if we expose more too
soon it will be harder to hide later.
The current module combination of structure2 and class2 works fine new
with the class2 launcher. If I get no objections I'll create a
diagram2 module and move everything there. I'll include use of that
module with the euml launcher.
I'd also like to move the concrete UML1.4 Figs and diagrams out of
core ArgoUML into a diagram1 module. That will be a simple move from
one project to another but keeping existing package structure.
That will move a mass of classes that reference GEF out of core
ArgoUML. Something I'm hopefully will continue and eventually leave
core ArgoUML unaware of GEF entirely. This will leave core ArgoUML
more flexible for reuse. Some other application like core argo-eclipse
can either include the GEF Figs or develop their own diagram layer.
At the moment the 'UML2' Figs simply extend the UML1.4 Figs. The work
can start soon to override those UML1.4 features where required.
Any feedback?
Bob.
2009/8/2 Bob Tarling <[email protected]>:
> You may have noticed I've recently commited a class2 module and a
> activity2 module.
>
> I've using these as a proof of concept. Please leave me to my own
> devices with these for just a little longer.
>
> In particular I'm trying to see if I can extend the Diagrams and Figs
> for UML1.4 for class diagrams and in the extension classes make the
> changes required for UML2 (such as fixing current problems that occur
> with drawing associations and when changing aggregation end).
>
> At the moment many of the UML2 classes are copies of UML1.4. This is
> not the long term intention. I intend to have the UML2 Figs extend the
> UML1.4 Figs where appropriate. Copying just allowed me to get the
> module working quicker (you can run the module now with the "ArgoUML
> class2" launcher (get the latest projects with
> argouml-core-projectset.psf first).
>
> I realise that my first mistake was to create all the Figs in the
> class2 module. FigClass2 for example can exist in other diagrams other
> than the class diagram.
>
> So I intend to create 4 other modules
>
> There will be one for each UML2 diagram supertype
> - structure2
> - behavior2
> - interaction2
>
> Any Figs that are common for different diagrams of those types will me
> stored in those modules.
>
> Those few that are required in more than one of those types will be in
> the module common2
>
> The dependency of class2 will then be on structure2, common2 and then
> base arguml and model interface.
>
> I hope to give the Figs just package scope however my concern here is
> in the reflection used by the persistence mechanism, that may give me
> problems.
>
> I'll keep you up to date with my progress.
>
> Hopefully once I have this demonstration then others can help with
> similar work on other diagrams.
>
> Regards
>
> Bob.
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2381502
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]]