Bạn đang xem bài viết Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả? được cập nhật mới nhất tháng 9 năm 2023 trên website Englishhouse.edu.vn. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất.
Ô kayyyy lét xờ gâuuuu 😎
Giả dụ trường hợp ở đây: Anh em đã có Use Case Diagram, đã capture được tổng quan các requirement theo góc nhìn của người dùng. Đó là thứ để chúng ta bỏ vào các document như FRD hoặc SRS.
Tuy nhiên, Use Case Diagram khá là chung chung để các stakeholders có cái nhìn trực quan về những requirements được mô tả. Do đó, anh em cần phải diễn đạt nó một cách chi tiết hơn nữa.
Use Case Specification, hay nói cách khác là ĐẶC TẢ USE CASE sẽ giúp anh em làm chuyện đó.
Đặc tả Use Case tồn tại dưới dạng một cái bảng ghi chú. Nó mô tả tất tần tật các thông tin về Use Case, giúp anh em đọc vào một phát là hiểu ngay Use Case Diagram nó vẽ vậy là ý gì.
Một cách tổng quan, Use Case Specification gồm 3 thành phần chính:
Use Case Name: Tên Use Case
Use Case ID: Mã Use Case
Use Case Description: Tóm gọn nhanh sự tương tác được thể hiện trong Use Case là gì.
Actor: Những đối tượng thực hiện sự tương tác trong Use Case.
Priority: Mức độ ưu tiên của Use Case so với các Use Case còn lại trong dự án.
Trigger: Điều kiện kích hoạt Use Case xảy ra.
Pre-Condition: Điều kiện cần để Use Case thực hiện thành công.
Post-Condition: Những thứ sẽ xuất hiện sau khi Use Case được thực hiện thành công.
Basic Flow: luồng tương tác CHÍNH giữa các Actor và System để Use Case thực hiện thành công.
Alternative Flow: luồng tương tác THAY THẾ giữa các Actor và System để Use Case thực hiện thành công.
Exception Flow: luồng tương tác giữa các Actor và System mà Use Case thực hiện thất bại.
Business Rule: các quy định về mặt Business mà hệ thống bắt buộc phải nghe theo, làm theo.
Non-Funtional Requirement: Vì Use Case chỉ dùng để thể hiện Functional Requirement, nên anh em phải bổ sung các yêu cầu về Non-Functional ở đây luôn.
…………………………………………………………………..
Một số thông tin bổ sung thêm cho anh em.
Use Case Description chỉ cần mô tả ngắn gọn theo cú pháp của User Story: Là “Actor”, tui muốn làm “Use Case Name”, để đạt được “mục đích – lý do” gì đó. Đẹp là không quá 3 dòng cho phần tóm gọn Use Case này.
Ví dụ đối với diễn đàn Medium đi chẳng hạn. Chúng ta sẽ vẽ Use Case Diagram và viết đặc tả Use Case cho phân hệ quản lý xác thực người dùng như sau.
USE CASE SPECIFICATION
Pre-Condition(s):
Tài khoản người dùng đã được tạo sẵn
Tài khoản người dùng đã được phân quyền
Thiết bị của người dùng đã được kết nối internet khi thực hiện đăng nhập
Post-Condition(s):
Người dùng đăng nhập ứng dụng thành công
Hệ thống ghi nhận hoạt động đăng nhập thành công vào Activity Log.
Basic Flow1. Người dùng truy cập ứng dụng Medium.
2. Người dùng chọn phương thức đăng nhập bằng tài khoản Medium
3. Người dùng nhập tài khoản Medium và chọn lệnh đăng nhập
4. Hệ thống xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng
5. Hệ thống ghi nhận hoạt động đăng nhập thành công vào Activity Log.
Alternative Flow2a. Người dùng chọn phương thức đăng nhập bằng tài khoản Gmail
2a1. Hệ thống chuyển sang màn hình đăng nhập của Google
3a. Người dùng nhập tài khoản Google và chọn lệnh đăng nhập
4a. Google xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng
Use Case tiếp tục bước 5.
2b. Người dùng chọn phương thức đăng nhập bằng tài khoản Facebook
2b1. Hệ thống chuyển sang màn hình đăng nhập của Facebook
3b. Người dùng nhập tài khoản Facebook và chọn lệnh đăng nhập
4b. Facebook xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng
Use Case tiếp tục bước 5. Exception Flow
4c. Hệ thống xác thực thông tin đăng nhập không thành công và hiển thị thông báo.
4c1. Người dùng chọn lệnh hủy đăng nhập.Use Case dừng lại.
4c2. Người dùng chọn lệnh lấy lại mật khẩuUse Case tiếp tục Use Case UC1-3
4c3. Người dùng chọn lệnh khóa tài khoảnUse Case tiếp tục Use Case UC1-4
Non-Functional RequirementNFR1.1-1: Time out cho màn hình đăng nhập dưới 60 giây.
NFR1.1-2: Mật khẩu của người dùng phải được hash bằng MD5.
Đó là đặc tả Use Case. Hi vọng ví dụ này đủ để anh em hình dung, mường tượng ra được chân tay mặt mũi của Use Case Specification.
Anh em có thể làm một Use Case Specification cho một Use Case (tức một hình Oval). Vậy ở ví dụ trên thì anh em sẽ có 1 sơ đồ Use Case Digram, gồm 5 Use Case, thì sẽ ứng với 5 Use Case Specification.
Tuy nhiên, có thể anh em sẽ thấy confuse ở một số chỗ…
Thường khi làm đặc tả Use Case mình sẽ rất dễ bị nhầm lẫn ở hai chỗ:
Trigger và Pre-Condition
Alternative Flow và Exception Flow.
4.1. Trigger và Pre-ConditionTrigger nghĩa là một thứ gì đó để kích hoạt cho Use Case chạy, khởi xướng cho Use Case chạy. Còn Pre-Condition nghĩa là một thứ gì đó, mà phải có nó thì Use Case mới chạy được.
Use Case có thể có Pre-Condition hoặc không, nhưng Trigger thì thường phải có.
Ví dụ Use Case rút tiền tại máy ATM.
Tức Use Case chỉ xảy ra khi ông khách hàng này ổng thực hiện lệnh rút tiền. Cụ thể thì có thể là ổng bấm cái nút “Rút tiền” trên màn hình. Đó là trigger để Use Case xảy ra.
Còn Pre-Condition là các điều kiện cần phải có để ông này ổng rút tiền thành công. Vì ổng không thể nào rút tiền được nếu trong tài khoản không còn tiện hoặc ổng chưa đút thẻ vô máy.
Hoặc Output (hoặc Post-Condition) của Use Case này có thể là trigger của Use Case khác.
Cũng ở ví dụ rút tiền tại máy ATM bên trên, Post-Condition ở đây có thể là:
Khách hàng nhận được tiền mặt sau khi thực hiện rút tiền.
Số dư của khách hàng đã bị trừ đi khoảng tiền đã rút.
Nếu những post-conditions này xảy ra thì Use Case: Rút tiền tại máy ATM đã được thực hiện xong. Và đồng thời nó cũng là trigger cho Use Case tiếp theo: Gửi tin nhắn SMS thông báo cho khách hàng.
…
Để phân biệt rõ hơn giữa Trigger và Pre-Condition thì anh em cứ tưởng tượng như thế này…
Trong giải điền kinh xóm chiếu mở rộng, ông Tèo là trọng tài, ông Tủn là vận động viên thi đấu. Cả 2 ông này đều là Actor. Một ông là Actor ở vai trò trọng tài, còn một ông là Actor ở vai trò vận động viên tham dự.
Use Case thì thể hiện sự tương tác của Actor trong một môi trường/ phạm vi cụ thể nào đó. Vậy ở đây, Use Case thể hiện sự tương tác chạy đua trong một giải điền kinh, mà cả Actor trọng tài và Actor vận động viên đều tham gia vào.
Vậy thì đâu là Trigger, và đâu là Pre-Condition?
Trigger chính là cò nổ của ông Tèo trọng tài. Ổng giơ súng lên trời, bắn cái đùng, là ông Tủn vận động viên bắt đầu chạy. Hay nói cách khác, khi cò nổ, thì là lúc Use Case bắt đầu.
Còn Pre-Condition là những điều kiện tiên quyết mà ông Tủn phải ô kê hết thì mới cho ổng tham dự giải đấu, ví dụ:
Ví dụ vậy, không đạt được những điều kiện này, ông Tủn không được phép tham gia chạy ở giải điền kinh xóm chiếu mở rộng. Hay nói cách khác, không đạt được những điều kiện này, Use Case sẽ không được thực hiện thành công.
Đó là sự khác biệt giữa Trigger và Pre-Condition.
Tuy nhiên thực tế thì anh em cũng không cần quá quan tâm vấn đề này làm gì. Trigger trong Use Case có thể là bất kỳ thứ gì, có thể là tác động từ phía người dùng, hoặc tác động từ chính hệ thống. Miễn nó thể hiện được hình ảnh cò nổ để Use Case chạy là được.
4.2. Alternative Flow và Exception FlowFlow là các luồng tương tác giữa các Actor và hệ thống với nhau. Basic Flow là luồng tương tác chính, là happy case đơn giản nhất có thể xảy ra.
Ví dụ chạy từ Quận 1 ra Quận 7 thì cứ men theo Cách Mạng Tháng 8 ra Hoàng Diệu, rồi cứ cắm đầu Nguyễn Văn Linh là ra. Đó chính là Basic Flow, là đường ngắn nhất, cơ bản nhất.
Nhưng thực tế còn rất nhiều đường khác mà anh em có thể đi: như quẹo qua Quận 8, đi Võ Văn Kiệt, Phạm Thế Hiển…. Hoặc thậm chí đi giữa đường xe bị lủng bánh, không có chỗ vá, phải dắt bộ ngược zề, và không qua được Quận 7 nữa, chuyến đi thất bại.
Những trường hợp đó mình sẽ gom hết lại, và quy nó thành Alternative Flow hoặc Exception Flow. Cụ thể:
Alternative Flow: những hướng khác giúp anh em đi từ Quận 1 tới Quận 7 thành công, như các tuyến đường khác chẳng hạn.
Exception Flow: những trường hợp mà nó ngăn chặn, khiến cho anh em không qua Quận 7 được, làm kế hoạch qua Quận 7 mình bị thất bại, như: lủng xe, hết xăng, bị công an giam xe…
Vậy xét qua lăng kính Use Case, đặc tính của 3 luồng tương tác này như sau:
…
Ví dụ trong mô hình quản lý e-Learning, anh em có một Use Case: Hủy kích hoạt tài khoản học viên chẳng hạn. Use Case này sẽ có các Flow như sau.
Admin mở tài khoản học viên cần hủy kích hoạt
Hệ thống hiển thị màn hình thông tin học viên
Admin chọn lệnh hủy kích hoạt
Hệ thống yêu cầu nhập mã OTP để xác nhận
Admin nhập đúng mã OTP để xác nhận lệnh hủy kích hoạt
Hệ thống kiểm tra mã OTP và tiến hành hủy kích hoạt
Hệ thống hiển thị thông báo đã hủy kích hoạt.
1a. Admin chọn học viên cần hủy kích hoạt ở lưới học viên.Use Case tiếp tục bước 3.
4a. Admin chọn phương thức xác nhận khác: Xác nhận qua reCaptcha
4a1. Hệ thống hiển thị mã reCaptcha và yêu cầu nhập mã reCaptcha để xác nhận
5a. Admin nhập đúng mã reCaptcha để xác nhận lệnh hủy kích hoạt
6a. Hệ thống kiểm tra mã reCaptcha và tiến hành hủy kích hoạtUse Case tiếp tục bước 7.
5b. Admin nhập sai mã reCaptcha.
5b1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.Use Case dừng lại.
5c. Admin nhập sai mã OTP.
5c1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.Use Case dừng lại.
Đối với luồng chính (Basic Flow), anh em sẽ đánh số thứ tự xuất hiện 1, 2, 3, 4, 5…., theo số nguyên. Còn đối với Alternative hay Exception Flow, anh em nên thêm các ký tự chữ cái a, b, c, d… bên cạnh để làm dấu cho dễ phân biệt.
Và để dễ hình dung và quản lý các steps có trong flow hơn, mình sẽ bonus thêm cho anh em phần sau đây, kaka 😎
4.3. Bonus: Mô tả Flow sao cho ngầuMình cá là 69% anh em lần đầu viết flow cho use case sẽ thấy hơi… rối bời, và không biết tổ chức các steps sao cho logic hết.
Để giải quyết vấn đề này, hãy vẽ nó. Một lần nữa, việc vẽ lên ngôi.
Dùng chữ khó quá thì chúng ta phải dùng hình. Anh em sẽ thể hiện Basic Flow, Alternative Flow và Exception Flow kèm hình vẽ như sau.
BASIC FLOW
1. Admin mở tài khoản học viên cần hủy kích hoạt
2. Hệ thống hiển thị màn hình thông tin học viên
3. Admin chọn lệnh hủy kích hoạt
4. Hệ thống yêu cầu nhập mã OTP để xác nhận
5. Admin nhập đúng mã OTP để xác nhận lệnh hủy kích hoạt
6. Hệ thống kiểm tra mã OTP và tiến hành hủy kích hoạt
7. Hệ thống hiển thị thông báo đã hủy kích hoạt.
ALTERNATIVE FLOW
1a. Admin chọn học viên cần hủy kích hoạt ở lưới học viên.Use Case tiếp tục bước 3.
4a. Admin chọn phương thức xác nhận khác: Xác nhận qua reCaptcha
4a1. Hệ thống hiển thị mã reCaptcha và yêu cầu nhập mã reCaptcha để xác nhận
5a. Admin nhập đúng mã reCaptcha để xác nhận lệnh hủy kích hoạt
6a. Hệ thống kiểm tra mã reCaptcha và tiến hành hủy kích hoạtUse Case tiếp tục bước 7.
EXCEPTION FLOW
5b. Admin nhập sai mã reCaptcha.
5b1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.Use Case dừng lại.
5c. Admin nhập sai mã OTP.
5c1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.Use Case dừng lại.
Đó là những gì mình dùng để mô tả Flow, một cách rõ ràng, logic và sáng sủa nhất có thể.
Các step ở Basic Flow, Alternative Flow hay Exception Flow nó đều đối xứng với nhau, thể hiện rõ thằng nào là thay thế của thằng nào, và thằng nào là Exception của thằng nào.
Riêng luồng tương tác nào Exception thì anh em để dạng nét đứt cho dễ phân biệt.
Các step bắt đầu (có thể là Trigger hoặc không) và kết thúc anh em hãy tô màu đen, để các Stakeholder có thể nắm được độ phức tạp của Use Case một cách nhanh nhất.
Còn đối với các Exception Flow – những flow làm fail Use Case, anh em hãy tô đỏ các step cuối cùng mà Use Case xảy ra không thành công (chẳng hạn step 5b1 hoặc 5c1).
.
.
.
TÓM GỌN
Đặc tả Use Case về bản chất rất đơn giản vì nó mang ngôn ngữ tự nhiên của người dùng. Vấn đề chỉ nằm ở một số điểm hay nhầm lẫn và cách chúng ta tổ chức các Use Case như thế nào cho logic và hiệu quả mà thôi 🙂
Mình sẽ tóm gọn giá trị của Use Case (cả Diagram và Specification) qua 2 bài notes về Use Case như sau:
Use Case giúp anh em thể hiện được rõ Requirement theo góc nhìn của người dùng cuối (rất quan trọng, vì nó giúp mình hiểu rõ bản chất vấn đề hơn).
Theo đó, những gì được thể hiện trong Use Case rất tự nhiên, ai đọc vô cũng hiểu hết trơn.
Use Case có thể chia nhỏ phạm vi theo nhiều phân hệ, hoặc cụm tính năng. Và nó cũng có thể nhìn dưới góc độ high-level. Do đó, dễ hơn cho mình rất nhiều để cover đủ các yêu cầu trong một dự án lớn.
Use Case là bước đệm tuyệt vời giữa việc mô tả tổng quát và mô tả chi tiết sự tương tác thông qua Sequence Diagram (con nhà UML).
Use Case được dùng để tạo các Epic, và các User Stories trong dự án Scrum, làm mọi thứ được nhất quán và rất chặt chẽ.
Use Case còn được dùng để tạo các Test Case sau này.
…
Bái bai và hẹn gặp lại 😎
Đặc Tả Sơ Đồ Use Case Quản Lý Khách Sạn
1. Khái niệm use case quản lý khách sạn
Use case là một kỹ thuật được dùng trong kỹ thuật phần mềm của hệ thống quản lý khách sạn nhằm nắm bắt yêu cầu chức năng của hệ thống. Nó mô tả các thao tác đặc trưng từ người dùng bên ngoài (actor) vào hệ thống.
2. Mô hình sơ đồ use case quản lý khách sạna. Tại Bộ phận Lễ tân
b. Tại Bộ phận Kế toán
c. Tại Bộ phận Kinh doanh
d. Tại Bộ phận Nhân sự
3. Đặc tả use case quản lý khách sạna. Use case quản lý đăng nhập
+ Hệ thống yêu cầu actor cung cấp thông tin đăng nhập gồm tên đăng nhập và mật khẩu.
+ Hệ thống check lại thông tin đăng nhập và thông báo thành công/thất bại cho actor. Nếu đăng nhập thành công hệ thống dựa trên thông tin đăng nhập sẽ đồng thời phân quyền tùy theo loại nhân viên. Nếu đăng nhập thất bại, hệ thống sẽ hiện thông báo cho người dùng và yêu cầu đăng nhập lại.
b. Use case Đăng xuất
+ Actor thực hiện chức năng đăng xuất khỏi hệ thống.
+ Hệ thống hiển thị yêu cầu xác nhận từ actor
+ Actor dùng xác nhận đăng xuất
+ Hệ thống đăng xuất tài khoản actor khỏi hệ thống. Nếu Actor không xác nhận đăng xuất thì hệ thống sẽ giữ nguyên hiện trạng.
c. Use case Đặt phòng
+ Bộ phận Lễ tân đăng nhập vào hệ thống
+ Chọn chức năng đặt phòng cho khách hàng
+ Hệ thống hiển thị form yêu cầu nhập thông tin khách hàng và ngày nhận phòng. Bao gồm: Số CMND; Họ tên; Địa chỉ; SĐT.
+ Bộ phận lễ tân nhập thông tin và ngày nhận phòng của khách đầy đủ theo form
+ Hệ thống tự động kiểm tra thông tin phòng ngày mà khách hàng yêu cầu, đồng thời lọc danh sách các loại phòng và các phòng tương ứng mà khách hàng có thể thuê vào ngày đó.
TH1: Còn loại phòng mà khách hàng yêu cầu:
+ Lễ tân chọn phòng theo yêu cầu của khách hàng đã đặt.
+ Hệ thống kiểm tra dữ liệu lễ tân vừa nhập và lưu lại thông tin đặt phòng của khách. Nếu thông tin khách hàng đã tồn tại trong hệ thống thì sẽ không lưu thông tin khách hàng nữa mà chỉ lưu thông tin đặt phòng.
TH2: Loại phòng mà khách hàng yêu cầu đã hết phòng trống:
+ Hệ thống sẽ báo hết loại phòng đã chọn và cảnh báo để yêu cầu chọn loại phòng khác.
+ Lễ tân sẽ thông báo cho khách và tiếp tục tìm kiếm loại phòng khác hoặc thời gian khác nếu khách hàng yêu cầu. Nếu khách hàng không còn nhu cầu thực hiện hủy phiếu đăng ký.
+ Hệ thống thông báo và yêu cầu thực hiện lại.
d. Use case kiểm tra tình trạng phòng
+ Actor đăng nhập vào hệ thống
+ Actor chọn chức năng “Đặt phòng” hoặc “Thuê phòng” với một phòng.
+ Hệ thống sẽ tìm kiếm thông tin phòng dựa vào mã phòng và phản hổi lại tình trạng hiện tại của phòng (đang ở, đã được đặt trước hoặc còn trống)
+ Kết thúc use case
e. Use case tìm thông tin đặt phòng
+ Lễ tân thực hiện chức năng đăng ký phòng đặt trước, chọn chức năng “Tìm thông tin đặt phòng”
+ Lễ tân nhập số CMND của khách hàng để tiến hành tìm thông tin đặt phòng.
+ Hệ thống tìm kiếm thông tin đặt phòng của khách hàng và trả về kết quả
f. Use case Lập phiếu dịch vụ
+ Bộ phận lễ tân đăng nhập hệ thống và chọn chức năng lập phiếu dịch vụ.
+ Hệ thống sẽ tạo ra phiếu dịch vụ ứng với thông tin nhận phòng tương ứng và hiển thị thông tin ra để lễ tân xem, đồng thời yêu cầu lễ tân chọn các dịch vụ mà khách hàng yêu cầu.
+ Hệ thống lưu lại phiếu sử dụng dịch vụ, đồng thời lưu thông tin chi tiết xuống “Chi tiết phiếu dịch vụ”.
+ Kết thúc Use case.
+ Lưu thông tin phiếu sử dụng dịch vụ của khách hàng vào hệ thống nếu use case thực hiện thành công.
g. Use case Thống kê doanh thu
+ Nhân viên kế toán đăng nhập hệ thống và chọn nút “Thống kê”
+ Hệ thống hiển thị menu thống kê: theo ngày, theo tháng, theo quý, theo năm.
+ Nhân viên kế toán chọn một trong các mục.
+ Hệ thống sẽ thống kê và in ra giấy.
Bản Vẽ Use Case (Use Case Diagram)
Trong bài trước chúng ta đã biết vai trò của bản vẽ Use Case là rất quan trọng, nó giúp chúng ta hiểu yêu cầu, kiến trúc chức năng của hệ thống và chi phối tất cả các bản vẽ còn lại. Trong bài này chúng ta sẽ tìm hiểu về các thành phần cấu tạo nên bản vẽ này, cách xây dựng và sử dụng nó.
1. Các thành phần trong bản vẽ Use CaseĐầu tiên, chúng ta xem một ví dụ về Use Case Diagarm.
Bây giờ chúng ta sẽ tìm hiểu kỹ hơn về các thành phần của bản vẽ.
1.1 ActorActor được dùng để chỉ người sử dụng hoặc một đối tượng nào đó bên ngoài tương tác với hệ thống chúng ta đang xem xét. Lưu ý, chúng ta hay bỏ quên đối tượng tương tác với hệ thống, ví dụ như Bank ở trên.
Actor được biểu diễn như sau:
Use Case là chức năng mà các Actor sẽ sử dụng. Nó được ký hiệu như sau:
1.3 Relationship(Quan hệ)Relationship hay còn gọi là conntector được sử dụng để kết nối giữa các đối tượng với nhau tạo nên bản vẽ Use Case. Có các kiểu quan hệ cơ bản sau:
– Association
– Generalization
– Include
– Extend
1.4 System BoundarySystem Boundary được sử dụng để xác định phạm vi của hệ thống mà chúng ta đang thiết kế. Các đối tượng nằm ngoài hệ thống này có tương tác với hệ thống được xem là các Actor.
2. Các bước xây dựng Use Case DiagramChúng ta đã nắm được các ký hiệu của bản vẽ Use Case, bây giờ là lúc chúng ta tìm cách lắp chúng lại để tạo nên bản vẽ hoàn chỉnh. Thực hiện các bước sau để xây dựng một bản vẽ Use Case:
+ Bước 1: Tìm các Actor
Trả lời các câu hỏi sau để xác định Actor cho hệ thống:
– Ai sử dụng hệ thống này?
– Hệ thống nào tương tác với hệ thống này?
Xem xét ví dụ về ATM ở trên chúng ta thấy:
Như vậy có 03 Actor: Customer, ATM Technician và Bank
+ Bước 2: Tìm các Actor
Trả lời câu hỏi các Actor sử dụng chức năng gì trong hệ thống? chúng ta sẽ xác định được các Use Case cần thiết cho hệ thống.
Xem xét ví dụ ở trên ta thấy:
Customer sử dụng các chức năng: Check Balance, Deposit, Withdraw và Transfer
ATM technician sử dụng: Maintenance và Repair
Bank tương tác với tất cả các chức năng trên.
Tóm lại, chúng ta phải xây dựng hệ thống có các chức năng: Check Balance, Deposit, Withdraw, Transfer, Maintenance và Repair để đáp ứng được cho người sử dụng và các hệ thống tương tác.
+ Bước 3: Xác định các quan hệ
Phân tích và các định các quan loại hệ giữa các Actor và Use Case, giữa các Actor với nhau, giữa các Use Case với nhau sau đó nối chúng lại chúng ta sẽ được bản vẽ Use Case.
Nhìn vào bản vẽ trên chúng ta nhận biết hệ thống cần những chức năng gì và ai sử dụng. Tuy nhiên, chúng ta chưa biết được chúng vận hành ra sao? Sử dụng chúng như thế nào? Để hiểu rõ hơn hệ thống chúng ta cần phải đặc tả các Use Case.
Có 2 cách để đặc tả Use Case.
Cách 1: Viết đặc tả cho các Use Case
Chúng ta có thể viết đặc tả Use Case theo mẫu sau:
Tên Use Case
Mã số Use Case
Mô tả tóm tắt// Hiển thị thông tin chi tiết của Account
Các bước thực hiện
Điều kiện thoát
Yêu cầu đặc biệt// Ghi rõ nếu có
Yêu cầu trước khi thực hiện// Phải đăng nhập
Điều kiện sau khi thực hiện
Cách 2: Sử dụng các bản vẽ để đặc tả
Chúng ta có thể dùng các bản vẽ như Activity Diagram, Sequence Diagram để đặc tả Use case. Các bản vẽ này chúng ta sẽ bàn ở những bài tiếp theo.
4. Sử dụng UseCase Diagram– Phân tích và hiểu hệ thống
– Thiết kế hệ thống.
– Làm cơ sở cho việc phát triển, kiểm tra các bản vẽ như Class Diagram, Activity Diagram, Sequence Diagram, Component Diagram.
– Làm cơ sở để giao tiếp với khách hàng, các nhà đầu tư.
– Giúp cho việc kiểm thử chức năng, kiểm thử chấp nhận.
5. Kết luậnĐến đây, chúng ta đã tìm hiểu được bản vẽ đầu tiên và rất quan trọng (use case diagram), các bạn cần tiếp tục thực hành để nắm rõ hơn về bản vẽ này cũng như cách xây dựng và sử dụng chúng trong quá trình phát triển sản phẩm phần mềm.
Để giúp các bạn hiểu rõ hơn về bản vẽ Use Case trong bài tiếp theo chúng ta sẽ thực hiện qua từng bước bài thực hành xây dựng Use Case Diagram.
Bài tiếp: Thực hành xây dựng bản vẽ Use Case
Bài trước: Cơ bản về phân tích và thiết kế hướng đối tượng
Tại Sao Phải Có Use Case Diagram Trong Uml
Nhìn vào hình ảnh sau đây ắt hẳn các bạn có thể thấy một phần chính mình trong đó. Những thứ ngớ ngẩn ấy tưởng chừng không thể xảy ra nhưng nó vẫn chực chờ xuất hiện trong những hiểu lầm của team dev và khách hàng. Vì thế Usecase Diagram sinh ra để phần nào giải quyết vấn đề ấy.
Usecase Diagram là gì?Usecase Diagram được hiểu là sơ đồ tính năng của sản phẩm cung cấp cho người dùng. Bản vẽ này sẽ cho người dùng hiểu được sản phẩm này cung cấp những tính năng gì cho người dùng, hoặc người dùng có thể làm được gì với nó.
ActorActor trong UML được thể hiện bởi một stickman. Để chỉ một người nào đó tương tác với phần mềm (lấy ví dụ bạn là người ấn vào các nút trên remote, bạn là một actor).
Lưu ý: Actor không phải là một thành phần của phần mềm.
UsecaseUsecase là các chức năng của phần mềm được actor sử dụng (giống như các nút bấm trên remote điều hòa)
Quan hệ AssociationThường dùng để chỉ mối quan hệ giữa Actor với Use Case hoặc giữa các Use Case với nhau.
GeneralizationLà quan hệ kế thừa, chỉ quan hệ giữa đối tượng con với đối tượng cha (thường dùng cho Actor)
“Con to hơn cha (về khả năng) vì thế con làm đc tất cả cha làm và hơn thế nữa”Ví dụ: Trong trang chúng tôi Contributor cũng là một User, có thể làm các việc như đăng nhập, học tập, codewar,… ngoài ra còn có thể đăng bài luyện tập, đăng blog,…
IncludeThường dùng giữa các Use Case. Nó mô tả việc một Use Case lớn được chia ra thành các Use Case nhỏ để dễ cài đặt (module hóa) hoặc thể hiện sự dùng lại.
Trong Include, hành động ở đuôi mũi tên (verify captcha) phải được hoàn thành trước khi thực hiện hành động ở đầu mũi tên (login)
ExtendExtend dùng để mô tả quan hệ giữa 2 Use Case. Quan hệ Extend được sử dụng khi có một Use Case được tạo ra để bổ sung chức năng cho một Use Case có sẵn và được sử dụng trong một điều kiện nhất định nào đó.
Trong Extend, hành động có thể có hoặc có thể không thực hiện cũng được.
Extension point: dùng để ghi chú khi nào hành động trong quan hệ Extend được thực hiện.
System BoundaryĐược hiểu đơn giản là đường biên, được sử dụng để xác định phạm vi của thiết kế. Các đối tượng nằm ngoài phạm vi này có tương tác với phần mềm có thể được xem là Actor.
Quay lại ví dụ về cái remote cho dễ hiểu, bạn chỉ có thể bấm vào các nút nằm trong remote thôi. Nếu bạn bấm vào tường rồi yêu cầu điều hòa thực hiện một chức năng thì điều đó thật vô lý.
Ứng dụngThiết kế hệ thống.
Làm cơ sở cho việc phát triển, kiểm tra các bản vẽ như Class Diagram, Activity Diagram, Sequence Diagram, Component Diagram.
Làm cơ sở để giao tiếp với khách hàng.
Hỗ trợ việc kiểm thử tính năng, chất lượng,….
Tạm kếtĐón xem kỳ sau: Thực hiện vẽ một Use Case Diagram với Star UML
Vẽ Use Case Diagram Với Star Uml
Trước hết, để phân tích hệ thống trên bạn phải có kiến thức về hệ thống thương mại điện tử, chúng ta có thể tìm hiểu thông qua các nguồn sau:
– Xem qua các forum
– Xem các hệ thống mẫu
– Hỏi những người chuyên về lĩnh vực này
Lưu ý: Bạn không thể thiết kế tốt được nếu bạn không có kiến thức về lĩnh vực của sản phẩm mà bạn sẽ xây dựng.
Bước 2: Xác định các ActorBạn hãy trả lời cho câu hỏi “Ai sử dụng hệ thống này?”
Xem xét Website chúng ta nhận thấy:
– Những người chỉ vào để đọc bài viết. Những người này là Người xem (Guest).
Về phía quản trị forum, có những người sau đây tham gia vào hệ thống:
Tiếp theo chúng ta trả lời câu hỏi “Hệ thống nào tương tác với hệ thống này?”
Ví dụ chúng ta sử dụng Facebook, Gmail để thực hiện chức năng Login thì chúng ta sẽ có các Actor tương ứng tương tác với hệ thống
Như vậy, chúng ta đã có các Actor của hệ thống gồm: Guest, Member, Mod, S-mod, Admin, Facebook, Google
Bạn cần khảo sát và phân tích thêm cũng như hỏi trực tiếp khách hàng để xác định đầy đủ các Actor cho hệ thống.
Bước 3: Xác định Use CaseBạn cần trả lời câu hỏi “Actor sử dụng chức năng gì trên hệ thống?”.
Trước tiên, xem xét với Actor ” Guest ” trên trang chúng tôi để xem họ sử dụng chức năng nào?
– Xem trang chủ
– Xem bài viết
– Tìm kiếm bài viết
– Đăng ký tài khoản để trở thành Member
– …….
Tiếp theo, xem xét Actor ” Member ” và nhận thấy họ sử dụng chức năng:
– Đăng nhập
– Đăng bài
– …
Tương tự như vậy bạn xác định chức năng cho các Actor còn lại.
Bước 4: Vẽ bản vẽ Use CaseTrước hết chúng ta xem xét và phân tích các chức năng của “Guest” chúng ta nhận thấy.Chức năng tìm kiếm bài viết sẽ bao gồm chức năng xem những bài viết đã tìm kiếm ấy. Tuy nhiên chức năng xem bài viết vẫn là một chức năng độc lập. Vì thế mình nối Association vào cả 2. Và đặt mối quan hệ Extend cho chúng.
Đặt lại tên cho gọn và xác định các mối quan hệ của chúng, chúng ta có thể vẽ Use Case Diagram cho Actor này như sau:
Thay vì nối tất cả như thế sẽ rất rối mắt. “Member” có tất cả Use Case của “Guest”, có thể xem “Member” là con của “Guest”, vì thế ta có thể sử dụng quan hệ kế thừa. Chúng ta sẽ tối giản sơ đồ như ảnh dưới:
Đỡ đau mắt hơn rồi đúng không nào?
Kết luậnNhư vậy, chúng ta đã hoàn thành bản vẽ Use Case cho trang web CForum. Hy vọng, các bạn có thể hiểu và sử dụng bản vẽ này trong việc phân tích hệ thống một cách hiệu quả.
Tips: Nếu phần mềm của bạn được xây dựng theo mô hình Agile/Scrum, các bạn đã có trong tay Use Story rồi thì việc chuyển chúng thành Use Case sẽ dễ như trở bàn tay.
11 Cách Xả Stress Đơn Giản Nhưng Rất Hiệu Quả
Biết cách xả stress hiệu quả có thể giúp bạn tránh những ảnh hưởng tiêu cực đến sức khỏe và cuộc sống của bạn.
Thống kê gần đây của Tổ chức lao động quốc tế (ILO) đã cho thấy một con số đáng giật mình: khoảng 20% dân số thế giới đang bị căng thẳng (stress) quá mức trong công việc. Tổ chức Y tế Thế giới (WHO) cũng đã khẳng định stress đang là mối đe dọa lớn nhất cho sức khỏe cộng đồng trong thế kỷ 21. Còn tại Việt Nam, theo một nghiên cứu khác, tỷ lệ bình quân số người bị stress trên cả nước là hơn 52%. Có vô số lí do dẫn đến stress: kinh tế phát triển, áp lực công việc ngày càng cao, môi trường làm việc ngày càng trở nên phức tạp và căng thẳng, áp lực của cuộc sống và của bản thân là quá lớn… Từ đây, stress có cơ hội xuất hiện và đang dần trở thành nỗi ám ảnh của cuộc sống hiện đại.
Hiểu rằng có lúc bạn cũng nên nói lời từ chối
Chúng ta thường cảm thấy mình có trách nhiệm phải nói “Có” với mọi người khi chúng ta được đề nghị giúp đỡ. Hãy nhớ rằng, bạn không thể làm tất cả mọi thứ cho tất cả mọi người. Trước tiên bạn phải đáp ứng nhu cầu của riêng bạn trước khi bạn thực sự có thể cung cấp cho người khác những gì họ cần.
Ngừng than vãn
Than vãn sẽ không mang lại điều gì tốt hơn cho những vấn đề hiện tại của bạn, tiêu hao năng lượng và thời gian cho “công việc” này quả là lãng phí. Ngừng than vãn cũng là cách xả stress giúp bạn bớt suy nghĩ, từ đây có thể giúp bạn vui vẻ và lạc quan hơn.
Chuyển màn hình
Hãy dành cho bản thân khoảng 5 phút chuyển màn hình máy tính từ những con số loằng ngoằng, vô số những email cần giải quyết gấp sang 1 clip hài hoặc 1 bài hát yêu thích nào đó. 5 phút thật sự không tốn quá nhiều thời gian của bạn đâu, mà ngược lại, nó có thể giúp bạn “tăng năng suất” sau khi đã xả được stress đấy!
Nhai kẹo cao su
Các nhà nghiên cứu đã chỉ ra rằng hoạt động nhai của miệng sẽ có tác động đẩy máu lên não, giúp chúng ta tỉnh táo và vui vẻ hơn, tạm thời giúp quên đi những lo lắng, phiền muộn.
Tập hít thở, tập cười
Nghe qua có vẻ hơi vô lí, bởi vì ngay cả những đứa trẻ cũng có thể làm được điều này, nhưng trên thực tế việc hít thở sâu, đều đặn, cười nhiều hơn mỗi ngày là điều không phải ai cũng làm được. Hơn thế nữa, những bài tập đơn giản này lại cách xả stress hiệu quả trong công việc.
Sử dụng liệu pháp mùi hương
Mùi hương có thể giúp ích rất nhiều trong việc xả stress. Hãy thử sử dụng năm hoặc sáu giọt tinh dầu hoa oải hương, hương chanh, hoàng lan hoặc hoa phong lữ thảo trong một bồn tắm ấm, hoặc đặt hai hoặc ba giọt lên một miếng vải và thỉnh thoảng hít vào trong ngày. Bạn cũng có thể sử dụng một vài giọt trên gối để giúp ngủ ngon hơn.
Bày tỏ thái độ biết ơn
Cho dù bạn biết ơn một ngày nắng đẹp hay biết ơn vì bạn đã đến nơi làm việc một cách an toàn, hãy nghĩ về tất cả những điều tốt đẹp bạn có trong cuộc sống. Lòng biết ơn sẽ nhắc nhở bạn về những nguồn lực bạn có để đối phó với căng thăng. Nhiều nghiên cứu cho thấy những người có thái độ biết ơn, nghĩ về những điều tích cực có sức khỏe tinh thần tốt hơn, giảm căng thẳng và chất lượng cuộc sống tốt hơn.
Mát xa
Mọi người đều thích massage và bạn có biết rằng nó đã được xem như một liều thuốc giảm đau trong hàng ngàn năm. Người xưa đã sử dụng massage để đả thông kinh mạch nhằm cải thiện sức khỏe. Ngày nay, chúng ta sử dụng massage để thư giãn các cơ bắp căng thẳng, giảm đau và cải thiên lưu thông máu, tất cả có thể làm nên điều kỳ diệu cho tâm trí.
Cung cấp vitamin B
Vitamin B được biết đến là một dưỡng chất giúp thúc đẩy hoạt động não và hệ thần kinh cũng như giúp thư giãn và chống mệt mỏi. Trên thực tế, dấu hiệu thiếu vitamin B bao gồm khó chịu, trầm cảm và thờ ơ, vì vậy để loại bỏ các triệu chứng đó, hãy tăng lượng thức ăn giàu vitamin B. Vitamin B thường được tìm thấy trong các loại rau mầm và ngũ cốc, đậu, đậu, các loại hạt, gan, trứng và các sản phẩm từ sữa.
Thỉnh thoảng hãy là một “đứa trẻ”
Hãy làm những gì bạn thích như khi còn là một đứa trẻ. Vẽ, tô màu, nhảy, đọc truyện, chơi nhạc, thậm chí là chơi với đất sét. Thể hiện bản thân mà không cần lo lắng về việc duy trì hình ảnh chuyên nghiệp mà bạn đang hướng đến. Chỉ cần thư giãn và tận hưởng chính mình. Tất cả chúng ta đều có một “đứa trẻ” trong tâm hồn và thỉnh thoảng nên cho phép “đứa trẻ” đó được ra ngoài dạo chơi.
Lê Hoài Phương – chúng tôi
Tư vấn nghề nghiệp – Cẩm nang khác
Cập nhật thông tin chi tiết về Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả? trên website Englishhouse.edu.vn. Hy vọng nội dung bài viết sẽ đáp ứng được nhu cầu của bạn, chúng tôi sẽ thường xuyên cập nhật mới nội dung để bạn nhận được thông tin nhanh chóng và chính xác nhất. Chúc bạn một ngày tốt lành!