Use case modelsiam2dev.net/E_Learning/OOAD/Lec07_OOAD_Use_case_model...The Iterative Approach OOAD :...
Transcript of Use case modelsiam2dev.net/E_Learning/OOAD/Lec07_OOAD_Use_case_model...The Iterative Approach OOAD :...
โดย อาจารย ดร. นฐพงศ สงเนยมhttp://[email protected]
สาขาวชา วทยาการคอมพวเตอรคณะวทยาศาสตรและเทคโนโลย มหาวทยาลยราชภฏพระนคร
Last Update : 30/01/2561
Lec07 : Use case model
แหลงขอมลเพมเตม : : http://www.lumpaya.com/sdlc01.htmhttp://www.siam2dev.com [ dr.
nattapong songneam]
Lecture Outline
1. กระบวนการพฒนาซอฟตแวร (Software Development Process )
ทบทวน
2. ข นตอนการวเคราะหระบบ (System Analysis)
3. การวเคราะหระบบดวย ยสเคส (System Analysis and Use Case )
4. การสราง ยสเคสไดอะแกรม (Use Case Diagram )
5. ตวอยางของ ยเคส (Example Of Use case)
UP :: โครงสรางกรรมวธ - Lifecycle Phases
เตรยมงาน (Inception) – นยามขอบเขตของโครงการ , ขอบเขตของระบบทจะพฒนา
OOAD : Object-Oriented Analysis and Design 3
Inception Elaboration Construction Transition
time
Unified process แบงการพฒนาออกเปน 4 เฟส (phases) แบงโครงการออกเปน 4 ระยะ
ทารายละเอยด (Elaboration) – วางแผนโครงการ จดทารายละเอยดความตองการ จดสรางสถาปตยกรรมระบบ
จดสราง (Construction) – สรางและทดสอบโปรแกรม
ถายโอน (Transition) – ตดตงถายโอนระบบใหกบผใช
3
Requirement Analysis
Use case จะเรมทาในเฟส น
Requirement specifications
การเขยนโครงการ (Proposal)
• ชอโครงการ
• ความเปนมาและความสาคญของปญหา
• วตถประสงคของโครงการ
• ขอบเขต
• แผนการดาเนนงาน Gantt Chart
• ประโยชนทคาดวาจะไดรบ
• อภธานศพทเฉพาะ
The Iterative Approach
OOAD : Object-Oriented Analysis and Design 5
Disciplinesgroup activities
logically
In an iteration,you walk through
all disciplines
5
ระบบบรหารโรงแรม ABC
Business Model : โมเดลทางธรกจBusiness Rule : กฏเกณฑ/เงอนไขทางธรกจ
โปรแกรม บรหารงานโรงแรม (GENiUS iHotel) เปน โปรแกรมโรงแรม ทออกแบบสาหรบชวยบรหารงาน โรงแรม รสอรท อพารทเมนต แบบรายวน และรายเดอน โดยสวนประกอบหลกๆ ของโปรแกรมจะประกอบไปดวย ขอมลหองพก (Room Information) ระบบการจองหองพก (Reservation) ระบบการเชคอน (Guest Check In) ระบบการเชคเอาท (Guest Check Out) ระบบขอมลผเขาพก (Guest History) ระบบการขายสนคาในหองพก (Mini Bar) ระบบการซอสนคา ระบบสตอกสนคา (Inventory) ระบบแมบาน (House Keeping) ระบบการบารงรกษาหองพก (Room Maintainance) ระบบการปดบญชรอบวน (Night auditor) และ ระบบงานเอกสาร ตางๆ อาทเชน Guest Folio ใบเสรจรบเงน ใบกากบภาษ เปนตน รวมไปทงระบบการรายงานรายวน รายงานแบบสรป และ รายงานเชงวเคราะห เชงลก ใหผบรหาร อาทเชน รายงานประวตผเขาพก รายงานการรบเงนของ Cashier รายงานการเขาพก รายงานสรปยอดหองพกคงเหลอ (Room Forecasting) รายงานสนคาคงเหลอสตอกกลาง หรอ มนบาร รายงานการใชหองพก (Room Occupancy) รายงาน ยอดการจองหองพกลวงหนา (Forecast Report) และ รายงานอนๆ และเครองมอชวยเหลอในการทางาน (Front Utility) อกมากมาย
คณสมบตของ โปรแกรมโรงแรม
ระบบโรงแรม คออะไร ?
Business model•ชอ•ทตง ทอย•ใครเปนเจาของ•ดาเนนกจการมาแลวกป•จานวนหองพก•ประเภท•พนกงาน•แผนก ฝาย•รายละเอยดตางเกยวกบ การทาธรกจ โรงแรม•ฯลฯ
Business model
Business Rule
Business Rule เงอนไข ของธรกจ
•การเขาพก ทาอยางไร•การเปนสมาชก / ทาอยางไร•การจอง•การจายเงน•การรบพนกงาน•การตอนรบลกคา
การจองเพอจะ ตรวจสอบสถานะของหอง?
ตวอยาง Business Rule
ตวอยาง Business Ruleบรษท เอม บ เค จากด(มหาชน) เปนผประกอบธรกจระดบแนวหนาของประเทศไทย โดยมงเนนธรกจทสนบสนนดานการทองเทยว และการพฒนาอสงหารมทรพย เปนหลก
บรษท เอม บ เค จากด(มหาชน) เปนผประกอบธรกจระดบแนวหนาของประเทศไทย โดยมงเนนธรกจทสนบสนนดานการทองเทยว และการพฒนาอสงหารมทรพย เปนหลก โดย MBK ไดจดทะเบยนแปรสภาพบรษท เปนบรษทมหาชนจากดชอวา “บรษท เอม บ เค พรอพเพอรตส แอนด ดเวลลอปเมนท จากด (มหาชน)”เมอวนท 8 เมษายน 2537 และไดรบอนญาตให เปนบรษทจดทะเบยนในตลาดหลกทรพยแหงประเทศไทย อกครงเมอวนท 5 เมษายน 2539 ใชชอยอหลกทรพยวา “MBK - PD” โดยเรมมการซอขาย หนสามญ ของบรษทฯ ในตลาดหลกทรพยแหงประเทศไทยเมอวนท 24 เมษายน 2539ตอมาเมอวนท 20 พฤศจกายน 2545 บรษทฯ ไดเปลยนชอบรษทจาก “บรษท เอม บ เค พรอพเพอรตส แอนด ดเวลลอปเมนท จากด (มหาชน)” เปน “บรษท เอม บ เค ดเวลลอปเมนท จากด (มหาชน)” และเมอวนท 10 พฤศจกายน 2546 บรษทฯ ไดเปลยนชอบรษทฯ อกครงจาก “บรษท เอม บ เค ดเวลลอปเมนท จากด (มหาชน)” เปน “บรษท เอม บ เค จากด (มหาชน) ” “MBK” และเปลยนชอยอหลกทรพยจาก “MBK - PD” เปน “MBK” จนถงปจจบนMBK ประกอบดวย 8 กลมธรกจ คอ1. ธรกจศนยการคา 2. ธรกจโรงแรมและการทองเทยว 3.ธรกจอสงหารมทรพย 4.ธรกจกอลฟ 5. ธรกจขาว 6. ธรกจการเงน 7.ธรกจอนๆ 8. ธรกจสนบสนน ดงน
บรษท เอม บ เคMBK ประกอบดวย 8 กลมธรกจ คอ
ตวอยาง Business Rule
ตวอยาง Business Model
UML : Unified Modeling Language
Use CaseDiagramsUse Case
DiagramsUse CaseDiagrams
ScenarioDiagramsCollaboration
Diagrams
StateDiagramsState
DiagramsComponentDiagrams
ComponentDiagramsComponent
DiagramsDeploymentDiagrams
StateDiagramsState
DiagramsObjectDiagrams
ScenarioDiagramsScenario
DiagramsStatechartDiagrams
Use CaseDiagramsUse Case
DiagramsSequenceDiagrams
StateDiagramsState
DiagramsClassDiagrams
ActivityDiagrams
Models
http://www.siam2dev.com [ dr. nattapong songneam]
1. Software Development Process
1. Requirement Specification : define problem domain
2. Analysis : what problem to be solved? (อะไรคอปญหาทตองแก)
3. Design : how to solve the problem? (แกอยางไร)
4. Implementation : how to implement the solution?
5. Testing : how to ensure that the solution can solve the problem?
1. ทดสอบในเรองความเรว ประสทธภาพ ความปลอดภย ความมนคง เสถยร
2. ทดสอบความเขากนได หรอ การประกอบของสวนยอยๆ
6. Maintenance : how to adjust the solution to accomodate change?
1. ในรอบระยะเวลาหนงอาจจะตองมการปรบเปลยน
7. Retirement : when does the system to be retired?
บทท 5 Requirement Specification
Use case
StopA
A
หา Business Rule/Model
Start
Planning
Requirement Specification
สราง Use Case Diagram
สราง Class diagram
ออกแบบ UI and Prototype
Implementation /coding
Testing
อ.ดร. นฐพงศ สงเนยม 18
ขอกาหนดของความตองการ(Requirement Specifications)
2. System Analysis• กระบวนการวเคราะหระบบ (system analysis phase)
– มงเนน “what” ทระบบจะตองม และตองทาใหกบผใช โดยยงไมเนน “how” วาจะทาอยางไร (ในขนตอนนเปนการ User Requirement)
• กระบวนการวเคราะหความตองการของผใชระบบ (Requirementanalysis phase)– ใชในการสรางแบบจาลองหนาทการทางานของระบบ
ซอฟตแวร จากมมมองของผใชภายนอก หรอ ระบบภายนอก– จะไดแบบจาลองของความตองการของผใชระบบ
(Requirement Model) เปน Output
จาก UP ในเฟส ท 2 สงจะตองได หรอเสรจ กคอ Use case 80%
What >> Analysis1. ระบบตองขายสนคาได2. เกบขอมลพนกงานได3. ....
How >> Design / Implement– ออกแบบ ขอ 1. ใน Traditional Method กคอการ ออกแบบ
อลกอรทม/Pseudo Code, และเขยนผงงาน / ผงโครงสราง– แบบเชงวตถ กสรางเปน use case diagram และ class diagram
Requirement Specification
ระบบขายสนคา
ซอ
ลกคา
สนคา/ ใบเสรจ
ขอมลสนคา
โปรแกรม ตองทางาน
อยางไร
Cjava
การซอ จะตองเขยนโปรแกรมอยางไร
การเกบขอมลลกคา มความตองการ อะไร
1. ขอกาหนดของความตองน คอ จะทาอยางไร กบขอมลน มความตองการอะไรบาง
2. เชน ในการจดเกบหรอบนทกขอมลลกคา มเงอนไข หรอขอกาหนดตางๆ ดงน
1. การเกบขอมล จะตองเกบใหครบได รหส เลขทบตรประชาชน ชอ ทอย เบอรโทร เพศ สถานะ อเมล ขอมลเหลานจะตองเกบลงในฐานขอมล
2. จะขาดสงใดสงหนงไมได ระบบจะตองไมยอมใหบนทก
3. เบอรโทร จะเกบ 10 หลก หามเกน หามขาด
4. เบอรโทรจะตองไมเปนตวอกษร
5. เลขทบตรประชาชน จะตองเปน 13 หลก และเปนตวเลขเทานน
6. สถานะ จะตองประกอบไปดวย โสด สมรส อยาราง
7. อเมล จะตองถกตองตามหลก โดยม @
122233333333333
เลขทบตรประชาชน
ความตองการนมาจากผใช end user/ system ownerเจาของความตองการ โดยแทจรงไมใชลกคา
Requirements
1.
ออกแบบ Use case
2.
ทาไมตอง 1-2 เดอน หรอ ทาไม 3-4 หรอเทาไร ?
3. System Analysis and Use Case
• Use Case Model– แบบจาลองความตองการของระบบ ท นาเสนอ functional
requirement ของระบบโดยรวม จากมมมองของผใช ภายนอก หรอ ระบบภายนอก
– ระบพฤตกรรม หรอหนาทการทางานของระบบ (เนน “what”) ทระบบตองม
– ใชในการทดสอบ และตรวจสอบ โครงสราง และหนาทการทางานของระบบ
– ใน UML สามารถระบเปน / เราสามารถเขยน use case ได 2 แบบ คอ
• Use Case Description (Text) หรอ • Use Case Diagram(Diagram)
บทท 5
ความแตกตางระหวาง what และ how
• What คอระบบนน จะตองมมความตองการหรอฟงกชนอะไรบาง
• How แตละความตองการหรอฟงกชน จะทาอยางไร
ระบบโรงแรม ทาอะไรบาง
•Functional requirements ?•Non-Functional requirements ?
ความตองการของระบบโรงพยาบาล
จงบอกความตองการตอไปน ขอใดเปนฟงกชน และขอใดไมเปนฟงกชน
1. ระบบจะเกบขอมลลกคาได .....................เปน..............................
2. ระบบสามารถเรยกใชงานไดทนท ...................เปน............................
3. ระบบสามารถรองรบการเชอมตอกบ Linux ………………เปน……………4. ระบบสามารถใชงานผาน wifi ได .........................ไมเปน...............................5. ระบบจะตองรายงานยอดผ ปวย แตละวนได ......................เปน.....................
6. ระบบจะตองบนการจายยาได ...................................เปน..........................
7. ระบบจะตองตรวจสอบขอมลผ ปวยแตละโรคได ...............เปน..........................
8. ระบบจะตองรนผาน iOS ได ..................ไมเปน.....................................9. ระบบจะตองใชงานงาย ..............................ไมเปน................................
10. ระบบจะตองรนไดทก browser ………………ไมเปน…………………..
Requirement
• Req08 : คนหาขอมลหองพก{ จากความตองการของ พนกงาน }
– ระบบจะตองสามารถคนหาวาหองพกใด วาง/ไมวาง– ระบบสามารถตรวจสอบไดวาหองใด มลกคาคนใดเขาพก– ระบบสามารถตรวจสอบไดวา หองพกนน ครบกาหนด Check
out วนไหน/เมอไหร– ระบบสามารถตรวจสอบได วา ลกคา ใชบรการ Minibar
หรอไม– ตรวจสอบวามแมบานทาความสะอาดแลวหรอไม
Req01 , Req08 , Req15 , Req20 , Req09 , Req07, Req02
เปนฟงกชน หรอไมเปน
ลกคา
พนกงาน
คนหา
หองพก
ระบบเวบแอพพลเคชนจองหองพกออนไลน
ถาเปนออนไลน ลกคาสามารถเขาไปเซคหองพกไดวาวาง
หรอไมวาง
ลกคา
พนกงาน
คนหา
หองพก
ระบบการจองหองพกโรงแรมถาเปนระบบวนโดวแอพพลเคชน ลกคาจะไมสามารถเขาไปเซคหองพกไดวาวางหรอไม
วาง จะตอสอบถามผานพนกงาน
ตรวจสอบผ
เขาพก
<<include>>
Login
minibarจองหองพก
ลกคา
พนกงานคนหา
หองพก
ระบบการจองหองพกโรงแรมถาเปนระบบวนโดวแอพพลเคชน ลกคาจะไมสามารถเขาไปเซคหองพกไดวาวางหรอไม
วาง จะตอสอบถามผานพนกงาน
ตรวจสอบผ
เขาพก
Login
minibarจองหองพก
หองพกวาง
Validate Client
การพฒนาระบบจองหองพกโรงแรม ม Requirement ?
• Req01 : คนหาขอมลหองพก
• Req02 : สมครสมาชกได
• Req03 : จองหองพก
• Req04 : ชาระเงน
• Req05 : คนเงน
• ReqN : คนหองพก
Functional requirement
วาง และ พรอมเขาพก
ไมวาง และ มคนอย
วาง แต ไมพรอมเขาพก / ยงไมทาความสะอาด
จงวเคราะหระบบโรงแรม แลว เขยน
• Functional requirements ?• Non-Functional requirements ?
อยางละ 10
รายการ
ต.ย. Functional Requirements
• Req01 : การจองหองพก• { จากความตองการของ ลกคา }
– ในการจองหองพก จะมเงอนไขดงน• ระบบจะตองตรวจสอบขอมลการสมาชกได • ระบบจะตองทาการบนทกวาขอมลผจอง ไดแก รหส ชอ-นามสกล
เบอรโทร ทอย• ระบบจะตองสามารถตรวจสอบไดวา มหองวาหรอไม {uses Req08}• จะสามารถบนทกขอมลการจองหองพกได {uses Req09} โดยเกบ
วนท เวลา จานวนหอง จานวนผเขาพก วนทเชคอน วนท เชคเอาท• ระบบสามารถ ตรวจสอบไดภายหลงวา พนกงานคนใดเปนผรบการ
จอง• ถาเปนสมาชก จะมสวนลด 10 % {extend Req10}
จอง
ตรวจสอบหองพก
โปรแกรมยอย
• Sub(vb)/Procedure(pascal)• Function/
• Function/Method• คนคา
• ไมคนคา
ต.ย. Functional Requirements
• Req01 : สมครสมาชก• { จากความตองการของ ลกคา }
– ในการ สมครสมาชกจะมเงอนไขดงน• ระบบจะตองตรวจสอบขอมลการสมาชกได • ระบบจะตองทาการบนทกวาขอมลผจอง ไดแก รหส
เลขทบตรประชาชน ชอ-นามสกล เบอรโทร ทอย• ระบบตองตรวจสอบ ขอมลเลขทบตรประชาชน ทถกตอง
ได 13 หลก
ผใชระบบสารสนเทศ:แหลงของความตองการ
• เจาของระบบ (System owners/Sponsors ) – มสวนไดสวนไดเสยจากการลงทนสรางระบบสารสนเทศ
เจาของผบรหาร ผจดการ• ผใชภายใน (Internal users)
– End-users คอผใชทปอนขอมลเขาสระบบโดยตรง ไมจาเปนตองมทกษะหรอความรมาก เนนความถกตองและรวดเรวของการปอนขอมลเขาสระบบ
– Power-users คอผใชทมความรความชานาญเฉพาะดาน สามารถใชงานฟงกชนของระบบในสวนทมความซบซอนได
– Administrators คอผทดแลและควบคมใหระบบสามารถดาเนนการไดอยางราบรนตามวตถประสงคทตงไว
– Executive users คอผใชทตองการสารสนเทศมาเพอการตดสนใจและบรหารองคกร
• ผใชภายนอก (External users)– ผใชซ งเปนบคคลภายนอกองคกร แตสามารถเขาถงบรการของ
ระบบในองคกรได
จากทเคยสอนไปแลว บทท 5
Use Case Description Example
• Name: การสงรายการซอขายหลกทรพย (Place Order)– Main flow of events:
1. Trader ปอนชอ และรหสของ client2. System ตรวจสอบ (Validate) ชอ รหส และ credit ของ
client3. Trader ปอนรหสหลกทรพย จานวนหลกทรพย และราคา
หลกทรพย ท Client ตองการซอขาย4. System ตรวจสอบเงอนไขราคาของหลกทรพย
{ตรงกบเงอนไขของตลาดหรอไม เชน Margin ขนตาเทาไร}5. System สง order ใหกบตลาดหลกทรพย6. System เกบหมายเลข order ทไดรบจากตลาดหลกทรพย7. System แจงให Trader ทราบ
Trader
Place OrderStock
Exchange Market
Use case ไดมาจาก Requirement Specification
4. Use Case Diagram• นาเสนอฟงกชนหรอ Use Case และการปฏสมพนธโตตอบกน
ระหวางระบบ และ ผใชภายนอก (someone / something อาจเปนคน หรอระบบกได)
• สวนประกอบของ use case diagram ดวย– Use Case – ฟงกชน/ความสามารถ/หนาทของระบบ– Actor – ผทมบทบาท/ ผกระทา/ผใชงาน Use Case นนๆ– Relationship - เสนแสดงความสมพนธระหวาง Use Case กบ
Actor– System / System Boundary - ระบบทกาลงพฒนา
Use Case Modeling : Core Elements
Construct Description Syntax
use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.
actor A coherent set of roles that users of use cases play when interacting with these use cases.
system boundary
Represents the boundary between the physical system and the actors who interact with the physical system.
UseCaseName
ActorName
Construct Description Syntax
association The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.
generalization A taxonomic relationship between a more general use case and a more specific use case.
extend A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case.
Use Case Modeling : Core Relationships
<<extend>>
Construct Description Syntax
Include / uses An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case.
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
รายการ
การถอนเงนสด
อาจจะเปนของใครกได
เปนการระบรายละเอยด
หรอ ยกตวอยางมา 1
รายการ
ซอขาว
นาย ก. แลกคปอง 100 บาทแลกคปอง
สวมล ซอขาวมนไก 30 บาท
Scenario is a capture of use case
ถอนรายวชา
เพมรายวชา
•สมชายถอนรายวชา OOAD•สมศร ถอนวชาแคลคลส•สมควร ถอนวชา OOP
scenarioUse case
สมหญงเพมรายวชา OOP
การสมครสมาชก นาย นฐพงศ สมครบตรเครดตนาย สมศร สมครสมาชก MK
class Instances/objects
จองหองพก
ตรวจสอบหองวาง
นายแดงจองหอง 142นาย ก จองหองพก เลขท 321...
scenariousecase
สมศรตรวจสอบหอง 142
อะไรคอ Transaction ?
• ราน เซเวน– ขายสนคา– ซอสนคา– เพมขอมลสนคา– เปลยนราคาสนคา– คนหารายการสนคา
• โรงภาพยนตร• โรงแรม
Transaction หลายๆ transaction รวมเปน use case อาจกลาวได วา use case กคอ
requirement นนเอง
ระบบ รานเซเวน
• Use case ซอสนคา• Scenario : สมศร ซอแปรงสฟน 2 อน• Scenario : นายก. ซอขนมปง 5 ชน
ใชตอนทดสอบโปรแกรม
ซอสนคา
ใชตอน นา use case ไปทดสอบระบบ
Transaction
แปรงสฟน 2 ดาม
ขนมเลย 1 หอ
ขนมปง 1 หอ
นม 1 โหล
• Use case : คานวณ พท. สเหลยม• Scenario :: สเหลยมท ก 2 ยาว 4
ใชในตอนออกแบบ วาโปรแกรมตองทาอะไรไดบาง
ใชในตอนทดสอบระบบ วาเปนไปตาม use case หรอไม
Actors• Actor หมายถง someone หรอ some thing ทมการ
ปฏสมพนธ โตตอบกบระบบ– สงใดกตามทมความตองการในการแลกเปลยน
information กบระบบ หรอ สงใดกตามทอยภายนอกระบบ และมการใชงาน Use Case ของระบบ
– กาหนดบทบาทหนาทของผใชระบบ (actor ใชสาหรบกาหนดบทบาท ของผใชระบบ วาทาอะไรกบระบบ หรอใช อะไร/ตดตอจากระบบ)
– กาหนดการเชอมโยงกบระบบอนๆ ภายนอก• ตวอยางของ Actors
– Customer -- maintain their account (ลกคาตองการปรบปรงรายการบญชของตวเอง)
– Cashier -- verify withdrawal amountCustomer Cashier
เวลา คณถอนเงน แคชเชยร สามารถตรวจสอบยอดการถอนได
ในการเกบขอมลลกคา• Req05 : จดการขอมลลกคา
– เพมลกคาใหม/สมครสมาชก– แกไขขอมลลกคา {customer/staff/admin}– จะตองใหลกคาสามารถด ขอมลตนเองได– จะตองใหลกคา แกไข ขอมลลกคา บางอยางได Customer -- maintain their
account (ลกคาตองการปรบปรงรายการบญชของตวเอง)
Customer
Maintain their account
Add new customer Staff
คลนก ลกคา ตองการแกไขทอย ผานเคาเตอร / พยาบาล
Delete account
Admin
Actor หมายถง someone หรอ some thing ทมการปฏสมพนธ โตตอบกบระบบสงใดกตามทมความตองการในการแลกเปลยน information กบระบบ หรอ สงใดกตามทอยภายนอกระบบ และมการใชงาน Use Case ของระบบกาหนดบทบาทหนาทของผใชระบบกาหนดการเชอมโยงกบระบบอนๆ ภายนอก
ATMchkpassword
Actor
ATM
customer
Validate account
<<
include>>
Actors• Actors สามารถอธบายโดยใช Generalization/Specialization
Relationship
• อาจพจารณา Actors เปนคลาส ใน UML เนองจากม relationships เชนเดยวกบทคลาสม
Generalization/specialization relationship
Customer
ATM Customer Cashier Customerจงอธบายรปน ?
แบงโดยใชเกณฑ ลกษณะของการใชงาน
Actors• Actors สามารถอธบายโดยใช Generalization/Specialization
Relationship
• อาจพจารณา Actors เปนคลาส ใน UML เนองจากม relationships เชนเดยวกบทคลาสม
Generalization/specialization relationship
Customer
Personal Customer Coporate 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 System
System & Use cases
• A system there are several use cases.
usecase3
usecase5
usecase2
Usecase1 usecase
N
usecase4
• ในระบบหนงๆ จะม ยสเคสไดอะแกรมไดหลาย ยสเคสไดอะแกรม• ในแตละยสเคสไดอะแกรม จะมหลายๆ ยสเคส
usecase1
usecase2
usecase3
usecase4
usecase
usecase
Usecase 1
usecase
ระบบใหญ
Use case 1
จดการลกคา
• เกบประวต • แกไข• ลบ• คน
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
จงอธบายรปน ?
ตวลกมเหมอนพอแม แตสามารถดดแปแลงเพมเตมความสามารถของพอแมได
Parent use case
child use case
“Include” relationship• มกใชในการหลกเลยงการอธบายการไหลของเหตการณ (flow of events) เดม ซา
กนหลายๆ ครง โดยรวบรวมพฤตกรรมรวม ใน Use Case
• หลกเลยงการ copy & paste ของ Use Case Descriptions
• เปรยบเสมอนการเรยกโปรแกรมยอย/ฟงกชน จากโปรแกรมหลก
Validate client
Place order
<<include>>
Track order
<<include>>
ทกครงทจะซอ/
ขาย ตอง login
โปรแกรมหลก
โปรแกรมยอย
“Include” relationship• มกใชในการหลกเลยงการอธบายการไหลของเหตการณ (flow of events) เดม ซา
กนหลายๆ ครง โดยรวบรวมพฤตกรรมรวม ใน Use Case
• หลกเลยงการ copy & paste ของ Use Case Descriptions
• เปรยบเสมอนการเรยกโปรแกรมยอย/ฟงกชน จากโปรแกรมหลก
Validate client
Place order
<<include>>
Track order
<<include>>
ทกครงทจะซอ/
ขาย ตอง login
โปรแกรมหลก
โปรแกรมยอย
Trader
Read mail
Login
<<include>>
Post FB
Login
<<include>>
ใน UML ไมไดกลาวถงมาตรฐาน ส แปลวา ไมกาหนดวาสใดหมายถงอะไร แตสญลกษณ ถกกาหนดไว
“Include” Example• Name : การตรวจสอบรายการซอขายหลกทรพย
(Track Order) – Main flow:
1. ใชหมายเลข order ในการตรวจสอบ ทไดรบจากตลาดหลกทรพยObtain and verify order number
2. Include สวนของ “Validate client”3. ในแตละสวนของ Order …
Track Order ValidateClient
<<include>>
Use case description
Use case diagram
“Extend” relationship
• ใชสรางแบบจาลองบางสวนของ Use Case ท user อาจมองเปน optional– Optional หมายถง นอกเหนอ จาก
เหตการณปกต หรอมากกวาปกต หรอพเศษ• ต.ย. สมครเรยน เอกสารขาดไมครบ• การลงทะเบยน เงนไมพอ
• ใช สรางแบบจาลอง conditional subflows
• ใชในการแทรก subflows ในจดทระบโดยพจารณา ปฏสมพนธระหวาง Actors
<<extend>>(set priority)
Place orderExtension points:
Set priority
Place rush order
conditional
“Extend” Example• Name : ¡ÒÃÊ‹§ÃÒ¡Òë×éÍ¢ÒÂËÅÑ¡·ÃѾÂ� (Place Order)
– Main flow of events:1. …2. Trader »‡Í¹à§×è͹䢢ͧËÅÑ¡·ÃѾÂ� ·Õè Client µŒÍ§¡ÒÃ
«×éÍ¢ÒÂ3. ¡íÒ˹´ÅíÒ Ñº¤ÇÒÁÊíÒ¤ÑÞ â´Â (set priority)4. System Ê‹§ order ãËŒ¡ÑºµÅÒ´ËÅÑ¡·ÃѾÂ�5. ...
Place Order Place RushOrder
<<extend>>
[ ]optional
Relationships between Use Case
WithdrawalCash
ValidateAccount
<<include>>
Ship PartialOrder
Ship Order
<<extend>>
Comparing extends/ uses• extend
– ใชแยกความแตกตางของ Use Case – actors ทเกยวของมกเปนคนกระทา Use case และUse
Case ทextend ทงหมด– actor มกเชอมตอกบ “base” Use Case
• include/use– ใช extract พฤตกรรมรวม– มกไมม actor เกยวของโดยตรงกบ Use Case ทม
พฤตกรรมรวม– actors ทแตกตางกน for “caller” use cases possible
A Use Case Diagram
Establish Credit
<<include>>
Trader
Validate Client
<<include>>
PlaceOrder
<<extend>>FinancialOfficer
TrackOrder
RetinalScan
CheckPassword
Place RushOrder
StockExchange
<<include>>
someone
someone
something
ให Problem Domain มา แลว functional / non-functional แลวสรางเปน usecase
A Use Case Diagram
<<include>>
Customer
Validate Account
<<include>>
BankTeller
Deposit
BalanceChecking
Transfer
Withdraw
Verifywithdrawal
<<include>>
ATM/CDM
ตอนทถอน มการตรวจสอบยอดเงนคงเหลอ /หมายถงธนาคารตองเชคกอน
<<include>>
<<include>>
Verify Transfer
ตรวจสอบเลข บช.ตรวจสอบจานวนเงน
A Use Case Diagram
<<include>>
Customer
Validate Account
<<include>>
BankTeller
Deposit
BalanceChecking
Transfer
Withdraw
Verifywithdrawal
<<include>>
<<include>>
ATM/CDM
ตอนทถอน มการตรวจสอบยอดเงนคงเหลอ /หมายถงธนาคารตองเชคกอน
Validate Account
Function Balance_checking() If balance >= amt then
balance = balance -amtElse
msgbox “เงนไมพอ”End if
End Funciton
WidtdrawBalance_Checking ()
..……
Implement with Visual Basic
Balance Checking
If balance >= amt thenbalance = balance - amt
Elsemsgbox “เงนไมพอ”
End if
WidtdrawBalanceChecking()
..……
BalanceChecking()
When and how?• Requirements capture
– ใชในการกาหนด Reuqirement ของระบบ– สรางแบบจาลอง (Model) ของ user requirements
ดวย Use Case• Test Scenarios
– สรางแบบจาลอง (Model) ของสถานการณการทดสอบระบบ (test scenarios) ดวย Use Case
• Use Case: – ระบส งท Actor ตองการใหมในระบบ– ต งชอให Use Case– เขยนคาอธบายส นๆ– เพมรายละเอยดในภายหลง
เปนหนาทของ use case specified
เปนหนาทของ use case designer
Finding Actors• สามารถระบ actor ไดโดยตอบคาถามตอไปน
– ใครเปนคนใชงานหนาทการทางานหลกของระบบ (primary actors)?– ใครตองการการสนบสนนการทางานจากระบบ?– ใครตองการบารงรกษา และบรหารระบบ (secondary actors)?– Hardware devices ใดทตองการใหระบบจดการดแล?
• ถาระบบฮารดแวร เครองจกรใด ตองการการซอมบารง / เครองจกรไมใชคน– ระบบภายนอกระบบใดท ตองการใหระบบมปฏสมพนธดวย?
• ระบบจายคานาประปา -- ไมใชคน แตเปนระบบ• ระบบเกบภาษ/จายภาษ – สรรพากร ไมใชคน
– ใคร หรอ อะไรทตองการไดรบผลประโยชน จาก output ของระบบ? • หลงจาก use case ทางานแลว สงผลลพธให ใคร
• Tips– ไมควรพจารณาเฉพาะ users ทใชงานระบบโดยตรง แต พจารณา users
อนๆ ทตองการใชบรการจากระบบดวย
association
หา Actors
จายเงนเดอน
ระบบจายเงนเดอนของ ขาราชการ ในมหาวทยาลย
ขาราชการ พนกงงานฝายบคคล
พนกงงานฝายบคคล
Finding Use Cases• สาหรบแตละ actor ตอบคาถามตอไปน
– หนาทการทางานอะไรท actor ตองการจากระบบ?– ขอมลใดบางท actor ตองการสราง อาน ลบ เปลยนแปลง หรอ
เกบอยภายในระบบ?– เหตการณใดบางทระบบตองแจงให actor ทราบ? หรอ actor
ตองแจงใหระบบทราบ? – หนาทการทางานของระบบ ชวยทาใหงานประจาวนของ actor
งายขนหรอไม?• ถาไมพจารณา actors
– อะไรคอ input/output ของระบบ ? input/output เหลานนมาจากไหน หรอใครเปนคนนาไปใชงาน?
– ปญหาหลกของระบบทใชงานอย คออะไร?
หนาทการทางานอะไรท actor ตองการจากระบบ?
Student
คนหาเกรด
เปลยนชอ
ถอนวชา
การปรบปรง
ขอมลนกศกษา
Recipe (เทคนค)• ระบ actors ทมปฏสมพนธกบระบบ• พจารณาแนวทางของระบบ ในการปฏสมพนธกบ
actors• จาแนกพฤตกรรมของระบบใน การปฏสมพนธกบ
actors ใหเปน use cases โดยกาหนดความสมพนธระหวาง Use Case
ตวอยางการเขยน Use case
ตวอยาง use case
• ผใชงานสอดบตร ATM เขาสเครองรบบตร หากบตรใชงานไดจงเขาสหนาจอ Main Menu หากใชงานไมไดบตร ATM จะถกปลอยคน (Reject) ออกมา หากบตรใชได ผใชงานตองระบประเภทบญชและจานวนเงนทตองการถอน หากมเงนในบญชมากกวาหรอเทากบจานวนทระบ ผใชงานสามารถนาเงนออกจากเครอง ATM ได
85
ตวอยาง scenario
Scenario ท 1• นายสมชายสอดบตร ATM ของธ.กรงเทพ สาขาหาดใหญ แต
บตรเสย บตรจงถก reject ออกมา
86
ตวอยาง scenario
Scenario ท 2• นางสมใจสอดบตร ATM ของธ.ทหารไทย สาขาบางเขน บตร
สามารถใชการได แตเงนในบญชไมพอจาย จงไมสามารถนาเงนไปใชได
87
ตวอยาง scenario
Scenario ท 3• นายสมบตสอดบตร ATM ของ ธ.ทหารไทย สาขาบางเขน บตร
สามารถใชการได และมเงนในบญชเพยงพอ เขาตองการถอน100 บาท และในบญชมเงนจานวน 250 บาท ดงนนนายสมบตจงสามารถนาเงนออกจากเครอง ATM ไปใชได
88
ต.ย. Use case diagram ทม uses
• จงสราง use case diagram เพออธบายการตรวจสอบ user ทเขามาในระบบคอมพวเตอรขององคกรตาง ๆ ตองมการตรวจสอบรหสผานรวมอยดวย โดย actor ของระบบนคอผจดการระบบ
89
ข นตอนท 1 :หา use case และ actor ของระบบ
• use case ของระบบคอ– การตรวจสอบ user (Validate user)– การตรวจสอบรหสผาน (Check password)
• actor ของระบบคอ– ผจดการระบบ (System Administrator)
90
ข นตอนท 2 : เขยน scenario ของระบบ
• scenario ท 1 : user ปอน password ทถกตอง– การตรวจสอบ password ใน use case ชอ check
password ตรวจสอบไดถกตอง ทาใหกจกรรมใน validate user ดาเนนตอไปได
91
ข นตอนท 2 : เขยน scenario ของระบบ
• scenario ท 2 : user ปอน password ทไมถกตอง– ทาให use case ชอ check password ถกเรยกใชอก
หลายครงจนกวาจะถก หรอจนกวาจะครบ 3 ครง จงตด user คนนนออกจากระบบ
92
ข นตอนท 3 : เขยน use case diagram
User Authorization
Validate Users Check Password
SystemAdministrator
<<uses>>
93
ตย. Use case diagram ทม extends
• จงสราง use case diagram ทแสดงการรบโทรศพท ซงขณะทรบโทรศพทปกต หากมสายเรยกซอนเขามา อาจทาใหตองมการรบสายเรยกซอนกอน ซงทาใหการรบสายโทรศพทตามปกตตองชะงกชวคราว
94
ข นตอนท 1 : หา use case และ actor ของระบบ
• use case ของระบบคอ– การรบโทรศพท– การรบสายเรยกซอน
• actor ของระบบคอ– ผรบโทรศพท
95
ขนตอนท 2 : เขยน scenario ของระบบ
• scenario ท 1 : เกดสายเรยกซอน– เมอเกดสายเรยกซอน ทาให use case การรบโทรศพท เกด
การชะงกงน ซงผรบอาจหยดการสนทนาชวขณะ– หรอผรบเปลยนไปรบสายทเรยกซอนแทน
• scenario ท 2 : ไมเกดสายเรยกซอน
96
ข นตอนท 3 : เขยน use case diagram
การรบโทรศพท
รบโทรศพท รบสายเรยกซอน
ผรบโทรศพท
<<extends>>
97
ตวอยาง การเขยน use case diagram
• จงสราง use case diagram เพออธบายการลงทะเบยนของนกเรยน ซงเกดจากผลของการวเคราะหความตองการเบองตน สามารถเขยนเปนรายการไดดงน
98
ความตองการ (Requirement)
• ในแตละภาคการศกษาจะมการลงทะเบยนของนกศกษา โดยนกศกษาทลงทะเบยนในแตละภาคการศกษาจะม 2 ประเภทคอ– นกศกษาปจจบน– นกศกษาใหม
99
ความตองการ...
• การลงทะเบยนในแตละครงจะมการเกบหลกฐานและคาเลาเรยน • ซงการลงทะเบยนเรยนจะเสรจสนไดกตอเมอหลกฐานทไดรบมา
ครบถวนถกตอง• และในขณะเดยวกนเงนคาเลาเรยนทเรยกเกบไดกตองมจานวน
ครบถวนดวย
100
ความตองการ...
• เจาหนาทของสถาบนการศกษาจะเปนผจดการในเรองของการจดเกบหลกฐานและคาเลาเรยนทงหมด
• และผจายเงนตองเปนนกเรยนเทานน
101
ความตองการ...
• สาหรบนกศกษาบางคนทไดรบสทธพเศษเชน– ไดรบทนเรยนฟร– เปนนกกฬาของสถาบน– หรอเปนผทาชอเสยงใหสถาบนจะมสทธไดรบยกเวนคาเลาเรยนในบางภาคการศกษา
102
หา use case ของระบบ
• use case ของระบบคอ– การลงทะเบยนนกศกษา– การเกบหลกฐาน– การชาระคาเลาเรยน
103
หา use case อนทเก ยวของ
• หา use case อนทเก ยวของคอ– การลงทะเบยนนกศกษา
• การลงทะเบยนนกศกษาใหม• การลงทะเบยนนกศกษาปจจบน
– การเกบหลกฐาน• หลกฐานไมพรอม
104
หา use case อนทเก ยวของ
• หา use case อนทเก ยวของคอ– การชาระคาเลาเรยน
• มเงนไมพอชาระคาเลาเรยน• ไดรบการยกเวนคาเลาเรยน
105
หา actor ของระบบ
• Actor ของระบบคอ– เจาหนาท– นกศกษา
106
เขยน Use Case Diagram
ลงทะเบยนนกศกษาใหม
ลงทะเบยนนกศกษาปจจบน
ชาระเงนคาเลาเรยน
เกบหลกฐาน
หลกฐานไมพรอม
มเงนไมพอชาระคาเลาเรยน
ไดรบการยกเวนคาเลาเรยน
เจาหนาท
นกศกษา
<<uses>>
การลงทะเบยนเรยนของนกศกษา 107
การเขยน Use caseองคประกอบมดงน
- ชอของ Use Case
- ภาพรวมของการทางาน (Overview)
- Actor หลก (Primary Actor)
- Actor รอง (Secondary Actor)
- จดเรมตน (Starting Point)
- จดสนสด (End point)
- การทางานของ Use Case (Flow of Events)
- การทางานของ Use Case เมอมปญหาเกดขน (Alternative flowof Events)
- ผลของการทางานของ Use Case (Measurable Result)
Use Case : Create Order• ภาพรวมของการทางาน (Overview)
จดประสงคหลกของ Use Case น เพอทาการลงขอมลในใบสงซอสนคาจากลกคา
• Actor หลก (Primary Actor)ตวแทนฝายขายสนคา
• Actor รอง (Secondary Actor)ไมม
• จดเร มตน (Starting Point)Use Case ตวนเร มตนเมอ Actor ตวแทนฝายขายสนคาขอใหระบบ
ทาการลงขอมลการสงซอสนคา• จดสนสด (End point)
คาขอเพอทาการลงขอมลการสงซอสนคาเสรจสนสมบรณหรอไมกถกยกเลก
Use Case : Create Orderการทางานของ Use Case (Flow of Events)
จาก User Interface บนจอเพอทาการลงขอมลการสงซอ Actorจะตองทาการใสขอมลเกยวกบการสงซอ เปนตนวา วนทลกคาตองการใหสนคาสงมอบถงมอ (Required Date) ปรมาณทตองการส งซอ (Quantity) ตองการใหสงมอบสนคาโดยบรษทสงสนคาไหน (Ship Via) ตองการใหใหสงมอบสนคาทไหน (Ship Address) หลงจากนนแลว Actor สามารถเลอกทจะทาการบนทกขอมลลงไปไวในฐานขอมล หรอยกเลกการทางานทงหมด ถา Actor เลอกทาการบนทก ใบสงซอใบใหมกจะถกสรางขนมาในฐานขอมล
Use Case : Create Orderการทางานของ Use Case เมอมปญหาเกดขน
(Alternative Flow of Events)ถาไมมสนคาทตองการอยในคลงสนคา ระบบจะตองแจงให Actor ทราบพรอมกนนนกตองยกเลกการทางานทเหลอของUse Case น
ผลของการทางานของ Use Case (Measurable Result)จะมใบสงซอสนคาใหม 1 ใบขนมาในระบบ
Cash Register Example
Use Case: Buy items
Actors: Customer, Cashier
Type: Primary
Description: A Customer arrives at a checkout with items to purchase. The Cashier records the purchase itemsand collects payment. On completion, the Customer leaves with the items
Expanded Use Case Example
Use Case: Buy Items with Cash
Actors: Customer (initiator), Cashier
Purpose: Capture a sale and its cash payment
Overview: A Customer arrives at a checkout with items topurchase. The Cashier records the purchase items and collects a cash payment. Oncompletion, the Customer leaves with the items.
Type: primary and essential
Cross references: R1.1, R1.2, R1.7
Expanded Use Case (2)
1. This use case begins when a Customer arrives at the register with items to purchase.
2. The cashier records the identifier from each item. If more than one of the same item, the Cashier can enter the quantity as well.
4. Cashier indicates completion of item entry.
6. Cashier tells the Customer the total.
3. Determines the item price and adds the item information to the running sales transaction. The description and price of the item are presented.
5. Calculates and presents the sale total.
TYPICAL COURSE OF EVENTS
ACTOR ACTION SYSTEM RESPONSE
Expanded Use Case (3)
7. The Customer gives a cash payment -possibly greater than the sale total.
8. The Cashier records the cash received amount.
10. The Cashier deposits the cash received and extracts the balance owing. Cashier gives balance and receipt to Customer.
12. Customer leaves with items purchased.
ACTOR ACTION SYSTEM RESPONSE
9. Show the balance due
back to the Customer.
Generates a receipt.
11. Logs the completed
sale.
Expanded Use Case (4)
• Alternative Courses
• Line 2: Invalid identifier entered. Indicate error
• Line 7: Customer didn’t have enough cash. Cancel sales transaction
• If a Typical Course of Events has multiple equally likely courses of action
– indicate branches in Use case
– write a subsection for each branch indicating the typical course of events
– have alternatives for each subsection if necessary
Use case ของ ระบบรบ-สงเมล
http://i.stack.imgur.com/zAAcZ.jpg
student teacher
member
Borrow book
Return Book
LibrarianCheckingMember
Check period
borrowed
Calculation fine
ระบบการยมหนงสอในหองสมด(Borrow book from library)
<<include>> <<
extend>>
user customer CardAuthorization
CheckInventory Status
Object Actors Product
แบบฝกหด
• จงเขยน functional requirement ของการจองหองพกโรงแรม1. เขยน Requirement Specification2. หา Actor3. หา use case4. เขยน 5 Scenario5. แลวเขยน use case diagram ของการจองหองพก
โรงแรม