การออกแบบระบบโดยใช้ UML (Unified Modeling Language)

แนวคิดในการวิเคราะห์  และออกแบบระบบโดยใช้ 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 เพื่อแสดงให้เห็นถึงภาพรวมของการจัดวางส่วนประกอบต่าง ๆ  ในระบบงาน

2. Usecase Diagram

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

รูปภาพ 14 Usecase Diagram ของระบบส่งต่อผู้ป่วย

ในภาพที่ 14 เป็นตัวอย่างการใช้งาน Usecase Diagram เพื่อแสดงให้เห็นกรณีต่าง ๆ  ที่ผู้ใช้เข้ามาใช้งานระบบ สัญลักษณ์รูปคนก้าง (Stickman) เราเรียกว่าแอคเทอร์ (Actor) แอคเทอร์จะใช้แทนผู้ใช้ที่เป็นคนจริง หรือระบบอีกระบบหนึ่งที่ต้องการใช้งานระบบนี้ก็ได้

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

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

ความสัมพันธ์ระหว่าง Usecase กับ Usecase สามารถเกิดขึ้นได้ 2 แบบคือ

1.    includes                   ถ้า Usecase หนึ่ง includes ไปที่ Usecase อีกก้อนหนึ่ง หมายถึง การทำงานภายใน Usecase นั้นจะต้องไปสั่งให้อีก Usecase ที่ถูก includes เข้ามาไว้ ทำงานร่วมกันด้วย ถ้าคิดในแบบง่าย ๆ  ก็คือ Usecase ที่ถูก includes จะถูกรวมการทำงานเข้าไว้กับ Usecase ที่เป็นตัวหลักด้วยเสมอ จากตัวอย่างในภาพที่ 14 จะพบว่า การตรวจสอบสถานภาพของผู้ป่วย การตรวจสอบค่าใช้จ่ายที่ใช้รักษา และการบันทึกข้อมูลผู้ป่วยส่งต่อจะต้องผ่าน Usecase เพื่อเลือกผู้ป่วยก่อนเสมอ

                                        ความสัมพันธ์แบบ includes มักจะเกิดขึ้นเสมอกับ Usecase ที่มีลักษณะการทำงานเป็นทั่วๆ  ไป เช่น การเพิ่มข้อมูล การลบข้อมูล การบันทึกข้อมูล การค้นหาข้อมูล ซึ่งมักจะถูกรวมเข้าไปไว้ใน Usecase ที่เป็นกิจกรรมเฉพาะของระบบงานนั้น ๆ

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

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

รูปภาพ 15 การออกแบบให้แอคเทอร์สืบทอดต่อจากแอคเทอร์ที่มีลักษณะทั่วไป

2.1 Usecase Description

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

ตารางที่ 1 ตัวอย่างข้อมูลที่ควรใส่เข้าไปใน Usecase Description

Usecase No.	หมายเลข Usecase เพื่อใช้สำหรับอ้างอิงกับ Usecase อื่น
Usecase name	ชื่อของ Usecase
Last update on	วันที่แก้ไขครั้งสุดท้าย
Last update by	ชื่อของผู้ที่แก้ไขเอกสารนี้ครั้งสุดท้าย
Primary Actor	แอคเทอร์ที่เป็นผู้กระทำหลัก
Secondary Actor	แอคเทอร์ที่เป็นผู้กระทำรอง
Objective	วัตถุประสงค์
Usecase type	ประเภทของ Usecase เช่น Basic, Alternative, Abstract หรือ Extension
Precondition	เงื่อนไขที่ต้องเกิดมาก่อนที่จะมาทำงานที่ Usecase นี้
Success End Condition	เงื่อนไขที่บ่งชี้ให้เห็นว่า Usecase เสร็จอย่างสมบูรณ์
Failed End Condition	เงื่อนไขที่บ่งชี้ให้เห็นว่า Usecase ล้มเหลว
Trigger	เมื่อเข้ามาทำที่ Usecase นี้แล้วจะทำให้เกิดเหตุการณ์ต่อเนื่องอะไรขึ้น
Basic Flow of Events	ลำดับเหตุการณ์ตามปกติ
Exception Flow of Events	ลำดับเหตุการณ์พิเศษที่ไม่ค่อยพบบ่อยในกรณีปกติ
Alternative Flow of Events	ลำดับเหตุการณ์อื่น ๆ  ที่เป็นทางเลือกเมื่อไม่สามารถทำตามลำดับเหตุการณ์ปกติได้
Current Open Issue	ประเด็นที่ยังเป็นที่น่าสงสัยอยู่ในปัจจุบัน
Future Open Issue	ประเด็นที่อาจจะเกิดขึ้นในอนาคต
Superordinates	Usecase ที่ต้องเกิดขึ้นก่อนที่จะเข้ามาทำงานใน Usecase นี้
Subordinates	Usecase ที่จะเกิดตามมาหลังจากที่ Usecase นี้เสร็จสิ้น
General Description	รายละเอียดอื่น ๆ  ทั่วไปที่เพิ่มเติมให้กับผู้อ่าน

ในตารางที่ 1 จะเป็นรายละเอียดทั่ว ๆ  ไปที่ควรจะใส่ให้กับ Usecase หนึ่งก้อน ซึ่งอาจจะมีรูปแบบต่างกันไป แล้วแต่กฏระเบียบของทีมพัฒนา อย่างไรก็ตามข้อมูลที่สำคัญที่ควรจะปรากฏใน Usecase Description เสมอก็คือลำดับเหตุการณ์[3]ที่เกิดขึ้น ซึ่งอย่างน้อยจะต้องมีอยู่หนึ่งลำดับเหตุการณ์ที่เป็นเหตุการณ์หลักที่แอคเทอร์จะกระทำกับระบบงานใน Usecase นี้ นอกจากนั้นถือว่าเป็นข้อมูลเพิ่มเติมที่อาจจะมีหรือไม่มีก็ได้

ตารางที่ 2 ตัวอย่างของการเขียน Usecase Description ให้กับ Usecase บันทึกข้อมูลผู้ป่วยส่งต่อ

Usecase No.	3.1
Usecase name	บันทึกข้อมูลผู้ป่วยส่งต่อ
Last update on	10 กันยายน พ.ศ. 2546
Last update by	นาย สรพงษ์ เรือนมณี
Primary Actor	ผู้ใช้ระบบของสถานบริการฝ่ายส่ง
Secondary Actor
Objective	เพื่อบันทึกข้อมูลผู้ป่วย แล้วส่งต่อไปให้สถานบริการที่จะรับผู้ป่วยไปรักษาต่อ
Usecase type	þ Basic ¨ Alternative ¨ Abstract ¨ Extension
Precondition	1.      ผู้ใช้ต้องป้อนชื่อผู้ใช้และรหัสผ่านเพื่อขอเข้าสู่ระบบก่อน 2.      ผู้ใช้ต้องมีระดับสิทธิพอเพียงที่จะดำเนินการบันทึกข้อมูลผู้ป่วยส่งต่อ 3.      ผู้ป่วยที่จะถูกส่งต่อไปที่สถานบริการฝ่ายรับ จะต้องเป็นผู้ป่วยที่มีสิทธิประกันสุขภาพ โดยผ่านการตรวจสอบสิทธิมาแล้ว
Success End Condition	1.      มีข้อมูลครบถ้วนถูกบันทึกไว้ในแฟ้มผู้ป่วยส่งต่อ 2.      มีข้อความแจ้งเตือนไปปรากฏที่เครื่องเทอร์มินอลของสถานบริการฝ่ายรับ ว่าผู้ป่วยที่ถูกเลือก ได้ส่งต่อไปที่สถานบริการแห่งนั้นแล้ว 3.      มีข้อความปรากฏให้ผู้ใช้ทราบว่าได้บันทึกข้อมูลเสร็จเรียบร้อยแล้ว
Failed End Condition	1.      มีข้อความปรากฏให้ผู้ใช้ทราบว่าการบันทึกข้อมูลไม่สำเร็จ 2.      ไม่มีข้อมูลใด ๆ  ทั้งสิ้นบันทึกไว้ในแฟ้มผู้ป่วยส่งต่อ 3.      ไม่มีข้อความแจ้งเตือนใด ๆ  ไปปรากฏที่เครื่องเทอร์มินอลของสถานบริการฝ่ายรับ
Trigger	ส่งเหตุการณ์แจ้งเตือนไปที่เครื่องเทอร์มินอลของสถานบริการฝ่ายรับ
Basic Flow of Events	1.      หลังจากผู้ใช้เข้าสู่ระบบงาน และผู้ใช้มีสิทธิที่จะส่งต่อผู้ป่วยได้ จะปรากฏคำสั่งให้ผู้ใช้เลือกว่าจะส่งต่อผู้ป่วย 2.      ผู้ใช้เลือกคำสั่งเพื่อส่งต่อผู้ป่วย จะปรากฏแบบฟอร์มให้ผู้ใช้กรอกข้อมูลที่จำเป็นสำหรับการส่งต่อผู้ป่วย 3.      ผู้ใช้เลือกผู้ป่วยที่ต้องการส่งต่อไปที่สถานบริการอื่น (ดูที่ Usecase 3.2 เลือกผู้ป่วย) 4.      ผู้ใช้เลือกสถานบริการที่ต้องการส่งผู้ป่วยไปให้ (ดูที่ Usecase 3.3 เลือกสถานบริการ) 5.      ผู้ใช้กรอกรายละเอียดที่เหลือในแบบฟอร์มให้ครบถ้วน 6.      ผู้ใช้เลือกคำสั่งบันทึกข้อมูลผู้ป่วยส่งต่อ 7.      ระบบตรวจสอบความถูกต้องของข้อมูลในแบบฟอร์มผู้ป่วยส่งต่อ ก่อนที่จะเริ่มดำเนินการบันทึกเข้าสู่ระบบ 8.      ถ้าข้อมูลที่ผู้ใช้กรอกเข้ามาทุกอย่างถูกต้อง และครบถ้วนสมบูรณ์ ระบบจะบันทึกข้อมูลผู้ป่วยส่งต่อ เข้าสู่แฟ้มข้อมูลผู้ป่วยส่งต่อ 9.      ระบบส่งสัญญาณแจ้งเตือนไปที่เครื่องเทอร์มินอลที่เปิดไว้ที่สถานบริการที่รับต่อผู้ป่วย 10.    ระบบแจ้งข้อความให้ผู้ใช้ทราบว่าการบันทึกเสร็จสมบูรณ์ 11.    ผู้ใช้ตอบ ตกลง แล้วกลับเข้าสู่การทำงานในหน้าเมนูหลัก
Exception Flow of Events	8.1    ถ้าข้อมูลที่ผู้ใช้กรอกเข้ามาไม่ครบถ้วนสมบูรณ์ 8.2    แสดงข้อความแจ้งเตือนปรากฏขึ้นบนหน้าจอ พร้อมกับแนะนำผู้ใช้ว่าสมควรแก้ไขที่ตรงจุดไหน 8.3    ผู้ใช้แก้ไขข้อมูลในแบบฟอร์มแล้วทดลองสั่งบันทึกข้อมูลใหม่อีกครั้ง
Alternative Flow of Events	1.      ลักษณะการทำงานแบบ Batch Operation โดยการเก็บข้อมูลผู้ป่วยส่งต่อไว้ก่อน แล้วจึงสั่งให้บันทึกข้อมูลทั้งหมดในเวลาเดียวกัน
Current Open Issue	1.      มีการทำงานแบบ Offline หรือไม่ เช่นในกรณีที่เครื่องเซิร์ฟเวอร์ที่ส่วนกลางไม่พร้อมดำเนินการให้ จะสามารถเก็บข้อมูลการส่งต่อผู้ป่วยไว้ที่เครื่องเทอร์มินอลก่อนหรือไม่ 2.      การแจ้งไปที่เครื่องเทอร์มินอลของสถานบริการรับผู้ป่วย จะให้แจ้งแบบ Synchronous หรือแจ้งแบบ Asynchronous 3.      ต้องการให้เก็บบันทึกเหตุการณ์ ที่ผู้ใช้เข้าใช้งานระบบไว้ในไฟล์บันทึกเหตุการณ์เปลี่ยนแปลง (Event Log) ด้วยหรือไม่
Future Open Issue	1.      ในกรณีที่มีผู้ใช้สองคนพยายามจะส่งผู้ป่วยคนเดียวกัน กรณีแบบนี้สามารถเกิดขึ้นได้หรือไม่ และถ้าเกิดขึ้นจะให้แก้ปัญหานี้อย่างไร
Superordinates	1.      ตรวจสอบความเป็นผู้ใช้ของระบบ 2.      ตรวจสอบสิทธิการเข้าใช้งาน 3.      เลือกผู้ป่วย 4.      ตรวจสอบสิทธิประกันสุขภาพของผู้ป่วย 5.      เลือกสถานบริการที่รับผู้ป่วย
Subordinates	1.      ส่งสัญญาณเตือนสถานบริการฝ่ายรับ
General Description

2.2 สรุปการใช้งาน Usecase Diagram

ใน Usecase Diagram ประกอบด้วยสัญลักษณ์ 3 อย่างคือ

ชื่อสัญลักษณ์	รูปสัญลักษณ์	คำอธิบายอย่างย่อ
Usecase		แสดงกรณีที่แอคเทอร์จะทำงานโต้ตอบกับระบบ และจะต้องมีผลลัพธ์บางอย่างเกิดขึ้นถ้าทำสำเร็จ
Actor		เป็นผู้กระทำกับระบบงาน โดยสั่งให้ระบบทำงานบางอย่างให้ อาจจะเป็นผู้ป้อนข้อมูลให้กับระบบ หรือเป็นผู้ที่ต้องการข้อมูลจากระบบก็ได้
includes stereotype		รวมเอาอีก usecase หนึ่งที่ปลายลูกศรชี้ไปไว้ด้วยกัน แสดงให้เห็นว่าไปเรียกใช้งาน usecase อีกตัวหนึ่ง
extends stereotype		มี usecase ที่เกิดขึ้นเป็นกรณีพิเศษ ต่อไปจาก usecase ตัวนี้ ซึ่งทางปลายลูกศรจะชี้ไปที่อีก usecase หนึ่งที่เป็นกรณีพิเศษที่ไม่ค่อยจะพบบ่อยในการทำงานตามปกติ

3. Static Diagram

จากภาพที่ 1 เราจะเห็นว่า UML แบ่งไดอะแกรมออกเป็น 2 ส่วนคือส่วนที่เป็น Static Diagram และ Dynamic Diagram ในหัวข้อนี้จะกล่าวถึงเฉพาะแต่ส่วนที่เป็น Static Diagram เท่านั้น ซึ่งสถาปนิกซอฟแวร์จะใช้ Static Diagram เพื่อออกแบบโครงสร้างของระบบงาน ใน Static Diagram จะมีไดอะแกรมอยู่ 4 ตัวคือ Class Diagram, Object Diagram, Component Diagram และ Deployment Diagram ที่ได้กล่าวถึงวัตถุประสงค์การใช้งานไว้แล้วในหัวข้อที่ 1.

สัญลักษณ์ส่วนใหญ่ที่ปรากฏอยู่ใน Class Diagram ซึ่งถือว่าเป็นหัวใจสำคัญสำหรับการออกแบบระบบที่เป็น Object-Oriented เนื่องจากระบบที่เป็น Object-Oriented จะประกอบด้วยวัตถุหลาย ๆ  ชนิดทำงานร่วมกัน เพื่อให้ได้ผลลัพธ์ตามเป้าหมายที่ Usecase ได้กำหนดไว้ ในเอกสารฉบับนี้จะไม่ได้เน้นแนวคิดของการออกแบบซอฟแวร์เชิงวัตถุ (ซึ่งได้กล่าวถึงไว้ในเอกสาร แนวคิดการออกแบบซอฟแวร์เชิงวัตถุ แล้ว) แต่จะเน้นไปที่ความหมายของสัญลักษณ์แต่ละตัวที่ใช้ใน Static Diagram เช่น สัญลักษณ์ของ Class สัญลักษณ์ของ Object และสัญลักษณ์อื่น ๆ  ที่จะกล่าวถึงอีกต่อไป

3.1 Class

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

รูปภาพ 16 สัญลักษณ์ของคลาส

ในภาพที่ 16 จะเห็นว่าเวลาที่วาดรูปคลาสใน UML จะใช้สี่เหลี่ยมและแบ่งคลาสออกเป็น 3 ส่วนคือ ส่วนบนสุดคือชื่อคลาส ส่วนตรงกลางเป็นที่วางของรายการแอททริบิวท์ และส่วนด้านล่างสุดเป็นที่วางของรายการเมธอด แม้ว่าเราจะเขียนคลาสให้ประกอบด้วยแอททริบิวท์และเมธอด แต่แท้ที่จริงแล้วแอททริบิวท์และเมธอดที่ปรากฏให้เห็นในคลาสจะเกิดขึ้นจริงก็ต่อเมื่อเรานำคลาสนี้ไปสร้างเป็นวัตถุ แล้วใช้งานวัตถุเท่านั้น ดังนั้นในภาษาโปรแกรมอย่างเช่น Java จึงเรียกแอททริบิวท์ว่า instance variable (ตัวแปรอินสแตนซ์) และเรียกส่วนที่เป็นเมธอดว่า instance method (อินสแตนซ์เมธอด)

รูปภาพ 17 ตัวอย่างการแสดงผลรายละเอียดของคลาสในแบบต่าง ๆ

จากภาพที่ 17 จะเห็นว่าในการวาดสัญลักษณ์คลาสใน UML อาจจะให้ปรากฏเฉพาะแค่เพียงบางส่วนก็ได้ เช่นในรูป d. จะซ่อน (Suppress) ส่วนที่เป็นแอททริบิวท์และเมธอดไว้เพื่อให้เห็นเฉพาะชื่อคลาส มักจะใช้แสดงผลในไดอะแกรมที่นำเสนอแต่ภาพรวม ในรูป c. จะแสดงผลเฉพาะรายการเมธอดและซ่อนส่วนที่เป็นแอททริบิวท์ไว้ ซึ่งมักจะแสดงผลในไดอะแกรมที่ต้องการให้ไคลเอ็นต์โค้ดเห็นเฉพาะ public interface ที่สามารถเรียกใช้งานได้ ในรูป b. จะแสดงผลเฉพาะรายการแอททริบิวท์ และซ่อนส่วนที่เป็นเมธอดไว้มักจะปรากฏในไดอะแกรมที่เตรียมไว้เพื่อแมปข้อมูลไปเก็บในฐานข้อมูล และในรูป a. เป็นการแสดงรายละเอียดทั้งหมดของคลาส ซึ่งมักจะแสดงไว้ใน Detailed Design Specification ที่พร้อมสำหรับให้โปรแกรมเมอร์นำไปเข้ารหัสโปรแกรม

จากประสบการณ์ในการออกแบบซอฟแวร์ เราอาจจะแบ่งคลาสออกได้ตามวัตถุประสงค์การใช้งาน หลายประเภท เช่น

1.    Domain Classs[4]                  เป็นคลาสที่ใช้สำหรับสร้าง Domain Object ที่จะใช้แทนวัตถุที่มีอยู่จริงในระบบ และเป็นของระบบงานนั้นเอง คลาสเหล่านี้มักจะมีหน้าที่เป็นตัวแทน (Representative) ให้กับคน วัตถุ สิ่งของ ที่มีอยู่ในโลกความจริง (Real-world) และมีอยู่ในระบบงานที่เรากำลังวิเคราะห์และออกแบบ คลาสเหล่านี้มักจะพบได้จากการวิเคราะห์ระบบ หรือวิเคราะห์ Problem Statement ที่ย่อยมาจากความต้องการของระบบอีกที ตัวอย่างของโดเมนคลาสในระบบส่งต่อผู้ป่วยเช่น คลาส Patient, Hospital, Card และ User

2.    Business Logic Class[5]       เป็นคลาสที่ใช้สำหรับสร้างวัตถุที่เป็น Business Object เพื่อให้รับผิดชอบดำเนินการตามขั้นตอนที่ระบบงานนั้น ๆ  ได้กำหนดเอาไว้ เช่นในระบบส่งต่อผู้ป่วย ขั้นตอนการบันทึกการส่งต่อผู้ป่วย อาจจะรับผิดชอบโดยวัตถุที่สร้างมาจากคลาสชื่อว่า PatientTransferManager ซึ่งจะทำหน้าที่ควบคุมการส่งต่อผู้ป่วยตั้งแต่ตอนเริ่มต้นจนกระทั่งเสร็จกระบวนการเลยก็ได้

3.    Presentation Class[6]            เป็นคลาสที่อยู่ที่ส่วนแสดงผล และส่วนที่ติดต่อกับผู้ใช้ (User Interface) คลาสเหล่านี้จะนำไปสร้างวัตถุที่ใช้สำหรับรับข้อมูลเข้า และใช้สำหรับแสดงผล ตัวอย่างของ Presentation Class ในระบบส่งต่อผู้ป่วยเช่นคลาสชื่อ PatientTransferForm ที่ใช้สำหรับเป็นแบบฟอร์มบันทึกข้อมูลผู้ป่วยส่งต่อ

รูปภาพ 18 ตัวอย่างการแยกประเภทคลาสเพื่อรับผิดชอบในกระบวนการส่งต่อผู้ป่วย

นอกจากประเภทคลาส 3 ประเภทดังที่กล่าวมาแล้วนี้ ยังมีวิธีการแบ่งประเภทคลาสที่หนังสืออีกหลายเล่มเกี่ยวกับการออกแบบเชิงวัตถุได้แบ่งประเภทเอาไว้

ตารางที่ 3 ตัวอย่างการแบ่งประเภทคลาสที่สถาปนิกซอฟแวร์ผู้มีประสบการณ์ได้เคยแนะนำไว้

วิธีการคิดแบบ	ประเภทคลาสที่เกิดขึ้น
MVC	Model, View, Controller
Peter Coad [UML In Color 2000]	Party or thing, Role, Moment-Interval, Catalog likes description
Enterprise JavaBeans	Entity Bean, Session Bean
Rumbaugh	Boundary, Controller, Entity

3.1.1 Attribute

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

ตัวอย่างของการออกแบบแอททริบิวท์ให้กับวัตถุ เช่น วัตถุผู้ป่วยในภาพที่ 17 จะประกอบด้วยแอททริบิวท์ id ที่ใช้สำหรับเก็บรหัสผู้ป่วย แอททริบิวท์ name ที่ใช้สำหรับเก็บชื่อ-นามสกุลผู้ป่วย แอททริบิวท์ personId ใช้สำหรับเก็บรหัสบัตรประจำตัวประชาชน แอททริบิวท์ age ใช้สำหรับเก็บอายุของผู้ป่วย แอททริบิวท์ sex ใช้สำหรับเก็บเพศของผู้ป่วย และแอททริบิวท์ occupation ใช้สำหรับเก็บอาชีพของผู้ป่วย

ใน UML จะมีรูปแบบในการเขียนแอททริบิวท์ ดังต่อไปนี้

[visibility] attribute-name [: type [ = default-value] ]

ความหมายของส่วนประกอบแต่ละส่วนในการเขียนแอททริบิวท์มีดังนี้

1.    visibility                           หมายถึงความสามารถในการมองเห็นตัวแอททริบิวท์นี้ว่าจะยอมให้มองเห็นและเรียกใช้งานได้จากตำแหน่งใดบ้าง ซึ่งจะมีสัญลักษณ์ได้ 3 อย่างดังนี้

                                               เครื่องหมาย –        หมายถึง private เป็นการกำหนดให้มองเห็นได้เฉพาะในคลาสเดียวกันนี้เท่านั้น

                                               เครื่องหมาย +       หมายถึง public เป็นการกำหนดให้มองเห็นได้จากทุกตำแหน่งในโปรแกรมซึ่งก็คือคลาสอื่นจะสามารถมองเห็นพวกที่เป็น public และสามารถเรียกใช้งานได้ด้วย

                                               เครื่องหมาย #        หมายถึง protected เป็นการกำหนดให้มองเห็นได้เฉพาะในคลาสเดียวกันนี้ และเฉพาะคลาสลูกที่สืบทอดต่อไปจากคลาสนี้เท่านั้น (ดูรายละเอียดในเรื่อง Inhertiance)

2.    attribute-name                คือชื่อของแอททริบิวท์ซึ่งเราอาจจะกำหนดให้มีชื่ออะไรก็ได้

3.    type                                 คือชนิดของแอททริบิว์ซึ่งอาจจะมีชนิดเป็น String (ตัวอักษร) หรือ integer (จำนวนเต็ม) หรือ double (เลขทศนิยมแบบความแม่นยำสองเท่า) หรือ float (เลขทศนิยมแบบความแม่นยำต่ำ) หรือ boolean (ค่าตรรก เป็นได้สองค่าจริงกับเท็จเท่านั้น) รวมทั้งสามารถเป็นชื่อคลาสหรือชื่ออินเตอร์เฟสที่เราได้ออกแบบไว้แล้วก็ได้ ในการกำหนดชนิดของแอททริบิวท์นี้มักจะไปลงรายละเอียดกันในระดับของ Detailed Design เมื่อได้ตกลงใจแล้วว่าจะใช้แพลตฟอร์มใดสำหรับพัฒนาระบบ

4.    default-value                   คือค่าดีฟอลต์ที่จะกำหนดให้กับแอททริบิวท์ตั้งแต่ตอนที่วัตถุถูกสร้างขึ้นครั้งแรกซึ่งอาจจะเป็นค่าอะไรก็ได้แล้วแต่ข้อกำหนดของระบบงาน ปกติแล้วมักจะไปใส่ในขั้น Detailed Design

ตัวอย่างของการเขียนแอททริบิวท์เช่น

 

รูปภาพ 19 ตัวอย่างการเขียนแอททริบิวท์ในรูปแบบต่าง ๆ

ในภาพที่ 19 เป็นตัวอย่างของการเขียนแอททริบิวท์ ให้กับคลาส Hospital ซึ่งสามารถอธิบายได้ดังนี้

1.    แอททริบิวท์ชื่อ id มี visibility เป็น private และมีชนิดข้อมูลเป็นตัวอักษร

2.    แอททริบิวท์ชื่อ name มี visibility เป็น protected และมีชนิดข้อมูลเป็นตัวอักษร

3.    แอททริบิวท์ชื่อ type มี visibility เป็น public และมีชนิดข้อมูลเป็นตัวอักษร และมีค่าดีฟอลต์เริ่มต้นเป็นคำว่า PROVINCE

4.    แอททริบิวท์ชื่อ provinceId มี visibility เป็น protected และมีชนิดข้อมูลเป็นตัวอักษร

5.    แอททริบิวท์ชื่อ province มี visibility เป็น private และมีชนิดข้อมูลเป็นคลาสชื่อ Province ซึ่งแสดงให้เห็นว่าตัวแปร province นี้ใช้สำหรับเป็นตัวแปรอ้างอิงเพื่อใช้อ้างอิงวัตถุ Province ได้

3.1.2 Method

เป็นส่วนพฤติกรรมของวัตถุ ในส่วนนี้จะบอกให้เรารู้ว่าวัตถุสามารถทำอะไรได้บ้าง ซึ่งการกระทำของวัตถุส่วนใหญ่จะถูกออกแบบให้กระทำกับข้อมูลที่เก็บอยู่ในตัววัตถุนั้นเอง ในขณะที่ไคลเอ็นต์โค้ดเรียกใช้ให้วัตถุทำงาน ไคลเอ็นต์จะต้องเรียกใช้เมธอด (Method Call) และผ่านค่าอาร์กิวเมนต์ใปให้ตามรายการพารามิเตอร์ที่เมธอดต้องการ เมื่อทำงานจนกระทั่งจบเมธอดแล้วเมธอดบางตัวอาจจะมีค่าที่ส่งคืนกลับมา (Return Value) เพื่อให้ไคลเอ็นต์โค้ดนำค่านั้นกลับไปใช้งานต่อก็ได้

ใน UML เราจะมีรูปแบบในการเขียนเมธอด ดังต่อไปนี้

[visibility] method-name([param-name : type, param-name : type, … ]) [ : return-type ]

ความหมายของส่วนประกอบแต่ละส่วนในการเขียนเมธอดมีดังนี้

1.    visibility                           หมายถึงความสามารถในการมองเห็นตัวเมธอดนี้ว่าจะยอมให้มองเห็นและเรียกใช้งานได้จากตำแหน่งใดบ้าง ซึ่งจะมีสัญลักษณ์ได้ 3 อย่างดังนี้

                                               เครื่องหมาย –        หมายถึง private เป็นการกำหนดให้มองเห็นได้เฉพาะในคลาสเดียวกันนี้เท่านั้น

                                               เครื่องหมาย +       หมายถึง public เป็นการกำหนดให้มองเห็นได้จากทุกตำแหน่งในโปรแกรมซึ่งก็คือคลาสอื่นจะสามารถมองเห็นพวกที่เป็น public และสามารถเรียกใช้งานได้ด้วย

                                               เครื่องหมาย #        หมายถึง protected เป็นการกำหนดให้มองเห็นได้เฉพาะในคลาสเดียวกันนี้ และเฉพาะคลาสลูกที่สืบทอดต่อไปจากคลาสนี้เท่านั้น (ดูรายละเอียดในเรื่อง Inhertiance)

2.    method-name                 คือชื่อของเมธอดซึ่งเราอาจจะกำหนดให้มีชื่ออะไรก็ได้

3.    param-name                   คือชื่อของพารามิเตอร์ซึ่งเราอาจจะกำหนดให้มีชื่ออะไรก็ได้แต่จะต้องไม่ไปซ้ำกับชื่อพารามิเตอร์ตัวอื่นที่อยู่ในวงเล็บเดียวกันนี้

4.    param-type                     คือชนิดข้อมูลของพารามิเตอร์

5.    return-type                      คือชนิดของค่าส่งคืน ว่าค่าที่ได้กลับมาเมื่อทำงานจนจบเมธอดแล้วจะมีชนิดข้อมูลเป็นชนิดอะไร ซึ่งอาจจะเป็น String, integer, double หรือ อื่น ๆ  ดังที่ได้กล่าวมาแล้ว

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

รูปภาพ 20 ตัวอย่างการเขียนเมธอดแบบต่าง ๆ

จากภาพที่ 20 แสดงให้เห็นวิธีการเขียนเมธอดแบบต่าง ๆ  ซึ่งสามารถอธิบายได้ดังนี้

1.    เมธอดชื่อ transferPatient มี visibility เป็น public และรับพารามิเตอร์ 2 ตัวคือ user มีชนิดข้อมูลเป็น User และ form มีชนิดข้อมูลเป็น PatientTransferForm เมื่อทำงานจนจบเมธอดแล้วจะส่งคืนค่ากลับมาเป็น boolean ซึ่งจะมีค่าเป็น true หรือ false

2.    เมธอดชื่อ transferPatient มี visibility เป็น private และรับพารามิเตอร์ 1 ตัวคือ form มีชนิดข้อมูลเป็น PatientTransferForm เมธอดนี้ไม่มีค่าส่งคืน

3.    เมธอดชื่อ isValidUser มี visibility เป็น public และรับพารามิเตอร์ 2 ตัวคือ username มีชนิดข้อมูลเป็นตัวอักษร และพารามิเตอร์ชื่อ password มีชนิดข้อมูลเป็นตัวอักษรเช่นเดียวกัน เมื่อเมธอดนี้ทำงานจนจบจะได้ค่าส่งคืนกลับมามีชนิดข้อมูลเป็นวัตถุ User

4.    เมธอดชื่อ getUser มี visibility เป็น protected และรับพารามิเตอร์ตัวเดียวคือ username มีชนิดข้อมูลเป็นตัวอักษร และเมื่อทำงานจนจบเมธอดจะได้ค่าส่งคืนกลับมามีชนิดข้อมูลเป็นวัตถุ User

3.2 Object

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

รูปภาพ 21 ตัวอย่างของวัตถุที่ถูกสร้างขึ้นจากคลาส Patient

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

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

รูปภาพ 22 ตัวอย่างการเขียนวัตถุแบบย่อ

ภาพที่ 22 แสดงให้เห็นว่าเราสามารถเขียนภาพวัตถุได้หลายแบบ แบบ Full details เป็นแบบที่เราแสดงรายละเอียดของวัตถุครบทั้งหมด คือมีรายการแอททริบิวท์และค่าของแอททริบิวท์แต่ละตัวด้วย สำหรับแบบ Short-form เราจะแสดงเฉพาะชื่อตัวแปรอ้างอิงและชนิดของวัตถุ และแบบที่เราไม่แสดงชื่อตัวแปรอ้างอิงแต่จะต้องแสดงชนิดของวัตถุไว้ด้วยเสมอ แบบนี้เราเรียกว่า Anonymous Object ทั้งสองแบบหลังเป็นการเขียนวัตถุแบบย่อ ซึ่งมักจะปรากฏให้เห็นใน Sequence Diagram และ Collaboration Diagram

3.3 Association

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

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

รูปภาพ 23 ตัวอย่าง Association ที่เกิดขึ้นกับวัตถุ Hospital และ Patient

ในภาพที่ 23 เราจะเห็นว่าความสัมพันธ์ที่เกิดกับวัตถุ h1 และ a คือ h1 เป็นวัตถุ Hospital และ a เป็นวัตถุ Patient โดยวัตถุ h1 ส่งวัตถุ a ไปให้วัตถุ h2 รับไปรักษาต่อ

รูปภาพ 24 ตัวอย่างความสัมพันธ์ระหว่างวัตถุ Hospital และวัตถุ Patient แต่เขียนในรูปคลาส

ในภาพที่ 24 เป็นภาพใน Class Diagram ที่ลากเส้นเชื่อมโยงระหว่างคลาส Hospital และคลาส Patient

เนื่องจากวัตถุ Hospital และวัตถุ Patient มีความสัมพันธ์กันดังที่ปรากฏในภาพที่ 23

เรื่องของความสัมพันธ์ระหว่างวัตถุมีรายละเอียดปลีกย่อยอีกมากมาย ซึ่งจะขอกล่าวถึงในหัวข้อต่อไปนี้

3.3.1 Association Name

Associtation Name คือชื่อที่เรากำกับไว้บนเส้น Assocation เพื่อแสดงให้เห็นว่าวัตถุทั้งสองตัวนี้สัมพันธ์กันด้วยการกระทำอะไร ดังนั้น ส่วนใหญ่แล้วเราจึงตั้งชื่อ Association Name ให้ขึ้นต้นด้วยคำกริยา (Verb) และเวลาที่อ่านจะมีหัวลูกศรกำกับไว้ว่าให้อ่านจากวัตถุฝั่งไหนไปที่ฝั่งไหน ตัวอย่างของ Association Name เช่นในภาพที่ 24 เราจะเห็นว่าวัตถุ Patient ทำความสัมพันธ์กับวัตถุ Hospital โดยเหตุผลที่มากระทำกันก็คือ วัตถุ Hospital ส่ง (Send) วัตถุ Patient ต่อไปให้อีกที่หนึ่ง และวัตถุ Hospital อีกตัวหนึ่งรับ (Receive) วัตถุ Patient ไว้รักษาพยาบาลต่อไป ถ้าไม่มีหัวลูกศรกำกับทิศทางการอ่าน ปกติแล้วเราจะอ่านจากซ้ายไปขวาและบนลงล่าง

บางครั้งการใส่ไว้แค่ Association Name อาจจะไม่ทำให้ความสัมพันธ์ชัดเจนหรือเข้าใจง่ายเพียงพอ

รูปภาพ 25 แม้ว่าจะใส่ Association Name ให้แล้วแต่ความหมายยังไม่ชัดเจน

ตัวอย่างในภาพที่ 25 จะเห็นความสัมพันธ์ที่เกิดจากวัตถุ Person มาสัมพันธ์กันโดยวัตถุ Person มาแต่งงาน (marries) กับวัตถุ Person อีกคนหนึ่ง จากภาพแม่ว่าเราจะใส่ Association Name ให้แล้วก็ตามแต่รายละเอียดอื่น ๆ  ก็ยังคงเป็นข้อสงสัย เช่น เราไม่รู้ว่า Person คนไหนที่เป็น สามี (Husband) และ Person คนไหนที่เป็น ภรรยา (Wife) เป็นต้น ซึ่งปัญหาดังกล่าวนี้เราจะกล่าวถึงในเรื่อง Role Name ต่อไป

3.3.2 Role Name

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

รูปภาพ 26 ตัวอย่างการใส่ Role Name เพื่อให้ความสัมพันธ์ชัดเจนขึ้น

ในภาพที่ 26a เป็นตัวอย่างการใส่ Role Name ให้กับความสัมพันธ์ระหว่างวัตถุ Hospital และวัตถุ Patient เมื่อวัตถุ Hospital ส่งวัตถุ Patient ออกไปจะรับบทบาทเป็น sender และตัว Patient จะรับบทบาทเป็น sent patient (ผู้ป่วยที่ถูกส่งต่อ) สำหรับเส้นล่างเมื่อวัตถุ Hospital รับวัตถุ Patient เข้ามารักษาพยาบาลต่อ วัตถุ Hospital จะรับบทบาทเป็น receiver (ผู้รับ) และวัตถุ Patient จะรับบทบาทเป็น received patient (ผู้ป่วยที่ถูกรับเข้า) ในภาพ 26a นี้จะเห็นว่าเป็นการใช้ Role Name ที่ฟุ่มเฟือยและไม่จำเป็นต้องใส่เนื่องจาก แม้ว่าจะไม่ใส่ Role Name ลำพังแค่ Association Name ก็ทำให้ผู้อ่านไดอะแกรมเข้าใจได้อยู่แล้ว แต่อย่างไรก็ตาม จะมีบางครั้งที่เราจะต้องใส่ Role Name ด้วยจึงจะทำให้ผู้อ่านไดอะแกรมเข้าใจได้ดียิ่งขึ้น เช่น ในภาพ 26b ถ้าเราใส่ Role Name เข้าไป เราจะสามารถอ่านได้ว่าวัตถุ Person หนึ่งคนรับบทบาทเป็น สามี (husband) แต่งงานกับวัตถุ Person อีกหนึ่งคนที่รับบทบาทเป็นภรรยา (Wife)

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

รูปภาพ 27 ตัวอย่างการนำ Role Name ไปตั้งเป็นชื่อแอททริบิวท์และเมธอด

3.3.3 Multiplicity

เมื่อวัตถุมาทำความสัมพันธ์ เราสามารถนับจำนวนได้ว่าวัตถุทำความสัมพันธ์กันอยู่ด้วยจำนวนเท่าไรต่อเท่าไร เราเรียกจำนวนของวัตถุที่เกิดความสัมพันธ์กันขึ้นนี้ว่า Multiplicity

รูปภาพ 28 ความสัมพันธ์ระหว่างวัตถุในระบบสั่งจองตั๋วเครื่องบิน

ในภาพที่ 28 แสดงให้เห็นความสัมพันธ์ระหว่างวัตถุที่อยู่ในระบบสั่งจองตั๋วเครื่องบิน เราจะเห็นว่าวัตถุ Flight 1 ตัวสามารถเกี่ยวข้องกับวัตถุ Seat อีก 3 ตัว แต่เมื่อวิเคราะห์ให้ดีแล้วเราอาจจะได้ว่า วัตถุ Flight 1 ตัวสามารถเกี่ยวข้องวัตถุ Seat ได้หลายตัว

รูปภาพ 29 ตัวอย่างของ Multiplicity ที่เกิดจากการวิเคราะห์ภาพที่ 28

เวลาที่เราอ่าน Multiplicity เราสามารถอ่านได้ 2 ทิศทางคืออ่านจากซ้ายไปขวาหรืออ่านจากขวาไปซ้าย เช่นในภาพที่ 29 เราอ่านจากซ้ายไปขวาได้ว่า วัตถุ Flight หนึ่งตัวสัมพันธ์กับวัตถุ Seat อีกหลาย ๆ  ตัว และเมื่ออ่านจากขวามาซ้ายจะได้ความหมายว่า วัตถุ Seat หนึ่งตัวสัมพันธ์กับวัตถุ Flight เพียงตัวเดียว ซึ่งเราจะได้หลักการอ่าน Multiplicity ก็คือถ้าเริ่มอ่านจากด้านไหนให้นับด้านนั้นเป็น 1 เสมอ (เพราะในความเป็นจริง เป็นความสัมพันธ์ระหว่างวัตถุ ไม่ใช้ความสัมพันธ์ระหว่างคลาส แต่นำมาเขียนอยู่ใน Class Diagram เท่านั้น)

จำนวนนับสามารถเขียนได้หลายแบบ เช่น

0..1	เกิดความสัมพันธ์หรือไม่เกิดก็ได้
1	ต้องเกิดความสัมพันธ์กับวัตถุหนึ่งตัวเท่านั้น
0..*	เกิดความสัมพันธ์กับวัตถุหรือไม่เกิดก็ได้ และสามารถเกิดความสัมพันธ์กับวัตถุกี่ตัวก็ได้
1..*	เกิดความสัมพันธ์กับวัตถุตั้งแต่หนึ่งตัวขึ้นไป ถึงกี่ตัวก็ได้
*	เหมือนกับ 0..*
1, 2, 4	ถ้าเกิดความสัมพันธ์ต้องเกิดกับวัตถุ 1 ตัว 2 ตัวหรือกับ 4 ตัวเท่านั้น

3.3.4 Navigatability

ทิศทางของความสัมพันธ์มีอยู่ 2 แบบคือ แบบทิศทางเดียว (Uni-Direction) หรือแบบสองทิศทาง (Bi-Direction)

รูปภาพ 30 ตัวอย่างการใช้ Navigatability จาก Patient มาที่ Hospital

จากภาพที่ 30 เราจะเขียนเส้น Association ที่มีทิศทาง ให้มีหัวลูกศรชี้ไปทางใดสักทางหนึ่ง จากภาพหมายความว่าวัตถุ Patient สามารถเชื่อมโยงมาที่วัตถุ Hospital ได้ (สังเกตแอททริบิวท์ sender, receiver และเมธอด getSenderHospital, getReceiverHospital ที่เก็บอยู่ในวัตถุ Patient) แต่ในทางกลับกัน วัตถุ Hospital ไม่สามารถเชื่อมโยงไปที่วัตถุ Patient ได้

3.3.5 Aggregation

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

รูปภาพ 31 ตัวอย่างการใช้ Aggregation

เส้น Aggregation จะแสดงให้เห็นเป็นรูปสี่เหลี่ยมข้าวหลามตัด (Diamond) โดยชี้จากด้าน Diamond ไปที่อีกด้านหนึ่ง ด้านที่หัว Diamond ติดอยู่ก็คือด้านที่เป็นวัตถุรวม (Whole) ที่ประกอบด้วยวัตถุที่ด้าน Part of ที่เป็นวัตถุชิ้นส่วนย่อยที่ประกอบอยู่ในวัตถุรวม

เมื่อเราเขียนความสัมพันธ์แบบ Aggregation แล้วมักจะไม่จำเป็นต้องเขียน Association Name บอกไว้อีกแล้วเนื่องจากถือว่าผู้อ่านจะต้องแปลความหมายได้ทันทีว่าหมายถึงการ "ประกอบด้วย"

3.3.6 Composition

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

รูปภาพ 32 ตัวอย่างการใช้งาน Composition

วิธีการเขียน Composition จะแสดงเป็นรูป Diamond เหมือนกับใน Aggregation แต่จะใช้เป็นสีดำทึบ

3.3.7 Association Class

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

รูปภาพ 33 แสดงการใช้ Association Class และ Association Object

จากภาพที่ 33 จะเห็นว่าทุกครั้งที่วัตถุ Student มาสัมพันธ์กับวัตถุ Course จะทำให้เกิดเป็นวัตถุ Transcript เช่นวัตถุ a เป็นนักเรียนชื่อสมชายขณะที่ ยังไม่ได้ไปสัมพันธ์กับวัตถุ Course ก็จะไม่มีวัตถุ Transcript เกิดขึ้น แต่เมื่อไปทำความสัมพันธ์กับวัตถุ Course ชื่อ Object-Oriented จะทำให้เกิดเป็นวัตถุ Transcript ซึ่งใช้สำหรับเก็บผลการสอบ

3.4 Inheritance

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

เหตุผลที่เรากำหนดให้คลาสลูกไปสืบทอดต่อจากคลาสแม่ มีทั้ง 2 มุมมองคือ

1.    มุมมองโปรแกรมเมอร์   คลาสลูกจะได้ความสามารถของคลาสแม่ติดมาด้วยทำให้ไม่ต้องเขียนโปรแกรมซ้ำกับที่เคยเขียนไว้แล้วในคลาสแม่

2.    มุมมองสถาปนิก           คลาสลูกสมควรสืบทอดจากคลาสแม่เนื่องจากเป็นคลาสชนิดเดียวกัน (อยู่ในตระกูลเดียวกัน) วิธีการมองแบบนี้ เราสามารถอ่านได้คำว่า "is a" หรือภาษาไทยก็คือ "เป็น" เช่นถ้าบอกว่าคลาส Car สืบทอดต่อจาก Vehicle (ยานพาหนะ) เรากล่าวได้ว่า "Car is a Vehicle" (รถยนต์เป็นยานพาหนะ)

รูปภาพ 34 การใช้เส้น Generalization เพื่อแสดง Inheritance ระหว่างคลาสลูกและคลาสแม่

จากภาพที่ 24 จะเห็นว่าใน UML จะใช้เส้น Generalization ที่มีลักษณะหัวลูกศรสามเหลี่ยนโปร่งใส โดยใช้ลูกศรนี้ชี้ไปที่คลาสที่เป็นคลาสแม่ ซึ่งมีความเป็นลักษณะทั่วไปมากกว่าคลาสลูกที่พิเศษกว่า ตัวอย่างในภาพที่ 34 คลาสแม่คือยานพาหนะและคลาสลูกที่เป็นรถยนต์จะมีแอททริบิวท์ color และ weight และเมธอด move ที่ได้มาจากคลาสแม่ รวมกับแอททริบิวท์ wheels (ล้อรถ) และเมธอด fillFuel (เติมน้ำมัน) ที่เป็นของคลาส Car เอง สำหรับคลาสลูก Boat ก็จะสืบทอดจากคลาส Vehicle ดังนั้นจะมีคุณสมบัติของคลาส Vehicle รวมกับแอททริบิวท์ tail ที่เป็นของตัวเองด้วย

3.5 Abstract Class

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

รูปภาพ 35 ตัวอย่างของ Abstract Class และ Abstract Method

จากภาพที่ 35 จะเห็นว่าเราออกแบบให้คลาส Vehicle เป็น Abstract Class เนื่องจากเราไม่ต้องการให้ไคลเอ็นโค้ดนำคลาส Vehicle ไปสร้างเป็นวัตถุ ถ้าไคลเอ็นต์โค้ดต้องการคลาสวัตถุจะต้องสร้างจากคลาส Car หรือคลาส Boat ที่เป็นคลาสลูก ให้สังเกตเมธอด move ที่อยู่ในคลาส Vehicle จะเขียนเป็นตัวเอน แสดงให้เห็นว่าเป็น Abstract Method พวกที่เป็น Abstract Method นี้จะเป็นเมธอดที่ไม่มีการทำงานอยู่ข้างใน แต่เป็นเมธอดเปล่า ๆ  ที่มีเฉพาะโครงสร้างการประกาศเมธอดเท่านั้น คลาสลูกที่สืบทอดต่อไปจาก Abstract Class จะต้องเขียนการทำงานให้กับ Abstract Method ให้สมบูรณ์ ที่เมธอด move ในคลาส Vehicle เป็น Abstract Method ก็เนื่องจากเราไม่สามารถตัดสินใจได้ว่ากระบวนการเคลื่อนที่ในคลาส Vehicle จะเป็นอย่างไรเนื่องจากเราไม่รู้ว่าเป็นการเคลื่อนแบบรถหรือการเคลื่อนที่แบบเรือ จึงต้องทิ้งไว้เมธอด move นี้ไว้เป็น Abstract Method ก่อน

3.6 Interface

ใช้สำหรับเชื่อมต่อระหว่างคลาสที่เป็นผู้เรียกใช้ (Client Code) กับคลาสที่เป็นผู้ทำงานให้ (Implementation Code) ภายในอินเตอร์เฟสจะมีแต่โครงสร้างเมธอด โดยไม่มีการทำงานภายในเมธอด ดังนั้นเราจะคิดว่าอินเตอร์เฟสเป็น Abstract Class ที่ภายในมีแต่ Abstract Method ก็ได้

รูปภาพ 36 ตัวอย่างการใช้ interface

จากภาพที่ 36 เรากำหนดให้มีอินเตอร์เฟสชื่อว่า Service ซึ่งใช้ในความหมายว่าอะไรก็ตามที่เป็น Service แล้วจะต้องมีความสามารถ 3 อย่างคือ start (สามารถสั่งให้เริ่มทำงานได้) stop (สามารถสั่งให้หยุดทำงานได้) และ getStatus (สามารถสอบถามสถานะของงานที่กำลังทำอยู่ในปัจจุบันได้) ที่วัตถุ ServiceManager จะเป็นผู้ที่ควบคุมวัตถุ Service ทั้งหมดที่อยู่ในระบบ โดยเก็บรายการว่าในระบบมี Service อะไรอยู่บ้าง ดังนั้นใน ServiceManager จะสามารถรับ Service ไปเก็บไว้ในรายการได้โดยเรียกใช้เมธอด addService (ให้สังเกตว่าเมธอด addService รับอาร์กิวเมนต์มีชนิดข้อมูลเป็น Service) สมมุติว่าในระบบของเรามีบริการ 4 อย่างคือ Database, FileSystem, Telnet และ Web โดยทั้ง 4 คลาสนี้อิมพลีเมนต์มาจากอินเตอร์เฟส Service ทั้งสี่คลาสนี้จะต้องมีเมธอด start, stop และ getStatus พร้อมกับมีการทำงานอยู่ภายในเมธอดเหล่านี้ด้วย เมื่อทั้ง 4 คลาสนี้อิมพลีเมนต์มาจากอินเตอร์เฟส Service เราจะถือว่ามันเป็น Service ด้วยและวัตถุที่เกิดจากคลาสทั้ง 4 นี้จะสามารถใส่ให้กับเมธอด addService ในวัตถุ ServiceManager ได้ด้วย

3.7 Implementation

จากในภาพที่ 36 เราจะเห็นเส้น Implementation (ซึ่งบางครั้งเรียกว่า Realization หรือ Refinement) ชี้จากคลาสที่รับงานมาทำไปที่อินเตอร์เฟสที่เป็นผู้กำหนดงาน เส้น Implementation นี้จะชี้จากคลาสไปที่อินเตอร์เฟสเสมอ

รูปภาพ 37 ตัวอย่างการวาด Interface แบบย่อ

เราสามารถวาดอินเตอร์เฟสเป็นรูปวงกลมก็ได้ ซึ่งเป็นสัญลักษณ์ย่อของอินเตอร์เฟส เช่นปรากฏในภาพ 37

รูปภาพ 38 ตัวอย่างการสร้างคลาสอิมพลีเมนต์จากอินเตอร์เฟสมากกว่า 1 ตัว

ในภาพที่ 38 แสดงให้เห็นว่าคลาส Superman อิมพลีเมนต์จากอินเตอร์เฟส Runnable และ Flyable ดังนั้นคลาส Superman จะต้องมีการทำงานให้กับเมธอด run และ fly ครบทั้งคู่

3.8 Dependency

เป็นเส้นที่แสดงให้เห็นว่าวัตถุจำเป็นต้องอาศัยวัตถุอีกชิ้นหนึ่งในการทำงานร่วมด้วย

รูปภาพ 39 แสดงการใช้งาน Dependency

จากภาพที่ 39 จะเห็นเส้นประลากจาก PatientTransferManager ไปที่คลาส Patient ซึ่งบอกให้ทราบว่าคลาส PatientTransferManager มีการทำงานบางอย่างที่ต้องอาศัยคลาส Patient ร่วมด้วย ทำให้เวลาที่จะสร้างคลาส PatientTransferManager ให้เส็จสมบูรณ์จำเป็นต้องสร้างคลาส Patient มาก่อน

3.9 Package

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

รูปภาพ 40 ตัวอย่างการใช้งานแพคเกจ

ในภาพที่ 40 จะเห็นว่าเราแยกคลาสออกเป็น 3 แพคเกจคือ Domain, Presentation และ System และในแต่ละแพคเกจก็จะมีคลาสที่ทำงานในเรื่องนั้น ใน UML จะใช้สัญลักษณ์โฟลเดอร์ (Folder) แทนตัวแพคเกจ และแพคเกจสามารถมีแพคเกจซ้อนอยู่ข้างในลึกไปเรื่อย ๆ  กี่ชั้นก็ได้

3.10 Component

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

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

รูปภาพ 41 ตัวอย่างการใช้สัญลักษณ์ Component และ Dependency

จากภาพที่ 41 เราจะเห็นว่ามีคอมโพเนนท์อยู่ 3 ตัวคือ Patient, Hospital และ TransferManager โดยคอมโพเนนท์ TransferManager จะต้องใช้คอมโพเนนท์ Patient และ Hospital ทำงานร่วมกันด้วย

3.11 Node

โหนดหมายถึงหน่วยประมวลผลที่สามารถใช้สำหรับรันคอมโพเนนท์ ซึ่งอาจจะหมายถึงเครื่องคอมพิวเตอร์ที่ใช้เป็นเครื่องเซิร์ฟเวอร์ หรือ เครื่องเทอร์มินอลต์อย่างเช่นเครื่องคอมพิวเตอร์ PC หรือโทรศัพท์มือถือในยุค 3G อย่างปัจจุบันก็ได้ เมื่อเราสร้างคอมโพเนนท์แล้วเราจะต้องนำคอมโพเนนท์ไปวางให้รันอยู่บนโหนดเราเรียกกระบวนการนำคอมโพเนนท์ไปใส่ไว้ในโหนดว่า Deployment

รูปภาพ 42 ตัวอย่างการใช้สัญลักษณ์ Node ใน Deployment Diagram

จากภาพที่ 42 จะเห็นว่าเราแบ่งเครื่องเซิร์ฟเวอร์ออกเป็นสองตัวคือเครื่อง Application Server ที่ใช้สำหรับรันคอมโพเนนท์ Patient, Hospital และ TransferManager แล้วจะมีเครื่องเซิร์ฟเวอร์อีกเครื่องทำหน้าที่เป็น Web Server สำหรับรันคอมโพเนนท์ PatientTransferForm

3.12 สรุปสัญลักษณ์ที่ใช้ใน Static Diagram

ชื่อสัญลักษณ์	รูปสัญลักษณ์	ความหมายอย่างย่อ
Class		คลาสใช้สำหรับเป็นแม่แบบให้กับวัตถุ
Object		เป็นหน่วยรวมของข้อมูลและพฤติกรรม อาจจะหมายถึงวัตถุในโลกความจริง (Real-world) เช่น คน สิ่งของ หรือหมายถึงวัตถุในจินตนาการที่สมมุติให้ทำงานบางอย่างให้กับระบบ
Association		ความสัมพันธ์ระหว่างวัตถุ
Aggregation		ความสัมพันธ์แบบประกอบส่วน
Composition		ความสัมพันธ์แบบประกอบติด
Association with Navigatability		ความสัมพันธ์แบบทิศทางเดียว
Attribute	visibility name:type=default_value	รูปแบบของการเขียนแอททริบิวท์
Method	visibility name(parameter:type, parameter:type, ….):return_type	รูปแบบของการเขียนเมธอด
Generalization		สร้างคลาสลูกสืบทอดจากคลาสแม่
Implementation		สร้างคลาสอิมพลีเมนต์จากอินเตอร์เฟส
Interface		ข้อกำหนดระหว่างไคลเอ็นต์โค้ดและอิมพลีเมนต์โค้ด
Dependency		คลาสที่ขึ้นอยู่คลาสอีกคลาสหนึ่ง
Component		ชิ้นส่วนของซอฟแวร์ที่ออกแบบมาให้ทำหน้าที่อย่างใดอย่างหนึ่งและสามารถเชื่อมต่อเข้ากับระบบงานได้โดยใช้ข้อกำหนดที่ชัดเจน
Node		หน่วยประมวลผลที่ใช้สำหรับรันคอมโพเนนท์

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

4. Dynamic Diagram

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

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

1.    Class Scope Delegation        หมายถึง การแบ่งงานให้คลาสลูกมารับไปทำแทน ลักษณะแบบนี้เกิดขึ้นเนื่องจากที่คลาสแม่ไม่ต้องการระบุวิธีการทำงานให้ชัดเจนลงไปเนื่องจากจะทำให้ระบบมีโครงสร้างที่ไม่ยืดหยุ่นเพียงพอ จึงทิ้งงานบางอย่างที่เป็นเรื่องจำเพาะเจาะจงไว้ให้กับคลาสลูกที่มาสืบทอดต่อไป รับหน้าที่ไปทำต่อ (ดูที่ Abstract Class ในหัวข้อ 3.)

2.    Object Scope Delegation      หมายถึง การแบ่งงานให้กับวัตถุอื่นมารับไปทำแทน ส่วนใหญ่แล้วเป็นวัตถุจากคลาสอีกคลาสหนึ่งที่มีความสามารถในเรื่องนั้น ๆ ตัวอย่าง เช่นการบันทึกข้อมูลลงไปที่ฐานข้อมูลไม่ใช่ความสามารถของวัตถุ Patient ดังนั้นวัตถุ Patient จะแยกงานการบันทึกข้อมูลให้กับวัตถุ PatientDB รับผิดชอบไปทำแทน เป็นต้น บางครั้งเราเรียกคลาสที่มารับผิดชอบงานย่อย ๆ  ไปทำแทนว่าเป็น Servant Class (คลาสผู้รับใช้)

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

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

รูปภาพ 43 สัญลักษณ์ที่ใช้ใน Sequence Diagram

ในภาพที่ 43 จะเห็นว่ามีสัญลักษณ์หลายรูปที่ปรากฏอยู่ใน Sequence Diagram ซึ่งเราจะได้อธิบายถึงความหมายของสัญลักษณ์ในหัวข้อต่อไป

4.1 Message

เมื่อเราต้องการสั่งงานวัตถุให้ทำงาน เราจะเรียกว่าเป็นการส่งเมสเสจ (Message) ไปแจ้งให้วัตถุทำงานบางอย่างให้ การส่งเมสเสจเป็นภาษาทาง Object-Oriented และใน UML จะใช้เส้นลูกศรชี้จากวัตถุผู้สั่งงาน ไปที่วัตถุที่ทำงานให้

รูปภาพ 44 แสดงการส่งเมสเสจเพื่อขอให้วัตถุทำงานให้

จากภาพที่ 44 จะเห็นว่าเราเขียนเส้นโยงจากวัตถุที่เป็นผู้สั่งงานไปที่วัตถุที่ทำงานให้ เส้นนี้เราเรียกว่าเมสเสจ และเมื่อแปลงให้กลายเป็น Detailed Design เมสเสจก็คือเมธอดที่ทำโดยคลาสที่รับเมสเสจ เรามีเมสเสจอยู่ 2 แบบคือ Synchronous Message หมายถึงเมสเสจที่ผู้ส่ง ส่งไปแล้วจะต้องรอรับผลลัพธ์กลับมาทันที และ Asynchronous Message คือเมสเสจที่ผู้ส่ง ส่งไปแล้วไม่จำเป็นต้องรอรับผลลัพธ์กลับมา และทางวัตถุผู้ส่งเมสเสจหลังจากส่ง Asynchronous Message แล้วสามารถทำงานอย่างอื่นต่อไปได้เลยทันที

4.1.1 Synchronous Message

เป็นเมสเสจที่ส่งไปแล้ว ผู้ส่งต้องรอรับผลลัพธ์กลับมาด้วย ถ้าวัตถุที่รับงานไปทำยังทำงานไม่เสร็จวัตถุที่เป็นผู้ส่งไม่มีสิทธิ์ไปทำงานอื่นก่อน (Block-Waiting) ตัวอย่างของการส่งเมสเสจประเภทนี้ในชีวิตประจำวันเช่นการโทรศัพท์เวลาที่เราโทรไปเพื่อต้องการคุยกับอีกคนหนึ่ง เราจะต้องรอจนกว่าคนที่เราต้องการคุยด้วยมารับสายและระหว่างพูดคุยโทรศัพท์เราจะต้องจับจังหวะ (โดยการใช้คำว่า ฮัลโหล) อยู่กับผู้พูดที่ปลายทางตลอดเวลา

ในทางโปรแกรมการส่งเมสเสจแบบ Synchronous ก็คือการเรียกใช้เมธอดภายใน Thread เดียวกัน หรือถ้าเป็นการเรียกใช้เมธอดแบบข้าม Thread ก็จะต้องมีกระบวน Thread Synchronization เพื่อให้ Thread ผู้เรียกใช้หยุดรอจนกว่า Thread ที่ทำงานให้ (Worker Thread) ทำงานจนเสร็จก่อนแล้วจึงจะสามารถทำงานอย่างอื่นต่อไปได้

รูปภาพ 45 ตัวอย่างของเส้น Synchronous Message

ในภาพที่ 45 UML จะแสดงเส้น Synchronous Message ด้วยลูกศรหัวดำทึบ ซึ่งจะแตกต่างจากเส้นเมสเสจในภาพที่ 44 เส้นเมสเสจในภาพที่ 44 ไม่มีลูกศรหัวทึบซึ่งบอกให้ทราบว่าเป็นเส้นที่ยังไม่ได้กำหนด (Unspecify) ว่าจะให้เป็นแบบ Synchronous หรือ Asynchronous มักจะพบในขั้นตอน Conceptual Design ที่รายละเอียดของระบบงานยังไม่ชัดเจน

4.1.2 Asynchronous Message

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

หรืออาจจะเปรียบเทียบกับเมสเสจที่ส่งไปด้วยโทรศัพท์มือถือ (Short-Message) ก็เป็นลักษณะของ Asynchronous Message เช่นเดียวกัน โดยผู้ส่งเมสเสจส่งไปแล้วไม่จำเป็นต้องรอผลลัพธ์อะไร ทางฝั่งผู้รับจะรับเมสเสจไปแล้วตัดสินใจเองว่าจะทำอะไรต่อจากนั้น

รูปภาพ 46 ตัวอย่างของเส้น Asynchronous Message

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

ใน UML ใช้เครื่องหมายลูกศรสีดำครึ่งหัว เพื่อบอกให้ทราบว่าเป็นเมสเสจแบบ Asynchronous Message ดังเช่นปรากฏในภาพที่ 46

4.2 Object Life Line

เป็นเส้นประที่ลากจากข้างใต้รูปวัตถุ เพื่อบอกให้รู้ว่าวัตถุยังมีชีวิตอยู่ คำว่ามีชีวิตหมายความว่าวัตถุยังคงอยู่ในระบบสามารถใช้งานได้ ในความเป็นจริงวัตถุอาจจะไม่ได้เริ่มต้นมีขึ้นตั้งแต่ตอนที่เปิดใช้ระบบงานก็ได้ (เนื่องจากจะสิ้นเปลืองหน่วยความจำมาก ถ้าต้องค้างวัตถุทั้งหมดไว้ในหน่วยความจำของเครื่องเซิร์ฟเวอร์) แต่ในการออกแบบแล้วเราอาจจะสมมุติว่าวัตถุมีใช้งานได้ตลอดเวลาที่เปิดระบบอยู่ เราจึงเห็นว่าวัตถุส่วนใหญ่จะปรากฏอยู่ที่ด้านบนของ Sequence Diagram แล้วมีเส้น Life-Line ลากยาวลงมาจนกระทั่งบรรจบด้านล่าง

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

รูปภาพ 47 ตัวอย่างของเส้นเมสเสจที่ส่งมาเพื่อสร้างวัตถุ

จากภาพที่ 47 ให้สังเกตว่าวัตถุ somchai ไม่ได้เกิดขึ้นตั้งแต่ตอนแรกที่เปิดระบบ แต่จะเกิดขึ้นเมื่อวัตถุ System สั่ง createUser ที่ตัววัตถุ UserManager และวัตถุ UserManager จะสร้างวัตถุ User ขึ้นโดยใช้ตัวแปรอ้างอิงชื่อว่า somchai หลังจากสร้างวัตถุ somchai ขึ้นแล้ว จึงเริ่มแสดงเส้น Life-Line ตั้งแต่ ณ จุดที่วัตถุถูกสร้างขึ้น

หรือบางครั้งเส้น Life-Line อาจจะขาดหายไปเมื่อวัตถุถูกทำลายทิ้งจากระบบแล้วก็ได้ เช่น ที่ปรากฏให้เห็นในภาพที่ 48

รูปภาพ 48 ตัวอย่างการใช้ Destroy Message และการตัด Life-Line ของวัตถุ

จากภาพที่ 48 จะเห็นว่าเมื่อวัตถุ UserManager สั่ง remove ไปที่วัตถุ User จะทำให้วัตถุ User ถูกทำลายทิ้งไปจากระบบ และเส้น Life-Line จะถูกกากบาทและหายไปนับตั้งแต่จุดนั้น

4.3 Activation Bar

เป็นแถบทึบที่ครอบเส้น Life-Line ไว้เป็นช่วง ๆ  ตรงบริเวณที่มี Activation Bar ครอบอยู่แสดงให้เห็นว่าวัตถุที่สั่งงานไปยังคงรอคอยผลลัพธ์กลับจากวัตถุที่ทำงานให้อยู่ ให้สังเกตในกรณีที่เป็น Asynchronous Message ในภาพที่ 46 จะเห็นว่า Activation Bar ของวัตถุ somchai จะขาดหายไปหลังจากส่งจดหมายออกไปแล้ว เนื่องจากวัตถุ somchai ไม่จำเป็นต้องรอผลลัพธ์กลับมาจากวัตถุ somsri

การเขียน Activation Bar ไว้จะช่วยทำให้เราเขียนขอบเขตของการเรียกใช้เมธอด ว่าการทำงานครอบคลุมวัตถุใดบ้าง และเมื่อวัตถุที่รับงานไปทำ ทำงานเสร็จแล้วอาจจะมีผลลัพธ์ส่งคืนกลับมา และเราจะแสดงให้เห็นเป็นเส้น return ก็ได้ (บางครั้งอาจจะไม่แสดงเส้น return ให้เห็นแต่ถ้าเป็น  Synchronous Message ผู้อ่านต้องเข้าใจอยู่แล้ว ว่าการส่งเมสเสจไปสั่งงานจะต้องรอจนทำงานเสร็จแล้วกลับออกมาจากเมธอด)

4.4 Guard

เป็นวิธีการใส่เงื่อนไขในการส่งเมสเสจ เพื่อบอกให้เข้าใจว่า เมสเสจนี้จะส่งออกไปก็ต่อเมื่อเงื่อนไขที่ใส่ไว้ใน Guard เป็นจริงเท่านั้น

รูปภาพ 49 ตัวอย่างการใช้ Guard เพื่อกำหนดเงื่อนไขก่อนสั่งงาน

จากภาพที่ 49 เราจะเห็นว่าในเมสเสจที่ 3 จะมีการ์ดเขียนไว้ว่า anUser == null หมายความว่า เงื่อนไขนี้จะต้องทดสอบแล้วเป็นจริงเสมอ จึงจะอนุญาตให้ส่งเมสเสจ new User() ต่อได้ ถ้าเงื่อนไขไม่เป็นจริง จะมีการทำงานต่อไป วิธีการเขียนการ์ดจะใส่เงื่อนไขไว้ในเครื่องหมาย [] และเมื่อเปลี่ยนให้กลายเป็นโปรแกรมแล้วการ์ดก็คือคำสั่ง if…else ในภาษาโปรแกรมทั่วไป

4.5 Code Implementation

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

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

รูปภาพ 50 ตัวอย่างที่จะนำมาเขียนเป็นโปรแกรมภาษา Java

จากภาพที่ 50 เป็นขั้นตอนของระบบขณะที่กำลังจะสร้างผู้ใช้คนใหม่ใส่เข้าไปในระบบ โดยเริ่มจากการกรอกชื่อผู้ใช้เข้ามาผ่านทางส่วนติดต่อกับผู้ใช้ (Graphical User Interface) และส่วนติดต่อกับผู้ใช้จะมาสั่งงานวัตถุ System ให้สร้างผู้ใช้พร้อมกับส่งข้อมูลที่จำเป็นมาให้

1. โครงสร้างโค้ดของคลาส System

1   public class System {

2       public void someMethod() {

3           String id = ...;

4           String user = ...;

5           String password = ...;

6           UserManager manager = ...;

7           manager.createUser(id, user, password);

8       }

9   }

หมายเหตุ –    เครื่องหมาย … ไม่ใช่ไวยากรณ์ของภาษา Java แต่ละไว้หมายถึงว่าไปได้ค่ามาจากที่ใดสักแห่งหนึ่งในโปรแกรม

2. โครงสร้างโค้ดของคลาส UserManager

1   public class UserManager {

2       public void createUser(String id, String name, String password) {

3           User anUser = getUser(id);

4           if(anUser == null) {

5               User newUser = new User(id);

6               newUser.setName(name);

7               newUser.setPassword(password);

8               save(newUser);

9           }

10      }

11  

12      public User getUser(String id) {

13          return ...;

14      }

15  

16      public void save(User user) {

17               ...

18      }

19  }

3. โครงสร้างโค้ดของคลาส User

1   public class User {

2       public User(String id) {

                 ...

3       }

4   

5       public void setName(String name) {

6                ...

7       }

8   

9       public void setPassword(String password) {

10               ...

11      }

12  }

บรรณานุกรม

[Coplien 95] Coplien, James and Doug Schmidt (eds.). Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995.

[Eriksson 98] Eriksson, Hans-Erik and Magnus Penker. UML Tookit. John Wiley & Sons, Inc. 1996.

[Gamma 95] Gamma, Erich, Richard Helm, Ralph Johson, and John Vlissides. Design Patterns. Readings, MA: Addison-Wesley, 1995.

[Coad 99] Peter Coad, Mark Mayfield. Java Design: building better apps and applets. Prentice Hall

[Coad 2000] Peter Coad, Mark Mayfield. UML in Colors. Pretice Hall

[Rose 2002] Wendy Boggs, Micheal Boggs. Mastering UML with Rational Rose 2002. Sybex

---

[1] แพลตฟอร์มในที่นี้หมายถึงสภาวะแวดล้อมที่พร้อมสำหรับการรันแอพพลิเคชันโดยระบบปฏิบัติการหรือภาษาโปรแกรมเป็นผู้จัดเตรียมไว้ให้ ตัวอย่างของแพลตฟอร์มเช่น Java 2 Enterprise Edition, .NET Framework, Windows DNA, และอื่นๆ

[2] หมายถึงการใช้งานเครื่องคอมพิวเตอร์เครื่องอื่นในเครือข่ายได้เหมือนกับการใช้เครื่องคอมพิวเตอร์ของตัวเอง (โดยไม่คิดถึงเวลาที่สูญเสียไปจาก Network Latency)  ตัวอย่างเช่น Distributed Object, Distributed Transaction, Distributed Processing, Clustering หรืออื่นๆ

[3] เรียกว่า Flow of Events หรือหนังสือบางเล่มเรียกว่า Scenario

[4] ในการแบ่งคลาสของ Rumbaug อาจจะใช้ชื่อคลาสประเภทนี้ว่า Entity ซึ่งหมายถึงคลาสที่แทน คน วัตถุ สิ่งของในระบบงาน

[5] ในวิธีการแบ่งคลาสของ Rumbaug เรียกคลาสประเภทนี้ว่า Controller Class

[6] ในวิธีการแบ่งคลาสของ Rumbaug เรียกคลาสประเภทนี้ว่า Boundary Class เนื่องจากมักจะครอบแกนกลางของระบบไว้ภายในและรับหน้าที่ติดต่อกับผู้ใช้ระบบ ซึ่งใน 3-Tier Architecture จะวางคลาสพวกนี้อยู่ที่ User Tier (1^st Tier)

[7] นอกเสียจากว่าเราจะออกแบบให้ร่วมกันใช้แอททริบิวท์จากออบเจกต์เดียวกัน