switching from uml and code on the fly is so dificuld using pen and paper

also pen and paper is quite clear to to ppl around it wenn it's drawn but for archiving it doesn't work. even if you can draw clear enough (which will in my experience take to much time) sqeesing fields methodes or anything else once you drawn it, doesn't work.

Use UML for design and specification purpose, only. As soon as you have a class with more than a few methods in it, the class diagram gets unreadable. If it comes to other diagram types like sequence diagrams for example, generated diagrams get totally useless. And since there is little value in class diagrams alone, rountrip engineering tends to be an expensive waste of time...

switching from uml and code on the fly is so dificuld using pen and paper

Round-trip uml tools tend to generate crappy code and crappy diagrams. In attempting to make both easier and more automated they make everything more difficult. IMHO of course.

IMHO Together excells at both. But it isnt round-trip. Round-trip sucks. Its simultaneous (what you might consider "continous round-trp") which is ther eason its the only useful UMl tool Ive ever found.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

Use UML for design and specification purpose, only. As soon as you have a class with more than a few methods in it, the class diagram gets unreadable. If it comes to other diagram types like sequence diagrams for example, generated diagrams get totally useless. And since there is little value in class diagrams alone, rountrip engineering tends to be an expensive waste of time...

if your class has 'more then a few' (public) methodes(if there not public they don't (usually)belong in your uml),.... .....well more then a few, if your class has a lot of public methodes, perhaps you should evaluate your design.

round tripping with interaction digrams or generated interaction diagrams have never a fixed cirkel and changes should never be done by the developer (alone). generated Depence diagrams are like unittests.

thats actually interesting to repeat. as soon as your not building a liberie aren't you constantly re-designing re-evaluating or are you builing a factoryfactoryfoofactoryfactoryfactory, which can do anything it might have to do in the future? for small RFC, small programs I don't really think I'm getting my point across.

switching from uml and code on the fly is so dificuld using pen and paper

Round-trip uml tools tend to generate crappy code and crappy diagrams. In attempting to make both easier and more automated they make everything more difficult. IMHO of course.

I'm feeling you, however thats a problem with the implication not with the consept. as jeff also points out, uml tools are costy and good uml tools, oi oi oi.

Nah, I don't agree. I've tried Borland's tool and its insistance of doing code and diagrams in parallel just doesn't work very well at all. Especially in C++. And their insistance in dividing the products into developer/architect/whatever with no "everything" option doesn't help matters. Enterprise Architect is about the best for diagrams, it does a reasonable job of being a uml-aware drawing app but it's still more clunky than pen and paper (or their digital equivilents).

Of course, either option is still miles better than trying to do it in Viso.

But it isnt round-trip. Round-trip sucks. Its simultaneous (what you might consider "continous round-trp") which is ther eason its the only useful UMl tool Ive ever found.

Jeff - I think you just haven't yet been fortunate enough to try a really good implementation of round-trip .

I have - fleetingly, sadly - and it was actually very good indeed. Especially if you're into XP - it lets you work stuff out with other people (UML changes) then go and reflect those directly into added or refactored methods on your code base (the thing I was playing with just refactored by editing signatures and dropping in a code comment FIXME: this method probbly needs rewriting now), and then (couple of clicks in eclipse) autogenerate the JUnit test stubs directly from the new method stubs.

Result: you're straight into editing the tests, all *pre-connected to their appropriate real code methods*, with 0 effort.

I haven't yet seen a good implementation of method deletion, although my experience with method adding suggest that a good implementation is possible and would be rather delightful to use.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org