Tìm hiểu hỗ trợ của USE về định nghĩa các metamodel và các ràng buộc OCL để đảm bảo tính đúng đắn (wellformedness) của các mô hình

Nhóm 2 BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC CÔNG NGHỆ -ĐHQGHN KHOA :CNTT BÁO CÁO Môn học các vấn đề hiện đại của CNPM Đề Bài: Tìm hiểu hỗ trợ của USE về định nghĩa các metamodel và các ràng buộc OCL để đảm bảo tính đúng đắn (wellformedness) của các mô hình Giáo viên: o Ts Đặng Đức Hạnh o Ts Vũ Diệu Hương Nhóm thực hiện: nhóm 2: o Nghiêm Ngọc Quyết o Nguyễn Minh Tiến Nhóm 2 Phân công công việc:  Nghiêm Ngọc Quyết tìm hiểu về Metamodel và hỗ trợ của USE về metamodel.  Nguyễn Minh tiến tìm hiểu các ràng buộc OCL để đảm bảo tính đúng đắn của mô hình Nhóm 2 MỤC LỤC A, ĐẶT VẤN ĐỀ ........................................................................................................................4 B, NỘI DUNG .............................................................................................................................4 Chương 1: Tổng Quan về Metamodel và OCL .........................................................................4 1.1Tổng quan về Metamodel: ...............................................................................................4 1.1.2 Metamodel và model: ..................................................................................................6 1.2, Tổng quan về OCL- Object Constraint Language: .........................................................8 1.2.1 OCL là gì: ...................................................................................................................8 1.2.2 Cú pháp OCL: .............................................................................................................9 Chương 2: Hỗ trợ của USE về UML metamodel và OCL ....................................................... 12 (lấy UMLcore13 trong USE làm ví dụ) .................................................................................. 12 2.1 UML metamodel: ......................................................................................................... 12 2.2 các ràng buộc OCL: ...................................................................................................... 18 2.3 Một số ví dụ về các ràng buộc OCL trong Metamodel: ............................................. 21 Tài liệu tham khảo: .................................................................................................................... 25 Nhóm 2 A, ĐẶT VẤN ĐỀ UML là ngôn ngữ mô hình hóa thống nhất, biểu diễn các đối tượng bằng các kí hiệu trực quan. Nhưng UML có nhược điểm là nó không thể hiện được hết các khía cạnh của hệ thống. Vì vậy người ta phải dùng thêm OCL để mô tả các ràng buộc cho các đối tượng của mô hình UML. USE là một hệ thống đặc tả hệ thống thông tin. Nó được sử dụng để kiểm tra tính đúng đắn của một mô hình UML bằng các ràng buộc OCL. Để làm được điều đó USE sử dụng các cấu trúc của UML metamodel và các ràng buộc OCL để có thể kiểm tra tính đúng đắn của một mô hình UML. Sau đây chúng e xin trình bày chủ đề :“Hỗ trợ của USE về định nghĩa các metamodel và các ràng buộc để đảm bảo tính đúng đắn (wellformedness) của các mô hình”. Cụ thể trong bài này chúng em sẽ làm về UML metamodel(UMLcore1.3). B, NỘI DUNG Chương 1: Tổng Quan về Metamodel và OCL 1.1Tổng quan về Metamodel: 1.1.1, Mô hình metamodeling 4 tầng: Mô hình metamodeling dựa trên nguyên lý sử dụng các ngôn ngữ mô hình hóa để mô tả một hệ thống ở các cấp độ khác nhau. Nó gồm có 4 tầng:  Tầng metametamodel(M3).  Tầng metamodel (M2).  Tầng model(M1).  Tầng instance(M0). Nhóm 2 Hình 1. Mô hình Modeling Trên đỉnh của kiến trúc metamodeling là meta-metamodel .Nó là một framework và ngôn ngữ tự định nghĩa, trừu tượng để đặc tả, xây dựng và quản lý các metamodel trung lập với kỹ thuật. Nó là nền tảng để xác định bất kỳ một ngôn ngữ mô hình hóa nào như UML hoặc thậm chí là bản thân chính nó.. Mục tiêu chính của cấu trúc bốn tầng với một meta-metamodel chung là nhằm hỗ trợ nhiều metamodel và model, nhằm cho phép khả năng mở rộng, tích hợp và quản lý model và metamodel chung. Mọi metamodel, tiêu chuẩn hoặc tùy chỉnh (do người sử dụng định nghĩa), được xác định bởi metametamodel đều được đặt trên tầng M2. Một trong số đó là UML, một ngôn ngữ mô hình đồ họa cho việc đặc tả các hệ thống phần mềm. Với các UML profile, các khái niệm UML cơ bản (Class, Association, v.v.) có thể được mở rộng với những khái niệm mới (stereotype) và thích nghi với nhu cầu của một sự mô hình hóa cụ thể. Các mô hình của thế giới thực, được biểu diễn bởi các khái niệm được định nghĩa trong metamodel tương ứng tại tầng M2 (ví dụ như metamodel UML) nằm ở tầng M1. Cuối cùng, tại tầng M0, là những thứ từ thế giới thực đã được mô hình hóa trong tầng M1. Ví dụ như: MOF Class (tại tầng M3) được dùng để định nghĩa khái niệm UML Class (M2), UML Class được dùng để xác định khái niệm Person (M1), và Tom, Dick và Harry (UML Objects) biểu diễn cho thực tế (M0). Nhóm 2 1.1.2 Metamodel và model: UML bao gồm UML metamodel và UML model. UML metamodel giữ chức năng định nghĩa các thành tố và cú pháp UML. UML model mô tả ký hiệu các thành tố và các lược đồ dựa trên UML metamodel. Model là một mô tả hoặc một đặc tả hệ thống và môi trường của nó theo một ngữ cảnh nào đó. Model thường được thể hiện kết hợp hình vẽ (drawing) và chữ (text). Text có thể là ngôn ngữ mô hình hóa (modeling language) hoặc ngôn ngữ tự nhiên (natural language). UML model sử dụng các phần tử mô hình (phần từ cấu trúc, phần tử hành vi, phần tử nhóm gộp, phần tử chú thích)và các qui tắc liên kết các phần tử mô hình đó lại để mô hình hóa một hệ thống. UML model thường miêu tả hệ thống theo hướng đối tượng (object). Hình 2. Định nghĩa Model [Jean Bézivin, Introduction to Model Engineering] Meta Model định nghĩa cú pháp (syntax) và ngữ nghĩa (semantic) của Model. UML metamodel cung cấp một cái nhìn chặt trẽ về cú pháp và ngữ nghĩa của UML. Nó giải thích tất cả các khái niệm của UML model bằng mô hình(coi mỗi khái niệm là một class). Ví dụ: Class Attribute, class Operation, class Association…… Hình 3. Định nghĩa Meta Model [Jean Bézivin, Introduction to Model Engineering] Nhóm 2 Hình 4. Metamodel UML  Ví dụ về một UML model và UML metamodel tương ứng: Hình 5.UML model. Nhóm 2 Hình 6.UML metamodel. 1.2, Tổng quan về OCL- Object Constraint Language: 1.2.1 OCL là gì: 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 không thể hiện được hết các khía cạnh của hệ thống phần mềm. Chính vì thế, OCL đượ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 trong thực tế. OCL được sử dụng để:  Mô tả sự bất biến trong các lớp và bên trong mô hình lớp.  Mô tả tiều điều kiện và hậu điều kiện cho các phương thức.  Đặc tả ràng buộc của các thuộc tính lớp và các phương thức. Nhóm 2 Hình 7. Ví dụ về OCL 1.2.2 Cú pháp OCL:  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à Person: context Person Từ khóa seft 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: Nhóm 2 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,...)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ụ : Nhóm 2 context Job::increase( perCent : Integer ) pre: 00 và <=100 post: salary=salary@pre*(1+perCent/100) – hậu điều kiện giá trị salary  Kiểu tập hợp và các phép toán trên tập hợp: Kiểu tập hợp Ý nghĩa Set Tập bao gồm các phần tử toán học. Các phần tử trong tập hợp không được lặp lại. OrderedSet Là một Set. Nhưng các phần tử được sắp xếp theo thứ tự. Bag Là một tập hợp các phần tử cho phép sự lặp lại các phần tử. Sequence Tập bao gồm các phần tử được sắp xếp, và cho phép một phần tử được xuất hiện nhiều lần.  Các phép toán trên Collection: Phép toán Giá trị trả về Ý nghĩa =(c: Collection(T)) Boolean Trả về true nếu 2 tập hợp cùng kiểu và cùng có số lượng phần tử, thứ tự phần tử. (c:Collection(T)) Boolean Trả về true nếu 2 tập hợp không bằng nhau c->size() Interger Số lượng phần tử có trong tập hợp c->includes(object : T) Boolean true nếu object là một phần tử của tập hợp c->excludes(object : T) Boolean Trả về giá trị true nếu object không thuộc tập hợp c Nhóm 2 Page 12 Chương 2: Hỗ trợ của USE về UML metamodel và OCL (lấy UMLcore13 trong USE làm ví dụ) USE muốn kiểm tra tính đúng đắn của mô hình thì nó sẽ làm theo các bước sau:  Chuyển mô hình UML về dạng metamodel tương ứng  Áp dụng các ràng buộc OCL để kiểm tra tính đúng đắn của các UML metamodel thu đượcSử dụng một số thay đổi cú pháp nhỏ bằng các cú pháp USE theo các luật sau: 1. Nếu một association không có tên thì thêm tên. 2. Nếu tên trùng với các từ khóa trong USE thì thêm gạch dưới 3. Thêm () khi gọi một phương thức không có tham số. 4. Thay thế tất cả các lần xuất hiện tiềm ẩn của collect bằng lời gọi rõ ràng 5. Thay thế tất cả các lần xuất hiện tiềm ẩn của collection flattening bằng cách sử dụng operation flatten. 6. Thay thế lần xuất hiện boolen enumeration với kiểu Boolean OCL. 2.1 UML metamodel: UMLCore bao gồm các thành tố cốt lõi và được mô tả bởi bốn mô hình là sườn (Backbone), quan hệ (Relationships), phụ thuộc (Dependencies)và Classifiers . Core giới thiệu cú pháp cho mô hình hóa tĩnh, không quan tâm đến quá trình vận động và tương tác giữa các đối tượng trong thế giới thực. 2.1.1 Mô hình Backbone (sườn) : Nhóm 2 Page 13 Backbone chủ yếu định nghĩa thành tố Classifier. Classifier là thành tố trừu tượng đóng vai trò tổng quát hóa trực tiếp của phần lớn các thành tố cụ thể khác. Ngoài ra, các thành tố cụ thể cơ bản của UML được định nghĩa trong Core bao gồm thuộc tính (attribute), phương thức (operation) và cách thực hiện phương thức (method), tham số (parameter) và ràng buộc (constraint). Để phục vụ cho quá trình định nghĩa Classifier, UML đưa ra các thành tố trừu tượng có vai trò là tổng quát hóa (trực tiếp hay gián tiếp) của Classifier. Các thành tố này có quan hệ với nhau và có quan hệ với Classifier được mô tả trong mô hình Backbone bao gồm:  Element: là một thành tố trừu tượng ở mức cao nhất, tổng quát nhất trong các thành tố UML  ModelElement: là thành tố được định danh trong mô hình và là tổng quát hóa cấp cao nhất thứ 2 cho các thành tố các sau Element. ModelElement là thành tố được xác định theo tên Nhóm 2 Page 14  Namespace: là tập hợp các thành tố ModelElement với điều kiện định danh của một ModelElement trong một Namespace là duy nhất  GeneralizableElement: là thành tố có thể tham gia vào quan hệ tổng quát hóa. Một GeneralizableElement có thể tổng quát hóa một GeneralizableElement khác.  Feature: mô tả đặc tính của một Classifier chủ yếu là tầm vực(visibility) của đặc tính. Tầm vực này xác định một đặc tính của Classifier có thể được tham chiếu đền Classifier khác hay chỉ được sử dụng bởi chính Classifier chứa đặc tính đó.  StructuralFeature: được thừa kế từ Fearture, StructuralFeature mô tả đặc tính về mặt cấu trúc của một Classifier, mô tả cấu trúc này có thể thay đổi hay cố định qua thuộc tính changeability của StructuralFeature. StructualFeature có một đặc biệt hóa là thuộc tính (Attribute).  BehavioralFeature: Được kế thừa từ Feature và biểu diễn các đặc tính về mặt hành vi của một Classifier đồng thời mô tả đặc tính hành vi này có ảnh hưởng lên trạng thái của Classifier hay không qua thuộc tính isQuery. BehavioralFeature gồm hai đặc biệt hóa là phương thức (Operation) và Method. Attribute (thuộc tính) : Attribute mô tả các giá trị mà một Classifier có thể sử dụng để thể hiện trạng thái.  Operation (phương thức) : Operation là phương thức có thể được yêu cầu từ một Classifier chứa Operation để tác động lên Classifier này. Operation có quan hệ kết hợp (association) với tham số (parameter) nghĩa là Operation sử dụng một tập tham số để khởi đầu cho việc thi hành. Một Operation có thể được kế thừa từ các Operation khác.  Method (mô tả phương thức) : Method có quan hệ kết hợp với phương thức (Operation) mô tả cụ thể cách thức thực hiện một phương thức bao gồm các quy trình và các thuật toán. Method có tác động đến kết quả của phương thức.  Parameter (tham số) : Parameter là tham số có thể thay đổi, gởi và nhận. Một Parameter có thể bao gồm tên, kiểu dữ liệu và quan hệ với các thành tố khác giao tiếp với nó. Parameter được sử dụng trong mô tả phương thức (Operation), mẫu (Templates)... Nhóm 2 Page 15  Constraint (ràng buộc) : Constraint là các điều kiện về mặt ngữ nghĩa hay các giới hạn cho một thành tố, có thể diễn tả ở dạng văn bản hay một biểu thức logic của một ngôn ngữ mô tả ràng buộc. Ngoài việc định nghĩa thành tố ràng buộc Constraint, UML còn định nghĩa một ngôn ngữ cho mô tả ràng buộc là ngôn ngữ ràng buộc đối tượng (Object Constraint Language). Giữa các Classifier có quan hệ tổng quát hóa. Do Classifier là thành tố trừu tượng nên tất cả các thành tố thừa kế Classifier đều có tính chất này. 2.1.2. Mô hình Relationships (các quan hệ) : Mô hình Relationships định nghĩa các quan hệ giữa các thành tố UML bao gồm hai loại quan hệ cơ bản là quan hệ tổng quát hóa (generalization), quan hệ kết hợp (association). Quan hệ tổng quát hóa (generalization) là sự liên hệ giữa hai thành tố đặc biệt hơn và tổng quát hơn. Định nghĩa quan hệ kết hợp (Association) và Classifier tham gia vào mối kết hợp (AssociationEnd).  GeneralizationElement(phần tử tổng quát hóa): kế thừa lớp Classifier. Các đối tượng thuộc lớp này tham gia vào quá trình tổng quát hóa. Thành tố đặc biệt hơn Nhóm 2 Page 16 gọi là thành tố con (child) và thành tố tổng quát hơn là thành tố cha (parent). Thành tố con tham gia vào quan hệ tổng quát hóa. Thành tố cha tham gia vào quan hệ tổng quát hóa.  Association: quan hệ kết hợp của các Classifier với nhau.  AssociationEnd: vai trò của từng Classifier trong một mối quan hệ.  AssociationClass: là lớp kế thừa Class, được sinh ra để làm rõ ý nghĩa của quan hệ kết hợp. 2.1.3. Mô hình Classifiers (các đặc biệt hóa của classifiers) : Mô hình Classifiers mô tả các đặc biệt hóa của Classifier bao gồm các thành tố lớp (Class), giao diện (Interface), kiều dữ liệu (DataType), nút (Node) và thành phần (Component) Component bao gồm nhiều thành ModelElement.  Class: là tập hợp các đối tượng có cùng các thuộc tính, hành động và ngữ nghĩa.  Interface: là tập các phương thức (operation) của một Classifier. Mỗi Interface cung cấp một dịch vụ của Classifier bao gồm một nhóm các operation có quan hệ với Interface đó. Mỗi Classifier có thể cung cấp nhiều dịch vụ khác nhau qua các Interface khác nhau.  DataType: mô tả kiểu dữ liệu của người sử dụng. Nhóm 2 Page 17  Node: là thành tố đại diện cho một tài nguyên vật lý có bộ nhớ và khả năng xử lý tính toán.  Component: là một phần riêng biệt ở mức vật lý của hệ thống. Component đóng gói các phương thức xử lý và cung cấp tập các dịch vụ xử lý này qua một tập giao diện (interface)khác nhau. Mỗi giao diện bao gồm nhiều phương thức khác nhau để phục vụ cho một mục đích cụ thể. Các phương thức có thể là các đoạn mã thi hành được, các script hay lệnh. Một component thường cung cấp nhiều loại dịch vụ khác nhau liên quan đến một đối tượng cụ thể. 2.1.4 Mô hình Dependencies (các quan hệ phụ thuộc) :  Dependency: mô tả sự phụ thuộc chức năng giữa hai thành phần cho và thành phần nhận. Thành phần cho đóng vai trò cung cấp dịch vụ cho thành phần nhận. Dependency định nghĩa phụ thuộc giữa hai thành tố ModelElement nên hầu như tất cả các thành tố cụ thể thừa kế ModelElement đều có thể có quan hệ phụ thuộc.  Binding: định nghĩa quan hệ giữa một mẫu (Template) là thành phần cho của Dependency với một thành phần được tạo từ Template đó là thành phần nhận của Dependency. Binding bao gồm các đối số phù hợp với các tham số của Template.  Abstraction: mô tả mối liên hệ giữa các thành tố ở các mức trừu tượng hóa khác nhau. Ví dụ như chuyển một khái niệm ở mức phân tích sang mức thiết kế bằng quan hệ Abstraction. Nhóm 2 Page 18  Permisson: cung cấp quyền hạn cho một thành tố ngoài không gian các thành tố (Namespace) tham chiếu các thành tố khác trong Namespace. Thành tố nhận là một ModelElement thành tố cho bắt buộc là một Namespace. Usage là quan hệ giữa một thành tố ModelElement có sử dụng phương thức của một thành tố ModelElement khác. 2.2 các ràng buộc OCL:  Ngữ cảnh Association:  Vai trò của từng Classifier(AssociationEnd) phải có tên duy nhất trong từng quan hệ liên kết(Association).  Nhiều nhất có thể có 1 AssociationEnd là tập hợp.  Nếu quan hệ liên kết(Association) có 3 hay nhiều hơn các AssociationEnd thì sẽ không có AssociationEnd nào là tập hợp hoặc thành phần.  Các Classifier ứng với từng AssociationEnd tham gia kết nối phải nằm trong không gian tên của quan hệ liên kết(Association).  Ngữ cảnh AssociationClass:  Tên của AssociationEnds và không được trùng nhau.  AssociationClass không thể được định nghĩa giữa chính nó và một cái khác.  Ngữ cảnh AssociationEnd:  Classifier tương ứng với AssociationEnd không thể là một Interface hoặc DataType nếu hướng của Association tới nó là kết thúc.  An Instance may not belong by composition to more than one composite Instance.  Ngữ cảnh BehavioralFeature:  Tất cả các tham số phải có một tên duy nhất.  Các loại tham số phải nằm trong không gian tên của Classifier.  Ngữ cảnh Binding: Nhóm 2 Page 19  Đối số của một ModelElement phải phù hợp, cùng loại với tham số của ModelElement tương ứng.  A Binding has one client and one supplier.  Một ModelElement có thể tham gia vào nhiều nhất một Binding trong vai trò một client.  Ngữ cảnh Class:  Trong một class cụ thể, mỗi một phương thức phải được miêu tả trong một memod miêu tả đầy đủ.  Một lớp chỉ có thể chứa Classes, Associations, Generalizations, UseCases, Constraints, Dependencies, Collaborations, DataTypes, and Interfaces như một không gian tên.  Ngữ cảnh Classifier:  Không có BehavioralFeature cùng loại nào được giống nhau về chữ kí trong cùng một Classifier.  Không có một thuộc tính nào được có tên giống nhau trong cùng một Classifier.  Không có một AssociationEnd nào được có tên giống nhau trong cùng một Classifier.  Tên của một thuộc tính không thể giống như tên của một AssociationEnd hoặc tên của một ModelElement trong cùng một Classifier.  Với mỗi Operation được đặc tả thực hiện trong một Classifier, thì Classifier phải có một hoạt động phù hợp.  All of the generalizations in the range of a powertype have the same discriminator.  Phân biệt tên phải khác tên thuộc tính và tên AssociationEnd đối diện.  Ngữ cảnh Component:  Một thành phần chỉ có thể chứa các thành phần khác  Một thành phần chỉ có thể chứa DataTypes, Interfaces, Classes,Associations, Dependencies, Constraints, Signals, DataValues and Objects.  Ngữ cảnh Constraint  Không thể áp dụng Constraint cho chính nó  Ngữ cảnh DataType: Nhóm 2 Page 20  DataType chỉ có thể chứa các Operations, tất cả phải được truy vấn.  Một DataType không thể chứa bất kì các ModelElement nào khác.  Ngữ cảnh GeneralizableElement:  Phần tử root không thể là con của bất cứ thành phần nào (Generalizations).  Phần tử con nhất không thể là cha của bất cứ phần tử nào.  Không được phép kế thừa vòng tròn.  Phần tử cha phải được bao gồm trong không gian tên của GeneralizableElement.  Ngữ cảnh Interface: Một Interface chỉ có thể chứa các Operation Một Interface không thể chứa bất kì một ModelEthement nào Tất cả các tình năng (Features) được định nghĩa trong Interface phải là public (công khai)  Ngữ cảnh Method:  Nếu các Opetation là một truy vấn thì sau đó phải nêu ra Method.  Chữ kí của Method tương ứng với chữ kí của Operation tương ứng với nó.  Khả năng hiển thị của Method tương ứng với Opetation tương ứng với nó.  Các Operation được thực hiện phải là một tính năng có kế thừa trong cùng một Classifier giống như phương pháp.  Ngữ cảnh Namespace:  Nếu một yếu tố không phải là một Association hoặc Generalization thì tên của nó phải là duy nhất trong không gian tên.  Tất cả các Association phải có sự kết hợp giữa tên của nó và Classifier tương ứng trong không gian tên.  Ngữ cảnh StructuralFeature:  Các loại kết nối bao gồm không gian tên của chủ sở hữu. Nhóm 2 Page 21  Các loại của một StructuralFeature phải là một Class, DataType or Interface. 2.3 Một số ví dụ về các ràng buộc OCL trong Metamodel: Các loại lỗi thường gặp của mô hình UML:  Lỗi cú pháp :sai chính tả của các từ khóa và tên hoạt động tiêu chuẩn.  Không nhất quán:không có tối đa hoạt động được xác định trên đa dạng.  Gỡ lỗi kiểm tra: union các bộ với các loại phần tử không tương thích. 2.3.1Một số ràng buộc trong Association: Hình 10: Association  Các Association phải có một tên duy nhất Nhìn hình vẽ 10 ta thấy các association đều có tên hoàn toàn khác biệt nhau o Cú pháp ràng buộc OCL: inv Association1: self.allConnections()->forAll( r1, r2 | r1.name = r2.name implies r1 = r2 )  Nhiều nhất là 1 AssociationEnd có thể là một tập hoặc một thành phần o Cú pháp ràng buộc OCL: Nhóm 2 Page 22 inv Association2: self.allConnections()->select(ae : AssociationEnd | ae.aggregation_ #none)->size <= 1  Nếu có lớn hơn hoặc bằng 3 AssociationEnd thì sẽ không có AssociationEnd nào là một tập hoặc một thành phần được o Cú pháp ràng buộc inv Association3: self.allConnections()->size >=3 implies self.allConnections()->forAll(ae : AssociationEnd | ae.aggregation_ = #none) 2.3.2 Một số ràng buộc trong Generalizations:  Một root thì không thể Generalizations tới chính nó : Hình 11 : UML metaclass Như trong hình 1 root là gốc rễ của metaclass này, nó không có lớp cha trong hệ thống phân cấp của các phần tử UML. Đây là lớp cha cho tất cả metaclass trong kết cấu hạ tầng của UML o Cú pháp ràng buộc OCL : inv GeneralizableElement1: self.isRoot implies self.generalization->isEmpty Nhóm 2 Page 23  Ràng buộc không một Genaralizations nào có thể có một Genaralization cha nào đến một phần tử chỉ là một lá o Cú pháp ràng buộc OCL : inv GeneralizableElement2: self.parent()->forAll(s | not s.isLeaf)  Không được phép thừa kế theo vòng tròn Giải sử ta có 3 lớp A,B,C không thể xảy ra trường hợp lớp A kế thừa lớp B, Lớp B kế thừa lớp C và lớp C lại kế thừa lớp A được o Cú pháp OCL : inv GeneralizableElement3: not self.allParents()->includes(self) 2.3.3 Một số ràng buộc trong Interface:  Một Interface chỉ chứa các operation Trong UML một class đã là interface thì class đó chỉ chứa các operation Hình 12 : Biểu đồ class diagram Nhóm 2 Page 24 Như trong hình 2 thì lớp Account là lớp có kiểu > do đó lớp này chỉ chứa các Operation mà không chứa các Attributes o Cú pháp ràng buộc OCL : inv Interface1: self.allFeatures()->forAll(f | f.oclIsKindOf(Operation) ) -- f.oclIsKindOf(Operation) or f.oclIsKindOf(Reception)) Ngoài ra một interface còn không chứa bất kì một ModelElement nào. Ở đây có thể hiểu tất cả các Operations trong interface class đều không chứa nội dung. Ví dụ : Trong class Account trong hình 2 chỉ được định nghĩa Operation : public double getBalance(); Nhưng không được định nghĩa như sau : public double getBalance(){ this.balance = balance; } o Cú pháp ràng buộc OCL : inv Interface2: self.allContents()->isEmpty  Tất cả các Features được định nghĩa trong interface đều phải ở dạng public Ví dụ trong hình 2 : Tất cả các Operation đều ở dạng public o Cú pháp ràng buộc OCL : inv Interface3: self.allFeatures()->forAll ( f | f.visibility = #public ) 2.3.4 Một số ràng buộc trong DataType: Nhóm 2 Page 25 Hình 14 : DataType DataTypes định nghĩa các kiểu dữ liệu dùng riêng trong UML metamodel, nghĩa là thuộc tính của các thành tố trong UML metamodel có các kiểu dữ liệu trong DataTypes. DataTypes cần thiết cho sự tham khảo sâu hơn về các thuộc tính và ý nghĩa mỗi thuộc tính của một thành tố trong UML metamodel và nó có một số ràng buộc như sau :  Một DataType không thể chứa bất kì một ModelElement nào khác o Cú pháp ràng buộc OCL : inv DataType2: self.allContents()->isEmpty  Một DataType chỉ có thể chứa Operations, tất cả đều phải được truy vấn o Cú pháp ràng buộc OCL: inv DataType1: self.allFeatures()->forAll(f | f.oclIsKindOf(Operation) and f.oclAsType(Operation).isQuery) Tài liệu tham khảo:  q=Mark+Richters+and+Martin+Gogolla.+A+metamodel+for+OCL.+In+Robert+Fr ance+and+Bernhard+Rumpe,+editors,+Proceedings+of+the+Second+International +Conference+on+the+Unified+Modeling+Languag#v=onepage&q&f=false  Nhóm 2 Page 26  alloy.1233474.html  file UMLcore13.use trong USE