[Hỏi]Giúp em về cái usecase

[vanduc0409]

Em mới lần đầu tiên làm quen với cái usecase này.:sosad::sosad: Em có đọc qua 1 số tài liệu nhưng chưa nắm rõ vấn đề lắm ạ. Em làm 1 ví dụ đơn giản về cái này. Các bác xem có đúng ko nha. :gach::adore:
Ví dụ: em muốn làm 1 cái phần mềm. Em muốn nhân viên điều hành đăng nhập vào hệ thống rồi vào hệ thống sẽ phân ra quản lí học sinh và quản lí giáo viên. Rồi chọn 1 trong 2 đều có chức năng thêm,sửa,xóa.

Em vẽ như sau.
-- Các bác xem có đúng không???.
-- Cái bảng mà bao quanh cái thêm sửa xóa có đúng ko, hay là phải dùng group?????.
-- Đăng nhập vào hệ thống rồi chọn 1 trong 2 cái quản lí học sinh hoặc quản lí giáo viên thì có phải thêm 2 cái usecase quản lí giáo viên và học sinh rồi từ 2 cái usecase đó nối với thêm sửa xóa ko???

http://i740.photobucket.com/albums/xx47/vanduc0409/1-5.jpg

các bác cho em hỏi thêm là cái "include" và "extend" làm sao mà phân biệt được.

PS cho các tay to: nếu mà post nhầm box thì các anh cho thớt em sống qua đêm nay rồi del nha. :stick::stick:

[vanduc0409]

uppppppppppppppppppppppppp.
Không ai giúp em ah. hix

[_sharp_]

extend: B can be inclued in A
include: B is always inclued in A

[vanduc0409]

extend: B can be inclued in A
include: B is always inclued in A

Bạn có thể giúp mình kĩ hơn 1 chút được ko. mình làm cái hình có đúng không???. chỉnh sửa thế nào

[LMFAO]

1. Các bác xem có đúng không???
-> Sai chỗ các Usecase khác Included Đăng nhập. Đăng nhập là 1 trường hợp sử dụng riêng, tuy là muốn thực hiện các Usecase khác thì trước đó phải đăng nhập. Nhân viên quản lý use Đăng nhập. Thiếu Đăng xuất nữa nha bạn.

2. Cái bảng mà bao quanh cái thêm sửa xóa có đúng ko, hay là phải dùng group?????.
-> Đúng. Cái Boundary đó có thể tượng trưng cho 1 System, Subsystem, Module hay Feature...

3. Đăng nhập vào hệ thống rồi chọn 1 trong 2 cái quản lí học sinh hoặc quản lí giáo viên thì có phải thêm 2 cái usecase quản lí giáo viên và học sinh rồi từ 2 cái usecase đó nối với thêm sửa xóa ko???
-> Như thế này, Usecase Diagram có thể vẽ theo Level (High, Low hoặc Detailed). Vd:
- High level sẽ có 4 Usecases: Quản lý Sinh viên, Quản lý Giáo viên, Đăng nhập, Đăng xuất.
- Low level thì không có Quản lý Sinh viên, Quản lý Giáo viên mà trỏ thẳng vào các Usecase con.

Bổ sung:
- Mỗi feature quản lý thông tin gì đó thì phải có Xem danh sách, Xem chi tiết nữa. Sau đó mới đến Thêm, Xóa, Sửa.
- Kiểm tra đúng sai không phải là Usecase. Nó chỉ là 1 bước trong Usecase Đăng nhập.

[_sharp_]

Bạn có thể giúp mình kĩ hơn 1 chút được ko. mình làm cái hình có đúng không???. chỉnh sửa thế nào

Theo bạn, DangNhap extend KiemTraDungSai có đúng kô hay phải include?


extend: B can be inclued in A
include: B is always inclued in A

[vanduc0409]

1. Các bác xem có đúng không???
-> Sai chỗ các Usecase khác Included Đăng nhập. Đăng nhập là 1 trường hợp sử dụng riêng, tuy là muốn thực hiện các Usecase khác thì trước đó phải đăng nhập. Nhân viên quản lý use Đăng nhập. Thiếu Đăng xuất nữa nha bạn.

2. Cái bảng mà bao quanh cái thêm sửa xóa có đúng ko, hay là phải dùng group?????.
-> Đúng. Cái Boundary đó có thể tượng trưng cho 1 System, Subsystem, Module hay Feature...

3. Đăng nhập vào hệ thống rồi chọn 1 trong 2 cái quản lí học sinh hoặc quản lí giáo viên thì có phải thêm 2 cái usecase quản lí giáo viên và học sinh rồi từ 2 cái usecase đó nối với thêm sửa xóa ko???
-> Như thế này, Usecase Diagram có thể vẽ theo Level (High, Low hoặc Detailed). Vd:
- High level sẽ có 4 Usecases: Quản lý Sinh viên, Quản lý Giáo viên, Đăng nhập, Đăng xuất.
- Low level thì không có Quản lý Sinh viên, Quản lý Giáo viên mà trỏ thẳng vào các Usecase con.

Bổ sung:
- Mỗi feature quản lý thông tin gì đó thì phải có Xem danh sách, Xem chi tiết nữa. Sau đó mới đến Thêm, Xóa, Sửa.
- Kiểm tra đúng sai không phải là Usecase. Nó chỉ là 1 bước trong Usecase Đăng nhập.

1. Thế có nghĩa là bỏ tất cả cái included đến đăng nhập ah bạn. Nhưng mình nghĩ trước khi sử dụng thì phải đăng nhập mới được.
2. ok.
3. Nếu phải làm 1 bài thì cũng phải phân ra high level và low level à. Mà low level thì chỉ cần trỏ thẳng vào thêm sửa xóa xem là được à. có cần cái đăng nhập, đăng xuất không
4. ý định mình không phải là kiểm tra đúng sai mà là xử lí khi sai nó sẽ hiện lên 1 panel báo lỗi.

Thanks bạn. Bạn góp ý rất cụ thể:adore:

Theo bạn, DangNhap extend KiemTraDungSai có đúng kô hay phải include?

mình nghĩ là extend. vì nó là 1 hoạt động trong dangnhap. Bạn có thể giải thích cho mình vì sao là include ko:sweat::sweat:

[vanduc0409]

uppppppppppp. hóng các cao nhân

[LMFAO]

Đợi mình 5ph sẽ up ví dụ cho bạn hiểu hơn

[duythanh10a7]

Phân tích thiết kế hướng đối tượng :surrender:

[LMFAO]

Mình mới vẽ Usecase Diagram hệ thống của bạn để bạn có thể hiểu rõ hơn. Và mối liên quan giữa Usecase và Giao diện để phần nào hiểu Included, Extend là như thế nào.
Download: w w w.mediafire.com/download.php?ohx3w905su99cl6

1. Định nghĩa Usecase: là 1 trường hợp sử dụng của người dùng (người, hoặc máy) tác động lên hệ thống. Usecase được chia làm 2 loại High level và Detailed level.
- High level (Xem hình UCD-Level1): thường dùng trong Architecture (phân tích kiến trúc hệ thống vì kiến trúc thì không cần detailed usecase), hoặc viết tài liệu cho customer (không có kiến thức về ngành phần mềm) hay end-user xem (vì họ cũng ko cần hiểu detailed mà vẫn có thể hiểu hệ thống hoạt động như thế nào.
- Detailed level (Xem hình UCD-Level2): thường dùng trong Detailed Design. Khi đó cần phải thật chi tiết usecase và làm 1 số bước nữa (học Detailed Design bạn sẽ biết) để chuyển qua giai đoạn Implementation (Coding).
-> Vậy thì trước khi phân tích Usecase, bạn phải biết rằng tài liệu bạn cần phải viết mục đích của nó dùng để làm gì? Và làm đúng với những gì tài liệu yêu cầu.

2. UseCase Description: mô tả chi tiết 1 Usecase. Phần này mình mô tả để bạn hiểu cái "Kiểm tra đúng sai" của bạn không phải là usecase. VD Usecase Đăng nhập (Mình chỉ viết Main flow, bỏ qua pre,post condition và các flow khác):
- Người sử dụng nhập Tên tài khoản và Mật khẩu.
- Người sử dụng chọn "Đăng nhập".
- Hệ thống kiểm tra tính hợp lệ của Tên tài khoản và Mật khẩu người sử dụng nhập vào.
Business Rule: Mật khẩu có độ dài từ 6 đến 12 kí tự và chỉ chứa các ký tự a-z, A-Z, 0-9.
- Hệ thống kiểm tra sự tồn tài của tài khoản trong hệ thống.
- Hệ thống tắt cửa sổ đăng nhập và hiển thị màn hình chính.
- Kết thúc Usecase.
Như trên, "Kiểm tra đúng sai" của bạn chỉ là 1 bước trong mô tả Usecase Đăng nhập. Nếu cho nó là 1 usecase, thì mình cũng có thể thêm 1 usecase nữa là "Kiểm tra tồn tại". Điều đó là không đúng.

3. Included: bạn xem hình Exp-Include và UCD-Level2 cái Quản lý thông tin giáo viên. Và tự đặt câu hỏi:
- Tại sao "Xem danh sách" extend "Thêm"?
- Nhưng lại include "Xem"?
4. Extend: bạn xem hình Exp-Extend và UCD-Level2 cái Quản lý thông tin sinh viên. Và cũng đặt câu hỏi:
- Tại sao "Xem danh sách" extend "Thêm"?
- Và extend"Xem"?
- 2 hình Exp-Extend và Exp-Include khác nhau chỗ nào?

Mới bắt đầu với Usecase mà bạn hiểu như vậy là tốt rồi. Cố gắng tìm hiểu và thực hành nhiều hơn là bạn sẽ làm tốt thôi :)

[windsea]

chú này học BCVT hửm

[vanduc0409]

Đợi mình 5ph sẽ up ví dụ cho bạn hiểu hơn

Thanks bạn:beauty::beauty:

chú này học BCVT hửm

Uhm. d09. đồng môn ah

Phân tích thiết kế hướng đối tượng :surrender:

Công nghệ phần mềm mà. Phân tích thiết kế hướng đối tượng kì sau mình mới học:look_down:

[vanduc0409]

Mình mới vẽ Usecase Diagram hệ thống của bạn để bạn có thể hiểu rõ hơn. Và mối liên quan giữa Usecase và Giao diện để phần nào hiểu Included, Extend là như thế nào.
Download: w w w.mediafire.com/download.php?ohx3w905su99cl6

1. Định nghĩa Usecase: là 1 trường hợp sử dụng của người dùng (người, hoặc máy) tác động lên hệ thống. Usecase được chia làm 2 loại High level và Detailed level.
- High level (Xem hình UCD-Level1): thường dùng trong Architecture (phân tích kiến trúc hệ thống vì kiến trúc thì không cần detailed usecase), hoặc viết tài liệu cho customer (không có kiến thức về ngành phần mềm) hay end-user xem (vì họ cũng ko cần hiểu detailed mà vẫn có thể hiểu hệ thống hoạt động như thế nào.
- Detailed level (Xem hình UCD-Level2): thường dùng trong Detailed Design. Khi đó cần phải thật chi tiết usecase và làm 1 số bước nữa (học Detailed Design bạn sẽ biết) để chuyển qua giai đoạn Implementation (Coding).
-> Vậy thì trước khi phân tích Usecase, bạn phải biết rằng tài liệu bạn cần phải viết mục đích của nó dùng để làm gì? Và làm đúng với những gì tài liệu yêu cầu.

2. UseCase Description: mô tả chi tiết 1 Usecase. Phần này mình mô tả để bạn hiểu cái "Kiểm tra đúng sai" của bạn không phải là usecase. VD Usecase Đăng nhập (Mình chỉ viết Main flow, bỏ qua pre,post condition và các flow khác):
- Người sử dụng nhập Tên tài khoản và Mật khẩu.
- Người sử dụng chọn "Đăng nhập".
- Hệ thống kiểm tra tính hợp lệ của Tên tài khoản và Mật khẩu người sử dụng nhập vào.
Business Rule: Mật khẩu có độ dài từ 6 đến 12 kí tự và chỉ chứa các ký tự a-z, A-Z, 0-9.
- Hệ thống kiểm tra sự tồn tài của tài khoản trong hệ thống.
- Hệ thống tắt cửa sổ đăng nhập và hiển thị màn hình chính.
- Kết thúc Usecase.
Như trên, "Kiểm tra đúng sai" của bạn chỉ là 1 bước trong mô tả Usecase Đăng nhập. Nếu cho nó là 1 usecase, thì mình cũng có thể thêm 1 usecase nữa là "Kiểm tra tồn tại". Điều đó là không đúng.

3. Included: bạn xem hình Exp-Include và UCD-Level2 cái Quản lý thông tin giáo viên. Và tự đặt câu hỏi:
- Tại sao "Xem danh sách" extend "Thêm"?
- Nhưng lại include "Xem"?
4. Extend: bạn xem hình Exp-Extend và UCD-Level2 cái Quản lý thông tin sinh viên. Và cũng đặt câu hỏi:
- Tại sao "Xem danh sách" extend "Thêm"?
- Và extend"Xem"?
- 2 hình Exp-Extend và Exp-Include khác nhau chỗ nào?

Mới bắt đầu với Usecase mà bạn hiểu như vậy là tốt rồi. Cố gắng tìm hiểu và thực hành nhiều hơn là bạn sẽ làm tốt thôi :)

Thanks bạn đã giúp. Để mình download về tìm hiểu thêm.
Mà bạn đang học hay đi làm rồi.

----------------------------------------------------------
Đã xem qua bài bạn. Đúng là vừa đọc thấy thắc mắc ngay chỗ extend và include. Mình thấy giáo viên và sinh viên là bình đẳng sao chỗ thì dùng extend, chỗ thì dùng include. Mà hơn nữa sao lại dùng (-->)(mũi tên) để nối giữa nhân viên với các usecase hả bạn. Sao mình toàn dùng(-)(đường thẳng):surrender::surrender:
Cái này khó hiểu quá. hix.

[vanduc0409]

Bác LM ơi, em vẫn chưa phân biệt sự khác nhau khi nhìn vào 2 ảnh đó của bác. hix

Theo như em hiểu về 2 cái đó thì là

Extend là mở rộng. tức là chỉ là các trường hợp đặc biệt của 1 usecase
Include là bao gồm, nó là 1 hành động khác. Phải thực hiện nó mới thực hiện được các cái sau.

Như vậy thì cái hình của bác em thấy lạ lạ thế nào đó.
"Xem danh sách" <--- include--- "xem". tức là chức năng "xem" phải thực hiện trước rồi mới "xem danh sach". Cũng như thế thì UCD-level 1 đáng ra mấy cái usecase đó phải --include--> đến đăng nhập mới đúng chứ nhỉ

Em nói sai bác thông cảm.:gach::gach:. Giải thích cụ thể hơn tí nữa cho em đi bác

[vanduc0409]

uppppppppppppppp lên

[kaizvn]

lấy cái này về coi.
giải thích đầy đủ extend và include.
trước mình cũng dùng cái guide này để viết cho dự án :D.

chủ thớt có rau ria gì thì pm trả ơn nhá :beauty:

[vanduc0409]

lấy cái này về coi.
giải thích đầy đủ extend và include.
trước mình cũng dùng cái guide này để viết cho dự án :D.

chủ thớt có rau ria gì thì pm trả ơn nhá :beauty:

cái này mình download về đọc rồi. Nhưng mình muốn hiểu rõ hơn qua ví dụ của mình.
Thanks bạn:adore::adore:

[LMFAO]

Cái Sinh viên mình để Extend, Giáo viên mình để Include là để ví dụ thôi. Tùy vào hoàn cảnh mình sẽ quyết định là Include hay Extend. Nó sẽ ảnh hưởng đến người thiết kế giao diện khi nhìn vào Usecase của bạn.
A Include B không có nghĩa là thực hiện B trước mới thực hiện A. Mà là trong khi thực hiện A ta sẽ bắt buộc phải thực hiện B.

Quản lý sinh viên mình để "Xem danh sách" extend "Xem" có nghĩa là trong khi "Xem danh sách", bạn có thể "Xem" hoặc không "Xem". Khi đó bạn tham khảo giao diện thứ 1 của mình, giao diện chính là 1 cái danh sách, muốn xem chi tiết phải double click vào 1 dòng trong danh sách đó thì nó hiện lên cửa sổ xem chi tiết. Hoặc là bạn không muốn xem thì không double click. Điều đó phù hợp với Extend.

Quản lý Giáo viên mình để "Xem danh sách" include "Xe" có nghĩa là trong khi "Xem danh sách", thì luôn hiển thị thông tin chi tiết bên cạnh (trên cùng 1 cửa sổ), điều đó là bắt buộc. Bạn tham khảo giao diện thứ 2 của mình. Vậy thì nó đúng với định nghĩa Include.

Mình đang học năm 3 Software Engineering và đã thực hiện usecase này gần 2 năm. Còn thắc mắc thì bạn cứ post nhé.

[kaizvn]

cái này mình download về đọc rồi. Nhưng mình muốn hiểu rõ hơn qua ví dụ của mình.
Thanks bạn:adore::adore:

quái thật, cái đó nói cũng dễ hiểu quá rồi còn gì, đi học lăn đùng ra ngủ à :canny: :angry:

extend và include thì cứ như nghĩa của nó.
vd hành động A có thể có các chức năng khác thêm nữa thì extend, còn include là cần phải có cái gì đó mới đc.

vd : user extend login, register.
user mua hàng, đưa hàng vào giỏ rồi bấm thanh toán, nhưng cần phải có thằng admin nó xác nhận giao dịch đàng hoàng, thông tin ok thì nó mới confirm, rồi tiến hành giao hàng.
vậy
user --(extend)-->checkout --(extend)--->order completed.

có thêm 1 cái include vào ngay cái checkout là
admin --(include) ---> checkout

kết quả :
yes ---> order complete, còn no---> order cancelled.

vì ko vẽ ra nên mình chỉ giải thích sơ sơ đc.

[vanduc0409]

Cái Sinh viên mình để Extend, Giáo viên mình để Include là để ví dụ thôi. Tùy vào hoàn cảnh mình sẽ quyết định là Include hay Extend. Nó sẽ ảnh hưởng đến người thiết kế giao diện khi nhìn vào Usecase của bạn.
A Include B không có nghĩa là thực hiện B trước mới thực hiện A. Mà là trong khi thực hiện A ta sẽ bắt buộc phải thực hiện B.

Quản lý sinh viên mình để "Xem danh sách" extend "Xem" có nghĩa là trong khi "Xem danh sách", bạn có thể "Xem" hoặc không "Xem". Khi đó bạn tham khảo giao diện thứ 1 của mình, giao diện chính là 1 cái danh sách, muốn xem chi tiết phải double click vào 1 dòng trong danh sách đó thì nó hiện lên cửa sổ xem chi tiết. Hoặc là bạn không muốn xem thì không double click. Điều đó phù hợp với Extend.

Quản lý Giáo viên mình để "Xem danh sách" include "Xe" có nghĩa là trong khi "Xem danh sách", thì luôn hiển thị thông tin chi tiết bên cạnh (trên cùng 1 cửa sổ), điều đó là bắt buộc. Bạn tham khảo giao diện thứ 2 của mình. Vậy thì nó đúng với định nghĩa Include.

Mình đang học năm 3 Software Engineering và đã thực hiện usecase này gần 2 năm. Còn thắc mắc thì bạn cứ post nhé.

:beauty::beauty:. Tối qua mình cũng đã ngẫm nghĩ thế này rồi:byebye:. Nhưng mình vẫn thắc mắc. Sao mũi tên extend lại chỉ vào thếm,xóa,cập nhật... Mình nghĩ là phải ngược lại chứ nhỉ.:sosad:. Trong mục xem danh sách thì có thếm sửa xóa chứ nhỉ. Giải thích mình đoạn này nữa nha.
Bạn học năm thứ 3 là bằng mình. Nhưng trường mình lại mới bắt đầu học. hix. Mình PTIT

[vanduc0409]

quái thật, cái đó nói cũng dễ hiểu quá rồi còn gì, đi học lăn đùng ra ngủ à :canny: :angry:

extend và include thì cứ như nghĩa của nó.
vd hành động A có thể có các chức năng khác thêm nữa thì extend, còn include là cần phải có cái gì đó mới đc.

vd : user extend login, register.
user mua hàng, đưa hàng vào giỏ rồi bấm thanh toán, nhưng cần phải có thằng admin nó xác nhận giao dịch đàng hoàng, thông tin ok thì nó mới confirm, rồi tiến hành giao hàng.
vậy
user --(extend)-->checkout --(extend)--->order completed.

có thêm 1 cái include vào ngay cái checkout là
admin --(include) ---> checkout

kết quả :
yes ---> order complete, còn no---> order cancelled.

vì ko vẽ ra nên mình chỉ giải thích sơ sơ đc.

Đi học chăm chú nghe giảng nhưng đây mới là bài đầu tiên nên cũng khó phân biệt. :pudency::pudency:. Mình muốn chắc chắn cái vấn đề này chút để về sau cho đỡ sai. Cái pdf bạn gửi mình đọc qua rồi. Hiểu thì có nhưng không chắc chắn lắm:sweat::sweat:

[rockman_9x]

chú này học BCVT hửm

hải Phong =)) Biết tôi ko

[LMFAO]

mình có trả lời trong topic của bạn đó. yahoo thì mình sẽ pm bạn sau

[vanduc0409]

Oh mình vẽ ngược Extend với Include :D

Bạn cho mình nick yahoo đi. Mà bạn nói bạn vẽ ngược là sao. Tức là quay đầu lại hết ah. :pudency::pudency::gach::gach:. Bạn giải thích mình luôn đi.
Mà mình tưởng phải có tương tác từ nhân viên với Thêm, cập nhật, Xóa chứ. Usecase là tương tác giữa người dùng và phần mềm mà bạn. Tức là người dùng sử dụng chức năng thêm sửa xóa => có đường thẳng từ nhân viên đến thêm, sửa, xóa chứ nhỉ

[LMFAO]

Bạn cho mình nick yahoo đi. Mà bạn nói bạn vẽ ngược là sao. Tức là quay đầu lại hết ah. :pudency::pudency::gach::gach:. Bạn giải thích mình luôn đi.
Mà mình tưởng phải có tương tác từ nhân viên với Thêm, cập nhật, Xóa chứ. Usecase là tương tác giữa người dùng và phần mềm mà bạn. Tức là người dùng sử dụng chức năng thêm sửa xóa => có đường thẳng từ nhân viên đến thêm, sửa, xóa chứ nhỉ

Oh xoay ngược chiều Extend và Include lại nha bạn.
Nếu giải thích thì mình sẽ đi ngược từ Giao diện về Usecase thì bạn sẽ hiểu hơn. Nhưng như thế thì không đúng bài bản. Sau 1 năm biết Usecase, mình cũng làm như bạn. Sau đó được thầy hướng dẫn cách làm này, mới hiểu rõ hơn và xem nó như là 1 format vẽ Usecase cho các feature Quản lý thông tin như vậy. Cho mình hỏi bạn hiểu và phân biệt feature với function requirement như thế nào?

[vanduc0409]

uhm. ok
Còn phân biệt giữa feature và requirement thì mình chưa biết. Tính năng và yêu cầu. Mình nghĩ là giống nhau. Bạn nói thêm đi
Ah. Mà nếu có thêm phần tìm kiếm trong mỗi cái quản lí thì trong mỗi cái subsystem thêm 1 usecase tìm kiếm rồi nối với nhân viên bạn nhỉ. :byebye:

[LMFAO]

uhm. ok
Còn phân biệt giữa feature và requirement thì mình chưa biết. Bạn nói thêm đi

- Fuctional Requirement là chức năng như đăng nhập, đăng xuất, Xem, Thêm, Xóa, Sửa...
- Feature dịch ra là tính năng, nhưng theo cách nhìn của mình thì nó là tập hợp các chức năng tác động vào 1 thông tin cụ thể. Ví dụ Quản lý thông tin Sinh viên là 1 feature, Quản lý thông tin Giáo viên là 1 feature. Trong đó có Xem danh sách, Thêm, Xem, Xóa, Sửa đều tác động vào thông tin Sinh viên hay tt Giáo viên.

Khi vào 1 cửa sổ quản lý 1 thông tin gì đó (như giao diện của mình) thì bạn luôn phải Xem danh sách, rồi sau đó muốn Thêm, Xem chi tiết, Xóa, Sửa sau đúng ko? Vậy thì Actor trỏ thẳng vào Xem danh sách.
Vậy bạn thử đặt trường hợp ngược lại, Actor trỏ thẳng vào Thêm. Vậy làm sao để chọn chức năng Thêm mà không Xem danh sách? Khi đó bạn suy nghĩ "Thêm" include "Xem danh sách"??? Nhưng thật ra là "Xem danh sách" Extend "Thêm". Có nghĩa là trong khi xem danh sách, bạn có thể Thêm hoặc ko Thêm.

[LMFAO]

uhm. ok
Còn phân biệt giữa feature và requirement thì mình chưa biết. Tính năng và yêu cầu. Mình nghĩ là giống nhau. Bạn nói thêm đi
Ah. Mà nếu có thêm phần tìm kiếm trong mỗi cái quản lí thì trong mỗi cái subsystem thêm 1 usecase tìm kiếm rồi nối với nhân viên bạn nhỉ. :byebye:

Thường thì mình để chung tìm kiếm vào usecase "Xem danh sách", và nó trở thành "Tìm kiếm/Xem danh sách". Hoặc bạn tách riêng 2 usecase ra, "Xem danh sách" Extend "Tìm kiếm" chứ actor ko trỏ thẳng vào "Tìm kiếm" (như mình giải thích ở cmm trên).

[vanduc0409]

- Fuctional Requirement là chức năng như đăng nhập, đăng xuất, Xem, Thêm, Xóa, Sửa...
- Feature dịch ra là tính năng, nhưng theo cách nhìn của mình thì nó là tập hợp các chức năng tác động vào 1 thông tin cụ thể. Ví dụ Quản lý thông tin Sinh viên là 1 feature, Quản lý thông tin Giáo viên là 1 feature. Trong đó có Xem danh sách, Thêm, Xem, Xóa, Sửa đều tác động vào thông tin Sinh viên hay tt Giáo viên.

Khi vào 1 cửa sổ quản lý 1 thông tin gì đó (như giao diện của mình) thì bạn luôn phải Xem danh sách, rồi sau đó muốn Thêm, Xem chi tiết, Xóa, Sửa sau đúng ko? Vậy thì Actor trỏ thẳng vào Xem danh sách.
Vậy bạn thử đặt trường hợp ngược lại, Actor trỏ thẳng vào Thêm. Vậy làm sao để chọn chức năng Thêm mà không Xem danh sách? Khi đó bạn suy nghĩ "Thêm" include "Xem danh sách"??? Nhưng thật ra là "Xem danh sách" Extend "Thêm". Có nghĩa là trong khi xem danh sách, bạn có thể Thêm hoặc ko Thêm.

Thanks bạn. :sogood::haha::haha:. Mình hiểu rồi.

[LMFAO]

Thanks bạn. :sogood::haha::haha:. Mình hiểu rồi.
Bạn xem cái đó là format để vẽ Usecase quản lý luôn nha. Hầu hết phần mềm, web đều theo format đó. Tiện cho việc tái sử dụng sau này, chỉ cần chỉnh sửa lại thôi.
Mà bạn đang học môn Requirement Engineering hả?

[vanduc0409]

Bạn xem cái đó là format để vẽ Usecase quản lý luôn nha. Hầu hết phần mềm, web đều theo format đó. Tiện cho việc tái sử dụng sau này, chỉ cần chỉnh sửa lại thôi.
Mà bạn đang học môn Requirement Engineering hả?

Mình cũng sẽ theo cái format đó. :sexy::sexy:
Uhm. mình đang học môn đó.Nhập môn công nghệ phân mềm. Mà mới bắt đầu học. Nhưng mình khác bạn. Môn đó chỉ là 1 môn trong số cái mình học. Còn hình như bạn tập trung hoàn toàn vào môn đó.

[LMFAO]

Mình cũng sẽ theo cái format đó. :sexy::sexy:
Uhm. mình đang học môn đó.Nhập môn công nghệ phân mềm. Mà mới bắt đầu học. Nhưng mình khác bạn. Môn đó chỉ là 1 môn trong số cái mình học. Còn hình như bạn tập trung hoàn toàn vào môn đó.

Đâu có chỗ nào nói mình hoàn toàn tập trung vào nó đâu :D. Mình học Software Engineering. Requirement Engineering mình học ở HK1 năm 2. Còn rất nhìu môn khác :)

[N.V.T]

Tập hợp các thao tác thêm, sửa, xóa là một chuỗi các hành động để thực hiện 1 công việc, vì vậy không nên tách chúng ra làm các User case khác nhau. Ví dụ như bài toán quản lý sinh viên thì các thao tác : thêm, sửa, xóa danh sách sinh viên được gộp trong User case "Quản lý SV".

[Harry-LK]

Nếu chủ thớt mà học tdque (PTIT) thì chủ thớt liên lạc mình để biết thêm chi tiết nhé
Nếu ko thì mình ko có ý kiến gì =))

[satthu.daumungmu]

Nếu chủ thớt mà học tdque (PTIT) thì chủ thớt liên lạc mình để biết thêm chi tiết nhé
Nếu ko thì mình ko có ý kiến gì =))

Nếu học tdque thì chia buồn với chủ thớt, cái định nghĩa include và extend nó sẽ thay đổi theo từng buổi học. Tự cầu phúc đi :))

[vanduc0409]

Đâu có chỗ nào nói mình hoàn toàn tập trung vào nó đâu :D. Mình học Software Engineering. Requirement Engineering mình học ở HK1 năm 2. Còn rất nhìu môn khác :)

Đó. Bạn học nói chung lại là công nghệ phần mềm. Require Engineering 1 kì, Software 1 kì. Bên mình thì là 1 môn có tất cả. :stick::stick:

Đã nộp bài và được 0đ. Bạn LMFAO ơi, bài bạn thầy mình nói sai hoàn toàn. Nếu viết như bạn thì bỏ hẳn phần sau luôn. tức là thêm sửa xóa vứt đi. Vì không có tương tác với actor. Hì. chắc mỗi thầy mỗi khác

[vanduc0409]

Nếu chủ thớt mà học tdque (PTIT) thì chủ thớt liên lạc mình để biết thêm chi tiết nhé
Nếu ko thì mình ko có ý kiến gì =))

Mình học PTIT đây. Add nick mình đi. Mình hỏi mấy cái nha bạn. van.duc0409:adore:

[LMFAO]

Đó. Bạn học nói chung lại là công nghệ phần mềm. Require Engineering 1 kì, Software 1 kì. Bên mình thì là 1 môn có tất cả. :stick::stick:
Đã nộp bài và được 0đ. Bạn LMFAO ơi, bài bạn thầy mình nói sai hoàn toàn. Nếu viết như bạn thì bỏ hẳn phần sau luôn. tức là thêm sửa xóa vứt đi. Vì không có tương tác với actor. Hì. chắc mỗi thầy mỗi khác
Chưa đủ post nên ko pm cho bạn được.
:) có lẽ yêu cầu bài tập của thầy của bạn khác. Bạn có thể search google với key "usecase diagram" và xem 5 hình đầu tiên kết quả search bạn sẽ thấy extend và include actor ko trỏ thẳng tới nó. Sẽ có trường hợp trỏ thẳng vào được nhưng không phải trong trường hợp quản lý thông tin như vậy. Bạn tìm hiểu thử xem :).

P/S: mà cũng xin lỗi đã làm bạn bị con 0 :D. Cố gắng lần sau nha bạn :D

[LMFAO]

Tập hợp các thao tác thêm, sửa, xóa là một chuỗi các hành động để thực hiện 1 công việc, vì vậy không nên tách chúng ra làm các User case khác nhau. Ví dụ như bài toán quản lý sinh viên thì các thao tác : thêm, sửa, xóa danh sách sinh viên được gộp trong User case "Quản lý SV".
Trước khi làm điều bạn nói thì bạn hãy xem mục đích viết Usecase ở đây là gì? Nếu là High level thì làm như bạn đúng rồi. Còn Low level (Detailed level) thì phải chi tiết đến Xem, Thêm, Xóa, Sửa.

[vanduc0409]

Chưa đủ post nên ko pm cho bạn được.
:) có lẽ yêu cầu bài tập của thầy của bạn khác. Bạn có thể search google với key "usecase diagram" và xem 5 hình đầu tiên kết quả search bạn sẽ thấy extend và include actor ko trỏ thẳng tới nó. Sẽ có trường hợp trỏ thẳng vào được nhưng không phải trong trường hợp quản lý thông tin như vậy. Bạn tìm hiểu thử xem :).

P/S: mà cũng xin lỗi đã làm bạn bị con 0 :D. Cố gắng lần sau nha bạn :D

Uhm. Chắc ý của thầy mình khác. Mình search rồi. Cũng thấy như bạn nói. Nhưng không hiểu sao thầy mình lại nói không được nhỉ. :stick::stick:

[Harry-LK]

Nói chung là include với extend khá là ko rõ ràng, ko có cái nào đúng cái nào sai, mà phải tùy thuộc vào thiết kế sao cho thế nào cho phù hợp nữa :D. Mình học PTTK 2,5 với thầy tdque năm mà quanh đi quẩn lại vẫn include + extend mà mãi mới hơi ngộ ngộ ra chút, nên bạn cứ yên tâm, ko phải xoắn XD

[Mmmphhh mmphh mph]

Các bác chỉ em vẽ cái boundary trên Rotional Rose với... Cai boundary là biên của hệ thống để phân biệt actor và use case đó các bác.
Sorry mod vì đào mộ nhưng em cần gấp quá. Google rồi mà ko ra.

[windsea]

hải Phong =)) Biết tôi ko

biết, chú đc chúng nó để ở chữ ký mấy câu phán thần thánh :gach: