• Tĩm tắt
Use case này cho phép người dùng thố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
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 thố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ừ khố để 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ừ khố 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 hàng, hình ảnh, mơ tả, giá cả, số lượng cĩ sẳn trong kho hàng. 3. Use case kết thúc.
Luồng sự kiện phụ
1. Từ khố nhập vào để tìm kiếm khơng tìm thấy trong hệ thống.
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ỉ hố đơ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 hố đơ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 xố 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ỉ
hố đơ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 hố đơ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ỉ hố đơ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 hiện các bước tiếp theo.
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 tố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à số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 hố 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 giữa các lớp bị loại ra: nếu một trong các lớp của kết hợp đã bị
loại bỏ, thì kết hợp phải được loại bỏ, hoặc phát biểu lại bằng các lớp khác. - 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à ở
- 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ế.