3. Đối tƣợng nghiên cứu
1.4. Tìm hiểu về Google AppEngine
Google App Engine (GAE) là một nền tảng để phát triển và lƣu trữ các ứng dụng web bằng cách sử dụng máy chủ và cơ sở hạ tầng của Google. Các ứng dụng GAE dễ dàng đƣợc xây dựng, dễ dàng để bảo trì cũng nhƣ mở rộng quy mô về lƣu lƣợng truy cập hay dung lƣợng lƣu trữ. Với GAE, chúng ta không cần bảo trì máy chủ, đơn giản chỉ là tải ứng dụng lên, và ứng dụng sẵn sàng hoạt động. GAE hỗ trợ các ngôn ngữ Java, Python, PHP, và Go; hỗ trợ các chuẩn giao thức và công nghệ cho phát triển các ứng dụng Web. GAE đƣợc thiết kế cho khả năng mở rộng mạnh
42 mẽ và hiệu suất cao. Cơ sở hạ tầng của Google cung c ấp hiệu suất tốt ngay trong trƣờng hợp ứng dụng đòi hỏi hoạt động với lƣợng dữ liệu lớn. Với chi phí xây dựng và triển khai ứng dụng ban đầu gần nhƣ bằng 0, khách hàng dễ dàng xây dựng các ứng dụng theo yêu cầu. Khi ứng dụng đã thu đƣợc lợi nhuận và vƣợt qua mức sử dụng thông thƣờng thì khách hàng chỉ phải trả kho ản phí tài nguyên mà mình đã sử dụng. Cụ thể hơn, mời độc giả xem tài liệu [5].
Đặc điểm:
- Lƣu trữ bền vững với các thao tác truy vấn, sắp xếp, giao dịch.
- Tự động mở rộng và cân bằng tải.
- Bất đồng bộ các nhiệm vụ trên hàng đợi để thực hiện các công việc ngoài phạm vi yêu cầu.
- Lập lịch cho các nhiệm vụ để kích hoạt các sự kiện tại thời điểm định trƣớc, hoặc sự kiện có tính chu kỳ.
- Tích hợp các dịch vụ đám mây và các API khác của Google.
1.4.2. Mô hình kiến trúc ho ạt độ ng G AE
43 - Static File Servers: máy chủ tĩnh
- Datastore: kho dữ liệu - Memcache: vùng nhớ đệm
- URL Fetch: dịch vụ giao tiếp với web - Mail: dịch vụ thƣ điện tử
- Image: dịch vụ thao tác ảnh
Khi có một yêu cầu từ thiết bị (điện tho ại, máy tính) đƣợc gửi tới GAE thông qua Front ends, ứng dụng chủ sẽ điều khiển và lập lịch cho tất cả các yêu cầu. Nếu yêu cầu truy vấn đến tệp tin tĩnh, yêu cầu đó sẽ đƣợc chuyển hƣớng đến máy chủ tĩnh. Ngƣợc lại, yêu cầu sẽ đƣợc gửi đến ứng dụng trên GAE. Ứng dụng có thể truy cập tới kho dữ liệu, dịch vụ lƣu trữ bộ nhớ, dịch vụ thao tác ảnh.
1.4.3. Các thành phần và chức năng G AE
1.4.3.1. Môi trƣờng thực thi (runtime environment)
GAE cung c ấp hai môi trƣờng thực thi tốt cho các ứng Java và Python. Môi trƣờng phụ thuộc vào ngôn ngữ và các công nghệ liên quan khi phát triển ứng dụng.
Môi trƣờng Java: GAE sẽ chạy ứng dụng web Java bằng cách sử dụng một JVM Java 7 trong một môi trƣờng “sandbox” an toàn. App Engine gọi lớp servlet của ứng dụng để xử lý các yêu c ầu và chuẩn bị phản ứng trong môi trƣờng này.
Môi trƣờng Python: App Engine thực thi ứng dụng Python bằng cách sử dụng một thông dịch Python đƣợc nạp sẵn trong môi trƣờng “sandbox ” an toàn. Ứng dụng nhận đƣợc yêu c ầu web, thực hiện công việc và gửi phản hồi bằng cách tƣơng tác với môi trƣờng này.
Cả hai môi trƣờng Java và Python đều sử dụng chung một mô hình: một yêu cầu gửi đến ứng dụng trên server, ứng dụng đƣợc kích ho ạt (nếu cần thiết), gọi bộ phận xử lý yêu cầu và trả về kết quả cho client.
1.4.3.2. Các file server tĩnh (static file servers)
Đây là các tài nguyên tĩnh, không thay đổi trong suốt quá trình hoạt động của web site, ví dụ nhƣ các hình ảnh và các file CSS hỗ trợ hiển thị trang web, các đoạn
44 mã JavaScript chạy trên trình duyệt, các tệp tin HTML tĩnh, GAE cung c ấp một máy chủ tách biệt chuyên làm nhiệm vụ trao đổi các tệp tin tĩnh này.
1.4.3.3. Kho dữ liệu (datastore)
Kho dữ liệu App Engine là một kho dữ liệu NoSQL, cung c ấp khả năng mở rộng lƣu trữ cho các ứng dụng web. Kho dữ liệu có các đối tƣợng gọi là thực thể, mỗi thực thể có một hoặc nhiều thuộc tính, hỗ trợ các loại dữ liệu nhƣ số nguyên, chuỗi kí tự. Mỗi thực thể đƣợc xác định bởi một định danh, trong đó phân loại các thực thể với mục đích truy vấn. Kho dữ liệu có thể thực thi nhiều hoạt động trong một phiên dao dịch duy nhất. Một giao dịch không thể thành công khi một hoạt động nào đó không thành công, các giao dịch lúc này tự động đƣợc cuộn lại. Điều này hữu ích cho các ứng dụng web mà nhiều ngƣời có thể cùng truy cập cùng một dữ liệu tại cùng một thời điểm.
1.4.3.4. Các dịch vụ (services)
Dịch vụ là các mối quan hệ giữa kho dữ liệu và môi trƣờng thực thi. GAE bao gồm các dịch vụ hữu ích cho các ứng dụng web. Các dịch vụ bao gồm: dịch vụ Memcache để lƣu trữ theo cặp từ khóa - giá trị, dịch vụ URL Fetch giúp truy cập vào các tài nguyên web khác, dịch vụ Mail giúp thực hiện việc trao đổi mail.
1.4.3.5. Tài khoản Google (google accounts)
Các chức năng của GAE đã đƣợc tích hợp trong các tài khoản của Google nhƣ Google Mail, Google Docs và Google Calendar. Chúng ta có thể sử dụng các tài kho ản trên Google cho các ứng dụng đó. Nếu ngƣời dùng đã có tài khoản trên Google, họ có thể đăng nhập để sử dụng ứng dụng với các tài khoản đó mà không cần tạo tài kho ản riêng trong từng ứng dụng. Điều này là không bắt buộc, chúng ta luôn có thể xây dựng hệ thống tài khoản riêng c ủa mình.
1.4.3.6. Các công c ụ lập trình (programming tools)
Google cung cấp một số công c ụ miễn phí trong việc phát triển ứng dụng GAE bằng ngôn ngữ Java và P ython. Chúng ta có thể tải các công cụ này cho ngôn ngữ tƣơng ứng với hệ điều hành của chúng ta từ trang web của Google.
45
1.4.4. Ƣu điểm, nhƣợc điểm của GAE
1.4.4.1. Ƣu điểm của GAE GAE có nhiều ƣu điểm:
- Không tốn chi phí đầu tƣ máy chủ.
- Giải quyết vấn đề mở rộng dễ dàng hơn.
- Miến phí trong một mức độ nào đó: miễn phí 1GB dữ liệu ban đầu, trả phí $0.026 mỗi GB thêm một tháng.
1.4.4.2. Nhƣợc điểm của GAE
Bên cạnh những ƣu điểm bên trên, GAE có những nhƣợc điểm cần phải cân nhắc, xem xét kĩ trƣớc khi sử dụng:
- Không hỗ trợ đa luồng. Các ứng dụng có thể chạy trên cùng một máy chủ, để ngăn chặn các ứng dụng can thiệp vào nhau, mỗi ứng dụng đƣợc chạy trong một môi trƣờng hạn chế gọi là “sandbox”.
- Mỗi yêu cầu bị giới hạn hoàn thành trong vòng 30 giây.
- Phụ thuộc vào Google App Engine, khó có thể tách ra thành một ứng dụng độc lập. Tính bảo mật không cao.
- Hỗ trợ ít ngôn ngữ(Java, Python, Go, PHP).
Với những nhƣợc điểm nhƣ trên, trong việc hoàn thành luận văn này, các nhƣợc điểm hầu hết không ảnh hƣởng. Với những ƣu điểm vƣợt trội, tôi quyết định sử dụng GAE.
46
CHƢƠNG 2: PHÂN TÍCH THIẾT KẾ HỆ THỐNG
Trong Chƣơng 2 tôi sẽ giới thiệu mô hình bài toán và quá trình phân tích thiết kế hệ thống để giải quyết bài toán đã đƣa ra trong Chƣơng 1.
2.1. Mô tả bài toán 2.1.1. Mô hình đề xuất 2.1.1. Mô hình đề xuất
Để giải quyết đƣợc bài toán đã đặt ra, tác giả đề xuất mô hình nhƣ sau:
Hình 2.1. Kiến trúc hệ thống Database
Server
47 Hệ thống bao gồm 4 thành phần nhƣ sau:
- Server: là nơi cung cấp các dịch vụ, xử lý và trả lại các thông tin cho các client.
- Client-A: đƣợc viết trên nền tảng Android, bao gồm các tính năng liên quan đến chiếc bút Spen nhƣ tạo, xóa các bài giảng của ngƣời dùng tƣơng ứng. Các bài giảng bao gồm các nét vẽ đƣợc lƣu trong tập tin JSON, âm thanh đƣợc lƣu trong tệp tin Audio, sau đó đƣợc gửi lên và đƣợc xử lý trên Server. Ngoài ra, Client-A có thể xem lại đƣợc các bài giảng đã tạo ra. Client-A thích hợp cho các thầy cô giáo tạo ra các bài giảng gửi lên Server.
- Client-B: đƣợc viết trên nhiều nền tảng, có thể truy cập đến Server để tải về các bài giảng đã đƣợc tao ra tƣơng ứng từ ngƣời dùng, sau đó có thể xem đƣợc các bài giảng. Điểm khác biệt duy nhất của hai lo ại Client chính là Client-B không có tính năng tạo các bài giảng. Client-B thích hợp cho học sinh, sinh viên để xem các bài giảng trên Server.
- Data base: phần này lƣu trữ các bài giảng đã đƣợc tạo theo từng ngƣời dùng. Server thao tác với Data base để thêm hoặc xóa một bài giảng nào đó.
2.1.2. Mục tiêu của hệ thống
- Cho phép ngƣời dùng có thể tải và cài đặt vào nhiều thiết bị, trên nhiều nền tảng khác nhau để có thể xem đƣợc các bài giảng.
- Cho phép ngƣời dùng sử dụng các thiết bị Android hỗ trợ bút Spen để có thêm chức năng tạo các bài giảng.
- Cho phép ngƣời dùng tạo tài khoản, đăng nhập để sử dụng hệ thống.
- Đối với ngƣời dùng trên thiết bị Android, có thể tạo ra các bài giảng một cách sinh động, trực quan bằng cách thao tác với bút Spen trên màn hình nhƣ thao tác với phấn trên bảng. Hiện nay bút Spen hoạt động rất chính xác, hiệu năng cao, mƣợt mà. Ngoài ra có thể xem lại các bài giảng đã tạo ra. Hơn nữa các bài giảng có dung lƣợng nhỏ, rất thích hợp để truyền tải cũng nhƣ lƣu trữ, tiết kiệm chi phí cho ngƣời dùng cũng nhƣ nhà cung cấp.
48 - Đối với ngƣời dùng sử dụng ứng dụng đa nền tảng, có thể tải về các bài giảng trên Server để xem lại. Dung lƣợng tải về nhỏ, giúp tiết kiệm chi phí dữ liệu. Bài giảng có thể tải về trong thời gian ngắn, giúp tiết kiệm đƣợc thời gian chờ đợi.
- Trong quá trình t ạo bài giảng, hỗ trợ các tính năng nhƣ t ẩy xóa, undo, redo. Ngoài ra có thể cài đ ặt kích thƣớc nét chữ, màu sắc, hoặc có thể tắt âm thanh.
- Hệ thống đ ảm bảo hoạt động ổn định, chính xác.
- Hệ thống có giao diện đơn giản, thân thiện, dễ sử dụng. - Hệ thống mang tính linh hoạt cao, dễ dàng mở rộng. - Hệ thống dễ dàng cài đặt, giảm tối đa chi phí vận hành.
2.1.3. Yêu cầu hệ thống
2.1.3.1. Yêu cầu chức năng - Tạo tài kho ản mới.
- Đăng nhập để sử dụng ứng dụng. - Thoát đăng nhập.
- Đối với Client-A, có thể tạo bài giảng mới bao gồm các thao tác vẽ, tẩy xóa, undo, redo. Có thể xóa bài giảng đã tạo trên Server.
- Xem danh sách các bài giảng. - Tải về các bài giảng.
- Xem từng bài giảng. 2.1.3.2.Yêu c ầu phi chức năng
- Hệ thống hoạt động ổn định, chính xác.
- Có thể tạo ra các bài giảng khi không có kết nối internet, bài giảng sẽ đƣợc lƣu tạm trong thiết bị.
- Có thể xem lại các bài giảng đã tải về máy khi không có kết nối internet. - Các nét vẽ đồng bộ với giọng nói đƣợc ghi âm lại.
2.1.3.3.Yêu c ầu về giao diện
- Hệ thống có giao diện đơn giản, thân thiện, dễ sử dụng cho tất các các đối tƣợng ngƣời dùng.
49 - Phù hợp với kích thƣớc màn hình của điện thoại cũng nhƣ máy tính bảng. 2.1.3.4.Yêu c ầu về môi trƣờng
- Client-A hoạt động tốt trên thiết bị Android hỗ trợ bút Spen. - Client-B hoạt động tốt trên thiết bị Android, iOS, trình duyệt Web.
2.1.4. Sơ đồ hoạt động hệ thống
Hình 2.2. Sơ đồ hoạt động của hệ thống Server Client-A Creater Client-B Viewer Database Audio Rec Speaker Speaker Input Output Monitor Pen Monitor Output Monitor
50
2.2. Phân tích hệ thống 2.2.1. Biểu đồ Use case 2.2.1. Biểu đồ Use case
2.2.1.1.Biều đồ Use case tổng quan
Hình 2.3. Biểu đồ Use case tổng quan
Hình 2.3 trình bày biểu đồ Use case tổng quan c ủa hệ thống. Tác nhân của hệ thống ở đây là ngƣời dùng. Hệ thố ng có các chức năng chính nhƣ đăng ký, đăng nhập, quản lý tài kho ản, quản lý các bài giảng.
2.2.1.2.Phân rã biểu đồ use case
51
Hình 2.3. Phân rã mức 2 use case quản lý tài khoản
52
2.2.2. Đặc tả Use case
2.2.2.1.Use case quản lý đăng nhập Tên Use case: quản lý đăng nhập.
Mô tả: quản lý đăng nhập bao gồm các công việc nhƣ đăng nhập, thay đổi mật khẩu, đăng xuất.
Tác nhân: ngƣời dùng.
Điều kiện tiên quyết: đã tồn tại tài khoản đăng nhập đối với công việc đăng nhập, thay đổi mặt khẩu; đã đăng nhập đối với công việc đăng xuất.
Kịch bản chính:
- Ngƣời dùng điền đầy đủ thông tin email và password để đăng nhập từ màn hình chính (C1).
- Sau khi đăng nhập thành công ngƣời dùng có thể thay đổi mật khẩu đã đăng nhập (C2).
- Ngƣời dùng có thể đăng xuất khi thoát ứng dụng, hoặc chỉ thoát ứng dụng để không phải đăng nhập lại trong lần tới (C3).
Kịch bản con:
- C1: Sau khi ngƣời dùng điền đầy đủ thông tin đăng nhập, hệ thống sẽ gửi thông tin đến máy chủ và kiểm tra thông tin đăng nhập có đúng không. Nếu thông tin đăng nhập là đúng, ứng dụng sẽ đƣa ngƣời dùng đến màn hình chính, ngƣợc lại, nếu sai ứng dụng sẽ thông báo để ngƣời dùng kiểm tra lại hoặc ngƣời dùng cần phải tạo tài khoản mới.
- C2: Ngƣời dùng có thể thay đổi mật khẩu sau khi đăng nhập. Ngƣời dùng cần điền đầy đủ thông tin mật khẩu cũ, mật khẩu mới, xác nhận mật khẩu mới để có thể thay đổi mật khẩu. Hệ thống sẽ kiểm tra nhƣng thông tin đó, nếu chính xác sẽ thực hiện thay đổi mật khẩu.
- C3: Ngƣời dùng đăng xuất khỏi hệ thố ng ho ặc giữ nguyên trạng thái đăng nhập cho lần mở ứng dụng tiếp theo.
53 2.2.2.2.Use case quản lý bài giảng
Tên Use case: quản lý bài giảng.
Mô tả: quản lý bài giảng bao gồm các công việc nhƣ xem danh sách các bài giảng, tạo một bài giảng mới, xóa bài giảng đã tạo, xem lại các bài giảng đã tạo, xem tất cả bài giảng trên hệ thống.
Tác nhân: ngƣời dùng.
Điều kiện tiên quyết: đã đăng nhập thành công. Kịch bản chính:
- Ngƣời dùng xem danh sách các bài giảng (C1).
- Ngƣời dùng đặt tựa đề cho bài giảng mới và bắt đầu tạo bài giảng mới (C2). - Ngƣời dùng xem lại bài giảng mình đã tạo (C3).
- Ngƣời dùng xóa bài giảng mình đã tạo (C4).
- Ngƣời dùng xem bài giảng của ngƣời khác tạo (C5). Kịch bản con:
- C1: Ngƣời dùng có thể xem danh sách các bài giảng có trên hệ thống, từ đó có thể xem nội dung một bài giảng nào đó.
- C2: Ngƣời dùng bắt đầu thao tác viết tay trên màn hình, kết hợp với giọng nói sẽ đƣợc ghi lại. Ngƣời dùng có các thao tác nhƣ xóa các nét vẽ trên màn hình, undo, redo, cài đặt kích thƣớc nét chữ, màu sắc nét chữ. Ngƣời dùng có thể tùy chọn có sử dụng tính năng ghi âm hay không. Các thao tác này chỉ dành cho ngƣời dùng sử dụng Client-A trên thiết bị Android hỗ trợ Spen.
- C3: Ngƣời dùng có thể chọn một bài giảng trong danh sách các bài giảng của mình để xem lại bài giảng tƣơng ứng.
- C4: Ngƣời dùng có thể xóa bài giảng mình đã tạo trƣớc đó, hệ thống sẽ kiểm tra, nếu ngƣời dùng là tác gi ả của bài giảng đó sẽ tiến hành xóa khỏi cơ sở dữ liệu trên hệ thống.
- C5: Ngƣời dùng có thể xem tất cả các bài giảng của ngƣời khác tạo. Các bài