सॉफ्टवेयर डिजाइन बनाम सॉफ्टवेयर आर्किटेक्चर [बंद]

Question

क्या कोई सॉफ्टवेयर डिजाइन और सॉफ्टवेयर आर्किटेक्चर के बीच अंतर बता सकता है?

अधिक विशेष रूप से; अगर आप किसी को 'डिजाइन' पेश करने के लिए कहते हैं - तो आप उनसे क्या उम्मीद करेंगे? वही 'आर्किटेक्चर' के लिए जाता है।

मेरी वर्तमान समझ है:

• डिजाइन: सिस्टम के एक विशिष्ट मॉड्यूल / भाग के लिए यूएमएल आरेख / प्रवाह चार्ट / सरल वायरफ्रेम (यूआई के लिए)
• वास्तुकला: घटक आरेख (यह दर्शाता है कि सिस्टम के विभिन्न मॉड्यूल एक दूसरे और अन्य प्रणालियों के साथ कैसे संवाद करते हैं), किस भाषा का उपयोग किया जाना है, पैटर्न ...?

यदि मैं गलत हूं तो मुझे सही करों। मैंने विकिपीडिया पर http://en.wikipedia.org/wiki/Software_design और http://en.wikipedia.org/wiki/Software_altecture पर लेखों का उल्लेख किया है , लेकिन मुझे यकीन नहीं है कि मैंने उन्हें सही ढंग से समझा है।

Comments

नीचे दिए गए किसी भी प्रश्न सहायक थे? ;)

— पैट्रिक करचर 26:10

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

— हॉट लिक्स

और मैंने एक बार वास्तुकला को "एक उद्देश्य के अनुकूल डिजाइन" के रूप में वर्णित देखा। यह थोड़ा मुश्किल है, लेकिन इसमें सच्चाई की एक डली है, क्योंकि अच्छी वास्तुकला को अंततः उद्देश्य-केंद्रित बनाम कार्यान्वयन-केंद्रित होना चाहिए।

— हॉट लक्स

Answer 1

तुम ठीक कह रहे हो। एक प्रणाली की वास्तुकला इसका 'कंकाल' है। यह सिस्टम के अमूर्त स्तर का उच्चतम स्तर है। किस तरह का डेटा स्टोरेज मौजूद है, मॉड्यूल एक-दूसरे के साथ कैसे तालमेल बिठाते हैं, रिकवरी सिस्टम क्या हैं। डिज़ाइन पैटर्न की तरह, वास्तुशिल्प पैटर्न हैं: MVC, 3-स्तरीय स्तरित डिज़ाइन, आदि।

सॉफ्टवेयर डिजाइन व्यक्तिगत मॉड्यूल / घटकों को डिजाइन करने के बारे में है। मॉड्यूल x की जिम्मेदारियां, कार्य, क्या हैं? वर्ग Y का? यह क्या कर सकता है, और क्या नहीं? किस डिज़ाइन पैटर्न का उपयोग किया जा सकता है?

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

Comments

इसके अलावा, वास्तुकला आमतौर पर क्या (किया जाता है) और कहां (यह किया जाता है) से संबंधित है, लेकिन कभी भी कैसे। ऐसा लगता है कि सिद्धांत का अंतर है - डिजाइन इस बात को पूरा करता है कि वास्तुकला कैसे (और नहीं) के बारे में बात नहीं करती है।

— आसफ आर

हाय @ आसफ़र! इसने मुझे वास्तुकला के विश्लेषण के बारे में सोचा क्योंकि विश्लेषण क्या (क्या किया जाता है) के साथ व्यवहार करता है और कैसे आप ऐसा सोचते हैं?

— क्रिस

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

— माजियार

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

— इवान हुआ

ऐसा इसलिए है क्योंकि एमवीसी एक वास्तुशिल्प डिजाइन है। MVC अपने आप में कोई विवरण नहीं बताता है। "व्यू" एक वेबसाइट, एक वाइनफॉर्म, एक कंसोल एप्लिकेशन हो सकता है। मॉडल लगभग कुछ भी हो सकता है, यह कुछ भी नहीं बताता है कि यह कहां से आता है (डेटाबेस परत या जो भी हो)।

— रेजी

Answer 2

एसडीएलसी (सॉफ्टवेयर डेवलपमेंट लाइफ साइकल) के कुछ विवरणों में वे विनिमेय हैं, लेकिन कंसस यह है कि वे अलग हैं। वे एक ही समय में हैं: विभिन्न (1) चरणों , (2) जिम्मेदारी के क्षेत्र , और निर्णय लेने के स्तर (3) ।

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

इन दो चरणों में होगा लगते विभिन्न कारणों के लिए एक साथ मिश्रण।

1. छोटी परियोजनाओं में अक्सर नियोजन को इन चरणों में अलग करने की पर्याप्त गुंजाइश नहीं होती है।
2. एक परियोजना एक बड़ी परियोजना का हिस्सा हो सकती है, और इसलिए दोनों चरणों के हिस्से पहले से ही तय किए जाते हैं। (पहले से ही मौजूद डेटाबेस, कन्वेंशन, मानक, प्रोटोकॉल, फ्रेमवर्क, पुन: प्रयोज्य कोड, आदि हैं)
3. एसडीएलसी के बारे में सोचने के नए तरीके ( फुर्तीली कार्यप्रणाली देखें ) कुछ हद तक इस पारंपरिक दृष्टिकोण को पुनर्व्यवस्थित करते हैं। डिजाइन (वास्तुकला कुछ हद तक) पूरे SDLC उद्देश्य पर होता है । अक्सर अधिक पुनरावृत्तियां होती हैं जहां पूरी प्रक्रिया बार-बार होती है।
4. सॉफ्टवेयर विकास वैसे भी योजना के लिए जटिल और कठिन है, लेकिन ग्राहक / प्रबंधक / सेल्सपर्स आमतौर पर लक्ष्यों और आवश्यकताओं को मध्य-धारा में बदलते हुए इसे कठिन बना देते हैं। डिजाइन और यहां तक ​​कि वास्तु निर्णय भी इस परियोजना में बाद में होने चाहिए कि क्या योजना है या नहीं।

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

Comments

अच्छा उत्तर। मैं कैसे एक कर सकते हैं पर जोर देने की तरह लग रहे अन्य का हिस्सा बनने का। चौथा बिंदु एक दिलचस्प सवाल उठाता है: क्या किसी विशेष समस्या डोमेन में डिज़ाइन किसी भी कम वैध है जब उसके पास अभी तक कोई वास्तुकला नहीं है? अनुभव हां का सुझाव देता है, लेकिन सिद्धांत रूप में मैं यह सोचना चाहता हूं कि एक डिजाइन जो उचित दायरे में रहता है (यानी किसी विशेष घटक के लिए) समान रूप से वैध होना चाहिए, भले ही इसका उपयोग कैसे किया जाए।

— टॉम डब्ल्यू

Answer 3

आर्किटेक्चर रणनीतिक है, जबकि डिजाइन सामरिक है।

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

जबकि डिजाइन स्थानीय बाधाओं से संबंधित गतिविधि है, जैसे कि डिजाइन पैटर्न, प्रोग्रामिंग मुहावरे और रिफैक्टोरिंग।

Comments

मैं इस वोट बढ़ाने के लिए "डिजाइन" और "आर्किटैक्चर" "डिजाइन" की परिभाषा में करने के लिए कम संदर्भ चाहते हैं ...

— पीटर हैनसेन

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

— क्रिस कन्नन

Answer 4

मैंने इसे पाया क्योंकि मैं वास्तुकला और डिजाइन के बीच सरल अंतर की तलाश कर रहा था;
आप उन्हें देखने के इस तरीके से क्या समझते हैं:

• वास्तुकला "क्या" हम निर्माण कर रहे हैं;
• डिजाइन "कैसे" हम निर्माण कर रहे हैं;

Comments

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

— मारेक

@ मारेक मुझे नहीं दिखता कि इसमें क्या गलत है। आर्किटेक्चर क्या बनाना है, क्लाइंट क्या चाहता है, इसे आम तौर पर कैसा दिखना चाहिए, इसे किन घटकों से बनाया जाना चाहिए, आदि। डिजाइन यह है कि ये चीजें वास्तव में कैसे बनाई जाती हैं: घटकों, एल्गोरिदम, आदि का वास्तविक कार्यान्वयन

— RecursiveExceptionException

Answer 5

1. आर्किटेक्चर का अर्थ है कंप्यूटर या कंप्यूटर आधारित प्रणाली की वैचारिक संरचना और तार्किक संगठन।

   डिजाइन का मतलब है कि किसी सिस्टम या किसी वस्तु के लुक और फंक्शन या कामकाज को दिखाने के लिए तैयार की गई योजना या ड्राइंग।

2. यदि आप एक घटक "आर्किटेक्चरिंग" कर रहे हैं, तो आप परिभाषित कर रहे हैं कि यह बड़ी प्रणाली में कैसे व्यवहार करता है।

   यदि आप एक ही घटक को "डिज़ाइन" कर रहे हैं, तो आप परिभाषित कर रहे हैं कि यह आंतरिक रूप से कैसे व्यवहार करता है।

सभी वास्तुकला डिजाइन है, लेकिन सभी डिजाइन वास्तुकला नहीं है।

Whatहिस्सा डिजाइन है, Howठोस कार्यान्वयन और का चौराहा है Whatऔर Howवास्तुकला है।

आर्किटेक्चर और डिज़ाइन को अलग करने के लिए छवि :

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

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

वह कड़ी जो अच्छी उपमा देती है

Comments

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

— बनती है

Answer 6

मैं कहूंगा कि तुम सही हो, मेरे अपने शब्दों में;

आर्किटेक्चर सिस्टम तत्वों के लिए सिस्टम आवश्यकताओं का आवंटन है। एक वास्तुकला के बारे में चार कथन:

1. यह भाषा या पैटर्न जैसी गैर-कार्यात्मक आवश्यकताओं को पेश कर सकता है।
2. यह घटकों, इंटरफेस, समय, आदि के बीच बातचीत को परिभाषित करता है।
3. यह नई कार्यक्षमता का परिचय नहीं देगा,
4. यह उन (डिज़ाइन किए गए) कार्यों को आवंटित करता है जो सिस्टम तत्वों को करने के लिए अभिप्रेत है।

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

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

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

यह अच्छा होगा कि रसोई के डिजाइन को रसोई स्थापित करने से पहले देखें लेकिन खाना पकाने के लिए यह आवश्यक नहीं है :

अगर मुझे लगता है कि आप इसके बारे में बता सकते हैं:

• वास्तुकला एक सार्वजनिक / इंजीनियरों के लिए अधिक विस्तृत अमूर्त स्तर पर है
• डिजाइन कम विस्तृत अमूर्त स्तर पर जनता के लिए अभिप्रेत है

Comments

आर्किटेक्चर के लिए +1 सिस्टम तत्वों के लिए सिस्टम आवश्यकताओं का आवंटन है। अंतिम सूची में 'a' शब्द के उपयोग के लिए वर्चुअल -1। इस पर मेरा लेना आपकी (सही) प्रारंभिक परिभाषा है, अमूर्तता का विरोधी है।

— क्रिस वाल्टन

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

— माइक जी

क्रियान्वयन में कहाँ फिट होता है? क्या कार्यान्वयन डिजाइन नहीं है?

— jwilleke

Answer 7

मेरा अनुस्मारक:

• हम बिना किसी से पूछे डिजाइन को बदल सकते हैं
• यदि हम आर्किटेक्चर को बदलते हैं, तो हमें किसी से संपर्क करने की आवश्यकता है (टीम, ग्राहक, हितधारक, ...)

Answer 8

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

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

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

( Http://www.copypasteisforword.com/notes/software-altecture-vs-software-design से एक टुकड़ा )

Comments

मुझे यह बहुत पसंद है। अच्छा योगदान है। मुझे यकीन नहीं है कि अगर यह इतना स्पष्ट है, लेकिन इस तरह के एक सवाल पर यह आपके बारे में निश्चित है जितना कि आप प्राप्त करेंगे। मैं आपको वोट दूंगा लेकिन मैं दिन के लिए वोट कर रहा हूं :(।

— माइक जी

Answer 9

व्यक्तिगत रूप से, मुझे यह पसंद है:

"डिजाइनर का संबंध तब होता है जब उपयोगकर्ता किसी बटन को दबाता है, और आर्किटेक्ट का संबंध तब होता है जब दस हजार उपयोगकर्ता एक बटन दबाते हैं।"

जावा कैड और हम्फ्री शील द्वारा जावा ™ ईई स्टडी गाइड के लिए SCEA

Comments

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

— रेने एनरिकेज़

Answer 10

मैं कई स्पष्टीकरणों से सहमत हूं; अनिवार्य रूप से हम वास्तुशिल्प डिजाइन और सॉफ्टवेयर सिस्टम के विस्तृत डिजाइन के बीच अंतर को पहचान रहे हैं।

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

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

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

Answer 11

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

यह कहना सामान्य है कि वास्तुकला डिजाइन की तुलना में उच्च स्तर पर है, या वास्तुकला तार्किक है और डिजाइन भौतिक है। लेकिन आमतौर पर स्वीकार की जाने वाली यह धारणा व्यवहार में बेकार है। आप तार्किक और भौतिक के बीच उच्च या निम्न अमूर्त के बीच की रेखा कहां खींचते हैं? निर्भर करता है!

तो, मेरा सुझाव है:

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

यह सब कहने के बाद ... एक और अधिक प्रासंगिक प्रश्न जो हमें पूछने की जरूरत है: कितना डिजाइन पर्याप्त है? यही है, जब मुझे डिज़ाइन (आरेख या गद्य में) का वर्णन करना बंद करना चाहिए और कोडिंग के लिए आगे बढ़ना चाहिए?

Comments

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

— थॉमस एलिंजर

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

— पाउलो मर्सन

Answer 12

हां जो मुझे सही लगता है। डिजाइन वह है जो आप करने जा रहे हैं, और वास्तुकला वह तरीका है जिसमें डिजाइन के बिट्स और टुकड़े एक साथ जुड़ जाएंगे। यह भाषा अज्ञेय हो सकता है, लेकिन आमतौर पर इस्तेमाल की जाने वाली तकनीकों को निर्दिष्ट करेगा यानी LAMP v विंडोज, वेब सेवा v RPC।

Answer 13

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

(विकिपीडिया, http://en.wikipedia.org/wiki/Software_altecture से )

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

(विकिपीडिया, http://en.wikipedia.org/wiki/Software_design से )

खुद मैने इससे बेहतर नहीं कहा होता :)

Answer 14

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

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

आप लेआउट को देख सकते हैं, हालांकि "लेआउट को आर्किटेक्चर" कर सकते हैं ...

Answer 15

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

Answer 16

सॉफ्टवेयर वास्तुकला "मुद्दों के साथ संबंधित है ... संगणना के एल्गोरिदम और डेटा संरचनाओं से परे।

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

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

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

इस लिंक को देखें।

शर्तें वास्तुकला, डिजाइन और कार्यान्वयन को परिभाषित करना

Answer 17

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

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

Answer 18

मुझे वास्तव में डिजाइन से वास्तुकला को अलग करने पर अंगूठे के नियम के लिए यह पेपर पसंद आया:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

इसे इंटेंस / लोकलिटी परिकल्पना कहा जाता है। सॉफ्टवेयर की प्रकृति पर कथन जो गैर-स्थानीय और आयामी हैं, वास्तुशिल्प हैं। ऐसे स्टेटमेंट जो स्थानीय और आन्तरिक हैं, डिजाइन हैं।

Comments

हाँ बिल्कुल। विचारों का एक ही सेट (एक ही लेखक से) जो मैं ऊपर सुझाव देता हूं। मुझे लगता है कि वे इस क्षेत्र में सहायक विचार हैं।

— इयोन

Answer 19

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

Comments

मुझे यह उत्तर सिर्फ इस वाक्य के कारण पसंद है "लेकिन वास्तुकला डिजाइन के भीतर भी है।" मैं कहूंगा कि "वास्तुकला डिजाइन के भीतर हो सकती है।" - यह आप पर निर्भर करता है। वे अलग नहीं हुए हैं।

— मिरोस्लाव ट्रिनीक

Answer 20

सुंदर व्यक्तिपरक लेकिन मेरा लेना:

वास्तुकला अन्य प्रणालियों, हार्डवेयर आवश्यकता, समग्र घटक डिजाइन और डेटा प्रवाह के साथ बातचीत सहित प्रणाली का समग्र डिजाइन।

डिजाइन संगठन और समग्र प्रणाली में एक घटक का प्रवाह। इसमें अन्य घटकों के साथ बातचीत के लिए घटक का एपीआई भी शामिल होगा।

Answer 21

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

उदाहरण के लिए, आपका व्यवसाय व्यापारियों के लिए "लाभ और हानि" के बारे में है, और आपके मुख्य कार्यों में "पोर्टफोलियो मूल्यांकन" और "जोखिम गणना" शामिल है।

लेकिन जब कोई सॉफ्टवेयर आर्किटेक्ट उसके समाधान का विवरण देगा, तो उसे महसूस होगा कि:

"पोर्टफोलियो मूल्यांकन" केवल एक आवेदन नहीं हो सकता है। इसे प्रबंधनीय परियोजनाओं में परिष्कृत किया जाना चाहिए:

• जीयूआई
• लांचर
• डिस्पैचर
• ...

(क्योंकि इसमें शामिल संचालन इतने विशाल होते हैं कि उन्हें कई कंप्यूटरों के बीच विभाजित करने की आवश्यकता होती है, जबकि सामान्य जीयूआई के माध्यम से हर समय निगरानी की जाती है)

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

Answer 22

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

यदि वह फिर इंजन के निर्माण को किसी अन्य टीम को सौंपता है, तो वे "इंजन आर्किटेक्चर" बनाएंगे ...

तो - यह अमूर्तता या विस्तार के स्तर पर निर्भर करता है। एक व्यक्ति का आर्किटेक्चर हो सकता है माता की डिजाइन!

Answer 23

वास्तुकला "डिजाइन के फैसले हैं जिन्हें बदलना मुश्किल है।"

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

इसका मतलब है कि आर्किटेक्चर भाषा, फ्रेमवर्क और आपके सिस्टम के डोमेन पर निर्भर करता है। यदि आप 5 मिनट में अपने जावा क्लास से सिर्फ एक इंटरफ़ेस निकाल सकते हैं, तो यह अब और वास्तुकला का निर्णय नहीं है।

Answer 24

क्लिफ नोट्स संस्करण:

डिजाइन: वांछित उत्पाद के विनिर्देशों के आधार पर एक समाधान को लागू करना।

वास्तुकला: नींव / उपकरण / बुनियादी ढांचा / घटक जो आपके डिजाइन का समर्थन करते हैं।

यह एक बहुत व्यापक प्रश्न है जो बहुत सारी प्रतिक्रियाओं को आमंत्रित करेगा।

Answer 25

आर्किटेक्चर एक सिस्टम बनाने के लिए डिज़ाइन पैटर्न का परिणामी संग्रह है।

मुझे लगता है कि डिजाइन रचनात्मकता यह सब एक साथ रखा जाता है?

Comments

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

— जेवियर

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

— मार्क रेडमैन

Answer 26

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

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

प्रैक्टिशनर आर्क को उच्च-स्तरीय डिज़ाइन निर्णयों के रूप में देखते हैं जो कि रणनीतिक हैं और एक परियोजना में पूर्ववत करना महंगा हो सकता है।

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

Answer 27

आर्किटेक्चर उच्च स्तर, सार और तार्किक डिज़ाइन है जबकि सॉफ्टवेयर डिज़ाइन निम्न स्तर, विस्तृत और भौतिक डिज़ाइन है।

Answer 28

इसके अलावा, देखें: http://en.wikipedia.org/wiki/4%2B1_Achitchitural_View_MMel

Comments

वड्डी, कृपया लिंक को पोस्ट करने के साथ सामग्री को संक्षेप में प्रस्तुत करने पर विचार करें। विषय पर चर्चा के लिए यह मेटा पोस्ट देखें । धन्यवाद!

— गार्जेंटुचेट

Answer 29

मुझे रॉय थॉमस फील्डिंग की परिभाषा और उनके पेपर में सॉफ्टवेयर आर्किटेक्चर के बारे में व्याख्या पसंद है: आर्किटेक्चरल स्टाइल्स एंड द डिजाइन ऑफ नेटवर्क-आधारित सॉफ्टवेयर आर्किटेक्चर

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

वह "रन-टाइम एलिमेंट्स" और "एब्सट्रैक्शन के स्तर" पर जोर देता है।

Comments

रन-टाइम एलिमेंट्स को एप्लिकेशन के कंपोनेंट या मॉड्यूल के लिए भी संदर्भित किया जाता है और प्रत्येक मॉड्यूल या कंपोनेंट में एब्सट्रैक्शन का अपना स्तर होता है। सही बात?

— अंकित राणा

Answer 30

इसका कोई निश्चित जवाब नहीं है क्योंकि "सॉफ्टवेयर आर्किटेक्चर" और "सॉफ्टवेयर डिजाइन" की काफी परिभाषाएं हैं और दोनों के लिए एक विहित परिभाषा नहीं है।

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

मेरी थोड़ी फ़्लिप्टेंट परिभाषा ( एसईआई परिभाषा पृष्ठ पर पाई गई ) यह है कि यह उन निर्णयों का समूह है, जिन्हें यदि गलत तरीके से बनाया गया है, तो आपकी परियोजना रद्द हो जाती है।

आर्किटेक्चर, डिजाइन और कार्यान्वयन को अवधारणाओं के रूप में अलग करने का एक उपयोगी प्रयास कुछ वर्षों पहले "वास्तुकला, डिजाइन, कार्यान्वयन" नामक एक शोध पत्र में अमन ईडन और रिक कज़मैन द्वारा किया गया था, जो यहां पाया जा सकता है: http: //www.sei.cmu .edu / पुस्तकालय / आस्तियों / ICSE03-1.pdf । उनकी भाषा काफी सारगर्भित है, लेकिन सरलता से वे कहते हैं कि आर्किटेक्चर एक ऐसा डिज़ाइन है जिसका उपयोग कई संदर्भों में किया जा सकता है और इसका अर्थ सिस्टम के पार लगाया जाना है, डिज़ाइन (गलत) डिज़ाइन है जिसे कई संदर्भों में उपयोग किया जा सकता है लेकिन एक विशिष्ट भाग में लागू किया जाता है प्रणाली, और कार्यान्वयन एक संदर्भ के लिए विशिष्ट है और उस संदर्भ में लागू किया गया है।

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

आशा है कि ये आपकी मदद करेगा!