Rational Rose alternatives

[Jim Henessey]

Hello,
I'd like to start working with UML, but would like to avoid having to purchase Rational Rose or other high-end UML programs. Does anyone here have recommendations for a professional caliber UML editor that they've worked with which is either inexpensive or free/open source?
Much appreciated.

[Jeff Langr]

I haven't tried it in a while, but ArgoUML seems to be the best place to start.
Also, Visio can do a good job of producing UML diagrams if you have a decent stencil set. The one that comes with Visio is lame. The one at Object Mentor's site works well for me.
-Jeff-

[Ilja Preuss]

Originally posted by Jim Henessey:
I'd like to start working with UML, but would like to avoid having to purchase Rational Rose or other high-end UML programs. Does anyone here have recommendations for a professional caliber UML editor that they've worked with which is either inexpensive or free/open source?

For many situations, the most effective UML tools are pencil and paper or a white board. Seriously.
Asking for a UML editor because you want to start using UML is like asking for a good word processor because you want to start using english...

[Rian Fergusson]

i have been using a great open source UML CASE tool called 'JUDE' ( Java and UML Developers Enviroment ). it is fantasic at generation java quickly and easily.
http://objectclub.esm.co.jp/Jude/jude-e.html
[corrected Link - Ilja]
[ February 11, 2004: Message edited by: Ilja Preuss ]

[Ilja Preuss]

Originally posted by Rian Fergusson:
it is fantasic at generation java quickly and easily.

With all due respect, I don't think UML has that much value as a programming language. For me, UML is most effectively used as a communication tool with coworkers. For that, it has to be flexible enough to be able to highlight specific aspects of the design, while ignoring others. A whiteboard really is the right tool for this.

[Jeroen Wenting]

I agree, but many people (and especially managers and architects) seem to think different.
Given the right UML tool the architect can make some nice diagrams (just like the manager does his planning) and the ready application will pop up out of thin air, no more need for those pesky programmers.
Of course the application will be so much hot air (just superheated thin air out of which it came) and no more than a hollow shell...

[Rian Fergusson]

I am a strong believer in modeling with the goal of generating skeleton code.
My primary reason for this is to completely define requirements. During analysis if modeling is undertaken with a UML CASE tool without the intention of generating code then the modeling process seems less relevant in relation to the systems implementation, but provides a stagnate period of documentation.
example, if I am modeling using a UML CASE and I have a rough idea how I will design the system (which most designers have) and I have no intention of generating code, then the process of modeling is only a documentation task because if the model was complete then a skeleton code could be created (why wouldn�t you use a code generator if it will basically produced the same code that you will be forced to write). Moreover, modeling without the intention of generation will lead to undefined requirements because the actual code is not affected by the model. If code generation does not occur your model doesn�t need to be complete (for system creation). I bet if you compared a model which was not generated with a complete reengineered model of the same system there would be great differences, differences alot more noticeable than with a generated code skeleton. Generated code when used properly will provide a framework for the whole system. A framework which fulfills requirements is a lot more difficult to modify than no framework, after all the framework will be basically perfect because design problems and requirements were nutted out in the pre-development stages
in conclusion, the basis for modeling as documentation is pointless unless you want an overview of how the system work. Model for the system, not for the maintenance�..
I too believe pen and paper is fantastic but only for very very high level designs.

P.S. please give me your thoughts on this topic..
Thank you
Rian Fergusson

[B Hayes]

Rian! Thanks a bunch.. I've been looking for an Open-Source Sequence Diagram editor

[Jim Henessey]

I'm thankful for all the feedback and grateful for the links to various editors provided. I've found that the past few projects I've worked on, there's been too much muddled thinking from the outset in terms of planning and organization of code - although UML is a tool and will not in itself save you from this, I'm hoping that it will bring greater discipline to the process. In the past, my planning has too often been very high level, so that when specs or circumstances change mid-development, tracking the full impact of these changes on all affected routines has been haphazard, resulting in time wasted tracking down bugs and last-minute code re-writes.
I'm hoping to use UML with the concepts described in
MIT's Open Courseware Software Engineering Laboratory to make initial planning more structured, and identify poorly thought out or disorganized development ideas from the start, as well as make it easier to make rapid changes to code either mid-development or after initial development.

[Ilja Preuss]

I would suggest to get a copy of Robert Martin's "Agile Software Development - Principles, Patterns, and Practices".
Taking a look at http://www.agilemodeling.com/ probably won't hurt, either...

[Ilja Preuss]

Originally posted by Rian Fergusson:
My primary reason for this is to completely define requirements.

For almost any project it is quite suboptimal to *completely* define the requirements before near the end of the project, for two reasons:
- people learn while working on a project. Customer and development team learn how to communicate more effectively (if you let them), the customer learns what he really needs (especially if he can use early versions of the system) etc.
- business environments change. Therefore, what the customer now needs is not what he will need when the project ends.
If you completely define the requirements too early in the project, the customer might get what asked for, but very likely not what he needs most.

During analysis if modeling is undertaken with a UML CASE tool without the intention of generating code then the modeling process seems less relevant in relation to the systems implementation, but provides a stagnate period of documentation.

Besides the fact that because of the reasons mentioned above analysis shouldn't ever end, the analysis model isn't good for generating code from.
That is because the analysis model describes the *problem*, but you want to get code for the *solution*. Often the structure of the problem and the structure of the solution don't have much in common. In fact there even exist concepts which only make sense in one of the models (e.g. inheritance).

example, if I am modeling using a UML CASE and I have a rough idea how I will design the system (which most designers have) and I have no intention of generating code, then the process of modeling is only a documentation task because if the model was complete then a skeleton code could be created (why wouldn�t you use a code generator if it will basically produced the same code that you will be forced to write).

Modeling is not a documentation activity. (You can use UML for documentation, but that's not modeling.)
The purpose of a model is to test a specific issue of the design. For example, you can model using UML to get a better feel for the dependencies in a proposed design, or to communicate an idea to your coworkers to see how they think about it.
Those models only need to communicate a very specific part of the design and are far from complete in the sense that you could generate code from it.

Moreover, modeling without the intention of generation will lead to undefined requirements because the actual code is not affected by the model.

I don't follow you here. I can capture requirements in a very complete and unambiguous way without resorting to UML, for example by using automated acceptance tests. I don't even understand how you'd "completely" capture requirements in UML at all.

If code generation does not occur your model doesn�t need to be complete (for system creation).

Yes, the model just needs to be complete enough for its specific purpose. I don't see how this would be a problem.

I bet if you compared a model which was not generated with a complete reengineered model of the same system there would be great differences, differences alot more noticeable than with a generated code skeleton.

One of those differences would be that the reengineered model would contain much more details and therefore is much less effective in communicating high level design ideas.
Other differences would probably be a result of finding better designs while coding the design.

Generated code when used properly will provide a framework for the whole system. A framework which fulfills requirements is a lot more difficult to modify than no framework,

But using code generation certainly isn't the only way to get such a "framework".

after all the framework will be basically perfect because design problems and requirements were nutted out in the pre-development stages

I don't think this can be true. Design problems are design problems because the present problems when being implemented. So only by implementing the design can you really know wether there are design problems. Reasoning about the design before implementing it is speculation, (possibly well-informed speculation, but still speculation).

[Patrick Nolan]

What I found is that ArgoUML is pretty much the only game (ie best) in town as far as open source / free UML tools go.... and unfortunately, it is very much in the beta phase. Like a previous poster said, pencil and paper are the best tools for diagramming .. but I think this really only applies when you are designing an architecture by yourself... If you need to communicate your architecture to outside consultants or to the rest of your internal team, it pays to have a commercial tool that can do the job well.
Patrick J. Nolan, Jr.

[Ilja Preuss]

Originally posted by Patrick Nolan:
If you need to communicate your architecture to outside consultants or to the rest of your internal team, it pays to have a commercial tool that can do the job well.

You mean like a whiteboard?
Seriously, I don't see how a UML program helps much in communicating in a team.

[Lasse Koskela]

Originally posted by Ilja Preuss:
Seriously, I don't see how a UML program helps much in communicating in a team.

I believe the idea is to communicate both ways with a UML model, which both can edit, instead of drawing from scratch every time.
However, this is not really about communication. It's about documentation and/or model-driven development, which is a whole different beast.

[Patrick Nolan]

I respecfully disagree I think UML diagrams are ALL (or at least mostly) about communication. What is one of the first things you do when you are asked to add features to an application with which you have no prior experience? I believe the first thing most of us would do is study the class diagrams and the sequence diagrams for that application. The diagrams are clearly a form of communication - the original developer is communication his design via UML to the rest of his/her team.
Patrick J. Nolan, Jr.

[Thomas Paul]

Originally posted by Ilja Preuss:
Seriously, I don't see how a UML program helps much in communicating in a team.

If your team is 3,000 miles (or even 300 miles) away, a white board isn't going to be much help. Also, writing code is very labor intensive and carries a much higher cost than doing design. When you are working with teams (especially teams who are inexperienced in good design) having a design tool like Rational is extremely helpful as it allows the designer to build a framework easily for the developers to use as a model. While the developers work on that, the designer can go on to other projects. This may not be relevant in your experience but it is extremely relevant in my experience. Ilja, you really need to get over the idea that Agile methodologies work in every environment. They don't.

[Thomas Paul]

Originally posted by Patrick Nolan:
I respecfully disagree I think UML diagrams are ALL (or at least mostly) about communication. What is one of the first things you do when you are asked to add features to an application with which you have no prior experience? I believe the first thing most of us would do is study the class diagrams and the sequence diagrams for that application. The diagrams are clearly a form of communication - the original developer is communication his design via UML to the rest of his/her team.

Yes, the person who said "the code is the documentation" should be taken out and shot. That is nothing but an excuse for not doing documentation. UML provides an easy way for programmers to get their arms around an application without trying to read code. But even more, UML provides a way for non-programmers to get their arms around an application.

[Thomas Paul]

To get back to the original question, there are tools that help to draw diagrams but there are no tools that replace Rational. It is an amazing and powerful tool.

[Thomas Paul]

Originally posted by Ilja Preuss:
I would suggest to get a copy of Robert Martin's "Agile Software Development - Principles, Patterns, and Practices".

I would suggest you get a copy of "Enterprise Java with UML" by CT Arrington.

[Ilja Preuss]

Originally posted by Patrick Nolan:
I think UML diagrams are ALL (or at least mostly) about communication.

I fully agree (though there obviously also is a movement to use UML as a programming language).
But that doesn't necessarily translate to UML modeling tools also being about communication. Those tools are typically rather restricting in several ways:
- They restrict you to the use of UML (or often even to a subset of UML!). Effective communication often involves some form of improvisation - combining two types of diagrams, using some custom notation etc.
- In a diagram, what not to show is often as important as what to show. A good diagram only shows a very specific aspect of the design and ignores the rest. The UML tools I know make it unfortunately hard to hide specific details.
- The best diagrams come into existence as an collaboration effort - at the white board, everyone can grab a pen and contribute. With a computer aided tool, most participants' ideas have to go through the "mouse proxy".

What is one of the first things you do when you are asked to add features to an application with which you have no prior experience? I believe the first thing most of us would do is study the class diagrams and the sequence diagrams for that application. The diagrams are clearly a form of communication - the original developer is communication his design via UML to the rest of his/her team.

Yes, of course. I would certainly like some high level diagrams (object-, collaboration- and state-diagrams might be helpful, too).
But I would also like *expressive* source code accompanied with extensive suites of acceptance- and unit tests. That's what "the code is the design" really means: not to take the existence of UML diagrams as an excuse to write sloppy code, but to take pains to make the code as expressive as possible to *minimize the need* of external documentation.
I have also heard of teams experimenting with indexed video tapes of design discussions and think that is a promising idea.
Pair Programming with someone already comfortable to the design would be my top-priority, though.

[Ilja Preuss]

Originally posted by Thomas Paul:
If your team is 3,000 miles (or even 300 miles) away, a white board isn't going to be much help.

Unless you have two electronic once interlinked and accompanied by a video conferencing system, possibly.
And Rational Rose is going to help much in which way? (Serious question - I don't have any idea how that would work.)

Also, writing code is very labor intensive and carries a much higher cost than doing design.

Writing code certainly isn't the only alternative to using a UML modeling tool, is it?
And, btw, I would actually write an extensive suite of acceptance tests.

When you are working with teams (especially teams who are inexperienced in good design) having a design tool like Rational is extremely helpful as it allows the designer to build a framework easily for the developers to use as a model. While the developers work on that, the designer can go on to other projects.

I'd think that it would be preferable to have unexperienced developers be guided by a living experienced person instead of (or in addition to) some cold diagrams - especially as I find that there is some vital feedback from the coding of a design that the people responsible for the design shouldn't miss.

Ilja, you really need to get over the idea that Agile methodologies work in every environment. They don't.

Agility is not about a family of methodologies. It's about a mind set. There are certainly environments in which it's hard to apply that mind set - but that's more a matter of culture than of needs.
Virtually every project out there could be more agile tomorrow than it is today, and it might be valueable to think about how to achieve that. Your mileage may vary, of course.

[HS Thomas]

A seasoned wood ( ) craftsman wouldn't draw diagrams for himself to take apart an old chair and put it together with a new design. It's in his head.
Whereas his customer may draw a diagram of the modifications he'd like to be made to the chair. The craftsman may draw modifications to that in turn to express a design idea to the customer.
I think that's what XP means by the code being enough documentation and I should think that's the skills a coder/designer needs to build.
Communication of larger parts of a design may only require demonstrations of tested code - which may be thrown away if it's decided the requirements are no longer needed. Better than reading endless documentation, IMHO.
There's a place for BDUF - capturing larger chunks of requirements into a rough design for communicating to agile developers.(?) The best thing that can happen to this rough design afterwards would be to throw it away and let the code speak for itself. If the code repeatedly gets thrown away one would have to question one's ability to capture requirements (or the coders skills ). Not many users read UML but they can interact with or test systems.
[ February 15, 2004: Message edited by: HS Thomas ]

[Thomas Paul]

Originally posted by HS Thomas:
A seasoned wood ( ) craftsman wouldn't draw diagrams for himself to take apart an old chair and put it together with a new design. It's in his head.

You have obviously never worked with a carpenter. What do you think he does for his apprentice?

[Thomas Paul]

And Rational Rose is going to help much in which way? (Serious question - I don't have any idea how that would work.)
Simple. The designs are done in rational by the designer working with the business analyst who passes them on to the development team. The design team can then review, add comments, make any changes that are required. it becomes an iterative process between the design team and the development team which in the end produces good dcumentation that can be used for the next development team that works on the application as well as the QA team that needs to build test scripts.
I'd think that it would be preferable to have unexperienced developers be guided by a living experienced person instead of (or in addition to) some cold diagrams - especially as I find that there is some vital feedback from the coding of a design that the people responsible for the design shouldn't miss.
It isn't always possible that the designers can interact with the developers easily. I have worked in many applications where this was the case. But UML can be used to pass design issues back and forth between the design team and the development team.
Agility is not about a family of methodologies. It's about a mind set. There are certainly environments in which it's hard to apply that mind set - but that's more a matter of culture than of needs.
I disagree strongly with this. There are many projects where agile methods will cause more trouble than they are worth. But as you say, your mileage will vary. I just think it is important to not fall into the trap of thinking that one methodology can solve every problem.

[HS Thomas]

Originally posted by Thomas Paul:
You have obviously never worked with a carpenter. What do you think he does for his apprentice?

A respected and successful craftsman would draw diagrams for his/her apprentices. But diagrams alone would not be enough to school the students in the craft. Ensuring they get the right experience helps , IMHO. And design is not a static activity but changes over time so it would be best to aim for a team that works closely in designing and developing rather than have an us- and them- 2 tiered team approach.
If you were shopping for a component would you want to look at the UML Diagrams of how it works or be given a trial version to check out and then buy ?
Environments are so fragile I cannot imagine a Big UML Diagram upfront would be of much benefit not even here USer story unfortunately.
Even for just practising UML which was the original intent of the question.

IBM's work with Rational XDE is part of a broader endeavor to fuse the IBM Rational XDE product family into IBM WebSphere Studio, Eclipse and Microsoft Visual Studio .NET. The goal is to bring design and testing closer together to encourage developers to model, develop and test applications in the same independent development environment to minimize errors and find bugs.

[ February 16, 2004: Message edited by: HS Thomas ]

[Ilja Preuss]

Originally posted by Thomas Paul:
And Rational Rose is going to help much in which way? (Serious question - I don't have any idea how that would work.)
Simple. The designs are done in rational by the designer working with the business analyst who passes them on to the development team. The design team can then review, add comments, make any changes that are required. it becomes an iterative process between the design team and the development team which in the end produces good dcumentation that can be used for the next development team that works on the application as well as the QA team that needs to build test scripts.

I am curious: how detailed will such a design be before you start to code it?

It isn't always possible that the designers can interact with the developers easily.

I can certainly believe that. But wouldn't it be almost always worth the effort to make the interaction as immediate and direct as possible?

I have worked in many applications where this was the case. But UML can be used to pass design issues back and forth between the design team and the development team.

Yes, of course. I certainly would use more UML in a distributed team than in a colocated one. What I am not sure about is how beneficial the use of *a tool like Rational Rose* really would be.

Agility is not about a family of methodologies. It's about a mind set. There are certainly environments in which it's hard to apply that mind set - but that's more a matter of culture than of needs.
I disagree strongly with this. There are many projects where agile methods will cause more trouble than they are worth.[/QB]

As I said above: Agility is not about methods - it's about the mind set.

[HS Thomas]

In the UK the following activity may become popular but developers will never get to see these models as it will be at a higher level of abstraction. Team Leaders may.
"This document describes the approach to modeling the project requirement adopted by projects that use Select Perspective. Leveraging UML as its core notation, Select Perspective extends the reach of UML by adding explicit support for Business Process Modeling (BPM) - an aid to achieving a shared understanding of the business context within which the solutions will operate . It also explicitly recognizes the different types of requirement that project teams have to take into account."
Select Business Modelling
[ February 16, 2004: Message edited by: HS Thomas ]

[Jeff Langr]

Interesting thread.
A carpenter would make a sketch on a napkin or on the back of a piece of plywood for his or her apprentice. They wouldn't use an expensive tool. The best carpenters I've worked with spend a few minutes producing an imperfect diagram on an 8-1/2 x 11 sheet of paper.
UML diagrams are very helpful for less experienced developers to understand the big picture and how things relate. And while more advanced developers/carpenters are able to understand more in their head about what is an appropriate design, they still can get feedback out of putting a design down on paper. Sometimes this feedback is quicker than the feedback from code.
I still recommend producing UML sketches in XP iteration planning meetings, as needed, to get everyone on the same page. Or when starting out a new task. I also recommend producing them at the end of a day or an iteration to communicate any significant design changes to the system. Yes, you can demonstrate these changes with the code, but often a quick sketch is more effective. And we're talking minutes here, not hours, days, or weeks of producing detailed design pictures.
Agile or not, UML is a tool for both communication and problem-solving. If it doesn't meet either of these needs, it's a waste of time. The point of agile is not to dismiss things like UML, it's to recognize how to use such tools effectively instead of reflexively. Detailing the entire system up-front in UML is rarely effective.
Back to the original question: A tool such as Visio is just fine for recording UML, if you need to do that. A tool like Together is just fine for showing you a snapshot of your existing system, if you need to do that. And perhaps someday Rational XDE will let you build everything in UML, in which case UML becomes the programming language and we can get rid of the Java guys. It's not anytime soon, as the MDA proponents would like to believe.
-Jeff-
[ February 16, 2004: Message edited by: Jeff Langr ]

[HS Thomas]

I believe the Eclipse Modeling Framework EMF is based on a model driven architecture. I'm not sure how that puts Java guys out of a job ? IBM's pool of Java developers must have increased simultaneously. And the number of plug-ins keep growing.
Horses for courses, I'd say.
[ February 16, 2004: Message edited by: HS Thomas ]

[Jeff Langr]

Originally posted by HS Thomas:
I believe the Eclipse Modeling Framework EMF is based on a model driven architecture. I'm not sure how that puts Java guys out of a job ? IBM's pool of Java developers must have increased simultaneously. And the number of plug-ins keep growing.
Horses for courses, I'd say.

Exactly.
-j-

[Ilja Preuss]

Originally posted by Jeff Langr:
I still recommend producing UML sketches in XP iteration planning meetings, as needed, to get everyone on the same page. Or when starting out a new task. I also recommend producing them at the end of a day or an iteration to communicate any significant design changes to the system. Yes, you can demonstrate these changes with the code, but often a quick sketch is more effective. And we're talking minutes here, not hours, days, or weeks of producing detailed design pictures.

Correct! Though I think you also need to take the personality tpyes inside the team into account - diagrams are not equally effective for everyone.
I actually very much like to draw some UML diagrams in a design discussion. (Though it has the big drawback that it makes it awfully visible how ineffective some of my ideas are when it comes down to actually coding them... )
I do have a coworker, though, who has problems connecting the diagrams to code. She is a quite good developer, with an incredible overview over the system - there are just more effective ways to communicate to her than diagrams.
As you said - horses for courses...

[Thomas Paul]

A carpenter would make a sketch on a napkin or on the back of a piece of plywood for his or her apprentice. They wouldn't use an expensive tool. The best carpenters I've worked with spend a few minutes producing an imperfect diagram on an 8-1/2 x 11 sheet of paper.
I wouldn't eant that carpenter working on my home. The carpenter that did tghe work on my house had a complete set of blueprints that showed where every single piece of wood he would use as going. He knew exactly how many pieces of wood and what size he needed before he started working. the plans were shown to plumbers and electricians who added their own expertise to the plan. It was also show to county officials who reviewed the plans to make sure they met our local codes. If they did all that for a small expansion to my house how could you let programmers do any less for a project that will be costing ten times what I paid for my expansion?
UML diagrams are very helpful for less experienced developers to understand the big picture and how things relate.
UML diagrams are very helpful for experienced people to review to figure out what an application does and how it does it. perhaps you haven't been in the unenviable position of taking over an application when the origianl developers were not available but if you were then you would have been very happy to find that they had provided you with a complete set of UML diagrams showing how the application worked. To take it back to the house analogy, imagine having to do work in an office building with no plans to tell you where the wiring was or how the plumbing ran through the building. You would have to punch holes in walls just to try to locate where anything was.
Agile or not, UML is a tool for both communication and problem-solving. If it doesn't meet either of these needs, it's a waste of time.
Not to the developers who follow in your footstep. UML makes much better documentation than code. As I said, the fool who said, "the code is the documentation" shoudl be forced to make business critical enhancements to an application with 2,000 Java classes and no documentation.
Back to the original question: A tool such as Visio is just fine for recording UML, if you need to do that.
The problem with a tool like Visio is that the diagrams have no intrinsic relationship. In Rational diagrams are tied together. Double click on a class diagram and you can see the sequence diagrams that this class participates in. One diagram can be used to generate other diagrams. Change one diagram and that change will refactor all the digrams it is related to.

[Thomas Paul]

Originally posted by Ilja Preuss:
I am curious: how detailed will such a design be before you start to code it?

I like to take it to sequence diagrams because the developers can clearly see what their classes are expected to do and how they interact with other classes. I have found that even inexperienced developers can produce good quality code very rapidly from sequence diagrams.
To give an example of UML as documentation... don't you think it would be a lot easier to work with MVNforum if we had class diagrams and sequence diagrams for the entire application?

[Lasse Koskela]

Originally posted by Thomas Paul:
Not to the developers who follow in your footstep. UML makes much better documentation than code. As I said, the fool who said, "the code is the documentation" shoudl be forced to make business critical enhancements to an application with 2,000 Java classes and no documentation.

I have been part of a project which inherited a huge piece of crappy, undocumented code, with no UML diagrams. Honestly, I would've preferred a reasonable set of unit tests over any UML diagrams the original developers could've drawn. Why? Because I could find my way through the package structure (10000 files, most of it Java code) without UML, but changing anything was close to a death wish... If the code is crappy, the UML diagrams probably won't be any better.

[HS Thomas]

It would seem with UML there are several levels of indirection.
Thomas, was the carpenter from a pre-built pre-fab way of working ? Some carpenters are trained to work with only pieces A,D and E and wouldn't know how to cope with a modification to the original design. Not exactly an artisan but still a good way of working.
Not everyone will be able to afford Rational, not everyone who can afford it would use it wisely, IMHO. I haven't had the privilege of trying it but would expect that only those who know how to use it effectively should be allowed to.
For the rest us, much more mileage with paper and pencil. Not to mention fun.
The tip on being able to code from sequence diagrams is interesting.I'm beginning to lean towards expecting to see both Thomas' and Illja's/Jeff's/Lasse's approaches in place, if it's possible. The ability to be agile to meet requirements would be paramount in whichever process.
[ February 17, 2004: Message edited by: HS Thomas ]

[Thomas Paul]

Originally posted by HS Thomas:
Not everyone will be able to afford Rational, not everyone who can afford it would use it wisely, IMHO. I haven't had the privilege of trying it but would expect that only those who know how to use it effectively should be allowed to.

Rational is a powerful tool and is not meant to be used by someone just fooling around with it anymore than you would allow someone to code your payroll application after fooling around with Java for a weekend. Rational is an architect's tool. It is meant to make the design process easier which allows the development process to go smoother with no surprises. The applications I developed with Rational were on-time and on-budget because we knew exactly what we were developing before we wrote a line of code.

[Thomas Paul]

Originally posted by Lasse Koskela:
I have been part of a project which inherited a huge piece of crappy, undocumented code, with no UML diagrams. Honestly, I would've preferred a reasonable set of unit tests over any UML diagrams the original developers could've drawn.

I inherited a huge, well-written application with no documentation. Unit tests were useless because trying to figure out the flow between several thousand classes was nearly impossible. I spent a week grepping through scores of directories to figure out what a single change would do to the application (and I inherited a backlog of changes that the previous developers hadn't been able to do). We documented the application with UML and the resulting diagrams made it easy to figure out the implications of any change. Fortunately Rational has a reverse engineering tool.

[HS Thomas]

Using Rational would be practice of a perfect craft up a notch while XP allows for inexperienced developers to perfect their craft. Rational should not be used to continuously override developers design changes ; that would suggest severe lack of communication. Writing test firsts is always good practice and ensures robust design and testing assurance.
Features you can do with Rational would have more value in Business Proces s Modelling and Architecture and probably determining the impact of devations of the built software from the business model.
Not that useful once a system gets really big ; tests are relied on much more. Viva los testers !
After which I imagine Rational would only be useful for Business Process Modelling.
Those licences must be paid for after all.
I wish I could use it just for one season , though.
[ February 17, 2004: Message edited by: HS Thomas ]

[Lasse Koskela]

Originally posted by Thomas Paul:
I spent a week grepping through scores of directories to figure out what a single change would do to the application (and I inherited a backlog of changes that the previous developers hadn't been able to do).

One of the benefits of having a good coverage of unit tests is that you could've simply made a change, ran the tests, and witnessed where the damn thing broke. Obviously it's not that black and white, but nevertheless it's a valuable ability to have in that kind of hell-hole projects.

Originally posted by Thomas Paul:
We documented the application with UML and the resulting diagrams made it easy to figure out the implications of any change. Fortunately Rational has a reverse engineering tool.

If the codebase was thousands of classes, how long did it take for you to clean up those reverse engineered spider webs? I am constantly amazed at how poorly all reverse engineering tools I've tried have performed in terms of intelligent diagram layout.

[Michal Harezlak]

Originally posted by Jim Henessey:
Hello,
[...] Does anyone here have recommendations for a professional caliber UML editor that they've worked with which is either inexpensive or free/open source?
Much appreciated.

Jim,
I was trying to get a discussion on that issue at IDE forum:
https://coderanch.com/t/102505/vc/Meta-Mill-answer
Unfortunately, no luck. Perhaps my thoughts will be helpful for you.
Best regards.