Hệ thống giao diện người dùng trên điện thoại di động theo hướng tiếp cận mô hình

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƢỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN



BÙI TẤN LỘC



NGHIÊN CỨU XÂY DỰNG
HỆ THỐNG GIAO DIỆN NGƢỜI DÙNG
TRÊN ĐIỆN THOẠI DI ĐỘNG
THEO HƢỚNG TIẾP CẬN MÔ HÌNH



LUẬN VĂN THẠC SĨ
NGÀNH KHOA HỌC MÁY TÍNH


Thành phố Hồ Chí Minh – 2010

ii

MỤC LỤC



THUẬT NGỮ VÀ CÁC TỪ VIẾT TẮT i
MỤC LỤC ii
DANH SÁCH CÁC HÌNH viii

DANH SÁCH CÁC BẢNG xi
Chương 1: Giới thiệu 1
1.1. Dẫn nhập 1
1.2. Bài toán phát triển giao diện cho nhiều loại thiết bị 3
1.2.1. Nhánh nghiên cứu Cross – platform user interfaces 3
a) Công nghệ Java 3
b) Công nghệ .NET 4
c) Công nghệ lập trình QT & GTK 4
d) Tóm tắt các công nghệ Cross – platform 5
1.2.2. Nhánh nghiên cứu MUI 5
1.2.3. Nhận xét 6
1.3. Mục tiêu nghiên cứu 7
1.3.1. Đối tượng nghiên cứu 7
1.3.2. Giới hạn đề tài 8
a) Giới hạn platform 8
b) Giới hạn hướng tiếp cận 8
iii

c) Kết quả nghiên cứu dự kiến 9
Chương 2: Cơ sở lý thuyết và các hướng tiếp cận 10
2.1. Hướng tiếp cận MDD 10
2.1.1. Các khái niệm cơ bản về mô hình 10
a) Model 11
b) DSL 11
c) Metamodel 12
2.1.2. Tư tưởng chính của hướng tiếp cận MDD 13
2.1.3. Các chuẩn hướng tiếp cận MDD 14
2.1.4. Hướng tiếp cận MDA 15
a) Kiến trúc Metadata MOF 15
b) Các góc nhìn trong MDA – MDA View Point 16

c) Phương pháp chuyển đổi mô hình 17
c.1. Chuyển đổi mô hình thủ công 17
c.2. Chuyển đổi mô hình tự động 17
c.3. Chuyển đổi mô hình dựa trên Transformation Model 18
d) Nhận xét 19
2.2. Hướng tiếp cận MBUID 19
2.2.1. Phân loại mô hình mô tả UI 20
a) Phân loại mô hình mô tả UI theo mức độ trừu tượng 20
a.1. Task model 21
a.2. AUI model 21
a.3. CUI model 22
a.4. FUI model 23
iv

b) Phân loại mô hình mô tả UI theo chức năng 23
b.1. Data, domain, application model 24
b.2. Dialog, presentation model 25
c) Liên hệ với các góc nhìn trong MDA 26
d) Nhận xét 27
2.2.2. Quy trình phát triển MBUID 27
a) Quy trình phát triển tổng quát 27
b) Quy trình phát triển của CAMELEON Framework 28
c) Quy trình phát triển của TERESA XML 29
d) Quy trình phát triển của UsiXML 30
e) Quy trình phát triển của MANTRA 32
f) Nhận xét 34
2.2.3. Định nghĩa và chuyển đổi mô hình trong MBUID 37
a) Task metamodel 37
b) AUI metamodel 41
c) CUI metamodel 45

d) Transformation metamodel 50
e) Nhận xét 53
2.3. Nhận xét 53
Chương 3: Phương pháp luận DGUIMS 54
3.1. Giới thiệu DGUIMS 54
3.2. Hệ thống mô hình trong DGUIMS 54
3.2.1. Phân loại mô hình trong DGUIMS 54
3.2.2. Kiến trúc MDD trong DGUIMS 57
v

3.3. Quy trình DGUIMS 59
3.3.1. Quy trình DGUIMS đầy đủ 59
3.3.2. Quy trình DGUIMS thu gọn 61
3.4. Các metamodel được đề xuất trong DGUIMS 62
3.4.1. AAUI metamodel 62
3.4.2. CUI metamodel 66
3.4.3. Transformation AAUI2CUI metamodel 70
Chương 4: Xây dựng môi trường phát triển DGUIMSE 74
4.1. Giới thiệu 74
4.2. Các package trong DGUIMSE 76
4.2.1. Package mô hình hóa AAUI, CUI model 76
a) Package mô hình hóa AAUI model 76
b) Package mô hình hóa CUI model trên .NET CF 3.5 76
c) Package mô hình hóa CUI model trên Android 7 77
4.2.2. Package mô hình hóa transformation model 77
a) Package mô hình hóa transformation model sang CUI .NET CF 3.5 78
b) Package mô hình hóa transformation model sang CUI Android 7 78
4.2.3. Package chuyển đổi giữa các mô hình 79
a) Package chuyển đổi từ AAUI sang transformation model trên .NET CF
3.5 79

b) Package chuyển đổi từ AAUI sang transformation model trên Android 7
80
c) Package chuyển đổi từ transformation model sang CUI trên .NET CF 3.5
80
vi

d) Package chuyển đổi từ transformation model sang CUI trên Android 7 . 81
4.2.4. Package chuyển đổi mô hình sang mã nguồn 81
a) Package chuyển đổi CUI model sang mã nguồn .NET CF 3.5 82
b) Package chuyển đổi CUI model sang mã nguồn Android 7 82
Chương 5: Case Study 83
5.1. Bước 01 mô hình hóa AAUI model 83
5.1.1. Mô hình hóa AAUI model cho .NET CF 3.5 83
5.1.2. AAUI model cho Android 7 84
5.2. Bước 02 chuyển đổi AAUI model sang transformation model tương ứng 84
5.3. Bước 03 cấu hình transformation model 85
5.4. Bước 04 thực thi transformation model chuyển sang CUI model tương ứng 85
5.5. Bước 05 phát sinh source code giao diện FUI model từ CUI model 85
5.6. Nhận xét 85
Chương 6: Kết luận và hướng phát triển 93
6.1. Các kết quả đạt được 93
6.1.1. Lý thuyết 93
a) Quy trình 93
b) Kiến trúc hướng mô hình và các mô hình 93
c) Các luật chuyển đổi 94
6.1.2. Ứng dụng 94
6.2. Hướng phát triển 95
TÀI LIỆU THAM KHẢO 96
PHỤ LỤC A: Luật chuyển đổi AAUI model sang transformation model 99
Luật chuyển đổi AAUI model sang transformation model trên .NET CF 99

vii

Luật chuyển đổi AAUI model sang transformation model trên Android 102
PHỤ LỤC B: Luật chuyển đổi transformation model sang CUI model 105
Luật chuyển đổi transformation model sang CUI model trên .NET CF 105
Luật chuyển đổi transformation model sang CUI model trên Android 114
PHỤ LỤC C: Luật chuyển đổi CUI model sang mã-nguồn 121
Luật chuyển đổi CUI model trên .NET CF sang mã nguồn 121
Luật chuyển đổi CUI model trên Android sang mã nguồn 125


1

Chƣơng 1: Giới thiệu
1.1. Dẫn nhập
Trong những năm gần đây, ngày càng xuất hiện nhiều loại thiết bị tính toán mới
bên cạnh máy tính cá nhân PC (Personal Computer). Được giới công nghiệp đầu tư
phát triển mạnh, điện thoại di động (mobile phone), thiết bị kỹ thuật số hỗ trợ cá
nhân (personal digital assistant), và gần đây nhất là máy tính bảng (Tablet) đang
dần tham gia cùng, thậm chí thay thế, thiết bị PC truyền thống trong đời sống hiện
đại.
Tuy nhiên khác với môi trường tương đối đồng nhất của họ PC, các thiết bị tính
toán hiện đại kể trên thường có sự khác biệt đáng kể về cả phần cứng và phần mềm.
Về phần cứng, các thiết bị có thể khác nhau về kích thước màn hình; về thiết bị
nhập/xuất dữ liệu; về cổng giao tiếp với các thiết bị khác, v.v…Đối với phần mềm,
các thiết bị có thể khác nhau về hệ điều hành (OS – Operating System) hoặc phiên
bản hệ điều hành; khác nhau về thư viện hỗ trợ lập trình (SDK – Software
Development Toolkit) hay phiên bản thư viện hỗ trợ lập trình.
Những khác biệt về phần mềm dẫn đến nhiều khó khăn trong việc phát triển cùng
một ứng dụng trên các loại thiết bị khác nhau. Đặc biệt, nếu việc phát triển chỉ tập

trung vào mã nguồn, thì khi thay đổi thiết bị, gần như ứng dụng phải được phát triển
lại từ đầu do khó tận dụng lại các sưu liệu phân tích thiết kế trong các giai đoạn sớm
của quá trình xây dựng ứng dụng. Ví dụ như phát triển ứng dụng “Quản lý chi tiêu
cá nhân” trên các thiết bị di động sử dụng hệ điều hành Symbian, J2ME, Windows
Mobile, Android, v.v… sẽ rất khác nhau do khác nhau về thư viện hỗ trợ lập trình,
cơ chế gọi màn hình, cách thức và định dạng lưu trữ dữ liệu, v.v…Mặt khác, những
thiết bị phần cứng khác nhau thì sẽ cung cấp những cách thức giao tiếp khác nhau
giữa người và máy (HCI – human – computer interaction) làm cho việc phát triển
2

ứng dụng cho từng loại thiết bị, đặc biệt là phần giao diện, càng thêm phức tạp.
Khái niệm giao tiếp được đề cập ở đây cần được hiểu rộng hơn khái niệm truyền
thống WIMP (Window, Icon, Mouse, Pointer). Ví dụ một vài hình thức giao tiếp
hiện đại là truyền hình internet – WebTV – Internet – enabled television; những
thiết bị có platform giao tiếp 3D cùng với khả năng hỗ trợ giọng nói (3D –
interactive platform with voice capability).
(Hình 1.1) minh họa một ứng dụng được phát triển trên nhiều loại thiết bị khác
nhau. Các mũi tên ngụ ý sự cần thiết phát triển các phiên bản riêng cho ứng dụng
trên từng môi trường khác biệt ứng với mỗi loại thiết bị.

Hình 1.1 Minh họa môi trường phát triển ứng dụng trên nhiều loại thiết bị khác nhau với Teresa XML [1]
Như vậy, có thể thấy chính sự đa dạng về phần cứng và phần mềm của các
loại thiết bị đã làm gia tăng độ biến thể của ứng dụng trên nhiều loại thiết bị, do
vậy làm giảm khả năng tái sử dụng sưu liệu và sản phẩm của quá trình phát
triển. Chi phí phát triển các ứng dụng đa thiết bị vì thế cũng gia tăng đáng kể.
3

Một trong những nỗ lực chính nhằm giảm thiểu chi phí của việc phát triển các
ứng dụng cho các loại thiết bị khác nhau được tập trung vào việc tối ưu hóa quá
trình phát triển giao diện cho nhiều loại thiết bị. Đây là bài toán được giải quyết

trong hướng nghiên cứu phát triển phần mềm giao diện – UID – User Interface
Development mà chúng tôi quan tâm trong luận văn này.
1.2. Bài toán phát triển giao diện cho nhiều loại thiết bị
Hướng nghiên cứu UID tập trung đề xuất các giải pháp để phát triển hiệu quả
phần giao diện cho ứng dụng. Bài toán lớn UID có nhiều bài toán con nhưng trong
luận văn này chúng tôi chỉ quan tâm đến vấn đề làm thế nào có thể tận dụng lại tối
đa sưu liệu phân tích, thiết kế và mã nguồn khi phát triển giao diện của cùng một
ứng dụng trên những loại thiết bị khác nhau nhằm giảm chi phí xây dựng ứng
dụng. Trong phần này chúng tôi sẽ giới thiệu sơ lược các hướng tiếp cận chính đang
được áp dụng để giải quyết bài toán giao diện nêu trên.
1.2.1. Nhánh nghiên cứu Cross – platform user interfaces
Nhánh nghiên cứu Cross – platform user interfaces [2] cho phép một ứng dụng có
thể thực thi trên một số hệ điều hành như Window, Linux, Solaris, v.v nhờ vào mã
nguồn của giao diện người dùng có thể mang chuyển – portable. Trong Cross –
platform user interfaces, cùng một đoạn mã nguồn, chạy trên những platform khác
nhau thì sẽ có cùng đối tượng thể hiện nhưng phong cách thể hiện khác nhau. Hiện
tại, các công nghệ ứng dụng tiêu biểu trong nhánh nghiên cứu này có thể kể đến
công nghệ Java, .NET, lập trình QT & GTK.
a) Công nghệ Java
Công nghệ Java sử dụng máy ảo Java – JVM – Java Virtual Machine thông dịch
mã nguồn Java byte code, qua đó cung cấp tính độc lập platform cho các ứng dụng
4

phát triển bằng Java. Về nguyên tắc, một đoạn mã bytecode có thể thực thi được
trên bất kỳ thiết bị nào có hỗ trợ máy ảo Java.
Ngày nay công nghệ này được ứng dụng rộng rãi trong việc phát triển các ứng
dụng trên PC. Có thể nói bài toán phát triển giao diện cho nhiều platform đã được
giải quyết trọn vẹn trên các máy PC.
Tuy nhiên trên các loại thiết bị di động thì công nghệ này vẫn chưa thể cho phép
giải quyết trọn vẹn bài toán khả chuyển giao diện. Nguyên nhân là muốn phát triển

mã nguồn khả chuyển trên các loại thiết bị di động, các loại thiết bị này phải có
chung một phần cấu hình phần cứng để các phiên bản CLDC và MIDP trong
công nghệ Java có thể hỗ trợ. Đây chính là hạn chế của công nghệ Java trên thiết
bị di động.
b) Công nghệ .NET
Công nghệ .NET sử dụng máy ảo trong framework .NET thông dịch mã nguồn
MSIL – Microsoft Intermediate Language. Trên lý thuyết công nghệ .NET có thể
mang đến tính khả chuyển cho nhiều loại thiết bị nhưng công nghệ .NET cũng hạn
chế trong việc giải quyết bài toán phát triển cùng một mã nguồn cho tất cả các thiết
bị di động do một số đòi hỏi về cấu hình của thiết bị.
Cụ thể chỉ khả chuyển trên các PC sử dụng hệ điều hành Windows và các loại
thiết bị di động phải cùng chung một phần cấu hình phần cứng và cần phải được cài
đặt hệ điều hành Windows Mobile. Do đó cũng giống như công nghệ Java, công
nghệ .NET vẫn chưa giải quyết được trọn vẹn bài toán giao diện cho nhiều loại
thiết bị.
c) Công nghệ lập trình QT & GTK
Các nhà lập trình nguồn mở trên nền Linux đã cho ra đời các ngôn ngữ lập trình
Cross – platform là QT và GTK. Hiện nay QT và GTK được minh họa trên các máy
5

PC sử dụng hệ điều hành Linux ít được minh họa trên các hệ điều hành khác. Riêng
QT cũng đã được ứng dụng để lập trình trên các thiết bị diện thoại di động sử dụng
hệ điều hành Symbian.
Do được thể hiện trên ít loại thiết bị như vậy nên QT và GTK chưa được kiểm
chứng đầy đủ trên các loại thiết bị di động.
d) Tóm tắt các công nghệ Cross – platform
Qua (Bảng 1.1) ta thấy, các công nghệ Cross – platform đã xem xét chưa giải quyết
được trọn vẹn bài toán phát triển hiệu quả giao diện trên nhiều thiết bị vì các khống chế
về cấu hình phần cứng hoặc phần mềm. Thiếu sự hỗ trợ của công nghệ khịến cho người
phát triển phần mềm phải mất nhiều thời gian để phát triển lại cùng một ứng dụng trên

các loại thiết bị khác biệt. Để khắc phục nhược điểm này, MUI - một nhánh nghiên cứu
khác của UID - tập trung nghiên cứu các đối tượng giao diện ở mức trừu tượng hơn
nhằm vượt qua giới hạn về cấu hình cụ thể của các thiết bị. Đây cũng chính là nhánh
nghiên cứu mà luận văn quan tâm và sẽ được trình bày ở phần kế tiếp.
Bảng 1.1 Tóm tắt các công nghệ Cross – platform
STT
Công nghệ
Tính khả chuyển trên PC
Tính khả chuyển trên thiết bị di động
1.
Java
Nhiều hệ điều hành
Nhiều hệ điều hành
Các thiết bị có chung một cấu hình
phần cứng mà CLDC và MIDP hỗ trợ
2.
.NET
Hệ điều hành Windows
Hệ điều hành Windows Mobile
Các thiết bị có chung một cấu hình
phần cứng mà framework hỗ trợ
3.
QT
Hệ điều hành Linux
Hệ điều hành Symbian
4.
GTK
Hệ điều hành Linux
Chưa được thể hiện
1.2.2. Nhánh nghiên cứu MUI

Nhánh nghiên cứu MUI – Multiple user interfaces [2] nghiên cứu các góc nhìn
khác nhau về dịch vụ và thông tin đáp ứng người sử dụng trên các platform thiết bị
tính toán khác nhau. Các thiết bị tính toán có cấu hình phần cứng, khả năng tính
toán, hệ điều hành và thư viện UI khác nhau do đó các hệ thống MUI có thể cung
6

cấp các đối tượng trừu tượng – virtual object để giao tiếp với nhiều loại dịch vụ và
nhiều thông tin khác nhau, từ đó cung cấp loại UI look – and – feel khác nhau trên
từng loại thiết bị.
Trong phạm vi luận văn này, chúng tôi quan tâm đến MUID – Multiple User
Interfaces Development – nhánh con của UID nghiên cứu các phương pháp luận
phát triển các ứng dụng giao diện sao cho tiết kiệm chi phí khả chuyển. Hệ thống
phương pháp luận sẽ bao gồm: quy trình phát triển – Process, các loại mô hình dùng
để mô tả hệ thống, ngôn ngữ mô hình hóa và các công cụ hỗ trợ – CASE Tool.
Một cách tiếp cận tổng quát thường được sử dụng trong MUID đó là phát triển
giao diện theo hướng mô hình MBUID – Model – based User Interfaces
Development. Tùy theo trường phái mà các nhà nghiên cứu có một cách tiếp cận và
phương pháp luận khác nhau nhưng đều dựa trên cách tiếp cận tổng quát MBUID.
Hiện nay trong hướng tiếp cận MUID nhiều phương pháp khác nhau, có thể kể đến
một số công trình nổi bật như: TERESA XML [1], CAMELEON Reference
Framework [3], UsiXML [4], v.v… Mỗi cách tiếp cận khác nhau sẽ cho chúng ta
một hệ thống phương pháp luận MUID khác nhau, và hiện nay chưa có sự thống
nhất, hay nói cách khác là chưa có chuẩn chung cho MUID. Có thể nói rằng: UID
vẫn còn trong giai đoạn đầu và các kết quả nghiên cứu về tính khả chuyển trên giao
diện dạng form vẫn còn chưa thật sự đầy đủ.
1.2.3. Nhận xét
Như đã trình bày, Cross-platform UI và MUI là hai hướng tiếp cận chính hiện
này để giải quyết bài toán phát triển giao diện trên nhiều thiết bị.
Trong Cross – platform user interfaces, cùng một đoạn mã nguồn, chạy trên
những platform khác nhau thì sẽ có cùng đối tượng thể hiện nhưng phong cách thể

hiện khác nhau. Mặc dù Cross – platform user interfaces đã có công nghệ minh họa
và ứng dụng là Java, .NET, QT và GTK, nhưng với những công nghệ này khả năng
7

mang chuyển mã nguồn chưa được giải quyết triệt để trên các loại thiết bị di động
có cấu hình phần cứng khác nhau.
Mặt khác nhánh nghiên cứu MUI nghiên cứu phương pháp luận phát triển giao
diện cho nhiều loại thiết bị. Cùng một ứng dụng nhưng được thể hiện bằng nhiều
đoạn mã nguồn, mỗi đoạn ứng với mỗi platform và sẽ có thể sẽ có những đối tượng
giao diện khác nhau nhưng phương pháp luận MUI sẽ cho phép tái sử dụng tối đa
những sưu liệu phần mềm độc lập thiết bị. Đây là một cách tiếp cận theo chúng tôi
là hứa hẹn để có thể xây dựng giao diện hiệu quả cho nhiều loại thiết bị. Tuy nhiên
hệ thống phương pháp luận và công nghệ minh họa của MUI thể hiện nhiều trường
phái, chưa được thống nhất, chưa được phát triển đầy đủ, các kết quả vẫn còn cần
được tiếp tục kiểm nghiệm, nghiên cứu và phát triển.
Tại Việt nam, thị phần phát triển ứng dụng trên thiết bị di động đang tăng trưởng,
khá mạnh, nhưng phần lớn các công ty chỉ áp dụng các công nghệ lập trình một
cách thủ công để giải quyết bài toán khả chuyển. Các nghiên cứu chuyên sâu về
phương pháp luận phát triển phần mềm, đặc biệt là giao diện phần mềm, cho nhiều
thiết bị di động vẫn còn rất thiếu vắng. Trong bối cảnh này, chúng tôi muốn tập
trung vào nghiên cứu hệ thống phương pháp luận trong MUID nhằm có thể vận
dụng một phương pháp hiệu quả để phát triển giao diện cho ứng dụng trên nhiều
thiết bị di động khác nhau.
1.3. Mục tiêu nghiên cứu
Trong phần này chúng tôi sẽ trình bày cụ thể vấn đề nghiên cứu được đặt ra trong
luận văn, các giới hạn của đề tài và những kết quả dự kiến của luận văn.
1.3.1. Đối tƣợng nghiên cứu
Hiện nay phương pháp luận MUID chưa có một chuẩn chung thống nhất về cách
phân loại mô hình, quy trình phát triển, ngôn ngữ đặc tả. Ngoài ra các công cụ vẫn
8

chưa được áp dụng nhiều, đặc biệt là công cụ hỗ trợ phát triển giao diện dạng form.
Chính vì vậy mà trong luận văn này chúng tôi sẽ tập trung vào nghiên cứu và vận
dụng các phương pháp luận trong MUID để giải quyết bài toán giao diện dạng form
trên các loại thiết bị.
Mục tiêu của chúng tôi là sẽ khảo sát một số các công trình nổi bật trong lĩnh
vực MUID và khả năng vận dụng các công trình này để phát triển giao diện form
trên các loại thiết bị khác nhau. Chúng tôi sẽ kiểm nghiệm thực tế các phương
pháp luận được tìm hiểu qua việc xây dựng một hệ thống hỗ trợ phát triển giao
diện người dung cho điện thoại di động theo hướng tiếp cận MUID. Dựa trên các
kết quả khảo sát, chúng tôi có thể sẽ đề xuất các bổ sung, cải tiến cần thiết để
nâng cao tính ứng dụng của những phương pháp này.
1.3.2. Giới hạn đề tài
a) Giới hạn platform
Luận văn nghiên cứu về phương pháp luận trong MUID nhưng được giới hạn
trong ngữ cảnh xây dựng giao diện form trên loại thiết bị di động sử dụng hệ điều
hành Windows Mobile và Android.
b) Giới hạn hướng tiếp cận
Một giới hạn nữa là về hướng tiếp cận giải quyết bài toán giao diện. Trong luận
văn này chúng tôi sẽ nghiên cứu giải quyết bài toán khả chuyển giao diện dựa trên
hai hướng tiếp cận chính là MBUID (Model – based User Interfaces Development)
và MDD (Model Driven Development).
Hướng tiếp cận này được lựa chọn dựa trên các nhận định sau đây:
- Các phương pháp luận trong MUID về cơ bản đều áp dụng hướng tiếp cận
chung MBUID. Hướng tiếp cận này đề xuất một tập các mô hình đặc tả giao
9

diện và một giải pháp kết hợp, phát triển các mô hình này để tạo ra giao diện
hoàn chỉnh.
- Sự trưởng thành của hướng tiếp cận MDD- hướng tiếp cận đặc trọng tâm vào

phát triển mô hình- trong những năm gần đây đã cung cấp các giải phát hiệu
quả bao gồm ngôn ngữ đặc tả quy trình và công cụ để phát triển và hiện thực
hóa các mô hình của quá trình phát triển.
- Xu hướng kết hợp hướng tiếp cận MDD và MBUID là một giải pháp hứa hẹn
vì tận dụng được các kết quả của MDD để giải quyết hiệu quả các vấn đề của
MBUID. Xu hướng này đã được khẳng định qua hàng loạt công trình nghiên
cứu gần đây trong lĩnh vực MUID, ví dụ là các bài viết trong Workshop
MDDAUI từ năm 2005 – 2009 đều đề cập đến những nghiên cứu kết hợp hai
hướng tiếp cận trên.
c) Kết quả nghiên cứu dự kiến
Luận văn tập trung nghiên cứu vấn đề xây dựng giao diện dạng form trên các loại
thiết bị di động sử dụng hệ điều hành Windows Mobile và Android. Các kết quả
nghiên cứu dự kiến bao gồm:
- Về lý thuyết: báo cáo tổng hợp các hướng tiếp cận MDD; hướng tiếp cập
MBUID; việc kết hợp MBUID và MDD. Từ đó nghiên cứu đề xuất một
phương pháp luận giải quyết mục tiêu của luận văn bao gồm: cách phân loại
mô hình, quy trình phát triển, phương pháp mô hình hóa, ngôn ngữ mô hình
hóa biểu diễn hệ thống giao diện trên các thiết bị di động sử dụng hệ điều
hành Windows Mobile và Android.
- Về mặt thực nghiệm: vận dụng phương pháp luận được đề xuất để xây dựng
một công cụ hỗ trợ xây dựng giao diện form trên platform Windows Mobile
và Android.

10

Chƣơng 2: Cơ sở lý thuyết và các hƣớng tiếp cận
Luận văn này được thực hiện qua việc áp dụng nhiều hướng tiếp cận và kỹ thuật
khác nhau nhưng dựa trên hai hướng tiếp cận chính là MDD và MBUID. Trong
chương này chúng tôi sẽ trình bày tóm tắt lý thuyết về hai hướng tiếp cận trên.
2.1. Hƣớng tiếp cận MDD

MDD (Model – Driven Development) là một hướng tiếp cận mới được cộng
đồng công nghệ phần mềm quan tâm phát triển từ những năm 2000. Khác với
hướng tiếp cận cổ điển xem xây dựng mã nguồn là hoạt động trung tâm của quá
trình phát triển phần mềm, MDD đặt trọng tâm vào việc xây dựng và chuyển đổi
các mô hình từ trừu tượng đến cụ thể để tạo ra sản phẩm cuối. Với cách tiếp cận
xem mô hình là trung tâm của quá trình phát triển, MDD muốn thông qua việc nâng
cao mức trừu tượng của các đối tượng làm việc cho phép sử dụng lại dễ dàng hơn
các sưu liệu và kết quả trung gian của quá trình phát triển. Nhờ đó, cách tiếp cận
này cũng cung cấp được một giải pháp hiệu quả cho bài toán tương thích cũng như
cho việc nâng cao hiệu suất phát triển.
Do mô hình là đối tượng trung tâm của MDD, nên trong phần này trước tiên
chúng tôi sẽ trình bày các khái niệm cơ bản về mô hình. Tiếp đến các tư tưởng
chính của hướng tiếp cập MDD sẽ được phân tích để làm rõ lợi ích của việc áp dụng
hướng tiếp cận này để giải quyết bài toán giao diện khả chuyển cho các loại thiết bị
di động. Cuối cùng, chúng tôi sẽ trình bày về các chuẩn quan trọng trong hướng tiếp
cận MDD, đặt biệt là kiến trúc MDA [5].
2.1.1. Các khái niệm cơ bản về mô hình
Trong phần này chúng tôi sẽ giới thiệu các khái niệm mô hình (model), ngôn ngữ
mô hình hóa chuyên biệt miền ứng dụng (DSL – Domain Specific Language) và
khái niệm siêu mô hình (metamodel).
11

a) Model
Một mô hình (Model) là đặc tả của một hệ thống theo một góc nhìn (View Point)
nào đó. Như vậy cùng một hệ thống có thể có nhiều mô hình phản ánh các góc nhìn
khác nhau của người khai thác hệ thống (Hình 2.1). Model được thể hiện thông qua
một ngôn ngữ mô hình hóa (Modeling Language). Ví dụ để mô tả một hệ thống,
người ta đặc tả hệ thống ở nhiều góc nhìn khác nhau với các loại mô hình tương
ứng như Use Case, Class, Sequence, v.v…

Hình 2.1 Mô tả Model đặc tả một hệ thống ở một View Point nào đó
b) DSL
Trong Công nghệ Phần mềm, thuật ngữ domain thường dùng để chỉ một miền,
một phạm vi ứng dụng (ví dụ miền ứng dụng các hệ thống nhúng, miền ứng dụng
các tiến trình dịch vụ). Để thể hiện các mô hình trong một miền ứng dụng chuyên
biệt nào đó, người ta thường dùng một DSL phù hợp. Một DSL – Domain Specific
Modeling Language - là một ngôn ngữ mô hình hóa phục vụ một miền ứng dụng
chuyên biệt. DSL định nghĩa các khái niệm chuyên biệt của miền ứng dụng này và
cách sử dụng các khái niệm này trong các mô hình mô tả những hệ thống thuộc về
miền ứng dụng.
Như tất cả các loại ngôn ngữ, để định nghĩa một DSL, cần phải định nghĩa cú
pháp (syntax) và ngữ nghĩa (semantics) của DSL. Cú pháp của một DSL xác định
tập các khái niệm được sử dụng trong DSL và sự liên hệ của các khái niệm này với
nhau (Abstract Syntax) cũng như quy định các bộ ký hiệu cụ thể dùng để thể hiện
các khái niệm này (Concrete Syntax). Ngữ nghĩa của DSL mô tả chính xác ý nghĩa
của từng khái niệm và mối liên hệ được định nghĩa trong DSL nhằm hướng dẫn
người dùng sử dụng đúng các khái niệm này trong khi xây dựng mô hình.
12

Có nhiều cách thức để định nghĩa cú pháp và ngữ nghĩa của DSL, một trong những
kỹ thuật hiện đại để làm việc này là dùng phương pháp meta-modeling, đặc tả ngôn
ngữ thông qua các siêu mô hình – metamodel.
c) Metamodel
Siêu mô hình (metamodel) là một mô hình được dùng để định nghĩa cú pháp trừu
tượng (Abstract Syntax) của một ngôn ngữ. Metamodel thể hiện mối liên hệ giữa các
khái niệm được định nghĩa bởi ngôn ngữ, qua đó xác định sự hợp lệ của các mô hình có
thể biểu diễn bằng ngôn ngữ đang xem xét. Mọi mô hình được thể hiện bằng một ngôn
ngữ mô hình hóa phải có quan hệ tương hợp (conform) với metamodel định nghĩa ngôn
ngữ được sử dụng (Hình 2.2). Nói cách khác, các khái niệm được sử dụng trong mô
hình phải là những thể hiện của các khái niệm được định nghĩa trong metamodel. (Hình

2.3) là một minh họa cho việc định nghĩa model dựa theo cú pháp trừu tượng của
metamodel.

Hình 2.2 Mô tả một Model dựa theo – c2 – conform to
Metamodel

Hình 2.3 Một ví dụ về metamodel

13

2.1.2. Tƣ tƣởng chính của hƣớng tiếp cận MDD
Theo MDD, việc phát triển phần mềm là quá trình chuyển đổi từ mô hình có độ
trừu tượng từ cao đến các mô hình cụ thể hơn, và cuối cùng thông thường là code.
Trong MDD, các mô hình được phân chia theo mức độ trừu tượng – mức độ phụ
thuộc của mô hình vào môi trường phát triển cụ thể. Ở bậc trừu tượng cao nhất
thông thường là các mô hình nghiệp vụ của hệ thống, sau đó là các mô hình mô tả
chức năng, kiến trúc hệ thống nhưng độc lập với platform phát triển, sau cùng là các
mô hình với độ trừu tượng thấp hơn phản ánh hệ thống được thực thi, triển khai trên
nền một môi trường cụ thể. Loại mô hình cụ thể nhất có thể xem là mã nguồn của
hệ thống.
Hoạt động chính trong phương pháp phát triển MDD là chuyển đổi mô hình
(model transformation). MDD mô tả tường minh các luật chuyển đổi để biến đổi
một mô hình sang một mô hình khác (có thể cùng hoặc khác mức trừu tượng, có thể
cùng hoặc khác ngôn ngữ biểu diễn). Quy trình phát triển cơ bản của MDD là khởi
đầu với các mô hình độc lập môi trường phát triển, chỉ phản ánh chức năng nghiệp
vụ của hệ thống, rồi chuyển đổi dần mô hình này xuống các mức trừu tượng thấp
thông qua việc thêm dần vào mô hình ban đầu các chi tiết cụ thể của việc xây dựng
hệ thống. Thông thường quy trình phát triển dừng lại với việc phát sinh mã nguồn
của hệ thống.
Cách tiếp cận MDD một mặt cho phép trì hoãn tối đa việc thể hiện các chi tiết cụ

thể của platfom xây dựng ứng dụng vào các mô hình phát triển hệ thống. Do đó các
sưu liệu của những bước phân tích, thiết kế không phụ thuộc vào platform có thể
được sử dụng lại dễ dàng hơn. Ngoài ra, cùng một mô hình ở mức trừu tượng cao và
độc lập platform, có thể phát sinh ra nhiều mô hình cụ thể tương ứng với các
platform chuyên biệt trên nhiều loại thiết bị. Ưu điểm này giúp cho hướng tiếp cận
MDD trở thành một giải pháp hiệu quả cho bài toán tương thích. Mặt khác, nhờ vào
việc hình thức hóa các luật chuyển đổi, MDD có thể cho phép tự động hóa việc
14

chuyển đổi mô hình, thông qua đó nâng cao hiệu suất của quá trình phát triển hệ
thống.
2.1.3. Các chuẩn hƣớng tiếp cận MDD
Cùng trong hướng tiếp cận MDD, có nhiều phương pháp khác nhau được đề xuất
để hiện thực hóa quá trình phát triển. Nổi bật có thể kể đến MDA – Model-Driven
Architecture của tổ chức OMG [5], MIC – Model Integrated Computing của nhóm
ISIS đại học Vanderbilt [6], SF – Software Factories của công ty Microsoft [7], và
một số chuẩn khác (Hình 2.4).

Hình 2.4 Công nghệ phát triển hƣớng mô hình MDD, các chuẩn hƣớng tiếp cận và công cụ hỗ trợ
Trong các chuẩn kể trên, có thể nói MDA của OMG là tiền thân của hướng tiếp
cận MDD. MDA được công bố rộng rãi, được quan tâm nghiên cứu và ứng dụng
nhiều nhất để tạo ra các công cụ hỗ trợ trong quá trình xây dựng phần mềm. Ví dụ
các công cụ hỗ trợ vẽ mô hình, hỗ trợ chuyển đổi mô hình, hỗ trợ phát sinh source
code được phát triển mạnh trên môi trường Eclipse. Từ đây trở về sau trong luận
văn này khi nhắc đến MDD chúng tôi hàm ý nói đến các ý tưởng gốc của cách tiếp
cận MDA.
15

2.1.4. Hƣớng tiếp cận MDA
Theo tài liệu MDA [5], MDA do tổ chức OMG đề xuất năm 2000, hướng tiếp

cận MDA định hướng các công cụ hỗ trợ phải có khả năng:
Xác định phần độc lập giữa hệ thống và platform.
Xác định phần phụ thuộc platform.
Chọn một platform chuyên biệt mà hệ thống phụ thuộc
Chuyển đổi hệ thống từ đặc tả platform này sang đặc tả ở platform khác
Ngoài ra, các sưu liệu do công cụ hỗ trợ tạo ra phải có cả ba tính chất sau: tính
khả chuyển – portability, tương vận – interoperability, khả dụng – reusability.
Để đạt mục tiêu khả chuyển, MDA đề ra kiến trúc Metadata MOF – MOF
Metadata Architect [8]. Để đạt các mục tiêu còn lại MDA phân chia các góc nhìn
phụ thuộc trong một hệ thống.
a) Kiến trúc Metadata MOF

Hình 2.5 Kiến trúc Metadata MOF – MOF Metadata Architecture [8]
16

Để có thể phát triển được công cụ hỗ trợ phát triển hệ thống đạt mục tiêu khả
chuyển, MDA định hướng phát triển hệ thống theo kiến trúc Metadata MOF như
trình bày ở (Hình 2.5). Trong đó, M0 là hệ thống cần xây dựng. Hệ thống này được
mô tả bởi các mô hình ở mức M1. Mức cao hơn là M2 chứa metamodel định nghĩa
ngôn ngữ mô tả các model ở mức M1. Mức trên cùng M3 là meta-metamodel định
nghĩa ngôn ngữ mô tả các metamodel ở mức M2. Meta-metamodel được xây dựng
thông qua các khái niệm mà nó định nghĩa. Để hỗ trợ việc định nghĩa ngôn ngữ mô
hình hóa dễ dàng hơn, OMG đề xuất một meta-metamodel chung nhất với tên gọi là
MOF – Meta Object Facility [8].
b) Các góc nhìn trong MDA – MDA View Point
Để định hướng xây dựng công công cụ hỗ trợ mô tả hệ thống ở các mức độ phụ
thuộc platform khác nhau và định hướng việc chuyển đổi mô hình. Trong tài liệu
MDA [5], MDA đề nghị mô tả hệ thống ở các mức độ phụ thuộc – View Point sau:
Mô hình độc lập tính toán – CIM – Computation Independent Model
Mô hình độc lập nền – PIM – Platform Independent Model

Mô hình phụ thuộc nền – PSM – Platform Specific Model
Ngoài ra, trong MDA cũng đề nghị mối quan hệ giữa các loại Model hay các View
Point trên được đặc tả dưới dạng các ánh xạ – mapping dùng để chuyển đổi –
transformation các mô hình. Ánh xạ chuyển đổi là một tập các luật và kỹ thuật dùng
để mô tả phát sinh từ một Model sang một hoặc nhiều Model khác. Việc chuyển đổi
mô hình giữa các View Point trên được minh họa như (Hình 2.6).
17


Hình 2.6 Minh họa chuyển đổi giữa các view point trong kiến trúc MDA
c) Phương pháp chuyển đổi mô hình
c.1. Chuyển đổi mô hình thủ công
Theo phương pháp này, các mô hình được chuyển đổi một cách thủ công bằng
kiến thức cá nhân của người thiết kế. Mô hình không được chuyển đổi tự động. Vì
vậy nếu mô hình có thể chuyển đổi tự động thì sẽ giảm nhiều thời gian phát triển.
c.2. Chuyển đổi mô hình tự động
Với phương pháp này, mô hình được chuyển đổi dựa trên các template hoặc tập
luật. Với cách này các mô hình được đánh dấu – mark (bởi profile UML) hoặc quy
định ngầm của người lập trình. Tuy nhiên việc chuyển đổi các loại mô hình
thường không là một song ánh. Các kỹ thuật chuyển đổi hiện tại (như ATL [9],
QVT [10], v.v…) chưa hỗ trợ bổ sung tham số trong quá trình chuyển đổi, chính vì
18

vậy làm hạn chế tính linh động trong quá trình chuyển đổi hoặc có thể dẫn đến mất
mát thông tin.
c.3. Chuyển đổi mô hình dựa trên Transformation Model
Để có thể sử dụng tham số giúp quá trình chuyển đổi linh động hơn trong tài liệu
MDA [5] đề nghị giải pháp chuyển đổi mô hình tổng quát – General Model to
Model transformation. Trong giải pháp này đề xuất một mô hình trung gian là
Tranformation Model (Hình 2.7) giữa các mô hình cần chuyển đổi rồi sau đó mới áp

dụng template hoặc tập luật chuyển đổi. Đây là một giải pháp bán tự động. Trong
mô hình trung gian này, người phát triển sẽ cấu hình các tham số cần thiết để có thể
từ đó chuyển đổi ra mô hình mong muốn. Với cách này sẽ linh động hơn giải pháp
tự động đã trình bày ở trên.

Hình 2.7 Giải pháp chuyển đổi mô hình tổng quát trong kiến trúc MDA [5]