DECISION TREE

A decision tree gives a graphic view of the processing logic involved in

decision making and the corresponding actions taken. The edges of a
decision tree represent conditions and the leaf nodes represent the
actions to be performed depending on the outcome of testing the
condition.
• Example: - Consider Library Membership Automation Software (LMS)
where it should support the following three options:
• New member
• Renewal
• Cancel membership
New member option-
• Decision: When the 'new member' option is selected, the software
asks details about the member like the member's name, address,
phone number etc.
• Action: If proper information is entered then a membership record for
the member is created and a bill is printed for the annual membership
charge plus the security deposit payable.
Renewal option-
• Decision: If the 'renewal' option is chosen, the LMS asks for the
member's name and his membership number to check whether he is
a valid member or not.
• Action: If the membership is valid then membership expiry date is
updated and the annual membership bill is printed, otherwise an
error message is displayed.
Cancel membership option-
• Decision: If the 'cancel membership' option is selected, then the
software asks for member's name and his membership number.
• Action: The membership is cancelled, a cheque for the balance
amount due to the member is printed and finally the membership
record is deleted from the database.
The following tree (fig.) shows the graphical representation of the above example.

Fig : Decision Tree of LMS

Decision table

A decision table is used to represent the complex processing logic in a

tabular or a matrix form. The upper rows of the table specify the
variables or conditions to be evaluated. The lower rows of the table
specify the actions to be taken when the corresponding conditions are
satisfied. A column in a table is called a rule. A rule implies that if a
condition is true, then the corresponding action is to be executed.
Example: -
• Consider the previously discussed LMS example. The following
decision table (fig.) shows how to represent the LMS problem in a
tabular form. Here the table is divided into two parts, the upper part
shows the conditions and the lower part shows what actions are
taken. Each column of the table is a rule.
From the above table you can easily understand that, if the valid selection condition is false then the action taken
for this condition is 'display error message'. Similarly, the actions taken for other conditions can be inferred from
the table.
FORMAL SYSTEM
SPECIFICATION
Formal Technique
• A formal technique is a mathematical method to specify a hardware
and/or software system, verify whether a specification is realizable,
verify that an implementation satisfies its specification, prove
properties of a system without necessarily running the system, etc.
The mathematical basis of a formal method is provided by the
specification language.
• Formal Specification Language
• A formal specification language consists of two sets syn and sem, and
a relation sat between them. The set syn is called the syntactic
domain, the set sem is called the semantic domain, and the relation
sat is called the satisfaction relation. For a given specification syn, and
model of the system sem, if sat (syn, sem), then syn is said to be the
specification of sem, and sem is said to be the specificand of syn.
• Syntactic Domains
• The syntactic domain of a formal specification language consists of an
alphabet of symbols and set of formation rules to construct well-
formed formulas from the alphabet. The well-formed formulas are
used to specify a system.
• Semantic Domains
• 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,
synchronization trees, partial orders, state machines, etc.
• Satisfaction Relation
• Given the model of a system, it is important to determine whether an
element of the semantic domain satisfies the specifications. This satisfaction is
determined by using a homomorphism known as semantic abstraction
function. The semantic abstraction function maps the elements of the
semantic domain into equivalent classes. There can be different specifications
describing different aspects of a system model, possibly using different
specification languages. Some of these specifications describe the system’s
behavior and the others describe the system’s structure. Consequently, two
broad classes of semantic abstraction functions are defined: those that
preserve a system’s behavior and those that preserve a system’s structure.
• Model-oriented vs. property-oriented approaches
• Formal methods are usually classified into two broad categories –
model – oriented and property – oriented approaches. In a model-
oriented style, one defines a system’s behavior directly by
constructing a model of the system in terms of mathematical
structures such as tuples, relations, functions, sets, sequences, etc.
• In the property-oriented style, the system's behavior is defined
indirectly by stating its properties, usually in the form of a set of
axioms that the system must satisfy.
• Operational Semantics
• Informally, the operational semantics of a formal method is the way
computations are represented. There are different types of
operational semantics according to what is meant by a single run of
the system and how the runs are grouped together to describe the
behavior of the system.
• Some commonly used operational semantics are as follows:
• Linear Semantics:-
• In this approach, a run of a system is described by a sequence (possibly
infinite) of events or states. The concurrent activities of the system are
represented by non-deterministic interleavings of the automatic actions.
For example, a concurrent activity a║b is represented by the set of
sequential activities a;b and b;a. This is simple but rather unnatural
representation of concurrency. The behavior of a system in this model
consists of the set of all its runs. To make this model realistic, usually
justice and fairness restrictions are imposed on computations to exclude
the unwanted interleavings.
• Branching Semantics:-
• In this approach, the behavior of a system is represented by a
directed graph. The nodes of the graph represent the possible states
in the evolution of a system. The descendants of each node of the
graph represent the states which can be generated by any of the
atomic actions enabled at that state. Although this semantic model
distinguishes the branching points in a computation, still it represents
concurrency by interleaving.
• Maximally parallel semantics:-
• In this approach, all the concurrent actions enabled at any state are
assumed to be taken together. This is again not a natural model of
concurrency since it implicitly assumes the availability of all the
required computational resources
• Partial order semantics:-
• Under this view, the semantics ascribed to a system is a structure of
states satisfying a partial order relation among the states (events).
The partial order represents a precedence ordering among events,
and constraints some events to occur only after some other events
have occurred; while the occurrence of other events (called
concurrent events) is considered to be incomparable. This fact
identifies concurrency as a phenomenon not translatable to any
interleaved representation.
Formal methods possess several positive features, some of which are
discussed below.
• Formal methods usually have a well-founded mathematical basis. Thus,
formal specifications are not only more precise, but also mathematically
sound and can be used to reason about the properties of a specification
and to rigorously prove that an implementation satisfies its
specifications.

• Formal methods have well-defined semantics. Therefore, ambiguity in

specifications is automatically avoided when one formally specifies a
system.
Limitations of formal requirements specification
It is clear that formal methods provide mathematically sound frameworks within large, complex
systems can be specified, developed and verified in a systematic rather than in an ad hoc manner.
However, formal methods suffer from several shortcomings, some of which are the following:
• Formal methods are difficult to learn and use.

• The basic incompleteness results of first-order logic suggest that it is impossible to check
absolute correctness of systems using theorem proving techniques.

• Formal techniques are not able to handle complex problems. This shortcoming results from the
fact that, even moderately complicated problems blow up the complexity of formal
specification and their analysis. Also, a large unstructured set of mathematical formulas is
difficult to comprehend.