Tài liệu Ngôn ngữ chuyển mô hình RTL (Restricted graph transformations language)

MỤC LỤC TÓM TẮT ............................................................................................................ ii BẢNG KÝ HIỆU VÀ CÁC CHỮ VIẾT TẮT ................................................... iii DANH SÁCH HÌNH VẼ .................................................................................... iv MỞ ĐẦU .............................................................................................................. 1 Chương I Cơ sở lý thuyết cho chuyển mô hình ................................................... 2 1.1 Phát triển hướng mô hình ............................................................................... 2 1.1.1 Khái niệm về mô hình ................................................................................. 4 1.1.2 Các chuẩn hướng tiếp cận MDD ................................................................. 5 1.1.3 Kiến trúc MDA............................................................................................ 6 1.2 Tổng quan về chuyển mô hình ....................................................................... 7 1.2.1 Các thuật ngữ trong chuyển mô hình .......................................................... 8 1.2.2 Một số giải pháp sử dụng ngôn ngữ chuyển ............................................... 9 1.3 Tổng kết chương .......................................................................................... 10 Chương II Ngôn ngữ chuyển mô hình RTL ....................................................... 11 2.1. Cơ sở hình thức cho RTL ............................................................................ 11 2.1.1 Kiến thức cơ sở về văn phạm đồ thị ba ..................................................... 12 2.1.2 Luật chuyển TGGs ràng buộc OCL .......................................................... 14 2.2. Cú pháp của RTL ....................................................................................... 22 2.3. Thực thi chuyển ........................................................................................... 23 2.4. USE hỗ trợ RTL .......................................................................................... 24 Chương III Thực nghiệm chuyển mô hình với RTL .......................................... 26 3.1 Bài toán chuyển UML sang CSP ................................................................. 26 3.1.1 Metamodel của biểu đồ hoạt động UML .................................................. 26 3.1.2 Metamodel của CSP .................................................................................. 28 3.2 Phương thức chuyển ..................................................................................... 29 3.3. Kết quả chuyển UML2CSP ......................................................................... 31 3.3.1 Xây dựng luật: ........................................................................................... 31 3.3.2 Áp dụng luật chuyển cho ví dụ cụ thể ....................................................... 37 3.4 Tổng kết chương .......................................................................................... 38 KẾT LUẬN ........................................................................................................ 40 TÀI LIỆU THAM KHẢO .................................................................................. 41 PHỤ LỤC ........................................................................................................... 42 A. XÂY DỰNG MÔ HÌNH VÀ LUẬT CHUYỂN ĐỔI................................... 42 B. MÃ SINH CỦA LUẬT ................................................................................. 49 i BẢNG KÝ HIỆU VÀ CÁC CHỮ VIẾT TẮT Từ viết tắt Từ chuẩn Diễn giải MDA Model Driven Architecture Kiến trúc hướng mô hình MDD Model-Driven Development Phát triển hướng mô hình MOF Meta-Object Facility Một chuẩn của OMG OMG Object Management Group Tổ chức quản lý đối tượng OCL Object Constraint Language Ngôn ngữ ràng buộc đối tượng UML Unified Modeling Language Ngôn ngữ mô hình hóa thống nhất RTL Restricted graph Ngôn ngữ chuyển mô hình giới transformations language hạn TGG Triple graph grammar Văn phạm đồ thị ba CSP Communicating sequential Tiến trình giao tiếp tuần tự processes iii DANH SÁCH HÌNH VẼ Hình 1.1: Ví dụ về hệ thống phân cấp metamodel bốn lớp của UML[3] ............. 5 Hình 1.2 Mô hình mối quan hệ ở mức metamodel ............................................... 8 Hình 2.1 Luật chuyển đồ thị ba và bước chuyển với luật chuyển tiến ............... 14 Hình 2.2 : Mô hình khái niệm bên trái tương ứng với mô hình thiết kế bên phải ....... 15 Hình 2.3: Chuyển đổi dưới dạng biểu đồ như một metamodel .......................... 15 Hình 2.4: Luật chuyển ba addAssociation tích hợp OCL ................................... 17 Hình 2.5: Ví dụ điều kiện áp dụng OCL ............................................................. 18 Hình 2.6: Ví dụ việc áp dụng điều kiện OCL cho luật ba ................................... 19 Hình 2.7 : Luật chuyển ba và dẫn xuất luật chuyển ba ....................................... 21 Hình 3.1 Metamodel của biểu đồ hoạt động UML [5] ....................................... 27 Hình 3.2: Ví dụ một biểu đồ hoạt động............................................................... 27 Hình 3.3: Biểu đồ hoạt động UML biểu diễn trên USE...................................... 28 Hình 3.4: Metamodel của CSP[5] ....................................................................... 29 Hình 3.5: Luật trafoInitialNode........................................................................... 31 Hình 3.6 Luật trafoFinalNode ............................................................................. 32 Hình 3.7 Luật trafoActionNode .......................................................................... 33 Hình 3.8 Luật trafoDecisionNode ....................................................................... 34 Hình 3.9 Luật trafoForkNode .............................................................................. 35 Hình 3.10 Luật trafoMergeNode ......................................................................... 36 Hình 3.11 Luật trafoJoinNode............................................................................. 37 Hình 3.12 Ví dụ chuyển mô hình từ biểu đồ hoạt động UML sang CSP ........... 39 iv MỞ ĐẦU Các hệ thống phần mềm ứng dụng hiện đang phát triển rất nhanh và ngày càng phức tạp đòi hỏi chúng ta phải có các phương pháp để cải thiện tốc độ phát triển và chất lượng của ứng dụng đó. Một trong những hướng tiếp cận đang rất được quan tâm trong phát triển phần mềm là phát triển hướng mô hình(MDD). Đã có nhiều phương pháp phát triển dựa trên hướng tiếp cận này như AGG, ATL, QVT[10]. Mỗi phương pháp đều đưa ra đề xuất xây dựng ứng dụng dựa trên những góc nhìn khác nhau của hệ thống dưới dạng mô hình. Để xây dựng ứng dụng một cách nhanh chóng và chính xác khi áp dụng phương pháp MDD, một điều quan trọng cần phải có là kiểm tra tính hợp lệ của mô hình. Những mô hình chính xác, chặt chẽ là điều kiện cần cho các bước xây dựng ứng dụng theo hướng mô hình hóa. Vì vậy, khi xây dựng mô hình cần có cơ chế kiểm tra các ràng buộc mà mô hình phải tuân theo. Những ràng buộc này được biểu diễn bằng ngôn ngữ ràng buộc đối tượng OCL. Trong phạm vi của luận văn, chúng tôi nghiên cứu và trình bày một phương pháp phát triển cụ thể là văn phạm đồ thị ba(TGG), nghiên cứu về ngôn ngữ chuyển mô hình RTL [3], [4]. Sau khi đưa nghiên cứu về RTL chúng tôi xây dựng các luật chuyển trong bài toán chuyển từ biểu đồ hoạt động UML sang đại số tiến trình CSP dựa trên công cụ USE. Trên cơ sở các luật chuyển đã được xây dựng chúng tôi áp dụng luật chuyển đó cho một ví dụ cụ thể để chuyển đổi mô hình biểu đồ hoạt động UML sang CSP[5]. USE được sử dụng làm công cụ kiểm chứng mô hình chuyển đổi trên. Cấu trúc của luận văn được tổ chức như sau: - Chương 1: Cơ sở lý thuyết cho chuyển mô hình. Chương này giới thiệu chung về phát triển hướng mô hình và tổng quan về chuyển mô hình. - Chương 2: Ngôn ngữ chuyển mô hình RTL. Trong đó tập chung vào nghiên cứu cơ sở hình thức cho RTL gồm: kiến thức cơ sở về văn phạm đồ thị ba, luật chuyển TGG ràng buộc OCL. Từ đó nghiên cứu về cú pháp của RTL và công cụ USE hỗ trợ RTL. - Chương 3: Thực nghiệm chuyển mô hình với RTL. Trên cơ sở nghiên cứu ngôn ngữ RTL, chúng tôi xây dựng bài toán chuyển từ biểu đồ hoạt động UML sang đại số tiến trình CSP bằng việc xây dựng các luật chuyển và áp dụng vào một ví dụ cụ thể. 1 Chương I Cơ sở lý thuyết cho chuyển mô hình Chương này giới thiệu về mô hình, ưu điểm của việc phát triển hướng mô hình và lý thuyết cho chuyển mô hình. Giới thiệu một số ngôn ngữ chuyển mô hình phần mềm . 1.1 Phát triển hướng mô hình Phát triển hướng mô hình (MDD) là hướng tiếp cận xem xét việc xây dựng chương trình là hoạt động chuyển đổi từ mô hình này sang mô hình khác. Ở hướng tiếp cận đối tượng, tất cả đều quy về đối tượng. Còn ở hướng tiếp cận MDD thì tất cả đều quy về mô hình. Một số ưu điểm trong phát triển hướng mô hình [10]: - Phát triển phần mềm nhanh hơn: Trong MDD các mô hình của một ứng dụng phần mềm được xác định trên một mức độ trừu tượng cao hơn so với các ngôn ngữ lập trình truyền thống. Mô hình này tự động chuyển đổi thành một ứng dụng phần mềm làm việc bằng cách tạo ra mã hoặc biên dịch /thực thi mô hình. Khi mô hình được sử dụng trên một mức độ trừu tượng cao sẽ nhanh hơn nhiều so với cùng một mô hình thể hiện trong mã. Nói cách khác: mỗi phần tử trong mô hình đại diện cho nhiều dòng mã. Do đó, có thể xây dựng nhiều chức năng hơn trong cùng một thời gian. - Chi phí-hiệu quả hơn: MDD có chi phí và hiệu quả hơn. Lý do đầu tiên đó là MDD thực hiện nhanh hơn do đó sẽ đưa ra thị trường nhanh hơn. Lý do thứ hai là có thể làm với chi phí thấp hơn. Điều này tất nhiên phụ thuộc vào chi phí học các phương pháp tiếp cận MDD và các chi phí để phát triển hoặc mua các công cụ. Nó cũng phụ thuộc vào mô hình kinh doanh. Thay đổi và duy trì các ứng dụng xây dựng bằng cách sử dụng một cách tiếp cận MDD cũng là hiệu quả chi phí. Nó là dễ dàng hơn để hiểu được hành vi của một ứng dụng bằng cách đọc các mô hình cao cấp. Ngoài ra nó là nhanh hơn để thêm chức năng hoặc thay đổi chức năng hiện có bằng cách sử dụng một ngôn ngữ cấp cao. - Tăng chất lượng phần mềm: Một phần mềm ứng dụng được quy định cụ thể trong một mô hình cấp cao được thực hiện bởi một cơ cấu hoặc chuyển đổi thành mã, chất lượng (kỹ thuật) của ứng dụng phụ thuộc vào cấu trúc sinh ra. Do đó, chất lượng có thể tăng lên rất nhiều bởi vì chúng ta có thể phát triển bởi những người tốt nhất . Hơn nữa, tất cả các thực hành tốt nhất tìm hiểu sẽ được 2 áp dụng cho các dự án xây dựng bằng cách sử dụng công cụ MDD. Trong trường hợp mua một công cụ MDD, nó có thể chứa các thực thi tốt nhất bởi vì nó được xây dựng dựa trên kiến thức của tất cả các dự án xây dựng bởi công cụ MDD trong quá khứ. - Ít bị lỗi hơn: Việc kiểm thử phần mềm sẽ tốn rất nhiều thời gian và chuyên môn. MDD đảm bảo rằng bạn có thể tập trung vào kiểm tra các chức năng của ứng dụng, tức là chấp nhận thử nghiệm. Vấn đề kỹ thuật đã được đảm bảo bằng cách thử nghiệm các công cụ MDD, ví dụ về các vấn đề cơ sở hạ tầng có liên quan hoặc các lỗ hổng bảo mật trong công nghệ. - Kiểm chứng có ý nghĩa: Ngay cả các chức năng chính nó là ít bị lỗi khi sử dụng một cách tiếp cận MDD, bởi vì kiểm chứng thực có ý nghĩa có thể được thực hiện trên các mô hình cao cấp. Khi sử dụng các ngôn ngữ lập trình truyền thống, bạn sẽ có một số cú pháp kiểm tra trong IDE của bạn và thậm chí có thể phân tích một số mã tĩnh. Tuy nhiên, do tính phổ quát của các ngôn ngữ lập trình này không thực sự giúp bạn tránh các lỗi chức năng. Khi sử dụng một cách tiếp cận MDD xác nhận tên miền cụ thể có thể được thực hiện tại thời điểm thiết kế. - Biểu diễn hệ thống bằng tri thức miền : MDD thi hành một sự tách biệt các mối quan tâm và kỹ năng. Chuyên gia miền có thể tập trung vào việc mô hình hóa các miền, trong khi chuyên viên kỹ thuật tập trung vào xây dựng các công cụ cần thiết cho MDD. Xây dựng các ứng dụng phức tạp không chỉ cho lập trình tốt nữa. MDD có thể giới thiệu các ký hiệu thích hợp (ví dụ như văn bản, đồ họa, bảng) để trao quyền cho các chuyên gia tên miền. - Lập trình tiên tiến cho phép tập trung trên các công cụ cứng: với MDD, các nhà phát triển tiên tiến làm công việc ít lặp đi lặp lại. Họ có thể tập trung vào các khía cạnh sáng tạo của công việc của họ. Ví dụ, họ có thể tập trung vào việc xây dựng các công cụ MDD. Họ cũng có thể cố vấn các nhà phát triển cơ sở hoặc chuyên gia tên miền, hoặc họ có thể chọn các phần cứng xây dựng ứng dụng. - Cầu nối khoảng cách giữa công nghệ và công nghệ thông tin(CNTT): Liên kết kinh doanh-IT là một vấn đề khi nói về xây dựng phần mềm. MDD có thể mang lại cho kinh doanh và CNTT gần nhau hơn trong các cách sau: thứ nhất, chuyên gia miền (hoặc các nhà phân tích kinh doanh) trực tiếp tham gia trong quá trình phát triển. Thứ hai, CNTT (một ứng dụng phần mềm) được xác định trên một mức độ cao hơn nhiều. Các mô hình này càng nhiều càng có thể khai báo và định nghĩa trong các khái niệm miền. Thứ ba, MDD phát triển 3 nhanh hơn phần mềm có thể được xây dựng trong các lần lặp lại ngắn hơn và do đó có phù hợp hơn cho mục đích (do thông tin phản hồi nhanh chóng của các doanh nghiệp, người dùng cuối cùng). Thứ tư, việc xác định các biến đổi rõ ràng giữa một mô hình của một tổ chức và một mô hình của một hệ thống CNTT. - Dễ thích ứng với những thay đổi trong các yêu cầu nghiệp vụ. Một trong những vấn đề của phát triển phần mềm là yêu cầu kinh doanh thường xuyên thay đổi nhanh hơn so với các hệ thống phần mềm hỗ trợ. Tuy nhiên, MDD có thể cung cấp một giải pháp bởi vì nó làm cho phát triển phần mềm nhanh hơn , nó cũng dẫn đến dễ dàng hơn để thay đổi các ứng dụng. - Dễ thích ứng với những thay đổi trong công nghệ. Thay đổi công nghệ theo nhau nhanh hơn và nhanh hơn. Hãy suy nghĩ về những điều như Java EE, SOA / soba, webservices, REST, SCA, OSGi, và gần đây hạn chế trong công nghệ khi ứng dụng điện toán đám mây (ví dụ như cấu trúc cơ sở dữ liệu ). MDD đảm bảo bạn không phải thay đổi mô hình ứng dụng của bạn khi bạn muốn di chuyển ứng dụng của bạn với các công nghệ khác. Điều duy nhất mà cần phải thay đổi là bộ tạo (hoặc bộ thông dịch). Sau khi thay đổi các mã bộ tạo (hoặc thêm các tùy chọn mã bổ sung ) tất cả các mô hình ứng dụng trực tiếp có thể được chuyển đổi thành mã cho công nghệ mới. - Thực sự thực thi kiến trúc: Các công ty thường xác định các nguyên tắc kiến trúc. Ứng dụng phần mềm phải tuân thủ những nguyên tắc này, nhưng làm thế nào để kiểm tra hoặc thi hành tuân thủ khi tất cả các mã được tạo ra bằng tay? Khi sử dụng MDD ứng dụng phần mềm được đảm bảo thực hiện đúng với kiến trúc được lựa chọn. Bạn thực sự có thể chuẩn hóa IT của bạn bởi vì nguyên tắc kiến trúc được thực thi trong các công cụ MDD 1.1.1 Khái niệm về mô hình Để hiểu rõ hơn về MDD, sau đây sẽ đưa ra một số khái niệm trong MDD như [3], [10]: - Model: mô hình là cách biểu diễn hệ thống được đơn giản giúp hiểu hơn về hệ thống. Mô hình thường được diễn đạt trong một ngôn ngữ đặc tả miền cụ thể hay ngôn ngữ mô hình hóa chung UML. Mô hình được biểu diễn bằng ký hiệu đồ họa. - Metamodel: Một metamodel của một mô hình X miêu tả cấu trúc của mô hình X theo kiểu hợp lệ. Một metamodel có thể được so sánh với cú pháp trong thiết kế ngôn ngữ. Metamodel được đinh nghĩa chính xác như là điều kiện tiên quyết cho chuyển mô hình. 4 Hình 1.1: Ví dụ về hệ thống phân cấp metamodel bốn lớp của UML[3] - Metametamodel: một metametamodel của mô hình X là metamodel được sử dụng để miêu tả metamodel của model X. Nó có thể được so sánh với ngữ pháp của một ngôn ngữ, cái mà được sử dụng để miêu tả ngữ pháp của ngôn ngữ X. Nền tảng được thiết lập tốt và tiêu chuẩn cho việc metametamodel tồn tại như MOF hay Ecore. MOF là một chuẩn của OMG cho việc định nghĩa metamodel. MOF có hai phiên bản: Complete MOF(CMOF) và Essential MOF (EMOF). Một cài đặt của EMOF được sử dụng phổ biến là Ecore, định nghĩa bởi Eclipse Modeling Framework (EMF) Ví dụ trong hình 1.1 chúng ta có các cấp độ của model. Mức M0 là cấp độ dữ liệu người dung, M1 là mô hình dữ liệu ở cấp độ M0. Cấp M2 là mô hình cấp trên của M1, do đó thường được gọi là một metamodel. Cấp M3 được tổ chức một mô hình thông tin của M2 và thường được gọi là metametamodel. 1.1.2 Các chuẩn hướng tiếp cận MDD Hướng tiếp cận MDD vẫn đang được phát triển và được sử dụng rộng rãi trong ngành công nghiệp phần mềm. Hiện nay có nhiều tổ chức tham gia nghiên cứu để thành lập một chuẩn riêng như: MDA (Model Driven Architecture) của tổ chức OMG, MIC (Model Intergrated Computing) của nhóm ISIS đại học Vanderbilt, SF (Software Factories) của công ty Microsoft, và một số chuẩn 5 khác. Trong các chuẩn đó, MDA của OMG được công bố rộng rãi, phát triển rất mạnh trong giới nghiên cứu. Hơn nữa còn được ứng dụng để tạo ra rất nhiều công cụ hỗ trợ trong quá trình xây dựng phần mềm, các công cụ này được phát triển rất nhanh trên môi trường Eclipse [10]. 1.1.3 Kiến trúc MDA MDA do tổ chức OMG đề xuất năm 2000. MDA là một hướng tiếp cận xem việc xây dựng phần mềm là việc chuyển đổi từ mô hình này sang mô hình khác. MDA được đề xuất bắt nguồn từ nhu cầu tồn tại rất lâu là: làm rõ và đặc tả các tác vụ hệ thống, cái nào phụ thuộc vào nền tảng, cái nào không phụ thuộc nền tảng, đồng thời chia ra các mức độ phụ thuộc vào nền tảng. MDA cung cấp một tập các nguyên tắc chỉ dẫn việc xây dựng, đặc tả cấu trúc hệ thống được biểu diễn như là các mô hình. Các mô hình sau đó được sinh bán tự động từ mã nguồn có khả năng thực thi bởi máy chuyển mô hình. MDA dựa trên cách sử dụng có hệ thống các mô hình như là những tác tử kỹ nghệ sơ cấp. Các mô hình được xem như là các lớp thực thể, thay thế mã nguồn. Mã nguồn được sinh ra từ các mô hình, từ bộ khung phát triển tới những sản phẩm hoàn thiện có thể triển khai được. Khi đó, người phát triển chỉ tập trung tới vấn đề (tức là các mô hình) mà không cần quan tâm tới nền tảng cài đặt cụ thể. Ở đây nền tảng có thể là ngôn ngữ cài đặt như Java, PHP… hoặc là các công nghệ như JSF, Spring… được áp dụng. Sự phức tạp của nền tảng cũng là lý do cho thấy phát triển hướng mô hình rất hiệu quả, có tính mềm dẻo, và khả năng khả chuyển cao. Cũng vì lí do đó, MDA được phát triển mạnh mẽ trong giới nghiên cứu và cũng được nhiều công cụ hỗ trợ trong quá trình xây dựng phần mềm[10]. Hướng tiếp cận MDA định hướng các công cụ hỗ trợ xây dựng phải đạt được: Thứ nhất, xác định phần độc lập giữa hệ thống và nền tảng; thứ hai, xác định phần phụ thuộc nền tảng; thứ ba, chọn nền tảng chuyên biệt mà hệ thống phù hợp; thứ tư, chuyển hệ thống từ đặc tả trên nền tảng này sang đặc tả trên nền tảng khác. Trong kiến trúc hướng mô hình MDA, các loại mô hình sau được sử dụng: Mô hình độc lập tính toán(CIM), mô hình độc lập nền (Platform Independent Model), và mô hình phụ thuộc nền (Platform Specific Model). Ba mô hình này biểu diễn các cách nhìn hệ thống từ các khía cạnh khác nhau của hệ thống và mức độ trừu tượng tương ứng với các giai đoạn phân tích, thiết kế và triển khai trong kỹ nghệ phần mềm. 6 - Mô hình độc lập tính toán (CIM): yêu cầu của hệ thống được mô hình hóa trong mô hình độc lập tính toán, CIM miêu tả ngữ cảnh mà hệ thống sẽ sử dụng. Nó có thể ẩn đi nhiều hoặc tất cả thông tin về việc làm thế nào dữ liệu được xử lý trong hệ thống. Có thể gọi mô hình độc lập tính toán là mô hình phân tích, mô hình miền hoặc mô hình nghiệp vụ, phụ thuộc vào ngữ cảnh mà chúng ta sử dụng cho phù hợp. CIM là mô hình của một hệ thống để thể hiện vị trí, vai trò của hệ thống trong môi trường sẽ triển khai nó. Nó giúp chúng ta biểu diễn chính xác những gì mà chúng ta hi vọng hệ thống sẽ thực hiện được. Điều này thật sự hữu ích, không chỉ nhằm hiểu được vấn đề chung của hệ thống mà còn giúp chúng ta có thêm một nguồn thông tin cho việc xây dựng những mô hình khác của hệ thống một cách đúng đắn. CIM đóng vai trò quan trọng trong việc lấp khoảng trống giữa những 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ì. Giúp chúng ta có thể xây dựng ứng dụng đáp ứng các yêu cầu trên những miền cụ thể - Mô hình độc lập nền (PIM): là mô hình độc lập với các đặc điểm của nền tảng. Nó miêu tả hệ thống mà không nêu rõ nó được sử dụng cho nền tảng 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. PIM có thể được sử dụng cho công nghệ máy ảo, một loại nền tảng chung hay các nền tảng trừu tượng. - Mô hình phụ thuộc nền (PSM): được xây dựng cho một nền tảng cụ thể. Nó có nguồn gốc từ một mô hình độc lập nền tảng cộng thêm một số thông tin liên quan. Do đó 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 nền tảng cụ thể. Tuy theo mục đích sử dụng. PSM có thể cung cấp ít hay nhiều thông tin chi tiết cần thiết cho việc tự động sinh ra các thành phần triển khai 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. 1.2 Tổng quan về chuyển mô hình Trong phát triển hướng mô hình một chuỗi các mô hình được tạo ra và duy trì. Mô hình biểu diễn các giai đoạn khác nhau của tiến trình phát triển. Thêm nữa, mô hình có thể thể hiện các khung nhìn khác nhau của hệ thống và biểu diễn các cấp trừu tượng khác nhau của hệ thống. Chuyển mô hình là một khái niệm trọng tâm trong lĩnh vực phát triển hướng mô hình. Chuyển mô hình cung cấp một cơ chế cho việc tự động tạo ra 7 và cập nhật các mô hình đích dựa trên thông tin chứa trên mô hình nguồn. Khi sự chuyển mô hình được định nghĩa chính xác, nó có thể được sử dụng để đảm bảo sự nhất quán giữa các mô hình khác nhau. Hiện nay tồn tại nhiều công nghệ chuyển mô hình, các loại có sự khác nhau giữa miền vấn đề, chẳng hạn đặc thù của vấn đề được giải quyết bởi công nghệ chuyển mô hình và cơ chế, chẳng hạn đặc thù của ngôn ngữ chuyển mô hình. Có 2 kiểu chuyển: Chuyển từ mô hình sang text (M2T) và chuyển mô hình sang mô hình (M2M) 1.2.1 Các thuật ngữ trong chuyển mô hình Sau đây là các thuật ngữ cơ bản về chuyển mô hình [10]: - 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. - Luật chuyển mô hình: Một luật chuyển mô hình trong mô tả là một thực thể nhỏ nhất trong chuyển mô hình. Nó miêu tả cách một phần mô hình nguồn có thể được chuyển tới phần 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ỗi phần xuất hiện của mẫu nguồn trong mô hình nguồn tương ứng một mẫu đích được tạo trong mô hình đích. Trong ngữ cảnh chuyển mô hình dựa trên đồ thị thì mẫu nguồn được gọi là phần bên trái (LHS) và mẫu đích gọi là phần bên phải (RHS) - Mô hình nguồn: trong ngữ cảnh của một chuyển mô hình, một mô hình có thể đóng vai trò như là mô hình nguồn, nếu nó là đầu vào của bước chuyển. Mô hình nguồn tuân thủ metamodel nguồn. Có thể có một hoặc nhiều hơn mô hình nguồn là đầu vào của bước chuyển. - Mô hình đích: trong ngữ cảnh của chuyển mô hình, một mô hình có thể đóng vai trò như là mô hình đích, nếu nó là đầu ra của bước chuyển mô hình. Mô hình đích phải tuân thủ metamodel đích. Một phép chuyển mô hình có thẻ có một hoặc nhiều mô hình đích. Hình 1.2 Mô hình mối quan hệ ở mức metamodel 8 1.2.2 Một số giải pháp sử dụng ngôn ngữ chuyển Sau đây chúng tôi giới thiệu một số ngôn ngữ và công cụ chuyển được quan tâm rộng rãi trong cộng đồng nghiên cứu cũng như trong công nghiệp. Giải pháp sử dụng AGG (Algebraic Graph Transformation)[10] AGG là ngôn ngữ chuyển mô hình theo kiểu đại số. AGG bao gồm tập hợp các đối tượng Node và Edge. Các Node liên kết với nhau thông qua Edge. AGG bao gồm các lớp trung gian giữa hai mô hình nguồn và đích. Mỗi lớp trung gian này là một sự tương ứng giữa một đối tượng của mô hình nguồn và một đối tượng của mô hình đích. Mỗi đối tượng có một định danh phục vụ cho chuyển đổi tương ứng giữa mô hình nguồn và đích. Ngoài ra, đối tượng trong AGG có thể có thuộc tính, kiểu thuộc tính, bao gồm ràng buộc về số lượng đối tượng có thể liên kết với nhau. AGG dựa trên cơ sở chặt chẽ về toán học, đồng thời có khả năng kiểm tra ràng buộc OCL trên mô hình nguồn và mô hình đích. Vì vậy, thường cho ra mô hình đích chính xác. Tuy nhiên, AGG gặp phải hạn chế lớn về vấn đề đặc tả, ngôn ngữ biểu diễn mô hình. Vì vậy, rất khó để có thể áp dụng AGG trong thực tế. Giải pháp sử dụng ATL (ATLAS Transformation Language)[7] ATL là một ngôn ngữ chuyển mô hình tới mô hình. ATL chỉ hỗ trợ phép chuyển 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à 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 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. Query/View/Transformation (QVT)[3] Query/View/Transformation (QVT) là một ngôn ngữ chuẩn cho chuyển mô hình được tạo bởi OMG. QVT sử dụng ngôn ngữ ràng buộc đối tượng (OCL), MOF và được căn chỉnh theo kiến trúc hướng mô hình MDA. QVT đúng như theo tên nó cho phép chuyển 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ó thể được xem như là loại đặc biệt của chuyển mô hình. QVT cũng được tích hợp trong môi trường phát triển Eclipse. QVT định nghĩa ba ngôn ngữ cho chuyển mô hình tới mô hình (M2M). Tất cả chúng hoạt động tren mô hình tuân thủ MOF 2.0 metamodels. 9 - QVT Relational : là một ngôn ngữ chuyển mô hình sơ khai. Cả cú pháp dạng ký tự và dạng đồ họa được định nghĩa cho QVT. Ngôn ngữ này hỗ trợ chuyển mô hình hai chiều. Một phép chuyển được đặc tả như là một tập các quan hệ giữa metamodel nguồn và metamodel đích. Phép chuyển này có thể được sử dụng để kiểm tra tính hợp lệ của hai mô hình. - QVT Core : là ngôn ngữ chuyển mô hình khai báo cấp thấp, là nền tảng cho ngôn ngữ QVT Relational. - QVT Operatinal : là ngôn ngữ chuyển đổi mệnh lệnh (imperative) được thiết kế cho việc phép chuyển theo một hướng duy nhất. 1.3 Tổng kết chương Như vậy trong chương này chúng tôi đã nêu rõ vai trò của phát triển hướng mô hình, các khái niệm về mô hình như model, metamodel…, các chuẩn tiếp cận hướng mô hình. Ngoài ra còn nghiên cứu tổng quan về chuyển mô hình như: các thuật ngữ trong chuyển mô hình, một số giải pháp sử dụng ngôn ngữ chuyển mô hình AGG, ATL, QVT. Trên cơ sở đó để rút ra những ưu điểm và hạn chế của các phương pháp chuyển mô hình trên từ đó nghiên cứu ngôn ngữ chuyển mô hình RTL trong phần tiếp theo. 10 Chương II Ngôn ngữ chuyển mô hình RTL Trong phần này chúng tôi sẽ nghiên cứu và cơ sở hình thức cho RTL như: kiến thức cơ sở về văn phạm đồ thị ba, luật chuyển của văn phạm đồ thị ba ràng buộc OCL từ đó để xác định cú pháp của RTL. 2.1. Cơ sở hình thức cho RTL Chuyển đổi mô hình có thể được xem như là trung tâm của phương pháp tiếp cận hướng mô hình, chẳng hạn như phương pháp tiếp cận mô hình trung tâm phát triển phần mềm (giống như các phương pháp tiếp cận dựa trên UML) và mô hình hướng công nghệ (MDE). Trong phương pháp tiếp cận, đồ thị là một đại diện tất nhiên cho các mô hình từ khi hầu hết các ngôn ngữ mô hình được hình thức hóa bởi một khung nhìn cú pháp trừu tượng xác định. Trong ngữ cảnh chuyển đổi đồ thị này là một cách tiếp cận đầy triển vọng cho chuyển đổi mô hình, đặc biệt là đối với những chuyển đổi phức tạp. Ưu điểm của phương pháp tiếp cận này là các luật chuyển đổi đồ thị có thể tạo dễ dàngvà được đặc tả bằng trực giác. Ngoài ra, sự phức tạp của luật chuyển đổi đồ thị cũng như hình thức áp dụng có thể được ẩn đối người dùng. Chuyển đồ thị là một cơ chế để xác định và áp dụng các biến đổi giữa các đồ thị cái gọi là luật viết lại đồ thị ( luật chuyển đổi đồ thị ). Đồ thị viết lại là một phần mở rộng của kỹ thuật viết lại trong ngữ pháp Chomsky. Một luật đồ thị chuyển đổi bao gồm hai đồ thị tương ứng bên trái (LHS)và phía bên phải (RHS) của luật này. Đối với mỗi luật tương ứng, các nút và cạnh trong LHS được kết hợp với các nút và các cạnh nhất định trong đồ thị ban đầu. Sau đó, các nút và cạnh phù hợp mà không tồn tại trong RHS được loại bỏ từ đồ thị ban đầu. Các nút và các cạnh còn lại trong RHS được xem như là mẫu cho việc tạo ra các nút mới và các cạnh trong đồ thị ban đầu. Để tăng sự tích hợp của chuyển đổi đồ thị và phương pháp tiếp cận hướng mô hình, đồ thị có thể được mở rộng để đồ thị thuộc tính đại diện các mô hình . Ở đây, các mô hình được nhìn thấy như sơ đồ đối tượng (Object diagram trong UML). Không giống như các phương pháp tiếp cận khác, ở đây nút và các cạnh của đồ thị thuộc tính là kiểu khác đồ thị thuộc tính (hay gọi là một đồ thị kiểu – type graph), trong các nút và các cạnh của đồ thị thuộc tính là kiểu của tổng đại số A Trong cách này kiểu và ngữ nghĩa của đồ thị thuộc tính có thể 11 được xác định dựa trên OCL. Điều này cho phép chúng ta vượt qua khó khăn với kiểu đồ thị thuộc tính như làm thế nào để giải thích các yếu tố trong tập hợp, kế thừa trong các metamodel [3], [4], [8]. 2.1.1 Kiến thức cơ sở về văn phạm đồ thị ba Văn phạm đồ thị ba (TGGs) đã được đầu tiên chính thức đề xuất trong [9]. Mục đích của họ là để giảm bớt sự mô tả của biến đổi phức tạp trong công nghệ phần mềm. TGGs cho phép chúng ta cấu trúc bản đồ văn phạm hai đồ thị để đồ thị tạo ra văn phạm đồ thị có thể được liên quan với nhau. Việc lập bản đồ giữa hai văn phạm đồ thị được thực hiện bằng cách chèn thêm một văn phạm đồ thị để xác định sự tương ứng giữa các yếu tố của chúng. Trong cách này, luật ba (triple rule) thu được là một thành phần của ba luật đối với văn phạm đồ thị bên trái, bên phải, và kết nối. Sau đó, nguồn gốc bộ ba (triple) có thể được xem như là một thành phần tương ứng của luật ba văn phạm đồ thị trong TGGs. Tích hợp đồ thị thu được bằng bộ ba được gọi là đồ thị ba. Từ một luật ba, chúng ta có thể lấy được những luật ba mới như tiến(forward), ngược(backward) mô hình tích hợp, và mô hình phát triển. Thông qua các kịch bản hoạt động, sự tương ứng giữa các mô hình nguồn và đích được thành lập. Để thúc đẩy sự tích hợp của TGGs và phương pháp tiếp cận hướng mô hình, chúng ta mở rộng đồ thị ba đến đồ thị thuộc tính ba. Không giống như những kiểu đồ thị thuộc tính ba đang làm việc, phương pháp tiếp cận ở đây các cạnh và nút của đồ thị thuộc tính ba là kiểu tổng đại số A. Mục tiêu của chúng ta là đưa ra các diễn giải của OCL. Ngoài ra, cách tiếp cận dựa trên OCL cho phép chúng ta hạn chế sự tương ứng một phần của luật ba bởi các điều kiện OCL. Văn phạm đồ thị ba (TGG) là sự mở rộng của chuyển đổi đồ thị để cung cấp khả năng mô tả các chuyển đổi phức tạp trong công nghệ phần mềm. Phương pháp đặc tả này cho phép khai báo các chuyển hai chiều giữa các ngôn ngữ đồ thị khác nhau. Cụ thể, TGG cho phép chúng ta thiết lập tương ứng giữa hai đồ thị thuộc văn phạm nguồn và đích bằng cách chèn thêm một văn phạm để liên hệ hai văn phạm đó. Trong cách này, luật chuyển đồ thị ba thu được gồm 3 thành phần: luật vế phải, luật vế trái, và luật kết nối. Đồ thị tích hợp thu được bằng dẫn xuất luật đồ thị ba được gọi là đồ thị ba [3]. - Định nghĩa 1 (Đồ thị, ánh xạ đồ thị): Đồ thị G =(GV ,GE, sG, tG), GV là các đỉnh, GE là các cạnh, các hàm sG, sT: GE → GV xác định định nguồn và đích của một cạnh. Cho đồ thị G, H có ánh xạ đồ thị f= (fV, fE): G→H gồm có 12 hai ánh xạ fV: GV→GE và fE: GE→HE là tương ứng định và cạnh trong đó fVo sG=sH o fE và fV o tG = tH o fE. - Định nghĩa 2: Bộ (G, typeG) của đồ thị G=(V,E,s,t) cùng với đồ thị ánh xạ typeG: G→ TG, ở đây TG được gọi là đồ thị kiểu và G là một thể hiện của TG. Cho đồ thị G= (G, typeG) và H=(H, typeH), f là đồ thị ánh xạ giữa G và H khi f: G→ H và typeH o f = typeG. - Định nghĩa 3 (Đồ thị ba, ánh xạ đồ thị ba): Ba đồ thị SG, CG, TG lần lượt là đồ thị nguồn, đồ thị đích, đồ thị kết nối, cùng với hai đồ thị ánh xạ sG: CG → SG và tG : CG → TG tạo thành đồ thị ba G =(SG sG← CG →tG TG) . G gọi là rỗng nếu, SG, CG và TG là đồ thị rỗng. Đồ thị ánh xạ ba m= (s,c,t): G->H giữa hai đồ thị triple G = (SG sG← CG →tG TG) và H = (SH sH← CH →tH TH) gồm có ba đồ thị ánh xạ s : SG → SH, c : CG → CH và t : TG → TH trong đó s ◦ sG = sH ◦ c và t ◦ tG = tH ◦ c - Định nghĩa 4 (Văn phạm đồ thị ba): Luật chuyển ba tr = L →tr R bao gồm đồ thị ba L và R và ánh xạ ba tr sao cho Cho luật chuyển ba tr = (s, c, t) : L → R, đồ thị triple G và ánh xạ ba m = (sm, cm, tm): L → G, gọi là khớp ba m, các bước chuyển đổi đồ thị triple G ⇒tr,m H từ G tới đồ thị triple H được cho bởi ba đổi tượng SH, CH và TH trong loại đồ thị bao gồm ánh xạ sH : CH → SH và tH : CH → TH. Ánh xạ n = (sn, cn, tn) được gọi là comatch. Văn phạm đồ thị ba là cấu trúc TGG= (TG, S, TR), trong đó TG là đồ thị kiểu, S là đồ thị khởi đầu và TR={tr1,tr2, tr3, ….., trn} là tập các luật chuyển ba.  Phương pháp chuyển mô hình dựa vào văn phạm đồ thị ba: Mô hình trong tiếp cận của được xem là các đồ thị. Để biểu diễn mô hình nguồn, đích và sự kết nối giữa chúng, chúng ta sử dụng văn phạm đồ thị ba. Từ một luật chuyển 13 đồ thị ba chúng ta có thể dẫn xuất thành các luật cho chuyển mô hình tiến (nguồn sang đích), ngược (đích sang nguồn) và tích hợp. - Định nghĩa 5 (Các luật dẫn xuất): Mỗi luật chuyển ba tr = L→R dẫn xuất ra các luật chuyển tiến, ngược và tích hợp được xác định như sau: Hình 2.1 Luật chuyển đồ thị ba và bước chuyển với luật chuyển tiến - Định lý 1. (Chuyển với các luật dẫn xuất): Cho TGG = (TG, S, TR) là văn phạm đồ thị ba và G =(Gs ← SC → ST) là đồ thị ba định kiểu bởi TG. Một chuyển tiến từ đồ thị nguồn GS sang đồ thị đích GT khi các điều kiện sau thỏa mãn: với mi là các khớp ba, trong đó (sni, cni, tni) là các comatch của mi. 2.1.2 Luật chuyển TGGs ràng buộc OCL Ý tưởng cơ bản cho việc tích hợp TGGs và OCL[3] Phần này giải thích ý tưởng cơ bản phương pháp tiếp cận bằng một ví dụ cụ thể. Chúng ta xem xét một tình huống điển hình trong phát triển phần mềm, ở đây muốn nói đến mối quan hệ giữa mô hình khái niệm và một mô hình thiết kế. Hình 2.2 cho thấy sự tương ứng giữa một liên kết đầu ở bên trái trong một mô hình khái niệm với một thuộc tính và hoạt động bên phải 14 bên trong một mô hình thiết kế. Ví dụ, chúng ta nhận ra rằng sự liên kết đầu customer được ánh xạ tới các thuộc tính customer và hành động GetCustomer() của lớp Order Hình 2.2 : Mô hình khái niệm bên trái tương ứng với mô hình thiết kế bên phải Chúng ta muốn thể hiện yêu cầu đó, khi chúng ta thêm một mối liên hệ giữa customer và Order trong mô hình khái niệm, các lớp tương ứng trong mô hình thiết kế sẽ tự động được mở rộng với các thuộc tính mới và hàng động mới. Vì vậy, sự tương ứng giữa liên kết đầy trong mô hình với các thuộc tính và hoạt động trong mô hình thiết kế đã được hình thành một cách chính thức. Hình 2.3: Chuyển đổi dưới dạng biểu đồ như một metamodel Kịch bản này là chuyển đổi mô hình giữa các sơ đồ lớp UML và QVT cũng như TGGs có thể tiếp cận các yêu cầu. Hình 2.3 cho thấy chuyển đổi dưới dạng biểu đồ như một metamodel. Phía bên trái cho thấy các metamodel cho các domain khái niệm, phía bên phải hiển thị các metamodel cho domain thiết kế và phần giữa là kết nối tương ứng giữa chúng. Sau đó chúng ta sẽ thấy, sơ đồ trong hình. 2.3 có thể được xem như là một biểu đồ thể hiện cho các metamodels 15 với các mũi tên đứt đoạn được biểu diễn như là các đối tượng thuộc các lớp từ phần giữa. Một luật TGG cũng như các ánh xạ QVT có thể thực hiện một hành động như có thêm một liên kết, cập nhật các thuộc tính và các hoạt động như được giải thích dưới đây[3],[6]. a, TGGs và OCL cho ví dụ chuyển đổi Hình 2.4 cho thấy luật chuyển ba addAssociation tích hợp OCL trong QVT like style. LHS tương ứng với phần bảo vệ, và RHS tương ứng phần phía dưới. LHS được bao gồm trong RHS. Ràng buộc OCL luật chuyển ba trong hình 2.4 được thể hiện tương ứng trên đầu và dưới của LHS và RHS. Các ràng buộc OCL có thể không chỉ được sử dụng để hạn chế các giá trị thuộc tính trong mô hình bảo vệ và dưới cùng, nhưng chúng cũng có thể thể hiện thêm những hạn chế chung về đồ thị như một biểu đồ đối tượng Luật TGG cổ điển không thể hiện ràng buộc OCL. Cách tiếp cận của ở đây cho phép thêm ràng buộc OCL trong tất cả các bộ phận và do đó cho phép một hình thức chung để hạn chế việc áp dụng luật cũng như mô tả kết quả làm mịn của các ứng dụng luật, để mô tả cập nhật thuộc tính đối tượng. Biểu thức OCL chung, có chuyển qua đầy đủ đồ thị mà luật được áp dụng. Đánh giá của các biểu thức OCL được thực hiện trước khi đồ thị làm việc được sửa đổi bởi luật. Các luật chuyển ba thể hiện trong hình. 2.4 làm như sau. Khi được áp dụng, đối tượng Assoc được tạo ra để đại diện cho một liên kết trong miền khái niệm. Kết quả viết lại đồ thị trong miền thiết kế, tức là, đối tượng attr và các đối tượng Op đại diện cho các liên kết được tạo ra. Các tương ứng giữa các liên kết, các thuộc tính mới và hoạt động được thiết lập bởi viết lại đồ thị trong miền tương ứng. Các ràng buộc OCL cho phép chúng ta kiểm tra khả năng áp dụng của các luật và cập nhật các giá trị thuộc tính trong miền thiết kế. b,Yêu cầu để tích hợp OCL trong TGGs Yêu cầu tích hợp OCL trong TGGs như sau: • Hỗ trợ công thức OCL cho các biểu thức thuộc tính. • Hỗ trợ OCL tiền (pre) và hậu(post) điều kiện các luật chuyển ba. • Hỗ trợ ràng buộc về metamodel cho các phần tương ứng của các quy tắc TGG. Giả sử rằng tất cả các ràng buộc phải được thực hiện từ luật TGG. Ngoài ra, sự tích hợp của TGGs và OCL yêu cầu biến thể của TGGs. Một nút trong miền tương ứng có thể được kết nối với nhiều nút trong miền còn lại. Đây là một biến thể của TGGs vì trong bản gốc TGG ánh xạ chỉ là 1-1. Trong 16 phần mở rộng , luật TGG có thể được xóa, nhưng ngược lại nếu chúng đã định nghĩa từ ban đầu thì luật TGG là không được xóa. Hình 2.4: Luật chuyển ba addAssociation tích hợp OCL c, Điều kiện OCL cho luật chuyển ba Trong phần này, xác định áp dụng điều kiện OCL của luật chuyển ba. Vì hạn chế trong các phần nguồn và đích, luật chuyển ba là xác định độc lập, điều kiện áp dụng luật chuyển ba có thể được định nghĩa là một kết hợp điều kiện trước và sau trong các phần nguồn, đích và kết nối tương ứng của luật chuyển ba. - Điều kiện OCL cho các phần nguồn và đích Điều kiện OCL cho nguồn hoặc đích của luật chuyển ba là áp dụng điều kiện OCL của một luật đơn giản tương ứng với phần này. Chúng ta có thể sử dụng điều kiện OCL để hạn chế một số luật , vì một mặt, LHS và RHS của luật là các đồ thị thuộc tính. Mặt khác, các nút của đồ thị thuộc tính phù hợp với một mô hình đối tượng M trùng với các điều khoản OCL. Điều này cho phép chúng ta sử dụng điều kiện OCL như một ràng buộc trên đồ thị thuộc tính. Định nghĩa 6. (Ràng buộc OCL trên đồ thị thuộc tính) Một ràng buộc OCL e trên đồ thị thuộc tính là một thuật ngữ logic OCL nó có thể được đánh giá trong bất kỳ minh hoạ I(a,b) của đồ thị. Đồ thị (không) 17