Hình 3.2: Mô hình WebML .ecorediag trong dự án EMF
Dự án EMF cung cấp công cụ Ecore diagram cho phép người dùng có thể sử dụng các ký hiệu trực quan để kéo thả thay vì phải định nghĩa các khái niệm trừu tượng trong mô hình ecore.
3.1.2. Mô hình genmodel
Từ mô hình Ecore trong dự án EMF cho phép tạo ra mô hình genmodel. Mô hình genmodel được sinh ra từ mô hình ecore bổ sung thêm các thông tin cho EMF. model, EMF.edit, EMF.editor, EMF.test; mô hình genmodel như hình dưới đây:
3.2. Biểu diễn cú pháp cụ thể
Cú pháp trừu tượng cho DSML trong dự án EMF đã được xây dựng, tiếp theo ta sẽ xây dựng cú pháp cụ thể cho DSML bằng dự án GMF của Elipse.
Bảng 3.1. Các ký hiệu được xây dựng trong dự án GMF của DSL cho miền ứng dụng Web
Khái niệm (Concept) Ký hiệu (Notation) Node HypertextLayer Node StaticPage Node IndexPage Node DetailPage Node Clink Node NCLink Node Class Node Attribute Connection HypertextLayerHaspages <HypertextLayerHaspages> Connection HypertextLayerHasHomepage <HypertextLayerHasHomepage>
Connection PageHasLinks <PageHasLinks> Connection
DynamicPageHasClass
<DynamicPageHasClass>
Connection ClassHasattributes <ClassHasattributes>
Clink
NClink
Các mô hình xây dựng trong dự án GMF của DSL cho ứng dụng Web gồm:
3.2.1. Graphical Definition Model (GDM) WML.gmfgrahp
Các Figure, Node, Connection, Compartment, Diagram Label cho các khái niệm thuộc miền được định nghĩa cụ thể như sau:
+ Figure: Định nghĩa các hình đại diện cho các node và connection
Hình 3.4: Mô hình WML.gmfgraph
+ Node: Trong mô hình, node được dùng để định nghĩa các khái niệm. Mỗi node tương ứng với một hình trong mô hình.
+ Polyline: Định nghĩa hình dáng đường ở cuối liên kết của các connection. Ví dụ hình hưới đây định nghĩa cho liên kết giữa Role và Permission.
Hình 3.6: Xây dựng Polyline cho node ClassAttribute
+ Figure Descriptor: Các hình đại diện cho các khái niệm miền và các
liên kết giữa các khái niệm trong mô hình miền. Như hình dưới đây là định nghĩa hình (ký hiệu) cho khái niệm ClassAttributes và hình liên kết giữa Class và Attributes.
+ Connection: Định nghĩa các liên kết (association) tồn tại giữa các khái
niệm miền.
Hình 3.8: Xây dựng connection giữa Class và Attributes
+ Diagram Label: Tên hiển thị trong các hình của các node hoặc
connection.
3.2.2. Tooling Definition Model (TDM)
Mô hình TDM được sử dụng để xác định thanh palette, tạo các tools, tạo các actions… cho các phần tử đồ họa. Trong dự án GMF_WML có xây dựng một thanh Palette cho các khái niệm (node) và liên kết (link). Kết quả của Tooling Definition Model trong dự án GMF_WML như hình dưới đây:
Hình 3.10: Mô hình WML.gmftool đã được xây dựng
3.2.3. Mapping Definition Model (MDM)
Mô hình MDM cho phép chúng ta liên kết ba mô hình với nhau đó là: Domain (WML. Ecore), Graphical definition (WML. gmfgraph) và tooling definition (WML. gmftool). Đây là mô hình quan trọng để phát triển dự án GMF và mô hình này là đầu vào để chuyển sang mô hình cuối cùng là Generation Model.
Mô hình MDM sẽ ánh xạ các khái niệm miền ở mức trừu tượng trong mô hình WML. ecore thành các khái niệm miền ở mức cụ thể trong WML. gmfgraph gắn với tool trong Palette của mô hình WML. gmftool. Trong Mapping Definition Model của dự án GMF WML cần ánh xạ các Node và Link giữa các Node, hình dưới đây là mô hình WML. gmftool đã xây dựng.
Hình 3.11: Các node, link mapping trong WML.gmfmap
+ Các node cần ánh xạ của dự án GMF_WML: HypertextLayer,
ContentLayer, Page, DynamicPage, StaticPage, Link, Class,…. Ví dụ như ánh xạ node như hình dưới đây:
Hình 3.12: Ánh xạ node HypertextLayer
Hình tiếp theo là ánh xạ của node HypertextLayer trong đó xác định node chứa bên trong là node Page.
Hình 3.13: Ánh xạ node HypertextLayer và Page
+ Các Link cần ánh xạ trong dự án GMF_WML: Webmodel.content. ContentLayer, Webmodel. hypertext. HyperTextLayer, HyperText.homepage. Page, HyperText.pages.Page , ví dụ như hình dưới đây:
3.3. Kỹ thuật sinh mã
Xây dựng máy sinh mã là một trong hai nhiệm vụ chính khi tạo ra giải pháp DSM. Máy sinh mã trong DSM được xây dựng để thực hiện nhiệm vụ trong một miền vấn đề cụ thể. Mã do nó sinh ra không cần phải sửa đổi, bổ sung vì nó đã đáp ứng được hết các yêu cầu của nhà phát triển. Mặc dù tác dụng của máy sinh mã to lớn như vậy nhưng để tạo ra được nó không phải là điều dễ dàng. Trong phần này, chúng ta sẽ tìm hiểu các bước để tạo ra một máy sinh mã trong DSM.
3.3.1. Các cách để xây dựng máy sinh mã
Chúng ta sẽ tìm hiểu về các cách khác nhau để làm nên kết cấu của máy sinh mã. Mỗi cách có thể được sử dụng riêng hoặc có thể kết hợp với cách khác. Chúng ta cần chia nhỏ máy sinh mã ra thành các máy sinh mã con. Mỗi máy sinh mã con sẽ giải quyết một vấn đề cụ thể. Chúng ta sẽ xây dựng máy sinh mã con theo các thứ tự:
Autobuild: Máysinh mã autobuild ở mức cao nhất. Nó qui định các file
được sinh ra trong máy sinh mã hoặc quy định kịch bản của hoạt động tiếp theo của máy sinh mã.
Máy sinh mã ở mỗi ngôn ngữ mô hình: Giải pháp DSM đầy đủ thường phải
sử dụng nhiều hơn một ngôn ngữ mô hình. Vì vậy đối với mỗi ngôn ngữ mô hình cần phải tạo ra một máy sinh mã con tương ứng.
Máy sinh mã cho mỗi loại file: Mỗi mô hình có thể sinh ra nhiều file vì vậy
với mỗi loại file trong từng mô hình chúng ta nên định nghĩa cho nó một máy sinh mã con tương ứng.
Máy sinh mã có thể song song sinh ra nhiều ngôn ngữ lập trình: Nhu cầu
tạo ra một ứng dụng dựa trên nhiều nền tảng khác nhau, trên nhiều ngôn ngữ khác nhau là rất lớn. Vì vậy một máy sinh mã cần phải hỗ trợ nhiều ngôn ngữ lập trình khác nhau.
3.3.2. Qui trình tạo ra máy sinh mã
Tạo và kiểm tra máy sinh mã: Phần quan trọng trong việc tạo ra máy sinh
mã biết được khi nào bắt đầu. Phải biết là đầu vào máy sinh mã và kết quả đầu ra của máy sinh mã là gì. Chúng ta giữ cho máy sinh mã càng đơn giản càng tốt, đẩy sự phức tạp xuống khuôn khổ miền. Đồng thời, ta phải chờ sau khi xây dựng xong mô hình chuyên biệt miền mới bắt đầu xây dựng máy sinh mã. Chúng ta sẽ xây dựng một ví dụ về mô hình chuyên biệt miền trên và sử dụng nó
để kiểm tra máy sinh mã. Một khi máy sinh mã đã có thể chạy với mô hình ví dụ thì ta nên thay đổi từng phần của mô hình và xem sự thay đổi đó xảy ra ở đầu ra của máy sinh mã như thế nào. Bắt đầu từ những thay đổi đơn giản nhất như tên của khái niệm rồi phức tạp hơn bằng cách cho thêm các đối tượng trên mô hình, từ đó sẽ có những thay đổi phù hợp với máy sinh mã. Cứ như thế ta sẽ có một máy sinh mã hoàn chỉnh. Và khi muốn thay đổi hoặc nâng cấp máy sinh mã, ta cũng làm tương tự các bước trên.
Chia sẻ và duy trì máy sinh mã: Máy sinh mã liên kết với ngôn ngữ mô
hình ở một mặt và liên kết với khuôn khổ miền, môi trường mục tiêu ở mặt còn lại. Vì vây để quá trình mô đun hóa được diễn ra thuận lợi cần giữ vững các mối liên kết trên. Ở giai đoạn bắt đầu viết máy sinh mã thì liên kết với ngôn ngữ mô hình thường mạnh hơn nên khi chúng ta có một bản cập nhật cho mô hình ngôn ngữ thì cũng thường có một bản cập nhật cho máy sinh mã đi kèm. Nếu trong trường hợp mô hình ngôn ngữ được cập nhật mà máy sinh mã không được cập nhật thì máy sinh mã và mô hình ngôn ngữ vẫn phải đi kèm với nhau. Mối liên kết giữa máy sinh mã với khuôn khổ miền cũng rất đáng chú ý. Những thay đổi trong khuôn khổ miền dẫn đến sự thay đổi trong máy sinh mã. Để đồng bộ tất cả những thay đổi giữa các thành phần, chúng ta phải đồng bộ các thay đổi trên vào cùng một phiên bản để tránh nhầm lẫn, sai phiên bản.
Kiểm soát phiên bản máy sinh mã: Chúng ta nên đánh dấu số phiên bản
máy sinh mã để có thể dễ dàng kiểm soát chúng.
3.3.3. Mã nguồn của mô hình EMF.model
Mã nguồn của mô hình trong dự án EMF được sinh ra từ mô hình genmodel nhờ bộ Genrator của dự án EMF, nó gồm các package wml, wml. impl, wml.until.
- wml: gồm các tệp java của các khai báo giao diện (inteface) tương ứng với các khái niệm trong metamodel và các khai báo kiểu tập hợp (enum) của Factory, Package.
- wml.impl: Gồm các tệp java của các lớp triển khai các interface được khai báo trong dự án WebML.
- wml.util: gồm hai tệp tương ứng với hai lớp WmlAdapterFactory.java và WmlSwitch. java.
Hình 3.15: Mã nguồn được tự động sinh ra từ mô hình WML.genmodel
3.3.4. Các thành phần của EMF.edit và EMF.editor
Nhờ bộ Generator của dự án EMF cho phép sinh ra các mã nguồn tự động các thành phần EMF.editor và EMF.edit.
Hình 3.16: WML.edit và WML.editor được sinh ra từ genmodel
3.3.5. Code Generation (CG)
Sau khi xây dựng mô hình Mapping Definition Model bước tiếp theo ta tạo mô hình Generator từ mô hình Mapping Definition Model sau đó tạo generate diagram từ mô hình Generator.
Hình 3.17: Generate diagram code của dự án GMF
Kết quả của bước trên sẽ tạo ra tệp Plugin. xml của tool DSL cho ứng dụng Web thu được từ kết quả của dự án GMF.
3.4. Kết quả của DSL cho miền ứng dụng Web
Kết quả dự án GMF WML chúng tôi đã xây dựng được một DSL cho miền ứng dụng Web là một Application Plug-in với Eclipse.
Hình 3.19: DSL cho miền ứng dụng Web
Tóm lại, trong chương này chúng tôi đã trình bày được các kết quả cài đặt
cho dự án xây dựng DSML trên Eclipse cho miền ứng dụng Web gồm có kết quả của dự án EMF, GMF.
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
1. Kết quả đạt được:
Với mục tiêu ban đầu của đề tài đặt ra là tìm hiểu về DSML, tìm hiểu về miền ứng dụng Web để xây dựng metamodel cùng với ngôn ngữ OCL để cài đặt trên tool use.
Sau thời gian nghiên cứu chúng tôi đã đạt được các kết quả như sau:
- Tìm hiểu các khái niệm, công cụ và phương pháp xây dựng ngôn ngữ mô hình hóa chuyên biệt miền.
- Tìm hiểu về miền ứn dụng Web, trên cơ sở lý thuyết đã nghiên cứu chúng tôi đã tìm hiểu về công cụ Eclipse và đã xây dựng được DSML cho miền ứng dụng Web bằng các metamodel và ngôn ngữ ràng buộc mô hình OCL.
2. Hướng phát triển:
- Nghiên cứu tiếp về chuyển mô hình, dự án GMT trong Eclipse để xây dựng bộ sinh code, sinh documentation.
- Nghiên cứu tích hợp ngôn ngữ chuyên biệt miền đã xây dựng với các ngôn ngữ chuyên biệt miền khác.
TÀI LIỆU THAM KHẢO
[1] MetaCase, http://www.metacase.com.
[2] WebML, http://www.webml.org.
[3] Robert A. Maksimchuk, Michael W. Engle, Bobbi J.Young, Ph.D.Jim
Conallen, Kelli A. Houston Grady Booch, “Object-Oriented Analysis
and Design with Applications”, the United States on recycled paper at
Courier in Westford, Massachusetts, April, 2007.
[4] Sanna Sivonen, "Domain-specific modelling language and code generator for
developing repositorybased", VTT Publications, Oulu, research project 2008.
[5] Richard C. Gronback, “Eclipse Modeling Project A Domain-Specific
Language”,United States of America, 2009.
[6] Rick Kuhn, "Role Based Access Control" American National Standards,
Apr. 2003.
[7] David Dean, Anna Gerber, Gunnar Wagenknecht, Philippe Vanderheyden
Bill Moore, “Eclipse Development using the Graphical Editing Framework
and the Eclipse Modeling Framework”, ibm. com/redbooks, 2004.
[8] Petter Graff Vladimir Bacvanski, “Mastering Eclipse Modeling
Framework”, 2005, Elipse.
[9] Reena Cherukuri Dr. Saeed Rajput, Role Based Access Control Models, Slide. [10] Elisa Chiarani (UNITN), Edith Felix (THA),Benjamin Fontan (THA),
Charles Haley (OU), Fabio Massacci (UNITN), Zoltán Micskei (BME), Bashar Nuseibeh (OU), Federica Paci (UNITN), Thein Tun (OU) Yijun Yu
(OU), Dániel Varró (BME) Gábor Bergmann (BME),"Methology For
Evolutionary", 1.33, 2010.
[11] Beatriz Marín, Oscar Pastor Giovanni Giachetti, "Integration Of Domain
Specific Modeling Languages and UML", ©Technomathematics Research
Foundation, 2009.
[12] Steven Kelly and Juha-Pekka Tolvanen, “Domain-Specific Modeling:
Enabling Full Code Generation”, AWiley-Interscience, 2008.
[13] Marco Brambilla, Jordi Cabot, and Manuel Wimmer, “Model - Driven
Software Engineering in Practic”, Morgan & Claypool Publishers, 2012.
[14] Jordi Cabot(1) and Martin Gogolla(2), “Object Constraint Language (OCL):
a Definitive Guide”, (1)INRIA / Ecole des Mines de Nantes (France), (2)
University of Bremen (Germany).
[15] Group Object Management, "Object Constraint Language", OMG, formal/06-05-01, 2006.