इंजीनियरों के रूप में, हम सभी कलाकृतियों (इमारतों, कार्यक्रमों, सर्किट, अणुओं ...) को "डिजाइन" करते हैं। यह एक गतिविधि (डिज़ाइन-टू-वर्ब) है जो किसी प्रकार का परिणाम (डिज़ाइन-ए-संज्ञा) पैदा करता है।
मुझे लगता है कि हम सभी इस बात से सहमत हैं कि डिजाइन-ए-संज्ञा कलाकृतियों की तुलना में एक अलग इकाई है।
सॉफ़्टवेयर व्यवसाय में एक महत्वपूर्ण गतिविधि (वास्तव में, किसी भी व्यवसाय में जहां परिणामी उत्पाद कलाकृतियों को बढ़ाने की आवश्यकता है) "डिजाइन (संज्ञा)" को समझना है। फिर भी, हम एक समुदाय के रूप में, इसे रिकॉर्ड करने में बहुत अधिक विफलताओं के रूप में प्रतीत होते हैं, जैसा कि लोगों द्वारा उनके कोड आधार के बारे में तथ्यों को पुन: खोज करने के प्रयास में दिखाया गया है। किसी को अपने कोड का डिज़ाइन दिखाने के लिए कहें और देखें कि आपको क्या मिलता है।
मुझे लगता है कि सॉफ़्टवेयर के लिए एक डिज़ाइन है:
- सॉफ्टवेयर क्या करना चाहिए और यह कितना अच्छा है, इसके लिए एक स्पष्ट विनिर्देश
- कोड का एक स्पष्ट संस्करण (यह हिस्सा आसान है, हर किसी के पास है)
- विनिर्देश को प्राप्त करने के लिए कोड का प्रत्येक भाग कैसे काम करता है, इसके लिए एक स्पष्टीकरण (उदाहरण के लिए, विशिष्ट अंशों और कोड अंशों के बीच एक संबंध)
- एक तर्क के रूप में क्यों कोड जिस तरह से यह है (जैसे, क्यों एक विशेष पसंद दूसरे के बजाय)
क्या नहीं है एक डिजाइन कोड पर एक विशेष परिप्रेक्ष्य है। उदाहरण के लिए [विशेष रूप से नहीं लेने के लिए] यूएमएल आरेख डिजाइन नहीं हैं। बल्कि, वे गुण हैं जिन्हें आप कोड से प्राप्त कर सकते हैं, या यकीनन, वे गुण जो आप चाहते हैं कि आप कोड से प्राप्त कर सकते हैं। लेकिन एक सामान्य नियम के रूप में, आप UML के कोड को प्राप्त नहीं कर सकते।
ऐसा क्यों है कि सॉफ्टवेयर के निर्माण के 50+ वर्षों के बाद, हमारे पास इसे व्यक्त करने के नियमित तरीके क्यों नहीं हैं? (स्पष्ट उदाहरणों के साथ मुझे विरोधाभासी महसूस कराएं
यहां तक कि अगर हम करते हैं, तो अधिकांश समुदाय "कोड" प्राप्त करने पर इतना ध्यान केंद्रित करता है कि डिजाइन-ए-संज्ञा वैसे भी खो जाती है। (IMHO, जब तक डिजाइन इंजीनियरिंग का उद्देश्य नहीं बन जाता है, डिजाइन से निकाले गए विरूपण साक्ष्य के साथ, हम इसके आसपास नहीं जा सकते हैं)।
आपने रिकॉर्डिंग डिज़ाइन के लिए किस अर्थ में देखा है (इस अर्थ में मैंने इसका वर्णन किया है)? कागजों के लिए स्पष्ट संदर्भ अच्छा होगा। आपको क्यों लगता है कि विशिष्ट और सामान्य साधन सफल नहीं हुए हैं? हम इसे कैसे बदल सकते हैं?
[मेरे अपने विचार हैं जो ऊपर दिए गए बुलेटप्रूफ दृश्य को दर्शाते हैं, लेकिन मैं अन्य लोगों के उत्तरों में दिलचस्पी लेता हूं ... और अपनी योजना को लागू करने के लिए कठिन है [[और शायद यही वास्तविक समस्या है: -]]]
EDIT 2011/1/3: एक उत्तर-सूत्र संकेत देता है कि "दस्तावेज़ीकरण" (संभवतः विशेष रूप से औपचारिक रूप से पाठात्मक नहीं) पर्याप्त हो सकता है। मुझे लगता है कि मुझे स्पष्ट करना चाहिए कि मुझे इस पर विश्वास नहीं है। 80 के दशक में शुरू होने वाले दृश्य पर CASE टूल दिखाई दिए, लेकिन शुरुआती टूल ने जो कुछ भी आकर्षित किया, उसके आरेखों के लिए केवल पिक्सेल पर कब्जा कर लिया; जबकि उपकरण यकीनन व्यावसायिक रूप से सफल थे, वे वास्तव में बहुत मददगार नहीं थे। एक प्रमुख अंतर्दृष्टि यह थी कि यदि अतिरिक्त "डिज़ाइन" कलाकृतियाँ औपचारिक रूप से व्याख्या योग्य नहीं हैं, तो आपको कोई गंभीर उपकरण सहायता नहीं मिल सकती है। मेरा मानना है कि समान अंतर्दृष्टि डिजाइन कैप्चर के किसी भी दीर्घकालिक उपयोगी रूप पर लागू होती है: यदि इसे एक औपचारिक संरचना नहीं मिली है, तो यह किसी भी वास्तविक उपयोग की नहीं होगी। पाठ दस्तावेज़ बहुत इस परीक्षण में विफल।