Sinh mã tự động trong 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, rồi từ đó chuyển đổi tự động sang các mô đun, mã nguồn, hay chương trìn

ĐẠI HỌC QUỐC GIA HÀ NỘI

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

ĐẠI HỌC QUỐC GIA HÀ NỘI

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

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

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

Hà Nội – 2014

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 dưới

sự hướng dẫn khoa học của TS Đặng Đức Hạnh

Nội dung nghiên cứu và kết quả nêu trong luận văn là hoàn toàn trung thực, được tôi tổng hợp, bổ sung và biên soạn theo sự hiểu biết của mình sau khi nghiên cứu được

từ các tài liệu tham khảo như sách, bài báo khoa học, luận văn, và dữ liệu từ các trang Web uy tín

Hà nội, tháng 6, năm 2014

Học viên

(ký và ghi rõ họ tên)

LỜI CẢM ƠN

Lời đầu tiên, tôi muốn dành 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ệ - ĐHQGHN, người đã trực tiếp định hướng và hướng dẫn tôi hoàn thành luận văn này Từ những ngày đầu còn bỡ ngỡ với lĩnh vực nghiên cứu mới, tôi

đã được Thầy tận tình quan tâm, hướng dẫn để tiếp cận nhanh với công nghệ mới

Và bây giờ, sau khi đã trải qua giai đoạn nghiên cứu, tôi cũng đã thu được những kiến thức nhất định được đúc kết trong luận văn này

Ngoài ra, trong khoảng thời gian học tập và nghiên cứu tại Trường Đại học Công nghệ – ĐHQGHN, với sự giảng dạy và giúp đỡ của các Thầy/Cô và các bạn học viên, tôi đã học được rất nhiều bổ ích và lý thú Ngoài những kiến thức về lĩnh vực Công nghệ Thông tin mà tôi thu lượm được, điều tôi tâm đắc nhất đó là khả năng

tư duy, phân tích, tổng hợp các vấn đề một cách khoa học từ Thầy/Cô và các bạn Điều đó không những giúp ích cho tôi trong việc xử lý tốt hơn các công việc hàng ngày, mà còn giúp tôi nâng cao khả năng nghiên cứu Tự đáy lòng mình, tôi xin gửi lời cảm ơn chân thành nhất tới các Thầy/Cô và các bạn Tôi cũng xin gửi lời cảm ơn tới gia đình mình đã luôn luôn động viên tôi hoàn thành tốt nhiệm vụ học tập được giao

Do lĩnh vực nghiên cứu được đề cập trong luận văn còn mới lạ, chưa được ứng dụng rộng rãi, và vẫn còn đang trong giai đoạn phát triển, cho nên tôi đã gặp không ít khó khăn trong việc nghiên cứu Giới hạn về thời gian cũng là vấn đề khiến tôi chưa tập trung hết tâm huyết để khai thác các vấn đề chuyên sâu hơn nữa trong lĩnh vực này Vì vậy mà chắc chắn luận văn sẽ còn nhiều điều thiếu sót, và rất mong nhận được ý kiến đóng góp quý báu của các Thầy/Cô và bạn đọc quan tâm Mọi ý kiến đóng góp xin vui lòng gửi về địa chỉ thư điện tử: lamdn84@gmail.com

Xin chân thành cảm ơn

Học viên

Dương Ngọc Lâm

MỤC LỤC

LỜI CAM ĐOAN ii

LỜI CẢM ƠN iii

MỤC LỤC iv

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

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

DANH MỤC CÁC BẢNG BIỂU xii

MỞ ĐẦU xiii

CHƯƠNG 1 TỔNG QUAN CÔNG NGHỆ PHÁT TRIỂN HƯỚNG MÔ HÌNH 1

1.1 Giới thiệu 1

1.2 Ứng dụng MDA trong quy trình phát triển phần mềm 2

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

1.2.2 Phát triển phần mềm theo phương pháp hướng mô hình (MDD) 4

1.2.3 Những thuận lợi của kiến trúc hướng mô hình (MDA) 5

1.2.3.1 Chất lượng sản phẩm 5

1.2.3.2 Khả năng tương thích 5

1.2.3.3 Khả năng tương tác 5

1.2.3.4 Bảo trì và Tư liệu 6

1.3 Cơ bản về MDA 6

1.3.1 Mô hình (model) là gì? 7

1.3.2 Meta-model 7

1.3.3 Chuyển đổi mô hình 8

1.3.4 Các đặc điểm mong muốn của sự chuyển đổi 9

1.3.4.1 Khả năng truy tìm nguồn gốc 9

1.3.4.2 Tính nhất quán gia tăng 10

1.3.4.3 Tính hai chiều 10

1.3.5 Mô hình bốn lớp của MDA 10

1.3.6 Ví dụ về MOF 12

1.4 Các tiêu chuẩn của OMG được sử dụng với MDA 14

1.4.1 MOF (Meta-Object Facility) 14

1.4.2 UML (Unified Modeling Language) 14

1.4.3 OCL (Object Contraint Language) 14

1.4.4 CWM (Common Warehouse MetaModel) 15

1.4.5 UML Profile 15

1.4.6 XMI (XML Metadata Interchange) 16

1.4.7 JMI (Java Metadata Interchange) 16

1.5 Tổng kết chương 17

CHƯƠNG 2 KHẢO SÁT KHẢ NĂNG SINH MÃ TỰ ĐỘNG TRONG MDD 18

2.1 Giới thiệu 18

2.2 Các bộ sinh mã hướng mô hình 19

2.2.1 Sử dụng Khuôn mẫu và Bộ lọc (Template and Filtering) 20

2.2.2 Sử dụng Khuôn mẫu và Meta-Model (Template and Meta-Model) 21

2.2.3 Sử dụng Bộ sinh dựa trên API (API-based Generator) 22

2.2.4 Sử dụng Sinh mã nội tuyến (Inline Code Generation) 22

2.3 Công cụ chuyển đổi mô hình 24

2.3.1 EMF (Eclipse Modeling Framework) 24

2.3.2 MDR (Metadata Repository) 25

2.3.3 AndroMDA 26

2.3.4 OptimalJ 26

2.3.5 ArcStyler 27

2.4 Khuôn mẫu (Templates) 27

2.4.1 Ngôn ngữ mục đích chung (General-Purpose Languages) 27

2.4.1.1 Ngôn ngữ đánh máy (Strongly Typed Languages) 27

2.4.1.2 Ngôn ngữ kịch bản (Loosely Typed Languages - Scripting) 28

2.4.2 Ngôn ngữ phụ thuộc miền (Domain-Specific Languages) 28

2.4.3 Ngôn ngữ chuyển đổi mô hình sang văn bản 28

2.4.3.1 Xpand 28

2.4.3.2 MOF Model to Text (MOFM2T) 30

2.4.3.3 JET (Java Emitter Templates) 33

2.5 Những lợi ích của việc sinh mã hướng mô hình 36

2.5.1 Chất lượng 36

2.5.2 Sự nhất quán 36

2.5.3 Sự linh hoạt 37

2.5.4 Tính di động 37

2.5.5 Phân tách các khía cạnh 38

2.5.6 Tốc độ phát triển 38

2.5.7 Tăng thời gian phân bổ cho các pha chính 38

2.6 Rủi ro từ việc áp dụng sinh mã 39

2.6.1 Phần mềm không phù hợp cho việc sinh mã 39

2.6.2 Chất lượng của phần mềm sinh mã kém 39

2.7 Tổng kết chương 39

CHƯƠNG 3 CÔNG NGHỆ WEB HƯỚNG MÔ HÌNH 41

3.1 Giới thiệu 41

3.1.1 Phương pháp tiếp cận 42

3.1.2 Phân tách các khía cạnh 44

3.1.3 Môi trường chuyển đổi 45

3.2 Công nghệ Web hướng mô hình UWE 46

3.2.1 Tổng quan về UWE 46

3.2.2 Các phương pháp khác trong MDWE so sánh với UWE 48

3.2.2.1 WebML 49

3.2.2.2 Object-Oriented Hypermedia (OO-H) 49

3.2.2.3 Object-Oriented Web Solution (OOWS) 49

3.3 Tự động sinh mã trong UWE4JSF 50

3.3.1 Tổng quan về UWE4JSF 50

3.3.2 Chuyển đổi mô hình và cơ chế thẩm định mô hình trong UWE4JSF 52

3.3.2.1 Chuyển đổi mô hình UML2UWE 53

3.3.2.2 Cơ chế thẩm định của UWE4JSF 55

3.3.2.3 Chuyển đổi mô hình sang mô hình UWE2JSF 56

3.3.2.4 UWE4JSF Meta-model 58

3.3.2.5 Chuyển đổi mô hình sang văn bản trong UWE4JSF 59

3.3.3 Cấu trúc của ứng dụng UWE4JSF 63

3.4 Tổng kết chương 65

CHƯƠNG 4 THỰC NGHIỆM VỚI UWE4JSF 66

4.1 Giới thiệu 66

4.2 Đặc tả yêu cầu 66

4.2.1 Biểu đồ ca sử dụng (Use Case Diagram) 67

4.2.2 Biểu đồ hoạt động (Activity Diagram) 67

4.3 Thiết kế mô hình 69

4.3.1 Mô hình nội dung (Content) 69

4.3.2 Mô hình điều hướng (Navigation) 69

4.3.3 Mô hình xử lý (Process) 71

4.3.3.1 AddContact 71

4.3.3.2 EditContact 72

4.3.3.3 DeleteContact 72

4.3.3.4 Login 73

4.3.3.5 Logout 73

4.3.3.6 Register 74

4.3.4 Mô hình biểu diễn (Presentation) 74

4.3.4.1 Giao diện tổng thể 76

4.3.4.2 MainMenu 77

4.3.4.3 ContactDataInput 77

4.3.4.4 CustomerInfo 78

4.3.4.5 Contact 79

4.3.4.6 Giao diện nhập liệu 80

4.3.4.7 Concrete Presentation Model 81

4.4 Thực hiện sinh mã 81

4.5 Đánh giá kết quả 81

4.6 Tổng kết chương 84

KẾT LUẬN 85

TÀI LIỆU THAM KHẢO 86

PHỤ LỤC 88

Phụ Lục A Các plug-in của công cụ UWE4JSF 88

Phụ Lục B Thực hành với MagicUWE 91 Phụ Lục C Thực hành chuyển đổi với Eclipse IDE 92

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

BPEL Business Process Execution Language

ID Identification

LMU Ludwig-Maximilians-Universität München

Chữ viết tắt Chú giải

MVC Model-View-Controller

XSTL eXtensible Stylesheet Language Transformations

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

Hình 1.2: Phương pháp phát triển phần mềm truyền thống 3

Hình 1.3: Ứng dụng MDA vào quy trình phát triển phần mềm 4

Hình 1.4: Khả năng tương tác sử dụng các cầu nối trong MDA Nguồn [4, mục 1.3.3] 5

Hình 1.5: Mô hình được viết bởi ngôn ngữ và mô tả hệ thống Nguồn [4, mục 2.1] 7

Hình 1.8: Định nghĩa chuyển đổi bên trong công cụ chuyển đổi Nguồn [4, mục 2.3] 9

Hình 2.14: Sinh mã dựa trên Khuôn mẫu và Bộ lọc 20

Hình 2.17: Sinh mã nội tuyến 22

Hình 3.26: Phân tách các chuyển đổi từ PIM sang PSM Nguồn từ Chương 3, tài liệu [3] 45

Hình 3.29: Chuyển đổi mô hình theo các khía cạnh Trích dẫn từ Chương 1 của [3] 48

Hình 3.34: Các thành phần mô hình tiêu chuẩn JSF của mô hình biểu diễn cụ thể 58

Hình 4.40 Biểu đồ lớp thể hiện mô hình điều hướng 70

Hình 4.48 Giao diện tổng thể của một trang Web được thể hiện qua mô hình biểu diễn 76

Hình 4.54 Mô hình biểu diễn cụ thể 81 Hình 4.55: Số dòng lệnh *.java ở thư mục /src 82

Hình 4.56: Số dòng lệnh *.jsp ở thư mục /WebContent 82

Hình Phụ Lục B.5: Xuất dữ liệu làm đầu vào cho công cụ chuyển đổi 91

Hình Phụ Lục C.9: Bổ sung mã nguồn 95

DANH MỤC CÁC BẢNG BIỂU

Bảng 4.1: Các khuôn mẫu được sử dụng trong biểu đồ hoạt động 67 Bảng 4.2: Các khuôn mẫu được sử dụng trong mô hình điều hướng 69 Bảng 4.3: Các khuôn mẫu được sử dụng trong mô hình biểu diễn 74

MỞ ĐẦU

Công nghệ phầm mềm luôn là điều gì đó ám ảnh các nhà khoa học, thúc đẩy họ phải luôn tìm tòi, sáng tạo ra những cách thức mới để nâng cao chất lượng của sản phẩm phần mềm Nhìn lại quá khứ từ khi máy tính ra đời cho đến ngày nay thì có thể thấy ngôn ngữ máy tính cũng đã phát triển qua nhiều thế hệ từ hợp ngữ, đến ngôn ngữ thủ tục, đến ngôn ngữ hướng đối tượng, và bây giờ là ngôn ngữ mô hình hoá Cùng với sự phát triển của ngôn ngữ, thì các phương pháp phát triển tương ứng với chúng cũng ra đời nhằm giải quyết bài toán chất lượng phần mềm, như phương pháp hướng đối tượng, phương pháp hướng thành phần, phương pháp hướng khía cạnh, vân vân Có một điều rất dễ nhận thấy đó là mức độ trừu tượng, tính

kế thừa của các ngôn ngữ, của các phương pháp đều phát triển theo hướng tăng dần Tại sao lại như vậy? Nguyên nhân chính, đơn giản đến từ những điều rất tự nhiên trong cuộc sống Đó là nhu cầu của con người

Công nghệ phát triển ngày càng hiện đại với nhiều nền tảng mới ra đời, cùng với nhu cầu ngày càng lớn của người dùng internet khiến cho các nhà phát triển phải xây dựng các hệ thống lớn có nhiều tính năng để đáp ứng nhu cầu đó, cũng như làm tăng sự trải nghiệm của người dùng Rồi nhu cầu mới lại được đưa ra một cách nhanh chóng, và các phiên bản phần mềm mới lại ra đời sao cho có thể hoạt động tốt được trên nền tảng mới Việc này thực tế gây ra rất nhiều phiền toái cho các nhà phát triển với các vấn đề quản lý, duy trì phần mềm một cách thủ công nếu họ vẫn áp dụng phương pháp phát triển cũ Nỗ lực và thời gian tiêu tốn cho việc duy trì đó là rất lớn Không có cách giải quyết nào tốt hơn là phải áp dụng các phương pháp phát triển mới vào quy trình phát triển phần mền

Để giải quyết nhu cầu người dùng một cách nhanh chóng, các nhà phát triển thường phải tập trung vào khâu phân tích các vấn đề ở giai đoạn đầu của dự án,

và cách tốt nhất để diễn đạt ý tưởng cho những bộ phận liên quan có chuyên môn khác nhau, là qua việc mô hình hoá các khía cạnh của phần mềm bằng ngôn ngữ mô hình hoá 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, rồi từ đó chuyển đổi tự động sang các

mô đun, mã nguồn, hay chương trình có thể thực thi được bằng các công cụ chuyển đổi Hiện tại, phương pháp phát triển này đang được áp dụng bởi rất nhiều

tổ chức vì nó đã giải quyết được rất nhiều vấn đề ở cả khía cạnh người dùng và khía cạnh người phát triển, và được xem như là thế hệ phát triển tiếp theo trong lĩnh vực công nghệ phần mềm

Ở một góc độ khác, trong thời buổi hội nhập kinh tế thế giới hiện nay, các công ty, tổ chức cạnh tranh nhau khốc liệt nhằm giành chỗ đứng trên thị trường, để khẳng định thương hiệu của mình bằng cách cung cấp các sản phẩm có chất lượng tốt hơn với giá cả rẻ hơn đối thủ Để thực hiện điều đó không có cách nào khác là phải

ứng dụng công nghệ mới vào quy trình sản xuất kinh doanh của mình, làm tăng năng suất sản phẩm, giảm thiểu sức lao động của con người Tất cả những điều nêu

trên là động lực thúc đẩy tôi lựa chọn đề tài nghiên cứu “Sinh mã tự động trong

phát triển phần mềm hướng mô hình”

Luận văn được cấu trúc như sau:

Chương 1: Tổng quan về công nghệ phát triển hướng mô hình (MDD/MDE) nói chung

và công nghệ phát triển phần mềm hướng mô hình nói riêng (MDSD/MDSE) Chương này cũng đề cập đến phương pháp phát triển sử dụng kiến trúc đang được áp dụng rộng rãi bởi các tổ chức hiện nay, đó là kiến trúc hướng mô hình MDA

Chương 2: Tập trung vào khảo sát khả năng sinh mã tự động (Code Generation) khi chuyển đổi giữa các mô hình trong phát triển phần mềm hướng mô hình Đi sâu vào nghiên cứu các phương pháp chuyển đổi từ mô hình sang văn bản (mã nguồn, tài liệu),

sử dụng các ngôn ngữ chuyển đổi và công cụ khuyển đổi khác nhau Tùy vào từng ứng dụng cụ thể mà có thể sử dụng các phương pháp khác nhau, phân tích ưu điểm, nhược điểm của từng phương pháp

Chương 3: Giới hạn phạm vi nghiên cứu qua việc phân tích công nghệ phát triển ứng dụng Web hướng mô hình (MDWD/MDWE) nói chung, đi sâu vào nghiên cứu khả năng sinh mã tự động với công nghệ Web hướng mô hình dựa trên UML (UWE) nói riêng, trong đó tập trung vào công cụ UWE4JSF

Chương 4: Thực nghiệm với UWE4JSF bằng cách xây dựng một ứng dụng đơn giản nhằm đánh giá khả năng sinh mã của công cụ này

CHƯƠNG 1 TỔNG QUAN CÔNG NGHỆ PHÁT TRIỂN

HƯỚNG MÔ HÌNH

Chương này luận văn sẽ đề cập một cách khái quát về Công nghệ phát triển hướng mô hình (MDD), trong đó luận văn sẽ giới hạn phạm vi nghiên cứu trong lĩnh vực phát triển phần mềm (MDSD) Ngoài ra luận văn cũng đề cập đến lý thuyết

cơ bản về kiến trúc hướng mô hình (MDA) và những lợi thế của phương pháp phát triển phần mềm sử dụng kiến trúc này so với phương pháp truyền thống

1.1 Giới thiệu

Tiếp tục với vấn đề được đề cập trong Phần Mở Đầu, khi các nhà phát triển đang đối mặt với nhiều vấn đề về sự phát triển nhanh chóng và ngày càng phức tạp của các nền tảng công nghệ mới Do đó, họ phải dành nhiều công sức và thời gian để tuỳ biến ứng dụng (thường theo cách thủ công là sửa mã nguồn) sao cho có thể hoạt động được trên các nền tảng khác nhau

Công nghệ hướng mô hình (MDE) là phương pháp tiếp cận mới giải quyết được

sự phức tạp của các nền tảng khác nhau bằng cách tập trung vào diễn tả khía cạnh miền ứng dụng một cách hiệu quả MDE hướng tới việc sử dụng các mô hình (models) như là tác nhân chính trong toàn bộ vòng đời phát triển của ứng dụng Và do đó, ở khía cạnh này nó cũng đồng nghĩa với thuật ngữ Phát triển hướng mô hình (MDD), và chúng ta có thể ngầm hiểu rằng khi nhắc đến MDE hay MDD là ta đang nói về

“Công nghệ phát triển hướng mô hình” MDD phát triển dựa trên ý tưởng về môi trường quản lý mô hình phần mềm có tính tự động hoá cao Nghĩa là nó không bị phụ thuộc vào các nền tảng, và khi có nền tảng mới ra đời thì sự tự động hoá đó sẽ phát huy tác dụng, ứng dụng mới sẽ được chuyển đổi tự động từ các mô hình để tương thích với nền tảng mới Điều đó làm tăng năng suất và thời gian phân phối sản phẩm

Ngày nay, MDD không chỉ được ứng dụng trong lĩnh vực phần mềm mà còn ở những lĩnh vực khác như phần cứng [6] (mô hình các mạch điện tử để tạo các mạch vật lý ngoài sự can thiệp của con người), các hệ thống nhúng [10] Phạm vi nghiên cứu được đề cập trong luận văn là lĩnh vực phần mềm, tương ứng với thuật ngữ

“Công nghệ phát triển phần mềm hướng mô hình” (MDSE hay MDSD) Tiếp đó, ở Chương 3 luận văn sẽ trình bày phạm vi cụ thể hơn là miền ứng dụng Web (MDWE) với các phương pháp phát triển Web hướng mô hình, mà trọng tâm là phương pháp UWE

Hình 1.1: Tập hợp miền ứng dụng và phương pháp trong MDD

Như đã trình bày, mô hình (model) là điểm mấu chốt mà các phương pháp tiếp cận trong MDD hướng tới Trong đó mô hình phần mềm có thể được phân loại thành phi cấu trúc và cấu trúc [6], ví dụ mô hình phi cấu trúc như các mô tả bằng ngôn ngữ tự nhiên, các hình vẽ bằng công cụ đồ hoạ máy tính; mô hình cấu trúc thì có tập hợp các thành phần được định nghĩa trước và các quy tắc mà chúng tuân theo Các quy tắc này có thể ở dạng phi hình thức (informally) hay dạng hình thức (formally) Các quy tắc được cung cấp dưới dạng hình thức được gọi là meta-model hay domain-specific language (DSL- ngôn ngữ phụ thuộc miền) hay modeling language (ngôn ngữ

mô hình hoá), và được sử dụng bởi các phương pháp mô hình hoá khác nhau

Trên thị trường hiện tại có nhiều kiến trúc hướng mô hình (xem Hình 1.1) mà MDD tuân theo như MDA (chuẩn hoá bởi OMG sử dụng MOF), Software Factories1(phát triển bởi Microsoft sử dụng DSL), EMF (được tích hợp với Eclipse sử dụng Ecore), DSM (sử dụng DSL, phát triển bởi MetaCase2 với công cụ MetaEdit+), vân vân Tuy nhiên, ở Chương này luận văn chỉ tập trung vào phân tích kiến trúc MDA Kiến trúc tương tự với MDA, chỉ khác biệt một số điểm là EMF sẽ được đề cập

ở Chương 2 Cả hai kiến trúc này đang được áp dụng rộng rãi bởi nhiều tổ chức hiện nay

1.2 Ứng dụng MDA trong quy trình phát triển phần mềm

Mục này sẽ giải thích tại sao MDA có thể khắc phục được những nhược điểm mà các phương pháp truyền thống đang gặp phải Về mặt bản chất, MDA không phải là quy trình phát triển phần mềm, và tư tưởng của MDA có thể áp dụng cho bất kỳ quy trình nào Cụ thể chúng ta sẽ so sánh phương pháp sử dụng MDA với phương pháp phát triển truyền thống trong quy trình phát triển theo mô hình thác nước

1 http://www.softwarefactories.com/TheBook.html

2 https://metacase.com/

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

Đối với việc xây dựng những hệ thống nhỏ, ít tốn kém thì việc áp dụng các phương pháp truyền thống vẫn còn hữu dụng, tuy nhiên đối với việc xây dựng những

hệ thống lớn, đòi hỏi phải đáp ứng nhiều tính năng từ phía người dùng, thì việc

áp dụng các phương pháp này về lâu về dài sẽ gây nhiều khó khăn cho nhà phát triển

để đáp ứng nhanh nhu cầu của người dùng, thời gian hạn hẹp sẽ khiến nhà phát triển sao nhãng phần thiết kế, do đó khoảng cách giữa pha thiết kế và pha lập trình ngày càng lớn, tầm quan trọng của pha thiết kế sẽ giảm dần theo thời gian Tuy việc cập nhật tài liệu sau khi lập trình có thể được giải quyết bằng các công cụ tạo tài liệu

từ mã nguồn, tuy nhiên nó cũng chỉ giải quyết được việc thiết kế ở mức thấp, còn ở mức trừu tượng cao hơn như biểu diễn bằng các biểu đồ, ý nghĩa của nó thì các công cụ này không giải quyết được Điều này sẽ gây nhiều khó khăn cho việc kiểm thử, vận hành, bảo trì hệ thống sau này khi tài liệu thiết kế không được cập nhật đầy đủ

Ngoài vấn đề về thiết kế trên thì mô hình truyền thống này còn phải đối mặt với vấn đề khả năng tương thích ngược Vì các công nghệ mới được phát minh theo

thời gian một cách nhanh chóng nhằm đáp ứng các yêu cầu ngày một đa dạng của người dùng, để giải quyết những vấn đề tồn đọng trước đó, buộc các nhà phát triển phần mềm cũng phải chạy đua theo để không bị lạc hậu Như vậy những phiên bản phần mềm mới có thể không tương thích với các công nghệ cũ, nền tảng cũ đã được dùng bởi mô hình truyền thống.

1.2.2 Phát triển phần mềm theo phương pháp hướng mô hình (MDD)

Phương pháp phát triển phần mềm hướng mô hình (MDSD) ít nhiều giải quyết được những vấn đề nêu trên Khi ứng dụng MDA vào quy trình phát triển theo

mô hình thác nước, bản chất ở mỗi pha của quy trình là tài liệu được thể hiện ở dạng

mô hình, và vì các mô hình này là mô hình hình thức (formal model) nên chúng có thể được hiểu bởi máy tính và được xử lý tự động

Hình 1.3: Ứng dụng MDA vào quy trình phát triển phần mềm

Các mô hình được sử dụng bởi các công cụ chuyển đổi tự động từ nhiều nhà phát triển khác nhau để tạo ra các lược đồ (schemas), khung mã nguồn (code skeletons), mã tích hợp (integration code), và kịch bản triển khai (deployment scripts) cho nhiều nền tảng khác nhau được sử dụng trong một dự án

MDA định nghĩa mô hình độc lập nền (PIM), mô hình phụ thuộc nền (PSM),

mô hình văn bản (Text), và cũng định nghĩa cách chúng liên kết với nhau Một PIM được tạo ra, sau đó được chuyển đổi sang một hoặc nhiều PSM, để rồi được chuyển sang Text

1.2.3 Những thuận lợi của kiến trúc hướng mô hình (MDA)

1.2.3.1 Chất lượng sản phẩm

Điểm mấu chốt là người phát triển chú trọng vào việc phát triển PIM, vì vậy mà

họ có thể làm việc một cách độc lập mà không phụ thuộc vào nền tảng đích, và có nhiều vấn đề kỹ thuật mà họ không cần quan tâm tới Những vấn đề này sẽ tự động thêm vào bởi việc chuyển đổi từ PIM sang PSM, do đó nó sẽ cải thiện năng suất theo hai cách:

 Người phát triển PIM sẽ làm ít việc hơn vì những chi tiết về nền tảng đích không cần được thiết kế Tại mức mô hình PSM và Text (mã nguồn) sẽ được viết ít hơn vì lượng lớn mã nguồn được sinh tự động từ PIM, PSM

 Người phát triển có thể chuyển từ việc chú trọng vào viết mã nguồn sang việc thiết kế PIM, do đó họ sẽ để ý nhiều hơn việc giải quyết các vấn đề nghiệp vụ tại thời điểm đầu thiết kế, hay bảo trì nâng cấp phần mềm sau này, dẫn đến

hệ thống sẽ phù hợp nhiều hơn với nhu cầu của người dùng, và người dùng cũng sẽ có được những tính năng tốt hơn trong khoảng thời gian ngắn hơn

1.2.3.2 Khả năng tương thích

Ngoài ra 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 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 công nghệ mới được phát minh trong tương lai, thì các tổ chức/công ty phần mềm cần cung cấp 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)

First transformation

Second transformation

Second

transformation

Hình 1.4: Khả năng tương tác sử dụng các cầu nối trong MDA Nguồn [4, mục 1.3.3]

Khi PSM được nhắm vào các nền tảng khác nhau, chúng không thể nói chuyện 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 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

Nếu chúng ta có thể chuyển đổi một PIM thành hai PSM được nhắm tới hai nền tảng, 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

Ví dụ, lấy một PSM là mô hình (mã nguồn) Java và một PSM khác là mô hình

cơ sở dữ liệu quan hệ Với một thành phần Customer trong PIM, ta biết lớp Java nào

mà thành phần này được chuyển đổi thành Ta cũng biết bảng nào (CSDL) mà

thành phần Customer này được chuyển đổi thành Xây dựng một cầu nối giữa một

đối tượng Java trong PSM và một bảng trong PSM là điều dễ dàng Để lấy một

đối tượng từ CSDL, ta truy vấn bảng đã được chuyển đổi từ Customer, và khởi tạo lớp

từ PSM còn lại (Java) với dữ liệu lấy được từ bước truy vấn trước Để lưu trữ một

đối tượng, ta tìm dữ liệu trong đối tượng Java và lưu nó vào bảng Customer Việc

ánh xạ giữa đối tượng Java và đối tượng cơ sở dữ liệu quan hệ là yếu tố cơ bản cho việc xây dựng các công nghệ quản lý dữ liệu như Hibernate3 mà không cần truy vấn trực tiếp vào CSDL Công nghệ này được sử dụng trong công cụ UWE4JSF sẽ được

đề cập ở Chương 3

1.2.3.4 Bảo trì và Tư liệu

Việc tập trung vào thiết kế sẽ dễ dàng cho các pha vận hành bảo trì sau này Khâu kiểm thử cũng sẽ nhẹ nhàng hơn nhiều vì lượng lớn mã nguồn được sinh tự động nên sẽ gặp ít lỗi hơn

1.3 Cơ bản về MDA

Ở mục 1.2, chúng ta đã đề cập một cách khái quát các thành phần cần có trong MDA như các mô hình (PIM, PSM, Text), mối quan hệ giữa các mô hình, các công cụ chuyển đổi, các bước chuyển đổi, vân vân Mục này sẽ trình bày chi tiết hơn về

lý thuyết từ những vấn đề cơ bản đến nâng cao, giúp cho độc giả có cái nhìn sâu hơn

về MDA

3 http://en.wikipedia.org/wiki/Hibernate_(Java)

1.3.1 Mô hình (model) là gì?

Một mô hình luôn luôn là một sự trừu tượng của vấn đề gì đó tồn tại trong thực tế Đối với mô hình phần mềm, nó luôn được viết bởi một ngôn ngữ, có thể là UML, một ngôn ngữ lập trình, hoặc bất kỳ một ngôn ngữ nào khác mà chúng ta nghĩ tới Để cho phép việc chuyển đổi tự động của một mô hình, các mô hình phải được viết bởi một ngôn ngữ hình thức (well-defined) Ngôn ngữ này có thể được hiểu và biên dịch một cách tự động bởi máy tính Ví dụ, trong MDA mã nguồn cũng là một

mô hình, vì nó được viết bởi ngôn ngữ lập trình có thể được hiểu bởi một trình biên dịch, và nó mô tả hệ thống Chúng ta có định nghĩa về mô hình (tham khảo [4]) như

sau:

“Một mô hình là một mô tả của (hoặc một phần của) một hệ thống được viết bởi một ngôn ngữ hình thức.”

“Một ngôn ngữ hình thức là một ngôn ngữ với mẫu được xác định rõ ràng, và

ý nghĩa phù hợp với việc biên dịch tự động bởi máy tính.”

Hình 1.5: Mô hình được viết bởi ngôn ngữ và mô tả hệ thống Nguồn [4, mục 2.1]

1.3.2 Meta-model

Cũng theo tài liệu [4] một meta-model cũng là một mô hình nhưng ở mức trừu tượng cao hơn vì nó biểu diễn mô hình, một meta-model chính nó phải được viết bằng ngôn ngữ hình thức (well-defined) Ngôn ngữ này được gọi là meta-language

Hình 1.6: Meta-model Như vậy, một meta-language cũng là một ngôn ngữ cụ thể mô tả ngôn ngữ

mô hình (modeling language)

Hình 1.7: Meta-language

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

Một công cụ chuyển đổi lấy một PIM và chuyển đổi nó thành một PSM Một công cụ chuyển đổi khác chuyển đổi PSM thành Text (Code) Những sự chuyển đổi này là điểm chính trong quy trình phát triển áp dụng MDA Một công cụ chuyển đổi cũng giống như một hộp đen Nó xem một mô hình như là đầu vào và sinh ra

mô hình thứ hai như đầu ra của nó Nếu chúng ta mở công cụ chuyển đổi ra và nhìn vào bên trong, chúng ta có thể thấy các thành phần liên quan đến việc thực hiện chuyển đổi Đâu đó bên trong công cụ, có một định nghĩa mô tả cách một mô hình được chuyển đổi Chúng ta gọi định nghĩa này là “định nghĩa chuyển đổi”

Hình 1.8: Định nghĩa chuyển đổi bên trong công cụ chuyển đổi Nguồn [4, mục 2.3]

“Một định nghĩa chuyển đổi 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.”

“Một luật chuyển đổi là một 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.”

1.3.4 Các đặc điểm mong muốn của sự chuyển đổi

Theo phương pháp MDA, có nhiều đặc điểm của quy trình chuyển đổi mà chúng ta muốn hướng tới, đó là:

 Khả năng truy tìm nguồn gốc, nghĩa là người ta có thể theo dõi một thành phần tại mô hình đích khi tìm ngược lại các thành phần tại mô hình nguồn nơi nó được sinh ra

 Tính nhất quán gia tăng, nghĩa là khi thông tin đích bổ sung đã được thêm vào

mô hình đích, và khi mô hình đích được tái sinh từ mô hình nguồn thì thông tin

bổ sung vẫn còn

 Tính hai chiều, nghĩa là một chuyển đổi có thể được áp dụng không chỉ từ nguồn tới đích mà còn ngược lại từ đích về nguồn

1.3.4.1 Khả năng truy tìm nguồn gốc

Trong nhiều tình huống, khả năng truy tìm nguồn gốc là tài sản hữu ích trong ứng dụng MDA Thường thì một PIM không có tất cả các thông tin cần thiết để thực thi toàn bộ hệ thống Và do đó khi chuyển đổi sang PSM thì PSM cần được lấp đầy thông tin một cách thủ công Điều tương tự xảy ra ở Text, một cách hiển nhiên, đây là nguồn gốc của mọi sự rắc rối Vì vậy mà một công cụ ít nhất nên làm là cảnh báo người dùng các phần bị thay đổi cho PIM Ví dụ, khi người dùng thay đổi tên của một phương thức trong PSM, công cụ có thể gợi ý phương thức tương ứng trong PIM cũng được đổi tên

1.3.4.2 Tính nhất quán gia tăng

Khi một mô hình đích được sinh ra, nó thường cần được thêm một vài việc phụ trợ như bổ sung mã vào một phương thức, hoặc tinh chỉnh một giao diện người dùng để tối ưu cách sử dụng Khi chúng ta tái sinh mô hình đích (vì có thay đổi

ở mô hình nguồn), chúng ta vẫn muốn duy trì các công việc phụ đã hoàn thành ở

mô hình đích lúc đầu Đây là chính là tính nhất quán gia tăng

1.3.4.3 Tính hai chiều

Đặc điểm mong muốn cuối của sự chuyển đổi là tính hai chiều, hay sự chuyển đổi có thể hoạt động ở cả hai hướng Điều mà chúng ta quan tâm ở đây là chuyển đổi ngược từ Text về PSM, rồi từ PSM về PIM Thực tế thì việc này rất khó thực hiện, vì cũng như việc đi biên dịch ngược ngôn ngữ máy về ngôn ngữ lập trình bậc cao (reverse engineering), và rất ít công cụ có thể thực hiện được

1.3.5 Mô hình bốn lớp của MDA

Để hiểu rõ hơn về model, meta-model, chúng ta xem xét mô hình bốn lớp được định nghĩa bởi OMG gồm M0, M1, M2, M3 như sau

Hình 1.9: Mô hình bốn lớp của MDA Nguồn [4, mục 8.2]

Lớp M0 mô tả các thực thể tham gia vào hệ thống như Khách hàng (Customer), Hoá đơn (Order) Lớp M1 mô hình hoá M0, cũng là mô hình hoá hệ thống, ví dụ các

mô hình UML Customer, Order ở M1 tương ứng với các thực thể ở lớp M0, tức là mỗi

trường hợp ở M0 là một cá thể của một trường hợp tại M1 Mô hình ở M1 được gọi là model Tương tự như vậy, ở mức trừu tượng cao hơn, các thành phần ở lớp M1 lại là các cá thể của các thành phần ở lớp M2 và mỗi thành phần ở M2 phân loại các

thành phần ở M1, ví dụ, tên lớp (Class) và thuộc tính (Attribute) của mỗi thành phần ở

M1 được mô hình ở lớp M2 Mô hình ở lớp M2 được gọi là meta-model Lớp M3 được gọi là meta-meta-model là mức trừu tượng cao nhất thể hiện M2 OMG định nghĩa MOF (Meta-Object-Facility) là ngôn ngữ cho lớp M3, và không còn lớp nào cao hơn M3 vì MOF (xem Hình 1.10) vừa là mô hình, vừa là ngôn ngữ trừu tượng (meta-language) biểu diễn chính nó và biểu diễn các ngôn ngữ khác

Stock

-id : string -name : string

System

Expressed in Instance of

Metalanguage M3: Model of model of model

Language M2: Model of model

Model M1: Model of a system

System M0: System

Hình 1.10: MOF trong MDA Nguồn [9, tr 204]

Ngoài model được trình bày là yếu tố quan trọng của MDA, thì meta-model cũng quan trọng không kém, nguyên nhân gồm hai lý do Thứ nhất, chúng ta cần một cơ chế định nghĩa các ngôn ngữ mô hình (ví dụ định nghĩa UML) để công cụ chuyển đổi sau

đó có thể hiểu các mô hình Như đã đề cập chúng ta định nghĩa các ngôn ngữ thông qua các meta-model Thứ hai, các luật chuyển đổi cấu thành một định nghĩa chuyển đổi mô tả cách một mô hình trong ngôn ngữ nguồn có thể được chuyển thành một mô hình ở ngôn ngữ đích Những luật này sử dụng các meta-model của ngôn ngữ nguồn và đích để định nghĩa sự chuyển đổi (xem Hình 1.11)

Hình 1.11: Cơ chế chuyển đổi mô hình trong MDA Nguồn [4, mục 8.3.1]

1.3.6 Ví dụ về MOF

Để hiểu rõ hơn về MOF và các tiêu chuẩn được sử dụng với MOF (sẽ được đề cập ở mục 1.4), chúng ta hãy xét một ví dụ đơn giản với mục đích giải thích tại sao MOF lại được dùng để định nghĩa meta-model hay language

Một tài liệu dạng XML có thể được mô tả bởi một tập các “element nodes”,

“attribute notes”, và “text nodes” như sau:

<acronyms>

<item acronym =”MOF” meaning =”Meta-Object Facility” /

<item acronym =”XMI” >

<meaning> XML Metadata Interchange </meaning>

</item>

</acronyms>

Tài liệu gồm có các “element nodes”: acronyms, item, item, meaning Các

“attribute nodes”: acronym, meaning, acronym Và “text node”: XML Metadata

Interchage Ta có nhận xét sau:

 (1) Mỗi node (nói chung) đều có tên (name)

 (2) Mỗi “element node” thì gồm các “element nodes” khác, “attribute nodes”,

hay “text nodes” Ví dụ item gồm có acronym, meaning, và meaning gồm có

XML Metadata Interchange

 (3) Mỗi “attribute node” thì có giá trị (value) Ví dụ, acrocym thì có giá trị

“MOF” và “XMI”

 (4) Mỗi tài liệu XML thì đều có một “root node” Ở đây “root node” có tên là

acronyms và nó cũng là “element node”

Ta biểu diễn các thông tin trên dưới dạng mô hình như sau:

có thể không có hoặc có nhiều “Node” con bên trong nó, điều này thể hiện sự trừu tượng của (2) Lớp “AtributeNode” có thuộc tính “value” thể hiện

sự trừu tượng của (3) Và tài liệu XML chỉ có một “RootNode”, kế thừa từ

“ElementNode” thể hiện sự trừu tượng của (4)

Mô hình trên ta gọi là meta-model vì nó thể hiện sự trừu tượng của tài liệu XML (hay gọi là XML model) Meta-model này biểu diễn tất cả thông tin theo cấu trúc của tài liệu XML nên ta gọi nó là XML meta-model Như vậy, MOF không được dùng để

mô tả sự biểu diễn cụ thể (concrete presentation, concrete syntax) cho XML, mà nó

mô tả cú pháp trừu tượng (ở đây là cấu trúc) của ngôn ngữ XML

Ở ví dụ trên thực chất các MOF class là các UML notation, hay còn gọi là UML Profile (là sự mở rộng của UML), là một tiêu chuẩn được dùng để ánh xạ giữa MOF và UML (xem lại M3 và M2 Hình 1.10)

1.4 Các tiêu chuẩn của OMG được sử dụng với MDA

Tư tưởng của MDA là không bó hẹp trong bất kỳ tiêu chuẩn nào Tuy nhiên, để

sử dụng hiệu quả MDA thì cần thiết có một tập các tiêu chuẩn liên quan về mô hình Điều này cho phép các tổ chức phát triển các công cụ tương thích với MDA, và có

sự tương tác dễ dàng giữa các công cụ với nhau

1.4.1 MOF (Meta-Object Facility)

MOF là ngôn ngữ dùng để định nghĩa ngôn ngữ mô hình MOF nằm trong lớp M3 Khi không có lớp cao hơn, MOF được dùng để định nghĩa chính nó Nó là ngôn ngữ định nghĩa UML (và CWM), nghĩa là các UML meta-model của UML được viết bởi MOF Vì MOF cũng định nghĩa chính nó nên nó cũng được xem như là một

mô hình (meta-meta-model)

Vai trò của MOF là nó cho chúng ta các khái niệm và công cụ để suy luận về ngôn ngữ mô hình Sử dụng định nghĩa MOF của một ngôn ngữ mô hình (meta-model lớp M2) chúng ta có thể định nghĩa chuyển đổi giữa các ngôn ngữ mô hình Bởi vì chuyển đổi được định nghĩa trong thuật ngữ meta-model của ngôn ngữ mô hình liên quan, chúng có thể được áp dụng cho bất cứ mô hình nào (tại lớp M1) được viết bởi một trong những ngôn ngữ đó Nếu không có một ngôn ngữ chuẩn mô tả các meta-model, chuyển đổi có thể không được định nghĩa đúng và phương pháp MDA sẽ rất khó để nhận biết Như vậy, MOF là công nghệ lõi của MDA

1.4.2 UML (Unified Modeling Language)

UML là ngôn ngữ mô hình chuẩn tại lớp M2, được xác định bằng cách sử dụng MOF Đại đa số mô hình đang được phát triển là mô hình UML vì thực tế đã chứng minh UML là ngôn ngữ thể hiện miền vấn đề một cách tốt nhất Ta đã biết meta-model mô tả ngôn ngữ và model được viết bởi ngôn ngữ, vậy UML meta-model

mô tả chính xác cách mà một mô hình UML (UML model) được xây dựng

1.4.3 OCL (Object Contraint Language)

OCL là ngôn ngữ ràng buộc hướng đối tượng, là một ngôn ngữ diễn tả trong đó 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 Theo ngữ cảnh của MDA, điều này có nghĩa là mô hình nguồn của một chuyển đổi trở nên phong phú hơn, làm cho nó có thể tạo ra nhiều 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 Text có chất lượng cao Ngoài ra, OCL cũng có thể được sử dụng tại lớp MOF, cho phép viết diễn tả về meta-model Ngoài việc mang lại nhiều 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 ở 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ể ở meta-model của ngôn ngữ nguồn hoặc đích

1.4.4 CWM (Common Warehouse MetaModel)

CWM là một ngôn ngữ mô hình (như UML) mà cụ thể là mô hình ứng dụng kho lưu dữ liệu Bởi vì kho lưu dữ liệu là công nghệ kết hợp thông tin từ nhiều nguồn, cho nên CWM meta-model được dùng cho nhiều nguồn khác nhau:

 Cơ sở dữ liệu quan hệ

 Bản ghi hay cấu trúc

 OLAP (Online Analytical Processing)

 XML

 Chuyển đổi (Transformations)

 Hình ảnh thông tin (Visualization of information)

 Khai phá dữ liệu (Data mining)

 Cơ sở dữ liệu đa hướng (Multidimensional databases)

 Meta-data cho doanh nghiệp (Business metadata)

 Quy trình xử lý kho lưu (Warehouse processes)

 Hoạt động kho lưu (Warehouse operation)

CWM meta-model được mô hình bằng cách sử dụng MOF Do đó, chúng có thể được

sử dụng như nguồn hoặc đích cho chuyển đổi MDA

1.4.5 UML Profile

Một UML Profile là sự mở rộng của UML, được định nghĩa bởi một tập các khuôn mẫu (stereotype), một tập các ràng buộc liên quan, và một tập các giá trị được gán nhãn (tag value)

Một định nghĩa khuôn mẫu được đặt tên và được đính kèm vào các thành phần trong meta-model Ví dụ, khuôn mẫu <<JavaClass>> được định nghĩa cho UML meta-class Trong một mô hình UML người ta có thể ứng dụng khuôn mẫu này vào mỗi lớp trong mô hình

Một ràng buộc có thể được đính kèm với một định nghĩa khuôn mẫu Ràng buộc này được diễn tả bởi OCL trong UML meta-model, và mô tả giới hạn trên những trường hợp của các thành phần mô hình cho khuôn mẫu nào được ứng dụng Ví dụ, với mỗi lớp trong một mô hình UML được gán nhãn với khuôn mẫu <<JavaClass>>, ràng buộc sau nên có: “Một lớp Java có thể có nhiều nhất một meta-class”

Một giá trị được gán nhãn là một meta-attribute bổ sung được đính kèm với meta-class trong UML meta-model Một giá trị được gán nhãn có tên và kiểu và được đính kèm với một khuôn mẫu cụ thể Nó có thể được gán một giá trị trong một mô hình, nhưng chỉ cho các thành phần có khuôn mẫu tương ứng

Ảnh hưởng của một UML Profile đó là nó định nghĩa một biến thể cụ thể của UML với một mục đích cụ thể, ví dụ để biểu diễn các thuộc tính của một trang Web như Text, Button, Form thì không thể dùng UML đơn thuần, khi đó UML Profile sẽ thể hiện tốt điều đó

1.4.6 XMI (XML Metadata Interchange)

Như đã đề cập ở ví dụ 1.3.6, UML Profile là ánh xạ giữa MOF và UML, thì ở khía cạnh khác XMI là ánh xạ giữa MOF và XML XMI cũng là một tiêu chuẩn định nghĩa các luật sinh (production rules) dùng cho việc tạo các Document Type Definition (DTD) và XML Schemas từ MOF meta-model, và nó còn có các luật tuần tự (serialization rules) cho các cá thể của MOF meta-model Các cá thể này sẽ phù hợp với XML Schemas và DTD đã được tạo từ meta-model

Các công cụ UML có thể trao đổi các mô hình UML với nhau nếu áp dụng đúng các luật tuần tự được đặc tả bởi XMI, tức là có sự tương thích giữa các công cụ UML với nhau Về bản chất, để trao đổi các mô hình với nhau các công cụ cần một cơ chế gọi là UML interchange format, và cơ chế này này có thể được suy ra từ việc áp dụng XMI

1.4.7 JMI (Java Metadata Interchange)

Tương tự như XMI, JMI là ánh xạ giữa MOF và Java (ví dụ tạo các Java API từ MOF meta-model)

1.5 Tổng kết chương

Kiến trúc hướng mô hình (MDA) là khung công tác cho phát triển phần mềm được chuẩn hoá bởi OMG Điểm mấu chốt là tầm quan trọng của các mô hình trong quy trình phát triển phần mềm Cùng với MDA quy trình này được điều khiển bởi các hoạt động mô hình hệ thống phần mềm

Vòng đời phát triển MDA không khác biệt nhiều so với vòng đời truyền thống Các nhân tố trong MDA là các mô hình hình thức, là các mô hình có thể hiểu được bởi máy tính Ba mô hình sau là cốt lõi của MDA:

 Mô hình độc lập nền (PIM), là mô hình với một mức trừu tượng cao, nghĩa là độc lập với bất cứ công nghệ triển khai nào

 Mô hình phụ thuộc nền (PSM), là mô hình thiết kế riêng để xác định hệ thống phần mềm với công nghệ triển khai cụ thể Một PIM được chuyển đổi thành một hoặc nhiều PSM

 Mô hình văn bản (Text/Code) PSM được chuyển đổi thành các yếu tố văn bản (mã nguồn, tài liệu)

Theo phương pháp truyền thống, việc chuyển đổi từ mô hình sang mô hình, hoặc

từ mô hình sang mã được thực hiện thủ công Trái ngược với điều này, việc chuyển đổi trong MDA luôn luôn được thực hiện bằng các công cụ và hoàn toàn tự động

Chuẩn quan trọng nhất trong MDA là MOF cho phép chúng ta định nghĩa

meta-model Ngoài MOF ra, chúng ta cũng cần ngôn ngữ định nghĩa chuyển đổi để mô tả

chuyển đổi giữa các mô hình Trong ngôn ngữ định nghĩa chuyển đổi chúng ta có thể cũng sử dụng OCL để cụ thể hóa những truy vấn và điều kiện Tất cả những ngôn ngữ

và chuẩn khác mà chúng ta đã biết đóng vai trò là ngôn ngữ nguồn và đích trong MDA Hơn nữa, bất cứ khi nào chúng ta định nghĩa một ngôn ngữ mới qua một MOF meta-model, nó có thể được sử dụng cùng với môi trường MDA Ngôn ngữ UML và

mở rộng của nó được định nghĩa bởi UML Profile, là ngôn ngữ mô hình sẽ được sử dụng thường xuyên

CHƯƠNG 2 KHẢO SÁT KHẢ NĂNG SINH MÃ TỰ ĐỘNG

TRONG MDD

Chương này luận văn sẽ trình bày khái quát về các bộ sinh mã hướng mô hình tuân theo kiến trúc MDA, trong đó cơ chế sử dụng khuôn mẫu (template) phần lớn được áp dụng bởi các bộ sinh mã Luận văn cũng đề cập tới một số công cụ chuyển đổi hướng mô hình hiện nay và ngôn ngữ chuyển đổi mà chúng sử dụng Ngoài ra, những khảo sát về ưu điểm và nhược điểm của việc sinh mã cũng sẽ được tổng kết

2.1 Giới thiệu

Khoa học máy tính đã không ngừng nỗ lực để nâng cao mức độ trừu tượng của ngôn ngữ máy tính phục vụ cho việc viết các chương trình máy tính từ đơn giản đến phức tạp Có thể nhìn lại chặng đường phát triển từ mã nhị phân tới hợp ngữ, tới các ngôn ngữ thủ tục và hướng đối tượng, và tới các ngôn ngữ mô hình hoá, với mục đích

là luôn luôn phát triển các cơ chế mang tính diễn tả nhiều hơn cho phép lập trình viên phát triển các đoạn mã được tổ chức tốt, linh hoạt, có thể mở rộng, mạnh mẽ và với ít

nỗ lực nhất Nghiên cứu về sinh mã là điều thiết yếu cho việc xây dựng công cụ tạo mã

và các yếu tố liên quan như tài liệu và mô hình

Hình 2.12: Sự trừu tượng hoá tăng dần của ngôn ngữ máy tính [18]

Như đã trình bày trong Chương 1 về MDA, bước cuối cùng trong tiến trình chuyển đổi là tạo mã thực thi cũng như các yếu tố hỗ trợ khác như file cấu hình, file

mô tả các thành phần, file triển khai, các kịch bản xây dựng (build scripts) và vân vân Phạm vi và hành vi thực thi ứng dụng được mô tả trong PIM và PSM càng hoàn thiện bao nhiêu, thì các yếu tố được được tạo ra càng hoàn thiện bấy nhiêu Tuỳ vào sự hoàn chỉnh và chất lượng của các công cụ MDA mà việc sinh mã có thể là tự động một phần cho đến một hệ thống hoàn chỉnh Tuy vậy, với sự tự động tối thiểu thì cũng làm giản

đơn công việc phát triển đi nhiều và đáng để ghi nhận điều đó Và vì việc sử dụng kiến trúc nhất quán cho việc quản lý khía cạnh độc lập nền và phụ thuộc nền của ứng dụng cũng là nguyên do cho sự tự động sinh mã được nghiên cứu

2.2 Các bộ sinh mã hướng mô hình

Kích thước và phạm vi của các bộ sinh mã thay đổi từ các đoạn kịch bản (script) tuỳ biến ngắn gọn, hoặc các chương trình chạy ở chế độ console với đầu vào tối thiểu cung cấp đầu ra tiền định nghĩa, cho tới các công cụ trực quan có thể sinh toàn bộ

hệ thống từ đầu vào là các định nghĩa mô hình phức tạp hơn Mục này sẽ đề cập cụ thể hơn đến việc sinh mã hướng mô hình tuân theo kiến trúc MDA

Đối với MDA việc sinh mã tự động hướng mô hình được mô tả ở Hình 2.13 sau đây

Hình 2.13: Chuyển đổi mô hình sang mã nguồn theo MDA Trong đó mô hình nguồn (Source Model) được viết bởi nhiều 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ư C/C++, Java, vân vân Đí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

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)

Có nhiều phương pháp sinh mã hướng mô hình khác nhau sử dụng kiến trúc trên

có thể điểm đến như sau:

2.2.1 Sử dụng Khuôn mẫu và Bộ lọc (Template and Filtering)

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 2.14: Sinh mã dựa trên Khuôn mẫu và Bộ lọc

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"/>

<attribute name ="age" type ="int"/>

</class>

 Khuôn mẫu (template) được viết bằng XSTL Mã Java được nhúng trực tiếp vào khuôn mẫu cùng với các Bộ lọc Các bộ lọc này sẽ đọc giá trị từ mô hình nguồn để điền vào khuôn mẫu

<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

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;}}

2.2.2 Sử dụng Khuôn mẫu và Meta-Model (Template and Meta-Model)

Phương pháp này là một sự mở rộng của phương pháp “Template and Filtering” [11] 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ả rồi mới áp dụng khuôn mẫu vào Khuôn mẫu được 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ể (tham khảo ví dụ ở mục 2.4.3)

Hình 2.15: Sinh mã dựa trên Khuôn mẫu và Meta-model

2.2.3 Sử dụng Bộ sinh dựa trên API (API-based Generator)

Client Program sẽ gọi API mà API này thông thường dựa vào meta-model hay

cú pháp của ngôn ngữ đích (Grammar) để sinh mã [12]

Hình 2.16: Sinh mã dựa trên API

2.2.4 Sử dụng Sinh mã nội tuyến (Inline Code Generation)

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 2.17: Sinh mã nội tuyến

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

#ifdef _WIN32 //Khai báo thư viện cho Windows

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:

Hình 2.18: Sinh mã dựa trên khuôn mẫu Nguồn [6, tr 140]

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) Ví dụ minh hoạ

Hình 2.19: Ví dụ về sinh mã Nguồn [6, tr 140]

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 Hiện tại, đã có các bộ tạo mã hướng mô hình sẵn có hoặc là sản phẩm thương mại hoặc là các dự án mã nguồn mở

Chúng cung cấp sự tự động sinh mã và quản lý hệ thống tổng thể dựa trên các

mô hình, thay đổi từ mô hình CSDL (database schema) tới các mô hình UML phức tạp hơn, sử dụng sự đa dạng của ngôn ngữ để diễn tả khuôn mẫu (template) 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 Trong phần này, phương pháp tiếp cận phổ biến nhất với những khía cạnh đó được đề cập tới Các công cụ sinh mã (hay bộ tạo mã) sau cung cấp hỗ trợ mạnh cho MDA

 Công cụ cung cấp sự tự động hoá mức cao trong định nghĩa và chuyển đổi

mô hình, thường được hướng tới miền ứng dụng cụ thể cho những luật chuyển phức tạp tương ứng với miền mà có thể được định nghĩa trước

 Công cụ được thiết kế cho một mục đích chung hơn, nhưng có thể được cấu hình để hỗ trợ MDA qua người dùng cuối, sự mở rộng các công cụ hãng thứ ba và sự tuỳ biến, thường được hướng tới một phạm vi rộng hơn của miền ứng dụng

2.3 Công cụ chuyển đổi mô hình

Trên thị trường hiện nay có rất nhiều công cụ chuyển đổi mô hình, mỗi công cụ đều có những ưu việt riêng Tuy nhiên trong phạm vi luận văn này, tác giả chỉ đề cập đến một số công cụ phổ biến sau

2.3.1 EMF (Eclipse Modeling Framework)

Khung mô hình hoá Eclipse (EMF) là nền tảng mô hình hoá tinh vi đằng sau trình phát triển Eclipse Mặc dù EMF chỉ được phát hành như một dự án con của Eclipse vào năm 2003, nhưng nó có một di sản lâu năm từ trình quản lý meta-data hướng mô hình của công cụ Visual Age IDE của IBM

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

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 (xem Hình 2.20) Một khung soạn thảo mô hình (Editor) và khung sinh mã (Generators) cũng được cung cấp 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

Hình 2.20: Khung EMF Nguồn [9, tr 210]

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ở Có thể kể đến như Acceleo, JET, openArchitectureWare, sẽ được

đề cập chi tiết hơn ở mục 2.4.3 cùng với ngôn ngữ chuyển đổi của chúng

2.3.2 MDR (Metadata Repository)

MDR là dự án mã nguồn mở được thành lập bởi Netbeans.org từ Tháng 1, 2002 Hiện nay MDR rất ổn định, và chỉ có những thay đổi nhỏ đi cùng với các bản phát hành mới của Netbeans

MDR là bộ lưu trữ meta-data tuân thủ các chuẩn MOF, XMI và JMI Nó cung cấp truy cập tức thời tới meta-data qua một tập các API phụ thuộc meta-model được tạo hoặc API độc lập meta-model Meta-data được quản lý bởi MDR có thể hoặc liên tục hoặc thoáng qua

MDR dùng như một tiện ích tích hợp được sử dụng bởi các thành phần riêng lẻ của một phần mềm để giao tiếp với nhau Ngoài ra, MDR như là một bộ lưu trữ lâu dài làm cho nó có thể thực thi các tính năng nâng cao của IDE như phân tích mã nguồn, tái cấu trúc hoặc chuyển đổi mô hình sang mô hình (như tạo mã Java từ mô hình UML) MDR như là một sự thực thi của MOF là công nghệ chính cần cho các công cụ triển khai MDA