Bài giảng Nhập môn công nghệ phần mềm - Tuần 7: Kỹ nghệ yêu cầu phần mềm

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 210/28/2020 Department of Software Engineering - SOICT/HUST • 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 hoá các dữ liệu cho bài toá Đánh giá 310/28/2020 Department of Software Engineering - SOICT/HUST • 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 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 10/28/2020 Department of Software Engineering - SOICT/HUST 4 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 10/28/2020 Department of Software Engineering - SOICT/HUST 5 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. 10/28/2020 Department of Software Engineering - SOICT/HUST 6 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. 10/28/2020 Department of Software Engineering - SOICT/HUST 7 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? 10/28/2020 Department of Software Engineering - SOICT/HUST 8 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? 10/28/2020 Department of Software Engineering - SOICT/HUST 9 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. • 10/28/2020 Department of Software Engineering - SOICT/HUST 10 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/28/2020 Department of Software Engineering - SOICT/HUST 11 Bài 1.3 Gợi ý của ô chữ: 10/28/2020 Department of Software Engineering - SOICT/HUST 12 Bài 1.3 Gợi ý của ô chữ: 10/28/2020 Department of Software Engineering - SOICT/HUST 13 Bài 1.3 Lời giải: 10/28/2020 Department of Software Engineering - SOICT/HUST 14 Bài 1.3 Lời giải: 10/28/2020 Department of Software Engineering - SOICT/HUST 15 Giải ô chữ Lời giải: 10/28/2020 Department of Software Engineering - SOICT/HUST 16 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 Department of Software Engineering - SOICT/HUST 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ế: 10/28/2020 Department of Software Engineering - SOICT/HUST 18 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ế. 10/28/2020 Department of Software Engineering - SOICT/HUST 19 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) 10/28/2020 Department of Software Engineering - SOICT/HUST 20 Phần II: Phân tích usecase • Các loại lớp phân tích khác nhau có thể được biểu diễn bằng các biểu tượng khác nhau hoặc với tên của khuôn mẫu trong cặp dấu (>): >, >, >. 10/28/2020 Department of Software Engineering - SOICT/HUST 21 Phần II: Phân tích usecase • Boundary classes • Một lớp biên là giao diện trung gian giữa hệ thống và một cái gì đó bên ngoài. Các lớp ranh giới cách ly hệ thống khỏi những thay đổi của môi trường xung quanh (ví dụ, những thay đổi về giao diện), giữ cho những thay đổi này không ảnh hưởng đến phần còn lại của hệ thống. • Một số hướng dẫn để tìm các lớp biên: – Một khuyến nghị cho việc xác định ban đầu các lớp biên là: mỗi cặp tác nhân / ca sử dụng → xác định ít nhất 1 lớp biên. – Một hệ thống có thể có một số loại lớp biên (theo phân loại của actor): • Các lớp giao diện người dùng • Các lớp giao diện hệ thống: ví dụ: các giao diện gọi các API của một hệ thống khác. • Các lớp giao diện thiết bị 10/28/2020 Department of Software Engineering - SOICT/HUST 22 Phần II: Phân tích usecase • Boundary classes • Với usecase “Tạo mới sổ hộ khẩu” → Form Tạo mới sổ hộ khẩu 10/28/2020 Department of Software Engineering - SOICT/HUST 23 Phần II: Phân tích usecase • Entity classes • Các lớp thực thể đại diện cho các kho thông tin trong hệ thống. Chúng thường được sử dụng để đại diện cho các khái niệm chính mà hệ thống quản lý. • Đối tượng thực thể (các thể hiện của lớp thực thể) được sử dụng để lưu giữ và cập nhật thông tin về một sự kiện, một người hoặc một đối tượng ngoài đời thực. • Một số hướng dẫn để tìm các lớp thực thể: – Đầu vào lấy luồng sự kiện theo usecase, gạch dưới các cụm danh từ trong luồng sự kiện. Chúng tạo thành danh sách ứng viên ban đầu của các lớp thực thể. – Thực hiện lọc bỏ các danh từ: Loại bỏ các ứng viên thừa (trùng lặp), Loại bỏ các ứng viên mơ hồ, Loại bỏ các tác nhân (ngoài phạm vi), Loại bỏ các cấu trúc triển khai, Loại bỏ các thuộc tính (lưu để sử dụng sau), Loại bỏ các hoạt động, → còn lại là các ứng viên cho lớp thực thể của usecase10/28/2020 Department of Software Engineering - SOICT/HUST 24 Phần II: Phân tích usecase • Entity classes • Với usecase “Tạo mới sổ hộ khẩu” → Entity sổ hộ khẩu, Entity nhân khẩu 10/28/2020 Department of Software Engineering - SOICT/HUST 25 Phần II: Phân tích usecase • Control classes • Các lớp điều khiển cung cấp khả năng phối hợp hành vi trong hệ thống. • Xác định logic điều khiển (thứ tự giữa các sự kiện) và các giao dịch trong một usecase • Một số hướng dẫn để tìm các lớp điều khiển: – Mỗi usecase xác định ít nhất một lớp điều khiển. – Các usecase chỉ liên quan đến thao tác đơn giản đối với thông tin được lưu trữ hệ thống có thể chỉ sử dụng các lớp thực thể và lớp biên, không dùng lớp điều khiển. – Các usecase phức tạp thường yêu cầu một hoặc nhiều lớp điều khiển để điều phối hành vi của các đối tượng khác trong hệ thống. Ví dụ về các lớp điều khiển bao gồm quản lý giao dịch, điều phối tài nguyên và xử lý lỗi. 10/28/2020 Department of Software Engineering - SOICT/HUST 26 Phần II: Phân tích usecase • Control classes • Với usecase “Tạo mới sổ hộ khẩu” → Control Quản lý hộ khẩu 10/28/2020 Department of Software Engineering - SOICT/HUST 27 Phần II: Phân tích usecase • Kết quả quá trình phân rã bước đầu của usecase “Tạo mới sổ hộ khẩu”: 10/28/2020 Department of Software Engineering - SOICT/HUST 28 Thực hiện tương tự với các usecase khác, chúng ta thu được một mô hình phân tích bao gồm các lớp phân tích trong đó. Chú ý: nếu trong các kết quả có các lớp phân tích trùng nhau (ví dụ trong một usecase khác cũng xuất hiện lớp thực thể “Sổ hộ khẩu”) thì cần hợp nhất các lớp phân tích này. Phần II: Phân tích usecase • Bước tiếp theo chúng ta cần xác định các thông tin chi tiết hơn cho các lớp phân tích này: – Mỗi lớp: xác định các thuộc tính và phương thức – Quan hệ giữa các lớp 10/28/2020 Department of Software Engineering - SOICT/HUST 29 Phần II: Phân tích usecase • Bài tập: Phân rã usecase “Đăng nhập”, xác định các lớp phân tích. • Gợi ý: 10/28/2020 Department of Software Engineering - SOICT/HUST 30 Phần II: Phân tích usecase • Phân bổ trách nhiệm ca sử dụng cho các đối tượng của các lớp phân tích • Với mỗi usecase: chúng ta cần phân bổ trách nhiệm ca sử dụng cho các đối tượng của các lớp phân tích. • Đây là một hoạt động quan trọng và đôi khi khó khăn, nó là cơ sở để chúng ta xác định các dữ liệu thành phần (phương thức + thuộc tính) cho mỗi lớp. • Kết quả của quá trình này có thể biểu diễn bằng biểu đồ trình tự (sequence diagram) hoặc biểu đồ giao tiếp (communication diagram) trong UML. 10/28/2020 Department of Software Engineering - SOICT/HUST 31 Phần II: Phân tích usecase • Biểu đồ trình tự (sequence diagram): Là biểu đồ tương tác tập trung vào thứ tự trao đổi các thông điệp theo thời gian. • Gồm: Các đối tượng tham gia tương tác và Trình tự các thông điệp trao đổi với nhau. 10/28/2020 Department of Software Engineering - SOICT/HUST 32 Phần II: Phân tích usecase • Biểu đồ giao tiếp (communication diagram): Là biểu đồ tương tác tập trung vào tổ chức các đối tượng tham gia tương tác. • Gồm: Các đối tượng tham gia tương tác. Đường liên kết giữa các đối tượng. Thông điệp trao chuyển giữa các đối tượng. Tập trung vào sự kiện có nghĩa là chú ý đặc biệt đến mối quan hệ (nối kết) giữa các đối tượng. 10/28/2020 Department of Software Engineering - SOICT/HUST 33 Phần II: Phân tích usecase • Bài tập: Từ mô tả chi tiết kịch bản usecase hãy Xây dựng biểu đồ trình tự cho usecase “Tạo mới sổ hộ khẩu”: xác định trình tự các thông điệp tương tác giữa các đối tượng của các lớp phân tích trong usecase này. 10/28/2020 Department of Software Engineering - SOICT/HUST 34 Phần II: Phân tích usecase • Gợi ý: 10/28/2020 Department of Software Engineering - SOICT/HUST 35 Phần II: Phân tích usecase • Phân tích dữ liệu cho hệ thống với biểu đồ thực thể - quan hệ (ERD) • Xác định các đối tượng dữ liệu • Xác định các đặc tính của các đối tượng dữ liệu • Thiết lập các mối quan hệ giữa các đối tượng dữ liệu 10/28/2020 Department of Software Engineering - SOICT/HUST 36 Phần II: Phân tích usecase • Bài tập: Xây dựng mô hình dữ liệu ERD cho nhóm chức năng số 1: “1. Quản lý thông tin hộ khẩu, nhân khẩu”. 10/28/2020 Department of Software Engineering - SOICT/HUST 37 Phần II: Phân tích usecase • Gợi ý: 10/28/2020 Department of Software Engineering - SOICT/HUST 38 Đặc tả các yêu cầu cho bài toán (casestudy) với usecase • Yêu cầu: • Hoàn thành Phân tích các yêu cầu cho bài toán (casestudy) với các nội dung: phân rã các lớp phân tích, xây dựng biểu đồ trình tự (biểu đồ giao tiếp), mô hình dữ liệu ERD. • Phần nội dung này các nhóm làm vào trong file .docx (báo cáo) • Các nhóm chuẩn bị thêm một slide powerpoint về nội dung Phân tích các yêu cầu ở trên, buổi học tiếp theo sẽ trình bày. 10/28/2020 Department of Software Engineering - SOICT/HUST 39