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!