Khóa luận Một số vấn đề về phát triển phần mềm hướng mô hình

không cần thiết với sự trừu tượng hiện tại của mô hình. Những thông tin này chỉ liên quan tới các công cụ hay các xử lý trong quá trình chuyển đổi mô hình. Ví dụ, một mô hình phân tích UML bao gồm các thực thể với các kiểu chuỗi có thể được gán nhãn là có độ dài cố định hay thay đổi, hoặc nó có thể được gán nhãn để chỉ ra độ dài tối đa. Từ góc nhìn phân tích, chỉ cần chỉ ra kiểu dữ liệu chuỗi là đủ. Tuy nhiên, khi chuyển đổi một thuộc tính kiểu chuỗi sang một kiểu của một cột trong cơ sở dữ liệu thì những thông tin thêm vào là cần thiết để hoàn thành việc chuyển đổi. Meta - Modeling Ứng dụng của MDA đòi hỏi các mô hình, PIM hay PSM, phải được miêu tả trong các ngôn ngữ chặt chẽ đầy đủ phù hợp cho sự thông dịch tự động bằng máy tính. Vì các ngôn ngữ mô hình như UML thường có hình thức đồ họa nên những phương pháp truyền thống như Backus Naur Form (BNF), phương pháp rất thành công trong việc định nghĩa các ngôn ngữ hình thức text (text-form language), là không phù hợp. Cần phải có các kỹ thuật khác để định nghĩa các ngôn ngữ mô hình trong MDA. Nói một cách khác, những kỹ thuật này cần có thể miêu tả cú pháp và ngữ nghĩa chặt chẽ. Hoặc nó cần hỗ trợ sự mở rộng của các ngôn ngữ mô hình. Giải pháp là một khung làm việc meta-modeling dựa trên nền của kiến trúc metadata 4 lớp truyền thống. Khái niệm của meta-modeling Khái niệm meta-modeling được đề xuất như một giải pháp để giải quyết những vấn đề sau: Các hệ thống trong những miền khác nhau hoặc các phần khác nhau trong một hệ thống phức tạp thường được mô hình bằng những kỹ thuật hình thức khác nhau phù hợp nhất để miêu tả các hành vi của chúng. Nhu cầu kiểm tra các hành vi tổng quan của hệ thống với những phần khác nhau được miêu tả bằng những kỹ thuật hình thức(formalism) khác nhau. Về căn bản meta-modeling là để sử dụng một ngôn ngữ mô hình phù hợp để mô hình những kỹ thuật khác nhau. Mỗi kỹ thuật được miêu tả như những cấu trúc phù hợp có thể được biểu diễn trong ngôn ngữ. Dựa trên meta-model chung này, ta có thể tạo một công cụ hỗ trợ tất cả những kỹ thuật này. Hơn nữa, những sự chuyển đổi giữa các mô hình được miêu tả trong những kỹ thuật khác nhau cũng có thể miêu tả rõ ràng. Kỹ thuật quan hệ thực thể và lược đồ lớp UML thường được dùng cho meta-modeling. Khung làm việc meta-modeling MOF Meta Object Facility (MOF), chuẩn kiến trúc metadata được đề xuất bởi OMG, dựa trên kiến trúc metadata 4 lớp truyền thống. Lớp M0: Các thể hiện Lớp M0 là nơi những thể hiện thực của hệ thống tồn tại. Ví dụ, những khách hàng “Dr. Joe Nobody” và “Mr. Mark Everyman” là các thể hiện trong hệ thống thực. Lớp M1: Mô hình của hệ thống Lớp M1 chứa các mô hình của hệ thống. Ví dụ, ở lớp này khái niệm “Khách hàng” được định nghĩa: một lớp UML tên “Khách hàng” có 2 thuộc tính UML “vai trò” và “họ tên”. Mỗi thành phần ở lớp M0 là một thể hiện của một thành phần ở lớp M1. Ví thế, cả “Dr. Joe Nobody” và “Mr. Mark Everyman” là những thể hiện của “Khách hàng” Lớp M2: Mô hình của mô hình Một thành phần ở lớp M2 chỉ rõ các thành phần ở lớp M1. Các thành phần ở lớp M1 là những thể hiện của các thành phần ở lớp M2. Ví dụ, trong lớp M2 khái niệm “Lớp UML” và “Thuộc tính UML” được định nghĩa. Lớp UML “Khách hàng” và “Hóa đơn” là những thể hiện của “Lớp UML” ở lớp M2. Lớp M3: Mô hình của M2 Tương tự, mỗi thành phần ở lớp M2 được định nghĩa ở lớp M3. Trong khung làm việc meta-modeling, MOF là ngôn ngữ M3 chuẩn, tất cả các ngôn ngữ mô hình là những thể hiện của MOF. Hình 2.4: Một ví dụ trong khung làm việc meta-model MOF Tầm quan trọng của meta-modeling trong MDA Meta-modeling cung cấp cơ sở để miêu tả và chuyển đổi các mô hình trong MDA. Điều này được chứng minh qua 2 phần: Nó được dùng để miêu tả các mô hình nguồn và mô hình đích. Trong MDA, cả PIM và PSM được miêu tả trong các ngôn ngữ mô hình M2 (các meta-model). Nó được dùng để miêu tả những sự chuyển đổi mô hình. Trong MDA, những sự chuyển đổi mô hình được chỉ rõ bởi một tập các luật được định nghĩa theo thuật ngữ của các meta-model tương ứng. Một vài vấn đề trong khung làm việc meta-model hiện tại Mặc dù khung làm việc meta-modeling có thể mở rộng được công nhận là một điều kiện tiên quyết của ứng dụng MDA, vẫn không có sự thống nhất về hình thức của khung làm việc này. Gần đây có nhiều thảo luận về những vấn đề tồn tại trong khung làm việc MOF. Nhiều nhà nghiên cứu đã tham gia vào lĩnh vực này và một vài giải pháp chưa đầy đủ đã được đề xuất. Meta-modeling chặt chẽ Khung làm việc meta-modeling MOF có đặc điểm là một meta-modeling rất chặt chẽ. Định nghĩa chính xác của khái niệm này được thể hiện như sau: Trong một kiến trúc mô hình mức n, M0, M1, Mn-1, mọi thành phần của một mô hình mức Mm phải là một thể hiện của chính xác một thành phần của một mô hình mức Mm+1 Hạn chế này có nghĩa rằng trong khung làm việc meta-model MOF: Khung làm việc meta-modeling thực hiện theo hình thức cây phân cấp tuyến (linear hierachy) Các mức được hình thành chỉ bởi các quan hệ “là thể hiện của”. Các mức có những cận chặt chẽ không thể vượt qua bởi quan hệ khác ngoài quan hệ “là thể hiện của” Quan hệ “là thể hiện của” chỉ tồn tại giữa 2 mức liền kề. Các vấn đề nảy sinh bởi sự hạn chế của meta-modeling chặt chẽ Vì meta-modeling chặt chẽ hạn chế quan hệ “là thể hiện của” chỉ ở 2 mức liền kề, một mô hình chỉ có thể định nghĩa ngữ nghĩa của các thể hiện trực tiếp của nó, và không thể ảnh hưởng đến những thực thể được tạo bởi những bước thể hiện xa hơn. Kỹ thuật thể hiện này được gọi là “shallow instantiation”, gây nên một vài vấn đề cơ bản khi các meta-level mở rộng nhiều hơn 2 mức. UML 2.0 và giải pháp MDA meta-modeling UML 2.0 hỗ trợ giải pháp cho khung làm việc meta-modeling MDA. Trong UML 2.0, định nghĩa của UML được tổ chức làm 2 phần : Cơ sở hạ tầng miêu tả khung làm việc tổng quan trong đó mô hình UML được thực hiện Siêu cấu trúc bên trong(populate) khung làm việc với các khái niệm mô hình hình thành nên ngôn ngữ mô hình UML. Trừ phi một khung làm việc meta-modeling nền tảng được cung cấp, nếu không thành công của MDA là không thể. Các chuẩn MOF, UML, XMI, XML, OCL với việc mô hình hóa và chuyển đổi mô hình Một chìa khóa quan trọng để tích hợp thành công cũng như đạt được sự liên tác và quản lý các siêu dữ liệu độc lập với các ứng dụng, các nền, các công cụ và các cơ sở dữ liệu cũng như dễ dàng thực hiện các chuyển đổi trong MDA là việc đưa ra các chuẩn cơ bản của OMG cho MDA bao gồm: CWM, MOF, UML và XMI. Hình 2.5: Mối liên hệ giữa các chuẩn của OMG MOF (Meta Object Facility) cung cấp chuẩn mô hình hóa và các cấu trúc chuyển đổi được dùng trong MDA. Các mô hình chuẩn khác của OMG, bao gồm UML, CWM, được định nghĩa dựa trên những khái niệm cấu trúc của MOF. Những thành phần cơ bản này cung cấp cho việc chuyển đổi và khả năng liên tác giữa các mô hình/siêu dữ liệu, và cung cấp một cơ chế để các mô hình được phân tích thành XMI. MOF cũng định nghĩa các giao diện cho phép chỉnh sửa các mô hình. Chúng được định nghĩa trong IDL và được mở rộng trong JAVA. Bất kỳ ngôn ngữ mô hình hóa nào được dùng trong MDA phải được xây dựng dựa trên những khái niệm của ngôn ngữ MOF, điều đó giúp cho việc chuẩn hóa các dữ liệu metadata, và đó là điều kiện đầu tiên để thực hiện các chuyển đổi tự động. CWM (Common Warehouse Metamodel) là một chuẩn data warehouse của OMG. CWM được dùng để thiết kế, xây dựng và quản lý các ứng dụng data warehouse. Đây là một ví dụ của việc áp dụng mô hình MDA cho một miền ứng dụng. UML (Unifiied Modeling Language) cung cấp các chuẩn trừu tượng để đơn giản hóa việc làm tài liệu, hiểu và bảo trì các hệ thống phần mềm phức tạp. Cơ chế mở rộng của UML cho phép chúng ta dễ dàng xây dựng các mô hình cho hệ thống và đặc tả chúng một cách chính xác và chi tiết. Ngoài ra, UML còn cung cấp UML Profile, cho phép chúng ta đặc tả các chi tiết gần hơn tới mô hình cài đặt, cũng như cho phép xây dựng các ánh xạ, các luật cho việc chuyển đổi. UML là một ngôn ngữ mô hình hóa và không phải là một ngôn ngữ lập trình. Là một ngôn ngữ mô hình hóa, UML cho phép người phát triển làm việc ở mức trừu tượng cao mà ít quan tâm tới các công nghệ, nền cụ thể, do đó làm giảm độ phức tạp của hệ thống, trực quan, dễ nắm bắt hệ thống hơn. UML chuẩn có thể được mở rộng cho từng dự án cụ thể nếu cần bằng cách dùng các UML profiles. Những ngữ nghĩa mới có thể được thêm vào cùng với các phần tử UML đã có để định nghĩa các khuôn mẫu (stereotypes), các giá trị đích và các ràng buộc. UML nhanh chóng hướng người phát triển tới kiến trúc (cấu trúc ở mức cao và các mối liên hệ) của các hệ thống cụ thể. Để đạt được hiệu quả đó giống như một công cụ mô hình hóa, các biểu đồ UML biểu diễn hệ thống ở mức trừu tượng cao, ẩn đi nhiều chi tiết mức thấp. Cùng với thời gian, người dùng UML nhận ra rằng cách tốt nhất để đạt được mục đích của mình là áp dụng MDA, mà trong đó, các mô hình UML được chuyển đổi tự động từ mức trừu tượng cao hơn tới trừu tượng thấp hơn và cuối cùng là chuyển đổi thành mã nguồn của một ngôn ngữ lập trình được lựa chọn. Mặc dù không phải là một yêu cầu bắt buộc nhưng UML là một công nghệ chính cho việc phát triển phần mềm theo hướng MDA và là nền tảng cho 99% các dự án phát triển theo hướng này. XMI (XML Metadata Interchange) là một kỹ thuật chuyển đổi chuẩn giữa các công cụ, các kho dữ liệu và phần mềm trung gian khác nhau. XMI có thể được dùng để tự động cung cấp XML DTDs từ các mô hình UML và MOF. XMI được dùng để diễn tả các mô hình UML (dùng UML XMI DTD), data warehouse và các cơ sở dữ liệu (dùng CWM XMI DTD), các định nghĩa giao diện CORBA (dùng IDL DTD), các lớp và giao diện Java (dùng Java DTD). XMI cùng kết hợp với các chuẩn mô hình hóa (UML), siêu mô hình/siêu dữ liệu (MOF và XML) và các phần mềm trung gian (UML profiles cho Java, EJB, IDL, EDOC .v.v..) đóng vai trò nòng cốt trong việc dùng XML cho MDA. OCL – Object Constraint Language là một ngôn ngữ biểu diễn các thông tin thêm và các thông tin cần thiết cho các mô hình được dùng trong mô hình hóa hướng đối tượng, và thường được dùng kết hợp với UML.Bằng cách dùng kết hợp với OCL, các mô hình UML bao gồm nhiều thông tin hơn. Nhiều thông tin của hệ thống không thể mô tả hết nếu chỉ dùng UML. Những thông tin này chỉ có thể được biểu diễn thông qua các biểu thức OCL. Đã có nhiều ý kiến cho rằng một bước tiến mới trong phát triển phần mềm chính là việc kết hợp UML với OCL để xây dựng các mô hình cho hệ thống. Các công cụ mô phỏng một hệ thống, sinh ra mã nguồn từ mô hình, và các công cụ hỗ trợ MDA cần phải có các mô hình đầu vào chi tiết hơn và rõ ràng hơn. Chất lượng đầu ra của các công cụ này phụ thuộc phần lớn vào chất lượng của các mô hình được dùng làm đầu vào. Các công cụ sinh ra mã nguồn từ UML/OCL làm cho quá trình phát triển hiệu quả hơn. OCL là một ngôn ngữ chính xác, không nhập nhằng và dễ hiểu. Nó cũng là một ngôn ngữ định kiểu. OCL là môt ngôn ngữ khai báo, trạng thái của hệ thống không thay đổi sau khi thực hiện các biểu thức OCL. UML/OCL thường được dùng để xây dựng các mô hình độc lập nền. Áp dụng mẫu trong chuyển đổi mô hình Các mẫu đóng một vai trò quan trọng trong hầu hết các dự án phát triển áp dụng MDA. Như chúng ta đã biết, việc chuyển đổi thành công PIM sang PSM và từ PSM tới mã yêu cầu PIM phải bao gồm các thông tin chi tiết để các công cụ có thể xử lý chuyển đổi. Việc thêm chi tiết thông tin này có thể được làm bằng cách áp dụng các mẫu thay vì thêm vào một cách thủ công. Do tầm quan trọng của mẫu trong MDA nói chung và chuyển đổi mô hình nói riêng, sau chúng tôi sẽ đi vào chi tiết của việc áp dụng mẫu trong chuyển đổi MDA ở phần sau. Kết luận Kỹ nghệ phần mềm hướng mô hình ngày càng nhận được nhiều sự quan tâm của giới công nghệ thông tin. Chính vì chuyển đổi mô hình là một trong hai vấn đề trọng tâm nhất của kỹ nghệ phần mềm (mô hình hóa và chuyển đổi mô hình) nên nó có được một sự quan tâm đặc biệt. Qua chương này, chúng tôi đã giúp người đọc hiểu sâu hơn về phát triển phần mềm hướng mô hình, giúp cho người đọc dễ dàng nắm bắt những kỹ thuật phức tạp hơn khi nghiên cứu về vấn đề này. Hiện nay, nhiều hướng nghiên cứu mới đang được đưa ra tại nhiều viện nghiên cứu, nhiều hội thảo khoa học, và đã đạt được những thành công nhất đinh. Chúng tôi tin rằng những thành công đó sẽ góp phần vào việc hiện thực hóa kỹ nghệ hướng mô hình, mà MDA là một ví dụ xác đáng nhất. Chương 2. NGÔN NGỮ CHUYỂN ĐỔI MÔ HÌNH MTL Để hiện thực hóa quy trình phát triển phần mềm hướng mô hình, các công cụ phát triển phải hỗ trợ tự động hóa sự chuyển đổi mô hình. Các công cụ này không chỉ cần phải cung cấp khả năng áp dụng những sự chuyển đổi được định nghĩa trước mà còn phải cung cấp một ngôn ngữ cho phép người dùng định nghĩa sự chuyển đổi mô hình và thực thi chúng theo các yêu cầu riêng. Nói cách khác, những cài đặt cho ngôn ngữ chuyển đổi không chỉ hỗ trợ phát triển phần mềm hướng mô hình mà còn phải nâng cao năng suất và chất lượng của sự phát triển. Trong chương này, chúng tôi sẽ tìm hiểu những yêu cầu của ngôn ngữ chuyển đổi mô hình nói chung và đi sâu vào ngôn ngữ MTL nói riêng. Những yêu cầu của ngôn ngữ chuyển đổi mô hình Để ngôn ngữ chuyển đổi được thực hiện tự động hóa bởi các công cụ cũng như hỗ trợ những nhà phát triển mô hình, nó cần hỗ trợ những đặc trưng sau [8]: Có thể thực thi. Được cài đặt hiệu quả. Biểu diễn đầy đủ, không nhập nhằng những sự chuyển đổi mô hình hiện tại (thêm, thay đổi hay xóa các thành phần mô hình) cũng như tạo mô hình mới hoàn toàn. Tăng năng suất làm việc của các nhà phát triển với những mô tả rõ ràng, ngắn gọn và chính xác: Ngôn ngữ cần phân biệt rõ ràng mô tả của những luật lựa chọn các thành phần mô hình nguồn với những luật tạo ra các thành phần mô hình đích. Ngôn ngữ cần cung cấp các thành phần đồ họa biểu diễn các khái niệm trong hình thức trực quan ngắn gọn và trực giác hơn so với hình thức văn bản. Ngôn ngữ cần có thể khai báo bằng cách tạo ngầm định các khái niệm hoặc kỹ thuật bất kỳ có thể thông dịch trực tiếp từ ngữ cảnh Cung cấp một phương tiện kết hợp những sự chuyển đổi để tạo nên những sự chuyển đổi hợp thành, cung cấp ít nhất các toán tử để sắp xếp, chọn lựa có điều kiện và lặp qua những sự chuyển đổi. Cung cấp một phương tiên để định nghĩa các điều kiện cho phép sự chuyển đổi được thực thi. Tuy nhiên, hiện nay vẫn chưa có một ngôn ngữ chuẩn nào chúng ta có thể dựa trên để viết định nghĩa sự chuyển đổi. Chính vì thế OMG đề xuất MOF 2.0 QVT [5] nhằm cung cấp một ngôn ngữ và khung làm việc chuẩn để định nghĩa sự chuyển đổi mô hình trong MDA. Theo đó, có rất nhiều ngôn ngữ, công cụ và cách tiếp cận cho sự chuyển đổi mô hình đã được đưa ra, đặc biệt là ngôn ngữ chuyển mô hình MTL [13] trong khung làm việc Umlaut NG. Chúng ta hãy phân tích ngôn ngữ này. Ngôn ngữ chuyển đổi mô hình MTL Tổng quan về MTL Ngôn ngữ chuyển đổi mô hình MTL là một ngôn ngữ hướng đối tượng mệnh lệnh, được nhóm Triskell ở Inrial phát triển để thí nhiệm với những ý tưởng mới trong ngữ cảnh của tiến trình chuẩn hóa MOF 2.0 QVT. Yêu cầu của MTL là trở thành một ngôn ngữ độc lập với sự biểu diễn của mô hình (và metamodel), và có thể tương tác trong một cách thống nhất với một vài loại kho dữ liệu mô hình như MDR của Sun, ModFact của Lip6 và EMF của IBM. Ví dụ, một sự chuyển đổi MTL được viết cho một mô hình, sau đó có thể được áp dụng tới mô hình khác độc lập ngôn ngữ dùng để biểu diễn metamodel của các mô hình. Như một công cụ trung tâm, MTL giúp kiểm tra và tổ chức những lĩnh vực nghiên cứu và công cụ khác nhau liên quan đến chuyển đổi mô hình cùng chia sẻ những khái nhiệm chung: các mô hình và các meta-model. MTL được thiết kế với những nguyên tắc kỹ nghệ phần mềm rất mạnh, ví dụ như tính mở rộng và tính mạnh mẽ. Vì những sự chuyển đổi mô hình có thể khá phức tạp, những nhà phát triển sự chuyển đổi cần có thể tái sử dụng những kinh nghiệm và thực tế tốt nhất của kỹ nghệ phần mềm. Nói cách khác, sự chuyển đổi phải được thiết kế, mô hình, kiểm thử,…Vì vậy ngôn ngữ MTL sử dụng một loại hướng đối tượng tương tự với những ngôn ngữ phổ biến như Java và C#. Một trong những đặc trưng đặc biệt là các thành phần của mô hình và các lớp của ngôn ngữ được thao tác trong một cách thống nhất. Không có sự khác biệt giữa định hướng hoặc chỉnh sửa một mô hình sử dụng các lớp chuyển đổi. Ví dụ, cả 2 đều sử dụng cùng những khái niệm lớp, thuộc tính, sự kết hợp,…Những thực tế tốt nhất hiển nhiên bao gồm khả năng áp dụng cách tiếp cận MDA tới bản thân sự chuyển đổi. Điều này thể hiện trong MTL với một tiến trình “tự hoàn thiện” - những thành phần của động cơ chuyển đổi được viết sử dụng chính động cơ. MTL được phân phối như một phần mềm mã nguồn mở. Về kỹ thuật, giao diện của nó được dựa trên một plug-in trong Eclipse cung cấp trình soạn thảo chuyên dụng cho cú pháp văn bản trong MTL, một môi trường thực thi và một khung nhìn bên ngoài. Khung làm việc UMLAUT NG UMLAUT [13] là một khung làm việc chuyên dụng dùng để thao tác trên các mô hình MOF và UML. Nó có khả năng nhập và xuất các mô tả mô hình trong một vài định dạng phổ biến và chuẩn hóa như XMI. Chính vì vậy, UMLAUT có tính mở cao và có thể tích hợp như một bộ xử lí nền tảng trong các bộ mô hình phổ biến khác. Nó cũng làm việc như một ứng dụng độc lập được điều khiển bởi một plug-in GUI chuyên dụng trong Eclipse. Kiến trúc chung UMLAUT là một khung làm việc chung bao gồm một động cơ lõi giao tiếp với các thành phần ngoài của nó qua các điểm vào – interface . Trong đó các module chức năng có thể “cắm vào” để đặc tả các hành vi nắm bắt những yêu cầu cụ thể. Một vài plug-in đã thực sự tồn tại được cung cấp với công cụ như các bộ tạo mã (Java), giao tiếp qua định dạng trao đổi XMI hoặc sự chuyển đổi các mô hình chuyên dụng của các hệ thống phân tán. Hình 4.1: Kiến trúc UMLAUT Động cơ lõi Về cơ bản, động cơ lõi UMLAUT là một tập các lớp cộng tác cài đặt metamodel MOF. Meta-model này được định nghĩa với một tập các lược đồ lớp MTL chứa các lớp và những sự kết hợp giữa các lớp. Bộ tạo mã đơn giản này ánh xạ các lớp UML (hay MOF) trực tiếp vào một tập các lớp Java. Những sự kết hợp được ánh xạ vào các thuộc tính chứa một đối tượng hoặc một tập hợp đối tượng phụ thuộc vào số lượng các phía của sự kết hợp. Ví dụ, một thể hiện của một lớp UML_PACKAGE được tạo ra để trình bày một Package trong một mô hình, một sự kết hợp ownedElement từ Package tới ModelElement được triển khai vào trong một thuộc tính ownedElement trong lớp UML_PACKAGE của loại COLLECTION [UML_MODEL_ELEMENT], và một thuộc tính package của loại UML_PACKAGE trong lớp UML_MODEL_ELEMENT. Vì động cơ này có khả năng đọc mô tả của mô hình (và vì vậy nó có thể đọc toàn bộ metamodel MOF cũng như metamodel UML), sự lựa chọn một cài đặt meta-model cụ thể thực hiện được bằng cách lựa chọn trong bộ tạo. Khi một mô hình được nạp, nó tồn tại trong bộ nhớ như một Cây cú pháp trừu tượng. Việc xây dựng các plug-in dựa trên những tiện ích và công cụ có sẵn cung cấp các chức năng cụ thể thao tác các thành phần mô hình. Ví dụ, cây phân cấp của mẫu thiết kế visitor cài đặt các chiến lược duyệt mô hình khác nhau. Một bộ tạo mã là một đặc tả của một OO_CODE_GENERATOR trừu tượng, viết chồng các phương thức tiện ích như visitClass hoặc visitOperation. Một khung làm việc cho sự chuyển đổi tự động các mô hình UML Một mô hình MOF cũng như UML bao gồm một tập các đối tượng mô hình. Để làm dễ dàng sự chuyển đổi như một mô hình, UMLAUT đóng vai trò như một khung làm việc hướng đối tượng tự động hóa những nhiệm vụ liên quan đến những sự chuyển đổi mô hình. Nó sử dụng cách tiếp cận lai bao gồm cả mô hình lập trình chức năng và mô hình lập trình hướng đối tượng để phát triển một tập công cụ gồm những toán tử chuyển đổi tái sử dụng. Mô hình chức năng hướng mạnh tới sự hợp thành tổng quát của những toán tử trong khi mô hình hướng đối tượng cung một một kỹ thuật mở rộng trực quan qua sự thừa kế và sự kết tập. Nhìn chung, sự chuyển đổi bao gồm hai thao tác tách riêng. Thứ nhất, tập hợp các thành phần meta-model trong một mô hình MOF (hoặc UML) đưa ra cần được duyệt qua. Thứ hai, trong suốt quá trình duyệt, một tập các thành phần meta-model tương ứng với các quy luật đưa ra được chọn và áp dụng một toán tử chuyển đổi. Lặp qua các thành phần mô hình Mỗi mô hình MOF cũng như UML bao gồm một thể hiện của một tập hợp các meta-class từ meta-model. Tập hợp meta-class này hình thành lên một mạng phức tạp những sự kết hợp. Giữa những sự kết hợp này, chúng ta quan tâm riêng tới quan hệ hợp thành của các thành phần meta-model. Trong khung làm việc chuyển đổi, chúng ta áp dụng một vòng lặp duyệt qua cấu trúc mở rộng để tạo ra một chuỗi “đường thẳng” các thành phần meta-model. Hình 4.2: Duyệt theo độ sâu đầu tiên của Iterator Sự chuyển đổi sử dụng cách tiếp cận dễ áp dụng Khung làm việc cung cấp một kỹ thuật phân chia các khía cạnh của các thao tác chuyển đổi được kết hợp linh động khỏi những chi tiết giải thuật. Nó chỉ định 3 đặc điểm: quá trình lặp qua các thành phần mô hình MOF (hoặc UML), các thao tác và vấn đề hợp thành tổng quát và linh động của những thao tác này. Ngữ nghĩa của sự chuyển đổi Sự chuyển đổi một mô hình MOF (hoặc UML) cơ bản bao gồm: Thêm các thành phần mô hình mới tới một mô hình Xóa bỏ các thành phần mô hình khỏi một mô hình Chỉnh sửa các thuộc tính trên một thành phần mô hình Các thao tác 1 và 2 chỉnh sửa cấu trúc cây cú pháp trừu tượng của mô hình MOF (hoặc UML). Thao tác 3 dùng để cập nhật các thành phần mô hình. Mục đích Cải tiến tính tái sử dụng kỹ nghệ phần mềm của những sự chuyển đổi phạm vi rộng. Sự chuyển đổi mô hình là một sự đầu tư lâu dài, nhìn riêng trong phạm vi của các hoạt động kỹ nghệ phần mềm. Yêu cầu người dùng đầu tiên là phải có mô hình khả chuyển và lâu bền. Độc lập khỏi công cụ mô hình và những kho dữ liệu. Để đạt được sự khả chuyển, chúng ta cần phân chia các vai trò khác nhau. Chúng ta thu được một kiến trúc 3 tầng Công cụ mô hình / Cơ chế chuyển đổi / Kho dữ liệu. Cho phép xây dựng khung làm việc đa miền / đa khía cạnh / đa cách tiếp cận. Tất cả người dùng có những mối quan tâm riêng của họ. MTL cần có thể cộng tác và tổ chức những sự chuyển đổi không được xây dựng cho cùng một mục đích nhưng có những điểm tương tự nhau. Ý tưởng là tạo một khung làm việc phạm vi rộng (mở rộng) tổ chức những sự chuyển đổi này theo một vài cách. MTL cho phép thử nhiệm những chiến lược lập trình khác nhau. Vì Inria là một viện nghiên cứu, một trong những mối quan tâm của nó là cung cấp một ngôn ngữ / trình biên dịch cho phép thí nhiệm rộng rãi những loại lập trình sự chuyển đổi và vì vậy trình biên dịch cần có thể mở rộng. Bài toán chuyển đổi mô hình lược đồ lớp sang mô hình quan hệ Bài toán chuyển đổi mô hình lớp sang mô hình quan hệ được lấy từ hội thảo MoDELS 2005 [12]. Dưới đây là metamodel mô hình lớp và metamodel của mô hình RDBMS của bài toán: Hình 4.3: Mô hình metamodel lớp Một mô hình bao gồm các lớp và những sự kết hợp trực tiếp. Một lớp bao gồm một hoặc nhiều thuộc tính, ít nhất một trong số chúng phải được đánh dấu như khóa chính của lớp. Một loại thuộc tính hoặc là một lớp người dùng khác, hoặc là một loại dữ liệu cơ sở. Những sự kết hợp được xem xét có một số lượng trên đích của chúng. Ngoài ra có thể biểu diễn các loại dữ liệu chuẩn như các thể hiện của lớp PrimitiveDataType. Hình 4.4: Mô hình metamodel RDBMS Một mô hình RDBMS bao gồm một hoặc nhiều bảng. Một bảng bao gồm một hoặc nhiều cột. Một hoặc nhiều cột này sẽ bao gồm một khóa pkey, biểu thị rằng cột này hình thành nên khóa chính của bảng. Một bảng có thể chứa không hoặc nhiều khóa ngoài Mỗi khóa ngoài chỉ tới bảng riêng nó nhận diện, và biểu thị một hoặc nhiều cột trong bảng như một phần của khóa ngoài. Các luật chuyển đổi Các lớp được đánh dấu lâu bền trong mô hình nguồn cần được chuyển đổi vào trong một bảng đơn cùng tên trong mô hình đích. Bảng kết quả cần chứa một hoặc nhiều cột ứng với mỗi thuộc tính trong lớp và một hoặc nhiều cột cho mỗi sự kết hợp ứng với lớp được đánh dấu trong mô hình nguồn. Các thuộc tính cần được chuyển đổi theo luật 3 – 5. Các lớp được đánh dấu không lâu bền không được chuyển đổi ở mức đỉnh. Với mỗi thuộc tính mà loại của nó là một lớp không lâu bền, hoặc với mỗi sự kết hợp mà “dst” của nó là một lớp, mỗi thuộc tính của lớp này cần được chuyển đổi theo luật 3. Các cột cần đặt tên là “name_transformed attr” trong đó “name” là tên của thuộc tính hoặc sự kết hợp và “transformed attr” là một thuộc tính được chuyển đổi, hai kí hiệu này được phân chia bởi một kí tự gạch dưới. Các cột sẽ được đặt vào trong các bảng được tạo từ các lớp lâu bền. Các thuộc tính mà loại của nó là loại dữ liệu cơ sở cần được chuyển đổi tới một cột đơn mà loại của nó giống như loại dữ liệu cơ sở. Các thuộc tính mà loại của nó là một lớp lâu bền cần được chuyển đổi thành một hoặc nhiều cột, những cột này cần được tạo từ các thuộc tính khóa chính của các lớp lâu bền này. Các cột cần được đặt tên là “name_transformed attr” trong đó “name” là tên của thuộc tính. Các cột kết quả cần được đánh dấu như sự tạo thành một khóa ngoài, thành phần “Fkey” được tạo cần chỉ tới bảng được tạo từ lớp lâu bền. Các thuộc tính mà loại của nó là một lớp không lâu bền cần được chu