หน่วยการเรียนรู้บทที่4

หน่วยที่ 4 โมเดลที่ใช้ออกแบบเชิงวัตถุ สมรรถนะย่อย(Element of Competency) แสดงความรู้เกี่ยวกับโมเดลที่ใช้ออกแบบเชิงวัตถุ วัตถุประสงค์เชิงพฤติกรรม(Behavioral Objectives 1. อธิบายลักษณะของภาษา UML ได้ 2. บอกข้อดีของ UML ได้ 3. บอกชนิดของไดอะแกรมใน UML ได้ 4. บอกความหมายของ Use Case Diagram ได้ 5. บอกความหมายของ Class Diagram ได้ 6. บอกความหมายของ Sequence Diagram ได้ 7. บอกความหมายของ Collaboration Diagram ได้ 8. บอกความหมายของ State Diagram (Statechart) ได้ 9. บอกความหมายของ Activity Diagram ได้ 10. บอกความหมายของ Component Diagram ได้ 11. บอกความหมายของ Deployment Diagram ได้ 12. บอกความหมายของ Object Diagram ได้

การวิเคราะห์และออกแบบเชิงวัตถุ เนื้อหาสาระ(Content) ภาษา UML ภาษา UML เป็นภาษาที่มีรูปภาพมาตรฐาน (Standard Visual Modeling Language)ภาษาสากลที่ใช้ในการ วิเคราะห์ ออกแบบ และพัฒนาระบบซอฟค์แวร์เชิงวัตถุ ดังนั้ น เอกสารการวิเคราะห์และออกแบบที่ถูกสร้างด้วย ภาษา UML จึงสามารถแลกเปลี่ยนและทำความเข้าใจตรงกันได้ระหว่างผู้ร่วมงานภายในกลุ่มผู้พัฒนาระบบ ภาษา UML มีคุณสมบัติที่สามารถนำเสนอและสนั บสนุนหลักการเชิงวัตถุได้อย่างครบถ้วน ชัดเจน และไม่ผูกติดกับภาษา โปรแกรมภาษาใดภาษาหนึ่ ง ภาษายูเอ็มแอล (Unifed Modeling Language : UML) เป็นภาษาสัญลักษณ์รูปภาพมาตรฐานที่ใช้เพื่อถ่ายทอด ความคิดที่มีต่อระบบให้ออกมาเป็นแผนภาพ ซึ่งประกอบด้วยรูปภาพหรือสัญลักษณ์ตามกฎในการสร้างแผนภาพ ซึ่งเรียกได้ว่ายูเอ็มแอลเป็นภาษาสำหรับใช้ในการสร้างแบบจำลอง เชิงวัตถุ รูปแบบที่ถูกสร้างขึ้นจากภาษา UML สามารถถูกแปลงไปเป็นระบบจริงที่ถูกสร้างขึ้นด้วยภาษาโปรแกรมเชิงวัตถุ ใดก็ได้ อีกทั้งภาษา UML เป็นภาษาที่ง่ายต่อการทำความเข้าใจ ผู้ที่ทำการศึกษาหรือนำไปใช้งานไม่จำเป็นต้องมี ความรู้อื่นใดนอกจากแนวคิดเชิงวัตถุ จากการที่ภาษา UML เป็นภาษาที่มีมาตรฐานผู้ออกแบบและพัฒนาจึงจำเป็น ต้องศึกษาไวยากรณ์ (Syntax) หรือโครงสร้างของภาษา UML ก่อนนำไป ใช้งาน ภาษายูเอ็มแอลประกอบด้วยองค์ ประกอบ 3 ส่วน คือ 1. สัญลักษณ์ทั่วไป (Thing) คือ สัญลักษณ์พื้นฐานที่ถูกใช้งานในการสร้างแผนภาพ (Diagram) ต่าง ๆของภาษา UML ถือว่าเป็นรูปแบบที่เล็กที่สุดของ Model สัญลักษณ์ทั่วไปแบ่งออกเป็น 4 หมวด คือ (1) หมวดโครงสร้าง (Structural Thing) (2) หมวดพฤติกรรม (Behavioral Thing) (3) หมวดการจัดกลุ่ม (Grouping Thing) (4) หมวดคำอธิบาย (Annotation Thing) 2. ความสัมพันธ์ (Relationship) สิ่งที่ใช้แสดงความสัมพันธ์ระหว่างสัญลักษณ์ทั่วไป มี 4 ชนิ ด คือ (1) ความสัมพันธ์แบบขึ้นต่อกัน (Dependency Relationship) : คุณสมบัติของสิ่งหนึ่ งขึ้นอยู่กับคุณสมบัติของอีก สิ่งหนึ่ ง (2) ความสัมพันธ์แบบเกี่ยวข้องกัน (Association Relationship) : สิ่งสองสิ่งที่มีความสัมพันธ์เชื่อมโยงกัน (3) ความสัมพันธ์แบบทั่วไป (Generalization Relationship): คุณสมบัติของสิ่งหนึ่ งเป็นคุณสมบัติพื้นฐานของ อีกสิ่งหนึ่ ง ซึ่งอาจมีคุณสมบัติมากกว่าคุณสมบัติพื้นฐานนั้ น (4)ความสัมพันธ์แบบต้นแบบ (Realization Relationship) : สิงหนึ งถูกสร้างให้มีคุณอีกสิ่งหนึ่ ง 3. แผนภาพ (Diagram) เกิดจากแนวคิดที่ว่าสัญลักษณ์ทั่วไปใด ๆ ก็ตามถ้ามีคุณสมบัติบางประการที่ของภาษา UML แล้ว อีกสิ่งหนึ่ งที่สำคัญ คือ การเลือกใช้งานแผนภาพ สาเหตุที่ภาษา UML ต้องมีแผนภาพที่หลากหลาย เนื่ องจากในระบบที่มีขนาดใหญ่และมีความขับช้อนไม่สามารถใช้แผนภาพชนิ ดใดเพียงแผนภาพเดียวแล้วแสดงมุม มองได้ครบ ทั้งมุมมองเชิงโครงสร้างของระบบ (Static หรือ Structural View) และเชิงพฤติกรรมของระบบ (Dynamic หรือ Behavioral View)

การวิเคราะห์และออกแบบเชิงวัตถุ ดังนั้ น จำเป็นต้องมีการเลือกแผนภาพหนึ่ งมาใช้ในมุมมองหนึ่ ง และเลือกอีกแผนภาพในอีกมุมมองหนึ่ ง เพื่อให้ได้ แผนภาพที่สามารถเสนอมุมมองได้อย่างครบถ้วน การใช้แผนภาพต้องเข้าใจจุดประสงค์ของแต่ละแผนภาพ และเลือก ใช้แผนภาพให้ตรงกับมุมมองที่ต้องการ ซึ่งมุมมอง (Vew) ตามแนวทางของ UML นี้ จะแยกออกเป็น 2 ลักษณะหลัก คือ (1) Static View (Structural View) มุมมองของระบบที่ไม่มีการเคลื่อนไหวหรือคงที่ ไม่ได้มองถึง มุมมองของระบบ ที่มีการเคลื่อนไหว เปลี่ยนแปลงสภาวะขององค์ประกอบที่อยู่ภายในระบบ เช่น Class Diagram 1. เป็นภาษารูปภาพมาตรฐานหรือภาษาสากลที่ใช้ในการพัฒนาชอฟต์แวร์เชิงวัตถุและสามารถใช้ในการเปลี่ยน แบบจำลองได้อย่างสื่อความหมาย รวมถึงการจัดสร้างเอกสารการวิเคราะห์ออกแบบระบบการประยุกต์ใช้ยูเอ็มแอลจะ ทำให้ผู้ร่วมงานมีความเข้าใจและสามารถแลกเปลี่ยนผลของการวิเคราะห์และออกแบบระบบในขั้นตอนต่าง ๆ ได้อย่าง รวดเร็วและตรงกัน 2. สามารถนำเสนอและสนั บสนุนหลักการเชิงวัตถุได้อย่างครบถ้วน ชัดเจน ทำให้นั กพัฒนาระบบสามารถทำความ เข้าใจปัญหาและค้นพบวิธีการแก้ไขได้อย่างรวดเร็วและง่ายยิ่งขึ้น 3. ไม่ผูกติดกับภาษาโปรแกรมภาษาใดภาษาหนึ่ ง คือ สามารถถูกแปลงเป็นระบบจริงด้วยภาษาเชิงวัตถุใดก็ได้ 4. เป็นภาษาที่ง่ายต่อการทำความเข้าใจ 5. สามารถถูกแปลงเป็นภาษาที่ใช้ในการสร้างระบบขึ้นจริงได้อย่างอัตโนมัติ ทำให้ลดเวลาและค่าใช้จ่ายในการ พัฒนาระบบ 6. สนั บสนุนการขยายปรับปรุงระบบ 7. ในการพัฒนาสิ่งต่าง ๆ ความคิดของนั กพัฒนาจะถูกบันทึกในลักษณะของเอกสารที่พร้อมจะนำมาทำความเข้าใจ ได้อย่างรวดเร็ว แผนภาพยูเอ็มแอล (UML Diagram) แผนภาพในภาษา UML แต่ละแผ่นภาพเปรียบเสมือนมุมมองในด้านต่าง ๆ ของระบบที่ ออกแบบกำลังจะพัฒนาโดย ในแต่ละแผนภาพที่แสดงมุมมองต่าง 1 ประกอบด้วยสัญลักษณ์ที่ใช้สื่อความหมายเฉพาะภายใน Diagram นั้ น นอกจากความรู้พื้นฐานที่เกี่ยวข้องกับองค์ประกอบและและแผนภาพของภาษาUML แล้ว สิ่งที่ทำให้การใช้นภาษา UML เป็นไปอย่างประสบผลสำเร็จอีกอย่างก็คือ ผู้ออกแบบพัฒนาจำเป็นต้องเรียนรู้กระบวนการในการเลือกใช้แผนภาพ ตามความเหมาะสม UML (Unified Modeling Language) 1. Unifled รวมสิ่งที่ดีที่สุดจากวิธีการพัฒนาเชิงวัตถุที่มีอยู่ในขณะนั้ นโดยมี บูช (Booch), รัมโบก์ฮ(Rumbaugh) และ จาค็อบสัน (Jacobson) เป็นผู้บุกเบิกหลักของ UML 2. Modeling ใช้สำหรับการนำเสนอตามมุมมองของสิ่งที่มีอยู่จริงเพื่อให้สามารถนำไปใช้กับการออกแบบและพัฒนา ชอฟต์แวร์เชิงวัตถุ 3. Language UML เป็นภาษาที่ใช้สัญลักษณ์เชิงภาพกราฟิกในการนำเสนอตามกฎเกณฑ์และวิธีการที่กำหนดไว้ UML เป็นภาษาที่ใช้ในการวิเคราะห์และออกแบบระบบเชิงวัตถุ ประกอบไปด้วยกฎเกณฑ์ต่าง ๆสามารถใช้ในการสร้าง แบบจำลองได้หลายแบบ ไม่ได้มีการกำหนดว่าแบบจำลองใดที่นั กออกแบบจำเป็นต้องสร้าง UML เป็นมาตรฐานสำหรับงานต่อไปนี้ 1. Visualizing ใช้สัญลักษณ์ภาพกราฟิกในการนำเสนอ 2. Specifying เป็นแบบจำลองที่มีรายละเอียดสมบูรณ์และชัดเจน 3.Constructing สามารถนำไปใช้กับโปรแกรมภาษาที่ต้องการได้โ 4. Documenting ใช้จัดทำเอกสารประกอบระบบได้ ข้อดีของแผนภาพ UML 1.ง่ายต่อการทำความเข้าใจนื่ องจากช้สัญลักษณ์ภาพกราฟิกในการนำเสนอการออกแบบ 2.เป็นส่วนสำคัญที่สุดในการพัฒนาระบบเชิงวัตถุและ SDLC 3.เสนอกลุ่มของ Best Engineering Practices ที่ได้รับการพิสูจน์ แล้วว่าประสบในการพัฒนาระบบขนาดใหญ่ที่มี ความชับซ้อนสูง 4.ช่วยในการสื่อสารระหว่างบุคลากรภายในทีม แสดงรายละเอียดที่สำคัญของการออกแบบในการตรวจสอบ สถาปัตยกรรมของการออกแบบระบบ 5. ไม่ขึ้นกับโปรแกรมภาษาที่ใช้ 6.เป็นพื้นฐานสำคัญสำหรับการทำความเข้าใจกัU Modeling Language 7. สนั บสนุนแนวคิดการพัฒนาระดับสูง เช่น Frameworks Patterns และ ComponentsUML ไม่ใช่ภาษาที่นำมาใช้ ในการเขียนโปรแกรม เป็นภาษาที่เอาไว้อธิบายการทำงานของสิ่งต่าง ๆให้ออกมาในรูปของแผนภาพ ซึ่งตัว UML เองมี วิธีการอธิบายความสัมพันธ์แบบต่าง ๆ ไว้มากมาย

การวิเคราะห์และออกแบบเชิงวัตถุ รูปที่ 4.1 UML Diagram องค์ประกอบของ UML องค์ประกอบของภาษายูเอ็มแอล มี 3 ส่วน คือ 4.2.1 สัญลักษณ์ทั่วไป (Thing) สัญลักษณ์ทั่วไป คือ สัญลักษณ์พื้นฐานที่ถูกใช้สร้างไดอะแกรม แบ่งเป็นหมวดย่อย ได้ ดังนี้ 1. หมวดโครงสร้าง (Structural ได้แก่ ยูสเคส คลาส อินเตอร์เฟซ คอมโพเนนต์ คอลลาบอเรชัน 2. หมวดพฤติกรรม (Behaviora) คือ ส่วนที่เป็นไดนามิกของยูเอ็มเอล ได้แก่ อิเตอร์แอกชัน 3. หมวดการจัดกลุ่ม (Grouping) เพื่อใช้ในการรวบรวมองค์ประกอบต่าง ๆ ในโมเดล ให้เหมาะสม ได้แก่แพ็กเกจ 4. หมวดคำอธิบายประกอบ (Annotational) ได้แก่ โน้ ต (Note) 4.2.2 ความสัมพันธ์ (Relationship) มี 3 ชนิด คือ 1. ความสัมพันธ์แบบพึ่งพา (Dependency Relationship) 2. ความสัมพันธ์แบบเกี่ยวพัน (Association Relationship) 3. ความสัมพันธ์แบบเจเนอรัลไลเซชัน (Generalization Relationship) 4.2.3 ไดอะแกรมต่าง ๆ (Diagram) ยูเอ็มแอลประกอบด้วย 9 ไดอะแกรม แต่ละไดอะแกรมเปรียบเสมือนมุมมองในด้านต่าง ๆ ของระบบที่กำลังพัฒนา ซึ่งช่วยให้การวิเคราะห์และออกแบบระบบเป็นไปได้อย่างมีประสิทธิภาพและง่ายยิ่งขึ้น 1. ยูสเคสไดอะแกรม (Use Case Diagram) ใช้ในการจำลองฟังก์ชันการทำงานของระบบ 2. คลาสไดอะแกรม (Class Diagram) ใช้ในการจำลองคลาสต่าง ๆ ที่จำเป็นในระบบ 3. แอกทิวิตีไดอะแกรม (Activity Diagram) มีหลักการเช่นเดียวกับโฟลว์ชาร์ต 4. สเตตชาร์ตไดอะแกรม (Statechart Diagram) ใช้สำหรับแสดงสถานะของออบเจ็กต์ในระหว่างการทำงาน 5. คอลลาบอเรชันไดอะแกรม (Collaboration Diagram) ใช้แสดงการทำงานร่วมกันของออบเจ็กต์ในระบบ 6. ซีเควนไดอะแกรม (Sequence Diagram) ใช้ในการจำลองกิจกรรมต่าง ๆ ที่เกิดขึ้นกับออบเจ็กต์ในระบบ 7. คอมโพเนนต์ไดอะแกรม (Component Diagran) ใช้สำหรับสร้างโมเดลของคอมโพเนนต์ในระบบ 8. ดีพลอยเมนต์ไดอะแกรม (Deployment Diagram ) ใช้แสดงการติดตั้งใช้งานส่วนประกอบต่าง ๆ ของระบบ 9. ออบเจ็กต์ไดอะแกรม (Object Diagram) แผนภาพเชิงวัตถุ Object Diagram มีแนวคิดพื้นฐานมาจาก Class Diagram แต่มีความแตกต่าง คือ Class Diagram มีรูปแบบเป็นนามธรรม

การวิเคราะห์และออกแบบเชิงวัตถุ 4.3 =ชนิดของไดอะแกรม UML ชนิ ดของไดอะแกรมใน UML มี 3 ชนิ ด ดังนี้ 1. Structural Diagram (1)บางครั้งถูกเรียกว่า Static Model (2) แสดงให้เห็นถึงโครงสร้างของระบบ (3) เน้ นไปที่ส่วนประกอบต่าง ๆ ที่รวมกันเป็นระบบ (4) ใช้ Static Mode( เมื่อต้องการกำหนดรายละเอียดของคลาสแอตทริบิวต์เมธอด โดยจะรวมถึงแพ็กเกจที่ อยู่ภายในระบบ (5) UML ไดอะแกรมที่สนั บสนุนการทำงานแบบนี้ ได้แก่ Class Diagram และ Object Diagram 2. Implementation Diagram (1) ถือเป็น Subset ของ Static Model (2) แสดงให้เห็นถึงส่วนประกอบต่าง ๆ ที่ระบบต้องการสำหรับ Deployment (3) โดยปกติเป็นการนำเสนอการจัดองค์กรในส่วนประกอบของซอฟต์แวร์ทาง Physical เช่นฮาร์ดแวร์หรือ จุดเชื่อมต่อต่าง ๆ (4) UML ไดอะแกรมที่สนั บสนุนการทำงานแบบนี้ ได้แก่ Component Diagram และDeployment Diagram 3. Behavioural Diagram (1) บางครั้งถูกเรียกว่า Dynamic Model (2) แสดงให้เห็นถึงพฤติกรรมการทำงานของระบบ เช่น ระบบมีการตอบสนองต่อเหตุการณ์ภายนอก (3) ช่วยในการกำหนดสิ่งที่ออบเจ็กต์ต้องการ และวิธีการที่ออบเจ็กต์มีการปฏิสัมพันธ์กันผ่านเมธอด (4) ใช้ Dynamic Model ในการออกแบบลอจิกการทำงานและพฤติกรรมของระบบ (5) UML ไดอะแกรมที่สนั บสนุนการทำงานแบบนี้ ได้แก่ Use Case Diagram, InteractionDiagram, State Diagram และ Activity Diagram รูปที่ 4.2 Use Case Diagram

การวิเคราะห์และออกแบบเชิงวัตถุ ยูสเคสไดอะแกรม เมื่อเริ่มต้นการพัฒนาระบบทุกครั้ง ผู้พัฒนาจะต้องเริ่มต้นที่ขั้นตอนแรกคือการค้นหาและ เก็บรวบรวมข้อมูล ความสามารถของระบบที่ผู้ใช้ต้องการซึ่งถือว่าสำคัญมากในการพัฒนาระบบในมาตรฐานยูเอ็ม แอลจะใช้ยูสเคสไดอะแกรม เพื่อเป็นเทคนิ คในการจำลองความต้องการของผู้แสดงความสามารถของระบบ ยูส เคสไดอะแกรมเป็นไดอะแกรมมาตรฐานที่สามารถทำความเข้าใจได้โดยง่าย ส่ วนประกอบสำคัญในยูสเคสไตอะแกรม ส่วนประกอบที่สำคัญของยูสเคสไดอะแกรมมี 3 ส่วน คือ ยูสเคส (Use Case)เส้นแสดงความสัมพันธ์ (Relationship) ในกสร้างยูสคสไดอะแกรมสิ่งสำคัญ คือ การค้นอะไรได้บ้าง โดยไม่สนว่าจะทำงานอย่างไรหรือใช้ เทคนิ คการสร้างอย่างไร 1. ยูสเคส คือ ความสามารถหรือฟังก์ชันที่ระบบจะต้องทำได้ จึงจะถือว่าระบบไม่มีข้อผิดพลาดใช้สำหรับหนดควม ต้องการของระบบผ่านมุมมองของผู้ใช้ โดยเน้ นไปที่ความสัมพันธ์ที่เกิดขึ้นในระบบ (2) ประกอบไปด้วยเหตุการณ์ต่าง ! ที่ถูกกำหนดไว้อย่างสมบูรณ์โดยผ่านแอกเตอร์และแสดงการโต้ตอบระหว่าง แอกเตอร์และระบบ (3) ต้องถูกกระทำโดยแอกเตอร์ และแอกเตอร์เป็นผู้ติดต่อกับระบบตามยูสเคสที่กำหนด (4) ยูสเคสรับข้อมูลจากแอกเตอร์และส่งข้อมูลให้แอกเตอร์ นั่ นคือ แอกเตอร์กระทำกับยูสเคสโดยการส่งข้อมูลเข้า สู่ ระบบตามยูสเคสหรือรอรับค่าที่ระบบส่ งกลับให้ (5) ยูสเคส ถือว่าเป็นการรวบรวมคุณลักษณะความต้องการในระบบอย่างสมบูรณ์ เปรียบสรุปความต้องการของ ลูกค้าออกเป็นข้อ ยูสเคสในยูมแอลแทนด้วยรูปวงรี มีชื่อยูสเคสและทุกยูสเคสจะอยู่ภายใต้กรอบสี่เหลี่ยมซึ่งหมาย ถึงระบบ รูปที่ 4.3 แผนภาพแสดงสัญลักษณ์ของยูสเคส 2. แอกเตอร์ คือ ผู้ที่กระทำกับยูสเคสหรือใช้งานยูสเคส อาจเป็นคนหรือไม่ก็ได้ ซึ่งจะเป็นผู้ที่ส่งข้อมูลหรือรับ ข้อมูล หรือแลกเปลี่ยนข้อมูลข่าวสารกับระบบที่กำลังพัฒนา ชื่อของแต่ละแอกเตอร์ไม่ใช่เป็นชื่อเฉพาะเจาะจง จะไม่ บอกว่าผู้ที่กระทำชื่ออะไร เป็นใคร แต่จะบอกถึงประเภทของแอกเตอร์หรือบทบาทและหน้ าที่ต่อระบบ ในการหา แอกเตอร์ของระบบจะดูที่ว่าใครเป็นผู้ใช้ระบบในฟังก์ชันที่สำคัญ ใครเป็นผู้ดูแลระบบ อุปกรณ์ฮาร์ดแวร์ใดบ้างที่ กระทำการเชื่อมต่อกับระบบ และระบบข้างนอกใดบ้างที่เชื่อมต่อรับส่งข้อมูลกับระบบที่เราสร้าง แอกเตอร์ในยูส เอ็มแอลแทนด้วยรูปคน (Stick Man)

การวิเคราะห์และออกแบบเชิงวัตถุ รูปที่ 4.4แผนภาพแสดงสัญลักษณ์แอกเตอร์เจ้าหน้ าที่พัสดุ 3. เส้นแสดงความสัมพันธ์ เป็นการเชื่อมโยงระหว่างยูสเคสและแอกเตอร์ เป็นเส้นที่แสดงความสัมพันธ์ระหว่าง ยูสเคส มี 2 ชนิ ด คือ (1) ความสัมพันธ์แบบขยาย (Extend Relationship) ยูสเคสหนึ่ งอาจถูกช่วยเหลือโดยการทำงานจากยูสเคสอื่น เช่น ยูสเคสการใส่รหัสอาจถูกช่วยเหลือโดยยูสเคสคำอธิบายการใส่รหัสสัญลักษณ์ในยูเอ็มแอล คือ ลูกศรเส้น ประที่ชี้จากยูสเคสแรกไปยังยูสเคสที่ถูกช่วยเหลือหรือถูกขยาย โดยมีคำว่า \"Extend\" อยู่ในเครื่องหมายสเตอริโอ ไทป์ (Stereotype) <> อยู่ที่กึ่งกลางลูกศร (2) ความสัมพันธ์แบบรวม (Include Relationship) ยูสเคสหนึ่ งอาจจำเป็นต้องอาศัย การทำงานของยูสเคสอื่น สำหรับยูสเคสที่ถูกเรียกใช้โดยยูสเคสอื่น ซึ่งสัญลักษณ์ในยูเอ็มแอลของความสัมพันธ์ คือลูกศรเส้นประชี้ไปยัง ยูสเคสที่ถูกเรียกใช้หรือถูกรวมไว้ โดยมีคำว่า \"บSes\" อยู่ในเครื่องหมายสเตอรีโอไทป์Stereotype) <> อยู่ที่ กึ่งกลางลูกศร ตัวอย่าง ระบบสารสนเทศจัดซื้อจัดจ้างพัสดุมีวิธีการทำงาน คือ เมื่อเจ้าหน้ าที่พัสดุได้รับเอกสารขอจัดซื้อจัด จ้างจากหน่ วยงาน หน่ วยงานจะจัดทำเอกสารจัดซื้อจัดจ้างซึ่งมีประเภทพัสดุ 2 กลุ่ม คือวัสดุและครุภัณฑ์ ในการ ทำเอกสารจัดซื้อจัดจ้างนั้ น เจ้าหน้ าที่พัสดุต้องพิจารณาว่าการจัดซื้อจัดจ้างพัสดนั้ นเพื่อนำมาใช้ในแผนงานใด ใช้งบประมาณจากหมวดใด จากนั้ น เจ้าหน้ าที่พัสดุจะพิจารณาว่าใช้วิธีการใดในการจัดซื้อจัดจ้าง โดยแบ่งเป็น 5 วิธี คือ - การจัดซื้อจัดจ้างวิธีตกลงราคา วงเงินน้ อยกว่า 100,000 บาท - การจัดซื้อจัดจ้างวิธีสอบราคา วงเงินน้ อยกว่า 100,000 บาท แต่ไม่เกิน 2,000,000 บาท - การจัดซื้อจัดจ้างวิธีประกวดราคา วงเงินน้ อยกว่า 2,000,000 บาท - การจัดซื้อจัดจ้างวิธีพิเศษ วงเงินน้ อยกว่า 100,000 บาท โดยมีเงื่อนไขพิเศษ เช่น เป็นพัสดุที่ต้องซื้อเร่งด่วน หรือพัสดุที่ใช้ในราชการลับ เป็นต้น - การจัดซื้อจัดจ้างวิธีกรณีพิเศษ ไม่มีการกำหนดวงเงิน แต่ต้องเป็นการซื้อหรือจ้างจากหน่ วยงานราชการ รัฐวิสาหกิจ ซึ่งสามารถนำเสนอกระบวนการทำงานต่าง ๆ โดยใช้ยูสเคสไดอะแกรมดังแสดงในรูปที่ 4.5

การวิเคราะห์และออกแบบเชิงวัตถุ รูปที่ 4.5 ยูสเคสไดอะแกรมรรบบสารสนเทศจัดซื้อจัดจ้างพัสดุ ประโยชน์ ของยูสเคสไดอะแกรม ยูสเคสไดอะแกรมจะจำลองการทำงานต่าง ๆ ของระบบ ซึ่งจะช่วยให้สามารถมองระบบได้ชัดเจนขึ้นยูสเคส ไดอะแกรมมีประโยชน์ สรุปได้ดังนี้ 1. เพื่อให้ผู้พัฒนาทราบถึงความสามารถของระบบว่าต้องทำอะไรได้บ้าง 2. เพื่อทราบถึงผู้ใช้งานในแต่ละส่วนของระบบ 3. ทำให้การติดต่อสื่อสารระหว่างผู้พัฒนากับลูกค้าหรือระหว่างผู้พัฒนาด้วยกันทำได้ง่าย 4. ใช้ในการทดสอบระบบซอฟต์แวร์ ว่าทำงนได้ครบถ้วนตามความต้องการหรือไม่ เนื่ องจากนั กพัฒนาส่วน ใหญ่มักไม่มีแนวทางหรือชั้นตอนในการทดสอบอย่างเป็นระบบระเบียบชัดเจน ไม่รู้ว่าจะต้องเริ่มทดสอบส่วนใด ก่อน 4.3.2 Class Diagram มีความสำคัญมากที่สุดใน UML ใช้ในการกำหนดคลาสรวมไปถึงการติดต่อกันระหว่าง คลาสในรูปของความร่วมมือระหว่างกันตลอดจนความสัมพันธ์ระหว่างกัน เป็นต้น รูปที่ 4.6 Class diagram

การวิเคราะห์และออกแบบเชิงวัตถุ คลาสไดอะแกรมเป็นไดอะแกรมที่แสดงการใช้งานคลาส ออบเจ็กต์ และมีการสร้างความสัมพันธ์ระหว่างคลาสหรือ ออบเจ็กต์เหล่านั้ น เช่น การสืบทอดคุณสมบัติของคลาส เป็นต้น การหาคลาสของออบเจ็กต์ได้ต้องสามารถจัดหมวด หมู่ของออบเจ็กต์ได้ การหาคลาสจากออบเจ็กต์ควรให้อยู่ในระบบที่กำลังสร้าง เช่น ระบบจัดซื้อ สามารถหาคลาสของ ระบบได้คือ คลาสลูกค้า คลาสใบสั่งซื้อ คลาสใบเสนอราคา คลาสใบเสร็จ รับเงิน เป็นต้น การสร้างคลาสดอะแกรม วัตถุประสงค์ของการสร้างคลาสไดอะแกรมเพื่อแสดงถึงโตรงสร้างของระบบประกอบด้วยคลาสและความสั มพันธ์ ระหว่างคลาส คลาสดอะแกรมถือว่าเป็นไอะแกรมสำคัญมากเพราะถูกใช้เป็นไดอะแกรมหลักในการสร้างไดอะแกรมอื่น อีกหลายประเภท สิ่งสำคัญในการสร้างไดอะแกรม คือ การค้นหาแนวคิดต่าง ที่อยู่ในขอบข่ายของระบบที่กำลังสนใจ มีวิธีการในการค้นหาคลาส ดังนี้ ที่ 1.คำนามปรากฏอยู่ในคำบรรยายยูสเคสจะถูกสร้างเป็นคลาส เช่น คลาสรถยนต์วิชาเรียน คลาสหนั งสือ คลาส สินค้า เป็นต้น 2. คำวิเศษณ์ที่ปรากฎอยู่ในคำบรรยายยุสเคสจะถูกสร้างเป็นแอตทริบิวต์ เช่น สีรถ รุ่นรถยี่ห้อรถ เป็นต้น 3. คำกิริยาที่ปรากฏอยู่ในคำบรรยายยุสเคสจะถูกสร้างเป็นโอเปอเรชัน เช่น สตาร์ตรถ เบรกลงทะเบียน ยกเลิก รายวิชา เป็นต้น สั ญลักษณ์ ตามมาตรฐานยูเอ็มแอล คลาสไดอะแกรมประกอบด้วยสัญลักษณ์ของคลาสและเส้นแสดงความสัมพันธ์ สัญลักษณ์ คลาสประกอบด้วย 3 ส่วน คือ ชื่อคลาส (Class Name) แอตทริบิวต์ และโอเปอเรชันความสัมพันธ์ระหว่างคลาส ซึ่ง ความสัมพันธ์เหล่านี้ สามารถเป็นได้ 3 รูปแบบ ดังนี้ 1. ความสัมพันธ์แบบพึ่งพิง (Dependency) ความสัมพันธ์แบบนี้ เกิดขึ้นเมื่อการเปลี่ยนแปลงที่เกิดขึ้นกับคลาสที่ถูก พึ่งพิง (Independent Class) ส่งผลต่อคลาสที่พึ่งพิง (Dependent Class) คลาสดังกล่าว การจำลองความสัมพันธ์แบบ นี้ สามารถทำได้โดยวาดเส้นตรงแบบประที่มีหัวลูกศรเป็นเส้นโปร่งชี้จากคลาสรองที่พึ่งพิงไปยังคลาสหลักที่ถูกพึ่งพิง 2. ความสัมพันธ์แบบถ่ายทอด (Generalization) คือความสัมพันธ์ระหว่างคลาสหลักและคลาสรองนั่ นเอง การ จำลองความสัมพันธ์แบบนี้ สามารถทำได้โดยวาดเส้นตรงทึบที่มีหัวลูกศรเป็นสี่เหลี่ยมโปร่ง ชี้จากคลาสรองไปยัง คลาสหลัก 3.ความสัมพันธ์แบบเชื่อมโยง (Association) เนความสัมพันธ์อีกชนิ ดหนึ่ งระหว่างตัวอย่าง จากระบบสารสนเทศจัด ซื้อจัดจ้างพัสดุ สามารถค้นหาคลาสของระบบ และแสดงความสัมพันธ์ระหว่างคลาสต่าง ๆ ได้ ดังรูปที่ 4.7คลาส ดังนี้ รูปที่ 4.7คลาสไดอะแกรมระบบสารสนเทศจัดซื้อจัดจ้างพัสดุ

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

การวิเคราะห์และออกแบบเชิงวัตถุ 4.3.4 Collaboration Diagram Collaboration Diagram เป็นไดอะแกรมที่แสดงการติดต่อกันระหว่างออบเจ็กต์โดยเน้ นไปที่โครงสร้างการ จัดองค์กรของออบเจ็กต์ที่มีการรับและส่ งค่าแมสเสจ รูปที่ 4.10 Collaborat Diagram คอลลาเรชันไดอะแกรมมีหน้ าที่ดียวกันกับเควนดอะแกรมแต่ไม่แสดงถึงแนเวลายกเว้นการโต้ตอบกันระหว่า ออบเจ็ก สัญลักษณ์ที่ใช้ประกอบด้วย วัตถุหรือคลาส แทนด้วยรูปสี่เหลี่ยมคล้ายซีเควนไดอะแกรม มีรูปแบบ คือ ชื่อออบเจ็ก/บทบาท : ชื่อคลาสและขีดเส้นใต้เพื่อแสดงว่าเป็นสแตนซ์ แต่ไม่จำเป็นต้องเรียงตามแนวนอนเหมือน ในควนไดอะแกรม มีเส้นเชื่อมกัน สิงก์ (Link) ซึ่งแต่ละลิงก์มีคำธิบายแสขั้นตอนการทำงานตามทิศทางลูกศรโดมี ตัวเลขลำดับกำกับไว้เพื่อบอกว่าขั้นตอนใดทำก่อนทำหลัง ซึ่งแทนแกนเวลาตามด้วยเครื่องหมายทวิภาค และเมส เสจในส่วนของลำดับย่อยนั้ นคอลลาบอเรชันไดอะแกรมจะใช้ตัวเลขและเติมจุดย่อยแล้วใส่ตัวเลขต่อเลขทศนิ ยม เพื่อให้รู้ว่าขั้นตอนนี้ เป็นการทำงานย่อยของเลขลำดับใด คอลลาบอเรชันไดอะแกรมใช้ในการออกแบบทำงาน แสดงถึงลำดับของการโต้ตอบกันระหว่างออบเจ็ก นั่ นคือ แสดงถึงกลุ่มของออบเจ็กต์ที่ทำงานร่วมกันสอดคล้อง กับความหมายของชื่อไดอะแกรม ลูกศรที่ชี้จะชี้ไปในทิศทางเดียวไม่กลับในเส้นเดียวกัน ตัวเลขที่กำกับข้างหน้ า เป็นการบอกลำดับขั้นการทำงานว่าใครส่งก่อนหรือหลังและบวนการใดที่มีการจัดลำดับเป็นอนุกรม คือต้องทำ ขั้นตอนนี้ เสร็จก่อนจึงสามารถทำตัวเลขที่กำกับข้างหน้ าถูกแบ่งย่อยเป็นทศนิ ยม แต่ถ้ากระบวนการใดสามารถทำ พร้อมกันได้ก็ไม่ต้องแยกย่อยเป็นทศนิ ยมเพิ่มขึ้นอีก ให้อยู่ในระดับเดียวกันได้ ในส่วนของการวนช้ำแสดงด้วย เครื่องหมาย *[ ] และในส่วนของเงื่อนไขแสดงภายในเครื่องหมายวงเล็บก้ามปู ตัวอย่าง จากตัวอย่างระบบสารสนเทศจัดซื้อจัดจ้างพัสดุการทำงานของยูสเคส การดำเนิ นการจัดซื้อจัดจ้างซึ่ง มีขั้นตอนการทำงานคือ เจ้าหน้ าที่พัสดุดับเบิลคลิกเมาส์ที่เอกสารขอจัดซื้อจัดจ้างพัสดุที่ต้องการดำเนิ นการก็จะ ไปที่หน้ าจอเอกสารนั้ น สามารถแสดงคอลลาบอเรชันไดอะแกรมทำเอกสารดำเนิ นการจัดซื้อจัดจ้างดังรูปที่ 4.11

การวิเคราะห์และออกแบบเชิงวัตถุ รูปที่ 4.11 คอลลาบอเรชันไดอะแกรมการดำเนิ นการจัดซื้อจัดจ้าง 4.3.5 State Diagram (Statechart) State Diagram (Statechart) ใช้สำหรับการแสดงวงจรชีวิตของคลาสหนึ่ ง ๆ โดยการกำหนดสถานะการทำงาน ของระบบที่ประกอบไปด้วย States, Transitions, และ Events เป็นหลัก รูปที่ 4.12 State Diagram (Statechart) สเตตชาร์ตไดอะแกรมบอกถึงพฤติกรรมของคลาสต่าง ๆ ในระบบว่ามีสถานะอะไรบ้างจะเปลี่ยนสถานะเมื่อเกิด เหตุการณ์อไร สเตตชาร์ตไดอะแกรมของแต่ละคลาสประกอบด้วยสถานะที่สามารถเกิดขึ้นได้ เช่น คนอยู่ใน สถานะกำลังเดิน รถอยู่ในสถานะกำลังวิ่ง เป็นต้น เมื่อเวลาผ่านไปหรือมีเหตุการณ์บางอย่างเกิดขึ้นย่อมทำให้เกิด การเปลี่ยนสถานะหรือเปลี่ยนพฤติกรรมได้ สเตตชาร์ตไดอะแกรมในยูเอ็มแอลมีจุดเริ่มต้นสถานะและจุดสิ้นสุด สถาน: โดยจุดเริ่มต้นมีสัญลักษณ์เป็นรูปวงกลมทึบและจุดสิ้นสุดสถานะเป็นรูปวงกลมโปร่งล้อมรอบวงกลมทึบ ข้างใน ส่วนสถานะในไดอะแกรมถูกแสดงเป็นรูปสี่เหลี่ยมหัวมนรูปร่างเหมือนแคปซูล และเชื่อมกันด้วยเส้นลูก ศรขี้จากสถานะหนึ่ งไปยังอีกสถานะหนึ่ ง สามารถเขียนคำอธิบายเหตุการณ์ที่ทำให้เปลี่ยนสถานะตรงเส้นลูกศร ได้ ดังตัวอย่างรูปที่ 4.13 ตัวอย่าง สถานะของการรอชำระเงิน คือเมื่อมีการชำระเงินและป้อนรายละเอียดต่าง ๆ สถานะก็จะเปลี่ยนจาก การรอเป็นปรับปรุงข้อมูลและเสร็จสมบูรณ์

การวิเคราะห์และออกแบบเชิงวัตถุ รูปที่ 4.13 สเตตชาร์ตไดอะแกรม 4.3.6 Activity Diagram Activity Diagram มีลักษณะคล้ายกับ Flow Chart โดยปกติแล้วจะเป็นการแสดงรายละเอียดของกิจกรรมต่าง ๆ ที่ มีความชับซ้อนสูงและเกิดขึ้นภายใน Use Case รูปที่ 4.14 Activity Diagram

การวิเคราะห์และออกแบบเชิงวัตถุ Package จะทำหน้าที่จัดเก็บระบบที่มีความชับซ้อนมากออกเป็นส่วน ๆ ที่มีการจัดกลุ่มตามหมวดหมู่ที่เกิดขึ้น หลาย ๆ โครงการ ใช้ Package ในการแสดงรายละเอียดที่ Use Case ที่เกี่ยวข้องในการส่งมอบงาน รูปที่ 4.15 Package แอกทิวิตีไดอะแกรมแสดงขั้นตอนการทำงานของยูสเคสเช่นเดียวกับชีเควนไดอะแกรมและคอลลาบอเรชัน ไดอะแกรม แต่เน้ นที่งานย่อยของวัตถุ ส่วนเอกทิวิตีไดอะแกรมจะเปลี่ยนสถานะได้โดยไม่ต้องมีเหตุการณ์ที่ กำหนดไว้ในไดอะแกรมมากระทำก่อน แต่เปลี่ยนสถานะเองตามกระบวนการทำงานคล้ายกับผังงานโปรแกรม สัญลักษณ์ในแอกทิวิตีไดอะแกรม มีแอกทิวิตี คือ กิจกรรมที่แสดงด้วยสีเหลี่ยมมนเหมือนแคปดูล เชื่อมโยงกัน ด้วยลูกศรเพื่อแสดงลำดับการทำงาน และมีเส้นทึบหนาในแนวนอนใช้วาดในกรณีที่ต้องรอแอกทิวิตีอื่นเสร็จหมด ก่อน จึงทำแอกทิวิตีถัดไปได้ โดยมีเส้นลูกศรเข้ามารวมกันที่จุดเดียว สวิมเลน(Swimlane) เป็นการแบ่งกลุ่มแอก ทิวิตีเป็นเลนเหมือนสระว่ายน้ำ โดยแบ่งเป็นช่องในแนวดิ่งและกำหนดแต่ละช่องด้วยชื่อของออบเจ็กต์ไว้แถวบน สุด ตัวอย่าง จากระบบสารสนเทศจัดซื้อจัดจ้างพัสดุแสดงภาพรวมของระบบได้โดยใช้แอกทิวิตีไดอะแกรม รูปที่ 4.16 แอกทิวิตีไดอะแกรมภาพรวมรวมระบบสารสนเทศจัดซื้อจัดจ้างพัสดุ

การวิเคราะห์และออกแบบเชิงวัตถุ 4.3.7 Component Diagram Component Diagram ใช้สำหรับแสดงรายละเอียดของคอมโพเนนต์ต่าง ๆ ที่ใช้ภายในช่วงเวลาของ Runtime ซึ่งจะรวมไปถึง Source Code, Binary Code และ Executable Component รูปที่ 4.17 Component Diagram คอมโพเนนต์ไดอะแกรม แสดงความสัมพันธ์ที่เชื่อมต่อกันระหว่างชอฟต์แวร์คอมโพเนนต์ในประกอบด้วยไฟล์ อะไรบ้าง ซึ่งอาจเนฟล์ซอร์สโค้ด (Source Code) ไฟล์ไบนารี (Binary Code)และไฟล์เอ็กซิคิวต์ (ExecutablCode) การตั้งชื่อของคอมโพเนนต์ในคอมโพเนนต์ไดอะแกรมจะใช้ชื่อของคลาสจากคลาสไดอะแกรม ไม่ใช่ชื่อของอินสแตน ซ์ (Instance) สัญลักษณ์ของคอมโพเนนต์ในคอมโพเนนต์ไดอะแกรมถูกแสดงเป็นสี่เหลี่ยม ประกอบด้วยสี่เหลี่ยม เล็ก 2 รูป ติดอยู่ที่ขอบด้านซ้าย และอาจเชื่อมต่อกันด้วยเส้นแสดงความสัมพันธ์ ตัวอย่าง จากระบบสารสนเทศจัดซื้อจัดจ้างพัสดุสามารถสร้างคอมโพเนนต์ไดอะแกรมที่แสดงองค์ประกอบของ ระบบซอฟต์แวร์ที่ประกอบด้วยไฟล์ที่สร้างโดย Oracle Developer ซึ่งมีส่วนขยายของไฟล์คือ .fmx และ .mทx โดย ไฟล์ทั้งหมดทำงานอยู่บนไฟล์เมนู ดังนี้ รูปที่ 4.18 คอมโพเนนต์ไดอะแกรมระบบสารสนเทศจัดซื้อจัดจ้างพัสดุ

การวิเคราะห์และออกแบบเชิงวัตถุ 4.3.8 Deployment Diagram Deployment Diagram ยอมให้ผู้ใช้สามารถมองเห็นถึงวิธีการ (How) ที่ซอฟต์แวร์ถูกนำไปใช้ โดยปกติจะใช้ สำหรับการกำหนด Configuration ของระบบตามมุมมองของสถาปัตยกรรมทางด้านฮาร์ดแวร์เป็นหลัก รูปที่ 4.19 Deployment Diagram ดีพลอยเมนต์ไดอะแกรมแสดงการเชื่อมต่อของอุปกรณ์ ฮาร์ดแวร์ในระบบและมักใช้ร่วมกับคอมโพเนนต์ใดอะ แกรม โดยข้างในฮาร์ดแวร์อาจประกอบด้วยชอฟต์แวร์คอมโพเนนต์ ดีพลอยเมนต์ไดอะแกรมแสดงอยู่ในรู ปอินสแนซ์และแสดงในช่วงเวลาของการรันหรือระหว่างการเอ็กซิคิวตั ดังนั้ นไฟล์คอมโพเนนต์ ที่ไม่ได้ใช้สำหรับรัน จะไม่ปรากฏในไดอะแกรมนี้ แต่มีในคอมโพเนนต์ของไฟล์ที่ใช้ทำงา ษณ์ของดีพลอยเมนต์ดอะแกรมเป็นการเชื่อม กันระหว่างโหนดซึ่งคือฮาร์ดแวร์ก็จะบรรจุ ซอฟต์แวร์คอมโพเนนต์ที่ถูกแสดงด้วยสัญลักษณ์ของคอมโพเนนไว้ข้าง ใน แต่ละคอมโพแนนด์ เชื่อม ช้ความสัมพันธ์แบบพึ่งพิง โดยชี้จากคอมโพเนนต์ที่ขอใช้บริการไปยังคอมโพเนนต์อื่น นนต์ไดอะแกรมโดยบนลูกศรอาจมีคำกำกับอยู่ภายใด้เครื่องหมายสเตอโอไทป์เพื่อสร้างความ หากจำเป็นสัญลักษณ์ ของโหนดถูกแสดงด้วยรูปลูกบาศก์ 3 มิติ ภายในบรรจุชื่อที่แสดงถึงประเภทของโหนด ถ้าเป็นโหนดอินสแตนซ์จะมี ทั้งชื่อจริงและประเภทของโหนด และต้องขีดเส้นได้ที่ชื่อของโหนดเพื่อแสดงว่าเป็นอินสแตนซ์ หรือออบเจ็กต์ ชื่อ ของโหนดเป็นชื่อเฉพาะ ส่วนประเภทของโหนดเป็นการบ่งบอกว่าโหนดนั้ นคือ อุปกรณ์ชนิ ดอะไร โหนดอาจถูกเชื่อม ต่อกับโหนดอื่นด้ ซึ่งแสดงว่าอุปกรณ์แต่ละตัวมีการติดต่อสื่อสารกันอย่างไรผ่านระบบเครือข่าย อาจมีคำกำกับภาย ใต้สัญลักษณ์สเตอโอไทป์เพื่อบอกว่าทั้ง 2 โหนดนี้ เชื่อมต่อกัน ด้วยการสื่อสารวิธีใด ซึ่งก็คือชนิ ดของช่องสัญญาณ ของเครือข่ายหรือโปรโตคอล เช่น <>เป็นต้น ตัวอย่าง จากระบบสารสนเทศจัดซื้อจัดจ้างพัสดุ สามารถสร้างดีพลอยเมนต์ใดอะแกรมการออกแบบ สถาปัตยกรรมทางกายภาพของระบบที่เป็นไคลเอนต์/ชิร์ฟเวอร์ ดังนี้ รูปที่ 4.20 ดีพลอยเมนต์ไดอะแกรมระบบสารสนเทศจัดซื้อจัดจ้างพัสดุ

การวิเคราะห์และออกแบบเชิงวัตถุ 4.3.9 Object Diagram Object Diagram หมายถึง แผนภาพเชิงวัตถุ มีแนวคิดพื้นฐานมาจาก Class Diagramแต่มีความแตกต่างคือ Class Diagram มีรูปแบบเป็นนามธรรม ซึ่งประกอบด้วยคลาสและความสัมพันธ์ส่วน Object Diagram เป็น แผนภาพที่แสดงถึงพฤติกรรมของระบบจริง จุดประสงค์คือเพื่อจับภาพมุมมอง คงที่ของระบบในช่วงเวลาหนึ่ ง แผนภาพเชิงวัตถุแสดงถึงภาพรวมของระบบที่กำลังทำงานในช่วงเวลาหนึ่ ง ตัวอย่างเช่นเราพิจารณารถไฟวิ่ง ตอนนี้ ถ้าคุณใช้เวลารถไฟวิ่ง แล้วคุณจะพบภาพคงที่ของมัน มีดังต่อไปนี้ สถานะเฉพาะกำลังทำงาน จำนวนผู้ โดยสารโดยเฉพาะ ซึ่งจะเปลี่ยนแปลงหากถ่ายในเวลาที่แตกต่างกัน ที่นี่ เราสามารถจินตนาการภาพของรถไฟวิ่ง เป็นวัตถุที่มีค่ข้างต้น และนี่ คือความจริงสำหรับระบบที่เรียบง่ายหรือซับซ้อนในชีวิตจริง โดยสรุปแล้วอาจกล่าว ได้ว่าแผนภาพเชิงวัตถุนั้ นใช้สำหรับ การสร้างต้นแบบของระบบ วิศวกรรมย้อนกลับ การสร้างแบบจำลอง โครงสร้างข้อมูลที่ชับซ้อนทำความเข้าใจกับระบบจากมุมมองการปฏิบัติ วิธีการเขียนแผนภาพเชิงวัตถุ พิจารณาชณะเขียน แต่ที่นี่ ไดอะแกรมจะถูกพิจารณาจากมุมมองระดับบนสุด ซึ่งต้องพิจารณาประเด็นที่สำคัญ Object Diagram มีแนวทางการเขียนคล้ายกับ Class Diagram มีคุณสมบัติมากมายที่ต้อง 1. ชื่อของ Object Diagram ควรมีความหมายเพื่ออธิบายลักษณะของระบบ 2.แต่ละองค์ประกอบและความสัมพันธ์ควรระบุล่วงหน้ า 3.ควรระบุความรับผิดชอบ (คุณสมบัติและวิธีการ) ของแต่ละ Object อย่างชัดเจน 4. สำหรับแต่ละคลาสควรระบุจำนวนคุณสมบัติขั้นต่ำ เนื่ องจากคุณสมบัติที่ไม่จำเป็นจะทำให้ไดอะแกรมมี ความซับซ้อน 5. ใช้บันทึกย่อทุกครั้งที่จำเป็นเพื่ออธิบายบางแง่มุมของแผนภาพ ในตอนท้ายของการวาดควรเข้าใจผู้ พัฒนา/Coder อย่างไรก็ตาม Class Diagram เป็นแนวคิดเชิงมโนภาพ แต่ Object Diagram เปรียบเสมือนวัตถุจริง ๆ เพื่อให้ เห็นภาพเราอาจเปรียบ Class Diagram คือพิมพ์เขียวของงานก่อสร้าง ขณะที่ ObjectDiagram เปรียบเสมือน แบบจำลองของงานที่จะสร้าง ซึ่งการเขียนแผนภาพเชิงวัตถุ มีขั้นตอน ดังนี้ 1. วิเคราะห์ระบบและตัดสินใจว่าอินสแตนซ์ใดมีข้อมูลและการเชื่อมโยงที่สำคัญ 2. พิจารณาเฉพาะกรณีเหล่านั้ นซึ่งจะครอบคลุมการทำงาน 3. ทำการปรับให้เหมาะสมเนื่ องจากจำนวนอินสแตนซ์ไม่จำกัดก่อนที่จะวาดไดอะแกรมวัตถุสิ่งต่อไปนี้ ควร คำนึ งถึงสิ่งเหล่านี้ 1.แผนภาพวัตถุประกอบด้วยวัตถุ 2.ตัวเชื่อมโยงในไดอะแกรมวัตถุถูกใช้เพื่อเชื่อมต่อวัตถุ 3.วัตถุและตัวเชื่อมโยงเป็นองค์ประกอบสองอย่างที่ใช้สร้างไดอะแกรมวัตถุ รูปที่ 4.21 Object Diagram

การวิเคราะห์และออกแบบเชิงวัตถุ ข้อกำหนดเกี่ยวกับ Use Case 1. ขั้นตอนการพัฒนาชอฟต์แวร์ รูปที่ 4.22 ขั้นตอนการพัฒนาชอฟต์แวร์ 2. แหล่งที่มาหลักของข้อบกพร่อง 3. Bug เกิดขึ้นได้จากหลาย ๆ สาเหตุ แต่สาเหตุหลักสามารถตรวจสอบได้จาก Specification รูปที่ 4.23 Bug

การวิเคราะห์และออกแบบเชิงวัตถุ 4. ความพยายามในการแก้ไขข้อบกพร่อง รูปที่ 4.24 ความพยายามในการแก้ไขข้อบกพร่อง Requirement หรือความต้องการคืออะไร 1. IEEE Standard Glossary of Software Engineering Terminology : เป็นเงื่อนไขหรือความสามารถที่ ต้องการของผู้ใช้ในการแก้ไขปัญหาเพื่อให้เป็นไปตามวัตถุประสงค์ที่กำหนดไว้ 2. Requirement เป็นการระบุว่าอะไรที่ต้องการพัฒนา ใช้แสดงถึง \"What\" ไม่ใช่ \"How\" ลักษณะของ Requirement ไม่มีความต้องการของระบบใดที่เหมือนกัน อย่างไรก็ตามมีกระบวนการหลายอย่างที่ช่วยในการค้นหาและ กำหนดความต้องการของระบบ เช่น วัตถุประสงค์ ขนาด และความชับซ้อนของระบบ เป็นต้น 1. Functional Requirement (1) ความต้องการที่เป็นฟังก็ชันการทำงาน (Function Requirement) เป็นสิ่งที่ระบบควรต้องทำหรือเป็นหน้ าที่ หลักของระบบ ความต้องการแบบนี้ ถือเป็นบริการที่ซอฟต์แวร์ควรมี (2)โดยปกติถูกนำเสนอเป็นขั้นตอนการทำงานที่ประกอบด้วยกิจกรรมต่าง ๆ ที่เกี่ยวข้องกับผู้ปฏิบัติงาน (3) เทคนิ คในการนำเสนอ ได้แก่ Use Cases, Requirements List \"Shall\" Statement 2. Non-Functional Requirement ความต้องการที่ไม่ได้เป็นฟังก์ชันการทำงาน จะไม่เกี่ยวข้องโดยตรงกับงานหรือฟังก์ชันหลัก - ความสามารถในการใช้งาน (Usability) ได้แก่ Human Factor, Help, Documentation - ประสิทธิภาพของระบบ ได้แก่ Response Time, Throughput, Resource Usage - ความน่ าเชื่อถือของระบบ (Reliability) ได้แก่ Failure Rate, Recoverability, Availablity - ความสะดวกในการเคลื่อนย้ายไปยังสภาพแวดล้อมใหม่ (Portability) - การสนั บสนุนด้านต่าง ๆ เช่น Maintainability, Internationalization Use Case Modeling 1. อาศัยแนวคิดที่ว่า \"อะไรคือสิ่งที่ระบบต้องทำสำหรับผู้ใช้แต่ละคน\" 2.ยูสเคสไดอะแกรมเป็นเทคนิ คในการพัฒนาแบบหนึ่ งที่ถูกรวบรวมไว้ใน UML ถูกคิดค้น โดย อีวาร์ จาค็อบ สัน ในปี ค.ศ. 1994 3.ช่วยในการค้นหาความต้องการของระบบตามมุมมองของผู้ใช้ 4. ใช้สำหรับการตรวจสอบติดตามการเปลี่ยนความต้องการของระบบตามฟังก์ชันการทำงาน และการทำงาน จริงที่เกิดขึ้นภายในระบบ (1) ใช้เป็นกลไกสำหรับขับเคลื่อนการดำเนิ นการของการพัฒนาระบบ (2) เป็นเครื่องมือที่ใช้ในการค้นหาคลาส (3) ใช้เป็นพื้นฐานในการทดสอบระบบ (4) ใช้เป็นพื้นฐานสำหรับการประเมินราคาของชอฟต์แวร์

การวิเคราะห์และออกแบบเชิงวัตถุ Development of New Use Case Template 1. ระบุทุก ๆ Actor ที่เป็นผู้ใช้ระบบ 2. กำหนด Use Case ของระบบ 3. กำหนดความสัมพันธ์ระหว่าง Actor และความสัมพันธ์ระหว่าง Use Case 4. สร้าง Use Case Diagram ในระดับบนสุด 5. เพิ่มเติมรายละเอียดของ Use Case Diagram ที่แสดงถึงขอบเขตของระบบ 6. กำหนดรายละเอียดของแต่ละ Use CaseGraphical Notation Graphical Notation 1. สัญลักษณ์ของ Actor ถูกนำเสนอโดย Stick Man โดยมีการระบุชื่อของ Actor ไว้ด้านล่างในรูปของ Role เป็นหลัก 2. สัญลักษณ์ของ Use Case ถูกนำเสนอโดย Elipse ที่มีการระบุชื่อของยูสเคสไว้ภายใน รูปที่ 4.25 สัญลักณษ์ของ Actor และ Use Case What is an Actor 1. ใช้สำหรับการนำเสนอสิ่งที่ต้องการติดต่อกับระบบ 2. นำเสนอบทบาท (Role) ของสิ่งที่อยู่ภายนอกระบบ เช่น ผู้ใช้ ฮาร์ดแวร์ หรือระบบอื่น ๆที่มีการติดต่อกับ ระบบที่ต้องการพัฒนา (อยู่ภายนอกระบบ) 3. Actor สื่อสารกับระบบโดยการติดต่อกันผ่านการส่งหรือรับแมสเสจระหว่างกัน 4. แต่ละยูสเคสจะไม่ถูกจำกัดอยู่กับหนึ่ ง Actor 5. จาค็อบสัน (1992) ได้จำแนก Actor ออกเป็น 2 ชนิ ด ดังนี้ (1) Primary Actor : เป็นผู้ที่ได้รับประโยชน์ โดยตรงจากระบบ (ถูกกำหนดไว้ด้านซ้ายมือของยูสเคสไดอะแกรม เสมอ) (2) Secondary Actor : เป็นผู้ที่ให้บริการหรือให้การสนั บสนุน Actor อื่น (ขวามือ)Secondary Actor ไม่ สามารถเกิดขึ้นได้โดยปราศจาก Primary Actor Actor Personalities 1. Initiator : ทำหน้ าที่กระตุ้นให้เกิดการทำงานของยูสเคส 2. External Server : ทำหน้ าที่ให้บริการกับระบบผ่านการทำงานภายในยูสเคส 3. Receiver : ทำหน้ าที่ในการรับข้อมูลจากยูสเคสเพียงอย่างเดียว 4. Facilitator : ทำหน้ าที่สนั บสนุนการติดต่อกับระบบของ Actor อื่น

การวิเคราะห์และออกแบบเชิงวัตถุ คุณสมบัติของ Actor 1. Actor อาจใช้ได้กับหลาย ๆ Use Case 2. Use Case อาจติดต่อได้กับหลาย ๆ Actor 3. การติดต่อกันสามารถนำเสนอผ่านสัญลักษณ์เส้นตรงได้ รูปที่ 4.26 สัญลักณษ์ของ Actor Relationship Between Actor 1. เนื่ องจาก Actor คือคลาส ดังนั้ นจึงสามารถมีความสัมพันธ์กันได้เช่นเดียวกับคลาสแต่สำหรับใน Use Case Diagram ความสัมพันธ์ที่ถูกระบุไว้เพียงอย่างเดียว คือ Generalization เพื่อใช้สำหรับแสดงการโต้ตอบระหว่าง Actor จำนวนหนึ่ งเท่านั้ น 2.Generalizatation จะเกิดขึ้นเมื่อบทบาทของ Actor จะถูกกำหนดให้อยู่ในรูปของ Actor Super-class ซึ่งจะมี ลักษณะเป็นการสืบทอดจาก Actor นั่ นเอง รูปที่ 4.28 สัญลักณษ์ของ Relationship Between Actor

การวิเคราะห์และออกแบบเชิงวัตถุ ลักษณะของ Use Case 1. Use Case เป็นลำดับของ Tansaction ที่ถูกดำเนิ นการโดยระบบ ซึ่งให้ผลลัพธ์ที่ชัดเจน 2. Use Case ถูกกำหนดในรูปจำนวนและลำดับการกระทำที่เกิดขึ้นในระบบ 3. Use Case จะเกิดขึ้นจากการกระทำของ Actor เสมอ ทั้งทางตรงหรือทางอ้อมเพื่อให้ระบบทำงานตาม Use Case ที่ปรากฎ 4. Use Case ต้องให้ผลลัพธ์กับ Actor ไม่ว่าจะเป็นทางใดทางหนึ่ งเสมอ 5. Use Case ต้องมีความสมบูรณ์ในตัวโดยไม่ต้องมีการแยกรายละเอียดให้ลึกลงไปในระดับถัดไป รูปที่ 4.28 Use case Use Case Name 1.การกำหนดอยูสเคสจะใช้รูปแบบดังต่อไปนี้ คำริยา + คำนามในรูปของออบเจ็กสั่งซื้อ (Place Order) ร้องขอ บริการ (Request Service) เป็นต้น 2.มัดระวังการใช้คำกริยาที่มีความหมายคลุมเครือ เช่น ทำ (Do) หรือกระบวนการ 3.ใช้คำกริยาที่มีความหมายชัดเจนได้ทันที เช่น เข้าสู่ระบบ (Login) ค้นหา (Search)(Approve) แจ้งให้ทราบ (Notify) เป็นต้น 4. ใช้คำประเภท Active Voice ไม่ใช่ Passive 5. ควรเลือกใช้ชื่อตามมุมมองของผู้ใช้ ไม่ใช่ตัวมุมมองของระบบ How Actor and Use Case Interact 1. สัญลักษณ์เส้นตรงที่ลากระหว่าง Actor กับ Use Case ใช้เพื่อแสดงให้เห็นว่า Actor มีการติดต่อกับ Use Case ส่วนหัวลูกศรใช้ในการกำหนดทิศทางและความสัมพันธ์ระหว่าง Actor และ Use Case (1) ทิศทางความสัมพันธ์โดยปกติจะเป็นสองทิศทาง (2) กำหนดความสัมพันธ์ระหว่างแต่ละ Actor และ Use Case 2. กำหนดร้ายละเอียดอย่างย่อสำหรับความสัมพันธ์ระหว่างกัน รูปที่ 4.29 How Actor and Use Case lnteract

การวิเคราะห์และออกแบบเชิงวัตถุ Relationship Between Use Case 1. Use Case หนึ่ ง ๆ อาจมีการใช้งานร่วมกับ Use Case อื่น ๆ ซึ่งลักษณะดังกล่าวเรียกว่าความสัมพันธ์ระ หว่างยูสเคส 2. ความสัมพันธ์ระหว่างยูสเคส ได้แก่ Extends, Includes/Uses และ Generalization (1) ความสัมพันธ์ระหว่างยูสเคสช่วยลดความซ้ำช้อนของงานตลอดจนความขัดแย้งต่าง ๆภายในแต่ละยูสเคส (2) การกำหนดความสัมพันธ์ควรทำในมุมมองของวิธีการเชิงวัตถุมากกว่าการใช้วิธีการแบบFunctional Decomposition Relationship : Generalization เกิดขึ้นเมื่อ Use Case จำนวนหนึ่ งมีพฤติกรรมบางส่วนที่เหมือนกัน พฤติกรรมดังกล่าวจะถูกนำมากำหนด ให้อยู่ในรูปของ Use Case หนึ่ ง ๆ ที่สามารถนำไปใช้ได้โดย Use Case อื่น ๆ ที่มีพฤติกรรมบางส่วนที่เหมือนกัน เช่น ในกรณีของการชำระเงิน (Make Payment) ซึ่งอาจมีการสืบทอดไปที่เป็น Pay Cash หรือ Pay by Credit Card นั่ นคือ Use Case สืบทอดทั้งหมดจะต้องถูกใช้ร่วมกับUse Case หลักในการทำงานเสมอ รูปที่ 4.30 Relationship Generalization Relationship : Include 1. Use Case ที่มีความสัมพันธ์แบบ include จะต้องทำงานร่วมกับ Use Case ที่ถูกกำหนดไว้เสมอ 2. ใน UML รุ่นแรก ๆ จะเรียกความสัมพันธ์แบบนี้ ว่า Use 3. ความสัมพันธ์แบบนี้ Use Case ย่อยจะถูกประมวลผลโดยเป็นส่วนหนึ่ งของ Use Caseหลักนั่ นคือการ ทำงานของ Use Case หลักจะไม่สมบูรณ์หากไม่มีการประมวลผล Use Case ย่อย รูปที่ 4.32 Relationship lnclde

การวิเคราะห์และออกแบบเชิงวัตถุ สรุ ปสาระสำคัญ ภาษาสากลที่ใช้ในการวิเคราะห์ออกแบบและพัฒนาระบบชอฟต์แวร์เชิงวัตถุ ดังนั้ นเอกสารการวิเคราะห์และ ภาษา UML เป็นภาษาที่มีรูปภาพมาตรฐาน (Standard Visual Modeling Language) และเป็นออกแบบที่ถูกสร้าง ด้วยภาษา UML จึงสามารถแลกเปลี่ยนและทำความเข้าใจตรงกันได้ระหว่างผู้ร่วมงานภายในกลุ่มผู้พัฒนาระบบ ภาษา UML มีคุณสมบัติที่สามารถนำเสนอและสนั บสนุนหลักการเชิงวัตถุได้อย่างครบถ้วนชัดเจนและไม่ผูกติดกับ ภาษาโปรแกรมภาษาใดภาษาหนึ่ ง ภาษา UML (Unifed Modeling Language) เป็นภาษาสัญลักษณ์รูปภาพมาตรฐานที่ใช้เพื่อถ่ายทอดความคิดที่มีต่อ ระบบให้ออกมาเป็นแผนภาพ ซึ่งประกอบด้วยรูปภาพหรือสัญลักษณ์ตามกฎในการสร้างแผนภาพ ซึ่งเรียกได้ว่ายู เอ็มแอลเป็นภาษาสำหรับใช้ในการสร้างแบบจำลองเชิงวัตถุ รูปแบบที่ถูกสร้างขึ้นจากภาษา UML สามารถถูกแปลงไปเป็นระบบจริงที่ถูกสร้างขึ้นด้วยภาษาโปรแกรมเชิงวัตถุ ใดก็ได้ อีกทั้งภายา UML เป็นภาษาที่ง่ายต่อการทำความเข้าใจ ผู้ที่ทำการศึกษาหรือนำไปใช้งานไม่จำเป็นต้องมี ความรู้อื่นใตนอกจากแนวคิดเชิงวัตถุ จากการที่ภาษา UML เป็นภาษาที่มีมาตรฐาน ผู้ออกแบบและพัฒนาจึงจำเป็น ต้องศึกษาไวยากรณ์ (Syntax) หรือโครงสร้างของภาษา UML ก่อนนำไปใช้งาน ภาษาเอ็มแอล ประกอบด้วยองค์ ประกอบ 3 ส่วน คือ 1. สัญลักษณ์ทั่วไป (Thing คือ สัญลักษณ์พื้นฐานที่ถูกใช้งานในการสร้างแผนภาพ (Diagram) ต่าง ๆของภาษา UML ถือว่าเป็นรูปแบบที่เล็กที่สุดของ Model สัญลักษณ์ทั่วไปแบ่งออกเป็น 4 หมวด คือ (1) หมวดโครงสร้าง (Structural Thing) (2) หมวดพฤติกรรม (Behavioral Thing) (3) หมวดการจัดกลุ่ม (Grouping Thing) (4) หมวดคำอธิบาย (Annotation Thing) 2.ควาามสัมพันธ์ (Relationship)เป็นสิ่งที่ใช้แสดงความสัมพันธ์ระหว่างสัญลักษณ์ทั่วไป มี คือ (1) ความสัมพันธ์แบบขึ้นต่อกัน (Dependency Relationship) คือ คุณสมบัติของสิ่งหนึ่ งขึ้นอยู่กับ คุณสมบัติของ อีกสิ่งหนึ่ ง (2)ความสัมพันธ์แบบเกี่ยวข้องกัน (Association Relationship) คือ สิ่งสองสิ่งที่มีคว เชื่อมโยงกัน (3) ความสัมพันธ์แบบทั่วไป (Generalization Relationship) คือ คุณสมบัติของสิ่งหนึ่ งเป็นคุณสมบัติพื้นฐาน ของอีกสิ่งหนึ่ ง ซึ่งอาจมีคุณสมบัติมากกว่าคุณสมบัติพื้นฐานนั้ น (4) ความสัมพันธ์แบบต้นแบบ (Realization Relationship) คือ สิ่งหนึ่ งถูกสร้างให้มีคุณสมบัติ ของอีกสิ่งหนึ่ ง 3. แผนภาพ (Diagram) คือ แผนภาพที่เกิดจากแนวคิดที่ว่า สัญลักษณ์ทั่วไปใด ๆ ก็ตามถ้ามีคุณสมบัติบาง ประการที่สามารถจัดให้อยู่ในกลุ่มเดียวกันได้ก็จะใช้แผนภาพมาจัดกลุ่มให้แก่สัญลักษณ์เหล่านั้ น นอกจากองค์ ประกอบของภาษา UML แล้ว อีกสิ่งหนึ่ งที่สำคัญ คือ การเลือกใช้งานแผนภาพ สาเหตุที่ภาษา UML ต้องมีแผนภาพ ที่หลากหลาย เนื่ องจากในระบบที่มีขนาดใหญ่และมีความชับซ้อน ไม่สามารถใช้แผนภาพชนิ ดใดเพียงแผนภาพเดียว แล้วแสดงมุมมองได้ครบ ทั้งมุมมองเชิงโครงสร้างของระบบU (Static หรือ StructuralView) และเชิงพฤติกรรม ของระบu (Dynamic หรือ Behavioral View) ดังนั้ นจำเป็นต้องมีการเลือกแผนภาพหนึ่ งมาใช้ในมุมมองหนึ่ ง และเลือกอีกแผนภาพหนึ่ งมาใช้ในอีกมุมมอง หนึ่ ง เพื่อให้ได้แผนภาพที่สามารถเสนอมุมมองได้อย่างครบถ้วนจำเป็นต้องใช้แผนภาพ โดยต้องเข้าใจจุดประสงค์ ของแต่ละแผนภาพ และเลือกใช้แผนภาพให้ตรงกับมุมมองที่ต้องการ View ตามแนวทางของ UML นี้ จะแยกออกเป็น 2 ลักษณะหลัก คือ 1.Static View (Structural View) มุมมองของระบบที่ไม่มีกาเคลื่อนไหวหรือคงที่ ไม่ 2. Dynamic View (Behavioral View) มุมมองของระบบที่มีการเคลื่อนไหว เปลี่ยนแปลงสภาวะหรือสถานะของ องค์ประกอบที่อยู่ภายในระบบ เช่น Sequence Diagram ข้อดีของยูเอ็มแอล ในการใช้ยูเอ็มแอลเป็นภาษามาตรฐานในการวิเคราะห์และออกแบบระบบเชิงวัตถุจะมีข้อดี หลายประการ ดังนี้ 1. เป็นภาษารูปภาพมาตรฐานหรือภาษาสากลที่ใช้ในการพัฒนาชอฟต์แวร์เชิงวัตถุและสามารถใชู้เอ็มแอวแบบ จำลองได้อย่างสื่อความหมาย รวมถึงการจัดสร้างเอกสารการวิเคราะห์ออการประยุกต์ใช้ยูเอ็มแอลจะทำให้ผู้ร่วม งานมีความเข้าใจและสามารถแลกเปลี่ยนผลการวิเคราะห์และออกแบบระบบในขั้นตอนต่าง ๆ ได้อย่างรวดเร็ว 2. สามารถนำเสนอและสนั บสนุนหลักการเชิงวัตถุได้อย่างครบถ้วน ชัดเจน ทำให้นั กพัฒนาระบบสามารถ ทำความเข้าใจปัญหาและค้นพบวิธีการแก้ไขได้อย่างรวดเร็วและง่ายยิ่งขึ้น 3. ไม่ผูกติดกับภาษาโปรแกรมภาษาใดภาษาหนึ่ ง คือสามารถถูกแปลงเป็นระบบจริง ด้วยภาษาเชิงวัตถุใดก็ได้ 4. เป็นภาษาที่ง่ายต่อการทำความเข้าใจ

การวิเคราะห์และออกแบบเชิงวัตถุ 5. สามารถถูกแปลงเป็นภาษาที่ใช้สร้างระบบขึ้นจริงได้อย่างอัโนมัติ ทำให้ลดเวลาและค่าใช้จ่ายในการพัฒนาระบบ 6. สนั บสนุนการขยายปรับปรุงระบบ 7 . ในการพัฒนาสิ่งต่าง ๆ จะถูกบันทึกความคิดของนั กพัฒนาในลักษณะของเอกสารที่พร้อม จะนำมาทำความเข้าใจ ได้อย่างรวดเร็ว แผนภาพในภาษา UML Diagram แต่ละผ่นภาพเปรียบเสมือนมุมมองในด้านต่าง ๆ ของระบบที่ผู้วิเคราะห์ออกแบบ กำลังจะพัฒนา โดยในแต่ละแผนภาพที่แสดงมุมมองต่าง ๆ ประกอบด้วยสัญลักษณ์ที่ใช้ในการสื่อความหมายเฉพาะ ภายใน Daram นั้ นนอกจากความรู้พื้นฐานที่เกี่ยวข้องกับองค์ประกอบและแผนภาพของภาษา UMแ แล้ว สิ่งที่ทำให้ การใช้งานภาษา UML เป็นไปอย่างประสบผลสำเร็จอีกอย่างก็คือ ผู้ออกแบบและพัฒนาจำเป็นต้องเรียนรู้ กระบวนการในการเลือกใช้แผนภาพตามความเห ในขั้นตอนกระบวนการพัฒนาชอฟต์แวร์เชิงวัตถุจะใช้แผนภาพของภาษา UML เพื่อสร้างโมเดลระบบอย่างเป็นขั้น ตอนสอดคล้องกับกระบวนการพัฒนาซอฟต์แวร์ในการพัฒนาระบบ โดยทั่วไปผู้พัฒนาไม่จำเป็นต้องสร้างแผนภาพ ให้ครบทุกเผนภาพเสมอไป ผู้พัฒนาสามารถปรับเปลี่ยนการใช้งานแผนภาพได้ตามความเหมาะสม องค์ประกอบของภาษายูเอ็มแอลมี 3 ส่วน คือ ย่อยได้ดังนี้ 1. สัญลักษณ์ทั่วไป (Thing) คือสัญลักษณ์พื้นฐานที่ถูกใช้งานในการสร้างไดอะแกรม แบ่งเป็นหมวด (1) หมวดโครงสร้าง (Structural ได้แก่ ยูสเคส คลาส อินเตอร์เฟซ คอมโพเนนต์ คอลลาบอเรชันและโหนด (2) หมวดพฤติกรรม (Behavioral) คือส่วนที่เป็นไดนามิกของยูเอ็มแอล ซึ่งได้แก่ อินเตอร์แอกชันตแมชชีน (3) หมวดการจัดกลุ่ม (Grouping) เพื่อใช้ในการรวบรวมองค์ประกอบต่าง ๆ ในโมเดลให้เหมาะสม ได้แก่ แพ็กเกจ (4) หมวดคำอธิบายประกอบ (Annotational) ได้แก่ โน้ ต (Note) 2. ความสัมพันธ์ (Relationship) มี 3 ชนิ ด คือ (1) ความสัมพันธ์แบบพึ่งพา (Dependency Relationship) (2) ความสัมพันธ์แบบเกี่ยวพัน (Association Relationship) (3) ความสัมพันธ์แบบเจเนอรัลไลเซชัน (Generalization Relationship) 3. ไดอะแกรมต่าง ๆ (Diagram) ยูเอ็มแอล ประกอบด้วย 9 ไดอะแกรม แต่ละไดอะแกรมเปรียบเสมือนมุมมองใน ด้านต่าง ๆ ของระบบที่กำลังพัฒนาซึ่งช่วยให้การวิเคราะห์และออกแบบระบบเป็นไปได้อย่าง มีประสิทธิภาพและง่าย ยิ่งขึ้น (1)ยูสเคสไดอะแกรม (Use Case Diagram) ใช้ในการจำลองฟังก์ชันการทำงานของระบบ (2)คลาสไดอะแกรม (Class Diagran) ใช้ในการจำลองคลาสต่าง ๆ ที่จำเป็นในระบบ (3) แอกทิวิตีไดอะแกรม (Activity Diagram ) มีหลักการเช่นเดียวกับโฟลว์ชาร์ตสเตตชาร์ตไดอะแกรม (Statechart Diagram (5) คอลลาบอเรชันไดอะแกรม (Collaboration Diagran) ใช้แสดงการทำงานร่วมกันของออบเจ็กต์ในระบบ (6)เควนไดอะแกรม (Sequence Diagram) ใช้ในการจำลองกิจกรรมต่าง ๆ ที่เกิดขึ้นกับออบเจ็กต์ในระบบ (7)คอมโพเนนต์ไดอะแกรม (Component Diagram) ใช้สำหรับสร้างโมเดลของคในระบบ (8) ดีพลอยเมนต์ไดอะแกรม (Deployment Diagram) ใช้แสดงการติดตั้งใช้งานส่วนประกอบต่าง ๆ ของระบบ (9) ออบเจ็กต์ไดอะแกรม (Object Diagram) มีแนวคิดพื้นฐานมาจาก Class Diagram แต่มีความแตกต่างคือ Class Diagram มีรูปแบบเป็นนามธรรมซึ่งประกอบด้วยคลาสและความสัมพันธ์ ส่วน ObjectDiagram เป็นแผนภาพ ที่แสดงถึงพฤติกรรมของระบบจริง จุดประสงค์คือ เพื่อจับภาพมุมมองคงที่ของระบบในช่วงเวลาหนึ่ ง แผนภาพเชิง วัตถุแสดงถึงภาพรวมของระบบที่กำลังทำงานในช่วงเวลาหนึ่ ง ชนิ ดของไดอะแกรมใน UML 1. Use Case Diagram 2. Class Diagram 3. Sequence Diagram 4. Collaboration Diagram 5. State Diagram (Statechart) 6. Activity Diagram 7. Component Diagram 8. Deployment Diagram 9. Object Diagram