Tài liệu Chuyển ngôn ngữ trong biểu diễn yêu cầu phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ HUYỀN TRANG CHUYỂN NGÔN NGỮ TRONG BIỂU DIỄN YÊU CẦU PHẦN MỀM LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN HÀ NỘI - 2013 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ HUYỀN TRANG CHUYỂN NGÔN NGỮ TRONG BIỂU DIỄN YÊU CẦU PHẦN MỀM Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60.48.10 LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. Trương Ninh Thuận HÀ NỘI – 2013 MỤC LỤC DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ .................................. 2 DANH MỤC HÌNH ẢNH .............................................................................. 3 DANH MỤC BẢNG BIỂU ............................................................................ 4 Chương I: Tổng quan ..................................................................................... 5 1.1 Đặt vấn đề ........................................................................................... 5 1.2 Tổng quan tình hình nghiên cứu .......................................................... 6 1.2.1 Mẫu yêu cầu .............................................................................. 6 1.2.2 Mẫu đặc tả ............................................................................... 10 1.2.3 Luật mô tả yêu cầu (SPS) ......................................................... 12 1.2.4 PROPEL - Công cụ hỗ trợ xác định yêu cầu ............................ 15 Chương II: Phương pháp chuyển ngôn ngữ .................................................. 18 2.1 Phương pháp chuyển đổi ................................................................... 18 2.1.1 Mô tả yêu cầu trong thiết kế và lập trình hướng đối tượng ....... 18 2.1.2 Phương pháp chuyển đổi .......................................................... 18 2.2 Tinh chỉnh yêu cầu ............................................................................ 19 2.3 Xác định sự kiện ............................................................................... 19 2.3.1 Cặp sự kiện/trạng thái bắt đầu và kết thúc ................................ 19 2.3.2 Sự kiện đơn.............................................................................. 20 2.3.3 Sự kiện sau tinh chỉnh .............................................................. 20 2.4 Xây dựng bảng hỏi ............................................................................ 20 2.4.1 Bảng hỏi PROPEL ................................................................... 20 2.4.2 Bảng hỏi dành cho SPSC (SPSCQT) ....................................... 23 2.4.3 Bảng thống kê tương ứng giữa SPSCQT và SPSC ................... 26 Chương III: Áp dụng và mở rộng SPSC ....................................................... 34 3.1 Phần mềm hỗ trợ ............................................................................... 34 3.1.1 Chức năng của phần mềm ........................................................ 34 3.1.2 Thiết kế và khả năng mở rộng .................................................. 38 0 3.2 Sử dụng SPSC để mô tả yêu cầu ....................................................... 40 3.2.1 Bộ yêu cầu chức năng .............................................................. 40 3.2.2 Bộ yêu cầu phi chức năng ........................................................ 47 3.3 Kết quả áp dụng và mở rộng SPSC ................................................... 50 3.3.1 Kết quả áp dụng ....................................................................... 50 3.3.2 Các luật được mở rộng trong SPSC ......................................... 50 Chương IV: Kết luận .................................................................................... 52 4.1 Kết quả nghiên cứu ........................................................................... 52 4.2 Hướng nghiên cứu tiếp tục ................................................................ 52 TÀI LIỆU THAM KHẢO ............................................................................ 54 Phụ lục 1: Mẫu yêu cầu “Living Entity Requirement Pattern” ...................... 56 Phụ lục 2: Course Registration Requirements ............................................... 62 1 DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ TT Từ viết tắt/Thuật ngữ 1 RP Mẫu yêu cầu Requirement Pattern 2 SPS Hệ thống luật mô tả Specification Pattern System 3 SPSKC Hệ thống luật mô tả (SPS) đề xuất bởi Konrad và Cheng SPSG Hệ thống luật mô tả (SPS) đề xuất bởi Grunske (giúp mô tả những yêu cầu liên quan đến xác xuất) 5 SPSC Hệ thống luật mô tả kết hợp của SPSKC, SPSG và SPS về xác suất của nhóm nghiên cứu của BOSCH 6 LTL Linear Time Logic 7 CTL Computational Tree Logic 8 GIL Graphical Interval Logic 9 MTL Metric Temporal Logic 10 TCTL Timed Computational Tree Logic 11 RTGIL Real-time Graphical Interval Logic 12 NL 13 14 4 Giải thích/Định nghĩa Ghi chú Ngôn ngữ tự nhiên Natural language PROPEL Công cụ hướng dẫn người dùng xác định yêu cầu PROPerty ELuciator SPSCQT Bảng hỏi dành cho SPSC SPSC Question Tree 2 DANH MỤC HÌNH ẢNH Hình 1.1: Phân chia mẫu yêu cầu của Dywer [7] .......................................... 11 Hình 1.2: SPS xây dựng bởi Konrad và Cheng [2] ....................................... 12 Hình 1.3: SPS xây dựng bởi Grunske [6] ...................................................... 14 Hình 1.4: Bốn mô tả xử lý của PROPEL [4] ................................................. 16 Hình 1.5: Ví dụ về bảng hỏi của PROPEL [4] .............................................. 16 Hình 1.6: Giao diện FSA của PROPEL [4] ................................................... 17 Hình 2.1: Bảng hỏi hoàn chỉnh cho mô tả xử lý của PROPEL [4] ................ 21 Hình 2.2: Bảng hỏi hoàn chỉnh cho mô tả phạm vi của PROPEL [4] ............ 22 Hình 2.3: Bảng hỏi SPSCQT - phần 1 .......................................................... 26 Hình 2.4: Bảng hỏi SPSCQT - phần 2 .......................................................... 27 Hình 2.5: Bảng hỏi SPSCQT - phần 3 .......................................................... 28 Hình 2.6: Bảng hỏi SPSCQT - phần 4 .......................................................... 29 Hình 2.7: Mô tả tương ứng trong SPSC - Phần 1 .......................................... 30 Hình 2.8: Mô tả tương ứng trong SPSC - Phần 2 .......................................... 31 Hình 2.9: Mô tả tương ứng trong SPSC - Phần 3 .......................................... 32 Hình 2.10: Mô tả tương ứng trong SPSC - Phần 4 ........................................ 33 Hình 3.1: Trang chủ phần mềm hỗ trợ .......................................................... 34 Hình 3.2: Giao diện thêm/sửa/xóa yêu cầu ................................................... 34 Hình 3.3: Giao diện xem chi tiết yêu cầu ...................................................... 35 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 ......... 35 Hình 3.5: Giao diện câu hỏi mô tả phạm vi .................................................. 36 Hình 3.6: Giao diện trả về kết quả phạm vi .................................................. 36 Hình 3.7: Giao diện câu hỏi mô tả xử lý ....................................................... 36 Hình 3.8: Giao diện nhập tên sự kiện............................................................ 37 Hình 3.9: Giao diện câu hỏi mối quan hệ giữa các sự kiện ........................... 37 Hình 3.10: Giao diện kết quả chuyển đổi sang SPSC.................................... 38 Hình 3.11: File văn bản xuất ra từ phần mềm ............................................... 38 3 DANH MỤC BẢNG BIỂU Bảng 1.1: Phân loại mẫu yêu cầu của Withall ................................................. 7 Bảng 1.2: Cấu trúc chuẩn cho mẫu yêu cầu .................................................... 9 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 .................. 23 Bảng 2.2: Bảng hỏi dành cho xử lý 01 sự kiện ............................................. 23 Bảng 2.3: Bảng hỏi dành cho xử lý 02 sự kiện ............................................. 24 Bảng 2.4: Bảng hỏi dành cho xử lý 03 sự kiện ............................................. 24 Bảng 2.5: Bảng hỏi dành cho xử lý 04 sự kiện ............................................. 25 Bảng 3.1: Cấu trúc file XML của bảng hỏi ................................................... 39 Bảng 3.2: Chi tiết hóa luật "bounded existence" ........................................... 50 Bảng 3.3: Bổ sung luật "simutaneously response" ........................................ 51 4 1 1. Chương I: Tổng quan 1.1 Đặt vấn đề Yêu cầu phần mềm thường được mô tả bằng ngôn ngữ tự nhiên vốn được coi là nhập nhằng, thiếu tính rõ ràng. Các phương pháp hình thức hiện tại lạ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 vốn được coi là khá khó hiểu đối với nhóm phát triển (bao gồm người thiết kế, lập trình viên, người kiểm thử,…). Để giải quyết vấn đề nêu trên, Konrad và Cheng [12] đã đưa ra một hệ thống luật mô tả (SPSKC) xây dựng bởi một số lượng giới hạn các từ vựng và cấu trúc tiếng anh. SPSKC giúp ghi lại yêu cầu chức năng bằng một ngôn ngữ là tập con của ngôn ngữ tự nhiên (tiếng anh) mà lại có thể dịch tự động sang logic hình thức. Tuy nhiên, SPSKC lại gặp vấn đề khi không mô tả các yêu cầu phi chức năng. Để bổ sung điểm yếu này, chúng ta có thể kết hợp thêm với hệ thống luật mô tả đưa ra bởi Grunske L (SKSG) [6]. Năm 2012, của nhóm nghiên cứu của BOSCH và nhóm nghiên của đại học Freiburg [2] đã kết hợp để kiểm chứng lại SPSKC trong phạm vi đặc biệt (công nghiệp ô tô), và trong phần phân tích họ cho rằng có thể sẽ rất hữu ích nếu xem xét việc mở rộng SPSKC bằng cách bổ sung thêm SPSG để thể hiện được những yêu cầu phi chức năng. Một vấn đề khác là nghiên cứu này không mô tả cách thức chuyển từ yêu cầu phần mềm bằng ngôn ngữ tự nhiên sang mô tả bằng SPS trong công bố này. Việc mô tả rõ phương pháp chuyển đổi là một việc vô cùng cần thiết để có thể khẳng định quá trình chuyển đổi có thực sự chính xác hay không, và là căn cứ để đánh giá kết quả chuyển đổi có đáng tin hay không. 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 (sau đây được gọi là SPSC) có đầy đủ để mô tả được các yêu cầu của một phần mềm hay không. - 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. Bộ mẫu sử dụng để kiểm chứng vấn đề đầu tiên là ví dụ mẫu cho phân tích yêu cầu trong tập tài liệu hướng dẫn “IBM rational software - Section 1: Course Registration Requirements” [8], với giả định rằng đây là bộ yêu cầu đủ rõ ràng và bao quát. 5 Công cụ hỗ trợ chuyển yêu cầu từ ngôn ngữ tự nhiên sang SPSC được xây dựng dựa trên ý tưởng dùng bảng hỏi trong phương pháp PROPEL (PROPerty ELucidation approach) được trình bày trong luận án tiến sĩ của Rachel L.Cobleigh [4]. 1.2 Tổng quan tình hình nghiên cứu Quá trình phát triển phần mềm thường gồm nhiều giai đoạn và gồm những công việc chính là phân tích yêu cầu, thiết kế hệ thống, lập trình sản phẩm, kiểm thử và phát hành tới khách hàng. Trước đây, khi một dự án thất bại (số tiền/thời gian thực hiện vượt quá kế hoạch ban đầu, sản phẩm quá nhiều lỗi,…), một số người thường nghĩ đó là lỗi của quá trình lập trình sản phẩm, nhưng thực tế không phải như vậy. Robert N. [3] đã thống kê 12 lỗi chính khiến cho một dự án phần mềm thất bại trên IEEE Spectrum inside technology, trong đó chỉ có 3 nguyên nhân liên quan trực tiếp đến kỹ thuật là “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”. Nghĩa là, xét về mặt kỹ thuật thì việc xác định chính xác yêu cầu phần mềm quan trọng không kém việc lựa chọn công nghệ và nâng cao kỹ năng lập trình. Chính vì lý do đó, sau một thời gian rất dài tập trung vào xây dựng các lý thuyết, công cụ để hỗ trợ lập trình, phát hiện lỗi và sửa lỗi khi lập trình, các chuyên gia phần mềm bắt đầu quan tâm đế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 bằng việc cố gắng đưa ra định nghĩa thế nào là một mô tả yêu cầu tốt. Trong cuốn sách “Software Engineering” xuất bản năm 2003, Karl E. Wiegers [9] cho rằng: “Một mô tả yêu cầu tốt đảm bảo đầy đủ các tiêu chí sau: hoàn thiện, chính xác, có thể hiện thực hóa, cần thiết, không nhập nhằng, có thể kiểm thử được và được đánh giá về mức độ quan trọng”. Dựa trên đó, ông đề xuất một số mẫu (template) tài liệu phân tích yêu cầu và đưa ra các hướng dẫn viết mô tả yêu cầu như: viết câu hoàn chỉnh, sử dụng thể chủ động, sử dụng những từ khóa đã được định nghĩa, sử dụng hình ảnh bổ sung để mô tả yêu cầu… 1.2.1 Mẫu yêu cầu Mặc dù Karl E. Wiegers [9] đã đưa ra những hướng dẫn khá trực quan với những ví dụ rõ ràng, chúng vẫn còn khái quát, chưa cụ thể đủ để áp dụng trong 6 các trường hợp thực tế. Do đó, chất lượng của tài liệu mô tả yêu cầu vẫn phụ thuộc hầu như hoàn toàn vào khả năng và kinh nghiệm của bản thân người phân tích yêu cầu. Để giải quyết vấn đề này, các chuyên gia đưa ra “mẫu yêu cầu”. Mỗi mẫu yêu cầu (RP - requirement pattern) sẽ hướng dẫn cách mô tả một loại yêu cầu nhất định. Theo Stephen Withall [11]: “Ý tưởng của RP là cung cấp hướng dẫn cách xác định yêu cầu cho một số 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, dễ dàng, và có chất lượng tốt hơn”. Ông đã đưa ra 37 RPs mô tả 37 loại yêu cầu mà ông cho là phổ biến (được nhóm lại thành 8 nhóm) như 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 1 Tên nhóm Tên mẫu yêu cầu Yêu cầu cơ bản Công nghệ (technology) (Fundamental) 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) 2 Thông tin Kiểu dữ liệu (data type) (Information) Định danh (ID) Cấu trúc dữ liệu (data structure) Hàm tính toán (calculation formula) 7 Lưu trữ dữ liệu (data archive) Tồn tại của dữ liệu (data longevity) 3 Thực thể dữ liệu Thực thể dữ liệu (Data entity) (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 Giao diện người dùng (User interface) người dùng (user Truy vấn (Inquiry) function) Báo cáo (Report) Báo cáo (Reporting) Khả năng truy cập (Accessibility) 5 Hiệu năng Thời gian phản hồi (Response time) (Performance) 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) 6 Độ khả chuyển Unparochialness (Flexibility) Tính đa dạng (Multiness) Khả năng mở rộng (Scalability) Khả năng nâng cấp (Extendability) 8 Tính cài đặt được (Installability) Đa ngôn ngữ (Multi-lingual) 7 8 Thương mại Thuế/phí (Fee/tax) (Commercial) Đơn vị đa tổ chức (Multiorganization unit) Điều khiển truy cập Đăng ký tài khoản (User registration) (access control) 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 authorization) phân quyền (Configurable Tuy nhiên, 37 mẫu yêu cầu không thể đầy đủ để bao phủ tất cả các loại yêu cầu phần mềm. Do đó, Withall xây dựng 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ác công ty tự đưa ra mẫu yêu cầu cho các loại yêu cầu cần thiết tùy theo đặc điểm của cá nhân/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 Tên mẫu yêu cầu - 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 đó 1. Những chi tiết cơ bản - 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 - Tác giả của mẫu 2. Tính khả dụng 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 9 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 6. Ví dụ Một hoặc một vài các yêu cầu thực tế từ RP đó. Lưu ý đôi khi các ví dụ giúp 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ó. 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 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ả. 1.2.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 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.1 dưới đây). 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. Hình 1.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). 11 1.2.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.2.3.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 (sau đây gọi tắt là SPSKC). Hình 1.2: SPS xây dựng bởi Konrad và Cheng [2] 12 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). 13 1.2.3.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]. Hình 1.3 dưới đây thể hiện cấu trúc của SPSG (SPS xây dựng bởi Grunske). Hình 1.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”. Như hình 1.3 thể hiện, ta có thể chọn probabilisticResponse với 14 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”. 1.2.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”. Khi được hỏi, người dùng sẽ lựa chọn hoặc là: sau khi A xảy ra, xử lý vẫn sẽ xẩy ra cho dù B không xảy ra; hoặc là: sau khi A xảy ra, nếu 15 B không xảy ra thì xử lý sẽ không xảy ra. Hệ thống sẽ đưa ra kết quả là “After A until B” với lựa chọn đầu tiên, và “Between A and B” với lựa chọn thứ 2. Hình 1.4. cho thấy 4 loại mô tả xử lý chính mà PROPEL xác định được dựa trên các câu trả lời của người dùng. Hình 1.4: Bốn mô tả xử lý của PROPEL [4] Hình 1.5 mô tả rõ ràng hơn về cách thức PROPEL giúp người dùng chuyển từ yêu cầu ngôn ngữ tự nhiên sang các đặc tả hình thức. Câu hỏi đầu tiên là “Có bao nhiêu sự kiện chính liên quan trong mô tả xử lý này?”, với hai lựa chọn là “Một sự kiện” và “Hai sự kiện” (từ đây về sau, để dễ dàng trong quá trình trình bày, từ “sự kiện” được dùng để thay cho “sự kiện” hoặc “trạng thái”, với bao hàm là trạng thái của một hệ thống cũng có thể được điền vào vị trí của từ “sự kiện”). Hình 1.5: Ví dụ về bảng hỏi của PROPEL [4] Nếu người dùng chọn “Một sự kiện” thì sẽ tiếp tục xuất hiện câu hỏi: “Lựa chọn nào sau đây mô tả tốt nhất yêu cầu về sự kiện A?” với 03 lựa chọn: A không bao giờ xuất hiện, A xuất hiện tối thiểu một lần, A xuất hiện chính xác 1 lần. Nếu người dùng chọn câu trả lời đầu tiên, thì loại mô tả xử lý ở đây là 16 “Absence”. Tương tự, với hai lựa chọn còn lại chúng ta có thể thấy kết quả trong hình. Tuy nhiên, trong thực tế người dùng chỉ thấy một câu hỏi tại một thời điểm và các lựa chọn trả lời tương ứng, không thấy được kết quả của câu trả lời đó (phần in nghiêng trong hình như Absence, Existence – no max bound). Tương ứng với các mô tả xử lý này, PROPEL sẽ dịch sang ngôn ngữ tự nhiên và vẽ máy trạng thái hữu hạn mở rộng như trong hình 1.6. Hình 1.6: Giao diện FSA của PROPEL [4] Mặc dù còn một số nhược điểm như chỉ hỗ trợ xác định mối quan hệ của tối đa 02 sự kiện/trạng thái trong mô tả phạm vi và tối đa 02 sự kiện/trạng thái trong mô tả xử lý, cũng như không áp dụng để mô tả các yêu cầu thời gian thực, phương pháp này vẫn là một lựa chọn tốt để dựa vào đó xây dựng phương pháp chuyển từ NL sang SPSC. 17