UML modeling tool

[Hanna Habashy]

hi all:
I want to learn UML, and I am looking for a free tool on the web. Something like an IDE or software. Does anyone know where can I find such a free tool? If there is any?

[Jeff Langr]

Try ArgoUML as a starting point.

[Lasse Koskela]

Here are some options:

ArgoUML is an open source UML tool (a bit crappy, but better than nothing)

Poseidon UML (Community Edition) is a bit more feature rich and polished

EclipseUML is a free plugin for the Eclipse IDE

Objecteering/UML has a free, personal edition

Visual Paradigm Community Edition

Dia is one of the oldest (open source, linux/unix)

Umbrello UML Modeler is another open source product for linux/unix

[Ilja Preuss]

Originally posted by Hanna Habashy:
I want to learn UML, and I am looking for a free tool on the web.

What makes you think you need more than paper and pencil? Serious question.

[Lasse Koskela]

Originally posted by Ilja Preuss:
What makes you think you need more than paper and pencil? Serious question.

If I may...
While Ilja has a point (full-blown UML tools are often more of a burden than a productivity-boost), there's a certain property with tools that may help learning -- they restrict you into the standard, the One way of doing things. Level 2 and Level 3 (Co'burn) developers will probably be annoyed by these restrictions but a Level 1 developer may very well be delighted to have someone (something, in this case) say exactly what can be drawn and what can't.

[Hanna Habashy]

Hi Ilja:
I am using the paper and the pencil now. But it is not effecient enough. I want to be able to share my diagrams with my team, archives all the diagarams of the packages I design, and make a proffissional presentaion to the clients and partners. This are the simplest reasons. UML is a very strong, well featured modeling tool. You can go to google and find more info about UML if you interested.

[Ilja Preuss]

Originally posted by Lasse Koskela:
they restrict you into the standard, the One way of doing things. Level 2 and Level 3 (Co'burn) developers will probably be annoyed by these restrictions but a Level 1 developer may very well be delighted to have someone (something, in this case) say exactly what can be drawn and what can't.

Mhh, my experience with UML tools suggest differently. Most seem to focus on generating code from UML (or the other way round) and thereby actually
- compromise the UML in some areas (such as not allowing certain features of UML they can't easily map to code, for example association classes), and
- focus on a level of detail that's necessary for code generation, but is often counterproductive for other uses.
So I'd think that a tool often will distract you from learning how to effectively apply UML by forcing you to learn how to use the tool and what it can and can't do. Your mileage may vary, of course...

[Ilja Preuss]

Originally posted by Hanna Habashy:
I am using the paper and the pencil now. But it is not effecient enough.

OK - that's a good reason to search for some more effective tools...

I want to be able to share my diagrams with my team,

The best way of sharing I know is on a white board in the team room. That only works for a colocated team, of course.
Besides that, I would suggest trying a scanner or a camera and http://www.polyvision.com/products/wbp.asp - again, seriously.

archives all the diagarams of the packages I design,

Same here. Also, observe how often you really need to take a look at them later on, how much time you spent keeping them up to date - and therefore which ones are really worthy keeping.

make a proffissional presentaion to the clients and partners.

OK, I guess these ones have to be look more "professional" than a sketch by hand.
I do know many people who prefer the freedom they get from MS Visio over the more specialized UML tools, but it's not for free, unfortunately...
http://tersesystems.com/code/?overview=vt14 looks promising, but since I know it, I didn't have to do a "good looking" diagram anymore, so I can't really comment. The last thing I did (after being frustrated by trying Poseidon and some Eclispe plugins) was using Dia, but that had some drawbacks, too.
You might get some more info from http://c2.com/cgi/wiki?UmlCaseVultures
Hope this helps...

[Lasse Koskela]

Originally posted by Ilja Preuss:
So I'd think that a tool often will distract you from learning how to effectively apply UML by forcing you to learn how to use the tool and what it can and can't do.

The devil is in the detail... I agree that tools generally restrict one from learning how to apply UML effectively. I was talking about learning to apply UML. Full stop.
I am using paper and pen as well (haven't touched a UML tool in 6 months or so) and I cope just fine. However, I have a senior colleague who uses Rational Rose a lot and is in fact quite effective with it. I guess it's all about how you use the tool.

[Nathaniel Stoddard]

I'm sorry to popping into a post like this, but is it common in industry to forego the use of UML modeling tools in favor of a paper & pencil approach? Or is what I hear in here a bit of an exception (for the elite?)?

[Jeff Langr]

Greetings Nathaniel,
This is an agile vs. classic debate that seems to crop up rather frequently at JavaRanch. Some developers believe that UML is best used as a precise specification tool, while others believe it is more valuable as a tool for problem solving and quick and succinct communication.
The agile camp believes that putting more detail into up-front UML diagrams quickly results in diminishing returns. The classic camp believes that UML can be the basis for completely model-driven development, where the ultimate goal is to diagram a system, then run it through a tool that generates all the code. They also believe that a modeler can create a detailed-enough set of UML diagrams so that they can hand them off to lower-cost programmers as precise specifications.
I fall into the agile camp. The hype on MDA (model-driven architecture) smacks to me of the many failed pipe dreams such as 4GLs that were supposed to save the world. And, while it can be valuable to do a prudent amount of up-front design, expending a lot of effort in doing so is wasteful, since it's virtually impossible to come up with a perfect design up front.
Designing a software application is not building a house, or even designing a house. It's a ludicrous comparison, yet it's one that surfaces constantly. "We should be able to completely specify a software application using UML, just like we can completely specify a building using a blueprint." Constructing a house or office building is a known quantity--we've put together billions of domiciles over thousands of years. The implications of architectural decisions on construction are well known. The implications of software design decisions on construction are not as well known, and there are vastly more interaction points in software where things can go wrong.
No, building software is more like engineering something brand new. In true engineering, you take small, incremental probes when you build something for the first time. You make a hypothesis based on what you already know, something that you will test against. You build to that hypothesis, then run your test. Based on what you learn, you alter the hypothesis, or keep it and add an additional one. It's the scientific method. (It also sounds a lot like test-driven development.)
An upfront design is a roadmap. It's never a bad idea to spend some time figuring what direction you want to head in. But the road travelled is never the same. There are roadblocks, detours, weather conditions, traffic jams, and so on. You could come up with a very detailed plan to get from NYC to LA, and try to insist on it, but I'll guarantee that 99 times out of 100, you have to learn to adapt and go where the road takes you.
If you want to invest effort in design, learn what good designs are all about. Learn how what you do in code impacts the design and vice versa. Designs don't exist in a vacuum--they must conform to what the construction needs end up being. The more you learn about design, the better your upfront notions of design will be. (Hint: if you think that knowing a few design patterns gives you a good design, you have a lot of learning to do.) You won't need to provide a finely detailed UML diagram, which will change anyway--sketches will suffice.
Having a lot of great-looking UML diagrams and a poorly constructed system is a far worse legacy than the opposite. Having great UML diagrams doesn't say anything about the quality of construction, while having great construction almost always implies you have a good design. In a well-constructed system, it's *very* easy to trace the design. In a well-designed system, anyone on the development team can quickly show you where to find things and how things flow through the system. Most of the proponents of heavy UML and MDA I've worked with know squat about construction. They propose overblown or insufficient designs that realize poorly in code.
Tools such as Together allow you to take quick snapshots of your system, providing considerable levels of detail. Obtaining snapshots like this can be useful, although they tend to hide the trees in the forest. It's just as easy to spend a few minutes every week to update a sketch of the relevant design features. If you feel compelled to retain these UML diagrams, a photocopier is often more than sufficient.
Having said all that, I still use tools such as ArgoUML to produce diagrams that look nice and that I can send electronically. But I spend little more effort on the tool than I would on a whiteboard sketch.
Jeff
[ March 29, 2004: Message edited by: Jeff Langr ]

[Nathaniel Stoddard]

Granted, I've never actually held a real job developing software, but not having models seems very strange to me. I've always figured that the models defined the system, and the code was just a miscellaneous artifact.
I guess that puts me in the classic camp. I don't think that a giant up-front design is a good thing. But something more along the lines of RUP with its iterative party is better. But peeking at RUP documenation shows that models make up a tremendous part of the project (assets, at least). Perhaps I'm just trepid because I've never been very good at reading other people's code--models though are no problem. Is there a moderate camp? I've always heard that since models are more abstract, it takes newbies much shorter amounts of time to get up to speed on projects. But if I read you right, you say that's not necessarily so.
I don't know about the agile stuff. Maybe it's time to do some reading.

[Jeff Langr]

I think you're on the right track and should stick with an iterative RUP-based approach for the time being. I don't believe models are inherently evil; again, I believe that there is a prudent amount of time you should invest in them. The biggest problem I have with the agile movement is that many of the participants assume that it means they have to know nothing about design.
When coaching teams neither familiar with agile development nor very knowledgeable about design, I promote heavier up-front design. Then I demonstrate how you can achieve a better design once you start realizing the original (proposed) design in construction. As teams become educated from both ends, they themselves are the ones who feel they can relax the need for as much detail up-front.
People who know little about good design will produce a bad system, regardless of whether they use an agile or classic approach. (You have to be able to recognize bad design in order to avoid it.) I have no problem with taking time up front to help them understand more about design.
-Jeff-
A system with poor documentation and good design is a far better legacy than the opposite. -JJL

[Jeff Langr]

With respect to the comment about the RUP and lots of models, remember that the RUP is a process framework. It is your job to take the suggested artifacts and principles, and build them into your own customized process. Technically, everything in RUP is optional (is the best RUP instance nothing at all? ).
You can even configure RUP to look like XP. Rational themselves provides a kit, or whatever they call it, that tells you how.
Nowhere does RUP say you should build and keep every one of those models up to date. Also, the level of detail you put into a UML diagram is relevant to which RUP phase you are in. Take a look at Martin Fowler's book UML Distilled for a discussion of this. Inception diagrams, for example, should have minimal detail; your UML should show more detail as you move through the phases (but nothing says that the code can't generate the diagrams in the later phases).
-Jeff-
[ March 30, 2004: Message edited by: Jeff Langr ]

[Ilja Preuss]

Originally posted by Jeff Langr:
The biggest problem I have with the agile movement is that many of the participants assume that it means they have to know nothing about design.

Many? Didn't occur to me...

People who know little about good design will produce a bad system, regardless of whether they use an agile or classic approach. (You have to be able to recognize bad design in order to avoid it.)

Yes, but I also think to be really able to know bad design, you need to have felt the pain caused by it. Putting the (bad) design into code early will help them recognize that it's bad, and learning how to refactor it will help them putting the newly learned into the code immediately.
At least that's what I experienced. I started a hobby project four times, every time with what I thought of as a better design. Every time I did find that it wasn't "good enough", so that I had to start over. Only after learning how to refactor it, I could continue to develop it and improve it's design on the fly.
Of course, with an inexperienced team, I would want to do more design lessons on the white board or something. I don't think that it would be best to do it all upfront, though...

[Ilja Preuss]

Originally posted by Nathaniel Stoddard:
Granted, I've never actually held a real job developing software, but not having models seems very strange to me.

Not having models would certainly be silly. And it's not at all what Agile development is about.
But actually having a model on paper or on disk doesn't buy you that much. Where you need the model is in the heads of the developers.
The paper or the disk is just a medium to get it into the heads, or for longer time persistence if you think the heads won't hold the information long enough.

I've always figured that the models defined the system, and the code was just a miscellaneous artifact.

How could that be? Isn't it the code that is the definitive description of the system - so definitive that the system can get automatically build from it?

Perhaps I'm just trepid because I've never been very good at reading other people's code--models though are no problem.

Yes, sometimes models are just easier to understand than code - at least for specific aspects of the system. Notice that that model doesn't necessarily needs to be created upfront. In an agile team, you can often simply go to a developer more familiar with the code and ask him to explain it to you on the white board. Or you might just pair program with him.
Also, what you can often do instead of producing a diagram of the hard to understand code is to refactor the code into something that's easier to understand. Code *can* be made quite expressive, if you care. (It might also be a matter of tools available. With a good code browser at hand, code can be much easier to navigate than with, say, Emacs or Textpad.)
There is one additional reason for the existence of models. Sometimes, a model is easier and/or less costly to create than the real thing, and therefore allows for more and more rapid experimentation. The model only needs to simulate the aspect of the real thing you want to test for.
That's why architects build models of the houses they plan to build - because building and tearing down the house over and over again would just be much too time consuming and costly. Something similar was true for software development, but with modern hard- and software, it's less and less the case. Today, Eclipse will build my system every time I save a file, often in a matter of seconds. Running the unit tests to see wether I broke something is a matter of minutes. So building models outside of the code is less important now than it was one or two decades ago.

I've always heard that since models are more abstract, it takes newbies much shorter amounts of time to get up to speed on projects.

A bunch of high level diagrams certainly is qutie helpfull. More important to me, though, would be
- tight collaboration with the "veterans",
- well-written, expressive code (you *can* express high level, abstract ideas in code, too), and
- an extensive suite of both system and unit tests

I don't know about the agile stuff. Maybe it's time to do some reading.

Perhaps you'd like to start with http://agilemodeling.com/ to see how modeling *does* fit into Agile Software Development.

[Jeff Langr]

Originally posted by Ilja Preuss:

Originally posted by Jeff Langr:
The biggest problem I have with the agile movement is that many of the participants assume that it means they have to know nothing about design.
--------------------------------------------------------------------------------
Many? Didn't occur to me...

Yeah, many. A lot of what I've done for the past 3-4 years is go into shops where they embarked upon an XP effort, and then proceeded to produce an entangled mess within a couple months. I would sit and code with the developers while talking them through (and sketching) what they had and how to improve it. My personal stats are pretty consistent--only about 2 out of 10 programmers know anything about design.
I should have counted how many times I heard someone say, "XP says you don't have to do design." It was pretty much echoed in every one of the many dozen places I've visited.
Without an understand of what is really meant by "small steps," "simple design," and "constant, vigilant refactoring," a shop that thinks they are doing XP will fail as miserably as anyone else, if not worse. The sad part is that these are not difficult things to learn. The average developer can quickly learn how to build well-constructed, well-designed systems using these practices and principles. But--it takes understanding and discipline.
-j-

[Ilja Preuss]

Originally posted by Jeff Langr:
I should have counted how many times I heard someone say, "XP says you don't have to do design." It was pretty much echoed in every one of the many dozen places I've visited.

Do you have an idea where they have this from? I mean, all the Agile proponents I know are rather explicite about the fact that Agile Development builds on *continuously* taking care of a good design, aren't they?

[Jeff Langr]

That's a great question. I don't think I have all the answers, but:
First and foremost, people hear what they want to hear. Consider that 7 or 8 out of 10 people are inadequately schooled in design. Many of them don't really want to know about design; they'd just as soon take the path of least possible resistance. Most of them view any sort of process as a set of hoops. To them, a process like XP on the surface suggests that all they need to do is go along with the flow and hack at things. "We don't do a lot of heavy design up front" to them translates to "we don't need to do design."
Second, consider that to understand how XP's practices of refactoring, TDD, metaphor, and whatever else impact design, you have to understand a bit about design in the first place. If you don't, you'll approach those practices (TDD and so on) as hoops, not fully understanding their benefits and when you're doing them wrong. In any case, the people that say "we don't do design in XP" don't believe that there is any because they wouldn't understand why in the first place.
Third, the word "design" has somehow gotten to be synonymous with "modeling" in many peoples' minds. If you're not drawing lots of little pictures, you must not be doing any design. Some people prefer not to believe that you can express design directly in code.
Finally, the way people learn about XP has a lot of impact. Many people learn from magazine articles and third-hand information. How many times have you seen someone who thought that "XP == pair programming?"
Most developers learn best from doing, not from hearing, reading, or even seeing. That's why pairing can be very beneficial.
As an example, I've run many labs for TDD where I did a short demo. Students then coded a TDD exercise that was different from the demo. I found that was too much for most people. Instead, I had them do exactly the same thing that I demonstrated.
I also used to demo more involved solutions--perhaps 40-50 combined lines of test and production code. I quickly stepped back to doing a stack demo, less than 30 lines total code, which is about as simple as you can get and still demonstrate all the basic techniques.
Even with both of these moves to more simplicity, you'd be amazed at the wild ideas that students coded once they tried to repeat the exact same exercise on their own. Lately I've moved to more choreographed demos--I type a line of code that you see on the projected screen, you type the same line of code. I click a button, you click a button. It's slower overall, but seems to work better.
-Jeff-
[ March 31, 2004: Message edited by: Jeff Langr ]

[Lasse Koskela]

Originally posted by Ilja Preuss:
Do you have an idea where they have this from?

My guess would be a senior architect reading a blurp on XP in a trade magazine, starting to run around the office "championing" XP and hosting "internal training sessions" himself based on his very own "view" on what XP is. Am I close?

[Lasse Koskela]

I gotta stop opening all new links in the background and going through them one by one... Anyway, I guess I was indeed pretty close

[Jeff Langr]

I have that pattern. I open about 10 windows and then reply to a few, often too late. I just replied to one elsewhere and decided to delete the post since two posts came inbetween the original and mine. Mine ended up being way too repetitive.
-Jeff-

[Lasse Koskela]

Hmm. What should we call this pattern? Dirty Writes?

[Ilja Preuss]

I have that pattern, too...
Jeff, thanks for the explanation!
It reminds me of something Ron Jeffries recently wrote on some mailing list: Every time he does a demonstration on TDD, afterwards there are always people stating things like "Wow, I have read your articles/books, but I never believed that you would *really* *do* all these things..." :roll:

[Jeff Langr]

Yeah, even as I demo, I hear the same thing: "you really do that?" It definitely gets the attention of people.
-j-

[Jim Arlow]

If you are looking for a good UML tool try MagicDraw UML (www.magicdraw.com). It is only a few hundred dollars and is a much more solid tool than ArgoUML. It is also very pleasant and easy to use. I created about 200 UML diagrams for my last book Enterprise Patterns and MDA (ISBN: 032111230X ) in MagicDraw because it is syntactically and semantically very accurate.