NGHIÊN cứu GIẢI PHÁP SINH mã GIAO DIỆN NGƯỜI DÙNG từ sơ đồ lớp CHO các ỨNG DỤNG QUẢN lý

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (11.57 MB, 87 trang )

TRƯỜNG ĐẠI HỌC QUỐC GIA TP HCM

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
----------  ----------

NGHIÊN CỨU GIẢI PHÁP SINH MÃ GIAO DIỆN
NGƯỜI DÙNG TỪ SƠ ĐỒ LỚP CHO
CÁC ỨNG DỤNG QUẢN LÝ

LUẬN VĂN THẠC SĨ
Chuyên ngành: KHOA HỌC MÁY TÍNH
Mã số: 60480101

Người hướng dẫn: PGS.TS. VŨ THANH NGUYÊN

TP Hồ Chí Minh, Năm 2017

LỜI CẢM ƠN

Tôi xin chân thành cảm ơn Thầy PGS. TS. VŨ THANH NGUYÊN – Giảng viên
trường Đại Học Công Nghệ Thông Tin đã luôn quan tâm, tận tình hướng dẫn và có
những nhận xét, góp ý quí báu giúp tôi trong suốt thời gian nghiên cứu và thực hiện
đề tài.
Tôi cũng xin gửi lời cám quý Thầy Cô trường Đại Học Công Nghệ Thông Tin đã tận
tình giảng dạy, trang bị cho tôi những kiến thức nền quí báu trong những năm học
vừa qua.
Tôi xin gửi lòng biết ơn sâu sắc đến Ba Mẹ, các anh chị và bạn bè đã ủng hộ, giúp đỡ
và động viên tôi trong những lúc khó khăn cũng như trong suốt thời gian học tập và
nghiên cứu.
Tp.Hồ Chí Minh, tháng 10 năm 2017

Học viên

Trần Thị Anh Thi

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 qua sự
hướng dẫn của PGS.TS VŨ THANH NGUYÊN – Giảng viên trường Đại Học Công
Nghệ Thông Tin.
Các nội dung nghiên cứu và kết quả đạt được trình bày trong luận văn là hoàn toàn
trung thực, do tôi tổng hợp, đúc kết bổ sung và biên soạn theo sự hiểu biết của mình
thông qua nghiên cứu từ các tài liệu tham khảo: Sách, báo cáo khoa học và các tài
liệu được công bố trên website.

Tp.Hồ Chí Minh, tháng 10 năm 2017
Học viên

Trần Thị Anh Thi

MỤC LỤC
DANH MỤC CÁC KÝ HIỆU VÀ CÁC TỪ VIẾT TẮT ......................................... 1
DANH SÁCH CÁC BẢNG ..................................................................................... 2
DANH SÁCH CÁC HÌNH VẼ VÀ ĐỒ THỊ ........................................................... 3
CHƯƠNG 1.

TỔNG QUAN .......................................................................... 5

1.1.

Dẫn nhập .............................................................................................. 5

1.2.

Bài toán phát sinh mã trong công nghệ phần mềm ................................ 6

1.3.

Tổng quan tình hình nghiên cứu ........................................................... 7

1.3.1.

Tình hình nghiên cứu ở nước ngoài .............................................. 7

1.3.2.

Tình hình nghiên cứu ở Việt Nam ................................................ 7

1.4.

Mục tiêu nghiên cứu............................................................................. 8

1.4.1.

Mục tiêu nghiên cứu ..................................................................... 8

1.4.2.

Giới hạn cho đề tài ....................................................................... 8

1.4.3.

Phát họa cho luận văn ................................................................... 9

1.4.4.

Kết quả nghiên cứu dự kiến .......................................................... 9

CHƯƠNG 2.
2.1.

CƠ SỞ LÝ THUYẾT VÀ HƯỚNG TIẾP CẬN ..................... 11

Mô hình MDD (Model-Driven Development) .................................... 11

2.1.1.

Mô hình MDA (Model-Driven Architecture)[10] ....................... 11

2.1.2.

Tư tưởng tiếp cận theo mô hình MDA [1][2][10] ....................... 12

2.1.2.1. Các chuẩn liên quan mô hình MDD ........................................ 15
2.1.2.2. Một số cách tiếp cận chuyền đổi từ mô hình sang mô
hình[1][2][3] .......................................................................................... 17
2.1.3.
2.2.

Mô hình đề xuất cho luận văn ..................................................... 18

Sơ lược về ngôn ngữ mô hình hóa UML ............................................ 19

2.2.1.

Ngôn ngữ UML .......................................................................... 19

2.2.2.

Sơ lược về XML (eXtensible Markup Language) ....................... 25

2.2.2.1. Cấu trúc của một tập tin XML ................................................ 26
2.2.2.2. Tính well-formed và valid của tài liệu XML ........................... 26
2.2.2.3. XML nameSpace .................................................................... 27
2.2.2.4. XML Xpath Language [17] .................................................... 28
2.2.3.

XMI (XML Metadata Interchage) ............................................... 28

2.3.

Phân tích tài liệu XML ....................................................................... 29

2.3.1.

SAX (Simple API for XML) ........................................................ 30

2.3.2.

DOM (Document Object Model) ................................................ 31

2.3.3.

Các thành phần chính của một tài liệu XMI ................................ 31

2.3.3.1. PackagedElement ................................................................... 32
2.3.3.2. Generalization ........................................................................ 32
2.3.3.3. Attribute ................................................................................. 33
2.3.3.4. Association ............................................................................. 34
2.3.3.5. Enumerration .......................................................................... 37
2.3.4.

Phân tích tài liệu XMI ................................................................ 38

CHƯƠNG 3.

MỘT GIẢI PHÁP SINH MÃ GIAO DIỆN NGƯỜI DÙNG TỪ

SƠ ĐỒ LỚP

39

3.1.

Kiến trúc của giải pháp....................................................................... 39

3.2.

Quy trình chuyển đổi của giải pháp .................................................... 40

3.3.

Mô hình đề xuất ................................................................................. 41

3.4.

Thuật toán .......................................................................................... 42

3.4.1.

Giải thuật phân tích tài liệu XMI ................................................ 42

3.4.2.

Giải thuật sinh mã giao diện người dùng .................................... 42

3.5.

Thực nghiệm ...................................................................................... 43

3.5.1.

Xây dựng sơ đồ lớp (class Diagram) ........................................... 43

3.5.1.1. Papyrus plugin ........................................................................ 43
3.5.1.2. Một số yêu cầu khi xây dựng class diagram ............................ 45
3.5.2.

Chuyển sơ đồ lớp sang tài liệu XMI ........................................... 49

3.5.3.

Thực hiện phân tích tài liệu XMI ................................................ 49

3.5.4.

Thực hiện sinh mã giao diện người dùng trên nền Java ............... 49

3.5.5.

Một số kết quả được sinh từ công cụ thực nghiệm ...................... 50

3.5.5.1. Giao diện đơn ......................................................................... 51
3.5.5.2. Giao diện loại Master/Detail ................................................... 54
3.5.5.3. Giao diện loại kế thừa/ đa hình ............................................... 56
3.5.6.
CHƯƠNG 4.

Đánh giá hiệu quả sinh mã giao diện .......................................... 57
KẾT LUẬN VÀ KHUYẾN NGHỊ ......................................... 59

4.1.

Kết quả đạt được ................................................................................ 59

4.2.

Hạn chế và hướng phát triển ............................................................... 59

TÀI LIỆU THAM KHẢO ..................................................................................... 61
PHỤ LỤC

............................................................................................... 63

Bảng khảo sát người dùng ..................................................................................... 63
Bài báo (thông báo đăng bài) ................................................................................. 65
Nội dung bài báo

............................................................................................... 66

DANH MỤC CÁC KÝ HIỆU VÀ CÁC TỪ VIẾT TẮT

API

Application Proframming Interface

CIM
DSL

Computation Independent Model
Domain-Specific Language

DSM
MDA

Domain-Specific Metamodel
Model-Driven Architecture

MDD

Model-Driven Development

MDE

Model-Driven Engineering

MDSD

Model-Driven Software Development

MOF

Meta-Object Facility

MVC
OCL

Model-View-Controler
Object Condtrain Language

OMG

Object Management Group

PIM

Platform-Independent Model

PSM
UI
UML

Platform Specified Model
User Interface
Unified Modeling Language

XMI

XML Metadata Interchange

XML

eXtensible Markup Language

GUI

Graphics User Interface

MIC

Model Intergrated Computing

DTD
DOM
SAX

Document Type Definition

Document Object Mode
Simple API for XML

HVTH: Trần Thị Anh Thi - CH1502021

Trang 1

DANH SÁCH CÁC BẢNG

Bảng 2. 1: Các giá trị bội số và ý nghĩa [14]. ........................................................ 23
Bảng 3. 1: Bảng chuyển đổi 1.............................................................................. 46
Bảng 3. 2: Bảng chuyển đổi 2.............................................................................. 47

HVTH: Trần Thị Anh Thi - CH1502021

Trang 2

DANH SÁCH CÁC HÌNH VẼ VÀ ĐỒ THỊ
Hình 2. 1: Kiến trúc Metadata MOF [16] ............................................................. 13
Hình 2. 2: Ba loại mô hình phụ thuộc của MDA .................................................. 15
Hình 2. 3: Mô hình đề xuất cho bài toán phát sinh mã giao diện .......................... 19
Hình 2 4: Class Employee................................................................................... 23
Hình 2. 5: UML Class Diagram ........................................................................... 25
Hình 2. 6: Ví dụ một tài liệu XML [17] ............................................................... 27
Hình 2. 7: SAX Parser ......................................................................................... 30
Hình 2. 8: DOM Parser ........................................................................................ 31
Hình 2. 9: Biểu diễn XMI của một lớp (Class) ..................................................... 32
Hình 2. 10: Biểu diễn XML của thành phần Generalization ................................. 33

Hình 2. 11: Biểu diễn XML của một Attribute ..................................................... 34
Hình 2. 12: Biểu diễn XML của thành phần Association...................................... 36
Hình 2. 13: Biểu diễn XML của thành phần Enumeration .................................... 38
Hình 3. 1: Kiến trúc hướng mô hình MDA trong bài toán sinh mã giao diện......... 39
Hình 3. 2: Quy trình chuyển đổi mô hình theo kiến trúc MDA .............................. 40
Hình 3. 3: Mô hình phát sinh mã giao diện ........................................................... 41
Hình 3. 4: Class Diagram được thiết kế bằng Papyrus [25] ................................... 44
Hình 3. 5: Class Diagram được thiết kế bằng Papyrus .......................................... 45
Hình 3. 6: Biểu diễn Association với các lượng số ................................................ 47
Hình 3. 7: Biểu diễn mối liên kết Generalization .................................................. 48
Hình 3. 8: Phân tích file XMI lấy các element ...................................................... 49
Hình 3. 9: Cấu trúc lưu trữ file XMI được tổ chức bằng các HashMap ................. 49
Hình 3. 10: Một số template trong công cụ sinh mã giao diện ............................... 50
Hình 3. 11: MDI frame ......................................................................................... 51
Hình 3 12: Giao diện đơn - sinh từ class Address.................................................. 52
Hình 3. 13: Giao diện đơn sinh từ class Account.................................................. 53
Hình 3 .14: Giao diện Master/Detail sinh từ class Oder và Enum OderStatus....... 54
Hình 3. 15: Giao diện Master/Detail được sinh từ lớp Product và LineItem .......... 55
Hình 3 16: Giao diện được sinh theo mô hình cây thừa kế ................................... 56
HVTH: Trần Thị Anh Thi - CH1502021

Trang 3

Hình 3. 17: Bảng thông tin kết quả thử nghiệm ...................................................... 57
Hình 3 .18: Thống kê khảo sát gười dùng .............................................................. 58

HVTH: Trần Thị Anh Thi - CH1502021

Trang 4

CHƯƠNG 1.

TỔNG QUAN

1.1. Dẫn nhập
Với sự phát triển mạnh mẽ của ngành Công Nghệ Thông Tin đã tạo ra diện
mạo mới cho một xã hội hiện đại. Các sản phẩm Công Nghệ Thông Tin gần như đã
được ứng dụng vào tất cả lĩnh vực đời sống xã hội. Theo đó khái niệm Công Nghệ
Phần Mềm trở thành một phần không thể thiếu và tách rời khỏi Công Nghệ Thông
Tin.
Phần mềm được coi như sản phẩm của ngành công nghệ phần mềm được phát
triển theo quy trình đặc biệt theo các mô hình hiện đại.
Quy trình phát triển phần mềm bao gồm nhiều công đoạn như: nhận yêu cầu,
phân tích, thiết kế, xây dựng, kiểm tra, khai thác và bảo trì phần mềm. Theo đó, trong
một quy trình phát triển phần mềm thì giao diện người dùng đóng vai trò quan trọng
về mặt phi chức năng của các hệ thống phần mềm (cụ thể là tính thân thiện và tính
khả dụng) của phần mềm. Khi một hệ thống phần mềm đòi hỏi tính tương tác cao thì
công sức bỏ ra cho việc thiết kế và hiện thực giao diện người dùng chiếm một phần
không hề nhỏ cho chi phí của dự án phần mềm.
Đa số các môi trường phát triển ứng dụng như Visual Studio, Eclipse, NetBean
đều có các công cụ hỗ trợ cho việc soạn thảo giao diện người dùng trực quan. Nhưng
những công cụ này vẫn chưa có tính tự động hóa, người dùng vẫn phải thiết kế từng
thành phần trong giao diện cũng như gõ vào từng dòng lệnh hay lựa chọn các layout
thích hợp.
Trong quá trình tìm hiểu, tôi nhận thấy mô hình hóa có tầm quan trọng trong
hầu hết các ngành khoa học kỹ thuật. Người dùng khi muốn xây dựng vật thể nào đó
người ta đều cần tạo ra mô hình và phương thức hoạt động cho nó, để từ đó có cái
nhìn tổng quát, trực quan về những gì đã thiết kế. Tuy nhiên, các nghiên cứu về ngôn

ngữ mô hình chuyên biệt hóa lĩnh vực hẹp (Domain Specific Languages) trong công
nghệ phần mềm thường chỉ dừng ở mức mô hình hóa các khái niệm mà chưa chú ý
nhiều đến việc tự động hóa xây dựng giao diện người dùng.
Tự động hóa trong công đoạn xây dựng giao diện người dùng đã trở thành một
nhu cầu cần thiết, nó sẽ giúp giảm thời gian phát triển, giảm số lượng lỗi phát sinh,
HVTH: Trần Thị Anh Thi - CH1502021

Trang 5

dễ dàng nâng cấp cũng như cung cấp cho người phát triển phần mềm cái nhìn tổng
quan hơn về những gì mình sẽ thiết kế.

1.2. Bài toán phát sinh mã trong công nghệ phần mềm
Trong lịch sử công nghệ phần mềm, vấn đề tự động hóa trong quy trình phát
triễn phần mềm luôn được quan tâm. Những cách tiếp cận để tự động hóa như lập
trình logic (Prolog), lập trình đặc tả (ví dụ như Lisp, Alloy) cũng đã đem lại một số
kết quả về mặt lý thuyết nhưng tính hiệu quả và độ khả dụng còn nhiều hạn chế (chạy
chậm, không có tương tác người-máy).
Ngoài ra việc xây dựng các công cụ hỗ trợ giống như một phần mềm hỗ trợ
(engine) cho việc thiết kế giao diện, cấu trúc của ứng dụng trên web hay trên các thiết
bị điện tử cũng thu hút các nhà thiết kế phần mềm. Như công cụ thiết kế giao diện
trên web của nhóm E. Visser [13] hay công cụ thiết kế các giao diện trên các nền điện
thoại di động của T. Clark [6] cũng mang đến một số kết quả nhất định.
Tuy nhiên tính tự động hóa trong phần mềm ứng dụng lại chưa thực sự được
quan tâm đúng mức từ những người làm phần mềm hiện nay, cũng có thể việc tự
động hóa càng cao cũng sẽ dẫn đến phạm vi ứng dụng càng thu gọn lại.
Quy trình xây dựng phần mềm được xem là hiệu quả khi quy trình đó đảm bảo
phạm vi ứng dụng rộng rãi, thời gian phát triển ngắn cũng như tính tự động cao. Trên
thực tế, với sự xuất hiện ngôn ngữ lập trình và các công cụ ngày càng nhiều, cũng

như nhiều phương pháp luận chính quy và bán chính quy đã đem lại sự tự động hóa
mang tính cục bộ trong quy trình xây dựng phần mềm. Tuy nhiên, việc tự động hóa
cho toàn bộ quá trình này sẽ dẫn đến phạm vi ứng dụng bị giới hạn lại và đó cũng là
yếu tố làm cho lĩnh vực này còn bỏ ngỏ nhiều hướng nghiên cứu.
Trong bối cảnh đó, tôi xin chọn một hướng để tiếp cận và hiện thực một một
phần trong quy trình phát triển phần mềm mà tính tự động hóa được nâng lên cũng
như phạm vi áp dụng được cải thiện, cụ thể tôi chọn quy trình xây dựng các giao
diện đồ họa người dùng cho các ứng dụng quản lý từ mô hình thiết kế lớp của
UML (Unified Modeling Language) một cách tự động.

HVTH: Trần Thị Anh Thi - CH1502021

Trang 6

1.3. Tổng quan tình hình nghiên cứu
1.3.1. Tình hình nghiên cứu ở nước ngoài
Hiện nay ở nước ngoài có một số nhóm nghiên cứu việc chuyển đổi
giữa các mô hình thiết kế sang mã nguồn như:
Nhóm Bedekar [4] cho phép thiết kế các giao diện trên công cụ đặc tả
và chuyển đổi sang giao diện người dùng. Nhóm này đã xây dựng được công
cụ cho phép chuyển đổi một mô hình ở mức khái niệm (conceptual model)
sang mã nguồn và chạy trên máy tính.
Nhóm Clark [6] cũng có những ý tưởng cho phép xây dựng một
Domain-Specific Language – DSL [7] giúp cho các ứng dụng chạy được trên
nhiều framework khác nhau mà không cần phải biên dịch lại. Nhóm này cũng
cho phép phát sinh mã giao diện tự động tuy nhiên chỉ giới hạn lại là giao diện
Web chạy trên nền di động.

1.3.2. Tình hình nghiên cứu ở Việt Nam

Ở Việt Nam, hiện cũng có các nhóm nghiên cứu về vấn đề xây dựng công
cụ phát sinh mã nguồn tự động cho các phát triển ứng dụng có thể nhắc đến một
vài nhóm như:
Nhóm nghiên cứu tại trường Đại học Công Nghệ, đại học Quốc Gia Hà
Nội do TS. Đặng Đức Hạnh làm trưởng nhóm. Nhóm có một số công trình nghiên
cứu về mô hình hóa trong ngữ cảnh hẹp (Domain-Specific Modeling Language)
để chuyển đổi từ các mô hình sang một ngôn ngữ cụ thể[1] [5]. Nhóm đã đạt được
một số kết quả cụ thể như: Kiểm chứng được ràng buộc giữa các mô hình và ngôn
ngữ đặc tả, kiểm tra tính hợp lệ…
Tại Tp. Hồ Chí Minh nhóm nghiên cứu về xây dựng hệ thống giao diện
người dùng tự động trên điện thoại di động theo hướng tiếp cận mô hình cũng đạt
được một số thành công nhất định. Nhóm nghiên cứu tại trường Đại học Khoa học
tự nhiên TP.HCM dưới sự hướng dẫn của TS. Trần Hạnh Nhi [2], PGS. TS Trần
Minh Triết [3] các nhóm đã có một số kết quả nghiên cứu về việc chuyển đổi từ
mô hình thiết kế sang giao diện người dùng trên các nền tảng là các thiết bị di
HVTH: Trần Thị Anh Thi - CH1502021

Trang 7

động. Tại trường Đại học Bách Khoa Tp.HCM có nhóm của TS. Lê Lam Sơn cũng
nghiên cứu về phát sinh mã tự động từ các ngôn ngữ đặc tả như Alloy [12]. Kết
quả của các nhóm cũng đã cho phép chuyển đổi được các mô hình đặc tả sang
ngôn ngữ thực thi mà cụ thể là các giao diện người dùng trên các nền ứng dụng
thiết bị di động.
1.4. Mục tiêu nghiên cứu
Trong phần này 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 hạn của luận văn và những kết quả dự kiến của luận văn.
1.4.1. Mục tiêu nghiên cứu
Mục tiêu của đề tài là đề xuất và hiện thực một giải pháp cho phép phát

sinh giao diện người dùng cho các ứng dụng quản lý từ sơ đồ lớp. Điểm đặt
biệt của ứng dụng quản lý là có rất nhiều màn hình và các màn hình này phần
lớn có liên quan đến có thực thể (Entity trong sơ đồ lớp). Trong quá trình phát
triển phần mềm, đặt biệt là phần mềm quản lý, việc thiết kế giao diện người
dùng là việc mất nhiều thời gian, chi phí. Đối với những đối tượng vừa mới
làm quen việc viết phần mềm quản lý thì công việc này càng mất nhiều thời
gian hơn. Từ đó cho thấy cần có một công cụ hổ trợ nhằm giúp phát sinh giao
diện người dùng một cách nhanh chóng.
Hiện nay phương pháp luận phát sinh mã giao diện từ mô hình lớp trong
UML- Unified Modeling Language chưa có một qui chuẩn chung. Chính vì
vậy mà đề tài này 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 mô hình hóa kết hợp phân tích ngữ nghĩa của mô hình (dựa
vào các ràng buộc) để phát sinh mã cho giao diện người dùng một cách hợp
lý. Mô hình tôi đề xuất là mô hình lớp trong UML.
Tôi dự định sẽ phát sinh mã nguồn giao người dùng chạy trên ngôn ngữ
lập trình Java cho các ứng dụng quản lý vừa và nhỏ.
1.4.2. Giới hạn cho đề tài
Luận văn chỉ tập trung tìm hiểu và xây dựng công cụ phát sinh mã giao
diện đồ họa người dùng từ sơ đồ lớp cho các ứng dụng quản lý trên máy tính
cá nhân.
HVTH: Trần Thị Anh Thi - CH1502021

Trang 8

Giao diện người dùng sẽ chạy trên nền Java.
1.4.3. Phát họa cho luận văn
Tìm hiểu các mô hình chuyển đổi mã nguồn từ mô hình lớp. Từ đó, xây
dựng mô hình cho bài toán phát sinh mã giao diện người dùng từ đặc tả ban đầu
là mô hình lớp. Mô hình sẽ giải quyết được các vấn đề sau:

Bước 1: Nhận một sơ đồ lớp UML (class diagram) làm dữ liệu đầu vào.
Bước 2: Chuyển đổi mô hình lớp sang dạng tài liệu XMI [8] làm cơ sở
phát sinh mã giao diện.
Bước 3: Xây dựng bộ công cụ phân tích tài liệu XMI để lấy ra các thông
tin của sơ đồ như: tên các lớp, các quan hệ giữ các lớp, lượng số của các quan
hệ, tên thuộc tính, kiểu dữ liệu của thuộc tính…
Bước 4: Chuyển tài liệu XMI thành mã nguồn giao diện trên ngôn ngữ
Java dựa vào thông tin phân tích được từ tài liệu XMI. Đồng thời, dựa vào bảng
qui định các ràng buộc giữa bộ ánh xạ các thành phần trong XMI. Bảng qui định
này với các thành phần giao diện trong gói Swing của Java sẽ được luận văn đề
xuất.
Kết quả của luận văn là toàn bộ mã nguồn giao diện cho ứng dụng với
đặc tả là mô hình lớp. Mã nguồn sinh ra có thể sửa đổi, mở rộng một cách dễ
dàng. Giao diện người dùng cho các đối tượng trong mô hình lớp cũng đảm bảo
tính thân thiện người dùng, hợp lý trong thiết kế.

1.4.4. Kết quả nghiên cứu dự kiến
Xây dựng được mô hình phát sinh mã giao diện người dùng tự động từ
sơ đồ lớp.
Ứng dụng mô hình trên cho bài toán phát sinh mã giao diện trong các
ứng dụng quản lý với mã nguồn là Java.
Xây dựng được một công cụ nhằm hỗ trợ cho bài toán phát sinh mã trên
một cách hiệu quả và dễ dàng.
Kiểm chứng tính hợp lý, đúng đắn cho các giao diện phát sinh từ công
cụ trên nhằm đảm bảo tính ứng dụng của nghiên cứu trong luận văn.
HVTH: Trần Thị Anh Thi - CH1502021

Trang 9

HVTH: Trần Thị Anh Thi - CH1502021

Trang 10

CHƯƠNG 2.

CƠ SỞ LÝ THUYẾT VÀ HƯỚNG TIẾP CẬN

2.1. Mô hình MDD (Model-Driven Development)
MDD (Model-Driven Development) [1][2]: Đây là hướng tiếp cận xem việc
xây dựng chương trình là hoạt động chuyển đổi từ mô hình này sang mô hình khác
đang được nghiên cứu và phát triển từ những năm 2000.
Ở hướng tiếp cận hướng đối tượng thì tất cả đều quy về đối tượng. Trái lại, ở
hướng tiếp cận MDD thì tất cả đều quy về mô hình. Trước hết vì trong MDD tất cả
đều dựa trên mô hình nên trong phần này tôi sẽ trình bày các nội dung, các khái niệm
cơ bản về mô hình. Tiếp đến sẽ trình bày tư tưởng chính của hướng tiếp cập MDD để
có thể thấy được cách tiếp cận MDD có thể áp dụng vào bài toán mà mình quan tâm.
MDD ra đời với các mục tiêu giải quyết một số vấn đề:  




Mã nguồn được tự động sinh ra từ việc chuyển đổi mô hình, tính tự

động hoá càng cao đồng nghĩa với việc thời gian và hiệu suất được cải tiến.  




Chất lượng phần mềm được nâng cao khi các luật chuyển đổi được

định nghĩa.  




Không bị phụ thuộc vào việc thay đổi nền tảng (platform), khi phải

thay platform mới chỉ việc điều chỉnh các luật chuyển đổi và sự thay đổi sẽ tự động
được áp dụng.  




Khả năng tái sử dụng cũng được nâng cao, các mô hình, luật chuyển

đổi hoàn toàn có thể sử dụng cho những ứng dụng khác nhau do có sự tách biệt giữa
các thành phần liên quan.  

2.1.1. Mô hình MDA (Model-Driven Architecture)[10]
MDA là một hướng tiếp cận mới trong việc phát triển các hệ thống phần
mềm. Nó tách biệt sự đặc tả các chức năng hệ thống khỏi sự đặc tả việc hiện
thực các chức năng này trên một platform cụ thể, thông qua khái niệm mô
hình.
HVTH: Trần Thị Anh Thi - CH1502021

Trang 11

Hiện nay có nhiều tổ chức tham gia nghiên cứu và tham vọng thành lập
một chuẩn riêng, ví dụ như: Kiến trúc hướng mô hình (MDA) của tổ chức
OMG [10][15], MIC – Model Intergrated Computing của nhóm ISIS đại học
Vanderbilt, SF – Software Factories của công ty Microsoft1, và một số chuẩn
khác.
Trong các chuẩn kể trên, MDA [15] của OMG được công bố rộng rãi,
được quan tâm nghiên cứu nhiều. Hơn nữa còn được ứng dụng để tạo ra nhiều
công cụ hỗ trợ trong quá trình làm 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 mã nguồn được phát triển
mạnh trên môi trường Eclipse.
Theo tài liệu 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ó các khả năng:
i)

Xác định phần độc lập giữa hệ thống và nền tảng (platform);

ii)

Xác định phần phụ thuộc nền tảng;

iii)

Chọn một nền tảng chuyên biệt mà hệ thống phụ thuộc;

iv)

Chuyển đổi hệ thống từ đặc tả nền tảng này sang đặc tả ở nền tảng khác

2.1.2. Tư tưởng tiếp cận theo mô hình MDA [1][2][10]
MDA tập trung chủ yếu vào các chức năng và hành vi của một hệ thống

mà không phải là công nghệ mà nó sẽ được thực hiện. Nó tách biệt các chi tiết
thực hiện khỏi các chức năng công việc. Vì vậy, không cần phải lặp lại quá
trình của mô hình hóa chức năng và hành vi của một ứng dụng hoặc hệ thống
mỗi khi xuất hiện một công nghệ mới.
Hướng tiếp cận của MDA trong phát triển phần mềm là sự chuyển đổi
các mô hình.
Ba mục tiêu chính của MDA là khả năng chuyển đổi (portability), tính
tương vận (interoperability) và khả năng tái sử dụng (reusability).

1

/>
HVTH: Trần Thị Anh Thi - CH1502021

Trang 12

Để đạt mục tiêu khả chuyển, MDA đề ra kiến trúc Metadata MOF (Meta
Object Facility) [16]. Để đạt các mục tiêu còn lại MDA phân chia các mức
nhìn phụ thuộc trong một hệ thống. Để có thể phát triển được công cụ hỗ trợ
phát triển hệ thống đạ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. Trong đó, M0 (layer) là hệ thống cần xây
dựng. M1(Model) là tập hợp các metadata. M2 (MetaModel) chứa các metamodel quy định cú pháp (syntax) và ngữ nghĩa (symantic) của các model ở
mức M1, đây là tầng không cố định trong kiến trúc MOF. Mức trên cùng M3
(MOF Model) là meta-metamodel định nghĩa các mô hình của meta-model
dựa trên đặc tả MOF

Hình 2. 1: Kiến trúc Metadata MOF [16]

MDA đưa ra 3 loại mô hình phụ thuộc như sau [1]:

-

CIM (Computation Independent Model): Mô hình độc lập tính toán – CIM là
mô hình nhằm mô hình hoá các yêu cầu của hệ thống, nó miêu tả các ngữ cảnh
mà hệ thống sẽ sử dụng. CIM có thể ẩn đi các thông tin về cách xử lý các dữ
liệu trong hệ thống. Tuỳ theo ngữ cảnh khác nhau mà có gọi CIM là mô hình
phân tích, mô hình miền hoặc mô hình nghiệp vụ.
Mô hình độc lập tính toán – CIM là mô hình của hệ thống để thể hiện vị trí, vai
trò của hệ thống trong môi trường triển khai nó. CIM giúp chúng ta biểu diễn
chính xác những gì mà chúng ta mong đợi hệ thống sẽ thực hiện được. Ngoài

HVTH: Trần Thị Anh Thi - CH1502021

Trang 13

ra, sự hữu ích của CIM không chỉ giúp hiểu được các vấn đề chung của hệ
thống mà còn giúp chúng ta có thêm cơ sở để xây dựng các mô hình khác của
hệ thống một cách đúng đắn. Nó đóng vai trò quan trọng trong việc lấp khoảng
trống giữa các chuyên gia phân tích trên miền cụ thể, những chuyên gia thiết
kế, triển khai hay bảo trì.
-

PIM (Platform Independent Model): PIM-Mô hình độc lận nền tảng, là một
cách nhìn về hệ thống trên quan điểm độc lập platform, mô tả hệ thống mà
không chứa bất cứ thông tin gì về platform sẽ hiện thực cuối cùng. Một PIM
thể hiện một mức độc lập platform cụ thể để có thể sử dụng với một tập các
platform khác nhau thuộc các loại tương tự. Một PIM mô tả một hệ thống phần
mềm hỗ trợ một số nghiệp vụ. Trong một PIM, hệ thống được mô hình từ quan
điểm làm thế nào để hệ thống hỗ trợ tốt nhất cho doanh nghiệp và nghiệp vụ.

Những yếu tố như là một hệ thống sẽ được hiện thực trên một mainframe với
một cơ sở dữ liệu quan hệ hay trên một server ứng dụng EJB thì không đóng
vai trò gì trong một PIM.

-

PSM (Platform Specified Model): PSM-Mô hình phụ thuộc nền tảng, biểu diễn
một cách trung thực cả ngữ nghĩa business run-time và technical run-time của
ứng dụng. Nó vẫn là một mô hình UML, nhưng, do các bước biến đổi, được
biểu diễn theo một biến thể (nghĩa là một profile) của UML mà phản ánh một
cách chính xác các thành phần technical run-time của platform đích.

HVTH: Trần Thị Anh Thi - CH1502021

Trang 14

Hình 2. 2: Ba loại mô hình phụ thuộc của MDA

2.1.2.1.

Các chuẩn liên quan mô hình MDD

MDD có thể hiểu là tên gọi chung cho hướng tiếp cận chuyển đổi
mô hình trong phát triển phần mềm được phân chia theo độ phụ thuộc vào
nền tảng. Hiện có nhiều hướng tiếp cận mô hình theo MDD. Tuy nhiên,
hiện nay trong các hội nghị, hội thảo thì MDD thường được nhắc đến theo
cách tiếp cận MDA của tổ chức OMG. Theo đó, trong luận văn tôi cũng sẽ
trình bày MDD theo cách tiếp cận này.
Tổ chức OMG đã đưa ra một số chuẩn cơ bản cho MDA như: MOF,

UML, XMI,…
i.

UML2 - Unified Modeling Language
Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language

– UML) là một ngôn ngữ để biểu diễn mô hình theo hướng đối tượng,
được xây dựng bởi ba tác giả chính James Rumbaugh, Grady Booch và
Ivar Jacobson với chủ đích:

2

/>
HVTH: Trần Thị Anh Thi - CH1502021

Trang 15

-

Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng.

-

Thiết lập một kết nối từ nhận thức của con người đến các sự kiện
cần mô hình hoá.

-

Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp,

có nhiều ràng buộc khác nhau.

-

Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và
máy.

Ngoài ra, UML còn cung cấp UML Profile hỗ trợ việc đặc tả các chi
tiết gần hơn tới mô hình cài đặt cũng như cho phép xây dựng các ánh xạ, các
luật chuyển đổi.
Các chuẩn của UML có thể được mở rộng cho từng dự án cụ thể khi
cần, bằng cách dùng UML profiles. Những ngữ nghĩa có thể được thêm vào
cùng với các phần tử UML đã có giúp ta định nghĩa các khuôn mẫu
(Stereotypes), các giá trị đích và các ràng buộc. UML hướng người phát triển
tới kiến trúc của các hệ thống cụ thể. Để đạt được hiệu quả đó giống như một
công cụ mô hình hoá, các biểu đồ UML biểu diễn hệ thống ở mức trừu tượng
cao, ẩn đi nhiều chi tiết ở mức thấp. Theo thời gian, người dùng UML nhận
thấy rằng cách tốt nhất để đạt được mục đích của mình là áp dụng MDA, mà
trong đó các mô hình UML được chuyển đổi tự động từ mức trừu tượng cao
tới trừu tượng ở mức thấp hơn và cuối cùng là chuyển đổi thành mã nguồn trên
một ngôn ngữ được lựa chọn.
Theo sự phát triển của công nghệ, UML hiển nhiên trở một công nghệ
chính cho việc phát triển phần mềm theo hướng MDA.
ii.

XMI[9] - XML Metadata Interchange

XMI (XML Metadata Interchange) cho phép trao đổi dữ liệu đặc tả giữa
các công cụ mô hình hoá dựa trên UML và lưu trữ dữ liệu đặc tả dựa trên
MOF (Meta Object Facility). XMI đóng vai trò chính trong việc dùng XML

trong MDA.
iii.

MOF[16] - Meta Object Facility

HVTH: Trần Thị Anh Thi - CH1502021

Trang 16

MOF cung cấp cấu trúc chuyển đổi và các chuẩn mô hình hóa được
dùng trong MDA. Những thành phần cơ bản này hỗ trợ cho việc chuyển đổi
và khả năng tương tác giữa các mô hình. Ngoài ra, MOF còn cung cấp một cơ
chế để các mô hình được phân tích thành XMI. MOF cũng định nghĩa các giao
diện cho phép chỉnh sửa mô hình, chúng được định nghĩa trong IDL và được
mở rộng trong Java.
Bất kỳ ngôn ngữ mô hình hoá nào theo chuẩn MDA cũng phải được
xây dựng dựa trên những khái niệm của ngôn ngữ MOF. Điều đó giúp cho
việc chuẩn hoá các dữ liệu metadata và đây cũng chính là điều kiện đầu tiên
để thực hiện việc chuyển đổi tự động.
iv.

OCL - Object Contraint Language

OCL là ngôn ngữ ràng buộc hướng đối tượng, đồng thời là một ngôn
ngữ diễn tả. OCL có thể được sử dụng cho cả mô hình MOF và UML. Việc sử
dụng OCL sẽ mở rộng sức mạnh diễn đạt của MOF và UML, nghĩa là là tăng
tính chính xác cho mô hình thiết kế thông qua các mô tả ràng buộc.
Trong MDA việc sử dụng OCL bảo đảm cho việc tạo ra các mô hình
đích hoàn chỉnh hơn. Khả năng đặc tả một mô hình nguồn chính xác và hoàn

chỉnh cho phép chuyển đổi MDA tạo ra nhiều PSM hay dạng văn bản có chất
lượng cao.
Ngoài ra, OCL cũng có thể được sử dụng rất hiệu quả trong định nghĩa
chuyển đổi mô hình. Ví dụ, để một hoặc nhiều thành phần trong một mô hình
nguồn tới một hoặc nhiều thành phần trong một mô hình đích. Những chuyển
đổi đó chỉ có thể được ứng dụng ở những điều kiện nhất định. Những điều kiện
này có thể được đặc tả bởi OCL, tức là một điều kiện OCL ở các thành phần
nguồn được liên kết tới một điều kiện OCL thứ hai ở mô hình đích.

2.1.2.2.

Một số cách tiếp cận chuyền đổi từ mô hình sang mô

hình[1][2][3]
i.

Tiếp cận dựa trên quan hệ

HVTH: Trần Thị Anh Thi - CH1502021

Trang 17

Tư tưởng chính của hướng tiếp cận này là xác định kiểu của thành tố
nguồn và thành tố đích của một quan hệ, sau đó sử dụng ràng buộc đặc tả quan
hệ này. Hướng tiếp cận này dùng lập trình logic để hiện thực các ràng buộc
trên do đặc tính tìm kiếm. Tất cả các hướng tiếp cận quan hệ đều chuyển đổi
hai chiều. Mô hình nguồn và mô hình đích phải tách biệt.
ii.

Tiếp cận dựa trên cấu trúc

Hướng tiếp cận này bao gồm hai giai đoạn: giai đoạn một tạo ra cấu
trúc phân cấp của mô hình đích, giai đoạn hai xác định giá trị cho các thuộc
tính và tham chiếu trong mô hình đích.
iii.

Tiếp cận lai

Hướng tiếp cận này kết hợp từ hai các hướng tiếp cận theo mô hình đã
được định nghĩa. Ví dụ, chúng ta có thể kết hợp cách tiếp cận cấu trúc với cách
tiếp cận quan hệ trên tạo ra một cách tiếp cận khác. Theo đó mô hình đích sẽ
bao gồm tập hợp các quan hệ, cấu trúc và có thể ràng buộc để chọn lọc các
thành tố ở mô hình nguồn.

2.1.3. Mô hình đề xuất cho luận văn
Dựa trên cơ sở lý thuyết của hướng tiếp cận MDD, tôi đề xuất mô hình cho
nghiên cứu của luận văn phương pháp sinh mã giao diện trên máy tính cá nhân từ
sơ đồ lớp như sau:

HVTH: Trần Thị Anh Thi - CH1502021

Trang 18

Process

UML:
Class Diagram

UML_to_XMI

XMI

ParserXMI

XMI Ilements
(Object diagram)

XMI_to_GUIclass

GUIClass in Java

Hình 2. 3: Mô hình đề xuất cho bài toán phát sinh mã giao diện

Theo mô hình đề xuất như trên, việc phát triển ứng dụng sẽ theo các bước sau:
-

Bước 1: Input dữ liệu - là sơ đồ lớp UML (class diagram).

-

Bước 2: Thực hiện chuyển đổi từ sơ đồ UML sang tài liệu XMI để làm
giàu ngữ nghĩa cho lược đồ UML. Việc chuyển đổi sẽ được thức hiện tự
động bằng công cụ plugin trên Eclipse

-

Bước 3: Bộ công cụ phân tích tự động PaserXMI sẽ:
o Phân tích nội dung của tài liệu XMI dựa trên các thuộc tính và quan

hệ giữa các đối tượng để xác định các thành phần cần lưu trữ.
o Định nghĩa lại và tổ chức lưu trữ thông tin từ kết quả thu được.

-

Bước 4: Thực hiện chuyển đổi sang mã giao diện của Java.

-

Bước 5: kết xuất của ứng dụng là các màn hình giao diện mà người dùng
có thể tinh chỉnh một cách dễ dàng.

2.2. Sơ lược về ngôn ngữ mô hình hóa UML
2.2.1. Ngôn ngữ UML

HVTH: Trần Thị Anh Thi - CH1502021

Trang 19

NGHIÊN cứu GIẢI PHÁP SINH mã GIAO DIỆN NGƯỜI DÙNG từ sơ đồ lớp CHO các ỨNG DỤNG QUẢN lý

Tài liệu liên quan

Tài liệu bạn tìm kiếm đã sẵn sàng tải về