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

0

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

1

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


2

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ

TT
Từ viết
tắt/Thuật ngữ
Giải thích/Định nghĩa
Ghi chú
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

4

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
Ngôn ngữ tự nhiên
Natural language
13
PROPEL
Công cụ hướng dẫn người dùng
xác định yêu cầu
PROPerty ELuciator
14
SPSCQT
Bảng hỏi dành cho SPSC
SPSC Question Tree

3

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

4

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


5

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.

6

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

7

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
Tên nhóm
Tên mẫu yêu cầu
1
Yêu cầu cơ bản
(Fundamental)
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)
2
Thông tin
(Information)
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)

8

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
(Data entity)
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)
5
Hiệu năng
(Performance)
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)
6
Độ khả chuyển
(Flexibility)
Unparochialness
Tính đa dạng (Multiness)
Khả năng mở rộng (Scalability)
Khả năng nâng cấp (Extendability)

9

Tính cài đặt được (Installability)
Đa ngôn ngữ (Multi-lingual)
7
Thương mại
(Commercial)
Thuế/phí (Fee/tax)
Đơn vị đa tổ chức (Multiorganization unit)
8
Điều khiển truy cập
(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)

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
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
- 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

10

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

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ộ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).

12

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]

13

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).

14

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

15

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

16

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à

17

“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.

18


2 Chương II: Phương pháp chuyển ngôn
ngữ
2.1 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 mô tả dưới dạng ngôn ngữ tự nhiên theo một cấu trúc nhất định, bổ
sung thêm một số hình ảnh thể hiện các ca sử dụng (use case). Mỗi ca sử dụng
được mô tả theo cấu trúc:
- 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 mô tả bằng lời.
Toàn văn tài liệu mô tả yêu cầu cho hệ thống đăng ký lớp học được dùng để làm
bộ mẫu trong luận văn này có trong Phụ lục 2.
2.1.2 Phương pháp chuyển đổi
Do các mô tả của SPSC đều được xây dựng dựa trên sự kiện/trạng thái và các
mô tả mối quan hệ giữa các sự kiện/trạng thái, nên việc chuyển đổi có ba bước
(sẽ được mô tả chi tiết trong các phần 2.2, 2.3, 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

19

2.2 Tinh chỉnh yêu cầu
Nếu yêu cầu tả hành động của người dùng thay vì hệ thống, ta cần chuyển
sang mô tả xử lý của hệ thống, và từ đó xác định lại sự kiện phù hợp.
Ví dụ yêu cầu ban đầu được thể hiện như sau: “sau khi người dùng nhập tên
tài khoản và mật khẩu, hệ thống thực hiện kiểm tra tài khoản và mật khẩu”.
Thực tế hệ thống không cần biết người dùng đã nhập gì vào tài khoản và mật
khẩu, mà chỉ quan tâm người dùng có yêu cầu xác thực hay không (có thể là
bằng cách nhấn vào nút “đăng nhập” như giao diện web phổ biến hiện nay).
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”.
2.3 Xác định sự kiện
Theo Rachel L.Cobleigh [4], phương pháp PROPEL hiện chỉ hỗ trợ việc xác
định mối quan hệ giữa các sự kiện/trạng thái, việc xác định các sự kiện/trạng
thái từ mô tả bằng ngôn ngữ tự nhiên vẫn chưa được đề cập đến. Thực tế người
dùng có thể lúng túng khi chọn lựa, xác định các sự kiện/trạng thái.
Do đó, chúng tôi đã đưa ra các nguyên tắc dựa trên kinh nghiệm trong quá
trình chuyển đổi các yêu cầu, giúp thống nhất quá trình thực hiện và giảm sai
sót. Và cần phải chú ý rằng sự kiện/trạng thái này có thể được dùng để miêu tả
yêu cầu xử lý ở mô tả này cũng có thể là phạm vi trong mô tả khác.
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:
- Trường hợp 1: các ca sử dụng (use case). Các ca sử dụng nên có sự kiện
bắt đầu và kết thúc. Các sự kiện xảy ra trong ca sử dụng đều phải thực hiện
sau sự kiện bắt đầu ca sử dụng, và trước sự kiện kết thúc ca sử dụng.
Ví dụ: đối với ca sử dụng mô tả yêu cầu về việc cập nhật điểm sẽ có sự
kiện start_update_grade và end_update_grade. Các sự kiện con trong ca sử

dụng sẽ được mô tả trong phạm vi giữa (scope: between)
start_update_grade và end_update_grade.
- Trường hợp 2: các yêu cầu có tính chất lặp. Tất cả các yêu cầu có tính chất
lặp đều bắt buộc có sự kiện bắt đầu và kết thúc, các hành động được lặp lại
được thực hiện sau sự kiện bắt đầu và trước sự kiện kết thúc.
Ví dụ: yêu cầu mô tả là “thực hiện kiểm tra khóa học đối với tất cả các
sinh viên, mỗi sinh viên kiểm tra số khóa học có lớn hơn 03 không” thì cần

20

có sự kiện start_check_student và end_check_student. Việc kiểm tra số
khóa học có lớn hơn 03 hay không sẽ được mô tả trong phạm vi giữa
(scope: between) start_check_student và end_check_student.
2.3.2 Sự kiện đơn
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.
2.4 Xây dựng bảng hỏi
2.4.1 Bảng hỏi PROPEL
Bảng hỏi đầy đủ của PROPEL dành cho mô tả xử lý và mô tả phạm vi được
thể hiện trong hình 2.1 và 2.2. Trong bảng hỏi này, có một số câu hỏi mà lựa
chọn trả lời sẽ dẫn đến các câu hỏi kế tiếp (ví dụ trong hình 2.1, câu hỏi dòng 26
chỉ được hỏi khi trong câu hỏi trước người dùng lựa chọn câu trả lời dòng 25).

Ngoài ra, một số câu hỏi sẽ được hỏi kế tiếp bất kể lựa chọn của câu hỏi trước là
gì (ví dụ trong hình 2.1, câu hỏi dòng 13 luôn được hỏi tiếp bất chấp kết quả của
câu hỏi dòng 10 là gì).

21


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

22


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 chỉnh
sửa một số phần để có thể hướng dẫn người dùng áp 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 phải thực hiện những thay đổi sau đây từ bảng hỏi của PROPEL: