Tóm tắt
Use case này cho phép người dùng thoát khỏi hệ thống sau khi đã đăng nhập vào rồi(signed in).
Các luồng sự kiện
Luồng các sự kiện chính
Use case này bắt đầu khi người dùng muốn thoát khỏi hệ thống khi đã đăng nhập rồi. 1. Hệ thống kết thúc mọi hoạt động, kết thúc một phiên đăng nhập chọn mua hàng... 2. Người dùng trở về trạng thái chưa đăng nhập
3. Hệ thống thông báo thông điệp kết thúc. 4. Use case kết thúc.
Luồng sự kiện phụ
Không có
● Pre – Condition (điều kiện trước): người dùng phải đăng nhập rồi ● Post –Condition (điều kiện sau): người dùng thoát khỏi hệ thống. 3.2.3.4 Use case duyệt xem danh mục hàng (browse catalog)
Tóm tắt
Use case này cho phép người dùng duyệt xem danh mục hàng trong hệ thống. Người dùng có thể tìm kiếm mục hàng cụ thể hoặc các mục hàng xếp sẵn thành loại (category).
Hệ thống hiển thị thông tin mục hàng đã yêu cầu, một khi mục hàng đã hiển thị, người dùng có thể chọn vào giỏ hàng
Các luồng sự kiện
Luồng các sự kiện chính
1. Use case này bắt đầu khi người dùng muốn tìm các mục hàng có trong hệ thống. 2. Hệ thống hiển thị mục hàng cho người dùng, người dùng cũng có thể nhập từ khoá để tìm kiếm. Công việc này có thể lặp đi lặp lại nhiều lần. Tìm kiếm có nhiều cách: - Search catalog: người dùng nhập từ khoá vào để tìm loại hàng, hoặc mục hàng cụ thể. Người dùng có thể chọn mục hàng vào giỏ hàng.
- Browse category: người dùng có thể chọn loại hàng trực tiếp có sẳn trong danh mục hàng (catalog). Hệ thống hiển thị các sản phẩm (product) của loại hàng đó.
- Browse product detail: người dùng sau khi duyệt qua loại hàng(category), các sản phẩm của loại hàng đó được hiển thị. Người dùng có thể duyệt qua từng loại sản phẩm. Mỗi loại sản phẩm có các mục hàng (Item) cụ thể, mỗi mục hàng gồm các thông tin: mã số mục hàng (ItemID), tên mục hàng, và giá cả của mục hàng.
- Browse Item detail: khi người dùng duyệt đến các mục hàng cụ thể, người dùng muốn xem chi tiết một mục hàng cụ thể nào đó thì hệ thống hiển thị thông tin: tên mục
Luồng sự kiện phụ
1. Từ khoá nhập vào để tìm kiếm không tìm thấy trong hệ thống.
● Pre – Condition (điều kiện trước):không có. ● Post –Condition (điều kiện sau): không có.
3.2.3.5 Use case chọn mua hàng vào giỏ (shopping cart)
Tóm tắt
Use case này cho phép người dùng chọn mục hàng và đặt vào giỏ hàng. Khi người dùng chọn xong những món hàng mình cần mua thì xác nhận đồng ý mua. Hệ thống yêu cầu người mua nhập thông tin về thẻ tín dụng, địa chỉ hoá đơn, địa chỉ vận chuyển. Hệ thống sẽ xác nhận tính hợp lệ của thẻ tín dụng và những thông tin khác. Sau đó người dùng submit hoá đơn đến hệ thống. Hệ thống gửi thông điệp xác nhận thông qua emai. Nếu người dùng chưa đăng nhập thì hệ thống bắt buộc phải đăng nhập.
Các luồng sự kiện
Luồng các sự kiện chính
1. Use case này bắt đầu khi người dùng muốn mua các mục hàng trong hệ thống. Người dùng tìm các mục hàng mình cần mua và đặt các mục hàng đó vào giỏ, quá trình chọn hàng lặp đi lặp lại cho đến khi người dùng chọn hàng xong. Trong quá trình chọn mua hàng người dùng có thể:
Thêm hoặc xoá mục hàng.
Thay đổi số lượng của một mục hàng trong giỏ hàng. Đồng ý mua mục hàng đó.
2. Khi chọn xong giỏ hàng, hệ thống yêu cầu xác nhận đồng ý mua các mục hàng đó. 3. Nếu người mua chưa đăng nhập thì hệ thống bắt buộc phải đăng nhập. Khi đã đăng nhập rồi thì hệ thống yêu cầu nhập thông tin về thẻ tín dụng, địa chỉ hoá đơn, địa chỉ vận chuyển và các thông tin khác.
4. Hệ thống yêu cầu người dùng xác nhận lại những thông tin trên, đồng thời hệ thống thẩm định thông tin đó có hợp lệ hay không.
5. Hệ thống hiển thị một hoá đơn cho người mua.
6. Hệ thống gửi một thông điệp xác nhận thông qua email 7. Use case kết thúc.
Luồng sự kiện phụ
1. Người dùng mua một mục hàng nào đó với số lượng vượt quá số lượng có trong kho.
2. Thông tin về thẻ tín dụng, địa chỉ hoá đơn, email… người dùng nhập vào không hợp lệ.
● Pre – Condition (điều kiện trước):không có.
● Post –Condition (điều kiện sau): một đơn hàng được tạo cho người mua (khách hàng), đơn hàng được gửi đến hệ thống xử lý đơn hàng, hệ thống này xác nhận và thực
3.3. Phân tích miền ứng dụng.
Sau khi xây dựng xong mô hình yêu cầu trường hợp người dùng: use case, mô hình được người dùng tán thành, ta phát triển mô hình phân tích, phân tích miền ứng dụng đã được nắm bắt.
3.3.1. Mô hình đối tượng:
3.3.1.1. Tìm các lớp giao diện(interface class)
Bước đầu hình thành ý niệm về giao diện, là cửa sổ tương tác giữa hệ thống với người dùng. Chuyển các yêu cầu người dùng vào hệ thống, hệ thống đáp ứng lại thông tin cần thiết mà người dùng mong muốn. Giao diện có thể là các form...
3.3.1.2. Tìm các lớp miền ứng dụng(hay các lớp nghiệp vụ)
Các thể hiện của các lớp này là các đối tượng có thể lưu trữ dữ liệu, xử lý các tính toán nghiệp vụ, xử lý các thông điệp. Đối tượng được tìm như là thực thể tồn tại một cách tự nhiên trong miền ứng dụng. Để tìm đối tượng chúng ta cần rà soát lại đặc tả yêu cầu từ mô hình use case, để nắm bắt những danh từ chứa khái niệm chủ chốt của ứng dụng. Đồng thời đưa ra những chức năng mà hệ thống cần hỗ trợ.
Để tìm đối tượng miền nghiệp vụ (hay miền ứng dụng) ta làm như sau:
● Dùng các luồng sự kiện của Use case như là đầu vào. ● Các trừu tượng hoá then chốt của use case.
● Nhìn vào những khái niệm chủ chốt (những khái niệm mà hệ thống phải hỗ trợ) để rút ra những danh từ.
● Giữ lại các lớp đúng đắn: ta loại bỏ các lớp không cần thiết và không chính xác theo các tiêu chuẩn sau:
- Các lớp dư thừa: nếu hai lớp cùng biểu diễn một thông tin, giữ lại tên diễn tả đúng đắn nhất.
- Các lớp không thích hợp: nếu một lớp có ít hoặc không có gì thực hiện vấn đề, nó phải được loại bỏ.
- Các lớp mơ hồ: một lớp phải xác định, một số lớp thử có thể có biên giới không rõ ràng hoặc là quá rộng, cần được loại bỏ.
- Các thuộc tính: các tên mô tả các đối tượng riêng lẻ. Các thao tác:
- Các vai trò: tên các lớp, phải phản ánh bản chất tự nhiên của nó, không phải là vai trò mà nó đóng trong kết hợp.
- Các cấu trúc cài đặt: các cấu trúc bắt nguồn từ thế giới thực, phảI được loại bỏ, chúng sẽ được cần đến trong khi thiết kế.
Nhận diện các kết hợp
Để xác định các kết hợp, thông thường là ta dựa vào tài liệu đặc tả ứng dụng và đặc biệt là từ mô tả use case để rút ra các động từ hay nhóm động từ. Sau đó ta tiến hành lọc bỏ để giữ lại các kết hợp tốt. Ta loại bỏ các kết hợp không cần thiết và không chính xác theo các tiêu chuẩn sau:
- Các kết hợp không thích hợp hoặc cài đặt: loại bỏ bất cứ kết hợp nào mà ở ngoài lĩnh vực vấn đề hoặc có quan hệ với cấu trúc cài đặt.
- Các tác động: kết hợp phải mô tả một đặc tính về cấu trúc của lĩnh vực ứng dụng. - Các kết hợp ba nhánh: các kết hợp ba nhánh nên được tách ra thành các kết hợp hai nhánh.
- Các kết hợp dẫn xuất: các kết hợp được định nghĩa bằng các kết hợp khác.
Nhận diện các thao tác
Để nhận diện các thao tác, một công cụ thuận lợi là ta nhìn vào các hành vi của các use case - luồng các sự kiện, sau đó phân bổ các hành vi này vào các lớp được sử dụng bởi use case đó.
Nhận diện các thuộc tính
Các thuộc tính là đặc tính của đối tượng riêng lẻ. Thuộc tính thường tương ứng với danh từ theo sau là nhóm từ sở hữu. Thuộc tính kém thích hợp để mô tả đầy đủ một vấn đề. Thuộc tính ít ảnh hưởng đến cấu trúc cơ sở của vấn đề. Đầu tiên ta ghi nhận các thuộc tính quan trọng trước, sau đó thêm dần các chi tiết vào sau.
3.4. Các lược đồ trong các gói
Sau khi tìm ra các lớp miền nghiệp vụ ta nhóm các lớp có quan hệ gần gũi vào trong các gói. Trong mỗi gói có thể chứa gói con trong đó.
Ta có các gói sau:
+ sign in and off package: gói đăng nhập
+ shopping cart package: gói mua chọn hàng, có các gói con là: cart package và catalog package
+ inventory package: gói thống kê số lượng hàng.
+ customer package: gói khách hàng, có các gói con là: account package, customer package, order package.
Lược đồ quan hệ giữa các lớp nghiệp vụ và lớp giao diện:
3.4.1. các lược đồ trong gói sign in and off
Ở mô hình quan niệm phân tích, mô tả yêu cầu ứng dụng ta chỉ mô tả sơ lược về các chức năng mà hệ thống sẽ làm. Đây là mô hình giao tiếp giữa nhà phát triển với người dùng, nó là bản mẫu cho sự giao tiếp, chưa can thiệp vào cách thực hiện như thế nào. Cái đó thuộc về pha thiết kế.