196 Question 196 EN + हिं Medium GB What distinguishes 'black-box' from 'white-box' design in component-based software design? IN घटक-आधारित सॉफ़्टवेयर डिज़ाइन में 'ब्लैक-बॉक्स' को 'व्हाइट-बॉक्स' डिज़ाइन से क्या अलग करता है? A Black-box uses dark IDE themes; white-box uses light themes ब्लैक-बॉक्स डार्क आईडीई थीम का उपयोग करता है; व्हाइट-बॉक्स हल्के विषयों का उपयोग करता है B Black-box specifies behaviour through interface only, hiding implementation; white-box exposes internal structure requiring users to understand internals to use it correctly ब्लैक-बॉक्स केवल इंटरफ़ेस के माध्यम से व्यवहार को निर्दिष्ट करता है, कार्यान्वयन को छुपाता है; व्हाइट-बॉक्स आंतरिक संरचना को उजागर करता है जिससे उपयोगकर्ताओं को इसे सही ढंग से उपयोग करने के लिए आंतरिक को समझने की आवश्यकता होती है C Black-box is for security systems; white-box for non-security ब्लैक-बॉक्स सुरक्षा प्रणालियों के लिए है; गैर-सुरक्षा के लिए व्हाइट-बॉक्स D Black-box components cannot be tested; white-box can be fully automated tested ब्लैक-बॉक्स घटकों का परीक्षण नहीं किया जा सकता; व्हाइट-बॉक्स का पूरी तरह से स्वचालित परीक्षण किया जा सकता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Black-box reuse treats a component as an opaque unit defined only by its interface contract (what it does, not how). White-box reuse requires examining and often modifying source code — creating tight coupling to implementation details that break when the component is updated. व्याख्या (हिन्दी) ब्लैक-बॉक्स पुन: उपयोग एक घटक को एक अपारदर्शी इकाई के रूप में मानता है जो केवल उसके इंटरफ़ेस अनुबंध द्वारा परिभाषित होता है (यह क्या करता है, कैसे नहीं)। व्हाइट-बॉक्स के पुन: उपयोग के लिए स्रोत कोड की जांच और अक्सर संशोधन की आवश्यकता होती है - कार्यान्वयन विवरणों के लिए सख्त युग्मन बनाना जो घटक अद्यतन होने पर टूट जाता है। 🎯 Exam Perspective Software Engineering ("Software Design" sub-topic) के इस प्रश्न को — difficulty level "Medium" कई प्रतियोगी परीक्षाओं जैसे SSC CGL, IBPS, RRB और State-level परीक्षाओं में repeat होते देखा गया है। Concept clarity के लिए explanation section जरूर पढ़ें। 🔗 Related Questions What is the difference between 'cohesion' and 'coupling... What is 'design pattern' versus 'architectural pattern'... What distinguishes 'black-box' from 'white-box' design... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
197 Question 197 EN + हिं Easy GB What is 'design pattern' versus 'architectural pattern', and what is a concrete example of each? IN 'डिज़ाइन पैटर्न' बनाम 'वास्तुशिल्प पैटर्न' क्या है, और प्रत्येक का एक ठोस उदाहरण क्या है? A Design patterns apply to databases; architectural patterns apply to application code डिज़ाइन पैटर्न डेटाबेस पर लागू होते हैं; आर्किटेक्चरल पैटर्न एप्लिकेशन कोड पर लागू होते हैं B Architectural patterns describe system-level structure (Microservices, MVC, Event-driven, Layered); design patterns describe local object-level solutions (Singleton, Observer, Factory) — architectural patterns have system-wide impact; design patterns are applied within individual components वास्तुशिल्प पैटर्न सिस्टम-स्तरीय संरचना (माइक्रोसर्विसेज, एमवीसी, इवेंट-संचालित, स्तरित) का वर्णन करते हैं; डिज़ाइन पैटर्न स्थानीय ऑब्जेक्ट-स्तरीय समाधानों (सिंगलटन, ऑब्जर्वर, फ़ैक्टरी) का वर्णन करते हैं - वास्तुशिल्प पैटर्न का सिस्टम-व्यापी प्रभाव होता है; डिज़ाइन पैटर्न व्यक्तिगत घटकों के भीतर लागू किए जाते हैं C Both terms are synonymous; the distinction is merely academic दोनों शब्द पर्यायवाची हैं; यह भेद केवल अकादमिक है D Design patterns are proprietary to GoF authors; architectural patterns are in the public domain डिज़ाइन पैटर्न GoF लेखकों के स्वामित्व में हैं; वास्तुशिल्प पैटर्न सार्वजनिक डोमेन में हैं ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) GoF's 23 patterns (Observer, Factory, Strategy) solve recurring object-collaboration problems within a component; they are implementation-level tools. Architectural patterns (Fowler's PoEAA, Buschmann's POSA) describe system organisation: Microservices determines how to decompose a system across process boundaries; this is not a design detail but a fundamental structural commitment with system-wide implications for deployment, scaling, and team organisation. व्याख्या (हिन्दी) GoF के 23 पैटर्न (पर्यवेक्षक, फ़ैक्टरी, रणनीति) एक घटक के भीतर आवर्ती ऑब्जेक्ट-सहयोग समस्याओं को हल करते हैं; वे कार्यान्वयन-स्तर के उपकरण हैं। वास्तुशिल्प पैटर्न (फाउलर का PoEAA, बुशमैन का POSA) सिस्टम संगठन का वर्णन करता है: माइक्रोसर्विसेज यह निर्धारित करता है कि प्रक्रिया सीमाओं के पार एक सिस्टम को कैसे विघटित किया जाए; यह कोई डिज़ाइन विवरण नहीं है बल्कि तैनाती, स्केलिंग और टीम संगठन के लिए सिस्टम-व्यापी निहितार्थ के साथ एक मौलिक संरचनात्मक प्रतिबद्धता है। 🎯 Exam Perspective यह सवाल Software Engineering ("Software Design" sub-topic) category का है — difficulty level "Easy", और Railway, SSC, Banking और Defence परीक्षाओं के exam pattern में इस तरह के questions common हैं। Answer choose करने के बाद दिया गया explanation जरूर पढ़ें। 🔗 Related Questions What distinguishes 'black-box' from 'white-box' design... What distinguishes 'black-box' from 'white-box' design... What is 'design pattern' versus 'architectural pattern'... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
198 Question 198 EN + हिं Medium GB In Waterfall, what distinguishes 'System Design' from 'Software Design'? IN वॉटरफॉल में, 'सिस्टम डिज़ाइन' को 'सॉफ़्टवेयर डिज़ाइन' से क्या अलग करता है? A System Design writes actual code; Software Design creates flowcharts सिस्टम डिज़ाइन वास्तविक कोड लिखता है; सॉफ्टवेयर डिज़ाइन फ़्लोचार्ट बनाता है B System Design allocates requirements to hardware and software components and establishes overall architecture; Software Design details the internal structure of software modules सिस्टम डिज़ाइन हार्डवेयर और सॉफ़्टवेयर घटकों के लिए आवश्यकताओं को आवंटित करता है और समग्र वास्तुकला स्थापित करता है; सॉफ़्टवेयर डिज़ाइन सॉफ़्टवेयर मॉड्यूल की आंतरिक संरचना का विवरण देता है C System Design is by customers; Software Design by developers सिस्टम डिज़ाइन ग्राहकों द्वारा होता है; डेवलपर्स द्वारा सॉफ्टवेयर डिजाइन D System Design covers only database schemas सिस्टम डिज़ाइन केवल डेटाबेस स्कीमा को कवर करता है ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) System Design (architectural design) partitions the overall system into hardware, software, and network subsystems, defining their interfaces. Software Design then elaborates the software subsystem — specifying module structure, data structures, and algorithms. व्याख्या (हिन्दी) सिस्टम डिज़ाइन (वास्तुशिल्प डिज़ाइन) समग्र सिस्टम को हार्डवेयर, सॉफ़्टवेयर और नेटवर्क सबसिस्टम में विभाजित करता है, उनके इंटरफेस को परिभाषित करता है। सॉफ़्टवेयर डिज़ाइन फिर सॉफ़्टवेयर सबसिस्टम को विस्तृत करता है - मॉड्यूल संरचना, डेटा संरचना और एल्गोरिदम को निर्दिष्ट करता है। 🎯 Exam Perspective यह प्रश्न Software Engineering ("Software Design" sub-topic) की तैयारी करने वाले अभ्यर्थियों के लिए उपयोगी है — difficulty level "Medium"। इस तरह के प्रश्न अक्सर SSC, Railway, Banking और State PCS जैसी परीक्षाओं में पूछे जाते रहे हैं, इसलिए concept और explanation दोनों को ध्यान से समझें, सिर्फ उत्तर याद न करें। 🔗 Related Questions What distinguishes 'black-box' from 'white-box' design... What distinguishes 'black-box' from 'white-box' design... What is the difference between 'cohesion' and 'coupling... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
199 Question 199 EN + हिं Hard GB What is the difference between 'cohesion' and 'coupling' in software design and what is the ideal goal? IN सॉफ़्टवेयर डिज़ाइन में 'सामंजस्य' और 'युग्मन' के बीच क्या अंतर है और आदर्श लक्ष्य क्या है? A High coupling and low cohesion is ideal; it allows maximum code reuse उच्च युग्मन और निम्न सामंजस्य आदर्श है; यह अधिकतम कोड पुन: उपयोग की अनुमति देता है B Cohesion is how strongly related responsibilities within a module are; coupling is how dependent modules are on each other — ideal is high cohesion and low coupling सामंजस्य यह है कि एक मॉड्यूल के भीतर जिम्मेदारियाँ कितनी मजबूती से संबंधित हैं; युग्मन यह है कि मॉड्यूल एक दूसरे पर कैसे निर्भर होते हैं - आदर्श उच्च सामंजस्य और कम युग्मन है C Cohesion refers to number of methods in a class; coupling to number of classes in a package सामंजस्य एक वर्ग में विधियों की संख्या को संदर्भित करता है; एक पैकेज में कक्षाओं की संख्या को युग्मित करना D Both cohesion and coupling should be minimised सामंजस्य और युग्मन दोनों को कम से कम किया जाना चाहिए ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) High cohesion means a module has a single well-defined purpose (SRP). Low coupling means modules interact through minimal interfaces without knowing each other's internals. Together they enable independent modification, testing, and replacement of modules. व्याख्या (हिन्दी) उच्च सामंजस्य का मतलब है कि एक मॉड्यूल का एक ही अच्छी तरह से परिभाषित उद्देश्य (एसआरपी) है। कम युग्मन का मतलब है कि मॉड्यूल एक-दूसरे के आंतरिक पहलुओं को जाने बिना न्यूनतम इंटरफेस के माध्यम से बातचीत करते हैं। साथ में वे मॉड्यूल के स्वतंत्र संशोधन, परीक्षण और प्रतिस्थापन को सक्षम करते हैं। 🎯 Exam Perspective Software Engineering ("Software Design" sub-topic) से जुड़ा यह सवाल — difficulty level "Hard" उन students के लिए काम का है जो SSC, Railway, Banking और State PCS की तैयारी कर रहे हैं। बेहतर होगा कि explanation पढ़कर concept clear करें, ताकि exam में similar प्रश्न आने पर confusion न हो। 🔗 Related Questions What distinguishes 'black-box' from 'white-box' design... What distinguishes 'black-box' from 'white-box' design... What is 'design pattern' versus 'architectural pattern'... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
200 Question 200 EN + हिं Medium GB What distinguishes 'black-box' from 'white-box' design in component-based software design? IN What distinguishes 'black-box' from 'white-box' design in component-based software design? A Black-box uses dark IDE themes; white-box uses light themes Black-box uses dark IDE themes; white-box uses light themes B Black-box specifies behaviour through interface only, hiding implementation; white-box exposes internal structure requiring users to understand internals to use it correctly ब्लैक-बॉक्स केवल इंटरफ़ेस के माध्यम से व्यवहार को निर्दिष्ट करता है, कार्यान्वयन को छुपाता है; व्हाइट-बॉक्स आंतरिक संरचना को उजागर करता है जिसके लिए उपयोगकर्ताओं को इसे सही ढंग से उपयोग करने के लिए आंतरिक को समझने की आवश्यकता होती है C Black-box is for security systems; white-box for non-security Black-box is for security systems; white-box for non-security D Black-box components cannot be tested; white-box can be fully automated tested Black-box components cannot be tested; white-box can be fully automated tested ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) Black-box reuse treats a component as an opaque unit defined only by its interface contract (what it does, not how). White-box reuse requires examining and often modifying source code — creating tight coupling to implementation details that break when the component is updated. व्याख्या (हिन्दी) Black-box reuse treats a component as an opaque unit defined only by its interface contract (what it does, not how). White-box reuse requires examining and often modifying source code — creating tight coupling to implementation details that break when the component is updated. 🎯 Exam Perspective SSC, Railway, Banking और State PCS जैसी परीक्षाओं में Software Engineering ("Software Design" sub-topic) से सवाल अक्सर पूछे जाते हैं — difficulty level "Medium"। इसलिए सिर्फ answer रटने के बजाय, नीचे दी गई explanation को ध्यान से पढ़ें और concept समझें। 🔗 Related Questions What is the difference between 'cohesion' and 'coupling... What distinguishes 'black-box' from 'white-box' design... In Waterfall, what distinguishes 'System Design' from '... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)
201 Question 201 EN + हिं Easy GB What is 'design pattern' versus 'architectural pattern', and what is a concrete example of each? IN What is 'design pattern' versus 'architectural pattern', and what is a concrete example of each? A Design patterns apply to databases; architectural patterns apply to application code Design patterns apply to databases; architectural patterns apply to application code B Architectural patterns describe system-level structure (Microservices, MVC, Event-driven, Layered); design patterns describe local object-level solutions (Singleton, Observer, Factory) — architectural patterns have system-wide impact; design patterns are applied within individual components Architectural patterns describe system-level structure (Microservices, MVC, Event-driven, Layered); design patterns describe local object-level solutions (Singleton, Observer, Factory) — architectural patterns have system-wide impact; design patterns are applied within individual components C Both terms are synonymous; the distinction is merely academic Both terms are synonymous; the distinction is merely academic D Design patterns are proprietary to GoF authors; architectural patterns are in the public domain Design patterns are proprietary to GoF authors; architectural patterns are in the public domain ✅ Correct Answer: 💡 Explanation / व्याख्या Explanation (English) GoF's 23 patterns (Observer, Factory, Strategy) solve recurring object-collaboration problems within a component; they are implementation-level tools. Architectural patterns (Fowler's PoEAA, Buschmann's POSA) describe system organisation: Microservices determines how to decompose a system across process boundaries; this is not a design detail but a fundamental structural commitment with system-wide implications for deployment, scaling, and team organisation. व्याख्या (हिन्दी) GoF के 23 पैटर्न (पर्यवेक्षक, फ़ैक्टरी, रणनीति) एक घटक के भीतर आवर्ती ऑब्जेक्ट-सहयोग समस्याओं को हल करते हैं; वे कार्यान्वयन-स्तर के उपकरण हैं। आर्किटेक्चरल पैटर्न (फाउलर का PoEAA, बुशमैन का POSA) सिस्टम संगठन का वर्णन करता है: माइक्रोसर्विसेज यह निर्धारित करता है कि प्रक्रिया सीमाओं के पार सिस्टम को कैसे विघटित किया जाए; यह कोई डिज़ाइन विवरण नहीं है बल्कि तैनाती, स्केलिंग और टीम संगठन के लिए सिस्टम-व्यापी निहितार्थ के साथ एक मौलिक संरचनात्मक प्रतिबद्धता है। 🎯 Exam Perspective अगर आप UPSC, SSC, Banking और Police भर्ती की तैयारी कर रहे हैं, तो Software Engineering ("Software Design" sub-topic) का यह topic आपके लिए महत्वपूर्ण है — difficulty level "Easy"। Exam में accuracy बढ़ाने के लिए हर सवाल की explanation जरूर पढ़ें। 🔗 Related Questions In Waterfall, what distinguishes 'System Design' from '... What distinguishes 'black-box' from 'white-box' design... What is the difference between 'cohesion' and 'coupling... 📚 Related Topic Introduction to Software Engineering (647) Software Development Models (195) Waterfall Model (197)