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ý

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ín

Trang 1

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

Trang 2

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

Trang 3

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

Trang 4

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 CƠ SỞ LÝ THUYẾT VÀ HƯỚNG TIẾP CẬN 11

2.1 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 Mô hình đề xuất cho luận văn 18

2.2 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

Trang 5

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 Đánh giá hiệu quả sinh mã giao diện 57

CHƯƠNG 4 KẾT LUẬN VÀ KHUYẾN NGHỊ 59

Trang 6

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

Trang 7

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

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

API Application Proframming Interface

CIM Computation Independent Model

DSL Domain-Specific Language

DSM Domain-Specific Metamodel

MDA Model-Driven Architecture

MDE Model-Driven Engineering

MDSD Model-Driven Software Development

MOF Meta-Object Facility

OCL Object Condtrain Language

PIM Platform-Independent Model

PSM Platform Specified Model

UML Unified Modeling Language

XMI XML Metadata Interchange

XML eXtensible Markup Language

GUI Graphics User Interface

MIC Model Intergrated Computing

DTD Document Type Definition

Trang 8

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

Trang 9

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

Trang 10

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

Trang 11

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,

Trang 12

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

Trang 13

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

Trang 14

độ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

Trang 15

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ừ

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

Trang 16

Trang 17

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

Trang 18

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 https://msdn.microsoft.com/en-us/library/ms954811.aspx

Trang 19

Để đ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 meta-model 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

Trang 20

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

Trang 21

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 UML 2 - 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 http://www.omg.org/spec/UML/2.5/

Trang 22

- 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

Trang 23

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ệ

Trang 24

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:

Trang 25

Process

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

Trang 26

UML[11], [20] là một ngôn ngữ mô hình hoá thống nhất có phần chính bao gồm những ký hiệu hình học, được các phương pháp hướng đối tượng sử dụng để thể hiện và miêu tả các thiết kế của một hệ thống Đây là ngôn ngữ đặc tả, trực quan hoá, xây dựng và làm sưu liệu cho nhiều khía cạnh khác nhau của một hệ thống phần mềm UML có thể được sử dụng làm công cụ giao tiếp giữa người dùng, nhà phân tích, nhà thiết kế và nhà phát triển phần mềm

UML sử dụng một hệ thống ký hiệu thống nhất để biểu diễn các phần

tử mô hình Tập hợp các ký hiệu và phần tử mô hình giúp tạo nên một mô hình UML Trong UML 2.0 có hai loại sơ đồ cơ sở: sơ đồ cấu trúc và sơ đồ hành

vi

Mỗi sơ đồ thuộc về một trong hai loại sơ đồ này

 Nhóm sơ đồ về cấu trúc

 Sơ đồ lớp 

 Sơ đồ đối tượng 

 Sơ đồ thành phần 

 Sơ đồ bố trí 

 Sơ đồ đóng gói 

 Sơ đồ cấu trúc đa hợp

 Nhóm biểu đồ hành vi

 Sơ đồ ca sử dụng 

 Sơ đồ trình tự 

 Sơ đồ giao tiếp 

 Sơ đồ máy trạng thái

 Sơ đồ hoạt động

 Sơ đồ bao quát tương tác

Trang 27

Mục đích của sơ đồ cấu trúc là để cho thấy cấu trúc tĩnh của hệ thống đang được mô hình hoá Mặt khác, sơ đồ hành vi cho biết các hành vi động giữa các đối tượng trong hệ thống, bao gồm những hành vi như: phương thức, sự hợp tác và các hoạt động của chúng

Trong khuôn khổ của luận văn chỉ tập trung vào sơ đồ lớp (Class Diagram) nên tôi trình bày loại biểu đồ này, biểu đồ được sử dụng làm đầu vào cho nghiên cứu của tôi

 Sơ đồ lớp- Class Diagram

Sơ đồ lớp [11][21][22] là một trong những bản vẽ quan trọng nhất của thiết kế phần mềm Nó cho thấy cấu trúc và quan hệ giữa các thành phần tạo nên phần mềm Trong quá trình xây dựng sơ đồ lớp, chúng ta sẽ phải quyết định rất nhiều yếu tố về thiết kế cũng như tạo giao diện trong quá trình phát triển phần mềm

Sơ đồ lớp cho thấy các thực thể khác nhau (người, các chủ đề và dữ liệu) liên quan với nhau như thế nào Mỗi lớp trong sơ đồ chứa đầy đủ thuộc tính của tập các đối tượng trong phần mềm Sơ đồ lớp nằm trong phần sơ đồ cấu trúc Sơ đồ lớp là kiểu sơ đồ cấu trúc điển hình cung cấp cho ta tập hợp các phần tử, thuộc tính mà tất cả các sơ đồ cấu trúc khác sử dụng

Trong UML, một lớp (class) được thể hiện bằng hình chữ nhật có 3 phần Phần thứ nhất chứa tên lớp, phần thứ hai chứa thuộc tính và các dữ liệu thành phần của lớp phần cuối cùng sẽ trình các phương thức hay hàm thành phần của lớp [22]

ii Thuộc tính (Attribute)

Thuộc tính thường là những danh từ miêu tả những đặc điểm của đối tượng Giá trị của thuộc tính thường là những dạng dữ liệu đơn giản được đa phần các ngôn ngữ lập trình hỗ trợ như Integer, Boolean, Floats, Char,

Trang 28

Thuộc tính có thể có nhiều mức độ trông thấy được (visibility) khác nhau, miêu tả liệu thuộc tính đó có thể được truy xuất từ các lớp khác với lớp định nghĩa ra nó hay không

Trong UML, thuộc tính công cộng (public) được kí hiệu "+" cho biết thuộc tính có thể truy xuất tại mọi nơi Thuộc tính riêng (private) được ký hiệu dấu "-" cho biết thuộc tính chỉ được truy xuất trong pham

vi lớp định nghĩa nó Thuộc tính protect được ký hiệu là dấu “#” chỉ ra phạm vi có thể truy xuất được bắt đầu từ lớp khai báo đến các lớp dẫn xuất sau đó

iii Phương thức (Methods)

Phương thức định nghĩa các hoạt động, hành vi mà lớp có thể thực hiện Phương thức được sử dụng để xử lý thay đổi các thuộc tính cũng như thực hiện các công việc khác Phương thức thường được gọi

là các hàm (function), nhưng chúng nằm trong một lớp và chỉ có thể được áp dụng cho các đối tượng của lớp này Một phương thức được miêu tả qua tên, giá trị trả về và danh sách của 0 cho tới nhiều tham số Lúc thi hành, phương thức được gọi kèm theo một đối tượng của lớp

Vì nhóm các phương thức miêu tả những dịch vụ mà lớp có thể cung cấp nên chúng được coi là giao diện của lớp này Giống như thuộc tính, phương thức cũng có tính trông thấy được như public, private và protect

Trang 29

Hình 2 4: Class Employee

Trong 1 sơ đồ lớp, các lớp thường không xuất hiện độc lập mà luôn có mối liên hệ với nhau rất chặt chẽ

+ Associatios: chỉ mối quan hệ rất chung giữa hai hay nhiều lớp, nó chỉ ra sự

liên kết trong các thể hiện của các lớp Tập hợp các liên kết có cùng ý nghĩa giữa các đối tượng tạo thành mối qian hệ association - quan hệ giữa 2 tập hợp (2 lớp)

Mũi tên trong sơ đồ là một chiều sẽ chỉ ra rằng chiều của đối tượng thuộc lớp này có thể gọi lớp kia nhưng không có chiều gọi ngược lại Nếu mũi tên không có chiều thì ngầm định là hai chiều hoặc chiều nào không quan trọng Trường hợp có quan hệ bội (multiplicity) là giá trị số nhiều, nghĩa là nhiều đối tượng tham gia kết hợp vào

Multiplicity (bội số quan hệ) là số lượng thể hiện của một lớp liên quan tới một thực thể của lớp khác Với mỗi liên kết, có 2 bội số quan hệ cho 2 đầu của liên kết

Bảng 2 1: Các giá trị bội số và ý nghĩa [14]

Trang 30

0 1 Có giá trị là 1 hoặc 0

0 * Có giá trị là 1 hoặc nhiều hơn

5 15 Có giá trị ltừ 5 đến 15

+ Agrregation: là một loại của quan hệ Association nhưng mạnh hơn Agrregation

chỉ quan hệ giữa các lớp dựa trên nền tảng của nguyên tắc "một tổng thể được tạo thành bởi các bộ phận" Nó được sử dụng khi chúng ta muốn tạo nên một thực thể mới bằng cách tập hợp các thực thể tồn tại với nhau Ví dụ một chiếc xe ô tô gồm có bốn bánh xe, một động cơ, v.v

+ Composition:là một loại mạnh hơn của Aggregation thể hiện quan hệ class này là một phần của class kia

+ Dependency: là loại quan hệ giữa 2 đối tượng, trong đó quan hệ giữa 2 phần tử

trong mô hình mà thay đổi ở phần tử này (phần tử độc lập) có thể gây ra thay đổi ở phần tử kia (phần tử phụ thuộc)

+ Inheritance: Một khái niệm rất quan trọng trong thiết kế hướng đối tượng là sự kế

thừa, nói về khả năng của một lớp kế thừa các chức năng của một lớp khác Lớp được

kế thừa có thể thêm các chức năng mới của riêng nó Để mô hình hoá sự thừa kế trên một sơ đồ lớp, một đường thẳng liền mạch được kẻ từ lớp con (lớp kế thừa) với một hình đầu mũi tên hoặc hình tam giác rỗng, khép kín chỉ tới lớp cấp trên

Trang 31

Hình 2 5: UML Class Diagram

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

XML[18] là từ viết tắt của cụm từ eXtensible Markup Language (Ngôn ngữ đánh dấu mở rộng), với bit đánh dấu là chìa khóa để nhận dạng dữ liệu XML dùng

văn bản để mô tả thông tin dựa trên cấu trúc cây (tree) Mọi thông tin điều được biểu diễn dưới dạng văn bản (text), các thẻ đánh dấu (tag markup) được sử dụng để phân chia thông tin cũng như thứ bậc của các thông tin dữ liệu được mô tả Các thẻ của XML không được định nghĩa trước, người viết XML sẽ tự định nghĩa thẻ XML của chính họ XML sử dụng các khai báo kiểu dữ liệu DTD (Document Type Definition) hay lược đồ XML Schema để mô tả dữ liệu

Trang 32

Những thuận lợi của XML có thể kể đến như sau:

- Dữ liệu độc lập là ưu điểm chính của XML Do XML chỉ dùng để mô tả dữ liệu bằng dạng text nên tất cả các chương trình đều có thể đọc được XML

- Dễ dàng đọc và phân tích dữ liệu, nhờ ưu điểm này mà XML được dùng để trao đổi dữ liệu giữa các chương trình

2.2.2.1 Cấu trúc của một tập tin XML

Document Prolog: lưu trữ metadata của XML gồm 2 phần: khai báo XML

và khai báo kiểu dữ liệu trong XML

 Phần khai báo XML (XML declararion) bao gồm các thông tin về version của XML, charset, encoding…

 Phần khai báo kiểu dữ liệu trong XML (DTD) dùng để khai báo cấu trúc của các thẻ dùng trong XML

Root element hay còn gọi là Document Element: chứa tất cả các phần tử

và nội dung của nó, một phần tử của XML phải có thẻ mở và thẻ đóng

2.2.2.2 Tính well-formed và valid của tài liệu XML

Một tài liệu XML phải well-formed và valid Một XML well-formed là một XML thích hợp cho việc phân tích (parser) Tức là, XML tuân thủ các luật lệ về Tag, Element, Attribute, Value v.v chứa bên trong, để parse có thể nhận diện và phân biệt

Một tài liệu XML well-formed chưa chắc chứa đựng những dữ liệu hữu dụng trong công việc Well-formed chỉ có nghĩa là XML có cấu trúc đúng Để hữu dụng cho công việc, XML chẳng những well-formed mà còn cần phải valid Một tài liệu XML valid khi nó chứa những dữ liệu cần có trong loại tài liệu

Một tài liệu XML được xem là well-formed (đúng cú pháp) khi thỏa mãn tất

cả các điều kiện sau:

- Phải có phần tử gốc (root Element), gọi là Document Element, nó chứa tất

cả các Elements khác trong tài liệu

- Mỗi một thẻ mở đều phải có thẻ đóng và tên thẻ phải phân biệt hoa thường (case sensitive)

Trang 33

- Các thẻ khi đóng phải theo đúng trình tự (mở sau đóng trước)

- Tên thẻ không nên có khoảng trắng, không nên bắt đầu bằng “xml”

- Các thuộc tính (atributes) của một thẻ luôn luôn tồn tại theo cặp theo quy

ước: <tên> = “<giá_trị>”; không nên đặt tên thuộc tính trùng nhau, và giá

trị của thuộc tính phải đặt trong cặp dấu nháy kép hay nháy đơn Tên của

thuộc tính (atribute) sẽ theo qui luật đặt tên giống như đối với tên thẻ

- Các thẻ (tag) trong XML có thể lồng nhau (Thẻ này có thể chứa nhiều thẻ

khác ở bên trong)

2.2.2.3 XML nameSpace

Trong XML, tên các element thường do người dùng tạo ra nên khi kết hợp với các tài liệu hay ứng dụng khác sẽ xảy ra xung đột (conflict) Để tránh sự xung đột này sẽ dùng tiền tố (prefix) khi đặt tên cho các phần tử

Hình 2 6: Ví dụ một tài liệu XML [17]

Để khai báo một không gian tên ta chỉ cần đưa thêm thuộc tính

xmlns:prefix vào bên trong phần tử gốc Prefix là tên của không gian tên, mỗi

không gian tên cần mang một định danh duy nhất Một không gian tên có thể

Trang 34

là một địa chỉ internet hoặc một địa chỉ nào đó miễn là địa chỉ này phải duy nhất

2.2.2.4 XML Xpath Language [17]

Để trao đổi thông tin trong các tài liệu XML, cần có một chuẩn chung để truy xuất dữ liệu và XML Path Language (XPath) được sinh ra để giải quyết vấn đề đó XPath là một ngôn ngữ thiết kế ra với mục đích giúp cho ứng dụng

có thể di chuyển bên trong XML document và truy xuất các giá trị cũng như thuộc tính của các phần tử

Mối quan hệ giữa các phần tử trong Xpath:

 Parent: mỗi node (element, attribute) đều có một node parent

 Children: mỗi node có thể có nhiều và cũng có thể không có node children nào

 Siblings: là các node có cùng node parent

 Ancestors: là các node tổ tiên, bao gồm node parent và các node parent của parent

 Descending: là các node con cháu, bao gồm node children và các node children của children

Xpath sử dụng XPath expressions để di chuyển hay truy xuất thuộc tính trong các node của XML document

2.2.3 XMI (XML Metadata Interchage)

XMI [9][19] là một chuẩn của OMG cho cho phép người dùng mô tả đối tượng bằng cách sử dụng XML XMI làm việc dựa trên các chuẩn như W3C XML, MOG XML và MOF Mục đích của XMI là cho phép dễ dàng trao đổi siêu dữ liệu (metadata) giữa các công cụ mô hình dựa trên UML và các kho lưu trữ metadata dựa trên MOF trong các môi trường phân tán không đồng nhất

XMI định nghĩa các vấn đề sau trong việc mô tả đối tượng

Trang 35

- Biểu diễn các đối tượng dưới dạng các phần tử và các thuộc tính XML

- Tạo cơ chế chuẩn cho các đối tượng trong một hoặc nhiều tập tin  

- Truy xuất đối tượng XMI bằng cách sử dụng mô hình XML  

- Xác định đối tượng, cho phép các đối tượng được tham chiếu từ các đối tượng khác dưới dạng các định danh (identifier - ID)  

Dựa trên tiêu chuẩn XML, XMI cũng bao gồm 2 phần: DTD và XML documents

- DTD: Mỗi XML có một DTD riêng tùy theo mục đích của người viết Xác định các phần tử có thể xuất hiện trong văn bản, thứ tự chúng xuất hiện, cách chúng được sắp xếp trong cái khác, và các chi tiết cơ bản trong cấu trúc văn bản XML

- XML documents: chứa thông tin của các tag XML documents trong XMI được hình thành dựa vào tập luật có thể được sinh ra bởi các

mô hình Trong qui trình đảo ngược lại quá trình để tái tạo lại các mô hình có thể sử dụng XML document Trong cả 2 trường hợp chuyển đổi thuận và ngược, các tập luật được sử dụng cho từng trường hợp cụ thể Trong XMI, XML DTD sử dụng metamodel được định nghĩa trong metamodel in MOF (ví dụ như: UML metamodel) và sau đó sinh ra các tập luật cho XMI

2.3 Phân tích tài liệu XML

Trang 36

Java API for XML3 Processing, hay JAXP, là một trong các API4 cho lập trình Java XML Nó cung cấp khả năng kiểm chứng và phân tích các tài liệu XML

Hai loại giao diện (interface) để phân tích cơ bản là:

- Giao diện phân tích dạng mô hình đối tượng tài liệu (Document Object

Model) - viết tắt là DOM5 Theo kỹ thuật này dữ liệu trong XML sẽ

được đọc và phân tích trên bộ nhớ theo sơ đồ cây XML

- Giao diện phân tích dạng API đơn giản dành cho XML API đơn giản

dành cho XML (Simple API for XML) - viết tắt là SAX6 Bộ phân tích này (SAX Parser) xử lý thông tin XML dưới dạng một dòng dữ liệu (single stream of data)

2.3.1 SAX (Simple API for XML)

Nguyên lý: SAX parser tự động đọc lần lượt file XML và thực thi callback (do API caller đăng kí vào parser) khi gặp các phần tử đặc biệt trong file XML

Ưu điểm: Không hạn chế về memory; phù hợp đối với các tài liệu có kích thước lớn và nội dung xử lý tương đối đơn giản

Nhược điểm: Khi parser đã đi qua 1 element thì không quay trở lại element đó được nữa nên nếu cần lấy thông tin từ 1 element nhiều lần thì vẫn cần lưu thông tin

Trang 37

2.3.2 DOM (Document Object Model)

Cũng giống như XML, DOM7 là một tiêu chuẩn được định nghĩa bởi tổ chức W3C Tuy nhiên, không giống SAX, DOM không được thiết kế một cách cụ thể cho công nghệ Java mà DOM dùng cho mọi nền tảng (cross-platform) và mọi ngôn ngữ (cross-language)

Nguyên lý: Xây dựng cấu trúc dữ liệu dạng cây ứng với toàn bộ file XML cho phép API tương tác trên đó

Ưu điểm: DOM là một mô hình hướng đối tượng chuẩn cho XML, định nghĩa một phương thức chuẩn cho việc truy cập và thao tác với tài liệu XML Cấu trúc của DOM biểu diễn tài liệu XML dưới dạng cấu trúc cây nên dễ sử dụng, không hạn chế

về số lần thao tác trên một phần tử của cây DOM Đầu vào là một tài liệu XML được

bộ phân tích bởi DOM và sẽ tạo một cây trong bộ nhớ chứa thông tin của tài liệu đó Việc phân tích tài liệu XML bây giờ đưa về phân tích, xử lý các nút của cây

Hình 2 8: DOM Parser

Nhược điểm: Không thể xử lý file XML có kích thước quá lớn vì không có đủ memory Hơn nữa, khi dùng DOM thì toàn bộ file XML đều được parse (DOM library làm công việc này để xây dựng cấu trúc cây) nên không thích hợp cho trường hợp chỉ cần lấy thông tin từ một số tag XML nằm ngay đầu file

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

7 https://vi.wikipedia.org/wiki/DOM

Trang 38

XMI [19] biểu diễn các attribute trong sơ đồ lớp UML dưới đạng các tag Mỗi tag thể hiện các thuộc tính và các mối quan hệ có trong sơ đồ lớp Việc ánh xạ từ sơ

đồ lớp sang tài liệu XMI giúp cho kết quả đầu vào của bài nghiên cứu trở nên dễ phân tích, quản lý dữ liệu của các lớp trở nên dễ dàng hơn

2.3.3.1 PackagedElement

P𝑎𝑐𝑘𝑎𝑔𝑒𝑑𝐸𝑙𝑒𝑚𝑒𝑛𝑡 là một trong các thành  phần quan trọng để biểu diễn lớp trong XMI

Cấu trúc một 𝑝𝑎𝑐𝑘𝑎𝑔𝑒𝑑𝐸𝑙𝑒𝑚𝑒𝑛𝑡 được mô tả như sau:

< packagedElement xmi:type = "uml:Class"

xmi:id= ""

name = "" >

Trong đó:

xmi:id Cho biết id của lớp

name Cho biết tên của lớp

Bằng cách so sánh thành phần xmi:id ta có thể tìm mối quan hệ generalization

và Association lúc phân tích tài liệu XMI của lớp

Hình 2 9: Biểu diễn XMI của một lớp (Class)

2.3.3.2 Generalization

Generalization biểu diễn mối quan hệ kế thừa, đây là mối quan hệ quan trọng không chỉ trong sơ đồ lớp mà trong ngôn ngữ hướng đối tượng Cấu trúc một thành phần Generalization trong thẻ Generalization như sau:

<generalization xmi:type="uml:Generalization"

xmi:id=””

general=””/>

Trang 39

Trong đó:

xmi:id: Cho biết id của Generalization. 

general: Cho biết id của lớp được kế thừa bằng việc so sánh với id của từng lớp trong xmi

Hình 2 10: Biểu diễn XML của thành phần Generalization

2.3.3.3 Attribute

Attribite được biểu diễn trong XMI như sau:

xmi:type = "uml:Property"

xmi:id = "id của Attribute"

name = "Tên Attribute"

visibility = " Public, Private hoặc protected"

>. 

Nội dung của một thuộc tính được đặc tả trong attribute biểu diễn dưới dạng trong các thẻ con bao gồm:

- <type xmi:type="uml:PrimitiveType" href=""/>  

- <lowerValue xmi:type="" xmi:id="" value=""/>  

- <upperValue xmi:type="" xmi:id="" value=""/>  

- <defaultValue xmi:type="" xmi:id="" name =""> <value   xsi:nil="true"/> </defaultValue>  

Trang 40

Hình 2 11: Biểu diễn XML của một Attribute

2.3.3.4 Association

Association biểu diễn sự liên kết giữa các lớp trong XMI, cấu trúc của mỗi thành phần association có 2 tag <ownedEnd> </ownedEnd> chứa thông tin 2 lớp liên kết với nhau và được mô tả như sau:  

< packagedElement xmi:type = “𝑢𝑚𝑙 : 𝐴𝑠𝑠𝑜𝑐𝑖𝑎𝑡𝑖𝑜𝑛”

xmi:id=””>

Định dạng
Số trang	87
Dung lượng	11,57 MB