Hello! :)


Thomas N. wrote:
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.
  

Wow—THANK YOU.  That means a lot to me!

I tend to think differently than most programmers.  Hardcore "left-brain" (pure logic) thinking does not come easily to me.  I tend to bounce back and forth between left- and right-brained thinking, trying to connect together things I learn from each. 

So, sometimes, communicating with really skilled programmers can be tricky for me, and I'm (1) surprised it clicked with you, and (2) very happy you like my ideas! :D

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.
  
Awesome.  Again, glad I'm not alone. 

(Heh.)

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.
  

Hmm. 

Well, the straight import for ArgoUML wasn't very useful.  But I imagine that some diagrams made by hand could be extremely useful. 

After hypothetical importing, imagine if each package had:
  1. A high-level overview
    • within the package
    • in terms of the overall application
  2. Class diagrams
  3. Use Cases (E.g., "What are the most common things this package does?")
And of course, comments in the diagrams themselves can clarify the non-obvious.  Or a diagram's comment might simply say something like, "This diagram shows the contents of package _____.  This package's job includes A, B, and C.  The most important members contained in this package are _____."

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.
  

Yes, I didn't find the generated diagrams particularly useful. :(

Regarding the last sentence: interesting.  What other criteria might there be?  (For example, an iTunes-style "SmartList" that fetches all classes with, say, a particular stereotype?)


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.
  

To be honest, the only diagrams I understand are Class, Sequence, and Object.  Maybe Component as well, since it seems conceptually similar to Class diagrams.

Okay, so, hypothetical time…

Let's say we import the project as an ArgoUML model, and the generated diagrams are useless.  As you say, the imported sources provide "the basis 'vocabulary'".  Didn't that just save use from creating hundreds of classes manually?  Even if every diagram was hand-crafted in order to be useful, that import rather nicely automates the most tedious part. 

From there we could start with a goal like, "Provide every package with the basic diagrams, X, Y, and Z." 

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.
  

Yeah.  There are tons of ways to use ArgoUML.  That's one reason I'm so interested in the project. :)

I know my proposal is irrelevant to some cases I didn't consider.  I was just keeping to where it would be useful.  I figure there are those other cases and they are valid, and I didn't need to think on them as long as I had a case where it would be useful.

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
  

Thanks for your thoughtful and very comprehensive reply!  You've given me renewed enthusiasm to keep trying to spark ideas. :)


—Zearin


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to