हम सभी अभी तक मॉडल संचालित विकास क्यों नहीं कर रहे हैं? [बन्द है]

Question

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

मैं यह भी जानता हूं कि बहुत सारी समस्याएं हैं

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

लेकिन फिर भी ये समस्याएं हल करने योग्य लगती हैं और लाभ को आवश्यक प्रयास से आगे बढ़ना चाहिए।

प्रश्न : आप सबसे बड़ी समस्याओं के रूप में क्या देखते हैं जो आपको मॉडल संचालित विकास पर भी विचार नहीं करते हैं?

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

Comments

मैं बिना किसी प्रोग्रामिंग या डेवलपमेंट मेथडोलॉजी में एक सच्चा आस्तिक हूं। उनमें से लगभग सभी कुछ के लिए उपयोगी हैं; कोई भी सब कुछ के लिए सर्वश्रेष्ठ नहीं है। मुझे विश्वास नहीं है कि एक "सच्चा आस्तिक" प्रश्न, P.SE के मानकों से रचनात्मक है।

— डेविड थॉर्नले

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

— कीसिजिक

@ डेविड थार्नले ने वोटिंग के दौरान टिप्पणी के लिए धन्यवाद दिया! मैं वास्तव में इसकी सराहना करता हूं, जब लोग टिप्पणी करते हैं जब वे डाउनवोट करते हैं।

— किड्जीक

जैसा कि मार्टिन फाउलर इसे कहते हैं ( martinfowler.com/bliki/ModelDrivenSoftwareDevelopment.html ): पर्याप्त टूलिंग सपोर्ट ( martinfowler.com/bliki/ProjectionalEditing.html ) नहीं।

— मिंगहुआ

Answer 1

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

कोई यह भी तर्क दे सकता है कि कोड की पीढ़ी केवल तभी उपयोगी है जब भाषा स्वयं (या फ्रेमवर्क) उच्च स्तर की नहीं है जो शक्तिशाली अमूर्तता के लिए अनुमति दे सकती है जो एमडीडी को अपेक्षाकृत व्यर्थ बना देगा।

Comments

फ्रेड ब्रुक्स ने इसे "नो सिल्वर बुलेट" कहा, लेकिन आपकी बात और उनके तर्क का सार समान है: cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html

— एडम

KeesDijk: IMO, पुनरावृत्ति को संभालना प्रोग्रामिंग का एक ही मूल है। लूपिंग, रिकर्सन, फ़ंक्शंस टू ओओ कॉन्सेप्ट्स आदि से प्रोग्रामिंग लैंगगेज़ में अधिकांश संरचना तत्व एक प्रकार के दोहराव या किसी अन्य को संभालने के लिए बनाए जाते हैं।

— user281377

फ्रेड ब्रूक्स के पास 50 और 60 के दशक के कुछ पेपर हैं जिन्हें अभी तक डिबंक किया जाना है। "माइथिकल मैन मंथ" पुस्तक (जिसमें "नो सिल्वर बुलेट" निबंध भी शामिल है, देखें।

— बेरिन लोरिट्स

1987? हेक, फ्रेड ब्रूक्स ने 1975 में एक किताब प्रकाशित की थी, जिसका कोई महत्व या सटीकता नहीं खोई है ( en.wikipedia.org/wiki/The_Mythical_Man-Month )। नहीं, मुझे नहीं लगता कि नो सिल्वर बुलेट के सिद्धांत आज की तुलना में कम सच हैं। जैसा कि @ammoQ ने इतनी सरलता से कहा: सॉफ्टवेयर विकास में कुछ अंतर्निहित जटिलता है ... "अब, आप विभिन्न तरीकों और तकनीकों, रूपरेखाओं, कार्यप्रणाली की कोशिश कर सकते हैं, लेकिन अधिकांश भाग के लिए, वे सिर्फ जटिलता के सभी को दूर करने की कोशिश करते हैं।" एक विशेष बाल्टी। यह दूर नहीं जाती।

— एडम क्रॉसलैंड

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

— डेविड थॉर्नले

Answer 2

दिलचस्प सवाल! मैं मानता हूं, मैं प्रशंसक नहीं हूं, लेकिन फिर मैंने कई बार परियोजनाओं में मॉडल संचालित विकास का उपयोग करने की कोशिश की है जो आपके द्वारा उठाए गए मुद्दों में से कुछ को फिट करते हैं।

यहाँ मेरी कारण सूची है:

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

Comments

धन्यवाद ! महान सूची! मुझे इस बात से सहमत होना होगा कि इन पर ध्यान दिया जाना चाहिए और यदि आप इसे गलत करते हैं तो विफलता की लागत वास्तव में बहुत अधिक है। एक प्रश्न: क्या आपका अनुभव MetaEdit जैसे अधिक DSL उपकरण के UML केस टूल के साथ अधिक है?

— कीसिजिक

@KeesDijk - UML, निश्चित रूप से! विशेष रूप से तर्कसंगत गुलाब, लेकिन तर्कसंगत एसडब्ल्यू वास्तुकार का एक सा भी।

— bethlakshmi

Answer 3

यह पहले से ही उद्धृत किया गया है, लेकिन कोई सिल्वर बुलेट बिंदु को अच्छी तरह से संबोधित नहीं करता है:

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

मेरा मानना ​​है कि इस वैचारिक निर्माण के विनिर्देशन, डिजाइन और परीक्षण के निर्माण के लिए सॉफ्टवेयर का कठिन हिस्सा है, न कि इसका प्रतिनिधित्व करने और प्रतिनिधित्व की निष्ठा का परीक्षण करने का श्रम। हम अभी भी वाक्यविन्यास त्रुटियों को सुनिश्चित करते हैं; लेकिन वे अधिकांश प्रणालियों में वैचारिक त्रुटियों की तुलना में फजी हैं।

यदि यह सच है, तो सॉफ़्टवेयर बनाना हमेशा कठिन होगा। स्वाभाविक रूप से कोई चांदी की गोली नहीं है।

बाद में, ब्रूक्स "स्वचालित प्रोग्रामिंग" की अवधारणा के बारे में निम्नलिखित बताते हैं:

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

पर्नस का तात्पर्य है कि यह शब्द ग्लैमर के लिए प्रयोग किया जाता है, शब्दार्थ सामग्री के लिए नहीं, मुखरता के लिए, "संक्षेप में, स्वचालित प्रोग्रामिंग हमेशा प्रोग्रामर के लिए उपलब्ध उच्चतर भाषा के साथ प्रोग्रामिंग के लिए एक व्यंजना रही है।"

वह तर्क देते हैं, संक्षेप में, कि ज्यादातर मामलों में यह समाधान पद्धति है, न कि समस्या, जिसका विनिर्देश दिया जाना है।

असल में, मैं तर्क दूंगा कि MDD एक उच्च स्तरीय भाषा के साथ प्रोग्रामिंग के लिए एक और व्यंजना है जो पहले उपलब्ध थी।

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

Comments

ब्रूक्स बहस कर रहा था कि क्या, 30 साल पहले?

— पॉल नाथन

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

— किड्जीक

Answer 4

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

क्योंकि मेरे जैसे प्रोग्रामर हैं जिन्हें एमडीडी की तुलना में TDD से अधिक प्रगति और परिणाम मिलते हैं।

क्योंकि मॉडलिंग! = प्रोग्रामिंग।

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

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

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

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

Comments

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

— किस्डिजक

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

— बेरिन लोरिट्श

माना !

— किड्किज

Answer 5

Microsoft / Apple / Google इसे आगे नहीं बढ़ा रहा है :)

किस तरह के विकास को लोकप्रिय बनाया जाता है इसका टूल, बैकर और इंजीलवाद के साथ बहुत कुछ है। एक बड़ी बैकर के बिना कुछ के साथ तोड़ना बहुत कठिन है (रेल पर रूबी शायद अपवाद है लेकिन यह जावा / सी # / पायथन की तुलना में अभी भी छोटा है)

Comments

ठीक है, मुझे सहमत होना होगा। हालाँकि Microsoft Visual Studio विज़ुअलाइज़ेशन और मॉडलिंग एसडीके आर्काइव के साथ थोड़ी सी कोशिश कर रहा है। msdn.micdn.microsoft.com/vsvmsdk पुश नहीं कर रहा है।

— 20 अगस्त को KeesDijk

Answer 6

एक साधारण कानून के कारण जो इन सभी मॉडलिंग टूल को प्रभावित करता है, आप जानते हैं, CASE, UML और ऐसे:

एक प्रोग्रामर और उसके कोड के बीच मिलना बहुत महंगा है।

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

डोमेन ड्रिवेन डिज़ाइन की महान अंतर्दृष्टि में से एक यह है कि मॉडल कोड में होना चाहिए, कोड के बाहरी किसी चीज़ में नहीं।

अंततः सवाल यह है: आपके मॉडल कोड में क्यों फिट नहीं होते हैं? यदि आप एम्बेडेड विकास कर रहे हैं और सी के साथ फंस गए हैं या विभिन्न प्लेटफार्मों के लिए कोड उत्पन्न करने की आवश्यकता है, तो कोड पीढ़ी लागत के लायक हो सकती है। बाकी सभी के लिए, एक अधिक शक्तिशाली प्रोग्रामिंग भाषा और बेहतर कोड डिज़ाइन आमतौर पर कोड के अलावा किसी अन्य चीज़ में कोड डिज़ाइन करने से बेहतर होते हैं।

Comments

DDD के संबंध में: मुझे मानना ​​होगा कि मुझे वास्तव में DSELs पसंद हैं। मैं (दूर से) barrelfish OS डेवलपमेंट ( barrelfish.org ) का अनुसरण कर रहा हूं और उन्होंने Filet-o-Fish का निर्माण किया, जो DSLs बनाने के लिए एक टूल है और फिर कोड में सीधे एब्सट्रैक्शन के उच्च स्तर पर काम करता है।

— मथिउ एम।

Answer 7

• बहुत कम लाभ के लिए एक विशाल परेशानी की तरह लगता है।
• मैं हमेशा किनारे के मामलों और अजीब चीजों के साथ डूब रहा हूं, जादू का सामान कभी भी सही काम नहीं करता है।
• ऊ चांदी की गोली नहीं है; OO पर सॉफ़्टवेयर-जनरेट करने की कार्यप्रणाली को फुलाने से चांदी नहीं बनती।

लेकिन मैं सामान्य रूप से enterprisey समाधान का शौकीन नहीं हूं।

Comments

+1 के लिए "बहुत कम लाभ के लिए एक विशाल परेशानी की तरह लगता है।"

— रीवरब

Answer 8

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

जैसा कि मुझे पता है, एमडीए की कमियां हैं:

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

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

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

Comments

धन्यवाद! एक और महान सूची। मेरा मानना ​​है कि रिफैक्टिंग पर कई क्षेत्रों में काम किया जा रहा है और मेटाएडिट चित्रमय मॉडल को डिबग कर सकता है लेकिन हां मैंने इस क्षेत्र में बहुत सारी महान चीजें नहीं देखी हैं।

— कीसिजिक

Answer 9

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

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

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

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

Answer 10

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

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

इसके अलावा, कोई डेवलपर किसी अन्य डिज़ाइन पैटर्न (या एंटी-पैटर्न) पर ईवेंट संचालित एचएसएम, या कुछ अन्य डिज़ाइन पैटर्न के रूप में कोड को लागू करने के लिए मॉडल को कैसे निर्देश दे सकता है? यदि किसी अज्ञात डिज़ाइन पैटर्न का उपयोग करने के लिए कोड को मैन्युअल रूप से अपडेट किया जाता है, तो क्या मॉडल सटीक रूप से चित्रित कर सकता है?

आप उन कार्यों को कैसे लागू करते हैं जो एक मॉडल में फिट नहीं होते हैं?

Comments

धन्यवाद ! मैं कैम्ब्रिज (में CodeGeneration attented codegeneration.net/cg2010 ) और आम सहमति थी कि एम्बेडेड दुनिया विशेष रूप से MDD के लिए उपयुक्त है। इसके अलावा नीदरलैंड थेल्स में एक कंपनी ( thalesgroup.com ) रडार सिस्टम में एमडीडी का उपयोग करके बहुत प्रगति कर रही है। सिस्टम के सामान्य कामकाज का मॉडल तैयार किया गया है, हर नए हार्डवेयर के लिए अलग-अलग बिल्डिंग ब्लॉक्स को कोड किया गया है। यह हार्डवेयर को बहुत तेजी से बदल देता है।

— कीसिजिक

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

— 20 अगस्त को KeesDijk

@KeesDijk: जब आप कहते हैं कि एम्बेडेड दुनिया विशेष रूप से एमडीडी के लिए अनुकूल है, तो क्या आप कारों और घरेलू उपकरणों में पाए जाने वाले सेल फोन ऐप या appsकंट्रोलर एसडब्ल्यू का उल्लेख कर रहे हैं।

— ओस्टरवाल

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

— KeesDijk

कुछ समय पहले हमारे पास Matlab / Simulink का एक लड़का था जो हमें कोड जनरेटर बेचने की कोशिश करता था। एंबेडेड कंट्रोलर पर स्क्वेयरली एएमडी। MISRA-C नहीं किया और प्रमाणित नहीं किया गया था, इसलिए थोड़ा दुखी हो सकता है कि बदल गया हो। एक नजर डालें, यह सी पैदा किया गया था

— टिम Williscroft

Answer 11

लघु उत्तर ... क्योंकि संचालित मॉडल अक्सर कोड पीढ़ी से संबंधित होता है और कोड नाजुक होता है; हमें जरूरत है कोड उन्मूलन और संचालित मॉडल निश्चित रूप से जाने का रास्ता है।

कुछ ने इस सवाल को खारिज कर दिया है कि कोई सुनहरा हथौड़ा नहीं है और सॉफ्टवेयर विकास स्वाभाविक रूप से जटिल है।

मैं उनसे पूरी तरह सहमत हूं कि कोई सुनहरा हथौड़ा नहीं है, लेकिन मुझे नहीं लगता है कि संचालित मॉडल गोल्डन हथौड़ों या चांदी की गोलियों की खोज है!

मैं जटिलता के साथ आगे जाना चाहूंगा; जटिलता के दो प्रकार हैं, जिन्हें मैं जैविक या प्राकृतिक जटिलता कहता हूं, जटिलता जो व्यवसाय और इसकी प्रक्रियाओं के लिए अंतर्निहित है, लेकिन हमारे पास औपचारिक जटिलता भी है।

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

आज पूरी जटिलता जो सूचना प्रणाली के विकास का शिकार करती है और विफलता का कारण बनती है और कमर औपचारिक जटिलता है; जटिलता जिसे समाप्त किया जा सकता है।

औपचारिक जटिलता बर्बादी है, कोड के कारण बर्बादी, मूल्य कम, परिवर्तन प्रतिकूल, अपरिवर्तनीय कोड; कोड जो इसके सख्त न्यूनतम तक कम होना चाहिए।

उसको कैसे करे? आसान! बस इसे मत लिखो, और इसे उत्पन्न मत करो, पहली जगह में!

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

यह एक ऑपरेटिंग सिस्टम की तरह है, आप इसे अपने द्वारा उपयोग किए जाने वाले प्रत्येक प्रोजेक्ट के लिए फिर से नहीं लिखते हैं। तो क्या जरूरत है एक तकनीकी इंजन है जो एक मॉडल को दिए गए सॉफ़्टवेयर के अपरिवर्तनीय पहलुओं को संभालता है। मैं इसे AaaS (एक सेवा के रूप में वास्तुकला) इंजन कहता हूं।

अनावश्यक कोड के रूप में, अच्छी तरह से यह अनावश्यक कोड है इसलिए इसे अलिखित भी छोड़ सकता है।

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

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

Answer 12

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

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

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

Comments

आपके सहयोग के लिए धन्यवाद। मुझे सहमत होना चाहिए और निकट भविष्य में समाधान नहीं देखना चाहिए।

— कीसडिक

Answer 13

मॉडल ड्रिवेन डेवलपमेंट एक गैर समझदारी है क्योंकि यह कोड दृष्टिकोण के लिए एक शीर्ष डाउन मॉडल है। केवल एक मॉडल से पूर्ण रनिंग एप्लिकेशन बनाना असंभव है और इसलिए MDD बेकार है !!

अपने आवेदन के कंकाल बनाने के लिए मैं केवल यूएमएल के उच्च स्तर पर यूएमएल का उपयोग करता हूं। मेरा मतलब है कि पैकेज, कक्षाएं आदि बनाना ... फिर तुरंत जावा भाषा में कोड करना शुरू करें।

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

मेरे UML चित्र मेरी परियोजना को गति देने में मेरी मदद करते हैं और अब बेकार नहीं हैं :-)

Answer 14

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

Answer 15

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

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

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

Answer 16

एमबीएसई - मॉडल आधारित सॉफ्टवेयर इंजीनियरिंग अधिक प्रासंगिक शब्द है।

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

जब आपके पास DSML और परिवर्तन / पीढ़ी प्रक्रिया पूरी तरह से और सही ढंग से लागू हो जाती है तो कलाकृतियों की पीढ़ी बहुत कम लागत पर आती है। लेकिन जब तक आप डिबगिंग टूलिंग के उस चरण तक नहीं पहुंच जाते, तब तक यह बहुत दर्दनाक है।

एमडीडी के लिए अधिकांश सफलता की कहानियां उत्पाद लाइन इंजीनियरिंग (पीएलई) के क्षेत्र में हैं, जहां एक समान उत्पादों का एक उत्तराधिकार का उपयोग टूलिंग का उपयोग करके किया जाता है। बेशक, जावा कोड जनरेटर के कई वास्तव में MDD के सरलीकृत संस्करण हैं। कुछ XML और उत्पन्न कोड बाहर।

Answer 17

आप ने लिखा:

मुझे यह भी पता है कि बहुत सारी समस्याएं हैं ... परियोजनाएं जो केवल मॉडल संचालित विकास (पर्याप्त पुनरावृत्ति नहीं) के लिए सही नहीं हैं

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

मैं कमजोर प्रोग्रामिंग भाषाओं के लिए मॉडल संचालित विकास को एक जटिल और अक्षम कार्य के रूप में देखता हूं।

Comments

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

— किड्जीक

@ रुपये: 'आर्किटेक्चर' से आपका क्या तात्पर्य है? यदि यह कोड है, तो मैं दोहराव को समाप्त कर सकता हूं, और आर्किटेक्चर को तुरंत बदल सकता हूं, उन चीजों को निर्दिष्ट कर सकता हूं जो प्रत्येक तात्कालिकता के लिए अजीब हैं। एक अच्छी भाषा के साथ, किसी भी पुनरावृत्ति को स्पष्ट किया जा सकता है।

— केविन क्लाइन

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

— Cenobyte321