วิเคราะห์และออกแบบระบบเชิงวัตถุ

• ครูผู้สอน นายธีรยุทธ ศรีโสภา เบอร์โทร 0802935459
• สัดส่วนคะแนน 70 : 30
• - คะแนนระหว่างภาค 70 คะแนน

จิตพิสัย 20 คะแนน

แบบฝึกหัดในหนังสือ 10 คะแนน

ใบงาน/ปฏิบัติ 20 คะแนน

สอบกลางภาค 20 คะแนน

- สอบปลายภาค 30 คะแนน

รวม 100 คะแนน

หมายเหตุ ขาดได้ไม่เกิน 4 ครั้ง

​

​

​

​

คำอธิบายรายวิชา

ศึกษาและปฏิบัติขั้นตอนการพัฒนาระบบสารสนเทศ หลักการพื้นฐานและแนวคิดเชิงวัตถุ กระบวนการวิเคราะห์และออกแบบเชิงวัตถุ โมเดลที่ใช้ออกแบบเชิงวัตถุ หลักการของ UML Modeling องค์ประกอบของ UML และการวิเคราะห์และออกแบบโปรแกรมทางธุรกิจ

วิชา การวิเคราะห์และออกแบบเชิงวัตถุ

​

(Object Oriented Analysis and Design)

​

​

​

หน่วยที่ 1 ขั้นตอนการพัฒนาระบบสารสนเทศ

สาระการเรียนรู้

• 1. ระบบสารสนเทศ
• 2. องค์ประกอบระบบสารสนเทศ
• 3. หลักการในการพัฒนาระบบสารสนเทศ
• 4. การรวบรวมข้อมูลเพื่อการวิเคราะห์ระบบ
• 5. รูปแบบการพัฒนาระบบสารสนเทศ

​

สาระการเรียนรู้

• 6. ขั้นตอนในการพัฒนาระบบสารสนเทศ
• 7. ผลที่ได้จากการวิเคราะห์ระบบ
• 8. ปัญหาในการพัฒนาระบบ
• 9. ปัจจัยที่มีต่อการพัฒนาระบบสารสนเทศ

​

จุดประสงค์การเรียนรู้

• 1. บอกความหมายของระบบสารสนเทศได้
• 2. อธิบายองค์ประกอบและหลักการของระบบสารสนเทศได้
• 3. อธิบายวิธีการรวบรวมข้อมูลเพื่อการวิเคราะห์ระบบได้
• 4. อธิบายรูปแบบและขั้นตอนในการพัฒนาระบบสารสนเทศได้
• 5. ประยุกต์ใช้ระบบสารสนเทศในการวิเคราะห์ระบบได้

​

สมรรถนะการเรียนรู้

• 1. แสดงความรู้เกี่ยวกับขั้นตอนการพัฒนาระบบสารสนเทศ
• 2. แสดงความรู้เกี่ยวกับการวิเคราะห์ระบบ
• 3. ปฏิบัติการพัฒนาระบบสารสนเทศและวิเคราะห์ระบบ

​

ระบบสารสนเทศ (Information System)

• ระบบสารสนเทศ (Information System หรือ IS) หมายถึง การจัดเก็บข้อมูลอย่างเป็นระบบโดยใช้ระบบคอมพิวเตอร์ เช่น ฮาร์ดแวร์ ซอฟต์แวร์ บุคลากร ข้อมูล และขั้นตอนการปฏิบัติงาน โดยใช้การทำงานต่าง ๆ ในรูปแบบของการเก็บ (input) การประมวลผล (processing) เผยแพร่ (output) และมีส่วนจัดเก็บข้อมูล (storage)

องค์ประกอบระบบสารสนเทศ

• 1. ฮาร์ดแวร์ (Hardware)
• 2. ซอฟต์แวร์ 
• 3. บุคลากร (People ware)
• 4. ข้อมูล (Data)
• 5. ขั้นตอนการปฏิบัติงาน

หลักการในการพัฒนาระบบสารสนเทศ

• 1)  คำนึงถึงเจ้าของและผู้ใช้ระบบ
• 2)  เข้าถึงปัญหาให้ตรงจุด ซึ่งมีแนวทางการแก้ปัญหาที่เป็นระบบมีขั้นตอนดังนี้
• 3)  กำหนดขั้นตอนหรือกิจกรรมในการพัฒนาระบบ
• 4)  กำหนดมาตรฐานในการพัฒนาระบบ
• 5)  ตระหนักว่าการพัฒนาระบบเป็นการลงทุนประเภทหนึ่ง
• 6)  เตรียมความพร้อมหากจะต้องยกเลิกหรือทบทวนระบบสารสนเทศที่กำลังพัฒนา
• 7)  แตกระบบสารสนเทศที่จะพัฒนาออกเป็นระบบย่อย
• 8)  ออกแบบระบบให้สามารถรองรับต่อการขยายหรือการปรับเปลี่ยนในอนาคต

การรวบรวมข้อมูลเพื่อการวิเคราะห์ระบบ (Systems Analysis)

• 1. การสอบถาม
• 2. การสังเกต
• 3. การสัมภาษณ์

​

การรวบรวมข้อมูลเพื่อการวิเคราะห์ระบบ (Systems Analysis)

การรวบรวมข้อมูลเพื่อการวิเคราะห์ระบบ (Systems Analysis)

• 1. Preliminary Investigation หมายถึง การตรวจสอบเบื้องต้น
• 2. System Survey หมายถึง การสำรวจระบบ
• 3. Determination of User Requirements หมายถึง ความมุ่งมั่นของผู้ใช้ระบบ
• 4. Analysis of the System Survey หมายถึง การวิเคราะห์การสำรวจระบบ
• 5. Systems Analysis Report หมายถึง รายงานการวิเคราะห์ระบบ

​

รูปแบบการพัฒนาระบบสารสนเทศ

• 1. วิธีพื้นฐานในการพัฒนาระบบ สามารถจำแนกได้เป็น 4 วิธี คือ
• 1) วิธีเฉพาะเจาะจง (Ad Hoc Approach)
• 2) วิธีสร้างฐานข้อมูล (Database Approach)
• 3) วิธีพัฒนาจากล่างขึ้นบน (Bottom-up Approach)
• 4) วิธีพัฒนาจากบนลงล่าง (Top-down Approach)

​

รูปแบบการพัฒนาระบบสารสนเทศ

• 2. การพัฒนาระบบแบบน้ำตก (Waterfall Model)
• 1) การกำหนดและเลือกโครงการ (System Initiation and Selection)
• 2) การเริ่มต้นและวางแผนโครงการ (System Initiation and Planning)
• 3) การวิเคราะห์ระบบ (System Analysis)
• 4) การออกแบบ (System Design)
• 5) การนำไปใช้ (System Implementation)
• 6) การบำรุงรักษาระบบ (System Maintenance)

​

รูปแบบการพัฒนาระบบสารสนเทศ

รูปแบบการพัฒนาระบบสารสนเทศ

• 3.  การพัฒนาระบบแบบน้ำตกที่ย้อนกลับขั้นตอนได้ (Adapted Waterfall) SDLC แบบ Adapted Waterfall เป็นรูปแบบในการพัฒนาระบบงานที่ปรับปรุงมาจากแบบ waterfall โดยในแต่ละขั้นตอนเมื่อดำเนินงานอยู่ สามารถย้อนกลับมายังขั้นตอนก่อนหน้าเพื่อแก้ไขข้อผิดพลาดหรือสามารถย้อนกลับข้ามขั้น โดยไม่จำเป็นต้องเป็นขั้นตอนที่ติดกันได้

​

รูปแบบการพัฒนาระบบสารสนเทศ

รูปแบบการพัฒนาระบบสารสนเทศ

• 4.  การพัฒนาระบบอย่างรวดเร็ว (Rapid Application Development : RAD)

รูปแบบการพัฒนาระบบสารสนเทศ

• 5. การพัฒนาระบบในรูปแบบขดลวด (Evolutionary Model SDLC)  

ขั้นตอนในการพัฒนาระบบสารสนเทศ

• 1. การกำหนดปัญหา (Problem Recognition)
• 2. การวิเคราะห์ระบบ (Analysis)
• 3. การออกแบบระบบ (Design)
• 4. การพัฒนาระบบ (Development)
• 5. การทดสอบระบบ (Test System)
• 6. การนำระบบไปใช้ (Implementation)
• 7. การบำรุงรักษา (Maintenance)

​

ขั้นตอนในการพัฒนาระบบสารสนเทศ

ขั้นตอนที่ 1 การกำหนดปัญหา

ขั้นตอนที่ 2 การวิเคราะห์ระบบ

ขั้นตอนที่ 3 การออกแบบระบบ

ขั้นตอนที่ 3 การออกแบบระบบ

ขั้นตอนที่ 4 การพัฒนาระบบ

ขั้นตอนที่ 5 การทดสอบระบบ

• 1. วิเคราะห์ความต้องการ
• 2. จัดทำแผนงานการทดสอบ
• 3. จัดทำแนวทางการทดสอบ
• 4. ดำเนินการทดสอบจริง
• 5. ทดสอบความถูกต้องของผลลัพธ์ที่ได้
• 6. รายงานผลการทดสอบ
• 7. ทดสอบว่าระบบที่พัฒนาตรงตามความต้องการของผู้ใช้หรือไม่

​

ขั้นตอนที่ 6 การนำระบบไปใช้

• 1. ศึกษาสภาพแวดล้อมของพื้นที่ก่อนที่จะนำระบบไปติดตั้ง
• 2. ติดตั้งระบบให้เป็นไปตามสถาปัตยกรรมที่ออกแบบไว้
• 3. จัดทำคู่มือระบบ
• 4. ฝึกอบรมผู้ใช้
• 5. ดำเนินการใช้ระบบงานใหม่
• 6. ประเมินผลการใช้งานของระบบใหม่

​

ขั้นตอนที่ 7 การบำรุงรักษา

• 1. กรณีเกิดข้อผิดพลาดขึ้นจากระบบ ให้ดำเนินการแก้ไขให้ถูกต้อง
• 2. อาจจำเป็นต้องเขียนโปรแกรมเพิ่มเติม กรณีที่ผู้ใช้มีความต้องการเพิ่มเติม
• 3. วางแผนรองรับเหตุการณ์ที่อาจเกิดขึ้นในอนาคต
• 4. บำรุงรักษาระบบงาน และอุปกรณ์

ผลที่ได้จากการวิเคราะห์ระบบ

• 1. ไม่มีการเปลี่ยนแปลงระบบใด ๆ เลย
• 2. ปรับปรุงระบบเดิมให้ดีขึ้น
• 3. พัฒนาระบบใหม่ขึ้นมาใช้งาน

ปัญหาในการพัฒนาระบบ

• 1. ขาดข้อกำหนดวิสัยทัศน์ วัตถุประสงค์และนโยบาย 
• 2. ขาดการวางแผนที่ดี 
• 3. ขาดงบประมาณ 
• 4. ขาดการติดตาม 
• 5. ขาดความรู้ทั้งผู้บริหารและเจ้าหน้าที่ระดับปฏิบัติการ 
• 6. การพัฒนาระบบที่ไม่เป็นไปตามข้อกำหนด 
• 7. การเปลี่ยนแปลงนโยบายหรือเปลี่ยนแปลงข้อมูลบ่อยครั้ง 

​

ปัจจัยที่มีต่อการพัฒนาระบบสารสนเทศ

• 1)  การสนับสนุนจากฝ่ายบริหาร
• 2)  การกำหนดขอบเขตและวัตถุประสงค์ที่ชัดเจน
• 3)  ความรู้ ความสามารถและประสบการณ์ของทีมพัฒนาระบบ
• 4)  การเลือกใช้เทคโนโลยีสารสนเทศที่เหมาะสม
• 5)  การบริหารโครงการพัฒนาระบบสารสนเทศอย่างมีประสิทธิภาพ

​

ใบงาน ที่1

• 1. แบ่งกลุ่มๆละ 5 คน ความรู้เกี่ยวกับขั้นตอนการพัฒนาระบบสารสนเทศทางธุรกิจที่เกี่ยวข้องกับระบบงานคอมพิวเตอร์
• 2. แบ่งกลุ่มๆละ 5 คน การประยุกต์ใช้ขั้นตอนการพัฒนาระบบโดยการปรับใช้กับระบบงานของตนเอง
• 3. แบ่งกลุ่มๆละ 5 คน ให้ศึกษาค้นคว้าข้อมูลเกี่ยวกับระบบสารสนเทศของสถานศึกษา หรือหน่วยงานอื่น ว่ามีระบบอย่างไร และมีการพัฒนาอย่างไร (นำเสนอ)

หน่วยที่ 2 หลักการพื้นฐานและแนวคิดเชิงวัตถุ

สาระการเรียนรู้

•    1. การเขียนโปรแกรมเชิงโครงสร้าง
• 2. การเขียนโปรแกรมเชิงวัตถุ
• 3. วัตถุหรืออ็อบเจกต์

4. คุณสมบัติทั่วไปของอ็อบเจกต์

• 5. องค์ประกอบของวัตถุหรืออ็อบเจกต์
• 6. ความสัมพันธ์ระหว่างอ็อบเจกต์

​

สาระการเรียนรู้

•    7. องค์ประกอบสำคัญของแนวคิดเชิงวัตถุ
• 8. กระบวนการพัฒนาเชิงวัตถุ
• 9. แนวคิดรวบยอดของอ็อบเจกต์
• 10. Abstraction และ Encapsulation
• 11. ภาษายูเอ็มแอล (UML)
• 12. ภาษาโปรแกรมเชิงวัตถุ

​

จุดประสงค์การเรียนรู้

•   1. อธิบายวิธีการเขียนโปรแกรมเชิงโครงสร้างและเชิงวัตถุได้
• 2. อธิบายองค์ประกอบของวัตถุและอ็อบเจกต์ได้
• 3. อธิบายกระบวนการพัฒนาเชิงวัตถุได้
• 4. อธิบายภาษายูเอ็มแอลได้
• 5. ประยุกต์การเขียนภาษาโปรแกรมเชิงวัตถุได้

​

สมรรถนะการเรียนรู้

• 1. แสดงความรู้เกี่ยวกับหลักการพื้นฐานเชิงวัตถุ
• 2. แสดงความรู้เกี่ยวกับแนวคิดเชิงวัตถุ
• 3. ปฏิบัติการเขียนภาษาโปรแกรมเชิงวัตถุ

การเขียนโปรแกรมเชิงโครงสร้าง �(Structured System Development)

การเขียนโปรแกรมเชิงวัตถุ� (Object-Oriented System Development)

การเปรียบเทียบขั้นตอนการเขียนโปรแกรมเชิงโครงสร้าง �และการเขียนโปรแกรมเชิงวัตถุ

วัตถุหรืออ็อบเจกต์ (object)

• วัตถุ (Objects) คือ สิ่งใด ๆ ก็ตามซึ่งมีคุณลักษณะ (Attribute) บ่งบอกถึงความเป็นตัวของ ตัวเองในขณะนั้น และสามารถแสดงพฤติกรรม (Behavior) ของตัวเองออกมาได้ในชีวิตประจำวันเมื่อมองดูรอบตัว พบเห็นวัตถุต่าง ๆ วัตถุที่สามารถมองเห็นได้และจับต้องได้ (Tangible Objects)

คุณสมบัติทั่วไปของอ็อบเจกต์

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

องค์ประกอบของวัตถุหรืออ็อบเจกต์

• 1. การสืบทอด/สืบสกุล (Inheritance)
• 2. การควบคุมการเข้าถึง (Encapsulation)
• 3. การกำหนดผลลัพธ์ของพฤติกรรมที่แตกต่างกันในสภาวะที่ต่างกัน (Polymorphism)

​

องค์ประกอบของวัตถุหรืออ็อบเจกต์

ความสัมพันธ์ระหว่างอ็อบเจกต์

• 1. ความสัมพันธ์แบบ Is-A Relationship
• 2. ความสัมพันธ์แบบ Has-A Relationship
• 3. ความสัมพันธ์แบบ Association
• 4. ความสัมพันธ์แบบ Composition
• 5. ความสัมพันธ์แบบ Aggregation

องค์ประกอบสำคัญของแนวคิดเชิงวัตถุ

• 1) การวิเคราะห์ ปัญหาโดยอาศัยแนวคิดเชิงวัตถุ (Object-Oriented Analysis: OOA)
• 2) การออกแบบเชิงวัตถุ (ObjectOriented Design: OOD)

กระบวนการพัฒนาเชิงวัตถุ

• 1. การรวมรวมและศึกษาความต้องการของระบบ (Requirement Gathering)
• 2. การกำหนดคลาสเอนทิตี (Class Entity Identification)
• 3. เก็บข้อมูลพฤติกรรมของคลาส (Class Behavior)
• 4. สร้างความสัมพันธ์ระหว่างคลาส (Class Relationship)
• 5. สร้างโมเดลของคลาส (Class Modeling)

แนวคิดรวบยอดของอ็อบเจกต์

• แนวคิดรวบยอดของอ็อบเจกต์ (Concept) หมายถึง แนวความคิดในข้อเท็จจริงต่าง ๆ ที่เราสามารถอธิบายลักษณะและพฤติกรรมของวัตถุนั้น ๆ ภายใต้กรอบแนวคิดของโดเมนที่เรากำลังพิจารณาในการทำงาน โดยไม่รวมถึงความรู้สึก

Abstraction และ Encapsulation

• Abstraction คือ การกำจัดข้อมูลที่ไม่เกี่ยวข้องทิ้งไปให้เหลือข้อมูลที่ต้องการเท่านั้น การแทนวัตถุที่มีอยู่ในโลกความเป็นจริงลงในระบบคอมพิวเตอร์ต้องพิจารณาถึงคุณสมบัติที่สำคัญของวัตถุเท่านั้น เป็นไปไม่ได้ที่จะพิจารณาคุณสมบัติทุกข้อมาของวัตถุที่มีอยู่จริง
• Encapsulation เป็นองค์ประกอบที่สำคัญอีกประการหนึ่งของ OOP ซึ่งหมายถึงการนำการปฏิบัติการ(Operation) รวมเป็นส่วนหนึ่งของวัตถุ เหตุที่เป็นเช่นนี้เพราะว่าต้องการซ่อนข้อมูลของวัตถุไว้ ผู้ใช้งานไม่จำเป็นต้องทราบถึงรายละเอียดต่าง ๆของวัตถุนั้น เพียงทราบถึงวิธีการจะใช้วัตถุนั้นก็เพียงพอ

ภาษายูเอ็มแอล (UML)

• ยูเอ็มแอล (UML) ย่อมาจาก Unified Modeling Language เป็นภาษาที่ใช้อธิบายแบบจำลองต่าง ๆ หรือเป็นภาษาสัญลักษณ์รูปภาพมาตรฐาน สำหรับใช้ในการสร้างแบบจำลองเชิงวัตถุ โดยยูเอ็มแอล เป็นภาษามาตรฐานสำหรับสร้างแบบพิมพ์เขียวให้แก่ระบบงาน

ภาษาโปรแกรมเชิงวัตถุ

• นักเขียนโปรแกรมบางคนคิดว่าการเขียนโปรแกรมขนาดใหญ่ บางครั้งก็เป็นงานที่หนักและเสียเวลามาก จึงได้พยายามคิดหาวิธีที่จะทำให้การเขียนโปรแกรมนั้นง่ายขึ้น และสามารถเขียนได้อย่างรวดเร็ว ทำให้เกิดเทคนิค การเขียนโปรแกรมเชิงวัตถุ (Object-Oriented Programming) หรือ OOP ขึ้นเพื่อช่วยลดความยุ่งยากของการเขียนโปรแกรม Object-Oriented Programming ต่างจากการเขียนโปรแกรมโดยทั่ว ๆ ไป

Visual Basic

• ภาษา Visual Basic พัฒนาโดย Prof. Kemeny และ Kurtz ที่เมือง Dartmouth เกิดขึ้น ในปี ค.ศ. 1960 โดยมีจุดประสงค์สำหรับใช้สอนในห้องคอมพิวเตอร์ เมื่อมีการพัฒนาเครื่องไมโครคอมพิวเตอร์ขึ้นในยุคแรก ๆ จะมีหน่วยความจำไม่เพียงพอที่จะทำงานกับโปรแกรมภาษาอื่น

JAVA

• จาวา เป็นภาษาใหม่ที่มาแรงมาก ภาษาจาวา ได้รับการพัฒนาขึ้นโดย บริษัท ซันไมโคร ซิสเตมส์ ในปี ค.ศ. 1991 โดยมีเป้าหมายที่จะสร้างผลิตภัณฑ์ อิเล็กทรอนิกส์ สำหรับผู้บริโภคที่ใช้ง่าย มีค่าใช้จ่ายต่ำ ไม่มีข้อผิดพลาด และสามารถใช้กับเครื่องใด ๆ ก็ได้ ซึ่งสิ่งเหล่านี้ก็ได้กลายเป็นข้อดีของจาวา ที่เหนือกว่าภาษาอื่น ๆ โดยเฉพาะอย่างยิ่ง ในการที่โปรแกรมซึ่งเขียนขึ้นด้วยจาวาสามารถนำไปใช้กับเครื่องต่าง ๆ โดยไม่ต้องทำการคอมไพล์โปรแกรมใหม่

ใบงานที่2

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

หน่วยที่ 3 กระบวนการวิเคราะห์และออกแบบเชิงวัตถุ

สาระการเรียนรู้

• 1. พื้นฐานการวิเคราะห์และออกแบบเชิงวัตถุ
• 2. การวิเคราะห์และออกแบบระบบ
• 3. ประเภทของการออกแบบระบบ
• 4. กิจกรรมในระยะออกแบบระบบ
• 5. กลยุทธ์การจัดหาระบบ

​

สาระการเรียนรู้

• 6. การออกแบบสถาปัตยกรรมระบบ
• 7. การเปรียบเทียบระดับการออกแบบระบบฐานข้อมูลกับสถาปัตยกรรมระบบฐานข้อมูล
• 8. ขั้นตอนการวิเคราะห์และออกแบบระบบ
• 9. การวิเคราะห์ระบบเชิงวัตถุ
• 10. การวิเคราะห์ในวงจรการพัฒนาระบบเชิงวัตถุ

​

จุดประสงค์การเรียนรู้

• 1. อธิบายพื้นฐานการวิเคราะห์และออกแบบเชิงวัตถุได้
• 2. อธิบายวิธีการวิเคราะห์และออกแบบระบบได้
• 3. อธิบายประเภทและกิจกรรมในการออกแบบระบบได้
• 4. อธิบายขั้นตอนการวิเคราะห์และออกแบบระบบได้
• 5. ประยุกต์การวิเคราะห์ในวงจรการพัฒนาระบบเชิงวัตถุได้

​

สมรรถนะการเรียนรู้

• 1. แสดงความรู้เกี่ยวกับกระบวนการวิเคราะห์และออกแบบเชิงวัตถุ
• 2. แสดงความรู้เกี่ยวกับขั้นตอนการวิเคราะห์และออกแบบระบบ
• 3. ปฏิบัติการวิเคราะห์ในวงจรการพัฒนาระบบเชิงวัตถุ
•  

​

พื้นฐานการวิเคราะห์และออกแบบเชิงวัตถุ

• การวิเคราะห์และออกแบบเชิงวัตถุ (OOAD) เป็นวิธีการที่ได้รับความนิยม โดยการดูระบบจากมุมมองของตัวอ็อบเจกต์เอง เพราะออบเจ็กต์ทำหน้าที่ปฏิบัติงานและเป็นตัวโต้ตอบหรือปฏิสัมพันธ์กับระบบ โดยผลผลิตสุดท้ายของการวิเคราะห์เชิงวัตถุ คือ การจำลองแบบเชิงวัตถุ (Object Model) ซึ่งจะเป็นตัวแทนของระบบสารสนเทศในความหมายของอ็อบเจกต์และแนวความคิดเชิงวัตถุ

การวิเคราะห์และออกแบบระบบ

ประเภทของการออกแบบระบบ

• 1. การออกแบบเชิงตรรกะ (Logical Design)
• 2. การออกแบบเชิงกายภาพ (Physical Design)

​

กิจกรรมในระยะออกแบบระบบ

• 1. การจัดหาระบบ
• 2. การออกแบบสถาปัตยกรรมระบบ
• 3. การออกแบบ Input, Output และ User Interface
• 4. การออกแบบฐานข้อมูล
• 5. การสร้างต้นแบบ
• 6. การออกแบบโปรแกรม

​

กลยุทธ์การจัดหาระบบ (System Acquisition Strategies)

• 1. การพัฒนาโปรแกรมขึ้นใช้เอง
• 2. การซื้อโปรแกรมสำหรับรูป
• 3. การว่าจ้างหน่วยงานภายนอก

การออกแบบสถาปัตยกรรมระบบ

การออกแบบสถาปัตยกรรมระบบ

การเปรียบเทียบระดับการออกแบบระบบฐานข้อมูลกับสถาปัตยกรรมระบบฐานข้อมูล

ขั้นตอนการวิเคราะห์และออกแบบระบบ

• 1. การวิเคราะห์ระบบ (Analysis)
• 2. การออกแบบระบบ (Design)
• 3. การพัฒนาระบบ (Development)

การวิเคราะห์ระบบเชิงวัตถุ

Fern Diagrams

Fern Diagrams

Fern Diagrams

Box Diagrams

Box Diagrams

Cardinal Constraints

Cardinal Constraints

Instances

Subtypes and Inheritances

Composed – of – Diagrams

State – Transition Diagrams

State – Transition Diagrams

Event Diagrams

Object-Flow Diagrams

การวิเคราะห์ในวงจรการพัฒนาระบบเชิงวัตถุ

• 1. การวิเคราะห์เชิงวัตถุ (Object-oriented Analysis)
• 2. การออกแบบเชิงวัตถุ (Object-oriented Design)
• 3. การเขียนโปรแกรมเชิงวัตถุ (Object-oriented programming)
• 4. การประเมิน (Evaluation)

หน่วยที่ 4 หลักการของ UML MODELING

สาระการเรียนรู้

• 1. ความหมายของ UML
• 2. การใช้ UML กับการพัฒนาระบบ
• 3. องค์ประกอบของ UML
• 4. สัญลักษณ์ทั่วไปของ UML
• 5. การจำลองแนวคิดของ UML

​

สาระการเรียนรู้

• 6. แนวคิดเชิงวัตถุ
• 7. กฎของ UML ในการออกแบบเชิงวัตถุ
• 8. ข้อดีของการใช้ UML
• 9. ประโยชน์ของ UML

​

จุดประสงค์การเรียนรู้

• 1. บอกความหมายของ UML ได้
• 2. อธิบายวิธีการใช้ UML กับการพัฒนาระบบ
• 3. อธิบายองค์ประกอบและสัญลักษณ์ทั่วไปของ UML ได้
• 4. อธิบายกฎของ UML ในการออกแบบเชิงวัตถุได้
• 5. ประยุกต์ใช้แนวคิดเชิงวัตถุและการออกแบบเชิงวัตถุได้

​

สมรรถนะการเรียนรู้

• 1. แสดงความรู้เกี่ยวกับหลักการของ UML Modeling
• 2. แสดงความรู้เกี่ยวกับการจำลองแนวคิดของ UML
• 3. ปฏิบัติการใช้กฎของ UML ในการออกแบบเชิงวัตถุ

​

ความหมายของ UML

• ยูเอ็มแอล (UML) ย่อมาจาก Unified Modeling Language เป็นภาษาที่ใช้อธิบายแบบจำลองต่าง ๆ หรือเป็นภาษาสัญลักษณ์รูปภาพมาตรฐาน สำหรับใช้ในการสร้างแบบจำลองเชิงวัตถุ โดยยูเอ็มแอล เป็นภาษามาตรฐานสำหรับสร้างแบบพิมพ์เขียวให้แก่ระบบงาน   

แบบจำลอง (Modeling)

• แบบจำลอง (Modeling) เป็นวิธีการวิเคราะห์ออกแบบ (Analysis and Design) อย่างหนึ่งที่เน้นการใช้งานแบบจำลองเป็นหลัก ซึ่งแบบจำลองที่สร้างขึ้นมาจะสามารถช่วยให้เข้าใจในปัญหาได้ง่ายขึ้น อีกทั้งยังสามารถนำแบบจำลองมาเป็นเครื่องมือในการสื่อสารถ่ายทอดความคิดกับบุคคลอื่น ๆ ที่เกี่ยวข้องในโครงการได้

การพัฒนาซอฟต์แวร์

การใช้ UML กับการพัฒนาระบบ

• UML เป็นเครื่องมือสำคัญสำหรับการพัฒนาระบบ และเพื่อให้บุคคลากรในทีมพัฒนาระบบทำงานร่วมกันได้อย่างมีประสิทธิภาพและมีความเข้าใจที่ตรงกัน เมื่อนำ UML มาประยุกต์ใช้ในการทำเอกสารสั่งงาน หรือทำเอกสารข้อระบุจำเพาะของระบบงาน (System Specification) แล้วจะทำให้ได้ระบบงานที่มีองค์ประกอบชัดเจนและสามารถนำไปประยุกต์ใช้ภาษาโปรแกรมที่เป็น Object-Oriented ได้ทันที

​

การใช้ UML กับการพัฒนาระบบ

การใช้ UML กับการพัฒนาระบบ

องค์ประกอบของ UML (Unified Modeling Language)

สัญลักษณ์ทั่วไปของ UML (Unified Modeling Language)

สัญลักษณ์

• 1. Private  เขียนแทนด้วยสัญลักษณ์   -   
• 2. Protect  เขียนแทนด้วยสัญลักษณ์   #   
• 3. Public  เขียนแทนด้วยสัญลักษณ์   +   

แบบจำลองแนวคิดของ UML

• การสร้าง UML
• กฎในการเชื่อมต่อแบบเอกสารสำเร็จรูป
• กลไกทั่วไปของ UML

​

แนวคิดเชิงวัตถุ

• Objects วัตถุแสดงถึงเอนทิตี
• Building Block พื้นฐาน
• Class รูปแบบของวัตถุ
• Abstraction Abstraction พฤติกรรมของเอนทิตีโลกแห่งความจริง
• Encapsulation Encapsulation เป็นกลไกของการซ่อนไว้จากโลกภายนอก
• Inheritance เป็นกลไกของการสร้างคลาสใหม่จากคลาสที่มีอยู่
• Polymorphism มันกำหนดกลไกการมีอยู่ในรูปแบบที่แตกต่างกัน

​

กฎของ UML ในการออกแบบเชิงวัตถุ

• UML (Unified Modeling Language) เป็นภาษาที่ใช้ในการสร้างแบบจำลองซอฟต์แวร์และระบบที่ไม่ใช่ซอฟต์แวร์ แม้ว่า UML จะใช้สำหรับระบบที่ไม่ใช่ซอฟต์แวร์ แต่สิ่งสำคัญคือการสร้างโมเดลแอพพลิเคชันซอฟต์แวร์เชิงวัตถุ ไดอะแกรมของ UML ส่วนใหญ่ที่กล่าวถึงในตอนนี้ถูกนำมาใช้เพื่อสร้างแบบจำลองด้านต่าง ๆ ทั้งมีรูปแบบเป็นวัตถุและไม่เป็นวัตถุ

​

ข้อดีของการใช้ UML (Unified Modeling Language)

• 1. UML ได้รวมข้อดีของโมเดลต่าง ๆ เอาไว้
• 2. เป็นภาษาที่เป็นมาตรฐานเปิด (Open Standard) (Open Standard)
• 3. ภาษา UML ครอบคลุมทุกส่วนในวงจรชีวิต (Life Cycle)
• 4. เป็นภาษาที่มีความสมดุลในงแง่ของความเรียบง่ายและความซับซ้อน
• 5. มีบริษัทชั้นนำและอุตสาหกรรมต่าง ๆ ให้การยอมรับและให้การสนับสนุน

​

ประโยชน์ของยูเอ็มแอล (UML)

• 1. วงจรการพัฒนาที่สั้นที่สุด (Shortest Development Life Cycle)
• 2. เพิ่มผลผลิต (Increase Productivity)
• 3. ปรับปรุงคุณภาพซอฟต์แวร์ (Improve Software Quality)
• 4. สนับสนุนระบบสืบทอดมรดก (Support Legacy system)
• 5. ปรับปรุงการเชื่อมต่อทีมงาน (Improve team connectivity)

​

หน่วยที่ 5 โมเดลที่ใช้ออกแบบเชิงวัตถุ

สาระการเรียนรู้

• 1. ยูเคสไดอะแกรม
• 2. คลาสไดอะแกรม
• 3. ความสัมพันธ์ระหว่าง Class
• 4. ความสัมพันธ์ระหว่าง Object
• 5. หลักในการสร้าง Class Diagram
• 6. สเตตชาร์ตไดอะแกรม
• 7. การออกแบบสเตตไดอะแกรม
• 8. ซีเควนซ์ไดอะแกรม

​

​

สาระการเรียนรู้

• 9. ข้อสังเกตของ Sequence Diagram
• 10. คอลลาบอเรชั่นไดอะแกรม
• 11. แอกทิวิตีไดอะแกรม
• 12. ขั้นตอนในการเขียน Activity Diagram
• 13. คุณสมบัติของ Activity Diagram ที่ดี
• 14. คอมโพเนนต์ไดอะแกรม
• 15. ดีพลอยเมนต์ไดอะแกรม

จุดประสงค์การเรียนรู้

• 1. บอกความหมายของไดอะแกรมต่าง ๆ ได้
• 2. อธิบายความสัมพันธ์ระหว่าง Class และ Object ได้
• 3. อธิบายหลักในการสร้าง Class Diagram ได้
• 4. อธิบายวิธีการออกแบบสเตทไดอะแกรมได้
• 5. ประยุกต์ใช้โมเดลในการออกแบบเชิงวัตถุได้

​

สมรรถนะการเรียนรู้

• 1. แสดงความรู้เกี่ยวกับไดอะแกรมแบบต่าง ๆ
• 2. แสดงความรู้เกี่ยวกับหลักในการสร้าง Class Diagram และออกแบบสเตตไดอะแกรม
• 3. ปฏิบัติการเขียน Activity Diagram

ยูเคสไดอะแกรม (Use Case Diagram)

• 1. ส่วนประกอบสำคัญในยูสเคสไดอะแกรม ส่วนประกอบที่สำคัญของยูเคสไดอะแกรม มี 3 ส่วน คือ ยูเคส (Use Case) แอ็กเตอร์ (Actor) เส้นแสดงความสัมพันธ์ (Relationship) ในการสร้างยูเคสไดอะแกรมสิ่งสำคัญคือการค้นหาว่าระบบ ทำอะไรได้บ้าง โดยไม่สนว่าจะทำงานอย่างไรหรือใช้เทคนิคการสร้างอย่างไร

​

ยูเคสไดอะแกรม (Use Case Diagram)

ยูเคสไดอะแกรม (Use Case Diagram)

• 2 ประโยชน์ของยูเคสไดอะแกรม ยูเคสไดอะแกรมจะจำลองการทำงานต่าง ๆ ของระบบ ซึ่งจะช่วยให้สามารถมองระบบได้ อย่างชัดเจนขึ้น ยูเคสไดอะแกรมมีประโยชน์ สรุปได้ดังนี้
• 2.1 เพื่อให้ผู้พัฒนาทราบถึงความสามารถของระบบว่าต้องทำอะไรได้บ้าง
• 2.2 เพื่อทราบถึงผู้ใช้งานในแต่ละส่วนของระบบ
• 2.3 ทำให้การติดต่อสื่อสารระหว่างผู้พัฒนากับลูกค้าหรือระหว่างผู้พัฒนาด้วยกันทำได้ง่าย
• 2.4 ใช้ในการทดสอบระบบซอฟต์แวร์ ว่าทำงานได้ครบถ้วนตามความต้องการหรือไม่

คลาสไดอะแกรม (Class Diagram)

• 1. การสร้างคลาสไดอะแกรม
• 2. คำนามที่ปรากฏอยู่ในคำบรรยายยูเคสจะถูกสร้างเป็นคลาส เช่น คลาสรถยนต์ คลาสวิชา เรียน คลาสหนังสือ คลาสสินค้า
• 3. คำวิเศษณ์ที่ปรากฏอยู่ในคำบรรยายยูเคสจะถูกสร้างเป็นแอททริบิวท์เช่น สีรถ รุ่นรถ ยี่ห้อรถ 4. คำกิริยาที่ปรากฏอยู่ในคำบรรยายยูเคสจะถูกสร้างเป็นโอเปอเรชั่น เช่น สตาร์ตรถ เบรก ลงทะเบียน ยกเลิกรายวิชา
• 5. สัญลักษณ์

ความสัมพันธ์ระหว่าง Class

• - ความสัมพันธ์แบบพึ่งพา (Dependency) - ความสัมพันธ์แบบสืบทอดคุณสมบัติ (Inheritance) เช่น “Class แม่” (Super Class) 
• - ความสัมพันธ์แบบร่วมกัน (Association) 

​

ความสัมพันธ์ระหว่าง Object 

• Association เป็นความสัมพันธ์ระหว่าง Object หรือ Class แบบ 2 ทิศทาง
• Aggregation เป็นความสัมพันธ์ระหว่าง Object หรือ Class แบบ “Whole-Part” หรือ “is part of” โดยจะมี Class ที่ใหญ่ที่สุดที่เป็น Object หลัก และมี Class อื่นเป็นส่วนประกอบ
• Composition เป็นความสัมพันธ์ระหว่าง Object หรือ Class แบบขึ้นต่อกันและมีความเกี่ยวข้องกันเสมอ โดยจะมี Class ซึ่งเป็นองค์ประกอบของ Class อื่นที่ใหญ่กว่า เมื่อ Class ที่ใหญ่กว่าถูกทำลาย Class ที่เป็นองค์ประกอบก็จะถูกทำลายไปด้วย

​

ความสัมพันธ์ระหว่าง Object 

• Generalization เป็นความสัมพันธ์ระหว่าง Object หรือ Class ในลักษณะของการสืบทอดคุณสมบัติจาก Class หนึ่ง (Super class) ไปยังอีก Class หนึ่ง (Subclass)
• Specialization คือ กระบวนการที่ตรงกันข้ามกับ กระบวนการ Generalization Abstraction กล่าวคือ ถ้าต้องการสร้าง Class ใหม่ โดยอาศัย Concept ของ Class เก่าบางส่วน และเพิ่มเติมใหม่บางส่วนจนเกิดเป็น Class ใหม่

​

หลักในการสร้าง Class Diagram

• 1.  กำหนดกรอบของ Problem Domain ให้ชัดเจน
• 2.  พิจารณาหา Objects ที่สามารถจับต้องได้เห็นได้สัมผัสได้ ซึ่งเรียกว่า Tangible Objects
• 3.  พิจารณาหา Objects ที่ไม่สามารถจับต้องได้ซึ่งเรียกว่า Intangible Objects
• 4. ใช้ Classification Abstraction เพื่อแยกแยะและสร้าง Class จาก Objects ที่มีอยู่
•        

หลักในการสร้าง Class Diagram

• 5. หา Aggregation Abstraction โดยพิจารณาการเป็นส่วนประกอบ
• 6. ใช้ Generalization มาพิจารณา
• 7. ใช้ Association มาพิจารณา
• 8. พิจารณา Class Diagram ว่ามี Class หรือ กลุ่มของ Class ที่ไม่มีความสัมพันธ์กับ Class อื่น ๆ หรือไม่

​

​

สเตตชารต์ไดอะแกรม (State diagram)

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

​

ซีเควนซ์ไดอะแกรม (Sequence Diagram)

​

•   ซีเควนซ์ไดอะแกรมบ่งบอกถึงในยูเคสนั้นวัตถุแต่ละตัวจะติดต่อสื่อสารกันอย่างไร มีขั้นตอนการทำงาน อย่างไร โดยเน้นไปที่แกนเวลาเป็นสำคัญถ้าเวลาเปลี่ยนขั้นตอนการทำงานจะเปลี่ยนโดยมีแอกเตอร์เป็น ผู้กระทำเริ่มต้น ในยูเอ็มแอลซีเควนซ์ไดอะแกรมมีแกนสมมติ 2 แกนคือ แกนนอนและแกนตั้ง

ซีเควนซ์ไดอะแกรม (Sequence Diagram)

​

ข้อสังเกตของ Sequence Diagram 

​

• 1. Sequence Diagram ช่วยให้นักวิเคราะห์ระบบทราบว่า คลาสใดควรจะมี Operation/Method ใดบ้าง
• 2. การเขียนลำดับกิจกรรมในแต่ละ Use Case สามารถเขียนได้อีกลักษณะหนึ่ง คือ แบ่งการปฏิบัติงานออกเป็น 2 ส่วน ได้แก่ ส่วนของ Actor ปฏิบัติ และส่วนของระบบปฏิบัติ

​

คอลลาบอเรชันไดอะแกรม (Collaboration Diagram)

• มีหน้าที่เดียวกันกับซีเควนซ์ไดอะแกรมแต่ไม่แสดงถึงแกนเวลาอย่างชัดเจนยกเว้นการโต้ตอบกัน ระหว่างอ็อบเจกต์สัญลักษณ์ที่ใช้ประกอบด้วย วัตถุ หรือคลาสแทนด้วยรูปสี่เหลี่ยมคล้ายซีเควนซ์ไดอะแกรมมีรูปแบบคือ ชื่ออ็อบเจกต์/บทบาท : ชื่อคลาสและขีดเส้นใต้เพื่อแสดงว่าเป็นอินสแตนซ์ แต่ไม่จำเป็นต้องเรียง ตามแนวนอนเหมือนในซีแควนไดอะแกรมมีเส้นเชื่อมกันระหว่างวัตถุ เรียกว่า ลิงก์ (Link) ซึ่งแต่ละลิงค์มี คำอธิบายแสดงขั้นตอนการทำงานตามทิศทางลูกศรโดยมีตัวเลขลำดับกำกับไว้เพื่อบอกว่าขั้นตอนใดทำก่อนทำ หลังซึ่งแทนแกนเวลาตามด้วยเครื่องหมายทวิภาคและเมสเสจ

​

คอลลาบอเรชันไดอะแกรม (Collaboration Diagram)

​

แอ็กทิวิตีไดอะแกรม (Activity Diagram)

• แอ็กทิวิตีไดอะแกรม (Activity Diagram) แอ็กทิวิตีไดอะแกรม แสดงลำดับกิจกรรมของการทำงาน (work flow) โดยการแสดงทางเลือกที่เกิดขึ้นและขั้นตอนการทำงาน โดยประกอบไปด้วยสถานะต่าง ๆ ที่เกิดขึ้นระหว่าง การทำงาน และผลจากการทำงานในขั้นตอนต่าง ๆ วงกลมสีดำ คือ จุดเริ่มต้น เรียก Initial State วงกลมสีดำ มีวงล้อมอีกชั้น คือ จุดสิ้นสุด เรียก Final State โดยจะอธิบายกิจกรรมในลักษณะของ การกระทำโดยใช้ไดอะแกรมใน UML จะมีลักษณะคล้าย Flow Chart

​

ขั้นตอนในการเขียน  Activity Diagram

• 1. พิจารณากิจกรรมต่าง ๆ ที่ที่ได้จากผลการวิเคราะห์ที่ควรอธิบาย
• 2. พิจารณากิจกรรมย่อยที่เกิดขึ้น เงื่อนไขหรือกรณีต่าง ๆ ที่เกิดขึ้นเมื่อเป็นไปตามเงื่อนไข
• 3. เรียงลำดับกิจกรรมที่เกิดก่อนหลัง
• 4. เขียนกิจกรรมย่อยด้วยสัญลักษณ์แสดงกิจกรรม
• 5. เขียนจุดเริ่มต้น
• 6. เขียนจุดสิ้นสุด

​

คุณสมบัติของ Activity Diagram ที่ดี

• 1.  มุ่งเน้นการติดต่อสื่อสารของระบบในเชิงไดนามิกส์
• 2. เฉพาะอิลิเมนต์ที่มีความสำคัญต่อกระบวนการทำงานเท่านั้น
• 3. แสดงรายละเอียดในแต่ละระดับการทำงาน โดยเลือกแสดง เฉพาะที่มีความสำคัญต่อการเข้าใจการทำงานของระบบเท่านั้น
• 4. ถ้าการทำงานส่วนใดมีความสำคัญ ก็ควรเขียน Activity Diagram ไม่ควรละเอาไว้หรือแสดงเพียงอย่างย่อ ๆ

​

คุณสมบัติของ Activity Diagram ที่ดี

​

​

คอมโพเนนต์ไดอะแกรม Component Diagram)

• คอมโพเนนต์ไดอะแกรม (Component Diagram) คอมโพเนนต์ไดอะแกรม เป็นไดอะแกรมที่แสดงโครงสร้างทางกายภาพของ Software โดยจะประกอบด้วยองค์ประกอบซึ่งอยู่ในรูปต่าง ๆ เช่น Binary, text และ Executeable ภายใน Component Diagram ก็จะมีความสัมพันธ์แสดงอยู่เช่นเดียวกับ Class Diagram, Object Diagram เป็นไดอะแกรมที่แสดงโครงสร้างและความเกี่ยวข้องกันของซอฟต์แวร์โดยคอมโพเนนต์ ประกอบไปด้วย source code และ runtime หรือ executable component

​

​

​

คอมโพเนนต์ไดอะแกรม (Component Diagram)

​

​

ดีพลอยเมนต์ไดอะแกรม (Deployment Diagram)

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

​

​

ดีพลอยเมนต์ไดอะแกรม (Deployment Diagram)

​

หน่วยที่ 6 USE CASE DIAGRAM

สาระการเรียนรู้

•   1. Use Case Diagram
• 2. สัญลักษณ์ความสัมพันธ์
• 3. การสร้าง Use Case Diagram
• 4. ข้อแนะนำในการสร้าง Use Case Diagram
• 5. การเขียนคำอธิบาย Use Case
• 6. ตัวอย่าง Use Case Diagram ของระบบการลงทะเบียนของนักศึกษา

​

​

จุดประสงค์การเรียนรู้

•   1. อธิบายวิธีการออกแบบการทำงานได้
• 2. อธิบายสัญลักษณ์ทั่วไปของ UML ได้
• 3. อธิบายวัตถุประสงค์ของ Use Case Diagram และ Interaction Diagrams
• 4. อธิบายวิธีการสร้างแผนภาพ Interaction Diagrams แบบ Sequence Diagram
• 5. ประยุกต์การออกแบบ Operation และแผนภาพ Interaction Diagram

​

สมรรถนะการเรียนรู้

•   1. แสดงความรู้เกี่ยวกับการออกแบบ Operation และแผนภาพ Interaction Diagram
• 2. แสดงความรู้เกี่ยวกับการสร้างแผนภาพ Interaction Diagrams แบบ Sequence Diagram
• 3. ปฏิบัติการสร้าง Use Case Diagram และ Sequence Diagram

​

Use Case Diagram

•  Use Case Diagram เป็นแผนภาพที่ใช้แสดงให้ทราบว่าระบบทำงานหรือมีหน้าที่ใดบ้าง โดยมีสัญลักษณ์รูปวงรีแทน Use Case และสัญลักษณ์รูปคน (Stick Man Icon) แทน Actor สำหรับชื่อ Use Case นั้น ให้ใช้คำกริยาหรือกริยาวลี (คำกริยามีกรรมมารองรับ)

Use Case Diagram

สัญลักษณ์ความสัมพันธ์

• Use Case คือ หน้าที่ที่ระบบต้องกระทำใช้สัญลักษณ์รูปวงรี พร้อมทั้งเขียนชื่อ Use Case หรือ Use Case Name ซึ่งต้องใช้คำกริยาหรือกริยาวลีก็ได้ 

Use Case Name

สัญลักษณ์ความสัมพันธ์

• Actor คือ ผู้เกี่ยวข้องกับระบบ ซึ่งรวมทั้ง Primary Actor และ Stakeholder Actor ที่เป็นมนุษย์ ในที่นี้จะใช้สัญลักษณ์รูปคน (Stick Man Icon) เหมือนกัน พร้อมทั้งเขียนชื่อ Actor ไว้ด้านล่างของสัญลักษณ์ด้วย

​

สัญลักษณ์ความสัมพันธ์

​

•  System Boundary เส้นแบ่งขอบเขตระหว่างการทำงานของระบบกับผู้ใช้งานผ่านระบบ (Use Case กับ Actor) โดยจะใช้รูปสี่เหลี่ยมเป็นสัญลักษณ์ พร้อมทั้งเขียนชื่อระบบไว้ด้านใน โดยการใส่ชื่อระบบที่ทำงานนั้น ๆ

​

สัญลักษณ์ความสัมพันธ์

• Connection คือ เส้นที่ลากเชื่อมต่อระหว่าง Actor กับ Use Case ที่มีปฏิสัมพันธ์กัน ใช้เส้นตรงไม่มีหัวลูกศรเป็นสัญลักษณ์ของ Connection ส่วน Connection ที่ใช้เชื่อมต่อระหว่าง Use Case กับ Use Case กรณีที่ Use Case นั้นมีความสัมพันธ์ซึ่งกันและกัน จะใช้สัญลักษณ์เส้นตรงมีหัวลูกศร พร้อมทั้งเขียนชื่อความสัมพันธ์ไว้ตรงกลางเส้นด้วย โดยเขียนไว้ภายในเครื่องหมาย <<...>>

​

สัญลักษณ์ความสัมพันธ์

• Extend Relationship เป็นความสัมพันธ์แบบขยายหรือเพิ่ม เกิดขึ้นในกรณีที่บาง Use Case ดำเนินกิจกรรมของตนเองไปตามปกติ แต่อาจจะมีเงื่อนไขหรือสิ่งกระตุ้นบางอย่างที่ส่งผลให้กิจกรรมตามปกติของ Use Case นั้นถูกรบกวนจนเบี่ยงเบนไป

​

สัญลักษณ์ความสัมพันธ์

สัญลักษณ์ความสัมพันธ์

• Gen

สัญลักษณ์ความสัมพันธ์

• Include Relationship ความสัมพันธ์อีกรูปแบบหนึ่งของ Use Case Diagram คือ ความสัมพันธ์แบบเรียกใช้ เกิดขึ้นในกรณีที่ Use Case หนึ่งไปเรียกหรือดึงกิจกรรมของอีก Use Case หนึ่งมาใช้เพื่อให้กิจกรรมนั้น เกิดขึ้นจริงใน Use Case ของตนเอง หรือกล่าวให้ง่ายกว่านั้นคือกิจกรรมใน Use Case หนึ่งอาจจะถูกผนวก เข้าไปรวมกับกิจกรรมของอีก Use Case หนึ่ง เรียกความสัมพันธ์ระหว่าง Use Case ในลักษณะนี้ว่า "Include Relationship" โดย Use Case ที่ทำหน้าที่ดึงกิจกรรมมาจาก Use Case อื่นๆ เรียกว่า "Base Use Case" ในขณะที่ Use Case ถูกเรียกหรือถูกดึงกิจกรรมมาใช้ เรียกว่า "Included Use Case" สามารถเขียนเส้น Connection ได้ในทิศทางตรงกันข้ามกับ Extend Relationship โดยเริ่มต้นลากเส้นตรงจาก Base Use Case หันลูกศรชี้ไปที่ Included Use Case แล้วเขียนชื่อ Relationship "<<uses>>" (บางตำราจะใช้คำว่า <<include>>) ไว้ตรงกลางเส้นด้วย

การสร้าง Use Case Diagram

• 1. ค้นหา Actor
• 2. ค้นหา Use Case ที่มีปฏิสัมพันธ์กับ Actor นั้นโดยตรง
• 3. ค้นหาและสร้างความสัมพันธ์ระหว่าง Use Case หรือ Actor (ถ้ามี) แล้วเพิ่มเติม Use Case ใหม่ซึ่งอาจเป็น Included Use Case, Extending Use Case ที่เพิ่มเติมจาก Base Use Case ที่มีอยู่แล้ว หรือจะเพิ่ม Base Use Case ใหม่ก็ได้ (ถ้ามี)

​

การสร้าง Use Case Diagram

• 4. ต้องไม่มี Actor ใดเลยที่ไม่มีปฏิสัมพันธ์กับ Use Case
• 5. ต้องไม่มี Use Case ใดเลยที่ไม่มีปฏิสัมพันธ์กับ Actor
• 6. Use Case ทุกตัวต้องมีปฏิสัมพันธ์อย่างใดอย่างหนึ่งกับ Actor หรือ Use Case ตัวอื่นๆเสมอ
• 7. เขียนคำอธิบายแต่ละ Use Case จนครบถ้วน

​

​

ข้อแนะนำในการสร้าง Use Case Diagram

• 1. Use Case Diagram ใช้เพื่อแสดงให้เห็นถึงข้อมูลความต้องการของผู้ใช้ระบบเท่านั้น
• 2. Use Case Diagram อาจมีความละเอียดมากหรือน้อยก็ได้
• 3. ให้ตระหนักอยู่เสมอว่า Use Case Diagram
• 4. Use Case Diagram โดยส่วนใหญ่จะไม่แสดงให้เห็นถึงการทำงานในระดับการจัดการข้อมูลในฐานข้อมูล

​

ข้อแนะนำในการสร้าง Use Case Diagram

• 5. จากข้อ 4 สิ่งที่ควรนำมาแสดงใน Use Case Diagram คือ หน้าที่หลัก ๆ หรือหน้าที่ที่เป็นจุดเด่นของระบบที่ผู้ใช้งานต้องการให้ระบบกระทำได้อย่างแท้จริงเท่านั้น
• 6. จากข้อ 5 คำว่า “หน้าที่หลักหรือหน้าที่ที่เป็นจุดเด่นของระบบ” ในที่นี้หมายถึง หน้าที่ที่ระบบจะต้องกระทำ (System Operate) ตามความต้องการของผู้ใช้ ไม่ใช่หน้าที่ที่ผู้ใช้จะต้องกระทำ (Human Operate) อันเนื่องจากการทำงานของระบบ

​

การเขียนคำอธิบาย Use Case

• 1.  Main Flow คือ ลำดับกิจกรรม เมื่อ Use Case ดำเนินกิจกรรมตามปกติ โดยการเขียนคำอธิบายในลักษณะเป็นย่อหน้า (Paragraph) และ Main Flow จะต้องมีเพียงหนึ่งเดียวเท่านั้น
• 2.  Exceptional Flow คือ ลำดับกิจกรรม เมื่อ Use Case ดำเนินกิจกรรมผิดจากปกติ โดยสามารถมีมากกว่า 1 Flow

​

หน่วยที่ 7�การออกแบบ OPERATION และแผนภาพ INTERACTION DIAGRAM

สาระการเรียนรู้

• 1. การออกแบบการทำงาน (Operation)
• 2. สัญลักษณ์ทั่วไปของ UML
• 3. วัตถุประสงค์ของ Use Case Diagram
• 4. ประโยชน์ของ Use Case Diagram
• 5. ขั้นตอนการสร้าง Use Case Diagram

​

สาระการเรียนรู้

• 6. การปฏิสัมพันธ์ (Interaction)
• 7. ความหมายของ Interaction Diagrams
• 8. วัตถุประสงค์ของ Interaction Diagrams
• 9. วิธีการสร้างแผนภาพ Interaction Diagrams แบบ Sequence Diagram
• 10. ขั้นตอนการสร้าง Sequence Diagram

​

จุดประสงค์การเรียนรู้

• 1. บอกความหมายของการออกแบบการทำงานได้
• 2. อธิบายวัตถุประสงค์และประโยชน์ของ Use Case Diagram ได้
• 3. อธิบายความหมาและวัตถุประสงค์ของ Interaction Diagrams ได้
• 4. อธิบายวิธีการสร้างแผนภาพ Interaction Diagrams แบบ Sequence Diagram ได้
• 5. ประยุกต์การออกแบบ Operation และแผนภาพ Interaction Diagram ได้

​

สมรรถนะการเรียนรู้

• 1. แสดงความรู้เกี่ยวกับการออกแบบการทำงาน
• 2. แสดงความรู้เกี่ยวกับ Use Case Diagram และ Interaction Diagrams
• 3. ปฏิบัติการออกแบบ Operation และแผนภาพ Interaction Diagram

​

การออกแบบการทำงาน (Operation)

• การออกแบบการทำงาน เป็นกระบวนการกำหนดงานเฉพาะอย่างที่จะต้องทำวิธีการที่ใช้ในการทำงาน และวิธีการที่เกี่ยวข้องกับงานอื่น ๆ ในองค์กร หรือเป็นกระบวนการของ การกำหนดงานของพนักงานตามลักษณะโครงสร้างให้สอดคล้องกับลักษณะของบุคคลเพื่อให้ บรรลุผลสำเร็จตามวัตถุประสงค์ขององค์กร

กระบวนการออกแบบงาน

• 1. ลักษณะเฉพาะอย่างของแต่ละงาน (the specification of individual tasks) หมายถึง งานที่แตกต่างที่พนักงานแต่ละคนทำ
• 2. ลักษณะเฉพาะอย่างของวิธีการปฏิบัติงาน (the specification of the method of performing each task) หมายถึง งานแต่ละงานมีวิธีการทำอย่างไร
• 3. การรวมแต่ละงานให้เป็นงานเฉพาะของแต่ละคน (the combination of individual tasks into specific jobs to be assigned to individuals) หมายถึง วิธีการที่งานในหน้าที่ที่แตกต่าง ได้รับการรวบรวมขึ้นเพื่อสร้างรูปแบบงาน

​

วัตถุประสงค์ของ Use Case Diagram

• 1. อธิบายเรื่องราวของ Problem Domain ทั้งหมด (Domain คือ กรอบหรือขอบเขตที่สนใจ)
• 2. บอกส่วนประกอบในระบบ (ระบบประกอบด้วยระบบย่อยอะไรบ้าง)
• 3. บอกความสัมพันธ์ของส่วนต่าง ๆ ในระบบ

​

ประโยชน์ของ Use Case Diagram

• 1. ช่วยให้ผู้พัฒนาระบบสามารถแยกแยะกิจกรรมที่อาจจะเกิดขึ้นในระบบ
• 2. เป็น Diagram พื้นฐาน ที่สามารถอธิบายสิ่งต่าง ๆ ได้โดยใช้รูปภาพที่ไม่ซับซ้อน
• 3. Use Case Diagram จะมีประสิทธิภาพ หากผู้เขียนมีความเข้าใจในProblem Domain อย่างแท้จริง

​

ขั้นตอนการสร้าง Use Case Diagram

• 1. ค้นหา Actor
• 2. ค้นหา Use Case ที่มีปฏิสัมพันธ์กับ Actor นั้นโดยตรง
• 3. ค้นหาและสร้างความสัมพันธ์ระหว่าง Use Case หรือ Actor (ถ้ามี) แล้วเพิ่มเติม Use Case ใหม่ ซึ่ง อาจเป็น Included Use Case, Extending Use Case ที่เพิ่มเติมจาก Base Use Case ที่มีอยู่แล้ว หรือจะเพิ่ม Base Use Case ใหม่ก็ได้ (ถ้ามี)

​

ขั้นตอนการสร้าง Use Case Diagram

• 4. ต้องไม่มี Actor ใดเลยที่ไม่มีปฏิสัมพันธ์กับ Use Case
• 5. ต้องไม่มี Use Case ใดเลยที่ไม่มีปฏิสัมพันธ์กับ Actor
• 6. Use Case ทุกตัวต้องมีปฏิสัมพันธ์อย่างใดอย่างหนึ่งกับ Actor หรือ Use Case ตัวอื่น ๆ เสมอ
• 7. เขียนคำอธิบายแต่ละ Use Case จนครบถ้วน

​

การปฏิสัมพันธ์ (Interaction)

• การปฏิสัมพันธ์ (Interaction) คือ การสื่อสารระหว่างผู้ใช้กับระบบ โดยที่ระบบมีส่วนต่อประสานเป็นทั้งส่วนที่ผู้ใช้สนใจและเป็นเหมือนคน สนทนา/ตัวกลางระหว่างผู้ใช้และระบบ เริ่มจากผู้ใช้ป้อนคำสั่ง/ออกคําสั่งแก่ ส่วนต่อประสานจากนั้นเป็นหน้าที่ของส่วนต่อประสานที่จะดำเนินการตามคําสั่ง ดังนั้นการสื่อสารระหว่างผู้ใช้และระบบมีความหมายคือเป็นภาษาทางอ้อม (Indirect language) แทนที่จะเป็นการกระทำโดยตรง (Direct Action)

​

ความหมายของ Interaction Diagrams

• Interaction Diagrams คือ แผนภาพที่อธิบายการโต้ตอบระหว่างองค์ประกอบต่าง ๆ ในแบบจำลอง การโต้ตอบนี้เป็นส่วนหนึ่งของพฤติกรรมแบบไดนามิกซ์ของระบบ วัตถุประสงค์พื้นฐานของไดอะแกรมทั้งสองมีความคล้ายคลึงกัน แผนภาพลำดับจะเน้นที่ลำดับเวลาของข้อความและแผนภาพการทำงานร่วมกันจะเน้นที่การจัดโครงสร้างของวัตถุที่ส่งและรับข้อความ

​

ความหมายของ Interaction Diagrams

• 1. Cell หมายถึง Message ที่ Sender ใช้เรียก Method ของ Receiver
• 2. Return หมายถึง Message ที่ใช้เพื่อส่งข้อมูลที่ถูกร้องขอโดย Sender จาก Receiver กลับไปยัง Sender
• 3. Send หมายถึง สัญญาณบางอย่างที่ Object ตัวหนึ่งส่งไปเพื่อบอกหรือกระตุ้น Object อีกตัวหนึ่ง โดยไม่ใช่ การเรียกใช้ Method ของ Object ที่ถูกกระตุ้น
• 4. Create หมายถึง Message ที่ Object ตัวหนึ่งส่งไปโดยมีจุดประสงค์เพื่อให้เกิดการสร้าง Object ของ Class ขึ้น
• 5. Destroy หมายถึง Message ที่ Object ตัวหนึ่ง ส่งไปยัง Object อีกตัวหนึ่ง เพื่อให้ Object ที่ได้รับ Message ทำลายตัวเอง

​

วัตถุประสงค์ของ Interaction Diagrams

• วัตถุประสงค์ของ Interaction Diagrams คือการเห็นภาพพฤติกรรมการโต้ตอบของระบบ การมองเห็นการโต้ตอบเป็นเรื่องยาก ดังนั้นการแก้ปัญหาคือการใช้รูปแบบต่าง ๆ เพื่อจับภาพแง่มุมต่าง ๆ ของการมีปฏิสัมพันธ์ แผนภาพSequence diagram และ Collaboration diagram.จะใช้ในการจับภาพธรรมชาติแบบไดนามิกแต่จากมุมที่แตกต่าง

​

วิธีการสร้างแผนภาพ Interaction Diagrams แบบ Sequence Diagram

หน่วยที่ 8 การออกแบบการโต้ตอบระหว่างออบเจ็ค

สาระการเรียนรู้

• 1. การออกแบบอินเตอร์เฟส
• 2. รูปแบบของการโต้ตอบระหว่างผู้ใช้กับระบบ
• 3. การเชื่อมความสัมพันธ์
• 4. Stereotype
• 5. ความสัมพันธ์ระหว่าง Use Case
• 6. ไดอะแกรม (diagram)
• 7. ประเภทของไดอะแกรม
• 8. บุคลากรที่เกี่ยวข้องในไดอะแกรมแต่ละประเภท

​

จุดประสงค์การเรียนรู้

• 1. บอกความหมายของการออกแบบอินเตอร์เฟสได้
• 2. อธิบายรูปแบบของการโต้ตอบระหว่างผู้ใช้กับระบบได้
• 3. อธิบายความสัมพันธ์ระหว่าง Use Case ได้
• 4. อธิบายประเภทของไดอะแกรมได้
• 5. ประยุกต์ใช้การออกแบบการโต้ตอบระหว่างอ็อบเจกต์ได้

​

​

สมรรถนะการเรียนรู้

• 1. แสดงความรู้เกี่ยวกับการออกแบบอินเตอร์เฟส
• 2. แสดงความรู้เกี่ยวกับไดอะแกรม
• 3. ปฏิบัติการใช้ไดอะแกรมแต่ละประเภท

​

การออกแบบอินเตอร์เฟส

• การออกแบบอินเตอร์เฟส หรือ UI จะต้องใช้บัญชีความต้องการประสบการณ์ และความสามารถของผู้ใช้ระบบ นักออกแบบควรทราบข้อจำกัดทางกายภาพ และจิตใจของผู้คน (เช่น Limited short-term memory) ควรตระหนักว่า คนจะทำผิดพลาดในเรื่องใดบ้าง หลักการออกแบบอินเตอร์เฟสหรือ UI หลัก ๆ ประกอบด้วย

​

การออกแบบอินเตอร์เฟส

• - User familiarity (ยู'เซอะ ฟะมิลลิแอ'ริที)
• - Consistency (คันซิส'เทินซี)
• - Minimal surprise (มินิมอล เซอไพรซ)
• - Recoverability (รีคัฟ'เวอะรี อะบิลลิที)
• - User guidance (ยู'เซอะ ไกเดินซฺ)
• - User diversity (ยู'เซอะ ไดเวอ'ซิที)

​

รูปแบบของการโต้ตอบระหว่างผู้ใช้กับระบบ

• - การโต้ตอบด้วยการพิมพ์คำสั่ง (Command Line Interaction)
• - การโต้ตอบด้วยเมนูคำสั่ง (Menu Interaction)
• - การโต้ตอบด้วยแบบฟอร์ม (Form Interaction)
• - การโต้ตอบผ่านวัตถุ (Object-Based Interaction)
• - การโต้ตอบด้วยภาษามนุษย์ (Natural Language Interaction)

​

​

การเชื่อมความสัมพันธ์

• 1. ความสัมพันธ์ระหว่าง Actor กับ Use Case
• 2. ความสัมพันธ์ระหว่าง Actor กับ Actor

​

Stereotype (สเทอ'รีโอไทพฺ)

• Stereotype เป็นเทคนิคที่ใช้ในการเพิ่มชนิดสัญลักษณ์ในภาษา UML จากสัญลักษณ์เดิมที่มีอยู่แล้วให้ เป็นสัญลักษณ์ชนิดใหม่
•  

​

ความสัมพันธ์ระหว่าง Use Case

• 1. ความสัมพันธ์แบบ Generalization (เจนนะระไลเซเชิน)
• /Specialization สเปเชียล ไล้เซชั่น
• 2. ความสัมพันธ์แบบ Include อินคลูด(หรือ Use)
• 3. ความสัมพันธ์แบบ Extend เอ็คซเทนด (หรือ Extends ก่อน V 2.0)
•  

​

ไดอะแกรม (diagram)

ประเภทของไดอะแกรม

• 1. Use case Diagram
• 2. Class Diagram
• 3. Object Diagram
• 4. Sequence Diagram
• 5. Collaboration Diagram

​

ประเภทของไดอะแกรม

• 6. Statechart Diagram
• 7. Activity Diagram
• 8. Component Diagram
• 9. Deployment Diagram

​

​

บุคคลากรที่เกี่ยวข้องในไดอะแกรมแต่ละประเภท

​

​

หน่วยที่ 9 การสร้าง CLASS และการสร้าง OBJECT ในโปรแกรม

สาระการเรียนรู้

• 1. การสร้าง Classes
• 2. การสร้างและการใช้งาน Object
• 3. Constructor
• 4. การสร้างอ็อบเจกต์ในภาษา Visual Basic
• 5. การสร้างอ็อบเจกต์ในภาษา C
• 6. การสร้างอ็อบเจ็กต์ในภาษา PHP
• 7. การสร้างคลาสและอ็อบเจ็กต์ภาษา Python

​

​

จุดประสงค์การเรียนรู้

• 1. อธิบายวิธีการสร้างและการใช้งานของ Class และ Object ได้
• 2. อธิบายวิธีการสร้างอ็อบเจกต์ในภาษาต่าง ๆ ได้
• 3. ประยุกต์การสร้างอ็อบเจกต์ในภาษาต่าง ๆ ได้

​

สมรรถนะการเรียนรู้

• 1. แสดงความรู้เกี่ยวกับการสร้าง Class และการสร้าง Object ในโปรแกรม
• 2. ปฏิบัติการสร้าง Class และการสร้าง Object ในภาษาต่าง ๆ
•  

​

การสร้าง Classes

• คลาสเป็นการกำหนดส่วนประกอบต่าง ๆ ที่จะนำไปสร้างอ็อบเจกต์ คลาสจะประกอบไปด้วยสมาชิกสองอย่าง คือ ตัวแปร และ
• เมธอด ตัวแปรใช้สำหรับเก็บข้อมูลต่าง ๆ เกี่ยวกับอ็อบเจกต์ และเมธอดเป็นการกำหนดฟังก์ชันการทำงานของอ็อบเจกต์เป็นรูปแบบการประกาศคลาสในภาษา Java

การสร้าง Classes

class ClassName {

// member variables

// member methods

}

การสร้าง Classes

• ในการสร้างคลาสจะใช้คำสั่ง class และตามด้วยชื่อของคลาสที่คุณจะสร้าง ชื่อคลาสควรเริ่มต้นชื่อด้วยตัวใหญ่และมีหลักการตั้งชื่อเช่นเดียวกับตัวแปร ภายในบล็อกคำสั่งของคลาสจะมีสมาชิกที่เป็นทั้งตัวแปรและเมธอด หรืออย่างใดอย่างหนึ่งก็ได้ มาดูตัวอย่างการสร้างคลาสในภาษา Java

​

การสร้างและการใช้งาน Object

• หลังจากที่สร้างคลาสแล้ว ต่อไปเป็นการนำคลาสมาสร้างอ็อบเจกต์ จะนำคลาส Person มาสร้างอ็อบเจกต์สำหรับตัวอย่างต่อไป

​

Constructor

• คอนสตรักเตอร์ (constructor) นั้นคือ เมธอดพิเศษที่จะทำงานเมื่ออ็อบเจกต์ถูกสร้างขึ้น มักใช้คอนสตักเตอร์ในการกำหนดค่าเริ่มต้นให้กับอ็อบเจกต์ ตัวอย่างการสร้างและใช้งานคอนสตรักเตอร์ในภาษา Java

​

การสร้างอ็อบเจกต์ในภาษา Visual Basic

• การสร้างอ็อบเจกต์ในภาษา Visual Basic จะใช้คลาส Person มาสร้างอ็อบเจกต์ โดยสร้างคอนสตรักเตอร์นั้นจะต้องมีชื่อเหมือนคลาสและกำหนดระดับการเข้าถึงของ

อ็อบเจกต์นั้น ๆ ด้วย

​

การสร้างอ็อบเจกต์ในภาษา C

• ในการที่จะสร้างอ็อบเจกต์ในภาษา C จะขอยกตัวอย่างคลาสง่าย ซึ่งจะเป็นคลาสของรูปสี่เหลี่ยมในสองมิติ

การสร้างอ็อบเจกต์ในภาษา PHP

• ในการที่จะสร้างอ็อบเจกต์ในภาษา PHP จะขอยกตัวอย่างคลาสง่าย ซึ่งจะนำคลาส User โดยมีโค้ดที่ได้สร้างไว้มาสร้าง อ็อบเจกต์

การสร้างคลาสและออบเจ็คภาษา Python

• ภาษา Python จะแนะนำให้รู้จักกับแนวคิดของการเขียนโปรแกรมเชิงวัตถุ (Object oriented programming หรือ OOP) เช่นเดียวกับภาษาอื่นๆ Python ถือเป็นหนึ่งในภาษาที่เป็น OOP โดยพื้นฐาน อย่างไรก็ตาม แนวคิดการเขียนโปรแกรมเชิงวัตถุในภาษา Python นั้นอาจจะแตกต่างจากภาษาอื่นเล็กน้อย เช่น สามารถสืบทอดจากหลายคลาสได้ในเวลาเดียวกัน และมันไม่มีคุณสมบัติการห่อหุ้มข้อมูลและไม่มี Interfaces เป็นต้น

​

หน่วยที่ 10 การวิเคราะห์และออกแบบโปรแกรมทางธุรกิจ

สาระการเรียนรู้

• 1. ความหมายของการวิเคราะห์และออกแบบโปรแกรม
• 2. นักวิเคราะห์ระบบ (System Analysis)
• 3. กิจกรรมต่าง ๆ ของระบบการประมวลผลข้อมูล
• 4. การวิเคราะห์ปัญหา
• 5. การวางแผนงานเพื่อศึกษาปัญหา
• 6. การศึกษาผลกระทบของระบบงาน

สาระการเรียนรู้

• 7. การเขียนรายงานแสดงหัวข้อปัญหา
• 8. สิ่งที่ควรจะมีในรายงานแสดงหัวข้อปัญหา
• 9. การทำแผนภาพตารางเวลา
• 10. การศึกษาความเหมาะสม
• 11. การออกแบบโปรแกรม
• 12. การออกแบบแฟ้มข้อมูลและฐานข้อมูล

​

สาระการเรียนรู้

• 13. หลักการออกแบบข้อมูลนำเข้า
• 14. การออกแบบข้อมูลนำเข้าทางจอภาพ
• 15. สิ่งที่ควรศึกษาในการออกแบบฟอร์ม
• 16. ขั้นตอนการพัฒนาโปรแกรม
• 17. การทดสอบการใช้งานของโปรแกรม
• 18. การทดสอบระบบ
• 19. การจัดทำเอกสารและคู่มือและการใช้งานของโปรแกรม
• 20. การปรับปรุงและพัฒนาโปรแกรม

​

​

จุดประสงค์การเรียนรู้

• 1. บอกความหมายของการวิเคราะห์และออกแบบโปรแกรมได้
• 2. อธิบายการวิเคราะห์และวางแผนเพื่อศึกษาปัญหาได้
• 3. อธิบายการเขียนรายงานแสดงหัวข้อปัญหาได้
• 4. อธิบายหลักการออกแบบโปรแกรมได้
• 5. ประยุกต์การออกแบบและเขียนโปรแกรมได้

สมรรถนะการเรียนรู้

• 1. แสดงความรู้เกี่ยวกับการวิเคราะห์โปรแกรมทางธุรกิจ
• 2. แสดงความรู้เกี่ยวกับการออกโปรแกรมทางธุรกิจ
• 3. ปฏิบัติการวิเคราะห์และออกโปรแกรมทางธุรกิจ

​

ความหมายของการวิเคราะห์และออกแบบโปรแกรม

• คำว่า วิเคราะห์มาจากคำว่า พิเคราะห์ ซึ่งเป็นการเปลี่ยน พ เป็น ว ในภาษาไทยซึ่งแปลความหมายได้ว่า การพินิจพิเคราะห์ การพิจารณา การใคร่ครวญ การไต่สวนความหรือเรื่องราว ส่วนในภาษาอังกฤษก็ได้ให้ความหมายใกล้เคียงกันคือ Determine, Examine และ Investigate ซึ่งคำว่าวิเคราะห์นี้สามารถนำไปใช้กับวิชาการต่าง ๆ ได้มากมาย เช่น การวิเคราะห์โครงสร้าง การวิเคราะห์เชิงคุณภาพ การวิเคราะห์เชิงปริมาณ การวิเคราะห์ปัญหา เป็นต้น 

​

นักวิเคราะห์ระบบ (System Analysis)

• นักวิเคราะห์ระบบ (System Analysis) คือ บุคคลที่ศึกษาปัญหาซับซ้อนที่เกิดขึ้นในระบบและแยกแยะปัญหาเหล่านั้นอย่างมีหลักเกณฑ์ นักวิเคราะห์ระบบหรือที่เราเรียกกันว่า SA จะทำหน้าที่หาวิธีการแก้ไขปัญหาที่แยกแยะเหล่านั้น พร้อมทั้งให้เหตุผลด้วยการวิเคราะห์ระบบนั้น นักวิเคราะห์ระบบจะต้องกำหนดขอบเขตของการวิเคราะห์ และต้องกำหนดจุดมุ่งหมายหรือเป้าหมายในการวิเคราะห์นั้นด้วย นอกจากนี้ยังต้องทำความเข้าใจโครงสร้างลักษณะขององค์การนั้นในด้านต่าง ๆ 

​

กิจกรรมต่าง ๆ ของระบบการประมวลผลข้อมูล 

• 1. เป็นผู้ที่ทำการวิเคราะห์ระบบงาน เพื่อค้นหาปัญหาต่าง ๆ ที่เกิดขึ้นของระบบ
• 2. เป็นผู้สร้างวิธีการที่เห็นว่าดีที่สุดหรือเหมาะสมที่สุดในการปฏิบัติงาน
• 3. นักวิเคราะห์ระบบจะต้องทำการพัฒนาระบบงานที่ได้ออกแบบระบบไว้
• 4. นักวิเคราะห์ระบบงานจะต้องทำการทดสอบระบบที่ได้ออกแบบขึ้นมาใหม่ให้มีความถูกต้อง
• 5. นักวิเคราะห์ระบบงานจะเป็นผู้ที่มีบทบาทในการติดตั้งระบบใหม่
• 6. นักวิเคราะห์ระบบงานจะต้องติดตามผลงานการปฏิบัติงานของระบบที่ได้ติดตั้งไว้

การวิเคราะห์ปัญหา 

• 1. ความปลอดภัยในการเก็บรักษาข้อมูลขององค์กร ความเข้มงวดหรือมาตรการการรักษาความปลอดภัยที่ไม่ได้มาตรฐาน อาจจะนำไปสู่ปัญหาของระบบที่ใช้อยู่ในปัจจุบัน 
• 2. การกำหนดอำนาจหน้าที่ของบุคคลในการใช้ข้อมูลในระบบว่าบุคคลใดจะสามารถใช้ข้อมูลอะไรบ้าง 
• 3. การกำหนดจุดมุ่งหมายของระบบข้อมูลที่มีอยู่ ว่าจะถูกนำไปใช้ในลักษณะใดเพื่ออะไร ยังไม่ชัดเจน ทำให้นำไปสู่ความขัดแย้งกันในระบบข้อมูลปัจจุบัน 

​

การวิเคราะห์ปัญหา 

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

การวางแผนงานเพื่อศึกษาปัญหา 

• 1. การกำหนดหัวเรื่องของปัญหา (Subject) 
• 2. กำหนดขอบเขตของปัญหา (Scope) 
• 3. การกำหนดจุดประสงค์หรือเป้าหมายของการศึกษา (Objective)

​

การศึกษาผลกระทบของระบบงาน 

• 1. ใครที่จะโดนกระทบ (Who) 
• 2. ระบบงานจะส่งผลกระทบอย่างไร (How) นักวิเคราะห์ระบบจะต้องทำความเข้าใจว่าระบบงานที่พัฒนาขึ้นจะมีผลกระทบกับใครบ้างโดยบุคคลที่โดยกระทบอยู่ตำแหน่งใดของธุรกิจ

การเขียนรายงานแสดงหัวข้อปัญหา 

• รายงานแสดงหัวข้อปัญหาเป็นรายงานสั้น ๆ แสดงถึงความคืบหน้าในการศึกษาเบื้องต้นของการวิเคราะห์ระบบ และแสดงหัวข้อหลักของระบบที่จะทำการศึกษา ในรายงานฉบับนี้นักวิเคราะห์ระบบจะต้องเขียนคำอธิบายให้ชัดเจนถึงปัญหาที่เกิดขึ้น ถ้าไม่สามารถชี้แจงได้ชัดเจนจะเป็นผลทำให้ผู้ว่าจ้างหรือผู้บริหารขาดความมั่นใจในความสามารถของนักวิเคราะห์ระบบ 

​

สิ่งที่ควรจะมีในรายงานแสดงหัวข้อปัญหา

• แนะนำถึงลักษณะของปัญหาทั่วไป เช่น หัวเรื่องของปัญหา (Subject) ขอบเขตของปัญหา (Scope) เป้าหมายในการแก้ปัญหา (Objectives)
• อธิบายถึงแนวทางเบื้องต้นในการแก้ปัญหา
• แสดงให้เห็นถึงส่วนที่ก่อให้เกิดปัญหา และก่อนที่ไปเกี่ยวข้องกับข้อมูล
• ให้คำนิยามของปัญหาที่เกิดขึ้นอย่างกระจ่างแจ้งชัดเจน

​

สิ่งที่ควรจะมีในรายงานแสดงหัวข้อปัญหา

• เน้นให้เห็นถึงเป้าหมายในการศึกษาเพื่อทำการแก้ไขปรับปรุง
• ให้คำแนะนำที่ดีเกี่ยวกับปัญหาที่เกิดขึ้น
• อธิบายถึงหลักการหือเหตุผลในการแก้ไข จากแนวความคิดของนักวิเคราะห์ระบบเอง ถ้ามีความจำเป็น
• ให้กราฟรูปภาพ กราฟข้อมูล DFD รูปภาพ แผนภูมิในการอธิบายถึงปัญหาถ้าจำเป็น

​

​

การทำแผนภาพตารางเวลา 

• ในการวางแผนและวิเคราะห์ระบบ วงจรพัฒนาระบบ (SDLC) เป็นแผนภาพรวมของการศึกษา ในการวิเคราะห์ระบบ ตารางเวลาที่วางไว้อาจจะเปลี่ยนแปลงได้ทุกเวลา ตารางที่กำหนดขึ้นนี้เป็นเพียงแนวทางของนักวิเคราะห์ระบบว่าจะทำอะไรเมื่อใด การทำตารางเวลานี้นักวิเคราะห์ระบบจะต้องเข้าใจชัดเจนถึงปัญหาที่เกิดขึ้น หมายถึง การกำหนดปัญหา (Problem Definition)

การศึกษาความเหมาะสม  

• ขั้นตอนของการศึกษาความเหมาะสมนี้เป็นขั้นตอนของการวิเคราะห์เบื้องต้น เพื่อเป็นการศึกษาและใช้ประกอบการตัดสินใจว่าจะพัฒนาระบบที่ใช้อยู่เดิมให้มีประสิทธิภาพยิ่งขึ้นหรือจะพัฒนาระบบใหม่ทั้งหมด ในขึ้นตอนที่นักวิเคราะห์ระบบจะต้องทำความเข้าใจสภาพแวดล้อมของการทำงานในปัจจุบัน

​

การออกแบบโปรแกรม

• 1. การบรรลุวัตถุประสงค์หรือความต้องการของผู้ใช้ 
• 2. การใช้ทรัพยากรอย่างเหมาะสม 
• 3. การหลีกเลี่ยงความซับซ้อน 
• 4. ระบบงานมีมาตรฐานเดียวกัน 

​

การออกแบบโปรแกรม

• 5. ความถูกต้องและเชื่อถือได้ของระบบ 
• 6. ความยืดหยุ่นของระบบ 
• 7. ระบบงานได้ถึงเอาข้อดีจากอดีตมารวมไว้ 
• 8. ระบบงานให้ผลลัพธ์ที่เข้าใจได้ต่อผู้ใช้ระบบ 

การออกแบบแฟ้มข้อมูลและฐานข้อมูล 

• 1. แฟ้มข้อมูลแบบอนุกรม (Sequential) 
• 2. แฟ้มข้อมูลแบบแรนดอม (Random/Direct) 
• 3. แฟ้มข้อมูลไอแซม (ISAM: Sequential Access Mode) 

​

หลักการออกแบบข้อมูลนำเข้า 

• 1.  ควรมีลักษณะที่ง่ายต่อการกรอก 
• 2. ตรงกับวัตถุประสงค์ที่ต้องการ 
• 3. การออกแบบต้องให้ตรวจสอบความถูกต้องได้ 
• 4. มีลักษณะที่ดึงดูดต่อผู้ใช้   

การออกแบบข้อมูลนำเข้าทางจอภาพ 

• 1. พยายามให้การแสดงข้อมูลบนจอภาพดูเรียบงายไม่ซับซ้อน 
• 2. พยายามให้การแสดงผลบนจอภาพมีมาตรฐานแบบเดียวกัน 
• 3. จะเน้นให้เห็นถึงความแตกต่างของข้อมูลบางอย่างที่ต้องการ 
• 4. เป็นการโต้ตอบระหว่างผู้ใช้ระบบกับจอภาพให้เป็นไปโดยธรรมชาติที่สุด  

​

สิ่งที่ควรศึกษาในการออกแบบฟอร์ม 

• 1. ควรรู้ถึงชนิดของเครื่องพิมพ์ที่ใช้ทำการพิมพ์แบบฟอร์มรายงาน
• 2. การเขียนรูปแบบของรายงานลงบนแผนผังร่างรายงาน
• 3. รูปแบบของกระดาษรายงาน

​

ขั้นตอนการพัฒนาโปรแกรม

• 1.  ศึกษาวิเคราะห์ปัญหาหรือโจทย์
•  (Problem Analysis)                                                                         
• 2.  ออกแบบโปรแกรม 
• (Program Design)                                                                                               
• 3.  เขียนโปรแกรม (Program Coding)                                                                                                       
• 4.  ทดสอบโปรแกรม (Program Testing)                                                                                                   
• 5.  เขียนเอกสารประกอบโปรแกรม (Documentation)

​

การทดสอบการใช้งานของโปรแกรม (Program testing)

• 1.  ทดสอบการทำงานของแต่ละโปรแกรม
• 2.  สร้างข้อมูลสำหรับทดสอบโปแกรม
• 3.  ทดสอบการทำงานของชุดโปรแกรม
• 4.  ทดสอบการสำรองแฟ้มข้อมูลและการเริ่มทำงานของระบบใหม่ การทดสอบเหล่านี้มีความจำเป็นในกรณีที่ระบบที่เกิดความผิดพลาดขึ้นมาอย่างกะทันหัน ซึ่งการสำรองแฟ้มข้อมูลตามระยะเวลาที่เหมาะสมก็จะช่วยให้การนำข้อมูลที่เสียไปนั้นกลับขึ้นมาอย่างง่ายดาย รวมทั้งการเริ่มทำงานใหม่ก็ต้องถูกต้องด้วย
• 5.   เขียนเอกสารประกอบโปรแกรม

การทดสอบระบบ (System testing)

• 1. การทดสอบแบบกล่องดำ (Black Box Testing)
• 2. การทดสอบแบบกล่องขาว (White Box Testing)

​

การจัดทำเอกสารและคู่มือการใช้งานของโปรแกรม

• คู่มือการใช้
• คู่มือการปฏิบัติการ 
• เอกสารประกอบการฝึกอบรม

การปรับปรุงและพัฒนาโปรแกรม

การแปลงข้อมูล (Data Conversion)

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

การปรับปรุงและพัฒนาโปรแกรม

• การติดตั้งและปรับเปลี่ยนระบบ (Installation and Conversion System)
• ส่วนการปรับเปลี่ยนระบบ (Conversion System) นั้น บางครั้งได้มีการติดตั้งระบบไว้แล้ว อาจจะต้องมีการปรับเปลี่ยนระบบเพื่อให้เหมาะสมมากยิ่งขึ้น การปรับเปลี่ยนไปสู่สิ่งใหม่ย่อมมีผลกระทบต่อผู้ใช้งานบางกลุ่มยังคงมีความคุ้นเคยกับวิธีการดำเนินงานแบบเก่า รวมทั้งข้อจำกัดในเรื่องความพร้อมในการเปลี่ยนแปลง ดังนั้นทีมงานพัฒนาระบบจึงควรเลือกแนวทางที่เหมาะสมในการปรับเปลี่ยนจากระบบหนึ่งไปสู่อีกระบบหนึ่ง

จบการนำเสนอ

​

​