Fog Creek Software
Discussion Board




The case against CASE?

CASE tools like Rational Rose have been around for some time, the intention being to improve the overall quality of software.

But how many of you guys actually use all 9 of them? class, package, object, use case, sequence, colloboration, state chart, activity, component and deployment diagrams?

Personally I feel that UML is overly-hyped, the only revenue-generating output from a software company is the code. Not diagrams and stuff.

I do use diagrams but not to the point of following the entire UML spec. Opinions?

The link below follows the discussion further.
www.advogato.org/article/635.html

Wei
Monday, April 14, 2003

Wei wrote, "CASE tools like Rational Rose have been around for some time, the intention being to improve the overall quality of software."

Perhaps, but the #1 reason companies buy CASE tools such as Rational Rose is so they can reverse-engineer human written code.

Wei wrote, "But how many of you guys actually use all 9 of them? class, package, object, use case, sequence, colloboration, state chart, activity, component and deployment diagrams?"

I don't work on large enterprise software projects, however, I have attended a few presentations where the speaker has said he has used many of them to build products like an auction website. Most people seem to only use a couple of diagrams. I believe it pretty much comes down to personal preference or company policy. Activity diagrams (similar to flowcharts) probably aren't all that popular, however, I think they would be useful if your company requires your project team to conduct code inspection meetings.

Wei wrote, "Personally I feel that UML is overly-hyped, the only revenue-generating output from a software company is the code. Not diagrams and stuff."

Words like overly-hyped or useless are a matter of perspective. If you have never been required to create a UML diagram or your company doesn't need/use them -- then from this perspective UML is overly-hyped.  If you are trying to build a repository of business objects that can be used throughout the company or you are required to work with others on a large software system design (i.e. several people are designing a system at the same time) you might feel differently.

I don't know for certain, but I doubt that UML is used very much within many software companies.

The value of UML diagrams is that they can be used in various ways (documentation, communication tool, quicker comprehension of the big picture, code generation, etc.). Supposedly Rational XDE (haven't tried this product myself) is supposed to be able to do a pretty good job at roundtrip engineering (i.e. create source code from certain UML diagrams and create diagrams from source code).

CASE tools were the "hot thing" in the mid 1990s. Many large corporations purchased them with the expectation/hope that they would be able to get rid of some of their programmers. IMO, CASE tools really aren't that popular right now because among other reasons the good ones cost a lot of money and it takes time to learn how to use one.

One Programmer's Opinion
Tuesday, April 15, 2003

Or perhaps there's just no such thing as a good CASE tool? :p

And the horse you rode in on
Tuesday, April 15, 2003

CASE tools help us organize information - some do that quite well.

But so far none of the tools I used, including Rose, were good enough at keeping model and code properly in sync (ie roundtrip).

With that in mind, I use CASE tools only for what they are really good at: helping me organize specifications, use cases, go through robustness analysis and sequencing and ending up with a high level system structure.

Cheers
Dino

Dino
Tuesday, April 15, 2003

Dino - have you tried Together (www.togethersoft.com I think)? It seems to come closer than Rose to what you want, though IMO it is still not perfect. In fact I don't think there will be a perfect one for me unless either it incorporates the IDE or the IDE incorporates the design tool, otherwise when using one you lose the features of the other, and probably some binding between diagrams and code as well).


Tuesday, April 15, 2003

No, never tried Together. Anyways, at some point I gave up the idea of roundtripping out of UML diagrams mainly because the gap between UML and actual code is way too large.

I mean what we call models in reality are not true models since they cannot predict anything, nor prove or disprove the completeness or consistency of a design against its set of requirements. Maybe UML is too simplistic? Or maybe UML simply doesn't address consistency and completeness type of problems? I don't know ...

All I can say is that UML fails to enforce consistency to class models. Instead Design Patterns (Gamma & Co) resolve a bit of the above issue, but then wouldn't a pattern based language work better? Again, I don't know ...

The bottom line is that the only proof that a system works is in the running code.

Therefore I dropped the roundtrip idea and I just work on specifications, use case, design,  using CASE tools, but then I get to write the actual code using the models/specs as a guideline and checking through a review process that the code & specs agree.

Cheers
Dino

Dino
Tuesday, April 15, 2003

The only way roundtrip can be perfect is if UML becomes a complete programming language in its own right ... which is a self defeating exercise, because the point is supposed to be that UML is documentation not code.

Therefore it can never be perfect.

And the horse you rode in on
Tuesday, April 15, 2003

"The only way roundtrip can be perfect is if UML becomes a complete programming language in its own right ... which is a self defeating exercise, because the point is supposed to be that UML is documentation not code"

UML may be documentation to you, but to me (and I suspect to Dino) it is a means of going from requirements to implementation. It may serve as documentation afterwards, but only if it describes what the implementation really is and not what it was intended to be (hence Dino's complaint that he can't find anything that does "roundtrip" engineering with UML). He is therefore absolutely correct in saying that the only documentation which makes any sense is the code itself

This is perfectly okay as long as nobody expects to see more abstract (whoops, there's that word again!) views of the system. At the present time UML leaks.


Tuesday, April 15, 2003

> Personally I feel that UML is overly-hyped,
> the only revenue-generating output from
> a software company is the code. Not
> diagrams and stuff.

Good developers can create a good OO or procedural design for their program, and they can do this with, or without UML.

UML is useful like a common language: developer A may be brilliant, and may have had thought of an excellent design, but he needs to communicate it to developer B.

If everybody understands and writes UML, this communication is faster and more efficient.

Mathematicians have a notation that is fairly standard. Developers have UML.

George Nicolescu
Tuesday, April 15, 2003

It's not documentation to me, I think it's a complete waste of time. :)

Some people feel it's documentation though ...

And the horse you rode in on
Tuesday, April 15, 2003

<< Mathematicians have a notation that is fairly standard. Developers have UML. >>

Developers have code.

The mathematical notation is well defined semantically, which is also true of code, but not of (say) UML diagrams.

The standard differences in math are more or less equivalent to standard differences between programming languages, in the sense that the difference is mostly syntax, but the underlying principles are equivalent (turing equivalent, in the case of code).

UML is so horribly underspecified (semantically) that I find it hard to use as a requirement/specification tool. You still need all the accompanying semantic definitions, so UML is, at most, of some help in giving a broad overview.

In the end, it is only the code that matters; So write code, and use your favourite reverse engineering tool to draw the diagrams for you, be it Rose, Together or (my favourite) Doxygen. And add diagrams and semantic documentation that helps gives the entire picture.

[slightly offtopic - With "Go to", we had spaghetti code which Dijkstra's influencial "Goto considered harmful" paper eventually helped eradicate.  Now, we have class spaghetti which is even more of a problem, but all modern methodologies and CASE tools actually encourage it. ]

For me, until better _semantic_ models come along, it's "CASE dismissed".

He-who-would-not-be-named
Wednesday, April 16, 2003

"In the end, it is only the code that matters; So write code, and use your favourite reverse engineering tool to draw the diagrams for you ….. And add diagrams and semantic documentation that helps gives the entire picture."

Been there, done that. However writing code first is not always possible nor advisable. There's always a preparation step required ahead of coding - design?

For large systems a CASE tool comes in handy same way a RDB helps us store large amounts of related data - ie helps us organize large amounts of spec and design info. 

Concretely, here's a page of my life:
1) interview knowledgeable business person (but technically incompetent) for 2-3 months, 1 week at a time.  End up with 200 pages of specifications full of inconsistent terminology and with an ambiguous process flow.
2) based on the specs write the use cases. Try and sequence the use cases while determining the actors and entity classes, states, etc. Figure out what's missing and ask questions (ie go back to 1).
3) check the use cases and make sure the process flow works as it supposed to. If not go back to 2.
4) run through the robustness analysis. Add control classes and view classes to the model. See if the use cases still hold. If not back to 2)
5) All in place and working, finally check on the packaging and dependencies. Solve all the packaging problems (loops in the dependencies, lack of abstractedness or instability problems, ...)
6) Finally release the model as a spec for the developer and move on ... (dev process, schedule, priorities, task allocation and finally writing some code ...)

Life could not be any easier ...

Anyway here is the balance sheet:
200-300 pages of reasonable specifications
10 actors defining roles in the system
100-200 use cases covering all the bus. req.
200-300 entities (ie 200 tables in a db)
60-70 controllers (future facades in the system)
500-600 views (future screens or screen components)
unknown number of helper, dao, value objects classes etc
=============
8 months x 2 people = 16 mm

Rose helped us reasonably well control and organize all this wealth of information.

Cheers
Dino

Dino
Wednesday, April 16, 2003

I always though UML was a way of codifing existing processes. A way of standardizing what was already going on.

Of course, then it grew into something a little too specific for most people. Just because UML exists doesn't mean you have to use all of it, or all of any aspect of it, such as use case. Take what works & throw the rest away.

Of course, that's difficult in a large company when developing a "what works" is often a difficult process becuase the environment is so much more beaurocratic and artificial than smaller development houses.

www.marktaw.com
Wednesday, April 16, 2003

*  Recent Topics

*  Fog Creek Home