Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003

What are Formal Specifications? Generally speaking, a formal specification is the expression, in some formal language and at some level of abstraction, of a collection of properties some system should satisfy.

A series of development steps for a complex software application  High-level goals are identified and refined until a set of requirements on the software and assumptions on the environment can be made precise to satisfy such goals  A software architecture, made of interconnected software components, is designed to satisfy such requirements  The various components are implemented and integrated so as to satisfy the architectural descriptions

System?  A descriptive model of the domain of interest  A prescriptive model of the software and its environment  A prescriptive model of the software alone  A model for the user interface  The software architecture  A model of some process to be followed  ……

Properties?  High level goals  Functional requirements  Non-functional requirements about timing, performance, accuracy, security  ……

Whether a specification is formal or not? The specification is expressed in a language made of three components:  Rules for determining the grammatical well-formedness of sentences (the syntax);  Rules for interpreting sentences in a precise, meaningful way within the domain considered (the semantics)  Rules for inferring useful information from the specification (the proof theory)

Organization of specifications in formal language Due to the fairly large collection of properties, specification is organized into units linked through structuring relationships: specialization, aggregation, instantiation, enrichment, use, etc. Each unit in general has: a declaration part: where variables of interest are declared an assertion part: where the intended properties on the declared variables are formalized.

What are good specifications?  Adequate  Internally consistent,  Unambiguous  Complete with respect to higher level ones  Be satisfied by lower-level ones  Minimal

Why specify formally?  Specifications is essential for: Designing validating Documenting Communicating Reengineering Reusing  Specification also provides the basis for their automated support

Automated tools to manipulate the formal specifications  To derive premises or logical consequences of the specification, for user confirmation,  To confirm that an operational specification satisfies more abstract specifications, or to generate behavioral counterexamples if not  To generate counterexamples to claims about a declarative specification  To generate concrete scenarios illustrating desired or undesired features about the specification or, conversely, to infer the specification inductively from such scenarios

Automated tools to manipulate the formal specifications (cont.)  To produce animations of the specification in order to check its adequacy  To check specific forms of specification consistency/completeness efficiently  To generate high-level exceptions and conflict preconditions that may make the specification unsatisfiable  To generate higher-level specifications such as invariants or conditions for liveness

Automated tools to manipulate the formal specifications (cont.)  To drive refinements of the specification and generate proof obligations  To generate test cases and oracles from the specification  To support formal reuse of components through specification matching

Specify... for whom? Formal specifications may concern different classes of consumers having fairly different background, abstractions and languages: Clients (specification of a goal or requirement) Domain experts (a domain description) Users Architects Programmers (an architectural component specification) Tools

Specify... when?  There are multiple stages in the software lifecycle at which formal specifications may enter the picture: When modeling the domain When elaborating the goals, requirements on the software, and assumptions about the environment When designing a functional model for the software When designing the software architecture When modifying or reengineering the software

A few important principles and facts overlooked  Specifications are never formal in the first place  Formal specifications are meaningless without a precise, informal definition of how to interpret them in the domain considered  Formal specification is not a mere translation process from informal to formal  Formal specifications are hard to develop and assess

A few important principles and facts overlooked (cont.)  The rationale for specific modeling choices in a specification is important for explanation and evolution. Unfortunately, such rationale is rarely documented.  The by-products of a formal specification process are often more important than the formal specification itself  To be useful, a formal system must have a limited domain of applicability.

Specification Paradigms  History-based specification  State-based specification  Transition-based specification  Functional specification  Operational specification

Evaluation of the specification  Expressive power and level of coding required.  Constructibility, manageability and evolvability  Usability  Communicability  Powerful and efficient analysis

Good news for the formal specification  The number of success stories in using formal specifications for real systems is steadily growing from year to year.  A recent, fairly impressive example is worth pointing out (eg. the Paris metro system)  The success of this formal development might be explained by the unusual combination of success factors  The maturity of specification tool technology is also steadily growing from year to year

Bad news for the formal specification  Limited scope  Poor separation of concerns  Low-level ontologies  Isolation  Poor guidance  Cost  Poor tool feedback

Tomorrow’s technologies for the formal specification  Constructiveness  Support for comparative analysis  Integration  Higher level of abstraction  Richer structuring mechanisms  Extended scope  Separation of concerns

Tomorrow’s technologies for the formal specification (cont.)  Lightweight techniques  Multiparadigm specification  Multibutton analysis  Multiformat specification  Reasoning in spite of errors  Constructive feedback from tools  Support for evolution  Support for reuse  Measurability of progress

Thank you!