บทที่การว 6 ิเคราะห และออกแบบเช...

บทที่ 6 การวิเคราะหและออกแบบเชิงวัตถุ (Object-Oriented Analysis and Design)

วัตถุประสงค

1. เขาใจแนวคิดเกี่ยวกับการวิเคราะหและออกแบบเชิงวัตถุ

2. เขาใจลักษณะและความสําคัญของคลาส ออบเจ็กต คุณลักษณะตางๆ และความสัมพันธระหวางคลาสกับ

ออบเจ็กต

3. สามารถเขียนการจําลองเชิงวัตถุดวย UML ไดทั้ง Use Cass Diagram, Class Diagram, Sequence

Diagram, State Transition Diagram และ Activity Diagram

4. สามารถเลือกใช Case Tool ตางๆ มาชวยในการเขียน UML ได

5. สามารถวิเคราะหและออกแบบระบบงานตางๆ ที่กําลังสนใจ ในรูปแบบเชิงวัตถุได

System Analysis and Design 97

บทที่ 6 การวิเคราะหและออกแบบเชิงวัตถุ (Object-Oriented Analysis and Design)

6.1 ความหมายและแนวความคิดที่ใชในวิธกีารเชิงวตัถุ แนวคิดเชิงวัตถุ (Object-oriented approach) มีพื้นฐานกําเนิดมาจาก ปญหาหรือขอจํากัดของการพัฒนา

เชิงกระบวนการ (Procedural approach) ซึ่งจะตองมีการระบุเฉพาะเจาะจงถึงขั้นตอนของโปรแกรมคอมพิวเตอรที

ละขั้นตอน ทําใหโปรแกรมเมอรตองสนใจในรายละเอียดแตละขั้นเปนอยางมาก โปรแกรมที่ไดก็จะใหผลที่ดีกับงาน

เฉพาะดานเทานั้น ไมสามารถนําไปใชกับงานประเภทอื่นๆ ได ดังนั้นแนวคิดเชิงวัตถุ จึงเขามามีบทบาทมากขึ้น ทําให

สามารถใชงานไดอยางเหมาะสมกับโลกแหงความจริง โดยจะใชไดกับงานหลากหลายประเภท

รูปที่ 6.1 Procedural approach กับ Object-Oriented approach

รูปที่ 6.2 วิธีการพัฒนาแนว Object-Oriented

Object-Oriented Analysis and Design

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

กระบวนการพัฒนาเชิงวัตถุ จะเริ่มจากการศึกษาความเปนไปได และการวิเคราะหระบบเดิมที่มีอยู การมอง

ในเชิงวัตถุ (Object) เปนสวนประกอบในการวิเคราะหและออกแบบเชิงวัตถุ โดยวัตถุแตละอันจะมีคุณสมบัติ

(Attributes หรือเรียกวา Properties) ของตนเอง ที่จะใชแสดงถึงลักษณะการทํางาน (Behavior หรือเรียกวา

Methods) ภายใตคุณสมบัตินั้น

การวิเคราะหและออกแบบเชิงวัตถุ เปนวิธีการที่ไดรับความนิยม โดยการดูระบบจากมุมมองของตัว

ออบเจ็กตเอง เพราะออบเจ็กตทําหนาที่ปฏิบัติงานและเปนตัวโตตอบหรือปฏิสัมพันธกับระบบ โดยผลผลิตสุดทาย

ของการวิเคราะหเชิงวัตถุ คือ การจําลองแบบเชิงวัตถุ (Object Model) ซึ่งจะเปนตัวแทนของระบบสารสนเทศใน

ความหมายของออบเจ็กตและแนวความคิดเชิงวัตถุ ซึ่งเมื่อถึงระยะของการทําใหเกิดผลในวงจรการพัฒนาระบบ

นักวิเคราะหระบบและนักเขียนโปรแกรมก็จะทําการแปลงออบเจ็กตใหเปน สวนจําเพาะของรหัสชุดคําส่ัง ซึ่งการใช

วิธีการแยกเปนสวนจําเพาะหรือโมดูลาร (Modular) จะชวยประหยัดเงินและเวลา เนื่องจากสามารถถูกใชอยางเต็มที ่

สามารถถูกตรวจสอบ และสามารถนําเอากลับมาใชใหมไดอีก

ออบเจ็กตใชเปนตัวแทนของ คน สถานที่ เหตุการณ หรือทรานแซคชั่น จะมีแอททริบิวท ซึ่งแสดงคุณสมบัติ

ที่อธิบายถึงลักษณะของออบเจ็กตนั้นๆ เชน แอททริบิวทของรถยนต คือ ยี่หอ แบบ และสี นอกจากนั้น ออบเจ็กตยังมี

เมทธอดซึ่งเปนวิธีการปฏิบัติตามที่ไดรับเมซเสจ เชน รถยนตแสดงเมทธอดที่เรียกวาเปดที่ปดน้ําฝนเพื่อสงเมซเสจใหมี

การเคลื่อนไหวของที่ปดน้ําฝน ดังรูปที่ 6.3 แสดงตัวอยางของแอททริบิวท เมทธอดและเมซเสจของออบเจ็กตรถยนต

รูปที่ 6.3 ออปเจ็กตรถยนต

ในรูปที่ 6.3 เปนออปเจ็กตที่มีแอททริบิวท เชน ยี่หอ แบบ สี สามารถแสดงเมทธอดตามเมซเสจที่ไดรับ เชน

เมื่อไดรับเมซเสจใหเหยียบเบรค เมทธอดคือ การหยุดที่ไฟแดง หรือการใหหมุนกานปดน้ําฝนเพื่อเปดที่ปดน้ําฝน

ขอดีของ Object-oriented (OO)

1. ลดความซับซอนของการพัฒนาระบบ และยังทําใหการสรางและการดูแลเปนไปไดงาย และรวดเร็ว

2. พัฒนาความสามารถในการสราง และคุณภาพของโปรแกรมเมอร เนื่องจาก เม่ือมีการวางโครงราง

การนํามาใชงาน และมีการทดสอบ เราสามารถที่จะนําระบบนี้ไปใชกับระบบอื่นๆ ไดอีก

3. ระบบที่มีการพัฒนาดวย Object-oriented (OO) จะมีความยืดหยุน สามารถแกไข และเพิ่มเติม ได

อยางงาย

4. Object-Oriented (OO) จะถูกนักวิเคราะหระบบมองในแงของระบบในโลกของความเปนจริง ไมใช

แคเพียงระดับของโปรแกรมทางภาษา (Programming Language) คือ สามารถหาทาง แกไข

ปญหาที่เกิดขึ้นไดอยางทันที

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


6.2 คลาสและองคประกอบของคลาส

6.2.1 คลาส (Class)

คลาส คือ กลุมของออบเจ็กตที่มีแอททริบิวทและเมทธอดเหมือนกัน เชน Honda City สีแดง, รถตูรับสง

นักเรียน, รถบรรทุกฮีโน 6 ลอ, Toyota Wish สีดํา และอื่นๆ ตางก็เปนพาหนะ ดังนั้นตัวอยางรถทั้งหมดจึงอยูในคลาส

VEHICLE

จากตัวอยางขางตนนั้น เราจะเรียก Honda City สีแดง, รถตูรับสงนักเรียน, รถบรรทุกฮีโน 6 ลอ และ

Toyota Wish สีดํา วาเปน อินสแตนส (instance) ของคลาส VEHICLE

ออบเจ็กตภายในคลาสสามารถแบงกลุมออกเปนซับคลาส (Subclass) ซึ่งในซับคลาสก็มีการแบงเปนประเภทตางๆ ไดอีก เชน TRUCK Object เปนซับคลาสใน VEHICLE Class นอกจากนั้นยังมี CAR, MINIVAN และ SCHOOL BUS เปนซับคลาสใน VEHICLE Class เชนกัน ดูตัวอยางในรูปที่ 6.4 ใหสังเกตวาซับคลาสทั้ง 4 ประเภทมีลักษณะประจําคลายกับของ VEHICLE เชน ผูผลิต แบบ ป น้ําหนักและสี แตอยางไรก็ตาม ซับคลาสแตละประเภทสามารถจะมีลักษณะประจําที่ไมเปนลักษณะรวมกันได เชน ปริมาณสูงสุดในการบรรทุกของรถบรรทุก หรือตําแหนงที่ตั้งของประตูฉุกเฉินของรถรับสงนักเรียน เปนตน

รูปที่ 6.4 อินสแตนตของ VEHICLE Class และแอททริบิวทและเมทธอด ใน VEHICLE Class



คลาสสามารถที่จะจัดกลุมเพิ่มได เรียกวา ซุปเปอรคลาส (Superclass) เชน NOVEL Class อยูในซุปเปอรคลาสที่เรียกวา BOOK เพราะวานิยายทั้งหมดเปนหนังสือ ใน NOVEL Class สามารถมีซับคลาสตางๆ ไดเชน ชนิดปกแข็งและชนิดปกออน ดูตัวอยางที่คลายกันในรูปที่ 6.5 คือ EMPLOYEE Class อยูในซุปเปอรคลาสที่เรียกวา PERSON เพราะวาพนักงานทุกคนเปนคน และมี INSTRUCTOR เปนซับคลาสของ EMPLOYEE เปนตน

รูปที่ 6.5 ตัวอยางของซุปเปอรคลาส คลาส และซับคลาสของคน

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

วัตถุหรือออบเจ็กต หมายถึงส่ิงตางๆ ที่เราใหความสนใจ เชน นักศึกษา ปากกา ใบลงทะเบียนเรียน บัญชี

เงินฝากธนาคาร ตารางเที่ยวบิน เปนตน

ดังรูปที่ 6.6 แสดงถึง CHILD Object ซึ่งมีแอททริบิวท คือ ชื่อ อายุ เพศ และสีผม หากครอบครัวนี้มีลูก 3

คน ก็จะมีอินสแตนสของ CHILD Object 3 แบบ สามารถแสดงเมทธอด คือ หยิบของเลน กินอาหารเย็น เลนของ

เลน เพื่อสงสัญญาณให CHILD Object แสดงผลตางๆ ดังกลาว สวนการสงเมซเสจ ทําเพื่อให CHILD Object นั้น

เขาใจ เชน การสงเมซเสจวา ”DINNER’S READY” บอกให CHILD Object เดินมาที่โตะเพื่อรับประทานอาหาร และ

สงเมซเสจวา ”SHARE WITH YOUR BROTHER/SISTER” เพื่อบอกให CHILD Object ใหความรวมมือกับ CHILD

Object คนอื่นๆ



รูปที่ 6.6 แสดงอินสแตนทของ CHILD Object รวมทั้งแอททริบิวทและเมทธอดของ Object

6.2.3 คุณสมบัติหรือแอททรบิิวท (Attributes)

หากเปรียบออบเจ็กตเหมือนคํานาม แอททริบิวทก็เปรียบเหมือนคําคุณศัพท ซึ่งเปนการอธิบายคุณสมบัติของออบเจ็กต ออบเจ็กตบางตัวอาจมีแอททริบิวท 2 – 3 รายการ แตบางออบเจ็กตอาจมีเปนสิบๆ รายการได ทั้งนี้ขึ้นอยูกับความตองการของธุรกิจและของผูใช เชน ระบบการควบคุมสินคาคงคลัง อาจจะมีหมายเลขชิ้นสวน คําอธิบายลักษณะ ผูจัดจําหนาย จํานวนสินคาคงคลงั ระดับสินคาคงคลังต่ําสุดและสูงสุด รอบการสั่งสินคาใหม และอื่นๆ นักวิเคราะหระบบจะกําหนดแอททริบิวทในระหวางขั้นตอนของการออกแบบระบบเชิงวัตถุ โดยออบเจ็กตสามารถสืบทอดหรือรับเอาแอททริบิวทอื่นๆ จากออบเจ็กตอื่นไดดวย ซึ่งจะเขาใจสวนนี้ไดดีขึ้น เมื่อเรียนรูเร่ืองของความสัมพันธของออบเจ็กตและคลาสตอไป ออบเจ็กตสามารถมีแอททริบิวทเฉพาะตัว ที่เรียกวา สเตท (State) สเตทของออบเจ็กตนี้ ทําหนาที่เหมือนคําคุณศัพท ซึ่งอธิบายสถานะปจจุบันของออบเจ็กต ดูจากตัวอยางในรูปที่ 6.7 STUDENT สามารถเปน FUTURE Student, CURRENT Student หรือ PAST Student เชนเดียวกันกับ FITNESS-CLASS ซึ่งสามารถ OPEN, CLOSED หรือ CANCELED และรายการบัญชีของธนาคารสามารถแสดงสถานะเปน ACTIVE, INACTIVE, CLOSED หรือ FROZEN



รูปที่ 6.7 State ของ Student Object, Fitness-Class Object และ Bank Account Object

6.2.4 วิธีการหรือเมทธอด (Methods) เมทธอด จะหมายถึงงานอยางใดอยางหนึ่งที่ออบเจ็กตสามารถแสดงผลได หากเปรียบออบเจ็กตเปนคํานาม แอททริบิวทจะเปรียบเหมือนคําคุณศัพท และเมทธอดจะเปรียบเหมือนคํานาม ซึ่งอธิบายวาออบเจ็กตทําอะไร และทําอยางไร ตัวอยางเมทธอดของการทอดมันฝรั่งที่เรียกวา MORE FRIES Method ตามรูปที่ 6.8 ประกอบดวย อุนน้ํามันใหรอน เติมมันฝรั่งแชแข็งลงในตะกราทอด จุมตะกราลงในน้ํามัน ตรวจสอบความสุกของมันฝรั่งที่ทอดแลว ยกตะกราขึ้นเมื่อสุกและปลอยใหน้ํามันสะเด็ด เทมันฝรั่งที่ทอดแลวลงในถาดและโรยเกลือ

รูปที่ 6.8 ตัวอยางเมทธอดของการทอดมันฝรั่ง ที่ประกอบดวย 7 ขั้นตอน



6.2.5 ขาวสารหรือเมซเสจ (Messages)

เมซเสจ เปนคําส่ังที่บอกใหออบเจ็กตแสดงเมทธอดอยางใดอยางหนึ่ง เชน คําส่ัง ADD ส่ังใหเพิ่ม STUDENT Instance ใน STUDENT Class โดย STUDENT Class รูวาจะเพิ่ม หมายเลขประจําตัว ชื่อ และขอมูลอืน่ที่เกี่ยวกับผูเรียนใหมคนนั้น ดังรูปที่ 6.9 ในทํานองเดียวกันคําส่ัง DELETE จะบอกหรือส่ังการให STUDENT Class ทําการลบขอมูล STUDENT Instance นั้นทิ้ง

6.2.6 โพลิมอรฟสซึม (Polymorphism) โพลิมอรฟสซึม (Polymorphism) เปนการสงคําส่ังเดียวกัน ไปยังออบเจ็กตที่ตางกัน จะใหผลที่แตกตางกัน ตัวอยางเชน รูปที่ 6.10 คําสั่ง GOOD NIGHT สงสัญญาณให PARENT Object อานนิทานกอนนอน แตเม่ือคําส่ังเดียวกันสงสัญญาณให DOG Object เปนคําส่ังใหสุนัขไปนอน เมื่อสงคําส่ังดังกลาวให CHILD Object เปนสัญญาณใหเด็กขอน้ําดื่มกอนนอนหรือเตรียมตัวเขานอน

รูปที่ 6.9 ตัวอยางการสงเมสเซส Add และ Delete ไปยังคลาส STUDENT เพื่อเรียกใชเมทธอด



รูปที่ 6.10 ตัวอยางของโพลิมอรฟสซึม

6.2.7 เอ็นแคปซูเลชัน (Encapsulation)

ลองนึกภาพวา ออบเจ็กตเหมือน กลองดํา (Black Box) เพราะวาคําส่ังที่สงไปที่ออบเจ็กตกอใหเกิดการเปล่ียนแปลงขึ้นภายในออบเจ็กตนั้นได โดยไมตองบอกวาการเปลี่ยนแปลงนั้นเกิดขึ้นไดอยางไร เชน เมื่อเรากดปุมโทรศัพทเพื่อติดตอเพื่อน เราก็จะไมทราบวา ระบบของโทรศัพททํางานอยางไร มีการวิ่งของวงจรโทรศัพทอยางไร เราทราบเพียงวา การติดตอของเราสําเร็จหรือไมเทานั้น (ไดผลลัพธโดยไมรูวากระบวนการทํางานทําอยางไร) แนวคิดของกลองดําเปนตัวอยางของ เอ็นแคปซูเลชัน (Encapsulation) ซึ่งหมายถึง การที่ขอมูลและเมทธอดทุกอยางทํางานดวยตัวของมันเอง เจากลองดํานี้ไมตองการสิ่งรบกวนจากภายนอก โดยจํากัดทางที่เขาไปสูขั้นตอนการทํางานภายใน โดยออบเจ็กตจะมีการปองกันไมใหรูรหัสภายใน (Internal Code) เพื่อถูกเปล่ียนแปลงโดยออบเจ็กตหรือระบบอื่น การออกแบบเชิงวัตถุ โดยทั่วไปจะนําไปใชงานกับภาษาที่ใชเขียนโปรแกรมเชิงวัตถุ (Object-Oriented Programming Languages) ขอไดเปรียบสําคัญของการออกแบบเชิงวัตถุ คือ นักวิเคราะหระบบสามารถประหยัดเวลาและหลีกเลี่ยงขอผิดพลาด โดยการใชออบเจ็กตที่แยกเปนสวนๆ และนักเขียนโปรแกรมก็สามารถแปลงการออกแบบนั้นใหเปนรหัสไดสะดวก นอกจากนั้นยังสามารถนําโมดูลที่ผานการทดสอบแลว มาใชงานกับโมดูลอื่นไดอีก จากตัวอยางรูปที่ 6.11 เมื่อ SALES TRANSACTION Object สงเมซเสจไปยังอินสแตนสของ CUSTOMER Class ใหสังเกตวา SALES TRANSACTION Object และ CUSTOMER Class สามารถนําไปใชไดอีกในการขายอื่นๆ ซึ่งมีแอททริบิวทและเมทธอดที่คลายกันไดอีก

รูปที่ 6.11 SALES TRANSACTION Object สงคําส่ังให UPDATE BALANCE

ของอินสแตนสใน CUSTOMER Class



6.3 ความสัมพันธระหวางออบเจ็กตและคลาส ความสัมพันธทําใหออบเจ็กตสามารถติดตอส่ือสารและมีปฏิสัมพันธกัน เพื่อแสดงหนาที่ทางธุรกิจและการจัดการรายการตางๆ ของระบบที่ตองการได โดยความสัมพันธจะอธิบายสิ่งตางๆ ที่ออบเจ็กตตองการจะรูระหวางกันวาออบเจ็กตมีการตอบรับอยางไรตอการเปลี่ยนแปลงของออบเจ็กตอื่นๆ และจะมีผลกระทบกับกลุมสมาชิกในคลาส ซุปเปอรคลาสหรือซับคลาสอยางไร โดยลักษณะของความสัมพันธจะมีความหนักแนนมากนอยตางกัน

6.3.1 การพ่ึงพิงกัน (Dependency)

การพ่ึงพิงกัน (Dependency) เกิดขึ้นเมื่อออบเจ็กตหนึ่งไดรับขอมูลการเปลี่ยนแปลง จากอีกออบเจ็กตหนึ่ง เชน ความเกี่ยวของที่มีการพึ่งพิงกันของ SCHOOL BUS Object และ BUS ROUTE Object ซึ่งการเปล่ียนแปลงที่เกิดขึ้นกับ BUS ROUTE Object จะมีผลกระทบกับ SCHOOL BUS Object

รูปที่ 6.12 การพึ่งพิงกันของ SCHOOL BUS Object และ BUS ROUTE Object



6.3.2 การมีสวนรวม (Association) การมีสวนรวม (Association) จะมีความสัมพันธที่หนักแนนมากกวาการพึ่งพิงกัน เกิดขึ้นเมื่อแอททริบิวทบางอยางของออบเจ็กตถูกกําหนดโดยการปฏิสัมพันธที่เกิดขึ้นกับออบเจ็กตอื่น เชน ความเกี่ยวของที่มีความสัมพันธกันของ STUDENT Object และ REGISTRATION RECORD Object การเปลี่ยนแปลงที่เกิดขึ้นใน REGISTRATION RECORD Object ทําใหเกิดผลกระทบกับสถานภาพของ STUDENT Object

รูปที่ 6.13 การมีสวนรวม (Association) ของ STUDENT Object และ REGISTRATION RECORD Object



6.3.3 การรวมกลุม (Aggregation) การรวมกลุม (Aggregation) เกิดขึ้นเมื่อ ออบเจ็กตหนึ่งเปนสวนหนึ่งของอีกออบเจ็กตหนึ่ง เชน มีการกําหนดแอททริบิวทและเมทธอดของ EMPLOYEE Object แตอยางไรก็ตาม EMPLOYEE Object ก็ยังเปนสวนหนึ่งของ DEPARTMENT Object ซึ่งมีแอททริบิวทและเมทธอดที่แตกตางกัน ความสัมพันธของการรวมกลุมระหวาง EMPLOYEE และ DEPARTMENT มีความเกี่ยวของที่หนักแนนมากกวาการมีสวนรวมหรือการพึ่งพิงกัน เพราะวาสมาชิกทุกคนใน DEPARTMENT ตองเปนอินสแตนสของ EMPLOYEE Object

รูปที่ 6.14 ความสัมพันธของการรวมกลุมระหวาง DEPARTMENT Object และ EMPLOYEE Object

6.3.4 การสืบทอด (Inheritance)

การสืบทอด (Inheritance) เกิดขึ้นเมื่อ ออบเจ็กตหนึ่งไดรับการสืบทอดแอททริบิวทหนึ่งอยางหรือหลายอยางจากอีกออบเจ็กตหนึ่ง เชน ความเกี่ยวของที่มีการสืบทอดกันของ INSTRUCTOR Object และ EMPLOYEE Object ในสวนของ INSTRUCTOR Object ซึ่งสืบทอดคุณสมบัติตาง ๆ จาก EMPLOYEE Class และยังสามารถมีแอททริบิวทเพิ่มขึ้นจากเดิม



รูปที่ 6.15 การสืบทอดกันของ INSTRUCTOR Object และ EMPLOYEE Object

6.4 แผนผังความสัมพันธของออบเจ็กต หลังจากที่ไดรูจักออบเจ็กต คลาส และความเกี่ยวของกันแลว ตอนนี้พรอมที่จะเขียนแผนผังความเกี่ยวของกันของออบเจ็กต ซึ่งทําใหมองเห็นภาพโดยรวมของระบบ โดยจะใชแบบจําลองเหลานี้เพื่อเปนแนวทางสําหรับการพัฒนาแผนผังและเอกสารอื่นๆ ตอไป รูปที่ 6.16 แสดงแผนผังความเกี่ยวของกันของออบเจ็กตภายในสถานออกกําลังกาย ใหสังเกตวาแบบจําลองดังกลาวแสดงออบเจ็กตตางๆ และการมีปฏิสัมพันธของการปฏิบัติงานและจัดการทรานแซคชั่น

รูปที่ 6.16 แผนผังความเกี่ยวของกันของออบเจ็กตภายในสถานออกกําลังกาย



6.5 การจําลองแบบเชิงวตัถุดวย UML

จากการวิเคราะหเชิงโครงสราง จะใชแผนภาพกระแสขอมูล (Data Flow Diagram: DFD) ในการแสดงแบบจําลองขอมูลและประมวลผล สวนการการวิเคราะหเชิงวัตถุ นักวิเคราะหระบบมักใช UML เพื่อเปนเครื่องมือเพื่ออธิบายระบบเชิงวัตถุ UML(Unified Modeling Language) ประกอบดวยแผนผังตางๆ ซึ่งใชสัญลักษณโดยทั่วไปและเครื่องหมายตางๆ ซึ่งเปนวิธีการแบบเบ็ดเสร็จ ทําใหงายตอการสราง การอาน และการใชประโยชนจากแผนผังของ UML โดยจะใช UML เพื่ออธิบาย ยูสเคสไดอาแกรม คลาสไดอาแกรม ซีคเว็นซไดอาแกรม สเตททรานสิชั่นไดอาแกรม และ แอคทิวิตี้ไดอาแกรม

6.5.1 แบบจําลองกรณีหรือยูสเคสโมเดลลิ่ง (Use Case Modeling) ยูสเคสเปนตัวแทนของขั้นตอนตางๆ ในการทําหนาที่ทางธุรกิจอยางใดอยางหนึ่งหรือการประมวลผลธุรกิจใดธุรกิจหนึ่ง โดยจะเรียก เอนทิตีภายนอก วา ผูแสดง (Actor) เอนทิตีนี้ เร่ิมตนใชยูสเคส โดยการรองขอใหระบบแสดงหนาที่หรือใหประมวลผล จากรูปที่ 6.17 ในระบบทางการแพทย เมื่อคนไขทําการนัดหมายเพื่อพบแพทย ผูแสดงคือ PATIENT และยูสเคส คือ MAKE APPOINTMENT

รูปที่ 6.17 ตัวอยางผูแสดง (Actor) คนไข ใชยูสเคสนัดหมายแพทย

ขอสังเกตของสัญลักษณ UML สําหรับยูสเคสจะเปนรูปวงรี ซึ่งมีคําอธิบายใตสัญลักษณเปนการกระทําหรือเหตุการณ สําหรับผูแสดงใชสัญลักษณรูปตัวคนและมีคําอธิบายบทบาทของผูแสดงนั้น ลูกศรที่ขีดจากผูแสดงไปยังสัญลักษณวงรีแสดงถึงความสัมพันธ เพราะเปนการเชื่อมโยงผูแสดงเขากับยูสเคส ในรูปที่ 6.18 เปนตัวอยางแสดงยูสเคสของผูโดยสารที่จองตั๋วเครื่องบิน ลูกคาที่ส่ังซื้อสินคา และพนักงานขับรถที่เปล่ียนสถานที่ในการรับผูโดยสาร

รูปที่ 6.18 ตัวอยางยูสเคสโมเดล โดยการใชสัญลักษณของ UML



ยูสเคสสามารถมีปฎิสัมพันธกับยูสเคสอื่นๆ ได โดยเมื่อผลของยูสเคสอันหนึ่งเขารวมกันกับยูสเคสอีกอันหนึ่ง คือ ยูสเคสอันที่สอง ใชงาน ยูสเคสอันแรก ซึ่ง UML ไดกําหนดความสัมพันธดวยลูกศรที่มีหัวบอดชี้ไปยังยูสเคสที่กําลังใชงานอยู กรณีของผูเรียนตองการเพิ่มช้ันเรียน ในสวนของ PRODUCE FITNESS-CLASS ROSTER ซึ่งใชผลของการ ADD FITNESS-CLASS เพื่อแสดงบัญชีรายชื่อของชั้นเรียนใหม สําหรับกรณีเม่ือมีการปรับปรุงขอมูลของผูสอน UPDATE INSTRUCTOR INFORMATION ใช CHANGE AVAILABILITY ยูสเคส ในการปรับปรุงขอมูลของ INSTRUCTOR Object

รูปที่ 6.19 ตัวอยางการมีปฏิสัมพันธกันระหวางยูสเคสอันหนึ่ง กับยูสเคสอีกอันหนึ่ง

ในการสรางยูสเคส ใหเริ่มตนโดยการพิจารณาจากขอมูลตางๆ ที่เก็บรวบรวมในชวงของการสรางแบบจําลองความตองการ จุดมุงหมายคือ การกําหนดตัวผูแสดงและการทําหนาที่ทางธุรกิจหรือการประมวลผล และสําหรับในแตละยูสเคส ตองทําการสรางคําอธิบายยูสเคส (Use Case Description) ในรูปของตาราง ซึ่งประกอบดวยรายการชื่อของยูสเคส ผูแสดง คําอธิบายของยูสเคส ขั้นตอนของงานและการกระทําเพื่อใหงานนั้นสําเร็จผล นอกจากนั้น ยังมีคําอธิบายของทางเลือกในการกระทํา มีเงื่อนไขกอนทํา เงื่อนไขหลังทํา และสมมุติฐาน ดังในรูปที่ 6.20 ซึ่งเปนการแสดงตัวอยางของ ADD NEW STUDENT Use Case และ CANCEL FITNESS-CLASS Use Case



Add New Student Use Case Name : Add New Student

Actor : StudentManager

Description : Describes the process used to add a student to a fitness-class

Successful 1. Manager checks FITNESS-CLASS SCHEDULE object for availability

Completion : 2. Manager notifies student

3. Fitness-class is open and student pays fee

4. Manager registers student

Alternative : 1. Manager checks FITNESS-CLASS SCHEDULE object for availability

2. Fitness-class is full

3. Manager notifies student

Precondition : Student requests fitness-class

Postcondition : Student is enrolled in fitness-class and fees have been paid

Assumptions : None

Add New Student

Cancel Fitness-class Use Case Name : Cancel Fitness-class

Actor : Manager

Description : Describes the process used cancel a fitness-class

Successful 1. Manager notifies FITNESS-CLASS SCHEDULE object of canceled class

Completion : 2. FITNESS-CLASS SCHEDULE object produce letters notifying students enrolled in the

fitness-class of the cancellation

3. Manager refunds fees to student

4. Manager notifies INSTRUCTOR object of canceled fitness-class

Alternative : None

Precondition : Fitness-class has been canceled

Postcondition : Student have been notified of cancellation and refunds have been made

Assumptions : None

Cancel Fitness-class

รูปที่ 6.20 คําอธิบาย ADD NEW STUDENT Use Case และ CANCEL FITNESS-CLASS Use Case

แผนผังกรณี แผนผังกรณีหรือยูสเคสไดอาแกรม (Use Case Diagrams) เปนการสรุปใหเห็นถึงภาพรวมของความสัมพันธของยูสเคสตางๆ ที่อยูภายในระบบ เชน แผนกบริการลูกคาของอูซอมรถยนต ซึ่งในระบบของการทํางานจะเกี่ยวของกับลูกคา พนักงานใหบริการผูมีหนาที่เขียนคําส่ังรายการซอมและใบเรียกเก็บเงิน และชางผูทําหนาที่ซอมรถยนต



รูปที่ 6.21 ยูสเคสไดอาแกรมแสดงถึงงานตางๆภายในแผนกบริการลูกคาของอูซอมรถยนต

ในการสรางยูสเคสไดอาแกรม ขั้นตอนแรกคือ กําหนดขอบเขตของระบบ ซึ่งมีลักษณะเปนรูปส่ีเหลี่ยมผืนผา ในขอบเขตของระบบ (System Boundary) จะแสดงทุกส่ิงทุกอยางที่รวมอยูในระบบ (อยูภายในรูปส่ีเหลี่ยมผืนผา) และทุกส่ิงทุกอยางที่อยูนอกระบบ (อยูภายนอกรูปส่ีเหลี่ยมผืนผา) หลังจากที่กําหนดขอบเขตของระบบแลว ใหจัดวางยูเคสตางๆ ลงในไดอาแกรม รวมทั้งผูแสดงตาง ๆ และแสดงถึงความสัมพันธตางๆ ที่มีภายในระบบนั้น

6.5.2 แผนผังแบงกลุม (Class Diagram) แผนผังแบงกลุม (Class Diagram) จะแสดงรายละเอียดของยูสเคสหนึ่งๆ ที่แสดงถึงคลาสตางๆ ซึ่งมีสวนรวมอยูในยูสเคสนั้นๆ รวมทั้งเอกสารที่แสดงความสัมพันธที่มีอยูในคลาสตางๆ ดังกลาว เชนเดียวกันกับ DFD คลาสไดอาแกรมคือแบบจําลองเชิงตรรกะ ซึ่งเกี่ยวของกับแบบจําลองเชิงกายภาพ และทายที่สุดจะกลายเปนภาระงานของระบบงานสารสนเทศ (Functioning Information System) สําหรับในการวิเคราะหเชิงโครงสราง คือ เอนทิตี ดาตาสโตร และโพรเสจ ที่จะถูกแปลงเปนโครงสรางขอมูล และรหัสชุดคําส่ัง (Program Code) เชนเดียวกับ คลาสไดอาแกรม จะเกี่ยวของกับรหัสสวนจําเพาะ ดาตาอ็อบเจกต และองคประกอบอื่นๆ ของระบบ ในขั้นแรกของการตรวจสอบยูสเคสและการกําหนดคลาสตางๆ ซึ่งมีสวนรวมอยูในการจัดการของธุรกิจประเภทนั้นๆ โดยในคลาสไดอาแกรม จะระบุแตละคลาสไวในรูปส่ีเหลี่ยมผืนผาและมีชื่อคลาสปรากฏอยูดานบน ตามดวยแอททริบิวทและเมทธอดของคลาส นอกจากนั้นจะมีเสนพรอมลูกศร แสดงความสัมพันธและคําอธิบายซึ่งแสดงการทําหนาที่ของความสัมพันธของคลาสทั้งสอง



คลาสไดอาแกรมยังรวมถึงแนวคิดที่เรียกวา คาดิแน็ลลิตี้ (Cardinality) ซึ่งอธิบายอินสแตนสของคลาสหนึ่งมีความเกี่ยวของกับอินสแตนสของอีกคลาสหนึ่งอยางไร ตัวอยางเชน ลูกจางอาจมีวันพักแตกตางกัน บางคนไมมีวันพักเลย บางคนมีหนึ่งวันหรือหลายวัน ในทํานองเดียวกันลูกจางบางคนมีคูสมรสหรือบางคนไมมี ในรูปที่ 6.22 แสดงเครื่องหมายตางๆ ของ UML และตัวอยางตางๆ ซึ่ง คาดิแน็ลลิตี้ ยังมีสวนสําคัญในชวงของการออกแบบวิเคราะหโครงสรางขอมูลของระบบ

รูปที่ 6.22 เครื่องหมายตางๆ ของ UML

จากรูปที่ 6.23 แสดงคลาสไดอาแกรมของ SALES ORDER Use Case ใหสังเกตวาพนักงานขายมีผูจัดการขายดูแลเพียง 1 คน สําหรับผูจัดการขายสามารถมีพนักงานขายอยูในความดูแลไดตั้งแตไมมีสักคนถึงมีหลายคน พนักงานขายสามารถมีลูกคาอยูในความรับผิดชอบไดตั้งแตไมมีสักคนเดียวหรือมีหลายคน แตลูกคาแตละคนจะมีพนักงานขายดูแลเพียงคนเดียว Sales Manager

Attributes

Methods

Sales Rep

Attributes

Methods

Sales Office

Attributes

Methods

Customer

Attributes

Methods

Order

Attributes

Methods

Items Ordered

Attributes

Methods

Assigned to Manages Assigned

Manages

Places

Consist

1

1

1

1

1

1

0..*

0..*

0..*

0..*

0..* 1..*

รูปที่ 6.23 คลาสไดอาแกรมของ SALE ORDER Use Case



6.5.3 แผนผังลําดับเหตุการณ (Sequence Diagrams) แผนผังลําดับเหตุการณ (Sequence Diagrams) คือ ไดนามิคโมเดล (Dynamic Model) ของยูสเคส แสดง

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

คลาส (Class) สัญลักษณของคลาส เปนรูปส่ีเหลี่ยมผืนผา ซึ่งมีชื่ออยูขางใน การสงหรือรับคําส่ังจะแสดงอยูที่สวนบนสุดของซีคเวนซไดอาแกรม

ไลฟไลน (Lifeline) สัญลักษณของไลฟไลนเปนเสนไขปลา ดูตัวอยางในรูปที่ 6.24 ไลฟไลนหมายถึงระยะเวลาซึ่งออบเจ็กตที่อยูขางบนมาปฎิสัมพันธกับออบเจ็กตอีกอันหนึ่ง ซึ่งอยูภายในยูสเคสเดียวกันเครื่องหมาย X แสดงถึงการสิ้นสุดของไลฟไลน

รูปที่ 6.24 ไลฟไลนของคลาส เครื่องหมาย X แสดงจุดส้ินสุดของไลฟไลนของคลาสที่ 2

เมซเสจ (Message) สัญลักษณของคําส่ังเปนเสนซึ่งขีดอยูระหวางออบเจ็กตทั้งสอง โดยดูตัวอยางจากรูปที่ 6.25 ปายคําส่ังแสดงชื่อของคําส่ัง และสามารถแสดงขอมูลเพิ่มเติมในคําส่ังนั้น ๆ

รูปที่ 6.25 แสดงการสง Message ระหวางออบเจ็กต



โฟกัส (Focus) สัญลักษณของโฟกัสเปนรูปส่ีเหลี่ยมผืนผา ซึ่งวางในแนวตั้งและวางครอบเสนไลฟไลน ดูตัวอยางในรูปที่ 6.26 โฟกัสเริ่มใชงานเมื่อออบเจ็กตสงคําส่ังหรือไดรับคําส่ัง

รูปที่ 6.26 โฟกัสของคลาสซึ่งแสดงระยะเวลาเมื่อคําส่ังถูกสงออกไป หรือเมื่อออบเจ็กตไดรับคําสั่ง

รูปที่ 6.27 Sequence Diagram ของ ADD NEW STUEDNT Use Case



6.5.4 แผนผังการเปล่ียนแปลงสภาพ (State Transition Diagrams)

แผนผังการเปลี่ยนแปลงสภาพ (State Transition Diagrams) แสดงถึงการเปลี่ยนแปลงของออบเจ็กตจากสถานะหนึ่งไปสูอีกสถานะหนึ่ง

รูปที่ 6.28 ตัวอยาง State Transition Diagram ของบัญชีธนาคาร

ใน State Transition Diagram เครื่องหมายของสถานะจะมีลักษณะสี่เหลี่ยมผืนผาที่มีมุมโคงทั้ง 4 ดาน ภายในมีชื่อปรากฏอยูดวย ทางดานซายจะมีเครื่องหมายวงรีขนาดเล็ก ซึ่งแสดงสถานะของการเริ่มตนหรือเปนจุดที่ออบเจ็กตเร่ิมตนมีปฏิสัมพันธกับระบบ การอานเริ่มตนจากซายไปขวา เสนตางๆ แสดงทิศทาง พรอมทั้งอธิบายการกระทําหรือเหตุการณ ซึ่งเปนสาเหตุใหเกิดการจัดการจากสถานะหนึ่งไปยังสถานะอื่น วงกลมที่จุดดําตรงกลางซึ่งอยูทางขวาเปนจุดส้ินสุดสถานะ

จากตัวอยางในรูป 6.29 แสดงสถานะของผูเรียนในสถานออกกําลังกาย FUTURE Student ที่เขามาเรียนใน

ชั้นเรียนจะกลายเปน CURRENT Student และเมื่อเรียนจบหรือยกเลิกการเรียน ผูเรียนนั้นก็จะกลายเปน PAST Student ใหสังเกตวาผูเรียนเกาซึ่งไมไดมาใชบริการเกิน 12 เดือน เมื่อมาลงทะเบียนอีกจะมีสถานะภาพเปนผูเรียนใหม

รูปที่ 6.29 ตัวอยาง State Transition Diagram ของผูเรียนในสถานออกกําลังกาย



6.5.5 แผนผังกจิกรรม (Activity Diagrams)

แผนผังกิจกรรม (Activity Diagrams) มีลักษณะคลายกับผังงานแนวนอน ซึ่งแสดงถึงการกระทําและเหตุการณตางๆ ในขณะที่ส่ิงตางๆ เหลานั้นเกิดขึ้นอยู ไดอาแกรมดังกลาวแสดงถึงการออกคําส่ังซึ่งทําใหมีการกระทําตางๆ เกิดขึ้น และกอใหเกิดผลของการกระทํา เชน ในรูปที่ 6.30 แสดง Activity Diagram ของการถอนเงินสดที่เครื่องบริการรับจายเงินอัตโนมัติ (ATM) ใหสังเกตวาลูกคาเริ่มตนการกระทําโดยการสอดบัตรและขอถอนเงินสด Activity Diagram ยังสามารถใชงานในลักษณะหลายๆ ยูสเคส ตอเปนรูปแบบของตะแกรงขดลวด ซึ่งมีคลาสตางๆ แสดงอยูในลักษณะของแทงส่ีเหลี่ยมผืนผาในแนวนอน และการกระทําตางๆ จะใชเครื่องหมายลูกศรในแนวนอน

รูปที่ 6.30 Activity Diagram ในการถอนเงินจากเครื่องบริการรับจายเงินอัตโนมัติ

6.4 เคสทลู (CASE Tools) มีการใชไดอะแกรมไดหลายแบบเพื่อเปนตัวแทนของระบบที่จะนําเสนอ แตหากจัดทําไดอะแกรมดวยมืออาจตองใชเวลาและนาเบื่อหนาย ดังนั้น นักวิเคราะหระบบจึงมักใชเคสทูล เพื่อทําใหขบวนการทั้งหมดรวดเร็วขึ้นและเตรียมโครงรางทั้งหมดสําหรับการทําเอกสารของสวนประกอบตางๆ ของระบบ นอกจากนั้น เคสทูลยังทําใหเกิดความแนใจของการเขากันไดและเตรียมการเชื่อมโยงทั่วๆ ไป เมื่อมีการกําหนดออบเจ็กตขึ้นและถูกใชเปนสวนหนึ่งของระบบ ออบเจ็กตเหลานั้นสามารถนําเอามาใชใหมไดอีกหลายๆ ครั้ง โดยไมตองทําอะไรเพิ่มเติมอีก ตัวอยางของเคสทูล ไดแก System Architect 2001 (SA/2001) ซึ่งจะสรางและปรับปรุงขอมูลที่รวมกันอยู เรียกวา สารานุกรม ในขณะที่ทําการสรางโมเดลดวย SA/2001 นักวิเคราะหระบบสามารถจัดทําเอกสารขั้นตอนตางๆ ในยูสเคส และอธิบายเหตุการณตางๆ ในลักษณะของแผนผังการเปลี่ยนสถานะ ตามรูปที่ 6.31



รูปที่ 6.31 การสรางยูสเคสและสเตททรานสิชั่นไดอะแกรมดวย SYSTEM ARCHITECT 2001

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


บทที่การว 6 ิเคราะห และออกแบบเช...

Documents