โดย อ.ดร. นฐพงศ สงเนยมhttp://[email protected]
สาขาวชา วทยาการคอมพวเตอรคณะวทยาศาสตรและเทคโนโลย มหาวทยาลยราชภฏพระนคร
Last Update : 05/01/2561
Lec06_การวเคราะหความตองการ (Requirement Analysis) ดวย Use case
http://www.siam2dev.com [ dr. nattapong songneam]
ดร. นฐพงศ สงเนยม
• http://www.siam2dev.com• E-mail : [email protected]• E-mail1 : [email protected]• E-mail1 : [email protected]• Facebook : [email protected]
http://www.siam2dev.com [ dr. nattapong songneam]
Lec06_การวเคราะหความตองการ (Requirement Analysis)
อ. นฐพงศ สงเนยมhttp://[email protected]@hotmail.com
Project• รปเลมรายงาน
– กาหนดหวขอ Project• ระบบโรงพยาบาล• ระบบโรงภาพยนตร• ระบบสนคาคงคลง• ระบบโรงแรม• ระบบบรหารการศกษา / ระบบการเรยนการสอน
– กาหนดความรบผดชอบ Project โดยใช Unified Process– ทา ขอเสนอโครงการ Proposal– วางแผน Gantt Chart + PERT chart– Usecase diagram– Class diagram– Sequence diagram / Communication Diagram– Activity Diagram
สมมต ใหมงบไมตากวา 1 ลานบาท
วเคราะหระบบงาน 1 ระบบดวยวธการเชงวตถใหแบงออกเปน 3 กลมกาหนดสงวนสอบปลายภาครปเลมรายงาน + CD
4.2 โครงสรางกรรมวธ - Lifecycle Phases
เตรยมงาน (Inception) – นยามขอบเขตของโครงการ , ขอบเขตของระบบทจะพฒนา
OOAD : Object-Oriented Analysis and Design 5
Inception Elaboration Construction Transition
time
Unified process แบงการพฒนาออกเปน 4 เฟส (phases)
ทารายละเอยด (Elaboration) – วางแผนโครงการ จดทารายละเอยดความตองการ จดสรางสถาปตยกรรมระบบ
จดสราง (Construction) – สรางและทดสอบโปรแกรม
ถายโอน (Transition) – ตดตงถายโอนระบบใหกบผใช
5
Requirement Analysisเซตอพระบบ วางแผนกาหนดหนาท ใครทาอะไร
UP : Phase 1. Inception• ชวงเรมตนของโครงการ
– ไดรบมอบหมายจาก เจาของกจการ / ลกคา / หวหนา ใหรบผดชอบโครงการเราจงเรยก วาเปน PM : Project Manager
– ในขนตนสงทคณตองทา กคอ จดหาทม และทา Proposal >> เคาโครงโครงการ/ แบบเสนอโครงการ/ตอผบรหาร
• หวขอหลกๆ
– ชอโครงการ เชน การพฒนาระบบจองหองพกโรงแรม
– ทมา ความสาคญของปญหา
– วตถประสงค
– ขอบเขต
– เทคโนโลย / นวตกรรม / กระบวนการทใช /วธการทใช
– แผนการดาเนนงาน ระยะเวลา / Gantt Chart
– งบประมาณ / อปกรณ / เครองมอ
– ผลทคาดวาจะไดรบ
ตองไดรบอนมต
เมอเสนอแลว และไดรบอนมตจงสามารถทาเฟส 2 ตอได
สงทสาคญ คอ ความนาเชอถอ
- ดจากอะไร ?
The Iterative Approach
OOAD : Object-Oriented Analysis and Design 8
Disciplinesgroup activities
logically
In an iteration,you walk through
all disciplines
8
รวบรวมขอมลควรเสรจภายใน เฟสท 1
รอบเฟสงาน
สป. 1 สป. 2 สป. 3 สป.4 สป.5Inception
ElaborationConstruction
Transition
Gantt Chart
กระแสงาน(workflow)
RequirementAnalysis
DesignImplement
TestingDeployment--------------
Configuration ManagementProject Management
Project ใหญ หนวยนบเวลา เปนเดอน หรอ ป
Project เลก กนบเปน สป.
ความตองการ (Requirements)
• ความตองการ (Requirements) ในทนหมายถงคณลกษณะในดานตางๆ ของระบบ
สารสนเทศทกาลงจะทาการพฒนาขนเพอ ใหระบบสามารถทางานตอบสนองตอผ
ใชไดอยางแทจรง
• แหลงของความตองการนนมาจากผใช (USER)
• นกวเคราะหระบบจะตองเปนผสงเคราะหความตองการนนจากขอมลตางๆ ทได
รบมาจากผใช โดยทาใหเปนขอกาหนดของความตองการ (Requirement
specifications) เพอใชเปนเปาหมายและขอบเขตของการพฒนาระบบตอไป
ต.ย.
• กระบวนการตงแต คนไข เขา โรงพยาบาล จนกระทงรกษาเสรจ/หายปวย ทาอะไรบาง
• กระบวนการตงแต นกเรยนมาสมครเปน นศ. และเขาเรยนไดทาอะไรบาง
1. ...................................
2. ...................................
3. ...................................
4. ...................................
5. ....................................
1. ...................................
2. ...................................
3. ...................................
4. ...................................
5. ....................................
การวเคราะหความตองการ
Requirement Analysis
• การวเคราะหความตองการ คอกระบวนการวเคราะหเพอหาขอกาหนดความตองการ
ของผใช โดยจะตองอาศยขอมลในดานตางๆ ทไดรบมาจากผใชและองคกรของผใชเพอ
ทาการวเคราะห
RequirementAnalysis
User requirement
Business Workflow
Problemsstatement
Business Information&Rule
RequirementSpecification
INPUT PROCESS OUTPUT
ผใชระบบสารสนเทศ:
แหลงของความตองการ
• เจาของระบบ (System owners/Sponsors )
– มสวนไดสวนไดเสยจากการลงทนสรางระบบสารสนเทศ เจาของผบรหาร ผจดการ
• ผใชภายใน (Internal users)
– End-users คอผใชทปอนขอมลเขาสระบบโดยตรง ไมจาเปนตองมทกษะหรอความรมาก เนนความถกตองและรวดเรวของการปอนขอมลเขาสระบบ
– Power-users คอผใชทมความรความชานาญเฉพาะดาน สามารถใชงานฟงกชนของระบบในสวนทมความซบซอนได
– Administrators คอผทดแลและควบคมใหระบบสามารถดาเนนการไดอยางราบรนตามวตถประสงคทตงไว
– Executive users คอผใชทตองการสารสนเทศมาเพอการตดสนใจและบรหารองคกร (EIS/MIS/DSS)
• ผใชภายนอก (External users)
– ผใชซงเปนบคคลภายนอกองคกร แตสามารถเขาถงบรการของระบบในองคกรได
คณจะไดทางานกตอเมอนาเสนอ Proporsal ผาน
เปนผใชงาน ระบบทางออม
ลกคา ของ โรงแรม
ตอบคาถามเหลานใหได
• โรงพยาบาล ใครคอ System Owner / Sponsor• โรงเรยน ใครคอ System Owner / Sponsor• โรงภาพยนตร ใครคอ System Owner / Sponsor• โรงแรมใครคอ System Owner / Sponsor• มหาวทยาลย System Owner / Sponsor• ในมหาวทยาลย End User• ในมหาวทยาลย executive user
ทาไมตองรจก User หรอ ทาไมตองแบง User ออกเปนกลมๆ
• เหตผล คอ แตละคนตองการใชงาน ระบบ ไมเหมอนกน ดงนน แตละคน กจะใหขอมลไมเหมอนกน ดงนนเราตองรวาจะเกบขอมลนจากใคร ?
ทาไมตองรจก User หรอ ทาไมตองแบง User ออกเปนกลมๆ
ถาคณ จะพฒนาระบบ ของ รพ. และอยากรวา ยาแบงออกเปนกประเภท ไปถาม ผอ. ได หรอไมไปถาม แมบานไดหรอไม
แตละ User จะใหขอมลเฉพาะ ฟงกชนงานตวเอง
ประเภทของระบบสารสนเทศ (IS: Information System)
• MIS Managment information system
– ระบบลงทะเบยน
– ระบบจองหองพก
– ระบบบญช
– ...
• DSS decision support system
• ES expert system : ระบบผเชยวชาญ เปนการนาเอาระบบคอมพวเตอรไปชวย ใหการ
ทางานหรอตดสนใจ หรอ คดแทนผใชได เชน ระบบผเชยวชาญสาหรบการแพทย AI , NN
• EIS Executive Information System :: สาหรบผบรหารระดบสง
• TPS transaction processing system :: สาหรบผใชระดบลาง งานประจา...รทน
– งานฝาก-ถอนเงน โอนเงน ของธนาคาร
– เพมถอน รายวชา ...
โรงพยาบาล
• System Owner :: ......ผอานวยการโรงพยาบาล..• End User : …….พยาบาล.• Power User : ……..IT Support หมอ• Administrator : …..IT Support• Executive User : …..ผบรหาร / ผอ. /กรรมการ• External User : ……ผปวย / บคคลภายนอก ? / ญาต
ผปวย / แขกผปวย /
โรงภาพยนตร
• System Owner :: ......เจาของโรงภาพยนตร ?• End User : …….พนกงานโรงภาพยนตร ? / พนง. ขายตว
/ พนง. ขายปอบคอน • Power User : ……..IT Support หมอ• Administrator : …..IT Support• Executive User : …..ผบรหาร / ผอ. /กรรมการ• External User : ……ผปวย / บคคลภายนอก ? / ญาต
ผปวย / แขกผปวย /
กระบวนการวเคราะหความตองการ
• การบวนการวเคราะหความตองการมขนตอนดงตอไปน
1. เกบรวบรวมขอมลทเปนขอเทจจรงตางๆ (Data gathering)
2. วเคราะหเพอระบถงความตองการตางๆ (Requirement Identification)
3. คดเลอกสวนทเปนสาระสาคญและอยในขอบเขตการพฒนา (Requirement selection/ Problem Domain)
4. จดจาแนกและจดโครงสรางของความตองการ (Requirement classification and structuring)
5. จดลาดบความสาคญและตกลงเจรจา (Prioritization and negotiation)
6. ตรวจสอบความถกตอง (Requirement validation)
7. จดทา Requirement Specification
Pioritize ….. Use case artchitecture
ERD ระบบโรงพยาบาล
สนทรพยของโรงพยาบาล
?
หอง คนไขเขาพก
1. เกบรวบรวมขอมลทเปนขอเทจจรงตางๆ (Information Gathering)
• สงเกต (Observed)
• สมภาษณ (Interview)
• แบบสอบถาม(Questionnaire)
• ทบทวนเอกสาร (Document reviews)
• ลงมอทา (Workshop)
2. การระบความตองการ Requirement Identification
• แตละความตองการควรเปนอสระในตวเอง ไมผสมปะปนกบความตองการอนๆ• ความตองการจะตองสามารถทาการทดสอบได (Testable) ในภายหลง• ความตองการจะตองสามารถจดการดงตอไปนได
– จดกลมของความตองการ (Grouped) เชน จดตาม Viewpoint ของผใช เปนตน
– จดลาดบความสาคญ (Prioritized)– กาหนดในระดบของนามธรรมและรายละเอยด (Level of Abstraction) – กาหนดความสมพนธในเชงการขนอยตอกน (Dependency)
• ความตองการแตละความตองการควรมรหสทเปนเอกเทศใชในการอางองได (ID)• ควรแสดงดวยประโยคพรรณนา (Descriptive) ทเรยบงายตรงไปตรงมา ไมควร
อธบายดวยประโยคทซบซอนจนไมสามารถถอดใจความได
แตละความตองการควรเปนอสระในตวเอง ไมผสมปะปนกบความตองการอนๆ
• แยกแตละความความตองการออกจากกน• เวลาไดขอมลทงหมด จะอยรวมๆ กน เพราะฉะนนตองแยกแต
ละความตองการออกจากกน
ผปวย ตองทาบตรประจาตวกอน
ชาระเงน
บนทกประวตผปวย
จายยา
ผปวยเดนมาท รพ. แลว จนท. จะเปนคนแจง/ถาม บตรสมาชก ทาบตรเขาคว รอหมอ ตรวจวนจฉย ใหพยาบาลจายยาสง บนทก
ประวตการรกษาจายเงน กลบบาน
ต.ย.
ผปวยเดนมาท รพ. แลว จนท. จะเปนคนแจง/ถาม บตรสมาชก ทาบตรเขาคว
รอหมอ ตรวจวนจฉย ใหพยาบาลจายยาสง บนทกประวตการรกษา
จายเงน กลบบาน
ใคร..............................................................
เขยนเปนความตองการ..............................................................
3. คดเลอกสวนทเปนสาระสาคญและอยในขอบเขตการพฒนา (Requirement selection/ Problem Domain)
• สาระ• ไรสาระ / ไมจาเปน / ไมสาคญ
– กลบบาน
ผปวย ตองทาบตรประจาตวกอน
ชาระเงน
บนทกประวตผปวย
จายยา
ผปวยเดนมาทหอง แลวทาบตร
เขาคว
รอหมอ ตรวจวนจฉยจายยา บนทก
ประวตการรกษา
จายเงน กลบบาน
การเขาคว จาเปนตองมหรอไม?ขนอยกบวาโปรแกรมทเราจะพฒนา รวม การทาบตร ควหรอไม ?
4. จดจาแนกและจดโครงสรางของความตองการ (Requirement classification and structuring)
บ.
ผงงานโครงสราง Structure Chart / Organization Chart
ประเภทของความตองการ (Requirement)
• ความตองการเชงฟงกชน (Functional requirements) คอการระบถงบรการหลกทระบบสามารถทาได (Statements of Services) เพอใหการประยกตใชสามารถเปนไปตามวตถประสงค– เชน ระบบสามารถบนทกการสงซอสนคาของลกคาได– ระบบสามารถออกรายงานสรปยอดขายประจาเดอนได
• ความตองการไมเปนเชงฟงกชน (Non-functional requirements) คอเงอนไข (constraint) ทไดกาหนดไวตอการพฒนาและการนาไปใชของระบบ – เชน ระบบจะตองใชงานบนระบบปฏบตการ Linux– ความเรวในการตอบสนอง (response time) ไมควรเกน 3 วนาท– สามารถทางานรวมกบระบบเกาได เปนตน
ความตองการทเปนเชงฟงกชน functional requirements
• เปนความตองการทเกยวกบระบบนนๆ โดยตรง
ผปวย ตองทาบตรประจาตวกอน
ชาระเงน
บนทกประวตผปวย
จายยา
ผปวยเดนมาทหอง แลวทา
บตร เขาคว
รอหมอ ตรวจวนจฉยจายยา
บนทกประวตการรกษา
จายเงน กลบบาน
Req. 1) ระบบนจะตองสามารถบนทกขอมลผปวยไดทาอยางไร >
เปนฟงกชน Function
ระบบบรหารงานคลนกผปวย จะตอง
• ตรวจโรคได• วนจฉยได• รกษาได• ทาบตรสมาชกได• เกบประวตการรกษาได• ทาจายยาได• จายเงนได• ทาการออกใบเสรจได• ....อนๆ
อยในระบบน และเปนหนาททซอฟตแวรหรอโปรแกรมจะตองทาได เรยกวาเปน Functional requirements
ต.ย.
Req. 1) ระบบนจะตองสามารถบนทกขอมลผปวยไดทาอยางไร >
1.1 ตองเกบ ชอ นามสกล ทอย เบอรโทร เลขบตรประชาชน อเมล ........1.2 เบอรโทร ตองเกบ ตวอกษร กรณ กด ตอได 025210141#48071.3….เลขบตรประชาชน ตองเกบ 13 หลก หามเวนวาง..
…..…..
…..
ขอมลดานบนน ไดมาจากใคร ?แอดมน เปนคนบนทกประวต ผปวยใชหรอไม ?
การชาระเงน
Req. 2) ระบบจะตองสามารถชาระ คารกษาพยาบาล ได โดย มขอกาหนดดงน / มรายละเอยดดงน2.1 ระบบสามารถจาย/ชาระไดทง เงนสด และเครดต
ตอนท จะตรวจรบ ซอฟตแวร นหรอไม
ถา ไมสามารถจายเปนดวย บตรเครดต ได
หนาจอชาระเงน
ประวตการรกษา
ขอมลผปวย
ประวตการรกษา
การจาแนกประเภทของ Non-functional requirements
• Product requirements– ใชงานไดอยางสะดวก (Usability requirements)– มประสทธภาพด (Efficiency requirements): Performance, Speed– มความมนคงสง (Reliability requirements)– สามารถใชงานในสภาพแวดลอมทตางกนได (Portability requirements)
• Organizational requirements– สามารถสงมอบไดในเวลาทกาหนด (Delivery requirements)– ตองสรางดวยวธการและเทคโนโลยทกาหนด (Implementation requirements)– ตองพฒนาโดยยดตามมาตรฐานของการพฒนาทกาหนด (Standard
requirements) เชน ใหกระบวนการพฒนามมาตรฐานตาม ISO เปนตน• External requirements
– จะตองรองรบการเชอมตอจากภายนอกได (Interoperability requirements)– จะตองไมผดศลธรรม (Ethical requirements)– จะตองไมผดกฎหมาย (Legislative (Law) requirements)
ระดบของความตองการ
• ความตองการของผใช (User requirements)– ถอยแถลงทเปนภาษาธรรมชาต (Natural language) ตลอดจนแผนภาพ
ตางๆ ทแสดงใหทราบถงความสามารถในการทางานของระบบและเงอนไขในการทางานของระบบ
– ความตองการของผใชจะตองเขยนใหผใชเขาใจไดโดยงายเปนหลก• ความตองการของระบบ (System requirements)
– คอการระบถงสงทระบบควรจะม เพอใหสามารถทางานไดตรงตามความตองการของผใช
– ทาหลงจากไดขอกาหนดความตองการของผใชมาแลว– มกจะเขยนดวยแบบจาลอง (Models) เพอแสดงองคประกอบของระบบใน
แงมมตางๆ– ใชเปนขอกาหนดในการออกแบบตอไป
ตวอยางขอกาหนดความตองการ
• ReqID: 1– ระบบสามารถเกบขอมลของลกคาได
• ขอกาหนดความตองการ (Requirement specification)1. ขอมลลกคาจะตองเกบในฐานขอมล2. ระบบจะไมยอมใหเกบขอมลลกคา ถาขาดขอมลตอไปน เลขทบตรประจาตว
ชอ นามสกล อเมล3. ระบบจะตองตรวจสอบรปแบบของ เลขทบตรประจาตว กอนจดเกบ4. ระบบจะตองตรวจสอบรปแบบของอเมลกอนจดเกบ5. ขอมลของลกคาจะตองถกจดเกบใหเปนความลบและปลอดภย6. จะตองสามารถเรยกดไดในภายหลงวา พนกงานคนใดเปนผบนทกหรอแกไข
ขอมลลกคาครงลาสด7. Etc.
• ถาออกแบบฐานขอมลแลวปอนขอมล หรอ บนทกขอมล
รหส ชอ-นามสกล อเมล เพศ เบอรโทร29101110125
Not Null
ขอเสยของการเขยนความตองการดวยภาษาธรรมชาต
• สอความหมายกากวมไมชด (Lack of clarity)• มความสบสน (Confusion)• ผสมปนเป (amalgamation)
c
#include stdio.hstatic void main() {
}
แนวทางการเขยนความตองการดวยภาษาธรรมชาต
• สรางรปแบบมาตรฐานในการเขยน (standard format)• ใชภาษาทตรงไปตรงมาอยางมเหตมผล และไมมความขดแยงกน• เนนคาทเปนสวนสาคญของความตองการนนๆ• เลยงการใชศพททางเทคนคมากจนเกนไป (ศพททางคอมพวเตอร)
วธการอธบายความตองการแบบอน (นอกเหนอจากภาษาธรรมชาต)
• ภาษาทเปนโครงสราง (Structured Language)• แบบจาลองสญลกษณภาพ (Graphical model)• ขอกาหนดทางคณตศาสตร (Formal/Mathematical
specification)
½*ฐ*ส
การตรวจสอบความถกตองของความตองการ
• การตรวจสอบความถกตองของความตองการ (Requirement validation) คอการตรวจวาความตองการทไดมานน ถกตองและตรงกบความตองการของผใชอยางแทจรงหรอไม
• หลกในการพจารณา– Validity ความตองการนนตรงกบทผใชตองการจรงหรอไม สามารถ
แกปญหาใหผใชไดจรงหรอไม– Consistency มความขดแยงกนระหวางความตองการหรอไม– Completeness เปนความตองการทครบถวนของผใชทกคนหรอไม– Realism สามารถสรางไดจรงตามความตองการหรอไม– Verifiability สามารถตรวจสอบไดหลงจากพฒนาเสรจแลวหรอไม
เทคนคในการหาความตองการ
• Joint Application Design (JAD)• Prototyping
Joint Application Design (JAD)
• คอเทคนคการกาหนดความตองการของระบบโดยเนนการรวบรวมบคคลทเกยวของกบระบบ (stakeholders) มากาหนดความตองการรวมกน– User , Manager, Sponsor, System Analysis– เปาหมาย คอ หาความตองการไปพรอมๆ กน จากแตละ
viewpoints• การดาเนนการเปนไปในลกษณะการประชม (Meeting/Brain
Storming)• จนสดทายไดขอสรปรวมกนเปน ขอกาหนดความตองการ ซงแสดง
คณลกษณะของระบบทตองการ
JAD Technique
JAD Technique
ถาองคกรเลก ไมเกน 10 จะโอเคถาขนาดกลาง 10 -100 พอได
ถาใหญ เกน ไมเหมาะสม แตอาจจะคดเลอกตวแทนได
Prototyping
• ใชในกรณทผใชยงไมทราบความตองการของตนเองอยางชดเจน• สรางตนแบบของระบบอยางรวดเรวจากความตองการทมอยเบองตน• ใหผใชประเมนและเสนอแนะเพอทาการปรบปรงจนกวาผใชยอมรบ• นาตนแบบทเปนทยอมรบของผใชมาพฒนาตอใหสมบรณจนสามารถใช
งานไดจรง
Prototype3
Prototype2
Prototyping
Initial Requirement Specification
Prototype1 User
Accepted Prototype
validation
CertainRequirement Specification
Development
Actual System
Prototype Construction
โดย อาจารย ดร. นฐพงศ สงเนยมhttp://[email protected]
สาขาวชา วทยาการคอมพวเตอรคณะวทยาศาสตรและเทคโนโลย มหาวทยาลยราชภฏพระนคร
Last Update : 05/01/2561
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 51
Inception Elaboration Construction Transition
time
Unified process แบงการพฒนาออกเปน 4 เฟส (phases) แบงโครงการออกเปน 4 ระยะ
ทารายละเอยด (Elaboration) – วางแผนโครงการ จดทารายละเอยดความตองการ จดสรางสถาปตยกรรมระบบ
จดสราง (Construction) – สรางและทดสอบโปรแกรม
ถายโอน (Transition) – ตดตงถายโอนระบบใหกบผใช
51
Requirement Analysis
Use case จะเรมทาในเฟส น
Requirement specifications
การเขยนโครงการ (Proposal)
• ชอโครงการ
• ความเปนมาและความสาคญของปญหา
• วตถประสงคของโครงการ
• ขอบเขต
• แผนการดาเนนงาน Gantt Chart
• ประโยชนทคาดวาจะไดรบ
• อภธานศพทเฉพาะ
The Iterative Approach
OOAD : Object-Oriented Analysis and Design 53
Disciplinesgroup activities
logically
In an iteration,you walk through
all disciplines
53
ระบบบรหารโรงแรม 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
อ.ดร. นฐพงศ สงเนยม 66
ขอกาหนดของความตองการ(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
Requirements
1.
ออกแบบ Use case
2.
ทาไมตอง 1-2 เดอน หรอ ทาไม 3-4 หรอเทาไร ?
อาจจะใชเวลา 1-2 เดอนอาจจะใชเวลา 1-2 เดอน
3. System Analysis and Use Case
• Use Case Model– แบบจาลองความตองการของระบบ ท นาเสนอ functional
requirement ของระบบโดยรวม จากมมมองของผใช ภายนอก หรอ ระบบภายนอก
– ระบพฤตกรรม หรอหนาทการทางานของระบบ (เนน “what”) ทระบบตองม
– ใชในการทดสอบ และตรวจสอบ โครงสราง และหนาทการทางานของระบบ
– ใน UML สามารถระบเปน• Use Case Description (Text) หรอ • Use Case Diagram(Diagram)
บทท 5
ระบบโรงแรม ทาอะไรบาง
•Functional requirements ?•Non-Functional requirements ?
Requirement
• Req08 : คนหาขอมลหองพก{ จากความตองการของ พนกงาน }
– ระบบจะตองสามารถคนหาวาหองพกใด วาง/ไมวาง– ระบบสามารถตรวจสอบไดวาหองใด มลกคาคนใดเขาพก– ระบบสามารถตรวจสอบไดวา หองพกนน ครบกาหนด Check
out วนไหน/เมอไหร– ระบบสามารถตรวจสอบได วา ลกคา ใชบรการ Minibar
หรอไม– ตรวจสอบวามแมบานทาความสะอาดแลวหรอไม
Req01 , Req08 , Req15 , Req20 , Req09 , Req07, Req02
การพฒนาระบบจองหองพกโรงแรม ม Requirement ?
• Req01 : คนหาขอมลหองพก
• Req02 : สมครสมาชกได
• Req03 : จองหองพก
• Req04 : ชาระเงน
• Req05 : คนเงน
• ReqN : คนหองพก
Functional requirement
วาง และ พรอมเขาพก
ไมวาง และ มคนอย
วาง แต ไมพรอมเขาพก / ยงไมทาความสะอาด
จงวเคราะหระบบโรงแรม แลว เขยน
• Functional requirements ?• Non-Functional requirements ?
อยางละ 10 รายการ
ต.ย. Functional Requirements
• Req01 : การจองหองพก• { จากความตองการของ ลกคา }
– ในการจองหองพก จะมเงอนไขดงน• ระบบจะตองตรวจสอบขอมลการสมาชกได • ระบบจะตองทาการบนทกวาขอมลผจอง ไดแก รหส ชอ-นามสกล
เบอรโทร ทอย• ระบบจะตองสามารถตรวจสอบไดวา มหองวาหรอไม {uses Req08}• จะสามารถบนทกขอมลการจองหองพกได {uses Req09} โดยเกบ
วนท เวลา จานวนหอง จานวนผเขาพก วนทเชคอน วนท เชคเอาท• ระบบสามารถ ตรวจสอบไดภายหลงวา พนกงานคนใดเปนผรบการ
จอง• ถาเปนสมาชก จะมสวนลด 10 % {extend Req09}
จอง
ตรวจสอบหองพก
โปรแกรมยอย
• Sub(vb)/Procedure(pascal)• Function/
• Function/Method• คนคา
• ไมคนคา
ต.ย. Functional Requirements• Req01 : สมครสมาชก• { จากความตองการของ ลกคา }
– ในการ สมครสมาชกจะมเงอนไขดงน• ระบบจะตองตรวจสอบขอมลการสมาชกได • ระบบจะตองทาการบนทกวาขอมลผจอง ไดแก รหส ชอ-
นามสกล เบอรโทร ทอย• ระบบจะตองสามารถตรวจสอบไดวา มหองวาหรอไม {uses
Req08}• จะสามารถบนทกขอมลการจองหองพกได โดยเกบ วนท เวลา
จานวนหอง จานวนผเขาพก วนทเชคอน วนท เชคเอาท• ระบบสามารถ ตรวจสอบไดภายหลงวา พนกงานคนใดเปนผรบ
การจอง• ถาเปนสมาชก จะมสวนลด 10 %
ผใชระบบสารสนเทศ:แหลงของความตองการ
• เจาของระบบ (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 – ฟงกชน/ความสามารถ/หนาทของระบบ– 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
scenario
Use case
สมหญงเพมรายวชา OOP
การสมครสมาชก นาย นฐพงศ สมครบตรเครดต
class Instances/objects
จองหองพก
ตรวจสอบหองวาง
นายแดงจองหอง 142นาย ก จองหองพก เลขท 321...
scenariousecase
สมศรตรวจสอบหอง 142
อะไรคอ Transaction ?
• ราน เซเวน– ขายสนคา– ซอสนคา– เพมขอมลสนคา– เปลยนราคาสนคา– คนหารายการสนคา
• โรงภาพยนตร• โรงแรม
Transaction หลายๆ transaction รวมเปน use case อาจกลาวได วา use case กคอ
requirement นนเอง
ระบบ รานเซเวน
• Use case ซอสนคา• Scenario : สมศร ซอแปรงสฟน 2 อน• Scenario : นายก. ซอขนมปง 5 ชน
ใชตอนทดสอบโปรแกรม
ซอสนคา
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
Actor หมายถง someone หรอ some thing ทมการปฏสมพนธ โตตอบกบระบบสงใดกตามทมความตองการในการแลกเปลยน information กบระบบ หรอ สงใดกตามทอยภายนอกระบบ และมการใชงาน Use Case ของระบบกาหนดบทบาทหนาทของผใชระบบกาหนดการเชอมโยงกบระบบอนๆ ภายนอก
ATM
chkpassword
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 ในระบบ
Customerwithdrawal cash
System• System
– อาจหมายถง Software system, business, hardware,..– วตถประสงคใน use-case modeling เพอระบขอบเขต
ของระบบทกาลงพฒนา (system boundary)• ใชสญลกษณ
System
System & Use cases
• A system there are several use cases.
usecase3 usecase5
usecase2Usecase 1
usecaseN
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 passwor
d
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
Verifywithdraw
al
<<include>>
ATM/CDM
ตอนทถอน มการตรวจสอบยอดเงนคงเหลอ /หมายถงธนาคารตองเชคกอน
A Use Case Diagram
<<include>>
Customer
Validate Account
<<include>>
BankTeller
Deposit
BalanceChecking
Transfer
Withdraw
Verifywithdraw
al
<<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 ได
126
ตวอยาง scenario
Scenario ท 1• นายสมชายสอดบตร ATM ของธ.กรงเทพ สาขาหาดใหญ แต
บตรเสย บตรจงถก reject ออกมา
127
ตวอยาง scenario
Scenario ท 2• นางสมใจสอดบตร ATM ของธ.ทหารไทย สาขาบางเขน บตร
สามารถใชการได แตเงนในบญชไมพอจาย จงไมสามารถนาเงนไปใชได
128
ตวอยาง scenario
Scenario ท 3• นายสมบตสอดบตร ATM ของ ธ.ทหารไทย สาขาบางเขน บตร
สามารถใชการได และมเงนในบญชเพยงพอ เขาตองการถอน100 บาท และในบญชมเงนจานวน 250 บาท ดงนนนายสมบตจงสามารถนาเงนออกจากเครอง ATM ไปใชได
129
ต.ย. Use case diagram ทม uses
• จงสราง use case diagram เพออธบายการตรวจสอบ user ทเขามาในระบบคอมพวเตอรขององคกรตาง ๆ ตองมการตรวจสอบรหสผานรวมอยดวย โดย actor ของระบบนคอผจดการระบบ
130
ข นตอนท 1 :หา use case และ actor ของระบบ
• use case ของระบบคอ– การตรวจสอบ user (Validate user)– การตรวจสอบรหสผาน (Check password)
• actor ของระบบคอ– ผจดการระบบ (System Administrator)
131
ข นตอนท 2 : เขยน scenario ของระบบ
• scenario ท 1 : user ปอน password ทถกตอง– การตรวจสอบ password ใน use case ชอ check
password ตรวจสอบไดถกตอง ทาใหกจกรรมใน validate user ดาเนนตอไปได
132
ข นตอนท 2 : เขยน scenario ของระบบ
• scenario ท 2 : user ปอน password ทไมถกตอง– ทาให use case ชอ check password ถกเรยกใชอก
หลายครงจนกวาจะถก หรอจนกวาจะครบ 3 ครง จงตด user คนนนออกจากระบบ
133
ข นตอนท 3 : เขยน use case diagram
User Authorization
Validate Users Check Password
SystemAdministrator
<<uses>>
134
ตย. Use case diagram ทม extends
• จงสราง use case diagram ทแสดงการรบโทรศพท ซงขณะทรบโทรศพทปกต หากมสายเรยกซอนเขามา อาจทาใหตองมการรบสายเรยกซอนกอน ซงทาใหการรบสายโทรศพทตามปกตตองชะงกชวคราว
135
ข นตอนท 1 : หา use case และ actor ของระบบ
• use case ของระบบคอ– การรบโทรศพท– การรบสายเรยกซอน
• actor ของระบบคอ– ผรบโทรศพท
136
ขนตอนท 2 : เขยน scenario ของระบบ
• scenario ท 1 : เกดสายเรยกซอน– เมอเกดสายเรยกซอน ทาให use case การรบโทรศพท เกด
การชะงกงน ซงผรบอาจหยดการสนทนาชวขณะ– หรอผรบเปลยนไปรบสายทเรยกซอนแทน
• scenario ท 2 : ไมเกดสายเรยกซอน
137
ข นตอนท 3 : เขยน use case diagram
การรบโทรศพท
รบโทรศพท รบสายเรยกซอน
ผรบโทรศพท
<<extends>>
138
ตวอยาง การเขยน use case diagram
• จงสราง use case diagram เพออธบายการลงทะเบยนของนกเรยน ซงเกดจากผลของการวเคราะหความตองการเบองตน สามารถเขยนเปนรายการไดดงน
139
ความตองการ (Requirement)
• ในแตละภาคการศกษาจะมการลงทะเบยนของนกศกษา โดยนกศกษาทลงทะเบยนในแตละภาคการศกษาจะม 2 ประเภทคอ– นกศกษาปจจบน– นกศกษาใหม
140
ความตองการ...
• การลงทะเบยนในแตละครงจะมการเกบหลกฐานและคาเลาเรยน • ซงการลงทะเบยนเรยนจะเสรจสนไดกตอเมอหลกฐานทไดรบมา
ครบถวนถกตอง• และในขณะเดยวกนเงนคาเลาเรยนทเรยกเกบไดกตองมจานวน
ครบถวนดวย
141
ความตองการ...
• เจาหนาทของสถาบนการศกษาจะเปนผจดการในเรองของการจดเกบหลกฐานและคาเลาเรยนทงหมด
• และผจายเงนตองเปนนกเรยนเทานน
142
ความตองการ...
• สาหรบนกศกษาบางคนทไดรบสทธพเศษเชน– ไดรบทนเรยนฟร– เปนนกกฬาของสถาบน– หรอเปนผทาชอเสยงใหสถาบนจะมสทธไดรบยกเวนคาเลาเรยนในบางภาคการศกษา
143
หา use case ของระบบ
• use case ของระบบคอ– การลงทะเบยนนกศกษา– การเกบหลกฐาน– การชาระคาเลาเรยน
144
หา use case อนทเก ยวของ
• หา use case อนทเก ยวของคอ– การลงทะเบยนนกศกษา
• การลงทะเบยนนกศกษาใหม• การลงทะเบยนนกศกษาปจจบน
– การเกบหลกฐาน• หลกฐานไมพรอม
145
หา use case อนทเก ยวของ
• หา use case อนทเก ยวของคอ– การชาระคาเลาเรยน
• มเงนไมพอชาระคาเลาเรยน• ไดรบการยกเวนคาเลาเรยน
146
หา actor ของระบบ
• Actor ของระบบคอ– เจาหนาท– นกศกษา
147
เขยน Use Case Diagram
ลงทะเบยนนกศกษาใหม
ลงทะเบยนนกศกษาปจจบน
ชาระเงนคาเลาเรยน
เกบหลกฐาน
หลกฐานไมพรอม
มเงนไมพอชาระคาเลาเรยน
ไดรบการยกเวนคาเลาเรยน
เจาหนาท
นกศกษา
<<uses>>
การลงทะเบยนเรยนของนกศกษา 148
การเขยน 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 ของการจองหองพก
โรงแรม
สง สป. หนา
การวเคราะหความตองการเชงวตถโดยใช Use Case diagram
Requirement Analysis
การวเคราะหความตองการ
ความสาคญของการวเคราะหความตองการ
• สาเหตของการยกเลกพฒนาซอฟตแวร– ความตองการไมสมบรณ– ไมมผใชระบบรวมพฒนา– ขาดทรพยากร– ความคาดหวงในระบบเปนไปไมได – ไมมการสนบสนนจากผบรหาร– มการปรบความตองการขณะพฒนา– ขาดการวางแผน– ไมมความตองการระบบทกาลงพฒนา
คาใชจายในการแกไขขอผดพลาด
วตถประสงคหลกของการวเคราะหความตองการ
• กาหนดขอตกลงกบผวาจาง ผใชระบบ วาระบบทจะพฒนาควรมความสามารถทาอะไรไดบาง
• ใหผพฒนาระบบ (System Developers) เขาใจขดความสามารถของระบบชดเจนยงขน
• ปรบขอบเขตของระบบ• จดการ กาหนดแผนการดานเทคนคตางๆ สาหรบการทางานตามรอบ
การพฒนา• กาหนดสวนเชอมตอของผใชงานระบบงานกบระบบ
วธการหาความตองการทแทจรง
• การสมภาษณ (Interviewing)• การระดมสมอง (Brainstorming)• การใชแบบสอบถาม (Questionnaire)• การสงเกต (Observation)
ระดบของความตองการ
เอกสารการวเคราะหความตองการ
1. บทนา1.1 วตถประสงค1.2 ขอบเขต1.3 คาจากดความ คาเหมอน คายอ1.4 เอกสารอางอง
2. การบรหารความตองการ2.1 การบรหารโครงการ หนาทภายในทมงาน2.2 โครงสรางพนฐานของระบบ และเครองมอทใช
เอกสารการวเคราะหความตองการ3. รายการบรหารความตองการ
3.1 ระบความตองการ ขนตอนการปฏบตงาน3.2 ระบกฎขอบงคบของความตองการ(ถาม)3.3 กาหนดคณสมบต (Attributes) ในขอ 3.13.4 รปแบบเนอหาของรายงานและวธการวด3.5 การบรหารความเปลยนแปลง
ขนตอนการขอเปลยนแปลงระบบโครงสรางของคณะกรรมการพจารณาจดตรวจสอบในแตละเฟส
3.6 ขนตอนการทางานและกจกรรม4. แผนการดาเนนงาน5. เครองมอในการพฒนาระบบทใชและการฝกอบรม
การพฒนาระบบเลกๆ อาจเขยนเอกสารดงน
• ขอบเขตของระบบทจะพฒนา(Problem Domain)• Glossary• เอกสารรายละเอยดของระบบ(Requirements
Specification)• Use-Case Diagram
Use Case Model
• Introduction• Survey Description• Use Case Packages• Use Case• Actors• Relationships• Diagrams• Use Case View
ขอบเขตของระบบทจะพฒนา(Problem Domain)
• เอกสารทระบถงระบบงานทกาลงจะพฒนา โดยบอกถงปญหาของงานททาอย ขอจากดของระบบทกาลงดาเนนงาน หรอความตองการของระบบทคาดหวง ตลอดจนเทคนคการทางาน ระเบยบ กฎเกณฑทจาเปน
Glossary
• เปนเอกสารทรวบรวมคานยามของระบบทใชกน หลกการเลอกคากคอ จะตองเลอกคาทเปนทเขาใจกนภายในหนวยงาน หรอเปนคาศพททมความหมายเฉพาะผดแปลกไปจากความเขาใจโดยทวไป หรอเปนคาศพททนยามใชเฉพาะระบบ เปนตน
เอกสารรายละเอยดของระบบ(Requirements Specification)
• บทนา – กลาวถงภาพกวางๆ ของระบบ• ภาพรวมทงหมด – อธบายขอบเขตของระบบทจะตองตดตอกบสวน
อนๆ ของระบบทงภายในและภายนอกรวมถงการทางานรวมกบระบบเดม
• ความตองการโดยละเอยด – อธบายความตองการโดยละเอยดเพอใหนกออกแบบสามารถออกแบบได และผทดสอบระบบทดสอบได
• เอกสารสนบสนนอนๆ เชน ดชน ภาคผนวก
หนาทเกยวของ
• เอกสารประกอบการพฒนาระบบเปนหนาทของใคร
หนาทของนกวเคราะหระบบ
Concepts in Use Case Model
กาหนดชอ Actor
Scenario
• สถานการณ หรอตวอยางเรองราวการใชงานระบบ• Scenario จดเปน instance ของ use case
withdrawal cash
a user withdrawals$200
ความสมพนธใน Use Case Diagram
• ความสมพนธเชงโครงสราง(Association)– แทนดวย
• ความสมพนธแบบสบทอด(Generalization)– แทนดวย
• ความสมพนธแบบพงพา(Dependency)– แทนดวย
ความสมพนธระหวาง Actor
Actor Generalization
ความสมพนธระหวาง Actor กบ Use Case
Example: Use Case Diagram
Actor กบขอบเขตของระบบ
ตวอยาง Use Case
Use Case
• ชอยสเคส• การทางานโดยยอ• ลาดบเหตการณทเกดขน• ความสมพนธ• เงอนไขกอนยสเคสทางาน• เงอนไขหลงยสเคสทางาน
Generalization ของ Use Case Diagram
ความสมพนธ <<include>> และ <<extend>>
สรปความสมพนธของ Use Case Diagram
ขอควรระวงในการใช Use Case Diagram
• Use Case ใชเปนเครองมอสอสารกบผใช ดงนนตองใหงายทสดเทาทจะทาได
• ไมควรใช <<include>>,<<extend>> และ inheritance โดยทไมจาเปน
• จานวน Use Case ไมควรเกน 20 Use Case โดยนบจาก Use Case ทไมมความสมพนธ
GUI ด vs GUI ไมด
ขนตอนการสรางอนเตอรเฟสพนฐาน
• คนหาการใชระบบ• โมเดลยสเซอรอนเตอรเฟสหลก• โมเดลยสเซอรอนเตอรเฟสยอย• สารวจความงายของการใชอนเตอรเฟส• สารวจความสมพนธของสวนตางๆ
Interface Flow Diagram vs GUI Design
ตวอยาง Interface Flow Diagram
ตวอยาง Interface Flow Diagram
ตวอยาง Interface Flow Diagram
ตวอยาง Interface Flow Diagram
แบบฝกหด
• ใหศกษารายละเอยดของระบบงานใดๆ ทพบเหน เชน การลงทะเบยน การตดเกรด แลวใหนามาวเคราะหความตองการพรอมทงเขยน Use Case Model
ขอขอบคณ แหลงขอมล
วฒพงษ เรอนทองภาควชา วทยาการคอมพวเตอรและเทคโนโลยสารสนเทศ คณะวทยาศาสตร มหาวทยาลยนเรศวร
Top Related