1. Object Oriented Analysis and Design: OOAD Seree Chinodom

2. Object Oriented Analysis and Design:OOAD • การวิเคราะห์และออกแบบระบบเชิงวัตถุุ คือการกำหนดแนวทางการปฏิบัติ (process) และสัญลักษณ์ (Notation) ที่ใช้ในการวิเคราะห์และออกแบบซอฟต์แวร์ ซึ่งจะอ้างอิงตามหลักการของวัตถุ (Object) คือการรวมทั้งคุณลักษณะ (Attribute) และหน้าที่การทำงาน (Operation) ไว้ด้วยกัน   • มีการกำหนดมาตรฐานขั้นตอนการปฏิบัติในการวิเคราะห์และออกแบบระบบ ซึ่งในมาตรฐานจะต้องมีการนิยามคำศัพท์ต่างๆ เพื่อความเข้าใจที่ตรงกัน สร้างมาตรฐานของโมเดล (Model) และสัญลักษณ์ (Notation) ที่ใช้ในการวิเคราะห์และออกแบบระบบ

3. มาตรฐานต่างๆใน OOAD • Object Oriented Software Engineering : OOSE โดย Jacobson • Object Modeling Technique : OMT โดย Rumbaugh • OO analysis and design โดย Coad และ Yourdon • มาตรฐานต่างๆ ก็จะมีความเหมือนหรือแตกต่างกันไป แต่โดยรวมแล้วก็ต้องประกันได้ว่าทำงานได้จริงและถูกต้อง • ในแต่ละ Phase การทำงานจะต้องสามารถคาดคะเนได้ว่าผลลัพธ์ที่ได้คืออะไร

4. การวิเคราะห์และออกแบบระบบเชิงวัตถุการวิเคราะห์และออกแบบระบบเชิงวัตถุ มีโมเดลที่ใช้อยู่ 3 แบบ คือ • Functional Model • Object Model • Dynamic Model

5. 1. Functional Model • เป็นโมเดลที่ใช้ในการแสดงความต้องการของระบบทั้งหมด • ช่วยในการอธิบายรายละเอียดหลักๆ ภายในวัตถุ • แสดงให้เห็นการไหลของข้อมูลในแต่ละการทำงานโดยจะสนใจเพียงแค่ว่ามีงานอะไรบ้างที่ต้องทำ จะยังไม่สนใจว่างานนั้นๆ ทำอย่างไร  เช่น ในการพิมพ์รายงานสรุปประจำเดือน จะต้องรู้ว่างานนี้ ใครเป็นผู้ที่รับผิดชอบรายงาน  ใครเป็นผู้ที่รับผิดชอบรายงาน   รูปร่างหน้าตาของรายงานเป็นอย่างไร มีข้อมูลอะไรบ้างที่สนใจ และเมื่อออกรายงานแล้ว ใครเป็นผู้ที่รับรายงานนั้นเป็นต้น

6. Functional Model (ต่อ) • เครื่องมือที่ใช้ในการแสดงความต้องการของระบบคือ Use case diagram (Use Case Diagram) • Use case diagram เป็นไดอะแกรมที่ใช้ในการแสดงความต้องการของระบบทั้งหมดในลักษณะที่ผู้ใช้งานสามารถเข้าใจได้ง่าย โดยจะถูกนำไปใช้ต่อไปใน Phase ต่างๆ ของการวิเคราะห์และออกแบบระบบ  

7. 2. Object Model • เป็นโมเดลที่ใช้ในการแสดงโครงสร้างของระบบ โดยจะแสดงในรูปของคลาส (Class) ต่างๆ พิจารณาจากความต้องการของระบบ ที่แสดงอยู่ในฟังก์ชันนอลโมเดล  • เครื่องมือที่ใช้ในการแสดงโครงสร้างของระบบจะมีComponent Diagram และ Class Diagram • Component Diagram แสดงให้เห็นถึงความสัมพันธ์ระหว่างcomponentต่างๆ ภายในระบบ • Class Diagram แสดงให้เห็นถึงคุณลักษณะ (attribute) คือ ข้อมูล (data) หรือ ตัวแปร (variable),  หน้าที่การทำงาน (Operation) คือเมธอด (method) ภายในคลาส และความสัมพันธ์ระหว่างคลาสต่างๆ ภายในระบบ

8. 3. Dynamic Model • เป็นโมเดลที่ใช้ในการแสดงถึงการทำงานระหว่าง object (Object) ต่างๆ ตามการส่งข้อความ   (Message) หรือเมื่อเหตุการณ์ (Event) ต่างๆ ได้เกิดขึ้น • object ในที่นี้หมายถึงอินสแทนซ์ (Instance) ที่สร้างขึ้นจากคลาสที่ได้ออกแบบไว้ใน object โมเดล โดยที่แต่ละ object มีคุณสมบัติ และพฤติกรรมเช่นเดียวกับคลาสต้นแบบ • การทำงานของระบบจะประกอบขึ้นจากการส่งข้อความไปมาระหว่าง object เหล่านั้น เมื่อมีการทำงานไปเรื่อยๆ แล้ว object อาจจะมีการเปลี่ยนสถานะ(State) ไปตามเหตุการณ์ที่เกิดขึ้นได้ เพื่อให้เป็นตามที่กำหนดไว้ในฟังก์ชันนอลโมเดล 

9. Dynamic Model (ต่อ) เครื่องมือที่ใช้ • Sequence Diagram • State Diagram

10. Sequence Diagram • เป็นไดอะแกรมแสดงให้เห็นถึงลำดับขั้นตอนการทำงานเมื่อมีการเกิดเหตุการณ์หนึ่งๆ ขึ้นแล้ว object ต่างๆ มีการทำงานต่อไปอย่างไร • วัตถุประสงค์หลักของSequence diagram คือเพื่อให้ผู้เขียนโปรแกรมสามารถพัฒนาระบบได้ตามที่ออกแบบไว้ • Sequence diagram เป็นเครื่องมือที่ผู้เขียนโปรแกรมสามารถนำไปศึกษาและพัฒนาโปรแกรมหรือขยายขีดความสามารถของโปรแกรมต่อไป

11. State Diagram • เป็นไดอะแกรมที่แสดงให้เห็นถึงสถานะทั้งหมดที่เป็นไปได้ และเหตุการณ์ที่ทำให้เกิดการเปลี่ยนสถานะของ object แต่ละตัว 

12. การพัฒนาซอฟต์แวร์ (Software Development) • การแบ่งการพัฒนาซอฟต์แวร์ออกเป็น Phase ต่างๆ เรียกว่า Software development life cycle model • มีการกำหนดมาตรฐาน Software development life cycle ไว้หลายโมเดล เช่น Waterfall model, Rapid prototyping model, Spiral model, Concurrent development model และ Formal methods model

13. Waterfall model & OOAD • Waterfall model จะแบ่ง Phase การทำงานออกเป็น 5 Phase  คือ  • Definition :Phase ของการให้คำนิยามต่างๆ ของซอฟต์แวร์ • Analysis : Phase ของการวิเคราะห์ • Design : Phase ของการออกแบบ • Implement and testing : Phase ของการปฏิบัติและทดสอบ   • Maintenance: Phase ของการบำรุงรักษา

14. Waterfall model

15. Phase 1 : การให้คำนิยามของซอฟต์แวร์) • เป็น Phase ที่สำคัญที่สุด เนื่องจากเป็นการศึกษาถึงความต้องการต่างๆ ของระบบ  • ปัญหาหลักของระบบคืออะไร • ขอบเขตของระบบงานที่สนใจมีแค่ไหน • ความต้องการของผู้ใช้มีอะไรเพิ่มเติมบ้าง • มีคำศัพท์อะไรบ้างจะต้องมีการให้คำนิยามของศัพท์เหล่านั้นเพื่อความเข้าใจที่ตรงกัน  • ถ้าใน Phase นี้วิเคราะห์ความต้องการของระบบไม่ชัดเจน ก็จะมีผลถึง Phase ต่อไปของการดำเนินงานด้วย • ผลลัพธ์ที่ได้เป็นฟังก์ชันนอลโมเดล คือ Use Case Diagram  และพจนานุกรมของข้อมูล (Data Dictionary)

16. Use Case Diagram • Use case diagramเป็นแนวคิดของไอวาร์ จาคอบสัน (Ivar Jacobson) ซึ่ง OMG ได้รวมไว้ในมาตรฐานของ UML ด้วย   และได้มีวิธีการอื่นๆ นำแนวคิดนี้ไปใช้อย่างกว้างขวาง • Use case diagram เป็นสิ่งที่ใช้ในการแสดงความต้องการของระบบทั้งหมดในลักษณะที่ผู้ใช้งานสามารถเข้าใจได้ง่ายซึ่งเน้นในมุมมองของผู้ใช้ระบบกับการติดต่อระบบ   • Use case diagram จะถูกนำไปใช้ต่อไปในการออกแบบระบบใน Phase ต่างๆ ของการดำเนินงาน

17. สัญลักษณ์หลักที่ใช้ใน Use Case Diagram • Actor คือสิ่งที่อยู่ภายนอกระบบที่จะพัฒนาขึ้นทั้งหมด  ที่ต้องการแลกเปลี่ยนหรือส่งข้อมูลให้กับระบบ • Actor อาจจะเป็นคน ระบบ หรือโปรแกรมอื่นๆ ก็ได้ โดยมากจะเป็นผู้เริ่มทำงานกับuse case เช่นผู้ใช้ระบบ เป็นต้น

18. สัญลักษณ์หลักที่ใช้ใน Use Case Diagram สัญลักษณ์ของ Actor System Human Software

19. สัญลักษณ์หลักที่ใช้ใน Use Case Diagram • Use Case จะเป็นตัวแทนงานที่เกิดขึ้นในขั้นตอนต่างๆ   โดยจะใช้สัญลักษณ์เป็นรูปวงรี หรือวงกลม  • ถ้า Use Case ใดมีกรอบสี่เหลี่ยมสีเทาล้อมรอบแสดงว่ามี Diagram ย่อยที่ใช้อธิบายรายละเอียดของ Use Case ต่อไป

20. สัญลักษณ์หลักที่ใช้ใน Use Cases Diagram • ระบบ (System) เป็นตัวแทนของระบบ ซึ่งใช้สัญลักษณ์เป็นรูปสี่เหลี่ยม ที่ถูกกระทำโดย Actor ภายในระบบประกอบไปด้วย Use Case ต่างๆ ในที่นี้คือ ระบบสรรหาทรัพยากรบุคคล (Recruitment System)  • สัญลักษณ์ของ System  

21. สัญลักษณ์หลักที่ใช้ใน Use Cases Diagram Communication  เป็นการแสดงความสัมพันธ์หรือการติดต่อสื่อสารกัน (การรับและให้ข้อมูลข่าวสารแก่กันและกัน) ระหว่าง Actor และ Use Case ซึ่งอาจจะเป็นการสื่อสารแบบทางเดียวหรือ 2 ทางก็ได้ แสดงด้วยสัญลักษณ์เส้นที่มีหัวลูกศรสีดำ • Relationship  เป็นการแสดงความสัมพันธ์ระหว่าง Use Case กับ Use Case โดยใช้เส้นที่มีหัวลูกศรสีขาว ความสัมพันธ์ระหว่างuse caseมีได้  2 แบบ คือ Extends และ Uses  

22. สัญลักษณ์หลักที่ใช้ใน Use Case Diagram • Extends เป็นการเพิ่มการทำงานให้กับ Use Case โดยการเรียกใช้จากอีก Use Case หนึ่ง ลูกศรจะออกจาก Use Case ที่ถูกเรียกใช้งานไปยัง Use Case ที่ต้องการเพิ่มเติมการทำงาน และจะมีข้อความ <<extends>> ระบุอยู่ข้างๆ เส้น  • Uses เป็นการแสดงให้เห็นถึงการ Inherit หน้าที่การทำงานจาก Use Case หนึ่ง ไปอีก Use Case หนึ่ง ปลายลูกศรจะอยู่ที่ Use Case หลักที่จะถูกถ่ายทอดความสามารถออกไป โดยจะมีข้อความ <<uses>> ปรากฎอยู่ข้างๆ เส้น

23. Phase 2 :  การวิเคราะห์ (Analysis) • เป็นหลักสำคัญของศึกษาและออกแบบถึงโครงสร้างของระบบงาน ตามขอบเขตของปัญหาที่สนใจมีอะไรบ้างตามUse case diagramที่ได้จาก Phase ที่ 1 • ใน Phase นี้จะได้ผลลัพธ์เป็น Object Model • ผู้วิเคราะห์จะทำการรวบรวมคลาสที่สัมพันธ์กันขึ้นมาเป็น หมวดหมู่ เรียกว่า Component เพื่อเป็นการลดความซ้ำซ้อนของระบบ  • Component Diagram แสดงถึงความสัมพันธ์ระหว่างcomponent ต่างๆ 

24. Phase 2 :  การวิเคราะห์ (Analysis) componentจำแนกได้ 3 แบบ คือ SUBSYSTEM, MODULE และ CATEGORY  มีสัญลักษณ์ดังนี้ Category Module Subsystem

25. Class Name Attribute Operation Phase 2 :  การวิเคราะห์ (Analysis) • Objects ต่างๆ ที่มีคุณลักษณะ (Attribute), หน้าที่การทำงาน(Operation) และความสัมพันธ์(Relationship) ขั้นพื้นฐาน ซึ่งในแต่ละคลาสประกอบไปด้วยรายละเอียดพื้นฐาน 3 ส่วน ดังนี้

26. Phase 2 :  การวิเคราะห์ (Analysis) • Class Name : แสดงชื่อของคลาสที่กำหนดในระบบ • Attribute : เป็นการกำหนดคุณลักษณะทั้งหมดที่มีภายในคลาส บอกถึงรายละเอียดของข้อมูล (Attribute) ภายในคลาสเดียวกันจะไม่ซ้ำกัน แต่ชื่อข้อมูลในคลาสอาจจะไปซ้ำกับชื่อข้อมูลในคลาสอื่นได้ • Operation : เป็นส่วนที่ใช้อธิบายในคลาสนั้นมี Method อะไรบ้าง  มีการรับค่าชุดของตัวแปร (Argument) อะไรบ้างหรือมีการส่งค่าออกไปหรือไม่ 

27. ความสัมพันธ์ระหว่างคลาส (Relationship) • UML ได้เตรียมความสัมพันธ์ระหว่างคลาสไว้ จะมีความสัมพันธ์อยู่ 4 แบบ มีสัญลักษณ์ดังนี้ • Association : จะแสดงความสัมพันธ์ระหว่างคลาส จะมีได้ทั้งทางเดียว และ 2 ทาง มีสัญลักษณ์ดังนี้ •  ความสัมพันธ์แบบทางเดียว      • ความสัมพันธ์แบบสองทาง :

28. ความสัมพันธ์ระหว่างคลาส (Relationship) • Aggregation : เป็นรูปแบบพิเศษของ association คือเป็นความสัมพันธ์ระหว่าง Whole และ parts ของมัน คือ Wholeจะประกอบไปด้วย parts ต่างๆ ของมัน • การคงอยู่ของ parts จะต้องขึ้นกับ Whole  หรือจะเรียกความสัมพันธ์แบบนี้ว่า Whole-part มีสัญลักษณ์ดังนี้  • ความสัมพันธ์แบบ by Value • ความสัมพันธ์แบบ by Reference 

29. ความสัมพันธ์ระหว่างคลาส (Relationship) • Depends on : เป็นรูปแบบความสัมพันธ์แบบหนึ่งที่ใช้แสดงความสัมพันธ์กันระหว่างคลาส 2 คลาส ในแง่ที่คลาส หนึ่งเรียกใช้บริการของอีกคลาสหนึ่ง กล่าวคือคลาสของผู้ขอบริการขึ้นอยู่กับบริการของคลาสของผู้ให้บริการ แต่ไม่มีการขึ้นต่อกัน • ภายในโครงสร้างของคลาส มีสัญลักษณ์ดังนี้

30. ความสัมพันธ์ระหว่างคลาส (Relationship) • Generalization : ความสัมพันธ์แบบนี้ใช้แสดงความสัมพันธ์ระหว่างคลาสกับคลาส  ในแง่ที่คลาสหนึ่งถ่ายทอดคุณสมบัติและโครงสร้างจากอีกคลาส หนึ่ง เรียกคลาสที่ถูกถ่ายทอดว่า  Super Class และเรียกคลาสที่ทำการถ่ายทอดว่า Sub Class มีสัญลักษณ์ดังนี้ People Employee Student

31. Phase 3 :  การออกแบบ (Design) • การออกแบบระบบจะเริ่มเมื่อข้อมูลในช่วงของการวิเคราะห์เพียงพอที่จะเริ่มทำการปฏิบัติกับระบบแล้ว ในการออกแบบควรจะพิจารณาถึง  • ฮาร์ดแวร์ ว่า ระบบเป็น centralized หรือ distributed   ถ้าเป็นระบบแบบ distributed มีการจัดการกับระบบความปลอดภัยอย่างไร  จะใช้อะไรเป็นตัวติดต่อสื่อสาร  ต้องการ 0bject เพิ่มเติมเพื่อช่วยอำนวยความสะดวกในการติดต่อสื่อสารหรือไม่ เป็นต้น

32. Phase 3 :  การออกแบบ (Design) • ซอฟต์แวร์ ว่ามีคลาสพิเศษอะไรบ้างเพื่อสร้างหน้าต่างส่วนที่ติดต่อกับผู้ใช้(User interface)      • ต้องการคลาสเพิ่มเติมเพื่อช่วยอำนวยความสะดวกในเรื่องของความสัมพันธ์ระหว่างคลาสหรือไม่   • ถ้าในระบบต้องการใช้ระบบฐานข้อมูล   มีคลาสพิเศษที่ต้องใช้ในการติดต่อระหว่าง DBMS หรือไม่   • ต้องมีการลดความซ้ำซ้อนของข้อมูลหรือไม่   • ต้องทำการ Normalization หรือไม่มี • การใช้คลาสของบุคคลภายนอกหรือไม่   การติดต่อระหว่างobjectเป็นแบบ พร้อมกัน(synchronously) หรือ เกิดขึ้นไม่พร้อมกัน(asynchronously)

33. Phase 3 :  การออกแบบ (Design) • ผลลัพธ์ที่ได้จาก Phase นี้ • คลาสเพิ่มเติม • คลาสเกี่ยวกับการติดต่อกับผู้ใช้งานคือหน้าต่าง ต่างๆ (GUI classes) • คลาสที่จัดการและติดต่อกับฐานข้อมูล (database classes), • การสนทนาระหว่างคลาส(dialogue)   และประเภทของobjectที่ต้องการเป็นแบบถาวร(Persistent object) • ความสัมพันธ์ระหว่างobject, transaction ต่างๆ ที่สนใจ • Dynamic model จะมี Sequence Diagram และ State Diagram

34. Sequence Diagram • Sequence Diagram เป็นไดอะแกรมที่แสดงให้เห็นถึงการทำงานระหว่าง object ต่างๆ ตามการส่งข้อความ(Message) และเมื่อเหตุการณ์(Event) ต่างๆ ได้เกิดขึ้น  ซึ่งผู้เขียนโปรแกรมจะใช้ไดอะแกรมตัวนี้เป็นตัวช่วยเพื่อที่จะได้เขียนโปรแกรมให้ได้ตามที่ได้ออกแบบไว้

35. สัญลักษณ์ที่ใช้ในSequence Diagram

36. สัญลักษณ์ที่ใช้ในSequence Diagram • Object :  คือ Instance ของ Class ที่ทำหน้าที่รับ-ส่งข้อความ (Message) จาก Object อื่นๆ และทำการตอบสนองตามข้อความนั้นๆ เพื่อให้เกิดการทำงานในขั้นตอนต่างๆ ของระบบ  โดยจะใช้สัญลักษณ์เป็นเส้นตรงแนวตั้งและมีชื่อของ object และคลาส กำหนดอยู่ด้านล่าง •  Message :  เป็นข้อความที่ส่งไปมาระหว่าง object เพื่อสั่งให้ object ทำงานตามที่กำหนด กล่าวได้ว่า Message  คือชื่อของ Method ของ object ที่ถูกเรียก

37. สัญลักษณ์ที่ใช้ในSequence Diagram • Message จะประกอบไปด้วยส่วนประกอบต่างๆ ดังต่อไปนี้ • Result Name :  คือ ตัวแปรที่จะจัดเก็บค่าที่ได้จากการส่งข้อความ(Message)   • Parameters : คือ Argument ต่างๆ ที่ส่งให้กับ object เพื่อทำงานตาม Method ที่กำหนดด้วย Message นั้นๆ   • Return Type :  คือ ประเภทของข้อมูลที่ส่งกลับมาหลังจากการทำงานของการส่ง Method นั้นๆ ถ้า Method นั้น กำหนดว่ามีการส่งค่ากลับมา • Constraint  : คือ เงื่อนไขในการส่ง Message

38. ตัวอย่าง Sequence Diagram การเปิดหน้าต่างเพื่อทำการยืนยัน

39. State Diagram • State Diagram เป็นไดอะแกรมที่แสดงให้เห็นว่า object หนึ่งๆ สามารถมีสถานะใดได้บ้าง และเกิดเหตุการณ์ใดจึงมีการเปลี่ยนสถานะ

40. สัญลักษณ์ใน State Diagram

41. ตัวอย่าง State Diagramของobjectจองห้องพัก

42. Phase 4 :  Implement และ testing • Implement และ testing เป็น Phase ของการเขียนโปรแกรมและทดสอบให้ได้เป็นไปตามการวิเคราะห์ • โดยจะใช้การโปรแกรมเชิงวัตถุ (Object Oriented Programming) ซึ่งการแปลงจากการวิเคราะห์และออกแบบไปเป็นการโปรแกรมเชิงวัตถุ • ส่วนการ Testing  ก็เป็นการตรวจสอบคุณภาพของโปรแกรมที่เราทำขึ้นมาโดยวิธีการตรวจสอบ object (Object Testing) 

43. Phase 4 :  Implement และ testing • การแปลงจากการวิเคราะห์และออกแบบไปเป็นการโปรแกรมสามารถเชิงวัตถุทำได้ไม่ยุ่งยากเนื่องจาก ทั้งการวิเคราะห์และออกแบบเชิงวัตถุ กับการโปรแกรมเชิงวัตถุ นั้นสนับสนุนหลักการของ Object-Oriented ด้วย คือ 1. Encapsulation : การปกป้องข้อมูล 2. Inheritance : การสืบทอดคุณสมบัติ 3. Polymorphism : การที่ได้รับข้อความ(Message) เดียวแล้วสามารถตอบสนองได้หลายรูปแบบ

44. ภาษาที่สนับสนุนหลักการของ Object-Oriented • C++ • Smalltalk • Eiffel • Object C • Object Pascal (หรือ Delphi) • Java 

45. การวิเคราะห์และออกแบบระบบเชิงวัตถุ การโปรแกรมเชิง (UML notation) วัตถุ (ภาษาจาวา) Component  เป็น package ในภาษา Java Class Class Attribute Attribute method  method  Attribute ต่างๆ ถ้าเป็น read only  เป็น set method  Attribute ต่างๆ ถ้าเป็น read-write เป็น get, set method Inherit  Sub class จะต้อง extends จาก Super Class

46. การวิเคราะห์และออกแบบระบบเชิงวัตถุ การโปรแกรมเชิง (UML notation) วัตถุ (ภาษาจาวา) ถ้า Component มีการอ้างอิงถึง  จะต้อง import package นั้น  Module หรือ Component อื่นๆ  access modifier : public (+)  เป็น public ในจาวา private (-)                         เป็น package ในจาวา protected (#) เป็น protected ในจาวา implementation (?) คือการกำหนด ณ ขณะ Implement เราอาจจะใช้ private ในภาษาจาวาก็ได้แล้ว แต่ขอบเขตกรณีที่เราศึกษา

47. ตัวอย่าง คลาส Cancel • มี Attribute อยู่ 1 ตัว คือ remark • มีประเภทข้อมูลเป็น String และมี Method อยู่ 1 Method คือ save คืนค่า boolean กลับ   • คลาส Cancel Inherite จากคลาส Transaction

48. ตัวอย่าง คลาส Cancel

49. ตัวอย่างโปรแกรม Javaของ คลาส Cancel public class Cancel extends Transaction {      private String remark;    public Cancel() {     super();      }      public String get_remark() {       return remark;      }      public void set_remark(String value) {       remark = value;      }      public boolean save() {          ?     }    } //end class Cancel

50. Phase 5 : Maintenance • ในการ Maintenance นั้นจะทำได้สะดวกกว่า • ยกตัวอย่างเช่นถ้ามีการเปลี่ยนแปลงโครงสร้างของคลาส • Cancel ก็จะทำการเปลี่ยนแปลงและ Implement คลาสนี้ใหม่เท่านั้น คลาสอื่นๆ ที่เกี่ยวข้องไม่จำเป็นต้องเปลี่ยนแปลง