Thao tác mô hình trong phát triển hướng mô hình

Phương pháp phát triển phần mềm hướng mô hình ra đời với ý tưởng chính là tập trung vào việc mô hình hoá phần mềm, từ đó thông qua việc chuyển đổi mô hình, các mô hình nguồn chuyển đổi t

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN HUY HOÀNG

THAO TÁC MÔ HÌNH TRONG PHÁT TRIỂN HƯỚNG MÔ HÌNH

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội-2014

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN HUY HOÀNG

THAO TÁC MÔ HÌNH TRONG PHÁT TRIỂN HƯỚNG MÔ HÌNH

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Ngành: Công nghệ thông tin

Chuyên ngành: Kỹ thuật phần mềm

Mã số: 60480103

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS ĐẶNG ĐỨC HẠNH

Hà Nội-2014

i

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 khoa học của TS Đặng Đức Hạnh

Các nội dung nghiên cứu và kết quả đạ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 soạn theo sự hiểu biết của minh thông qua nghiên cứu từ các tài liệu tham khảo: Sách, báo cáo khoa học và các tài liệu được công bố trên website, thư viện điện tử của cá nhân - tổ chức nghiên cứu khoa học trên khắp thế giới

Hà Nội, tháng 10 năm 2014 Người thực hiện

Nguyễn Huy Hoàng

ii

LỜI CẢM ƠN

Lời đầu tiên, Luận văn xin cảm ơn đề tài nghiên cứu khoa học cấp Đại học Quốc

gia Hà Nội, mã số QG.14.06 do TS Đặng Đức Hạnh làm chủ đề tài Luận văn hoàn

thành được hỗ trợ một phần bởi đề tài nghiên cứu nêu trên

Tôi cũng xin gửi lời cảm ơn sâu sắc nhất tới TS Đặng Đức Hạnh – Giảng viên Bộ môn Công nghệ Phần mềm – Khoa Công nghệ Thông tin – Trường Đại học Công nghệ

- Đại học Quốc Gia Hà Nội, người đã định hướng nghiên cứu, tận tình hướng dẫn tôi hoàn thành luận văn này Với bản thân tôi, lĩnh vực nghiên cứu này còn là mới nhưng qua sự định hướng về cách tiếp cận, hướng dẫn phương pháp nghiên cứu của Thầy tôi

đã thu được những kiến thức nhất định sau khi thực hiện luận văn này

Em xin gửi lời cảm ơn sâu sắc tới các giảng viên Khoa Công nghệ Thông tin – Trường Đại học Công nghệ - ĐHQG Hà Nội, các giảng viên sau đại học khoá K18 trường Đại học Công nghệ - ĐHQGHN, những người đã giảng dạy, truyền đạt cho tôi những kiến thức quý báu trong suốt quá trình học tập tại trường

Cuối cùng, tối xin gửi lời cảm ơn tới tất cả các bạn bè khoá sau đại học K18 - ngành CNTT, các đồng nghiệp, những người thân trong gia đình đã hết sức tạo điều kiện, giúp đỡ tôi trong quá trình học tập và thực hiện luận văn này

Mặc dù luận văn đã hoàn thành nhưng do kiến thức của người thực hiện còn hạn chế nên chắc chắn đề tài còn nhiều vấn đề hạn chế Tôi chân thành mong nhận được các ý kiến góp ý của tất cả mọi người để có định hướng trong các nghiên cứu tiếp theo

Hà Nội, tháng 10 năm 2014 Người thực hiện

Nguyễn Huy Hoàng

iii

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN ii

MỤC LỤC iii

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

DANH MỤC HÌNH ẢNH VÀ ĐỒ THỊ vii

DANH MỤC BẢNG BIỂU x

CHƯƠNG 1 MỞ ĐẦU 1

1.1 Đặt vấn đề 1

1.2 Phạm vi nghiên cứu 2

1.3 Cấu trúc luận văn 2

CHƯƠNG 2 TỔNG QUAN PHÁT TRIỂN HƯỚNG MÔ HÌNH 3

2.1 Phương pháp phát triển phần mềm truyền thống 3

2.2 Giới thiệu phát triển hướng mô hình - MDD 4

2.3 Các khái niệm trong phát triển hướng mô hình 5

2.3.1 Model 5

2.3.2 Metamodel 6

2.3.3 Metametamodel 6

2.3.4 Chuyển đổi mô hình 7

2.3.5 Mô hình nguồn 7

2.3.6 Mô hình đích 7

2.3.7 Ngôn ngữ chuyển mô hình 7

2.3.8 Luật chuyển mô hình 7

2.3.9 Ánh xạ 8

2.4 Kiến trúc hướng mô hình – MDA 8

2.4.1 Giới thiệu kiến trúc hướng mô hình 8

2.4.2 Các kiểu mô hình trong MDA 9

2.4.3 Những Lợi ích MDA mang lại 11

2.5 Một số chuẩn liên quan MDD 12

2.5.1 UML - Unified Modeling Language 13

2.5.2 XMI - XML Metadata Interchange 14

2.5.3 MOF - Meta Object Facility 14

2.5.4 OCL Object Contraint Language 14

iv

CHƯƠNG 3 CHUYỂN ĐỔI MÔ HÌNH TRONG MDD 16

3.1 Các hướng tiếp cận giải quyết vấn đề trong chuyển mô hình 16

3.1.1 Chuyển đổi mô hình sang mã nguồn 16

3.1.2 Chuyển đổi mô hình sang mô hình 17

3.2 Một số công cụ trong chuyển đổi mô hình 18

3.2.1 EMF - Eclipse Modeling Framework 18

3.2.2 Atlas Transformation Language - ATL 20

3.2.3 AndroMDA 20

3.2.4 ArcStyler 20

3.2.5 OptimaJ 20

3.2.6 QVT - Query/View/Transformation 21

3.3 Một số phương pháp sinh mã hướng mô hình 21

3.3.1 Phương pháp Template + Filterling 22

3.3.2 Phương pháp Template + Metamodel 23

3.3.3 Phương pháp sinh mã Inline-Code 24

3.4 Ngôn ngữ xây dựng Template trong các bộ sinh mã 25

3.4.1 Sử dụng ngôn ngữ 25

3.4.2 Sử dụng ngôn ngữ chuyên biệt miền 26

3.4.3 Sử dụng ngôn ngữ chuyển đổi mô hình chuyên dụng 26

CHƯƠNG 4 CÔNG CỤ CHUYỂN ĐỔI MÔ HÌNH ACCELEO M2T 31

4.1 Tổng quan về Acceleo 31

4.1.1 Lịch sử phát triển của Acceleo 31

4.1.2 Kiến trúc của Acceleo M2T 31

4.1.3 Nguyên lý cơ bản của Acceleo M2T 32

4.1.4 Template trong Acceleo M2T 33

4.2 Công cụ chuyển đổi mô hình Acceleo – JavaEE Generator 37

4.2.1 Các mô hình sử dụng trong Accleo JavaEE Generator 37

4.2.2 Module sinh mã trong Acceleo-JavaEE Generator 42

CHƯƠNG 5 CÀI ĐẶT VÀ THỰC NGHIỆM VỚI ACCELEO M2T 47

5.1 Nội dung và phạm vi thực nghiệm 47

5.1.1 Nội dung thực nghiệm 47

5.1.2 Phạm vi thực nghiệm 49

5.2 Thiết kế các mô hình 49

5.2.1 Mô hình thực thể (Entity model) 50

5.2.2 Mô hình trình diễn (Cinematic Model) 51

v

5.3 Cập nhật bộ công cụ Acceleo JavaEE Generator 70

5.3.1 Bổ sung template sinh mã SQL 70

5.3.2 Cập nhật các template sinh mã Hibernate 73

5.4 Thực hiện sinh mã và đánh giá kết quả 74

5.4.1 Sinh mã ứng dụng Công báo điện tử 74

5.4.2 Đánh giá hiệu quả sinh mã của Acceleo JavaEE Generator 75

KẾT LUẬN 78

TÀI LIỆU THAM KHẢO 79

PHỤ LỤC 81

vi

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

API Application Programming Interface

ATL ATLAS Transformation Language

CASE Computer Aided Software Engineering

CIM Computation Independent Model

DSL Domain-Specific Language

DSM Domain-Specific Metamodel

EMF Eclipse Modeling Framework

JET Java Emitter Templates

JMI Java Metadata Interface

MDRE Model Driven Reverse Engineering

MDSD Model-Driven Software Development

MDSE Model-Driven Software Engineering

MOF Meta-Object Facility

OCL Object Constraint Language

PIM Platform-Independent Model

UML Unified Modeling Language

XMI XML Metadata Interchange

XML eXtensible Markup Language

vii

DANH MỤC HÌNH ẢNH VÀ ĐỒ THỊ

Hình 2.1 Mình hoạ phương pháp phát triển phần mềm truyền thống 3

Hình 2.2 Áp dụng chuẩn MDA với mô hình thác nước 5

Hình 2.3 Mô hình được viết bởi một ngôn ngữ và mô tả hệ thống [3] 6

Hình 2.4 Biểu diễn khái niệm metamodel [3] 6

Hình 2.5 Mô tả chuyển đổi mô hình [3] 7

Hình 2.6 Mô phỏng kiến trúc – MDA 8

Hình 2.7 Kiến trúc metadata MOF [3] 9

Hình 2.8 Các mô hình trong MDA [1] 10

Hình 2.9 Khả năng tương tác sử dụng cầu nối trong MDA 12

Hình 2.10 Mối liên hệ giữa các chuẩn của OMG 13

Hình 3.1 Khung Eclipse Modeling Framework [8] 19

Hình 3.2 Mô hình Ecore và nguồn của nó [6] 19

Hình 3.3 Chuyển đổi mô hình sang mã theo MDA 22

Hình 3.4 Mô hình phương pháp Template + Fillerling 22

Hình 3.5 Mô hình phương pháp Template + Metamodel 24

Hình 3.6 Mô hình phương pháp sinh mã Inline-Code 24

Hình 3.7 Sinh mã dựa trên Template 25

Hình 3.8 JET Engine 27

Hình 3.9 Quy trình chuyển đổi của JET 28

Hình 3.10 Quy trình chuyển đổi trong oAW [5] 29

Hình 4.1 Minh hoạ kiến trúc của Acceleo M2T [15] 32

Hình 4.2 Nguyên lý cơ bản của Acceleo M2T 32

Hình 4.3 Các bước sinh mã trong Acceleo M2T 34

Hình 4.4 Ví dụ mô hình nguồn biểu diễn lớp NhanVien 34

Hình 4.5 Metamodel của biểu đồ lớp UML 35

Hình 4.6 Ví dụ File generate.mtl sinh lớp Java 35

Hình 4.7 Ví dụ: Mã nguồn NhanVien.Java được sinh ra 36

Hình 4.8 Entity metamodel trong Entity Designer 38

Hình 4.9 Ví dụ về một mô hình thực thể xây dựng bởi Entity Designer 38

Hình 4.10 Cinematic Metamodel trong Cinematic Designer 39

Hình 4.11 Ví dụ Flow Diagram trên Cinematic Designer 40

viii

Hình 4.12 Ví dụ về Package Diagram trên Cinematic Designer 40

Hình 4.13 Ví dụ về UI-Structure trong Cinematic Designer 40

Hình 4.14 SOA Metamodel trong SOA Designer 41

Hình 4.15 Ví dụ biểu đồ SOA biểu diễn trong SOA Designer 42

Hình 4.16 Ví dụ biểu đồ Component Contract trong SOA Designer 42

Hình 4.17 Kiến trúc MVC của Struts Framework 43

Hình 4.18 Kiến trúc của Hibernate Framework 45

Hình 5.1 Đặc tả biểu đồ Usecase – Quản lý công báo 47

Hình 5.2 Đặc tả biểu đồ Usecase – Quản lý văn bản 48

Hình 5.3 Đặc tả biểu đồ Usecase - Quản trị hệ thống 48

Hình 5.4 Đặc tả biểu đồ Usecase - Quản lý danh mục 48

Hình 5.5 Đặc tả biểu đồ Usecase – Khách viếng thăm hệ thống 49

Hình 5.6 Mô hình tổng quan đặc tả ứng dụng Công báo điện tử 50

Hình 5.7 Biểu đồ tổng quan các Block – Entity Model 50

Hình 5.8 Biểu đồ thực thể của Bock Vanban – Entity Model 51

Hình 5.9 Biểu đồ thực thể Bock Uer – Entity Model 51

Hình 5.10 Biểu đồ thực thể Block danhmuc - Entity Model 51

Hình 5.11 Biểu đồ tổng quan các Package - Cinematic Model 52

Hình 5.12 Biểu đồ tổng quan gói FrontEnd - Cinematic Model 53

Hình 5.13 Biểu đồ Flow ViewCongBao trong gói FrontEnd – Cinematic Model 54

Hình 5.14 Biểu đồ tổng quan gói BackEnd - Cinemantic Model 56

Hình 5.15 Biểu đồ Flow-Manage trong gói BackEnd – Cinematic Model 56

Hình 5.16 Biểu đồ Flow-ManageLinhVuc trong gói BackEnd – Cinematic Model 58

Hình 5.17 Biểu đồ Flow-ManageLoaiVanBan trong gói BackEnd – Cinematic Model 59

Hình 5.18 Biểu đồ Flow-ManageCoQuanBH trong gói BackEnd – Cinematic Model 62 Hình 5.19 Biểu đồ Flow-ManageVanBan trong gói BackEnd – Cinematic Model 62

Hình 5.20 Biểu đồ Flow-ManageCongBao trong gói BackEnd – Cinematic Model 65

Hình 5.21 Biểu đồ tổng quan gói System – Cinematic Model 66

Hình 5.22 Biểu đồ Flow-Login trong gói System – Cinematic Model 66

Hình 5.23 Biểu đồ Flow ManageAccount trong gói System – Cinematic Model 67

Hình 5.24 Biểu đồ Flow-Monitor trong gói System – Cinematic Model 69

Hình 5.25 Tạo mới template sqlCreate.mtl 70

ix

Hình 5.26 Nội dung Template sqlCreate.mtl – phần 1 71

Hình 5.27 Nội dung template sqlCreate.mtl phần -2 71

Hình 5.28 Mã nguồn sinh ra bởi sqlCreate.mtl 73

Hình 5.29 Cập nhật daoHibernateDirect.mtl trong module sinh mã Hibernate 73

Hình 5.30 Cập nhật daoHibernateCfg.mtl trong module sinh mã Hibernate 74

Hình 5.31 Cấu hình module StrutsArchitecture sinh mã từ mô hình Cinematic 74

Hình 5.32 Cấu hình module StrutsPresentation sinh mã từ mô hình Cinematic 75

Hình 5.33 Cấu hình module HibernateArchitectureEntity sinh mã từ Entity Model 75

Hình 5.34 Thời gian và số lƣợng file sinh bởi Acceleo JavaEE Generator 76

x

DANH MỤC BẢNG BIỂU

Bảng 5-1 Thành phần trong Flow-ViewCongBao – gói FrontEnd – Cinematic Model 55Bảng 5-2 Danh sách Flow trong gói BackEnd – Cinemantic Model 56Bảng 5-3 Thành phần trong Flow-Manage - gói BackEnd – Cinematic Model 57Bảng 5-4 Thành phần trong Flow-ManageLinhVuc – gói BackEnd – Cinematic Model 58Bảng 5-5 Thành phần trong Flow-ManageLoaiVanBan – gói BackEnd – Cinematic Model 60Bảng 5-6 Thành phần trong Flow-ManageCoQuanBH – gói BackEnd –Cinematic Model 61Bảng 5-7 Thành phần trong Flow-ManageVanBan – gói BackEnd – Cinematic Model 63Bảng 5-8 Thành phần trong Flow-ManageCongBao – gói BackEnd – Cinematic Model 64Bảng 5-9 Thành phần trong Flow-ManageAccount – gói System – Cinematic Model 67Bảng 5-10 Thành phần trong Flow-Mornitor – gói System – Cinematic Model 69

Tuy nhiên, một số trở ngại nhất định khiến trong phát triển phần mềm đó là việc dung hoà giữa hiệu suất và chất lượng vẫn còn là các mục tiêu khó đạt [14]:

 Khó nắm bắt chính xác yêu cầu của khách hàng: Các đơn vị phát triển phần

mềm thường có hiểu biết hạn chế về lĩnh vực của khách hàng Khách hàng không có kiến thức về qui trình phát triển phần mềm Thậm chí, khách hàng còn không biết hoặc không đưa ra yêu cầu rõ ràng Điều này thường dẫn đến nhu cầu thay đổi liên tục trong quá trình phát triển phần mềm

 Đối phó thường trực với yêu cầu thay đổi Thay đổi có thể diễn ra bất kỳ lúc

nào trong quá trình phát triển phần mềm Rất nhiều loại thay đổi có thể xảy ra như lỗi mã nguồn, thay đổi thiết kế, thay đổi nhân sự, thay đổi yêu cầu… Thay đổi càng trễ chi phí khắc phục càng cao

 Môi trường phát triển không đồng nhất Đối với những dự án phần mềm lớn

đội ngũ phát triển có thể bao gồm nhiều đội với nhiều nhân viên có những

kỹ năng lập trình, giao tiếp khác nhau đến từ nhiều nơi trên thế giới và sử dụng những những nền tảng kỹ thuật khác biệt Việc phối hợp các môi trường này thường đòi hỏi chi phí cao và làm phức tạp hóa quá trình phát triển

Mặt khác, trong phát triển thương mại, các công ty phát triển phần mềm luôn đặt mục tiêu nâng cao khả năng tự động hoá, tăng năng suất lao động, giảm thiểu chi phí sản xuất, nâng cao chất lượng sản phẩm… bằng cách áp dụng các công nghệ mới vào quy trình sản xuất

Để giải quyết các vấn đề nêu trên, các nhà phát triển phần mềm cần áp dụng nhiều phương pháp luận vào thực tiễn trong đó phương pháp phát triển phần mềm hướng mô hình Phương pháp phát triển phần mềm hướng mô hình ra đời với ý tưởng chính là tập trung vào việc mô hình hoá phần mềm, từ đó thông qua việc chuyển đổi mô hình, các

mô hình nguồn chuyển đổi tự động sang các mô hình đích, mô hình đích có thể là các

mô hình đặc tả, mã nguồn, tài liệu Chính vì khả năng ưu việt của phương pháp phát

2

triển hướng mô hình khiến tôi lựa chọn đề tài “Thao tác mô hình trong phát triển hướng mô hình”

1.2 Phạm vi nghiên cứu

Luận văn tập trung nghiên cứu và trình bày phương pháp luận về kiến trúc hướng

mô hình nói chung, phát triển hướng mô hình nói riêng, các công cụ chuyển đổi mô hình sang mô hình (M2M), mô hình sang văn bản (M2T) Cụ thể hơn luận văn đi sâu vào nghiên cứu và ứng dụng công cụ chuyển đổi mô hình sang văn bản – Acceleo M2T

1.3 Cấu trúc luận văn

Luận văn được cấu trúc thành 5 chương:

 Chương 1: Mở đầu – Đặt vấn đề và nêu ra định hướng nghiên cứu

 Chương 2: Tổng quan phát triển hướng mô hình (MDD) – Trình bày những kiến thức cơ bản về kiến trúc hướng mô hình (MDA) và một số chuẩn liên quan MDD

 Chương 3: Chuyển đổi mô hình trong phát triển hướng mô hình MDD- Trình bày phương pháp luận về chuyển đổi mô hình, các hướng tiếp cận trong chuyển đổi mô hình, một số công cụ chuyển đổi mô hình đang được áp dụng Nghiên cứu phương pháp chuyển đổi mô hình sang văn bản, chương này trình bày một

số phương pháp (pattern) sinh mã và ngôn ngữ xây dựng các khuôn mẫu (template) trong bộ sinh mã

 Chương 4: Công cụ chuyển đổi mô hình sang văn bản Acceleo– Chương này trình bày cơ sở lý thuyết của công cụ chuyển đổi mô hình sang văn bản Acceleo Nghiên cứu mã nguồn mở chuyển đổi mô hình sang mã nguồn Acceleo JavaEE Generator (Struts Framework, Hibernate Framework, Spring Framework)

 Chương 5: Cài đặt và thực nghiệm với Acceleo M2T – Hiệu chỉnh công cụ chuyển đổi Acceleo JavaEE Generator nhằm đảm bảo việc chuyển đổi mô hình sang mã nguồn Struts, Hibernate hoạt động trên nền tảng Web theo kiến trúc MVC với cơ sở dữ liệu Microsoft SQL Server và đưa ra đánh giá khả năng sinh

mã của bộ công cụ

3

Chương này của luận văn trình bày khái quát Phát triển phần mềm hướng mô hình (Model Driven Software Development – MDSD) Để hiểu rõ hơn về phát triển hướng

mô hình, Luận văn đưa ra các khái niệm, cơ sở lý thuyết về kiến trúc hướng mô hình, các chuẩn liên quan đến phát triển hướng mô hình và sự so sánh với phương pháp phát triển phần mềm truyền thống

Ngày nay, việc phát triển phần mềm theo phương pháp truyền thống vẫn đang được

áp dụng phổ biến Với các hệ thống phần mềm ở quy mô nhỏ thì phương pháp này vẫn đáp ứng và khả dụng Tuy nhiên khi nhu cầu tin học hoá hầu hết các nghiệp vụ trong mọi lĩnh vực của một tổ chức thì quy mô của một hệ thống phần mềm là lớn và lúc đó việc sử dụng phương pháp truyền thông sẽ gặp phải các khó khăn

Một ví dụ minh hoạ các pha phát triển phần mềm trên mô hình thác nước như Hình 2.1

Thu thập yêu cầu

Phân tích yêu cầu

Thiết kế

Cài đặt mã nguồn

Kiểm thử

Triển khai sử dụng

Dạng tài liệu đặc tả: Văn bản

Dạng tài liệu: Văn bản, biểu đồ

Dạng tài liệu: Văn bản, biểu đồ

Mã chương trình

Tài liệu: Mã chương trình, văn

bản

Hình 2.1 Mình hoạ phương pháp phát triển phần mềm truyền thống

Trong phương pháp phát triển phần mềm truyền thống, giả sử những người phát triển phần mềm đã tuân thủ rất chặt chẽ quy trình phát triển, các tài liệu ở các pha Thu thập yêu cầu, phân tích yêu cầu, thiết kế hệ thống, cài đặt mã nguồn… đã thể hiện các ràng buộc và sự liên quan cần có Điều đó vẫn không tránh khỏi các vấn đề:

4

 Khi có sự thay đổi về yêu cầu của người dùng, các pha sẽ đều phải thực hiện lại từ đầu Điều này dẫn đến mất nhiều thời gian và gây khó khăn cho người phát triển trong việc quản lý

 Sản phẩm cuối cùng sẽ phụ thuộc vào một nền tảng công nghệ cụ thể, khi nhu cầu công nghệ thay đổi sẽ dẫn đến phải xây dựng hệ thống lại từ đầu Trên đây là một số vấn đề mà phương pháp phát triển phần mềm truyền thống đã

và đang gặp các thách thức

2.2 Giới thiệu phát triển hướng mô hình - MDD

“Kỹ nghệ hướng mô hình (MDE) là phương pháp xem xét ở mức đại điện thống nhất, tất cả mọi thành phần được quy về mô hình”[10] Trong lĩnh vực phát triển phần mềm thì MDE được hiểu như phát triển hướng mô hình (MDD) hướng tới việc sử dụng các mô hình như là tác nhân chính trong toàn bộ vòng đời phát triển của ứng dụng, các ứng dụng được sinh mã từ các mô hình trừu tượng

Cũng theo Jean Bezivin [10] trong lĩnh vực phát triển phần mềm thì MDE hay MDD có ba hướng tiếp cận:

Development) phục vụ cho việc sinh mã từ mô hình Việc chuyển đổi mô hình được thực hiện trong thời gian phát triển

Engineering) áp dụng cho việc sinh các mô hình từ mã Việc chuyển đổi

thường được thực hiện trong lúc bảo trì

chuyển đổi mô hình trong khi thực thi ứng dụng, không phải là trong lúc phát triển hay khi bảo trì Các ứng dụng phổ biến ở đây nhằm đạt được khả năng tương tác giữa các hệ thống không đồng nhất

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 và thẩm định rõ ràng

 Không bị phụ thuộc vào việc thay đổi nền tảng (platform), khi cần thay đổi nền mới chỉ phụ thuộc vào 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

5

Thu thập yêu cầu

Phân tích yêu cầu

Thiết kế

Cài đặt mã nguồn

Kiểm thử

Triển khai sử dụng

Dạng tài liệu đặc tả: Văn bản

Hình 2.2 Áp dụng chuẩn MDA với mô hình thác nước

So sánh với phương pháp phát triển phần mềm truyền thống (xem mục 2.1) Sử dụng phương pháp phát triển hướng mô hình, áp dụng chuẩn MDA (xem mục 2.4) vào quy trình phát triển phần mềm theo mô hình thác nước (xem Hình 2.2) Tại mỗi pha phát triển, các tài liệu được đặc tả bởi các mô hình hình thức do vậy việc chuyển đổi tự động giữa các mô hình là khả dụng Thông qua các công cụ chuyển đổi mô hình, từ

mô hình độc lập nền - PSM có thể chuyển đổi sang các mô hình phụ thuộc nền- PSM;

từ mô hình phụ thuộc nền – PSM có thể được chuyển đổi sang dạng mã nguồn, tài liệu… Vì vậy các vấn đề gặp khó khăn với phương pháp truyền thống đã có thể được tháo gỡ

2.3 Các khái niệm trong phát triển hướng mô hình

2.3.1 Model

Mô hình là một phương pháp biểu diễn hệ thống một cách đơn giản nhằm giúp hiểu hơn về hệ thống Mô hình được biểu diễn bằng các ký hiệu đồ hoạ và thường được diễn đạt bởi ngôn ngữ đặc tả miền cụ thể hoặc dưới dạng ngôn ngữ hình thức Chúng

ta có thể định nghĩa mô hình như sau:

“Mô hình là một mô tả một phần của hệ thống hoặc toàn bộ hệ thống được viết bởi ngôn ngữ hình thức” [3] “Ngôn ngữ hình thức là ngôn ngữ với mẫu được xác định rõ ràng và ngữ nghĩa phù hợp với việc biên dịch tự động bởi máy tính”[3]

6

Hình 2.3 Mô hình đƣợc viết bởi một ngôn ngữ và mô tả hệ thống [3]

2.3.2 Metamodel

Metamodel [3] cũng là một mô hình, nó thể hiện ở mức trừu tƣợng hơn và sử dụng

để biểu diễn mô hình (model) Ngôn ngữ để biểu diễn metamodel đƣợc gọi là language

meta-Hình 2.4 Biểu diễn khái niệm metamodel [3]

Nói cách khác, metamodel của mô hình A mô tả cấu trúc hợp lệ của mô hình A Trong chuyển đổi mô hình thì metamodel là điều kiện tiên quyết

7

2.3.4 Chuyển đổi mô hình

Trong lĩnh vực phát triển hướng mô hình thì chuyển đổi mô hình là trọng tâm, nó được xem như một hộp đen cung cấp các cơ chế được thiết lập nhằm cho việc tự động tạo ra và cập nhật các mô hình đích dựa trên thông tin đầu vào được biểu diễn bởi mô hình nguồn [3] Định nghĩa về chuyển đổi mô hình: “Chuyển đổi mô hình là tập hợp

các luật chuyển đổi cùng mô tả cách một mô hình tại ngôn ngữ nguồn có thể được chuyển đổi thành một mô hình ở ngôn ngữ đích”

Hình 2.5 Mô tả chuyển đổi mô hình [3]

2.3.5 Mô hình nguồn

Trong ngữ cảnh của chuyển đổi mô hình, nếu một mô hình đóng vai trò là đầu vào của bước chuyển được gọi là mô hình nguồn Mô hình nguồn phải tuân thủ metamodel nguồn Có thể có một hoặc nhiều mô hình nguồn là đầu vào của bước chuyển

2.3.6 Mô hình đích

Trong ngữ cảnh của chuyển đổi mô hình, nếu một mô hình đóng vai trò là đầu ra của bước chuyển được gọi là mô hình đích Mô hình đích phải tuân thủ metamodel đích Có thể có một hoặc nhiều mô hình đích được sinh ra sau một bước chuyển Thuật ngữ mô hình đích thường được sử dụng trong chuyển đổi mô hình sang mô hình (M2M – Model To Model)

2.3.7 Ngôn ngữ chuyển mô hình

Một ngôn ngữ chuyển mô hình là một tập từ vựng và một ngữ pháp được định nghĩa ngữ nghĩa tốt cho khả năng chuyển mô hình

2.3.8 Luật chuyển mô hình

Theo [3] định nghĩa “Một luật chuyển đổi mô hình là sự mô tả cách một hoặc nhiều

cấu trúc trong ngôn ngữ nguồn có thể được chuyển đổi thành một hoặc nhiều cấu trúc trong ngôn ngữ đích” Một luật chuyển đổi mô hình là thực thể nhỏ nhất trong chuyển

mô hình Nó mô tả cách một phần của mô hình nguồn có thể được chuyển thành một phần của mô hình đích Một luật chứa một mẫu nguồn và một mẫu đích, đối với một phần xuất hiện của mẫu nguồn trong mô hình nguồn sẽ có ánh xạ tương ứng với một phần của mẫu đích trong mô hình đích

8

2.3.9 Ánh xạ

Ánh xạ là các đặc tả cho một cơ chế chuyển đổi các phần tử của một mô hình được xây dựng tuân theo một metamodel cụ thể này sang các phần tử của một mô hình được xây dựng tuân theo một metamodel khác.[16]

Các nhãn trong chuyển đổi mô hình là khái niệm biểu diễn một khái niệm trong mô hình đích và được áp dụng cho một phần tử của mô hình nguồn để chỉ ra phần tử đó được chuyển đổi như thế nào [16]

2.4.1 Giới thiệu kiến trúc hướng mô hình

Kiến trúc hướng mô hình - MDA (Model Driven Architecture ) [20] là một phương pháp chuyên biệt hoá trong phát triển hướng mô hình được đề xuất bởi tổ chức OMG (Object Management Group) từ năm 2001 MDA được đề xuất bắt nguồn từ nhu cầu làm rõ và đặc tả các tác vụ của hệ thống, xác định rõ ràng thành phần nào phụ thuộc vào nền tảng, thành phần nào không phụ thuộc vào nền tảng và đồng thời phân nhỏ các mức độ phụ thuộc vào nền tảng 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

Hình 2.6 Mô phỏng kiến trúc – MDA Trong Hình 2.6 mô tả mô hình MDA bao gôm: Một bộ công cụ chuyển đổi lấy mô hình nguồn là một PIM (xem mục 2.4.2.2) chuyển đổi thành mô hình đích là một PSM (xem mục 2.4.2.3) Ở một ngữ cảnh khác với một bộ công cụ chuyển đổi có thể chọn

mô hình nguồn là PSM (xem mục 2.4.2.3) và chuyển đổi thành mô hình đích dạng văn bản (mã nguồn, tài liệu…)

MDA định hướng cho các ứng dụng đạt được các điểm sau:

 Thể hiện sự tách biệt rõ ràng giữa hệ thống và nền tảng

 Đặc tả mô hình hệ thống trên nền tảng độc lập

 Xác định một nền tảng chuyên biệt mà hệ thống phù hợp

Hình 2.7 Kiến trúc metadata MOF [3]

MDA định hướng phát triển phần mềm theo kiểu kiến trúc hướng mô hình theo đặc

tả MOF (xem mục 2.5.3), xác định kiến trúc metadata như Hình 2.7 Trong đó, M0 là

hệ thống mà phần mềm mà chúng ta cần xây dựng Hệ thống này được mô tả bởi các

mô hình ở mức M1 Mức M2 chứa các metamodel quy định cấu trúc và ngữ nghĩa cho các mô hình ở mức M1 Mức M3 trên cùng là mức meta-metamodel định nghĩa cấu trúc và ngữ nghĩa biểu diễn metamodel ở mức M2

2.4.2 Các kiểu mô hình trong MDA

Trong kiến trúc hướng mô hình – MDA, các loại mô hình được sự dụng bao gồm:

Mô hình độc lập tính toán - CIM, mô hình độc lập nền – PIM, mô hình phụ thuộc nền – PSM và mô hình nền tảng – PM Ba kiểu mô hình CIM, PIM, PSM thể hiện các hướng nhìn hệ thống theo các khía cạnh khác nhau và ở mức độ trừu tượng tương ứng với các pha phân tích yêu cầu, thiết kế và cài đặt trong phương pháp phát triển phần mềm truyền thống (xem Hình 2.2)

10

Mô hình yêu cầu Requirements Model

Mô hình thiết kế Design Model

Mô hình thực thi Implementation Model

Chuyển đổi CIM2PIM & PIM2PIM

Chuyển đổi PIM2PSM

CIM ~ Mô hình phân tích yêu cầu

CIM ~ Mô hình phân tích yêu cầu

PIM ~ Mô hình thiết kế

PSM ~ Mô hình thực thi

Hình 2.8 Các mô hình trong MDA [1]

2.4.2.1 Mô hình độc lập tính toán - CIM

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 Tuỳ theo ngữ cảnh khác nhau mà có gọ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 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 trọ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ì

2.4.2.2 Mô hình độc lập nền – PIM

Mô hình độc lập nền – PIM là một mô hình độc lập với các nền tảng Nó mô tả hệ thống nhưng không nêu rõ nó sẽ được sử dụng cho một nền tảng cụ thể nào Một mô hình độc lập nền sẽ phù hợp cho các kiểu kiến trúc đặc biệt, nó có thể được sử dụng cho máy ảo, một loại nền tảng chung hoặc là các nền tảng trừu tượng

2.4.2.3 Mô hình phụ thuộc nền – PSM

Mô hình phụ thuộc nền – PSM là mô hình được xây dựng cho một nền tảng cụ thể

Nó có nguồn gốc từ mô hình PIM và thêm một số các thông tin liên quan Do vậy kết hợp được các đặc điểm của kỹ thuật nền tảng độc lập với chi tiết các nền tảng cụ thể

11

Tuỳ thuộc vào mục đích sử dụng mà PSM có thể cung cấp ít hay nhiều thông tin chi tiết về hệ thống Nếu PSM bao gồm tất cả các thông tin chi tiết cần thiết cho việc tự động sinh ra các thành phần của hệ thống từ mô hình thì đó là một mô hình phụ thuộc nền tảng triển khai Mặt khác, PSM có thể yêu cầu bước sàng lọc tự động hay thủ công trước khi khi có được một mô hình phụ thuộc nền tảng triển khai

2.4.2.4 Mô hình nền – PM

Mô hình nền – PM cung cấp một tập các khái niệm kỹ thuật, biểu diễn các phần khác nhau tạo nên nền tảng và những dịch vụ cung cấp bởi nền tảng đó Mặt khác, nó cũng cung cấp cho việc sử dụng mô hình phụ thuộc nền các khái niệm biểu diễn các thành phần khác nhau trên một nền tảng cụ thể, nghĩa là một mô hình nền cung cấp một metamodel cho mô hình phụ thuộc nền

2.4.3 Những Lợi ích MDA mang lại

2.4.3.1 Đảm bảo hiệu suất và chất lượng phần mềm

Phát triển theo MDA tập trung vào việc xây dựng mô hình PIM, ở bước này chúng

ta làm việc một cách độc lập mà không phụ thuộc vào nền tảng đích, các vấn đề liên quan đến nền tảng kỹ thuật sẽ tự động thêm vào bởi việc chuyển đổi từ PIM sang PSM hay việc chuyển đổi từ PSM sang Text cũng được tự động hoá Do vậy chúng ta tập trung vào việc giải quyết các vấn đề nghiệp vụ tại thời điểm đầu của pha thiết kế hoặc trong việc bảo trì nâng cấp hệ thống, chính vì thế sẽ cải tiến được hiệu suất và chất lượng của phần mềm

2.4.3.2 Khả năng tương tác

Khi PSM được xác định cho các nền tảng khác nhau, chúng không thể trao đổi trực tiếp với nhau Bằng cách nào đó chúng ta cần chuyển đổi các khái niệm từ một nền tảng này thành các khái niệm được sử dụng ở nền tảng khác Đây là những gì mà khả năng tương tác đề cập tới MDA giải quyết vấn đề này bằng cách tạo ra các cầu nối (bridge) cần thiết giữa chúng (xem Hình 2.9)

Như Hình 2.9, giả sử chúng ta chuyển đổi một PIM thành hai PSM phụ thuộc vào hai nền tảng khác nhau, tất cả thông tin chúng ta cần để thu hẹp khoảng cách giữa hai PSM là đã có sẵn Cụ thể, với mỗi thành phần trong PSM thứ nhất ta biết từ thành phần nào trong PIM mà nó đã được chuyển đổi Từ thành phần trong PIM ta biết thành phần tương ứng nào ở trong PSM thứ hai Do đó, ta có thể suy ra có bao nhiêu thành phần từ PSM thứ nhất liên quan đến các thành phần ở PSM thứ hai Khi ta biết tất cả chi tiết kỹ thuật nền tảng cụ thể của cả hai PSM, ta có tất cả thông tin cần thiết để tạo một cầu nối giữa hai PSM

12

Hình 2.9 Khả năng tương tác sử dụng cầu nối trong MDA

2.4.3.3 Khả năng tương thích và tái sử dụng

Khi xem xét đến khía cạnh tương thích ngược, thì từ một PIM có thể chuyển đổi sang nhiều PSM cho nhiều nền tảng đích khác nhau, do đó việc thiết kế PIM sẽ hoàn toàn tương thích với nền tảng mới sử công nghệ mới Mặt khác khi những nền tảng công nghệ mới được phát minh trong tương lai, thì chúng ta chỉ cần thay đổi những công cụ chuyển đổi phù hợp, điều này cho phép chúng ta nhanh chóng triển khai hệ thống mới dựa trên nền tảng cũ (PIM)

2.4.3.4 Bảo trì và tài liệu

Với sự tập trung vào công việc thiết kế và sự tự động chuyển đổi từ từ mô hình sang mô hình hay từ mô hình sang dạng mã nguồn, tài liệu, hơn nữa là cả bộ Testcase

sẽ dễ dàng cho các pha vận hành bảo trì sau này

2.5 Một số chuẩn liên quan MDD

Điểm đặc biệt quan trọng để tích hợp thành công cũng như đạt được sự liên tác và quản lý các siêu dữ liệu độc lập với các ứng dụng, các nền tảng, các công cụ và các cơ

sở dữ liệu cũng như dễ dàng thực hiện các chuyển đổi trong MDA nói riêng hay MDD nói chung là việc đưa ra các chuẩn chung thống nhất Tổ chức OMG đã đưa một số chuẩn cơ bản cho MDA như: MOF, UML, XMI, CWM, chúng có sự liên kết chặt chẽ với nhau như thể hiện trong Hình 2.10

13

MOF Model

UML Metamodel

CWM Data Mining

JMI XMI

JOLAP Metadata

JDM Metadata

CWM OLAP

Extend

Serializes

Instance Of

Instance Of Mapping to XML Mapping to Java

Mapping to Java

Instance Of

Instance Of

Hình 2.10 Mối liên hệ giữa các chuẩn của OMG

2.5.1 UML - Unified Modeling Language

Ngôn ngữ mô hình hoá thống nhất UML cung cấp các chuẩn trừu tượng nhằm đơn giản hoá việc làm tài liệu, hiểu và bảo trì các hệ thống phần mềm phức tạp Cơ chế mở rộng của UML hỗ trợ xây dựng các mô hình cho hệ thống và đặc tả một cách chi tiết, chính xác 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 xạ, các luật chuyển đổi

UML là ngôn ngữ mô hình hoá, cho phép chúng ta làm việc ở mức độ trừu tượng cao mà ít quan tâm tới nền tảng công nghệ, do vậy nó làm giảm mức độ phức tạp của

hệ thống, trực quan và dễ nắm bắt hệ thống hơn Chuẩn UML có thể được mở rộng cho từng dự án cụ thể khi chúng ta 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ể Để đạ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 để đạ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 chọn Mặc dù không phải là bắt buộc nhưng UML là một công nghệ chính cho việc phát triển phần mềm theo phương pháp MDA

14

2.5.2 XMI - XML Metadata Interchange

XMI là một kỹ thuật chuyển đổi chuẩn giữa các công cụ, các kho dữ liệu và các phần mềm trung gian khác nhau XMI có thể được sử dụng để tự động cung cấp XML DTD từ các mô hình UML và OMF XMI được dùng để diễn tả các mô hình UML (dùng UML XMI DTD), data warehouse và các cơ sở dữ liệu (dùng CWM XMI DTD), các định nghĩa giao diện CORBA (dùng IDL, DTD), các lớp và giao diện Java (dùng Java DTD) XMI cùng kết hợp các chuẩn mô hình hoá UML, siêu mô hình, siêu

dữ liệu (MOF và XML) và các phần mềm trung gian (UML profiles cho Java, EJB, IDL, EDOC…) đóng vai trò cốt lõi trong việc dùng XML trong MDA

2.5.3 MOF - Meta Object Facility

MOF [19] cung cấp chuẩn mô hình hoá và cấu trúc chuyển đổi được dùng trong MDA Các mô hình chuẩn khác của OMG như UML, CWM được định nghĩa dựa trên những khái niệm cấu trúc của MOF Những thành phần cơ bản này cung cấp cho việc chuyển đổi và khả năng liên tác giữa các mô hình và 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 kỳ ngôn ngữ mô hình hoá nào được sử dụng trong MDA 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à đó là điều kiện đầu tiên để thực hiện việc chuyển đổi tự động MOF cũng định nghĩa chính nó nên cũng được xem như là một metametamodel

2.5.4 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ả Chúng ta có thể viết diễn tả qua các mô hình 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 mạnh diễn đạt của MOF/UML, và cho phép người thiết kế mô hình sáng tạo nhiều mô hình mở rộng chính xác hơn

Một mô hình UML của một hệ thống trở nên chính xác và hoàn thiện hơn bởi việc ứng dụng OCL Áp dụng trong MDA, sử dụng OCL bảo đảm cho việc tạ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 tạo ra nhiều PSM hay dạng văn bản có chất lượng cao Ngoài ra, OCL cũng có thể được sử dụng trong các lớp MOF, cho phép viết diễn

tả các meta-model

Ngoài việc mang lại sự chính xác cho mô hình nguồn và định nghĩa ngôn ngữ, OCL cũng có thể được sử dụng rất hiệu quả trong định nghĩa chuyển đổi Ví dụ, một chuyển đổi liên kết 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, và chuyển đổi đó chỉ có thể được ứng dụng

15

ở 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 Tất cả sự diễn giải OCL sử dụng trong định nghĩa chuyển đổi đƣợc chỉ ra cụ thể ở metamodel của ngôn ngữ nguồn hoặc đích

16

Chuyển đổi mô hình là chìa khoá cốt lõi, là trọng tâm của phương pháp phát triển hướng mô hình Trong chương này luận văn trình bày chi tiết hơn về chuyển đổi mô hình trong MDD, cụ thể hơn luận văn sẽ đi sâu vào tìm hiểu các công cụ sử dụng trong chuyển đổi mô hình, các phương pháp (pattern) sinh mã áp dụng trong sinh mã hướng

mô hình và các ngôn ngữ xây dựng khung mẫu (template) của bộ sinh mã trong chuyển đổi mô hình sang văn bản

3.1 Các hướng tiếp cận giải quyết vấn đề trong chuyển mô hình

Phân tích các công cụ chuyển đổi mô hình hiện có, [11] đã phân loại các công cụ chuyển đổi mô hình như sau: Chuyển đổi mô hình sang mã nguồn có hai hướng tiếp cận là visitor-based và template-based; Chuyển đổi mô hình sang mô hình có bốn hướng tiếp cận gồm hướng tiếp cận định dạng trực tiếp (direct manipulation approaches), hướng tiếp cận dựa trên quan hệ (relational approaches), hướng tiếp cận dựa vào chuyển đổi đồ thị (graph transformation based approaches), hướng tiếp cận hướng cấu trúc (structure driven approaches) và hướng tiếp cận lai (hybrid approaches)

3.1.1 Chuyển đổi mô hình sang mã nguồn

3.1.1.1 Hướng tiếp cận visistor-base

Hướng tiếp cận này cung cấp một cơ chế viếng thăm để duyệt qua cấu trúc biểu diễn bên trong của mô hình và ghi lại mã nguồn vào dòng văn bản Ví dụ cho hướng tiếp cận này là Jamda [9] một bộ framework hướng đối tượng cung cấp một tập hợp các lớp để biểu diễn mô hình UML, một tập hợp hàm API, và cơ chế viếng thăm (CodeWriter) để sản sinh mã nguồn Jamda không hỗ trợ metamodel nhưng các thành

tố mô hình mới có thể được tạo thông qua thừa kế từ các lớp có sẵn

3.1.1.2 Hướng tiếp cận template-base

Đây là hướng tiếp cận được hầu hết các công cụ MDA hiện có sử dụng như b+m Generator Framework [4], JET (xem mục 3.4.3.1), Codagen Architect [17], AndroMDA (xem mục 3.2.3), ArcStyler (xem mục 3.2.4), OptimalJ (xem mục 3.2.5) Hướng tiếp cận này sử dụng các mẫu (template) để chuyển đổi Một mẫu bao gồm mã nguồn của ngôn ngữ đích và các đoạn mã đặc biệt để truy xuất đến thông tin trong mô hình nguồn Thông tin trong mô hình nguồn có thể được truy xuất thông qua các API hoặc sử dụng các ngôn ngữ truy vấn như OCL, XPath… Mã nguồn được sản sinh sẽ

có cấu trúc giống với cấu trúc mẫu Tuy nhiên mẫu hoàn toàn không phụ thuộc vào ngôn ngữ đích

17

3.1.2 Chuyển đổi mô hình sang mô hình

Các phương pháp này dùng để chuyển đổi một mô hình nguồn sang một mô hình đích Cả hai mô hình có thể thuộc cùng một metamodel hoặc khác metamodel Việc chuyển đổi có thể giữ nguyên thông tin hoặc làm mất thông tin từ mô hình nguồn Trong MDA việc chuyển đổi mô hình sang mô hình là cần thiết để lấp đầy khoảng trống giữa PIM và PSM

3.1.2.1 Hướng tiếp cận định dạng trực tiếp

Hướng tiếp cận này cung cấp bộ API dùng để định dạng mô hình Nhà phát triển phải tự cài đặt các luật chuyển đổi API thông thường là một framework hướng đối tượng, ngôn ngữ sử dụng chuyển đổi là các ngôn ngữ lập trình thông dụng như Visual Basic, Java Một khó khăn khi dùng hướng tiếp cận này là các ngôn ngữ lập trình được thiết kế cho nhiều mục đích nên việc lập trình chuyển đổi sẽ tốn rất nhiều thời gian

3.1.2.2 Hướng tiếp cận dựa trên quan hệ

Ý 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, truy ngược và khớp của nó ví dụ như Fprolog trong Mercury 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

3.1.2.3 Hướng tiếp cận dựa vào chuyển đổi đồ thị

Hướng tiếp cận này bao gồm các luật chuyển đổi từ một mẫu hình nguồn sang một mẫu hình đích Mẫu hình có thể được xác định bằng cú pháp cụ thể hoặc ở cú pháp trừu tượng của mô hình MOF Luật chuyển đổi sử dụng cú pháp trừu tượng có thể hoạt động trên mô hình bất kỳ có cùng metamodel Khi một mẫu hình nguồn được khớp, nó

sẽ được thay thế bởi mẫu hình đích Các thuộc tính của các thành tố trong mô hình đích có thể được tính toán sử dụng các phép toán logic

3.1.2.4 Hướng tiếp cận hướng cấu trúc

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

mô hình đích Một ví dụ về hướng tiếp cận này là OptimaJ OptimaJ cung cấp một framework bằng Java mà người dùng có thể thừa kế để định nghĩa các luật chuyển đổi Luật chuyển đổi được cài đặt bằng một hàm với tham số đầu vào là kiểu thành tố nguồn và kết quả trả về là đối tượng đại diện thành tố mô hình đích

3.1.2.5 Hướng tiếp cận lai

Hướng tiếp cận này kết hợp từ hai trong số các hướng tiếp cận ở trên, điển hình là ATL [12] Luật chuyển đổi ATL bao gồm tập hợp các biến và có thể ràng buộc để

18

chọn lọc các thành tố ở mô hình nguồn Một luật đơn giản trong ATL dùng để chuyển đổi các đối tượng thuộc lớp Author trong mô hình MMAuthor thành các đối tượng lớp Person trong mô hình MMPerson với name và surname lấy từ Author:

}

3.2 Một số công cụ trong chuyển đổi mô hình

Ngày nay phát triển hướng mô hình đã được quan tâm và nghiên cứu nhiều hơn, cũng bởi vậy mà nhiều công cụ chuyển đổi mô hình theo hướng tiếp cận MDA ra đời Trong khuôn khổ của luận văn này, tôi xin được đề cập đến một số công cụ phổ biến như sau:

3.2.1 EMF - Eclipse Modeling Framework

Khung mô hình hoá Eclipse (EMF) [7] là một bộ khung sinh mã mã mạnh mẽ hướng đến xây dựng các ứng dụng Java dựa trên định nghĩa các mô hình Nó được thiết kế để tạo các mô hình hoá thiết thực và hữu ích cho các lập trình viên Java EMF

là sự thống nhất ba bền tảng quan trọng: Java, XML và UML Mô hình có thể được định nghĩa khi sử dụng công cụ mô hình hoá UML, lược đồ XML hoặc thậm chí là các chú thích đơn giản trên giao diện Java Vì vậy ở đây người các nhà phát triển chỉ việc xây dựng các mô hình trừu tượng và phần còn lại là thực hiện tự động EMF được phát hành như một dự án con của Eclipse vào năm 2003, nhưng giờ đây nó là nền tảng mô hình hoá tinh vi đằng sau trình phát triển Eclipse và dường như không thể thiếu trong phát triển hướng mô hình [6]

EMF phần lớn là tương thích MDA với chỉ duy nhất sai lệch nhỏ từ một vài tiêu chuẩn Ví dụ, nền tảng của ngôn ngữ mô hình meta-model của EMF được biết đến là Ecore Ecore không giống nhưng rất sát với Essential MOF (EMOF) được mô tả trong MOF 2.0 của MDA EMF thường có thể tải một EMOF meta-model, các ánh xạ và chuyển đổi được phát triển giữa EMOF và Ecore

19

Hình 3.1 Khung Eclipse Modeling Framework [8]

EMF đi cùng với các cơ chế tiêu chuẩn dùng cho việc xây dựng meta-model và lưu lại chúng như các giao diện có thể lập trình được, cũng như mã nguồn và dữ liệu dạng XML Một khung soạn thảo mô hình (Editor) và khung sinh mã (Generators) cũng được cung cấp (xem Hình 3.1) EMF được tích hợp chặt chẽ với Eclipse và khả năng tận dụng kiến trúc và cơ sở hạ tầng của Eclipse hỗ trợ việc tích hợp meta-data riêng rẽ, qua nhiều công cụ trong một hệ sinh thái chung ăn theo Eclipse Điều này nâng cao mức độ tương tác giữa các công cụ phần lớn tương thích với MDA

Mô hình được sử dụng để biểu diễn mô hình trong EMF là Ecore Ecore chính là một mô hình EMF do đó nó vừa là model, vừa là metamodel thậm chí nó còn là meta-metamodel Ecore là thành phần cốt lõi của EMF, Ecore được tạo ra từ một trong ba nguồn: Mô hình UML, lược đồ XML, hoặc ký hiệu Java Interface Hình 3.2 cho thấy

mô hình Ecore sau khi thực thi bởi Java sẽ sinh ra mô hình đích như đã lựa chọn

Hình 3.2 Mô hình Ecore và nguồn của nó [6]

Do tiêu chuẩn chuyển đổi mô hình vẫn tiếp tục phát triển và các sản phẩm thu nhận được đều từ chính việc sinh mã, nên hầu hết các công cụ hiện tại đều tập trung vào sinh mã từ mô hình Nhìn chung, trên thị trường các công cụ MDA sử dụng EMF vẫn đang trưởng thành ở cả hai lĩnh vực thương mại cũng như các dự án mã nguồn mở

20

3.2.2 Atlas Transformation Language - ATL

ALT [12] là một ngôn ngữ sử dụng trong việc chuyển đổi mô hình sang mô hình (M2M) ATL chỉ hỗ trợ cho phép chuyển đổi mô hình theo một hướng Một chương trình chuyển ATL bao gồm các luật chuyển mô tả cách tạo ra các phần tử của mô hình đích Ngôn ngữ được đặc tả như là metamodel và với cú pháp cụ thể dưới dạng ký tự ATL được tích hợp trong môi trường phát triển của Eclipse và có thể làm việc với các

mô hình dựa trên EMF Mã nguồn ATL được biên dịch và sau đó được chạy trên máy chuyển mô hình

3.2.3 AndroMDA

AndroMDA [2] [8] là nền tảng mã nguồn mở tương thích MDA, nó có cơ chế cho phép các nền tảng và các thành phần hỗ trợ có thể hoán đổi trong và ngoài bất cứ lúc nào Nó được khai thác nhiều bởi các dự án nguồn mở hiện tại cho cả mục đích xây dựng dịch vụ phụ thuộc nền (XDoclet cho EJB) và dịch vụ nền tảng chung (Apache Velocity cho việc xây dựng khuôn mẫu chuyển đổi)

Với AndroMDA, lập trình viên có thể mở rộng ngôn ngữ mô hình hoá hiện tại qua các tiện ích như “metafacades” Phần mở rộng được phản ánh qua một UML Profile trong thư viện mô hình hoá và khuôn mẫu trong các công cụ chuyển đổi AndroMDA

hỗ trợ chủ yếu việc chuyển đổi từ mô hình sang mã

3.2.4 ArcStyler

ArcStyler [22] là công cụ phát triển phần mềm hàng đầu theo hướng MDA ArcStyler là nền tảng, môi trường tiêu chuẩn hoàn toàn được cài đặt trên Java hỗ trợ cho việc thiết kế, mô hình hoá, phát triển và quản lý chất lượng cao Nó dùng cho xây dựng các ứng dụng trong công nghiệp phần mềm không giới hạn phạm vi lớn nhỏ dựa trên công nghệ Java/J2EE và NET cũng như khả năng tuỳ chỉnh nền tảng hạ tầng Ngoài UML Profile, nó sử dụng cơ chế của chính nó để biểu diễn thông tin trong PIM Cũng như AndroMDA, ArcStyler hỗ trợ cơ chế mở rộng cho việc sinh mã Công cụ này cũng hỗ trợ việc chuyển đổi tuân thủ toàn bộ MDA với các luật chuyển đổi rõ ràng

3.2.5 OptimaJ

OptimalJ [23]là môi trường phát triển tuân thủ toàn bộ MDA Mô hình trong OptimalJ có nhiều mức trừu tượng như:

 Mô hình miền (OptimalJ Domain Model) tương ứng với PIM trong MDA

Nó định nghĩa miền nghiệp vụ (Business Domain) mà không có bất cứ thông tin chi tiết nền tảng cụ thể nào Nó được định nghĩa bằng cách mô hình hoá các tính năng và hành vi của ứng dụng, thông tin phụ thuộc miền được xây dựng dựa trên MOF bằng UML

21

 Mô hình miền được chuyển đổi tự động sang mô hình ứng dụng (OptimalJ Application Model), tương ứng với PSM trong MDA Miền ứng dụng định nghĩa ứng dụng, dựa trên công nghệ được lựa chọn như J2EE

 Cuối cùng miền ứng dụng được chuyển đổi tự động sang mô hình mã (OptimalJ Code Model) tương ứng với Code/Text trong MDA

3.2.6 QVT - Query/View/Transformation

QVT - Query/View/Transformation [21] là một ngôn ngữ chuẩn cho chuyển mô hình được tạo ra bởi OMG QVT sử dụng ngôn ngữ ràng buộc OCL, MOF và được định hướng theo kiến trúc MDA Cũng giống như cái tên của nó đã thể hiện rõ rằng QVT cho phép thực hiện: Chuyển đổi mô hình (transformation), biểu diễn mô hình (View) và truy vấn (Query) Truy vấn mô hình và biểu diễn mô hình được xem như một phương pháp đặc biệt của chuyển đổi mô hình QVT cũng được tích hợp trên Eclipse

QVT định nghĩa ba ngôn ngữ trong việc chuyển đổi mô hình tới mô hình (M2M) tuân thủ theo chuẩn MOF 2.0:

 QVT Relational: Là một ngôn ngữ chuyển đổi mô hình khai báo Hai dạng

cú pháp được định nghĩa trong QVT là cú pháp dạng ký tự và cú pháp dạng

đồ hoạ Ngôn ngữ QVT hỗ trợ chuyển đổi hai chiều Một phép chuyển được đặc tả như là một tập quan hệ giữa các metamodel nguồn và đích Phép chuyển này cũng có thể được kiểm tra tính hợp lệ của hai mô hình

 QVT Core: Chính là nền tảng cho ngôn ngữ QVT Relational, nó là một ngông ngữ chuyển đổi mô hình khai báo cấp thấp

 QVT Operational: Là ngôn ngữ chuyển đổi mệnh lệnh, được áp dụng để cho phép chuyển đổi theo một hướng duy nhất

Đối với MDA việc sinh mã tự động hướng mô hình được mô tả như Hình 3.3 Trong đó mô hình nguồn (Source Model) được xây dựng bởi các ngôn ngữ mô hình hoá khác nhau Đích (Target) là các đoạn mã phù hợp với cú pháp của các ngôn ngữ nền tảng như Java, C#, PHP… Đích cũng được xem như là mã nguồn hay chương trình (Code/Program) Bộ sinh mã (Code Generator) và định nghĩa sinh mã (Code Generation Definition) được xem như là Meta-Program

22

Hình 3.3 Chuyển đổi mô hình sang mã theo MDA Source Model được mô hình hoá bởi Source Meta-Model, Target Meta-Model biểu diễn Target Model hay Code/Program Code Generation Definition định nghĩa việc chuyển đổi từ Source Model sang Target Model bằng việc sử dụng các thành phần của Meta-Model Code Generator sẽ đọc các thông tin đầu vào từ Source Model, điền thông tin theo khuôn mẫu đã được định nghĩa bởi Code Generation Definition để sinh

mã (Code/Program)

Vậy các bộ sinh mã (Code Generator) được xây dựng và hoạt động như thế nào? Theo Markus Voelter [13] thì có một số phương pháp sinh mã như: Phương pháp Template + filterling; Phương pháp Template + Metamodel; Phương pháp sinh mà dựa trên API hay Phương pháp sinh mã Inline Code

3.3.1 Phương pháp Template + Filterling

Phương pháp này mô tả cách đơn giản nhất để sinh mã Thông thường, mã được tạo bằng cách áp dụng khuôn mẫu cho đặc tả mô hình văn bản (thường là XML/XMI),

và sau khi lọc một vài phần của đặc tả Một phần của mã nguồn cũng được nhúng trong khuôn mẫu

Hình 3.4 Mô hình phương pháp Template + Fillerling

Ví dụ sau mô tả việc sinh mã Java dựa vào đặc tả mô hình XML

 Mô hình nguồn được biểu diễn bởi XML:

<class name ="Person" package ="de.unifrei" >

<attribute name ="name" type ="String"/>

<xsl:template match = "/class" >

package <xsl:value-of select = "@package" />;

public class <xsl:value-of select = "@name" />

{ <xsl:apply-templates select = "attribute" /> }

</xsl:template>

<xsl:template match = "attribute" >

<xsl:variable name = "capname"

select ="concat( translate( substring( @name, 1, 1),

’abcdefghijklmnopqrstuvwxyz’,

’ABCDEFGHIJKLMNOPQRSTUVWXYZ’ ),

substring(@name, 2))" />

private <xsl:value-of select = "@type" />

<xsl:value-of select = "@name" />;

public <xsl:value-of select = "@type" />

get<xsl:value-of select = "$capname" /> ()

{return <xsl:value-of select = "@name" />;}

public void set<xsl:value-of select = "$capname" />

(<xsl:value-of select = "@type" /> <xsl:value-of select = "@name" />)

{this.<xsl:value-of select = "@name" /> = <xsl:value-of select = "@name" />;}

</xsl:template>

 File Java được sinh ra:

package de . unifrei ;

public class Person {

private String name ;

public String getName () { return name ;}

public void setName ( String name ) { this name = name ;}

private int age ;

public int getAge () { return age ;}

public void setAge ( int age ) { this age = age ;}}

3.3.2 Phương pháp Template + Metamodel

Phương pháp này là một sự mở rộng của phương pháp “Template and Filtering” (xem Hình 3.5) Thay vì áp dụng khuôn mẫu trực tiếp vào mô hình, thì việc đầu tiên là khởi tạo một meta-model từ đặc tả sau đó mới áp dụng khuôn mẫu Khuôn mẫu được

24

mô tả trong phạm vi của meta-model Meta-model có thể được mở rộng để bao gồm các khía cạnh miền hay kiến trúc cụ thể

Hình 3.5 Mô hình phương pháp Template + Metamodel

3.3.3 Phương pháp sinh mã Inline-Code

Phương pháp này mô tả kỹ thuật ở đó việc sinh mã được hoàn thành một cách ngầm định trong suốt việc thông dịch hay biên dịch của một chương trình thông thường, hay bằng cách của một trình tiền biên dịch Quá trình này thường chỉnh sửa chương trình rồi sau đó chương trình được biên dịch hoặc thông dịch lại

Hình 3.6 Mô hình phương pháp sinh mã Inline-Code

Ví dụ trong việc phát triển ứng dụng cho các nền tảng khác nhau (Windows, Linux), chúng ta chỉ muốn dùng một nền tảng mã nguồn để có thể biên dịch cho nhiều nền tảng đích, để làm được điều đó, ví dụ với ứng dụng viết bằng C/C++, chúng ta cần dùng các chỉ thị tiền biên dịch để khai báo thư viện cho nền tảng đích

Hiện nay, nhìn chung giải pháp cho nhu cầu sinh mã tự động là sử dụng bộ tạo mã dựa trên khuôn mẫu hướng mô hình (Model-driven Template-based Code-Generators) như đã trình bày ở mục 3.3.1 và mục 3.3.2 Kiến trúc bậc cao điển hình của hệ thống tạo mã hướng mô hình là dựa trên khuôn mẫu được mô tả cụ thể như sau:

25

Hình 3.7 Sinh mã dựa trên Template

Bộ tạo mã lấy thông tin từ mô hình (Models) và khuôn mẫu (Templates) làm đầu vào, sau đó chuyển đổi khuôn mẫu sang mã nguồn/chương trình (Programs)

Lợi thế của bộ sinh mã dựa trên khuôn mẫu hướng mô hình so với các dạng khác,

đó là người dùng có thể đặc tả được cả nội dung và định dạng của mã nguồn được sinh

ra Việc này mở rộng phạm vi phân loại các bộ tạo mã và giúp chúng phù hợp với phạm vi nhiệm vụ rộng hơn trong tiến trình phát triển Các thành phần lõi đặc trưng của một bộ tạo mã hướng mô hình dựa trên khuôn mẫu gồm các dạng mô hình nó sử dụng để tạo mã, các dạng ngôn ngữ nó dùng để mô tả chỉ thị trong khuôn mẫu và vòng đời của mã được tạo ra

3.4 Ngôn ngữ xây dựng Template trong các bộ sinh mã

Như mục 3.3 đã đề cập bộ sinh mã hướng mô hình dựa trên khuôn mẫu Vậy những dạng ngôn ngữ nào được sử dụng để mô tả các chỉ thị trong khuôn mẫu Mỗi ngôn ngữ thích hợp cho thành phần của các khuôn mẫu bảo đảm ngắn gọn, mạnh mẽ và sát với miền mà bộ tạo mã hướng tới Trong phần này sẽ mô tả, cũng như đưa ra những thuận lợi và bất lợi của các dạng ngôn ngữ khác nhau

3.4.1 Sử dụng ngôn ngữ

Sử dụng ngôn ngữ (Genneral – purpose language) cho việc định nghĩa khuôn mẫu, cung cấp cho lập trình viên những đặc điểm tính toán không giới hạn, nhưng nó cũng liên quan đến nguy cơ xuất hiện các lỗi logic trong khuôn mẫu, khi mà cú pháp của chúng phức tạp hơn Có hai loại ngôn ngữ dạng này là:

3.4.1.1 Ngôn ngữ định kiểu mạnh

Ngôn ngữ định kiểu mạnh (strongly type language) chính là những ngôn ngữ lập trình như C/C++, Java hoặc C# được dùng để xây dựng các khuôn mẫu (template) Việc sử dụng ngôn ngữ này cho phép lập trình viên xác định và giải quyết nhiều lỗi logic sử dụng phương pháp phân tích tĩnh Tuy nhiên, cú pháp của những ngôn ngữ như vậy liên quan nhiều đến việc ép kiểu, khai báo biến… sẽ làm tăng kích thước của khuôn mẫu và người phát triển sẽ mất nhiều thời gian để xây dựng khuôn mẫu

26

3.4.1.2 Ngôn ngữ định kiểu yếu

Những ngôn ngữ định kiểu yếu (Loosely Typed Languages ) là những ngôn ngữ lập trình không đặt nặng về kiểu như Pert, Php, hoặc các ngôn ngữ kịch bản khác Lập trình với các ngôn ngữ kịch bản như JavaScript hay VBScript làm cho lập trình viên giảm được công sức khai báo, ép kiểu và việc viết các khuôn mẫu trở nên nhỏ gọn và

dễ dàng hơn Tuy nhiên, việc sử dụng những ngôn ngữ như vậy làm cho sự xuất hiện lỗi khi chạy ở các khuôn mẫu thường xảy ra nhiều hơn, các lỗi cú pháp có thể chỉ được bắt gặp trong quá trình thông dịch, trong khi các lỗi khác sẽ chỉ được xác định trong lúc chạy ứng dụng

Sử dụng ngôn ngữ trong việc xây dựng các khuôn mẫu phục vụ cho các bộ sinh mã sau thực tế nhiều năm ứng dụng cho thấy rằng ngôn ngữ đánh máy không được trọng dụng như ngôn ngữ kịch bản (Php, Perl…) hay các dạng ngôn ngữ biến thể của ngôn ngữ định kiểu (như VBScript cho VB, Web Macro cho Java…)

3.4.2 Sử dụng ngôn ngữ chuyên biệt miền

DSL - Ngôn ngữ chuyên biệt miền (Domain-Specific Languages) được sử dụng để

mô tả hệ thống dưới các góc nhìn khác nhau Mỗi góc nhin là một miền và được mô tả bằng một mô hình Các mô hình này được định nghĩa bởi DSL Nội bản thân DSL có hai góc nhìn là cú pháp trừu tượng và cú pháp cụ thể Cú pháp trừu tượng là một metamodel định nghĩa các khái niệm và mối quan hệ giữa chúng trong một mô hình

Cú pháp cụ thể định nghĩa mức thể hiện vật lý giữa các khái niệm và mối quan hệ Hay nói cách khác ở góc nhìn cụ thể, các khái niệm và quan hệ được ánh xạ thành các biểu tượng thể hiện vật lý Cú pháp trừu tượng thể hiện bằng văn bản hoặc hình vẽ

Khuôn mẫu mà bộ tạo mã sử dụng được viết bằng ngôn ngữ DSL đơn giản là chỉ

áp dụng cho miền ứng dụng (ví dụ SQL cho CSDL, HTML cho Web) Ngôn ngữ như vậy thường gồm các đặc điểm cho sự lặp đi lặp lại và không cung cấp các tính năng cao hơn như tính toán Lợi thế của những ngôn ngữ này là dễ học, khi chúng thường gồm một số ít khái niệm và sự diễn tả liên quan tới miền ứng dụng Hơn nữa, vì sự đơn giản, xác suất lỗi logic trong khuôn mẫu giảm đi Hạn chế quan trọng nhất là thiếu sự

mở rộng, sự thừa kế trong những ngôn ngữ như vậy

3.4.3 Sử dụng ngôn ngữ chuyển đổi mô hình chuyên dụng

Đối với việc sinh mã hướng mô hình, thì trong những năm gần đây dạng ngôn ngữ dùng cho chuyển đổi mô hình sang văn bản, được sử dụng nhiều bởi các hãng hay các

dự án mã nguồn mở, có thể hoặc là biến thể của ngôn ngữ định kiểu, hoặc ngôn ngữ chuyên biệt miền Tuy nhiên chưa có một chuẩn chung nào được sử dụng cho tất cả các dự án, mà mỗi dự án tự sáng tạo và áp dụng theo mục đích riêng của mình, nhưng nhìn chung thì những dạng ngôn ngữ này đều được sử dụng với phương pháp chuyển

27

đổi dựa theo khuôn mẫu hướng mô hình đã đề cập ở các phần trước Một số loại ngôn ngữ chuyển đổi từ mô hình sang văn bản đang được áp dụng được trình bày như dưới đây

3.4.3.1 JET (Java Emitter Templates)

JET là công cụ mã nguồn mở Nó cung cấp một khung làm việc (framework) và các tiện ích cho việc sinh mã Các file khuôn mẫu dạng JSP được sử dụng và những người mà đã quen thuộc với công nghệ JSP dễ dàng học và sử dụng Nó cũng dễ mở rộng với các thẻ (tag) tuỳ biến giống như với JSP

JET cũng được hỗ trợ mạnh bởi các công cụ được tích hợp trong Eclipse Một dự

án chuyển đổi cụ thể có thể được tạo trong Eclipse IDE và cung cấp các file cần thiết Ngoài ra, một trình soạn thảo riêng cho JET và cấu hình triển khai để bắt đầu chuyển đổi cũng được cung cấp

Mặc định JET yêu cầu file XML là đầu vào, file XML này không nhất thiết là một dạng XML cụ thể nào, và không liên quan đến mô hình hoá phần mềm Xpath là ngôn ngữ được sử dụng để truy cập các nốt (nodes) khác nhau trong file nguồn XML, và điều hướng chúng giữa các thành phần Xpath cũng là một ngôn ngữ phạm vi rộng được biết đến bởi rất nhiều lập trình viên (xem Hình 3.8)

Hình 3.8 JET Engine Khi mà khuôn mẫu JET (*.jet) được phát triển và được lưu trong trình soạn thảo JET (Editor, Designer) thì một lớp Java (*.class) được sinh ra bên ngoài nó (xem Hình 3.9) Lớp khuôn mẫu (*.class) này có thể được gọi trực tiếp bởi mã nguồn Java khác (main() program) Vì vậy có thể lập trình một bộ phân tích cú pháp (parser) chuẩn bị cho mô hình nguồn được chuyển đổi bởi lớp khuôn mẫu JET

Sự chuyển đổi có thể được xem như là kế hoạch chi tiết được áp dụng cho mô hình nguồn Mô hình nguồn đôi khi chỉ được gọi qua một tập các tham số, bởi vì nó định nghĩa giá trị được sử dụng khi mà kế hoạch chi tiết được áp dụng Một sự chuyển đổi JET có thể được minh hoạ như sau: Tham số + Kế hoạch = Các yếu tố mong muốn

28

Hình 3.9 Quy trình chuyển đổi của JET Như đã phân tích ở trên thì chúng ta có thể thấy rằng JET là một bộ sinh (engine) dựa trên nền tảng công nghệ sẵn có, nó dễ dàng được học bởi các lập trình viên đã quen với các công nghệ như JSP Một dự án chuyển đổi cũng dễ dàng được thiết lập trong thời gian ngắn

Tuy nhiên JET cũng có những hạn chế, đó là với MDSD nó không hỗ trợ việc phân tích miền cụ thể, đơn cử là không thể kiểm tra được khuôn mẫu khi mà khuôn mẫu được lưu bởi trình soạn thảo JET, điều này không được như trình soạn thảo Xpand Vì vậy mà đối với những dự án lớn đòi hỏi việc xử lý nhiều mô hình phức tạp thì sẽ trở nên khó khăn cho JET khi mà không có công cụ hỗ trợ mở rộng cho miền cụ thể Xây dựng chuyển đổi dựa theo JET trong Eclipse liên quan đến nhiều kiến thức khác mà lập trình viên phải thực sự hiểu như Eclipse Resource và UI API, đây cũng là một hạn chế cho việc tạo chuyển đổi Mặt khác, JET cũng chỉ hỗ trợ sinh mã Java, hạn chế mở rộng cho các nền tảng khác

3.4.3.2 Xpand

Ngôn ngữ Xpand [24] được phát triển như là một phần của dự án openArchitecture-Ware (oAW) dùng cho việc chuyển đổi gồm cả từ mô hình sang mô hình và mô hình sang văn bản Xpand là một dạng của ngôn ngữ chuyên biệt miền Các khuôn mẫu xây dựng trên ngôn ngữ này được sử dụng bởi bộ sinh mã là một phần của luồng phát triển của nền tảng oAW (xem Hình 3.10) Xpand là độc lập với các dạng mô hình Các mô hình nguồn khác nhau được xử lý bởi một bộ phân tích cú pháp (parser) mà được liên kết tới luồng xử lý của oAW Bộ phân tích cú pháp có thể được viết cho bất kỳ mô hình nguồn nào và nền tảng oAW có thể cung cấp bộ phân tích cú pháp ngoài luồng cho các mô hình đầu vào được xây dựng bởi nhiều nền tảng khác nhau