Visual Paradigm Desktop | 
Visual Paradigm Online
डायग्रामिंग सिस्टम विश्लेषण और सॉफ्टवेयर डिज़ाइन में एक मूलभूत कौशल है। यह अमूर्त अवधारणाओं को दृश्य संरचनाओं में बदलता है जिन्हें टीमें समझ और आलोचना कर सकती हैं। हालांकि, दो विधियाँ अक्सर प्रैक्टिशनर्स में भ्रम पैदा करती हैं: डेटा फ्लो डायग्राम (DFD) और फ्लोचार्ट। जब तक दोनों प्रक्रियाओं का प्रतिनिधित्व करते हैं, लेकिन वे अलग-अलग उद्देश्यों के लिए होते हैं, अलग-अलग प्रतीकों का उपयोग करते हैं और सिस्टम व्यवहार के अलग-अलग पहलुओं पर ध्यान केंद्रित करते हैं। गलत उपकरण चुनने से गलत संचार, दोषपूर्ण तर्क या अकुशल विकास चक्र के नतीजे हो सकते हैं। यह मार्गदर्शिका दोनों विधियों के स्पष्ट, विश्वसनीय विश्लेषण की पेशकश करती है।
आवश्यकताओं के एकत्रीकरण, सिस्टम आर्किटेक्चर या प्रक्रिया सुधार में शामिल किसी भी व्यक्ति के लिए इन डायग्रामों के बीच बारीकियों को समझना आवश्यक है। यह दस्तावेज़ तकनीकी विशिष्टताओं, व्यावहारिक अनुप्रयोगों और महत्वपूर्ण अंतरों का अध्ययन करता है ताकि सटीक मॉडलिंग सुनिश्चित की जा सके।
एक फ्लोचार्ट एक एल्गोरिदम, वर्कफ्लो या प्रक्रिया का एक आलेखीय प्रतिनिधित्व है। यह एक विशिष्ट परिणाम प्राप्त करने के लिए लिए गए चरणों के क्रम को नक्शा बनाता है। फ्लोचार्ट का मुख्य ध्यान है नियंत्रण प्रवाह। यह एक प्रक्रिया के शुरू से लेकर अंत तक जाने के तर्क का विवरण देता है, जिसमें निर्णय बिंदु, लूप और शर्ती रास्ते शामिल हैं।
फ्लोचार्ट एक मानकीकृत आकृतियों के सेट पर निर्भर करते हैं, जो अक्सर ANSI या ISO मानकों से जुड़े होते हैं। प्रत्येक आकृति के क्रिया के बारे में एक विशिष्ट अर्थ होता है:
तर्क के प्रवाह को इन आकृतियों को जोड़ने वाले तीरों द्वारा दर्शाया जाता है। इस दृश्य वर्गीकरण के कारण विश्लेषक एक कार्यक्रम या व्यावसायिक प्रक्रिया के निष्पादन मार्ग का अनुसरण कर सकते हैं। यह विशेष रूप से विशिष्ट स्थितियों में सिस्टम के व्यवहार को दस्तावेज़ीकरण के लिए उपयोगी है।
फ्लोचार्ट तब आदर्श होते हैं जब जटिलता है तर्क और निर्णय लेने में प्रक्रिया के भीतर। निम्नलिखित परिदृश्यों पर विचार करें:
फ्लोचार्ट की ताकत इसकी शाखाओं को दिखाने की क्षमता है। यदि उपयोगकर्ता अमान्य डेटा दर्ज करता है, तो फ्लोचार्ट स्पष्ट रूप से उन्हें सुधार चरण की ओर निर्देशित करता है। यदि डेटा मान्य है, तो यह प्रसंस्करण चरण में आगे बढ़ता है। नियंत्रण तर्क पर ध्यान केंद्रित करना ही इसे डेटा-केंद्रित मॉडल से अलग करता है।
एक डेटा फ्लो डायग्राम (DFD) एक संरचित विश्लेषण उपकरण है जिसका उपयोग एक प्रणाली के भीतर जानकारी के प्रवाह का प्रतिनिधित्व करने के लिए किया जाता है। फ्लोचार्ट के विपरीत, DFD क्रियाओं के क्रम या घटनाओं के समय को नहीं दिखाता है। इसके बजाय, यह डेटा गतिशीलतापर ध्यान केंद्रित करता है। यह दिखाता है कि डेटा को प्रणाली के विभिन्न भागों के बीच कैसे परिवर्तित, संग्रहीत और स्थानांतरित किया जाता है।
DFD के लिए विशिष्ट प्रकार के प्रतीकों का उपयोग किया जाता है जो यूरडॉन/डेमार्को या गेन एंड सर्सन जैसी विधियों द्वारा परिभाषित किए गए हैं। इसका ध्यान डेटा के स्वयं पर होता है, न कि उसके नियंत्रण करने वाले तर्क पर।
DFD में एक महत्वपूर्ण नियम है कि दो डेटा भंडारों के बीच बिना प्रक्रिया के सीधे डेटा प्रवाह नहीं हो सकता है, न ही किसी बाहरी एकाई से डेटा भंडार तक बिना प्रक्रिया के सीधे प्रवाह हो सकता है। इससे यह सुनिश्चित होता है कि सभी डेटा संग्रहण में किसी प्रकार के परिवर्तन या प्रबंधन शामिल होता है।
DFD हीरार्किक होते हैं। जटिलता को प्रबंधित करने और आवश्यकतानुसार विस्तार से जानकारी प्रदान करने के लिए इन्हें स्तरों में बांटा जाता है।
DFD का उपयोग सर्वोत्तम होता है कार्यात्मक आवश्यकताओं प्रणाली के लिए। ये रुचि रखने वाले पक्षों को समझने में मदद करते हैं कि प्रणाली किस डेटा को संभालती है और वह कैसे आगे बढ़ता है। उपयोग के मामले इस प्रकार हैं:
DFD का प्राथमिक लाभ यह है कि यह समय और तर्क को अलग कर देता है, और केवल सूचना संरचना पर ध्यान केंद्रित करता है। यह प्रश्न का उत्तर देता है: “डेटा कहाँ जाता है?” बजाय “प्रणाली कैसे तय करती है कि क्या करना है?”
जबकि दोनों आरेख तीर और बॉक्स का उपयोग करते हैं, उनका आधारभूत दर्शन में महत्वपूर्ण अंतर होता है। दोनों को गलती से मिलाने से एक मॉडल बनता है जो प्रणाली की वास्तविक प्रकृति को नहीं पकड़ पाता।
| विशेषता | फ्लोचार्ट | DFD |
|---|---|---|
| फोकस | नियंत्रण प्रवाह (तर्क और क्रम) | डेटा प्रवाह (गति और रूपांतरण) |
| प्रतीक | ओवल, आयत, हीरे | वर्ग, वृत्त, खुले आयत |
| तीर | चरणों के क्रम को दर्शाते हैं | डेटा की दिशा को दर्शाते हैं |
| समय | क्रम और समय को संकेतित करता है | क्रम या समय को संकेतित नहीं करता है |
| निर्णय बिंदु | केंद्रीय (हीरे) | कोई नहीं (तर्क प्रक्रियाओं में छिपा है) |
| डेटा स्टोरेज | स्पष्ट रूप से दिखाया नहीं गया | स्पष्ट रूप से दिखाया गया (रिपॉजिटरी) |
| सर्वोत्तम उपयोग | प्रोग्राम तर्क, वर्कफ्लो | सिस्टम आर्किटेक्चर, आवश्यकताएं |
सबसे महत्वपूर्ण अंतर नियंत्रण की अवधारणा है। एक फ्लोचार्ट नियंत्रण का नक्शा है। यह आपको बताता है कि अगला क्या होगा। यदि शर्त A पूरी होती है, तो चरण B पर जाएं। नहीं तो चरण C पर जाएं। यह प्रोग्रामिंग और संचालन प्रक्रियाओं के लिए निर्णायक है।
एक DFD डेटा का नक्शा है। यह आपको बताता है कि कौन सी डेटा उपलब्ध है और वह कहां यात्रा करती है। यह यह नहीं चाहता है कि चरण B चरण C से पहले होता है या नहीं। DFD में प्रक्रियाएं समानांतर, क्रमिक या असमानांतर रूप से चल सकती हैं। आरेख सिर्फ यह दिखाता है कि प्रक्रिया 1 डेटा X उत्पन्न करती है, और प्रक्रिया 2 डेटा X का उपयोग करती है।
फ्लोचार्ट आमतौर पर डेटा स्टोरेज को शामिल नहीं करते हैं। वे क्रिया पर ध्यान केंद्रित करते हैं। यदि एक फ्लोचार्ट फाइल के बारे में बात करता है, तो यह आमतौर पर एक छोटा इनपुट/आउटपुट चरण होता है। DFD में डेटा स्टोर प्रथम श्रेणी के नागरिक होते हैं। वे सिस्टम की मेमोरी का प्रतिनिधित्व करते हैं। डेटा स्टोर की पहचान जल्दी करना डेटाबेस डिज़ाइन के लिए महत्वपूर्ण है। DFD विश्लेषक को स्थायित्व के बारे में सोचने के लिए मजबूर करता है, जबकि फ्लोचार्ट रैखिक निष्पादन के बारे में मानता है।
चित्र बनाना आसान है; सटीक और उपयोगी चित्र बनाना एक विद्या है। इन विधियों के बीच बदलते समय या स्पष्ट रणनीति के बिना बनाते समय कई आम गलतियां होती हैं।
एक आम गलती डेटा प्रवाह आरेख (DFD) के अंदर निर्णय हीरे रखना है। DFD तर्क को संभालते नहीं हैं। यदि कोई प्रक्रिया किसी शर्त पर निर्भर है, तो उस शर्त का वर्णन प्रक्रिया के साथ दिए गए पाठ में किया जाना चाहिए, न कि हीरे के रूप में बनाया जाना चाहिए। इससे आरेख डेटा पर केंद्रित रहता है।
DFD में, प्रत्येक डेटा स्टोर के कम से कम एक इनपुट और एक आउटपुट प्रवाह होना चाहिए (जब तक कि यह एक मृत डेटा स्टोर नहीं है, जो दुर्लभ है)। यदि एक डेटाबेस मौजूद है लेकिन कोई प्रक्रिया उसमें लिखती या पढ़ती नहीं है, तो आरेख दोषपूर्ण है। इसी तरह, फ्लोचार्ट में, प्रत्येक निर्णय हीरे के कम से कम दो बाहरी पथ होने चाहिए।
तीरों और आकृतियों पर लेबल सटीक होने चाहिए। “डेटा” एक लेबल नहीं है। “ग्राहक आदेश विवरण” एक लेबल है। “डेटा प्रोसेस करें” कमजोर है। “आदेश की पुष्टि और स्टोर करें” मजबूत है। स्पष्ट नामकरण प्रथाएं विकास के दौरान गलत व्याख्या से बचाती हैं।
एक ही आरेख में बहुत कुछ फिट करने की कोशिश करने से पठनीयता कम हो जाती है। यदि एक प्रक्रिया बॉक्स में 5 से 7 उप-प्रक्रियाओं से अधिक हैं, तो उसे निचले स्तर के DFD में विभाजित किया जाना चाहिए। लक्ष्य जटिलता को प्रबंधित करना है, न कि छिपाना।
अपने आरेखों के उद्देश्य को पूरा करने की गारंटी देने के लिए निम्नलिखित दिशानिर्देशों का पालन करें। ये अभ्यास चित्रण उपकरण के प्रकार पर निर्भर नहीं करते हैं।
दोनों प्रवाहचित्र और DFDs सॉफ्टवेयर विकास जीवनचक्र (SDLC) के अनिवार्य हिस्से हैं, लेकिन वे अलग-अलग चरणों में दिखाई देते हैं।
प्रारंभिक चरण के दौरान, DFDs अक्सर मुख्य उपकरण होते हैं। वे सूचना प्रसंस्करण के संदर्भ में यह निर्धारित करने में मदद करते हैं कि प्रणाली क्या करनी चाहिए। वे यह पहचानने में मदद करते हैं कि कौन-से इनपुट आवश्यक हैं और कौन-से आउटपुट अपेक्षित हैं। इससे तकनीकी टीम को व्यापार लक्ष्यों के साथ मिलाया जाता है।
जैसे ही प्रोजेक्ट डिजाइन के चरण में आता है, प्रवाहचित्र अधिक प्रासंगिक हो जाते हैं। DFD से प्राप्त उच्च स्तरीय आवश्यकताओं को विशिष्ट तर्क प्रवाह में बदला जाता है। डेवलपर्स DFD में पहचाने गए डेटा को प्रसंस्कृत करने वाले एल्गोरिदम को लागू करने के लिए प्रवाहचित्र (या पसोडोकोड) का उपयोग करते हैं।
दोनों आरेख परीक्षण के दौरान संदर्भ बिंदु के रूप में कार्य करते हैं। प्रवाहचित्र में पथों से परीक्षण मामले निकाले जा सकते हैं। DFD में प्रवाहों से डेटा अखंडता जांच निकाली जा सकती है। जब बदलाव की आवश्यकता होती है, तो इन आरेखों को अद्यतन करने से यह सुनिश्चित होता है कि दस्तावेज़ीकरण सटीक बना रहे।
एंटरप्राइज स्तर की प्रणालियों के लिए, सरल आरेख पर्याप्त नहीं हो सकते हैं। इन दोनों विधियों के बीच के अंतर को पाटने के लिए उन्नत मॉडलिंग तकनीकें मौजूद हैं।
प्रवाहचित्र का एक विकल्प, स्विमलेन आरेख ज़िम्मेदारी के लिए एक आयाम जोड़ता है। वे यह दिखाते हैं कि कौन प्रत्येक चरण करता है। जब कई विभाग एक साथ बातचीत करते हैं, तो यह उपयोगी होता है। यह प्रवाहचित्र की तर्कवादितता और संगठनात्मक संदर्भ को जोड़ता है।
ऐसी प्रणालियों के लिए जहां किसी वस्तु की स्थिति महत्वपूर्ण होती है (जैसे एक आदेश का “भुगतान किया गया” से “भेजा गया” में बदलना), प्रवाहचित्र बहुत रैखिक हो सकते हैं। राज्य आरेख घटनाओं द्वारा उत्प्रेरित राज्यों के बीच संक्रमण को दिखाते हैं। यह DFDs से अलग है, जो डेटा गति पर ध्यान केंद्रित करते हैं, और प्रवाहचित्रों से अलग है, जो प्रक्रियात्मक चरणों पर ध्यान केंद्रित करते हैं।
व्यवहार में, टीमें अक्सर दोनों का उपयोग करती हैं। एक DFD प्रणाली की सीमाओं और डेटा संरचना को परिभाषित करता है। एक प्रवाहचित्र एक विशिष्ट प्रक्रिया के भीतर के तर्क को परिभाषित करता है। उदाहरण के लिए, एक DFD दिखाता है कि “आदेश प्रसंस्करण” एक प्रक्रिया है। एक प्रवाहचित्र फिर उस “आदेश प्रसंस्करण” के आंतरिक तर्क को विस्तार से बताता है कि यह क्रेडिट कार्ड की प्रमाणीकरण कैसे करता है और स्टॉक की जांच कैसे करता है।
DFD और प्रवाहचित्र में चयन करना यह नहीं है कि कौन बेहतर है। यह यह जानने के बारे में है कि विशिष्ट प्रश्न के लिए कौन उपयुक्त है। यदि आप जानना चाहते हैं कि डेटा कैसे आगे बढ़ता है, तो DFD का उपयोग करें। यदि आप जानना चाहते हैं कि निर्णय कैसे लिए जाते हैं, तो प्रवाहचित्र का उपयोग करें।
दोनों को सीखने से व्यापक प्रणाली मॉडलिंग संभव होती है। यह सुनिश्चित करता है कि संरचना ठीक है (DFD) और तर्क कार्यान्वित किया जा सकता है (प्रवाहचित्र)। मानकों का पालन करने और सामान्य त्रुटियों से बचने से आप ऐसा दस्तावेज़ीकरण बना सकते हैं जो समय के परीक्षण को सहन कर सके और तकनीकी और गैर-तकनीकी टीमों के बीच स्पष्ट संचार को सुगम बना सके।
याद रखें कि आरेख जीवंत दस्तावेज़ होते हैं। वे प्रणाली के विकास के साथ विकसित होने चाहिए। नियमित समीक्षा और अद्यतन सुनिश्चित करते हैं कि दृश्य प्रतिनिधित्व संचालन की वास्तविकता का सही प्रतिबिंब बना रहे। चाहे आप एक सरल कार्यप्रवाह का नक्शा बना रहे हों या एक जटिल एंटरप्राइज आर्किटेक्चर, स्पष्टता किसी भी आरेखण प्रयास का अंतिम लक्ष्य है।
आवश्यकताओं से शुरुआत करें। सीमा को परिभाषित करें। आवश्यकता के अनुरूप उपकरण का चयन करें। और सटीकता के साथ दस्तावेज़ीकरण करें। इस अनुशासित दृष्टिकोण से बेहतर प्रणालियाँ बनती हैं और गलतफहमियाँ कम होती हैं।