Behavioural Model in Software Engineering

We will discuss the behavioural model in software engineering in this article.

The behavioural model is used to illustrate the dynamic behaviour of the system at the time when the model is executing. The behavioural model depicts what occurs or what should occur when a system reacts to a stimulus from its environment.

There are predominantly two kinds of stimuli that fall under behavioural models: data and event.

• Data: The system receives data that is required to be processed.
• Events: System processing is triggered when a certain event occurs.

Two kinds of behavioural models explain the system's behaviour in software engineering. The two models are the data processing model and the state machine model.

• Data Processing Model: In this model, Data Flow Diagrams (DFDs) represent the system's data processing.
• State Machine Model: In this model, state diagrams represent the system's response to external events.

Data Flow Diagrams (DFDs)

These Diagrams are also called bubble charts. It is used to represent the flow of data through the system. It is a graphical tool for communicating with users, managers, etc. It is a simple technique that assists in analyzing the proposed system. It illustrates the movement of data between external entities & processes and between databases & processes.

Any software you use has many pages, such as a login page, home page, etc. As the user moves from one page to another, it is not only the user moving but data flowing from one module to another. When all these things are represented graphically, it is called a data flow diagram.

DFD Elements

1. Source/ Sinks (External entities): It is an object, and the object is depicted with the help of the rectangle. The source delivers data to the system, and Sink obtains data from the system. Source and Sink are not used for processing data.
2. Data flows: The pipeline carries data and shows the direction of the data flow. It is represented with the help of the annotated arrows. It connects the external entities, processes, and databases. They are usually unidirectional, but if the same data flows in both directions, it is shown by the double-headed arrow.
3. Processes: It means the event that is happening. Processes are represented with the help of the circle. If the data flows toward the object, it is shown by the incoming arrow, and if the data flows away from the object, it is shown by the outgoing arrow.
4. Data Stores: The database stores data and is represented with the help of parallel lines. When data is written or updated in the database, it is denoted by an incoming arrow. When data is read from the database, it is denoted by an outgoing arrow.

Symbols Used in DFD are Shown in the Chart Below

Rules of Data Flow:

• Data should flow from external entities to process.
• Data should flow from the process to the external entity.
• Data should flow from process to store and back.
• Data should flow from process to process.
• Data should not flow from an external entity to an external entity.
• Data should not flow from an external entity to the store.
• Data should not flow from the store to an external entity.
• Data should not flow from store to store.

Levelling in DFD:

DFDs can be drawn to show the system at different levels. Initial or higher levels are divided into lower levels containing more information and functional detail.

Level 0 DFD:

It is also called a fundamental system model or context diagram. It shows the whole system as a single bubble with input and output data symbolized by incoming and outgoing arrows.

Level 0 DFD is divided into multiple bubbles, and each bubble is then divided into more detailed DFDs.

Example:

You can see the diagram below that shows Level 0 DFD for the Airline Reservation System.

It represents the entire reservation system using a single bubble. As we go forward, we will refine this DFD and the single bubble will be divided into multiple bubbles. Each bubble will represent a separate module; these bubbles will transform data.

Level 1 DFD:

When Level 0 is refined, the single bubble is divided into multiple bubbles.

Example:

You can see in the diagram below that a single bubble in the Airline Reservation System is divided into many bubbles.

First, data is received from the flight database and displayed to the external entity, the customer. There is a cancellation module where cancellation details are entered, and cancellation acknowledgement is attained. The seat reservation module shows that customers are reserving their seats. The seat reservation module interacts with the total cost calculation module, where the customer is given the total cost of the ticket. The ticket generation module generates the ticket after payment is done by the customer. The seat allocation module shows the boarding pass generation. These are the major processes in Level 1 DFD.

Level 2 DFD

Each process or module is refined at this level.

Example:

We can refine each module of the Airline Reservation System, but in this example, we will refine the "Reservation Module".

You can see in the diagram above that the external entity "customer" will check the availability of seats. The negative acknowledgement is sent to the customer if seats are unavailable, and the process ends. If seats are available, the number of passengers the customer enters is sent to the further module to collect passenger information. The "Collection of Passengers Information" module stores user details in the database and passes the user details to the "Payment Process" module. The Payment Process tells the customer the ticket cost, and then the customer makes the payment. After the payment is made, the "Payment Process" sends payment acknowledgement to the "Issue Ticket" module and generates a boarding pass for the E-ticket.

State Diagram

It is used to capture the behavioural characteristics of the system. The dynamic aspects of the system are depicted with the use of the state diagram.

State Diagram Elements

• State: It is the movement in the life cycle of an object. A rectangle with round corners is utilized to represent the state.
• Event: It is the trigger to move from one state to another.
• Transition: It represents the direction of movement from one state to another. The annotated arrows are used to represent the transition. The name of the event while transition is mentioned on the arrow.
• The initial state is the starting state, and the filled circle denote the initial state.
• Final state: It is the end state, and the filled circle on the outlined circle denote the final state.
• Decision box: It is used to make the decision. The diamond shape is utilized to denote the decision box.

Symbols used in the state diagram are shown in the chart below:

Examples of the state Diagrams

Example 1:

You can see the following "Order Management System" state diagram, in which there is an initial state and final state of the "Order" object. The first state is an idle state where the process starts. The next states are for events like sending requests, confirming requests and dispatching orders.

During the life cycle of an object, you can see some abnormal exits that may also occur due to some issue in the system. The event "Send Order Request" occurs in an intermediate state. The "Select Normal or Special Order" event occurs from here, a transition. After that, the "Order Confirmation" and the "Dispatch Order" events occur. When the whole life cycle is complete, it is considered a complete transaction.

Example 2:

The "University Form Fill-up System" state diagram can be seen below.

The starting symbol is given in the beginning, and the first state, "Registration", permits students to register their names. The student provides an ID and a password in the "Login" state. If the ID or password is incorrect during the login, the login is cancelled, and the login page reappears.

The next stage is the "Fill-up Form" state, where students fill out the form. The students submit the form after filling it out, and then the student is asked to pay registration fees. The payment is completed in the next state called the "Make Payment". The payment details are sent to the further state, which is the "Print", where the form can be printed or downloaded at this state. The "Make Payment" page is opened again if the payment is unsuccessful. The next state is the "Logout" state, where the student is logged out after the form is printed or downloaded. The end state symbol is used at the end after the completion of all the states.

Data-Driven Modeling

It is the first graphical model to be a data-driven model. These models represent the steps of processing input data and generating an associated output. They are useful in demonstrating end-to-end processing in a system, which aids in requirement analysis. The data-driven models are shown with the help of Data Flow Diagrams that we have already discussed.

Event-driven Modeling

It is the modeling that illustrates the response of the system to internal and external events. It is used to describe the state machine model.

The event-driven models are shown with the help of state diagrams that we have already discussed.

Conclusion

We have comprehended the behavioural model in software engineering in this article, and we have concluded the following points:

• Data and events are two sorts of stimuli in behavioural models.
• The data-processing model and state-machine models are two sorts of behavioural models.
• Data processing is shown using flow diagrams, and the response to the events is shown using state diagrams.
• DFDs depict the data flow between external objects & processes and between processes & databases.
• The state diagrams are used to depict the behaviour of the system.
• These diagrams are utilized for communication between developers, stakeholders, and clients.