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: Công nghệ thông tin
Chuyên ngành: Kỹ thuật Phần mềm
Mã số: 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
iii
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 nha
nh 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 t

hiế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
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 19
2.2.1 Sử dụng Khuôn mẫu và Bộ lọc (Template and Filtering) 20
2.2.2 Sử dụng Khuôn mẫu và Meta-Model (Template and Meta-Model) 21
2.2.3 Sử dụng Bộ sinh dựa trên API (API-based Generator) 22
2.2.4 Sử dụng Sinh mã nội tuyến (Inline Code Generation) 22
2.3 Công cụ chuyển đổi mô hình 24
2.3.1 EMF (Eclipse Modeling Framework) 24
2.3.2 MDR (Metadata Repository) 25
2.3.3 AndroMDA 26
2.3.4 OptimalJ 26
2.3.5 ArcStyler 27
2.4 Khuôn mẫu (Templates) 27
2.4.1 Ngôn ngữ mục đích chung (General-Purpose Languages) 27

2.4.1.1 Ngôn ngữ đánh máy (Strongly Typed Languages) 27
2.4.1.2 Ngôn ngữ kịch bản (Loosely Typed Languages - Scripting) 28
2.4.2 Ngôn ngữ phụ thuộc miền (Domain-Specific Languages) 28
2.4.3 Ngôn ngữ chuyển đổi mô hình sang văn bản 28
2.4.3.1 Xpand 28
2.4.3.2 MOF Model to Text (MOFM2T) 30
2.4.3.3 JET (Java Emitter Templates) 33
2.5 Những lợi ích của việc sinh mã hướng mô hình 36
2.5.1 Chất lượng 36
2.5.2 Sự nhất quán 36
2.5.3 Sự linh hoạt 37
2.5.4 Tính di động 37
2.5.5 Phân tách các khía cạnh 38
2.5.6 Tốc độ phát triển 38
2.5.7 Tăng thời gian phân bổ cho các pha chính 38
2.6 Rủi ro từ việc áp dụng sinh mã 39
2.6.1 Phần mềm không phù hợp cho việc sinh mã 39
2.6.2 Chất lượng của phần mềm sinh mã kém 39
2.7 Tổng kết chương 39
CHƯƠNG 3. CÔNG NGHỆ WEB HƯỚNG MÔ HÌNH 41
3.1 Giới thiệu 41
3.1.1 Phương pháp tiếp cận 42
3.1.2 Phân tách các khía cạnh 44
3.1.3 Môi trường chuyển đổi 45
3.2 Công nghệ Web hướng mô hình UWE 46
3.2.1 Tổng quan về UWE 46
3.2.2 Các phương pháp khác trong MDWE so sánh với UWE 48
3.2.2.1 WebML 49
3.2.2.2 Object-Oriented Hypermedia (OO-H) 49
v

3.2.2.3 Object-Oriented Web Solution (OOWS) 49
3.3 Tự động sinh mã trong UWE4JSF 50
3.3.1 Tổng quan về UWE4JSF 50
3.3.2 Chuyển đổi mô hình và cơ chế thẩm định mô hình trong UWE4JSF 52
3.3.2.1 Chuyển đổi mô hình UML2UWE 53
3.3.2.2 Cơ chế thẩm định của UWE4JSF 55
3.3.2.3 Chuyển đổi mô hình sang mô hình UWE2JSF 56
3.3.2.4 UWE4JSF Meta-model 58
3.3.2.5 Chuyển đổi mô hình sang văn bản trong UWE4JSF 59
3.3.3 Cấu trúc của ứng dụng UWE4JSF 63
3.4 Tổng kết chương 65
CHƯƠNG 4. THỰC NGHIỆM VỚI UWE4JSF 66
4.1 Giới thiệu 66
4.2 Đặc tả yêu cầu 66
4.2.1 Biểu đồ ca sử dụng (Use Case Diagram) 67
4.2.2 Biểu đồ hoạt động (Activity Diagram) 67
4.3 Thiết kế mô hình 69
4.3.1 Mô hình nội dung (Content) 69
4.3.2 Mô hình điều hướng (Navigation) 69
4.3.3 Mô hình xử lý (Process) 71
4.3.3.1 AddContact 71
4.3.3.2 EditContact 72
4.3.3.3 DeleteContact 72
4.3.3.4 Login 73
4.3.3.5 Logout 73
4.3.3.6 Register 74
4.3.4 Mô hình biểu diễn (Presentation) 74
4.3.4.1 Giao diện tổng thể 76
4.3.4.2 MainMenu 77
4.3.4.3 ContactDataInput 77

4.3.4.4 CustomerInfo 78
4.3.4.5 Contact 79
4.3.4.6 Giao diện nhập liệu 80
4.3.4.7 Concrete Presentation Model 81
4.4 Thực hiện sinh mã 81
4.5 Đánh giá kết quả 81
4.6 Tổng kết chương 84
KẾT LUẬN 85
TÀI LIỆU THAM KHẢO 86
PHỤ LỤC 88
Phụ Lục A. Các plug-in của công cụ UWE4JSF 88
vi
vii
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

DANH MỤC CÁC KÝ HIỆU CÁC CHỮ VIẾT TẮT
Chữ viết tắt Chú giải
AJAX Advanced Javascript and XML
APD Abtract Presentation Diagrams
API Application Programming Interface
ATL ATLAS Transformation Language
BPEL Business Process Execution Language
CASE Computer Aided Software Engineering
CWM Common Warehouse Metamodel
DSL Domain-Specific Language
DTD Document Type Definition
EJB Enterprise Java Bean
EMF Eclipse Modeling Framework
EMOF Essensial MOF

HTML HyperText Markup Language
ID Identification
JET Java Emitter Templates
JMI Java Metadata Interface
JSF Java Server Faces
JSP Java Server Pages
LMU Ludwig-Maximilians-Universität München
M2M Model to Model
M2T Model to Text
MOF Meta-Object Facility
MDA Model-Driven Architecture
MDE Model-Driven Engineering
MDD Model-Driven Development
MDR Metadata Repository
MDSE Model-Driven Software Engineering
viii
Chữ viết tắt Chú giải
MDSD Model-Driven Software Development
MDWE Model-Driven Web Engineering
MVC Model-View-Controller
NAD Navigation Access Program
OCL Object Constraint Language
OGNL Object Graph Navigation Language
OLAP Online Analytical Processing
OMG Object Management Group
OO-H Object-Oriented Hypermedia
OOWS Object-Oriented Web Solution
PIM Platform-Independent Model.
PHP Hypertext Preprocessor
PSM Platform-Specific Model

RMI Remote Method Invocation
SFs Software Factories
UEL Unified Expression Language
UI User Interface
UML Unified Modeling Language
URL Uniform Resource Locator
UWE UML-based Web Engineering
VTL Velocity Template Language
WebML Web Markup Language
XMI XML Metadata Interchange
XML eXtensible Markup Language
XSTL eXtensible Stylesheet Language Transformations

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 2
Hình 1.2: Phương pháp phát triển phần mềm truyền thống 3
Hình 1.3: Ứng dụng MDA vào quy trình phát triển phần mềm 4
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
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] 7
Hình 1.6: Meta-model 8
Hình 1.7: Meta-language 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] 9
Hình 1.9: Mô hình bốn lớp của MDA. Nguồn [4, mục 8.2] 10
Hình 1.10: MOF trong MDA. Nguồn [9, tr. 204] 11
Hình 1.11: Cơ chế chuyển đổi mô hình trong MDA. Nguồn [4, mục 8.3.1] 12
Hình 2.12: Sự trừu tượng hoá tăng dần của ngôn ngữ máy tính [18]. 18
Hình 2.13: Chuyển đổi mô hình sang mã nguồn theo MDA 19
Hình 2.14: Sinh mã dựa trên Khuôn mẫu và Bộ lọc. 20
Hình 2.15: Sinh mã dựa trên Khuôn mẫu và Meta-model. 21

Hình 2.16: Sinh mã dựa trên API. 22
Hình 2.17: Sinh mã nội tuyến. 22
Hình 2.18: Sinh mã dựa trên khuôn mẫu. Nguồn [6, tr. 140] 23
Hình 2.19: Ví dụ về sinh mã. Nguồn [6, tr. 140] 23
Hình 2.20: Khung EMF. Nguồn [9, tr. 210] 25
Hình 2.21: Luồng chuyển đổi trong oAW. Nguồn [5] 29
Hình 2.22: Chuyển đổi mô hình sang mã nguồn với Acceleo 31
Hình 2.23: JET Engine. 34
Hình 2.24: Chuyển đổi với JET. 34
Hình 2.25: Tốc độ phát triển theo số liệu năm 2009 của MetaCase [18] 38
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] 45
Hình 3.27: Môi trường chuyển đổi dựa trên EMF 46
Hình 3.28: Mô hình UWE được biểu diễn bởi UML Profile và UML 46
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] 48
Hình 3.30: Tiến trình chuyển đổi trong UWE4JSF [19] 51
Hình 3.31: Tiến trình chuyển đổi chi tiết trong UWE4JSF [17] 53
Hình 3.32: Gói hỗ trợ thẩm định mô hình trong UWE Meta-model 56
Hình 3.33: Ví dụ về cấu trúc của mô hình biểu diễn trong UWE. 57
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ể. 58
Hình 3.35: Cấu trúc cơ bản của UWE4JSF meta-model mức PSM 58
Hình 3.36 : Cấu trúc của khung ứng dụng UWE4JSF 64
Hình 4.37 Biểu đồ ca sử dụng tổng quát (Use Case Diagram) 67
Hình 4.38 Biểu đồ hoạt động chức năng CreateContact 68
Hình 4.39 Biểu đồ lớp thể hiện mô hình nội dung 69
Hình 4.40 Biểu đồ lớp thể hiện mô hình điều hướng 70
Hình 4.41 Mô hình xử lý tổng quát 71
Hình 4.42 Biểu đồ hoạt động AddContact 71
Hình 4.43 Biểu đồ hoạt động EditContact 72
Hình 4.44 Biểu đồ hoạt động DeleteContact 72

Hình 4.45 Biểu đồ hoạt động Login 73
Hình 4.46 Biểu đồ hoạt động Logout 73
Hình 4.47 Biểu đồ hoạt động Register 74
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. 76
Hình 4.49 Giao diện thành phần con MainMenu 77
Hình 4.50 Giao diện thành phần con ContactDataInput 77
Hình 4.51 Giao diện thành phần con CustomerInfo 78
Hình 4.52 Giao diện thành phần con Contact 79
Hình 4.53 Giao diện nhập dữ liệu cho Login và Register 80
Hình 4.54 Mô hình biểu diễn cụ thể 81
Hình 4.55: Số dòng lệnh *.java ở thư mục /src. 82
Hình 4.56: Số dòng lệnh *.jsp ở thư mục /WebContent. 82

Hình Phụ Lục A.1: Chuỗi plug-in trong UWE4JSF. 88
Hình Phụ Lục A.2: Các Plug-in của UWE4JSF 89
Hình Phụ Lục A.3: Cấu trúc thư mục, file của Plug-in 89
Hình Phụ Lục A.4: Các file khuôn mẫu của Plug-in 90
Hình Phụ Lục B.5: Xuất dữ liệu làm đầu vào cho công cụ chuyển đổi. 91
Hình Phụ Lục C.6: Khung ứng dụng Web. 93
Hình Phụ Lục C.7: Sinh mã bằng UWE4JSF. 93
Hình Phụ Lục C.8: Mã nguồn được sinh ra. 94
Hình Phụ Lục C.9: Bổ sung mã nguồn. 95

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 67
Bảng 4.2: Các khuôn mẫu được sử dụng trong mô hình điều hướng 69
Bảng 4.3: Các khuôn mẫu được sử dụng trong mô hình biểu diễn 74
Bảng 4.4: Các thành phần cần bổ sung 82
Bảng 4.5: Tiêu chí đánh giá việc sinh mã 83

Bảng Phụ Lục A.1: Các Plug-in của công cụ UWE4JSF 88

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ôn
g 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
xiv
ứ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.

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 nha
u.
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à
MDD tuân theo như MDA (chuẩn hoá bởi OMG sử dụng MOF), Software Factories
1

(phát triển bởi Microsoft sử dụng DSL), EMF (được tích hợp với Eclipse sử dụng
Ecore), DSM (sử dụng DSL, phát triển bởi MetaCase
2
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
Phân tích
Thiết kế
Lập trình
Kiểm thử
Triển khai
Tài liệu dạng văn
bản
Tài liệu dạng văn
bản, biểu đồ
Tài liệu dạng văn
bản, biểu đồ
Mã nguồn
Mã nguồn

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ã n
guồ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 sa
u 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
Phân tích
Thiết kế
Lập trình
Kiểm thử
Triển khai
Tài liệu dạng văn
bản
PIM
PSM
Mã nguồn
Mã nguồn

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 PI
M, 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
PSM PSM
Code Code
PSM Bridge
Code Bridge
First
transformation
First
transformation
Second
transformation
Second
transformation

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 n
hắ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ỹ th
uậ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ừ Cu
stomer, 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ệ quản lý dữ liệu như Hi
bernate
3
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 tr
ung 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ó tr
ong

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 n
gô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ó t
hà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 qua
n đế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

1.3.4.2 Tính nhất quán gia tăng
Khi một mô hình đích được sinh ra, nó thường cần được thêm một vài việc
phụ trợ như bổ sung mã vào một phương thức, hoặc tinh chỉnh một giao diện
người dùng để tối ưu cách sử dụng. Khi chúng ta tái sinh mô hình đích (vì có thay đổi
ở mô hình nguồn), chúng ta vẫn muốn duy trì các công việc phụ đã hoàn thành ở
mô hình đích lúc đầu. Đây là chính là tính nhất quán gia tăng.

1.3.4.3 Tính hai chiều
Đặc điểm mong muốn cuối của sự chuyển đổi là tính hai chiều, hay sự
chuyển đổi có thể hoạt động ở cả hai hướng. Điều mà chúng ta quan tâm ở đây là
chuyển đổi ngược từ Text về PSM, rồi từ PSM về PIM. Thực tế thì việc này rất khó
thực hiện, vì cũng như việc đi biên dịch ngược ngôn ngữ máy về ngôn ngữ lập trình
bậc cao (reverse engineering), và rất ít công cụ có thể thực hiện đư
ợc.
1.3.5 Mô hình bốn lớp của MDA
Để hiểu rõ hơn về model, meta-model, chúng ta xem xét mô hình bốn lớp được
định nghĩa bởi OMG gồm M0, M1, M2, M3 như sau.


Hình 1.9: Mô hình bốn lớp của MDA. Nguồn [4, mục 8.2]
10