Des lythuyet nhom03 tinder report

Hiểu được xu hướng của thời đại 4.0, nhóm em đã quyết định tìm hiểu và nghiên cứu ứng dụng Tinder - một trong những ứng dụng hẹn hò phổ biến nhất ở Việt Nam hiện nay.. 1.2 Mục tiêu của đ

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

MỤC LỤC

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN 2

BẢNG PHÂN CÔNG, ĐÁNH GIÁ THÀNH VIÊN 35

MỤC LỤC 3

MỤC LỤC BẢNG 5

MỤC LỤC HÌNH ẢNH 5

1 Tổng quan về đồ án 8

1.1 Lý do chọn đề tài: 8

1.2 Mục tiêu của đề tài 8

1.3 Phương pháp nghiên cứu 8

1.4 Cơ sở lý thuyết và những nghiên cứu liên quan 8

2 Phân tích yêu cầu 10

2.1 Phân tích nghiệp vụ 10

2.2 Phân tích yêu cầu về mặt chức năng 11

2.2.1 Sơ đồ UseCase tổng quát 11

2.2.2 Danh sách các tác nhân của hệ thống 11

2.2.3 Danh sách UseCase và đặc tả UseCase 12

2.3 Phân tích yêu cầu về mặt phi chức năng 15

2.3.1 Lý thuyết 15

2.3.2 Các yêu cầu phi chức năng của Tinder 16

2.4 Giao diện mẫu cho chức năng 18

2.4.1 Wiframe 18

2.4.2 Giao diện mẫu 31

3 Thiết kế hệ thống 20

3.1 Kiến trúc hệ thống 20

3.2 Thiết kế chi tiết cho các chức năng 22

3.2.1 Activity diagram 22

3.2.2 Class diagram 26

3.2.3 Sequence diagram 26

3.2.4 Database design 28

4 Triển khai hệ thống 31

5 Kết luận 31

5.1 Kết quả 32

5.2 Khó khăn 33

TÀI LIỆU THAM KHẢO Error! Bookmark not defined.

MỤC LỤC HÌNH ẢNH

Hình 1 - 1 AWS Architecture Diagram 9

Hình 2 - 1 Quy trình nghiệp vụ hẹn hò qua app Tinder 10

Hình 2 - 2 Sơ đồ usecase tổng quát 11

Hình 2 - 3 Log in 13

Hình 2 - 4 Log out 13

Hình 2 - 5 Super Like People 13

Hình 2 - 6 Unlimited Rewinds People 13

Hình 2 - 7 Boost People 14

Hình 2 - 8 Like people 14

Hình 2 - 9 Non People 14

Hình 2 - 10 Message People 14

Hình 2 - 11 View profile people 14

Hình 2 - 12 Change profiles 15

Hình 2 - 13 Upgrade account 15

Hình 2 - 14 BMAT 17

Hình 2 - 15 Đăng nhập 18

Hình 2 - 16 Tìm kiếm partner 18

Hình 2 - 17 Đăng ký 18

Hình 2 - 18 Siêu thích 18

Hình 2 - 19 Từ chối 18

Hình 2 - 20 Đồng ý 18

Hình 2 - 21 Xem lượt matches 19

Hình 2 - 22 Nhắn tin với partner 19

Hình 2 - 23 Cài đặt tài khoản 19

Hình 2 - 24 Xem thông tin partner 19

Hình 3 - 1 Architecture của Tinder (AWS 2.0) 20

Hình 3 - 2 Diagram-Activity Login 22

Hình 3 - 3 Diagram-Activity Manages matches 23

Hình 3 - 4 Diagram-Activity Manage pairings 24

Hình 3 - 5 Diagram-Activity View own profile 25

Hình 3 - 6 Class Diagram 26

Hình 3 - 7 Cấu trúc Redux trong React Native 26

Hình 3 - 8 Sequence Diagram - Match friend 27

Hình 3 - 9 Theo the app solution - các thành phần của hệ thống Tinder 28

Hình 3 - 10 Database - ERD của Tinder 29

Hình 3 - 11 Database - Json Tinder 30

Hình 4 - 1 Trang chủ 31

Hình 4 - 2 Thao tác like 31

Hình 4 - 3 Thao tác Nope 31

Hình 4 - 4 Chi tiết khám phá 31

Hình 4 - 5 Profile 31

Hình 4 - 6 Khám phá 31

Hình 4 - 7 Quét tìm đối tượng 32

Hình 4 - 8 Chi tiết tin nhắn 32

Hình 4 - 9 Tin nhắn 32

Hình 4 - 10 ReactNative - Dating app 32

MỤC LỤC BẢNG

Bảng 1 Phân công và đánh giá thành viên 36

Bảng 2 - 1 Bảng danh sách các tác nhân của hệ thống 11Bảng 2 - 2 Bảng danh sách các Usecase và đặc tả 12

1 Tổng quan về đồ án

1.1 Lý do chọn đề tài:

Đi lên song song với sự phổ biến của smartphone, các công cụ hẹn hò trực tuyến ngày càng trở nên phổ biến Nó giúp mọi người dễ dàng đến gần với nhau hơn, ở bất cứ nơi nào, thời điểm nào Cho dù mới được biết đến ở Việt Nam trong những năm gần đây, nhưng những ứng dụng hẹn hò trực tuyến đang trở nên cực kỳ thu hút với mọi người, mọi

độ tuổi từ sinh viên cho đến những người trưởng thành chín chắn Các app hẹn hò thực sự cần thiết và hữu ích khi trong thời đại mà chúng ta vùi đầu vào công việc và học tập, việc làm quen, kết nối và hẹn hò để tìm một nửa của bản thân trở nên khó khăn Để giải quyết được bất cập trên cho những người bận rộn, lần lượt các ứng dụng hẹn hò uy tín ra đời với nhiều điều độc đáo Hiểu được xu hướng của thời đại 4.0, nhóm em đã quyết định tìm hiểu và nghiên cứu ứng dụng Tinder - một trong những ứng dụng hẹn hò phổ biến nhất ở Việt Nam hiện nay Ngoài ra, sở thích của các thành viên trong nhóm là mong muốn tìm hiểu và khám phá những điều mới mẻ, độc đáo

1.2 Mục tiêu của đề tài

Có kiến thức cơ bản về các phân tích thiết kế hệ thống phần mềm nói chung và các ứng dụng hẹn hò nói riêng

Hiểu về quy trình phát triển phầm mềm, vẽ mô hình phục vụ lập trình phần mềm.Vận dụng được các kiến thức đã học để phát triền những ứng dụng hẹn hò tương

tự

1.3 Phương pháp nghiên cứu

Các phương pháp nghiên cứu được thực hiện trong đồ án

• Thực hành từ tổng thể đến chi tiết và từ bên trong lẫn bên ngoài

• So sánh và phân tích các ứng dụng khác cùng chủ đề

• Thu thập nhiều nguồn thông tin từ Internet: Các video hướng dẫn thiết kế hệ thông trên youtube, Thông tin từ page của Tinder, các sơ đồ phân tích phần mềm,… Phương pháp làm việc dựa theo Aigle Cụ thể là mô hình scrum

1.4 Cơ sở lý thuyết và những nghiên cứu liên quan

Cơ sở lý thuyết: các khái niệm liên quan về thiết kế hệ thống, các lý thuyết đã được học và các tài liệu được công bố của Tinder cũng như các đối tác Dựa trên sự tổng hợp của các tài liệu liên quan nhóm đã trình bày lại hệ thống của Tinder Và các cơ sở này hoàn toàn dựa vào trải nghiệm, tra cứu Tóm lại, cơ sở lý thuyết của nhóm đi từ x nguồn sau:

• Giáo trình Phân tích thiêt kế Hệ thống thông tin – Đại học Công nghệ Thông tin – Đại học quốc gia thành phố Hồ Chí Minh

• Giáo trình thầy Trần Đình Quế - Phân tích Hệ thống thông tin

• AWS Architecture Diagram: https://aws.amazon.com/vi/architecture

• Trải nghiệm thực tế của nhóm về ứng dụng

Những nghiên cứu liên quan: Sau khi đã xác định được cơ sở lý thuyết đưa ra được các loại mô hình mà Tinder sử dụng Từ đó tìm hiểu chuyên sâu theo mỗi mô hình

Ví dụ: sau khi đọc bài báo trên AWS thì nhóm biết được Tinder đã sử dụng database Amazon DynamoDB

• Blog về Tinder của Website: https://theappsolution.com

• Page của Tinder: https://help.tinder.com

• Blog về design tinder: http://highscalability.com/

Hình 1 - 1 AWS Architecture Diagram

2 Phân tích yêu cầu

2.1 Phân tích nghiệp vụ

Hình 2 - 1 Quy trình nghiệp vụ hẹn hò qua app Tinder

Trạng thái bắt đầu: Khi người dùng bắt đầu truy cập sử dụng ứng dụng Tinder

Bộ phận tham gia: Người dùng Tinder, hệ thống ứng dụng Tinder

Giải thích quy trình:

• Bước 1: Người dùng bật định vị cá nhân

• Bước 2: Người dùng tạo hồ sơ cá nhân

• Bước 3: Người dùng tạo thông tin tìm kiếm hẹn hò phù hợp với bản thân

• Bước 4: Người dùng bắt đầu vuốt chọn “đối tượng ghép cặp” dựa trên đề xuất của ứng dụng Tinder

• Bước 5: Nếu “đối tượng ghép cặp” phù hợp thì đến bước 6, nếu “đối tượng ghép cặp” không phù hợp thì quay lại bước 4

• Bước 6: Người dùng có thể trò chuyện với “đối tượng ghép cặp” → Kết thúc quy trình

2.2 Phân tích yêu cầu về mặt chức năng

2.2.1 Sơ đồ UseCase tổng quát

Hình 2 - 2 Sơ đồ usecase tổng quát

2.2.2 Danh sách các tác nhân của hệ thống

2.2.3 Danh sách UseCase và đặc tả UseCase

Tham khảo tên các tính năng và chức năng sử dụng của ứng dụng từ trang chủ của ứng dụng [1] Dưới đây là bảng danh sách các tính năng và có giao diện phía dưới:

1 Log in Đăng nhập tài khoản với google, facebook, phone

number

Khôi phục tài khoản (recover account)

2 Log out Đã đăng

Boost people (Premium features): Boost cho phép

người dùng trở thành một trong những hồ sơ hàng đầu trong khu vực của họ trong 30 phút Tăng cơ hội match nhiều hơn gấp 10 lần lượt xem hồ sơ khi boost

Super like people ((Premium features): Hồ sơ của

người dùng sẽ xuất hiện trong bao đựng thẻ với đường viền và dấu sao màu xanh lam sáng, làm nổi bật rằng bạn đã Siêu thích

Like people: sử dụng khi thích hồ sơ của ai đó, hoặc

tạo ra sự tương hợp nếu họ cũng thích bạn

Nope people: Bỏ qua hồ sơ của người dùng khác

Super like people

Unlimited Rewins people (Premium features): cho

phép người dùng lấy lại Lượt thích hoặc Không thích cuối cùng của mình

4 Manage

matches

Đã đăng nhập và match

Message people: nhắn tin với người dùng mà đã

Change profile: Thay đổi thông tin cá nhân của bạn

Upgrade account: Nâng cấp lên tài khoản gold để nhận được nhiều ưu đãi và các tính năng nổi bật

Bảng 2 - 2 Bảng danh sách các Usecase và đặc tả

Các giao diện tương ứng:

• Giao diện Log in và Log out

• Manage boosting top profiles

Hình 4 - 2 Log out Hình 4 - 1 Log in

Hình 4 - 4 Unlimited Rewinds People

Hình 4 - 3 Super Like People

• Manage matches

Hình 4 - 6 Like people Hình 4 - 7 Non People Hình 4 - 5 Boost People

Hình 4 - 8 Message People Hình 4 - 9 View profile people

• View own profiles

2.3 Phân tích yêu cầu về mặt phi chức năng

2.3.1 Lý thuyết

"Các yêu cầu phi chức năng là những ràng buộc và điều kiện đối với các yêu cầu chức năng của hệ thống như: ràng buộc về thời gian, ràng buộc về hiệu năng, các tiêu chuẩn được sử dụng Những yêu cầu này ảnh hưởng đến chất lượng, khả năng sử dụng của hệ thống và có tác động trực tiếp đến sự hài lòng của người sử dụng, do đó, quyết định sự thành công của hệ thống Các yêu cầu phi chức năng chung cho các hệ thống thông tin cung cấp dịch vụ công trực tuyến, gồm 7 chức năng cơ bản, đó là:

(1) Hiệu năng hoạt động: Yêu cầu về thời gian; Tài nguyên sử dụng; Công suất tối đa;

(2) Tương thích: Cùng tồn tại; Tương tác liên thông;

(3) Tính khả dụng: là mức độ sử dụng được và làm hài lòng người sử dụng như: Phù hợp với nhu cầu; Dễ dàng học cách sử dụng; Giao diện người sử dụng; Khả năng truy cập, khai thác;

Hình 4 - 10 Change profiles Hình 4 - 11 Upgrade account

(4) Tính tin cậy: Trưởng thành; Sẵn sàng; Khả năng chịu lỗi; Khả năng phục hồi; Thời gian giữa các lần xảy ra sự cố gián đoạn hoạt động của hệ thống;

(5) An toàn thông tin: Bảo mật; Toàn vẹn; Xác thực

(6) Duy trì được là Phân tích được; Hiệu chỉnh được và Khả chuyển là Mức độ hiệu suất và hiệu quả của việc dịch chuyển một hệ thống từ một nền tảng phần cứng, phần mềm, hệ điều hành từ môi trường sử dụng này sang môi trường sử dụng khác; hỗ trợ khả năng dịch chuyển từ nền tảng chạy trên Unix sang nền tảng chạy trên Windows Server một cách dễ dàng, không phát sinh thêm chi phí hoặc kinh phí không đáng kể; Thích ứng: là hỗ trợ và sử dụng các trình duyệt thông dụng hiện nay như Micrsoft Internet Explorer, Google Crome, Mozila Firefox…; Cài đặt được; Vận hành; khai thác; Khả năng thay thế được là mức độ một sản phẩm phần mềm của hệ thống có thể được thay thế bởi một sản phẩm phần mềm khác có cùng mục đích sử dụng trong cùng một môi trường

(7) Các yêu cầu phi chức năng khác: Yêu cầu phi chức năng cho công cụ tiềm kiếm, thống kê, xây dựng báo cáo; Lưu trữ: là tính đáp ứng của hệ thống đối với danh mục tiêu chuẩn, quy chuẩn kỹ thuật về ứng dụng công nghệ thông tin trong cơ quan nhà nước; Nền tảng công nghệ nền, phát triển ứng dụng là yêu cầu, định hướng lựa chọn công nghệ nền tảng dùng để xây dựng, phát triển hệ thống trong các dịch vụ công trực tuyến cấp huyện được triển khai độc lập, ưu tiên lựa chọn hệ quản trị cơ sở dữ liệu miễn phí đối với các phần mềm ứng dụng nội bộ đang có trên thị trường, ưu tiên lựa chọn các phần mềm miễn phí mã nguồn mở"

2.3.2 Các yêu cầu phi chức năng của Tinder

o Sử dụng cho 2 hệ điều hành: IOS và Android

• Hỗ trợ và sử dụng các trình duyệt thông dụng hiện nay như Microsoft Internet Explorer, Google Chrome, Mozilla Firefox

• Độ tin cậy:

o Không được làm đánh mất thông tin người dùng

o Thời gian sửa chửa và bảo trì không quá 6 tiếng

• Bộ nhớ:

o Chỉ sử dụng tối đa 256GB

o Ưu tiên lựa chọn hệ quản trị cơ sở dữ liệu miễn phí đối với các phần mềm ứng dụng nội bộ đang có trên thị trường

• Giao diện:

o Ứng dụng những kỹ thuật tâm lý và nguyên lý hành vi khác nhau để

chào đón và thu hút người dùng

o Tiếp nhận kích thích → Thực hiện hành động → Có thành quả →

• Phương pháp thiết kế: Agile

• Ngôn ngữ lập trình: React native

• Mô trình tiến trình: Scrum

c Yêu cầu từ bên ngoài:

2.4 Giao diện mẫu cho chức năng

2.4.1 Wiframe

Hình 4 - 15 Đăng ký Hình 4 - 13 Đăng nhập Hình 4 - 14 Tìm kiếm partner

Hình 4 - 18 Đồng ý Hình 4 - 17 Từ chối Hình 4 - 16 Siêu thích

Hình 4 - 22 Xem thông tin partner Hình 4 - 19 Xem lượt matches

Hình 4 - 21 Cài đặt tài khoản Hình 4 - 20 Nhắn tin với partner

2.4.2 Giao diện mẫu

Hình 2 - 3 Giao diện mẫu của Tinder

3 Thiết kế hệ thống

3.1 Kiến trúc hệ thống

Hình 3 - 1 Architecture của Tinder (AWS 2.0)

Mô tả:

• Sẽ có một nhóm các dịch vụ vi mô đằng sau Gateway, sẽ phục vụ các yêu cầu của người dùng

• Dịch vụ tạo hồ sơ sẽ được gọi khi hồ sơ người dùng được tạo

• Dịch vụ này sẽ lưu trữ thông tin người dùng trong cơ sở dữ liệu và thêm người dùng vào chỉ mục được phân đoạn địa lý tương ứng để người dùng hiển thị trong các đề xuất của những người dùng lân cận

• Chỉ mục này được Dịch vụ đề xuất truy vấn khi nhận được yêu cầu tạo đề xuất cho những người dùng khác

• Khi người dùng bắt đầu vuốt qua các đề xuất đó, Dịch vụ vuốt sẽ nhận các thao tác vuốt đó và đặt chúng vào luồng dữ liệu (ví dụ: AWS Kinesis / SQS)

• Có một nhóm công nhân đọc dữ liệu từ các luồng đó để tạo kết quả phù hợp

• Nhân viên thực hiện điều này bằng cách truy vấn bộ nhớ đệm Thích để xác định xem đó có phải là một kết quả trùng khớp hay không, trong trường hợp đó, thông báo trùng khớp được gửi đến cả những người dùng sử dụng các công nghệ như WebSockets

3.2 Thiết kế chi tiết cho các chức năng

3.2.1 Activity diagram

Hình 3 - 2 Diagram-Activity Login

Hình 3 - 3 Diagram-Activity Manages matches

Hình 3 - 4 Diagram-Activity Manage boosting top profiles

Hình 3 - 5 Diagram-Activity View own profile

3.2.2 Class diagram

Hình 3 - 6 Class Diagram

3.2.3 Sequence diagram

Sequence diagram thể hiện match với một đối tượng với react-native, redux:

Hình 3 - 7 Cấu trúc Redux trong React Native

• Redux sử dụng kiến trúc 1 chiều, tức là nó có flow như bên trên, chỉ vòng vòng

1 chiều đi từ action → reducer → store → view

• State của toàn bộ ứng dụng được lưu trong trong 1 store duy nhất là 1 Object

mô hình tree: Single source of truth

• Redux state là READ-ONLY: bạn không thể thay đổi trực tiếp state được, chỉ

có 1 cách duy nhất để update state là phải dispatch một action (là một js object)

• Những thay đổi của redux state được thực hiện bởi Pure functions (reducer)

Hình 3 - 8 Sequence Diagram - Match friend

Đầu tiên, người dùng thích một đối tượng sẽ quét qua phải (khi 2 người cùng thích

lẫn nhau hệ thống tự động thông báo match giữ 2 đối tượng)

Do đó sau khi quét sang phải, event sẽ được gửi từ giao diện của mình (view) và

dùng dispatch để thực hiện một action checkmatch() để kiểm tra 2 người có match với

nhau hay không

Mang các thông tin đến Store, mô tả mình muốn lấy thông tin match với cái store

này bằng dispatch(getMatchInfo()).Action có nhiệm vụ mô tả những gì xảy ra nhưng lại

không chỉ rõ phần state nào của response thay đổi và thay đổi như thế nào → việc này sẽ

do Reducer đảm nhiệm

Reducer nhận 2 tham số: state cũ và thông tin action được gửi lên, sau đó nó biến

đổi trả ra một state mới, không làm thay đổi state cũ

Và gửi request gọi api lấy thông tin ra từ database, tại backend sẽ xử lý data và kiểm tra match tại controller, sau đó gửi respone về reducer và reducer return 1 state mới về, rerender lại giao diện bằng subscribe (), cập nhật tình hình thay đổi ra View và gửi thông báo cho người dùng