วัตถุประสงค                                                    เพื่อใหผูเรียนสามารถ                                    ...
แบบจําลอง (Model)                                     แบบจําลองการสรางแบบจําลอง คือกระบวนการสรางตัวแทน             ประโย...
แบบจําลองในการวิเคราะหและ                 เทคนิคการสรางแบบจําลองที่ดี                                                   ...
กิจกรรมในการกําหนดความ                                                                     ขอมูลและผลลัพธ               ...
การกําหนดปญหาและขอบเขต                               กําหนดปญหาและขอบเขตกําหนดนิยามเบื้องตนของปญหาที่ตองแกไข         ...
การสัมภาษณ                                          การสัมภาษณขั้นตอน                                               การเ...
การสัมภาษณ                                                  การสัมภาษณการดําเนินการสัมภาษณ                             ...
Joint Application                 หองประชุม JAD                                                                          ...
การวิเคราะหเอกสาร                                      การสังเกตการณใหขอมูลเกี่ยวกับระบบปจจุบัน (“as-is” system)     ...
ความตองการทีมาจากระบบ                                ่                                        ความตองการทีมาจากระบบ     ...
ความตองการเชิงฟงกชัน                             ความตองการแบไมเปนฟงกชัน                 (Functional Requirements)...
ยูสเคส (Use Case)                                    ยูสเคสโมเดลยูสเคสคือชนิดของความสามารถของระบบจาก                   ยูส...
สัญลักษณสําคัญในแผนภาพ                 แผนภาพยูสเคส                                                                      ...
พิจารณาหาแอคเตอร                                                      พิจารณาหายูสเคส     ฮารดแวรหรือระบบภายนอกใดที่ใช...
การหา Exceptional flow                                     เขียนคําอธิบายยูสเคส  พิจารณาการกระทําที่ถูกเลือกปฏิบัติ แทนการ...
ขอแนะนําในการสรางแบบจําลอง                               ขอดีของการใชยูสเคสในการ                  ยูสเคส              ...
Unit03
Upcoming SlideShare
Loading in …5
×

Unit03

658 views
603 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
658
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Unit03

  1. 1. วัตถุประสงค เพื่อใหผูเรียนสามารถ อธิบายความหมายของความตองการ อธิบายความสําคัญของการกําหนดความตองการ อธิบายประเภทของความตองการ อธิบายกิจกรรมในกระบวนการกําหนดความตองการ อธิบายเทคนิคในการรวบรวมความตองการหนวยที่ 3: การกําหนดความตองการ อธิบายการวิเคราะหความตองการ (Requirements Determination) อธิบายสรางยูสเคสโมเดลOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 1 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 2 การวิเคราะหและออกแบบระบบ ซอฟตแวร การพัฒนาระบบทีประสบความสําเร็จ ่ สรางระบบที่ตรงกับความตองการ ภายในงบประมาณ ภายในระยะเวลา การวิเคราะหและออกแบบระบบทีมประสิทธิภาพ ่ ี ชวยหลีกเลี่ยงความลมเหลว วิเคราะห = การทําความเขาใจกับระบบที่จะสราง การสรางแบบจําลอง (Modeling) ออกแบบ = กําหนดรูปแบบการสรางระบบOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 3 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 4 1
  2. 2. แบบจําลอง (Model) แบบจําลองการสรางแบบจําลอง คือกระบวนการสรางตัวแทน ประโยชนคือเพื่อแสดงโดเมนหรือซอฟตแวร แบบจําลองสรางไดงายและเร็วแบบจําลอง (model) แสดงภาพที่สมบูรณของ แบบจําลองสามารถใชในการจําลองสถานการณ เพื่อระบบจากมุมมองดานหนึ่ง เรียนสิ่งที่มันกําลังแสดงอยูเพิ่มเติมการพัฒนาระบบมักใชแบบจําลองหลายตัวเพื่อ แบบจําลองสามารถวิวัฒนไปพรอมกับการเรียนรูงานหรือ ปญหาแสดงภาพของระบบในมุมมองที่ตางๆ  เราสามารถเลือกรายละเอียดที่จะนําเสนอและไมนําเสนอ ในแบบจําลอง แบบจําลองสามารถแสดงสิ่งที่มีจริงและจินตนาการใน ทุกดานไดOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 5 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 6 แผนภาพ (Diagram) แผนภาพแบบจําลองมักประกอบดวยเอกสารขอความและแผนภาพ กฎทีเปนมาตรฐานสําหรับการวาดแผนภาพมี ่นักวิเคราะหและนักออกแบบใชแบบจําลองเชิงแผนภาพ ความสําคัญตอการเขาใจเพื่อ สื่อสารความคิด UML (Unified Modeling Language) เปนภาษา สรางความคิดหรือความเปนไปไดใหมๆ มาตรฐานในการสรางแผนภาพเพื่อการพัฒนาระบบ ทดสอบความคิดหรือทํานาย เชิงวัตถุ เพื่อทําความเขาใจโครงสรางและความสัมพันธแผนภาพ (diagram) แสดงสวนใดสวนหนึ่งของระบบแบบจําลองหนึ่ง อาจใชแผนภาพหลายแบบในการนําเสนอ มักใชหลายแผนภาพOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 7 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 8 2
  3. 3. แบบจําลองในการวิเคราะหและ เทคนิคการสรางแบบจําลองที่ดี ออกแบบเนนการนําเสนอที่ไมซบซอน ั แบบจําลองยูสเคส (Use case model)เนนความสอดคลองภายในชุดแผนภาพ แบบจําลองโครงสราง (structural model)เนนความสมบูรณ แบบจําลองพฤติกรรม (dynamic and behavioralเนนการนําเสนอแบบเปนลําดับชั้น model)OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 9 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 10 ความตองการและขอกําหนด เพื่อใหไดระบบที่ตรงตามความตองการ คือ แกปญหาได ตองทําความเขาใจกับปญหา สภาพแวดลอมในการดําเนินธุรกิจ เทคโนโลยีทใชได ี่ เพื่อใหตัดสินใจเลือกกระทําทีเหมาะสมในการ ่ แกปญหา การกําหนดความตองการOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 11 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 12 3
  4. 4. กิจกรรมในการกําหนดความ ขอมูลและผลลัพธ ตองการการวิเคราะหโดเมน (domain analysis) ขอมูลเขา (input)การกําหนดปญหา (defining the problem) เอกสารริเริ่มโครงการ (project initiation document) ผลลัพธ (deliverables)การรวบรวมความตองการ เอกสารการวิเคราะหโดเมน (domain analysis(requirements gathering) document)การวิเคราะหความตองการ (requirements บทนิยามความตองการ (requirement definition)analysis) ยูสเคสโมเดล (use case model)การระบุความตองการ ตนแบบสวนติดตอผูใช (user interface prototype)(requirements specification) แผนการดําเนินงานที่ปรับปรุง (refined work plan) สถาปตยกรรมเบื้องตน (initial system architecture)OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 13 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 14 การวิเคราะหโดเมน เอกสารการวิเคราะหโดเมนกระบวนการเรียนรูเกี่ยวกับภูมหลังของระบบ ิ บทนํา (Introduction) อภิธานศัพท (Glossary)เพื่อใหเขาใจปญหา และตัดสินใจไดดีในการ ความรูทั่วไปเกี่ยวกับโดเมน (General knowledge aboutวิเคราะหความตองการ และขั้นตอนอื่นๆ the domain)โดเมน (domain) = แวดวงในการดําเนินงานหรือ ลูกคาและผูใช (Customer and user)เทคโนโลยีทคาดวาจะใชซอฟตแวร ี่ สภาพแวดลอม (The environment)ประโยชน งานหรือระเบียบวิธีดําเนินงานในปจจุบัน (Task and procedures currently performed) การพัฒนาที่รวดเร็ว ซอฟตแวรคูแขง (Competing software) ระบบที่ดีขึ้น ความคลายคลึงระหวางโดเมนและองคกร (Similarities สามารถคาดการณการขยายของระบบได across domains and organizations)OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 15 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 16 4
  5. 5. การกําหนดปญหาและขอบเขต กําหนดปญหาและขอบเขตกําหนดนิยามเบื้องตนของปญหาที่ตองแกไข  นิยามของปญหา (problem statement)ปญหา ถูกใชในการประเมินระบบ ความยุงยาก นิยามที่ดีตองสั้นและกระชับ โอกาส กําหนดปญหาที่แนชัดเพื่อชวยจํากัดขอบเขตทางแก คํานึงถึงเปาหมายระดับสูงของผูใช การพัฒนาซอฟตแวร สะทอนปญหาที่แทจริง ซื้อซอฟตแวร ขอบเขต (Scope) แกไขโดยไมใชซอฟตแวร หนาที่รับผิดชอบของระบบ งานหรือการกระทําที่มีผลตอการบรรลุเปาหมายของผูใชOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 17 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 18 การรวบรวมความตองการ เทคนิคการรวบรวมความตองการ (Requirement Gathering Techniques)การรวบรวมขอมูลเกี่ยวกับลักษณะที่ตองการของ การสัมภาษณ (Interviewing)ระบบจากบุคคลที่เกียวของ ่ การสังเกตการณ (Observation)ประโยชน การศึกษาเอกสาร (Document sampling) ไดขอมูลเพื่อใชในการวิเคราะหเพื่อกําหนดความ การใชสอบถาม (Questionnaires) ตองการ Joint Application Development (JAD) ชวยในการสรางการรองรับในการพัฒนาระบบในองคกร การระดมความคิด (Brain storming)ความทาทาย การทําตนแบบ (Prototyping) การเลือกบุคคลที่จะมีสวนรวม การรวบรวมและการรวมขอมูลOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 19 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 20 5
  6. 6. การสัมภาษณ การสัมภาษณขั้นตอน การเลือกผูถูกสัมภาษณ เลือกผูถูกสัมภาษณ ขึ้นกับขอมูลที่ตองการ ควรเลือกจากหลายกลุม (ผูมีสวนรวมหลักทุกกลุม) ออกแบบคําถามในการสัมภาษณ การออกแบบคําถามในการสัมภาษณ เตรียมพรอมสําหรับการสัมภาษณ ประเภทคําถาม ดําเนินการสัมภาษณ คําถามปลายเปด (open-ended question) คําถามปลายปด (closed-ended question) ติดตามผลหลังการสัมภาษณ คําถามสืบสวน (probing question) รูปแบบการสัมภาษณ มีโครงสราง กับไมมีโครงสราง Top-down กับ Bottom-up OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 21 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 22 การสัมภาษณ การสัมภาษณ การออกแบบคําถามในการสัมภาษณ การเตรียมพรอมสําหรับการสัมภาษณ คําถามที่ควรถาม วางแผน รายละเอียดแบบเจาะจง กําหนดรายการคําถาม คาดเดาคําตอบ และการติดตาม วิสัยทัศน ตรวจสอบความรูของผูถูกสัมภาษณ ความคิดที่แตกตาง กําหนดความสําคัญกรณีเวลาไมพอ การยอมรับขั้นต่ําสุด เตรียมความพรอมของผูถูกสัมภาษณ แหลงขอมูลอื่น แจงนัดหมาย, เหตุผลในการสัมภาษณ และขอบเขตการ ไดอะแกรมของการทํางาน สัมภาษณ OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 23 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 24 6
  7. 7. การสัมภาษณ การสัมภาษณการดําเนินการสัมภาษณ การติดตามผลหลังการสัมภาษณ สรางความนาเชื่อถือ สรางรายงานการสัมภาษณ (interview report) บันทึกทุกขอมูล พิเคราะหหาชองวาง หรือขอสงสัย ตรวจสอบนโยบายการใชสื่อบันทึก ทําใหแนใจวาคุณเขาใจทุกประเด็น และทุกคําศัพท แยกแยะขอเท็จจริงจากความคิดเห็น ใหเวลาผูถูกสัมภาษณถาม ขอบคุณผูถูกสัมภาษณถาม จบภายในเวลาOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 25 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 26 Joint Application Joint Application Development (JAD) Development (JAD)ทําใหทีมงาน ผูใช ผูบริหารไดทางานรวมกัน ํ รูปแบบการจัดชวยลดโอกาสในการเกิดปญหาการขยายขอบเขต จัดใหในสถานที่ไกลจากการรบกวนแบบแอบแฝงได 50% จัดที่นั่งเปนรูปตัวยูหลีกเลี่ยงปญหาของเจาะจงเกินไปหรือคคลุมเครือ ใชกระดานไวทบอรด หรือแบบพลิกได e-JADเกี่ยวของกับการระดมความคิด (brain storming)บทบาทสําคัญ ผูดําเนินรายการ (Facilitator) ผูจดบันทึก (Scribe)OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 27 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 28 7
  8. 8. Joint Application หองประชุม JAD Development (JAD) ขั้นตอน เลือกผูเขารวม ออกแบบการประชุม JPEG Figure 5-5 Goes Here กําหนดจํานวนวัน (5-10 วัน) และสถานที่ กําหนดตารางเวลา กําหนดระเบียบวาระ กําหนดคําถาม เตรียมการ แจงกําหนดการและวัตถุประสงคOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 29 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 30 Joint Application การใชแบบสอบถาม Development (JAD) ดําเนินการ เลือกผูมีสวนรวม บทบาทของผูดําเนินรายการ ใชกลุมตัวอยางจากประชากร รักษาการประชุมใหอยูในประเด็น ออกแบบแบบสอบถาม ชวยในดานคําศัพททางเทคนิค บันทึกขอมูลบนกระดาน เลือกคําถามอยางระมัดระวัง วางตัวเปนกลาง บริหารการทําแบบสอบถาม กระตุนการแสดงความคิดของผูเขารวม   ลดการมีอํานาจเหนือ วางแผนและดําเนินการเพื่อใหอัตราการตอบสนองสูง แกขอขัดแยง  ติดตามผลการทําแบบสอบถาม ติดตามผล สรางรายงานผลการสํารวจ ทํารายงานการประชุม สงผลไปยังผูมีสวนรวมOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 31 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 32 8
  9. 9. การวิเคราะหเอกสาร การสังเกตการณใหขอมูลเกี่ยวกับระบบปจจุบัน (“as-is” system) ผูใชหรือลูกคาอาจจะไมไดจําทุกสิงที่ตนทํา ่ประเภทของเอกสาร ตรวจสอบความถูกตองของขอมูลที่ไดมาดวยวิธีอื่น แบบฟอรม ทําตัวเปนเหมือนเงาเฝาดูการปฏิบติงานและจดบันทึก ั รายงาน พฤติกรรมเปลี่ยนเมื่อถูกจองมอง คูมือนโยบาย อยาละเลยกิจกรรมที่ทําเปนชวงเวลา รายสัปดาห รายเดือน รายป คูมือผูใชมองหาขอมูลที่ผูใชเพิ่มในแบบฟอรมมองหาองคประกอบที่ไมไดใชในแบบฟอรมOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 33 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 34 ความตองการของผูใช (User  การทําตนแบบ Requirements)ตนแบบ (prototype) คือโปรแกรมที่สรางอยางรวดเร็ว และ ความตองการทีมาจากระบบปจจุบัน (Current ่มีสวนเล็กๆ ของฟงกชันที่คาดวาจะมีในระบบสมบูรณ system)เพื่อใชในการรวบรวมผลตอบกลับเกี่ยวกับความคิด ความตองการใหม (New requirement)รูปแบบงายสุดของตนแบบคือ ตนแบบบนกระดาษ (paperprototype) ของสวนติดตอผูใช (user interface)เหมาะกับการพัฒนาแบบขนานอาจสรางตนแบบจําลอง (mock-up)ตนแบบดานอื่น – อัลกอริทึม หรือฐานขอมูลเพื่อทดสอบและตรวจสอบความคิดที่มี และสรางความคิดใหมOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 35 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 36 9
  10. 10. ความตองการทีมาจากระบบ ่ ความตองการทีมาจากระบบ ่ ปจจุบัน (Current system) ปจจุบัน (Current system)สวนใหมของระบบปจจุบันตอบสนองความตองการของผูที่ ระบบปจจุบนอาจมีจุดออนหรือขอผิดพลาดที่ควรกันไมให ัใช ผานการปรับปรุง และผูใชคุนเคยกับระบบ ในเกิดขึ้นในระบบใหม ชวยใหเขาใจการสภาพทั่วไปขององคการบางสวนของระบบปจจุบันไมสอดคลองกับความตองการ บางสวนของระบบปจจุบันอาจถูกคงไวแลว และมีบางดานที่ระบบไมรองรับ ตองทําความเขาใจการทํางานของบุคคลในปจจุบันเพื่อนักวิเคราะหจึงตองทําความเขาใจระบบปจจุบัน เพราะ อธิบายลักษณะของผูใชของระบบใหม หนาที่บางอยางในระบบปจจุบันตองคงในระบบใหม เพื่อรวบรวมขอมูลพื้นฐานเพื่อใชในการกําหนดและวัด ประสิทธิภาพของระบบใหม ขอมูลในระบบปจจุบันมีคาและตองนําไปใชในระบบใหม ความเปลี่ยนแปลงภายในและภายนอกองคกรกอใหเกิด เอกสารตางๆของในระบบปจจุบันอาจมีรายละเอียด ความตองการใหม นําไปสูการพัฒนาระบบใหมเพื่อ เกี่ยวกับอัลริทึมที่จําเปนในระบบใหม ตอบสนองความตองการนี้OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 37 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 38 สรางขอกําหนดความตองการ ความตองการ (Requirements)เขียนชุดคําสั่งที่แนนอนเพื่อกําหนดวาซอฟตแวร เปาหมายของการกําหนดความตองการ คือสรางขอกําหนด ความตองการ (Requirements specification)ตองทําอะไร ความตองการ คือ ถอยแถลงที่อธิบายในมุมของสิ่งที่ระบบอธิบายการแสดงพฤติกรรมของระบบ ตองทํา หรือบอกวาอะไรคือสิ่งที่ระบบตองทํา หรือขอบังคับแตไมระบุการออกแบบหรือการสราง ในการพัฒนาระบบ ตองมีสวนรวมในการแกปญหาของลูกคา เปนขอตกลงที่ผานการตอรองระหวางผูมีสวนรวม ปญหาในการกําหนดความตองการ มีคําอธิบายทีไมชดเจน ่ ั การกําหนดความตองการใหสมบูรณ การกําหนดใหมีเฉพาะความสามารถจําเปนOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 39 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 40 10
  11. 11. ความตองการเชิงฟงกชัน ความตองการแบไมเปนฟงกชัน (Functional Requirements) (Non-functional Requirements) คุณสมบัติเชิงพฤติกรมที่ระบบตองมีอธิบายสิ่งที่ระบบตองทําได หรือบริการที่ระบบ แบงเปนสามารถใหกบผูใชได ั สภาพแวดลอมในการทํางาน (operational)แบงเปน แพลตฟอรม เทคโนโลยีที่ใช การนําเขาขอมูล (input) ดานประสิทธิภาพ (performance) หรือ คุณภาพ (Quality) การแสดงผล (output) ความเร็วในการ ความสามารถในการรองรับ การจัดเก็บขอมูล การใชทรัพยากร การคํานวณและประมวลผล ความนาเชื่อถือ การใชประโยชน การกํากับเวลาและการประสานเวลา การพื้นตัวจากความขัดของ การบํารุงรักษาและขยาย การใชงานซ้ําOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 41 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 42 ความตองการแบไมเปนฟงกชัน เทคนิคการวิเคราะหความตองการ (Non-functional Requirements) การรักษาความปลอดภัย (security) Business process automation Problem analysis วัฒนธรรมหรือนโยบาย (cultural and political) Root cause analysis วัฒนธรรม Business process improvement นโยบาย Duration analysis กฎหมาย หรือระเบียบ Activity-base costing กระบวนการ (process) Information benchmarking กระบวนการพัฒนา Business process reengineering ตนทุนและกําหนดสง Outcome analysis Technology analysis Activity elimination การวิเคราะห Use CaseOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 43 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 44 11
  12. 12. ยูสเคส (Use Case) ยูสเคสโมเดลยูสเคสคือชนิดของความสามารถของระบบจาก ยูสเคสโมเดลมุมมองของผูใช  แสดงกลุมของยูสเคส แสดงลักษณะเฉพาะของพฤติกรรมของระบบทั้งหมด และยูสเคสคือลําดับการกระทําที่แอคเตอรกระทําเพื่อ แอคเตอรภายนอกทํางานหนึ่งใหสําเร็จ Use case model ประกอบดวย รายการยูสเคส และยูสเคส ใชเพือบันทึกขอบเขตของระบบ และความ ่ อาจมีคําอธิบายยูสเคส (Use case description) หรือเขาใจของผูพัฒนาวาอะไรคือสิ่งที่ผูใชตองการ  แผนภาพ (UML use case diagram)แสดงวิธีการใชระบบ โดยใชบางสวนของความสามารถของระบบOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 45 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 46 ตัวอยางอธิบายยูสเคสในรูป องคประกอบคําอธิบายยูสเคส แบบอยางงายชื่อ ยูสเคส: เปดไฟลแอ็คเตอร ขั้นตอน:เปาหมาย การกระทําของแอ็คเตอร การตอบสนองของระบบเงื่อนไขกอนทํา (pre-condition) 1. เลือกคําสั่ง ‘เปด’ 2. แสดงหนาตาง ‘เปดไฟล’สรุปหรือคําอธิบายยูสเคสแบบยอ 3. ระบุชื่อไฟลยูสเคสทีเกียวของ ่ ่ 4. ยืนยันการเลือก 5. เอาหนาตางไดอะล็อกออกจากขั้นตอน หนาจอเงื่อนไขหลังทํา (post-condition)OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 47 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 48 12
  13. 13. สัญลักษณสําคัญในแผนภาพ แผนภาพยูสเคส ยูสเคส แอ็คเตอร (actor)แผนภาพยูสเคส (Use case diagram) ใชแสดงงานที่ แสดงบทบาทของผูใชระบบจะสามารถทําได และผูใชที่ติดตอกับระบบใชความสามารถนี้ มีชื่อบทบาทอยูดานลาง   บทบาท อยูนอกขอบเขตของระบบ ยูสเคส (use case) ยูสเคส งานของระบบ อยูภายในขอบเขตของระบบ หัวเรื่อง/ขอบเขตระบบ (subject/system boundary) หัวเรื่อง ระบุชื่อของระบบภายใน หรือดานบน แสดงขอบเขตในการพิจารณาOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 49 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 50 สัญลักษณสําคัญในแผนภาพ สัญลักษณสําคัญในแผนภาพ ยูสเคส ยูสเคส ความสัมพันธ (association) ความสัมพันธแบบ generalization เชื่อมโยงแอ็คเตอรกับยูสเคส เชื่อมโยงระหวางแอ็คเตอร หรือระหวางยูสเคส ความสัมพันธแบบ include<<include>> เชื่อมโยงระหวางยูสเคส แสดงการใชยูสเคส ชี้ไปยังคลาสที่ถก include ู ความสัมพันธแบบ extend<<extend>> เชื่อมโยงระหวางยูสเคส แสดงการขยายยูสเคส ชี้ไปยังคลาสที่ถกขยาย ูOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 51 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 52 13
  14. 14. พิจารณาหาแอคเตอร พิจารณาหายูสเคส ฮารดแวรหรือระบบภายนอกใดที่ใชระบบนี้ในการ 1. สําหรับแตละแอคเตอร หางานหรือหนาที่ที่แอคเตอร ควร ทํางาน? สามารถทําได หรือที่ระบบตองการใหแอคเตอรทํา ยูสเคส ควรสื่อถึงการดําเนินของเหตุการณที่นําไปสูเปาหมายที่ แอพพลิเคชั่นนี้แกปญหาใด (เพื่อใคร)? ชัดเจน ผูใชใชระบบอยางไร (ยูสเคส)? ผูใชทําอะไรกับระบบ? 2. ตั้งชื่อยูสเคส ชื่อยูสเคสควรอธิบายหนาที่ของยูสเคส ชื่อยูสเคสควรสื่อวาอะไรจะเกิดขึ้นเมื่อยูสเคสถูกกระทํา ควรอยูในรูป กริยา หรือ กริยา + นาม ชื่อควรสือความหมาย และตรงกัน ่ 3. อธิบายยูสเคสพอสังเขป (คําอธิบายยูสเคสแบบยอ) โดยใช คําศัพทที่ผูใชคุนเคยOOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 57 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 58 เขียนคําอธิบายยูสเคส เขียนคําอธิบายยูสเคสเขียนรายละเอียดใหสมบูรณตามรูปแบบคําอธิบาย เขียนรายละเอียดใหสมบูรณตามรูปแบบคําอธิบายยูสเคส ยูสเคสเขียนลําดับขันตอนการทํางาน โดยเขียนเปนขอๆ ้ เขียนลําดับขันตอนการทํางาน โดยเขียนเปนขอๆ ้ แบงเปน แบงเปน Basic course (ลําดับเหตุการณหลัก) หรือ Normal flow Basic course (ลําดับเหตุการณหลัก) หรือ Normal flow (การดําเนินเหตุการณปกติ) (การดําเนินเหตุการณปกติ) Subflow (ลําดับเหตุการณยอย)  Subflow (ลําดับเหตุการณยอย)  Alternative course (ลําดับเหตุการณทางเลือก) หรือ Alternative course (ลําดับเหตุการณทางเลือก) หรือ Exceptional flow/alternative flow (การดําเนินเหตุการณ Exceptional flow/alternative flow (การดําเนินเหตุการณ กรณีแตกตาง) กรณีแตกตาง)OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 59 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 60 15
  15. 15. การหา Exceptional flow เขียนคําอธิบายยูสเคส พิจารณาการกระทําที่ถูกเลือกปฏิบัติ แทนการ ระบุความสัมพันธระหวางยูสเคส กระทําตามขันตอนใน Normal flow ้ <<include>> พิจารณาพฤติกรรมทีเกิดขึ้น ในกรณีเกิดสถาวะไม ่ ยูสเคสที่เปนขั้นตอนหนึ่งของหลายยูสเคส ปกติ (อาจเกิดจากความผิดพลาดของผูใช ความ <<extend>> ผิดปกติของเครื่อง หรือสภาพแวดลอมอื่นๆ ) ยูสเคสหนึ่งอาจแทรกเขาไปในอีกยูสเคสหนึ่ง Generalization ระหวางแอ็บสแตร็กยูสเคส และคอนครีตยูสเคส OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 61 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 62 การหาความสัมพันธแบบ การหาความสัมพันธระหวางยูสเคส extend1. ความสัมพันธแบบ include 1. พิจารณาแยก Excetional flow ออกมาเปนยูสเคส พิจารณาการกระทําที่ซ้ํากันในหลายๆ ยูสเคส แลวกําหนดใหยูสเคสใหม extend ยูสเคสเดิม แยกการกระทํานั้นออกมาเปนยูสเคส แลวกําหนดให 2. พิจารณาสภาวะทีอาจแทรกเขาไปในยูสเคส หรือ ่ ยูสเคสเดิม include ยูสเคสใหม หยุดการทํางานของยูสเคส2. ความสัมพันธแบบ extend 3. ปรับปรุงยูสเคสไดอะแกรม และคําอธิบายยูสเคส แยก exceptional flow ที่ซับซอน หรือสําคัญเปน ยูสเคสใหม3. ความสัมพันธแบบ generalization พิจารณาการ inheritance ของยูสเคสและแอคเตอร OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 63 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 64 16
  16. 16. ขอแนะนําในการสรางแบบจําลอง ขอดีของการใชยูสเคสในการ ยูสเคส พัฒนาซอฟตแวร1.ใสใจกับยูสเคสที่ไมซบซอนและที่เปนปกติกอน ั  ชวยในการกําหนดขอบเขต2.สําหรับทุกขันในยูสเคสใหถามคําถามนี้ ้ มักใชในการวางแผนการพัฒนา มีอะไรผิดพลาดเกิดขึ้นในขั้นนี้ไดบาง? ใชพัฒนาและตรวจสอบความตองการ ขั้นตอนนี้สามารถทํางานแตกตางไปไดอยางไรบาง? ใชเปนพื้นฐานในการกําหนดกรณีทดสอบ3.หายูสเคสรวมออกมาจากลําดับเหตุการณรวมและ  ใชในการวางโครงสรางคูมือผูใช  การใชงานทีเกี่ยวของ และถามีการเพิมยูสเคสใหมที่ ่ ่ เฉพาะขึ้นพยายามใชประโยชนจากความสัมพันธ แบบเอ็กซเทนด (extend) OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 65 OOAD 1/2551 ภาคปกติ ดร.สุขสถิต มีสถิตย 66 17

×