Sequence Diagram
🤔 เราจะอธิบายของต่างๆตอนที่มันคุยกันให้เข้าใจง่ายๆยังไงดี ?
Last updated
Was this helpful?
🤔 เราจะอธิบายของต่างๆตอนที่มันคุยกันให้เข้าใจง่ายๆยังไงดี ?
Last updated
Was this helpful?
เคยไหมเวลาอธิบายการทำงานให้กับเพื่อนๆในทีมว่า ของต่างๆมันทำงานร่วมกันยังไง ซึ่งตอนที่คุยกันก็อาจจะต้องทวนกันหลายทีบ้างเพื่อให้เข้าใจตรงกัน แต่แล้วตอนไปทำงานจริงๆก็ไม่ได้ทำตามที่คุย เพราะเข้าใจผิดหรือลืม เพราะมันมีขั้นตอนการทำงานที่ค่อนข้างเยอะและตัวแปรต่างๆที่รับส่งก็วุ่นวายเช่นกัน
ตัวอย่าง ฝั่ง front-end จะต้องส่งข้อมูลต่างๆไปให้กับฝั่ง back-end ผ่าน API ตัวนี้สำหรับเรื่องนี้นะ แล้วฝั่ง back-end จะไปเรียก module 1234 เพื่อทำงานต่อ แล้วจะได้ข้อมูลแบบนี้ส่งกลับมา บลาๆ
จากที่ร่ายยาวมาเราจะทำยังไงดีเพื่อให้คนในทีมเข้าใจและไม่ลืมขั้นตอนการทำงานของโค้ดเหล่านั้นได้กันนะ ?
ผมเชื่อว่าคนเราเห็นภาพแล้วเข้าใจได้ง่ายกว่าเห็นตัวหนังสือ ดังนั้นเราจะใช้แผนภาพที่เรียกว่า Sequence Diagram มาช่วยแก้ปัญหาโลกแตกนี้กัน โดยเจ้า sequence diagram นั้นจะแปลงเรื่องราวทั้งหมดที่เกิดขึ้นให้กลายเป็นรูปที่เข้าใจง่ายๆนั่นเอง
โดยปรกติเวลาที่เราใช้ UML เราจะไม่เขียนโค้ดหรือเขียนเอกสารกัน แต่เราจะวาดรูปเล่นกันต่างหาก โดยในตัวอย่างรอบนี้เราจะใช้ตัวอย่างของการ Login มาเขียนเป็น diagram แบบ step-by-step ดูละกัน ซึ่งผมจะให้ ดช.แมวน้ำ 🧔 เป็นคนไล่ลำดับการเขียน diagram ให้ดูละกันนะ
🧔 ในการเขียน sequence diagram นั้นเราจะต้องเริ่มวาดจากสิ่งที่เริ่มต้นกระบวนการก่อน ซึ่งในการ login นั้นจุดเริ่มต้นของมันคือมีผู้ใช้เข้ามานั่นเอง ดังนั้นเราก็จะวาดรูป ผู้ใช้ เป็นสิ่งแรกลงไป
🧔 หลังจากที่มีผู้ใช้เข้ามาในระบบแล้ว ระบบก็จะเปิดหน้า Login มาให้ผู้ใช้เห็น ดังนั้นเราก็จะวาดกล่องของหน้า Login เข้าไปตามรูปด้านล่าง
🧔 หลังจากที่ระบบแสดงหน้า login ขึ้นมาแล้ว ถัดไปผู้ใช้ก็จะทำการกรอกข้อมูลและกดปุ่มเข้าสู่ระบบซึ่งเป็นการทำงานระหว่าง User กับ Login page นั่นเอง ดังนั้นเราก็จะวาดรูปออกมาเป็นแบบนี้
🧔 หลังจากที่ Login page ถูก User เรียกมาแล้ว มันก็จะเริ่มต้นทำงานต่อ โดยเราจะวาดกล่องครอบจุดเริ่มต้นของสิ่งที่มันจะทำไปจนถึงขั้นตอนการทำงานสุดท้ายของมันลงไปภายในเส้นประตามรูปเลย
🧔 สิ่งแรกที่หน้า Login จะทำก็คือตรวจสอบว่าข้อมูลที่ผู้ใช้กรอกมานั้นครบหรือยัง เช่น ชื่อผู้ใช้ และ รหัสผ่าน ต้องไม่เป็นค่าว่างไรงี้ ซึ่งการทำงานนี้มันจะทำงานภายในหน้า Login เองไม่ได้ให้ใครช่วยทำ เราก็จะวาดรูปออกมาราวๆนี้
🧔 ถัดมาถ้าผู้ใช้ยังกรอกข้อมูลไม่ครบ ระบบก็จะแจ้งเตือนออกมา ซึ่งมันจะแจ้งเตือนเฉพาะกรณีที่ใส่ข้อมูลไม่ครบเท่านั้น ดังนั้นเราก็จะใส่กล่องเงื่อนไขครอบลงไปตามนี้
Fragments ในกล่อง fragment จะเห็นว่ามันเขียนไว้ว่าเป็น alt ซึ่งย่อมาจาก Alternative ที่แปลว่าทางเลือก ซึ่งมันจะทำก็ต่อเมื่อเงื่อนไขที่เขียนกำกับไว้เป็นจริง ส่วน fragments นั้นจริงๆมีให้เลือกใช้เยอะเต็มไปหมดเลย เช่น loop, ref ที่ได้ใช้บ่อยๆนะ ส่วนอันอื่นๆลองไปศึกษาเพิ่มเติมดูละกันนะ
🧔 ถัดมาถ้าผู้ใช้กรอกข้อมูลครบ มันก็จะส่งข้อมูลชื่อผู้ใช้และรหัสผ่านไปตรวจสอบกับเซิฟเวอร์โดยส่งผ่าน API ไป ซึ่งมันจะส่งไปก็ต่อเมื่อ ข้อมูลถูกกรอกครบหมดแล้วเท่านั้น เราก็จะวาดรูปออกมาราวๆนี้
สังเกตุนะว่าถ้าเราไม่ใส่ Guard condition ไว้ ตอนที่มันทำข้อ 3 เสร็จ คนที่ไม่รู้เรื่องก็จะเข้าใจว่ามันจะทำข้อ 4 ต่อเลยนั่นเอง แต่ถ้าเราใส่ Guard condition ไว้ในข้อ 4 มันจะเป็นการบังคับว่าต้องผ่านเงื่อนไขนี้ก่อนเท่านั้นนะถึงจะทำข้อนี้ได้นั่นเอง
🧔 ในการส่ง Message ของข้อ 4 เราอาจจะเขียนไว้เลยก็ได้ว่ามันส่งอะไรไปบ้างก็ได้ ตามรูปด้านล่าง
🧔 หลังจากที่ตัว API ตรวจสอบผลลัพท์ต่างๆแล้ว มันก็จะส่งผลลัพท์กลับมาให้กับหน้า Login นั่นเอง ซึ่งเราก็จะวาดรูปออกมาเป็น เส้นประ ครับ
🧔 ผลลัพท์ที่มันส่งกลับมา ในบางครั้งเราก็อยากจะเขียนรายละเอียดไว้กันลืมว่ามันส่งอะไรกลับมาบ้าง เราก็สามารถใส่ note ไว้ก็ได้ ซึ่งของที่เขียนไว้ใน note ไม่มีรูปแบบกำหนดไว้ ดังนั้นในตัวอย่างผมจะเขียน Json ที่มันส่งกลับมาละกัน ตามรูปเลย
🧔 ตัวผลลัพท์ที่ได้กลับมานั้น หน้า Login ก็จะทำการตัดสินใจต่อว่ามันจะต้องแสดงผลยังไงต่อดี ซึ่งเราจะเขียนแยกเงื่อนไขออกเป็น 2 เรื่องตามนี้
เข้าใช้งานไม่ได้ - ระบบก็ควรจะแจ้งข้อผิดพลาดที่ได้มาจากเซิฟเวอร์
เข้าใช้งานได้ - ระบบก็จะแจ้งเตือนว่ากำลังเปลี่ยนหน้านะ
🧔 เสร็จแล้ว จากที่ร่ายยาวมาเราก็จะได้ลำดับการทำงานของระบบ Login ทั้งหมด 7 ขั้นตอนที่ไม่ต้องนั่งไล่จำอะไร เพราะทุกคนในทีมสามารถกลับมาดูรูปก็สามารถพูดคุยกันต่อได้เลยนั่นเอง
ของที่ยกตัวอย่างให้ดูด้านบนทั้งหมดจริงๆมันก็เพียงพอต่อการใช้งาน 80% แล้วล่ะ ส่วนที่เหลือมันเป็นตัวเสริมให้เราสามารถลงรายละเอียดของแผนภาพได้ชัดขึ้นกว่าเดิมเฉยๆ ดังนั้นผมจะยกตัวอย่างการใช้งานตัวอื่นๆไว้ในนี้ต่อละกันไม่งั้นเดี๋ยวคนที่พึ่งเคยใช้จะตกใจว่าทำไมมันวุ่นวายจุงเบย
🧔 ถ้าการทำงานของเราจะต้องไปสร้าง Lifeline อื่นขึ้นมาเพื่อทำงานกับตัวนั้นโดยเฉพาะเราก็สามารถเขียนเป็นแบบนี้ได้
🧔 ในการส่ง message บางทีก็เป็นการสั่งให้อีก Lifeline นึงจบการทำงานเลยก็ได้เหมือนกัน เช่นพวกคำสั่ง Dispose ยังไงล่ะ ซึ่งเราก็จะวาดรูปเป็นแบบนี้
ขอแนะนำแบบเบื้องต้นไว้เท่านี้ก่อนละกัน เพราะที่เหลือมันเป็นของที่นานๆครั้งเราจะได้ใช้ เพราะการคุยกัน 80% ในการทำงานนั้นใช้แค่นี้ก็เหลือเฟือแล้วครับ ส่วนกรณีที่ต้องใช้ของที่เหลือก็คือ งานในจุดนั้นๆมันต้องมีการลงรายละเอียดที่ชัดเจนเพื่อไม่ให้เข้าใจผิดเพราะงานจุดนั้นมันละเอียดอ่อนจริงๆยังไงล่ะ
จากทั้งหมดเราก็จะเห็นแล้วว่า เราสามารถแปลงขั้นตอนการทำงานร่วมกันของคลาสต่างๆหรือ module ต่างๆให้กลายมาเป็นรูปภาพที่เข้าใจง่ายๆได้ยังไง ดังนั้นเราลองไปหัดวาดรูปเล่นเพื่อทำให้คนในทีมเข้าใจการทำงานได้ง่ายๆกันเถอะ
คำเตือน เวลาที่เราเขียน Diagram ต่างๆ ห้ามเอาทุกกระบวนการทำงานมาเขียนยำกันไว้ในภายใน diagram เดียวกัน เพราะไม่อย่างนั้นมันจะกลายเป็นแผนภาพพาทัวร์นรกเลย เพราะเส้นมันจะยุ่งเหยิงไม่รู้จุดเริ่มต้นแต่ละเรื่องคืออะไร
สิ่งที่ควรทำคือ เขียน 1 กระบวนการทำงานต่อ 1 diagram เท่านั้น ดังนั้นถ้างานเราใหญ่เราก็จะมีหลาย diagram ก็จริงแต่มันจะช่วยทำให้เรา focus กับแต่ละกระบวนการทำงานได้ชัดเจนขึ้นนั่นเอง
