- Các actor: Patien, Physician, Administrator - Các use case: Books Consulation, Checks Calendar, Examines Patient, Orders Test, Writes Prescription, Manages Consulation Schedule Diagra
Trang 1TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
MÔN PHÂN TÍCH THIẾT KẾ PHẦN MỀM
Trang 2NỘI DUNG BÀI LÀM
Phần 1: Phân tích và xác định yêu cầu
Yêu cầu phi chức năng (Non-Functional Requirements)
- (a) Chỉ người quản lý mới có thể lập lịch biểu (bảo mật)
- (b) Sao lưu lịch biểu hằng ngày (vận hành)
- (e) Hỗ trợ in qua kết nối không dây (vận hành)
- (f) Chỉ bác sĩ mới đặt được trạng thái có sẵn của mình hay không
- (j) Lưu thông tin cuộc hẹn mới trong vòng dưới 2 giây (hiệu suất) (bảo mật)
- (l) Vận hành trên hệ điều hành Windows (vận hành)
- (m) Truy xuất lịch hẹn hằng ngày trong vòng dưới 2 giây (hiệu suất)
Bài tập 1.2
Yêu cầu chức năng (Functional Requirements)
- (b) Ghi nhận việc bổ sung xe mới vào kho khi nhận xe từ nhà sản xuất
- (c) Cho phép người quản lý ghi lại sự chấp thuận lời đề nghị của khách hàng
- (d) Chuẩn bị hợp đồng mua bán
- (f) Lập hồ sơ mua xe của khách hàng
- (g) Cho phép nhân viên bán hàng tạo ưu đãi cho khách hàng
Trang 3- (i) Ghi nhận thông tin xe đổi trả của khách hàng
- (j) Cho phép nhân viên bán hàng biết liệu một ưu đãi có đang chờ xử lý trên một chiếc xe
cụ thể hay không
- (n) Ghi nhận khoản thanh toán của khách hàng
- (q) Phải được cập nhật các ưu đãi đang chờ xử lý trên các phương tiện cứ sau 15 phút
- (r) Cho phép người quản lý xem tồn kho xe mới hiện tại
- (s) Phần mềm phải giao tiếp với hệ thống quản lý cửa hàng
Yêu cầu phi chức năng (Non-Functional Requirements)
- (a) Chỉ chủ sở hữu và người quản lý bán hàng mới có thể phê duyệt các ưu đãi của khách
hàng (Bảo mật)
- (e) Không nhân viên bán hàng nào có thể truy cập vào danh bạ khách hàng của bất kỳ nhân viên bán hàng nào khác (Bảo mật)
- (h) Tất cả thiết bị máy tính đều được mua từ hãng Dell (Vận hành)
- (k) Việc sử dụng mỗi máy tính bảng phải được hạn chế ở nhân viên bán hàng được chỉ định (Bảo mật)
- (l) Chạy được trên máy tính bảng để nhân viên bán hàng sử dụng (Vận hành)
- (m) Phải kết nối không dây với máy in (Vận hành)
- (o) Cho phép người quản lý phương tiện mới đặt hàng xe mới (Bảo mật)
- (p) Thông tin cá nhân của khách hàng được bảo vệ tuân theo Đạo luật bảo vệ dữ liệu (Bảo
mật)
Bài tập 1.3
Yêu cầu chức năng (Functional Requirements)
- Quản lý danh mục âm nhạc (hiển thị bài hát, album, nghệ sĩ, thể loại)
- Tìm kiếm bài hát theo tên, nghệ sĩ, album, thể loại
- Nghe thử đoạn nhạc trước khi mua
- Tạo danh sách yêu thích để lưu trữ bài hát yêu thích
- Mua nhạc và thanh toán trực tuyến bằng thẻ ngân hàng, ví điện tử
- Đăng ký, đăng nhập và quản lý tài khoản người dùng
Trang 4- Đề xuất bài hát dựa trên sở thích cá nhân
- Cung cấp chương trình khuyến mãi và ưu đãi cho khách hàng
- Hỗ trợ đa nền tảng (trình duyệt web, thiết bị di động)
Yêu cầu phi chức năng (Non-Functional Requirements)
- Hệ thống phải đảm bảo tải xuống nhanh, tránh gián đoạn khi có sự cố mạng (hiệu suất)
- Dữ liệu người dùng và thông tin thanh toán phải được mã hóa (bảo mật)
- Hệ thống phải hỗ trợ nhiều người dùng truy cập đồng thời mà không bị chậm (hiệu suất)
- Hỗ trợ hoạt động trên nhiều trình duyệt và thiết bị khác nhau (vận hành)
- Thông tin cá nhân của người dùng phải được bảo vệ, không chia sẻ trái phép (bảo mật)
- Lưu giao dịch và cập nhật dữ liệu trong vòng dưới 2 giây (hiệu suất)
- Hệ thống phải sao lưu dữ liệu định kỳ để đảm bảo an toàn (vận hành)
Phần 2: Use case và use case diagram
- (a4) Quản trị viên
- (a5) Hệ thống quản lý y tế chính phủ (Government Health Regulatory System)
- (a6) Bệnh nhân
- (a7) Registers Patient
- (a8) Government Health Regulatory System
- (a9) Registers Patient
- (a10) Creates Patient’s Medical Profile
- (a11) Registers Patient
- (a12) Government Health Regulatory System
b)
Trang 5- Các actor: Patient, Doctor, Government Health Regulatory System, Administrator
- Các use case: Register Patient, Maintains Patient Details
Diagram b:
- Các actor: Staff
- Các use case: Creates Calendar, Maintains Calendar,Checks Calendar
Diagram c:
Trang 6- Các actor: Patien, Physician, Administrator
- Các use case: Books Consulation, Checks Calendar, Examines Patient, Orders Test, Writes
Prescription, Manages Consulation Schedule
Diagram d:
- Các actor: Patien, Private Patient, Card Reader, Printer
- Các use case: Pays Bill (extend: Pays Bill By Card, Pays Bill On Internet, Cash Cheque
Payment), Places Insurance Claim
Bài tập 2.1.3
a) Use case diagram: Patient Maintenance
Use Case: UC10 – Registers Patient
- Actors:
o A10-Patient
o A80-Administrator
o A90-Government Health Regulatory System
- Use Case Description:
o Bệnh nhân đăng ký thông tin cá nhân lần đầu vào hệ thống
o Quản trị viên hỗ trợ tạo và xác minh thông tin đăng ký của bệnh nhân
o Hệ thống quản lý y tế chính phủ xác minh chi tiết Medicare đối với những bệnh nhân đăng ký lần đầu
Use Case: UC12 – Maintains Patient Details
- Actors:
o A10-Patient
o A80-Administrator
- Use Case Description:
o Bệnh nhân có thể cập nhật thông tin cá nhân khi cần thiết
o Quản trị viên hỗ trợ kiểm tra và xác minh thông tin khi có sự thay đổi quan trọng
Use Case: UC14 – Creates Patients Medical Profile
Trang 7- Actors:
o A60-Doctor
o A80-Administrator
- Use Case Description:
o Bác sĩ tạo hồ sơ y tế cho bệnh nhân, bao gồm tiền sử bệnh, tình trạng sức khỏe, và thông tin điều trị
o Quản trị viên hỗ trợ quá trình tạo và xác minh hồ sơ y tế ban đầu Khi hồ sơ đã được tạo, việc bảo trì không còn cần sự tham gia của quản trị viên
b) Use case diagram: Calendar Maintenance
Use Case: UC20 - Creates Calendar
- Actors:
o A50 - Staff
- Use Case Description:
o Nhân viên có thể tạo mới một lịch trình công việc
Use Case: UC22 - Maintains Calendar
- Actors:
o A50 - Staff
- Use Case Description:
o Nhân viên có thể bảo trì lịch làm việc, chỉnh sửa hoặc cập nhật các thông tin cần thiết
o Một số hoạt động bảo trì, như đặt kỳ nghỉ, có thể yêu cầu sự ủy quyền phù hợp
Use Case: UC24 - Checks Calendar
- Actors:
o A50 - Staff
- Use Case Description:
o Nhân viên có thể kiểm tra lịch trình đã tạo hoặc được bảo trì
o Use Case này được bao gồm trong quá trình bảo trì lịch
c) Use case diagram: Consultation details
Use Case: UC30 - Books Consultation
Trang 8o Quản trị viên hỗ trợ quá trình đặt lịch thủ công khi cần
Use Case: UC24 - Checks Calendar
- Actors:
o A10 - Patient
o A80 - Administrator
- Use Case Description:
o Bệnh nhân và quản trị viên có thể kiểm tra lịch trình tư vấn hiện có
o Lịch trình này do bác sĩ cập nhật dựa trên tình trạng sẵn có của họ
Use Case: UC32 - Examines Patient
- Actors:
o A64 - Physician
- Use Case Description:
o Bác sĩ thực hiện kiểm tra sức khỏe bệnh nhân trong buổi tư vấn
Use Case: UC34 - Orders Tests
- Actors:
o A64 - Physician
- Use Case Description:
o Bác sĩ có thể yêu cầu xét nghiệm y tế bổ sung để chẩn đoán chính xác hơn
Use Case: UC35 - Writes Prescription
- Actors:
o A64 - Physician
- Use Case Description:
o Bác sĩ kê đơn thuốc dựa trên kết quả kiểm tra và xét nghiệm
Use Case: UC36 - Manages Consultation Schedule
Trang 9- Actors:
o A64 - Physician
- Use Case Description:
o Bác sĩ có thể quản lý và cập nhật lịch tư vấn của mình
d) Use case diagram: Accounting
Use Case: UC50 – Pays Bill
- Actors:
o A10 - Patient
- Use Case Description:
o Bệnh nhân thực hiện thanh toán hóa đơn sau khi hóa đơn đã được phát hành
o Thanh toán có thể được thực hiện bằng nhiều phương thức khác nhau
Use Case: UC56 - PaysBillOnInternet <<extends>> UC50 - PaysBill
- Actors:
o A10 - Patient
- Use Case Description:
o Bệnh nhân thực hiện thanh toán hóa đơn trực tuyến thông qua hệ thống thanh toán điện tử
o Hệ thống yêu cầu xác thực danh tính trước khi tiến hành giao dịch
Bài tập 2.1.4
a Use case diagram: Patient Maintenance
Use Case: UC10 - RegistersPatient
- Use case description:
o Bệnh nhân đăng ký vào hệ thống lần đầu tiên
o Thông tin của bệnh nhân được nhập vào hệ thống và có thể cần xác minh
- Precondition:
o Bệnh nhân chưa có hồ sơ trong hệ thống
Trang 10- Postcondition:
o Thông tin bệnh nhân được lưu trữ trong hệ thống
o Nếu cần, thông tin được gửi đến hệ thống quản lý y tế để xác minh
- Actor:
o A10 - Patient
o A80 - Administrator
o A90 - GovernmentHealthRegulatorySystem
- Use case relationship:
o Hệ thống quản lý y tế (A90) tham gia vào quá trình xác minh thông tin Medicare
o Quản trị viên (A80) có thể hỗ trợ tạo và xác minh thông tin bệnh nhân
- Basic flow:
o Bệnh nhân nhập thông tin cá nhân vào hệ thống
o Hệ thống kiểm tra thông tin và gửi đến hệ thống quản lý y tế để xác minh (nếu cần)
o Quản trị viên xác minh và hoàn tất đăng ký
o Hệ thống lưu trữ thông tin bệnh nhân
- Alternative flow:
o Nếu thông tin bệnh nhân đã tồn tại, hệ thống sẽ thông báo lỗi
b Use case diagram: Calendar Maintenance
Use Case: UC22 - MaintainsCalendar
- Use case description:
o Nhân viên thực hiện bảo trì lịch trình, có thể bao gồm cập nhật lịch hẹn hoặc đặt kỳ nghỉ
- Use case relationship:
o Bao gồm (<<include>>) UC24 - ChecksCalendar để kiểm tra lịch trình trước khi thực hiện cập nhật
Trang 11- Basic flow:
o Nhân viên truy cập vào hệ thống lịch trình
o Hệ thống hiển thị lịch trình hiện tại
o Nhân viên cập nhật thông tin lịch trình
o Hệ thống lưu lại thay đổi
- Alternative flow:
o Nếu cập nhật yêu cầu quyền đặc biệt (ví dụ: đặt kỳ nghỉ), hệ thống yêu cầu xác thực
bổ sung
c Use case diagram: Consultation Details
Use Case: UC30 - BooksConsultation
- Use case description:
o Bệnh nhân đặt lịch hẹn tư vấn với bác sĩ
- Use case relationship:
o Bao gồm (<<include>>) UC24 - ChecksCalendar để kiểm tra lịch trình trước khi đặt hẹn
Trang 12Bài tập 2.2.3
Use Case 5: U5 - Log On
- Use case description:
o Khách hàng đăng nhập vào hệ thống để sử dụng các chức năng như đặt xe, xem thông tin đặt xe, thay đổi thông tin cá nhân
o Customer (Member, Non-Member)
- Use case relationship:
o <<extend>> U9 - Change Password (cho phép đổi mật khẩu nếu cần)
o <<extend>> U12 - Log Off (cho phép đăng xuất sau khi đăng nhập)
- Basic flow:
o Người dùng nhập thông tin đăng nhập
o Hệ thống kiểm tra thông tin đăng nhập
o Nếu hợp lệ, hệ thống xác thực và chuyển hướng đến giao diện chính
- Alternative flow:
o Nếu thông tin đăng nhập sai, hệ thống hiển thị thông báo lỗi và cho phép thử lại
Use Case 7: U7 - Make Reservation
- Use case description:
- Thành viên đặt xe thông qua hệ thống sau khi xem thông tin chi tiết của xe
- Precondition:
o Người dùng đã đăng nhập vào hệ thống
o Xe có sẵn trong thời gian mong muốn
- Postcondition:
Trang 13- Use case relationship:
o <<extend>> U11 - Cancel Reservation (cho phép hủy đặt xe nếu cần)
o Nếu xe không có sẵn, hệ thống hiển thị thông báo và đề xuất lựa chọn khác
Use Case 3: U3 - View Car Model Details
- Use case description:
o Người dùng xem thông tin chi tiết về mẫu xe, bao gồm đặc điểm kỹ thuật, giá thuê, tình trạng sẵn có
o Customer (Member, Non-Member)
- Use case relationship:
o <<extend>> U13 - Look for Car Models (cho phép tìm kiếm mẫu xe trước khi xem chi tiết)
- Basic flow:
o Người dùng chọn một mẫu xe từ danh sách hoặc tìm kiếm
o Hệ thống hiển thị thông tin chi tiết của mẫu xe
- Alternative flow:
o Nếu xe không tồn tại, hệ thống hiển thị thông báo lỗi
Trang 14Bài tập 2.3.3
Use Case 1: Add a New Client
- Use case description:
o Campaign Manager thêm một khách hàng mới vào hệ thống để quản lý chiến dịch quảng cáo
- Use case relationship:
o Không có mối quan hệ mở rộng hoặc bao gồm với use case khác
- Basic flow:
o Campaign Manager nhập thông tin khách hàng mới
o Hệ thống kiểm tra và xác nhận dữ liệu
o Hệ thống lưu trữ thông tin khách hàng mới
- Alternative flow:
o Nếu thông tin không hợp lệ, hệ thống hiển thị thông báo lỗi và yêu cầu nhập lại
Use Case 2: Assign Staff to Work on a Campaign
- Use case description:
o Campaign Manager phân công nhân viên vào một chiến dịch cụ thể
- Precondition:
o Nhân viên đã được đăng ký trong hệ thống
o Chiến dịch phải có sẵn trong hệ thống
- Postcondition:
o Nhân viên được gán vào chiến dịch thành công
- Actor:
Trang 15o Campaign Manager
- Use case relationship:
o Không có mối quan hệ mở rộng hoặc bao gồm với use case khác
- Basic flow:
o Campaign Manager chọn chiến dịch cần gán nhân viên
o Campaign Manager chọn nhân viên cần gán
o Hệ thống cập nhật thông tin chiến dịch với nhân viên được chỉ định
- Alternative flow:
o Nếu nhân viên hoặc chiến dịch không hợp lệ, hệ thống hiển thị thông báo lỗi
Use Case 3: Record Client Payment
- Use case description:
o Campaign Manager ghi nhận thanh toán từ khách hàng vào hệ thống
- Use case relationship:
o Không có mối quan hệ mở rộng hoặc bao gồm với use case khác
- Basic flow:
o Campaign Manager chọn khách hàng có hóa đơn cần thanh toán
o Nhập số tiền thanh toán
o Hệ thống xác nhận và cập nhật thông tin thanh toán
Trang 16- Use case description:
o Monitoring Operator xem danh sách cảnh báo được hệ thống ghi nhận để theo dõi tình trạng khẩn cấp
- Precondition:
o Hệ thống có dữ liệu cảnh báo đã được ghi nhận
o Monitoring Operator đã đăng nhập vào hệ thống
- Postcondition:
o Các cảnh báo được hiển thị thành công cho Monitoring Operator
- Actor:
o Monitoring Operator
- Use case relationship:
o Không có mối quan hệ mở rộng hoặc bao gồm với use case khác
- Basic flow:
o Monitoring Operator yêu cầu xem danh sách cảnh báo
o Hệ thống truy xuất dữ liệu cảnh báo
o Hệ thống hiển thị danh sách cảnh báo cho Monitoring Operator
- Alternative flow:
o Nếu không có cảnh báo nào, hệ thống hiển thị thông báo “Không có cảnh báo mới”
Use Case 2: Generate Monitoring Data
- Use case description:
o Remote Sensor tạo dữ liệu giám sát và gửi đến hệ thống để theo dõi
- Use case relationship:
o Không có mối quan hệ mở rộng hoặc bao gồm với use case khác
- Basic flow:
o Remote Sensor thu thập dữ liệu môi trường
o Hệ thống nhận dữ liệu từ Remote Sensor
Trang 17o Hệ thống lưu trữ dữ liệu giám sát để Monitoring Operator có thể xem
- Alternative flow:
o Nếu Remote Sensor bị lỗi, hệ thống ghi nhận trạng thái lỗi và gửi cảnh báo đến Monitoring Operator
Bài tập 2.5.3
Use Case 1: Make Order Request
- Use case description:
o Customer gửi yêu cầu đặt hàng để mua sản phẩm từ hệ thống
- Precondition:
o Customer đã duyệt danh mục sản phẩm và chọn sản phẩm cần mua
o Customer đã đăng nhập vào hệ thống (nếu cần)
- Postcondition:
o Yêu cầu đặt hàng được hệ thống ghi nhận thành công
- Actor:
o Customer
- Use case relationship:
o Không có mối quan hệ mở rộng hoặc bao gồm với use case khác
- Basic flow:
o Customer chọn sản phẩm và nhấn vào nút đặt hàng
o Hệ thống hiển thị biểu mẫu xác nhận đơn hàng
o Customer nhập thông tin giao hàng và xác nhận đơn hàng
o Hệ thống ghi nhận đơn hàng và gửi xác nhận cho Customer
- Alternative flow:
o Nếu hệ thống gặp lỗi khi xử lý đơn hàng, hệ thống hiển thị thông báo lỗi và yêu cầu Customer thử lại
Use Case 2: Process Delivery Order
- Use case description:
o Supplier xử lý đơn hàng giao hàng cho Customer
- Precondition:
o Đơn hàng đã được hệ thống xác nhận