Software Engineering — MCQ Practice

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

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2176
EN + हिं Medium
GB What is the purpose of a 'use case' in requirements engineering and how does it differ from a user story?
IN आवश्यकता इंजीनियरिंग में 'उपयोग मामले' का उद्देश्य क्या है और यह उपयोगकर्ता की कहानी से कैसे भिन्न है?
A
Use cases are UML diagrams; user stories are test cases by QA teams उपयोग के मामले यूएमएल आरेख हैं; उपयोगकर्ता कहानियाँ QA टीमों द्वारा परीक्षण मामले हैं
B
A use case is a detailed description of system/actor interaction achieving a goal including main/alternative flows; a user story is a lightweight conversational expression of a requirement that defers detail to conversation उपयोग का मामला मुख्य/वैकल्पिक प्रवाह सहित किसी लक्ष्य को प्राप्त करने वाले सिस्टम/अभिनेता इंटरैक्शन का विस्तृत विवरण है; एक उपयोगकर्ता कहानी एक आवश्यकता की हल्की-फुल्की संवादात्मक अभिव्यक्ति है जो बातचीत में विस्तार प्रदान करती है
C
Use cases only for OOP systems; user stories apply to all paradigms केवल OOP सिस्टम के लिए केस का उपयोग करें; उपयोगकर्ता कहानियाँ सभी प्रतिमानों पर लागू होती हैं
D
User stories completely replace use cases in modern software engineering उपयोगकर्ता कहानियाँ आधुनिक सॉफ़्टवेयर इंजीनियरिंग में उपयोग के मामलों को पूरी तरह से बदल देती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Use cases provide structured complete descriptions with success/failure scenarios, pre/postconditions, and alternative flows — suitable for complex interactions and contractual specifications. User stories are intentionally brief placeholders for conversations in agile teams.
व्याख्या (हिन्दी) उपयोग के मामले सफलता/असफलता परिदृश्यों, पूर्व/उत्तर स्थितियों और वैकल्पिक प्रवाह के साथ संरचित पूर्ण विवरण प्रदान करते हैं - जटिल इंटरैक्शन और अनुबंध संबंधी विशिष्टताओं के लिए उपयुक्त। उपयोगकर्ता कहानियाँ सक्रिय टीमों में बातचीत के लिए जानबूझकर संक्षिप्त प्लेसहोल्डर हैं।
2177
EN + हिं Medium
GB What is the 'viewpoint-oriented' approach in requirements engineering and why is it valuable?
IN आवश्यकता इंजीनियरिंग में 'दृष्टिकोण-उन्मुख' दृष्टिकोण क्या है और यह मूल्यवान क्यों है?
A
All requirements must be written from the end user's perspective only सभी आवश्यकताओं को केवल अंतिम उपयोगकर्ता के दृष्टिकोण से लिखा जाना चाहिए
B
It structures requirements elicitation around multiple distinct stakeholder perspectives, helping discover conflicts and requirements invisible from any single viewpoint यह कई अलग-अलग हितधारक दृष्टिकोणों के इर्द-गिर्द आवश्यकताओं की संरचना करता है, जिससे किसी एक दृष्टिकोण से अदृश्य संघर्षों और आवश्यकताओं को खोजने में मदद मिलती है
C
Only applicable to multi-tenant cloud systems केवल बहु-किरायेदार क्लाउड सिस्टम पर लागू
D
Requires each team member to write separate requirements documents independently प्रत्येक टीम सदस्य को स्वतंत्र रूप से अलग-अलग आवश्यकता दस्तावेज़ लिखने की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Different stakeholders (users, administrators, regulators) have different and sometimes conflicting views. Viewpoint-oriented methods systematically capture each perspective, then explicitly reconcile conflicts — better surfaced during elicitation than during testing.
व्याख्या (हिन्दी) विभिन्न हितधारकों (उपयोगकर्ताओं, प्रशासकों, नियामकों) के अलग-अलग और कभी-कभी परस्पर विरोधी विचार होते हैं। दृष्टिकोण-उन्मुख तरीके प्रत्येक परिप्रेक्ष्य को व्यवस्थित रूप से पकड़ते हैं, फिर स्पष्ट रूप से संघर्षों को सुलझाते हैं - परीक्षण के दौरान की तुलना में स्पष्टीकरण के दौरान बेहतर ढंग से सामने आते हैं।
2178
EN + हिं Easy
GB What is 'prototyping' as a requirements elicitation technique and what is its primary risk?
IN आवश्यकताओं को पूरा करने की तकनीक के रूप में 'प्रोटोटाइपिंग' क्या है और इसका प्राथमिक जोखिम क्या है?
A
Creating a detailed architectural design before writing code; risk is over-specification कोड लिखने से पहले एक विस्तृत वास्तुशिल्प डिज़ाइन बनाना; जोखिम अति-विशिष्टता है
B
Building a partial/simulated version to elicit requirements through user interaction; primary risk is stakeholders mistaking the prototype for the final system and resisting necessary rework उपयोगकर्ता इंटरैक्शन के माध्यम से आवश्यकताओं को पूरा करने के लिए आंशिक/सिम्युलेटेड संस्करण का निर्माण; प्राथमिक जोखिम यह है कि हितधारक प्रोटोटाइप को अंतिम प्रणाली समझ लेते हैं और आवश्यक पुनर्कार्य का विरोध करते हैं
C
Always the cheapest requirements technique and should be used in all projects हमेशा सबसे सस्ती आवश्यकताओं वाली तकनीक और सभी परियोजनाओं में इसका उपयोग किया जाना चाहिए
D
Replaces requirements documentation entirely in modern development आधुनिक विकास में आवश्यकताओं के दस्तावेज़ीकरण को पूरी तरह से बदल देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Prototyping is powerful for eliciting tacit requirements users can't articulate verbally. The critical risk (Sommerville's 'prototype as final system') is that stakeholders see working UI and assume the system is nearly done, pressuring the team to release the technically inadequate prototype.
व्याख्या (हिन्दी) प्रोटोटाइप उन मौन आवश्यकताओं को प्राप्त करने के लिए शक्तिशाली है जिन्हें उपयोगकर्ता मौखिक रूप से व्यक्त नहीं कर सकते हैं। गंभीर जोखिम (सोमरविले का 'अंतिम सिस्टम के रूप में प्रोटोटाइप') यह है कि हितधारक काम कर रहे यूआई को देखते हैं और मान लेते हैं कि सिस्टम लगभग पूरा हो चुका है, जिससे टीम पर तकनीकी रूप से अपर्याप्त प्रोटोटाइप जारी करने का दबाव पड़ता है।
2179
EN + हिं Medium
GB What distinguishes 'elicitation' from 'analysis' in requirements engineering?
IN आवश्यकता इंजीनियरिंग में 'एलिसिटेशन' को 'विश्लेषण' से क्या अलग करता है?
A
Elicitation is done by customers; analysis by developers उद्दीपन ग्राहकों द्वारा किया जाता है; डेवलपर्स द्वारा विश्लेषण
B
Elicitation discovers and gathers requirements from stakeholders; analysis studies them for consistency, completeness, and resolves conflicts among elicited requirements एलीसिटेशन हितधारकों से आवश्यकताओं की खोज करता है और उन्हें एकत्र करता है; विश्लेषण निरंतरता, पूर्णता के लिए उनका अध्ययन करता है और उत्पन्न आवश्यकताओं के बीच टकराव का समाधान करता है
C
Elicitation only uses interviews; analysis only uses formal specification languages एलीसिटेशन केवल साक्षात्कार का उपयोग करता है; विश्लेषण केवल औपचारिक विनिर्देश भाषाओं का उपयोग करता है
D
Analysis precedes elicitation in the requirements process आवश्यकताओं की प्रक्रिया में विश्लेषण से पहले विश्लेषण किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Elicitation focuses on discovering what stakeholders need through interviews, workshops, observation. Analysis takes raw discovered requirements and studies them for internal consistency (no contradictions), completeness, and feasibility. Requirements from different stakeholders often conflict and analysis is where those conflicts are resolved.
व्याख्या (हिन्दी) एलीसिटेशन साक्षात्कार, कार्यशालाओं, अवलोकन के माध्यम से यह पता लगाने पर केंद्रित है कि हितधारकों को क्या चाहिए। विश्लेषण कच्ची खोजी गई आवश्यकताओं को लेता है और आंतरिक स्थिरता (कोई विरोधाभास नहीं), पूर्णता और व्यवहार्यता के लिए उनका अध्ययन करता है। विभिन्न हितधारकों की आवश्यकताओं में अक्सर टकराव होता है और विश्लेषण वह जगह है जहां उन संघर्षों का समाधान किया जाता है।
2180
EN + हिं Easy
GB In IEEE 830, what does the 'verifiability' property of a good requirement mean?
IN आईईईई 830 में, एक अच्छी आवश्यकता की 'सत्यापनीयता' संपत्ति का क्या मतलब है?
A
Requirement has been verified by at least two senior stakeholders आवश्यकता को कम से कम दो वरिष्ठ हितधारकों द्वारा सत्यापित किया गया है
B
A cost-effective test, inspection, demonstration, or analysis method must exist that can confirm whether the requirement has been met एक लागत प्रभावी परीक्षण, निरीक्षण, प्रदर्शन या विश्लेषण विधि मौजूद होनी चाहिए जो पुष्टि कर सके कि आवश्यकता पूरी हो गई है या नहीं
C
Requirement source has been identified and documented आवश्यकता स्रोत की पहचान और दस्तावेजीकरण किया गया है
D
Requirement can be traced to a business objective in the project charter आवश्यकता का पता प्रोजेक्ट चार्टर में व्यावसायिक उद्देश्य से लगाया जा सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) IEEE 830 requires verifiability: a requirement must be stated so that a finite cost-effective procedure exists to check that the system satisfies it. 'User-friendly' is not verifiable; 'new users complete registration in under 3 minutes on first attempt' is verifiable through usability testing.
व्याख्या (हिन्दी) आईईईई 830 को सत्यापन की आवश्यकता है: एक आवश्यकता बताई जानी चाहिए ताकि यह जांचने के लिए एक सीमित लागत प्रभावी प्रक्रिया मौजूद हो कि सिस्टम इसे पूरा करता है। 'उपयोगकर्ता-अनुकूल' सत्यापन योग्य नहीं है; 'नए उपयोगकर्ता पहले प्रयास में 3 मिनट से कम समय में पंजीकरण पूरा कर लेते हैं' को प्रयोज्यता परीक्षण के माध्यम से सत्यापित किया जा सकता है।
2181
EN + हिं Easy
GB What is the 'gold plating' problem in requirements engineering and from which side does it typically originate?
IN आवश्यकताओं की इंजीनियरिंग में 'गोल्ड प्लेटिंग' समस्या क्या है और यह आमतौर पर किस तरफ से उत्पन्न होती है?
A
Customers demanding premium features outside budget ग्राहक बजट से बाहर प्रीमियम सुविधाओं की मांग कर रहे हैं
B
Developers adding unrequested features believing they improve the product — wasting effort on features customers may never use डेवलपर्स बिना अनुरोध वाली सुविधाएँ जोड़ रहे हैं, यह विश्वास करते हुए कि वे उत्पाद को बेहतर बनाते हैं - उन सुविधाओं पर प्रयास बर्बाद कर रहे हैं जिनका ग्राहक कभी उपयोग नहीं कर सकते हैं
C
Excessive requirements documentation adding cost without clarity अत्यधिक आवश्यकताओं वाला दस्तावेज़ स्पष्टता के बिना लागत जोड़ता है
D
A financial software engineering term for transaction security layers लेनदेन सुरक्षा परतों के लिए एक वित्तीय सॉफ्टवेयर इंजीनियरिंग शब्द
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Gold plating occurs when developers add features beyond what was requested, typically out of enthusiasm. While well-intentioned, it wastes resources, introduces unplanned testing requirements, and can complicate the interface.
व्याख्या (हिन्दी) गोल्ड प्लेटिंग तब होती है जब डेवलपर्स आम तौर पर उत्साह से, अनुरोधित सुविधाओं से अधिक सुविधाएँ जोड़ते हैं। नेक इरादे से होते हुए भी, यह संसाधनों को बर्बाद करता है, अनियोजित परीक्षण आवश्यकताओं को प्रस्तुत करता है, और इंटरफ़ेस को जटिल बना सकता है।
2182
EN + हिं Medium
GB What is 'requirements traceability' and why is it particularly important in safety-critical systems?
IN 'आवश्यकताओं का पता लगाने की क्षमता' क्या है और यह सुरक्षा-महत्वपूर्ण प्रणालियों में विशेष रूप से महत्वपूर्ण क्यों है?
A
Ability to track who requested each requirement and their contact information यह ट्रैक करने की क्षमता कि प्रत्येक आवश्यकता और उनकी संपर्क जानकारी का अनुरोध किसने किया
B
Documented relationship linking requirements to design, code, and tests — enabling impact analysis and verification that all requirements are implemented; critical in safety systems for certification compliance डिज़ाइन, कोड और परीक्षणों से आवश्यकताओं को जोड़ने वाला दस्तावेज़ीकृत संबंध - प्रभाव विश्लेषण और सत्यापन को सक्षम करना कि सभी आवश्यकताएं लागू की गई हैं; प्रमाणीकरण अनुपालन के लिए सुरक्षा प्रणालियों में महत्वपूर्ण
C
Version control strategy for managing multiple branches of requirements documents आवश्यकता दस्तावेज़ों की अनेक शाखाओं के प्रबंधन के लिए संस्करण नियंत्रण रणनीति
D
Only applies to hardware requirements केवल हार्डवेयर आवश्यकताओं पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Traceability matrices link requirements to design decisions, implementation, and test cases bidirectionally. In safety-critical systems, regulators require proof every safety requirement has been implemented and tested — traceability is the evidence.
व्याख्या (हिन्दी) ट्रैसेबिलिटी मैट्रिक्स आवश्यकताओं को डिजाइन निर्णयों, कार्यान्वयन और परीक्षण मामलों से द्विदिश रूप से जोड़ता है। सुरक्षा-महत्वपूर्ण प्रणालियों में, नियामकों को प्रमाण की आवश्यकता होती है कि प्रत्येक सुरक्षा आवश्यकता को लागू किया गया है और परीक्षण किया गया है - पता लगाने की क्षमता इसका प्रमाण है।
2183
EN + हिं Easy
GB What is the 'requirements baseline' and what governance rules typically apply to it?
IN 'आवश्यकताओं की आधार रेखा' क्या है और इस पर आमतौर पर कौन से शासन नियम लागू होते हैं?
A
A preliminary draft of requirements used only for initial cost estimation आवश्यकताओं का प्रारंभिक मसौदा केवल प्रारंभिक लागत अनुमान के लिए उपयोग किया जाता है
B
A formally approved version of the requirements document serving as the agreed reference; changes require formal change control — impact assessment, CCB approval, and version management सहमत संदर्भ के रूप में कार्य करने वाले आवश्यकता दस्तावेज़ का औपचारिक रूप से अनुमोदित संस्करण; परिवर्तनों के लिए औपचारिक परिवर्तन नियंत्रण की आवश्यकता होती है - प्रभाव मूल्यांकन, सीसीबी अनुमोदन और संस्करण प्रबंधन
C
Automatically updated whenever a developer commits code जब भी कोई डेवलपर कोड करता है तो स्वचालित रूप से अपडेट हो जाता है
D
Produced by the testing team after system testing is complete सिस्टम परीक्षण पूरा होने के बाद परीक्षण टीम द्वारा उत्पादित किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A requirements baseline establishes a controlled reference. Once baselined, requirements are under configuration management — changes cannot be made informally. A Change Control Board evaluates impact on cost, schedule, and quality, approving or rejecting proposed changes.
व्याख्या (हिन्दी) आवश्यकताओं की आधार रेखा एक नियंत्रित संदर्भ स्थापित करती है। एक बार आधारभूत हो जाने पर, आवश्यकताएँ कॉन्फ़िगरेशन प्रबंधन के अंतर्गत होती हैं - परिवर्तन अनौपचारिक रूप से नहीं किए जा सकते। एक परिवर्तन नियंत्रण बोर्ड प्रस्तावित परिवर्तनों को स्वीकृत या अस्वीकार करते हुए लागत, अनुसूची और गुणवत्ता पर प्रभाव का मूल्यांकन करता है।
2184
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.
व्याख्या (हिन्दी) उच्च सामंजस्य का मतलब है कि एक मॉड्यूल का एक ही अच्छी तरह से परिभाषित उद्देश्य (एसआरपी) है। कम युग्मन का मतलब है कि मॉड्यूल एक-दूसरे के आंतरिक पहलुओं को जाने बिना न्यूनतम इंटरफेस के माध्यम से बातचीत करते हैं। साथ में वे मॉड्यूल के स्वतंत्र संशोधन, परीक्षण और प्रतिस्थापन को सक्षम करते हैं।
2185
EN + हिं Easy
GB What does the Dependency Inversion Principle (DIP) state and what design problem does it solve?
IN निर्भरता व्युत्क्रम सिद्धांत (डीआईपी) क्या बताता है और यह किस डिज़ाइन समस्या का समाधान करता है?
A
All class dependencies should be injected through constructors rather than setters सभी वर्ग निर्भरताओं को सेटर्स के बजाय कंस्ट्रक्टर्स के माध्यम से इंजेक्ट किया जाना चाहिए
B
High-level modules should not depend on low-level modules; both should depend on abstractions — solving the problem where changing a low-level component forces changes throughout the system उच्च-स्तरीय मॉड्यूल को निम्न-स्तरीय मॉड्यूल पर निर्भर नहीं होना चाहिए; दोनों को अमूर्तता पर निर्भर होना चाहिए - उस समस्या को हल करना जहां निम्न-स्तरीय घटक को बदलने से पूरे सिस्टम में परिवर्तन होता है
C
All software dependencies must be managed by a centralised dependency registry सभी सॉफ़्टवेयर निर्भरताएँ एक केंद्रीकृत निर्भरता रजिस्ट्री द्वारा प्रबंधित की जानी चाहिए
D
Inheritance is prohibited; composition required instead विरासत निषिद्ध है; इसके बजाय रचना की आवश्यकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) DIP inverts the traditional dependency flow. Business logic depending on a database interface (abstraction) rather than the database directly means changing the database doesn't break business logic. This decouples layers and makes components independently replaceable.
व्याख्या (हिन्दी) डीआईपी पारंपरिक निर्भरता प्रवाह को उलट देता है। व्यावसायिक तर्क डेटाबेस के बजाय डेटाबेस इंटरफ़ेस (अमूर्त) पर निर्भर करता है, इसका सीधा मतलब है कि डेटाबेस को बदलने से व्यावसायिक तर्क नहीं टूटता है। यह परतों को अलग करता है और घटकों को स्वतंत्र रूप से बदलने योग्य बनाता है।
2186
EN + हिं Easy
GB What is the 'Law of Demeter' and what coupling problem does it address?
IN 'डेमेटर का नियम' क्या है और यह किस युग्मन समस्या का समाधान करता है?
A
Each class must have at most ten methods प्रत्येक कक्षा में अधिकतम दस विधियाँ होनी चाहिए
B
A method should only call methods of its own class, its parameters, objects it creates, or direct components — preventing 'train wreck' chaining that creates hidden long-range coupling एक विधि को केवल अपने स्वयं के वर्ग, उसके मापदंडों, उसके द्वारा बनाई गई वस्तुओं, या प्रत्यक्ष घटकों के तरीकों को कॉल करना चाहिए - 'ट्रेन मलबे' श्रृंखला को रोकना जो छिपी हुई लंबी दूरी की युग्मन बनाता है
C
Global variables are prohibited in object-oriented programs ऑब्जेक्ट-ओरिएंटेड प्रोग्राम में वैश्विक चर निषिद्ध हैं
D
All class attributes must be private with public getters and setters सभी वर्ग विशेषताएँ सार्वजनिक गेटर्स और सेटर्स के साथ निजी होनी चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Train wreck code like customer.getWallet().getCurrency().getSymbol() makes the caller dependent on the entire object graph's internal structure. The Law of Demeter limits coupling by requiring objects to communicate only with immediate neighbours, enforcing encapsulation.
व्याख्या (हिन्दी) ट्रेन व्रेक कोड जैसे customer.getWallet().getCurrency().getSymbol() कॉलर को संपूर्ण ऑब्जेक्ट ग्राफ़ की आंतरिक संरचना पर निर्भर बनाता है। डेमेटर का नियम वस्तुओं को केवल निकटतम पड़ोसियों के साथ संचार करने की आवश्यकता के द्वारा युग्मन को सीमित करता है, जिससे एनकैप्सुलेशन लागू होता है।
2187
EN + हिं Medium
GB What distinguishes a 'layered architecture' from a 'hexagonal (ports and adapters) architecture'?
IN 'स्तरित आर्किटेक्चर' को 'हेक्सागोनल (पोर्ट और एडाप्टर) आर्किटेक्चर' से क्या अलग करता है?
A
Layered is for web applications; hexagonal is for desktop applications लेयर्ड वेब अनुप्रयोगों के लिए है; हेक्सागोनल डेस्कटॉप अनुप्रयोगों के लिए है
B
Layered enforces directional dependency flow (UI→Business→Data); hexagonal puts business logic at the centre with all external concerns as interchangeable adapters connecting through ports स्तरित दिशात्मक निर्भरता प्रवाह को लागू करता है (यूआई→व्यवसाय→डेटा); हेक्सागोनल बंदरगाहों के माध्यम से जुड़ने वाले विनिमेय एडेप्टर के रूप में सभी बाहरी चिंताओं के साथ व्यावसायिक तर्क को केंद्र में रखता है
C
Hexagonal has exactly six layers; layered can have any number हेक्सागोनल में ठीक छह परतें होती हैं; स्तरित में कोई भी संख्या हो सकती है
D
Both are identical; hexagonal is a newer name for layered दोनों एक जैसे हैं; हेक्सागोनल लेयर्ड का नया नाम है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) In layered architecture, business logic depends on the database — making database changes ripple upward. Alistair Cockburn's Hexagonal architecture isolates the domain model at the core; all I/O are adapters the domain doesn't depend on, enabling full testability without infrastructure.
व्याख्या (हिन्दी) स्तरित वास्तुकला में, व्यावसायिक तर्क डेटाबेस पर निर्भर करता है - जिससे डेटाबेस परिवर्तन ऊपर की ओर बढ़ते हैं। एलिस्टेयर कॉकबर्न की हेक्सागोनल वास्तुकला डोमेन मॉडल को मूल रूप से अलग करती है; सभी I/O एडेप्टर हैं जिन पर डोमेन निर्भर नहीं है, जो बुनियादी ढांचे के बिना पूर्ण परीक्षण योग्यता को सक्षम करते हैं।
2188
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.
व्याख्या (हिन्दी) ब्लैक-बॉक्स पुन: उपयोग एक घटक को एक अपारदर्शी इकाई के रूप में मानता है जो केवल उसके इंटरफ़ेस अनुबंध द्वारा परिभाषित होता है (यह क्या करता है, कैसे नहीं)। व्हाइट-बॉक्स के पुन: उपयोग के लिए स्रोत कोड की जांच और अक्सर संशोधन की आवश्यकता होती है - कार्यान्वयन विवरणों के लिए सख्त युग्मन बनाना जो घटक अद्यतन होने पर टूट जाता है।
2189
EN + हिं Medium
GB What does 'Design by Contract' (DbC) entail and how does it differ from defensive programming?
IN 'डिज़ाइन बाय कॉन्ट्रैक्ट' (DbC) में क्या शामिल है और यह रक्षात्मक प्रोग्रामिंग से कैसे भिन्न है?
A
DbC is a legal framework for software licensing डीबीसी सॉफ्टवेयर लाइसेंसिंग के लिए एक कानूनी ढांचा है
B
DbC specifies formal preconditions, postconditions, and invariants — callers meet preconditions; method guarantees postconditions. Defensive programming checks all inputs regardless of responsibility, adding redundancy डीबीसी औपचारिक पूर्वशर्तें, पश्चशर्तें और अपरिवर्तनीयताएं निर्दिष्ट करता है - कॉल करने वाले पूर्वशर्तों को पूरा करते हैं; विधि पोस्टकंडिशन की गारंटी देती है। रक्षात्मक प्रोग्रामिंग जिम्मेदारी की परवाह किए बिना, अतिरेक जोड़ते हुए सभी इनपुट की जाँच करती है
C
DbC contracts are written by lawyers; defensive programming by developers डीबीसी अनुबंध वकीलों द्वारा लिखे जाते हैं; डेवलपर्स द्वारा रक्षात्मक प्रोग्रामिंग
D
Both are equivalent approaches with different terminology दोनों अलग-अलग शब्दावली के साथ समान दृष्टिकोण हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Bertrand Meyer's DbC creates a formal agreement: preconditions (caller's responsibility), postconditions (method's guarantee), invariants (always-true properties). DbC places blame clearly. Defensive programming checks everything everywhere — safer across trust boundaries but adds overhead and ambiguity.
व्याख्या (हिन्दी) बर्ट्रेंड मेयर का डीबीसी एक औपचारिक समझौता बनाता है: पूर्व शर्त (कॉलर की जिम्मेदारी), पोस्टकंडिशन (विधि की गारंटी), अपरिवर्तनीय (हमेशा-सही गुण)। डीबीसी स्पष्ट रूप से दोषारोपण करता है। रक्षात्मक प्रोग्रामिंग हर जगह हर चीज़ की जाँच करती है - विश्वास की सीमाओं के पार सुरक्षित लेकिन ओवरहेड और अस्पष्टता जोड़ती है।
2190
EN + हिं Easy
GB What is the 'God Object' anti-pattern and what refactoring approach addresses it?
IN 'गॉड ऑब्जेक्ट' विरोधी पैटर्न क्या है और कौन सा रिफैक्टरिंग दृष्टिकोण इसे संबोधित करता है?
A
A highly reusable class handling all common utilities; should be kept and extended सभी सामान्य उपयोगिताओं को संभालने वाला एक अत्यधिक पुन: प्रयोज्य वर्ग; रखा जाना चाहिए और बढ़ाया जाना चाहिए
B
A class that knows too much or does too much — violating SRP and creating a hub of dependencies; addressed by extracting classes and redistributing responsibilities according to cohesion एक वर्ग जो बहुत अधिक जानता है या बहुत अधिक करता है - एसआरपी का उल्लंघन करता है और निर्भरता का केंद्र बनाता है; सामंजस्य के अनुसार वर्गों को निकालकर और जिम्मेदारियों को पुनर्वितरित करके संबोधित किया गया
C
The main entry point class of any application किसी भी एप्लिकेशन का मुख्य प्रवेश बिंदु वर्ग
D
Only a problem in procedural programming, not OOP केवल प्रक्रियात्मक प्रोग्रामिंग में एक समस्या है, OOP नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) God Objects accumulate as developers add functionality to an existing central class. Eventually it becomes monolithic and coupled to everything. Refactoring uses Extract Class to pull cohesive groups of responsibilities into dedicated classes.
व्याख्या (हिन्दी) जैसे ही डेवलपर्स मौजूदा केंद्रीय वर्ग में कार्यक्षमता जोड़ते हैं, गॉड ऑब्जेक्ट जमा हो जाते हैं। अंततः यह अखंड हो जाता है और हर चीज़ से जुड़ जाता है। रिफैक्टरिंग जिम्मेदारियों के एकजुट समूहों को समर्पित कक्षाओं में खींचने के लिए एक्सट्रैक्ट क्लास का उपयोग करता है।
2176–2190 of 2726