Software Design
Software Design tests how you turn requirements into a structured, verifiable solution before code exists. Expect questions on architecture styles, modularity, UML notation, design principles, and interface/UI decisions.
Core rules
- Separate functional requirements (what the system does) from non-functional requirements (performance, security, usability, availability). Every design element should trace to a requirement.
- Aim for high cohesion (one module, one focused responsibility) and low coupling (few dependencies between modules). Information hiding exposes interfaces, not internals.
- Know common architectures: layered, MVC, client-server, service-oriented, and microservices. Choose based on change frequency, scaling, team boundaries, and operational cost.
- Read UML precisely: use-case (actors and goals), class (attributes, operations, multiplicity), sequence (time-ordered messages), activity (workflow), state (event-driven states).
- Apply SOLID and DRY where they reduce change impact; do not add patterns without a force.
Worked example
An order system changes discount rules monthly. Extract a DiscountPolicy interface with concrete strategies and inject it into CheckoutService. Keep checkout orchestration in a service layer and persistence behind a repository. This isolates the volatile rule, lowers coupling, and makes unit testing possible. A sequence diagram shows the checkout flow calling the policy before payment.
Traps
Reversing cohesion and coupling; treating non-functional requirements as later tuning; using activity diagrams for object message order; forcing patterns into simple stable code; drawing UML without multiplicities or return messages.