use case modelsiam2dev.net/e_learning/ooad/lec07_ooad_use_case_model...the iterative approach ooad :...

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

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

Last Update : 30/01/2561

Lec07 : Use case model

แหลงขอมลเพมเตม : : http://www.lumpaya.com/sdlc01.htmhttp://www.siam2dev.com [ dr.

nattapong songneam]

Lecture Outline

1. กระบวนการพฒนาซอฟตแวร (Software Development Process )

ทบทวน

2. ข นตอนการวเคราะหระบบ (System Analysis)

3. การวเคราะหระบบดวย ยสเคส (System Analysis and Use Case )

4. การสราง ยสเคสไดอะแกรม (Use Case Diagram )

5. ตวอยางของ ยเคส (Example Of Use case)

UP :: โครงสรางกรรมวธ - Lifecycle Phases

เตรยมงาน (Inception) – นยามขอบเขตของโครงการ , ขอบเขตของระบบทจะพฒนา

OOAD : Object-Oriented Analysis and Design 3

Inception Elaboration Construction Transition

time

Unified process แบงการพฒนาออกเปน 4 เฟส (phases) แบงโครงการออกเปน 4 ระยะ

ทารายละเอยด (Elaboration) – วางแผนโครงการ จดทารายละเอยดความตองการ จดสรางสถาปตยกรรมระบบ

จดสราง (Construction) – สรางและทดสอบโปรแกรม

ถายโอน (Transition) – ตดตงถายโอนระบบใหกบผใช

3

Requirement Analysis

Use case จะเรมทาในเฟส น

Requirement specifications

การเขยนโครงการ (Proposal)

• ชอโครงการ

• ความเปนมาและความสาคญของปญหา

• วตถประสงคของโครงการ

• ขอบเขต

• แผนการดาเนนงาน Gantt Chart

• ประโยชนทคาดวาจะไดรบ

• อภธานศพทเฉพาะ

The Iterative Approach

OOAD : Object-Oriented Analysis and Design 5

Disciplinesgroup activities

logically

In an iteration,you walk through

all disciplines

5

ระบบบรหารโรงแรม ABC

Business Model : โมเดลทางธรกจBusiness Rule : กฏเกณฑ/เงอนไขทางธรกจ

โปรแกรม บรหารงานโรงแรม (GENiUS iHotel) เปน โปรแกรมโรงแรม ทออกแบบสาหรบชวยบรหารงาน โรงแรม รสอรท อพารทเมนต แบบรายวน และรายเดอน โดยสวนประกอบหลกๆ ของโปรแกรมจะประกอบไปดวย ขอมลหองพก (Room Information) ระบบการจองหองพก (Reservation) ระบบการเชคอน (Guest Check In) ระบบการเชคเอาท (Guest Check Out) ระบบขอมลผเขาพก (Guest History) ระบบการขายสนคาในหองพก (Mini Bar) ระบบการซอสนคา ระบบสตอกสนคา (Inventory) ระบบแมบาน (House Keeping) ระบบการบารงรกษาหองพก (Room Maintainance) ระบบการปดบญชรอบวน (Night auditor) และ ระบบงานเอกสาร ตางๆ อาทเชน Guest Folio ใบเสรจรบเงน ใบกากบภาษ เปนตน รวมไปทงระบบการรายงานรายวน รายงานแบบสรป และ รายงานเชงวเคราะห เชงลก ใหผบรหาร อาทเชน รายงานประวตผเขาพก รายงานการรบเงนของ Cashier รายงานการเขาพก รายงานสรปยอดหองพกคงเหลอ (Room Forecasting) รายงานสนคาคงเหลอสตอกกลาง หรอ มนบาร รายงานการใชหองพก (Room Occupancy) รายงาน ยอดการจองหองพกลวงหนา (Forecast Report) และ รายงานอนๆ และเครองมอชวยเหลอในการทางาน (Front Utility) อกมากมาย

คณสมบตของ โปรแกรมโรงแรม

ระบบโรงแรม คออะไร ?

Business model•ชอ•ทตง ทอย•ใครเปนเจาของ•ดาเนนกจการมาแลวกป•จานวนหองพก•ประเภท•พนกงาน•แผนก ฝาย•รายละเอยดตางเกยวกบ การทาธรกจ โรงแรม•ฯลฯ

Business model

Business Rule

Business Rule เงอนไข ของธรกจ

•การเขาพก ทาอยางไร•การเปนสมาชก / ทาอยางไร•การจอง•การจายเงน•การรบพนกงาน•การตอนรบลกคา

การจองเพอจะ ตรวจสอบสถานะของหอง?

ตวอยาง Business Rule

ตวอยาง Business Ruleบรษท เอม บ เค จากด(มหาชน) เปนผประกอบธรกจระดบแนวหนาของประเทศไทย โดยมงเนนธรกจทสนบสนนดานการทองเทยว และการพฒนาอสงหารมทรพย เปนหลก

บรษท เอม บ เค จากด(มหาชน) เปนผประกอบธรกจระดบแนวหนาของประเทศไทย โดยมงเนนธรกจทสนบสนนดานการทองเทยว และการพฒนาอสงหารมทรพย เปนหลก โดย MBK ไดจดทะเบยนแปรสภาพบรษท เปนบรษทมหาชนจากดชอวา “บรษท เอม บ เค พรอพเพอรตส แอนด ดเวลลอปเมนท จากด (มหาชน)”เมอวนท 8 เมษายน 2537 และไดรบอนญาตให เปนบรษทจดทะเบยนในตลาดหลกทรพยแหงประเทศไทย อกครงเมอวนท 5 เมษายน 2539 ใชชอยอหลกทรพยวา “MBK - PD” โดยเรมมการซอขาย หนสามญ ของบรษทฯ ในตลาดหลกทรพยแหงประเทศไทยเมอวนท 24 เมษายน 2539ตอมาเมอวนท 20 พฤศจกายน 2545 บรษทฯ ไดเปลยนชอบรษทจาก “บรษท เอม บ เค พรอพเพอรตส แอนด ดเวลลอปเมนท จากด (มหาชน)” เปน “บรษท เอม บ เค ดเวลลอปเมนท จากด (มหาชน)” และเมอวนท 10 พฤศจกายน 2546 บรษทฯ ไดเปลยนชอบรษทฯ อกครงจาก “บรษท เอม บ เค ดเวลลอปเมนท จากด (มหาชน)” เปน “บรษท เอม บ เค จากด (มหาชน) ” “MBK” และเปลยนชอยอหลกทรพยจาก “MBK - PD” เปน “MBK” จนถงปจจบนMBK ประกอบดวย 8 กลมธรกจ คอ1. ธรกจศนยการคา 2. ธรกจโรงแรมและการทองเทยว 3.ธรกจอสงหารมทรพย 4.ธรกจกอลฟ 5. ธรกจขาว 6. ธรกจการเงน 7.ธรกจอนๆ 8. ธรกจสนบสนน ดงน

บรษท เอม บ เคMBK ประกอบดวย 8 กลมธรกจ คอ

ตวอยาง Business Rule

ตวอยาง Business Model

UML : Unified Modeling Language

Use CaseDiagramsUse Case

DiagramsUse CaseDiagrams

ScenarioDiagramsCollaboration

Diagrams

StateDiagramsState

DiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagramsState

DiagramsObjectDiagrams

ScenarioDiagramsScenario

DiagramsStatechartDiagrams

Use CaseDiagramsUse Case

DiagramsSequenceDiagrams

StateDiagramsState

DiagramsClassDiagrams

ActivityDiagrams

Models

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

1. Software Development Process

1. Requirement Specification : define problem domain

2. Analysis : what problem to be solved? (อะไรคอปญหาทตองแก)

3. Design : how to solve the problem? (แกอยางไร)

4. Implementation : how to implement the solution?

5. Testing : how to ensure that the solution can solve the problem?

1. ทดสอบในเรองความเรว ประสทธภาพ ความปลอดภย ความมนคง เสถยร

2. ทดสอบความเขากนได หรอ การประกอบของสวนยอยๆ

6. Maintenance : how to adjust the solution to accomodate change?

1. ในรอบระยะเวลาหนงอาจจะตองมการปรบเปลยน

7. Retirement : when does the system to be retired?

บทท 5 Requirement Specification

Use case

StopA

A

หา Business Rule/Model

Start

Planning

Requirement Specification

สราง Use Case Diagram

สราง Class diagram

ออกแบบ UI and Prototype

Implementation /coding

Testing

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

ขอกาหนดของความตองการ(Requirement Specifications)

2. System Analysis• กระบวนการวเคราะหระบบ (system analysis phase)

– มงเนน “what” ทระบบจะตองม และตองทาใหกบผใช โดยยงไมเนน “how” วาจะทาอยางไร (ในขนตอนนเปนการ User Requirement)

• กระบวนการวเคราะหความตองการของผใชระบบ (Requirementanalysis phase)– ใชในการสรางแบบจาลองหนาทการทางานของระบบ

ซอฟตแวร จากมมมองของผใชภายนอก หรอ ระบบภายนอก– จะไดแบบจาลองของความตองการของผใชระบบ

(Requirement Model) เปน Output

จาก UP ในเฟส ท 2 สงจะตองได หรอเสรจ กคอ Use case 80%

What >> Analysis1. ระบบตองขายสนคาได2. เกบขอมลพนกงานได3. ....

How >> Design / Implement– ออกแบบ ขอ 1. ใน Traditional Method กคอการ ออกแบบ

อลกอรทม/Pseudo Code, และเขยนผงงาน / ผงโครงสราง– แบบเชงวตถ กสรางเปน use case diagram และ class diagram

Requirement Specification

ระบบขายสนคา

ซอ

ลกคา

สนคา/ ใบเสรจ

ขอมลสนคา

โปรแกรม ตองทางาน

อยางไร

Cjava

การซอ จะตองเขยนโปรแกรมอยางไร

การเกบขอมลลกคา มความตองการ อะไร

1. ขอกาหนดของความตองน คอ จะทาอยางไร กบขอมลน มความตองการอะไรบาง

2. เชน ในการจดเกบหรอบนทกขอมลลกคา มเงอนไข หรอขอกาหนดตางๆ ดงน

1. การเกบขอมล จะตองเกบใหครบได รหส เลขทบตรประชาชน ชอ ทอย เบอรโทร เพศ สถานะ อเมล ขอมลเหลานจะตองเกบลงในฐานขอมล

2. จะขาดสงใดสงหนงไมได ระบบจะตองไมยอมใหบนทก

3. เบอรโทร จะเกบ 10 หลก หามเกน หามขาด

4. เบอรโทรจะตองไมเปนตวอกษร

5. เลขทบตรประชาชน จะตองเปน 13 หลก และเปนตวเลขเทานน

6. สถานะ จะตองประกอบไปดวย โสด สมรส อยาราง

7. อเมล จะตองถกตองตามหลก โดยม @

122233333333333

เลขทบตรประชาชน

ความตองการนมาจากผใช end user/ system ownerเจาของความตองการ โดยแทจรงไมใชลกคา

Requirements

1.

ออกแบบ Use case

2.

ทาไมตอง 1-2 เดอน หรอ ทาไม 3-4 หรอเทาไร ?

3. System Analysis and Use Case

• Use Case Model– แบบจาลองความตองการของระบบ ท นาเสนอ functional

requirement ของระบบโดยรวม จากมมมองของผใช ภายนอก หรอ ระบบภายนอก

– ระบพฤตกรรม หรอหนาทการทางานของระบบ (เนน “what”) ทระบบตองม

– ใชในการทดสอบ และตรวจสอบ โครงสราง และหนาทการทางานของระบบ

– ใน UML สามารถระบเปน / เราสามารถเขยน use case ได 2 แบบ คอ

• Use Case Description (Text) หรอ • Use Case Diagram(Diagram)

บทท 5

ความแตกตางระหวาง what และ how

• What คอระบบนน จะตองมมความตองการหรอฟงกชนอะไรบาง

• How แตละความตองการหรอฟงกชน จะทาอยางไร

ระบบโรงแรม ทาอะไรบาง

•Functional requirements ?•Non-Functional requirements ?

ความตองการของระบบโรงพยาบาล

จงบอกความตองการตอไปน ขอใดเปนฟงกชน และขอใดไมเปนฟงกชน

1. ระบบจะเกบขอมลลกคาได .....................เปน..............................

2. ระบบสามารถเรยกใชงานไดทนท ...................เปน............................

3. ระบบสามารถรองรบการเชอมตอกบ Linux ………………เปน……………4. ระบบสามารถใชงานผาน wifi ได .........................ไมเปน...............................5. ระบบจะตองรายงานยอดผ ปวย แตละวนได ......................เปน.....................

6. ระบบจะตองบนการจายยาได ...................................เปน..........................

7. ระบบจะตองตรวจสอบขอมลผ ปวยแตละโรคได ...............เปน..........................

8. ระบบจะตองรนผาน iOS ได ..................ไมเปน.....................................9. ระบบจะตองใชงานงาย ..............................ไมเปน................................

10. ระบบจะตองรนไดทก browser ………………ไมเปน…………………..

Requirement

• Req08 : คนหาขอมลหองพก{ จากความตองการของ พนกงาน }

– ระบบจะตองสามารถคนหาวาหองพกใด วาง/ไมวาง– ระบบสามารถตรวจสอบไดวาหองใด มลกคาคนใดเขาพก– ระบบสามารถตรวจสอบไดวา หองพกนน ครบกาหนด Check

out วนไหน/เมอไหร– ระบบสามารถตรวจสอบได วา ลกคา ใชบรการ Minibar

หรอไม– ตรวจสอบวามแมบานทาความสะอาดแลวหรอไม

Req01 , Req08 , Req15 , Req20 , Req09 , Req07, Req02

เปนฟงกชน หรอไมเปน

ลกคา

พนกงาน

คนหา

หองพก

ระบบเวบแอพพลเคชนจองหองพกออนไลน

ถาเปนออนไลน ลกคาสามารถเขาไปเซคหองพกไดวาวาง

หรอไมวาง

ลกคา

พนกงาน

คนหา

หองพก

ระบบการจองหองพกโรงแรมถาเปนระบบวนโดวแอพพลเคชน ลกคาจะไมสามารถเขาไปเซคหองพกไดวาวางหรอไม

วาง จะตอสอบถามผานพนกงาน

ตรวจสอบผ

เขาพก

<<include>>

Login

minibarจองหองพก

ลกคา

พนกงานคนหา

หองพก

ระบบการจองหองพกโรงแรมถาเปนระบบวนโดวแอพพลเคชน ลกคาจะไมสามารถเขาไปเซคหองพกไดวาวางหรอไม

วาง จะตอสอบถามผานพนกงาน

ตรวจสอบผ

เขาพก

Login

minibarจองหองพก

หองพกวาง

Validate Client

การพฒนาระบบจองหองพกโรงแรม ม Requirement ?

• Req01 : คนหาขอมลหองพก

• Req02 : สมครสมาชกได

• Req03 : จองหองพก

• Req04 : ชาระเงน

• Req05 : คนเงน

• ReqN : คนหองพก

Functional requirement

วาง และ พรอมเขาพก

ไมวาง และ มคนอย

วาง แต ไมพรอมเขาพก / ยงไมทาความสะอาด

จงวเคราะหระบบโรงแรม แลว เขยน

• Functional requirements ?• Non-Functional requirements ?

อยางละ 10

รายการ

ต.ย. Functional Requirements

• Req01 : การจองหองพก• { จากความตองการของ ลกคา }

– ในการจองหองพก จะมเงอนไขดงน• ระบบจะตองตรวจสอบขอมลการสมาชกได • ระบบจะตองทาการบนทกวาขอมลผจอง ไดแก รหส ชอ-นามสกล

เบอรโทร ทอย• ระบบจะตองสามารถตรวจสอบไดวา มหองวาหรอไม {uses Req08}• จะสามารถบนทกขอมลการจองหองพกได {uses Req09} โดยเกบ

วนท เวลา จานวนหอง จานวนผเขาพก วนทเชคอน วนท เชคเอาท• ระบบสามารถ ตรวจสอบไดภายหลงวา พนกงานคนใดเปนผรบการ

จอง• ถาเปนสมาชก จะมสวนลด 10 % {extend Req10}

จอง

ตรวจสอบหองพก

โปรแกรมยอย

• Sub(vb)/Procedure(pascal)• Function/

• Function/Method• คนคา

• ไมคนคา

ต.ย. Functional Requirements

• Req01 : สมครสมาชก• { จากความตองการของ ลกคา }

– ในการ สมครสมาชกจะมเงอนไขดงน• ระบบจะตองตรวจสอบขอมลการสมาชกได • ระบบจะตองทาการบนทกวาขอมลผจอง ไดแก รหส

เลขทบตรประชาชน ชอ-นามสกล เบอรโทร ทอย• ระบบตองตรวจสอบ ขอมลเลขทบตรประชาชน ทถกตอง

ได 13 หลก

ผใชระบบสารสนเทศ:แหลงของความตองการ

• เจาของระบบ (System owners/Sponsors ) – มสวนไดสวนไดเสยจากการลงทนสรางระบบสารสนเทศ

เจาของผบรหาร ผจดการ• ผใชภายใน (Internal users)

– End-users คอผใชทปอนขอมลเขาสระบบโดยตรง ไมจาเปนตองมทกษะหรอความรมาก เนนความถกตองและรวดเรวของการปอนขอมลเขาสระบบ

– Power-users คอผใชทมความรความชานาญเฉพาะดาน สามารถใชงานฟงกชนของระบบในสวนทมความซบซอนได

– Administrators คอผทดแลและควบคมใหระบบสามารถดาเนนการไดอยางราบรนตามวตถประสงคทตงไว

– Executive users คอผใชทตองการสารสนเทศมาเพอการตดสนใจและบรหารองคกร

• ผใชภายนอก (External users)– ผใชซ งเปนบคคลภายนอกองคกร แตสามารถเขาถงบรการของ

ระบบในองคกรได

จากทเคยสอนไปแลว บทท 5

Use Case Description Example

• Name: การสงรายการซอขายหลกทรพย (Place Order)– Main flow of events:

1. Trader ปอนชอ และรหสของ client2. System ตรวจสอบ (Validate) ชอ รหส และ credit ของ

client3. Trader ปอนรหสหลกทรพย จานวนหลกทรพย และราคา

หลกทรพย ท Client ตองการซอขาย4. System ตรวจสอบเงอนไขราคาของหลกทรพย

{ตรงกบเงอนไขของตลาดหรอไม เชน Margin ขนตาเทาไร}5. System สง order ใหกบตลาดหลกทรพย6. System เกบหมายเลข order ทไดรบจากตลาดหลกทรพย7. System แจงให Trader ทราบ

Trader

Place OrderStock

Exchange Market

Use case ไดมาจาก Requirement Specification

4. Use Case Diagram• นาเสนอฟงกชนหรอ Use Case และการปฏสมพนธโตตอบกน

ระหวางระบบ และ ผใชภายนอก (someone / something อาจเปนคน หรอระบบกได)

• สวนประกอบของ use case diagram ดวย– Use Case – ฟงกชน/ความสามารถ/หนาทของระบบ– Actor – ผทมบทบาท/ ผกระทา/ผใชงาน Use Case นนๆ– Relationship - เสนแสดงความสมพนธระหวาง Use Case กบ

Actor– System / System Boundary - ระบบทกาลงพฒนา

Use Case Modeling : Core Elements

Construct Description Syntax

use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

actor A coherent set of roles that users of use cases play when interacting with these use cases.

system boundary

Represents the boundary between the physical system and the actors who interact with the physical system.

UseCaseName

ActorName

Construct Description Syntax

association The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.

generalization A taxonomic relationship between a more general use case and a more specific use case.

extend A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case.

Use Case Modeling : Core Relationships

<<extend>>

Construct Description Syntax

Include / uses An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case.

Use Case Modeling : Core Relationships (cont’d)

<<include>>

Use Cases v.s. Scenario• Use Case

– ความสามารถ หรอ หนาทการทางานของระบบ– แตละ Use Case แทนชดของ transactions ทระบบ

ทางานโตตอบกบ ผใชงาน หรอระบบอนๆ ภายนอก• Scenario

– สถานการณ หรอตวอยางเรองราวการใชงานระบบ– Scenario จดเปน instance ของ use case– เชน

withdrawal cash

a user withdrawals$200

รายการ

การถอนเงนสด

อาจจะเปนของใครกได

เปนการระบรายละเอยด

หรอ ยกตวอยางมา 1

รายการ

ซอขาว

นาย ก. แลกคปอง 100 บาทแลกคปอง

สวมล ซอขาวมนไก 30 บาท

Scenario is a capture of use case

ถอนรายวชา

เพมรายวชา

•สมชายถอนรายวชา OOAD•สมศร ถอนวชาแคลคลส•สมควร ถอนวชา OOP

scenarioUse case

สมหญงเพมรายวชา OOP

การสมครสมาชก นาย นฐพงศ สมครบตรเครดตนาย สมศร สมครสมาชก MK

class Instances/objects

จองหองพก

ตรวจสอบหองวาง

นายแดงจองหอง 142นาย ก จองหองพก เลขท 321...

scenariousecase

สมศรตรวจสอบหอง 142

อะไรคอ Transaction ?

• ราน เซเวน– ขายสนคา– ซอสนคา– เพมขอมลสนคา– เปลยนราคาสนคา– คนหารายการสนคา

• โรงภาพยนตร• โรงแรม

Transaction หลายๆ transaction รวมเปน use case อาจกลาวได วา use case กคอ

requirement นนเอง

ระบบ รานเซเวน

• Use case ซอสนคา• Scenario : สมศร ซอแปรงสฟน 2 อน• Scenario : นายก. ซอขนมปง 5 ชน

ใชตอนทดสอบโปรแกรม

ซอสนคา

ใชตอน นา use case ไปทดสอบระบบ

Transaction

แปรงสฟน 2 ดาม

ขนมเลย 1 หอ

ขนมปง 1 หอ

นม 1 โหล

• Use case : คานวณ พท. สเหลยม• Scenario :: สเหลยมท ก 2 ยาว 4

ใชในตอนออกแบบ วาโปรแกรมตองทาอะไรไดบาง

ใชในตอนทดสอบระบบ วาเปนไปตาม use case หรอไม

Actors• Actor หมายถง someone หรอ some thing ทมการ

ปฏสมพนธ โตตอบกบระบบ– สงใดกตามทมความตองการในการแลกเปลยน

information กบระบบ หรอ สงใดกตามทอยภายนอกระบบ และมการใชงาน Use Case ของระบบ

– กาหนดบทบาทหนาทของผใชระบบ (actor ใชสาหรบกาหนดบทบาท ของผใชระบบ วาทาอะไรกบระบบ หรอใช อะไร/ตดตอจากระบบ)

– กาหนดการเชอมโยงกบระบบอนๆ ภายนอก• ตวอยางของ Actors

– Customer -- maintain their account (ลกคาตองการปรบปรงรายการบญชของตวเอง)

– Cashier -- verify withdrawal amountCustomer Cashier

เวลา คณถอนเงน แคชเชยร สามารถตรวจสอบยอดการถอนได

ในการเกบขอมลลกคา• Req05 : จดการขอมลลกคา

– เพมลกคาใหม/สมครสมาชก– แกไขขอมลลกคา {customer/staff/admin}– จะตองใหลกคาสามารถด ขอมลตนเองได– จะตองใหลกคา แกไข ขอมลลกคา บางอยางได Customer -- maintain their

account (ลกคาตองการปรบปรงรายการบญชของตวเอง)

Customer

Maintain their account

Add new customer Staff

คลนก ลกคา ตองการแกไขทอย ผานเคาเตอร / พยาบาล

Delete account

Admin

Actor หมายถง someone หรอ some thing ทมการปฏสมพนธ โตตอบกบระบบสงใดกตามทมความตองการในการแลกเปลยน information กบระบบ หรอ สงใดกตามทอยภายนอกระบบ และมการใชงาน Use Case ของระบบกาหนดบทบาทหนาทของผใชระบบกาหนดการเชอมโยงกบระบบอนๆ ภายนอก

ATMchkpassword

Actor

ATM

customer

Validate account

<<

include>>

Actors• Actors สามารถอธบายโดยใช Generalization/Specialization

Relationship

• อาจพจารณา Actors เปนคลาส ใน UML เนองจากม relationships เชนเดยวกบทคลาสม

Generalization/specialization relationship

Customer

ATM Customer Cashier Customerจงอธบายรปน ?

แบงโดยใชเกณฑ ลกษณะของการใชงาน

Actors• Actors สามารถอธบายโดยใช Generalization/Specialization

Relationship

• อาจพจารณา Actors เปนคลาส ใน UML เนองจากม relationships เชนเดยวกบทคลาสม

Generalization/specialization relationship

Customer

Personal Customer Coporate Customer

จงอธบายรปน ?

แบงโดยใชเกณฑ ลกษณะลกษณะของลกคา

Actors• เชอมตอกบ use cases โดยใชเสนแสดงความเกยวของ ปฏสมพนธ

(association)• association = ความสมพนธทมการตดตอสอสารกน (ทงการรบ และสง

messages ใหแกกนและกน)

• ใช generalization relationships อธบายความสมพนธ ระหวาง actors ไมจาเปนตองอธบายรายละเอยดของ Association เนองจากไมมการ Implement สวนของ Actor ในระบบ

Customer withdrawal cash

System• System

– อาจหมายถง Software system, business, hardware,..– วตถประสงคใน use-case modeling เพอระบขอบเขต

ของระบบทกาลงพฒนา (system boundary)• ใชสญลกษณ

System System

System & Use cases

• A system there are several use cases.

usecase3

usecase5

usecase2

Usecase1 usecase

N

usecase4

• ในระบบหนงๆ จะม ยสเคสไดอะแกรมไดหลาย ยสเคสไดอะแกรม• ในแตละยสเคสไดอะแกรม จะมหลายๆ ยสเคส

usecase1

usecase2

usecase3

usecase4

usecase

usecase

Usecase 1

usecase

ระบบใหญ

Use case 1

จดการลกคา

• เกบประวต • แกไข• ลบ• คน

Relationships between Use Case

• Extends : เปน generalization relationships ในกรณท Use Case หนงๆ ขยาย (extends) Use Case อน โดยการเพมการกระทา (actions)

• Includes/Uses : เปน generalization relationship ในกรณทUse Case หนงๆ เรยกใช (uses) Use Case อน ทพจารณาให เปนสวนหนงของ Use Case นนๆ

Generalization Relationship• Child Use case รบถายทอด

คณสมบตมาจาก Parent Use Case

• Child สามารถเปลยนแปลงพฤตกรรมทรบจาก Parent หรอเพมเตมพฤตกรรม

• Child อาจนาไปแทนท ในทๆ Parent ปรากฏ

Validate client

Check password

Retinal scan

จงอธบายรปน ?

ตวลกมเหมอนพอแม แตสามารถดดแปแลงเพมเตมความสามารถของพอแมได

Parent use case

child use case

“Include” relationship• มกใชในการหลกเลยงการอธบายการไหลของเหตการณ (flow of events) เดม ซา

กนหลายๆ ครง โดยรวบรวมพฤตกรรมรวม ใน Use Case

• หลกเลยงการ copy & paste ของ Use Case Descriptions

• เปรยบเสมอนการเรยกโปรแกรมยอย/ฟงกชน จากโปรแกรมหลก

Validate client

Place order

<<include>>

Track order

<<include>>

ทกครงทจะซอ/

ขาย ตอง login

โปรแกรมหลก

โปรแกรมยอย

“Include” relationship• มกใชในการหลกเลยงการอธบายการไหลของเหตการณ (flow of events) เดม ซา

กนหลายๆ ครง โดยรวบรวมพฤตกรรมรวม ใน Use Case

• หลกเลยงการ copy & paste ของ Use Case Descriptions

• เปรยบเสมอนการเรยกโปรแกรมยอย/ฟงกชน จากโปรแกรมหลก

Validate client

Place order

<<include>>

Track order

<<include>>

ทกครงทจะซอ/

ขาย ตอง login

โปรแกรมหลก

โปรแกรมยอย

Trader

Read mail

Login

<<include>>

Post FB

Login

<<include>>

ใน UML ไมไดกลาวถงมาตรฐาน ส แปลวา ไมกาหนดวาสใดหมายถงอะไร แตสญลกษณ ถกกาหนดไว

“Include” Example• Name : การตรวจสอบรายการซอขายหลกทรพย

(Track Order) – Main flow:

1. ใชหมายเลข order ในการตรวจสอบ ทไดรบจากตลาดหลกทรพยObtain and verify order number

2. Include สวนของ “Validate client”3. ในแตละสวนของ Order …

Track Order ValidateClient

<<include>>

Use case description

Use case diagram

“Extend” relationship

• ใชสรางแบบจาลองบางสวนของ Use Case ท user อาจมองเปน optional– Optional หมายถง นอกเหนอ จาก

เหตการณปกต หรอมากกวาปกต หรอพเศษ• ต.ย. สมครเรยน เอกสารขาดไมครบ• การลงทะเบยน เงนไมพอ

• ใช สรางแบบจาลอง conditional subflows

• ใชในการแทรก subflows ในจดทระบโดยพจารณา ปฏสมพนธระหวาง Actors

<<extend>>(set priority)

Place orderExtension points:

Set priority

Place rush order

conditional

“Extend” Example• Name : ¡ÒÃÊ‹§ÃÒ¡Òë×éÍ¢ÒÂËÅÑ¡·ÃѾÂ� (Place Order)

– Main flow of events:1. …2. Trader »‡Í¹à§×è͹䢢ͧËÅÑ¡·ÃѾÂ� ·Õè Client µŒÍ§¡ÒÃ

«×éÍ¢ÒÂ3. ¡íÒ˹´ÅíÒ Ñº¤ÇÒÁÊíÒ¤ÑÞ â´Â (set priority)4. System Ê‹§ order ãËŒ¡ÑºµÅÒ´ËÅÑ¡·ÃѾÂ�5. ...

Place Order Place RushOrder

<<extend>>

[ ]optional

Relationships between Use Case

WithdrawalCash

ValidateAccount

<<include>>

Ship PartialOrder

Ship Order

<<extend>>

Comparing extends/ uses• extend

– ใชแยกความแตกตางของ Use Case – actors ทเกยวของมกเปนคนกระทา Use case และUse

Case ทextend ทงหมด– actor มกเชอมตอกบ “base” Use Case

• include/use– ใช extract พฤตกรรมรวม– มกไมม actor เกยวของโดยตรงกบ Use Case ทม

พฤตกรรมรวม– actors ทแตกตางกน for “caller” use cases possible

A Use Case Diagram

Establish Credit

<<include>>

Trader

Validate Client

<<include>>

PlaceOrder

<<extend>>FinancialOfficer

TrackOrder

RetinalScan

CheckPassword

Place RushOrder

StockExchange

<<include>>

someone

someone

something

ให Problem Domain มา แลว functional / non-functional แลวสรางเปน usecase

A Use Case Diagram

<<include>>

Customer

Validate Account

<<include>>

BankTeller

Deposit

BalanceChecking

Transfer

Withdraw

Verifywithdrawal

<<include>>

ATM/CDM

ตอนทถอน มการตรวจสอบยอดเงนคงเหลอ /หมายถงธนาคารตองเชคกอน

<<include>>

<<include>>

Verify Transfer

ตรวจสอบเลข บช.ตรวจสอบจานวนเงน

A Use Case Diagram

<<include>>

Customer

Validate Account

<<include>>

BankTeller

Deposit

BalanceChecking

Transfer

Withdraw

Verifywithdrawal

<<include>>

<<include>>

ATM/CDM

ตอนทถอน มการตรวจสอบยอดเงนคงเหลอ /หมายถงธนาคารตองเชคกอน

Validate Account

Function Balance_checking() If balance >= amt then

balance = balance -amtElse

msgbox “เงนไมพอ”End if

End Funciton

WidtdrawBalance_Checking ()

..……

Implement with Visual Basic

Balance Checking

If balance >= amt thenbalance = balance - amt

Elsemsgbox “เงนไมพอ”

End if

WidtdrawBalanceChecking()

..……

BalanceChecking()

When and how?• Requirements capture

– ใชในการกาหนด Reuqirement ของระบบ– สรางแบบจาลอง (Model) ของ user requirements

ดวย Use Case• Test Scenarios

– สรางแบบจาลอง (Model) ของสถานการณการทดสอบระบบ (test scenarios) ดวย Use Case

• Use Case: – ระบส งท Actor ตองการใหมในระบบ– ต งชอให Use Case– เขยนคาอธบายส นๆ– เพมรายละเอยดในภายหลง

เปนหนาทของ use case specified

เปนหนาทของ use case designer

Finding Actors• สามารถระบ actor ไดโดยตอบคาถามตอไปน

– ใครเปนคนใชงานหนาทการทางานหลกของระบบ (primary actors)?– ใครตองการการสนบสนนการทางานจากระบบ?– ใครตองการบารงรกษา และบรหารระบบ (secondary actors)?– Hardware devices ใดทตองการใหระบบจดการดแล?

• ถาระบบฮารดแวร เครองจกรใด ตองการการซอมบารง / เครองจกรไมใชคน– ระบบภายนอกระบบใดท ตองการใหระบบมปฏสมพนธดวย?

• ระบบจายคานาประปา -- ไมใชคน แตเปนระบบ• ระบบเกบภาษ/จายภาษ – สรรพากร ไมใชคน

– ใคร หรอ อะไรทตองการไดรบผลประโยชน จาก output ของระบบ? • หลงจาก use case ทางานแลว สงผลลพธให ใคร

• Tips– ไมควรพจารณาเฉพาะ users ทใชงานระบบโดยตรง แต พจารณา users

อนๆ ทตองการใชบรการจากระบบดวย

association

หา Actors

จายเงนเดอน

ระบบจายเงนเดอนของ ขาราชการ ในมหาวทยาลย

ขาราชการ พนกงงานฝายบคคล

พนกงงานฝายบคคล

Finding Use Cases• สาหรบแตละ actor ตอบคาถามตอไปน

– หนาทการทางานอะไรท actor ตองการจากระบบ?– ขอมลใดบางท actor ตองการสราง อาน ลบ เปลยนแปลง หรอ

เกบอยภายในระบบ?– เหตการณใดบางทระบบตองแจงให actor ทราบ? หรอ actor

ตองแจงใหระบบทราบ? – หนาทการทางานของระบบ ชวยทาใหงานประจาวนของ actor

งายขนหรอไม?• ถาไมพจารณา actors

– อะไรคอ input/output ของระบบ ? input/output เหลานนมาจากไหน หรอใครเปนคนนาไปใชงาน?

– ปญหาหลกของระบบทใชงานอย คออะไร?

หนาทการทางานอะไรท actor ตองการจากระบบ?

Student

คนหาเกรด

เปลยนชอ

ถอนวชา

การปรบปรง

ขอมลนกศกษา

Recipe (เทคนค)• ระบ actors ทมปฏสมพนธกบระบบ• พจารณาแนวทางของระบบ ในการปฏสมพนธกบ

actors• จาแนกพฤตกรรมของระบบใน การปฏสมพนธกบ

actors ใหเปน use cases โดยกาหนดความสมพนธระหวาง Use Case

ตวอยางการเขยน Use case

ตวอยาง use case

• ผใชงานสอดบตร ATM เขาสเครองรบบตร หากบตรใชงานไดจงเขาสหนาจอ Main Menu หากใชงานไมไดบตร ATM จะถกปลอยคน (Reject) ออกมา หากบตรใชได ผใชงานตองระบประเภทบญชและจานวนเงนทตองการถอน หากมเงนในบญชมากกวาหรอเทากบจานวนทระบ ผใชงานสามารถนาเงนออกจากเครอง ATM ได

85

ตวอยาง scenario

Scenario ท 1• นายสมชายสอดบตร ATM ของธ.กรงเทพ สาขาหาดใหญ แต

บตรเสย บตรจงถก reject ออกมา

86

ตวอยาง scenario

Scenario ท 2• นางสมใจสอดบตร ATM ของธ.ทหารไทย สาขาบางเขน บตร

สามารถใชการได แตเงนในบญชไมพอจาย จงไมสามารถนาเงนไปใชได

87

ตวอยาง scenario

Scenario ท 3• นายสมบตสอดบตร ATM ของ ธ.ทหารไทย สาขาบางเขน บตร

สามารถใชการได และมเงนในบญชเพยงพอ เขาตองการถอน100 บาท และในบญชมเงนจานวน 250 บาท ดงนนนายสมบตจงสามารถนาเงนออกจากเครอง ATM ไปใชได

88

ต.ย. Use case diagram ทม uses

• จงสราง use case diagram เพออธบายการตรวจสอบ user ทเขามาในระบบคอมพวเตอรขององคกรตาง ๆ ตองมการตรวจสอบรหสผานรวมอยดวย โดย actor ของระบบนคอผจดการระบบ

89

ข นตอนท 1 :หา use case และ actor ของระบบ

• use case ของระบบคอ– การตรวจสอบ user (Validate user)– การตรวจสอบรหสผาน (Check password)

• actor ของระบบคอ– ผจดการระบบ (System Administrator)

90

ข นตอนท 2 : เขยน scenario ของระบบ

• scenario ท 1 : user ปอน password ทถกตอง– การตรวจสอบ password ใน use case ชอ check

password ตรวจสอบไดถกตอง ทาใหกจกรรมใน validate user ดาเนนตอไปได

91

ข นตอนท 2 : เขยน scenario ของระบบ

• scenario ท 2 : user ปอน password ทไมถกตอง– ทาให use case ชอ check password ถกเรยกใชอก

หลายครงจนกวาจะถก หรอจนกวาจะครบ 3 ครง จงตด user คนนนออกจากระบบ

92

ข นตอนท 3 : เขยน use case diagram

User Authorization

Validate Users Check Password

SystemAdministrator

<<uses>>

93

ตย. Use case diagram ทม extends

• จงสราง use case diagram ทแสดงการรบโทรศพท ซงขณะทรบโทรศพทปกต หากมสายเรยกซอนเขามา อาจทาใหตองมการรบสายเรยกซอนกอน ซงทาใหการรบสายโทรศพทตามปกตตองชะงกชวคราว

94

ข นตอนท 1 : หา use case และ actor ของระบบ

• use case ของระบบคอ– การรบโทรศพท– การรบสายเรยกซอน

• actor ของระบบคอ– ผรบโทรศพท

95

ขนตอนท 2 : เขยน scenario ของระบบ

• scenario ท 1 : เกดสายเรยกซอน– เมอเกดสายเรยกซอน ทาให use case การรบโทรศพท เกด

การชะงกงน ซงผรบอาจหยดการสนทนาชวขณะ– หรอผรบเปลยนไปรบสายทเรยกซอนแทน

• scenario ท 2 : ไมเกดสายเรยกซอน

96

ข นตอนท 3 : เขยน use case diagram

การรบโทรศพท

รบโทรศพท รบสายเรยกซอน

ผรบโทรศพท

<<extends>>

97

ตวอยาง การเขยน use case diagram

• จงสราง use case diagram เพออธบายการลงทะเบยนของนกเรยน ซงเกดจากผลของการวเคราะหความตองการเบองตน สามารถเขยนเปนรายการไดดงน

98

ความตองการ (Requirement)

• ในแตละภาคการศกษาจะมการลงทะเบยนของนกศกษา โดยนกศกษาทลงทะเบยนในแตละภาคการศกษาจะม 2 ประเภทคอ– นกศกษาปจจบน– นกศกษาใหม

99

ความตองการ...

• การลงทะเบยนในแตละครงจะมการเกบหลกฐานและคาเลาเรยน • ซงการลงทะเบยนเรยนจะเสรจสนไดกตอเมอหลกฐานทไดรบมา

ครบถวนถกตอง• และในขณะเดยวกนเงนคาเลาเรยนทเรยกเกบไดกตองมจานวน

ครบถวนดวย

100

ความตองการ...

• เจาหนาทของสถาบนการศกษาจะเปนผจดการในเรองของการจดเกบหลกฐานและคาเลาเรยนทงหมด

• และผจายเงนตองเปนนกเรยนเทานน

101

ความตองการ...

• สาหรบนกศกษาบางคนทไดรบสทธพเศษเชน– ไดรบทนเรยนฟร– เปนนกกฬาของสถาบน– หรอเปนผทาชอเสยงใหสถาบนจะมสทธไดรบยกเวนคาเลาเรยนในบางภาคการศกษา

102

หา use case ของระบบ

• use case ของระบบคอ– การลงทะเบยนนกศกษา– การเกบหลกฐาน– การชาระคาเลาเรยน

103

หา use case อนทเก ยวของ

• หา use case อนทเก ยวของคอ– การลงทะเบยนนกศกษา

• การลงทะเบยนนกศกษาใหม• การลงทะเบยนนกศกษาปจจบน

– การเกบหลกฐาน• หลกฐานไมพรอม

104

หา use case อนทเก ยวของ

• หา use case อนทเก ยวของคอ– การชาระคาเลาเรยน

• มเงนไมพอชาระคาเลาเรยน• ไดรบการยกเวนคาเลาเรยน

105

หา actor ของระบบ

• Actor ของระบบคอ– เจาหนาท– นกศกษา

106

เขยน Use Case Diagram

ลงทะเบยนนกศกษาใหม

ลงทะเบยนนกศกษาปจจบน

ชาระเงนคาเลาเรยน

เกบหลกฐาน

หลกฐานไมพรอม

มเงนไมพอชาระคาเลาเรยน

ไดรบการยกเวนคาเลาเรยน

เจาหนาท

นกศกษา

<<uses>>

การลงทะเบยนเรยนของนกศกษา 107

การเขยน Use caseองคประกอบมดงน

- ชอของ Use Case

- ภาพรวมของการทางาน (Overview)

- Actor หลก (Primary Actor)

- Actor รอง (Secondary Actor)

- จดเรมตน (Starting Point)

- จดสนสด (End point)

- การทางานของ Use Case (Flow of Events)

- การทางานของ Use Case เมอมปญหาเกดขน (Alternative flowof Events)

- ผลของการทางานของ Use Case (Measurable Result)

Use Case : Create Order• ภาพรวมของการทางาน (Overview)

จดประสงคหลกของ Use Case น เพอทาการลงขอมลในใบสงซอสนคาจากลกคา

• Actor หลก (Primary Actor)ตวแทนฝายขายสนคา

• Actor รอง (Secondary Actor)ไมม

• จดเร มตน (Starting Point)Use Case ตวนเร มตนเมอ Actor ตวแทนฝายขายสนคาขอใหระบบ

ทาการลงขอมลการสงซอสนคา• จดสนสด (End point)

คาขอเพอทาการลงขอมลการสงซอสนคาเสรจสนสมบรณหรอไมกถกยกเลก

Use Case : Create Orderการทางานของ Use Case (Flow of Events)

จาก User Interface บนจอเพอทาการลงขอมลการสงซอ Actorจะตองทาการใสขอมลเกยวกบการสงซอ เปนตนวา วนทลกคาตองการใหสนคาสงมอบถงมอ (Required Date) ปรมาณทตองการส งซอ (Quantity) ตองการใหสงมอบสนคาโดยบรษทสงสนคาไหน (Ship Via) ตองการใหใหสงมอบสนคาทไหน (Ship Address) หลงจากนนแลว Actor สามารถเลอกทจะทาการบนทกขอมลลงไปไวในฐานขอมล หรอยกเลกการทางานทงหมด ถา Actor เลอกทาการบนทก ใบสงซอใบใหมกจะถกสรางขนมาในฐานขอมล

Use Case : Create Orderการทางานของ Use Case เมอมปญหาเกดขน

(Alternative Flow of Events)ถาไมมสนคาทตองการอยในคลงสนคา ระบบจะตองแจงให Actor ทราบพรอมกนนนกตองยกเลกการทางานทเหลอของUse Case น

ผลของการทางานของ Use Case (Measurable Result)จะมใบสงซอสนคาใหม 1 ใบขนมาในระบบ

Cash Register Example

Use Case: Buy items

Actors: Customer, Cashier

Type: Primary

Description: A Customer arrives at a checkout with items to purchase. The Cashier records the purchase itemsand collects payment. On completion, the Customer leaves with the items

Expanded Use Case Example

Use Case: Buy Items with Cash

Actors: Customer (initiator), Cashier

Purpose: Capture a sale and its cash payment

Overview: A Customer arrives at a checkout with items topurchase. The Cashier records the purchase items and collects a cash payment. Oncompletion, the Customer leaves with the items.

Type: primary and essential

Cross references: R1.1, R1.2, R1.7

Expanded Use Case (2)

1. This use case begins when a Customer arrives at the register with items to purchase.

2. The cashier records the identifier from each item. If more than one of the same item, the Cashier can enter the quantity as well.

4. Cashier indicates completion of item entry.

6. Cashier tells the Customer the total.

3. Determines the item price and adds the item information to the running sales transaction. The description and price of the item are presented.

5. Calculates and presents the sale total.

TYPICAL COURSE OF EVENTS

ACTOR ACTION SYSTEM RESPONSE

Expanded Use Case (3)

7. The Customer gives a cash payment -possibly greater than the sale total.

8. The Cashier records the cash received amount.

10. The Cashier deposits the cash received and extracts the balance owing. Cashier gives balance and receipt to Customer.

12. Customer leaves with items purchased.

ACTOR ACTION SYSTEM RESPONSE

9. Show the balance due

back to the Customer.

Generates a receipt.

11. Logs the completed

sale.

Expanded Use Case (4)

• Alternative Courses

• Line 2: Invalid identifier entered. Indicate error

• Line 7: Customer didn’t have enough cash. Cancel sales transaction

• If a Typical Course of Events has multiple equally likely courses of action

– indicate branches in Use case

– write a subsection for each branch indicating the typical course of events

– have alternatives for each subsection if necessary

Use case ของ ระบบรบ-สงเมล

http://i.stack.imgur.com/zAAcZ.jpg

student teacher

member

Borrow book

Return Book

LibrarianCheckingMember

Check period

borrowed

Calculation fine

ระบบการยมหนงสอในหองสมด(Borrow book from library)

<<include>> <<

extend>>

user customer CardAuthorization

CheckInventory Status

Object Actors Product

แบบฝกหด

• จงเขยน functional requirement ของการจองหองพกโรงแรม1. เขยน Requirement Specification2. หา Actor3. หา use case4. เขยน 5 Scenario5. แลวเขยน use case diagram ของการจองหองพก

โรงแรม