Lecture # 02

Formal Specifications
Instructor: Saima Zareen
Assistant Professor
Department of Software Engineering
[email protected]
RECAP

 My name is ………………………….

 I remember …………………………..
Outline
 Defining Formal Specification.
 Formal Specifications and Problem domain
 Components of Formal Specification
 Attributes of Good Formal Specification
 Why Formal Specifications are required?
 Who can use Formal Specifications?
 When Formal Specifications can be defined?
 Scope and Pitfalls
 Formal Specifications Paradigms.
 Applications
 Limitations
 Improvements
 Summary
Formal Specification
 What are Formal Specifications?
 Formal specifications may refer to fairly
different things in the software lifecycle;
 the wording is thus heavily overloaded.
 An additional source of confusion stems from
the fact that a single word is used for a product
and the corresponding process.
Formal Specification contd..
 Generally speaking, a formal specification is
the expression in:
 some formal language and
 at some level of abstraction,
 A collection of properties some system should
satisfy.
Formal Specification contd..
 This definition covers different notions, that
are dependent on
 What the word system covers?
 What kind of properties are of interest?
Formal Specification : System
 The “system” being specified
 may be a model of the domain of interest.
 a model of the software and its environment.
 a model of the software alone.
 a model for the user interface
Formal Specification: Properties
 The “properties” under consideration may
 refer to high-level goals.
 functional requirements
 non-functional requirements about:
 timing, performance, accuracy, security, etc.;
 environmental assumptions;.
 services provided by architectural components;
protocols of interaction among such
components and so on.
Formal Specification: Problem Domain
 There is a common idea of specifications
pertaining to the problem domain.
 one must first state that problem correctly.
 a solution to a problem be given as a set of sub
problems to be specified and solved in turn.
Components of Formal Specification
 A specification is formal if it is expressed in a language
made of three components:
i. Syntax
 rules for determining the grammatical well-formedness of
sentences
ii. Semantics
 rules for interpreting sentences in a precise, meaningful
way within the domain considered.
iii. Proof theory
 rules for inferring useful information from the
specification .
 This component provides the basis for automated analysis
of the specification.
What are Good Specification?

 Writing a “correct” specification is very difficult

 probably as difficult as writing a correct program.
i. A specification must be adequate,
 it must adequately state the problem at hand.
ii. It must be internally consistent,
 it must have a meaningful semantic interpretation
 that makes true all specified properties taken together.
iii. It must be unambiguous,
 it may not have multiple interpretations of interest making it
true.
iv. It must be complete with respect to higher-level ones,
 the collection of properties specified must be sufficient.
What are Good Specifications? Contd..

v. It must be satisfied by lower-level ones.

 It should be minimal, it should not state
properties that are irrelevant to the problem OR
 that are only relevant to a solution for that
problem
Why Specify Formally?

1. Problem specifications are essential for

i. designing,
ii. validating,
iii. documenting,
iv. communicating,
v. reengineering,
vi. Reusing solutions.
2. Formality helps in obtaining higher-quality
specifications within such processes.
3. It also provides the basis for their automated
support.
Why specify formally? Contd..

4. Formalization in itself has been used widely

i. to raise many questions
ii. and detect serious problems in original
informal formulations.
5. Formalism provides precise rules of
interpretation
i. that allow many of the problems with natural
language to be overcome.
Why Specify Formally? Contd..
6. formal specifications may be manipulated by
automated tools for a wide variety of
purposes:
i. to derive logical consequences of the
specification, for user confirmation,
ii. to generate concrete scenarios illustrating
desired or undesired features about the
specification.
iii. to check specific forms of specification
consistency/completeness Efficiently.
Why specify formally? Contd..
viii. to generate higher-level specifications such as
invariants or conditions.
ix. to drive refinements of the specification .
x. to generate test cases from the specification.
xi. to support formal reuse of components
through specification matching.
8. Formal specifications can also be generated
from program code as a basis for reverse
engineering and software evolution.
Specify... for whom?
1. Users with different
1. background,
2. abstractions and
3. languages
 clients,
 domain experts,
 users,
 architects,
 programmers, and
 tools.
Specify... for whom?
For example
i. the specification of a goal or requirement
should be checked by clients for adequacy.
ii. a domain description should be produced or
checked by domain experts.
iii. an architectural component specification
should be seen in a detailed form by
programmers assigned to that component .
Specify... for whom? Contd..
2. There are multiple stages in the software
lifecycle at which formal specifications may
enter the picture,
 For Example
i. when modeling the domain;
ii. when elaborating the goals, requirements on the
software,
iii. assumptions about the environment;
Specify... when?
1. when designing a functional model for the
software.
2. when designing the software architecture.
3. when modifying or reengineering the
software.
4. The main focus to date has been on formal
specifications
• written during the design of a preliminary
functional model for the software.
Formalization: Scope and Pitfalls
1. Specifications are never formal in the first
place
 To state properties precisely and formally
 one must first figure out, what these properties are.

 They must necessarily be formulated in a language all

parties can speak and understand,
 that is, natural language.
Formalization: Scope and Pitfalls contd..
2. Formal specifications are meaningless
without a precise, informal definition of how
to interpret them in the domain considered.
Formalization: Scope and Pitfalls
contd..
3. Formal specification is not a mere translation
process from informal to formal.
i. The specification of a large, complex system
requires relevant objects and phenomena to be
 Identified
 Interrelated and
 characterized through properties of interest.
Formalization: Scope and Pitfalls contd..
4. Formal specifications are hard to develop and
assess.
i. The diversity and subtlety of errors that can be
made from the multiplicity of modeling
choices
ii. As a consequence, formal specifications are
rarely correct in the first place.
iii. It has been frequently noted, that even wrong
specifications may help finding out problems
in original formulations.
Formalization: Scope and Pitfalls contd..
5. To be useful, a formal system must have a
limited domain of applicability.
i. Specific types of systems require specific types
of techniques for natural expression.
Specification Paradigms
 Formal specification techniques differ mainly
by the particular specification paradigm they
rely on.
1. History-based Specification
i. The principle here is to specify a system by
characterizing its maximal set of admissible
histories (or “behaviors”) over time.
Specification Paradigms contd..
a. These assertions involve operators referring to
past, current and future states.
b. The assertions are interpreted over time
structures.
c. The properties refer to time intervals.
Specification Paradigms contd..
2. State-based Specification
one may characterize the admissible system states
at some arbitrary snapshot.
i. The properties of interest are specified by
a) invariants containing the system objects at any
snapshot.
b) pre- and post-assertions containing the application
of system operations at any snapshot.
Specification Paradigms contd..
c) A pre-assertion captures a weakest necessary
condition on input states for the operation to be
applied.
d) a post-assertion captures a strongest effect condition
on output states if the operation is applied.
Examples
Languages such as:
i. Z,
ii. VDM or
iii. B rely on this paradigm.
Specification Paradigms contd..
3. Transition-based Specification
 One may characterize the required transitions from
state to state.
 The properties of interest are specified by a set of
transition functions in the state machine transition.
b. The transition function for a system object gives,
 each input state
 triggering event,
 the corresponding output state.
Specification Paradigms contd..
b. The occurrence of a triggering event is a
sufficient condition for the corresponding
transition to take place.
d. necessary preconditions may also be specified
to guard the transition
Examples
 State charts.
 PROMELA (protocol/process meta language)
Specification Paradigms contd..
3. Functional specification
i. The principle here is to specify a system as a
structured collection of mathematical
functions.
Example
 OBJ
 LARCH
Specification Paradigms contd..
4. Operational Specification
i. At the extreme opposite, a system may be
characterized as a structured collection of
processes that can be executed by some more or
less abstract machine.
ii. Early languages such as
 Paisley process oriented, applicative and interpretable
Specification language
 GIST Glasgow Interactive System Groups
 Petri-nets
 Process Algebras
 http://formalmethods.wikia.com/wiki/VL
Applications of Formal Specifications
 Examples
 Paris metro line for traffic .
 Nuclear reactors (UVAR)
 IBMS Customer Information and Control
System (CICS)
 Civil aviation Display information system for
UK’s air traffic management.
 Tektronics, family of oscilloscopes
 Clinical neutron medical system (Washington)
Limitations of Formal Specifications
 Formal specification techniques suffer a
number of weaknesses.
i. Limited scope
 The vast majority of techniques are limited to the
specification of functional properties,
 that is, Properties about what the target system is
expected to do.
 Nonfunctional properties are in general left outside
any kind of formal treatment.
Limitations of Formal Specifications contd..
ii. Isolation.
 formal specification techniques are isolated
from other software products and processes.
Limitations of Formal Specifications contd..
iii. Cost.
 Many formal specification techniques require
high expertise in formal systems in general (and
mathematical logic in particular),
 Due to the scarcity of such expertise
 their use in industrial projects is nowadays still highly
limited in spite of the promised benefits.
Limitations of Formal Specifications contd..
iv. Poor tool feedback
 Many analysis tools are effective at pointing out
problems, but in general they do a poor job of
 suggesting causes at the root of such problems
 proposing recovery actions.
Improvements in Formal Specifications
i. Support for comparative analysis
 we need precise criteria and measures for
assessing specifications and comparing their
relative merits.
Improvements in Formal Specifications
contd..
ii. Integration.
 Tomorrow’s technology should care for the
integration of formal specifications within the
software lifecycle - from high-level goals to
functional design to architectural components
Improvements in Formal Specifications
contd..
iii. Extended scope.
Specification techniques need to be extended in
order to cope with the various categories of non-
functional properties that are:
• elicited during requirements engineering and
• play a prominent role during architectural design,
 e.g.,
 properties about performance, integrity, confidentiality,
accuracy of information, availability, fault-tolerance,
operational costs, maintainability, and so forth.
Improvements in Formal Specifications
contd..
vi. Lightweight techniques
 The use of formal specifications should not
require deep expertise in formal systems.
 The mathematical elaboration should be
hidden;
 analysis tools should be usable like compilers.
Improvements in Formal Specifications
contd..
vii. Multi-paradigm specification
 Complex systems have multiple aspects.
 Since no single paradigm will ever serve all
purposes due to
 semantic biases,
 frameworks are needed in which multiple paradigms
can be combined in a semantically meaningful way so
that
 the best features of each paradigm can be exploited.
Summary
 Formal Specifications refer to process as well as to
a product.
 It is a language that contains three parts, syntax,
semantics and proof theory.
 It is related to the problem domain.
 Good formal specifications are complete,
consistent, complete, unambiguous and adequate.
 One cannot express a system formally in a sinlge
step.
Summary
 It requires a series of steps and refinements.
 Formal specifications are useful for every
stakeholder who is involved directly or indirectly
in system development.
 Formal Specifications are used in different
applications of aviation, telecommunication and
transportation.
 Their use is being expanded to even design of
buildings.
 Formal specification can be defined at any stage of
system design.
Summary
 But results are more fruitful if applied at initial
requirements elicitation phase.
 Formal specifications are limited in scope
 There is no criteria to measure the effectiveness of
Formal Specifications.
 There exists four paradigms of Formal
Specification.
 There is the need to integrate the best features of
Formal Specification paradigms for better results.
Questions