Doing Design Diagrams
CMU601: Dissertation - Week 7
Birmingham Newman University
Lecturer: James Williams
Undergraduate Final Year Project
3-hour session • 29 slides • 2 practical tasks
Session Timeline:
- 10 min: Introduction & objectives
- 40 min: Diagram types & purposes
- 45 min: Task 1 - Creating system diagrams
- 15 min: Break/Catch up
- 30 min: Advanced diagramming techniques
- 40 min: Task 2 - Complete project diagrams
- Remaining: Self-directed work
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
Why Diagrams Matter: Good diagrams clarify your thinking, communicate ideas effectively, and demonstrate professional practice in your dissertation.
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
Structure Diagrams
Show system components and relationships
- Class diagrams
- Component diagrams
- ER diagrams
- Architecture diagrams
Behavior Diagrams
Show system dynamics and flow
- Sequence diagrams
- Activity diagrams
- Use case diagrams
- State diagrams
Data Diagrams
Show data structure and relationships
- ER diagrams
- Data flow diagrams
- Database schemas
- Data models
Interface Diagrams
Show user interfaces and navigation
- Wireframes
- Mockups
- Prototypes
- Site maps
UML Class Diagrams
Purpose: Show classes, attributes, methods, and relationships in object-oriented systems
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
Purpose: Model database structure showing entities, attributes, and relationships
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
Purpose: Show how users (actors) interact with the system
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
Purpose: Show how objects interact in a particular sequence over time
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)
Purpose: Show workflow, business processes, or algorithm logic
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
Purpose: Show high-level system components and how they connect
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
Purpose: Plan user interface layout and navigation before building
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
Objective:
Create professional diagrams for your dissertation project
Activity Steps:
- Choose diagramming tool (Lucidchart, Draw.io, or PlantUML)
- Create an account and start new project
- Draw a system architecture diagram showing major components
- Create an ER diagram for your database (if applicable)
- OR create a class diagram for your main classes (OOP projects)
- Draw at least one sequence or activity diagram
- Export diagrams as PNG/PDF
- Save source files for future editing
Requirements:
- Use proper notation (UML standards)
- Clear labels and relationships
- Appropriate level of detail (not too simple, not overwhelming)
- Professional appearance
Time:
45 minutes
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
Figma
Best for: UI/UX wireframes and mockups
Free tier: 3 projects
Miro
Best for: Collaborative brainstorming and flowcharts
Free tier: 3 boards
Microsoft Visio
Best for: Professional diagrams, available through O365
University license may be available
Balsamiq
Best for: Low-fidelity wireframes
30-day free trial
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
Show how your UI adapts to different screen sizes
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)
Purpose: Show how data moves through your system
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
Objective:
Create comprehensive diagram documentation for your dissertation
Activity Steps:
- Review diagrams created in Task 1
- Create wireframes for 3-5 key screens/views
- Draw a site map or navigation diagram
- Create a use case diagram showing user interactions
- Draw at least one more detailed diagram (sequence, activity, or DFD)
- Ensure all diagrams follow consistent styling
- Add captions and explanations to each diagram
- Export all diagrams in high quality
- Organize in a "diagrams" folder in your project
- Create a diagrams.md file listing all diagrams with descriptions
Deliverable:
Complete set of professional diagrams ready for your dissertation report
Time:
40 minutes
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:
- Plan: Create diagrams before coding
- Build: Implement based on diagrams
- Refine: Update diagrams as you learn
- Document: Final diagrams match implementation
Pro Tip: Keep diagram source files in your Git repository under docs/diagrams/
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
Key Takeaways
Remember:
- Different diagram types serve different purposes
- UML for software structure and behavior
- ERD for database design
- Wireframes for UI planning
- Architecture diagrams for system overview
- Choose appropriate tools (Draw.io, Lucidchart, Figma)
- Keep diagrams updated as your project evolves
- Professional diagrams demonstrate systematic development
🎯 This Week's Goals
Complete by end of week:
- System architecture diagram
- Database ERD or class diagram
- 3-5 wireframes for main screens
- At least 2 behavior diagrams (sequence/activity/use case)
- All diagrams organized and documented
- Regular development work continues!
Remember: Diagrams are tools to help YOU think clearly and communicate effectively. They should make your dissertation stronger!
Contact: JWilliams@Staff.newman.ac.uk