แนวคิดในการวิเคราะห์และออกแบบระบบโดยใช้ UML (ตอนที่ 1)

แนวคิดในการวิเคราะห์  และออกแบบระบบโดยใช้ UML

1. แนะนำภาพรวมของการใช้ UML

2. Usecase Diagram

3. Static Diagram

4. Dynamic Diagram

1. แนะนำภาพรวมของการใช้ UML

UML ย่อมาจาก Unified Modelling Language ซึ่งหมายถึงการรวบรวมสัญลักษณ์ที่ใช้ในการทำโมเดล ที่เกิดจากแนวคิดของศาตราจารย์ 3 ท่านคือ Jame Rumbaugh, Grady Booch และ Ivar Jacobson ซึ่งเป็นผู้ที่ใช้วิธีการบรรยายโมเดลของซอฟแวร์ด้วยรูปภาพ ก่อนที่จะมาเป็น UML ทั้ง 3 ท่านนี้ได้มีรูปภาพที่ใช้สำหรับบรรยายองค์ประกอบในซอฟแวร์ที่เป็นของแต่ละท่านเองอยู่แล้ว แต่เนื่องจากวิธีการของทั้ง 3 ท่านนี้ได้ตีพิมพ์เผยแพร่จนกระทั่งเป็นที่นิยมใช้กันแพร่หลายในเวลาต่อมา และสัญลักษณ์ที่ใช้ก็ปรากฏออกมาเป็นรูปร่างที่ต่างกัน ทำให้เอกสารที่เขียนขึ้นด้วยสัญลักษณ์แบบหนึ่งไม่สามารถถ่ายทอดความเข้าใจไปสู่นักพัฒนาระบบที่เรียนรู้สัญลักษณ์มาจากวิธีการอีกแบบหนึ่งได้ ทั้งที่เป็นการบรรยายในเรื่องเดียวกันแต่เนื่องจากใช้สัญลักษณ์หรือรูปภาพไม่เหมือนกันจึงทำให้เกิดปัญหาในการสื่อความหมาย  และทำให้เกิดความล่าช้าในการพัฒนาระบบ

จนกระทั่งประมาณปี ค.ศ. 1997 ศาสตราจารย์ทั้ง 3 ท่านได้ริเริ่มแนวคิดที่เป็นมาตรฐานโดยรวบรวมเอาสัญลักษณ์ที่ใช้สำหรับบรรยายองค์ประกอบซอฟแวร์ในวิธีการต่าง ๆ  มาปรับปรุงรวบรวม และจัดกลุ่มให้เกิดขึ้นเป็นสัญลักษณ์มาตรฐานที่จะสามารถนำไปถ่ายทอดสื่อสารกันระหว่างนักพัฒนาซอฟแวร์ทั่วโลก จนกระทั่งเกิดเป็น UML และปัจจุบัน UML ก็ได้รับการยอมรับให้เป็นมาตรฐานหนึ่งของ ISO ทางซอฟแวร์ ซึ่งนอกจากจะใช้บรรยายองค์ประกอบของซอฟแวร์แล้ว ในอนาคต UML ยังขยายรูปสัญลักษณ์ให้ครอบคลุมไปถึงการบรรยายในเรื่องอื่น ๆ  ที่ไม่เกี่ยวข้องกับซอฟแวร์โดยตรงอีกด้วย เช่น Business Process หรือ Workflow ก็สามารถใช้ UML บรรยายให้เห็นเป็นรูปภาพได้

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

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

รูปภาพ 1 ภาพรวมของ UML ไดอะแกรม

จากภาพที่ 1 จะสังเกตเห็นว่า เราสามารถแยกไดอะแกรมออกได้เป็น 2 ประเภทใหญ่ ๆ  คือ Static Diagram และ Dynamic Diagram ส่วนที่เป็น Static Diagram ใช้สำหรับออกแบบโครงสร้างเปรียบเสมือนกับโครงสร้างของตึกหรือสิ่งก่อสร้างที่เราใช้กันอยู่ในอุตสาหกรรมก่อสร้าง และส่วนที่เป็น Dynamic Diagram  ใช้สำหรับออกแบบการทำงานขององค์ประกอบต่าง ๆ  ในโครงสร้างว่าส่วนประกอบแต่ละส่วนมีการทำงานภายในตัวมัน และมีการทำงานประสานงานกันเป็นอย่างไร ซึ่งถ้าเปรียบเทียบกับการสร้างตึก Static Diagram  จะทำให้เราเห็นว่าตึกหลังนี้มีโครงสร้างอาคารอย่างไร คือมีการแบ่งชั้นออกเป็นกี่ชั้น และแต่ละชั้นมีห้องกี่ห้อง มีห้องประชุม ห้องน้ำ ห้องรับแขกอยู่ที่จุดไหนในอาคาร แต่การดูแต่ Static Diagram เราจะไม่ทราบว่าตึกหลังนี้มีระบบรักษาความปลอดภัยเป็นอย่างไร มีวิธีการอย่างไรจึงจะสามารถขอเข้าใช้ห้องประชุม หรือวิธีการขอเช่าที่จอดรถ ต่าง ๆ  เหล่านี้เราจะต้องดูที่ Dynamic Diagram เนื่องจากเป็นเรื่องของวิธีการที่เราจะนำมาใช้กับโครงสร้างที่ได้ออกแบบไว้

สำหรับ Usecase Diagram ที่ไม่ได้จัดให้อยู่ในประเภท Static หรือ Dynamic เนื่องจาก Usecase ไม่ได้มีวัตถุประสงค์เพื่อใช้ออกแบบองค์ประกอบในระบบ แต่ใช้สำหรับบรรยายถึงความต้องการของระบบว่าระบบที่เราจะสร้างขึ้นมีความสามารถอะไรที่ผู้ใช้สามารถใช้งานได้

1.2 วัตถุประสงค์ของไดอะแกรมแต่ละประเภท

1.2.1 Usecase Diagram

Usecase Diagram มีวัตถุประสงค์เพื่อแสดงให้เห็นสถานการณ์ต่าง ๆ  ที่ผู้ใช้สามารถใช้งานระบบ แต่ละสถานการณ์ที่ระบบสามารถบริการให้ผู้ใช้สำเร็จลุล่วงตามที่ต้องการได้ เราเรียกว่า Usecase ในแต่ละ Usecase จะมีลำดับเหตุการณ์ (Scenario) ที่สามารถบรรยายได้ว่าผู้ใช้  (Actor) โต้ตอบกับระบบอย่างไรบ้าง

รูปภาพ 2 ตัวอย่างของ Usecase ของระบบร้านอาหาร

จากภาพที่ 2 เราจะเห็นว่าในระบบร้านอาหารจะมีกรณีต่าง ๆ  ที่ผู้ใช้ระบบสามารถเข้าใช้งานระบบได้ และเราจะแบ่งผู้ใช้ออกตามบทบาทที่เค้ากระทำกับระบบ เช่น ลูกค้าที่ใช้งานระบบสามารถสั่งให้ระบบทำอะไรได้บ้าง ผู้จัดการร้านสามารถสั่งให้ระบบทำอะไรได้บ้าง เป็นต้น

สำหรับรายละเอียดของสัญลักษณ์ที่ใช้ใน Usecase ไดอะแกรมจะมีอธิบายในหัวข้อที่ 2 Usecase Diagram ต่อไป

1.2.2 Class Diagram

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

รูปภาพ 3 ตัวอย่างของ Class Diagram ในระบบลงทะเบียนฝึกอบรม

จากในภาพที่ 3 เราเห็นถึงโครงสร้างของคลาสต่าง ๆ  ในระบบลงทะเบียนฝึกอบรม ซึ่งถ้าเรานำคลาสต่าง ๆ  เหล่านี้มาสร้างเป็นวัตถุใช้ในระบบงานและประกอบเข้าด้วยกัน ให้สามารถทำงานร่วมกันแล้วเราจะได้แบบจำลองของระบบธุรกิจที่เรากำลังต้องการใช้งานอยู่ ตัวอย่างเช่น วัตถุที่สร้างจากคลาส Student จะเป็นตัวแทนของนักเรียนที่มาลงทะเบียนเรียน วัตถุที่สร้างจากคลาส Subject จะเป็นตัวแทนของวิชาหนึ่งวิชา เป็นต้น

สำหรับรายละเอียดของสัญลักษณ์ที่ประกอบกันอยู่ใน Class Diagram จะมีอธิบายไว้ในหัวข้อ Static Diagram ต่อไป

1.2.3 Object Diagram

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

รูปภาพ 4 การใช้ Object Diagram เพื่อตรวจสอบความถูกต้องของ Class Diagram

จากภาพที่ 4 สังเกตว่าเมื่อเราได้ออกแบบความสัมพันธ์ระหว่างวัตถุ Customer  และวัตถุ Address ไว้ใน Class Diagram ว่าให้มีความสัมพันธ์เป็นแบบ Many-to-Many แล้ว เราอาจจะต้องเขียน Object Diagram ขึ้นอย่างในภาพที่ 4 เพื่อจำลองเหตุการณ์ว่าวัตถุ Customer 3 ตัวจะสัมพันธ์กับวัตถุ Address 2 ตัวได้อย่างไร ในกรณีที่เกิดความขัดแย้งกับที่ระบบงานต้องการ เราจะสามารถเห็นได้ทันทีจากใน Object Diagram เช่นถ้าในระบบงานกำหนดไว้ว่า “ที่อยู่ของลูกค้าหนึ่งคนจะนำไปใช้กับลูกค้ารายอื่นไม่ได้” เมื่อเรานำมาตรวจสอบดูใน Object Diagram จะพบว่าที่อยู่ a999 ถูกนำไปใช้กับลูกค้า 3 รายคือ somchai somsuk และ somsri ซึ่งผิดไปจากที่ระบบกำหนดไว้ เราจะรู้ได้ทันทีว่าที่ออกแบบไว้ใน Class Diagram เป็นการออกแบบที่ผิดและต้องแก้ไขให้กลายเป็นความสัมพันธ์แบบ One-to-Many จากวัตถุ Customer ไปที่วัตถุ Address แทน

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

1.2.4 Sequence Diagram

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

รูปภาพ 5 ตัวอย่างลำดับเหตุการณ์เมื่อพนักงานขายทำใบเสนอราคา

จากภาพที่ 5 สังเกตเห็นว่าเมื่อพนักงานขายที่อู่ซ่อมรถยนต์แห่งหนึ่ง ต้องการส่งใบเสนอราคาให้ลูกค้า พนักงานขายจะเข้าสู่ระบบแล้ว สั่งสร้างใบเสนอราคาผ่านทางเว็บเพจที่ระบบได้จัดเตรียมไว้ให้ แล้วหลังจากนั้นที่หน้าเว็บจะไปสั่งงานวัตถุ Garage ให้สร้างวัตถุ Quotation ขึ้น พร้อมกับใส่รายละเอียดคือวัตถุ Part ที่จำเป็นต้องซ่อมหรือเปลี่ยนใหม่เข้าไปในวัตถุ Quotation หลังจากสั่งให้วัตถุ Quotation พิมพ์ออกมาทางเครื่องพิมพ์แล้วจึงบันทึกใบเสนอราคาไว้ในระบบงานพร้อมกับแฟกซ์ใบเสนอราคาให้ลูกค้า

Sequence Diagram ถือว่าเป็นไดอะแกรมที่มีความสำคัญมากพอ ๆ  กับ Class Diagram เนื่องจาก Sequence Diagram จะบอกให้เราทราบว่าวัตถุแต่ละตัวในระบบมีการทำงานร่วมกันอย่างไร และใครทำก่อนทำหลัง ซึ่งปกติแล้ว Class Diagram จะไม่ระบุถึงรายละเอียดในการปฏิบัติอย่างใน Sequence Diagram

รายละเอียดของสัญลักษณ์ที่ใช้ใน Sequence Diagram จะกล่าวถึงอีกครั้งในหัวข้อ Dynamic Diagram ต่อไป

1.2.5 Collaboration Diagram

อยู่ในกลุ่มของ Dynamic Diagram เช่นเดียวกับ Sequence Diagram แต่ Collaboration Diagram จะแสดงให้เห็นถึงภาพรวมของการทำงานร่วมกันระหว่างวัตถุ โดยไม่เน้นไปที่ลำดับของการสั่งงานอย่างที่แสดงใน Sequence Diagram ดังนั้นผู้ที่มอง Collaboration Diagram จะต้องการรู้เพียงว่างาน ๆ  นี้ประกอบขึ้นจากวัตถุอะไรมาทำงานร่วมกันบ้าง

รูปภาพ 6 Collaboration Diagram ที่มีความหมายตรงกับกับที่แสดงในภาพที่ 5

ในภาพที่ 6 แสดงให้เห็น Collaboration Diagram ที่เป็นการประสานงานกันระหว่างวัตถุ Garage วัตถุ Quotation และวัตถุ Part เพื่อให้พนักงานขายสามารถพิมพ์ใบเสนอราคา เราจะสังเกตเห็นว่าภาพนี้จะมีความหมายเดียวกันกับภาพที่ 5 แต่วิธีการเขียนจะต่างจาก Sequence Diagram ตรงที่จะเสนอมุมมองในแบบภาพรวมมากกว่าการเน้นไปที่ลำดับการสั่งงาน

1.2.6 Statechart Diagram

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

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

รูปภาพ 7 แสดงสถานะของวัตถุหนังสือในระบบห้องสมุด

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

สำหรับรายละเอียดของสัญลักษณ์ที่ใช้งาน Statechart Diagram จะกล่าวถึงอีกครั้งในเรื่อง Dynamic Diagram

1.2.7 Activity Diagram

ใช้สำหรับแสดงให้เห็นถึงกิจกรรมย่อย ๆ  ที่ต้องทำให้เสร็จในหนึ่งงาน ใน Activity Diagram จะไม่ได้สนใจว่าเป็นลำดับเหตุการณ์ใน Usecase ไหน แต่จะเกี่ยวข้องกับกระบวนการทางธุรกิจ (Business Process) จริง ๆ  ที่ระบบงานต้องกระทำให้สำเร็จลุล่วง ดังนั้นใน Activity Diagram จึงแสดงเฉพาะกิจกรรมโดยไม่ได้สนใจว่ากิจกรรมนั้นจะทำโดยวัตถุตัวไหน ซึ่งจะแตกต่างจาก Sequence และ Collaboration ถ้าเป็น Sequence Diagram เราจะต้องบอกให้ได้ว่าวัตถุตัวไหนเป็นผู้สั่งงานและวัตถุตัวไหนเป็นผู้รับผิดชอบทำงานนั้น

รูปภาพ 8 ตัวอย่างการใช้ Activity Diagram เพื่อบรรยายกิจกรรมที่ต้องทำเพื่อส่งต่อผู้ป่วย

จากภาพที่ 8 แสดงให้เห็นกิจกรรมที่ต้องทำเพื่อส่งต่อผู้ป่วยที่มีสิทธิประกันสุขภาพจากสถานบริการแห่งหนึ่งไปยังสถานบริการอีกแห่งหนึ่ง

รายละเอียดของสัญลักษณ์ที่ใช้ใน Activity Diagram จะกล่าวถึงอีกครั้งในเรื่องของ Dynamic Diagram ต่อไป

1.2.8 Component Diagram

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

นอกจากนี้ ในการเขียน Component Diagram มักจะเป็นการเขียนที่ผ่านการวิเคราะห์ในระดับรายละเอียดมาแล้วว่าจะพัฒนาระบบด้วยแพลตฟอร์ม[1]อะไร ดังนั้นส่วนประกอบที่ปรากฏในไดอะแกรมจะระบุให้เห็นถึงความเป็นเอกลักษณ์ของแพลตฟอร์มที่ใช้ด้วยก็ได้ เช่น ถ้าพัฒนาส่วนประกอบให้สามารถรันได้บนแพลตฟอร์ม J2EE ส่วนประกอบอาจจะอยู่ในรูปของไฟล์ JAR, WAR หรือ EAR แต่ถ้าพัฒนาส่วนประกอบให้สามารถรันได้บนแพลตฟอร์ม Windows ส่วนประกอบก็อาจจะอยู่ในรูปของไฟล์ DLL เป็นต้น

รูปภาพ 9 ตัวอย่างของส่วนประกอบที่ใช้ในแพลตฟอร์มที่เป็นที่นิยมอยู่ในปัจจุบัน

ในภาพที่ 9 เราสามารถเขียนส่วนประกอบด้วยสัญลักษณ์รูปสี่เหลี่ยมและมีขายื่นออกมาสองขา ทั้งสองขานั้นเป็นการแสดงความหมายของปลั๊ก (Plug) ที่ใช้สำหรับเสียบประกอบเข้ากับระบบงาน ในการพัฒนาระบบแบบประกอบส่วน (Component-Based Software Development) จะเน้นการแยกผลิตภัณฑ์ออกเป็นส่วนประกอบย่อย ๆ  และแบ่งสายการผลิตออกตามส่วนประกอบที่ต้องสร้างขึ้น รวมทั้งการตรวจสอบคุณภาพของส่วนประกอบก่อนที่จะประกอบเข้าสู่ระบบงาน

การออกแบบ

รูปภาพ 10 ตัวอย่างของการแบ่งระบบออกเป็นส่วนประกอบหลาย ๆ  ชิ้น  และเชื่อมต่อกันด้วยอินเตอร์เฟส

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

เนื่องจากสัญลักษณ์ที่ใช้ Component Diagram มีไม่มากนัก และใช้รูปสัญลักษณ์เหมือนกับใน Class Diagram ดังนั้นผู้อ่านสามารถดูความหมายของสัญลักษณ์ได้จากหัวข้อ Static Diagram ต่อไป

1.2.9 Deployment Diagram

ใช้สำหรับจัดวางระบบงาน และวางตำแหน่งของส่วนประกอบให้อยู่ในเครื่องเซิร์ฟเวอร์หรือเครื่องไคลเอ็นต์ที่เหมาะสม เนื่องจากในปัจจุบันระบบงานส่วนใหญ่ใช้ Distributied Technology[2]  ซึ่งจะสามารถนำส่วนประกอบที่พัฒนามาวางอยู่ในเครื่องคอมพิวเตอร์เครื่องไหนก็ได้ที่เชื่อมต่อกันอยู่ในเน็ตเวิร์ค เพื่อให้เครื่องคอมพิวเตอร์หลาย ๆ  เครื่องช่วยกันทำงาน เป็นการเพิ่มประสิทธิภาพของระบบ และลดความเสี่ยงที่จะเกิดขึ้นกับคอมพิวเตอร์เพียงเครื่องเดียว

ดังนั้นส่วนประกอบที่พัฒนาขึ้นมาอาจจะถูกนำไปวางไว้อยู่ในเครื่องคอมพิวเตอร์หลาย ๆ  เครื่องในเน็ตเวิร์คแล้วให้ทำงานร่วมกันโดยใช้ Distributed Protocol อย่างเช่น RMI, IIOP, COM+ หรือ SOAP เป็นต้น ดังนั้นการจัดวางส่วนประกอบจึงเป็นเรื่องที่ต้องพิจารณาถึงในการพัฒนาระบบด้วย ว่าจะนำส่วนประกอบไปแยกวางไว้กี่เครื่องแล้วเครื่องเซิร์ฟเวอร์ตัวไหนรับผิดชอบหน้าที่อะไร ใน UML เราใช้ Deployment Diagram เพื่อบอกให้ทราบว่า ส่วนประกอบไหนถูกวางไว้ที่เครื่องคอมพิวเตอร์เครื่องไหน ใน Deployment Diagram จะเรียกเครื่องเทอร์มินอลที่มีหน่วยประมวลผลสำหรับรันส่วนประกอบได้เรียกว่า โหนด (Node) เนื่องจากปัจจุบันหน่วยประมวลผลไม่ได้ยึดติดอยู่กับเครื่องคอมพิวเตอร์เสมอไป ยกตัวอย่างเช่น หน่วยประมวลผลที่อยู่ในโทรศัพท์มือถือ หน่วยประมวลผลที่อยู่ในเครื่องใช้ไฟฟ้า ดังนั้นคำว่าโหนดจึงมีความหมายกว้างกว่าคอมพิวเตอร์

รูปภาพ 11 ตัวอย่างการจัดวางส่วนประกอบและโหนดใน Deployment Diagram

ภาพที่ 11 ใน Deployment Diagram จะใช้สัญลักษณ์กล่องสี่เหลี่ยมแทนโหนด และในโหนดจะมีส่วนประกอบต่าง ๆ  ที่กำลังรันอยู่ภายใน ตัวอย่างในภาพนี้แบ่งโหนดออกเป็น 3 โหนดคือ Central Server ที่เป็นเครื่องเซิร์ฟเวอร์ของส่วนกลาง และ Sender Server ที่เป็นเว็บเซิร์ฟเวอร์ที่ศูนย์ใหญ่ประจำแต่ละจังหวัด และ Receiver Server ที่เป็นเว็บเซิร์ฟเวอร์ที่อยู่ในสถานบริการย่อย ๆ  แต่ละแห่ง

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

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

รูปภาพ 12 บทบาทของบุคคลากรในทีมพัฒนาระบบที่เกี่ยวข้องกับ Diagram ใน UML

จากภาพที่ 12 เป็นตัวอย่างของบทบาทที่เกี่ยวข้องกับ UML เช่น System Analyst มีหน้าที่เขียน Usecase Diagram และ Software Architect มีหน้าที่เปลี่ยน Usecase ให้กลายเป็นสถาปัตยกรรมของระบบงานที่บรรยายออกมาเป็น Class Diagram และ Sequence Diagram รวมทั้งไดอะแกรมอื่น ๆ  อีกที่จะทำให้ระบบมีสถาปัตยกรรมที่ชัดเจนขึ้น ส่วน Programmer จะมีต้องสามารถอ่านและทำความเข้าใจกับไดอะแกรมต่าง ๆ  ที่ System Analyst และ Software Architect เป็นผู้เขียนขึ้น รวมทั้งบางครั้ง Programmer อาจจะต้องสามารถเขียน Class Diagram หรือ Sequence Diagram ในระดับรายละเอียดได้ด้วย สำหรับ System Administrator จะสามารถอ่าน Component Diagram และ Deployment Diagram เพื่อนำแอพพลิเคชันไปติดตั้งให้เกิดเป็นระบบงานตามที่ผู้ใช้ต้องการได้

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

1.4 สรุปภาพรวมของการใช้ UML กับการพัฒนาระบบ

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

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

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

รูปภาพ 13 ขั้นตอนในการออกแบบระบบงาน

 ในภาพที่ 13 แสดงการแบ่งขั้นตอนในการออกแบบออกเป็น 3 ขั้นคือ Conceptual Design เป็นการออกแบบขั้นพื้นฐานเพื่อกำหนดโครงสร้างและสถาปัตยกรรมโดยรวมของระบบ ในขั้นนี้นักออกแบบจะพยายามหาว่าระบบต้องทำงานอะไรให้กับผู้ใช้บ้าง และพยายามค้นหาวัตถุหลักที่ประกอบอยู่ในระบบนั้น ซึ่งเราเรียกว่า Domain Object ดังนั้นในขั้น Conceptual Design จะต้องเกี่ยวข้องกับไดอะแกรมหลายชนิด รวมทั้ง Class และ Sequence Diagram ด้วย แต่ลักษณะการเขียน Class และ Sequence Diagram จะเขียนในลักษณะที่ไม่ระบุรายละเอียด เช่น ไม่บอกชนิดข้อมูลของแอททริบิวท์และเมธอด

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

ในขั้น Physical Design จะสมมุติว่าได้ผลผลิตเป็นโปรแกรมและส่วนประกอบที่สามารถทำงานได้ตามความต้องการของระบบแล้ว เราจะต้องนำส่วนประกอบเหล่านี้ไปจัดวางในโหนดต่าง ๆ  ให้เหมาะสม ดังนั้นเราจึงจำเป็นต้องใช้ Component Diagram และ Deployment Diagram เพื่อแสดงให้เห็นถึงภาพรวมของการจัดวางส่วนประกอบต่าง ๆ  ในระบบงาน

บทความอื่นที่เกี่ยวข้อง