Kiểm chứng tính nhất quán của hệ thống phần mềm trong quá trình tái cấu trúc

Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

1

TRƯỜNG ĐẠI HỌC HẢI PHÒNG
KHOA CÔNG NGHỆ THÔNG TIN

ĐỀ TÀI
KHÓA LUẬN TỐT NGHIỆP

Đề tài: “Kiểm chứng tính nhất quán của hệ thống phần
mềm trong quá trình tái cấu trúc “

Giảng viên hướng dẫn:

ĐÀO THỊ HƯỜNG

Sinh viên thực hiện: VŨ TUẤN ANH

Lớp

: ĐẠI HỌC CÔNG NGHỆ THÔNG TIN K13

Khoá

:

Hệ

: Chính quy

2012-2016

Hải Phòng, tháng 5 /2016

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

2

Mục Lục

Danh Sách Hình Vẽ

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

3

LỜI CẢM ƠN

Với tất cả tình cảm của mình em xin gửi lời cảm ơn chân thành tới tất cả các
thầy cô giáo trong khoa Công Nghệ Thông Tin trường Đại học Hải Phòng và
đặc biệt là cô giáo Thạc sĩ: Đào Thị Hường người đã hướng dẫn và dìu dắt em
trong suốt quá trình làm kiến tập. Cô không chỉ hướng dẫn em rất tận tình trong
việc thiết kế nội dung đề tài mà còn có những ý kiến vô cùng quý báu giúp cho
bài kiến tập của em mang tính khoa học và chính xác.
Mặc dù đã cố gắng tập trung nghiên cứu, sưu tầm, tham khảo các tài liệu và
được sự chỉ bảo, giúp đỡ tận tình của cô giáo và bạn bè song vì điều kiện kiến
thức, phương pháp còn hạn chế và ít kinh nghiệm thực tế nên bài kiến tập này
còn nhiều thiếu sót. Em mong quý thầy cô và các bạn góp ý, bổ sung để bài kiến
tập được hoàn thiện hơn.
Em xin chân thành cảm ơn!
Hải Phòng, năm 2016
Sinh viên
Vũ Tuấn Anh

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

4

LỜI MỞ ĐẦU
Ngày nay, công nghiệp phần mềm đã trở thành cơ sở hạ tầng quan trọng
của nền kinh tế toàn cầu, ứng dụng phần mềm vào tiến trình quản lý, sản xuất
của các doanh nghiệp cũng tạo ra tỷ suất lợi nhuận lớn hơn rất nhiều so với

trước đây. Trong tiến trình toàn cầu hóa này, bên cạnh sự tiến bộ về mặt công
nghệ thì việc nghiên cứu và đề xuất các thuật toán mới cũng có ý nghĩa hết sức
quan trọng. Với tốc độ phát triển của các doanh nghiệp phần mềm tại Việt Nam,
dịch vụ gia tăng chất lượng phần mềm đang là một trong những xu hướng chính
của công nghiệp phần mềm.
Cùng với quá trình vận hành, cơ chế bảo trì để đảm bảo chất lượng phần
mềm là một trong những nhân tố không thể thiếu. Yêu cầu thay đổi phần mềm
xuất hiện do sự phát sinh của các vấn đề mới về môi trường nghiệp vụ, về hiệu
năng, về độ tin cậy... Vấn đề đặt ra là phải quản lý được những thay đổi đối với
hệ thống phần mềm và tầm quan trọng của cải tiến chất lượng phần mềm.
Theo cách tiếp cận tiến hóa của quy trình phát triển phần mềm, từ một hệ
thống đơn giản ban đầu được xây dựng, quá trình tiến hóa được thực hiện một
cách liên tục cho đến khi đạt được hệ thống với các chức năng mong muốn. Ở
mỗi giai đoạn, hệ thống được mở rộng theo một yêu cầu mới hoặc một tập hợp
các yêu cầu mới. Tuy vậy, có một điều hiển nhiên rằng, không phải bản thiết kế
hệ thống ban đầu nào cũng có khả năng linh hoạt để sẵn sàng thêm các yêu cầu
mới. Do đó, một trong các yêu cầu quan trọng của các thiết kế phần mềm, chính
là sự linh hoạt, điều đó đồng nghĩa với việc, thiết kế phần mềm không chỉ đáp
ứng tốt các yêu cầu hiện tại mà còn sẵn sàng cho quá trình tích hợp những yêu
cầu mới phát sinh trong tương lại.
Một trong các kĩ thuật đang được sử dụng rộng rãi để gia tăng chất lượng
phần mềm chính là tái cấu trúc phần mềm (refactoring), quá trình tích hợp thêm
các đặc trưng của hệ thống sẽ trở nên dễ dàng hơn nếu trước đó đã thực hiện
bước tái cấu trúc. Nó làm cải tiến chất lượng của bản thiết kế.
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm

trong tiến trình tái cấu trúc

5

Mẫu thiết kế (Design Patterns) (Hunt, 2013) là một kỹ thuật trong lập trình
hướng đối tượng, được sử dụng thường xuyên trong các ngôn ngữ lập trình
hướng đối tượng. Nó cung cấp các “mẫu thiết kế”, các giải pháp để giải quyết
các vấn đề chung, thường gặp trong lập trình. Mẫu thiết kế giúp giải quyết vấn
đề một cách tối ưu nhất trong lập trình hướng đối tượng.
Trong bài thực tập tốt nghiệp này sẽ tập trung nghiên cứu tiến trình tái cấu
trúc có sử dụng các mẫu thiết kế trong tiến trình cải tiến chất lượng phần mềm.
1.
1.1

Tổng quan
Phát biểu bài toán
Trong môi trường thế giới thực, một trong những tính chất nội tại quan

trọng của hệ thống phần mềm là khả năng tiến hóa (evolve). Phần mềm cần
được cải tiến, sửa đổi, sao cho phù hợp với những yêu cầu mới, mã nguồn cũng
trở nên phức tạp hơn và có cách biệt ngày càng lớn so với thiết kế ban đầu, điều
đó, đương nhiên làm giảm chất lượng của phần mềm. Vì thế, phần lớn chi phí
cho việc phát triển phần mềm đều dành cho quá trình bảo trì [1], [2], [3]. Các
phương pháp và công cụ để cải tiến chất lượng phần mềm không giải quyết
được vấn đề này, đôi khi dẫn đến khả năng gia tăng về thời gian thực hiện cũng
như làm cho phần mềm phức tạp hơn.
Để đương đầu với vấn đề này, câu hỏi cấp thiết đặt ra cho ngành công nghệ
phần mềm là "Làm thế nào giảm độ phức tạp trong quá trình tiến hóa phần mềm
mà vẫn từng bước nâng cao được chất lượng nội bộ của phần mềm?". Lĩnh vực
nghiên cứu này được biết đến chính là kỹ thuật tái cấu trúc phần mềm

(refactoring), đặc biệt là trong phát triển phần mềm hướng đối tượng [1, 2].
Theo Tchaikovsky và Cross [3], tái cấu trúc được hiểu là "sự chuyển đổi từ
một hình thức biểu diễn này sang một hình thức biểu diễn khác, tương đương
nhau về mức độ trừu tượng, nhưng vẫn giữ nguyên hành vi bên ngoài của các
đối tượng trong hệ thống (chức năng và ngữ nghĩa). Sự chuyển dịch trong tái
cấu trúc thường là thay đổi diện mạo của chương trình, chẳng hạn như thay đổi
mã để cải thiện cấu trúc thiết kế của phần mềm. Trong khi tái cơ cấu tạo ra các
phiên bản mới mà thực hiện hoặc đề nghị thay đổi với hệ thống chủ đề, nó
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

6

không thường liên quan đến sửa đổi bởi vì các yêu cầu mới. Tuy nhiên, nó có
thể dẫn để quan sát tốt hơn của hệ thống chủ đề mà đề nghị thay đổi rằng sẽ cải
thiện các khía cạnh của hệ thống."
Tuy nhiên, một vấn đề phát sinh khi áp dụng các mẫu thiết kế trong quá
trình tái cấu trúc là chúng ta không thể đảm bảo sự nhất quán (consistency) giữa
mô hình thiết kế cũ (trước khi tiến hành tái cấu trúc) và mô hình thiết kế mới
(sau khi tiến hành tái cấu trúc). Điều này có thể dẫn đến một số tính chất đúng
đắn của hệ thống không được bảo tồn.
Một số phương pháp đã được đề xuất để kiểm tra tính nhất quán giữa các
mô hình như kỹ thuật chuyển đổi mô hình (C. Zhao), (P. Bottoni, 2003), mô tả
hệ thống bằng khung nhìn logic (R. Van Der Straeten, 2003), hoặc trao đổi siêu
dữ liệu XML. Trong nghiên cứu này sẽ đề xuất một cách tiếp cận mới để kiểm

chứng tính nhất quán trong quá trình tái cấu trúc phần mềm sử dụng các mẫu
thiết kế. Những đóng góp chính của đề tài là (1) kiểm tra tính nhất quán của các
thuộc tính và hành vi của hệ thống bằng cách xác định các tiền và hậu điều kiện
(pre/post condition) của mỗi kịch bản trong mô hình; (2) minh họa chi tiết
phương pháp đề xuất trên hệ thống cảm ứng kiểm soát lưu lượng giao thông
đường bộ (Adaptive Road Traffic Control System - ARTCs (K.Ranjini, 2011)).
1.2 Kiến thức cơ sở
1.2.1
Tái cấu trúc phần mềm
Khái niệm tái cấu trúc (refactoring) được giới thiệu lần đầu trong luận án
tiến sĩ của Opdyke [1]. Tái cấu trúc là biến thể của tái cơ cấu (restructuring),
Opdyke định nghĩa về tái cấu trúc như sau: "Tái cấu trúc là tiến trình làm thay
đổi cấu trúc bên trong của hệ thống phần mềm mà không ảnh hưởng đến các
hành vi bên ngoài của hệ thống". Ý tưởng chính trong tái cấu trúc là phân bố lại
các lớp (classes), các biến (variables), và các phương thức trên mối quan hệ
phân cấp giữa các lớp nhằm tạo thuận lợi cho nhu cầu mở rộng và thích nghi của
hệ thống trong tương lai.
Trong bối cảnh của sự tiến hóa phần mềm, chuyển dịch cơ cấu
(restructuring) và tái cấu trúc (refactoring) được sử dụng để cải thiện chất lượng
của phần mềm (ví dụ, khả năng mở rộng, mô đun hóa, tái sử dụng, bảo trì, tính
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

7

hiệu quả...). Tái cấu trúc và tái cơ cấu cũng được sử dụng trong kĩ nghệ tái tạo
phần mềm (reengineering), đó là kiểm tra và thay đổi một hệ thống đối tượng để
pha nó trong một hình thức mới và thực hiện tiếp theo các hình thức mới. Trong
bối cảnh này, việc tái cơ cấu là cần thiết để chuyển đổi mã di sản hoặc mã đã bị
suy thoái thành hơn mô-đun hoặc có cấu trúc hình thức, hoặc thậm chí di chuyển
mã để một ngôn ngữ lập trình khác nhau hoặc ngay cả ngôn ngữ mô hình.

1.2.2

Mẫu thiết kế
Trong công nghiệp phát triển phần mềm hiện đại, một trong những mục

tiêu quan trọng là khả năng mở rộng và bảo trì của hệ thống phần mềm. Để đạt
được tiêu chí đó, thì cần có bản thiết kế phần mềm tốt. Bản thiết kế đó không chỉ
giải quyết các trường hợp cụ thể, mà còn có thêm khả năng mở rộng. Có nhiều
kỹ thuật để hỗ trợ cho việc xây dựng một thiết kế tốt, trong đó việc ứng dụng
các Mẫu thiết kế (Design Patterns) đang được sử dụng rộng rãi. Đối với một tình
huống thiết kế cụ thể được đưa ra, các Mẫu thiết kế cung cấp một khuôn mẫu
chung để giải quyêt tình huống đó. Nói cách khác, Mẫu thiết kế cung cấp giải
pháp cho các vấn đề thiết kế phổ biến. Trong lập trình hướng đối tượng (Object
Oriented Programming), các mẫu thiết kế giải quyết các vấn đề về kế thừa và
tương tác nói chung, chứ không phải là vấn đề về kiến trúc tổng thể trong quy
mô lớn.
Điểm kỳ diệu của các mẫu thiết kế là khả năng dễ dàng tái sử dụng, dễ mở
rộng và bảo trì. Nếu ta có một thiết kế không tốt, khi gặp vấn đề phát sinh, phần
mềm đó không có khả năng tái sử dụng và bảo trì, sẽ phải dành nhiều thời gian,
thậm chí là nhiều hơn cả thời gian bỏ ra xây dựng, chỉ là để sửa chữa chúng.
Các mẫu thiết kế trong cuốn sách nổi tiếng của GOF [4] được phân loại
thành ba nhóm, cụ thể là (1) nhóm các mẫu khởi tạo (creational patterns), (2)
nhóm các mẫu cấu trúc (structural patterns), (3) và nhóm các mẫu hành

vi(behavioral patterns). Nhóm đầu tiên, cung cấp cách thức để tạo ra một hoặc
nhóm đối tượng. Các mẫu trong nhóm thứ hai dùng để thiết lập, định nghĩa quan

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

8

hệ giữa các đối tượng. Nhóm mẫu cuối cùng xác định cách cư xử giao tiếp giữa
các lớp và các đối tượng.
Trong phần này, sẽ trình bày chi tiết một mẫu trong nhóm hành vi, cụ thể là
mẫu chiến lược (Strategy), mẫu này sẽ được ứng dụng cụ thể vào mô hình minh
họa trong phần 3. Nói cách khác, mẫu chiến lược “Định nghĩa một tập hợp các
thuật toán, đóng gói chúng thành từng loại một, và giúp chúng có thể hoán đổi
cho nhau". Mẫu chiến lược thực thi các thuật toán một cách linh động, tùy thuộc
vào ngữ cảnh cụ thể. Ý nghĩa thực sự của mẫu chiến lược là chúng ta tách rời
phần xử lý một chức năng ra khỏi đối tượng. Sau đó tạo ra một tập hợp các thuật
toán để xử lý chức năng đó và cho phép lựa chọn thuật toán đúng đắn nhất khi
thực thi chương trình. Mẫu thiết kế này thường được sử dụng để thay thế cho sự
kế thừa, khi muốn chấm dứt việc theo dõi và chỉnh sửa một chức năng qua nhiều
lớp con.

Hình 1: Mẫu chiến lược (Strategy)

Mẫu chiến lược trên Hình 1 bao gồm các thành phần sau:

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

•

9

IStrategy: Giao diện (Interface) được chia sẻ giữa các lớp con cụ thể
trong họ các thuật toán. Lớp Context sử dụng giao diện để gọi đến
các thuật toán đã được định nghĩa trong các lớp con.

•

ConcreteStrategy: Nơi các thuật toán được cài đặt cụ thể.

•

Context: Lớp dùng để tham chiếu đến kiểu ISstrategy.
Trong một số trường hợp, Context có thể cài đặt các
phương thức bởi vậy các lớp ConcreteStrategy có thể truy
cập đến các dữ liệu này.
1.2.3

Ngôn ngữ mô hình hóa thống nhất – UML(Unified Modeling

Language)
UML[10] là ngôn ngữ mô hình hóa thống nhất với các ký hiệu trực quan,
được các phương pháp hướng đối tượng sử dụng để thể hiện và miêu tả các thiết
kế của hệ thống. Nó là một ngôn ngữ để đặc tả, trực quan hóa, xây dựng và làm
tài liệu cho nhiều đối tượng khác nhau. UML[10] có thể làm công cụ giao tiếp
giữa người dùng, nhà phân tích, nhà thiết kế và nhà phát triển phần mềm.


Mục đích của UML

• Mô hình hóa 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ự việc cần mô hình

hóa.
• 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 hóa có thể sử dụng được bởi người và máy.


Miền ứng dụng của UML

UML[1] có thể được sử dụng trong nhiều giai đoạn từ phát triển, thiết kế, thực
hiện và bảo trì .
• Hệ thống thông tin (Infomation system) : Cất giữ, lấy, biến đổi thông tin cho

người sử dụng. Xử lý những khoảng dữ liệu lớn có quan hệ phức tạp, mà chúng
được lưu trữ trong các cơ sở dữ liệu quan hệ hay hướng đối tượng.
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

10

• Hệ thống kỹ thuật (Technical system): Xử lý và điều khiển các thiết bị viễn

thông, hệ thống quân sự hay quá trình công nghiệp. Đây là loại thiết bị phải xử
lý các giao tiếp đặc biệt, không có giao giao diện chuẩn và thường là các hệ
thống thời gian thực.
• Hệ thống nhúng (Embeded system): Thực hiện trên các thiết bị phần cứng trên ô

tô, thiết bị di động...Điều này được thực hiện với lập trình mức thấp với hỗ trợ
thời gian thực.
• Hệ thống phân bố (Distributed system): Được phân bố trên một số máy cho

phép truyền dữ liệu từ nơi này đến nơi khác một cách dễ dàng. Chúng đòi hỏi
các cơ chế liên lạc đồng bộ để bảo đảm toàn vẹn dữ liệu. Thường được xây dựng
trên một số kỹ thuật hướng đối tượng như CORBA, COM/DCOM.
• Hệ thống giao dịch (Bussiness system): Mô tả mục đích, tài nguyên, các quy tắc

và công việc kinh doanh.
• Phần mềm hệ thống (System software): Định nghĩa cơ sở hạ tầng kỹ thuật cho

phần mềm khác sử dụng chẳng hạn như hệ điều hành, cơ sở dữ liệu,...


Hệ thống biểu đồ trong UML
Biểu đồ Use case (Use case Diagram)
Biểu đồ lớp (Class Diagram)
Biểu đồ đối tượng (Object Diagram)
Biểu đồ trạng thái (State Diagram)
Biểu đồ trình tự (Sequence Diagram)
Biểu đồ cộng tác (Collaboration Diagram)
Biểu đồ hoạt động (Activity Diagram)
Biểu đồ thành phần (Component Diagram)
Biểu đồ triển khai (Deployment Diagram)
1.2.4

Ngôn ngữ ràng buộc dối tượng OCL(Object Constraint

Language)
Trong quá trình phát triển phần mềm người ta nhận ra rằng, chỉ với hệ
thống ký hiệu trực quan trong UML[10] không thể đặc tả được hết các khía
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

11

cạnh thực tế của hệ thống phần mềm. Chính vì thế, OCL[9] được xây dựng và
phát triển với mục đích bổ sung cho các đặc tả UML trở nên rõ ràng và chính

xác hơn. Và OCL trở thành chuẩn ngôn ngữ đặc tả cho các biểu đồ trong
UML[10] trong thực tế. Trong phần này chúng ta quan tâm chủ yếu tới cách
thức biểu diễn đặc tả OCL[9] trên biểu đồ lớp, tập trung vào biểu diễn các ngữ
cảnh, các bất biến, tiền điều kiện, hậu điều kiện cho phương thức.

OCL được sử dụng
Giống như một ngôn ngữ truy vấn
Các biểu thức OCL có thể được sử dụng trong mọi mô hình UML để biểu
diễn giá trị. Giá trị biểu diễn của nó có thể là một giá trị kiểu cơ sở hay tham
chiếu tới đối tượng.
Mô tả sự bất biến trong các lớp và các kiểu bên trong các mô hình lớp
Một bất biến trong lớp và các kiểu bên trong lớp là một ràng buộc luôn
luôn đúng. Mô tả sự bất biến cho lớp và các kiểu bên trong lớp chính là xác định
những ràng buộc tổng quát cho lớp và các kiểu bên trong mô hình lớp.
Đặc tả bất biến kiểu cho mẫu – stereotypes.
Mô tả tiền điều kiện và hậu điều kiện trong các phương thức.
Đặc tả các ràng buộc của thuộc tính lớp, các phương thức.

Đặc tả OCL trên biểu đồ lớp
- Khai báo ngữ cảnh
OCL là một ngôn ngữ hình thức, chúng được biểu diễn dưới dạng biểu
thức.Biểu thức OCL dùng để đặc tả cho UML luôn luôn phải gắn liền với một
đối tượng trong mô hình UML. Do vậy trước khi tiến hành biểu diễn biểu thức
OCL chúng ta phải khai báo ngữ cảnh mà biểu thức OCL tham gia.
Cú pháp khai báo một ngữ cảnh :
Khai báo một ngữ cảnh bắt đầu bằng từ khóa context và tiếp đến là tên ngữ
cảnh. Ví dụ khai báo ngữ cảnh có tên là Bank: context

Bank

Sử dụng “--” để viết chú thích cho biểu thức OCL, nó giống như “//” trong C++.
Từ khóa selt
Biểu thức OCL luôn được đặt trong một ngữ cảnh cụ thể, và để chỉ ra thể hiện
của đối tượng trong ngữ cảnh đó chúng ta sử dụng từ khóa seft.
-

Khai báo một bất biến - invariant

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

12

Một ràng buộc bất biến là một ràng buộc được liên kết tới một lớp cụ thể trong
một ngữ cảnh cụ thể. Mục đích của một ràng buộc bất biến là chỉ rõ sự bất biến
tại một khía cạnh nào đó của lớp. Một ràng buộc bất biến chứa một biểu thức
OCL. Biểu thức này phải đúng cho mọi thể hiện của phân loại lớp tại mọi thời
điểm. Chỉ khi một thể hiện thực thi một phép toán thì không cần đánh gía biểu
thức này là đúng.
Cú pháp khai báo một bất biến:
Khai báo một bất biến bắt đầu với từ khóa inv, tiếp đến là tên của bất biến.
Ví dụ :

context Company --khai báo ngữ cảnh có tên là Company
inv

:

seft.

numberOfEmployees

>

50

--Khai báo một bất biến.
Ý nghĩa : Mọi thể hiện của đối tượng Company phải thỏa mãn ràng buộc
numberOfEmployees > 50 tại mọi thời điểm.
Từ khóa seft tham chiếu tới thể hiện của đối tượng Company, sử dụng toán tử
“.” để chỉ tới thuộc tính numberOfEmployees của đối tượng Company.
-

Tiền điều kiện và hậu điều kiện – pre & post condition

Tiền điều kiện và hậu điều kiện là các ràng buộc liên kết tới phương thức của
một phân loại lớp. Mục đích của tiền điều kiện là chỉ rõ điều kiện phải có trước
khi phương thức thực thi. Tiền điều kiện chứa một biểu thức OCL (trả về kết
quả Boolean). Biểu thức OCL này phải được đánh giá là đúng bất cứ khi nào
phương thức bắt đầu thực thi, nhưng việc đánh giá này chỉ áp dụng cho thể hiện
thực thi phương thức.Mục đích của hậu điều kiện là chỉ rõ điều kiện phải có sau
khi thực thi phương thức. Hậu điều kiện cũng được biểu diễn bằng một biểu
thức OCL (trả về kết quả Boolean). Việc đánh giá biểu thức OCL tại thời điểm
kết thúc thực thi phương thức. Bên trong ràng buộc tiền điều kiện không sử
dụng toán tử @pre nhưng bên trong ràng buộc hậu điều kiện có thể sử dụng

@pre để tham chiếu tới giá trị của tiền điều kiện.
Cú pháp:
context Typename::operationName(para1: Type1, para2 : Type2,...)
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

13

Return Type
pre: Khai báo các tiền điều kiện
post: Khai báo các hậu điều kiện hoặc:
context Typename::operationName(para1 : Type1, para2 : Type2,...)
Return Type
pre preconditionName : Khai báo tiền điều kiện
post postconditionName: Khai báo hậu điều kiện
Ví dụ:
context Person::income(d : Date)
Return interger
pre preOK: d > 0
Tiền điều kiện: đảm bảo d > 0

post postOK: result > 5000

Hậu điều kiện đảm bảo trả về kết quả > 5000.
1.2.5

Ngôn ngữ mô hình hóa Java - JML(Java Modeling

Language)
JML (Java Modeling Language) là ngôn ngữ đặc tả hành vi, được sử
dụng để đặc tả hành vi của các mô đun trong ngôn ngữ Java. JML là sự kết hợp
phương pháp thỏa thuận với phương pháp đặc tả dựa trên mô hình của ngôn
ngữ Larch. JML sử dụng logic Hoare kết hợp với việc đặc tả các tiền/
hậu điều kiện (pre-/post-condition) và các bất biến (invariant) của các thuộc
tính, các cấu trúc.
Các đặc tả JML được thêm vào mã Java dưới dạng các chú giải
(annotation)
bên trong các chú thích (comment). Các chú thích trong ngôn ngữ Java được
hiểu như là các chú giải JML khi nó bắt đầu bằng ký tự “@”.
public class purse
{
final int MAX BALANCE;
int balance;
//@ invariant 0 <= blance && blance <= MAX BALANCE;
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

14

byte[] pin;

/*@ invariant pin!= null && pin.length == 4 &&
(forall int i; 0<=i&&i<=4;0<=pin[i]&&pin[i]<=9);
*/
/* requires amount >=0
@ assignable balance;
@ ensures
balance==\old(balance)-amount && \result == balance;
@ signals (PurseExeption) blance==\old(balance); */
int debit(int amount) throws purseException
}

Trong đoạn code trên minh họa việc sử dụng JML đặc tả cho lớp Purse.
Trong đó, trường balance được đặc tả với bất biến (invariant) là balance
luôn trong đoạn từ 0 đến Phương thức debit nhận vào đối số amount. Phương
thức này sẽ trừ amount vào balance và trả về giá trị của balance sau khi
trừ trong trường hợp balance lớn hơn hoặc bằng amount. Trong trường hợp
balance nhỏ hơn amount, một ngoại lệ PurseException sẽ được trả về.
Tiền điều kiện (requires) của phương thức này là amount phải lớn hơn hoặc
bằng 0; hậu điều kiện (ensures) là balance bị trừ đi một lượng amount và trả
về kết quả sau khi trừ. Phương thức này còn có một hậu điều kiện nữa cho
trường hợp phương thức trả về ngoại lệ (signals).
Trong đề tài này em xin giới thiệu một công cụ

2.

Phương pháp kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc.
Trong phần này sẽ trình bày phương pháp dùng trong kiểm chứng tính nhất

quán giữa các mô hình hệ thống phần mềm (mô hình trước và sau khi tái cấu

trúc). Phương pháp kiểm chứng sẽ được trình bày một cách tổng quan, sau đó,
từng bước kiểm chứng sẽ được trình bày một cách chi tiết. Cuối cùng là ví dụ về
Hệ thống kiểm soát lưu lượng giao thông đường bộ (Adaptive Road Traffic
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

15

Control - ARTC) sẽ được sử dụng làm ví dụ minh họa cho phương pháp đã trình
bày.
2.1

Tổng quan về phương pháp kiểm chứng
Như trên đã trình bày, việc áp dụng các mẫu thiết kế trong tiến trình tái cấu

trúc phần mềm sẽ làm thay đổi cấu trúc thiết kế bên trong của hệ thống mà vẫn
giữ nguyên các hành vi cần thiết của phần mềm. Điều này được thực hiện nhằm
mục đích làm cho phần mềm dễ hiểu hơn, dễ sửa chữa thay đổi hơn mà không
làm tốn quá nhiều chi phí... Như một hệ quả tất yếu, chúng ta cần phải kiểm
chứng sự nhất quán về mặt hành vi giữa mô hình gốc (initial model) và mô hình
sau khi đã tái cấu trúc (evolution model). Phương pháp kiểm chứng bao gồm ba
tiến trình cơ bản, (1) mô hình hóa hệ thống phần mềm, (2) thực hiện tái cấu trúc,
và (3) tiến trình kiểm chứng tính nhất quán giữa hai hệ thống.
Ngôn ngữ mô hình hóa thống nhất UML (Unified Modeling Language)
được công nhận là chuẩn công nghiệp vào năm 1997, từ đó đến nay nó được sử

dụng phổ biến bởi rất nhiều các nhà nghiên cứu. Trong bài này cũng sẽ sử dụng
UML đề mô hình hóa hệ thống phần mềm thành một mô hình hình thức (formal
model). Đây chính là bước mô hình hóa hệ thống. Cụ thể hơn, trong bước mô
hình hóa này, biểu đồ lớp (class diagram) được sử dụng để mô tả các lớp và mối
quan hệ giữa chúng. Biểu đồ tuần tự (sequence diagram) sẽ được sử dụng để mô
tả hành vi của hệ thống, mỗi biểu đồ tuần tự được coi như một kịch bản
(scenario) thực thi một tiến trình nào đó, do vậy hệ thống có thể bao gồm một
hoặc một tập hợp các kịch bản.
Mô hình tiến hóa (evolution model) là kết quả của quá trình áp dụng các
mẫu thiết kế trong tiến trình tái cấu trúc hệ thống. Với mỗi mô hình thiết kế cụ
thể, việc lựa chọn mẫu thiết kế nào để áp dụng đóng một vai trò quan trọng
trong việc cải tiến tính linh hoạt của phần mềm.
Để phục vụ cho mục tiêu kiểm chứng tính nhất quán giữa các mô hình phần
mềm trước và sau khi tái cấu trúc, một tập luật dần dần được xây dựng. Các
hành vi cần kiểm chứng của hệ thống được biểu diễn bằng ngôn ngữ ràng buộc
đối tượng OCL (Object Constraint Language), nó bao gồm (1) các bất biến, (2,
3) tiền và hậu điều kiện của các đối tượng có trong hệ thống. Cuối cùng, sau quá

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

16

trình thực hiện kiểm chứng, hệ thống sẽ trả lại kết quả nhất quán (bảo tồn) hoặc
không nhất quán (không bảo tồn) các hành vi của hệ thống.

Hình 2: Tổng quan về phương pháp kiểm chứng
2.2

Mô hình hóa hệ thống bằng UML
Ngôn ngữ mô hình hóa thống nhất UML cung cấp khá nhiều công cụ (biểu

đồ) để mô hình hóa các khía cạnh khác nhau của hệ thống phần mềm. Trong đó,
sơ đồ trình tự được sử dụng để miêu tả hành vi của các chức năng chính của hệ
thống. Bên cạnh đó, ngôn ngữ ràng buộc đối tượng OCL được sử dụng để giải
quyết các yêu cầu phi chức năng (các ràng buộc mà phần tử UML cần thỏa mãn)
để thực hiện các yêu cầu chức năng. Các ràng buộc này được chia thành ba loại

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

17

chính, (1) các bất biến (invariants) trên các thuộc tính của lớp, (2,3) tiền và hậu
điều kiện (pre/postcondition) áp dụng đối với các phương thức của lớp.
Bất biến (Invariant): bất biến được định nghĩa trên các thuộc tính của lớp, là
điều kiện mà mọi thể hiện (instance) của lớp đó phải thỏa mãn.
Tiền điều kiện (Precondition): tiền điều kiện của một phương thức là các điều
kiện mà phương thức đó phải thỏa mãn trước khi nó được thực thi.
Hậu điều kiện (Postcondition): hậu điều kiện của một phương thức là các điều

kiện mà phương thức đó phải thỏa mãn sau khi nó được thực thi.


Trong đề tài này sẽ đưa vào thêm hai loại ràng buộc được định nghĩa
trên kịch bản (Scenario) của mô hình hệ thống phần mềm.

Tiền điều kiện của kịch bản (Scenario precondition): Tiền điều kiện của một
kịch bản là các điều kiện mà tất cả các thuộc tính của các lớp có tham gia vào
kịch bản phải thỏa mãn trước khi kịch bản đó được thực thi.
Hậu điều kiện của kịch bản (Scenario postcondition): Hậu điều kiện của một
kịch bản là các điều kiện mà tất cả các thuộc tính của các lớp có tham gia vào
kịch bản phải thỏa mãn sau khi kịch bản đó được thực thi.
 Các thành phần của hệ thống được mô hình hóa một cách tuần tự dựa
trên các định nghĩa sau đây:
Định nghĩa 1 (Mô hình): Một mô hình M là một bộ 2 phần tử {CM,SM}, trong
đó CM là tập hợp các lớp và SM là tập hợp hành vi của các kich bản có trong mô
hình.
Định nghĩa 2 (Lớp): Một lớp CiM ∈ CM được biểu diễn bởi bộ-3 CiM = {OPCiM,
ACiM, ICiM}, ở đây OPCiM là tập hợp các phương thức công khai, ACiM là tập hợp
các thuộc tính công khai, và ICiM là tập trạng thái các bất biến của lớp.
Định nghĩa 3 (Tiền điều kiện của phương thức trừu tượng): Tiền điều kiện
PREopiM của phương thức opei, được hiện thực hóa bởi N phương thức opei trong
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

18

các lớp con CksiM, trong lớp trừu tượng CiM được tính bằng hợp tiền điều kiện
của tất cả các phương thức opei trong các lớp con CksiM.
Giả sử Pi(opei) biểu diễn tiền điều kiện của phương thức opei trong các lớp
∨

con, khi đó chúng ta tính tiền điều kiện theo công thức PREopiM = Pi(opei) cho
phương thức opei trong lớp trừu tượng CiM, ở đây opei ∈ CksiM là các phương
thức hiện thực hóa, và P là mệnh đề.
Định nghĩa 4 (Hậu điều kiện của phương thức trừu tượng): Hậu điều kiện
POSTopiM của phương thức opei, được hiện thực hóa bởi N phương thức opei trong
các lớp con CksiM, trong lớp trừu tượng CiM được tính bằng hợp hậu điều kiện
của tất cả các phương thức opei trong các lớp con CksiM.
Tương tự như cách tính tiền điều kiện của phương thức trong lớp trừu
tượng, dễ thấy POSTopiM =

∨

Pi(opei), ở đây opei ∈ CksiM là các phương thức hiện

thực hóa, và P là các mệnh đề biểu diễn hậu điều kiện của các phương thức opei
trong các lớp con.
Hành vi của một mô hình phần mềm được biểu diễn thông qua hành vi của
các kịch bản có trong mô hình. Trong bài này, mỗi một kịch bản của hệ thống
tương ứng với một biểu đồ tuần tự trong UML.
Định nghĩa 5 (Kịch bản): Một kịch bản SiM được biểu diễn bởi bộ-4
SiM = {CISiM, PRESiM, ESiM, POSTSiM}, trong đó CISiM ⊆ CiM biểu diễn cho tập hợp
các lớp tham gia vào kịch bản, PRESiM là tiền điều kiện của kịch bản, ESiM là tập
có thứ tự các phương thức trong các lớp được thực thi trong kịch bản, và

POSTSiM là hậu điều kiện của kịch bản đó.
Định nghĩa 6 (Phương thức của kịch bản): Một phương thức của kịch bản là
một bộ-4

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

19

là EkSiM = {PREEkSiM,OPEkSiM, POSTEkSiM,k}, trong đó PREEkSiM là tiền
điều kiện của phương thức, OPEkSiM là các phương thức công khai thực thi trong
kịch bản, POSTEkSiM là hậu điều kiện của các phương thức, và k là thứ tự thực
hiện của phương thức trong kịch bản.
Trong đề tài này, chúng ta xem xét trường hợp mà cả tiền và hậu điều kiện
của một phương thức là sự kết hợp của các vị từ trên các thuộc tính của các lớp
tham gia vào kịch bản, ví dụ, PREEkSiM =

∨

P(ACijM), ở đây ACijM ∈ ACiM là thuộc

tính, CiM ⊆ CISiM và P là vị từ. Một kịch bản bao gồm một chuỗi các hoạt động,
do đó tiền và hậu điều kiện của một phương thức được hình thành bởi biểu thức
tiền và hậu điều kiện của phương thức thực hiện ngay trước đó. Lưu ý rằng, một
phương thức công khai của một lớp trong các kịch bản khác nhau có thể có tiền

và hậu điều kiện khác nhau. Tiền và hậu điều kiện của một kịch bản được xác
định dựa trên tiền và hậu điều kiện của tất cả các phương thức có tham gia và
kịch bản. Và được định nghĩa như sau:
Định nghĩa 7 (Tiền điều kiện của kịch bản): Tiền điều kiện của một kịch bản
PRESiM được xác định bởi tiền điều kiện của phương thức đầu tiên thực thi trong
kịch bản đó.
Tiền điều kiện của phương thức đầu tiên trong kịch bản được đặc bởi các
ràng buộc trên tất cả các .
Định nghĩa 8 (Hậu điều kiện của kịch bản): Hậu điều kiện của một kịch bản
POSTSiM được xác định bởi hợp của các ràng buộc trên các thuộc tính công
khai
ACijM của hậu điều kiện của phương thức POSTEkSiM diễn ra sau cùng trong ESiM.
Cho một kịch bản S = (e1,e2,..en), trong đó ei, i = 1..n, là phương thức thứ i
thực thi trong kịch bản. Theo định nghĩa 6, chúng ta có ei = (preei, opei, postei, i)
và post(ei) = VPk(AkC), ở đây Pk là các logic vị từ AkC, biểu diễn cho thuộc tính
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

20

của các lớp C có liên quan đến kịch bản này. Giả sử rằng kịch bản S chỉ có duy
nhất một thuộc tính công khai AC cùng xuất hiện trong biểu thức hậu điều kiện
của ei và ej sao cho 1 ≤ i < j ≤ n. Như vậy, chúng ta sẽ có postei = Pi(AC) và postej
= Pj(AC). Nếu ei thực thi trước ej, Pj(AC) cần phải được duy trì cho đến khi
phương thức thứ j được thực thi.

Định nghĩa 9 (Tái cấu trúc): Một tiến trình tái cấu trúc R sử dụng mẫu thiết kế
D được biểu diễn như sau: R: M

D(SU BMS)

M’ trong đó M và M’’ theo thứ tự

biểu thị cho các mô hình trước và khau khi thực hiện tái cấu trúc, D là tên của
mẫu thiết kế được ứng dụng, và SUBMS ⊆ SM là tập các kịch bản tham gia vào
tiến trình tái cấu trúc này.

2.3

Kiểm tra tính nhất quán của mô hình tiến hóa
Trong phần này sẽ thảo luận về vấn đề kiểm chứng tính nhất quán của mô

hình phần mềm sau khi áp dụng các mẫu thiết kế. Nhằm giảm độ phức tạp cho
quá trình kiểm chứng, các thuộc tính cần kiểm chứng sẽ được phân thành hai
loại (1) Các thuộc tính tĩnh (static), và (2) các thuộc tính động ( dynamic ). Đối
với loại thuộc tính thứ nhất, phương pháp kiểm chứng dựa trên các bất biến của
lớp, với loại thuộc tính thứ hai, quá trình kiểm chứng sẽ thao tác trên tiền/hậu
điều kiện của các kịch bản.
Quá trình kiểm chứng sẽ được thực hiện một cách lần lượt, dựa trên sự tuân
thủ các Mệnh đề chi tiết sau đây.
2.3.1
Kiểm chứng các thuộc tính tĩnh

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13

Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

21

Việc áp dụng các mẫu thiết kế trong tái trúc phần mềm thường dẫn đến
thay đổi các cấu trúc bên trong của mô hình. Tuy nhiên, luôn có một vài các
ràng buộc tĩnh cần được duy trì trong suốt tiến trình này. Bài này đề xuất kiểm
chứng các thuộc tính tĩnh dựa trên khái niệm bất biến của lớp (class invariants).
Trong trường hợp đặc biệt, nếu các lớp tham gia và tiến trình tái cấu trúc của mô
hình không bị thay đổi, điều hiển nhiên các bất biến của các lớp đó sẽ được duy
trì.
Mệnh đề 1 (Bảo tồn các tính chất tĩnh): Quá trình tái cấu trúc một mô hình
phần mềm được coi là bảo tồn các thuộc tính tĩnh nếu các bất biến của các lớp
trên mô hình hiện tại tương đương logic với các bất biến của các lớp trên mô
hình ban đầu.
Chúng ta có thể hình thức hóa mệnh đề trên cụ thể như sau.
Cho R: M

D(SU BMS)

M’ là mô hình được tái cấu trúc, R được coi là bảo

tồn các tính chất tĩnh nếu: ∀CiM | CiM ∈ CM ∧ CiM ∈ C’M =⇒ ICiM ≡ IciM

2.3.2

Kiểm chứng các tính chất động

Yêu cầu quan trọng đối với tiến trình tái cấu trúc sử dụng các mẫu thiết kế

là sự không thay đổi (bảo tồn) các hành vi bên ngoài của mô hình phần mềm.
Trong chuyên đề này, các hành vi của hệ thống được mô tả thông qua các kịch
bản (scenario). Bởi vậy, chúng ta cần phải kiểm tra liệu tập hợp các kịch bản
tham gia vào tiến trình tái cấu trúc có bảo tồn các hành vi của nó hay không.
(Total dynamic consistency).
Mệnh đề 2 (Nhất quán toàn phần trên các thuộc tính động): Một tiến trình
tái cấu trúc trên mô hình phần mềm được gọi là nhất quán toàn phần trên các
thuộc tính động (với mô hình ban đầu), nếu với mỗi kịch bản trên mô hình hiện
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

22

tại, tiền và hậu điều kiện của nó đều tương đương logic với tiền và hậu điều kiện
của kịch bản tương ứng trên mô hình ban đầu.
Một cách hình thức hóa, cho R: M

M’ là một tiến trình tái cấu

trúc, SiM ∈ SUBMS gọi là nhất quán toàn phần trên các thuộc tính động, nếu
PRESiM ≡ PRESiM’ ∧ POSTSiM ≡ POSTSiM’. Trong phần 2.2, chúng ta đã chỉ ra tiền
D(SU BMS)

và hậu điều kiện của các kịch bản được suy dẫn bởi các phương thức tham gia
vào kịch bản, bởi vậy nếu PRESiM ≡ PRESiM’ ∧ POSTSiM ≡ POSTSiM’, tất cả các
ràng buộc trên các thuộc tính công khai của các kịch bản sau tái cấu trúc sẽ được
bảo tồn.
Mệnh đề 3 (Nhất quán bộ phận trên các thuộc tính động): Một tiến trình tái
cấu trúc mô hình phần mềm được gọi là nhất quán bộ phận trên các thuộc tính
động (so với mô hình ban đầu) nếu tiền điều kiện của các kịch bản trên mô hình
hiện tại ( mô hình sau khi đã tái cấu trúc) không hề thay đổi, hậu điều kiện của
các kịch bản chỉ thỏa mãn một phần so với tiền/hậu điều kiện của các kịch bản
tương ứng trong mô hình gốc.
Tương tự như trên, chúng ta có thể hình thức hóa tiến trình nhất quán bộ phận
D(SU BMS)

trên các thuộc tính động như sau. Cho R: M

M’ là một tiến trình tái

cấu trúc, SiM ∈ SUBMS được gọi là nhất quán một phần nếu như PRESiM ≡
PRESiM’∧ POSTSiM =⇒ POSTSiM0. Trong trường hợp này, nếu POSTSiM =⇒
POSTSiM’, như vậy giá trị của các ràng buộc trên các kịch bản của các thuộc tính
cộng khai vẫn nằm trong phạm vi mong muốn.
Mệnh đề 4 (Không nhất quán): Một tiến trình tái cấu trúc mô hình phần mềm
được gọi là không nhất quán nếu nó đồng thời không thỏa mãn cả nhất quán
toàn phần và nhất quán bộ phận trên các thuộc tính động.
Cho R: M

D(SU BMS)

M’ là một tiến trình tái cấu trúc, SiM ∈ SUBMS là không nhất

quán nếu SiM không thỏa mãn nhất quán một phần (đương nhiên nó cũng không
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

23

thể thỏa mãn nhất quán toàn phần). Trong trường hợp này, giá trị của các ràng
buộc trên các thuộc tính công khai của kịch bản bị vi phạm sau tiến trình tái cấu
trúc.
Để minh họa cho phương pháp kiểm chứng đã đề xuất trong phần này sẽ đưa ra
một ví dụ, minh họa chi tiết quá trình kiểm chứng trong phần tiếp theo.

3

Ví dụ minh họa
Tắc nghẽn giao thông là một vấn đề ngày càng tăng tại các thị trấn và thành

phố trên toàn thế giới. Chính quyền địa phương phải liên tục làm việc để tối đa
hóa hiệu năng sử dụng của mạng lưới đường bộ và giảm thiểu bất kỳ sự gián
đoạn nào (gây ra bởi tai nạn hoặc các sự kiện bất thường,...) Trong bài này, sẽ sử
dụng tài liệu phân tích và thiết kế hệ thống Kiểm soát lưu lượng giao thông
đường bộ (Adaptive Road Traffic Control - ARTC) để minh họa cho phương
pháp kiểm chứng đã được đề xuất trong phần 2.3.
3.1 Mô tả hệ thống ARTC
Trong hệ thống này, một máy tính trực tuyến được sử dụng để liên tục

giám sát giao thông lưu lượng giao thông của các khu vực khác nhau (máy tính
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc

24

này nhận tín hiệu truyền về từ các máy dò (detector) đặt trên đường phố), máy
tính này cũng được sử dụng như là mô hình tín hiệu đầu vào để các bộ tối ưu
thực thi trên hệ thống. Những bộ tối ưu thực hiện một loạt các điều chỉnh nhỏ
thường xuyên để báo hiệu thời gian nhằm mục tiêu đảm bảo lưu thông hiệu quả
nhất trên toàn mạng lưới.
Nó phối hợp hoạt động của tất cả các tín hiệu giao thông ở một khu vực để
cung cấp thông tin tối ưu nhất cho các loại xe lưu thông qua mạng lưới giao
thông. Trong khi phối hợp tất cả các tín hiệu, nó đáp ứng một cách thông minh
và liên tục các thay đổi lưu lượng giao thông và dao động suốt ngày.
Khi phương tiện giao thông đi qua các máy dò, hệ thống sẽ nhận được các
thông tin và chuyển đổi dữ liệu thành tín hiệu nội bộ và sử dụng chúng để xây
dựng "Cyclic flow profiles" cho mỗi đường đi trên mạng lưới giao thông.
Phương tiện đi lại sẽ di chuyển với một tốc độ bình thường và tham gia trở lại
hàng đợi nếu gặp tín hiệu đèn đỏ trên đường.
Các dữ liệu từ mô hình sau đó được sử dụng bởi ba bộ tối ưu, các bộ tối ưu
này liên tục được tùy chỉnh bởi ba thông số điều khiển giao thông trọng điểm:
thời gian cho tín màu xanh cho từng hướng (green time), thời gian giữa các tín
hiệu liền kề (amber time) và tổng thời gian của tất cả các tín hiệu (cyclic time).
Mục tiêu của ba bộ tối ưu này là giảm thiểu thời gian lãng phí cho tín hiệu màu

xanh, giảm thời gian dừng và chờ đợi cho các phương tiện với tín hiệu màu đỏ.

3.2

Mô hình hóa hệ thống ARTC sử dụng UML và OCL
Từ cách nhìn phân tích và thiết kế hệ thống hướng đối tượng với một hệ

thống phần mềm, sẽ xây dựng biểu đồ lớp ban đầu cho hệ thống ARTC như
Hình 3.

GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13


Kiểm chứng tính nhất quán của hệ thống phần mềm
trong tiến trình tái cấu trúc
TrafficController

Detector
- detectorID: String
- location: String
- roadID: Integer
- vehicleCount
: String
- crossTime: Time
- vehicleSpeed
: Integer
+ active()
+ deactive()

+
sendTrafficFlow
()

+

25

detectVehicle
()

- controllerID
: String
- location: String

+
+
+
+

speedLimit
: Integer
roadID: String
getTrafficFlow
()
analyzeTraffic
()
setSignal()
setTime()

Road

- roadID: String
- roadName: String
- roadLocation
: String
- trafficFlow: Object
+ setRoadDetail
()
+ getRoadDetail
()

Optimizer

- amberTime
: Integer
- greenTime: Integer
- state: STATE
- signal: SIGNAL
- duration: Integer
- cycleTime: Integer
+ analyzeSignal
()
+
analyzeTimeLimit
()
+
analyzeAdjacent
()

Hình 3: Biểu đồ lớp khởi đầu cho hệ thống ARTC

Biểu đồ lớp mô tả bộ khung cho cấu trúc tĩnh của hệ thống. Nó biểu thị các
lớp, các thuộc tính và các phương thức tương ứng với các lớp có trong hệ thống.
Trong Hình 3, Traffic controller là lớp đóng vai trò trung tâm, liên kết với các
lớp khác trong hệ thống ARTC. Lớp Detector mô tả địa chỉ vật lý của các máy
dò tín hiệu, nó cũng cung cấp số lượng các phương tiện đã lưu thông qua tuyến
đường trên một đơn vị thời gian nhất định.
Lớp tiếp theo là lớp Optimizer, nó bao gồm các phương thức analyzeSignal(),
analyzeTimeLimit() và analyzeAdjacent() sử dụng để phân tích các tín hiệu đầu
vào. Cuối cùng là lớp Road, chứa đựng các thông tin về các con đường và tỷ lệ
lưu lượng giao thông trung bình của các phương tiện đi qua nó.
Ngôn ngữ ràng buộc đối tượng (The Object Constraint Language – OCL[9]) là
ngôn ngữ tự khai báo, dùng để mô tả các ràng buộc đối với các thành phần có
GVHD: ThS. Đào Thị Hường

SVTH: Vũ Tuấn Anh, Lớp CNTT K13