Năm 1996, quy trình phát triển MBUID tổng quát được đề nghị [13], trong đó các mô hình mô tả giao diện của hệ thống được chia thành ba mức trừu tượng và lần lượt được phát triển theo trình tự: Task/Domain, AUI, và CUI (Hình 2.15). Quá trình chuyển đổi giữa các mô hình Task/Domain, AUI, và CUI có thể được thực hiện tự động với sự trợ giúp của các công cụ thiết kế.
Hình 2.15 Model – based User Interface Development Process [13]
Ưu điểm của quy trình này là trì hoãn sự phụ thuộc kết quả phân tích thiết kế giao diện vào môi trường phát triển, do đó nâng cao tính sử dụng lại của các kết quả phân tích thiết kế. Nhưng hạn chế của quy trình này là việc cài đặt mã nguồn vẫn phải làm bằng tay và hiện lúc đó chưa có các công cụ hỗ trợ phát sinh mã nguồn tự động cho quy trình này.
b)Quy trình phát triển của CAMELEON Framework
Sau khi quy trình tổng quát MBUID được đề nghị, đã có nhiều nhóm nghiên cứu hiện thực hóa quy trình này. Nổi bật là quy trình của CAMELEON Framework (Hình 2.16) được đề nghị năm 2001 [3], [18]. Mục tiêu chính của CAMELEON Framework là phát triển phương pháp luận hỗ trợ cho các hệ thống giao tiếp cảm ngữ cảnh (tùy thuộc vào giao tiếp của người sử dụng như giọng nói, bàn phím, bút cảm ứng mà hệ thống cung cấp đối tượng giao tiếp tương ứng).
Hình 2.16 Cameleon Unifying Reference Framework cho Multi –Target User Interface [3]
Ưu điểm của quy trình này hiện thực hóa quy trình tổng quát đồng thời cung cấp môi trường hỗ trợ phát triển hệ thống giao diện. Quy trình này còn sử dụng trong nhánh nghiên cứu Multi-Target User Interface và Plastic User Interface cũng là để giải quyết bài toán phát triển cùng một giao diện trên nhiều platform mà luận văn quan tâm.
Tuy nhiên quy trình này được hiện thực hóa để xây dựng các hệ thống giao diện cảm ngữ cảnh mà không được chú trọng nhiều đến việc phát triển giao diện. Hơn nữa việc tạo ra những Ontological model (bao gồm các loại mô hình mô tả UI theo chức năng (2.2.1.b)) phủ hết các platform là rất khó khăn và làm cho chúng thêm cồng kềnh.
c)Quy trình phát triển của TERESA XML
Năm 2005, TERESA XML [1] sử dụng lại quy trình trong CAMELEON Framework với một vài bổ sung và sửa đổi, TERESA XML được xây dựng để làm môi trường phát triển giao diện trên desktop, các thiết bị di động ngoài ra còn phát
triển ứng dụng giao diện hỗ trợ giọng nói. Tuy nhiên hiện nay TERESA XML chỉ hỗ trợ phát sinh ra mã nguồn của các ngôn ngữ: XHTML, VoiceXML, X+V, SVG, Xlet. Với TERESA XML, ta hoàn toàn chưa thế phát triển ứng dụng dạng form trên các loại thiết bị di động. Do đó việc phát triển ứng dụng với TERESA XML là những ứng dụng web, giọng nói đơn giản, các đối tượng thể hiện giao diện đơn giản. Ngoài ra TERESA vẫn chưa khắc phục được nhược điểm của CAMELEON Framework. Trong TERESA XML, mô hình Task vẫn cồng kềnh và phủ hết các platform quan tâm. Nói cách khác việc phát triển ứng dụng với TERESA XML trong MUID còn hạn chế. Theo chúng tôi, TERESA XML chỉ có ý nghĩa trong những thí nghiệm, nghiên cứu. Còn việc áp dụng rộng rãi để phát triển các ứng dụng trong bài toán giao diện mà ta quan tâm thì chưa thể được.
d)Quy trình phát triển của UsiXML
UsiXML [4] được đề xuất 2005, cũng sử dụng lại quy trình trong CAMELEON Framework (Hình 2.17). UsiXML hỗ trợ phát sinh mã nguồn của các ngôn ngữ: HTML, Java, C++. Nhóm tác giả UsiXML cũng cung cấp nhiều công cụ cho phép phát triển phần mềm theo MUI và các hướng khác (Hình 2.18). Có thể nói UsiXML là ngôn ngữ mạnh và cung cấp bộ công cụ mạnh để phát triển MUI hiện nay. Tuy nhiên hiện vẫn chưa có nhiều tài liệu tham khảo, các công cụ chỉ công bố một phần hoặc công bố trong nhóm nghiên cứu (Bảng 2.2). Với việc hỗ trợ phát sinh mã nguồn cho các ngôn ngữ đích như vậy thì vẫn chưa đáp ứng được mục tiêu chính của MUID.
Hình 2.17 Quy trình trong UsiXML [4]
Hình 2.18 Các công cụ hỗ trợ trong quy trình UsiXML [4]
Bảng 2.2 Các công cụ đƣợc đề nghị trong UsiXML
STT Công cụ Nội dung hỗ trợ Ghi chú
1. Ideal XML Task & AUI Model Công bố chương trình không công bố source code
2. TransformiXML Chuyển đổi giữa các mô hình Không công bố chương trình và source code
3. KnowiXML AUI Model Công bố chương trình không công bố source code
4. FlashiXML Chuyển đổi mô hình Không công bố chương trình và source code
5. QtkXML Chuyển đổi mô hình Công bố chương trình và source code
6. GrafiXML CUI Model và chuyển đổi mô hình
Công bố chương trình và source code
7. InterpiXML Chuyển đổi mô hình Công bố chương trình và source code
8. VisualiXML Chuyển đổi mô hình Không công bố chương trình và source code
9. VisiXML CUI Model Là Visio của Microsoft
10. SketchiXML CUI Model Công bố chương trình không công bố source code
11. FormiXML CUI Model Không thấy đề cập trên website
12. PlastiXML CUI Model Không thấy công bố và source code
13. ComposiXML CUI Model Công bố chương trình và source code
14. ReversiXML Chuyển đổi mô hình Không công bố source code và chương trình
e)Quy trình phát triển của MANTRA
Năm 2006, cách tiếp cận MANTRA – Model-based engineering of multiple interfaces with transformations [16] đề xuất thêm mô hình là AAUI – Adapted AUI. Đây là mô hình trung gian giữa AUI và CUI (Hình 2.19). Theo tác giả của phương pháp này, về mặt cấu trúc và ngữ nghĩa thì AAUI vẫn là mô hình độc lập platform, tuy nhiên AAUI được tinh chỉnh cho phù hợp với những giới hạn và ràng buộc về mặt thể hiện giao diện trên platform.
Tuy hiện chỉ có một ví dụ trong báo cáo của tác giả minh họa hướng tiếp cận MANTRA, việc xây dựng môi trường, công cụ hỗ trợ phát triển MUID theo hướng tiếp cận này vẫn chưa phát triển đầy đủ.
f) Nhận xét
Năm 1996, quy trình tổng quát trong MBUID được đề nghị gồm một bộ các mô hình (Task, AUI, CUI) các mô hình này được chuyển đổi một cách tự động, còn FUI thì phải thực hiện bằng tay (Hình 2.20). Tuy nhiên quy trình này chưa được hiện thực hóa, chưa có công cụ hỗ trợ.
Hình 2.20 Các mô hình trong quy trình tổng quát
Năm 2001, dựa trên quy trình tổng quát CAMELEON Framework đề nghị gồm một bộ các mô hình (Task, AUI, CUI, FUI)i, với i tập platform quan tâm (Hình 2.21). Khác với quy trình tổng quát, trong quy trình này FUI cũng được chuyển đổi tự động. Ngoài ra CAMELEON Framework cũng cung cấp các công cụ hỗ trợ giúp hiện thực hóa quy trình. Tuy nhiên quy trình này lại đi nhiều theo hướng phát triển cảm ngữ cảnh không chú trọng đến việc phát triển giao diện. Mặt khác nếu sử dụng quy trình này thì ngay từ bước đầu, các mô hình đã phải phủ hết tất cả các platform quan tâm, gây cồng kềnh, nặng nề ngay từ bước đầu.
Hình 2.21 Các mô hình trong quy trình CAMELEON Framework
Đến năm 2005, TERESA XML và UsiXML đã sử dụng lại quy trình trong CAMELEON Framework. Nhưng điểm khác so với quy trình cũ là chỉ có mô hình Task ở bước đầu là phủ hết tất cả các platform quan tâm (Hình 2.22). Hơn nữa việc hỗ trợ các platform cũng rất hạn chế. Về giao diện, TERESA XML minh họa phát triển những giao diện web đơn giản trên thiết bị di động. Còn UsiXML hỗ trợ giao diện cho nhiều platform nhưng các công cụ chưa đầy đủ, công bố hoặc công bố một phần.
Hình 2.22 Các mô hình trong quy trình của TERESA XML và UsiXML
Năm 2006, MANTRA cũng sử dụng lại quy trình CAMELEON Framework nhưng đề nghị thêm một mô hình trung gian giữa AUI và CUI là AAUI (Hình
2.23). Mô hình trung gian này làm cho mô hình Task và AUI đạt mức độ trừu tượng cao, giảm đi việc phải phủ hết các platform quan tâm ở bước đầu rất nhiều. Tuy nhiên MANTRA dừng ở mức đề nghị và minh họa trong một ứng dụng cụ thể, chưa hỗ trợ hết công cụ phát triển theo lý thuyết này.
Hình 2.23 Các mô hình trong quy trình của MANTRA
Bảng 2.3 Tóm tắt các quy trình phát triển MBUID
STT Quy trình Công cụ Ghi chú
1. Tổng quát N/A Chưa có chỉ dẫn cụ thể
2. CAMELEON Framework
Hỗ trợ các platform cho ứng dụng giao diện cảm ngữ cảnh.
Ở bước đầu, mô hình Task và các mô hình khác phải phủ hết các platform quan. Nghĩa là phụ thuộc vào platform ở ngay bước đầu tiên trong quy trình.
3. TERESA XML
Hỗ trợ các ngôn ngữ XHTML, VoiceXML, X+V, SVG, Xlet
Sử dụng lại quy trình trong CAMELEON Framework. Chỉ có mô hình Task phải phủ hết các platform quan tâm.
4. UsiXML Theo lý thuyết hỗ trợ các ngôn ngữ HTML, Java, C++ nhưng các công cụ chưa công bố đầy đủ
Sử dụng lại quy trình trong CAMELEON Framework. Chỉ có mô hình Task phải phủ hết các platform quan tâm.
5. MANTRA Theo lý thuyết hỗ trợ mã nguồn C#, VB.NET, ASP.NET nhưng chưa công bố công cụ
Sử dụng lại quy trình CAMELEON Framework nhưng đề xuất thêm AAUI. Ở mức Task, AUI, AAUI vẫn giữ được mức phân tích, thiết kế độc lập với platform, chỉ có mức CUI và FUI là phải phụ thuộc vào platform.
Các quy trình đã đề cập có thể được tóm tắt ở (Bảng 2.3). Như vậy chỉ có quy trình mà MANTRA đề nghị có khả năng trì hoãn được bước phân tích, thiết kế phụ thuộc vào platform cao hơn các quy trình còn lại.
2.2.3.Định nghĩa và chuyển đổi mô hình trong MBUID
Trong phần trước, chúng tôi đã trình bày các quy trình trong MBUID và trong các quy trình này sử dụng các loại model trong các bước đó là task, AUI, CUI, FUI. Trong phần này chúng tôi sẽ trình bày các kết quả nghiên cứu về các metamodel của task, AUI, CUI để định nghĩa các model tương ứng. Còn với FUI là mã nguồn code nên ta sẽ không quan tâm.
a)Task metamodel
Trong các quy trình MBUID, để mô tả giao tiếp của người dùng với hệ thống, người ta sử dụng task model. Ngoài ra task model còn phục vụ cho nhiều nhánh nghiên cứu khác với nhiều mục đích khác nhau, có riêng một nhánh nghiên cứu là Task-Based Application chuyên nghiên cứu về task model. Trong nhánh này, người ta nghiên cứu task model với nhiều mục đích khác nhau trong ngữ cảnh phát triển các loại ứng dụng khác nhau. Một số loại task model trong lĩnh vực Task-Based Application được khảo sát [19] là: AMBOSS, ANSI/CESA, CTT, Diane+, GOMS, GTA, HTA, TKS, TOOD, UsiXML, Relevance. Có nhiều loại task model nhưng trong hướng tiếp cận MBUID, người ta sử dụng CTT [11] task model, điển hình là các bài viết trong Workshop MDDAUI từ năm 2005 đến nay đều đề cập và sử dụng CTT task model. Ngoài ra trong các bài viết của hội nghị TAMODIA từ năm 2006, bài nào có nhắc đến task model đều có tham chiếu hoặc sử dụng CTT task model. (Hình 2.24) là một ví dụ task model cho ứng dụng soạn thảo văn bản.
Hình 2.24 CTT Task model cho ứng dụng soạn thảo văn bản
CTT – ConcurTaskTree [11] task model được biểu diễn dưới dạng các task và các mối quan hệ giữa chúng. Trong CTT task model các ký hiệu về các loại task được trình bày ở (Hình 2.25) , còn các mối quan hệ giữa các task được thể hiện bằng đường nối 2 đầu task với nhau.
Hình 2.25 Ký hiệu các loại task trong CTT task model [11]
Có 4 loại task là: user task, abstraction task, application task, và interaction task. User task mô tả tác vụ nội tại của người dùng. Abstraction task là tác vụ trừu tượng có thể phân rã thành các loại task khác. Application task là một đơn vị tác vụ phải thực hiện trong hệ thống, ví dụ tính toán hoặc kết xuất. Interaction task là tác vụ giao tiếp giữa người dùng với hệ thống. Trong ngữ cảnh xây dựng giao diện user
task thường không được sử dụng trong task model. Cũng trong ngữ cảnh này, về sau application task sẽ được hiện thực hóa thành một màn hình hoặc một group các đơn vị thể hiện giao diện trên mành hình hay gọi chung là một đơn vị output; còn interaction task sẽ được hiện thực hóa thành một đơn vị input/output hoặc là command trên màn hình giao diện. Trong CTT task model, có nhiều mối quan hệ giữa các loại task, mỗi mối quan hệ diễn tả một thứ tự thực hiện giữa các task. Các mối quan hệ này được tóm tắt ở bảng sau (Bảng 2.4)
Bảng 2.4 Mối quan hệ giữa các task trong task model STT Loại quan hệ Ký hiệu Ý nghĩa
1. Choice T1 [] T2 Chọn thực hiện T1, T2 không kể thứ tự
2. Order Independence T1 |=| T2 T1 phải kết thúc trước rồi T2 mới được thực hiện
3. Independent Concurrency
T1 ||| T2 T1 và T2 được thực hiện đồng thời, không có ràng buộc điều kiện giữa T1 và T2
4. Concurrent with information exchange
T1 |[]| T2 T1 và T2 được thực hiện đồng thời nhưng giữa T1 và T2 có sự đồng bộ hóa. Việc T1 thay đổi thông tin sẽ làm T2 thay đổi thông tin và ngược lại
5. Disabling T1 [> T2 Khi T2 thực hiện, T1 sẽ được kết thúc
6. Suspend/Resume T1 |> T2 Trong lúc T1 đang thực hiện, nếu T2 thực hiện thì tạm dừng T1 và khi T2 kết thúc thì T1 tiếp tục thực hiện.
7. Enabling T1 >> T2 Thực hiện tuần tự, T1 kết thúc rồi T2 mới bắt đầu
8. Enabling with informtion passing
T1 []>> T2
Thực hiện tuần tự, T1 kết thúc rồi T2 mới bắt đầu. T1 chuyển một số thông tin cho T2
9. Interaction T* T có thể được lặp lại nhiều lần
10. Optional task [T] T có thể được hoặc không được thực hiện
Nhờ vào các loại task trong CTT task model mà từ task model ta có thể phát sinh ra các mô hình mô tả giao diện khác thể hiện rõ các đối tượng giao diện input, output, command tương ứng. Nhờ vào mối quan hệ giữa các loại task mà ta biết được thứ tự thực hiện các tác vụ cũng như thứ tự thực hiện các thao tác trên màn hình khi task model được hiện thực hóa.
Để hình thức hóa định nghĩa task model và để cung cấp ngữ pháp cho quá trình chuyển đổi mô hình từ task model sang các model loại khác người ta định nghĩa task metamodel. Vì CTT task model được áp dụng không chỉ trong MBUID mà còn được áp dụng trong nhiều nhánh nghiên cứu khác nên cũng có nhiều loại CTT task metamodel quy định cú pháp của CTT task model để phù hợp với lĩnh vực bài toán giải quyết. Hiện chưa có một chuẩn riêng cho CTT task metamodel trong MBUID.
(Hình 2.26) là task metamodel trong công cụ CTTE – CTTEnvironment, phục vụ cho nhiều nhánh nghiên cứu trong hướng nghiên cứu UID.
Hình 2.26 CTT task model trong công cụ CTTE – ConcurTaskTreeEnvironment [19]
Còn (Hình 2.27) là hai một CTT task metamodel cho Ubiquitous UI được nhắc đến trong[20]. Nhưng dù thế nào các CTT task metamodel này vẫn có điểm chung là phải có những khái niệm cơ bản như: các loại task và các loại quan hệ giữa các task.
Hình 2.27 Một dạng khác của CTT task metamodel cho Ubiquitous UI [20]
b)AUI metamodel
Khi đã có task model, trong các quy trình MBUID sẽ sử dụng task model và task metamodel để phát sinh ra AUI model chứa các đối tượng giao diện độc lập với platform. Cũng giống như task model, người ta cũng cần định nghĩa AUI metamodel làm cú pháp choa AUI model và hiện cũng chưa có một chuẩn cho AUI model và AUI metamodel. Tuy nhiên trong các AUI model và AUI metamodel có các khái niệm chung là: input, output và command.
(Hình 2.28) là AUI metamodel của TERESA XML [1], metamodel này được định nghĩa dựa trên ngôn ngữ DTD. Tuy nhiên ta nhận thấy các khái niệm elementary interactor trong mô hình này thật sự không hoàn toàn độc lập với platform vì các khái niệm numerical edit, position edit, v.v… là cụ thể đối với một platform.
Hình 2.28 AUI metamodel trong TERESA XML [1]
(Hình 2.29) thể hiện AUI metamodel trong UsiXML, khác với AUI metamodel trong TERESA XML, metamodel này trừu tượng hơn, độc lập với các platform. Ngoài ra AUI metamodel trong UsiXML còn có khái niệm spatioTemporal cho
phép định nghĩa quan hệ vị trí, thực hiện của các đối tượng giao diện trên màn hình.