Sinh mã tự động trong phát triển phần mềm hướng mô hình

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

DƯƠNG NGỌC LÂM

SINH MÃ TỰ ĐỘNG TRONG PHÁT TRIỂN PHẦN MỀM
HƯỚNG MÔ HÌNH

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội – 2014


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

DƯƠNG NGỌC LÂM

SINH MÃ TỰ ĐỘNG TRONG PHÁT TRIỂN PHẦN MỀM
HƯỚNG MÔ HÌNH
Ngành:
Chuyên ngành:
Mã số:

Công nghệ thông tin
Kỹ thuật Phần mềm
60480103

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

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

Hà Nội – 2014


LỜI CAM ĐOAN
Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi, được thực hiện dưới
sự hướng dẫn khoa học của TS. Đặng Đức Hạnh.
Nội dung nghiên cứu và kết quả nêu trong luận văn là hoàn toàn trung thực, được
tôi tổng hợp, bổ sung và biên soạn theo sự hiểu biết của mình sau khi nghiên cứu được
từ các tài liệu tham khảo như sách, bài báo khoa học, luận văn, và dữ liệu từ các trang
Web uy tín.
Hà nội, tháng 6, năm 2014
Học viên
(ký và ghi rõ họ tên)

ii


LỜI CẢM ƠN
Lời đầu tiên, tôi muốn dành lời cảm ơn sâu sắc nhất tới TS. Đặng Đức Hạnh –
Giảng viên Bộ môn Công nghệ Phần mềm – Khoa Công nghệ Thông tin – Trường Đại
học Công nghệ - ĐHQGHN, người đã trực tiếp định hướng và hướng dẫn tôi hoàn
thành luận văn này. Từ những ngày đầu còn bỡ ngỡ với lĩnh vực nghiên cứu mới, tôi
đã được Thầy tận tình quan tâm, hướng dẫn để tiếp cận nhanh với công nghệ mới. Và
bây giờ, sau khi đã trải qua giai đoạn nghiên cứu, tôi cũng đã thu được những kiến
thức nhất định được đúc kết trong luận văn này.
Ngoài ra, trong khoảng thời gian học tập và nghiên cứu tại Trường Đại học Công
nghệ – ĐHQGHN, với sự giảng dạy và giúp đỡ của các Thầy/Cô và các bạn học viên,
tôi đã học được rất nhiều bổ ích và lý thú. Ngoài những kiến thức về lĩnh vực Công

nghệ Thông tin mà tôi thu lượm được, điều tôi tâm đắc nhất đó là khả năng tư duy,
phân tích, tổng hợp các vấn đề một cách khoa học từ Thầy/Cô và các bạn. Điều đó
không những giúp ích cho tôi trong việc xử lý tốt hơn các công việc hàng ngày, mà còn
giúp tôi nâng cao khả năng nghiên cứu. Tự đáy lòng mình, tôi xin gửi lời cảm ơn chân
thành nhất tới các Thầy/Cô và các bạn. Tôi cũng xin gửi lời cảm ơn tới gia đình mình
đã luôn luôn động viên tôi hoàn thành tốt nhiệm vụ học tập được giao.
Do lĩnh vực nghiên cứu được đề cập trong luận văn còn mới lạ, chưa được ứng
dụng rộng rãi, và vẫn còn đang trong giai đoạn phát triển, cho nên tôi đã gặp không ít
khó khăn trong việc nghiên cứu. Giới hạn về thời gian cũng là vấn đề khiến tôi chưa
tập trung hết tâm huyết để khai thác các vấn đề chuyên sâu hơn nữa trong lĩnh vực này.
Vì vậy mà chắc chắn luận văn sẽ còn nhiều điều thiếu sót, và rất mong nhận được ý
kiến đóng góp quý báu của các Thầy/Cô và bạn đọc quan tâm. Mọi ý kiến đóng góp
xin vui lòng gửi về địa chỉ thư điện tử:
Xin chân thành cảm ơn.
Học viên
Dương Ngọc Lâm

iii


MỤC LỤC
LỜI CAM ĐOAN......................................................................................................................................... ii
LỜI CẢM ƠN.............................................................................................................................................. iii
MỤC LỤC..................................................................................................................................................... iv
DANH MỤC CÁC KÝ HIỆU CÁC CHỮ VIẾT TẮT..................................................................... viii
DANH MỤC CÁC HÌNH ẢNH VÀ ĐỒ THỊ
...........................................................................................................................................................................

x
DANH MỤC CÁC BẢNG BIỂU........................................................................................................... xii

MỞ ĐẦU..................................................................................................................................................... xiii
CHƯƠNG 1. TỔNG QUAN CÔNG NGHỆ PHÁT TRIỂN HƯỚNG MÔ HÌNH
..........................................................................................................................................................................

1
1.1

Giới thiệu.......................................................................................................................................... 1

1.2

Ứng dụng MDA trong quy trình phát triển phần mềm...................................................................2

1.2.1

Phát triển phần mềm theo phương pháp truyền thống.....................................................................3

1.2.2

Phát triển phần mềm theo phương pháp hướng mô hình (MDD).....................................................4

1.2.3

Những thuận lợi của kiến trúc hướng mô hình (MDA)....................................................................5

1.2.3.1

Chất lượng sản phẩm............................................................................................................. 5

1.2.3.2

Khả năng tương thích............................................................................................................. 5

1.2.3.3

Khả năng tương tác................................................................................................................ 5

1.2.3.4

Bảo trì và Tư liệu................................................................................................................... 6

1.3

Cơ bản về MDA................................................................................................................................ 6

1.3.1

Mô hình (model) là gì?................................................................................................................... 7

1.3.2

Meta-model.................................................................................................................................... 7

1.3.3

Chuyển đổi mô hình........................................................................................................................ 8

1.3.4

Các đặc điểm mong muốn của sự chuyển đổi..................................................................................9

1.3.4.1

Khả năng truy tìm nguồn gốc................................................................................................. 9

1.3.4.2

Tính nhất quán gia tăng........................................................................................................ 10

1.3.4.3

Tính hai chiều...................................................................................................................... 10

1.3.5

Mô hình bốn lớp của MDA........................................................................................................... 10

1.3.6

Ví dụ về MOF............................................................................................................................... 12

1.4

Các tiêu chuẩn của OMG được sử dụng với MDA........................................................................14

1.4.1

MOF (Meta-Object Facility)......................................................................................................... 14

1.4.2

UML (Unified Modeling Language).............................................................................................. 14

1.4.3

OCL (Object Contraint Language)............................................................................................... 14

1.4.4

CWM (Common Warehouse MetaModel)...................................................................................... 15

1.4.5

UML Profile................................................................................................................................. 15

1.4.6

XMI (XML Metadata Interchange)................................................................................................ 16

1.4.7

JMI (Java Metadata Interchange)................................................................................................. 16

1.5

Tổng kết chương............................................................................................................................. 17

CHƯƠNG 2. KHẢO SÁT KHẢ NĂNG SINH MÃ TỰ ĐỘNG TRONG MDD

........................................................................................................................................................................

18
2.1

Giới thiệu........................................................................................................................................ 18

iv


2.2

Các bộ sinh mã hướng mô hình ...................................................

2.2.1Sử dụng Khuôn mẫu và Bộ lọc (Template and Filtering) ...............
2.2.2Sử dụng Khuôn mẫu và Meta-Model (Template and Meta-Model)

2.2.3Sử dụng Bộ sinh dựa trên API (API-based Generator) ..................

2.2.4Sử dụng Sinh mã nội tuyến (Inline Code Generation) ....................
2.3

Công cụ chuyển đổi mô hình........................................................

2.3.1EMF (Eclipse Modeling Framework)..............................................

2.3.2MDR (Metadata Repository) ..........................................................

2.3.3AndroMDA ......................................................................................

2.3.4OptimalJ .........................................................................................

2.3.5ArcStyler .........................................................................................
2.4

Khuôn mẫu (Templates)................................................................

2.4.1Ngôn ngữ mục đích chung (General-Purpose Languages) ............

2.4.1.1 Ngôn ngữ đánh m

2.4.1.2 Ngôn ngữ kịch bả

2.4.2Ngôn ngữ phụ thuộc miền (Domain-Specific Languages) ..............

2.4.3Ngôn ngữ chuyển đổi mô hình sang văn bản...................................

2.4.3.1 Xpand.................

2.4.3.2 MOF Model to Te

2.4.3.3 JET (Java Emitter
2.5

Những lợi ích của việc sinh mã hướng mô hình .........................

2.5.1Chất lượng.......................................................................................

2.5.2Sự nhất quán....................................................................................

2.5.3Sự linh hoạt......................................................................................

2.5.4Tính di động.....................................................................................

2.5.5Phân tách các khía cạnh..................................................................

2.5.6Tốc độ phát triển .............................................................................

2.5.7Tăng thời gian phân bổ cho các pha chính.....................................

2.6Rủi ro từ việc áp dụng sinh mã .............................................................................

2.6.1Phần mềm không phù hợp cho việc sinh mã.................

2.6.2Chất lượng của phần mềm sinh mã kém.......................
2.7

Tổng kết chương .........................................................

CHƯƠNG 3. CÔNG NGHỆ WEB HƯỚNG MÔ HÌNH......................................................
3.1

Giới thiệu .....................................................................

3.1.1Phương pháp tiếp cận...................................................

3.1.2Phân tách các khía cạnh...............................................

3.1.3Môi trường chuyển đổi .................................................

3.2Công nghệ Web hướng mô hình UWE..................................................................

3.2.1Tổng quan về UWE.......................................................

3.2.2Các phương pháp khác trong MDWE so sánh với UWE

3.2.2.1 WebM

3.2.2.2 Object

v


3.2.2.3 Object-Oriented Web Solution (OOWS) ................................................................................
3.3

Tự động sinh mã trong UWE4JSF .....................

3.3.1

Tổng quan về UWE4JSF.........................................

3.3.2

Chuyển đổi mô hình và cơ chế thẩm định mô hình

3.3.2.1 Chuyển đổi mô hình UML2UWE...........................................................................................
3.3.2.2 Cơ chế thẩm định của UWE4JSF............................................................................................
3.3.2.3 Chuyển đổi mô hình sang mô hình UWE2JSF .......................................................................
3.3.2.4

UWE4JSF Meta

3.3.2.5 Chuyển đổi mô hình sang văn bản trong UWE4JSF...............................................................
3.3.3

Cấu trúc của ứng dụng UWE4JSF ........................

3.4

Tổng kết chương ..................................................

CHƯƠNG 4. THỰC NGHIỆM VỚI UWE4JSF ..................................................................
4.1

Giới thiệu ..............................................................

4.2

Đặc tả yêu cầu ......................................................

4.2.1

Biểu đồ ca sử dụng (Use Case Diagram) ..............

4.2.2

Biểu đồ hoạt động (Activity Diagram)...................

4.3

Thiết kế mô hình ..................................................

4.3.1

Mô hình nội dung (Content) ..................................

4.3.2

Mô hình điều hướng (Navigation) .........................

4.3.3

Mô hình xử lý (Process)..........................................

4.3.3.1

AddContact .....

4.3.3.2

EditContact .....

4.3.3.3

DeleteContact..

4.3.3.4

Login................

4.3.3.5

Logout..............

4.3.3.6

Register ...........

4.3.4

Mô hình biểu diễn (Presentation) ..........................

4.3.4.1 Giao diện tổng thể...................................................................................................................
4.3.4.2

MainMenu.......

4.3.4.3

ContactDataInp

4.3.4.4

CustomerInfo ..

4.3.4.5

Contact.............

4.3.4.6 Giao diện nhập liệu .................................................................................................................
4.3.4.7

Concrete Presen

4.4

Thực hiện sinh mã................................................

4.5

Đánh giá kết quả ..................................................

4.6

Tổng kết chương ..................................................

KẾT LUẬN

.....................

TÀI LIỆU THAM KHẢO........................................................................................................
PHỤ LỤC.................................................................................................................................
Phụ Lục A. Các plug-in của công cụ UWE4JSF ..........................................................................................

vi


Phụ Lục B. Thực hành với MagicUWE..................................................................................................... 91
Phụ Lục C. Thực hành chuyển đổi với Eclipse IDE..................................................................................92

vii


DANH MỤC CÁC KÝ HIỆU CÁC CHỮ VIẾT TẮT
Chữ viết tắt
AJAX
APD
API
ATL
BPEL
CASE
CWM
DSL
DTD
EJB
EMF
EMOF
HTML
ID
JET
JMI
JSF
JSP
LMU
M2M
M2T
MOF
MDA
MDE

MDD
MDR
MDSE


Chữ viết tắt
MDSD
MDWE
MVC
NAD
OCL
OGNL
OLAP
OMG
OO-H
OOWS
PIM
PHP
PSM
RMI
SFs
UEL
UI
UML
URL
UWE
VTL
WebML
XMI
XML

XSTL

ix


DANH MỤC CÁC HÌNH ẢNH VÀ ĐỒ THỊ
Hình 1.1: Tập hợp miền ứng dụng và phương pháp trong MDD
Hình 1.2: Phương pháp phát triển phần mềm truyền thống
Hình 1.3: Ứng dụng MDA vào quy trình phát triển phần mềm
Hình 1.4: Khả năng tương tác sử dụng các cầu nối trong MDA. Nguồn [4, mục 1.3.3]
Hình 1.5: Mô hình được viết bởi ngôn ngữ và mô tả hệ thống. Nguồn [4, mục 2.1]
Hình 1.6: Meta-model
Hình 1.7: Meta-language
Hình 1.8: Định nghĩa chuyển đổi bên trong công cụ chuyển đổi. Nguồn [4, mục 2.3]
Hình 1.9: Mô hình bốn lớp của MDA. Nguồn [4, mục 8.2]
Hình 1.10: MOF trong MDA. Nguồn [9, tr. 204]
Hình 1.11: Cơ chế chuyển đổi mô hình trong MDA. Nguồn [4, mục 8.3.1]
Hình 2.12: Sự trừu tượng hoá tăng dần của ngôn ngữ máy tính [18].
Hình 2.13: Chuyển đổi mô hình sang mã nguồn theo MDA
Hình 2.14: Sinh mã dựa trên Khuôn mẫu và Bộ lọc.
Hình 2.15: Sinh mã dựa trên Khuôn mẫu và Meta-model.
Hình 2.16: Sinh mã dựa trên API.
Hình 2.17: Sinh mã nội tuyến.
Hình 2.18: Sinh mã dựa trên khuôn mẫu. Nguồn [6, tr. 140]
Hình 2.19: Ví dụ về sinh mã. Nguồn [6, tr. 140]
Hình 2.20: Khung EMF. Nguồn [9, tr. 210]
Hình 2.21: Luồng chuyển đổi trong oAW. Nguồn [5]
Hình 2.22: Chuyển đổi mô hình sang mã nguồn với Acceleo
Hình 2.23: JET Engine.
Hình 2.24: Chuyển đổi với JET.

Hình 2.25: Tốc độ phát triển theo số liệu năm 2009 của MetaCase [18]
Hình 3.26: Phân tách các chuyển đổi từ PIM sang PSM. Nguồn từ Chương 3, tài liệu [3]
Hình 3.27: Môi trường chuyển đổi dựa trên EMF
Hình 3.28: Mô hình UWE được biểu diễn bởi UML Profile và UML
Hình 3.29: Chuyển đổi mô hình theo các khía cạnh. Trích dẫn từ Chương 1 của [3]
Hình 3.30: Tiến trình chuyển đổi trong UWE4JSF [19]
Hình 3.31: Tiến trình chuyển đổi chi tiết trong UWE4JSF [17]
Hình 3.32: Gói hỗ trợ thẩm định mô hình trong UWE Meta-model
Hình 3.33: Ví dụ về cấu trúc của mô hình biểu diễn trong UWE.
x


Hình 3.34: Các thành phần mô hình tiêu chuẩn JSF của mô hình biểu diễn cụ thể.
Hình 3.35: Cấu trúc cơ bản của UWE4JSF meta-model mức PSM
Hình 3.36 : Cấu trúc của khung ứng dụng UWE4JSF
Hình 4.37 Biểu đồ ca sử dụng tổng quát (Use Case Diagram)
Hình 4.38 Biểu đồ hoạt động chức năng CreateContact
Hình 4.39 Biểu đồ lớp thể hiện mô hình nội dung
Hình 4.40 Biểu đồ lớp thể hiện mô hình điều hướng
Hình 4.41 Mô hình xử lý tổng quát
Hình 4.42 Biểu đồ hoạt động AddContact
Hình 4.43 Biểu đồ hoạt động EditContact
Hình 4.44 Biểu đồ hoạt động DeleteContact
Hình 4.45 Biểu đồ hoạt động Login
Hình 4.46 Biểu đồ hoạt động Logout
Hình 4.47 Biểu đồ hoạt động Register
Hình 4.48 Giao diện tổng thể của một trang Web được thể hiện qua mô hình biểu diễn.
Hình 4.49 Giao diện thành phần con MainMenu
Hình 4.50 Giao diện thành phần con ContactDataInput
Hình 4.51 Giao diện thành phần con CustomerInfo

Hình 4.52 Giao diện thành phần con Contact
Hình 4.53 Giao diện nhập dữ liệu cho Login và Register
Hình 4.54 Mô hình biểu diễn cụ thể
Hình 4.55: Số dòng lệnh *.java ở thư mục /src.
Hình 4.56: Số dòng lệnh *.jsp ở thư mục /WebContent.
Hình Phụ Lục A.1: Chuỗi plug-in trong UWE4JSF.
Hình Phụ Lục A.2: Các Plug-in của UWE4JSF
Hình Phụ Lục A.3: Cấu trúc thư mục, file của Plug-in
Hình Phụ Lục A.4: Các file khuôn mẫu của Plug-in
Hình Phụ Lục B.5: Xuất dữ liệu làm đầu vào cho công cụ chuyển đổi.
Hình Phụ Lục C.6: Khung ứng dụng Web.
Hình Phụ Lục C.7: Sinh mã bằng UWE4JSF.
Hình Phụ Lục C.8: Mã nguồn được sinh ra.
Hình Phụ Lục C.9: Bổ sung mã nguồn.

xi


DANH MỤC CÁC BẢNG BIỂU
Bảng 4.1: Các khuôn mẫu được sử dụng trong biểu đồ hoạt động
Bảng 4.2: Các khuôn mẫu được sử dụng trong mô hình điều hướng
Bảng 4.3: Các khuôn mẫu được sử dụng trong mô hình biểu diễn
Bảng 4.4: Các thành phần cần bổ sung
Bảng 4.5: Tiêu chí đánh giá việc sinh mã
Bảng Phụ Lục A.1: Các Plug-in của công cụ UWE4JSF

xii


MỞ ĐẦU

Công nghệ phầm mềm luôn là điều gì đó ám ảnh các nhà khoa học, thúc đẩy họ
phải luôn tìm tòi, sáng tạo ra những cách thức mới để nâng cao chất lượng của sản
phẩm phần mềm. Nhìn lại quá khứ từ khi máy tính ra đời cho đến ngày nay thì có thể
thấy ngôn ngữ máy tính cũng đã phát triển qua nhiều thế hệ từ hợp ngữ, đến ngôn ngữ
thủ tục, đến ngôn ngữ hướng đối tượng, và bây giờ là ngôn ngữ mô hình hoá. Cùng với
sự phát triển của ngôn ngữ, thì các phương pháp phát triển tương ứng với chúng cũng
ra đời nhằm giải quyết bài toán chất lượng phần mềm, như phương pháp hướng đối
tượng, phương pháp hướng thành phần, phương pháp hướng khía cạnh, vân vân. Có
một điều rất dễ nhận thấy đó là mức độ trừu tượng, tính kế thừa của các ngôn ngữ, của
các phương pháp đều phát triển theo hướng tăng dần. Tại sao lại như vậy? Nguyên
nhân chính, đơn giản đến từ những điều rất tự nhiên trong cuộc sống. Đó là nhu cầu
của con người.
Công nghệ phát triển ngày càng hiện đại với nhiều nền tảng mới ra đời, cùng với
nhu cầu ngày càng lớn của người dùng internet khiến cho các nhà phát triển phải xây
dựng các hệ thống lớn có nhiều tính năng để đáp ứng nhu cầu đó, cũng như làm tăng
sự trải nghiệm của người dùng. Rồi nhu cầu mới lại được đưa ra một cách nhanh
chóng, và các phiên bản phần mềm mới lại ra đời sao cho có thể hoạt động tốt được
trên nền tảng mới. Việc này thực tế gây ra rất nhiều phiền toái cho các nhà phát triển
với các vấn đề quản lý, duy trì phần mềm một cách thủ công nếu họ vẫn áp dụng
phương pháp phát triển cũ. Nỗ lực và thời gian tiêu tốn cho việc duy trì đó là rất lớn.
Không có cách giải quyết nào tốt hơn là phải áp dụng các phương pháp phát triển mới
vào quy trình phát triển phần mền.
Để giải quyết nhu cầu người dùng một cách nhanh chóng, các nhà phát triển
thường phải tập trung vào khâu phân tích các vấn đề ở giai đoạn đầu của dự án, và
cách tốt nhất để diễn đạt ý tưởng cho những bộ phận liên quan có chuyên môn khác
nhau, là qua việc mô hình hoá các khía cạnh của phần mềm bằng ngôn ngữ mô hình
hoá. Phương pháp phát triển phần mềm hướng mô hình ra đời với ý tưởng chính là tập
trung vào việc mô hình hoá phần mềm, rồi từ đó chuyển đổi tự động sang các mô đun,
mã nguồn, hay chương trình có thể thực thi được bằng các công cụ chuyển đổi. Hiện
tại, phương pháp phát triển này đang được áp dụng bởi rất nhiều tổ chức vì nó đã giải

quyết được rất nhiều vấn đề ở cả khía cạnh người dùng và khía cạnh người phát triển,
và được xem như là thế hệ phát triển tiếp theo trong lĩnh vực công nghệ phần mềm.
Ở
một góc độ khác, trong thời buổi hội nhập kinh tế thế giới hiện nay, các công
ty, tổ chức cạnh tranh nhau khốc liệt nhằm giành chỗ đứng trên thị trường, để khẳng
định thương hiệu của mình bằng cách cung cấp các sản phẩm có chất lượng tốt hơn với
giá cả rẻ hơn đối thủ. Để thực hiện điều đó không có cách nào khác là phải
xiii


ứng dụng công nghệ mới vào quy trình sản xuất kinh doanh của mình, làm tăng năng
suất sản phẩm, giảm thiểu sức lao động của con người. Tất cả những điều nêu trên là
động lực thúc đẩy tôi lựa chọn đề tài nghiên cứu “Sinh mã tự động trong phát triển
phần mềm hướng mô hình”.
Luận văn được cấu trúc như sau:
Chương 1: Tổng quan về công nghệ phát triển hướng mô hình (MDD/MDE) nói chung
và công nghệ phát triển phần mềm hướng mô hình nói riêng (MDSD/MDSE). Chương
này cũng đề cập đến phương pháp phát triển sử dụng kiến trúc đang được áp dụng rộng
rãi bởi các tổ chức hiện nay, đó là kiến trúc hướng mô hình MDA.
Chương 2: Tập trung vào khảo sát khả năng sinh mã tự động (Code Generation) khi
chuyển đổi giữa các mô hình trong phát triển phần mềm hướng mô hình. Đi sâu vào
nghiên cứu các phương pháp chuyển đổi từ mô hình sang văn bản (mã nguồn, tài liệu),
sử dụng các ngôn ngữ chuyển đổi và công cụ khuyển đổi khác nhau. Tùy vào từng ứng
dụng cụ thể mà có thể sử dụng các phương pháp khác nhau, phân tích ưu điểm, nhược
điểm của từng phương pháp.
Chương 3: Giới hạn phạm vi nghiên cứu qua việc phân tích công nghệ phát triển ứng
dụng Web hướng mô hình (MDWD/MDWE) nói chung, đi sâu vào nghiên cứu khả
năng sinh mã tự động với công nghệ Web hướng mô hình dựa trên UML (UWE) nói
riêng, trong đó tập trung vào công cụ UWE4JSF.
Chương 4: Thực nghiệm với UWE4JSF bằng cách xây dựng một ứng dụng đơn giản

nhằm đánh giá khả năng sinh mã của công cụ này.

xiv


CHƯƠNG 1. TỔNG QUAN CÔNG NGHỆ PHÁT
TRIỂN HƯỚNG MÔ HÌNH
Chương này luận văn sẽ đề cập một cách khái quát về Công nghệ phát triển
hướng mô hình (MDD), trong đó luận văn sẽ giới hạn phạm vi nghiên cứu trong lĩnh
vực phát triển phần mềm (MDSD). Ngoài ra luận văn cũng đề cập đến lý thuyết cơ bản
về kiến trúc hướng mô hình (MDA) và những lợi thế của phương pháp phát triển phần
mềm sử dụng kiến trúc này so với phương pháp truyền thống.
1.1

Giới thiệu

Tiếp tục với vấn đề được đề cập trong Phần Mở Đầu, khi các nhà phát triển đang
đối mặt với nhiều vấn đề về sự phát triển nhanh chóng và ngày càng phức tạp của các
nền tảng công nghệ mới. Do đó, họ phải dành nhiều công sức và thời gian để tuỳ biến
ứng dụng (thường theo cách thủ công là sửa mã nguồn) sao cho có thể hoạt động được
trên các nền tảng khác nhau.
Công nghệ hướng mô hình (MDE) là phương pháp tiếp cận mới giải quyết được
sự phức tạp của các nền tảng khác nhau bằng cách tập trung vào diễn tả khía cạnh
miền ứng dụng một cách hiệu quả. MDE hướng tới việc sử dụng các mô hình (models)
như là tác nhân chính trong toàn bộ vòng đời phát triển của ứng dụng. Và do đó, ở khía
cạnh này nó cũng đồng nghĩa với thuật ngữ Phát triển hướng mô hình (MDD), và
chúng ta có thể ngầm hiểu rằng khi nhắc đến MDE hay MDD là ta đang nói về “Công
nghệ phát triển hướng mô hình”. MDD phát triển dựa trên ý tưởng về môi trường quản
lý mô hình phần mềm có tính tự động hoá cao. Nghĩa là nó không bị phụ thuộc vào các
nền tảng, và khi có nền tảng mới ra đời thì sự tự động hoá đó sẽ phát huy tác dụng, ứng

dụng mới sẽ được chuyển đổi tự động từ các mô hình để tương thích với nền tảng mới.
Điều đó làm tăng năng suất và thời gian phân phối sản phẩm.
Ngày nay, MDD không chỉ được ứng dụng trong lĩnh vực phần mềm mà còn ở
những lĩnh vực khác như phần cứng [6] (mô hình các mạch điện tử để tạo các mạch vật
lý ngoài sự can thiệp của con người), các hệ thống nhúng [10]. Phạm vi nghiên cứu
được đề cập trong luận văn là lĩnh vực phần mềm, tương ứng với thuật ngữ “Công
nghệ phát triển phần mềm hướng mô hình” (MDSE hay MDSD). Tiếp đó, ở Chương 3
luận văn sẽ trình bày phạm vi cụ thể hơn là miền ứng dụng Web (MDWE) với các
phương pháp phát triển Web hướng mô hình, mà trọng tâm là phương pháp UWE.

1


Hình 1.1: Tập hợp miền ứng dụng và phương pháp trong MDD
Như đã trình bày, mô hình (model) là điểm mấu chốt mà các phương pháp tiếp
cận trong MDD hướng tới. Trong đó mô hình phần mềm có thể được phân loại thành
phi cấu trúc và cấu trúc [6], ví dụ mô hình phi cấu trúc như các mô tả bằng ngôn ngữ
tự nhiên, các hình vẽ bằng công cụ đồ hoạ máy tính; mô hình cấu trúc thì có tập hợp
các thành phần được định nghĩa trước và các quy tắc mà chúng tuân theo. Các quy tắc
này có thể ở dạng phi hình thức (informally) hay dạng hình thức (formally). Các quy
tắc được cung cấp dưới dạng hình thức được gọi là meta-model hay domain-specific
language (DSL- ngôn ngữ phụ thuộc miền) hay modeling language (ngôn ngữ mô hình
hoá), và được sử dụng bởi các phương pháp mô hình hoá khác nhau.
Trên thị trường hiện tại có nhiều kiến trúc hướng mô hình (xem Hình 1.1) mà
1

MDD tuân theo như MDA (chuẩn hoá bởi OMG sử dụng MOF), Software Factories
(phát triển bởi Microsoft sử dụng DSL), EMF (được tích hợp với Eclipse sử dụng
2

Ecore), DSM (sử dụng DSL, phát triển bởi MetaCase với công cụ MetaEdit+), vân
vân. Tuy nhiên, ở Chương này luận văn chỉ tập trung vào phân tích kiến trúc MDA.
Kiến trúc tương tự với MDA, chỉ khác biệt một số điểm là EMF sẽ được đề cập
ở Chương 2. Cả hai kiến trúc này đang được áp dụng rộng rãi bởi nhiều tổ chức hiện
nay.
1.2

Ứng dụng MDA trong quy trình phát triển phần mềm

Mục này sẽ giải thích tại sao MDA có thể khắc phục được những nhược điểm mà
các phương pháp truyền thống đang gặp phải. Về mặt bản chất, MDA không phải là
quy trình phát triển phần mềm, và tư tưởng của MDA có thể áp dụng cho bất kỳ quy
trình nào. Cụ thể chúng ta sẽ so sánh phương pháp sử dụng MDA với phương pháp
phát triển truyền thống trong quy trình phát triển theo mô hình thác nước.

1
2

/> />
2


1.2.1 Phát triển phần mềm theo phương pháp truyền thống
Đối với việc xây dựng những hệ thống nhỏ, ít tốn kém thì việc áp dụng các
phương pháp truyền thống vẫn còn hữu dụng, tuy nhiên đối với việc xây dựng những
hệ thống lớn, đòi hỏi phải đáp ứng nhiều tính năng từ phía người dùng, thì việc áp
dụng các phương pháp này về lâu về dài sẽ gây nhiều khó khăn cho nhà phát triển.
Yêu cầu
Tài liệu dạng văn
bản

Phân tích
Tài liệu dạng văn
bản, biểu đồ
Thiết kế
Tài liệu dạng văn
bản, biểu đồ
Lập trình
Mã nguồn
Kiểm thử
Mã nguồn
Triển khai

Hình 1.2: Phương pháp phát triển phần mềm truyền thống
Hình trên minh họa các pha phát triển của mô hình thác nước, các pha phân tích,
thiết kế mô tả các vấn đề hầu như dưới dạng văn bản, và hình ảnh minh họa là một số
biểu đồ (UML) như biểu đồ ca sử dụng, biểu đồ lớp, biểu đồ hoạt động, vân vân. Đến
pha lập trình thì một số vấn đề sẽ nảy sinh như nếu có những yêu cầu mới từ phía
người dùng, thì thông thường nhà phát triển sẽ chú trọng nhiều hơn vào pha lập trình
để đáp ứng nhanh nhu cầu của người dùng, thời gian hạn hẹp sẽ khiến nhà phát triển
sao nhãng phần thiết kế, do đó khoảng cách giữa pha thiết kế và pha lập trình ngày
càng lớn, tầm quan trọng của pha thiết kế sẽ giảm dần theo thời gian. Tuy việc cập
nhật tài liệu sau khi lập trình có thể được giải quyết bằng các công cụ tạo tài liệu từ mã
nguồn, tuy nhiên nó cũng chỉ giải quyết được việc thiết kế ở mức thấp, còn ở mức trừu
tượng cao hơn như biểu diễn bằng các biểu đồ, ý nghĩa của nó thì các công cụ này
không giải quyết được. Điều này sẽ gây nhiều khó khăn cho việc kiểm thử, vận hành,
bảo trì hệ thống sau này khi tài liệu thiết kế không được cập nhật đầy đủ.
Ngoài vấn đề về thiết kế trên thì mô hình truyền thống này còn phải đối mặt với
vấn đề khả năng tương thích ngược. Vì các công nghệ mới được phát minh theo
3

thời gian một cách nhanh chóng nhằm đáp ứng các yêu cầu ngày một đa dạng của
người dùng, để giải quyết những vấn đề tồn đọng trước đó, buộc các nhà phát triển
phần mềm cũng phải chạy đua theo để không bị lạc hậu. Như vậy những phiên bản
phần mềm mới có thể không tương thích với các công nghệ cũ, nền tảng cũ đã được
dùng bởi mô hình truyền thống.
1.2.2 Phát triển phần mềm theo phương pháp hướng mô hình (MDD)
Phương pháp phát triển phần mềm hướng mô hình (MDSD) ít nhiều giải quyết
được những vấn đề nêu trên. Khi ứng dụng MDA vào quy trình phát triển theo mô hình
thác nước, bản chất ở mỗi pha của quy trình là tài liệu được thể hiện ở dạng mô hình,
và vì các mô hình này là mô hình hình thức (formal model) nên chúng có thể được
hiểu bởi máy tính và được xử lý tự động.

Yêu cầu
Tài liệu dạng văn
bản
Phân tích
PIM
Thiết kế
PSM
Lập trình
Mã nguồn
Kiểm thử
Mã nguồn
Triển khai

Hình 1.3: Ứng dụng MDA vào quy trình phát triển phần mềm
Các mô hình được sử dụng bởi các công cụ chuyển đổi tự động từ nhiều nhà phát
triển khác nhau để tạo ra các lược đồ (schemas), khung mã nguồn (code skeletons), mã
tích hợp (integration code), và kịch bản triển khai (deployment scripts) cho nhiều nền

tảng khác nhau được sử dụng trong một dự án.
MDA định nghĩa mô hình độc lập nền (PIM), mô hình phụ thuộc nền (PSM), mô
hình văn bản (Text), và cũng định nghĩa cách chúng liên kết với nhau. Một PIM được
tạo ra, sau đó được chuyển đổi sang một hoặc nhiều PSM, để rồi được chuyển sang
Text.
4


1.2.3 Những thuận lợi của kiến trúc hướng mô hình (MDA)
1.2.3.1 Chất lượng sản phẩm
Điểm mấu chốt là người phát triển chú trọng vào việc phát triển PIM, vì vậy mà
họ có thể làm việc một cách độc lập mà không phụ thuộc vào nền tảng đích, và có
nhiều vấn đề kỹ thuật mà họ không cần quan tâm tới. Những vấn đề này sẽ tự động
thêm vào bởi việc chuyển đổi từ PIM sang PSM, do đó nó sẽ cải thiện năng suất theo
hai cách:
Người phát triển PIM sẽ làm ít việc hơn vì những chi tiết về nền tảng đích
không cần được thiết kế. Tại mức mô hình PSM và Text (mã nguồn) sẽ được
viết ít hơn vì lượng lớn mã nguồn được sinh tự động từ PIM, PSM.
Người phát triển có thể chuyển từ việc chú trọng vào viết mã nguồn sang việc
thiết kế PIM, do đó họ sẽ để ý nhiều hơn việc giải quyết các vấn đề nghiệp vụ
tại thời điểm đầu thiết kế, hay bảo trì nâng cấp phần mềm sau này, dẫn đến hệ
thống sẽ phù hợp nhiều hơn với nhu cầu của người dùng, và người dùng cũng sẽ
có được những tính năng tốt hơn trong khoảng thời gian ngắn hơn.
1.2.3.2 Khả năng tương thích
Ngoài ra xét đến khía cạnh tương thích ngược, thì từ một PIM có thể chuyển đổi
sang nhiều PSM cho nhiều nền tảng khác nhau, do đó việc thiết kế PIM sẽ hoàn toàn
tương thích với nền tảng mới sử công nghệ mới. Mặt khác khi những công nghệ mới
được phát minh trong tương lai, thì các tổ chức/công ty phần mềm cần cung cấp những
công cụ chuyển đổi phù hợp, điều này cho phép chúng ta nhanh chóng triển khai hệ
thống mới dựa trên nền tảng cũ (PIM).

1.2.3.3 Khả năng tương tác
PIM
First
transformation

First
transformation
PSM Bridge

PSM

PSM

Second
transformation

Second
transformation
Code Bridge

Code

Code

Hình 1.4: Khả năng tương tác sử dụng các cầu nối trong MDA. Nguồn [4, mục 1.3.3]
5


Khi PSM được nhắm vào các nền tảng khác nhau, chúng không thể nói chuyện
trực tiếp với nhau. Bằng cách nào đó chúng ta cần chuyển đổi các khái niệm từ một

nền tảng thành các khái niệm được sử dụng ở nền tảng khác. Đây là những gì mà khả
năng tương tác đề cập tới. MDA giải quyết vấn đề này bằng cách tạo ra các cầu nối
(bridge) cần thiết giữa chúng.
Nếu chúng ta có thể chuyển đổi một PIM thành hai PSM được nhắm tới hai nền
tảng, tất cả thông tin chúng ta cần để thu hẹp khoảng cách giữa hai PSM là đã có sẵn.
Cụ thể, với mỗi thành phần trong PSM thứ nhất ta biết từ thành phần nào trong PIM
mà nó đã được chuyển đổi. Từ thành phần trong PIM ta biết thành phần tương ứng nào
ở trong PSM thứ hai. Do đó, ta có thể suy ra có bao nhiêu thành phần từ PSM thứ nhất
liên quan đến các thành phần ở PSM thứ hai. Khi ta biết tất cả chi tiết kỹ thuật nền
tảng cụ thể của cả hai PSM, ta có tất cả thông tin cần thiết để tạo một cầu nối giữa hai
PSM.
Ví dụ, lấy một PSM là mô hình (mã nguồn) Java và một PSM khác là mô hình cơ
sở dữ liệu quan hệ. Với một thành phần Customer trong PIM, ta biết lớp Java nào mà
thành phần này được chuyển đổi thành. Ta cũng biết bảng nào (CSDL) mà thành phần
Customer này được chuyển đổi thành. Xây dựng một cầu nối giữa một đối tượng Java
trong PSM và một bảng trong PSM là điều dễ dàng. Để lấy một đối tượng từ CSDL, ta
truy vấn bảng đã được chuyển đổi từ Customer, và khởi tạo lớp từ PSM còn lại (Java)
với dữ liệu lấy được từ bước truy vấn trước. Để lưu trữ một đối tượng, ta tìm dữ liệu
trong đối tượng Java và lưu nó vào bảng Customer. Việc ánh xạ giữa đối tượng Java và
đối tượng cơ sở dữ liệu quan hệ là yếu tố cơ bản cho việc xây dựng các công nghệ
3

quản lý dữ liệu như Hibernate mà không cần truy vấn trực tiếp vào CSDL. Công nghệ
này được sử dụng trong công cụ UWE4JSF sẽ được đề cập ở Chương 3.
1.2.3.4 Bảo trì và Tư liệu
Việc tập trung vào thiết kế sẽ dễ dàng cho các pha vận hành bảo trì sau này. Khâu
kiểm thử cũng sẽ nhẹ nhàng hơn nhiều vì lượng lớn mã nguồn được sinh tự động nên
sẽ gặp ít lỗi hơn.
1.3

Cơ bản về MDA

Ở
mục 1.2, chúng ta đã đề cập một cách khái quát các thành phần cần có trong
MDA như các mô hình (PIM, PSM, Text), mối quan hệ giữa các mô hình, các công cụ
chuyển đổi, các bước chuyển đổi, vân vân. Mục này sẽ trình bày chi tiết hơn về lý
thuyết từ những vấn đề cơ bản đến nâng cao, giúp cho độc giả có cái nhìn sâu hơn về
MDA.
3

/>
6


1.3.1 Mô hình (model) là gì?.
Một mô hình luôn luôn là một sự trừu tượng của vấn đề gì đó tồn tại trong thực
tế. Đối với mô hình phần mềm, nó luôn được viết bởi một ngôn ngữ, có thể là UML,
một ngôn ngữ lập trình, hoặc bất kỳ một ngôn ngữ nào khác mà chúng ta nghĩ tới. Để
cho phép việc chuyển đổi tự động của một mô hình, các mô hình phải được viết bởi
một ngôn ngữ hình thức (well-defined). Ngôn ngữ này có thể được hiểu và biên dịch
một cách tự động bởi máy tính. Ví dụ, trong MDA mã nguồn cũng là một mô hình, vì
nó được viết bởi ngôn ngữ lập trình có thể được hiểu bởi một trình biên dịch, và nó mô
tả hệ thống. Chúng ta có định nghĩa về mô hình (tham khảo [4]) như sau:
“Một mô hình là một mô tả của (hoặc một phần của) một hệ thống được viết
bởi một ngôn ngữ hình thức.”
“Một ngôn ngữ hình thức là một ngôn ngữ với mẫu được xác định rõ ràng, và
ý nghĩa phù hợp với việc biên dịch tự động bởi máy tính.”

Hình 1.5: Mô hình được viết bởi ngôn ngữ và mô tả hệ thống. Nguồn [4, mục
2.1] 1.3.2 Meta-model

Cũng theo tài liệu [4] một meta-model cũng là một mô hình nhưng ở mức trừu
tượng cao hơn vì nó biểu diễn mô hình, một meta-model chính nó phải được viết bằng
ngôn ngữ hình thức (well-defined). Ngôn ngữ này được gọi là meta-language.

7


Hình 1.6: Meta-model
Như vậy, một meta-language cũng là một ngôn ngữ cụ thể mô tả ngôn ngữ mô
hình (modeling language).

Hình 1.7: Meta-language
1.3.3 Chuyển đổi mô hình
Một công cụ chuyển đổi lấy một PIM và chuyển đổi nó thành một PSM. Một
công cụ chuyển đổi khác chuyển đổi PSM thành Text (Code). Những sự chuyển đổi
này là điểm chính trong quy trình phát triển áp dụng MDA. Một công cụ chuyển đổi
cũng giống như một hộp đen. Nó xem một mô hình như là đầu vào và sinh ra mô hình
thứ hai như đầu ra của nó. Nếu chúng ta mở công cụ chuyển đổi ra và nhìn vào bên
trong, chúng ta có thể thấy các thành phần liên quan đến việc thực hiện chuyển đổi.
Đâu đó bên trong công cụ, có một định nghĩa mô tả cách một mô hình được chuyển
đổi. Chúng ta gọi định nghĩa này là “định nghĩa chuyển đổi”.

8


Hình 1.8: Định nghĩa chuyển đổi bên trong công cụ chuyển đổi. Nguồn [4, mục 2.3]
“Một định nghĩa chuyển đổi là tập hợp các luật chuyển đổi cùng mô tả cách
một mô hình tại ngôn ngữ nguồn có thể được chuyển đổi thành một mô hình ở
ngôn ngữ đích.”
“Một luật chuyển đổi là một mô tả cách một hoặc nhiều cấu trúc trong ngôn

ngữ nguồn có thể được chuyển đổi thành một hoặc nhiều cấu trúc trong ngôn ngữ
đích.”
1.3.4 Các đặc điểm mong muốn của sự chuyển đổi
Theo phương pháp MDA, có nhiều đặc điểm của quy trình chuyển đổi mà chúng
ta muốn hướng tới, đó là:
Khả năng truy tìm nguồn gốc, nghĩa là người ta có thể theo dõi một thành phần
tại mô hình đích khi tìm ngược lại các thành phần tại mô hình nguồn nơi nó
được sinh ra.
Tính nhất quán gia tăng, nghĩa là khi thông tin đích bổ sung đã được thêm vào
mô hình đích, và khi mô hình đích được tái sinh từ mô hình nguồn thì thông tin
bổ sung vẫn còn.
Tính hai chiều, nghĩa là một chuyển đổi có thể được áp dụng không chỉ từ
nguồn tới đích mà còn ngược lại từ đích về nguồn.
1.3.4.1 Khả năng truy tìm nguồn gốc
Trong nhiều tình huống, khả năng truy tìm nguồn gốc là tài sản hữu ích trong ứng
dụng MDA. Thường thì một PIM không có tất cả các thông tin cần thiết để thực thi
toàn bộ hệ thống. Và do đó khi chuyển đổi sang PSM thì PSM cần được lấp đầy thông
tin một cách thủ công. Điều tương tự xảy ra ở Text, một cách hiển nhiên, đây là nguồn
gốc của mọi sự rắc rối. Vì vậy mà một công cụ ít nhất nên làm là cảnh báo người dùng
các phần bị thay đổi cho PIM. Ví dụ, khi người dùng thay đổi tên của một phương thức
trong PSM, công cụ có thể gợi ý phương thức tương ứng trong PIM cũng được đổi tên.

9