(LUẬN văn THẠC sĩ) chuyển ngôn ngữ trong biểu diễn yêu cầu phần mềm

Tổng quan

Đặt vấn đề

Yêu cầu phần mềm thường được diễn đạt bằng ngôn ngữ tự nhiên, nhưng điều này thường dẫn đến sự không rõ ràng Các phương pháp hình thức hiện tại chỉ cho phép kiểm chứng yêu cầu khi chúng được mô tả bằng ngôn ngữ hình thức, điều này có thể gây khó khăn cho nhóm phát triển Để giải quyết vấn đề này, Konrad và Cheng đã phát triển hệ thống luật mô tả SPSKC, sử dụng một tập hợp giới hạn từ vựng và cấu trúc tiếng Anh, cho phép ghi lại yêu cầu chức năng bằng ngôn ngữ tự nhiên dễ hiểu và có thể dịch sang logic hình thức Tuy nhiên, SPSKC không thể mô tả các yêu cầu phi chức năng, vì vậy cần kết hợp với hệ thống luật mô tả SKSG của Grunske L để khắc phục điểm yếu này.

Vào năm 2012, nhóm nghiên cứu của BOSCH và Đại học Freiburg đã hợp tác để kiểm chứng SPSKC trong lĩnh vực công nghiệp ô tô Họ cho rằng việc mở rộng SPSKC bằng cách bổ sung SPSG để đáp ứng các yêu cầu phi chức năng là rất hữu ích Tuy nhiên, nghiên cứu này không mô tả cách chuyển đổi yêu cầu phần mềm từ ngôn ngữ tự nhiên sang mô tả bằng SPS Việc xác định rõ phương pháp chuyển đổi là cần thiết để đảm bảo tính chính xác của quá trình và đánh giá độ tin cậy của kết quả chuyển đổi.

Từ nghiên cứu nói trên, luận văn đặt ra hai mục tiêu chính cần giải quyết:

Sự kết hợp giữa SPSKC và SPSG thành một SPS kết hợp (gọi tắt là SPSC) là cần thiết để đảm bảo rằng tất cả các yêu cầu của phần mềm được mô tả đầy đủ và chính xác.

- Cần có những quy tắc nào để chuyển đổi từ ngôn ngữ tự nhiên sang SPSC tránh sai sót và giảm công sức của người thực hiện

Mẫu kiểm chứng đầu tiên được sử dụng là ví dụ cho phân tích yêu cầu trong tài liệu hướng dẫn “IBM Rational Software - Phần 1: Yêu cầu Đăng ký Khóa học”, với giả định rằng bộ yêu cầu này đủ rõ ràng và toàn diện.

TIEU LUAN MOI download : skknchat@gmail.com

Công cụ hỗ trợ chuyển đổi yêu cầu từ ngôn ngữ tự nhiên sang SPSC được phát triển dựa trên phương pháp PROPEL (PROPerty ELucidation approach) như được trình bày trong luận án tiến sĩ của Rachel L Cobleigh.

Tổng quan tình hình nghiên cứu

Quá trình phát triển phần mềm bao gồm nhiều giai đoạn quan trọng như phân tích yêu cầu, thiết kế hệ thống, lập trình, kiểm thử và phát hành sản phẩm Trước đây, khi một dự án thất bại do vượt quá ngân sách hoặc thời gian, hoặc sản phẩm gặp nhiều lỗi, người ta thường đổ lỗi cho quá trình lập trình Tuy nhiên, thực tế cho thấy rằng nguyên nhân thất bại không chỉ nằm ở khâu lập trình mà còn ở nhiều yếu tố khác trong toàn bộ quy trình phát triển.

Robert N đã chỉ ra 12 lỗi chính dẫn đến thất bại của dự án phần mềm trong bài viết trên IEEE Spectrum, trong đó chỉ có 3 lỗi liên quan trực tiếp đến kỹ thuật: không xác định chính xác yêu cầu phần mềm, sử dụng công nghệ chưa hoàn chỉnh và kỹ năng lập trình kém Điều này cho thấy rằng việc xác định chính xác yêu cầu phần mềm có vai trò quan trọng không kém gì việc lựa chọn công nghệ phù hợp và nâng cao kỹ năng lập trình.

Sau một thời gian dài tập trung vào việc phát triển lý thuyết và công cụ hỗ trợ lập trình, cũng như phát hiện và sửa lỗi, các chuyên gia phần mềm đã chuyển hướng chú ý đến việc nâng cao chất lượng phân tích yêu cầu phần mềm.

Quá trình nâng cao chất lượng phân tích yêu cầu bắt đầu từ việc xác định một mô tả yêu cầu tốt Theo Karl E Wiegers trong cuốn sách “Software Engineering” xuất bản năm 2003, việc này rất quan trọng để đảm bảo sự thành công trong phát triển phần mềm.

Một mô tả yêu cầu tốt cần đáp ứng đầy đủ các tiêu chí như: hoàn thiện, chính xác, có khả năng hiện thực hóa, cần thiết, rõ ràng, có thể kiểm thử và được đánh giá về mức độ quan trọng.

Ông đề xuất một số mẫu tài liệu phân tích yêu cầu và hướng dẫn viết mô tả yêu cầu, bao gồm việc viết câu hoàn chỉnh, sử dụng thể chủ động, áp dụng các từ khóa đã được định nghĩa và bổ sung hình ảnh để làm rõ yêu cầu.

Mặc dù Karl E Wiegers đã cung cấp hướng dẫn trực quan và ví dụ rõ ràng, nhưng những hướng dẫn này vẫn còn khái quát và chưa đủ cụ thể để có thể áp dụng hiệu quả trong thực tế.

Chất lượng tài liệu mô tả yêu cầu phụ thuộc vào khả năng và kinh nghiệm của người phân tích yêu cầu Để cải thiện điều này, các chuyên gia đã phát triển "mẫu yêu cầu" (RP - requirement pattern) để hướng dẫn cách mô tả các loại yêu cầu cụ thể.

Ý tưởng của RP là hướng dẫn xác định yêu cầu cho các nhóm yêu cầu phổ biến, giúp việc viết mô tả yêu cầu trở nên nhanh chóng, dễ dàng và chất lượng hơn Ông đã trình bày 37 RPs, phân loại thành 8 nhóm, như thể hiện trong Bảng 1.1 dưới đây.

Mẫu yêu cầu “Living entity RP” thuộc nhóm “Data Entity” trong Bảng 1.1 được mô tả trong phụ lục 1

Bảng 1.1: Phân loại mẫu yêu cầu của Withall

STT Tên nhóm Tên mẫu yêu cầu

Công nghệ (technology) Tiêu chuẩn (comply with standard) Chỉ đến các yêu cầu (refer to requirements) Tài liệu (documentation)

Giao diện liên kết giữa các hệ thống (inter-system interface)

Tương tác giữa các hệ thống (inter-system interaction)

Kiểu dữ liệu (data type) Định danh (ID)

Cấu trúc dữ liệu (data structure) Hàm tính toán (calculation formula)

Lưu trữ dữ liệu (data archive) Tồn tại của dữ liệu (data longevity)

Thực thể dữ liệu (Data entity) Lưu trữ thông tin (Information storage) Tồn tại của thực thể (entity living) Giao dịch (transaction)

Lịch sử (chronicle) Cấu hình (configuration)

4 Chức năng cho người dùng (user function)

Giao diện người dùng (User interface) Truy vấn (Inquiry)

Báo cáo (Report) Báo cáo (Reporting) Khả năng truy cập (Accessibility)

Thời gian phản hồi (Response time) Thông lượng (Throughput)

Công suất tĩnh (Static capacity) Công suất động (Dynamic capacity) Tính sẵn sàng (Availability)

Unparochialness Tính đa dạng (Multiness) Khả năng mở rộng (Scalability) Khả năng nâng cấp (Extendability)

Tính cài đặt được (Installability) Đa ngôn ngữ (Multi-lingual)

Thuế/phí (Fee/tax) Đơn vị đa tổ chức (Multiorganization unit)

(access control) Đăng ký tài khoản (User registration) Xác thực người dùng (User authentication) Phân quyền người dùng (User authorization) Các phân quyền đặc biệt (Specific authorization)

Cấu hình phân quyền (Configurable authorization)

Mặc dù có 37 mẫu yêu cầu, nhưng chúng không thể bao quát tất cả các loại yêu cầu phần mềm Vì vậy, Withall đã phát triển một "cấu trúc chuẩn" cho mẫu yêu cầu và khuyến khích các nhà phân tích cũng như các công ty tự tạo ra mẫu yêu cầu phù hợp với đặc điểm riêng của cá nhân hoặc tổ chức (xem Bảng 1.2).

Bảng 1.2: Cấu trúc chuẩn cho mẫu yêu cầu

1 Những chi tiết cơ bản

- Những đặc điểm cơ bản, giúp nhận ra những biến thể khác nhau của cùng một loại mẫu

- Miền bao hàm của RP đó

- Những mẫu liên quan nếu có

- Tần suất xuất hiện – số lượng những yêu cầu thuộc dạng RP này trong một hệ thống điển hình

- Các tập phân loại mẫu

Những trường hợp RP có thể áp dụng, và kể cả những trường hợp RP không nên áp dụng

3 Thảo luận Các thảo luận về các chủ đề tổng quát và về cách làm thế nào để chỉ định rõ những yêu cầu thuộc RP đó

4 Nội dung Một danh sách các mục thông tin mà một yêu cầu thuộc RP đó cần phải có

5 Mẫu yêu cầu Một mẫu sẵn có dạng điền vào chỗ trống giúp mở đầu phát triển các yêu cầu thuộc RP đó dễ dàng hơn

Một hoặc một vài yêu cầu thực tế từ RP có thể được phát triển dễ dàng hơn khi sử dụng các mẫu sẵn có làm ví dụ mở đầu.

7 Các yêu cầu bổ sung

Những góp ý, thông tin bổ sung giúp ích cho phát triển các yêu cầu sau này

8 Những gợi ý cho thiết kế và lập trình

Những gợi ý cho các lập trình viên về cách thức cài đặt các yêu cầu thuộc dạng RP này

9 Những gợi ý cho kiểm thử

Những gợi ý cho việc thực hiện kiểm thử các yêu cầu thuộc dạng RP này

RP đã tạo ra một bước tiến quan trọng trong việc làm rõ và thống nhất mô tả các yêu cầu Bằng cách sử dụng cùng một mẫu RP cho các yêu cầu khác nhau nhưng cùng loại, cấu trúc của chúng sẽ trở nên đồng nhất, đảm bảo đầy đủ các thành phần cơ bản cần thiết.

Chất lượng của các yêu cầu phần mềm (RP) không đồng nhất và phụ thuộc vào kinh nghiệm của người tạo ra chúng Việc lựa chọn RP phù hợp để thể hiện yêu cầu cũng cần kỹ năng của người phân tích Do đó, RP gặp phải vấn đề về chất lượng không đồng đều, ảnh hưởng bởi kinh nghiệm và kỹ năng cá nhân của chuyên gia Hơn nữa, RP vẫn chưa giải quyết được vấn đề kiểm chứng tính rõ ràng, không nhập nhằng hay trùng lặp của các yêu cầu được mô tả.

Một số nhóm nghiên cứu đang tiếp tục cập nhật và bổ sung các yêu cầu phi chức năng vào các quy trình phát triển phần mềm (RP) hiện có.

11 trong hội nghị REPA‟ 2012 [5], một số nhóm nghiên cứu khác chú ý đến các mẫu đặc tả (SP – specification pattern) xây dựng bởi Dwyer

Theo định nghĩa của phòng thí nghiệm Santos [7]:

Mẫu đặc tả thuộc tính là một mô tả tổng quát về yêu cầu thường gặp trong chuỗi trạng thái hoặc sự kiện của mô hình hệ thống trạng thái hữu hạn Nó thể hiện cấu trúc cơ bản của một khía cạnh hành vi trong hệ thống và cung cấp các biểu thức cho hành vi đó trong các hình thức phổ biến.

Phương pháp chuyển ngôn ngữ

Phương pháp chuyển đổi

2.1.1 Mô tả yêu cầu trong thiết kế và lập trình hướng đối tượng

Trong thiết kế và lập trình hướng đối tượng, yêu cầu chức năng của phần mềm được diễn đạt bằng ngôn ngữ tự nhiên theo một cấu trúc nhất định, kèm theo hình ảnh minh họa các ca sử dụng (use case) Mỗi ca sử dụng sẽ được mô tả theo một cấu trúc cụ thể để đảm bảo tính rõ ràng và dễ hiểu.

- Mô tả ngắn gọn (brief description)

- Các luồng sự kiện (flows of events), bao gồm: luồng sự kiện chính (basic flow), các luồng tương đương (alternative flows)

- Các yêu cầu đặc biệt (special requirements)

- Các điều kiện trước (pre-conditions)

- Các điều kiện sau (post-conditions)

- Các điểm mở rộng (extension points)

Trong tài liệu mẫu của IBM, các yêu cầu phi chức năng được trình bày bằng lời Toàn bộ nội dung mô tả yêu cầu cho hệ thống đăng ký lớp học, được sử dụng làm bộ mẫu cho luận văn này, có thể được tìm thấy trong Phụ lục 2.

Các mô tả của SPSC được xây dựng dựa trên sự kiện và trạng thái, cũng như mối quan hệ giữa chúng Do đó, quá trình chuyển đổi bao gồm ba bước chính, sẽ được trình bày chi tiết trong các phần 2.2, 2.3 và 2.4.

- Bước 1: tinh chỉnh lại các mô tả đang có để mô tả yêu cầu đối với hệ thống (không phải đối với người dùng)

- Bước 2: xác định sự kiện/trạng thái của hệ thống

- Bước 3: xác định mối quan hệ giữa các sự kiện/trạng thái

Tinh chỉnh yêu cầu

Khi cần mô tả hành động của người dùng thay vì hệ thống, chúng ta cần chuyển hướng sang việc miêu tả cách mà hệ thống xử lý các yêu cầu Từ đó, chúng ta có thể xác định lại các sự kiện phù hợp liên quan đến hành động của người dùng.

Sau khi người dùng nhập tên tài khoản và mật khẩu, hệ thống chỉ cần xác nhận yêu cầu xác thực, không cần quan tâm đến nội dung cụ thể của tài khoản và mật khẩu Điều này thường được thực hiện thông qua việc nhấn nút “đăng nhập” trên giao diện web.

Do đó ta có thể chuyển yêu cầu trên thành: “Ngay khi nhận được yêu cầu xác thực, hệ thống thực hiện kiểm tra tài khoản và mật khẩu”.

Xác định sự kiện

Theo Rachel L.Cobleigh, phương pháp PROPEL hiện chỉ hỗ trợ xác định mối quan hệ giữa các sự kiện và trạng thái, trong khi việc nhận diện các sự kiện và trạng thái từ mô tả bằng ngôn ngữ tự nhiên vẫn chưa được đề cập Điều này có thể khiến người dùng gặp khó khăn trong việc lựa chọn và xác định các sự kiện hoặc trạng thái một cách chính xác.

Chúng tôi đã phát triển các nguyên tắc dựa trên kinh nghiệm để chuyển đổi yêu cầu, nhằm thống nhất quy trình thực hiện và giảm thiểu sai sót Cần lưu ý rằng sự kiện hoặc trạng thái được mô tả ở đây có thể được áp dụng để diễn đạt yêu cầu xử lý trong các bối cảnh khác nhau.

2.3.1 Cặp sự kiện/trạng thái bắt đầu và kết thúc

Xây dựng hai sự kiện bắt đầu và kết thúc trong các trường hợp sau:

Trong trường hợp 1, các ca sử dụng (use case) cần được xác định rõ ràng với sự kiện bắt đầu và kết thúc Mọi sự kiện diễn ra trong ca sử dụng phải xảy ra sau sự kiện bắt đầu và trước sự kiện kết thúc, đảm bảo tính liên tục và mạch lạc trong quá trình thực hiện.

Trong ca sử dụng mô tả yêu cầu cập nhật điểm, sẽ có hai sự kiện quan trọng là start_update_grade và end_update_grade Các sự kiện con liên quan sẽ được xác định trong khoảng thời gian giữa start_update_grade và end_update_grade.

Trong trường hợp thứ hai, các yêu cầu có tính chất lặp cần có sự kiện bắt đầu và kết thúc Tất cả các hành động lặp lại sẽ được thực hiện giữa hai sự kiện này, cụ thể là sau sự kiện bắt đầu và trước sự kiện kết thúc.

Để thực hiện kiểm tra khóa học cho tất cả sinh viên, cần xác minh xem mỗi sinh viên có số khóa học lớn hơn 03 hay không.

Trong bài viết này, chúng tôi sẽ thảo luận về hai sự kiện quan trọng là start_check_student và end_check_student Việc kiểm tra số lượng khóa học có vượt quá 03 hay không sẽ được thực hiện trong khoảng thời gian giữa hai sự kiện này.

Xây dựng sự kiện đơn khi thấy có các trường hợp sau:

- Trường hợp 1: thể hiện tình trạng của hệ thống, ví dụ như “đăng nhập thành công” có thể chuyển thành sự kiện đơn login_successfully

- Trường hợp 2: thể hiện hoạt động của hệ thống, ví dụ như “kiểm tra số lượng khóa học” có thể chuyển thành sự kiện đơn check_number_of_courses

2.3.3 Sự kiện sau tinh chỉnh Đối với các yêu cầu cần được tinh chỉnh, sự kiện được xác định dựa vào yêu cầu sau tinh chỉnh Với ví dụ trong phần “2.2 Tinh chỉnh yêu cầu”, hai sự kiện đơn xảy ra ở đây là recv_authen_req và validate_user.

Xây dựng bảng hỏi

Bảng hỏi PROPEL cung cấp mô tả chi tiết về quy trình và phạm vi, được thể hiện trong hình 2.1 và 2.2 Trong bảng hỏi này, một số câu hỏi có sự phụ thuộc vào câu trả lời trước, như câu hỏi dòng 26 chỉ được hỏi khi người dùng chọn câu trả lời dòng 25 Bên cạnh đó, cũng có những câu hỏi sẽ được hỏi tiếp theo bất kể lựa chọn trước đó, chẳng hạn như câu hỏi dòng 13 luôn được hỏi bất chấp kết quả của câu hỏi dòng 10.

21 Hình 2.1: Bảng hỏi hoàn chỉnh cho mô tả xử lý của PROPEL [4]

Hình 2.2: Bảng hỏi hoàn chỉnh cho mô tả phạm vi của PROPEL [4]

Sau khi so sánh bảng hỏi PROPEL và SPSC, chúng tôi nhận thấy cần điều chỉnh một số phần để hướng dẫn người dùng chuyển từ ngôn ngữ tự nhiên sang SPSC Cụ thể, SPSCQT (SPSC Question Tree - bảng hỏi dành cho SPSC) cần thực hiện các thay đổi cần thiết từ bảng hỏi của PROPEL.

- Điều chỉnh một lựa chọn để mô tả phạm vi (scope) để tránh trùng lặp

- Bổ sung một số lựa chọn dành cho mô tả xử lý với 01 sự kiện/trạng thái

Điều chỉnh các lựa chọn mô tả xử lý cho hai sự kiện hoặc trạng thái, với nhiều câu hỏi chỉ liên quan đến hoặc có thể quy về một sự kiện cần được chuyển đổi thành dạng một sự kiện duy nhất.

- Bổ sung toàn bộ bảng hỏi dành cho mô tả xử lý với 03 sự kiện/trạng thái (do PROPEL chỉ hỗ trợ tối đa 02 sự kiện/trạng thái)

- Bổ sung toàn bộ bảng hỏi dành cho 04 sự kiện/trạng thái (do PROPEL chỉ hỗ trợ tối đa 02 sự kiện/trạng thái)

- Bổ sung toàn bộ bảng hỏi dành cho các mô tả xác xuất (SPSG)

2.4.2 Bảng hỏi dành cho SPSC (SPSCQT)

Trong các bảng hỏi dưới đây, những câu hỏi và lựa chọn đã được bổ sung hoặc chỉnh sửa so với bộ câu hỏi gốc của PROPEL sẽ được in nghiêng và gạch chân.

2.4.2.1 Bảng hỏi phân biệt yêu cầu có/không có tính xác suất Đối với câu trả lời có, các câu hỏi sẽ tiếp tục theo cấu trúc của phần 2.4.2.3 Bảng hỏi dành cho yêu cầu có tính xác suất, nếu không sẽ tiếp tục theo cấu trúc của phần 2.4.2.2 Bảng hỏi dành cho yêu cầu không có tính xác suất

Bảng 2.1: Bảng hỏi phân biệt yêu cầu có/không có tính xác suất

Does this requirement have probabilistic quality properties?

2.4.2.2 Bảng hỏi dành cho yêu cầu không có tính xác suất

2.4.2.2.1 Bảng hỏi dành cho xử lý 01 sự kiện

Bảng 2.2: Bảng hỏi dành cho xử lý 01 sự kiện

How many events of primary interest are there in this behavior?

- Which of the following choices best describes the restriction of A? - A is never allowed to occur

- A is required to occur throughout the given scope (*)

- A is required to occur at least k times (***)

- A is required to occur exactly k times (***)

The inclusion of option (*) highlights the "universality" model of SPSC, while option (**) signifies the "existence" model Additionally, options (***) are incorporated based on potential scenarios within the "bounded existence" model, necessitating the addition of the corresponding SPSC for these cases.

2.4.2.2.2 Bảng hỏi dành cho 02 sự kiện

- Which of the following choices best describes how A and B interact? - If A occurs, B is required to occur subsequently

- B is not allowed to occur until after A occurs

- Both statements above: If A occurs, B is required to occur subsequently; and B is not allowed to occur until after A occurs

- If A occurs then there is at least one execution sequence such that B eventually occurs (*)

Lựa chọn (*) được bổ sung để thể hiện khả năng trong mẫu SPSC Các câu hỏi khác trong PROPEL đã được loại bỏ vì chỉ liên quan đến một sự kiện hoặc trạng thái duy nhất Ví dụ, câu hỏi về khả năng A xuất hiện nhiều lần trước khi B xuất hiện có thể được chuyển thành mô tả đơn giản hơn.

“Before B” trong phạm vi và A ở xử lý 1 sự kiện

- Which of the following choices best describes how A, B and C interact?

- If A occurs and is succeeded by B, then C previously occurs

- If A occurs, then B previously occurs and was preceded by C

- If A occurs, then B eventually occurs and is succeeded by C

- If A occurs and is succeeded by B, then C eventually occurs after B - If A and B occurs simutaniously, then C eventually occurs

Trong SPSC, các lựa chọn được bổ sung tương ứng với các mẫu như sau: chuỗi ưu tiên 1 - 2, chuỗi ưu tiên 2 - 1, chuỗi phản hồi 1 - 2, và chuỗi phản hồi 2 - 1 Lựa chọn cuối cùng được thêm vào để thể hiện rằng khi cả trường hợp A và B đều thỏa mãn, thì C sẽ xảy ra Đối với lựa chọn này, cần phải bổ sung SPSC.

- Which of the following choices best describes how A, B and C interact?

- If A occurs then B eventually occurs and is succeeded by C, where D does not occur between B and C

Lựa chọn được thêm vào tương ứng với mẫu “constrain chain” trong SPSC

2.4.2.2.5 Bảng hỏi dành cho phạm vi

Bảng hỏi trong nghiên cứu PROPEL đã loại bỏ câu hỏi cuối cùng, vì nó chỉ nhằm làm rõ nghĩa mà không ảnh hưởng đến kết quả mẫu trong SPSC.

2.4.2.3 Bảng hỏi dành cho yêu cầu có tính xác suất

Bảng hỏi được phân loại thành ba loại sự kiện: 1 sự kiện, 2 sự kiện và 3 sự kiện, dựa trên các mẫu tương ứng Nguyên tắc xác định mối quan hệ giữa các sự kiện được thực hiện trước, sau đó là việc xác định khung thời gian và xác suất xảy ra.

Do bảng hỏi tương đối dài nên để tránh trùng lặp, có thể tham khảo trong bảng thống kê phần 2.4.3 dưới đây

2.4.3 Bảng thống kê tương ứng giữa SPSCQT và SPSC

Bảng thống kê này thể hiện sự tương ứng giữa các câu trả lời và kết quả của SPSC theo số thứ tự Chẳng hạn, câu trả lời số 9 "Hành vi cần được giữ trước lần xuất hiện đầu tiên của A" tương ứng với kết quả SPSC là phạm vi "Trước A".

Các hình 2.3, 2.4, 2.5 trong các trang tiếp theo thể hiện bảng hỏi SPSCQT hoàn chỉnh

Hình 2.3: Bảng hỏi SPSCQT - phần 1

27 Hình 2.4: Bảng hỏi SPSCQT - phần 2

2.4.3.2 Mô tả tương ứng trong SPSC

Hình 2.7: Mô tả tương ứng trong SPSC - Phần 1

31 Hình 2.8: Mô tả tương ứng trong SPSC - Phần 2

Áp dụng và mở rộng SPSC

Phần mềm hỗ trợ

3.1.1 Chức năng của phần mềm Để thuận tiện cho việc chuyển đổi từ ngôn ngữ tự nhiên sang SPSC, chúng tôi đã xây dựng phần mềm hỗ trợ Phần mềm này thực hiện các chức năng sau:

- Cho phép thêm mới/sửa/xóa các yêu cầu (trong đó cho phép sửa nội dung mô tả bằng ngôn ngữ tự nhiên)

- Đối với mỗi yêu cầu, phần mềm sẽ đưa ra câu hỏi và các lựa chọn để giúp người dùng tìm được mô tả phù hợp trong SPSC

- Xuất ra file định dạng doc để dễ dàng trao đổi với các bên liên quan

Giao diện trang chủ của phần mềm như trong Hình 3.1

Hình 3.1: Trang chủ phần mềm hỗ trợ

3.1.1.1 Thêm/sửa/xóa tên yêu cầu

Hình 3.2 thể hiện giao diện cho phép người dùng thêm/sửa/xóa tên các yêu cầu của hệ thống

Hình 3.2: Giao diện thêm/sửa/xóa yêu cầu

3.1.1.2 Xem chi tiết yêu cầu

Sau khi nhập tên yêu cầu, người dùng sẽ được chuyển đến giao diện chính, nơi hiển thị tất cả các yêu cầu ở phía bên trái màn hình, như thể hiện trong Hình 3.3.

Hình 3.3: Giao diện xem chi tiết yêu cầu

Khi người dùng nhấp vào tên yêu cầu, hệ thống sẽ hiển thị thông tin liên quan bên phía bên phải màn hình, bao gồm nội dung yêu cầu bằng ngôn ngữ tự nhiên trong phần "Description" và yêu cầu đã được chuyển đổi sang SPSC trong phần "corresponding SPS".

3.1.1.3 Chỉnh sửa mô tả yêu cầu bằng ngôn ngữ tự nhiên

Người dùng có thể chỉnh sửa nội dung yêu cầu bằng ngôn ngữ tự nhiên bằng cách vào giao diện xem chi tiết yêu cầu và nhấp vào “Edit description” Hệ thống sẽ cho phép điều chỉnh phần mô tả như hình 3.4.

Hình 3.4: Giao diện chỉnh sửa mô tả yêu cầu bằng ngôn ngữ tự nhiên

3.1.1.4 Cung cấp bảng hỏi hỗ trợ sinh mô tả trong SPSC

Để chỉnh sửa phần SPSC của yêu cầu, người dùng chỉ cần nhấn vào “Generate SPS” trong giao diện “Xem chi tiết yêu cầu” Hệ thống sẽ hiển thị bảng hỏi với hướng dẫn xử lý theo mô tả trong phần 2.4.3, kèm theo bảng thống kê tương ứng giữa SPSCQT và SPSC.

Nếu người dùng trả lời rằng yêu cầu này không có tính xác suất, hệ thống sẽ chuyển sang câu hỏi tiếp theo liên quan đến phạm vi.

Hình 3.5: Giao diện câu hỏi mô tả phạm vi

Nếu người dùng chọn lựa chọn thứ hai (No) thì hệ thống sẽ trả về phạm vi tương ứng là “Globally” như trong hình 3.6

Hình 3.6: Giao diện trả về kết quả phạm vi

Và hệ thống sẽ tiếp tục hỏi đến mô tả hành vi như trong hình 3.7

Hình 3.7: Giao diện câu hỏi mô tả xử lý

Nếu người dùng chọn “Two events”, hệ thống sẽ cho phép người dùng nhập tên của 02 sự kiện

Sau khi người dùng nhập tên sự kiện, hệ thống sẽ tiếp tục yêu cầu thông tin về mối quan hệ giữa các sự kiện Tên sự kiện được chèn vào các câu hỏi và câu trả lời, tạo ra giao diện trực quan và dễ hiểu cho người dùng.

Hình 3.9: Giao diện câu hỏi mối quan hệ giữa các sự kiện

Nếu người dùng chọn câu trả lời đầu tiên (như đánh dấu trên Hình 3.9), hệ thống trả về kết quả mô tả tương ứng trong SPSC như trong hình 3.10

Hình 3.10: Giao diện kết quả chuyển đổi sang SPSC

3.1.1.5 Xuất file văn bản định dạng doc

Khi có ít nhất một mô tả yêu cầu trong SPSC, người dùng có thể dễ dàng xuất file văn bản định dạng doc bằng cách nhấn vào nút “Export all” File văn bản được xuất ra sẽ có định dạng tương tự như hình minh họa.

Hình 3.11: File văn bản xuất ra từ phần mềm

3.1.2 Thiết kế và khả năng mở rộng

Do đặc tính của bảng hỏi, nó được lưu trữ trong file XML, như minh họa trong bảng 3.1 Với cấu trúc này, việc điều chỉnh bảng hỏi trở nên dễ dàng, chỉ cần sửa đổi trực tiếp trong XML mà không cần phải lập trình lại toàn bộ phần mềm.

Phần mềm này được phát triển để tương thích với các bảng hỏi phức tạp hơn so với bảng hỏi hiện tại, cho phép xử lý nhiều yêu cầu cùng một lúc.

Trong tương lai, khi mở rộng bộ luật, mỗi yêu cầu trong SPSC có thể có nhiều mô tả tương ứng, cho phép nhiều luật cùng thỏa mãn Phần mềm này được thiết kế linh hoạt để đáp ứng các tình huống này mà không cần phải lập trình lại.

Bảng 3.1: Cấu trúc file XML của bảng hỏi

SPSC Question Tree

Does this requirement have probabilistic quality properties?

Is the behavior only required to hold within restricted interval(s) in the event sequence?

No, the behavior is required to hold through out the entire event sequence

How many events are there in this scope?

One events

Two events

Sử dụng SPSC để mô tả yêu cầu

3.2.1 Bộ yêu cầu chức năng

The IBM course registration system encompasses eight key functionalities: closing the registration process, logging in, managing professor information, maintaining student information, registering for courses, selecting courses to teach, submitting grades, and viewing report cards.

Do giới hạn trong việc trình bày luận văn và tính chất tương tự của một số ca sử dụng, phần áp dụng này chỉ tập trung vào hai ca sử dụng đại diện: ca sử dụng đăng nhập và ca sử dụng kết thúc quá trình đăng ký Ca sử dụng đăng nhập, với quy trình tương đối đơn giản, sẽ được mô tả chi tiết để minh họa quá trình chuyển đổi Ngược lại, ca sử dụng kết thúc quá trình đăng ký có độ phức tạp cao hơn, giúp chứng minh khả năng mô tả của SPSC trong các tình huống phức tạp.

3.2.1.1 Ca sử dụng Đăng nhập (login)

Dựa vào nguyên tắc đã trình bày, ta xác định được cặp sự kiện bắt đầu và kết thúc ca sử dụng là recv_login_reg và end_login

Các sự kiện đơn là: show_login_interface, recv_authen_req, user_exist, login_successfully, user_not_exist, login_unsuccessfully, return_error, cancel_login

3.2.1.1.2 Xác định quan hệ giữa các sự kiện

Ta bắt đầu thực hiện chuyển đổi lần lượt từng yêu cầu, bắt đầu từ yêu cầu đầu tiên (ký hiệu là RP1)

The use case initiates when the user intends to access the Course Registration system, which is currently in the login state and displaying the login screen.

The requirement should be refined to state, "After the system receives the login request, it displays the login interface." Following the application of the questionnaire, the representation in SPSC will be as follows:

“Globally, it is always the case that if recv_login_reg holds then show_login_interface eventually holds.”

Mô tả này được sử dụng làm ví dụ cho chức năng trong phần “3.1.1 Chức năng của phần mềm”, giúp người đọc hiểu rõ hơn về cách thức hoạt động của phần mềm.

RP2: The actor enters his/her name and password The system validates the entered name and password and logs the actor into the system

The requirement should be refined to: "After the system receives a login request, it validates the entered username and password, subsequently logging the user into the system." We have identified the following events: recv_authen_req, validate_user, user_exist, and login_successfully.

Khi sử dụng bảng hỏi, chúng ta sẽ thấy đường đi của các câu hỏi và trả lời như sau:

- Is the behavior only required to hold within restricted interval(s) in the event sequence?

- How many events of primary interest are there in this behavior?

- Which of the following choices best describes how recv_authen_req and validate_user interact?

- Both statements above: If recv_authen_req occurs, validate_user is required to occur subsequently; and validate_user is not allowed to occur until after recv_authen_req occurs

Người dùng thường có xu hướng chọn ba hoặc bốn sự kiện để thể hiện mối quan hệ giữa chúng, thay vì chỉ hai sự kiện như trong bảng hỏi và trả lời Tuy nhiên, nếu cảm thấy không phù hợp, họ sẽ quay lại và lựa chọn từng cặp hai sự kiện để biểu diễn một cách chính xác hơn.

Với hai sự kiện đầu tiên (recv_authen_req và validate_user), theo cách trả lời như trên, kết quả trong SPSC sẽ như sau:

“Globally, it is always the case that if receive_login_req holds then validate_user eventually holds

Globally, it is always the case that if validate_user holds then receive_login_req previously held.”

Tiếp tục áp dụng bảng hỏi cho cặp sự kiện tiếp theo, ta sẽ có:

“After validate_user, it is always the case that if user_exist holds then login_successfully eventually holds.”

Tương tự như vậy, ta áp dụng cho tất cả các yêu cầu còn lại:

In the Basic Flow of the RP3 use case, if the actor inputs an invalid username or password, the system responds by displaying an error message The actor then has the option to either restart the Basic Flow or cancel the login attempt, leading to the conclusion of the use case.

“After validate_user, it is always the case that if user_not_exist holds then login_unsuccessfully eventually holds and is succeeded by return_error

After login_unsuccessfully, if return_error holds then there is at least one execution sequence such that cancel_login holds

After login_unsuccessfully, it is always the case that if return_error holds then there is at least one execution sequence such that recv_login_req holds

After login_unsuccessfully, it is always the case that if return_error holds and is succeeded by cancel_login, then end_login eventually holds after cancel_login.”

RP4: Post-conditions: If the use case was successful, the actor is now logged into the system If not, the system state is unchanged

Trạng thái login_successfully xác nhận người dùng đã đăng nhập thành công vào hệ thống Nếu quá trình đăng nhập không thành công, trạng thái của hệ thống sẽ không bị thay đổi.

3.2.1.2 Ca sử dụng Kết thúc việc đăng ký (Close registration)

Thay vì mô tả chi tiết quy trình chuyển đổi như trong các ca sử dụng đăng nhập, bài viết này chỉ tập trung vào việc liệt kê các yêu cầu và kết quả chuyển đổi Mục đích là để thể hiện khả năng mô tả của SPSC đối với những ca sử dụng phức tạp.

The use case initiates when the Registrar requests the system to close registration It is essential for the Registrar to be logged into the system for this process to commence.

“After login_successfully, it is always the case that if recv_close_req holds then curuser_is_Registrar previously held.”

The RP6 system verifies if registration is currently in progress If so, it alerts the Registrar with a message, and the use case concludes Closing registration cannot occur while registration is ongoing.

During the registration process, specifically between the start and close registration phases, if the recv_close_req condition is met, it will ultimately lead to a return_error This return_error will be followed by the end_close_reg phase, ensuring that no events occur between the display_error and the end_close_reg stages.

The system verifies that a professor is assigned to teach each course offering and that a minimum of three students are enrolled If these criteria are met, the course offering is confirmed for all relevant schedules.

“Between recv_close_req and end_close_reg, there are transitions to states in which start_check_course holds at most 1 times

Between recv_close_req and end_close_reg, if start_check_course holds, then end_check_course eventually holds

Between recv_close_req and end_close_reg, if end_check_course holds, then start_check_course previously held

Between start_check_course and end_check_course, start_check_a_course holds exactly n times (n is the number of course)

Between start_check_course and end_check_course, it is always the case that if start_check_a_course holds then end_check_a_course eventually holds

Between start_check_course and end_check_course, it is always the case that if end_check_a_course holds then start_check_a_course previously held

In the context of the process between start_check_a_course and end_check_a_course, it can be asserted that when both course_is_signup and course_has_more3stds are true at the same time, the condition commit_course will ultimately be satisfied.

Kết quả áp dụng và mở rộng SPSC

Kết quả áp dụng trên tổng cộng 60 yêu cầu chức năng (đối với 08 ca sử dụng) và 08 yêu cầu phi chức năng cho thấy:

- Đối với yêu cầu chức năng: Bằng cách mở rộng SPSC thêm 03 luật, hoàn toàn có thể mô tả được 100% các yêu cầu chức năng

SPSC hiện chỉ mô tả được 5 trong số 8 yêu cầu phi chức năng, tương đương 62.5% tổng số yêu cầu Các yêu cầu chưa được mô tả bao gồm yêu cầu về hiệu năng liên quan đến khả năng phản hồi của hệ thống với nhiều người dùng, yêu cầu về tính sử dụng và yêu cầu về ràng buộc thiết kế.

Toàn bộ yêu cầu bảo mật trong bộ mẫu kiểm chứng được mô tả bằng các luật trong SPSKC, mà nhóm nghiên cứu của BOSCH cho rằng không thể diễn đạt các yêu cầu phi chức năng.

Khi xây dựng bảng hỏi, câu hỏi đầu tiên nên là “đây có phải là yêu cầu có tính xác suất hay không” thay vì “đây có phải yêu cầu chức năng hay không” Điều này bởi vì một số yêu cầu phi chức năng có thể được diễn đạt bằng bộ luật mô tả tương tự như yêu cầu chức năng.

3.3.2 Các luật được mở rộng trong SPSC

3.3.2.1 Chi tiết hóa luật “bounded existence”

The SPSC initially featured a single law known as "bounded existence," which is defined by the principle that "transitions to states in which P holds occur at most twice." To adequately address the requirements, this concept has been further elaborated into three distinct categories, as outlined in Table 3.2.

Bảng 3.2: Chi tiết hóa luật "bounded existence"

1 there are transitions to states in which A holds at least k times

2 it is always the case that A holds exactly k times

3 there are transitions to states in which A holds at most k times

3.3.2.2 Bổ sung luật về “simutaneously response”

Trong quá trình mô tả yêu cầu, một số sự kiện chỉ xảy ra khi hai sự kiện khác diễn ra đồng thời Vì vậy, cần bổ sung luật như được trình bày trong bảng dưới đây.

Bảng 3.3: Bổ sung luật "simutaneously response"

If A and B holds simutaniously, then C eventually holds

Tiêu đề	Chuyển Ngôn Ngữ Trong Biểu Diễn Yêu Cầu Phần Mềm
Tác giả	Nguyễn Thị Huyền Trang
Người hướng dẫn	PGS. TS. Trương Ninh Thuận
Trường học	Đại Học Quốc Gia Hà Nội
Chuyên ngành	Công Nghệ Thông Tin
Thể loại	luận văn thạc sĩ
Năm xuất bản	2013
Thành phố	Hà Nội

Định dạng
Số trang	82
Dung lượng	2,04 MB