# Cheerleading Roster - System Analysis & Design Document
### 1. Introduction
* **Project Name**: CheerleadingRoster
* **Purpose**: To provide users (fans and admins) with an intuitive platform to query, manage, and maintain cheerleader schedules for CPBL games.
(中華職棒啦啦隊班表查詢)
* **Target Users**: General users (fans), admins
---
### 2. System Objectives & Core Features
* Allow admin to manage schedules (CRUD)
* Display each cheerleader's info in each info page (maybe use kendo window or bootstrap?)
* Search/filter by cheerleader, team, date, or location
像上次workshop查書，預設會display全部啦啦隊，有search arg才會更新grid裡面的data (use kendo grid)
* Responsive UI for both desktop and mobile users (響應式設計)
* Role-based access (user vs admin)
* 要能查看站位
* 場地地圖 店家

---

### 3. Technology Stack
This project will be using the following technologies across different layers:
* **Frontend**
* **Backend**
* **Database**
* **Authentication & Security**
* **DevOps / Deployment**
* **Testing**

---

### 4. System Architecture

This system will follow a Layered MVC Architecture. It separates the application into distinct layers:

- **Presentation Layer**: ASP.NET MVC Controllers and Razor Views, handles HTTP requests and UI rendering.
- **Service Layer**: Contains core business logic such as validation, filtering, and decision-making (e.g., checking for cheerleader schedule conflicts).
- **Repository Layer**: Provides access to the database using Entity Framework Core. Responsible for CRUD operations.
- **Domain Model Layer**: Defines data models (e.g., Cheerleader, Schedule, Team) used throughout the system.
- **Utility Layer**: Provides reusable tools (e.g., DateHelper, SecurityHelper).

---

### 5. Database Design
* **Entity Relationship Diagram (ERD)** – [Insert Image or Diagram]
* **Tables**:
* Cheerleader (ID, CName, EName, Image, Age, Description)
* Team (ID, CName, EName, Logo, ShortName)
* Cheerleader_Team (++CheerleaderID++, ++TeamID++, JoinDate, LeaveDate)
* Game (ID, Date, Location, ++HomeTeam(TeamID)++, ++VisitingTeam(TeamID)++)
* Schedule (++GameID++, ++CheerleaderID++) //many to many
* User (ID, Email, Password, Role, CreatedDate)
* FavoriteGame (++UserID++, ++GameID++) //many to many
* FavoriteCheerleader (++UserID++, ++CheerleaderID++) //many to many
* FavoriteTeam (++UserID++, ++TeamID++) //many to many

6. Modules Overview
Module Description
Home Public landing page
Schedule Viewer Query/search schedules
Admin Dashboard Schedule management (CRUD)
Auth Login/logout system
Team Management CRUD for cheerleaders and teams

7. Routing Design
URL Description
/Home/Index Homepage
/Schedule/Query Search schedules
/Admin/ScheduleList Admin schedule table
/Cheerleader/Details/{id} View cheerleader profile

8. Naming Conventions
Variables: camelCase

Classes: PascalCase

Table names: PascalCase (e.g., Cheerleader, Schedule)

Folder structure:

bash
複製
編輯
/Controllers
/Views
/Models
/Services
/DAOs
/wwwroot/css
9. User Flow Diagrams / Use Cases
Fan queries cheerleader schedule by team or date

Admin logs in and manages upcoming schedules

System prevents duplicate schedule assignments

10. Security Considerations
Session-based authentication

Role-based authorization

Input validation (anti-XSS, anti-SQL injection)

.gitignore sensitive files (e.g., connection strings, .env)

11. Testing Strategy
Use MSTest for unit testing (Service Layer)

Manual UI testing for schedule creation

Authentication and authorization tests

Edge case: same cheerleader double-booked

12. Future Enhancements
Add user favorites/bookmarking

Email notification for schedule changes

Export calendar (ICS format)

Mobile app version

AI cheerleader popularity ranking