Hello Bob! I think you have simplified the problem so much you cannot see my point. Perhaps it goes back to problems in defining what a subsystem is.
I have some idea that the subsystems are, to some extent, independent. They could be maintained independently. Because of that, the GUI-parts of a subsystem are problematic. In your diagrams you have either ignored the fact that Notation, CG/RE, and Critics need small GUI-parts (they are colored pink) or you have included that in the ArgoUML Frame. My whole reasoning is around how we shall treat them. If they are to be in "ArgoUML Frame" (in the Cookbook this is called Application) then I'd say the subsystem isn't as independent as they should be because maintaining any of them would involve maintaining the ArgoUML Frame subsystem. I have some more comments below. > -----Original Message----- > From: Bob Tarling [mailto:[EMAIL PROTECTED] > Sent: den 10 februari 2007 20:58 > To: [email protected] > Subject: Re: [argouml-dev] Subsystems with GUI-parts > > > By separating them in two (as my second example) any part of the ArgoUML > GUI can call > > the Notation subsystem whenever it chooses. The NotationGui subsystem, > or whatever we > > should call it, can depend on GUI components without destroying the > layered architecture. > > Now I'm even more confused. > > You show a complex subsystem like diagrams as a package inside some > GUI subsystem. > > Yet the few simple GUI classes require for notation, that should be > accessible by the ArgoUML GUI, are shown as a subsystem that can't be > accessed from that GUI. > > Why would the existing NotationGUI classes rely on the diagrams? Or > the other way around? I can't see that they have any relationship with > each other at all. > > Unfortunately all the suggested architecture diagrams I submitted so > long ago I can't find any more. > > They were something along the lines of the attached, I've colour coded > with pink as non-gui. I don't see any important difference between your model and the subsystems that we have explained in the Cookbook (or actually a single one but that is connected to the other discussion). > In here I would consider those few GUI notation classes to be among > the common available Actions and dialogs contained in some package > within that subsystem. As I mentioned before, then they shouldn't be pink then. > It may be that all GUI subsystems need to have access to some set of > GUI utility classes. I've left this off for clarity. In the cookbook this is modeled as a dependency on the GUI subsystem. In the current application the GUI utility classes are awt and swing classes. > I've added things like ArgoNetbeans and ModelEMF to demonstrate the > flexibility we should be prepared for. The Eclipse integration is more interesting to discuss since it is working to replace awt and swing. /Linus --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
