ดาวน์โหลดงานนำเสนอ
งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ
1
ระบบบริหารจัดการคลังยา
Case study 2 ระบบบริหารจัดการคลังยา
2
Case study 2: การบริการจัดการคลังยา
สถานีอนามัย เป็นหน่วยงานราชการ สังกัดกระทรวงสาธารณะสุขมีสาขาสำนักงาน อยู่ตามตำบล อำเภอ ทั่วประเทศ เพื่อให้บริการสาธารณะสุขขั้นพื้นฐานกับ ประชาชนในชนบท เป็นส่วนใหญ่ บุคลากรประจำที่สำนักงานมีจำกัด ระบบงานที่ช่วยในการบริหารจัดการยังไม่มี ระบบจัดเก็บข้อมูล ที่ผ่านมาต้องใช้ การบันทึกข้อมูลลงสมุด การตรวจสอบการค้นหาข้อมูล ต้องใช้เวลามาก สถานีอนามัยทุกแห่งมีการเก็บยาเพื่อให้บริการผู้ป่วยที่มารับบริการ โดยมีแพทย์ ผู้รักษาจะเป็นผู้สั่งจ่ายยาให้กับผู้ป่วยแต่ละราย และยังไม่มีการพัฒนาระบบการ จัดเก็บข้อมูลโดยใช้คอมพิวเตอร์ ในลักษณะเป็นฐานข้อมูลที่สามารถค้นหา แก้ไข พิมพ์รายงาน ติดตามความเคลื่อน ไหวรายการยาที่มีอยู่ที่สถานีอนามัย การตรวจสอบวันหมดอายุยาแต่ละชนิดทำได้ยากต้องใช้เวลานาน สิ้นเปลืองแรงงาน มีความยุ่งยากในการดำเนินการ
3
Use Case Diagram ระบบบริหารจัดการคลังยา
4
Use Case Diagram ระบบบริหารจัดการคลังยา
ทำทะเบียนยา D-0003 จัดเก็บยา D-0004 ออกรายงาน D-0005 จ่ายยา ผอ.สถานีอนามัย จนท.รับยา หมอ D-0006 ตรวจเช็ค วันหมดอายุ System D-0001 ล็อคอิน
5
Use-Case Narrative Author (s) : Group 1 Date : 26 Feb 2008
Version : DM001 Use-Case Names: ล็อคอิน Use Case Type : Functional requirements Use –Case ID: D-0001 Priority: สูง Source Requirements Primary Business Actor: เจ้าหน้าที่, หมอ, ผอ. Other Participating Actors: - Other Interested Stakeholders: Description: Use Case นี้อธิบายเหตุการณ์ที่ Actor ทำการ Log in เพื่อเข้าสู่ระบบ Precondition: ผู้ใช้ระบบเปิดโปรแกรมระบบบริหารจัดการคลังยา Trigger: เมื่อผู้ใช้กรอกข้อมูล Username และ Password ถูกต้อง ล็อคอิน
6
Use-Case Narrative ล็อคอิน Typical Course of Event Actor Action
System Response Step 1: ผู้ใช้กรอกข้อมูล Username และ Password แล้วกดปุ่ม Submit Step 2: ระบบทำการตรวจสอบข้อมูล Username และ Password ที่ผู้ใช้กรอกเข้ามาว่าตรงกับฐานข้อมูลที่มีอยู่หรือไม่ Step 3: ถ้าข้อมูลไม่ตรงกันให้ตรวจสอบ Step 4: Step 4: ให้ตรวจสอบว่า Username ผิด หรือ Password ผิด Step 5: ระบบแจ้งข้อผิดพลาดจาก Step 4: เพื่อให้ผู้ใช้ระบบกรอกข้อมูลใหม่ให้ถูกต้อง Step 6: ระบบตรวจสอบข้อมูล Username และ Password อีกครั้ง ถ้าข้อมูลถูกต้องให้แสดงข้อความ “ยินดีต้อนรับเข้าสู่ระบบ” Step 7: ระบบตรวจสอบความพร้อมของฟังก์ชั่นการทำงานต่างๆ ของระบบตามสิทธิ์ของผู้ใช้ระบบแต่ละคน ล็อคอิน
7
Use-Case Narrative ล็อคอิน Alternate Course:
Alt-Step 2: ถ้าข้อมูล Username และ Password ถูกต้องให้ผู้ใช้สามารถ Log in เข้าสู่ระบบได้ และสามารถใช้งานระบบตามสิทธิ์ของแต่ละคน Alt-Step 3: ถ้าข้อมูล Username และ Password ไม่ตรงกับฐานข้อมูล ให้ผู้ใช้กรอกข้อมูลใหม่ให้ถูกต้อง Conclusion: Use Case นี้จะสิ้นสุดเมื่อผู้ใช้ระบบทำการ Log in เข้าสู่ระบบได้ Postcondition: ผู้ใช้ระบบสามารถทำรายการต่างๆ ตามสิทธิ์ในการใช้ระบบของแต่ละคนได้ Business Rules: - Implementation Constraints and Specifications: มีการออกแบบ GUI ให้ผู้ใช้สามารถใช้งานง่าย, ไม่ซับซ้อน และมีการออกแบบระบบ On Web เพื่อให้ระบบสามารถจัดการข้อมูลได้ทั่วถึงและมีการอัพเดทข้อมูลต่างๆ เพื่อการบริการผ่านระบบเว็บบราวส์เซอร์ Assumptions: ระบบสามารถรายงานสถิติการ Log in ได้ Open Issues: สามารถ Log in เข้าสู่ระบบจากระยะไกลได้ (ผ่านระบบอินเตอร์เน็ต) ล็อคอิน
8
Use-Case Narrative Author (s) : Group 1 Date : 26 Feb 2008
Version : DM001 Use-Case Names: ทำทะเบียนยา Use Case Type : Functional requirements Use –Case ID: D-0002 Priority: สูง Source Requirement Primary Business Actor: เจ้าหน้าที่รับยา Other Participating Actors: - Other Interested Stakeholders: หมอ - ตรวจสอบรายชื่อและชนิดของยา Description: กำหนดประเภทของยาจัดทำทะเบียนยาที่มีการ order เข้ามาใหม่ Precondition: ผู้ใช้ระบบต้องทำการ Log in เข้าสู่ระบบก่อน Trigger: ผู้ใช้เลือกรายการทำทะเบียนยา
9
Use-Case Narrative Typical Course of Event Actor Action
System Response Step 1: ผู้ใช้กรอกข้อมูลเกี่ยวกับรายละเอียดของยา เช่น ชนิด วันหมดอายุ เป็นต้น Step 2: ระบบทำการตรวจสอบกับฐานข้อมูลว่ามียาชนิดนั้นอยู่ในฐานข้อมูลหรือไม่ Step 3: ถ้าตรวจสอบว่ามี ให้ระบบแจ้งข้อความเตือนว่า “มีข้อมูลยาชนิดนี้ในฐานข้อมูลแล้ว” Step 4: ระบบทำการยกเลิกการทำรายการนั้น Step 5: หากระบบตรวจสอบแล้วพบว่ายังไม่มีทะเบียนยานั้นในฐานข้อมูล ให้ทำการบันทึกข้อมูลตามรายการเข้าสู่ฐานข้อมูล Step 6: ถ้าระบบสามารถเพิ่มข้อมูลได้ ให้แจ้งข้อความเตือนว่า “บันทึกข้อมูลทะเบียนยาเรียบร้อยแล้ว” Step 7: ระบบเตรียมรับการบันทึกข้อมูลใหม่
10
Use-Case Narrative Alternate Course:
Alt-Step 2: กรณีที่ตรวจสอบแล้วไม่พบข้อมูลยาชนิดนั้นๆ ในฐานข้อมูลให้ทำการเพิ่ม Record ตามรายละเอียดข้อมูลยาที่ผู้ใช้กรอก Alt-Step 5: กรณีที่ไม่มีข้อมูลทะเบียนยานั้นในระบบฐานข้อมูลคลังยา ให้ระบบเช็คว่าข้อมูลที่ผู้ใช่กรอก (ในส่วนของรายการยาที่จะเพิ่มทะเบียนใหม่) ว่าครบถ้วนหรือไม่ ถ้าไม่ครบให้แจ้งข้อความเตือนว่า “กรุณากรอกข้อมูลให้ครบถ้วน” Conclusion: ผู้ใช้ระบบสามารถเพิ่มรายการทะเบียนยาใหม่ในฐานข้อมูลได้ Postcondition: ระบบทำการเพิ่มข้อมูลทะเบียนยาใหม่ (โดยไม่ซ้ำกับของเดิม) Business Rules: Implementation Constraints and Specifications: มีการออกแบบ GUI ให้ผู้ใช้สามารถใช้งานง่าย, ไม่ซับซ้อน และมีการออกแบบระบบ On Web เพื่อให้ระบบสามารถจัดการข้อมูลได้ทั่วถึงและมีการอัพเดทข้อมูลต่างๆ เพื่อการบริการผ่านระบบเว็บบราวส์เซอร์ Assumptions: ระบบสามารถแสดงข้อมูลรายงานทะเบียนยาตามรายการที่เลือกได้ Open Issues: ผู้ใช้สามารถแก้ไขข้อมูลทะเบียนยาในระบบฐานข้อมูลได้
11
Use-Case Narrative Author (s) : Group 1 Date : 26 Feb 2008
Version : DM001 Use-Case Names: จัดเก็บยา Use Case Type : Functional requirements Use –Case ID: D-0003 Priority: สูง Source Requirement Primary Business Actor: เจ้าหน้าที่ Other Participating Actors: - Other Interested Stakeholders: Description: Use Case นี้อธิบายเกี่ยวกับขั้นตอนในการจัดเก็บยา Precondition: - ข้อมูลทะเบียนยาและจำนวนสำหรับยาที่มีอยู่ในระบบแล้ว Trigger: ข้อมูลจำนวนยาแต่ละชนิด สามารถเพิ่ม / ลด และแก้ไขข้อมูลของ จำนวนยาได้- ข้อมูลจำนวนยาแต่ละชนิดถูกแสดงผลหรือพิมพ์ออกมา ตามคำร้องขอ
12
Use-Case Narrative จัดเก็บยา Typical Course of Event Actor Action
System Response Step 1: เจ้าหน้าที่เลือกเมนู Manage Stock Step 3 : เจ้าหน้าที่กรอกจำนวนยาที่นำเข้าและเบิกจ่าย Step 2: ระบบแสดงหน้าเพิ่ม, แก้ไขและบันทึกรายละเอียดจำนวนยา Step 4 : ระบบทำการตรวจสอบความถูกต้องของข้อมูลที่ส่ง เข้ามาก่อนทำการบันทึก Step 5: ระบบทำการบันทึกข้อมูล และแสดงหน้าจอ รายละเอียดจำนวนยา หลังจากการบันทึกข้อมูลเรียบร้อยแล้ว จัดเก็บยา
13
Use-Case Narrative Alternate Course:
Alt-Step 1 : ถ้าบุคคลไม่มีสิทธิในการเข้าถึง ระบบจะแสดงข้อความปฏิเสธ การเลือกเมนูนั้น Alt-Step 4 : ถ้าข้อมูลที่ส่งเข้ามาไม่สามารถเก็บลงในฐานข้อมูลได้ ให้มีการ แจ้งถึงปัญหาที่เกิดขึ้น และร้องขอให้มีการส่งข้อมูลเข้ามาในระบบใหม่อีกครั้ง Alt-Step 5 : ถ้าจำนวนยาใน Stock น้อยกว่า 0 ให้แสดงข้อความว่า Out of Stock Conclusion: Use case นี้สิ้นสุดลงเมื่อข้อมูลถูกแสดงผลหรือพิมพ์ออกมาตามคำร้องขอและข้อมูลได้ถูกบันทึกอย่างถูกต้องครบถ้วน Postcondition: สามารถจัดเก็บยาได้ตามรายการที่มี Business Rules: เจ้าหน้าที่รับยาสามารถบันทึกและแก้ไขได้เท่านั้น หมอและผอ.สถานีอนามัยสามารถดูรายงานข้อมูล Stock ได้อย่างเดียว Implementation Constraints and Specifications: ต้องมีการสร้างระบบที่สามารถแยกแยะประเภทของผู้ใช้งานได้ อาจมีการแจ้งเตือนจำนวนยาใน Stock ที่น้อยกว่า 10 หน่วย ของแต่ละ ประเภท Assumptions: ระบบสามารถจัดเก็บและคำนวณจำนวนยาใน Stock ได้ Open Issues: -
14
Use-Case Narrative Author (s) : Group 1 Date : 26 Feb 2008
Version : DM001 Use-Case Names: จ่ายยา Use Case Type : Functional requirements Use –Case ID: D-0004 Priority: สูง Source Requirement Primary Business Actor: เจ้าหน้าที่, หมอ Other Participating Actors: - ผอ. Other Interested Stakeholders: - Description: Use Case นี้อธิบายเกี่ยวกับขั้นตอนการจ่ายยาตามใบสั่งยา Precondition: ผู้ใช้ระบบต้องทำการ Log in เข้าสู่ระบบก่อน Trigger: ผู้ใช้ระบบเลือกเมนู “จ่ายยา”
15
Use-Case Narrative จ่ายยา Typical Course of Event Actor Action
System Response Step 1: ผู้ใช้ระบบกรอกข้อมูลยาตามใบสั่งยา Step 2: ระบบตรวจสอบรายชื่อยาว่ามีอยู่ในทะเบียนยาหรือไม่ Step 3: ระบบตรวจสอบว่ายาที่มีอยู่นั้น เพียงพอกับความต้อง การ (ที่ต้องจ่าย) หรือไม่ Step 4: ถ้าตรวจพบว่ามี ให้ระบบทำการตัด Stock ยาชนิดนั้นๆ ตามข้อมูลใบสั่งยา Step 5: ถ้าตรวจพบว่าไม่มียาชนิดนั้นในทะเบียนยา ให้ระบบทำการแจ้งข้อความเตือนว่า “ไม่มียาชนิดนี้ในคลังยา กรุณาตรวจสอบข้อมูลใหม่อีกครั้ง” Step 6: กรณีที่ระบบตรวจสอบแล้วพบว่ายาชนิกนั้นมีจำนวนไม่เพียงพอต่อความต้องการตามใบสั่งยา ให้ระบบทำการแจ้งข้อความเตือนว่า “ระบบไม่สามารถจ่ายยาได้ เนื่องจากมียาไม่เพียงพอ กรุณาติดต่อผู้จัดเก็บยา (Stock Management)” จ่ายยา
16
Use-Case Narrative จ่ายยา Alternate Course:
Alt-Step 2: กรณีตรวจสอบแล้วพบว่ามีรายชื่อยาที่ชนิดนั้นอยู่ในทะเบียนยา ให้ระบบแสดงรายละเอียดพร้อมสรรพคุณของยาชนิดนั้น รวมถึงข้อมูลคำแนะนำสำหรับผู้ป่วย เช่น รับประทานก่อนอาหาร หรือหลังอาหาร วันละกี่ครั้ง เป็นต้น Alt-Step 3: กรณีที่ไม่มียาชนิดนั้นในทะเบียนยา ให้ผู้ใช้หรือเจ้าหน้าที่ที่เกี่ยวข้องทำหมายเหตุไว้ในใบสั่งยา แล้วแจ้งให้เจ้าหน้าที่ที่ทำการ Stock ยาทราบ พร้อมทั้งแจ้งให้ผู้สั่งยา (คุณหมอ) ทราบด้วย Conclusion: เจ้าหน้าที่จ่ายยาสามารถจ่ายยาได้ตามใบสั่งยา Postcondition: ถ้ามียาใน Stock เจ้าหน้าที่ก็ทำการจ่ายยาตามขั้นตอน พร้อมออกใบสำคัญรับยาให้ผู้ป่วย Business Rules: - Implementation Constraints and Specifications: มีการออกแบบ GUI ให้ผู้ใช้สามารถใช้งานง่าย, ไม่ซับซ้อน และมีการออกแบบระบบ On Web เพื่อให้ระบบสามารถจัดการข้อมูลได้ทั่วถึงและมีการอัพเดทข้อมูลต่างๆ เพื่อการบริการผ่านระบบเว็บบราวส์เซอร์ Assumptions: ระบบสามารถทำการตัด Stock ยาได้ตรงตามข้อมูลใบสั่งยา Open Issues: ระบบทำการจัดเก็บข้อมูลการจ่ายยาเพื่อ Support ในส่วนของการออกรายงานสถานะยา จ่ายยา
17
Use-Case Narrative Author (s) : Group 1 Date : 26 Feb 2008
Version : DM001 Use-Case Names: พิมพ์รายงาน Use Case Type : Functional requirements Use –Case ID: D-0005 Priority: สูง Source Requirement Primary Business Actor: หมอ, เจ้าหน้าที่, ผอ. Other Participating Actors: Other Interested Stakeholders: - Description: Use Case นี้อธิบายเกี่ยวกับการ Print Report Precondition: ผู้ใช้ระบบต้องทำการ Log in เข้าสู่ระบบก่อน Trigger: เมื่อผู้ใช้ระบบเลือกเมนู “พิมพ์รายงาน”
18
Use-Case Narrative พิมพ์รายงาน Typical Course of Event Actor Action
System Response Step 1: ผู้ใช้ระบบเลือกประเภทของรายงานที่ต้องการ Step 2: ระบบตรวจสอบว่ามีข้อมูลรายงานตามประเภทที่ผู้ใช้กำหนดหรือไม่ในฐานข้อมูลคลังยา Step 3: ระบบทำการตรวจสอบความถูกต้องของข้อมูล Step 4: ระบบทำการดึงข้อมูลรายงานตามประเภทรายงานที่ผู้ใช้เลือก ขึ้นมาแสดงในแบบฟอร์มรายงานนั้นๆ Step 5: ระบบส่งคำสั่งพิมพ์รายงานออกทางเครื่องพิมพ์ได้ตามรายการที่ผู้ใช้เลือก เช่น รายงานสถานะยาในคลังยา แยกตามวันที่, ประเภท, เรียงลำดับวันหมดอายุ, รายงานการจ่ายยาแต่และชนิด, รายงานการจ่ายยาประจำวัน, ประจำเดือน เป็นต้น พิมพ์รายงาน
19
Use-Case Narrative พิมพ์รายงาน Alternate Course:
Alt-Step 2: ถ้าไม่มีข้อมูลของประเภทรายงานที่ผู้ใช้ระบุ ให้ระบบแจ้งข้อความเตือนว่า “ไม่พบข้อมูลที่ต้องการ” จากนั้นให้ระบบทำการยกเลิกรายการดังกล่าว Alt-Step 4: กรณีที่เกิดปัญหาในการติดต่อฐานข้อมูล ให้แจ้งข้อความเตือนว่า “ไม่สามารถติดต่อฐานข้อมูลได้ในนณะนี้” แล้วให้เจ้าหน้าที่ติดต่อผู้เกี่ยวข้องเพื่อแก้ไขปัญหาดังกล่าว Conclusion: ระบบแสดงข้อมูลรายงานตามที่ต้องการ Postcondition: ระบบสามารถแสดงตัวอย่างก่อนพิมพ์ออกทางหน้าจอ ตามประเภทรายงานที่เลือก Business Rules: - Implementation Constraints and Specifications: มีการออกแบบ GUI ให้ผู้ใช้สามารถใช้งานง่าย, ไม่ซับซ้อน และมีการออกแบบระบบ On Web เพื่อให้ระบบสามารถจัดการข้อมูลได้ทั่วถึงและมีการอัพเดทข้อมูลต่างๆ เพื่อการบริการผ่านระบบเว็บบราวส์เซอร์ Assumptions: ระบบสามารถแสดงข้อมูลรายงานได้ตามต้องการ Open Issues: พิมพ์รายงาน
20
Use-Case Narrative Author (s) : Group 1 Date : 26 Feb 2008
Version : DM001 Use-Case Names: เช็ควันหมดอายุ Use Case Type : Functional requirements Use –Case ID: D-0006 Priority: สูง Source Requirement Primary Business Actor: เจ้าหน้าที่ Other Participating Actors: หมอ Other Interested Stakeholders: - Description: Use Case นี้อธิบายเกี่ยวกับการเช็ควันหมดอายุของยาแต่ละชนิด โดยสามารถสรุปออกมาเป็นรายงาน เพื่อวางแผนการจัดการต่อไป Precondition: - ข้อมูลทะเบียนยาสำหรับยาที่มีอยู่ในระบบแล้ว Trigger: - ข้อมูลวันหมดอายุของยาแต่ละประเภทถูกแสดงผลหรือพิมพ์ออกมาตามคำร้องขอ
21
เช็ควันหมดอายุ Typical Course of Event Actor Action System Response
Step 1 : เจ้าหน้าที่เลือก เมนู ตรวจสอบวันหมดอายุ Step 3 : เจ้าหน้าที่เลือก วัน/เดือน/ปี ที่ต้องการ ตรวจสอบ Step 5: เจ้าหน้าที่เลือก พิมพ์รายงาน Step 2 : ระบบแสดงหน้าตรวจสอบวันหมดอายุของยาและ รายละเอียดยา Step 4 : แสดงรายละเอียดของยาและจำนวนยาที่หมดอายุ Step 6: พิมพ์รายงานทางเครื่องพิมพ์ เช็ควันหมดอายุ
22
เช็ควันหมดอายุ Alternate Course:
Alt-Step 1 : ถ้าบุคคลไม่มีสิทธิในการเข้าถึง ระบบจะแสดงข้อความปฏิเสธการเลือกเมนูนั้น Alt-Step 4 : ถ้าไม่มีการเลือกวันเดือนปีที่ต้องการให้แสดงรายละเอียดวันหมดอายุและจำนวนของยา ณ วันปัจจุบัน Conclusion: Use case นี้สิ้นสุดลงเมื่อข้อมูลถูกแสดงผลหรือพิมพ์ออกมาตามคำร้องขอ Postcondition: ระบบแสดงข้อมูลสรุปวันหมดอายุของยาตามรายการที่เลือก Business Rules: เจ้าหน้าที่สามารถดูรายงานรายละเอียดข้อมูลวันหมดอายุและจำนวนยาที่หมดอายุได้เท่านั้น Implementation Constraints and Specifications: ต้องมีการสร้างระบบที่สามารถแยกแยะประเภทของผู้ใช้งานได้ อาจมีการแจ้งเตือนวันหมดอายุของยาล่วงหน้า 30 วัน Assumptions: ระบบแสดงข้อมูลได้ถูกต้องตามความเป็นจริง โดยอิงจากข้อมูลทะเบียนยา Open Issues: - เช็ควันหมดอายุ
23
Class Diagram Class Diagram ของระบบบริหารจัดการคลังยาสถานีอนามัย ประกอบไป ด้วยกันทั้งหมด Class ได้แก่ Class Login Class user Class Admin Class doctor Class officer Class drugstore Class drug Class form Class ทำทะเบียนยา Class จัดเก็บยา Class เบิกจ่ายยา Class ยืม-คืนยา Class DataBase
25
Activity Diagram
26
Database Design: Drug วันผลิต date วันหมดอายุ 7 ราคา ลำดับ
(Sequence No.) คุณสมบัติ (Attribute) คำอธิบาย (Description) ขนาด (Width) ประเภท (Type) ประเภทคีย์ (Key Type) 1 drugid รหัสยา 6 Varchar2 PK 2 dname ชื่อยา 50 3 mfgDate วันผลิต date 4 expDaate วันหมดอายุ 5 total จำนวน unit หน่วยนับ 7 type FK 8 price ราคา 9 drugdetail รายละเอียด 150 10 Produceid บริษัทผู้ผลิต
27
Sequence Diagram: Login
28
Sequence Diagram: ตรวจสอบวันหมดอายุ
29
Interface Design
30
Q&A Thank You
31
Assignment 2 จงออกแบบเชิงวัตถุระบบ Directory เพื่อบันทึกและแสดงข้อมูลที่เกี่ยวข้องของ เพื่อนๆ เช่น ชื่อ นามสกุล ชื่อเล่น เบอร์โทรศัพท์ วันเกิด ภาพถ่าย ฯลฯ โดยระบบ สามารถบันทึกข้อมูลเพิ่มเติมได้ และค้นหาขัอมูลจาก ชื่อ นามสกุล หรือวันเดือน เกิดได้ การออกแบบให้แสดง Usecase diagram, class diagram, sequence diagram, activity diagram, interface และ database design ตาม ความเหมาะสม ให้แบ่งนักศึกษาเป็น 3 กลุ่ม แต่ละกลุ่มออกแบบระบบโดยใช้ Case tool เช่น MS Visio, StarUML, IBM Rational software และจัดทำเป็นรายงาน ส่ง พร้อมทั้งนำเสนอผลงานด้วย PowerPoint ในวันที่8 ตุลาคม 2554
งานนำเสนอที่คล้ายกัน
© 2024 SlidePlayer.in.th Inc.
All rights reserved.