कितनी बार आप औपचारिक यूएमएल का उपयोग करते हैं?


33

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

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


9
बड़ा सवाल है। आपके प्रोफेसर का रवैया संभवतः कॉलेज में सीखे जा रहे कुछ कौशल और "वास्तविक" दुनिया में आवश्यक कौशल के बीच वर्तमान डिस्कनेक्ट का एक लक्षण है।
पैड्सस्लैकर

@ शिक्षा, शिक्षा का उद्देश्य (विशेष रूप से उन जगहों पर जहां "प्रोफेसरों" शिक्षण करते हैं) केवल उन कौशल का उपयोग नहीं करना है जो वास्तविक दुनिया द्वारा आवश्यक हैं।
पी शेव्ड

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

1
@ कंप्यूटर कंप्यूटर विज्ञान! = सॉफ्टवेयर इंजीनियरिंग हालांकि, मैं सीएस ग्रेड की बड़ी संख्या को विलाप करता हूं जो कोड नहीं कर सकता है, प्रोग्रामिंग जरूरी नहीं है कि कंप्यूटर विज्ञान का ध्यान केंद्रित हो।
जॉर्ज मैरियन

5
@ जॉर्ज मारियन: मिथ। प्रोग्रामिंग और सॉफ्टवेयर विकास सीएस पाठ्यक्रमों में पढ़ाया जाता है। "Cs! = Se" कहना सही न पढ़ाने का एक आधा बहाना है।
स्टीवन एवर्स

जवाबों:


45

कभी नहीँ।

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

वास्तव में, हमने साक्षात्कार के दौरान हमारे द्वारा उपयोग किए गए गाइड से एकमात्र यूएमएल प्रश्न को हटा दिया, क्योंकि हममें से किसी ने भी वास्तव में उत्तरों की परवाह नहीं की।


+1 मैं पूरी तरह सहमत हूं। मुझे पता है कि मैं शायद अपने आप को झकझोर रहा हूं और मेरा अगला ग्राहक दस्तावेज में औपचारिक यूएमएल की मांग करेगा!
पैड्सलेकर

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

4
+1 पर सहमत हुए। मैं याद नहीं कर सकता कि पिछली बार हमने किसी यूएमएल का उपयोग किया था। बहुत समय की जरूरत है और बहुत कम रिटर्न, कोई आरओआई नहीं।
वाल्टर

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

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

14

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


11

विडंबना यह है कि यूएमएल को लचीला माना जाता है।

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

आपके प्रश्न का उत्तर देने के लिए, मैं दूसरों के साथ हूं। मैंने कभी भी पूर्ण-पूर्ण, औपचारिक यूएमएल का उपयोग नहीं किया है।


6

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

पिछले पांच वर्षों में "बक्से और तीर" के अधिक से अधिक मौके पर आविष्कार किए गए हैं और आमतौर पर सामान्य विचार प्राप्त करने के लिए पर्याप्त है। इस समय के दौरान औपचारिक रूप से केवल यूएमएल सही है।


वास्तव में??! लोग वास्तव में उस सुविधा का उपयोग करते हैं?
19

2
"उपयोग किया गया"। भूत काल।
फ़ीचर क्रिप

4

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

अपने प्रोफेसर से पूछें कि वह आखिरी बार कब एक वास्तविक प्रणाली पर उस दृष्टिकोण का उपयोग किया था। गंभीरता से।

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

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

या हो सकता है कि आप एक ऐसे चरण में हैं जहाँ आप एक पूर्ण औपचारिक मॉडलिंग चरण के विपरीत अतिथि-सत्कार और स्केचिंग कर रहे हैं। वे उदाहरण हैं जो दिमाग में आएंगे।

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

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

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

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

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


3

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

मेरा निष्कर्ष यह था कि यूएमएल रूपकों और अंकन को उधार लिया जाता है, लेकिन साधनों की कठोरता का थोड़ा पालन होता है।

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

अकादमिक शोध के सामान्य तथ्य, निश्चित रूप से लागू होते हैं :)

पेपर एब्सट्रैक्ट और स्वयं पेपर का लिंक (यदि आपके पास एसीएम एक्सेस नहीं है)

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


1

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


1

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

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

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

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

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

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


0

जब मैंने UML के बारे में पढ़ा तो मैंने अपने C ++ पाठ्यक्रम में हल करने वाली सभी समस्याओं पर यह कोशिश की। Fortunatly पहले उदाहरणों में से एक मैंने एक लिंक की गई सूची का वर्णन करने की कोशिश की।
काम नहीं किया।
कहा कि, एक अच्छी मॉडलिंग प्रक्रिया के साथ मिलकर यूएमएल उपयोगी है। सिर्फ इसलिए कि यह बेहतर या बदतर मानक के लिए है।
मुझे टेम्प्लेट मेटा प्रोग्रामिंग की विवरण भाषा देखना अच्छा लगेगा। मुझे लगता है कि यह समझने में बहुत मदद मिलेगी कि <<<>>> -land में क्या चल रहा है


0

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

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

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

यूएमएल महान, शानदार और वास्तव में उपयोगी है लेकिन मॉडल संचालित विकास बेकार है !!


मैं असहमत हूं कि एमडीडी बेकार है। मैंने कुछ परियोजनाओं में काम किया है जहाँ यह सफल रही है। यह काम करने के लिए एक निश्चित कार्य संदर्भ लेता है। हम अभी भी सभी स्थितियों में इसे प्रभावी ढंग से लागू करने के लिए सॉफ्टवेयर इंजीनियरिंग के बारे में पर्याप्त नहीं जानते हैं।
luis.espinal

0

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


0

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

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

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


यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। क्या आप इसे बेहतर आकार में संपादित करना चाहेंगे ?
gnat

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