Thông tin tài liệu
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Bùi Duy Hải KIỂM CHỨNG MÔ HÌNH ASPECT-UML BẰNG ALLOY 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 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Bùi Duy Hải KIỂM CHỨNG MÔ HÌNH ASPECT-UML BẰNG ALLOY 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: Phạm Thị Kim Dung HÀ NỘI - 2010 LỜI CÁM ƠN Đầu tiên tôi xin gửi lời cảm ơn sâu sắc tới cô giáo Ths.Phạm Thị Kim Dung, bộ môn công nghệ phần mềm, khoa công nghệ thông tin, trường đại học công nghệ, đại học Quốc Gia Hà Nội – người đã định hướng đề tài và tận tình hướng dẫn chỉ bảo tôi trong suốt quá trình thực hiện khóa luận tốt nghiệp này. Tôi cũng xin trân trọng cảm ơn quý thầy cô trong Khoa Công nghệ thông tin trường Đại học Công nghệ, Đai học Quốc Gia Hà Nội đã tận tình giảng dạy, truyền đạt những kiến thức quý báu trong suốt bốn năm học làm nền tảng cho tôi thực hiện khóa luận tốt nghiệp này. Con xin cảm ơn cha mẹ và gia đình đã sinh ra và nuôi dạy con khôn lớn, luôn bên cạnh động viên và ủng hộ con trên con đường mà con yêu thích và lựa chọn. Cám ơn các bạn sinh viên Khoa công nghệ thông tin khóa 2006-2010. Các bạn đã giúp đỡ và ủng hộ tôi rất nhiều cũng như đóng góp nhiều ý kiến quý báu, qua đó, giúp tôi hoàn thiện khóa luận tốt hơn. Mặc dù đã rất nỗ lực, cố gắng nhưng chắc hẳn khóa luận của tôi vẫn còn nhiều thiếu sót. Tôi rất mong nhận được nhiều những ý kiến đánh giá quý, phê bình của quý thầy cô, của anh chị và các bạn. Một lần nữa tôi xin chân thành cảm ơn! Hà Nội, tháng 5 năm 2010 Bùi Duy Hải Mục Lục !"#$%&' ()*+,-./&'0 -)1203"4 ,-.5637873&.%%394 .:"2;0< =">%.4 ?7@">%+,-.A B<"&8CD=E. F,G /DH"IJ5K.9B B.'0 -)#L%"C51203"K 337M 8 %++9N BM0<0&'0 -)#L%"CN B<"#<*+ 81203" BBO=+"P+,-1203"Q.B B()*1&&8B B1&&8RST&/-UB BVL"">%,G%&&8B BB !"+H" -1&&8S BSO%D<8 8%&&8S B"+,-1203"Q. 81&&8W B,-1203".W B,-X,BY BB"+,-1203".DZ1&&8B BSO=+"P+,-1203".2;7@1&&8B4 SSO[&'SY DANH MỤC HÌNH VẼ \ 3 DANH MỤC BẢNG BIỂU DANH MỤC NHỨNG TỪ VIẾT TẮT OOP Object Oriented Programming UML Unifined Model Language OCL Object Contraint Language AOP Aspect Oriented Programming 1 Chương 1 : MỞ ĐẦU 1.1 Đặt vấn đề Ngày nay, công nghệ thông tin ngày càng phát triển và được ứng dụng vào tất cả các lĩnh vực của cuộc sống xã hội. Nó tạo ra một diện mạo mới cho xã hội và nhờ đó nền văn minh nhân loại được nâng lên một tầm cao mới. Công nghệ phần mềm là một phần không thể tách rời trong công nghệ thông tin. Hiện nay ngành công nghệ phần mềm trên thế giới đã và đang phát triển như vũ bão. Những tiến bộ của khoa học kĩ thuật phần cứng đã tạo điều kiện thuận lợi cho công nghệ phần mềm ngày càng phát triển không ngừng. Phần mềm được coi là sản phẩm chính của công nghệ phần mềm.Quá trình phát triển phần mềm gồm nhiều giai đoạn: thu thập yêu cầu, phân tích, thiết kế,xây dựng, kiểm chứng , triển khai và bảo trì. Trong đó việc kiểm chứng phần mềm là hết sức quan trọng để đảm bảo chất lượng của một phần mềm. Kiểm chứng mô hình UML cũng đóng góp vào việc kiểm chứng phần mềm.Việc kiểm chứng mô hình UML + OCL đã được giải quyết [2]. Vấn đề đặt ra bây giờ là kiểm chứng mô hình Aspect-UML(là một mô hình UML đơn giản được mở rộng với việc sử dụng Aspect). Nhờ Aspect và các ràng buộc của nó mà mô hình Aspect UML được cung cấp thêm thông tin. Mô hình Aspect UML có thể được kiểm chứng từ các xung đột tương tác Aspect, để làm tự động công việc kiểm chứng mô hình Aspect UML là chuyển đổi mô hình Aspect UML sang ngôn ngữ đặc tả Alloy. Alloy cung cấp một ngôn ngữ đặc tả mô hình đơn giản dựa trên logic cũng như công cụ mô phỏng[]. Trong phạm vi khóa luận này tôi sẽ chỉ ra quy tắc chuyển đổi một mô hình Aspect UML sang ngôn ngữ Alloy. 1.2 Cấu trúc khóa luận Chương 1: Phần mở đầu. Chương 2: Giới thiệu về mô hình UML và lập trình hướng Aspect. Chương 3: Kiểm chứng mô hình Aspect- UML bằng Alloy Chương 4: Kết luận và hướng nghiên cứu trong tương lai. 2 Chương 2: Giới thiệu về mô hình UML và lập trình hướng Aspect 2.1 Mô hình UML (Unifined Model Language) 2.1.1 Lịch sử phát triển của UML Theo [1] những năm đầu của thập kỷ 90 có rất nhiều phương pháp phân tích, thiết kế hệ thống hướng đối tượng và cùng với chúng là các ký hiệu riêng cho từng phương pháp. Số lượng các phương pháp trong khoảng từ 10 đã lên đến gần 50 trong những năm từ 1989 đến 1994. Ba phương pháp phổ biến nhất là OMT (Object Modeling Technique) [James Rumbaugh], Booch91 [Grady Booch] và OOSE (Object-Oriented Software Enginering) [Ivar Jacobson]. Mỗi phương pháp đều có những điểm mạnh và yếu. Như OMT mạnh trong phân tích và yếu ở khâu thiết kế, Booch91 thì mạnh ở thiết kế và yếu ở phân tích. OOSE mạnh ở phân tích các ứng xử, đáp ứng của hệ thống mà yếu trong các khâu khác. Do các phương pháp chưa hoàn thiện nên người dùng rất phân vân trong việc chọn ra một phương pháp phù hợp nhất để giải quyết bài toán của họ. Hơn nữa, việc các ký hiệu khác nhau của các phương pháp đã gây ra những sự mập mờ, nhầm lẫn khi mà một ký hiệu có thể mang những ý nghĩa khác nhau trong mỗi phương pháp. Ví dụ như một hình tròn được tô đen biểu hiện một multiplicity trong OMT lại là một aggregation trong Booch). Thời kỳ này còn được biết đến với tên gọi là cuộc chiến giữa các phương pháp. Khoảng đầu năm 94, Booch đã cải tiến phương pháp của mình trong đó có ứng dụng những ưu điểm của các phương pháp của Rumbaugh và Jacobson. Tương tự Rumbaugh cũng cho đăng một loạt các bài báo được biết đến với tên gọi phương pháp OMT-2 cũng sử dụng nhiều ưu điểm của phương pháp của Booch. Các phương pháp đã bắt đầu hợp nhất, nhưng các kí hiệu sử dụng ở các phương pháp vẫn còn nhiều điểm khác biệt. Cuộc chiến này chỉ kết thúc khi có sự ra đời của UML – một ngôn ngữ mô hình hóa hợp nhất. Tại sao lại là hợp nhất? Đó là do có sự hợp nhất các cách kí hiệu của Booch, OMT và Objectory cũng như các ý tưởng tốt nhất của một số phương pháp khác như hình vẽ sau: Hình 1:Hợp nhất các phương pháp thiết kế bằng UML Bằng cách hợp nhất các kí hiệu sử dụng trong khi phân tích, thiết kế của các phương pháp đó, UML cung cấp một nền tảng chuẩn trong việc phân tích thiết kế. Có nghĩa là các nhà phát triển vẫn có thể tiến hành theo phương pháp mà họ đang sử dụng hoặc là có thể tiến hành theo một phương pháp tổng hợp hơn( do thêm vào những bước ưu điểm của từng phương pháp). Nhưng điều quan trọng là các ký hiệu giờ đây đã thống nhất và mỗi ký hiệu chuẩn của tổ chức OMG (Object Management Group) vào tháng 7-1997. 2.1.2 Ứng dụng của mô hình UML UML là một ngôn ngữ dùng để: • Trực quan hóa • Cụ thể hóa • Sinh mã ở dạng nguyên mẫu • Lập và cung cấp tài liệu UML là một ngôn ngữ bao gồm một bảng từ vựng và các quy tắc để kết hợp các từ vựng đó phục vụ cho mục đích giao tiếp. Một ngôn ngữ dùng cho việc lập mô hình là ngôn ngữ mà bảng từ vựng( các ký hiệu) và các quy tắc của nó tập trung vào việc thể hiện về mặt khái niệm cũng như vật lý của một hệ thống. Mô hình hóa mang lại sự hiểu biết về một hệ thống. Một mô hình không thể giúp chúng ta hiểu rõ một hệ thống, thường là phải xây dựng một số mô hình xét từ những góc độ khác nhau. Các mô hình này có quan hệ với nhau. UML sẽ cho ta biết cách tạo ra và đọc hiểu được một mô hình đươc cấu trúc tốt, nhưng nó không cho ta biết những mô hình nào nên tạo ra và khi nào tạo ra chúng. Đó là nhiệm vụ của quy trình phát triển phần mềm. 2.1.2.1 UML là ngôn ngữ dùng để trực quan hóa Đối với nhiều lập trình viên, không có khoảng cách nào giữa ý tưởng để giải quyết một vấn đề và việc thể hiện điều đó thông qua các đoạn mã. Họ nghĩ ra và họ viết mã. Trên thực tế, điều này gặp một số vấn đề. Thứ nhất, việc trao đổi về các ý tưởng giữa những người lập trình sẽ gặp khó khăn, trừ khi tất cả đều nói cùng một ngôn ngữ. Thậm chí ngay cả khi không gặp trở ngại về ngôn ngữ thì đối với từng công ty, từng nhóm cũng có những “ngôn ngữ” riêng của họ. Điều này gây trở ngại cho một người mới vào để có thể hiểu được những việc đang được tiến hành. Hơn nữa, trong lĩnh vực phần mềm, nhiều khi khó có thể hiểu được nếu chỉ xem xét các đoạn mã lệnh. Ví dụ như sự phân cấp của các lớp, ta có thể phải duyệt rất nhiều đoạn lệnh để hiểu được sự phân cấp của các lớp. Và nếu như người lập trình không mô tả các ý tưởng mà anh ta đã xây dựng thành mã lệnh thì nhiều khi cách tốt nhất là xây dựng lại trong trường hợp một người khác đảm nhận tiếp nhiệm vụ khi anh ta rời khỏi nhóm Đối với nhiều lập trình viên, không có khoảng cách nào giữa ý tưởng để giải quyết một vấn đề và việc thể hiện điều đó thông qua các đoạn mã. Họ nghĩ ra và họ viết mã. Trên thực tế, điều này gặp một số vấn đề. Thứ nhất, việc trao đổi về các ý tưởng giữa những người lập trình sẽ gặp khó khăn, trừ khi tất cả đều nói cùng một ngôn ngữ. Thậm chí ngay cả khi không gặp trở ngại về ngôn ngữ thì đối với từng công ty, từng nhóm cũng có những “ngôn ngữ” riêng của họ. Điều này gây trở ngại cho một người mới vào để có thể hiểu được những việc đang được tiến hành. Hơn nữa, trong lĩnh vực phần mềm, nhiều khi khó có thể hiểu được nếu chỉ xem xét các đoạn mã lệnh. Ví dụ như sự phân cấp của các lớp, ta có thể phải duyệt rất nhiều đoạn lệnh để hiểu được sự phân cấp của các lớp. Và nếu như người lập trình không mô tả các ý tưởng mà anh ta đã xây dựng thành mã lệnh thì nhiều khi cách tốt nhất là xây dựng lại trong trường hợp một người khác đảm nhận tiếp nhiệm vụ khi anh ta rời khỏi nhóm. Xây dựng mô hình sử dụng ngôn ngữ UML đã giải quyết được các khó khăn trên.Khi trở thành một chuẩn trong việc lập mô hình, mỗi kí hiệu mang một ý nghĩa rõ rang và duy nhất, một nhà phát triển có thể đọc được mô hình xây dựng bằng UML do một người khác viết.Những cấu trúc mà việc nắm bắt thông qua đọc mã lệnh là khó khăn nay đã được thực hiện trực quan.Một mô hình rõ ràng, sáng sủa làm tăng khả năng giao tiếp, trao đổi giữa các nhà phát triển. 2.1.2.2 UML là ngôn ngữ để chi tiết hóa Có nghĩa là xây dựng các mô hình một các tỉ mỉ, rõ ràng, đầy đủ ở các mức độ chi tiết khác nhau. Đặc biệt là UML thực hiện việc chi tiết hoá tất cả các quyết định quan trọng trong phân tích, thiết kế và thực thi một hệ thống phần mềm. [...]... cho mô hình kiểm tra ở chỗ nó cho phép định nghĩa các mô hình vô hạn Các đặc tả Alloy có thể bị kiểm tra bằng cách sử dụng Alloy Analyzer Alloy Analyzer được thiết kế để thực hiện kiểm tra phạm vi hữu hạn, ngay cả trên các mô hình vô hạn 3.1.2 Tính chất của ngôn ngữ alloy • Đối các mô hình hữu hạn alloy có thể hữu hạn phạm vi kiểm tra: phân tích được đầy đủ các đối tượng đặc tả • Alloy cho phép kiểm. .. quyết ngữ nghĩa gây ra xung đột giữa các aspect Mô hình Aspect-UML có thể được kiểm tra từ các xung đột tương tác aspect Một cách để tự động quá trình kiểm chứng là chuyển đổi mô hình Aspect- UML sang ngôn ngữ đặc tả Alloy Alloy cung cấp một ngôn ngữ đặc tả mô hình đơn giản dựa trên logic đầu tiên như phân tích mô hình và công cụ mô phỏng[] Một mô hình Alloy được soạn thảo từ một tập hợp các signature... quan hệ giữa chúng Mô hình này có thể được thêm các rang buộc bởi predicates và assertions Một mô hình là trừu tượng cái mà thực sự xác định một tập hợp có thể vô hạn của một mô hình hữu hạn Alloy thực thi đặc tả mô hình bằng cách tìm kiếm mô hình cá biệt đáp ứng một số đặc điểm của đặc tả Một mô hình có thể được kiểm tra là có giá trị hay là thỏa mãn bên trong các ràng buộc một mô hình cá biệt Thật... 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 Chương 3: Kiểm chứng mô hình Aspect-UML 3.1 Giới thiệu về Alloy 3.1.1 Alloy[ 4] là gì? Trong công nghệ phần mềm, Alloy là một ngôn ngữ đặc tả mô hình hóa cho những biểu thị sự ràng buộc của những cấu trúc phực tạp trong công nghệ phần mềm Alloy là một công cụ mô hình hóa... được gọi (không như fact) 3.2 Đặc tả mô hình Aspect-UML trong Alloy 3.2.1 Mô hình Aspect UML Vì việc đặc tả mô hình UML+ OCL đã được nghiên cứu và hoàn thành do vậy chúng ta chỉ xem xét đến mô hình Aspect- UML Phương pháp đặc tả trong bài luận này sẽ xem xét cách phân tích các tương tác aspect trong mô hình A-O được viết trong Aspect UML [5,6] Aspect-UML là một mô hình đơn giản mở rộng của UML và sử... đặc tả • Alloy cho phép kiểm tra vô hạn các mô hình vì kiểm tra hữu hạn không nhận được phản ánh đúng từ mô hình cần đặc tả • Alloy có khả năng đặt quan hệ logic giữa các đối tượng trong mô hình • Tự động phân tích và kiểm tra tính đứng đắn của các mô hình • Về cấu trúc dữ liệu: o Xử lý vụng về o Chức năng đệ quy khó diễn tả 3.1.3 Cấu trúc một chương trình Alloy module … sig A{…} fact F {…} assert a... Shape - Lớp Line: mô tả 1 đoạn thẳng, chứa 2 thuộc tính là điểm đầu và điểm cuối của đoạn thẳng và được kế thừa từ lớp Shape Dưới đây là sơ đồ lớp của bài toán Figure 1 Hình 4: Sơ đồ lớp của bài toán vẽ hình Mô hình hóa thành các lớp như vậy ta thấy bài toán đã tương đối ổn Bây giờ vấn đề đặt ra là mỗi khi ta thay đổi tọa độ của một điểm hay co giãn hình, di chuyển hình ta lại phải vẽ lại hình ở vị trí... biệt Thật vậy, các phân tích Alloy giới hạn việc tìm kiếm các mô hình cá biệt cái mà kích cỡ(về các đối tượng) là thấp hơn cho một số ràng buộc cố đinh bời người sử dụng Alloy khẳng định hướng tiếp cận đặc tả của nó bằng việc đề xuất giả thuyết phạm vi nhỏ mà theo đó các counterexample phế bỏ một mô hình có khuynh hướng xảy ra trong các ví dụ mô hình nhỏ Để kiểm chứng mô hình Aspect UML, trước hết chúng... để thực hiện mỗi cái trong chúng 3.2.3 Đặc tả mô hình Aspect UML bằng Alloy Phần này giải thích cách mà mô hình Aspect UML có thể được chuyển đổi sang đặc tả Alloy để chúng sau này có thể được phân tích bằng Alloy Analyzed Bảng 2: Chuyển đổi thành phần cấu trúc mô hình Aspect UML sang Alloy Các class và aspect được chuyển thành các khai báo signature trong Alloy Các thuộc tính của một lớp hoặc của 1... của các bộ đếm) o Một mô hình có thể có bất kỳ các con số của fact sigA {} fact { all z: A | F } • Assert: sự liên kết có ý đi theo các fact của mô hình có thể kiểm tra bằng cách sử dụng các lệnh kiểm tra 3.1.4.6 Các hằng số và các toán tử Ngôn ngữ của các mối quan hệ có các hằng và toán tử của mình chúng • Hằng: o None = tập rỗng o Univ = tập phổ biến o Iden = đồng nhất • Các toán tử(Operators): o Set . Hải KIỂM CHỨNG MÔ HÌNH ASPECT-UML BẰNG ALLOY 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 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Bùi Duy Hải KIỂM CHỨNG. góp vào việc kiểm chứng phần mềm.Việc kiểm chứng mô hình UML + OCL đã được giải quyết [2]. Vấn đề đặt ra bây giờ là kiểm chứng mô hình Aspect-UML( là một mô hình UML đơn giản được mở rộng với việc. dựng, kiểm chứng , triển khai và bảo trì. Trong đó việc kiểm chứng phần mềm là hết sức quan trọng để đảm bảo chất lượng của một phần mềm. Kiểm chứng mô hình UML cũng đóng góp vào việc kiểm chứng
Ngày đăng: 23/08/2014, 13:36
Xem thêm: đồ án tốt nghiệp kiểm chứng mô hình aspect-uml bằng alloy
