เขาสร้าง Class Diagram กันอย่างไร

ไป search หาข้อมูลเล่นๆ นานๆ ทีจะมีคนไทยเขียนบทความเกี่ยวกับ Object-Oriented เลยเก็บมาฝากกันครับ

เรื่องนี้คนสนใจกันมาก เป็นเรื่องน่ายินดีครับ แสดงว่าเราเริ่มเข้าสู่กระบวนการใหม่ในการพัฒนา Software จากเดิมที่ออกแบบกันโดยใช้ DFD (Data Flow Diagram) และ ER Diagram มาเป็น UML แต่แน่ๆ ครับ การปรับเปลี่ยนครั้งนี้คงไม่ง่ายนัก อาจต้องตีลังกาคิดกันบ้าง แต่ไม่เป็นไรครับเรามีตัวช่วยที่ปรมาจารย์ทั้งหลายคิดค้นกันขึ้นมา วันเรามาดูรายละเอียดกัน

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

แค่นึกเป็น Class แล้ว

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

ฟังดูแล้ว เหมือนกับมันไม่น่าจะเกี่ยวกันระหว่าง Table และ Class แต่ปรมาจารย์ Peter Coad บอกว่าที่พูดกันว่า OO เป็นการปฏิบัติวงการการเขียนโปรแกรมนั้น ไม่เห็นด้วยครับ เขาบอกว่า OO เป็นการขยายภาพของ Table นั่นเอง น่าเรียกว่าเป็นการปฏิรูปจึงจะถูก ในส่วนของ Table นั้นเรานิยาม Attributes (Fields ต่างๆ) ถ้าเปรียบกับสมัยนี้เขาบอกว่ามันยังไม่ครบถ้วน เป็นโลกแค่ครึ่งไป เมื่อบวกกับ Operations (Methods ต่างๆ) ตามด้วยความสัมพันธ์ มันก็ครบใบพอดี จึงไม่น่าแปลกใจเลยว่าทำไมกลุ่มคนเหล่านี้ถึงสามารถ กำหนดชื่อ class ได้โดยไม่ยาก

แต่ปัญหาที่พบมากสำหรับคนกลุ่มนี้ก็คือ Responsibility ครับ กำหนดชื่อ Class ได้ แต่พอไล่ลงไปในระดับ Field แล้วจะค่อนข้างมั่ว เพราะแนวคิดในการกำหนดตรงนี้มันมีความแตกต่างกันระหว่าง Relational และ OO ยิ่งกำหนด Operation แล้วละก็ยิ่งมั่วใหญ่ เพราะไม่คุ้นเคยเอาเสียเลย ทางแก้ก็คือให้ไปใช้วิธีอื่นดูสักพัก จนกระทั่งเราเข้าใจแนวคิด OO จริงๆ คราวนี้ค่อยกับมาใช้วิธีนี้ จะเห็นผลดีครับ

สิ่งที่คนกลุ่มนี้ต้องระวังอีกก็คือ การทำ Normalization คนที่เก่งๆ ในการทำ Relational นั้น มักจะออกแบบ Table ที่ถูกหลัก Normalization ระดับ 3 ได้เลย ไม่จำเป็นต้องปรับที่หลังอีก แต่ผลลัพธ์ที่ได้ มันก็ขัดกับ OO อยู่พอสมควร เรื่องนี้ต้องระวัง อีกเรื่องก็คือ เวลาเราออกแบบ Class นั้นเรารองรับความสัมพันธ์แบบ Many-to-Many แต่ Relational ไม่ใช่มันต้องแตกออกเป็น One-to-Many 2 ตัว คนกลุ่มนี้มักจะมองความความสัมพันธ์แบบ Many-to-Many ไม่ออกครับ

แล้วถ้านึกเป็น Class ไม่ได้มีอะไรพอช่วยได้ไหม

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

หลังจากยุค Waterfall แล้ว เราก็เข้าสู่ยุค Spiral มี Methodology อยู่หลายเจ้าเลยที่ถือกำเนิดขึ้นมา ตัวที่เราน่าจะได้ยินกันบ่อยๆ ก็จะมี Extreme Programming และ Unified Process ถ้าวางกันบนไม้บรรทัดแล้ว จะเห็นว่า XP นั้นจะทางซ้ายติดขอบ ส่วน Unified Process จะอยู่คนละขั้ว ขวาติดขอบเหมือนกัน ซ้ายขวาหมายถึงอะไร ทาง XP นั้นคนคิดก็คือกลุ่มโปรแกรมเมอร์ (แบบไม่เป็นทางการคือ Gang of Four และผองเพื่อน) ดังนั้นจึงเน้นถึงการเขียน Code เป็นหลัก เอกสารหรือ Diagram ต่างๆ ไม่เน้น เพราะยึดหลักว่าของที่เอาไปขายคือตัว Code ส่วน Unified Process เกิดมาจากนักคิดครับ และก็เป็นกลุ่มเดียวกันกับคนที่คิด UML (แบบเป็นทางการคือ Three Amigos) แนวคิดหลักของ Unified Process จะอยู่ที่ Project Management เน้นการสร้างเอกสาร และ ใช้ Diagram เป็นหลัก จะเห็นได้ว่ามันคนละขั้วเลย ทาง XP ก็มีคนไม่ชอบ เพราะอย่างแรกก็คือเรากำหนดเวลาตายตัวของโครงการได้ยาก เพราะใช้วิธี Onsite Customer ทำให้ผู้ใช้สามารถเรียกร้องเนื้องานเพิ่มได้เรื่อยๆ ส่วนทาง Unified Process นั้น ก็มีคนติว่า เสียเวลาและแรงงานในการทำเอกสารมากเกินไป (ถึงแม้ว่าจะบอกว่าบางตัวไม่ทำก็ได้) มีข้อดีข้อเสียครับ ใครที่รับงานเป็นทางการ ที่ต้องกำหนด Scope ให้ชัดเจนก่อนลงมือ เพื่อให้ประเมินราคาได้ แบบนี้ Unified Process ก็ดูเหมาะ แต่สำหรับงานแบบ Pioneer ที่ไม่เคยทำกันมาก่อน ยังไม่รู้ว่าต้องทำอะไร และทำได้อย่างไร กำหนดอะไรชัดเจนไม่ได้เลยในตอนแรก เวลาคิดเงินจึงต้องคิดเป็นราคาเหมา แบบนี้ XP ก็น่าจะเป็นทางเลือกที่ดีครับ

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

Extreme Programming

ทางค่ายของ Extreme Programming ไม่ได้มีอะไรใหม่ เขาใช้วิธีที่มีอยู่แล้วนั่นคือ CRC Card (Class Responsibility Collaborator Card) ว่าไปแล้ว XP ไม่เคยคิดอะไรใหม่เลย เพียงแค่เป็นตัวรวบรวมวิธีที่ดีที่เคยมีมาเอาเข้าไว้ด้วยกัน CRC Card ก็เช่นกันครับมีมานานแล้ว XP ยืมมาใช้เท่านั้น

CRC Card เป็นกระดาษ ถ้าได้กระดาษแข็งก็จะดี ขนาดเล็กกว่า Letter หรือ A4 เพราะไม่ต้องการให้ดูเป็นทางการจนเกินไป จะเป็น A5 ก็น่าจะดี หรือ 4"x6" ก็มีคนใช้ ซึ่งหน้าตาตามรูปนี้ครับ

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

หลังจากที่เราได้กระดาษมาแล้ว เราต้องกำหนด class เพื่อเอามาใส่ หนึ่ง CRC card ต่อหนึ่ง Class แล้วเราจะเอาชื่อ class จากไหนมาใส่กันเล่า ทาง XP บอกว่าให้เราดู User Story หรือเอกสารประกอบ มองหาคำนามที่อยู่ในเอกสารเหล่านั้น ดูว่ามีอะไรบ้าง เอาคำนามนั่นแหละครับแปลงมาเป็นชื่อ class

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

จากนั้นเราก็มาดูครับ class แม่บ้านมันอยู่ลอยๆ เกินไป เราต้องสร้าง class ลูกจ้างขึ้นมา เพื่อให้ class แม่บ้าน Inherit เอาข้อมูลเหล่านี้ไปกรอกช่อง Superclasses และ Subclasses ให้เรียบร้อย อย่าลืมลบ "รู้ชื่อ" ออกาจาก class แม่บ้านนะครับ เอาไปใส่ไว้ใน class "ลูกจ้าง" แทน

จากนั้นให้เรานึกถึง Scenario คำว่า Scenario นั้นก็คือเหตุการณ์เหตุการณ์หนึ่งของโปรแกรมของเรา โดยปกติแล้วมีคนมาเป็นตัวเริ่มต้น Scenario ก็จะเป็นเรื่องราวตั้งแต่ต้นกระบวนการจนจบสิ้นนั่นเอง พอเรานึกถึง Scenario ขึ้นมา class ต่างๆ ก็เปรียบได้กับตัวละคร มันจะโลดแล่นเข้ามาในฉากนี้ และจุดนี้เอง คูณจะเห็นพฤติกรรมที่ class ต่างๆ จะกระทำซึ่งกันและกัน คุณเอาข้อมูลเหล่านั้น ไปกรอกลงช่อง Responsibilities ครับ จากนั้น ถ้า class หนึ่ง class ใดมีปฏิสัมพันธ์กับ class อื่น ก็ให้เราระบุ class ที่มันเกี่ยวข้อง ลงในช่อง collaborators เช่น class แม่บ้าน เกี่ยวข้องกับตลาด เพราะต้องไปจ่ายกับข้าว ก็ให้ใส่ "ตลาด" ลงในช่อง collaborators ครับ

มาถึงจุดนี้ เราก็เอา CRC card มาสร้างเป็น Class Diagram ผมคงไม่ต้องบอกมานะครับ ในส่วนของ Responsibilities จะถูกแปลงเป็น Attributes (พวกที่ขึ้นต้นว่า "รู้") และ Operations ส่วน Collaborators จะถูกแปลงให้เป็นเส้นความสัมพันธ์ต่างๆ ครับ ส่วน subclasses/superclasses ก็จะแปลงเป็น Inheritance นั่นเอง

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

Unified Process

แนวคิด Unified Process ในการสร้าง Class นั้น ผมว่าส่วนหนึ่งก็คงได้รับอิทธิพลมาจาก CRC Card เหมือนกัน แก่นคล้ายกัน แต่วิธีการนั้นแตกต่างกันอย่างเห็นได้ชัด เรามาดูรายละเอียดของ Unified Process กัน

ขั้นตอนแรกในการวิเคราะห์งานนั้น Unified Process กำหนดให้สร้าง Use Case (Use Case ก็เป็นของเก่าครับ เกิดก่อน Unified Process นานเลยครับ)Use Case เป็นการบรรยายถึงกิจกรรมในจินตนาการครับ จินตนาการว่าถ้า software เราเสร็จ มันจะมีกิจกรรมอะไร แล้วมีใครเกี่ยวข้องบ้าง อาจจะกล่าวได้ว่า มันจะอธิบายว่าใครทำอะไร ที่ไหนเมื่อไร แต่ไม่ได้บอกว่าทำอย่างไร (เหมือนกับ Scenario ใน CRC Card) ในกิจกรรมหนึ่งก็ต่อ Use Case ตัวหนึ่ง ที่ยกตัวอย่างกันบ่อยๆ จนกลายเป็นมาตรฐานสำหรับ Use Case ไปแล้ว นั่นก็คือกิจกรรมเกี่ยวกับการทำธุรกรรมกับตู้ ATM เราก็จะมี Use-Case สำหรับการถอน การฝาก การถามยอด แยกกันครับ

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

เมื่อเราได้ Use Case มาแล้ว ขั้นต่อไปก็เหมือนกับ CRC Card ครับ คือให้มองหาคำนามใน Use Case นั้น เมื่อเราได้คำนามมาแล้ว เราก็เอาคำนามที่ได้มาเข้าสู่กระบวนการปรับบทบาทครับ เช่นถ้าได้คำนามว่า Employee มันก็ดูกว้างไป ระบุให้ชัดกว่านี้ครับว่าเป็น Accountant เป็นต้น เมื่อปรับเรียบร้อยแล้ว เราก็วาด Class Diagram เป็นก้อนๆ เอาไว้ หรือเอาคำนามไปใส่ไว้ในกล่องสี่เหลี่ยมของ Class Diagram นั่นเอง ตรงนี้จะใช้ UML Class Diagram tool วาดเอา หรือจะวาดในกระดาษหรือบนกระดานก็ไม่ผิดกติกาแต่อย่างใด

เมื่อได้ ก้อน Class ต่างๆ แล้ว ลองลากความสัมพันธ์ดูครับ ใช้ Association อย่างเดียวก็พอ แต่สิ่งที่ควรจะใส่ก็คือข้างไหน เป็น one ข้างไหนเป็น Many พร้อมทั้งตั้งชื่อบทบาทที่เส้นด้วย จะได้อ่านเข้าใจง่าย

จากนั้นเราก็ลองเอา Attributes ใส่ตาม class ต่างๆ ยังไม่ต้องเน้นความถูกต้องมากครับ เพราะเรามีเครื่องมืออีกตัวหนึ่งที่ช่วยให้กำหนดสิ่งต่างๆ ได้ถูกต้องขึ้น นั่นก็คือ Sequence Diagram ว่ากันไปแล้วขั้นตอนนี้ก็เหมือนกับ CRC Card ที่ไล่ตาม Scenario แต่ต่างกันตรงที่ว่า Unified Process จะเห็นภาพได้ชั้ดเจนกว่า เพราะวาดเป็น Sequence Diagram (ทุกคนคงรู้จัก Sequence Diagram กันนะครับ) ระหว่างที่วาดนั้น Attributes และ Operation ต่างๆ ก็จะผุดขึ้นมา คุณก็เอาไปปรับปรุงใน Class Diagram ได้เลย

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

ผมเล่าแบบตัดตอนมากนะครับ เพราะใน Unified Process นั้นมีรายละเอียดมาก ตัวช่วยก็มีเยอะ ถ้าสนใจรายละเอียดแบบทุกกระบวนการ ผมแนะนำ หนังสือเล่มนี้ครับ

ICONIX

อย่างที่ผมบอกตั้งแต่แรกครับ XP อยู่ข้างหนึ่ง UP อยู่อีกข้าง แล้วมี Methodology กระจายตัวกันอยู่บนไม้บรรทัด แต่ ICONIX พิเศษหน่อย มีคนไม่น้อยเชื่อว่ามันอยู่ตรงกลางพอดี (หกนิ้ว) เป็นภาษาพุทธก็เรียกว่าเป็นยมบาล ทำกรรมดีและชั่วเท่าๆ กัน (ไม่ได้บอกว่าข้างไหนดีหรือชั่วนะครับ)

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

ที่บอกว่ามันถูกจริตผม เพราะว่า ผมอยู่ในกลุ่ม Relational ที่กล่าวมาข้างต้นครับ เวลาคุยๆ นี่นึกเป็น Table ได้ทันที ผมเองก็ไม่ชอบรำมวยแบบ Unified Process ก็ชื่อ Class มันอยู่ในหัวของผมเกือบหมดแล้ว ICONIX ก็ดีใจหาย บอกว่าขั้นตอนแรกก็นิยาม Class กันได้เลย

ว่าแล้วผมก็เริ่มบรรเลงการสร้าง Class เลย แต่ก็เช่นเดิมครับ ค่อนข้างจะคร่าวๆ ไม่เน้นรายละเอียดพวก Attributes และ Operations สักเท่าไร ทำให้มีพอมีอะไรที่จับต้องได้ก็พอครับ เมื่อสร้างเสร็จแล้ว ICONIX ก็บอกให้ผมสร้าง Use Case แบบเดียวกันกับใน Unified Process คิดกันคนละแบบเลยเห็นไหมครับ Unified Process สร้าง Use Case เพื่อกลั่นกรองให้ได้ Class แต่ ICONIX กลับสร้าง Class Diagram ก่อนแล้วค่อยสร้าง Use Case รายละเอียดการสร้าง Use Case ผมคงไม่ฉายซ้ำนะครับลองอ่านดูจากข้างบนครับ

เมื่อได้ Use Case แล้วเอา Use Case ที่ได้นั้นมาขยายเพิ่มเติมโดยใช้ Robustness Diagram เชื่อว่ามีหลายคนคงไม่เคยได้ยินชื่อ Robustness Diagram จริงๆ แล้ว Robustness Diagram คนคิดค้นไม่ใช่อื่นไกลครับ เป็นคนหนึ่งในกลุ่ม Three Amigos ที่ชื่อว่า Ivar Jacobson นั่นเอง ก่อนที่จะมารวมกลุ่ม Three Amigos ซึ่งถือว่าเป็นเสาหลักเสาหนึ่งของยุทธภพ Jacobson เคยเป็นเจ้าสำนัก Objectory มาก่อน และ Diagram ตัวหนึ่งที่เขาคิดค้นขึ้นมานั้น ก็คือ Robustness Diagram แต่พอมารวมตัวเป็นสำนัก Rational เจ้า Robustness Diagram ก็ถูกโยนทิ้งไป ไม่ปรากฏใน UML ICONIX นี่ไปปลุกผี Robustness Diagram ให้ฟื้นคืนชีพอีกครั้ง ลองมาดูหน้าตา Robustness Diagram กันครับ

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

เรามาลองดูครับ Robustness Diagram จะประกอบด้วย รูป 3 แบบ นั่นก็คือ Boundary รูปที่คนชี้หานั่นแหละครับ คือรูปที่มีกำแพงยื่นออกไปทางด้านซ้ายนั่นเอง Boundary เป็นตัวบอกว่า หน่วยนี้เป็นหน่วยที่ติดต่อกับผู้ใช้ ยังมีแบบที่สองครับ ที่เป็นวงกลม แล้วมีขีดเส้นใต้ข้างล่าง เราเรียกพวกนี้ว่า Entity ถ้าว่ากันในเรื่อง Class แล้ว มันก็พวก Persistence Class นั่นเอง ส่วน วงกลมที่มีเครื่องหมายน้อยกว่าอยู่บนหัว จริงๆ แล้วแสดงการหมุนครับ พวกนี้เรียกว่า Controller เป็นตัวประสานงานอยู่ตรงกลางระหว่าง Boundary กับ Entity ครับ ใครรู้จัก Pattern เยอะๆ ก็จะร้อง ไอ้หย่า นี่มัน Model-View-Controller นี่นา ใช่แล้วครับ ไม่ผิดหรือ Model-View-Controller นั่นเอง การแยกหมวดหมู่เช่นนี้ทำให้เรามองเห็น Class ได้ชัดขึ้นมากครับ

คำถามตามมาครับ แล้วเราจะรู้ได้อย่างไรว่าควรมีวงกลมอะไรบ้าง ข้อนี้ตอบไม่ยากครับ ก็เอา class ที่สร้างมาได้ตั้งแต่ต้นมาเป็นตัวตั้งสิครับ ถ้าขาดไปบางตัว มาถึงขึ้นนี้ก็สามารถเพิ่มเติมได้ แต่สังเกตนะครับ เราไม่ได้สนใจ Attributes และ Operations เลย

มาอีกคำถามหนึ่งที่น่าสนใจ ก็ Robustness Diagram มันไม่มีใน UML แบบนี้มิต้องวาดมือกันหรือ ไม่ขนาดนั้นครับ จริงๆ แล้วสาเหตุหลักที่ Three Amigos ตัด Robustness Diagram ออกไป ไม่ใช่เพราะมันไม่ดีนะครับ แต่หาก เราสามารถทดแทนมันได้ด้วย Class Diagram ครับ ใน Class Diagram เขาจะมีสิ่งหนึ่งที่เรียกว่า Stereotype ปกติแล้วก็มี 3 อย่างนี้ให้เลือก ลองดูตัวอย่างจาก Visio ครับ

Visio ไม่ได้รองรับ Robustness Diagram ผมเลยต้องไปที่ Menu UML->Stereotypes เพื่อเพิ่มคำทั้งสาม ที่ Base Class เป็น Class แต่ถ้าเป็น Magic Draw พอผมเลย Stereotypes มันก็มีทั้งสามแบบให้เลือก พอเลือกแล้ว มันเปลี่ยนรูปจากกล่องสี่เหลี่ยมให้กลายเป็นอย่างนี้ครับ

เมื่อเราได้ Robustness Diagram แล้ว คราวนี้ก็เหมือนกับ Unified Process แล้วครับ คือสร้าง Sequence Diagram ซึ่งน่าจะสร้างได้ง่ายขึ้นมาก เพราะเราดึงเอาวัตถุดิบจาก Robustness Diagram ไปใช้นั่นเอง

เมื่อได้ Sequence Diagram แล้วก็ไม่แตกต่างจาก Unified Process ครับ คือเอา Attributes, Operations และความสัมพันธ์กลับไปปรับปรุง Class Diagram ที่เราสร้างขึ้นไว้ตอนแรก ก็เป็นอันเสร็จพิธี

ถ้าอยากได้ข้อมูลเพิ่มเติมลองหนังสือเล่มนี้ครับ

ตัวช่วย

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

ตัวช่วยกำหนดชื่อ class

มีตัวช่วยตัวหนึ่งที่เรียกว่า Conceptual Class Category List เป็นรายการหมวดหมู่ของของต่างๆ รายการหมวดหมู่มีดังนี้ครับ

• สถานที่
• Transaction ที่ต้องเก็บ
• บทบาทของคน
• Container ของ ข้อมูล
• สิ่งที่อยู่ใน Container
• สิ่งที่จับต้องได้
• ระบบคอมพิวเตอร์ภายนอก
• คำนาม
• องค์กร
• เหตุการณ์
• กระบวนการ
• กฏ ข้อจำกัด นโยบาย
• catalog
• งาน สัญญา
• การเงิน บริการ
• คู่มือ หนังสือ

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

ตัวช่วยกำหนด Attributes และ Operations

เมื่อเราได้ชื่อ Class แล้ว เนื้อหาที่อยู่ใน Class นั้นยังคงเป็นปัญหาอยู่ จะลองผิดลองถูก ก็กลัวเสียเวลาเยอะ ไม่เป็นไรครับ เรามีตัวช่วยอีกแล้ว ใน Methodology ที่ชื่อว่า MDA (Model Driven Architecture) ของ OMG นั้นมีการคิดค้นสิ่งหนึ่งที่เรียกว่า Archetype ขึ้นมา ถ้าแปลเป็นภาษาที่เราชาวคอมพิวเตอร์เข้าใจนั่นก็คือ Pattern นั่นเอง แต่ไม่ใช่แบบ Design Pattern นะครับ มันเป็น Pattern งานธุรกิจ มีเนื้อหาและความสัมพันธ์ที่ตรงกับงานเลย เช่น Pattern ของ สินค้า เป็น class ที่ design เสร็จเป็นของสำเร็จรูป มีการทำ category การจัดการ package นโยบายราคาเป็นต้น สมมุติว่าเวลาคุณออกแบบ แล้วเกิดมีคำว่าสินค้าโผล่ขึ้นมา คุณสามารถยืม Archetype เอามาใส่ได้เลยครับ มี Attributes Operations และความสัมพันธ์ให้เสร็จสรรพ พอเอามาก็เอามาปรับปรุงตัดของที่ไม่ต้องการออก เพิ่มส่วนที่ไม่มีใน Archetype เข้าไป ผมว่ามันดีกว่าการเริ่มต้นที่ 0 เลยเป็นไหนๆ ถ้าเปรียบเทียบกับ Design Pattern แล้ว ผมเห็นประโยชน์ของ Archetype มากกว่าเยอะ (ถ้าอยากได้เหตุผล ก็ลอง Vote บทความ Design Pattern ผมจะร่ายยาวให้อ่านกัน)

ตัวช่วยกำหนดความสัมพันธ์ของ Class

หนังสือ Analysis Patterns ของ Martin Folwer เจ้าเก่า หนังสือเล่มนี้ ก็เป็น Pattern เหมือนกันคล้ายกับ Archetype แต่ไม่เน้น Attributes หรือ Operations แต่หากเน้น Process มีกลยุทธ์เยอะเลยครับ เห็นจากตัวอย่างๆ จริงๆ กันเลย ใครสนใจเรื่องทำบัญชี มี Pattern ตรงๆ ให้ศึกษา ถ้าได้แนวคิดแล้วก็สามารถประยุกต์ใช้กับงานอื่นได้อีกต่างหาก แต่ข้อเสียก็มีครับ หนังสือเล่มนี้ไม่ได้ใช้ UML เลยอ่านยากหน่อย ผนวกกับไม่ได้เน้น Attributes กับ Operations จึงทำให้มีแต่คำอธิบาย ไม่ค่อยมีตัวอย่าง นับว่าเป็นหนังสืออ่านยากเล่มหนึ่งครับ พยายามกันหน่อยครับ

ก่อนจบขอนอกเรื่องไปยัง UML

มีคนพูดถึง UML กันมาก วันนี้ผมขอนอกเรื่องใช้พื้นที่ตรงนี้อธิบายให้เห็นภาพกันหน่อย UML นั้นที่จริงแล้วเป็น Diagrams ที่ชนะการประกวดมา ด้วยเหตุว่า ในยุคอดีตนั้น มีสำนัก OO อยู่หลายสำนัก แต่ละสำนักก็พูดเรื่องที่ไม่หนีกันเท่าไรหรอกครับ แต่กลับมี Diagram อยู่มากมายเข้าทำนองต่างคนต่างคิด ดังนั้นเพื่อให้ไม่สับสน จะใช้กำลังยุบสำนักก็ใช่ที่ เลยมีกลยุทธ์ ยิงนัดเดียวได้นกสองตัว คือประกาศกันทั่วว่า เราจะมีมาตรฐานกลางของ Diagram ที่จะใช้ร่วมกันทุกสำนัก เชิญทุกคนเข้ามาประกวด เหตุการณ์ก็สนุกครับ สำนักเล็กๆ ก็รวมตัวกันเป็นก๊ก เพื่อมีอำนาจต่อรองกัน ดีครับ มันเลยเหลือไม่กี่สำนักในยุคปัจจุบัน และสุดท้ายเราก็ได้ UML ตอนปี 1997

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

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

Supoj

26/Jul/05

ที่มา: http://www.twoguru.com/playground/article/classdef.htm

ลิงค์น่าสนใจ : http://search.appjob.com/search.php?kw=class%20diagram