Bài giảng Nhập môn công nghệ phần mềm - Bài tập tuần 7 - Trường Đại học Bách khoa Hà Nội
Nhập môn Công nghệ phần mềm
Introduction to Software Engineering
(IT3180)
Bài tập tuần 07
Kỹ nghệ yêu cầu phần mềm (Requirement
Engineering) (tiếp theo)
Giang vien
Mục tiêu
• Thực hiện các bài tập (câu hỏi) về phân tích yêu
cầu phần mềm
• Thực hiện các bài tập về công cụ đặc tả yêu cầu
phần mềm
• Phân tích các yêu cầu cho bài toán (casestudy)
của môn học: sử dụng một số biểu đồ của UML
– Phân rã các usecase thành các lớp phân tích nhận
trách nhiệm thực thi các hoạt động trong kịch bản
usecase
– Làm quen với sơ đồ trình tự (sequence diagram)
– Xây dựng sơ đồ thực thể - quan hệ (ERD): mô hình
Department of Software Engineering -
10/28/2020hoá các dữ liệu cho bài toán
2
SOICT/HUST
Đánh giá
• Hoàn thành các bài tập về phân tích và đặc tả
yêu cầu phần mềm, nắm được các khái niệm và
những hoạt động cần thực hiện trong giai đoạn
phân tích
• Vận dụng các công cụ đặc tả yêu cầu phần
mềm: Sơ đồ thực thể liên kết – ERD (entity
relation diagram) + và một số biểu đồ trong UML
như biểu đồ trình tự
• Hoàn thành phân tích các yêu cầu cho bài toán
(casestudy) của môn học
Department of Software Engineering -
10/28/2020
3
SOICT/HUST
Bài 1.1
a) Tác nhân ca sử dụng luôn là con người, không phải là
các thiết bị hệ thống?
1. Sai
2. Đúng
Department of Software Engineering -
10/28/2020
4
SOICT/HUST
Bài 1.1
b) Use-cases là một kịch bản mà mô tả?
1. Phần mềm thực hiện như thế nào khi được dùng trong một tình
huống cho trước
2. Những công cụ CASE sẽ được dùng như thế nào để xây dựng hệ
thống
3. Kế hoạch xây dựng cho sản phẩm phần mềm
4. Những test-case cho sản phẩm phần mềm
Department of Software Engineering -
10/28/2020
5
SOICT/HUST
Bài 1.1
c) Phát biểu nào sau đây là đúng về yêu cầu phần mềm? Trả lời bằng cách đánh
dấu T (đúng) hoặc F (sai).
• (1) T / F Độ tin cậy và bảo mật là ví dụ về các yêu cầu chức năng.
• (2) T / F Yêu cầu đóng vai trò như một cơ sở cho việc kiểm tra và xác minh.
• (3) T / F Yêu cầu mô tả kiến trúc phần mềm.
• (4) T / F Các yêu cầu về hành vi thường mang tính chủ quan và không thể đo lường
được.
• (5) T / F Các trường hợp sử dụng nắm bắt các yêu cầu chức năng.
• (6) T / F Lý do số một mà các dự án thành công là sự tham gia của nhà phát triển.
• (7) T / F Một ca sử dụng đại diện cho một hành vi ví dụ của hệ thống.
• (8) T / F Các tình huống mở rộng của một ca sử dụng thiết lập sự hiểu biết giữa
khách hàng và nhà phát triển hệ thống về các yêu cầu.
• (9) T / F Trong hầu hết các trường hợp sử dụng, gần như mọi bước đều có thể bị lỗi.
Department of Software Engineering -
10/28/2020
6
SOICT/HUST
Bài 1.1
c) Phát biểu nào sau đây là đúng về yêu cầu phần mềm? Trả lời bằng cách đánh
dấu T (đúng) hoặc F (sai). Gợi ý:
• (1) T / F Độ tin cậy và bảo mật là ví dụ về các yêu cầu chức năng.
• (2) T / F Yêu cầu đóng vai trò như một cơ sở cho việc kiểm tra và xác minh.
• (3) T / F Yêu cầu mô tả kiến trúc phần mềm.
• (4) T / F Các yêu cầu về hành vi thường mang tính chủ quan và không thể đo lường
được.
• (5) T / F Các trường hợp sử dụng nắm bắt các yêu cầu chức năng.
• (6) T / F Lý do số một mà các dự án thành công là sự tham gia của nhà phát triển.
• (7) T / F Một ca sử dụng đại diện cho một hành vi ví dụ của hệ thống.
• (8) T / F Các tình huống mở rộng của một ca sử dụng thiết lập sự hiểu biết giữa
khách hàng và nhà phát triển hệ thống về các yêu cầu.
• (9) T / F Trong hầu hết các trường hợp sử dụng, gần như mọi bước đều có thể bị lỗi.
Department of Software Engineering -
10/28/2020
7
SOICT/HUST
Bài 1.2
a) Hãy trình bày nội dung của hoạt động thẩm định yêu
cầu?
b) Hãy nêu một số nhược điểm/hạn chế của kỹ thuật mô
hình hóa ca sử dụng?
Department of Software Engineering -
10/28/2020
8
SOICT/HUST
Bài 1.2
a) Hãy trình bày nội dung của hoạt động thẩm định yêu cầu?
Gợi ý:
• Mỗi yêu cầu có phù hợp với dự án tổng thể hoặc mục tiêu của hệ thống không?
• Tất cả các yêu cầu được chỉ định ở mức trừu tượng có phù hợp không?
• Mỗi yêu cầu có cần thiết cho mục tiêu hệ thống hay là một tính năng bổ sung?
• Mỗi yêu cầu có bị ràng buộc và rõ ràng không?
• Nguồn cho từng yêu cầu là gì?
• Các yêu cầu có xung đột với nhau không?
• Yêu cầu có thể đạt được trong môi trường kỹ thuật được đề xuất cho hệ thống hoặc sản
phẩm không?
• Mỗi yêu cầu có thể kiểm thử được không?
• Mô hình yêu cầu có phản ánh thông tin, chức năng và hành vi của hệ thống được xây
dựng không?
• Mô hình yêu cầu có được tổ chức theo cách cho phép biểu diễn thông tin hệ thống theo
hướng chi tiết dần một cách liên tục không?
• Tất cả các mẫu yêu cầu đã được xác thực hợp lệ hay chưa và chúng có phù hợp với yêu
cầu của khách hàng không?
Department of Software Engineering -
10/28/2020
9
SOICT/HUST
Bài 1.2
b) Hãy nêu một số nhược điểm/hạn chế của kỹ thuật mô hình hóa ca
sử dụng?
Gợi ý:
• Thiếu đặc tả hình thức trong mô tả ca sử dụng.
• Không phải tất cả các hệ thống đều có các tác nhân được
xác định rõ ràng.
• Các ca sử dụng vốn không theo hướng đối tượng.
• Các nhà phát triển có xu hướng tiến hành phân rã chức
năng với các ca sử dụng.
• …
Department of Software Engineering -
10/28/2020
10
SOICT/HUST
Bài 1.3
Hãy giải ô chữ tổng hợp kiến thức dưới đây với các gợi ý kèm theo?
10
1
Bài 1.3
Gợi ý của ô chữ:
Department of Software Engineering -
SOICT/HUST
10/28/2020
12
Bài 1.3
Gợi ý của ô chữ:
Department of Software Engineering -
SOICT/HUST
10/28/2020
13
Bài 1.3
Lời giải:
Department of Software Engineering -
SOICT/HUST
10/28/2020
14
Bài 1.3
Lời giải:
Department of Software Engineering -
SOICT/HUST
10/28/2020
15
Giải ô chữ
Phần II: Phân tích usecase
• Phân tích yêu cầu là nhằm trả lời câu hỏi hệ thống sẽ làm những gì
(what), hơn là chỉ ra cách thức (how) làm những việc đó.
• Phân rã các yêu cầu phức tạp được trình bày trong pha xác định yêu
cầu thành các nhân tố chính cùng mối quan hệ giữa chúng để làm cơ
sở cho giải pháp được trình bày trong pha thiết kế sau này. Kết quả của
quá trình phân rã là các lớp phân tích. Tất cả các hoạt động trong kịch
bản của Use-Case phải được phản ánh đầy đủ trong các lớp phân tích.
• Tại sao lại cần phân tích? Mô hình trợ giúp cho người phân tích trong
việc hiểu về thông tin, chức năng và hành vi của hệ thống.
10/28/2020
17
Phần II: Phân tích usecase
• Mô hình phân tích có vai trò như cầu nối giữa các
mô tả hệ thống và mô hình thiết kế:
Department of Software Engineering -
10/28/2020
18
SOICT/HUST
Phần II: Phân tích usecase
• Xác định các lớp phân tích như thế nào? Hầu
như không có một công thức chung cho việc phát
hiện ra các lớp.
– Tìm các lớp là một công việc đòi hỏi sự sáng tạo được
thực hiện với sự trợ giúp của chuyên gia ứng dụng.
– Quá trình phân tích và thiết kế có tính lặp: danh sách
các lớp sẽ thay đổi theo thời gian.
– Tập hợp của các lớp tìm ra ban đầu chưa chắc đã là tập
hợp cuối cùng của các lớp sẽ được thực thi và biến đổi
thành code sau này. Nhiều thành phần trong giai đoạn
phân tích có thể bị biến đổi hoặc mất đi khi sang pha
thiết kế.
Department of Software Engineering -
10/28/2020
19
SOICT/HUST
Phần II: Phân tích usecase
• Ba khía cạnh của hệ thống có thể sẽ thay đổi:
– 1. Ranh giới giữa hệ thống và các tác nhân của nó
– 2. Thông tin hệ thống sử dụng
– 3. Logic điều khiển của hệ thống
• → Trong nỗ lực cô lập các bộ phận của hệ thống
có thể sẽ thay đổi, chúng ta sẽ “đóng hộp” những
thay đổi đó vào các lớp. Trên cơ sở đó mỗi
usecase được phân rã thành các thành phần thuộc
vào một trong ba loại lớp phân tích sau:
– Lớp biên (ranh giới)
– Lớp thực thể (chứa thông tin)
– Lớp điều khiển (logic điều khiển)
Department of Software Engineering -
10/28/2020
20
SOICT/HUST
Tải về để xem bản đầy đủ
39 trang
27/04/2022
3960
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Nhập môn công nghệ phần mềm - Bài tập tuần 7 - Trường Đại học Bách khoa Hà Nội", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- bai_giang_nhap_mon_cong_nghe_phan_mem_bai_tap_tuan_7_truong.pdf
