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

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 chuyển đổi thành một hoặc nhiều cột theo luật 2. Chú ý rằng các khóa chính và khóa ngoài của các lớp không lâu bền được chuyển đổi cần được kết nối phù hợp và được cân nhắc xem các lớp không lâu bền được chuyển đổi có thể chứa khóa chính và khóa ngoài từ một số bất kỳ của các lớp được chuyển đổi khác. Khi chuyển đổi một lớp, tất cả các thuộc tính của các lớp cha của nó (những thuộc tính này phải được tính toán đệ qui), và tất cả các sự kết hợp có các lớp như “src” cần được xem xét. Các thuộc tính trong các lớp con với cùng tên như một thuộc tính trong lớp cha được xem xét để viết chồng thuộc tính của lớp cha. Trong cây thừa kế, chỉ lớp cha mức đỉnh cần được chuyển vào trong một bảng, tuy nhiên bảng kết quả cần chứa các cột được kết nối từ tất cả các lớp con của nó. Giải quyết với MTL Bài toán thực nghiệm chuyển đổi từ mô hình lược đồ lớp tới mô hình cơ sở dữ liệu quan hệ được cài đặt trong MTL sử dụng một số kỹ thuật chính sau đây. Chi tiết về sự cài đặt sẽ được trình bày đầy đủ hơn trong chương 5. Visitor Kiến trúc tổng quan của sự cài đặt chuyển đổi mô hình trong ví dụ được tổ chức xung quanh 2 lần duyệt dùng mẫu visitor. Dựa trên mẫu visitor, chúng ta dễ dàng duyệt qua các thành phần của mô hình dựa trên loại của thành phần được thăm. Nhờ đó, một vài điểm của thành phần mô hình có thể được chỉnh sửa phù hợp. Hơn nữa, MTL có một vài khả năng đặc biệt với các visitor. Nó tự động thêm phương thức accept(visitor) cần thiết tới bất cứ thành phần mô hình hoặc lớp MTL. Duyệt nhiều lần Chúng ta phân chia sự chuyển đổi mô hình làm nhiều lần duyệt. Chính vì vậy, những nhiệm vụ chuyển đổi sẽ được phân bố hợp lí và tương đối đơn giản. Đồng thời, nó cũng giúp viết và gỡ lỗi sự chuyển đổi nhờ trực quan hóa các kết quả trung gian, xem xét mỗi lần duyệt như một sự chuyển đổi độc lập. Khung làm việc Chúng ta sử dụng một khung làm việc nhỏ để tái sử dụng những giải thuật chuyển đổi cho các lần duyệt cũng như cho các bài toán chuyển đổi khác. Lưu vết metamodel và sử dụng cấu trúc dữ liệu tạm thời bên trong. Trong sự chuyển đổi, để lần duyệt sau không bị ràng buộc bởi những trong lần duyệt trước chúng ta sử dụng một cấu trúc riêng biệt, một mô hình lưu vết nhỏ. Với tất cả các thành phần chính trong mô hình nguồn, mô hình lưu vết này lưu trữ thành phần đích được tạo trong suốt lần duyệt đầu tiên.Thêm vào việc sử dụng bên trong, những lưu vết này được trình bày như một mô hình, cũng có thể lưu lại để sử dụng cho những sự chuyển đổi sau hoặc một sự chuyển đổi ngược . Đánh giá, đề xuất cho ngôn ngữ chuyển đổi mô hình, ngôn ngữ MTL Sau đây là những đánh giá và đề xuất cho ngôn ngữ chuyển đổi mô hình nói chung, MTL nói riêng. MTL được cài đặt để hỗ trợ MOF 2.0 QVT. Ngôn ngữ MTL được xem như một ngôn ngữ metamodel cho sự chuyển đổi mô hình hay một mô hình PIM trong động cơ MT của nó. MTL có những đặc điểm chính sau: Sự cài đặt sử dụng thiết kế hướng đối tượng (dựa trên những khái niệm MOF) Hỗ trợ đa thừa kế Cho phép metamodelize một metamodel trực tiếp trong MTL Người dùng có thể sử dụng metamodel từ một kho dữ liệu dựa trên trình kết nối kho dữ liệu, ví dụ MDR từ Sun, ModFact từ Lip6, EMF từ IBM, hoặc từ MTL. Để đánh giá MTL, chúng ta chủ yếu sử dụng các yêu cầu về đặc trưng của công cụ chuyển đổi mô hình của OMG MOF 2.0 QVT. Các đặc trưng hỗ trợ Ngôn ngữ MTL đã đáp ứng được các yêu cầu sau: Hỗ trợ tài liệu hướng dẫn sử dụng. Trong tài liệu khái niệm metamodel trung tâm cũng như cú pháp của MTL và cách thức cài đặt trình biên dịch được giới thiệu. Cho phép người dùng tự xây dựng trình biên dịch của MTL. Người dùng là hoàn toàn tự do về chiều của sự chuyển đổi. Hỗ trợ cú pháp chặt chẽ đầy đủ, có thể được sử dụng như ngôn ngữ chuyển đổi trong các dự án khác. Hỗ trợ Truy vấn và Khung nhìn trong MTL. Hỗ trợ cú pháp trừu tượng trong MTL, được trình bày trong hướng dẫn sử dụng. Hỗ trợ tài liệu hướng dẫn sử dụng bằng tiếng Anh và dễ hiểu. Hỗ trợ ví dụ cài đặt của trình biên dịch của MTL Các đặc trưng chưa được hỗ trợ: Tuy nhiên, ngôn ngữ MTL vẫn chưa đáp ứng được các yêu cầu sau: Chưa hỗ trợ sự hợp thành và tái sử dụng. Ví dụ: không có mô hình trung gian, mô hình nguồn tạo ra mô hình đích như một hộp đen, PIM sẽ chuyển đổi trực tiếp vào mã nguồn. Chưa hỗ trợ những khung cảnh chuyển đổi phức tạp. Ví dụ: sự chuyển đổi M-N Chưa hỗ trợ tính mạnh mẽ trong việc thực thi sự chuyển đổi. Ví dụ: khi thực thi mà gặp lỗi sự chuyển đổi sẽ dừng lại. Chưa hỗ trợ sự hiệu chỉnh hướng điểm. Ví dụ: không có khả năng lưu vết giữa các mô hình, người phát triển phải tự mình thực hiện, không có sự chuyển đổi tổng quan để người dùng có thể mở rộng. Chưa hỗ trợ khả năng ánh xạ hai chiều Đề xuất Để bổ sung thêm khả năng chuyển đổi mô hình của MTL, chúng tôi đề xuất một số giải pháp sau: Tích hợp thêm các mẫu thiết kế (từ GOF [9]) dưới dạng các thư viện mở rộng cho các đối tượng MTL cũng như các thành phần mô hình sẽ làm tăng thêm tính tái sử dụng cũng như hiệu quả định nghĩa sự chuyển đổi. Phiên bản MTL hiện tại mới chỉ hỗ trợ hai kỹ thuật là Visitor và Observer. Dựa trên kỹ thuật mở rộng của ngôn ngữ MTL là khả năng “tagging” - các “tag” là các cặp “khóa/giá trị” được kết hợp với một thư viện MTL hoặc một lớp MTL hoặc một phương thức MTL - chúng ta có thể dẫn xuất các “tag” mới để chỉnh sửa sự chuyển đổi MTL theo một vài “hành vi liên kết” - một loại đặc biệt của chuyển đổi MTL. Với những mở rộng này, nhà phát triển sự chuyển đổi MTL có thể định nghĩa sự chuyển đổi phức tạp - chuyển đổi định nghĩa của sự chuyển đổi, hay còn gọi là sự chuyển đổi “reflective”, cũng như tái sử dụng toàn bộ định nghĩa sự chuyển đổi. Kết luận Trong chương này chúng tôi đã trình bày một số yêu cầu của ngôn ngữ chuyển đổi mô hình và đi sâu vào tìm hiểu ngôn ngữ MTL. Với sự thiết kế dựa trên những nguyên tắc kỹ nghệ mạnh mẽ và khung làm việc UMLAUT NG chuyên dụng, MTL hứa hẹn tiến tới các tiêu chí ngôn ngữ chuyển đổi chuẩn hóa theo đề xuất MOF 2.0 QVT. Bài toán chuyển đổi mô hình lớp sang mô hình quan hệ được chọn làm ví dụ tổng quát minh họa cho sức mạnh của MTL (chi tiết kỹ thuật của bài toán sẽ được trình bày kỹ hơn trong chương 5). Đồng thời, chúng tôi cũng đưa ra một số nhận xét đánh giá cũng như đề xuất cho ngôn ngữ. Tuy nhiên vì đây là một ngôn ngữ còn tương đối mới nên cần có thêm nhiều kiểm nghiệm cũng như bổ sung các khả năng chuyển đổi. Chương 3. LẬP TRÌNH VÀ THỰC NGHIỆM Trên cơ sở lý thuyết của các chương trước,. trong chương này chúng tôi tiến hành thực nghiệm áp dụng ngôn ngữ chuyển đổi vào bài toán chuyển đổi mô hình lớp. Bài toán “Quản lý thư viện sách trẻ em” được chọn để áp dụng những bài toán tổng quát nêu trên. Đồng thời, chúng tôi cũng tìm hiểu và vận dụng các công cụ, đọc hiểu mã nguồn khi tiến hành toán thực nghiệm, nâng cao những kỹ năng cần thiết của cử nhân Công nghệ thông tin. Mô tả bài toán áp dụng Thủ thư gọi sách là đầu sách (dausach). Mỗi đầu sách có một ISBN để phân biệt với các đầu sách khác. Các đầu sách có thể được dịch ra nhiều thứ tiếng (ngonngu) khác nhau và được đóng thành bìa (bia) khác nhau.. Một đầu sách có thể có nhiều bản sao (bansach) ứng với đầu sách đó. (Mã số cuốn sách được đánh số tự động, bắt đầu từ 1, 2, 3, ,…) Mỗi đầu sách có một trạng thái (trangthai) cho biết cuốn sách đó có thể cho mượn được hay không. Để trở thành bạn đọc (bandoc) của thư viện, thì mỗi bạn đọc phải đăng ký và cung cấp các thông tin cá nhân cũng như địa chỉ và điện thoại của mình. Thủ thư sẽ cấp cho bạn đọc một thẻ điện tử, trên đó có mã số thẻ chính là mã số bạn đọc để phân biệt các bạn đọc khác. (Mã số được đánh số tự động, bắt đầu từ 1, 2, 3, ,…). Thẻ này có giá trị trong 1 năm kể từ ngày đăng ký. Một tháng trước ngày hết hạn thẻ, thủ thư sẽ thông báo cho bạn đọc biết để đến gia hạn thêm. Trẻ em (trecon) để trở thành độc giả của thư viện cần có 1 người bảo trợ có trách nhiệm bảo lãnh và đăng kí. Mô hình biểu đồ lớp của bài toán Hình 5.1: Mô hình biểu đồ lớp Thực nghiệm chuyển đổi với MTL Cài đặt công cụ MTL Phiên bản MTL được phát triển bởi đội Triskell ở viện nghiên cứu Inria. Động cơ MT được phân phối như một phần mềm mã nguồn mở theo đăng ký LGPL. Phiên bản của MTL sử dụng trong chương này là V0.0.6. Yêu cầu cài đặt Bạn cần cài đặt một số công cụ trước khi cài đặt MTL Cài đặt phiên bản JDK từ 1.4 trở đi. Cài đặt Eclipse 3.0 Cài đặt Unimoto để tạo các mô hình theo metamodel tùy chọn. Sau đó cài đặt MTL sử dụng công cụ cập nhật của Eclipse Hình 5.2: Tính năng Tìm và Cài đặt trong Eclipse Hình 5.3: Tìm đặc trưng mới Hình 5.4: Thêm trang web cập nhật Umlaut NG Hình 5.5: Cài đặt hoặc cập nhật plugin Umlaut Cài đặt luật chuyển mô hình lớp sang quan hệ bằng MTL Bài toán chuyển đổi mô hình lược đồ lớp sang mô hình quan hệ được trình bày tổng quan trong chương 3. Sau đây là chi tiết các kỹ thuật chính cài đặt bài toán với MTL Visitor Kiến trúc tổng quan của sự cài đặt chuyển đổi mô hình trong ví dụ được tổ chức xung quanh 2 lần duyệt dùng mẫu visitor. Sở dĩ chúng ta dùng mẫu visitor vì nó cung cấp một cách dễ dàng để duyệt các thành phần của mô hình. Một vài điểm của thành phần mô hình có thể được chỉnh sửa khi sử dụng các visitor. Về cơ bản, visitor cho phép gọi các thao tác cụ thể dựa trên loại của các thành phần mô hình được thăm. Ví dụ tùy thuộc vào loại là “Class” hay “Attribute” hay “Association” các phương thức “VisitClass”, “VisitAttribute” và “VisitAssociation” tương ứng sẽ được gọi. Ngoài ra, những thay đổi khác với các thành phần mô hình cũng có thể thực hiện bằng cách định nghĩa thứ tự duyệt. Vì MTL cũng là một ngôn ngữ hướng đối tượng nên dựa vào khái niệm thừa kế việc sử dụng mẫu visitor để duyệt qua các thành phần mô hình là rất thích hợp. Hơn nữa, MTL có một vài khả năng đặc biệt với các visitor. Nó tự động thêm phương thức accept(visitor) cần thiết tới bất cứ thành phần mô hình hoặc lớp MTL .Sau đây là nội dung phương thức visitClass trong ClassVisitor được viết bằng MTL. class ClassVisitor visitClass (instance : Standard::OclAny; context : Standard::OclAny): Standard::OclAny { theClass : source_model::Class; result : VisitorResult; // we create the result result := resultFactory.create (); // we retrieve the called object theClass := instance.oclAsType (!source_model::Class!); // we continue the visit with the Attribute objects foreach(anAttribute : source_model::Attribute) in (theClass.attrs) { result.add(anAttribute.accept(this,context). oclAsType(!Standard::OclAny!)); } // this would have been better if the association has been // navigable from the class. // as the metamodel is not navigable this way, we have to retrieve // it using a foreach on the type. foreach (anAssociation : source_model::Association) in (!source_model::Association!.allInstances()) { if( anAssociation.src.[=](theClass)) { // visit only association for which this class is source // (ensures that we visit only once) result.add (anAssociation.accept (this, context).oclAsType(!Standard::OclAny!)); } } return result; } Duyệt nhiều lần Một trong những khó khăn mà người viết sự chuyển đổi mô hình có thể gặp phải là về thời điểm phù hợp để áp dụng một vài phần của sự chuyển đổi. Trong thực tế, khi viết sự chuyển đổi, người viết sự chuyển đổi phải bảo đảm một thành phần được tạo ra trước khi áp dụng luật chuyển đổi với nó. Với ví dụ nghiên cứu này, chúng ta chia các luật chuyển đổi vào 2 tập hợp, mỗi tập hợp được khởi động từ 1 visitor. Sau đó, sự chuyển đổi được áp dụng trong 2 lân duyệt. Lần duyệt đầu tiên tạo tất cả các thành phần chính trong mô hình đích. Ví dụ, các bảng tương ứng với các lớp ở mức đỉnh được đánh dấu “is_persistent = true” và các cột của bảng tương ứng với các thuộc tính của lớp này. Nó cũng có thể liên kết một vài thành phần khác, nhưng chúng ta phải đảm bảo rằng các thành phần được visitor liên kết phải tồn tại. Khi chúng ta đã chắc chắn rằng tất cả các thành phần mô hình tồn tại, lần duyệt tiếp theo sẽ áp dụng các luật còn lại. Để làm trong sáng mã chuyển đổi, người viết sự chuyển đổi có thể chọn sử dụng nhiều hơn 2 lần duyệt và sau đó nhóm các luật thực thi tương ứng với những lần duyệt. Phân chia sự chuyển đổi vào trong một vài lần duyệt cũng giúp viết và gỡ lỗi sự chuyển đổi vì nó trực quan hóa các kết quả trung gian, xem xét mỗi lần duyệt như một sự chuyển đổi độc lập. Trong bài toán này, lần duyệt đầu tiên tạo tất cả các bảng và các cột của bảng tương ứng với các lớp mức đỉnh được đánh dấu “is_persistent = true” và các thuộc tính của lớp. Lần duyệt thứ 2 tạo các cột và các khóa ngoài tương ứng với các lớp “is_persistent = false” và quan hệ giữa lớp nguồn và lớp đích của “Association”. Như một minh họa, mã MTL của lần duyệt đầu tiên được đưa ra dưới đây: visitClass (instance : Standard::OclAny; context : Standard::OclAny): Standard::OclAny { theClass : source_model::Class; result : VisitorResult; str : Standard::String; theTable : target_model::Table; // we create a new visitor result result := this.resultFactory.create (); // we retrieve the called object theClass := instance.oclAsType (!source_model::Class!); // if persistent create a table if classHelper.isClassPersistent(theClass) { // if this is the topmost parent then create the class // otherwise , simply retrieve the table if isNull(theClass.parent) { // create the table theTable := class2RDBMSHelper.getTableForClass(theClass); }else { theTable := class2RDBMSHelper.getTableForClass( classHelper.getTopParent(theClass)); trace.add(theClass, theTable); } // we call the parent visit method, // the current class is passed in the context this.oclAsType(!ClassVisitor!).visitClass(instance, instance); } /* else: non persistent classes, connected attributes and associations cannot be processed in pass 1 */ return result; } Phân chia sự chuyển đổi cũng cho phép sử dụng nguồn dữ liệu đầy đủ và hiệu quả nhất để cài đặt các luật. Logic chính của sự chuyển đổi có thể dựa vào mô hình nguồn, mô hình đích hoặc cả hai. Bản thân MTL không giả định rằng sự chuyển đổi sử dụng mô hình nào trong 2 mô hình. Thực tế, trong cài đặt của ví dụ này, chúng ta sử dụng các thành phần mô hình cả từ mô hình nguồn và mô hình đích. Điều này bởi vì giải thuật càng trong sáng mạch lạc sự duy trì càng cao. Trong lần duyệt đầu tiên, chúng ta sử dụng mô hình nguồn bởi vì chúng ta đang tạo các thành phần mô hình đích. Thậm chí nếu chúng ta có một mô hình đích tồn tại để đồng bộ hóa , chúng ta vẫn không nên dựa vào nó trong suốt giai đoạn này. Trong lần duyệt sau, sự phối hợp khá khác biệt, chúng ta thực sự có một mô hình trung gian tin cậy trong mô hình đích. Rất có khả năng thông tin trong mô hình đích biểu diễn nhiều hơn thông tin trong mô hình nguồn, chính vì vậy người viết sự chuyển đổi cần có thể thao tác mô hình trung gian này. Ở bài toán ví dụ, chúng ta sử dụng những thông tin trong mô hình này khi tạo các khóa phụ. Nhờ lần duyệt đầu, chúng ta đã có các tên cột khóa chính cần thiết để trỏ tới khóa ngoài. Đồng thời, chúng ta cũng cần lưu vết giữa các lớp nguồn và đích theo cấu trúc trung gian. Điều này được mô tả chi tiết hơn trong 2 phần bên dưới. Khung làm việc Để giúp viết các luật của sự chuyển đổi trong các lần duyệt visitor, chúng ta sẽ sử dụng một khung làm việc nhỏ. Thông thường, nó chứa mã tái sử dụng giống như các truy vấn, mã sinh mô hình hoặc các giải thuật phức tạp. Trong phạm vi bài toán, chúng ta có thể phân biệt 2 loại khung làm việc chính: các khung làm việc hướng metamodel và các khung làm việc hướng sự chuyển đổi. Các khung làm việc hướng metamodel là chuyên dụng tới chỉ một metamodel, giống như trong bài toán này là metamodel lớp hoặc metamodel RDBMS. Mỗi khi chúng ta sử dụng một metamodel mới, chúng ta có thể phải phát triển một khung làm việc tương ứng. Thậm chí cho những metamodel đơn giản, chúng ta có thể cần lặp lại một vài yêu cầu phức tạp. Ví dụ trong metamodel lớp, yêu cầu xác định sự lâu bền của một lớp là rất quan trọng. Câu hỏi này ngầm định một sự đệ quy - sự lâu bền ngầm định định hướng liên kết cha lên tới cha cao nhất có thể trả lời câu hỏi. Các khung làm việc hướng sự chuyển đổi mô hình liên quan tới một sự chuyển đổi riêng. Thỉnh thoảng, chúng có thể được xem xét như một phần của bản thân sự chuyển đổi. Khi nhiều sự chuyển đổi được phát triển, phương pháp ban đầu được thiết kế cho một sự chuyển đổi có thể hữu ích trong một sự chuyển đổi khác. Ví dụ, một người có thể nghĩ có 2 biến thể của sự chuyển đổi mô hình biểu đồ lớp sang mô hình quan hệ: một cái lấy chỉ một lớp mô hình như nguồn, một cái lấy một lớp mô hình và một mô hình cấu hình khác. Cả 2 sự chuyển đổi đều liên quan, và chúng chia sẻ mã qua sự sắp xếp của khung làm việc. Những khung làm việc này rất hữu ích để tái sử dụng những giải thuật phức tạp và lặp lại. Trong bài toán này, một vài truy vấn đệ quy ngầm định thích hợp với 1 trong 2 khung làm việc Sau đây là 2 phương thức tạo các thuộc tính, được trích từ khung làm việc: Class2RDBMS // add the created columns to the table // use the given prefix for column name createColumnsForNonPersistentClass( theClass: source_model::Class; theTable : target_model::Table; namePrefix : Standard::String) { newPrefix : Standard::String; foreach ( anAttribute : source_model::Attribute) in (theClass.attrs) { newPrefix := namePrefix; createColumnFromAttribute(anAttribute, theTable, newPrefix); } foreach ( anAssoc : source_model::Association) in (classHelper.getDestAssoc(theClass)) { if not classHelper.isClassPersistent( anAssoc.dest.oclAsType(!source_model::Class!)) { newPrefix:= namePrefix.concat( anAssoc.name.oclAsType(!Standard::String!)); createColumnsForNonPersistentClass( anAssoc.dest.oclAsType(!source_model::Class!), theTable, newPrefix); } } } createColumnFromAttribute( theAttribute: source_model::Attribute; theTable : target_model::Table; namePrefix : Standard::String) : target_model::Column { theColumn : target_model::Column; name : Standard::String; name := namePrefix.concat( theAttribute.name.oclAsType(!Standard::String!)); if (theAttribute.type.oclIsKindOf(!source_model::PrimitiveDataType!)) { theColumn := new target_model::Column(); theColumn.name := name; theColumn.type := theAttribute.type.name; associate ( cols := theColumn : target_model::Column, owner := theTable : target_model::Table ); if theAttribute.is_primary { // we also need to associate it as a pkey associate ( pkey := theColumn : target_model::Column, pkeyreferers:= theTable : target_model::Table ); } } return theColumn; } Lưu vết metamodel và sử dụng cấu trúc dữ liệu tạm thời bên trong Để không bị ràng buộc với những sự chuyển đổi trong lần duyệt 2 chúng ta cần sử dụng một cấu trúc riêng biệt, một mô hình lưu vết nhỏ. Với tất cả các thành phần chính trong mô hình nguồn, mô hình lưu vết này lưu trữ thành phần đích được tạo trong suốt lần duyệt đầu tiên. Ví dụ, lớp Hashtable chứa các cặp lưu vết “Table, Class” tương ứng “Table” được tạo từ “Class” nào. Sau đó trong suốt những lần duyệt sau, chúng ta dựa trên lớp Hashtable lưu vết này truy vấn các thành phần “Class” hoặc “Table” phụ thuộc vào yêu cầu. Vì các lưu vết cho phép truy vấn nội dung của lần duyệt trước, viết các luật của lần duyệt sau dễ dàng hơn. Thêm vào việc sử dụng bên trong, những lưu vết này, trình bày như một mô hình, cũng có thể lưu lại để sử dụng cho những sự chuyển đổi sau hoặc một sự chuyển đổi ngược. Cấu trúc dữ liệu trung gian có thể rất phức tạp.Ví dụ, trong lần duyệt 2 của bài toán này, chúng ta muốn tạo khóa ngoài và các cột trong các lớp nguồn trỏ tới một lớp đích lâu bền. Để thực hiện điều này chúng ta cần truy vấn tất cả các lớp lâu bền được kết hợp với lớp đưa ra. Một phương thức đệ quy sẽ dễ dàng tạo ra những lớp này như một danh sách. Tuy nhiên, rất có khả năng có một vài lớp không lâu bền giữa những lớp nguồn và lớp đích lâu bền trong đồ thị kết hợp. Nếu chúng ta theo sau cách tiếp cận đơn giản này, chúng ta sẽ thiếu một vài thông tin để tạo các cột khóa ngoài. Chúng ta cần tên của chúng và những tên này phụ thuộc vào sự kết hợp giữa các lớp nguồn lâu bền và các lớp đích lâu bền của chúng. Tập đơn giản gồm các Class là không đủ, chúng ta cần thêm một vài thông tin nữa. Một cấu trúc mới bên trong sẽ thực hiện điều này, nó định nghĩa một lớp MTL mới lưu trữ một lớp lâu bền và đường dẫn dẫn tới lớp này. Sau đó từ danh sách này, chúng ta có đủ thông tin để tạo khóa ngoài và các cột trong các lớp nguồn. Áp dụng luật chuyển đổi cho bài toán cụ thể Chúng tôi chọn bài toán Quản lí thư viện sách trẻ em đơn giản để minh họa áp dụng bài toán tổng quát chuyển đổi mô hình lớp sang mô hình quan hệ. Quá trình chuyển đổi bài toán Mô hình được đánh dấu làm đầu vào của bài toán Hình 5.6: Mô hình được đánh dấu làm đầu vào của bài toán Mô hình này được biểu diễn trong Unimoto như sau Hình 5.7: Mô hình lược đồ lớp của bài toán trong Unimoto Mô hình đầu vào được biểu diễn dưới dạng xmi Sau đó, dựa vào Unimoto chúng ta sinh mô hình xmi làm đầu vào cho bài toán chuyển đổi tổng quát mô hình lớp sang mô hình quan hệ dịch bằng công cụ MTL. Sau đây là một đoạn trích tệp tin mô hình lược đồ lớp đầu vào biểu diễn theo định dạng xmi Netbeans XMI Writer 1.0 … Mô hình đầu ra được biểu diễn dưới dạng xmi Đoạn trích sau đây là mô hình lược đồ quan hệ đầu ra theo định dạng xmi. Netbeans XMI Writer 1.0 Mô hình lược đồ quan hệ biểu diễn trong Unimoto như sau Hình 5.8: Mô hình lược đồ quan hệ của bài toán trong Unimoto Kết luận Trên đây, chúng tôi đã tìm hiểu vận dụng các kỹ thuật áp dụng ngôn ngữ chuyển đổi và áp dụng mẫu thiết kế đưa ra trong các chương trước. Bài toán chuyển đổi mô hình lớp sang mô hình quan hệ được chọn minh họa cho ngôn ngữ chuyển đổi mô hình MTL. Chúng tôi chọn bài toán Quản lí thư viện sách trẻ nhỏ đơn giản để minh họa cho toàn bộ quá trình áp dụng bài toán tổng quát trên .Trong quá trình thực nghiệm, chúng tôi đã thu được những kết quả khá khả quan đồng thời cũng nâng cao được các kỹ năng đọc hiểu mã nguồn, sử dụng công cụ, nắm bắt công nghệ. Đây là những kỹ năng cần thiết của cử nhân Công nghệ thông tin. KẾT LUẬN Phát triển phần mềm hướng mô hình - MDD đã khắc phục được nhiều hạn chế mà các quá trình phát triển phần mềm trước đó chưa giải quyết được. Những kết quả đạt được của kiến trúc phần mềm hướng mô hình – MDA do tổ chức OMG đề xướng đã kiểm nghiệm khả năng hiện thực hóa của MDD. Nội dung khóa luận trình bày tổng quan về kỹ nghệ phần mềm hướng mô hình và tập trung vào kiến trúc phần mềm hướng mô hình MDA. Đồng thời, chúng tôi cũng làm rõ một số kỹ thuật quan trọng cho vấn đề chuyển đổi mô hình như áp dụng ngôn ngữ chuyển đổi hay mẫu thiết kế. Trong khóa luận, chúng tôi tìm hiểu một số vấn đề trong phương pháp phát triển phần mềm tương đối mới ở nước ta như giải pháp MDD, khung làm việc MDA, vấn đề chuyển đổi mô hình. Với các chuẩn UML và MOF, vấn đề biểu diễn mô hình đã được giải quyết. Tuy nhiên với sự chuyển đổi mô hình còn một số vấn đề quan trọng như sự nhất quán và sự đồng bộ giữa các mô hình. Chính vì vậy, chúng tôi nhấn mạnh vào kỹ thuật chính là áp dụng ngôn ngữ chuyển đổi mô hình. Với ngôn ngữ chuyển đổi mô hình, chúng tôi đi sâu vào tìm hiểu ngôn ngữ chuyển đổi MTL cũng như đưa ra một số đánh giá và đề xuất cho ngôn ngữ. Qua đó, chúng tôi đã nắm bắt được những công nghệ liên quan như công nghệ hướng đối tượng với ngôn ngữ UML cùng các chuẩn như MOF, XMI, metamodel,…; mẫu thiết kế hay các phương pháp phát triển phần mềm mới tập trung nhiều hơn vào mô hình. Trong quá trình thực nghiệm, chúng tôi đã tiến hành áp dụng ngôn ngữ chuyển đổi và mẫu thiết kế trong quá trình chuyển đổi mô hình cho bài toán “Quản lý thư viện sách trẻ em”. Đồng thời, chúng tôi cũng tìm hiểu và vận dụng các công cụ, đọc hiểu mã nguồn để áp dụng cho bài toán thực nghiệm. Đây là những kỹ năng quan trọng của kỹ sư Công nghệ thông tin. Tuy nhiên do thời gian và khả năng có hạn, đồng thời đây cũng là một vấn đề còn khá mới mẻ nên trong quá trình thực hiện khóa luận còn nhiều sai sót cũng như một số khía cạnh cần mở rộng mà chưa có điều kiện. Chúng tôi đưa ra một số hướng nghiên cứu để phát triển đề tài: Đối với ngôn ngữ chuyển đổi mô hình MTL có thể tích hợp thêm các mẫu thiết kế (từ GOF) dưới dạng các thư viện dẫn xuất và mở rộng dựa trên kỹ thuật “tagging”. Xây dựng một khung làm việc tích hợp ngôn ngữ chuyển đổi mô hình và mẫu thiết kế cho sự chuyển đổi mô hình. TÀI LIỆU THAM KHẢO [1]Anneke Kleppe, Jos Warmer, Wim Bast MDA Explained: The Model Driven Architecture: Practice and Promise Reference Manual. 2nd Edition. [2] Jordan Liu, Frank Qin, Xiaoping Jia. A Survey on Model Transformation  Approaches and Introduction of a Model Transformation Framework based on  Hierarchical Meta Model [3] Object Management Group, Inc: Model Driven Architecture  [4] Object Management Group, Model Driven Architecture MDA Guide V1.0.1 omg/03-06-01 [5] Object Management Group, Inc: MOF 2.0 Query/Views/Transformations RFP 2002 [6] R. S. Pressman. Software Engineering, A Practitioner's Approach. [7] Sami Beydeda. Matthias Book, Volker Gruhn (Eds.) Model-Driven Software Development 2005 [8] Shane Sendall and Wojtek Kozaczynski Model Transformation – the Heart and Soul of Model-Driven Software Development [9] T. Reenskaug, P. Wold, and O. A. Lehne. Working with Objects: The OORAM Software Engineering Method [10] Xabier Larrucea, Ana Belen García Díez, Jason Xabier Mansell Practical Model Driven Development Process [11] W3C, XSL Transformations (XSLT) Version 1.0, November 1999, [12] Model Transformation in Practice Workshop, part of the MoDELS 2005 Conference October 3rd 2005 [13] Model Transformation Language (MTL) [14] OptimalJ 3.0 User’s Guide,