1 / 25

Class Diagram

Class Diagram. อ.วชิระ หล่อประดิษฐ์ ระบบสารสนเทศทางคอมพิวเตอร์ มหาวิทยาลัยเทคโนโลยีราชมงคลล้านนา ลำปาง. สรุปเกณฑ์ในการสร้าง Use Case Diagrams. StarUML http ://staruml.sourceforge.net/en/download.php. ชื่อ Use Case ต้องไม่ซ้ำกัน Use Case แต่ละอัน ต้องมีความชัดเจนว่าทำงานอย่างไร

Télécharger la présentation

Class Diagram

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Class Diagram อ.วชิระ หล่อประดิษฐ์ ระบบสารสนเทศทางคอมพิวเตอร์ มหาวิทยาลัยเทคโนโลยีราชมงคลล้านนา ลำปาง

  2. สรุปเกณฑ์ในการสร้าง Use Case Diagrams StarUML http://staruml.sourceforge.net/en/download.php ชื่อ Use Case ต้องไม่ซ้ำกัน Use Case แต่ละอัน ต้องมีความชัดเจนว่าทำงานอย่างไร ต้องมีการจัดลำดับความสำคัญของ Use Case เอาไว้ด้วย มีการกำหนดสภาพ Precondition และ Postconditionอย่างชัดเจน ระบุ Actor ของ Use Case ให้ชัดเจน ให้วิเคราะห์ระบบจาก User Requirement

  3. ปัญหากลุ่ม ให้ออกแบบวัตถุ Customer (ลูกค้า) และวัตถุ Theater (โรงภาพยนต์) โดยยึดหลักของ Object, Attribute, Method ในการซื้อตั๋วชมภาพยนต์

  4. Class Diagrams • Class diagram คือ แผนภาพที่ใช้แสดง class และความสัมพันธ์ (relationship) ระหว่าง class • ความสัมพันธ์ที่แสดงเป็นความสัมพันธ์เชิงสถิตย์ (static) ไม่ใช่ความสัมพันธ์ที่เกิดขึ้นเนื่องจากกิจกรรม (dynamic) • Static Relation คือ ความสัมพันธ์ที่มีอยู่แล้วเป็นปกติในระหว่าง Class ต่าง ๆ  • Static relationship • เจ้าของบัญชีเป็นเจ้าของบัญชีเงินฝาก • Dynamic relationship • เจ้าของบัญชีฝากเงินเข้าบัญชีเงินฝาก • เจ้าของบัญชีถอนเงินจากบัญชีเงินฝาก • เจ้าของบัญชีปรับปรุงยอดบัญชีเงินฝาก

  5. Man - Name # Surname - Age + tellName() + tellAge() สัญลักษณ์ Class Class Name Attributes Methods สัญลักษณ์ Visibility Private แทนด้วย - Protected แทนด้วย # Public แทนด้วย +

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

  7. เทคนิคการตีความเป็นวัตถุเทคนิคการตีความเป็นวัตถุ ได้จากการมองภาพของหน่วยบุคคล, องค์กร, สถานที่, รายงาน, แบบฟอร์ม แล้วทำการระบุหน้าที่ในระบบ ใช้ประสบการณ์การเขียนโปรแกรมเชิงวัตถุในการตีความหมายของวัตถุและคลาส ใช้ Generalization ในการมองลักษณะวัตถุที่มีร่วมกัน สร้างวัตถุจาก Entity, Data Store และ Flow บน DFD

  8. หลักการตั้งชื่อ Class, Attributes และ Methods • ชื่อของ Class, Attribute และ Methods ต้องเป็นชื่อที่สื่อความได้ และตรงกับความหมายของ Class, Attribute และ Methods นั้นๆ ในกรณีที่ชื่อเป็นคำผสมให้นำคำเหล่านั้นมาเรียงต่อกันโดยไม่มีเครื่องหมายใดๆ คั่น โดยอักษรตัวแรกของแต่ละคำ ต้องเป็นตัวพิมพ์ใหญ่ • เช่น ตั้งชื่อ Class ที่ใช้เพื่อจำลองบัตรสมาชิก (Member Card) ว่า “MemberCard” • ชื่อ Class ควรขึ้นต้นด้วยตัวอักษรภาษาอังกฤษตัวพิมพ์ใหญ่ • เช่น ReaderCounter • ชื่อ Methods หรือ Attributes ควรขึ้นต้นด้วยอักษรภาษาอังกฤษตัวพิมพ์เล็ก • เช่น memberCardId, enterCount()

  9. หลักการตั้งชื่อ Class, Attributes และ Methods • ชื่อ Methods ที่ใช้กำหนดค่าของ Attributes ควรขึ้นต้นด้วยคำว่า “set” แล้วตามด้วยชื่อ Attribute นั้นซึ่งขึ้นต้นด้วยอักษรตัวพิมพ์ใหญ่ • เช่น Methods ที่ใช้กำหนดค่าของ Attribute “memberCardId” ควรมีชื่อว่า “setMemberCardId” • ชื่อ Methods ที่ใช้อ่านค่าของ Attributes ควรขึ้นต้นด้วยคำว่า “get” แล้วตามด้วยชื่อ Attribute นั้น ซึ่งขึ้นต้นด้วยอักษรตัวพิมพ์ใหญ่ • เช่น Method ที่ใช้อ่านค่าของ Attribute “memberCardId” ควรมีชื่อว่า “getMemberCardId()”

  10. Man - Name # Surname - Age + tellName() + tellAge() ค่า Visiblility สัญลักษณ์ Visibility Private แทนด้วย - Protected แทนด้วย # Public แทนด้วย +

  11. Visibility แบบ Public • มองเห็นและเรียกใช้ได้โดยตรงจากภายนอก Class • เข้าไปเปลี่ยนค่า อ่านค่า หรือเรียกใช้งานได้ทันทีโดยอิสระจากภายนอก Class • มักใช้กับMethod มากกว่า Attributesเพราะเรียกใช้งานได้ทันที • จะใช้เครื่องหมาย +กำกับไว้ด้านหน้าใน Class Diagram

  12. Visibility แบบ Private • ไม่สามารถเห็นได้จากภายนอก จะเห็นได้ภายในเฉพาะตัว class เองเท่านั้น • หากภายนอกต้องการแก้ไข หรืออ่านค่า ทำได้วิธีเดียวคือ ทำผ่าน Method ที่เกี่ยวข้อง (Encapsulation หรือการห่อหุ้ม) • โดยทั่วไปมักใช้กับ Attributes มากกว่าMethod • จะใช้เครื่องหมาย – กำกับไว้ด้านหน้า ใน Class Diagram

  13. Visibility แบบ Protected • สงวนไว้สำหรับการทำ Inheritance (การถ่ายทอด) โดยเฉพาะ • สามารถเข้าถึงได้เฉพาะตัว Class เอง และ Class ที่เป็น Class ลูก • โดยปกติจะเป็นสัญลักษณ์ของ Superclass (Class แม่) • เมื่อทำ inheritance แล้ว Attributes และ Method เหล่านี้จะเป็นได้ทั้ง Private หรือ Protect ซึ่งขึ้นอยู่กับภาษาที่ใช้ • จะใช้เครื่องหมาย #กำกับไว้ด้านหน้า

  14. หลักการในการสร้าง Class Diagram Class ที่ได้ คือ Actor - Operator System Startup - ATM Machine - (Printer) Class ที่ได้ คือ System Shutdown - ATM Machine - (Printer) • กำหนดกรอบของโจทย์ให้ชัดเจน หา Class ที่มีทั้งหมด • เขียน Use Case Diagram ของโจทย์ที่กำหนดไว้ • Actor 1 Actor คือ Class 1 Class • พิจารณาว่าในแต่ละ Use Case มี Class ใดอยู่บ้าง • ทำให้ครบทุก Use Case

  15. หลักการในการสร้าง Class Diagram • ทำการสร้าง Class โดยใช้หลักต่อไปนี้ • หา Attributes และ Methods ที่มีอยู่ใน Class นั้นๆ โดยพิจารณาเฉพาะข้อมูลที่จำเป็น • วาด Class ที่ได้ลงใน Class diagram • หาค่า Visibility ให้กับ Attribute และ Method • หา Attribute และ Method • Class Operator • Attribute • รหัส (id) • ชื่อ (name) • นามสกุล (surname) • Username (user) • Password (pass) • Method • แสดงข้อมูล (showInfo) • เข้าสู่ระบบ (login) Operator + id - name - surname - user - pass + showInfo() + login()

  16. แบบฝึกหัดระหว่างเรียนแบบฝึกหัดระหว่างเรียน • สร้าง Class ต่อไปนี้จาก ระบบ ATM • ผู้ใช้ (Customer) • ตู้ ATM (ATMMachine) • บัตร ATM (ATMCard) • สลิป (Slip) • บัญชีธนาคาร (BankID)

  17. หลักการในการสร้าง Class Diagram • หาความสัมพันธ์ระหว่าง Class แต่ละ Class ให้ครบทุก Class • ความสัมพันธ์ดังกล่าวได้แก่ • Associationเป็นความสัมพันธ์แบบอ้างอิง โดยไม่มีใครเป็นเจ้าของใคร เช่น ความสัมพันธ์ระหว่างสามีและภรรยา • Aggregationเป็นความสัมพันธ์แบบที่ต้องขึ้นอยู่กับอีกฝ่ายหนึ่ง เช่น สาขาวิชาระบบสารสนเทศฯ มีอาจารย์หลายๆ ท่านเป็นอาจารย์ประจำสาขา • Compositionเป็นความสัมพันธ์ที่คล้ายกับ Aggregation แต่จะต่างกันตรงคลาสสมาชิกจะดำรงอยู่ได้เมื่อมีคลาสหลักเท่านั้น • Generalizationคือ การรับข้อมูลลักษณะบางประการมาจากคลาสแม่

  18. ความสัมพันธ์ประเภท Association • เป็นความสัมพันธ์แบบอ้างอิง โดยไม่มีใครเป็นเจ้าของใคร เช่น ความสัมพันธ์ระหว่างสามีและภรรยา • สามารถกำหนดจำนวนอ้างอิงต่อกัน เช่น เชื่อมต่อกันแบบหนึ่งต่อหนึ่ง (One to One) หรือหนึ่งต่อกลุ่ม (One to Many) • ตัวอย่าง Association

  19. ความสัมพันธ์ประเภท Aggregation เป็นการแสดงถึงการเป็นส่วนประกอบ คือ คลาสหลัก และในคลาสหลักก็มีการอ้างอิงถึงคลาสอื่นๆ ที่เป็นส่วนประกอบ

  20. ความสัมพันธ์ประเภท Composition เป็นการแสดงถึงการเป็นส่วนประกอบ เช่นเดียวกับ Aggregation ต่างกันตรงที่เมื่อคลาสหลักถูกทำลาย คลาสที่อ้างอิงคลาสหลักจะถูกทลายด้วย

  21. ความสัมพันธ์ประเภท Generalization Generalization คือ การรับข้อมูลลักษณะบางประการมาจากคลาสแม่

  22. หลักการในการสร้าง Class Diagram • พิจารณา Class ที่มีความสัมพันธ์กันแล้วใส่ Cardinality ให้ถูกต้อง • ระบุชนิดความสัมพันธ์ ได้แก่ • One to One (1..1) มีได้แค่ 1 ไม่มีไม่ได้ • Zero to One (0..1) มีได้แค่ 1 ไม่มีเลยก็ได้ • One to Many (1..*) มีได้มากกว่า 1 ไม่มีไม่ได้ • Zero to Many (0..*) มีได้มากกว่า 1 ไม่มีเลยก็ได้ • ใส่ Cardinality (ตัวเลขความสัมพันธ์) ให้ถูกต้อง

  23. ตัวอย่างการสร้าง Class Diagram Problem Domain ที่กำหนดคือ “ในคณะวิชาวิทยาศาสตร์ของสถาบันการศึกษาแห่งหนึ่งมีบุคลากรหลายประเภทด้วยกัน ได้แก่ อาจารย์ นักศึกษา และเจ้าหน้าที่ โดยที่อาจารย์แต่ละท่านมีหน้าที่ในการสอนวิชาใดวิชาหนึ่งหรือมากกว่า 1 วิชาก็ได้ และนักศึกษาก็มีหน้าที่ในการศึกษาวิชาวิชาหนึ่ง หรือมากกว่า 1 วิชาก็ได้ ในเวลาเดียวกันเจ้าหน้าที่ของภาควิชา คือ เจ้าหน้าที่ประจำห้องทดลองต่าง ๆ โดยกำหนดว่าใน 1 ห้องทดลองจะต้องมีเจ้าหน้าที่ 1 คนเสมอ”

  24. แนวทางการวิเคราะห์ • พิจารณาผู้ที่เกี่ยวข้องกับระบบก่อนว่ามีใครบ้าง • พิจารณากระบวนการต่างๆ ที่เกิดขึ้นในระบบ • วาด Use Case Diagram เพื่อพิจารณาภาพรวมของระบบ • พิจารณา Object หรือ Class ต่างๆ ที่ใช้ โดยพิจารณาจาก • Actor ใน Use Case Diagram • Object และ Class จาก Use Case ต่างๆ • กำหนด Object หรือ Class ใน Class Diagram • สร้างความสัมพันธ์ของ Class • กำหนด Attribute และ Method ต้องเกี่ยวข้องกับระบบ

  25. คำถามท้ายบท จงสร้าง Class Diagram จาก Problem Domain ที่กำหนดให้ต่อไปนี้ Problem Domain ในบริษัทจัดหางานแห่งหนึ่ง จะให้บริการเป็นสื่อกลางในการติดต่อกันระหว่าง นายจ้างที่ต้องการลูกจ้างและผู้สมัครงานที่ต้องการหางานทำ โดยจะรับจัดเก็บข้อมูลเกี่ยวกับคุณสมบัติของผู้สมัครและคุณสมบัติของงานแต่ละตำแหน่งที่นายจ้างต้องการ และเมื่อพบว่ามีตำแหน่งงานที่เหมาะแก่ผู้สมัคร บริษัทจะจัดทำจดหมายเพื่อติดต่อให้นายจ้างและผู้สมัครให้มาสัมภาษณ์กันที่บริษัท (เป็นระบบสารสนเทศ)

More Related