Đề 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

Chia sẻ: Nguyen Tuan Anh | Ngày: | Loại File: PDF | Số trang:26

Thêm vào BST

Báo xấu

103
lượt xem 26
download

Đề 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

Mô tả tài liệu

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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à...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Đề 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

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:  N ghiêm N gọc Quyết tìm hiểu về Metamodel và hỗ trợ của USE về metamodel.  N guyễ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 Một số ví dụ về các ràng buộ c OCL trong Metamodel: ............................................. 21 2.3 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í h iệ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 m etamodel(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 n gô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 n iệ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 ụ n hư: 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 ể h iệ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ữ n ghĩ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 n gười ta nh ận ra rằng, chỉ với hệ thống ký h iệu trực quan trong UML không thể h iệ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 ể h iệ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 n gữ 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 ể h iệ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 b iế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. Ý n ghĩa : Mọi thể h iệ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 ể h iệ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 b iể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 ) p re: 0includes(object : Boolean T) Trả về giá trị true nếu object khôn g thu ộc tập c->excludes(object : Boolean hợp c T)
Nhóm 2 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) : Page 12
Nhóm 2 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 Page 13
Nhóm 2  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)... Page 14
Nhóm 2  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 Page 15
Nhóm 2 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. Page 16
Nhóm 2  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. Page 17
Nhóm 2  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: Page 18
Nhóm 2  Đố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: Page 19
Nhóm 2  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. Page 20