Traffic warning reportv7

Hệ thống Cảnh Báo Giao Thông - 1-
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
KHOA CÔNG NGHỆ THÔNG TIN I
ĐỒ ÁN
TỐT NGHIỆP ĐẠI HỌC
Đề tài: Xây Dựng Hệ Thống Cảnh Báo Giao Thông
Giảng viên hướng dẫn : ThS. Nguyễn Thị Ngọc Vinh
Sinh viên thực hi ện: Nguyễn Đức Hạnh
Lớp : D08CNPM2
Khoá : 2008-2012
Hệ : Đại học chính quy
Hà Nội, tháng 12 /2012
GVHD: Nguyễn Thị Ngọc Vinh SVTH: Nguyễn Đức Hạnh - D08CNPM2

Lời mở đầu

Mục lục
CHƯƠNG 1: GIỚI THIỆU BÀI TOÁN ................................................................................... 7
1.1 Đặt vấn đề .................................................................................................................. 7
1.2 Hệ thống GPS và ứng dụng ............................................................................................. 8
1.2.1 Một số khái niệm ...................................................................................................... 8
1.2.2 Xác định tọa độ ......................................................................................................... 9
1.2.3 Ứng dụng GPS ........................................................................................................ 10
CHƯƠNG 2: TỔNG QUAN VỀ HỆ ĐIỀU HÀNH ANDROID ............................................ 11
2.1 Giới thiệu chung ............................................................................................................ 11
2.2 Phát triển ứng dụng trên Android platform ................................................................... 11
2.3 Các thành phần của Android 2.2.................................................................................... 13
2.3.1 Activity ................................................................................................................... 13
2.3.2 Intent ....................................................................................................................... 14
2.3.3 Android Service ...................................................................................................... 15
2.3.4 Content Provider ..................................................................................................... 19
2.3.5 Broadcast Receiver ................................................................................................. 20
2.3.6 Control View .......................................................................................................... 20
2.4 Giới thiệu về Google Map API ...................................................................................... 25
2.5 Công nghệ Servlet.......................................................................................................... 26
CHƯƠNG 3: PHÂN TÍCH THIẾT KẾ HỆ THỐNG ............................................................. 28
3.1 Mục tiêu xây dựng hệ thống .......................................................................................... 28
3.2 Xác định yêu cầu hệ thống............................................................................................. 28
3.2.1 Các chức năng của hệ thống ................................................................................... 28
3.2.2 Các Actor tương tác với hệ thống ........................................................................... 28
3.2.3 Sơ đồ UseCase của hệ thống................................................................................... 29
3.2.4 Xây dựng kịch bản cho các usecase........................................................................ 30
3.3 Thiết kế hệ thống ........................................................................................................... 40
3.3.1 Atrribute cho các lớp .............................................................................................. 40
3.3.2 Operation ................................................................................................................ 41
3.3.3 Biểu đồ lớp chi tiết.................................................................................................. 42
3.3.4 Hiện thực hóa use case: .......................................................................................... 42

3.3.5 Biểu đồ trạng thái.................................................................................................... 48
3.4 Kiến trúc hệ thống ......................................................................................................... 49
3.4.1 Lựa chọn hình trạng mạng (topology) của hệ thống:.............................................. 49
3.4.2 Truyền dữ liệu giữa Client Server .......................................................................... 51
3.4.3 Lựa chọn công nghệ cho các tầng........................................................................... 51
3.4.4 Xử lý lư u trữ với cơ sở dữ liệu quan hệ .................................................................. 51
CHƯƠNG 4: CÀI ĐẶT VÀ TRIỂN KHAI HỆ THỐNG ....................................................... 52
4.1 Cấu hình phần cứng thử nghiệm .................................................................................... 52
4.2 Cài đặt triển khai hệ thống ............................................................................................. 52
4.3 Sử dụng và đánh giá k ết quả thử nghiệm....................................................................... 52
4.3.1 Chức năng thêm Cảnh báo:..................................................................................... 53
4.3.2 Tra cứu cảnh báo trong khu vực ............................................................................. 56
4.3.3 Tra cứu cảnh báo thông qua Google Map: ............................................................. 58
4.3.4 Theo dõi cảnh báo ở gần người dùng: .................................................................... 59
4.3.5 Phê duyệt cảnh báo: ................................................................................................ 60

DANH MỤC CÁC BẢNG, SƠ ĐỒ, HÌNH

KÍ HIỆU CÁC CỤM TỪ VIẾT TẮT

CHƯƠNG 1: GIỚI THIỆU BÀI TOÁN
1.1 Đặt vấn đề
Giao thông hiện tại đang là một vấn đề nan giải ở các đô thị lớn của Việt Nam. Nhiều
tổ chức, ban ngành và cả xã hội đang cùng chung tay tìm giải pháp khắc phục. Bộ giao
thông cũng đã tích cực trong việc nâng cấp, phát triển cơ sở hạ tầng và áp dụng nhiều giải
pháp nhằm giảm thiểu số lượng người tham gia giao thông trên các tuyến đường chính.
Tuy nhiên tình trạng tắc nghẽn giao thông vẫn thường xuyên xảy ra. Ngoài ra các trục trặc
của cơ sở hạ tầng vẫn hàng ngày đe dọa sự an toàn của người tham gia thông.
Ở các thành phố lớn, người tham gia giao thông phải đối mặt với rất nhiều vấn đề. Một
vấn đề mà mọi người dân sống ở các thành phố lớn đều từng trải qua đó là ùn tắc giao
thông. Ùn nghẽn giao thông gây thiệt hại không nhỏ cho người tham gia giao thông nói
riêng và cả xã hội nói chung. Hàng ngày hàng giờ nó tiêu tốn thời gian, công sức, ảnh
hướng xấu đến sức khỏe và cả tinh thần của những người tham gia giao thông.
Ví dụ ở Hà Nội, hàng ngày có ít nhất hàng trăm nghìn người phải tốn khá nhiều thời
gian ở các nút tắc đường. Nhiều tuyến đường ùn tắc đến hàng giờ. Giả sử mỗi ngày có
100.000 người, gặp phải tình trạng tắc đường và mỗi người tốn 30phút để trải qua tuyến
đường tắc đó, thì tổng thời gian tốn kém cho tắc đường một năm là hơn 18 triệu giờ,
tương đương 1800 năm. Tiếp tục, giả sử thu nhập trung bình mỗi người là 20.000vnđ/giờ
thì mỗi năm tổng số tiền hao phí là hơn 100 tỷ vnđ. Số tiền này thực sự rất lớn so với số
tiền 100triệu để xây một trường học cho trẻ em huyện miền núi Sapa. Trên đây chỉ là con
số ước lượng dựa trên thu nhập bình quân và tình hình giao thông của Hà Nội. Tất nhiên
với thành phố trên 7 triệu dân như Hà Nội thì con số thực sẽ lớn hơn. Qua đó ta có thể
thấy sự thiệt hại do ùn tắc giao thông gây ra là không nhỏ.
Bên cạnh đó, tai nạn giao thông cũng là một vấn đề nhức nhối của xã hội. Theo thống
kê không đầy đủ của bộ giao thông, trong 8 tháng đầu năm 2012, tính trên địa bàn Hà Nội
đã xảy ra 439 vụ tai nạn giao thông đường bộ, đường sắt khiến 366 người thiệt mạng và
210 người bị thương. Tuy số người thiệt mạng đã giảm 87 người so với cùng kỳ năm
2011, nhưng đây cũng là một con số không nhỏ. Đặc biệt, có nhiều vụ tai nạn giao thông
không đáng có, do người tham gia giao thông chủ quan và thiếu thông tin về các sự cố,
cảnh bảo điểm nguy hiểm.
Tất cả các vấn đề trên sẽ ít nhiều được giảm thiểu nếu người tham gia giao thông có
một kênh thông tin về các điểm giao thông có vấn đề. Đây không phải là một giải pháp
mới. Hiện tại đài phát thanh Hà Nội cung cấp kênh VOV Giao Thông, cung cấp thông tin
các điểm tắc đường cho người tham gia giao thông vào giờ cao điểm. Tuy nhiên kênh
thông tin này có một số nhược điểm. Thứ nhất là thông tin cung cấp một chiều, người
tham gia giao thông phải theo dõi chương trình liên tục để chờ nhận được thông tin về

điểm giao thông cần biết. Thứ 2 do cung cấp qua hình thức phát thanh quảng bá nên VOV
chỉ có đủ thời gian để cung cấp các thông tin chung nhất. Và cuối cùng là nguồn cung cấp
thông tin là do cộng tác viên của VOV và người dân gọi điện. Với nguồn tin từ người dân
qua điện thoại thì khó có thể xác thực được tính chính xác. Ngày nay, khi số lượng người
sử dụng smartphone tăng nhanh chóng, phát triển hệ thống cảnh báo giao thông trên
smartphone thì tất cả các hạn chế trên sẽ được cải thiện.
Mục tiêu của đề tài là xây dựng một hệ thống cung cấp thông tin cảnh báo giao thông
trên smart phone. Hệ thống này sẽ khắc phục được 3 nhược điểm của kênh thông tin phát
thanh như đã trình bày ở trên.
 Cung cấp thông tin và cảnh bảo mọi lúc. Dựa vào hệ thống định vị toàn cầu
GPS, ứng dụng có thể xác định được vị trí người sử dụng và khoảng cách từ họ
đến vị trí những điểm đang ùn tắc, nguy hiểm… Từ đó sẽ đưa ra những cảnh
báo phù hợp. Google cũng cung cấp Google Map API, một thư viện giúp hiển
thị vị trí người dùng và vị trí các cảnh bảo trên bản đồ.
 Cung cấp nguồn thông tin đầy đủ và thuận tiện. Thông qua ứng dụng Cảnh Báo
Giao Thông, người sử dụng có thể theo dõi mọi thông tin cảnh báo bất kỳ lúc
nào của hệ thống và từ những người tham gia giao thông khác cung cấp. Từ
thông tin các tuyến đường đang ùn tắc, các điểm nguy hiểm, ổ gà, hỏng đường,
đèn tối…
 Tăng khả năng xác thực qua hình ảnh. Ứng dụng cảnh báo giao thông cung cấp
chức năng gửi cảnh báo giao thông kèm hình ảnh. Điểm quan trọng là ảnh bắt
buộc phải chụp qua ứng dụng. Sau khi được gửi đến server, cảnh báo sẽ được
kiểm duyệt một lần nữa trước khi cung cấp công khai.
Trước khi đi sâu vào ứng dụng, chúng ta sẽ tìm hiểu hệ thống GPS và nền táng
Android cũng như ứng dụng của chúng trong việc xây dựng hệ thống Cảnh Báo Giao
Thông.
1.2 Hệ thống GPS và ứng dụng
1.2.1 Một số khái ni ệm
Một máy thu GPS sẽ tính toán vị trí của nó bằng cách xác định chính xác thời gian tín
hiệu gửi bằng vệ tinh GPS ở ngoài không gian tới nó. Để làm được việc này thì máy thu
GPS phải nhìn nhấy ít nhất 3 vệ tinh GPS và thực hiện tính toán xác định vị trí của mình
bằng cách sử dụng các thông tin từ vệ tinh GPS. Quá trình này sẽ dựa trên một nguyên lý
của toán học đơn giản. Bên cạnh đó GPS cần biết khoảng cách từ các vệ tinh đến vị trí
cần xác định trên mặt đất nhờ công thức: S = v * t
Để thực hiện việc tính toán trên, các máy thu GPS phải biết hai thứ tối thiểu: vị trí của
ít nhất 3 vệ tinh và khoảng cách giữa các máy thu GPS đến từng vệ tinh đó. Bằng cách

phân tích sóng điện từ tần số cao, công sất cực thấp từ vệ tinh, máy thu GPS sẽ có thể tính
toán ra được hai điều đó, hay máy thu có thể tính toán được khoảng cách dựa vào khoảng
thời gian cần thiết để tín hiệu đến được máy thu.
Nhiều đơn vị tín hiệu GPS được thu nhận thì sẽ cho thấy các thông tin như hướng và
tốc độ… bị thay đổi.
Theo nguyên tắc là chỉ cần 3 vệ tinh là đủ để xác định vị trí của máy thu GPS. Nhưng
có những yếu tố khác làm ảnh hưởng tới chất lượng thu nhận tín hiệu của vệ tinh, do đó
cần dùng từ 4 hoặc nhiều hơn thế nữa để có thể xác định được chính xác hơn về vị trí (với
sai số nhở hơn).
1.2.2 Xác định tọa độ
Giả sử máy thu GPS sử dụng dữ liệu từ 4 tín hiệu của 4 vệ tinh thu được, máy thu đó
có thể xác định thời gian gửi và vị trí của các vệ tinh đó.
Với x,y,z là các thành phần về vị trí trong tọa độ và thời gian được gửi đi là t vậy ta
có các tập tín hiệu tới là:
[xi ,yi ,zi,ti] với i là chỉ số của một vệ tinh.
GPS tự xác định được thời gian tr là lúc nhận được tin nhắn của vệ tinh từ đó xác
định được khoảng thời gian vận chuyển tin nhắn trong môi trường không gian là:
tr - ti
Giả sử các tin nhăn được truyền với tốc độ của tốc độ ánh sáng ( c = 300.000 Km/s)
vậy khoảng cách giữa máy thu và vệ tinh được xác định là :
( tr - ti )c
Mỗi một vị trí của vệ tinh và khoảng cách của vệ tinh đó sẽ xác định được một hình
cầu với tầm là vị trí của vệ tinh và bán kính là khoảng cách của vệ tinh tới máy thu. Khi
đó với tín hiệu của 4 vệ tinh ta sẽ có 4 hình cầu tương ứng. Trong trường hợp lý tưởng và
không có lỗi thì máy thu GPS sẽ được xác định nằm tại giao điểm của 4 mặt cầu đó.
Một vấn đề cần lưu ý nữa là khoảng thời gian trễ: Chiều dài khoảng thời gian trễ này
chính là thời gian truyền của tín hiệu từ vệ tinh. Máy thu nhận thời gian này với tốc độ
ánh sáng để xác định quãng đường truyền tín hiệu. Giả sử rằng tín hiệu truyền trên đường
thẳng, đây chính là khoảng cách từ vệ tinh đến máy thu. Để thực hiện phép đo này, chúng
ta phải chắc chắn là đồng hồ trên vệ tinh và trong máy thu phải đồng bộ với nhau. Một sai
số 1 mili giây sẽ dẫn đến sai số là 300 ngàn mét. Do đó, độ chính các tối thiểu cho các
máy thu phải là cỡ nano giây (10-9 ). Để có độ chính xác như vậy, phải trang bị đồng hồ
nguyên tử cho không chỉ các vệ tinh mà còn máy thu. Nhưng đồng hồ nguyên tử thì lại
đắt, khoảng 50 đến 100 ngàn đô. Điều đó thì quá đắt và thật sự không thiết thực.

Để có thể đưa các ứng dụng GPS đến với chúng ta, các kỹ sư đã có một giải pháp
thông minh và hiệu quả. Mỗi quả vệ tinh mang theo một cái đồng hồ nguyên tử, nhưng
mỗi máy thu thì chỉ trang bị đồng hồ quartz thông thường. Các đồng hồ quartz này được
điều chỉnh liên tục dựa vào tín hiệu được truyền đi từ các vệ tinh.
Trên lý thuyết thì 4 mặt cầu phải giao nhau tại 1 điểm. Nhưng do sai số đồng hồ quartz
rẻ tiền, 4 mặt cầu đã không cho 1 giao điểm duy nhất. Biết rằng sai số này gây ra bởi đồng
hồ trên máy thu là như nhau Δt, máy thu có thể dễ dàng loại trừ sai số này bằng cách tính
toán ra lượng hiệu chỉnh cần thiết để 4 mặt cầu giao nhau tại một điểm. Dựa vào đó, máy
thu tự động điều chỉnh đồng hồ cho đồng bộ với đồng hồ nguyên tử trên vệ tinh. Nhờ đó
mà đồng hồ trên máy thu có độ chính xác gần như tương đương với đồng hồ nguyên tử.
Vậy là chuyện đo khoảng cách đã được giải quyết ổn thoả.
Biết khoảng cách rồi, chúng ta còn phải biết vị trí chính xác của các vệ tinh trên quĩ
đạo. Điều này cũng không khó lắm vì các vệ tinh chuyển đông trên các quĩ đạo biết trước
và có thể dự đoán được.Trong bộ nhớ của mỗi máy thu đều có chứa một bảng tra vị trí
tính toán của tất cả các vệ tinh vào bất kỳ thời điểm nào gọi là Almanac.
1.2.3 Ứng dụng GPS
Dựa trên hệ thống GPS, ứng dụng trên smartphone có thể xác định vị trí của khách du
lịch. Dựa trên thông tin này, ứng dụng có thể đưa ra khoảng cách tới các địa điểm du lịch.
Điều này đặc biệt có ích với những du khách lần đầu tới Hà Nội vẫn còn bỡ ngỡ.
Kết hợp ứng dụng GPS và Googmap, hệ thống có thể cung cấp cho người tham gia
giao thông cái nhìn trực quan về tình trạng giao thông hiện tại.

CHƯƠNG 2: TỔNG QUAN VỀ HỆ ĐIỀU HÀNH ANDROID
2.1 Gi ới thi ệu chung
Để xây dựng hệ thống cảnh báo giao thông trên smart phone thì việc phát triển ứng
dụng trên smart phone là không thể thiếu. Vì vậy em xin chọn một trong hai nền tảng phổ
biến cho thiết bị di động nhất hiện nay, đó là Android.
Android
Android là hệ điều hành trên điện thoại di động (và hiện nay là cả trên một số đầu phát
HD, HD Player, TV) phát triển bởi Google và dựa trên nền tảng Linux. Trước đây,
Android được phát triển bởi công ty liên hợp Android (sau đó được Google mua lại vào
năm 2005).
Các nhà phát triển viết ứng dụng cho Android dựa trên ngôn ngữ Java. Sự ra mắt của
Android vào ngày 5 tháng 11 năm 2007 gắn với sự thành lập của liên minh thiết bị cầm
tay mã nguồn mở, bao gồm 78 công ty phần cứng, phần mềm và viễn thông nhằm mục
đính tạo nên một chuẩn mở cho điện thoại di động trong tương lai.
Lịch sử phát tri ển Anroid
Tháng 7 năm 2005, Google mua lại Android, Inc., một công ty nhỏ mới thành lập có
trụ sở ở Palo Alto, California, Mỹ. Những nhà đồng sáng lập của Android chuyển sang
làm việc tại Google gồm có Andy Rubin (đồng sáng lập công ty Danger), Rich Miner
(đồng sáng lập công ty Wildfire Communications), Nick Sears (từng là phó chủ tịch
của T-Mobile), và Chris White (trưởng nhóm thiết kế và phát triển giao diện tại WebTV).
Ngày 5 tháng 11 năm 2007, Liên minh thiết bị cầm tay mở rộng (Open Handset
Alliance), bao gồm nhiều công ty trong đó có Texas Instruments, tập đoàn Broadcom,
Google, HTC, Intel, LG, tập đoàn Marvell Technology, Motorola, Nvidia, Qualcomm,
Samsung Electronics, Sprint Nextel và T-Mobile được thành lập với mục đích phát triển
các tiêu chuẩn mở cho thiết bị di động. Cùng với sự thành lập của liên minh OHA, họ
cũng giới thiệu sản phẩm Android đầu tiên. Nó là một thiết bị di động có hệ điều hành
dựa trên nhân Linux phiên bản 2.6.
Ngày 9 tháng 12 năm 2008, thêm 14 thành viên mới gia nhập liên minh phát triển
android OHA, gồm có ARM Holdings, Atheros Communications,Asustek Computer Inc,
Garmin Ltd, Softbank, Sony Ericsson, Toshiba Corp, và Vodafone Group Plc. Mã nguồn
mở Android được phát hành kể từ ngày 21 tháng 10 năm 2008.
2.2 Phát tri ển ứng dụng trên Android platform
Để phát triển một ứng dụng android, người lập trình cần có một bộ công cụ bao gồm:
- JDK (Java Development Kit): bộ công cụ và thư viện chung cho phát triển ứng
dụng bằng ngôn ngữ java

- Android SDK (Android Software Development Kit): bộ công cụ và thư viện dành
riêng cho phát triển ứng dụng trên android platform
- Eclipse IDE và plugin android trên eclipse: Eclipse hiện nay là công cụ tốt nhất hỗ
trợ lập trình viên quản lý source code và phát triển ứng dụng android
Một project Android sẽ có cấu trúc sau:
 AndroidManifest.xml
Trong bất kì một dự án Android nào khi tạo ra đều có một file AndroidManifest.xml,
file này được dùng để định nghĩa các màn hình sử dụng, các quyền cũng như các giao
diện cho ứng dụng. Đồng thời nó cũng chứa thông tin về phiên bản SDK cũng như màn
hình chính sẽ chạy đầu tiên.
File này được tự động sinh ra khi tạo một dự án Android. Trong file manifest bao giờ
cũng có 3 thành phần chính đó là: application, permission và version
 Gen
Thư mục này chứa file R.java là một file tự động sinh ra ngay khi tạo ứng dụng, file
này được sử dụng để quản lý các thuộc tính được khai báo trong file XML của ứng dụng
và các tài nguyên hình ảnh.
Mã nguồn của file R.java được tự động sinh khi có bất kì một sự kiện nào xảy xa làm
thay đổi các thuộc tính trong ứng dụng. Chẳng hạn như, bạn kéo và thả một file hình ảnh
từ bên ngoài vào dự án thì ngay lập tức thuộc tính đường dẫn đến file đó cũng sẽ được
hình thành trong file R.java hoặc xoá một file hình ảnh thì đường dẫn tương ứng đến hình
ảnh đó cũng tự động bị xoá.
Có thể nói file R.java hoàn toàn không cần phải đụng chạm gì đến trong cả quá trình
xây dựng ứng dụng.
 Layout
Thư mục layout chứa các file .xml được dùng để thiết kế, định nghĩa các thành phần
giao diện cho ứng dụng.
 Value
Chứa các giá trị sử dụng trong ứng dụng được bạn định nghĩa, như các dòng ký tự
(string), các màu (color), các themes...
 Drawable
Thư mục chứa các hình ảnh để làm icon hoặc tài nguyên cho giao diện...
 Src
Chứ file source .java. Chúng ta sẽ viết code cho ứng dụng trong những file này
 Android library

Chứa file Android.jar, nó chứa tất cả các thư viện class cần thiết cho một ứng dụng
android
 Assets
Là thư mục chứa tất cả tài nguyên, dữ liệu được sử dụng bởi ứng dụng như HTML,
text file, database, etc.
2.3 Các thành phần của Android 2.2
Các component của android được chia thành 6 loại cơ bản:
 Activity là một component cung cấp một giao diện mà người dùng có thể tương
tác để làm một việc gì đó, như gọi điện, chụp ảnh, gửi email, xem bản đồ… Có thể
coi mỗi activity là một window hiển thị giao diện tương tác người dùng.
 Service là một component chạy ẩn trong android. Service sử dụng để update dữ
liệu, đưa ra các cảnh báo (Notìication) và không cung cấp giao diện tương tác.
 Content Provider được sử dụng để quản lý và chia sẻ dữ liệu giữa các ứng dụng
 Intent là component để truyền tải các thông báo
 BroadCast Receiver là thành phần thu nhận các intent từ bên ngoài gửi tới.
 Notification làm nhiệm vụ đưa ra các cảnh báo mà không làm cho activity phải
ngừng hoạt động
Activity, Service, Broadcast Receiver và Content Provider là các thành phần chính cấu
tạo nên ứng dụng android. Chúng cần được khai báo trong file AndroidManifest khi sử
dụng.
2.3.1 Activity
Activity là thành phần quan trọng nhất vì nó đóng vai trò chính trong việc xây dựng
ứng dụng Android. Hệ điều hành Android quản lý các activity theo cơ chế stack: khi một
activity mới được khởi tạo, nó sẽ được xếp lên đầu của stack và đặt ở trạng thái running
activity, các activity dưới đó sẽ bị tạm dừng và chỉ hoạt động trở lại khi activity trên nó
được giải phóng.
Activity bao gồm 3 trạng thái tồn tại:
- Resumed: Activity đang hiển thị trên màn hình (foreground) và người dùng có thể
tương tác
- Pause: Một Activity khác ở trạng thái Resumed nhưng activity này vẫn được hiển
thị. Đó là trường hợp một activity khác hiển thị ở trên cùng stack nhưng không lấp đầy
màn hình hoặc có một phần trong suốt. Khi ở trạng thái này, activity có thể bị hủy bởi hệ
thống khi cần bộ nhớ.

- Stop: Activity hoàn toàn bị che khuất bởi activity khác. Một thực thể activity ở trạng
thái này vẫn tồn tại. Tuy nhiên, nó không bao giờ hiển thị cho người dùng và nó cũng có
thể bị hủy bởi hệ thống khi cần sử dụng.
2.3.2 Intent
Một ứng dụng android có thể có nhiều hơn một Activity. Khi ứng dụng của chúng ta
có nhiều hơn một activity, ta cần phải điều hướng từ một activity này tới activity khác.
Trong Android ta sẽ sử dụng Intent để điều hướng giữa nhiều activity. Nói một cách đơn
giản và dễ hiểu hơn, Intent là một cơ cấu cho phép truyền thông điệp giữa các thành phần
của 1 ứng dụng và giữa các ứng dụng với nhau.

Các thuộc tính của Intent:
 action: là hành động được thực hiện, vd : ACTION_VIEW, ACTION_MAIN
 data: là dữ liệu sẽ được xử lý trong action, thường được diễn tả là một Uri
 category: bổ sung thêm thông tin cho action của Intent.
 type: chỉ rõ kiểu của data
 component: chỉ rõ thành phần sẽ nhận và xử lý intent. Khi thuộc tính này được
xác định thì các thuộc tính khác sẽ trở thành thuộc tính phụ.
 extras: mang theo đối tượng Bundle chứa các giá trị bổ sung.
Phân loại Intent
Intent được chia làm 2 loại:
 Explicit Intents: intent đã được xác định thuộc tính component, nghĩa là đã chỉ rõ
thành phần sẽ nhận và xử lý intent. Thông thường intent dạng này sẽ không bổ
sung thêm các thuộc tính khác như action, data. Explicit Intent thương được sử
dụng để khởi chạy các activity trong cùng 1 ứng dụng.
 Implicit Intents: Intent không chỉ rõ component xử lý, thay vào đó nó bổ sung
thông tin trong các thuộc tính. Khi intent được gửi đi, hệ thống sẽ dựa vào những
thông tin này để quyết định component nào thích hợp nhất để xử lý nó.
Intent Filter
Activity, Service và BroadCast Receiver sử dụng Intent Filter để thông báo cho hệ
thống biết các dạng Implicit Intent mà nó có thể xử lý. Nói cách khác, Intent Filter là bộ
lọc Intent, chỉ cho những Intent được phép đi qua nó.
Intent Filter mô tả khả năng của component định nghĩa nó. Khi hệ thống bắt được 1
Implicit Intent (chỉ chứa 1 số thông tin chung chung về action, data và category...), nó sẽ
sử dụng những thông tin trong Intent này, kiểm tra đối chiếu với Intent Filter của các
component các ứng dụng, sau đó quyết định khởi chạy ứng dụng nào thích hợp nhất để xử
lý Intent bắt được. Nếu có 2 hay nhiều hơn ứng dụng thích hợp, người dùng sẽ được lựa
chọn ứng dụng mình muốn.
2.3.3 Android Service
Service là một ứng dụng trong android chạy ở chế độ background không cần tương tác
với người dùng. Ví dụ: trong khi đang sử dụng một ứng dụng, chúng ta muốn nghe nhạc
cùng thời điểm đó. Và do đó nó có thể chạy giống như một dịch vụ. Ngoài ra sử dụng
Service cũng là một ý tưởng tuyệt vời cho những chương trình thực thi mà không cần đến
giao diện tương tác với người sử dụng như việc luôn cập nhật tọa độ địa lý của thiết bị
dựa vào GPS.
Một Service có thể được sử dụng theo 2 cách:

 Nó có thể được bắt đầu và được cho phép hoạt động cho đến khi một người nào
đó dừng nó lại hoặc nó tự ngắt. Ở chế độ này, nó được bắt đầu bằng cách gọi
Context.startService() và dừng bằng lệnh Context.stopService(). Nó có thể tự ngắt bằng
lệnh Service.stopSelf() hoặc Service.stopSelfResult(). Chỉ cần một lệnh stopService() để
ngừng Service lại cho dù lệnh startService() được gọi ra bao nhiêu lần
 Service có thể được vận hành theo như đã được lập trình việc sử dụng một
Interface mà nó định nghĩa. Các người dùng thiết lập một đường truyền tới đối tượng
Service và sử dụng đường kết nói đó để thâm nhập vào Service. Kết nối này được thiết
lập bằng cách gọi lệnh Context.bindService() và được đóng lại bằng cách gọi lệnh
Context.unbindService(). Nhiều người dùng có thể kết nối tới cùng một thiết bị. Nếu
Service vẫn chưa được khởi chạy, lệnh bindService() có thể tùy ý khởi chạy nó. Hai chế
độ này thì không tách biệt toàn bộ. Bạn có thể kết nối với một Service mà nó đã được bắt
đầu với lệnh startService(). Ví dụ, một Service nghe nhạc ở chế độ nền có thể được bắt
đầu bằng cách gọi lệnh startService() cùng với một đối tượng Intent mà định dạng được
âm nhạc để chơi. Chỉ sau đó, có thể là khi người sử dụng muốn kiểm soát trình chơi nhạc
hoặc biết thêm thông tin về bài hát hiện tại đang chơi, thì sẽ có một Activity tạo lập một
đường truyền tới Service bằng cách gọi bindService(). Trong trường hợp như thế này,
stopService() sẽ không thực sự ngừng Service cho đến khi liên kết cuối cùng được đóng
lại.
Giống như một Activity, một Service cũng có các phương thức chu kỳ thời gian mà
bạn có thể cài đặt để kiểm soát những sự thay đổi trong trạng thái của nó. Những những
phương thức của Service thì ít hơn là của Activity – chỉ có 3- và chúng thì được sử dụng
rộng rãi, không được bảo vệ.
void onCreate()
void onStart(Intent intent)
void onDestroy()
Bằng việc thực hiện những phương thức này, bạn có thể giám sát 2 vòng lặp của chu
kỳ thời gian của mỗi Service Entire lifetime của một Service diễn ra giữa thời gian
onCreate() được gọi ra và thời gian mà onDestroy() trả lại. Giống như một Activity, một
Service lại tiến hành cài đặt ban đầu ở onCreate(), và giải phóng tát cả các tài nguyên còn
lại ở onDestroy(). Ví dụ, một Service phát lại nhạc có thể tạo ra một luồng và bắt đầu chơi
nhạc onCreate(),và sau đó luồng chơi nhạc sẽ dừng lại ở onCreate(),
Active lifetime của một Service bắt đầu bằng một lệnh tới onStart(). Đây là phương
thức được chuyển giao đối tượng Intent mà đã được thông qua để tới startService()
Service âm nhạc sẽ mở đối tượng Intent để quyết định xem sẽ chơi loại nhạc nào và bắt
đầu phát nhạc.

Không có callback tương đương nào cho thời điểm Service ngừng lại – không có
phương thức onStop()
Các phương thức onCreate() và onDestroy() được gọi cho tất cả các Service dù chúng
có được bắt đầu bằng Context.startService() hoặc Context.bindService() hay không. Tuy
nhiên thì, onStart() chỉ được gọi ra đối với các Service bắt đầu bằng startService().
Nếu một Service cho phép những Service khác kết nối với nó thì sẽ có thêm các
phương thức callback dành cho Service đó để thực hiên
IBinder onBind(Intent intent)
boolean onUnbind(Intent intent)
void onRebind(Intent intent)
Hàm callback onBind() thông qua đối tượng Intent đã được truyền đến bindService và
onUnbind() được chuyển giao đối tượng mà đã được chuyển đến. Nếu Service đang được
chỉ định (binding), onBind() quay trở lại kênh thông tin mà người dùng sử dụng để tương
tác với Service. Phương thức onUnbind() có thể yêu cầu onRebind() được gọi nếu một
người dùng kết nối với Service
Biểu đồ dưới đây minh họa cho các phương thức callback giành cho một Service. Mặc
dù, nó phân biệt các Service được tạo ra thông qua startService với các Service mà được
tạo ra bằng bindService(). Hãy nhớ rằng bất kì Service nào, cho dù nó được khởi tạo như
thế nào thì nó vẫn có thể cho phép các người dùng kết nối tới nó một cách hiệu quả nhất,
cho nên bất kì Service nào cũng có thể được chỉ định thông qua các các phương thức
onBind()và onUnbind()

Vòng đời của Service
Để sử dụng Android Service chúng ta phải định nghĩa một lớp kế thừa từ một lớp
Service (trong android.jar).
Ví dụ:
Public class MyService extends Service {
@Override
public IBinder onBind(Intent arg0) {
return null;
}
@Override

public int onStartCommand(Intent intent, int flags, int startId) {
.
Toast.makeText(this, “Service Started”,
Toast.LENGTH_LONG).show();
return START_STICKY;
}
@Override
public void onDestroy() {
super.onDestroy();Toast.makeText(this, “Service Destroyed”,
Toast.LENGTH_LONG).show();
}
}
Tất cả các service được tạo ra đều phải được khai báo trong file AndroidManifest.xml
<service android:name=”.MySer vice” />
2.3.4 Content Provider
Trong hệ thống Android tất cả các tài nguyên ngư Contact, SMS,… đều được lưu trữ
vào CSDL SQLite của hệ thống. Cũng như các CSDL khác, CSDL mà hệ thống Android
sử dụng để lưu trữ thông tin cũng cho phép chúng ta truy vấn dữ liệu như một CSDL
MSSQL thông thường. Tuy nhiên, trong hệ thống đó chúng ta không cần phải thao tác
bằng lệnh SQL nhiều để truy xuất dữ liệu mà thay vào đó Android đã được trang bị một
API cho phép người lập trình có thể dễ dàng truy xuất dữ liệu. Đó gọi là ContentProvider.
Một Content Provider cung cấp một tập chi tiết dữ liệu ứng dụng đến các ứng dụng
khác. Thường được sử dụng khi chúng ta muốn tạo cơ sở dữ liệu dưới dạng public (các
ứng dụng khác có thể truy xuất ).
Dữ liệu thường được lưu trữ ở file hệ thống, hoặc trong một SQLite database. Đơn
giản để các ta có thể hình dung như: Danh bạ, Call log, cấu hình cài đặt...trên điện thoại là
dữ liệu dưới dạng Content Provider.
Content Provider thực hiện một tập phương thức chuẩn mà các ứng dụng khác có thể
truy xuất và lưu trữ dữ liệu của loại nó điều khiển.
Tuy nhiên, những ứng dụng không thể gọi các phương thức trực tiếp. Hơn thế chúng
dùng lớp Content Resolver và gọi những phương thức đó. Một Content Resolver có thể

giao tiếp đến nhiều content provider; nó cộng tác với các provider để quản lý bất kỳ giao
tiếp bên trong liên quan.
2.3.5 Broadcast Receiver
Broadcast receiver là một thành phần trong android cho phép đăng kí sự kiện hệ thống
hay ứng dụng. Tất cả các receiver được đăng kí cho một sự kiện đều được thông báo bởi
Android khi sự kiện này xảy ra.
Broadcast Receiver được kế thừa từ lớp BroadcastReveiver và được đăng kí receiver
trong ứng dụng Android bởi file AndroidManifest (hoặc bằng code).
<receiver android:name="MyPhoneReceiver" >
<intent-filter>
<action android:name="android.intent.action.PHONE_STATE" >
</action>
</intent-filter>
</receiver>
2.3.6 Control View
Trong một ứng dụng Android, giao diện người dùng được xây dựng từ các đối tượng
View và ViewGroup. Có nhiều kiểu View và ViewGroup. Mỗi một kiểu là một kế thừa
của class View và tất cả các kiểu đó được gọi là các Widget.
Tất cả mọi widget đều có chung các thuộc tính cơ bản như là cách trình bày vị trí,
background, kích thước, lề,… Tất cả những thuộc tính chung này được thể hiện hết ở
trong đối tượng View.
Trong Android Platform, các screen luôn được bố trí theo một kiểu cấu trúc phân cấp
như hình dưới. Một screen là một tập hợp các Layout và các widget được bố trí có thứ tự.
Để thể hiện một screen thì trong hàm onCreate của mỗi Activity cần phải được gọi một
hàm là setContentView(R.layout.main); hàm này sẽ load giao diện từ file XML lên để
phân tích thành mã bytecode.

Cấu trúc giao diện của ứng dụng Android
Basic Views
Các thành phần View cơ bản chúng ta có thể sử dụng để thiết kế giao diện người dùng
cho ứng dụng Android:
 Textview
 EditText
 Button
 ImageButton
 CheckBox
 ToggleButton
 RadioButton
 RadioGroup

Thành phần View cơ bản
Những thành phần View cho phép chúng ta hiển thị thông tin dạng text, và thực thi
những lựa chọn cơ bản.
Picker View
Chọn ngày, giờ là một trong những nhiệm vụ cần thiết để thực thi một ứng dụng
mobile. Android hỗ trợ chức năng này thông qua TimePicker và DatePicker

TimePicker vs DatePicker
List Views
ListView cho phép ứng dụng hiển thị một danh sách dài các items. Trong android có
hai kiểu của list view: ListView và SpinnerView. Cả hai đểu sử dụng để hiển thị danh
sách dài các items.
 ListView: Được sử dụng để thể hiện một danh sách các thông tin theo từng cell.
Mỗi cell thông thường được load lên từ một file XML đã được cố định trên đó số
lượng thông tin và loại thông tin cần được thể hiện. Các items trong ListView sẽ
hiển thị đầy đủ trên screen của ứng dụng.
 SpinnerView: Hiển thị một item tại một thời điểm từ một danh sách và người sử
dụng có thể lựa chọn một trong số items thuộc danh sách đó.

ListView (trái) và SpinnerView (phải)
LinearLayout
LinearLayout được dùng để bố trí các thành phần giao diện theo chiều ngang hoặc
chiều dọc nhưng trên một line duy nhất mà không có xuống dòng. LinearLayout làm cho
các thành phần trong nó không bị phụ thuộc vào kích thước của màn hình. Các thành phần
trong LinearLayout được dàn theo những tỷ lệ cân xứng dựa vào các ràng buộc giữa các
thành phần
FrameLayout
FrameLayout được dùng để bố trí các đối tượng theo kiểu giống như là các Layer
trong Photoshop. Những đối tượng nào thuộc Layer bên dưới thì sẽ bị che khuất bởi các
đối tượng thuộc Layer nằm trên. FrameLayer thường được sử dụng khi muốn tạo ra các
đối tượng có khung hình bên ngoài chẳng hạn như contact image button.
AbsoluteLayout
Layout này được sử dụng để bố trí các widget vào một vị trí bất kì trong layout dựa
vào 2 thuộc tính toạ độ x, y. Tuy nhiên, kiểu layout này rất ít khi được dùng bởi vì toạ độ
của các đối tượng luôn cố định và sẽ không tự điều chỉnh được tỷ lệ khoảng cách giữa các
đối tượng. Khi chuyển ứng dụng sang một màn hình có kích thước với màn hình thiết kế
ban đầu thì vị trí của các đối tượng sẽ không còn được chính xác như ban đầu.

RetaliveLayout
Layout này cho phép bố trí các widget theo một trục đối xứng ngang hoặc dọc. Để đặt
được đúng vị trí thì các widget cần được xác định một mối ràng buộc nào đó với các
widget khác. Các ràng buộc này là các ràng buộc trái, phải, trên, dưới so với một widget
hoặc so với layout parent. Dựa vào những mối ràng buộc đó mà RetaliveLayout cũng
không phụ thuộc vào kích thước của screen thiết bị. Ngoài ra, nó
còn có ưu điểm là giúp tiết kiệm layout sử dụng nhằm mục đích giảm lượng tài
nguyên sử dụng khi load đồng thời đẩy nhanh quá trình xử lý.
TableLayout
Layout này được sử dụng khi cần thiết kế một table chứa dữ liệu hoặc cần bố trí các
widget theo các row và column. Chẳng hạn như, giao diện của một chiếc máy tính đơn
giản hoặc một danh sách dữ liệu.
2.4 Giới thi ệu về Google Map API
Google Map là một dịch vụ ứng dụng đắt giá của google cung cấp. Nó cho phép
người dùng thấy bản đồ đường sá, vị trí các địa điểm kinh doanh, thậm chí ảnh chụp bề
mặt trái đất với tỷ lệ tùy chỉnh. Với google map người dùng có thể dễ dàng tìm kiếm
đường đi, vị trí cửa hàng, trạm xăng… một cách hết sức trực quan thông qua 2 chế độ
chính là: ảnh vệ tinh và bản đồ.
Để bên phát triển thứ 3 có thể sử dụng dịch vụ này, Google cung cấp Google Map
API cho phép tích hợp Google Map vào các ứng dụng web hoặc mobile. Kết hợp những
gì Google Map và hệ thống định vị toàn cầu GPS cung cấp, nhà phát triển có thể triển
khai dễ dàng các ứng dụng sử dụng vị trí người sử dụng. Đây thực sự là một công nghệ có
nhiều ứng dụng trong cuộc sống. Trong hệ thống cảnh báo giao thông, Google Map API
sẽ cung cấp giao diện Map View cho việc theo dõi bản đồ và vị trí các report.
 Đăng ký Google Map Key
Google Map API không phải là một dịch vụ miễn phí. Để sử dụng Google Map API,
cần có Map API Key. Hiện tại Google cho phép đăng ký API Key miễn phí với giới hạn
về số lượng kết nối và giới hạn thiết bị.
 Sử dụng Google View trong android
Để đơn giản trong việc sử dụng Google MAP API, google đã cung cấp thư viện
Google Maps trên android, nó cho phép người pháp triển quản lý map trên MapActivity
và MapView. Để tạo một ứng dụng android đơn giản sử dụng Google Map cần chú ý
thêm một số bước sau:
1) Vì thư viện Maps không có trong bộ thư viện chuẩn của android, nên bắt buộc
phải khai báo nó trong Android Manifest, như sau:

<uses-library android:name="com.google.android.maps"/>
2) Cấp phép cho ứng dụng kết nối internet. Đây là điều không thể thiếu trong tất
cả các ứng dụng sử dụng google map. Nó được khai báo trong Android
Manifest như sau:
<uses-permission android:name="android.permission.INTERNET"/>
3) Sử dụng MapView trong layout của Activity. Đây là một custom component
được xây dựng trong thư viện Maps. Vì vậy việc tên component cần phải được
nhập đầy đủ. Và cần phải có thuộc tính apikey hợp lệ:
<?xml version="1.0" encoding="utf-8"?>
<com.google.android.maps.MapView
xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/mapview"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:clickable="true"
android:apiKey="Your Maps API Key"
/>
4) Sử dụng MapActivity thay cho Activity của thư viện android.
public class HelloGoogleMaps extends MapActivity
Trên đây là một số điểm chú ý cơ bản để sử dụng thư viện Google Maps. Bên cạnh
việc hiển thị bản độ thì bộ thư viện này còn hỗ trợ khá nhiều cho việc quản lý map. Ví dụ
như, tạo các overlay đánh dấu địa điểm, tìm đường đi ngắn nhất…
2.5 Công nghệ Servlet
Để phát triển một hệ thống chia sẻ thông tin giữa nhiều người dùng thì công nghệ phía
server là điều không thể thiếu. Servlet là những chương trình Java chạy trong một Web
server dùng Java. Nó đóng vai trò như một chương trình server, liên tục nhận yêu cầu từ
các client và trả lời các yêu cầu đó. Servlet là một trong những công nghệ có nhiều ưu
điểm so với những công nghệ khác.
 Hiệu năng: Các servlet được chạy thông qua máy ảo java nên một servlet xử lý
nhiều yêu cầu đồng thời mà không cần sử dụng nhiều tiến trình hoặc nhiều vùng dữ
liệu, vì vậy các request được đáp ứng hiệu quả hơn. Các servlet cũng chạy nhanh
hơn so với các chương trình được viết bằng các ngôn ngữ khác như PERL.

 Khả năng mở rộng: Kể từ khi nhiều servlet có thể xử bởi một tiến trình duy nhất,
chúng ta đã có thể quản lý hàng triệu request client mà không làm quá tải server.
(vì giao tiếp trong 1 tiến trình đơn giản hơn rất nhiều so với giữa nhiều tiến trình)
 Khả năng di chuyển: Nếu chúng ta thay đổi hệ thống, chúng ta chỉ cần cài đặt
phiên bản java thích hợp trên nền tảng mới, các servlet vẫn không thay đổi.
 Dễ sử dụng: Do được viết bằng Java, servlet tạo thành một môi trường xuất sắc
cho các dịch vụ mạng. Lập trình viên Java không trực tiếp quản lý bộ nhớ, vì thế
servlet tránh được lỗi tràn bộ đệm, vốn tạo ra các điểm yếu về bảo mật trong các
phần mềm được viết bằng C hay C++. Những cơ chế đơn giản của Java để xử lý
các trường hợp ngoại lệ và đa luồng khuyến khích việc phát triển các dịch vụ mạng
một cách chặt chẽ và đáng tin cậy.

CHƯƠNG 3: PHÂN TÍCH THIẾT KẾ HỆ THỐNG
3.1 Mục tiêu xây dựng hệ thống
Từ việc phân tích tình trạng giao thông và các kiến thức trên, ở chương này tôi xin
trình bày về việc xây dựng hệ thống cảnh báo giao thông. Hệ thống cảnh báo giao thông
sẽ làm nhiệm vụ chính là cung cấp thông tin tình trạng giao thông cho người sử dụng
smart phone, đồng thời đưa ra các cảnh báo dựa trên hệ thống định vị toàn cầu GPS.
3.2 Xác định yêu cầu hệ thống
3.2.1 Các chức năng của hệ thống
Hệ thống cảnh báo giao thông có nhiệm vụ cơ bản là chia sẻ thông tin giao thông giữa
những người dùng cuối (End User). Hoạt động chia sẻ thông tin này sẽ được kiểm duyệt
bởi người quản lý (Manager User). Hệ thống cần tận dụng tối đa những lợi thế của
smartphone để đem lại sự tiện dụng nhất khi End User tiếp cần nguồn thông tin. Vì vậy,
hệ thống cảnh báo giao thông sẽ gồm các chức năng chính như sau:
 Gửi cảnh báo giao thông: chức năng này cho phép người dùng đóng góp thông tin
cảnh báo cho hệ thống. Các cảnh báo này sẽ được lưu trữ và được dùng để chia sẻ cho các
người dùng khác sau khi được phê duyệt. Thông tin cảnh báo cần chứa những thông tin
đầy đủ, ngắn gọn và trực quan, ví dụ: mô tả cảnh báo, hình ảnh, vị trí của cảnh báo…
 Tra cứu thông tin cảnh báo giao thông: chức năng này cho phép người dùng tra
cứu tất cả các thông tin cảnh báo đã được phê duyệt trong một thành phố hoặc một vùng
có bán kính lớn xung quanh vị trí hiện tại của người dùng. Các thông tin này cần được
cung cấp 1 cách trực quan (hiện thị trên google map), tiện dụng, tiện tra cứu. Chức năng
này cần cung cấp cho người dùng thông tin tổng quát và chi tiết của tình trạng giao thông
trong phạm vi rộng. Điều này sẽ hỗ trợ người dùng lựa chọn cho mình tuyến đường phù
hợp nhất hoặc ít nhất người dùng sẽ có thông tin về các vấn đề giao thông có thể gặp phải
trên tuyến đường sẽ đi.
 Cảnh báo giao thông: chức năng này cho phép người dùng theo dõi các thông tin
cảnh báo xung quanh vị trí hiện tại. Chức năng này là ứng dụng của GPS và google map
trên smartphone. Từ những thông tin cảnh báo nhận được, người dùng có thể đưa ra các
xử lý kịp thời với các vấn đề giao thông.
 Phê duyệt và hủy bỏ cảnh báo: chức năng này cho phép Manager User phê duyệt
hoặc hủy bỏ cảnh báo. Các cảnh báo đã được phê duyệt sẽ được cung cấp cho tất cả người
dùng trong hệ thống. Với các thông tin chi tiết như hình ảnh, mô tả, vị trí cảnh báo…
người quản lý sẽ dễ dàng hơn trong việc chọn lọc những cảnh báo chính xác nhất.
3.2.2 Các Actor tương tác với hệ thống
Mã Tên Actor Mô tả

A1 End User Người sử dụng ứng dụng Cảnh Báo Giao Thông
trên thiết bị di động để tra cứu thông tin thông tin và
đóng góp thông tin cảnh báo
A2 Manager User
Người sử dụng ứng dụng Cảnh Báo Giao Thông
trên thiết bị di động để phê duyệt các cảnh báo mà tất
cả người dùng đóng góp. Ngoài ra Manager User có
thể sử dụng web để thực hiện chức năng phê duyệt của
hệ thống.
3.2.3 Sơ đồ UseCase của hệ thống
 U1 Register: usecase đăng ký thành viên của hệ thống
 U2 Login: usecase cho phép user đăng nhập vào hệ thống
 U3 Logout: usecase cho phép user thoát khỏi hệ thống
 U4 ViewMapReport: cho phép user xem tất cả report đã được duyệt của hệ
thống trên bản đồ
 U5 AddReport: cho phép user gửi cảnh báo đến server
 U6 ViewListReports: Hiển thị danh sách các report còn hiệu lực sắp xếp theo
thời gian
 U7 ViewDetailReport: Hiển thị thông tin chi tiết một cảnh báo

 U8 ViewNearReports: Hiển thị danh sách các cảnh báo gần user trên google
map view
 U9 ViewListInactiveReports: Hiển thị danh sách các cảnh báo chưa được phê
duyệt
 U10 ApproveReport: Cho phép Manager User phê duyệt một cảnh báo
 U11 RejectReport: Cho phép Manager User hủy một cảnh báo
3.2.4 Xây dựng kịch bản cho các usecase
Các kịch bản sau sẽ mô tả tương tác giữa user với ứng dụng (client) và giữa client với
server
U1 Register
Tên use case Register
Tác nhân Unregister User
Đảm bảo tối thiểu Hệ thống cho phép user nhập lại thông tin
Đảm bảo thành công Ứng dụng hiển thị giao diện và kết nối đến server
Kích hoạt User mở ứng dụng Cảnh Báo Giao Thông trên
smartphone và chọn chức năng Register
1. User nhập đầy đủ thông tin các trường, bao gồm: username, password,
fullname rồi click vào nút đăng ký
2. Ứng dụng trên smartphone (client) kiểm tra tính hợp lệ của thông tin đăng
ký: username,password khác trống, nhỏ hơn 50ký tự
3. Client gửi thông tin đăng ký đến server
4. Server kiểm tra tính hợp lệ của thông tin đăng ký: tên username chưa tồn tại
5. Server lưu trữ thông tin người dùng và trả về thông báo đăng ký thành công
6. Client hiển thị thông báo đăng ký thành công và thoát khỏi giao diện đăng
ký
Ngoại lệ
2.1. User chưa nhập đầy đủ thông tin
2.1.1 Hệ thống hiển thị thông báo yêu cầu user nhập đầy đủ thông tin
3.1 Mất kết nối internet
3.1.1 Client hiển thị thông báo mất kết nối
5.1 Username đã tồn tại
5.1.1 Server trả về thông báo username đã tồn tại
5.1.2 Client hiển thị thông báo

U2 Login
Tên use case Login
Tác nhân User
Đảm bảo tối thiểu User đã đăng ký tài khoản
Kích hoạt User mở ứng dụng Cảnh Báo Giao Thông trên
smartphone
1. User nhập đầy đủ thông tin các trường, bao gồm: username, password rồi
click vào nút Login
2. Ứng dụng trên smartphone (client) kiểm tra tính hợp lệ của thông tin đăng
nhập: username, password khác trống
3. Client gửi thông tin đăng ký đến server
4. Server kiểm tra tính hợp lệ của thông tin đăng nhập: tên username và
password khớp với trong cơ sở dữ liệu. Sau đó server sinh token cho tài
khoản
5. Server trả về thông tin đầy đủ của user cho client, bao gồm: họ tên, token
6. Client nhận thông tin của server và chuyển sang giao diện đã login.
Ngoại lệ
2.1 User chưa nhập đầy đủ thông tin
2.1.1 Client hiển thị thông báo yêu cầu nhập đầy đủ thông tin
3.1 Mất kết nối internet
3.1.1 Client hiển thị thông báo mất kết nối
4.1 1 Thông tin đăng nhập không hợp lệ
4.1.1 Server trả về thông báo tài khoản không hợp lệ
4.1.2 Client hiển thị thông báo
U3 Logout
Tên use case Logout
Tác nhân User
Đảm bảo tối thiểu User đã đăng nhập tài khoản

Kích hoạt User click vào nút login sau khi đăng nhập
1. Client gửi request logout đến server đồng thời quay về giao diện chưa login
2. Server xóa token của user trong cơ sở dữ liệu
Ngoại lệ
2.1 Token không tồn tại
U4 ViewMapReport
Tên use case ViewMapReport
Tác nhân User, Manager User
Đảm bảo tối thiểu User đã đăng nhập vào tài khoản
Kích hoạt Chọn chức năng ViewMapReport
1. User chọn giao diện xem bản đồ cảnh báo
2. Client gửi request đến server, gồm các trường: token
3. Server lấy tất cả thông tin cảnh báo còn hiệu lực
4. Server gửi trả về thông tin các cảnh báo
5. Client nhận thông tin và hiển thị cảnh báo trên google map
Ngoại lệ
U5 AddReport
Tên use case AddReport
Tác nhân User
Kích hoạt Chọn chức năng AddReport
1. User nhập các trường trên giao diện: Category, Description, chụp ảnh,
2. Client kiếm tra tính đầy đủ của các trường

3. Client gửi thông tin cảnh báo đến server
4. Server lưu trữ thông tin cảnh báo vào cơ sở dữ liệu và trả về thông báo đã
nhận thông tin
5. Trả về thông báo thành công
6. Client hiển thị thông báo gửi thành công
Ngoại lệ
2.1 User chưa nhập đủ các trường bắt buộc: category, picture, address
2.1.1 Hiển thị thông báo yêu cầu nhập đầy đủ thông tin
U6 ViewListReport
Tên use case ViewListReport
Tác nhân User
Kích hoạt Chọn chức năng ViewListReport
1. User chọn giao diện xem danh sách cảnh báo
3. Server lấy tất cả thông tin cảnh báo còn hiệu lực
4. Server gửi trả về thông tin các cảnh báo
5. Client nhận thông tin và hiển thị danh sách thông tin cảnh báo
Ngoại lệ
3.1 Hệ thống không có cảnh báo nào còn hiệu lực
3.1.1 Thông báo không có cảnh báo nào
U7 ViewNearReport
Tên use case ViewNearReport
Tác nhân User
Kích hoạt Chọn chức năng ViewNearReport

1. User chọn giao diện ViewNearReport
2. Client cập nhật tọa độ user thông qua phần cứng GPS
3. Client gửi request đến server, gồm token và tọa độ người dùng
4. Server tìm trong csdl những cảnh báo có khoảng cách với user nhỏ hơn 5km
5. Server trả về tất cả thông tin cảnh báo tìm được
6. Client gửi yêu cầu lấy bản đồ vị trí của report đến Google Map Server
7. Google Map Server trả về thông tin bản đồ
8. Client hiển thị vị trí các cảnh báo và vị trí user trên GoogleMapView
Ngoại lệ
U8 ViewDetailReport
Tên use case ViewDetailReport
Tác nhân User
Kích hoạt Hiển thị giao diện ViewListReport
1. User click vào một report
2. Client lấy thông tin chi tiết report từ thông tin danh sách report đã lấy từ
server
3. Client gửi yêu cầu lấy ảnh của report từ server
4. Server trả về ảnh của report
5. Client gửi yêu cầu lấy bản đồ vị trí của report đến Google Map Server
6. Google Map Server trả về thông tin bản đồ
7. Client hiển thị các trường thông tin và vị trí của report bao gồm: danh mục
report, thời gian được tạo, mô tả, vị trí (trên google map view) và ảnh chụp
Ngoại lệ
U9 ViewListInactionReport
Tên use case ViewListInactiveReport

Tác nhân User
Kích hoạt Chọn chức năng ViewListInactiveReport
2. Server lấy tất cả thông tin cảnh báo chưa được duyệt
3. Client nhận thông tin và hiển thị danh sách thông tin cảnh báo chưa duyệt
Ngoại lệ
U10 ApproveReport
Tên use case ApproveReport
Tác nhân ManagerUser
Đảm bảo tối thiểu ManagerUser đã đăng nhập vào tài khoản
Kích hoạt Chọn chức năng ViewDetailReport từ giao diện
ViewListInactiveReport
1. User click vào nút Approve sau khi xem thông tin chi tiết report
2. Client gửi request đến server
3. Server cập nhật thông tin report vào cơ sở dữ liệu.
4. Server gửi trả về thông báo approve thành công
5. Client hiển thị thông báo
Ngoại lệ
U11 RejectReport
Tên use case RejectReport
Tác nhân ManagerUser
Đảm bảo tối thiểu ManagerUser đã đăng nhập vào tài khoản
Kích hoạt Chọn chức năng ViewDetailReport từ giao diện
ViewListInactiveReport

1. User click vào nút Reject sau khi xem thông tin chi tiết report
2. Client gửi request đến server
3. Server cập nhật thông tin report vào cơ sở dữ liệu.
4. Server gửi trả về thông báo Reject thành công
5. Client hiển thị thông báo
Ngoại lệ
8.2.5 Minh họa các usecase bằng bi ểu đồ giao ti ếp:
Các biểu đồ giao tiếp sau sẽ làm rõ hoạt động của các thành phần trong hệ thống Cảnh
Báo Giao Thông.
U1 Register: usecase đăng ký thành viên của hệ thống
U2 Login: Đăng nhập
U3 Logout: usecase cho phép user thoát khỏi hệ thống

U4 ViewMapReport: cho phép user xem tất cả report đã được duyệt của hệ
thống trên bản đồ
U5 AddReport: Thêm cảnh báo
U6 ViewListReport: Xem danh sách cảnh báo

U7 ViewNearReports: Xem các cảnh báo gần nhất trên google map
U8 ViewDetailReport: Xem chi ti ết thông tin cảnh báo

U9 ViewListInactiveReports: Hiển thị danh sách các cảnh báo chưa được phê duyệt
U10 ApproveReport: Cho phép Manager User phê duyệt một cảnh báo

U11 RejectReport: Cho phép Manager User hủy một cảnh báo
3.3 Thi ết kế hệ thống
3.3.1 Atrribute cho các l ớp
Class Location: Chứa thông tin một địa điểm

- address: Tên địa điểm (được cung cấp bởi Google API thông qua tọa độ hoặc do
user tự nhập)
- lat: Vĩ độ của địa điểm
- lon: Kinh độ của địa điểm
Class User: Chứa thông tin user
- username: Tên tài khoản đăng nhập
- password: Mật khẩu
- fullname: Họ tên
- currentLocation: Địa điểm ở thời điểm hiện tại (hoặc thời điểm gần nhất) của
user, được cập nhật qua GPS
- token: Là chuỗi ký tự ngẫu nhiên đại diện cho việc đăng nhập của user
Class Gallery: Chứa thông tin danh sách ảnh của mỗi cảnh báo
- name: tên gallery
- imagesURL: danh sách URL ảnh của gallery
Category: Danh mục cảnh báo
- name: tên danh mục
- timeLife: thời gian tồn tại cho cảnh báo thuộc danh mục này, tính từ lúc cảnh
báo được tạo.
Report: Cảnh báo giao thông
- category: Danh mục của cảnh báo
- description: Mô tả chi tiết cảnh báo
- gallery: Danh sách ảnh mô tả cho cảnh báo
- location: Vị trí của cảnh báo
- dateCreated: Thời gian tạo
- isApproved: Xác định cảnh báo đã được duyệt
3.3.2 Operation
Class Location
+ void Location(float lat,float lon,String address)
+ void distance(Location location): tính khoảng cách so với 1 điểm khác
Class User
+ register(User user): đăng ký
+ login(String username,String password): đăng nhập
Class Gallery
+ void addImageURL(String imageURL): thêm url của ảnh

+ Bitmap fetchImage(int n): lấy ảnh thứ n từ server
Category
+ Datetime getTimeLife()
Report
+ void addReport(): thêm cảnh báo
+ void sendReport(): gửi cảnh báo
+ void approveReport(): duyệt cảnh báo
+ void rejectReport(): hủy cảnh báo
3.3.3 Biểu đồ lớp chi ti ết
3.3.4 Hiện thực hóa use case:
U1 Register: usecase đăng ký thành viên của hệ thống

U2 Login:
U3 Logout: usecase cho phép user thoát khỏi hệ thống

U4 ViewMapReport: cho phép user xem tất cả report đã được duyệt của hệ thống trên
bản đồ
U5 AddReport: cho phép user gửi cảnh báo đến server

U6 ViewListReports: Hiển thị danh sách các report còn hiệu lực
U7 ViewDetailReport: Hiển thị thông tin chi tiết một cảnh báo

U8 ViewNearReports: Hiển thị danh sách các cảnh báo gần user trên google map view
U9 ViewListInactiveReports: Hiển thị danh sách các cảnh báo chưa được phê duyệt

U10 ApproveReport: Cho phép Manager User phê duyệt một cảnh báo
U11 RejectReport: Cho phép Manager User hủy một cảnh báo

3.3.5 Bi ểu đồ trạng thái
Biểu đồ trạng thái cho chức năng đăng ký
Biểu đồ trạng thái cho chức năng gửi cảnh báo

3.4 Kiến trúc hệ thống
3.4.1 Lựa chọn hình trạng mạng (topology) của hệ thống:
Như đã xác định từ đầu, hệ thống Cảnh Báo Giao Thông sẽ cung cấp dịch vụ chia sẻ
thông tin cảnh báo giữa các người dùng smartphone thông qua một server. Chính vì vậy
kiến trúc 3 tầng là kiến trúc phù hợp nhất vì những lý do sau:
 Hệ thống Cảnh Báo Giao Thông gồm 3 phần tương ứng với kiến trúc 3 tầng:
giao diện tương tác người dùng trên client smartphone, chương trình xử lý logic
cho hệ thống và phần lưu trữ thông tin cảnh báo. Điều này giúp hệ thống được
phát triển một cách đơn giản hơn.
 Cải thiện hiệu năng hệ thống: một trong những điểm yếu của client smartphone
đó là khả năng xử lý phần cứng thấp. Với một máy server cấu hình cao sẽ giúp
client giảm thiếu tối đa công việc tính toán và xử lý dữ liệu.
 Nâng cao tính bảo mật: Một hệ thống client server thông thường sẽ cho các
máy client kết nối đến server thông qua mạng internet. Chính vì vậy vấn đề bảo
mật trở nên hết sức quan trọng. Trong kiến trúc 3 tầng, chúng ta chỉ cần cài đặt
cơ chế bảo mật ở tầng giữa. Khi đó tầng dữ liệu ở sau tầng giữa sẽ gần như
không cần bảo mật. Điều này sẽ giúp tầng dữ liệu hoạt động với hiệu năng cao
nhất.

 Tính linh hoạt trong kiến trúc: Kiến trúc độc lập dữ liệu, giao diện và xử lý
logic sẽ hết sức tính linh hoạt khi phát triển và mở rộng hệ thống. Ví dụ với
cùng một tầng Application Server và Database đã phát triển, ta có thể phát triển
ứng dụng client trên nhiều môi trường khác nhau như android platform, ios,
window, web…
Hệ thống Cảnh Báo Giao thông sẽ được phát triển theo kiến trúc 3 tầng như sau:
Tầng Database (tầng dữ liệu): Đây là nơi lưu trữ thông tin lâu dài cho toàn bộ hệ
thống. Tầng database server cho phép tầng Application Server thực hiện các truy vấn lưu
trữ, tìm kiếm, cập nhật… trên cơ sở dữ liệu. Vì cơ sở dữ liệu của hệ thống cần xây dựng
là cơ sở dữ liệu quan hệ nên tầng database sẽ do một hệ quản trị cơ sở dữ liệu quản lý.
Tầng Application Server (tầng trung gian): Có vai trò tiếp nhận các yêu cầu từ client
và xử lý bussiness logic cho hệ thống. Tầng này sẽ trực tiếp giao tiếp với tầng database để
thao tác với cơ sở dữ liệu khi cần. Trong hệ thống Cảnh Báo Giao Thông, các ứng dụng
client sẽ giao tiếp với server thông qua giao thức HTTP qua môi trường internet. Chính vì
vậy chương trình ở tầng trung gian cần xử lý được các request HTTP và gửi về response
phù hợp. Thông thường, tầng trung gian và tầng dữ liệu được triển khai trên một máy tính
hoặc các máy tính trong một mạng nội bộ. Và chỉ tầng giữa mới giao tiếp trực tiếp với
bên ngoài mạng nội bộ để tăng cường tính bảo mật.
Tầng Client: Thông thường với một hệ thống, tầng client sẽ được triển khai trên nhiều
nền tảng khác nhau và cùng sử dụng các dịch vụ do tầng giữa cung cấp. Trong phạm vi đề
tài này, hệ thống Cảnh Báo Giao Thông sẽ tập trung phát triển tầng client trên nền tảng
android cho thiết bị di động.

3.4.2 Truyền dữ liệu gi ữa Client Server
Giao thức được dùng để truyền dữ liệu trong hệ thống Cảnh Báo Giao Thông là HTTP.
Vì bản chất của giao thức này chỉ cho phép truyền dữ liệu dạng text, trong khi giữa tầng
client và server của hệ thống cần truyền cả đối tượng và file ảnh. Giải pháp ở đây đó là sử
dụng các thư viện hỗ trợ chuyển đổi kiểu đối tượng và file ảnh sang dạng text để trước khi
truyền dữ liệu và chuyển đổi ngược lại sau khi nhận dữ liệu. Trong pha cài đặt, hệ thống
sẽ sử dụng JSON (một định dạng hoán vị dữ liệu nhanh) để truyền đối tượng giữa client
và server. Đồng thời sử dụng thư viện MultiPart của Apache cung cấp để truyền file ảnh
đến server thông qua giao thức http. Do phạm vi của đồ án và không phải nội dung chính
nên 2 kỹ thuật này không được trình bày ở đây.
3.4.3 Lựa chọn công nghệ cho các tầng
 Công nghệ sử dụng ở client: Android platform
 Công nghệ sử dụng ở tầng trung gian: Servlet (J2EE platform)
 Cơ sở dữ liệu: MySQL 5.0
3.4.4 Xử lý lưu trữ với cơ sở dữ liệu quan hệ
Trong biểu đồ lớp thiết kế, lớp Location (chứa thông tin tọa độ một điểm) và lớp
Image (chứa đường dẫn ảnh của cảnh báo trên server) gần như không có những thực thế
giống nhau. Chính vì vậy trong cơ sở dữ liệu hai lớp này sẽ được ghép vào các bảng khác
thay vì lưu trữ ở những bảng riêng để phân biệt giữa các thực thể.

CHƯƠNG 4: CÀI ĐẶT VÀ TRIỂN KHAI HỆ THỐNG
Dựa trên việc phân tích hệ thống và các đối tượng, chương này sẽ tập trung trình bày việc
cài đặt, triển khai và ứng dụng của hệ thống.
4.1 Cấu hình phần cứng thử nghi ệm
 Client Mobile: android os 2.3 (phiên bản phổ biến nhất hiện nay)
 Computer Server: Chip core i3 330M, Ram 4Gb
4.2 Cài đặt tri ển khai hệ thống
Do không có điều kiện triển khai hệ thống trên môi trường internet, vì vậy thay vì client
kết nối đến server thông qua ip tĩnh trong môi trường internet, trong phần triển khai này,
client sẽ được kết nối qua mạng cục bộ và ip được đặt cố định.
 Máy tính Server cần triển khai những ứng dụng sau:
o MySQL 5.1: Đây là một ứng dụng hệ quản trị cơ sở dữ liệu phổ biến. Nó đóng vai
trò như là một database server cung cấp service lưu trữ và truy vấn cơ sở dữ liệu.
MySQL có thể cho phép các kết nối từ xa thông qua mạng internet. Tuy nhiên,
theo kiến trúc của hệ thống đã xây dựng, MySQL cần được cấu hình để chỉ chấp
nhận các truy vấn trong mạng nội bộ.
o Apache Tomcat 7: Là ứng dụng server cung cấp các dịch vụ HTTP, FTP…
Apache Tomcat cho phép triển khai các ứng dụng java trên nền tảng J2EE. Cụ thể
ở đây là ứng dụng phía server của hệ thống Cảnh Báo Giao Thông xây dựng trên
công nghệ Servlet.
 Client Android: Như đã nói ở trên, hệ thống sẽ được triển khai giả lập internet. Chính vì
vậy ip của máy server sẽ được đặt cố định và tất cả client sẽ kết nối đến server thông qua
ip đó. Sau khi biên dịch ứng dụng client sang file apk, ứng dụng này sẽ được cài vào thiết
bị mobile android và có thể hoạt động giống như trong môi trường internet.
4.3 Sử dụng và đánh giá kết quả thử nghi ệm
Sau khi đăng nhập, người sử dụng có thể chọn các chức năng từ giao diện chính như
sau:

4.3.1 Chức năng thêm Cảnh báo:
Để sử dụng chức năng này, thiết bị di động của người sử dụng cần có kết nối internet và
có phần cứng GPS. Người dùng sẽ bắt buộc cần có các trường sau trước khi gửi cảnh báo:
Category: Là trường phân loại cảnh báo. Nhằm mục đích giúp người dùng thao tác một
các nhanh nhất khi gửi cảnh báo. Hệ thống đã xây dựng sẵn một danh sách các danh mục
cảnh báo cho người dùng lựa chọn thay vì nhập text.

Description: Đây là trường không bắt buộc. Dùng để mô tả cảnh báo trong trường hợp
thông tin từ Category và Photos chưa thể hiện rõ nội dung, mức độ cảnh báo.
Photos: Cho phép người sử dụng chụp lại hình ảnh lại nơi có vấn đề giao thông bằng máy
ảnh của smartphone. Để hạn chế việc người sử dụng lấy ảnh có sẵn trong thiết bị, ứng
dụng sẽ bắt buộc người dùng phải chụp ảnh mới mỗi khi tạo cảnh báo.

Location: Chứa thông tin vị trí, địa chỉ của cảnh báo. Khi chức năng Send Report
được khởi động. Ứng dụng sẽ tự động cập nhật tọa độ hiện tại của người dùng, đồng thời
tự động thấy địa chỉ của người dùng thông qua google service và hiển thị bản đồ lấy tọa
độ hiện tại của người sử dụng làm trung tâm như hình vẽ dưới đây. Điều này đồng nghĩa
với việc ứng dụng khởi tạo vị trí cảnh báo mặc định là vị trí người dùng. Ứng dụng cho
phép người dùng thay đổi địa chỉ trên TextBox và thay đổi tọa độ của cảnh báo bằng việc
click vào vị trí khác của bản đồ. Sau khi thay đổi vị trí hiện tại, người dùng cũng có thể
quay lại vị trí hiện tại bằng việc click vào biểu tượng hình tròn màu đen.

Để hoàn thành thao tác gửi cảnh báo, người dùng click vào nút Send. Cảnh báo sẽ
được gửi đến server và ứng dụng sẽ hiển thị thông báo của server sau khi nhận được.
4.3.2 Tra cứu cảnh báo trong khu vực
Chức năng này cho phép người sử dụng tra cứu thông tin cảnh báo trong khu vực. Khi
người dùng lựa chọn chức năng này, ứng dụng sẽ hiển thị danh sách các cảnh báo đã được
phê duyệt với các thông tin chung như sau:
 Khoảng cách so với người dùng: Dựa vào tọa độ của cảnh báo lấy từ server và tọa
độ của người dùng thông qua GPS trên smartphone, ứng dụng sẽ tính khoảng cách
theo đường thẳng từ vị trí cảnh báo đến vị trí hiện tại của người dùng
 Một số thông tin cơ bản khác: Như Category của cảnh báo, địa chỉ của cảnh báo.
Ngoài ra, ứng dụng còn cho phép người dùng lọc cảnh báo thông qua thanh Filter.
Người dùng có thể tra cứu nhanh hơn danh sách cảnh báo theo thời gian hoặc category.

Để tra cứu thông tin chi tiết của một cảnh báo, người sử dụng cần click vào cảnh báo
đó. Sau đó ứng dụng sẽ hiển thị đầy đủ thông tin chi tiết của một cảnh báo, bao gồm: danh
mục cảnh báo, mô tả chi tiết, thời gian tạo, album ảnh của tai nạn và bản đồ vị trí của tai
nạn. Người dùng có thể click vào biểu tượng vị trí cảnh báo trên bản đồ để theo dõi địa
chỉ chi tiết.

4.3.3 Tra cứu cảnh báo thông qua Google Map:
Tính năng này cho phép người dùng theo dõi thông tin cảnh báo một cách trực quan
trên Google Map View. Các vị trí có cảnh báo sẽ có biểu tượng đặc biệt. Các biểu tượng
này được hiển thị theo category của cảnh báo. Nghĩa là mỗi loại cảnh báo sẽ có một biểu
tượng riêng. Khi người dùng cũng có thể click vào các biểu tượng khi muốn xem chi tiết
thông tin cảnh báo, như hình sau:

4.3.4 Theo dõi cảnh báo ở gần người dùng:
Tính năng này cho phép người dùng theo dõi các cảnh báo xung quanh vị trí hiện tại
một cách trực quan. Khi khởi tạo chức năng này, ứng dụng sẽ cập nhật tọa độ của người
dùng từ đó thống kê các cảnh báo xung quanh người dùng một bán kính nhất định.
Chức năng này cho phép người dùng theo dõi các cảnh báo dưới 2 dạng là google map
và dưới dạng danh sách.
 Google map: hiển thị vòng tròn bán kinh 500m, có tâm là tọa độ của người
dùng. Ở giao diện này, người dùng có thể dễ dàng quan sát một cách trực quan
các cảnh báo ở cự ly gần.

 Danh sách cảnh báo: Liệt kê các cảnh báo gần người dùng trong một bán kính
nhất định. Các cảnh báo sẽ được sắp xếp theo khoảng cách với người dùng. Để
xem thông tin chi tiết cảnh báo, người dùng có thể click vào cảnh báo cần xem.
4.3.5 Phê duyệt cảnh báo:
Tính năng này cho phép ManagerUser phê duyệt (approve) hoặc hủy (reject) các cảnh báo
được gửi đến server. Ứng dụng hiển thị danh sách các cảnh báo chưa được active như giao diện
dưới đây.

Khi ManagerUser chọn một cảnh báo, ứng dụng sẽ hiển thị giao diện DetailReport với
hai nút Approve và Reject. ManagerUser sẽ dựa vào những thông tin cảnh báo để quyết
định việc phê duyệt hay hủy bỏ cảnh báo. Các cảnh báo được phê duyệt sẽ được sử dụng
để cung cấp thông tin cho tất cả các người dùng khác trong hệ thống.

Traffic warning reportv7

Recommended

Recommended

More Related Content

Similar to Traffic warning reportv7

Similar to Traffic warning reportv7 (20)

Traffic warning reportv7