Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 201 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
201 questions
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.
व्याख्या (हिन्दी) ब्लैक-बॉक्स पुन: उपयोग एक घटक को एक अपारदर्शी इकाई के रूप में मानता है जो केवल उसके इंटरफ़ेस अनुबंध द्वारा परिभाषित होता है (यह क्या करता है, कैसे नहीं)। व्हाइट-बॉक्स के पुन: उपयोग के लिए स्रोत कोड की जांच और अक्सर संशोधन की आवश्यकता होती है - कार्यान्वयन विवरणों के लिए सख्त युग्मन बनाना जो घटक अद्यतन होने पर टूट जाता है।
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) सिस्टम संगठन का वर्णन करता है: माइक्रोसर्विसेज यह निर्धारित करता है कि प्रक्रिया सीमाओं के पार एक सिस्टम को कैसे विघटित किया जाए; यह कोई डिज़ाइन विवरण नहीं है बल्कि तैनाती, स्केलिंग और टीम संगठन के लिए सिस्टम-व्यापी निहितार्थ के साथ एक मौलिक संरचनात्मक प्रतिबद्धता है।
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.
व्याख्या (हिन्दी) सिस्टम डिज़ाइन (वास्तुशिल्प डिज़ाइन) समग्र सिस्टम को हार्डवेयर, सॉफ़्टवेयर और नेटवर्क सबसिस्टम में विभाजित करता है, उनके इंटरफेस को परिभाषित करता है। सॉफ़्टवेयर डिज़ाइन फिर सॉफ़्टवेयर सबसिस्टम को विस्तृत करता है - मॉड्यूल संरचना, डेटा संरचना और एल्गोरिदम को निर्दिष्ट करता है।
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.
व्याख्या (हिन्दी) उच्च सामंजस्य का मतलब है कि एक मॉड्यूल का एक ही अच्छी तरह से परिभाषित उद्देश्य (एसआरपी) है। कम युग्मन का मतलब है कि मॉड्यूल एक-दूसरे के आंतरिक पहलुओं को जाने बिना न्यूनतम इंटरफेस के माध्यम से बातचीत करते हैं। साथ में वे मॉड्यूल के स्वतंत्र संशोधन, परीक्षण और प्रतिस्थापन को सक्षम करते हैं।
200
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.
व्याख्या (हिन्दी) ब्लैक-बॉक्स पुन: उपयोग एक घटक को एक अपारदर्शी इकाई के रूप में मानता है जो केवल उसके इंटरफ़ेस अनुबंध द्वारा परिभाषित होता है (यह क्या करता है, कैसे नहीं)। व्हाइट-बॉक्स के पुन: उपयोग के लिए स्रोत कोड की जांच और अक्सर संशोधन की आवश्यकता होती है - कार्यान्वयन विवरणों के लिए सख्त युग्मन बनाना जो घटक अद्यतन होने पर टूट जाता है।
201
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) सिस्टम संगठन का वर्णन करता है: माइक्रोसर्विसेज यह निर्धारित करता है कि प्रक्रिया सीमाओं के पार एक सिस्टम को कैसे विघटित किया जाए; यह कोई डिज़ाइन विवरण नहीं है बल्कि तैनाती, स्केलिंग और टीम संगठन के लिए सिस्टम-व्यापी निहितार्थ के साथ एक मौलिक संरचनात्मक प्रतिबद्धता है।
196–201 of 201