โดย อ ดร นัฐพงศ ส์งเนียม่...

โดย อ.ดร. นฐพงศ สงเนยมhttp://www.siam2dev.netDr.nattapong_s@hotmail.com

สาขาวชา วทยาการคอมพวเตอรคณะวทยาศาสตรและเทคโนโลย มหาวทยาลยราชภฏพระนคร

Last Update : 05/01/2561

Lec06_การวเคราะหความตองการ (Requirement Analysis) ดวย Use case

http://www.siam2dev.com [ dr. nattapong songneam]

ดร. นฐพงศ สงเนยม

• http://www.siam2dev.com• E-mail : dr.nattapong_s@hotmail.com• E-mail1 : siam2dev@hotmail.com• E-mail1 : xnattapong@hotmail.com• Facebook : siam2dev@hotmail.com

http://www.siam2dev.com [ dr. nattapong songneam]

Lec06_การวเคราะหความตองการ (Requirement Analysis)

อ. นฐพงศ สงเนยมhttp://www.siam2dev.comsiam2dev@hotmail.comxnattapong@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://www.siam2dev.comDr.nattapong_s@hotmail.com

สาขาวชา วทยาการคอมพวเตอรคณะวทยาศาสตรและเทคโนโลย มหาวทยาลยราชภฏพระนคร

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

ขอขอบคณ แหลงขอมล

วฒพงษ เรอนทองภาควชา วทยาการคอมพวเตอรและเทคโนโลยสารสนเทศ คณะวทยาศาสตร มหาวทยาลยนเรศวร