Class​ ​Diagram​ ​คือ​อะไร​ ​และ​ใช้​ใน​การ​ออกแบบ​โครงสร้าง​ซอฟต์แวร์​อย่างไร

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

อ่านกล่องและเส้นความสัมพันธ์

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

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

ตัวอย่างสมมติ: ระบบคำขอ

อาจมี User, Request และ StatusChange โดยผู้ใช้สร้างคำขอหนึ่งหรือหลายรายการ คำขอมีประวัติการเปลี่ยนสถานะหลายครั้ง คำถามสำคัญคือกฎ “ใครเปลี่ยนสถานะได้” ควรอยู่ตรงไหนและตรวจอย่างไร ภาพคลาสช่วยคุยเรื่องความรับผิดชอบ แต่ยังไม่แทนการออกแบบสิทธิ์ระดับข้อมูลหรือการทดสอบ

ต่างจาก ER Diagram อย่างไร

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

ใช้ในรายงาน

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

อ่าน ER Diagram และ Software Design หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

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

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

แหล่งข้อมูลประกอบ

• Object Management Group: UML 2.5.1 — นิยาม Class และความสัมพันธ์ใน UML