Date: Wed, 24 Nov 1999 17:33:56 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jcm@dogma.freebsd-uk.eu.org (Jonathon McKitrick) Cc: chat@FreeBSD.ORG Subject: Re: RAD and CASE for Unix Message-ID: <199911241733.KAA17679@usr08.primenet.com> In-Reply-To: <Pine.BSF.4.02A.9911231916420.58822-100000@dogma.freebsd-uk.eu.org> from "Jonathon McKitrick" at Nov 23, 99 07:21:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Question: When Unix starts getting its fair share of Rapid Application > Development tools and Computer Aided Software Engineering tools, (this has > already begun in KDEveloper and others, i believe), would you expect the > resulting software to be more, less, or equally stable when compared to > similar products running on Windows? Are we going to see an avalanche of > bug-infested bloatware ? RAD is a path to bug-infested bloatware, if it is not used properly, since it results in user interfaces being designed before the guts have been designed, and anything that does that will result in an incomplete mapping of the problem space. CASE tools are a different matter, particularly those which specify interfaces and object relationships, and do so in a high level way, such as by allowing the creation of design patterns using UML as an implementation tool. Such tools can generate class definitions for OO languages (and even non-OO languages, like C: think X widgets) that can be used as a basis for implementation, after the abstract relationship between objects has been codified in the design of the objects themselves. Rational Rose is a (poor) example of what such a tool could be. CASE can also support testing and documentation efforts, as well as literate programming. Though it is $50,000 a seat, I think that the "BattleMap" CASE tool is excellent; it enforces literate programming, and does a full branch-path analysis on the code, which can effectively be used to automate the generation of code coverage test cases. The literate programming aspect allows you to test implementation vs. specification, seperate from the idea of simple code coverage; this ensures that the specification and the documentation for the applciation match what the application really does. The "BattleMap" tool runs on Solaris and other platforms; it does _not_ run on Windows platforms. Test tools like "Purify" are somewhere in the middle. Note that "Purify" relies on the underlying OS unmapping page zero in order to catch pointer dereferences, and on a tightly controlled per process virtual address space to catch things going off into the weeds. Purify could not perform nearly as well on Windows systems because of this (and would have problems on Linux, due to NULL pointers to standard functions not being fatal, as they should be, in many places in the Linux libc). Visual C++ and Visual Basic, as well as most Java IDE tools, are not what I would call CASE tools, since they do not assist software engineering, they only assist programming, which is something very different. Consider that if we had a UML model of the FreeBSD VM system, and were able to validate implementation vs. design, we would be able to quickly and easily identify and then eliminate the VM bugs that have haunted FreeBSD for years now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911241733.KAA17679>