Ngôn ngữ mô hình hóa cho các yêu cầu bảo mật

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ








CHU THỊ MINH HUỆ









NGÔN NGỮ MÔ HÌNH HÓA
CHO CÁC YÊU CẦU BẢO MẬT

LUẬN VĂN THẠC SĨ













Hà Nội – 2011



ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ






CHU THỊ MINH HUỆ

NGÔN NGỮ MÔ HÌNH HÓA
CHO CÁC YÊU CẦU BẢO MẬT



Ngành : Công nghệ thông tin
Chuyên ngành : Công nghệ phần mềm
Mã số : 60 48 10




LUẬN VĂN THẠC SĨ





NGƯỜI HƯỚNG DẪN KHOA HỌC:
TS. ĐẶNG ĐỨC HẠNH





Hà Nội – 2011
3

MỤC
L
Ụ
C



LỜI CẢM
Ơ
N 1
LỜI CAM Đ
O
AN 2
MỤC
L
Ụ
C
3
DANH MỤC KÝ HIỆU, TỪ VIẾT
T
Ắ
T
5
DANH MỤC BẢN
G
6
DANH MỤC HÌNH V
Ẽ
7

MỞ ĐẦU 9
CHƢƠNG 1. TỔNG QUAN VỀ MÔ HÌNH HÓA CHUYÊN BIỆT
M
I
Ề
N 11
1.1. Mô hình hóa mục đích chung và mô hình hóa chuyên biệt
m
iề
n
11
1.1.1. Mô hình
h
óa 11
1.1.2. Mô hình hóa mục đích c
hun
g 12
1.1.2. Mô hình hóa chuyên biệt
miền
13
1.2. Ngôn ngữ mô hình hóa chuyên biệt
miền
16
1.2.1. Biểu diễn mô
h
ì
nh
17
1.2.2. Ràng buộc mô
h

ì
nh
. 17
1.3. Phƣơng pháp xây dựng ngôn ngữ mô hình hóa chuyên biệt miền (DS
M
L
) 18
1.4. Một số công cụ hỗ
trợ
xây dựng DS
M
L
20
1.4.1. Giới thiệu về các công cụ cho DSML 20
1.4.2. Eclipse f
ra
me
W
o
r
k 21
1.4.2.1. Các dự án cho mô hình hóa của Eclipse 21
1.4.2.2. Phát triển dự án
DSML
với Eclipse 23
CHƢƠNG 2. MÔ HÌNH HÓA CHUYÊN BIỆT MIỀN CHO MIỀN BẢO
M
Ậ
T
30

2.1. Miền bảo
m
ậ
t
30
4

2.1.1. Giới thiệu
về
miền bảo m
ậ
t 30
2.1.2. Điều khiển truy cập dựa trên vai trò (RBAC) 31
2.1.2.1. Core RBAC 32
2.1.2.2.
Hirerarchical
RB
A
C 33
2.1.2.3. Constrained RBAC 34
2.2.
Metamodel
cho bảo mật theo mô hình
R
BA
C
36
2.3. Xác định các luật
ràng
buộc

trên
m
e
t
a
m
o
d
el. 38
CHƢƠNG 3. XÂY DỰNG NGÔN NGỮ CHUYÊN BIỆT MIỀN RBAC TRÊN ELIPSE 40
3.1. Cú pháp
trừu
t
ƣ
ợ
n
g 40
3.2. Cú pháp cụ
t
h
ể 45
3.3. Thêm các
ràng
buộc viết bằng
O
CL
60
CHƢƠNG 4 VẬN DỤNG DSML CHO
R
BA

C
62
4.1. Giới thiệu về phân quyền
trong
diễn
đ
à
n
. 62
4.2. Mô hình hóa các yêu cầu bảo mật của diễn đàn với Tool DSML
R
BA
C
65
KẾT LUẬN VÀ HƢỚNG PHÁT
TR
I
Ể
N
68
TÀI LIỆU THAM
KH
Ả
O
69
5

DANH MỤC KÝ HIỆU, TỪ VIẾT
T
Ắ

T



Từ viết
tắt

Tiếng Anh

Tiếng Việt
ATL
ATLAS Transformation
Language
Ngôn ngữ chuyển ATLAS
DSD
Dynamic Separation of Duty
Tách nhiệm vụ động
DSL
Domain specific language
Ngôn ngữ chuyên biệt miền
DSM
Domain Specific modeling
Mô hình hóa chuyên biệt miền
DSML
Domain specific modeling
language
Ngôn ngữ mô hình hóa
chuyên biệt miền
EMF
Eclipse Modeling Framework

Khung mô hình hóa Eclipse
GMF
Graphical Modeling Framework
Khung mô hình hóa đồ họa
M
2
M

Model-to-Model Transformation
Chuyển mô hình sang mô hình
M2T
Model-to-Text Transformation
Chuyển mô hình sang text
MDD
Model Driven Development
Phát triển hƣớng mô hình
OCL
Object Constraint Language
Ngôn ngữ ràng buộc đối tƣợng
OMG
Object Management Group
Tổ chức quản lý đối tƣợng
QTV
Query/View/Transformation
Truy vấn/ Khung nhìn/ Chuyển

QVTO
QVT Operational Mapping
Language
Ngôn ngữ ánh xạ hoạt động

QVT
QVTR
QVT Relations
Các quan hệ QVT
RBAC
Role-Based Access Control
Kiểm soát truy cập dựa
trên vai trò
RH
Role Hierarchy
Cây kế thừa vai trò
SoD
Separation of Duty
Tách nhiệm vụ
SSD
Static Separation of Duty
Tách nhiệm vụ tĩnh
6

DANH MỤC BẢN
G



Bảng 1.1. Các công cụ cho xây dựng
DSML
[
2
]
20

Bảng 3.1. Các ký hiệu đƣợc xây dựng trong dự án GMF cho DSML RBAC 46





7

DANH MỤC HÌNH V
Ẽ



Hình 1.1. Ví dụ về mô hình
[
6
]
12
Hình 1.2. Mô hình sử dụng UML 13
Hình 1.3. Mô hình kiến trúc phần cứng trong automobiles bằng
DSML EAST-ADL
14
Hình 1.4. Mô hình hóa chuyên biệt miền với mô hình hóa mục đích chung
[
2
]
16
Hình 1.5. Ví dụ về metamodel 17
Hình 1.6.
Ví

dụ về ràng buộc với OCL 18
Hình 1.7. Dự án mô hình hóa Eclipse
[
5
]
21
Hình 1.8. DSL Toolkit artifacts—abstract
[
5
]
24
Hình 1.9. Luồng công việc phát triển DSL
T
ool
k
it
[
2
]
25
Hình 1.10. Các thành phần đƣợc xây dựng trong dự án EMF
[
12
]
26
Hình 1.11. MetaModel đại diện cho tập tối thiểu các thuật ngữ với ecore
[
12
]
27

Hình 1.12. Luồng công việc phát triển dự án G
M
F
[
2
]
28
Hình 1.13. Cửa sổ tiện ích GMF D
a
shbo
ar
d 29
Hình 2.1. Kiểm soát truy cập truyền thống và
RBAC
[
12
]
31
Hình 2.2. Tổ chức các đối tƣợng trong mô hình
RBAC
[
12
]
32
Hình 2.3. Mô hình Core
RBAC
[
6
]
33

Hình 2.4. Mô hình
Hierarchical
RBAC
[
4
]
34
Hình 2.5. Mô hình SSD trong Hierarchy
RBAC
[
6
]
35
Hình 2.6: Mô hình quan hệ DSD
[
6
]
36
Hình 2.7: MetaModel cho RBAC 36
Hình 3.1. Mô hình RBAC.ecorediag 41
Hình 3.2. Mô hình RBAC.ecore 42
Hình 3.3. Mô hình
RB
A
C.gen
m
odel
43
Hình 3.4. Mã nguồn của mô hình tự động sinh từ mô hình RBAC.genmodel 44
8

Hình 3.5.
RBAC.edit
và
RBAC.Editor
đƣợc sinh ra từ genmodel 45
Hình 3.6.Mô hình
B
A
C.g
m
f
g
ra
ph 47
Hình 3.7. Xây dựng PolyLine cho link
R
oleH
a
s
P
e
r
m
ission 48
Hình 3.8. Xây dựng Figure cho Role và Link
R
oleH
a
s

P
e
r
m
ission 49
Hình 3.9. Xây dựng node Roles 50
Hình 3.10 Xây dựng Connection
R
oleH
a
s
P
e
r
m
ission 50
Hình 3.11. Diagram Label RolesName 51
Hình 3.11. Compartment của Node Action 51
Hình 3.12. Mô hình
RBAC.gmftool
đã xây dựng 52
Hình 3.13. Các Node, link Mapping trong RBAC1.gmfmap 53
Hình 3.14. Ánh xạ node Role 54
Hình 3.15. Ánh xạ Node Action và
P
e
r
m
ission 55
Hình 3.16. Ánh xạ Link Role Has

P
e
r
m
ission 56
Hình 3.17. Generate diagram code của dự án GMF RBAC 57
Hình 3.18. Cửa sổ Extensions của Plugin.xml trong dự án GMF RBACG 58
Hình 3.19.
DSML
cho RBAC 59
Hình 3.20. Các luật đƣợc thêm vào mô hình RBAC1.gmfmap 60
Hình 3.21. Thông báo lỗi khi mô hình hóa sai (Vi phạm các lu
ậ
t) 61
Hình 4.1. Nhóm ngƣời dùng trong diễn đ
à
n 62
Hình 4.2. Mô hình hóa yêu cầu bảo mật của hệ thống sử dụng tool
DSML
RBAC 65
Bảng 4.1. Gán quyền cho các vai trò trong mô hình của diễn đàn trong hình 4.1 67





9

MỞ ĐẦU

Các hệ thống phần mềm hiện đại ngày nay càng ngày càng trở lên phức tạp.
Khi phát triển đòi hỏi giảm thời gian, giảm chi phí nhƣng lại phải tăng chất lƣợng
phần mềm để tăng tính cạnh tranh và đáp ứng các nhu cầu sử dụng phần mềm
trên tất cả các lĩnh vực khác nhau của đời sống con ngƣời.
Để giải quyết vấn đề nghịch lý trong phát triển phần mềm ngƣời ta đề xuất
giải pháp phát triển các framework phục vụ cho phát triển phần mềm. Tuy nhiên
những giải pháp đó cũng không đủ để đáp ứng các nhu cầu của ngành công nghiệp
phần mềm và việc phát triển phần mềm vẫn thủ công dựa vào con ngƣời là chủ yếu.
Vì vậy việc nghiên cứu và đƣa ra một giải pháp tăng tính tự động trong phát triển
phần mềm đã đƣợc đề xuất và phát triển. Giải pháp phát triển phần mềm hƣớng mô
hình (MDD) đƣợc xem là một giải pháp phù hợp cho vấn đề gặp phải trong phát
triển phần mềm. Phát triển hƣớng mô hình là đặt mô hình hóa là vấn đề trọng tâm
trong phát triển phần mềm, từ các mô hình sẽ đƣợc dịch chuyển sang mã trƣơng
trình triển khai nhờ bộ sinh mã nguồn (code generator). P hát triển hƣớng mô hình
đặc biệt phù hợp với phát triển các sản phần mềm cùng dòng (software product
line).
Một trong các hƣớng tiếp cận của phát triển hƣớng mô hình là mô hình hóa
chuyên biệt miền (DSM), trong đó việc xây dựng ngôn ngữ mô hình hóa chuyên biệt
miền (DSML) thƣờng đƣợc triển khai dƣới dạng một dự án nhỏ khởi đầu trong một
dự án lớn. K ết quả của dự án mô hình hóa chuyên biệt miền là một ngôn ngữ
m
ô
hình hóa chuyên biệt miền. Ngôn ngữ cho phép mô hình hóa các vấn đề trong dự
án, kết quả thu đƣợc là sự dịch chuyển các mô hình của dự án sang code triển
khai, điều này làm giảm thời gian và chi phí phát triển phần mềm.
Bảo mật đóng một vai trò trung tâm trong phát triển và hoạt động của các hệ
thống phần mềm phân tán với quy mô lớn, nhƣ thƣơng mại điện tử. Bảo mật là một khía
cạnh ngang trong phát triển phần mềm. Nó là vấn đề gặp phải đối với hầu hết các dự án
phần mềm tuy nhiên vấn đề thiết kế bảo mật trong thiết kế tổng thể thƣờng bị bỏ quên

hoặc chỉ tích hợp trong gia đoạn quản trị hệ thống. Hạn chế này là do thiếu công cụ hỗ
trợ kỹ nghệ bảo mật, tích hợp bảo mật thủ công rất khó và thƣờng phát sinh lỗi do ngƣời
phát triển hệ thống thiếu kinh nghiệm vì họ không phải là chuyên gia về bảo mật. Vì vậy
10

việc tích hợp bảo mật trong dự án phần mềm nếu thực hiện đƣợc một cách trực quan và
tự động, sẽ làm giảm chi phí và tăng chất lƣợng của phần mềm [1]
Với những ƣu điểm của mô hình hóa chuyên biệt miền và lợi ích mang lại tícần
thiết phải phát triển một ngôn ngữ cho phép mô hình hóa chính xác các yêu cầu bảo
mật. Xuất phát từ những lý do trên chúng tôi đã lựa chọn đề tài ―Ngôn ngữ mô hình
hóa cho các yêu cầu bảo mật‖. Mục tiêu của đề tài là tìm hiểu phƣơng pháp phát triển
phần mềm hƣớng mô hình với hƣớng tiếp cận là mô hình hóa chuyên biệt miền.
Trong đề tài này chúng tôi tập trung tìm hiểu nền tảng, phƣơng pháp, công cụ phát
triển ngôn ngữ mô hình hóa chuyên biệt miền và cài đặt thử nghiệm cho miền bảo
mật với tool Eclipse. Việc xây dựng bộ sinh code tự động cũng nhƣ tích hợp ngôn
ngữ mô hình hóa chuyên biệt miền với các ngôn ngữ mô hình hóa khác nhƣ
UML hoặc ngôn ngữ mô hình hóa hóa chuyên biệt miền với miền khác, sẽ không
đƣợc xem xét trong đề tài này.
Luận văn đƣợc cấu trúc thành 4 chƣơng nhƣ s
a
u
:

o Chương 1. Tổng quan về mô hình hóa chuyên biệt
m
iề
n


Chƣơng này giới thiệu chung về cơ sở lý thuyết của phƣơng pháp phát t

r
iển
phần mềm hƣớng mô hình với hƣớng tiếp cận là mô hình hóa chuyên biệt miền,
phân tích lợi ích của DSML, cũng nhƣ các công cụ hỗ trợ cho mô hình hóa chuyên
biệt miền.
o Chương 2. Mô hình hóa chuyên biệt miền cho miền bảo
m
ậ
t

Chƣơng này trình bày về miền bảo mật, xác định metamodel, các luật
r
à
ng
buộc cho miền bảo mật theo mô hình điều khiển truy cập dựa trên vai trò của ngƣời
dùng (RBAC).
o Chƣơng 3. Xây dựng ngôn ngữ chuyên biệt miền RBAC
trên
E
cli
p
se
Chƣơng này trình bày về cài đặt và kết quả thử nghiệm
DSML
cho miền b
ả
o
mật trên phần
mềm
mã nguồn mở Eclipse.

o Chƣơng 4. Vận dụng DSML cho RBAC.
Mục tiêu chính của chƣơng này là để kiểm nghiệm kết quả thử nghiệm t
r
ong
chƣơng 3, cho một bài toán thực tế.
o Chƣơng 5. Kết luận và hƣớng phát triển.
11

CHƢƠNG 1. TỔNG QUAN VỀ MÔ HÌNH HÓA CHUYÊN BIỆT
M
I
Ề
N

Trong chương này chúng tôi sẽ tập trung vào trình bày về mô hình hóa
v
à
ngôn ngữ mô hình hóa chuyên biệt miền, phương pháp xây dựng và công cụ hỗ trợ
cho phát triển ngôn ngữ mô hình hóa chuyên biệt miền.
1.1. Mô hình hóa mục đích chung và mô hình hóa chuyên biệt
m
iề
n

Trong quy trình phát triển phần mềm, trong một số giai đoạn có sử dụng các
ngôn ngữ mô hình hóa mục đích chung, để xây dựng các mô hình, ví dụ UML đ
ƣ ợ c s ử d ụ n g để xây dựng các biểu đồ trong pha phân tích và thiết kế hệ thống.
Các mô hình đƣợc mô hình hóa bởi UML thƣờng sử dụng với ý nghĩa làm tài liệu
cho dự án là chính, nếu có phát sinh mã nguồn thì chỉ dừng lại ở mức mã khung, vì
vậy nếu muốn sinh mã nguồn tự động hoàn toàn thì cần sử dụng một ngôn ngữ mô

hình hóa chuyên biệt miền có phạm vi đủ hẹp để hiểu đƣợc miền từ đó sinh mã
nguồn từ miền [2]. Sau đây, chúng tôi sẽ trình bày về mô hình hóa mục đích chung
và mô hình hóa chuyên biệt miền.
1.1.1. Mô hình
h
ó
a
Theo định nghĩa của James Rumbaugh [3] thì mô hình là sự nắm bắt các
thành phần chính trong hệ thống. Và mô hình trực quan là các mô hình mà sử dụng
các ký hiệu đồ họa trong mô hình. Khi đó mô hình sẽ cho phép chúng ta hiểu rõ hơn
về hệ thống mà chúng ta cần phát triển.

Mô hình hóa là một quá trình chuyển thế giới thực thực thành các mô hình
bằng cách bỏ các chi tiết không quan tâm và giữ lại các chi tiết quan tâm biểu diễn
bằng các hình học, khi đó các mô hình sẽ làm cho chúng ta hiểu thế giới thực một
cách dễ dàng hơn. Dƣới đây là một ví dụ về mô hình.





12

1.1.2. Mô hình hóa mục đích
c
hun
g

Trong phát triển phần mềm hƣớng mã nguồn (code - centric), vòng đời phát triển
phần mềm đƣợc chia thành các pha: Xác định yêu cầu, phân tích và thiết kế, lập trình,
kiểm thử với cách tiếp cận này trong pha phân tích và thiết kế có sử dụng ngôn ngữ mô
hình hóa mục đích chung (Ví dụ nhƣ UML) để mô hình hóa phần mềm. Nhƣng không
phải lúc nào phần mềm cũng đƣợc triển khai nhƣ mô hình ban đầu, nếu có sử dụng mô
hình để tự động sinh ra code thì code đƣợc sinh ra thƣờng chỉ là mã khung thô và lập
trình viên cần hoàn thiện tiếp. Các mô hình ở đây mang ý nghĩa làm tài liệu nhiều hơn
mục đích sinh mã nguồn tự động. Hình dƣới đây là một ví dụ về mô hình hóa với UML.
Hình 1.1. Ví dụ về mô hình
[
6
]


13

Ngôn ngữ UML đã đƣợc phát triển tƣơng đối hoàn thiện và đƣợc cung cấp cũng
nhƣ công nhận rộng rãi. Mô hình hóa với UML, khi thay đổi mã nguồn hoặc mô hình
thay đổi cần mất chi phí về thời gian, tài nguyên, tiền bạc để đồng bộ giữa mô hình
và mã nguồn dẫn đến tăng chí phí trong dự án phần mềm [2]. Phƣơng pháp mô hình
hóa chuyên biệt miền có thể khắc phục những nhƣợc điểm trên của phƣơng pháp
mô hình hóa mục địch chung. Mô hình hóa chuyên biệt miền sẽ đƣợc chúng tôi đề
cập trong mục dƣới đây.
1.1.2. Mô hình hóa chuyên biệt
miền

Mô hình hóa chuyên biệt miền
(Domain
Specific modeling - DSM) là sử
dụng ngôn ngữ mô hình hóa chuyên biệt miền để tạo các mô hình và sinh mã
nguồn từ các mô hình đó với bộ sinh code (code generator) [2].
Ngôn ngữ mô hình hóa chuyên biệt miền
(Domain-Specific M
o
d
eli
n
g
Hình 1.2. Mô hình sử dụng UML

14

Language - DSML) là một ngôn ngữ chuyên biệt miền cụ thể nó đƣợc sử dụng để
xây dựng các mô hình đồ họa cho các hệ thống phần mềm. Đ ịnh nghĩa ngôn ngữ mô
hình hóa chuyên biệt miền và bộ sinh code nên đƣợc thực hiện bởi các chuyên gia miền (vì
họ là ngƣời hiểu về miền nhất). Khi đó, họ có thể cung cấp mã nguồn có chất lƣợng cao
cho miền. Quy trình xây dựng bộ sinh code có thể định nghĩa tƣơng đƣơng với việc xây
dựng trình biên dịch cho một ngôn ngữ thứ 3. Định nghĩa này cũng nhấn mạnh hƣớng tiếp
cận phát triển hƣớng mô hình bằng cách tự hạn chế các mô hình đồ họa và không bao gồm
các ngôn ngữ lập trình [2].
Ngôn ngữ chuyên biệt miền
(Domain
specific language - DSL) là một
ngôn ngữ chƣơng trình hoặc ngôn ngữ đặc tả thực thi, bằng cách tích hợp các khái

niệm trừu tƣợng của tri thức miền vào trong ngôn ngữ dƣới dạng các ký hiệu có tính
biểu cảm cao. DSL tăng mức độ trừu tƣợng bằng cách sử dụng các khái niệm
quen thuộc với các chuyên gia miền và thƣờng đƣợc giới hạn trong một miền vấn
đề cụ thể nào đó [2].
Dƣới đây là một ví dụ về mô hình đƣợc mô hình hóa bằng một ngôn ngữ mô
hình hóa chuyên biệt miền.









Hình 1.3. Mô hình kiến trúc phần cứng trong automobiles bằng
DSML EAST-ADL
1

Ngôn ngữ EAST-ADL chuyển các tri thức miền thành các khái niệm của ngôn

1

15

ngữ, các khái niệm đó là ECU, Chanel, Processor, Memory. Các khái niệm này có các
ký hiệu đồ họa riêng và quen thuộc với các chuyên gia miền.
Ý tƣởng chính trong phát triển hƣớng mô hình là tập trung vào các mô hình
trong phát triển phần mềm và các mô hình đó sẽ đƣợc tự động sinh sang mã nguồn
triển khai. Một hƣớng tiếp cận trong phát triển hƣớng mô hình là các mô hình đƣợc

mô hình hóa bằng một ngôn ngữ mô hình hóa chuyên biệt miền. Với hƣớng tiếp cận
này, giai đoạn đầu của dự án cần phát triển ngôn ngữ mô hình hóa chuyên biệt miền.
Ngôn ngữ mô hình hóa chuyên biệt miền đã xây dựng, sẽ đƣợc sử dụng để mô hình
hóa các yêu cầu của phần mềm cần phát triển thuộc miền. Bộ sinh code tự động của
ngôn ngữ sẽ tự động sinh mã chƣơng trình từ các mô hình đã xây dựng. Hiệu quả sinh
code tự động từ mô hình phụ thuộc vào tính đúng đắn của ngôn ngữ mô hình hóa
chuyên biệt miền. Để xây dựng đƣợc ngôn ngữ mô hình hóa chuyên biệt miền đúng
đắn, hiệu quả cao yêu cầu đòi hỏi miền vấn đề không quá lớn để có thể hiểu rõ về
miền, các khái niệm trong miền, mối quan hệ giữa các khái niệm và các nghiệp vụ của
miền [2].
Khi một DSML và bộ sinh code đƣợc định nghĩa đúng đắn bởi các chuyên gia
miền thực sự, DSM tăng tốc việc phát triển phần mềm và giảm số lƣợng lỗi trong
các sản phẩm phần mềm. Với hƣớng tiếp cận này cần bỏ chi phí ban đầu để phát triển
DSML. Vì vậy nếu có ít ứng dụng phát triển trong cùng một miền vấn đề thì có thể
chi phí phát triển theo MDD lại lớn hơn phát triển theo phƣơng pháp truyền thống.
Nhƣng phát triển nhiều ứng dụng trong cùng một miền vấn đề (ví dụ nhƣ một họ sản
phẩm phần mềm), DSM mang lại lợi ích lớn hơn rất nhiều với chi phí xây dựng
DSML và bộ sinh code. Hình dƣới đây minh họa về lợi ích của DSML trong
các dự án phần mềm. Đây cũng chính là vấn đề mấu chốt khi lựa chọn DSM để phát
triển phần mềm hay mô hình hóa mục đích chung với UML để phát triển phần mềm.
Sau khi bỏ chi phí ban đầu để triển khai DSML và bộ sinh code, việc triển các ứng
dụng mới có thể nhanh hơn phƣơng pháp truyền thống từ 5 đến
10 lần [2].

16























Vì vậy khi phát triển các dự án, tùy thuộc vào số lần lặp lại của các dự án thuộc
cùng một miền, cũng nhƣ tổng chi phí của các dự án mà lựa chọn phƣơng pháp phát

triển phần mềm tốt nhất về chi phí.
1.2. Ngôn ngữ mô hình hóa chuyên biệt
miền


Ngôn ngữ chuyên biệt miền có thể đƣợc xây dựng bằng cách sử dụng các
Metamodels hoặc sử dụng Context- free grammar, thông thƣờng thì ngôn ngữ đồ
họa đƣợc phát triển bằng cách sử dụng các metamodels và ngôn ngữ văn bản đƣợc
định nghĩa bởi context – free grammar [2]. Trong tiếp cận của chúng tôi ngôn ngữ mô
hình hóa chuyên biệt miền đƣợc xây dựng trong đó sử dụng các ký hiệu đồ họa để mô
hình hóa các yêu cầu, chúng tôi đã xây dựng một metamodel để định nghĩa mô hình
chuyên biệt miền cho ngôn ngữ. Tuy nhiên mô hình đồ họa không đặc tả đủ chính xác
và rõ ràng vì vậy cần thêm các ràng buộc trên các đối tƣợng để làm chặt chẽ hơn ngữ
nghĩa của mô hình, chúng tôi có sử dụng ngôn ngữ ràng buộc đối tƣợng (Object
constrain language - OCL) để xây dựng các luật ràng buộc trên metamodel.
Hình 1.4. Mô hình hóa chuyên biệt miền với mô hình hóa mục đích chung
[
2
]


17


1.2.1. Biểu diễn mô
h
ì
nh

Metamodel là một mô hình của một ngôn ngữ mô hình hóa. Nó cho phép
chúng ta biểu diễn cú pháp trừu tƣợng của một ngôn ngữ đồ họa, một metamodel sẽ
bao gồm các thành phần nguyên thủy để tạo nên ngôn ngữ mô hình hóa.
MetaModel định nghĩa cú pháp (syntax) và ngữ nghĩa (semantic) của mô hình. Trong
đó mô hình là một thể hiện của metamodel. Ví dụ trong ngôn ngữ mô hình hóa
UML, để có thể tạo đƣợc mô hình (1), thì trong ngôn ngữ cần phải có các thành
phần nguyên thủy là Association, AssocEnd, Class và mô hình (1) là một thể hiện
của metamodel nhƣ mô tả (2). Và metamodel
là (3).

1.2.2. Ràng buộc mô
h
ì
nh
.

Mô hình đồ họa không đủ để đặc tả chính xác và rõ ràng, cần thêm vào các ràng
buộc trên các đối tƣợng, để ràng buộc các đối tƣợng chúng ta sẽ sử dụng các ngôn
ngữ cho phép ràng buộc trên các đối tƣợng mô hình. N gôn ngữ OCL là một trong
các ngôn ngữ cho phép ràng buộc trên các đối tƣợng. Ví dụ nhƣ lớp NhanVien, chúng
ta muốn ràng buộc thuộc tính Tuoi của nhân viên lớn hơn hoặc bằng 21, khi đó mô
hình đồ họa không đủ để diễn tả, chúng ta có thể sử dụng biểu thức OCL để ràng
Hình 1.5. Ví dụ về metamodel
18

buộc nhƣ sau:


Context NhanVien inv:
Self.Tuoi>=21

Hình 1.6.
Ví
dụ về ràng buộc với OCL

OCL không phải là một ngôn ngữ lập trình, không thể viết chƣơng trình
logic hoặc luồng điều khiển trong OCL. OCL là một ngôn ngữ biểu thức, và các
biểu thức OCL không tạo ra hiệu ứng nghĩa là không làm thay đổi trạng thái của các
đối tƣợng. OCL là một ngôn ngữ kiểu mỗi một biểu thức OLC có một kiểu, kiểu trả
về của biểu thức OCL có thể là bất kỳ kiểu nào.

OCL đƣợc sử dụng cho nhiều mục đích khác nhau nhƣ: Ngôn ngữ truy vấn; xác
định tính bất biến trên các lớp và các kiểu trong mô hình lớp; xác định tính bất biến
cho Stereotypes; mô tả tiền điều kiện và hậu điều kiện cho các hoạt động và phƣơng
thức; mô tả Guards; xác định cá ràng buộc cho hoạt động; …
Về cú pháp cũng nhƣ cách xây dựng các biểu thức OCL chúng ta có thể tham
khảo các tài liệu về OCL theo chuẩn của tổ chức OMG [4] .

1.3. Phƣơng pháp xây dựng ngôn ngữ mô hình hóa chuyên biệt miền (DS
M
L
)

Để xây dựng đƣợc một DSML đúng đắn, chúng ta phải nghiên cứu về miền
v
ấ
n
đề ngôn ngữ diễn đạt để từ đó xây dựng cú pháp và ngữ nghĩa cho ngôn ngữ. Để xây
dựng đƣợc DSML chúng ta cần xây dựng cú pháp trừu tƣợng, cú pháp cụ thể, ngữ
nghĩa, để đảm bảo tạo ra một ngôn ngữ đúng đắn cần tạo ra các luật ràng buộc cho
ngôn ngữ. Dƣới đây là các bƣớc cơ bản mà một dự án xây dựng
DSML
phải trải qu
a
.
a) Khảo sát
m
iề
n

Chúng ta sẽ khảo sát miền để tìm kiếm các khái niệm trừu tƣợng đúng đắn và
ánh xạ các khái niệm thuộc miền thành các khái niệm trừu tƣợng. Với cách này giúp
ngăn chặn các lỗi sớm trong giai đoạn thiết kế, giảm công việc đặc tả, và làm cho
ngôn ngữ phù hợp hơn. Mô tả những vấn đề trong thuật ngữ miền vấn đề thay vì các khái
19

niệm triển khai. Các từ trừu tƣợng tốt nhất là chúng ta nên mƣợn những thuật ngữ
thuộc miền. Giai đoạn này cho phép chúng ta thu đƣợc các khái niệm của miền, cách mà
các khái niệm miền tƣơng tác với nhau, và các nghiệp vụ của miền. Để có thể hiểu
đƣợc miền tốt nhất, đúng đắn nhất giai đoạn này cần phải làm việc hợp tác với các
chuyên gia về miền, những ngƣời mà hiểu về miền và nghiệp vụ của miền nhất.
b) Xây dựng
metamodel
và các
ràng bu
ộc
Giai đoạn này, chúng ta sẽ chỉ định các khái niệm mô hình, các thuộc tính của
chúng và các luật ràng buộc sử dụng ngôn ngữ và thực thi mô hình đúng đắn. Chúng ta
sẽ ánh xạ các khái niệm chính của miền (các khái niệm này là kết quả tìm kiếm các khái
niệm trong bƣớc trƣớc) tới các đối tƣợng ngôn ngữ mô hình hóa. Kết quả của giai đoạn
này là chúng ta sẽ xây dựng đƣợc một MetaModel và các ràng buộc trên đó đây chính là
cú pháp trừu tƣợng của DSML.
c) Xác định ký pháp cho ngôn ngữ (
n
o
t
a
t
io

n
)
Ngôn ngữ cần trình diễn trực quan cho ngƣời sử dụng. Nhƣ các biểu đồ, sử dụng
các ký hiệu, biểu tƣợng để đại diện cho các khái niệm khác nhau của ngôn ngữ. Vì
vậy cần xây dựng các ký pháp cho ngôn ngữ. Kết quả của giai đoạn này chính là
chúng ta xây dựng đƣợc cú pháp cụ thể cho DSML bằng cách ánh xạ các khái niệm
trong cú pháp trừu tƣợng tới các ký hiệu đại diện cho nó bằng đồ họa.
d) Thao tác mô
h
ì
nh

Sau khi chúng ta xây dựng đƣợc cú pháp trừu tƣợng và cú pháp cụ thể cho
DSML, chúng ta muốn các mô hình đƣợc mô hình hóa bằng DSML đã xây dựng có
thể chuyển sang mã nguồn thực thi, hoặc kiểm tra mô hình, hoặc sinh tài liệu từ mô
hình thì chúng ta cần xây dựng cho DSML bộ sinh mã nguồn (code generator), sinh
tài liệu (documentation) hoặc kiếm tra mô hình (mode checking).

Để thực xây dựng đƣợc bộ sinh mã nguồn, thì chúng ta cần ánh xạ các khái
niệm mô hình sang code bằng các dự án chuyển mô hình M2T, kết quả của giai đoạn này
là xây dựng bộ sinh mã nguồn tự động cho DSML cho phép dịch chuyển các mô hình đã
đƣợc mô hình hóa bởi DSML sang mã nguồn thực thi. Có thể coi giai đoạn này là
chúng ta đã xây dựng trình biên dịch cho DSML [2].
20

1.4. Một số công cụ hỗ
trợ
xây dựng DS
M
L

1.4.1. Giới thiệu về các công cụ cho
DSML




















Bảng 1.1 trình bày tóm tắt về các Tool cho phát triển DSML. Bảng trên cho
chúng thấy tất cả các tool đều xây dựng cho hệ nền Window, tuy nhiên với GEMS và
MetaEdit+ có thể cho các hệ nền khác. Ngôn ngữ xây dựng Metamodelling của các
Bảng 1.1. Các công cụ cho xây dựng
DSML
[

2
]


21

tool thì khá khác nhau, mỗi một tool dùng một ngôn ngữ khác, ngôn ngữ để định
nghĩa các ràng buộc thì có GEMS cùng nhiều ngôn ngữ có thể là java, OCL…, code
đầu ra của bộ sinh code thì tất cả các tool đều có khả năng sinh code cho bất kỳ ngôn
ngữ nào, riêng DSML tools của Microsoft là VisualBasic và C# [2].
Sau khi xem xét và tìm hiểu các công cụ cho phát triển DSML cũng nhƣ định
hƣớng sau này chúng tôi đã lựa chọn công cụ GEMS để nghiên cứu và cài đặt thử
nghiệm. Phần tiếp theo chúng tôi xin trình bày về công cụ GEMS.
1.4.2. Eclipse f
r
a
me
W
o
r
k

1.4.2.1. Các dự án cho mô hình hóa của
Eclipse

Eclipse là một hệ nền khả mở cho các tool tích hợp. Các tool đƣợc viết Plug- ins.
Hình 1.7. Dự án mô hình hóa Eclipse
[
5
]


22

Eclipse plug-ins đƣợc viết bằng ngôn ngữ java. Eclipse cũng là dự án mã nguồn mở.
Hình 1.7 là hình ảnh đề xuất ban đầu nhƣ là một logo cho dự án mô hình hóa. Hình
dƣới cho chúng ta thấy cấu trúc của một dự án mô hình hóa và các vùng chức năng
của nó. EMF là trung tâm mà cung cấp các khả năng phát triển cú pháp trừu tƣợng.
EMF Query, validation, và Transaction bổ sung chức năng EMF core. Xung quanh các
thành phần phát triển cú pháp trừu tƣợng là các công nghệ model- transformation gồm có
model to text và model to model (QVT và ATL). Bên ngoài là phát triển các cú pháp cụ
thể: GMF sử dụng để trình diễn các mô hình. Cuối cùng một vài dự án xung quanh và
các thành phần trình diễn mô hình có thể khởi đầu từ dự án
mô hình hóa [5].

Dự án mô hình hóa của Eclipse tập trung vào việc tiến hóa và thúc đẩy các công
nghệ phát triển dựa trên mô hình. Cộng đồng Eclipse cung cấp một bộ các Modeling
Frameworks, toolings, và các chuẩn triển khai.
a) Phát
triển
cú pháp
trừu
tƣợng
(abstract
sy
n
t
a
x)

Nhân của DSML là cú pháp trừu tƣợng. Nó đƣợc sử dụng để phát triển hầu hết
các artifacts gồm có graphical concrete syntax, model-to-model transformations, và
model-to-text transformations. Thông thƣờng thì thành phần đầu tiên của một
DSML đƣợc phát triển là cú pháp trừu tƣợng, Elipse cung cấp Eclipse Modeling
Framework (EMF) để xây dựng cú pháp trừu tƣợng.
EMF Project: Cung cấp Famework để xây dựng metamodel biểu diễn cú pháp
trừu tƣợng cho DSML, EMF cho phép chúng ta tinh chỉnh cấu trúc và ngữ nghĩa của
metamodel bằng cách sử dụng ngôn ngữ ràng buộc đối tƣợng OCL, validation [2].
b) Phát
triển
cú pháp cụ thể (
C
o
n
c

r
e
t
e Sy
n
t
a
x)

Cú pháp trừu tƣợng cho một DSML thƣờng đƣợc trình diễn bởi ngƣời con ngƣời
vì vậy ngôn ngữ cần phải đƣợc phát triển cú pháp cụ thể, Eclipse có cung cấp dự án
GMF cho phép phát triển cú pháp cụ thể đồ họa các ký pháp đồ họa sẽ đƣợc ánh xạ
sang cú pháp trừu tƣợng đƣợc phát triển với dự án EMF trong Eclipse [2].
c) Thao tác
trên
mô
h
ì
nh

Để tạo môi trƣờng soạn thảo đồ họa hoặc văn bản cho phép tùy chỉnh. Chúng ta
thƣờng muốn cung cấp một vài đầu ra từ thể hiện mô hình, khi đấy chúng ta sẽ thực
23

hiện một số thao tác trong mô hình nhƣ chuyển từ mô hình sang mã nguồn triển khai, hay
chuyển từ mô hình sang một mô hình khác. Trong Eclipse có cung cấp hai thành phần
chuyển mô hình model - to - model và model – to text cho phép phát triển các thao
tác trên mô hình cho DSML.
Model-to-Model Transformation
(M2M)

Project:
M2M là một khía cạnh
quan trọng của phát triển hƣớng mô hình. Dự án M2M cung cấp một Framework cho
các ngôn ngữ chuyển mô hình. Việc chuyển đổi đƣợc thực hiện bởi transformation
engines. Có ba transformation engines mà đƣợc phát triển trong dự án là: ATL
(ATLAS Transformation Language), QTVO (Query/View/Transformation Operational
Mapping Language), QVTR (QVT Relations).
Model to Text (M2T) Project: Dự án này sử dụng để chuyển mô hình sang text [2].

1.4.2.2. Phát triển dự án
DSML
với
Eclipse

Để xây dựng một DSL Toolkit chúng ta cần định nghĩa mô hình miền
(metamodel), biểu đồ, cú pháp văn bản, các chuyển mô hình sang mô hình và mô hình
sang text. Dự án mô hình hóa của Eclipse cung cấp các FrameWorks tƣơng ứng sau:
Eclipse Modeling Framework (EMF), Graphical Modeling Framework (GMF),
Model-to-Model Transformation (M2M), and Model-to-Text Transformation (M2T).
Các artifacts của DSL liên quan với nhau nhƣ thế nào đƣợc thể hiện trong hình dƣới
đây. Hình dƣới cũng cho chúng ta biết domain model là cơ sở cho tất cả các artifact khác.
[5]

24


Hình 1.8. DSL Toolkit artifacts—abstract
[
5
]


Một Toolkit DSL bao gồm các công cụ cần thiết cho phát triển tất cả các khía
cạnh khác nhau của một ngôn ngữ chuyên biệt miền bao gồm cả chuyển mô hình và sinh
code. Luồng công việc để phát triển một DSL Toolkit với Eclipse đƣợc thể hiện trong
hình dƣới đây:
25

Hình 1.9. Luồng công việc phát triển DSL
T
ool
k
it
[
2
]



Để có đầy đủ các dự án hỗ trợ cho phát triển DSML với bản phát hành helios
chúng ta cần cài đặt thêm các dự án cần thiết phục vụ cho phát triển DSML
2
.
a) Xây dựng cú pháp
trừu
tƣợng cho DSML với dự án
E

M
F
.

EMF là một trong các dự án của Eclipse, nó là một Framework tích hợp mô hình
hóa và dữ liệu là nền tảng để lƣu trữ metadata và metamodel. EMF cũng là một
Framework sinh mã nguồn cho xây dựng Eclipse editors là Plug-ins của
Eclipse.
Eclipse EMF có thể đƣợc sử dụng để mô hình hóa mô hình miền. EMF có sự
phân biệt giữa meta-model và mô hình thực tế. Meta-model mô tả cấu trúc của mô
hình. Một mô hình là thể hiện của meta-model. Một EMF meta-model đƣợc xác định,
chúng ta có thể tạo ra các lớp triển khai viết bằng java từ các mô hình này. EMF cung

2