Tools To Automate Checking of Software Design 128
heck writes "Scientific American describes some of the work to develop tools for examining the design of software for logical inconsistencies. The article is by one of the developers of Alloy, but the article does reference other tools (open and closed source) in development. The author admits that widespread usage of the tools are years away, but it is interesting reading the approach they are taking regarding validation of design."
too hard. (Score:5, Insightful)
Back in the mid-80s I attended a seminar in Atlanta, it was about automated software engineering... and tools and workbenches that would take as input specifications and design parameters and would crank out entire suites of software/applications. (Heck, there was even a new acronym for it, can't remember what it was, but it was a hot, hot, hot button for a few years.) We were pretty much warned our careers were over, automation was here to generate what we as professionals had studied years to create.
It never happened. It never came close to happening. We are as far away today or further from tools that can generate applications transcendentally.
I was skeptical then, I'm skeptical now. Tools like the ones described are useful, but they're not foolproof, and they hardly supplant the intuition and "art" that is programming.
At best tools are an adjunct to the software development process, not to be a replacement for common sense testing and design and code walkthroughs. I could construct many scenarios that logically would be consistent but have no relationship to the desired end of the application, i.e., a logic consistency tool would not detect a problem. Any poorly designed system with these "new" tools applied will merely be rigorously poor systems.
As for the prime example (in the Scientific American article) of the Denver International Airport baggage handling debacle, I doubt logic analysis tools would have had much impact on the success or failure of that effort. I knew people involved in the project, and "logic consistency" in their software was the least of their problems. (I would have loved to been on a team to design and develop that system -- I think it was a cool concept, and ultimately VERY feasible... )
I did get one benefit from the Atlanta Seminar -- I got a football signed by Fran Tarkenton (he was CEO of one of the startup companies fielding a software generating workbench).
Re:too hard. (Score:5, Insightful)
I see one problem with this. (Score:2, Insightful)
software snake oil (Score:4, Insightful)
These tools have very limited applicability (Score:2, Insightful)
Crutch for bad developers (Score:3, Insightful)
It's not going to find everything, let alone fix it. See Turing: the halting problem.
Good Software Design (Score:5, Insightful)
And thus you cannot validate a design because that would require representing a concept and determining if an interface suitably models it. That is HARD. If that were possible you would effectively have a thinking, rationalizing, brain (Artifical Intelligence) in which case you wouldn't be dorking around with validating programs, you would be dynamically generating them.
[1] Frequently people advocate that interfaces are "well defined". That just means there are no holes in the logic of it's use. Personally I think a well defined interface is useless if it does not correctly model a concept. You can always go back and fill in the holes later.
[2] Although this is also when you discover that you didn't get the concept right and need to adjust the interface (hopefully not by much)
Re:too hard. (Score:5, Insightful)
When I was young, stupid and without real-world experience, I also thought UML was crap. However, once you realize that the point of UML is not helping to design, but helping to communicate the design to other developers, it becomes useful (not ground-breaking, not amazing, not neccessary, just useful).
It's like that: when you design a piece of software alone, you can use whatever system you want to model it (keep it all in your memory, write class-structure as pseudo-code etc.). If you need to communicate your design to others, it's good to have a system with defined semantics to formulate the design (visualization is not even the issue here), and one such system is UML; surely not the best, but one that a sufficient number of developers (software engineers, not programmers) are trained to understand.
Lacking such a system of communication, you would first have to explain the meta-model (explain how the description of your design is to be understood) instead of just explaining the design-model itself.
Re:too hard. (Score:3, Insightful)
I vaguely recall that fad as well. A lot of executives were jazzed about the idea, as they seemed to assume that software was rote and procedural anyway. They viewed programmers as simple translators, not realizing that program code doesn't just facilitate the resulting software, but was the software. Regardless of how many tools you devise to commoditize the basic functions of software, the effort required to actually make it is proportional to the complexity of describing its total functionality. You'll just end up having to specify all of the procedures involved, anyway, whether you do it in code or through some meta-coding tool.
By the same token, code checkers can't know what your intentions are for every variable and class relationship. They can tell you if you generate invalid or null variables, or if a function is orphaned, stuff that is strictly boolean. Beyond mistakes like that, you'll have to tell the checker in explicit manners what to look for, negating the benefit of the tool.
We have time saving techniques already. They're called code libraries, design patterns, and error handling.
Re:too hard. (Score:4, Insightful)
at absolute best, it saves you 5 minutes of typing boilerplate class skeletons
The code generation from UML is only supposed to be the class skeletons, and I've got to ask... have you never written an application with more than a handful of classes? The time spent just building the skeletons for some of the applications I've written over the years has taken a helluva lot longer than 5 minutes.
I personally find class diagrams darned useful. I also find use case diagrams useful not because they help the programmer, but because they help to make sure that we correctly understand what the user is asking for.
From reading your post, though, I'm not entirely certain you have actually bothered to learn UML before you started to slam it. You say:
it just doesn't, and never can, portray all the information that text can
Anybody who knows UML knows that an incredible amount of the work is done in text. Sure, you can create state and activity diagrams for your use cases... or you can just attach textual documentation that is typically easier to create and much smaller than state or activity diagrams. This is what you are typically ENCOURAGED to do for anything but the most convoluted process... and when you have a very convoluted process, even text fails.
There are times that it is very useful to have pictures with circles and arrows and a paragraph on the back of each one.
UML is not the best solution for every development project, for very large projects with lots of developers involved, it can certainly make life easier.
Re:Finding Nemo Architecture (Score:2, Insightful)
Re:Finding Nemo Architecture (Score:3, Insightful)
If we get enough small components they can be combined into any piece of software. Eventually we wouldn't need any more components and thus no more software developers.
the key is that phrase "can be combined" although my second pick is "eventually". your finding nemo system will have to be self-organizing because is too vast to have organization imposed from without. You already have that kind of system today anyway. So if you have a self organizing system, two questions are a) how does it arise and b) how do you get it to do what you want. The real-world analogy for this way of thinking is the garden and the gardener. you're thinking wouldn't it be real cool if we had "cells" which you could stack on top of one another and you could have any kind of plant you want, whereas what you want is to be the gardener instead and let the software plants grow by themselves (think of the order of magnitude in scale between a group of cells and the entire garden). And so I think your "eventually" is a really, really, really long time.
Re:Good Software Design (Score:2, Insightful)
A well defined interface means that if you build 1 million holes in a plank and I deliver 1 million pegs, when they "meet" they fit.
A square hole and a round hole, one 1 inch in diameter and one 1 foot wide, all of them model the concept, but are utterly useless.
You can always go back and fill in the holes later.
No you cannot, otherwise we would all use Dvorak keyboards, not this stupid Qwerty. And we would have had HDTV 15 years ago. And...
Thank you! (Score:1, Insightful)
Tools that make sure programs are self-consistent are good!
What's the point of having testing and real world trials if you're programming doesn't even agree with itself?