Case Tool

Software tool designed for use in Computer Aided SoftwareEngineering.

CASE tools aren't evil. But are they often too restrictive? Do they discourage EvolutionaryDesignTechniques?

Please finish this description of Case tools by adding your comments about Case below.

I've always viewed CrcCards as an anti-case-tool. Many people try them and get nothing out of them. The same is true for most tools and methods, of course, but with them one expends so much more energy and seems so much more productive, and wastes so much more time before failing.

To be positive for a moment, I am pleased that so many people have found CRC Cards both useful and liberating. Their success comes from within. My advice to them: Try running your next CRC session in your head.

-- WardCunningham

p.s. NormKerth is my model of someone who can make methods and tools work. His advice: "You've got to make a method your own before it will work for you."

I believe that CASE tools discourage thinking. It just doesn't work to get a team huddled around a keyboard; you lose that sense of ownership you get with CRC cards. Furthermore, I've seen CASE tool users spend most of their time getting the picture pretty, not working on semantics; hence, the pattern Mercenary Analyst [1].

Consider this quote from Rybczynski, regarding Alberti:

: Here is another liability: beautiful drawings can become ends in themselves. Often, if the drawing deceives, it is not only the viewer who is enchanted but also the maker, who is the victim of his own artifice... Alberti understood, as many architects of today do not, that the rules of drawing and the rules of building are not one and the same, and mastery of the former does not ensure success in the latter (The Most Beautiful House in the World, by Witold Rybczynski, p. 121).

-- JimCoplien

It's possible to use CASE tools (with some methods, anyway) by starting at a whiteboard or with 3x5 cards, then transcribe the work to a computer. (And that, too, is where Mercenary Analyst [1] comes from.) Certainly all the collaborative magic that happens in good teams is vital; admittedly, it's less likely to happen around circa 1995 screens than around other media.

The value of CASE tools is to provide a legible, searchable, checkable record of some effort (analysis, design, whatever) that can be put under "source control."

I think the problem is that CASE tools create drawings of software, but SoftwareHasNoShape.

(And maybe CASE tools are their own worst enemy? They never (?) reflect the user interface conventions of the environments they run under. They often have unique user interfaces. In my experience, they always have really lousy user interfaces! Having only one person have to deal with that pain is why "Mercenary Analyst" [1] isn't named something gentler, such as "Separate Scribe.")

If there was a method that could be implemented/automated with the WikiWikiWeb, I'd jump on it!

-- PaulChisholm

CASE tools also abhor inconsistency. My designs are never fully consistent. During design, there are always parts of my design which are inconsistent with the rest. People seem to be able to live with this inconsistency. CASE tools cannot. Keeping all the models "always" consistent impedes progress.

You lose DesignVelocity.

Ultimately design is about language, written, spoken, drawn or hand-waved, and design is done through conversation. CRC cards are a powerful way to direct, focus and speed design conversations.

Patterns help too. They provide a new vocabulary about a common and shared design culture that enriches our design conversations and increases DesignVelocity.

-- RichardHelm

(Static checking and DesignVelocity aren't just antithetical; they're complementary. Sometimes you have to run as fast as you can to hit all the places you want to explore; sometimes you have to snuggle down and make sure your nest is secure. Hey, I want DesignVelocity to drop to zero during final system testing! In theory, development methods and CASE tools and programming languages could support DesignVelocity early on, and static checking later on. In practice, that seems to be one of the first choices a development effort has to make. Bummer. -- PaulChisholm)

To expand just a little on what Richard wrote regarding how CASE tools abhor inconsistency, what has always driven me out of my tree is that CASE tools require that everything be given the same weight and attention to detail. So, those things which are completely or even intuitively understood must nevertheless be painstakingly recorded in agonizing detail, and those which you would like to defer until later must be faked in some manner so that when you run the CASE validation of the design, the tool doesn't choke and spew. When I mentioned this phenomenon to our resident StP guru who is capable of spending countless uninterrupted hours toying with his drawings, he said, "Validation? I never run it."

Gee, I wish I'd thought of that.

CASE tools are terrific for recording the design, but they still stink when it comes to creating the design. Creation is an uneven, herky-jerky progression full of fits and starts, hitches and conceptual high dives with no water in sight (I always feel a lot like Wile E. Coyote when designing). Until CASE tools exist which can cope with the shapeless plasticity of the intuitive mind, they'll remain as nothing more than glorified drawing programs. CRC cards have helped us design collectively and with great enthusiasm by providing a medium facile enough to capture the fevered collaborations of mad, wild-eyed software developers, yet simple and clear enough to instantly be useful.

-- DonOlson

I am quite surprised by the negative entries on CASE tools. Synon is a CASE tool that, I believe, changes business application development in a very positive way. One thing that developers lack is the propensity to document. Let a system evolve for 5 - 10 years with multiple hands at the code and you wind up with garbage that is almost impossible to maintain. At very least, it is definitely not cost effective to keep it going. This situation breeds key person dependency. That 'key person' is the ownership guy that knows the system. This is great for that programmer but extremely bad for the company and other programmers in the department.

CASE tools provide a standard method of approach. True, construction may seem boring, but the construction time compared to traditional methods is dramatically reduced. CASE does require a certain amount of development discipline.

Emphasis in CASE is not in construction, CASE makes that the easy part, it's the analysis and development phases that become critical. Semantic and abstract data modeling are the new challenges we encounter. That is where the future of system and applications development is heading. I say that because it's not only functions and processes that should be object oriented, it is the data and the data relationships also!

In a paper I recently wrote, I pointed out that many systems written today have the business rules hard coded in the program. I contend that the BusinessRulesBelongInFiles! Defining these, their relationship to the data and designing a system that allows for the rapid change of these business rules or, for that matter, system rules, becomes the critical path. CASE frees us from worrying about construction methods and trivial matters like ownership of the programs. True, you can't be an idiot and construct using a CASE tool, but you can't be simply a programmer when defining and developing system architectures and database designs.

This is 'Big Picture' thinking. Defining abstracts, data relationships and finding patterns in the environment you are building for are the mental challenges! Not, 'should I use an IF, a DO WHILE, a DO UNTIL, or a CASE statement here?'

-- BillMeecham

In the previous wiki entry, BillMeecham said something that struck me: One thing that developers lack is the propensity to document.

I have always thought that the answer to the developers don't document problem is to teach developers to document. Thus, ProgrammersAreWriters.

-- ToddCoram

I've been using a CASE tool (RationalRose for Smalltalk) over the last few months, and I've become convinced that CASE tools have been put on the wrong end of things. We are using Rational Rose to document things AFTER they've been written rather than trying to "force-fit" them in before. We've been using CRC and the occasional Booch diagram on a big piece of paper stuck to the wall to design things before they are coded. It's only after the code reaches a "freeze" that we whip out the CASE tool and ReverseEngineer the design to get diagrams so we can explain the system to others.

I find that these diagrams especially help us explain the system in terms of what Patterns we find. For instance, I showed KenAuer a fairly complex part of the system a while back by showing him the diagrams and saying "This part over here is Composite, this part over here uses Interpreter, and this bit over on the edge uses Singleton."

-- KyleBrown

The October 1996 (v. 39, no. 10) issue of Communications of the ACM has an article, "Why are CASE Tools not used?" The author, Juhani Iivari, surveyed a number of software development companies in Finland. He found that improvements in productivity and quality (as far as CASE tools were concerned) were positively correlated with usage and "relative advantage," while usage was positively correlated with management support and negatively correlated with "voluntariness." In other words, people benefited from CASE tools if they used them and CASE tools were a good fit for the problem, and people used CASE tools if management wanted them to and if they were forced to use them. This is in Finland; Iivari presents some evidence and an argument that low voluntarism would be even more important for CASE usage in the United States. -- PaulChisholm

The main problem with CASE tools is that management often see them as a panacea. Vendors usually plug them by quoting all the extra features such as "full cycle code generation". That's not what I use a CASE tool for.

All methodologies have a graphical element. The diagrams perform (at least) two functions.

Making it simpler for a designer to envisage the inter-relationships between their classes and view the complete design.
Making it easier to explain the design to (often non-technical) management.

I think better about a design when I'm looking at a picture of it. Once you get beyond about 5 classes you can't easily hold the structure in your mind - even with the use of patterns.

So, for me a good CASE tool is an enhanced drawing tool. It supports my notation of choice, provides some consistency checking, and encourages iterative design by making it easy to change the diagrams and play "what if".

-- KeithDerrick

I remember hearing someone say that diagrammatic models are lies, because like comments they can always be out of sync with the code. Personally, I like diagrams because I have strong tendencies toward visualization when I design. Picture is worth a thousand words, etc. To me, the ideal in all of this would be to make systems which can render their own design diagrammatically in UnifiedModelingLanguage, OML, BusinessObjectNotation, or whatever. At that point, we have full model consistency and we also have the ability to "see" an abstract (read "less detailed") view of our system. As much as I like the spartan attitude of becoming "one with the code" I think that anything that we can do to make our systems HyperReflective? in this way ought to be encouraged. -- MichaelFeathers

Re: "I have always thought that the answer to the developers don't document problem is to teach developers to document"... This argument is used in many forms in many fields and situations, complaining about many things (I am thinking of the same complaint offered to formal methods at the moment). I have seen two main approaches to dealing with it. One is to assume that you can teach developers to document, and spend your energy on that. The other is to assume you can't teach developers to document and work from there. Most places try for the first and apologize that they didn't succeed. ExtremeProgramming is interesting because it works from the second. Perhaps we'll hear them apologize for whatever aspect doesn't work for them, but so far they seem quite happy.

I don't have reason to believe you can teach developers to document, and that is based on their personality, education and the economic and social forces at work on the job. This means I accept from the outset that anything in a CASE tool is out of date. -- AlistairCockburn

I've recently had a positive experience of CASE tools. We're using one for the design and C++/COM code generation on a project that's been running for twelve months now.

Initially I put my foot down and said "we are going to use this tool - at least for the next 3 months". A bit of resistance, but the limited duration allowed every one a get out if it didn't work. Once we got to the three month checkpoint, no one asked to drop the tool, no rave reviews but acceptance. At the six month point I was asked if we could add the test framework into the model as it was "easier that way".

So, how's it changed the way we work? I think the biggest change is that we do more design now. Partly gross design time before the coding starts, but more importantly perhaps, during coding. When you fire up a CASE tool to change / add a method to a class, you are faced with a many-class view of the system. When you edit a header file, you see a much lower level view of the system. Whilst a good programmer should rise above this, anything that helps has got to be a good thing. -- GilesChamberlin

Why is this an argument for using CASE tools? It seems to me that you could have gotten the same benefit (and probably more often) by keeping a bunch of CRC cards lying around on a big table, or having a bunch of wall-chart UML diagrams around the room. You'd still get the "big picture" and it'd be cheaper and faster. -- KyleBrown

My sympathies are definitely with the ExtremeProgrammers on this one. I'm trying to champion CRC at the moment. However, I've also been roped into a company-wide evaluation of various Case tools. So can anyone who has practical experience of using Rose, Artisan, Rhapsody or whatever for full-on code generation sum up their findings? (And if no-one answers, feel free to prune this in a couple of months!) -- EoinCavanagh

[1] http://www.research.att.com/orgs/ssr/people/cope/Patterns/Process/section24.html

Case tools are appropriate for some types of development. Case tools are not appropriate for some types of development. The types of development for which Case tools are appropriate and not appropriate are not necessarily mutually exclusive. -- EricJungkurth?

I've been using Rhapsody since 2001 but I'm also an advocate of the principles inherent in Extreme Programming. Test Driven development and pair programming is a given for me. The main divergence I have with die-hard agile guys is that I apply these principles at a higher level of abstraction than C++, Java code etc because I trust the code that Rhapsody generates and, trust me, I'm not easily pleased. It is incredibly powerful as a code generator as it actually produces the code you'd want to see. I guarantee that I've never have to go outside the tool to write a single line of C++ for any embedded application on which I've worked. It is also easy to include any existing code into a build.

The argument I regularly hear from the agile community is that "the code is the design". I say that if you really want to believe that then I guess we must be done in the evolution of software development techniques. Note however that as little as 20 years ago some were saying that the only thing that mattered was the assembler code.

Rhapsody is a special tool. You need to experience it properly to see that. As with anything that will provide worth there is some effort involved in learning how to utilise its power. The problem is that too many software engineers have become weary and settled for the first thing that made good sense, Extreme Programming, and still want to believe that it is a total solution. It's great but it's even better than you think when the UML design is all that matters.

-Ian Macafee (yes, I used to work for I-Logix but that was just for 3 years and I've left now - I've gone back to developing using Rhapsody and I teach my kids how to use Rhapsody)

i.macafee@virgin.net

CategoryJargon