วิศวกรรมซอฟต์แวร์ Software Engineering
Download
Report
Transcript วิศวกรรมซอฟต์แวร์ Software Engineering
แบบจำลองระบบ
(System Model)
Outline
1
ควำมสำคัญของแบบจำลอง
2
แบบจำลองตำมแนวทำงเชิงโครงสร้ ำง
3
แบบจำลองตำมแนวทำงเชิงวัตถุ
2
ทำไมต้ องมีแบบจำลอง
เป็ นเครื่ องมือที่ใช้แทนการสื่ อสารด้วยข้อความหรื อคาพูด
เป็ นเครื่ องมือที่ช่วยให้การสื่ อสารระหว่างกลุ่มบุคคล
มีความถูกต้องตรงกัน
เกิดขึ้นระหว่างการวิเคราะห์ความต้องการ และนาไปใช้
ในการออกแบบระบบ
แบบจำลองกำรวิเครำะห์ (Analysis Model)
แบบจำลอง คือ สัญลักษณ์ที่ใช้จาลองข้อเท็จจริ งต่างๆ
ที่เกิดขึ้นในระบบ เป็ นแผนภาพที่แสดงให้เห็นในแต่ละ
มุมมองของระบบ
แบบจำลองกำรวิเครำะห์ คือ แบบจาลองที่เขียนขึ้น
จากข้อกาหนดความต้องการของระบบ สะท้อนให้เห็นถึง
หน้าที่การทางานของระบบด้านต่างๆ และจะถูกนาไปใช้
ในระยะการออกแบบต่อไป
ควำมสำคัญของแบบจำลอง
แบบจำลองเป็ นเครื่องมือสำคัญที่ช่วยให้ กำรสื่ อสำร
ระหว่ ำงบุคคลทุกฝ่ ำยมีควำมถูกต้ องตรงกันมำกขึน้
แบบจำลองประกอบด้ วยรู ปภำพสั ญลักษณ์ แสดงให้ เห็น
กำรทำงำนของระบบ หรือแสดงให้ เห็นหน้ ำทีข่ องระบบ
โครงสร้ ำง และส่ วนประกอบต่ ำง ๆ
แบบจำลองเป็ นสิ่ งทีไ่ ด้ จำกกำรวิเครำะห์ ควำมต้ องกำร
ของผู้ใช้ ท้งั ในด้ ำนระบบและซอฟต์ แวร์
ควำมสำคัญของแบบจำลอง
แบบจำลองสะท้ อนให้ เห็นหน้ ำที่กำรทำงำนของระบบในด้ ำน
ต่ ำง ๆ ได้ อย่ ำงชัดเจน
ระบบทำหน้ ำที่อะไร (What) และอย่ ำงไร (How)
มีกำรสร้ ำงแบบจำลองในระยะกำรวิเครำะห์ ควำมต้ องกำร และ
เป็ นจุดเริ่มต้ นของกำรสร้ ำงแบบจำลองระยะอืน่ ๆ
นำแบบจำลองจำกระยะกำรวิเครำะห์ ไปใช้ เพือ่ กำหนด
รำยละเอียดทำงด้ ำนเทคนิคเพิม่ เติม เพือ่ นำไปเขียนโปรแกรม
สิ่ งที่ได้ จำกระยะกำรออกแบบ คือ แบบจำลองของกำรออกแบบ
ควำมสั มพันธ์ ระหว่ ำงแบบจำลองของกำรวิเครำะห์ และกำรออกแบบ
เนื่องจำกเอกสำรข้ อกำหนดควำมต้ องกำรเป็ นเครื่องมือที่ผ้ ูใช้
หรือลูกค้ ำนำมำประเมินระบบหรือซอฟต์ แวร์ เพือ่ พิจำรณำ
ยอมรับให้ นำมำใช้ งำนได้
ข้ อกำหนดควำมต้ องกำรหรือรำยละเอียดของระบบ (System
Description) แบบจำลองของกำรวิเครำะห์ (Analysis Model)
และแบบจำลองของกำรออกแบบ (Design Model) มี
ควำมสั มพันธ์ กนั อย่ ำงต่ อเนื่องเป็ นลูกโซ่
ควำมสั มพันธ์ ระหว่ ำงแบบจำลองของกำรวิเครำะห์ และกำรออกแบบ
System
Description
Analysis
Model
Design
Model
แบบจำลองกำรวิเครำะห์ (Analysis Model)
ประเภท
แบบจาลองตามแนวทางเชิงโครงสร้าง (Structured Analysis) –
Process Model (DFD) + Data Model (ER)
แบบจาลองตามแนวทางเชิงวัตถุ (Object Oriented Analysis) –
UML (Unified Modeling Language)
แบบจำลองเชิงโครงสร้ ำง (Structured Analysis)
พิจารณาข้อมูล (Data) และกระบวนการ (Process) แยกกัน
แบ่งออกเป็ น 2 ชนิด คือ
แบบจาลองกระบวนการ (Process Model) จาลองขั้นตอน
การทางานของระบบ - DFD
แบบจาลองข้อมูล (Data Model) จาลองโครงสร้างข้อมูล
ทั้งหมดในระบบ - ERD
แบบจำลองกระบวนกำร (Process Model)
แผนภำพกระแสข้ อมูล (Data Flow Diagram : DFD)
แผนภาพที่แสดงถึงทิศทางการไหลของข้อมูลที่มีอยูใ่ น
ระบบ
จากกระบวนการทางานหนึ่งไปอีกกระบวนการหนึ่ง หรื อ
ไปยังส่ วนอื่นที่เกี่ยวข้อง เช่น แหล่งจัดเก็บข้อมูล (Data
Store) ผูท้ ี่เกี่ยวข้องที่อยูน่ อกระบบ (External Agent)
นา DFD ไปเป็ นแนวทางในการออกแบบ ฐานข้อมูล
แบบจำลองกระบวนกำร (Process Model)
ประเภทของแผนภำพกระแสข้ อมูล
- แผนภำพกระแสข้ อมูล เชิงตรรกะ (Logical DFD) –
แสดงกระบวนการของระบบในระดับแนวคิด (Conceptual)
เท่านั้น
- แผนภำพกระแสข้ อมูล เชิงกำยภำพ (Physical DFD) –
แสดงรายละเอียดภายในกระบวนการ เช่น ชื่อกระบวนการ
วิธีการทางาน แหล่งกาเนิด และปลายทาง เป็ นต้น
สั ญลักษณ์ ของ DFD
Process id
Process name
External
Agent
Flow Direction
ID Data Store
หลักกำรของ DFD
แบ่งการทางานจากกระบวนการหลักที่อยูร่ ะดับบน ลง
ไปสู่ กระบวนการย่อยที่อยูร่ ะดับล่าง
DFD ระดับบนสุ ด Context Diagram
เริ่ มสร้าง DFD ต้องเริ่ มจาก Context Diagram เพื่อแสดง
ให้เห็นภาพรวมของระบบ
Context Diagram
แผนภาพกระแสข้อมูลระดับบนสุ ด
แสดงภาพรวมการทางานของระบบที่สมั พันธ์กบั
สภาพแวดล้อมภายนอกระบบ
กาหนดขอบเขตของระบบที่จะพัฒนาได้
ตัวอย่ ำง Context Diagram
0
บริษัทคู่ค้ำ
สิ นค้าใหม่
ระบบ
ร้ ำนขำยสิ นค้ ำ
กาหนดราคาขาย
สิ นค้าที่ตอ้ งการ
ลูกค้ ำ
ใบเสร็จรับเงิน
รายงานการขาย
รายงานสต๊อกสิ นค้า
เจ้ ำของร้ ำน
Context Diagram ของระบบร้ ำนขำยสิ นค้ ำ (Seller System)
อธิบำย Context Diagram
ระบบร้านขายสิ นค้าจะต้องปฏิสมั พันธ์กบั บุคคลอืน่ หรื อ
หน่วยงานอื่นที่อยูน่ อกระบบ 3 กลุ่ม คือ
บริษทั คู่ค้ำ หมายถึง ร้านค้า หรื อบริ ษทั ที่ระบบจัดซื้อสิ นค้าเข้า
มาขาย
ลูกค้ ำ หมายถึง ผูท้ ี่มาซื้ อ หรื อมาชมสิ นค้า
เจ้ ำของร้ ำน หมายถึง ผูท้ ี่กาหนดราคาขาย และ ต้องการรายงาน
ต่างๆ จากระบบ เช่น รายงานการขายประจาวัน รายงานสต๊อก
สิ นค้าคงเหลือ
Data Flow Diagram Level 0
จากภาพรวมของระบบร้านขายสิ นค้า จะต้องมีการขยาย หรื ออธิบาย
ระบบย่อย หรื อรายละเอียดย่อยของระบบ
สร้าง DFD ระดับถัดมา คือ ระดับ 0 เพื่อแสดงให้เห็นกระบวนการ
ทางานภายในของระบบ
หากกระบวนการในระดับ 0 แต่ละกระบวนการ ยังมีการอธิบาย
รายละเอียดหรื อการทางานปลีกย่อยลงไปอีก สามารถเขียน DFD ใน
ระดับ 1 หรื อ 2 หรื อ 3 ต่อไปได้อีก
*** การแตกระบบ ระบบนั้นควรแตกได้อย่างน้อย 2 กระบวนการ
ตัวอย่ำง Data Flow Diagram Level 0
บริษัทคู่ค้ำ
รองเท้าใหม่
สิ นค้าที่ตอ้ งการ
2.0
ใบเสร็จรับเงิน
ขำยสิ นค้ ำ
1.0
ข้ อมูล
สิ นค้ ำ
ข้อมูลสิ นค้า
ลูกค้ ำ
ข้อมูลการขาย
ข้อมูลสิ นค้า
D2 รำยกำรขำย
D1 สิ นค้ ำ
ข้อมูลการขาย
3.0
ข้อมูลสิ นค้า
กาหนดราคาขาย
เจ้ ำของร้ ำน
รายงานสต๊อกสิ นค้า
รายงานการขาย
DFD Level 0 ของระบบร้ ำนขำยสิ นค้ ำ
รำยงำน
ตัวอย่ำง Data Flow Diagram Level 1
2.1
ข้อมูลสิ นค้า
ตรวจสอบ
สิ นค้ ำ
D1 สิ นค้ ำ
ราคา
2.2
ลดจานวนสิ นค้า
ลูกค้ ำ
สิ นค้าที่ตอ้ งการ
บันทักกำรขำย
ใบเสร็จรับเงิน
ข้อมูลการขาย
D2 รำยกำรขำย
2.2
ข้อมูลการขาย
DFD Level 1 ของกระบวนกำร 2.0 ขำยสิ นค้ ำ
พิมพ์ใบเสร็จ
แผนภำพแสดงควำมสั มพันธ์ ระหว่ ำงข้ อมูล
เรี ยกว่า Entity Relationship Diagram
หรื อเรี ยกย่อๆ ว่า E-R Diagram
เป็ นแผนภาพที่ใช้เป็ นเครื่ องมือสาหรับจาลองข้อมูล
ประกอบด้วย Entity (กลุ่มของข้อมูลที่เป็ นเรื่ องเดียวกัน)
และ Relationship หรื อ ความสัมพันธ์ระหว่างข้อมูลใน entity
ทุก Entity จะมี Attribute บอกลักษณะหรื อคุณสมบัติ
สั ญลักษณ์ ที่ใช้ ใน E-R Diagram
Attribute2
Attribute1
Entity2
Relation Name
Entity1
Attribute3
Attribute4
ระบบงำนขำย
Customer (Customer_ID, Name, Address)
Order (Order_ID, Product_ID)
Sale Order (Sale_ID, Order_ID, Customer_ID)
E-R Diagram ระบบงำนขำย
Order_ID
Order
Product
1
Customer_ID
Order_ID
1
Get Order
Data
Sale_ID
Sale Order
M
ลูกค้าทาการสั่งซื้ อสิ นค้า (order) และ
ใบสั่งซื้ อจะถูกเปลี่ยนเป็ นใบขายสิ นค้า (sale order)
โดยในใบขายสิ นค้า จะมีรหัสของลูกค้า และ รหัสของ
ใบสั่งซื้ อ เพื่อใช้อา้ งอิง
Get Customer
Data
Customer
Address
Name
Customer_ID
E-R Diagram ระบบงำนขำย
คำอธิบำย
Entity Sale Order จะดึงข้อมูลใบสัง่ ซื้ อ (Order Data) มาจาก
Entity Order และดึงข้อมูลลูกค้า (Customer Data) มาจาก Entity
Customer
แผนผังโครงสร้ ำง (Structure Chart)
แสดงให้เห็นการแบ่งการทางานของระบบออกเป็ นส่ วนย่อยๆ ที่เรี ยกว่า
โมดูล (Module)
เป็ นแผนผังลาดับชั้น แสดงความสัมพันธ์ระหว่างฟังก์ชนั ของโปรแกรม
แต่ละโมดูลจะมีการเรี ยกใช้ขอ้ มูลระหว่างกันตามลาดับชั้น
โมดูลระดับบน จะเรี ยกใช้โมดูลที่อยูร่ ะดับล่าง
มีโมดูลระดับบนสุ ดเพียงโมดูลเดียว เป็ นโมดูลหลัก
โมดูลระดับล่างสุ ดจะประกอบไปด้วยอัลกอริ ธึมและลอจิกของโปรแกรม
สั ญลักษณ์ ของ Structure Chart
ชื่อโมดูล
ชื่อโมดูล
โมดูล
ชื่อข้อมูล
ไลบรารี โมดูล ใช้เก็บฟังก์ชนั การทางานทั้งหมดของโปรแกรม
ชื่อข้อมูล
ข้อมูลที่ส่งไปมาระหว่างโมดูล (couple)
ชื่อข้อมูล
ชื่อข้อมูล
ข้อมูลควบคุม หรื อ Flag
ชื่อโมดูล
การเรี ยกใช้งานโมดูลอย่างมีเงื่อนไข
เรี ยกใช้โมดูลซ้ า
กำรอ่ ำนและเรียกใช้
z
A
z
x
B
x
D
y
C
A ส่ งข้ อมูล x ไปยัง B
B ส่ งข้ อมูล x ไปยัง C เพือ่
ประมวลผลจนได้ ผลลัพธ์ y
ส่ งข้ อมูล y กลับไปยัง B
B จะใช้ ข้อมูล y ประมวลผล
จนได้ ผลลัพธ์ เป็ นข้ อมูล z ที่
A ต้ องกำร
A ส่ งข้ อมูล z ไป D เพือ่
ประมวลผล
แบบจำลองตำมแนวเชิงวัตถุ
เชิงโครงสร้ ำง ทีมงานจะต้องพิจารณากระบวนการทางาน
และข้อมูลของระบบแยกส่ วนกัน
เชิงวัตถุ พิจารณาทุกๆ สิ่ งในระบบที่สนใจเป็ น วัตถุ
(Object) ซึ่งประกอบไปด้วยข้อมูล (คุณลักษณะ) และ
กระบวนการทางาน (พฤติกรรม) นัน่ คือ พิจารณาทั้งข้อมูลและ
กระบวนการไปพร้อมๆ กัน
ระบบตำมแบบจำลองตำมแนวคิดเชิงวัตถุ
ประกอบด้ วย Object จำนวนมำกทีส่ ั มพันธ์ กนั เพือ่ ทำงำน
ร่ วมกัน ให้ เกิดเป็ นกำรทำงำนของระบบ
Object ทีม่ ีคุณลักษณะและพฤติกรรมเหมือนกัน จะถูกจัดอยู่ใน
คลำส (Class) เดียวกัน
เช่ น object “นักศึกษำ” , “อำจำรย์ ” , “เจ้ ำหน้ ำที่”
จะถูกจัดอยู่ในคลำส “คน“ เนื่องจำกบุคลำกรจะมีลกั ษณะ หู ตำ
จมูก หรือแขนขำ เหมือนกัน
คลำส เป็ นเหมือนแม่ พมิ พ์ที่ใช้ สร้ ำง object ของคลำสนั้นๆ
ภำพจำลองของ class Customer
Customer
custId
custName
addCust()
deleteCust()
editCust()
displayInfo()
Class Name
Attribute
Method
(Behavior/
Operation)
UML
Unified Modeling Language
ภาษารู ปภาพเพื่อใช้สร้างแบบจาลองเชิงวัตถุ
ได้รับการยอมรับจากองค์กร OMG (Object
Management Group)
UML แบ่ งเป็ น 2 กลุ่ม
Structure Diagram
เป็ นกลุ่มแผนภาพที่แสดงให้เห็นโครงสร้างเชิงสถิตของระบบ
(Static) หมายถึง โครงสร้างที่ไม่มีการเปลี่ยนแปลงหรื อ
เคลื่อนไหวแม้จะมีเหตุการณ์ใดๆ เกิดขึ้น
Behavioral Diagram
เป็ นกลุ่มแผนภาพที่แสดงให้เห็นภาพเชิงกิจกรรมของระบบ
(Dynamic) คือ แสดงให้เห็นพฤติกรรมของระบบที่มีการ
เปลี่ยนแปลงไปเมื่อมีเหตุการณ์ใดๆ เกิดขึ้น และแสดงให้เห็นถึง
ความสามารถของระบบที่ดาเนินการในหน้าที่บางอย่างได้
UML แบ่ งเป็ น 2 กลุ่ม
Structure Diagram
Class Diagram
Object Diagram
Component Diagram
Deployment Diagram
Behavioral Diagram
Use Case Diagram
Sequence Diagram
Collaboration Diagram
State Diagram
Activity Diagram
Class Diagram
ประกอบด้วย Class และความสัมพันธ์ระหว่าง Class เช่น
Dependency, Generalization, Association เป็ นต้น
Class Diagram สามารถแสดงรายละเอียดว่ามี Method และ
Attribute อย่างไร
Class Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Class Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Object Diagram
ประกอบด้วย Object และ Relation ระหว่าง Object โดยแต่ละ
Object จะแสดง Instance ของแต่ละ class ที่มีในระบบ และ
ความสัมพันธ์ระหว่าง Class เช่น Dependency, Generalization หรื อ
Association ซึ่ งมีลกั ษณะเช่นเดียวกับ Class Diagram
Class
Object
- ประชาชน
- บุรินทร์
- แม่น้ า
- วัง
- รถยนต์
- นิสสัน
- กีฬา
- โยคะ
Object Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Component Diagram
เป็ น Diagram ซึ่งแสดงโครงสร้างทางกายภาพของ
Software โดยจะประกอบด้วยองค์ประกอบซึ่ งอยูใ่ นรู ป
ต่างๆ เช่น Binary, text และ executable ภายใน
Component Diagram ก็จะมีความสัมพันธ์แสดงอยู่
เช่นเดียวกับ Class Diagram, Object Diagram
Component Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Deployment Diagram
เป็ นสิ่ งที่สามารถทาการแสดงระบบสถาปั ตยกรรมของ
Hardware/Software ตลอดจนความสัมพันธ์ระหว่าง
hardware/software
ที่มา http://www.thaiall.com/uml/indexo.html
Use case Diagram
เป็ น Diagram ที่ทาหน้าที่ Capture requirement
1. เป็ นเทคนิคในการสร้างแบบจาลอง เพื่อใช้อธิบายหน้าที่ของระบบ
ใหม่ หรื อระบบปัจจุบนั
2. กระบวนการสร้าง Use case เป็ นแบบวนซ้ า (Iteration)
3. องค์ประกอบมี Use case, Actor, Use case Relation และ System
4. ความต้องการของระบบจะได้จาก ลูกค้า ผูใ้ ช้ + ผูพ้ ฒั นาระบบ
Use case Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Use case Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Use case Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Sequence Diagram
แสดงลาดับการทางานของระบบ โดยมี Object และ
เวลา เป็ นตัวกาหนดลาดับของงาน และเน้นไปที่
instant ของ Object
1. Simple : ย้ายการควบคุมระหว่างวัตถุ
2. Synchronous : ติดต่อแบบรอคาตอบ ก่อนทางานอื่นต่อไป
3. Asynchronous : ติดต่อแบบไม่รอคาตอบที่กลับมา
Sequence Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Collaboration Diagram
แสดงลาดับการทางานของ วัตถุ ผูเ้ กี่ยวข้อง และกิจกรรม โดย
ลาดับการทางานไม่ข้ ึนกับเวลา เพราะการแสดงความสัมพันธ์
ของ Object กับเวลาเป็ นหน้าที่ของ Sequence Diagram
Collaboration Diagram
เส้ นลูกศรครึ่งเดียว คือ ติดต่อแบบไม่รอคาตอบที่กลับมา
ที่มา http://www.thaiall.com/uml/indexo.html
State Diagram
ประกอบด้วย State ต่างๆ ของ Object และเหตุการณ์ต่างๆ ที่ทา
ให้สถานะของ Object เปลี่ยนและการกระทาที่เกิดขึ้นเมื่อ
สถานะของระบบเปลี่ยนไป สามารถบอกสถานะของ Object ได้
โดยจะให้ความสนใจว่า ณ เวลาใดๆ Object นั้นมี status เป็ น
แบบใด
ที่มา http://www.thaiall.com/uml/indexo.html
Activities Diagram
แสดงลาดับ กิจกรรมของการทางาน(Work Flow) สามารถแสดง
ทางเลือกที่เกิดขึ้นได้ Activity Diagram จะแสดงขั้นตอนการทางาน
ในการปฏิบตั ิการ โดยประกอบไปด้วยสถานะต่างๆ ที่เกิดขึ้น
ระหว่างการทางาน และผลจากการทางานในขั้นตอนต่าง ๆ
วงกลมสี ดา คือ จุดเริ่ มต้น เรี ยก Initial State
วงกลมสี ดา มีวงล้อมอีกชั้น คือ จุดสิ้ นสุ ด เรี ยก Final State
Activities Diagram
ที่มา http://www.thaiall.com/uml/indexo.html
Start
Stop
สรุป
ทีมงานจาเป็ นต้องสร้างแบบจาลองชนิดต่าง ๆ เพื่อช่วยให้การ
สื่ อสารมีความถูกต้อง ตรงกัน
แบบจาลอง (Model) จะประกอบด้วยรู ปภาพสัญลักษณ์ เพื่อใช้
อธิบายแทนสิ่ งต่าง ๆ ในระบบ ทาให้เข้าใจง่ายขึ้น
เมื่อเข้าสู่ระยะการออกแบบ ทีมงานจะต้องนาแบบจาลองที่ได้จาก
ระยะการวิเคราะห์มาใช้ เพื่อกาหนดรายละเอียดต่าง ๆ ด้านเทคนิค
เพิ่มเติม ให้สามารถสื่ อสารกับโปรแกรมเมอร์ต่อไปได้ง่ายขึ้น
แบบจาลองตามแนวทางการวิเคราะห์และออกแบบระบบมี 2
แนวทาง ได้แก่ แนวทางเชิงโครงสร้าง (Structured System
Approach) และแนวทางเชิงวัตถุ (Object-Oriented Approach)
สรุป
แนวทางเชิงโครงสร้างจะพิจารณาขั้นตอนการทางานของระบบแยก
ส่ วนจากข้อมูลของระบบ
แบบจาลองเชิงโครงสร้าง มี 2 ประเภท
• แบบจาลองกระบวนการทางานของระบบ (Process Model)
• แบบจาลองข้อมูล (Data Model)
แบบจาลองกระบวนการทางานของระบบ จะแสดงให้เห็นขั้นตอน
การทางานทั้งหมดของระบบ
• แผนภาพที่ใช้ คือ แผนภาพกระแสข้อมูล (Data Flow Diagram :
DFD)
สรุป
แบบจาลองข้อมูล ใช้แสดงข้อมูลและความสัมพันธ์ระหว่าง
ข้อมูลทั้งหมด
• แผนภาพที่ใช้คือ แผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล
(Entity Relationship Diagram : ERD)
ทีมงานสามารถสร้างแบบจาลองใดก่อนก็ได้ และเมื่อเข้าสู่ ระยะ
การออกแบบแล้ว ทีมงานสามารถนา DFD และ ERD จากการ
วิเคราะห์ไปกาหนดรายละเอียดทางเทคนิคเพิ่มเติมได้
DFD ที่สร้างในระยะการออกแบบ เรี ยกว่า DFD ระดับกายภาพ
(Physical DFD)
สรุป
แนวทางเชิงวัตถุ จะพิจารณาสิ่ งต่าง ๆ ในระบบเป็ นวัตถุ (Object)
แต่ละอ็อบเจ็กต์จะประกอบด้วยข้อมูลและขั้นตอนการทางานรวมอยู่
ด้วยกัน
แนวทางเชิงวัตถุ ช่วยให้ทีมงานวิเคราะห์ความต้องการได้รวดเร็ วขึ้น
แบบจาลองเชิงวัตถุ (Object Model) ที่สะท้อนให้เห็นมุมมองด้าน
ต่าง ๆ ของอ็อบเจ็กต์ในระบบได้
ภาษาที่ใช้สร้างแบบจาลองเชิงวัตถุที่นิยมใช้คือ UML (Unified
Modeling Language)
สรุป
UML แบ่งออกเป็ น 2 กลุ่ม
• Structural Diagram ใช้แสดงโครงสร้างของระบบ เป็ นโครงสร้างที่
ไม่มีการเปลี่ยนแปลง
– Class Diagram, Object Diagram, Component Diagram และ
Deployment Diagram
• Behavioral Diagram ใช้แสดงพฤติกรรมของระบบที่มีการ
เปลี่ยนแปลงตามเหตุการณ์
– Use Case Diagram, Sequence Diagram, Collaboration Diagram,
Statechart Diagram และ Activity Diagram