Usecase diagram การย ม ค นหน งส อ

2 | P a g e ค ำน ำ หนงัสือเล่มน้ีจดัทำ ข้ึนเพื่อให้นกัศึกษำไดศ้ึกษำเกี่ยวกบักำรสร้ำงแบบจ ำลองและโปรแกรมมีควำมรู้ ควำมเข้ำใจเกี่ยวกับหลักกำรของโปรแกรมเชิงวัตถุซ่ึงหนำ้หำครอบคลุมต้งัแต่หลกัสำ คญัแนวคิดกำรออกแบบ โปรแกรมเชิงวัตถุ กำรสร้ำงแบบจ ำลอง ด้วยแผนภำพคลำสพร้อมยกตัวอย่ำง แผนภำพคลำสกำรเขียนโปรแกรม และอธิบำยอย่ำงละเอียด เน้ือหำภำยในหนงัสือเล่มน้ีมีกำรอธิบำยถึงกำรเขียนกำรออกแบบกำรตอบโต้ระหว่ำงอ็อบเจกต์โดย เน้ือหำบทที่8 เป็นพ้ืนฐำนกำรเขียนกำรเขียนกำรออกแบบกำรตอบโต้ระหว่ำงอ็อบเจกต์ในกรณีที่ผู้อ่ำนยังไม่รู้ วิธีกำรเขียนโปรแกรมแนะน ำให้อ่ำนเรียงตำมบทเนื่องจำกบทหลัง ๆ จะต้องน ำควำมรู้จำกบทแรกมำ ประกอบกำรทำ ควำมเขำ้ใจแต่อยำ่งไรก็ตำมหนงัสือเล่มน้ีไดค้รอบคลุมเน้ือหำกำรกำรเขียนกำรออกแบบกำร ตอบโต้ระหว่ำงอ็อบเจกต์ ผเู้ขียนหวงัเป็นอยำ่งยงิ่วำ่หนงัสือเล่มน้ีช่วยสร้ำงควำมรู้ควำมเขำ้ใจใหแ้ก่ผอู้่ำนเพื่อให้ สำมำรถเริ่มตน้กำรเขียนโปรแกรมเชิงวตัถุไดอ้ยำ่งมนั่ใจและเป็นพ้ืนฐำนกำรเรียนรู้วิชำระดบัสูงต่อไป

3 | P a g e สำรบัญ หน้ำที่ กำรออกแบบอินเทอร์เฟซ 4 กำรเชื่อมควำมสัมพันธ์ 5 สเตอริโอไทป์ (Stereotype) 6 ควำมสัมพนัธ ์ ระหวำ่ง Use Case 8 ควำมสัมพันธ์แบบ Include 9 ไดอะแกรม Diagram 10 -13 บุคลำกรที่เกี่ยวข้องในไดอะแกรมแต่ละประเภท 14 สรุปประเด็นส ำคัญ 15

4 | P a g e การออกแบบอินเทอร์เฟซ หลักกำรออกแบบอินเทอร์เฟซหรือ UI หลักๆ ประกอบด้วย 1.1 User Familiarityควำมคุ้นเคยของผู้ใช้เช่น ระบบส ำนักงำนควรค ำนึงถึงเอกสำร จดหมำยแล้ว น ำมำแทนที่ไฟล์ต่ำงๆ 1.2 Consistencyควำมเหมำะสมและควำมมนั่คง เช่น คำ สั่งและเมนูควรมีรูปแบบเดียวกนั 1.3 Minimal Surprise ถำ้คำ สั่งเป็นคำ สั่งที่คุน้เคยแลว้ผใู้ชจ้ะมีควำมสำมำรถคำดกำรณ์กำรทำ งำนของ คำ สั่งได้ 1.4 Recoverability ควำมยืดหยุ่น ผู้ใช้อำจท ำงำนพลำด ควรมีกำรกู้คืนข้อมูลได้ และรวมไปถึงกำรลบ กำรสร้ำง กำรย้ำย และอื่นๆ 1.5 User Guidance แนะน ำผู้ใช้มีกำรช่วยเหลือหรือแนะน ำ กำรใช้งำนระบบ หรือ Help 1.6 User Diversity ควำมหลำกหลำยของผู้ใช้ ควรค ำนึงถึงสถำนที่ ควำมเป็ นอยู่ ลักษณะของแต่ละ พ้ืนที่ที่เกี่ยวขอ้งกบัระบบ รูปแบบการโต้ตอบระหว่างผู้ใช้กบัระบบ ในกำรออกแบบ User interface จะพิจำรณำประสิทธิภำพ ในกำรโต้ตอบระหว่ำงผู้ใช้กับระบบเป็ นหลัก 2.1กำรโตต้อบดว้ยกำรพิมพค์ำ สั่ง (Command Line Interaction) 2.2 กำรโตต้อบดว้ยเมนูคำ สั่ง (Manu Interaction) 2.3 กำรโต้ตอบด้วยแบบฟอร์ม (From Interaction) 2.4 กำรโต้ตอบผ่ำนวัตถุ (Object-Based Interaction) 2.5 กำรโต้ตอบด้วยภำษำมนุษย์ (Natural Language Interaction) 1. ซอฟต์แวร์จ ำแนกเสียง (Speech Recognition)จะมีส่วนช่วยให้ที่มีควำมพิกำรในด้ำนกำรใช้งำน เมำส์หรือคีย์บอร์ด 2. ซอฟต์แวร์ขยำยภำพ (Screen Magnification)จะมีส่วนใช้ผู้ที่มีควำมบกพร่องในระยะกำรมองเห็น

5 | P a g e 3. ซอฟตแ์วร์ในกำรอ่ำนเน้ือหำบนจอScreen Reader จะมีส่วนช่วยอย่ำงสูงส ำหรับผู้พิกำรทำงด้ำน กำรมองเห็น โดยจะเก็บกำรกระทำ ต่ำงๆ ที่เกิดข้ึนบนหนำ้จอและแสดงออกดว้ยทำงใดทำงหน่ึง ใหแ้ก่ผใู้ชไ้ดร้ับ รู้ 4. ซอฟต์แวร์ช่วยแปล (Translation Software)จะช่วยในกำรเขำ้ถึงแก่บุคคลใดๆ ที่มีปัญหำดำ้นกำร รับรู้ทำงภำษำ การเชื่อมความสัมพันธ์ กำรเชื่อมระหว่ำง Actor กับ Use Case จะใช้เส้นแสดงควำมสัมพันธ์ แสดงควำมเกี่ยวข้องปฏิสัมพันธ์ หมำยถึง ควำมสัมพันธ์ที่มีกำรติดต่อสื่อสำรกัน 3.1 ควำมสัมพันธ์ระหว่ำง Actor กับ User Case สำมำรถแบ่งตำมควำมสัมพันธ์ แบบทิศทำงเดียวได้ 3กรณีดงัน้ี Actor เป็นผู้ได้รับข้อมูลจาก Use case จะใช้สัญลักษณ์เช่นนี้ Actor เป็นผู้ได้รับข้อมูลจาก Use case จะใช้สัญลักษณ์เช่นนี้ Actor เป็นผู้ได้รับข้อมูลจาก Use case จะใช้สัญลักษณ์เช่นนี้

6 | P a g e 3.2 ควำมสัมพันธ์ระหว่ำง Actor กับ Actorจะมีควำมสัมพันธ์ในรูปแบบที่สำมำรถสืบทอดคุณสมบัติ บทบำทหน้ำที่ของ Actor จำก Actor Superclass ไปยัง Actor Subclass ซึ่งเรียกว่ำ Generalization/Specialization Relationship ตัวอย่ำงเช่น Generalization/Specialization Relationship คนคุมงำน (Supervisor) เป็ นคนงำนพิเศษที่มีหน้ำที่พิเศษมำกกว่ำคนงำน (Worker) สเตอริโอไทป์ (Stereotype) สเตอริโอไทป์ Stereotype เป็นเทคนิคในกำรใช้เพิ่มชนิดสัญลกัษณ์ในภำษำ UML จำกสัญลักษณ์เดิมที่ มีอยู่แล้วให้เป็นสัญลักษณ์ชนิดใหม่ Worker Superviso r <> <>

7 | P a g e ความสัมพันธ์ระหว่าง Use Case ควำมสัมพันธ์ของ Use Case เป็นควำมสัมพนัธ์ที่เกิดข้ึนระหวำ่ง Use Case กับ Use case ซึ่งมีสัญลักษณ์ ที่ใช้แทนควำมสัมพันธ์3รูปแบบ 5.1 ควำมสัมพันธ์แบบ Generalization/Specialization เป็ นควำมสัมพันธ์ Use Case คล้ำยกับ ควำมสัมพันธ์ระหว่ำงคลำส (ในเรื่อง Abstraction) จะใช้ Generalization/Specializationกรณีที่ต้องแสดงควำมสัมพันธ์ในเชิงกำรจ ำแนกแยกประเภท ของ Use Case มองเป็ น Use Case เป็ นคลาส Parent Use Case Parent Use Case Validate User Verify Password Fingerprint Recognition

8 | P a g e ความสัมพันธ์แบบ Include (หรือ User) เป็ นควำมสัมพันธ์ในกรณีที่ Use Case หนึ่งไปเรียกใช้หรือดึงกิจกรรมของอีก Use Case หนึ่ง เพื่อให้ กิจกรรมน้นัเกิดจริงในตนเอง ความสัมพันธ์แบบ Extend หรือ Extends ก่อน V 2.0 เป็ นควำมสัมพันธ์ที่ Use Case หนึ่งไปมีผลต่อกำรท ำงำนตำมปกติของอีก Use Case หนึ่ง Extending Use Case เป็ น Use Case ที่มำ extend Base Use Case ซึ่งจะมีผลในกำรด ำเนินงำนของ Base Use Case ถูก รบกวนหรือมีกำรสะดุด หรือมีกำรเปลี่ยนแปลงกิจกรรมไป <> Based Use Case Included Use Case i <> ลักษณะการใช้งานชี้ไปยัง Use Case ที่ถูกเรียกใช้งาน <> Based Use Case Extending Use Case <> ลักษณะการใช้งานชี้ไปยัง Use Case ที่ถูกเรียกใช้Extend

9 | P a g e ไดอะแกรม Diagram เมื่อใช้UML วำดรูปองค์ประกอบของซอฟต์แวร์ จะวำดอยู่ในไดอะแกรม ซึ่งอำจให้ควำมหมำยของ ไดอะแกรมวำ่เป็นกระดำษร่ำงแบบสถำปนิกใชใ้นกำรออกแบบสิ่งก่อสร้ำงก็ได้ใน UML แบ่งไดอะแกรม ออกเป็ น 9 ชนิด โดยแยกตำมวัตถุประสงค์กำรใช้งำนและช่วงเวลำที่น ำไปใช้ในระยะเวลำกำรพัฒนำระบบได้ ดงัน้ี สำมำรถแยกไดอะแกรมได้เป็ น 2 ประเภทใหญ่ๆ คือ Static Diagram และ Dynamic Diagram ส่วนที่ เป็ น Static Diagram ใชส้ำ หรับออกแบบโครงสร้ำง เปรียบเสมือนกบัโครงของตึก หรือ สิ่งก่อสร้ำงที่ใชอ้ยใู่น อุตสำหกรรมก่อสร้ำง และส่วนที่เป็น Dynamic Diagram ใช้ส ำหรับออกแบบกำรท ำงำนขององค์ประกอบ ต่ำงๆ ส ำหรับ Use Case Diagram ที่ไม่ได้จัดอยู่ในประเภท Static หรือ Dynamic เนื่องจำก Use Case ไม่ได้ มี วัตถุประสงค์ เพื่อใช้ออกแบบองค์ประกอบในระบบ แต่ใช้ส ำหรับบรรยำย ถึงควำมต้องกำรของระบบว่ำระบบ ที่จะสร้ำงข้ึนมำมีควำมสำมำรถอะไรที่ผใู้ชส้ำมำรถใช้งำนได้ Requirement Capturing Use Case Diagram Class Diagram Object Diagram Static Diagram Component Diagram Deployment Diagram Sequence Diagram Collaboration Diagram Dynamic Diagram Statechart Diagram Activity Diagram

10 | P a g e ประเภทของไดอะแกรม ไดอะแกรมแต่ละประเภท ท ำงำนแตกต่ำงกัน มีวัตถุประสงค์ของกำรท ำงำนที่แตกต่ำงกัน 7.1 Use Case Diagram Use Case Diagram มีวัตถุประสงค์เพื่อแสดง ให้เพื่อเห็นสถำนกำรณ์ต่ำงๆ ที่ผู้ใช้สำมำถใช้งำนระบบแต่ ละสถำนกำรณ์ ที่ระบบสำมำรถ บริกำรให้ผู้ใช้ส ำเร็จลุล่วง ตำมที่ต้องกำร เรียกว่ำ Use Case ล ำดับเหตุกำรณ์ที่ สำมำรถบรรยำยได้ว่ำผู้ใช้ โต้ตอบกับระบบอย่ำงไรบ้ำง เพิ่ม ลบ แก้ไข ข้อมูล ส ำรองข้อมูล นักศึกษำ Login เข้ำสู่ระบบ รับช ำระ ค่ำลงทะเบียน กรอกข้อมูล รำยวิชำ ค้นหำข้อมูล ตรวจสอบกำร ลงทะเบียน บันทึกผล กำรเรียน พิมพ์ ใบเสร็จรับเงิน

11 | P a g e 7.2 Class Diagram Class Diagram มีวัตถุประสงค์เพื่อใช้บรรยำยโครงสร้ำงของคลำสที่ประกอบกันอยู่ในระบบงำนว่ำ คลำสอะไรบ้ำงถึงแม้ว่ำ Class Diagram จะแสดงให้เห็นถึงโครงสร้ำงคลำส แต่ในขณะที่ระบบงำนก ำลัง ดำ เนินกำรคลำสจะตอ้งถูกนำ ไปสร้ำงเป็นวตัถุแลว้จึงจะใชง้ำนวตัถุดงัน้นัเมื่อเห็นรูปคลำสไดอะแกรมจะตอ้ง สำมำรถเขำ้ใจถึงส่วนประกอบของวตัถุที่สร้ำงข้ึนจำกคลำสรวมท้งัคุณลกัษณะและเมทอ็ดที่อยใู่นวตัถุที่ถูกสร้ำง ข้ึนจำกคลำส

12 | P a g e 7.3 Object Diagram Object Diagram มีวตัถุประสงคเ์พื่อแสดงวตัถุที่ถูกสร้ำงข้ึนจำกคลำสและจำ ลองควำมสัมพนัธ์ระหวำ่ง วันที่ได้ออกแบบควำมสัมพันธ์ไว้ใน Class Diagram น้นัสำมำรถเกิดข้ึนไดจ้ริงในระบบงำนหรือไม่ดงัน้นัหนำ้ที่ Object Diagram จึงใช้ส ำหรับพิสูจน์โครงสร้ำงที่ร่ำงไว้ใน Class Diagram ว่ำสำมำรถน ำมำสร้ำงเป็ นระบบได้ ตรงกับที่ต้องกำรจริง ๆ นักออกแบบระบบที่ยังไม่มีประสบกำรณ์เพียงพอจะต้องพยำยำมเขียน Object Diagram ควบคู่ไปกบัคลำสไดอะแกรมดว้ยเสมอทุกคร้ังเพื่อใหแ้น่ใจวำ่ ไดอ้อกแบบ Class Diagram ไว้ถูกต้อง

13 | P a g e 7.4 Sequence Diagram Sequence Diagram มีวตัถุประสงคเ์พื่อแสดงใหเ้ห็นลำ ดบัของกำรสั่งงำนวตัถุใหท้ำ งำนไปจนกระทงั่ Use Case ซึ่งในเสร็จงำนหนึ่งงำนปกติมักจะใช้ Sequence Diagram บรรยำยถึงลำ ดบัเหตุกำรณ์ที่เกิดข้ึนในหน่ึง Use Case จะเป็นกรณีที่เกิดข้ึนกบัระบบงำนและภำยใน Use Case จะต้องมีล ำดับเหตุกำรณ์ที่ผู้ใช้จะใช้ Sequence Diagram จะแสดงให้เห็นว่ำเมื่อผู้ใช้มำใช้งำนตำม Use Case จะทำ ให้ระบบตอ้งไปสั่งงำนวตัถุตวัไหน บ้ำงให้ท ำงำนต่อเนื่องกนัเป็นลำ ดบัไปจนกระทงั่ ไดผ้ลลพัธ์ตำมที่Use Case ไดก้ำ หนดไวด้งัน้นังำนระบบจำก เมื่อนักศึกษำวิทยำลัยแห่งหนึ่งต้องกำรลงทะเบียนในรำยวิชำที่ต้องกำรเจ้ำหน้ำที่ทะเบียนจะเข้ำสู่ระบบแล้ว กรอกขอ้มูลกำรลงทะเบียนผ่ำนทำงเวบ็เพจที่ระบบไดจ้ดัเตรียมไวใ้หห้ลงัจำกน้นัที่หนำ้เวบ็จะสั่งงำนวตัถุ Payment Forminterface ให้สร้ำงวัตถุ Payment Control ข้ึนพร้อมกบั ใส่รำยละเอียดคือวตัถุRegistrationForm ที่ จ ำเป็ นต้องกำรลงทะเบียนเข้ำไปในวัตถุ Registration Form หลงัจำกสั่งใหว้ตัถุRegistration Form พิมพ์ออกมำ ทำงเครื่องพิมพ์แล้วจึงบันทึกใบลงทะเบียนไว้ในระบบงำนพร้อมกับพิมพ์ใบเสร็จให้กับนักศึกษำเพื่อเป็ น หลักฐำนในกำรลงทะเบียน Sequence Diagram ถือเป็ นไดอะแกรมที่มีควำมส ำคัญมำกพอ ๆ กับ Class Diagram เนื่องจำก Sequence Diagram จะบอกให้ทรำบว่ำวัตถุแต่ละตัวในระบบมีกำรท ำงำนร่วมกันอย่ำงไรและใครท ำ ก่อนท ำหลังซึ่งปกติแล้ว Class Diagram จะไม่ระบุถึงรำยละเอียดในกำรปฏิบัติอย่ำงใน Sequence Diagram

14 | P a g e บุคลากรที่เกยี่วข้องในไดอะแกรมแต่ละประเภท เนื่องจำกไดอะแกรมแต่ละประเภทมีวัตถุประสงค์กำรใช้งำนต่ำงกันและในทีมพัฒนำระบบจะ ประกอบดว้ยบุคลำกรในบทบำทต่ำง ๆ ที่มีควำมเชี่ยวชำญทำงเทคนิคที่ต่ำงกนัไปดงัน้นับุคคลที่อยใู่นทีมพฒันำ อำจไม่จำ เป็นตอ้งเขียนไดอะแกรมท้งั 9 ไดอะแกรมไดอ้ยำ่งสมบูรณ์ท้งัหมด แต่จะใหเ้ฉพำะบุคคลบำงบทบำท เท่ำน้นัที่จะมีหนำ้ที่เขียนไดอะแกรมในแต่ละประเภท

15 | P a g e สรุปประเด็นส าคัญ กำรออกแบบอินเทอร์เฟซหรือ UI จะต้องใช้บัญชีควำมต้องกำรจำกประสบกำรณ์และควำมสำมำรถของ ผู้ใช้ระบบนักออกแบบควรทรำบข้อ จ ำกัด ทำงกำยภำพและจิตใจของผู้คนมีรูปแบบของกำรโต้ตอบระหว่ำงผู้ใช้ กับระบบในกำรออกแบบ User Interface จะพิจำรณำประสิทธิภำพในกำรโต้ตอบระหว่ำงผู้ใช้กับระบบเป็ นหลัก ซึ่งรูปแบบของกำรโต้ตอบมีหลำยรูปแบบควำมสัมพันธ์ระหว่ำง Actor กำรเชื่อมระหว่ำง Actor กับ Use Case จะ ใช้เส้นแสดงควำมเกี่ยวข้องปฏิสัมพันธ์ควำมสัมพันธ์ที่มีกำรติดต่อสื่อสำรกันควำมสัมพันธ์ของ Use Case เป็ น ควำมสัมพนัธ์ที่เกิดข้ึนระหว่ำง Use Case กับ Use Case ซึ่งมีสัญลักษณ์ที่ใช้แทนควำมสัมพันธ์ไดอะแกรมเมื่อใช้ UML วำดรูปองค์ประกอบของซอฟต์แวร์จะวำดอยู่ในไดอะแกรมซึ่งอำจให้ควำมหมำยของไดอะแกรมว่ำเป็ น กระดำษร่ำงแบบที่สถำปนิกใชใ้นกำรออกแบบสิ่งก่อสร้ำงก็ไดป้ระเภทของไดอะแกรมกำรทำ งำนของ ไดอะแกรมแต่ละประเภทท ำงำนแตกต่ำงกันโดยมีวัตถุประสงค์ของกำรท ำงำนที่แตกต่ำงกัน