Software design diagrams are visual tools used during the analysis and design phases of the Software Development Life Cycle (SDLC) to model system structure, behavior, and interactions. These UML diagrams help teams communicate architecture decisions, document requirements, and validate designs before implementation.
Diagrams in This Section (in SDLC order)
Use Case Diagrams — Capture functional requirements from the user's perspective. Map actors to system capabilities with include/extend relationships.
Activity Diagrams — Model workflows and business processes with support for parallel execution, decision branches, and swimlanes.
Sequence Diagrams — Model object interactions over time. Essential for API design, microservices communication, and debugging complex flows.
Class Diagrams — Define the static structure of a system: classes, attributes, methods, and relationships (association, aggregation, composition, inheritance).
New Project Design — Checklist and guidance for kicking off a new software project: scoping, design artifacts, and early architectural decisions.
When to Use Each Diagram
Requirements gathering: Use Case Diagrams
System architecture: Class Diagrams, Sequence Diagrams
Business process modeling: Activity Diagrams
API & integration design: Sequence Diagrams
Object-oriented design: Class Diagrams
2. How the diagrams fit the SDLC
The diagrams answer different questions and are most useful in roughly this order. A new project design checklist fixes the goal, scope and constraints. Use case diagrams then list the actors and what each needs from the system, without saying how. Activity diagrams describe the workflow behind a use case, including decisions, parallel branches and swimlanes for who does each step. Sequence diagrams zoom into one scenario and show which component calls which, in what order, and what comes back, which is where API contracts and timeouts get designed. Class diagrams capture the static structure that results: types, attributes, operations and their relationships.
Behavioural diagrams (use case, activity, sequence) describe what happens; the structural class diagram describes what exists. Most teams do not draw every diagram for every feature. A use case list plus one sequence diagram per non-trivial interaction is often enough, and diagrams-as-code tools such as PlantUML and Mermaid keep them in version control next to the code they describe.