क्या यूएमएल व्यावहारिक है? [बन्द है]


114

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

संपादित करें: मेरा अनुभव 10 डेवलपर परियोजनाओं के तहत छोटे तक सीमित है।

संपादित करें: कई अच्छे उत्तर, और हालांकि सबसे क्रिया नहीं, मैं चयनित एक को सबसे संतुलित मानता हूं।


4
2013 के सर्वेक्षण के परिणामों से पता चलता है कि इसका उपयोग उतना अधिक नहीं किया जाता है जितना सॉफ्टवेयर इंजीनियरिंग के प्राध्यापक उम्मीद करते हैं (!) और कुछ कारणों का खुलासा करते हैं: oro.open.ac.uk/35805/8/UML%20in%20ults%208.pdf
फ्यूमरमैन

जवाबों:


47

पर्याप्त रूप से जटिल प्रणाली में कुछ स्थान ऐसे होते हैं जहाँ कुछ UMLको उपयोगी माना जाता है।

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

  • कक्षा आरेख
  • स्टेट डायग्राम
  • गतिविधि आरेख
  • अनुक्रम आरेख

ऐसे कई उद्यम हैं जो उनके द्वारा शपथ लेते हैं और कई जो समय और प्रयास की पूरी बर्बादी करते हैं।

ओवरबोर्ड नहीं जाना सबसे अच्छा है और यह सोचें कि आप जिस प्रोजेक्ट पर हैं उसके लिए सबसे अच्छा है और जो सामान लागू है उसे उठाएं और समझ में आए।


83

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

यह सिर्फ इस बारे में नहीं है कि आप क्या कर रहे हैं। नए किराए के बारे में क्या है जो अब से छह महीने में आता है और कोड पर गति करने के लिए आने की आवश्यकता है? अब से लगभग पांच साल बाद जब परियोजना पर काम कर रहे सभी लोग चले गए हैं?

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

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

अन्य मामला जहां मैंने यूएमएल को उपयोगी पाया है, वह तब है जब एक वरिष्ठ डेवलपर एक घटक को डिजाइन करने के लिए जिम्मेदार है, लेकिन फिर डिजाइन को कार्यान्वित करने के लिए एक जूनियर डेवलपर को सौंप देता है।


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

6
BobTurbo से सहमत हूं, मुझे यूएमएल के लिए कभी कोई फायदा नहीं हुआ, खासकर किसी और के यूएमएल के लिए। मैं हमेशा सीधे कोड पर जाना पसंद करता हूं।
जेम्स एडम

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

1
@ जेम्स एडम, किसी भी आरेख को कोड को देखने के लिए प्रतिस्थापित नहीं किया जाता है, लेकिन सिस्टम के अधिक उच्च स्तरीय अवलोकन वाले कोडबॉसेस (कोड की लाखों पंक्तियों को आज़माएं) में समय और तंत्रिकाओं के ढेर को बचाया जा सकता है।
सेरीन

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

34

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

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


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

बिल्कुल भी सहमत नहीं हैं - यदि आप जटिल घटक बनाते हैं - उमल मस्ट है
तोहटन याहेज़केल

18

जटिल प्रक्रियाओं के लिए सामान्य कार्य-प्रवाह और DFDs बहुत उपयोगी हो सकते हैं। अन्य सभी आरेख (ESPECIALLY UML), मेरे अनुभव में, अपवाद के बिना समय और प्रयास के एक दर्दनाक बर्बादी है।


16

मुझे असहमत होना पड़ेगा, यूएमएल का उपयोग सभी जगह किया जाता है - कहीं भी एक आईटी परियोजना को डिजाइन किया जा रहा है जो आमतौर पर यूएमएल होगा।

अब चाहे इसका उपयोग अच्छी तरह से किया जा रहा हो, यह दूसरी बात है।

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

क्लास डायग्राम रिश्तों को दिखाने की कोशिश करते समय बहुत उपयोगी हो सकता है, साथ ही ऑब्जेक्ट विशेषताओं, जैसे कि दृढ़ता। जब कभी एकल विशेषता या संपत्ति को जोड़ने की बात आती है तो वे आमतौर पर ओवरकिल हो जाते हैं, खासकर जब वे कोड लिखे जाने के बाद अक्सर तारीख से बाहर हो जाते हैं।

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


14

मैं इस बात का उल्लेख करके अपने उत्तर को प्राप्त करूंगा कि मेरे पास बड़े (आईबीएम-जैसे) कॉर्पोरेट विकास वातावरण में अनुभव नहीं है।

जिस तरह से मैं यूएमएल और देखने वाजिब एकीकृत प्रक्रिया है कि यह अधिक है बात कर आप वास्तव में से क्या करने जा रहे हैं के बारे में कर तुम क्या करने जा रहे हैं क्या।

(दूसरे शब्दों में यह काफी हद तक समय की बर्बादी है)


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

2
आप जो करना चाहते हैं उसके बारे में बात करना और लिखना आपको और अन्य मुद्दों को समझने और जल्द से जल्द पकड़ने में मदद करता है।
कामरान बिगली

12

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


वाह। एक उपकरण के बारे में क्या जो कोड के साथ आरेख को बनाए रखता है और इसके विपरीत, जैसे एक साथ?
डैन रोसेनस्टार्क

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

1
@MarcusDowning नहीं, यह बड़े पैमाने पर नए कामों में मदद करता है। यह कोड की तुलना में UML को देखने में तेज है।
कामरान बिगडेल

10

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

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

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

आरेखों का उपयोग किए बिना, हमें छात्रों की कोड फ़ाइलों के माध्यम से एक-एक करके जाने के लिए समय निकालना होगा।


+1 डेटा का अच्छा दृश्य मुद्दों और रुझानों को उजागर करने में मदद करता है अन्यथा अप्रासंगिक विवरण के साथ अस्पष्ट।
व्लादि गुदिम

8

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

  • संचार
  • मानकीकृत डिजाइन / समाधान प्रलेखन
  • डीएसएल (डोमेन विशिष्ट भाषा) परिभाषा
  • मॉडल परिभाषा (UML प्रोफाइल)
  • पैटर्न / एसेट उपयोग
  • कोड जनरेशन
  • मॉडल टू मॉडल ट्रांसफॉर्मेशन

पास्कल द्वारा पोस्टिंग के ऊपर उपयोग सूची को देखते हुए पर्याप्त नहीं है क्योंकि यह केवल आरेख निर्माण के लिए बोलता है। एक परियोजना UML से लाभान्वित हो सकती है यदि उपरोक्त में से कोई भी महत्वपूर्ण सफलता कारक हैं या समस्या वाले क्षेत्र हैं जिन्हें मानकीकृत समाधान की आवश्यकता है।

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


5

यूएमएल ने मेरे लिए वर्षों तक काम किया है। जब मैंने शुरू किया तो मैंने फाउलर के यूएमएल डिस्टिल्ड को पढ़ा जहां उन्होंने कहा कि "पर्याप्त मॉडलिंग / वास्तुकला / आदि करें।" बस आपको जो चाहिए वो इस्तेमाल कीजिये !


4

क्यूए इंजीनियर के दृष्टिकोण से, यूएमएल आरेख तर्क और विचार में संभावित खामियों को इंगित करते हैं। मेरा काम आसान कर देता है :)


3

मुझे लगता है कि यूएमएल उपयोगी है मुझे लगता है कि मुझे लगता है कि 2.0 की कल्पना ने एक बार एक स्पष्ट विनिर्देश को कुछ फूला हुआ और बोझिल बना दिया है। मैं समय आरेखों के संस्करण से सहमत हूं क्योंकि उन्होंने एक शून्य भरा ...

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

कहा जा रहा है कि मुझे निम्नलिखित यूएमएल उपकरण पसंद हैं:

  1. वायलेट - यदि यह किसी भी अधिक सरल थे, तो यह कागज का एक टुकड़ा होगा

  2. Altova UModel - जावा और सी # मॉडलिंग के लिए अच्छा उपकरण

  3. मैजिकड्रॉ - मॉडलिंग के लिए मेरा पसंदीदा वाणिज्यिक उपकरण

  4. पोसीडॉन - हिरन के लिए अच्छे बैंग के साथ सभ्य उपकरण

  5. StarUML - सर्वश्रेष्ठ ओपन सोर्स मॉडलिंग टूल

3

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

विषय से: http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx पर विकास प्रक्रिया के भीतर मॉडल का उपयोग करना

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

आप निम्नलिखित पोस्ट पर मेरी प्रतिक्रिया पढ़ना चाहते हैं:

"अच्छा सॉफ्टवेयर डिजाइन / वास्तुकला" कैसे सीखें? पर /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489


3

यद्यपि यह चर्चा लंबे समय से निष्क्रिय रही है, लेकिन मेरे दिमाग में कुछ महत्वपूर्ण बातें हैं- जोड़ने के लिए अंक।

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

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


2
क्या आपने यूएमएल मानक पढ़ा है? इसमें कोई गणितीय पृष्ठभूमि नहीं है, और इसमें आंतरिक विसंगतियां भी हैं। यह समझना भी बहुत मुश्किल है: उदाहरण के लिए, गोल आयतों का उपयोग दो पूरी तरह से अलग-अलग चीजों के लिए किया जाता है (राज्य मशीनों और क्रियात्मक गतिविधियों में गतिविधियां और गतिविधियां)। यह भयंकर है।
व्यानोलो

2

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

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

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


2

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

अनिवार्य रूप से, यह वास्तव में मायने नहीं रखता कि आप क्या उपयोग करते हैं, आपको बस दो बातों को ध्यान में रखना होगा:

  • आप किसी तरह का आर्किटेक्चर प्लान करना चाहते हैं
  • आप यह सुनिश्चित करना चाहते हैं कि टीम में हर कोई वास्तव में परियोजना नियोजन के लिए उसी तकनीक का उपयोग कर रहा है

यूएमएल सिर्फ इतना है: आप अपनी परियोजनाओं की योजना कैसे बनाते हैं, इस पर एक मानक। यदि आप नए लोगों को किराए पर लेते हैं, तो किसी भी मौजूदा मानक को जानने की अधिक संभावना है - यह यूएमएल, फ्लोकार्ड, नासी-श्नाइडरमैन, जो भी हो - बल्कि आपके घर के सामान में बाहर निकलने के बजाय।

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


2

यूएमएल उपयोगी है, हाँ वास्तव में! मैंने इसके मुख्य उपयोग किए हैं:

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

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


2

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

इसलिए मैंने एक प्रयोग किया और टैग "UML" या "FOWLER" के साथ यहां इसके बारे में एक पोस्ट है। यह सी # के लिए एक सरल विचार था। कॉकबर्न उपयोग के मामलों को प्रोग्रामिंग कंस्ट्रक्शंस के नामस्थान में वर्गीकृत करने का एक तरीका खोजें (जैसे कि वर्ग और आंतरिक वर्ग के नामस्थान या गणना के लिए नामस्थान का उपयोग करके)। मेरा मानना ​​है कि यह एक व्यवहार्य और सरल तकनीक हो सकती है लेकिन अभी भी इसके बारे में सवाल हैं और दूसरों को इसकी जांच करने की आवश्यकता है। यह सरल कार्यक्रमों के लिए अच्छा हो सकता है, जिन्हें एक प्रकार के छद्म डोमेन विशिष्ट भाषा की आवश्यकता होती है, जो बिना किसी भाषा एक्सटेंशन के c # कोड के ठीक बीच में मौजूद हो सकता है।

यदि आप रुचि रखते हैं तो कृपया पोस्ट देखें। यहाँ जाओ ।


2

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

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


2

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


यह इतना आसान नहीं है! यदि आप UML मॉडल को वास्तविक कोड से निकालने के लिए रिवर्स इंजीनियरिंग का उपयोग करते हैं, तो आप अपने UML मॉडल में बहुत विस्तार के साथ समाप्त होते हैं, जो बेकार है। इसमें कोई संदेह नहीं है कि शोधकर्ताओं द्वारा इसका पीछा किया जा रहा है, लेकिन इसे हल करना आसान समस्या नहीं है।
ComDubh

2

जैसे ही आप अपने खेतों और विधियों के साथ एक वर्ग का प्रतिनिधित्व करते हैं, वैसे ही यूएमएल का उपयोग किया जाता है, हालांकि यह यूएमएल आरेख का एक प्रकार है।

यूएमएल के साथ समस्या यह है कि संस्थापकों की पुस्तक बहुत अस्पष्ट है।

यूएमएल सिर्फ एक भाषा है, यह वास्तव में एक विधि नहीं है।

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


1

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


या बहुत कम से कम प्रमुख डिजाइन मुद्दों पर।
सिल्वरकोड

1

UML लोगों की बड़ी टीमों के साथ बड़ी परियोजनाओं के लिए अच्छा लगता है। हालांकि मैंने छोटी टीमों में काम किया है जहां संचार बेहतर है।

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


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

1

मेरा मानना ​​है कि यूएमएल केवल इस तथ्य के लिए उपयोगी है कि यह लोगों को उनकी कक्षाओं के बीच संबंधों के बारे में सोचने के लिए मिलता है। ऐसे रिश्तों के बारे में सोचना शुरू करना एक अच्छा शुरुआती बिंदु है, लेकिन यह निश्चित रूप से हर किसी के लिए एक समाधान नहीं है।

मेरा मानना ​​है कि यूएमएल का उपयोग उस स्थिति के लिए व्यक्तिपरक है जिसमें विकास टीम काम कर रही है।


0

मेरे अनुभव में:

सार्थक कोड आरेख बनाने और संवाद करने की क्षमता किसी भी सॉफ्टवेयर इंजीनियर के लिए एक आवश्यक कौशल है जो नए कोड विकसित कर रहा है, या अन्य कोड को समझने का प्रयास कर रहा है।

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


0

यूएमएल दो तरह से उपयोगी है:

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

  • प्रबंधन का पक्ष: UMl आरेख उस ग्राहक की आवश्यकताओं का दर्पण है जो गलत है: यदि आप यूएमएल के बिना कोड करते हैं, तो हो सकता है कि आपको कई घंटों के काम के बाद बग की आवश्यकता हो। आरेख यूएमएल आपको संभावित विवादास्पद बिंदुओं को खोजने और कोडिंग से पहले हल करने की अनुमति देता है => अपनी योजना बनाने में मदद करें।

आमतौर पर, यूएमएल आरेखों के बिना सभी परियोजनाओं का सतही विश्लेषण होता है या उनका आकार छोटा होता है।

यदि आप लिंक्डइन ग्रुप सिस्टम्स इंजीनियर्स में हैं , तो मेरी पुरानी चर्चा देखें ।


-1

अंत में UML केवल RUP के कारण मौजूद है। क्या हमें जावा / .Net का उपयोग करने के लिए यूएमएल या इसके किसी भी संबंधित सामान की आवश्यकता है? व्यावहारिक उत्तर यह है कि उनके पास अपना डोक्यूमिनेशन (जावाडॉक आदि) है जो पर्याप्त है और हमें अपना काम पूरा करने देता है!

यूएमएल नो थैंक्स।


RUP प्रक्रिया प्रबंधन के बारे में है, UML भाषा के बारे में है। जब आप बहुत से लोगों के साथ व्यवहार करते हैं और एक सामान्य भाषा की आवश्यकता होती है, तो यूएमएल उपयोगी होता है।
प्रोग्रामरनोवाइस

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

-1

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


-2

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


-3

यूएमएल लोगों के भीतर संचार के तरीकों में से एक है। व्हाइटबोर्ड बेहतर है।

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