Map
Index
Random
Help
th

QuoteRef: tretJ9_2001

topics > all references > ThesaHelp: references t-z



Topic:
formal methods and languages
Topic:
safety critical systems
Topic:
automation
Topic:
transformation of programs
Group:
exception handling
Group:
testing
Topic:
testing testing
Topic:
automated tests of specifications and designs
Topic:
limitations of formalism
Topic:
program proving is infeasible
Topic:
executable code from specifications and designs
Topic:
software models of reality
Topic:
programming style
Topic:
good requirement specifications
Group:
programming notation
Topic:
software metrics
Topic:
software review

Reference

Tretman, J., Wijbrans, K., Chaudron, M., "Software engineering for formal methods: The development of a storm surge barrier control system. Revisiting seven myths of formal methods", Formal Methods in System Design, 19, 2, pp. 195-215, September 2001. Google

Quotations
abstract ;;Quote: used formal methods for BOS, the automated control system for Rotterdam's movable dam; highest safety integrity level; completed on time and within budget
197 ;;Quote: automated control needed for a highly reliable storm surge barrier; humans have one in a thousand failure probability for complex tasks
200 ;;Quote: validated BOS's communication protocol with PROMELA and SPIN; identified an unsafe situation where only one door closed; intuitive chart of message sequence
202 ;;Quote: BOS used formal Z specifications and natural language for detailed design; checked consistency, types, completeness; verified postconditions and invariants for highly critical subsystems
202 ;;Quote: systematic coding from formal detailed design specifications; mapped Z specifications to code; pre- and post-conditions and invariants as assertions
202+;;Quote: use one pattern for reporting errors and recovering failed processes
202+;;Quote: over half of system for simulators, test systems, and supporting software
203 ;;Quote: derived test cases from formal specification; tested each precondition and postcondition; also white-box testing; only three faults during operation; acceptance testing found cosmetic faults
207 ;;Quote: use formal methods to verify a design instead of proving correctness; forces engineers to be precise about details; resolves differences of interpretation between implementers and testers
note ;;Quote: program proving and automatic derivation of code from formal specifications are not important; e.g., implementation of formal specifications caused few errors
209 ;;Quote: formal methods do not help with conceptual models and high-level structuring; both require experience; formal specification gives a false feeling of confidence
209 ;;Quote: need specification standards with pragmatics, formating, naming conventions, language restrictions
209 ;;Quote: a simple error in Z can lead to a correct specification with a completely different meanings; e.g., forgetting a prime symbol ' to indicate the new state
211 ;;Quote: the length of a Z specification corresponds to the testing and development effort; useful for scheduling
211 ;;Quote: formal design specification allows test construction concurrently with coding; ready to test when coding finished
211+;;Quote: testers are effective reviewers of formal design specifications; they use the specifications to write their tests
note ;;Quote: formal methods were used successfully; all of the software engineers found them useful
213 ;;Quote: should have formalized the functional specification as well as the technical design; found problems, errors, ambiguities, and inconsistencies

Related Topics up

Topic: formal methods and languages (53 items)
Topic: safety critical systems (32 items)
Topic: automation (15 items)
Topic: transformation of programs (27 items)
Group: exception handling   (12 topics, 314 quotes)
Group: testing   (18 topics, 557 quotes)
Topic: testing testing (13 items)
Topic: automated tests of specifications and designs (12 items)
Topic: limitations of formalism (93 items)
Topic: program proving is infeasible (47 items)
Topic: executable code from specifications and designs (18 items)
Topic: software models of reality (24 items)
Topic: programming style (47 items)
Topic: good requirement specifications (36 items)
Group: programming notation   (14 topics, 221 quotes)
Topic: software metrics (32 items)
Topic: software review (80 items)

Collected barberCB 1/05
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.