Một Số Phương Pháp Kiểm Chứng Tái Cấu Trúc Phần Mềm

Luận án tiến sĩ trình bày các phương pháp kiểm chứng tái cấu trúc phần mềm, góp phần nâng cao chất lượng và hiệu quả trong lĩnh vực công nghệ thông tin.

• Tác giả: Đào Thị Hường
• Người hướng dẫn: PGS. TS. Trương Ninh Thuận
• Trường học: Đại học Quốc gia Hà Nội
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Phương Pháp Kiểm Chứng Tái Cấu Trúc Phần Mềm
• Loại tài liệu: luận án tiến sĩ
• Năm xuất bản: 2018
• Địa điểm: Hà Nội

Tóm tắt

I. Tổng Quan Phương Pháp Tái Cấu Trúc Phần Mềm Hiệu Quả

Tái cấu trúc phần mềm là quá trình cải thiện cấu trúc bên trong của hệ thống mà không làm thay đổi hành vi bên ngoài. Đây là một kỹ thuật quan trọng để nâng cao chất lượng phần mềm, giúp hệ thống dễ bảo trì, mở rộng và tái sử dụng hơn. Tuy nhiên, tái cấu trúc có thể phức tạp và dễ gây ra lỗi nếu không được thực hiện cẩn thận. Các hệ thống phần mềm rất dễ phát sinh lỗi, đặc biệt khi người phát triển không tuân thủ nghiêm ngặt các quy trình và tiêu chuẩn. Do vậy, việc kiểm soát tiến trình này là vô cùng quan trọng. Luận án này đề xuất một số phương pháp bảo toàn các ràng buộc của hệ thống phần mềm sau tiến trình tái cấu trúc, tập trung vào các hệ thống hướng đối tượng với các đặc trưng về bất biến (invariants) và hành vi (behaviors).

1.1. Tầm Quan Trọng của Kiểm Chứng Tái Cấu Trúc

Kiểm chứng tái cấu trúc là quá trình đảm bảo rằng việc tái cấu trúc không gây ra lỗi hoặc thay đổi hành vi của hệ thống. Đây là một bước quan trọng để đảm bảo rằng việc tái cấu trúc thực sự mang lại lợi ích và không gây ra tác động tiêu cực. Các hoạt động tái cấu trúc cần được kiểm soát chặt chẽ đồng thời phải đánh giá ảnh hưởng của tiến trình này trên các đặc trưng về chất lượng và xem xét sự bảo toàn các đặc tính quan trọng của hệ thống phần mềm.

1.2. Các Thách Thức Trong Tái Cấu Trúc Phần Mềm

Tái cấu trúc phần mềm đối mặt với nhiều thách thức, bao gồm việc đánh giá ảnh hưởng của tái cấu trúc đến chất lượng, đảm bảo bảo toàn hành vi, duy trì tính nhất quán giữa các thành phần và xây dựng công cụ hỗ trợ. Việc xác định và đặc tả hành vi của phần mềm một cách hình thức, sau đó định nghĩa chính xác khái niệm về bảo toàn hành vi là một thách thức lớn. Cần chú ý rằng, các loại hành vi cần bảo toàn thường phụ thuộc vào đặc trưng của mỗi loại phần mềm.

II. Vấn Đề Tại Sao Cần Phương Pháp Kiểm Chứng Tái Cấu Trúc

Tái cấu trúc phần mềm, mặc dù mang lại nhiều lợi ích, lại tiềm ẩn rủi ro lớn nếu không được kiểm soát chặt chẽ. Các hệ thống phần mềm phức tạp, đặc biệt là các hệ thống hướng đối tượng, rất dễ bị ảnh hưởng bởi các thay đổi nhỏ trong quá trình tái cấu trúc. Do đó, việc kiểm chứng tái cấu trúc là vô cùng quan trọng để đảm bảo rằng các thay đổi không gây ra lỗi hoặc làm thay đổi hành vi của hệ thống. Cần phải xem xét, giải quyết các bài toán liên quan như đánh giá ảnh hưởng của tiến trình tái cấu trúc trên các chỉ tiêu về chất lượng, đảm bảo tiến trình tái cấu trúc bảo toàn hành vi, duy trì sự nhất quán giữa các thành phần phần mềm sau tiến trình tái cấu trúc.

2.1. Nguy Cơ Phát Sinh Lỗi Trong Quá Trình Tái Cấu Trúc

Trong quá trình tái cấu trúc, việc thay đổi cấu trúc bên trong có thể vô tình gây ra lỗi nếu không được kiểm tra kỹ lưỡng. Ví dụ, việc thay đổi thứ tự các phương thức hoặc thuộc tính, hoặc việc thay đổi cách các lớp tương tác với nhau, có thể dẫn đến các lỗi khó phát hiện. Hoạt động tái cấu trúc thực hiện trên các hệ thống phần mềm rất dễ phát sinh lỗi đặc biệt trong trường hợp người phát triển không tuân thủ một cách nghiêm ngặt các quy trình và tiêu chuẩn phát triển phần mềm.

2.2. Yêu Cầu Về Tính Đúng Đắn Sau Tái Cấu Trúc

Sau khi tái cấu trúc, hệ thống phải hoạt động đúng như trước, không có lỗi mới và không có hành vi thay đổi. Đây là yêu cầu cơ bản của tái cấu trúc và việc kiểm chứng là cần thiết để đảm bảo yêu cầu này được đáp ứng.Tiến trình tái cấu trúc phải được thực thi một cách thận trọng, đồng thời xem xét, giải quyết các bài toán liên quan.

2.3. Đánh Giá Ảnh Hưởng Của Tái Cấu Trúc Đến Chất Lượng

Tái cấu trúc cần đi kèm với đánh giá tác động đến các thuộc tính chất lượng như độ phức tạp, tính dễ hiểu, khả năng mở rộng, tái sử dụng và hiệu suất. Cần có các kỹ thuật đo lường hoặc ước lượng tác động này, ví dụ như độ đo phần mềm, đo thực nghiệm, kỹ thuật thống kê, hoặc điều khiển thực nghiệm.

III. Phương Pháp Bảo Toàn Bất Biến UML Trong Tái Cấu Trúc

Một phương pháp quan trọng để kiểm chứng tái cấu trúc là bảo toàn các bất biến trong biểu đồ lớp UML. Bất biến là các ràng buộc luôn đúng đối với các đối tượng của một lớp. Bằng cách đảm bảo rằng các bất biến được bảo toàn sau tái cấu trúc, chúng ta có thể đảm bảo rằng các đối tượng vẫn ở trạng thái hợp lệ. Các phần tử của biểu đồ lớp cùng với các ràng buộc bất biến được hình thức hóa bằng các ký pháp toán học. Tái cấu trúc trên biểu đồ lớp được thực hiện thông qua các phép toán Folding, Abstraction, Composition, Factoring và Unfolding.

3.1. Hình Thức Hóa Ràng Buộc và Biểu Đồ Lớp

Để bảo toàn bất biến, cần hình thức hóa các ràng buộc và biểu đồ lớp. Việc sử dụng các ký hiệu toán học giúp đảm bảo tính chính xác và tránh sự mơ hồ. Luận án đề xuất luật tái cấu trúc cho các phép toán đồng thời cũng chứng minh sự đúng đắn của các luật này bằng phương pháp toán học.

3.2. Các Phép Toán Tái Cấu Trúc Trên Biểu Đồ Lớp UML

Việc sử dụng các phép toán tái cấu trúc như Folding, Abstraction, Composition, Factoring và Unfolding cho phép chúng ta thực hiện các thay đổi cấu trúc một cách an toàn và có kiểm soát. Tiến trình tái cấu trúc áp dụng các phép toán trên được khẳng định là bảo toàn bất biến của các lớp của mô hình ban đầu trên mô hình tái cấu trúc.

3.3. Xây Dựng Luật Tái Cấu Trúc

Luận án đề xuất các luật tái cấu trúc (refactoring rules) cho các phép toán đồng thời cũng chứng minh sự đúng đắn của các luật này bằng phương pháp toán học. Cần xây dựng các quy tắc rõ ràng để hướng dẫn quá trình tái cấu trúc và đảm bảo tính chính xác. Các luật này cần được chứng minh tính đúng đắn để đảm bảo rằng chúng không gây ra lỗi.

IV. Phương Pháp Kiểm Chứng Bảo Toàn Hành Vi Với Mẫu Thiết Kế

Một phương pháp khác để kiểm chứng tái cấu trúc là kiểm chứng bảo toàn hành vi. Điều này có nghĩa là đảm bảo rằng các hành vi của hệ thống không thay đổi sau khi tái cấu trúc. Có thể sử dụng các mẫu thiết kế để giúp đảm bảo bảo toàn hành vi.Phần mềm ban đầu cùng với các ràng buộc về hành vi (pre/post-conditions) của các kịch bản (scenarios) tham gia vào tiến trình tái cấu trúc được hình thức hóa.

4.1. Sử Dụng Pre Post Conditions Để Đặc Tả Hành Vi

Pre/post-conditions là các điều kiện trước và sau khi thực hiện một phương thức. Bằng cách đảm bảo rằng các pre/post-conditions được đáp ứng sau tái cấu trúc, chúng ta có thể đảm bảo rằng hành vi của phương thức không thay đổi. Hoạt động tái cấu trúc được thực thi sẽ gây ảnh hưởng trực tiếp đến các thành phần cấu tạo cũng như các ràng buộc hành vi này.

4.2. Hình Thức Hóa Kịch Bản và Ràng Buộc Hành Vi

Các kịch bản (scenarios) và ràng buộc hành vi cần được hình thức hóa để có thể kiểm tra một cách chính xác. Việc sử dụng các ký hiệu toán học giúp đảm bảo tính chính xác và tránh sự mơ hồ. Do vậy, các ràng buộc hành vi được tính toán lại và so sánh với với các ràng buộc của hệ thống ban đầu.

4.3. Ứng Dụng Mẫu Thiết Kế Strategy Trong Tái Cấu Trúc

Luận án đặc biệt quan tâm đến tiến trình tái cấu trúc có sử dụng mẫu thiết kế, cụ thể là mẫu Strategy (một mẫu thuộc về nhóm các mẫu hành vi của nhóm GoF). Mẫu Strategy cho phép chúng ta thay đổi hành vi của một đối tượng mà không cần thay đổi mã của đối tượng đó.

V. Ứng Dụng CVT Công Cụ Kiểm Chứng Tính Nhất Quán

Để hỗ trợ quá trình kiểm chứng tái cấu trúc, một công cụ CVT (ConsistencyValidatorTool) đã được xây dựng. CVT cho phép kiểm tra tính nhất quán về mặt hành vi của mô hình phần mềm trước và sau khi tái cấu trúc. Công cụ này nhận dữ liệu đầu vào là mô hình cùng với ràng buộc hành vi và trả về kết luận về sự nhất quán.

5.1. Chức Năng Của Công Cụ Kiểm Chứng CVT

Công cụ CVT giúp tự động hóa quá trình kiểm chứng tái cấu trúc, giảm thiểu sai sót do con người và tăng tốc quá trình phát triển phần mềm.Công cụ CVT nhận đầu vào các mô hình phần mềm trước và sau khi tái cấu trúc cùng với các ràng buộc về hành vi (biểu diễn bằng biểu thức OCL) và trả lại kết luận về sự nhất quán giữa hai mô hình này.

5.2. Đầu Vào Đầu Ra Của Công Cụ CVT

Đầu vào của CVT là các mô hình phần mềm trước và sau khi tái cấu trúc, cùng với các ràng buộc về hành vi được biểu diễn bằng ngôn ngữ OCL. Đầu ra của CVT là kết luận về sự nhất quán giữa hai mô hình.Sau quá trình thực thi, CVT sẽ trả lại kết luận về khả năng nhất quán giữa các mô hình này.

VI. Kết Luận Hướng Phát Triển Tương Lai Kiểm Chứng Tái Cấu Trúc

Nghiên cứu này đã đề xuất các phương pháp kiểm chứng tái cấu trúc phần mềm hiệu quả, tập trung vào bảo toàn bất biến và bảo toàn hành vi. Các phương pháp này giúp đảm bảo rằng việc tái cấu trúc không gây ra lỗi và hệ thống vẫn hoạt động đúng sau khi tái cấu trúc. Các kết quả nghiên cứu của luận án góp phần bổ sung và hoàn thiện các giải pháp nâng cao chất lượng của hệ thống phần mềm khi áp dụng kỹ thuật tái cấu trúc.

6.1. Tóm Tắt Đóng Góp Của Nghiên Cứu

Nghiên cứu đã đóng góp vào việc phát triển các phương pháp kiểm chứng tái cấu trúc, bao gồm hình thức hóa ràng buộc, sử dụng phép toán tái cấu trúc, và áp dụng mẫu thiết kế. Đề xuất phương pháp bảo toàn bất biến của lớp trong tái cấu trúc mô hình UML. Các thành phần của biểu đồ lớp cùng với các ràng buộc bất biến được hình thức hóa. Tiến trình tái cấu trúc biểu đồ lớp của UML được thực hiện thông qua năm phép toán liên quan đến quan hệ phân cấp trong kế thừa.

6.2. Hướng Nghiên Cứu Tiếp Theo Trong Tái Cấu Trúc

Hướng nghiên cứu tiếp theo có thể tập trung vào việc phát triển các công cụ hỗ trợ tái cấu trúc tự động, cũng như việc áp dụng các phương pháp kiểm chứng tái cấu trúc cho các loại phần mềm khác nhau. Việc tự động hóa quy trình kiểm chứng, nâng cao khả năng tích hợp các công cụ, và mở rộng phạm vi áp dụng cho các loại phần mềm khác nhau là những hướng đi đầy tiềm năng.

Trích đoạn nội dung tài liệu

Mở đầu, Mục 2.2 sẽ làm rõ khái niệm tái cấu trúc cũng như các bước áp dụng kỹ thuật tái cấu trúc trên chế tác phần mềm và các khái niệm khóa của mô hình hướng đối tượng được sử dụng trong luận án. Các mục tiếp theo, luận án sẽ lần lượt mô tả về ngôn ngữ mô hình hóa thống nhất UML (Unified Modeling Language), mẫu thiết kế (Design Pattern), ngôn ngữ ràng buộc đối tượng OCL (Object Constraint Language), ngôn ngữ đặc tả cho Java JML (Java Modeling Language) và cuối cùng là logic vị từ cấp 1 FOL (First-Order Logic). Chú ý rằng, trong chương này luận án đề cập đến các khái niệm quan trọng như biểu đồ lớp (Class diagram), lớp (Class), thuộc tính (attribute), phương thức (methods), bất biến của lớp (class invariants), tiền/hậu điều kiện (pre/post-conditions) của phương thức, v. Tuy nhiên, do nội dung và phương pháp nghiên cứu của các Chương 3 và 4 là khác nhau nên các khái niệm này cũng được biểu diễn hình thức theo các cách khác nhau nhằm mục tiêu tạo sự phù hợp với phương pháp nghiên cứu được đề xuất ở từng chương.1 Tái cấu trúc (refactoring) Tái cấu trúc (refactoring) “là sự thay đổi cấu trúc bên trong nhằm mục tiêu làm cho nó trở nên dễ hiểu và dễ sửa đổi hơn mà không làm thay đổi hành vi có thể quan sát được của hệ thống phần mềm”.

Ý tưởng chính của tái cấu trúc là phân bố lại các lớp (classes), các thuộc tính (attributes) và các 9 (LUAN.624801 TIEU LUAN MOI download : skknchat@gmail. Kiến thức cơ sở 10 phương thức (methods) xung quanh mối quan hệ phân cấp giữa các thành phần này [27]. Tái cấu trúc thường được thực hiện theo từng bước nhỏ, mỗi bước nhỏ này đều được chứng minh sự bảo toàn về mặt hành vi. Sự kết hợp nhiều bước nhỏ sẽ tạo thành một tiến trình tái cấu trúc phức hợp mà vẫn bảo toàn được các hành vi bên ngoài của hệ thống.

Mục tiêu của tái cấu trúc luôn luôn là sự tương đương (về ngữ nghĩa hoặc hành vi) của hệ thống ban đầu với phiên bản tái cấu trúc của nó. Tuy nhiên, trong một số trường hợp cần sự linh hoạt, tái cấu trúc chỉ cần bảo toàn một số hành vi mong muốn của hệ thống. Tái cấu trúc trên hệ thống phần mềm mang lại một số lợi ích như giúp cải thiện thiết kế của hệ thống, làm cho phần mềm trở nên dễ hiểu hơn, giúp tìm ra lỗi của hệ thống và làm tăng hiệu quả thực thi của chương trình phần mềm [27]. Về mặt kỹ thuật, tái cấu trúc có nguồn gốc từ toán học khi thực hiện biến đổi các biểu thức tương đương (thay đổi các nhân tố biểu diễn làm cho biểu thức trở nên rõ ràng hơn).

Bởi vậy, tái cấu trúc ẩn bên trong nó ngụ ý tương đương; nói cách khác trước và sau khi tái cấu trúc chức năng của phần mềm phải giống nhau. Kỹ thuật tái cấu trúc khi mới ra đời được giới thiệu để áp dụng trên mã nguồn của phần mềm, tuy nhiên, theo thời gian kỹ thuật này được thực thi trên hầu hết các chế tác (artifact) khác nhau của hệ thống phần mềm như mô hình thiết kế, lược đồ cơ sở dữ liệu, bản phân tích yêu cầu phần mềm, mã nguồn v. Tiến trình tái cấu trúc thực thi trên mỗi chế tác phần mềm bao gồm sáu bước chính sau đây [43]: (1) Xác định vị trí tiến hành tái cấu trúc. Mỗi chế tác của hệ thống phần mềm cũng bao gồm bên trong nó rất nhiều thành phần cấu tạo (bản thiết kế bao gồm biểu đồ lớp, biểu đồ tuần tự, v.

Người phát triển hệ thống cần phải xác định vị trí nào trên chế tác sẽ được tác động hoạt động tái cấu trúc; (2) Xác định phép toán tái cấu trúc sẽ được tiến hành đối với vị trí trên. Tiến trình tái cấu trúc bao gồm bên trong nó rất nhiều hoạt động khác (LUAN.624801 TIEU LUAN MOI download : skknchat@gmail. Kiến thức cơ sở 11 nhau, bởi vậy cần phải xác định rõ loại hoạt động tái cấu trúc được áp dụng trên vị trí đã xác định trong bước (1); (3) Đảm bảo rằng tiến trình tái cấu trúc bảo toàn hành vi của hệ thống. Mục tiêu cuối cùng của tiến trình tái cấu trúc là cải thiện cấu trúc bên trong nhưng không làm ảnh hưởng đến hành vi bên ngoài.

Bởi vậy, sau mỗi khi thực hiện tiến trình bằng cách thức nào đó phải chỉ ra sự bảo toàn các hành vi mong muốn của hệ thống; (4) Thực thi tiến trình tái cấu với vị trí và kỹ thuật tái cấu trúc đã được xác định tại các bước (1) và bước (2). Thực hiện các hoạt động tái cấu trúc trên các thành phần phần mềm; (5) Đánh giá ảnh hưởng của tiến trình tái cấu trúc trên các đặc trưng về chất lượng phần mềm. Sự cải thiện chất lượng của hệ thống phần mềm được đánh giá thông qua các chỉ tiêu như tính phức hợp, khả năng hiểu được, khả năng bảo trì, v. hoặc sự cải thiện các tiến trình như giá thành, công sức, năng suất; (6) Duy trì sự nhất quán giữa các chế tác khác phần mềm với nhau.

Hệ thống phần mềm có rất nhiều chế tác khác nhau, khi thực hiện tái cấu trúc trên một chế tác phần mềm thì phải đảm bảo sự nhất quán của nó đối với các chế tác còn lại. Quy trình tái cấu trên áp dụng đối với tất cả các chế tác phần mềm được tái cấu trúc, tuy nhiên, mỗi hoạt động này có thể được hỗ trợ bởi rất nhiều công cụ, kỹ thuật hoặc phương pháp hình thức hóa khác nhau nhằm mang lại hiệu quả cao nhất cho tiến trình tái cấu trúc. Tiến trình tái cấu trúc bao gồm bên trong nó rất nhiều hoạt động khác nhau, Flower [27] đã trình bày một danh mục khá đầy đủ các phép tái cấu trúc. Dựa trên tiêu chí về độ phức tạp (complexity), ông cũng phân loại các phép toán tái cấu trúc vào hai nhóm chính: (i) nhóm các phép tái cấu trúc nguyên thủy (Primitive Refactoring) và (ii) nhóm các phép tái cấu trúc phức hợp (Composite Refactoring).

Nhóm các phép tái cấu trúc nguyên thủy thường đề cập đến các hoạt động khá đơn giản như MoveAttribute, MoveAssociationEnd, PushDownAttribute, RenameAttribute, ExtractClass, ExtractSuperclass, PullUpMethod, v. Các hoạt động này đã được chứng minh là các biến đổi bảo toàn hành vi (behavior-preserving) trong tiến trình tái cấu trúc [45]. Nhóm các phép tái cấu trúc còn lại liên quan quan đến (LUAN.624801 TIEU LUAN MOI download : skknchat@gmail. Kiến thức cơ sở 12 các hoạt động phức tạp hơn và được cấu thành từ sự kết hợp các phép tái cấu trúc nguyên thủy theo các cách khác nhau [14] như tuần tự (chaining) hoặc lặp (iteration).

Nói cách khác, các phép tái cấu trúc phức hợp thường được tạo ra từ một tập có thứ tự các phép tái cấu trúc nguyên thủy. Như vậy, các hoạt động tái cấu trúc rất đa dạng và phức tạp, việc áp dụng các phép toán nào trên những chế tác phần mềm nào là một trong những thử thách và phụ thuộc vào các yếu tố như kinh nghiệm và tầm nhìn của người phát triển hệ thống.2 Mô hình hướng đối tượng Mô hình hướng đối tượng biểu diễn một hệ thống có tính logic của các đối tượng có trong thế giới thực cùng với các ràng buộc của các đối tượng này và các mối quan hệ tương quan giữa chúng [11]. Mô hình hướng đối tượng thường được biểu diễn bởi biểu đồ lớp trong UML (mô tả cấu trúc tĩnh của hệ thống) và được tạo thành từ các phần tử chính sau đây: (1) Lớp: là tập hợp các đối tượng có cùng các thuộc tính (attributes) và phương thức (methods). Mỗi đối tượng phải thuộc về một lớp nào đó và là một thể hiện của lớp đó.

Trong lập trình hướng đối tượng, câu lệnh khai báo ra một lớp mới tương đương với việc tạo ra môt kiểu dữ liệu trừu tượng hoặc một kiểu dữ liệu nguyên thủy (kiểu số nguyên (integer), kiểu xâu (string), hay kiểu logic, v. – Phương thức (Methods): dùng để biểu diễn hành vi (behavior ) của lớp (các phương thức thường thao tác trên trạng thái của đối tượng). (2) Mối quan hệ giữa các lớp: trong mô hình hướng đối tượng, các lớp thường tương tác với nhau theo những cách riêng và bao gồm rất nhiều loại liên kết logic. Trong luận án này, chúng tôi quan tâm đến một số loại liên kết sau đây: (LUAN.624801 TIEU LUAN MOI download : skknchat@gmail.

Kiến thức cơ sở 13 – Kết hợp (Association): là một quan hệ cấu trúc mô tả một tập hợp các liên kết (links), mỗi liên kết tạo ra sự kết nối giữa các đối tượng; – Tụ hợp (Aggregation): là dạng đặc biệt của kết hợp, diễn đạt cho quan hệ cấu trúc giữa một tổng thể và các bộ phận của nó; – Hợp thành (Composition): là dạng đặc biệt của tụ hợp, trong đó nếu đối tượng tổng thể bị hủy bỏ thì các đối tượng bộ phận của nó cũng bị hủy bỏ theo; – Hiện thực hóa (Realization): là quan hệ ngữ nghĩa giữa các phân lớp (classifiers), trong đó một phân lớp sẽ đặc tả cam kết mà phân lớp kia phải đảm bảo đáp ứng và thực thi. Quan hệ hiện thực hóa mà chúng ta thường gặp là quan hệ giữa các giao diện và lớp hay thành phần thực thi, hoặc quan hệ giữa các ca sử dụng và các cộng tác hiện thực hóa chúng; – Tổng quát hóa (Generalization): là loại quan hệ đặc biệt hóa/khái quát hóa trong đó các đối tượng của phần tử đặc biệt hóa là có thể được thay thế bởi các đối tượng của phần tử khái quát hóa. Theo cách này, phần tử con sẽ kế thừa và chia sẻ cấu trúc và hành vi của phần tử cha; – Sự phân cấp (Class Hierarchy): sử dụng để định nghĩa mối quan hệ kế thừa giữa các lớp. Ràng buộc thường được đặc tả bởi các biểu thức logic (Boolean expression) và phải đánh giá cho là đúng hoặc sai, đồng thời phải được thỏa mãn với một thiết kế chính xác của hệ thống.

Các ràng buộc liên quan đến biểu đồ lớp được phân thành ba loại như sau: – Bất biến của lớp (Class invariants): là ràng buộc định nghĩa trên các thuộc tính của lớp và phải được thỏa mãn bởi bất kì một thể hiện nào của lớp; – Tiền điều kiện của phương thức (Pre-condition of a method ): là điều kiện mà phương thức cần phải thỏa mãn trước khi nó được thực hiện; (LUAN.624801 TIEU LUAN MOI download : skknchat@gmail.