Topics from 2800-topics.pdf in Q1 Format (2024 Exam Style)
1. Centralized vs. Distributed Version Control Systems (Week 2)
Centralized VCS:
- A version control system where a central server stores the full history of a project. Developers check out files from this single source, and all changes are committed directly to the central repository. This simplifies access control but creates a single point of failure. Examples include Subversion (SVN).
Distributed VCS:
- In this model, every developer has a full copy of the repository, including its history. Changes are committed locally first and later synced with a central server or other peers. It supports offline work and reduces dependency on a central server. Git is a prominent example.
Connection:
Both systems manage code versions but with contrasting architectures. Centralized VCS prioritizes simplicity and centralized control, while Distributed VCS emphasizes resilience and flexibility. The shift from centralized to distributed reflects modern needs for collaboration in decentralized teams.
2. Unit Testing vs. Integration Testing (Weeks 3–4)
Unit Testing:
- Validates individual components (e.g., methods or classes) in isolation. It ensures each unit works as intended before integration. Tools like JUnit automate these tests, enabling rapid feedback and early bug detection.
Integration Testing:
- Checks interactions between integrated modules or systems. It uncovers issues like data flow errors or API mismatches. This testing phase ensures combined units function cohesively in a broader context.
Connection:
Both aim to improve code reliability but operate at different scopes. Unit tests form the foundation, catching low-level errors, while integration tests address higher-level system behavior. Together, they ensure robustness across granular and holistic levels.
3. Aggregation vs. Composition (UML/Week 5)
Aggregation:
- A “has-a” relationship where objects exist independently. For example, a Department aggregates Employee objects, but employees can exist without the department. Represented in UML with a hollow diamond.
Composition:
- A stricter “part-of” relationship where child objects depend on the parent’s lifecycle. For instance, a Car composes Engine objects; destroying the car destroys the engine. UML uses a filled diamond.
Connection:
Both are UML associations but differ in dependency strength. Aggregation implies loose coupling, while composition enforces ownership. Choosing between them impacts system modularity and lifecycle management.
4. Singleton Pattern vs. Factory Pattern (Week 6–7)
Singleton Pattern:
- A creational pattern ensuring only one instance of a class exists. Useful for resources like database connections. Implemented via private constructors and static instance methods.
Factory Pattern:
- Creates objects without specifying their exact class. It centralizes object creation logic, promoting flexibility and decoupling code from concrete implementations.
Connection:
Both manage object creation but with distinct goals. Singleton restricts instantiation to one instance, while Factory abstracts creation logic. They often complement each other—e.g., a factory might return a singleton instance.
5. Waterfall vs. Scrum (Week 9)
Waterfall Model:
- A linear, sequential approach to software development where each phase (requirements, design, implementation, testing) must be completed before the next begins. Suitable for stable, well-defined projects.
Scrum:
- An Agile framework using iterative cycles (sprints) to deliver incremental value. Roles like Product Owner and Scrum Master prioritize flexibility, collaboration, and adapting to changing requirements.
Connection:
Waterfall emphasizes upfront planning, while Scrum embraces adaptability. Both aim to deliver working software but cater to different project environments—predictability vs. responsiveness.
6. Statement Coverage vs. Branch Coverage (Week 10)
Statement Coverage:
- Measures the percentage of code lines executed during testing. Ensures every statement runs at least once but may miss logical branches.
Branch Coverage:
- Checks whether all decision paths (e.g., if/else outcomes) are tested. It provides stricter validation than statement coverage by examining control flow.
Connection:
Both are test coverage metrics targeting code execution. Statement coverage offers a baseline, while branch coverage ensures logical completeness. Combining both reduces undetected errors in complex logic.
7. Code Review vs. Code Inspection (Weeks 3–4)
Code Review:
- A collaborative process where peers examine code for defects, readability, and adherence to standards. Modern reviews are lightweight, often asynchronous (e.g., GitHub pull requests).
Code Inspection:
- A formal, structured review involving documented checklists and roles (e.g., moderator, scribe). It aims to identify defects through rigorous analysis, often in regulated environments.
Connection:
Both improve code quality through peer feedback but differ in formality. Code reviews are agile and iterative, while inspections are comprehensive and systematic. Together, they balance speed and thoroughness.