Tài liệu Đề 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 pdf

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: 0<perCent and perCent<=100 – tiền điều kiện đảm bảo percent>0 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 <<interface>> 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
