Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering)

1
Formal Specification a RoadmapAxel van
Lamsweerdepublished on ICSE (International
Conference on Software Engineering)

• Jing Ai
• 10/28/2003

2
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.

3
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

4
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

5
Properties?

• High level goals
• Functional requirements
• Non-functional requirements about timing,
  performance, accuracy, security

6
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)

7
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.

8
What are good specifications?

• Adequate
• Internally consistent,
• Unambiguous
• Complete with respect to higher level ones
• Be satisfied by lower-level ones
• Minimal

9
Why specify formally?

• Specifications is essential for
• Designing
• validating
• Documenting
• Communicating
• Reengineering
• Reusing
• Specification also provides the basis for their
  automated support

10
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

11
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

12
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

13
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

14
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

15
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

16
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.

17
Specification Paradigms

• History-based specification
• State-based specification
• Transition-based specification
• Functional specification
• Operational specification

18
Evaluation of the specification

• Expressive power and level of coding required.
• Constructibility, manageability and evolvability
• Usability
• Communicability
• Powerful and efficient analysis

19
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

20
Bad news for the formal specification

• Limited scope
• Poor separation of concerns
• Low-level ontologies
• Isolation
• Poor guidance
• Cost
• Poor tool feedback

21
Tomorrows technologies for the formal
specification

• Constructiveness
• Support for comparative analysis
• Integration
• Higher level of abstraction
• Richer structuring mechanisms
• Extended scope
• Separation of concerns

22
Tomorrows 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

23
Thank you!