sondmk header
การวิเคราะห์และะออกแบบระบบเชิงออปเจ็คต์

คะแนน

Post by Goborijung at : 2019-03-09 09:26:38
ในห้องเรียน : 35 | สอบกลางภาค : 25 | สอบปลายภาค : 40 

Table of Contents

Post by Goborijung at : 2019-03-09 11:23:50
Chapter 1 : พื้นฐานการวิเคราะห์และออกแบบระบบเชิงวัตถุ 
- OOAD คืออะไร
- พื้นฐานสำหรับ Object
- OOA และ OOD
- ขั้นตอนของ OOAD
- Unified Modeling Language (UML)

Chapter 2 : แนวคิดเชิงออปเจ็คต์ 
- Domain (โดเมน)
- Object (ออปเจ็คต์)
- Identity (ไอเดนทิตี้ )
- Encapsulation (เอ็นเคปซูเลชั่น)
- Inheritance (อินเฮอริแต้น)
- Polymorphism (พอลี้มอฟิสึม)

Chapter 3 : การวิเคราะห์และออกแบบเชิงออปเจ็คต์ 
- SDLC Phases ช่วงเวลา วงจรการพัฒนาระบบ
- Scope & Problem ขอบเขตและปัญหา

Chapter 4 : Requirements ความต้องการ 
- Functional Requirements ความต้องการ ฟังก์ชั่นการทำงาน
- Non-Functional Requirements ความต้องการที่ไม่มีฟังก์ชั่นการทำงาน

Chapter 5 : UML และ แผนภาพกิจกรรม  
- แผนภาพกรณีการใช้งานคืออะไร 
- แผนภาพ UML
- แผนภาพกิจกรรม

Chapter 6 : แผนภาพกรณีการใช้  
- ผู้กระทำ
- กรณีการใช้
- การรวมเข้า/ส่วนขยายที่สัมพันธ์กัน
- ขอบเขต

Chapter 7 : แผนภาพคลาส  
- Association (Name, Property, Method, Visibility)
- Generalization (Inheritance)
- Aggregation (Shared, Composite)

Chapter 8 : Sequence Diagram แผนภาพลำดับ  
Chapter 9 : Deployment Diagram (Structural Diagram)  
Chapter 10 : State Diagram (State, Transition)  

CHAPTER 1

Post by Goborijung at : 2019-03-09 13:38:35
Introduction 
software คืออะไร
- Program Computer โปรแกรมคอมพิวเตอร์
- Intangible จับต้องไม่ได
- Easy to reproduce ง่ายในการทำซ้ำ
- Easy to modity ง่ายในการแก้ไข

ชนิด/ประเภท ของ Software
- Custom พัฒนาขึ้นมาเฉพาะ เพื่อให้ตรงกับงานนั้นๆ
- Generic (Package) ซอฟต์แวร์ส าเร็จรูป เช่นซอฟต์แวร์จัดการระบบบัญชี เป็นต้น
- Embedded พัฒนาเพื่อใช้กับ Hardware และจะ แก้ไขได้ยากกว่า

Software (มุมมองการตอบสนอง)
- Real time software ตอบสนองทันที
- Data processing software (Batch) เหมาะส าหรับงานที่ประมวลผลข้อมูลมากๆ , ท างานลักษณะ Batch

คุณภาพของ Software
- Usability ผู้ใช้งานสามารถใช้งานง่าย เรียนรู้การใช้งานได้เร็ว
- Efficiency มีประสิทธิภาพ และใช้กินยากรน้อย
- Reliability มีความน่าเชื่อถือสูง
- Maintainability สามารถบ ารุงรักษาง่าย
- Reuseability สามารถน าบางส่วนไปใช้กับโปรเจคอื่นได

Software Engineering วิศวกรรมซอฟต์แวร์ 
* กระบวนการทางวิศวกรรมสำาหรับพัฒนาระบบซอฟต์แวร์ เพื่อให้ซอฟต์แวร์มีคุณสมบัติ ดังนี้
- ซอฟต์แวร์มีคุณภาพ
- เสร็จตามระยะเวลาที่กำหนด
- เสร็จภายใต้งบประมาณที่กำหนด
* เป้าหมายวิศวกรรมซอฟต์แวร์ คือ พัฒนาซอฟต์แวร์ที่ ถูก เร็ว ดี 

Stakeholders (ผู้ที่มีส่วนได้เสีย) ใน วิศวกรรมซอฟต์แวร์
- Users ผู้ใช้งานซอฟต์แวร์
- Customers ลูกค้า, ผู้ว่าจ้าง, ผู้จ่ายเงินค่าพัฒนา
- Software Developers, Development Managers นักพัฒนาซอฟต์แวร

Software Development การพัฒนาซอฟต์แวร์
System Development Life Cycle : SDLC
1. Project Planning - วางแผน
2. System Analysis - วิเคราะห์ระบบ(ปัญหา)
3. System Design - ออกแบบระบบ(วิธีการแก้ไข)
4. Programming - เขียนโปรแกรม
5. Testing - ทดสอบระบบ
6. Conversion - การเปลียนไปใช้ระบบใหม่
7. Production and Maintenance - การสร้างและบำรุงรักษา

1. Planning (Feasibility Analysis) การวางแผน วิเคราะห์ความเป็นไปได้
* การวางแผนการท างาน
- การศึกษาความเป็นไปได
- วางแผนการพัฒนาระบบ
- หาทีมงาน

* สิ่งที่ได้จากการวางแผนการท างาน
- Project Plan
- ทีมงาน

2. System Analysis การวิเคราะห์ระบบ
* การวิเคราะห์ระบบ
• เข้าใจระบบงานเดิม
• หาผู้ที่เกี่ยวข้องกับระบบใหม่ (Stakeholder)
• เก็บข้อมูล วิเคราะห์หาปัญหาและสาเหตุของปัญหาของระบบงานเดิม
• เก็บข้อมูล วิเคราะห์หาความต้องการของระบบงานใหม่
• วิเคราะห์หา Process
• วิเคราะห์หาความเกี่ยวข้องระหว่าง Stakeholder และ Process
• วิเคราะห์หาความต้องการส าหรับระบบงานใหม



3. System Design การออกแบบระบบ
* การออกแบบระบบงานใหม
• ออกแบบการแก้ปัญหาที่ได้จากขั นตอนการวิเคราะห์ ว่าจะแก้ปัญหาอย่างไร
• ออกแบบสถาปัตยกรรมระบบ (Application Architecture Design)
• ออกแบบข้อมูล Input, Output ต่างๆ
• ออกแบบฐานข้อมูล

4. Programming การเขียนโปรแกรม
* การพัฒนาระบบงานใหม
• พัฒนาระบบงานใหม่
• พัฒนาระบบฐานข้อมูล
• ทดสอบส่วนต่างๆในระหว่างการพัฒนา เช่น unit testing

* สิ่งที่ได้จากการพัฒนาระบบงานใหม
• ซอฟต์แวร์ระบบงานใหม่
• ระบบฐานข้อมูลส าหรับระบบงานใหม

5. Testing ทดสอบระบบ
* การทดสอบระบบงานใหม่
• ทดสอบระบบงานย่อย (Test Case)
• ทดสอบระบบงานรวม (Integraction Test)

* สิ่งที่ได้จากการทดสอบระบบงานใหม่
• เอกสารการทดสอบระบบ
• ระบบงานที่มีการปรับปรุงหลังการทดสอบ

6. Conversion การเปลี่ยนไปใช้ระบบใหม่
* การติดตั งระบบงานใหม่
• ติดตั งซอฟต์แวร์และฮาร์ดแวร์ของระบบงานใหม่
• ทดสอบระบบงานรวม
• ฝึกอบรมการใช้งานระบบงานใหม่
• จัดการการเปลี่ยนแปลงต่างๆในระบบ

* สิ่งที่ได้จากการติดตั งระบบงานใหม่
• เอกสารการฝึกอบรม
• ระบบงานที่มีคุณภาพ ตรงตามความต้องการ
• เอกสารอื่นๆ (User Manual, Software Specification เป็นต้น)



7. Production & Maintenance การสร้างและบำรุงรักษา
* การบ ารุงรักษาระบบ
• การแก้ไขปัญหาต่างๆ
• จัดการการเปลี่ยนแปลงต่างๆในระบบ

* สิ่งที่ได้จากการบ ารุงรักษาระบบงานใหม่
• ระบบงานที่แก้ไขแล้ว
• เอกสารการจัดการการเปลี่ยนแปลง

การพัฒนาซอฟต์แวร์โดยใช้แนวคิดเชิงวัตถ
• การใช้แนวคิดเชิงวัตถุเป็นแนวคิดหลัก ในการพัฒนาซอฟต์แวร์
• การใช้แนวคิดเชิงวัตถุเป็นแนวคิดหลัก ในวงจรการพัฒนาระบบ (SDLC)

วัตถุ (Object)
• สิ่งต่างๆที่เราก าลังสนใจ
• สิ่งที่จับต้องได้ เช่น ผู้ใช้งานระบบ, เซิร์ฟเวอร์, ใบเสร็จ เป็นต้น
• สิ่งที่จับต้องไม่ได้ เช่น ข้อมูลการสั่งซื อ, ความเป็นเจ้าของ เป็นต้น



องค์ประกอบของ Object
• Attritube/Property คือคุณสมบัติ, คุณลักษณะ หรือ สถานะของวัตถุ เช่น ชื่อ, สถานะ, สี, ขนาด เป็นต้น
• Method/Function พฤติกรรม หรือหน้าที่ ที่วัตถุสามารถ ท าได้ เช่น คลิกได้, เดินได้, บันทึกได้ เป็นต้น 
• Identity/Unique มีความเป็นเอกลักษณ์ ถึงจะเป็นวัตถุ ประเภทเดียวกัน แต่จะมีสิ่งที่ไม่เหมือนกัน

Attribute/Property คุณสมบัติหรือคุณลักษณะ
• เราสามารถบรรยายคุณสมบัติของ Object ต่างๆเท่าที่คุณสมบัติ ดังกล่าวเป็นคุณสมบัติที่เราสนใจ หรืออยู่ใน Domain เช่น สีและจ านวนล้อ  สีผิวและเพศ 
• ในทาง OO จะเรียกสิ่งที่ใช้ในการบรรยายคุณลักษณะต่างๆของ Object ว่า Attribute
• Attribute ก็คือคุณสมบัติของแต่ละ Object



Method/Function วิธีการ ฟังก์ชั่น
• การจะท าให้Object สามารถโต้ตอบหรือมีปฏิสัมพันธ์ระหว่างกัน ได้ ต้องอาศัยองค์ประกอบที่ส าคัญอย่างหนึ่งของ Object นั่นคือ Method
• Method คือ การกระท าที่ Object สามารถกระท าได้ หรือถูกร้อง ขอให้กระท าได้ ซึ่งก็คือ พฤติกรรมของ Object นั่นเอง

ตัวอย่างเช่น นาย ก เปิดเครื่องคอมพิวเตอร์ยี่ห้อ A
• สามารถวิเคราะห์หา Object 2 Object คือ นาย ก และคอมพิวเตอร์ยี่ห้อ A
• สามารถหา Class ได้ 2 Class คือ คน และคอมพิวเตอร์

เมื่อวิเคราะห์จะพบว่า Interaction ที่เกิดขึ้นคือ นาย ก เปิดเครื่องคอมพิวเตอร์ยี่ห้อ A
หมายความว่า จะต้องมี Object ตัวใดตัวหนึ่งใน 2 ตัวนี้ สามารถท ากิจกรรม เปิด เกิดขึ้น

ค าถามคือ Object ใดที่ทำให้กิจกรรมนี เกิดขึ น

เช่น เมื่อต้องการให้คอมพิวเตอร์A เปิด ต้องมีใครสักคนหรืออะไรสักอย่าง มาสั่งให้เครื่องคอมพิวเตอร์เปิด (คอมพิวเตอร์ยี่ห้อ A เปิดด้วยตัวเองไม่ได้) หมายความว่า เครื่องคอมพิวเตอร์ A ต้องมีความสามารถในการเปิดหรือมีMethod เปิด อยู่ในตัวเอง

• โดย นาย ก เป็นผู้มากระตุ้น (Trigger) ให้เครื่องคอมพิวเตอร์ยี่ห้อ A เปิดขึ้น
• หรืออาจจะกล่าวได้ว่า Method เปิดของเครื่องคอมพิวเตอร์ยี่ห้อ A ถูก เรียกใช้งานนั่นเอง

Unique/Identity
• ถ้าสังเกตการอ้างถึง Object ต่างๆที่เราสนใจ เราจะใช้ ประโยคที่เฉพาะเจาะจงของ Object นั นๆ เช่น รถยนต์ ทะเบียน กข 123
• ทุกๆ Object ที่อยู่ใน Class เดียวกัน จะต้องมีเอกลักษณ์ ประจ าตัวที่สามารถจ าแนกความแตกต่างระหว่าง Object ได้ นั่นคือ Object จะต้องมีเอกลักษณ์ที่ไม่ซ ากับ Object อื่น เรียกคุณสมบัตินี ว่า Object Identity หรือ Unique Identity

* สาเหตุที่เราต้องระบุให้จ าเพาะเจาะจง เพราะว่า Object แต่ละตัว จะไม่สามารถซ าหรือเป็นตัวเดียวกับ Object อื่นได้ 



Object Oriented Software Engineering
• Object Oriented Analysis (OOA) เป็นขั้นตอนการวิเคราะห์เพื่อให้ทราบว่า Problem Domain คืออะไร
• Object Oriented Design (OOD) เป็นขั้นตอนการออกแบบหรือจ าลองวิธีการ เพื่อแก้ปัญหา Problem Domain
• Object Oriented Programming (OOP) เป็นขั้นตอนการสร้างหนทาง แก้ปัญหาในรายละเอียดให้เกิดขึ้นและใช้งานจริง
• การพัฒนาระบบคอมพิวเตอร์นั้น รวมถึงการวิเคราะห์ ออกแบบ พัฒนาโปรแกรม ทดสอบ และน าไปใช้ เรียกพัฒนาระบบคอมพิวเตอร์ด้วยหลักการ Object Orienteation ว่า“Object Oriented Software Engineering (OOSE)”

สรุปองค์ประกอบของ OOSE ได้ดังนี้
OOSE = OOA + OOD + OOP
OOSE = OOAD + OOP

Unified Modeling Language : UML
• เครื่องมือส าหรับการวิเคราะห์และออกแบบเชิงวัตถุ
• แบบจ าลองเชิงสัญลักษณ์หรือแผนภาพส าหรับระบบงาน
• แบบจ าลองเพื่ออธิบายแนวคิดเชิงวัตถุ

เป็นเครื่องมือที่ได้รับความนิยมเพิ่มขึ้นตลอดเวลา เริ่มประยุกต์ใช้กับระบบงานมากขึ้น เพราะเป็นเครื่องมือที่มีความหลากหลายในการแสดงแบบซอฟต์แวร์ เป็นโมเดลมาตรฐานที่ใช้ หลักการออกแบบ OOP (Object Oriented Programming) รูปแบบของภาษามีNotation เป็นสัญลักษณ์ส าหรับสื่อความหมาย มีกฎระเบียบที่มีความหมายต่อการเขียนโปรแกรม (Coding) 

• สิ่งที่จ าเป็นอย่างหนึ่งในกระบวนการวิเคราะห์และออกแบบ คือ การสร้าง แบบจ าลองของ Object, Class และองค์ประกอบอื่นๆของระบบ ซึ่ง
ถ่ายทอดได้ดีที่สุด คือ การแสดงในรูปแบบของสัญลักษณ์ เช่น รูปภาพ แผนภาพ หนึ่งในเครื่องมือที่นิยมมากที่สุดคือ UML
• UML ไม่ได้เป็นเพียงเครื่องมือเท่านั้น แต่จัดได้ว่าเป็นภาษา เนื่องจาก UML มีหน่วยของภาษาที่ชัดเจน คือมีทั้งค าศัพท์และไวยากรณ์ที่ชัดเจน
• แต่ UML แตกต่างจากภาษาทั่วไป คือรูปแบบของภาษานั้น ประกอบขึ้นจาก รูปภาพและแผนภาพ ไม่ใช่อักขระ จึงได้มีการจัดให้UML เป็นประเภทหนึ่ง
ของภาษารูปภาพ



Thing
หมายถึง สิ่งต่างๆที่ใช้จ าลอง สิ่งที่ได้มาจากกระบวนการ Abstraction เป็นสิ่งที่ใช้อธิบายกลุ่มของ object หรือ method ที่มีคุณสมบัติ การท างาน และ
ความสัมพันธ์ที่เหมือนกัน สัญลักษณ์ที่ใช้วาด Class แบ่งเป็น 3 ส่วนคือ Name, Attribute และ Operation

• Structural Things เปรียบเสมือนค านามของภาษา UML ได้แก่ Class, Interface, Use Case, Component, Node
• Behavioral Things ท าหน้าที่เสมือนหนึ่งค ากริยาของภาษา UML ประกอบด้วย Message และ State
• Grouping Things ท าหน้าที่ในการรวมเอากลุ่มของ Structural Things และ กลุ่ม Behavioral Things เข้าด้วยกัน ใน UML เรียกว่า Package
• Annotational Things มีหน้าที่อธิบาย UML Model ที่ถูกสร้างขึ้น

Relationship
หมายถึง ความสัมพันธ์ที่ท าหน้าที่ในการเชื่อมโยง Things ต่างๆเข้าไว้ด้วยกัน

• Dependency ใช้เพื่ออธิบายของสองสิ่งมีความสัมพันธ์แบบขึ้นต่อกันหรือมีอิทธิพลต่อกัน
• Association ใช้เพื่ออธิบายความสัมพันธ์ระหว่างสิ่งของสองสิ่งในระนาบความสัมพันธ์เดียวกัน เช่น ความสัมพันธ์ระหว่างห้องเรียนกับอาคาร
• Generalization ใช้เพื่ออธิบายความสัมพันธ์ระหว่างสิ่งของสองสิ่งในรูปแบบของการจ าแนก การแบ่งประเภท
• Realization ใช้เพื่ออธิบายความสัมพันธ์ระหว่างสิ่งของสองสิ่ง สิ่งหนึ่งท าหน้าที่ในการด าเนินการใช้Method ของอีกสิ่งหนึ่ง

Diagram
คือ สิ่งที่ท าหน้าที่รวบรวมเอา Things และ Relationships ที่เกี่ยวข้องสอดคล้องกัน ไว้ที่เดียวกัน

• Class Diagram เป็น Diagram ที่ใช้แสดงโครงสร้างของ Class ต่างๆที่เราสนใจ
• Object Diagram เป็น Diagram ที่ใช้เพื่อแสดงโครงสร้างของ Object ต่างๆที่เราสนใจ
• Use Case Diagram เป็น Diagram ที่ใช้เพื่อแสดง Use Case ที่เป็นกลุ่มงานของเหตุการณ์ แสดง Actor ที่เป็นผู้ที่ไม่ได้อยู่ในระบบ แต่มีส่วนเกี่ยวข้องกับระบบ และแสดงความสัมพันธ์ระหว่าง Use Case และ Actor เหล่านั้น
• Sequence Diagram หรือ Communication Diagram เป็น Diagram ที่ใช้เป็นที่ รวมของ Class และหรือ Object และชุดของ Message ซึ่งก่อให้เกิดการด าเนินการอย่างใดอย่างหนึ่งของระบบ
• Statechart Diagram เป็น Diagram ที่แสดงถึงสถานะ เหตุการณ์ที่ก่อให้เกิดการ เปลี่ยนแปลงสถานะที่สามารถเป็นไปได้ของ Class หนึ่งๆ
• Component Diagram เป็น Diagram ที่แสดงให้เห็นถึงองค์ประกอบของระบบและ ความสัมพันธ์ที่มีอยู่ระหว่าง Component เหล่านั้น จัดเป็น Diagram ที่แสดงให้เห็นภาพของ การ Implement ระบบ
• Deployment Diagram เป็น Diagram ที่แสดงให้เห็นถึงองค์ประกอบที่ท าหน้าที่ ประมวลผลและความสัมพันธ์ระหว่างองค์ประกอบเหล่านั้น

ใน UML 2.0 ยังได้เพิ่ม Timing Diagram, Interaction Diagram, Composite Diagram และเปลี่ยนชื่อ Collaboration Diagram เป็น Communication Diagram 


CHAPTER 2

Post by Goborijung at : 2019-03-10 14:56:27
Object Oriented Concepts
องค์ประกอบของ Object
•Identity/Unique มีความเป็นเอกลักษณ์ ถึงจะเป็นวัตถุประเภท เดียวกัน แต่จะมีสิ่งที่ไม่เหมือนกัน
• Attritube/Property/Characteristic คือคุณสมบัติ, คุณลักษณะหรือสถานะของวัตถุ เช่น ชื่อ, สถานะ, สี, ขนาด เป็นต้น
• Method/Function/Behavior พฤติกรรม หรือหน้าที่ ที่วัตถุสามารถท าได้ เช่น คลิกได้, เดินได้, บันทึกได้ เป็นต้น

Object Orientation
• แนวคิดที่ใช้แนวคิดเชิงวัตถุเป็นแนวคิดหลัก
• ส าหรับอธิบายหรือจัดการความซับซ้อนต่างๆ เช่น การพัฒนาซอฟต์แวร์ เป็นต้น
•ในปัจจุบัน รอบตัวเรานั้นจะพบกับวัตถุ (Object) ต่างๆมากมายไม่ว่าจะเป็นวัตถุที่จับต้องได้และวัตถุที่จับต้องไม่ได้
• Object หนึ่งๆ ในช่วงเวลาหนึ่งๆ อาจจะอยู่นิ่ง หรืออาจะไม่ได้อยู่นิ่ง แต่จะด าเนินการหรือถูกด าเนินการอย่างใดอย่างหนึ่ง การด าเนินการนั้นท าให้เกิดกิจกรรม ความเคลื่อนไหวหรือการกระท าเช่น คนรับประทานอาหาร เกิดจาก คน ด าเนินการ กิน ต่ออาหาร
•ในชีวิตประจ าวันของเรานั้น ล้วนแต่เกิดจากการมีความสัมพันธ์(Relationship) และปฏิสัมพันธ์ (Interaction) ระหว่าง Object 2 ตัวขึ้นไป
• กิจกรรมคนรับประทานอาหาร เกิดจาก Interaction รับประทานระหว่างคนกับอาหารและเกิดจาก Relationship เป็นเจ้าของ ระหว่างคนกับอาหาร
• กิจกรรมสุนัขเล่นกับแมว เกิดจาก Interaction เล่นระหว่างสุนัขกับแมวและเกิด Relationship เป็นเพื่อน ระหว่างสุนัขกับแมว



จากตัวอย่างข้างต้น เราสามารถแยกแยะความแตกต่างระหว่าง Relationship กับ Interaction ได้ดังนี้
1. Relationship คือ ความเกี่ยวข้องและความสัมพันธ์ระหว่างObject 2 ตัวขึ้นไป โดยทั่วไปจะมองไม่เห็น อาศัยการตีความ เช่น ความเป็นแม่-ลูก ความเป็นเจ้าของ
2. Interaction คือ ปฏิสัมพันธ์หรือการกระท าใดๆ ที่เกิดขึ้น ระหว่าง Object 2 ตัวขึ้นไป สามารถมองเห็นหรือสังเกตเห็นได้ เช่น การสร้าง การเล่น ซึ่งจะท าให้เกิดกิจกรรมต่างๆขึ้น

การใช้ OO จัดการความซับซ้อน
• Thing & Characteristics or properties ชื่อ, นามสกุล, ที่อยู่, วันเกิด, ขนาด เป็นต้น
• Function or methods เดิน, วิ่ง, กิน, เรียน, บอกชื่อ-นามสกุล, คลิก เป็นต้น
• Thing & its parts หัว, ล าตัว, แขน, ขา เป็นต้น
• Type of things นักศึกษา, อาจารย์, ปุ่ม, รายงาน เป็นต้น




ข้อดีของ Object Orientation
•Reusability น ากลับมาใช้ใหม่
•Flexibility ความยืดหยุ่น
•Maintainability ง่ายในการบ ารุงรักษา

คุณลักษณะของ Object
• Identity
• Encapsulation
• Inheritance
• Polymorphism

Identity
คุณลักษณะ
•วัตถุมีความเป็นเอกลักษณ์
• มีความแตกต่างกัน ถึงแม้จะเป็นวัตถุชนิดเดียวกัน
• มีความแตกต่างกัน ถึงแม้จะเป็นวัตถุที่เกิดจากคลาสเดียวกัน

ถ้าสังเกตการอ้างถึง Object ต่างๆที่เราสนใจ เราจะใช้ประโยคที่เฉพาะเจาะจงของ Object นั นๆ เช่น รถยนต์ทะเบียน กข 123
ทุกๆ Object ที่อยู่ใน Class เดียวกัน จะต้องมีเอกลักษณ์ประจ้าตัวที่สามารถจ้าแนกความแตกต่างระหว่าง Object ได้ นั่นคือ
Object จะต้องมีเอกลักษณ์ที่ไม่ซ ้ากับ Object อื่น เรียกคุณสมบัตินี ว่า Object Identity หรือ Unique Identity
สาเหตุที่เราต้องระบุให้จ้าเพาะเจาะจง เพราะว่า Object แต่ละตัวจะไม่สามารถซ ้าหรือเป็นตัวเดียวกับ Object อื่นได้ 





Inheritance
คุณลักษณะ
• การสืบทอดคุณสมบัติ (Property) และพฤติกรรม (Method)
• เพื่อการน้ากลับมาใช้ใหม่ (Reuse)




Polymorphism
คุณลักษณะ
• การมีได้หลายรูปแบบ
• นิยมใช้กับ method
• เพื่อการน้ากลับมาใช้ใหม่ (Reuse)

Class
• ต้นแบบของ Objects ที่ใช้เป็นโครงสร้างให้แก่ Object
• เป็นนามธรรม ไม่สามารถใช้งานได้โดยตรง หากต้องการใช้ งานต้องสร้าง Object จากคลาสนันๆ
• สมาชิกที่เกิดจาก Class คือ Object (instance)

ความสัมพันธ์ระหว่าง Class และ Object
• Object ไม่สามารถเกิดขึ นเองได้
• Object เกิดขึ นจาก Class
• 1 Class สามารถสร้าง Object ได้ไม่จ้ากัด
• Object ที่สร้างจาก Class ใด Object นั นจะมี property และ method เหมือนกับ Class นั น
• Object ที่เกิดจาก Class จะมีความเป็นเอกลักษณ์ (Identity)




CHAPTER 3

Post by Goborijung at : 2019-03-10 15:43:39
Object Oriented Analysis and Design
กระบวนการพัฒนาระบบของ Unified Process
Unified Process (UP) เป็นกระบวนการพัฒนาระบบเชิง วัตถุแบบหนึ่งที่มีการประยุกต์แนวคิดแบบวนซ ้า โดยความยาวของ แต่ละรอบการพัฒนาระบบ ให้อยู่ในระหว่าง 2 ถึง 6 สัปดาห์ การใช้การคืบทีละน้อยที่มีการตอบกลับอย่างรวดเร็ว เพื่อให้เกิดการปรับเปลี่ยนเป็น หัวใจส้าคัญของการวิเคราะห์และออกแบบระบบแบบวนซ ้า

1. Business Modeling
2. Requirement
3. Analysis and Design
4. Implementation
5. Test
6. Deployment

1. Business Modeling
เป็นกระบวนการที่เกี่ยวข้องกับเรื่อง
• การก้าหนดวิสัยทัศน์ (Vision)
• ขอบเขตของระบบ
• ความรับผิดชอบ/ผู้รับผิดชอบ
• การปรับปรุงกระบวนการทางธุรกิจ

2. Requirements
การวิเคราะห์ความต้องการของระบบจากผู้มีส่วนเกี่ยวข้อง
• การวิเคราะห์Use Case
- Functional Requirement
- Non-Functional Requirement

3. Analysis & Design
* วิเคราะห์และออกแบบทุกแง่มุมของระบบ
• รองรับการเปลี่ยนแปลงของระบบได้เมื่อความต้องการ ของระบบด้านหน้าที่หลักเปลี่ยน (Functional Requirement)

* สิ่งที่ได้จากการวิเคราะห์และออกแบบ
• Design Model (สถาปัตยกรรมของระบบ ฐานข้อมูล และระบบเครือข่าย) ซึ่งเป็นพิมพ์เขียวส้าหรับการพัฒนา โปรแกรมต่อไป

4. Implementation
การพัฒนาโปรแกรมให้ระบบท้างานได้
• ระบบท้างานได้ตามผลการวิเคราะห์และออกแบบ
• การทดสอบโปรแกรมบน Unit Test

5. Test
ทดสอบการท้างานร่วมกัน
• ทดสอบการท้างานร่วมกันในแต่ละส่วนที่พร้อมติดตั ง
• การตรวจสอบเพื่อยืนยันว่าทั งระบบนั นสามารถท้างาน ตอบสนองต่อความต้องการของระบบ (Requirement) ได้

6. Deployment
การติดตั งระบบส้าหรับการใช้งาน
• การติดตั งระบบให้พร้อมส้าหรับการใช้งานของผู้ใช้ (Product Release)
• การส่งมอบ
• ติดตั งซอฟต์แวร์
• ให้ความช่วยเหลือผู้ใช้งานเริ่มต้น

เฟสของ Unified Process
แนวทางของการพัฒนาระบบ UP นั นมีกระบวนการที่ สามารถแบ่ได้เป็น 4 ช่วง คือ Business Modeling

1. Inception Phase เพื่อสร้างความเข้าใจในขอบเขตของระบบ
2. Elaboration Phase เพื่อขยายขอบเขตความเข้าใจ
3. Construction Phase ช่วงการพัฒนาระบบจนกระทั่งเสร็จสิ น
4. Transition Phaseช่วงด้าเนินการทดสอบระบบ

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

2. Elaboration Phase
มีวัตถุประสงค์เพื่อขยายขอบเขตความเข้าใจความต้องการของระบบ ของผู้เกี่ยวข้องในทีมผู้พัฒนาระบบ รวมทั งมีการก้าหนดสถาปัตยกรรมของ
ระบบ
• การก้าหนดสถาปัตยกรรมของระบบ
• การปรับปรุงวิสัยทัศน์
• การพัฒนาระบบส่วนที่เป็นสถาปัตยกรรมหลัก
• การจัดการกับความเสี่ยงสูง
• การระบุความต้องการหลักและขอบเขตของระบบ
• การประมาณที่ใกล้เคียงความจริงมากขึ น
• มีกระบวนการในการวิเคาะห์ความต้องการที่ใกล้เสร็จสิ น กระบวนการของ การวิเคราะห์และออกแบบซอฟต์แวร์ (Analysis & Design) จะด้าเนินงานไป
ได้เกินครึ่ง

3. Construction Phase
เป็นช่วงที่เกิดการพัฒนาระบบจนกระทั่งเสร็จสิ น ซึ่งต่อเนื่องมาจากการ พัฒนาระบบที่เกิดขึ นในเฟสก่อนหน้า และเมื่อระบบถูกพัฒนาจนเสร็จก็จะมี
การเตรียมความพร้อมเพื่อใช้งานระบบ
• การทดสอบในระดับ Unit Test
• การทดสอบในระดับ Integration Test
ระบบที่เสร็จสิ นในเฟสนี จะเรียกว่าเป็นระบบที่พร้อมรับการทดสอบ จากผู้ใช้ (Beta release) การพัฒนาระบบเกือบเสร็จสิ นสมบูรณ์

4. Transition Phase
เป็นช่วงที่ด้าเนินการทดสอบระบบที่ต่อเนื่องจากเฟสก่อนหน้า
• การทดสอบ Beta จนกระทั่งติดตั งระบบเสร็จพร้อมใช้งาน
• ได้รับข้อมูลป้อนกลับจากผู้ใช้งาน
• ตรวจสอบข้อผิดพลาดที่อาจยังหลงเหลืออยู่




การพัฒนาซอฟต์แวร์โดยใช้แนวคิดเชิงวัตถุ
•การใช้แนวคิดเชิงวัตถุเป็นแนวคิดหลัก ในการพัฒนาซอฟต์แวร์
•การใช้แนวคิดเชิงวัตถุเป็นแนวคิดหลัก ในวงจรการพัฒนาระบบ (SDLC)

วัตถุ (Object)
•สิ่งต่างๆที่เราก้าลังสนใจ
•สิ่งที่จับต้องได้ เช่น ผู้ใช้งานระบบ, เซิร์ฟเวอร์, ใบเสร็จ เป็นต้น
•สิ่งที่จับต้องไม่ได้ เช่น ข้อมูลการสั่งซื อ, ความเป็นเจ้าของ เป็นต้น

องค์ประกอบของ Object
•Attribute/Property คือคุณสมบัติ, คุณลักษณะ หรือสถานะของวัตถุ เช่น ชื่อ, สถานะ, สี, ขนาด เป็นต้น
•Method/Function พฤติกรรม หรือหน้าที่ ที่วัตถุสามารถท้าได้ เช่น คลิกได้, เดินได้, บันทึกได้ เป็นต้น
•Identity/Unique มีความเป็นเอกลักษณ์ ถึงจะเป็นวัตถุประเภทเดียวกัน แต่จะมีสิ่งที่ไม่เหมือนกัน

การวิเคราะห์และออกแบบเชิงวัตถุ (OOAD)
การใช้แนวคิดเชิงวัตถุเป็นแนวคิดหลักในการวิเคราะห์ และออกแบบเชิงวัตถุ แบ่งออกเป็น 2 ส่วน
•การวิเคราะห์เชิงวัตถุ (OOA) คือ การวิเคราะห์ระบบโดยใช้แนวคิดเชิงวัตถุ
•การออกแบบเชิงวัตถุ(OOD) คือ การออกแบบระบบโดยใช้แนวคิดเชิงวัตถุ

การวิเคราะห์ระบบเชิงวัตถุ (OOA)
การใช้แนวคิดเชิงวัตถุเป็นแนวคิดหลักในการวิเคราะห์ดังนี
• ขั นตอนการท้างานระบบงานเก่า (Activity Diagram)
• ขอบเขตระบบงานใหม่
• ผู้ที่เกี่ยวข้องกับระบบงานใหม่
• ปัญหาและความต้องการระบบงานใหม่ (Requirements)
• Task Analysis
- Use Case ของระบบงานใหม่
- Activity Diagram
• Conceptual Class ของระบบงานใหม่
• Structure Analysis
- Conceptual Class ของระบบงานใหม่
- Specification Class ของระบบงานใหม่
• Behavioral Analysis
- Sequence diagram ของ use case ต่างๆ
- State diagram ของอ็อปเจกต์ที่ส้าคัญ

ขั นตอนการวิเคราะห์ระบบเชิงวัตถุ
1. เข้าใจระบบงานเดิม
2. วิเคราะห์ Domain
• ปัญหาของระบบงาน (Problem)
• ขอบเขตของระบบงานใหม่ (Scope)
3. เก็บข้อมูลปัญหาและความต้องการ (Requirement)
4. วิเคราะห์ความต้องการระบบงานใหม่
• Functional และ Non-functional requirement
5. วิเคราะห์ Task Analysis
• Use Case Diagram
• Activity Diagram
6. วิเคราะห์ Structure Analysis
• Conceptual Case Diagram
• Specification Class Diagram
7. วิเคราะห์ Behavioral Analysis
• Sequence Diagram
• Collaboration Diagram
• State Diagram

Problem and Scope
ปัญหาของระบบงาน (Problem)
•ความยากล้าบากที่ผู้ใช้งานเผชิญในการระบบ หรือซอฟต์แวร์
•โอกาสที่สามารถท้าให้เกิดผลประโยชน์บางอย่าง
•การแก้ปัญหาคือ วิธีการแก้ปัญหาที่เกิดขึ นซึ่งน้ามาสู่การ พัฒนาซอฟต์แวร์

ขอบเขตของระบบงานใหม่ (Scope)
•รายการของทุกๆสิ่งที่จ้าเป็นต่อการท้างานของระบบ
•ก้าหนดผู้ที่เกี่ยวข้องกับระบบงานทั งหมด
•ตัดสิ่งที่ไม่จ้าเป็นออก
•หากขอบเขตกว้างเกินไป ให้แยกขอบเขตให้แคบลง
•การก้าหนดขอบเขตถูกต้องเกิดจากการก้าหนดปัญหาที่ ถูกต้อง

Requirement
• ค้าอธิบายส้าหรับอะไรต่างๆที่ระบบต้องท้า
• ค้าอธิบายส้าหรับข้อจ้ากัดต่างๆในการพัฒนาระบบ
• ค้าอธิบายว่าระบบท้าอะไร โดยยังไม่ระบุว่าท้าอย่างไร
• ต้องเพียงพอส้าหรับการแก้ปัญหาของผู้ใช้งาน
• ต้องได้รับการยอมรับหรือเห็นด้วยจากผู้ใช้งาน (stakeholder)
• Requirement ที่ดีควรครบถ้วนและกระชับ

ประเภทของ Requirement
• Functional requirement
- ความต้องการที่เป็นความต้องการหลักและจ้าเป็นของระบบงาน
• Non-functional requirement
- ความต้องการที่ไม่ใช่ความต้องการหลัก แต่จ้าเป็นต้องมีในระบบงาน

การออกแบบระบบเชิงวัตถุ (OOD)
การใช้แนวคิดเชิงวัตถุเป็นแนวคิดหลักในการออกแบบระบบ ดังนี
• สถาปัตยกรรมของระบบงานใหม่ (Architecture Design)
• Input & Output Design
• User Interface Design
• Other Design

ขั นตอนการออกแบบระบบเชิงวัตถุ
1. ออกแบบสถาปัตกรรมของระบบ (ต้องได้สถาปัตยกรรมเบื องต้นตั งแต่ขั นตอนการวิเคราะห์)
• Deployment Diagram
2. ออกแบบ Input & Output
3. ออกแบบ User Interface
4. ออกแบบส่วนอื่นๆที่เกี่ยวข้องกับระบบงาน

ตัวอย่าง ระบบบริการ Taxi For Life  
1. บทน้า
ในปัจจุบันการใช้บริการแท็กซี่โดยทั่วไป นอกจากจะใช้วิธีการเรียกด้วยตนเองตามจุด ต่างๆแล้ว บางครั งอาจอยู่ในสถานที่ซึ่งมีความยากล้าบากในการเดินทางมาเรียกด้วยตนเอง ก็สามารถโทรศัพท์แจ้งศูนย์บริการแท็กซี่ให้ส่งรถแท็กซี่มารับตามสถานที่ต่างๆ ซึ่ง ศูนย์บริการรถแท็กซี่จะแจ้งรถแท็กซี่ที่เป็นสมาชิกผ่านทางวิทยุสื่อสาร แท็กซี่ที่อยู่ในบริเวณ ใกล้เคียงจะตอบรับการไปรับผู้ใช้บริการตามสถานที่ๆได้แจ้งไว้ โดยที่ผู้ใช้บริการไม่ทราบ
รายละเอียดของรถแท็กซี่ หรือแม้กระทั่งว่าคนขับรถแท็กซี่ที่มาให้บริการนั นเป็นใคร มี ประวัติอย่างไร มีความปลอดภัยหรือไม่ เพื่อลดปัญหาดังที่กล่าวมาข้างต้น จึงได้ออกแบบ ระบบบริการแท็กซี่ For Life ขึ น โดยการท้างานจะสามารถใช้ได้กับแอพพลิเคชันบนสมาร์ท โฟนหรือแท็บเล็ต ซึ่งผู้ใช้งานสามารถท้าการตรวจสอบรายละเอียดต่างๆ ของรถแท็กซี่ เพื่อ ความมั่นใจและปลอดภัยในการใช้บริการ

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

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




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




CHAPTER 4

Post by Goborijung at : 2019-03-11 09:59:44
Requirements
System Requirements
ความต้องการของระบบ คือความสามารถในการท างานและเงื่อนไขของการท างานของระบบ หรือเงื่อนไขที่ระบบต้องท าให้ส าเร็จ

ความต้องการของระบบมักจะเกิดการเปลี่ยนแปลงไปอย่างน้อย 25%ในระหว่างการพัฒนาระบบ ดังนั้นการได้มาซึ่งความต้องการที่ครบถ้วนก่อนจะเริ่มลงมือออกแบบและพัฒนาโปรแกรมนั้น จึงเป็นไปได้ยาก แต่ด้วยลักษณะของการพัฒนาระบบเชิงวัตถุที่เป็นการวนซ้้าและมีการเปลี่ยนแปลงได้(Evolutionary) ท้าให้นักพัฒนาพร้อมที่จะรองรับความเปลี่ยนแปลงของความต้องการของระบบที่อาจเกิดขึ้นระหว่างการพัฒนาระบบได้ด

ประเภทของ Requirements
• Functional Requirement ความต้องการระบบด้านหน้าที่ หรือความต้องการ ระบบด้านการท างาน
• Non-functional Requirement ความต้องการด้านอื่นๆ

Functional Requirements (FRs)
Data
• Inputs ข้อมูลที่จ าเป็นต่างๆของระบบ
• Outputs ข้อมูลต่างๆของระบบ
• Storage ข้อมูลที่ระบบเก็บไว้ ส าหรับให้ระบบอื่นๆน าไปใช้งาน

Computation
• ส่วนค านวณหรือส่วนประมวลผลต่างๆในระบบ

Requirements for sequencing and parallelism
• ระยะเวลาที่ใช้ส าหรับการท างานของส่วน Data และ Transformations

Exception handling
• ข้อยกเว้นต่างๆ



Functional Requirement จะถูกอธิบายไว้ในเอกสาร Vision ดังนี้
1. สถานการณ์ปัจจุบันของระบบ และเป้าหมายของระบบใหม่ อธิบายภาพรวมของ ปัญหาที่เกิดขึ้นในระบบที่ใช้งานอยู่ในปัจจุบัน และเป้าหมายของการพัฒนาระบบใหม่ เพื่อเน้นความต้องการของระบบ และคุณภาพของระบบใหม่ โดยใช้Use Case
2. สรุปฟังก์ชันของระบบ เป็นการแจกแจงรายการฟังก์ชันของระบบ ที่ไม่ใช่เพียงการเขียนรายชื่อ Use Case ทั้งหมดที่มี แต่จะต้องเป็นรายการที่แสดงถึงพฤติกรรมที่ระบบท้างานได้เพื่อตอบสนองต่อผู้เกี่ยวข้องของระบบ (Stakeholders) โดยที่ผู้อ่านรายงานเหล่านี้จะสามารถเข้าใจได้ว่าจะใช้บริการของระบบอย่างไรได้บ้าง

ตัวอย่างการเขียน VISION
ระบบขายของธุรกิจค้าปลีกแบบ POS VISION
บทน า
ระบบขายนี้เป็นระบบขายแบบ POS ที่มีความต้านทานต่อความผิดพลาด เพื่อรองรับร้านสาขาที่อาจมีความแตกต่างกันในกฎทางธุรกิจบางข้อ (Business Rule) โครงสร้างสถาปัตยกรรมระบบ และส่วนต่อประสานผู้ใช้งานใช้ในการด้าเนินการขายได้ รวมทั้งระบบนี้สามารถเชื่อมต่อกับระบบอื่นของธุรกิจได้อีกด้วย

ภาพรวมของธุรกิจ
ปัญหาที่พบในปัจจุบันในการขายของธุรกิจ คือการที่ระบบขายที่ใช้งานอยู่ยังไม่ยืดหยุ่น ไม่สามารถรองรับงานขายที่เกิดขึ้นในทุกสาขาได้ เนื่องจากร้านสาขาบางร้านมีกระบวนการทางธุรกิจที่แตกต่างกันไปเพียงเล็กน้อยนอกจากนี้แล้วระบบขายที่ใช้งานอยู่ยังไม่สามารถส่งข้อมูลขายไปบันทึกบัญชีและตัดสต๊อกสินค้าได้ทัน ท้าให้ธุรกิจมีข้อมูลไม่ทันต่อการตัดสินใจและวางแผน ซึ่งสามารถสรุปได้ดังนี้
- ระบบท้างานได้ช้าลงอย่างสังเกตได้ชัดเมื่อมีลูกค้าจ้านวนมากรอช้าระเงินในร้าน
- เมื่อเกิดข้อผิดพลาดขึ้น ข้อมูลรายการขายที่ก้าลังบันทึกมีโอกาสหายไป
- ข้อมูลในระบบบัญชี และระบบสินค้าคงคลังยังไม่ถูกต้องตรงกับการขายที่เกิดขึ้น
- ไม่สามารถปรับเปลี่ยนวิธีการท้างานในกระบวนการขายได้ หากแต่ละสาขามีBusiness Rule ที่แตกต่างกัน
- ไม่สามารถน้าเทคโนโลยีอื่น เช่น PDA มาใช้งานร่วมกับระบบขายได้ 

Stakeholder Descriptions
ผู้ที่เกี่ยวข้องกับระบบขายมีดังต่อไปนี้
- แคชเชียร์ ท้าหน้าที่ใช้ระบบขายเพื่อบันทึกรายการขายที่เกิดขึ้นทันที รับช้าระตามรายการขายที่เกิดขึ้นจัดการรับคืนสินค้า และเปลี่ยนสินค้า เปิดช่องรับช้าระเงินและปิดช่องรับช้าระเงิน
- ผู้จัดการร้านสาขา มีหน้าที่สรุปยอดขายประจ้าวันของทั้งร้านสาขา สรุปจ้านวนสินค้าที่ขายได้ และยอดสินค้าคงเหลือเพื่อเตรียมสั่งซื้อเพิ่ม
- ผู้ดูแลระบบ มีหน้าที่จัดการข้อมูลของผู้ใช้งาน จัดการสิทธิการใช้งานของผู้ใช้งานในระบบ

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

Non-functional Requirements (NFRs)
ความต้องการระบบที่ช่วยเอื้อประโยชน์ให้ผู้ใช้งานระบบได้ง่ายขึ้นดีขึ้น หรือมีความปลอดภัยมากขึ้น ได้แก่
• Usability ระบบมีส่วนข่วยให้ผู้ใช้ ใช้งานระบบได้
• Reliability การสร้างความเชื่อมั่นให้กับผู้ใช้ ถึงแม้ล่มก็จะสามารถกู้กลับคืนมาได้
• Performance ประสิทธิภาพของระบบ (Response Time, Throughput,Accuracy, Availability, Resource Usage)
• Supportability/Enhancement สามารถเปลี่ยนแปลงระบบ(Adaptability) เพื่อให้รองรับกับความต้องการที่เพิ่มขึ้น/เปลี่ยนไปได้
• Interface การก าหนดให้ระบบจะต้องเชื่อมต่อกับระบบอื่น
• Operation ข้อก าหนดในการใช้งานระบบ
• Service ระบบตอบสนอง/ให้บริการได้ตรงกับความต้องการ

Non-functional Requirement ความต้องการอื่นๆของระบบ จะไม่ได้ถูกอธิบายไว้ใน Use Case Diagram แต่จะถูกอธิบายไว้ในเอกสารSupplementary Specification ดังนี้
1. ความต้องการระบบด้านอื่น (Non-functional Requirement) ได้แก่Usability, Reliability, Performance และ Supportability
2. ตัวอย่างรายงานที่ได้จากระบบ (เอกสารแนบ)
3. ข้อก าหนดด้านฮาร์ดแวร์และซอฟต์แวร์ ได้แก่ อุปกรณ์ที่จะน้ามาใช้ในระบบข้อก้าหนดด้านระบบเครือข่าย ระบบปฏิบัติการ
4. ข้อก าหนดด้านการพัฒนาระบบ (Development Constraint) ได้แก่เครื่องมือที่ใช้ในการพัฒนาระบบ กระบวนการพัฒนาระบบ (Methodology) Component ที่จะน้ามาใช้ ระบบอื่นภายนอกที่ต้องมีการเชื่อมต่อ
5. ข้อก าหนดด้านการออกแบบและการติดตั้งอื่น
6. เอกสารประกอบของระบบที่ต้องมี (เอกสารแนบ)
7. ประเด็นด้านลิขสิทธิ์ สิทธิการใช้งานและประเด็นอื่นด้านกฎหมาย
8. ข้อก าหนดในการท างานเฉพาะ (Application-specific Domain Rule)เช่น การค้านวณภาษีขายในรายการขายจะเป็นข้อก้าหนดการท้างานในภาพรวม มักจะถูกบันทึกไว้ในข้อก้าหนดทางธุรกิจ (Business Rule) แต่การให้ส่วนลดในรายการสินค้าแต่ละรายการในรายการขายที่เกิดขึ้น ควรถูกบันทึกไว้ในส่วนนี้ของ SupplementarySpecification)
9. ข้อมูลที่เกี่ยวข้องในขอบเขตของระบบ (Information in Domain of Interest) เป็นการอธิบายแหล่งอ้างอิงส้าหรับข้อมูลที่อยู่ในขอบเขตของระบบที่จะพัฒนาเช่น ผู้เชี่ยวชาญที่อ้างอิงได้สูตรการค้านวณ กฎหมาย ซึ่งข้อมูลเหล่านี้จะเป็นประโยชน์ให้ทีมผู้พัฒนาระบบสามารถค้นคว้าเพิ่มเติมเพื่อท้าความเข้าใจได้ 

ตัวอย่างการเขียน Supplementary Specification
ระบบขายของธุรกิจค้าปลีกแบบ POS Supplementary Specification
Usability
เนื่องจากลูกค้าต้องการตรวจสอบข้อมูลในรายการขายจากจอภาพ ดังนั้น จึงมีข้อก้าหนดต่อไปนี้ส้าหรับการแสดงข้อมูลทางจอภาพ
- ข้อความจะต้องอ่านได้ในระยะ 1 เมตร
- ใช้สีขาวด้าเป็นหลัก
เนื่องจากแคชเชียร์จะมองลูกค้าและสินค้าเป็นส่วนใหญ่ ไม่ได้มองที่จอภาพ ดังนั้น หากมีข้อผิดพลาดในการท้างานที่จะต้องเตือนแคชเชียร์ ควรมีการเตือนด้วยเสียงประกอบ

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

Performance
ความเร็วของการบันทึกรายการขายเป็นสิ่งส้าคัญในการท้างานของระบบขายของธุรกิจค้าปลีกแบบ POSและการรอนุมัติการรับช้าระเงินจากบริษัทบัตรเครดิตอาจเป็นจุดคอขวดได้ ดังนั้น เป้าหมายหลักหนึ่งของระบบก็คือ การอนุมัติ การช้าระเงินจะต้องเสร็จภายใน 1 นาที อย่างน้อย 90% ของรายการขายทั้งหมดที่ใช้บริการเพื่อให้สามารถรองรับปริมาณลูกค้าในช่วงเวลาที่มีการขายเป็นจ้านวนมาก ระบบสามารถเปิดรับการช้าระเงินพร้อมกันได้อย่างน้อย 50 Station

Supportability
ร้านสาขาของธุรกิจค้าปลีกแห่งนี้ อาจมีความหลากหลายในด้านระบบเครือข่ายส้าหรับระบบขายแบบ POSน้าไปติดตั้งเพื่อใช้งาน เช่น บางร้านสาขาใช้Thin-client บางร้านสาขาอาจใช้Thick-client บางร้านสาขาอาจใช้สถาปัตยกรรมแบบหลายชั้น (N-tier) ดังนั้น การออกแบบสถาปัตยกรรมระบบของระบบขายจะต้องสามารถดัดแปลงเพื่อให้ติดตั้งในระบบเครือข่ายได้หลายประเภท

Interface
ระบบขายแบบ POS นี้สามารถเชื่อมต่อกับฮาร์ดแวร์ได้หลายแบบ ได้แก่ จอภาพแบบสัมผัส (touch-screenmonitor) เครื่องอ่านบาร์โค้ด เครื่องพิมพ์ใบเสร็จ เครื่องอ่านบัตรเดบิต/เครดิตระบบขายแบบ POS นี้ สามารถเชื่อมต่อกับระบบอื่นภายนอก ได้แก่ ระบบค้านวณภาษีส้าเร็จรูป ระบบบัญชีและระบบบริหารสินค้าคงคลังที่ใช้งานอยู

Application-specific Domain Rule
Rule 1 : การให้ส่วนลด ส่วนลดที่ธุรกิจค้าปลีกมีอยู่ ได้แก่ พนักงาน 20% ลูกค้าชั้นหนึ่ง 10% ลูกค้าผู้สูงอายุ15% เป็นต้น ส่วนลดเหล่านี้สามารถเปลี่ยนแปลงได้ และสามารถเพิ่มการให้ส่วนลดแก่ลูกค้ากลุ่มใหม่ได้ ซึ่งแต่ละสาขาอาจมีการให้ส่วนลดที่ไม่เท่ากัน

Rule 2 : การให้ส่วนลดการขาย ส่วนลดต่อรายการขายเกิดขึ้นตามรายการส่งเสริมการขายที่ธุรกิจก้าหนดขึ้นและมีหลายรูปแบบ ได้แก่ ส่วนลด 10%จากยอดซื้อ 1,000 บาท ส่วนลด 40%ส้าหรับรายการขนม อบหลังเวลา18.00 น. เป็นต้น ส่วนลดเหล่านี้อาจมีช่วงระยะเวลาก้าหนด เช่น ตั้งแต่ 1 เมษายน – 31 พฤษภาคม เป็นต้น

Rule 3 : การให้ส่วนลดเฉพาะสินค้า ซึ่งเป็นส่วนหนึ่งของรายการส่งเสริมการขายที่ธุรกิจก้าหนดขึ้น เช่น การแถม 1 ชิ้นในการซื้อ 2 ชิ้นของน้้ายาปรับผ้านุ่มยี่ห้อหนึ่ง เป็นต้น ส่วนลดเหล่านี้มักมีช่วงระยะเวลาก้าหนดเช่นเดียวกับ Rule 2

Information in Domain of Interest
ราคาสินค้า ก่อนการให้ส่วนลดตาม Application-Specific Domain Rules (ตามแผนการตลาด) สินค้าจะมี ราคาขาย และอาจมีราคาที่ลดได้ ในการขายปกติจะเป็นการใช้ราคาขายและใช้ในการบันทึกบัญชี และภาษี และเมื่อเกิดการขายขึ้นจริงสามารถใช้ราคาที่ลดได้ในการต่อรองกับลูกค้าการจัดการการรับช้าระเงินโดยใช้บัตรเดบิตหรือเครดิต เมื่อลูกค้าใช้บัตรเดบิตหรือบัตรเครดิตในการช้าระเงินค่าสินค้า ระบบจะส่งข้อมูลการใช้บัตรไปยังระบบให้บริการอนุมัติการช้าระเงินของบริษัทบัตรเดบิตหรือบัตรเครดิตนั้น เมื่อได้รับการอนุมัติ ระบบจะบันทึกตั้งบริษัทบัตรฯเป็นลูกหนี้ของธุรกิจ ทุกสิ้นวันบริษัทบัตรเครดิตจะโอนเงินเป็นจ้านวนรวมทั้งหมดที่มีลูกค้าใช้บัตรช้าระค่าสินค้าในวันนั้นไปยังบัญชีของธุรกิจ ซึ่งอาจมีการหักค่าบริการไว้แล้วภาษีขาย การค้านวณภาษีขาย สินค้าบางประเภทอาจไม่มีภาษีขาย หรือลูกค้าบางรายไม่ต้องช้าระภาษีขายหรือมีการลดภาษีขาย กฎเกณฑ์เกี่ยวกับภาษีขายอาจมีการเปลี่ยนแปลงได้ 

ตัวอย่างการเขียน Supplementary Specification
ระบบงานบริการแท็กซี่ Supplementary Specification 
Usability
เนื่องจากลูกค้าต้องการทราบสถานะในการให้บริการ หลังจากที่เรียกใช้บริการจาก Application Taxi For Life ระบบจึงจ้าเป็นต้อง
- สามารถประมาณระยะเวลาในการมารับผู้โดยสาร
- แสดงเป็นข้อความแจ้งเตือนทาง Application
ผู้ใช้บริการสามารถอ่านคู่มือประกอบการใช้งานได้ในเมนู ค าแนะน าในการใช้บริการ

Reliability
กรณีระบบล่มไม่สามารถใช้งานได้ ให้ติดต่อโดยการส่งข้อความยืนยันเพื่อแจ้งให้ผู้โดยสารทราบ

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

Supportability
ผู้ใช้บริการอาจมีระบบปฏิบัติการที่แตกต่างกัน ดังนั้นระบบจะต้องสามารถรองรับการท้างานของผู้ใช้บริการทั้งระบบ iOS, Android และ Windows เพื่อการใช้งานที่ครอบคลุมการให้บริการ

Interface
ระบบ Taxi For Life สามารถเชื่อมต่อกับฮาร์ดแวร์-เครื่องพิมพ์ใบเสร็จได้ เพื่อจัดพิมพ์ใบเสร็จให้กับผู้ใช้บริการ

Application-specific Domain Rule
Rule 1 : การให้ส่วนลด กรณีเข้าใช้ใช้บริการครั้งแรก จะได้รับรหัสส่วนสดส้าหรับการใช้งาน 50 บาท
Rule 2 : การให้ส่วนลดอื่นๆ กรณีเป็นลูกค้าทั่วไปไม่มีการค้านวณส่วนลดการใช้บริการ ถ้าเป็นลูกค้า ประเภทพรีเมียม จะได้รับส่วนลดการใช้บริการ 10%

เทคนิคการเก็บ Requirements
•การดูงาน (Observation)
- ดูงานจริงของผู้ใช้งาน
- ดูเอกสารในระบบงานเดิม
•การสัมภาษณ์ (Interviewing)
•การประชุม (Brainstorming)
•การท าโปรโตไทป์ (Prototyping)
•การใช้ยูสเคสไดอะแกรม (Use Case Diagram)
- สร้างแผนภาพ use case เบื้องต้นเพื่อยืนยัน requirement

ตัวอย่าง Software Requirements System
สายการบิน
สมมติว่าเจ้าของสายการบินขนาดเล็ก ต้องการให้ลูกค้าสามารถดูข้อมูลเที่ยวบินและจองตั๋วผ่านเว็บไซต์ได้หลังจากที่สัมภาษณ์ผู้จัดการและตัวแทนจ าหน่ายตั๋วแล้วนักออกแบบซอฟต์แวร์ได้ท าการร่างเอกสาร SRS ไว้ ซึ่งส่วนหนึ่งมีรายละเอียดดังนี

• ผู้ใช้ที่ไม่ได้ลงทะเบียน สามารถดูเที่ยวบินได้ แต่ไม่สามารถจองได้
• ลูกค้าใหม่ที่ต้องการจอง ต้องกรอกชื่อ ที่อยู่ บริษัท เบอร์โทรศัพท์ อีเมล์ ลงในแบบฟอร์ม
• ลูกค้าแบ่งออกเป็น 2 ประเภท คือ รูปแบบบริษัท และบุคคลธรรมดา
• ลูกค้าสามารถค้นเที่ยวบินได้จากปลายทางและเวลาบิน
• ลูกค้าสามารถจองเที่ยวบินที่แสดงถึงหมายเลขเที่ยวบินและที่นั่งได้
• ระบบสามารถส่งการยืนยันการจองไปยังลูกค้า ผ่านทางอีเมล์ เมื่อเกิดการจอง
• ตั๋วสามารถถูกยกเลิกได้ช้าสุด 1 สัปดาห์ก่อนการบิน ซึ่งจะคืนเงินให้ 80%
• ตัวแทนจ าหน่ายตั๋วสามารถดูและแก้ไขข้อมูลเที่ยวบินได

วิเคราะห์ว่าเป็น Requirement หรือไม่ ถ้าเป็น จัดอยู่ในประเภทใด FRs หรือ NFRs
•วิธีการน าเข้าข้อมูลเกี่ยวกับเที่ยวบิน เช่น ข้อมูลผู้โดยสาร,การจองตั๋ว เป็นต้น
• ข้อมูลต่างๆที่แสดงบนตั๋วเครื่องบิน และรายงานต่างๆ
•วิธีการค านวณอัตราค่าโดยสาร
• ข้อมูลต่างๆที่ต้องเก็บในฐานข้อมูลส าหรับตัวแทนจ าหน่ายตั๋วเครื่องบิน และการเข้าถึงอื่นๆ ของข้อมูล
•ระบบควรได้รับการออกแบบเพื่อที่จะสามารถขยายหรือ
รองรับการจัดการแผนการบินส าหรับนักบินที่บินบ่อยๆ
•ระบบต้องพร้อมใช้งานอยู่ตลอดเวลา โดยอนุญาตให้ระบบหยุดท างานได้เพียง 2 นาทีต่อสัปดาห์
•การจัดเรียงเที่ยวบินต้องใช้“merge sort algorithm”
•ระบบสามารถรองรับการจองของลูกค้าพร้อมกันได้สูงสุด500 ราย

CHAPTER 5

Post by Goborijung at : 2019-03-11 10:21:08
UML & Activity Diagram

Model
• แบบจ าลองที่แสดงถึงรายละเอียดของสิ่งที่เราก าลังสนใจ
• ในที่นี้หมายถึงแบบจ าลองของระบบที่เราก าลังวิเคราะห์และออกแบบ
• เข้าใจปัญหาของระบบได้ง่าย
• ให้ความหมายตรงกัน
• ใช้เป็นต้นแบบในการสร้างระบบงานจริงได

Why use a Model? 
• ง่าย และเร็วในการสร้างแบบจ าลอง
• สามารถเห็นภาพรวมและรายละเอียดของระบบงานได้อย่างชัดเจน
• เพื่อเป็นสื่อกลางระหว่างนักพัฒนาระบบและผู้ที่เกี่ยวของ(Stakeholder)

Model & OOAD 
• แบบจ าลองที่สามารถรองรับแนวคิดเชิงวัตถุได้
• แบบจ าลองที่สามารถแสดงรายละเอียดการวิเคราะห์และ ออกแบบเชิงวัตถุได้
• ปัจจุบันแบบจ าลองที่ได้รับความนิยมคือ UML

What is UML? 
• Unified Modeling Language
• เป็นสัญลักษณ์กราฟิกมาตรฐานสากล (Standard GraphicNotation)
• ก าหนดโดย Object Management Group (OMG)
• ใช้ในการสร้างแบบจ าลองระบบงาน
• ประกอบด้วยแผนภาพ (Diagram) ต่างๆที่สนับสนุนแนวคิดเชิงวัตถุที่สามารถอธิบายรายละเอียดของระบบได้



ประเภทของ UML Diagrams
•แผนภาพเชิงโครงสร้าง (Structure Diagrams)
- แสดงโครงสร้างของระบบ
- ยังไม่แสดงขั้นตอนหรือพฤติกรรม
•แผนภาพเชิงพฤติกรรม (Behavior Diagrams)
- แสดงถึงขั้นตอนการท างานของระบบ

Structural Diagrams
• แผนภาพเชิงโครงสร้าง (Structural Diagrams)
- Class diagram *
- Deployment diagram *
- Object diagram
- Component diagram
- Package diagram
- Etc...

Behavior Diagrams
* แผนภาพเชิงพฤติกรรม (Behavior Diagrams)
• Activity diagram *
• Use case diagram *
•Sequence diagram *
• Collaboration diagram
•State diagram *
•Timing diagram
•Etc…

Activity Diagram (แผนภาพกิจกรรม)เป็นแผนภาพที่ใช้แสดงแบบจำลองลำดับกิจกรรมการทำงานของระบบ (Activity Workflow)
• เป็นแผนภาพที่ใช้แสดง Control flow ของระบบ
• เป็นแผนภาพที่ใช้แสดงแบบจำลองลำดับกิจกรรม (Activity)ของ Use Case
• มีลักษณะคล้าย System Flow Chart 
•สำหรับคน (Human) ใช้แสดง Workflow
•สำหรับซอฟต์แวร์ (Software component) ใช้แสดง Control Flow ของซอร์ฟแวร








ตัวอย่าง ระบบลงทะเบียนออนไลน์มออ.
1. นศ.เข้าสู่ระบบ
2. นศ.ท าการเลือกรายวิชา
3. นศ.บันทึกผลการลงทะเบียน
4. อาจารย์พิจารณารายวิชาที่ลงทะเบียนเกรดเฉลี่ยสะสมมากกว่าหรือเท่ากับ 2.00 อนุมัติได้ เกรดเฉลี่ยสะสมน้อยกว่า 2.00 ต้องเขียนค าร้อง
5. คณบดีอนุมัติการลงทะเบียน
6. นศ.รับทราบผลการลงทะเบียน
7. นศ.พิมพ์ใบช าระเงิน และเข้าดูตารางเรียน

แบบฝึกหัด Activity Diagram(แผนภาพกิจกรรม) (เลขคี่) 
แบ่งกลุ่ม 3 คนเพื่อออกแบบ Activity Diagram สำหรับระบบยืมคืนหนังสือห้องสมุดที่มีขั้นตอนดังนี้
1. ผู้ใช้บริการขอยืมหนังสือกับเจ้าหน้าที่
2. เจ้าหน้าที่ตรวจสอบสิทธิสมาชิกในการยืมของผู้ใช้บริการ และแจ้งแก่ผู้ใช้บริการ
3. สมาชิกแจ้งขอยืมกับเจ้าหน้าที่
4. เจ้าหน้าที่ตรวจสอบว่ามีหนังสือที่ร้องขอหรือไม่
5. ระบบตรวจเช็ครายการหนังสือที่ต้องการยืม
6. เจ้าหน้าที่ท ารายการยืม
7. เจ้าหน้าที่ก าหนดวันคืน
8. เจ้าหน้าที่บันทึกข้อมูลการยืม
9. เจ้าหน้าที่แจ้งข้อมูลการยืมแก่สมาชิก

แบบฝึกหัด Activity Diagram (เลขคู่) 
แบ่งกลุ่ม 3 คนเพื่อออกแบบ Activity Diagram ส าหรับระบบการสั่งซื้อสินค้าเครื่องส าอางที่มีขั้นตอนดังนี้
1. ลูกค้าสั่งซื้อสินค้า
2. เซลล์ได้รับใบสั่งซื้อ
3. เซลล์ร้องขอการน าสินค้าออกจากสต๊อกสินค้าจากแผนกสต๊อก
4. แผนกสต๊อกท าการแพ็คสินค้าเพื่อเตรียมส่ง
5. เซลล์ส่งสินค้าและใบเรียกเก็บเงินให้ลูกค้าพร้อมๆกัน
6. ลูกค้ารับสินค้าและช าระค่าสินค้า

แนวข้อสอบกลางภาค

Post by Goborijung at : 2019-03-17 17:42:44
แนวข้อสอบ OO กลางภาค 30 คะแนน
1. Concep ของ OO (Property , Behavior ,  Indentity)
2. คุณลักษณะของ OO 4 อย่าง Indentity , Inheritance , Encapsulation , Polymorphism
3. ลักษณะของ Software คุณภาพเป็นอย่างไร
4. กระบวนการของ OO (Unifield Process) Business Model , Requirement ,  A&D , Implement , Test , Deployment
5. การหาคลาสและออบเจ็ค
6. ให้เขียน Activity Diagram ระบบห้องสมุดอัติโนมัติ


Framework

Library


เครื่องมือพัฒนาเว็บ



การออกแบบและพัฒนาเว็บไซต์


Download SourceCode



copyAllright © 2016 soundmk.com