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.
The model subsystem also needs GUI parts to operate as does any other subsystem. But you seem to think the model subsystem has some other special rules that make it different. The only thing that makes it different to my perspective is that it's the only subsystem with a clear interface and its available from all the GUI. Others should follow the same lead. I see subsystem as units of self contained business logic OR presentation. The presentation of the business logic should remain entirely independent with ArgoUML providing swing controls which may or may not be used by an external system like eclipse or netbeans.
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.
This is not true for the model subsystem. Like the model subsystem we need to define a clear interface for the other parts. I would reverse your argument. If a subsystem contains mixed gui and business logic then it is not independant because it needs to change if and when the GUI changes.
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).
That's good, the less we need to change there the better.
> 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.
You're confusing something here. The subsystems in pink are those that do not need to and should not contain any GUI. Just as with the model subsystem.
> 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.
The cookbook describes the explorer as being part of the GUI subsystem. The explorer is one of the major graphical views of the model interface. So why wouldn't the GUI subsystem also contain the other major graphical views of other non-visual subsystems. We seem to carry on with this disagreement and return to the same arguments time and time again. I've simply never worked on a system before that actively tries to create such a strong relationship between view and model. Bob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
