Khóa luân tốt nghiệp: PHÁT TRIỂN ỨNG DỤNG QUẢN LÝ NGƯỜI DÙNG DỊCH VỤ XE BUÝT TRÊN NỀN ANDROID

67 561 1
Khóa luân tốt nghiệp: PHÁT TRIỂN ỨNG DỤNG QUẢN LÝ NGƯỜI DÙNG DỊCH VỤ XE BUÝT TRÊN NỀN ANDROID

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

... Host-based card emulation Ứng dụng hỗ trợ người dùng DVXB Ứng dụng hỗ trợ người dùng dịch vụ xe buýt Ứng dụng quản lý người dùng DVXB Ứng dụng quản lý người dùng dùng dịch vụ xe buýt X XI DANH MỤC CÁC... thống hai ứng dụng: ứng dụng quản lý người sử dụng dịch vụ xe buýt ứng dụng hỗ trợ người dùng dịch vụ xe buýt việc quản lý tài khoản giao dịch đồ xe buýt để người sử dụng quan sát vị trí xe buýt trạm... Google API Từ khóa: Hệ thống quản lý người dùng dịch vụ xe buýt ,Ứng dụng quản lý người dùng dịch vụ xe buýt, NFC, Ứng dụng hỗ trợ người dùng dịch vụ xe buýt IV ABSTRACT Summary: Nowaday, under

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Quan Tuấn Vũ PHÁT TRIỂN ỨNG DỤNG QUẢN LÝ NGƯỜI DÙNG DỊCH VỤ XE BUÝT TRÊN NỀN ANDROID KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công Nghệ Thông Tin HÀ NỘI - 2014 I ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Quan Tuấn Vũ PHÁT TRIỂN ỨNG DỤNG QUẢN LÝ NGƯỜI DÙNG DỊCH VỤ XE BUÝT TRÊN NỀN ANDROID KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công Nghệ Thông Tin Cán bộ hướng dẫn: TS. Nguyễn Ngọc Hóa Cán bộ đồng hướng dẫn: ThS. Dư Phương Hạnh HÀ NỘI - 2014 II VIETNAM NATIONAL UNIVERSITY, HANOI UNIVERSITY OF ENGINEERING AND TECHNOLOGY Quan Tuan Vu DEVELOPING USER MANAGEMENT APPLICATION IN BUS SERVICE BASE ANDRIOD Major: Engineering and Technology Supervisor: TS. Nguyen Ngoc Hoa Co-Supervisor: ThS. Du Phuong Hanh HA NOI - 2014 III TÓM TẮT NỘI DUNG Tóm tắt: Ngày nay, đi với quá trình đô thị hóa nhanh chóng, nhu cầu di chuyển của con người cũng theo đó tăng lên, mạng lưới xe buýt công cộng cũng theo đó ngày càng mở rộng. Với quy mô ngày càng lớn, việc xác thực người dùng, kiểm soát thanh toán, quản lý và hỗ trợ khách hàng trên xe buýt ngày càng trở nên khó khăn. Khóa luận trình bày về việc xây dựng một phần của hệ thống quản lý người dùng dịch vụ xe buýt. Hệ thống gồm hai phần cơ bản chạy riêng biệt, phần thứ nhất là phía máy chủ cung cấp các dịch vụ web nhằm thao tác dữ liệu với cơ sở dữ liệu – phần này thuộc vào phạm vi khóa luận “Phát triển hệ thống quản lý người dùng dịch vụ xe buýt trên nền tảng Struts2”[31]. Phần thứ hai là phía máy khách dưới dạng ứng dụng Android cũng được chia thành hai phần nhỏ hơn – là phần chính mà khóa luận này nói đến. Khóa luận sẽ trình bày xây dựng hai ứng dụng nhằm giải quyết hai bài toán khác nhau. Ứng dụng quản lý người dùng dịch vụ xe buýt hướng tới việc quản lý khách hàng trên xe buýt, giải quyết bài toán xác thực người dùng bằng thẻ NFC bằng các kết quả trả về của dịch vụ web của phần thứ nhất của hệ thống. Ngoài phần máy chủ thuộc phần một của hệ thống, tôi cũng xây dựng một máy chủ riêng với phạm vi nhỏ hơn, nhằm giải quyết các vấn đề truy xuất về dữ liệu bản đồ xe buýt của ứng dụng thứ hai. Ứng dụng hỗ trợ người dùng dịch vụ xe buýt hướng tới việc trợ giúp khách hàng sử dụng dịch vụ xe buýt, ứng dụng cung cấp cho người sử dụng những thông tin tài khoản, giao dịch trong giới hạn cũng như một bản đồ xe buýt để người sử dụng có thể quan sát được vị trí hiện tại của các xe buýt và các trạm dừng của tuyến xe buýt đó được xây dựng trên dữ liệu trạm xe buýt ở khóa luận “Số hóa hệ thống xe buýt trên nền Google Maps” [30] và Google API. Từ khóa: Hệ thống quản lý người dùng dịch vụ xe buýt ,Ứng dụng quản lý người dùng dịch vụ xe buýt, NFC, Ứng dụng hỗ trợ người dùng dịch vụ xe buýt. IV ABSTRACT Summary: Nowaday, under the rapid growth in urbanization process, the demond for moving is quick increased. As a result, network bus public transportation is more and more wide. The problems of user authentication, payment control, management and support bus service’s customer become to difficult work. This thesis indicate the part of building user management system in bus service. The system include two basic part. The first part is server which provides web services for database interaction. It is a part of another thesis [31]. The second part is client which was two Android application. It’s main content of this thesis. This thesis indicate two Android application which is built to solve two different problems. User management application in bus service is create towards bus customer management, user authencation by using NFC tag and the results of web services. Outside the scope of the first part, I have a small server to solve a database interaction of bus location for the second Android Application. User support application in bus service is build toward support bus customer. This application prodive user information, payments and a map which show current location of buses, bus stop. That map base in data from “Digitize bus system based Google Maps” [30]. . Words: User management system in bus service , User management application in bus service, NFC, User support application in bus service. V LỜI CAM ĐOAN Tôi xin cam đoan những nghiên cứu của tôi về nội dung khóa luận “Phát triển ứng dụng quản lý người dùng dịch vụ xe buýt trên nền Android” mà tôi viết trong khoá luận này là sự thật. Những gì tôi viết ra không sao chép từ các tài liệu, không sử dụng các kết quả của người khác mà không trích dẫn cụ thể. Tôi xin cam đoan ứng dụng này tôi trình bày trong khoá luận là do tôi tự phát triển, không sao chép mã nguồn của người khác.Nếu sai tôi hoàn toàn chịu trách nhiệm theo quy định của trường Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội Hà Nội, ngày tháng năm Sinh viên Quan Tuấn Vũ VI LỜI CẢM ƠN Khóa luận tốt nghiệp được hoàn thành tại Đại học Công Nghệ - Đại học Quốc Gia Hà Nội. Có được kết quả của khóa luận tốt nghiệp này, tôi xin bày tỏ lòng biết ơn chân thành và sâu sắc đến Đại học Công Nghệ - Đại học Quốc Gia Hà Nội, đặc biệt là thầy giáo Nguyễn Ngọc Hóa đã nhiệt tình chỉ bảo hướng dẫn, dìu dắt, giúp đỡ và đóng góp những ý kiến quý báu cho tôi để hoàn thành khóa luận tốt nghiệp này. Xin gửi lời cảm ơn chân thành toàn thể các thầy cô trường Đại học Công Nghệ đại học Quốc Gia Hà Nội đã dạy dỗ và truyền đạt những kiến thức quí báu cho tôi trong những năm tháng qua. Cuối cùng, tôi xin được cảm ơn cha mẹ, bạn bè và người thân, những người đã ở bên tôi, khuyến khích và động viên tôi trong cuộc sống, học tập. Trong quá trình hoàn thành khóa luận tốt nghiệp, Tôi mặc dù đã rất cố gắng tuy nhiên sẽ không tránh khỏi những hạn chế về mặt kiến thức và cũng như kinh nghiệm mà tự mình không thể nhìn thấy được. Vậy nên, tôi rất mong nhận được sự đóng góp, phê bình của quý thầy cô, các nhà khoa Hà Nội, ngày 14 tháng 5 năm 2014 Sinh viên học, đọc giả và các bạn. Xin chân thành cảm ơn! Quan Tuấn Vũ VII MỤC LỤC Contents TÓM TẮT NỘI DUNG..........................................................................................iv ABSTRACT.............................................................................................................v LỜI CAM ĐOAN...................................................................................................vi LỜI CẢM ƠN........................................................................................................vii MỤC LỤC.............................................................................................................viii BẢNG DANH MỤC TỪ VIẾT TẮT......................................................................x DANH MỤC CÁC HÌNH VẼ...............................................................................xii DANH MỤC BẢNG BIỂU..................................................................................xiii CHƯƠNG 1:GIỚI THIỆU.......................................................................................1 CHƯƠNG 2:LÝ THUYẾT LIÊN QUAN...............................................................3 2.1. Tổng quan về Android..................................................................................3 2.1.1. Giới thiệu chung.....................................................................................3 2.1.2. Một số đặc điểm của Android................................................................3 2.1.3. Kiến trúc Android..................................................................................5 2.1.4. Các thành phần chính trong một ứng dụng Android:............................6 2.2. Giới thiệu về công nghệ NFC và Android NFC API...................................7 2.2.1. Giới thiệu về Công nghệ NFC...............................................................7 2.2.2. Android NFC API................................................................................10 2.3. Google Maps Android API.........................................................................15 2.3.1. Các đối tượng Map..............................................................................16 2.3.2. Vẽ trên bản đồ......................................................................................17 2.3.3. Tương tác với bản đồ...........................................................................18 2.3.4. Dữ liệu về tọa độ..................................................................................18 2.3.5. Thay đổi góc nhìn................................................................................18 VIII 2.4. Hệ quản trị cơ sở dữ liệu MySQL..............................................................19 2.5. Cơ sở dữ liệu nhúng SQLite ......................................................................19 CHƯƠNG 3: XÂY DỰNG HỆ THỐNG..............................................................22 3.1. Mô hình hệ thống........................................................................................22 3.2. Phân tích và xác định yêu cầu.....................................................................24 3.2.1. Ứng dụng quản lý người dùng dịch vụ xe buýt...................................24 3.2.2. Ứng dụng hỗ trợ người dùng dịch vụ xe buýt ....................................33 3.3. Thiết kế........................................................................................................39 3.3.1. Kiến trúc ứng dụng..............................................................................39 3.3.2. Xác định gói thiết kế............................................................................39 3.3.3. Thiết kế cho từng ca sử dụng...............................................................40 3.3.4. Thiết kế giao diện.................................................................................45 CHƯƠNG 4: THỰC NGHIỆM.............................................................................48 4.1. Môi trường thực nghiệm.............................................................................48 4.1.1. Cấu hình thiết bị...................................................................................48 4.1.2. Các công cụ phần mềm........................................................................49 4.2. Kết quả thực nghiệm...................................................................................49 4.3. Đánh giá và hướng phát triển......................................................................50 CHƯƠNG 5: KẾT LUẬN.....................................................................................51 TÀI LIỆU THAM KHẢO......................................................................................52 Tiếng Anh...........................................................................................................52 Tiếng Việt...........................................................................................................53 IX BẢNG DANH MỤC TỪ VIẾT TẮT NFC Near field communication HCE Host-based card emulation Ứng dụng hỗ trợ người dùng DVXB Ứng dụng hỗ trợ người dùng dịch vụ xe buýt Ứng dụng quản lý người dùng DVXB Ứng dụng quản lý người dùng dùng dịch vụ xe buýt X XI DANH MỤC CÁC HÌNH VẼ XII DANH MỤC BẢNG BIỂU XIII CHƯƠNG 1: GIỚI THIỆU Với tốc độ tăng trưởng chóng mặt như hiện nay, các nghành cũng phát triển với quy mô rộng lớn, đặc biệt với nghành dịch vụ. Một nền kinh tế năng động phải có các nghành dịch vụ phát triển với nhiều loại hình. Khi kinh tế phát triển, nhu cầu con người ngày càng cao, xu thế xuất hiện những nhu cầu mới phục vụ những nhu cầu đó như các dịch vụ khách sạn, du lịch, chăm sóc sức khỏe,… Trong số các nhu cầu đó cần tính đến nhu cầu di chuyển. Tại nước ta đặc biệt Hà Nội nhu cầu di chuyển của người dân là rất lớn, vì vậy dịch vụ xe buýt công cộng hiện nay đang rất sôi động. Theo Tổng công ty Vận tải Hà Nội, năm 2009 đã có 385 triệu hành khách đi xe buýt chiếm trên 92% sản lượng vận chuyển của toàn thành phố. Ước tính, trung bình mỗi ngày xe buýt vận hành trên 10.000 lượt xe, vận chuyển được trên 1 triệu lượt hành khách, hạn chế trên 700.000 lượt xe máy tham gia giao thông trên đường phố [32]. Với hệ thống xe buýt bao phủ khắp Hà Nội đã giảm đáng kể số vụ tai nạn trong thành phố, cũng như giảm tắc đường, bảo vệ môi trường của thủ đô. Xe buýt không ngừng phục vụ cho những nhu cầu cần thiết của con người như: đi học, đi làm, … Tuy nhiên, với số lượng hành khách quá đông như hiện nay, khả năng đáp ứng của xe buýt là hoàn toàn không đủ và việc xác thực người dùng dịch, kiểm soát thanh toán trên một chuyến xe cũng như việc hỗ trợ khách hàng là khó thực hiện. Cũng vì lý do trên, chúng tôi thực hiện đề tài này nhằm xây dựng một hệ thống quản lý người dùng dịch vụ xe buýt để khắc phục các vấn đề về xác thực người dùng và kiểm soát thanh toán trên xe buýt và hỗ trợ khách hàng để cải thiện thực trạng hiện nay. Trong phạm vi khóa luận này, tôi sẽ đi sâu vào các nội dung xung quanh phần thứ hai của hệ thống là hai ứng dụng: ứng dụng quản lý người sử dụng dịch vụ xe buýt và ứng dụng hỗ trợ người dùng dịch vụ xe buýt trong việc quản lý tài khoản giao dịch của mình và một bản đồ xe buýt để người sử dụng có thể quan sát được vị trí hiện tại của các xe buýt và các trạm dừng của tuyến xe buýt đó. Để xây dựng được ứng dụng quản lý người dùng dịch vụ xe buýt, bài toán đặt ra trước hết là cách để định danh duy nhất một người sử dụng duy nhất. Cách định danh phổ biến và thường được sử dụng là mỗi người dùng dịch vụ xe buýt thường được cấp phát một thẻ xe buýt trong đó ghi rõ nội dung cần thiết để xác thực người sử dụng và tình trạng sử dụng dịch vụ hiện tại của người xe buýt đó. Tuy nhiên, thẻ định danh 1 hiện tại đang được sử dụng tại Việt Nam là loại thẻ giấy và việc xác thực người dùng dịch vụ xe buýt được thực hiện một cách thủ công để xác thực chính xác thì mất nhiều thời gian, khó có thể thống kê và có thể dễ dàng làm giả. Vậy cách để định danh người dùng dịch vụ xe buýt phải đảm bảo độ tin cậy về thông tin, tốc độ nhanh, an toàn và có thể thực hiện tự động. Theo các điều kiện đặt ra ở trên, ý tưỏng của tôi là xác thực người sử dụng thông qua thẻ từ: cụ thể là loại thẻ NFC. Như vậy việc định danh người sử dụng sẽ định danh thông qua ID của thẻ, thông tin người sử dụng sẽ được lưu trên một máy chủ và truy vấn thông qua các dịch vụ web. Ứng dụng quản lý người dùng dịch vụ xe buýt sẽ là trung gian giao tiếp giữa thẻ từ NFC định danh người dùng và dịch vụ web thẩm định người dùng. Điều này có nghĩa là mỗi xe buýt sẽ được trang bị một thiết bị có khả năng đọc thẻ từ, ở đây tôi chọn thiết bị Android có hỗ trợ đọc thẻ từ NFC. Còn với ứng dụng hỗ trợ người dùng dịch vụ xe buýt, ngoài việc sử dụng thẻ NFC để định danh người sử dụng như ứng dụng quản lý người dùng dịch vụ xe buýt đã nói ở phần trên. Đối với bài toán còn lại là làm việc với dữ liệu bản đồ, tôi sẽ giải quyết bài toán này thông qua Google Maps API vì tính phổ biến, dữ liệu vừa đủ và sự đa dạng trong các tính năng mà nó cung cấp trên nền Android cùng với dữ liệu các trạm xe buýt được số hóa ở khóa luận “Số hóa hệ thống xe bus trên nền Google Maps” [30], và các dịch vụ web để giải quyết bài toán hiển thị bản đồ xe buýt. Nội dung khóa luận bao gồm 4 chương: Chương 1 - Giới thiệu: Nêu thực trạng, giới thiệu bài toán, ý tưởng xây dựng và các vấn đề sẽ được trình bày. Chương 2 – Các công cụ được sử dụng: Nêu những công cụ, cơ sở lý thuyết được áp dụng để thực hiện hệ thống. Chương 3 - Xây dựng hệ thống: Trình bày về mô hình của hệ thống, cấu trúc và cách giải quyết của từng phần của hệ thống. Chương 4 – Thực nghiệm: Trình bày về cách sử dụng hệ thống, những kết quả đã đạt được. Đánh giá và trình bày hướng phát triển tiếp theo của hệ thống. Chương 5 – Kết luận: Tóm tắt lại quá trình xây dựng, những kết quả đã đạt được, ý nghĩa thực tiễn của hệ thống. 2 CHƯƠNG 2: LÝ THUYẾT LIÊN QUAN 2.1. Tổng quan về Android 2.1.1. Giới thiệu chung Android là một hệ điều hành mã nguồn mở dành cho thiết bị di động như điện thoại thông minh và máy tính bảng. Được phát triển bởi Liên minh thiết bị cầm tay mở rộng, dẫn đầu là Google. Từ quan điểm của nhà phát triển, Android là một hệ điều hành xây dựng trên nhân Linux. Nó bao gồm giao diện cảm ứng, widgets, camera, … và tập các chức năng cần thiết để có thể được gọi là điện thoại thông minh. Android là một nền tảng hỗ trợ các ứng dụng khác nhau, có sẵn trong Google Play Store. Nền tảng Android cũng cho phép người dùng có thể phát triển, cài đặt và sử dụng ứng dụng của họ. Android FrameWork được cấp phép theo chứng chỉ Apache. 2.1.2. Một số đặc điểm của Android Android cung cấp đầy đủ bộ phần mềm cho các thiết bị di động bao gồm: hệ điều hành, middleware (các phần mềm có nhiệm vụ kết nối các thành phần phần mềm và các ứng dụng với nhau) và ứng dụng di động cốt lõi. 2.1.2.1. Tính mở Android là một hệ điều hành mã nguồn mở, có thể tự do mở rộng để kết hợp thêm các công nghệ mới. Android được xây dựng trên cơ sở cho phép các nhà phát triển tạo ra các ứng dụng di động dựa trên toàn bộ chức năng mà di động có. Ví dụ như, ứng dụng có thể thực hiện các chức năng cốt lõi của điện thoại như: thực hiện cuộc gọi, gửi tin nhắn văn bản hoặc sử dụng máy ảnh,… Điều này cho phép các nhà phát triển tạo ra các ứng dụng mang đến sự trải nghiệm phong phú và gần gũi với người dùng. Android được xây dựng trên nhân Linux (là phần mềm mở và miễn phí) và sử dụng máy ảo được thiết kế và tối ưu hóa bộ nhớ và tài nguyên phần cứng trong môi trường di động. 3 Android có một cộng đồng các lập trình viên và những người đam mê rất năng động. Họ sử dụng mã nguồn Android để phát triển và phân phối những phiên bản chỉnh sửa của hệ điều hành. 2.1.2.2. Tính ngang bằng giữa các ứng dụng Android không phân biệt các ứng dụng cốt lõi và các ứng dụng được phát triển bởi bên cung cấp thứ ba. Mọi ứng dụng đều được phát triển trên cơ sở truy cập toàn bộ chức năng của thiết bị di động nhằm cung cấp cho người dùng các ứng dụng và dịch vụ phong phú. Với các thiết bị xây dựng trên nền tảng Android, người dùng có thể tùy chỉnh thiết bị theo cách họ mong muốn. Ví dụ như, cài đặt bất cứ ứng dụng nào, thay đổi màn hình chính của thiết bị, thiết đặt cách xử lý các sự kiện bằng các ứng dụng mà họ nghĩ là phù hợp. 2.1.2.3. Phá vỡ ranh giới ứng dụng Android phá vỡ các rào cản cần thiết nhằm hướng tới xây dựng các ứng dụng mới và sáng tạo nhờ vào khai thác tối đa chức năng của phần cứng. Ví dụ như, nhà phát triển có thể xây dựng các ứng dụng chụp ảnh với nhiều đổi mới so với ứng dụng cốt lõi có sẵn. 2.1.2.4. Phát triển các ứng dụng một cách nhanh chóng và dễ dàng Các ứng dụng cho Android được phát triển bằng ngôn ngữ Java sử dụng bộ phát triển phần mềm Android (SDK). SDK bao gồm một bộ đầy đủ các công cụ dùng để phát triển, gồm có công cụ gỡ lỗi, thư viện phần mềm, bộ giả lập điện thoại dựa trên QEMU, tài liệu hướng dẫn, mã nguồn mẫu, và hướng dẫn từng bước. Môi trường phát triển tích hợp (IDE) được hỗ trợ chính thức là Eclipse sử dụng phần bổ sung Android Development Tools (ADT). Các công cụ phát triển khác cũng có sẵn, gồm có Bộ phát triển gốc dành cho các ứng dụng hoặc phần mở rộng viết bằng C hoặc C++, Google App Inventor, một môi trường đồ họa cho những nhà lập trình mới bắt đầu, và nhiều nền tảng ứng dụng web di động đa nền tảng phong phú. 2.1.2.5. Quản lý bộ nhớ Android được thiết kế quản lý bộ nhớ (RAM) nhằm giảm tối thiệu tiêu thụ điện năng. Khi một ứng dụng Android không còn được sử dụng, hệ thống sẽ tự động ngưng hoạt động của ứng dụng đó, mặc dù thực sự là nó vẫn ở trạng thái mở. Vì điều đó, các ứng dụng được tạm ngưng không tiêu thụ tài nguyên và được khởi động lại khi cần 4 thiết. Điều này giúp cho Android tăng khả năng đáp ứng người dùng (ứng dụng cần khởi động lại), mặt khác đảm bảo tối thiệu tiêu hao năng lượng của ứng dụng nền. Quản lý bộ nhớ được thực hiện một cách tự động: khi bộ nhớ đầy hệ thống sẽ bắt đầu diệt ứng dụng và tiến trình không hoạt động được một thời gian, sắp theo thời điểm cuối mà chúng được sử dụng. 2.1.2.6. Bảo mật và riêng tư Các ứng dụng được giới hạn trong phạm vi tài nguyên của chính mình, chúng được hoạt động một cách riêng biệt và không được phép chạm đến phần tài nguyên còn lại ngoại trừ người sử dụng trao quyền đó một cách công khai cho ứng dụng khi cài đặt. Điều này làm giảm bớt ảnh hưởng của lỗi bảo mật hoặc lỗi chương trình có trong ứng dụng. 2.1.3. Kiến trúc Android Kiến trúc Android (Hình 2.1) được chia làm bốn tầng bao gồm: - Tầng một: tầng Application là tầng ở trên cùng cách xa với phần cứng nhất, nó chứa các ứng dụng mà lập trình viên phát triển. Tầng hai: Application Framework. Một vài trong đó là: o Activity Manager: quản lý vòng đời của các Activity. o Windows Manager: quản lý form của các ứng dụng. o Content Providers: cho phép các ứng dụng truy cập dữ liệu từ các ứng dụng khác hoặc để chia sẻ dữ liệu của riêng ứng dụng o View UI - để xây dựng layout của ứng dụng. o Resource Manager - cung cấp cách thức truy cập đến non-code resources. o Notification Manager - cho phép tất cả các ứng dụng hiển thị thông báo của mình trên hệ điều hành. o Google xây dựng cho các developer để phát triển các ứng dụng của họ - - trên Android chỉ bằng cách gọi các API. Tầng ba: Libraries.là các thư viện được viết bằng ngôn ngữ C/C++ sẽ được các developer phát triển ứng dụng android thông qua tầng Android Framework. Có thể kể ra đây một số thư viện quen thuộc với các lập trình viên như: Media Libraries, Surface Manager, LibWebCore, …. Tầng bốn: Nhân Linux. 5 Hình 2.1. Mô hình kiến trúc phần mềm Android 2.1.4. Các thành phần chính trong một ứng dụng Android: Một ứng dụng Android thường có các thành phần sau: - Activity: là một thành phần của ứng dụng cung cấp một giao diện mà người - dùng có thể tương tác vào đó để thực hiện một hành động nào đó. Service: là một thành phần chạy ngầm trong Android và không có giao diện. - Khi được bật. Service dùng để update dữ liệu, đưa ra các cảnh báo (Notifacation) và không bao giờ hiển thị cho người dùng nhìn thấy. Broadcast Receiver(BR): là thành phần để thu nhận các Intent thông báo từ hệ - điều hành (pin yếu, có sms, có cuộc gọi đến..) hoặc từ chính trong ứng dụng của chúng ta. BR cũng không có giao diện người dùng. Content Provider: cho phép ứng dụng truy suất, chỉnh sửa và chia sẻ dữ liệu riêng với nhau. 6 - Intent và bộ lọc Intent: là một đối tượng dùng để thông báo yêu cầu hành - động từ một thành phần khác như: khởi động một Activity, một Service hoặc cung cấp một BR. App Widgets: là một ứng dụng nhỏ có thể được nhúng trong các ứng dụng - khác và được cập nhập một cách định kỳ. Processes và Threads. 2.2. Giới thiệu về công nghệ NFC và Android NFC API 2.2.1. Giới thiệu về Công nghệ NFC 2.2.1.1. Khái quát về NFC Near Field Communication là tập hợp các tiêu chuẩn cho smartphone và các thiết bị tương tự có thể thiết lập một kết nối thông qua sóng radio khi các thiết bị đó nằm trong một phạm vi đủ gần. Kết nối cũng có thể được thiết lập giữa các thiết bị NFC và chip NFC không dùng năng lượng ( hay còn gọi là thẻ NFC).[1][2] NFC xây đựng dựa trên các hệ thống RFID : là các hệ thống chỉ giao tiếp một chiều từ các thẻ thông minh, NFC cải tiến hơn so với RFID. Nó cho phép giao tiếp hai chiều giữa các thiết bị đầu cuối. Một trong những thể hiện của việc giao tiếp này là tính năng Android Beam trên thiết bị thông minh Android. Android Beam sử dụng NFC để bật Bluetooth ở cả hai thiết bị và tự động tăt Bluetooth khi kết thực hiện xong một công việc nào đó. S-Beam là mở rộng của AndroidBeam, sử dụng NFC để chia sẻ địa chỉ MAC và IP và thực hiện công việc trực tiếp trên mạng WIFI thay cho Bluetooth.[3] Thiết bị NFC có thể sử dụng cho việc thanh toán điện tử, tương tự với các loại thẻ tín dụng và thẻ điện tử thông minh.Như Google Wallet cho phép người tiêu dùng lưu trữ thông tin thẻ tín dụng trong một chiếc ví ảo sau đó sử dụng thiết bị NFC với thiết bị đọc thẻ chấp nhận giao dịch Master Card PayPass.[4] Germany[5], Austria[6], Finland[7], New Zealand[8] , Italy[9], Iran[10] và Turkey[11] đã có hệ thống vé NFC cho dịch vụ xe công cộng. 2.2.1.2. Các thông số kỹ thuật của thẻ NFC NFC là một tập hợp các công nghệ không dây tầm ngắn ( phạm vi 10 cm hoặc ít hơn ). NFC hoạt động ở tần số 13,56 MHz trên chuẩn ISO/IEC 18000-3 và tốc độ từ 106 kbit/s tới 424 kbit/s. NFC luôn có một đối tượng khởi động và một đối tượng mục tiêu. Nếu mục tiêu là đối tượng bị động, đối tượng khởi động tạo ra một vùng RF cung cấp năng lượng cho mục tiêu bị động. Cho nên đối tượng NFC có hình thức đơn giản 7 như : thẻ, thẻ dán, thẻ không cần pin. Nếu cả hai đối tượng đều chủ động thì cả hai thiết bị đều là đối tượng khởi động (nguồn cung cấp điện) và luân phiên tạo ra các vùng riêng, thiết bị chờ dữ liệu sẽ vô hiệu hóa trường RF của chính nó. Giao tiếp NFC pear-to-pear có thể kích hoạt khi hai thiết bị NFC đang bật.[3] Năng lượng RF tập trung trong phạm vi ±7 KHZ phạm vi băng thông, nhưng đường bao phổ đầy đủ có thể rộng tới 1.8 MHz khi sử dụng biến điệu ASK.[12] Thẻ NFC chứa dữ liệu và thường chỉ đọc, và có thể cho phép ghi đè. Thẻ NFC có thể được tùy chỉnh bởi nhà sản xuất hoặc sử dụng các thông số kỹ thuật được cung cấp trong diễn đàn NFC. An toàn lưu dữ liệu cá nhân trong thẻ NFC như thẻ ghi nợ và thẻ tín dụng, mã PIN và các thông tin khác. Diễn đàn NFC định nghĩa có bốn loại thẻ NFC có tốc độ truyền thông khác nhau về cấu hình, bảo mật, dữ liệu lưu trữ và độ bền. Bộ nhớ của thẻ từ 96 đến 4096 bytes. 2.2.1.3. So sánh với Bluetooth NFC và Bluetooth đều là công nghệ giao tiếp tầm ngắn và được tích hợp vào điện thoại di động. NFC hoạt động ở tốc độ chậm hơn so với Bluetooth, nhưng tiêu thụ ít điện năng và không yêu cầu ghép nối. NFC thiết lập nhanh hơn so với Bluetooth, nhưng có tốc độ truyền chậm hơn so với Bluetooth ngay cả ở trạng thái năng lượng thấp. Với NFC, thay vì thực hiện các công việc thủ công để xác định các thiết bị, kết nối của hai thiết bị NFC được thiết lập một cách nhanh chóng (chưa tới 1/10 giây).Với khoảng cách tối đa là 20cm, NFC có khoảng cách ngắn làm giảm khả năng bị chặn dẫn đến ngắt trong khu vực đông đúc. Trái ngược với Bluetooth, NFC tương thích với hạ tầng công nghệ RFID thụ động (13.56 MHz ISO/IEC 18000-3) [13]. 2.2.1.4. Tổ chức tiêu chuẩn và dự án công nghiệp Tiêu chuẩn: NFC được chấp nhận là tiêu chuẩn ISO/IEC vào 8/10/2003 và chuẩn ECMA. NFC là một công nghệ mở được chuẩn hóa ECMA-340 và ISO/IEC 18092 . Tiêu chuẩn quốc tế này quy định cụ thể : tiêu chuẩn sản xuất, mã hóa, tốc độ truyền, định dạng khung và giao diện RF, cũng như khởi tạo các phương án và điều kiện cần thiết để kiểm soát xung đột dữ liệu trong quá trình khởi tạo. Hơn nữa, tiêu chuẩn này định nghĩa giao thức vận chuyển bao gồm cả giao thức kích hoạt và phương pháp trao đổi dữ liệu. Giao diện không khí cho NFC được chuẩn hóa tại: ISO/IEC 18092 / ECMA-340[14] và ISO/IEC 21481 / ECMA-352[15]. NFC cũng bao gồm cả chuẩn ISO/IEC 14443 A, B, và FeliCa. Ngoài ra diễn đàn NFC đã xác định kiểu dữ liệu phổ biến là NFC Data Exchange Format (NDEF). GSMA: Hiệp hội GSMA là hiệp hội thương mại toàn cầu đại diện cho 800 nhà vận hành điện thoại di động và 200 công ty sản phẩm và dịch vụ trên 219 quốc gia. 8 Nhiều tổ chức trong đó đã thực nghiệm công nghệ NFC trên toàn thế giới và đang chuẩn bị cho quá trình thương mại hóa [16]. GSMA có liên quan đến: - Thiết lập tiêu chuẩn: GSMA đang phát triển chứng nhận và thử nghiệm để đảm bảo khả năng tương tác toàn cầu của dịnh vụ NFC [16]. Xác định cách tiếp cận toàn cầu chung nhất để sử dụng NFC để liên kết các thiết bị NFC với hệ thống thanh toán không tiếp xúc [17][18]. 17/11/2010. AT&T, Verizon và T-Mobile ra mất công ty liên doanh (ISIS) nhằm phát triển nền tảng duy nhất sử dụng công nghệ NFC để thanh toán di động. ISIS cho phép thiết bị NFC có chức năng như thẻ tín dụng cho 200 triệu khách hàng. Diễn đàn NFC: là một hiệp hội phi lợi nhuận được thành lập vào 18/3/2004 bởi NXP Semiconductors, Sony và Nokia để thúc đẩy việc sử dụng NFC trong thiết bị điện tử tiêu dùng, thiết bị di động và máy tính. NFC Forum thúc đẩy việc thực hiện và tiêu chuẩn của công nghệ NFC để đảm bảo khả năng tương tác giữa các thiết bị và dịch vụ. Tính đến tháng 6 năm 2013, Diễn đàn NFC đã có hơn 190 thành viên.[19] 2.2.1.5. Các khía cạnh an toàn Mặc dù phạm vi giao tiếp của NFC chỉ giới hạn trong một vài centimet nhưng công nghệ NFC không đảm bảo thông tin liên lạc được an toàn. Năm 2006, Ernst Haselsteiner và Klemens Breitfuß đã liệt kê các loại tấn công có thể xảy ra khi sử dụng thẻ NFC [20]. NFC không cung cấp phòng chống việc nghe trộm thông tin và dễ bị tổn thương bởi thay đổi dữ liệu. Ứng dụng phải sử dụng các phương thức cao hơn như giao thức mã hóa để thiết lập an toàn. Các kiểu tấn công khi sử dụng thẻ NFC bao gồm: - - - Nghe trộm: Tín hiệu RF trong giao tiếp không dây có thể bắt được bằng ăng ten. Phạm vi có thể nghe trộm tín hiệu RF phụ thuộc vào nhiều thông số. Thường là 10m với thiết bị chủ động và 1m cho thiết bị thụ động.[20] [21] Sửa đổi dữ liệu: Có thể dễ dàng phá hủy dữ liệu bằng sóng nhiễu. Không có cách nào hiện nay có thể ngăn chặn được sự tấn công này. Tuy nhiên, nếu thiết bị NFC kiểm tra vùng RF trong khi đang gửi dữ liệu thì nó có thể phát hiện dược các cuộc tấn công. Tấn công chuyển tiếp: Các thiết bị NFC bao gồm các chuẩn giao thức ISO / IEC 14443, các kiểu tấn công chuyến tiếp cũng có tính khả thi. Trong kiểu tấn công này, kẻ tấn công có thể chuyển các yêu cầu của người đọc cho nạn nhân và chuyển tiếp câu trả lời của kẻ tấn công cho người đọc, để kẻ tấn công có thể giả mạo là chủ của chiếc thẻ. Cũng tương tự như kiểu tấn công “người ở giữa”. 9 - - Mất tài sản: Mất thẻ RFID, NFC sẽ cung cấp cho người tìm thấy mọi thông tin chứng thực được lưu trong thẻ của người mất. Để thiết giải quyết vấn đề này, cần nhiều hơn một yếu tố xác thực vật lý. Walk-off : Sau khi mở quyền truy cập vào một chức năng, hoặc dữ liệu NFC, hệ thống thườmg đặt chế độ time-out khi không sử dụng. Cuộc tấn công có thể xảy ra vào thời điểm hệ thống chưa time-out. Cách giải quyết kiểu tấn công cần nhiều hơn một yếu tố xác thực vật lý. 2.2.2. Android NFC API Thẻ NFC có độ phức tạp, tinh vi tùy vào loại thẻ. Loại đơn giản chỉ cung cấp đọc và viết, đôi khi cũng có một số trường trong thẻ được dùng để quy định thẻ chỉ có thể được đọc. Thẻ phức tạp hơn cung cấp các hoạt động toán học, có phần cứng mã hóa để phân quyền truy cập vào khu vực của thẻ. Thẻ thiết kế tinh vi nhất cung cấp tương tác phức tạp với mã thực thi trên thẻ. Dữ liệu trong thẻ NFC thường có chung một định dạng khung, hầu hết Android NFC API được xây dựng trên chuẩn NDEF (NFC Data Exchange Format) của diễn đàn NFC. Thiết bị Android hỗ trợ NFC với ba chế độ chính: - Chế độ đọc/ ghi. Cho phép thiết bị đọc và ghi các thẻ, thẻ dán NFC bị động. Chế độ P2P. Cho phép các thiết bị NFC trao đổi dữ liệu thông qua chức năng Android Beam. Chế độ giả lập thẻ. Cho phép thiết bị Android hoạt động như một thẻ NFC. 2.2.2.1. Các vấn đề cơ bản của NFC trong Android 2.2.2.1.1. Hệ thống công văn thẻ Các thiết bị Android thường tìm kiếm thẻ NFC khi màn hình mở khóa và chế độ NFC được bật. Hệ thống này thực thi phân tích thẻ đã được thiết bị phát hiện, phân loại dữ liệu và khởi động ứng dụng quan tâm đến dữ liệu thu nhập được bằng cách: - Phân tích thẻ NFC và tìm ra định dạng MIME hoặc URI. Đóng gói hai định dạng trên vào một intent. Bắt đầu một hoạt động dựa trên intent. 2.2.2.1.2. Cơ chế ánh xạ NFC tới định dạng MIME, URI NDEF được đóng gói bên trong một tin nhắn ( NdefMessage ) có chứa các bản ghi ( NdefRecord ). Mỗi NdefRecord phải được hình thành theo các đặc điểm kỹ thuật của loại bản ghi. Khi thiết bị Android quét một thẻ NFC chứa dữ liệu định dạng NDEF. Từ NdefMessage quét được, hệ thống phân tích NdefMessage nhằm tìm các định dạng MIME và URI. Để thực hiện điều đó, hệ thống đọc NdefRecord đầu tiên 10 trong NdefMessage để xác định cách đọc toàn bộ dữ liệu NDEF. Một NdefMessage tốt có cấu trúc NdefRecord đầu tiên như sau: - 3-bit TNF: tên của loại định dạng. Variable length type: lưu giữ loại của bản ghi. Variable length ID: định danh cho bản ghi. Variable length payload: tải trọng thực tế của dữ liệu để đọc hoặc viết. Hệ thống công văn thẻ sử dụng NdefRecord đầu tiên để ánh xạ định dạng MIME và URI. Nếu thành công, thông tin đó được đóng gói trong một intent ACTION_NDEF_DISCOVERED. Trong một số trường hợp, hệ thống này không xác định dược NdefRecord đầu tiên (đồng nghĩa với việc không thể ánh xạ định dạng MIME hay URI hoặc dữ liệu không bắt đầu với kiểu cấu trúc NDEF). Trong trường hợp này, thông tin về các công nghệ thẻ và tải trọng thực tế được đóng gói trong intent ACTION_TECH_DISCOVERED. 2.2.2.1.3. Cơ chế kích hoạt ứng dụng qua thẻ NFC Khi thông tin được đóng trong một intent, hệ thống công văn thẻ sẽ gửi intent đó tới các ứng dụng quan tâm tới intent đó. Nhìn chung có ba loại intent chính cho cơ chế quét thẻ NFC: - ACTION_NDEF_DISCOVERED: intent này nhằm kích hoạt các Activity khi thẻ chứa dữ liệu NDEF. Đây là loại intent được ưu tiên hàng đầu, nó sẽ được ưu tiên kích hoạt hàng đầu so với hai kiểu intent còn lại. - ACTION_TECH_DISCOVERED: nếu không có Activity nào đăng kí xử lý intent ACTION_NDEF_DISCOVERED: hệ thống công văn thẻ sẽ cố gắng kích hoạt ứng dụng đăng ký xử dụng loại thẻ này. Intent này cũng được kích hoạt đầu tiên, nếu thẻ quét được không chứa kiểu dữ liệu NDEF. - ACTION_TAG_DISCOVERED nếu không có Activity nào đăng kí xử lý ACTION_NDEF_DISCOVERED và ACTION_TECH_DISCOVERED intent này được kích hoạt. Các hoạt động cơ bản của hệ thống công văn thẻ hoạt động: - Cố gắng kích hoạt Activity bởi intent đã được tạo khi quét thẻ NFC (ACTION_NDEF_DISCOVERED hoặc ACTION_TECH_DISCOVERED). - Nếu không có Activity nào được kích hoạt, kích hoạt Activity với độ ưu tiên thấp nhất (ACTION_TECH_DISCOVERED hoặc ACTION_TAG_DISCOVERED). - Nếu không ứng dụng nào được kích hoạt. Thì không làm gì. 11 Hình 2.2. Cơ chế hoạt động của Hệ thống công văn Thẻ [22] 2.2.2.1.4. Lấy thông tin từ Intent NFC intent có thể chứa các thành phần sau của thẻ được quét: - EXTRA_TAG: Đối tượng thẻ (tag) đại diện cho thẻ được quét. EXTRA_NDEF_MESSAGE: Một mảng các NdefMessage phân tích được từ thẻ ( thành phần bắt buộc có trong intents). EXTRA_ID: định danh cấp thấp của thẻ. 2.2.2.1.5. Tạo NdefRecord phổ biến Từ phiên bản Android 4.0 ( API level 14)[22], Android hỗ trợ việc tạo Uri tự động. Từ phiên bản 4.1 (API lv 16) [22], hỗ trợ các phương thức tạo MIME và các NdefRecord mở rộng. 2.2.2.1.6. Android Application Record (AAR) AAR được hỗ trợ ở phiên bản Android 4.0 trở lên. AAR chắc chắn cho ứng dụng được ưu tiên khi xử lý NdefMessage thông qua tên gói được nhúng trong một NdefRecord. Có thể thêm AAR vào bất cứ NdefRecord nào của NdefMessage, bởi vì Android tìm kiếm AAR trên tất cả NdefRecord của NdefMessage. Nếu tìm thấy AAR, Android kích hoạt ứng dụng qua tên gói của ứng dụng được nhúng trong AAR. Nếu không tìm thấy ứng dụng, Android sẽ bật Google Play để tìm kiếm ứng dụng và tải về. AAR được sử dụng để ngăn các ứng dụng khác cùng xử lý một itent mà lập trình viên triển khai trong thẻ NFC. AAR chỉ hỗ trợ ở mức độ ứng dụng, bộ lọc Intent hỗ trợ ở mức Activity. Một thẻ NFC có chứa AAR, sẽ được hệ thống công văn thẻ xử lý như sau: 12 - - Sử dụng bộ lọc intents như bình thường. Nếu Activity thỏa mãn thêm điều kiện AAR thì khởi động Activity. Nếu các Actvity kết quả của bộ lọc Intent không thõa mãn AAR. Nếu nhiều Activity có thể xử lý intent đó, hoặc không Activity nào có thể xử lý. Kích hoạt ứng dụng thỏa mãn AAR. Nếu không ứng dụng nào có thể bắt đầu với AAR, vào GooglePlay và download ứng dụng. 2.2.2.1.7. Truyền NdefMessage tới thiết bị Android hỗ trợ NFC khác AnroidBeam cho phép hai thiết bị Android hỗ trợ NFC có thể trao đổi dữ liệu. Ứng dụng dùng để truyền dữ liệu cần nằm ở tiền cảnh và thiết bị nhận đang ở trạng thái không khóa. Khi thiết bị truyền nằm trong phạm vi vừa đủ với thiết bị nhận, người sử dụng có thể chọn hoặc không chọn truyền dữ liệu cho thiết bị nhận. Một Activity chỉ có thể đẩy một NdefMessage tại một thời điểm. Thiết bị NFC nhận dữ liệu phải được hỗ trợ gói com.android.npp - giao thức đẩy dữ liệu NDEF hoặc giao thức SNEP (Simple NDEF Exchange Protocol) của diễn đàn NFC. Giao thức com.android.npp là cần có của phiên bản Android API level 9 (Android 2.3) tới level 13 (Android 3.2) [22]. Từ Android 4.0 trở lên đều cần cả com.android.npp lẫn SNEP[22]. 2.2.2.2. Các vấn đề nâng cao của NFC trong Android Phần này nói qua về các API cho phép sử dụng các công nghệ thẻ khác nhau mà Android hỗ trợ. Android đọc, ghi dữ liệu dưới các chuỗi byte và sử dụng giao thức do người lập trình thiết lập (có thể không phải kiểu dữ liệu NDEF hoặc là NDEF) để phát hiện và xác định và kết nối với thẻ. Khi làm việc với thẻ NFC và các thiết bị hỗ trợ Android, định dạng chính thường đước sử dụng là NDEF. Với kiểu dữ liệu NDEF, Android hỗ trợ phân tích cú pháp của thông điệp và đặt nó trong một NdefMessage nếu có thể. Tuy nhiên, có những trường hợp thẻ không chứa dữ liệu NDEF hoặc không thể ánh xạ MIME/URI, trong trường hợp này lập trình viên cần kết nối với thẻ, đọc và viết theo giao thức riêng. Android cung cấp gói android.nfc.tech để sử dụng trong các trường hợp nói trên. 2.2.2.3. Mô phỏng thẻ NFC Nhiều thiết bị Android cung cấp chức năng giả lập thẻ NFC. Chức năng này thường được thực hiện bởi một chip riêng biệt trong thiết bị, là một thành phần bảo 13 mật. Một số SIM được cung cấp bởi một số nhà mạng không dây cũng có thành phần này. Android 4.4 có một số phương pháp bổ sung giả lập thẻ mà không cần thông qua các thành phần bảo mật là : “host-based card emulation” (HCE)[23]. Điều này cho phép bất cứ ứng dụng Android có thể giả lập thẻ NFC và giao tiếp với các thiết bị đọc thẻ NFC. 2.2.2.3.1. Giả lập với thành phần bảo mật Khi giả lập thẻ NFC được thực hiện thông qua thành phần bảo mật, thẻ được mô phỏng nằm trong thành phần bảo mật và các thông tin được truy xuất thông qua ứng dụng Android. Khi đọc thẻ NFC, bộ điều khiển NFC chuyển hướng đích đọc của thiết bị đọc sang thành phần bảo mật. Hình 2.3. Giả lập thẻ NFC thông qua thành phần bảo mật [23] Các thành phần bảo mật tự thực hiện các công việc giao tiếp với các thiết bị đọc thẻ NFC mà không cần sự hỗ trợ nào của tầng ứng dụng. Sau khi giao dịch hoàn tất, ứng dụng có thể truy vấn đến các yếu tố bảo mật để lấy các thông tin cần thiết từ giao dịch. 2.2.2.3.2. Host-Based Card Emulation Khi mô phỏng thẻ bằng HCE, dữ liệu được chuyển tới CPU mà trên đó ứng dụng Android đang chạy trực tiếp. 14 Hình 2.4. Giả lập NFC thông qua HBC [23] 2.2.2.3.3. Các loại thẻ giao thức NFC được hỗ trợ để tạo giả lập Android 4.4 hỗ trợ nhiều giao thức, loại thẻ phổ biến. Cụ thể hơn là các loại thẻ dựa trên các chuẩn của diễn đàn NFC : ISO-DEP (dựa trên ISO/IEC 14443-4) [23] và tiến trình Application Protocol Data Units (APDUs) được nêu trong các chuẩn kĩ thuật ISO/IEC 7816-4 [23]. Android chỉ được giới hạn giả lập công nghệ tiêu chuẩn ISODEP NFC-A (ISO / IEC 14.443-3 Loại A) [23]. Còn công nghệ NFC-B (ISO / IEC 14.443-4 Loại B) [23] là tùy chọn. 2.2.2.3.4. Dịch vụ HCE Kiến trúc HCE dựa trên thành phần dịch vụ Android (Android service). Lợi thế của thành phần dịch vụ Android là có thể chạy nền để có thể phản hồi thiết bị đọc NFC trong nền mà không cần khởi động giao diện. 2.2.2.3.5. HCE và bảo mật Kiến trúc HCE bản thân nó cung cấp một phần cốt lõi của an ninh: vì dịch vụ này được bảo vệ bới system permission BIND_NFC_SERVICE, chỉ có hệ điều hành có thể giao tiếp và liên kết với dịch vụ HCE. 2.3. Google Maps Android API Google Maps Android API hỗ trợ việc thêm bản đồ dựa trên dữ liệu bản đồ của Google Maps. API này tự động xử lý các việc truy cập vào máy chủ Google Maps nhằm tải tài liệu, hiển thị bản đồ, và phản hồi biển hiện bản đồ. API này cũng được dùng cho việc đánh dấu bản đồ, vẽ đa giác, tạo một lớp phủ lên bản đồ cơ bản, thay 15 đổi góc nhìn của người sử dụng trên một khu vực bản đồ. Các đối tượng cung cấp thông tin bổ sung thêm cho các địa điểm, cho phép người dùng tương tác với bản đồ. API cho phép thêm đồ họa trên bản đồ. 2.3.1. Các đối tượng Map Google Maps API cho phép hiển thị Google Map trên ứng dụng. Loại bản đồ này giống với bản đồ của ứng dụng Google Maps for Mobile (GMM)[25], bản đồ do Google Maps API tạo ra và bản đồ của ứng dụng GMM có nhiều tính năng tương tự. Nhưng có hai sự khác biệt cơ bản, bản đồ tạo ra bởi API thì: - Không chứa bất kỳ nội dung cá nhân nào. Còn GMM thì có chứa thông tin cá nhân. Các biểu tưởng trên bản đồ không phải cái nào cũng có thể nhấp chuột. Tuy nhiên, các địa điểm được thêm vào có thể được nhấp, API hỗ trợ việc đánh dấu nghe gọi cho các tương tác khác nhau. Ngoài chức năng tạo lập bản đồ, API cũng hỗ trợ các chức năng phù hợp với giao diện người dùng Android. Ví dụ, thiết lập các tương tác với bản đồ bằng cách thiết lập lắng nghe sự kiện phản hồi lại tương tác của người sử dụng. Lớp quan trọng khi làm việc với đối tượng bản đồ là lớp GoogleMap. Trong giao diện người dùng Android, một bản đồ sẽ được biểu diễn bằng một MapFragment hoặc đối tượng MapView. GoogleMap xử lý hoạt động tự động sau: - Kết nối với dịch vụ Google Map (GoogleMap service). Tải các dữ liệu Map. Hiển thị dữ liệu Map. Hiển thị các khía cạnh điều khiển như pan và zoom. Phản hồi tương tác cho pan và zoom như di chuyển bản đồ và zoom in và zoom out. 2.3.1.1. MapFragment MapFragment là lớp con Fragment trong Android, cho phép đặt bản đồ Google trong một Fragment của Android. Các đối tượng MapFragment cung cấp các phương thức truy cập vào GoogleMap. Không giống như một View, một Fragment là một hành vi hay một phần của giao diện người dùng trong một Activity. Nhiều Fragment có thể kết hợp trong một Activity để tạo một giao diện đa cửa sổ[26]. 16 2.3.1.2. MapView MapView là lớp con của View trong Android, cho phép đặt bản đồ Google trong một View của Android. View là một đại diện cho vùng chữ nhật trên màn hình là một khối cơ bản để xây dựng giao diện Android và Widgets. Các đối tượng Mapview cung cấp các phương thức truy cập vào GoogleMap. 2.3.1.3. Các loại bản đồ Google Maps Android API cung cấp bốn loại bản đồ: - Normal: Bản đồ đường điển hình. Bao gồm: đường giao thông, các công trình, các đối tượng tự nhiên quan trọng như: sông, hồ, … Đường bộ và tính năng nhãn cũng được hiển thị. Hypird: Sự kết hợp giữa ảnh từ vệ tinh và các bản đồ đường. Đường bộ và tính năng nhãn cũng được hiển thị. Satellite: Dữ liệu ảnh vệ tinh. Đường bộ và tính năng nhãn cũng được hiển thị. Terrian: Dữ liệu địa hình. Bản đồ này bao gồm màu sắc, các đường cong và nhãn... Đường bộ và tính năng nhãn cũng được hiển thị. None: Bản đồ không được hiển thị. Đối tượng được hiển thị dưới dạng lưới trống. - 2.3.1.4. Indoors Maps Ở các mức độ zoom khác nhau, bản đồ có thể hiển thị mặt phẳng đáy cho các không gian kiến trúc như: sân bay, trung tâm mua sắm, cửa hàng lớn, trạm trung chuyển,… Loại hiển thị này được áp dụng cho bản đồ loại Normal, sẽ được tự động kích hoạt khi người dùng thay đổi mức độ zoom. Mặt phẳng đáy được hiển thị trên bản đồ tại một thời điểm. Mặc định sẽ là bản đồ đầu tiên được bổ sung vào ứng dụng. 2.3.2. Vẽ trên bản đồ Google Maps Android API cung cấp chức năng thêm vào bản đồ các đối tượng sau: - Điểm đánh dấu (Marker): để xác định một vị trí trên bản đồ. API này cũng cung cấp cho phép lắng nghe sự kiện tương tác của người dùng với Marker. 17 - Cửa sổ thông tin (Info Window): là cửa sổ thông tin hiện ra khi người dùng - tác động vào Markers. Chỉ một Infor Wondow được phép hiển thị trong một thời điểm. Các hình đơn giản (Shape): Google Maps API for Android cũng cung cấp - một số cách đơn giản, để thêm các Shape vào bản đồ bao gồm: tập các đoạn thẳng giữa hai đường thẳng có ít nhất một đỉnh (Polyline) thường dùng để đánh dấu đường và các tuyến đường, đa giác (Polygon) thường dùng để đánh dấu các khu vực trên bản đồ, hình tròn (Circle) là hình chiếu của hình tròn trên trái đất được vẽ trên bản đồ. Lớp phủ mặt bằng (Ground Overlays): là một hình ảnh được gắn với bản đồ. - Không giống Marker, Ground Overlays được định hướng với trái đất chứ không phải màn hình. Lớp phủ ô (Title Overlays): là một tập các hình ảnh được thêm vào trên đỉnh của các ô trên bản đồ cơ sở. 2.3.3. Tương tác với bản đồ Google Maps Android API cung cấp cách thức người dùng có thể tương tác với bản đồ. - Giao diện điều khiển: API hỗ trợ việc xây dựng giao diện trên các thành phần - có thể thấy ở ứng dụng Google Maps bao gồm: điều khiển zoom, la bàn, vị trí hiện tại. Phản hồi tương tác của bản đồ: API hỗ trợ việc bật, tắt các phản hồi mặc định - của bản đồ khi người dùng tương tác như: phản hồi bằng cách zoom (với các tương tác như: nhấp đúp, kéo bằng hai tương tác đồng thời,… ), phản hồi bằng cách di chuyển điểm nhìn, . Các sự kiện: API cho phép lắng nghe các sự kiện từ bản đồ. 2.3.4. Dữ liệu về tọa độ Các dữ liệu có sẵn của một thiết bị Android bao gồm vị trí hiện tại của thiết bị, Google API cho phép đồng bộ vị trí đó lên bản đồ. Google Play services Location API cho phép: xác định vị trí thiết bị, lắng nghe sự thay đổi của vị trí, xác định phương thức vẩn chuyển, tạo và giám sát các khu vực địa lý trước. 2.3.5. Thay đổi góc nhìn Google Maps Android API v2 có thể nghiêng, xoay góc và di chuyển điểm nhìn bản đồ, tạo cho người dùng khả năng định hướng một cách dễ dàng dù là ở mức độ zoom nào. 18 2.4. Hệ quản trị cơ sở dữ liệu MySQL MySQL là hệ quản trị cơ sở dữ liệu quan hệ mã nguồn mở được sử dụng nhiều thứ hai trên thế giới được phát triển bởi MySQL AB. MySQL là miễn phí nằm ở vị trí trung tâm trong nhóm LAMP cho ứng dụng web mã nguồn mở (Linux-ApacheMySQl-Pearl/PHP/Python). Vì MySQL ổn định và dễ sử dụng, có tính khả chuyển, hoạt động trên nhiều hệ điều hành cung cấp một hệ thống lớn các hàm tiện ích mãnh mẽ, MySQL có cùng một cách truy xuất và mã lệnh tương tự với ngôn ngữ SQL vì thế mà MySQL được sử dụng và hỗ trợ của những lập trình viên yêu thích mã nguồn mở. MySQL là một hệ cơ sở dữ liệu quan hệ, dữ liệu được lưu trữ trong nó theo các bảng riêng biệt và giữa các bảng được liên kết với nhau theo các mối quan hệ xác định chứ không đưa dữ liệu vào một khối chung. Cách lưu trữ như vậy làm tăng thêm tốc độ và tính linh hoạt. Giao dịch trong MySQL được thực hiện tuân theo mô hình ACID, cho phép đánh chỉ mục, hỗ trợ các kiểu dữ liệu chuẩn, cho phép thực hiện replication database,… Với các đặc tính như vậy, hệ quản trị cơ sở dữ liệu quan hệ MySQL thích hợp trong các mô hình và giải pháp thương mại điện tử. MySQL được viết bằng ngôn ngữ C/C++ và được sử dụng trên nhiều hệ điều hành khác nhau như: AIX, BSDi, FreeBSD, HP-UX, eComStation, i5/OS, IRIX, Linux, OS X, Microsoft Windows, NetBSD, Novell NetWare, OpenBSD, OpenSolaris, OS/2 Warp, QNX, Oracle Solaris, Symbian, … Hầu hết các ngôn ngữ lập trình đều hỗ trợ các API để thao tác với MySQL như: Connector/Net của Microsoft's Visual Studio , JDBC cho java, … MySQL bao gồm các lớp bảo mật dữ liệu vững chắc để bảo vệ dữ liệu nhạy cảm từ những kể xâm nhập. Thêm vào đó, tính mở rộng là rất quan trọng với hệ quản trị cơ sở dữ liệu, MySQL có thể xử lý dữ liệu có thể lên đến 50 triệu bản ghi hoặc hơn. Giới hạn kích thước tập tin (file) mặc định là 4GB tuy nhiên, chúng ta có thể tăng co số này lên đến 8TB.[26] Và cuối cùng, MySQL có khả năng quản lý bộ nhớ tốt, máy chủ của MySQL thường xuyên được kiểm tra kĩ lưỡng để tránh việc rò rỉ bộ nhớ. 2.5. Cơ sở dữ liệu nhúng SQLite Được giới thiệu để giúp các ứng dụng quản lý dữ liệu của mình thuận tiện hơn, SQLite là một bộ thư viện dùng trong lập trình để hiện thực một SQL Database Engine có khả năng tự tổ chức quản lý dữ liệu, không cần server mà thực hiện đọc ghi vào file trực tiếp, không cần cấu hình mà vẫn hỗ trợ đầy đủ các tính năng quản lý giao tác. SQLite là SQL Database Engine nhúg mã nguồn mở theo mô hình dữ liệu quan hệ 19 đang được sử dụng nhiều nhất trên thế giới do tính cơ động cao, dễ sử dụng, gọn nhẹ, hiệu quả và tin cậy. SQLite là một thư viện nhỏ gọn kích thước tối đa là 500 KB, tùy thuộc vào nền tảng hướng đến mà thiết lập để tối ưu hóa trình biên dịch. Nếu các tính năng tùy chọn được bỏ qua, kích thước tối đa của SQLite là 300 KB, hơn nữa nó được thiết kế để chạy chiếm một khoảng nhỏ trong không gian stack và rất nhỏ trong heap. Chính vì vậy, SQLite là công củ cơ sợ dữ liệu phổ biến trên các bộ nhớ hạn chế các tiện ích như: điện thoại di động, máy nghe nhạc MP3, … Lưu ý, bộ nhớ cấp phát càng nhiều thì Sqlite có tốc độ càng lớn, nhưng không có nghĩa là tốc độ của nó không chấp nhận được trong môi trường bộ nhớ hạn chế.[28] SQLite có thể làm việc với cơ sở dữ liệu lên đến hằng TetraByte, và hầu hết các thao tác trên dữ liệu thông thường đều chạy nhanh hơn các hệ cơ sỡ dữ liệu theo mô hình client-server phổ biến khác. Và hơn nữa nó có khả năng tổ chức lưu trữ mà không phải phụ thuộc vào các thư viện bên ngoài. Đây là một đặc điểm khá quan trọng khiến SQLite trở thành CSDL phù hợp để nhúng vào các thiết bị di động hoặc tích hợp vào các ứng dụng muốn chạy mà không cần phải điều chỉnh cấu hình hệ thống. Ngoài ứng dụng như một định dạng tập tin vào các ứng dụng và làm cơ sở dữ liệu cho các thiết bị điện tử. SQLite còn có thể sử dụng làm cơ sở dữ liệu cho các website vì SQLite không cần phải cấu hình và dữ liệu được lưu trữ thành các tập tin trên đĩa thật sự nên nó đang trở thành lựa chọn phổ biến cho các website vừa và nhỏ. Mỗi phiên bản SQLite được kiểm tra cẩn thận trước khi công bố cho nên Sqlite rất đáng tin cậy. Giao dịch trong SQLite được thực hiện tuân theo mô hình ACID và nó vẫn tuân thủ ACID trong trường hợp có sự cố hệ thống hay mất điện. Đương nhiên, điều đó không có nghĩa là SQLite không tồn tại lỗi. Hiển nhiên, các đặc điểm tạo nên các ưu điểm của SQLite là con dao hai lưỡi làm cho SQLite có các hạn chế sau: - - Kết nối mạng: SQLite không có máy chủ, biện pháp là chia sẻ thông qua network file systems. Hệ thống này có độ trễ nhất định điều này làm ảnh hưởng đến hiệu xuất của SQLite. Mặt khác, khi sử dụng điều này lỗ hổng an ninh là có thể xảy ra vì: các tập tin truyền đi có thể bị mở và điều chỉnh từ xa. Chỉ phù hợp với các ứng dụng quy mô nhỏ: SQLite không phải là lựa chọn thích hợp cho các loại dữ liệu lớn và được cập nhập một cách liên tục. Tính đồng thời: SQLite cho phép đọc đồng thời nhưng chỉ một người có thể được ghi trong một thời điểm. 20 21 CHƯƠNG 3: XÂY DỰNG HỆ THỐNG 3.1. Mô hình hệ thống Hệ thống quản lý người dùng dịch vụ xe buýt bao gồm: - User Management Database: cơ sở dữ liệu lưu trữ thông tin về tài khoản - người dùng dịch vụ xe buýt, nhân viên xe buýt, và lịch sử giao dịch, ... Location Database: cơ sở dữ liệu này lưu trữ về vị trí tọa độ của các trạm - dừng xe buýt, vị trí hiện thời của xe buýt đang hoạt động. User Management Server: máy chủ nhận các truy vấn từ User Management - Webservice và User Management Website nhằm tương tác với User Management Database. Location Server: máy chủ nhận các truy vấn từ ứng dụng quản lý người dùng - dịch vụ xe buýt (Staff Android Application) và hỗ trợ người dùng (Customer Android Application) nhằm lưu trữ hoặc lấy thông tin về các tọa độ từ Location Database. User Management Webservices: là dịch vụ web cung cấp các thông tin cần - thiết cũng như xử lý, lưu trữ các cuộc giao dịch từ khách hàng trên các chuyến xe. Sau khi truy vấn, kết quả trả về tuân theo cấu trúc JSON. User Management Website: giao diện nền web cung cấp thông tin cho khách - hàng và nhân viên. Staff Android Application: là ứng dụng Android được cài đặt trên các thiết bị - Android cố định trên xe buýt. Có chức năng chính là cung cấp cho nhân viên cách xác thực người dùng thông qua thẻ NFC. Customer Android Application: là ứng dụng Android được cài đặt trên thiết bị của khách hàng. Có chức năng chính là cung cấp thông tin tài khoản, lịch sử giao dịch cho khách hàng và cung cấp một bản đồ các tuyến đường xe buýt và vị trí hiện tại của các xe buýt cho khách hàng. Ngoài ra còn thành phần ngoài hệ thống Google Services cụ thể là Google Maps (là một trong những dịch vụ thuộc Goolge Services) đóng vai trò tất yếu trong việc hiển 22 thị bản đồ ở thành phần Customer Android Application bằng cách trả về các kết quả đồng bộ với Google API và các thông tin về bản đồ khác trên cấu trúc JSON. Hình 3.1. Mô hình hệ thống Mô hình thực thể được biểu thị như Hình 3.2: 23 Hình 3.2. Mô hình thực thể 3.2. Phân tích và xác định yêu cầu 3.2.1. Ứng dụng quản lý người dùng dịch vụ xe buýt 3.2.1.1. Tổng quan về ứng dụng Ứng dụng được biểu thị là thành phần Staff Android Application trên mô hình hệ thống (Hình 3.1). Là ứng dụng được cài đặt trên thiết bị Android cố định được cung cấp cho mỗi xe buýt. Ứng dụng này cung cấp cho nhân viên xe buýt cách xác thực người dùng dịch vụ xe buýt một cách tự động thông qua việc quét thẻ NFC mà khách hàng được cấp khi đăng ký làm thẻ xe buýt, cũng như đẩy dữ liệu về vị trí hiện tại của xe buýt lên máy chủ và cung cấp thông tin cá nhân chính nhân viên xe buýt đang trực và người dùng vừa thực hiện giao dịch thông qua thẻ NFC thông qua các dịch vụ web . 24 Hình 3.3. Mô hình Use Case: Ứng dụng quản lý người dùng dịch vụ xe buýt Về cơ bản có hai tác nhân chính tác động lên ứng dụng: - Nhân viên: nhân viên là người khởi động ứng dụng thông qua đăng nhập - bằng một trong hai cách: sử dụng thẻ NFC hoặc cung cấp tài khoản và mật khẩu. Nhân viên có thể kiểm tra thông tin cá nhân sơ lược được lưu trên hệ thống thông qua ứng dụng cũng như lịch sử xác nhận giao dịch khách hàng của mình. Sau khi ứng dụng khởi động, nhân viên điều phối, kiểm tra khách hàng thực hiện việc quét thẻ qua thiết bị nhằm xác thực giao dịch. Cũng như phát hiện các xác thực không hợp lệ hoặc gian lận mà tùy vào đó thực hiện báo cáo vi phạm, tạm thời đình chỉ khả năng hoạt động của thẻ thông qua ứng dụng. Khách hàng: là tác nhân cần được xác thực thông qua việc quét thẻ qua thiết bị. Khi khách hàng thực hiện công việc quét thẻ, ứng dụng sẽ thực hiện việc xác nhận bằng cách gửi ID thẻ NFC tới các dịch vụ web mà tại đó thực hiện công việc xác nhận khách hàng và thực hiện giao dịch nếu trạng thái thẻ còn hợp lệ để thực hiện thao tác giao dịch. Ứng dụng sẽ nhận kết quả trả về của các webservice đó và thông báo cho nhân viên và khách hàng thông tin của khách hàng (bao gồm ảnh) nếu thẻ có thể xác thực và thông báo giao dịch có được thực hiện thành công hay không. 25 3.2.1.2. Đặc tả Use Case 3.2.1.2.1. Đăng nhập - Mô tả: là chức năng cho phép người dùng ứng dụng đăng nhập vào hệ thống bằng - thẻ NFC hoặc tài khoản và mật khẩu. Tác nhân: người sử dụng. Điều kiện trước: Người sử dụng mới khởi động ứng dụng hoặc mới thực hiện đăng - xuất và chưa đăng nhập lại. Điều kiện sau: Nếu đăng nhập thành công hiển thị giao diện cung cấp thông tin cá - - nhân cho người dùng. Thông tin tài khoản gửi về được lưu trong cơ sở dữ liệu cục bộ. Nếu không, thông báo người sử dụng lý do. Kịch bản ca sử dụng: 1. Ứng dụng hiển thị màn hình đăng nhập, kiểm tra xem thiết bị đã bật chế độ đọc thẻ NFC hay chưa. Nếu chưa, hiển thị cảnh báo yêu cầu thiết bị bật chế độ đọc ghi thẻ NFC với hai tùy chọn: 1.1. Yes: chuyển hướng tới tùy chọn của thiết bị để khởi động chế độ đọc thẻ NFC. 1.2. No: Tiếp tục sử dụng ứng dụng mà không bật chế độ dọc thẻ NFC. 2. Người dùng thông qua thẻ NFC hoặc tài khoản, mật khẩu và chọn nút “Đăng nhập”. 3. Ứng dụng tiền kiểm tra thông tin sau đó gửi và nhận kết quả dịch vụ web để xác nhận. 3.1. Nếu thông tin không hợp lệ thì use case “thông tin đầu vào sai lệnh” được thực hiện. 3.2. Nếu tình trạng kết nối với server là không thể thiết lập thì use case “xử lý không thể kết nối với server” được kích hoạt. 3.3. Nếu phản hồi của dịch vụ web là thành công, thông tin người sử dụng được trả về từ dịch vụ web được lưu trong cơ sở dữ liệu của ứng dụng, ứng dụng chuyển qua giao diện use case “Kiểm tra thông tin cá nhân”. 4. Ứng dụng phản hồi kết quả lên giao diện. Yêu cầu phi chức năng: Hệ thống đáp ứng đăng nhập không quá 7 giây. Ca sử dụng con: o Khi hệ thống không thể kết nối tới server, hệ thống thông báo không thể kết nối cho người dử dụng. o Khi thông tin đầu vào là sai lệch, hệ thống thông báo thông tin không chính xác cho người sử dụng. 26 Hình 3.4. Use case: "Đăng nhập" 3.2.1.2.2. Đăng xuất - Mô tả: là chức năng giúp người dùng thông báo kết thúc phiên làm việc với hệ - thống. Tác nhân: người sử dụng. Điều kiện trước: ứng dụng đang chạy và trước đó người sử dụng đã đăng nhập rồi - và chưa đăng xuất. Điều kiện sau: Đăng xuất thành công hay thất bại đều kích hoạt chức năng đăng - - nhập, thông tin người dùng được lưu trong cơ sở dữ liệu cục bộ đều bị xóa. Kịch bản ca sử dụng: 1. Người sử dụng chọn chức năng đăng xuất từ giao diện ứng dụng. 2. Ứng dụng lấy thông tin người sử dụng từ cơ sở dữ liệu của ứng dụng, thực hiện gửi thông tin người sử dụng lên dịch vụ web thông báo người sử dụng kết thúc pha làm việc. 2.1. Nếu tình trạng kết nối với server là không thể thiết lập thì use case “xử lý không thể kết nối với server” được kích hoạt. 2.2. Nếu tình trạng không tìm thấy thông tin tài khoản từ cơ sở dữ liệu thì use case “không tìm thấy thông tin tài khoản” được thực thi. 3. Ứng dụng thông báo kết quả phản hồi cho người sử dụng và trở lại màn hình đăng nhập. Yêu cầu phi chức năng: phản hồi không quá 5 giây. Ca sử dụng con: o “xử lý không thể kết nối với server” : xóa thông tin người dùng trong cơ sở dữ liệu ứng dụng, thông báo cho người sử dụng lỗi kết nối với server. o “không tìm thấy tài khoản” : thông báo cho người sử dụng việc không tìm thấy thông tin cá nhân trong cơ sở dữ liệu. 27 Hình 3.5. Use case: "Đăng xuất" 3.2.1.2.3. Kiểm tra thông tin cá nhân` - - Mô tả: chức năng này để hiển thị thông tin sơ bộ (bao gồm ảnh) cho người sử dụng ứng dụng. Tác nhân: người sử dụng. Điều kiện trước: ứng dụng đang chạy và trong trạng thái đăng nhập thành công. Điều kiện sau: hiển thị thông tin người dùng. Kịch bản ca sử dụng: 1. Người sử dụng vừa mới đăng nhập thành công hoặc chọn chức năng hiển thị thông tin của mình. 2. Ứng dụng truy xuất đến cơ sở dữ liệu của ứng dụng lấy định danh (ID) của người sử dụng (là một trong những thông tin trả về sau đăng nhập). Gửi thông tin đó đến dịch vụ web nhằm lấy thông tin của người sử dụng: 2.1. Nếu không thể kết nối với server, uses case “xử lý không thể kết nối server” được kích hoạt. 2.2. Nếu thông tin gửi lên chính xác, dịch vụ web trả về thông tin cá nhân và ứng dụng hiển thị thông tin đó lên giao diện. Yêu cầu: thông tin phản hồi không quá 5 giây. Ca sử dụng con: o Khi hệ thống không thể kết nối tới server, hệ thống thông báo không thể kết nối cho người dử dụng. Hình 3.6. Use case: "Kiểm tra thông tin cá nhân" 28 3.2.1.2.4. Kiểm tra lịch sử giao dịch - Mô tả: Chức năng này thể hiện thông tin về giao dịch mà nhân viên đã thực hiện - kiểm tra giao dịch. Tác nhân: Người sử dùng (quyền nhân viên). Điều kiện trước: ứng dụng đang chạy và trong trạng thái đăng nhập thành công. Điều kiện sau: hiển thị danh sách lịch sử giao dịch được đánh theo danh mục: trong - - ngày: giao dịch được ghi nhận trong ngày, trong tuần: giao dịch được ghi nhận trong tuần của những ngày trước đó, trong tháng: giao dịch được ghi nhận trong tháng của các tuần trước đó. Kịch bản ca sử dụng: 1. Người sử dụng chọn chức năng hiển thị thông tin giao dịch của mình. 2. Ứng dụng truy xuất đến cơ sở dữ liệu của ứng dụng lấy định danh (ID) của người sử dụng (là một trong những thông tin trả về sau đăng nhập). Gửi thông tin đó đến dịch vụ web nhằm lấy thông tin của người sử dụng: 2.1. Nếu không thể kết nối với server, uses case “xử lý không thể kết nối server” được kích hoạt. 2.2. Nếu thông tin gửi lên chính xác, dịch vụ web trả về lịch sử giao dịch trog vòng một tháng, ứng dụng phân danh mục rồi hiển thị thông tin đó lên giao diện. Yêu cầu: thông tin phản hồi không quá 20 giây. Ca sử dụng con: o Khi hệ thống không thể kết nối tới server, hệ thống thông báo không thể kết nối cho người dử dụng. Hình 3.7. Use case: "Kiểm tra lịch sử giao dịch" 3.2.1.2.5. Xác thực người dùng - Mô tả: là chức năng quan trọng, chức năng chính của ứng dụng. Dùng để xác thực và thanh toán không tiếp xúc với người dùng dịch vụ xe buýt. 29 - Tác nhân: người dùng dịch vụ xe buýt. Điều kiện trước: Ứng dụng đang chạy trong trạng thái đã đăng nhập tài khoản - quyền nhân viên và thiết bị bật trạng thái đọc NFC. Điều kiện sau: Thông báo thông tin người dùng và trạng thái giao dịch( bằng âm - - thanh và thông điệp hiển thị). Kích hoạt gửi giao dịch nếu trạng thái giao dịch hợp lệ. Kịch bản ca sử dụng: 1. Nhân viên chọn chức năng xác thực người dùng. 2. Người dùng quẹt thẻ NFC qua thiết bị. 3. Ứng dụng kiểm tra thẻ có đúng chuẩn để đọc hay không: 3.1. Nếu không, kích hoạt use case “thẻ không thỏa mãn điều kiện giao dịch”. 3.2. Nếu có, lấy định danh từ thẻ (ID) gửi nó lên dịch vụ web, dịch vụ web thông qua ID sẽ xác thực người dùng: 3.2.1. Nếu xác thực được người dùng thành công, kiểm tra trạng thái giao dịch của thẻ và loại hình giao dịch của thẻ. Thực hiện giao dịch. Và đồng thời trả về thông tin của người sử dụng. 3.2.2. Nếu không thành công thông báo tới ứng dụng việc giao dịch không thành công. 4. Thông qua kết quả trả về của giao dịch từ dịch vụ web, ứng dụng thông báo việc xác nhận không thành công hoặc có thành công bằng âm thanh và thông báo khác nhau. Nếu có thể xác thực và người dùng, trạng thái thẻ có thể giao dịch thì thông báo giao dịch thành công và hiển thị thông tin người sử dụng. Yêu cầu phi chức năng: thông tin trả về không quá 5 giây và việc hiển thị ảnh của người dùng không quá 7 giây. Ca sử dụng con: o “Thẻ không thỏa mãn điều kiện giao dịch”:  Nếu không thể xác thực người dùng qua thẻ, không trả về thông tin gì và thông báo không thể giao dịch.  Nếu có thể xác thực người dùng qua thẻ, nhưng trạng thái thẻ không thể giao dịch thì hiển thị thông tin người dùng và thông báo không thể giao dịch. o Khi hệ thống không thể kết nối tới server, hệ thống thông báo không thể kết nối cho người dử dụng. 30 Hình 3.8. Use case: "Xác thực người dùng dịch vụ xe buýt" 3.2.1.2.6. Báo cáo vi phạm - Mô tả: là chức năng báo cáo hành vi gian lận, vi phạm trật tự của người sử dụng - dịch vụ xe buýt như: sử dụng thẻ của người khác,… Tác nhân: người sử dụng (quyền nhân viên). Điều kiện trước: người sử dụng xác nhận thông tin, thực hiện giao dịch bằng việc - - quẹt thẻ. Điều kiện sau: hiển thị thông điệp thành công hay thất bại. Kịch bản ca sử dụng: 1. Sau khi người sử dụng được xác nhận, nhân viên phát hiện hành vi gian lận. Và chọn chức năng báo cáo gian lận với người sử dụng này. 2. Ứng dụng lấy định danh người sử dụng gửi thông tin tới dịch vụ web báo cáo vi phạm: 2.1. Nếu không thể kết nối đến server kích hoạt use case “Xử lý khi không thể kết nối server”. 3. Hiển thị thành công hay thất bại của báo cáo vi phạm với người sử dụng. Yêu cầu phi chức năng: phản hồi trong vòng 3 giây. Ca sử dụng con: o Khi hệ thống không thể kết nối tới server, hệ thống thông báo không thể kết nối cho người dử dụng. 31 Hình 3.9. Uses case: "Báo cáo vi phạm" 3.2.1.3. Mô hình lớp phân tích: Mô hình lớp phân tích được thể hiện ở Hình 3.10. Và được mô tả sơ bộ ở Bảng 3.1. Hình 3.10. Mô hình lớp phân tích: Ứng dụng quản lý người DVXB Uses case Tên lớp phân tích Đăng nhập LoginForm Đăng xuất Mô tả sơ bộ Lớp giao diện cho phép người dùng đăng nhập LoginController Lớp điều khiển việc xác thực đăng nhập từ dịch vụ web LogoutForm Lớp giao diện cho phép người dùng đăng xuất 32 LogoutController Lớp điều khiển việc xác thực đăng xuất từ dịch vụ web Kiểm tra InformationForm thông tin cá nhân InformationForm Lớp giao diện cho phép người dùng xem thông tin Lớp điều khiển việc triết xuất thông tin từ dịch vụ web Xác thực AuthenticationForm Lớp giao diện cho phép nhân viên xác thực người người dùng xe buýt dùng AuthenticationController Lớp điều khiển việc triết xuất thông tin, thực hiện giao dịch từ dịch vụ web Thông báo ReportController vi phạm Lớp điều khiển việc thông báo vi phạm tới dịch vụ web Gửi tọa độ LocationService hiện tại Lớp điều khiển gửi tọa độ lên server location Kiểm tra HistoryPaymentsForm lịch sử giao dịch HistoryPaymentsControl ler Lớp giao diện cho phép nhân viên hiển thị thông tin giao dịch mình đã duyệt Lớp điều khiển việc triết giao dịch từ dịch vụ web UserBean Lớp thực thể chứa thông tin tài khoản (User) UserInformation Lớp thực thể chứa thông tin chi tiết về người dùng Payment Lớp thực thể chứa thông tin về giao dịch Location Lớp thực thể chứa thông tin về tọa độ Bảng 3.1. Các lớp phân tích: Ứng dụng quản lý người dùng DVXB 3.2.2. Ứng dụng hỗ trợ người dùng dịch vụ xe buýt 3.2.2.1. Tổng quan về ứng dụng Ứng dụng được biểu thị là thành phần Customer Android Application trên mô hình hệ thống (Hình 3.1). Ứng dụng này được cài đặt bởi bất cứ thiết bị Android nào. Nó cung cấp chức năng cho người sử dụng có thể kiểm tra thông tin tài khoản, thông 33 tin thẻ mà khác hàng xe buýt được cấp khi đăng ký sử dụng thẻ để thanh toán. Ngoài ra, ứng dụng còn hỗ trợ khách hàng bản đồ các trạm dừng của các tuyến xe buýt, cũng như hiển thị lên bản đồ vị trí xe buýt đang vận hành theo thời gian để tiện lợi cho việc sử dụng dịch vụ xe buýt công cộng. Tác nhân có thể tương tác với ứng dụng là người dùng. Người dùng có thể thực hiện kích hoạt ứng dụng thông qua đăng nhập bằng thẻ NFC được cấp khi đăng ký sử dụng thẻ để thanh toán hoặc tài khoản và mật khẩu. Sau khi đăng nhập thành công, người dùng có thể kiểm tra thông tin cá nhân, trạng thái giao dịch của thẻ cũng như việc tìm kiếm các trạm dừng của các tuyến xe buýt hay quan sát trạng thái di chuyển của xe buýt. Hình 3.11. Mô hình Use Case Ứng dụng hỗ trợ người dùng dịch vụ xe buýt 3.2.2.2. Đặc tả Use Case Ở ứng dụng hỗ trợ người dùng dịch vụ xe buýt, có một vài chức năng giống với chức năng của ứng dụng quản lý người dùng dịch vụ xe buýt như: đăng nhập, đăng xuất, kiểm tra thông tin người dùng nên tôi sẽ không nhắc lại để tránh việc trùng lặp. 3.2.2.2.1. Kiểm tra lịch sử giao dịch - Mô tả: Chức năng này thể hiện thông tin về giao dịch mà người dùng đã thực hiện - giao dịch cho dịch vụ xe buýt trong vòng một tháng trở lại. Tác nhân: Người sử dùng (quyền người dùng). 34 - - - Điều kiện trước: ứng dụng đang chạy và trong trạng thái đăng nhập thành công. Điều kiện sau: hiển thị danh sách lịch sử giao dịch được đánh theo danh mục: trong ngày: giao dịch được ghi nhận trong ngày, trong tuần: giao dịch được ghi nhận trong tuần của những ngày trước đó, trong tháng: giao dịch được ghi nhận trong tháng của các tuần trước đó Kịch bản ca sử dụng: 1. Người sử dụng chọn chức năng hiển thị thông tin giao dịch của mình. 2. Ứng dụng truy xuất đến cơ sở dữ liệu của ứng dụng lấy định danh (ID) của người sử dụng (là một trong những thông tin trả về sau đăng nhập). Gửi thông tin đó đến dịch vụ web nhằm lấy thông tin của người sử dụng: 2.1. Nếu không thể kết nối với server, uses case “xử lý không thể kết nối server” được kích hoạt. 2.2. Nếu thông tin gửi lên chính xác, dịch vụ web trả về lịch sử giao dịch trog vòng một tháng, ứng dụng phân danh mục rồi hiển thị thông tin đó lên giao diện. Yêu cầu: thông tin phản hồi không quá 20 giây. Ca sử dụng con: o Khi hệ thống không thể kết nối tới server, hệ thống thông báo không thể kết nối cho người sử dụng. Hình 3.12. Use case: "Kiểm tra lịch sử giao dịch" 3.2.2.2.2. Hiển thị bản đồ xe buýt - Mô tả: là chức năng hiển thị bản đồ đi kèm với các trạm xe buýt, các vị trí hiện tại - của các xe của một tuyến xe nào đấy để người dùng trực quan hơn trong việc sử dụng dịch vụ xe buýt. Tác nhân: người dùng dịch vụ xe buýt. Điều kiện: ứng dụng đang chạy và trong trạng thái đăng nhập thành công. Điều kiện sau: hiển thị trên bản đồ các trạm xe buýt, vị trí các xe đang vận hành. Kịch bản ca sử dụng: 1. Người dùng chọn chức năng hiển thị bản đồ xe buýt. 2. Ứng dụng hiển thị bản đồ cơ bản, đi kèm với vị trí hiện tại của người sử dụng. 3. Người nhập tuyến xe mà người dùng muốn hiển thị thông tin, và chọn hiển thị. 35 - 4. Ứng dụng sẽ kiểm tra kết nối với server: 4.1. Nếu không thể kết nối đến server thực hiện use case “Hiển thị bản đồ xe buýt khi không thể kết nối được server”. 4.2. Nếu có thể kết nối đến server, ứng dụng sẽ kiểm tra coi tuyến đường đã được tải về hay chưa: 4.2.1. Nếu rồi, thực hiện truy xuất tới cơ sở dữ liệu ứng dụng lấy các điểm và hiển thị sau đó kết nối tới server lấy vị trí hiện tại của các xe buýt để hiển thị. 4.2.2. Nếu chưa, gửi thông tin tuyến đường tới server để lấy các thông tin đó về. Nếu lấy thành công thực hiện lưu trữ vào cơ sở dữ liệu các trạm xe ứng dụng và hiển thị. Yêu cầu phi chức năng: o có thể hiển thị các trạm xe mà trước đó truy xuất mà không cần kết nối server. o Các dữ liệu về bản đồ gồm: tọa độ trạm xe buýt, đường đi giữa các trạm xe - buýt,… sẽ được cập nhật dần dần vào cơ sở dữ liệu của ứng dụng (SQLite) để giảm số lần truy vấn đến server. Mỗi khi có thay đổi, server tăng chỉ số version, ứng dụng phải xóa toàn bộ dữ liệu có sẵn trong cơ sở dữ liệu cục bộ và bắt đầu cập nhập lại dữ liệu mới qua mỗi lần truy vấn của khách hàng. Ca sử dụng con: o Hiển thị bản đồ xe buýt khi không kết nối được server: Khi người sử dụng không kết nối thiết bị với server, chức năng này được sử dụng nhằm hiển thị các tuyến đường mà trước đó người sử dụng đã truy xuất tới server để lấy thông tin bằng cách lấy thông tin được lưu trong cơ sở dữ liệu của ứng dụng. 36 Hình 3.13. Use case: "Hiển thị bản đồ xe buýt" Để hiểu rõ hơn về use case này, quan sát biểu đồ Hình 3.14 biểu thị hoạt động của uses case trong ca sử dụng con : khởi tạo bản đồ và Hiển thị trạm xe buýt. ( Để hiểu rõ các lớp được dùng trong biểu đồ xem Hình 3.15). Hình 3.14. Sequence Diagram: Khởi tạo bản đồ và Hiển thị trạm xe buýt 37 3.2.2.3. Mô hình lớp phân tích: Mô hình phân tích lớp của ứng dụng hỗ trợ người dùng dịch vụ xe buýt được mô tả như Hình 3.15.Do tính chất trùng lặp với ứng dụng quản lý người dùng dịch vụ xe buýt, một số lớp sẽ không được nhắc lại, mô tả sơ bộ các lớp được thể hiện ở Bảng 3.2. Hình 3.15. Mô hình lớp phân tích: Ứng dụng hỗ trợ người dùng DVXB Uses case Tên lớp phân tích Mô tả sơ bộ Hiển thị HistoryPaymentsForm lịch sử giao dịch HistoryPaymentsControl ler Lớp giao diện cho phép nhân viên hiển thị thông tin giao dịch đã thực hiện. Hiển thị Mapform bản đồ Lớp giao diện hiển thị bản đồ xe buýt hỗ trợ người dùng Lớp điều khiển việc triết giao dịch từ dịch vụ web. MapController Lớp điều khiển việc lấy thôn tin số liệu bản đồ xe buýt từ location server Points Thực thể lưu tọa độ các trạm xe buýt Route Thực thể thông tin của một tuyến xe. PointOfRoute Thực thể lưu tập các tọa độ của trạm xe. DirectionsBean Thực thể lưu thông tin về tập các điểm tạo nên 38 một đoạn đường giữa hai tọa độ xe buýt Bảng 3.2. Các lớp phân tích: Ứng dụng hỗ trợ người dùng DVXB 3.3. Thiết kế 3.3.1. Kiến trúc ứng dụng Kiến trúc của ứng dụng được thể hiện đầy đủ ở Hình 3.16. - Ứng dụng quản lý người dùng dịch vụ xe buýt nhận các thông tin về nhân - viên, khách hàng và gửi giao dịch thông qua các dịch vụ web được kết nối với server (mối quan hệ (1)). Nó cũng gửi thông tin về vị trí hiện tại của xe buýt cho server lưu trữ thông tin về địa điểm của xe buýt (mối quan hệ (2)). Ứng dụng hỗ trợ người dùng dịch vụ xe buýt nhận thông tin khách hàng từ - dịch vụ web được kết nối với server (mối quan hệ (3)). Nhận thông tin về trạm xe buýt, địa điểm xe buýt từ server lưu trữ thông tin về địa điểm của xe buýt (mối quan hệ (4)). Nhận thông tin về bản đồ Google Map từ dịch vụ của Google (mối quan hệ (5)). Cả hai ứng dụng đều lưu một vài dữ liệu cục bộ như các thông tin bản đồ xe buýt, tài khoản (trong phiên sử dụng),… trong cơ sở dữ liệu SQLite (mối quan hệ (6)). Hình 3.16. Kiến trúc ứng dụng 3.3.2. Xác định gói thiết kế Ứng dụng được triển khai theo công nghệ xây dựng ứng dụng Android. Do đó ta xác định được các gói thiết kế sau: - Gói gồm các lớp Java là triển khai của các đối tượng thực thể (góc src). 39 - Và các gói khác trong android như: res chứa các gói về hằng, giao diện hay libs chứa các thư viện trong android và thư viện được import thêm,… Hình 3.17 biểu hiện thành phần của gói src của hai ứng dụng. Src bao gồm: - Gói Activity: chứa các Activity được thừa kế từ lớp Activity trong gói Android. Là các class điều khiển, tương tác với giao diện. Gói Bean: chứa các thực thể. Adapter: chứa các Adapter được thừa kế từ các gói Adapter phục vụ cho việc hiển thị danh sách. Common: chứa các lớp cho việc xử lý cơ bản. Serconnect: chứa các lớp giao tiếp với server hoặc web serivce. Database: chứa các lớp giao tiếp với cơ sở dữ liệu SQLite. Service: chứa các lớp Service được thừa kế từ lớp Service trong Android. Là thành phần thực thi ngầm không cần giao diện hiển thị như Activity. Draw: chứa một vài lớp để vẽ lên bản đồ GoogleMap. Hình 3.17. Gói Src 3.3.3. Thiết kế cho từng ca sử dụng Cơ sở để xác định các lớp thiết kế là các lớp phân tích, mỗi lớp phân tích sẽ cho chúng ta một khối thiết kế. Chi tiết hóa các khối thiết kế này chúng ta được các lớp thiết kế. Ứng dụng được thực hiện trên cấu trúc một ứng dụng Android. Vậy nên các lớp phân tích biên sẽ được thiết kế là các giao diện Layout trên cấu trúc xml. Các lớp phân tích điều khiển sẻ trở thành tập các lớp thiết kế gồm: Activity (lớp điều khiển giao diện – mỗi Acitivity tương ứng với một giao diện hiển thị), Asysntask ( lớp chạy ngầm 40 đồng bộ với giao diện Activity – thường dùng để chứa hàm thực thi các lớp Connect ), Connect (lớp dùng để kết nối với server hay dịch vụ web – nằm trong gói ServerConnect). Các lớp phân tích thực thể sẽ được phân tích tương ứng với một lớp thực thể và các phương thức tương ứng trong lớp SQLiteDatabase để tương tác với dữ liệu cục bộ trong ứng dụng. Sau khi qua quá trình phân tích, nếu loại bỏ các use case trùng lặp chúng ta xác định được tám use case chính trong cả hai ứng dụng. Để tránh việc nhắc lại các lớp đã được phân tích mà không có sự thêm mới trong các use case trước, tôi sẽ bỏ qua các lớp phân tích đó trong các use case sau nếu nó được nhắc đến. 3.3.3.1. Đăng Nhập Các lớp phân tích của ca sử dụng “Đăng Nhập” gồm có: LoginForm, LoginController và thực thể UserBean. Từ các lớp phân tích ta có được các lớp thiết kế thể hiện ở Bảng 3.3. Lớp phân tích Lớp thiết kế Chú thích LoginForm activity_login Định dạng Layout xml LoginController LoginActivity Lớp thừa kế Activity trong gói Android LoginAsyntask Lớp thừa kế Asyntask trong gói Android LoginConnect Lớp đối tượng trong Java UserBean Lớp đối tượng trong Java SQLiteDatabase Lớp thừa kế SQLiteHelper hỗ trợ việc thao tác với dữ liệu SQLite. UserBean Bảng 3.3. Lớp thiết kế : “Đăng nhập” 3.3.3.2. Đăng xuất Các lớp phân tích của ca sử dụng “Đăng Xuất” gồm có: LogoutForm, LogoutController và thực thể UserBean. Từ các lớp phân tích ta có được các lớp thiết kế thể hiện ở Bảng 3.4. Lớp phân tích Lớp thiết kế Chú thích 41 LogoutForm Là một phần của menu giao diện. Không có lớp riêng. LogoutController LogoutAsyntask Lớp thừa kế Asyntask trong gói Android LogoutConnect Lớp đối tượng trong Java Bảng 3.4. Lớp thiểt kế: “Đăng xuất” 3.3.3.3. Kiểm tra thông tin cá nhân Các lớp phân tích của ca sử dụng “Kiểm tra thông tin cá nhân” gồm có: InformationForm, InformationController và thực thể UserBean, UserInformationBean. Từ các lớp phân tích ta có được các lớp thiết kế thể hiện ở Bảng 3.5. Lớp phân tích Lớp thiết kế Chú thích InformationForm activity_information Định dạng Layout xml InformationController InformationActivity Lớp thừa kế Activity trong gói Android InformationAsyntask Lớp thừa kế Asyntask trong gói Android InformationConnect Lớp đối tượng trong Java UserInformationBean Lớp đối tượng trong Java SQLiteDatabase Lớp thừa kế SQLiteHelper hỗ trợ việc thao tác với dữ liệu SQLite. UserInformationBean Bảng 3.5. Lớp thiết kế: "Kiểm tra thông tin" 3.3.3.4. Xác thực người dùng dịch vụ xe buýt Các lớp phân tích “Xác thực người dùng xe buýt” gồm có UserAutheticationForm, UserAutheticationController, UserInformationBean, Payment. Từ các lớp phân tích ta có được các lớp thiết kế thể hiện ở Bảng 3.6. 42 Lớp phân tích Lớp thiết kế Chú thích UserAutheticationForm activity_checkertag Định dạng Layout xml InformationController CheckerTagActivity Lớp thừa kế Activity trong gói Android InformationAsyntask Lớp thừa kế Asyntask trong gói Android InformationConnect Lớp đối tượng trong Java PaymentAsyntask Lớp thừa kế Asyntask trong gói Android PaymentConnect Lớp đối tượng trong Java PaymentBean Lớp đối tượng trong Java SQLiteDatabase Lớp thừa kế SQLiteHelper hỗ trợ việc thao tác với dữ liệu SQLite. Payment Bảng 3.6. Lớp thiết kế:"Xác thực người dùng xe buýt" 3.3.3.5. Báo cáo vi phạm Các lớp phân tích “Báo cáo vi phạm” gồm có UserAutheticationForm, ReportController, UserInformationBean. Từ các lớp phân tích ta có được các lớp thiết kế thể hiện ở Bảng 3.7. Lớp phân tích Lớp thiết kế Chú thích ReportController ReportAsyntask Lớp thừa kế Asyntask trong gói Android Bảng 3.7. Lớp thiết kế: "Báo cáo vi phạm" 3.3.3.6. Kiểm tra lịch sử giao dịch (nhân viên): Các lớp phân tích “Hiển thị lịch sử giao dịch (nhân viên)” gồm có HistoryPaymentForm, HistoryPaymentController, Payments. Từ các lớp phân tích ta có được các lớp thiết kế thể hiện ở Bảng 3.8. Lớp phân tích Lớp thiết kế Chú thích 43 HistoryPaymentForm activity_history Định dạng Layout xml HistoryPaymentController HistoryActivity Lớp thừa kế Activity trong gói Android LoadHistoryAsyntask Lớp thừa kế Asyntask trong gói Android LoadHistoryConnect Lớp đối tượng trong Java Bảng 3.8. Lớp thiết kế: "Kiểm tra lịch sử giao dịch (nhân viên)" 3.3.3.7. Kiểm tra lịch sử giao dịch (người dùng dịch vụ xe buýt) Các lớp phân tích “Hiển thị lịch sử giao dịch (người dùng dịch vụ xe buýt)” gồm có HistoryPaymentForm, HistoryPaymentController, Payments. Từ các lớp phân tích ta có được các lớp thiết kế thể hiện ở Bảng 3.9. Lớp phân tích Lớp thiết kế Chú thích HistoryPaymentControl LoadHistoryCustomerAsyntask Lớp thừa kế Asyntask trong gói Android LoadHistoryCustomerConnect Lớp đối tượng trong Java Bảng 3.9. Lớp thiết kế: "Kiểm tra lịch sử giao dịch(người dùng)" 3.3.3.8. Hiển thị bản đồ xe buýt Use case này bao gồm các lớp phân tích: MapForm, MapController, Location, Route, DirectionBean, PointsOfRoute, Points. Từ các lớp phân tích ta có được các lớp thiết kế thể hiện ở Bảng 3.10. Lớp phân tích Lớp thiết kế Chú thích MapForm activity_main Định dạng Layout xml MapController MainActivity Lớp thừa kế Activity trong gói Android LoadVersion Lớp thừa kế Asyntask trong gói Android. LoadData Lớp 44 thừa kế Asyntask trong gói Android. LoadFullRoute Lớp thừa kế Asyntask trong gói Android. LoadBusLocation Lớp thừa kế Asyntask trong gói Android. RideConnectServer Lớp đối tượng trong Java Location Location Là lớp có sẵn. Route Route Lớp đối tượng trong Java DirectionBean DireactionBean Lớp đối tượng trong Java PointOfRoute PointOfRoute Lớp đối tượng trong Java Points LatLng Lớp đối tượng trong gói Google Services Play Bảng 3.10. Lớp thiết kế: "Hiển thị bản đồ xe buýt" 3.3.4. Thiết kế giao diện 3.3.4.1. Ứng dụng quản lý người dùng dịch vụ xe buýt Giao diện ứng dụng quản lý người dùng dịch vụ xe buýt được thiết kế như Hình 3.18. Gồm có: - - Giao diện đăng nhập: cho phép nhân viên đăng nhập bằng tài khoản, mật khẩu và biển số xe hoặc qua thẻ NFC. Giao diện thông tin nhân viên: hiển thị thông tin sơ lược về nhân viên. Giao diện xác thực người dùng: cho phép nhân viên xác thực người dùng thông qua thẻ NFC hoặc báo cáo bi phạm. Giao diện hiển thị thông tin sơ lược về người dùng khi thẻ được xác nhận. Giao diện lịch sử giao dịch: chứa thông tin nhân viên đã duyệt giao dịch trong vòng một tháng gần nhất. Trong đó các mối qua hệ của các màn hình như sau: - Màn hình đầu tiên khi khởi động ứng dụng là giao diện đăng nhập. Đăng nhập thành công, ứng dụng hiển thị giao diện thông tin nhân viên ( quan hệ (1)). 45 - Từ giao diện thông tin nhân viên, xác thực người dùng , lịch sử giao dịch đều có thể chuyển tiếp qua lai giữa các giao diện thông qua thanh menu (quan hệ (3),(4),(5)) và có thể đăng nhập (quan hệ (2)). Hình 3.18. Giao diện quản lý quản lý người dùng dịch vụ xe buýt 3.3.4.2. Ứng dụng hỗ trợ người dùng dịch vụ xe buýt Giao diện ứng dụng hỗ trợ người dùng dịch vụ xe buýt được thiết kế như Hình 3.19. Gồm có: - Giao diện đăng nhập: cho phép người dùng đăng nhập bằng tài khoản, mật khẩu hoặc qua thẻ NFC. Giao diện thông tin người dùng: hiển thị thông tin sơ lược về người dùng. Giao diện bản đồ xe buýt: cho phép nhân viên tìm kiếm các trạm dừng của các tuyến xe và quan sát vị trí của các xe đang vận hành. 46 - Giao diện lịch sử giao dịch: chứa thông tin người dùng đã giao dịch trong vòng một tháng gần nhất. Trong đó các mối qua hệ của các màn hình như sau: - Màn hình đầu tiên khi khởi động ứng dụng là giao diện đăng nhập. Đăng nhập thành công, ứng dụng hiển thị giao diện thông tin người dùng ( quan hệ (1)). Từ giao diện thông tin cá nhân, bản đồ giao dịch , lịch sử giao dịch đều có thể chuyển tiếp qua lai giữa các giao diện thông qua thanh menu (quan hệ (3),(4),(5)) và có thể đăng nhập (quan hệ (2)). Hình 3.19. Giao diện ứng dụng hỗ trợ người dùng dịch vụ xe buýt 47 CHƯƠNG 4: THỰC NGHIỆM 4.1. Môi trường thực nghiệm 4.1.1. Cấu hình thiết bị - Thiết bị được sử dụng trong thực nghiệm là điện thoại Android dòng HTC ONE J. Có cấu hình như sau: HTL22 CPU Bộ nhớ Software Information Số lượng Cores Quad Core (4 nhân) Bộ vi xử lý 1.7 GHz Bộ nhớ trong 32 GB Ram 2 GB Android version 4.1.2 HTC sense version 5.0 HTC SDK API level 5.2.3 PRI version 3.39_01C PRL version 00000 Kernel version 3.4.10-g54237c3 Baseband version 1.23.11.0523 Browser version Webkit/534.30 Bảng 4.1. Cấu hình thiết bị thực nghiệm - Loại thẻ NFC được sử dụng trong thực nghiệm là: Sony Xperia NFC Smart Tags. Máy tính dùng để phát triển ứng dụng có cấu hình như sau: Asus x42j CPU Intel(R) Pentium(R) CPU P6100 @2.00 Ghz 48 RAM 2.00 GB OS Window 7 Professional 32-bit Bảng 4.2. Cấu hình máy tính 4.1.2. Các công cụ phần mềm Bảng sau trình bày về công cụ, gói phần mềm, … quan trọng mà tôi đã sử dụng để xây dựng hệ thống này: Ghi chú Eclipse IDE for Java and Report Môi trường phát triển ứng dụng Developers tích hợp Android SDK Version: Juno Service Release 2 Build id: 20130225-0426 Apache 2.2.8 (Win32) Là server được sử dụng trong việc chạy thử nghiệm PHP 5.2.6 Java 1.7.0_55 Là ngôn ngữ lập trình để xây dựng hệ thống MySQL 5.0.51 Hệ quản trị cơ sở dữ liệu MySQL Bảng 4.3. Công cụ, và các gói phần mềm,… 4.2. Kết quả thực nghiệm Về cơ bản một phần hệ thống trong phạm vi khóa luận đã đáp ứng được các yêu cầu cần thiết và hoàn thành tài liệu thiết kế chi tiết nền tảng hệ thống nằm trong phạm vi khóa luận bao gồm: ứng dụng quản lý người dùng dịch vụ xe buýt và ứng dụng hỗ trợ người dùng dịch vụ xe buýt, cũng như phía server quản lý các thông tin vị trí về tuyến xe và xe buýt. Với những kết quả nghiên cứu và thực nghiệm như đã trình bày, hệ thống nằm trong phạm vi khóa luận đã giải quyết được cơ bản các vấn đề được được đặt ra. Tuy nhiên do còn thiếu kinh nghiệm nên kết quả thu được còn nhiều hạn chế, cần tiếp tục được cải thiện, nâng cấp. 49 4.3. Đánh giá và hướng phát triển Hầu hết các thành phần của hệ thống đều cần cải thiện theo các hướng khác nhau để tăng cường khả năng của toàn hệ thống cũng như cải tiến các chức năng khác. Thay đổi giao diện cho phù hợp, tiện ích đáp ứng yêu cầu người dùng hơn nữa Mặt khác, có thể tích hợp thêm việc thanh toán, quản lý người dùng bằng thành phần bảo mật trong điện thoại, thẻ sim, hay thông qua chính ứng dụng hỗ trợ người dùng dịch vụ xe buýt theo công nghệ giả lập thẻ nói trên. Nhìn chung, đây là một hệ thống khá hoàn chỉnh về chức năng và có thể được phát triển để cung cấp dịch vụ mang tính chất thương mại. Để đạt được mục tiêu đó, cần đặt ưu tiên cao nhất vào việc đảm bảo tính ổn định của hệ thống, chống các truy cập trái phép, đảm bảo an toàn thông tin của người sử dụng, ... 50 CHƯƠNG 5: KẾT LUẬN Đi kèm với tốc độ tăng trưởng kinh tế và quá trình đô thị hóa, nhu cầu cho dịch vụ di chuyển ngày càng tăng, kéo theo đó là sự mở rộng của các dịch vụ công cộng. Khuyến khích người dân dùng dịch vụ xe buýt là một trong những biện phát để giảm các phương tiện giao thông di chuyển trên đường. Hiển nhiên, người dùng dịch vụ xe buýt theo đó sẽ ngày càng tăng. Bài toán về xác thực người dùng, quản lý thanh toán, hỗ trợ khách hàng sẽ ngày càng trở nên khó khăn trong việc kiểm soát. Với kết quả nghiên cứu và thực nghiệm đã trình bày, đã bước đầu thực hiện một phần nào đó trong việc xây dựng hệ thống giải quyết các bài toán đã nêu. Tuy nhiên, với kinh nghiệm chưa nhiều, kiến thức chưa thực sự là đủ và khả năng tìm hiểu còn yếu. Cho nên,việc sai sót là khó tránh khỏi. Theo dó là kết quả thu được còn nhiều hạn chế và còn tiếp tục sửa chữa, cải thiện và xây dụng nhiều hơn nữa. 51 TÀI LIỆU THAM KHẢO Tiếng Anh 1. [1] “What is NFC?” , NFC Forum. Retrieved 14 June 2011. 2. [2] a b Nikhila (26 October 2011), “NFC — future of wireless communication”, Gadgetronica. 3. [3] a b Nosowitz, Dan (1 March 2011), “Everything You Need to Know About Near Field Communication”. Popular Science Magazine. Popular Science, Retrieved 14 June 2011. 4. [4] “Google Wallet — where it works”, Google, Retrieved 11 December 2011. 5. [5] “Germany: Transit Officials Enable Users to Tap or Scan in New Trial”, NFC Times, February 11, 2011. 6. [6] “Austria: 'Rollout' Uses NFC Reader Mode To Sell Tickets and Snacks”, NFC Times, March 1, 2011. 7. [7] Saylor, Michael (2012). “The Mobile Wave: How Mobile Intelligence Will Change Everything”, Perseus Books/Vanguard Press, p. 63. ISBN 9781593157203. 8. [8] “Telecom New Zealand and Westpac test NFC with Auckland Transport”, NFC World, April 30, 2012. 9. [9] “Italy: Telecom Italia and ATM to launch NFC ticketing service in Milan”, NFC World, April 24, 2009. 10. [10] “Irancell demonstrates NFC payments and ticketing ”, NFC World, Retrieved 2 April 2014. 11. [11] “Turkcell Wallet Transport”, NFC, April 30, 2012. 12. [12] Patauner, C. “High Speed 13.56 MHz” (PDF), EuraSIP. RFID/NFC at the Frequency of 13. [13] “Near Field Communication Versus Bluetooth”, Retrieved 28 November 2012. 52 14. [14] “Ecma International: Standard ECMA-340, Near Field Communication Interface and Protocol (NFCIP-1)”, December 2004 15. [15] “Ecma International: Standard ECMA-352, Near Field Communication Interface and Protocol–2 (NFCIP-2)”, December 2003 16. [16] “World's leading mobile operators announce commitment to NFC technology”, GSMA press release, corporate website, February 21, 2011.[2] 17. [17] “GSM Association Aims For Global Point Of Sale Purchases by Mobile Phone”, GSM Association, 13 February 2007 18. [18] “Momentum Builds Around GSMA's Pay-Buy Mobile Project”, GSM Association, 25 April 2007 19. [19] “Verizon Wireless and Discover Financial Services Join the NFC Forum as Principal Members”, NFC Forum Press Release, June 19, 2013. 20. [20] “Ernst Haselsteiner, Klemens Breitfuß: Security in near field communication (NFC) PDF (158 kB)”, Philips Semiconductors, Printed handout of Workshop on RFID Security RFIDSec 06, July 2006 21. [21] Hancke, Gerhard P (July 2008). “Eavesdropping Attacks on HighFrequency RFID Tokens”. 4th Workshop on RFID Security (RFIDsec'08). pp. 100–13. 22. [22] “NFC Basics”, Android Developers. 23. [23] “Host-Based Card Emulation”, Android Developers. 24. [24] “Advanced NFC”, Android Developers. 25. [25] “Google Map For Mobile”, Google Mobile. 26. [26] “Fragment”. Android Developer. 27. [27] “NW 6.5 SP8: Novell MySQL Administration Guide”, Novell Doccument. 28. [28] “About SQLite”, SQLite Home Page. 29. [29] “Android (operating system)”, en-wikipedia. Tiếng Việt 1. [30] Nguyễn Việt Cường, “Số hóa hệ thống xe bus trên nền Google Maps”, Khóa luận tốt nghiệp, Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội, 2012. 53 2. [31] Nguyễn Văn Nội, “Phát triển hệ thống quản lý người dùng dịch vụ xe buýt trên nền tảng Struts2”, Khóa luận tốt nghiệp, Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội, 2014. 3. [32] Tuyết Mai, “Người đi xe buýt chiếm 92% sản lượng vận chuyển”, Website Thông tấn xã Việt Nam – vietnamplus.vn, ngày 23/01/2010. 4. [33] “Android”, vi-wikipedia. 54 [...]... phần thứ hai của hệ thống là hai ứng dụng: ứng dụng quản lý người sử dụng dịch vụ xe buýt và ứng dụng hỗ trợ người dùng dịch vụ xe buýt trong việc quản lý tài khoản giao dịch của mình và một bản đồ xe buýt để người sử dụng có thể quan sát được vị trí hiện tại của các xe buýt và các trạm dừng của tuyến xe buýt đó Để xây dựng được ứng dụng quản lý người dùng dịch vụ xe buýt, bài toán đặt ra trước hết... dụng quản lý người dùng dịch vụ xe buýt sẽ là trung gian giao tiếp giữa thẻ từ NFC định danh người dùng và dịch vụ web thẩm định người dùng Điều này có nghĩa là mỗi xe buýt sẽ được trang bị một thiết bị có khả năng đọc thẻ từ, ở đây tôi chọn thiết bị Android có hỗ trợ đọc thẻ từ NFC Còn với ứng dụng hỗ trợ người dùng dịch vụ xe buýt, ngoài việc sử dụng thẻ NFC để định danh người sử dụng như ứng dụng quản. .. nhất một người sử dụng duy nhất Cách định danh phổ biến và thường được sử dụng là mỗi người dùng dịch vụ xe buýt thường được cấp phát một thẻ xe buýt trong đó ghi rõ nội dung cần thiết để xác thực người sử dụng và tình trạng sử dụng dịch vụ hiện tại của người xe buýt đó Tuy nhiên, thẻ định danh 1 hiện tại đang được sử dụng tại Việt Nam là loại thẻ giấy và việc xác thực người dùng dịch vụ xe buýt được... không phân biệt các ứng dụng cốt lõi và các ứng dụng được phát triển bởi bên cung cấp thứ ba Mọi ứng dụng đều được phát triển trên cơ sở truy cập toàn bộ chức năng của thiết bị di động nhằm cung cấp cho người dùng các ứng dụng và dịch vụ phong phú Với các thiết bị xây dựng trên nền tảng Android, người dùng có thể tùy chỉnh thiết bị theo cách họ mong muốn Ví dụ như, cài đặt bất cứ ứng dụng nào, thay đổi... XÂY DỰNG HỆ THỐNG 3.1 Mô hình hệ thống Hệ thống quản lý người dùng dịch vụ xe buýt bao gồm: - User Management Database: cơ sở dữ liệu lưu trữ thông tin về tài khoản - người dùng dịch vụ xe buýt, nhân viên xe buýt, và lịch sử giao dịch, Location Database: cơ sở dữ liệu này lưu trữ về vị trí tọa độ của các trạm - dừng xe buýt, vị trí hiện thời của xe buýt đang hoạt động User Management Server: máy chủ... máy chủ nhận các truy vấn từ ứng dụng quản lý người dùng - dịch vụ xe buýt (Staff Android Application) và hỗ trợ người dùng (Customer Android Application) nhằm lưu trữ hoặc lấy thông tin về các tọa độ từ Location Database User Management Webservices: là dịch vụ web cung cấp các thông tin cần - thiết cũng như xử lý, lưu trữ các cuộc giao dịch từ khách hàng trên các chuyến xe Sau khi truy vấn, kết quả... NdefMessage, bởi vì Android tìm kiếm AAR trên tất cả NdefRecord của NdefMessage Nếu tìm thấy AAR, Android kích hoạt ứng dụng qua tên gói của ứng dụng được nhúng trong AAR Nếu không tìm thấy ứng dụng, Android sẽ bật Google Play để tìm kiếm ứng dụng và tải về AAR được sử dụng để ngăn các ứng dụng khác cùng xử lý một itent mà lập trình viên triển khai trong thẻ NFC AAR chỉ hỗ trợ ở mức độ ứng dụng, bộ lọc Intent... dụng quản lý người dùng dịch vụ xe buýt đã nói ở phần trên Đối với bài toán còn lại là làm việc với dữ liệu bản đồ, tôi sẽ giải quyết bài toán này thông qua Google Maps API vì tính phổ biến, dữ liệu vừa đủ và sự đa dạng trong các tính năng mà nó cung cấp trên nền Android cùng với dữ liệu các trạm xe buýt được số hóa ở khóa luận “Số hóa hệ thống xe bus trên nền Google Maps” [30], và các dịch vụ web để... thiết đặt cách xử lý các sự kiện bằng các ứng dụng mà họ nghĩ là phù hợp 2.1.2.3 Phá vỡ ranh giới ứng dụng Android phá vỡ các rào cản cần thiết nhằm hướng tới xây dựng các ứng dụng mới và sáng tạo nhờ vào khai thác tối đa chức năng của phần cứng Ví dụ như, nhà phát triển có thể xây dựng các ứng dụng chụp ảnh với nhiều đổi mới so với ứng dụng cốt lõi có sẵn 2.1.2.4 Phát triển các ứng dụng một cách nhanh... Các công cụ phát triển khác cũng có sẵn, gồm có Bộ phát triển gốc dành cho các ứng dụng hoặc phần mở rộng viết bằng C hoặc C++, Google App Inventor, một môi trường đồ họa cho những nhà lập trình mới bắt đầu, và nhiều nền tảng ứng dụng web di động đa nền tảng phong phú 2.1.2.5 Quản lý bộ nhớ Android được thiết kế quản lý bộ nhớ (RAM) nhằm giảm tối thiệu tiêu thụ điện năng Khi một ứng dụng Android không

Ngày đăng: 01/10/2015, 09:01

Từ khóa liên quan

Mục lục

  • 2.1. Tổng quan về Android

  • 2.2. Giới thiệu về công nghệ NFC và Android NFC API

  • 2.3. Google Maps Android API

  • 2.4. Hệ quản trị cơ sở dữ liệu MySQL

  • 2.5. Cơ sở dữ liệu nhúng SQLite

  • 3.1. Mô hình hệ thống

  • 3.2. Phân tích và xác định yêu cầu

  • 3.3. Thiết kế

  • 4.1. Môi trường thực nghiệm

  • 4.2. Kết quả thực nghiệm

  • 4.3. Đánh giá và hướng phát triển

  • Tiếng Anh

  • Tiếng Việt

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan