ดาวน์โหลดงานนำเสนอ
งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ
1
The Unified Modeling Language
What is UML คืออะไร UML เป็นมาตรฐานสำหรับ Unified Modeling Language object-oriented system มีการพัฒนา จากงานของ Grady Booch, James Rumbaugh, Ivar Jacobson, และบริษัท Rational Software Corporation เหล่านี้เป็นนักวิทยาศาสตร์ที่มีชื่อเสียง
2
The Unified Modeling Language
UML เป็นโมเดลมาตรฐานที่ใช้หลักการออกแบบ OOP (Object Oriented Programming) รูปแบบของภาษามี Notation เป็นสัญลักษณ์สำหรับสื่อความหมาย มี กฎระเบียบที่มีความหมายต่อการเขียนโปรแกรม (Coding) ดังนั้นการใช้ UML จะต้องทราบความหมายของ Notation เช่น generalize, association, dependency, class และ package สิ่งเหล่านี้มีความจำเป็นต่อตีความการออกแบบ ก่อนนำไป Implement ระบบงานจริง กันไปบ้าง แต่ทั้งหมดก็ทำให้กิจกรรมกรอบงานทั่วไปชุดเดียวกันได้แก่ กิจการการสื่อสาร การวางแผน การสร้างแบบจำลอง การก่อสร้างและการใช้งาน
3
ทำไมต้องใช้ UML สามารถแสดงส่วนประกอบในการสร้างโปรเจคในรูปของ OOP
เชื่อมแนวคิดกับการออกแบบระบบโดยใช้ Object Oriented Code ง่ายต่อการทำความเข้าใจและสามารถแปลงเป็น Code program ได้
4
Software Performance UML ถูกน ามาใช้ในการพัฒนา software
1. ช่วยลดระยะเวลาในการพัฒนาระบบงาน(Shortest Development life cycle) 2. ช่วยเพิ่มความสามารถในการทำงาน(Increase productivity) 3. ช่วยเพิ่มคุณภาพของระบบงาน (Improve software quality) 4. รองรับระบบงานเดิม(Support legacy system) 5. ช่วยในการสื่อสารระหว่างทีมผู้พัฒนาระบบงาน(Improve team connectivity)
5
ประโยชน์ของUML (UML Advantage)
1.วงจรการพัฒนาที่สั้นที่สุด (Shortest Development life cycle) 2. เพิ่มผลผลิต (Increase productivity) 3. ปรับปรุงคุณภาพซอฟต์แวร์ (Improve software quality) 4. สนับสนุนระบบสืบทอดมรดก (Support legacy system) 5. ปรับปรุงการเชื่อมต่อทีมงาน (Improve team connectivity)
6
Use Case Diagram Use Case Diagram
เป็นแผนภาพที่แสดงการทำงานของผู้ใช้ระบบ (User) และความสัมพันธ์กับระบบ ย่อย (Sub systems) ภายในระบบใหญ่ ในการเขียน Use Case Diagram ผู้ใช้ระบบ (User) จะถูกกำหนดว่าให้ เป็น Actor และ ระบบย่อย (Sub systems) คือ Use Case จุดประสงค์หลักของการเขียน Use Case Diagram ก็เพื่อเล่าเรื่องราวทั้งหมดของระบบ ว่ามีการทำงานอะไรบ้าง เป็นการดึง Requirement หรือเรื่องราวต่าง ๆ ของ ระบบจาก ผู้ใช้งาน ซึ่งถือว่าเป็นจุดเริ่มต้นในการวิเคราะห์และออกแบบระบบ
7
Use Case Diagram Use Case Diagram
สัญลักษณ์และความสัมพันธ์ใน Use Case Diagram สัญลักษณ์ที่สำคัญของ Use Case Diagram มีดังต่อไปนี้ Use Case คือ หน้าที่ที่ระบบต้องกระทำใช้ช้สัญลักษณ์รูปวงรี พร้อมทั้งเขียนชื่อ Use Case ซึ่งต้องใช้คำกริยาหรือกริยาวลีก็ได้
8
Use Case Diagram Use Case Diagram
Actor คือ ผู้เกี่ยวข้องกับระบบ ซึ่งรวมทั้ง Primary Actor และ Stakeholder Actor ที่เป็นมนุษย์ ในที่นี้จะใช้ สัญลักษณ์รูปคน (Stick Man Icon) เหมือนกัน พร้อมทั้งเขียนชื่อ Actor ไว้ด้านล่างของสัญลักษณ์ด้วย แต่หาก เป็น Actor ที่ไม่ใช่มนุษย์ เช่น ระบบงานอื่นที่อยู่นอกเหนือระบบที่เราสนใจ จะใช้รูปสี่เหลี่ยมแล้วเขียนคำว่า “<>” ไว้ด้านบน
9
Use Case Diagram Use Case Diagram
System Boundary เส้นแบ่งขอบเขตระหว่างระบบกับผู้กระทำต่อระบบ (Use Case กับ Actor) ใช้รูปสี่เหลี่ยมเป็นสัญลักษณ์ พร้อมทั้งเขียนชื่อระบบไว้ด้านใน
10
Use Case Diagram Use Case Diagram
Connection คือ เส้นที่ลากเชื่อมต่อระหว่าง Actor กับ Use Case ที่มีปฏิสัมพันธ์กัน ใช้เส้นตรงไม่มีหัวลูกศรเป็นสัญลักษณ์ ของ Connection ส่วน Connection ที่ใช้เชื่อมต่อระหว่าง Use Case กับ Use Case กรณีที่ Use Case นั้นมี ความสัมพันธ์ซึ่งกันและกัน จะใช้สัญลักษณ์เส้นตรงมีหัวลูกศร พร้อมทั้งเขียนชื่อความสัมพันธ์ไว้ตรงกลางเส้นด้วย โดยเขียนไว้ภายในเครื่องหมาย <>
11
ความสัมพันธ์ของ Use Case Diagram
Extend Relationship เป็นความสัมพันธ์แบบขยายหรือเพิ่ม เกิดขึ้นในกรณีที่บาง Use Case ดำเนินกิจกรรมของตนเองไปตามปกติ แต่อาจจะมีเงื่อนไขหรือสิ่งกระตุ้นบางอย่างที่ส่งผลให้กิจกรรมตามปกติของ Use Case นั้นถูกรบกวนจนเบี่ยงเบน ไป ซึ่งเราสามารถแสดงเงื่อนไขหรือสิ่งกระตุ้นเหล่านั้นได้ในรูปของ “Use Case” และเรียกความสัมพันธ์ระหว่าง Use Case ในลักษณะนี้ว่า “Extend Relationship”
12
ความสัมพันธ์ของ Use Case Diagram
Include Relationship ความสัมพันธ์อีกรูปแบบหนึ่งของ Use Case Diagram ก็คือ ความสัมพันธ์แบบเรียกใช้ เกิดขึ้นในกรณีที่ Use Case หนึ่งไปเรียกหรือดึงกิจกรรมของอีก Use Case หนึ่งมาใช้ เพื่อให้กิจกรรมนั้นเกิดขึ้นจริงใน Use Case ของตนเอง หรือกล่าวให้ง่ายกว่านั้นคือ กิจกรรมใน Use Case หนึ่ง อาจจะถูกผนวกเข้าไปรวมกับกิจกรรมของอีก Use Case หนึ่ง เราเรียกความสัมพันธ์ระหว่าง Use Case ในลักษณะนี้ว่า “Include Relationship”
13
การสร้าง Use Case Diagram
เริ่มต้นการสร้าง Use Case Diagram ด้วยการวิเคราะห์หาขอบเขตของระบบ (Problem Domain) ซึ่ง ประกอบไปด้วยการค้นหา Actor ที่ควรมีในระบบ และ Use Case ที่มีปฏิสัมพันธ์โดยตรงกับ Actor เหล่านั้น ขึ้นมาก่อน จากนั้นจึงเพิ่มเติม Use Case อื่นๆ เข้าไปจนครบหน้าที่การท างานของระบบ 1. ค้นหา Actor 2. ค้นหา Use Case ที่มีปฏิสัมพันธ์กับ Actor นั้นโดยตรง 3. ค้นหาและสร้างความสัมพันธ์ระหว่าง Use Case หรือ Actor (ถ้ามี) แล้วเพิ่มเติม Use Case ใหม่ซึ่ง อาจเป็น Included Use Case, Extending Use Case ที่เพิ่มเติมจาก Base Use Case ที่มีอยู่แล้ว หรือจะเพิ่ม Base Use Case ใหม่ก็ได้ (ถ้ามี)
14
การสร้าง Use Case Diagram
4. ต้องไม่มี Actor ใดเลยที่ไม่มีปฏิสัมพันธ์กับ Use Case 5. ต้องไม่มี Use Case ใดเลยที่ไม่มีปฏิสัมพันธ์กับ Actor 6. Use Case ทุกตัวต้องมีปฏิสัมพันธ์อย่างใดอย่างหนึ่งกับ Actor หรือ Use Case ตัวอื่นๆเสมอ 7. เขียนค าอธิบายแต่ละ Use Case จนครบถ้วน
15
การเขียนคำอธิบาย Use Case
1. Main Flow คือ ล าดับกิจกรรม เมื่อ Use Case ดำเนินกิจกรรมตามปกติ โดยการเขียนคำอธิบายในลักษณะ เป็นย่อหน้า (Paragraph) และ Main Flow จะต้องมีเพียงหนึ่งเดียวเท่านั้น 2. Exceptional Flow คือ ลำดับกิจกรรม เมื่อ Use Case ด าเนินกิจกรรมผิดจากปกติ โดยสามารถมีมากกว่า 1 Flow ได้ ทั้ง Main Flow และ Exceptional Flow จะต้องระบุถึงสาเหตุของการเริ่มต้นและสิ้นสุดกิจกรรมด้วย เสมอ นอกจากการระบุถึง Main Flow และ Exceptional Flow แล้ว เราสามารถเพิ่มเติมส่วนประกอบ อื่นๆ ได้ตามความเหมาะสม โดยในที่นี้จะเพิ่ม Use Case Title, Use Case Id, Primary Actor และ Stakeholder Actor ด้วย
16
Activity Diagram ใช้ อธิบายกิจกรรมที่เกิดขึ้นในลักษณะกระแสการไหลของการทำงาน (workflow) จะมีลักษณะเดียวกับ Flowchart (แสดงขั้นตอนการทำงานของระบบ) โดยซึ่งมี สิ่งต่างเหล่านี้ Activity ขั้นตอนในการท างานแต่ละขั้นตอน อาจเป็นการท างานต่างๆ ได้แก่ การคำนวณผลลัพธ์บางอย่าง การเปลี่ยนแปลงสถานะ (State) ของระบบ การส่งค่ากลับคืน การส่งสัญญาณ การเรียกให้ Operation (Method) อื่นๆเพื่อทำงาน การสร้าง หรือ ทำลายวัตถุ Activity
17
Activity Diagram Edge/Control Flow คือ connection ที่ถูกสร้างขึ้นเพื่อให้ทำงานระหว่าง Activity Nodes เพื่อควบคุมและเคลื่อนที่ของ งาน
18
Activity Diagram Initial Node Initial หรือ start node แสดงจุดเริ่มต้นของ Diagram
19
Activity Diagram Final Node Flow final : แสดงจุดสิ้นสุดของ single control Activity final: สิ้นสุดการทำงานของ control flows ทั้งหมดภายใน activity diagram.
20
Activity Diagram Object Flows Object flow คือเส้นทางซึ่ง object หรือ data สามารถผ่านได้ แสดงโดยใช้ลูกศรโดยหัวลูศรจะบอถึงทิศทางที่ Object เดินทางไปหรือเขียนอย่างย่าโดยใช้ input และ output pin
21
Activity Diagram Data store เป็นส่วนที่จะท าการเก็บข้อมูลซึ่งเป็นการเก็บแบบถาวร เมื่อน าข้อมูลออกจะเป็นการ copy ออกไป โดยระบุสัญลักษณ์ «data store» ใน Object
22
Class Diagrams ในการวิเคราะห์และออกแบบระบบด้วย UML นั้น ส่วนที่สำคัญที่สุดก็คือการออกแบบโครงสร้างของ ข้อมูลและการทำงานของโปรแกรม ในแนวคิดของการพัฒนาระบบด้วย OOP (Object Oriented Programming) นั้นเรามองข้อมูลและโปรแกรมเป็นหน่วยเดียวกันที่เรียกว่าคลาส (Class) การออกแบบ องค์ประกอบของคลาสซึ่งประกอบด้วยข้อมูลที่ประกอบขึ้นเป็นคลาสซึ่งเรียกว่าแอตทริบิวท์ (attribute) และส่วน ของโปรแกรมหรือหน้าที่การท างานของคลาสซึ่งเรียกว่าโอเปอเรชั่น (operation) รวมถึงความสัมพันธ์ระหว่าง คลาสต่าง ๆ ที่ประกอบขึ้นเป็นระบบนั้น สามารถทำได้ด้วยการเขียนคลาสไดอะแกรม (class diagram) โดย คลาสไดอะแกรม จะมีองค์ประกอบดังต่อไปนี้
23
Class Diagrams คลาส (Class) ส่วนประกอบหลักของคลาสไดอะแกรมก็คือคลาสต่าง ๆ ที่ประกอบกันขึ้นเป็นระบบ คลาสอาจจะเป็น ตัวแทนของ คน สถานที่ เหตุการณ์ หรือสิ่งต่าง ๆ ซึ่งเป็นส่วนประกอบของระบบที่เรากำลังวิเคราะห์และ ออกแบบอยู่ ในแต่ละคลาสจะมีการจัดเก็บข้อมูลและมีวิธีในการจัดการกับข้อมูลที่จัดเก็บ โดยคลาสจะเป็นรูป สี่เหลี่ยมที่ถูกแบ่งออกเป็นสามส่วน โดยชื่อคลาสจะอยู่ส่วนบนสุด และแอตทริบิวต์จะอยู่ตรงกลาง และโอเปอเรชั่น จะอยู่ล่างสุด (ดูรูป)
24
Class Diagrams แอตทริบิวต์(Attribute) แอตทริบิวต์คือข้อมูลที่เป็นคุณสมบัติของคลาส ซึ่งก็คือข้อมูลที่เราสนใจจะจัดเก็บและนำมาใช้ในระบบ เราสามารถกำหนดระดับของการเข้าถึงข้อมูลเหล่านี้ได้ โดยการใส่เครื่องหมายดังต่อไปนี้ไว้ข้างหน้าของแอตทริบิวต์ (+) สาธารณะ (public) หมายถึงการอนุญาตให้คลาสอื่น ๆ สามารถมองเห็นและใช้งานข้อมูลที่อยู่ใน แอตทริบิวต์นี้ได้ (#) ป้องกัน (protected) หมายถึงการอนุญาตให้คลาสอื่น ๆ สามารถมองเห็นแอตทริบิวต์นี้ได้แต่ ไม่อนุญาตให้ใช้งานแอตทริบิวต์นี้ได้ (-) ซ่อนไว้ (hidden) หมายถึงคลาสอื่น ๆ ไม่สามารถที่จะมองเห็นและใช้งานแอตทริบิวต์นี้ได้
25
Class Diagrams ความเกี่ยวข้องกัน (Association) ความสัมพันธ์แบบนี้เป็นความสัมพ้นธ์ส่วนใหญ่ของคลาสต่าง ๆ ในระบบ ซึ่งจะทำงานร่วมกันด้วย ความสัมพันธ์ที่เกี่ยวข้องกัน เป็นความสัมพันธ์ในรูปแบบของการทำงานร่วมกันเช่นเดียวกับการท างานใน ชีวิตประจำวันของเรา (ดูรูปข้างล่างประกอบ)
26
Class Diagrams
งานนำเสนอที่คล้ายกัน
