Hình 4.2.12: biểu đồ tuần tự kết bạn
Kết bạn cho phép mở rộng kết nối. Thành viên của mạng xã hội địa điểm có thể kết bạn với các thành viên Facebook và ngược lại. Mối quan hệ sẽ được thêm vào trên server nếu 1 hoặc 2 người là thành viên của mạng xã hội địa điểm và cập nhật trên Facebook nếu cả 2 người là thành viên của Facebook. Việc lấy danh sách bạn bè cũng tương tự. Thành viên Facebook sẽ lấy cả bạn bè trên Facebook và trên mạng xã hội địa điểm. Tất nhiên là phải chờ sự chấp nhận của người được mời.
5. Client
5.1. Kiến trúc tổng quan
Client là ứng dụng trên điện thoại di động chạy hệ điều hành Android. Do đó, các lớp được thiết kế cần thích hợp với kiến trúc Android. Ứng dụng đồ án xây dựng theo kiến trúc 3 tầng MVC như hình vẽ:
Hình 5.1.1 kiến trúc tổng quan client
Tầng View gồm các thành phần giao diện hiện thị cho người dùng và nhận các yêu cầu của người dùng. Dữ liệu hiện thị lấy từ các bean và quản lý các bean do tầng Controler phụ trách. Các yêu cầu của người dùng cũng được chuyển cho tầng 2 này xử lý.
Tầng controller là trái tim của ứng dụng- Heart là lớp chính. mọi xử lý điều hướng được thực hiện tại đây như : chuyển các yêu cầu người dùng thành các request lên server, hay thao tác dữ liệu … Tầng này có thành phần connectmanage quản lý kết nối, thiết lập nó và nhận hay gửi dữ liệu người dùng. Các dữ liệu sẽ hiển thị cho người dùng cũng qua tầng này chuyển lên tầng View.
Tầng Model liên quan đến cơ sở dữ liệu của ứng dụng. Các bean sẽ trong BeanBox nhận dữ liệu chuyển ra và vào cơ sở dữ liệu. Việc này sẽ được Heart uỷ quyền cho đối tượng quản lý cơ sở dữ liệu.
Hình 5.2.a giao diện menu Bản đồ
Chức năng hiển thị status của bạn bè hay thành viên chia sẻ nào đó.
Hình 5.2.d menu danh sách
5.3. Biểu đồ lớp
Thành phần view gồm các 4 Activity chính là : MainActivity, MapActivity( hiển thị bản đồ), MeActivity ( hiển thị thông tin cá nhân), PeopleActivity ( tương ứng với menu Danh sách ).
Thành phần Controler gồm lớp chính là Heart, trái tim của ứng dụng, lớp này sẽ dùng lớp ConnectActivity để gửi và nhận dữ liệu tới Server. Dữ liệu gửi đi và nhận về nằm trong các lớp JSON chứa các trường thông tin.
Thành phần còn lại là Model gồm lớp quản lý database là databaseManager. Lớp này có thành phần con là SQLiteDataBase có hỗ trợ trong thư viện lập trình Android và ánh xạ tới file database của ứng dụng. Dữ liệu sẽ được lưu trong các Bean được Heart khởi tạo trước khi thao tác với các dữ liệu.
Hình 5.3 biểu đồ lớp
5.4. Biểu đồ tuần tự
5.4.1. Usecase định vị bản thân
Ứng dụng sử dụng lớp Mapactivity để lắng nghe thay đổi vị trí của người dùng. Khi người dùng thay đổi vị trí 1 khoảng cách cho trước ( trong ứng dụng là 500m) hoặc người dùng chủ động định vị bản thân, update Location sẽ được thực hiện, sẽ cập nhật vị trí và gửi về server nếu cần thiết.
Hình 5.4.1 biểu đồ tuần tự định vị bản thân
5.4.2. Usecase bình luận
Hình 5.4.2 biểu đồ tuần tự bình luận
Người dùng bình luận status hoặc experience của người khác sẽ được lớp Heart uỷ quyền cho connectActivity thực hiện với dữ liệu gửi đi là đối tượng JSONcomment sau khi đã khởi tạo. respond trả về sẽ được kiểm tra , nếu thành công sẽ lưu vaaof cơ sơ dữ liệu.
Hình 5.4.3 biểu đồ tuần tự chia sẻ trạng thái
Cũng tương tự như bình luận lớp connectActivity sẽ được uỷ quyền để gửi đi JSONstatus đã được khởi tạo nhờ lớp Heart. Một điều khác là không cần phải lưu vào cơ sở dữ liệu.
5.4.4. Usecase chia sẻ trải nghiệm
Hoàn toàn tương tự với usecase chia sẻ trạng thái, dữ liệu gửi đi có thể nhiều hơn nếu người dùng có đăng kèm theo ảnh cá nhân.
Hình 5.4.4 biểu đồ tuần tự chia sẻ trải nghiệm
5.4.5. Usecase gửi tin nhắn
Hình 5.4.4 biểu đồ tuần tự khám phá địa điểm
Khám phá địa điểm là chức năng người dùng gửi yêu cầu lấy thông tin liên quan đến địa điểm mà họ chọn. thông tin là các trải nghiệm của người khác về địa điểm này nếu họ chia sẻ với người dùng. Người dùng cần gửi đi ID của place đến Server, dữ liệu trả về là các trải nghiệm liên quan.
6. Server
6.1. Kiến trúc tổng quan
Server được xây dựng theo mơ hình web MVC.
Hình 6.1 kiến trúc Server
Tuy nhiên dữ liệu hiện thị không hiện thị trên web nên tầng View sẽ trả về dữ liệu theo định dạng JSON object để thuận tiện cho việc trao đổi dữ liệu và kiến trúc RESTful Service. Đối với mơ hình web MVC có rất nhiều framework hỗ trợ. Trong khuôn khổ đồ án sử dụng Springweb MVC vì nó hỗ trợ mạnh kiến trúc Restful và JSON object. Ngoài ra ở tầng Model, đồ án sử dụng Hibernate Frame work để công việc kết nối với database dễ dàng hơn. Cơ sở dữ liệu được xây dựng bằng Oracle 10g .
Khi ứng dụng gửi request đến server theo các yêu cầu của kiến trúc RESTful Service như post, get, put, delete, Tomcat nghe ngóng và chuyển yêu cầu này Front controller của Spring Framework. Tiếp tục, request được uỷ thác cho Controler. Việc chuyển công việc thao tác dữ liệu liên quan nếu có sẽ được thực hiện bởi Model được tạo bởi Controler. Tại đây, ta có Hibernate hỗ trợ. Hibernate có các bean và các bean này ánh xạ với database. Các bean được tạo ra và được khởi tạo dữ liệu và dữ liệu sẽ truyền vào bean, bean sẽ lăn ra lăn vào database để thực hiện cơng việc thao tác dữ liệu của mình. Việc ánh xạ sẽ được qua các file cấu hình mà Hibernate yêu cầu. Hibernate kết nối với database Oracle 10g với thư viện của mình. Kết quả trả về sẽ được Controler đẩy cho Front controller và nó sẽ thực hiện tạo các đối tượng dữ liệu trả về cho các request theo mẫu View Template mà ở đây là các đối tượng JSON object.
6.2. Biểu đồ lớp
Kiến trúc web MVC được xây dựng theo framework Spring MVC 3.0. Các lớp listener các yêu cầu từ client được framework hỗ trợ. Việc xây dựng controller là kế thừa các lớp trong thư viện. Các lớp chính có thể nhóm thành 3 nhóm:
mapping. dữ liệu sẽ truyền cho các Bean và thực hiện thao tác với database. Các bean này cũng được xuất hiện trong các file cấu hình của Hibernate.
Hình 6.2 biểu đồ lớp server
6.3. Thiết kế Cơ sở dữ liệu 6.3.1. Mơ hình thực thể liên kết
Cơ sở dữ liệu xoay quanh người dùng. Người dùng là myCharacter – nhân vật chính. Người dùng có những trải nghiệm về điểm, có lược sử hành động của mình tại đâu đó, các địa điểm này sẽ được coi là địa điểm mà người dùng quan tâm, lược sử hay trải nghiệm sẽ được chia sẻ với những ai. Người dùng kết bạn với ai, có inbox và outbox chứa các tin nhắn . Và khi họ viết comment về hành động hay lược sử , trải nghiệm của người khác. Notification là thơng báo cho người dùng họ có gì tương tác với họ chẳng hạn : bạn bè vừa comment hay có tin nhắn, hay nhận được lời mời kết bạn …
Hình 6.3.1 sơ đồ thực thể liên kết
6.3.2. Thiết kế bảng cơ sở dữ liệu
Database gồm 10 bảng với bảng mycharacter làm trung tâm liên kết với các bảng khác. Riêng bảng policy liên kết ngầm định với bảng experience , history và mycharacter. Policy type ở các bảng này có 4 kiểu: all- tất cả mọi người được phép xem, friend – chỉ có bạn bè mới được xem – no one , không ai được xem cả và some- 1 vài người chỉ định trong policy mới được xem. Đây là cách liên kết ngầm định với các bảng còn lại của policy.
Comment cũng có 2 loại 1 loại là comment lên status và loại còn lại là lên experience. Quyết định thuộc loại nào do trường type và targetid là id của comment hoặc exprience.
Bảng notification có trường đặc biệt là type và targetid cũng chỉ ra đối tượng tương tác thông báo cho người dùng như là comment hay lời mới kết bạn…
Hình 6.3.3.a bảng policy
Hình 6.3.3.b bảng place
Hình 6.3.3.c bảng notification
Hình 6.3.3.d bảng comment
Hình 6.3.3.e bảng mycharacter
Hình 6.3.3.g bảng image
Hình 6.3.3.h bảng history
Hình 6.3.3.i bảng friend
Hình 6.3.3.j bảng experience
6.4. Biểu đồ Usecase
Hình 6.4 biểu đồ usecase server
Về cơ bản các usecase ở server giống với usecase của hệ thống nhưng tác nhân giờ đây là các yêu cầu từ client nên chi tiết về mặt kỹ thuật hơn hệ thống. các chức năng cơ bản tương ứng như login,get place Experience tương ứn với khám phá địa điểm của hệ thống, get people in place tương ứng với khám phá xung quanh, ping message tương ứng với gửi tin nhắn,post comment tương ứng với bình luận, post experience tương ứng với chia sẻ trải nghiệm, post status tương ứng với chia sẻ hành động, post make friend request và post make friend confirm tương ứng với usecase kết bạn trên của mạng xã hội…
Hình 6.5.1 biểu đồ tuần tự login
Mỗi ứng dụng đều cần đăng nhập của người dùng. Các thành viên của Facebook sẽ đăng nhập với server của Facebook, login này chỉ áp dụng cho thành viên của mạng xã hội.Khi nhận được yêu cầu, controller được uỷ thác sẽ gọi đến lơp characterBO, lớp này gọi đến phương thức tương ứng để trả về dữ liệu. dữ liệu bao gồm thông tin người dùng, danh sách bạn bè, và notification là thơng báo cho người dùng có gì mới với mình.
Controller cũng thực hiện việc kiểm tra kết quả trả về. Việc đăng nhập xảy ra như tiến trình trên hình.
6.5.2. Usecase lấy vị trí của 1 người ( get person Location )
Khi nhận được yêu cầu, controller được uỷ thác sẽ gọi đến lơp characterBO, lớp này gọi đến phương thức tương ứng để trả về dữ liệu. Và điều cần làm là đối chiếu người gửi yêu cầu có nằm trong danh sách cho phép hay không. Thêm một điều nữa là có thể người được yêu cầu về vị trí có thể chưa tham gia mạng xã hội mà là thành viên Facebook, do đó cần trả về kết quả phù hợp.
Hình 6.5.2 biểu đồ tuần tự get person location
6.5.3. Usecase get people in place
Usecase tương ứng với usecase khám phá địa điểm tại client. đầu vào là địa điểm, đầu ra là danh sách character. Tương tự như trên lớp BO và DAO sẽ thực hiện nhiệm vụ lấy về dữ liệu. Tất nhiên kết quả trả về là danh sách những ai chia sẻ tại địa điểm đó.
Hình 6.5.3 biểu đồ tuần tự get people in place
6.5.4. Usecase getPerson - lấy thông tin thành viên.
Chức năng tương ứng khi người dùng muốn hiển thị thông tin chi tiết của người khác so với những thông tin cơ bản như tên vị trí hay status. Đó có thể là danh sách bạn bè, các địa điểm mà người dùng quan tâm và cả những trải nghiệm của họ trên các địa điểm. Tất nhiên, phải kiểm tra người gửi yêu cầu có nằm trong số những người được cho phép hay khơng.
Hình 6.5.4 biểu đồ tuần tự get person
6.5.5. Usecase get place Exerience
Người dùng sẽ gửi ID của mình để gửi yêu cầu, Server sẽ kiểm tra xem họ được xem những trải nghiệm nào của ai trên địa điểm này . Danh sách trả về là list Experience. Các lớp BO và DAO tương ứng với Experience được thực hiện giống như các usecase trước.
Hình 6.5.5 biểu đồ tuần tự get place experience
6.5.6. Usecase ping message gửi tin nhắn
Các tin nhắn sẽ được lưu trên server và người dùng sẽ ping message này cho người khác. Người nhận sẽ đọc tin nhắn sau khi tải về máy. chức năng khá đơn giản. message bao gồm thông tin về người gửi ,người nhận, nội dung, ngày tháng. Tin nhắn chỉ lưu trên server nên khái niệm outbox và inbox sẽ chung nhau cùng dữ liệu và sẽ phân biệt khi thao tác trên người gửi hay người nhận. Các lớp BO và DAO như thường lệ là chèn vào bảng dữ liệu tương ứng.
Hình 6.5.6 biểu đồ tuần tự ping message
6.5.7. Usecase post comment
Comment có 2 loại là comment tới status hay experience. Do đó comment có trường type và objectID để có thể truy cập đúng đối tượng. hệ thống cũng chèn thêm dữ liệu về thời gian post vào dữ liệu. Việc insert tiến hành giống như các usecase trên.
Hình 6.5.7 biểu đồ tuần tự post comment
6.5.8. Usecase post status
Hình 6.5.8 biểu đồ tuần tự post status
Tương tự như post comment nhưng không phải là chèn thêm vào bảng mà cập nhật lại các trường trong bảng mycharacter. tiếp đó là lưu status trước đó vào bảng history = lược sử các trạng thái hay hành động của người dùng.
6.5.9. Usecase post experience
Cũng tiến hành tương tự nhưng phức tạp hơn trong trường hợp post status hay comment vì dữ liệu có thể kèm theo image. Do đó cần kiểm tra nguồn bức ảnh nếu có. Nếu là file image ta sẽ chèn vào cơ sở dữ liệu và trả về dạng url, nếu là ảnh từ Facebook ta cũng có dạng url. Tiếp đó ta sẽ chèn vào bảng dữ liệu tương ứng là experience table.
Hình 6.5.9 biểu đồ tuần tự post exprience
7. Giao tiếp Server-client
Định dạng JSON được chọn làm định dạng trao đổi giữa server và client do tính chất gọn nhẹ. Các hệ thống lớn cũng cho thấy sự thành công khi sử dụng định dạng này như Facebook. Dữ liệu trả về sẽ lưu trong bean của server và sẽ xuất dưới định dạng Json nhờ thư viện chuyển đổi trong String. Tại Client dữ liệu thu về sẽ được chuyển lại thành bean nhờ lớp Resttemplate chuyển đổi.
8. Cài đặt và thực thi
Xây dựng ứng dụng đồ án chưa thể xây dựng đầy đủ các chức năng mà xây dựng các chức năng chính như menu Map- bản đồ, Me- tơi, List- danh sách như trên hình:
Hình 8.2 giao diện bản đồ ứng dụng client với status
Hình 8.3 giao diện danh sách ứng dụng client
Hình 8.4 giao diện tơi ứng dụng client
Chương III Đánh giá 9. Đánh giá tổng quan 9.1. Ưu điểm
Mạng xã hội địa điểm không phải quan tâm đến việc thu hút người dùng vì kết nối với Facebook, có thể coi như 1 plugin của Facebook nhưng vẫn mở rộng cho các thành viên không phải là facebook.
Ứng dụng client sử dụng thư viện của Android trong việc hiển thị bản đồ và nhận tín hiệu GPS nên tận dụng tối ưu điểm mà thư viện cung cấp.
Mơ hình kiến trúc MVC nên tận dụng những điểm mạnh mà kiến trúc này mang lại như dễ dàng nâng cấp, bảo trì, minh bạch trong các chức năng.