लागू करने से पहले या बाद में आपको क्लास डायग्राम बनाना चाहिए?

Question

जिस तरह से आप लाभ उठाने से पहले एक बनाते हैं, तो मैं इसे देखता हूं:

• आगे की योजना बनाना
• परियोजना का अवलोकन

लेकिन आप हार गए:

• समय (काम करते हुए आप कोड लिखते समय शायद दोहराते हैं)

दूसरी ओर, मैं सिर्फ अपने कोड लिखने के बाद उन सभी को बना सकता हूं ताकि इसे भविष्य के डेवलपर्स के लिए एक संदर्भ के रूप में रख सकें।

कौन सा वर्ग आरेखों के उद्देश्य को पूरा करता है और कौन सा अधिक फायदेमंद है?

Comments

प्रश्न यह हो सकता है: "क्या आपको कक्षा के चित्र बनाने चाहिए?"। अन्यथा, लोरेंजो का उत्तर देखें :)

— जय

Answer 1

यदि आप उन्हें पहले बनाते हैं, तो वे डिजाइन चरण का हिस्सा होंगे।

यदि आप उन्हें बनाने के बाद, आप सिर्फ प्रलेखन के लिए उनका उपयोग कर सकते हैं। लेकिन डॉक्यूमेंटिंग बेहतर और तेज है अगर आप डिजाइन और कोडिंग के दौरान ऐसा करते हैं।

वैसे, आप डिजाइन करने में समय नहीं गंवाते हैं! कोडिंग वाला भाग तेज होगा। और बेहतर।

आखिरकार, आपको लगता है कि एक गगनचुंबी इमारत या पुल का डिजाइन करना केवल निर्माण शुरू करने के बजाय समय का नुकसान है?

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

Comments

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

— लुइस एगुइलर

Answer 2

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

Answer 3

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

Comments

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

— सेप

Answer 4

यह डिजाइन का हिस्सा है और इसलिए कार्यान्वयन से पहले बनाया जाना चाहिए। यह कहना नहीं है कि वर्तमान कार्यान्वयन राज्य को प्रतिबिंबित करने के लिए कार्यान्वयन के दौरान / बाद में उन्हें परिष्कृत नहीं किया जा सकता है।

कार्यान्वयन के बाद एक डिज़ाइन प्रदान करना जिसे मैं "काउबॉय कोडिंग" कहूंगा, और निश्चित रूप से आप जंगली जंगली पश्चिम में पनप सकते हैं, लेकिन याद रखें कि काउबॉय आमतौर पर किसी न किसी बिंदु पर मृत हो जाते हैं।

Answer 5

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

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

इसके अलावा, अन्य प्रकार के आरेखों को नहीं भूलना चाहिए। मैंने हमेशा अनुक्रम आरेखों को सबसे अधिक उपयोगी होने के लिए पाया है, और मैं उन्हें अक्सर उपयोग करता हूं जब घटकों के बीच बहुत अधिक संचार होता है।

Answer 6

कार्यान्वयन से पहले। जैसा कि मेरे एक पूर्व सहकर्मी ने एक बार कहा था 'मुझे कोडिंग शुरू करने से पहले जितना संभव हो उतना प्रोग्रामिंग करना पसंद है, और मुझे लगता है कि यह एक अच्छा तरीका है।

Answer 7

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

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

Answer 8

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

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

Answer 9

इससे पहले : यह आपके विचारों को व्यवस्थित करने और आपके इरादे को संवाद करने में मदद करेगा। यहाँ विवरण में मत जाओ।

बाद में : यह स्वचालित रूप से निर्माण प्रक्रिया के भाग के रूप में कोड से उत्पन्न होता है, जाहिर है (आशा है कि आप बहुत अधिक संलग्न नहीं हैं)

दोनों उपयोगी हैं, लेकिन लागू होने से पहले ही सामान को फेंक दिया जा सकता है ... यह इस बिंदु पर पहले से ही आउट-डेटेड है।

Answer 10

Topcased के साथ , मैं डिजाइन चरण के दौरान अपने वर्ग आरेख बनाता हूं। फिर मैं अपने कार्यान्वयन के कैनवास के उत्पादन के लिए "जनरेट कोड" बटन पर क्लिक करता हूं। फिर मैं कोड के साथ प्लेसहोल्डर्स को भरता हूं।

Answer 11

मैं जवाब के लिए वोट करने जा रहा हूँ (सी) परेशान मत करो।

वे काफी हद तक अनावश्यक हैं। व्यक्तिगत रूप से, मैं कभी भी उन्हें देखने के लिए परेशान नहीं होता जब उन्हें प्रदान किया जाता है।

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

बाद में, वे अनावश्यक दस्तावेज हैं। यदि आप यह पता नहीं लगा सकते हैं कि कक्षाएँ क्या कर रही हैं या वे एक-दूसरे से थोड़े कोड के निरीक्षण से कैसे संबंधित हैं, तो आपके पास सॉफ़्टवेयर डेवलपर के रूप में आपके कौशल में एक छेद है।

बेशक, यह जवाब वास्तव में अभिमानी और राय लगता है; ओह अच्छा।

Answer 12

एफिल और संबंधित उपकरणों के साथ यह केवल एक ही अंतर्निहित फाइलों की ओर इशारा करते हुए सभी दृष्टिकोणों का अंतर है।