How much will it take to master UML?

[roman]

Hi everybody,

I just wonder to know how much will it take to master UML?

I would like using Sparx Enterprise Architect tool for modelling.

Background:

1) I have strong Computer Scince skills (including OOP)

2) In the Company I work in there is a medium project that in my opinion requires using CASE tools. I am the one responsible for deploying CASE tools, managing and developing the project.

What time will it take for me to quickly study the stuff, taking into consideration the fact of presence of real (working) project to train?

Thanks for any opinions

[mikewhit]

... to master UML ...

Depends on how much 'real' design experience you have, IMHO.

If you're already used to going from requirements to design to implementation, and are familiar with the different approaches needed, then a few weeks work with a good coursebook, a 'real' project, and EA should bring you to an adequate level, if you restrict yourself to the core diagrams and elements, and set yourself a process to work through.

I don't feel I have 'mastered' UML and I've been doing it for several years - I'm not familiar with 'correct' use of some of the backwaters. It's useful to have others to talk to (this forum for example).

Earlier, I found with Yourdon/Constantine modelling, and later Shlaer-Mellor, that I was only fully able to appreciate them when I had already encountered the issues they had been designed to deal with.

So I wouldn't put learning UML in the same category as e.g. learning Java, where knowing the syntax and understanding the concepts of synchronisation and classes will get you there. IMHO.

[TrtnJohn]

Roman,

Mastering UML is not the hard part.  Defining a usable design process based around it that will be acceptable to your company will be the hard part.  The real reason for UML is to communicate design.   So, you need to decide why you need to communicate design.  Do you want to have peer reviews or just documentation?  Do you want to track your project and requirements and review it with your clients?  There are a lof of uses for UML.  But, essentially it is a tool for communications.  Don't fall into the trap of thinking that it is a development tool and will write code for you.  The reverse engineering features are just time savers.

[angel-o-sphere]

Ah well, thats easy

General Rules:
a) dont drink  
b) dont drink and drive (if a) fails)  
c) meditate (at least daily, better more often)  

And yes, sorry to say that: no sex!  

angel'o'sphere

[Andrue]

This is something I am trying to come to grips with. I can more or less read a UML diagram and I can create something that looks like a UML diagram but I have no idea if it's 'correct'.

The impression I'm getting is that 'correct' WRT to UML (both individual diagrams and the entire set of diagrams for a project) can be defined as 'conveys the same, useful, information to all who read it' rather than 'follows the syntax of the language'.

From my current experience (only a few weeks really) UML is helping me think about the design but only in the same way I would have done in code.

I effectively work alone. There is a team but no one I need to communicate ideas to. Normally I'd start by writing class declarations and some simple code. When the code is in danger of getting complicated I call and declare (but not implement) a method or function.

ISTM that UML is allowing me to move that process into a diagram. I can't say it's giving me a huge productivity boost though. All I'd currently say is that at the end of the process I will have better documentation for an outside to look at. Not that that's a bad thing but I don't currently get the feeling that UML is giving me personally anything I didn't already have.

[TrtnJohn]

Andrue,

It is a catch-22. You are struggling with making the transition because the benefits aren't that apparant because you haven't seen them yet.  I can tell you that, even for one person development team, there is a benefit.  But, first you need to begin to view your design as a blueprint instead of real code.  UML gives you a visual overview of your system.  It can show greater detail than possible by just code browsing.  If you blueprint your system you can easily spot the flawed and/or redundant parts.  This is much harder when you just bang out the code.

Not to say that writing some code can't help you move your design forward.  The best designs come about when you take an iterative approach and design some, code some, ...  This is where the reverse engineering tools really help out.  It is really interesting to take a project that someone just coded with using UML and reverse engineer it into EA.  It is really shocking to the original developer the ugly spider-web they created without even realizing it.

[csuscheck]

I'd suggest you pick up Fowler's UML Distilled (latest edition).  It gives you a basic idea of most of the UML notations, it's quick and short and cheap.

The UML Bible is a pretty good reference for really detailed information on UML.

To master UML you must practice and get a good mentor.  Many of the books say you can get by with 20% of the UML notation for most projects, and I'd agree.  The hard part is applying the UML.

[Andrue]

I was on holiday last week and today is the first time I've looked at my UML in over seven days. I have to admit that I found it easier to read and get back into than I would have done code.

Not so much because I could read it at a glance (I can't) but because I can read enough and know that I can drill down if/when I have to.

It's also easier to rearrange the design elements because you don't have to undo work that you did previously.

So when I first posted I was tolerant of the idea of The UML but now I'm beginning to see definite advantages to it.