UML tool for team development

[Leandro Oliveira]

Do you know any good UML tool for team development...
Jude is really weak...


Thanks in advance!

[Ilja Preuss]

White boards work very well, if your team is colocated.

But tell us more: what are you looking for in a tool, and what does Jude miss?

[Simon Brown]

And how much do you want to pay?

[Scott Ambler]

The vast majority of software modeling is performed using simple tools such as paper and Plain Old Whiteboards (POWs). This is something that the folks involved with the OMG prefer that you don't recognize.

-Scott

[Leandro Oliveira]

I work in a project with 3 software designers. We use Espiral process. Sometimes I need something modeled by other designers. But with jude, we can't work on the same jude project at the same time, and we have redesign many things already designed... Is there a tool that could help us!? We don't use the whiteboard because we like to keep the design updated. When we refactor applications we refactor the design before.

[Scott Ambler]

Why can't you keep the diagrams on the whiteboard and simply evolve them as you need to?

- Scott

[Leandro Oliveira]

But we have to archive the project.
And, I would need many whiteboards to design!?

I'm new with software design!!
Do you know where I could find a "best practices"!?!?

Thanks in advance.

[Ilja Preuss]

I think you are confusing design with design artifacts external to code. It's really the code that is the final design document.

Anyway, Scott's Agile Modeling website might help you: http://www.agilemodeling.com/

[Ilja Preuss]

Originally posted by Leandro Oliveira:
But we have to archive the project.

What for?

You could use electronic whiteboards, or http://www.polyvision.com/products/wbp.asp

And, I would need many whiteboards to design!?

How many do you think you would need?

http://www.developerdotstar.com/mag/articles/reeves_design_main.html might also give some interesting insights.

[Gerardo Tasistro]

Might want to check out www.gentleware.com and their Poseidon product. The enterprise edition is the one you're looking for.

[Scott Ambler]

Digital snap shots of whiteboard photos work very well, I do it all the time. Also, you don't really need to keep all the diagrams, just the ones which actually add value. I've built very large systems where the architecture was drawn on whiteboards. When we run out of space, we just erase the lowest priority diagram. At the end of the project, simply through pure Darwinism, you end up with the most important diagrams left on the boards. This is likely what you'll need in your overview docs.

- Scott

[Reid M. Pinchback]

Originally posted by Scott Ambler:
The vast majority of software modeling is performed using simple tools such as paper and Plain Old Whiteboards (POWs)[/URL]. This is something that the folks involved with the OMG prefer that you don't recognize.

Which brings up something I've been wondering about lately. There seems to be a sustained media (publishing) attention lately to MDA, executable UML, and assorted generative techniques that seem derived from, or at least motivated somewhat by those (e.g. Eclipse Modeling Framework).

Does this stuff have legs? Not trying to hijack the topic; I'm wondering if there is enough reality to this stuff that it would be useful for non-trivial team projects. If so (back to the original topic), with what tools, and more importantly with what caveats?

One half of my brain likes slicing and dicing a large problem into diagrams that force me to think about the problem, but the other side learned the directness of test-driven development is a Good Thing (sorry Martha, hate to steal your tag line but...). The concern I have in the case of teams is that it seems to be much harder to get people to shift to (frankly to even try) test-driven development than I would have expected.
Tends to motivate you to look around for alternatives to add to the bag of project tools.

[Ilja Preuss]

Originally posted by Reid M. Pinchback:
One half of my brain likes slicing and dicing a large problem into diagrams that force me to think about the problem, but the other side learned the directness of test-driven development is a Good Thing (sorry Martha, hate to steal your tag line but...). The concern I have in the case of teams is that it seems to be much harder to get people to shift to (frankly to even try) test-driven development than I would have expected.
Tends to motivate you to look around for alternatives to add to the bag of project tools.

I don't think that MDA can or should replace TDD. Executable UML just makes UML a programming language - a program written in UML still can contain bugs. (This is true of every other modeling language, too, I'd assume.)

Until now, noone could tell me how to write automated tests for UML diagrams. Not that I'd say it's impossible, but I'm quite skeptical about the benefits...

[Scott Ambler]

Which brings up something I've been wondering about lately. There seems to be a sustained media (publishing) attention lately to MDA, executable UML, and assorted generative techniques that seem derived from, or at least motivated somewhat by those (e.g. Eclipse Modeling Framework).

I suspect that the "uber modeling tool"-based approaches to modeling are very unrealistic. At Examining the MDA and Are You Ready For the MDA? I provide a fairly coherent argument for why the MDA is a niche technology. I suspect that this vision is appropriate for about 5% of the business application development market place, about another 20% will use some form of softare-based modeling tool but nowhere near what MDA proscribes, and that the other 75% will only use simple tools such as paper and whiteboards.

So why does the MDA get so much press but whiteboard modeling virtually nothing? Because the tool vendors don't make any money sell whiteboard markers, the consultants can find more business helping you with a complex approach (e.g. MDA) instead of a simple one, and the computer science academics rarely do observational studies so they don't have a clue as to what is happening in the real world.

- Scott

[Stan James]

Leandro, sounds like most of the answers here simply advised against keeping tool-based models, but we often find ourselves in places where somebody demands them and it's not really even open for discussion. For some reviews around here if I showed up with a snapshot of a whiteboard they's say "Ho ho ho, very cute, try again."

For very big bucks, Rational Rose (I haven't kept up with the latest rebranding, whatever they call it today) lets you break a model up into subfiles at arbitrary boundaries. You have to read all subfiles to open a model, but you can use a locking version control tool (which will raise a whole new round of arguments from the Agile folk) if you feel the need to control who changes which bits.

[Gerardo Tasistro]

All the arguments I've been seeing are based on the upfront cost of the solution and some rather circular arguments. Sure whiteboards are cheaper and UML requires training, but if we all played along these rules we'd still be digging with shovels instead of excavators and other machinery.

The reasons I find for using some sort of UML tool are the following

-ease of replication: Sure whiteboards are cheap, but try making a copy of it again and again. Snapshooting it with a digital camera is nice, but rather unprofessional.
-ease of modification: Say you forgot something in the middle, need to add something or modify layout. Whiteboard requires you to erase and redraw. Tools just copy, paste and move around.
-tracking changes: Some tools can use CVS or version control, in the worst case you can just hardcopy every week and keep records of how things evolved. I've found that whiteboard approaches make it hard to keep records of changes (specially given the redraw process). So it is rarely done. Changes through various iterations of the project don't get properly updated on the whiteboard(particularly true on the first few weeks). I've also found that tools help you monitor time. Since sometimes you come along the all too famous "ups, and we'll need that too". You add it to the project, don't add it to the diagram and then ask yourself why you're two weeks behind schedule.

Now we can get into the more elaborate UML to Java and back to UML gadgets. Are they really usefull? Although Scott's argument that few are trained is true. It seems to me like a chicken and egg problem. Rather circular problem that boils down to money and how much are you willing to pay to have the tools and the training.

First and furthermost I think Java to UML is a must. Sure your whiteboard diagram can say you have this and that component and packages, classes going in this way and that. But did you really code that? With a tool you can check and see if your code represents your diagram. Things get worse if halfway through you realize the whiteboard isn't the best model. You refactor your code and (now answer this one truthfully) you modify your whiteboard. Yea right. Usually the whiteboard starts to lag and lag and lag.

Another reason Java to UML is a must in documentation. Sure JavaDoc is really nice, but once you see what some of these tools can do you can't live without them. Turn your code into UML, document, print and sit down to think things over.

Now up to now I haven't used a skill set that borders on nuclear physics have I? Nothing beyond what you'd do with say PowerPoint. Just basic understanding of UML diagrams, some Get Started Guide with MyUMLProgram and you got all this.

Now I wont boast of being an UML expert and yes two way design is still above me. I might use it for the beginning stages, but now all the way through the process. On this I will agree with Scott in that it takes a special set of skills and understanding to do efficient two way UML-Java work. But the fact that I can't do it right now is no justification for not having the tool. Because if I don't have it right now how do I get the skills. On and on the argument goes.

So it boils down to nickles and cents. I'm willing to pay between nothing and 1000 US dollars for a tool like that if it just gives me the first few features and a quick Java to UML. Simply because my time is worth more. Doing that by hand can eat a couple of hours a week. Add it up and you'll find the tool to be not that expensive. I would not put more than 2000 US dollars on the table because my skills are not worth it right now. A lack of two way development doesn't justify such a sophisticated tool.

To sum things up. Every case is different. Depends on what you want to do, what you know and how much money you have. I started with Argo UML (http://argouml.tigris.org/) which is free and now work with Poseidon (which cost me about the said $1000). Hope this helps people get started in UML and break the "skill" barrier that "keeps" us within the realm of whiteboards.

[Ilja Preuss]

Originally posted by Gerardo Tasistro:
All the arguments I've been seeing are based on the upfront cost of the solution and some rather circular arguments.

I'm not sure how you've come to that perception.

Sure whiteboards are cheaper and UML requires training, but if we all played along these rules we'd still be digging with shovels instead of excavators and other machinery.

I'm not suggesting whiteboards because they are cheaper, but because often enough *they work better*. And I'm certainly all for using UML on the white board, where appropriate.

And, to go with your analogy, many software projects using the latest UML software are like using the latest big fully automated high tech excavator, although what the team really needs most is a small bag filled with sand.

-ease of replication: Sure whiteboards are cheap, but try making a copy of it again and again. Snapshooting it with a digital camera is nice, but rather unprofessional.

Unprofessional? What do you mean by that?

-ease of modification: Say you forgot something in the middle, need to add something or modify layout. Whiteboard requires you to erase and redraw. Tools just copy, paste and move around.

Doesn't happen as often as you might think. Often, the layout isn't as critical as those tools make you feel. And redrawing a something on a whiteboard actually is much less costly than doing the same in some software tool - and often enough the right thing to do, because it also forces you to concentrate on the essential and get rid of cruft.

-tracking changes: Some tools can use CVS or version control, in the worst case you can just hardcopy every week and keep records of how things evolved. I've found that whiteboard approaches make it hard to keep records of changes (specially given the redraw process).

And keeping track of history is important because...? And a history of white board photos would fullfil that need because...?

Changes through various iterations of the project don't get properly updated on the whiteboard(particularly true on the first few weeks).

If that's true, that has to mean that the diagrams actually aren't used, hasn't it?

I've also found that tools help you monitor time. Since sometimes you come along the all too famous "ups, and we'll need that too". You add it to the project, don't add it to the diagram and then ask yourself why you're two weeks behind schedule.

I'm not sure I understand what you are getting at here. Do you have an example of what happened in one of your projects?

Now we can get into the more elaborate UML to Java and back to UML gadgets.

Not to me. If I want to know what the code looks like, or want to create/change code, I work with code. The value of UML to me lies in *abstracting* from the code - to hide details that aren't important to the point I want to make. That can't be done automatically by a tool.

First and furthermost I think Java to UML is a must. Sure your whiteboard diagram can say you have this and that component and packages, classes going in this way and that. But did you really code that?

If your team doesn't know from simply working with the code and the diagrams in parallel, you're probably in trouble, yes. I wonder how that could happen, though.

Things get worse if halfway through you realize the whiteboard isn't the best model. You refactor your code and (now answer this one truthfully) you modify your whiteboard.

Either that, or I simply erase it. Depends on whether it's still needed - and what I draw the whiteboard model in the first place.

But if your diagram is sensitive to low level refactorings, it's possibly simply too detailed.

Another reason Java to UML is a must in documentation. Sure JavaDoc is really nice, but once you see what some of these tools can do you can't live without them.

If the UML simply is a one to one transformation from the code, I can't see much value in it. Again, it will be missing the abstractions that are necessary to add significant value.

Turn your code into UML, document, print and sit down to think things over.

Mhh, I must be working very differently from you.

OK, if that works for you, that is great. Still, those diagrams probably aren't a good *team* tool, or good documentation.

Now I wont boast of being an UML expert and yes two way design is still above me. I might use it for the beginning stages, but now all the way through the process. On this I will agree with Scott in that it takes a special set of skills and understanding to do efficient two way UML-Java work. But the fact that I can't do it right now is no justification for not having the tool. Because if I don't have it right now how do I get the skills. On and on the argument goes.

I really, really believe that it's not as much a matter of skill, but more a matter of general appropriateness of tools. I simply can't see how UML is a better programming language than textual code. It is a modeling language, and modeling implies a form of abstraction.

To sum things up. Every case is different. Depends on what you want to do, what you know and how much money you have. I started with Argo UML (http://argouml.tigris.org/) which is free and now work with Poseidon (which cost me about the said $1000). Hope this helps people get started in UML and break the "skill" barrier that "keeps" us within the realm of whiteboards.

I agree that it depends on what you want to do. And unfortunately, we don't yet have an answer on that question from the original poster. So until we get that, it's really hard to answer.

For what *I* want to do with UML, most often a white board (or a napkin) is exactly the appropriate tool. And because I feel that more sophisticated tools often actively get in the way of using UML effectively, I very much hesitate to recommend them without knowing more.

And I don't feel at all that white boards are holding me back in learning how to use UML effectively. In fact I'd argue that people who refrain from using white boards extensively are missing on learning some very effective practices.
[ January 23, 2006: Message edited by: Ilja Preuss ]

[Gerardo Tasistro]

I come to this perception from reading the thread. Go back and you won't find a post that suggests an answer to his question. Just a whiteboards work well, are good enought, are better or something along those lines.

Don't be mistaken. I use whiteboards. I take photos of them and then print them for records. That doesn't substitute UML software tools and it certainly doesn't answer the original post's question. And yes they are unprofessional. Imagine a documentation full of photos of whiteboards.

Regarding the example you want. Usually during the analysis I start with a whiteboard diagram. Then pass it to UML. The printed UML gets thought out and worked with the client. As you start to learn about the processes you sketch more on the whiteboard. Those ideas are then passed to UML and the UML diagram grows in complexity. Obviously your initial time estimate and TODO list grows as more "ups, and we'll need that too" modules get "discovered" by the client and included in the project. I find it useful to have UML software tools that help me add and modify my work without reworking the whole whiteboard or recopy it into a new diagram. I find UML history diagrams useful to justify requirements and budgets. And while you can do a lot of this with whiteboards, a software tool just does it much faster.

Regarding the Java to UML feedback. Sure if my team can't do it from do it from working with the code and diagram in parallel I'm in trouble! No duh! But that's exactly the use of this tool. To see if my team can do it before I find myself in an even bigger set of trouble. We can call it validation if you will.

And sure you can refactor your whiteboard by hand, but that takes time. With an UML tool that happens automatically when you sincronize diagram and code. That way you can "concentrate on the essential and get rid of cruft."

Finally I don't get were the perception that for me textual code is a "lesser" as compared to UML. I never said that and I don't support it. I find UML to be a great block builder and block visualizer and a software tool is valuable sidekick for software development. I also never said it subsitutes whiteboards. Nor did I say I UML the whole project and convert it into a working Java application with the click of a button. Like I clearly said. I use whiteboards, but quickly move those ideas to the general project UML. Write code, check the program, do more diagrams, do more code, do more testing, do more code to UML visualization, etc etc etc.

Ah, and while we are at it. I don't think whiteboards hold you back from anywhere, specially from UML. I said that the lack of skills in UML and UML software tools in particular does keep you in the real of whiteboards. I'm not in a "whiteboard UML" vs "software UML" battle here. But do consider it important to dive into software UML tools to break the skill barrier and begin to enjoy certain benefits whiteboards can't give you.

[Michael Duffy]

Originally posted by Leandro Oliveira:
Do you know any good UML tool for team development...
Jude is really weak...


Thanks in advance!

I disagree that JUDE is weak. I've used Rational Rose, Together/J, and Visio, and I've found that JUDE is better than all of them. It does a good job on the UML standards and lets me import/export Java nicely. What's the weakness? I haven't found it.

[Ilja Preuss]

Originally posted by Gerardo Tasistro:
I come to this perception from reading the thread. Go back and you won't find a post that suggests an answer to his question. Just a whiteboards work well, are good enought, are better or something along those lines.

How is "white boards work very well, if your team is colocated" not an answer to the original question?

Seriously, if I needed the help of a designer, my preferred way of working were to meet with the designer on a white board and discuss the design with him.

Of course the original poster might answer "I can't/don't want to do that" - which could lead to some interesting follow ups. Still, the above simply is the advice I know to give initially.

Your advice obviously would be different. I don't have a problem with that. I'd just ask you to respect mine, too.

Don't be mistaken. I use whiteboards. I take photos of them and then print them for records. That doesn't substitute UML software tools and it certainly doesn't answer the original post's question.

How do you know that it doesn't substitute software tools *in the original posters situation*? I'd think that the only person who could tell whether the OPs question is answered is himself...

And yes they are unprofessional. Imagine a documentation full of photos of whiteboards.

What would be unprofessional about such a documentation? Why should I, as a developer who has to work with such a documentation, care? With other words, what bad would happen because of the existance of such a documentation?

Regarding the example you want.

Interesting example that shows that we work very differently.

What I asked for, though, was an example of a situation where you got in trouble because you didn't use a software tool for diagrams.

Usually during the analysis I start with a whiteboard diagram. Then pass it to UML.

So on the white board you don't use UML? Or are you just confusing terminology here?

The printed UML gets thought out and worked with the client. As you start to learn about the processes you sketch more on the whiteboard. Those ideas are then passed to UML and the UML diagram grows in complexity. Obviously your initial time estimate and TODO list grows as more "ups, and we'll need that too" modules get "discovered" by the client and included in the project. I find it useful to have UML software tools that help me add and modify my work without reworking the whole whiteboard or recopy it into a new diagram. I find UML history diagrams useful to justify requirements and budgets.

That's not what I typically use UML for, which might explain a lot of our differences.

And sure you can refactor your whiteboard by hand, but that takes time. With an UML tool that happens automatically when you sincronize diagram and code. That way you can "concentrate on the essential and get rid of cruft."

Your and my experience certainly differ on this one. I've never found a software tool that made it easy to generate simple UML diagrams from code that expressed what I wanted them to express.

Software tools are also often much less useful in a collaborative situation (i.e. during a discussion). And they often don't allow customizations that are essential for adapting a diagram to the current needs.

Finally I don't get were the perception that for me textual code is a "lesser" as compared to UML.

I didn't say that.

It did sound to me, though, as if you generate some code from your diagrams. I don't see value in that activity.

I said that the lack of skills in UML and UML software tools in particular does keep you in the real of whiteboards.

Interesting theory, but not supported by my experience.

I'm not in a "whiteboard UML" vs "software UML" battle here. But do consider it important to dive into software UML tools to break the skill barrier and begin to enjoy certain benefits whiteboards can't give you.

I've used UML software for some time. In fact I once worked on a project where a UML tool was the primary IDE.

So I'd say that I don't use white boards because I don't know the software tools, but exactly because the software tools I did experience did provide much less value to me.

[Scott Ambler]

Don't be mistaken. I use whiteboards. I take photos of them and then print them for records. That doesn't substitute UML software tools and it certainly doesn't answer the original post's question. And yes they are unprofessional. Imagine a documentation full of photos of whiteboards.

I write documentation with whiteboard photos all the time, in fact I've written several books, with different publishers, that included whiteboard photos.

I agree with you that you can use CASE tool in addition to whiteboards, in fact I point this out as one of the three main categories of modeling strategies (see Approaches to AMDD). BUT, the reality is that many people don't have access to these tools, nor do they have the skills to use them, nor are they even motivated to use them.

- Scott

[Ilja Preuss]

Originally posted by Scott Ambler:

I agree with you that you can use CASE tool in addition to whiteboards, in fact I point this out as one of the three main categories of modeling strategies (see Approaches to AMDD). BUT, the reality is that many people don't have access to these tools, nor do they have the skills to use them, nor are they even motivated to use them.

Scott, do you think that using CASE tools always adds value? Serious question - your list of reasons not to use CASE tools seems to imply that...

[Reid M. Pinchback]

Starting to feel like a lot of this thread fits into the category of "violent agreement". The agreement is "for my own work I know what makes sense". The rest is mostly energetic debate over experiences that probably aren't going to translate well from one person (or team) to another. No big surprise there.

Originally posted by Scott Ambler:
nor do they have the skills to use them, nor are they even motivated to use them

I'm inclined to think that this is one of the more germane points, one that it easy for people to forget about. Methodologies abound. Tools abound. Ultimately it is the behaviour of the people involved that drive the outcome. Discussions of "to-CASE-or-not-to-CASE" or "to-UML-or-not-to-UML", etc., etc., in isolation can be fun but unlikely to drive an issue to some resolution. Maybe easier to resolve when you are talking about an individual, but harder as the size of the team grows (and teams were the starting point of this thread).

I think most of us sooner or later find that approaches requiring universal agreement in the team are difficult to make work (just remember your last squabble over a broken build!). Individuals vary too much in their skills, approach and attitude towards their work (as this thread shows). Speaking only for myself, I doubt CASE until I see (affordable)tools that help the people who want them, but are 100% orthogonal to the activities of those who don't - in other words, to allow a work process that doesn't "break" when somebody opts out of the activity.

I haven't used Together personally, but from other people I get the impression that its critic-like functionality works along those lines (you either pay attention to the code critics or you don't). Rose, on the other hand, mostly expects everybody to play by the same set of rules or you spend a lot of time trying to keep files, diagrams, directories in sync. I've used Rose somewhat, I like the pretty pictures, but doubt I'd ever again expect anybody else on my team to give it so much as a passing glance. Unless you work in a very regulated or high-ceremony environment, it just isn't something you can ensure which means you are unlikely to derive value from the tool no matter what its merits.

Keeping human beings in sync for the sake of a tool is very tough, even if you happen to feel it is justified. If somebody is looking for a UML for team development, that is probably an issue to keep in mind while evaluating various options. If the team is all enthused/engaged, you have more options. Less enthused, not so many options.

[Scott Ambler]

Scott, do you think that using CASE tools always adds value? Serious question - your list of reasons not to use CASE tools seems to imply that...

CASE tools often remove value from the overall effort, as other people have implied. You need a good tool in the hands of good people who know what they're doing and who are allowed to do the right thing as the situation demands. That doesn't seem to happen a lot, but it definitely does every so often.

- Scott

[Don Morgan]

I've always found it easy to go back and forth from whiteboard to code to CASE tool (Rational Rose). By the way, I am not sure where it got started, but the idea that these tools are "complicated" or "difficult to use" is unfounded. Also, you do not need to follow a specific methodology to use them, and you can use them as much or as little as required. At least this has been my experience.

*Most* whiteboard diagrams look like sh*t compared to diagrams from a tool (unless of course you are a Monet, Rembrandt, da Vinci, van Gogh or Ambler. Yes, Scott, the diagrams in your books are good!). Another issue is that even if the photos of your whiteboard diagrams truly are great, some people, typically important people, will make a judgement just based on the fact they are "hand drawn scribbles".

I used to have long arguments about why I preferred hand written slides, my "hand drawn scribbles", to Powerpoint, but finally caved.

[Gerardo Tasistro]

Ilja, I'm sorry. I think your've fallen into irrationality. I believe I'm done with this thread.

[Scott Ambler]

Thanks. My diagrams are great because I follow basic style guidelines. I've got them summarized at Modeling Style Guidelines.

- Scott

[Ilja Preuss]

Originally posted by Gerardo Tasistro:
I think your've fallen into irrationality.

Rest assured that I'm as rational (and as passionate) as usual. Nothing to be sorry about.

In contrast to Reid, I feel that we are in violent *dis*agreement. I have no problem with that - there is room for more than one opinion at JavaRanch.

If to you that means one of us has to be wrong (and obviously not you), that sounds a little bit unfortunate - and perhaps not as respectful as I'd like - to me, but I can live with it.

[Gerardo Tasistro]

Look Ilja I don't know if[whiteboards] it substitutes software tools or not in the original post. Personally I don't care because the original post WAS NOT ASKING TO SUBSTITUTE A SOFTWARE TOOL. It was asking for a better SOFTWARE tool.

Secondly we don't know the team is collocated.

Regardin your comment:

"What would be unprofessional about such a documentation?"

Now if you need to ask....

BTW, and given a previous post I'd like to ask do you know what PowerPoint is and what it is used for? Sorry for the sarcasm, but I just don't get your question. Or actually how your question can be backed by any seriousness. Or at best any generalization.

I'm sure you're blessed by great caligraphy skills. Your boxes and arrows must be perfect and you write in true type Arial 12pt, but other mortals like myself have problems. So we use tools that make our work look nice.

I also envy your 2000 dollar SLR digital camera with which you take photos of those whiteboards. Other like myself have to do with 200 or 300 dollar aim and shoot cameras.

Now I'll try to skip over the parts of your post that look more like a Windows vs Linux FUD war and get down to the grist.

I'm sorry you haven't found a software tool that fits you, but others have. And I don't find it fair for you to generalize your misfortune over others good fortune.

I don't consider a "collaborative" situation to be a meeting or discussion as they are by default collaborative. Hence a "collaborative" discussion or "collaboravite" meeting is a redundant term unless you're having a meeting with yourself and are schizophrenic. I see a collaborative situation not only as a meeting, but as the interaction of various members or teams for a common goal. Team which can or can not be collocated. Meetings in my point of view are just a process inside the whole collaboration.

In such situations[collaboration] I find software tools to be superior to whiteboards in two major areas: replication and editing. Try sending 20 copies of your whiteboard to your printer. Or better yet do a copy paste on your whiteboard.

Aside from the features mentioned in previous posts, software tools and UML software tools in particular also add the feature of locking you into a set of diagram primitives (UML itself). That while it might seem limiting is also very practial in transfering ideas as each widget means one and one thing. While I might not use UML on the whiteboard because sometimes (actually, most of the time) your client doesn't undertand UML. I sure use UML on the software and final diagrams. Because it standardizes the language. There is no ambiguity. And through it I can collaborate with other team members. Be them collocated or not.

I apologize if I sounded rude by saying you've fallen into irrationality. But I don't find any coherence between the question asked and the answer given by you. Although I don't try to push an "I'm right and you're wrong" position it is clear I have found software UML tools useful and you haven't. Hence my comments although not necesarily right are more educated and atuned to the question at hand than yours given our UML software experience. More so given that we both agree on the fact that we work in different ways one with software tools and one without. If a certain "violent" disagreement is percieved from me it isn't so much from a disagreement on your work methodology, but rather your addition of irrelevant data to a thread. For this violent position a apologize.

[Scott Ambler]

I just wanted to point out that the diagrams on my site, and in the AM book, were shot with a 3.3 megapixel camera. Similar cameras can be found easily for $200.

Also, as far as unprofessional goes, it depends on the situation. A few years back I was giving a management presentation overviewing the scope and architecture of a very large system (the largest this client was attempting to date). The presentation contained many sketches. A competitor from another consulting company was foolish enough to point out in the presentation that it was unprofessional to include such diagrams in the slides. I pointed out that my bill rate was fairly high and that I felt it would be unprofessional to spend several days creating slick looking diagrams when I could spend several minutes cleaning up the snapshots which conveyed the exact same information. The C-level people in the room agreed with me.

- Scott

[Ilja Preuss]

Originally posted by Gerardo Tasistro:
Look Ilja I don't know if[whiteboards] it substitutes software tools or not in the original post. Personally I don't care because the original post WAS NOT ASKING TO SUBSTITUTE A SOFTWARE TOOL. It was asking for a better SOFTWARE tool.

If you take a close look, it was asking for a *tool*. But even if it asked for a software tool, I'd be more interested in helping the poster with his problem - including giving him new ideas to think about - than answering a question verbatim. As geeks, we often are a little bit fast with applying software tools where non-software might work better. I like to remind myself and others about this from time to time.

I'm wondering why you seem to be so upset about me bringing software tools into the discussion.

Secondly we don't know the team is collocated.

Correct, we are mostly shooting into the dark.

"What would be unprofessional about such a documentation?"

Now if you need to ask....

Well, I can imagine some reasons why *someone* could think about it as unprofessional. But what I'm interested in here is *your* opinion. And frankly, I'm not sure we mean the same thing by the term "professional".

BTW, and given a previous post I'd like to ask do you know what PowerPoint is and what it is used for?

Yes, used it quite a lot. Interestingly, for my last presentation I tried a mind map at the white board instead, and it worked really well.

I'm sure you're blessed by great caligraphy skills. Your boxes and arrows must be perfect and you write in true type Arial 12pt, but other mortals like myself have problems. So we use tools that make our work look nice.

Quite to the contrary - my calligraphy is horrible. But the diagrams typically don't have to look nice, they just have to communicate.

That's what professional means to me: using the right tool at the right time, one that solves the problem at hand effectively. For a business presentation that had to look good I'd certainly use some software tool. For a diagram that I need to communicate an idea to the rest of the team, a white board often is more efficient, in my experience.

I will try to photograph and post a recent example on monday.

I also envy your 2000 dollar SLR digital camera with which you take photos of those whiteboards. Other like myself have to do with 200 or 300 dollar aim and shoot cameras.

I don't feel that your sarcasm helps in the discussion. If you are interested in knowing what works for me, and how it works, I'd love to share my experience and hear about yours.

I'm sorry you haven't found a software tool that fits you, but others have. And I don't find it fair for you to generalize your misfortune over others good fortune.

Point taken. Please notice that I feel similarly about your dismissive tone regarding white boards as a "fully fledged UML tool".

I see a collaborative situation not only as a meeting, but as the interaction of various members or teams for a common goal. Team which can or can not be collocated. Meetings in my point of view are just a process inside the whole collaboration.

Yes. On the other hand, if possible, a face to face conversation almost always works better than any more document driven approach, in my experience.

For example, when I have a doubt about the design of a part of the application I'm not familiar with, I will ask into the room, not look into some documentation.

In such situations[collaboration] I find software tools to be superior to whiteboards in two major areas: replication and editing. Try sending 20 copies of your whiteboard to your printer. Or better yet do a copy paste on your whiteboard.

Never felt the need to do so. That's not to say that I've never used a software tool to print a UML diagram and pin it on the wall. It just didn't provide enough value to do it again.

But then again, there are electronic white boards, as you probably know.

Aside from the features mentioned in previous posts, software tools and UML software tools in particular also add the feature of locking you into a set of diagram primitives (UML itself). That while it might seem limiting is also very practial in transfering ideas as each widget means one and one thing.

The limiting factor is much more important to me than the unificating one.

I sure use UML on the software and final diagrams. Because it standardizes the language. There is no ambiguity. And through it I can collaborate with other team members. Be them collocated or not.

I don't understand why we are at this point of the discussion again. Sure, UML is great - I use it all the time. But if you know UML, you don't need a tool that enforces its correct usage - it just comes naturally at the white board.

I apologize if I sounded rude by saying you've fallen into irrationality. But I don't find any coherence between the question asked and the answer given by you.

Apology accepted. Next time you wonder what I'm talking about, it might be more effective to ask questions.

Although I don't try to push an "I'm right and you're wrong" position it is clear I have found software UML tools useful and you haven't. Hence my comments although not necesarily right are more educated and atuned to the question at hand than yours given our UML software experience.

Well, I guess we interpreted the original question differently.

If a certain "violent" disagreement is percieved from me it isn't so much from a disagreement on your work methodology, but rather your addition of irrelevant data to a thread.

I still don't feel that suggesting using a white board as a UML tool is obviously irrelevant to the situation the original poster is in. If that's our main disagreement - well, we should probably just agree to disagree.

[Ilja Preuss]

Originally posted by Scott Ambler:
Also, as far as unprofessional goes, it depends on the situation. A few years back I was giving a management presentation overviewing the scope and architecture of a very large system (the largest this client was attempting to date). The presentation contained many sketches.

I probably wouldn't have had that much courage. Thanks for sharing this story!

[Ilja Preuss]

Here is a recent example on how we use UML on the whiteboard:



The diagram came into being during a twenty minute discussion where a coworker explained to me the existing design (black) and flow (purple), and we discussed possible changes to be applied to implement a new feature (red, yellow).

As you can see, we used a lot of non-UML annotation, which proved to be very effective in communicating what needed to be communicated.

I also used this diagram today for a five minute introduction to my pair programming partner.

I expect this diagram to be updated during the next days while we work on the feature, and to simply be discarded once we are finished with it.

I can't imagine how using a software tool could have been more effective, although your mileage certainly might vary...
[ January 30, 2006: Message edited by: Ilja Preuss ]

[Gerardo Tasistro]

I think I've been clear on my point that during the meetings a whiteboard is great. And in that context unbeatable. My position though is that after the meeting is over UML tools quickly overcome the whiteboard. Your diagram in my case would have evolved to this:

http://www.tasistro.com/ilja/classWithBlackItems.pdf

Then as the red elements got added (possibly in a following meeting although in this specific case we know it was the same one) this would evolve to.

http://www.tasistro.com/ilja/classWithRedAdditionPreAutoLayout.pdf

With the autolayout I might have looked for a clearer view

http://www.tasistro.com/ilja/classWithRedAdditionPostAutoLayout.pdf

In my opinion the software diagrams look "cleaner". This is what I mean by more professional. I know they are both "tecnically professional", but the software version just looks better in my opinion.

As I see it the two scopes can be seen here


http://www.tasistro.com/ilja/scopeDiagram.pdf

With an added pink area of more advanced usage (if the tool supports it). Which would lead to code like the following>


http://www.tasistro.com/ilja/JavaCode.zip

Note that I didn't create any package containers so all classes are just plain old default package.

[Ilja Preuss]

Originally posted by Gerardo Tasistro:
I think I've been clear on my point that during the meetings a whiteboard is great. And in that context unbeatable. My position though is that after the meeting is over UML tools quickly overcome the whiteboard.

Mhh, you seem to work sequentially than me. It's very likely that during the next days I will suddenly stand up, go the three steps to the white board, sketch a new idea into the diagram and ask for the opinion of my coworkers.

Your diagram in my case would have evolved to this:

What do you mean by "evolved"? It rather seems to be *missing* important information from the white board, and doesn't seem to add any value besides looking "nicer".

Then as the red elements got added (possibly in a following meeting although in this specific case we know it was the same one) this would evolve to.

I don't see under what circumstances splitting the discussion into two meetings would have made sense...

With the autolayout I might have looked for a clearer view

No, this didn't make it clearer to me. I wasn't aware of this before, but it seems that the original layout actually had some semantic (although I still couldn't explain it). The autolayouted diagram really looks more confusing to me than the white board one.

Another disadvantage of the autolayout is that while the diagram evolves (for example, the relationship between SRS and Geometry is unlikely to be implemented), the layout changes again, and it's harder to recognize what remained the same.

In my opinion the software diagrams look "cleaner". This is what I mean by more professional. I know they are both "tecnically professional", but the software version just looks better in my opinion.

Well, yes, that's what I suspected. But "looking clean" is not it's purpose. Helping communicate design ideas in a collocated, highly colaborative team is, to me. For that it's much more important that everyone can look at it, and contribute to it at any time, with minimal effort, than that it "looks good".

Which would lead to code like the following

Generating code out of the diagram really wouldn't have had any benefit to us, as far as I see it.

The actual implementation is much more complicated than shown in the diagram. A lot more classes need to be touched and the design decisions evaluated by seeing how the code "reacts" to implementing them.

It really needs to be done very incrementally - in small steps over the next few days. The design details aren't clear yet and need to be evolved while carefully implementing the feature piece by piece. The diagram really just is a sketch of our initial rough idea on how to tackle the problem.

Now, you might be used to working in a very different way. That's fine. The above, though, is how I know to work, and it's working quite well...

[Stan James]

A lot of this gets down to who consumes the information and what they expect. Ilja's picture is the perfect medium for him and his partner, but I can easily think of a few people who would be seriously put off to find it in a design review. (From which I infer (big leap) that Ilja doesn't have formal design reviews, and I'm all the more sad that we do.) One of Scott Ambler's persistent messages is to think through the cost and value of any artifact and make sure it's really doing. The more formal diagrams could be worth doing in some settings but not in others.

Another aspect is ease of editing. I fire up Rose or my own sequence diagramming tool now & then when I tire of erasing and redrawing paper or whiteboard diagrams. I'll use the tool even for throw-away diagrams if it helps me focus on the problem and not the erasing. But they are much less useful for collaborative sessions where it's better to take turns at the board.

BTW: Ilja, does your picture say "Chili con carne" near the lower left? Now I have to go out for Mexican.
[ January 30, 2006: Message edited by: Stan James ]

[Gerardo Tasistro]

Well it seems we are talking about the same thing. I agree that whiteboards are good in the meeting, but beyond that they fall back. Lacking replicability and editing features found in software tools. I won't go down into this since it is clear that for you erasing today's menu to put a class in is just fine. Personally I find it troublesome how much smaller you have to write and make things as things get tight on the board. Moving stuff around a software tool is much easier.

Please do note that on my post I said "might" look for a better layout. Never saying it was. Just a statement for the sake of exemplifiying. I also took the color change as an milestone for the diagram. Don't know if it really was or was two people on the same day. It was just for examples sake.

The "missing" part wasn't left out of negligence I just couldn't understand what it said. Once again we fall on the neatness of things. Software tools are clearer to read as the do print "nicer" (and smaller "kb") images.

Finally the software part as I stated in the diagram is optional and depends on the needs and modes of work. Never did I say it was a do or die.

I'm glad it works for you. It doesn't for me.

[Gerardo Tasistro]

Stan I believe Ilja is missing the fact that I'm moving beyond the meeting. During the meeting whiteboards are great and software tools are a burden. But a bit of "clean" documentation afterwards doesn't hurt anybody and given the amount of open source and free UML tools out there there is really no reason (money wise) not to sketch it down on the PC.

Sooner or later the UML on the whiteboard will be pretty much terminal. Why not keep a copy of it in a digital format that isn't a JPEG. It is good reference, looks nice, can be transfered around and doesn't cost much (using open source products).

[Scott Ambler]

Gerardo, I think that you're missing the concept that Ilja isn't talking about a meeting, he's talking about agile software development. I think that this is where the conversation deviates: Ilja's environment sounds much more collaborative and flexible than yours. That's perfectly fine, you need to use the right tools for the job.

But, stop and think for a few minutes. How would you act if your team was co-located in its own room, with its own whiteboards that it had complete control over (e.g. you could leave a model on the whiteboards and evolve it as needed throughout the project)? Better yet, if anyone would be allowed to work on any aspects of the model(s), as long as they worked with someone else to do so (and remember, it would be in full sight of the rest of the team)? Better still, that everyone understood that they could and should learn from others through collaboration? How would you work differently in this sort of situation?

Ilja, I'd love to see your white board example written up in a bit more detail and posted on the web. It's the type of case study which would be incredibly valueable to share with others. The vast majority of developers do their modeling on whiteboards, but don't think that it's normal or even modeling because it doesn't match the CASE tool vision being promoted by the vendors out there. As you'd expect, I'd be very happy to link to it from Agile Modeling.

- Scott

[Gerardo Tasistro]

Scott I have thought about it. So my previous posts stand as evidence. I don't discredit the whiteboard. I think it is a great tool and good for the meeting, but that doesn't substitute for UML software. I use whiteboards too, I just happen to pass it to UML software soon afterwards.

Can I keep the whiteboard? Yes. But the printed copy from the software is so much more practical to work on at my desk. I do some prototyping, ground some ideas then rework the model. Write that down on the paper and then update the diagram. Sure I could update the whiteboard, but a pdf goes a lot faster through email than the whiteboard. So my team can have a view of my ideas before we sit down again at the whiteboard.

Now I'd like to ask you Scott. What's your gripe with CASE tool vendors? And all you know about are comercial apps? Before I went out and spent a thousand bucks on Poseidon I used Argo UML and UMbrello for years. Tools which are both free. And I had no vendor breathing down my back. I moved on to Poseidon when I had needs Argo or UMbrello couldn't satisfy. None of which are related whiteboards.

Bottom line is you don't have to spend a buck on software to have UML software tools. They add quite a few features whiteboards don't have. They don't substitute whiteboards for brainstorming, but they beat it in neatness, editing(move, copy, paste) and replicability. And just like it happened with office productivity tools, these too will become comodity items over time. So more features will get added with no added cost.