traffic warning reportv7

Hệ thống Cảnh Báo Giao Thông - 1-

GVHD: Nguyễn Thị Ngọc Vinh SVTH: Nguyễn Đức Hạnh - D08CNPM2

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



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

http://www.vietnamandroid.com/tag/thiet-bi-cam-tay

http://www.vietnamandroid.com/tag/thiet-bi-cam-tay

http://www.vietnamandroid.com/tag/phan-cung-2

http://www.vietnamandroid.com/tag/t-mobile



- 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=”.MyService” />

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.


U2 Login: Đăng nhập




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





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:




U2 Login:




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



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

Healthcare