क्यों यू.एम.एल.

Vsevolod Leonov - उत्पाद प्रबंधक, Embarcadero।
अलेक्जेंडर ल्युलिन - लीड डेवलपर, गारेंट
मैक्सिम क्रायलोव - प्रोजेक्ट मैनेजर, गारेंट

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

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

विज्ञापन की कमी के सबूत - आइए देखें कि ऊपर क्या लिखा गया है। हमने अभी निर्धारित किया है:

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

कंपनी की वेबसाइट फिर से विज्ञापन कारणों के लिए नहीं है। तो विकिपीडिया भी करता है, जो "विज्ञापन-मुक्त" का मानक है। उपरोक्त अनुच्छेद प्रकाशन को ए) पूर्णता देने का कार्य करता है; b) पाठकों के प्रति जिम्मेदारी।

यदि आप (व्यापक अर्थों में - लोग, कंपनियां, विशेषज्ञ, विशेषज्ञ) लेखकों से सहमत नहीं हैं, तो हमें इस विषय पर आपके प्रकाशनों के लिंक देखकर खुशी होगी। यदि आपको इसकी सहायता चाहिए, तो कृपया vsevolod.leonov@embarcadero.com पर संपर्क करें।

Vsevolod : हमें बताएं, क्या UML का उपयोग मूल रूप से विकास प्रक्रिया के घटकों में से एक के रूप में स्वीकार किया गया था?

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

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

Vsevolod : क्या कोई "वैचारिक असहमति" नहीं थी? अलग-अलग कोडिंग स्टाइल हैं, क्या यह काम नहीं करता है कि "हर किसी का अपना यूएमएल हो"? या यूएमएल "सभी को एक कंघी के नीचे कंघी करना" है?

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

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

Vsevolod : यूएमएल की ओर देखने के लिए निर्णय किस बिंदु पर किया गया था?

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

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



Vsevolod : ऐसे मामले थे जब UML के साथ भी सहमत होना संभव नहीं था?

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

अलेक्जेंडर : यूएमएल एक हठधर्मिता या "सार्वभौमिक गोली" नहीं है, बल्कि एक साधन है। लेकिन काम वास्तव में बेहतर हो गया है। क्योंकि यह पूरी प्रणाली पर बस "नज़र" करना संभव हो गया, जल्दी से समीक्षा के दायरे को बदल दिया। फिर हम UseCase को देखते हैं, फिर 5 मिनट के बाद हम पहले ही बाइट्स के लिए नीचे जा चुके हैं। स्केलिंग बहुत तेज है। कहते हैं, जैसा कि Google धरती में है।

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

अलेक्जेंडर : कुछ बिंदु तक, इस तरह की योजना ने हमारे लिए काम किया। लेकिन मुझे भूमिकाएं बदलनी पड़ीं। दूसरों को प्रतिस्थापित करें। और परियोजनाओं की जटिलता बढ़ गई है।

Vsevolod : और आप कैसे समझते हैं कि परियोजना पहले से ही "जटिल" हो गई है?

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

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

Vsevolod : मॉडलिंग प्रक्रिया कैसे चल रही है? क्या यह है कि "इच्छुक कॉमरेड्स" का एक समूह एक ही समय में इकट्ठा होता है और "एक चार्ट पर उंगलियों" को खींचता है? या एक स्पष्ट भेद है - गुरु-अनुयायी। यानी एक ड्रॉ - क्या बाकी लोग ध्यान देते हैं?

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

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

Vsevolod : यूएमएल का उपयोग करके आप शुरू में क्या समस्याएं हल करना चाहते थे?

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

अलेक्जेंडर : रिश्ते की जटिलता। "नंगे" कोड में उनकी "अपरिपक्वता"। डिजाइन और कोडिंग नियम। टेम्पलेट समाधान का उपयोग। फिर, यूएमएल को औपचारिक रूप से "सहमत" करने के अवसर के रूप में देखा गया।

Vsevolod : और क्यों बिल्कुल UML?

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

Vsevolod : क्लासिक्स धोखा नहीं है? या यूएमएल की जगह और भूमिका के बारे में आपका अपना दृष्टिकोण था?

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

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

Vsevolod : "स्टीरियोटाइप" की अवधारणा पर चर्चा करते हैं?

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

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

Vsevolod : मुझे विस्तार से बताएं कि यह आपके लिए कैसे विकसित हुआ है - स्टेप वाइज?

मैक्सिम : गैरेन (प्लेटफ़ॉर्म एफ 1) के नए संस्करण पर काम की शुरुआत में, हमें एक समस्या का सामना करना पड़ा: सर्वर C ++ / CORBA में विकसित किया गया था, और क्लाइंट डेल्फी में एक शेल था। कुछ कारणों के लिए, हम डेल्फी के लिए देशी खोल पर VisiBroker का उपयोग नहीं कर सकते थे, लेकिन हमने सर्वर साइड के लिए एक वैकल्पिक विकल्प नहीं देखा। तब क्लाइंट पर "एडेप्टर" (C ++ में dll) बनाने के लिए एक समाधान प्रस्तावित किया गया था, जो कि CORBA का उपयोग करते हुए सर्वर के साथ काम करेगा, इसके अलावा कुछ आंतरिक परिवर्तनों, कैशिंग और यहां तक ​​कि क्लाइंट लॉजिक के कुछ हिस्से को सम्‍मिलित करने के लिए, सब कुछ देते हुए। समझने और सुविधाजनक तरीके से डेल्फी खोल। मुझे लगता है कि यह कहने लायक नहीं है कि "गारंटर" जैसी प्रणाली, इंटरफेस के नामकरण जिसके माध्यम से एडेप्टर और शेल ने बातचीत की, जल्दी से धमकी वाले अनुपात का अधिग्रहण किया। अब कल्पना करें कि C ++ और डेल्फी में एक dll के बीच कोई ऑब्जेक्ट इंटरफ़ेस क्या है? संक्षेप में, यह "वास्तविक नरक" है: विभिन्न प्रकार के स्थानांतरण नियम, विभिन्न मेमोरी प्रबंधन, निर्यात हेडर में विवरण नियंत्रण की कमी और डेल्फी में, जब पूरी तरह से किसी भी विसंगति पूरी तरह से अप्रत्याशित परिणाम और सुपर-एनवेट्रिवियल हॉगिंग, आदि की ओर जाता है।

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

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

Vsevolod : विकास टीम में एक नया व्यक्ति कैसे शामिल है? उसे आरेखों का "ढेर" दिया जाता है? या क्या वह प्राथमिक ऑपरेशन से शुरू होता है जिसे "पूरी प्रणाली को देखने" की आवश्यकता नहीं है?

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

Vsevolod : हर कोई जानता है कि नए दृष्टिकोण और तरीके हमेशा सभी टीम के सदस्यों द्वारा सकारात्मक रूप से नहीं माना जाता है। क्या सक्रिय या निष्क्रिय प्रतिरोध के कोई मामले हैं?

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

Vsevolod : कार्यान्वयन प्रक्रिया कैसे हुई - रिवर्स इंजीनियरिंग किया गया था?

अलेक्जेंडर : नहीं किया। उस समय, बस कोई अच्छा उपकरण नहीं थे। और अब मैं गहराई से आश्वस्त हूं कि यह आवश्यक नहीं है। क्योंकि « » , ( , ), /. «» . - «» .

: : - – «». , , , , , , . – UML . , , . – , . , , , , .

: «» . , UML ?

: . . , , « ». « ». .

: «» UML. «» , , . , , .

: ? – ? , ? « » ?

: , . — . – + .

«», « » ( ) . «» . यानी , , – «», – «». , , . - « View -, - – View». – . «» .

? , IT- «» . , . , . « XP». , , . « », – . « ».

, , «» «». «» , «», «». – . « ».

: «», UML, DSL, ?

: . — , , , , , .. , – , . - , , , , , . , . «a» «b» , . , . , «» , , , – , .

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

Vsevolod : क्या रिफैक्टरिंग की गुणवत्ता को मापना संभव है? फिर से रिफ्लेक्टर की जरूरत नहीं?

सिकंदर : , . , , , . , /, . - «», «». , «» , «» – .

: , . , « , ». , UML- , ?

: , , . , , « ». UML . , , «».

: – UML- . 100% ?

: . , 100% . , . « ».

: , , , . .

: .. – UML ?

: . , , , - « ». «». « ».

, , «» , , – . , , .

: , – UML. , . , , , : UML .

: , «», , ?

: , . , UML «», . , - . , , UML-, , «», «», «» .. , , , , , . यानी , – , DSL , , , UML . यानी , UML, «» , .

: « » ?

: – . . , . , – . ( ) , .

: , , . , , , , , , .

: . , , ?

: , , , , UML, , . . . « ». , . « ». . – « ». «» . « ». , . .

: , , , , . , . , , , .

: , , UML? (, ), , : « UML, ?»

: - , « ». , UML . – , UML, .

: « UML» ?

: . . bug-tracking .

:… , know-how. , : html , , .

: UML- ? !

: . UML.

: , .

: UML- «-»?

: UML . UseCase Sequence. , , . 1, , , , . ..., , .

: -, ( , ), . , UML. .

: UML- ?

: , UseCase'.

: ? , «» , «»?

: . , state machines. . , , . - sequence, , .. « », , , , .

: , Sequence , . «» SAX-. , .

: RAD- . , , , , , . UML?

: UML «» «-», . . RAD – . , . यानी « » , « » . « » «» . SAX-, ..

: , , . , , . , – lego-.

: ?

: . « ». . , , – . , , . , , .
UML :-) . , .

: «». , -, UML ?

: . « - », , , .

: UML , , , , . «hello world». , , «hello world» , IDE :), .

: , UML ?

: - «» .

: , , .

: ?

: . , « ».

: UML , « »?

: - , , -, , , - , .

: . /. , . , «».

: , . UML ?

: , , , — . , , . , , .

: , UML , , . , , . . , , , .. DSL. .

: ?

: -, , .

: , ? : « »!

: , . , . . UML ..

: , . , . , . «», «».
UML- . , «», , .

: ?

: — . , « » .

: – . , , .

: DSL?

: , .

: !

: Embarcadero, , … Delphi?

: , Delphi . RAD UML, . Delphi RAD- . – . Delphi XE4. 64-.

: ++, , , , Delphi, ++, python, java , «» «» — . — . Delphi , , , , , , . , Delphi .

PS «», .