एक सफल परियोजना के लिए यूएमएल आरेख कितने महत्वपूर्ण हैं? [बन्द है]

Question

मैं एक परियोजना के बीच में हूं और मुझे यूएमएल आरेख (उपयोग के मामले, वर्ग आरेख, आदि) लिखने के लिए कहा गया था। परियोजना बहुत जटिल नहीं है।

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

Comments

आपको इस पोस्ट में रुचि हो सकती है: programmers.stackexchange.com/questions/58084/…

— c_maker

क्षमा करें, लेकिन मुझे UML "तकनीकी बकवास", समय नुक़सान और .. ठीक है, मैं यहाँ रुकूँगा। मैं अब बेहतर महसूस कर रहा हूं।

— चिरॉन

"यदि आपको ग्राहक के लिए भुगतान करने के लिए तैयार होने में अधिक समय लगता है, तो आप इसके लिए भुगतान करना चाहते हैं" इस्तेमाल किया जा सकता है और यह सार्थक होगा:

— पीएचडी

"Should I just be doing other fun stuff like writing code?"तुम्हारा मतलब है: "other stuff that contributes to the bottom line of the project like writing code"निश्चित रूप से?

— स्टुपरयूसर

बेशक आप करते हैं, और आपको शर्ली नहीं कहते हैं।

— स्टुपरयूसर

Answer 1

मैं कुछ समय पहले यूएमएल का बहुत बड़ा प्रशंसक था। मैं भी OMG प्रमाणित हूँ। मैंने इसका उपयोग बड़े उद्यम परियोजनाओं में किया था, जिसमें मैं शामिल था।

आज, मैंने यूएमएल को लगभग पूरी तरह से रोक दिया। कभी-कभी, मैं अनुक्रम आरेख का उपयोग करता हूं जो मुझे सिस्टम के बीच बातचीत का वर्णन करने के लिए बहुत उपयोगी लगता है, लेकिन कोई अन्य चित्र नहीं।

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

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

Comments

आपने कहा कि आप OML प्रमाणित हैं। OML क्या है? एक लेखन त्रुटि?

— B:52овиЈ

हां, यह वस्तु प्रबंधन समूह के लिए OMG था, UML के पीछे जीव => uml.org

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

— थॉमस ओवेन्स

पहला पैराग्राफ बहुत मजेदार है यदि आप सिर्फ ओएमजी को इसके सामान्य अर्थ के साथ पढ़ते हैं ।

— जेएसबी JS

@ Pierre303 मैं सहमत हूं, कि UML के अलावा अन्य विकल्प भी हैं। लेकिन सवाल शुद्ध कोडिंग के विपरीत विनिर्देशन / प्रलेखन टूल का उपयोग करने के बारे में भी है। जब तक टीम वास्तव में इन कार्यों के लिए उपकरण का उपयोग करती है, तब तक कोई मतलब नहीं है कि यह "मतलब" का उपयोग करता है "? क्या आप "[नहीं] बहुत जटिल" परियोजनाओं के लिए भी उपयोगकर्ता कहानियों का उपयोग करते हैं या उन मामलों में समय बर्बाद कर रहे हैं?

— स्कारफ्रिज

Answer 2

योजना महत्वपूर्ण है, लेकिन प्रसिद्ध रणनीतिकार कार्ल वॉन क्लॉज़विट्ज़ चेतावनी देते हैं

कोई भी अभियान योजना दुश्मन के साथ पहले संपर्क से नहीं बचती है

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

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

Comments

But likely a waste of time for documenting your code for future programmers.यदि कोई प्रोजेक्ट UML को प्रलेखन के रूप में उपयोग करना चाहता है, तो यह आमतौर पर रिवर्स इंजीनियरिंग टूल का उपयोग करके बनाया जाता है। विभिन्न उपकरण हैं जो स्रोत कोड से वर्ग और अनुक्रम आरेख (और कभी-कभी कुछ अन्य) उत्पन्न कर सकते हैं, और इन उपकरणों के आउटपुट को दस्तावेज के रूप में कैप्चर किया जाता है।

— थॉमस ओवेन्स

Answer 3

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

केवल यूएमएल लिखने के लिए यूएमएल अनावश्यक नौकरशाही बन जाता है और परियोजना और कोड को बिना किसी लाभ के परिवर्तन के लिए कम अनुकूलनीय बनाता है।

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

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

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

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

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

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

Answer 4

यूएमएल का मूल्य है यदि टीम के सदस्य सामूहिक रूप से इसे समझते हैं और इसे डिजाइन निर्णयों को संक्षेप और संवाद करने का एक उपयोगी तरीका मानते हैं। आपको यह सब जानने की जरूरत नहीं है, बस वह सबसेट जो कि टीम को उपयोगी लगता है।

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

Comments

+1: वास्तव में: UML को एक स्केच के रूप में देखें ।

— रिचर्ड

Answer 5

मैंने एक बार एक टमटम पर काम किया था जहाँ मुझे अनुबंध डेवलपर्स की एक टीम को विदेशों में प्रबंधित करने की आवश्यकता थी।

जो सामान वे पैदा कर रहे थे उनमें से कुछ बहुत भयावह थे (रिमोट कॉन्ट्रैक्ट कोडर्स का एक सामान्य लक्षण - वे वास्तव में आपके कोड के लिए बहुत परवाह नहीं करते हैं, वे बस जल्दी करना चाहते हैं)।

परियोजना का प्रबंधन करने के लिए, मैंने खुद को यूएमएल आरेखों का निर्माण किया और इसे कोड करने के लिए उन्हें सौंप दिया। यह बहुत सफल रहा - यूएमएल में प्रोग्राम लिखने में मुझे इतना समय नहीं लगा, बहुत तेजी से जावा की तुलना में, और यह कुछ ऐसा था जिसे ठेकेदारों का पालन किया जा सकता था और इसके खिलाफ मापा जा सकता था।

एक चेतावनी - वे कई बार रचनात्मक बनना चाहते थे और मेरे मॉडलों से विचलित हो गए, हालाँकि उन मामलों में वे वास्तव में सही थे, और सभी यूएमएल में अंतिम उत्पाद की गुणवत्ता में सुधार हुआ

Comments

+1 - मॉडलिंग के प्रमुख लाभों में से एक है विभिन्न विचारों को बनाना, बदलना, समझना और उनके बारे में तेज़ी से पता लगाना जो आप इसे कोड में कर सकते हैं।

— डंक

Answer 6

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

यदि कोई आपके यूएमएल आरेखों को पढ़कर आपकी परियोजना को समझने की योजना बना रहा है, तो यह संभवतः उनके समय की बर्बादी नहीं है।

Answer 7

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

एक अच्छा मुद्दा बनाया है यहाँ से ragu.pattabi यूएमएल के दो प्रकार के बीच भेद ...

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

जब यूएमएल को have कौशल होना चाहिए ’(10 साल पहले या उससे अधिक) के रूप में देखा गया था, उस समय मैं अपने कई प्रशंसकों के विचारों के कारण शायद इसके खिलाफ था। लेकिन अब इसके पक्ष से बाहर हो गया है, मैं खुद को यह देखने के लिए देख रहा हूं कि यह क्या है - एक उपयोगी उपकरण जिसमें योग्यता है लेकिन सॉफ्टवेयर विकास की चांदी की गोली नहीं है।

Comments

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

— डंक

Answer 8

मैं यूएमएल का उपयोग करता हूं (या यूएमएल के समान एसटीएच :)) जब मैं उन दोस्तों से बात करता हूं जो हम करने वाले हैं। विचारों पर चर्चा करने के लिए। यूएमएल प्रोजेक्ट तैयार करने के लिए नहीं जो मेरे लिए कोड को ऑटोजेनरेट करेगा। मैं यूएमएल में अपनी कक्षाएं बनाने की कल्पना नहीं कर सकता, फिर कोड उत्पन्न कर सकता हूं और बाद में इसे ट्विक नहीं कर सकता। ऐसा कभी नहीं होता। इसलिए आपको कोड से यूएमएल में परिवर्तन लाना होगा। और जब मैं यूएमएल का उपयोग करता हूं तो मैं व्हाइटबोर्ड या पेपर पर आकर्षित करता हूं। एंटरप्राइज आर्किटेक्ट जैसे टूल में कभी नहीं।

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

Answer 9

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

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

मेरा सुझाव है कि आप अपनी परियोजना में समय आवंटित करें और चक्रों में आरेख का निर्माण करें। पहले आपकी परियोजना के उच्च स्तर के पहलुओं को कवर करेगा और बाद के स्तर विवरण पर अधिक ध्यान केंद्रित कर सकते हैं।

विशेष रूप से मामलों का उपयोग कोड से आसानी से नहीं किया जा सकता है (सिस्टम के कई अन्य पहलुओं के विपरीत)। सुनिश्चित करें कि आप उन करते हैं।

Comments

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

— जिम जी।

@JimG। यह सच या असत्य हो सकता है, जो इस बात पर निर्भर करता है कि प्रलेखन कितना विस्तृत है। यदि आप अपने दस्तावेज़ को उच्च-स्तरीय (घटक, प्रमुख वर्गों का प्रमुख विवरण) रखते हैं, तो दस्तावेज़ जल्दी से बासी नहीं होंगे। यदि आप मैन्युअल रूप से हर वर्ग के प्रत्येक सदस्य को दस्तावेज देते हैं, तो आपका काम बहुत जल्दी बेकार हो जाएगा।

— डैनी वारोड

@JimG।, मुझे यकीन है कि आप इस तरह से सोचने वाले अकेले नहीं हैं। तथ्य यह है कि सॉफ्टवेयर बदलता है, विश्लेषण, डिजाइन और कार्यान्वयन दस्तावेजों को पूरी तरह से अप्रचलित नहीं करता है। ऐसा ज्ञान तंत्र जीवन चक्र के दौरान विकसित होता है। यदि आपको आईटी ऑडिट करने वाले संगठनों को सिस्टम सौंपना था, तो आपको प्रलेखन दिखाना होगा, न कि केवल कोड और बायनेरिज़।

— NoChance

@ ईमाद करीम: आईटी ऑडिट करने वाले ओर्गास्म के बारे में - उस डॉक्यूमेंटेशन में से अधिकांश परफेक्ट है और केवल ऑडिट के लिए है। अधिकांश सॉफ्टवेयर देवता इस पर भरोसा नहीं करेंगे।

— जिम जी।

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

— NoChance

Answer 10

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

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

Answer 11

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

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

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

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

Answer 12

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

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

Answer 13

मैं उन्हें बहुत ज्यादा ओवररेटेड पाता हूं। मैं उन्हें केवल उन चित्रों पर विचार करता हूं जो एक हजार शब्दों को चित्रित नहीं करते हैं।

Comments

बिना किसी के हाथ में पेंट और एक ब्रश रखें और यह सब परिणाम साफ करने के लिए एक गड़बड़ है। हालांकि, एक कलाकार के हाथों में पेंट और एक ब्रश रखा जाता है और कला का जन्म होता है। यूएमएल आरेखों के लिए समान है।

— डंक

Answer 14

यूएमएल केवल मूल्य का है अगर सिस्टम को डिजाइन करने वाले लोग खुद कोड नहीं लिख सकते हैं। यानी, UML एक 'भाषा' है, जो किसी अन्य व्यक्ति के लिए वास्तु अवधारणाओं को बताती है, अब यदि आप वह व्यक्ति हैं जो कोड डिजाइन कर रहे हैं और इसे लागू कर रहे हैं, तो आपको खुद को यह दिखाने की आवश्यकता क्यों होगी कि आप क्या करने जा रहे हैं? ?! इसके बजाय कोडिंग के लिए सीधे सिर पर जाएं। आपको अभी भी दस्तावेज बनाना होगा कि आपने बाद में क्या किया, लेकिन समग्र दक्षता तेज है।

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

Comments

LMAO, काला / सफेद? विकास का आपका "सुझाया हुआ" तरीका वह कारण है जो मुझे इतनी बार विनाशकारी परियोजनाओं को साफ करने और ठीक करने के लिए कहा जाता है। कोड डिजाइन नहीं है। ऐसे कुछ लोग हैं, जो मामूली जटिल प्रणाली भी बना सकते हैं (मुझे लगता है कि मुझे उस बयान को स्टैंड-अलोन के रूप में छोड़ना होगा)। और अभी तक, बहुत कम हैं जो सीधे कोड में कूदकर कर सकते हैं। इसके अलावा, आपके पास एक "टूटी हुई" प्रणाली तेज हो सकती है, लेकिन आपके पास कोड में सीधे कूदकर "काम करने वाला" सिस्टम तेज नहीं होगा। लेकिन मुझे लगता है कि यह सब उन परियोजनाओं पर निर्भर करता है जो आपके पास हैं। यदि आधा काम करना ठीक है, तो आपका दृष्टिकोण ठीक है।

— १६'१२ को

Answer 15

मैं कभी यूएमएल का प्रशंसक नहीं था, लेकिन मैं सिस्टम या कार्यों के बीच बातचीत का वर्णन करने के लिए एक अच्छे अनुक्रम आरेख को महत्व देता हूं।

हालाँकि क्लास का आरेख जन्म से पहले अप्रचलित है। एक मोटे डिजाइन के लिए यूएमएल की आवश्यकता नहीं होती है, और एक संपूर्ण दस्तावेज कोड बेस से स्वचालित रूप से निकाला (लाइव) होता है। Javadoc और Doxygen ने पूरी तरह से मैनुअल क्लास आरेख की आवश्यकता का पालन किया है।

प्रलेखन के बारे में बात यह है कि दो स्तर हैं:

• उच्च स्तर (वास्तुशिल्प) निर्णय मैन्युअल रूप से प्रलेखन होना चाहिए
• निम्न स्तर (संस्थाओं संबंधों) तथ्यों को स्वचालित रूप से निकाला जाना चाहिए

Comments

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

— डंक

Answer 16

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

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

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

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

इस प्रकार, आपके प्रश्न का उत्तर वास्तव में है, "यह निर्भर करता है"। इस मामले में, यह लोगों पर निर्भर करता है, परियोजना की जटिलता और यह कितना महत्वपूर्ण है कि सिस्टम ठीक से काम करता है।

Answer 17

मेरे अनुभव से यूएमएल डेवलपर्स के बीच कोड पैटर्न के बारे में और एप्लिकेशन के सामान्य रूप में आर्किटेक्चर के लिए संचार के लिए महत्वपूर्ण है।

Answer 18

मुझे आरेख पसंद हैं, लेकिन अगर मुझे एक बनाने के लिए कहा गया (विशेषकर यूएमएल!), तो मैं दो प्रश्न पूछूंगा:

1. यह किसके लिए है?
2. क्या उन्हें अब इसकी जरूरत है?

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

Answer 19

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

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

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

या तो इसका उपयोग मॉडल अवधारणाओं के आधार पर गतिशील निर्णय लेने के लिए मेटाडाटा के एक प्रत्यक्ष स्रोत के रूप में, या वास्तविक पीढ़ी के कोड में उपयोग किए जाने वाले स्थिर कोड कलाकृतियों को उत्पन्न करने के लिए कोड पीढ़ी का उपयोग करके किया जाता है।

Answer 20

अगर यूएमएल की योग्यता के बारे में, या कार्यक्रमों की वास्तुकला को डिजाइन करने की योग्यता के बारे में नहीं पता है।

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

डिजाइनिंग कार्यक्रमों के बारे में।

1. हर कार्यक्रम में एक डिज़ाइन होता है, भले ही आप इसकी योजना क्यों न बनाते हों। जब कोड लिखा जाता है, तो उसे रिवर्स-इंजीनियर करें। यदि आपने इसकी योजना नहीं बनाई है, तो शर्त लगाएं कि यह एक खराब डिज़ाइन होगा।

2. आवर्ती समस्याओं के लिए ज्ञात पैटर्न का उपयोग करके डिज़ाइन आपको समय की बचत करेगा।

3. यदि आप एक टीम में काम करते हैं, तो समाधानों पर चर्चा करने के लिए, विचारों को प्रसारित करने के लिए, और काम को वितरित करने के लिए बहुत ही व्यावहारिक लेकिन आवश्यक है।