Khóa luận Kiểm chứng các giao thức bằng AOP

1 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Thân Văn Đức KIỂM CHỨNG CÁC GIAO THỨC BẰNG AOP KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công nghệ thông tin HÀ NỘI - 2010 2 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Thân Văn Đức KIỂM CHỨNG CÁC GIAO THỨC BẰNG AOP KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công nghệ thông tin Cán bộ hướng dẫn: Ths.Phạm Thị Kim Dung HÀ NỘI - 2010 3 Lời cảm ơn Trong quá trình thực hiện đề tài, tôi đã gặp rất nhiều khó khăn và bỡ ngỡ. Nếu không có sự giúp đỡ và lời động viên chân thành của nhiều người có lẽ tôi khó có thể hoàn thành tốt khóa luận này. Đầu tiên tôi xin tỏ lòng biết ơn sâu sắc đến Cô Phạm Thị Kim Dung đã tận tình hướng dẫn trong suốt quá trình viết khóa luận tốt nghiệp. Tôi muốn gửi lời cảm ơn đến các thầy giáo cô giáo trong hội đồng bảo vệ. Những ý kiến đóng góp của cô là vô cùng hữu ích, nó giúp tôi nhận ra các khuyết điểm của khóa luận. Tôi xin chân thành cảm ơn quý Thầy, Cô và bạn bè trong 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 kiến thức, sát cánh và trải nghiệm cùng tôi trong suốt 4 năm học tập. Với vốn kiến thức được tiếp thu trong quá trình học không chỉ là nền tảng cho quá trình nghiên cứu khóa luận mà còn là hành trang quí báu để tôi bước vào đời một cách vững chắc và tự tin. Con xin cảm ơn cha mẹ, những người đã có công sinh thành, dưỡng dục và nuôi dạy con nên người. Cuối cùng tôi kính chúc quý thầy, cô dồi dào sức khỏe, đạt được nhiều thành công trong công việc và cuộc sống. 4 TÓM TẮT NỘI DUNG Kiểm chứng phần mềm có một vai trò quan trọng trong việc đảm bảo tính đúng đắn của hệ thống phần mềm trong suốt quá trình thực thi,kiểm chứng giúp phát hiện, tìm ra lỗi và thông báo lỗi cho nhà phát triển. Phương pháp lập trình hướng khía cạnh (AOP) cùng với công nghệ AspectJ ra đời đã tạo ra một hướng phát triển mới cho kiểm chứng phần mềm, giúp nâng cao khả năng dò tìm lỗi, thông báo lỗi mà không ảnh hưởng tới mã nguồn hệ thống. Trong thực tế, biểu đồ UML là sự lựa chọn rất phổ biến cho việc mô hình hóa hệ thống phần mềm ở giai đoạn thiết kế hiện nay. Trong đó, biểu đồ tuần tự (sequence diagram) là một biểu đồ quan trọng, nó miêu tả các cách thức đối tượng tương tác và giao tiếp với nhau. Việc kiểm chứng thiết kế và kiểm chứng các giao thức ràng buộc trong biểu đồ trình tự là rất cần quan trọng vì nếu thiết kế biểu đồ tuần tự sai kéo theo các hoạt động của hệ thống hoặc trình tự hệ thống cần thực hiện sẽ bị sai dẫn tới toàn bộ hệ thống thiết kế sai. Trong phạm vi khóa luận, tôi xin trình bày phương pháp sinh mã aspect phục vụ cho mục đích kiểm chứng phần mềm từ biểu đồ tuần tự kết hợp với máy trạng thái và công cụ tự động sinh mã aspect dựa trên phương pháp này. Mã aspect tạo ra từ công cụ có thể dùng đan vào chương trình để thực hiện nhiệm vụ kiểm chứng các ràng buộc giữa các đối tượng và tính đúng đắn của hệ thống nhằm giảm thiểu tối đa lỗi khi viết mã cài đặt cho hệ thống. 5 MỤC LỤC Chương 1. Mở Đầu ....................................................................................................8 1.1. Đặt vấn đề .........................................................................................................8 1.2.Bài toán..............................................................................................................8 1.3. Tổng quan về phương pháp giải quyết bài toán..................................................9 1.4. Cấu trúc khóa luận.............................................................................................9 Chương 2. Ngôn ngữ UML và biểu diễn biểu đồ trong UML bằng XMI..............11 2.1. Giới thiệu chung về UML:...............................................................................11 2.2. Các loại biểu đồ UML .....................................................................................12 2.2.1. Nhóm biểu đồ về cấu trúc ........................................................................12 2.2.2. Nhóm biểu đồ hành vi ..............................................................................12 2.3. Biểu đồ tuần tự trong UML2.0(Sequence diagram) .........................................12 2.4. Một số thành phần chính trong biểu đồ tuần tự ................................................14 2.4.1. Đường đời (lifeLine) ................................................................................14 2.4.2. Thông điệp (Message)..............................................................................15 2.4.3. Đoạn gộp (Combind Fragment)................................................................16 2.5. Biểu diễn biểu đồ tuần tự :...............................................................................19 2.5.1. Biểu diễn Đường đời (LifeLine ):.............................................................19 2.5.2. Biểu diễn Thông điệp: ..............................................................................19 2.5.3. Lời chú giải (Comment) ...........................................................................19 2.5.4. Các đoạn gộp (CombindedFragment) .......................................................19 2.6. Sơ lược về XML..............................................................................................20 2.7. Biểu diễn tài liệu XML....................................................................................21 2.8. TƯƠNG TÁC VỚI TÀI LIỆU XML ...............................................................23 2.8.1 DOM........................................................................................................23 2.8.2 XML DOM :.............................................................................................23 2.8.3 XMI:.........................................................................................................25 2.9. Máy trạng thái FSM. .......................................................................................25 2.9.1. Tổng quan về các thành phần trong máy trạng thái FSM ..........................25 2.9.2. Xây dựng máy hữu hạn trạng thái từ các thành phần của biểu đồ ...................26 CHƯƠNG 3..............................................................................................................30 Aspect và lập trình hướng khía cạnh ......................................................................30 3.1 Tổng quan về lập trình hướng khía cạnh. ..........................................................30 3.2 Biên dịch AOP: ................................................................................................31 6 3.3 LỢI ÍCH CỦA AOP : .......................................................................................32 3.4 AspectJ.............................................................................................................32 3.4.1. Đặc tả ngôn ngữ: ......................................................................................32 3.4.2. Phần thực thi:...........................................................................................33 3.5. Một số khái niệm cơ bản trong AspectJ: ..........................................................33 3.5.1. Join point .................................................................................................33 3.5.2. Pointcut....................................................................................................33 3.5.3. Advice .....................................................................................................33 3.5.4. Aspect......................................................................................................34 3.6. Cơ chế họa động của AspectJ ..........................................................................35 3.6.1. Compile – time: .......................................................................................35 3.6.2. Link – time: .............................................................................................35 3.6.3. Load – time:.............................................................................................35 3.7. Sử dụng AOP Phát triển ứng dụng và phương pháp kiểm chứng dựa trên AOP ...............................................................................................................................36 CHƯƠNG 4..............................................................................................................38 PHƯƠNG PHÁP KIỂM CHỨNG CÁC GIAO THỨC BẰNG AOP ....................38 4.1 Biểu diễn giao thức...........................................................................................38 4.2. Tiền điều kiện và hậu điều kiện : .....................................................................39 4.2.1. Tiền điều kiện : ........................................................................................39 4.2.2. Hậu điều kiện :.........................................................................................39 4.2.3 Biểu diễn tiền điều kiện và hậu điều kiện trong biểu đồ trình tự : ..............39 4.3 Kiểm chứng giao thức: .....................................................................................40 Chương 5 Xây dựng công cụ sinh mã từ máy trạng thái ......................................42 5.1 Tổng quan về xây dựng công cụ sinh mã từ máy trạng thái...............................42 5.1.1 Lấy các thành phần trong tài liệu XMI. .....................................................42 5.1.2. Sinh mã Aspect từ biểu đồ tuần tự UML ..................................................45 5.2. Sinh mã kiểm chứng giao thức AnBm .............................................................46 Chương 6 Kết luận...................................................................................................49 6.1 Kết luận về khóa luận .......................................................................................49 6.2 Hướng phát triển trong tương lai : ....................................................................50 7 Danh mục ký hiệu, từ viết tắt UML Unified Modeling Language AOP Aspect-Oriented Programming FSM Finite State Machine OOP Object Oriented Programming XML eXtensible Markup Language XMI XML Metadata Interchange DOM Document Object Model SEQUENCE DIAGRAM BIỂU ĐỒ TUẦN TỰ 8 Chương 1. Mở Đầu 1.1. Đặt vấn đề Trong những năm cuối của thế kỉ XX, nhân loại đã được chứng kiến những tiến bộ vượt bậc của các ngành khoa học công nghệ như: công nghệ điện tử, công nghệ sinh học… và một ngành công nghệ mới không thể không nhắc tới đó là ngành công nghệ thông tin. Những tiến bộ của ngành công nghệ thông tin đã giúp ích được cho con người và những ngành khoa học khác là rất lớn. Ngành công nghệ phần mềm là sự áp dụng một cách tiếp cận có hệ thống, có kỷ luật và định lượng được cho những việc phát triển, hoạt động bảo trì phần mềm. Ngành công nghệ phần mềm bao trùm các kiến thức, các công cụ, và các phương pháp cho việc định nghĩa yêu cầu phần mềm và thực hiện các tác vụ thiết kế phần mềm, xây dựng phần mềm, kiểm thử phần mềm ,bảo trì phần mềm…. Trong các giai đoạn đó, giai đoạn kiểm thử phần mềm với các chức năng kiểm tra, phát hiện và sửa lỗi phần mềm là rất quan trọng để đảm bảo chất lượng của một phần mềm. Từ thực tế cho thấy, các lỗi của phần mềm gây thiệt hại rất lớn về thời gian, tiền bạc và công sức của con người. Lỗi phần mềm được phát hiện càng muộn càng gây thiệt hại nghiêm trọng, gây tổn thất về thời gian,công sức và có thể phải xây dựng lại toàn bộ hệ thống từ đầu. Vì vậy, việc tìm ra lỗi sớm và sửa lỗi sớm là rất cần thiết khi thiết kế một hệ thống phần mềm. Kiểm chứng phần mềm là kiểm tra phần mềm có được thiết kế đúng và thực thi đúng như đặc tả yêu cầu không. Với vai trò quan trọng như vậy, giai đoạn kiểm thử trong ngành công nghệ phần mềm được sự quan tâm và tìm hiểu của nhiều nhà nghiên cứu. Trên thực tế, đa số các thao tác kiểm chứng phần mềm là dựa trên việc kiểm tra đầu vào và đầu ra của chương trình, việc kiểm tra này được thực hiện nhiều lần thủ công và cố gắng tìm ra tất cả các trường hợp cho đầu vào để xem đầu ra có được kết quả như ý không. Vì vậy, việc kiểm tra như vậy không thể đánh giá hay thẩm định được quá trình hoạt động logic của chương trình theo đúng như đặc tả ban đầu hay không. Quá trình hoạt động logic ở đây có thể là các tương tác tuần tự giữa các đối tượng, các giao thức giữa các đối tượng…. nhằm đảm bảo hơn tính đúng đắn của sản phẩm phần mềm. Trong khóa luận này tôi xin trình bày phương pháp tự động sinh mã aspect kiểm chứng đặc tả giao thức dựa trên lập trình hướng khía cạnh ( Aspect-Oriented Programming). 1.2.Bài toán Hiện nay có nhiều phương pháp để kiểm chứng phần mềm như giả lập hay kiểm chứng mô hình. Trong phạm vi bài toán được đặt ra, tôi muốn đề cập tới phương pháp kiểm chứng phần mềm dựa trên phương pháp lập trình hướng khía cạnh. Việc kiểm chứng cụ 9 thể của bài toán là kiểm chức giao thức đặc tả hoạt động của các đối tượng trong Java. Giao thức có thể được mô tả bằng tay hoặc mô tả bằng biểu đồ trạng thái. Trong cách tiếp cận này, một ứng dụng hướng đối tượng được đặc tả bằng mô hình UML và được cài đặt bằng ngôn ngữ java. Từ biểu đồ trình tự UML sẽ là đầu vào để tạo ra mã kiểm chứng aspect. Mã này được đan vào chương trình bằng công cụ AspectJ để kiểm tra hoạt động của chương trình trong thời gian chạy. Trong quá trình chạy của chương trình, các đoạn mã aspect sẽ tự động kiểm tra các giao thức và đưa ra thông báo lỗi khi có bất kì vi phạm nào xảy ra. Từ một biểu đồ tuần tự UML, xuất ra tài liệu XMI đặc tả của biểu đồ này. Tài liệu XMI này chính là đầu vào cho công cụ cần xây dựng. Dựa vào các kiến thức UML, XML tôi sẽ phân tích tài liệu XMI, sử dụng máy trạng thái (FSM) mô tả biểu đồ tuần tự UML và sinh mã aspect phục vụ kiểm chứng. Mã aspect là kết quả sau cùng của công cụ. 1.3. Tổng quan về phương pháp giải quyết bài toán Bài toán bắt đầu với đầu vào là biểu đồ tuần tự UML, biểu đồ này đã được xuất ra dưới dạng XMI, file XMI này sẽ là đầu vào cho công cụ sinh mã kiểm chứng. Trong báo cáo “Checking implementations of UML 2.0 sequence diagrams”[4] đã xây dựng được công máy trạng thái. Dựa vào máy trạng thái này, tôi đã phát triển máy trạng thái để phù hợp với bài toán đặt ra. Máy trạng thái FSM sẽ duyệt tất cả các trạng thái. Dựa vào các kiến thức về AspectJ [2,3] tôi đã tìm hiểu để xây dựng công cụ tự động sinh mã aspect. Việc xây dựng công cụ tự động sinh aspect của tôi gồm các bước : - Phát triển máy trạng thái để sử dụng theo mục đích kiểm thử. Đầu tiên, tôi sẽ phải tìm hiểu về tài liệu XMI, cách sử dụng XML DOM để đọc tài liệu XMI này để phát triển thêm các yêu cầu về xử lý tiền điều kiện và hậu điều kiện. Phát triển thêm các phương thức để tiện cho việc lấy ra các trạng thái, quản lý các trạng thái và sử lý các String, các hiển thị theo đúng mục đích. - Xây dựng chức năng tự động sinh mã aspect từ FSM : Sử dụng máy trạng thái được sinh ra, duyệt qua từng trạng thái trong FSM, áp dụng cấu trúc cú pháp cài đặt mã aspect để tạo ra mã aspect hoàn chỉnh. 1.4. Cấu trúc khóa luận Chương 1 : Mở đầu. Chương 2 : Trình bày sơ qua các kiến thức về UML,XML,XMI. Trong biểu đồ UML tôi đi tìm hiểu chi tiết về biểu đồ tuần tự và các thành phần của nó. Đây là nền tảng để tìm hiểu cách biểu diễn và hoạt động của biểu đồ. Dựa vào những kiến thức về XML,XMI giúp tôi nắm được cấu trúc tài liệu, cách thao tác, sử lý tài liệu XMI để lấy ra những thông tin cần thiết cho việc phát triển máy trạng thái FSM. 10 Chương 3 : Trình bày về aspect và lập trình hướng khía cạnh. Nêu nên những ưu điểm của AOP, vai trò của nó trong sự phát triển của ngành công nghệ phần mềm. . Những kiến thức về AOP và aspect giúp tôi tạo ra các đoạn mã aspect theo đúng cú pháp phục vụ cho việc kiểm thử. Giới thiệu về AspectJ là một cài đặt của AOP cho ngôn ngữ lập trình Java. Chương 4 : Trình bày phương pháp giải quyết bài toán kiểm chứng các giao thức bằng AOP. Chương 5: Trình bày công cụ sinh mã Aspect và mã kiểm chứng giao thức AnBm. Chương 6 : Kết luận. 11 Chương 2. Ngôn ngữ UML và biểu diễn biểu đồ trong UML bằng XMI. 2.1. Giới thiệu chung về UML: [1] Ngôn ngữ UML(Unified Modeling Language) là một loại ký pháp mô hình hướng đối tượng. Ý tưởng về đối tượng bắt nguồn từ ngôn ngữ Simula, nhưng chỉ trụ vững được từ những năm 80, với sự xuất hiện của ngôn ngữ lập trình Smalltalk và C++.Khi lập trình hướng đối tượng phát triển thì có nhu cầu về mô hình hóa hướng đối tượng.Chính vì vây, dẫn tới sự xuất hiện của các phương pháp mô hình hóa đối tượng như OOAD của Grady Booch, OMT của Jim Rumbaugh, Fusion của Derek Coleman …. Do có nhiều chuẩn dẫn tới sự phân tán không hợp lý, có nhưng khi có các sự xung đột của các phương pháp với nhau.Và xu hương nhất thiết là cần hợp nhất các phương thức này lại. Tháng 1/1994 IG.booch và J.Rumbauch bắt đầu hợp tác, nhắm xây dựng một “Phương pháp hợp nhất ” trên cơ sở hai phương pháp Booch 93 và OMT-2. Năm 1995 I.Jacobsson và các phương pháp Objectory gia nhập,và từ đó họ được các đồng nghiệp gọi là “ba người bạn”(the three amigos).Họ quyết định thu hẹp mục tiêu, nhằm thành lập mô hình hóa hợp nhất. - Tháng 6/1996 ra đời phiên bản UML 0.9. - Tháng 1/1997 IBM và Softteam kết hợp các thành viên UML để đưa ra phiên bản 1.1 - Tháng 11/1997 UML 1.1 được công nhận là chuẩn cho các ngôn ngữ mô hình hóa và trao đặc quyền xét lại (Do OMG-Object Management Group công nhận) - Tháng 6/1998 ra đời UML 1.2 - Tháng 10/1998 ra đời UML 1.3 - Tháng 5/2001 ra đời UML 1.4 - Tháng 6/2003 thông qua dự thảo UML 2.0(dự kiến phe duyệt vào cuối năm 2004) Mỗi phiên bản sau đều có sự hiệu chỉnh, bổ sung so với phiên bản trước, chẳng hạn trong phiên bản UML 1.4 có 9 loại biểu đồ nhưng trong phiên bản 2.0 có tời 13 loại biểu đồ. Tuy nhiên cần chú ý: khi xem xét tiến trình RUP, phải hiểu rằng đây là một tiến trình mang tính “tổng quát”, tức là nó có thể đem áp dụng vào mọi dự án phần mềm, vì thế rất phức tạp. Trong những dự án nhỏ, chúng ta chủ yếu sử dụng ý tưởng của RUP và một số bước nào đó. 12 Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) là một ngôn ngữ để biểu diễn mô hình theo hướng đối tượng được xây dựng bởi ba tác giả trên với chủ đích là: - Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng. - Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần mô hình hoá. - Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có nhiều ràng buộc khác nhau. - Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy. 2.2. Các loại biểu đồ UML Về biểu đồ UML có tất cả 12 loại biểu đồ được chia ra làm hai nhóm :Nhóm các biểu đồ về cấu trúc, và nhóm các biểu đồ hành vi.(theo UML 2.0) 2.2.1. Nhóm biểu đồ về cấu trúc - Biểu đồ lớp - Biểu đồ đối tượng - Biểu đồ thành phần - Biểu đồ bố trí - Biểu đồ gói - Biểu đồ cấu trúc đa hợp 2.2.2. Nhóm biểu đồ hành vi - Biểu đồ ca sử dụng - Biểu đồ trình tự - Biểu đồ giao tiếp - Biểu đồ máy trạng thái - Biểu đồ hoạt động - Biểu đồ bao quát tương tác 2.3. Biểu đồ tuần tự trong UML2.0(Sequence diagram) Biểu đồ tuần tự là biểu đồ theo thứ tự thời gian. Biểu đồ trình tự là một trong hai biểu đồ tương tác chính, với chủ đích làm nổi bật trình tự theo thời gian của các thông điệp.Nó trình bày một một tập hợp các đối tượng và các thông điệp được trao đổi giữa chúng.Các đối tượng là các cá thể có tên hay khuyết danh của các lớp, cũng có thể là các đối tác, các hợp tác, các thành phần, các nút. Biểu đồ trình tự được trình bày theo hai chiều. - Chiều ngang bố trí các đối tượng, các đối tượng bố trí theo hình chữ nhật, hoặc bằng biểu tượng, dàn thành hàng ngang trên biểu đồ.Trình tự các đối tượng không quan 13 trọng.Nhưng đối tượng khởi phát thông điệp nên để ở phía bên trái, đối tượng mới được tạo lập thì nên vẽ ở phía dưới ngang với thông điệp tạo lập chúng. - Hàng dọc là trục thời gian(hướng xuống dưới).Mỗi đối tượng có mang một trục đứng(nét đứt), gọi là đường đời(có tài liệu gọi là vòng đời). Đường đời kết thúc bởi một gạch chéo, khi đối tượng bị hủy bỏ.Các thông điệp là các mũi tên nằm ngang nối đường đời của hai đối tượng và vẽ lần lượt từ trên xuống dưới theo thứ tự thời gian. Nếu muốn làm rõ thời kỳ hoạt động (nắm giữ điểu khiển) và làm rõ sự lồng nhau của các thông điệp, trên đường đời vè thêm hay một số dải hẹp hình chữ nhật, gọi là tiến trình điều khiển(focus of coltrol).lề phải và lề trái của biểu đồ có thể gi các giải thích, các ràng buộc. Định dạng thông điệp thôngđiệp(tham số) ví dụ message(str).Tên thông điệp có thể gắn thêm tiền tố với các ý nghĩa sau: - Một biểu thức trình tự có dạng a:a là số thứ tự của thông điệp, nhưng có thể là một nhãn(ký tự). - Một điều kiện lựa chọn, ở dạng [điều kiện] với ý nghĩa thông điệp chỉ được gửi khi điều kiện thỏa mãn. Biểu đồ tuần tự bao gồm nhiều thành phần, song có ba thành phần chủ yếu là các đối tượng, thông điệp và các đoạn gộp. 14 Hình 1. Ví dụ về sequence diagram trong việc giao dịch với ngân hàng 2.4. Một số thành phần chính trong biểu đồ tuần tự Như đã đề cập ở trên, biểu đồ tuần tự UML biểu diễn quá trình tương tác giữa các đối tượng trong hệ thống phần mềm theo trình tự thời gian gửi và nhận các thông điệp. Gần đây, phiên bản UML 2.0 ra đời và cập nhật thêm nhiều đặc điểm mới so với phiên bản UML 1 như Interaction Use hay Combined Fragment (đoạn gộp). Các tài liệu đặc tả của OMG là nơi cần thiết để tìm hiểu về cấu trúc và ý nghĩa của các thành phần trong biểu đồ, ngoài ra cũng có một bài báo mô hình hóa các thành phần này chặt chẽ về mặt toán học . Dưới đây là hình vẽ biểu diễn cấu trúc và mối liên quan giữa các thành phần trong một biểu đồ tuần tự UML 2.0 Hình 2. Biểu đồ tuần tự UML 2.0 Tuy nhiên, giới hạn trong báo cáo này chúng ta không đề cập hết tất cả các thành phần trên mà chỉ giới thiệu ba loại chính và cần thiết cho việc xây dựng máy trạng thái đó là: đường đời (Lifeline), thông điệp (Message) và đoạn gộp (Combined Fragment). 2.4.1. Đường đời (lifeLine) Một đường đời có thể biểu diễn cho một đối tượng hoặc là một lớp. Với đối tượng nó có tên dạng là objectName:ClassName trong đó objectName có thể bỏ qua nếu bỏ qua thì nó là một đối tượng không xác định. Như trong Hình 3 thì là một đối tượng s có kiểu là 15 Student ứng với đường đời thứ nhất, cái thứ hai sẽ là một đối tượng không xác định nào đó thuộc lớp Student. Với lớp thì đơn giản chỉ có tên lớp. Hình 3. Đường đời 2.4.2. Thông điệp (Message) Một thông điệp hay một thông điệp xuất phát từ đường đời này sang đường đời khác, mỗi thông điệp có một tên. Nó chính là biểu diễn cho một phương thức của lớp đích được gọi từ một đối tượng của lớp nguồn và tên thông điệp chính là signature của phương thức đó bao gồm cả các tham số (nếu có) tuy nhiên thường không có kiểu trả về và kiểu của các tham số. Trong Altova UModel cung cấp bảy loại thông điệp như trên hình vẽ bao gồm: thông điệp thông thường, thông điệp trả lời, thông điệp khởi tạo, thông điệp hủy một đường đời, và hai loại thông điệp có độ trễ về thời gian. Các thông điệp được sắp theo thứ tự thời gian thực hiện trên hệ thống thật. Vì ở đây cài đặt sử dụng ngôn ngữ Java nên ta có thể tạm không quan tâm tới các thông điệp hủy một đường đời. 16 Hình 4. Thông điệp 2.4.3. Đoạn gộp (Combind Fragment) Đoạn gộp là một vùng hình chữ nhật trên biểu đồ được định nghĩa bao gồm có hai thành phần là: InteractionOperator và các InteractionOperand. Một InteractionOperand là một vùng chứa các thông điệp trong đoạn gộp và nó có ràng buộc Interaction Constraint riêng cho nó, khi ràng buộc thỏa mãn thì các thông điệp trong vùng này sẽ được thực thi. Một đoạn gộp có thể có một hay nhiều InteractionOperand tùy thuộc vào InteractionOperator sử dụng là gì. Có mười một loại InteractionOperator tuy nhiên, ta sẽ đề cập tới 4 loại InteractionOperator chính là loop, alternative, option và break. Loop (loop) thì giống như cấu trúc vòng lặp trong ngôn ngữ lập trình, khi nó được sử dụng thì đoạn gộp sẽ chỉ có một InteractionOperand. Các thông điệp trong đó có thể lặp từ 0 tới n lần tùy theo đáp ứng ràng buộc là như thế nào. 17 Hình 5. Miêu tả Loop. Option (opt) thì giống như cấu trúc if then trong các ngôn ngữ lập trình. Các thông điệp trong Interaction Operand duy nhất của đoạn gộp này sẽ được thực hiện nếu thỏa mãn ràng buộc Interaction Constraint nếu không thì toàn bộ sẽ bị bỏ qua. Hình 6. Miêu tả opt Alternative (alt) thì giống như cấu trúc if then else, có thể có rất nhiều khối if then liên tiếp nhau mỗi khối tương ứng với một Interaction Operand và theo thứ tự thì sẽ phải có một trong số chúng được thực hiện còn các thông điệp trong các khối còn lại bị bỏ qua. 18 Hình 7. Miêu tả alt Còn break (break) thì hơi đặc biệt một chút. Nếu như Interaction Constraint không thỏa mãn thì các thông điệp trong đoạn gộp này bị bỏ qua giống như trường hợp với option. Tuy nhiên nếu như ràng buộc thỏa mãn, thì chỉ các thông điệp trong khối này được thực hiện còn lại tất cả các thông điệp đứng dưới đoạn gộp này trên biểu đồ sẽ không được thực hiện nữa. Hình 8. Miêu tả Break 19 2.5. Biểu diễn biểu đồ tuần tự bằng XMI : Là việc lấy các thành phần trong tài liệu XMI để xây dựng các thành phần cho biểu đồ tuần tự. Các thành phần trong biểu đồ tuần tự rất nhiều, ta chỉ lấy những thành phần phục vụ cho việc xây dựng máy trạng thái FSM và sinh mã Aspect kiểm thử. Các thành phần cần được biểu diễn là đường đời(LifeLine), Thông điệp(Message), Lời chú giải (Comment),Điểm(point), và các thành phần đoạn gộp như loop, opt, alt, break. Thành phần Comment dùng để đặc tả các ràng buộc, từ đó xây dựng lớp Constraint. 2.5.1. Biểu diễn Đường đời (LifeLine ): Đặc tả các đặc trưng của Lifeline như id, name, classname, objectname. Các thông tin trển được lấy trong thẻ tag lifeline trong tài liệu XMI. 2.5.2. Biểu diễn Thông điệp: Có hai loại thông điệp trong biểu đồ tuần tự. Trong nội dung bài khóa luận ta chỉ quan tâm đến loại thông điệp được chứa trong đoạn mã như hình dưới đây : Dùng DOM XML lấy các thông tin cần thiết từ đoạn mã trên như là id, name,địa chỉ thông điệp được gửi (sendEvent), đích đến (receiveEvent). 2.5.3. Lời chú giải (Comment) Việc định nghĩa ra Comment để xác định tiền điều kiện và hậu điều kiện của các phương thức. Lấy nội dung tiền điều kiện và hậu điều kiện trong thuộc tính body của thẻ ownedComment. Ta xử lý xâu kết quả đó lấy ra các thành phần cần thiết, các thành phần đó ở đây tôi định nghĩa bao gồm kiểu pre/pos, điều kiện và thông điệp (phương thức) liên quan đến nó. 2.5.4. Các đoạn gộp (CombindedFragment) 20 Đoạn mã trên chứa thành phần liên quan đến các CombindedFragment. Tất cả các thẻ interaction Constraint đều được đặt trong đoạn mã như trên. Tên kiểu của chúng được đặt trong thẻ operand xmi:type =”UML:InteractionOperand” với thuộc tính interactionOperator. 2.6. Sơ lược về XML. XML là viết tắt cho chữ eXtensible Markup Language , XML gần giống với HTML (Hypertext markup Language). Nó cung cấp một phương tiện dùng văn bản để mô tả thông tin và áp dụng một cấu trúc kiểu cây cho thông tin đó. Mọi thông tin đều hiển thị dưới dạng văn bản (text), chen giữa các thẻ đánh dấu (markup) với nhiệm vụ ký hiệu sự phân chia thông tin thành một cấu trúc có thứ bậc của các dữ liệu ký tự . XML là một ngôn ngữ đánh dấu tương đối mới vì nó là một subset (một phần nhỏ hơn) của và đến từ (derived from) một ngôn ngữ đánh dấu già dặn tên là Standard Generalized Markup Language (SGML). Ngôn ngữ HTML cũng dựa vào SGML, thật ra nó là một áp dụng của SGML. SGML được phát minh bởi Ed Mosher, Ray Lorie và Charles F. Goldfarb của nhóm IBM research vào năm 1969, khi con người đặt chân lên mặt trăng. Lúc đầu nó có tên là Generalized Markup Language (GML), và được thiết kế để dùng làm meta-language, một ngôn ngữ được dùng để diễn tả các ngôn ngữ khác - văn phạm, ngữ vựng của chúng ,.v.v.. Năm 1986, SGML được cơ quan ISO (International Standard Organisation) thu nhận (adopted) làm tiêu chuẩn để lưu trữ và trao đổi dữ liệu. Khi Tim Berners-Lee triển khai HyperText Markup Language - HTML để dùng cho các trang Web hồi đầu thập niên 1990, ông ta cứ nhắc nhở rằng HTML là một áp dụng của SGML. Vì SGML rất rắc rối, và HTML có nhiều giới hạn nên năm 1996 tổ chức W3C thiết kế XML. XML version 1.0 được định nghĩa trong hồ sơ February 1998 W3C Recommendation. - Ví dụ về XML. 21 Mrs. Mary McGoon 2.7. Biểu diễn tài liệu XML Tài liệu xml phải thỏa mãn: - Phải có một root (gốc) duy nhất, nó chứa tất cả các element khác trong tài liệu. - Mỗi opening Tag phải có một closing Tag giống như nó. - Tags trong XML thì case sensitive, tức là opening Tag và closing Tag phải được đánh vần y như nhau, chữ hoa hay chữ thường. - Mỗi Child Element phải nằm trọn bên trong Element cha của nó. - Attribute value trong XML phải được gói giữa một cặp ngoặc kép hay một cặp apostrophe. Phần tử gốc :Một văn bản XML phải được chứa trong một phần tử tố đơn. Phần tử đơn đó được gọi là phần tử gốc, và nó chứa tất cả các từ ngữ và bất cứ phần tử nào trong văn bản. Trong ví dụ dưới đây, văn bản XML được chứa đựng trong một phần tử đơn . Chú ý văn bản này có một chú thích nằm ngoài phần tử gốc, điều này hoàn toàn hợp lệ. Hello, World! Những phần tử không được đan chéo: Các phần tử XML không thể đan chéo. Đây là vài đánh dấu không hợp lệ: I really love XML. 22 Nếu bạn bắt đầu một phần tử trong một phần tử , bạn cũng phải kết thúc nó ở đó. Nếu bạn muốn các dòng chữ XML là chữ nghiêng, bạn cần bổ sung một phần tử thứ hai để sửa lại đánh dấu: I really love XML. Bộ kiểm ngữ XML sẽ chỉ chấp nhận đánh dấu này, trong khi bộ kiểm ngữ HTML chấp nhận cả hai. Thẻ kết thúc là cần thiết. Bạn không thể bỏ một thẻ kết thúc nào. Trong ví dụ đầu tiên dưới đây, đánh dấu không hợp lệ vì không có thẻ kết thúc đoạn (). Trong khi HTML (vài trường hợp trong SGML) đều chấp nhận được thì điều này lại bị bộ kiểm ngữ XML từ chối. Yada yada yada... Yada yada yada... ... Nếu một phần tử không chứa đánh dấu nào thì nó được gọi là phần tử rỗng; dấu ngắt HTML () và hình ảnh (img>) là hai phần tử ví dụ. Trong các phần tử rỗng ở của văn bản XML, bạn có thể đặt một gạch chéo đóng trong thẻ bắt đầu. Hai phần tử dấu ngắt và hai phần tử hình ảnh dưới có nghĩa tương tự với bộ kiểm ngữ XML: Các phần tử là phân biệt chữ hoa/chữ thường. 23 Các phần tử XML là phân biệt chữ hoa/chữ thường. Trong HTML, và đều giống nhau; trong XML, thì lại không thế. Nếu bạn kết thúc một phần tử bằng một thẻ , sẽ bị mắc lỗi. Trong ví dụ dưới đây, tiêu đề phía trên là không hợp lệ, còn tiêu đề dưới thì chính xác. Thuộc tính phải nằm trong dấu trích dẫn Có hai nguyên tắc về các thuộc tính trong văn bản XML: - Thuộc tính phải có giá trị - Những giá trị đó phải được đặt trong dấu trích dẫn (" hoặc '). 2.8. TƯƠNG TÁC VỚI TÀI LIỆU XML 2.8.1 DOM. DOM là viết tắt của Document Object Model. DOM là một chuẩn do tổ chức W3C(Worrld Wide Web Consortium) đặt ra. DOM định nghĩa các phương thức chuẩn cho việc truy cập tài liệu giống như XML, HTML : W3C DOM là một nền tảng và giao diện ngôn ngữ trung gian cho phép chương trình ngoặc các đoạn script truy cập động, sửa đổi dữ liệu, cấu trúc và định dạng cả một tài liệu. DOM bao gồm ba thành phần/mức khác nhau như sau: Core DOM : Mô hình chuẩn cho bất kì tài liệu có cấu trúc. XML DOM: Mô hình chuẩn cho tài liệu XML HTML DOM : Mô hình chuẩn cho tài liệu HTML. DOM định nghĩa các đối tượng và thuộc tính của tất cả phẩn tử trong tài liệu cùng với phương thức (giao diện) để truy cập đến chúng. 2.8.2 XML DOM : XML DOM là một mô hình đối tượng chuẩn cho XML, một giao diện lập trình chuẩn cho XML,một nền đồng thời là một ngôn ngữ độc lập. XML DOM định nghĩa một phương thức chuẩn cho việc truy cập và thao tác với tài liệu XML. Cấu trúc của DOM biểu diễn một tài liệu XML dưới dạng cấu trúc cây. Với DOM, việc thao tác với tài liệu XML được thực hiện dễ dàng. Ví dụ về cây XML DOM : 24 Hình 9. cây XML DOM XML DOM định nghĩa các đối tượng và thuộc tính của tất cả phần tử XML cùng phương thức để truy cập đến chúng. Nói cách khác XML DOM là một chuẩn cho việc truy xuất, sửa đổi, thêm vào hay loại bỏ các phần tử XML. Mọi thứ trong XML đều là node. Theo định nghĩa DOM ta có : - Một tài liệu hoàn chỉnh là một node tài liệu. - Mọi phẩn tử XML là một node phần tử. - Phần nội dung trong các phần tử XML là node nội dung - Mọi thuộc tính là một node thuộc tính. - Các chú thích là node chú thích. Một số phương thức thường sử dụng để thao tác với tài liệu XML: -Duyệt node : + ParentNode: lấy node cha của node hiện tại. + ChildNodes: lấy node con của node hiện tại. + FirstChild: lấy node con đầu tiên của node hiện tại + LastChild: lấy node con cuối cùng của node hiện tại + NextSibling : lấy node kế tiếp node hiện tại. + previousSibling: lấy node trước node hiện tại. - Thao tác trên các node : + getElementsByTagName(String tagname) : trả về một tập các node có thuộc tính tên là tagname. + getElementById(String Id) : Trả về một node có thuộc tính id là Id. + setAttribute(String name,String value): Đặt thuộc tính cho node với tên thuộc tính là name, giá trị là value. 25 + getAttribute(String name): lấy các giá trị của thuộc tính có tên là name. + removeChild: Xóa node con của node hiện tại. + removeAttribute: Xóa bỏ thuộc tính của node hiện tại. + replaceChild : Thay thế node con của node hiện tại bằng một node mới. + createNode: Dùng để tạo ra tất cả các loại node. + nodeCha.appendChild: thêm vào phần tử cuối cùng của danh sách các node con của nodeCha. 2.8.3 XMI: XMI (XML Metadata Interchange) là một chuẩn đưa ra bởi tổ chức Object Management Group (OMG) để trao đổi các siêu dữ liệu (Metadata) thông qua ngôn ngữ XML. Các siêu dữ liệu ở đây có thể là bất kỳ mô hình dữ liệu nào mà có thể biểu diễn được theo chuẩn Meta-Object Facility (MOF) cũng được tổ chức này đưa ra ban đầu để mô hình các đối tượng trong các biểu đồ UML. Tệp đặc tả mà chúng ta sử dụng là tuân theo chuẩn XMI 2.1 được xuất ra bởi công cụ Altova Umodel. Mỗi đặc tả tương ứng với một biểu đồ tuần tự UML 2.0. Do XMI được xây dựng dựa trên XML hay nói cách khác nó cũng chính là ngôn ngữ XML. Vì lý do này mà ta có thể sử dụng các cách truy xuất tệp XMI như với tệp XML. Ở đây, chúng ta dùng chuẩn DOM - là một chuẩn để biểu diễn và tương tác với các đối tượng trong các tài liệu XML – để từ các hàm API mà nó cung cấp, truy xuất thông tin về biểu đồ tuần tự từ tệp XMI. Trước khi đi vào cụ thể quá trình truy xuất thông tin như thế nào, chúng ta đề cập tới một số kiến thức cơ bản về cấu trúc của một tài liệu XMI như sau: Giống như XML và các ngôn ngữ đánh dấu khác, nó bao gồm hệ thống các cặp thẻ đánh dấu (tag) và phần nội dung nằm giữa mỗi cặp thẻ đó. Một thẻ bất kỳ thường được bắt đầu bằng ký tự “”. Một tài liệu XMI có cấu trúc dạng cây bao gồm các nút (Node) được gọi là phần tử (Element). Một phần tử thường bắt đầu bằng một thẻ và kết thúc bằng một thẻ tương ứng ví dụ như và hoặc nằm trong một thẻ rỗng chẳng hạn như . Giữa hai thẻ này có thể chứa nội dung dữ liệu hay chứa các Phần tử khác gọi là những nút con. Những nút con lại tiếp tục có thể có các nút con khác tạo nên một cây. Ngoài ra, mỗi phần tử còn có thể có các thuộc tính riêng đứng thành từng cặp tên=giá trị ở trong thẻ khởi đầu của phần tử đó. 2.9. Máy trạng thái FSM. 2.9.1. Tổng quan về các thành phần trong máy trạng thái FSM Máy hữu hạn trạng thái FSM bao gồm những thành phần cơ bản sau : 26 - State: Biểu diễn trạng thái của chương trình hay cụ thể là phương thức đang được kiểm tra và được biến đổi sau mỗi lời gọi hàm hợp lệ (các thông điệp tương ứng trong biểu đồ tuần tự). - Event: Tương ứng với các thông điệp trao đổi giữa các đường đời trong biểu đồ hay là các lời gọi hàm giữa các đối tượng trong chương trình thực thi. - Transition: Là cầu nối giữa các State với nhau được sử dụng tới khi có một Event làm thay đổi trạng thái. Chúng có chứa State nguồn và đích cộng thêm Event dẫn tới thay sự chuyển đổi trạng thái này. - FSMControl: Có thể coi lớp này chính là máy trạng thái mà chúng ta xây dựng được. Nó có chứa các State, các Transition và các Event. - FSMContext: Mỗi phương thức khi thực thi sẽ có các trạng thái khác nhau và quá trình biến đổi các trạng thái cũng khác nhau. Quá trình này được đặc trưng bởi một đối tượng FSMContext cho riêng phương thức đó. Nói cách khác, lớp FSMContext làm nhiệm vụ điều khiển máy trạng thái và kiểm tra tính hợp lệ của dãy các lời gọi hàm cho một phương thức cần kiểm thử. 2.9.2. Xây dựng máy hữu hạn trạng thái từ các thành phần của biểu đồ Gọi tập hợp các trạng thái (State) là S = {s0, s1, s2, … sn} Tập hợp các thông điệp (không tính thông điệp trả lời) là M = {m0, m1, m2, m3… mn} Đầu tiên ta tạo ra trạng thái s0, đặt nó là trạng thái khởi đầu. Với mỗi thông điệp thứ mi, ta tạo ra State si + 1 và tạo ra Transition (si, mi, si+1) nối từ State thứ i tới State thứ i + 1 có Event tương ứng với thông điệp thứ i. Lưu tên các State si và si + 1 vào trong thông điệp mi như là trạng thái nguồn và đích của thông điệp thứ i để sau này làm việc với các đoạn gộp nếu có. Đặt trạng thái cuối cùng tạo ra là trạng thái kết thúc. Nếu không có các đoạn gộp thì coi như công việc đã hoàn thành. Lưu lý là trạng thái đích của thông điệp mi sẽ là trạng thái nguồn của của thông điệp mi+1. Nếu có đoạn gộp Loop, trong Loop có thể có một hoặc nhiều thông điệp và khối Loop này có thể được thực thi chỉ một lần hoặc có thể lặp lại nhiều lần hoặc không thực hiện lần nào. Không mất tính tổng quát, ta đặt thông điệp đầu tiên và cuối cùng trong Loop theo thứ tự là mi và mn . Ở bước trên ta đã lưu lại trạng thái nguồn và đích của mỗi thông điệp ví dụ như thông điệp mi sẽ có nguồn là si và đích là si + 1 còn mn có nguồn là sn và đích là sn + 1 Để cho dễ hình dung ta sẽ ký hiệu một thông điệp giống như một transition (snguồn, m, 27 sđích) . Như thế, thông điệp đầu tiên ngay sau Loop là thông điệp mn+1 sẽ ký hiệu là (sn + 1, mn + 1, sn + 2) Đầu tiên ta xét khối Loop này được thực hiện ít nhất một lần. Vậy sau khi thông điệp cuối cùng mn trong loop thực thi xong thì chương trình đang ở trạng thái sn + 1 và có hai khả năng một là chạy tiếp thông điệp ngay sau loop hai là quay trở lại trạng thái trước khi thông điệp đầu tiên mi thực hiện. Trường hợp thứ nhất thì không có vấn đề gì, ta chỉ quan tâm tới trường hợp còn lại khi mà thông điệp đầu tiên trong Loop (mi) được gọi lại lần nữa. Vậy ta phải thêm vào máy trạng thái một Transition có nguồn là trạng thái hiện tại (sn + 1), Event tương ứng với mi và đích là đích của mi. Tức là ta phải bổ sung thêm Transition (sn + 1, mi, si + 1). Tiếp theo ta xét khối loop này không được thực hiện một lần nào mà thực hiện ngay thông điệp đầu tiên sau Loop. Lúc này, chương trình đang ở trạng thái si và tiếp theo thông điệp mn + 1 sẽ được gọi. Do vậy ta phải thêm vào một Transition có nguồn là si, Event tương ứng với mn + 1 và đích là trạng thái đích của mn + 1. Tức là ta phải bổ sung thêm Transition (si, mn + 1, sn + 2). Để dễ hình dung, ta lấy một ví dụ về việc một người truy vấn số dư tài khoản ở ngân hàng như sơ đồ sau: Hình 10. Ví dụ về một biểu đồ tuần tự cho việc truy vấn tài khoản ngân hàng. 28 Ở sơ đồ này, một User có thể tạo nhiều tài khoản và khi truy vấn số dư thì sẽ phải truy vấn ở tất cả các tài khoản của anh ta. Với các bước như trên, ta sẽ thu được một state machine như hình vẽ sau: Hình 11. Máy hữu hạn trạng thái ứng với ví dụ truy vấn tài khoản ngân hàng. Nếu biểu đồ có đoạn gộp Option, ta dễ thấy đây là trường hợp đặc biệt của Loop khi mà các thông điệp bên trong chỉ được thực hiện một lần hoặc không lần nào. Do vậy với các giả thiết như trên ta thấy cần thiết phải thêm vào Transition (si, mn + 1, sn + 2). Đối với đoạn gộp Break, các thông điệp trong đoạn gộp này hoặc là không được thực thi lần nào nếu được gọi thì sau khi thực thi xong các thông điệp trong đoạn gộp này, chương trình sẽ kết thúc ngay. Như thế, ta có thể hình dung đây là một trường hợp đặc biệt của đoạn gộp Option chỉ khác là nếu được sử dụng thì toàn bộ các thông điệp đứng sau nó sẽ bị bỏ qua. Trong trường hợp này, sau khi thực thi thông điệp cuối cùng trong đoạn gộp, chương trình đang ở trạng thái sn + 1. Tới đây, chương trình chấm dứt nên ta phải bỏ đi tất cả các Transition có nguồn là trạng thái này đồng thời đặt sn + 1 cũng là một trạng thái kết thúc. Trong trường hợp còn lại thì vẫn những giả thiết giống như với Option ta vẫn phải thêm vào Transition (si, mn + 1, sn + 2). Nếu có đoạn gộp Alternative, chúng ta giới hạn chỉ có hai Interaction Operand trong đoạn gộp này là một if then Operand và một else Operand. Bắt buộc một trong hai Operand này phải được thực thi và chỉ một trong hai mà thôi. Do đó ta phải bỏ đi một Transition xây dựng ở bước đầu tiên nối giữa trạng thái cuối và đầu của hai Operand này đi. Ngoài ra do tất cả các Operand trong đoạn gộp này có vai trò ngang hàng nhau nên trạng thái nguồn và đích của mỗi Operand cũng là giống nhau. Việc còn lại là ta phải xác định và thêm các Transition tương ứng với chúng. 29 Tuy nhiên sẽ có vấn đề nảy sinh nếu như các đoạn gộp này nằm ở cuối cùng của biểu đồ tuần tự. Với các đoạn gộp có một Interaction Operand như Loop, Opt, Break thì các thông điệp có thể không được gọi lần nào. Hoặc với Alternative thì chỉ có một trong các Interaction Operand được thực hiện. Như thế ta phải thêm các trạng thái kết thúc cho phù hợp với từng trường hợp đó. Cuối cùng, có một vấn đề là trong các bước trên có thể sẽ sinh ra một trạng thái mà có hai Transition với các Event có cùng tên thông điệp. Như vậy sẽ làm cho máy trạng thái của chúng ta trở thành một máy trạng thái không đơn định (Non-deterministic finite state machine). Do đó sau khi đã tạo ra máy trạng thái như trên, ta phải kiểm tra xem nó có đơn định hay không nếu không thì ta sẽ phải biến đổi nó trở thành đơn định. 30 CHƯƠNG 3 Aspect và lập trình hướng khía cạnh 3.1 Tổng quan về lập trình hướng khía cạnh. [4] Những năm gần nay, với sự phát triển của phương pháp lập trình hướng đối tượng (OOP) đã mang lại nhiều bước tiến mới cho lập trình nói chung và đưa ngành Công nghệ phần mềm lên một bước phát triển mới. Sự ra đời của hướng phát triển phần mềm hướng đối tượng (OOSD: Object-Oriented Software Development) đã mang lại những hiệu quả đáng kể. Tuy nhiên, nó vẫn bộc lộ những hạn chế, chẳng hạn trong các ứng dụng cần có sự đồng bộ hóa hay các ứng dụng có sự đan nhau phức tạp giữa các thành phần bên trong thì các ứng dụng tiếp cận theo hướng đối tượng tỏ ra không phù hợp. Bên cạnh đó, tính tĩnh trong cách tiếp cận hướng đối tượng không cho phép phần mềm thích ứng với những thay đổi mới đáp ứng yêu cầu người dùng. Trong bài báo này, chúng tôi trình bày một hướng tiếp cận mới trong việc phát triển phần mềm - hướng khía cạnh (AO: Aspect- Oriented). Hướng tiếp cận này còn khá mới mẽ (được đưa ra vào những năm cuối thập niên 90) nhưng hứa hẹn những lợi điểm giải quyết được những yêu cầu có tính đan xen phức tạp, đồng thời mang lại cho phần mềm khả năng thay đổi và bổ sung yêu cầu mới sau khi đã hoàn chỉnh hay thậm chí đã đưa vào sử dụng. Lập trình hướng khía cạnh được xây dựng trên các phương pháp lập trình hiện tại như lập trình hướng đối tượng, lập trình có cấu trúc, bổ sung thêm các khái niệm và cấu trúc để mô-đun hóa các chức năng cắt ngang hệ thống (crosscutting concern). Với AOP, các quan hệ cơ bản sử dụng các phương pháp cơ bản. Nếu sử dụng OOP, sẽ thực thi các quan hệ cơ bản dưới hình thức lớp (class). Các aspect trong hệ thống đóng gói các chức năng cắt ngang hệ thống lại với nhau. Chúng sẽ quy định cách các mô-đun khác nhau gắn kết với nhau để hình thành lên hệ thống cuối cùng. Nền tảng cơ bản của AOP khác với OOP là cách quản lý các chức năng cắt ngang hệ thống. Việc thực thi của từng chức năng cắt ngang AOP bỏ qua các hành vi được tích hợp vào nó. AOP có thể xem là một sự bổ sung cho OOP, cho phép chúng ta giải quyết các bài toán phức tạp tốt hơn và hiệu quả hơn. Vấn đề cốt lõi của AOP là cho phép chúng ta thực hiện các vấn đề riêng biệt một 31 cách linh hoạt và kết hợp chúng lại để tạo nên hệ thống sau cùng. AOP bổ sung cho kỹ thuật lập trình hướng đối tượng bằng việc hỗ trợ một dạng mô đun khác, cho phép kéo thể hiện chung của vấn đề đan nhau vào một khối. Khối này được gọi là ‘aspect’ (tạm dịch là ‘lát’ – hàm ý lát cắt đi qua nhiều lớp đối tượng), từ chữ ‘aspect’ này chúng ta có tên của phương pháp phát triển phần mềm mới: aspect-oriented programming. Nhờ mã được tách riêng, vấn đề đan nhau trở nên dễ kiểm soát hơn. Các aspect của hệ thống có thể thay đổi, thêm hoặc xóa lúc biên dịch và có thể tái sử dụng. Một dạng biên dịch đặc biệt có tên là Aspect Weaver thực hiện kết hợp các thành phần riêng lẻ lại thành hệ thống hợp nhất. AOP gồm ba bước phát triển: - Phân tích các yêu cầu để xác định vấn đề chung và vấn đề đan nhau. - Xây dựng thể hiện từng vấn đề riêng biệt. - Tổng hợp các thể hiện. Giống như các phương pháp lập trình khác, việc thực hiện AOP gồm hai phần: đặc tả ngôn ngữ mô tả cú pháp và cấu trúc ngôn ngữ; biên dịch kiểm tra sự đúng đắn của mã lệnh theo đặc tả ngôn ngữ và chuyển đổi sang dạng mã máy có thể thực thi. Đặc tả ngôn ngữ AOP: Xét ở mức cao, ngôn ngữ AOP gồm 2 thành phần : - Thể hiện vấn đề : Ánh xạ yêu cầu riêng lẻ ở dạng mã đề trình dịch có thể chuyển đổi sang dạng thực thi. Thể hiện vấn đề có dạng thủ tục cụ thể, bạn có thể dùng ngôn ngữ truyền thông như C/C++ hay java. - Đặc tả quy tắc đan kết : Xác định cách thức tổng hợp các vấn đề riêng lẻ. Muốn vậy, thẻ hiện cần sử dụng hoặc tạo ra một ngôn ngữ để xác định quy tắc đan kết có thể là sự mở rộng của ngôn ngữ thể hiện, hoặc một ngôn ngữ hoàn toàn khác. 3.2 Biên dịch AOP: Trình biên dịch AOP thực hiện theo trình tự hai bước như sau: - Kết hợp các hành vi riêng lẻ. - Chuyển đổi thông tin kết quả sang dạng mã thực thi. Việc biên dịch ứng dụng AOP có thể thực hiện theo nhiều cách, trong đó có cách dịch mã sang mã. Theo cách này, mã nguồn được tiền xử lý các aspect riêng lẻ để tạo ra mã đã được đan kết với nhau. Kế tiếp trình biên dịch AOP đưa mã đã được chuyển đổi này sang trình biên dịch ngôn ngữ cơ sở để tạo dạng mã thực thi cuối cùng. Ví dụ, theo cách này, các aspect riêng lẻ của ứng dụng AOP dùng ngôn ngữ java trước tiên sẽ được đan kết ở dạng mã nguồn java, kế tiếp trình biên dịch java sẽ chuyển mã nguồn này sang mã thực thi (Byte code). Tương tự, cũng có thể thực hiện đan kết ở giai đoạn mã thực thi, mã thực thi vẫn là một dạng mã nguồn,nếu như hệ thống thực thi chế độ nền- máy ảo 32 java- hỗ trợ aspect. Với cách này, đầu tiên máy ảo java sẽ nạp các quy tắc đan kết, rồi áp dụng các quy tắc này cho các lớp được nạp sau đó. Nói cách khác trình biên dịch thực hiện đan kết các aspect trong khi thực thi. AOP tổng hợp hệ thống đi từ các vấn đề đan nhau đến vấn đề chính, còn OOP đi theo hướng ngược lại. Tuy nhiên, OOP và AOP không phủ định nhau mà bổ sung cho nhau. AOP có thể dùng các kỹ thuật lập trình khác làm cơ sở, và vẫn giữ được những ưu điểm của hệ thống cơ sở. 3.3 LỢI ÍCH CỦA AOP : AOP là một kỹ thuật mới đầy triển vọng, hứa hẹn đem lại nhiều lợi ích cho việc phát triển phần mềm. Dưới đây là một số lợi ích cụ thể: • Mô đun hoá những vấn đề đan nhau: AOP xác định các vấn đề một cách tách biệt hạn chế tối thiểu việc nhập nhằng mã, cho phép mô đun hoá cả vấn đề liên quan đến nhiều lớp đối tượng. • Dễ dàng phát triển hệ thống: Việc thêm chức năng mới có thể thực hiện dễ dàng bằng cách tạo aspect mới mà không cần quan tâm đến vấn đề đan nhau. Khi thêm các mô đun mới vào hệ thống, các aspect hiện có sẽ đan kết với chúng và tạo nên sự phát triển chặt chẽ. • Cho phép để lại quyết định thiết kế tương lai: Một thiết kế tốt phải tính đến cả yêu cầu hiện tại và tương lai, việc xác định yêu cầu tương lai là một công việc khó khăn. Nếu bỏ sót những yêu cầu tương lai có thể bạn sẽ phải thay đổi hay thực hiện lại nhiều phần hệ thống. Với AOP, người thiết kế hệ thống có thể để lại các quyết định thiết kế cho những yêu cầu tương lai nhờ thực hiện theo các aspect riêng biệt. • Tái sử dụng mã tốt hơn: Các aspect là những mô đun riêng biệt, được kết hợp linh động – đây chính là yếu tố quan trọng để tái sử dụng mã. AOP cho phép tái sử dụng mã tốt hơn OOP. 3.4 AspectJ AspectJ là sự mở rộng theo mô hình AOP của ngôn ngữ Java, với sự mở rộng này mã chương trình viết bằng Java sẽ tương thích với chương trình viết bằng AspectJ. AspectJ gồm hai phần cơ bản là: 3.4.1. Đặc tả ngôn ngữ: Chỉ ra cách viết mã, với AspectJ các chức năng cơ bản của hệ thống sẽ được viết bằng Java còn các chức năng cắt ngang hệ thống sẽ được thực hiện bởi AspectJ. 33 3.4.2. Phần thực thi: Cung cấp các công cụ biên dịch, gỡ lỗi. AspectJ đã được plugin vào công cụ phát triển Eclipse ( và được đánh giá là sản phẩm tốt nhất hiện nay về AOP. 3.5. Một số khái niệm cơ bản trong AspectJ: 3.5.1. Join point Join point là bất kỳ điểm nào có thể xác định được khi thực hiện chương trình. Ví dụ: lời gọi hàm, khởi tạo đối tượng. Join point chính là vị trí mà các hành động thực thi cắt ngang được đan vào. Trong AspectJ mọi thứ đều xoay quanh join point. Một số loại join point chính trong AspectJ: o Join point tại hàm khởi tạo (constructor). o Join point tại các phương thức. o Join point tại các điểm truy cập thuộc tính. o Join point tại các điểm điều khiển ngoại lệ: Được điều khiển trong khối điều khiển ngoại lệ. 3.5.2. Pointcut Pointcut là một cấu trúc chương trình mà nó ch ọn các join point và ngữ cảnh tại các join point đó [7, 12]. Ví dụ một pointcut có thể chọn một join point là lời gọi đến một phương thức và lấy thông tin ngữ cảnh của phương thức đó như đối tượng chứa phương thức đó, các tham số của phương thức đó. Cú pháp của pointcut được khai báo như sau: [access specifier] pointcut pointcut-name([args]) : pointcut-definition; Ví dụ: public pointcut test(): call(void Line.setP1(Point)); 3.5.3. Advice Advice là mã thực hiện tại một join point mà được chọn bởi pointcut [7, 12]. Hay nói cách khác, nếu ta coi pointcut là khai báo tên phương thức, thì advice là phần thân của phương thức đó. Pointcut và advice sẽ hình thành nên các luật đan kết các quan hệ đan xen. Advice được chia ra làm ba loại sau: 1. Before: Được thực hiện trước join point. 2. After: Được thực hiện sau join point. 3. Around: Thực thi xung quanh join point. Giả sử ta có pointcut được khai báo như sau: 34 pointcut updateDisplay(): execution(void *.moveBy(int,int)) Ta có thể xây dựng các advice như sau: - Before advice thự hiện lưu vết before() : updateDisplay() { // logging } - After advice thực hiện cập nhật hình after() : updateDisplay() { display.update(this); } Ví dụ về around advice dùng để kiểm tra thuộc tính age của lớp Person trong phương thức setAge() có vi phạm điều khiện không (điều kiện: age > 0). void around(Person person, int age):setAge(person, age) { if(age > 0) Process(person,age); else System.out.println("Invalid Age!"); } 3.5.4. Aspect Aspect là phần tử trung tâm của AspectJ, giống như class trong Java. Aspect chứa mã thể hiện các luật đan kết cho các concern. Join point, pointcut, advice được kết hợp trong aspect . Aspect được khai báo theo mẫu sau: [access specification] aspect [extends class-or-aspect-name] [implements interface-list] [(Pointcut)] { ... aspect body } Ví dụ: public abstract aspect AbstractLogging { public abstract pointcut logPoints(); public abstract Loger getLogger(); before():logPoints() { 35 getLogger().log(Level.INFO, “Before” + thisJoinPoint); } } Tuy có gần giống các đặc điểm của class trong Java như: chứa thuộc tính, phương thức, có thể khai báo trừu tượng, có thể kế thừa… Tuy nhiên, Aspect có một số khác biệt cơ bản sau: 1. Aspect không thể khởi tạo trực tiếp. 2. Aspect không thể khởi tạo trực tiếp. 3. Aspect không thể kế thừa từ một aspect cụ thể (không phải trừu tượng) Aspect có thể được đánh dấu là có quyền bằng định danh privileged. Nhờ đó nó có thể truy cập đến các thành viên của lớp mà chúng cắt ngang. 3.6. Cơ chế họa động của AspectJ Aspect compiler là thành phần trung tâm của AspectJ, nó có nhiệm vụ kết hợp các file mã nguồn Java với các aspect lại với nhau để tạo ra chương trình cu ối cùng. Quá trình dệt có thể xảy ra ở các thời điểm khác nhau: compile – time, link – time và load – time. 3.6.1. Compile – time: Dệt trong thời gian biên dịch là cách đơn giản nhất. Mã nguồn Java và các aspect sẽ được kết hợp với nhau trước khi trình biên dịch dịch mã nguồn ra dạng byte code. Hay nói cách khác, trước khi biên dịch, các mã aspect sẽ được phân tích, chuyển đổi sang dạng mã Java và được chèn chính xác vào các vị trí đã định nghĩa sẵn trong mã nguồn Java chính của chương trình. Sau đó trình biên dịch sẽ dịch mã đã được dệt này ra dạng byte code. AspectJ 1.0.x sử dụng cách này để dệt chương trình. 3.6.2. Link – time: Quá trình dệt được thực hiện sau khi mã nguồn Java và các aspect được biên dịch ra dạng byte code. Một bộ xử lý tĩnh được sử dụng để đánh dấu các điểm gọi hàm trong mã được viết bằng java. Khi một hàm được thực thi. Runtime system sẽ phát hiện ra điểm nào cần gọi đến mã aspect để thực thi và khi đó mã aspect sẽ được gọi để đan vào chương trình chính. AspectJ 1.1.x sử dụng cách này để dệt chương trình. 3.6.3. Load – time: Quá trình dệt được thực hiện khi máy ảo Java tải một class vào để chạy. Theo cách này, mã nguồn Java và các aspect được biên dịch ra dạng byte code. Quá trình dệt diễn ra khi classloader nạp một class. AspectJ 1.5.x sử dụng cách này để dệt chương trình. 36 3.7. Sử dụng AOP Phát triển ứng dụng và phương pháp kiểm chứng dựa trên AOP Ngày nay, AOP được ứng dụng rộng rãi trong việc phát triển phần mềm. Phát triển hệ thống sử dụng AOP tương tự như phát triển hệ thống sử dụng các phương pháp khác, cũng g ồm các bước như: xác định concern, cài đặt concern và kết hợp chúng lại tạo thành hệ thống cuối cùng. Cộng đồng nghiên cứu AOP đề xuất ba bước thực hiện như sau: o Phân tích bài toán theo khía cạnh (Aspectual decomposition): Trong bước này chúng ta phân tích các yêu cầu nhằm xác định các chức năng chính của hệ thống và các chức năng cắt ngang hệ thống. Các phương thức cắt ngang hệ thống được tách ra khỏi các chức năng chính. o Xây dựng các chức năng (Concern Implementation): Cài đặt các chức năng một cách độc lập. o Kết hợp các khía cạnh lại để tạo nên hệ thống hoàn chỉnh (Aspectual Recompositon): Trong bước này chúng ta chỉ ra các quy luật kết hợp bằng cách tạo ra các aspect. Quá trình này gọi là quá trình dệt mã, sử dụng các thông tin trong aspect để cấu thành hệ thống cuối cùng. Hình 12. Các giai đoạn phát triển ứng dụng sử dụng AOP AOP đã được nghiên cứu và áp dụng vào rất nhiều ngôn ngữ lập trình như: Java, C, C#, PHP. Một số dự án được liệt kê trong bảng dưới đây: Bảng: Các dự án nghiên cứu AOP Tên dự án Địa chỉ AspectJ AspectWerkz Jboss AOP Sping AOP Aspect# 37 AspectC++ JAC Từ khả năng mô-đun hóa các quan hệ đan xen, các chức năng cắt ngang hệ thống; tách rời sự hoạt động của các mô-đun cũng như nhiều ưu điểm khác của AOP so với OOP mà hiện nay AOP đã trở thành sự lựa chọn phù hợp cho rất nhiều hệ thống phần mềm; đặc biệt là trong các chức năng lưu vết, bảo mật, xác thực của hệ thống phần mềm. Ngoài ra, do các mã aspect độc lập với mã nguồn chính của chương trình, có thể sửa đổi tùy theo ý muốn của lập trình viên, chính vì vậy AOP cònđư ợc ứng dụng rất lớn vào các loại kiểm chứng trong quá trình thiết kế phần mềm. Ví dụ như: kiểm chứng giao thức [5], kiểm tra việc gọi tuần tự các hàm trong chương trình… Nội dung chính của các phương pháp kiểm chứng dựa trên AOP là dựa vào những kiến khái niệm cơ bản của AOP như: join point, pointcut, advice, aspect để xây dựng nên các mô-đun kiểm chứng (các aspect) từ các chức năng cắt ngang hệ thống. Các aspect này sẽ được đan vào khung mã ngu ồn chương trình thông qua trình biên dịch AspectJ để thực hiện chức năng kiểm chứng. 38 CHƯƠNG 4. KIỂM CHỨNG CÁC GIAO THỨC BẰNG AOP 4.1 Biểu diễn giao thức. Một giao thức trên các đối tượng là việc gọi tuần tự các phương thức trong biểu đồ trình tự theo quy tắc được chỉ ra từ trước. Trong phạm vi khóa luận này, tôi chỉ diễn tả cách biểu diễn giao thức các giao thức cơ bản như ABn AnBm, (A*B)n. Trong đó, A,B là các giao thức còn m,n là số lần A,B được gọi trong chương trình. [5] đã kiểm chứng được các giao thức (AB)n, (A*B)n trên biểu đồ trình tự, xong chưa xử lý với precondition và postcondition. Trong phạm vi bài khóa luận tôi sẽ trình bày việc xử lý các giao thức được định nghĩa ở trên biểu đồ tuần tự, bên cạnh đó sử lý triệt để hơn các ràng buộc precondition và postcondition cho tất cả các giao thức. Trong bài khóa luận, tôi đề cập hai cách để biểu diễn giao thức: - Biểu diễn trên biểu đồ tuần tự: Bằng cách sử dụng hai vòng lặp, là một thành phần trong combindedFragment để miêu tả giao thức trên. Bằng cách mô tả này, ta có thể mô tả hầu hết tất cả các giao thức cơ bản. Trong ví dụ dưới đây, một vòng lặp thể hiện việc gọi m lần giao thức Message2 và một vòng lặp thể hiện gọi n lần giao thức Message4. Hình 13: Mô tả giao thức AnBm. 39 - Biểu diễn giao thức bằng biểu thức : Việc biểu diễn bằng biểu thức giúp cho việc thực hiện quá trình kiểm tra giao thức một cách nhanh chóng. Giao thức AnBm được biểu diễn bằng biểu thức [A]n[B]m. Ví dụ : [void message2()]m [void message4()]n như trong hình vẽ. Như trong định nghĩa trên thì phương thức void message2() sẽ được gọi m lần và phương thức void message4() sẽ được gọi n lần trong mã nguồn chương trình. 4.2. Tiền điều kiện và hậu điều kiện : 4.2.1. Tiền điều kiện : Tiền điều kiện biểu diễn những ràng buộc mà một thủ tục sẽ thực hiện một cách chính xác. Ví dụ như : - Put sẽ không được gọi nếu ngăn xếp đã đầy. - Remove item sẽ không được thực hiện trên một ngăn xếp khi ngăn xếp là rỗng. Tiền điều kiện vào có hiệu lực đến tất cả những lời gọi thủ tục, cả trong lớp và từ những lớp liên quan. Một hệ thống chính xác sẽ không bao giờ thực thi một lời gọi không thỏa mãn tiền điều kiện. 4.2.2. Hậu điều kiện : Hậu điều kiện biểu diễn những thuộc tính của trạng thái kết quả có được sau khi thực hiện thủ tục. Ví dụ như : - Sau thủ tục put, ngăn xếp sẽ không thể rỗng, phần tử trên cùng là phần tử mời được thêm vào và số lượng phần tử sẽ tăng lên 1. - Sau khi remove, ngăn xếp không thể đầy, số phần tử giảm đi 1. Sự có mặt của mệnh đề hậu điều kiện trong thủ tục bảo đảm kết quả của thủ tục sẽ thỏa mãn các thuộc tính(giả sử rằng thủ tục đã thỏa mãn tiền điều kiện để được gọi). 4.2.3 Biểu diễn tiền điều kiện và hậu điều kiện trong biểu đồ trình tự : Trong sequence diagram, để biểu diễn tiền điều kiện và hậu điều kiện tôi dùng một thành phần Comment để biểu diễn, Comment này sẽ chứa đựng thông tin về loại điều kiện (tiền điều kiện hoặc hậu điều kiện), điều kiện ràng buộc và thủ tục liên quan. Ví dụ như ở trong hình vẽ: - Comment thứ nhất có nội dung: pre:x=0:Message2 biểu diễn rằng kiểu của điều kiện là tiền điều kiện(pre), điều kiện ở đây là x=0 và phương thức liên quan đến là message2. - Comment thứ nhất có nội dung: pos:x>0:Message2 biểu diễn rằng kiểu của điều kiện là hậu điều kiện(pos), điều kiện ở đây là x>0 và phương thức liên quan đến là message2. 40 Hình 14. Mô tả tiền điều kiện và hậu điều kiện trong biểu đồ tuần tự 4.3 Kiểm chứng giao thức: Giả thiết cần kiểm chứng biểu đồ như trong hình 9.Việc kiểm chứng giao thức sẽ làm được những việc sau : - Kiểm tra xem mã nguồn chương trình có thực hiện tuần tự các phương thức như trong thiết kế của biểu đồ trình tự hay không: Từ thiết kế trên, khi ta viết mã chương trình thì chương trình phải tuân thủ các nguyên tắc trong bản thiết kế trên như: phương thức void message1() phải được gọi trước phương thức void message2(), phương thức void message2() gọi trước phương thức void message4(). Trước void message2() thì phải gọi void message1() trước… Để giải quyết vấn đề này bằng AOP ta đặt tên cho các trạng thái của chương trình khi chương trình thực thi bằng mã aspect. Ban đầu là trạng thái mở đầu(state_start), sau khi gọi 1 phương thức thì trạng thái sẽ bị thay đổi và được đánh dấu ở phương thức đó. Sau cùng là trạng thái kết thúc. - Kiểm chứng xem mã nguồn có đáp ứng các ràng buộc nếu có không : Là việc xác minh các tiền điều kiện và hậu điều kiện được miêu tả trong biểu đồ tuần tự là đã được xác minh hay chưa. Trong hình 9 mô tả ràng buộc với phương thức void message2(). Trước khi gọi void message2() thì kiểm tra x=0 có đúng hay không. Sau khi gọi void message2() thì x>0 có đúng hay không. Việc kiểm chứng các ràng buộc như vậy là không khó khăn chỉ có điều khi ràng buộc thể hiện một cách phức tạp thì chúng ta phải viết tách các điều kiện ra thành từng điều kiện nhỏ để có thể kiểm chứng. - Thông báo lỗi và chỉ ra lỗi trong đoạn cài đặt của chương trình: Khi có lỗi cài đặt được phát hiện thì mã kiểm chứng cho in ra dòng thông báo lỗi ở vị trí liên quan để người kiểm tra có thể dễ dàng sửa lại cho đúng. 41 Trường hợp Sequence diagram định nghĩa các combindedFragment thì việc kiểm chứng sẽ xác minh cả các combindedFragment mà có chứa điều kiện có được thực thi đúng không. Ví dụ như Loop là một combindedFragment, chương trình sẽ kiểm tra xem Loop có được thực hiện đúng không, về số vòng lặp, giao thức lặp…. Trong trường hợp không định nghĩa một CombindedFragment nào trong biểu đồ tuần tự thì việc kiểm chứng giao thức sẽ là kiểm chứng cài đặt trên sequence diagram. Tức là sẽ kiểm tra đơn thuần mã thực thi có thực hiện tuần tự như trong thiết kế biểu đồ tuần tự hay không. Duyệt các trạng thái : Các trạng thái được đặt vào Enumeration và được duyệt lần lượt để đặt các trạng thái vào sau khi phương thức được gọi. 42 Chương 5 Xây dựng công cụ sinh mã từ máy trạng thái 5.1 Tổng quan về xây dựng công cụ sinh mã từ máy trạng thái. Dựa vào cấu trúc của mã aspect tôi đã trình bày ở phần trên, tôi tiến hành phương pháp cài đặt mã aspect từ máy trạng thái. Mã aspect kiểm thử gồm các pointcut Việc cài đặt mã aspect bao gồm những việc sau đây : - Lấy các thành phần cần sử dụng trong tài liệu XMI . - Duyệt các trạng thái từ FSM. - Xác định số pointcut cần đặt vào. Số pointcut cần thiết bằng số lượng phương thức trong chương trình. - Xác định các hành vi mà hệ thống cần thực thi, những điều kiện ràng buộc cho các giao thức. Trước khi gọi phương thức thì trạng thái của hệ thống phải ra sao, có những điều kiện gì đi kèm, sau khi gọi phương thức thì điều kiện ra sao. Trong bước này ta xác định các mã kiểm chứng Advice. Sau khi xác định được các pointcut và advice, tổng hợp mã trên theo cấu trúc cú pháp của AspectJ. 5.1.1 Lấy các thành phần trong tài liệu XMI. Truy xuất các đường đời (Lifeline) Một đường đời trong tệp XMI được biểu diễn bởi phần tử có thẻ là trong đó có nhiều thuộc tính, ta chỉ quan tầm tới hai thuộc tính là id và name. Ta sẽ lưu hai thuộc tính này trong đó name thì ta chỉ quan tâm tới tên lớp (nhớ lại quy tắc tên một đường đời là objectName:ClassName ) tức là sau dấu hai chấm còn bỏ đi tên đối tượng. Vì trong một biểu đồ có thể có nhiều đường đời có cùng tên lớp nhưng khác nhau tên đối tượng do vậy, mỗi khi ta truy xuất thêm một đường đời mới ta lại phải kiểm tra xem trước đó đã có đường đời nào cùng lớp với nó hay chưa nếu có rồi thì tên đối tượng sẽ được đặt theo quy tắc sau: object1, object2, … Sau khi lưu hết các phần tử này, kết quả ta sẽ có được một dãy các đường đời đã vẽ trên biểu đồ. Truy xuất các thông điệp (Message) Một thông điệp được biểu diễn bởi phần tử có thẻ là trong đó ta quan tâm tới thuộc tính id, name, sendEvent, receiveEvent và messageSort. Tên của thuộc tính ta sẽ chỉ lấy lại tên của phương thức còn bỏ đi phần tham số. Từ hai thuộc tính sendEvent 43 và receiveEvent, thông qua phần tử mà có thuộc tính xmi:type= “uml:MessageOccurrenceSpecification ta sẽ tìm ra đường đời nguồn và đích của thông điệp đấy. Từ thuộc tính messageSort ta sẽ biết được thông điệp đấy thuộc loại nào trong bảy loại thông điệp đã nêu trên. Kết quả ta sẽ thu được một dãy các thông điệp. Tuy nhiên có một vấn đề là thứ tự các thông điệp sẽ là thông điệp nào được vẽ trước sẽ có thứ tự trước chứ không theo thứ tự thông điệp bên trên sẽ có thứ tự trước. Do vậy ta phải dựa vào tọa độ của các thông điệp để sắp xếp lại danh sách các thông điệp theo đúng trình tự của chúng trên biểu đồ. Thủ tục thực hiện là ta phải tìm trong phần tử có thẻ id của thông điệp sau đó tính tọa độ rồi sắp xếp lại theo thứ tự các tọa độ. Cuối cùng ta sẽ có một dãy các thông điệp theo đúng thứ tự mong muốn. Truy xuất các đoạn gộp( Combinded Fragment) Các đoạn gộp chỉ có một Interaction Operand sẽ được truy xuất như sau. Giả sử với đoạn gộp có Interaction Operator là loop thì trong tệp XMI sẽ nằm trong phần tử có thẻ mà có thuộc tính xmi:type=“uml:CombinedFragment” và thuộc tính interactionOperator= “loop”. Từ phần tử này ta sẽ lấy ra thuộc tính id và tìm trong phần diagrams xem phần tử nào có thuộc tính guiLink_Element trùng với id của loop. Qua đó, loop sẽ có các tọa độ về vị trí, chiều cao, chiều rộng. Rồi ta sẽ tìm xem các thông điệp nào có tọa độ nằm trong loop thì sẽ lưu lại, đánh dấu thông điệp đầu tiên và cuối cùng bên trong loop. Ta cần lưu thêm thông điệp ngay sau loop mà không phải là một thông điệp trả lời vì cần thiết cho việc xây dựng máy trạng thái sau này. 44 Những đoạn gộp chỉ có một Interaction Operand khác như Option và Break cũng làm tương tự như với loop chỉ khác là ở thuộc tính interactionOperator bây giờ sẽ là “opt” hay “break”. OPT Break Đối với những đoạn gộp có nhiều Interaction Operand như Alternative thì bước đầu tiên ta cũng làm tương tự như với bên trên với thuộc tính interactionOperator=“alt”. Sau đó khi lấy các tọa độ về kích thước thì ta phải lấy thêm tọa độ của các đường thẳng phân cách giữa các Interaction Operand. Từ đấy ta sẽ xác định các thông điệp bên trong đoạn 45 gộp thuộc về Operand nào, thông điệp nào là mở đầu và thông điệp nào là kết thúc Operand đó. Ngoài ra ta phải xác định thêm thông điệp đầu tiên không phải thông điệp trả lời sau đoạn gộp này. 5.1.2. Sinh mã Aspect từ biểu đồ tuần tự UML Chúng ta tiến hành kiểm thử aspect để giải quyết bài toán với đầu vào là biểu đồ tuần tự UML dưới dạng file XMI. Máy trạng thái đã đọc được nội dung từ file XMI và lấy ra được một số thông tin. Nhưng để sinh ra mã nguồn kiểm thử tôi phải định nghĩa thêm một số phương thức quan trọng tương tác với các trạng thái của FSM là getBeforeState, getCondition, getPreCon, getPos. getBeforeState lấy ra các trạng thái có thể tiến tới trạng thái cho trước,getPreCon lấy ra điều kiện trước, getPoss: lấy ra điều kiện sau, getCondition lấy ra điều kiện cụ thể là gì. Ngoài ra cần định nghĩa hàm chuanhoa để sửa lại hiển thị của các trạng thái và các phương thức cho đúng. Đặc biệt do trong biểu đồ tuần từ không cho phép đặc tả tiền điều kiện và hậu điều kiện một cách tường minh, vì vậy để giải quyết vấn đề này tôi sử dụng một thành phần khác trong biểu đồ tuần từ là Comment, nội dung trong thành phần này là để tôi định nghĩa các ràng buộc về tiền điều kiện và hậu điều kiện, lấy ra và sử lý các tiền điều kiện và hậu điều kiện là từ nội dung của thành phần comment này. File kiểm chứng Aspect ta sẽ dùng : - Before advice : Kiểm tra xem giá trị của biến state hiện thời có bằng giá trị của các trạng thái trước nó có thể chuyển trạng thái khi gọi phương thức hiện thời hay không. Mặt khác, kiểm tra các ràng buộc tiền điều kiện của phương thức. Nếu vi phạm thì sẽ báo lỗi. 46 - After advice: Đặt lại giá trị mới cho biến state sau khi thay đổi trạng thái được gọi. Thực hiện các phép kiểm tra hậu điều kiện, kiểm tra tính đúng đắn của giao thức. 5.1.3. Thuật toán sinh mã aspect được cài đặt như sau : - Duyệt lần lượt tất cả các event (phương thức) trong FSM. Thiết lập trạng thái cho lần lượt mỗi khi một phương thức được gọi: + Sau khi gọi một phương thức, đổi trạng thái cho nó trong after advice. + Dùng before advice kiểm tra state trước nó có phải là các trạng thái có thể chuyển đến trạng thái hiện thời không. Bằng cách lấy tất cả các trạng thái có thể gọi đến phương thức hiện tại và so sánh với state hiện tại. Nếu sai thì báo lỗi. -Lấy ra các precondition và pos-condition để kiểm chứng. Nếu sai với điều kiện trong precondition và pos-condition thì báo lỗi. Trước tiên ta phải lấy ra ràng buộc trong tài liệu XMI, và được lấy từ thành phần Comment. Commnent được biểu diễn trong tài liệu XMI là tag mà có các thuộc tính là xmi:type = “uml:Comment” và thuộc tính body = “” chính là nội dung chúng ta cần quan tâm. Nội dung trong thuộc tính body chúng ta cần định nghĩa chính xác theo khuân mẫu : body = “pre/pos: condition:Message”. Trong đó : - pre/ pos : xác định kiểu của điều kiện là tiền điều kiện hay là hậu điều kiện. - Conditon : biểu diễn ràng buộc cụ thể là gì. - Message: biểu diễn tên của thông điệp liên quan. Như trong hình trên, thuộc tính body của ownComment là :pre:x=0:message2 có nghĩa: kiểu của điều kiện là tiền điều kiện(pre),điều kiện ràng buộc là x =0 và là tiền điều kiện trước khi gọi Message2. Pos:x>0:message2 có nghĩa: kiểu của điều kiện là hậu điều kiện(pos), điều kiện ràng buộc là x>0 và là hậu điều kiện sau khi gọi message2. - Vòng lặp (Loop) biểu diễn các giao thức cơ bản, ta cần sử lý vòng lặp nếu có. Các phương thức được đặt trong vòng lặp để thể hiện chúng được lặp bao nhiều lần. Đây là CombindedFragment chủ yếu để tạo ra các giao thức phức tạp. Việc kiểm chứng này ở mức đơn giản nhất là kiểm chứng tính đúng đắn ở một vòng lặp. Tức là kiểm tra xem trong vòng lặp đó số lần lặp, các phương thức lặp với tuần tự đó là phải chính xác. 5.2. Sinh mã kiểm chứng giao thức AnBm 47 Việc kiểm chứng giao thức AnBm có các vấn đề sau : Thứ nhất Kiểm chứng việc thực hiện m lần gọi phương thức A và n lần phương thức B. Việc này được thực hiện dễ dàng bằng cách đặt 2 biến nguyên counta và countb, biến counta được tăng l sau khi gọi xong phương thức A, countb được tăng thêm 1 sau khi gọi phương thức B. Việc kiểm tra gọi n lần phương thức B chỉ được thực hiện khi đã gọi n lần phương thức A. after(): pc_A(){ counta=0; } after(): pc_B(){ countb=0; } Thứ 2: Kiểm chứng việc gọi liên tiếp m lần phương thức A và liên tiếp n lần phương thức B. Việc này được thực hiện như sau, đầu tiên, gọi 2 biến checka và checkb, khởi tạo giá trị ban đầu cho 2 biến này = 0. Hai biến này được tăng lên 1 khi một phương thức bất kì được gọi. pointcut pc() : call(* *.*(*)); before() : pc() { checka++; checkb++; } checka bằng 0 khi phương thức A được gọi, checkb bằng 0 khi phương thức B được gọi. after(): pc_A(){ checka=0; } after(): pc_B(){ checkb=0; } Bằng cách này ta biết được sự liên tiếp khi gọi các phương thức A và B. Chỉ có ở vị trí khi bắt đầu gọi đến phương thức A, khi đó checka là khác 0, nhưng counta chắc chắn là bằng 0. Vì vậy nên khi counta bằng 0 và checka khác 0 thì vẫn đúng. Ngược lại couta khác 0 và checka khác 0 là sai. if(checka !=0 && counta !=0){ 48 System.out.println("Error"); result = false; } Biến boolean result được khởi tạo là true, biến này được gán bằng false khi các điều kiện không được thỏa mãn. Khi kết thúc chương trình, nếu biến result = true thì giao thức đã kiểm tra là đúng, ngược lại nếu result = false thì giao thức đã kiểm chứng sai. Kiểm chứng tính đúng đắn trong biểu đồ tuần tự(Sequence diagram) Việc kiểm chứng biểu đồ tuần tự bao gồm : - Kiểm chứng việc đặc tả trong biểu đồ tuần tự có đúng với khi cài đặt không. - Kiểm tra tính đúng đắn khi cài đặt, có cả tiền điều kiện và hậu điều kiện. Việc kiểm chứng đặc tả trong biểu đồ tuần tự có đúng với đặc tả không là việc kiểm chứng việc gọi lần lượt các phương thức sao cho đúng đắn. Tuân thủ quy tắc trong khi cài đặt. Việc kiểm chứng này được thực hiện bằng thuật toán sau đây : - Đặt các biến state nguyên là biến trạng thái. Trong biểu đồ có n phương thức thì sẽ có n+1 trạng thái bao gồm trạng thái đầu và trạng thái kết thúc. - Sau mỗi lời gọi phương thức thì đặt cho nó ở một trạng thái. - Hàm getBeforeState(Event e) sẽ lấy ra tất cả các trạng thái mà có thể gọi tới phương thức e. - Kiểm tra các tiền điều kiện ràng buộc và hậu điều kiện ràng buộc đối với mỗi phương thức. - lấy và so sánh các trạng thái của từng trạng thái trong biểu đồ xem có đúng với đúng với trạng thái thực của nó không. Dùng mã aspect để kiểm chứng. 49 Chương 6 Kết luận 6.1 Kết luận về khóa luận Trong quá trình thực hiện đề tài này, tôi đã tìm hiểu những kiến thức cơ bản về kiểm chứng phần mềm giúp cho việc phát hiện và sửa lỗi phần mềm nhằm đảm bảo chất lượng của phần mềm, các kiến thức cơ bản về UML, Sequence Diagram về chi tiết các thành phần, cách sử dụng và biểu diễn chúng. Tôi đã tìm hiểu các kiến thức về AOP và áp dụng các kiến thức này để xây dựng phương pháp kiểm thử dựa vào những đặc tính ưu việt của AOP. Các mô đun aspect chứa mã kiểm chứng có thể cắt ngang can thiệp vào một thành phần của hệ thống và tách biệt hoàn toàn với chương trình ban đầu. Đây là một khả năng rất hay và mạnh mẽ của AOP. Quá trình kiểm chứng phần mềm mà tôi đề cập trong khóa luận được tóm tắt lại như sau: Từ biểu đồ trình tự UML đặc tả giao thức, xuất biểu đồ này dưới dạng tài liệu XMI, tiếp đó phân tích tài liệu XMI, máy trạng thái tương tác vơi tài liệu XMI cho ra được biểu đồ trạng thái. Với việc phát triển thêm một số thành phần cho máy trạng thái và xây dựng các mô đun cho việc sinh mã aspect kiểm chứng cho các giao thức cơ bản, tôi đã xây dựng được công cụ sinh mã kiểm chứng tự động bằng aspect từ tài liệu XMI mô tả giao thức. Với chương trình này tôi có thể kiểm chứng được hầu hết các giao thức định nghĩa được trên biểu đồ tuần tự. Khi thực hiện khóa luận tôi cũng gặp phải những khó khăn khi xây dựng công cụ sinh mã kiểm chứng tự động. Việc biểu diễn ràng buộc trong biểu đồ trình tự là rất khó,bằng phương pháp của tôi có thể giải quyết triệt để các ràng buộc đơn giản. Nhưng khi ràng buộc là tổ hợp của rất nhiều ràng buộc nhỏ lẻ bắt buộc phải tách chúng ra thành từng ràng buộc nhỏ lẻ để có thể kiểm chứng. Và một vấn đề nữa là chương trình phụ thuộc hoàn toàn vào tài liệu XMI, mà XMI lại là tự động được sinh ra và phụ thuộc hoàn toàn vào công cụ. Vì vậy, các thành phần của biểu đồ UML được biểu diễn rất khác nhau với mỗi công cụ sinh tài liệu XMI khác nhau. Trong bài khóa luận tôi sử dụng chương trình Altova UModel để sinh tài liệu XMI. Đây là một công cụ khá mạnh mẽ và biểu diễn được tương đối đầy đủ các thành phần biểu đồ UML. 50 6.2 Hướng phát triển trong tương lai : Từ những vẫn đề tồn tại của khóa luận, trong tương tai tôi sẽ tiếp tục nghiên cứu nhằm hoàn thiện công cụ sinh mã tự động.Hướng phát triển gần nhất là việc mô tả thêm các biểu thức chính quy để biểu diễn các giao thức phục vụ kiểm chứng được nhanh. Xa hơn, tôi sẽ nghiên cứu phương pháp để đồng nhất giữa giao thức biểu diễn bằng biểu đồ tuần tự với việc biểu diễn giao thức bằng biểu thức chính quy. Tức là từ biểu đồ tuần tự có thể suy ra biểu thức chính quy mô tả giao thức và ngược lại. Nghiên cứu phương pháp kiểm chứng biểu đồ tuần tự mà phù hợp với đặc tả chung của tài liệu XMI để chương trình không phụ thuộc vào tài liệu XMI do công cụ tạo ra. 51 TÀI LIỆU THAM KHẢO [1] UML . [2] [3] UML Specifications [4] Anh-Hoang Truong, Phuc Dinh Nguyen, Tuyen Luu, Checking implementations of UML 2.0 sequence diagrams”. [5] Vũ Sỹ Vương, Kiểm chứng đặt tả UML cho tác tử phần mềm. [6] XMI Specifications [7] Farida Mostefaoui DIRO,Julie Vachon , University of Monreal Quebec, Canada Verification of Aspect –UML models using alloy, 2007.