Formal Specification: a Roadmap
Download
1 / 23

Jing Ai 10/28/2003 - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Jing Ai 10/28/2003' - trula


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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

Jing Ai

10/28/2003


What are formal specifications
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
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
System? application

  • 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
Properties? application

  • High level goals

  • Functional requirements

  • Non-functional requirements about timing, performance, accuracy, security

  • ……


Whether a specification is formal or not
Whether a specification is formal or not? application

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
Organization of specifications in formal language application

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
What are good specifications? application

  • Adequate

  • Internally consistent,

  • Unambiguous

  • Complete with respect to higher level ones

  • Be satisfied by lower-level ones

  • Minimal


Why specify formally
Why specify formally? application

  • 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
Automated tools to manipulate the formal specifications application

  • 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
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 cont1
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
Specify... for whom? (cont.)

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
Specify... when? (cont.)

  • 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
A few important principles and facts overlooked (cont.)

  • 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
A few important principles and facts overlooked (cont.) (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
Specification Paradigms (cont.)

  • History-based specification

  • State-based specification

  • Transition-based specification

  • Functional specification

  • Operational specification


Evaluation of the specification
Evaluation of the specification (cont.)

  • Expressive power and level of coding required.

  • Constructibility, manageability and evolvability

  • Usability

  • Communicability

  • Powerful and efficient analysis


Good news for the formal specification
Good news for the formal specification (cont.)

  • 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
Bad news for the formal specification (cont.)

  • Limited scope

  • Poor separation of concerns

  • Low-level ontologies

  • Isolation

  • Poor guidance

  • Cost

  • Poor tool feedback


Tomorrow s technologies for the formal specification
Tomorrow’s technologies for the formal specification (cont.)

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

Thank you! (cont.)


ad