"यूएमएल कभी भी एमडीडी के लिए सबसे खराब चीज है।" क्यों?


17

विलियम कुक ने एक ट्वीट में लिखा है कि:

" यूएमएल कभी भी एमडीडी के लिए सबसे खराब चीज है। सौभाग्य से कई लोगों को अब यह पता चला है ... "

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

मैंने देखा है कि बहुत से लोग UML को पसंद नहीं करते हैं। यह भी उल्लेखनीय है कि वह एकेडेमिया में हैं, जहाँ यूएमएल प्रभावी डिजाइन और मॉडलिंग की पवित्र कब्र है।


15
मैं कहूंगा कि MDD सबसे बुरी चीज है जो कभी भी MDD के साथ हुई है।
माइकल बोर्गवर्ड

जवाबों:


39

खैर, मैं अकादमिक हूं जिसने मूल ट्वीट पोस्ट किया है। ट्वीट्स का मतलब विद्वतापूर्ण लेख नहीं है। वे विज्ञापन हैं, और मुझे लगता है कि वे विवादास्पद भी हो सकते हैं। यहाँ मेरे अनुवर्ती ट्वीट हैं:

1) UML को OO डिजाइन बनाने के लिए बनाया गया था। यह प्रभाव है कि आप एक सिस्टम के कोड को मॉडलिंग कर रहे हैं, सिस्टम के व्यवहार को नहीं। यूएमएल गलत स्तर पर है।

2) यह विचार कि यूएमएल में 7 (या 13) आरेख प्रारूप सब कुछ पागल कर सकते हैं। GUIs, वेब वायरफ्रेम, प्राधिकरण, आदि के बारे में क्या ???

3) यूएमएल ने इस विचार को प्रोत्साहित किया है कि मॉडल को चित्रमय होना चाहिए। हास्यास्पद! पाठ और ग्राफिक मॉडल दोनों उपयोगी और अक्सर विनिमेय हैं

4) यूएमएल एक बार बहुत बड़ा और जटिल है और एक ही समय में बहुत सीमित है। प्रयोग करने योग्य एक्सटेंशन के लिए स्टीरियोटाइप और प्रोफाइल प्रभावी नहीं हैं।

ध्यान दें कि मैं जरूरी नहीं कह रहा हूं कि यूएमएल खराब है। मैं बस यह कह रहा हूं कि यह "मॉडल-संचालित विकास" के लक्ष्य की मदद नहीं कर रहा है, जो कि मुझे इसमें दिलचस्पी है। मैं "पवित्र कब्र" के बारे में टिप्पणी को नहीं समझता।


10
+1 खोजने और अपने खुद के ट्वीट के बारे में एक सवाल का जवाब देने के लिए!
वॉरेन पी

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

1
@Warren P: आप MDD और UML के बारे में क्या पसंद करते हैं?
dan_l

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

मुझे लगता है कि "पवित्र ग्रिल" टिप्पणी सिखाई जाने की आवृत्ति के संदर्भ में है।

8

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


मजेदार बात यह है कि यह मौजूद है harborfreight.com/impact-screwdriver-set-with-case-37530.html
Buddhi741

3

मुझे लगता है कि एक मामला यह भी है कि एमडीडी सबसे खराब चीज है जो यूएमएल के साथ हुई (इसके अलावा हमारे पास यूएमएल 2 क्यों होगा?), लेकिन इस बात को नजरअंदाज करते हुए ...

एमडीडी = मॉडल संचालित <डिजाइन | विकास>। विचार समस्या डोमेन के लिए उपयुक्त अमूर्त के स्तर पर समाधान विकसित करने में सक्षम होना है - अर्थात, यह उन समाधानों को व्यक्त करने के लिए सबसे प्राकृतिक वाक्यविन्यास में समस्याओं का समाधान व्यक्त करने का एक प्रयास है। समस्या डोमेन स्वयं एक परिचालन मॉडल (जो एक मॉडल द्वारा कंप्यूटर द्वारा निष्पादित किया जा सकता है) की विशेषता है। तो, MDD एक बहुत ही आकर्षक दृष्टिकोण हो सकता है, भले ही दो प्रमुख आवश्यकताओं के साथ एक:

  1. कंप्यूटर निष्पादन के लिए उपयुक्त रूप में उस भाषा को संकलित करने में सक्षम होना चाहिए (मॉडल का संचालन होना चाहिए ); तथा
  2. समस्या डोमेन के लिए एक मॉडलिंग भाषा बनाना होगा।

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

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

    किसी भी स्थिति में, MDD का वादा अधूरा है। UML को सबसे खराब चीज माना जा सकता है जो MDD को हुई क्योंकि इसने MDD टूल डेवेलपर्स का ध्यान उन मॉडल्स के बहिष्कार पर रखा जो वास्तव में काम कर सकते हैं (सॉफ्टवेयर समस्याओं के एक छोटे से सेट के लिए)।


  • -2

    जब तक यह सिर्फ एक मॉडलिंग भाषा है तब तक यूएमएल महान है। यदि आप चित्रमय दृश्य प्राप्त करने के लिए MDD को UML से जोड़ने का प्रयास करते हैं तो यह बेकार है। एमडीएम बिना यूएमएल के साथ-साथ यूएमएल के बिना एमडीडी के लिए बहुत अच्छा होगा।

    मान लीजिए कि यूएमएल और एमडीडी ने आज एक साथ जीवन को बेहतर बनाने के लिए तलाक ले लिया है :-)


    यह किसी भी स्तर पर "महान" नहीं है। विनाशकारी एडीए प्रोग्रामिंग भाषा (बूच) के एक उपयोगकर्ता ने कुछ बचकाना आरेख बनाए और यूएमएल बनाने के लिए अधिक गंभीर वर्ग आरेख दृष्टिकोणों के एक जोड़े के साथ झुका। यूएमएल तुरंत एक बड़े सॉफ्टवेयर-वेंडर राजस्व जनरेटर में बदल गया। यह भयावह था, लेकिन अनुक्रम, डेटा प्रवाह आदि जैसे नए आरेख प्रकार (जो कि पूर्व-दिनांकित यूएमएल) में गिराने से बचाया गया था, इसके बारे में कुछ भी विस्तार योग्य नहीं है। कोई डेटाबेस स्कीमा, कोई लेयर आरेख नहीं, यह एक ही समय में अंतराल और बेकार आरेखों से भरा है।
    रिक ओ'शे
    हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
    Licensed under cc by-sa 3.0 with attribution required.