00060000797 nghiên cứu các kỹ thuật và công cụ hỗ trợ cho Đặc tả yêu cầu và sinh tự Động các chế tác trong phát triển phần mềm

00060000797 nghiên cứu các kỹ thuật và công cụ hỗ trợ cho Đặc tả yêu cầu và sinh tự Động các chế tác trong phát triển phần mềm

BÁO CÁO TỔNG KẾT

KẾT QUẢ THỰC HIỆN ĐỀ TÀI KH&CN

CẤP ĐẠI HỌC QUỐC GIA

Tên đề tài: Nghiên cứu các kỹ thuật và công cụ hỗ trợ cho đặc tả yêu cầu

và sinh tự động các chế tác trong phát triển phần mềm

Mã số đề tài: QG.20.54

Chủ nhiệm đề tài: TS Đặng Đức Hạnh

Hà Nội, tháng 04 năm 2023

1

1.3 Danh sách chủ trì, thành viên tham gia thực hiện đề tài

TT Chức danh, học vị, họ và tên Đơn vị công tác Vai trò thực hiện đề tài

4 PGS TS Trương Anh Hoàng Trường ĐHCN Thành viên chính

5 NCS Nguyễn Thị Hạnh Trường ĐHCN Thành viên chính

7 HVCH Phạm Văn Trường Trường ĐHCN Kỹ thuật viên

8 HVCH Phùng Thị Hương Trường ĐHCN Kỹ thuật viên

1.4 Đơn vị chủ trì: Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội

1.5 Thời gian thực hiện:

1.5.1 Theo hợp đồng: từ tháng 04 năm 2020 đến tháng 04 năm 2022

1.5.2 Gia hạn (nếu có): đến tháng 04 năm 2023

1.5.3 Thực hiện thực tế: từ tháng 04 năm 2020 đến tháng 04 năm 2023

1.6 Những thay đổi so với thuyết minh ban đầu (nếu có):

Trong quá trình thực hiện, đề tài có thay đổi về thành viên tham gia như sau: (1) Bổ sung ThS Nguyễn Thu Trang thay cho TS Vũ Diệu Hương (từ 03/2021, chuyển công tác); (2) Bổ sung

HVCH Lâm Văn Tùng tiếp tục công việc của HVCH Phùng Thị Hương (từ 03/2021)

1.7 Tổng kinh phí được phê duyệt của đề tài: 330 triệu đồng

sống Nghiên cứu và vận dụng để tạo ra các phần mềm chất lượng với vòng đời phát triển ngắn, cùng chi phí hợp lý là rất cần thiết và mang tính cấp bách Trong phát triển phần mềm, đặc tả yêu cầu là khâu quan trọng, nhằm mô tả một cách chính xác và đầy đủ những gì hệ thống phần mềm cần thực hiện, cũng như các ràng buộc khác về sản phẩm và quy trình [BTYN18] Đến nay, các yêu cầu thường được đặc

tả dựa trên ngôn ngữ tự nhiên và các ngôn ngữ hình thức [CA07] Tuy nhiên, các dạng đặc này thường vẫn chưa đáp ứng được các tiêu chí cơ bản của tài liệu yêu cầu như tính chính xác, nhất quán, hiểu được và đầy đủ Việc phát hiện muộn các lỗi ở khâu đặc tả yêu cầu [Kam09], nghĩa là chỉ được phát hiện ở các giai đoạn sau, thường ở pha cài đặt, sẽ làm gia tăng nhiều lần chi phí sửa lỗi Mặt khác, đặc tả yêu cầu không chính xác sẽ gây khó hiểu cho các bên liên quan, trở cản cho hoạt động quản lý các yêu cầu và làm giảm khả năng sinh tự động các chế tác1 dẫn đến phần mềm kém chất lượng, không đáp ứng được các nhu cầu và bài toán đặt ra Thực trạng này đã đặt ra những thách thức và cũng là chủ đề nghiên cứu của đề tài - nghiên cứu các kỹ thuật đặc tả yêu cầu và sinh tự động các chế tác phần mềm Các nghiên cứu về đặc tả yêu cầu phần mềm thường chủ yếu tập trung vào các yêu cầu chức năng Một số nghiên cứu tập trung vào kỹ thuật đặc tả yêu cầu phi chức năng [MZN10] Các yêu cầu phi chức năng chủ yếu được xem xét ở nhóm các tính chất hệ thống, được biểu diễn dựa vào các logic, như logic vị từ cấp một hoặc các logic thời khoảng (temporal logic) Các nghiên cứu theo hướng này tập trung

đề xuất các kỹ thuật để kiểm tra và đảm bảo hành vi của hệ thống thỏa mãn các tính chất đặt ra Hướng nghiên cứu này thường được tiến hành theo hai tiếp cận: kiểm chứng mô hình (model checking) và chứng minh lý thuyết (theorem proving).

Tiếp cận hướng phương pháp hình thức Các yêu cầu thường được đặc tả ở dạng

ngôn ngữ tự nhiên, có cấu trúc hoặc phi cấu trúc, hoặc các ngôn ngữ/mô hình bán hình thức (semi formal models) như ngôn ngữ UML, với các biểu đồ như biểu đồ ca

sử dụng (use cases), biểu đổ ER (entity-relationship), biểu đồ tương tác hay biểu đồ trạng thái (statecharts) Một số ngôn ngữ mô hình hóa được đề xuất như SysML - Systems Modeling Language [SV08] để đặc tả các hệ thống phức tạp, ở các cấp độ trừu tượng khác nhau, đồng thời, cung cấp khả năng lần vết (traceability) giữa các chế tác, chẳng hạn, giữa đặc tả yêu cầu và ca kiểm thử Ngôn ngữ KAOS - Knowledge

1tương ứng với thuật ngữ artifacts, để chỉ các sản phẩm được tạo ra trong phát triển phần mềm

2

theo hướng tiếp cận siêu mô hình hóa (metamodeling) như UML/OCL [BTW15]

và nhóm các ngôn ngữ dựa vào các dạng logics khác Đặc tả yêu cầu sử dụng các ngôn ngữ hình thức cho phép người thiết kế hiểu một cách chính xác, không nhập nhằng về thế giới vấn đề, từ đó tìm ra được giải pháp phù hợp nhất Tuy nhiên, các dạng đặc tả hình thức thường gây khó hiểu cho người dùng, khách hàng, với các bên liên quan, bao gồm cả người phát triển Vì tính phức tạp và khó hiểu của ngôn ngữ hình thức, các đặc tả yêu cầu hình thức có thể được diễn đạt sai, không đúng với nhu cầu thực sự của người dùng Đến nay, việc đảm bảo đặc tả hình thức phản ánh đúng nhu cầu người dùng vẫn còn nhiều thách thức.

Tiếp cận hướng chuyên biệt miền Hướng nghiên cứu này đề xuất sử dụng các

khái niệm thuộc miền vấn đề (abstractions) để diễn đạt các đặc tả yêu cầu Theo cách đó, các đặc tả yêu cầu trở nên dễ hiểu hơn cho các chuyên gia miền và các bên liên quan Hơn nữa, các nghiên cứu [BGM10, DTJ14] tìm cách tích hợp các tri thức miền vấn đề vào công cụ đặc tả, hướng đến khả năng chuyển các đặc tả

về các chế tác phần mềm khác bao gồm các mã nguồn Một số nghiên cứu gần đây [MDND18, SVL+15] đề xuất các ngôn ngữ đặc tả yêu cầu chức năng dựa trên

ca sử dụng, hướng đến các mục tiêu sinh tự động các ca kiểm thử phần mềm.

Sinh tự động các chế tác phần mềm từ đặc tả yêu cầu Hoạt động sinh các

chế tác phần mềm từ các đặc tả yêu cầu đến nay thường chỉ được tiến hành một cách thủ công Giải quyết bài toán tự động hóa cho hoạt động này thường gặp nhiều khó khăn, do bản chất vấn đề ở đây là khoảng cách ngữ nghĩa (semantics gap) giữa không gian miền vấn đề và không gian kỹ thuật Một số nghiên cứu gần đây [GDS+18,CKL12] đề cập đến vấn đề này và đề xuất hướng giải quyết cho một

số tình huống cụ thể Hướng tiếp cận tiềm năng để giải quyết bài toán này là dựa vào các kỹ thuật chuyển đổi mô hình (model transformations) [FR07] Nghiên cứu trong [SN15] đề xuất phương pháp kết hợp chuyển đổi mô hình và kỹ thuật xử lý ngôn ngữ tự nhiên để sinh tự động mã nguồn Java từ đặc tả ca sử dụng Một số nghiên cứu gần đây [HHBH19,RMPC+18,OAJ+17] giới thiệu các kỹ thuật để sinh

tự động ca kiểm thử từ đặc tả yêu cầu Đến nay, bài toán sinh tự động các chế tác phần mềm từ đặc tả yêu cầu vẫn đang là chủ đề nghiên cứu nóng và thách thức Nghiên cứu về đặc tả yêu cầu và sinh tự động các chế tác phần mềm từ đặc tả vẫn đang là chủ đề nghiên cứu mở tại Việt Nam Liên quan trực tiếp chủ đề này là dòng nghiên cứu về các phương pháp hình thức Hợp tác chặt chẽ với nhóm chúng

3

nghiên cứu về trí tuệ nhân tạo, đặc biệt là các kỹ thuật biểu diễn tri thức và xử lý ngôn ngữ tự nhiên Việc xác định và biểu diễn các yêu cầu phần mềm cũng có nhiều điểm chung với dòng nghiên cứu về hệ thống thông tin, bao gồm các kỹ thuật mô hình hóa và phân tích quy trình nghiệp vụ.

Nhóm nghiên cứu kỹ nghệ mô hình phần mềm (software model engineering) chúng tôi đã tập trung vào hướng nghiên cứu này trong nhiều năm và đã xuất bản nhiều công trình nghiên cứu Đầu tiên, chúng tôi đã giới thiệu kỹ thuật mô

tả ngữ nghĩa tích hợp giữa các mô hình tương ứng với hai cấp độ ca sử dụng và thiết kế [DTG10] Chúng tôi cũng đã đề xuất phương pháp sử dụng văn phạm đồ thị ba (triple graph grammar) để liên kết các mô hình với nhau, qua đó diễn giải mối quan hệ ngữ nghĩa giữa các mô hình [DMA] Trong [DM16], chúng tôi đã giới thiệu một cách tiếp cận để đảm bảo chất lượng của các chuyển đổi mô hình Gần đây, chúng tôi đã đề xuất một phương pháp thiết kế hướng miền cùng với một DSL dựa trên chú thích DCSL [LDN18] cho phép biểu diễn các mô hình miền hướng đối tượng Cũng theo dòng nghiên cứu này, một số kết quả nghiên cứu gần đây của nhóm chúng tôi tập trung vào kỹ thuật sinh tự động các ca kiểm thử từ đặc tả ca

sử dụng [HHBH19,MDND18].

2.2 Mục tiêu và ý nghĩa

Qua khảo sát hiện trạng nghiên cứu về đặc tả yêu cầu và sinh tự động các chế tác phần mềm từ đặc tả yêu cầu, đề tài hướng đến các mục tiêu sau:

• Phát triển phương pháp và ngôn ngữ đặc tả theo tiếp cận chuyên biệt miền

để đặc tả yêu cầu chức năng một cách chính xác, hướng các bên liên quan.

• Đề xuất phương pháp sinh tự động các chế tác phần mềm từ đặc tả yêu cầu bằng kỹ thuật chuyển đổi mô hình: Mô hình đầu vào tương ứng với đặc tả yêu cầu và mô hình đích tương ứng với các chế tác phần mềm cần được sinh.

• Hỗ trợ và hiện thực hóa phương pháp đề xuất bằng một bộ công cụ phần mềm được đóng gói và triển khai ở dạng nguồn mở.

Đề tài không chỉ tập trung giải quyết một vấn đề thách thức của công nghệ phần mềm, góp phần gia tăng tự động hóa trong phát triển phần mềm, tăng năng

4

góp phần nâng cao chất lượng đào tạo và nghiên cứu khoa học Nhiều học phần và

chuyên đề liên quan trực tiếp đến nội dung của đề tài như: Phân tích thiết kế, Kỹ

nghệ yêu cầu, Tự động hóa trong phát triển phần mềm và Công nghệ phần mềm.

Thứ hai, đối với sự phát triển tiềm lực KH&CN của Trường và ĐHQGHN, hiện tại lực lượng nghiên cứu về công nghệ phần mềm tại ĐHQGHN nói chung, Trường ĐHCN nói riêng, nhìn chung còn khá mỏng cả về nhân lực và nội dung nghiên cứu Các đóng góp nghiên cứu về công nghệ phần mềm còn ở mức khiêm tốn, chưa đúng với vị thế và tiềm năng của ĐHQGHN Đề tài góp phần khắc phục thiếu hụt này, tiến tới hình thành nhóm nghiên cứu mạnh về mô hình hóa và tự động hóa phần mềm Hơn nữa, kết quả nghiên cứu của đề tài góp phần xây dựng nền tảng lý thuyết cho các đề xuất về phương pháp và công cụ hỗ trợ, hiện thực hóa định hướng đại học số hóa 4.0 ở ĐHQGHN, đồng thời góp phần giải quyết bài toán lớn về tích hợp

và hiện đại hóa phần mềm.

2.3 Phương pháp và nội dung nghiên cứu

Để đạt được các mục tiêu nghiên cứu, đề tài sử dụng một số phương pháp tổng hợp sau Thứ nhất, đề tài sử dụng phương pháp nghiên cứu tài liệu cho các nội dung nghiên cứu tổng quan về các kỹ thuật đặc tả hình thức, tiếp cận mô hình hóa chuyên biệt miền, vấn đề đặc tả yêu cầu và các tình huống sinh chế tác từ đặc tả yêu cầu, ngôn ngữ biểu diễn các chế tác phần mềm Thứ hai, trong phần nội dung nghiên cứu về phương pháp và ngôn ngữ đặc tả yêu cầu, đề tài vận dụng phương pháp thuộc quy trình kỹ nghệ ngôn ngữ: từ khảo sát miền, xây dựng mô hình khái niệm, đến định nghĩa cú pháp, ngữ nghĩa, và tiếp đó, cài đặt và đánh giá ngôn ngữ Thứ ba, đề tài vận dụng phương pháp chuyển đổi mô hình cho phần sinh tự động các chế tác từ đặc tả yêu cầu Các bước cơ bản trong quy trình kỹ nghệ chuyển đổi

mô hình bao gồm: từ đặc tả yêu cầu, thu thập dữ liệu kiểm thử, đến thiết kế, cài đặt và thực thi chuyển đổi mô hình Cuối cùng, một số phương pháp và kỹ thuật khác cũng được sử dụng trong đề tài bao gồm phương pháp thu thập dữ liệu cho phần tổng hợp dữ liệu về đặc tả yêu cầu Phương pháp phát triển phần mềm cho phần cài đặt công cụ hỗ trợ Phương pháp đánh giá thực nghiệm được tiến hành trên phần mềm công cụ hỗ trợ và được dùng để đánh giá phương pháp, ngôn ngữ

đề xuất và đánh giá các chuyển đổi để sinh tự động các chế tác phần mềm.

5

tác phần mềm từ các dạng đặc tả yêu cầu Một trọng tâm nữa của đề tài là xây dựng các chuyển đổi mô hình để sinh tự động các chế tác phần mềm từ đặc tả yêu cầu Cuối cùng, đề tài tập trung phát triển công cụ phần mềm nguồn mở để hỗ trợ các phương pháp được đề xuất.

2.4 Tổng hợp các kết quả nghiên cứu

Đề tài đã đạt được các kết quả chính sau: (1) Phương pháp và ngôn ngữ hỗ trợ đặc tả yêu cầu [NTD22,CD20]; (2) Phương pháp sinh tự động các chế tác dựa vào chuyển đổi mô hình [TD23a, TD23b, TD23c, CD20, ND21]; (3) Xây dựng công cụ nguồn mở FRSL2 hỗ trợ đặc tả yêu cầu và sinh tự động chế tác phần mềm từ đặc

tả Sau đây là phần diễn giải các kết quả đạt được của đề tài.

2.4.1 Phương pháp và ngôn ngữ hỗ trợ đặc tả yêu cầu

Đề tài tập trung đặc tả chính xác ngữ nghĩa của các ca sử dụng - một kỹ thuật phổ biến được sử dụng để diễn đạt các yêu cầu chức năng của phần mềm Từ đó, chúng tôi đề xuất ngôn ngữ chuyên biệt miền FRSL để diễn đạt chính xác các yêu cầu chức năng ở dạng mô hình ca sử dụng.

2.4.1.1 Miền đặc tả ca sử dụng

Ca sử dụng (use case) lần đầu tiên được giới thiệu trong [Jac92] với mục đích mô hình hóa tương tác giữa hệ thống phần mềm và môi trường Ca sử dụng được sử dụng rộng rãi để nắm bắt các yêu cầu chức năng của hệ thống từ quan điểm của người dùng.

Hình 2.1 thể hiện một phần mô hình ca sử dụng của hệ thống Điểm bán hàng (POS) [Lar04] Mô hình ca sử dụng trong ví dụ này được biểu diễn bằng biểu đồ ca sử dụng UML, cùng với các mô tả ca sử dụng ở dạng văn bản Xét ca

sử dụng Quy trình bán hàng (ProcessSale), tác nhân Thu ngân (Cashier) tham gia ca sử dụng này để đạt được mục tiêu, ghi lại các mặt hàng đã mua và thu tiền

2https://github.com/vnu-dse/frsl.git

6

8 The use case Hand Credit Payment is included

9 System logs completed sale.

10 System presents the payment.

11 Customer leaves with receipt and goods.

Alternative Flows:

1a Customer or Manager indicate to resume a suspended sale.

1 Cashier performs resume operation, and enters the ID to retrieve the sale.

2 System displays the state of the resumed sale, with subtotal 2a Sale is not found.

1 System signals error to the Cashier.

2 Cashier starts a new sale.

8a Paying by cash Extension Points:

E1 Payment with gifts: The extension point occurs at step 8

of the basic flow.

UC2: Handle Credit Payment

Basic Flow:

1 Customer enters their credit account information.

2 System sends payment authorization request to an external Payment

Authorization Service System, and requests payment approval.

3 System receives payment approval and signals approval to Cashier.

4 System records the credit payment,

which includes the payment approval.

5 System presents credit payment signature input mechanism.

6 Cashier asks Customer for a credit payment signature

Customer enters signature.

UC3: Handle Gift Certificate Payment Basic Flow:

2 System records the payment with the gift.

Primary Actor: Cashier

Preconditions: Cashier is identified and authenticated.

Postconditions: Sale is saved Accounting is updated.

Commissions is recorded Receipt is generated.

Payment authorization approvals are recorded.

Basic Flow:

1 Customer arrives at POS checkout with goods

and/or services to purchase.

2 Cashier starts a new sale.

3 System prepares for a new sale.

4 Cashier enters item identifier.

5 System records sale line item

and presents item description, price, and running total.

4-5 Cashier repeats steps 4-5 until indicates done.

6 System presents total with taxes calculated.

7 Cashier tells Customer the total for the payment.

Hình 2.2: Mô tả ở dạng văn bản các ca sử dụng của hệ POS [Lar04].

Ca sử dụng thường được đặc tả bằng cách sử dụng mẫu mô tả [Coc00], bao gồm hai phần chính, như được minh họa trong Hình 2.2 Phần đầu tổng quan về ca sử dụng với các trường: “tên ca sử dụng”, “tác nhân”, và “tiền và hậu điều kiện” Tiền (hậu) điều kiện cần được đáp ứng trước (sau) khi thực hiện ca sử dụng Phần còn lại của đặc tả ca sử dụng tập trung vào các luồng kịch bản Một ca sử dụng chứa

luồng cơ bản và một số luồng thay thế Luồng cơ bản nắm bắt những gì thường xảy

ra đối với ca sử dụng Trong trường hợp luồng cơ bản không thành công do bất kỳ điều kiện nào, hệ thống sẽ thực hiện một luồng thay thế.

Một ca sử dụng có thể tham gia vào các mối quan hệ sau: tổng quát hóa, bao

gộp (include) và mở rộng (extend) Ví dụ, như minh họa trong Hình 2.1, ca sử

7

Điều kiện mở rộng thỏa mãn khi Customer thanh toán bằng phiếu quà tặng.

2.4.1.2 Cú pháp của ngôn ngữ đặc tả FRSL

Chúng tôi xác định siêu mô hình (metamodel) định nghĩa cú pháp trừu tượng cho FRSL như trong Hình 2.3 Siêu mô hình này tương ứng với miền ca sử dụng Mô hình FRSL cung cấp mô tả tổng quan về các ca sử dụng và nắm bắt thông tin chi tiết về các ca sử dụng như sau: (1) Mô hình miền ở dạng biểu đồ lớp UML/OCL; (2) Cấu trúc ca sử dụng được xác định bởi các mối quan hệ, bao gồm và mở rộng của ca sử dụng; (3) Các kịch bản ca sử dụng; (4) Các mẫu hình chụp (snapshot patterns) để thể hiện tiền và hậu điều kiện của các ca sử dụng hoặc các bước (step);

và (5) Điều kiện gác (guard) của các luồng thay thế hoặc các bước nối lại hoặc các phần mở rộng của ca sử dụng.

Hình 2.3: Siêu mô hình (metamodel) định nghĩa cú pháp trừu tượng của FRSL.

8

store : Store ;

sale : Sale ;

pos: Register ;

$payment : Payment ;

(sale , pos): CapturedOn ;

(sale , payment ): PaidBy ;

!( store , sale ): LogsCompleted ;

[ sale isComplete = false ]

Danh mục 2.2 hiển thị một bước hành động hệ thống trong ca sử dụng ProcessSale Đặc tả này chứa hai hành động hệ thống để hiển thị thông tin cho tác nhân Cashier thông qua các biến đối tượng saleInfor và cashierInfor Danh mục 2.3 cho thấy

ca sử dụng HandleGiftCertPayment mở rộng ca sử dụng ProcessSale tại Step8.

Danh mục 2.2: Ví dụ đặc tả FRSL cho các bước hành động hệ thống.

( cashier , pos ): WorksOn ;

(_pos , pos): _Tracks ;

( _cashier , cashier ): _Tracks ;

to

sale : Sale ;

(sale , pos): CapturedOn ;

(_sale , sale ): _Tracks ;

[ sale oclIsUndefined () = false ]

[ sale total = 0]

[ sale date = curDate ]

actions

Cashier <- saleInfor : Sequence ( OclAny ) = Sequence { sale id , sale total };

Cashier <- cashierInfor : Sequence ( OclAny ) = Sequence { cashier name };

end

Danh mục 2.3: Ví dụ đặc tả cho quan hệ mở rộng ca sử dụng trong FRSL

extensionPoint PaidByGiftCert at { step08 }

description = ’It occurs as the Customer would pay with gift certificate ’

when

$_giftCert : GiftCertificate ;

end

HandleGiftCertPayment extends ProcessSales at { PaidByGiftCert }

2.4.1.3 Ngữ nghĩa hình thức của ngôn ngữ đặc tả FRSL

Chúng tôi đã xây dựng ngữ nghĩa hình thức cho ngôn ngữ đặc tả FRSL với một số các định nghĩa chính như sau.

9

• bất kỳ trạng thái hệ thống hiện tại nào được thể hiện bằng hình chụp (snapshot) của PDM cũng có thể được biểu diễn bằng hình chụp tương ứng của SDM;

• bất kỳ đối tượng nào được phản ánh bởi một lớp clsP của PDM cũng được tái hiện bởi một lớp tương ứng clsS của SDM Một sự tương ứng như vậy có thể được duy trì bởi liên kết lần vết một-một _T rack(clsP, clsS) Chỉ tác tử của PDM,

tức là bằng hành động của tác tử, mới có thể trực tiếp kiểm soát hoặc giám sát các thực thể của clsP Phần mềm, thông qua các hành động của hệ thống, chỉ có thể truy cập gián tiếp vào các thực thể này thông qua các thực thể tương ứng clsSdưới dạng “hình ảnh" của chúng.

Một mô hình miền hợp nhất UDM của PDM và SDM là một mô hình đối tượng bao gồm tất cả các lớp, liên kết và liên kết lần vết (tracking).

Định nghĩa 2 (Ca sử dụng) Ca sử dụng của một hệ thống trong SDM và PDM

tương ứng là một bộ ⟨Σ, S, E, S, s0, →, F, δ⟩3 sao cho:

• Σ = Σe∪ Σs∪ {ε, ε′, ε′′} trong đó Σe là hành động của tác nhân, Σs là hành động của hệ thống và {ε, ε′, ε′′} xử lý các luồng ca sử dụng;

• S là tất cả các mẫu hình chụp (snapshot patterns) của mô hình miền hợp nhất;

• E = ⟨ep, Es⟩ trong đó ep là một đối tượng hoạt động (được gọi là tác tử) của PDM, biểu diễn tác nhân chính và Es biểu diễn tác nhân phụ;

• S là tập con hữu hạn không rỗng của S để biểu diễn các trạng thái;

• s0 là một trạng thái ban đầu, một phần tử của tập hợp trạng thái S;

• →⊂ S × S × Σ × S × S là một quan hệ chuyển tiếp, được ký hiệu α c p1,a,c p2

−−−−−→ β

cho ⟨α, cp1, a, cp2, β ⟩ ∈→, sao cho

– nếu a ∈ Σe (Σs) thì a là một hành động tác nhân (hệ thống) cp1 và cp2 tương ứng là các mẫu hình chụp của PDM và SDM cp1 và cp2 tương ứng là tiền và hậu điều kiện của a;

3chữ ‘E’ trong định nghĩa này có nghĩa là ‘Môi trường’ của phần mềm, tức là tác nhân

10

– nếu s c p2,ε,cp2

−−−−→ s ∧ s ∈ F thì cp2 được gọi là hậu điều kiện của ca sử dụng ;

• F là tập con của S chứa các trạng thái kết thúc.

• δ : Σ → Bool là một hàm sao cho ∃!n, ∀0 ≤ i < n, ∃!si+1 : si

a i

−→ si+1∧δ(ai)∧sn∈

F ∧ ∀a ∈ Σ \ {a0, , an} : ¬δ(a) Hàm này để kiểm tra xem một hành động có

thuộc luồng cơ bản của ca sử dụng hay không.

Mô hình ca sử dụng của một hệ thống bao gồm tất cả các ca sử dụng của hệ thống.

Định nghĩa 3 (Kịch bản - Scenario) Kịch bản sc của ca sử dụng uc = ⟨Σ, S, A, S, s0, →, δ, F ⟩

là một chuỗi chuyển tiếp (s0

• Chúng ta viết si − → ssc i+1(∀0 ≤ i < n) để biểu thị bước chuyển tiếp của sc.

• |sc| biểu thị tất cả các trạng thái của kịch bản sc, nghĩa là |sc| = {s0, s1, , sn}.

• |uc| biểu thị tất cả các kịch bản của ca sử dụng uc.

Định nghĩa 4 (Bao gộp ca sử dụng - Inclusion) Ca sử dụng A bao gộp ca sử dụng

B khi và chỉ khi ∃sc ∈ |A|, sb

với tiền trạng thái của Step1 của HandleCreditPayment, tương ứng với SBb

1 Kể từ

đó, mỗi bước chuyển đổi trạng thái của ProccessSale được xác định theo một bước

tương ứng của HandleCreditPayment: (SAb

Định nghĩa 5 (Mở rộng ca sử dụng - Extension) Giả sử A, B là hai ca sử dụng

của mô hình miền hợp nhất UD; p là mẫu hình chụp của UD Ca sử dụng A được

mở rộng bởi ca sử dụng B từ điểm mở rộng p, dẫn đến một ca sử dụng mới A′ của

UD sao cho ∀sA ∈ |A|, sb

trạng thái SAe

7của Step7 (biểu diễn bởi uc1 :: step7) Trạng thái này trùng với trạng thái Sb và tiền trạng thái SCb

1 của Step1 của HandleGiftCertificatePayment (biểu

diễn bởi uc3 :: step1 ) Sau khi kết thúc ca sử dụng mở rộng này ở hậu trạng thái

SCe

2, quá trình thực thi sẽ tiếp tục với ca sử dụng mở rộng ProcessSale tại Step9.

2.4.1.4 Ngữ nghĩa hình thức của ngôn ngữ đặc tả hướng đối tượng

Theo hướng nghiên cứu thiết lập khung ngữ nghĩa hình thức cho các ngôn ngữ đặc

tả hướng đối tượng như FRSL, trong [NTD22], chúng tôi đã tập trung xây dựng ngữ nghĩa hình thức cho ngôn ngữ Transactional Featherweight Java Từ đó, chúng tôi định nghĩa hệ thống kiểu tương ứng cho mục đích ước lược ngưỡng tài nguyên

sử dụng của các chương đa tiến trình lồng nhau.

2.4.2 Sinh tự động các chế tác dựa vào chuyển đổi mô hình

Trong các phương pháp phát triển phần mềm hiện tại, các ca sử dụng tương ứng với các yêu cầu chức năng cần được chuyển sang các mô hình hệ thống được phản

13

FRSL ModelAnalysis

Test ModelGUI Prototype

TesterCustomer

Hình 2.6: Sinh các chế tác phần mềm từ đặc tả yêu cầu chức năng bằng FRSL.

Phần này giới thiệu cách tiếp cận dựa trên mô hình của chúng tôi hướng đến mục tiêu này Như được minh họa trong Hình 2.6, chúng tôi đã đặc tả các yêu cầu chức năng của phần mềm dưới dạng mô hình FRSL Dựa trên ngữ nghĩa chính thức của FRSL, chúng tôi có thể tự động chuyển đổi đặc tả FRSL sang các chế tác phần mềm, bao gồm bản mẫu GUI, bộ ca kiểm thử và mô hình thiết kế UML Các chuyển đổi này được tiến hành theo một trong hai dạng: mô hình sang mô hình (M2M) hoặc từ mô hình sang văn bản (M2T).

2.4.2.1 Sinh các ca kiểm thử

Chúng tôi định nghĩa chuyển đổi mô hình từ đặc tả yêu cầu FRSL sang ca kiểm thử theo các bước chuyển đổi sau Thứ nhất, đặc tả FRSL được chuyển đổi (M2T) sang mô hình ứng dụng ở dạng biểu đồ lớp UML/OCL Nội dung bước chuyển đổi này như sau: (1) Mỗi ca sử dụng được chuyển thành một lớp ca sử dụng; (2) Mỗi bước trong ca sử dụng tương ứng với một thao tác của lớp ca sử dụng Tiền và hậu điều kiện của bước này được chuyển thành tiền và hậu điều kiện của thao tác này; (3) Các điều kiện gác để xác định điểm mở rộng ca sử dụng hoặc bước nối lại (rejoiningStep) sẽ được chuyển thành các thao tác truy vấn của lớp ca sử dụng Tiếp đó, mô hình ứng dụng UML/OCL sẽ được chuyển sang mô hình filmstrip Chúng tôi sử dụng mô hình filmstrip, như được giới thiệu trong [GHDD17], để

14

biểu diễn các kịch bản của ca sử dụng trong một cấu trúc duy nhất Một mô hình filmstrip như vậy là kết quả của việc chuyển đổi từ mô hình ứng dụng UML/OCL, trong đó một số lớp và liên kết được thêm vào và các tiền và hậu điều kiện được chuyển đổi thành các bất biến Một biểu đồ đối tượng hợp lệ trong mô hình filmstrip

sẽ biểu thị một chuỗi các lệnh gọi thao tác cùng với các biểu đồ đối tượng trung gian trong mô hình ứng dụng Lưu ý rằng các lệnh gọi thao tác trong mô hình ứng dụng được biểu diễn dưới dạng các đối tượng gọi thao tác trong mô hình filmstrip.

Do đó, mỗi biểu đồ đối tượng hợp lệ trong mô hình filmstrip này sẽ tương ứng với một kịch bản của ca sử dụng.

Bước cuối cùng, các ca kiểm thử được sinh dựa vào tìm kiếm mô hình đối tượng hợp lệ (model finding) từ mô hình filmstrip Công cụ tìm mô hình trên biểu đồ lớp UML/OCL chẳng hạn như USE/ModelValitor [KG12] và UMLtoCSP [CCR14] cho phép tìm kiếm một thể hiện của biểu đồ lớp thỏa mãn tất cả các bất biến OCL Hình 2.7 tổng quan về quá trình tạo các ca kiểm thử sử dụng USE/ModelValidator.

2.4.2.2 Sinh mô hình ở dạng biểu đồ UML

Chúng tôi định nghĩa các chuyển đổi để sinh biểu đồ ca sử dụng và biểu đồ trạng thái từ đặc tả FRSL Thuật toán và nội dung các luật chuyển được đặc tả như trong Hình 2.8.

2.4.2.3 Sinh giao diện bản mẫu

Chúng tôi định nghĩa ngôn ngữ UISL để biểu diễn các mô hình giao diện người dùng Theo đó, chuyển đổi để sinh giao diện bản mẫu từ đặc tả FRSL được tiến hành theo hai bước chính sau Đầu tiên, đặc tả FRSL sẽ được chuyển sang mô hình UISL bằng chuyển đổi M2M Tiếp đó, mô hình UISL thu được sẽ sinh mô hình dạng văn bản html để biểu diễn giao diện người dùng Chi tiết kỹ thuật này đã trình bày trong báo cáo chuyên đề.

15

báo Scopus [TD23b], 01 bài báo tạp chí VNU-JCSCE [TD23a] và 01 báo cáo hội nghị [ND21].

2.4.3 Công cụ hỗ trợ đặc tả yêu cầu và sinh tự động chế tác

Chúng tôi đã phát triển phần mềm công cụ hỗ trợ các phương pháp đề xuất với hai nhóm chức năng chính: (1) Chức năng đặc tả yêu cầu phần mềm bằng ngôn ngữ FRSL; (2) Chức năng sinh tự động một số chế tác phần mềm từ đặc tả yêu cầu FRSL Phần mềm được cài đặt và triển khai ở dạng mã nguồn mở, sử dụng ngôn ngữ lập trình Java Mã nguồn phần mềm và tài liệu đi kèm được lữu trữ qua dịch

vụ Github4 Hình 2.9 biểu diễn mô hình ca sử dụng của phần mềm FRSL Các ca

sử dụng của phần mềm FRSL được tổ chức theo từng gói tương ứng với các nhóm chức năng (1) sinh ca kiểm thử, (2) sinh bản mẫu giao diện, (3) sinh biểu đồ UML

và (4) sinh đồ thị FRSL.

Công cụ FRSL được phát triển dựa trên nền tảng Eclipse với kiến trúc plug-ins cho phép khả năng mở rộng Kiến trúc plug-ins bao gồm hai phần chính: hệ thống lõi (core) và các mô-đun chức năng (plugins) Thiết kế chính này cho phép bổ sung tính năng dưới dạng mô-đun vào hệ thống lõi, cung cấp khả năng mở rộng, tính linh hoạt và phân tách các tính năng ứng dụng và tùy chỉnh nghiệp vụ Hệ thống lõi dựa trên nền tảng Eclipse, và các mô-đun khác của FRSL sẽ được phát triển dưới dạng các plugins của Eclipse Hiện tại, mô-đun chính của FRSL tập trung đặc tả

cú pháp trừu tượng, mô đun này sẽ là đầu đầu vào cho các mô đun chức năng khác, nhằm tạo ra các sản phẩm khác nhau từ cú pháp trừu tượng Hình 2.10 mô tả kiến trúc tổng thể của FRSL, với hệ thống lõi dựa trên nền tảng Eclipse Các mô-đun chức năng được biểu diễn bởi hình chữ nhật nét đứt là các plugins.

Hình 2.11 mô tả cấu trúc mã nguồn FRSL dựa vào kiến trúc Eclipse Cửa sổ bên trái của hình biểu diễn các plugins chức năng, có thể phân thành các nhóm: (1) đặc tả FRSL, (2) đặc tả ràng buộc UML/OCL, (3) cài đặt các chuyển đổi M2M với ATL [JABK08] và (4) cài đặt các chuyển đổi M2T với Acceleo [BCW12] Cú pháp trừu tượng của FRSL được đặc tả dựa trên hệ thống siêu mô hình trên nền tảng Eclipse với dạng đặc tả ecore Trong khi đó, cú pháp cụ thể dạng văn bản của FRSL được xây dựng bằng công nghệ Xtext cũng trên nền tảng Eclipse.

4https://github.com/vnu-dse/frsl.git

17

Hình 2.10: Kiến trúc tổng thể FRSL.

18

Sau đây là phần đánh giá của chúng tôi về các kết quả đạt được của đề tài, bao gồm: (1) Phương pháp và ngôn ngữ hỗ trợ đặc tả yêu cầu [NTD22, CD20, Duc23]; (2) Phương pháp sinh tự động các chế tác dựa vào chuyển đổi mô hình [TD23a, TD23b,TD23c,CD20,ND21]; (3) Xây dựng công cụ nguồn mở FRSL.

Phương pháp và ngôn ngữ hỗ trợ đặc tả yêu cầu

Nghiên cứu phương pháp và ngôn ngữ hỗ trợ đặc tả yêu cầu có ý nghĩa thu hẹp khoảng cách ngữ nghĩa giữa thế giới vấn đề và không gian giải pháp, mở ra khả năng sinh tự động các chế tác phần mềm, góp phần gia tăng tự động hóa trong phát triển phần mềm Chúng tôi đã đề xuất ngôn ngữ FRSL để đặc tả các yêu cầu chức năng dựa vào ca sử dụng Cú pháp trừu tượng và cụ thể dạng văn bản, cũng như ngữ nghĩa hình thức của ngôn ngữ FRSL đã được xây dựng Một phần kết quả đã được công bố qua 01 bài báo ISI [NTD22] và 01 báo cáo hội thảo quốc tế [CD20]

và 01 bài báo đang được gửi đăng tạp chí VNU-JCSCE [Duc23] Phần kết quả khác gắn với các hoạt động nghiên cứu và đào tạo sinh viên, học viên và nghiên cứu sinh Chúng tôi dự kiến tiếp tục hoàn thiện tính năng cho FRSL, đặc biệt gia tăng năng lực diễn đạt cho ngôn ngữ.

19

tế Với một số kết quả đã có về sinh tự động ca kiểm thử, cùng các kết quả khác về phương pháp đặc tả yêu cầu FRSL, chúng tôi dự kiến công bố qua 01 bài báo ISI Các kết quả còn lại, nhìn chung mới dừng ở mức báo cáo khóa luận và luận văn, chủ yếu đang ở giai đoạn thử nghiệm Các chuyển đổi mô hình được đề xuất này cần phải được tiếp tục nghiên cứu mở rộng, cũng như gia tăng đánh giá thực nghiệm.

Xây dựng công cụ hỗ trợ đặc tả yêu cầu và sinh chế tác

Bộ phần mềm công cụ nguồn mở hỗ trợ đặc tả FRSL đã được xây dựng thành công theo các mục tiêu đề ra, hỗ trợ hai chức năng chính: (1) Biểu diễn đặc tả FRSL và (2) Sinh tự động một số chế tác, đặc biệt là các ca kiểm thử Đến nay, phần mềm vẫn đang ở mức bản mẫu, cần được tiếp tục hoàn thiện, bổ sung thêm các tính năng tương ứng với các kết quả nghiên cứu đề cập ở trên.

2.6 Tóm tắt kết quả bằng tiếng Việt và tiếng Anh

Tóm tắt Phần mềm ngày nay có xu hướng tích hợp sâu rộng trong hầu hết các

lĩnh vực của đời sống Để tạo ra phần mềm có chất lượng trong vòng đời phát triển ngắn, với chi phí hợp lý là rất cần thiết và cấp bách Trong phát triển phần mềm, đặc tả yêu cầu là một bước quan trọng, nhằm mô tả chính xác và đầy đủ những gì

hệ thống phần mềm phải làm, cũng như các ràng buộc khác đối với sản phẩm và quy trình Xu hướng này thúc đẩy nhu cầu đặc tả chính xác các yêu cầu chức năng, cũng như phát triển các chuyển đổi để tạo ra các tạo phẩm phần mềm từ đặc tả yêu cầu Nghiên cứu này đề xuất một ngôn ngữ chuyên biệt miền FRSL để đặc tả các yêu cầu chức năng Chúng tôi định nghĩa một siêu mô hình được mở rộng từ siêu

mô hình UML cho các ca sử dụng để định nghĩa cú pháp trừu tượng cho FRSL Một

cú pháp cụ thể dạng văn bản được phát triển cho ngôn ngữ này Chúng tôi cũng cung cấp một ngữ nghĩa hình thức cho ngôn ngữ này Tiếp đó, chúng tôi đề xuất các kỹ thuật dựa trên chuyển đổi mô hình để sinh tự động các chế tác phần mềm

từ đặc tả FRSL Các chế tác bao gồm các ca kiểm thử, bản mẫu GUI và một số biểu đồ UML Chúng tôi phát triển một phần mềm mã nguồn mở dựa trên Eclipse

để hỗ trợ phương pháp được đề xuất.

20

trend drives the need for precise specification of functional requirements, as well

as the development of transformations to generate software artifacts from the quirements specification This research proposes a domain-specific language named FRSL to specify functional requirements We define a metamodel as extension of UML Use case metamodel to define the abstract syntax of FRSL A textual concrete syntax is defined for FRSL We also provide a formal semantics for this language.

re-We then propose transformation-based techniques to automatically generate from the FRSL specification software artifacts, including test cases, GUI prototype, and UML diagrams We develop an Eclipse-based opensource software to support the proposed method.

21

• Mô tả cú pháp trừu tượng, cú pháp cụ thể

và ngữ nghĩa của ngôn ngữ đặc tả yêu cầu được đề xuất (FRSL)

• Minh họa phương pháp và ngôn ngữ được

Nội dung chính bao gồm:

• Mô tả nội dung phương pháp sinh tự động chế tác phần mềm, làm rõ tính mới của phương pháp được đề xuất

• Đặc tả các chuyển đổi mô hình để sinh tự động một số chế tác từ đặc tả yêu cầu FRSL

• Minh họa phương pháp được đề xuất bằng ứng dụng cụ thể

• Đánh giá định tính và định lượng phương

Các yêu cầu chính bao gồm:

• Chức năng đặc tả yêu cầu phần mềm bằng ngôn ngữ FRSL

• Chức năng sinh tự động một số chế tác phần mềm từ đặc tả yêu cầu FRSL

• Được đóng gói ở dạng phần mềm nguồn

mở, cùng các tài liệu đặc tả, thiết kế, kiểm

thử và hướng dẫn sử dụng

01 phần mềm

Framework for Model Transformations Int

J Softw Eng Knowl Eng., Vol 33, 2023

Thi-Hanh Nguyen and Duc-Hanh Dang On

Integrating Multiple Restriction Domains to

Automatically Generate Test Cases of Model

Transformations Informatica, Vol 47, No 1,

pp 21-42, 2023 ISSN 0350-5596 DOI

10.31449/inf.v47i1.4421 (ISI/Scopus)

1.3

Ngoc-Khai Nguyen, Anh-Hoang Truong, and

Duc-Hanh Dang Finding Memory Bound of

Cloned Objects in Software Transactional

Memory Programs Int J Softw Eng Knowl

Eng., Vol 32, No 6, pp 791-818, 2022

ISSN 0218-1940 DOI

10.1142/S0218194022500139 (ISI)

2 Sách chuyên khảo được xuất bản hoặc ký hợp đồng xuất bản

3 Đăng ký sở hữu trí tuệ

4 Bài báo quốc tế không thuộc hệ thống ISI/Scopus

5 Bài báo trên các tạp chí khoa học của ĐHQGHN, tạp chí khoa học chuyên ngành

quốc gia hoặc báo cáo khoa học đăng trong kỷ yếu hội nghị quốc tế

5.1

Thi-Hanh Nguyen and Duc-Hanh Dang A

Contract-Based Specification Method for

Model Transformations VNU Journal of

Science: Computer Science and

Communication Engineering, Vol 39, No 1,

pp 1-22, 2023 ISSN 0866-8612 DOI

10.25073/2588-1086/vnucsce.657

Chấp nhận in

6 Báo cáo khoa học kiến nghị, tư vấn chính sách theo đặt hàng của đơn vị sử dụng

7 Kết quả dự kiến được ứng dụng tại các cơ quan hoạch định chính sách hoặc cơ sở

ứng dụng KH&CN

24

1 Nguyễn Thị Hạnh 2,4 tháng / 38 triệu đồng

(04/2020 – 03/2022)

Khung hình thức hỗ trợ đảm bảo chất lượng chuyển đổi mô hình

Đã bảo vệ

3 Nguyễn Minh Hằng Không kinh phí hỗ trợ

(05/2020 - 01/2021)

Phương pháp sinh tự động bản mẫu giao diện người dùng

từ đặc tả yêu cầu chức năng

25

2 Sách chuyên khảo được xuất bản hoặc ký hợp đồng xuất bản 0 0

5

Số lượng bài báo trên các tạp chí khoa học của ĐHQGHN,

tạp chí khoa học chuyên ngành quốc gia hoặc báo cáo khoa

học đăng trong kỷ yếu hội nghị quốc tế

6 Báo cáo khoa học kiến nghị, tư vấn chính sách theo đặt

7 Kết quả dự kiến được ứng dụng tại các cơ quan hoạch định chính sách hoặc cơ sở ứng dụng KH&CN 0 0

26

và xây dựng nhóm nghiên cứu mạnh thuộc Trường ĐH Công nghệ, ĐHQGHN

Nhóm nghiên cứu về công nghệ mô hình hóa và tự động hóa cho phát triển, vận hành và tiến hóa phần mềm (SME Lab - Software Model Engineering) Khoa Công nghệ Thông tin, Trường ĐH Công nghệ

Đại học Quốc gia Hà Nội

Hà Nội, ngày tháng năm 2023

Đơn vị chủ trì đề tài

(Thủ trưởng đơn vị ký tên, đóng dấu)

Chủ nhiệm đề tài

TS Đặng Đức Hạnh

[ABK 02] Egidio Astesiano, Michel Bidoit, Hélène Kirchner, Bernd Krieg-Bruckner,

Peter D Mosses, Donald Sannella, and Andrzej Tarlecki CASL: the Common

Algebraic Specification Language Theoretical Computer Science, 286:153 –

196, 2002.

Engineering in Practice Synthesis Lectures on Software Engineering, 1(1):

1–182, September 2012 ISSN 2328-3319, 2328-3327.

engineering pages 65–68, November 2010.

A Proposal for a Machine-Checked Formal Semantics for OCL 2.5 Archive

of Formal Proofs, September 2015.

[BTYN18] Amel Bennaceur, Thein Tun, Yijun Yu, and Bashar Nuseibeh Requirements

Engineering In Handbook of Software Engineering, pages 51–92 Springer,

January 2018.

In Proc Int Conf Future of Software Engineering (FOSE), pages 285–303.

IEEE, June 2007 ISBN 978-0-7695-2829-8.

diagrams using constraint programming Journal of Systems and Software,

93:1–23, 2014.

Diagrams from Use Cases In Proc 12th Int Conf Knowledge and Systems

Engineering (KSE), pages 109–114 IEEE, November 2020 ISSN: 2164-2508.

be-tween requirements and design: An approach based on Problem Frames and

SysML Journal of Systems and Software, 85(3):717–745, March 2012 ISSN

0164-1212.

27

[DMA] Duc-Hanh Dang, Martin Gogolla, and Anh-Hoang Truong On Scenario

Syn-chronization In Proc 8th Int Symp Automated Technology for Verification

and Analysis (ATVA), volume LNCS 6252, pages 97–111 Springer.

Confor-mance between Models Based on Scenario Synchronization J UCS, 16(17):

2293–2312, January 2010.

domain-specific requirement elicitation In Proc 4th Int Conf Requirements

Pat-terns (RePa), pages 17–24 IEEE, August 2014.

Requirements VNU Journal of Science: Computer Science and

Communi-cation Engineering, 39(N):1–20, 2023 ISSN 2588-1086.

Software: A Research Roadmap In Proc Int Conf Future of Software

Engineering (FoSE), pages 37–54 IEEE, May 2007.

Sylvain Guerin Bridging the Gap Between Informal Requirements and mal Specifications Using Model Federation In Einar Broch Johnsen and Ina

For-Schaefer, editors, Proc 16th Int Conf Software Engineering and Formal

Methods (SEFM), volume LNCS 10886, pages 54–69 Springer, 2018 ISBN

978-3-319-92970-5.

[GHDD17] Martin Gogolla, Frank Hilken, Khanh-Hoang Doan, and Nisha Desai

Check-ing UML and OCL model behavior with filmstrippCheck-ing and classifyCheck-ing terms.

In Sebastian Gabmeyer and Einar Broch Johnsen, editors, Proc 11th Int.

Conf Tests and Proofs (TAP@STAF, volume LNCS 10375, pages 119–128.

Springer, 2017.

[HHBH19] Chu Thi Minh Hue, Dang Duc Hanh, Nguyen Ngoc Binh, and Truong Anh

Hoang USLTG: Test Case Automatic Generation by Transforming Use

Cases International Journal of Software Engineering and Knowledge

En-gineering, 29(09):1313–1345, September 2019 ISSN 0218-1940.

A model transformation tool Science of Computer Programming, 72(1-2):

31–39, June 2008 ISSN 01676423.

28

[KG12] Mirco Kuhlmann and Martin Gogolla From UML and OCL to relational

logic and back In Robert B France, J¨urgen Kazmeier, Ruth Breu, and Colin

Atkinson, editors, Proc 15th Int Conf Model Driven Engineering Languages

and Systems (MODELS), volume LNCS 7590, pages 415–431 Springer, 2012.

Object-Oriented Analysis and Design and Iterative Development Addison

Wes-ley Professional, 3rd ed edition, 2004 ISBN 978-0-13-148906-6 LCCN QA76.9.O35 L37 2005.

de-sign using annotation-based domain specific language Computer Languages,

Systems & Structures, 54:199–235, December 2018 ISSN 14778424.

[MDND18] Minh- Chu, Duc-Hanh Dang, Ngoc-Binh Nguyen, and Duc Minh Le USL:

A Domain-Specific Language for Precise Specification of Use Cases and Its

Transformations Informatica, 42(3), 2018 ISSN 1854-3871, 0350-5596.

the Notion of Non-functional Requirements In Proc Int Symp Applied

Computing (SAC), pages 311–317 ACM, Sierre Switzerland, March 2010.

ISBN 978-1-60558-639-7.

for Specification-Driven Testing of Model Transformations In Proc 8th Int.

Conf on Information and Computer Science (NICS), pages 224–229 IEEE,

December 2021.

Mem-ory Bound of Cloned Objects in Software Transactional MemMem-ory Programs.

International Journal of Software Engineering and Knowledge Engineering,

32(06):791–818, June 2022 ISSN 0218-1940 Publisher: World Scientific Publishing Co.

Ed-wards, and Scott Turner Automated test case generation from high-level

logic requirements using model transformation techniques In Proc 9th Int.

Conf Computer Science and Electronic Engineering (CEEC), pages 178–182.

IEEE, September 2017.

29

Req2Test - Graph Driven Test Case Generation for Domain Specific

Re-quirement International Journal of Computer Trends and Technology, 60

(2):123–132, June 2018 ISSN 22312803.

Snap: Model-Driven Requirements Engineering in Practice Springer

Inter-national Publishing, 2015 ISBN 978-3-319-12837-5 978-3-319-12838-2.

Require-ments Specification using SysML Journal of Software, 3(6):57–68, June

2008 ISSN 1796-217X.

[SVL+15] Dusan Savic, Siniˇsa Vlaji´c, Saˇsa Lazarevi´c, Ilija Antovi´c, Stanojevic Vojislav,

Miloˇs Mili´c, and Alberto Silva Use case specification using the SilabReq

Domain Specific Language Computing and Informatics, 34:877–910, April

2015.

Method for Model Transformations VNU Journal of Science: Computer

Science and Communication Engineering, 39(1):1–22, 2023 ISSN 2588-1086.

Domains to Automatically Generate Test Cases of Model Transformations.

Informatica, 47(1):21–42, 2023 ISSN 0350-5596.

Testing Framework for Model Transformations International Journal of

Software Engineering and Knowledge Engineering, 33(N):1–39, 2023 ISSN

0218-1940.

Goal Orientation: A Paradigm Shift for Requirements Engineering In hard Goos, Juris Hartmanis, Jan van Leeuwen, Martin Wirsing, Alexander

Ger-Knapp, and Simonetta Balsamo, editors, Proc 9th Int Conf Radical

Innova-tions of Software and Systems Engineering in the Future (RISSEF), volume

LNCS 2941, pages 325–340 Springer, 2004 ISBN 978-3-540-21179-2.

30

https://mjl.clarivate.com/search-results 1/2

Refine Your Search Results

Sort By:

Search Results

Found 1 results (Page 1)

Exact Match Found

1 –

1 of1

Items per page:

 Share These Results

INTERNATIONAL JOURNAL OF SOFTWARE ENGINEERING AND KNOWLEDGE ENGINEERING

5 TOH TUCK LINK, SINGAPORE, SINGAPORE, 596224

Web of Science Core

Additional Web

of ScienceIndexes:

Current Contents Engineering, Computing & Technology | Essential Science Indicators

* Requires free login

 Share This Journal View profile page

Use our Manuscript Matcher to find

the best relevant journals!

Find a Match

Web of Science Coverage

TC4MT: A Specification-Driven Testing Framework

for Model Transformations

Thi-Hanh Nguyen 1,2,3 and Duc-Hanh Dang1,2∗

1 Department of Software Engineering, VNU University of Engineering and Technology

2 Vietnam National University, Hanoi

3 Hanoi National University of Education

Received (Day Month Year) Revised (Day Month Year) Accepted (Day Month Year)

Model transformation is a core mechanism for Model-Driven Engineering (MDE) Writing complex programs such as model transformations is error-prone, and efficient testing techniques are required for their quality assurance There are several challenges when it comes to testing model transformations, including the automatic generation of suitable input test models and the construction of test oracles based on verification prop- erties Many approaches to generating input models ensure coverage of a certain level

of the source meta-model and some input/output model constraints Furthermore, most transformation testing techniques are tailored to specific implementation languages or quality properties, which makes it difficult to reuse testing techniques for different lan- guages due to their language-specific nature The diversity of languages and verification properties raises the need for a black-box testing framework of model transformations that is independent of transformation implementation languages as well as supports sys- tematic verification of the quality properties In this paper, we clarify the basic elements

of such a framework, and how to apply this framework for systematically testing model transformations The main tasks of the model transformation testing process, including test design, test execution, and evaluation, are defined and realized within this integrated framework.

Keywords: Model Transformation; Transformation Testing; Triple Graph Grammars.

1 Introduction

In Model-Driven Engineering (MDE), models are used to represent systems on ahigher level of abstraction A key aspect of MDE is to automate model managementoperations by model transformations (MT) High-level models often are refined us-ing automated transformations until the code of the final application is obtained.Besides, there is a recurring need to transform models between different languagesand at different levels of abstraction, e.g to migrate between language versions, to

∗ Corresponding author.

Email address: hanhdd@vnu.edu.vn

1

translate models into semantic domains for analysis, to generate platform-dependentmodels from platform-independent models, or to refine and abstract models Thesyntactic and semantic complexity of models has led to a significant increase inthe complexity of model transformation systems, putting the need for the transfor-mation engineering process Within such a process the specification and testing oftransformations are significant to ensure the quality of transformations.

Transformation testing is to execute an implementation of the transformationwith given input test models, resulting in actual output models, and then to val-idate whether the results match the expected outputs [16] Model transformationtesting, therefore, contains several specific problems compared to more general pro-gram testing First, the automatic synthesis of test models is difficult due to largeconstraints on transformations, including well-formedness rules, pre- and postcondi-tions, and invariants Second, black-box testing techniques of transformations oftenrequire an effective specification method to accurately represent the transformationrequirements as a test basis Third, the test oracle involves checking actual outputmodels against expected output models for a particular test objective Test oracleconstruction is a difficult confusing task with challenges such as determining the ex-pected properties on the output model and verifying these properties automatically

to achieve the test objective

To tackle the aforementioned challenges, we propose a specification-driven ing framework called TC4MT (Test Cases for Model Transformations) to ensurethe quality of model transformations Specifically, we define a contract-based spec-ification language (TC4MT) to represent the transformation requirements playingthe role as a test basis to generate black-box test cases The TC4MT language is de-signed based on the triple graph grammars [27], thus allowing analysis of potentialdependencies and conflicts between transformation rules to design test conditions.The rest of this paper is structured as follows Section 2 represents backgroundknowledge related to specification-based transformation testing and provides a mo-tivating example for our research work Section 3 describes our approach overviewfor constructing a specification-driven testing framework Section 4 introduces ourTC4MT specification language Then, we explain a method for test case generationbased on the TC4MT transformation specification language in Sect 5 We presenttool support in Sect 6 and use this tool to study the effectiveness of the generatedtest suite using different coverage criteria in Sect 7 Section 8 relates our work toother similar approaches This paper is closed with a conclusion and future works

test-2 Background and Motivation

This section provides background knowledge of this work and presents a modeltransformation example and its requirements Through this transformation exam-ple, we highlight challenges of the specification-driven transformation testing

2.1 Motivating Example

This section motivates our work with the CD2RDBM transformation between classdiagrams (CD) and relational database models (RDBM) This transformation exam-ple is introduced in [9] In this paper, we focus on its simplified version for commontransformation situations as regarded in [31] Metamodels specifying the input andoutput modeling spaces of this transformation are shown in Fig 1 The CD2RDBMtransformation includes a set of transformation requirements At the specificationlevel, these requirements are often specified in the form of transformation contractsindependent of implementation languages

Fig 1 The source and target metamodels of the CD2RDBM transformation.

A transformation contract allows a designer to specify what a transformationdoes, under which conditions it can be applied to a model, and what its exceptedresult is Such information is also helpful for choosing and applying the proper trans-formation in the context of off-the-shelf transformations In the context of modeltransformation engineering, contract levels can be described in Fig 2 First, Typecontracts are specified by the source and target metamodels since they describethe types of the manipulated data, implying that the source and target modelsmust conform to these types [10] Second, Behavior contracts put further restric-tions on the required input models, the produced output models as well as theircombinations Behavior contract often include preconditions, postconditions, andinvariants Preconditions put restrictions on the required input models such thatthe transformation is applicable Postconditions are used to express whether or not

an output model should contain certain configurations of elements Invariants press conditions that need to be satisfied by any pair of source-target models of

ex-a correct trex-ansformex-ation Third, protocol contrex-acts specify the globex-al behex-avior ofsource/target models in terms of synchronizations between method calls w.r.t statetransitions of the transformation system The aim of such a contract is to describethe dependencies between services provided by a component, such as sequence, par-

allelism, or shuffle They are considered as protocol contracts and often represented

by transformation rules About the structure aspect, a transformation rule expressesthe valid relationship between source and target models so it can be considered as

an extension of a positive invariant Finally, Contracts of service quality mean thespecific quality parameters for the manufacturing process and the product such asAccountability, Availability, Deadline, Priority, Criticality, and etc [44] In this pa-per, we focus on specifying functional requirements of model transformations usingtype contracts, behavior contracts and protocol contracts while the specification ofservice quality contracts is out of the scope of the paper

Fig 2 Contract levels of model transformations.

We focus on the simplified version of the CD2RDBM transformation that cludes the following pre- and postconditions (Pre and Post for the short)

in-• (Pre1) A Class does not inherit itself;

• (Pre2) The name of a Class is unique;

• (Pre3) Any two Attributes of a class must have distinct names

• (Pre4) The child Class does not redefine Attributes of its parent Class;

• (Pre5) Association’s name does not coincide with Class’s name;

• (Post1) A Table must have unique name;

• (Post2) Two Columns of a Table must have distinct names;

• (Post3) A Table cannot have more than one primary key Column

Beside, Invariants specify the correspondence relationships between source els and target models A negative invariant expresses invalid correspondence rela-tionship The CD2RDBM transformation contains the following negative invariants

mod-• (Inv1) If the source model has a Class instance without parent classes, the

target model must have a Table instance with the same name;

• (Inv2) If the source model has a Class instance which owns an Attributeinstance then the target model must have a Table instance whose namecoincides with the class name and the Table instance contains a Columninstance whose name coincides with the attribute name;

• (Inv3) If the source model has two distinct Class instances that inherit fromeach other, the target model cannot have two separate Table instances Thename of each table coincides with the name of the corresponding class

The transformation rules used to express positive invariants are similar to proaches in [18, 22, 20], but with the addition of dynamic semantics expressing thebehavior of the model elements that should be implemented to maintain a consis-tent relationship between source and target models The CD2RDBM transformationincludes the following transformation rules

ap-• (r1) The name of a Class coincides with the name of a corresponding Table;

• (r2) The name and data type of a non-primary Attributes coincides withthe ones of a corresponding Column;

• (r3) A primary Attribute is mapped to a primary key Column;

• (r4) A multi-valued aggregation between two Classes is mapped to a newassociative Table that relates the two corresponding Tables;

• (r5) An aggregation/association relationship between two Classes that ischaracterized by a single-valued end and a multi-valued end (0 *, 1 *) ismapped to a foreign key Column that relates two corresponding Tables;

• (r6) A child Class and its parent Class are mapped to the same Table

• (r7) After transformation rule application, inheritance hierarchy will beflattened by copying the Attributes if the parent Class down to all of itschild Classes and removing the parent Class from the model

In the requirements specification phase, the above requirements set can be pressed by many different means such as natural language, modeling language, andformal language, at many levels of abstraction ranging from abstract statements

ex-to detailed design At the implementation phase, the requirements are used as thebasis for developing an executable model transformation implementation A modeltransformation, e.g., the CD2RDBM transformation can be implemented by differ-ent transformation languages, as surveyed in [30], from imperative transformationlanguages (e.g., QVTo, MOFScript, Kermeta2, ) to declarative transformationlanguages (e.g., QVTr, Tefkat, JTL, ), graph-based transformation languages (e.g.,GReAT, eMoflon, TGGInterpreter, ), or hybrid languages (e.g., ATL, VIATRA,Fujaba, ) This puts forward a need for a verification method that is applicable forsuch a diversity of transformations, i.e., in a way independent from implementationlanguages

2.2 Model transformation verification

Model transformations are also software artifacts that need to be quality assured towork towards ensuring software quality Hartmut et al [31] have summarized manydifferent studies on the transformation verification to provide a quality model interms of the functional aspect Hartmut’s classification is similar to the followingquality property set proposed by Lukman et al [33]

• Syntactic correctness: For each source model used as input to the modeltransformation, the resulting output model must be a syntactically validinstance of the target modeling language

• Semantic correctness: The semantics of each source model must be served or reflected respectively in the target model obtained by the modeltransformation The semantics of a model includes static semantics ex-pressed by the information structure and dynamic semantics expressed bythe model behaviors in case the model has behavior semantics (dynamicmodels) Therefore, semantic correctness can be considered in two respects:information preservation and behavior preservation

pre-• Completeness: A model transformation can execute on any valid sourcemodel to produce the corresponding target model In addition, strong com-pleteness (Strong completeness) may require that any valid target model

be achievable by a valid transformation execution scenario

• Functional behavior: For each valid source model, the model transformation

on it must terminate (termination) and lead to the same resulting targetmodel, or in other words transformation (confluence) on the transformationresult

Testing cannot prove quality properties but can show the presence or absence

of errors within a model transformation under specific test cases Testing can beeffectively used for learning quality and early detection of defects at a low cost and

an acceptable effort level of testers In the transformation testing process, testersneed to first -for test models that conform to the source metamodel Since manualcreation of test models is often time-consuming, labor intensive, and error-prone,automated test model generation is a useful solution [16] Next, executing the modeltransformation on the test models under the test conditions will generate the out-put target models Testers need to construct test oracles that define the expectedoutput and the test oracle function that compares the actual output with the ex-pected output to decide the test result Testers can design test conditions and testoracles based on the transformation specification according to the black-box testingapproach or based on the transformation implementation program according to thewhite-box testing approach

White-box testing techniques analyze the components of the model tion implementation to specify test conditions [25, 24, 27] They have many advan-tages in designing test models that cover the execution paths of the implementation

transforma-program and generate test data that examines the transforma-program’s side effects, especially

as good support for debugging In MDE, most transformation implementation guages are developed as domain-specific languages for different application domains,

lan-so they are diverse in genre, numerous in number, continuously evolving, and lackinggeneral-purpose languages [30, 32] Therefore, the proposed white-box testing tech-niques are often difficult to apply to many different transformation implementationlanguages

The black-box testing techniques allow for designing test cases early withoutknowledge of the transformation implementation structure Black-box test cases of-ten are highly reusable and easier to use for testers An effective black-box testingapproach requires an effective specification method that can represent transforma-tion requirements fully and accurately An incomplete specification can produce

a test model set that does not cover all important aspects of the business main, and many input cases causing errors are untested Design by contracts isseen as the foundation for developing trusted systems such as model transforma-tions [10, 2, 21, 20, 4] The challenge for quality assurance of model transformationssuch as CD2RDBM transformation is to have an effective specification method thatfacilitates the verification of specification compliance of a transformation imple-mentation In this paper, we address black-box transformation testing for qualityassurance There are a number of black-box methods that have been proposed, butthere are still some shortcomings that have not been fully resolved

do-(1) A method of efficiently specifying the requirements set is needed to provide

a test basis for black-box testing techniques Current specification languagesmostly focus on requirements specification based on behavior contracts Thelanguage should allow the representation of type contracts, behavior contracts,and protocol contracts It should also allow visual representation of complexrequirements and be defined based on a formal semantic that could offer meansfor verifying transformations

(2) In specification-based testing, partition analysis helps to generate test models

to achieve high coverage of test basis and avoid duplication of test cases ever, partition analysis-based transformation testing also has certain difficultiesand challenges The partitioning conditions need to be uniformly expressed tosupport the partition combining, and the representation of partition conditionsalso needs to support the constraint solving of automated test model genera-tion Determining test model generation conditions that need to be linked withthe expected output evaluation conditions to verify specific quality attributes.(3) Testing allows us to verify quality attributes of transformations, including syn-tactic correctness, information preservation, and completeness In current workssuch qualities are often verified using formal methods with high complexity andcost [3, 34, 33] or white-box testing methods by analyzing the transformationimplementation [25, 24, 27] This poses the challenge of systematically testingmodel transformation quality attributes using black-box testing techniques