ĐẠ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
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
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
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
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
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ể
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
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…
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ụ
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
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]
Copyright: Tài liệu đại học ©