Nghiên cứu áp dụng phân hệ đa phương tiện ip trong mạng viễn thông việt nam

LỜI CAM ĐOAN Tôi xin cam đoan rằng những nghiên với đề tài “Phương pháp phân tích sự ảnh hưởng của các thành phần và ứng dụng cho kiểm thử hồi quy trong các dự án Java EE” được trình bà

ĐẠI HỌC QUỐC GIA HÀ NỘI

ĐẠI HỌC QUỐC GIA HÀ NỘI

MỤC LỤC

MỤC LỤC i

LỜI CAM ĐOAN iii

LỜI CẢM ƠN iv

DANH MỤC THUẬT NGỮ VIẾT TẮT v

DANH MỤC HÌNH VẼ vi

DANH MỤC BẢNG viii

Chương 1 Giới thiệu 9

Chương 2 Phương pháp phân tích sự ảnh hưởng trong JCIA 11

2.1 Bộ công cụ JCIA 11

2.2 Phân tích các phụ thuộc 17

2.2.1 Tiền xử lý mã nguồn 17

2.2.2 Phân tích sự phụ thuộc cho Struts 2 17

2.2.3 Phân tích sự phụ thuộc trong Java Core 19

2.2.4 Phân tích phụ thuộc cho công nghệ kết nối cơ sở dữ liệu JDBC 20

2.2.5 Phân tích phụ thuộc cho Hibernate 24

2.3 Quản lý phiên bản 27

Chương 3 Phương pháp phân tích ảnh hưởng các thành phần giao diện và phân loại kiểm thử hồi quy 28

3.1 Phương pháp phân tích ảnh hưởng các thành phần giao diện 28

3.1.1 Phân tích kiến trúc Java Servlet 28

3.1.2 Phương pháp phân tích sự ảnh hưởng 31

3.2 Phương pháp phân loại kiểm thử hồi quy 35

3.2.1 Kiểm thử hồi quy 35

3.2.2 Phân loại kiểm thử hồi quy 35

3.2.3 Quy trình kiểm thử hồi quy dựa trên phương pháp đề xuất 36

Chương 4 Thực nghiệm và triển khai 36

4.1 Giới thiệu công cụ JCIA mở rộng 38

4.2 Thực nghiệm 39

4.3 Ý nghĩa của công cụ thực nghiệm 39

Chương 5 Kết luận 53

TÀI LIỆU THAM KHẢO 56

LỜI CAM ĐOAN

Tôi xin cam đoan rằng những nghiên với đề tài “Phương pháp phân tích

sự ảnh hưởng của các thành phần và ứng dụng cho kiểm thử hồi quy trong các dự án Java EE” được trình bày trong luận văn này là công trình nghiên cứu

của riêng tôi dưới sự hướng dẫn của thầy giáo PGS TS Phạm Ngọc Hùng,

không sao chép lại của người khác Tất cả các nguồn tài liệu tham khảo, các công trình nghiên cứu liên quan đều được trích dẫn cụ thể

Tôi xin chịu hoàn toàn trách nhiệm nếu có bất kỳ phát hiện nào về sự sao chép mà không có trích dẫn trong tài liệu tham khảo

LỜI CẢM ƠN

Đầu tiên, tôi xin gửi lời cảm ơn chân thành tới thầy giáo PGS TS Phạm

Ngọc Hùng - người đã hướng dẫn tận tình, chỉ bảo và đóng góp ý kiến quý báu

cho tôi trong suốt quá trình học tập và làm khóa luận Trong quãng thời gian được thầy hướng dẫn, tôi đã học hỏi được nhiều kinh nghiệm về phương pháp nghiên cứu, kỹ năng trình bày Thầy còn tiếp thêm cho tôi niềm tin vượt qua khó khăn giúp tôi trưởng thành hơn trong cuộc sống

Tôi xin gửi lời cảm ơn chân thành đến các thầy cô giáo khoa Công nghệ thông tin trường Đại học Công nghệ - Đại học Quốc gia Hà Nội đã tận tình truyền đạt những kiến thức quý báu, tạo điều kiện tốt nhất cho tôi trong suốt thời gian học tập và nghiên cứu Tiếp theo, tôi xin gửi lời cảm ơn đến gia đình và người thân đã luôn bên cạnh động viên, cổ vũ và là chỗ dựa vững chắc để tôi yên tâm học hành trong suốt những năm qua Tôi cũng xin gửi lời cảm ơn chân thành đến Bùi Quang Cường và Ngô Hải Yến đã tạo điều kiện giúp đỡ tôi để nghiên cứu công cụ JCIA

Mặc dù đã rất cố gắng nhưng luận văn chắc chắn không tránh khỏi những thiếu sót, tôi rất mong nhận được những ý kiến đánh giá và phê bình từ phía các Thầy Cô để luận văn được hoàn thiện hơn

Tôi xin chân thành cảm ơn!

Hà Nội, tháng 10 năm 2018

Học viên

Nguyễn Thị Hồng Vân

DANH MỤC THUẬT NGỮ VIẾT TẮT

1 AST Abstract Syntax Tree Cây cấu trúc trừu tượng

2 CIA Change Impact Analysis Phân tích ảnh hưởng sự

7 JDBC Java Database Connectivity Giao diện tương tác với

cơ sở dữ liệu quan hệ trong Java

8 JDG Java Dependency Graph Đồ thị phụ thuộc Java EE

9 MVC Model - View - Controller Mô hình thiết kế ứng

dụng Web

10 ORM Object Relational Mapping Ánh xạ quan hệ đối

tượng

DANH MỤC HÌNH VẼ

Hình 2.1 Giao diện chính của công cụ JCIA 13

Hình 2.2 Màn hình Project View 13

Hình 2.3 Màn hình Dependency View 14

Hình 2.4 Change Impact View 15

Hình 2.5 Hiển thị mã nguồn 15

Hình 2.6 Change Set View 16

Hình 2.7 Impact Set View 16

Hình 2.8 Mô hình ứng dụng Struts2 17

Hình 2.9 Quy trình phân tích sự phụ thuộc cho ứng dụng Struts 2 18

Hình 2.10 Ví dụ minh họa đồ thị chuỗi 22

Hình 2.11 Quá trình xây dựng và dự đoán câu truy vấn 23

Hình 2.12 Quá trình phân tích phụ thuộc cho Hibernate 24

Hình 2.13 So sánh cây cấu trúc giữa hai phiên bản mã nguồn 27

Hình 3.1 Kiến trúc Java Servlet 28

Hình 3.2 Vòng đời của Java Servlet 29

Hình 3.3 Mã nguồn sử dụng nền tảng Java Servlet 30

Hình 3.4 Phân loại kiểm thử hồi quy 35

Hình 3.5 Quy trình kiểm thử hồi quy đề xuất 36

Hình 4.1 Kiến trúc của công cụ JCIA 38

Hình 4.2 Kết quả đầu ra của công cụ 39

Hình 4.3 Ứng dụng Web quản lý bệnh viện 40

Hình 4.4 Lỗi xảy ra ở phiên bản 1 49

Hình 4.6 Yêu cầu thêm mới cho giao diện quản lý bệnh nhân 50

Hình 4.7 Nghiệp vụ liên quan đến Health Insurance 50

Hình 4.8 Kết quả tập thay đổi và ảnh hưởng cho kiểm thử đơn vị 51

Hình 4.9 Kết quả tập thay đổi và ảnh hưởng cho kiểm thử giao diện 51

Hình 4.10 Kết quả kiểm thử hồi quy giao diện với Ranorex 52

Hình 4.11 Kết quả tập thay đổi và ảnh hưởng cho kiểm thử tích hợp 52

DANH MỤC BẢNG

Bảng 2.1 Ý nghĩa các kiểu cạnh trong đồ thị chuỗi 24

Bảng 2.2 Các phương thức truy xuất CSDL có sẵn của Hibernate 26

Bảng 4.1 Mô tả yêu cầu chức năng quản lý nhân viên 41

Bảng 4.2 Mô tả yêu cầu chức năng quản lý phòng 42

Bảng 4.3 Mô tả yêu cầu chức năng quản lý dịch vụ 42

Bảng 4.4 Mô tả yêu cầu chức năng quản lý bệnh nhân 43

Bảng 4.5 Mô tả yêu cầu chức năng đặt phòng 43

Bảng 4.6 Mô tả yêu cầu chức năng quản lý thuốc 44

Bảng 4.7 Mô tả yêu cầu chức năng quản lý bán thuốc 44

Chương 1 Giới thiệu

Trong lĩnh vực phát triển phần mềm hiện nay, hầu hết các ứng dụng phần mềm đều được phát triển trên nền Web Chính vì vậy, việc kiểm thử để đảm bảo chất lượng các ứng dụng Web là một vấn đề rất cần thiết Tuy nhiên, các ứng dụng Web ngày càng trở nên phức tạp, đặc biệt là đối với các ứng dụng Web sử dụng nền tảng Java EE - một trong những giải pháp đang được sử dụng phổ biến

để triển khai cho các ứng dụng Web doanh nghiệp Các ứng dụng này thường được phát triển trong thời gian dài, với quy mô lớn và có độ phức tạp cao, ví dụ như các ứng dụng xử lý nghiệp vụ logic trong các lĩnh vực ngân hàng, thuế, kế toán, v.v Khi một phiên bản mới được bàn giao có thể là do nâng cấp, sửa đổi

mã nguồn, v.v., việc kiểm thử viên phải kiểm thử lại toàn bộ chức năng của phần mềm là rất cần thiết để đảm bảo các chức năng vẫn hoạt động tốt, bởi vì một sự thay đổi nhỏ trong ứng dụng cũng có thể gây ra một số ảnh hưởng không thể dự đoán trước hay thậm chí là cả những sai sót tiềm ẩn bên trong đối với ứng dụng đang phát triển Phương pháp đơn giản để kiểm thử hồi quy là chạy tất cả các ca kiểm thử của phiên bản trước [1] Tuy nhiên, việc kiểm thử lại toàn bộ này là rất tốn kém về thời gian và công sức Do đó, để hoàn thành công việc kiểm thử đúng tiến độ và hiệu quả, các công ty phần mềm cần phải áp dụng các phương pháp và công cụ nhằm tối ưu được các hoạt động kiểm thử Phương pháp phân tích sự ảnh hưởng của các thành phần kết hợp với công cụ kiểm thử tự động để thực hiện kiểm thử hồi quy là một giải pháp hữu hiệu nhằm nâng cao tính hiệu quả và chính xác, giảm thiểu chi phí và rút ngắn thời gian trong quá trình kiểm thử các sản phẩm phần mềm nói chung và các ứng dụng Web nói riêng Thay vì kiểm thử lại toàn bộ ứng dụng, kiểm thử viên chỉ cần kiểm thử các thành phần bị thay đổi và thành phần có khả năng bị ảnh hưởng dựa trên thay đổi đó

Phân tích ảnh hưởng sự thay đổi (Change Impact Analysis - CIA) [3,4,5] là giải pháp để giải quyết bài toán trên CIA đóng một vai trò quan trọng trong các giai đoạn phát triển phần mềm, bảo trì và kiểm thử hồi quy Đối với nhóm phát triển, CIA có thể được ứng dụng vào việc giúp nhận biết các thay đổi cần thực hiện dựa trên các thay đổi có sẵn Đối với kiểm thử viên, CIA có thể ứng dụng vào việc xác định những ca kiểm thử có liên quan đến phần mã nguồn chỉnh sửa giúp giảm số lượng các ca kiểm thử và rút ngắn thời gian kiểm thử hồi quy mà vẫn đảm bảo được chất lượng phần mềm

Trong thực tế, có một số công cụ hỗ trợ quản lý phiên bản mã nguồn như Git, SVN, VSS, v.v., các công cụ này giúp lập trình viên quản lý được các dòng lệnh thay đổi qua các phiên bản khác nhau Tuy nhiên, để có thể đánh giá được

các ảnh hưởng từ sự thay đổi là chưa có giải pháp thỏa đáng Một số nghiên cứu trước đã đề xuất các phương pháp và công cụ thực hiện việc đảm bảo chất lượng

mã nguồn cho ứng dụng doanh nghiệp [2] Công cụ JCIA ra đời phần nào giải quyết được bài toán trên cho ứng dụng Java EE, công cụ giúp người dùng có thể thực hiện phân tích ảnh hưởng sự thay đổi cho các ứng dụng Java EE đa nền tảng, hỗ trợ các công nghệ nền tảng (framework) như Hibernate, Struts, Spring Mặc dù vậy, công cụ này còn khá đơn giản, phân tích sự phụ thuộc chủ yếu cho

mã nguồn Java và chưa mang lại tính hiệu quả trong việc kiểm thử hồi quy ở góc nhìn của kiểm thử viên

Dựa trên ý tưởng về phương pháp phân tích phụ thuộc trong mã nguồn Java, một cải tiến được nghiên cứu nhằm phân tích ảnh hưởng sự thay đổi cho các thành phần liên quan đến giao diện, từ đó kiểm thử viên sẽ có góc nhìn khách quan hơn về công việc kiểm thử hồi quy cần thực hiện trên các giao diện thay đổi và ảnh hưởng, cũng như đưa ra một cái nhìn khách quan giữa lập trình viên và kiểm thử viên Trong nghiên cứu này, công nghệ Java Servlet sẽ được tập trung hỗ trợ đầu tiên Sau đó, luận văn sẽ hoàn thiện dần phương pháp cho các nền tảng khác Ngoài ra, luận văn cũng phát triển một giải pháp phân loại kiểm thử sau khi có được tập thay đổi và ảnh hưởng từ hai phiên bản khác nhau

để hỗ trợ cho việc kiểm thử hồi quy được thực hiện một cách hiệu quả Một bộ công cụ được phát triển như là một phiên bản tiếp theo của công cụ JCIA [5] để thực hiện các giải pháp đã triển khai và tiến hành thực nghiệm nhằm minh chứng cho tính hiệu quả của công cụ phát triển

Phần còn lại của luận văn được cấu trúc như sau Chương 2 trình bày về phương pháp phân tích sự ảnh hưởng trong công cụ JCIA đã được thực hiện Ở Chương 3, luận văn này giới thiệu phương pháp cải tiến bao gồm phương pháp phân tích sự phụ thuộc cho thành phần giao diện trong công nghệ Java Servlet, phân loại kiểm thử từ các tập thay đổi và tập ảnh hưởng tìm được Tiếp đến, Chương 4 mô tả công cụ hỗ trợ, kết quả thực nghiệm và thảo luận Cuối cùng, Chương 5 là kết luận của luận văn và các định hướng nghiên cứu trong tương

lai

Chương 2 Phương pháp phân tích sự ảnh hưởng trong JCIA

Nội dung của chương này sẽ trình bày về lý thuyết kiểm thử hồi quy và công cụ JCIA đã được xây dựng từ phương pháp phân tích ảnh hưởng sự thay đổi [2] Trước tiên, luận văn sẽ trình bày khái niệm kiểm thử hồi quy, sau đó trình bày tổng quan về bộ công cụ JCIA, tiếp theo là các phương pháp phân tích

sự ảnh hưởng các thành phần cho một số nền tảng và công nghệ trong dự án Java EE

2.1 Kiểm thử hồi quy

Khi phát triển một hệ thống phần mềm, điều quan trọng là đạt được mức yêu cầu về chất lượng Một lỗi nhỏ trong hệ thống cũng có thể là tốn kém để sửa chữa sau khi sản phẩm đã được bàn giao Vì vậy, kiểm thử là một khía cạnh quan trọng trong dự án phát triển sản phẩm của hệ thống phần mềm Để tìm lỗi trong sản phẩm thiết kế càng sớm càng tốt, kiểm thử được thực hiện trong nhiều giai đoạn Một hệ thống phần mềm lớn thường được chia thành nhiều hệ thống con, và một hệ thống con được chia thành các mô đun nhỏ hơn Kiểm thử phần mềm sau đó có thể được tách thành bốn giai đoạn: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận người dùng

Khi phát triển phần mềm liên quan đến thay đổi mã nguồn do lỗi hoặc bổ sung tính năng mới, khách hàng muốn có các tính năng mới trong phiên bản mới nhất, nhưng mong đợi các tính năng cũ vẫn giữ nguyên Dựa vào kinh nghiệm

đã cho thấy những sửa đổi này có thể gây ra chức năng làm việc trước đó thất bại Để kiểm tra tính toàn vẹn của phần mềm đối với loại lỗi bất ngờ này, kiểm thử hồi quy được sử dụng Kiểm hồi quy có thể được thực hiện trên mỗi trong bốn giai đoạn kiểm thử nêu trên, và được thực hiện lý tưởng mỗi khi mã nguồn được sửa đổi hoặc sử dụng trong môi trường mới

Kiểm thử hồi quy là kiểm tra lại có lựa chọn của một hệ thống hoặc thành phần để xác minh rằng các sửa đổi không gây ra các ảnh hưởng không mong muốn và hệ thống hoặc thành phần đó vẫn phải tuân thủ các yêu cầu cụ thể Để giảm thiểu thời gian thực hiện công việc này một cách hiệu quả, việc lựa chọn kĩ thuật kiểm thử và kiểm thử tự động là rất cần thiết Một cách đơn giản để kiểm thử hồi quy là kiểm thử lại toàn bộ phiên bản trước đó Tuy nhiên, khi phiên bản mới có sự thay đổi thì các ca kiểm thử của phiên bản trước đó có thể không chạy lại được mà không có sự sửa đổi hay cập nhật Một bộ các ca kiểm thử tốt phải được duy trì chạy xuyên suốt qua các phiên bản của hệ thống bằng cách cập nhật, loại bỏ các ca kiểm thử lỗi thời qua các phiên bản Các ca kiểm thử dư thừa không ảnh hưởng đến tính đúng, sai cũng như phát hiện được lỗi của hệ

thống, chúng chỉ ảnh hưởng đến thời gian và chi phí kiểm thử Như đã đề cập trước đó, người ta ước tính kiểm thử hồi quy có thể chiếm gần một nửa chi phí bảo trì phần mềm Việc loại bỏ các ca kiểm thử dư thừa nên được thực hiện giúp giảm thời gian và chi phí kiểm thử Chi phí cho việc thực hiện lại một bộ kiểm thử có thể được giảm bằng cách chọn một tập hợp các ca kiểm thử được thực hiện lại, bỏ qua các ca kiểm thử không liên quan hoặc ưu tiên thực hiện một tập con của bộ kiểm thử liên quan đến thay đổi [1]

2.2 Bộ công cụ JCIA

Trong quá trình phát triển phần mềm, việc ra đời các phiên bản mới thay thế phiên bản cũ là tất yếu để giải quyết các yêu cầu thay đổi từ khách hàng, sửa lỗi, nâng cấp và mở rộng hệ thống, v.v Đối với các dự án trong giai đoạn nâng cấp và bảo trì, lập trình viên khó để hiểu các kiến trúc của các ứng dụng trước khi những thay đổi đó được thực hiện do thiếu hoặc không đầy đủ tài liệu phần mềm Do đó, việc kiểm soát toàn bộ sự ảnh hưởng của việc thay đổi là rất khó khăn và có thể dẫn tới nhiều rủi ro cho doanh nghiệp

Công cụ JCIA ra đời với mục đích hỗ trợ xây dựng phần mềm hiệu quả và

dễ dàng hơn Công cụ hỗ trợ phân tích ảnh hưởng của sự thay đổi cho các dự án viết bằng Java EE sử dụng các công nghệ: EJB, JSF, CDI, JAX-WS, JPA, v.v JCIA bao gồm các mô-đun chính: bộ xử lý cơ sở, bộ phân tích ảnh hưởng sự thay đổi, bộ phân tích cấu trúc, bộ trình diễn, bộ quản lý người dùng và lịch sử phân tích Trong đó, mô-đun xử lý cơ sở bao gồm hai thành phần con là bộ tiền

xử lý và bộ phân tích phụ thuộc theo từng nền tảng khác nhau để sinh cây cấu trúc và phụ thuộc cho các nút trên cây [2]

Bộ công cụ này nhận đầu vào là toàn bộ mã nguồn dự án doanh nghiệp sử dụng các nền tảng và công nghệ Java EE dưới dạng tệp nén Người dùng tải dự

án lên JCIA, công cụ sẽ hiển thị cấu trúc của dự án và đồ thị phụ thuộc giữa các thành phần JCIA cung cấp hai cách để thực hiện việc phân tích ảnh hưởng sự thay đổi bằng hai cách:

 Người dùng chọn tập thay đổi và phân tích trực tiếp trên giao diện hiển thị phụ thuộc Đầu vào là mã nguồn, đầu ra là kiến trúc của mã nguồn thể hiện dưới dạng đồ thị cây và dạng đồ thị phụ thuộc

 Phân tích tự động bằng cách người dùng tải lên mã nguồn đã thay đổi, công cụ thực hiện so sánh hai phiên bản mã nguồn và phân tích ảnh hưởng rồi trả về kết quả báo cáo

Công cụ gồm ba phần giao diện chính: Project View, Central View bao gồm Dependency View và Change Impact View, Change Set View và Impact Set View Hình 2.1 mô tả giao diện chính của công cụ JCIA với các phụ thuộc được thể hiện bằng mũi tên có chiều từ nút (node) sở hữu phụ thuộc đến nút bị gọi

Hình 2.1 Giao diện chính của công cụ JCIA

- Khung nhìn Project View

Khung nhìn Project View cung cấp cho người dùng giao diện trực quan để

xem mã nguồn dự án đầu vào dưới dạng cây thư mục Nút chức năng “Expand

All” dùng để hiển thị các thành phần chứa bên trong thư mục và các thư mục

con trong nó (như Hình 2.2)

Hình 2.2 Màn hình Project View

- Khung nhìn Dependency View

Khung nhìn Dependency View cho phép hiển thị tất cả các thành phần trong dự án và sự phụ thuộc lẫn nhau giữa chúng Bao gồm các phụ thuộc hàm gọi hàm, hàm dùng biến

Mũi tên nối giữa hai nút thể hiện rằng hai đối tượng đó có mối quan hệ phụ thuộc lẫn nhau Xem thông tin cụ thể của một nút bằng cách chọn tệp, một cửa

sổ sẽ hiển thị thông tin của tệp đó (như Hình 2.3)

Hình 2.3 Màn hình Dependency View Việc hiển thị phụ thuộc trên giao diện cũng được phân mức tùy vào yêu

cầu người dùng với ba mức: All, None, Partial Mức All cho phép hiển thị tất cả phụ thuộc, mức None không hiển thị phụ thuộc, Partial chỉ hiển thị phụ thuộc

liên quan đến nút đang làm việc

Để thêm một nút vào tập thay đổi, chọn nút đó và chọn chức năng Change

Sau khi nút được thêm vào tập thay đổi, nút sẽ chuyển sang màu xanh Để xem

mã nguồn của tệp, chọn một nút thuộc kiểu tệp, sau đó chọn chức năng View

Source Code (như Hình 2.4)

- Khung nhìn Change Impact View

Change Impact View là phần giao diện được sinh ra sau khi thực hiện phân tích ảnh hưởng, dữ liệu hiển thị sẽ chứa những nút có liên quan đến kết quả phân tích ảnh hưởng (như Hình 2.5)

Hình 2.4 Change Impact View

Hình 2.5 Hiển thị mã nguồn

- Khung nhìn Change Set View

Để thay đổi thuộc tính của một đối tượng (lớp, biến hay hàm), các thay đổi

được lưu trong tập Change và được thể hiện trong khung nhìn Change Set (như

Hình 2.6) Từ đó có thể thay đổi theo mong muốn của người dùng và gửi lên hệ thống yêu cầu phân tích

Hình 2.6 Change Set View

Các nút chức năng bao gồm: Impact Level, Upload Change Set, Clean all

và Analyze

Impact Level: Là giá trị thể hiện cho mức ảnh hưởng muốn phân tích Với

mức 1 là các tệp ảnh hưởng trực tiếp và tương tự các mức 2, 3, 4, v.v

Upload Change Set: Để thay đổi nhiều tệp cùng một lúc bằng cách tải lên

một tệp text chứa đường dẫn của các tệp thay đổi trong mã nguồn dự án Công

cụ sẽ tự tìm kiếm các tệp và thêm chúng vào tập thay đổi

Clean all: Xóa bỏ toàn bộ các tập thay đổi và tập ảnh hưởng đã được phân tích Analyze: Thực hiện phân tích tập thay đổi để tìm các tập bị ảnh hưởng

- Khung nhìn Impact Set View

Là nơi hiển thị các tệp ảnh hưởng sau khi công cụ thực hiện quá trình phân

tích ảnh hưởng từ tệp thay đổi (như Hình 2.7) Nút chức năng Export Data dùng

để xuất dữ liệu phân tích Người dùng sẽ nhận được một tệp zip chứa các tệp

thuộc tập thay đổi và tập ảnh hưởng cùng với một tệp MS Excel chứa thông tin của chúng

Hình 2.7 Impact Set View

2.3 Phân tích các phụ thuộc

2.2.1 Tiền xử lý mã nguồn

Định nghĩa 2.1: (Biểu đồ phụ thuộc Java EE), cho mã nguồn ứng dụng

Java EE, một biểu đồ phụ thuộc Java EE viết tắt là JDG (Java dependency

graph) được định nghĩa là một cặp (V, E) với V = {v 1 ,v 2 , ,v k} là tập nút đại diện cho các thành phần trong mã nguồn như thư mục, tệp, lớp, phương thức, thuộc

Trong ứng dụng Java EE, ngoài mã nguồn Java còn nhiều định dạng mã nguồn được sử dụng như XML, JSP, XHTML, v.v., mỗi định dạng sẽ có cấu trúc cú pháp tương ứng Các mã nguồn này sẽ được tiền xử lý để đưa về định dạng chung là cây cấu trúc, các nút trong cây cấu trúc chứa các thông tin cần thiết để phân tích phụ thuộc và chúng được thiết kế tối ưu phục vụ cho việc duyệt cây và tìm kiếm các nút trên cây dễ dàng hơn [2]

2.2.2 Phân tích sự phụ thuộc cho Struts 2

Hình 2.8 Mô hình ứng dụng Struts2

Struts 2 là một công nghệ nền tảng được thiết kế theo mô hình MVC bao gồm Model, View, Controller như Hình 2.8 Trong đó View hiển thị dữ liệu trong một định dạng cụ thể thường là mã nguồn JSP, Model định nghĩa các đối tượng để tương tác với cơ sở dữ liệu, Model sẽ định nghĩa thuộc tính đối tượng

và thường dùng mã nguồn Java, Controller xử lý lôgic, làm vai trò điều hướng giữa Model và View thông qua lớp FilterDispatcher cùng với tệp cấu hình do người dùng định nghĩa sử dụng mã nguồn XML Một ví dụ cho mã nguồn cấu hình Struts 2 cho chức năng hiển thị được mô tả trong Mã nguồn 2.1

Mã nguồn 2.1 Mã tệp cấu hình Struts 2

<action name=“hienthi” class=“controller.HelloActionSupport”

method=“hienthi”>

<result name=“success”>/WEB-INF/hienthi.jsp</result>

Hình 2.9 mô tả quy trình phân tích sự phụ thuộc cho Struts 2

Hình 2.9 Quy trình phân tích sự phụ thuộc cho ứng dụng Struts 2

Quy trình phân tích sự phụ thuộc bắt đầu từ tệp cấu hình trong mã nguồn Struts 2, các thông tin phụ thuộc giữa các thành phần sẽ được khai thác với phụ

thuộc từ thẻ <action> đến hàm hienthi() của lớp HelloActionSupport và một phụ thuộc từ thẻ <result> đến tệp JSP hienthi.jsp Để phân tích sự phụ thuộc

trong ứng dụng sử dụng Struts 2, bao gồm các bước như sau [2]:

 Bước 1: trình xác nhận sẽ kiểm tra mã nguồn của dự án có sử dụng Struts

2 không, đầu ra là cây cấu trúc tương ứng với tệp cấu hình chính của Struts 2

 Bước 2: một trình phân tích cú pháp sẽ tìm kiếm tất cả tệp cấu hình được

khai báo trong struts.xml và duyệt tất cả các tệp cấu hình, lưu thông tin trong Configuration Model chứa thông tin về : Package, Action, Result,

Result Type, Interceptor, Interceptor Stack

 Bước 3: trình phân tích phụ thuộc sẽ đọc thông tin từ Configuration

Model cùng với phân tích cây cấu trúc để xác định phụ thuộc và thêm vào

cây cấu trúc

2.2.3 Phân tích sự phụ thuộc trong Java Core

Trong mã nguồn Java, có ba loại quan hệ chính giữa các lớp: quan hệ phụ thuộc, thành phần và kế thừa [2] Dựa vào các quan hệ này, bộ phân tích phụ thuộc cho Java Core sẽ phân tích các nút là thành phần Java trên biểu đồ phụ thuộc Java EE và xác định phụ thuộc Java Core giữa các thành phần

Quan hệ phụ thuộc: hai lớp gọi là phụ thuộc nếu phương thức của lớp này

sử dụng đối tượng của lớp kia để thực hiện các thao tác Khi hai lớp phụ thuộc, những thay đổi ở lớp này sẽ ảnh hưởng đến lớp kia Ví dụ, Mã nguồn 2.2 gồm

phương thức f sử dụng đối tượng lớp B, C để thực hiện thao tác

Mã nguồn 2.2 Mã Java thể hiện quan hệ phụ thuộc

public class A { public void f(B b, C c) { … } public void f(){

B b = new B();

C c = new C();

… } }

Quan hệ thành phần: một lớp sẽ chứa các thuộc tính là đối tượng của lớp khác Ví dụ, lớp A chứa các thuộc tính là đối tượng của lớp B như Mã nguồn 2.3

Mã nguồn 2.3 Mã Java thể hiện quan hệ thành phần

public class A {

int a;

private B b; // B là một lớp }

Quan hệ kế thừa: một lớp con kế thừa các thuộc tính public của lớp cha và

có thể thêm một số các thuộc tính riêng Khi lớp cha thay đổi thì các lớp con kế thừa nó sẽ bị ảnh hưởng Ví dụ trong Mã nguồn 2.4, lớp B kế thừa thành phần

public của lớp A và có thêm đặc tính riêng k

Mã nguồn 2.4 Mã Java thể hiện quan hệ kế thừa

public class A {

int a;

public int f(){ } } class B extends A{

public void k(){ } }

2.2.4 Phân tích phụ thuộc cho công nghệ kết nối cơ sở dữ liệu JDBC

JDBC (Java Database Connectivity) là một giao diện lập trình ứng dụng của Java (API) được dùng để kết nối và truy xuất cơ sở dữ liệu JDBC quản lý kết nối đến cơ sở dữ liệu, gửi các câu truy vấn từ ứng dụng Java tới cơ sở dữ liệu

và xử lý kết quả sau truy vấn thành các đối tượng của Java Mã nguồn 2.5 là một

ví dụ về câu truy vấn trong JDBC [2]

Mã nguồn 2.5 Mã nguồn chương trình Sample

public String getTableName(String a){

return “Consumer where name =” +a ; } public Consumer findConsumer(boolean isOrderId, int order, Session session) {

List<Consumer> consumers = new ArrayList<>();

String orderBy = “order by”;

if (order == 0) orderStr = “”;

Một vấn đề quan trọng cần giải quyết từ Mã nguồn 2.5 làm thế nào để biết được câu truy vấn cuối cùng có giá trị gì và có ảnh hưởng đến bảng nào trong cơ

sử dữ liệu Hiện nay có một vài công cụ đã giải quyết được vấn đề này: JSA, JDBC Checker, v.v Trong phần này, một phương pháp dự đoán giá trị câu truy vấn mã nguồn Java bằng đồ thị chuỗi được trình bày

Định nghĩa 2.2: Phép toán gộp: Cho hai tập A = {a 1 , a 2 , , a n} và B =

mãn [2]:

C = {(a + b) | a ∈ A và b ∈ B}

Định nghĩa 2.3: Đồ thị chuỗi: Đồ thị gốc r là nút rỗng, có hướng thể hiện

quá trình thay đổi giá trị của một chuỗi kí tự, kí hiệu G = <V, E>, V là tập các đỉnh, E = V OP V biểu diễn tập các cạnh của đồ thị với các kiểu cạnh: OP =

{INIT, CONCAT} Mỗi đỉnh v ∈ V gồm ba giá trị, kí hiệu v = (l, t, c, R v) [2] Trong đó:

 l ∈ {STRING, VARIABLE, METHOD, APPENDABLE, UNDEFINED}

là nhãn của đỉnh

 t ∈ {UNION, PRODUCT} là kiểu xử lí của đỉnh

 c: thông tin lưu trữ của đỉnh Với l = STRING, c thể hiện cho một chuỗi kí

tự Với l = VARIABLE hoặc APPENDABLE, c thể hiện cho tên biến Với l = METHOD, c thể hiện cho tên hàm

 R v : tập dự đoán chứa những giá trị chuỗi có thể có của đỉnh v Nếu vl =

STRING, R v được khởi tạo là {v c}, ngược lại là { }

Ý nghĩa các các kiểu cạnh được thể hiện trong Bảng 2.1 Biểu thức v 1 (label) v 2 biểu thị một cạnh có hướng từ đỉnh v 1 tới đỉnh v 2 với kiểu là label [2]

Mã nguồn 2.5 mô tả một đồ thị chuỗi được biểu diễn như Hình 2.10 Đầu tiên, mọi câu lệnh trong mã nguồn sẽ được quét, chỉ câu lệnh sử dụng hàm

createQuery sẽ được xử lý Nút mới được tạo tùy theo kiểu của tham số truyền

vào và thêm vào đồ thị Nếu nó là phương thức, nội dung của phương thức được

quét, giá trị câu lệnh return sẽ được xử lý và thêm vào đồ thị Nếu phần tử vừa

thêm là biến cục bộ, bộ sinh đồ thị sẽ quét trong phương thức sử dụng biến đó Nếu câu lệnh thay đổi giá trị biến được tìm thấy, đỉnh mới được tạo tùy thuộc vào việc thay đổi là khởi tạo hay cộng gộp và thêm vào đồ thị

Trong trường hợp giá trị mới đó được tạo nên bởi nhiều thành phần nhỏ, ví

dụ như “select * from” + getTableName() +orderBy thì mỗi thành phần được

nối trực tiếp đến phần tử thêm cuối cùng trong đồ thị với cạnh kiểu CONCAT

Những đoạn câu lệnh ở trong cặp if…then, then…else được tính như một đồ thị con có đỉnh là phần tử được thêm cuối cùng trong đồ thị, và đỉnh gốc đó được đặt kiểu PRODUCT Trong trường hợp câu lệnh cần thêm vào đồ thị ở trong vòng lặp, ta phải xác định giá trị được thêm ở dạng chuỗi kí tự bình thường, hay

là phần tử của một mảng Nếu là một chuỗi kí tự, giá trị của đỉnh được thêm vào

đồ thị có dạng <<(value)+>> Nếu là phần tử của mảng, toàn bộ phương thức

sẽ được quét lại lần nữa để tìm ra những giá trị được thêm vào mảng, sau đó được thêm vào đồ thị Cứ quét như vậy tới cuối phương thức hoặc không còn nút nào được thêm mới nữa thì kết thúc việc sinh đồ thị [2]

Hình 2.10 Ví dụ minh họa đồ thị chuỗi Sau khi đồ thị chuỗi được xây dựng, một bộ giải đồ thị sử dụng phương pháp đệ quy cùng thuật toán duyệt tiền thứ tự để dự đoán câu truy vấn có thể

được tạo ra Mỗi kiểu xử lí t của đỉnh v thể hiện cách thêm giá trị các đỉnh ra của

đến v i có nhãn CONCAT, theo thứ tự FIFO (First In First Out - đỉnh được thêm vào cây trước sẽ được lấy ra trước) Với Rv là tập dự đoán của đỉnh v [2], khi đó:

 v UNION VOUT Rv = Rv ○ Rv1 ○ Rv2 ○…○ Rvn với v 1 , v 2 ,…, v n ∈ VOUT

 v PRODUCT VOUT Rv = (Rv ○ Rv1) (Rv ○ Rv2) … (Rv ○ Rvt ) với v 1 ,

v 2 ,…, v t ∈ VCONCAT Còn lại, v j ∈ VOUT \ VCONCAT, tập dự đoán Rvj sẽ được thêm trực tiếp vào tập dự đoán R của đỉnh METHOD, VARIABLE

và APPENDABLE phía trên gần nhất

Hình 2.11 Quá trình xây dựng và dự đoán câu truy vấn

Từ đồ thị chuỗi, phương pháp giải đồ thị để tìm tập dự đoán được biểu diễn như sau:

q = R “from” + R “getTableName” ○ R “order”

= {“select * from”} ○ ({“Consumer where name =”} ○ R ”a”) ○ R “order by”

= {“select * from”} ○ ({“Consumer where name =”} ○

{“<<UNDEFINED>>“}) (({“order by”} ○ R “category”) “”)

= {“select * from”} ○ {“Consumer where name = <<UNDEFINED>>”} ○ (({

“order by” } ○ (({“category”} ○ {“desc”}) ({“category”} ○ { “asc”)))

“”)

= {“select * from Consumer where name = <<UNDEFINED>>”} ○ (({“order

= {“select * from Consumer where name = <<UNDEFINED>>”}, “select *

from Consumer where name = <<UNDEFINED>> ○ ({“order by category

= [“select * from Consumer where name = <<UNDEFINED>>”,

“select * from Consumer where name = <<UNDEFINED>> order by

category desc”,

“select * from Consumer where name = <<UNDEFINED>> order by

category asc”]

Sau khi tập dự đoán được xây dựng xong, các câu truy vấn được phân tích

Các bảng sử dụng trong câu ở các vị trí quan trọng như: sau “from”, sau “join”,

v.v sẽ được lấy ra Danh sách những bảng này sẽ được thêm vào cây cấu trúc và sinh phụ thuộc

Bảng 2.1 Ý nghĩa các kiểu cạnh trong đồ thị chuỗi

method() {return “value”;}

v 1 (CONCAT)

v 2

Giá trị v 2 được thêm vào giá

trị của v 1

var += “concat value”;

b.append(“append value”);

2.2.5 Phân tích phụ thuộc cho Hibernate

ORM Framework (Object Relational Mapping Framework) là một kỹ thuật chuyển đổi dữ liệu giữa các cơ sở dữ liệu quan hệ sang các đối tượng trong ngôn ngữ lập trình hướng đối tượng như Java, C#, v.v Hibernate là một trong những công nghệ nền tảng cung cấp API cho phép ứng dụng có thể thao tác với cơ sở

dữ liệu, ánh xạ các bảng trong cơ sở dữ liệu với các đối tượng trong Java Hibernate hỗ trợ ánh xạ tự động thông qua tệp ánh xạ XML hoặc dùng Annotation để ánh xạ các trường trong bảng với các thuộc tính của đối tượng Java

Hình 2.12 Quá trình phân tích phụ thuộc cho Hibernate Hình 2.12 mô tả các bước phân tích phụ thuộc cho Hibernate [2] Đầu tiên,

bộ phân tích sẽ xác định xem mã nguồn có sử dụng Hibernate hay không bằng

cách tìm tệp cấu hình hibernate.hbm.xml Tiếp theo, bộ phân tích sẽ đọc các thẻ

có trong tệp cấu hình và chỉ ra các thẻ XML, mỗi thẻ XML có thể khai báo một tệp ánh xạ XML khác hoặc một lớp Java Sau đó, bộ phân tích sẽ xác định tệp cấu hình ánh xạ theo cách nào và phân tích theo cách tương ứng Mỗi nút thể hiện cho bảng, cột của cơ sở dữ liệu được tạo và thêm vào cây AST hiện tại Các nút này cũng được bộ phân tích truy vấn sử dụng để tìm những thành phần có khả năng tác động đến cơ sở dữ liệu

Mã nguồn 2.6 là một ví dụ về tệp cấu hình trong Hibernate, bộ phân tích sẽ

tìm tất cả các thẻ <mapping> chứa thông tin ánh xạ từ cơ sở dữ liệu với lớp trong Java Với phương pháp ánh xạ bằng tệp XML, thẻ <mapping> sử dụng thuộc tính là “resource” cùng với tên tệp XML chứa thông tin ánh xạ Còn với phương pháp Annotation, thuộc tính là “class” và tên lớp Java với đầy đủ

package

Trong Mã nguồn 2.7 của tệp ánh xạ Employee.hbm.xml, thực thể Employee được ánh xạ với bảng EMPLOYEE trong thẻ <class> Khóa chính id được ánh

xạ với thuộc tính id trong thẻ <id>, first_name với firstName, last_name với

lastName, salary với salary trong thẻ <property>

Bộ phân tích Hibernate được chia thành hai phần: phân tích câu truy vấn

và hàm phân tích thực thể Hibernate đã xây dựng sẵn các phương thức tương tác với cơ sở dữ liệu bằng thực thể, danh sách các phương thức cho trong Bảng 2.2 [2] Tham số truyền vào các hàm này có thể là tên của thực thể Java dưới

dạng “package.name” Đi cùng với tên thực thể là đối tượng Java chứa các giá

trị cần gửi cho cơ sở dữ liệu, hoặc chỉ cần gửi đối tượng Java Các phương thức này có các đặc điểm khá riêng biệt nên chúng dễ được tìm thấy bằng cách quét qua từng câu lệnh Sau đó phân tích các tham số truyền vào phương thức này và xác định kiểu thực thể của tham số

Bảng 2.2 Các phương thức truy xuất CSDL có sẵn của Hibernate

delete(Object object)

delete(String entityName, Object object) Xóa một bản ghi

get(Class clazz, Serializable id)

get(String entityName, Serializable id) Lấy thông tin bản ghi

load(Class clazz, Serializable id)

load(Object object, Serializable id) Lấy thông tin bản ghi

2.4 Quản lý phiên bản

Bộ so sánh mã nguồn [2] nhận đầu vào là phiên bản mã nguồn đã được thay đổi, một trình kiểm tra sẽ quét toàn bộ mã nguồn mới, so sánh với mã nguồn gốc để tìm ra những tệp có nội dung thay đổi hoặc có thể là tệp thêm vào hoặc tệp bị xóa Với tệp thay đổi, bộ tiền xử lý tương ứng với mã nguồn tệp đó

sẽ được sử dụng tạo cây AST mới Sau đó, thông tin nút gốc được sử dụng để định danh trên cây AST của mã nguồn gốc Tiếp theo, một trình duyệt cây sẽ duyệt hậu thứ tự được thực hiện và tìm ra các nút được thêm mới, xóa đi, v.v Đầu ra của bộ so sánh mã nguồn là tệp thay đổi để cung cấp cho việc phân tích ảnh hưởng sự thay đổi

Hình 2.13 So sánh cây cấu trúc giữa hai phiên bản mã nguồn

Hình 2.13 là một ví dụ so sánh hai phiên bản mã nguồn của dự án Nút

File_A.java được định danh trên cây cấu trúc mã nguồn gốc, sau đó trình duyệt

cây thực hiện duyệt hậu thứ tự đồng thời trên hai cây với độ sâu cấp ba, nhận

thấy nút thuộc tính có tên ID đã được thay đổi kiểu từ kiểu int thành kiểu long,

và nút phương thức A2() tồn tại trên cây mới nhưng không có trên cây gốc, do

đó nút này đã được thêm mới