Formal Techniques in Software Engineering

• Formal techniques use mathematical methods to specify, verify, and

prove properties of systems without needing to execute them.

• Formal specification languages consist of a syntactic domain, a

semantic domain, and a satisfaction relation between them.
Syntactic domain

• Consists of an alphabet of symbols and a set of formation rules to

construct well-formed formulas from the alphabet.

• The well-formed formulas are used to specify a system.

Semantic domain
• Formal techniques can have considerably different semantic domains.

• Abstract data type specification languages are used to specify

algebras, theories, and programs.

• Programming languages are used to specify functions from input to

output values.

• Concurrent and distributed system specification languages are used

to specify state sequences, event sequences, state-transition
sequences, synchronisation trees, partial orders, state machines,
Satisfaction Relation

• Determines whether a system’s model meets its specifications

through a semantic abstraction function.
 Operational Semantics
Operational semantics refers to how system computations are represented.

Different types of operational semantics include:

• Linear Semantics: System runs are sequences of events or states, with concurrent activities
represented through non-deterministic interleaving of actions.

• Branching Semantics: System behaviour is modelled using directed graphs, where nodes
represent states, and descendants represent actions that can occur next.

• Maximally Parallel Semantics: Assumes that all concurrent actions are executed together, which
is not always realistic due to resource constraints.

• Partial Order Semantics: Uses a structure of states to represent a partial order of events, allowing
some events to occur concurrently without a sequential order.
Merits of Formal Methods:

• Encourage rigor and precision in specification.

• Provide a mathematical basis for reasoning and verification.

• Enable automatic analysis and verification.

Limitations:

• Formal methods are complex to learn and use.

• Cannot guarantee absolute correctness due to the limits of theorem proving.

• Struggle with complexity, making large systems difficult to manage.

AXIOMATIC SPECIFICATION
• Uses first-order logic to define system operations through pre-conditions

and post-conditions.

• Pre-conditions define the requirements for successful operation invocation,

primarily focusing on input constraints.

• Post-conditions set the conditions that must be met for an operation's

successful completion, determining the correctness of the output.

Steps for Developing Axiomatic Specifications

• Define the valid input range for the function.

• Specify the conditions that must hold for the function's output.

• Identify any changes made to the input parameters after execution.

• Combine these into the function’s pre-conditions and post-conditions.

• This method is used to define constraints on input and output, ensuring system

operations behave correctly.

 Example 1

• The function f(x: real): real takes a real number as input and returns a real number as

output, with behaviour depending on the value of the input.

• Pre-condition: x ∈ R: This means that the input x must be a real number. This is a broad

condition ensuring that the function can only accept real numbers as inputs.
Post-condition
• The post-condition defines the expected result of the function based on

the input value. It is written as a logical expression involving two cases:

• First Case:

• If x ≤ 100, the function will return half of x.

• This is written as (x ≤ 100) ∧ (f(x) = x / 2)

• Second Case:

• If x > 100, the function will return double the value of x.

• This is written as (x > 100) ∧ (f(x) = 2 * x)

Example 2

• The function search searches for the key in the array X.

• The pre-condition guarantees that the key exists in X.

• The post-condition ensures that the function returns the correct index of

the key in X and that the array remains unchanged.

Function Definition:
• search(X: intArray, key: integer) : integer
• This defines a function named search that takes two arguments:
• X: an array of integers (intArray).
• key: an integer value that needs to be found in the array.
• The function returns an integer, which is likely the index where the key is found.

Pre-condition (pre):
• ∃ i ∈ [Xfirst...Xlast], X[i] = key
• This pre-condition states that there exists an index i within the range of the array X (from the
first element Xfirst to the last element Xlast) such that X[i] is equal to the key.
• In other words, this condition ensures that the key exists in the array X before the function is
called.
 Post-condition (post)
• {(X'[search(X, key)] = key) ∧ (X = X')}

• The post-condition ensures two things:

• Correct Indexing: After the search function is executed, the value at the index returned by

search(X, key) in the array X should be equal to the key. In other words, the function correctly

finds the index of the key in X.

• No Modification of Array: The array X remains unchanged after the function call (X = X'), meaning

the search operation does not modify the input array.

ALGEBRAIC SPECIFICATIONS
• Technique for specifying object classes or types by defining

relationships between the operations on those types.

• In this, a system is represented as a heterogeneous algebra, consisting

of multiple sets and operations, unlike traditional homogeneous

algebras.
Key components of algebraic specification include:
• Types section: Specifies the data types (sorts) used.

• Exception section: Lists exceptional conditions for different operations.

• Syntax section: Defines the signatures of interface procedures, describing the input domain and output
sorts.

• Equations section: Provides rewrite rules that define the operations' meanings using equations.

Operations are categorized as:

• Basic construction operators: Essential for creating or modifying types (e.g., "create").

• Extra construction operators: Additional constructors (e.g., "remove").

• Basic inspection operators: Evaluate attributes of a type without modifying them(e.g., "eval").

• Extra inspection operators: Additional inspectors.

Key points of the rules for extra inspection operators

1.Constructor vs. Inspector:

•If the data type being specified appears on the right-hand side of the operator's expression, it is a constructor.

•If the data type does not appear on the right-hand side, it is an inspection operator.

2.Basic and Extra Operators:

•Establish whether operators are basic constructors, extra constructors, basic inspectors, or extra inspect

3.Axioms for Operators:

•Write axioms for every basic constructor combined with each basic inspector and extra constructor.

•Write axioms for each extra inspector in terms of basic inspectors.

Key points of the rules for extra inspection operators (contd..)

4.Number of Axioms:

•The minimum number of axioms required is calculated as: m1 × (m2 + n1) + n2, where:

•m1 = number of basic constructors

•m2 = number of extra constructors

•n1 = number of basic inspectors

•n2 = number of extra inspectors

Example 1
 Properties of Algebraic Specifications

• Completeness: The equations should allow for the reduction of any sequence of operations on the interface

procedures. If the specification is incomplete, the reduction process may get stuck at some point.

• Finite Termination Property: The application of rewrite rules should always terminate, meaning the process

will eventually stop.

• Unique Termination Property: Regardless of the order in which the rewrite rules are applied, they should

always lead to the same final result.

Example 2
Function-oriented design and the Structured
Analysis/Structured Design (SA/SD) methodology
Function-Oriented Design Overview

• Systems are initially viewed as black-boxes that provide services (high-level

functions) to users.

• Involves "top-down decomposition," where high-level functions are broken down

into smaller, more detailed functions, eventually mapped to a module structure.

SA/SD involves two distinct activities

• Structured Analysis (SA): Transforming the Software Requirement

Specification (SRS) into a Data Flow Diagram (DFD) model.

• Structured Design (SD): Converting the DFD model into a structure

chart (module structure).

Data Flow Diagrams (DFDs)
• DFD is a hierarchical graphical model representing system functions and the data

interchange among them.

• A DFD model ignores control flow and algorithms but focuses on data flow.

• Symbols used in DFDs:

• Process (Bubble): Represents a function or processing task (circle).

• External Entity: Represents entities interacting with the system (rectangle).

• Data Flow: Depicts data movement between processes or external entities (directed arrow).

• Data Store: Represents logical files or data stores (two parallel lines).

• Output Symbol: Used for hardcopy outputs.

DFD symbols
Concepts in DFD
• Synchronous vs. Asynchronous Operations:

• Synchronous: Bubbles connected by a data flow arrow operate at the same speed.

• Asynchronous: Bubbles connected via a data store can operate independently.

• Data Dictionary:

• A data dictionary lists and defines all data items in the DFD model.

• Provides a consistent vocabulary, helps determine data structures.

• In large projects, maintaining the dictionary manually is challenging, so CASE tools automate

its generation.
Synchronous and Asynchronous operation
Data Definition Operators
• +: Composition of two data items (e.g., a+b).

• [,,]: Selection, where any one item can occur (e.g., [a, b]).

• (): Optional data (e.g., a+(b)).

• {}: Iterative data (e.g., {name}5 represents five names).

• =: Equivalence (e.g., a = b + c).

• */ */**: Used for comments.

Computer-Aided Software Engineering (CASE) tools assist in automatically creating data

dictionaries, maintaining consistency, and supporting queries about data items

DFD Model Overview
• A DFD (Data Flow Diagram) graphically represents how input data is transformed into output

through a hierarchy.

• Consists of many DFDs and a single data dictionary.

• Top-level DFD is called Level 0 or Context Diagram, with each lower level providing more details.

• The model starts with an abstract representation, and processes are decomposed into sub-

processes in lower levels.

• Levels are hierarchical: Level 0 (Context Diagram), Level 1 (single DFD), Level 2 (up to 7 DFDs),

Level 3 (up to 49 DFDs).

Context Diagram
• Represents the system as a single bubble annotated with the system’s name (noun).

• Shows the external entities interacting with the system, and the data they input and

output.

• Data flows are shown as incoming and outgoing arrows.

• Developed by analyzing the SRS (Software Requirement Specification) to identify users

and data interactions.

• External entities should appear only in the context diagram, not in lower levels.
 Level 1 DFD
• Contains 3 to 7 bubbles representing important functions of the system.

• If the system has more than 7 high-level requirements, combine some into

a single bubble. If less than 3, split some functions.

• Developed by examining the high-level functional requirements in the SRS.

Decomposition

• Each bubble in the DFD represents a system function.

• Decomposition or factoring involves breaking down a function into

subfunctions at the next level.

• Each bubble should be decomposed into 3 to 7 sub-bubbles for clarity.

• Decomposition stops when a function can be described with a simple

algorithm
Construction of DFDs

• Context Diagram: Identifies high-level functions, inputs, outputs, and

interactions from the SRS.

• Level 1 Diagram: Represents each high-level function as a bubble.

• Lower-Level Diagrams: Decompose each high-level function into

subfunctions, showing input, output, and interactions.

• Repeat decomposition recursively until subfunctions are simple.

Numbering Bubbles

•Context diagram bubble is numbered as 0.

•Bubbles at Level 1 are numbered 0.1, 0.2, etc. Children of these are numbered 0.1.1, 0.1.2, etc.

•Numbering provides a clear hierarchy.

Balancing DFDs

•The data entering or leaving a bubble at one level must match the data flow in the corresponding

decomposition at the next level.

•Ensures that parent and child DFDs are consistent.

Depth of Decomposition

•Decomposition should continue until the function can be represented using a simple algorithm.

•Typically, decomposition up to Level 1 or 2 is sufficient for simple problems.

•Large problems may require up to Level 3 or 4.

Common Errors in DFD Modeling
• Drawing more than one bubble in the context diagram.

• Including external entities at levels below the context diagram.

• Creating DFDs with too few or too many bubbles (optimal range: 3 to 7).

• Failing to balance DFDs across different levels.

• Including control information in the DFD (e.g., conditions or triggers for functions).

• Connecting data stores directly to each other or to external entities without processing.

• Overlooking or adding functionality not specified in the SRS.

• Using non-intuitive data or function names.

• Cluttering DFDs with excessive data flow arrows. Solutions include combining data flows into a
higher-level data item.
RMS Calculating Software

• Read three integral numbers from the user in the range of –1000 and
+1000

• Determine the root mean square (RMS) of the three input numbers
and display it.
• The system accepts three integers from the user and returns the
result to him.

• We can see that there are four basic functions that the system needs
to perform
• Accept the input numbers from the user,
• Validate the numbers
• Calculate the root mean square of the input numbers
• Display the result.

• Calculate the mean, and finally calculate the root

Shortcomings of the DFD Model:
• Imprecision:
• DFD labels can be too short to fully describe the function of a bubble.
• Undefined Control Aspects:
• DFDs do not specify control aspects, such as the order in which inputs are consumed
and outputs produced. It also doesn't define the sequence of execution for different
bubbles, making it unsuitable for modelling real-time systems.
• Subjective Decomposition:
• Decomposition into successive levels of DFDs is subjective, depending on the
analyst's judgment.
• Improper Guidance for Decomposition:
• DFD techniques do not provide specific guidance on how to decompose a function
into its subfunctions, relying instead on subjective judgment.