0% found this document useful (0 votes)
10 views26 pages

FSM New

Uploaded by

S
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views26 pages

FSM New

Uploaded by

S
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

EVENT/STATE/DATA DRIVEN

FINITE STATE MACHINE


BEHAVIORAL DESIGN TECHNIQUES

Ms.ALF. Sajeetha

MS.ALF.SAJEETHA - SDLC 1
SOFTWARE BEHAVIORAL METHODS
Software behavioral specification methods are techniques used to define and
describe the behavior of software systems. These methods involve documenting the
functionality, actions, and responses of a software system under various conditions
and inputs. They help in articulating how a system should operate, respond, and
handle different scenarios.
Behavioral specification methods can include various techniques such as formal
methods (mathematical modeling), use cases, state diagrams, flowcharts, and other
documentation to precisely outline the expected behavior of software. These methods
aid in understanding, designing, and validating software systems, ensuring they
function as intended.

MS.ALF.SAJEETHA - SDLC 2
MS.ALF.SAJEETHA - SDLC 3
MS.ALF.SAJEETHA - SDLC 4
DATA-DRIVEN DESIGN ARCHITECTURE
A data-driven architecture is best suited for applications that rely heavily on
managing and manipulating data.
This approach focuses on storing, retrieving, and modifying data and the interactions
between different parts of the application and the data.
A data-driven architecture often includes a centralized data storage location, such as
a database.
It uses data binding and flow techniques to ensure consistency and synchronicity
across the application.

MS.ALF.SAJEETHA - SDLC 5
DATA-DRIVEN DESIGN ARCHITECTURE
In a data-driven design architecture, the data controls the flow and logic of the application
to change your program’s logic and result.

A typical characteristic of a data-driven architecture includes


1. The state of its data primarily determines the application’s state.
2. Data is typically stored in a centralized location, such as a database. Different parts
of the application access and modify the data through defined interfaces.
3. Data binding is often used to keep different parts of the user interface in sync with
the underlying data.
4. Changes to the data can trigger updates to different parts of the application. Still,
the current state of the data often determines the specific actions taken in response
to those changes.
MS.ALF.SAJEETHA - SDLC 6
EVENT-DRIVEN DESIGN ARCHITECTURE
An Event-driven architecture focuses more on reacting to and handling specific events
within the application.
This approach is well-suited for applications that need to respond quickly to changes
in the environment or user input.
Real-time System are often event-driven with minimal data processing. For Example,
a landline phone switching system responds to events such as ‘receiver off hook’ by
generating a dial tone.
Event-driven modeling shows how a system responds to external and internal events.
It is based on the assumption that a system has a finite number of states and that
events may cause a transition from one state to another.

MS.ALF.SAJEETHA - SDLC 7
EVENT-DRIVEN DESIGN ARCHITECTURE
Characteristics of an event-driven architecture include
The application’s state is determined by the events that occur.
Events can be triggered by external sources, such as user input or network responses, or by
internal actions within the application.
When an event occurs, the application reacts by triggering specific actions or workflows
rather than relying on the current state of the data to determine its behavior.
Event-driven architectures often use a publish-subscribe pattern, where different parts of the
application can subscribe to specific events and take action when those events occur.

MS.ALF.SAJEETHA - SDLC 8
STATE MACHINE MODELS
State Diagram is design model used in Software Design Process to describe the
behavior of a system considering all possible states of an object when an event
occurs. These model the behavior of the system in response to external and internal
events. They show the system’s responses to stimuli so are often for modelling real-
time systems.
State Machine models show system states as nodes and events as arcs between these
nodes. When an event occurs, the system moves from one state to another.
State Chart are the integral part of the UML and are used to represent state
machine models.

MS.ALF.SAJEETHA - SDLC 9
FINITE STATE MACHINE
A finite state machine is a mathematical model of computation defined by a list of its states, its
initial state and the inputs that trigger each transition. It can be left as an abstract concept for
illustration or a process implemented in hardware (electronic or mechanical) or software or
some combination. The term is often shortened to just state machine and can be in exactly one
of a “finite” number of states at any given time. The state machine can change from one state
to another in response to some inputs or event. The change from one state to another is called
a transition.
OR
FSM is a computing machine that has a Fixed set of possible states, a set of inputs that
change the state, and a set of possible outputs.
OR
In a regular FSM, the behavior of the system is defined by transitions between a finite set of
states, triggered by inputs, and governed by rules specifying the conditions under which
transitions occur.

MS.ALF.SAJEETHA - SDLC 10
FINITE STATE MACHINE MODELS

MS.ALF.SAJEETHA - SDLC 11
Payment System:
FORMAL SPECIFICATION The machine will accept both cash and electronic
Purpose: payments.
The soda vending machine is designed to Cash payments will be inserted into a designated
dispense various soda beverages upon user slot, and the machine will provide change if
selection and payment. necessary.
Features: Electronic payments can be made using
User Interface: credit/debit cards or mobile payment methods.
The machine will have a user-friendly Dispensing Mechanism: Once a soda is selected
interface with a digital display and a and payment is confirmed, the machine will
selection panel.
dispense the chosen beverage.
The selection panel will consist of buttons
corresponding to different soda options. The dispensing mechanism will release the
selected soda from a refrigerated compartment.
Soda Options:
Change Return:
The machine will offer a variety of soda
options, including popular brands and If a user pays with cash and the machine cannot
flavors. provide the exact change, it will return the change
Each soda option will be associated with a using the coin return slot. MS.ALF.SAJEETHA - SDLC 12
Refill and Maintenance: Power Saving:
The machine will have a system to The machine will be programmed to enter
monitor soda levels. a power-saving mode during periods of
inactivity.
When soda levels are low, the Optional Features:
machine will display a notification
for maintenance and/or refill. Customization:
A secure access panel will allow Some machines may allow users to
authorized personnel to restock customize their soda by choosing the level
sodas and perform maintenance. of carbonation or sweetness.
Security: Digital Advertising:
The digital display could be used for
The machine will be equipped with advertising promotions or displaying
security features to prevent nutritional information.
tampering and unauthorized access.
Sustainability:
There will be a surveillance camera
to monitor the area around the The machine could be designed with eco-
friendly features, such as recyclable
machine. packaging or energy-efficient components.
MS.ALF.SAJEETHA - SDLC 13
MS.ALF.SAJEETHA - SDLC 14
MS.ALF.SAJEETHA - SDLC 15
MS.ALF.SAJEETHA - SDLC 16
MS.ALF.SAJEETHA - SDLC 17
MS.ALF.SAJEETHA - SDLC 18
MS.ALF.SAJEETHA - SDLC 19
MS.ALF.SAJEETHA - SDLC 20
MS.ALF.SAJEETHA - SDLC 21
MS.ALF.SAJEETHA - SDLC 22
MS.ALF.SAJEETHA - SDLC 23
MS.ALF.SAJEETHA - SDLC 24
EXTENDED FINITE STATE MACHINE MODELS
The FSM is used to model a system that has a control part, for example a basic telephone device.
However, if the system has, in addition to the control part, a data part, then an extended FSM can
be used. Extended Finite State Machine (EFSM) is an extension of the traditional Finite State
Machine (FSM) model, which is a mathematical model used to design and describe the behavior of
systems with discrete states. An EFSM can model both control and data parts since it extends the
FSM structure with a set of variables (memory).

An FSM always performs a transition on a given input from one state to another an EFSM however
only performs a transition when a given set of conditions have been satisfied. An EFSM allows you
to also use variables for example you could implement a for loop. This allows you to easily model
algorithms that would otherwise require a combinatorial explosion of states.

EFSMs are commonly used in the specification and verification of software systems, especially in
scenarios where a more detailed representation of system behavior is needed compared to what
a traditional FSM can provide.

MS.ALF.SAJEETHA - SDLC 25
MS.ALF.SAJEETHA - SDLC 26

You might also like