22 ตอนที่ 4.2 การออกแบบและพัฒนาซอฟตแวรสําหรับระบบอัตโนมัติของเครือขาย โปรดอานแผนการสอนประจําตอนที่ 42 แลวจงศกษาเนอหาสาระ พรอมปฏบตกจกรรมในแตละเรอง หัวเรื่อง 4.2.1 วงจรการพัฒนาระบบ 4.2.2 แนวทางการออกแบบและพัฒนาซอฟตแวรแบบอไจล 4.2.3 ยูเอ็มแอลและการรวบรวมความตองการดวยยูเอ็มแอล 4.2.4 การวิเคราะหและการออกแบบซอฟตแวรดวยยูเอ็มแอล แนวคิด 1. วงจรการพัฒนาระบบ เปนชุดของกิจกรรมสําหรับดําเนินการเพื่อพัฒนาระบบสารสนเทศ ประกอบดวย การนิยามปญหา การศึกษาความเปนไปได การวิเคราะหระบบ การออกแบบระบบ การนําใช และการบํารุงรักษา ซึ่งเปนแนวทางโดยทั่วไปที่สามารถนําไปใชสําหรับการพัฒนา ซอฟตแวรระบบอตโนมตของเครอขายได 2.
เปนแนวทางใหมทเหมาะกบสถานการณในปจจบน ท สภาพแวดลอมในการดําเนินธุรกิจมีการเปลี่ยนแปลงอยางรวดเร็ว ตองการแนวทางการพัฒนาที่ คลองแคลว ยืดหยุน เนนการพัฒนาและนําซอฟตแวรออกใชงานไดรวดเร็วขึ้น มีประสิทธิภาพ ไดรับความนิยม และใชกันแพรหลายมากขึ้น โดยมีเจตนารมณที่ใหคุณคากับ คนและการ ปฏิสัมพันธ ซอฟตแวรที่ใชงานได การรวมมือกับลูกคาหรือผูใช และการตอบสนองตอการ เปลี่ยนแปลง 3. ยูเอ็มแอล เปนภาษาที่ใชระบบสัญกรณเพื่อบรรยายลักษณะของแบบจําลองเชิงวัตถุของระบบ สําหรับกําหนดขอบเขตของปญหา รวบรวมความตองการระบบ วิเคราะหระบบ ออกแบบระบบ และนําเสนอแนวความคิดของกระบวนการทํางานที่มีในแตละขั้นตอนของการพัฒนาระบบ สารสนเทศ โดยแผนภาพของยูเอ็มแอลแบงไดเปน 2 กลุมคือ แผนภาพโครงสรางและแผนภาพ พฤติกรรม สําหรับการรวบรวมความตองการนั้น เปนดําเนินการเพื่อสรางความเขาใจถึงความ ตองการในบริบทของธุรกิจและสรางความเขาใจเชิงเทคนิคของระบบ แสดงรายละเอียดของความ ตองการของระบบในรูปของเอกสารซึ่งระบุผูใชงานทั้งหมดที่เกี่ยวของสําหรับนําไปใชในการ วิเคราะหและออกแบบ และกําหนดขอบเขตของระบบที่จะพัฒนาไมใหกวางจนเกินกวาจะทําได
แนวทางการพฒนาซอฟตแวรแบบอไจล
1. อธิบายวงจรการพัฒนาระบบได
2. อธิบายแนวทางการออกแบบและพัฒนาซอฟตแวรแบบอไจลได
3. อธิบายยูเอ็มแอลและการรวบรวมความตองการดวยยูเอ็มแอลได
4. อธิบายการวิเคราะหและการออกแบบซอฟตแวรดวยยูเอ็มแอลได
23 สําเร็จตามเวลาและงบประมาณที่กําหนด หรือแคบไปจนไมสามารถตอบสนองความตองการของ ธุรกิจได 4. การวิเคราะหซอฟตแวรดวยยูเอ็มแอลนั้น เปนการนําแบบจําลองและขอมูลที่ไดมาจากขั้นตอน การรวบรวมความตองการมาคนหาคลาสและกําหนดเปนคลาสในแผนภาพ จากนั้นกําหนด รูปแบบของความสัมพันธระหวางคลาส กําหนดคุณลักษณะที่เหมาะสมใหกับคลาส นํายูสเคส ระบบทั้งหมดที่ไดมาจากการสรางแบบจําลองความตองการ มาตรวจสอบกระบวนการที่ระบุใน ยูสเคส เพื่อใหสามารถรองรับความตองการทั้งหมดไดอยางครบถวนสมบูรณ แลวปรับปรุงแกไข แผนภาพคลาสใหมีความสมบูรณมากขึ้น และปรับปรุงอภิธานศัพท สําหรับการออกแบบ ซอฟตแวรดวยยูเอ็มแอลนั้น เปนการจับคูคลาส ความสัมพันธระหวางคลาส กําหนดตัวเขาถึง สําหรับการนําคาภายในคลาสมาใชงาน เพิ่มเติมรายละเอียด เลือกใชแพตเทิรนในการออกแบบ และสรางแบบจําลองการออกแบบสถาปตยกรรม วัตถุประสงค เมื่อศึกษาตอนที่
4.2 จบแลว นักศึกษาสามารถ
โดยทั่วไปนักวิเคราะหระบบจะเปนผูนําเสนอนิยามและทิศทางของโครงการพัฒนาระบบหรือ ซอฟตแวรโดยระบบจะถูกนําเสนอหลังจากนักวิเคราะหไดทําความเขาใจภาพรวมทั้งหมดของความตองการ
ความจาเปนและปญหาตางๆของผใชโดยระบบหรอซอฟตแวรทนาเสนอจะสามารถใชในการทางานรวมกน ระหวางผใชกลมตางๆขององคกรได
ทงนการพฒนาซอฟตแวรหรอระบบสารสนเทศใดๆนนขอใหยดหลกไววาเปนไปเพอการแกปญหา ใดปญหาหนงตามทผใชตองการซงโดยทวไปการแกปญหามดวยกน5ขั้นตอนคือ(1)การทําความเขาใจ ปญหาเปนการพิจารณาขอบเขตของปญหา(problemdomain)ใหละเอยดครบถวน(2)การออกแบบทาง แกปญหาโดยการแตกปญหาหรืองานออกเปนงานยอยที่สามารถจัดการได(3)การพิจารณาทางเลือกตางๆ ทางแกปญหาทไดออกแบบมานนอาจจะไมใชทางแกทดทสดตองพจารณาทางเลอกและปรบใหดขน(4)การ สรางโซลชนเปนการนาสงทออกแบบไวมาสรางเปนซอฟตแวรหรอแอปพลเคชนและ(5)การทดสอบโซลูชัน และแกไขปญหาเปนการทดสอบในระหวางการพฒนาเพอหาขอผดพลาดและแกไขใหถกตองแตการทดสอบ ไมไดรบประกนวาจะไมมปญหาใดๆเกดขนอกในอนาคตเพยงแตทาใหมนใจไดวาโซลชนทพฒนาขนนน สามารถทํางานไดและนําไปใชแกปญหาได
วงจรการพัฒนาระบบหรือเอสดีแอลซี(SystemDevelopmentLifeCycle–SDLC)เปนชุดของ กิจกรรมซึ่งนักวิเคราะหนักออกแบบและผูใชรวมกันดําเนินการเพื่อพัฒนาระบบสารสนเทศหรือระบบหรือ
24
เรื่องที่4.2.1วงจรการพัฒนาระบบ
ภาพที่4.7วงจรการพัฒนาระบบ วงจรการพฒนาระบบประกอบดวยขนตอนตางๆดงน 1.การนิยามปญหา การนิยาม ปญหา การศึกษา ความ เปนไปได การ วิเคราะห การ ออกแบบ การนําใช การ บํารุงรักษา
ซอฟตแวร(ภาพที่4.7)
25 สิ่งสําคัญเรื่องแรกคือ จะตองรูถึงปญหาตาง ๆ ซึ่งเปนพื้นฐานสําหรับระบบที่จะถูกนําเสนอ เปนการ
ที่จะนําไปสูการ สํารวจเบื้องตนหรือริเริ่มการทวนสอบเพื่อกําหนดทางเลือกตาง ๆ ในการพัฒนาระบบสําหรับแกปญหา เหลานน
แตไมมประสทธภาพ หรอการนาบางสวนของระบบทมอยแลวมาพฒนาใหเปนกระบวนการทางานทดขน ประเด็นสําคัญที่ควรพิจารณาอีกเรื่องหนึ่งคือ ความตองการการเปลี่ยนแปลงของระบบ ซึ่งแนวคิด หรือไอเดียตาง ๆ สําหรับการเปลี่ยนแปลง อาจจะมาจากสภาพแวดลอมภายนอกองคกรหรือภายในองคกร แนวคดการเปลยนแปลงทมาจากสภาพแวดลอมภายนอก มกจะเกดจากลกคา ตวแทนจาหนาย หรอหนวยงาน ภาครัฐ เมื่อทําการตรวจสอบแลว แนวคิดหรือไอเดียเหลานี้ที่จะตองตอบสนองตอความตองการการ เปลี่ยนแปลงของระบบก็จะนํามาสูการนิยามปญหานั่นเอง สาหรบแนวคดการเปลยนแปลงทมาจากภายในองคกร มกจะเกดจากผบรหารระดบสง ผใชงาน และ ตัวนักวิเคราะหระบบเอง เมื่อมีการเปลี่ยนแปลงภายในองคกรเกี่ยวกับการปฏิบัติงานหรือความกาวหนาทาง เทคโนโลยี อาจจะรูสึกวามีความจําเปนจะตองอัปเดตแอปพลิเคชันที่มีอยูหรือปรับปรุงขั้นตอนการดําเนินงาน ใหดีขึ้น หรือเกิดปญหาที่รุนแรงในการดําเนินงานทําใหผูบริหารระดับสูงตองเขามาตรวจสอบ ทั้งนี้ ผูบริหาร
ๆ ทไดรบแลวเกดขอสงสยใน ตวเลข ซงไอเดยหรอแนวคดเหลานจะนําไปสูการศึกษาในเรื่องตาง ๆ ตามที่ผูบริหารรองขอมา สําหรับแนวคิดการเปลี่ยนแปลงที่มาจากผูใชงาน แนวคิดที่มาจากผูใชมักจะเกิดการประสบเหตุการณ จากสภาพแวดลอมการทํางานของตนเอง การแปลงไอเดียของผูใชไปสูการศึกษาความเปนไปไดนั้น จะเกิดขึ้น ภายในขอบเขตมากนอยแคไหนหรืออยางรวดเร็วเพียงใด ซึ่งขึ้นอยูกับปจจัยหลายอยาง เชน ความเสี่ยงและ ผลลัพธที่จะไดกลับมา ตนทุนดานการเงินและแหลงทุนสําหรับการทําใหระบบทํางาน และการจัดลําดับ ความสําคัญของโครงการตาง ๆ ในบริษัท เปนตน ซึ่งปจจัยเหลานี้เปนสิ่งสําคัญ ที่จะทําใหเกิดการตอบสนอง ตอความตองการการเปลี่ยนแปลงของผูใช 2. การศึกษาความเปนไปได จากผลการตรวจสอบและสํารวจปญหาและความตองการในขั้นตอนแรกของการนิยามปญหา นํามาสู การขยายผลในขั้นตอนตอมาคือ การศึกษาความเปนไปได (feasibility study) ซึ่งเปนการทดสอบขอเสนอ โครงการในประเด็นของ ความสามารถในการทํางาน ผลกระทบตอองคกร ความสามารถที่จะตอบสนองความ ตองการของผูใช และประสิทธิภาพในการใชทรัพยากร โดยจะเนน 3 ดาน ดังนี้ อะไรคือความจําเปนของผูใชที่สามารถแสดงใหเห็นไดอยางชัดเจน และระบบหรือซอฟตแวร ที่นําเสนอจะสามารถตอบสนองความตองการของผูใชไดอยางไร
รับรูรับทราบถึงความจําเปนในการปรับปรุงระบบสารสนเทศหรือขั้นตอนการดําเนินงาน
นาไปสการพจารณาความซาซอนในเรองของการทางาน จดทเปนคอขวด ขนตอนการทางานทมอย
อาจจะไดแนวคดการเปลยนแปลงหรอไอเดยจากการอานขอมลหรอรายงานตาง
26 ทรพยากรใดบางทพรอมสาหรบการพฒนาระบบหรอซอฟตแวรทนําเสนอ ปญหาที่ตองแกไข นั้นมีคุณคาเพียงพอที่จะดําเนินการพัฒนาระบบหรือซอฟตแวรที่นําเสนอหรือไม ผลกระทบของระบบหรือซอฟตแวรที่นําเสนอที่มีตอองคกรมีอะไรบาง ระบบหรือซอฟตแวรที่
หรอไม คําถามเหลานี้จะตองไดรับการตอบอยางระมัดระวังเพราะเกี่ยวของกับ การทวนสอบและการประเมิน ปญหาในภาพรวมทั้งหมด การระบุหรือจําแนกและอธิบายระบบหรือซอฟตแวรที่นําเสนอ คุณสมบัติหรือ ประสิทธิภาพ คาใชจายของแตละระบบ และการคัดเลือกในตอนสุดทายเพื่อใหไดระบบหรือซอฟตแวรที่ดีที่สุด วัตถุประสงคของการศึกษาความเปนไปไดนั้น นอกจากดําเนินการเพื่อแกปญหาแลวจะตองคํานึงถึง ขอบเขตของระบบหรือซอฟตแวรดวย ในระหวางการศึกษาความเปนไปไดจะตองมีการนิยามปญหาใหตกผลึก เห็นเปนรูปธรรม และประเด็นตาง ๆ ของปญหาทั้งหมดจะตองถูกรวบรวมเอาไวในระบบ ซึ่งจะทําใหตนทุน และกําไรจากการพัฒนาระบบหรือซอฟตแวรไดรบการคาดคะเนออกมาอยางถกตองทสด ผลของการศึกษาความเปนไปได คือ ขอเสนอโครงการที่เปนทางการ ในลักษณะของรายงานที่เปน เอกสารทางการ ซึ่งมีรายละเอียดเกี่ยวกับโซลูชัน10 ทั้งหมดและมีขอบเขตงานชัดเจน โดยขอเสนอโครงการจะ สรปวา มอะไรทจาเปนจะตองรและมอะไรทจาเปนจะตองดาเนนการ ประกอบดวยสงเหลานคอ ขอความเกี่ยวกับปญหา (statement of the problem) เปนขอความที่เปนลายลักษณ อักษรระบุถึงปญหาที่จะนําไปสูการวิเคราะหระบบ ขอสรุปสิ่งที่คนพบและขอเสนอแนะ (summary of findings and recommendations) เปนรายการของสงทคนพบหลก ๆ และขอเสนอแนะของการศกษา ความเปนไปได ซึ่งเปนสิ่งที่ผใชตองการรหรอเขาถงไดเพอดผลลพธจากการวเคราะหระบบ หลงจากการศกษาความเปนไปได และขอสรปจะถกกลาวถงไวตามรายการของขอเสนอแนะ รายละเอียดของการคนพบ (details of findings) เปนโครงรางของวิธีการและขั้นตอน การดําเนินงานที่เปนอยูของระบบปจจุบัน ซึ่งเปนไปตามวัตถุประสงคและขั้นตอนการ ดําเนินงานของระบบหรือซอฟตแวรที่นําเสนอเพื่อพัฒนา รวมถึง การอภิปรายผล โครงสราง ฐานขอมูล ตนทุนและกําไรที่จะไดรับจากระบบหรือซอฟตแวรที่นําเสนอหรือพัฒนา 10 โซลูชัน (solution หรือไอทีโซลูชัน (IT solution) หมายถึง ขอเสนอแนะ ทางเลือก หรือผลลัพธ ของการออกแบบหรือการ พัฒนาระบบงาน
นําเสนอจะเหมาะสมหรือเขากันไดกับแผนงานระบบสารสนเทศในภาพรวมขององคกร
การสมภาษณเปนเครองมอซงใชกนโดยทวไปและจาเปนจะตองมทกษะพเศษและมความไวตอ
27 ขอเสนอแนะและบทสรุป (recommendations and conclusions) ขอเสนอแนะ จะตองเปนลักษณะเจาะจง เกี่ยวกับระบบหรือซอฟตแวรที่นําเสนอหรือพัฒนา รวมถึง การ มอบหมายงานรายบุคคล ตนทุน ตารางการดําเนินงานโครงการ และวันที่เปาหมาย
ซึ่งจะ นําไปสูการออกแบบและการนําใช การตดสนใจ ณ จดนเปนเรองทสําคัญมากของวงจรการพัฒนาระบบเพราะ มีหลายโครงการอาจจะไมไดดําเนินการตอตั้งแตขั้นตอนนี้ สําหรับการเปลี่ยนแปลงในขอเสนอโครงการจะทํา ในลักษณะของการเขียนเปนลายลักษณอักษร ขึ้นอยูกับความซับซอนและตนทุนของโครงการ และจะมีการ ทวนสอบการเปลี่ยนแปลงกอนที่จะเขามาสูการออกแบบระบบตอไป 3. การวิเคราะห การวเคราะห (analysis) เปนการศกษาในรายละเอยดสาหรบการดาเนนงานตาง ๆ ซงตองมในระบบ หรือซอฟตแวรที่จะพัฒนา รวมถึง ความสัมพันธทั้งหมดภายในระบบและกับภายนอกระบบ คําถามสําคัญคือ จะตองทําอะไรบางเพื่อการแกปญหา มุมมองดานหนึ่งของการวิเคราะหก็คือ การนิยามขอบเขตของระบบหรือ ซอฟแวรที่จะพัฒนาโดยตองคํานึงถึงระบบอื่นที่เกี่ยวของดวย (ถามี) ในระหวางการวิเคราะหขอมูลจะถูก รวบรวมมาจากแหลงขอมูลตาง ๆ กําหนดจุดที่มีการตัดสินใจ และพิจารณารายการธุรกรรมที่อยูในระบบ ปจจุบัน เครื่องมือในการวิเคราะห เชน ผังการไหลของขอมูล (Data Flow Diagram – DFD) ยูเอ็มแอล (UML - Unified Modeling Language) การสัมภาษณ การสังเกตการณในพื้นที่ปฏิบัติงานจริง และแบบสอบถาม เปนตน
ความรูสึก (sensitivity) ตอผูที่ถูกสัมภาษณ อคติในเรื่องของการรวบรวมขอมูลและการแปลผลนั้นเปนปญหา และอปสรรคสาคญของการวเคราะหระบบ การฝกอบรม ประสบการณ และสามัญสํานึก เปนสิ่งที่ตองมีเพื่อใช ในการรวบรวมขอมูลสําหรับการวิเคราะห เมื่อการวิเคราะหไดดําเนินการเสร็จสมบูรณแลว นักวิเคราะหระบบ จะมีความเขาใจอยางชัดเจนวา จะตองดําเนินการใดบาง เพื่อจะไดดําเนินการในขั้นตอนตอไปและเปนการ ตัดสินใจวาจะแกไขปญหาตาง ๆ อยางไร โดยขั้นตอนการออกแบบระบบ จะเปนการเปลี่ยนจากจากมุมมอง เชิงตรรกะไปเปนเชิงกายภาพของวงจรการพัฒนาระบบ ทั้งนี้
อานเพิ่มเติมในเรื่องที่
4.
การ ออกแบบ (design) ระบบหรือซอฟตแวร คําวา การออกแบบ ในที่นี้ ใชอธิบายระบบหรือซอฟตแวรที่จะ พัฒนาขึ้น และกระบวนการที่จะดําเนินการ ซึ่งรวมถึง รายละเอียดเชิงเทคนิคที่ใชในการพัฒนา การเขียน โปรแกรม และการทดสอบ คําถามสําคัญคือ ปญหาควรแกไขอยางไร ขั้นตอนหลัก ๆ ของการออกแบบมีดังนี้
หลังจากผูบริหารไดทบทวนขอเสนอโครงการแลวก็จะกลายเปนขอตกลงอยางเปนทางการ
การวิเคราะหโดยใชยูเอ็มแอล
4.2.2 ถึง 4.2.5
การออกแบบ ขั้นตอนที่ใชความคิดสรางสรรคและทาทายมากที่สุดขั้นตอนหนึ่งของวงจรการพัฒนาระบบคือ
28 1) การออกแบบผลลัพธหรือเอาตพุต (output) ขั้นตอนแรกคือ การกําหนดวาผลลัพธควรเปน อยางไร รูปแบบใด และนําเสนอตัวอยางของผลลัพธ 2) การออกแบบการนําเขาหรืออินพุต (input) เปนการออกแบบขอมูลที่จะนําเขาที่ตรงตาม ความตองการของผลลพธ 3) การออกแบบฐานขอมูล เปนการออกแบบฐานขอมูลที่จะจัดเก็บขอมูลใหตรงตามความ ตองการของผลลัพธ 4) การออกแบบการประมวลผล เปนการออกแบบการประมวลผลการปฏิบัติงานผานการเขียน โปรแกรม รวมถึง รายการโปรแกรมที่จําเปนบรรลุวัตถุประสงคของระบบที่พัฒนา 5) การจัดทําเอกสารโดยละเอียด (detailed system documentation) เปนการจัดทําเอกสาร ที่อธิบายรายละเอียดตาง ๆ ของระบบหรือซอฟตแวรที่พัฒนาขึ้น ประกอบดวย ผังงาน โครงสรางการจัดเก็บขอมูล หนาตารายงาน แผนงานสําหรับการนําใชระบบ ขอมูลเกี่ยวกับ บุคลากร การเงิน ฮารดแวร สิ่งอํานวยความสะดวก การประมาณการตนทุนที่ใกลเคียงกับ ตนทนทจะเกดขนจรง รวมถง การคาดคะเนถงผลกระทบของระบบทจะมตอผใชและองคกร 6) การนําสงผลการออกแบบเพื่อการรับรอง/การอนุมัติ (design summit for approval) เปน การนาเสนอเพอรบการประเมนโดยผบรหารตดสนใจสาหรบการดาเนนการในขนตอนตอไป 7) การทดสอบโปรแกรม เปนการทดสอบรายการโปรแกรมทั้งหมดใหเปนไปตามวัตถุประสงค ของระบบที่พัฒนา ทงน การออกแบบโดยใชยเอมแอล อานเพมเตมในเรองท 4.2.2 ถง 4.2.5 5. การนําใช งานหลัก ๆ ของขั้นตอนการนําใช (implementation) จะเกี่ยวของกับการฝกอบรมผูใช การเตรียม ความพรอมในพนททางานทจะตดตงระบบ และการแปลงไฟลหรอขอมลตาง ๆ เขาสฐานขอมล เมอระบบท พัฒนาขึ้นนั้นมีการเชื่อมโยงอุปกรณคอมพิวเตอรทั้งหมดเขาดวยกัน รวมถึง คอมพิวเตอรที่ติดตั้งอยูใน ระยะไกล ดังนั้น ระบบเครือขายการสื่อสารโทรคมนาคมจะตองไดรับการทดสอบไปพรอม ๆ กับการนําใช ระบบที่พัฒนาขึ้นดวย โดยในชวงการทดสอบครั้งสุดทาย จะตองมีการทดสอบการยอมรับของผูใช แลวก็ จัดการฝกอบรมผูใช สวนการแปลงขอมูลโดยปกติแลวจะดําเนินการในชวงเวลาเดียวกันกับการฝกอบรมผูใช หรอวาหลงจากนนกได การทดสอบระบบเปนการตรวจสอบความพรอมและความถูกตองของระบบ สําหรับการเขาถึง การ ปรับปรุงใหทันสมัยหรืออัปเดต และคนคืนขอมูล จากฐานขอมูล เมื่อโปรแกรมพรอมใชงาน ขอมูลสําหรับการ ทดสอบจะถูกอานเขาไปยังอุปกรณคอมพิวเตอรและประมวลผลกับขอมูลที่เตรียมไวสําหรับการทดสอบ ถาการ
การแปลงขอมูลสวนใหญจะดําเนินการคูขนานไปในระหวางการใชงานระบบใหมกับระบบเกาพรอม
29 ทดสอบประสบความสําเร็จ
ไมสําเร็จ
กัน
หากเกิดขอผิดพลาดในระบบใหมที่พัฒนาขึ้นมาระบบ เกาก็ยังทํางานได แตในบางกรณีการดําเนินการแบบคูขนานก็ไมเหมาะสม สวนกรณีอื่น หลังจากระบบใหมที่ พฒนาขนมาไดรบการพสจนแลววาใชงานได ระบบเกาก็จะถูกเลิกใชงานไป 6. การบํารุงรักษา กิจกรรมการบํารุงรักษา (maintenance) เริ่มตนเมื่อการแปลงขอมูลเขาสูระบบใหมดําเนินการเสร็จ การจดทาเอกสารกถอวาเปนสวนหนงของการบารงรกษา เจาหนาทททาหนาทบารงรกษาระบบจะไดรบคารอง ขอจากผูใชที่มีอํานาจหนาที่เทานั้น และนิยามของการปรับแกที่ตองการ โปรแกรมตนฉบับ และขั้นตอนการ ดําเนินงานสําหรับระบบจะถูกนํามาจากไลบรารีของโปรแกรมที่เขียนไว จากนั้นโปรแกรมที่ไดรับการ เปลี่ยนแปลงตองทําการทดสอบและสงใหผูใชเพื่อรับรอง เมื่อโปรแกรมที่ปรับแกไดรับการรับรอง ก็จะปรับแก เอกสาร และเก็บไวในไลบรารี แลวแจงผูใชใหทราบวา การบํารุงรักษาดําเนินการเสร็จแลวเพื่อทําการปด โครงการ การบํารุงรักษาสามารถแบงออกเปน 3 ประเภท คือ การบํารุงรักษาเพื่อความถูกตอง การบํารุงรักษา เพื่อการปรับแก และการบํารุงรักษาเพื่อความสมบูรณ 1) การบํารุงรักษาเพื่อความถูกตอง (corrective maintenance) หมายถึง การซอมแซมความ
ยงไมไดรบการแกไขใหถกตองซงเกดขนกอนหนานหรอจากการกาหนดสมมตฐานผด 2) การบํารุงรักษาเพื่อการปรับแก (adaptive maintenance) หมายถึง การเปลี่ยนแปลง ฟงกชันการทํางานของโปรแกรม 3) การบํารุงรักษาเพื่อความสมบูรณ (perfective maintenance) หมายถึง การปรับปรุงการ ทํางานใหดียิ่งขึ้น หรือการปรับแกโปรแกรมเพื่อใหตอบสนองตอความจําเปนที่เพิ่มขึ้นของ ผูใช หรอความจาเปนทเปลยนแปลงไป การบํารุงรักษาทั้ง 3 ประเภทนี้ การบํารุงรักษาเพื่อความสมบูรณใชเงินและเวลามากกวาการ บํารุงรักษาเพื่อความถูกตองและการบํารุงรักษาเพื่อการปรับแกรวมกัน การบํารุงรักษาจะครอบคลุมกิจกรรมที่คอนขางเยอะมาก รวมถึง การแกไขโคดโปรแกรมและการ ออกแบบที่ผิดใหถูกตอง การปรับปรุงเอกสารและขอมูลทดสอบใหทันสมัย และการยกระดับการสนับสนุนผูใช อยางไรก็ตาม กิจกรรมหลายอยางถูกจัดหมวดหมูวาเปนการบํารุงรักษาแตเปนการปรับปรุงใหดีขึ้น เนื่องจาก
โปรแกรมหรือซอฟตแวรก็จะสามารถนําไปใชประมวลผลกับขอมูลจริงตอไป หาก
จะดําเนินการวินิจฉัยหาสาเหตุเพื่อระบุและแกไขขอผิดพลาดในโปรแกรม
ๆ
วิธีนี้จะมีตนทุนสูงแตก็จะทําใหเกิดความวางใจไดวา
ลมเหลวของการประมวลผลหรือการดําเนินงาน หรือทําการเปลี่ยนแปลงเนื่องจากมีปญหาที่
เปลี่ยนแปลงในรายละเอียดที่ไดออกแบบไว ซึ่งมีความจําเปนที่จะตามใหทันถึงการเปลี่ยนแปลงความจําเปน
30 การบํารุงรักษา หมายถึง การทําใหบางสิ่งบางอยางกลับมาอยูในสภาพเดิมหรือสภาพที่เปนตนฉบับ และปญหา หลักในการบํารุงรักษาซอฟตแวรคือ การใชแรงงานบุคลากรที่คอนขางเยอะ ซึ่งมักจะเกิดจากความผิดพลาด แตการปรับปรุงใหดีขึ้น หมายถึง การเพิ่ม การปรับแก หรือการพัฒนาโคดโปรแกรมใหม เพื่อจะรองรับการ
ทั้งนี้ วงจรการพัฒนาระบบ (SDLC) เปนแนวทางโดยทั่วไปสําหรับการพัฒนาระบบสารสนเทศ ซอฟตแวร หรือแอปพลิเคชัน ซึ่งนําไปปรับเปนแนวทางการพัฒนาแบบอื่นหรือแนวทางใหม ๆ เชน แนว ทางการออกแบบและพัฒนาซอฟตแวรแบบอไจล เปนตน ซงจะไดกลาวตอไปในเรองท 422 โดยพฒนาขนมา เพื่อแกไขจุดบกพรองและมีประสิทธิภาพดีกวาแนวทางการพัฒนาแบบเดิม อยางไรก็ตาม วงจรการพัฒนา ระบบนี้ก็สามารถนํามาใชกับการพัฒนาซอฟตแวรระบบอัตโนมัติของเครือขาย เพราะใหแนวคิดและหลักการ พนฐานสาหรบการพฒนาระบบในภาพกวางได หลงจากศกษาเนอหาสาระเรองท 4.2.1 แลว โปรดปฏิบัติกิจกรรม 4.2.1 ในแนวการศึกษาหนวยที่ 4 ตอนที่ 4.2 เรื่องที่ 4.2.1
ของผูใชและสภาพแวดลอมของการดําเนินงาน
เรื่องที่ 4.2.2 แนวทางการออกแบบและพัฒนาซอฟตแวรแบบอไจล แนวทางการพฒนาซอฟตแวรตามวงจรการพฒนาระบบทกลาวถงในเรองท 421 เปนแบบนาตก (waterfall) ซึ่งเปนแนวทางการพัฒนาแบบดั้งเดิมมีการดําเนินการเปนลําดับขั้น
แนวทางการพัฒนาซอฟตแวรแบบอไจลสามารถทําใหบริษัทพัฒนาซอฟตแวรประสบความสําเร็จใน การตอบสนองความตองการของลูกคาได เนื่องจากเปนแนวทางพัฒนาซอฟตแวรที่มีความยืดหยุนและรวดเร็ว
ดวยการแบงงานออกเปนสวนยอยเพื่อการสรางและทดสอบ
ซอฟตแวรแบบอไจลยังสงเสริมใหเกิดการทํางานรวมกันเปนทีมขามฝายหรือแผนกงานในองคกรดวย ซึ่งทําให
เรงกระบวนการพัฒนาซอฟตแวรในภาพรวมใหรวดเร็วยิ่งขึ้น
แนวทางการพัฒนาซอฟตแวรตามวงจรการพัฒนาระบบเปนแบบน้ําตกนั้น
31
สําหรับในเรื่องนี้จะกลาวถึง แนวทางการพัฒนาซอฟตแวรแบบอไจล (agile) ซึ่งเปนแนวทางใหมที่เหมาะกับสถาการณในปจจุบัน ที่ สภาพแวดลอมในการดําเนินธุรกิจมีการเปลี่ยนแปลงอยางรวดเร็ว ตองการแนวทางการพัฒนาที่มีความ คลองแคลว ยืดหยุน เนนการพัฒนาและนําซอฟตแวรออกใชงานไดรวดเร็วขึ้น มีประสิทธิภาพ ไดรับความนิยม และใชกันแพรหลายมากขึ้น แนวทางการพัฒนาซอฟตแวรแบบอไจล (agile) นั้น มีการประกาศเปนแถลงการณเพื่อแสดง เจตนารมณของการใชแนวทางแบบอไลจในการพัฒนาซอฟตแวร (Manifesto for Agile Software Development. สืบคนจาก https://agilemanifesto.org/) โดย 1) ใหคุณคากับ คนและการปฏิสัมพันธ มากกวา กระบวนการและเครื่องมือ 2) ใหคุณคากับ ซอฟตแวรที่ใชงานได มากกวา เอกสารที่มีรายละเอียดครบถวนสมบูรณ 3) ใหคณคากบ การรวมมอกบลกคาหรอผใช มากกวา การตอรองตามทระบในสญญา 4) ใหคุณคากับ การตอบสนองตอการเปลี่ยนแปลง มากกวา การทํางานตามแผนงานที่กําหนดไว ทั้งนี้ สิ่งที่กลาวไวทางขวามือของแถลงการณนั้นก็มีคุณคาเชนกัน
คุณคากับสิ่งที่กลาวไวทางซายมือมากกวา
เพียงแตแนวทางนี้จะมุงเนนให
โดยนําแนวคิดการพัฒนาแบบทําซ้ํา (iterative) กับแบบเพิ่ม (incremental) มาใชในการออกแบบและพัฒนา ซอฟตแวร เพื่อทําใหแนใจวา สามารถสงมอบงานที่ทํางานได ไมมีการลมเหลว และเรงความเร็วในการสงมอบ งานได ดวยเทคโนโลยีมีการเปลี่ยนแปลงอยางรวดเร็ว
สามารถปรับตัวใหทันตอการเปลี่ยนแปลง
ซอฟตแวร ทําใหทีมพัฒนาสามารถสงมอบงานไดอยางรวดเร็วและบอยขึ้น นอกจากนั้น แนวทางการพัฒนา
แนวทางการพัฒนาซอฟตแวรแบบอไจลชวยใหองคกร
ไมมจดทใหเพมฟเจอรใหมในระหวางการพฒนา ดงนน การบารงรกษาจงมความยงยาก มาก เชน สงทลกคาตองการ ณ วนแรกทบอกความตองการตอทมพฒนา หากใชแนวทางการพฒนาซอฟตแวร ตามวงจรการพัฒนาระบบเปนแบบน้ําตก ลูกคาจะไดรับมอบงานหลังจากโครงการเสร็จอาจจะใชเวลาเปนป
จะดําเนินการตามลําดับ โดยไมมการยอนกลบ
เปนตน แตดวยแนวทางการพัฒนาซอฟตแวรแบบอไจล ทําใหทีมพัฒนาสามารถสรางฟเจอรไดมากกวาโดยใช
แนวทางการพัฒนาซอฟตแวรแบบอไจลใชกระบวนการพัฒนาแบบเดียวกับ
ความแตกตางระหวางแนวทางการพัฒนาซอฟตแวรแบบอไจลและแนวทางการพัฒนาซอฟตแวรตาม
ชวงแรก สดทายแลวกอาจจะไมเปนไปตามความตองการทางธุรกิจ
2) แนวทางการพัฒนาซอฟตแวรแบบอไจล เกิดขึ้นจากขอเสียของแนวทางการพัฒนาซอฟตแวร ตามวงจรการพัฒนาระบบแบบน้ําตก โดยแนวทางการพัฒนาซอฟตแวรแบบอไจลเปนแนวคิดของการจัดการ
32
ระยะเวลาเดียวกัน อยางไรก็ตาม
แนวทางการพัฒนาซอฟตแวรตามวงจรการพัฒนาระบบเปนแบบน้ําตก คือ รวบรวมความตองการ ออกแบบ พัฒนา ทดสอบ นําใช และบํารุงรักษา เพียงแตแนวทางการพัฒนาซอฟตแวรแบบอไจลสามารถปรับเปลี่ยนได
วงจรการพัฒนาระบบแบบน้ําตก (ภาพที่ 4.8) มีดังนี้ 1) แนวทางการพัฒนาซอฟตแวรตามวงจรการพัฒนาระบบแบบน้ําตก เปนแนวทางแบบดั้งเดิมซึ่ง มีขั้นตอนที่คอนขางเขมงวด นักพัฒนายึดติดกับแผนการออกแบบที่กําหนดไวตั้งแตเริ่มตนโครงการ ผูบริหาร โครงการตองใชเวลามากในการเจรจาสาหรบเปาหมายการสงมอบงาน การจดสรรทรพยากร และฟเจอรตาง ๆ ทําใหใชระยะเวลานานในขั้นตอนของการวางแผนของโครงการ สวนลูกคาจะตองสรุปความตองการตั้งแตกอน เริ่มกระบวนการพัฒนา และใชระยะเวลายาวนานในการพัฒนา โดยผูบริหารโครงการติดตามความกาวหนา ของโครงการจากการสงมอบงานตั้งแตตนจนจบ ขอเสียคือซอฟตแวรมักไมตอบสนองตอการเปลี่ยนแปลงและ กระบวนการใชระยะเวลานานเกินไปในการสงมอบซอฟตแวรที่ใชงานได เมื่อซอฟตแวรพรอมใชงาน ตองใช
และมีความยืดหยุนคลองแคลวกวาในทุกขั้นตอนของกระบวนการ
รอบระยะเวลาในการเผยแพรถึงหกเดือนหรือนานกวานั้น ตามความตองการที่ถูกกําหนดไวอยางเขมงวดใน
ผูบริหารโครงการพัฒนาซอฟตแวร แบบอไจล มีบทบาทสําคัญในการวางแผน ดําเนินการ ติดตามตรวจสอบ ควบคุม และปดโครงการ แนว ทางการพัฒนาซอฟตแวรแบบอไจลจะไมขึ้นอยูกับการกําหนดงานที่จะตองสงมอบ แตขึ้นอยูกับจํานวนชั่วโมง การเลือกฟเจอร การจัดลําดับความสําคัญ และการตอบสนองความตองการของลูกคา โดยแนวทางการพัฒนา ซอฟตแวรแบบอไจล จะแบงงานออกเปนสพรินต (sprints) หรอการทาซา (iterations) ในตอนเรมตนของการ พฒนาแตละสพรนตหรอการทาซาแตละครง ทมพฒนาจะตดสนใจรวมกนวา สงใดทสามารถทาไดเสรจภายใน กรอบเวลาและกําหนดฟเจอรที่จะสงมอบ ในตอนสุดทายของแตละสพรินตหรือการทําซ้ําแตละครั้ง ซอฟตแวร จะถูกนําไปไวในสภาพแวดลอมการใชงานเพื่อใหลูกคาสามารถทดลองใชและใหขอเสนอแนะได ในขณะที่การ พัฒนาสวนอื่นก็ดําเนินตอไป
เพื่อดูแลการเปลี่ยนแปลงและกระบวนการพัฒนาซอฟตแวรที่รวดเร็วขึ้น
ภาพที่4.8ความแตกตางระหวางแนวทางการพัฒนาซอฟตแวรแบบอไจลและแนวทางการพัฒนา
วิธีการพัฒนาซอฟตแวรแบบอไจลและวิธีการพัฒนาซอฟตแวรตามวงจรการพัฒนาระบบแบบน้ําตก นนจะแตกตางกนในเรองของคณภาพและการทดสอบโดยแตละเฟสหรอขนตอนของวงจรการพฒนาระบบจะ
เฟสของพัฒนาหรือสรางซอฟตแวรแตวิธีการพัฒนาซอฟตแวรแบบอไจลการทดสอบจะดําเนินการไปพรอม
พฒนาขนทละนดและดาเนนการทดสอบการใชงานอยางตอเนองผใชกสามารถใชงานซอฟตแวรไดระหวาง การพฒนาและสามารถใชสวนของซอฟตแวรทคอยๆพฒนาเพมขนไดเรอยๆทาใหสามารถทบทวนความ
ตองการซอฟตแวรที่แทจริงของตนเองและปรับแผนไดซึ่งเปนไปในลักษณะของวงจรพีดีซีเอ(PDCA–PlanDo-Check-Act)ทําใหทีมพัฒนาซอฟตแวรสามารถสงมอบผลงานที่มีคุณคามากที่สุดใหกับผูใชไดเพราะการ ดําเนินการในลักษณะนี้จะมุงเนนผลลัพธหรือซอฟตแวรความยืดหยุนในการพัฒนาและตอบสนองตอการ เปลี่ยนแปลงในเรื่องความตองการของตลาดหรือสภาพแวดลอมของธุรกิจได นอกจากนนวธการพฒนาซอฟตแวรแบบอไจลมลกษณะเปนการพฒนาแบบปรบตวได(adaptive) หรือการขับเคลื่อนดวยคุณคา(value-driven)ซงเปนวธทสามารถปรบแผนการทางานโดยมการกาหนดการ สงมอบงานเปนระยะแตจะมความยดหยนในการดาเนนงานหรอสามารถปรบเปลยนกาหนดการสงมอบงาน
33
ซอฟตแวรตามวงจรการพัฒนาระบบเปนแบบน้ําตก ที่มา:
Pawlicka,A.(2021).
ทําตามลําดับเฟสกอนหนาจะตองทําใหเสร็จกอนจึงจะเริ่มเฟสถัดไปเฟสของการทดสอบจึงถูกแยกออกจาก
กับการเขียนโปรแกรมการทดสอบจึงเกิดขึ้นซ้ําทุกครั้งเมื่อเขียนโปรแกรมเสร็จทําใหซอฟตแวรคอยๆ
34 ไดดวย การพฒนาแบบปรบตวไดนมงเนนทการปรบตวไดอยางรวดเรวตอการเปลยนแปลงทเกดขน เชน เมอ โครงการมีการเปลี่ยนแปลง ทีมพัฒนาก็จะตองปรับเปลี่ยนตามดวย เปนตน อยางไรก็ตาม วิธีการพัฒนาแบบนี้ ทําใหทีมพัฒนาไมสามารถจะบอกไดแนนอนวาอะไรจะเกิดขึ้นในอนาคต ทําไดเพียงวางแผนคราว ๆ เชน งาน ใดที่จะตองทําในสัปดาหหนา ภายในเดือนหนาจะไดฟเจอรใดเพิ่มขึ้นบาง หรือภายใน
ใดบาง เปนตน ทั้งนี้ การพัฒนาซอฟตแวรระบบอัตโนมัติของเครือขายก็สามารถนําวิธีการพัฒนาซอฟตแวรแบบอไจล มาใชได เพื่อเพิ่มความคลองแคลว ยืดหยุน การสงมอบที่รวดเร็ว และประสิทธิภาพใหกับการจัดการระบบ เครอขายได หลงจากศกษาเนอหาสาระเรองท 4.2.2 แลว โปรดปฏิบัติกิจกรรม 4.2.2 ในแนวการศึกษาหนวยที่ 4 ตอนที่ 4.2 เรื่องที่ 4.2.2
6 เดือนจะสงมอบฟเจอร
ตงแตเรมตนจนกระทงสนสดวงจรการพฒนาระบบสารสนเทศ ซงไมวาจะเปนการพฒนา ซอฟตแวรโดยทวไป หรอพฒนาซอฟตแวรระบบอตโนมตของเครอขาย หากตองการสรางแบบจาลองเชงวตถก็ สามารถใชยูเอ็มแอลได โดยตัวอยางของการใชยูเอ็มแอลสําหรับงานระบบอัตโนมัติของเครือขายศึกษาเพิ่มเติม
แนวความคิดจากการวิเคราะหและออกแบบกับการเขียนโปรแกรมหรือโคดในลักษณะการโปรแกรมเชิงวัตถุได โดยตรง แตยูเอ็มแอลมีขอกําหนดของรูปแบบในการใชงาน การนําไปใชจึงตองเขียนใหถูกตองตาม วากยสัมพันธ (syntax) ของภาษา
35 เรื่องที่ 4.2.3 ยูเอ็มแอลและการรวบรวมความตองการดวยยูเอ็มแอล เนื้อหาของเรื่องที่ 4.2.3 นี้ ยกเนื้อหามาปรับปรุงและเรียบเรียง จากตอนที่ 2.2 พื้นฐานเกี่ยวกับการ พัฒนาระบบสารสนเทศดวยวิธีเชิงวัตถุ หนวยที่ 2 การรวบรวมความตองการและการวิเคราะหระบบ สารสนเทศ เขียนโดย ผูชวยศาสตราจารย ดร.ปราโมทย ลือนาม ในชุดวิชา 99708 ระเบียบวิธีวิจัยและ เครองมือในการพัฒนาระบบดานเทคโนโลยีสารสนเทศและการสื่อสาร ฉบับพิมพเมื่อ พ.ศ. 2562 1. ยูเอ็มแอล ยูเอ็มแอล (UML -Unified Modeling Language) เปนภาษาที่ใชระบบสัญกรณ (notation system) เพื่อบรรยายลักษณะของแบบจําลอง (model) ของระบบ ยูเอ็มแอลมักจะถูกนํามาใชในการสรางแบบจําลอง เชงวตถ (object modeling) แบบจาลองนจะใชสาหรบกาหนดขอบเขตของปญหา (problem domain) ซง อยูในขั้นตอนของการรวบรวมความตองการระบบเพื่อนําไปใชในขั้นตอนของการวิเคราะหระบบ และใช สําหรับอธิบายแนวความคิดของกระบวนการทํางานที่มีในแตละขั้นตอนของการพัฒนาระบบสารสนเทศ ยูเอ็มแอล พัฒนาขึ้นโดยมีวัตถุประสงคเพื่อใชสําหรับการวิเคราะห ออกแบบ ระบุรายละเอียด จําลอง ทําใหเห็นภาพ (visualization) และสรางเอกสารของแบบจําลองระบบ แบบจําลองเหลานี้สามารถนําไปใช
ไดในหนวยที่ 6 ยูเอ็มแอลชวยทําใหการพัฒนาระบบสารสนเทศทําไดสะดวกรวดเร็ว เนื่องจากสามารถเชื่อมโยง
อีกทั้ง ยังมีความสามารถในการปรับขนาด (scalability) ใหเหมาะสมกับ การใชงาน สามารถประยุกตใชไดกับระบบงานขนาดเล็กไปจนถึงระบบงานขนาดใหญที่ซับซอน และมีความ เหมาะสมอยางยิ่งกับการพัฒนาระบบที่ใชวิธีแบบวนซ้ําและทําเพิ่ม (incremental and iterative approach) หรือแนวทางการพัฒนาซอฟตแวรแบบอไจล โดยการปรับปรุงแผนภาพอยางตอเนื่อง ทั้งการเพิ่มเติม รายละเอยดและการปรบแผนภาพให สอดคลองกบสงทเปลยนแปลงในระหวางกระบวนการออกแบบแตละ รอบ ทั้งนี้ ควรพิจารณาความสัมพันธระหวางแนวคิดของยูเอ็มแอลกับวิธีการพัฒนาระบบ (ภาพที่ 4.9) และควรทําความเขาใจวา ยูเอ็มแอลไมไดอยูในสวนของกระบวนการ (process) ของการพัฒนาระบบ ไมได
ประโยชนได
บอกวามกระบวนการใดบางทจะตองทาเพอใหพฒนาระบบสาเรจหรอควรจะตองทาอยางไรการพฒนาระบบ จึงจะมีประสิทธิภาพและยูเอ็มแอลไมใชเครื่องมือพัฒนาระบบทใชสาหรบการสรางหรอบรหารโครงการ พัฒนาระบบหากแตสามารถนายเอมแอลไปใชในสวนของการสรางแผนภาพซงเปนองคประกอบทสาคญสวน
ภาพท4.9ความสมพนธระหวางแนวคดของยเอมแอลกบวธการพฒนาระบบ
การใชงานยูเอ็มแอลไมจําเปนตองใชทุกแผนภาพในการสรางแบบจําลองของระบบในแตละขั้นตอน ของการพัฒนาระบบสามารถเลือกใชบางแผนภาพใหเหมาะสมกับงานแตละสวนเชนการเก็บรวบรวมความ ตองการใชแผนภาพยูสเคสการวิเคราะหระบบใชแผนภาพคลาสรวมกับแผนภาพลําดับการออกแบบระบบใช แผนภาพออบเจ็กตรวมกับแผนภาพลําดับเปนตน แผนภาพยูเอ็มแอลมีทั้งหมด13ประเภท(ภาพที่4.10)สามารถจําแนกไดเปน2กลุมใหญคือ แผนภาพโครงสราง(structurediagrams)และแผนภาพพฤตกรรม(behaviordiagrams)
แผนภาพโครงสรางแสดงใหเห็นโครงสรางของสวนตางๆทประกอบขนมาเปนระบบแผนภาพ พฤติกรรมแสดงวิธีการทํางานและการรวมกันทํางานของสวนประกอบยอยของระบบและวิธีการตอบสนองตอ คํารองขอ(request)ทเกดขนกบระบบในแตละชวงเวลาขอแตกตางระหวางแผนภาพทั้งสองกลุมคือ แผนภาพโครงสรางมีลักษณะเปนสแตติกโมเดล(staticmodel)หรือแบบจําลองสถิตซึ่งแสดงโครงสราง คุณลักษณะและความสัมพันธของสิ่งที่ปรากฏบนแผนภาพโดยจะไมเปลี่ยนแปลงตามเวลาสวนแผนภาพ
36
หนึ่งของวิธีการพัฒนาระบบ
ที่มา:
วิภาเจริญภัณฑารักษและปราโมทยลือนาม.(2562).
1)แผนภาพคลาส(classdiagrams)แสดงคลาสประเภทของคลาสสวนตอประสาน(interface) และความสัมพันธระหวางคลาสของระบบที่สนใจแผนภาพคลาสจะสรางขึ้นในชวงการวิเคราะหและออกแบบ
37 พฤติกรรมมีลักษณะเปนไดนามิกโมเดล(dynamicmodel)หรือแบบจําลองพลวัตซึ่งแสดงสถานะการ เปลี่ยนแปลงของสถานะการสงผานเมสเซจ(message)และการดําเนินการกับเหตุการณที่เกิดขึ้นโดยจะ เปลี่ยนแปลงไปตามเวลา ภาพที่4.10โครงสรางและประเภทของแผนภาพยูเอ็มแอล ที่มา:วิภาเจริญภัณฑารักษและปราโมทยลือนาม.(2562). แผนภาพโครงสราง(structurediagrams)ประกอบดวยแผนภาพ6ประเภทดังนี้
ระบบ
2) แผนภาพออบเจกต (object diagrams)
สัญลักษณของแพ็กเกจมีลักษณะเหมือนกับโฟลเดอรบนระบบปฏิบัติการวินโดวส
ภายในของคลาสหรือสวนประกอบยอย รวมทั้งอธิบายถึงความสัมพันธภายในคลาสตามบริบทที่กําหนด
5) แผนภาพคอมโพเนนต (component diagrams) แสดงสวนประกอบที่สําคัญภายในระบบเปน
38
หรือแผนภาพวัตถุ แสดงอินสแทนซ (instance) ใน ลักษณะของ “วัตถุ” หรือออบเจกต (ซึ่งรวมทั้งคุณสมบัติและพฤติกรรมของออบเจกต) สรางขึ้นจากคลาสตาง ๆ ที่มีอยูในแผนภาพคลาสของระบบ แผนภาพออบเจ็กตจะสรางขึ้นในชวงการวิเคราะหและออกแบบระบบ 3) แผนภาพแพ็กเกจ (package diagrams) เปนการจัดรวมกลุมของคอมโพเนนต (components) ที่เปนสวนประกอบยอยภายในระบบที่มีสวนสัมพันธเกี่ยวของกันไวในหมวดหมูเดียวกัน ประโยชนคือ ชวยให สะดวกตอการทําความเขาใจ สวนประกอบยอยในแพ็กเกจอาจเปน คลาส ออบเจกต ยูสเคส คอมโพเนนต หรือแพ็กเกจยอยในแพ็กเกจ เพื่อแสดงใหเห็นความสัมพันธระหวางแพ็กเกจและลําดับชั้นของแพ็กเกจ
แผนภาพแพ็กเกจจะสรางขึ้น ในชวงการออกแบบระบบ 4) แผนภาพโครงสรางของสวนประสม (composite structure diagrams) แสดงองคประกอบ
แผนภาพโครงสรางของสวนประสมจะสรางขนในชวงการออกแบบระบบ
และใช ในการจดกลมของสวนประกอบยอยของระบบแยกตามหนาทการทางาน เชน แสดงสวนประกอบของระบบวา ประกอบดวยแฟมขอมูลใดบางที่ตองใชในขณะที่โปรแกรมทํางาน (อาจเปนแฟมขอมูลประเภท .exe, .txt หรือ แฟมขอมูลไลบรารีตาง ๆ เชน .lib, .dll เปนตน) หรือแบงสวนประกอบยอยของระบบเปนโมดูลสําหรับการ รับ-สงขอมูล การขาย การผลิต และการออกรายงาน เปนตน แผนภาพคอมโพเนนตจะสรางขึ้นในชวงการ ออกแบบระบบ 6) แผนภาพดีพลอยเมนต (deployment diagrams) แสดงวิธีในการนําใชระบบ โดยการ เคลื่อนยายติดตั้งสวนประกอบตาง ๆ ของระบบ ทั้งฮารดแวร ซอฟตแวร ระบบฐานขอมูล หรือเครือขาย ให พรอมสําหรับการใชงานจริง แผนภาพดีพลอยเมนตจะสรางขึ้นในชวงการออกแบบระบบ เพื่อนําไปใชในชวง การปรบเขาสการใชงานจรง แผนภาพพฤติกรรม (behavior diagrams) ประกอบดวย 4 แผนภาพ ดังนี้ 1) แผนภาพยูสเคส (use case diagrams) แสดงการปฏิสัมพันธ (interact) ใน 2 รูปแบบคือ ระหวาง (1) ระบบกับผูใช หรือ (2) ระบบกับระบบภายนอก (external systems) โดยแผนภาพยูสเคสจะ แสดงวาใครบางที่เปนผูใชระบบ และผูใชเหลานั้นมีการติดตอกับระบบในลักษณะใด แผนภาพยูสเคสมีจุดเดน คือ เปนแผนภาพที่สามารถทําความเขาใจไดงาย นักวิเคราะหระบบมักจะใชแผนภาพยูสเคสในชวงการ รวบรวมความตองการของระบบ (system requirement) ซึ่งจะชวยใหนักวิเคราะหสามารถกําหนดขอบเขต ของระบบไดอยางถูกตองครบถวน
ลักษณะของโมดูล (module) แสดงใหเห็นถึงขอกําหนดและวิธีการในการติดตอประสานกับโมดูลนั้น
(state machine diagrams)
รวบรวมความตองการและการวิเคราะหระบบ
4) แผนภาพปฏิสัมพันธ
จึงนําแผนภาพลําดับมาใชในเฉพาะเสนทางที่เลือกบางเสนทางที่
แผนภาพลําดับจะสรางขึ้นในชวงการวิเคราะหและออกแบบระบบ
ในชวงการรวบรวมความตองการและการวิเคราะหระบบ
39 2) แผนภาพกิจกรรม
diagrams) แสดงใหเห็นกลุมของการกระทําหรือการปฏิบัติงานที่ เรียกวา แอ็กชัน (action) ซึ่งประกอบขึ้นตามลําดับขั้นรวมกันเปนกิจกรรม (activity) ของงาน แผนภาพ กิจกรรมแสดงใหเห็นถึงขั้นตอนการปฏิบัติงาน ทางเลือก และเงื่อนไขของทางเลือกที่มีในแตละกิจกรรม แผนภาพกิจกรรมจะสรางขึ้นในชวงการรวบรวมความตองการและการวิเคราะหระบบ 3) แผนภาพสเทจแมชีน
แสดงสถานะของระบบตามชวงชีวิต รวมทั้ง แสดงเหตุการณใด ๆ ที่สามารถเปลี่ยนสถานะของระบบเพื่อการเสริมสรางความเขาใจโดยเฉพาะในการอธิบาย การทํางานที่ซับซอน แผนภาพนี้สามารถใชในการอธิบายพฤติกรรมระบบทั้งหมด หนวยยอยของระบบ (subsystem) หรือแมแตเพียงวัตถุเดียว (single object) ในระบบ แผนภาพสเทจแมชีนจะสรางขึ้นในชวงการ
(activity
(interaction diagrams) แบงออกเปน 4 แบบ ดังนี้ - แผนภาพลําดับ (sequence
แสดงการปฏิสัมพันธระหวางออบเจกตตามลําดับของ เหตุการณที่เกิดขึ้น แผนภาพลําดับมีลักษณะที่งายตอการทําความเขาใจ แสดงใหเห็นภาพการทํางานของ ระบบ และใชเสริมกับแผนภาพกิจกรรม เนื่องจากแผนภาพกิจกรรมอาจจะมีเงื่อนไขจํานวนมาก ทําใหมี ทางเลือกในการทํางานไดหลายเสนทาง
ตองการอธิบายขยายความ
- แผนภาพการสื่อสาร (communication diagrams) แสดงวิธีที่ออบเจกตใชในการปฏิสัมพันธ
แผนภาพการสื่อสารจะสรางขึ้น
diagrams)
รวมทั้งการเชื่อมโยง
(connections) ที่ใชในการสนับสนุนการปฏิสัมพันธนั้น
- แผนภาพเวลา (timing diagrams) แสดงการเปลี่ยนแปลงสถานะ (state) เงื่อนไข (condition) หรือบทบาท (role) ของออบเจกตตามลําดับของเวลา โดยปกติสถานะที่เปลี่ยนแปลงไปนั้นมีสาเหตุ เนื่องมาจากการตอบสนองตอเหตุการณใด ๆ ที่เกิดขึ้น
(interaction overview diagrams) ใชในการรวบรวม แผนภาพลาดบ แผนภาพการสอสาร และแผนภาพเวลา เขาดวยกน เพอแสดงการปฏสมพนธทสาคญทเกดขน ในระบบ แผนภาพภาพรวมการปฏิสัมพันธจะสรางขึ้นในชวงการวิเคราะหระบบ ในทางปฏิบัติ โดยทั่วไปจะใชทั้งแผนภาพโครงสรางและแผนภาพพฤติกรรมรวมกันในการบรรยาย ลักษณะของระบบในแงมุมตาง ๆ เชน อาจจะใชแผนภาพคลาสเพื่ออธิบายโครงสรางของระบบรวมกับการใช แผนภาพสเทจแมชีนเพื่อแสดงพฤติกรรมของแตละวัตถุในการตอบสนองตอเหตุการณลักษณะตาง ๆ ที่อาจ เกิดขึ้นภายในระบบ
แผนภาพเวลาจะสรางขึ้นในชวงการวิเคราะหระบบ - แผนภาพภาพรวมการปฏิสัมพันธ
(1) สรางความเขาใจความตองการในบริบทของธุรกิจ (business context)
(2) แสดงรายละเอียดของความตองการของระบบในรูปของเอกสาร (requirements specification)
กวางจนเกินกวาจะทําไดสําเร็จตามเวลาและงบประมาณที่กําหนด หรือแคบไปจนไมสามารถตอบสนองความ
(system requirement modeling) เปนสวนที่ พัฒนาตอเนื่องจากความตองการเชิงธุรกิจ เพื่อใหสามารถกําหนดไดวาระบบที่จะพัฒนาสามารถแกไขปญหาที่ ธุรกิจที่กําลังเผชิญอยูไดอยางไร แบบจําลองความตองการเชิงระบบสรางจากมุมมองและแนวความคิดของ ผูพัฒนาระบบ (developer perspective) โดยจะใหรายละเอียดทางเทคนิคที่ลงลึกมากขึ้นกวาแบบจําลอง ความตองการเชิงธุรกิจ
40 2.
วัตถุประสงคของการรวบรวมความตองการ
การรวบรวมความตองการดวยยูเอ็มแอล
มีดังนี้
เทคนิคของระบบที่ตองการ
และสรางความเขาใจเชิง
สามารถระบุผูใชงานทั้งหมดที่เกี่ยวของกับระบบ เพื่อนํามาใชในกระบวนการวิเคราะหและออกแบบ
กําหนดขอบเขตของระบบ (system boundaries) เพื่อทําใหขอบเขตของระบบที่จะพัฒนาไม
ตองการของธุรกิจได สงทจะตองดาเนนการในชวงนคอ
ซงอาจแบงยอยออกเปน 2 สวน ดังนี้ 1) การสรางแบบจําลองความตองการเชิงธุรกิจ (business
modeling) เปนการสราง แบบจําลองความตองการตามมุมมองของธุรกิจ
เพื่อใหเขาใจในการวิธีดําเนินงาน ของระบบที่ใชในปจจุบัน และสภาพปญหาของธุรกิจที่กําลังประสบอยู
ระบบ
และมั่นใจวาเกิดความเขาใจ ตรงกับ ความตองการของธุรกิจ เจาของระบบ และผูใชงานระบบ การเก็บรวมรวบความตองการและวิเคราะหขอมูลในสวนนี้ เปนหนาที่ของนักวิเคราะหธุรกิจดานไอที (IT Business Analyst - IT BA) แหลงขอมูลจะไดมาจากผูบริหารขององคกร ทั้งระดับอาวุโสในองคกร ผูบริหารในระดับหนวยงาน และผูบริหารเทคโนโลยีสารสนเทศ รวมทั้งมุมมองทางธุรกิจจากผูใชภายใน หนวยงานที่เปนผูปฏิบัติงานในหนาที่ที่มีความเกี่ยวของกับระบบ 2) การสรางแบบจําลองความตองการเชิงระบบ
การเก็บรวมรวบความตองการและวิเคราะหขอมูลในสวนนี้จะเปนหนาที่ของ นักวิเคราะหระบบ (System Analyst - SA)
(3)
การสรางแบบจาลองความตองการ
requirement
(business perspective)
ตองดําเนินการกอนจะทําการพัฒนา
เพื่อใหทราบในเหตุผลของความตองการที่จะมีระบบไวใชงานอยางชัดเจน
ประกอบดวย 4 งานหลัก คือ (1) การระบุ
(2) การระบุยูสเคสธุรกิจ (3) การเขียนยูสเคสธุรกิจ และ (4) การสรางอภิธานศัพท แตหาก
ตองการขยายรายละเอียดอาจเสริมความเขาใจดวยการสรางแผนภาพกิจกรรมและแผนภาพการสื่อสาร
3) การบรรยายยูสเคสธุรกิจ (business use case narrative) เปนการแสดงรายละเอียดดวย คําอธิบายในเชิงการพรรณนาเพื่อใหเกิดความเขาใจในหนาที่การทํางาน
และเปนขอมูลพื้นฐานที่จะทําใหทราบวาระบบใหมควรจะตองมีวิธีดําเนินการอยางไรใหดี
41
แอ็กเทอรธุรกิจ
1) การระบุแอ็กเทอรธุรกิจ แอ็กเทอร (actor) หมายถึง คน (people) องคกร (organizations) ระบบ (systems) หรืออุปกรณ (devices) ที่ใชระบบ หรือมีปฏิสัมพันธแลกเปลี่ยนขอมูลสารสนเทศกับระบบ ดังนั้น อุปกรณหรือระบบภายนอกจึงถือวาเปนแอ็กเทอรดวย โดยระบุแอ็กเทอรหลัก (primary actors) และแอ็กเทอรรอง (secondary actors) ของระบบ แอ็กเทอรหลัก คือ ผูขอใชบริการจากระบบ ตองการใหระบบชวยทํางานเพื่อใหสําเร็จตามเปาหมาย เปนผูที่ติดตอกับระบบ และเปนผูทํากระบวนการนั้นในระบบ (acts on the system) และสวนแอ็กเทอรรอง คือ ผูที่ระบบตองการขอความชวยเหลือเพื่อใหเปาหมายของแอ็กเทอรหลักสําเร็จ เปนผูใหขอมูลหรือใหบริการ กับระบบ (is acted on/used/invoked by the system) ทั้งนี้ แอ็กเทอรหลักของระบบจะตองมีเสมอ ในขณะที่แอ็กเทอรรองอาจจะมีหรือไมมีก็ได ถามีแสดง วาระบบจําเปนตองมีแอ็กเทอรรองเพื่อชวยสนับสนุนการทํางานของยูสเคสนั้น ๆ เนื่องจากแอ็กเทอรหลักไม สามารถทํายูสเคสนั้นสําเร็จไดถาไมมีแอ็กเทอรรอง 2) การระบุยูสเคสธุรกิจ แตละยสเคสคอ องคประกอบยอยของระบบ เมอนาองคประกอบทงหมดมา รวมกันก็จะสามารถมองเห็นภาพการทํางานของระบบในเชิงธุรกิจทั้งหมด ในขั้นตอนนี้มักจะมองเห็นแคยูสเคส ที่มีการสื่อสารกันระหวางแอ็กเทอรที่เปน
รวบรวมความตองการของระบบ เพื่อแสดงถึงการใชงานระบบที่มีรายละเอียดมากขึ้น มีการแสดงถึงเงื่อนไข ทางเลือก
การใชวิธีเชิงวัตถุสรางแบบจําลองความตองการเชิงธุรกิจ
“คน" ยูสเคสที่เกิดขึ้นทั้งหมดจะเพิ่มเติมและปรับปรุงในขั้นตอนการ
และมีรูปแบบเปนโครงสรางมากขึ้น
ของระบบปจจุบัน
ขึ้น และสามารถแกไขปญหาที่กําลังเผชิญอยูได 4) การสรางอภิธานศัพท (glossary) เปนทางเลือกใหมที่มาแทนการสรางพจนานุกรมขอมูล (data dictionary) ที่ใชกันในวิธีแบบดั้งเดิม ซึ่งเปนวิธีการอธิบายความหมายของคําเหมือนกัน แตพจนานุกรมขอมูล จะบอกเฉพาะขอมลเทานน ไมครอบคลมการใหคาอธบายกระบวนการ ซงวธเชงวตถทงขอมูลและกระบวนการ จะตองถูกนํามาอธิบายความหมาย
แสดงใหเห็นวิธีปฏิบัติงานและปญหา
42 การใชวิธีเชิงวัตถุสรางแบบจําลองความตองการเชิงระบบ ประกอบดวย 4 งานหลัก คือ (1) การระบุ แอกเตอรระบบ (2) การระบุยูสเคสระบบ (3) การเขียนแผนภาพยูสเคสระบบ และ (4) การบรรยายยูสเคส ระบบ 1) การระบุแอกเตอรระบบ เปนการระบุแอกเตอรระบบ (system actors) ของระบบงานใหมที่จะ พัฒนา ไดแก คนหรือหนวยงานที่เปนผูใชงานหรือไดรับประโยชนจากการทํางานของระบบ อุปกรณที่ระบบ ตองใชงาน และการติดตอปฏิสัมพันธกับระบบภายนอก และเขียนคําอธิบายอยางยอเพื่อใหเขาใจถึงขอมูล พื้นฐานของแอกเตอร วิธีการ และเงื่อนไขของการปฏิสัมพันธกับระบบ เชน แอ็กเตอร: ลูกคา, คําอธิบาย: บคคลใด ๆ ทใชเวบเบราวเซอรในการเขาถงระบบผานเครอขายอนเทอรเนต เปนตน 2) การระบุยูสเคสระบบ แตละยูสเคสคืองานยอยภายในระบบใหม เมื่อนํางานยอยทั้งหมดมารวมกัน และกําหนดความสัมพันธระหวางงานยอย จะชวยใหมองเห็นภาพของระบบที่กําลังพัฒนาไดทั้งหมด โดยระบุ รหัสยูสเคส ชื่อยูสเคสอยางยอ และคําอธิบายยูสเคส เชน รหัสยูสเคส: SR01, ชื่อยูสเคส: คนดูประเภทหอง (Browse Room Types), คําอธิบายยูสเคส: ลูกคาใชเบราเซอรเพื่อดูประเภทตาง ๆ ของหองที่มีใหบริการ เชน หองสวีท หองเดี่ยว หองคู เปนตน 3) การเขียนแผนภาพยูสเคสระบบ เพื่อแสดงใหทราบวา ระบบทํางานใดหรือมีหนาที่ใดบาง และ นําไปใชเปนพื้นฐานเพื่อการสรางแผนภาพแบบอื่นในขั้นตอนตอไป การเขียนแผนภาพยูสเคส (ภาพที่ 4.11) ทําไดโดยระบุชื่อระบบ วาดขอบเขตของระบบ วาดแอ็กเทอรในแผนภาพ วาดยูสเคสในแผนภาพ และกําหนด ความสัมพันธระหวางยูสเคสแบบตาง ๆ ไดแก (1) แบบสนธิการ (association) เสนทึบไมมีลูกศร (2) แบบการ พึ่งพา (dependency) เสนประมีลูกศร ทั้งการรวม (inclusion) เพื่อเรียกใชการทํางาน ที่ทําเองไมได หัว ลูกศรชี้ไปที่ยูสเคสหลัก และการขยาย (extension) เพื่อขยาย/เพิ่มเติมการทํางาน หางลูกศรชี้ไปที่ยูสเคสหลัก หรอ (3) แบบสามญการ (generalization) เสนทบมลกศร
ที่มา:วิภาเจริญภัณฑารักษและปราโมทยลือนาม.(2562).
4)การบรรยายยูสเคสระบบใชประกอบกับแผนภาพยูสเคสเนื่องจากอาจมีรายละเอียดจํานวนมาก ที่ไมสามารถใสลงไวในแผนภาพไดการใชขอความบรรยายจึงเปนสิ่งจําเปนรูปแบบการบรรยายยังไมมี มาตรฐานทแนนอนหวขอทจาเปนตองมในการบรรยายยสเคสประกอบดวยรหสชอขนตอนเงอนไขกอน เงื่อนไขหลังและหัวขออื่นๆ(ถามี)เชนรหัส:SR01,ชื่อ:BrowseRoomTypes,ขนตอน:1.ลูกคาเลือก ประเภทของหองที่ตองการไดแกStandard/Superior/SuperiorCorner/ExecutivePremier/Junior Suite/OneBedSuite/SiamSuiteเปนตน2.IncludeยูสเคสSR02,เงื่อนไขกอน:ไมมี,เงื่อนไขหลัง:ไม มี,รเลชนชป:includesSR02เปนตน
43 ภาพที่4.11การเขียนแผนภาพยูสเคส
หลังจากศึกษาเนื้อหาสาระเรื่องที่4.2.3แลวโปรดปฏิบัติกิจกรรม4.2.3 ในแนวการศึกษาหนวยที่4ตอนที่4.2เรื่องที่4.2.3
2) กําหนดรูปแบบของความสัมพันธประเภทตาง
3) กําหนดคุณลักษณะ (attributes)
(association)
4) นํายูสเคสระบบทั้งหมดที่ไดมาจากการสรางแบบจําลองความตองการเชิงระบบ
44 เรื่องที่ 4.2.4 การวิเคราะหและการออกแบบซอฟตแวรดวยยูเอ็มแอล เนื้อหาของเรื่องที่ 4.2.5 นี้ ยกเนื้อหามาปรับปรุงและเรียบเรียง จากตอนที่ 2.4 การวิเคราะหดวยวิธี เชิงวัตถุ หนวยที่ 2 การรวบรวมความตองการและการวิเคราะหระบบสารสนเทศ และตอนที่ 3.3 การออกแบบ ระบบสารสนเทศเชิงวัตถุ หนวยที่ 3 การออกแบบระบบสารสนเทศ เขียนโดย ผูชวยศาสตราจารย ดร. ปราโมทย ลือนาม ในชุดวิชา 99708 ระเบียบวิธีวิจัยและเครื่องมือในการพัฒนาระบบดานเทคโนโลยี สารสนเทศและการสื่อสาร ฉบับพิมพเมื่อ พ.ศ. 2562 1. การวิเคราะหซอฟตแวรดวยยูเอ็มแอล ขั้นตอนของการวิเคราะหเชิงวัตถุ เปนงานที่ตองทําวนซ้ําทุกขั้นตอน จนกวาจะไดผลสําเร็จตาม วัตถุประสงคที่วางไว ประกอบดวย 1) นําแบบจําลองและขอมูลตาง ๆ ที่ไดมาจากขั้นตอนการรวบรวมความตองการในเชิงธุรกิจและเชิง ระบบ มาวเคราะหแบบสถต (static analysis) โดยเรมจากการคนหาคลาสตาง ๆ จากความตองการเชงระบบ เพื่อนํามากําหนดเปนคลาสในแผนภาพตาง ๆ
ๆ ระหวางคลาส เชน สนธิการ
การ
และการสบทอด
เปนตน
พงพง (dependency) องคประกอบ (composition)
(inheritance)
ที่เหมาะสมใหกับคลาส
มาตรวจสอบวา
หากไมได ตองปรับคลาส ความสัมพันธระหวางคลาส และคุณลักษณะทั้งหมดอยางละเอียด (fine-tune) เพื่อใหสามารถรองรับความ ตองการทั้งหมดไดอยางครบถวนสมบูรณ 5) นําแบบจําลองและขอมูลตางๆ ที่ไดมาจากขั้นตอนการรวบรวมความตองการเชิงระบบและการ วิเคราะหแบบสถิตมาทําการวิเคราะหแบบพลวัต (dynamic analysis) ผลจากการวิเคราะหจะนําไปใชในการ ปรบปรงแกไขแผนภาพคลาสใหมความสมบรณมากขน 6) ปรบปรงอภธานศพทตามทจาเปน
กระบวนการที่ระบุในยูสเคสสามารถรองรับไดจากคลาสที่มีอยูขณะนี้หรือไม
45 การวิเคราะหแบบสถิตและพลวัต การวิเคราะหแบบสถิต คือ การนําเอาความตองการในเชิงธุรกิจและเชิงระบบมาพิจารณาตอ และ จัดทําเปนแบบจําลองเพื่อใหไดสิ่งที่สามารถแสดงใหเห็นโครงสราง คุณลักษณะ และความสัมพันธของสวนตาง ๆ ที่ประกอบขึ้นเปนระบบ นิยมใชแผนภาพที่อยูในกลุมโครงสราง คือ แผนภาพคลาส และแผนภาพออบเจกต การวิเคราะหแบบพลวัต คือ การนําเอาความตองการในเชิงธุรกิจและเชิงระบบมาพิจารณา เชนเดียวกับการวิเคราะหแบบสถิต แตแบบจําลองที่จัดทําจะมีวัตถุประสงคเพื่อแสดงใหเห็นวิธีการทํางาน และ การรวมกันทํางานของหนวยยอยตาง ๆ ที่ประกอบขึ้นเปนระบบ และแสดงวิธีการตอบสนองตอเหตุการณที่ อาจเกิดขึ้นกับระบบในลักษณะตาง ๆ ในแตละชวงเวลา นิยมใชแผนภาพที่อยูในกลุมพฤติกรรม เชน แผนภาพ การสื่อสาร แผนภาพลําดับ แผนภาพกิจกรรม แผนภาพสเตจแมชีน เปนตน ผลจากการวิเคราะหแบบพลวัต จะชวยเพิ่มความเขาใจในเชิงพฤติกรรมของระบบที่ถูกตองมากขึ้น ซึ่ง อาจจะตองนาผลเหลานไปใชปรบปรงแกไขแผนภาพคลาสอกครงเพอใหมความสมบรณถกตอง การปรบปรง คลาสนี้หมายรวมถึง การเพิ่ม ลบ แกไข คลาส ความสัมพันธ คุณลักษณะ และวิธีการดําเนินงานของคลาส ความแตกตางระหวางการวิเคราะหทั้งสองแบบ คือ การวิเคราะหแบบสถิตใชการมองระบบและ สวนประกอบแบบสแตติกวิว (static view) คือสิ่งตางๆ จะไมเปลี่ยนแปลงไมวาจะเวลาใด สวนการวิเคราะห แบบพลวัตใชการมองการมองระบบและสวนประกอบแบบไดนามิกวิว (dynamic view) คือ สิ่งตาง ๆ สามารถเปลี่ยนแปลงไดตลอดเวลา แผนภาพคลาสจากการวิเคราะหแบบสถิต คลาส (class) คอ สงทใชในการนยามออบเจกต คลาสจะเปนแผนแบบ (template) ทใชในการสราง ออบเจกต และการที่ออบเจกตตองถูกสรางขึ้นมาจากคลาส จึงถือวาออบเจกตเปนกรณีตัวอยาง (instance) ของคลาส คลาสเปรียบเสมือนเปนสิ่งที่ใชในการจัดกลุมของออบเจกตที่มีลักษณะของ โครงสราง (structure) คุณลักษณะ (attribute) และพฤติกรรม (behavior) เหมือนกัน ออบเจกตถูกสรางจากคลาสใด จะตองมี โครงสรางและพฤตกรรมรปแบบเดยวกบคลาสทเปนแผนแบบนน ออบเจกต (object) ความหมายโดยทั่วไปคือ สิ่งที่มีตัวตน (tangible) สามารถสัมผัส (touchable) และมองเห็นได (visible) สําหรับความหมายในทางเทคโนโลยีเชิงวัตถุ หมายถึง สิ่ง (thing) ที่ใชแสดงวัตถุใน โลกความจริง และเปนขอแตกตางระหวางคลาสกับออบเจกต คือ คลาสจะเปนนามธรรม (abstract) หมายถึง จับตองไมไดและทํางานไมได ในขณะที่ออบเจกตเปนรูปธรรม (concrete) คือเปนสิ่งที่มีตัวตนและสามารถ ทํางานได คุณสมบัติพื้นฐานของออบเจกต คือ (1) สามารถระบุอัตลักษณได (identifiable) (2) มีสภาพ (state) และ (3) มีพฤติกรรม (behavior)
1) ระบพจน (term) ทเปนคานาม
ออกแบบจะใชแผนภาพคลาสมาแสดงรายละเอียดของการออกแบบ
(analysis classes) ในขั้นตอนการ
สิ่งที่มักจะแสดงในแผนภาพมีแคชื่อของคลาสและความสัมพันธระหวางคลาส สวน
จะนําไปเพิ่มเติมภายหลังในขั้นตอนการวิเคราะหแบบพลวัตและการออกแบบระบบตอไป
46 วิธีการคนหาคลาส คือ
พิจารณาวา ในระบบงานควรจะประกอบดวยคลาสอะไรบาง
พฤติกรรมอยางไร
นําการบรรยายยูสเคสระบบจากการรวบรวมความตองการเชิงระบบมา
และในแตละคลาสควรจะมีคุณลักษณะหรือ
มีวิธีการและขอกําหนดดังนี้
(noun) หรอนามวล (noun phase) จากคาบรรยายยสเคสระบบ
นําพจนที่ไดมาจัดวางบนแผนภาพ จัดกลุมของพจนตามความสัมพันธเกี่ยวของ โดยพิจารณา พจนที่มีความหมายเดียวกัน มีความหมายใกลเคียงกัน หรือมีความหมายในเรื่องเดียวกัน 3) ลบพจนที่ไมเกี่ยวของ ลบพจนที่เปนแอ็กเทอรซึ่งกําหนดเปนคลาสไมได และปรับลดความสําคัญ ของพจนลงเปนแอตทริบิวต แผนภาพคลาสที่ใชในชวงการวิเคราะห จะเรียกวา คลาสวิเคราะห
2)
จะเรียกวา คลาสออกแบบ (design classes) ขอแตกตางคอ คลาสวเคราะหจะแสดงรายละเอยดในระดบสง (high level) คอ เนนแสดงโครงสราง และความสัมพันธระหวางคลาส สวนพฤติกรรมและคุณลักษณะจะแสดงเพียงคราว ๆ สวนคลาสออกแบบจะ แสดงรายละเอียดในระดับต่ํา (low level) คือจะแสดงขอมูลของพฤติกรรม และคุณลักษณะทุกประการอยาง ชัดเจน วัตถุประสงคเพื่อจะสงมอบแผนภาพใหกับโปรแกรมเมอรนําไปเขียนโปรแกรมพัฒนาระบบงานตอไป รายละเอียดภายในแตละคลาส (ภาพที่ 4.12) ประกอบดวย สวนสําคัญหลัก 3 สวน ไดแก (1) สวน บนสุดเปนชื่อของคลาส (2) สวนกลางเปนสวนของแอตทริบิวต (attribute) และ (3) สวนลางสุดเปนสวนของ การดําเนินการ (operation) โดยจะตองระบุชื่อคลาสเสมอ นอกนั้นจะใสหรือไมก็ได
วิเคราะหแบบสถิต
พฤติกรรม คุณลักษณะ ทัศนวิสัย (visibility) ความพหุคูณ
และแท็กแสดงรายละเอียด (tag)
โดยเฉพาะในขั้นตอนการ
(multiplicity)
ขั้นตอนการปรับแบบจําลองที่ไดจากระยะการวิเคราะหสูแบบจําลองในระยะการออกแบบเพื่อให ผูพัฒนาซอฟตแวรหรือนักเขียนโปรแกรมสามารถนําไปใชเปนตนแบบการพัฒนาโปรแกรมไดอยางถูกตองและ
2.1การแมปคลาสจากการวิเคราะหสูการออกแบบ
แมปคลาสที่ไดจากการวิเคราะหไปเปนคลาสที่ใชในชวงของการออกแบบมีการเพิ่มเติมใน รายละเอียดของฟลดและเมสเสจ(Message)ในคลาสรวมถงกาหนดคาเรมตนประเภทของคาเรมตนทศน วิสัย(visibility)และการเพิ่มการกําหนดตัวเขาถึง(accessor)นอกจากเพมเตมในรายละเอยดในสงทมอยเดม แลวยังควรพิจารณาวามีเมสเสจ(Message)ทจาเปนตองใชงานเพมอกหรอไมหากจาเปนตองมกสามารถ เพิ่มในคลาสออกแบบนี้ได
2.2การแมปสนธิการ สําหรับยูเอ็มแอลสัญลักษณตางๆบนแผนภาพในชวงการวิเคราะหและออกแบบไมมีความแตกตาง กันแตอยางใดอยางไรก็ตามบางตําราแนะนําวาสามารถเพิ่มเติมสัญลักษณที่อานชวยสรางความเขาใจในการ ออกแบบไดดีขึ้นเชนการนําแผนภาพคลาสที่ไดจากการวิเคราะหมาเพิ่มการระบุวาassociationที่เกิดขึ้น ระหวาง2คลาสสดทายแลวจะเปนการเพมฟลดลงในคลาสใดคลาสหนง(one-wayassociation)หรืออาจ
47 ภาพท4.12รายละเอียดภายในคลาส ที่มา:วิภาเจริญภัณฑารักษและปราโมทยลือนาม.(2562). 2.การออกแบบซอฟตแวรดวยยเอมแอล
สมบูรณ
เปนไปไดวาจะเพมฟลดลงในทง2คลาสทเรยกวาความสมพนธแบบสองทศทาง(two-wayassociation) ทงนควรพจารณาโดยยดตามขอกาหนดของธรกจเปนหลก
2.3การกําหนดตัวเขาถึง
ตัวเขาถึง(accessor)เปนเมสเสจที่ใชในการกําหนดคาหรือนําคาของฟลดหรือแอตทริบิวตภายใน คลาสมาใชงานและชวยใหการดําเนินการตางๆเกยวกบฟลดถกจดรวมกลมไวทเดยวตวเขาถงแบงเปน2 รูปแบบคือ(1)gettersใชสําหรับนําคาของฟลดมาใชโดยการสงคากลับ(returnthevalue)เมื่อเรียกใช gettersและ(2)settersใชสาหรบตงคาหรอกาหนดคาใหมใหกบฟลด(ภาพที่4.13)
ภาพที่4.13ตัวอยางการกําหนดตัวเขาถึง(accessor)
หลังจากไดคลาสออกแบบแลวสิ่งที่จะไดตามมาคือแผนภาพออบเจ็กตเนื่องจากคลาสเปนแมแบบ ของออบเจ็กตแผนภาพออบเจกตจะชวยใหผออกแบบและผพฒนาโปรแกรมเหนถงโครงสรางของขอมลความ เชอมโยงและเขาใจการทางานทชดเจนของระบบไดดขน 2.4การใชแพตเทิรนในการออกแบบ การออกแบบระบบสารสนเทศนิยมใชแพตเทิรนการออกแบบ(designpattern)เพื่อประหยัดเวลา และลดปญหาขอผิดพลาดแพตเทิรนการออกแบบมีหลากหลายรูปแบบที่หลากหลายการเลือกอันที่ควร พิจารณาตามความเหมาะสมของงานแพตเทิรนที่นิยมใชกันเชนBCE(Boundary-Control-Entity)MVC (Model-View-Controller)และโครงสรางตามเลเยอร(layeringstructure)เปนตน
48
ที่มา:วราภรณวิยานนทและปราโมทยลือนาม.(2562).
ในที่นี้จะกลาวถึงแพตเทิรนเอ็มวีซี(MVC–Model-View-Controller)(ภาพที่4.14)ซึ่งนํามาใช สําหรับการออกแบบกราฟกสวนตอประสานของแอปพลิเคชันบนวินโดวสภายหลังเมื่อเว็บไดรับความนิยมก็ นิยมนําเอ็มวีซีมาใชในการออกแบบเว็บแอปพลิเคชันเชนกันเอ็มวีซีมีแนวคิดวาโครงสรางของแอปพลิเคชัน สามารถแบงคอมโพเนนต(component)ออกเปน3สวนหลักไดแกโมเดล(model)วิว(view)และ คอนโทรลเลอร(controller)โดยโมเดลเปนออบเจ็กตที่ใชแสดงแทนตัวขอมูลในรูปแบบของโครงสราง สารสนเทศ(informationstructures)วิวเปนออกเจ็กตที่ใชในสวนตอประสานผูใชวิวจึงเปนสิ่งที่ผูใชงาน มองเห็นและเปนชองทางในการรับคําสั่งจากผูใชงานสวนคอนโทรลเลอรเปนออบเจ็กตที่ทําหนาที่เปนตัวกลาง ในการเชื่อมตอกับโมเดลและวิวตามเงื่อนไขการทํางานเพื่อควบคุมตรรกะ(controllogic)ทกาหนดในการใช
วราภรณวิยานนทและปราโมทยลือนาม.(2562). เมื่อเลือกแพตเทิรนที่เหมาะสมกับระบบไดแลวขั้นตอนตอไปคือพิจารณาในแตละสวนของ องคประกอบยอยในแพตเทิรนวาควรประกอบดวยระบบยอย(subsystems)ใดบางโดยดูจากหนาที่ความ รับผิดชอบของแตละระบบยอยจากนั้นกําหนดความเกี่ยวของกันหรือการขึ้นตอกัน(dependency)ของแต ละระบบยอยพจารณาจากขอมลทใชรวมกนโดยทวไปแตละระบบยอยควรมหนาทการทางานเฉพาะอยาง และควรมีความเปนอิสระตอกันดังนั้นเมื่อมาทํางานรวมกันจึงตองพิจารณาวาจะติดตอสื่อสารหรือประสาน
49
งาน ภาพที่4.14แพตเทิรนเอ็มวีซี(MVC–Model-View-Controller) ที่มา:
2.5 แบบจําลองการออกแบบสถาปตยกรรมระบบ
แบบจําลองที่จัดสรางในชวงการออกแบบสถาปตยกรรมเปนเรื่องของการนําเอาขอกําหนด คุณลักษณะ (specification) ของระบบมาแสดงใหเห็นถึงภาพของโครงสรางและการเชื่อมโยงองคประกอบที่
50 การทํางานรวมกัน (interact) อยางไร และควรออกแบบสวนตอประสาน (interfaces) อยางไร ใหการทํางาน ของระบบโดยรวมเปนไปอยางมีประสิทธิภาพ ขั้นตอนตอไปคือ ใหพิจารณาวาภายในระบบยอยควรมีองคประกอบหรือคอมโพเนนตใดบาง สามารถ มองไดวาสวนของซอฟตแวร ฮารดแวร หรืออุปกรณตาง ๆ ที่ทํางานรวมกันในระบบ ก็คือ คอมโพเนนตแตละ สวนของระบบนั่นเอง ขั้นตอนนี้จะคลายกับการพิจารณาระบบการทํางานยอย คือ ทุกคอมโพเนนตในระบบ นั้นยอมมีบทบาทหนาที่ของตนอยางชัดเจน ไมควรมีคอมโพเนนตใดที่ทํางานซ้ําซอนกัน ตามหลักการแลวแต ละคอมโพเนนตควรตองมความเปนอสระในการทางานจากกน ทงนเพอใหการแกไขหรอการแทนท คอมโพเนนตเหลานนสามารถทาไดโดยงาย ไมสงผลกระทบ หรอสงผลกระทบตอองคประกอบสวนอนในระบบ นอยที่สุด ถึงแมวาคอมโพเนนตเหลานั้นอาจจะมีการเปลี่ยนแปลงไปตามกาลเวลา อันเนื่องจากความตองการ ตามหนาที่ของระบบที่เปลี่ยนแปลงไปก็ตาม ขอมูลที่ไดจากการวิเคราะหความตองการ และการวิเคราะห ระบบ จะเปนสิ่งสําคัญในการกําหนดขอบเขต หนาที่ความรับผิดชอบของระบบการทํางานไดอยางชัดเจน นอกเหนือจากนั้นการออกแบบที่ดีจะสงผลใหคอมโพเนนตที่ไดพัฒนาขึ้นสามารถนํากลับไปใชใหม (reuse) ได ชวยเพิ่มประสิทธิภาพ ประหยัดเวลา และลดตนทุนในการพัฒนาระบบ
แผนภาพทนามาใชในชวงนประกอบดวยแผนภาพแพกเกจ (package) นําเสนอระบบและลักษณะของการจัดกลุมองคประกอบยอยที่มีความสัมพันธกัน และแผนภาพดีพลอยเมนต (deployment) ที่แสดงวิธีในการปรับใชระบบเขาสูการใชงานจริง แผนภาพแพ็กเกจ ใชสําหรับการจัดกลุมของหนวยยอยในเชิงตรรกะ (logic grouping) (ภาพที่ 4.15) ในการออกแบบระบบทมขนาดใหญและมความซบซอนสง แผนภาพแพกเกจจะชวยใหผใชงานทเกยวของ สามารถทําความเขาใจระบบไดงายขึ้น ดวยการนําเสนอระบบในลักษณะภาพนามธรรมระดับสูง (higher abstraction level) ที่ไมแสดงรายละเอียดปลีกยอย มีการจัดกลุมขององคประกอบที่มีความสัมพันธกัน ออกเปนสวนๆ (ภาพท 416) และแสดงความสมพนธระหวางองคประกอบวามความขนอยตอกนในลกษณะใด ตัวอยางแผนภาพแพ็กเกจแสดงในภาพที่ 4.17
เนนในเชงกายภาพทงหมดของระบบ
วราภรณวิยานนทและปราโมทยลือนาม.(2562).
วราภรณวิยานนทและปราโมทยลือนาม.(2562). การวาดแผนภาพแพ็กเกจควรเริ่มจากการแบงกลุมของแพ็กเกจออกเปนกลุมยอยทางเลือกหนึ่งใน การแบงกลมทนยมทากนคอการแบงลาดบชนตามลกษณะของสถาปตยกรรมทเลอกใช
51 ภาพที่4.15การจดกลมคลาสรวมกนเปนแพกเกจ ที่มา:
ภาพที่4.16สวนประกอบของแผนภาพแพ็กเกจ ที่มา:
แผนภาพดีพลอยเมนต แผนภาพดีพลอยเมนตจัดอยูในกลุมของแผนภาพโครงสราง(structurediagrams)ของยูเอ็มแอล โดยเฉพาะในสวนที่เกี่ยวของกับอุปกรณฮารดแวรและสภาพแวดลอมในการปฏิบัติการของซอฟตแวร (softwareexecutionenvironments)แผนภาพดีพลอยเมนตจึงมักนํามาใชประโยชนในการอธิบายระบบ เนองจากสามารถแสดง(1)สถาปตยกรรมของระบบในขณะใชงาน(run-time)(2)โทโพโลยี(topology)ที่ เปนรูปแบบการเชื่อมตอความสัมพันธเชื่อมโยงและเสนทางการสื่อสาร(communicationpaths)ระหวาง ฮารดแวรในระบบและ(3)สภาพแวดลอมและองคประกอบ(elements)สวนของซอฟตแวรททางานอย ภายในฮารดแวรแตละโหนดแผนภาพดพลอยเมนตจงเปนเอกสารสาคญทมกนามาใชประโยชนในการนาใช ซอฟตแวรคอมโพเนนตทตดตงอยภายในโหนด
52 ภาพที่4.17ตัวอยางแผนภาพแพ็กเกจ ที่มา:
หลังจากศึกษาเนื้อหาสาระเรื่องที่4.2.4แลวโปรดปฏิบัติกิจกรรม4.2.4 ในแนวการศึกษาหนวยที่4ตอนที่4.2เรื่องที่4.2.4
วราภรณวิยานนทและปราโมทยลือนาม.(2562).
