Visual Paradigm Desktop | 
Visual Paradigm Online
सिस्टम विश्लेषण और प्रक्रिया मॉडलिंग में डूबने पर, डेटा फ्लो डायग्राम (DFD) के अलावा कोई भी अवधारणा इतनी भ्रम उत्पन्न नहीं करती है। यह सॉफ्टवेयर इंजीनियरिंग, बिजनेस विश्लेषण और आर्किटेक्चर में एक मूल बात है। फिर भी, इसकी लंबी उपस्थिति के बावजूद, इसके बारे में गलतफहमी का बड़ा स्तर बना हुआ है। कई प्रैक्टिशनर इसे एक फ्लोचार्ट समझते हैं या यह मानते हैं कि यह लॉजिक फ्लो को दर्शाता है। इन गलतफहमियों के कारण गलत सिस्टम डिजाइन, भ्रमित दस्तावेज़ीकरण और विकास देरी हो सकती है।
यह गाइड शोर को हटा देता है। हम डेटा फ्लो डायग्राम्स के चारों ओर फैली सबसे लंबी चली आ रही गलतफहमियों का विश्लेषण करेंगे, तकनीकी वास्तविकताओं को स्पष्ट करेंगे और सटीक मॉडलिंग के लिए एक मजबूत ढांचा प्रदान करेंगे। चाहे आप एक नए एप्लिकेशन को डिज़ाइन कर रहे हों या मौजूदा एक की जांच कर रहे हों, इन डायग्राम्स के पीछे के सच को समझना सफलता के लिए आवश्यक है।
सबसे व्यापक गलतफहमी यह है कि डेटा फ्लो डायग्राम सिर्फ एक खूबसूरत फ्लोचार्ट है। जबकि इनके दृश्य अंतर्दृष्टि समान हैं, लेकिन उनका उद्देश्य और नोटेशन मूल रूप से अलग है। दोनों को गलती से मिलाने से मॉडल बनते हैं जो वर्णन करते हैंकैसेएक सिस्टम कैसे सोचता है, बल्किक्याडेटा कहाँ जाता है।
यदि आप एक जटिल निर्णय वृक्ष को DFD में दर्शाने की कोशिश करते हैं, तो आप स्पष्टता खो देते हैं। DFD को निष्पादन के क्रम को दिखाने के लिए नहीं बनाया गया है। इन्हें डेटा के निर्भरता को दिखाने के लिए बनाया गया है। एक प्रक्रिया दूसरी के पहले हो सकती है, लेकिन DFD में क्रम मायने नहीं रखता, बशर्ते डेटा प्रवाह सही हो। यह अंतर असिंक्रोनस सिस्टम या वितरित आर्किटेक्चर के नक्शा बनाते समय महत्वपूर्ण है।
एक और सामान्य गलती यह मानना है कि DFD एक प्रक्रिया के आंतरिक तर्क को समझाता है। जब प्रक्रिया बबल (गोला) को देखा जाता है, तो एक स्टेकहोल्डर पूछ सकता है, “यहाँ अंदर क्या होता है?” DFD इसका उत्तर नहीं देता।
DFD में एक प्रक्रिया एक ब्लैक बॉक्स है। यह इनपुट डेटा प्रवाह स्वीकार करती है और आउटपुट डेटा प्रवाह उत्पन्न करती है। आंतरिक एल्गोरिदम, शर्ती कथन या व्यापार नियमों का प्रतिनिधित्व नहीं किया जाता है। यह एक सीमा नहीं है; यह एक विशेषता है। यह विश्लेषकों को ऊंचे स्तर पर सिस्टम को देखने और कोड-स्तरीय विवरणों में फंसे बिना बाहर निकलने की अनुमति देता है।
तर्क को डायग्राम में बल देने की कोशिश करने से भ्रम उत्पन्न होता है। यह डेटा के आंदोलन को छिपा देता है, जो मुख्य लक्ष्य है। यदि आप तर्क दिखाना चाहते हैं, तो फ्लोचार्ट या अनुक्रम आरेख का उपयोग करें। DFD को डेटा के लिए रखें।
पाठक अक्सर एक DFD को देखते हैं और तत्वों की स्थिति से क्रम का अनुमान लगाते हैं। वे सोच सकते हैं कि बाएं तरफ की प्रक्रिया दाएं तरफ की प्रक्रिया से पहले होती है। यह गलत है।
DFD एक प्रणाली के संरचना के स्थिर प्रतिनिधित्व हैं, समय रेखा नहीं। वे नहीं दिखाते हैं:
इस स्थिर प्रकृति के कारण DFD आवश्यकता एकत्र करने के लिए उत्कृष्ट हैं। वे डेटा आवश्यकताओं के दायरे को परिभाषित करते हैं बिना समय संबंधी प्रतिबंधों के जो बदल सकते हैं। एक रियल-टाइम प्रणाली और एक बैच-प्रोसेसिंग प्रणाली के लिए एक ही DFD हो सकता है, भले ही उनके संचालन के समय बहुत अलग हों।
एक डेटा प्रवाह आरेख को अत्यधिक विस्तृत बनाने की ललक रहती है। कुछ लोग मानते हैं कि एक ही आरेख में हर लेनदेन और डेटा बिंदु को शामिल करना बेहतर है। वास्तविकता में, इससे एक ‘स्पैगेटी आरेख’ बनता है जिसे पढ़ना असंभव हो जाता है।
सिद्धांत के अनुसार विघटनमहत्वपूर्ण है। आप संदर्भ आरेख (स्तर 0) से शुरू करते हैं, जो प्रणाली को एक प्रक्रिया के रूप में बाहरी एकाधिकारों के साथ बातचीत करते हुए दिखाता है। फिर आप उस प्रक्रिया को स्तर 1, फिर स्तर 2 और इसी तरह विभाजित करते हैं। प्रत्येक स्तर विशेष रुचि के क्षेत्र में विवरण जोड़ता है।
यदि आप सभी स्तरों को एक दृश्य में फिट करने की कोशिश करते हैं, तो आप बड़ी छवि को देखने की क्षमता खो देते हैं। एक अच्छा मॉडल उच्च स्तर के अवलोकन और आवश्यकता पड़ने पर विशिष्ट विवरण के बीच संतुलन बनाता है। जटिलता को श्रेणीबद्धता के माध्यम से नियंत्रित करना चाहिए, घनत्व के माध्यम से नहीं।
आधुनिक इंटरफेस अक्सर डेटा प्रवाह को भ्रमित करते हैं। हितधारक अपने आरेखों में स्क्रीन, बटन और उपयोगकर्ता बातचीत देखना चाहते हैं। जबकि उपयोगकर्ता बातचीत महत्वपूर्ण है, वह उपयोग केस आरेखों या वायरफ्रेम में आती है, DFD में नहीं।
DFD डेटा का अनुसरण करते हैं, पिक्सेल नहीं। बटन क्लिक एक घटना है जो एक प्रक्रिया को सक्रिय करती है। DFD को उस प्रक्रिया को दिए गए डेटा (उदाहरण के लिए, “लॉगिन क्रेडेंशियल”) की चिंता होती है, न कि दृश्य बटन की। डेटा प्रवाह आरेख में UI तत्वों को मिलाना जानकारी के प्रणाली के माध्यम से वास्तविक गति से विचलित करता है।
इन मिथों को तोड़ने के लिए, हमें निर्माण तत्वों को समझना होगा। एक मानक DFD चार मुख्य तत्वों से मिलकर बनता है। यहां भ्रम ऊपर दिए गए मिथों को बढ़ावा देता है।
| तत्व | आकृति | कार्य | आम भ्रांति |
|---|---|---|---|
| बाहरी एकाई | आयत | सिस्टम के बाहर डेटा का स्रोत या गंतव्य | सोच रहे हैं कि यह सिस्टम के अंदर एक डेटाबेस है |
| प्रक्रिया | वृत्त या गोल कार्यालय | इनपुट डेटा को आउटपुट डेटा में बदलता है | सोच रहे हैं कि यह तर्क या कोड दिखाता है |
| डेटा स्टोर | खुला आयत | वे स्थान जहां डेटा विश्राम करता है | सोच रहे हैं कि यह केवल एक फाइल फोल्डर का प्रतिनिधित्व करता है |
| डेटा प्रवाह | तीर | तत्वों के बीच डेटा की गति | सोच रहे हैं कि यह नियंत्रण संकेतों का प्रतिनिधित्व करता है |
पौराणिक कथाओं से आगे, मॉडल की अखंडता को कमजोर करने वाली व्यावहारिक गलतियाँ हैं। अपने काम की जांच करने के लिए इस जांच सूची का उपयोग करें।
DFD के गलत विचारों का सबसे अधिक भावी प्रभाव खराब डेटाबेस डिज़ाइन है। यदि आप DFD को एक प्रवाह चार्ट के रूप में लेते हैं, तो आप प्रक्रिया क्रम के आधार पर तालिकाओं का डिज़ाइन कर सकते हैं, बजाय डेटा एकाधिकार के।
जब DFD सही होता है, तो डेटा स्टोर आपके डेटाबेस स्कीमा के लिए नक्शा बन जाते हैं। डेटा प्रवाह तालिकाओं के बीच संबंधों को दर्शाते हैं। यदि आप डेटा स्टोर तत्व को नजरअंदाज करते हैं, तो आप एक डेटाबेस बनाने का जोखिम उठाते हैं जो आवश्यक डेटा आवागमन को समर्थित नहीं कर सकता है। उदाहरण के लिए, यदि DFD में एक “ग्राहक आदेश” प्रवाह को “स्टॉक इन्वेंट्री” स्टोर में जाते हुए दिखाया गया है, तो डेटाबेस को इन एकाधिकारों को जोड़ना होगा। यदि DFD अस्पष्ट है, तो विदेशी कुंजियाँ गायब हो सकती हैं या गलत रूप से परिभाषित की जा सकती हैं।
इसके अलावा, यह समझना कि DFD में तर्क नहीं दिखाया जाता है, आपको प्रक्रिया चरणों के आधार पर डेटाबेस को अत्यधिक सामान्यीकृत करने से रोकता है। आप डेटा निर्भरता के आधार पर सामान्यीकरण करते हैं, लेनदेन के क्रम के आधार पर नहीं। इस अंतर के कारण विकास चक्र के बाद के घंटों के रीफैक्टरिंग की बचत होती है।
तो, इन जाल में फंसे बिना आप कैसे आगे बढ़ेंगे? एक विश्वसनीय डेटा प्रवाह आरेख बनाने के लिए इस संरचित दृष्टिकोण का पालन करें।
सभी या सभी उन चीजों की सूची बनाएं जो सिस्टम की सीमा के बाहर हैं और इससे बातचीत करते हैं। इसमें उपयोगकर्ता, अन्य प्रणालियाँ या नियामक निकाय शामिल हैं। आंतरिक विभागों को शामिल न करें, जब तक कि वे अलग प्रणाली के रूप में कार्य न करें।
लेवल 0 आरेख बनाएं। पूरी प्रणाली को केंद्र में एकल प्रक्रिया के रूप में रखें। बाहरी एकाधिकारों को इस प्रक्रिया से जोड़ने वाली रेखाएं खींचें। रेखाओं को प्राथमिक डेटा के आदान-प्रदान के रूप में लेबल करें (उदाहरण के लिए, “अनुरोध फॉर्म”, “भुगतान रसीद”)।
केंद्रीय प्रक्रिया को मुख्य उप-प्रक्रियाओं में तोड़ें। इन्हें प्रणाली के मुख्य कार्यों के रूप में होना चाहिए (उदाहरण के लिए, “आदेश प्रक्रिया”, “इन्वेंट्री अपडेट”, “रिपोर्ट उत्पन्न करें”)। सुनिश्चित करें कि संदर्भ आरेख में प्रणाली में प्रवेश करने वाला सभी डेटा इस स्तर पर कहीं भी प्रवेश करता है।
वह स्थान पहचानें जहां जानकारी को सहेजा जाना चाहिए। यदि प्रक्रियाओं के बीच डेटा प्रवाह होता है लेकिन सहेजा नहीं जाता है, तो यह सिर्फ एक प्रवाह है। यदि यह बना रहता है, तो यह एक स्टोर है। इन स्टोर को संबंधित प्रक्रियाओं से जोड़ें।
यह सबसे महत्वपूर्ण तकनीकी चरण है। एक माता-पिता प्रक्रिया के इनपुट और आउटपुट को उसके बच्चे प्रक्रियाओं के इनपुट और आउटपुट के योग के बराबर होना चाहिए। यदि डेटा प्रवाह लेवल 0 प्रक्रिया में प्रवेश करता है, तो इसे लेवल 1 विभाजन में दिखाया जाना चाहिए। यदि यह गायब हो जाता है, तो आपको तार्किक त्रुटि है।
इसका क्या मतलब है? DFD को गलत करने की कीमत सिर्फ एक सुंदर आरेख नहीं है। यह प्रोजेक्ट डिलीवरी पर वास्तविक दुनिया के प्रभाव के रूप में होती है।
DFD के सिद्धांतों का पालन करके—डेटा पर ध्यान केंद्रित करना, तर्क को नजरअंदाज करना और पदानुक्रम का सम्मान करना—आप इन जोखिमों को कम करते हैं। मॉडल व्यापार और तकनीकी टीम के बीच एक अनुबंध बन जाता है।
डेटा प्रवाह आरेख को समझने के लिए अनुशासन की आवश्यकता होती है। यह सब कुछ एक साथ दिखाने की इच्छा को रोकने की आवश्यकता होती है। यह स्वीकार करने की आवश्यकता होती है कि एक आरेख वास्तविकता का प्रतिनिधित्व है, वास्तविकता नहीं। इसमें डेटा आवागमन और तार्किक प्रवाह के बीच स्पष्ट अंतर रखने की आवश्यकता होती है।
जब आप गलत धारणाओं को हटा देते हैं, तो DFD एक शक्तिशाली उपकरण बन जाता है। यह आवश्यकताओं को स्पष्ट करता है, तर्क में खामियों को उजागर करता है और संचार के पुल के रूप में कार्य करता है। यह एक सुंदर चित्र बनाने के बारे में नहीं है। यह यह सुनिश्चित करने के बारे में है कि आपकी प्रणाली के माध्यम से बहने वाली जानकारी का लेखा-जोखा हो, सुरक्षित हो और कुशल हो।
अपने वर्तमान मॉडल्स को गहराई से देखें। क्या आप तर्क के स्थान पर डेटा दिखा रहे हैं? क्या आप क्रम को निर्भरता से भ्रमित कर रहे हैं? क्या आप एक ही आरेख में बहुत सारे स्तरों को अतिभारित कर रहे हैं? इन गलतफहमियों को सुधारने से आपके सिस्टम विश्लेषण की गुणवत्ता में काफी सुधार होगा। डेटा पर ध्यान केंद्रित करें। सरल रखें। आवश्यकता होने पर विभाजित करें। और हमेशा अपने प्रवाहों को संतुलित रखें।
अंततः, एक अच्छा DFD वह है जिसे कोई भी मैनुअल के बिना पढ़ और समझ सकता है। यही सफलता का वास्तविक मापदंड है।