• Post Reply Bookmark Topic Watch Topic
  • New Topic

Learn UML  RSS feed

 
clojure forum advocate
Bartender
Posts: 3479
Clojure Mac Objective C
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys, any way to learn UML from the scratch??
(some online tutorial please!).
 
author
Ranch Hand
Posts: 799
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by John Todd:
Hi guys, any way to learn UML from the scratch??
(some online tutorial please!).


Search "UML tutorial" at Google. Looked like I got a bunch of good hits. Bookwise, a great place to start is Martin Fowler's UML Distilled. It's short but should do the trick. There are possibly some concerns about its level of coverage of UML 2, so you may want to secure the spec as well. (OMG spec catalog)
Jeff
[ January 23, 2004: Message edited by: Jeff Langr ]
 
author
Ranch Hand
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've got an online description of all 13 of the UML 2 artifacts at www.agilemodeling.com/essays/umlDiagrams.htm. It's basically a free, online version of UML Distilled.
However, you need to get experience with the UML. Best way to do this is to work with other people with good modeling skills. Expect to invest several years to become a good modeler.
Worst yet, the UML is just a start, as you'll see at www.agilemodeling.com/artifacts/. Don't let anyone tell you different.
- Scott
 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Scott Ambler:
However, you need to get experience with the UML.


This is very very true. I read the books, articles, and tutorials for two or three years but only in the past six months since I started using UML as my day-in-day-out handwritten notation during casual technical discussions amongst our team, have I truly begun my long treck along the Path to Wisdom and Comprehenstion of The UML.
UML is like mathematics. You have to practice it for real, not just read about it, before you truly learn it. Amen.
 
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try "UML in a nutshell" from Oreilly.
It will help you come upto speed on some of the artifacts related to UML.
If you can be productive on Use Cases, Sequance diagrams, Class diagrams; you will be considered almost a guru on this aspect.
Dan.
 
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"UML for Java Programmers" is another good introduction, concentrating on the basics of UML for communication purposes (in contrast to UML as a programming language).

Originally posted by Chris Daniel:
If you can be productive on Use Cases...


Notice that use cases are *not* part of UML, but use case *diagrams* (which provide not much more than a rough overview over existing use cases - the meat always is in their textual description).
 
Jeff Langr
author
Ranch Hand
Posts: 799
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Scott Ambler:
However, you need to get experience with the UML. Best way to do this is to work with other people with good modeling skills. Expect to invest several years to become a good modeler.
Worst yet, the UML is just a start, as you'll see at www.agilemodeling.com/artifacts/. Don't let anyone tell you different.


While this is all true, I view this advice as unfortunate for inexperienced developers. Yes, there is a lot of complexity in modeling. However, the rudiments of UML--what most developers should know and should be able to use daily--are not exceptionally complex or involved. Most people don't want to become a modeler--they want to be able to build software, using models to communicate ideas and to solve problems.
-Jeff-
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jeff Langr:
While this is all true, I view this advice as unfortunate for inexperienced developers. Yes, there is a lot of complexity in modeling. However, the rudiments of UML--what most developers should know and should be able to use daily--are not exceptionally complex or involved. Most people don't want to become a modeler--they want to be able to build software, using models to communicate ideas and to solve problems.


I agree. But to me that only makes it more important to me to be aware of the alternatives to UML. Don't try to become an UML expert - learn its basics and then turn your look to the other modeling techniques, that would be my advice.
 
mister krabs
Ranch Hand
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
"UML for Java Programmers" is another good introduction, concentrating on the basics of UML for communication purposes (in contrast to UML as a programming language).

I would diagree. Too much of the book is spent on things that have nothing to do with UML. There are 50 pages of uncommented Java code in the book. And much of the advice, contrary to the name of the book, applies only to programmers following Martin's design paradigm. For example, his discussion on state diagrams goes off on a tangent as he discusses his SMC tool. The whole book treats UML way too lightly, even too lightly for someone just wanting to use it for team discussion. The whole book has the feel of a bunch of article thrown together.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Thomas Paul:
There are 50 pages of uncommented Java code in the book.


I am not fully through the book yet, but as far as I can tell, the code is commented by unit tests and UML diagrams. I didn't have any problem understanding the code till now. And as you very often see questions like "how does this diagram translate to code" from beginners, I am not sure that showing code is the wrong thing for everyone.

For example, his discussion on state diagrams goes off on a tangent as he discusses his SMC tool.


I actually quite like that he doesn't restrict the book to pure UML, but also mentions some alternatives (like a textual description of state machines) and explains when they might be preferable over UML.

The whole book treats UML way too lightly, even too lightly for someone just wanting to use it for team discussion.


I find it to be just of the right weight. It's probably a matter of taste...

The whole book has the feel of a bunch of article thrown together.


I share the concern that it sometimes feels less coherent than I'd like it too. Nevertheless I find it to be quite valuable, though.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!