You say 'JML' ? Wikipedia (en)

PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Mon, 06 Jan 2014 09:58:42 UTC Contents

Articles 1 5 10 References Article Sources and Contributors 15 Image Sources, Licenses and Contributors 16 Article Licenses License 17 Java Modeling Language 1 Java Modeling Language

The Java Modeling Language (JML) is a specification language for Java programs, using Hoare style pre- and and invariants, that follows the design by contract paradigm. Specifications are written as Java annotation comments to the source files, which hence can be compiled with any Java compiler. Various verification tools, such as a runtime assertion checker and the Extended Static Checker (ESC/Java) aid development.

Overview JML is a behavioural interface specification language for Java modules. JML provides semantics to formally describe the behavior of a Java module, preventing ambiguity with regard to the module designers' intentions. JML inherits ideas from Eiffel, Larch and the Refinement Calculus, with the goal of providing rigorous formal semantics while still being accessible to any Java programmer. Various tools are available that make use of JML's behavioral specifications. Because specifications can be written as annotations in Java program files, or stored in separate specification files, Java modules with JML specifications can be compiled unchanged with any Java compiler.

Syntax JML specifications are added to Java code in the form of annotations in comments. Java comments are interpreted as JML annotations when they begin with an @ sign. That is, comments of the form

//@

or

/*@ @*/

Basic JML syntax provides the following keywords requires Defines a on the method that follows. ensures Defines a on the method that follows. signals Defines a postcondition for when a given Exception is thrown by the method that follows. signals_only Defines what exceptions may be thrown when the given precondition holds. assignable Defines which fields are allowed to be assigned to by the method that follows. pure Declares a method to be side effect free (this shorthand for assignable \nothing). Defines an invariant property of the class. loop_invariant Defines a for a loop. also Java Modeling Language 2

Combines specification cases and can also declare that a method is inheriting specifications from its supertypes. assert Defines a JML assertion. spec_public Declares a protected or private variable public for specification purposes. Basic JML also provides the following expressions \result An identifier for the return value of the method that follows. \old() A modifier to refer to the value of the at the time of entry into a method. (\forall ; ; ) The universal quantifier. (\exists ; ; ) The existential quantifier. a ==> b a implies b a <== b a is implied by b a <==> b a if and only if b as well as standard for logical and, or, and not. JML annotations also have access to Java objects, object methods and operators that are within the scope of the method being annotated and that have appropriate visibility. These are combined to provide formal specifications of the properties of classes, fields and methods. For example, an annotated example of a simple banking class may look like

public class BankingExample {

public static final int MAX_BALANCE = 1000; private /*@ spec_public @*/ int balance; private /*@ spec_public @*/ boolean isLocked = false;

//@ public invariant balance >= 0 && balance <= MAX_BALANCE;

//@ assignable balance; //@ ensures balance == 0; public BankingExample() { this.balance = 0; }

//@ requires 0 < amount && amount + balance < MAX_BALANCE; //@ assignable balance; Java Modeling Language 3

//@ ensures balance == \old(balance) + amount; public void credit(final int amount) { this.balance += amount; }

//@ requires 0 < amount && amount <= balance; //@ assignable balance; //@ ensures balance == \old(balance) - amount; public void debit(final int amount) { this.balance -= amount; }

//@ ensures isLocked == true; public void lockAccount() { this.isLocked = true; }

//@ requires !isLocked; //@ ensures \result == balance; //@ also //@ requires isLocked; //@ signals_only BankingException; public /*@ pure @*/ int getBalance() throws BankingException { if (!this.isLocked) { return this.balance; } else { throw new BankingException(); } } }

Full documentation of JML syntax is available in the JML Reference Manual [1]. Java Modeling Language 4

Tool support A variety of tools provide functionality based on JML annotations. The Iowa State JML tools provide an assertion checking compiler jmlc which converts JML annotations into runtime assertions, a documentation generator jmldoc which produces Javadoc documentation augmented with extra information from JML annotations, and a unit test generator jmlunit which generates JUnit test code from JML annotations. Independent groups are working on tools that make use of JML annotations. These include: • ESC/Java2 [2], an extended static checker which uses JML annotations to perform more rigorous static checking than is otherwise possible; • Daikon [3], a dynamic invariant generator; • KeY, which provides a theorem prover with a JML front-end; • Krakatoa [4], a static verification tool based on the Why [5] verification platform and using the Coq proof assistant; • JMLeclipse [6], a plugin for the Eclipse integrated development environment with support for JML syntax and interfaces to various tools that make use of JML annotations. • Sireum/Kiasan [7], a symbolic execution based static analyzer which supports JML as a contract language. • JMLUnit [8], a tool to generate files for running JUnit tests on JML annotated Java files. • TACO [9], open source program analysis tool that statically checks the compliance of a Java program against its Java Modeling Language specification.

References • Gary T. Leavens and Yoonsik Cheon. Design by Contract with JML; Draft tutorial. • Gary T. Leavens, Albert L. Baker, and Clyde Ruby. JML: A Notation for Detailed Design; in Haim Kilov, Bernhard Rumpe, and Ian Simmonds (editors), Behavioral Specifications of Businesses and Systems, Kluwer, 1999, chapter 12, pages 175-188. • Gary T. Leavens, Erik Poll, Curtis Clifton, Yoonsik Cheon, Clyde Ruby, David Cok, Peter Müller, Joseph Kiniry, Patrice Chalin, and Daniel M. Zimmerman. JML Reference Manual (DRAFT), September 2009. HTML [10]

External links • JML website [11]

References

[1] http:/ / jmlspecs. org/ jmlrefman/ jmlrefman_toc. html

[2] http:/ / secure. ucd. ie/ products/ opensource/ ESCJava2/

[3] http:/ / pag. csail. mit. edu/ daikon/

[4] http:/ / krakatoa. lri. fr/

[5] http:/ / why. lri. fr/

[6] http:/ / jmleclipse. projects. cis. ksu. edu/

[7] http:/ / www. sireum. org/ ?q=node/ 21/

[8] http:/ / www. eecs. ucf. edu/ ~leavens/ JML2/ docs/ man/ jmlunit. html

[9] http:/ / www. dc. uba. ar/ inv/ grupos/ rfm_folder/ TACO

[10] http:/ / www. jmlspecs. org/ jmlrefman/ jmlrefman_toc. html

[11] http:/ / www. jmlspecs. org/ Design by contract 5 Design by contract

Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming, is an approach for designing software. It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with , postconditions and invariants. These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts. "Design by Contract" is a registered trademark of Eiffel Software in the United States, and should not be confused with the general design approach. Microsoft calls their design-by-contract programming implementation "Code Contracts".[1]

History The term was coined by in connection with his design of the Eiffel and first described in various articles starting in 1986[2][3][4] and the two successive editions (1988, 1997) of his book Object-Oriented Software Construction. Eiffel Software applied for trademark registration for Design by Contract in December 2003, and it was granted in December 2004.[5][6] The current owner of this trademark is Eiffel Software.[][7] Design by contract has its roots in work on formal verification, formal specification and . The original contributions include: • A clear metaphor to guide the design process • The application to inheritance, in particular a formalism for redefinition and dynamic binding • The application to exception handling • The connection with automatic software documentation

Description The central idea of DbC is a metaphor on how elements of a software system collaborate with each other on the basis of mutual obligations and benefits. The metaphor comes from business life, where a "client" and a "supplier" agree on a "contract" that defines for example that: • The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit). • The client must pay the fee (obligation) and is entitled to get the product (benefit). • Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts. Similarly, if a routine from a class in object-oriented programming provides a certain functionality, it may: • Expect a certain condition to be guaranteed on entry by any client module that calls it: the routine's precondition—an obligation for the client, and a benefit for the supplier (the routine itself), as it frees it from having to handle cases outside of the precondition. • Guarantee a certain property on exit: the routine's postcondition—an obligation for the supplier, and obviously a benefit (the main benefit of calling the routine) for the client. • Maintain a certain property, assumed on entry and guaranteed on exit: the . The contract is the formalization of these obligations and benefits. One could summarize approach by the "three questions" that the designer must repeatedly ask about the contract: • What does contract expect? • What does contract guarantee? Design by contract 6

• What does contract maintain? Many programming languages have facilities to make assertions like these. However, DbC considers these contracts to be so crucial to software correctness that they should be part of the design process. In effect, DbC advocates writing the assertions first. The notion of a contract extends down to the method/procedure level; the contract for each method will normally contain the following pieces of information:[citation needed] • Acceptable and unacceptable input values or types, and their meanings • Return values or types, and their meanings • Error and exception condition values or types that can occur, and their meanings • Side effects • Preconditions • Postconditions • Invariants • (more rarely) Performance guarantees, e.g. for time or space used Subclasses in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them). These rules approximate behavioural subtyping. All class relationships are between client classes and supplier classes. A client class is obliged to make calls to supplier features where the resulting state of the supplier is not violated by the client call. Subsequently, the supplier is obliged to provide a return state and data that does not violate the state requirements of the client. For instance, a supplier data buffer may require that data is present in the buffer when a delete feature is called. Subsequently, the supplier guarantees to the client that when a delete feature finishes its work, the data item will, indeed, be deleted from the buffer. Other design contracts are concepts of "class invariant". The class invariant guarantees (for the local class) that the state of the class will be maintained within specified tolerances at the end of each feature execution. When using contracts, a supplier should not try to verify that the contract conditions are satisfied; the general idea is that code should "fail hard", with contract verification being the safety net. DbC's "fail hard" property simplifies the debugging of contract behavior, as the intended behaviour of each routine is clearly specified. This distinguishes it markedly from a related practice known as defensive programming, where the supplier is responsible for figuring out what to do when a precondition is broken. More often than not, the supplier throws an exception to inform the client that the precondition has been broken, and in both cases—DbC and defensive programming—the client must figure out how to respond to that. DbC makes the supplier's job easier. Design by contract also defines criteria for correctness for a software module: • If the class invariant AND precondition are true before a supplier is called by a client, then the invariant AND the postcondition will be true after the service has been completed. • When making calls to a supplier, a software module should not violate the supplier's preconditions. Design by contract can also facilitate code reuse, since the contract for each piece of code is fully documented. The contracts for a module can be regarded as a form of software documentation for the behavior of that module. Design by contract 7

Performance implications Contract conditions should never be violated during execution of a bug-free program. Contracts are therefore typically only checked in debug mode during software development. Later at release, the contract checks are disabled to maximize performance. In many programming languages, contracts are implemented with assert. Asserts are by default compiled away in release mode in C/C++, and similarly deactivated in C#/Java. This effectively eliminates the run-time costs of contracts in release.

Relationship to software testing Design by contract does not replace regular testing strategies, such as unit testing, integration testing and system testing. Rather, it complements external testing with internal self-tests that can be activated both for isolated tests and in production code during a test-phase. The advantage of internal self-tests is that they can detect errors before they manifest themselves as invalid results observed by the client. This leads to earlier and more specific error detection.

Language support

Languages with native support Languages that implement most DbC features natively include: • Ada 2012 • Ciao • Clojure • Perl6 • Cobra • D • Eiffel • Fortress • Lisaac • Mercury • Nice • Oxygene (formerly Chrome) • Racket (including higher order contracts, and emphasizing that contract violations must blame the guilty party and must do so with an accurate explanation[8]) • RPS-Obix • Sather • SPARK (via static analysis of Ada programs) • Spec# • Vala • VDM Design by contract 8

Languages with third-party support Various libraries, preprocessors and other tools have been developed for existing programming languages without native Design by Contract support: • Ada, via GNAT pragmas for preconditions and postconditions. • C and C++, via the DBC for C preprocessor, GNU Nana, eCv static analysis tool, or the Digital Mars C++ compiler, via CTESK extension of C. Loki Library provides a mechanism named ContractChecker that verifies a class follows design by contract. • C# (and other .NET languages), via Code Contracts [9] (a Microsoft Research project integrated into the .NET Framework 4.0) • DELPHI PRISM, see [10] • Groovy via GContracts GContracts [11] • Java, via Contracts for Java [12], iContract2/JContracts [13], Contract4J [14], jContractor [15], C4J [16], Google CodePro Analytix, STclass [17], Jass preprocessor, OVal [18] with AspectJ, Java Modeling Language (JML), Jtest, SpringContracts [19] for the Spring framework, Modern Jass [20], Custos [21] using AspectJ,JavaDbC [22] using AspectJ, JavaTESK using extension of Java, chex4j [23] using javassist, and the highly customizable java-on-contracts [24]. • JavaScript, via Cerny.js [25], ecmaDebug [26], jsContract [27], or jscategory [28]. • Common Lisp, via the macro facility or the CLOS metaobject protocol. • Nemerle, via macros. • Perl, via the CPAN modules Class::Contract [29] (by Damian Conway) or Carp::Datum [30] (by Raphael Manfredi). • PHP, via Praspel or Stuart Herbert's ContractLib [31]. • Python, using packages like zope.interface [32], PyDBC [33] or Contracts for Python [34]. • Ruby, via Brian McCallister's DesignByContract, Ruby DBC ruby-contract or contracts.ruby [35]. • , via the XOTcl object-oriented extension.

Notes

[1] Code Contracts (http:/ / research. microsoft. com/ en-us/ projects/ contracts/ ) [2] Meyer, Bertrand: Design by Contract, Technical Report TR-EI-12/CO, Interactive Software Engineering Inc., 1986 [3] Meyer, Bertrand: Design by Contract, in Advances in Object-Oriented Software Engineering, eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1–50

[4] Meyer, Bertrand: Applying "Design by Contract", in Computer (IEEE), 25, 10, October 1992, pp. 40–51, also available online (http:/ / se.

ethz. ch/ ~meyer/ publications/ computer/ contract. pdf)

[5] United States Patent and Trademark Office registration for "DESIGN BY CONTRACT" (http:/ / tess2. uspto. gov/ bin/ showfield?f=doc&

state=4010:lsqmmo. 2. 2)

[6] United States Patent and Trademark Office registration for the graphic design with words "Design by Contract" (http:/ / tess2. uspto. gov/ bin/

showfield?f=doc& state=4010:lsqmmo. 2. 1)

[7] Current status of United States Patent and Trademark Office registration for the graphic design with words "Design by Contract" (http:/ / tarr.

uspto. gov/ servlet/ tarr?regser=serial& entry=78342308)

[8] Findler, Felleisen Contracts for Higher-Order Functions (http:/ / www. eecs. northwestern. edu/ ~robby/ pubs/ papers/ ho-contracts-icfp2002. pdf)

[9] http:/ / research. microsoft. com/ en-us/ projects/ contracts/

[10] http:/ / edn. embarcadero. com/ article/ 39398

[11] http:/ / gcontracts. org/

[12] https:/ / code. google. com/ p/ cofoja/

[13] http:/ / sourceforge. net/ projects/ jcontracts/

[14] http:/ / www. polyglotprogramming. com/ contract4j

[15] http:/ / jcontractor. sourceforge. net/

[16] http:/ / c4j. sourceforge. net/

[17] http:/ / www-valoria. univ-ubs. fr/ stclass/

[18] http:/ / oval. sourceforge. net/ Design by contract 9

[19] http:/ / springcontracts. sourceforge. net/

[20] http:/ / modernjass. sourceforge. net/

[21] http:/ / custos. dev. java. net

[22] http:/ / code. google. com/ p/ javadbc/

[23] http:/ / chex4j. sourceforge. net

[24] http:/ / code. google. com/ p/ java-on-contracts/

[25] http:/ / www. cerny-online. com/ cerny. js/

[26] http:/ / weblogs. mozillazine. org/ weirdal/ archives/ 016921. html

[27] https:/ / github. com/ oyvindkinsey/ jsContract

[28] http:/ / jscategory. wordpress. com/ source-code/

[29] https:/ / metacpan. org/ module/ Class::Contract

[30] https:/ / metacpan. org/ module/ Carp::Datum#PROGRAMMING-BY-CONTRACT

[31] https:/ / github. com/ stuartherbert/ ContractLib/

[32] http:/ / pypi. python. org/ pypi/ zope. interface/

[33] http:/ / pypi. python. org/ pypi/ PyDBC/

[34] http:/ / pypi. python. org/ pypi/ contract/

[35] http:/ / github. com/ egonSchiele/ contracts. ruby

Bibliography • Mitchell, Richard, and McKim, Jim: Design by Contract: by example, Addison-Wesley, 2002 • A wikibook describing DBC closely to the original model.

• McNeile, Ashley: A framework for the semantics of behavioral contracts (http:/ / dx. doi. org/ 10. 1145/ 1811147. 1811150). Proceedings of the Second International Workshop on Behaviour Modelling: Foundation and Applications (BM-FA '10). ACM, New York, NY, USA, 2010. This paper discusses generalized notions of Contract and Substitutability.

External links

• An introduction to Design by Contract(TM) (http:/ / archive. eiffel. com/ doc/ manuals/ technology/ contract/ )

• Benefits and drawbacks; implementation in RPS-Obix (http:/ / www. rps-obix. com/ docs/ manuals/

design_by_contract_contract_programming. html)

• C2 Wiki: Design by Contract (http:/ / c2. com/ cgi/ wiki?DesignByContract)

• Class Contracts in Delphi Prism (http:/ / prismwiki. codegear. com/ en/ Class_Contracts)

• Contract language and tools for .NET (http:/ / research. microsoft. com/ contracts)

• Damian Conway's Class::Contract (https:/ / metacpan. org/ module/ Class::Contract) Perl module from CPAN

• Digital Mars Contract Programming (http:/ / www. digitalmars. com/ ctg/ contract. html) (DBC)

• dlib C++ Library (http:/ / dclib. sourceforge. net)

• GContracts - Programming by Contract with Groovy (http:/ / github. com/ andresteingress/ gcontracts)

• GNU Nana (http:/ / savannah. gnu. org/ projects/ nana/ )

• Isaac/Lisaac Project home (http:/ / www. isaacos. com)

• Java Programming by Contract Class Utility (http:/ / www. dugaldmorrow. com/ index.

php?option=com_content& task=view& id=19& Itemid=38)

• Bertrand Meyer: Applying "Design by Contract" (http:/ / se. ethz. ch/ ~meyer/ publications/ computer/ contract. pdf), IEEE Computer, October 1992.

• Raphael Manfredi's Carp::Datum (https:/ / metacpan. org/ module/ Carp::Datum) Perl module from CPAN

• Using Code Contracts for Safer Code (http:/ / buksbaum. us/ 2011/ 04/ 20/ using-code-contracts-for-safer-code/ ) Formal methods 10 Formal methods

In computer science, specifically software engineering and hardware engineering, formal methods are a particular kind of mathematically based techniques for the specification, development and verification of software and hardware systems. The use of formal methods for software and hardware design is motivated by the expectation that, as in other engineering disciplines, performing appropriate mathematical analysis can contribute to the reliability and robustness of a design.

Formal methods are best described as the application of a fairly broad variety of theoretical computer science fundamentals, in particular logic calculi, formal languages, automata theory, and program semantics, but also type systems and algebraic data types to problems in software and hardware specification and verification.[1]

Taxonomy

Formal methods can be used at a number of levels: Level 0: Formal specification may be undertaken and then a program developed from this informally. This has been dubbed formal methods lite. This may be the most cost-effective option in many cases. An example formal specification using the Z notation. Level 1: Formal development and formal verification may be used to produce a program in a more formal manner. For example, proofs of properties or refinement from the specification to a program may be undertaken. This may be most appropriate in high-integrity systems involving safety or security. Level 2: Theorem provers may be used to undertake fully formal machine-checked proofs. This can be very expensive and is only practically worthwhile if the cost of mistakes is extremely high (e.g., in critical parts of microprocessor design). Further information on this is expanded below. As with programming language semantics, styles of formal methods may be roughly classified as follows: • Denotational semantics, in which the meaning of a system is expressed in the mathematical theory of domains. Proponents of such methods rely on the well-understood nature of domains to give meaning to the system; critics point out that not every system may be intuitively or naturally viewed as a function. • Operational semantics, in which the meaning of a system is expressed as a sequence of actions of a (presumably) simpler computational model. Proponents of such methods point to the simplicity of their models as a means to expressive clarity; critics counter that the problem of semantics has just been delayed (who defines the semantics of the simpler model?). • Axiomatic semantics, in which the meaning of the system is expressed in terms of preconditions and postconditions which are true before and after the system performs a task, respectively. Proponents note the connection to classical logic; critics note that such semantics never really describe what a system does (merely what is true before and afterwards). Formal methods 11

Lightweight formal methods Some practitioners believe that the formal methods community has overemphasized full formalization of a specification or design.[2][3] They contend that the expressiveness of the languages involved, as well as the complexity of the systems being modelled, make full formalization a difficult and expensive task. As an alternative, various lightweight formal methods, which emphasize partial specification and focused application, have been proposed. Examples of this lightweight approach to formal methods include the Alloy object modelling notation,[4] Denney's synthesis of some aspects of the Z notation with use case driven development,[5] and the CSK VDM Tools.[6]

Uses Formal methods can be applied at various points through the development process.

Specification Formal methods may be used to give a description of the system to be developed, at whatever level(s) of detail desired. This formal description can be used to guide further development activities (see following sections); additionally, it can be used to verify that the requirements for the system being developed have been completely and accurately specified. The need for formal specification systems has been noted for years. In the ALGOL 58 report, John Backus presented a formal notation for describing programming language syntax (later named Backus Normal Form then renamed Backus-Naur Form (BNF)[7]). Backus also wrote that a formal description of the meaning of syntactically valid ALGOL programs wasn't completed in time for inclusion in the report. "Therefore the formal treatment of the semantics of legal programs will be included in a subsequent paper." It never appeared.

Development Once a formal specification has been produced, the specification may be used as a guide while the concrete system is developed during the design process (i.e., realized typically in software, but also potentially in hardware). For example: • If the formal specification is in an operational semantics, the observed behavior of the concrete system can be compared with the behavior of the specification (which itself should be executable or simulateable). Additionally, the operational commands of the specification may be amenable to direct translation into executable code. • If the formal specification is in an axiomatic semantics, the preconditions and postconditions of the specification may become assertions in the executable code.

Verification Once a formal specification has been developed, the specification may be used as the basis for proving properties of the specification (and hopefully by inference the developed system).

Human-directed proof Sometimes, the motivation for proving the correctness of a system is not the obvious need for re-assurance of the correctness of the system, but a desire to understand the system better. Consequently, some proofs of correctness are produced in the style of mathematical proof: handwritten (or typeset) using natural language, using a level of informality common to such proofs. A "good" proof is one which is readable and understandable by other human readers. Critics of such approaches point out that the ambiguity inherent in natural language allows errors to be undetected in such proofs; often, subtle errors can be present in the low-level details typically overlooked by such proofs. Formal methods 12

Additionally, the work involved in producing such a good proof requires a high level of mathematical sophistication and expertise.

Automated proof In contrast, there is increasing interest in producing proofs of correctness of such systems by automated means. Automated techniques fall into two general categories: • Automated theorem proving, in which a system attempts to produce a formal proof from scratch, given a description of the system, a set of logical axioms, and a set of inference rules. • Model checking, in which a system verifies certain properties by means of an exhaustive search of all possible states that a system could enter during its execution. Some automated theorem provers require guidance as to which properties are "interesting" enough to pursue, while others work without human intervention. Model checkers can quickly get bogged down in checking millions of uninteresting states if not given a sufficiently abstract model. Proponents of such systems argue that the results have greater mathematical certainty than human-produced proofs, since all the tedious details have been algorithmically verified. The training required to use such systems is also less than that required to produce good mathematical proofs by hand, making the techniques accessible to a wider variety of practitioners. Critics note that some of those systems are like oracles: they make a pronouncement of truth, yet give no explanation of that truth. There is also the problem of "verifying the verifier"; if the program which aids in the verification is itself unproven, there may be reason to doubt the soundness of the produced results. Some modern model checking tools produce a "proof log" detailing each step in their proof, making it possible to perform, given suitable tools, independent verification.

Formal methods and notations There are a variety of formal methods and notations available. Specification languages • Abstract State Machines (ASMs) • A Computational Logic for Applicative Common Lisp (ACL2) • ANSI/ISO C Specification Language (ACSL) • Alloy • Autonomic System Specification Language (ASSL) • B-Method • Event-B [8] • CADP • Common Algebraic Specification Language (CASL) • Process calculi • CSP • LOTOS • π-calculus • Actor model • Esterel • Lustre • mCRL2 • Perfect Developer • Petri nets Formal methods 13

• RAISE • SPARK Ada • Specification and Description Language • Temporal logic of actions (TLA) • USL • VDM • VDM-SL • VDM++ • Z notation • Rebeca Modeling Language Model checkers • SPIN • PAT [9] is a powerful free model checker, simulator and refinement checker for concurrent systems and CSP extensions (e.g. shared variables, arrays, fairness). • MALPAS Software Static Analysis Toolset is an industrial strength model checker used for Formal Proof of safety critical systems • UPPAAL

References [1] Monin, pp.3-4

[2] Daniel Jackson and Jeannette Wing, "Lightweight Formal Methods" (http:/ / people. csail. mit. edu/ dnj/ publications/ ieee96-roundtable. html), IEEE Computer, April 1996

[3] Vinu George and Rayford Vaughn, "Application of Lightweight Formal Methods in Requirement Engineering" (http:/ / www. stsc. hill. af.

mil/ crosstalk/ 2003/ 01/ George. html), Crosstalk: The Journal of Defense Software Engineering, January 2003

[4] Daniel Jackson, "Alloy: A Lightweight Object Modelling Notation" (http:/ / people. csail. mit. edu/ dnj/ publications/ alloy-journal. pdf), ACM Transactions on Software Engineering and Methodology (TOSEM), Volume 11, Issue 2 (April 2002), pp. 256-290 [5] Richard Denney, Succeeding with Use Cases: Working Smart to Deliver Quality, Addison-Wesley Professional Publishing, 2005, ISBN 0-321-31643-6.

[6] Sten Agerholm and Peter G. Larsen, "A Lightweight Approach to Formal Methods" (http:/ / home0. inet. tele. dk/ pgl/ fmtrends98. pdf), In Proceedings of the International Workshop on Current Trends in Applied Formal Methods, Boppard, Germany, Springer-Verlag, October 1998 [7] Knuth, Donald E. (1964), Backus Normal Form vs Backus Naur Form. Communications of the ACM, 7(12):735–736.

[8] http:/ / www. event-b. org/ index. html

[9] http:/ / www. comp. nus. edu. sg/ ~pat/ This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.

Further reading • Jean François Monin and Michael G. Hinchey, Understanding formal methods, Springer, 2003, ISBN 1-85233-247-6. • Jonathan P. Bowen and Michael G. Hinchey, Formal Methods. In Allen B. Tucker, Jr. (ed.), Computer Science Handbook, 2nd edition, Section XI, Software Engineering,Chapter 106, pages 106-1 – 106-25, Chapman & Hall / CRC Press, Association for Computing Machinery, 2004. • Michael G. Hinchey, Jonathan P. Bowen, and Emil Vassev, Formal Methods. In Philip A. Laplante (ed.), Encyclopedia of Software Engineering, Taylor & Francis, 2010, pages 308–320. Formal methods 14

External links

• Formal Methods Europe (FME) (http:/ / www. fmeurope. org/ )

• Formal method (http:/ / academic. research. microsoft. com/ Keyword/ 14916) keyword on Microsoft Academic Search

• Foldoc:formal methods (http:/ / foldoc. org/ formal+ methods)

• Evidence on Formal Methods uses and impact on Industry (http:/ / www. fm4industry. org) Supported by the

DEPLOY (http:/ / www. deploy-project. eu) project (EU FP7) Article Sources and Contributors 15 Article Sources and Contributors

Java Modeling Language Source: http://en.wikipedia.org/w/index.php?oldid=575546934 Contributors: Abdull, Alex.g, BBB, Banazir, Bovineone, Doradus, Doug Bell, Gleavens, InverseHypercube, Jgc2003, JohnCD, Jpbowen, KeYIT, Kelly Martin, Leland McInnes, Lewis Grant01, Lfstevens, Mdd, MeltBanana, Pawelkg, Peak, Poco a poco, Raven in Orbit, RedWolf, Skytvfreak, Smshaner, Suruena, Thumperward, Tillmo, TittoAssini, TurboForce, Urhixidur, 42 anonymous edits

Design by contract Source: http://en.wikipedia.org/w/index.php?oldid=576132175 Contributors: 2coma7, Aapo Laitinen, Adrian.benko, AlexLehm, AliveFreeHappy, Allan McInnes, Andreas Kaufmann, Andrewsmeredith, Antonielly, Ap, Atcack, B44H, Basil.bourque, Beland, BenFrantzDale, CaliforniaAliBaba, CanisRufus, Charles Matthews, Charles Merriam, Chris Chittleborough, ChuckEsterbrook, Classicalecon, Colonies Chris, Ctxppc, CyrilB, Cyrius, Darius Bacon, David from Downunder, DavidCary, DeanWilson, Dereckson, Designatevoid, Diaa Sami, Dicklyon, Doradus, Dtm1234, Elibarzilay, Eliovir, Evildeathmath, Flopster2, Forderud, Frecklefoot, Fuchsias, Galwhaa, Geh, Gioto, Graue, Grhodes40, Gunsoft, Gwernol, Intgr, Itai, Ivan Enderlin, J. Finkelstein, JLaTondre, JamesHaigh, Jayjg, Jerryobject, John Vandenberg, JonasGranqvist, Jrv, Jswap, Judith Carlton, Jvoegele, Kaare, Keplervic, Krischik, LOL, Leibniz, Lewisdg2000, Magioladitis, Marco Krohn, Mark Leighton Fisher, Marudubshinki, Mathrick, Matt Crypto, MattGiuca, Matthias.f, Mav, Mboverload, Mdd, Michael Hardy, Mike Segal, Mindmatrix, Mlorenz, Mrwojo, Musiphil, Natalie Mak, Nbulp, NickHodges, Nneonneo, Obligato17, Od Mishehu, Oleg Alexandrov, Ootachi, PJonDevelopment, PabloCastellano, Pindakaas, Pnm, Prakash Nadkarni, Prosfilaes, RTC, Ramix, Rbonvall, Rich Farmbrough, Ricvelozo, Rizniz, Rl, Rufous, Sae1962, Schoelle, SchreyP, Sebastian.Dietrich, Sebleblanc, Setok, SimonP, Sma045, Snakeowl, Somnambulon, Sreyan, Talandor, The Anome, Tillmo, Timwi, Tobias Bergemann, Torc2, Traroth, Two Bananas, Ulner, Vatula, Vdm, Wikidrone, Wlievens, Yannick Moy, Ylai, Yukoba, Yworo, Zondor, Zsinj, 181 anonymous edits

Formal methods Source: http://en.wikipedia.org/w/index.php?oldid=581194027 Contributors: AGK, ARC Gritt, Adavidb, Airsplit, Allan McInnes, Amakuru, Andyed 2003, Annaamalia, Antonielly, Ashley Y, Ayda D, Bdongol, Bogdanb, Brad7777, CarlHewitt, ComputScientist, Damyot, Daniel5Ko, Danielbruns, Dekart, Derek farn, Dylan Lake, Erhasalz, FSVZ, Fgegypt, FlyHigh, GeorgeBills, Gioto, Huperniketes, J.delanoy, Jcarnelian, Jim Huggins, Jimmaths, JohnGDrever, Jpbowen, Kelson, Khalid hassani, Leibniz, Mark Renier, Mburkhol, Mdd, Michael Hardy, Michael Snow, Minesweeper, MrOllie, Nikkimaria, NuclearWarfare, Pablomics, Pcap, [email protected], Project2501a, Ragerdl, RichardDenney, Robert Will, Robertbyrne, Sspecter, Stephenb, SteveLoughran, T.krilavicius, TakuyaMurata, Topbanana, Torfason, Vasywriter, VictorAnyakin, Vkuncak, Vonkje, Waeswaes, Wavelength, Wbm1058, Zouxiaohui, 88 anonymous edits Image Sources, Licenses and Contributors 16 Image Sources, Licenses and Contributors

File:Agendacumple en Z.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Agendacumple_en_Z.jpg License: Creative Commons Attribution-Share Alike Contributors: PABLOLIZ License 17 License

Creative Commons Attribution-Share Alike 3.0 //creativecommons.org/licenses/by-sa/3.0/