MÔ HÌNH CHUYỂN đổi bán tự ĐỘNG GIAO DIỆN TĨNH WEB SILVERLIGHT 5 0 SANG ANDROID 4 2 dựa TRÊN GIẢI PHÁP TRANUI

ISBN: 978-604-82-1375-6 10VII-O-2 MÔ HÌNH CHUYỂN ĐỔI BÁN TỰ ĐỘNG GIAO DIỆN TĨNH WEB SILVERLIGHT 5.0 SANG ANDROID 4.2 DỰA TRÊN GIẢI PHÁP TRANUI Nguyễn Đức Huy, Nguyễn Văn Vũ, Trần Minh

ISBN: 978-604-82-1375-6 10

VII-O-2

MÔ HÌNH CHUYỂN ĐỔI BÁN TỰ ĐỘNG GIAO DIỆN TĨNH WEB SILVERLIGHT 5.0

SANG ANDROID 4.2 DỰA TRÊN GIẢI PHÁP TRANUI Nguyễn Đức Huy, Nguyễn Văn Vũ, Trần Minh Triết

Khoa Công Nghệ Thông Tin, Trường Đại Học Khoa Học Tự Nhiên, ĐHQG-HCM

Email: {ndhuy,nvu,tmtriet}@fit.hcmus.edu.vn

TÓM TẮT

Nội dung của bài báo sẽ trình bày mô hình chuyển đổi bán tự động giao diện tĩnh của các trang Web được xây dựng bằng công nghệ Microsoft Silverlight 5.0 sang giao diện ứng dụng của nền tảng Android 4.2 trên các thiết bị di động Dựa trên giải pháp của TranUI, nhóm tác giả đã xây dựng 2 mô hình giao diện của công nghệ

MS Silverlight 5.0 và Android 4.2, mô hình chuyển đổi tổng quát (CUI) của các giao diện giữa các nên tảng trên Bên cạnh đó, để thực hiện việc chuyển đổi, nhóm tác giả đã đề xuất chuyển 2 tập luật thực hiện việc chuyển đổi giữa các mô hình trên

Từ khóa: RIA, MDD, MBUID, Tranformation Modeling, User Interface, Silverlight, Android UI

GIỚI THIỆU

Với sự phát triển của Internet trên toàn thế giới ngày nay, các hoạt động của hàng ngày của con người như trao đổi thông tin, liên lạc, làm việc, tìm kiếm thông tin… đều được thực hiện trên môi trường mạng Từ đó, các ứng dụng web với việc hỗ trợ giao diện thân thiện và gần gũi với người dùng đã gần như thay thế các ứng dụng desktop Bên cạnh đó, sự phát triển của công nghệ RIA (Rich Internet Application) càng mang lại sức mạnh hơn cho các ứng dụng web RIA – Rich Internet Application1 là một ứng dụng web mang nhiều đặc điểm của một ứng dụng desktop Cơ chế hoạt động của RIA thường là giao tiếp giữa các trình duyệt web, thông qua các

plug-in, các vùng độc lập trên website (sandbox), các đoạn mã Javascript hoặc các máy ảo (virtual machine) riêng của từng nền tảng RIA cụ thể Giai đoạn năm 2007 – 2008 là thời điểm phát triển mạnh mẻ nhất của các ứng dụng RIA Điển hình nhất trong hướng công nghệ này là các nền tảng Adobe Flash/Flex, Microsoft Silverlight và JavaFX Bên cạnh đó, Ngoài ra, theo số liệu thống kê của Wikimedia và IDC vào những năm gần đây (đặc biệt

là từ 2010 cho đến 2013) công nghệ di động và truyền thông phát triển mạnh mẽ Cùng với sự phát triển của các công nghệ di động đã đem đến sự tiện lợi cho người dùng cuối với tính linh động và tiện dụng của chúng Số lượng người sử dụng các thiết bị di động trong những năm gần đây tăng mạnh Doanh số bán ra và số truy cập vào internet từ các thiết bị di động đã hơn hẳn máy tính cá nhân (laptop và desktop) Từ đó, nhu cầu các ứng dụng trên các nền tảng di động cũng ngày càng tăng nhanh

Hình 1là thể hiện nhu cần cần chuyển đổi các ứng dụng trên thống đã có trên một nền tảng Web sang các ứng dụng trên các nền tảng di động Mặc dù các thiết bị di động đều có các trình duyệt web cho phép người dùng cuối thao tác với các ứng dụng web như Facebook, Youtube, GMail… Nhưng ứng dụng web vẫn chưa tận dụng hết các ưu điểm của các thiết bị di động như: đồng bộ hóa danh bạ với các ứng dụng Gmail, tự động thông báo khi có mail mới… Vì vậy, các nhà phát triển đã hướng đến việc xây dựng riêng ứng dụng trên từng nền tảng di động khác nhau cho hệ thống của mình

Hình 1 Giao diện của ứng dụng FaceBook và Gmail trên nền Web, iOS và Android

Tuy nhiên, chi phí để phát triển các ứng dụng trên nhiều nền tảng di động khác nhau sẽ rất lớn Đặc biệt, quá trình chuyển đổi giao diện giữa các nền tảng sẽ rất tốn thời gian và chi phí để đảm bảo giữ nguyên các thông

số của các thành phần trên giao diện.Bảng 1 là bảng khảo sát và thông kê chi phí phát triển của một dự án ứng

1 RIA – Rich Internet Application: http://en.wikipedia.org/wiki/Rich_Internet_application

Báo cáo toàn văn Kỷ yếu hội nghị khoa học lần IX Trường Đại học Khoa học Tự nhiên, ĐHQG-HCM

dụng di động cụ thể (thường là phát triển trên nền tảng iOS trước) và sau đó chuyển đổi sang các nền tảng di động khác như: Android, Windows Phone, … từ các doanh nghiệp phần mềm ở Việt Nam

Bảng 1 Bảng khảo sát chi phí phát triển và chuyển đổi nền tảng trên thiết bị di động của các công ty phần mềm

Việt Nam trong năm 2013

Stt Công ty Ứng dụng

Quá trình phát triển Quá trình chuyển đổi nền tản Nền tảng Thời gian Số nhân

lực Nền tảng

Thời gian/nền tảng

Số nhân lực/nền tảng

Số thiết bị

1 KMS Empire Suite iOS > 2 năm 10 iOS,

Android

>2 năm 3 – 4 4 (iOS), 7

(Android)

2 Gameloft Asphat 8 iOS 9 tháng – 1

năm

30 Android 4 – 5 tháng 5 – 6 57

3 Gameloft Modern

Combat 5

iOS 9 tháng – 1

năm

30 Android 4 – 5 tháng 5 – 6 57

4 Gameloft Real Football

2013

iOS 9 tháng – 1

năm

30 Android 4 – 5 tháng 5 – 6 57

5 Gameloft Miami

Vindication

Brew, BB

OS

1.5 – 2.5 tháng

6 Gameloft Zombie

Infection 2

Brew, BB

OS

1.5 – 2.5 tháng

7 Gameloft Sally's Studio J2ME 6 tháng 10 J2ME,

Brew, BB

OS

1.5 – 2.5 tháng

Brew, BB

OS

1.5 – 2.5 tháng

9 VNG Thế giới

phim

Android 4 tháng 8 Android,

iOS, BB

10

3 tháng – 2 tháng – 1 tháng

1 – 1 – 1 5 – 3 – 2

Android

3 tháng – 3 tháng

1 – 1 3 – 5

12 VNG Trùm bắn ca

iOS

Qua bảng thống kê (Bảng 1), cho thấy chi phí chuyển đổi sẽ mất ít nhất là 2 tháng và ứng với từng nền tảng cần phải có ít nhất từ 1 đến 2 lập trình viên làm việc trên nền tảng đó (chi phí này chưa tính đến nguồn nhân lực thiết kế đồ họa) Thực tế trên đã cho thấy nhu cầu trong việc chuyển đổi ứng giữa các ứng dụng là rất cần thiết Bên cạnh đó, với một thời gian rất dài phát triển của các ứng dụng RIA[1][2][3], số lượng các ứng dụng trên nền tảng này rất lớn Tuy nhiên, nền tảng RIA tiêu tốn quá nhiều năng lượng của thiết bị client nên một số nền tảng

di động không cho các dạng ứng dụng RIA này họat động Vì thế, nhu cầu cần chuyển đổi các ứng dụng trên nền tảng RIA sang ứng dụng trên thiết bị di động càng cần thiết hơn

Xuất phát từ những nhu cầu cần chuyển đổi các ứng dụng RIA (cụ thể là Microsoft Silverlight) đã tồn tại sang các nền tảng của thiết bị di động, nhằm giảm thiểu chi phí trong quá trình chuyển đổi công nghệ, nhóm nghiên cứu sẽ tập trung giải quyết các vấn đề sau: (1) xây dựng mô hình chuyển đổi nền tảng trung gian CUI cho nền tảng Microsoft Silverlight 5.0 và Android 4.2, (2) mô hình hóa các thành phần giao diện của Microsoft Silverlight 5.0 và Android 4.2, (3) xây dựng 2 tập luật chuyển đổi giữa giữa 3 mô hình trên, (4) thực nghiệm chuyển đổi các giao diện của ứng dụng cụ thể

Để giải quyết các vấn đề trên, chúng tôi đã dựa trên các kết quả nghiên của của giải pháp TranUI [27] mà nhóm đã thực hiện và trình bày ở hội FAIR 2014 tại Đại học Thái Nguyên

Cơ sở lý thuyết và các công trình liên quan

ISBN: 978-604-82-1375-6 12

Để thực hiện đề tài, nhóm nghiên cứu các vấn đề về mô hình hóa phần mềm, đặc biệt là hướng tiếp cận mô hình hóa giao diện phần mềm Đề tài sẽ tập trung vào việc nghiên cứu chuyển đổi mô hình giao diện UI (User Interface) [7][8][9] dựa vào các phương pháp MDD (Model Driven Development), MDA (Model Driven Architecture), MBUID (Model-Based User Interface Development) kết hợp với hướng nghiên cứu OOHDM (Object-Oriented Hypermedia Design Method) và hướng nghiên cứu cải tiến OOH4RIA (Object-Oriented Hypermedia fof Rich Internet Application)

Hướng tiếp cận MDA (Model – Driven Architecture)

MDA (Model – Driven Architecture)[4] là một phương pháp tiếp cận thiết kế và xây dựng kiến trúc hệ thống theo phương pháp mô hình, được tổ chức OMG đề xuất vào năm 2000 Hướng tiếp cận này dựa trên các

thành phần đặc trưng của một hệ thống cần có MDA đề xuất 3 mô hình ở mức độ phục thuộc: CIM –

Computation Independent Model - mô hình độc lập tính toán, PIM – Platform Independent Model - mô hình độc lập nền tảng, PSM – Platform Specific Model - mô hình phụ thuộc nền tảng Để định nghĩa cấu trúc lưu trữ của

các mô hình phụ thuộc, MDA đề xuất kiến trúc MOF[5] Kiến trúc MOF Metadata[17] được phân thành 4 tầng thiết kế, dựa trên quan điểm đề xuất trong kiến trúc lưu trữ Metadata truyền thống: M3 layer - MOF Model: là một mô hình hướng đối tượng, M2 layer – Metamodel: là tầng không cố định trong kiến trúc metadata MOF, M1 layer – Model: là một tập hợp các metadata, không nhất thiết bị giới hạng bởi meta-layer, M0 layer: đây là tầng thể hiện cụ thể cấu trúc mô hình cụ thể trên từng nền tảng

Hướng tiếp cận MBUID (Model – Based User Interface Development)

MBUID[6]cũng là một phương pháp luận thiết kế giao diện phần mềm theo hướng mô hình Hệ thống được được phát triển dự trên thiết kế của các loại mô hình Các loại mô hình này cũng được đưa ra theo từng mức trừu tượng và có sự chuyển đổi của qua các loại mô hình này để phát sinh ra code phụ thuộc vào nền tảng tương ứng Điểm khác biệt giữa MDD và MBUID là trong MBUID không có khái niệm Metamodel Do đó, các model trong MBUID được xây dựng có tính chất hình thức Việc chuyển đổi giữa các mô hình trong MBUID được thực hiện theo phương pháp thủ công, dùng template mẫu hoặc các bộ luật nhưng ít tính chất linh động Có nhiều nhóm nghiên cứu về MBUID, do đó cho đến nay vẫn chưa có một chuẩn thống nhất chung Dưới đây là một số phương pháp và ký hiệu mô hình của các nhóm nghiên cứu đạt kết quả tốt và phổ biến Về phân loại mô hình có 2 phương pháp là phân loại theo mức độ trù tượng[18][19] và phân loại mô hình theo chức năng Phương pháp phân loại theo mức độ trừu tượng[18][19] định nghĩa 4 loại mô hình: Task Model, AUI – Abstract User Interface với công cụ hỗ trợ UsiXML[20], CUI – Concrete User Interface với công cụ hỗ trợ Teresa XML[21], FUI – Final User Interface – là code giao diện trên nền tản cụ thể Phương pháp phân loại theo chức năng định nghĩa 2 nhóm mô hình là: nhóm 1 với các mô hình Data model, Domain model và Application model với công

cụ hỗ trợ là SEESCOA[22], nhóm 2 với các mô hình Dialog model và Presentation model Bên cạnh đó, MBUID

đề xuất nhiều qui trình phát triển và chuyển đổi khác nhau như: qui trình tổng quát[19] được đề xuất vào năm

1996, qui trình CAMELEON Framework[23][24] được đề xuất năm 2001, qui trình TERESA XML[21], qui trình UsiXML[20] được đề xuất năm 2005 và qui trình MANTRA[25] được đề xuất năm 2006 Đa phần các hướng nghiên cứu trên về mô hình hóa giao diện người dùng, sẽ sử dụng một trong các qui trình trên để thực hiện việc mô hình hóa Tuy nhiên có nhiều nhóm công bố qui trình của mình kèm công cụ hỗ trợ, có nhóm chỉ công bố qui trình, không công bỗ công cụ hỗ trợ nên sẽ gặp nhiều khó khắn trong việc việc so sánh và kiểm chứng các qui trình Nhưng đa phần các hướng nghiên cứu đề phát triển dựa trên qui tổng quát Do đó, trong đề tài chúng tôi sử dụng qui trình này để thực hiện đề tài nghiên cứu

Hướng nghiên cứu OOHDM (Object – Oriented Hypermedia Design Method)

OOHDM (Object-Oriented Hypermedia Design Method)[9][10][11] là một phương pháp thiết kế giao diện cho các dạng ứng dụng siêu truyền thông (hypermedia) theo hướng đối tượng và được nhúng vào nền web Hướng nghiên cứu này được đề xuất vào năm 1995 OOHDM là một mô hình nền tảng cho việc xây dựng các ứng dụng Hypermedia lớn Nó được sử dụng để thiết kế nhiều loại ứng dụng khác nhau như: website, hệ thống thông tin, Kiosk tương tác, các ứng dụng trình diễn truyền thông đa truyền thông… OOHDM gồm có 4 thể hiện

cụ thể: Conceptual design: thiết kế các khái niệm, Navigational design: thiết kế các định hướng, Abstract Interface Design: thiết kế giao diện ở mức trừu tượng, Implementation: hiện thực hóa.Các thành phần trên giao diện nguyên thủy sẽ được chia ra thành các đối tượng Và điều này sẽ linh động hơn và dễ dàng hơn trong việc thiết kế và cập nhật/thay đổi mô hình của giao diện ứng dụng Ngoài ra với tính chất thiết kế hướng đối tượng được chia thành 4 mô hình trong OOHDM sẽ tách biệt và chuyên biệt hóa các chức năng trên giao diện Từ đó, việc tái sử dụng các thành phần thiết kế trên giao diện trước đó sẽ dễ dàng hơn

Hướng nghiên cứu OOH4RIA (Object Oriented Hypermedia design method for Rich Internet Application)

OOH4RIA[12][13] là một phương pháp luận thiết kế mô hình hóa các ứng dụng trên nền tảng RIA – Rich Internet Application dựa trên phương phương pháp OOHDM kết hợp với thư viện GWT – Google Web Toolkit của Google Phương pháp luận này được nhóm tác giả Tây Ban Nha đề xuất vào năm 2008 Bên cạnh đó,

Báo cáo toàn văn Kỷ yếu hội nghị khoa học lần IX Trường Đại học Khoa học Tự nhiên, ĐHQG-HCM

OOH4RIA thừa kế các phương pháp chuyển đổi trong MDA để thực hiện phép chuyển đổi giữa các mô hình của mình như: PIMToPIM, PIMToPSM, PIMToCode, PSMToCode… OOH4RIA định nghĩa các loại mô hình sau: OOH Domain Model - mô hình miền ứng dụng, Navigation Model - mô hình chuyển hướng, Orchestration Model skeleton - Mô hình phối hợp theo mẫu skeleton, Presentation Model skeleton - Mô hình giao diện theo mẫu skeleton, Orchestration Model - Mô hình phối hợp, Presentation Model - Mô hình giao diện Bên cạnh đó,

nhóm tác giả còn đề xuất quy trình phát triển một hệ thống ứng dụng theo phương pháp luận OOH4RIA(Error! Reference source not found.) gồm có 4 giai đoạn: OOH Designer – thiết kế các đối tượng OOH, Model

Transformer – chuyển đổi mô hình, UI Designer – thiết kế giao diện người dùng, Orchestration Designer – thiết

kế mô hình phối hợp hoạt động

Hình 2 Quy trình phát triển hệ thống RIA với OOH4RIA[12]

Trong đó, 3 giai đoạn OOH Designer, UI Designer, Orchestration Designer cần có sự can thiệp của con người Chỉ có duy nhất quá trình Model Transformer để thực hiện 4 phép chuyển đổi là PIMToPSM cho Nav2Orch, PIMToPSM cho Nav2Pre và PIMToCode cho GWT Server side và PSMToCode cho GWT Client side là được thực hiện tự động Đích cuối cùng của quy trình này là một ứng dụng RIA hoàn chỉnh Cũng trong năm 2008 nhóm tác giả này đã công bố một nghiên cứu sử dụng OOH4RIA để thực hiện chuyển đổi tầng giao diện giữa các ứng dụng RIA[1] Trong bài báo này, tác giả trình bày một thực nghiệm ứng dụng OOH4RIA và

bộ thư viện hỗ trợ[26] để tổng quát hóa và chuyển đổi tần giao diện của các ứng dụng RIA

Giải pháp TranUI

Dựa trên nền tảng của các nghiên cứu về mô hình ở trên, đặc biệt là khuyết điểm quá phức tạp của hướng nghiên cứu OOH4RIA, nhóm đã đề xuất một giải pháp thực hiện chuyển đổi bán tự động giữa các giao diện tĩnh của các ứng dụng RIA sáng giao diện của các ứng dụng di động với tên gọi TranUI TranUI được xây dựng dựa trên các khái niệm của hướng nghiên cứu MBUID là chính Giải pháp pháp TranUI đề xuất một qui trình

(Hình 3 Qui trình chuyển đổi của giải pháp TranUI) thực hiện xây dựng một hệ thống chuyển đổi gồm

các thành phần sau:

WebUI model – Web User Interface model: là mã nguồn đặc tả giao diện của website trên nền tảng công

nghệ RIA

In order to understand this approach, this paper

presents a new model-driven development process

applied to a case study called GWT Mail Application

[7] In section 2, we give an overview of the process

using the model-driven specific SPEM notation The

subsequent sections detail the different artefacts of this

process Section 3 presents the OOH domain and

navigation models that specify the RIA server side In

sections 4 and 5, we introduce the main contribution of

this work namely the presentation and orchestration

models Once all models are defined, we propose the

specification of the transformation models used for

accelerating this process, as we can see in section 6

Finally, sections 7 and 8 outline the relevant related

work and the future lines of research

2 The Model-Driven development process

of OOH4RIA

We propose a model-driven development process

allowing to specify an almost complete Rich Internet

Application (RIA), through the extension of the

traditional Web methodologies like OOH with two

new RIA presentation models which will be introduced

in this paper

Figure 1 is a graphical representation of the

model-driven development process with definition of models

and transformations that permit to obtain a RIA

implementation A notation proposed by the OMG

standard SPEM represents this process This diagram

introduces a set of stereotypes specific for

model-driven processes It includes an actor stereotype able to

represent a transformation engine called Model

Transformer and defines a set of stereotypes of the

metaclass activity to represent different MDA

transformations such as PIMToPIM, PIMToPSM,

PIMToCode, PSMToCode, etc

The process starts with the OOH designer defining

the OOH domain model to represent the domain

entities and the relationships between them From this

model, the OOH designer represents the navigation

through the domain concepts and establishes the

visualization constraints using the navigation model

With the definition of both OOH models begins the

part of the process that constitutes the main

contribution of this work

It first transforms the navigation model into the

presentation model by means of the PIM2PSM

transformation called Nav2Pres This presentation

model is specifically defined for the GWT platform

allowing us to capture clearly the different widgets that

constitute a GWT interface The Nav2Pres is a

model-to-model transformation defined in QVT that

establishes the different screenshots of the model presentation

After obtaining the container screenshots of the presentation model, the User Interface designer completes them placing the widgets, defining the style and establishing the spatial configuration by means of Panels It is worth pointing out that these widgets can

be related to a navigational element thereby showing the dynamic content coming from the server side into the user interface

OOH Designer Model

Transformer UI Designer

Orchestration Designer

Define OOH Domain Model

Define OOH Navigational Model

<<PIMToPSM>>

Nav2Pres

Presentation Model skeleton

Orchestation Model skeleton

OOH Domain Model

<<PIMToPSM>>

Pres&Nav2Orch

Presentation Model Orchestation Model

Define Complete Orchestation Model

Define Complete Presentation Model

OOH Navigation Model

Rich Internet application

<<PSMToCode>>

GWT Client side

<<PIMToCode>>

GWT Server side

<<WorkDefinition>>

Model-Driven Development Process of OOH4RIA

Figure 1 The OOH4RIA model-driven

development process

Since the RIA possesses a rich interactive user interface similar to desktop applications, we must complete the static features of widgets with a model that will allow us to specify the interaction between these widgets and the rest of the system This model has been called orchestration model and is represented

as a UML profile of state machine diagram The orchestration model does not have to be defined from scratch because a model-to-model transformation

called Pres&Nav2Orch allows us to obtain the

skeleton of the orchestration model from the navigation and presentation models

The model-to-model transformation starts by establishing the screenshots behavioural states and their transitions from the navigational nodes and the associations respectively It also defines the widget behavioural states corresponding to the widgets represented in the presentation model At this point, the

14

ISBN: 978-604-82-1375-6 14

CUI model – Concrete User Interface model: là mô hình mô tả giao diện cụ thể nhưng độc lập với nền tảng

(đây là mô hình chuyển đổi trung gian)

FUI model – Final User Interface model: mô hình mã nguồn của nền tảng Model tương ứng

Web2CUI Transformer – Web to CUI transformer: là bước chuyển đổi từ mô hình mã nguồn giao diện

Web sang mô hình mô tả giao diện

CUI2FUI Transformer – CUI to FUI transformer: bước chuyển đổi từ mô hình mô tả giao diện sang mã

nguồn của nền tảng

Hình 3 Qui trình chuyển đổi của giải pháp TranUI

Đề xuất giải pháp và mô hình

Dựa trên giải pháp chuyển đổi TranUI, nhóm tác giả đã thực hiện xây dựng mô hình chuyển đổi bán tự động giao diện tĩnh của các ứng dụng Microsoft Silverlight 5.0 sang giao diện của ứng dụng di động Android 4.2 Để thực hiện việc chuyển đổi này, nhóm đã xây dựng qui trình chuyển đổi như Hình 4 và các mô hình giao diện cùng 2 tập luật chuyển đổi

Hình 4 Áp dụng qui trình chuyển đổi TranUI cho các nền tảng Microsoft Silverlight 5.0 và Android 4.2

Theo khảo sát thống kê, cấu trúc mã XAML của công nghệ Microsoft Silverlight và cấu trúc đặc tả giao diện của Android XML đều dựa trên bộ cấu trúc ngữ pháp XML Hai nền tảng này có nhiều điểm tương đồng nên về cấu trúc và thành phần giao diện nên có thể chuyển đổi được Chúng tôi đã thực hiện thử nghiệm trên 2 nền tảng này Để thực hiện theo các bước của quy trình TranUI đã đề xuất, chúng tôi đã xây dựng 3 mô hình Silverlight WebUI, CUI (dùng chung) và Android FUI Để thực hiện chuyển đổi giữa các mô hình này, chúng tôi

đã xây 2 bộ luật chuyển đổi Các phần tiếp theo của chương này sẽ trình bày chi tiết về khảo sát công nghệ cũng như các thức xây dựng mô hình và các bộ luật chuyển đổi của toàn hệ thống

Kiến trúc mô hình WebUI của Microsoft Silverlight 5.0

Khảo sát đặc điểm control trên giao diện

Theo khảo sát thực tế, tính đến thời điểm tháng 8 năm 2013, Microsoft Silverlight version 5.0 hỗ trợ 34 control với 181 loại thuộc tính Nhưng để thỏa mãn tính khả chuyển đổi giữa các đối tượng tương thích (trong

thời gian nghiên cứu phát triển luận văn) chúng tôi chỉ thực hiện chuyển đổi đối với các control sau: Button, Canvas, CheckBox, ComboBox, DatePicker, Image, Label, ListBox, PasswordBox, ProgressBar, RadioButton, ScrollViewer, TextBox, Slider

Silverlight WebUI Model

CUI Model

Android FUI Model

WebUI2CUITransformer

CUI2FUITransformer

Báo cáo toàn văn Kỷ yếu hội nghị khoa học lần IX Trường Đại học Khoa học Tự nhiên, ĐHQG-HCM

Dựa trên đặc thù của các control này, chúng tôi mô hình hóa thành các Metamodel SliverlightWebUI (sẽ được trình bày trong phần tiếp theo) Số control còn lại, do tính chất đặc thù và phức tạp vì chỉ thương tích với các dạng ứng dụng web nên chưa thể thực hiện chuyển đổi Chúng tôi có nghiên cứu giải pháp sẽ cài đặt mới control mới tương ứng cho các nền tảng di động Ví dụ: cài đặt mới control TreeView cho nền tảng Android để

có thể chuyển đổi control TreeView từ Silverlight sang Android Nhưng do trong phạm vi giới hạn và thời gian hoàn thành luận văn không cho phép nên chúng tôi không thực hiện phương pháp này để hỗ trợ có thể chuyển

đổi đầy đủ các control Silverlight để đảm bảo tính đầy đủ và tính đúng đắng trong quá trình chuyển đổi

Kiến trúc Microsoft Silverlight WebUI

Trong phần này, chúng tôi trình bày kiến trúc Silverlight WebUI đã xây dựng như Hình 5 Đây là kiến trúc của mô hình của Microsoft Silverlight được sử dụng để đọc một cấu trúc tài liệu giao diện XAML làm đầu vào

hệ thống

Hình 5 Kiến trúc mô hình Silverlight WebUI Kiến trúc mô hình Android FUI của Android 4.2

Khảo sát đặc điểm Control trên giao diện của Android

Theo khảo sát thực tế, tính đến thờ điểm tháng 8 năm 2013, Android version 4.2 hỗ trợ 84 control Trong

đó có các control trùng lắp về mặt thể hiện, ví dụ: Password và PasswordNumber trên Android Như vậy đối với những nhóm control dạng này sẽ được gom nhóm lại

Bên cạnh đó, do số lượng control rất nhiều và có những control chỉ mang tính chất đặc thù của riêng Android như FrameLayout Những dạng control này là hoàn toàn không thể nào chuyển đổi được Do vậy, trong

luận văn này, chúng tôi chỉ thực hiện chuyển đổi các control sau: TextView, EditText, Button, CheckBox, RadioButton, ToggleButton, Switch, ProgressBar, Slider, RatingBar, DropDown, DatePicker, TimePicker, ListView, ImageView, ScrollView, LinearLayout, RelativeLayout, TableLayout

Kiến trúc Android FUI

Kiến trúc của Android FUI được thể hiện như ở Hình 6 Theo kiến trúc này, chúng tôi đã xác định các thành phần có thể chuyển đổi

ISBN: 978-604-82-1375-6 16

Hình 6 Kiến trúc mô hình Android FUI

Với kiến trúc mô hình Android FUI này, chúng tôi đã xây dựng được các cấu trúc phát sinh mã nguồn XML giao diện của nền tảng Android Nhưng tùy thuộc vào từng version của Android nên những tập luật và cú pháp này có thể thay đổi Do vậy, để sử dụng cho một version khác của nền tảng Android, cần phải xây dựng lại

bộ cấu trúc phát sinh mã Và để đảm bảo cú pháp phát sinh mã Android XML đúng với kết quả hiển thị, chúng tôi xây dựng bộ cú pháp kiểm tra XSD Ứng với từng control sẽ có một file XSD để kiểm tra và làm mẫu phát sinh tag xml cho giao diện Android tương ứng

Hình 7 là cấu trúc XSD để phát sinh tag Android XML của control Button trên Android FUI Dựa vào XSD này, hệ thống sẽ phát sinh ra code Android XML tương ứng, đảm bảo tính đúng đắn về mặt cú pháp của Android XML

Hình 7 Cấu trúc XSD của control Button trên Android FUI

Mô hình CUI trung gian của giải pháp TranUI

Trong quy trình TranUI, phần quan trọng nhất là CUI Model Đây là mô hình quyết định thiết kế và các thành phần trên giao diện Web của nền tảng RIA được giữ và sẽ được chuyển đổi sang các nền tảng trên thiết bị

di động Đây là một mô hình trung gian để quyết định các thông số của các thành phần giao diện được nạp vào

hệ thống từ WebUI có thể chuyển đổi được qua được FUI của các nền tảng di động tương ứng

Báo cáo toàn văn Kỷ yếu hội nghị khoa học lần IX Trường Đại học Khoa học Tự nhiên, ĐHQG-HCM

Hình 8 Kiến trúc CUI của giải pháp TranUI

Để định nghĩa cho các thành phần của CUI, nhóm tác giả đề xuất cấu trúc thiết kế của CUI (Hình 8) Trên

mô hình này, chúng tôi chia thành 2 phần chính:

ComponentUI: ở phần này sẽ chứa các thành phần giao diện có tính chất chứa đựng các thành phần giao

diện Để thực hiện xây dựng kiến trúc của phần này, chúng tôi đề xuất sử dụng mẫu Composite trong Design Pattern Để phân tiện lợi cho quá trình phát triển và tái sử dụng về sau, chúng tôi đã đề xuất kiến trúc này tách thành 2 phần khác nhau:

LayoutCUI: đây là nhóm các thành phần hỗ trợ Layout (chia vùng) cho các thành phần giao diện Theo

khảo sát các mô hình Layout của các ứng dụng như Adobe Flash/Flex, Microsoft Silverlight, JavaFX, Android, iOS, Windows Phone thì có 3 loại layout đặc trưng là: Linear Layout, Relative Layout và Grid Layout Trong

mô hình CUI đề xuất, chúng tôi đã mô hình 3 loại layout này thành 3 thành phần của giao diện là: LinearLayoutCUI, RelativeLayoutCUI, GridLayoutCUI

ContainerCUI: là nhóm các control: ComboBoxCUI, ListBoxCUI và ScrollViewCUI Đây là các control

có tính chất bao bọc/chứa các thành phần giao diện khác bên trong

SingleUI: qui định cấu trúc của các thành phần giao diện (control) đơn, không mang tính chất bao bọc như:

TextBoxCUI, TextViewCUI, ImageViewCUI, ProgressBarCUI, CheckBoxCUI, RadioButtionCUI, DatePickerCUI, TimePickerCUI, SliderCUI, ButtonCUI

Thành phần thuộc tính – Attribute: thành phần này là tổng hợp các thuộc tính có thể có của các thành phần giao diện (control) hiện tại Thành phần này sẽ được định nghĩa từ các file XSD Mỗi file XSD sẽ đặc tả cho một control có cấu trúc tương tự như (Hình 9)

Hình 9 Đặc tả cấu trúc XSD lưu trữ thông tin của Control Button trong CUI Tập luật chuyển đổi WebUI2CUI và CUI2FUI

Để có thể thực hiện việc chuyển đổi giữa các mô hình, chúng tôi đề xuất kiến trúc quản lý các tập luật chuyển đổi Các tập luật này sẽ được bổ sung và tùy biến tùy thuộc vào mục tiêu chuyển của người dùng sử dụng

áp dụng quy trình và mô hình này cho các nền tảng cụ thể

ISBN: 978-604-82-1375-6 18

Hình 10 Kiến trúc mô hình chuyển đổi WebUI2CUI

Hình 10là kiến trúc của mô hình chuyển đổi WebUI2CUI và (Hình 11) là kiến trúc của mô hình chuyển đổi CUI2FUI Hai kiến trúc chuyển đổi mô hình này giống nhau Chỉ khác nhau ở phần quản lý tập luật (Rule Management) và các luật chuyển đổi (Rule) Các thành phần trong mô hình này gồm:

Hình 11 Kiến trúc mô hình chuyển đổi CUI2FUI

Để thực hiện lưu trữ các luật chuyển đổi linh động và dễ dàng cập nhật hay bổ sung trong quá trình hệ thống hoạt động, chúng tôi đề xuất phương pháp lưu trữ thành các file định dạng xml.Hình 12 là một ví dụ về việc lưu trữ bộ luật chuyển đổi một control/thành phần giao diện CheckBox từ CUI sang FUI trên nền tảng Android Các tag <Mapping> sẽ qui định việc ánh xạ tên của từng thuộc tính của CUI sang FUI sẽ được chuyển đổi như thế nào

Báo cáo toàn văn Kỷ yếu hội nghị khoa học lần IX Trường Đại học Khoa học Tự nhiên, ĐHQG-HCM

Hình 12 Ví dụ về lữu luật chuyển đổi từ CUI sang FUI trên Android

Qua quá trình nghiên cứu chuyển đổi, nhóm tác giả đã thực hiện chuyển đổi được 15 thành phần giao diện (Control) được thể hiện qua Bảng 2

Bảng 2 Bảng chuyển đổi control giữa các mô hình Microsoft Silverlight WebUI, CUI, Android FUI

Thực nghiệm

Để thực nghiệm hệ thống chuyển đổi bán tự động này, nhóm nghiên cứu đã thực hiện qua phương pháp Case-Study với 2 ứng dụng chuyển đổi chính là màng hình chính của ứng dụng Skype và màng hình Login của ứng dụng FaceBook

Ứng dụng Skype chat

Hình 13 là ứng dụng thực hiện việc chuyển đổi giao diên trên khung chat của Skype (được mô phỏng lại theo nền web của Skype) trên Microsoft Silverlight 5.0 và đang triển khai lên trình duyệt IE