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

Một trong các kĩ thuật đang được sử dụng rộng rãi để gia tăng chất lượngphầ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êmcác đặc trưng của hệ thống sẽ trở nên

TRƯỜNG ĐẠI HỌC HẢI PHÒN G

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á : 2012-2016

Hệ : Chính quy

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

Mục Lục

Danh Sách Hình Vẽ

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ácthầ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 trongviệ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 chobà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ếnthứ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àycò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ếntậ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

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ọngcủ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ấtcủ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ớitrướ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ôngnghệ 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ứcquan 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ínhcủ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ầnmềm là một trong những nhân tố không thể thiếu Yêu cầu thay đổi phần mềmxuấ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ệună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ộtcá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ợpcá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ầumớ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êucầ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ượngphầ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êmcá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ệnbướ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ế

Mẫu thiết kế (Design Patterns) (Hunt, 2013) là một kỹ thuật trong lập trìnhhướng đối tượng, được sử dụng thường xuyên trong các ngôn ngữ lập trìnhhướng đối tượng Nó cung cấp các “mẫu thiết kế”, các giải pháp để giải quyếtcá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ấutrú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. Tổng quan

Trong môi trường thế giới thực, một trong những tính chất nội tại quantrọ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ũngtrở 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ácphươ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ũngnhư 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ựcnghiê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 đươngnhau 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áicấ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ácphiên bản mới mà thực hiện hoặc đề nghị thay đổi với hệ thống chủ đề, nó

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ảithiệ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ểmchứ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ẫuthiế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ácthuộ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ếtphươ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.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 ántiế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áchà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ạicá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ượngcủ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

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ạophầ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 Trongbố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ụctiê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ụngcác Mẫu thiết kế (Design Patterns) đang được sử dụng rộng rãi Đối với một tìnhhuống thiết kế cụ thể được đưa ra, các Mẫu thiết kế cung cấp một khuôn mẫuchung để giải quyêt tình huống đó Nói cách khác, Mẫu thiết kế cung cấp giảipháp cho các vấn đề thiết kế phổ biến Trong lập trình hướng đối tượng (ObjectOriented 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ầnmề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

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ữacá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 đổicho 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ộcvà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ờiphầ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ậttoán để xử lý chức năng đó và cho phép lựa chọn thuật toán đúng đắn nhất khithự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ềulớ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:

• 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

• 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ìnhhó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àngbuộ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

UML[1] có thể được sử dụng trong nhiều giai đoạn từ phát triển, thiết kế, thựchiện và bảo trì

• Hệ thống thông tin (Infomation system) : Cất giữ, lấy, biến đổi thông tin chongườ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

• Hệ thống kỹ thuật (Technical system): Xử lý và điều khiển các thiết bị viễnthô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 chophé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ỏicá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ựngtrê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 chophần mềm khác sử dụng chẳng hạn như hệ điều hành, cơ sở dữ liệu,

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

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ínhxác hơn Và OCL trở thành chuẩn ngôn ngữ đặc tả cho các biểu đồ trongUML[10] trong thực tế Trong phần này chúng ta quan tâm chủ yếu tới cáchthứ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

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ểudiễn giá trị Giá trị biểu diễn của nó có thể là một giá trị kiểu cơ sở hay thamchiế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ônluô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 địnhnhữ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

- 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ểuthứ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

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ếntạ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ứcOCL 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ủamộ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ướckhi 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ếtquả Boolean) Biểu thức OCL này phải được đánh giá là đúng bất cứ khi nàophương thức bắt đầu thực thi, nhưng việc đánh giá này chỉ áp dụng cho thể hiệnthự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ó saukhi 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ểuthức OCL (trả về kết quả Boolean) Việc đánh giá biểu thức OCL tại thời điểmkế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, )

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

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ấtquá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ấutrú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

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

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ấutrú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ẫngiữ 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ằmmụ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ônglà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ểmchứng sự nhất quán về mặt hành vi giữa mô hình gốc (initial model) và mô hìnhsau khi đã tái cấu trúc (evolution model) Phương pháp kiểm chứng bao gồm batiế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ụngUML đề mô hình hóa hệ thống phần mềm thành một mô hình hình thức (formalmodel) Đâ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ốiquan 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ộthoặ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ácmẫ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ọngtrong 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ầnmề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áchà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á

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ặckhô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

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ảiquyế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

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ĩatrê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àokị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àokị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ựatrê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 ,S M}, trong

đó C M là tập hợp các lớp và S M 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 Ci M = {OPCiM ,

A CiM , I CiM}, ở đây OPCiM là tập hợp các phương thức công khai, A CiM là tập hợp các thuộc tính công khai, và I CiM 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

PRE opiM của phương thức op ei , được hiện thực hóa bởi N phương thức op ei trong

các lớp con Cksi M , trong lớp trừu tượng Ci M được tính bằng hợp tiền điều kiện của tất cả các phương thức op ei trong các lớp con Cksi M

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(op ei) 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

POST opiM của phương thức op ei , được hiện thực hóa bởi N phương thức op ei trong các lớp con Cksi M , trong lớp trừu tượng Ci M được tính bằng hợp hậu điều kiện của tất cả các phương thức op ei trong các lớp con Cksi M

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ủacá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ốngtươ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

Si M = {CISiM , PRE SiM , E SiM , POST SiM}, trong đó CISiM ⊆ CiM biểu diễn cho tập hợp các lớp tham gia vào kịch bản, PRE SiM là tiền điều kiện của kịch bản, E SiM 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à POST SiM 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

là EkSiM = {PREEkSiM,OPEkSiM, POSTEkSiM,k}, trong đó PREEkSiM là tiền điều kiện của phương thức, OP EkSiM là các phương thức công khai thực thi trong kịch bản, POST EkSiM 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ệncủ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(A CijM), ở đâ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ứctiề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ộtphươ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

PRE SiM đượ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ácrà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

POST SiM đượ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

A CijM của hậu điều kiện của phương thức POST EkSiM diễn ra sau cùng trong E SiM

Cho một kịch bản S = (e1,e2, e n), 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 , op ei , post ei , i)

và post(ei ) = VP k(Ak C), ở đây P k là các logic vị từ Ak C, biểu diễn cho thuộc tính