UML Diagrams Functional Model Seree Chinodom

Slides:



Advertisements
งานนำเสนอที่คล้ายกัน
สรุปภาพรวมของหน่วยการเรียนรู้
Advertisements

การออกแบบฐานข้อมูลในระดับ Conceptual
การเสนอโครงการวิทยานิพนธ์
Chapter 8 : Logic Modeling & Data Modeling
การกระทำทางสังคม (Social action)
(Material Requirement Planning)
การวิเคราะห์ระบบและวิธีปฏิบัติงาน
การเขียนผังงาน.
Object-Oriented Analysis and Design
ตัวอย่างการสร้าง Class Diagram
Class Diagram.
Thesis รุ่น 1.
Business Modeling (บางส่วนอ้างอิงจาก ดร.อดิศร ณ อุบล)
ภาษา SQL (Structured Query Language)
Object-Oriented Analysis and Design
ซอฟต์แวร์.
บทที่ 5 การจำลองแบบเชิงวัตถุ Object Modeling
การวางแผนและการดำเนินงาน
Object-Oriented Analysis and Design
Use Case Diagram.
Example Use Case Diagram
Example Class Diagram.
หน่วยที่ 1 เทคโนโลยีสารสนเทศ.
Surachai Wachirahatthapong
SCC : Suthida Chaichomchuen
Enhanced Entity-Relationship Model
การออกแบบแบบจำลองข้อมูล
การเขียนโปรแกรมคอมพิวเตอร์และอัลกอริธึม
เทคโนโลยีสารสนเทศ เทคโนโลยี + สารสนเทศ.
บทบาทการบริหารงานสำนักงาน 1
ความหมาย ปัญญาประดิษฐ์
โครงร่างการวิจัย (Research Proposal)
การแสดงการทำงานของระบบด้วย Use Case Diagram
Systems Analysis and Design
การออกแบบฐานข้อมูลเชิงสัมพันธ์
บทที่ 1 ความรู้พื้นฐานในการ พัฒนาระบบ
การรวบรวมความต้องการ (Requirements Gathering)
คำถามตามเกณฑ์ PMQA:105คำถาม หมวด4 10คำถาม.
บทที่ 3 การวิเคราะห์ Analysis.
ความสัมพันธ์ระหว่างคลาส (Class Relationship)
ที่ใช้ใน Object-Oriented Design
Data Modeling Chapter 6.
System Analysis and Design
วิชาวิเคราะห์และออกแบบระบบเชิงวัตถุ Lec08 :: Behavioral Modeling with UML Behavioral Diagrams Interaction Diagrams Nattapong Songneam
Geographic Information System
Object-Oriented Programming
Lecture 2 แก้ไขปัญหาด้วย OOP (Solving problems using OOP in Java)
การเขียนเกณฑ์การประเมิน (Rubric)
การจัดการฐานข้อมูล.
หลักการแก้ปัญหา
Sequence Diagram Communication Diagram
Activity Diagram Wattanapong suttapak, Software Engineering,
school of Information communication Tecnology,
BC305 การวิเคราะห์และออกแบบระบบสารสนเทศ
Modeling and Activity Diagram
การวิเคราะห์และออกแบบระบบ System Analysis and Design
ระบบคอมพิวเตอร์ (computer system)
Unified Modeling Language
ระบบฐานข้อมูล.
วิชา การวิเคราะห์และออกแบบเชิงวัตถุ รหัส
กลุ่ม สำนักอนามัย กรุงเทพมหานคร.
บทที่ 4 ข้อเสนอโครงการวิจัย
State Diagram Wattanapong suttapak, Software Engineering,
Object Oriented Development with UML
บทที่ 5 ความต้องการ วิศวกรรมความต้องการ แบบจําลองการวิเคราะห์
การวิเคราะห์ซอฟต์แวร์
for Display Antique and Art Object Information
UML (Unified Modeling Language)
Use Case Diagram.
ใบสำเนางานนำเสนอ:

UML Diagrams Functional Model Seree Chinodom Object Oriented Analysis and Design UML Diagrams Functional Model Seree Chinodom

UML has 9 kinds of diagrams Class Diagram Object Diagram Component Diagram Deployment Diagram Use Case Diagram Sequence Diagram Collaboration Diagram StateTransition Diagram Activity Diagram Structural Diagrams Functional Diagrams Behavioral Diagrams

Functional Modeling

Use Case Diagram นำเสนอ Use Case และการปฏิสัมพันธ์โต้ตอบกันระหว่างระบบ และ ผู้ใช้ภายนอก (อาจเป็นคน หรือระบบก็ได้) ประกอบด้วย Use Case - ความสามารถ/หน้าที่ของระบบ Actor - ผู้กระทำ/ผู้ใช้งาน Use Case นั้นๆ Relationship - เส้นแสดงความสัมพันธ์ระหว่าง Use Case กับ Actor System - ระบบที่กำลังพัฒนา

Use Case Modeling : Core Elements

Use Case Modeling : Core Relationships <<extend>>

Use Case Modeling : Core Relationships (cont’d) <<include>>

Use Cases v.s. Scenario Use Case ความสามารถ หรือ หน้าที่การทำงานของระบบ แต่ละ Use Case แทนชุดของ transactions ที่ระบบทำงานโต้ตอบกับ ผู้ใช้งาน หรือระบบอื่นๆ ภายนอก Scenario สถานการณ์ หรือตัวอย่างเรื่องราวการใช้งานระบบ Scenario จัดเป็น instance ของ use case เช่น withdrawal cash a user withdrawals $200 15

Actors Actor หมายถึง someone หรือ some thing ที่มีการปฏิสัมพันธ์ โต้ตอบกับระบบ สิ่งใดก็ตามที่มีความต้องการในการแลกเปลี่ยน information กับระบบ หรือ สิ่งใดก็ตามที่อยู่ภายนอกระบบ และมีการใช้งาน Use Case ของระบบ กำหนดบทบาทหน้าที่ของผู้ใช้ระบบ กำหนดการเชี่อมโยงกับระบบอื่นๆ ภายนอก ตัวอย่างของ Actors Customer -- maintain their account Cashier -- verify withdrawal amount Customer Cashier 14

Actors Actors สามารถอธิบายโดยใช้ Specialization Relationship อาจพิจารณา Actors เป็นคลาส ใน UML เนื่องจากมี relationships เช่นเดียวกับที่คลาสมี specialization relationship Customer ATM Customer Cashier Customer

Actors เชื่อมต่อกับ use cases โดยใช้เส้นแสดงความเกี่ยวข้อง ปฏิสัมพันธ์ (association) association = ความสัมพันธ์ที่มีการติดต่อสื่อสารกัน (ทั้งการรับ และส่ง messages ให้แก่กันและกัน) ใช้ generalization relationships อธิบายความสัมพันธ์ ระหว่าง actors ไม่จำเป็นต้องอธิบายรายละเอียดของ Association เนื่องจากไม่มีการ Implement ส่วนของ Actor ในระบบ Customer withdrawal cash

System ใช้สัญลักษณ์ System อาจหมายถึง Software system, business, hardware,.. วัตถุประสงค์ใน use-case modeling เพื่อระบุขอบเขตของระบบที่กำลังพัฒนา (system boundary) ใช้สัญลักษณ์ System

Relationships between Use Case Extends : เป็น generalization relationships ในกรณีที่ Use Case หนึ่งๆ ขยาย (extends) Use Case อื่น โดยการเพิ่มการกระทำ (actions) Includes/Uses : เป็น generalization relationship ในกรณีที่ Use Case หนึ่งๆ เรียกใช้ (uses) Use Case อื่น ที่พิจารณาให้เป็นส่วนหนึ่งของ Use Case นั้นๆ

Generalization Relationship Child Use case รับถ่ายทอดคุณสมบัติมาจาก Parent Use Case Child สามารถเปลี่ยนแปลงพฤติกรรมที่รับจาก Parent หรือเพิ่มเติ่มพฤติกรรม Child อาจนำไปแทนที่ ในที่ๆ Parent ปรากฏ Validate client Check password Retinal scan

“Include” relationship มักใช้ในการหลีกเลี่ยงการอธิบายการไหลของเหตุการณ์ (flow of events) เดิม ซ้ำกันหลายๆ ครั้ง โดยรวบรวมพฤติกรรมร่วม ใน Use Case หลีกเลี่ยงการ copy & paste ของ Use Case Descriptions Validate client Place order <<include>> Track order

Example of Include in a Track Order Use Case Validate Client <<include>> System Response Actor Action 1. Input order number 2. Verify Order Number Include (Validate User) 3. For each part in the order, query its status 4. Report back to user Note: includes should also be mentioned in the overview and cross-reference section of the Use Case

“Extend” relationship ใช้สร้างแบบจำลองบางส่วนของ Use Case ที่ user อาจมองเป็น optional ใช้ สร้างแบบจำลอง conditional subflows ใช้ในการแทรก subflows ในจุดที่ระบุโดยพิจารณา ปฏิสัมพันธ์ระหว่าง Actors Place order Extension points: Set priority <<extend>> (set priority) Place rush order

Example of Extends in a Use Case Place Order Place Rush Order <<extend>> Actor Action System Response 1. Ask for order to be place 2. Verify customer details. Include (Validate User) 3. Collect the user’s order items. (set priority) 4. Submit order for processing Note: extends should also be mentioned in the overview and cross-reference section of the Use Case

Relationships between Use Case Ship Order Validate Account <<extend>> <<include>> Ship Partial Order Withdrawal Cash

Comparing extends/uses ใช้แยกความแตกต่างของ Use Case actors ที่เกี่ยวข้องมักเป็นคนกระทำ Use case รวมทั้ง Use Case ที่ extend ทั้งหมด actor มักเชื่อมต่อกับ “base” Use Case include/use ใช้กำหนด Use Case ที่มีพฤติกรรมร่วม มักไม่มี actor เกี่ยวข้องโดยตรงกับ Use Case ที่มีพฤติกรรมร่วม

A Use Case Diagram Retinal Scan <<include>> Track Order Validate Client Check Password <<include>> Trader Place Order <<include>> Establish Credit Stock Exchange Financial Officer <<extend>> Place Rush Order

A Use Case Diagram Deposit Transfer Validate Account Customer <<include>> Customer Validate Account Bank Teller Deposit Balance Checking Transfer Withdraw Verify withdrawal

When and how? Requirements capture ใช้ในการกำหนด Reuqirement ของระบบ สร้างแบบจำลอง (Model) ของ requirements ด้วย Use Case Test Scenarios สร้างแบบจำลอง (Model) ของสถานการณ์การทดสอบระบบ (test scenarios) ด้วย Use Case Use Case: ระบุสิ่งที่ customer ต้องการให้มีในระบบ ตั้งชื่อให้ Use Case โดยเขียนคำอธิบายสั้นๆ เพิ่มรายละเอียดในภายหลัง Sources for identifying use cases: Think about potential actors Think about potential external events

Finding Actors สามารถระบุ actor ได้โดยตอบคำถามต่อไปนี้ ใครเป็นคนใช้งานหน้าที่การทำงานหลักของระบบ (primary actors)? ใครต้องการการสนับสนุนการทำงานจากระบบ? ใครต้องการบำรุงรักษา และบริหารระบบ (secondary actors)? Hardware devices ใดที่ต้องการให้ระบบจัดการดูแล? ระบบภายนอกระบบใดที่ ต้องการให้ระบบมีปฏิสัมพันธ์ด้วย? ใคร หรือ อะไรที่ต้องการได้รับผลประโยชน์ จาก output ของระบบ? Tips ไม่ควรพิจารณาเฉพาะ users ที่ใช้งานระบบโดยตรง แต่ พิจารณา users อื่นๆ ที่ต้องการใช้บริการจากระบบด้วย

Finding Use Cases สำหรับแต่ละ actor ตอบคำถามต่อไปนี้ เหตุการณ์ใดบ้างที่ระบบต้องแจ้งให้ actor ทราบ? หรือ actor ต้องแจ้งให้ระบบทราบ? หน้าที่การทำงานของระบบ ช่วยทำให้งานประจำวันของ actor ง่ายขึ้นหรือไม่? ถ้าไม่พิจารณา actors อะไรคือ input/output ของระบบ ? input/output เหล่านั้นมาจากไหน หรือใครเป็นคนนำไปใช้งาน? ปัญหาหลักของระบบที่ใช้งานอยู่ คืออะไร?

Recipe ระบุ actors ที่มีปฏิสัมพันธ์กับระบบ สำหรับแต่ละ actor ให้ระบุกระบวนการที่ actor เริ่มต้นกระทำ หรือมีส่วนร่วม สำหรับ event ให้ระบุ เหตุการณ์ภายนอกที่ระบบต้องตอบสนอง ให้หาความสัมพันธ์ระหว่างเหตุการณ์ และ actor เพื่อสร้างเป็น use case