Slashdot Mirror
High Integrity Software
What is SPARK? It's a language, a subset of Ada that will run on any Ada compiler, with extensions that automated tools can analyze to prove the correctness of programs. As the author says in his Preface, "I would like my programs to work without spending ages debugging the wretched things." SPARK is designed to minimize debugging time (which averages 50% of a project's duration in most cases).
SPARK relies on Ada's idea of "programming by contract," which separates the ability to describe a software interface (the contract) from its implementation (the code). This permits each to be compiled and analyzed separately.
It specifically attempts to insure the program is correct as built, in contrast to modern Agile methods which stress cranking a lot of code fast and then making it work via testing. Though Agility is appealing in some areas, I believe that, especially for safety critical system, focus on careful design and implementation beats a code-centric view hands down.
SPARK mandates adding numerous instrumentation constructs to the code for the sake of analysis. An example from the book:
Procedure Add(X: In Integer);
--#global in out Total;
--#post Total=Total~ + X;
--#pre X > 0;
The procedure definition statement is pure Ada, but the following three statements SPARK-specific tags. The first tells the analysis tool that the only global used is Total, and that it's both an input and output variable. The next tag tells the tool how the procedure will use and modify Total. Finally a precondition is specified for the passed argument X.
Wow! Sounds like a TON of work! Not only do we have to write all of the normal code, we're also constructing an almost parallel pseudo-execution stream for the analysis tool. But isn't this what we do (much more crudely) when building unit tests? In effect we're putting the system specification into the code, in a clear manner that the tool can use to automatically check against the code. What a powerful and interesting idea!
And it's similar to some approaches we already use, like strong typing and function prototyping (though God knows C mandates nothing and encourages any level of software anarchy).
There's no dynamic memory usage in SPARK -- not that malloc() is inherently evil, but because use of those sorts of constructs can't be automatically analyzed. SPARK's philosophy is one of provable correctness. Again -- WOW!
SPARK isn't perfect, of course. It's possible for a code terrorist to cheat the language, defining, for instance, that all globals are used everywhere as in and out parameters. A good program of code inspections would serve as a valuable deterrent to lazy abuse. And it is very wordy; in some cases the excess of instrumentation seems to make the software less readable. Yet SPARK is still concise compared to, say, the specifications document. Where C allows a starkness that makes code incomprehensible, SPARK lies in a domain between absolute computerese and some level of embedded specification.
The book has some flaws: it assumes the reader knows Ada, or can at least stumble through the language. That's not a valid assumption any more. And I'd like to see real-life examples of SPARK's successes, though there's more info on that at www.sparkada.com.
I found myself making hundreds of comments and annotations in the book, underlining powerful points and turning down corners of pages I wanted to reread and think about more deeply.
A great deal of the book covers SPARK's syntax and the use of the automated analysis tools. If you're not planning to actually use the language, your eyes may glaze over in these chapters. But Part 1 of the tome, the first 80 pages which describes the philosophy and fundamentals of the language and the tools, is breathtaking. I'd love to see Mr. Barnes publish just this section as a manifesto of sorts, a document for advocates of great software to rally around. For I fear the real issue facing software development today is a focus on code ueber alles, versus creating provably correct code from the outset.
You can purchase High Integrity Software from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
The very first page quotes C.A.R Hoare's famous and profound statement
Not to be confused with C.A.M. Hoare's famous and profound statement: "Want to see my boobies?"
Or do they sit around thinking of methodologies to write books about?
Those who can, do, those who can't, teach?
Seriously, I'm not one to complain, but this isn't a review; it's a guy saying "WOW" repeatedly.
"High Integrity Software"
SCO should adopt that as their motto.
Trolling is a art,
..if the contract itself is wrong?
Now, is there a language to ensure that your boss asks you to program the right thing?
In General, if you want info, RTFA. However for those of you who just want some links to check things out quickly:
Hereis a PDF that contains samble chapters of the book reviewed.
Also from the same site is the following text and links for those of you wanting "real world examples":
"Industrial Experience with SPARK (PDF 234kb) Dr. Roderick Chapman, Praxis Critical Systems Limted. Presented at ACM SigAda 2000 conference. This paper discusses three large, real-world projects (C130J, SHOLIS and the MULTOS CA) where SPARK has made a contribution to meeting stringent software engineering standards. "
The Army reading list
The Army reading list
SPARK is used heavily in the safety critical software in the Eurofighter amongst other projects. It is a complete pain to type all of the annotation, takes forever to run the tool and it very rarely comes up with any real problems in the code. I would pay good money never to have to go near it again. It was used to meet contractual requirements, not engineering requirements.
One neat trick is to generate a large proportion of the annotation from the output error messages. Sort of defeats using the tool though but since it doesn't find much anyway the time freed up can be used to do some real testing.
This seems rather a waste of time. You either first describe exactly what the code does, then write the code, or you write a simplification of what the code does, then the code.
In the first case, you write the exact same thing twice, in different languages. That sounds like an immense waste of time to me.
In the second case, your specification does not cover every aspect, which introduces loopholes, defeating the purpose of the contract.
In either case, you get in trouble if there are errors in the contract.
Please correct me if I got my facts wrong.
The best available modern system for formal verification is the Extended Static Checking system for Java developed at DEC SRL. This was developed at DEC before HP shut down that research operation. It's still available as a free download.
What all this machinery does is put teeth into "design by contract". With systems like this, you can tell if a function implements its contract, and you can tell if a caller complies with the contract of each thing they call. Before running the program.
Developing in this mode means spending forever getting rid of the static analysis errors. Then, the program usually just runs. That's exactly what you want for embedded systems. But it's painful for low-grade programming like web site development, where "cosmetic errors" are tolerable and time-to-market matters more than correctness.
Ok, I know nothing about SPARK, so forgive my ignorance.
me neither, me too...
my understanding is that the contract has hard requirements on specific input and specific output for results. all of which are defined prior to executing that code. something like "we require an incomming integer with a value that is between zero and fifteen. we gaurantee that an integer value will be returned that is either zero or one"
with a public class interface you can write a peice of code that does this, but it won't gaurantee anything. it's up to the developer to exhaustively test all situations and make sure that it happens. in a contract based language, i would guess that the program either won't compile, won't run, or will fail in obvious ways in the development stage if the requirements are not met. i'm not sure how they handle requirements that aren't met.
Crappy software is all around us (obviously). It may not seem like a huge tragedy that, say, Microsoft Windows has so many security problems but the unfortunate reality is that the entire Western Economy heavily relies upon software that is so fragile that fresh installations become compromised within minutes.
Since so much of what we depend on these days is powered by software, I can't help but feel that industrial software development should be taken under the wing of Engineering. Why, you say? Well, professional fields like medicine, law, and engineering associate a duty to public safety with the job, and the regulatory bodies for the professions ensure that individuals who practice irresponsibly will lose their profesional status.
There is no such accountability for software development. Look at Microsoft Windows, that our banks and governments rely upon! I think such a product would be much higher quality if the coders working on it were professionals and had to adhere to Codes; violating their professional duties would mean severe personal consequences. And the firm itself (Microsoft) would be legally liable if it produced a shoddy, dangerous product!
Design By Contract was not invented by SPARK; the name was popularised by Bertrand Meyer, who added it to his "Eiffel" language.
:-).
/anything/ about how sqrt is computed, you can use it in powerful ways. Preconditions and postconditions can't always be as informative as the ones above are (the ones above define everything about the integer sqrt function), but they can give useful information.
Anyhow, DBC is totally distinct from object orientation. In DBC, each component in your software comes with a "contract" that states "if I am called when the _preconditions_ are true, I promise that after I run the _postconditions_ will be true."
The preconditions and postconditions are a group of logical statements, hopefully ones which are useful to your program
Let me give a little example.
function: sqrt( x )
preconditions:
- integer (x)
- positive (x)
postconditions:
- result > 0
- result * result x
Do you see what's happening there? Without knowing
Adding in object orientation support to DBC is a little more complex, but I won't go into that unless asked.
Traditional DBC systems, including Eiffel, couldn't verify your contracts, so most of them would translate the contracts into code, and include that code in the executable; if a contract failed, the code would throw an exception or otherwise fail. SPARK is interesting because it can detect contract failures without running the code; it can also detect when your contracts fail to promise enough.
-Billy
I've been using ada for a little while now. Its actually a good language, with many features that provided self checking code. SPARK seems a bit excessive.
:integer range 0..15) . If x goes above 15 or under 0 during runtime you get a constraint error.
For example ada already had constrained types (x
The ada compiler checks alot of things during compile time that I've never seen before.
One thing I note that the review does not mention is the fact that SPARK is, while Turing-complete, not very much fun to program in. Starting with Ada, a pretty B&D langauge to start with, SPARK removes all the remaining pointy bits, including: "the goto statement, aliasing, default parameters for subprograms (i.e. procedures and functions), side-effects in functions, recursion, tasks, user-defined exceptions, exception handlers and generics" (list taken from here, emphasis mine), plus dynamic allocation, which is mentioned in the review.
:)
/. a while back (which I didn't read). Even if you did read it, read it again.
Basically the only excuse you could possibly have for writing something in SPARK is extremely critical code (ie, if it fails, many people die). Even then I'd be skeptical it would provide much benefit, but at least it would provide some ass-covering ability.
For a alternatve view of the practicality of correctness proofs, see chapter 4 of Peter Guttman's thesis. IIRC there was a book review of it on
"No programming language can save you from yourself."
- Me
Two statements there.
:-). Odd.
I would have been interested if all this instrumentation had been grafted onto a language like Java, or C++. But to have to switch to Ada just to be able to add in instrumentation that helps in code analysis?
Switching languages is a tiny effort compared to the change required to design your code for static validation. The SPARK people strongly recommend against trying to "switch" to SPARK; if you want the benefits, you have to code with it from the start. It's kind of like taking a 100,000 line C program written by 30 programmers over 10 years and trying to "switch" it to C++ -- it's theoretically possible, but in practice it's easier to start over.
And what they did in Ada would have been impossible in C++. It's significant that SPARK code will run EXACTLY the same on all compliant Ada compilers. No platform dependancies, no ambiguities, no undefined behavior... ALWAYS the same. You simply can't possibly define a subset of C++ which would be able to make those promises. I don't know if it would be possible with Java; since there's no formal specification of Java, probably not.
It's also funny that he WOW's at the idea of no dynamic memory allocation...
I felt that way too
The reason they did it is simple, though -- they wanted to be able to set absolute bounds on when a SPARK program will or will not fail (throw an exception). There's no way to do that with dynamic memory allocation as it's defined in Ada and most other languages.
Yes, that's limiting; no argument. But for some problems, particularly ones solvable by programs managing their own memory, the limitation doesn't matter compared to the benefits -- a SPARK program can execute without any runtime support code.
Why not just use a type safe language?
No such thing -- type safety is an uncomputable problem.
If you meant strongly typed, that's easy; Ada was already strongly typed. SPARK just guerantees that the programs will always run the same, and SPARK's verifier guarantees that the types are chosen and described correctly.
-Billy
My last software project ran off with my wife, stole all my money, and crashed my new corvette. Damn! I really could have used this, instead I hired a bunch of Klingon programmers.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
i.e. Y, your sqrt, is no more than X when squared, but increase it by 1 and it is more than X. You require X to be non-negative.
Assuming that your implementation implements an initial guess at Y and then repeatedly increments it, you would specify a loop invariant that shows that your guess at Y (say 'Z') is such that (Z+1)*(Z+1) For more information on what's practicable in a customer-specified system, read the peer-reviewed publications...
Disclaimer: SPARK hacker for 6 years
Adi: Inveterate mathmo, Christian, BOFHlet hubbie and Perl lover.