Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Why don't Open Source programmers use CASE?

By Paul Johnson in Technology
Tue Oct 03, 2000 at 01:08:22 PM EST
Tags: Software (all tags)
Software

CASE (Computer Aided Software Engineering) tools enjoy widespread use in the computer software industry, but not amongst Open Source coders. Why is this?


What is CASE?

A CASE tool these days generally provides the following facilities:

  • Diagram editors. The standard graphical notation is now UML (Unified Modelling Language) created by the Trinity of Booch, Rumbaugh and Jacobson at Rational Software. Previously it was Yourdon. The Shlaer-Mellor method was in vogue at one point, but now seems to be eclipsed by UML.
  • Consistency checking. The contents of the various diagrams are checked for conformance to syntactic and semantic rules of the notation, and consistency with each other. In fact these days the diagrams are just views into an underlying "model" of the project, so it is not possible to create "illegal" diagrams.
  • Code generation. This converts the diagrams into class and function declarations. The actual operations are usually implemented by typing the text of function bodies into the CASE tool, which then pastes these inside the appropriate files. Code generation is generally user-programmable, so you can (e.g.) incorporate your favourite GUI library and automatically generate dialog boxes for particular classes, or write a special-case generator for interfaces to that horrible legacy code from the previous version.
  • Model animation. This is the diagrammatic equivalent of the source level debugger. You can watch objects exchange messages and see how state machines react when events occur. Execution traces are shown in nice time-lines which can be compared to the theoretical ones you generated during the design.
  • "Round trip engineering", a grandiose name for incorporating changes in the source code back into the project model. The sophistication of this varies, but most tools seem to use formatted comments to find their way around the code and mark off certain sections as non-editable. I've heard stories of projects being unable to get their heavily modified code back into the model, and having to abandon the model.
  • Configuration management, or at least links to a range of configuration management tools.
  • Requirements management, or at least links to tools.
  • Bug tracking and workflow, or at least links to tools.
  • "Documentation" tools. These are provided for developers with legacy customers who think that real documentation has to be printed on paper. They just print out a predefined selection of diagrams and the text they enclose in PDF, RDF, Postscript or whatever. More intelligent customers will ask for a snapshot of the model and a license for the CASE tool.

The earliest CASE tools were probably flow-chart editors, but they never got very far. CASE tools only became fasionable was in the days of Yourdon. Yourdon used "Data Flow Diagrams" (DFDs) to express the way in which information moved between modules and sub-modules, and State Transition Diagrams (STDs, I kid you not) to show the way in which different modules were activated at different times. There were also Entity Relationship Diagrams (ERDs), which were basically the project data expressed in 3rd Normal Form (like in a relational database). But nobody ever really used ERDs.

However in the Days of Yore(don) the tools were primitive. The most popular tool was Teamwork, and it made refactoring a project really really hard. The result was that everyone did a sort of top-down analysis, creating a tree of modules and submodules down three or four layers, and that was that. There was no code generation, so of course the model and the code tended to drift out of synch. In every Yourdon project I've seen the managers either claimed that the model was really up to date when it wasn't, or promised that it would be brought up to date Real Soon Now, as soon as the next release was out of the door.

When OO started to become popular in the late 80s, and especially when C++ hit the fan, CASE got a real push forwards. Several OO notations got moving, and quite a few died out. (Eris be praised, the abomination HOOD died early, despite being pushed by the European Space Agency). This isn't the place for a detailed history, but in the late 90's UML emerged and is now the dominant standard. One change which UML introduced was process-independence: previously all the notations were bundled with some kind of development process, but UML explicitly rejected this. UML is a notation only, and can be used any way you see fit.

Lots of people don't like UML, but IMHO its not too bad. Its main downsides are that it is complicated and lacks a clearly defined semantics. In part this is because it was designed to be directly translated into various target languages, so the exact semantics of a UML class depend on the semantics of the language into which it is translated. This also causes headaches when you try to use UML features which are not directly supported in the target language, or vice versa. E.g. multiple inheritance when targetting Java, or any inheritance when targetting C. There is also a clear C++ bias in the design of UML. E.g. specific flags corresponding to "private", "protected" and "public" features in a class. OTOH there is no support for objects changing class, as in CLOS and other "academic" OO languages.

Why use CASE?

With early CASE this was a tricky question. A common reply from skeptics was "pretty pictures for managers". Software project managers knew that they had a problem with hitting deadlines and budgets, and hence were ready to buy anything that promised to be a solution. There may also have been an element of "nobody ever got fired for buying CASE" in there. I recall trying to interest people in Eiffel in those days, and one of the showstopping questions was "what CASE tool support does it have?". It might have been a much better language, but without CASE support it was dead.

These days CASE proponents find it much easier to give an answer to the question of "why?". Now that CASE tools can guarantee to keep code and model in synch the royal headache of manually updating two representations of the same thing has gone away. And CASE tools help reduce the cost of Brook's Law by showing new team members how the system works.

CASE Users

Almost all CASE tool users are commercial software development houses, and CASE licenses are a significant cost for these people. Meanwhile Open Source hackers have ignored CASE completely. There are very few OS CASE tools available, and nothing to match the commercial offerings.

So this brings me back to my original question: why don't hackers use CASE? Here are some random thoughts on why (not).

  • CASE is expensive and proprietary. But that has never been a problem in the past. When hackers want a tool they build it, and the result can usually hold its head up against the best in the commercial world. Gcc, Linux, Apache, cvs and bugzilla all demonstrate this. I have no doubt that if hackers wanted CASE tools then commercial CASE vendors would be forced to charge a lot less for them, or even driven out of business. Remember when C++ compilers cost real money?
  • Open Source coders need to know how the system works. Eric Raymond has written about the way in which OS projects violate Brook's Law and get away with it, but you still need at least some understanding of how the code works in order to modify it. CASE diagrams can give you this.
  • On the other hand OS designs emphasise modularity and well-defined interfaces (sometimes they even document those interfaces). Many of the very successful OS projects (Apache and Linux in particular) are built on this principle. Once you have a modular architecture, new features can become almost independent of the main system, needing only the narrow little module interface to communicate.
  • Another principle from Brooks: show me your code and I won't understand, but show me your tables and I won't need to see the code. Do open source projects emphasise data structures enough that the code becomes transparent? From what I've seen I don't think so.
  • Is it just a historical thing? The ability of CASE tools to keep model and code in synch has only occured over the past five or so years. Before then their use required a lot more work. Maybe hackers just haven't caught up yet.
  • Is it a cultural thing? Do hackers reckon that they can do without namby pamby diagrams? Or is the "nobody got fired for buying CASE" attitude still dominant in business?
  • Is it related to the wide range of languages used by OS projects? CASE tools generally support C, C++ and Java. Hackers use Perl, Python, Lisp and many other languages which are higher level than (especially) C++. Do these higher level languages give the same productivity boost as CASE tools?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Why don't OSS projects use CASE?
o No added value: CASE tools lose 10%
o No free CASE tools 12%
o Text based high level languages give the same win 7%
o Modular designs give the same win 10%
o Clear data structures give the same win 1%
o Historical: old CASE tools sucked 19%
o Cultural: rejection of diagrams by hackers 38%

Votes: 57
Results | Other Polls

Related Links
o UML
o Rational
o Yourdon
o Shlaer-Mel lor
o HOOD
o Also by Paul Johnson


Display: Sort:
Why don't Open Source programmers use CASE? | 33 comments (25 topical, 8 editorial, 0 hidden)
CASE? (3.08 / 12) (#5)
by the coose on Tue Oct 03, 2000 at 12:29:40 PM EST

Seriously, I haven't heard much about it and I've been in the business for almost 8 years. I suppose it has a lot to do with what type of software you develop. After reading your (excellent) article, I can see large applications benefiting from such a tool.

In my previous job I worked in the Microelectronics Division at IBM. I worked with DSPs; the software I worked on ranged from DSP assembly code to Windows drivers (yuck!!) to small test applications written in TestBASIC (double yuck!!). I really can't see where CASE tools would've benefited me; it seems like it just would've gotten in the way.

But in my current job as an embedded systems programmer, I work with a mixture of C, C++, and 68K Assembly. The project consists of a mostly flat class hierarchy with most of the underlying real time code written in straight C with inline assembly. With only a 33MHz 68302 and a 40 MIP DSP to do the real time communication protocols we do, you have to get things done in a certain amount of time - no questions. Do CASE tools allow for this kind of precision? It would seem they do from your article but how much setup time would their be? Would I be spending way too much time configuring the CASE tool to generate the code to meet the real time requirements?

I don't know; it sounds like more work to me when all I really need to do is pop up my favorite editor (Cooledit ;) and start coding away.

Why no more CASE tools. (3.92 / 14) (#6)
by Sedennial on Tue Oct 03, 2000 at 12:33:11 PM EST

First, I must say this is an extremely well written post.

I've used CASE type tools in the past, primarily code generators and prototyping software. However, as I moved deeper into software development I found more and more inflexibility, and a lot of underlying assumptions made which produced sloppy, slow, and often buggy code.

I found that I was spending more time rewriting the generated code than I was in writing original code myself. It also makes it difficult to go back 3 months later and tear apart a piece of software that was essentially written by me and whomever wrote the code generator.

The final death knell for me and CASE tools though came when I quit developing for Windows/DOS and moved to OS/2, then to Linux. I started working in Perl, REXX, and other languages (continuing in C and ASM though). I couldn't find a CASE tool that worked well, and I finally realized that fundamentally I hated using 'machine generated' code. It always seemed to inherently go against the principles of good coding.

And frankly, the generated code was always kludgy and totally inelegant.
--
Warning: The Sturgeon General has determined that watching television may lead to IQ reduction, loss of your auto keys, and other negative side effects.

a case in point (4.37 / 16) (#11)
by Anonymous 242 on Tue Oct 03, 2000 at 01:16:49 PM EST

Argo/UML is a free CASE tool written in Java for anyone itching to see what software engineering is all about.

My take is that there are several reasons that not a whole lot of programmers (let alone open source programmers) use CASE.

  • Most programmers are tinkerers and not engineers.

    This is not a criticism of programmers, but very few programmers I know actually engineer their program. Most projects I have worked with do have some design documents, but rely on what I call organic programming for the implementation. For comparrison, most hand built cars are put together by tinkerers while assembly line cars are mostly engineered. When (and only when) the engineering is done well (think Audi, BMW) does the assembly line product equal the hand-built product done by a tinkerer with lots of experience. OTOH, lots of hand built cars aren't even safe enough to drive on the road. ;)

  • Many people mistake visual RAD tools (like C++ Builder or Visual Basic) for CASE tools and so don't realize the true power of CASE.

    The idea of engineering a program is so foreign to most people that they don't really comprehend the idea. Let me make a comparrison to music. I was speaking with my brother in law about how I wanted to get a high end sound card (back in 1994) so I could compose music programatically. His view was that doing so (1) took all the fun out of it and (2) didn't take the same level of talent as playing a "live" instrument. The same attitudes often exist in the IT world. Engineering rather than tinkering is looked on with disdain because the false notion exists that CASE is simply painting a screen with a RAD tool. Well, programatically creating music is much more than just throwing notes on a staff with Lillypond and CASE is much more than just painting the GUI and connecting it to a database. People without truly understanding engineering never grok the difference.

  • Most CASE tools are prohibitively expensive.

    As pointed out by more than one person, your average college age open source tinkerer doesn't have several thousands of dollars to spend on CASE. I evaluated a few different CASE tools in 1999. I remember one that was a 16 bit Windows program (in 1998) that cost $1,500. The code generator cost another $1,000.

  • Very few CASE tools support multiple languages or multiple paradigms.

    In the Open Source world, variety is more than the spice of life. In the Open Source world, variety is life. A CASE tool that doesn't generate Perl, C++, Lisp and a few other languages will not find much acceptance in the Open Source world.

  • Very few Open Source developers grok OO.

    This is beginning to change, and there have been notable exceptions from an early date, but Open Source has a largely procedural parentage favoring procedural languages over OO enhanced languages. CASE, on the other hand, favors OO design philosophy.

The bottom line is that CASE is more than just a tool, its a philosophy of design. For programmers to be effective with CASE, they need to change the way they think and this is counter-intuitive to most open source programmers. Why adapt to a tool that changes the way you think if one is already productive thinking in the current manner?

Just my lame two cents.

-l

what I've found (3.00 / 2) (#21)
by drivers on Tue Oct 03, 2000 at 03:57:44 PM EST

I've been trying to get involved in a free software project called ClanLib which is a C++ Game Development Framework, and is cross platform (runs under Linux and Windows at least, taking advantage of X and other targets on Linux, and DirectX on Windows). It's pretty cool, but they could use a lot of help in terms of documentation, testing, and fixing up the code. Which is what I'm trying to do.

I started picking up lots of different books and reading them to make sure I knew what I was doing. The C++ Programming Language (Stroustrup), Game Architecture and Design (Rollings and Morris), Object Oriented Analysis and Design with Applications (Booch), UML Distilled, and Design Patterns (gang of four). (In the middle of all of these.) If you know what these books cover then you know where I'm coming from.

I wanted to take apart ClanLib, diagram it up in UML to get my head around it, and use that to write documentation, tutorials, test cases, and suggest improvements for the design. From what I can tell so far, there was very little thought put into the code based on good Object Oriented programming.

I am interested in any programs that I can use to build UML diagrams. I tried Argo/UML and found it to be incomplete, buggy, generally user-hostile.

[ Parent ]

Re: what I've found (3.00 / 1) (#22)
by Anonymous 242 on Tue Oct 03, 2000 at 04:26:59 PM EST

I tried Argo/UML and found it to be incomplete, buggy, generally user-hostile.

I believe that your experience with Argo/UML was not entirely different from experiences many people have had with CASE tools. This is why I wholeheartedly agreed with trhurler that the current crop of tools sucks wind.

Even so, there is little motivation to improve such tools when very few people are inclined to use them. I applaud your effort to look at ClanLib systemically, but as you learned, it was less engineered than grown organically and you lacked a complete and intuitive tool to model it.

CASE will only help projects that have been designed by some sort of strict methodology. If your project doesn't fit the model, attempting to model it is doomed to failure.

Thanks for sharing,

-l

[ Parent ]

Re: what I've found (3.00 / 1) (#23)
by Fesh on Tue Oct 03, 2000 at 04:27:24 PM EST

As far as breaking it apart and diagramming it... I have the same dilemma with the closed-source system I'm working on at work. What sort of approaches were you using?

I suppose part of my problem is that I'm having a hard time getting my head around UML, especially since most of the stuff I've seen is geared towards designing a system from the ground up instead of trying to model something that's already there.



[ Parent ]

Re: a case in point (3.50 / 2) (#24)
by aphrael on Tue Oct 03, 2000 at 04:55:41 PM EST

Most programmers are tinkerers and not engineers.

Absolutely. Another issue, too, is that a lot of programming requires integration with existing systems which are not fully understood. It's difficult to perform engineering analysis on the new system until you understand the old one --- and the only way you're going to come to understand the old one is by tinkering with it and building things that interact with it; thus, by the time you're ready to perform the engineering analysis, you've already done a significant fraction of the post-analysis work, which makes the analysis seem redundant.



[ Parent ]
Software "Engineering" (4.00 / 1) (#31)
by Simon Kinahan on Wed Oct 04, 2000 at 10:30:18 AM EST

Well. This post is longer than many articles, and I'm sure I could cut it, however I lack time. Here it is anyway.

I am not sure that any existing software "engineering" practice corresponds to engineering in the sense that is understood in other disciplines. In physical engineering, typically a project to build a new thing goes through a long, complex design and testing process, where ideas are discussed and prototypes built, and various different professionals (architects, engineers, manufacturing and materials specialists) take part in different stages. Only once the new thing has been established to be buildable, functional and safe is it actually built. This applies both to one off objects (bridges) and mass produced objects (microprocessors). Any change to the designed object once its built or being manufactured is considered a major undertaking in its own right, a whole separate engineering project.

If we try to draw analogies with software, the analogue of the process of manufacturing is the process of compiling the source, building an install kit and burning CDs. The analogue of the process an architect would go through with a customer of talking about the kind of building they want, and keeping an eye to implementation, is what we typically call "requirments gathering". That process is iterative, both for architects and for us, as implementation issues typically tangle up the original plan. Everything else we do is design . No, really. Read that again. Everything else we do is design. Coding is design, design is design, testing is design, "architecture" is design, even maintenance is design. By strict analogy with physical engineering, I believe this is indisputable.

There is however, as most of you no doubt know, another, more common world view, where "coding" is seem as the manufacturing process, and the actual process of manufacturing ignored as an incidental (after all, it is trivial), and "maintenance" is seen as the equivalent of stopping the girders from rusting by painting them frequently. The idea of "design" is reserved for some process, performed up-front, in cargo cult imitation of what real engineers do, by "architects" or other senior people with no contact with the code. "Coders" are considered as a particularly pesky form of overpayed semi-skilled labour.

This world view is responsible for some of the failings of the software industry as a whole. People employed as developers often don't realise that their job is to do quite a large portion of the design for the product, and fail to take responsibility for their decisions. People employed as "designers" or "architects" or (gods forbid) "analysts" produce specs that miss stuff out and fail to take feedback from "mere coders". Thus real design - actually deciding how the product should do things, and in many cases even accurately describing what it does, simply fails to get done explicitly and is done by accident by the first developer to come to it in some arbitrary way.

Software is different from physical engineering, mostly in the fact that the "manufacturing process" for software has extremely low costs. Thus you can release stuff have it break, fix it, release it again at almost zero cost to you, and in the case of open source or subscription models at almost zero cost to the customer (unless, of course, they actually tried to deploy it while it was still broken). Try doing that with a bridge. Its my view, in the end, that all software developers are engineers, since what they do are steps of the engineering process typically done by people called engineers. Its not at all clear to me what it means to engineer a program as opposed to to write one actually should mean.

Of course, I know what it typically means. In most peoples minds it means to have a separate conception of the "design" of the software which can be presented independently from code in any particular language, which covers the class structure without talking about code. Somehow, having a diagram showing the classes and their interfaces is meant to be a "better" representation of the code than the code itself.

In my view this approach is confused. I yet to have anyone clearly explain how this is meant to be helpful, or how a diagram showing the formal structure of a program (ie. UML) is meant to make sense without a complete functional description of what is being achieved. What is actually, really missing in most software products is a clear conception of what they do and how they do it, not an idea of how they are constructed. If you talk a developer on the average long-running project, one thats in "maintenance" mode, he can tell you about every single method on every single class, and talk you through the control flow in every single thread, but he cannot, usually, give a concise description of what the code actually does at a higher level of description than that of the code itself.

Having said all of that, I place myself firmly on the "engineer" side of the engineer vs tinkerer divide. I rate the people I work with, and have tried to acquire my working habits from, as consummate professionals compared with most software "engineers", and I have to say that in my view CASE tools are designed to support the software industry's cargo-cult idea of what engineering is. They represent the form of programs without representing their functions, and thus focus thought on form without function, perfectly reflecting the attitude of managers and "professionals" which aims to attain the form of "real engineering" without understanding the function.

Simon

If you disagree, post, don't moderate
[ Parent ]

Re: Software "Engineering" (none / 0) (#32)
by Anonymous 242 on Wed Oct 04, 2000 at 11:41:37 AM EST

Of course, I know what it typically means. In most peoples minds it means to have a separate conception of the "design" of the software which can be presented independently from code in any particular language, which covers the class structure without talking about code. Somehow, having a diagram showing the classes and their interfaces is meant to be a "better" representation of the code than the code itself.

What I hear Simon Kinahan to be saying is that most people consider flow-charting (or using some other graphical design methodology) to be engineering.

If this in fact Simon Kinahan's assertion, it may very well be what most people think, but it is certainly not what CASE is about. CASE is not about pretty pictures, it is about design methodology. A design methodology may or may not include elements of graphical design.

Lets think about another form of design: architecture. Who would deny that some absolutely fabulous buildings were built in the past with no formal design? I don't think anyone would. But who today would start building without blueprints? Does this mean that blueprints are the only valid method of designing a building? Certainly not. Does it mean that blueprints are the only important aspect of designing a building? Certainly not.

Similiar to blue prints, CASE tools simply help visualize what needs to be designed. Advanced CASE tools will also do some of the translation from design to code and allow changes in code to be reflected in design.

I also applaud Simon Kinahan for raising a very valid aspect of quality engineering, functional design. IMO, no where near enough programmers employ functional programming techniques, so there is no formal method to prove that the results of the programming are what they ought to be. To many programmers rely on testing to see if the results of the programming are what they are expected to be instead of doing the math to demonstrate that the results are not only what the are expected to be but are also answering the correct questions.

I am reminded of the system in Jurassic Park that everyone was assuming was counting the entire population of dinosaurs when in reality it was counting the entire population of dinosaurs up to and including a maximum amount. In a functionally designed program one uses mathematics to prove that the results are answering the correct question. The flip side of this is the question of whether or not such surety is worth the time and effort to retrain the IT staff to think and design in an altogether different manner than they are used to.

[ Parent ]

CASE is for bureacracies (3.45 / 11) (#12)
by Kaa on Tue Oct 03, 2000 at 01:28:38 PM EST

As I see it, CASE tools are a godsent when you have 47 programmers in five and a half departments trying to make a system which works. In other words, CASE is good for managing large projects with multiple programmers trying to implement a fixed design spec.

Open Source is different. Most everything at least starts by being written by one or two or three people. Software written by so few people does not need CASE tools. Later, if the project is successful and many, many programmers start to contribute, they typically pick a chunk, improve it (from their point of view) and submit it back. Trying to impose CASE discipline on these volunteers is likely just to drive them away.

Basically, CASE is needed if both conditions are met:

(1) Large project, many, many programmers
(2) Programmers can be forced to do things the way CASE wants them to

Early Open Source projects fail on both, late Open Source projects fail on second.



Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.


Re: CASE is for bureacracies (none / 0) (#33)
by Paul Johnson on Thu Oct 05, 2000 at 11:12:11 AM EST

As I see it, CASE tools are a godsent when you have 47 programmers in five and a half departments trying to make a system which works.

What about an OSS project which has 47 programmers in five and a half countries?

Paul
You are lost in a twisty maze of little standards, all different.
[ Parent ]

(3.57 / 7) (#13)
by damien on Tue Oct 03, 2000 at 01:32:43 PM EST

My experience with CASE tools is that they try to make the easy parts of coding easier, and don't help with the hard parts. They can rapidly generate piles of skeletal classes, but filling in the middle is still left to the programmer.

The thing is, writing the skeleton isn't what takes time. When I code, my time goes into documentation and implementation -- areas which CASE tools don't make significantly faster.

These tools might be handy for people doing GUI design. I don't do much GUI work these days, so I can't comment there. I do know that I can put together a window faster in Tcl/Tk than I can with any GUI editor I have used.

Other features, such as debugging and source control, are available from simpler tools that work well. CVS is a solid version control system; there are times when I wish it had better support for file moves, but it suits my needs 99% of the time. I've found that often more feature-rich tools consume more time than they save. (ClearCase is a notable case in point.)

All of the above holds only for the type of work I do. Other programmers, working on different tasks, may find pretty CASE tools more useful. I'll be sticking with XEmacs (and the godly viper-mode), gdb, and CVS, though.

-Damien

CASE isn't about GUI design (3.00 / 3) (#17)
by Anonymous 242 on Tue Oct 03, 2000 at 02:41:31 PM EST

If you are under the impression that CASE is about GUI design, I think you don't quite undrstand what CASE is all about.

CASE is not about painting screens and connecting widgets to SQL queries.

CASE is about engineering a program by design and having the tools to translate that design to code. CASE, when used correctly, does in fact help with documentation and implementation. Documentation generation will be part of a sufficiently advanced CASE tool.

You are on to something with this statement, though:

I've found that often more feature-rich tools consume more time than they save.

An effort to "save time" with CASE tools is doomed to failure because CASE isn't about saving time, its about using an entirely different development paradigm. Moving to a different paradigm will always have somewhat of a steep learning curve. This is part of the reason so few great C programmers make good C++ programmers. You can be an adequate C++ programmer and think in C, but to be a good C++ programmer you have to train yourself to think the C++ way. The same holds true for CASE. You have to think differently through the entire process to use CASE to its fullest advantage and learning to think differently takes time and energy.

How often is this cost of learning a different paradigm truly worth the cost? Most developers (especially open source developers) seem to be saying the cost is very rarely worth the rewards in regards to CASE.

And yet I find myself wondering if the words of CS Lewis as applied to the Christian faith are not applicable to CASE. His words were something to the effect of: Christianity is not so much tried and found lacking as it is never tried. How many programmers try immersing themselves in whatever design philosophy their case tool is based on vs. how many programmers simply try to save time and/or effort?

[ Parent ]

I've got a whole host of reasons. (3.50 / 10) (#14)
by trhurler on Tue Oct 03, 2000 at 01:38:06 PM EST

1) There are no free CASE tools, and the expertise to build them, while not beyond free software developers, certainly is specialized and not what most of us know best.

2) CASE tools are the wrong tool for most of us. We aren't paying programmers, so it isn't worth it to invest time and/or money into a tool to make newbies' lives easier. In fact, if the newbies can't learn in the current environment, they probably aren't needed.

3) CASE tools are the product of software engineering, which is viewed by most of the crowd I know as pretty useless for anything but building reliable antilock brake systems and so forth.

4) Programming is fun. For programmers, CASE is generally NOT fun; charts and diagrams are for marketroids. Free software people are usually in it for the enjoyment, the ego boost, the useful results, and so on - but they wouldn't do it if they weren't having a good time.

5) Read the original code Netscape released as "mozilla." Or try to. Then read code produced by a good bunch of free software geeks. I seriously doubt Netscape used/uses CASE tools, but regardless, you can see why they might benefit: frankly, they're pushing too hard, too fast, and the results suck wind. We don't have that problem, and when we do, the project in question just dies quietly and the world goes on as usual.

6) Since most of us are somewhat perfectionist and "backwards," we tend to reject just about anything new for some time. Integrated development environments, CASE tools, and so on will be a long time coming for us, if they ever do. Partially, this is because of inertia. Partially it is because the tools suck. (Yes, they do. I don't want to hear about your favorite; they all suck, and they will for at least another decade. It takes time to produce something as beautiful as vi, make, and cc:) Partially it is because most of us still think GUIs are for getting lots of xterms on one screen.

A better question is, why is it so important to you how other people choose to do their development? They're obviously succeeding in huge numbers, and the quality of their work, when it succeeds, is generally quite high. They don't appear to want or need CASE tools, formal methods, or other "modern" amenities, and if they end up needing them, they're bright enough to figure that out for themselves.

--
'God dammit, your posts make me hard.' --LilDebbie

Re: I've got a whole host of reasons. (4.33 / 3) (#16)
by slambo on Tue Oct 03, 2000 at 02:29:25 PM EST

I agree with most of your points, but there is part of your fourth point that isn't quite right for me:
... For programmers, CASE is generally NOT fun; charts and diagrams are for marketroids. ...
In working through several projects, I've found charts and diagrams to be of immense help in visualizing the data, structures and modules. One of the first parts of my current project, Genes (http://genes.sourceforge.net) was to build an ERD for the database. For a project like this, you have to know how the data is modeled before you can build an effective interface.

At work, building some new libraries based on the GoF patterns, creating a diagram of the class hierarchy first made writing the code almost overly simple.

So, pretty pictures have their values to developers as well as management. I haven't used any CASE tools in my own projects yet because of the cost involved in purchasing a license. If there were free CASE tools of sufficient quality (that I knew of), I probably would be using them.
--
Sean Lamb
"A day without laughter is a day wasted." -- Groucho Marx
[ Parent ]

Re: I've got a whole host of reasons. (4.00 / 1) (#18)
by Anonymous 242 on Tue Oct 03, 2000 at 03:23:25 PM EST

There are no free CASE tools

The two I know of are Argo and Venus. I found these two about two years ago. There may or may not be more by now.

CASE tools are the wrong tool for most of us. We aren't paying programmers, so it isn't worth it to invest time and/or money into a tool to make newbies' lives easier. In fact, if the newbies can't learn in the current environment, they probably aren't needed.

The flawed assumption here is that CASE tools are for project newbies. This is not the <wince> case. </wince> The diagrams provided by CASE tools may make it easier for project newbies to understand the code, but that is an unintentional side effect. The purpose of CASE is to make engineering software easier, just as the purpose of CAD/CAM is to make mechanical engineering easier.

CASE tools are the product of software engineering, which is viewed by most of the crowd I know as pretty useless for anything but building reliable antilock brake systems and so forth.

This is the core of the matter. For most programmers, why engineer a solution when a good enough solution can be organically developed? CASE is overkill for a good many projects and often even if CASE is not overkill, it may not be worth the programmers time and effort to learn CASE a project it will help with.

Programming is fun. For programmers, CASE is generally NOT fun;

I would beg to differ, but I'm a rather sick puppy. For most people playing instruments is more fun than writing music in assembler, but then comes along a band like Mental Destruction and puts out a full length CD entirely coded by hand. But, for the most part I agree with your sentiment, most programmers do not find using CASE tools to be fun. I think this is mostly due to needing to learn to think differently to be truly effective with CASE tools. I've met many people that can think easily in C/C++/Perl/Whatever but very few that think easily in some design notation.

Read the original code Netscape released as "mozilla." Or try to. Then read code produced by a good bunch of free software geeks. I seriously doubt Netscape used/uses CASE tools, but regardless, you can see why they might benefit: frankly, they're pushing too hard, too fast, and the results suck wind. We don't have that problem, and when we do, the project in question just dies quietly and the world goes on as usual.

I'm not sure I understand this point. Netcape seems to have suffered from bad management that resulted in unusable code. I think such would have been the case even if they had used CASE. CASE doesn't ensure a good design, CASE only makes it easier to express a design.

Since most of us are somewhat perfectionist and "backwards," we tend to reject just about anything new for some time. Integrated development environments, CASE tools, and so on will be a long time coming for us, if they ever do. Partially, this is because of inertia. Partially it is because the tools suck.

I heartedly agree with you here. You hit the nail right on the head. How old is C++? And only in the last couple of years have open source programmers started heavily using C++. Part of the problem was inertia, on *nix C was the lingua franca for binaries. The other part of the problem was the lack of a good free C++ compiler. Today, while C projects are still much more common, C++ is no longer a second class citizen in the open software world. Part of this is due to the entry of a new generation of programmers and part of it is because the GNU C++ compiler sucks less than it used to.

A better question is, why is it so important to you how other people choose to do their development?

This is indeed a good question and the reasons why you reject this question as valid are very poor.

They're obviously succeeding in huge numbers, and the quality of their work, when it succeeds, is generally quite high.

The large numbers of successful open source projects are the net result of a much larger number of open source projects that start and fail. Many of these failures may not have crashed and burned under a different paradigm.

I don't think that CASE is the end all and be all of software design. Neither do I think the typical hand coded throw-away proto-type model is in and of itself a bad thing. The two models are two different ways of approaching development and both have their time and place. Personally, I think (all other things being equal) a project that is engineered instead of developed stands a better chance of success. But being engineered doesn't guarantee a good design and being organinally developed does not guarantee a bad design. CASE tools, do however, shift the focus to the design which, for the most part is a good thing.

Have a day,

-l

[ Parent ]

Re: I've got a whole host of reasons. (4.00 / 1) (#27)
by trhurler on Tue Oct 03, 2000 at 05:38:28 PM EST

The flawed assumption here is that CASE tools are for project newbies. This is not the <wince> case. </wince>
I know this; what I meant was that the effect this might well have on open source projects, which tend to attract lots of clueless idiots, would be to enable them to do things they aren't any good at. I know several projects that are(unofficially, of course) downright hostile to newbies who actually want to write code, for the simple reason that they can't produce goods of sufficient quality. Making it easier for them isn't what is wanted.
I agree with your sentiment, most programmers do not find using CASE tools to be fun.
And I agree with your(snipped) assertion that some programmers like CASE tools; my point was merely that -most- seem not to. I know I don't like the thought of using anything of the sort that I've ever seen.
I'm not sure I understand this point. Netcape seems to have suffered from bad management that resulted in unusable code.
Oh, they certainly had bad management, but that wasn't their only problem. They suffered Microsoft Syndrome. This is the disorder in which you try to both grow your company and develop software at such an incredible pace that nobody really knows what is going on, including management, regardless of how competent or incompetent any of them may be. CASE tools can probably help -somewhat- by providing an easier-to-view big picture. Open source projects just don't do stupid things like growing the development team at 1000% per month, though, so they lack this incentive to use CASE tools.
The large numbers of successful open source projects are the net result of a much larger number of open source projects that start and fail. Many of these failures may not have crashed and burned under a different paradigm.
Most of the failures I see are projects that suffered from lack of expertise, lack of dedication, or lack of time. A few more died of being poor ideas in the first place. Very few ever get big enough to fail on account of the lack of proper design without acquiring sufficient importance and developer-count to fix the problems, no matter how severe they may be, or in many cases, just start over. In fact, starting over to clean up mistakes and historical baggage is official policy for some projects.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
all good points (none / 0) (#29)
by Anonymous 242 on Tue Oct 03, 2000 at 07:10:39 PM EST

I'm not in 100% agreement with all of them, but thanks for the discussion.

-l

[ Parent ]

CASE sounds good... (3.66 / 3) (#15)
by mandomania on Tue Oct 03, 2000 at 01:58:25 PM EST

To qualify, I've never worked on an open source project, so I don't really know how the programming infrastructure works. However, CASE tools sound like a really good way for budding programmers to come up to speed on open source projects. A good UML diagram of a class or two that needs work would be of infinite benefit to programmers who are new to a project.

I'm not sure, however, I would trust code generated by these tools. Besides, that's not really the point of working on open source projects, or so it seems to me. I believe most people work on open source projects because 1) they feel they can fill a software need in the community and 2) it gives them a concentrated project/excuse to code.

In the case of open source projects, I would think that some decent modeling software would be of great benefit, but anything further would simply stifle the project.

--
Mando
The Code is Sound.
Thought-provoking course.... (3.33 / 3) (#19)
by WWWWolf on Tue Oct 03, 2000 at 03:35:25 PM EST

"Who am I?"

"Why am I?"

"And why the heck I made this specification, when in the same time used I would have developed the same thing to a working state - using Knuth's Literate Programming methods, in INTERCAL, in five different approaches?"

(from the afterword of my Introduction To Systems Design course assignment documentation =)

I'm studying in Department of Information Processing Science in University of Oulu, Finland. I'm aiming for Master of Sciences grade, which is called "Master of Philosophy" here for some reason I don't know. And if anything, the systems design course made me think of deep matters, so maybe the name of the grade is justified. =)

Well, the above three questions were not the ones that actually came into my mind. What I was thinking was this: Is design and documentation evil? I've got that fateful and commin attitude that Real Guys Just Code. But I found out that my answer to that question was: No, it's not evil. Yes, it's required. Direly required.

Personally, I don't see design and documentation of programs as a bad thing. Good programs are well designed; Good programs are well documented. To be honest, I didn't want to write programs using, say, GTK+'s glib because there was no documentation. Well, the header file was fortunately informative...

It was the same weekend I had to read the source of XMMS to figure out how to make plugins... =) If the hackers would bother document and design the stuff better, the OSS world would be a lot clearer place and easier for the newbies to sink into.

Design is good. The lecturer who's now trying to teach us UML said that all programmers design - if you don't do it with CASE tools or in paper, you'll do it in your head. So, don't hesitate to do make proper designs - because if your memory fails, at least you have something written down, in addition of that complicated and huge program of yours.

Documentation is good. If you can put those designs of yours to paper, more people can undestand them. If you want the people to join hacking, make it clear and make at least some accurate documentation...

I don't know if CASE tools themselves are useful to hackers, but I believe they would be of value if people would know how to use them. And there are some open-source CASE tools available; I made the above-mentioned assignment documentation with GNU Dia and LyX. (The course had Yourdon MSA stuff, but Dia can handle UML too.)

At very least, I'd recommend to document with something. Maybe not UML or MSA. Even simple drawings and some Extremely Helpful Comments in the code that can be extracted with a documentation generation tool.

-- Weyfour WWWWolf, a lupine technomancer from the cold north...


CASE tools? First understand the patterns... (3.00 / 6) (#20)
by chewie on Tue Oct 03, 2000 at 03:46:47 PM EST

This is a plug for a book I find quite invaluable when designing software, especially for C++, Python, or other language for OO style of development. It introduced me to a whole new world of design and gave me a vocabulary to use when describing complex design problems. It is a serious recommendation for anyone who wants to become a better software designer. Of course, couple this with UML and ArgoUML, and you've got a definite winner!

Gamma, E., et.al., "Design Patterns. Elements of Resuable Object-Oriented Software", 1995, Addison-Wesley. ISBN 0-201-63361. (link).
assert(expired(knowledge)); /* core dump */

Definition problem (2.66 / 3) (#25)
by Smiling Dragon on Tue Oct 03, 2000 at 05:21:43 PM EST

Ok, I'm being horribly naughty and commenting on somthing I haven't read properly (weeeelll, I've got the attention span of a goldfish on speed in the morning) Latching onto one of the lines: > So this brings me back to my original question: > why don't hackers use CASE? The definition I tend to think of when someone says hacking is "rapid developement of small projects" that kinda goes against the idea of case. Teeny niggle about teeny part but yeah, see above :)
-- Sometimes understanding is the booby prize - Neal Stephenson
Definition problem - ah bugger! (none / 0) (#26)
by Smiling Dragon on Tue Oct 03, 2000 at 05:25:14 PM EST

Damn, shoulda paid more attention to the choice of formatting... let's try that again...
- - Post starts here - -
Ok, I'm being horribly naughty and commenting on somthing I haven't read properly (weeeelll, I've got the attention span of a goldfish on speed in the morning)

Latching onto one of the lines:
> So this brings me back to my original question:
> why don't hackers use CASE?

The definition I tend to think of when someone says hacking is "rapid developement of small projects" that kinda goes against the idea of case.

Teeny niggle about teeny part but yeah, see above :)
- - Post ends here - -


-- Sometimes understanding is the booby prize - Neal Stephenson
[ Parent ]
A CASE success story (4.60 / 5) (#28)
by Maniac on Tue Oct 03, 2000 at 05:54:43 PM EST

Let me describe a situation where we used CASE tools successfully. It is not a situation that is common in open source. As a success story, it should help define when CASE tools should be used.

APPLICATION AREA: Aircraft maintenance trainer

ORIGINAL CONCEPT

Our original concept was that we would get drawings or block diagrams from the aircraft manufacturer, make similar diagrams in a CASE too, and generate FORTRAN code to simulate that aircraft system.

ORIGINAL IMPLEMENTATION

Time frame - early to mid 1980's.

We selected a Symbolics Lisp Machine as the workstation platform. There were several perceived advantages to using Lisp with automatic garbage collection and powerful graphics tool in implementing what we called Model Builder. The user would draw a data flow diagram using a set of basic blocks to represent a portion of the system. The basic blocks included a summer, limiter, selection (like a switch), function, array or table lookup, and sub-models. Data types were limited to integer, real, and character to match FORTRAN implementations.

The models were stored on a file server (actually a VAX). The FORTRAN code was generated by the back end program running on the VAX. You could run the model in a test environment on the VAX. You could run the cross compiler (to 286's) and download it to the target machine for testing as well. Fixes had to be made on the workstation.

This system actually worked pretty good. We believe we saved about 3x the cost of developing the tools in the generated code for our simulators. The code always compiled cleanly and interfaces were enforced automatically. We were also able to do most of our testing on the VAX & skip a lot of painful testing on the target hardware.

Some drawbacks we noted were:

  • it took more time to fix problems (go to the workstation, make the change, run the back end, retest) than with FORTRAN source code.
  • the source code was awful - about 5x the size of hand generated code. It ran fast though so it just impacted memory usage.
  • you had to ignore the generated code & use the diagrams.
  • several good software developers were extremely bad modellers
  • since it was our own tool, we had to keep maintaining it
  • about 1/3rd of the diagrams were "control flow" - hard to implement in a data flow tool
Overall though, it was considered a success.

SECOND IMPLEMENTATION

Time frame - late 1980's

We used the Model Builder for a few years by itself but were especially concerned about a few of the drawbacks. PC's were also starting to become inexpensive and more powerful. We did a second set of tools under the name Magic . The front end was Excelerator RTS, a PC based CASE tool. The back end was a new code generator that analyzed a complete set of diagrams and with a few configuration files, generated the FORTRAN for a complete simulator.

Several features included:

  • A block in a Magic data flow diagram could be a Model Builder model, another Magic diagram, or a hand coded model.
  • Control flow diagrams addressed a major Model Builder drawback.
  • We supported the concept of a stub model where a section of the system could be replaced by a stub (consume inputs, benign outputs)
  • We could distribute the simulation across several CPU's - data was copied whenever it changed value.
  • The quality of code was much higher - much closer to hand coded standards
  • Using the data dictionary, we were able to capture more information to aid in diagnosing problems and for documentation.
This was also considered a success - our productivity using both tools went up. We still had the problem of increased cycle time for fixes.

POST SCRIPT

Looking back, these tools solved a specific problem - code generation for a specific application domain. They were both successful as measured by the productivity of our staff (fewer hours needed to implement a system than otherwise needed). As a company, we were successful when using them.

However, neither of these tools can be used today - they were both locked into products that lost in the market place. Would I do something like them today - sure, if I had enough of that kind of work to do. Should there be an open source project to develop something like these tools - I'm not sure. Is there a critical mass for something like this?

Ramble: UML is evil. (3.33 / 3) (#30)
by ksandstr on Tue Oct 03, 2000 at 08:03:16 PM EST

I tried, a few weeks ago, to make a diagram about a recent OO thingy I wrote (a prototype 3d engine, not released, etc) in UML using Dia. About halfway through I realized that just by looking at the diagram you couldn't actually tell how the different parts of the program (classes, etc) would really work together. Sure, you could maybe put together a few use cases but that wouldn't really give you a good mental image of how the main scene graph is going to look like in the typical case. In the end I gave up and wrote the class descriptions and all that stuff in the header files in a format that could be extracted with 30 lines of perl. The descriptions turned out to be much more informative than some UML diagram.

If you ask me, UML is just something you do battle with in order to satisfy the suits. It's not of much use in getting others up to speed on how this system works since it's not the actual code (or even documentation thereof); reading the code and/or the inline documentation is still better than looking at some diagram that probably doesn't have anything to do with how the code base looks right now.

The very concept of a "CASE tool" sounds fishy to me. Why would you want a frickin' program to write class skeletons for you? When you finally have a tool that's strong enough to express every possible relationship and state/transition combination between 2 or more objects, you either have a new language or are reimplementing an older and better known language, only not as well.

Or maybe I'm just being old school in a "if you can't gain undestanding of the system by studying the code, fuck off" kind of way. In my opinion, that's the opensource way ("learn by tinkering" is the way to go).



Fin.
Why don't Open Source programmers use CASE? | 33 comments (25 topical, 8 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!