Software Development and Management

SOA can be implemented using CORBA (Common Object Request Broker Architecture) for distributed objects and Web Services for standardized XML-based communication. TEST and DCOMM are not recognized SOA implementation technologies.

SOA guiding principles include service identification/categorization, reuse, granularity, compliance to standards, and monitoring/tracking. Option D captures all these aspects. Individual options A, B, and C are each valid principles but incomplete.

In Lotus Notes, UIDOC (NotesUIDocument) provides the QuerySave event where you can validate field values before the document is saved. DOC is the backend document class without UI events, Values is a property, and Getvalue is not a standard validation method. UIDOC's QuerySave is the correct validation hook.

SE24 is the SAP transaction code used to build and manage classes in the ABAP object navigator. SE25 is for testing, SE37 is for function modules, and SE11 is for data dictionary - none are specifically for building classes.

Cognos DecisionStream is the odd one out because it is an ETL (Extract, Transform, Load) tool used for data integration and transformation, whereas the other three options (MicroStrategy, Actuate, and Siebel Analytics) are all Business Intelligence and reporting platforms used for data visualization, dashboards, and analytics.

Spring primarily supports Setter Injection and Constructor Injection as its main dependency injection mechanisms.

Flow charts, pseudocode, and UML are all design tools used in software development. Bytecode, however, is an intermediate representation of compiled code that executes on a virtual machine (like JVM), not a design aid.

Statically linking libraries embeds all library code directly into the executable at build time, which increases file size significantly compared to dynamic linking where libraries are shared. Every statically linked application contains its own copy of library code, leading to code redundancy across multiple executables. Option B is incorrect - higher-order functions are language concepts unrelated to linking. Option C is wrong - both static and dynamic linking are subject to license terms. Option D describes 'DLL hell' which is a problem with dynamic linking, not static linking.

Extreme Programming (XP) practices include pair programming, test-driven development, refactoring often, continuous integration, and frequent customer communication. 'Debugging is for wimps' contradicts XP's emphasis on testing and quality - it's clearly NOT a tenet of XP.

Comments improve code maintainability by explaining intent, complex logic, and design decisions. Options A (global variables), B (short names), and D (pointer arithmetic) are widely recognized as anti-patterns that hurt reusability and maintainability.

Coined by Fred Brooks in his book, "The Mythical Man-Month" refers to the fallacy that software project progress is perfectly scalable by adding more people, famously summarized as 'Brooks's Law': adding manpower to a late software project makes it later.

Adding new XML Schema types is backward compatible because existing requestors don't reference or need these new types. Changing parameters (B), renaming operations (C), or changing complex data type structures (D) all break existing requestors that depend on the current definitions. WSDL is designed for extensibility through additions.

Request-response pattern involves a client sending a message and receiving a reply, while one-way pattern sends a message without expecting a response. These are the two fundamental message exchange patterns in web services. Option A describes execution modes (async/sync), not patterns. Options C and D are SOAP encoding styles, not message exchange patterns.

Model-Based Testing framework specifically requires creating and maintaining models (often UML diagrams) that represent the system under test. The tests are then generated or derived from these models. This is distinct from modularity-driven frameworks that focus on code structure or context-based frameworks that organize by business context.

BPEL fault handling uses catch blocks within scopes to handle specific fault types (Option B). Multiple catch blocks can handle different fault conditions in the same scope (Option C). Option A is incorrect - BPEL doesn't use 'try-catch' terminology. Option D is incorrect - CatchAll can be used with catch blocks.