บทที่ 3 การออกแบบและพัฒนาระบบ (System Design and Implementation)

เนื้อหาในบทนี้อธิบายวิธีแปลงความต้องการ (Requirements) จากเอกสารข้อกำหนด (SRS) และเอกสารออกแบบ (SDD) ให้เป็นรูปธรรม สู่แนวทางการวางโครงสร้างสถาปัตยกรรมซอฟต์แวร์ (Architecture Design) ทฤษฎีประยุกต์ของปัญญาประดิษฐ์ ตลอดจนกระบวนการบริหารจัดการข้อมูลให้มีประสิทธิภาพสูงสุด โดยเน้นอธิบายเหตุผลเบื้องหลังว่า "ทำไม" ถึงต้องใช้การออกแบบนี้ มากกว่าแค่บอกว่า "มีอะไรบ้าง" เพื่อเป็นแม่แบบ (Blueprint) ให้บุคลากรทางวิศวกรรมสามารถปรับปรุงระบบ TaijiFlow AI ได้อย่างมีบูรณภาพ

สารบัญ

• 3.1 ภาพรวมความต้องการของระบบ (System Requirements Overview)
• 3.2 สถาปัตยกรรมและระบบนิเวศ (Architecture & Ecosystem)
• 3.3 การออกแบบโมดูลหลัก (Core Module Design)
• 3.4 การคัดเลือกและประมวลผลข้อมูล (AI Training Pipeline)
• 3.5 Heuristics Engine: ระบบวิเคราะห์และประเมินผลท่าทาง (Heuristics Engine)
• 3.6 ระบบสนับสนุนการวิเคราะห์และการจัดการข้อมูล (Analytics & Data Management)
• 3.7 สถาปัตยกรรมการติดตั้งแอปพลิเคชัน (Deployment Architecture)
• 3.8 ความเชื่อมโยงของระบบและการทดสอบ (System Traceability)
• 3.9 บทสรุปประจำบท (Chapter Summary)

---

3.1 ภาพรวมความต้องการของระบบ (System Requirements Overview)

3.1.1 ภาพรวม Use Case (Use Cases Overview)

ระบบ TaijiFlow AI ครอบคลุม Use Case ทั้งหมด 12 Use Cases ซึ่งแบ่งตามบทบาทของผู้ใช้และเส้นทางการใช้งานหลัก 2 เส้นทาง ได้แก่ Trainee (ผู้ฝึก) และ Admin (ผู้ดูแลระบบ) การออกแบบ 12 Use Cases นี้เกิดจากการวิเคราะห์เส้นทางการใช้งานของผู้ฝึก (User Journey) ตั้งแต่เปิดแอปครั้งแรก → ปรับเทียบร่างกาย → ฝึก → ดูผล → ปรับปรุง → ฝึกซ้ำ

ภาพที่ 3.1 Use Case Diagram แสดงความสัมพันธ์ระหว่างผู้ใช้ทั้ง 2 กลุ่มกับ 12 Use Cases

จากแผนภาพข้างต้น ความสัมพันธ์ระหว่างกลุ่มผู้ใช้กับบริบทการใช้งานนำไปสู่การกำหนด Use Case รวม 12 กรณี โดยมีหลักการออกแบบหลักคือการแยกเส้นทางการทำงานของ Trainee (ผู้ฝึก) และ Admin (ผู้ดูแลระบบ) ออกจากกันอย่างชัดเจน เพื่อให้ระบบสิทธิ์และ UI Flow มีความเป็นอิสระต่อกัน ดังสรุปในตารางที่ 3.1

ตารางที่ 3.1 Use Case 12 กรณีของระบบ TaijiFlow AI

ID	Use Case	ผู้ใช้	ฟังก์ชันหลัก
UC-01	Perform Training	Trainee	เริ่มเซสชันฝึก เลือกท่า-ระดับ รับ Realtime Feedback รับเกรดเมื่อจบ
UC-02	Calibrate Body	Trainee	ยืน T-Pose ให้ระบบวัดสัดส่วนแขน-ไหล่-ลำตัว ใช้เป็นฐาน Scale
UC-03	Receive Feedback	Trainee	ดู Visual Skeleton + Highlight จุดผิด + ได้ยิน TTS แนะนำขณะรำ
UC-04	View Score Summary	Trainee	ดูคะแนนรวม เกรด (S–F) และ Radar Chart 6 ทักษะหลังจบ Session
UC-05	Review Replay	Trainee	ดูโครงกระดูกย้อนหลังพร้อม Highlight จุดผิดตามช่วงเวลา
UC-06	Gesture Control	Trainee	ใช้ท่ามือ (Thumbs Up / Fist / Peace) ควบคุม Start/Stop/Mode โดยไม่ใช้คีย์บอร์ด
UC-07	Enter Flow State	Trainee	เปิดโหมดสมาธิ ซ่อน HUD ลดสิ่งรบกวนสายตา เน้นจังหวะการเคลื่อนไหว
UC-08	Submit Feedback Survey	Trainee	ตอบแบบสอบถาม ระบบส่งไป Google Sheets ผ่าน Apps Script
UC-09	View Tutorial	Trainee	เปิดบทเรียนโต้ตอบสอนหลักการมวยและวิธีใช้งานระบบ
UC-10	Manage Configurations	Trainee	ปรับภาษา ธีม Sensitivity ของกฎ มุมมอง และฟังก์ชันแสดงผล
UC-11	Manage Reference Data	Admin	บันทึกท่าต้นแบบ Export JSON + Video เป็น Master Path
UC-12	View Feedback Dashboard	Admin	ดูสถิติคะแนนและผลแบบสอบถามรวมในรูปแบบกราฟ

IMPORTANT

Use Case ทั้งหมดถูกเชื่อมโยงกับ Functional Requirements, Activity Diagrams, Sequence Diagrams, Design Modules และ Test Cases ผ่าน Traceability Record อย่างครบถ้วนตามมาตรฐาน ISO/IEC 29110

3.1.2 ข้อกำหนดเชิงฟังก์ชัน (Functional Requirements)

การจัดกลุ่ม Functional Requirements ออกเป็น 5 กลุ่มตามลักษณะงาน มีจุดประสงค์หลักเพื่อสนับสนุนหลักการ High Cohesion / Low Coupling ในการออกแบบโมดูล โดยเฉพาะกลุ่ม "Core AI & Motion Analysis" ซึ่งถูกแยกออกจาก "Evaluation & Feedback" อย่างชัดเจน เพื่อให้สามารถสลับ Computer Vision Engine ในอนาคต (Phase 2) ได้โดยไม่กระทบกับกลุ่มที่ต้องการข้อมูลผลลัพธ์ (FR-04 ถึง FR-06)

ตารางที่ 3.2 Functional Requirements จัดกลุ่มตาม MoSCoW Priority

ชื่อกลุ่ม	FR	วัตถุประสงค์หลัก	Priority
Core AI & Motion Analysis	FR-01	วิเคราะห์โครงสร้างกระดูกดิจิทัล 33 จุดต่อเนื่องแบบทันที ด้วย Google MediaPipe Pose [15]	Must
	FR-02	สร้าง Body Scale Factor เฉพาะบุคคลจากท่า T-Pose	Must
	FR-03	ประเมินคุณภาพท่ารำเชิงจลนศาสตร์ (Kinematics) ผ่านกฎ Heuristics 9 ข้อ	Must
	FR-10	เครื่องมือบันทึกท่ามาตรฐาน (Master Path) สำหรับผู้เชี่ยวชาญ	Must
Evaluation & Feedback	FR-04	แสดง Skeleton Overlay พร้อมระบุจุดที่ต้องปรับปรุง	Must
	FR-05	สรุปผลด้วยเกรด S–F และ Radar Chart วัด 6 ทักษะหลัก	Must
	FR-06	แจ้งเตือนด้วยเสียงภาษาธรรมชาติ (TTS) โดยไม่ขัดจังหวะ	Must
UX & Interaction	FR-07	สนับสนุนการควบคุมด้วยท่ามือแทนคีย์บอร์ด	Should
	FR-08	โหมดฝึกต่อเนื่อง (Flow State Mode) เพื่อลดภาระการรับรู้และประมวลผล (Cognitive Load)	Could
Record & Review	FR-09	บันทึกและเล่นซ้ำโครงกระดูกย้อนหลัง	Should
System Support	FR-11	บทเรียนแนะนำระบบและหลักการมวยเบื้องต้น	Should
	FR-12	แบบสอบถามและแดชบอร์ดรวบรวมข้อเสนอแนะ	Should

การจัดลำดับ Priority ตามกรอบ MoSCoW ส่งผลต่อแผนการพัฒนาโดยตรง: Iteration 1 มุ่งให้ระบบสามารถทดสอบกับผู้เชี่ยวชาญมวยได้โดยครอบคลุม FR ระดับ "Must" ทั้งหมด ส่วน Iteration 2 เสริมประสบการณ์ผู้ใช้ทั่วไปด้วย FR ระดับ "Should" และ Iteration 3 เพิ่มฟีเจอร์เสริมตามความต้องการขั้น "Could" ในระยะถัดไป

3.1.3 ข้อกำหนดที่ไม่ใช่ฟังก์ชัน (Non-Functional Requirements)

NFR มีน้ำหนักในการกำหนดสถาปัตยกรรมไม่น้อยกว่า FR โดยข้อกำหนด 2 ด้านที่ส่งผลต่อการตัดสินใจออกแบบสูงที่สุดคือ Privacy ซึ่งบังคับให้ระบบต้องประมวลผล AI ทั้งหมดบนเครื่องผู้ใช้ (Client-side Only) และ Maintainability ซึ่งนำไปสู่สถาปัตยกรรม 4-Layer และ Strategy Pattern ในการออกแบบ Heuristics Engine

ตารางที่ 3.3 Non-Functional Requirements และผลต่อการออกแบบ

ด้าน	เกณฑ์ที่กำหนด	ผลกระทบสำคัญต่อการออกแบบ
Performance	FPS ≥ 25 ขณะฝึก, โหลดโมเดล < 5 วินาที, TTS Latency ≤ 200 ms	แยก Layer Presentation/Logic, ใช้ WASM เร่งความเร็ว MediaPipe
Usability	ผู้ใช้ใหม่เริ่มต้นได้เองภายใน 10 นาที, รองรับการควบคุมด้วยท่ามือ	ออกแบบ Tutorial, Calibration, Gesture Control ลด Learning Curve
Privacy	ข้อมูลวิดีโอต้องไม่ออกนอกเครื่องผู้ใช้	ไม่มี Backend API สำหรับวิดีโอ ประมวลผล AI ทุกขั้นตอนบน Client
Security	HTTPS บังคับ, ไม่เก็บข้อมูลส่วนบุคคลใน Phase 1	ใช้ Anonymous Survey, เก็บ Session Data ใน Local Storage
Portability	รองรับ Chrome/Edge 90+ โดยไม่ต้องการ GPU พิเศษ	เพิ่ม WASM/WebGL Fallback และ Lite Mode สำหรับอุปกรณ์พกพา
Maintainability	เพิ่มท่า/กฎใหม่ได้โดยไม่แก้ไข Core Engine	แยก Rules เป็น Class อิสระและใช้ JSON Config แทน Hardcode

ข้อกำหนดทั้ง 6 ด้านข้างต้น ถูกนำไปเป็นหลักเกณฑ์ในการตัดสินใจทางสถาปัตยกรรมและการออกแบบโมดูลในหัวข้อ 3.2 ถึง 3.5 ที่จะนำเสนอต่อจากนี้

---

3.2 สถาปัตยกรรมและระบบนิเวศ (Architecture & Ecosystem)

เนื้อหาในหัวข้อนี้จะอธิบายถึงโครงสร้างการทำงานของโปรเจ็กต์โดยเริ่มตั้งแต่มุมมองระดับมหภาค (Macro-level) ในหัวข้อ 3.2.1 เพื่อแสดงให้เห็นภาพรวมของแพลตฟอร์มทั้ง 4 ซับโดเมน จากนั้นจะเจาะลึกลงมาสู่ระดับซอฟต์แวร์แอปพลิเคชัน (Micro-level) ในหัวข้อ 3.2.2 ที่กล่าวถึงการจัดสถาปัตยกรรม 4 ชั้น (4-Layer Pattern) และจบลงด้วยแผนผังระดับโครงสร้างโฟลเดอร์ในหัวข้อ 3.2.3 เพื่อสะท้อนให้เห็นว่าคอมโพเนนต์และการออกแบบนั้นสอดคล้องกันอย่างแท้จริง

3.2.1 ระบบนิเวศ TaijiFlow Learning Ecosystem

TaijiFlow ถูกออกแบบเป็นแพลตฟอร์มหลายซับโดเมนที่ทำงานร่วมกัน เพื่อให้แต่ละส่วนมีวัตถุประสงค์ที่ชัดเจนและสามารถพัฒนาแยกกันได้

ภาพที่ 3.2 ผังบริบทของระบบ (Context Diagram) แสดงความสัมพันธ์ระหว่าง 4 ซับโดเมนและผู้ใช้

การออกแบบระบบนิเวศ TaijiFlow ดังภาพข้างต้น เน้นรองรับเป้าหมายเชิงสถาปัตยกรรมซอฟต์แวร์ที่ต้องแยกส่วนบริการ ควบคู่ไปกับการตอบรับวัตถุประสงค์การอนุรักษ์มรดกทางวัฒนธรรมและซอฟต์พาวเวอร์ดังที่ได้อภิปรายบริบทไว้ในบทที่ 1 โดยซับโดเมนทั้ง 4 มีการทำงานบูรณาการกัน ดังแสดงในตารางด้านล่าง

ตารางที่ 3.4 ส่วนประกอบ TaijiFlow Ecosystem

ซับโดเมน	URL	บทบาทหลัก	ผู้ใช้หลัก
TaijiFlow AI	ai.taijiflow.org	เว็บแแอปหลัก ฝึกท่าม้วนไหมด้วย Heuristics 9 ข้อ แบบทันที	Trainee, Expert
TaijiFlow Docs	docs.taijiflow.org	ศูนย์รวมเอกสารวิศวกรรม (Project Plan, SRS, SDD, ฯลฯ)	Developer, Admin
TaijiFlow Learn	learn.taijiflow.org	แหล่งเรียนรู้ทฤษฎีมวย ปรัชญาเต๋า ตารางคลาสฝึก	Trainee, Expert
TaijiFlow Research	research.taijiflow.org	พื้นที่จัดเก็บวิทยานิพนธ์และบทความวิจัย	Researcher, Academic

3.2.2 สถาปัตยกรรม 4-Layer ของ TaijiFlow AI (Web App)

หัวใจของการออกแบบคือการแยกหน้าที่ออกเป็น 4 Layer อย่างเข้มงวด เหตุผลหลักคือ

1. ทดสอบได้อิสระ (Independent Testing) — Heuristics Logic อยู่ใน Business Logic Layer ไม่ยุ่งกับ DOM จึงทดสอบด้วย Jest บน Node.js ได้โดยไม่ต้องเปิด Browser
2. เปลี่ยน UI ได้โดยไม่กระทบตรรกะประมวลผล (UI/Logic Decoupling) — การปรับแต่งส่วนติดต่อผู้ใช้ (Visual UI) หรือเพิ่ม Animation จะไม่ส่งผลต่อสูตรคำนวณ Heuristics
3. รองรับการย้ายระบบในอนาคต (Migration Support) — เมื่อต้องการเปลี่ยนจาก MediaPipe Legacy → MediaPipe Tasks API ใน Phase 2 จะแก้ไขเฉพาะองค์ประกอบภายในชั้น External APIs ต่ำสุดเท่านั้น โดยไม่ส่งผลกระทบต่อองค์ประกอบใน Business Logic

เพื่อตอบสนองเป้าหมายทั้ง 3 ประการ โครงสร้างของแอปพลิเคชันจึงถูกจัดระเบียบเป็น 4 ชั้นหลัก (Layers) ซึ่งช่วยแยกการไหลของข้อมูล (Data Flow) และบทบาทหน้าที่ออกจากกันอย่างชัดเจน ดังแสดงในภาพที่ 3.3

ภาพที่ 3.3 — System Architecture Diagram แสดง 4-Layer และ Data Flow

รายละเอียดและโมดูลสำคัญที่บรรจุอยู่ภายในแต่ละ Layer สรุปไว้ในตารางที่ 3.5 ดังนี้

ตารางที่ 3.5 สถาปัตยกรรม 4-Layer: หน้าที่และเหตุผล

Layer	โฟลเดอร์หลัก	โมดูลหลัก	หน้าที่และเหตุผล
1. Presentation	js/ui/, js/display/	UI Manager, Drawing Manager, Audio Manager, Tutorial UI	แยกส่วนติดต่อผู้ใช้ (Interface) และการแสดงผล ให้เป็นอิสระจากตรรกะการประมวลผล
2. Business Logic	js/core/, js/rules/, js/controllers/	HeuristicsEngine, ScoringManager, CalibrationManager	ศูนย์กลางการคำนวณและกฎ Heuristics ต้องทดสอบได้แบบ Unit Test (Node.js/Jest)
3. Data	js/utils/, data/	SessionManager, i18n, ReferencePoseLoader	จัดการทรัพยากร (Resources) และข้อมูล Session ให้พร้อมใช้งานสำหรับ Business Logic
4. External APIs	(เรียกจาก Business Logic)	MediaPipe Pose, Web Speech API, Google Apps Script	ห่อหุ้ม (Encapsulate) การเรียกใช้ Library ภายนอก เพื่อให้ง่ายต่อการเปลี่ยนผ่านเทคโนโลยีในอนาคต

ในขณะที่ภาพที่ 3.3 แสดงเพียงทิศทางการไหลของข้อมูลระหว่างชั้นการทำงาน ภาพที่ 3.4 Component Diagram ต่อไปนี้ จะเจาะลึกให้เห็นถึงความสัมพันธ์และการเรียกใช้งาน (Dependencies) ระหว่างโมดูลย่อยหลักๆ ที่ตั้งอยู่ภายในแต่ละชั้น เพื่อแสดงให้เห็นว่าโมดูลระดับ Presentation ไม่สามารถเข้าถึง Data ได้โดยตรง แต่ต้องผ่านการอนุญาตจาก Business Logic เสมอ ตามหลักการหลวม (Loose Coupling)

ภาพที่ 3.4 ผังองค์ประกอบของระบบ (Component Diagram) แสดงการเชื่อมต่อระหว่าง Component หลัก

3.2.3 โครงสร้างไฟล์โครงการ (Project File Structure)

โครงสร้างไฟล์ถูกออกแบบให้สะท้อนสถาปัตยกรรม 4-Layer และขนาดของโครงการอย่างชัดเจน

TaijiFlow/
├── src/
│   ├── js/
│   │   ├── ui/           # Presentation: UI Managers
│   │   ├── display/      # Presentation: Canvas Drawing
│   │   ├── core/         # Business Logic: Engines, Managers
│   │   ├── rules/        # Business Logic: Heuristics Rules (9 files)
│   │   ├── controllers/  # Business Logic: Flow Controllers
│   │   └── utils/        # Data: Helper Utilities
│   ├── data/             # Data: Master Path JSON + T-Pose Reference
│   ├── css/              # Presentation: Styles
│   ├── index.html            # Main App Entry Point
│   ├── data_collector.html   # Reference Data Collector (UC-11)
│   └── feedback_summary.html # Dashboard (UC-12)

การที่ rules/ เป็นโฟลเดอร์แยกอิสระ (ไม่รวมอยู่ใน core/) มีเหตุผลสำคัญ — เพื่อให้แต่ละ Rule สอดคล้องกับหลักการ Open/Closed Principle โดยเป็นคลาสอิสระที่ สืบทอดคุณสมบัติ (Extend) จาก BaseRule และสามารถเพิ่มกฎใหม่ในระยะถัดไปได้โดยไม่ต้องแก้ไของค์ประกอบหลักของ HeuristicsEngine เพียงแค่ลงทะเบียน (Register) คลาสใหม่เข้าไปยังระบบ

โครงสร้างโฟลเดอร์นี้สะท้อนกระบวนการ บริหารการปรับปรุง (Configuration Management) ตามมาตรฐาน ISO/IEC 29110 ซึ่งกำหนดให้ส่วนประกอบซอฟต์แวร์ต้องสามารถระบุตัวตน (Identify), ควบคุม (Control), และตรวจสอบ (Audit) ได้อย่างเป็นอิสระ การแยก rules/, core/, และ controllers/ ออกจากกัน ช่วยสนับสนุนการทำ เอกราชของซอฟต์แวร์ (Software Independence) และการจัดเก็บประวัติการแก้ไข (Versioning) ที่มีความเฉพาะเจาะจงรายชิ้นส่วน (Granular Versioning) ซึ่งลดความเสี่ยงจากการถดถอยของระบบ (Regression) อย่างมีนัยสำคัญ

---

3.3 การออกแบบโมดูลหลัก (Core Module Design)

ด้วยแนวคิดสถาปัตยกรรมที่แบ่งชั้นข้อมูลไว้อย่างชัดเจน ระบบซอฟต์แวร์ของ TaijiFlow AI จึงถูกนำมาแยกส่วนออกเป็นกลุ่มโมดูลตามหน้าที่การทำงาน (Separation of Concerns) เพื่อให้ผู้พัฒนาสามารถดูแลรักษาง่าย โดยโครงสร้างโมดูลหลักแบ่งออกเป็น 3 กลุ่มใหญ่ ได้แก่ Core Engines (หน่วยประมวลผลกฎอัจฉริยะ), Controllers (ผู้ควบคุมทิศทางการรัน), และ UI & Display (องค์ประกอบประกอบการนำเสนอ)

3.3.1 Core Engines — หัวใจของระบบ

เพื่อแสดงให้เห็นภาพรวมกลไกการทำงานและความสัมพันธ์ (Coupling/Dependencies) ระหว่างโมดูลประมวลผลเชิงลึก สามารถพิจารณาได้จาก Class Diagram ดังภาพที่ 3.5

ภาพที่ 3.5 ผังคลาสของระบบ (Class Diagram) แสดงความสัมพันธ์ระหว่างองค์ประกอบของกลุ่ม Core Engines

จาก Class Diagram สามารถแยกแยะความรับผิดชอบและบทบาทของโมดูลย่อยแต่ละตัวในกลุ่ม Core Engines ซึ่งเปรียบเสมือนขุมพลังขับเคลื่อนการประมวลผลแบบเรียลไทม์ ดังรายละเอียดในตารางที่ 3.6

ตารางที่ 3.6 Core Engine Modules

CI-ID	ชื่อ Module	หน้าที่หลัก	Use Case
CD-CORE-01	HeuristicsEngine	ประสาน Rule 9 ข้อ, รับ Landmarks → ส่ง Feedback และควบคุมการลำดับความสำคัญ (Priority Selection)	UC-01, 03
CD-CORE-02	ScoringManager	คำนวณคะแนนตามค่าน้ำหนัก (Weighting), ประเมินเกรด S–F และเตรียมข้อมูล Radar Chart	UC-04
CD-CORE-03	CalibrationManager	ประมวลผล T-Pose → สร้าง Body Scale Factor สำหรับปรับค่าขีดจำกัด (Threshold) เฉพาะบุคคล	UC-02
CD-CORE-04	SessionManager	บันทึกสถิติการฝึก (Session Statistics), Timeline และคะแนนรายกฎ (Rule Scores) สะสม	UC-01, 04, 05
CD-CORE-05	GestureManager	ประมวลผล MediaPipe Gesture → แปลงเป็นคำสั่งควบคุมระบบ (System Command)	UC-06
CD-CORE-06	ReplayManager	บริหารจัดการ Skeleton Buffer ระหว่างการฝึก เพื่อใช้ในการแสดงผลย้อนหลัง (Replay)	UC-05

HeuristicsEngine เป็นโมดูลที่ซับซ้อนที่สุดในระบบ ทำงานเป็น ตัวประสานงานหลัก (Orchestrator) ที่รับ Landmarks 33 จุดจาก MediaPipe ทุกเฟรม (Frame) แล้วดำเนินการดังนี้:

1. ส่งข้อมูลให้ Rule แต่ละตัวประมวลผลแยกกันผ่าน การประเมินผลแบบขนาน (Parallel Evaluation)
2. รวบรวมผลลัพธ์จาก Rule ทั้ง 9 ตัว เพื่อประเมินความถูกต้องในภาพรวม
3. คัดเลือกการแจ้งเตือน (Top-Priority Feedback) ที่สำคัญที่สุดในขณะนั้นตามลำดับความสำคัญ (Priority Logic)
4. ส่งข้อมูลผลลัพธ์ไปยัง Audio Manager (TTS) และ Drawing Manager (Visual) เพื่อนำเสนอต่อผู้ใช้

3.3.2 Controllers — จัดการ Flow การฝึก

Controllers ทำหน้าที่เชื่อม Business Logic กับ Presentation Layer โดยรับ Event จาก UI และแปลงเป็น Commands สำหรับ Engines

ตารางที่ 3.7 Controllers

CI-ID	ชื่อ Module	หน้าที่	Use Case
CD-CTRL-01	TrainingFlowController	ควบคุมวงจรชีวิตการฝึก (Start/Stop Session) และโหลด Pose Configuration	UC-01
CD-CTRL-02	ScriptController	ประสานงานลำดับขั้นตอน (Orchestration) ภายในเซสชันการฝึก	UC-01
CD-CTRL-03	TutorialManager	บริหารจัดการการแสดงผลบทเรียนโต้ตอบ (Interactive Tutorial)	UC-09
CD-CTRL-04	FlowStateController	ควบคุมการสลับโหมดการฝึกต่อเนื่อง (Flow State Mode)	UC-07
CD-CTRL-05	ReplayController	ควบคุมกลไกการเล่นย้อนหลัง (Play/Pause/Seek/Speed) สำหรับการวิเคราะห์	UC-05

3.3.3 UI & Display Components

Presentation Layer แบ่งออกเป็นสองกลุ่มการทำงานหลักที่มีสภาพแวดล้อมทางสถาปัตยกรรมต่างกันอย่างสิ้นเชิง ได้แก่ กลุ่มที่ทำหน้าที่แสดงผลหน้าจอมาตรฐานแบบวัตถุ (DOM) และกลุ่มทำงานเรนเดอร์ระดับพิกเซลผ่านพื้นผ้าใบ (Canvas/WebGL)

กลุ่ม UI (จัดการ DOM): โมดูลในกลุ่มนี้รับผิดชอบจัดการโครงสร้างอินเทอร์เฟซมาตรฐาน เช่น หน้าต่างตั้งค่า ตัวจัดการภาษา หรือ แผงข้อความ โดยมีรายละเอียดโมดูลดังเปิดเผยในตารางที่ 3.8

ตารางที่ 3.8 UI Components

CI-ID	Module	หน้าที่
CD-UI-01	UIManager	จัดการส่วนประสานงานหลัก (Main UI), การสลับพาเนล และควบคุมสถานะแอปพลิเคชัน
CD-UI-02	HeaderManager	แสดงแถบเครื่องมือ (Toolbar), สถานะการประมวลผล และส่วนการปรับแต่งภาษา
CD-UI-03	Translator	ประมวลผลชุดข้อความหลายภาษา (i18n), สลับภาษา และส่งข้อมูลเสียงไปยัง TTS
CD-UI-04	ThemeManager	บริหารจัดการชุดสีและตัวแปร CSS สำหรับโหมด Light/Dark เพื่อความสบายตา
CD-UI-05	RulesConfigManager	ส่วนติดต่อผู้ใช้สำหรับการปรับแต่งค่าขีดจำกัด (Threshold) ของแต่ละกฎ Heuristic
CD-UI-06	RulesPopupManager	พาเนลเสริมสำหรับแสดงคำอธิบายและรูปภาพประกอบสำหรับแต่ละกฎ Heuristic
CD-UI-07	SurveyManager	อินเทอร์เฟซจัดเก็บข้อมูลป้อนกลับแบบนิรนาม (Anonymous Feedback) เพื่อส่งไปยัง Google Apps Script
CD-UI-08	DashboardManager	ประมวลผลและแสดงภาพรวมข้อมูลสถิติหรือข้อเสนอแนะในรูปแบบกระดานสรุปผล (Dashboard)

กลุ่ม Display (จัดการ Canvas/WebGL):

ในขณะที่โมดูลกลุ่มแสดงผลกราฟิก (Display) ต้องอาศัยเครื่องมือการวาดภาพระดับสูง (Drawing Manager) ควบคู่กับการรวบรวมเส้นทางเรนเดอร์บนหน่วยความจำภาพ (WebGL) อย่างต่อเนื่องเป็นหลัก การแยกกลุ่ม Display ออกจาก UI ปกติมีจุดประสงค์หลักเพื่อ เพิ่มประสิทธิภาพการเรนเดอร์ (Rendering Performance) โดยการใช้ GPU เร่งความเร็วในส่วนของ Canvas ในขณะที่ UI ปกติยังคงใช้ DOM เพื่อความสะดวกในการเข้าถึง (Accessibility) โดยมีรายละเอียดฟังก์ชันในตารางที่ 3.9

ตารางที่ 3.9 Display Components

CI-ID	Module	หน้าที่
CD-UI-09	DrawingManager	วาดรูปลักษณ์ Skeleton ลงบนแคนวาส ควบคู่กับการแต้มจุดผิดสังเกต (Highlight)
CD-UI-10	AudioManager	บริหารคิวเสียงผู้ฝึกสอน TTS และกรองมิให้เกิดการแจ้งเตือนเสียงทับซ้อนกัน
CD-UI-11	PathVisualizer	เรนเดอร์ลากเส้นเชื่อมสาย Master Path เพื่อเทียบทิศทางสัมพัทธ์กับ User Path
CD-UI-12	RadarChartManager	ประกอบผลคำนวณกราฟประเมินพฤติกรรมรูปแมงมุมครอบคลุมเรดาร์ 6 ทักษะ
CD-UI-13	LightingManager	คำนวณความสว่างจากเฟรมภาพกล้อง (Luminance) และเตือนจุดบอดแสง

---

3.4 การคัดเลือกและประมวลผลข้อมูล (AI Training Pipeline)

เนื้อหาในหมวดนี้มุ่งเน้นส่องแสง (Highlight) เส้นชีวิตของข้อมูล (Data Lifecycle) ภายในแพลตฟอร์ม TaijiFlow AI ตั้งแต่กระบวนการควบคุมสถาปัตยกรรม (3.4.1) กลไกการไหลของข้อมูลและลำดับเหตุการณ์ (3.4.2) การปรับเทียบสัดส่วนร่างกาย (3.4.3) ตลอดจนระบบตรรกะการลำดับข้อมูลป้อนกลับแบบพหุรูปแบบ (3.4.4) เพื่อแสดงหลักฐานการทำงานที่มีประสิทธิภาพของระบบโครงสร้างแบบ Real-time Processing

3.4.1 การออกแบบสถาปัตยกรรมตัวควบคุม (Controller & Orchestration Logic)

เพื่อให้ระบบที่มีโมดูลจำนวนมากทำงานประสานกันได้อย่างราบรื่นและลดความซับซ้อน (Coupling) TaijiFlow AI จึงใช้รูปแบบ Facade Pattern โดยมีไฟล์ script.js ทำหน้าที่เป็น Main Orchestrator (ตัวประสานงานหลัก) ดังนี้

1. หน้าที่: ทำหน้าที่เป็นอินเทอร์เฟซเดียวที่ติดต่อกับทุกโมดูล (Heuristics, Scoring, UI) เพื่อควบคุมวงจรชีวิตการฝึก (Training Lifecycle)
2. การทำงาน: เมื่อผู้ใช้สั่ง "เริ่มฝึก" script.js จะทำหน้าที่เป็น ตัวประสานงานระดับแแอปพลิเคชัน (Application Orchestrator) โดยการส่งสัญญาณไปยัง CameraManager เพื่อเปิดกล้อง, CalibrationManager เพื่อขอสัดส่วนร่างกาย, และ PoseProcessor เพื่อเริ่มการไหลของข้อมูล
3. ประโยชน์: ช่วยให้การแก้ไขที่ระดับโมดูลภายใน (Sub-systems) ไม่ส่งผลกระทบต่อโครงสร้างการทำงานหลัก ทำให้ระบบมีความเสถียรและบำรุงรักษาง่าย

3.4.2 กลไกการไหลของข้อมูลและลำดับเหตุการณ์ (Data Pipeline and Sequence Flow)

เพื่อให้เข้าใจทั้งกลไกเบื้องหลังและปฏิสัมพันธ์เบื้องหน้า ข้อมูลจากกล้องเว็บแคมจะถูกประมวลผลผ่านกระบวนการ Pipeline ที่เน้นความเร็วสูงและขจัดคอขวดของระบบเพื่อให้ได้ภาพที่ลื่นไหลระดับ 30 เฟรมต่อวินาที (FPS) ดังแสดงการเดินทางของข้อมูลในภาพที่ 3.6

ภาพที่ 3.6 ผังการไหลของข้อมูล AI Pipeline (Data Flow Diagram) แสดงการไหลของข้อมูลในระบบจาก Input สู่ Feedback

ในขณะเดียวกัน เมื่อมองจากมุมมองของผู้ใช้งาน ปฏิสัมพันธ์ดังกล่าวจะเกิดเป็นกระบวนทัศน์ลำดับเหตุการณ์ (Sequence of Events) อย่างเป็นขั้นตอน โดยครอบคลุมตั้งแต่ผู้ใช้เข้าสู่แอปพลิเคชัน การอนุญาตให้ใช้งานกล้อง จนถึงการจบเซสชันฝึกซ้อม ซึ่งสอดคล้องกับกระแสข้อมูลข้างต้น ดังอธิบายด้วย Sequence Diagram ในภาพที่ 3.7

ภาพที่ 3.7 ผังลำดับเหตุการณ์การฝึกซ้อม (Sequence Diagram: UC-01) แสดง Training Session Flow (UC-01) และสเตปการทำงานเบื้องหลัง

ผลลัพธ์จากกระบวนทัศน์ลำดับเหตุการณ์ดังกล่าว นำเสนอเป็นพื้นที่สร้างปฏิสัมพันธ์ระหว่างผู้เรียนกับปัญญาประดิษฐ์ (User Interface) ณ ขณะเปิดใช้งานจริง โดยผู้ฝึกจะเห็นร่างโครงกระดูกและกล่องสถานะประเมินผลอย่างต่อเนื่อง ดังแสดงในภาพที่ 3.8

ภาพที่ 3.8 หน้าจอหลักขณะฝึกซ้อมแบบทันทีในโหมดสว่าง (Light Mode) สำหรับเป็นปลายทางเชื่อมสัญญาณการเตือน

หมายเหตุ: สำหรับรายละเอียดของการออกแบบหน้าจอส่วนย่อย (Sub-UI) เช่น หน้าต่างแจ้งเตือน (Modal), หน้าจอตั้งค่า (Settings), และหน้าต่างข้อผิดพลาด (Error Alerts) สามารถดูรายละเอียดเพิ่มเติมได้ในภาคผนวก ง. (คู่มือการใช้งานและส่วนติดต่อผู้ใช้)

3.4.3 การปรับเทียบสัดส่วนร่างกาย (Body Calibration & Scaling)

เนื่องจากผู้ใช้แต่ละรายมีสรีระ (Anthropometry) ที่แตกต่างกัน เช่น ความยาวของช่วงแขนเมื่อเทียบกับลำตัว ระบบจึงจำเป็นต้องสร้าง Individualized Threshold ผ่านกระบวนการ Calibration (UC-02) ก่อนเริ่มการฝึก ดังนี้

1. กระบวนการ: ผู้ใช้ยืนในท่า T-Pose เพื่อให้ระบบทำ การสกัดตัวแปรลักษณะเฉพาะ (Feature Extraction) โดยวัดระยะห่างระหว่างจุดอ้างอิงหลัก (เช่น ระยะ Shoulder-to-Hip และ Arm Span)
2. การคำนวณ: ระบบจะคำนวณแแและสร้าง Body Scale Factor ซึ่งเป็นค่าคงที่เฉพาะบุคคลเพื่อใช้ใน การทำให้เป็นบรรทัดฐาน (Normalization) ของพิกัด Landmarks ทุกจุดให้เป็นสัดส่วนเดียวกัน
3. ประโยชน์: ช่วยแก้ปัญหาความหลากหลายของสรีระรายบุคคล (Individual Variation) และลดอัตราผลบวกปลอม (False Positives) ในกรณีที่ผู้ฝึกมีสรีระที่ต่างจากมาตรฐาน (เช่น แขนสั้นหรือยาวกว่าปกติ) ทำให้เกณฑ์การตัดสิน (Heuristic Thresholds) มีความยุติธรรมและแม่นยำรายบุคคล

กระบวนการให้คะแนนและการอนุมานสัดส่วนเหล่านี้จะแสดงหน้าต่างยืนยันบนภาพวิดีโอเพื่อความมั่นใจแบบหน้าจอเดี่ยว (Single-page App) ดังตัวอย่างหน้าจอในภาพที่ 3.9

ภาพที่ 3.9 หน้าจอการปรับเทียบสัดส่วนร่างกาย (Calibration UI) แสดงการวัดระยะ Body Scale

3.4.4 ระบบการสอนและตรรกะเชิงจลนศาสตร์ (Multi-modal Feedback & Kinematics Priority Logic)

TaijiFlow AI ทำหน้าที่เป็น "Virtual Coach" ที่สื่อสารกับผู้ใช้ผ่าน 3 ช่องทางหลัก (Visual Skeleton, Bilingual Text, และ Audio TTS) โดยมีหัวใจสำคัญอยู่ที่ ตรรกะเชิงจลนศาสตร์ (Kinematics Priority Logic) เพื่อป้องกันภาวะข้อมูลล้น (Information Overload) ดังนี้

1. กลไกการคัดเลือก (Priority Selection)

ในสถานการณ์ที่ผู้ฝึกทำผิดกฎหลายข้อพร้อมกัน ระบบจะไม่แจ้งเตือนทุกข้อ แต่จะเลือกข้อที่ สำคัญที่สุดเพียงข้อเดียว ตามลำดับชั้นความสำคัญ ดังนี้

• ลำดับที่ 1 (Safety/Fundamental): เน้นความนิ่งของแกนกลาง (R-05) และการทรงตัว (R-08) เพราะเป็นรากฐานของความปลอดภัย
• ลำดับที่ 2 (Core Mechanics): เน้นการใช้สะโพก/เอว (R-04) และการจมข้อศอก (R-03) ซึ่งเป็นแก่นของมวยไท้เก๊ก
• ลำดับที่ 3 (Refinement): เน้นความลื่นไหล (R-06) และความต่อเนื่อง (R-07) สำหรับผู้ฝึกระดับกลางขึ้นไป

2. ช่องทางการสื่อสาร (Multi-modal Channels)

• Visual Feedback: เน้นสี (Color-coding) และเอฟเฟกต์ (Pulse/Glow) บนโครงกระดูกเพื่อให้รู้จุดที่ต้องแก้ไขทันที
• Bilingual Guidance: ระบบใช้ชุดข้อมูล I18N (Internationalization) ในรูปแบบ JSON เพื่อเก็บข้อความสั่งการและ Feedback ใน 2 ภาษา (ไทย/อังกฤษ) และส่งไปประมวลผลเสียงผ่าน Web Speech API
• Adaptive Theme & Visibility: ระบบรองรับการสลับรูปแบบการแสดงผล (Light/Dark Theme) เพื่อเพิ่มความสบายตาและการเข้าถึงข้อมูลในมุมมองแบบหลากหลาย
• Intelligent Cooldown: ระบบเสียง TTS จะมีช่วงพัก 5 วินาทีก่อนแจ้งเตือนซ้ำ เพื่อให้ผู้ฝึกมีเวลาปรับตัว

ตรรกะดังกล่าวถูกออกแบบให้อำนวยความสะดวกสำหรับผู้ด้อยโอกาสและสอดรับกับสภาพแสงแวดล้อมดังแสดงความแตกต่างในภาพที่ 3.10

ภาพที่ 3.10 รูปแบบการแสดงผลข้อมูลป้อนกลับแบบ 2 ภาษาและการสลับโหมดการแสดงผล (Accessibility UI)

3.4.5 การคำนวณคะแนนและการวิเคราะห์โครงสร้างข้อมูลเชิงปริมาณ (Scoring & Quantitative Analysis)

ตลอดเซสชันการฝึก โมดูล ScoringManager ทำหน้าที่เก็บสะสมผลพฤติกรรมภาพรวมนับสัดส่วนเฟรมที่ผ่านเกณฑ์ เทียบเฟรมทั้งหมดเพื่อวัดสถานภาพสะสมรายทักษะ ครอบคลุมพฤติกรรมหลากมิติ 6 ด้านที่เรียกว่า ดัชนีชี้วัดทักษะ (KPIs) ได้แก่ รูปทรง, ความต่อเนื่อง, ความลื่นไหล, ความมั่นคง, ความสมดุลและจังหวะ (Sync/Coordination) จากนั้นนำคะแนนดิบทั้งหมดมาถ่วงน้ำหนัก (Weighting) ตามความสำคัญปรรับค่าออกมาเป็นระบบเกรดและค่าพลังเชิงสถิติ

การประเมินผลลักษณะนี้เปลี่ยนพฤติกรรมฝึกซ้อมเชิงนามธรรมกลายเป็นโครงสร้างปริมาณเชิงเลขชัดเจน นำเสนอตัวอย่างเป็นกราฟวิเคราะห์คะแนนแบบใยแมงมุม (Radar Chart) เพื่อสรุปดัชนีชี้วัดทักษะ (KPIs) ทันทีหลังจบการฝึก ดังภาพตัวอย่างที่ 3.14

ภาพที่ 3.11 หน้าจอสรุปผลคะแนนและความแม่นยำรายด้านในรูปแบบ Radar Chart สำหรับสรุปท้ายคาบหลัก

---

3.5 Heuristics Engine: ระบบวิเคราะห์และประเมินผลท่าทาง

Heuristics Engine คือหัวใจสำคัญของโครงการ TaijiFlow AI ทำหน้าที่เป็น "Virtual Coach" ที่นำความรู้ความเชี่ยวชาญจากตำรามวยมาแปลงเป็นตรรกะคอมพิวเตอร์ เนื้อหาในหัวข้อนี้จะอธิบายถึงกระบวนการทำงานแบบครบวงจร เริ่มจากรากฐานทางวิชาการที่อ้างอิงจากคัมภีร์มวย (3.5.1) กลยุทธ์การประเมินแบบไต่ระดับ (3.5.2) การออกแบบสถาปัตยกรรมเชิงวิศวกรรมซอฟต์แวร์ (3.5.3) ตลอดจนรายละเอียดวิธีการคำนวณทางคณิตศาสตร์ในแต่ละข้อ (3.5.4) และวงจรการคัดกรองข้อมูลเพื่อส่งผลลัพธ์แบบทันที (3.5.5)

3.5.1 รากฐานทางวิชาการ: หลักการมวยไท้เก๊กและกฎ Heuristics

TaijiFlow AI ได้คัดเลือกหลักการสำคัญจาก "10 หลักการของ Yang Chengfu" และ "ทฤษฎีการม้วนไหม" มาสร้างเป็นกฎ Heuristics ทั้ง 9 ข้อ โดยกฎ Heuristics 9 ข้อ ใน TaijiFlow AI ถูกออกแบบมาจาก

1. หลักการดั้งเดิม จากตำราไท้เก๊กที่เป็นที่ยอมรับ
2. ความเหมาะสมกับเทคโนโลยี ที่ใช้ (MediaPipe Pose)
3. ความเป็นไปได้ในการวัด จากมุมกล้องหน้าตรง
4. ระดับความยาก ที่เหมาะกับผู้เริ่มต้นจนถึงขั้นสูง

หมวดหมู่กฎ (Rule Categories)

Heuristics Rules ถูกออกแบบตามคัมภีร์มวยไท้เก๊ก (Taiji Principles) โดยแยกหมวดหมู่เพื่อการประมวลผลและการตั้งค่า (Configuration) ที่ง่ายขึ้นในโค้ด rules/

1. หมวดความเที่ยงตรงเชิงเรขาคณิต (Geometric Accuracy): โฟกัสไปที่วิถีการเคลื่อนที่ (Trajectory) ของข้อมือที่วาดขึ้นในอากาศ เพื่อตรวจสอบความสมมาตรและรูปทรงวงกลมตามมาตรฐาน
2. หมวดความมั่นคงเชิงจลนศาสตร์ (Kinematics Stability & Posture): ใช้วิชาเรขาคณิตสามมิติ ตรวจสอบมุมองศาของข้อต่อ (Joint Angles) ว่าสอดคล้องกับหลักสรีระศาสตร์ของไท้เก๊กหรือไม่ เช่น การกดศอก หรือการบิดแกนเอว
3. หมวดเชิงพลวัตและคุณภาพการเคลื่อนไหว (Dynamic & Movement Quality): ใช้วิชาฟิสิกส์ประยุกต์ (ความเร็ว ความเร่ง) เพื่อวิเคราะห์ความลื่นไหลและจังหวะที่สม่ำเสมอ เพื่อหาจุดบกพร่องเรื่องจังหวะสะดุดหรือการกระชากแรง (Jerk)
4. หมวดศูนย์ถ่วงและการกระจายน้ำหนัก (COG & Weight Distribution): สำหรับการฝึกระดับสูง จะตรวจสอบจุดศูนย์ถ่วงของร่างกาย (Center of Gravity) ควบคู่กับความสัมพันธ์ของการเคลื่อนไหวส่วนบนและส่วนล่าง

ภาพที่ 3.12 รายละเอียดหมวดหมู่อัลกอริทึม Heuristics 4 หมวดหมู่

ตารางที่ 3.10 แหล่งอ้างอิงหลักการมวยไท้เก๊กสำหรับการออกแบบเกณฑ์ Heuristics

แหล่งอ้างอิง	ผู้แต่ง / สำนัก	ปี / ยุคสมัย	ประเภท	บทบาทต่อระบบ
Taiji Chuan Lun (王宗岳) [20]	Wang Zongyue	~1800s	ตำราโบราณ	กำหนดปรัชญาพื้นฐาน (Stability, Flow)
Illustrated Chen Taijiquan [21]	Chen Xin (陈鑫)	1919	ตำราเฉินซิน	รายละเอียดท่าม้วนไหม (Rule R-01, R-02)
Yang Chengfu 10 Essentials [22]	Yang Chengfu	~1930s	คำสอนพื้นฐาน	กฎการผ่อนคลายและแกนกลาง (R-03, R-04, R-05)
Silk Reeling Theory [23]	Chen Family	-	ทฤษฎีเฉพาะทาง	กำหนดตรรกะการต่อเนื่องและประสานงาน (R-06, R-07, R-09)

เพื่อให้น้ำหนักทางวิชาการและเป็นไปตามหลักวิศวกรรมความรู้ (Knowledge Engineering) การออกแบบกฎ Heuristics 9 ข้อ สำหรับท่าม้วนไหม จึงได้รับการถอดรหัสและอ้างอิงแหล่งที่มาอย่างชัดเจน (Traceability) ดังตารางที่ 3.11

ตารางที่ 3.11 การเปรียบเทียบกฎ Heuristics 9 ข้อกับหลักการมวยไท้เก๊ก

Rule ID	หลักการไท้เก๊ก	ความหมาย	คำอธิบาย	ชื่อกฎ	ความสำคัญ
R-01	圆转如意 (หยวนจ้วนหรูอี้) [21]	วงกลมนุ่มนวลตามต้นแบบ	เส้นทางม้วนไหมเป็นวงกลมหรือสมมาตร	Path Shape	⭐⭐⭐
R-02	旋腕转臂 (ซวนว่านจ้วนปี้) [21]	หมุนข้อมือหงาย-คว่ำถูกต้อง	การหมุนฝ่ามือต้องสอดคล้องกับทิศทางขึ้น	Arm Rotation	⭐⭐⭐
R-03	沉肩坠肘 (ชิ่นเจียนจุ้ยโจ่ว) [22]	จมไหล่ ศอกไม่ยกสูง	ศอกต้องอยู่ต่ำกว่าไหล่และผ่อนคลาย	Elbow Sinking	⭐⭐⭐
R-04	腰為主宰 (เยาเหวยจู่ไจ่) [22]	เอวเป็นแกน เอวนำมือตาม	การเคลื่อนไหวต้องเริ่มจากเอว/สะโพก	Waist Initiation	⭐⭐⭐
R-05	虚领顶劲 (ซวี่หลิงติ่งจิ้น) [22]	ศีรษะตั้งตรงนิ่ง	ศีรษะตั้งตรงและมั่นคง ไม่ก้มเงย	Vertical Stability	⭐⭐
R-06	如抽丝 (รู๊โชวสือ) [23]	นุ่มนวลราวดึงไหม	ความเร็วสม่ำเสมอเหมือนการดึงไหม	Smoothness	⭐⭐
R-07	绵绵不断 (เหมียนเหมียนปู้ต้วน) [23]	ต่อเนื่องไม่ขาดตอน	เคลื่อนไหวต่อเนื่อง ไม่มีหยุดนิ่ง	Continuity	⭐⭐
R-08	分虚实 (เฟินซวีสือ) [20, 22]	ถ่ายน้ำหนักสมดุล	แยกความว่าง/เต็ม และรักษาศูนย์ถ่วง	Weight Shift	⭐⭐
R-09	上下相随 (ซ่างเซี่ยเซียงซุย) [23]	บนล่างสัมพันธ์กัน	ร่างกายส่วนบนและล่างเคลื่อนไหวสัมพันธ์กัน	Coordination	⭐⭐⭐

การเชื่อมโยงนี้พิสูจน์ว่า TaijiFlow AI ไม่ได้เพียงแค่ตรวจจับการเคลื่อนไหวร่างกายทั่วไป แต่เป็นการออกแบบที่อยู่บนฐานรากของ องค์ความรู้ดั้งเดิม ร่วมกับ คอมพิวเตอร์วิทัศน์สมัยใหม่

3.5.2 กลยุทธ์การฝึกสอนแบบปรับตัวตามระดับทักษะ (Adaptive Training Strategy)

เนื่องจากผู้ฝึกแต่ละกลุ่มมีพื้นฐานที่แตกต่างกัน ระบบจึงแบ่งการประเมินออกเป็น 3 ระดับ (Level 1–3) เพื่อให้ผู้ฝึกสามารถพัฒนาได้อย่างเป็นลำดับขั้นตอน

ตารางที่ 3.12 — การกำหนดกฎ Heuristics

Level	รูปแบบ	ผู้ใช้เป้าหมาย	ระดับ	การเคลื่อนไหว	กฎที่ใช้	R-01	R-02	R-03	R-04	R-05	R-06	R-07	R-08	R-09
1	นั่ง	ผู้เริ่มต้น	เริ่มต้น	แขน และส่วนบน	3	✅	❌	✅	❌	❌	❌	✅	❌	❌
2	ยืน	ผู้ฝึกทั่วไป	กลาง	เอวและส่วนบน	6	✅	✅	✅	✅	✅	❌	✅	❌	❌
3	ยืนย่อ	ผู้เชี่ยวชาญ	สูง	ทั้งตัว (บน-ล่าง)	9	✅	✅	✅	✅	✅	✅	✅	✅	✅

กลไกการไต่ระดับความซับซ้อนนี้ ถูกออกแบบภายใต้ฐานคิดของการรับรู้ (Cognitive Factors) เพื่อให้ผู้ฝึกสามารถรักษาสมาธิและเรียนรู้ได้อย่างเป็นธรรมชาติ ดังอธิบายผ่านแผนภาพการซ้อนทับระดับทักษะในภาพที่ 3.13

ภาพที่ 3.13 แผนภาพซ้อนทับแสดงเหตุผลการจัดกลุ่มกฎ Heuristics ตามระดับการฝึก (Adaptive Cognitive Load)

การออกแบบให้จำนวนกฎ (Heuristics Rules) เพิ่มขึ้นตามลำดับขั้นนี้ มีวัตถุประสงค์เพื่อ การจัดการภาระทางพุทธิปัญญา (Cognitive Load Management) เพื่อลดโอกาสเกิดภาวะข้อมูลล้นหลาม (Cognitive Overload) การจำกัดกฎให้เหลือเพียงส่วนที่จำเป็นใน Level 1 ช่วยให้ผู้เริ่มต้นสามารถรักษาสมาธิและจดจ่อ (Focus) กับพื้นฐานสำคัญได้โดยไม่รู้สึกท้อถอย เมื่อทักษะเริ่มพัฒนาเข้าสู่สภาวะอัตโนมัติ (Automaticity) ระบบจึงค่อยเพิ่มความซับซ้อนไปจนถึง Level 3 เพื่อการตรวจสอบที่ครอบคลุมทุกมิติ

3.5.3 สถาปัตยกรรมและกระบวนการออกแบบ (Design Process and Architecture)

การแปลงหลักการมวยไท้เก๊กสกุลเฉินที่เป็นนามธรรมให้เป็นกฎที่คอมพิวเตอร์ประมวลผลได้ เป็นความท้าทายสำคัญทาง วิศวกรรมความรู้ (Knowledge Engineering) ของโครงการนี้ โดยกระบวนการออกแบบ (Design Process) มี 3 ขั้นตอนหลัก ซึ่งสามารถอธิบายผ่านสายพานการประมวลผลในภาพที่ 3.14 ดังนี้:

ภาพที่ 3.14 กระบวนการวิศวกรรมความรู้ 3 ขั้นตอน (Knowledge Engineering Process)

1. สกัดหลักการ (Principle Extraction): ผู้เชี่ยวชาญมวยอธิบายหลักการแต่ละข้อเป็นภาษาธรรมชาติ เช่น "ศอกต้องจมลงเสมอ"
2. แปลงเป็นตัวชี้วัด (Metric Definition): เปลี่ยนภาษาธรรมชาติเป็นคุณลักษณะที่วัดได้จากพิกัด Landmarks 33 จุดของ MediaPipe เช่น "มุมระหว่าง Shoulder → Elbow → Wrist ต้องไม่เกิน 45°"
3. กำหนดเกณฑ์ (Threshold Calibration): ทดสอบกับชุดข้อมูลวิดีโอผู้เชี่ยวชาญและปรับค่า Threshold จนได้เกณฑ์การเตือนที่เหมาะสม

เพื่อให้กระบวนการทั้ง 3 ขั้นตอนข้างต้นสามารถถูกเขียนเป็นซอร์สโค้ดที่มีความยืดหยุ่นสูง รองรับการสลับสับเปลี่ยนกฎในแต่ละระดับการฝึก (ระดับ 1–3) และรองรับการเพิ่มกฎใหม่ในอนาคต โครงสร้างของ Heuristics Engine จึงถูกออกแบบโดยใช้รูปแบบ Strategy Design Pattern เพื่อสนับสนุนหลักการ Open/Closed Principle ดังแสดงในภาพที่ 3.15

ภาพที่ 3.15 Class Diagram ของ Heuristics Engine แสดงสถาปัตยกรรมแบบ Strategy ของ Heuristics Rules

จากผังในภาพที่ 3.15 การที่กฎการประเมินทุกข้อ (Rule 1-9) สืบทอด (Inherit) จาก BaseRule Class ทำให้มี Interface มาตรฐานเหมือนกันทั้งหมด โมดูลประมวลผลหลัก (HeuristicsEngine) จึงสามารถวนลูปเรียกเมธอด validate() และ getFeedback() ของทุกกฎผ่านกลไก พหุสัณฐาน (Polymorphism) ได้อย่างอิสระ โดยไม่ต้องทราบรายละเอียดสมการคณิตศาสตร์ที่ซ่อนอยู่ภายในโมดูลของแต่ละกฎ (Loose Coupling)

3.5.4 รายละเอียดเกณฑ์การคำนวณเชิงปริมาณ (Metrics and Calculation Methods)

เพื่อแปลงพิกัด (Coordinates) เชิงพื้นที่ของ MediaPipe ให้เป็นผลลัพธ์เชิงคุณภาพ ระบบอาศัยเทคนิคทางเรขาคณิตวิเคราะห์ (Analytic Geometry) และจลนศาสตร์ (Kinematics) เข้ามาช่วยประมวลสัญญาณแบบทันที เช่น การใช้ Dynamic Time Warping (DTW) เพื่อเปรียบเทียบความเพี้ยนของเส้นทางการเคลื่อนไหว การประยุกต์สูตร Vector Cross Product เพื่อหาการหมุนของข้อมือในปริภูมิ 3 มิติเชิงทิศทาง หรือการใช้ดัชนี SPARC (Spectral Arc Length) มาจับสมูทเนส (Smoothness) ในการส่งแรง ซึ่งรายละเอียดของจุดอ้างอิงและเทคนิคการคำนวณสำหรับกฎทั้ง 9 ข้อ สรุปไว้ในตารางที่ 3.13

(หมายเหตุ: ทุกพิกัด 3 มิติที่ถูกนำมาคำนวณในตารางนี้ ได้ผ่านกระบวนการ Normalization ปรับสัดส่วนมาตราส่วนของแต่ละบุคคลโดยโมดูล Calibration Manager แล้ว เพื่อให้การประมวลผลเป็นอิสระจากระยะห่างของหน้ากล้อง)

ตารางที่ 3.13 Heuristics Rules 9 ข้อ และวิธีการคำนวณ

Rule	ชื่อ	Landmarks ที่ใช้	วิธีการประมวลผลและเกณฑ์การวัด (Calculations & Metrics)
R-01	Path Shape	ข้อมือ (15/16)	Dynamic Time Warping (DTW) เพื่อวัดความคล้ายคลึงของวิถีปัจจุบัน vs ต้นแบบ
R-02	Arm Rotation	ข้อมือ, นิ้ว (15-20)	Vector Cross Product เพื่อหาทิศทางของ Normal Vector ของฝ่ามือแบบ 3 มิติ
R-03	Elbow Sinking	ไหล่, ศอก, ข้อมือ (11-16)	การวัดมุมระหว่าง Shoulder→Elbow เทียบกับระนาบแนวนอน (Horizontal Plane)
R-04	Waist Initiation	เอว, ไหล่, ข้อมือ (23-26, 11-16)	Phase Lag Analysis ของความเร็วเชิงเส้น (Velocity) ระหว่าง Hip vs Wrist
R-05	Vertical Stability	จมูก, หู (0-8)	ส่วนเบี่ยงแบนมาตรฐาน (Standard Deviation) ของแนวแกนดิ่ง (Y-axis)
R-06	Smoothness	ข้อมือ (15/16)	Spectral Arc Length (SPARC) [18], [19] เพื่อวิเคราะห์ความซับซ้อนของสัญญาณความเร็ว
R-07	Continuity	ข้อมือ (15/16)	การตรวจหาค่าความเร็วที่ใกล้ศูนย์ (Near-zero Velocity) นอกเหนือจากจุดเปลี่ยนทิศทาง
R-08	Weight Shift	สะโพก, หัวเข่า (23-28)	การเคลื่อนที่ตามแนวขวาง (Lateral Displacement) ของจุดบั้นท้ายเทียบกับฐานรองรับ
R-09	Coordination	ข้อมือ, สะโพก (15-16, 23-24)	การวิเคราะห์ทิศทางความเร็ว (Velocity Direction) ของข้อมือเทียบกับจุดศูนย์กลางเอว

3.5.5 ลำดับการประมวลผลกฎ (Heuristics Evaluation Flow)

เพื่อให้การให้คำแนะนำป้อนกลับ (Feedback) มีความแม่นยำและไม่สร้างภาระการรับรู้และประมวลผล (Cognitive Load) ให้แก่ผู้ฝึกจนเกินไป Heuristics Engine จึงถูกออกแบบให้มีลำดับการประมวลผลแบบวนรอบเฟรม (Per-frame Cycle) ดังแสดงในภาพที่ 3.16

ภาพที่ 3.16 ผังการทำงานของ Heuristics Engine (Activity Diagram) แสดงวงจรการประมวลผลและการคัดเลือกผลลัพธ์

คำอธิบายตรรกะการประมวลผลในแผนภาพประกอบด้วยขั้นตอนหลักดังนี้:

1. Sense & Process: ระบบรับพิกัดร่างกายที่ผ่านการทำ Calibration แล้วมาเข้าสู่โมดูลประเมินผล
2. Parallel Validation: กฎ Heuristics ทั้ง 9 ข้อจะทำการตรวจสอบความถูกต้องของท่าทางพร้อมกันในทุกเฟรม โดยแต่ละกฎจะคืนค่าสถานะ (Normal / Warning / Critical) พร้อมข้อความแนะนำ
3. Priority-based Filtering: ในกรณีที่ผู้ฝึกทำผิดหลักการหลายข้อพร้อมกัน ระบบจะใช้ ตรรกะเชิงจลนศาสตร์ (Kinematics Priority Logic) เพื่อคัดเลือกข้อผิดพลาดที่มีความสำคัญสูงสุดเพียงหนึ่งเดียวมาแสดงผล เพื่อให้ผู้ฝึกสามารถปรับปรุงท่าทางได้อย่างเป็นขั้นตอนโดยไม่เกิดสภาวะข้อมูลล้นหลาม
4. Feedback Synthesis: ผลลัพธ์ที่ถูกคัดเลือกจะถูกส่งต่อไปยังโมดูลการแสดงผล (Visualizer) และโมดูลเสียง (TTS) เพื่อโต้ตอบกับผู้ใช้แบบฉับพลัน

---

3.6 ระบบสนับสนุนการวิเคราะห์และการจัดการข้อมูล (Analytics & Data Management)

เนื้อหาในหัวข้อนี้ให้ความสำคัญต่อเครื่องมือและกระบวนการทำงานที่เกิดขึ้นภายหลังจบการฝึกซ้อม (Post-session Tools) เพื่อให้บริการแก่นักวิจัย ผู้ประเมินผล หรือผู้เชี่ยวชาญ (Admin) สำหรับบริหารคลังข้อมูลและย้อนรอยความผิดพลาดแบบ Frame-by-frame

3.6.1 ระบบเล่นย้อนหลังเพื่อการวิเคราะห์ (Skeleton Replay System)

โมดูล ReplayManager (UC-05) ทำหน้าที่เพิ่มขีดความสามารถในการเรียนรู้ผ่านกระบวนการสะท้อนคิด (Self-Reflection) ระบบนี้อาศัยการจัดเก็บข้อมูลแพ็กเกจโครงกระดูก (Skeleton Buffer) นำมาเรนเดอร์ภาพใหม่ย้อนหลัง ผนวกกับเทคนิค การประมาณค่าในช่วงเชิงเส้น (Linear Interpolation - Lerp) เพื่อเสริมสร้างความต่อเนื่องของการแสดงผล (Smoothing) ทำให้ผู้ฝึกสามารถสังเกตจุดบกพร่องได้อย่างละเอียดในทุกเฟรมการเคลื่อนไหว ดังตัวอย่างเครื่องมือในภาพที่ 3.17

ภาพที่ 3.17 หน้าจอ Skeleton Replay แสดงการเล่นย้อนหลังแบบ 3D Overlay

3.6.2 เครื่องมือจัดการข้อมูลแม่แบบสำหรับผู้เชี่ยวชาญ (Reference Data Collector Tool)

เครื่องมือจัดการเฉพาะด้าน (data_collector.html) มีบทบาทสำคัญในการจัดเก็บบันทึกท่าทางแม่แบบจากชุดท่าอาจารย์มวย (Master Path JSON) ซึ่งเป็นค่ามาตรฐานเชิงเปรียบเทียบ (Reference Baseline) ขั้นตอนนี้ช่วยรับรองความถูกต้องของเส้นทางมาตรฐานและป้องกันความคลาดเคลื่อนจากข้อผิดพลาดของข้อมูลนำเข้า ดังแสดงอินเทอร์เฟซในภาพที่ 3.18

ภาพที่ 3.18 ส่วนต่อประสานเครื่องมือตั้งค่าพิกัดต้นฉบับ Master Pose (Data Collector)

3.6.3 การส่งออกข้อมูลและการรักษาความเป็นส่วนตัว (Data Export & Privacy-by-Design)

ภายใต้หลักการ การออกแบบที่คำนึงถึงความเป็นส่วนตัว (Privacy-by-Design) กลไกของระบบจะทำการแยกอัตลักษณ์ทางภาพ (Visual Identity) ออกจากพฤติกรรมการเคลื่อนไหวโดยสิ้นเชิง ทำให้ข้อมูลที่มีการส่งถ่ายมีเพียงไฟล์พิกัดคณิตศาสตร์ในรูปแบบ JSON (Landmarks Coordinates) เท่านั้น สิ่งนี้ทำให้นักวิจัยสามารถนำชุดข้อมูลกลับไปวิเคราะห์ใหม่ (Post-analysis Re-run) ได้อย่างปลอดภัยและเป็นไปตามหลักจริยธรรมข้อมูล

รูปแบบการจัดเก็บเชิงคลังข้อมูลนี้ สามารถอธิบายได้ผ่านผังโครงสร้างของ Logical Data Model ดังภาพที่ 3.19

ภาพที่ 3.19 แบบจำลองข้อมูลเชิงตรรกะ (Logical Data Model) แสดงโครงสร้างข้อมูล JSON สำหรับส่งออกวิเคราะห์ภายนอก

---

3.7 สถาปัตยกรรมการติดตั้งแอปพลิเคชัน (Deployment Architecture)

ระบบแอปพลิเคชัน TaijiFlow จะถูกรวบรวมและประกอบร่างผ่านกระบวนการ Continuous Deployment เพื่อเผยแพร่บริการสู่ระบบเครือข่าย Vercel Edge Network ในรูปแบบ Static Hosting เพื่อรองรับการเข้าถึงจากผู้ใช้งานทั่วโลกด้วยความเร็วสูง (Low Latency)

นอกจากนี้ระบบยังส่งเสริมสิทธิ์การเข้าถึงข้อมูลตามมาตรฐาน Progressive Web App (PWA) ด้วยคุณสมบัติดังนี้:

• Service Worker: ทำหน้าที่จัดการแคช (Caching) ข้อมูลโมเดล AI และพิกัดท่าต้นแบบ JSON ทำให้ผู้ใช้งานสามารถสั่งฝึกซ้อมระบบได้ทันทีแม้ในสภาวะออฟไลน์
• Installation: ผู้ใช้งานสามารถติดตั้งแอปบนอุปกรณ์พกพาได้โดยตรง ทำให้การเข้าถึงบทเรียนไท้เก๊ก (Learning on Demand) เป็นไปอย่างสะดวกและยืดหยุ่น

สถาปัตยกรรมโครงสร้างพื้นฐานเหล่านี้ได้ถูกแสดงไว้ในลักษณะ Deployment Diagram ในภาพที่ 3.20

ภาพที่ 3.20 ผังการจัดวางระบบ (Deployment Diagram)

---

3.8 ความเชื่อมโยงของระบบและการทดสอบ (System Traceability)

3.8.1 แนวคิดการตรวจสอบย้อนกลับ (Traceability Concept)

เพื่อให้มั่นใจว่าซอฟต์แวร์ที่พัฒนาขึ้นตอบโจทย์ความต้องการของผู้ใช้และได้รับการทดสอบอย่างครบถ้วน โครงงานนี้จึงจัดทำตารางตรวจสอบย้อนกลับ (Traceability Matrix) ที่เชื่อมโยงตั้งแต่ความต้องการระดับผู้ใช้ (IRS), ความต้องการเชิงฟังก์ชัน (SRS), การออกแบบ (Design), ไปจนถึงชุดทดสอบ (Test Cases) โดยมีรายละเอียดภาพรวมสรุปไว้ส่วนนี้

3.8.2 ตารางสรุปความเชื่อมโยง (Traceability Matrix Summary)

จากตรรกะและแนวคิดแผงผังเบื้องต้นข้างต้น สามารถนำมาประมวลผลเป็นตารางจับคู่ความสอดคล้อง (Mapping) ระหว่างเป้าหมายกับชุดทดสอบทั้งหมด ดังแสดงรายละเอียดในตารางที่ 3.14

ตารางนี้ทำหน้าที่สองประการคือ (1) ยืนยันความสมบูรณ์ของการออกแบบ โดยแสดงว่าทุก Use Case มี Requirement, Design Artifact, และชุดทดสอบรองรับครบถ้วน และ (2) อ้างอิงล่วงหน้า (Forward Reference) ไปยังบทที่ 4 ซึ่งนำเสนอรายละเอียดและผลการดำเนินการทดสอบจริง (Execution Result) ของแต่ละชุดทดสอบอย่างครบถ้วน ผู้อ่านสามารถอ้างอิงตารางนี้ควบคู่กับบทที่ 4 เพื่อตรวจสอบความสอดคล้องระหว่างแผนการออกแบบและผลการทดสอบได้

ตารางที่ 3.14 Traceability Matrix สรุป UC-01 ถึง UC-12

UC	Use Case	URS	SRS	AD	SD	CD (Core)	UTC	ITC	STC	UATC
UC-01	Perform Training	01–06	01–09	AD-01	SD-01	CD-CORE-01,02,03	01–31, 63–72	ITC-01, 02	STC-01	UATC-01, 05
UC-02	Calibrate Body	07–10	10–14	AD-02	SD-02	CD-CORE-03	32–44	ITC-03	STC-02	UATC-02
UC-03	Receive Feedback	11–14	15–19	AD-03	SD-03	CD-CORE-01, CD-RULE-01–09	01–31	ITC-01, 02	STC-03	UATC-01, 03
UC-04	View Score Summary	15–18	20–23	AD-04	SD-04	CD-CORE-02	45–50	—	STC-04	UATC-04
UC-05	Review Replay	19–22	24–28	AD-05	SD-05	CD-CORE-06, CD-CTRL-05	51–62	—	STC-05	—
UC-06	Gesture Control	23–26	29–32	AD-06	SD-06	CD-CORE-05	63–66	—	STC-06	—
UC-07	Enter Flow State	27–30	33–36	AD-07	SD-07	CD-CTRL-04	67–69	—	STC-07	—
UC-08	Submit Feedback Survey	31–34	37–40	AD-08	SD-08	CD-UI-07	70–72	—	STC-08	SVT-01
UC-09	View Tutorial	35–38	41–44	AD-09	SD-09	CD-CTRL-03	—	—	STC-09	UATC-02
UC-10	Manage Configurations	39–42	45–48	AD-10	SD-10	CD-UI-02, 05	—	—	STC-10	—
UC-11	Manage Reference Data	43–45	49–52	AD-11	SD-11	CD-UI-01, 02	—	—	STC-11	—
UC-12	View Feedback Dashboard	46–47	53–55	AD-12	SD-12	CD-UI-08	—	—	STC-12	SVT-02

NOTE

URS/SRS แสดงเป็น absolute ID ตาม SRS.md Section 4 UTC = Unit Test Case (72 กรณี), ITC = Integration Test Case (3 กรณี), STC = System Test Case (12 กรณี) UATC = User Acceptance Test Case (5 กรณี), SVT = Survey Validation Test (2 กรณี) รายละเอียดครบถ้วนอยู่ในเอกสาร Traceability Record (ภาคผนวก ฉ) และ Test Plan (ภาคผนวก จ)

3.8.3 การทดสอบการยอมรับโดยผู้ใช้ (User Acceptance Testing - UATC)

การทดสอบในระดับนี้ออกแบบให้ครอบคลุมเฉพาะ เส้นทางการใช้งานหลัก (Core User Journey) และ ความถูกต้องของโดเมนความรู้ (Domain Validity) ที่ต้องการมุมมองจากผู้ใช้จริงหรือจากผู้เชี่ยวชาญโดเมนด้านมวยไท้เก๊กโดยตรง ดังนี้

• UATC-01 (Academic Accuracy): ยืนยันโดยผู้เชี่ยวชาญมวยไท้เก๊กสกุลเฉิน ว่ากฎ Heuristics ทั้ง 9 ข้อนั้นสอดคล้องกับหลักการไท้เก๊กอย่างแท้จริง → ตอบโจทย์ UC-01, UC-03
• UATC-02 (Usability & Learnability): ผู้ใช้ทั่วไปสามารถเริ่มต้นการฝึกฝนได้ด้วยตนเองผ่านระบบแนะนำ (Tutorial) โดยไม่ต้องพึ่งพาคู่มือภายนอกภายในเวลา 5 นาที → ตอบโจทย์ UC-01, UC-02, UC-09
• UATC-03 (Feedback Comprehension): ผู้ฝึกสามารถเข้าใจคำแนะนำ (Feedback) ทั้งในรูปแบบภาพและเสียงสื่อสารสองภาษา และนำไปปรับปรุงท่าทางได้ทันที → ตอบโจทย์ UC-03
• UATC-04 (Scoring Transparency): ผู้ใช้มีความเชื่อมั่นว่าระบบการให้คะแนนและเกรดสะท้อนถึงทักษะและความแม่นยำในการรำที่แท้จริง → ตอบโจทย์ UC-04
• UATC-05 (Overall Satisfaction): ผู้ใช้มีความพึงพอใจในภาพรวมและต้องการใช้ระบบเพื่อการฝึกฝนอย่างต่อเนื่อง → ตอบโจทย์ภาพรวม UC-01 ถึง UC-12

Use Case ที่แสดงสัญลักษณ์ "—" ในคอลัมน์ UATC ของตารางที่ 3.14 (เช่น UC-05 ถึง UC-07, UC-10 และ UC-11) ได้รับการผ่านการทดสอบคุณภาพในระดับ System Test (STC) อย่างครบถ้วนแล้ว โดยส่วนใหญ่เป็นฟังก์ชันเสริมสำหรับผู้ใช้ระดับสูง (Advanced Features) หรือเป็นฟังก์ชันสำหรับผู้ดูแลระบบ (Admin)

3.8.4 การทดสอบระดับบูรณาการ (Integration Testing - ITC)

การทดสอบระดับบูรณาการเน้นไปที่การไหลของข้อมูลข้ามโมดูล (Cross-module Data Flow) โดยเฉพาะในส่วนของ AI Processing Pipeline ที่เป็นแกนกลางสำคัญ โดยมีกรณีทดสอบหลักดังนี้:

• ITC-01 (Perfect Flow Integration): ทดสอบการส่งต่อข้อมูลพิกัด (Landmarks) ที่มีความแม่นยำสูงจาก MediaPipe เข้าสู่ HeuristicsEngine และ ScoringManager ว่าสามารถประมวลผลเป็นคะแนนที่ถูกต้องได้หรือไม่
• ITC-02 (Error Propagation Analysis): ทดสอบความทนทานของระบบเมื่อข้อมูลนำเข้ามีสัญญาณรบกวน (Noise) ว่า ScoringManager จะสามารถสะสมความคลาดเคลื่อนได้อย่างสมเหตุสมผลหรือไม่
• ITC-03 (Calibration Handoff): ทดสอบการส่งต่อค่า Body Scale Factor จากโมดูล CalibrationManager ไปยัง HeuristicsEngine ว่าระบบสามารถรับค่าไปปรับใช้ใน Normalization ได้ทันทีโดยไม่ต้องรีสตาร์ทระบบหรือไม่

สำหรับ Use Case อื่นๆ (UC-04 ถึง UC-12) ส่วนใหญ่เป็นการทำงานในชั้น Presentation หรือ Controller Layer ซึ่งไม่มีความซับซ้อนในการเชื่อมต่อข้อมูลข้ามโมดูลมากนัก จึงได้รับการตรวจสอบความถูกต้องผ่านการทดสอบระดับโมดูล (Unit Test) และระดับระบบ (System Test) แทน

---

3.9 บทสรุปประจำบท (Chapter Summary)

สถาปัตยกรรมและการออกแบบระบบปัญญาประดิษฐ์ประมวลผลท่าทางตามแนวคิดวิศวกรรมซอฟต์แวร์ที่นำเสนอในบทนี้ ถือเป็นพิมพ์เขียว (Blueprint) สำคัญที่ช่วยให้โครงการ TaijiFlow AI มีความมั่นคงและตรวจสอบได้ตามมาตรฐาน ISO/IEC 29110

การแยกส่วนประกอบแอปพลิเคชันอย่างเป็นระเบียบ (Separation of Concerns) ไปจนถึงการออกแบบตรรกะการประมวลผลแบบทันที (Real-time Pipeline) ล้วนมุ่งเป้าไปที่การตอบสนองต่อทั้งข้อกำหนดเชิงฟังก์ชัน (Functional Requirements) และข้อกำหนดที่ไม่ใช่ฟังก์ชัน (Non-Functional Requirements) เช่น ประสิทธิภาพและความเป็นส่วนตัว องค์ความรู้และโครงสร้างที่ถูกจัดเตรียมในบทนี้ จะถูกนำไปพิสูจน์ผลสัมฤทธิ์ผ่านการทดสอบและประเมินผลเชิงประจักษ์ร่วมกับกลุ่มเป้าหมายจริง ดังที่จะนำเสนอรายละเอียดในบทถัดไป