OSDev.org

How many of you do designs in UML?
Does it really help?

If so, can anyone point me towards a good place that explains what UML is for (something more precise than designing a process would be nice ) and how to use it. I've downloaded UML programs in the past... but never really 'got' what any it meant. The terms were all alien to me - I'm doing a better job learning Haskell than I did with UML! ;D

I've been using UML for a few years now, it allows you to express your (object-oriented) designs in a way that's very clear and can be used to explain designs to others. It also allows you to encapsulate design patterns in a single class diagram for clarity, show relations, construction, destruction etc., as well as a lot of other things, such as use cases and sequence diagrams.

UML is too much to explain here, but I can tell you that if you want a job in computer programming you'd better at least understand it.

I'd prefer you'd understand it, but myself, I hate UML. It's a language in itself to loosely describe a computer program. What's the source code for? All UML seen by me is just a hiding of unnecessary complexity you should tackle against, not ignore it.

If I can describe programs clearly in forth, how can't you describe programs clearly with C or java?

What would be really use for me would be a language which describes all relationships between things clearly, now, in the past, in the future and generally! Without using any kind of idea about 'function' or name. At the same time it could generate the executables for me...

Names are the ultimate evil root of clouded information. They are the reason for why can't we understand more than two thousand years old writings properly. Still we are rather trying to keep anonymous names up instead of killing them.

Candy wrote:UML is too much to explain here, but I can tell you that if you want a job in computer programming you'd better at least understand it.

Thanks, and... Ah! I didn't realise it was quite so important. Cheers, I'll go back and take another look at it.

@Cheery - Can't help but feel (probably just because it's in my head at the moment) that Haskell would cover some of them. Yes there are functions - but from a mathematical functional point of view as opposed to a set of instructions. Not quite certain I follow the name point though, perhaps anonymous lambda delegates are what you're looking for?

@Midas - I like haskell, especially... I love unificators! (ones you use almost without notice in haskell, when you define a function and give it parameter card and action after that.) Thought the anonymity of names... I say that one should leave functions behind and start writing code which doesn't use concept 'function' to structure code. So you wouldn't have methods or variables. Pasteable code or 'anonymous function' like you say in haskell, would be still possibly good and preferable.

If you ask "how one should program then?" I think you should start wondering the concept of a computer program and compare it to your intents for computer. (I've been wondering that trough already, but I do say it later when I've full picture about how I should say it).

UML is important for corporate **** and buzzwords. You need it to cheat your boss to take such creative person to work, when what he really needs is a randomly typing monkey or an AI. That's why it's so important, if you are planning to be a hobbyist or run your own business, forget UML.

I hate UML myself as well, it seems to try to over-explain while simultaneously not explain enough about the design. I personally used a mangled version of it for my own quick designs, it may not have all the "features" of real UML but it sure is a lot quicker for me to use.

Since everybody here seems to dislike it:

UML allows you to explain, for OO designs, how objects link to each other. It describes how many of each object are in each other, how they confer and how the architect of the program would like these to work together. Actually writing down a bit of a class diagram is useful for all nontrivial programs that use classes, you'll usually want a few pages for it too. Keeping them up to date is a lot of work, especially in current UML programs such as Microsoft Visio and Rational Rose.

If you're using it just for yourself, don't overburden yourself. Just make a simple class diagram only in your head, make complex ones on paper, only actually work them out if they're the basis of something or you think you'll have to refer to them a lot in the future.

If you work with multiple people or with a bit of time-delaying in your work (say, you halt your work for a few weeks), spend a bit more time and make proper class diagrams.

If you are the architect of a program / application / system, also add the use cases you see fit. Despite their simplicity, they're a very good indication to actual programmers what operations should be cheap and what should be expensive.

I for myself like UML too, it provides a simple overview of class and object-relations, like Candy already mentioned.

The thing I hate however are those WYSIWYG UML-Editors that take you hours to design your diagrams. There is nothing wrong with reverse-engineering diagrams from current source (or prototype-sources, such as headers), but designing them before writing a single line of code (just like many people advertise it) is something I simply dislike - I mean, I'm a coder, not a graphics designer

Just some experiences I made during work, just wanted to mention them somewhere

cheers Joe

My main problem with them is that their UI is tuned to a manager, not to a programmer. A programmer wants to just write code, preferably with some bit of design attached to it. If the tool I use could just read what I type and distill the UML out of it, that'd be loads better than clicking it all together. I'll move the classes it distilled onto class diagrams detailing bits of the design. That's both easier and quicker.

My take on UML:

Quite often you have to sketch on a whiteboard to explain your ideas to coworkers. Or you have to document a system's architecture. Or you use some tool to reverse-engineer the architecture overview from source. UML is the thing here.

Aside from that, I think that any "integrated" approach where you draw UML first and have it automatically converted to source or somesuch is the kind of BS only senior managers and CS Ph.D's could come up with. It doesn't work, in all my experience.

Solar wrote: Aside from that, I think that any "integrated" approach where you draw UML first and have it automatically converted to source or somesuch is the kind of BS only senior managers and CS Ph.D's could come up with. It doesn't work, in all my experience.

100% ACK

JoeKayzA wrote:

Solar wrote: Aside from that, I think that any "integrated" approach where you draw UML first and have it automatically converted to source or somesuch is the kind of BS only senior managers and CS Ph.D's could come up with. It doesn't work, in all my experience.

100% ACK

I agree, up to the point of generating empty class and method definitions, which is quite useful as it saves a lot of mechanical typing. Unfortunately this does not work reliably for C++ in any UML tool I've used.

UML is fine when you have to illustrate design patterns, etc, too. Yet when it comes to using design patterns, a UML-to-code program isn't that handy (typically, you want to add patterns during code refactoring, not just when you write code out of nothing)...

As for reverse-engineering tools that build UML graphs out of source/binaries typically produces over-complicated graphs containing hundreds of boxes and links all over the place, rarely put things that you consider "close" to each other nexto each other etc. so their output is pretty useless imho.

I like UML, It allows you to express your ideas into a easy to manage form. It also allows to only worry about the design in the inception and elaboration phases of development (which is what UML was designed for), This means that your classes and databases will be better structured and if done well allow for future expansion to the project. This also means that the analysis team don't need to know any thing about how it is going to be implemented.

The thing I sort of don't like is all of the documentation involved in UML. I mean to even get started with it you have to write at least 20+ use-cases and a couple of flow of events. And in some cases you have to write a scope document or requirements document (Not trying to scare you). But on the other hand the all the documentation allows you to better "define" and understand the problem at hand.

As for RAD(Rapid Application Development) tools, If used correctly can produce all classes needed and even genrenate code in any language to a point where all you have to do is implement is the base classes.

@Cheery: I can see that you have not looked into UML that much

I use UML in my Systems Analysis classes in college.

Patrick