Synchronous Operations: % Imagine two bubbles (representing functions) directly connected by an arrow. % They are synchronous, like synchronized dancers—they operate at the same speed. j vom “read “ Example: In Figure, the "validate-number" bubble waits for data from "read- number" before starting, and "read-number" waits until "validate-number' finishes. Asynchronous Operations: * Picture two bubbles connected through a data store (like a storage space). ‘* They are asynchronous, operating independently of each other's specd. % Here's why: The first bubble (producer) stores data in the data store. It can store multiple pieces of data before the second bubble (consumer) even uses any. (Bm / | (D) em (Runter ‘Synchronous operation of two bubbles (b) Asynchronous operation of two bubbles FIGURE Synchronous and asynchronous data flow, Data Dictionary whenever you create a model (like a diagram) of how a system works, called a DED. model, you need a data dictionary to go along with it. This dictionary is like a list that tells you about all the different pieces of information in the model. Imagine the model as different levels, like the main view (level 0), a closer look (level 1), and even closer (level 2), and so on. The data dictionary keeps track of everything in all these levels. It tells you what each piece of information is called and what type it is. If you have something made up of smaller parts, like the tolal pay being the regular pay plus vertime pay, the data dictionary helps explain that. It's like a guide to understand the information in the model. ln any software development process, the dictionary is crucial, particularly for the "sons listed below: * A data dictionary is like a shared language guide for developers working on a Project. It's crucial to have a consistent vocabulary for data, so everyone talks about things in the same way. In big projects, different developers might usc different words for the same data, causing confusion, SAK KUMAR SatTO0 Ww* The data dictionary helps developers understand how to build different data structures by breaking them down into their parts. * It’s also handy for impact analysis, which means figuring out how changes to One piece of data might affect different parts of the project. This is super useful when you're checking how, for example, tweaking an input or fixing a bug might impact things. In big systems, the data dictionary can get really complicated and big. Even medium. Sized projects can end up with thousands of entries in the data dictionary. Trying to manage such a huge dictionary by hand becomes tough. That's where computer-aided Software engineering (CASE) tools come in handy. These tools automatically keep track of the data items as you create your system diagram (DFD) and make the data dictionary for you. Designers don't have to do much to create it themselves. These tools also let you ask questions about the data, like figuring out which data affects certain processes or what a specific data item docs. All this is made casicr by storing the data dictionary in a fancy system called a relational database management system (RDBMS). Data Definition The following data definition operators can be used to define composite data items in terms of primitive data items. +: indicates the combination of two data items; for example, a+b stands for a and b. L.] : indicates selection, meaning that any of the data elements shown inside the square bracket has the potential to occur. For instance, [a,b] denotes the possibility that either an or b occurs. 0 : The data that is optional and may or may not be displayed is represented by the contents of the bracket. a+(b) represents either a or a+b occurs, {} : denotes the definition of iterative data; for example, {name}5 denotes five name data. {name}* denotes one or more name data instances. indicates equivalency; for example, a=b+c indicates that a composite data item consists of both b and c. /**/ ; Everything that appears between /* and */ is regarded as a comment. Developing The DFD Model of a System A Data Flow Diagram (DFD) model is like a map showing how input data transforms into output data in a system. It uses a hierarchy of diagrams to represent this process. ‘At the top, you have the level 0 DFD, also known as the context diagram. It's like the DIPAK KUMAR SAHOOcr a re, simple and casy 10 understand. As you go dow tu , peor deals are added gradually, “ m the levels, starting from yo! poll this com fee ee the most abstract view of the system's problem, Bysyou move * o “ ha You break down processes into sub-processes and ial pow data flows bet ween them, Each level introduces more details, and the spans beeome more COMP. For instance, Level 2 might have up to 7 separate rans, Level 3 could have up to 49, and so on, But here's the key: there's only one = gtionary for the whole model. This dictionary holds all the data names and their fitionss making it a reference for understanding the entire DED model. Context Diagram tecontext diagram is like the big picture, the highest-level representation in a Data flow Diagram (DFD) model. It portrays the entire system as one bubble. In this ign, the bubble is named after the software system being developed, usually using soon, Unlike other levels in the DFD model, where bubbles are named with verbs juedon their main function, the context diagram uses a noun to capture the system's ‘untext rather than its functionality. tere 6 DED: Castes dagears'” Javsl 1 DEDFor instance, imagine a context diagram for supermarket software, It would be labelled ‘Supermarket Software.’ This diagram helps to understand the system's surroundings, showing external entities that interact with the system, what data they provide to the system, and what data they receive in retum, Arrows indicate the flow of data into and out of the system, and th arrows are labelled with data names. To create the context diagram, you analyze the Software Requirements Specification (SRS) document. You identify the types of users and external systems interacting with the system, understanding what data they input and receive. "Users" here also includes external systems supplying or receiving data. Level 1 DFD The Level 1 Data Flow Diagram (DFD) shows three to seven important functions of a system. It's created by looking at high-level functional requirements in the Software Requirements Specification (SRS) document. If there are three to seven requirements, cach becomes a bubble on the Level 1 DFD. Input and output data for these functions are then added to the diagram. If there are more than seven requirements, related ones can be combined in Level 1 and split in lower levels. If there are fewer than three requirements, they need to be broken down into subfunctions to have about five to seven bubbles. The goal is to keep the DFD model clear and understandable, Each bubble represents a system function and is decomposed into three to seven subfunctions in successive levels, making the model more systematic, “© Construction of Context Diagram: Examine determine: > Various high-level tasks that the system must complete. > Every high-level function receives data iny function output data. > Connections (data flow) between the hi discovered. the SRS document to put, and every high-level igh-level functions that have been Provide a diagrammatic representation of these high-level function components. This Would create the DFD 0, often known as the top-level data flow diagram (DFD). + Construction of level 1 diagram: Analyse the high-level oj erations outlined in the SRS paper. Each high-level function in the SRS doc Ps tie ‘ument should be represented by a bubble if there are Fequirements. Some of the bubbles must be blended if there are more than seven, Some of th * Construction of lower-level diagrams: Use the following series of a | its component subfunctions: |_ pmax kumar sarioo ns to break down cach high-level function into eeDIPAK KUMAR SAHOO = » Determine cach of the high-level function’s many subfunctions. » Determine which data cach of these subfunctions receives as input » Determine the information that each of the: ubfunctions produce > Determine how these subfunctions communicate with one another (data flow). Make use ofa DFD to diagrammatically represent these aspects. For every subfunction, recursively repeat Step 3 until a subfunction can be expressed by a straightforward algorithm, Numbering of Bubbles The various bubbles that are present in the DED must be numbered. These figures aid in distinguishing any bubble in the DED from its bubble number in a unique way. Typically, the context level bubble has the number 0 given to it to denote the 0 level DED. Level 1 bubbles are numbered, for example, 0.1, 0.2, 0.3, ete. A bubble with the number x will break down into bubbles with the numbers x.1, x.2, x.3, ete. With this numbering approach, we can clearly identify a bubble's level, ancestors, and successors by looking at its number. Balancing DFDs In a Data Flow Diagram (DFD) model, there's a hierarchy where different DFDs represent various levels of details. Balancing a DFD means making sure that the data flows in and out of a sub-diagram match the data flows of its parent diagram. For example, in Figure, in the Level | DFD, data items dl and d3 flow out of bubble 0.1, and d2 flows into it (shown by a dotted circle). When we go to the next level, where bubble 0.1 is broken into three (0.1.1, 0.1.2, 0.1.3), the decomposition is balanced: d1 and d3 flow out, and d2 flows in. Dangling arrows (dl, d2, d3) represent the data flows into or out of a diagram. How far to decompose? Once a bubble has been determined to represent a basic set of instructions, it should not be further disassembled. Decomposition up to level 1 should be sufficient for straightforward issues. Large industrial standard issues, however, might require level 3 or level 4 breakdown. Decomposition above level 4 is rarely, if ever, required. Commonly made errors while constructing a DFD model Creating Data Flow Diagrams (DFDs) is straightforward, but both students and professionals often face common challenges when modelling software systems with DEDs. While learning through experience is valuable, it can be costly in a business setting. Therefore, it's beneficial to recognize and understand the typical mistakesbeginners make when building DED models, so you can actively work to avoid them The errors include: A common error made by novices is to draw many bubbles in the context diagram. The system should be shown as a single bubble in the context diagram, * A lot of novices build DFD models with external clements that show up at all DED levels. A representation of every external entity interacting with the system should be limited to the context diagram. At no other level in the DFDs should the external entities be included. * Having too few or too many bubbles in a DED is a typical mistake. Per schematic, no more than three to seven bubbles should be permitted. ‘This implies that in the subsequent level, every bubble in a DED should break down into three to seven smaller bubbles. A lot of novices leave the DFDs imbalanced at the various levels of a DFD model. ‘* Trying to depict control information in a DFD is a common error made by many novices while creating a DFD model. moat DIPAK KUMAR SAHOO