SEO

Activity Diagram คืออะไร ? เขียนอย่างไร ?

UML Activity Diagram | Symbols and Components Of UML with Example

Activity Diagram คืออะไร ? เขียนอย่างไร ?

กรณีการใช้แผนภาพแสดงนักแสดงกรณีการใช้งานภาชนะกรณีการใช้งาน และความสัมพันธ์ของพวกเขา สัญลักษณ์ใด ๆ ที่อาจเชื่อมโยงกับภาพอื่น ๆ หรือเอกสารภายนอก คลิกที่ลิงค์เพื่อเปิดเอกสารที่เกี่ยวข้อง

2.Sequence Deagram

ด้วยแผนภาพลำดับที่คุณรูปแบบจำลองพฤติกรรมของระบบที่นี่ UML 2 ในบรรทัดตัวอย่างแผนภาพลำดับ จะมีบางข้อความ HotLinked กับรหัสรูปแบบวิธีการ

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

o   เป็นการสร้างแบบจำลองเชิงกิจกรรมของ Problem Domain

o   แต่ละกิจกรรมจะเกิดจากการโต้ตอบระหว่างกันระหว่าง object นั่นเอง

o   เป็น diagram ที่ใช้เพื่อแสดงกิจกรรมระหว่าง object หรือ class

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

4.Activity Diagram

Activities Diagram แสดงลำดับ กิจกรรมของการทำงาน(Work Flow) สามารถแสดงทางเลือกที่เกิดขึ้นได้ Activity Diagram จะแสดงขั้นตอนการทำงานในการปฏิบัติการ โดยประกอบไปด้วยสถานะต่างๆ ที่เกิดขึ้นระหว่างการทำงาน และผลจากการทำงานในขั้นตอนต่าง ๆ

วงกลมสีดำ คือ จุดเริ่มต้น เรียก Initial State

วงกลมสีดำ มีวงล้อมอีกชั้น คือ จุดสิ้นสุด เรียก Final State

5.Collaboration Diagram

การทำงานร่วมกันของ diagram

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

6.What is UML?

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

7.Goals of UML?

เป้าหมายหลักในการออกแบบของ UML คือ

1.ให้ผู้ใช้พร้อมต่อการใช้งาน ภาษาแบบจำลองการแสดงภาพเพื่อให้สามารถพัฒนาและแลกเปลี่ยนรูปแบบที่มีความหมาย
2.ให้กลไกการขยายและความเชี่ยวชาญในการขยายแนวคิดหลัก
3.เป็นอิสระจากภาษาโปรแกรมเฉพาะและกระบวนการพัฒนา
4.จัดให้มีพื้นฐานความเข้าใจภาษาอย่างเป็นทางการสำหรับการสร้างแบบจำลอง
5.สนับสนุนให้มีการเจริญเติบโตของตลาดเครื่องมือ
OO
6.การสนับสนุนระดับสูงขึ้นแนวความคิดในการพัฒนาเช่นความร่วมมือ กรอบ รูปแบบและส่วนประกอบ
7.บูรณาการปฏิบัติที่ดีที่สุด

8.Why Use UML?

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

9.History of UML?

UML การพัฒนาเริ่มขึ้นในช่วงปลาย 1994 เมื่อ Grady Booch และ Jim Rumbaugh ของ Rational Software Corporation เริ่มงานของพวกเขาใน unifying Booch และ OMT (Object Modeling Technique) วิธีการ ในปี 1995 ฤดูใบไม้ร่วง, Ivar Jacobson และ บริษัท ของเขาได้เข้าร่วม Objectory เหตุผลและความพยายามการรวมกันนี้การรวมใน OOSE (Object – Oriented Software Engineering)

10.When to Use use-case diagram?

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

11.How to Draw: Use Cases Diagrams?

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

เริ่มต้นด้วยรายการลำดับของขั้นตอนที่ผู้ใช้อาจใช้เวลาในการดำเนินการเพื่อให้สามารถทำ ตัวอย่าง เช่น ผู้ใช้วางสินค้ากับ บริษัท ขายอาจทำตามขั้นตอนเหล่านี้

1.ค้นหาแคตตาล็อกและเรียกดูรายการที่เลือก
2.โทรพนักงานขาย
3.ข้อมูลการจัดส่งวัสดุสิ้นเปลือง
4.ข้อมูลการชำระเงินซัพพลาย
5.ได้รับหมายเลขยืนยันจากพนักงานขาย

ขั้นตอนกาสร้างเหล่านี้จะใช้ไดอะแกรมง่าย

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

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

12.Rational Rose?

ให้การออกแบบบูรณาการและสนับสนุนการพัฒนาเพื่อการพัฒนารูปแบบการขับเคลื่อนด้วย UML

Activity Diagram หรือแผนภาพกิจกรรม ใช้อธิบายกิจกรรมที่เกิดขึ้นในลักษณะกระแสการไหลของการทำงาน (Workflow)  จะมีลักษณะเดียวกับ Flowchart  โดยขั้นตอนในการทำงานแต่ละขั้นจะเรียกว่า Activity

การใช้งาน Activity Diagram

  1. อธิบาย กระแสการไหลของการทำงาน (Workflow)
  2. แสดงขั้นตอนการทำงานของระบบ

Activity เป็นการทำงานต่างๆ ได้แก่

  1. การคำนวณผลลัพธ์บางอย่าง
  2. การเปลี่ยนแปลงสถานะ (State) ของระบบ
  3. การส่งค่ากลับคืน
  4. การส่งสัญญาณ
  5. การเรียกใช้ Operation (Method) อื่นๆ เพื่อทำงาน
  6. การสร้าง หรือ ทำลายวัตถุ

ลักษณะของ Activity Diagram
Activity Diagram จะต้องมีจุดเริ่มต้นกับจุดสิ้นสุด และในระหว่างจุดเริ่มต้นกับจุดสิ้นสุดจะมีขั้นตอนหรือ Activity ต่างๆ ของระบบ

รูปแบบการใช้ Activity Diagram
1. แบบทั่วไป

2. แบบมีทางเลือกให้ตัดสินใจ
การกำหนดทางเลือกให้แก่ Activity Diagram ทำได้ 2 วิธี
– ลากลูกศรของแต่ละทางเลือกไปยัง Activity ผลลัพธ์ของทางเลือกโดยตรง
-ลากลูกศรของแต่ละทางเลือกผ่านรูปสี่เหลี่ยมขนมเปียกปูนก่อน

3. แบบมีการทำงานพร้อมๆกันหลายงาน
ให้ใช้เส้นตรงแนวนอนเส้นหนาที่เรียกว่า Swim Lanes มาเป็นสัญลักษณ์ที่ใช้จัดกลุ่มงานที่มีการทำงานพร้อมๆกันหรือการทำกิจกรรมในลักษณะคู่ขนาน

4. แบบการส่งสัญญาณ
ในกระบวนการทำงาน อาจเป็นไปได้ว่าจะมีการส่งสัญญาณบางอย่างในระหว่างการทำงาน เมื่อเกิดการส่ง – รับ สัญญาณ เราเรียกว่าเกิด Activity ได้เช่นกัน

Usecase Diagram

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

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

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

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

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

Usecase Description

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

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 และสัญลักษณ์อื่น ๆ  ที่จะกล่าวถึงอีกต่อไป

1. Class

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

หลักการเขียน Use Case Diagram

สัญลักษณ์ที่สาคัญของ Use Case Diagram มีดังต่อไปนี้

Use Case คือ หน้าที่ที่ระบบต้องกระทำ ใช้สัญลักษณ์รูปวงรี พร้อมทั้งเขียนชื่อ Use Case
ซึ่งต้องใช้คำกริยาหรือกริยาวลีก็ได้

Actor คือ ผู้เกี่ยวข้องกับระบบ ซึ่งรวมทั้ง Primary Actor และ Stakeholder Actor ที่เป็นมนุษย์ ในที่นี้จะใช้สัญลักษณ์รูปคน (Stick Man Icon) เหมือนกัน พร้อมทั้งเขียนชื่อActor ไว้ด้านล่างของสัญลักษณ์ด้วย แต่หากเป็น Actor ที่ไม่ใช่มนุษย์ เช่น ระบบงานอื่นที่อยู่นอกเหนือระบบที่เราสนใจ จะใช้รูปสี่เหลี่ยมแล้วเขียนคำว่า “<<actor>>” ไว้ด้านบนแทน

System Boundary เส้นแบ่งขอบเขตระหว่างระบบกับผู้กระทำต่อระบบ (Use Case กับ Actor) ใช้รูปสี่เหลี่ยมเป็นสัญลักษณ์ พร้อมทั้งเขียนชื่อระบบไว้ด้านใน ซึ่งสำคัญมากทุกการเขียนจะต้องไม่ลืมเขียน System Boundary

Connection คือ เส้นที่ลากเชื่อมต่อระหว่าง Actor กับ Use Case ที่มีปฏิสัมพันธ์กัน ใช้เส้นตรงไม่มีหัวลูกศรเป็นสัญลักษณ์ของ Connection ส่วน Connection ที่ใช้เชื่อมต่อระหว่าง Use Case กับ Use Case กรณีที่ Use Case นั้นมีความสัมพันธ์ซึ่งกันและกัน จะใช้สัญลักษณ์เส้นตรงมีหัวลูกศร พร้อมทั้งเขียนชื่อความสัมพันธ์ไว้ตรงกลางเส้นด้วย โดยเขียนไว้ภายในเครื่องหมาย <<…>>

Extend Relationship เป็นความสัมพันธ์แบบขยายหรือเพิ่ม เกิดขึ้นในกรณีที่บาง Use Case ดำเนินกิจกรรมของตนเองไปตามปกติ แต่อาจจะมีเงื่อนไขหรือสิ่งกระตุ้นบางอย่างที่ส่งผลให้กิจกรรมตามปกติของ Use Case นั้นถูกรบกวนจนเบี่ยงเบนไป ซึ่งเราสามารถแสดงเงื่อนไขหรือสิ่งกระตุ้นเหล่านั้นได้ในรูปของ “Use Case” และเรียกความสัมพันธ์ระหว่าง Use Case ในลักษณะนี้ว่า “Extend Relationship” โดยเรียก Use Case ที่ถูกรบกวนหรือ Use Case ที่ดาเนินงานตามปกติว่า “Base Use Case” และเรียก Use Case ที่ทำหน้าที่รบกวนหรือกระตุ้น Base Use Case ว่า “Extending Use Case” ซึ่งการเขียนสัญลักษณ์ Extend Relationship จะเขียนใน Connection เช่น <<extend>>

Include Relationship ความสัมพันธ์อีกรูปแบบหนึ่งของ Use Case Diagram ก็คือ ความสัมพันธ์แบบเรียกใช้เกิดขึ้นในกรณีที่ Use Case หนึ่งไปเรียกหรือดึงกิจกรรมของอีก Use Case หนึ่งมาใช้เพื่อให้กิจกรรมนั้นเกิดขึ้นจริงใน Use Case ของตนเอง หรือกล่าวให้ง่ายกว่านั้นคือกิจกรรมใน Use Case หนึ่ง อาจจะถูกผนวกเข้าไปรวมกับกิจกรรมของอีก Use Case หนึ่ง เราเรียกความสัมพันธ์ระหว่าง Use Case ในลักษณะนี้ว่า “Include Relationship” โดย Use Case ที่ทาหน้าที่ดึงกิจกรรมมาจาก Use Case อื่นๆ เรียกว่า “Base Use Case” ในขณะที่ Use Case ที่ถูกเรียก หรือถูกดึงกิจกรรมมาใช้ เรียกว่า“Included Use Case” สามารถเขียนเส้น Connection ได้ในทิศทางตรงกันข้ามกับ Extend Relationship โดยเริ่มต้นลากเส้นตรงจาก Base Use Case หันลูกศรชี้ไปที่ Included Use Case แล้วเขียนชื่อว่า <<include>> ไว้ตรงกลาง

หลักการเขียน Sequence Diagram

Sequence Diagram เป็น Diagram ที่ประกอบไปด้วย Class หรือ Object เส้นที่ใช้เพื่อแสดงลำดับเวลา และเส้นที่ใช้เพื่อแสดงกิจกรรมที่เกิดขึ้นจาก Object หรือ Class ใน Diagram ภายใน Sequence Diagram จะใช้สี่เหลี่ยมแทน Class หรือ Object ซึ่งภายในกรอบสี่เหลี่ยมจะมีชื่อของ Object หรือ Class ประกอบอยู่ในรูปแบบ {Object}: Class

กิจกรรมที่เกิดขึ้นจะแทนด้วยลูกศรแนวนอนที่ชี้จาก Class หรือ Object หนึ่งไปยัง Class หรือ Object ตัวต่อไป การระบุชื่อกิจกรรมนั้นอยู่ในรูปแบบ {[Condition]} Function  ชื่อของกิจกรรมจะต้องเป็น Function ที่มีอยู่ใน Class หรือ Object ที่ลูกศรชี้ไป

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

หลักในการเขียน State Diagram

  1. จาก Class Diagramให้ดูว่ามีState Diagram กี่ตัวที่ต้องเขียน  ไม่จำเป็นที่จะต้องเขียน State Diagram ของ ทุก Function ทุก Class Diagram ในบาง Function ที่ไม่ได้มีกิจกรรมที่ซับซ้อนมากมาย ก็ไม่จำเป็นต้องมี StateDiagram
  2. ในแต่ละ Classให้พิจารณาว่าจะมี State อะไรบ้าง โดยยังไม่ต้องคำนึงว่ามีFunction อะไรอยู่บ้าง
  3. จากState ที่มีอยู่ให้เขียน State Diagram ของแต่ละ Function
  4. หากพบว่ามี Stateใดที่จะต้องเพิ่ม ให้เพิ่มเข้าไป เพื่อทำให้ State Diagram สมบูรณ์ขึ้น
  5. ทำข้อ 3 และ 4 จนกว่าจะได้State Diagram ของ 1 Class ที่สมบูรณ์
  6. ทำจนครบทุกๆ ClassในClass Diagram

Leave a Reply

Your email address will not be published. Required fields are marked *