1. Trang chủ
  2. » Luận Văn - Báo Cáo

Kiểm tra ràng buộc thời gian sử dụng phương pháp AOP

76 701 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 76
Dung lượng 1,62 MB

Nội dung

Khi thiết kế một chiếc cầu, các mối quan tâm cơ bản là trụ cầu, giàn kéo, xà dầm, dây cáp; còn các mối quan tâm theo tiếp theo gồm các tính năng dàn trải toàn bộ công trình là lắp đặt hệ

Trang 1

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

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trang 2

MỤC LỤC

Lời cam đoan 1

Tóm tắt nội dung 3

MỤC LỤC 4

DANH MỤC KÍ HIỆU – TỪ VIẾT TẮT 6

DANH MỤC HÌNH VẼ 7

Mở đầu 8

Chương 1 Giới thiệu lập trình hướng khía cạnh (Aspect-Oriented Programming) 10 1.1 Giới thiệu 10

1.2 Lập trình hướng khía cạnh – AOP 11

1.2.1 Lịch sử hình thành 12

1.2.2 Phương pháp lập trình hướng khía cạnh 13

1.3 Ngôn ngữ lập trình hướng khía cạnh AspectJ 15

1.3.1 Các khái niệm cơ bản 15

1.3.2 Cơ chế hoạt động của AspectJ 16

1.3.2.1 Thực thi cắt ngang 16

1.3.2.2 Join point 17

1.3.2.3 Point cut 20

1.3.2.4 Advice 22

1.3.2.5 Introduction 24

1.3.2.6 Compile-time declaration 25

1.3.2.7 Aspect 25

1.3.3 Kết luận 27

Chương 2 Ngôn ngữ mô hình hoá đặc tả ràng buộc thời gian 28

2.1 Giới thiệu 28

2.2 Một số biểu đồ UML 28

2.2.1 Biểu đồ trạng thái 30

2.2.2 Biểu đồ trình tự 31

2.2.3 Biểu đồ thiết lập thời gian 31

2.2.3.1 Vấn đề đặc tả 31

2.2.3.2 Định nghĩa ràng buộc thời gian 33

2.2.3.3 Tầm quan trọng 33

2.3 Ngôn ngữ XML (eXtensible Markup Language) 34

2.3.1 Cơ bản về XML 34

2.3.2 XML DOM 36

2.3.2.1 DOM 36

2.3.2.2 XML DOM 37

2.3.2.3 XML DOM Parser 37

2.3.2.4 XML DOM API 38

2.4 XMI (XML Metadata Interchange) 39

2.5 Kết luận 40

Trang 3

Chương 3 Kiểm tra sự tuân thủ giữa thực thi và đặc tả ràng buộc thời gian 41

3.1 Phương pháp đặc tả 41

3.2 Đặc tả làm quy tắc sinh mã Aspect tự động 43

3.3 Kết luận 45

Chương 4 Tự động sinh mã Aspect từ máy trạng thái 46

4.1 Mô tả biểu đồ trình tự UML bằng các đối tượng trong Java 46

4.2 Xây dựng FSM mô tả biểu đồ trình tự UML 47

4.2.1 Máy trạng thái 47

4.2.2 Thuật toán xây dựng máy trạng thái mô tả biểu đồ trình tự UML 47

4.3 Sinh aspect từ FSM mô tả biểu đồ trạng thái UML 49

4.4 Kết luận 50

Chương 5 Thực nghiệm 51

5.1 Hệ thống thực nghiệm 51

5.1.1 Module sinh máy trạng thái từ đặc tả UML Timing diagram 51

5.1.1.1 Xây dựng cấu trúc dữ liệu mô tả biểu đồ trình tự 51

5.1.1.2 Đọc thông tin từ XML 54

5.1.1.3 Lấy ràng buộc thời gian từ file xml 55

5.1.2 Module sinh aspect từ biểu đồ trạng thái 58

5.1.2.1 Xây dựng mã aspect tạo khuân mẫu (template ) 58

5.1.2.2 Template tổng hợp cho kiểm tra tính tuần tự và ràng buộc thời gian 59

5.1.2.3 Sinh mã Aspect tự động từ máy trạng thái và Template 63

5.2 Một ví dụ chạy thử nghiệm 64

5.2.1 Biểu đồ tuần tự và ràng buộc thời gian 64

5.2.2 chương trình sinh mã Aspect từ đặc tả UML 66

5.2.3 Một số giao dịch cụ thể 67

5.2.4 Kiểm tra kịch bản 68

5.2.4.1 Gọi đúng chuỗi trong biểu đồ tuần tự 68

5.2.4.2 Chuỗi gọi không đúng tuần tự 70

5.3 Kết luận 71

Kết luận 72

Kết luận về khóa luận 72

Hướng phát triển trong tương lai 73

Trang 4

DANH MỤC KÍ HIỆU – TỪ VIẾT TẮT

AIS Account Information System

AOP Aspect-Oriented Programming

API Application Programming Interface

ATM Automatic Teller Machine

BDD Binary Decision Diagram

CMU Carnegie Mellon University

CTL Computation Tree Logic

ERP Enterprise Resource Planning

FSM Finite State Machine

HR Human Resource

IRST Istituto per la Ricerca Scientifica e Tecnolgica

JAC Java Aspect Component

LTL Linear Time Logic

NIST National Institute of Standards and Technology

OCL Object Constraint Language

OOP Object-Oriented Programming

PLTL Past Linear Time Logic

PARC Palo Alto Research Center

SPIN Simple Promela Interpreter

UML Unified Modeling Language

Trang 5

DANH MỤC HÌNH VẼ

Hình 1.1 Thực thi các mối quan tâm cắt ngang bằng AOP 12

Hình 1.2: Các giai đoạn phát triển AOP 15

Hình 1.3: Ví dụ về định nghĩa point cut 21

Hình 1.4 các điểm khác nhau khi chèn vào join point 23

Hình 2.1 Biểu đồ UML 2.0 29

Hình 2.2: Biểu đồ trạng thái thực hiện hóa đơn 30

Hình 2.3: Biểu đồ tuần tự rút tiền từ máy ATM 31

Hình 2.4 UML Concise Timing Diagram 32

Hình 2.5 Minh họa biểu đồ ràng buộc thời gian 33

Hình 2.6: XML DOM Parser 38

Hình 2.7 Sử dụng XMI trao đổi thông tin giữa các công cụ khác nhau 40

Hình 3.1: Tiến trình kiểm chứng chung 42

Hình 3.2: Biểu đồ trình tự UML Timing Diagram 44

Hình 4.1 Mô tả các đối tượng trong java 46

Hình 4.2 Mô Hình Máy trạng thái 47

Hình 5 1 Mô tả việc thông điệp từ XML 54

Hình 5.2 Lớp đọc ràng buộc thời gian 55

Hình 5.3 Cài đặt sinh máy trạng thái 58

Hình 5.4 Mã Aspect cho kiểm tra tính ràng buộc thời gian 59

Hinh 5.5 Biểu đồ tuần tự giao dịch rút tiền từ máy ATM 64

Hình 5.7 Chương trình sinh mã Aspects 66

Hình 5.8 Demo generate aspects 67

Hình 5.9 Chương trình mô phỏng giao dịch để kiểm tra bằng mã aspect đã sinh 67

Trang 6

Phần mềm được coi là sản phẩm chính của công nghệ phần mềm, được phát triển theo các mô hình, quy trình phát triển đặc biệt Quá trình phát triển phần mềm bao gồm rất 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 tra, triển khai và bảo trì phần mềm Trong các giai đoạn đó giai đoạn kiểm tra, phát hiện, xác định và sửa các 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 Các lỗi phần mềm có thể gây thiệt hại to lớn về tiền bạc, thời gian 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 thì càng gây hậu quả nghiêm trọng, tốn rất nhiều thời gian và công sức để sửa chữa lỗi, thậm chí có thể phải xây dựng lại toàn bộ hệ thống

từ đầu Chính vì vậy cần có các phương pháp phát hiện lỗi sớm nhằm giảm thiểu công sức

để sửa chúng Để phát hiện ra những lỗi phần mềm, phần mềm cần phải được kiểm chứng (Verification) và thẩm định (Valication) [13] Kiểm chứng phần mềm là kiểm tra xem phần mềm có được thiết kế đúng và thực thi đúng như đặc tả yêu cầu hay không Thẩm định phần mềm là giai đoạn có sự hỗ trợ của khách hàng nhằm kiểm tra xem phần mềm

có đáp ứng được các yêu cầu của họ hay không

Mục đích chính của kiểm chứng phần mềm là làm giảm thiểu lỗi phần mềm tới mức

có thể chấp nhận được Chính vì vậy, nó có vai trò vô cùng quan trọng trong toàn bộ quy trình phát triển phần mềm và trong ngành công nghệ phần mềm hiện nay Nó đã và đang thu hút được mối quan tâm của rất nhiều nhà nghiên cứu

Giai đoạn kiểm thử trong quy trình phát triển phần mềm có mục đích kiểm tra tính đúng đắn của sản phầm phần mềm Trên thực tế, các thao tác kiểm thử đơn vị chỉ đánh giá được tính đúng sai của đầu vào và đầu ra của chương trình, không kiểm tra được quá

Trang 7

trình hoạt động logic của chương trình có theo đúng đặc tả ban đầu hay không Những đơn vị chương trình nhỏ này nếu không được kiểm tra kỹ sẽ có thể gây ra thiệt hại nặng

nề khi tích hợp chúng để tạo thành chương trình hoàn chỉnh Vấn đề đặt ra là cần có phương pháp kiểm chứng các đặc tả giao thức giữa các đối tượng, các tác tử ngay trong thời gian chạy, đánh giá xem trong thời gian chạy đối tượng hay tác tử phần mềm có vi phạm các giao thức ràng buộc đã được đặc tả hay không, và từ đó đảm bảo chắc chắn hơn tính đúng đắn của sản phầm phần mềm Trong luận văn này, tôi xin giới thiệu phương

pháp tự động sinh mã aspect kiểm chứng đặc tả giao thức trong thời gian chạy, dựa trên

phương pháp lập trình hướng khía cạnh (Aspect – Oriented Programming)

2 Nội dung bài toán

Hiện nay có rất 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 ở đây, 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 (AOP) [7, 12] Lĩnh vực kiểm chứng cụ thể trong phạm vi bài toán là kiểm tra tự động tính tuần tự của các phương thức trong giao thức, kiểm tra ràng buộc thời gian của các phương thức trong giao thức có tuân theo thiết kế đặc tả hay không 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; Các aspect sau đó sẽ được đan vào khung mã Java để kiểm tra tại bất kỳ thời điểm nào trong thời gian chạy (aspect là mô-đun cắt ngang hệ thống) Bài toán có nhiệm vụ là tạo ra được các aspect từ biểu đồ ràng buộc thời gian (Timing Diagram); dùng công cụ AspectJ để đan các aspect này vào khung chương trình Java chính Khi đó, 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 đặc tả 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

Nhiệm vụ chính của bài toán là xây dựng phương pháp tạo ra các đoạn mã aspect để kiểm chứng, xây dựng công cụ tự động sinh mã aspect kiểm chứng từ đặc tả giao thức

bằng biểu đồ ràng buộc thời gian Các tài liệu XMI 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 về UML, XML tôi sẽ phân tích tài liệu XMI, xây dựng máy trạng thái (FSM) mô tả các biểu đồ UML Sử dụng máy trạng thái vừa tạo để sinh ra mã

aspect phục vụ cho việc kiểm chứng sau này Mã aspect chính là đầu ra cuối cùng của

công cụ

Trang 8

Chương 1 Giới thiệu lập trình hướng khía cạnh

(Aspect-Oriented Programming)

1.1 Giới thiệu

Khi kiến trúc sư thiết kế một ngôi nhà, những mối quan tâm chính nhất mà kiến trúc

sư đó nghĩ tới đầu tiên là việc lựa chọn các tính năng cơ bản của ngôi nhà: Thiết kế nền móng, chiều cao của tường, độ dốc của mái, vị trí và kích thước của phòng Các vấn đề được quan tâm tiếp theo là các tính năng đều cần thiết và được chia sẻ bởi các tính năng

cơ bản trên, ví dụ như thiết kế điện nước Khi thiết kế một chiếc cầu, các mối quan tâm cơ bản là trụ cầu, giàn kéo, xà dầm, dây cáp; còn các mối quan tâm theo tiếp theo gồm các tính năng dàn trải toàn bộ công trình là lắp đặt hệ thống điện.Việc thiết kế phần mềm cũng dựa trên tư tưởng tương tự như thế.Một nhà thiết kế phần mềm đầu tiên bao giờ cũng quan tâm đến các chức năng chính, cơ bản của hệ thống, mà trong ứng dụng doanh nghiệp chính là các logic nghiệp vụ cơ bản Ví dụ như trong một ứng dụng về ngân hàng, các mô-đun chính được thiết kế để quản lý các giao dịch ngân hàng cho các khách hàng thực hiện Trong ứng dụng bán hàng, mô-đun chính quản lý việc bán hàng và quản lý hàng trong kho.Trong cả hai ứng dụng trên, các mối quan tâm trải khắp hệ thống liên quan đến các tính năng như lưu vết (logging), thẩm định quyền hạn (authorization), lưu trữ dữ liệu (persistence) và các tính năng khác đều cần được chia sẻ và cần thiết cho các các mô-đun nghiệp vụ chính Các mối quan tâm dàn trải trên rất nhiều các mô-đun nghiệp

vụ chính được gọi là các mối quan tâm cắt ngang hệ thống (crosscutting concern)

Mặc dù lập trình hướng đối tượng (Object-Oriented Programming -OOP) là phương pháp phổ biến nhất hiện nay được sử dụng để quảnlý các mối quan tâm nghiệp vụ chính nhưng phương pháp này chưa đủ cho rất nhiều các mối quan tâm cắt ngang hệ thống, đặc biệt là các ứng dụng phức tạp.Phương pháp lập trình hướng khía cạnh (Aspect-Oriented Programming - AOP) [10, 16, 22] là phương pháp lập trình mới cung cấp sự tách biệt các mối quan tâm cắt ngang hệ thống bằng cách đưa ra một đơn vị mô-đun mới cắt ngang các mô-đun khác, đó chính là aspect Với AOP, ta có thể cài đặt các mối quan tâm cắt ngang

hệ thống trong các aspect thay vì dàn trải chúng trên các mô-đun nghiệp vụ chính liên quan Quá trình bộ đan aspect (weaver) kết hợp các mô-đun nghiệp vụ chính với các aspect thành hệ thống cuối cùng được gọi là quá trình đan (weaving) Như vậy, AOP đã

Trang 9

mô-đun hóa các mối quan tâm cắt ngang một cách rõ ràng, tách biệt với các mô-đun nghiệp vụ chính giúp cho việc thiết kế, thực thi và bảo trì hệ thống dễ dàng hơn và tốn ít chi phí, công sức Chương này giới thiệu về phương pháp lập trình hướng khía cạnh AOP Chương này cũng trình bày về AspectJ, một cài đặt phổ biến của AOP trên ngôn ngữ Java

Thực tế thì, mặc dù OOP giải quyết rất tốt trong việc mô-đun hóa các mối quan tâm nghiệp vụ chính nhưng lại gặp khó khăn trong việc mô-đun hóa các mối quan tâm cắt ngang hệ thống Phương pháp AOP được phát triển để giải quyết khó khăn này của OOP Trong AOP, các mối quan tâm cắt ngang hệ thống được mô-đun hóa bằng cách xác định rành mạch vai trò của mỗi mối quan tâm trong hệ thống, thực thi mỗi vai trò đó trong mô-đun riêng của chúng, và kết nối lỏng mỗi mô-đun chỉ với một số hữu hạn các mô-đun khác Hình 1 minh họa việc thực thi các mối quan tâm cắt ngang bằng AOP Ở đây, các lời triệu gọi tới các mối quan tâm cắt ngang được tự động đan vào các mô-đun nghiệp vụ

chính thông qua aspect Aspect là một đơn vị mô-đun mới cho phép định nghĩa các quy

tắc đan cũng như hành động đan vào các mô-đun nghiệp vụ chính.AOP phát triển dựa trên các phương pháp lập trình khác như OOP và lập trình hướng thủ tục, bổ sung thêm các khái niệm và các tổ chức mới nhằm mô-đun hóa các mối quan tâm cắt ngang hệ thống Với AOP, ta có thể cài đặt các mối quan tâm nghiệp vụ chính bằng phương pháp lập trình chính đã chọn Ví dụ như, nếu OOP là phương pháp lập trình chính thì ta có thể cài đặt

các mối quan tâm bằng các lớp Các aspect trong hệ thống đóng gói các mối quan tâm cắt

ngang hệ thống; chúng quy định các mô-đun khác nhau trong hệ thống cần phải được đan với nhau như thế nào để thu được hệ thống cuối cùng Điểm khác biệt cơ bản nhất giữa AOP và OOP chính là việc quản lý các mối quan tâm cắt ngang hệ thống trong AOP,

Trang 10

người lập trình cài đặt các mối quan

Hình 1.1 Thực thi các mối quan tâm cắt ngang bằng AOP

tâm nghiệp vụ chính mà không cần quan tâm đến các hành vi cắt ngang chúng sẽ được đan vào như thế nào Ví dụ như một mô-đun nghiệp vụ chính không cần biết các hoạt động của nó đang được lưu vết hoặc thẩm định quyền hạn Như thế, việc cài đặt các mối quan tâm riêng lẻ là độc lập với nhau

1.2.1 Lịch sử hình thành

Trong nhiều năm gần đây, nhiều nhà lí luận đã cho rằng cách tốt nhất để tạo ra được các hệ thống có thể quản lý được là nhận biết và tách biệt các mối quan tâm của hệ thống Chủ đề này được biết đến với tên là “tách biệt các mối quan tâm” (Separation Of Concerns - SOC) Trong một bài báo vào năm 1972, David Parnas đã đề xuất rằng cách tốt nhất để có được SOC là thông qua mô-đun hóa - quá trình tạo ra các mô-đun trong đó che giấu cách giải quyết của mô-đun này với các mô-đun khác Những năm tiếp theo, các

Trang 11

nhà nghiên cứu đã đưa ra nhiều cách khác nhau để quản lý các mối quan tâm OOP cung cấp một cách thức hiệu quả để tách biệt các mối quan tâm nghiệp vụ chính Tuy nhiên, phương pháp này lại gặp khó khăn khi xuất hiện các mối quan cắt ngang hệ thống Một số phương pháp như lập trình tự sinh (generative programming), siêu lập trình (meta-programming), lập trình tự điều chỉnh (reflective programming), lập trình có khả năng thích ứng (adaptive programming), lập trình hướng chủ đề (subject-oriented programming), lập trình hướng khía cạnh (aspect-oriented programming) và lập trình có mục đích (intentional programming) đã nổi lên như các cách tiếp cận khả dĩ nhằm mô-đun hóa các mối quan tâm cắt ngang hệ thống Tuy nhiên trong đó, AOP là phương pháp phổ biến nhất và tỏ ra hiệu quả nhất khi giải quyết vấn đề này Hầu hết các hoạt động ban đầu tạo nên AOP hiện nay đã được làm tại nhiều trường đại học trên toàn thế giới Cristina Lopes và Gregor Kiczales của trung tâm nghiên cứu Palo Alto (Palo Alto Research Center

- PARC), một công ty con của hãng Xerox, là những người đóng góp đầu tiên cho AOP Gregor đưa ra thuật ngữ AOP vào năm 1996 Ông đã quản lý một nhóm nghiên cứu tại Xerox và phát triển thành công AspectJ, một trong những cài đặt thực tế đầu tiên của AOP, vào cuối những năm 1990 Gần đây, Xerox đã chuyển dự án AspectJ cho cộng đồng

mã nguồn mở tại eclipse.org để tổ chức này tiếp tục cải thiện và hỗ trợ cho dự án AspectJ

là một cài đặt của AOP cũng giống như Java và SmallTalk là các cài đặt của OOP AspectJ dựa trên ngôn ngữ Java nhưng cũng có rất nhiều cài đặt của AOP trên các ngôn ngữ khác từ AspectC cho C đến Pythius cho Python Những cài đặt này cũng áp dụng các khái niệm tương tự trong AspectJ cho các ngôn ngữ khác Bên cạnh đó, cũng có một số cài đặt khác cho ngôn ngữ Java ngoài AspectJ như Java Aspect Component (JAC) của AOPSYS, AspectWerkz của BEA Systems, JBoss AOP hoặc Spring AOP [20] Các cài đặt này khác nhau về cách thức biểu diễn các mối quan tâm cắt ngang hệ thống và dịch các mối quan tâm này để tạo ra hệ thống cuối cùng

1.2.2 Phương pháp lập trình hướng khía cạnh

Phương pháp lập trình hướng khía cạnh vẫn còn trong giai đoạn đầu của sự phát triển và đang dần hoàn thiện Thực tế có rất nhiều nhóm nghiên cứu lĩnh vực này, cũng có những sự hợp nhất nhưng cũng còn nhiều vấn đề chưa thống nhất, kể cả những thuật ngữ như các khái niệm của AOP, tuỳ thuộc vào ngữ cảnh sử dụng các kỹ thuật AOP riêng Tuy nhiên, về cơ bản quá trình phát triển phần mềm theo AOP gồm có 3 bước sau đây:

Trang 12

• Phân rã bài toán theo khía cạnh (Aspectual decomposition): Trong

bước này, cần phân rã yêu cầu của bài toán thành các mối quan tâm nghiệp vụ chính

và các mối quan tâm cắt ngang hệ thống Nói một cách khác, bước này nhằm tách biệt các mối quan tâm mức mô-đun nghiệp vụ với các mối quan tâm cắt ngang, mức hệ thống Ví

dụ trong bài toán quản lý sử dụng thẻ ATM, các mối quan tâm nghiệp vụ như rút tiền, chuyển khoản Các mối quan tâm cắt ngang là lưu vết, lưu trữ, thẩm định quyền hạn, vì chúng cần thiết cho nhiều mô-đun khác

• Cài đặt các mối quan tâm (Concern implementation): Sau khi phân rã, các mối

quan tâm được cài đặt một cách riêng rẽ Trong ví dụ về bài toán quản lý sử dụng thẻ ATM, lập trình viên sẽ cài đặt các mô-đun nghiệp vụ chính bao gồm rút tiền và chuyển khoản; đồng thời cài đặt các mô-đun cắt ngang như lưu vết, lưu trữ, thẩm định quyền hạn, Ta có thể tận dụng các kỹ thuật truyền thống như lập trình hướng thủ tục hoặc lập trình hướng đối tượng để cài đặt các mô-đun này

• Kết hợp lại các khía cạnh (Aspectual recomposition): Sau quá trình phân rã và cài

đặt các mối quan tâm, để hệ thống có thể hoạt động được thì các mối quan tâm cần phải được kết hợp theo một số quy tắc nào đó Người tích hợp (Aspect Integrator) sẽ cần phải chỉ ra các quy tắc để hợp nhất bằng cách xây dựng các thành phần mô-đun hóa gọi là

aspect Quá trình kết hợp này được gọi là “tích hợp” hay “đan” (weaving) bằng cách sử

dụng các quy tắc trên để hình thành nên hệ thống cuối cùng Ví dụ một luật tích hợp: “Tất các các hoạt động của hệ thống cần phải được lưu vết lại” sẽ được cài đặt trên một ngôn ngữ AOP nào đó để chỉ ra các quy tắc đan.Như vậy, mối quan tâm lưu vết sẽ được bộ đan (weaver) tích hợp

vào các mô-đun nghiệp vụ theo đúng quy tắc chỉ ra

Hình 1 2 minh họa các giai đoạn phát triển các ứng dụng AOP.[22]

Trang 13

Hình 1.2: Các giai đoạn phát triển AOP

1.3 Ngôn ngữ lập trình hướng khía cạnh AspectJ

1.3.1 Các khái niệm cơ bản

AspectJ [1, 10, 16, 22] là một mở rộng hướng khía cạnh cho ngôn ngữ lập trình Java Chính vì thế, mọi chương trình Java hợp lệ đều là một chương trình AspectJ hợp lệ

Trình biên dịch AspectJ sẽ kết hợp chương trình Java chính với các aspect thành các tệp

.class phù hợp với các đặc tả Java byte-code, cho phép máy ảo Java có thể thực thi các tệp này Bằng các sử dụng Java là ngôn ngữ cơ sở, AspectJ có được toàn bộ các ưu điểm của Java và giúp cho các nhà lập trình Java dễ dàng hiểu ngôn ngữ AspectJ

AspectJ bao gồm hai phần: Phần đặc tả ngôn ngữ và phần thực thi ngôn ngữ Phần đặc tả ngôn ngữ định nghĩa ngôn ngữ viết mã chương trình Với AspectJ, các mối quan tâm nghiệp vụ chính được cài đặt trên ngôn ngữ lập trình Java còn các mối quan tâm cắt ngang và các quy tắc đan được cài đặt trên các mở rộng của AspectJ Phần thực thi ngôn ngữ cung cấp các công cụ biên dịch, gỡ lỗi và tích hợp với các môi trường phát triển tích hợp khác phổ biến Các phần tiếp theo trong chương này sẽ trình bày về phần đặc tả ngôn ngữ, các thông tin về phần thực thi ngôn ngữ (trình biên dịch, môi trường phát triển, ) có thể xem trong các tài liệu [10, 16, 22]

Trong AOP, công việc kết hợp (đan - weaving) mối quan tâm cắt ngang với các mối quan tâm nghiệp vụ chính được thực hiện dựa trên các quy tắc đan Các quy tắc đan chỉ ra hành động nào được thực hiện khi một số điểm nào đó trong quá trình thực thi chương

Trang 14

trình xảy a Với AspectJ khi thực thi AOP, trình biên dịch AspectJ sử dụng các mô-đun

cài đặt các mối quan tâm cắt ngang chứa các quy tắc đan (các aspect) để chèn thêm hành

vi mới cho các mô-đun cài đặt các mối quan tâm nghiệp vụ chính mà không cần thay đổi

mã nguồn của các mô-đun ghiệp vụ chính Việc đan mã nguồn nghiệp vụ chính với các

aspect chỉ thực hiện trong byte-code mà trình biên dịch sinh ra

1.3.2 Cơ chế hoạt động của AspectJ

1.3.2.1 Thực thi cắt ngang

Trong AspectJ, việc thực thi các quy tắc đan bởi trình biên dịch được gọi là thực thi cắt ngang (crosscutting) Các quy tắc đan này cắt ngang nhiều mô-đun một cách có hệ thống nhằm mô-đun hóa các mối quan tâm cắt ngang AspectJ định nghĩa ra hai loại thực thi cắt ngang, đó là thực thi cắt ngang tĩnh và thực thi cắt ngang động

• Thực thi cắt ngang động (dynamic crosscutting): Thực thi cắt ngang động là việc

đan hành vi mới vào quá trình thực thi một chương trình Hầu hết việc thực thi cắt ngang trong AspectJ đều là thực thi cắt ngang động Thực thi cắt ngang động chèn thêm hoặc thay thế luồng thực thi chương trình chính theo cách cắt ngang nhiều mô-đun, chính vì thế làm thay đổi hành vi của hệ thống Ví dụ như nếu muốn chỉ ra rằng một hành động nào đó được thực hiện trước sự thực thi của một vài phương thức hoặc trước khi xử lý ngoại lệ trong một số lớp nào đó thì chỉ cần chỉ ra các điểm đan và hành động được thực hiện khi các điểm này thỏa mãn trong một mô-đun riêng lẻ

• Thực thi cắt ngang tĩnh (static crosscutting): Thực thi cắt ngang tĩnh là việc đan các sửa đổi vào cấu trúc tĩnh như lớp, giao diện hay các aspect của hệ thống Chức năng

chính của thực thi cắt ngang tĩnh là hỗ trợ cho thực thi cắt ngang động Ví dụ như khi thêm dữ liệu và phương thức mới vào lớp và phương thức đã có nhằm định nghĩa ra các trạng thái và các hành vi của một lớp nào đó sử ụng trong các hành động của thực thi cắt ngang động Thực thi cắt ngang tĩnh còn được sử dụng nhằm khai báo các cảnh báo và lỗi tại thời điểm biên dịch cho nhiều mô-đun

AspectJ sử dụng các cú pháp mở rộng cho ngôn ngữ lập trình Java để chỉ ra các quy tắc đan cho việc thực thi cắt ngang động và thực thi cắt ngang tĩnh Các cú pháp mở rộng này được thiết kế theo cách mà một lập trình viên Java cảm thấy quen thuộc khi sử dụng

Để xác định các quy tắc đan một cách tự động các mối quan tâm cắt ngang vào các

Trang 15

mô-đun nghiệp vụ chính, AspectJ sử dụng các cấu trúc sau để diễn tả việc cài đặt các mối

quan tâm cắt ngang hệ thống: Join point, pointcut, advice, introduction, compile-time declaration và aspect

1.3.2.2 Join point

Join point là một điểm có thể xác định trong quá trình thực thi một chương trình Đó

có thể là một lời gọi đến một phương thức hoặc lệnh gán cho một thành viên của một đối

tượng Trong AspectJ, mọi thứ đều xoay quanh các join point, bởi vì chúng là những vị trí

mà các hành động thực thi cắt ngang được đan vào.Sau đây một số loại join point chính

trong AspectJ:

• Method join point: Có hai loại join point mà AspectJ dành cho các phương thức

Đó là join point thực thi phương thức (method execution join point) và join point triệu gọi phương thức (method call join point) Join point thực thi phương thức nằm trên chính phần thân của phương thức thực thi Trong khi đó, join point triệu gọi phương thức lại

nằm trên các phần khác của chương trình, thường là các phương thức gọi phương thức

đang xét.Join point thực thi phương thức bao gồm sự thực thi của tất cả các mã trong phần thân của bản thân phương thức đang xét Đoạn mã sau đây minh họa cho join point

thực thi cho phương thức debit()

public class Account {

public void debit(float amount)

throws InsufficientBalanceException {

if (_balance < amount) { //

throw new InsufficientBalanceException( //

"Total balance not sufficient");//

} else { //

_balance -= amount; //

} //

}

Trang 16

account.debit(100); // < debit() method call join point

• Constructor join point: Các join point trên một phương thức khởi tạo gần giống với

emphmethod join point, chỉ khác là chúng biểu diễn sự thực thi và triệu gọi việc tạo ra

một đối tượng của một lớp Đoạn mã sau đây minh họa cho join point thực thi cho khởi

tạo cho lớp Account :

public class Account {

Account account = new Account(199);

• Field access join point: Các field access join point nắm bắt việc truy cập các trường dữ liệu bao gồm truy cập đọc và truy cập ghi các trường dữ liệu Các join point

này chỉ có hiệu lực với thành viên dữ liệu của tới một thành viên dữ liệu của một lớp chứ không có hiệu lực với các biến cục bộ của một phương thức

•Field read access join point nắm bắt việc truy cập đọc tới một thể hiện hoặc một thành viên dữ liệu của một lớp Đoạn mã dưới đây minh họa một field read access join point tới trường accountNumber của lớp Account :

Trang 17

public class Account {

Dưới đây là đoạn mã minh họa cho field write access join point tới trường

accountNumber của lớp Account :

public class Account {

int _accountNumber;

public Account(int accountNumber) {

_accountNumber = accountNumber;//< Write access join point

ngoại lệ:

try {

account.debit(amount);

Trang 18

} catch (InsufficientBalanceException ex) { //

1.3.2.3 Point cut

Point cut là một cấu trúc chương trình lựa chọn ra một nhóm các join point và tập hợp ngữ cảnh tại các join point này Ví dụ như, một point cut có thể lựa chọn một join point là lời gọi tới một phương thức, nó cũng có thể nắm bắt ngữ cảnh của phương thức

đó, chẳng hạn như đối tượng đích chứa phương thức được gọi và các tham số của phương

thức đó Point cut dùng để chỉ ra các quy tắc đan còn join point là các vị trí thỏa mãn các

quy tắc đó

Một point cut designator dùng để xác định point cut bằng tên hoặc bằng một biểu thức Ta có thể khai báo một point cut trong một aspect, một lớp hoặc một giao diện

Giống như dữ liệu và phương thức, ta có thể sử dụng một định danh phạm vi truy cập

(public, private, ) đểgiới hạn quyền truy cập đến point cut

Trong AspectJ, các point cut có thể có tên hoặc không Các point cut không tên, giống như các lớp không tên, được định nghĩa tại nơi sử dụng Các point cut được đặt tên

là các thành phần có thể được tham chiếu từ nhiều nơi khác khiến cho chúng có thể tái sử

dụng được Tên của các point cut sử dụng cú pháp sau:

[access specifier] pointcut pointcut-name([args]) : pointcut-definition

Hình 1.3 minh họa ví dụ về định nghĩa point cut với tên accountOperations() Point cut này sẽ nắm bắt toàn bộ các phương thức trong lớp Account

Trang 19

Hình 1.3: Ví dụ về định nghĩa point cut

Kết luận Để chỉ ra một nhóm các join point, phần Signature của point cut

chứa các ký tự đại diện (wildcard) và các toán tử Trong AspectJ, có 3 loại ký tự đại diện và 2 loại toán tử

• Ký tự đại diện:

“*”: Chỉ ra số lượng bất kỳ các ký tự trừ dấu chấm (“.”)

“ ”: Chỉ ra số lượng bất kỳ các ký tự, chứa cả dấu chấm

“+”: Chỉ ra bất kỳ lớp con hoặc giao diện con nào

• Toán tử:

Toán tử một ngôi: AspectJ chỉ cung cấp duy nhất một toán tử một ngôi “!” cho

point cut: Toán tử phủ định cho phép phù hợp tất cả các join point trừ join point mà point cut chỉ ra bằng toán tử “!”

Toán tử hai ngôi: “||” (Hoặc) và “&&” (Và) để kết nối các point

cut với nhau

Bảng 2.1 chỉ ra ánh xạ giữa các loại join point tương ứng với các cú

pháp point cut designator Cú pháp chi tiết của point cut có thể xem

trong tài liệu [16] và [22]

Trang 20

Loại join point Cú pháp join point Method execution execution(MethodSignature) Method call call(MethodSignature) Constructor

execution

execution(ConstructorSignature)

Constructor call call(ConstructorSignature) Class initialization staticinitialization(TypeSignature) Field read access get(FieldSignature)

Field write access set(FieldSignature) Exeception handler

execution

Handler(TypeSignature)

Object pre-initialization preinitialization(ConstructorSignatur

e) Advice execution adviceexecution()

1.3.2.4 Advice

Advice là một đoạn mã được thực thi tại một join point đã được lựa chọn bởi một point cut Advice có thể được thực thi trước (before advice), sau (after advice) hoặc “xung quanh” (around advice) join point Around advice có thể chỉnh sửa đoạn mã tại join point,

nó có thể thay thế, thậm chí bỏ qua sự thực thi của đoạn mã đó Sử dụng advice, ta có thể đưa ra thông báo trước khi thực thi đoạn mã tại các điểm join point xác định trên một vài mô-đun Phần thân của advice gần giống với thân của phương thức Nó sẽ được thực thi khi một join point được thỏa mãn

Hình 1.4 minh họa các điểm khác nhau trong chuỗi thực thi join point triệu gọi và

thực thi phương thức debit(), ta có thể chèn thêm một hành vi mới thông qua các loại

advice

Trang 21

Hình 1.4 các điểm khác nhau khi chèn vào join point

Dưới đây là ví dụ về before advice Advice này có nhiệm vụ thẩm định quyền hạn

của người dùng khi sử dụng bất cứ phương thức nào của lớp Account

before() : call(* Account.*( )) {

// authenticate the user

}

Đoạn mã dưới đây minh họa after advice dùng để lưu vết lại khi bất kỳ phương thức

nào của lớp Account được triệu gọi

after() : call(* Account.*( )) {

// log the return from operation

Trang 22

}

Dưới đây là ví dụ minh họa về around advice dùng để kiểm tra việc rút tài khoản

Nếu số tiền rút vượt quá số dư tài khoản thì không cho phép rút

void around(Account account, float amount)

throws InsufficientBalanceException :

call(* Account.debit(float) throws InsufficientBalanceException)

&& target(account)

&& args(amount) { try {

proceed(account, amount);

} catch (InsufficientBalanceException ex) {

// overdraft protection logic

}

}

Poincut và advice cùng nhau tạo nên các quy tắc thực thi cắt ngang động Trong khi các point cut xác định các join point cần thiết thì advice cung cấp hành động sẽ xảy ra tại các join point đó

1.3.2.5 Introduction

Introduction là lệnh để thực thi cắt ngang tĩnh nhằm đưa vào các thay đổi cho lớp, giao diện và aspect của hệ thống Điều này tạo ra các thay đổi tĩnh cho các mô-đun mà

không ảnh hưởng trực tiếp đến các hành vi của chúng Ví dụ như, ta có thể thêm một

phương thức hoặc một trường vào một lớp (được gọi là inter-type declaration) Introduction sau khai báo lớp Account thực thi giao diện BankingEntity đồng thời khai

báo thêm trường dữ liệu minimumBalance và phương thức getAvailableBalance() cho lớp Account:

declare parents: Account implements BankingEntity;

private float Account._minimumBalance;

Trang 23

public float Account.getAvailableBalance() {

return getBalance() - _minimumBalance;

}

1.3.2.6 Compile-time declaration

Compile-time declaration là một lệnh thực thi cắt ngang tĩnh cho phép thêm các

cảnh báo và các lỗi tại thời điểm biên dịch nhờ phát hiện các mẫu thông dụng nào đó Khai báo sau làm cho trình biên dịch đưa ra một cảnh báo nếu bất kỳ phần nào của hệ

thống gọi phương thức save() trong lớp Persistence Việc sử dụng point cut call() để nắm

bắt lời gọi phương thức:

declare warning : call(void Persistence.saveObject))

: "Consider using Persistence.saveOptimized()";

1.3.2.7 Aspect

Aspect là đơn vị trung tâm trong AspectJ, giống như lớp là đơn vị trung tâm trong

Java Nó chứa đoạn mã diễn tả các quy tắc đan cho cả thực thi cắt ngang động và thực thi

cắt ngang tĩnh Poincut, advice, introduction và declaration kết hợp thành aspect Bên cạnh các phần tử của AspectJ, aspect còn có thể chứa cả dữ liệu, phương thức, các thành viên lớp lồng nhau giống như một lớp bình thường trong Java Aspect tương tự như một

lớp thông thường trong Java ở các điểm:

• Aspect có thể chứa các thành phần dữ liệu và các phương thức giống như

lớp

• Aspect có thể có các định danh về phạm vi truy cập giống như lớp và giao

diện bao gồm: public, mặc định (mức package), protected và private

• Aspect có thể khai báo chúng là dạng trừu tượng bằng từ khóa abstract

• Aspect có thể kế thừa các lớp và các aspect trừu tượng khác, và có thể thực

thi các giao diện

• Aspect có thể nằm trong các lớp và các giao diện.Tuy nhiên, aspect không phải một lớp Dưới đây là các điểm khác của aspect với lớp:

• Aspect không thể được thể hiện hóa trực tiếp

Trang 24

• Aspect không thể kế thừa từ các aspect cụ thể (không trừu tượng)

• Aspect có thể được đánh dấu là có đặc quyền bằng định danh phạm vi truy cập privileged Điều này làm cho các aspect có thể truy cập được đến các thành

viên private của các lớp mà chúng cắt ngang

Ta có thể kết hợp các phần thực thi cắt ngang tĩnh và thực thi cắt ngang độngvào

thành một aspect dưới đây:

public aspect MinimumBalanceRuleAspect {

// Introduction

declare parents: Account implements BankingEntity;

// Compile-time declaration

declare warning : call(void Persistence.save(Object))

: "Consider using Persistence.saveOptimized()";

// Inter-type declaration

private float Account._minimumBalance;

public float Account.getAvailableBalance() {

return getBalance() - _minimumBalance;

before(Account account, float amount)

throws InsufficientBalanceException : debitOperations(account, amount){

if (account.getAvailableBalance() < amount) {

throw new InsufficientBalanceException(

Trang 25

"Insufficient available balance");

Trang 26

Chương 2 Ngôn ngữ mô hình hoá đặc tả ràng buộc

thời gian

2.1 Giới thiệu

UML (Unified Modeling Language) là ngôn ngữ mô hình hoá được sử dụng để biểu diễn, đặc tả và xây dựng các thành phần của hệ thống phần mềm Nó là một chuẩn của tổ chức OMG(Object management Group) UML giúp người sử dụng mô tả được các tài liệu đặc tả yêu cầu, tài liệu phân tích và tài liệu thiết kế ứng dụng Hiện nay, nó được dùng để

mô hình hoá gần như toàn bộ các hệ thống phần mềm từ nhỏ đến lớn, từ đơn giản đến phức tạp trên thế giới

2.2 Một số biểu đồ UML

UML sử dụng một hệ thống kí hiệu thống nhất để biểu diễn các phần tử mô hình Tập các phần tử mô hình tạo nên các biểu đồ UML Có nhiều loại biểu đồ UML như : biểu đồ ca sử dụng, biểu đồ lớp, biểu đồ tuần tự, biểu đồ trạng thái, biểu đồ hoạt động… Nếu UML 1.X có 9 loại biểu đồ, UML 2.0 mở rộng có 13 loại biểu đồ Nó phân thành hai nhóm: Biểu đồ cấu trúc (structure Diagram) và biểu đồ hành vi (behavior Diagram) Hình 2.1 biểu diễn UML 2.0 và được phát triển từ UML 1.5

Trang 27

Hình 2.1 Biểu đồ UML 2.0

Nét đặc trưng của Structure Diagram biểu diễn hệ thống được xây dựng không thay đổi theo thời gian, bao gồm 6 loại biểu đồ: Biểu đồ lớp (class Diagram), biểu đồ đối tượng (Object Diagram), biểu đồ đóng gói (Package Diagram), biểu đồ triển khai (Deployment Diagram), biểu đồ cấu trúc hỗn hợp ( Composite structure Diagram) và biểu

đồ cấu thành (Component Diagram)

Biểu đồ hành vi( Behavioral Diagram bao gồm 7 loại biểu đồ: Biểu đồ hoạt động (Activity Diagram), biểu đồ trạng thái (state Machine Diagram), biểu đồ ca sử dụng (Use case Diagram), biểu đồ tương tác tổng quát (Interaction Diagram), biểu đồ trình tự (Sequence Diagram), biểu đồ truyền thông(Communication Diagram) và biểu đồ thiết lập thời gian (Timing diagram)

Luận văn này tôi xin trình bày ba loại biểu đồ được làm đầu vào cho nghiên cứu của tôi là biểu đồ trạng thái (state Diagram), biểu đồ trình tự (Sequence Diagram), biểu đồ thiết lập thời gian (Timing Diagram)

Trang 28

2.2.1 Biểu đồ trạng thái

Biểu đồ trạng thái là một sự bổ sung cho lời miêu tả biểu đồ lớp Nó mô tả chu kỳ tồn tại của đối tương từ khi sinh ra đến khi bị phá hủy Nó chỉ ra tất cả các trạng thái mà đối tượng của lớp này có thể có, các hành vi của đối tượng và những sự kiện tác động làm thay đổi trạng thái

Ví dụ:

Hình 2.2: Biểu đồ trạng thái thực hiện hóa đơn

Một trạng thái có thể có ba phần sau:

- Name: Tên của trạng thái, Ví dụ: Paid, Unpaid

- State variables (các biến trạng thái – không bắt buộc): đây là những thuộc tính của

lớp được thể hiện qua biểu đồ trạng thái

- Activities (sự kiện – không bắt buộc): Đây là phần dành cho hoạt động nơi mà các sự

kiện và hành động và liệt kê Có ba loại sự kiện chuẩn hóa có thể được sử dụng cho hành động:

o Entry: Xác định các hành động tạo trạng thái

o Exit: Xác định các hành động khi rời bỏ trạng thái

o Do: Xác định các hành động cần phải thực hiện trong trạng

thái

Sự kiện là nguyên nhân của chuyển trạng thái Một sự kiện có thể kích hoạt một hoặc nhiều hành động bởi một tác nhân Trong UML, có các kiểu sư kiện:

- Change events: Xuất hiện khi điều kiện thỏa mãn

- Signal events: Chỉ ra việc nhận một tín hiệu ngoài từ một đối tượng sang đối tượng

khác

- Call events: Chỉ ra việc nhận một lời gọi hàm bởi một đối tượng hoặc tác nhân

- Time events: Đánh dấu việc chuyển trạng thái sau một khoảng thời gian

Trang 29

2.2.2 Biểu đồ trình tự

Biểu đồ trình tự minh họa các đối tượng tương tác với nhau ra sao Chúng tập trung vào các chuỗi thông điệp, có nghĩa là các thông điệp gửi và nhận giữa một loạt các đối tượng như thế nào Biểu đồ tuần tự có hai trục: trục dọc chỉ thời gian, trục nằm ngang chỉ

ra một tập các đối tượng Ví dụ:

Hình 2.3: Biểu đồ tuần tự rút tiền từ máy ATM

Một biểu đồ tuần tự cũng nêu bật sự tương tác giữa các đối tượng trong một kịch bản – một tương tác sẽ xảy ra tại một thời điểm nào đó trong quá trình thực thi hệ thống Biểu đồ tuần tự gồm hai thành phần chính:

- Các đối tượng

- Các thông điệp trao đổi giữa các đối tượng

2.2.3 Biểu đồ thiết lập thời gian

2.2.3.1 Vấn đề đặc tả

Biểu đồ thiết lập thời gian (Timing Diagram là kiểu biểu đồ mới được thêm vào UML 2.0 Nó là một dạng đặc biệt của biểu đồ tương tác (interaction Diagram), được sử dụng để khảo sát sự hoạt động của một hoặc nhiều đối tượng từ khi bắt đầu đến khi kết thúc một giai đoạn mà nhấn mạnh ràng buộc thời gian

Biểu đồ thiết lập thời gian biểu diễn sự thay đổi trạng thái của đối tượng trong một giai đoạn mà nhấn mạnh ràng buộc thời gian Nó được sử dụng để thiết kế phần mềm nhúng, ví dụ như phần mềm điều khiển bơm nhiên liệu vào hệ thống xe hơi, đôi lúc chúng được sử dụng trong kinh doanh

Trang 30

Biểu đồ thiết lập thời gian cũng là một kiểu đặc biệt của biểu đồ trình tự Sự khác biệt giữa biểu đồ thiết lập thời gian và biểu đồ trình tự là trục thời gian nằm ngang, thời gian tăng dần từ trái sang phải Biểu đồ thiết lập thời gian có hai kiểu: Concise notation và robust notation

Kí pháp ngắn gọn (Concise notation) biểu diễn dòng thời gian khá rõ ràng, biểu đồ thiết lập thời gian trong kí pháp ngắn gọn biểu diễn chu kì sống của lifeline từng giai đoạn của thời gian Trong kí pháp này, biểu đồ thiết lập thời gian sẽ biểu diễn trạng thái lifeline, việc thay đổi điểm giữa các trạng thái này và ràng buộc thời gian của biểu đồ

Hình 2.4 UML Concise Timing Diagram

Kí pháp ngắn gọn rất thuận lợi được sử dụng khi bạn cần khảo sát những hành vi chung của một hoặc nhiều đối tượng trong suốt một chu kì của thời gian trong khi xem nguồn gốc được sử dụng khi bạn cần vẽ thông tin chi tiết hơn về sự chuyển đổi giữa trạng thái của đường sống (lifelines)

Kí pháp vững chắc tìm hiểu chi tiết những gì xảy ra trong lifeline Lifeline là mô hình đơn giản bởi việc thêm các đoạn vào hệ thống

Trang 31

Hình 2.5 Minh họa biểu đồ ràng buộc thời gian

cả hai kí pháp đều có các mục đích riêng, mặc dù kí pháp vững chắc hữu ích hơn của hai đối tượng cụ thể mà di chuyển tới hoặc lui giữa các trạng thái

2.2.3.2 Định nghĩa ràng buộc thời gian

Ràng buộc thời gian được IBM định nghĩa: là sự đặc trưng xác nhận hành động hợp lệ (validation action), dùng đo khoảng thời gian gọi một phương thức hoặc trình tự việc gọi phương thức

Xác nhận tính hợp lệ của hành động là cơ chế kiểm tra giá trị thực của biến

(variable) tại thời điểm thực thi có phù hợp với giá trị mong muốn của biến không 2.2.3.3 Tầm quan trọng

Ràng buộc thời gian thực sự quan trọng trong biểu đồ thiết lập thời gian Nó mô tả

chi tiết bao lâu sự phân chia tương tác diễn ra

Chúng thường dùng một lượng thời gian mà sự tham gia ở trong trạng thái ngoại lệ hoặc bao lâu một sự kiện diễn ra được gọi và nhận được biểu diễn trong hình 2 5 Sự áp dụng ràng buộc thời gian vào biểu đồ này Khoảng thời gian của một sự kiện phải nhỏ

Trang 32

hơn của quan hệ đo thời gian t và p2: participant2 ở trong trạng thái 4 cho giá trị lớn nhất

ta chọn XMI bởi nó mềm dẻo, là cách phổ biến để trình bày dữ liệu

2.3 Ngôn ngữ XML (eXtensible Markup Language)

2.3.1 Cơ bản về XML

XML kết hợp những ưu điểm của các ngôn ngữ trước đó (sự đơn giản của HTML và cấu trúc mô tả tài liệu của SGML), có khả năng mô tả nhiều loại dữ liệu khác nhau với mục đích là đơn giản hóa việc chia sẻ dữ liệu giữa các hệ thống khác nhau, đặc biệt là các

hệ thống được kết nối với Internet XML là ngôn ngữ đánh dấu với mục đích chung cho W3C đề nghị [6]

XML là một ngôn ngữ đánh dấu, nó 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ự [6]

Nội dung của một tài liệu XML gồm hai phần chính:

- Nội dung chính: Hệ thống các thẻ đánh dấu tương ứng với các thông tin cần biểu

diễn và có một node gốc

- Nội dung phụ: Bổ sung thông tin cho tài liệu XML, một số thẻ phụ:

o Thẻ khai báo tham số: <?xml Ten1=“Giatri1”… ? >

Một số tham số thường dùng như: tham số version (phiên bản chỉ định của XML), tham số encoding (cách mã hóa các ký tự), tham số standalone (liên kết với tài liệu xml khác)

Trang 33

o Thẻ chỉ thị xử lý: Mô tả một số thông tin cho tài liệu XML nhưng có ý nghĩa riêng đối với một vài công cụ xử lý nào đó Cấu trúc:

<? Bo_Xu_Ly_Du_Lieu >

Ví dụ: <?xml-stylesheet type=“text/css” href=“a.css” ?>

Định dạng thể hiện tài liệu XML với “chương trình định dạng”

theo ngôn ngữ CSS được lưu trữ bên trong tệp tin a.css Thẻ này có ý

nghĩa với một số trình duyệt như IE5, Netscape

o Thẻ ghi chú: Không ảnh hưởng đến tài liệu XML

Cấu trúc: < Nội dung ghi chú >

o Thẻ CDATA: Yêu cầu các bộ phân tích tài liệu XML bỏ qua không phân tích vào nội dung bên trong của thẻ này Mục đích chính của thẻ này là cho phép sử dụng trực tiếp bên trong thẻ một số ký hiệu không được phép sử dụng bên ngoài Ví dụ các ký tự „<‟, „>‟

Cấu trúc: <![CDATA [Nội dung]]>

o Thẻ khai báo thực thể: cho phép tài liệu XML tham chiếu đến một tập hợp các giá trị đã chuẩn bị trước dưới dạng một tên gợi nhớ (tên thực thể)

Khai báo: <!DOCTYPE Ten_goc[

Khai báo thực thể tên X

Khai báo thực thể tên Y]

o Thẻ khai báo cấu trúc

Các thẻ XML không được định nghĩa trước trong cú pháp XML, người sử dụng có thể tự định nghĩa theo các thẻ theo ý thích khi sử dụng XML XML sử dụng DTD hoặc XML schema để mô tả dữ liệu XML biểu diễn dữ liệu bằng cách sử dụng các thành phần XML, trong đó chứa một trong các thành phần sau đây:

- Thẻ bắt đầu: Chứa tên của thành phần

- XML attributes: Các thuộc tính, mỗi thuộc tính có tên và giá trị

- Nội dung: Có thể chứa một đoạn văn bản hoặc thuộc tính, cũng có thể chứa cả hai

- Thẻ kết thúc, giống với tên của thẻ bắt đầu

Trang 34

<comment> An edge of one graph</comment>

Có 6 thành phần XML trong tài liệu này Đầu tiên là chỉ thị xử lý, Phần tử edge chứa thuộc tính có tên là type và giá trị là directed Phần tử edge chứa hai phần tử con là from

và to chúng có hai thuộc tính là id Phần tử comment chứa nội dung là một đoạn văn bản

(text)

XML đã trở thành một công cụ rất mạnh và đơn giản để lưu trữ dữ liệu trên các file

Nó cho phép bạn lưu trữ dữ liệu theo mẫu và có thể truy xuất được bằng các ứng dụng khác nhau, nhưng nó không thể tạo ra dữ liệu Bằng cách sử dụng các API như DOM, SAX, bạn có thể truy xuất dữ liệu từ một tài liệu XML rất dễ dàng

2.3.2 XML DOM

2.3.2.1 DOM

“The W3C Document Object Model (DOM) is a platform and language-neutral

interface that allows programs and scripts to dynamically access and update the content,

structure, and style of a document” [http://www.w3.org/]

DOM gồm ba phần riêng biệt:

- Core DOM: Định nghĩa các đối tượng chuẩn cho các tài liệu có cấu

Trang 35

2.3.2.2 XML DOM

XML DOM định nghĩa các đối tượng và thuộc tính của tất cả các thẻ của tài liệu XML và các phương thức (giao diện) để truy xuất chúng Nó là một chuẩn để truy xuất, thêm, xóa, sửa các thẻ XML

Trong DOM, mọi thứ trong tài liệu đều là nút (node):

- Toàn bộ tài liệu là một nút tài liệu (document node) – cây node

o Một cây gồm nhiều node

o Node cao nhất gọi là root

o Mỗi node, trừ root ra có chính xác một node cha

o Một node có nhiều node con

o Node lá là node không có node con

- Mọi thẻ XML là một nút thẻ (element node)

- Text trong các thẻ XML là nút text (text node)

- Mọi thuộc tính là nút thuộc tính (attribute node)

- Ghi chú là nút ghi chú (comment node)

2.3.2.3 XML DOM Parser

Để đọc, cập nhật và thao tác trên một tài liệu XML ta cần một XML Parser Có nhiều XML Parser được hỗ trợ trong hầu hết các ngôn ngữ (Java, Net…) Parser nạp tài liệu XML vào trong bộ nhớ của máy tính và được xem dưới dạng cây node Sau đó dữ liệu sẽ được thao tác và xử lý thông qua tập hàm XML DOM API

Trang 36

Hình 2.6: XML DOM Parser

2.3.2.4 XML DOM API

Cung cấp các phương thức xử lý tài liệu XML Trong XML DOM API có rất nhiều phương thức để có thể thao tác với tài liệu XML, ở đây tôi xin chỉ ra một số phương thức thường sử dụng nhất để thao tác với tài liệu XML:

- Duyệt node:

o ParentNode: Lấy node cha của node hiện tại

o ChildNodes: Lấy các node con của node hiện tại

o firstChild: Lấy node con đầu tiên của node hiện tại

o lastChild: Lấy node con cuối cùng của node hiện tại

o nextSibling: Lấy node kế tiếp node hiện tại

o previousSibling: Lấy node trước node hiện tại

- Thao tác trên các node:

o getElementsByTagName(String tagname): Trả về một tập các node có thuộc tính tên là: tagname

o getElementById(String id): Trả về một node có thuộc tính id là: id

o 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

Trang 37

o getAttribute(String name): lấy giá trị của thuộc tính có tên là name

o removeChild: Xóa node con của node hiện tại

o removeAttribute: Xóa bỏ thuộc tính của node hiện tại

o replaceChild: Thay thế node con của node hiện tại bằng một node mới

o createNode: Dùng để tạo ra tất cả các loại node

o createElement: = createNode với loại element node

o createTextNode: = createNode với loại text node

o createAttribute: = createNode với loại attribute node

o 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

o nodeCha.insertBefore: thêm node mới vào trước node nào đó trong danh sách node con của nodeCha

2.4 XMI (XML Metadata Interchange)

XMI là một chuẩn OMG cho việc trao đổi siêu dữ liệu (metadata) giữa các công cụ, các kho dữ liệu và các ứng dụng Nó là một chuẩn cho phép người dùng mô tả đối tượng bằng cách sử dụng XML Nó làm việc dựa trên các chuẩn như W3C XML, OMG UML

và MOF [14]

Mặc dù XML có rất nhiều ưu điểm, nhưng vẫn có một khoảng cách nhất định giữa XML với các đối tượng (objects) XML định nghĩa các phần tử XML, các thuộc tính, không phải là đối tượng Nó không cung cấp các đặc điểm của hướng đối tượng như đa thừa kế và nó không chứa mô hình đối tượng Tồn tại nhiều cách khác nhau để lưu trữ dữ liệu XML và nếu sử dụng các công cụ khác nhau để lưu trữ XML thì sẽ gây ra khó khăn trong việc trao đổi dữ liệu Khi ta lưu trữ đối tượng bằng XML cũng vậy, nếu đối tượng được lưu trữ khác nhau trong XML thì rất khó khăn để trao đổi giữa các công cụ Tuy nhiên, XMI ra chính là cầu nối liền khoảng cách giữa đối tượng và XML Nó cung cấp một chuẩn để tạo ra một ánh xạ từ một đối tượng được định nghĩa bằng UML đến XML

Trang 38

Hình 2.7 Sử dụng XMI trao đổi thông tin giữa các công cụ khác nhau

XMI được xây dựng dựa trên XML, vì vậy chúng ta hoàn toàn có thể sử dụng các API chuẩn thao tác với XML như DOM, SAX để thao tác với tài liệu XMI Trong nghiên cứu của tôi, tôi sử dụng DOM XML cho ngôn ngữ Java để thao tác với tài liệu XMI

2.5 Kết luận

Chương này giới thiệu những kiến thức cơ bản về UML, XML, XMI Đó là nền tảng

tôi sử dụng trong khóa luận để xây dựng công cụ tự động sinh mô-đun aspect kiểm chứng

mà tôi sẽ trình bày ở chương tiếp theo

Ngày đăng: 06/07/2015, 21:23

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[5] Anh-Hoang Truong, Thanh-Binh Trinh, Dang Van Hung, Viet-Ha Nguyen, Nguyen Thi Thu Trang, and Pham Dinh Hung. “ Checking Interface Interaction Protocols Using Aspect-Oriented Programming”. SEFM' 08, Cape Town, South Africa, November 10-14, 2008 Sách, tạp chí
Tiêu đề: Checking Interface Interaction Protocols Using Aspect-Oriented Programming
[7] B. Brard, M. Bidoit, A. Finkel, F. Laroussinie, A. Petit, L. Petrucci,Ph. Schnoebelen, and P. McKenzie. Systems and Software Verification Model Checking Techniques and Tools. Springer, 2001 Sách, tạp chí
Tiêu đề: Systems and Software Verification Model Checking Techniques and Tools
[8] A. Cimatti, E. Clarke, F. Giunchiglia, and M. Roveri. NuSMV: A New Symbolic Model Verifier. In 11th International Conference on Computer Aided, Verification (CAV’99), Trento, Italy, July, 2003 Sách, tạp chí
Tiêu đề: 11th International Conference on Computer Aided, Verification (CAV’99)
[9] E. M. Clarke, Jr. O. Grumberg, and D. A. Peled. Model Checking. The MIT Press, 1999 Sách, tạp chí
Tiêu đề: Model Checking
[10] A. Colyer, A. Clement, G. Harley, and M. Webster. Eclipse AspectJ:AsAspectJ Development Tools. Addison Wesley Professional Publisher, 2004 Sách, tạp chí
Tiêu đề: Eclipse AspectJ:AsAspectJ Development Tools
[11] G. Denaro and M. Monga. An Experience on Verification of Aspect Properties. In Proceedings of the 4th International Workshop on Principles of Software Evolution, 2001 Sách, tạp chí
Tiêu đề: Proceedings of the 4th International Workshop on Principles of Software Evolution
[12] O. Grumberg E. Clarke and D. Long. Verification tools for finitestate concurrent systems. In A Decade of Concurrency, volume 803 of Lecture Notes in Computer Science, page 124-175. Springer, June 1993 Sách, tạp chí
Tiêu đề: A Decade of Concurrency
[13] E. A. Emerson and J. Y. Halpern. Sometimes and Not Never revisited: On branching versus linear time temporal logic. In Journal of the ACM, volume 33(1): 151-178, 1986 Sách, tạp chí
Tiêu đề: Journal of the ACM
[14] C. Flanagan, K. Rustan, M. Leino, and R. Stata. Extended Static Checking for Java. In ACM SIGPLAN Notices, Proceedings of the ACM SIGPLAN 2002 Conference on Programming language design and implementation PLDI ’02, volume 37. ACM Press, May 2002 Sách, tạp chí
Tiêu đề: ACM SIGPLAN Notices, Proceedings of the ACM SIGPLAN 2002 Conference on Programming language design and implementation PLDI ’02
[15] M. Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Edition. Addison Wesley, 2003 Sách, tạp chí
Tiêu đề: UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Edition
[16] J. D. Gradecki and N. Lesiecki. Mastering AspectJ Aspect-Oriented Programming in Java. Wiley Publishing Inc, 2003 Sách, tạp chí
Tiêu đề: Mastering AspectJ Aspect-Oriented Programming in Java
[18] B. Hailpern and P. Santhanam. Software Debugging, Testing and Verification. IBM Systems Journal, 2002 Sách, tạp chí
Tiêu đề: Software Debugging, Testing and Verification
[19] J. Jackson. Inside the UML. Object Management Group, 1999.pect- Oriented Programming with AspectJ and the Eclipse Sách, tạp chí
Tiêu đề: Inside the UML". Object Management Group, 1999
[21] S. Krishnamurthi, K. Fisler, and M. Greenberg. Verifying Aspect Advice Modularly. Proceedings of the 12th ACM SIGSOFT twelfth international Sách, tạp chí
Tiêu đề: Verifying Aspect Advice Modularly
[20] M. Kersten. Aop tools comparison. Technical report, University of British Columbia, Feb 2005. http://www.ibm.com/developerworks Link
[6] A. D. Brucker and B. Wolff. Checking OCL Constraints in Distributed Component Based Systems. Technical report, Institut fur Informatik Albert Ludwigs University at Freibur, Germany, 2001 Khác

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w