You are on page 1of 105

การวิเคราะห

(Analysis)
การวิเคราะหและออกแบบระบบเชิงวัตถุดวย
UML : Unified Modeling Language

จีรวัฒน ทะลาสี
สาขาวิชาสารสนเทศศาสตร คณะวิทยาการสารสนเทศ
มหาวิทยาลัยมหาสารคาม 1
แนวคิดเชิงวัตถ(Object
แนวคดเชงวตถุ (Object Oriented)
• แนวคิ
แนวคดเชงวตถุ (Object Oriented) หมายถง
ดเชิงวัตถ(Object หมายถึง การใช
การใช
Object เปนตัวหลักในการพิจารณาความเปนจริงตางๆที่เกิดขึ้นใน
โลก โดยมองทุ
โดยมองทกสิ
กสงในโลกเปนวตถุ
่งในโลกเปนวัตถทัท้งงหมด
หมด และมองว
และมองวากจกรรมท
ากิจกรรมที่
เกิดขึ้นในโลกนี้เกิดจากความสัมพันธและปฏิสัมพันธระหวางวัตถุ

2
ตารางเปรียบเทียบการวิเคราะหและออกแบบระบบวิธีเดิมกับวิธีเชิงวัตถ
ตารางเปรยบเทยบการวเคราะหและออกแบบระบบวธเดมกบวธเชงวตถุ
วิธีเดิม วิธีเชิงวัตถุ
เริ่มตนจากการวิเคราะหเอกสาร เริ่มตนการวิเคราะหจาก Objects ที่
ผลลัพธ และการทํางานของระบบงาน สามารถเห็นไดชัดเจน
เดิม
เดม
แตกการทํางานออกเปนหนวยยอยๆ แบงกลุมของ Object ตามคุณลักษณะ
องคประกอบตางๆของระบบ เชน
องคประกอบตางๆของระบบ เชน การ แตละ Object เปนอสระตอกน
แตละ เปนอิสระตอกัน การ
ประมวลผล การออกรายงาน การ เปลี่ยนแปลงจะไมกระทบกัน
คํานวณ จะเกี่ยวพันกัน การ
เปลีย่ นแปลงจะกระทบซึ่งกันและกัน
การปรับเปลี่ยนระบบตองแกไข การปรับเปลี่ยนระบบ ทําไดโดยการ
Source Code เปลี่ยน Attributes,
เปลยน Attributes Functions ของ
Object 3
Tools ที่สนับสนุนมีนอยลง Tools ที่สนับสนุนมีมากขึ้น
วัตถ (Objects)
วตถุ
• วัวตถุ
ตถ (Object) คอหนวยสนใจของระบบททาใหเกดเหตุ
คือหนวยสนใจของระบบที่ทําใหเกิดเหตการณ การณ วตถุ
วัตถ
เปนไดทั้งสิ่งที่สามารถจับตองได (เชน โตะ รถยนต คอมพิวเตอร คน)
และวัตถทีท่ไไมสามารถจบตองได
และวตถุ มสามารถจับตองได (เชน
(เชน บรษท
บริษัท ฝฝายตางๆ
ายตางๆ หลั
หลกสู
กสตร)
ตร)
• การสื่อสารระหวาง Object เรียกวา Message

4
คลาส (Class)
• Class คือกลุุมของ Object j ที่มีโครงสรางพื้นฐฐานพฤติ ฤ กรรมเดียวกัน
Object ที่มีคุณสมบัติเดียวกัน ก็จะรวมกลุมอยูใน Class เดียวกัน
• Class และ Object มีความคลายกันมากจนทําใหหลายคนสงสัยวาเปนสิ่ง
เดียี วกันหรืือไไม ในความเป
ใ ปนจริิง Class
Cl ถือื วา เปปน นามธรรม (Abstract)
(Ab t t)
ในขณะที่ Object นั้นเปนสิ่งที่มีตัวตน (Concrete) กลาวคือ Class
เปนเหมือนพิมพเขียวของ Object โดยท
เปนเหมอนพมพเขยวของ โดยที่ Class จะไมสามารถทางานได
จะไมสามารถทํางานได แต
แต
Object สามารถทํางานได
• การทํางานของ Object จะเปนไปตามคุณสมบัติที่กําหนดไวใน Class และ
Object ทุกตัวก็ตองอยูใน Class ดังนั้น Class และ Object จึงเปน
สิ่งคูกันเสมอ

ที่มา: การวิเคราะหและออกแบบระบบ, โอภาส เอี่มสิริวงศ 25485


คลาส (Class)
• Class นอกจากจะมชอ
นอกจากจะมีชื่อ Class กากบแลว
กํากับแลว Student

ยังมี คุณสมบัติ (Attributes) และ หนาที่ StudentID


FirstName
การทํางาน (Operations หรอ
การทางาน หรือ LastName
Methods) Address
Telephone
Name Birthdate
Faculty
Attributes GPA
Register()
Methods Drop()
Withdraw()
ตัวอยาง Class Student 6
การสืบทอดคณสมบั
การสบทอดคุ ณสมบตติ (Inheritance)
• การสืบทอดคุุณสมบัติ ((Inheritance)) คือ การที่ Subclass ไดรับการ
ถายทอดคุณสมบัติ (Attributes) มาจาก Superclass แลวผนวก
คุณสมบัติพิเศษเพิ่มเขาไป

Multiple Inheritance
• สัญญลักษณที่ใช คือ ลูกศรหัวรูปสามเหลี่ยมใส ชี้จาก Subclass ไปยัง
Superclass
7
การสืบทอดคณสมบั
การสบทอดคุ ณสมบตติ (Inheritance)
Transaction

TransactionNumber
EmployeeNumber
TransactionDate
TransactionTime
BarcodeNumber
Price
SalesTax

Sales Transaction Rental Transaction

----inherited---- ----inherited----
TransactionNumber TransactionNumber
EmployeeNumber EmployeeNumber
Without Inheritance TransactionDate TransactionDate
TransactionTime TransactionTime
BarcodeNumber BarcodeNumber
Price Price
SalesTax SalesTax
----local---- ----local----
QuantitySold MemberNumber

8
With Inheritance
การสืบทอดคณสมบั
การสบทอดคุ ณสมบตติ (Inheritance)
• หลั
หลกของการสบทอดคุ
กของการสืบทอดคณสมบั
ณสมบตจะทาใหความสมพนธระหวาง
ติจะทําใหความสัมพันธระหวาง
Object มีความชัดเจนยิ่งขึ้น กลาวคือถามีความสัมพันธที่ชัดเจนมาก
ขึ้นเทาใด จะสงผลใหการออกแบบระบบงานงายขน
ขนเทาใด จะสงผลใหการออกแบบระบบงานงายขึ้น
• ผูออกแบบระบบงานเชิงวัตถุสามารถออกแบบระบบงานขนาดใหญได
โดยการอาศัย Object ทมการนยามไวกอนหรอทมผู
โดยการอาศย ที่มีการนิยามไวกอนหรือที่มีผอื่นทาการ
นทําการ
ออกแบบไวกอนแลว ซึ่งเปนที่มาของการนํากลับมาใชใหม
(Reusability)

ที่มา: การวิเคราะหและออกแบบระบบ, โอภาส เอี่มสิริวงศ 25489


ขอดีของการสืบทอดคณสมบั
ขอดของการสบทอดคุ ณสมบตติ
• การสืบทอดคณสมบั
การสบทอดคุ ณสมบตมขอด
ติมีขอดี คืคออ
1. ทําใหมีโครงสรางที่เปนระบบ สามารถปรับเปลี่ยนไดงาย
2 ลดเวลาในการพฒนาระบบ
2. ลดเวลาในการพัฒนาระบบ
3. ลดคาใชจายในการพัฒนาระบบ

ที่มา: การวิเคราะหและออกแบบระบบ, โอภาส เอี่มสิริวงศ 2548


10
Polymorphism
• Polymorphism
y p คือ การที่ Object
j ที่ตางกันมีปฏฏิกิริยาตอบสนองตอ
Function/ Message หนึ่งๆในวิธีที่ตางกัน
• Class รููปสี่เหลี่ยม กับ Class รููปสามเหลี่ยม ไดรับการสืบทอดคุณ ุ สมบัติ
จาก Class รูปหลายเหลี่ยม โดยทั้งคูมี Function ที่ชื่อ draw()
เหมือนกัน แตเมื่อมีการเรียกใช function ดังกลาว Object ที่สรางจาก
Cl
Class รูปสี่ีเหลียี่ มจะมีกี ารวาดรูปสี่ีเหลียี่ ม ขณะทีี่ Object
Obj t ทีสี่ รา งจาก
Class รูปสามเหลี่ยมจะมีการวาดรูปสามเหลี่ยม

11
Polymorphism
• หลักการ Polymorphism y p
ชวยใหสามารถนํา code กลับมาใช
ใหม ได เนื่องจากสามารถกําหนด รูปหลายเหลี่ยม
ชุดคําํ สัั่งทัวั่ ไป และมอบหนา ทีี่ d ()
draw()
รายละเอียดของการนําไปใชแก
Object ทเกยวของจดการ
ที่เกี่ยวของจัดการ รูรปสี
ปสเหลยม
่เหลี่ยม รูรปสามเหลี
ปสามเหลยม่ยม
draw() draw()

12
Polymorphism

13
Encapsulation และ Information
Hiding
• การซอนรายละเอียดเปนพื้นฐานของการปกปดขอมููลภายในและวิธีการทํางานของ
Object
• ตามแนวคิดเชิงวัตถุ การจะลวงรูรายละเอียดขอมูลของ Object จะตองไดรับอนุญาต
จากเจาของ Object นนกอน
จากเจาของ นั้นกอน กล
กลาวคอการเขาถงขอมู
าวคือการเขาถึงขอมลนั
ลนน้น จะไมสามารถเขาถงได
จะไมสามารถเขาถึงได
โดยตรง แตจะตองมีการตอบรับจาก Method ใน Object ปลายทางนั้นวาจะยอม
ให Object ที่สง Message เขาถึงขอมูลของตนหรือไม
• Encapsulation หมายถึง ลักษณะการเขียนโปรแกรมที่จะมีการซอนขอมูลที่
ตองการควบคุมความถูกตองของขอมูลไว (Information Hiding) และบังคับ
ใ  Object อนเขาถงขอมู
ให ื่  ึ  ลทซอนไวผานทาง
ี่  ไ   Interface ทเตรยมไว
ี่ ี ไ  ทาให
ํใ 
สามารถควบคุมความถูกตองของขอมูลได

14
Encapsulation และ Information
Hiding
• กลไกการปกปองกนขอมู
กลไกการปกปองกันขอมลและวิ
ลและวธการทางานของ
ธีการทํางานของ Object สามารถเปน
สามารถเปน
– Public (+) ซึ่งสามารถเขาถึงไดโดยตรงจากภายนอก
– Private (#) ซงจะถู
ซึ่งจะถกใช
กใชงานจากภายใน
งานจากภายใน Class เทานน
เทานั้น
– Protected (-) ซึ่งจะสามารถเห็นหรือเขาถึงไดจากภายใน Subclass
เทานั้น

15
ความสัมพันธระหวาง Object
ความสมพนธระหวาง
• ความสมพนธระหวาง
ความสัมพันธระหวาง Object ประกอบดวย
ประกอบดวย
1. Association
2 Aggregation
2.
3. Composition
4 Generalization
4.

16
Association
• เปนความสัมพันธระหวาง Object หรือ C ass แบบ 2 ทิศทาง
Class

17
Aggregation
• เปนความสัมพันธระหวาง Object หรือ C ass แบบ “Whole-Part”
Class oe a t
หรือ “is part of” โดยจะมี Class ที่ใหญที่สุดที่เปน Object หลัก
และมี Class อืน่ เปนสวนประกอบ

Car Whole

Engine Body Wheel Part

18
Composition
• เปนความสัมพันธระหวาง Object
หรือ Class แบบขึ้นตอกันและมี Text

ความเกี่ยวของกันเสมอ โดยจะมี
Class ซึ่งเปนองคประกอบของ
Class อืน่ ที่ใหญกวา
Windows Button

• เมื่อ Class
C ที่ใหญกวาถูกทําลาย
Class ที่เปนองคประกอบก็จะถูก Menu

ทําลายไปดวย
ทาลายไปดวย

19
Generalization
Person

• เปนความสัมพันธระหวาง Object
j Lastname
Fi t
Firstname
หรือ Class ในลักษณะของการสืบ Birthdate
Gender

ทอดคุณสมบัติจาก Class หนึ่ง Walk()


Jump()

(Superclass) ไปยงอกไปยังอีก Talk()


()
Sleep()

Class หนึ่ง (Subclass)


Eat()

Student Teacher

Department Position
Year Expertise
GPA
Lecture()
Enroll()
() Comment()
Study()
Exam()
Graduate()

20
Unified Modeling Language
(UML)
• UML เปนภาษารู
เปนภาษารปภาพมาตรฐาน
ปภาพมาตรฐาน (Standard Modeling
Language) สําหรับใชในการสรางโมเดลเชิงวัตถุ
• UML เปปนเสมืือนพิมิ พเ ขียี วทีแี่ สดงภาพรวมของระบบทังั้ หมด โดยจะ

แสดงในรูปแบบของแผนภาพ (Diagram) เพือ่ ใหเกิดความเขาใจที่
ตรงกันระหวางผออกแบบระบบ,
ตรงกนระหวางผู อกแบบระบบ โปรแกรมเมอรและผู
โปรแกรมเมอรและผใชชงาน
งาน

21
Unified Modeling Language (UML)

• เปนภาษาที่ใชในการสรางแบบจําลอง (Modeling Language) ที่ประกอบดวยองคความรูที่ใชใน


การนําเสนอและออกแบบเอกสารประกอบโปรแกรม
ป โป
• รวม 3 แนวคิด/วิธีการเชิงวัตถุที่ ไดแก Booch, Rumbaugh และ Jacobson รวมทั้งจากบุคคลอื่น
• จดเปนมาตรฐานสาหรบการแลกเปลยนแนวคดการออกแบบระบบ
จัดเปนมาตรฐานสําหรับการแลกเปลี่ยนแนวคิดการออกแบบระบบ และองคความรู
และองคความรในเชงเทคนค
นเชิงเทคนิค
ในรูปของแบบจําลอง
• ไมใชภาษาโปรแกรม (Programming Language)
• ใช method หรือ methodology
• ไมระบุ Process ที่ใชในการทํางาน
• UML ใชในการสรางแบบจําลองการวิเคราะห และออกแบบระบบ โดยไมขึ้นกับ Process
• แตละโครงงานสามารถเลือก Process การทํางาน ที่เหมาะสม กับสภาพความจริงของโครงงาน
โดยไมขึ้นกับ modeling
โดยไมขนกบ d li llanguage
22
ความเปนมาของ UML
ความเปนมาของ
• UML ถูถกคิ
กคดคนทบรษท
ดคนที่บริษัท Rational Software ในป
ในป 1994
1994-
1995 โดย Grady Booch, James Rumbaugh และ
Ivar Jacobson
• ในป 1997 UML version 1.1 ไดถูกเสนอเปนมาตรฐานกับ
OMG ((Object j Management
g p) ซึ่งไดถูก
Group)
กําหนดใหเปนภาษาโมเดลมาตรฐาน จากนัน้ UML ไดถูกพัฒนาจนถึง
version 1.4 (ป 2001) และ 2.0 (ป 2002)

23
History of UML
• 1970s วิธีเชิงวัตถุุ ((Object-oriented
j method))
• 1970s, 1980s, 1990s “Method Wars”
Grady Booch,
Booch Jim Rumbaugh,
Rumbaugh Ivar Jacobson
• 3 แนวคิด/วิธีการเชิงวัตถุที่เปนที่นิยมใชในชวงกลางทศวรรษ 1990s ไดแก
– OOSE (Object-Oriented Software Engineering) โดย Ivar Jacobson
– OMT (Object Modelling Technique) โดย Jim Rumbaugh
– Booch method โดย Grady Booch
• ปญหาดานการสื่อสาร สัญลักษณที่ใชในแตละวิธีการไมเหมือนกัน

24
History of UML
• ในป
ในป 1994/5 Booch, Rumbaugh และ Jacobson (เรยกตวเองวา (เรียกตัวเองวา “three
three
amigos”) รวมกันทําการรวบรวมแนวคิด องคความรู และเทคนิคตางๆ
เขาดวยกัน ทที่ Rational Software
เขาดวยกน
• Three Amigos เสนอ Unified Modelling Language (UML) ไปยัง
หนวยงาน OMG (Object Management Group) เพอใหเปนภาษา
หนวยงาน เพื่อใหเปนภาษา
มาตรฐานสําหรับสรางแบบจําลองเชิงวัตถุ
• UML Version 1.1 ได ไ ถ ูกพัฒ
ั นาขึึ้นในป
ใ ป 1997 เพือื่ เปปนมาตรฐาน สํําหรับั
สรางแบบจําลองเชิงวัตถุ

25
History of UML
• ปป 1998 พฒา
พัฒา UML Version 1.2
• ป 1999 พัฒา UML Version 1.3
• ป 2000 พัฒั า UML Version 1.4
• ป 2001 พัฒา UML Version 2.0
• http://www.uml.org/

26
UML Diagrams
• Structure • Behavior
Diagrams Diagrams
– Class – Activityy
– Object – Sequence
– Package – Collaboration
– Deployment
D l t – Interaction
I t ti
– Component Overview Timing
– Composite – Behavioral State
Structure Machine
– Proxy State
Machine
27
– Use Case
Use Case Diagram
• Use Case Diagram เปนแผนภาพทใชทแสดงปฏสมพนธ
เปนแผนภาพทีใ่ ชที่แสดงปฏิสัมพันธ
ระหวางระบบงานและสิ่งที่อยูน อกระบบงาน Use Case
Diagram ประกอบดวย
– Actor คือ ผูที่กระทํากับระบบ อาจเปนผูที่ทําการสงขอมูล, รับขอมูล
หรือ แลกเปลี่ยนขอมูลกับระบบนั้นๆ เชน ลูกคากับระบบสั่งซื้อสินคาทาง
โทรศัพท
โทรศพท
– Use Case คือ หนาที่หรืองานตางๆในระบบ เชน การเช็คสต็อค
การสั่งซื้อสินคา เปนตน
– Relationship คือ ความสัมพันธระหวาง Use Case กับ
Actor

28
Models and Diagrams
A model is a complete
description of a system
from a particular perspective State
State
Diagrams
Class
Diagrams
Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Use Case Diagrams
Object
Diagrams
Sequence Diagrams Diagrams
Diagrams Diagrams
g
Di
Diagrams

Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams Component
Diagrams
Diagrams Models Diagrams

Scenario Component
Scenario
Diagrams
Component
Diagrams
Deployment
Statechart
Diagrams Diagrams
Diagrams Diagrams
Activityy
Diagrams
29
UML has 9 kinds of diagrams
n Class Diagram
o Obj t Diagram
Object Di
p Component Diagram Structural Diagrams
q D l
Deployment t Di
Diagram
r Use Case Diagram
s S
Sequence Diagram
Di
t Collaboration Diagram Behavioral Diagrams
u St t T
StateTransition
iti Diagram
Di
v Activity Diagram

30
UML(Unified
( Modeling
g Language)
g g )

• 5 มุมมมองหลั
มมองหลกของ
กของ UML
– Use-case view : หนาที่การทํางานของระบบซอฟตแวร โดย
พิจารณาจากมมมองของผ
พจารณาจากมุ มมองของผูใชภายนอก
ชภายนอก หรอ
หรือ ระบบภายนอก
• use-case diagram
– Logical view : หนาทการทางานของระบบมโครงสรางอยางไร
หนาที่การทํางานของระบบมีโครงสรางอยางไร มอง
ในรูปของ static structure และdynamic behavior
• class diagram, object diagram, state, sequence,
collaboration, activity diagrams

31
UML(Unified
( Modeling
g Language)
g g )

– Component
p view : องคประกอบยอยในการ implement
p ที่ประกอบ
เปนระบบ และ dependency ระหวางองคประกอบเหลานั้น
• component diagram
– Concurrency view: การแบงแยก process และ processors โดย
พิจารณาทั้ง communication และ synchronization
• dynamic diagrams (state, sequence, collaboration activity)
• implementation diagrams(component และ deployment)
– Deployment
Deplo ment viewie : โครงสรางทางกายภาพเกยวกบ
โครงสรางทางกายภาพเกี่ยวกับ การตดตง
การติดตั้ง และ
ใชงานระบบ
• deployment diagram
32
Class Diagrams
• Class diagrams
– แสดงรายละเอียี ดของ Class
Cl และความสัมั พัันธระหวา ง Class
Cl
ในมุมมองแบบ logical view
• องคป ระกอบของ UML class diagrams ได
ไ แ ก
– Class, โครงสรางของ Class และพฤติกรรมของ Class
– ตัวบงชี้ Multiplicity และ navigation
– ชื่อของ Role
– ความสัมพันธแบบ Association, aggregation,
dependency, และ inheritance

33
Class Diagram
• Class Diagram คอ คือ แผนภาพทใชแสดง
แผนภาพทีใ่ ชแสดง Class และ
ความสัมพันธระหวาง Class ของระบบที่สนใจ (Problem
Domain)) เชน ในระบบจัดซื้อ Class ที่เกีย่ วของคือ ผููผลิต,
พนักงานจัดซื้อ, ใบสั่งซื้อ, ใบเสนอราคา, ใบเสร็จรับเงิน เปนตน

34
Class Diagram
• สญญลกษณ
สัญญลักษณ Class ประกอบดวย
ประกอบดวย
1. Class Name คือ ชื่อของ Class
2 Attributes คอ
2. คือ คณลั
คุณลกษณะของ
กษณะของ Class
3. Operations หรือ Methods คือ กิจกรรมที่สามารถกระทํากับ
Object นนๆได
นั้นๆได
Name

Attributes

Methods
35
Classes in UML
• เขียนได 2 รูปแบบ
Class name

Person Person
- TaxIDNo : String
Attributes - Name : String
attribute name : type + Income : double
+ TaxPaid : Boolean
+ calcTax()
Operations
+ calcTaxBal()
operation name(parameter : type)
: result type
36
Class Diagram
Customer Account

FirstName Number
LastName 1 Has Balance
CardName Transaction
PinNumber *
Account Deposit()
Withdraw()
VerifyPassword() UpdateAccount()

Perform

*
Transaction
ตัวอยาง Class Diagram ในระบบธนาคาร
TransactionID
TransactionDate
TransactionTime
TransactionType
Account
Amount
PostBalance

37
A Class Diagram
g
Actuator

startUp(
p( )
shutDown( )

generalization

Light Heater Cooler Temperature

off( )
on( ) 1 1

0..*
aggregation
1
1 1
Environmental Controller SystemLog
y g

define_climate( ) display( )
terminate_climate( ) recordEvent( ) 38
An Object Diagram
Account
#31421123

Victoria High Street Account


Branch #741421123
(A Branch Object)
Account
#521665423

Account
#31421123
London Road
Branch
Account
(A Branch Object) #31421123

Account
#714559543

39
Component Diagram
• Component Diagram เปนแผนภาพทแสดงโครงสรางและ
เปนแผนภาพที่แสดงโครงสรางและ
ความสัมพันธระหวางองคประกอบ (Components) ตางๆของ
Software ซึ่งองคประกอบดังกลาวอาจเปน Source Code,,
Executable Program, Binary รวมถึง Text และ
User Interface

40
Component Diagram

Professor.exe

Course.dll Database.dll

Professor Info AddCourse Offering

ตัวอยาง Component
p Diagram
g ของระบบการลงทะเบียน

41
A Component Diagram
Billi
Billing.exe Register.exe
Billing
System

People.dll
User
Course.dll
Course

Student Professor
Course Course
Offering

Componentt Di
C Diagram เปปนไดอะแกรมที
ไ ใ่ี ชอ ธิบิ ายถึงึ ซอฟต
ฟ แวร
ตางๆ ที่เปน Component ของระบบ 42
D l
Deployment
t Diagram
Di
• Deployment Diagram ใชสําหรับแสดง
สถาปตยกรรมของระบบในลักษณะที่เปน physical
p y
Architecture คือแสดงวามีคอมพิวเตอรและอุปกรณ
อะไรบางที่ตองการใชในระบบ
• ใชรูปลูกบาศกแทน โดย 1 ลูกบาศกจะแทน 1 โหนด และแตละ
โหนดก็จะมี component ทเปนองคประกอบของโหนดนน
โหนดกจะม ที่เปนองคประกอบของโหนดนั้น

43
Deployment Diagram
• Deployment
p y Diagram
g เปนแผนภาพที่แสดงสถาปตยกรรมของ
Hardware และ Software ในระบบรวมทั้งความสัมพันธระหวาง

<<LAN>>
<<Client Workstation>> <<Server>>
Receptionist PC Office Server

<<LAN>>

Receptionist PC
Office Server

44
A Deployment
p y Diagram
g

Account
A
Account Server
Server

Deploys
AccountDB.java
AccountMgt.java

AccountDB.java
j AccountMgt.java

45
Use Case Diagram
• Use Case แปลตรงตวมความหมายวา
แปลตรงตัวมีความหมายวา กรณีกรณของการใชงาน
ของการใชงาน
ที่เกิดจากมุมมองของผูใชระบบ ตัวอยางงายๆ ของ Use
Case กคอ ก็คือ
- Create Order (ทําการลงใบสั่งซื้อสินคา)
- Modify
M dif OrderO d (ทํําการเปลี ป ่ียนแปลงหรื
ป ือแกไ ขใบสั
ใ ง่ั ซือื้
สิ้นคา)
- Delete Order (ทําการลบใบสั่งซื้อสินคา)

46
Use Case Diagram
• Use Case อาจหมายถง
อาจหมายถึง การอธิ
การอธบายฟงกชนการทางาน
บายฟงกชันการทํางาน
ตางๆ ของระบบนั่นเอง
• Use Case Diagram จะแสดงแผนผงการใชงานของ
จะแสดงแผนผังการใชงานของ
ระบบ โดยมีองคประกอบ 2 สวนคือ actor และ use
case

47
A Use Case Diagram
<<include>> Retinal
Track Validate Scan
Order Client

Trader <<include>> Check


Password

<<include>>
Place Establis
stab s
Order h
Stock Credit Financial
Exchange <<extend>> Officer

Place
Rush
Order

48
Use Case Diagram
ATM Subsystem: Withdrawal

Enter Password

Check Balance

Card Holder
Withdraw Cash

Get Slip

ตัวอยาง Use Case การถอนเงิน 49


Use Case Diagram
Telephone Ordering System

Check Status

Salesperson

Place Order

Customer Clerk
Fill Order

Establish
Credit

Manager

ตัวอยาง Use Case การสั่งซื้อสินคาทางโทรศัพท 50


Sequence Diagram
• Sequence Diagram จะแสดงการทางานของ จะแสดงการทํางานของ
ออบเจ็กตตา งๆเมือ่ เกิดการสงขาวสารหรือ massage
และเมอเกดเหตุ
ื่ ิ การณตางๆ   โดยทศทางของลู
โ ิ กศรจะเปนการบง
ป 
บอกถึงทิศทางการสง messageระหวางออบเจ็กต

51
Sequence Diagram
• Sequence Diagram เปนแผนภาพทใชอธบายการทางานของ
เปนแผนภาพทีใ่ ชอธิบายการทํางานของ
Use Case เพือ่ แสดงถึงขั้นตอนการทํางานและลําดับของการสื่อสาร
((Message) g ) ระหวาง Object
j ที่ตอบโตกัน
• Sequence Diagram จะแสดงอยูใ นรูปแบบ 2 มิติ โดยเสนประ
แนวตั้ง ((Lifeline)) จะนําเสนอในดานเวลา สวนเสนแนวนอน
(Message) จะนําเสนอเกี่ยวกับการโตตอบกันระหวาง Object
หรือ Class ตางๆ

52
Sequence Diagram

ATM Machine Account


Card Holder
InsertCard()

RequestPassword()

EnterPassword()

CheckPassword()

ConfirmAccess()

Di l T
DisplayTransType()
T ()

ChooseTransType()

ReadAccBalance()

Co
ConfirmBalance()
a a ce()

DisplayBalance()

CloseTrans()

ReturnCard()

53
ตัวอยาง Sequence Diagram การสอบถามยอดบัญชีจากตู ATM
A Sequence Diagram

: Student registration registration math 101 math 101


form manager section 1
1: fill in info
2: submit
3: add course(joe, math 01)
4: are you open?
5: are you open?
6: add (joe)
7: add (joe)

54
Collaboration Diagram
• Collaboration Diagram จะแสดงการ
ติดตอสื่อสารระหวางออบเจ็กตตางๆ และความสัมพันธ
 ี่  ็  ิ  ื่
ระหวางทแตละออบเจกตตดตอสอสารกน ั

55
Collaboration Diagram
• Collaboration Diagram เปนแผนภาพชนดเดยวกบ
เปนแผนภาพชนิดเดียวกับ
Sequence Diagram โดย Sequence Diagram จะ
เปนแผนภาพที่แสดงถึงการสื่อสาร แต
เปนแผนภาพทแสดงถงการสอสาร แต Collaboration
Diagram จะนําเสนอการทํางานรวมกันระหวาง Object เปนหลัก
แตก็สามารถแสดงถึงลําดับกอนหลังดวย

56
Collaboration Diagram
1. InsertCard
3. EnterPassword
7. ChooseTransType
11.CloseTrans

Card Holder

2. RequestPassword
6. DisplayTranstype
10. DisplayBalance ATM Machine
12. ReturnCard

4. CheckPassword
8. ReadAccBalance

5. ConfirmAccess
5
9. ConfirmBalance

Account

ตัวอยาง Collaboration Diagram การสอบถามยอดบัญชีจากตู ATM 57


A Collaboration Diagram
g
1: set course info course form
f :
2: process CourseForm

: Registrar 3: add course

aCourse : theManager :
Course CurriculumManager
Cu cu u ge
4: new course

58
State--Transition Diagram
State
State Transition Diagram ทาหนาทตอไปน
State-Transition ทําหนาที่ตอไปนี้
• แสดงวงจรชีวิตของออบเจ็กต ระบบยอยตางๆ และระบบ
โดยรวม
• บงบอกวาเหตุกุ ารณตางๆๆ จะสงผลกระทบใหเกิดอะไรขึ้นบางใน
ระบบ
• อาจมีจี ดุ เริิ่มตน และและจุดจบได
ไ ห ลายจุด

59
A State
State--Transition
Diagram
Add student[ count < 10 ]
Add Student /
Initialization Set count = 0
Open
do: Initialize course
entry: Register
R i student
d
exit: Increment count
Cancel
Cancel [ count = 10 ]
Canceled
do: Notify registered students Closed
Cancel do: Finalize course

60
Statechart Diagram
• Sequence
q Diagram
g เปนแผนภาพที่ใชแสดงสถานะตางๆและการเปลี
ๆ ่ยน
สถานะของ Class ตัง้ แตเริ่มตนจนสิ้นสุด

Ready Booting Complete Boot


Do/waiting
Do/loading the OS
for instructions
Switch on Complete

Off On
Switch is turned on
Do/Shut down Do/turn on
the power the Computer

ตัวอยาง Statechart Diagram การเปดเครื่องคอมพิวเตอร


61
Activity diagram
• ใชสําหรับ
– อธิบาย กระแสการไหลของการทํ
ไ างาน (workflow)
– แสดงขั้นตอนการทํางานของระบบ
• แตละขั้นตอนการทํางาน เรียกวา Activity ตัวอยาง ได
ไ แก
– การคํานวณผลลัพธบางอยาง
– การเปลี่ยนแปลงสถานะ (State) ของระบบ
– การสงคากลับคืน
– การสงสัญญาณ
– การเรียกใหโอเปอรเรชันอื่นๆ ทํางาน
– การสราง หรือ ทําลายวัตถุ
62
Activity Diagram
• Activityy Diagram g เปนแผนภาพที่ใชที่แสดงขั้นตอนการ
ทํางานของ use case (เชนเดียวกับ Sequence Diagram
และ Collaboration Diagram) แตจะเนนไปที่งานยอยของวัตถุ

โดยจะมี กี ระบวนการทํางานคลา ยกับ Flowchart
Fl h t
• Activity Diagram บางครั้งมีลักษณะคลาย Swimlane

โดยจะแบงกลุ มกจกรรมทเกดขนเปนชอง
ิ ี่ ิ ึ้ ป  โดยกากบแตละชองดวยชอของ
โ ํ ั    ื่
Object แตละ Swimlane แสดงถึงกิจกรรมที่เกิดขึ้นกับ
Object นนๆ นัน้ ๆ

63
CardHolder ATM Machine Account

Activity
Di
Diagram InsertCard Request Password

Enter Password Check Password Confirm Access

Display Transaction Type

ตัวอยาง Activity Diagram การ


สอบถามยอดบัญชีจากต ATM
สอบถามยอดบญชจากตู Choose Transaction Type Read A/C Balance Confirm Balance

Display Balance

Close Transaction Return Card

64
An Activity
y Diagram
g
Ordinary Example
Show
MessageBox Create postscript
“P i i ”
“Printing” fil
file
on Screen

Remove Se d postscript
Send postsc pt
MessageBox file to printer

Swimlane displayer sampler


Example

65
Benefits of UML
• เปนภาษามาตรฐานทีใ่ ชในการสรางแบบจําลองเชิงวัตถุ โดยใช
รูปภาพ (Standard Visual Modeling Language)
• ใชในการแลกเปลี่ยนขอมูล แบบจําลองกันระหวางทีมผูพัฒนา และ
ระหวางผูใช กับทีมผูพ ัฒนา
• นําเสนอ และ สนับสนุุนหลักการเชิงวัตถุไุ ดครบถวน ชัดเจน
• ไมผูกติดกับภาษาโปรแกรม (Programming Language) ภาษาใด
ภาษาหนึ่ง
ภาษาหนง
• สนับสนุนการขยายขอบเขต และการปรับปรุงระบบ โดยที่ไม
จาเปนตองลงมอพฒนาซอสโคดกอน
ํ ป  ื ั โ  
66
แบบฝกหัด
จงสราง Use Case Diagram g ของระบบหองสมุุดในมหาวิทยาลัยแหงหนึง่ ซึง่ ผูเู ขาใช
บริการไดแก นักศึกษา อาจารย และพนักงานของมหาวิทยาลัย
ในกระบวนการทํางาน เจาหนาที่หองสมุดจะทําหนาทีใ่ หบริการยืม/คืนหนังสือของแกบคุ คลดังกลาว
นอกจากนี้ยังจะตองจัดการกับทรัพยากรในหองสมุด เชน การเพิ่ม, แกไข, ลบขอมูลหนังสือและ
วารสาร รวมทั้งขอมูลเกี่ยวกับสมาชิกของหองสมุดอีกดวย
ทุกเดือื น เจา หนา ทีหี่ องสมุดจะตอ งทําํ รายงานตา งๆ สง ใใหกับผูอํานวยการศูนยส ารสนเทศ เชน
รายงานจํานวนสมาชิก, รายงานจํานวนหนังสือและวารสารใหม, รายงานการยืม/คืนหนังสือ, รายงาน
คาปรับลาชา เปนตน

67
Use Case Model

68
System Analysis
• กระบวนการวิเคราะหระบบ (system analysis phase)
– มุงเนน “what” ที่ระบบจะตองมี และตองทําใหกับผูใ ช ไมเนน
“how” วาจะทําอยางไร
• กระบวนการวิเคราะหความตองการของผูใชระบบ (Requirement
analysis phase)
– ใชในการสรางแบบจําลองหนาที่การทํางานของระบบซอฟตแวร
จากมมมองของผ
จากมุ มมองของผูใชชภายนอก
ภายนอก หรอ
หรือ ระบบภายนอก
– ไดแบบจําลองของความตองการของผูใชระบบ (Requirement
Model) เปน
เปน Output
69
System Analysis and Use
• Use Case Model Case
Case
– แบบจํ
แบบจาลองความตองการของระบบ
าลองความตองการของระบบ ทีท่ นาเสนอ
นําเสนอ functional
requirement ของระบบโดยรวม จากมุมมองของผูใชภายนอก
หรือ ระบบภายนอก
หรอ
– ระบุพฤติกรรม หรือหนาที่การทํางานของระบบ (เนน “what”) ที่
ระบบตองมี
ระบบตองม
– ใชในการทดสอบ และตรวจสอบ โครงสราง และหนาที่การทํางาน
ของระบบ
– ใน UML ระบุเปน Use Case Description (Text) หรือ Use
Case Diagram(Diagram)
70
Stock

Use Case Example Place Order Exchange


M k
Market

• Name: การสงรายการซื้อขายหลักทรัพย (Place Order)


– Main flow of events: Trader
1. Traderปอนชื่อ และรหัสของ client
2. System ตรวจสอบ (Validate) ชือื่ รหัส และcredit ของ client
3. Trader ปอนรหัสหลักทรัพย จํานวนหลักทรัพย และราคา
หลักทรัพย ที่ Client ตองการซื้อขาย
4. System ตรวจสอบเงื่อนไขราคาของหลักทรัพย
6. System สง order ใหกบั ตลาดหลักทรัพย
7. System เก็บหมายเลข order ที่ไดรับจากตลาดหลักทรัพย
8. System แจงให Trader ทราบ 71
Use Case Diagram
• นําเสนอ Use Case และการปฏิสัมพันธโตตอบกันระหวางระบบ
และ ผูใชภายนอก (อาจเปนคน หรือระบบก็ได)
• ประกอบดวย
– Use Case - ความสามารถ/หนาที่ของระบบ
– Actor - ผูผกระทา/ผู
ระทํา/ผใชชงาน
งาน Use Case นนๆ
นั้นๆ
– Relationship - เสนแสดงความสัมพันธระหวาง Use Case กับ
Actor
– System - ระบบที่กําลังพัฒนา
72
Use Case Modeling :
Core
Construct Description
Elements Syntax
use case A sequence of actions, including
variants, that a system (or other
UseCaseName
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.
ActorName

system Represents the boundary between


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

73
Use Case Modeling : Core
R l ti
Relationships
hi
Construct Description Syntax
association
i ti The participation
Th ti i ti off an actor
t ini a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other
other.
generalization A taxonomic relationship between a
more general use case and a more
specific
p use case.
extend A relationship from an extension use
case to a base use case, specifying
how the behavior for the extension <<extend>>
use case can be inserted into the
behavior defined for the base use
case.

74
Use Case Modeling : Core
Relationships (cont’d)
Construct Description Syntax
include An relationship from a base use case
to an inclusion use case, specifying <<include>>
how the behavior for the inclusion use
case is inserted into the behavior
defined for the base use case.

75
Use Cases v v.s.
s
• Use Case
– ความสามารถ หรือScenario
หนาที่การทํางานของระบบ
– แตละ Use Case แทนชุดของ transactions ที่ระบบทํางานโตตอบกับ
ผูผใชชงาน
งาน หรอระบบอนๆ
หรือระบบอื่นๆ ภายนอก
• Scenario
– สถานการณ
สถานการณ หรอตวอยางเรองราวการใชงานระบบ
หรือตัวอยางเรื่องราวการใชงานระบบ
– Scenario จัดเปน instance ของ use case
– เชน
a user withdrawals
$200
withdrawal cash
76
Actors
• Actor หมายถึง someone หรือ some thing ที่มีการปฏิสัมพันธ โตตอบ
กับระบบ
– สิ่งใดก็ตามที่มีความตองการในการแลกเปลี่ยน information กับ
ระบบ หรือ สิ่งใดก็ตามที่อยููภายนอกระบบ และมีการใชงาน Use
Case ของระบบ
– กาหนดบทบาทหนาทของผู
กําหนดบทบาทหนาที่ของผใชชระบบระบบ
– กําหนดการเชี่อมโยงกับระบบอื่นๆ ภายนอก
• ตวอยางของ
ตัวอยางของ Actors
At
– Customer -- maintain their account
– Cashier
C hi -- verify if withdrawal
ithd l amountt
Customer Cashier
77
Actors
• Actors สามารถอธิบายโดยใช Specialization Relationship

specialization
relationship
Customer

ATM Customer Cashier Customer

• อาจพิ
อาจพจารณา
จารณา Actors
A t เปนคลาส
เปนคลาส ใน UML เนองจากม
เนื่องจากมี relationships
l ti hi
เชนเดียวกับที่คลาสมี

78
Actors
• เชื่อมตอกับ use cases โดยใชเสนแสดงความเกี่ยวของ ปฏิสัมพันธ
( i ti )
(association)
• association = ความสัมพันธที่มีการติดตอสื่อสารกัน (ทั้งการรับ
และสง messages ใหแกกนและกน)
และสง ใหแกกันและกัน)

withdrawal cash
Customer

• ใช
ใช generalization
generali ation relationships อธบายความสมพนธ
อธิบายความสัมพันธ ระหวาง
ระหวาง
actors ไมจําเปนตองอธิบายรายละเอียดของ Association เนื่องจาก
ไมมีการ Implement สวนของ
ไมมการ สวนของ Actor ในระบบ
79
System
• System
– อาจหมายถึงึ Software system, business, hardware,..
– วัตถุประสงคใน use-case modeling เพื่อระบุขอบเขตของระบบ
ที่กําลังพัฒนา (system boundary)
• ใชสญ
ั ลักษณ

System

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

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

82
“Include”
Include relationship
• มักใชในการหลีกเลี่ยงการอธิบายการไหลของเหตุการณ (flow of
events) เดิม ซ้ํากันหลายๆ ครัง้ โดยรวบรวมพฤติกรรมรวม ใน Use
Case
<<include>>
Validate
Place
client
order
d

<<include>>
Track
order
d

• หลกเลยงการ
หลีกเลี่ยงการ copy & paste ของ Use Case Descriptions
83
<<include>>
“Include”
Include Example Track Order Validate
Client

• Name : การตรวจสอบรายการซื้อขายหลักทรัพย
(Track Order)
– Main flow:
1. ใชหมายเลข order ในการตรวจสอบ ที่ไดรับจากตลาด
หลักทรัพย Obtain and verify order number
2. Include สวนของ “Validate client”
3. ในแตละสวนของ Order …

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

85
<<extend>> Place Rush
“Extend” Example Place Order
Order

• Name : การสงรายการซื้อขายหลักทรัพย (Place Order)


– Main flow of events:
1. …
2. Trader ปอนเงื่อนไขของหลักทรัพย ที่ Client ตองการซื้อ
ขาย
3. กําหนดลําดับความสําคัญ โดย (set priority)
y สง order ใหกบั ตลาดหลักทรัพย
4. System
5. ...

86
Relationships between Use
Case
Validate Ship Order
Account

<<include>> <<extend>>

Withdrawal Ship Partial


Cash Order

87
Comparing extends/uses
• extend
– ใชแยกความแตกตางของ
ใชแยกความแตกตางของ Use U Case
C
– actors ที่เกี่ยวของมักเปนคนกระทํา Use case และUse Case ที่
extend ทังั้ หมด
– actor มักเชื่อมตอกับ “base” Use Case
• include/use
– ใช
ใช extract พฤตกรรมรวม
พฤติกรรมรวม
– มักไมมี actor เกี่ยวของโดยตรงกับ Use Case ที่มพี ฤติกรรมรวม
– actors ทีแี ตกตางกััน for “caller” use cases possible
88
A Use Case Diagram
g

<<include>> Retinal
Track Validate Scan
Order Client

Trader <<include>> Check


Password

<<include>>
Place Establis
stab s
Order h
Stock Credit Financial
Exchange <<extend>> Officer

Place
Rush
Order

89
A Use Case Diagram
g
Deposit

Transfe
r

Validate
Account
Customer <<include>> <<include>>
include Verify
withdrawa
Withdraw Bank
l
Teller
<<include>>

Balance
Checking

90
When and how?
• Requirements capture
– ใช
ใชในการกาหนด
ในการกําหนด Reuqirement ของระบบ
– สรางแบบจําลอง (Model) ของ ser requirements ดวย Use Case
• Test
est Scenarios
Sce a os
– สรางแบบจําลอง (Model) ของสถานการณการทดสอบระบบ (test
scenarios) ดวย Use Case
• Use Case:
ระบุุสิ่งที่ customer ตองการใหมใี นระบบ
– ตั้งชื่อให Use Case
– เขียนคําอธิบายสั้นๆ
– เพิ่มรายละเอียดในภายหลัง
91
Finding Actors
• สามารถระบุ actor ไดโดยตอบคําถามตอไปนี้
– ใใครเปปนคนใช
ใ งานหนาทีกี่ ารทําํ งานหลักั ของระบบ (primary
( actors)?
)
– ใครตองการการสนับสนุนการทํางานจากระบบ?
– ใครตองการบํารงรั
ใครตองการบารุ งรกษา
กษา และบรหารระบบ
และบริหารระบบ (secondary actors)?
– Hardware devices ใดที่ตองการใหระบบจัดการดูแล?
– ระบบภายนอกระบบใดที่ ตองการใหระบบมีปฏิสัมพันธดวย?
– ใคร หรือ อะไรที่ตองการไดรับผลประโยชน จาก output ของระบบ?
• Tips
– ไมควรพิจารณาเฉพาะ users ที่ใชงานระบบโดยตรง แต พิจารณา users อื่นๆ ที่
ตองการใชบริการจากระบบดวย

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

93
Recipe
• ระบ
ระบุ actors ทมปฏสมพนธกบระบบ
ที่มีปฏิสัมพันธกับระบบ
• พิจารณาแนวทางของระบบ ในการปฏิสัมพันธกับ actors
• จําํ แนกพฤติกิ รรมของระบบใน ใ การปฏิ
ป ิสัมพัันธกับ actors ให
ใ เปน
use cases โดยกําหนดความสัมพันธระหวาง Use Case

94
ตัวอยางการเขียน Use case
ตวอยางการเขยน

95
การเขียน Use case
องคประกอบมีดังนี้
- ชือื่ ของ Use
U C Case
- ภาพรวมของการทํางาน (Overview)
- Actor หลก หลัก (Primary Actor)
- Actor รอง (Secondary Actor)
- จุจดเริ
ดเรมตน
ม่ ตน (Starting Point)
-จุดสิ้นสุด (End point)
- การทํางานของ Use Case ((Flow of Events))
- การทํางานของ Use Case เมื่อมีปญหาเกิดขึ้น (Alternative
flow of Events)
-ผลของการทํางานของ Use U C Case (M
(Measurable bl Result)
R lt)
96
Use Case : Create Order
ภาพรวมของการทํางาน (Overview)
จุดประสงคหลักของ Use Case นี้ เพื่อทําการลงขอมูลในใบสั่ง
ซื้อสินคาจากลกค
ซอสนคาจากลู กคาา
Actor หลัก (Primary Actor)
ตัวแทนฝายขายสินคา
ตวแทนฝายขายสนคา
Actor รอง (Secondary Actor)
ไมมี
จุดเริ่มตน (Starting
(S Point))
Use Case ตัวนี้เริ่มตนเมื่อ Actor ตัวแทนฝายขายสินคา
ขอใหระบบทําการลงขอมลการสั
ขอใหระบบทาการลงขอมู ลการสงซอสนคา
่งซื้อสินคา
จุดสิ้นสุด (End point)
คําขอเพื่อทําการลงขอมูลการสั่งซื้อสินคาเสร็จสิ้นสมบูรณหรือไมก็ถูก
ยกเลกิ
97
Use Case : Create Order
การทํางานของ Use Case (Flow of Events)
จาก User Interface บนจอเพื่อทําการลงขอมูลการสั่งซื้อ
Actor จะตองทําการใสขอมูลเกี่ยวกับการสั่งซื้อ เปนตนวา วันที่ลูกคา
ตองการใหสินคาสงมอบถึงมือ (Required Date) ปริมาณที่
ตองการสั่งซื้อ (Quantity) ตองการใหสงมอบสินคาโดยบริษัท
สงสินคาไหน (ShipVia) ตองการใหใหสงมอบสินคาที่ไหน
(ShipAddress) หลังจากนั้นแลว Actor สามารถเลือกที่จะ
ทําการบันทึกึ ขอมูลลงไปไว
ไ ไ ในฐานขอมูล หรืือยกเลิกการทํางานทั้งหมด
ถา Actor เลือกทําการบันทึก ใบสั่งซื้อใบใหมก็จะถูกสรางขึ้นมาใน
ฐานขอมูล
98
Use Case : Create Order

การทางานของ
การทํ างานของ Use Case เมอมปญหาเกดขน
เมื่อมีปญหาเกิดขึ้น
(Alternative Flow of Events)
ถาไมมีสินคาที่ตองการอยในคลงสนคา
ถาไมมสนคาทตองการอยู นคลังสินคา ระบบจะตองแจงให
ระบบจะตองแจงให Actor
ทราบพรอมกันนั้นก็ตองยกเลิกการทํางานที่เหลือของ Use Case
นนี้
ผลของการทํางานของ Use Case (Measurable
R
Result) lt)
จะมีใบสั่งซื้อสินคาใหม 1 ใบขึ้นมาในระบบ
99
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 items
and collects payment. On completion, the
Customer leaves with the items

100
Expanded Use Case Example
U C
Use Case: B Items
Buy It with
ith Cash
C h
Actors: Customer (initiator), Cashier
Purpose: Capture a sale and its cash payment
Overview: A Customer arrives at a checkout with items to
purchase. The Cashier records the purchase
items and collects a cash payment
payment. On
completion, the Customer leaves with the items.
Type: primary and essential
Cross references: R1.1, R1.2, R1.7

101
Expanded Use Case (2)
( )
TYPICAL COURSE OF EVENTS
1. This use case
ACTOR begins
ACTION g SYSTEM RESPONSE

when a Customer
arrives at the register
with items to
purchase. 3. Determines the item price and adds
2 The cashier records
2. the item information to the runningg
the identifier from sales transaction. The description and
each item. If more price of the item are presented.
th one off the
than th same
5. Calculates and presents the
item, the Cashier can
enter
e te tthe
e qua
quantity
t ty as sale total.
well.
102
4. Cashier indicates
l i fi
Expanded Use Case (3
(3 )
ACTOR ACTION SYSTEM RESPONSE

7. The Customer
gives a cash
payment - possibly
greater than the
sale total. 9. Show the balance due
8. The Cashier back to the Customer.
records the cash Generates a receipt.
received amount
amount. 11. Logs the completed
sale.
10. The Cashier
10
deposits the cash 103
received and
t t th
Expanded Use Case (4
( 4)
• Alternative Courses
• Line 2: Invalid identifier entered.
Indicate error
• Line 7: Customer didn’t have enough
cash Cancel sales transaction
cash.
• 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 104
– have alternatives for each subsection if
The End

105