mở đầu phát triển các yêu cầu dễ dàng hơn là các mẫu sẵn có. Các yêu cầu Những góp ý, thông tin bổ sung giúp ích cho phát triển các bổ sung yêu cầu sau này 8. Những gợi ý Những gợi ý cho các lập trình viên về cách thức cài đặt các cho thiết kế và yêu cầu thuộc dạng RP này lập trình 9. Những gợi ý Những gợi ý cho việc thực hiện kiểm thử các yêu cầu thuộc cho kiểm thử dạng RP này Có thể nói RP đã tạo một bước tiến đáng kể, giúp cho việc mô tả các yêu cầu trở nên rõ ràng và thống nhất hơn.
Các yêu cầu khác nhau (nhưng cùng loại) sử dụng cùng một mẫu RP sẽ có cấu trúc giống nhau, giúp đảm bảo có đầy đủ những thành phần cơ bản. Tuy nhiên, do RP không phải là một bộ cố định, chất lượng của từng RP phụ thuộc vào kinh nghiệm của người/nhóm người tạo nên nó. Thêm vào đó, khi áp dụng, việc lựa chọn RP nào để thể hiện yêu cầu cũng đòi hỏi khả năng của người phân tích yêu cầu. Như vậy, RP lại vấp phải vấn đề về chất lượng không đồng đều và phụ thuộc vào kinh nghiệm và kỹ năng cá nhân chuyên gia xây dựng/sử dụng RP.
Đồng thời, RP cũng chưa giải quyết được vấn đề đặt ra về việc 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ả.2 Mẫu đặc tả Trong khi một số nhóm nghiên cứu tiếp tục đi theo hướng cập nhật, bổ sung các RP sẵn có như nghiên cứu xây dựng RP cho các yêu cầu phi chức năng 10 z 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ột mẫu đặc tả thuộc tính là một mô tả tổng quát hóa của một yêu cầu xảy ra thường xuyên trong một chuỗi trạng thái/sự kiện chấp nhận được trong một mô hình hệ thống trạng thái hữu hạn. Một mẫu đặc tả mô tả cấu trúc cơ bản của một khía cạnh nào đó thuộc hành vi của một hệ thống và đưa ra những biểu thức của hành vi đó trong phạm vi của những hình thức phổ biến”. SP cũng gần với mục đích của RP, nhưng với yêu cầu chặt chẽ hơn là phải chuyển được sang một hệ thống logic nào đó như MTL, TCTL, RTGIL.
Năm 1999, Dywer và các cộng sự [10] đã đưa ra tư tưởng về việc mô tả các yêu cầu về mặt xử lý của hệ thống bằng các SP gồm 2 phần là phạm vi (scope) và hành vi (behavior). Đồng thời, họ cũng đưa ra tư tưởng phân chia các mẫu mô tả dựa trên các xử lý của hệ thống mà chúng mô tả (có thể thấy trong ví dụ hình 1. Mẫu mô tả sự xuất hiện (Occurrence pattern) mô tả khả năng xảy ra của một sự kiện hoặc một trạng thái trong suốt quá trình vận hành của hệ thống. Mẫu mô tả thứ tự (Order pattern) mô tả mối liên hệ về thứ tự của các sự kiện hoặc các trạng thái trong quá trình vận hành của hệ thống.1: Phân chia mẫu yêu cầu của Dywer [7] Trong đó, mẫu mô tả sự xuất hiện chỉ liên quan đến một sự kiện hoặc một xử lý.
Mẫu này được chia nhỏ hơn nữa thành các loại: không xảy ra (absence), có khả năng xuất hiện (existence), có khả năng xuất hiện trong một giới hạn nào đó (bounded existence), xuất hiện trong suốt quá trình (universality). Mẫu mô tả thứ tự liên quan đến nhiều hơn một sự kiện hoặc mô tả xử lý. Mẫu loại này được chia nhỏ hơn thành các loại: liên hệ trước (precedence), liên hệ trước theo chuỗi (chain precedence), liên hệ sau (chain response), liên hệ sau theo chuỗi (chain response).3 Luật mô tả yêu cầu (SPS) SP đã giúp chúng ta tới gần với việc hình thức hóa yêu cầu phần mềm nhưng việc rút ngắn khoảng cách giữa yêu cầu bằng ngôn ngữ tự nhiên và ngôn ngữ hình thức chỉ thực sự có triển vọng khi Konrad và Cheng đưa ra đề xuất về việc xây dựng một luật mô tả yêu cầu (SPS – specification pattern system) gồm một bộ các từ vựng và cú pháp giới hạn của ngôn ngữ tự nhiên để thể hiện yêu cầu, mà vẫn đảm bảo việc tự động chuyển nó sang các dạng logic như LTL, CTL, GIL, MTL, TCTL, RTGIL.1 SPSKC – SPS xây dựng bởi Konrad và Cheng Năm 2005, dựa vào mẫu đặc tả áp dụng cho hệ thống thời gian thực xây dựng bởi Dywer như trong hình 1.1, Konrad và Cheng đã xây dựng mô hình SPS của họ như trong hình 1.2: SPS xây dựng bởi Konrad và Cheng [2] 12 z Có thể thấy SPSKC thừa kế nền tảng mà Dwyer đã xây dựng: một yêu cầu được mô tả bởi phạm vi và xử lý. Trong đó phạm vi được chia nhỏ thành các loại: toàn cục/toàn thể (globally), trước sự kiện/trạng thái R (before R), sau sự kiện/trạng thái Q (after Q), giữa hai sự kiện/trạng thái R và Q (between R and Q), sau sự kiện/trạng thái R cho đến khi sự kiện/trạng thái Q xảy ra (after R until Q).
Xử lý gồm có hai kiểu lớn là kiểu định tính (quanlitative type) và kiểu thời gian thực (real-time type). Trong đó mỗi kiểu lại được chia thành các dạng nhỏ bên trong. Ví dụ như một yêu cầu: “tại mọi thời điểm, người dùng chỉ có thể xem thông tin sau khi đăng nhập” sẽ được xây dựng bằng cách nối phạm vi toàn cục (globally) với xử lý dạng liên hệ trước (precedence), thành: “Globally, it is always the case that if view_information holds, then logged_on previously held”. Thông thường, yêu cầu ở dạng ngôn ngữ tự nhiên và yêu cầu mô tả bằng SPSKC sẽ được thực hiện theo mối quan hệ 1 – 1, nhưng trong một số trường hợp có thể sẽ là quan hệ 1 – 2.
Ví dụ sau được cung cấp bởi nhóm nghiên cứu tại BOSCH và đại học Freiburg trong bài báo xuất bản năm 2012 có tiêu đề “Automotive behavioral requirements expressed in a specification: a case study at BOSCH”. Yêu cầu ở dạng ngôn ngữ tự nhiên: “If the transition condition ChangeGear comes true, the system shall stay for at least 50 ms in state F and then change into the state 0 (after at most 100 ms)” khi chuyển sang theo dạng SPSKC sẽ là sự kết hợp giữa mẫu “bounded invariance” và mẫu “bounded response”, tức là: “Globally, it is always the case that if ChangeGear holds, then StateF holds for at least 50 time unit(s)” và “Globally, it is always the case that if ChangeGear holds, then State0 holds after at most 100 time unit(s)”. Trong nghiên cứu nói trên, nhóm nghiên cứu đã thử nghiệm việc áp dụng SPSKC vào thể hiện 289 yêu cầu xử lý (behaviorral requirements) phục vụ cho quá trình sản xuất ô tô. Kết quả thử nghiệm chỉ ra rằng SPSKC có thể thể hiện được 84% của 289 yêu cầu nói trên.
Trong số 16% còn lại (39 yêu cầu) thì có 25 yêu cầu có thể thể hiện bằng cách bổ sung thêm 3 luật mô tả cho SPSKC còn 14 yêu cầu không thực sự là yêu cầu xử lý (do sai sót trong quá trình lựa chọn bộ yêu cầu để thể hiện).2 SPSG – SPS xây dựng bởi Grunske Như đã trình bày trong phần trên, dù đã thể hiện được một lượng lớn các mẫu yêu cầu chức năng, theo nhóm nghiên cứu của BOSCH và Freiburg thì SPSKC vẫn chưa thể hiện được các yêu cầu phi chức năng (điều mà về sau luận văn này chỉ ra rằng không hoàn toàn chính xác). Do đó, năm 2008, Grunske đã phát triển một SPS có thể thể hiện các yêu cầu về tính sẵn sàng, độ tin cậy, sự an toàn, bảo mật và hiệu năng [6].3 dưới đây thể hiện cấu trúc của SPSG (SPS xây dựng bởi Grunske).3: SPS xây dựng bởi Grunske [6] Để dễ hiểu, chúng ta có thể lấy ví dụ một yêu cầu hiệu năng: “Hệ thống phải có khả năng phản hồi trong vòng tối đa 10 giây đối với 80% số yêu cầu gửi đến”.3 thể hiện, ta có thể chọn probabilisticResponse với 14 z upperTimeBound, ta sẽ được: “The system shall have a behavior where with a probability 80% it is the case that after receive_request holds, then as a response send_answer becomes true within 10 seconds”.4 PROPEL - Công cụ hỗ trợ xác định yêu cầu Mặc dù các yêu cầu được thể hiện bằng các cấu trúc và từ vựng giới hạn của tiếng anh, việc đòi hỏi một người không chuyên về logic tự xác định và tìm ra cấu trúc logic nào phù hợp để thể hiện yêu cầu vẫn là một thách thức lớn. Để giải quyết vấn đề này, một số nhóm nghiên cứu đi theo hướng sử dụng các kỹ thuật xử lý ngôn ngữ tự nhiên để phân tích yêu cầu như dự án Attempto Controlled English [13] hay gần đây nhất là nhóm nghiên cứu của Đại học California tìm cách tự động xác định các mẫu LTL trong yêu cầu viết bằng ngôn ngữ tự nhiên [1]. Tuy nhiên các nghiên cứu này vẫn còn rất xa mới có thể áp dụng vào thực tế phân tích yêu cầu, bởi ngôn ngữ tự nhiên vốn mập mờ và thường không rõ ràng.
Quá trình chuyển đổi ngôn ngữ trong luận văn này cũng cho thấy kể cả ví dụ mẫu của IBM cũng cần phải bổ sung thêm thông tin mới có thể chuyển sang SPSC. Một phương pháp ít tham vọng hơn và có độ chính xác cao hơn là PROPEL – công cụ sử dụng hệ thống câu hỏi để hướng dẫn người dùng tìm ra biểu diễn hợp lý [4]. Theo thống kê tác giả, PROPEL có thể giúp tìm ra các yêu cầu với độ chính xác 95%. Công cụ này cung cấp ba giao diện, trong đó đưa ra câu hỏi và các lựa chọn trả lời, giúp người dùng dễ dàng xác định mối liên quan giữa các sự kiện/trạng thái trong yêu cầu hệ thống.
Ba giao diện bao gồm: • Giao diện bảng hỏi dạng cây (QT), đưa ra câu hỏi và các câu trả lời để người dùng lựa chọn, qua đó giúp người dùng có thể chọn mẫu đặc tả thuộc tính phù hợp. • Giao diện đồ họa mô phỏng máy trạng thái hữu hạn mở rộng (Finite-State Automata - FSA) giúp đảm bảo sự chuẩn xác của yêu cầu; • Giao diện ngôn ngữ tự nhiên (DNL) giúp người dùng có thể dễ dàng hiểu được Việc sử dụng bảng hỏi sẽ giúp cho người dùng xác định được chính xác mối quan hệ về logic mà không cần thiết phải biết sâu về các ngôn ngữ logic. Ví dụ dễ thấy là việc thường xuyên nhầm lẫn giữa hai phạm vi “after A until B” và “between A and B”.