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
CHƢƠNG 3 CHUYỂN ĐỔI MÔ HÌNH TRONG MDD
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:
rule Author{ from a : MMAuthor!Author to p : MMPerson!Person{ name <- a.name, surname <- s.surname } }
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.
3.3 Một số phương pháp sinh mã hướng mô hình
Đố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