Bắt đầu Nhận MO MO = “MUA” Phiên chơi hợp lệ? MO = “DD [Nguoi noi tieng]” Gửi MT:
Yeu cau cua Quy Khach chua thuc hien duoc do phien choi da het hieu luc. Phien
du doan bat dau luc 8:00 va ket thuc luc 23:59 hang ngay. Cam on Quy Khach da su
dung dich vu cua VinaPhone.
Đã dự đoán? Gửi MT:
Lenh MUA cua Quy Khach khong thanh cong do Quy Khach da du doan dung ten Nguoi noi tieng ngay DD/MM/YYYY. Ket qua nguoi chien thang se duoc thong bao
vao 8:00 DD/MM/YYYY. Cam on Quy Khach da su dung dich vu cua VinaPhone.
Đã mua quá 10 lần? Gửi MT:
Quy Khach da thuc hien lenh MUA vuot qua quy dinh cua dich vu trong ngay (Toi da 20 lan/ngay). De biet them chi tiet, Quy
Khach vui long lien he tong dai 9191 hoac truy cap website http:// nguoinoitieng.vinaphone.com.vn
Hết tiền? Gửi MT:
Tai khoan cua Quy Khach khong du de MUA thong tin nguoi noi tieng. Quy Khach
vui long nap them tien vao tai khoan va thu lai. Xin tran trong cam on.
Chưa mua thông tin?
Gửi MT:
Yeu cau cua Quy Khach chua duoc thuc hien. Quy Khach vui long soan MUA gui 1566 (1000dong/tin) de mua thong tin va
du doan ten Nguoi noi tieng. De biet them chi tiet, Quy Khach vui long lien he tong dai 9191 hoac truy cap website:
http://nguoinoitieng.vinaphone.vn Phiên chơi hợp
lệ?
Gửi MT:
Yeu cau cua Quy Khach chua thuc hien duoc do phien choi da het hieu luc. Phien du doan bat dau luc 8:00 va ket thuc luc 23:59 hang
ngay. Cam on Quy Khach da su dung dich vu cua VinaPhone.
Đáp án đúng
Gửi MT:
Rat tiec, Quy Khach da du doan sai ten Nguoi noi tieng ngay hom nay. Quy Khach vui long soan MUA gui 1566 (1000dong/ tin) de mua thong tin va du doan ten Nguoi noi tieng. De biet them chi tiet, Quy Khach vui long lien he tong dai 9191 hoac truy cap website: http://nguoinoitieng.vinaphone.com.vn
Gửi MT:
Chuc mung Quy Khach da du doan dung ten nguoi noi tieng ngay hom nay. Quy Khach dang co 99% co hoi gianh Nokia Lumina 525 tu chuong trinh Nhan dien nguoi noi tieng! Neu Quy Khach la
nguoi may man gianh duoc giai thuong Nokia Lumina 525 tu VinaPhone, Quy Khach se nhan duoc thong bao tu chuong trinh.
Cam on Quy Khach da su dung dich vu cua VinaPhone Phiên mới? Gửi thông báo
phiên chơi mới Kết thúc Y Y N Y N Y Y N Y N Y N N N Y Gửi MT: Nội dung gợi ý
N Kết thúc Kết thúc Y Y Trừ tiền 1000 VNĐ N
Hình 4.3 Luồng xử lý dịch vụ Nhận diện Ngƣời nổi tiếng
Tiến trình Tên gọi Mô tả
Bắt đầu Start Bắt đầu của một dịch vụ, hoặc một phiên dịch vụ Cấu hình:
- Id của dịch vụ
Kết thúc End Kết thúc của một dịch vụ
Trừ tiền X VNĐ
Debit Trừ tiền từ tài khoản thuê bao Cấu hình:
- X VNĐ Đầu vào:
- Số điện thoại 84xxxxxx, lấy từ tiến trình SMSIn
Đầu ra:
- Kết quả trừ tiền (thành công, hết tiền…)
Nhận MO
SMSIn Nhận tin nhắn từ thuê bao Đầu vào:
- Id của dịch vụ, lấy từ tiến trình Start Đầu ra:
- Tin nhắn MO nội dung X
- Số điện thoại thuê bao đã gửi tin 84xxxxx - Phiên hiện tại của dịch vụ, phục vụ cho các
tiến trình sau
Gửi MT Mẫu MT
SMSOut Gửi tin nhắn tới thuê bao Cấu hình:
- Mẫu tin nhắn MT nội dung X (ví dụ: Quy khach dang co <so_diem> diem)
Đầu vào:
- Số điện thoại thuê bao nhận tin 84xxxxxx, lấy từ tiến trình SMSIn
- Các tham số động lấy từ các tiến trình khác như AddPoint, GenerateTicket (ví dụ: điểm, mã dự thưởng) để thay thế trong mẫu tin nhắn MT
Lấy nội dung
SendContent Lấy nội dung trong module Quản trị nội dung của SDP
Cấu hình:
- Id của nội dung (không bắt buộc), nếu không cấu hình thì lấy theo tiêu chí
- Tiêu chí độ ưu tiên: lấy nội dung theo độ ưu tiên từ cao đến thấp
- Tiêu chí ngẫu nhiên: lấy nội dung một cách ngẫu nhiên
- Template của tin nhắn tới khách hàng, trong đó có chứa nội dung
Đầu vào:
- Số điện thoại thuê bao cần gửi nội dung 84xxxxx, lấy từ tiến trình SMSIn
Đầu ra:
- Id của nội dung - Chi tiết nội dung
Cộng X điểm
AddPoint Cộng điểm cho thuê bao Cấu hình:
- Số điểm cần cộng X Đầu vào:
- Số điện thoại thuê bao cần cộng 84xxxxx, lấy từ tiến trình SMSIn
- Phiên đang chơi, lấy từ tiến trình Start Đầu ra:
- Tổng số điểm trong phiên hiện tại của thuê bao
- Tổng số điểm trong toàn dịch vụ của thuê bao
Tạo mã dự thưởng
GenerateTicket Tạo mã dự thưởng cho thuê bao Cấu hình:
- Dạng mã dự thưởng, ví dụ có 5 chữ số - Số ticket tạo ra
Đầu vào:
- Số điện thoại thuê bao 84xxxxx, lấy từ tiến trình SMSIn
- Phiên đang chơi, lấy từ tiến trình Start Đầu ra:
- Mã dự thưởng vừa tạo
- Tổng số mã dự thưởng của thuê bao
MO = “X” MO giống “X Y”
CheckMO Kiểm tra tin nhắn MO do thuê bao gửi tới Cấu hình:
- Cú pháp cần so sánh, ví dụ “GOI Y”, “MUA”, “DD <nguoi_noi_tieng>”
- Cú pháp cần đưa vào xử lý để kiểm tra nội dung đáp án sau khi so sánh đúng, ví dụ <nguoi_noi_tieng>
Đầu vào:
- Tin nhắn MO, lấy từ tiến trình SMSIn Đầu ra:
- Kết quả đúng sai
Số MO = X?
CountMO Kiểm tra số tin nhắn thuê bao đã gửi tới theo một dạng cú pháp
Cấu hình:
- Cú pháp cần so sánh, ví dụ “GOI Y”, “MUA”, “DD <nguoi_noi_tieng>”
- Số lần xuất hiện X - Type: =, >, <, >=, <= Đầu vào:
- Số điện thoại thuê bao 84xxxxx, lấy từ tiến trình SMSIn
- Phiên hiện tại Đầu ra:
- Kết quả đúng sai
Hiệu lực phiên?
ValidatePeriod Kiểm tra thời điểm hiện tại phiên dịch vụ có hiệu lực không
Đầu vào:
- Cách 1: thông tin bắt đầu và kết thúc lấy từ tiến trình Start + End
- Cách 2: Id của phiên chơi, lấy từ tiến trình Start
Đầu ra:
- Kết quả đúng sai
Hết tiền?
CheckBalance Kiểm tra tài khoản thuê bao hết tiền hay không Đầu vào:
- Kết quả của tiến trình Debit Đầu ra:
- Kết quả đúng sai
Số nội dung = X?
CountContent Kiểm tra số nội dung đã gửi cho thuê bao trong phiên hiện tại, ví dụ số câu hỏi hay số gợi ý
Cấu hình
- Số lượng cần số sánh X
- Có cho phép kết thúc cuộc chơi trong phiên này nếu điều kiện đúng hay không?
Đầu vào:
- Phiên hiện tại
- Số điện thoại thuê bao 84xxxxx, lấy từ tiến trình SMSIn
Đầu ra:
- Kết quả đúng sai
Đáp án đúng?
CheckAnswer Kiểm tra đáp án của thuê bao đúng hay sai Cấu hình
- Có cho phép kết thúc cuộc chơi trong phiên này nếu điều kiện đúng hay không?
- Tin nhắn MO của thuê bao, lấy từ tiến trình SMSIn
- Id của nội dung đã gửi, lấy từ tiến trình SendContent
- Có cho phép kết thúc cuộc chơi trong phiên này nếu điều kiện đúng hay không?
Đầu ra:
- Kết quả đúng sai
Đã hoàn thành phiên chơi?
IsFinished Kiểm tra thuê bao đã hoàn thành phiên chơi hay chưa? (trả lời hết các câu hỏi trong ngày, hoặc đã dự đoán đúng).
Đầu vào:
- Số điện thoại thuê bao 84xxxxx, lấy từ tiến trình SMSIn
Đầu ra:
- Kết quả đúng sai
Bảng 4.4 Mô tả các tiến trình cơ bản
Ngoài ra, để liên kết giữa các tiến trình với nhau, cần có id cho từng tiến trình, và thêm các thuộc tính (cấu hình) liên kết như: tiến trình trước đó, tiến trình tiếp theo, tiến trình tiếp theo nếu kết quả đúng, tiến trình tiếp theo nếu kết quả sai.
Các tiến trình cơ bản trong Bảng 4.4 sẽ được chi tiết hóa trong mục 4.2.3 để có thể lập trình được.
4.2.3 Thiết kế SMS Platform
4.2.3.1 Xây dựng các tiến trình và các tham số
Dựa vào Bảng 4.4 có thể xây dựng chi tiết các tiến trình và liệt kê các tham số sử dụng cho cấu hình, đầu vào và đầu ra của hệ thống
STT Tên tham số Mô tả ý nghĩa
Tham số cấu hình
1 id id của tiến trình, là tham số có tính duy nhất, để phân biệt giữa các tiến trình
2 from id của tiến trình trước đó
3 to id của tiến trình tiếp theo (đối với các tiến trình hành động) 4 toY id của tiến trình tiếp theo nếu điều kiện kiểm tra đúng (đối
với các tiến trình điều kiện)
5 toN id của tiến trình tiếp theo nếu điều kiện kiểm tra sai (đối với các tiến trình điều kiện)
Start)
7 amount Số tiền trừ vào tài khoản thuê bao trong tiến trình Debit 8 mtTemplate Cấu hình định dạng tin nhắn gửi tới thuê bao trong tiến trình
SMSOut và SendContent
9 contentId id của nội dung cụ thể cần lấy trong tiến trình SendContent 10 sortType Cách lấy nội dung trong tiến trình SendContent (1: theo id, 2:
theo độ ưu tiên, 3: lấy ngẫu nhiên)
11 point Điểm cộng thêm trong tiến trình AddPoint
12 format Định dạng mã dự thưởng trong tiến trình GenerateTicket, có dạng XXXXXX
13 ticketNum Số mã dự thưởng tạo ra trong tiến trình GenerateTicket 14 template Mẫu để so sánh trong tiến trình CheckMO và CountMO 15 syntax Cú pháp cần lấy ra từ MO để kiểm tra đáp án của nội dung
sau này
16 type Loại so sánh trong tiến trình CountMO (1: so sánh bằng, 2: so sánh nhỏ hơn, 3: so sánh lớn hơn, 4: so sánh nhỏ hơn hoặc bằng, 5: so sánh lớn hơn hoặc bằng). So sánh ở đây là so sánh số lượng MO (tin nhắn thuê bao gửi tới) với một tham số cấu hình (là tham số count)
17 count Số lượng cần so sánh trong tiến trình CountMO
18 isFinished Có cho phép kết thúc bài chơi trong phiên đó hay không (trong trường hợp đã dự đoán đúng, hoặc đã chơi một số lượng câu hỏi cho phép), sử dụng trong tiến trình CheckAnswer, CountContent
Tham số đầu vào/đầu ra 1 periodId id của phiên chơi hiện tại 2 msisdn Số điện thoại người chơi
3 moContent Nội dung tin nhắn người chơi gửi tới hệ thống 4 moId Id của tin nhắn gửi tới, do hệ thống lưu lại
5 moSyntax Cú pháp đã lọc từ MO để kiểm tra đáp án của nội dung sau này (ví dụ DD My Tam thì chỉ cần lấy thông tin My Tam để kiểm tra đáp án)
6 ticket Mã dự thưởng lần cuối cùng được lưu 7 totalTicket Tổng số mã dự thưởng hiện tại
8 periodPoint Số điểm trong phiên hiện tại 9 totalPoint Tổng số điểm của toàn dịch vụ 10 chargeResult Kết quả tính tiền
11 contentId Id của nội dung cuối cùng gửi cho người chơi 12 content Nội dung text cuối cùng gửi cho người chơi
13 isFinished Bài chơi đã dừng hay chưa 14 startTime Thời gian bắt đầu phiên hiện tại 15 endTime Thời gian kết thúc phiên hiện tại
Bảng 4.5 Các tham số cấu hình, đầu vào và đầu ra
Các tiến trình được định nghĩa dưới dạng XML (Extensible Markup Language), trong đó chứa các tham số được liệt kê trong Bảng 4.5
Các tiến trình được kết nối với nhau thông qua các tham số from, to, toY và toN. Dựa trên các kịch bản dịch vụ và các luồng xử lý đã phân tích Hình 4.1, Hình 4.2, Hình 4.3 có thể xây dựng được các cấu hình kịch bản dịch vụ bằng cách sử dụng ngôn ngữ XML
Công việc tiếp theo của phần thiết kế là thiết kế cơ sở dữ liệu chứa các thông tin phục vụ các kịch bản SMS. Chi tiết thiết kế của cơ sở dữ liệu được trình bày trong mục 4.2.3.2
4.2.3.2 Thiết kế cơ sở dữ liệu
Thông tin cần lưu của các kịch bản bao gồm:
- Thông tin về nội dung: các câu hỏi, các gợi ý, đáp án phục vụ người chơi. Thông tin này được cấu hình trên module Quản lý nội dung của SDP, để phục vụ cho mô phỏng, cơ sở dữ liệu tái hiện lại các nội dung này một cách đơn giản thông qua hai bảng “CONTENT” và “CONTENT_RESULT”
- Thông tin về dịch vụ: cấu hình dịch vụ, phiên chơi. Thông tin này cũng được lưu trên module Quản lý dịch vụ của SDP, để phục vụ cho mô phỏng, cơ sở dữ liệu tái hiện lại các thông tin này một cách đơn giản thông qua hai bảng “SERVICE” và “SERVICE_PERIOD”
- Thông tin về các tin nhắn người chơi gửi tới chương trình - Thông tin về các tin nhắn chương trình gửi tới người chơi - Thông tin về giao dịch điểm của người chơi
- Thông tin về giao dịch mã dự thưởng của người chơi - Thông tin về giao dịch gửi nội dung cho người chơi
- Trạng thái hiện tại của người chơi dịch vụ: số điểm trong phiên, số mã dự thưởng, tổng số điểm…
Hình 4.4 mô tả chi tiết thiết kế cơ sở dữ liệu bao gồm các bảng và mối quan hệ giữa các bảng
Hình 4.4 Thiết kế cơ sở dữ liệu
Bảng SERVICE: Bảng lưu thông tin dịch vụ
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của dịch vụ, là khóa chính của bảng Có
name varchar(255) Tên của dịch vụ Có
description varchar(1024) Mô tả dịch vụ Không
Bảng 4.6 Bảng SERVICE
Bảng SERVICE_PERIOD: Bảng lưu thông tin phiên của dịch vụ
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của phiên Có
service_id int(10) Id của dịch vụ chứa phiên Có
start_time datetime Thời điểm bắt đầu phiên Có
end_time datetime Thời điểm kết thúc phiên Có
Bảng 4.7 Bảng SERVICE_PERIOD
Bảng CONTENT: Bảng lưu thông tin nội dung (câu hỏi, gợi ý)
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của nội dung Có
content varchar(4000) Nội dung text (không dấu) Có
priority int(10) Độ ưu tiên Không
service_id int(10) Id của dịch vụ Có
Bảng 4.8 Bảng CONTENT
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của kết quả Có
content_id int(10) Id của nội dung gắn với kết quả Có
content varchar(4000) Kết quả Không
content_corect varchar(4000) Kết quả đúng Không
content_wrong varchar(4000) Kết quả sai Không
syntax_correct varchar(4000) Cú pháp đúng Có
syntax_wrong varchar(4000) Cú pháp sai Không
Bảng 4.9 Bảng CONTENT_RESULT
Bảng USER_SERVICE: Bảng lưu thông tin sử dụng dịch vụ của người chơi
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của bảng Có
service_id int(10) Id của dịch vụ Có
total_point int(10) Tổng số điểm của người chơi Không period_point int(10) Tổng số điểm của người chơi trong
phiên hiện tại
Không total_ticket int(10) Tổng số mã dự thưởng của người
chơi
Không current_period_id int(10) Id của phiên hiện tại Không msisdn varchar(20) Số điện thoại của người chơi Có ticket varchar(255) Mã dự thưởng đã được cấp gần đây
nhất
Không is_period_finished tinyint(1) Đã kết thúc bài chơi trong phiên hay
chưa
0: chưa kết thúc, có thể tiếp tục chơi 1: đã kết thúc, sang phiên tiếp theo mới được chơi tiếp
Có
Bảng 4.10 Bảng USER_SERVICE
Bảng USER_CONTENT_LOG: Bảng lưu các nội dung hệ thống gửi cho người chơi
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của bảng Có
msisdn varchar(20) Số điện thoại người chơi Có
content_id int(10) Id của nội dung gửi cho người chơi Có mt_id int(10) Id của tin nhắn MT gửi tới người chơi có
chứa nội dung gửi
Không
sent_time datetime Thời gian hệ thống gửi tin Không
Bảng 4.11 Bảng USER_CONTENT_LOG
Bảng POINT_TRANSACTION: Bảng lưu các giao dịch điểm của người chơi
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của bảng Có
msisdn varchar(20) Số điện thoại người chơi Có
period_id int(10) Id của phiên chơi Có
point int(10) Điểm cộng thêm cho người chơi Có
create_date datetime Thời gian hệ thống cộng điểm Có mo_id int(10) Id của tin nhắn MO người chơi gửi tới
chương trình có liên quan đến việc cộng điểm
Có
Bảng 4.12 Bảng POINT_TRANSACTION
Bảng TICKET_TRANSACTION: Bảng lưu các giao dịch mã dự thưởng của người chơi
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của bảng Có
msisdn varchar(20) Số điện thoại người chơi Có
period_id int(10) Id của phiên chơi Có
ticket varchar(20) Mã dự thưởng cấp cho người chơi Có