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

ĐẠ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

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

Cán bộ hướng dẫn: Ths.Phạm Thị Kim Dung

HÀ NỘI - 2010

2

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.

3

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.

4

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

5

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

6

Danh mục ký hiệu, từ viết tắt

UML

Unified Modeling Language

Aspect-Oriented Programming

Finite State Machine

AOP

FSM

OOP

Object Oriented Programming

eXtensible Markup Language

XML Metadata Interchange

XML

XMI

DOM

Document Object Model

SEQUENCE DIAGRAM

BIỂU ĐỒ TUẦN TỰ

7

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ụ

8

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.

9

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.

10

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.

-

bản 1.1

-

Tháng 1/1997 IBM và Softteam kết hợp các thành viên UML để đưa ra phiên

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 đó.

11

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

12

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.

13

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à

14

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.

15

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.

16

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.

17

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

18

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)

19

Đ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.

20

<name>

<first-name>

Mary

</first-name>

<last-name>

McGoon

</last-name>

</name>

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

<greeting>. 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ệ.

<?xml version="1.0"?>

Hello, World!

</greeting>

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ệ:

<p>

<b>I <i>really

love</b> XML.

</i>

</p>

21

Nếu bạn bắt đầu một phần tử <i>trong một phần tử <b>, bạn cũng phải kết thúc nó ở

đó. Nếu bạn muốn các dòng chữ XMLlà chữ nghiêng, bạn cần bổ sung một phần tử thứ

hai <i>để sửa lại đánh dấu:

<p>

<b>I <i>really

love</i></b>

</p>

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 (</p>). 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.

<p>Yada yada yada...

<p>...

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 (<br>) 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:

<br />

Các phần tử là phân biệt chữ hoa/chữ thường.

22

Các phần tử XML là phân biệt chữ hoa/chữ thường. Trong HTML, <h1> và <H1>

đề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ử <h1>bằng

một thẻ </H1>, 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 :

23

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.

24

+ 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ự “<” và kết thúc bằng “>”. 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ư <section> và </section> hoặc nằm trong

một thẻ rỗng chẳng hạn như <line-break/>. 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 :

25

- 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 = {s₀, s₁, s₂, … s_n}

Tập hợp các thông điệp (không tính thông điệp trả lời) là M = {m₀, m₁, m₂, m₃… m_n}

Đầu tiên ta tạo ra trạng thái s₀, đặt nó là trạng thái khởi đầu.

Với mỗi thông điệp thứ m_i, ta tạo ra State s_{i + 1}và tạo ra Transition (s_i, m_i, s_i+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 s_ivà s_{i + 1}vào trong thông điệp m_inhư 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 m_isẽ là trạng thái nguồn của của thông điệp

m_i+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à m_ivà m_n. Ở 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 m_isẽ có nguồn là s_ivà đích là s_{i + 1}còn m_ncó nguồn là s_nvà đích là s_n

_{+ 1}Để cho dễ hình dung ta sẽ ký hiệu một thông điệp giống như một transition (s_nguồn, m,

26

s_{đích) .}Như thế, thông điệp đầu tiên ngay sau Loop là thông điệp m_n+1sẽ ký hiệu là (s_{n + 1}

m_{n + 1}, s_{n + 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 m_ntrong loop thực thi xong thì chương trình đang ở trạng thái s_{n + 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 m_ithự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 (m_i) đượ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 (s_n

_{+ 1}), Event tương ứng với m_ivà đích là đích của m_i. Tức là ta phải bổ sung thêm Transition

(s_{n + 1}, m_i, s_{i + 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 s_ivà tiếp theo

thông điệp m_{n + 1}sẽ được gọi. Do vậy ta phải thêm vào một Transition có nguồn là s_i,

Event tương ứng với m_{n + 1}và đích là trạng thái đích của m_{n + 1}. Tức là ta phải bổ sung

thêm Transition (s_i, m_{n + 1}, s_{n + 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.

27

Ở 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 (s_i, m_{n + 1}, s_{n + 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 s_{n + 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 s_{n + 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 (s_i, m_{n + 1}, s_{n + 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.

28

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.

29

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

30