What is the case against CASE

In my humble experience, CASE tools seem to a marker for project doom. In theory, I kind of like the idea, but in practice it mostly seems to be about CASE tools companies selling ill-fitting tools to PHB's, who then foist them on us programmers. I've been on a (doomed) project before where I was told "We spent $100K on these tools that will write 90% of the code. You just have to fill in the other 10%." Uh huh. Doomed.

Even Rational Rose is available on linux: http://www.rational.com/tryit/rose/index.jsp
Also there is an OpenSource approach to CASE tools: http://uml.sourceforge.net/index.php
This may not be as powerfull as Rational Rose, but there is no case against CASE in OpenSource.

Personally I prefer to do the documentation of my projects using doxygen. For me this is much more handy. Especially when you want to document class libraries. I sometimes draw UML diagrams. But this is not really using CASE tools. I don't like the comments that go into my sourcecode when I use a CASE tools (especially Rational Rose). And I don't want to do the routing of my class diagrams by hand. With doxygen this is done automatically.

No one prevents you from using them. Beside the mentioned Umbrello there is also the Java-based ArguUMLM. But I don't use them either, and don't know any projects that use them. Why?

• IMHO they don't scale very well. They are cute for 5 classes, but if you have 25 and they don't fit on you screen anymore things get very uncomfortable. I think it becomes easier to read and browse the class headers in text files then.
• Usually there are two kinds of developments in OpenSource projects. Either a single contributor designs and writes larger chunk alone, or several contributors use a evolutionary process by submitting many tiny patches. I think that the best use case for UML tools is when several people are designing a project together, but this happens almost never in OSS. And for the tiny-patches approach UML is very bad: you can't distribute patches of a graph, and systems like CVS usually can't merge the files of the CASE tools. Also, people judge contributions based on the code. Who cares about a good design when nobody implements it? There are far too many things that have never been finished.
• I design most code in my head, usually at place that it is not suitable for a UML editor (like under the shower :). And as long as I don't have to show the design to other people before I implement it, it is much more efficient that way.

Writing a good CASE tool is Hard. As such, the good ones tend to cost a lot of money. I imagine most free software developers either can't afford these tools, or want to keep their projects accessible to other developers who might not be able to afford them.

The free/open source CASE tools I've tried tend not to be very good. Some folks can apparently tolerate ArgoUML's quirks, but I can't. Dachshund strikes me as a very promising project; but its development seems to move in fits and starts and it still has a ways to go before it is usable. I haven't tried Umbrello, but I'm about to.

I think the most useful thing a CASE tool can do is to be able to reverse-engineer human-written code. And that's very hard to do. I don't care if a tool can generate code if it can't read the code back into a model once I've manually modified the code. So in the absence of that functionality, a CASE tool is only good for it's diagramming capabilities. And I can get that from Dia.

That's the primary reason. Those tools are usually targeted at the imbecile "developer" crowd out there who think those tools really write the code for them.

While graphical interfaces are certainly useful, I believe in no such thing as a CASE tool. Unless of course you can come up with a graphical programming language.

C++ isn't a graphical programming language for instance.

Tools that visualize code are useful things, but there is no such thing as a design process in which you first use some dumb CASE tool, and then go and fill in the blanks. That could only be useful for a novice programmer candidate who does not even know the difference between interface and implementation. Granted, 90% of all "programmers" are at that level, so maybe this might be useful to force them to think for a few jiffies before dumping their stupidity in ASCII. Things like special purpose code generators, UI designers, etc. will be used and have their scope but there it is an illusion produced by incompetent and fake "Software Engineering" people who wouldn't be able to understand the slightest bit of CS theory. Writing the signatures of functions IS NOT THE SAME GODDAMN THING as coding.

Please show me how to design a recursive algorithm using those CASE tools. Those are for algorithm-devoid, data copying, microsoft drones. I hate people who try to enforce those tools that much.

In a "doomed project" I was in, we were forced to come up with design documents making extensive use of UML diagrams. The guy who was a C programmer came up with two classes SomethingViewer and Dosomething that had like 40 functions each. He didn't have a clue about OO, and as demonstrated these tools cannot teach anybody OOD.

exa angry and out

CASE tools are just a bad idea, if your job is writing code.

This is a subset of the "Software Engineering is just a bad idea" problem, which I have talked about elsewhere, but it's a highly visible one. Huge numbers of (usually failed) projects have wasted hundreds of billions of dollars on CASE tools and the consulting that comes with them.

While I don't want to get too far into the problems with Software Engineering, there is a great deal of confusion as to the purpose of it. In Software Craftsmanship, Pete McBreen points out that the field of Software Engineering was born to deal with massive software projects with huge budgets and very serious consequences for failure. SE is about spending years of time and billions of dollars to eradicate the last 1% of error from your code.

Whether it does this well is a separate question, but if SE, and by extension CASE, were to meet these kinds of goals, would you and your organization's goals be met?

If you look at the proposed benefits of any CASE tool, you'll be surprised what the marketing spin is actually saying. Let's take a look at a snippet of The Rational Edge, a part of Rational's marketing materials touting their CASE products.

Usually, an organization at Level Four will develop an explicit traceability strategy prior to starting a project and then document it in the requirements management plan. The strategy will define the requirements levels and how they fit in the hierarchy. In addition, it will lay down some "rules" for requirements relationships. For example, one rule might be that for every "user need" there must at least be one "feature," and for each feature there must be at least one use case. Implementing a requirements management process like this sets up capability for sophisticated reporting [...]

Does your open source project have a Requirements Management Plan? A Traceability Strategy? A hierarchy of requirements levels? "rules" for requirements relationships? I'm willing to bet that it doesn't, for one good reason:

None of those things produce code.

In a large organization, where you have a lot of resources to manage, it's really more important just to make sure you're not completely wasting a resource than to capitalize on each resource with maximal efficiency. In the Free/Open Source community, we don't have to worry about people goofing off and not doing work, because if they do that they're effectively not a resource to be utilized anyway. People only join these projects voluntarily, so we're much more concerned with getting the most code/documentation/artwork out of a particular contributor than trying to make absolutely sure that none of our contributors are sitting idle.

Of course, in my opinion, there's something wrongheaded about trying to marshal collossal teams to produce huge, huge pieces of software and then trying to mitigate the technical problems that crop up with layers of management and procedure. This (along with the high cost, I'm sure) is why most F/OSS hackers don't just ignore CASE tools, but actively disdain them. If you don't have a requirements management plan and a feature request routing procedure, why do you need software to manage that kind of process?

Most of us would prefer to deal with organizational and structural issues the way we know best: with technology. Not just a fancier whiteboard with built-in memo capabilities, but genuine technological solutions. Rather than write an elaborate assembler calling conventions document and circulate it for approval, we write high-level languages like Perl and Python. Rather than archive every idea as a diagram, divorced from a "live" project, we merely encourage people submitting feature requests to accompany them with patches that implement a prototype of their feature.

Various Extreme Programming case studies show that similar ideas work in a larger corporate environment, and the emphasis that Software Engineering places on management of resources may be completely misguided even for large corporate users. I don't think this debate is entirely settled (and it isn't usually framed this way), but there are lots of reasons not to use CASE tools in any environment, especially one whose goals are, as with the F/OSS community, almost entirely technical.

These CASE tools never, ever integrate with debuggers. If they were truly graphical programming languages (and you could achieve "100% generation" and get something meaningful out of it), you would be able to debug, refactor, and enhance code as well as author it. Without even rudimentary support for testing and QA, the code-generation tools that come with UML software are nothing but an unsubstantiated fantasy about UML's effectiveness.

Because those tools have no idea what the semantics is in reality, ie. they are not programming languages. It is ad hoc, and very much prone to error, _because_ while you have a UI ...> PL translation you are missing on the UI <--- PL translation. That would of course require that UI to understand exactly what you are doing, which is kind of non-sense because the "real UI" of the programming language is the program, not some Rational Rose mumbo-jumbo.

The language translation thing you could actually talk about. Now I wanna say a few things you can't tell a management person. :>

I'd like to point out the guys who wrote UML actually have NOT THE FREAKING IDEA what semantics is. They _think_ their stupid diagrams have a useful meaning, but in reality it's just a diagram. Their level of ignorance is clearly reflected in their UML spec, trying to push that as a universal specification of design, oh, and not just in programming....

exa shakes his head

If only they had read a tiny bit of work on computational ontology they would have known that a representation is good only when it is useful. You will see that those use cases and collaboration diagrams will often not reflect the solution to the problem or help you do it, therefore their function is simply pleasing the even more imbecile management.

Another reason why I am so much sure about my claim that UML guys are complete morons: these people actually come from a tradition of bigotry so intervowen into corporate non-sense that they think they are good engineers by not really having contributed anything at all to programming wisdom.

Why?

Because programming advances when you have a novel language feature, a new concept, etc. Like objects and classes, or higher order functions, or genericity. Which are very much distinct things, btw, and none of which is done well by C++.

There are justified forms of bigotry, for instance the designer of Eiffel will defend that his view of programming is reflected in the language, and it will help practice better software engineering. There is merit in that, if you look at Eiffel and the similar Sather there are a lot of nice ideas that have actually been implemented and makes sense engineering-wise. He may have pushed his idea single sidedly on some projects, but there is some meat to it and it's hard to say "We'll use X and not your PL in this project"

Now, look at UML, Rational Rose and all that trash, you will see that their credibility is just a product of Britney Spears level (shallow) popularity and reciprocal appreciation of stupidity between them and managers. Ah, how great that you are morons. Thank you sir, we think it's great that you appreciate our being morons, and we'd like to commend you on your being complete imbeciles..... It's exactly the same thing as Visual Studio wielding "developers" who often have no idea how to make an interface that can't be drawn with the UI designer.

That said, if somebody comes and develops a great graphical programming environment and it works there is nobody who's gonna object to it!!! I contribute to KDevelop project exactly for that reason. Why should we be stuck with an editor which doesn't even give us a means to visualize and browse the source code by PL semantic categories? We also use Qt Designer because it's a blessing, there is no point in writing pages and pages of monotonic widget code....

Way back in the ancient mists of time, when I was a Mac hacker, I tried out Prograph. It's a full-fledged programming language (sort of like LISP with 2D model of how return values connect to parameters) with a killer debugger--you could watch your values propagate along the dataflow graphs, edit the program, roll back execution, etc.

Kinda weird, I admit, but nicely done.

UML-based CASE tools are somewhat bogus (at least from my language designer's perspective) because they're a sign of weakness either in your programming language--perhaps you can't do high-level modeling directly in your source, the way Paul Graham can--or in your source browser--perhaps you can't generate all the pictures you need on the fly.

CASE tools are also doubtful because many of them assume two separate representations of the same information, always a maintenance sin. If you have complete round-tripping between CASE and source, you're fine, but a lot of these tools don't do it well. Remember all those companies which lost their COBOL source code and had to do Y2K remediation by hand-hacking OS/390 binaries at $375/hour? If you can't round-trip, your company will be digging itself into the exact same hole, and you'll be in Oracle Consultant Hell<tm> for the next two decades.

Of course, I'm assuming a slightly idealized world here, with good languages and tools. Perhaps your languages suck collosally, you've got no source browser, and you're an extremely visual thinker (or your teammates are). Then I can see the point. Or perhaps your CASE tool is an actual, high-level programming language well-suited to your domain, and it allows you to maintain a single source representation. Great!

However, many interesting designs can't be expressed in some of the UML sub-languages--you can't really show multimethods, template metaprogramming, or domain-specific language extensions using LISP-style macros. And since I often work at this level of abstraction, UML's "all the world is a 1994 C++ compiler" attitude kinda gets on my nerves at times. My CASE tools run inside my compiler, and they don't suck.

If these tools answer a deep need for you, then go ahead and use them. But if they seem strangely irrelevant to your working style, don't feel like you're a bad person. And make sure your boss tries out a pilot project with these tools, and seriously considers their effects on long-term source maintainability.

There is no silver bullet at the coding level--most big productivity gains come from better HR practices (hiring very small numbers of extremely talented people) and better project management (building features in order of decreasing ROI, a la XP).

There have been a couple implemented through the years. You could call Hypercard on the Mac as one. SGI's Explorer and the Khoros project were attempts to do this for scientific visualization. ( And in IMHO, they both were pretty successful.) They didn't write code for you, but provided a structure in which to glue many standard modules and your custom modules into a simple dataflow.

I think the big problem with these systems is making them general enough to be useful and to get executables that will run outside the framework of the graphical editor.

I think Khoros is still available and is definitely worth taking a look at if you're interested in such things.

- Booker C. Bense

BTW, I'd be delighted to see that Visual LISP. Interestingly enough LISP is one of the few languages that would work well in a visual environment.

Happy hacking,

I tinkered around with UML a while back. I read a couple books on it. I didn't have the cash for a proper CASE tool, so I would use drawing programs or even draw them on paper. I also tried ArgoUML but it was hardwired to be the way Java programmers like it, and I wanted to do C++.

At some point I gave up with a vague sense of disappointment, feeling like there must be something wrong with me if I couldn't use UML. But then sometime in 2000 I was very pleased to read in the book More C++ Gems on page XVI of the introduction:

Throughout the last three decades, the software industry has been trying to find ways to express designs outside the code. Consequently, we invented things like flow charts, data flow diagrams, and UML. Bjarne is saying that we need to express the design directly in the code. This does not preclude diagrams and models, but begs an interesting question. What document is the final authority for the design? Is it the model? Or is it, as Bjarne seems to suggest, the code?

Interestingly enough there is considerable momentum gathering behind a number of lightweight development processes that also claim as a fundamental principle that the design is best expressed in the code. Perhaps the premier of these processes is Extreme Programming (XP).

That was also the first I heard of XP. They give the URL of the Extreme Programming Wiki, and I spent a lot of time exploring there.

This was the first I realized that I wasn't somehow sinning by not diagramming my code. Rather, the very best thing I could be possibly doing was documenting my design by writing my code.

The usual way I do my design is that I write header files. The other thing I do is write unit tests. A unit test doesn't just serve the purpose of seeing if your code works, it also serves as a requirements specification, in which the requirement is expressed in code.

I used to try to write flowcharts early in my career. Once, when I had to debug a really nasty network test tool that was a complicated state machine, I drew a complicated dataflow diagram and wallpapered my cubicle with it - which turned out to be all that was required to get management support for scrapping the tool so I could write a new one.

I've been working full-time as a software engineer since 1987. I've shipped more high-quality commercial programs than I can even remember anymore.

And I never draw a diagram.

That's because I express the design in the code.

There is a school of thought that claims design should be free from coding language syntax. This will probably is true among the people who are not familiar with the syntax of the language, but are good only in the semantics part, though. That may probably explain why there is a field in software engineering devoted to this area.

Naturally, the tools they use do not even touch the tools coders use. A good example of it is UML and others.

Personally, I would prefer a tool that can deal with both: semantics and syntax. Maybe someday, UML can have all these as well.