Rational Rose alternatives

[Jeff Langr]

Originally posted by Thomas Paul:
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.

Documentation == communication, does it not? If it's documentation that people actually read and trust, it meets this goal.
The reverse problem is also true: there are many fools who invested a lot of time doing UML and paid little attention to the construction. Given the choice, well-crafted code with a poorly documented design is a much better legacy than the opposite. Most people, unfortunately, come across systems with neither good design nor good code.
-Jeff-
[ February 17, 2004: Message edited by: Jeff Langr ]

[Jeff Langr]

Originally posted by 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.

Note that I said "for his or her apprentice," the point being that carpenters teaching and imparting design ideas to other team members can work in a more informal medium.
-Jeff-
[ February 17, 2004: Message edited by: Jeff Langr ]

[HS Thomas]

Even with Business Process Modelling (using UML extensions) someone will still be writing Integration Tests , User Acceptance Tests. If accepting work that has no documentation there should be integration and acceptance tests to go with it, IMHO. Or get the testers to write those tests first and run code against the tests. Just a thought.
[ February 17, 2004: Message edited by: HS Thomas ]

[Jeff Langr]

Originally posted by Thomas Paul:
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.

I never suggested that UML diagrams were not useful for reviewing an application.
I have been in your unenviable position of taking over such systems, many times. Nine times out of 10, the UML diagrams were out of date or inadequate. Nine times out of 10, it wouldn't have mattered, because the poor construction of the code was where the real money ended up being wasted.
The best answers we got on such systems came from people who understood the design (and why it was the way it was--something you don't get from UML diagrams themselves) and were able to step through it for us.
UML diagrams also did prove useful; however, the ones that did were not intricately detailed. A couple key sequence diagrams representing the more complex scenarios, a big picture class diagram, a prudent state diagram, for example, were all we generally needed.
-Jeff-
[ February 17, 2004: Message edited by: Jeff Langr ]

[Jeff Langr]

Originally posted by Thomas Paul:
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.

Not necessarily. I've also been in the situation where there were reams of finely detailed, intricate documentation. The overwhelming volume made things about as difficult to understand had there been none. (Particularly since, as almost always, the question of what could be trusted vs what was out of date came into play.) Once again, finding someone who could step us through the pertinent stuff was what actually worked.
As with good software abstraction, good documentation is about being prudent with the things you want to represent. "Abstraction is the elimination of the irrelevant and the amplification of the essential." -R. Martin
-Jeff-

[Thomas Paul]

Originally posted by Jeff Langr:
Most people, unfortunately, come across systems with neither good design nor good code.

That is a different problem altogether and speaks to the general level of unprofessionalism that runs through our industry.

[Thomas Paul]

Originally posted by Jeff Langr:
Nine times out of 10, the UML diagrams were out of date or inadequate. Nine times out of 10, it wouldn't have mattered, because the poor construction of the code was where the real money ended up being wasted.

This is where the unprofessionalism of our industry exposes itself. Too many applications are developed late and over budget. Although you will always hear programmers complaining about changing specs, or unclear specs, or a million other issues, the fact is that at least 50% of failed applications are due to the IT department.
Programmers hate doing documentation so when someone tells you not to worry about it because the documentation is always out of date, they are feeding the worst behaviors of the IT department. Imagine a builder realizing that there was a problem with an architect's plan and just doing things a different way without going back to the architect for the changes.

[Thomas Paul]

I just want to add one thing that seems to cause some confusion about rational. Rational is not a UML tool. Rational is a design tool that uses UML as the language of design. The difference between Rational and Visio is like the difference between an IDE like Eclipse and notepad.

[HS Thomas]

I'm intrigued. Any chance of / links to some snapshots of what is ? Patterns ?
Anyway downloading a trial version.
[ February 17, 2004: Message edited by: HS Thomas ]

[Jeff Langr]

Originally posted by Thomas Paul:
I just want to add one thing that seems to cause some confusion about rational. Rational is not a UML tool. Rational is a design tool that uses UML as the language of design. The difference between Rational and Visio is like the difference between an IDE like Eclipse and notepad.

The OP was interested in a low-end UML "editor." They weren't clear on what the intended use was.
-j-

[Lasse Koskela]

Originally posted by Thomas Paul:
Although you will always hear programmers complaining about changing specs, or unclear specs, or a million other issues, the fact is that at least 50% of failed applications are due to the IT department.

It depends on what you mean by failing? The legendary CHAOS report from Standish Group (1995) listed a top 10 list of project challenging factors... The vast majority was related to changing requirements, lack of requirements, deficiencies in requirements, and lack of communication.

[Jeff Langr]

Originally posted by Thomas Paul:
This is where the unprofessionalism of our industry exposes itself. Too many applications are developed late and over budget. Although you will always hear programmers complaining about changing specs, or unclear specs, or a million other issues, the fact is that at least 50% of failed applications are due to the IT department.

I don't think you can come up with the numbers to back that fact, but I'll agree that 50% doesn't seem like an outrageous claim.

Programmers hate doing documentation so when someone tells you not to worry about it because the documentation is always out of date, they are feeding the worst behaviors of the IT department. Imagine a builder realizing that there was a problem with an architect's plan and just doing things a different way without going back to the architect for the changes.

Just for the record, I've never said "don't do documentation."
One reason documentation gets out of date is related to my earlier posting--most developers don't understand where to best expend their efforts. Prudence.
Re: the continuing builder analogy, builders make small scale changes all the time on houses without going back to the architectural diagram. In any case, the software construction to building construction analogy is weak for so many reasons.
-Jeff-

[Thomas Paul]

Originally posted by Lasse Koskela:
It depends on what you mean by failing? The legendary CHAOS report from Standish Group (1995) listed a top 10 list of project challenging factors... The vast majority was related to changing requirements, lack of requirements, deficiencies in requirements, and lack of communication.

I see all those things as IT failures. It is up to IT to manage change. It is up to IT to facilitate communication. It is up to IT to insure that requirements are understood before committing to work. I have seen plenty of projects with "scope creep" where the fault was that IT didn't understand the scope before they started and failed to have a change control mechanism in place.

[Ilja Preuss]

Originally posted by Thomas Paul:
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?

You could because - when using the appropriate techniques - software is much easier to change than hardware.

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.

I did take over an application from one of our customers after they discontinuoued the contract with the original development company. The code is crap, and I wouldn't trust any diagram the original developers had provided. We are currently working on writing system tests for the critical functionality, so that we know when we break something. Eclipses browsing, search and refactoring capabilities are also a great help.
Meanwhile I have a rough picture of some parts of the design in my head, and I would probably draw some high level diagrams when explaining it to a coworker.

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.

Imagine you had some X-Ray glasses too look through the walls. Also imagine you could half the profile of all the wiring in the house by just changing the value of a constant. Imagine after doing that, you could press a button and see wether the new wiring holds out against all the inhabitants using all their electrical devices at the same time. Imagine after the house being burnt down by the test, you could simply restore the initial state of the house at virtually no cost.
With Software, you don't have to imagine - you can learn to do it. And it isn't any magic involved...

Not to the developers who follow in your footstep. UML makes much better documentation than code.

UML makes a good complement to code - especially for the high level overview, and for some critical details which are hard to express in code.
But in my experience, code *can* be made quite expressive regarding the details of the design.

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.

Well, I am working on such an application. The sytesm is more than five years under development and has remarkably improved in both the internal design and stability and functionality in the last year.

[Ilja Preuss]

Originally posted by Thomas Paul:
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?

I don't know, I didn't follow the MVNforum development discussions closely. What problems did you face?

[Ilja Preuss]

Originally posted by Thomas Paul:
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.

We really live in different worlds. I typically don't even fully know what functionality our customers will request two weeks from now.

[Ilja Preuss]

Originally posted by Thomas Paul:
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.

Why was it nearly impossible, though it was well-written? Can you tell more about it?

I spent a week grepping through scores of directories

Ouch - you really did *grep*? What about using a decent class browser?

to figure out what a single change would do to the application

So I gather you didn't have an extensive suite of acceptance tests? (I guess otherwise you could just have been running those after making the change?)

We documented the application with UML and the resulting diagrams made it easy to figure out the implications of any change.

You might be interested in taking a look at SmallWorlds (reviewed in the Toolshed). It has a "what if" view, where you can click on a class and get a web of classes which may be affected by a change to the original one. I am not sure how well that really works, though.

Fortunately Rational has a reverse engineering tool.

I am curious - how much of the above mentioned UML documentation was automatically generated and how much did you have to customize it?
Thanks!

[Ilja Preuss]

Originally posted by Thomas Paul:
Too many applications are developed late and over budget. Although you will always hear programmers complaining about changing specs, or unclear specs, or a million other issues, the fact is that at least 50% of failed applications are due to the IT department.

I agree that not being able to handle unclear or changing specs appropriately is an IT problem.
I am not sure that being late or over budget *inherently* is something to be avoided, though. Providing the customer with maximum value at the end of the project seems to be more important to me than meeting the goals set at the start of the project.

Programmers hate doing documentation so when someone tells you not to worry about it because the documentation is always out of date, they are feeding the worst behaviors of the IT department.

But that's actually *not* what's being said.
What is being advised is "because external documentation so easily gets out of date, try to make as much of it unnecessary as possible, by putting the information into a more reliable medium." Does that sound like a bad advice to you?

[Ilja Preuss]

Originally posted by Thomas Paul:
It is up to IT to manage change. It is up to IT to facilitate communication. It is up to IT to insure that requirements are understood before committing to work. I have seen plenty of projects with "scope creep" where the fault was that IT didn't understand the scope before they started and failed to have a change control mechanism in place.

I fully agree!

[frank davis]

Originally posted by Thomas Paul:
This is where the unprofessionalism of our industry exposes itself. Too many applications are developed late and over budget.

Oh really. I've seen where upper management or marketing picks some date by which a project must be done based on deals they've just signed or some strategic decisions. I've seen it done where they do not consult the IT dept for a realistic time frame. So, naturally the project is late, it gets chalked up as another statistic and tabulated by the authors of project managemnt books as yet another example of how bad things are in the IT field and this in turn is echoed in disussion boards around the internet.
In not every case does Management not consider IT when demanding a deadline, but even those cases where it does, pressure is still exerted to come up with deadlines that are not simply highly likely to succeed even with the best of professionalism.
Then there is the uncertaintity principle. Software can involve doing things that have not been done before. For non-trivial software it is simply not possible to know even with high degree of certaintity how long it will take. Especially if you are developing a new product with new functionality not seen in the marketplace, there may be no precedent by which to estimate time to completion. And for some depts and IT teams, almost every project may be "new" to them and they will not be able to estimate completion times, but not because they are unprofesional.
The truth is that time estimates are only slighlty better than pure guesstimates at best, and in the real world the pressure to get things done causes those guesstimates to lean towards the slighlty too optimistic side. The result is that an entire industry is unjustifiable slandered because of an impossible task of accurately predicting completion times.

[Andrew Och]

Dear Jim
I use Dia or rather Dia-Gnome to create class diagrams and use case diagrams. I am sure it has nowhere near the functionality of Rational Rose, but it doesnt take an age to startup and its Free Software, so perhaps it is another package to consider.
Best regards
Andrew