Hi Tony, I like the way you think, and I like your ideas! The answers to your questions can teach a lot about modeling and using UML in software projects.
> > Or when the matter is complicated. Do you have all wellknown patterns in > > your head? I find it hard to understand a 2 classconfiguration like the > > composite pattern without diagram. > > > Right-o. Good point! I always have a pricture of any complex system I deal with in my mind. Imagination and abstraction are required for any creative act, be it art or software development. > > That is not true - the cookbook is full with diagrams. > > Architecture, and even e.g. the issues process. > > > Yes, it is, but they are a bunch of separate images scatteredthroughout > the > Cookbook. I'm saying that the one of the main sellingpoints of > ArgoUML—the ability to view and interact with diagrams for aproject > in a single place—could be put to use for the project itself. There is a simple answer to why there is no such model for ArgoUML: because it's not very useful! I bet many of us imported the whole sources of ArgoUML into a huge model, only to find out that the result is a lot of data with just a little value. For me it just turned out to be better to just concentrate on some aspect, and then create a separate model for that. Of course, this includes the import of ArgoUML sources, too, but just portions of it. UML consists of 9 diagram types that are mapped to 7 ArgoUML diagram types, and with importing ArgoUML sources you just get class diagram, which is only a part of the structural view of the ArgoUML system. And even these diagrams, if automatically generated, are not very informative. Good class diagrams for ArgoUML consists of classes of various packages. A package is not the only criterion for grouping classes in one diagram. So, most of the useful diagraming work is done by hand, the imported sources are only the basis "vocabulary" used in this work. But indeed, doing this will not only help understanding ArgoUML, but also reveals weaknesses and potential of ArgoUML. One starts to think about new features. I recommend everyone to do this, my ideas came most of the time from this. For understanding ArgoUML, class diagrams and sequence diagrams are two very valuable diagram types, more than the others. Modeling source code oriented is only one field for using UML. Other areas are specifying software systems from scratch (along some methodology perhaps), MDA, or even non-software related work like process modeling. Some of this is found in the cookbook, and for this the import of source code or your proposed huge model is not even required. So, it's a wide field, but I agree that we could do some more, and I expect that with a developer wiki the sharing of diagrams about ArgoUML becomes easier. Thanks for bringing up that interesting topic, Thomas -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
