Doing Design Diagrams

Learning Objectives

• Understand different types of design diagrams and their purposes
• Create UML diagrams for software architecture
• Design entity-relationship diagrams (ERDs) for databases
• Develop wireframes and mockups for user interfaces
• Draw system architecture and flow diagrams
• Use professional diagramming tools effectively
• Document design decisions for dissertation reports

The Importance of Design Diagrams

Benefits for Your Dissertation:

• Clarity: Visualize complex systems at a glance
• Planning: Think through architecture before coding
• Communication: Share ideas with supervisors clearly
• Documentation: Professional evidence for your report
• Problem Detection: Spot issues early in design phase
• Assessment: Markers expect professional diagrams

Common Mistakes:

• ❌ Creating diagrams after building the system
• ❌ Using hand-drawn sketches in final report
• ❌ Diagrams that don't match actual implementation
• ❌ Overly complex diagrams that confuse rather than clarify

Types of Design Diagrams

UML Class Diagrams

When to Use:

• Object-oriented programming projects
• Showing system structure
• Planning class hierarchies
• Documenting existing code

Key Components:

┌─────────────────────┐
│      User           │  ← Class Name
├─────────────────────┤
│ - id: int           │  ← Attributes (- = private)
│ - username: string  │
│ - email: string     │
│ + password: string  │  (+ = public)
├─────────────────────┤
│ + login(): bool     │  ← Methods
│ + logout(): void    │
│ + register(): bool  │
└─────────────────────┘

Class Diagram Relationships

Types of Relationships:

• Association: Basic connection (straight line)
• Aggregation: "Has-a" relationship (hollow diamond)
• Composition: "Part-of" relationship (filled diamond)
• Inheritance: "Is-a" relationship (hollow triangle)
• Dependency: Uses temporarily (dashed arrow)

Example:

University ◇───── Department ◇───── Course
(aggregation)    (aggregation)
Student ←──────── Enrollment ──────→ Course
(many-to-many relationship)
Person △
│
┌──────┴──────┐
Student      Staff
(inheritance)

Real Example: E-commerce System

┌─────────────────────┐
│      Customer       │
├─────────────────────┤
│ - customerId: int   │
│ - name: string      │
│ - email: string     │
├─────────────────────┤
│ + placeOrder()      │
│ + viewOrders()      │
└─────────────────────┘
│
│ 1
│
│ *
┌─────────────────────┐
│       Order         │
├─────────────────────┤
│ - orderId: int      │
│ - date: DateTime    │
│ - status: string    │
├─────────────────────┤
│ + calculateTotal()  │
│ + cancelOrder()     │
└─────────────────────┘
│
│ 1
│
│ *
┌─────────────────────┐
│     OrderItem       │
├─────────────────────┤
│ - quantity: int     │
│ - price: decimal    │
├─────────────────────┤
│ + getSubtotal()     │
└─────────────────────┘

Entity-Relationship Diagrams

When to Use:

• Designing database schemas
• Planning data relationships
• Documenting existing databases
• Any project with persistent data storage

Key Components:

• Entities: Tables/Objects (rectangles)
• Attributes: Fields/Properties (ovals)
• Relationships: Connections (diamonds or lines)
• Cardinality: One-to-one, one-to-many, many-to-many
• Primary Keys: Unique identifiers (underlined)
• Foreign Keys: Reference to other tables

ERD Example: Student Management System

┌──────────────────┐
│     Student      │
├──────────────────┤
│ PK student_id    │
│    name          │
│    email         │
│    date_of_birth │
└──────────────────┘
│
│ 1
│
enrolls in│
│
│ N
│
┌──────────────────┐
│   Enrollment     │
├──────────────────┤
│ PK enrollment_id │
│ FK student_id    │
│ FK course_id     │
│    grade         │
│    semester      │
└──────────────────┘
│
│ N
│
│ 1
│
┌──────────────────┐
│      Course      │
├──────────────────┤
│ PK course_id     │
│    course_name   │
│    credits       │
│ FK instructor_id │
└──────────────────┘

PK = Primary Key, FK = Foreign Key

Use Case Diagrams

When to Use:

• Requirements gathering phase
• Showing system functionality from user perspective
• Identifying different user roles
• Planning features and interactions

Components:

• Actors: Users or external systems (stick figures)
• Use Cases: System functions (ovals)
• System Boundary: Scope of your system (box)
• Relationships: Associations, includes, extends

Use Case Example: Online Shopping

Customer                    ┌─────────────────────────┐
│                        │   Shopping System       │
│                        │                         │
├──────────────────────→ │   ○ Browse Products     │
│                        │                         │
├──────────────────────→ │   ○ Add to Cart         │
│                        │                         │
├──────────────────────→ │   ○ Checkout            │
│                        │         │               │
│                        │         ├─<includes>   │
│                        │         │               │
│                        │         ↓               │
│                        │   ○ Process Payment     │
│                        │                         │
├──────────────────────→ │   ○ Track Order         │
│                        │                         │
│                        │   ○ Write Review        │
Admin │                     │         │               │
│                        │         ├─<extends>     │
│                        │         │               │
├──────────────────────→ │   ○ Manage Products     │
│                        │                         │
└──────────────────────→ │   ○ View Reports        │
│                         │
└─────────────────────────┘

Sequence Diagrams

When to Use:

• Documenting API calls
• Showing authentication flows
• Explaining complex interactions
• Debugging system behavior

Example: User Login Sequence

User      Browser     Server      Database
│           │           │            │
├─Enter────→│           │            │
│credentials│           │            │
│           ├─POST────→ │            │
│           │ /login    │            │
│           │           ├─Query────→ │
│           │           │ user data  │
│           │           │←──────────┤
│           │           │  user row  │
│           │           ├─Verify────┤
│           │           │ password   │
│           │←─────────┤            │
│           │  JWT token│            │
│←──────────┤           │            │
│  Success  │           │            │
│           │           │            │

Activity Diagrams (Flowcharts)

When to Use:

• Documenting business logic
• Explaining algorithms
• Showing decision points
• Process workflows

Example: Password Reset Flow

┌──────────────┐
│ User requests│
│ password reset│
└──────┬───────┘
│
┌──────▼───────┐
│ Enter email  │
└──────┬───────┘
│
┌──────▼───────┐
◇  │Email exists? │
└┬─────────┬───┘
Yes │         │ No
│         └──────→ Show generic message
│
┌──────▼────────┐
│Generate token │
└──────┬────────┘
│
┌──────▼────────┐
│ Send email    │
└──────┬────────┘
│
┌──────▼────────┐
│ User clicks   │
│ reset link    │
└──────┬────────┘
│
┌──────▼────────┐
│ Enter new     │
│ password      │
└──────┬────────┘
│
┌──────▼────────┐
│ Update DB     │
└──────┬────────┘
│
┌──────▼────────┐
│  ●  Done      │
└───────────────┘

System Architecture Diagrams

Example: Web Application Architecture

┌─────────────────────────────────────────────────┐
│              CLIENT TIER                        │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
│  │ Browser  │  │  Mobile  │  │  Desktop │     │
│  │   App    │  │   App    │  │   App    │     │
│  └─────┬────┘  └────┬─────┘  └────┬─────┘     │
└────────┼────────────┼─────────────┼────────────┘
│            │             │
HTTPS        HTTPS         HTTPS
│            │             │
┌────────▼────────────▼─────────────▼────────────┐
│          APPLICATION TIER (Backend)             │
│  ┌──────────────────────────────────────┐      │
│  │     Load Balancer (Nginx)            │      │
│  └────────────┬─────────────────────────┘      │
│               │                                 │
│  ┌────────────▼──────────┐  ┌──────────────┐  │
│  │   Web Server (Django) │  │  Web Server  │  │
│  │   - REST API          │  │  (Django)    │  │
│  │   - Business Logic    │  │              │  │
│  └────────────┬──────────┘  └──────┬───────┘  │
└───────────────┼────────────────────┼───────────┘
│                    │
┌───────────────▼────────────────────▼───────────┐
│              DATA TIER                          │
│  ┌──────────────────┐  ┌──────────────────┐   │
│  │   PostgreSQL     │  │   Redis Cache    │   │
│  │   Database       │  │                  │   │
│  └──────────────────┘  └──────────────────┘   │
└─────────────────────────────────────────────────┘

Wireframes: UI Planning

Wireframe Levels:

• Low-Fidelity: Basic boxes and text (sketches)
• Mid-Fidelity: More detail, grayscale
• High-Fidelity: Detailed, interactive prototypes

What to Include:

• Layout structure and grid
• Navigation elements
• Content placement
• Interactive elements (buttons, forms)
• User flow between screens

Don't Include (in wireframes):

• Final colors and branding
• Actual images (use placeholders)
• Real content (use Lorem Ipsum)

Task 1: Design Your System Diagrams

Professional Diagramming Tools

Lucidchart (Recommended for Beginners)

• Pros: Intuitive, templates, collaboration, free for students
• Best For: All diagram types, especially flowcharts and ERDs
• Free Tier: 60 objects per diagram (upgrade with .ac.uk email)

Draw.io / Diagrams.net (Free & Open Source)

• Pros: Completely free, works offline, integrates with Drive
• Best For: All diagram types, technical users
• Download: app.diagrams.net

PlantUML (Code-Based)

• Pros: Version control friendly, generate from text
• Best For: UML diagrams, developers who prefer code
• Learning Curve: Steeper but powerful

Additional Diagramming Options

Recommendation:

Start with Draw.io (free, unlimited) or Lucidchart (easier interface). Use Figma for UI/UX design.

PlantUML: Code-to-Diagram

Why Use PlantUML?

• Generate diagrams from simple text
• Version control friendly (just text files)
• Easy to update and maintain
• Consistent styling automatically

Example: Class Diagram

@startuml
class User {
- id: int
- username: string
- email: string
+ login(): bool
+ logout(): void
}
class Order {
- orderId: int
- date: DateTime
- total: decimal
+ calculateTotal(): decimal
}
User "1" -- "*" Order : places
@enduml

Generates a professional UML diagram automatically!

Design Diagram Best Practices

Do's:

• ✅ Use standard notation (UML, ERD conventions)
• ✅ Keep diagrams focused - one concept per diagram
• ✅ Use clear, descriptive labels
• ✅ Maintain consistent styling
• ✅ Include legends if using custom notation
• ✅ Export in high resolution (PNG 300dpi or vector PDF)
• ✅ Keep source files for future edits

Don'ts:

• ❌ Cramming too much into one diagram
• ❌ Using non-standard symbols without explanation
• ❌ Low-resolution screenshots
• ❌ Hand-drawn diagrams in final report
• ❌ Inconsistent styling across diagrams
• ❌ Outdated diagrams that don't match code

Documenting Your Diagrams

In Your Dissertation Report:

• Caption: Clear, descriptive title
• Figure Number: For cross-referencing
• Context: Explain what the diagram shows
• Explanation: Walk through key elements
• Rationale: Why this design was chosen

Example Caption:

Figure 3.2: System Architecture Diagram
This diagram illustrates the three-tier architecture of
the Student Management System. The client tier consists
of web and mobile interfaces, the application tier
handles business logic via Django REST API, and the
data tier uses PostgreSQL for persistence and Redis
for caching. This architecture was chosen to ensure
scalability and separation of concerns.

Creating Effective Wireframes

Start with Paper Sketches:

• Quick iteration of ideas
• No commitment to specific design
• Easy to throw away and start over
• Focus on layout and flow

Progress to Digital:

• Use wireframing tools (Figma, Balsamiq)
• Maintain grayscale/low-fidelity look
• Focus on functionality, not aesthetics
• Create multiple views/screens
• Show user flow between screens

Essential Wireframe Elements:

• Header/navigation
• Content areas
• Sidebar elements
• Footer
• Interactive elements (buttons, forms)
• Modal/popup patterns

Responsive Design Wireframes

Desktop Wireframe Priorities:

• Multiple columns possible
• Horizontal navigation
• More information density
• Hover states and interactions

Mobile Wireframe Priorities:

• Single column layout
• Hamburger menu or tab bar
• Touch-friendly buttons (minimum 44px)
• Simplified navigation
• Progressive disclosure

Tablet Considerations:

• Hybrid approach
• Often similar to desktop with some adaptations
• Touch targets still important

Site Maps and Navigation Diagrams

Purpose:

Show the information architecture and how users navigate through your system

Example Site Map:

Home
├── About
├── Products
│   ├── Category A
│   │   ├── Product 1
│   │   └── Product 2
│   └── Category B
│       ├── Product 3
│       └── Product 4
├── Services
│   ├── Service 1
│   └── Service 2
├── Blog
│   └── Blog Post
└── Contact
User Account (authenticated)
├── Dashboard
├── Profile
├── Orders
│   └── Order Details
└── Settings

Data Flow Diagrams (DFD)

DFD Elements:

• External Entities: Users, external systems (squares)
• Processes: Data transformations (circles/bubbles)
• Data Stores: Databases, files (parallel lines)
• Data Flows: Movement of data (arrows)

Example: Online Order Processing

[Customer] ──order details──→ (1.0 Process Order)
│
├──store order──→ ==Orders DB==
│
├──payment info──→ (2.0 Process Payment)
│                        │
│                        └──→ [Payment Gateway]
│
└──confirmation──→ (3.0 Send Email)
│
└──email──→ [Customer]

Task 2: Complete Your Diagram Set

Using Diagrams During Development

Diagrams as Living Documents:

• Reference diagrams while coding
• Update diagrams when architecture changes
• Use diagrams to explain code to supervisor
• Share diagrams in GitHub wiki or docs folder

Diagram-Driven Development:

1. Plan: Create diagrams before coding
2. Build: Implement based on diagrams
3. Refine: Update diagrams as you learn
4. Document: Final diagrams match implementation

Avoiding Common Mistakes

❌ Too Complex:

• Diagram shows every single detail
• Unreadable due to clutter
• Fix: Create multiple focused diagrams instead

❌ Too Simple:

• Diagram lacks meaningful information
• Doesn't add value to understanding
• Fix: Add appropriate level of detail

❌ Inconsistent Notation:

• Different styles across diagrams
• Custom notation without explanation
• Fix: Follow UML/standard conventions

❌ Outdated Diagrams:

• Diagrams don't match actual implementation
• Created once, never updated
• Fix: Update diagrams during development