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 quán hệ thống phần mềm tiến trình tái cấu trúc 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 quán hệ thống phần mềm 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 /2016 GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc 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 quán hệ thống phần mềm tiến trình tái cấu trúc LỜI CẢM ƠN Với tất tình cảm em xin gửi lời cảm ơn chân thành tới tất thầy cô giáo khoa Công Nghệ Thông Tin trường Đại học Hải Phòng đặc biệt cô giáo Thạc sĩ: Đào Thị Hường người hướng dẫn dìu dắt em suốt trình làm kiến tập Cô không hướng dẫn em tận tình việc thiết kế nội dung đề tài mà có ý kiến vô quý báu giúp cho kiến tập em mang tính khoa học xác Mặc dù cố gắng tập trung nghiên cứu, sưu tầm, tham khảo tài liệu bảo, giúp đỡ tận tình cô giáo bạn bè song điều kiện kiến thức, phương pháp hạn chế kinh nghiệm thực tế nên kiến tập nhiều thiếu sót Em mong quý thầy cô bạn góp ý, bổ sung để kiến tập hoàn thiệ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 quán hệ thống phần mềm tiến trình tái cấu trúc LỜI MỞ ĐẦU Ngày nay, công nghiệp phần mềm trở thành sở hạ tầng quan trọng 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 doanh nghiệp tạo tỷ suất lợi nhuận lớn nhiều so với trước Trong tiến trình toàn cầu hóa này, bên cạnh tiến mặt công nghệ việc nghiên cứu đề xuất thuật toán có ý nghĩa quan trọng Với tốc độ phát triển doanh nghiệp phần mềm Việt Nam, dịch vụ gia tăng chất lượng phần mềm xu hướng công nghiệp phần mềm Cùng với trình vận hành, chế bảo trì để đảm bảo chất lượng phần mềm nhân tố thiếu Yêu cầu thay đổi phần mềm xuất phát sinh vấn đề môi trường nghiệp vụ, hiệu năng, độ tin cậy Vấn đề đặt phải quản lý thay đổi hệ thống phần mềm tầm quan trọng cải tiến chất lượng phần mềm Theo cách tiếp cận tiến hóa quy trình phát triển phần mềm, từ hệ thống đơn giản ban đầu xây dựng, trình tiến hóa thực cách liên tục đạt hệ thống với chức mong muốn Ở giai đoạn, hệ thống mở rộng theo yêu cầu tập hợp yêu cầu Tuy vậy, có điều hiển nhiên rằng, thiết kế hệ thống ban đầu có khả linh hoạt để sẵn sàng thêm yêu cầu Do đó, yêu cầu quan trọng thiết kế phần mềm, linh hoạt, điều đồng nghĩa với việc, thiết kế phần mềm không đáp ứng tốt yêu cầu mà sẵn sàng cho trình tích hợp yêu cầu phát sinh tương lại Một kĩ thuật sử dụng rộng rãi để gia tăng chất lượng phần mềm tái cấu trúc phần mềm (refactoring), trình tích hợp thêm đặc trưng hệ thống trở nên dễ dàng trước thực bước tái cấu trúc Nó làm cải tiến chất lượng thiết kế GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc Mẫu thiết kế (Design Patterns) (Hunt, 2013) kỹ thuật lập trình hướng đối tượng, sử dụng thường xuyên ngôn ngữ lập trình hướng đối tượng Nó cung cấp “mẫu thiết kế”, giải pháp để giải vấn đề chung, thường gặp lập trình Mẫu thiết kế giúp giải vấn đề cách tối ưu lập trình hướng đối tượng Trong thực tập tốt nghiệp tập trung nghiên cứu tiến trình tái cấu trúc có sử dụng mẫu thiết kế tiến trình cải tiến chất lượng phần mềm 1.1 Tổng quan Phát biểu toán Trong môi trường giới thực, tính chất nội quan trọng hệ thống phần mềm khả tiến hóa (evolve) Phần mềm cần cải tiến, sửa đổi, cho phù hợp với yêu cầu mới, mã nguồn trở nên phức tạp có cách biệt ngày lớn so với thiết kế ban đầu, điều đó, đương nhiên làm giảm chất lượng phần mềm Vì thế, phần lớn chi phí cho việc phát triển phần mềm dành cho trình bảo trì [1], [2], [3] Các phương pháp công cụ để cải tiến chất lượng phần mềm không giải vấn đề này, dẫn đến khả gia tăng thời gian thực làm cho phần mềm phức tạp Để đương đầu với vấn đề này, câu hỏi cấp thiết đặt cho ngành công nghệ phần mềm "Làm giảm độ phức tạp trình tiến hóa phần mềm mà bước nâng cao chất lượng nội phần mềm?" Lĩnh vực nghiên cứu biết đến kỹ thuật tái cấu trúc phần mềm (refactoring), đặc biệt phát triển phần mềm hướng đối tượng [1, 2] Theo Tchaikovsky Cross [3], tái cấu trúc hiểu "sự chuyển đổi từ hình thức biểu diễn sang hình thức biểu diễn khác, tương đương mức độ trừu tượng, giữ nguyên hành vi bên đối tượng hệ thống (chức ngữ nghĩa) Sự chuyển dịch tái cấu trúc thường thay đổi diện mạo chương trình, chẳng hạn thay đổi mã để cải thiện cấu trúc thiết kế phần mềm Trong tái cấu tạo phiên mà thực đề nghị thay đổi với hệ thống chủ đề, GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc không thường liên quan đến sửa đổi yêu cầu Tuy nhiên, dẫn để quan sát tốt hệ thống chủ đề mà đề nghị thay đổi cải thiện khía cạnh hệ thống." Tuy nhiên, vấn đề phát sinh áp dụng mẫu thiết kế trình tái cấu trúc đảm bảo quán (consistency) mô hình thiết kế cũ (trước tiến hành tái cấu trúc) mô hình thiết kế (sau tiến hành tái cấu trúc) Điều dẫn đến số tính chất đắn hệ thống không bảo tồn Một số phương pháp đề xuất để kiểm tra tính quán mô kỹ thuật chuyển đổi mô hình (C Zhao), (P Bottoni, 2003), mô tả hệ thống khung nhìn logic (R Van Der Straeten, 2003), trao đổi siêu liệu XML Trong nghiên cứu đề xuất cách tiếp cận để kiểm chứng tính quán trình tái cấu trúc phần mềm sử dụng mẫu thiết kế Những đóng góp đề tài (1) kiểm tra tính quán thuộc tính hành vi hệ thống cách xác định tiền hậu điều kiện (pre/post condition) kịch mô hình; (2) minh họa chi tiết phương pháp đề xuất hệ thống cảm ứng kiểm soát lưu lượng giao thông đường (Adaptive Road Traffic Control System - ARTCs (K.Ranjini, 2011)) 1.2 Kiến thứ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) giới thiệu lần đầu luận án tiến sĩ Opdyke [1] Tái cấu trúc biến thể tái cấu (restructuring), Opdyke định nghĩa tái cấu trúc sau: "Tái cấu trúc tiến trình làm thay đổi cấu trúc bên hệ thống phần mềm mà không ảnh hưởng đến hành vi bên hệ thống" Ý tưởng tái cấu trúc phân bố lại lớp (classes), biến (variables), phương thức mối quan hệ phân cấp lớp nhằm tạo thuận lợi cho nhu cầu mở rộng thích nghi hệ thống tương lai Trong bối cảnh tiến hóa phần mềm, chuyển dịch cấu (restructuring) tái cấu trúc (refactoring) sử dụng để cải thiện chất lượng phần mềm (ví dụ, khả 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 quán hệ thống phần mềm tiến trình tái cấu trúc hiệu ) Tái cấu trúc tái cấu sử dụng kĩ nghệ tái tạo phần mềm (reengineering), kiểm tra thay đổi hệ thống đối tượng để pha hình thức thực hình thức Trong bối cảnh này, việc tái cấu cần thiết để chuyển đổi mã di sản mã bị suy thoái thành mô-đun có cấu trúc hình thức, chí di chuyển mã để ngôn ngữ lập trình khá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 đại, mục tiêu quan trọng khả mở rộng bảo trì hệ thống phần mềm Để đạt tiêu chí đó, cần có thiết kế phần mềm tốt Bản thiết kế không giải trường hợp cụ thể, mà có thêm khả mở rộng Có nhiều kỹ thuật để hỗ trợ cho việc xây dựng thiết kế tốt, việc ứng dụng Mẫu thiết kế (Design Patterns) sử dụng rộng rãi Đối với tình thiết kế cụ thể đưa ra, Mẫu thiết kế cung cấp khuôn mẫu chung để giải quyêt tình Nói cách khác, Mẫu thiết kế cung cấp giải pháp cho vấn đề thiết kế phổ biến Trong lập trình hướng đối tượng (Object Oriented Programming), mẫu thiết kế giải vấn đề kế thừa tương tác nói chung, vấn đề kiến trúc tổng thể quy mô lớn Điểm kỳ diệu mẫu thiết kế khả dễ dàng tái sử dụng, dễ mở rộng bảo trì Nếu ta có thiết kế không tốt, gặp vấn đề phát sinh, phần mềm khả tái sử dụng bảo trì, phải dành nhiều thời gian, chí nhiều thời gian bỏ xây dựng, để sửa chữa chúng Các mẫu thiết kế sách tiếng GOF [4] phân loại thành ba nhóm, cụ thể (1) nhóm mẫu khởi tạo (creational patterns), (2) nhóm mẫu cấu trúc (structural patterns), (3) nhóm mẫu hành vi(behavioral patterns) Nhóm đầu tiên, cung cấp cách thức để tạo nhóm đối tượng Các mẫu 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 quán hệ thống phần mềm tiến trình tái cấu trúc hệ đối tượng Nhóm mẫu cuối xác định cách cư xử giao tiếp lớp đối tượng Trong phần này, trình bày chi tiết mẫu nhóm hành vi, cụ thể mẫu chiến lược (Strategy), mẫu ứng dụng cụ thể vào mô hình minh họa phần Nói cách khác, mẫu chiến lược “Định nghĩa tập hợp thuật toán, đóng gói chúng thành loại một, giúp chúng hoán đổi cho nhau" Mẫu chiến lược thực thi thuật toán cách linh động, tùy thuộc vào ngữ cảnh cụ thể Ý nghĩa thực mẫu chiến lược tách rời phần xử lý chức khỏi đối tượng Sau tạo tập hợp thuật toán để xử lý chức cho phép lựa chọn thuật toán đắn thực thi chương trình Mẫu thiết kế thường sử dụng để thay cho kế thừa, muốn chấm dứt việc theo dõi chỉnh sửa chức qua nhiều lớp Hình 1: Mẫu chiến lược (Strategy) Mẫu chiến lược Hình bao gồm 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 quán hệ thống phần mềm tiến trình tái cấu trúc • IStrategy: Giao diện (Interface) chia sẻ lớp cụ thể họ thuật toán Lớp Context sử dụng giao diện để gọi đến thuật toán định nghĩa lớp • ConcreteStrategy: Nơi thuật toán cài đặt cụ thể • Context: Lớp dùng để tham chiếu đến kiểu ISstrategy Trong số trường hợp, Context cài đặt phương thức lớp ConcreteStrategy truy cập đến liệu 1.2.3 Ngôn ngữ mô hình hóa thống – UML(Unified Modeling Language) UML[10] ngôn ngữ mô hình hóa thống với ký hiệu trực quan, phương pháp hướng đối tượng sử dụng để thể miêu tả thiết kế hệ thống Nó ngôn ngữ để đặc tả, trực quan hóa, xây dựng làm tài liệu cho nhiều đối tượng khác UML[10] làm công cụ giao tiếp người dùng, nhà phân tích, nhà thiết kế nhà phát triển phần mềm  Mục đích UML • Mô hình hóa hệ thống sử dụng khái niệm hướng đối tượng • Thiết lập kết nối từ nhận thức người đến việc cần mô hình hóa • Giải vấn đề mức độ thừa kế hệ thống phức tạp, có nhiều ràng buộc khác • Tạo ngôn ngữ mô hình hóa sử dụng người máy  Miền ứng dụng UML UML[1] sử dụng nhiều giai đoạn từ phát triển, thiết kế, thực 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ý khoảng liệu lớn có quan hệ phức tạp, mà chúng lưu trữ sở 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 quán hệ thống phần mềm tiến trình tái cấu trúc 10 • Hệ thống kỹ thuật (Technical system): Xử lý điều khiển thiết bị viễn thông, hệ thống quân hay trình công nghiệp Đây loại thiết bị phải xử lý giao tiếp đặc biệt, giao giao diện chuẩn thường hệ thống thời gian thực • Hệ thống nhúng (Embeded system): Thực thiết bị phần cứng ô tô, thiết bị di động Điều thực 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ố số máy cho phép truyền liệu từ nơi đến nơi khác cách dễ dàng Chúng đòi hỏi chế liên lạc đồng để bảo đảm toàn vẹn liệu Thường xây dựng số kỹ thuật hướng đối tượng CORBA, COM/DCOM • Hệ thống giao dịch (Bussiness system): Mô tả mục đích, tài nguyên, quy tắc công việc kinh doanh • Phần mềm hệ thống (System software): Định nghĩa sở hạ tầng kỹ thuật cho phần mềm khác sử dụng chẳng hạn hệ điều hành, sở liệu,  Hệ thống biểu đồ 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 trình phát triển phần mềm người ta nhận rằng, với hệ thống ký hiệu trực quan UML[10] đặc tả hết khía GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm 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ả khung cho cấu trúc tĩnh hệ thống Nó biểu thị lớp, thuộc tính phương thức tương ứng với lớp có hệ thống Trong Hình 3, Traffic controller lớp đóng vai trò trung tâm, liên kết với lớp khác hệ thống ARTC Lớp Detector mô tả địa vật lý máy dò tín hiệu, cung cấp số lượng phương tiện lưu thông qua tuyến đường đơn vị thời gian định Lớp lớp Optimizer, bao gồm phương thức analyzeSignal(), analyzeTimeLimit() analyzeAdjacent() sử dụng để phân tích tín hiệu đầu vào Cuối lớp Road, chứa đựng thông tin đường tỷ lệ lưu lượng giao thông trung bình phương tiện qua Ngôn ngữ ràng buộc đối tượng (The Object Constraint Language – OCL[9]) ngôn ngữ tự khai báo, dùng để mô tả ràng buộc thành phần có GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc 26 mô hình UML Ta sử dụng OCL để thêm vào ràng buộc lớp có trọng biểu đồ lớp sau: Context Optimizer inv self.amberTime = Context TrafficController::getTrafficFlow() pre: self.trafficFlow -> isEmpty() post: self.trafficFlow -> notEmpty() Context TrafficController::analyzeTraffic() pre: self.trafficFlow -> notEmpty() post: (state = heavyTraffic) OR (state = lowTraffic) OR (state = highTraffic) OR (state = noTraffic) Context Optimizer::analyzeSignal() 10 pre: (state = heavyTraffic) OR (state = lowTraffic) 11 post: if (state = heavyTraffic) then (signal = green) 12 else (signal = red) 13 endif 14 Context Optimizer::analyzeTimeLimit() 15 pre: (state = heavyTraffic) OR (state = lowTraffic) 16 post: if (state = heavyTraffic) then (greenTime > 60) GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc 27 17 else (greenTime isEmpty() GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc 30 post: self.trafficFlow -> notEmpty() Context TrafficController::analyzeTraffic() pre: self.trafficFlow -> notEmpty() post: (state = heavyTraffic) OR (state = lowTraffic) OR (state = highTraffic) OR (state = noTraffic) Context SignalOptimizeStrategy::optimizeTraffic() 10 pre: (state = heavyTraffic) OR (state = lowTraffic) 11 post: if (state = heavyTraffic) then (signal = green) 12 else (signal = red) 13 endif 13 Context TimeLimitOptimizeStrategy::optimizeTraffic() 14 pre: (state = heavyTraffic) OR (state = lowTraffic) 15 post: if (state = heavyTraffic) then (greenTime > 60) 16 else (greenTime 60)) else if (state = lowTraffic) then ((signal = red) AND ( greenTime isEmpty() POST_SiM = if (state = heavyTraffic) then ((signal = green) AND ( greenTime > 60)) GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc else if 33 (state = lowTraffic) then ((signal = red) AND ( greenTime isEmpty() POST_S’iM = if (state = heavyTraffic) then ((signal = green) AND ( greenTime > 60)) else if (state = lowTraffic) then ((signal = red) AND ( greenTime (\result==SIGNAL.green); @ also @ ensures ((st==STATE.lowTraffic)&&(sig==SIGNAL.green)) ==>(\result==SIGNAL.red); @ also @ signals_only Exception; GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc • 36 Sau xây dựng xong phương thức GetSignal lớp Optimizer, ta sử dụng công cụ OpenJML mà thu kết sau: Hình 7: Kết kiểm chứng sau sử dụng công cụ OpenJML Như với công cụ OpenJML kiểm chứng phương thức GetSignal lớp Optimizer VALID SIGNAL STATE trường hợp INVALID phương thức GetSignal kiểm chứng quán Đối với lớp lại phương thức lại ta thực tương tự với cách thức để thu kết việc kiểm chứng tính quán tự động GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc 3.5 37 Kết luận Trong này, đề xuất phương pháp để kiểm chứng quán tiến trình tái cấu trúc thực mẫu thiết kế mô hình phần mềm Một mô hình mô tả cách sử dụng biểu đồ lớp UML biểu đồ tuần tự, sơ đồ lớp dùng để đặc tả cấu trúc tĩnh mô hình biểu đồ dùng để mô tả hành vi kịch thực nhiệm vụ hệ thống phần mềm Bên cạnh đó, OCL sử dụng để mô tả ràng buộc thuộc tính hành vi lớp Chúng đề xuất tập luật dùng để xác minh trình tiến hóa phần mềm, mô hình sau áp dụng mẫu thiết kế có phù hợp với đặc tả mô hình ban đầu hay không Để minh họa cho phương pháp đề xuất, xây dựng mô hình hệ thống thích ứng điều khiển lưu lượng giao thông đường (Adaptive Road Trafic Control - ATRC) UML[10] Trong ví dụ này, minh họa việc kiểm chứng tính quán áp dụng mẫu Strategy mô hình kịch (biểu diễn cho chức tương ứng hai mô hình), kịch khác thực cách tương tự dối với hệ thống phức tạp Kết cuối việc kiểm tra tính quán hành vi bên mô hình phụ thuộc kết hợp tất kết kiểm tra cặp kịch tương ứng GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc 38 mô hình Nếu chỉ tồn kết không quán, kết kiểm tra hai hệ thống coi không quán quán phần Trong ví dụ minh họa này, dễ thấy trình mô hình hóa trình kiểm tra tính quán thực cách tự động cách sử dụng ngôn ngữ JML để mô tả ràng buộc sử dụng công cụ OpenJML để kiểm tra tính quán Tài liệu tham khảo [1] W F Opdyke, Refactoring: A program restructuring aid in designing objectoriented application frameworks, Ph.D thesis, PhD thesis, University of Illinois at Urbana-Champaign (1992) [2] E J Chikofsky, J H Cross, et al., Reverse engineering and design recovery: A taxonomy, Software, IEEE (1) (1990) 13–17 [3] D P RHRJJV Erich Gamma, Elements of reusable object-oriented software (1994) [4] T Mens, S Demeyer, D Janssens, Formalising behaviour preserving program transformations, in: A Corradini, H Ehrig, H.J Kreowski, G Rozenberg (Eds.), Graph Transformation, Vol 2505 of Lecture Notes in Computer Science, Springer Berlin Heidelberg, 2002, pp 286–301 [5] C Zhao, J Kong, K Zhang, Design pattern evolution and verification using graph transformation, in: System Sciences, 2007 HICSS 2007 40th Annual Hawaii International Conference on, IEEE, 2007, pp 290 a–290a GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 Kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc 39 [6] K.Ranjini, A.Kanthimathi, Y.Yasmine, Article: Design of adaptive road traffic control system through unified modeling language, International Journal of Computer Applications 14 (7) (2011) 36– 41, full text available [7] Object Management Group – Object Constraint Language Version 2.2 [8] TS Dương Kiều Hoa – Tôn Thất An – Phân tích thiết kế hệ thống thông tin theo UML GVHD: ThS Đào Thị Hường SVTH: Vũ Tuấn Anh, Lớp CNTT K13 [...]... 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. .. 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. .. 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ệ. .. 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. .. công thức của logic vị từ cấp 1 bởi vậy, chúng ta có thể kiểm chứng tính nhất quán của hệ thống bằng các công cụ kiểm chứng tự động mà em giới thiệu trong đề tài của mình đó là công cụ OpenJML 3.4 Sử dụng công cụ OpenJML kiếm chứng tính nhất quán của hệ thống 3.4.1 phần mềm Giới thiệu về công cụ OpenJML Trong quá trình mô hình hóa hệ thống đã sử dụng ngôn ngữ OCL để biểu diễn ràng buộc của hệ thống những... 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 34 Từ các giá trị về tiền và hậu điều kiện tính toán được của các kịch bản trên Theo Mệnh đề 2, quá trình tái cấu trúc sử dụng mẫu thiết kế Strategy trong hệ thống ARTC hoàn toàn bảo tồn (nhất quán toàn phần) các thuộc tính động giữa mô hình ban đầu và mô hình sau phát triển Chú ý rằng, OCL mô tả các điều kiện trong công thức của. .. 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. .. 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... 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. .. 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