ĐỒ ÁN CÔNG NGHỆ THÔNG TIN ĐỀ TÀI WEBSITE BÁN ĐỒ TRANG SỨC

- Loại sản phẩm được phân theo nhóm, chủng loại- Thông tin danh sách sản phẩm với nhiều cách thể hiện khác - Sắp xếp sản phẩm theo các tiêu chí như: giá bán, thời gian bảo hành hoặc theo

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

KHOA HỆ THỐNG THÔNG TIN



ĐỀ CƯƠNG MÔN HỌC

ĐỒ ÁN CÔNG NGHỆ THÔNG TIN

ĐỀ TÀI: WEBSITE BÁN ĐỒ TRANG SỨC

GVHD: Nguyễn Đình Loan Phương Nhóm thực hiện:

Phạm Việt Hà: 09520504 Hoàng Thị Kim Oanh: 09520600

Tp Hồ Chí Minh, ngày 09 tháng 04 năm 2013.

CHƯƠNG I: TỔNG QUAN

1 Thông tin chung về đề tài:

Tên đề tài: Website bán đồ trang sức

GVHD:

Nguyễn Đình Loan PhươngNhóm thực hiện:

Phạm Việt Hà: 09520504Hoàng Thị Kim Oanh: 09520600

2 Đặt vấn đề:

Dù việc đưa ứng dụng thương mại điện tử vào Việt Nam chưa lâu nhưng hiệntại thương mại điện tử ở nước ta đang được ứng dụng nhiều và thúc đẩy phát triển mạnh mẽ

Ngoài những ứng dụng rộng rãi như quảng cáo, rao vặt, buôn bán mặt hàng trên các trang web chuyên dụng, các mạng xã hội, một loại hình kinh doanh phổ biến trên mạng là xây dựng website riêng và bày bán hàng cho từng doanh nghiệp, cửa

hàng…

Việc có web riêng cho doanh nghiệp kinh doanh, giới thiệu sản phẩm, buôn bán online, quản lí việc kinh doanh là rất tiện lợi Giúp doanh nghiệp tìm được nhiều nguồn khách hàng tiềm năng mà ko phải dày công tìm kiếm, chi phí quảng cáo rẻ, chi phí kinh doanh thấp, dễ quản lí, thống kê…

Web kinh doanh online cho từng cửa hàng, doanh nghiệp giúp khách hàng tìm kiếm sản phẩm dễ dàng, dễ dàng đặt mua cũng như thanh toán khi cần thiết

3 Mục đích:

Xây dựng ứng dụng website quản lý việc mua bán sản phẩm của cửa hàng

- Mục tiêu:

Xây dựng ứng dụng quản lý việc lưu trữ hồ sơ thông tin khách hàng vào cơ sở

dữ liệu, quản lý sản phẩm, báo cáo thống kê, in hóa đơn, in báo cáo thu phí…

4 Hiện trạng:

Trong giới hạn về thời gian và nhân lực, để thực hiện website còn gặp rất nhiều khó khắn Công nghệ và kỹ thuật ngày càng cao, đòi hỏi tính nhanh nhạy và thích ứng nhanh Bên cạnh đó, sinh viên còn hạn chế về mặt kiến thức …

CHƯƠNG II: LÝ THUYẾT CƠ SỞ ĐỂ GIẢI QUYẾT VẤN ĐỀ

1 Giải pháp giải quyết vấn đề:

Để đáp ứng được những khó khăn khi thực hiện, nhóm đã tiến hành khảo sát rất nhiều các website mua bán, từ đó rút ra nhứng điểm mạnh và hạn chế Ngoài ra nhóm còn xem và học hỏi cách thiết kế từ các trang web có mã nguồn mở sau khi tiến hành khảo sát, nhóm đã xác định được yêu cầu cho đề tài Bước tiếp theo nhóm

sẽ tìm hiểu về các công nghệ và kỹ thuật để hỗ trợ cho việc hiện thực hóa các yêu cầu đề ra Sau giai đoạn khảo sát, tìm hiểu, nhóm tiến hành thiết kế, cài đặt và kiểm thử dự án

- Tìm hiểu về đề tài, tìm các tài liệu liên quan

- Điều tra, thí nghiệm và thiết kế dữ liệu

- Bước đầu hoàn thành layout chính cho trang website bán đồ trang sức

- Lập đề cương, viết báo cáo chương 1

o Tháng thứ hai:

- Hoàn thành việc xữ lý và phân tích thiết kế cơ sở dữ liệu

- Thực hiện code các module

- Viết báo cáo chương 2, 3

o Tháng Thứ ba:

- Tiếp tục thực hiện và chỉnh sửa các module

- Viết báo cáo chương 4, 5

o Tháng thứ tư:

- Hoàn chỉnh website

- Cài đặt và kiểm thử

- Viết báo cáo và hoàn chỉnh đồ án

 Các module trong web nhóm sẽ nghiên cứu thực hiện bao gồm:

:

Các module trong việc xuất bản nội dung, giao diện tương tác người dùng

1 Thiết kế giao diện Bản thiết kế giao diện phù hợp với mặt

hàng, thương hiệu bạn định kinh doanh

2 Trang chủ Thể hiện tổng quan nội dung của toàn bộ

- Loại sản phẩm được phân theo nhóm, chủng loại

- Thông tin danh sách sản phẩm với nhiều cách thể hiện khác

- Sắp xếp sản phẩm theo các tiêu chí như: giá bán, thời gian bảo hành hoặc theotên

4 Giỏ hàng, xem hàng Module thể hiện thông tin một sản phẩm:

- Xem chi tiết mặt hàng

- Thông tin liên hệ của công ty

- Form liên hệ trực tiếp trên website

- Bảng đồ dẫn đường tới cửa hàng, công ty bạn

8 Tiện ích Các tiện ích phục vụ trong việc kinh doanh

và người dùng:

- Hỗ trợ trực tuyến

- Tin tức về tỷ giá và giá cả quy đổi

- Liên kết đối tác và bạn bè cùng ngành nghề

đặc thù riêng của từng sản phẩm

Module trong hệ thống quản trị nội dung CMS

1 Module quản lý nhóm Chia hệ thống quản lý CMS theo các

- Là khách hàng

- Là người quản lý hệ thống

3 Module quản lý chủ đề Quản lý danh sách chủ đề như:

- Chủ đề về sản phẩm và loại sản phẩm

- Chủ đề về tin tức và chính sách bánhàng

5 Module quản lý sản phẩm Module quản lý sản phẩm:

- Danh sách sản phẩm

- Sản phẩm tiêu biểu

- Sản phẩm bán chạy

6 Module quản lý đơn hàng Quản lý đơn hàng

- Đơn hàng mới tới

- Đơn hàng đang chờ duyệt và thanh toán

- Đơn hàng đã thanh toán

7 Module thống kê và báo cáo

tình hình bán hàng

Thống kê việc bán hàng

- Thông kê bán hàng theo ngày

- Thống kê theo tuần

- Thông kê theo tháng

- Xuất báo cáo theo thời gian

8 Module quản lý thông tin liên

hệ Quản lý thông tin liên hệ, thông tin phản hồi từ người dùng

4 Phân tích đề tài:

Website bán đồ trang sức muốn mở rộng kinh doanh trên mạng Hiện tại Website bán đồ trang sức muốn xây dựng một website để giới thiệu chung về công ty, giới thiệu các sản phẩm có bày bán tại website và cho phép khách hàng đặt mua và thanhtoán qua mạng

o Thay đổi thông tin cá nhân

o Xem nhật kí giao dịch, lịch sử hoạt động

o Xem sản phẩm

o Chọn sản phẩm muốn mua

o Xem giỏ hàng

o Xin trợ giúp, giới thiệu về sản phẩm khi cần

 Đối với công ty:

- Admin là người quản lí tất cả, phân quyền cho từng accout, sửa chữa, nâng cấp và bảo trì website

- Manager là người quản lí bán hàng cho website nhưng không có quyền chỉnh sửa website, thay đổi cấu trúc cơ sở dữ liệu…

5 Phân tích yêu cầu:

a Yêu cầu chức năng

- Cho phép thăm quan website không cần đăng nhập

- Cung cấp thông tin tài khoản

- Cho phép người dùng thực hiện các giao dịch: chuyển khoản, đặt hàng

- Cho phép khách hàng cập nhập các thông tin cá nhân, thay đổi mật khẩu

- Cho phép khách hàng xem lại giỏ hàng

- Đảm bảo tính bảo mật cho các tài khoản khách hàng và cho các cuộc giao dịch

- Admin có quyền quản lý sản phẩm, thông tin sản phẩm, thông tin người dùng, quảng cáo, tin tức và giao diện của website

b Yêu cầu phi chức năng:

- Hệ thống của cửa hàng được truyển khai theo dạng website có tính bảo mật cao

- Giao diện gần gũi, đơn giải và thân thiện với người sử dụng

- Tuân thủ theo luật “Ngân hàng và các tổ chức tín dụng”

CHƯƠNG III PHÂN TÍCH, THIẾT KẾ, THỰC HIỆN HỆ THỐNG

A PHÂN TÍCH WEBSITE VỚI UML

1 Sơ đồ Use case (Use case Diagram):

Hình 1: Sơ đồ Use case

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

ST

T

Tác nhân hệ thống Ý nghĩa

1 Khách hàng Là người tác động vào hệ thống, sử dụng các chức năng

như thay đổi thông tin cá nhân, thanh toán, đặt mua sản phẩm…

2 Admin Là người tác động vào hệ thống, có quyền quản lý hệ

thống

3 Danh sách các Use case nghiệp vụ:

1. Đăng nhập Khách hàng, admin thực hiện đăng nhập vào hệ

thống

2. Quản lý giỏ hàng Khách hàng (người mua) đặt mua các sản phẩm

được đăng trên hệ thống

3. Thanh toán Khách hàng chọn hình thức thanh toán phù hợp

4. Quản lý thông tin cá nhân Khách hang và admin quản lý các thông tin về

tài khoản của mình

5. Quản lý sản phẩm Admin quản lý các sản phẩm trên hệ thống

6. Quản lý đơn hàng Admin quản lý đơn hàng của khách hàng đã đặt

7. Quản lý thông tin khách

hàng Admin quản lý các tài khoản khách hàng

8. Liên hệ Admin lập các báo cáo thống kê

9. Tin tức Khách có thể ghé thăm website mà không cần

đăng nhập

10. Đăng ký Khách hàng đăng ký tài khoản mới

11. Tìm kiếm thông tin SP Người dùng có thể tìm sản phẩm theo từ khóa

hoặc mức giá sản phẩm

12. Quản lý liên hệ Admin thay đổi thoogn tin liên hệ

13. Quản lý tin tức Admin quản lý tin tức

14. Xem sản phẩm Khách hàng xem được sản phẩm trên website

15. Quản lý phân quyền Admin quản lý quyền

Use case này bắt đầu khi người dùng muốn đăng nhập vào hệ thống.

- Hệ thống yêu cầu người dùng nhập tên đăng nhập và mật khẩu

- Người dùng nhập tên đăng nhập và mật khẩu

- Hệ thống kiểm tra thông tin đăng nhập

- Hệ thống cho phép người dùng đăng nhập vào hệ thống và lưu vào lịch sửcủa tài khoản

 Dòng sự kiện khác:

- Tên đăng nhập hoặc mật khẩu không đúng:

Nếu trong dòng sự kiện chính, người dùng nhập sai tên đăng nhập hoặc mật khẩu thì hệ thống sẽ thông báo lỗi Người dùng có thể thực hiện lại thao tác đăng nhập hoặc hủy bỏ thao tác, use case kết thúc

 Trạng thái hệ thống sau khi thực hiện use case :

Nếu use case thành công thì người dùng đăng nhập vào hệ thống và sử dụng cácquyền tương ứng với phân quyền của mình Ngược lại, trạng thái hệ thống thayđổi

 Điều kiện tiên quyết:

yêu cầu nhập username, pasword

Đăng nhập vào hệ thống

[ Không đúng ]

[Đúng]

[Yêu cầu đăng nhập]

Tiếp nhận yêu cầu dăng nhập

4.2 Use case “Quản lý thông tin cá nhân”:

 Xem thông tin tài khoản:

- Hệ thống hiển thị các thông tin

đủ thông tin hoặc hủy bỏ thao tác đang thực hiện, lúc này use case kếtthúc.

- Sơ đồ Activity “Quản lý thông tin cá nhân”

Tiếp nhận yêu cầu xem thông tin cá nhân

Hiển thị thông tin cá nhân chọn thông tin cần xem [Yêu cầu quản lý thông tin có nhân]

 Điều kiện tiên quyết:

Người dùng phải đăng nhập vào hệ thống trước khi thực hiện chức năng này

 Trạng thái hệ thống sau khi thực hiện use case:

Nếu use case thành công, thông tin cá nhân vừa thay đổi được cập nhập lại vào

hệ thống Ngược lại, trạng thái của hệ thống không thay đổi

 Điểm mở rộng:

Không có

4.3 Use case “Quản lý sản phẩm”:

- Hệ thống hiển thị thông tin sản phẩm.

- Admin chọn sản phẩm và một trong các luồng sau được thực hiện

o Nếu admin chọn “Thêm sản phẩm” Luồng phụ “Thêm sản phẩm” được thực hiện

o Nếu admin chọn “Thay đổi thông tin sản phẩm” Luồng phụ “Thay đổithông tin sản phẩm” được thực hiện

o Nếu admin chọn “Xóa sản phẩm” Luồng phụ “Xóa sản phẩm” được thực hiện

 Thêm sản phẩm:

- Hệ thống yêu cầu admin nhập thông tin sản phẩm

Lưu ý: Admin cần nhập đầy đủ các thông tin

- Khi điền đầy đủ thông tin của sản phẩm, admin chọn nút Thêm

- Hệ thống kiểm tra thông tin đã được nhập

- Hệ thống lưu sản phẩm vào cơ sở dữ liệu và tự động phát sinh mã sản phẩm của sản phẩm vừa thêm

- Hệ thống hiển thị danh sách sản phẩm đã đăng của người dùng

- Sơ đồ activity “Thêm sản phẩm”

Tiếp nhận yêu cầu thêm sản phẩm

 Thay đổi thông tin sản phẩm:

- Admin chọn sản phẩm muốn thay đổi thông tin

- Hệ thống tìm kiếm và hiển thị thông tin của sản phẩm mà Admin yêu cầu

- Admin thay đổi thông tin của sản phẩm này Bao gồm các thông tin ở luồng phụ “Thêm sản phẩm”

- Sau khi thay đổi các thông tin cần thiết Admin chọn nút “Sửa”

- Hệ thống kiểm tra thông tin được thay đổi

- Hệ thống cập nhập thông tin lại vào cơ sở dữ liệu và xuất ra màn hình

- Sơ đồ Activity “Sửa sản phẩm”

Tiếp nhận yêu cầu sửa thông tin sản phẩm

Cập nhật thông tin sản phẩm

[ Không hợp lệ]

[ Hợp lệ]

[Yêu cầu sửa thông tin sản phẩm]

Yêu cầu chọn thông tin cần sửa

Yêu cầu nhập mã hoặc tên sản phẩm

Hiển thị thông tin sản phẩm

 Xóa sản phẩm:

- Admin chọn sản phẩm cần xóa

- Hệ thống tìm kiếm và hiển thị thông tin của sản phẩm mà Admin yêu cầu

- Admin chọn nút “Xóa”

- Hệ thống kiểm tra thông tin sản phẩm

- Hệ thống cập nhập lại trạng thái của sản phẩm vào cơ sở dữ liệu

- Sơ đồ Activity “Xóa sản phẩm”

Tiếp nhận yêu cầu xóa sản phẩm

Cập nhật thông tin sản phẩm

[ Không xóa]

[ Xóa]

[Yêu cầu xóa sản phẩm]

Yêu cầu nhập mã hoặc tên sản phẩm

Hiển thị thông tin sản phẩm

 Dòng sự kiện khác:

- Thông tin của sản phẩm không đầy đủ: Nếu thông tin được Admin nhập vào luồng phụ “Thêm sản phẩm” và “Thay đổi thông tin sản phẩm” không đầy đủ thì hệ thống sẽ hiển thị thông báo lỗi: các thông tin chưa đầy đủ và yêu cầu bổ sung đầy đủ các thông tin Admin có thể bổ sung đầy đủ các thông tin hoặc hủy bỏ thao tác, use case kết thúc

- Thông tin về sản phẩm không hợp lệ: Nếu thông tin được Admin nhập vào luồng phụ “Thêm sản phẩm” và “Thay đổi thông tin sản phẩm” không hợp lệ thì hệ thống sẽ hiển thị thông báo lỗi: các thông tin không hợp lệ và yêu cầu Admin sửa lại các thông tin chưa hợp lệ Admin có thể chỉnh sửa các thông tin chưa hợp lệ hoặc hủy thao tác, use case kết thúc

- Sản phẩm hiện đang giao dịch:Nếu sản phẩm mà Admin muốn xóa hiện đang trong trạng thái giao dịch thì hiện sẽ hiện thông báo: sản phẩm hiện đang trong trạng thái giao dịch Use case kết thúc

 Các yêu cầu đặc biệt:

Chỉ admin mới có thể thực hiện được use case này

 Điều kiện tiên quyết:

Admin phải đăng nhập vào hệ thống trước khi use case có thể bắt đầu

 Trạng thái hệ thống sau khi thực hiện use case:

Nếu use case thành công thì thông tin của sản phẩm sẽ được cập nhập vào hệ thống Ngược lại, trạng thái của hệ thống không thay đổi

- Người dùng nhập các thông tin cần thiết

- Hệ thống kiểm tra các thông tin người dùng nhập vào

- Hệ thống lưu thông tin giao dịch vào cơ sở dữ liệu

 Dòng sự kiện khác:

- Thông tin tài khoản không đầy đủ: Nếu người dùng nhập thiếu (hoặc sai) thông tin tài khoản thì hệ thống hiển thị thông báo: Không được bỏ sót các thông tin Người dùng có thể nhập lại thông tin chuyển khoản hoặc hủy thao tác, use case kết thúc

- Mật khẩu giao dịch không chính xác: Nếu mật khẩu giao dịch không chính xác thì hệ thống sẽ hiển thị thông báo: Mật khẩu giao dịch không chính xác và yêu người dùng nhập lại mật khẩu Người dùng có thể nhập lại mật khẩu hoặc hủy bỏ thao tác, use case kết thúc.

 Điều kiện tiên quyết:

Người dùng phải đăng nhập vào hệ thống trước khi thực hiện use case

 Trạng thái hệ thống sau khi thực hiện use case:

Nếu use case thành công thì hệ thống sẽ cập nhập lại số dư của 2 tài khoản đã thực hiện giao dịch

 Điểm mở rộng:

Không có

 Sơ đồ Activity “thanh toán”

4.5 Đặc tả Use case “Quản lý giỏ hàng”:

- Người dùng nhập các thông tin cần thiết

- Hệ thống kiểm tra các thông tin người dùng nhập vào

- Hệ thống lưu thông tin giao dịch, chi tiết hóa đơn vào cơ sở dữ liệu

- Hệ thống cập nhập lại trạng thái của cuộc giao dịch vừa rồi và thông báo giao dịch thành công

 Dòng sự kiện khác:

- Số dư tài khoản của người dùng không đủ để thực hiện giao dịch: Nếu số

dư tài khoản của người dùng không đủ thì hệ thống sẽ hiển thị thông báo:

Số dư tài khoản không đủ để thực hiện giao dịch và yêu cầu người dùng kiểm tra lại số lượng sản phẩm cần mua hoặc nạp thêm tiền vào tài khoản.Người dùng có thể kiểm tra lại số lượng sản phẩm, nạp thêm tiền hoặc hủy bỏ thao tác, use case kết thúc

- Mật khẩu giao dịch không chính xác: Nếu mật khẩu giao dịch không chính xác thì hệ thống sẽ hiển thị thông báo: Mật khẩu giao dịch không chính xác và yêu người dùng nhập lại mật khẩu Người dùng có thể nhập lại mật khẩu hoặc hủy bỏ thao tác, use case kết thúc

 Điều kiện tiên quyết:

Người dùng phải đăng nhập vào hệ thống trước khi thực hiện use case

 Trạng thái hệ thống sau khi thực hiện use case:

Nếu use case thành công thì hệ thống sẽ xác nhận hóa đơn đặt hàng Ngược lại, trạng thái hệ thống không thay đổi

 Điểm mở rộng:

Không có

 Sơ đồ Activity “Thêm sản phẩm vào giỏ hàng”

Tiếp nhận yêu cầu thêm sản phẩm

Cập nhật lại giỏ hàng

[Yêu cầu thêm sản phẩm vào giỏ hàng]

Yêu cầu chọn sản phẩm muốn thêm

Yêu cầu chọn số lượng sản phẩm muốn thêm

 Sơ đồ Activity “Sữa sản phẩm trong giỏ hàng”

Tiếp nhận yêu cầu sửa sản phẩm

Cập nhật lại giỏ hàng

[Yêu cầu sửa sản phẩm trong giỏ hàng]

Yêu cầu chọn sản phẩm muốn sửa

Yêu cầu sửa số lượng sản phẩm

 Sơ đồ Activity “Xóa sản phẩm trong giỏ hàng”

Tiếp nhận yêu cầu xóa sản phẩm

Cập nhật lại giỏ hàng

[Yêu cầu xóa sản phẩm trong giỏ hàng]

Yêu cầu chọn sản phẩm muốn xóa

Xác nhận đã xóa sản phẩm [Không xóa]

[Xóa]

4.6 Đặc tả Use case “Quản lý thông tin khách hàng”:

- Sau khi admin chọn chức năng, một trong các luồng sau sẽ thực hiện:

o Nếu admin chọn “Xóa khách hàng”: luồng phụ Xóa được thực hiện.

o Nếu admin chọn “Sửa thông tin khách hàng”: luồng phụ Sửa được

thực hiện

o Nếu admin chọn “Ghi chú”: luồng phụ thêm ghi chú sẽ được thục

hiện

 Xóa khách hàng:

- Admin chọn khách hàng muốn xóa

- Hệ thống tìm kiếm và hiển thị thông tin của khách hàng mà người sử dụng yêu cầu

- Admin chọn nút “Xóa”

- Hệ thống kiểm tra thông tin khách hàng

- Hệ thống cập nhập lại trạng thái của khách hàng vào cơ sở dữ liệu.

- Sơ đồ Activity “Xóa khách hàng”

 Sửa thông tin khách hàng:

- Người dùng chọn khách hàng cần thay đổi thông tin

- Hệ thống tìm kiếm và hiển thị thông tin của khách hàng mà người sử dụng yêu cầu

- Admin thay đổi thông tin khách hàng này Bao gồm tất cả các thông tin:

- Hệ thống kiểm tra các thông tin vừa thay đổi

- Hệ thống cập nhập lại cơ sở dữ liệu và hiển thị các thông tin vừa thay đổi lên màn hình

- Sơ đồ Activity “Sửa thông tin khách hàng”

 Thêm khách hàng:

- Admin thêm khách hàng

- Hệ thống kiểm tra và cập nhật khách hàng được thêm

- Hệ thống cập nhật lại cơ sở dữ liệu vừa thay đổi

- Sơ đồ Activity “Thêm khách hàng”

Tiếp nhận yêu cầu thêm khách hàng

nhập thông tin khách hàng muốn thêm

- Email của khách hàng đã tồn tại: Nếu email nhập vào trong luồng phụ

“Sửa thông tin khách hàng” không hợp lệ thì hệ thống sẽ hiển thị thông báo lỗi: các Email khách hàng không hợp lệ và yêu cầu admin nhập lại email khác Admin có thể chỉnh sửa các thông tin chưa hợp lệ hay hủy thao tác đang thực hiện, use case kết thúc

 Các yêu cầu đặc biệt:

Không có

 Điều kiện tiên quyết:

Admin phải đăng nhập vào hệ thống để thực hiện use case

 Trạng thái hệ thống sau khi thực hiện use case:

Nếu use case thành công, thông tin của khách hàng sẽ được xóa hoặc sửa trong

cơ sở dữ liệu

 Điểm mở rộng:

Không có

4.7 Đặc tả use case “Đăng kí”:

- Hệ thống lưu thông tin của người dùng và cơ sở dữ liệu

- Hệ thống hiển thị thông thông báo đăng kí thành công và đã đăng nhập

 Dòng sự kiện khác:

- Email không chính xác hoặc đã có người sử dụng: Nếu trong trường hợp email người dùng nhập vào không chính xác hoặc đã có người sử dụng thì

hệ thống sẽ thông báo và yêu cầu người dùng nhập lại email Người dùng

có thể nhập lại email hoặc hủy thao tác, use case kết thúc

- Thông tin không đầy đủ: Nếu trong trường hợp thông tin người dùng nhậpvào không đầy đủ thì hệ thống sẽ hiển thị thông báo yêu cầu người dùng nhập lại các thông tin còn thiếu Người dùng có thể nhập lại các thông tin hoặc hủy thao tác, use case kết thúc

 Yêu cầu đặc biệt:

Không có

 Điều kiện tiên quyết:

Không có

 Trạng thái hệ thống sau khi thực hiện use case:

Nếu use case thành công thì một tài khoản khách hàng mới được thêm vào cơ sở

dữ liệu Và ngược lại, trạng thái hệ thống không thay đổi

 Điểm mở rộng:

Không có

Sơ đồ Activity “Đăng ký”

4.8 Đặc tả Use case “Liên hệ”:

- Khách hàng thông báo cho hệ thống là không muốn liên hệ nữa thì

usecase này được kết thúc

 Yêu cầu đặc biệt:

Không có

 Điều kiện tiên quyết:

khách hàng phải đăng nhập vào hệ thống trước khi use case bắt đầu

 Điểm mở rộng:

Không có.

Sơ đồ Activity “Liên hệ”

Tiếp nhận yêu cầu liên hệ khách hàng

khách hàng xem thông tin liên hệ , trình bày thắc mắc

Xác nhận đã lưu thắc mắc của khách hàng

cập nhật lại trang liên hệ

[Yêu cầu liên hệ của khách hàng]

4.9 Đặc tả Use case “Quản lý Liên hệ”:

 Dòng sự kiện chính:

- Hệ thống yêu cầu admin chọn chức năng cần thực hiện (Thêm, xóa, sửa)

- Sau khi admin chọn chức năng, một trong các luồng sau được thực hiện:

o Nếu admin chọn “Thêm thông tin liên hệ”: luồng phụ Thêm được thựchiện

o Nếu admin chọn “Sửa thông tin liên hệ”: luồng phụ Sửa được thực hiện

o Nếu admin chọn “Xóa thông tin liên hệ”: luồng phụ Xóa được thực hiện

 Thêm thông tin liên hệ:

- Hệ thống yêu cầu admin nhập thông tin liên hệ

- Hệ thống lưu thông tin liên hệ và hiển thị thông tin liên hệ lên màn hình

Sơ đồ Activity “Thêm thông tin liên hệ”

Tiếp nhận yêu cầu thêm thông tin liên hệ của admin

admin thêm thông tin liên hệ

Xác nhận thông tin liên hệ đã thêm

cập nhật lại trang liên hệ

Lưu

[Yêu cầu thêm thông tin liên hệ]

Không lưu

 Sửa thông tin liên hệ:

- Admin chọn thông tin liên hệ muốn thay đổi thông tin

- Hệ thống kiểm tra thông tin được thay đổi

- Hệ thống cập nhập thông tin thay đổi và xuất thông tin ra màn hình

Sơ đồ Activity “Sữa thông tin liên hệ”

Tiếp nhận yêu cầu sửa thông tin liên hệ của admin

admin sửa thông tin liên hệ muốn thay đổi

Xác nhận thông tin liên hệ đã thay đổi

cập nhật lại trang liên hệ

Lưu [Yêu cầu sửa thông tin liên hệ]

Không lưu

 Xóa thông tin liên hệ:

- Admin chọn thông tin liên hệ muốn xóa

- Hệ thống cập nhập lại thông tin liên hệ

Sơ đồ Activity “Xóa thông tin liên hệ”

Tiếp nhận yêu cầu xóa thông tin liên hệ của admin

admin xóa thông tin liên hệ muốn xóa

Xác nhận thông tin liên hệ đã thay đổi

cập nhật lại trang liên hệ

 Các yêu cầu đặc biệt:

Không có

 Điều kiện tiên quyết:

Admin phải đăng nhập vào hệ thống để thực hiện use case

 Trạng thái hệ thống sau khi thực hiện use case:

Nếu use case thành công thì một thông tin liên hệ mới sẽ được thêm vào cơ sở

dữ liệu Ngược lại hệ thống không thay đổi

 Điểm mở rộng:

Không có

4.10 Đặc tả Use case “Xem tin tức”:

 Tóm tắt:

Use Case này cho phép khách hàng xem tin tức của website

 Dòng sự kiện:

 Dòng sự kiện chính:

- Khách hàng click vào trang Tin tức

- Hệ thống hiển thị trang tin tức

Sơ đồ Activity “Xem tin tức”

Tiếp nhận yêu cầu xem tin tức

Hiển thị tin tức chọn tin tức cần xem

[Yêu cầu xem tin tức]

4.11 Đặc tả Use case “ Quản lý tin tức”:

- Hệ thống hiển thị danh sách tin tức

- Hệ thống yêu cầu admin chọn chức năng cần thực hiện (Thêm, xóa, sửa)

- Sau khi admin chọn chức năng, một trong các luồng sau được thực hiện:

o Nếu admin chọn “Thêm tin tức”: luồng phụ Thêm được thực hiện

o Nếu admin chọn “Sửa tin tức”: luồng phụ Sửa được thực hiện

o Nếu admin chọn “Xóa tin tức”: luồng phụ Xóa được thực hiện

 Thêm thông tin:

- Hệ thống yêu cầu admin nhập thông tin tin tức

- Hệ thống kiểm tra thông tin đã được nhập

- Hệ thống lưu thông tin và hiển thị tin tức lên màn hình

- Sơ đồ Activity “Thêm tin tức”

Tiếp nhận yêu cầu thêm tin tức của admin

admin thêm tin tức cần thêm

Xác nhận thông tin tin tức đã thay đổi

cập nhật lại trang tin tức

Lưu

[Yêu cầu thêm tin tức]

Không lưu

 Sửa thông tin:

- Admin chọn tin tức muốn thay đổi

- Admin thay đổi thông tin này Bao gồm tất cả thông tin tại luồng phụ

“Thêm tin tức”

- Hệ thống kiểm tra thông tin được thay đổi

- Hệ thống cập nhập thông tin thay đổi và xuất tin tức ra màn hình

- Sơ đồ Activity “Sửa tin tức”

Tiếp nhận yêu cầu sửa tin tức của admin

admin chọn tin tức cần sửa

Xác nhận thông tin tin tức đã thay đổi

Sửa [Yêu cầu sửa tin tức]

Không sửa

 Xóa tin tức:

- Admin chọn tin tức muốn xóa

- Hệ thống cập nhập lại danh sách các tin tức

- Sơ đồ Activity “Xóa tin tức”

Tiếp nhận yêu cầu xóa tin tức của admin

admin chọn tin tức cần xóa

Xác nhận thông tin tin tức đã bị xóa

cập nhật lại trang tin tức

 Các yêu cầu đặc biệt:

Không có

 Điều kiện tiên quyết:

Admin phải đăng nhập vào hệ thống để thực hiện use case

 Trạng thái hệ thống sau khi thực hiện use case:

Nếu use case thành công thì một tin tức mới sẽ được thêm vào cơ sở dữ liệu Ngược lại hệ thống không thay đổi

 Dòng sự kiện:

Use case này bắt đầu khi người dùng muốn tìm kiếm sách trong hệ thống

 Dòng sự kiện chính:

- Hệ thống yêu cầu người sử dụng chọn chức năng tìm kiếm

- Sau khi người sử dụng chọn chức năng Tìm kiếm, luồng phụ Tìm kiếm đượcthực hiện

 Tìm kiếm:

- Hệ thống hiển thị giao diện tìm kiếm giao tiếp với người sử dụng

- Hệ thống yêu cầu người dùng chọn các điều kiện tìm kiếm theo ýmuốn mà hệ thống hỗ trợ

- Danh sách các sản phẩm thoả điều kiện đã được đưa ra sẽ được hiểnthị (kết quả tìm kiếm)

 Dòng sự kiện khác:

- Không có sản phẩm nào thoả điều kiện tìm kiếm được đưa ra: Hệ thống tựđộng thông báo cho người sử dụng biết không có sản phẩm nào thoả điềukiện đã được đưa ra và trở về trạng thái trước đó Lúc này Use-case kết thúc

 Các yêu cầu đặc biệt:

Không có

 Điều kiện tiên quyết:

Không có

 Trạng thái hệ thống sau khi kết thúc Usecase:

Nếu Usecase thành công, những sản phẩm thoả điều kiện tìm kiếm sẽ được hiểnthị Ngược lại trạng thái của hệ thống không thay đổi

 Điểm mở rộng:

Không có

Sơ đồ Activity “Tìm kiếm”

Tiếp nhận yêu cầu nhập từ khóa tìm kiếm

Hiển thị kết quả tìm kiếm

[ Không tìm thấy kết quả]

[ tìm thấy kết quả]

[Yêu cầu tìm kiếm]

4.13 Use case “Quản lý đơn hàng”:

- Hệ thống hiển thị danh sách các đơn hàng đã đặt

- Sau khi admin chọn chức năng, một trong các luồng sau sẽ thực hiện:

o Nếu admin chọn “Xem danh sách đơn hàng”: luồng phụ Xem danh

sách đơn hàng được thực hiện

o Nếu admin chọn “Xem chi tiết đơn hàng”: luồng phụ Xem chi tiết đơn

 Xem danh sách đơn hàng:

- Admin chọn Xem danh sách đơn hàng

- Hệ thống tìm kiếm và hiển thị tất cả các đơn hàng của khách hàng mà người sử dụng yêu cầu

- Sơ đồ Activity “Xem danh sách đơn hàng”

 Xem chi tiết đơn hàng:

- Người dùng chọn đơn hàng cần xem chi tiết

- Hệ thống tìm kiếm và hiển thị thông tin của khách hàng và thong tin sản phẩm khách hàng đã đặt mua

Sơ đồ Activity “Xem chi tiết đơn hàng”

 Lọc đơn hàng:

- Admin chọn chức năng lọc đơn hàng

- Hệ thống kiểm tra và hiển thị nhưng đơn hàng đã được lọc theo yêu cầu của admin ( lọc theo ngày tháng, sản phẩm )

- Sơ đồ Activity “Lọc đơn hàng”

 Sắp xếp đơn hàng:

- Admin chọn chức năng sắp xếp các đơn hàng (theo ngày tháng,

quý…)

- Hệ thống tìm kiếm và hiển thị danh sách đơn hàng đã được sắp xếp

- Sơ đồ Activity “Sắp xếp đơn hàng”

 Dòng sự kiện khác:

- Nếu không có đơn hàng nào thỏa điều kiện mà admin yêu cầu thì hệ thống

sẽ thong báo không tìm thấy danh sách cần, use case kết thúc

 Các yêu cầu đặc biệt:

Không có

 Điều kiện tiên quyết:

Admin phải đăng nhập vào hệ thống để thực hiện use case

 Trạng thái hệ thống sau khi thực hiện use case:

Nếu use case thành công, hệ thống sẽ hiển thị theo yêu cầu những danh sách có trong cơ sở dữ liệu

 Điểm mở rộng:

Không có