Tải bản đầy đủ
a) Các ứng dụng và công cụ cần gửi những thông báo đến những khách hàng trong một danh sách nào đó. Ứng dụng gửi nội dung cần gửi hoặc những lệnh nào đó đến dịch vụ máy chủ xử lý SMS (MCDVSMS). Tuỳ vào loại thông điệp, MCDVSMS có thể đọc thông tin từ cơ s

a) Các ứng dụng và công cụ cần gửi những thông báo đến những khách hàng trong một danh sách nào đó. Ứng dụng gửi nội dung cần gửi hoặc những lệnh nào đó đến dịch vụ máy chủ xử lý SMS (MCDVSMS). Tuỳ vào loại thông điệp, MCDVSMS có thể đọc thông tin từ cơ s

Tải bản đầy đủ

dưới dạng một dịch vụ hệ thống. Đối với hệ điều hành Windows họ NT, đó là
dịch vụ NT. Mục đích xây dựng MCDVSMS dưới dạng dịch vụ hệ thống là để
đảm bảo sự ổn định trong quá trình vận hành và không cần phải đăng nhập hệ
thống để chạy chương trình. Có thể thiết lập để dịch vụ NT chạy theo những
thông số cho trước với những quyền hạn khác nhau.
Công việc của MCDVSMS là gửi lệnh AT đến mô-đem, đọc trả lời từ mô
đem, xử lý kết quả đó và có thể gửi lệnh đến mô-đem tuỳ thuộc vào kết quả xử
lý. Cần giải quyết việc đồng bộ hoá quá trình gửi lệnh/nhận kết quả và xử lý
kết quả để không xảy ra lỗi và tranh chấp trong hệ thống MCDVSMS. Các môi
trường phát triển phần mềm theo mặc định thường tạo ra một chương trình
mới chỉ bao gồm một tiến trình và quá trình xử lý câu lệnh trong chương trình
xảy ra một cách nối tiếp. Khi đó, chương trình có thể làm việc không hiệu quả
và đặc biệt có thể gây ra lỗi trong một số trường hợp. Cách giải quyết là xây
dựng chương trình đa tiến trình (multi-threading) và dùng các đối tượng giúp
đồng bộ hoá quá trình truy cập đến một tài nguyên dùng chung của nhiều tiến
trình khác nhau như mutex, semaphore, event, interlock trong thư viện
WINAPI. Các môi trường lập trình ngày nay đều có các lớp khác nhau triển
khai các chức năng tương ứng. Một ví dụ đơn giản cho trường hợp không tổ
chức đồng bộ hoá giữa các tiến trình. Nếu chương trình có hai tiến trình T1 và
T2 sử dụng chung một biến n – chẳng hạn, số lượng SMS cần gửi. Để tăng giá
trị của n lên 2 đơn vị, T1 phải đọc n vào thanh ghi, tăng giá trị thanh ghi lên
hai đơn vị, sau đó lưu n lại trong bộ nhớ với giá trị mới. Trong thời gian đó,
tiến trình T2 tăng n lên một đơn vị và lưu vào bộ nhớ trước khi T1 lưu n vào
bộ nhớ. Như vậy, kết quả của T2
Nếu MCDVSMS chỉ làm việc với một mô-đem thì đơn giản hơn nhiều so
với trường hợp đồng thời nhiều mô-đem. Tuy nhiên, cũng cần xây dựng ít nhất
hai tiến trình khác nhau, một phụ trách việc gửi lệnh đến mô-đem, một phụ
trách đọc kết quả trả lại từ mô-đem và xử lý khi làm việc với chỉ một mô-đem.
Nếu không thực hiện tốt, chương trình có thể gửi đến mô-đem các lệnh khác
nhau trong khi chưa đọc hết hoặc chưa kịp xử lý kết quả từ mô-đem. Điều này
41

sẽ gây nên mất kết quả hoặc/và gây nên các lỗi xung đột trong sử dụng môđem, chẳng hạn tràn bộ nhớ đệm, mô-đem xử lý không kịp,…Thậm chí có thể
gây ra lỗi truy cập đến các tài nguyên dùng chung khác, chẳng hạn danh sách
lệnh gửi đến mô-đem.
Tương tự, nếu MCDVSMS làm việc với đồng thời nhiều mô-đem, thì mỗi
phân hệ làm việc với một mô-đem đều phải có ít nhất hai tiến trình. Ngoài ra,
để MCDVSMS sử dụng các mô-đem được hiệu quả, cần phải tổ chức phân bổ
công việc giữa các mô-đem. Nghĩa là tối thiểu, các phân hệ sẽ sử dụng chung
danh sách SMS cần gửi. Cũng có thể tổ chức hệ thống theo kiểu mỗi phân hệ
đọc kết quả từ mô-đem và gửi nó đến CSDL hoặc mỗi phân hệ là một dịch vụ
NT khác nhau, các phân hệ khác khi rỗi sẽ truy cập CSDL để đọc danh sách kết
quả và xử lý. Như thế, vấn đề tương tranh giữa các phân hệ trong việc đọc
danh sách kết quả cũng như danh sách SMS cần gửi sẽ được hệ quản trị CSDL
giải quyết thay. Tuy nhiên, như vậy sẽ tăng ít nhất gấp đôi số lượng truy cập
đến CSDL từ hệ thống. Hệ quản trị CSDL phải xử số lượng lệnh rất lớn để xử lý
một truy cập, có thể tương đương với tổng số lượng lệnh của cả hệ thống
MCDVSMS, dù là truy cập đơn giản. Khi đó, hiệu quả tổng quan không cao. Vì
thế, tổ chức MCDVSMS theo kiểu đa phân hệ đa tiến trình, các tiến trình sử
dụng những tài nguyên dùng chung, để phân bổ công việc giữa các mô-đem là
giải pháp tối ưu nhất.
2.4.
2.4.1.

Phân tích hệ thống
Lưu đồ hệ thống

42

Hình 2.5. Lưu đồ hệ thống
2.4.2.

Biểu đồ USE CASE
UML đưa ra khái niệm Use Case để nắm bắt các yêu cầu của học sinh,

sinh viên (người sử dụng). UML sử dụng biểu đồ Use case (Use Case Diagram)
để nêu bật mối quan hệ cũng như sự giao tiếp với hệ thống. Qua phương pháp
mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thống
sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía hệ thống
(tức là Use case). Các tác nhân và các Use case được mô hình hóa cùng các mối
quan hệ và được miêu tả trong biểu đồ Use case của UML. Mỗi một Use case
được mô tả trong tài liệu, và nó sẽ đặc tả các yêu cầu của khách hàng . User
chờ đợi điều gì ở phía hệ thống mà không hề để ý đến việc chức năng này sẽ
được thực thi ra sao?
43

Nhận diện tác nhân và use-case
Hệ thống được chia làm hai phần: một phần dành cho người dùng và
một phần dành cho người quản trị hệ thống. Danh sách các tác nhân và
UseCase:
Tác nhân

UseCase
Gửi tin nhắn tra cứu

Người dùng

Nhận tin nhắn từ tổng đài

Người quản trị hệ thống

Quản lý tin nhắn đến
Thống kê hệ thống

Biểu đồ Use-Case
- Đối với tác nhân người dùng:

Gui tin nhan tra cuu

Nguoi dung
Nhan tin nhan tu tong dai

Hình 2.6. Biểu đồ Use Case cho tác nhân người dùng
- Đối với tác nhân người quản trị hệ thống:

44

Hình 2.7. Biểu đồ Use Case cho tác nhân người quản trị hệ thống
Chú thích: mối liên kết giữa tác nhân cha và tác nhân con là mối liên kết
extend.
2.4.3.

Đặc tả các USE CASE
a) UC Gửi tin nhắn tra cứu
- Mục đích: Người dùng soạn tin nhắn tra cứu gửi đến hệ thống
- Tác nhân: Học sinh, sinh viên
- Mô tả chung: Người dùng muốn tra cứu điểm của mình trong quá
trình học tập tại trường. Khi đó người dùng sẽ soạn tin theo cú pháp
“diem mamon masv” để thực hiện việc tra cứu.
- Luồng sự kiện chính:
Hành động của tác nhân
1.Gửi tin nhắn tra cứu.

Phản ứng của hệ thống
2. Nhận tin nhắn từ người dùng.
3.Tiến hành tra cứu theo thông
tin mà người dùng gửi đến, sau
đó gửi thông báo đến cho người
dùng về việc

yêu cầu tra cứu

điểm có thành công hay không?
45

4.Nhận tin nhắn từ hệ thống

- Luồng sự kiện phụ :
Trong khi người dùng gửi tin nhắn đến tổng đài với thông tin bắt
buộc mà hệ thống yêu cầu người dùng phải gửi lên hệ thống như:
mamon, masv. Nếu người dùng nhập sai cú pháp thì hệ thống gửi thông
báo “Ban nhap khong dung dinh dang \"DIEM MAMON MASV "\ Xin thu
lai.” Hoặc nếu người dùng gửi tin nhắn với thông tin không có trong
CSDL thì hệ thống sẽ thông báo “Thong tin tra cuu khong chinh xac. Xin
thu lai”. Ngược lại hệ thống sẽ gửi kết quả điểm của môn đó cho người
dùng .

-

Biểu đồ trình tự:

: Nguoi dung

1 : Soan tin nhan tra cuu()

: CSDL

<>
: He thong tra cuu

<>
: DT nguoi dung

2 : Gui tin nhan den he thong()

5 : Gui tin nhan thong bao ket qua()

3 : Tra cuu diem()

4 : Ket qua tra cuu()

6 : Nhan tin nhan tu he thong()

Hình 2.8. Biểu đồ trình tự cho UC gửi tin nhắn tra cứu

46

-

Biểu đồ cộng tác:

Hình 2.9. Biểu đồ cộng tác cho UC gửi tin nhắn tra cứu
b)

UC Nhận tin nhắn từ hệ thống

- Mục đích: Người dùng nhận tin nhắn từ hệ thống
- Tác nhân: Học sinh, sinh viên
- Mô tả chung: Khi hệ thống nhận được yêu cầu tra cứu của người dùng
thì hệ thống sẽ tiến hành tra cứu gửi thông báo đến người dùng. Thông
báo đó có thể là kết quả mà người dùng cần hoặc là hệ thống thông báo
nhắn tin không đúng định dạng hoặc thông tin tra cứu không chính xác.
Khi đó người dùng chỉ việc hiển thị tin nhắn và xem như bình thường.
Nếu người dùng mà soạn tin sai cú pháp thì có thể gửi yêu cầu khác lên
hệ thống.
c) UC Quản lý tin nhắn đến
- Mục đích: Người quản trị muốn xem hoặc xóa tin nhắn đến hệ thống.
- Tác nhân: Người quản trị hệ thống.
- Mô tả chung: Khi người dùng gửi tin nhắn đến hệ thống thì tin nhắn
được lưu trong bảng tb_Message. Khi hệ thống bắt đầu hoạt động thì
Form giao diện chính của hệ thống sẽ hiển thị toàn bộ thông tin tin nhắn
đến. Người quản trị có thể xem hoặc xóa từng tin nhắn.
47

- Luồng sự kiện chính: Người quản trị hệ thống muốn xóa tin nhắn nào
sẽ chọn tin nhắn đó và hệ thống lập tức xóa tin nhắn đó đi.
d) UC Xóa tin nhắn đến
- Mục đích: Người quản trị muốn xóa tin nhắn đến hệ thống.
- Tác nhân: Người quản trị hệ thống.
- Mô tả chung: Khi người dùng gửi tin nhắn đến hệ thống thì tin nhắn
được lưu trong bảng tb_Message. Khi hệ thống bắt đầu hoạt động thì
Form giao diện chính của hệ thống sẽ hiển thị toàn bộ thông tin tin nhắn
đến. Người quản trị có thể xóa từng tin nhắn.
- Luồng sự kiện chính:
Hành động của tác nhân
Phản ứng của hệ thống
1.Người quản trị chọn tin nhắn cần
xóa.
2. Hệ thống xóa tin nhắn đã được
chọn và cập nhật lại trong CSDL.

- Biểu đồ trình tự:
: Nguoi quan tri he thong

<>
: Frm giao dien

1 : Chon tin nhan muon xoa()

<>
: Ctrl dieu khien HT

2 : Xu ly yeu cau xoa tin nhan()

3 : Xoa tin nhan()

Hình 2.10. Biểu đồ trình tự cho UC Quản lý tin nhắn đến
- Biểu đồ cộng tác:

48

: CSDL

Hình 2.11. Biểu đồ cộng tác cho UC Quản lý tin nhắn đến
e) UC Thống kê hệ thống
- Mục đích: Người quản trị muốn thống kê hệ thống số tin nhắn đến và
số thuê bao.
- Tác nhân: Người quản trị hệ thống.
- Mô tả chung: Khi người dùng gửi tin nhắn đến hệ thống thì tin nhắn
được lưu trong bảng tb_Message. Khi hệ thống bắt đầu hoạt động thì
Form giao diện chính của hệ thống sẽ hiển thị toàn bộ thông tin tin nhắn
đến. Người quản trị có thể xem có bao nhiêu người dùng hệ thống và có
bao nhiêu tin nhắn đến hệ thống.
- Luồng sự kiện chính:
Hành động của tác nhân
1.Người quản trị chọn View statistics

- Biểu đồ trình tự:

49

Phản ứng của hệ thống
2. Hệ thống sẽ thống cho số người sử
dụng hệ thống và số tin nhắn đến hệ
thống.

: Nguoi quan tri he thong

<>
: Form giao dien he thong

1 : Nguoi quan tri chon View statistics()

<>
: Ctrl_dieu khien he thong

<>
: CSDL

2 : Gui yeu cau muon xem thong ke()
3 : Lay du lieu()
5 : Tra ve du lieu thong ke cho nguoi dung()
4 : Tra ve du lieu()
6 : Hien thi thong tin thong ke()

Hình 2.12. Biểu đồ trình tự cho UC Thống kê hệ thống
- Biểu đồ cộng tác:

Hình 2.13. Biểu đồ cộng tác cho UC Thống kê hệ thống

2.4.5.

Biểu đồ lớp
50

a) Biểu đồ lớp cho Uses Case Người dùng
<>
giao dien dien thoai
+id
+so dien thoai
+ngay gui
nguoi dung

+luu tin nhan()
+sua tin nhan()
+xoa tin nhan()

<>
he thong tra cuu

<>
CSDL

+kiem tra tin nhan()
+nhan tin nhan()
+gui tin nhan()

+tin nhan da gui
+tin nhan da nhan

Hình 2.14. Biểu đồ lớp cho UC Người dùng
b) Biểu đồ lớp cho Uses Case Người quản trị hệ thống
<>
form giao dien

nguoi quan tri he thong

+tin nhan nguoi dung
+so dien thoai nguoi dung
+ngay nhan
+id
+diem

ctrl dieu khien he thong
+gui tin nhan()
+nhan tin nhan()
+xoa tin nhan()
+tra cuu diem()

+gui tin nhan()
+quan ly tin nhan()

Hình 2.15. Biểu đồ lớp cho UC Người quản trị hệ thống

2.4.6.

Biểu đồ Activity(Biểu đồ hoạt động)

51

<>
CSDL
+tin nhan da gui
+tin nhan da nhan
+co so du lieu diem