क्या कोड आमतौर पर यूएमएल से उत्पन्न होता है? [बन्द है]


39

इसलिए जब मैं विश्वविद्यालय में था तो मुझे यूएमएल के लाभों और कोड विकास में इसके भविष्य पर शिक्षित किया गया था।

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

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

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

क्या लोग यूएमएल का उपयोग कोड या डेटाबेस जनरेशन जैसी अधिक परिष्कृत चीजें करने के लिए करते हैं?


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

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

9
@ एसके-तर्क - मैंने सोचा कि एक तस्वीर ने एक हजार शब्दों को चित्रित किया है?
माइकल अरनेल

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

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

जवाबों:


64

हां, UML CASE उपकरण 90 के दशक के हॉट आइटम में से एक थे ... और फिर वितरित करने में विफल रहे।

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

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

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


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

1
+1 90 के दशक के प्रचार के लिए, हार्डवेयर डिज़ाइन यहां तक ​​कि एक ही समय में विपरीत दिशा में आगे बढ़ रहा था, योजनाबद्ध कैप्चर से दूर और एचडीएल की ओर।
जे.के.

2
1996 से 2002 तक मैं एक ऐसी कंपनी के लिए काम कर रहा था जहां हमने सफलतापूर्वक "बेहतर" ईआर मॉडल के रूप में यूएमएल आरेखों का उपयोग किया। हमारे पास अपने ORM फ्रेमवर्क, SQL / DDL के लिए C ++ कोड उत्पन्न करने के लिए हमारे अपने कोड जनरेटर थे और सभी एक ही मॉडल से दस्तावेज थे।
डॉक्टर ब्राउन

2
यूएमएल आरेख का एक बड़ा उपयोग भी मचान है।
गेटर्स / सेटर के

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

36

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

वे गलत थे। यह उस समय के बारे में होगा जब लोग भाषण को छोड़ देंगे और गुफा पेंटिंग पर वापस जाएंगे।

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


2
+1, वास्तविक शब्द समस्याओं की जटिलता के मुद्दे को लाने के लिए धन्यवाद। महान बिंदु।
NoChance

G के बारे में क्या, LabVIEW में इस्तेमाल की जाने वाली चित्रमय प्रोग्रामिंग भाषा?
एंजेलो। हेंस

1
@ एंजेलो.हैंस: वास्तविक दुनिया की समस्याओं को हल करने में अयोग्य दृष्टिकोण की तरह दुनिया की समस्याओं को देखते हुए
whatsisname

@whatsisname यह आरेख बहुत अव्यवस्थित है। लेकिन मैंने बहुत अच्छे संरचित और बहुत "पठनीय" आरेख LabVIEW में वास्तविक दुनिया की समस्याओं को हल करते हुए देखा है।
एंजेलो। हेंस

@ एंजेलो। यान: मैंने लैबव्यू के समान सिस्टम का उपयोग किया है। वे एक सीमित डोमेन में छोटे अनुप्रयोगों के निर्माण के लिए ठीक हैं।
केविन क्लाइन

9

नहीं

किंवदंती असफल धारणा पर आधारित थी कि लेखन:

class ClassName extends SomeThing
{

}

... यह कठिन है और स्वचालन की जरूरत है

आप अभी भी सामयिक आस्तिक, या विश्वासियों की भीड़ पा सकते हैं ।
लेकिन यह है कि यह कैसे धर्म और पंथ के साथ चला जाता है।


4
मुझे वास्तव में एक बड़ी संख्या के साथ उत्तर की आवश्यकता महसूस हुई ।
ZJR

6

वहाँ गया, यह बहुत उपयोगी नहीं मिला।

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

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

विधि निकायों को अभी भी हाथ से भरना पड़ा, क्योंकि आरेख वास्तव में राज्य मशीन कंकाल के अपवाद के साथ प्रतिनिधित्व नहीं कर सकते हैं।

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


@mouviciel: मुझे नहीं लगता कि ऐसा कोई उपकरण है, जिसमें ऐसी समस्याएँ न हों। रैप्सोडी वास्तव में उत्पन्न कोड का उपयोग करके सबसे खराब समस्याओं को कम करने की कोशिश करता है, जो कि पाठ है, सदस्यों के लिए आधिकारिक रूप में।
जान हुदेक

3

हालांकि यूएमएल मॉडल से सीधे कोड (और यहां तक ​​कि पूरे सिस्टम) को उत्पन्न करना निश्चित रूप से संभव है, मैंने कभी इस तरह से इसका उपयोग नहीं किया है।

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

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


1

यह सब (मॉडलिंग आरेख) संचार उद्देश्यों के लिए है

सॉफ्टवेयर विकास प्रक्रिया में मॉडलिंग के 4 महत्वपूर्ण उपयोग हैं:

  1. एकीकृत डिजाइन उपकरण

  2. बात करने का यंत्र

  3. सॉफ्टवेयर पीढ़ी के लिए एक सहायता

  4. वास्तविक-शब्द समस्या की जटिलता को कम करने का एक तरीका (मैंने इसे @kevin cline की प्रतिक्रिया से ऊपर सीखा)

  5. मॉडलिंग की प्रक्रिया कुछ डिजाइनरों को कोडिंग (और इसके विपरीत) पर विचार नहीं किए गए विवरणों के बारे में सोचने के लिए मिलती है। डिजाइनिंग के समय मॉडलिंग करने से आप किसी भाषा या किसी भाषा में किसी विधि को कोड करने की तुलना में बड़ी तस्वीर पर विचार कर सकते हैं।

डेटाबेस (ईआर डायग्राम) के निर्माण के लिए मेरी राय में मॉडलिंग महत्वपूर्ण है, प्रक्रिया प्रवाह (एक्टिविटी डायग्राम्स) को समझना और उपयोगकर्ता-सिस्टम इंटरैक्शन (केस डायग्राम का उपयोग करना) को समझना।

क्या लोग यूएमएल का उपयोग कोड या डेटाबेस जनरेशन जैसी अधिक परिष्कृत चीजें करने के लिए करते हैं?

हाँ सचमुच। उत्पन्न करने के लिए ERDs (UML आरेख नहीं) और वर्ग आरेख का उपयोग किया जा सकता है (आपके उपकरण की क्षमताओं के आधार पर):

1 - डेटा परिभाषा भाषा (DDL)

2 - आपकी पसंदीदा भाषा में CRUD और कक्षा आरेखों के लिए संग्रहीत कार्यविधियाँ (चूंकि ORM उपकरण इस बारे में अधिक काम करते हैं)

मॉडलिंग टूल की सबसे मूल्यवान विशेषताओं में से हैं:

1 - मॉडल की अखंडता रखने की क्षमता। यदि आप एक परिवर्तन करते हैं तो यह मॉडल में फैलता है

2 - उपयोग किए गए सवालों के जवाब देने की क्षमता (मेरे मॉडल में 'खाता' का उपयोग कहां किया गया है?)

3 - समवर्ती उपयोगकर्ताओं को मॉडल पर काम करने की अनुमति देने की क्षमता

4 - चित्रमय अभ्यावेदन के भीतर खोजें

5 - मुद्रण नियंत्रण

6 - लेयरिंग (परतों में अपने आरेख तत्वों को व्यवस्थित करें) ताकि आप एक परत-एक-समय पर ध्यान केंद्रित कर सकें

7 - कई डेटाबेस सिस्टम के लिए डेटाबेस कोड जनरेशन

8 - मॉडल सत्यापन (चेक स्थिरता, लापता चाबियाँ, चक्र, आदि)

इसलिए, मॉडलिंग टूल, विशेष रूप से अच्छे लोग, पेंट की तुलना में बहुत अधिक करते हैं।


3
मैं 2 बातें बताना चाहता हूं: 1. आपको ऑर्डर की गई सूचियां पसंद हैं।
ताजनगरी

@talnicolas, आप सही हैं! मैं :)
NoChance

0

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

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


0

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


-1

अपने नवीनतम प्रोजेक्ट में मैं यूएमएल-लैब (https://www.uml-lab.com) का उपयोग कर रहा हूं। यह एक अच्छा उपकरण है जो मॉडल को रिवर्स इंजीनियर बनाने की अनुमति देता है। उपकरण जावा कोड और यहां तक ​​कि जेपीए एनोटेशन उत्पन्न करता है जो काफी सटीक हैं।

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

यह पहली बार है जब मैंने एक उत्पाद को ऑब्जेक्ट मॉडलिंग और एक शॉट में कोड पीढ़ी के साथ-साथ डेटा मॉडलिंग करते देखा।

अन्यथा मेरी पिछली परियोजनाओं में, मैंने हमेशा बासी मॉडल देखे हैं जो गलत हैं या तो बहुत विस्तृत हैं।

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


-4

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

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

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


-5

मुझे अभी भी समझ में नहीं आया है कि व्यावसायिक वस्तु जैसे उपकरण के साथ व्यापार खुफिया सभी कंपनी की जानकारी का विश्लेषण और लाभ लेने में सक्षम क्यों है जबकि तकनीकी स्तर पर हम अभी भी कोड स्तर पर या केवल यूएमएल के साथ सार स्तर पर काम कर रहे हैं !!

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

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

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

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


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