सॉफ्टवेयर डिजाइन pseudocoding द्वारा?


9

क्या आप छद्मकोड पर आधारित विधि के साथ सॉफ्टवेयर डिजाइन करने (यानी नीचे लिखने) का एक अच्छा तरीका जानते हैं?

मैं सॉफ्टवेयर डिजाइन के लिए नया हूं और यूएमएल के बारे में कुछ जानकारी पढ़ता हूं। मेरा विनम्र वर्ग पदानुक्रम अब तक अच्छा है, हालांकि, यह जटिल होने के बाद मुझे लगता है कि "पूरे" चित्र को देखने के साथ मैं भविष्य के विस्तार के लिए एक अलग संरचना का उपयोग कर सकता था। जैसा कि पायथन प्रोटोटाइप करने के लिए अच्छा है मैं सिर्फ लिखना शुरू करने के साथ लगभग ठीक हूं, लेकिन काफी नहीं।

इसलिए मैंने यूएमएल श्रेणी के चित्र बनाने की कोशिश की, लेकिन वे मुझे बहुत मदद नहीं करते हैं। मैं जिन समस्याओं को हल करता हूं, मैं उनके सिर में तुच्छ रूप से कर सकता हूं। एक बार जब मैं वास्तविक तरीकों को छद्म करना शुरू करता हूं, तो मैं अतिरिक्त डिजाइन आवश्यकताओं को नोटिस करता हूं।

तो अगर आप छद्मकोड द्वारा डिजाइन करना चाहते थे, तो आप इसे कैसे करेंगे? मुझे विश्वास है कि मेरे लिए एक विधि है जो कोड के साथ लगभग 1-टू -1 सबसे अच्छा काम करती है। लेकिन अधिकांश यूएमएल सॉफ़्टवेयर विधि का कोड भी नहीं दिखाते हैं (उदाहरण के लिए गोफ में चित्रों के विपरीत)।

किसी ने दावा किया कि यूएमएल केवल प्रलेखन और प्रस्तुति के लिए है और डिजाइन के लिए यह महान नहीं है? मुझे भी वह एहसास मिलता है। मैंने सोचा था कि शुद्ध यूएमएल और कुछ सरलीकृत व्हाइटबोर्ड स्केच सॉफ्टवेयर को डिज़ाइन करने का तरीका थे जब तक कि मुझे एनोगीडी एपीडीटी नहीं मिला।

तो फुर्तीली विकास कुछ है जिसे मुझे बाहर देखना चाहिए या क्या वे बेतरतीब ढंग से उस चुस्त को बुलाते हैं - मुझे लगा कि चुस्त केवल अनुसूची के बारे में है? या मैं गलत तरीके से डिजाइन कर रहा हूं (यूएमएल के साथ) - क्या कोई स्यूडोकोड द्वारा डिजाइन करता है? मैं उसके लिए एक अच्छा उपकरण कैसे खोज सकता हूं?


3
स्टीव मैककोनेल ने अपने बुक कोड कम्प्लीट 2 में स्यूडोकोड प्रोग्रामिंग प्रक्रिया (पीपीपी) का वर्णन किया है । विधि निम्न-स्तरीय डिज़ाइन और कार्यान्वयन पर ध्यान केंद्रित करती है, लेकिन यह एक अच्छा पढ़ा जा सकता है यदि आप इसके बाद हैं।
थिटोन

जवाबों:


8
 I thought agile is about schedule only?

यह सिर्फ प्लानिंग नहीं है। फुर्तीली सॉफ्टवेयर विकास एक विकासवादी विकास और अनुकूली योजना के साथ समय-समय पर पुनरावृत्त वितरण होने के बारे में अधिक है जो उत्पाद के मालिक द्वारा अनुरोधित परिवर्तनों के लिए लचीली प्रतिक्रिया को प्रोत्साहित करता है।

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

मेरे अनुभव में चार्ट को ग्राहक के दृष्टिकोण से समझना बहुत आसान है। वे नेत्रहीन अपील कर रहे हैं और कई बार बहुत रंगीन और आसानी से पालन करते हैं। हालांकि, वास्तविक एप्लिकेशन कोड के साथ डिस्कनेक्ट की प्रकृति के कारण चार्ट बनाए रखना बहुत कठिन है। हर बार जब एप्लिकेशन में परिवर्तन किया जाता है तो डेवलपर को चार्ट सहित सभी दस्तावेज़ीकरण को अपडेट करने के लिए समय निकालना पड़ता है। हालांकि, टीम या कंपनी में बीए होने के बाद उस समस्या को आसानी से समाप्त किया जा सकता है, जो क्लाइंट व्यवसाय प्रक्रिया को अच्छी तरह से समझता है और यूएमएल आरेखों का प्रबंधन कर सकता है।

यूएमएल जैसे उपकरण इस प्रक्रिया को आसान बना सकते हैं लेकिन केवल ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के साथ अच्छी तरह से काम करता है। तकनीकी टीमों के लिए छद्म कोड बहुत आसान है। इस कोड को बनाने की प्रक्रिया वास्तविक प्रोग्रामिंग भाषा विकास चरण की गति को बहुत बढ़ा देती है।

कुछ अन्य विकल्प हैं जिन्हें आप भी देख सकते हैं:

  • डेटा फ्लो आरेख
  • स्टेट डायग्राम
  • प्रक्रिया प्रवाह चार्ट

देखने के लिए अच्छा संदर्भ: सॉफ्टवेयर डिज़ाइन ट्यूटोरियल । इसके अलावा, मैं व्यक्तिगत रूप से Pseudocode या कोड पर एक अच्छा ब्लॉग पढ़ने की सलाह दूंगा? कोडिंग हॉरर द्वारा पोस्ट - पढ़ने के लिए मेरा पसंदीदा ब्लॉग :)

सभी सभी में, कुछ ट्रेड-ऑफ हैं जिन्हें आपको विचार करने की आवश्यकता है।


3
Pseudocode या कोड के लिंक के लिए +1 । बस लानत कोड लिखो।
केविन क्लाइन

@ElYusubov: स्पष्टीकरण के लिए धन्यवाद। ऐसा लगता है कि आप भी UML प्रस्तुति के लिए अधिक है? वास्तविक डिजाइन के लिए मैंने इस पर जोर नहीं दिया? अंत में आप 3 आरेखों का प्रस्ताव करते हैं। क्या उन्हें कुछ विस्तार के लिए कोड के साथ 1-टू -1 बनाया जा सकता है। मेरा मतलब है कि कुछ चीजें जो आरेख में काम करती हैं, कोड के साथ काम नहीं कर सकती हैं - जो मैं बचना चाहता हूं।
जेरनुक

@ गेरेनुक, डेटा फ्लो आरेखों को कोड प्रवाह के साथ 1-टू -1 बनाया जा सकता है। हालांकि, आमतौर पर आरेख का उपयोग घटकों / मॉड्यूल / उपयोग मामलों के बीच उच्च स्तरीय डिजाइन और बातचीत देखने के लिए किया जाता है।
यूसुबोव

3

असेंबली लैंग्वेज में प्रोग्रामिंग करते समय, छद्म कोड लिखना बहुत मायने रखता है। विधानसभा भाषा में मैन्युअल रूप से अनुवाद करने और फिर अनुवाद को डीबग करने के प्रयास को समाप्त करने से पहले एल्गोरिथ्म को सत्यापित किया जा सकता है। यह अभी भी पहली पीढ़ी के संकलित भाषाओं जैसे कि फोरट्रान IV के लिए कुछ मायने रखता है, जहां एकमात्र नियंत्रण निर्माण GOTO था, सभी चर (औपचारिक तर्क को छोड़कर) वैश्विक थे, और चर नाम छह वर्णों तक सीमित थे।

आज हम असेंबली भाषा में बहुत कम प्रोग्रामिंग करते हैं, और मुझे सिर्फ कोड लिखने के बजाय छद्म कोड लिखने में बहुत कम मूल्य दिखाई देता है। एक सभ्य भाषा में, वास्तविक कोड शब्द के लिए लगभग छद्म कोड का पालन करेगा, और छद्म कोड केवल समय की बर्बादी है।

हालाँकि, मैं नीचे कोडिंग शुरू नहीं करता। मैं टीडीडी का पालन करता हूं और एक परीक्षण के साथ शुरू करता हूं। फिर मैं शीर्ष पर कोडिंग शुरू करता हूं, और धीरे-धीरे अपने नीचे से नीचे तक काम करता हूं क्योंकि परीक्षण पास करने के लिए आवश्यक है।

छद्म कोड का विकल्प निम्न-स्तरीय कक्षाओं की 1000 लाइनें नहीं लिख रहा है। इसके बजाय शीर्ष पर शुरू करें, अपने डोमेन के लिए आदर्श लेकिन गैर-मौजूद एपीआई को कॉल करें। फिर एपीआई का निर्माण करें।


जब मैं सिर्फ कोडिंग शुरू करता हूं, तो कभी-कभी मुझे लगता है कि डिज़ाइन-वार मैं कुछ कोड को फैक्टर कर सकता हूं। हालांकि रीफैक्टरिंग ठीक है, फिर भी इसे टाला जा सकता था अगर मैंने पहले सभी कोड के अवलोकन पर देखा होता और कुछ रचनात्मकता का इस्तेमाल किया होता। एक चित्रमय छद्मकोड दृश्य एक संघनित ग्राफ़ में सब कुछ प्रस्तुत कर सकता है। क्या मेरी गलती कहीं और है?
जेरेनुक

2
आपकी गलती इस विश्वास में है कि कोड को रिफलेक्ट करना किसी भी तरह से छद्म कोड को रिफैक्ट करने की तुलना में अधिक काम है। एक आधुनिक आईडीई के साथ यह आसान और तेज है कि वास्तविक कोड लिखने की तुलना में छद्म कोड के साथ गड़बड़ करने के लिए या तो सादे कागज संपादक में कागज पर।
केविन क्लाइन

1

जब आप सभी विधियों को सूचीबद्ध करना छोड़ देते हैं और केवल वंशानुक्रम दिखाते हैं, तब भी मुझे कक्षा के चित्र काफी मुश्किल से लगते हैं। अनुक्रम आरेख अच्छे हैं, लेकिन अजीब लगता है जब मैं उन्हें (शायद सिर्फ मुझे) ड्राइंग कर रहा हूं।

मुझे लगता है कि डेटा प्रवाह आरेख और संरचना चार्ट अधिक उपयोगी हैं (हालांकि संरचना चार्ट आमतौर पर BDUF से जुड़े होते हैं और इसलिए इस समय एहसान से बाहर हैं)। DFDs कार्यात्मक अपघटन के लिए विशेष रूप से उपयोगी हैं। DFD में प्रत्येक "बबल" को अपने स्वयं के DFD में तब तक तोड़ा जा सकता है, जब तक कि आप जो भी विस्तार चाहते हैं उसे प्राप्त न करें।


0

मुझे लगता है कि ग्राफिकल टूल छद्म कोडिंग से बेहतर हैं, लेकिन यूएमएल बस इतना अधिक ओवरकम्प्लिकेटेड है कि यह उन तरीकों से बुरे को जोड़ती है :-)

थोड़ा और स्पष्ट होने के लिए: मुझे लगता है कि प्रोग्रामिंग एक निश्चित समस्या का विश्लेषण करने का एक तरीका है, इसे छोटे घटकों और उनके इंटरैक्शन से अलग करें। यह "एक यात्रा, एक गंतव्य नहीं है", आप लगातार समस्या के बारे में अपने ज्ञान में सुधार करते हैं, इसलिए घटकों का ग्राफ बदल रहा है: परतें दिखाई देती हैं और दूर हो जाती हैं, फ़ंक्शन और डेटा आइटम ऊपर और नीचे जाते हैं, आदि।

इस प्रक्रिया का पालन करने के लिए प्राकृतिक उपकरण एक स्केचबोर्ड है, जितना संभव हो उतना सरल है, लेकिन त्वरित समझ में मदद करने के लिए पर्याप्त जटिल है (समान तार्किक अर्थ के लिए समान रंग, आकार, तीर)। मुझे चांदी की गोली नहीं मिली है, और शायद मैं एक दिन खुद लिखूंगा, लेकिन अब मैं ग्लिफी का उपयोग करता हूं ; प्रीजी के जूमिंग फीचर के साथ संयुक्त यह लगभग सही होगा।

छद्म कोडिंग क्यों नहीं? स्यूडोकोडिंग कार्यान्वयन के लिए एक कदम आगे है, "घटक ग्राफ का क्रमबद्ध रूप", जब आप अभी तक अपने विचारों को आकार देते हैं। अच्छा नहीं है, अपने सिर को सीमित करें। अपने अनुभव में मैंने पाया कि बाद में मैं कोडिंग शुरू करता हूं, कम कोड मुझे फेंकना होगा ...

लेकिन शायद यह इसलिए है क्योंकि मैंने उन सभी को बाहर फेंक दिया कोड लिखा है, इसलिए मुझे अब उन्हें लिखने की ज़रूरत नहीं है, जो अनुभव मैंने उनसे प्राप्त किया है वह सिस्टम डिजाइन करते समय मेरे साथ है? खैर, मुझे बयान को संशोधित करना होगा।

यदि आप अपने ग्राफ के साथ खो गए हैं, और कई समान संभव समाधान देखते हैं, तो pseudocode पर जाएं, या यहां तक ​​कि नकली वस्तुओं के साथ उस कोड को भी लिखें - जावा में, यह लगभग कोई अंतर नहीं है। कोड देखें, उन घटकों की संरचना और उपयोगिता को महसूस करें, इससे आपको अपना ग्राफ ठीक करने और निर्णय लेने में मदद मिलेगी। लेकिन यह केवल तभी काम करता है जब आप उस कोड को फेंकने के लिए तैयार हों यदि आपको लगता है कि यह खराब है। मुझे लगता है कि यह छद्मकोड का लाभ है: इसे रखने के लिए कम प्रलोभन जब यह काम करता है, लेकिन यह संरचना में गलत है (और हमेशा की तरह, आपके पास पर्याप्त समय नहीं है)। :-)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.