Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web

ội bộ hoặc trên Web site. Mỗi nhà phát triển cài đặt các chuyển đổi mong muốn và các plugin đi kèm (plugin phụ thuộc). Khi chúng đã được cài đặt, nhà phát triển sẽ có một menu các mục chọn mới và tập các preference mặc định mà khi được triệu gọi nó sẽ nhắc nhà phát triển các thông số được yêu cầu trước khi triệu gọi chuyển đổi đó. Tất cả luận lý chuyển đổi trong ánh xạ được lập code ở trong chuyển đổi được tải xuống (từ trên mạng nội bộ hay mạng intranet) và được thực thi với các chuyển đổi này. Chỉ riêng điều này thôi thì không đủ để đảm bảo rằng bất kỳ chuyển đổi nào cũng được sử dụng một cách chính xác. Do đó, hầu hết các chuyển đổi được xây dựng tốt sẽ bao gồm các phần mới để được thêm vào phần help online của Eclipse. Những phần này sẽ chỉ ra khi nào, tại sao và làm như thế nào một chuyển đổi được triệu gọi. Dĩ nhiên, trong mỗi môi trường, quy trình này sẽ được cập nhật và được giao tiếp sao cho phù hợp. Toolkit MDA cho IBM Rational XDE Java đã xuất hiện từ cuối năm 2003, và được sử dụng trong nhiều trường hợp khách hàng khác nhau và đã được đúc kết thành các bài học kinh nghiệm như sau. 2.4.5. Các bài học trong việc thiết kế và ứng dụng các giải pháp MDA Khi tạo các giải pháp MDA các bước sau cần được theo một cách nhất quán • Kiểm tra các mô hình đang được sử dụng trong quy trình phát triển, và các kết nối ngữ nghĩa giữa các thành phần thuộc các mô hình có mức trừu tượng khác nhau. • Xác định các chuyển đổi cần thiết cho sự tự động hóa. • Lập tài liệu các yêu cầu (requirement) chuyển đổi. • Tạo ra các profile UML cần thiết. • Phát triển code chuyển đổi. • Lập tài liệu cách sử dụng, sau đó đóng gói và triển khai. Những bước này thiết lập nên cơ sở của các project MDA khác nhau, và cùng với thiết kế lặp điển hình và sự phát triển giảm rủi ro, chúng đã đề ra một hướng dẫn đắc lực đến cách tiếp cận MDA. 2.4.5.1. Về vấn đề các kết nối mô hình ngữ nghĩa Hướng dẫn 1: Phát triển các chuyển đổi chỉ khi các kết nối ngữ nghĩa giữa các thành phần mô hình được hiểu rõ. Trước bất kỳ nỗ lực nào để đưa sự tự động vào trong quy trình phát triển, ta phải có một cái nhìn thông suốt và đầy đủ về tất cả các mô hình được sử dụng và được quản lý trong quy trình. Đã thường xuyên xảy ra việc các nỗ lực phát triển bắt đầu với sự tạo ra các mô hình không cần thiết, chỉ vì quy trình phát triển chưa phù hợp, đúng đắn cho rằng Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 82 các mô hình này là cần thiết. Các mô hình chỉ nên được tạo ra khi chúng cung cấp các thông tin rõ ràng và có ích cho nỗ lực phát triển. Mặt khác, nhiều project thường bị mất một số mô hình quan trọng và các khái niệm trừu tượng kết nối nhiều phần khác nhau của hệ thống. Do đó bất kỳ khi nào một số lượng đáng kể sự thông dịch và hoạt động của con người được sử dụng trong một phần cụ thể của project, ta có thể cần một mô hình hình thức nhằm nắm bắt các quá trình suy nghĩ và các quyết định thiết kế được làm trong suốt các hoạt động này. Kết nối ngữ nghĩa giữa các thành phần trong các mô hình thuộc các mức trừu tượng khác nhau có tầm quan trọng đặc biệt trong ngữ cảnh MDA. Hầu hết các hoạt động hiện nay xung quanh vấn đề MDA liên quan đến sự tự động của các chuyển đổi mô hình, đặc biệt là chuyển đổi giữa các mô hình ở mức trừu tượng cao hơn với các mô hình ở mức trừu tượng thấp hơn. Điển hình là các kết nối kiểu “fan out”; nghĩa là một thành phần mô hình đơn ở mức trừu tượng cao (ví dụ: use case) được kết nối đến nhiều thành phần mô hình (ví dụ: các boundary, entity, controller) trong các mô hình cấp thấp hơn Khả năng theo vết của các kết nối này quan trọng vì một số lý do, trong đó, lý do quan trọng nhất là khả năng hỗ trợ các chuyển đổi tự động. Nhưng nó cũng có tầm quan trọng trong môi trường phát triển lặp, nơi mà các chuyển đổi thường được triệu gọi nhiều lần. Thông thường một chuyển đổi hiếm khi chuyển đổi một mô hình nguồn thành một mô hình đích. Thường là có một mô hình nguồn chính cùng với một số thông số đa mục đích sẽ tạo ra một tập các mô hình đích. Ví dụ, trong một hệ thống J2EE, một mô hình phân tích chứa các thông tin sẽ được chuyển đổi thành một thiết kế cơ sở dữ liệu, một Java interface, một số Java ServerPages (JSPs), và một số bản mô tả việc cấu hình hoặc triển khai. Tất cả các mô hình này sẽ chi tiết hơn mô hình phân tích ban đầu và phải được đồng bộ hóa để thực thi chính xác. Do đó, việc phát triển một chuyển đổi quản lý việc truyền thông tin từ mô hình nguồn cấp cao thành một nhóm các mô hình cấp thấp, sẽ lợi hơn việc phát triển các chuyển đổi riêng biệt cho từng cặp mô hình input và output. Chính khả năng này cùng với nội dung ngữ nghĩa giữa các mô hình cấp thấp khác nhau làm cho MDA trở thành một công nghệ thu hút mọi người. Hơn thế nữa, một tính chất quan trọng của một chuyển đổi là khi được thực thi, chỉ có những thành phần của mô hình đích có phụ thuộc trực tiếp vào mô hình nguồn thì mới được cập nhật. Bất kỳ thông tin nào trong mô hình đích mà không phải được tạo ra bởi sự chuyển đổi lần đầu tiên thì nên được giữ nguyên. Ngoài ra, các thành phần mô hình được tạo bởi sự chuyển đổi không nên bị nhân bản trong mô hình đích trong mỗi lần gọi, tốt hơn là chúng chỉ nên được cập nhật (hoặc được tạo nếu chưa có trong mô hình). Hàm API của MDA Toolkit được xây dựng để các chuyển đổi tuân theo các quy luật thiết kế này. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 83 2.4.5.2. Về vấn đề xác định các chuyển đổi cần thiết Hướng dẫn 2: Không phải tất cả các kết nối ngữ nghĩa đều tạo nên các chuyển đổi MDA tốt. Khi các kết nối ngữ nghĩa được xác định giữa các phần tử trong mô hình, chúng nên được kiểm tra xem các luật quản lý các mối quan hệ của chúng có phù hợp cho sự tự động hay không. Một chuyển đổi thích hợp chỉ có thể thực thi khi các luật này rõ ràng và không bị nhập nhằng. Các luật có thể lớn và phức tạp hoặc cũng có thể nhỏ và đơn giản, trong cả hai trường hợp đều có thể cần tạo nên một chuyển đổi để hiện thực chúng. Tuy nhiên, nếu các luật định nghĩa các kết nối này sau đó sẽ xây dựng các phần tử mới trong các mô hình khác, mà các phần tử mới này lại yêu cầu kinh nghiệm hay sự phán đoán của người phát triển, thì sự tự động dễ dàng bị loại bỏ sau đó. Một lý do khác để loại bỏ sự tự động là khả năng các mô hình không thể truy xuất các phần tử cần thiết thông qua việc lập trình. Ví dụ, nếu hầu hết các bước chuyển đổi đều liên quan đến việc đọc các tài liệu ngôn ngữ tự nhiên, bất chấp mức độ hình thức của nó, thì cũng không thể phù hợp với sự tự động của MDA. Để minh hoạ cho điều này, ta có thể thấy việc chuyển đổi một tài liệu đặc tả use case thành một mô hình phân tích thường không thể thực hiện. Tuy nhiên, chuyển đổi một lược đồ tuần tự UML, hay lược đồ hoạt động cùng với một use case, có thể phù hợp cho sự tự động. 2.4.5.3. Về vấn đề lập tài liệu các yêu cầu chuyển đổi Hướng dẫn 3: Việc viết các chuyển đổi MDA nên được xem là một dự án phát triển phần mềm Chuyển đổi hiệu quả nhất là các chuyển đổi thực hiện tự động các công việc quá nhàm chán hoặc quá phức tạp một cách nhất quán và đáng tin cậy. Sự động hóa MDA đảm bảo tính nhất quán và trong hầu hết các trường hợp tiết kiệm được đáng kể thời gian cũng như công sức lập trình cho các lập trình viên. Không có gì ngạc nhiên rằng hầu hết các chuyển đổi thành công là các ví dụ phần mềm quan trọng. Khi sử dụng sự động hóa MDA và sự tạo ra các chuyển đổi quan trọng, ta nên coi chúng như là một sự phát triển phần mềm riêng biệt Một chuyển đổi, đặc biệt khi được tạo ra với MDA Toolkit, là một ví dụ của phần mềm tạo ra theo nhu cầu. Các requirement nên được hiểu rõ ràng và nên được kiểm tra cả về mặt ngữ nghĩa và kỹ thuật. Tập hợp các đặc tả requirement được chứa trong tài liệu ánh xạ. Tài liệu ánh xạ mô tả chi tiết các kết nối ngữ nghĩa giữa các thành phần lập mô hình trong nhiều mô hình khác nhau tham gia trong chuyển đổi. Các requirement khác có thể bao gồm vấn đề hiệu suất, vấn đề bảo mật, vấn đề khả mở rộng… Hầu hết các chuyển đổi mà chúng ta quan tâm đến đều phải trải qua các giai đoạn phân tích và thiết kế và kết quả cuối là một tập các class hiện thực chuyển đổi đó. Các vấn đề khác, như test, triển khai và hướng dẫn cách sử dụng cũng nên có đầy đủ như trong quy trình phát triển phần mềm truyền thống. Tuy các chuyển đổi MDA không đòi hỏi Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 84 phải có một nhóm phát triển lớn hiện thực nó, nhưng việc phát triển chúng như một phần độc lập (tức là phải trải qua đầy đủ các giai đoạn) sẽ đảm bảo chất lượng của chuyển đổi. Khi xác định các requirement cho một chuyển đổi hiện thực bằng MDA Toolkit, ta phải xét ba hành vi khác nhau: • Kiểm tra tính hợp lệ của các thông số nhập. • Thực thi các logic hoặc các ánh xạ chuyển đổi cốt lõi. • Kiểm tra các kết hợp ngữ nghĩa giữa các thành phần mô hình tham gia trong chuyển đổi. Sự thực thi logic chuyển đổi và sự bổ sung vào các mô hình đích là công việc quan trọng nhất trong toàn bộ chuyển đổi. Tuy nhiên, kiểm tra tính hợp lệ của dữ liệu nhập và kiểm tra việc chuyển đổi đã hoàn chỉnh chưa cũng rất quan trọng trong môi trường phát triển lặp (việc chuyển đổi có thể được áp dụng nhiều lần trên cùng một mô hình nguồn). Hướng dẫn 4: Kiểm tra tính toàn vẹn của tất cả các thông số và các artifact tham gia trong một chuyển đổi trước khi thực thi chuyển đổi đó Hầu hết các thứ đều có thể được triệu gọi và xử lý trong một chuyển đổi được tạo ra bởi MDA Toolkit và MDA Toolkit không cung cấp cơ chế giám sát quy trình giao dịch. Trong một số trường hợp, một chuyển đổi bắt đầu nhưng phải dừng trước khi được hoàn tất, không có cơ chế đảm bảo rằng việc dừng chuyển đổi này sẽ xác lập lại (reset) tất cả các thông số đầu vào trở về trạng thái trước khi chuyển đổi. Điều này là bởi vì MDA Toolkit không giới hạn hay hạn chế các kiểu artifact có thể tham gia vào một chuyển đổi. Điều này thì rất hữu ích khi trong một chuyển đổi có thể triệu gọi các Web services bên ngoài hoặc có thể chỉnh sửa, bổ sung các artifact. Nói chung, nhà phát triển chuyển đổi phải đảm bảo vào tính toàn vẹn của các artifact được xử lý trong một chuyển đổi. Kết quả là cần phải đảm bảo rằng tập các artifact đầu vào phải thuộc vào một trạng thái được định nghĩa (nghĩa là tất cả các thông số được yêu cầu phải được xác định, các profile cần thiết phải được thêm vào trong mô hình và nội dung cần thiết trong các mô hình là các artifact được kiem Hướng dẫn 5: Cần một đặc tả của việc kiểm tra để duy trì sự toàn vẹn của chuyển đổi sau khi thực hiện các thay đổi trong mô hình đích Khi các chuyển đổi trở thành một phần trong quy trình phát triển lặp, dường như sau mỗi chuyển đổi được thực thi, các artifact, cả input và output đều phải được cập nhật bằng tay. Điều này là theo một quy tắc chung của phát triển hướng mô hình: các thay đổi được đưa vào hệ thống trong các mô hình với mức trừu tượng thích hợp nhất, bất kể mức trừu tượng đó là mức nào. Ví dụ, một thực thể Customer được mô tả trong mô hình phân tích cấp cao có thể không chứa thông tin về cách lưu trữ (optimistic, pessimistic…). Vì vậy các thay đổi đối với cách lưu trữ này không cần đưa vào mô hình phân tích, mà nên đưa vào mô hình thiết kế nơi chúng có sẽ có ảnh hưởng nhiều nhất. Do do sự thêm vào một thuộc tính khóa mới đối với class Customer sẽ có thể đòi hỏi một thay đổi trực tiếp lên mô hình phân tích cấp cao. Khi chính xác và sau một ước lượng có thể, thay đổi này sẽ Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 85 được phản ánh chính xác lên mô hình cấp thấp, như kết quả của một chuyển đổi MDA tự động. Vì các quy trình phát triển lặp đều khuyến khích sự phát triển của mô hình thông qua một quy trình phát triển, một đặc tính quan trọng cũa một chuyển đổi tốt là khả năng phân tích trạng thái hiện tại của các artifact và so sánh chúng với trạng thái mong muốn sau khi thực hiện xong chuyển đổi. Bước này được khuyến khích trong các chuyển đổi được tạo bằng MDA Toolkit là bước kiểm chứng (verification). Thông thường bước kiểm chứng này chạy riêng biệt và chạy sau khi các artifact đã trải qua chuyển đổi và các điều chỉnh sau đó. Do đó, các mô hình và artifact cuối có thể trải qua sự tính chế thêm mà sự tinh chế này không liên quan đến bất kỳ thông tin ngữ nghĩa nào được quản lý bởi quy trình chuyển đổi. Trong suốt quá trình tinh chế này, các thay đổi (mặc dù không mong muốn) có thể làm đứt các liên kết về ngữ nghĩa giữa các mô hình. Thực thi tường minh bước kiểm chứng trong một chuyển đổi sẽ tạo ra một bản tường trình cho nhà phát triển về bất kỳ các đứt quãng trong ánh xạ ngữ nghĩa được thiết lập bởi chuyển đổi ban đầu. Các đứt quãng này sau đó có thể được thực hiện một cách chính xác hơn bởi nhà phát triển, kết quả là sẽ có một số thay đổi trong mô hình đích hoặc mô hình nguồn hoặc cả hai. Hướng dẫn 6: Trong hầu hết các trường hợp MDA, các ánh xạ mô hình đến mô hình thường phức tạp và đòi hỏi sự thiết kế và hiện thực cẩn thận. Logic cốt lõi trong một chuyển đổi thường là thuật toán trong đó một tập hợp các thành phần mô hình được chuyển đổi thành một tập hợp khác. Trong một ánh xạ kiểu khai báo đơn giản, các kết nối là tương đối đơn giản, dễ thực hiện, và có ít sự nhập nhằng. Trong các chuyển đổi MDA có quy mô lớn, các ánh xạ luôn không quá đơn giản. Thường một thành phần trong mô hình nguồn sẽ ánh xạ dến một cấu hình của các thành phần theo một tập hợp các điều kiện phức tạp bao gồm các thành phần mô hình khác, các kết nối và các stereotype và tag value của các profile UML khác nhau. Lấy một ví dụ đơn giản một thực thể có tên là Addres. Thực thể này gồm nhiều thuộc tính, một trong các thuộc tính đó được được đánh tag là khóa chính (trong profile đánh dấu). Ánh xạ một class trừu tượng như thực thể này thành một đối tượng Java và thiết kế cơ sở dữ liệu là tương đối dễ thực hiện (xem hình 2-20). Một đối tượng Java được tạo ra với các thuộc tính được phản chiếu và các kiểu dữ liệu được hiệu chỉnh cho chính xác. Các hàm get và set cũng được tạo thêm. Trong thiết kế cơ sở dữ liệu, một table và các column được tạo ra với tên được điều chỉnh cho phù hợp với các chuẩn đặt tên của cơ sở dữ liệu. Khóa chính (được xác định bởi tag trong profile đánh dấu) được gán. Các kiểu dữ liệu được chuyển đổi với sự trợ giúp của profile đánh dấu. Profile đánh dấu có thể được sử dụng để xác định các giá trị null và các thuộc tính cở sở dữ liệu điển hình khác. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 86 Hình 2-20: Ánh xạ một thực thể đơn giản vào các mô hình đối tượng và mô hình thiết kế Ví dụ đơn giản này đã minh họa cho việc ánh xạ một class trong mô hình trừu tượng thành một class trong mô hình đối tượng và một table trong mô hình dữ liệu. Các thuộc tính trong mô hình trừu tượng ánh xạ một-một các thuộc tính trong mô hình đối tượng và các column trong mô hình dữ liệu. Các phương thức trong mô hình đối tượng tất cả đều có thể truy ngược lại một thuộc tính mô hình trừu tượng. Tuy nhiên, trong ví dụ khác, việc ánh xạ không còn quá dễ dàng. Xét một ví dụ thứ hai là một tập các class tham gia trong hệ thống phân cấp trong mô hình phân tích (hình 2-21) Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 87 Hình 2-21: Mô hình phân tích Các class RestrictedProduct và CommercialProduct là sự phân loại từ Product. Class Product cũng xác định hai thuộc tính (code và supplier) là định danh đối tượng hay khóa chính. Tuy nhiên chúng thường được xác định bằng tag value hoặc stereotype mà tag value hay stereotype này có thể không xuất hiện trực tiếp trên lược đồ (có thể xem bằng cách xem property của thuộc tính). Bằng cách sử dụng các quy tắc đặt tên của tổ chức và các chiến lược ánh xạ thuộc tính, vẫn có ba cách rất khác nhau để một tập các class có thể được chuyển đổi thành một mô hình cơ sở dữ liệu. Chúng ta có thể gọi đó là ba chiến lược như sau “Roll Up”, “Roll Down” và “Separate Tables”, và các chiến lược này được hỗ trợ bởi Data Modeler của IBM Rational XDE, như trong hình 2-22. Hình 2-22: Chiến lược Roll up Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 88 Trong chiến lược đầu tiên, một bảng mới T_PRODUCT_TYPE được tạo ra bằng cách lấy class cơ sở và thêm tiền tố _TYPE. Các column trong bảng này được định nghĩa trước bởi ánh xạ và luôn được tạo ra giống nhau trong các lần áp dụng chuyển đổi. Table này được sử dụng để cung cấp một phương tiện mở rộng để thêm vào các kiểu mới. Tất cả các thuộc tính của các class con được đưa vào (roll up) trong một bảng chính. Trong chiến lược Roll Down, được minh họa trong hình 2-23, tất cả các class cụ thể (concrete class) được tạo bảng riêng cho nó. Trong đó các column trong class cơ sở được nhân bản vào trong tất cả các bảng. Hình 2-23: Chiến lược Roll Down Cuối cùng là chiến lược Separate Tables, được minh họa trong hình 2-24, mỗi class được ánh xạ thành một bảng, và các quan hệ định danh được tạo ra giữa class cơ sở và class con để các thuộc tính của class cơ sở được ánh xạ trong table class cơ sở có thể được truy xuất bởi các hàng dữ liệu tương ứng trong các table con. Trong cả ba chiến lược, các table sử dụng khóa tổng hợp (composite key) được ngầm định bởi class cơ sở chính. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 89 Hình 2-24: Chiến lược Separate tables Từ ví dụ này, rõ ràng các chiến lược ánh xạ không còn đơn giản và một số thành phần trong mô hình trừu tượng có thể ánh xạ đồng thời đến nhiều thành phần khác nhau trong thiết kế cơ sở dữ liệu. Ngoài ra, trong trường hợp Roll Up, ba class phân tích được ánh xạ thành hai table, với chỉ một trong số chúng dùng chung tên với class phân tích. Mô hình đối tượng cũng có thể có các yêu cầu cho chỉ một thuộc tính như một khóa đối tượng (như trong J2EE). Kết quả chuyển đổi thành mô hình đối tượng Java được minh họa trong hình 2-25. Vì có hai thuộc tính tạo nên một khóa đối tượng, một class khóa (key class) mới được tạo ra và một quan hệ định hướng (direction association) được thêm vào thiết kế đối tượng ngoài hàm get và set. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 90 Hình 2-25: Thiết kế đối tượng java với quan hệ tổng quát hóa và khóa kết hợp Trường hợp này cũng minh họa cho các phức tạp tiềm ẩn trong các ánh xạ sử dụng trong thực tế. Trương hợp này sẽ trở nên phức tạp hơn nhiều khi các luật quyết định chiến lược ánh xạ phụ thuộc vào sự kết hợp giữa các tag value và cấu hình mô hình phân tích (nghĩa là sử dụng Roll Up khi có nhiều nhất là ba class, thay thế các khóa tổng hợp với một khóa integer được tạo tự động nếu giá trị tag override không được gán là False…) Trong một tầm nhìn nhỏ, không có vấn đề nào là không vượt qua được, và mỗi trường hợp, được kiểm tra tách biệt, làm rất tốt, thường tương ứng với những gì các nhà thiết kế và phát triển đã phải làm bằng tay trong nhiều năm. Tuy nhiên, khi được tập họp lại vào một chuyển đổi, mà cần phải cộng tác với cấu trúc và nội dung của các mô hình đích, các logic phức tạp và đan xen lẫn nhau thường gây khó khăn cho việc biểu diễn các chuyển đổi đơn thuần là kiểu khai báo. Trong các trường hợp này, các chuyển đổi tốt nhất là được biểu diễn và hiện thực theo thuật toán. Đây cũng là kiểu sử dụng mặc định của MDA Toolkit. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 91 Hướng dẫn 7. Các chuyển đổi có thể được thể hiện bằng khai báo hoặc bằng câu lệnh. Nói chung, cách tiếp cận bằng câu lệnh thì phù hợp hơn khi mô tả các chuyển đổi phức tạp. Trong khi MDA Toolkit nhấn mạnh đến việc thể hiện theo kiểu câu lệnh, nó cũng cho phép các pattern XDE triệu gọi, hoặc hỗ trợ các hàm khai báo. MDA Toolkit cho phép các nhà phát triển chuyển đổi tạo ra các mô hình tham chiếu (reference model) với tập các thành phần mô hình đã được định nghĩa trước, mà các thành phần mô hình này có thể được copy có chọn lọc đến một mô hình đích và được thay đổi trong suốt quá trình sao chép. Hình 2-26 là một đoạn mẫu mô hình tham chiếu chứa các class và các quan hệ. Một số class có thuộc tính và hàm. Các hàm có code template (code mẫu) cho chúng, được sử dụng để tạo ra nội dung code của hàm hoàn chỉnh. Tên của các thành phần mô hình không phải là tên Java hợp lệ, vì tập các class này không được sử dụng để tạo ra code trực tiếp. Đúng hơn là, tập các class này sẽ được copy vào trong một code model, và trong lúc copy, các tên thành phần sẽ được cập nhật cho phù hợp với tên thật của các class có trong mô hình nguồn của chuyển đổi. Hình 2-26: Một pattern của các thành phần mô hình trong mô hình tham chiếu Quy trình tổng quan của chuyển đổi là xử lý một mô hình nguồn (một mô hình độc lập platform, PIM) và tìm kiếm các class có tag là class được quản lý (<<managed class>>), nghĩa là các class có stereotype hoặc tag value được xác định trong chuyển đổi. Việc đánh dấu trong mô hình PIM chỉ ra rằng class nào cần được chuyển đổi thành một tập các class trong mô hình PSM đích. Do đó đối với mỗi class được quản lý trong PIM, tập hợp các class trong hình 2-26 sẽ được copy vào vị trí thích hợp trong PSM, và trong suốt quá trình copy này, các tên sẽ được chỉnh sửa cho phù hợp với thông tin trong class PIM nguồn. Hình 2-27 thể hiện các kết quả của việc chuyển đổi một class trong PIM có stereotype là > vào trong PSM. Kết quả là có 4 class mới được tạo Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 92 thành, các tên của các class này dựa trên tên của class PIM nguồn. Chuyển đổi không chỉ copy trên cấu trúc và các thuộc tính class từ đoạn mẫu mô hình tham chiếu, mà còn tăng cường thêm cho các class mới được tạo các thuộc tính và hàm của class PIM. Các hàm get và set cũng được tạo thêm trong class PSM. Hình 2-27: Áp dụng một pattern dựa trên mô hình tham chiếu Loại tiếp cận này tăng cường kiểu định nghĩa pattern khai báo và trực quan với sự điều khiển code bến dưới. Trong suốt quá trình chuyển đổi, các hàm callback được gán và có thể được triệu gọi trong quá trình copy. Điều này cho phép nhà phát triển có cơ hội để xác định và tinh chế các tên đích của tất cả các thành phần được copy. Sau khi tạo và copy các thông tin trong mô hình tham chiếu, phần còn lại của chuyển đổi sẽ copy tất cả các thuộc tính và hàm publuc của các class PIM và tạo ra các hàm get và set. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 93 2.4.5.4. Về vấn đề tạo UML Profile Hướng dẫn 8: UML Profile có thể được sử dụng để để quản lý sự đánh dấu (markup) như là một phần của sự chuyển đổi (transformation). UML Profile được sử dụng trong hai cách riêng biệt và tách rời. Đầu tiên, vai trò truyền thống của UML profile là cung cấp một cơ chế để mở rộng ngữ nghĩa của UML theo các domain khác nhau. Profile lập mô hình dữ liệu và profile lập mô hình nghiệp vụ là các ví dụ của các profile UML cho phép IBM Rational XDE lập mô hình các quá trình nghiệp vụ và các thiết kế cơ sở dữ liệu vật lý, luận lý tương ứng. Các profile cũng là cơ chế hữu ích để quản lý sự đánh dấu mô hình (model marking), một yếu tố cần thiết của quá trình chuyển đổi mô hình của MDA. Đánh dấu là một bước hoặc một kĩ thuật ở trong MDA mà trong đó, các thông tin thêm vào không phải thuộc ngữ nghĩa của chính mô hình, và được dùng cho quá trình tự động sau này. Đánh dấu mô hình thường chỉ được làm ngay trước khi một chuyển đổi đã sẵn sàng để triệu gọi. Dĩ nhiên, một mô hình có thể được đánh dấu trong lúc nó đang được phát triển. Tuy nhiên, vai trò và kỹ năng của các nhà phát triển tạo ra các mô hình không thích hợp cho việc hiểu ý nghĩa và mục đích của các đánh dấu khác nhau. Ví dụ, giả sử một mô hình thực thể trừu tượng đơn giản (một phần của mô hình phân tích truyền thống) dùng UML để phát triển bởi các nhà phân tích. Mô hình này định nghĩa một số thực thể persistent trong hệ thống, bao gồm các thuộc tính của chúng và các mối quan hệ giữa chúng. Mô hình này sẽ được chuyển đổi sang một thiết kế cơ sở dữ liệu luận lý (hoặc vật lý). Nhưng vấn đề xãy ra là khi sử dụng một mô hình phân tích để chuyển sang một mô hình dữ liệu mới, bởi vì các thông tin lưu trong mô hình phân tích là không đủ cho một mô hình dữ liệu làm việc. Ví dụ, một kiểu một thuộc tính String của một thực thể có thể hiện thực thành một column kiểu char, varchar hoặc text. Thông tin về chiều dài tối đa của cột cũng là một thông tin thường không được biểu diễn trong mô hình phân tích. Các chuyển đổi đi từ một mô hình trừu tượng cao sang mô hình trừu tượng thấp rồi sang các mô hình có mức trừu tượng thấp hơn và chi tiết hơn nữa thường phải đối mặt với bài toán thông tin chưa hoàn tất trong mô hình. Ngay cả khi ánh xạ các association vào các field trong Java, việc xác định cách chuyển đổi các association có bậc là “1..n” cũng không rõ ràng. Các ngữ nghĩa của set, list, và map cũng vượt quá phạm vi ngữ nghĩa của hầu hết các mô hình phân tích UML, nhưng chúng lại được sử dụng trong các class Java. UML profile như là một giải pháp ở đây để sử dụng cho giai đoạn chuyển đổi. Một profile đánh dấu, phân biệt và tách hẳn khỏi bất kỳ một profile ngữ nghĩa nào, có thể được áp dụng vào mô hình bao gồm các stereo type và các tag value chỉ dùng duy nhất cho việc chuyển đổi. Một profile lập mô hình dữ liệu có thể chứa các tag mô tả chiều dài của cột... Một Java profile chứa các thông tin về cách chuyển đổi một association thành một phần tử trong class của Java. Bộ MDA toolkit cho phép tạo ra các profile sử dụng cho bất kỳ mô hình nào có thể mở được bởi Rational XDE. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 94 2.4.5.5. Về vấn đề phát triển chuyển đổi Hướng dẫn 9: Các chuyển đổi nên được tạo ra theo cách mà chúng có thể tham gia vào một quá trình phát triển lặp đi lặp lại. Trong khi các chuyển đổi chỉ sử dụng một lần có vẻ dễ dàng để phát triển, tuy vậy người ta cũng thấy rằng mức độ và khả năng sử dụng của các chuyển đổi này cũng thấp như công sức đã bỏ ra để hiện thực chuyển đổi đó. Phát triển các chuyển đổi với MDA Toolkit để các chuyển đổi này tham gia vào quá trình phát triển lặp yêu cầu người phát triển chú ý kỹ đến các thành phần trong thiết kế và hiện thực. MDA API cung cấp các phương thức chính cho sự truy xuất và thao tác trên mô hình chính là các API phục vụ cho quá trình phát triển chuyển đổi lặp. Ví dụ, khi tạo một thuộc tính trên một class, phương thức createAttribute() của đối tượng MdaClass mặc định đầu tiên sẽ kiểm tra kiểm tra xem có tồn tại một thuộc tính với tên đó trong mô hình hay chưa, nếu đã có, nó sẽ không tạo một thuộc tính trùng lắp với thuộc tính đó. Một điều thú vị là đây không phải là một hành vi mặc định của các API cung cấp để truy xuất UML bởi vì bảng đặc tả UML không hề yêu cầu tên của các thuộc tính là duy nhất. Do đó, về lý thuyết, các API này nên cho phép điều trùng lắp trên. Tuy nhiên, hầu hết các chuyển đổi của chúng ta đều nhắm vào một ngôn ngữ lập trình như là Java hay C++, do đó, trên thực tế ta sẽ không cho phép sự trùng lắp tên thuộc tính. MDA Toolkit API có cách hiện thực như sau: khi nó so sánh các tên class cũng như các tên của thuộc tính, nó tìm kiếm sự duy nhất trong container và sử dụng các so sánh phân biệt chữ hoa và chữ thường (case-sensitive); khi so sánh các phương thức, nó thực hiện các so trùng tên phương thức (có phân biệt chữ hoa và chữ thường) kết hợp với so sánh kiểu dữ liệu của danh sách các đối số input và bỏ qua kiểu trả về của phương thức. Do vậy, MDA toolkit API cho phép các nhà phát triển chuyển đổi với đích là C++ hoặc Java phát triển một chuyển đổi cho phép sử dụng lặp một cách dễ dàng hơn. Quá trình phát triển một chuyển đổi dựa vào MDA Toolkit nhỏ hơn nhiều so với một bài tập phát triển code trong Java và cụ thể là trong phát triển một Eclipse Java Plugin. MDA Toolkit wizard cung cấp hầu hết code mà Eclipse yêu cầu và để cho các nhà phát triển chuyển đổi nhắm vào việc hiện thực chuyển đổi logic. Hướng dẫn 10: Một chuyển đổi tốt hiện thực các thủ tục kiểm chứng (validation), chuyển đổi và xác nhận (verify). Khi MDA Toolkit wizard tạo một project, nó cung cấp các stub cho ba phương thức quan trọng này như trong ví dụ sau: public boolean validate() throws Exception{ boolean valid = true; return valid; } Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 95 public void transform() throws Exception { } public boolean verify() throws Exception { boolean verified; return verified; } Phương thức quan trọng nhất là transform(), phương thức này được triệu gọi khi nhà phát triển muốn triệu gọi quá trình chuyển đổi. Trong phương thức này các logic nghiệp vụ của chuyển đổi được coding. Các logic nghiệp vụ của chuyển đổi thường được giao cho các phương thức helper và các class xây dựng theo nhu cầu chuyển đổi riêng của từng người để chúng thực hiện công việc chuyển đổi thật sự. Trong suốt quá trình chuyển đổi, sẽ rất hữu ích khi viết các thông điệp chuyển đổi vào một nơi có thể thấy được để các nhà phát triển có thể giám sát quá trình. Một ví dụ chuyển đổi mẫu được chỉ ra trong ví dụ sau. Các tên các file mô hình phân tích và mô hình thiết kế là các thông số. Các giá trị của thông số có thể được truy xuất thông qua việc gọi một phương thức của class cha. Sau đó chúng sẽ được chuyển sang các tham chiếu thành phần của mô hình MDA. Trong bảng này, mô hình phân tích được quét để tìm các class có stereotype là “Persistent Object” (trong một profile) và không là class con của class khác, bởi vì toàn bộ cây phân cấp được xử lý trong một chức năng. Hầu hết công việc là phối hợp nhờ vào phương thức helper processPersistenceObject(), một phương thức sử dụng các class được phân công (delegate) để thực hiện công việc chuyển đổi. Ví dụ: Hiện thực mẫu tìm các class có stereotype “PersistentObject” trong mô hình phân tích. public void transform() throws Exception { writeln("Transformation has started ..."); String analysisModelFilename = getStringParameter(TransformationParameters. P_FILE_PIM_MODEL); String designModelFilename = getStringParameter(TransformationParameters. P_FILE_PSM_MODEL); MdaModel designModel = openModel("psm", designModelFilename); MdaModel analysisModel = openModel("pim", analysisModelFilename); if( pim != null && psm != null && stereotype.length()>0 ) { MdaClass[] classes = analysis.getMdaClasses(MdaOption.RECURSE); for(int i=0;i<classes.length;i++) { Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 96 MdaClass pimCls = classes[i]; MdaGeneralization ger=pimCls.getMDAGenaralizations(); if(ger.length()==0 && pimCls.isStereotyped(“MyCustomProfile”, PersistentObject)){ processPersistentObject(); } } } writeln("Transformation has completed."); } Phương thức validate() được gọi trước khi gọi phương thức transform() và nếu validate() trả về một giá trị false, phương thức transform sẽ không được thực thi. Trong hiện thực mẫu trong ví dụ sau, mô hình phân tích được kiểm tra để đảm bảo chắc chắn rằng nó thật sự đang tồn tại và nó áp dụng một profile theo yêu cầu. Mô hình thiết kế được kiểm tra về sự tồn tại của nó và nó là một mô hình code, tức có thể thực hiện kỹ thuật roundtrip trên code Java. Ví dụ: Mô hình phân tích được kiểm tra cho việc áp dụng các UML profile và kiểm tra mô hình thiết kế để đảm bảo khả năng roundtrip. public boolean validate() throws Exception{ boolean valid = true; writeln(“Starting validation); String designModelFilename= getStringParameter(TransformationParamaters.P_FILE_PSM_MODEL; MdaModel designModel = openModel(“designModel”,designModelFilename); if(designModel == null){ valid = false; writeln(“The design model is a required parameter and must exist.”); }else{ if( !designModel.canRTE()){ valid = false; writeln(“The design model must be an XDE Code Model”); } } Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 97 String analysisModelFilename= getStringParameter(TransformationParamaters.P_FILE_PIM_MODEL; MdaModel analysisModel = openModel(“analysisModel”,ModelFilename); if(analysisModel == null){ valid = false; writeln(“The analysis model is a required parameter and must exist.”); }else{ if(!analysisModel.hasProfile(“MyCustomProfile”){ valid = false; writeln(“The profile “MyCustomProfile” must be” +”applied to analysis model!”); } } writeln(“Validation completed!”); return valid; } Phụ thuộc vào mức xác nhận mong muốn, một method verify() có thể rất phức tạp, ngang bằng với phương thức transform, và thường nó sử dụng các phương thức và class helper tương tự với code chuyển đổi thực sự. Trong ví dụ sau, đoạn code mẫu này dùng để nhận dạng các thành phần trong mô hình phân tích cần chuyển đổi. Ví dụ: method verify() public boolean verify() throws Exception { writeln("Verifying transformation ..."); boolean verified = true; String analysisModelFilename = getStringParameter(TransformationParameters.P_FILE_PIM_MODEL; String designModelFilename = getStringParameter(TransformationParameters.P_FILE_PSM_MODEL; MdaModel designModel = openModel("psm", designModelFilename); MdaModel analysisModel = openModel("pim", analysisModelFilename); if( pim != null && psm != null && stereotype.length()>0 ) { MdaClass[] classes = analysis.getMdaClasses(MdaOption.RECURSE); for(int i=0;i<classes.length;i++) { Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 98 MdaClass pimCls = classes[i]; MdaGeneralization ger=pimCls.getMDAGenaralizations(); if(ger.length()==0 && pimCls.isStereotyped(“MyCustomProfile”, PersistentObject)){ verifyPersistentObject(pimCls); } } } else { writeln("\tRequired parameters not available."); } writeln("Verification complete."); return verified; } Sự phát triển và kiểm tra một chuyển đổi MDA tiến hành như các project Eclipse plugin khác. Một chuyển đổi có thể được debug thông qua sử dụng Eclipse runtime workbench. 2.4.5.6. Về vấn đề triển khai chuyển đổi Hướng dẫn 11: Sử dụng kiến trúc Eclipse plugin để đơn giản hoá quá trình cài đặt và nâng cấp các chuyển đổi MDA. Khi một chuyển đổi được phát triển xong, cần phải triển khai và hướng dẫn sử dụng chuyển đổi đó. Cơ chế Eclipse Update Manager cung cấp một một cơ chế thuân tiện cho việc cài đặt các plugin vào trong Eclipse. Sử dụng các chức năng của Eclipse Plugin Development Environment (PDE), chuyển đổi có thể được đóng gói và đặt trên internet do đó dễ dàng tải (download) và cài đặt các chuyển đổi này và các plugin phụ thuộc khác. Khi chuyển đổi đã được cài đặt, một menu chuyển đổi có thể được tích cực (thấy được) ở bất kỳ khung làm việc nào (lập mô hình, code...). Nhà phát triển có thể tuỳ ý chạy ba phương thức (validate, transform và verify) đồng thời hoặc chạy chúng riêng rẽ. Kết quả sẽ xuất hiện trong mô hình đích và quá trình chuyển đổi sẽ được hiển thị trên cửa sổ log (log view). Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 99 3. Hiện thực 3.1. Pattern và Code Template 3.1.1. DateHelperLib -Bao gồm các phương thức xử lý ngày tháng như: so sánh hai ngày, định dạng ngày tháng… 3.1.2. FileHelperLib -Bao gồm các phương thức quản lý file như: copy file, xóa thư mục, lấy đuôi file… Người sử dụng có thể áp dụng hai hiện thực trên vào mô hình hệ thống và sinh code. Code được sinh ra chưa tự import các thư viện Java, người sử dụng sẽ tự động import các thư viện này thông qua chức năng hỗ trợ import của Rational XDE. (Click chuột phải vào editor window, chọn Organize Import hoặc click trái vào phần gợi ý sửa lỗi trong editor window). 3.2. Plugin 3.2.1. Plugin UserManagement 3.2.1.1. Chức năng Thực hiện đọc mô hình UML, sinh ra các phương thức dựa theo Hibernate framework để quản lý User ở tầng DAO (không hiện thực các method thuộc tầng Business và tầng Presentation), mỗi phương thức bao gồm câu lệnh HQL và các lệnh khởi tạo, đóng session, transaction. Các phương thức được sinh ra bao gồm: • save: Lưu một đối tượng User vào table tương ứng trong cơ sở dữ liệu • update: Cập nhật các thông tin của đối tượng User lên table trong cơ sở dữ liệu. • remove: Xóa một đối tượng (một hàng) khỏi table trong cơ sở dữ liệu. • validate: So trùng Username và Password • isExist: Kiểm tra sự tồn tại của một đối tượng User trong table. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 100 • getUser: Trả về một đối tượng User trong table. Hệ quản trị cơ sở dữ liệu quan hệ được sử dụng có thể là bất kỳ DBMS quan hệ nào: Oracle, SQL Server, PostGreSQL… 3.2.1.2. Hiện thực: • Platform đích: Hibernate, Java. • Công cụ sử dụng: Rational XDE for Java, MDA Toolkit. • Hiện thực plugin bằng ngôn ngữ Java dựa trên MDA transformation wizard do MDA toolkit cung cấp trên công cụ Rational XDE. • Bước 1: Dùng Rational XDE (có MDA Toolkit) tạo một profile UserProfile, bao gồm các stereotype sau: -Stereotype cho Class: > -Stereotype cho các thuộc tính (Atribute) > > Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 101 Hình 3-1: Mô tả một mô hình tạo các stereotype phục vụ cho plugin quản lý User Sau khi hoàn chỉnh mô hình trên, ta sử dụng MDA Profile Tool để đăng ký một profile mới với hệ thống, tên của profile này là UserManager. Từ đây, tất cả các mô hình được lập trên Rational XDE đều có thể áp dụng profile này. • Bước 2: Xây dựng plugin thực hiện chuyển đổi từ mô hình sang code: -Tạo một plugin project dựa trên MDA Transformation Wizard. -Đọc từ mô hình nguồn hệ thống, thực hiện các phương thức chính sau: 1. validate: kiểm tra tính hợp lệ các thông số Input. 2. transform: chỉ thực hiện khi validate thành công. Với bất kỳ class nào có áp dụng «UserManagement» kiểm tra xem các phương thức và các thuộc tính của nó có áp dụng các stereotype trong UserManager Profile hay không, nếu có sinh ra các phương thức quản lý User tương ứng như đã nêu ở phần chức năng. Hiện thực cụ thể: Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 102 • Tìm trong mô hình hệ thống (trong Class Diagram) các class có stereotype là «UserManagement». • Với mỗi class có stereotype là «UserManagement»: o Xác định tên table tương ứng với class này, khoá chính của table đó, file nguồn tương ứng sẽ được sinh code: Parameter param = new Parameter(".hbm"); String tableKeycolumn = param.getTableKeyName(hibernateDir, normalizeName(pimCls.getName().trim())); String className = param.getTableName(hibernateDir, normalizeName(pimCls.getName().trim())); String FilePathToWrite=param.getFiletoWriteMethod (hibernateDir,className); o Duyệt qua các thuộc tính trong class này: Tìm trong class hai thuộc tính có stereotype >, >. Phân tích file ánh xạ XML trong thư mục Hibernate để tìm ra các thông số cần thiết cho các phương thức được sinh ra. Sinh ra các phương thức save, update, remove, validate, isExist, getUser để hiện thực tầng DAO, tương tác với table tương ứng với class có stereotype > trong mô hình UML nói trên. o Nếu người sử dụng có chọn sinh ra class Java Hibernate Session Factory, ta sẽ sinh ra một class HibernateSessionFactory có các phương thức quản lý việc khởi tạo và kết thúc của Session 3. verify: kiểm tra tính thống nhất giữa model và code sinh ra. 3.2.1.3. Hướng dẫn sử dụng plugin: Công cụ sử dụng: • Rational XDE (+MDA Toolkit) • My Eclipse (+Hibernate Synchronizer) Transformation được đóng gói dưới dạng plugin do đó, ta có thể lấy plugin này cho vào thư mục plugins của công cụ RationalXDE. 3.2.1.3.1. Yêu cầu -Người sử dụng phải áp dụng UserManager profile vào model hệ thống Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 103 -Người sử dụng dùng XDE lấy model hệ thống đã vẽ để sinh ra file script (chứa các câu lệnh SQL) để tạo table theo một DBMS nhất định. Sau đó, dùng file script này và DBMS đã chọn đó để tạo database. -Dùng một MyEclipse (hoặc một IDE bất kỳ) có hỗ trợ Hibernate Synchronizer để ánh xạ các table thành các đối tượng Java, một table tương ứng với ba thành phần sau: • File XML ánh xạ giữa table và class • Java Abstract Class • Java Class thừa kế từ abstract class trên. Các method sẽ được ghi vào class này Ba thành phần này sẽ được chứa trong cùng một thư mục Hibernate dùng tương tác với cơ sở dữ liệu bên dưới. 3.2.1.3.2. Triệu gọi Transform Các thông số Input: • PIM Model: Tên file của mô hình UML hệ thống. Mô hình này phải áp dụng profile UserManager • Code (PSM) Model: Mô hình code cho project. Đây là mô hình trong đó các class được sinh ra. • Prefix: Prefix trong tên của các table. • Hibernate Directory: Thư mục chứa các class Java do Hibernate Synchronizer sinh ra. • CreateSessionFactory: Check box cho phép người sử dụng chọn sinh ra Class HibernateSessionFactory hay không. • Session Factory Package: Nếu người sử dụng đánh dấu vào Check box “Create SessionFactory”, người sử dụng phải xác định đường dẫn packge đích cho file HibernateSession Factory. Các thông số này có thể được thiết lập trên Eclipse Preferences chuẩn (Windows|Preferences). Ở Preferences Dialog này, tập các thông số có thể được điền trước do đó người phát triển không cần phải nhập các thông số này mỗi khi transformation được triệu gọi. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 104 Hình 3-2: Eclipse Preferences Hình 3-3: Transformation Dialog. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 105 • Quá trình transform bao gồm ba bước, tương ứng với ba checkbox trong Transformation Dialog. o validate: kiểm tra tính hợp lệ các thông số Input o transform: chỉ thực hiện khi validate thành công. Với bất kỳ class nào có apply > kiểm tra xem các method và các attribute của nó có áp dụng các stereotype trong UserManager Profile hay không, nếu có các method quản lý User tương ứng như đã nói ở phần chức năng sẽ được sinh ra. o verify: kiểm tra tính thống nhất giữa model và code sinh ra. • Người sử dụng có thể đánh dấu một trong ba check box để yêu cầu thực hiện từng chức năng tương ứng hoặc đánh dấu cả ba check box để yêu cầu thực hiện cả ba chức năng (validate, transform, verify). o Cho phép áp dụng plugin nhiều lần nếu có chỉnh sửa trên mô hình nguồn. Các phương thức đã sinh ra của mô hình cũ sẽ được thay thế bằng các phương thức tương ứng với mô hình mới đã chỉnh sửa. • Sau khi đã đánh dấu vào các checkbox, nhấn nút OK để thực hiện quá trình sinh code. • Các thông điệp của quá trình sinh code sẽ xuất hiện trên log window của XDE. Do đó, người sử dụng có thể dễ dàng theo dõi và kiểm soát quá trình sinh code Kết quả: -Các method được sinh ra trong file Java Class đã giới thiệu ở trên 3.2.2. Plugin Search 3.2.2.1. Chức năng Hỗ trợ người sử dụng tạo phương thức có chức năng tìm kiếm trong file DAO (là file chứa các chức năng thêm vào ngoài các chức năng cơ bản là load, update, retrieve, delete, thực hiện trên đối tượng mang dữ liệu – transient data, cụ thể trong Hibernate là các file class ánh xạ từ cơ sở dữ liệu lên). • Input: o Mô hình UX của ứng dụng có áp dụng profile SearchProfile. Mô hình này chứa các class có stereotype là > và các attribute có stereotype là >. o Thư mục chứa file ánh xạ có extension là hbm của Hibernate. • Output: Các phương thức có chức năng tìm kiếm trong các file DAO tương ứng. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 106 3.2.2.2. Hiện thực • Platform đích: Hibernate, Java. • Công cụ sử dụng: Rational XDE for Java, MDA Toolkit. • Hiện thực plugin bằng ngôn ngữ Java dựa trên MDA transformation wizard do MDA toolkit cung cấp trên công cụ Rational XDE. Quy trình phát triển • Bước 1: Tạo một plugin-in project sử dụng wizard MDAToolkit Transformation Wizard. • Bước 2: Định nghĩa các danh sách các thông số transform: public static final String P_FILE_SEARCH_MODEL = "searchModelTransformationSearch"; public static final String P_HIBERNATE_DIRECTORY = "HibernateDirectory"; • Bước 3: Định nghĩa các giá trị mặc định cho các thông số transform: setDefault(P_FILE_SEARCH_MODEL,""); setDefault(P_HIBERNATE_DIRECTORY,""); • Bước 4: Định nghĩa các controls GUI cho các thông số transform: addField(new FileFieldEditor(P_FILE_SEARCH_MODEL, "&Search Model file:", parent)); addField(new DirectoryFieldEditor(P_HIBERNATE_DIRECTORY,"Hibernate directory", parent)); • Bước 5: Định nghĩa logic chuyển đổi: được hiện thực trong hàm transform. Sau khi lấy các thông số nhập (đã được validate hoặc chưa được validate, tùy vào người sử dụng có check vào check box Validate hay không, do đó ta vẫn cần thực hiện bước validate trong hàm này), ta sẽ phân tích: o Bước 5.1: phân tích mô hình UX để lấy ra các class có stereotype là Search và các attribute có stereotype là Search Attribute. Kết quả được chứa trong ArrayList với mỗi phần tử trong ArrayList có kiểu là <MdaClass, MdaAttribute[]> (mỗi class Search có một hoặc nhiều attribute Search) o Bước 5.2: phân tích các file ánh xạ hbm để lấy ra các tên class (mỗi class tương ứng với một table trong cơ sở dữ liệu), tên id và tên property thuộc Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 107 class đó. Kết quả được chứa trong ArrayList với mỗi phần tử trong ArrayList có kiểu là . o Bước 5.3: tạo một dialog mới sử dụng các kết quả vừa phân tích được, cho phép người dùng ánh xạ giữa attribute Search và id hoặc property trong class ánh xạ từ CSDL. o Bước 5.4: sau khi người dùng tạo ra các cặp (attributeSearch, id|property), tìm đến các file DAO tương ứng cho các class ánh xạ, tạo các hàm Search trong file này, có dạng : Search (session, SearchParamater) có kiểu trả về là ArrayList Template của nội dung: ArrayList arrRet = null; String hSQL = ""; hSQL = …. arrRet = (ArrayList) (find(hSQL, session)); return arrRet; • Bước 6: Định nghĩa logic validate các thông số do user truyền vào. 3.2.2.3. Hướng dẫn sử dụng • Bước 1: Chuyển vào perspective Modeling, mở mô hình UX của ứng dụng. Vào properties->AppliedProfiles, chọn profile SearchProfile để thêm các stereotype cần thiết cho chuyển đổi Search này. • Bước 2: Trong mô hình UX, chọn các class cần thêm chức năng search. Thêm vào stereotype > cho các class này bằng cách: click chuột vào class -> trong phần properties-> Stereotype, thêm vào “Search”. Thêm vào stereotype > cho attribute bằng cách: click chuột vào attribute->trong phần properties-> Stereotype, thêm vào stereotype >. • Bước 3: Vào menu Transform Æ TransformationSearch (nếu chưa kích hoạt thì vào menu Window -> Customize Perspective. Trong mục Available Items chọn Other, rồi check vào box TransfomationSearchMenus. Nhấn OK.). • Bước 4: Trong TransformationSearch dialog. Nhập Search Model file: nhập đường dẫn đến mô hình UX của ứng dụng. Nhập Hibernate directory: nhập đường dẫn đến thư mục chứa các file hbm của Hibernate. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 108 Hình 3-4: TransformationSearch dialog. • Bước 5: Chọn các action cần được thực hiện (validate: kiểm chứng thông số nhập, transformation: thực hiện transform). • Bước 6: Nhấn OK. Plugin sẽ phân tích mô hình và các file hbm để trích xuất thông tin cho dialog tiếp theo gồm các class (có stereotype là Search) cùng các thuộc tính (có stereotype là SearchAttribute), các class tương ứng với các table cùng với các id, property tương ứng với các column trong table đó. • Bước 7: Trong dialog SelectInfo dialog. Dùng combo ComboSearchAttribute (chứa class Search) và list ListSearchAttribute (chứa attribute Search của class đó) chọn attribute Search trong mô hình UX. Dùng combo ComboTable (chứa thông tin table) và list ListColumn (chứa thông tin column) chọn column muốn ánh xạ với attribute Search. Nhấn Select. Thông tin sẽ lập tức được hiển thị trong list SelectedItems nhằm giúp người dùng dễ dàng theo dõi. Click chuột vào dòng thông tin này, nhấn Remove sẽ loại bỏ được thông tin này. Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 109 Hình 3-5: SelectInfo dialog • Bước 8: Sau khi chọn xong, nhấn button Transform để plugin tạo ra các phương thức trong file DAO. 3.3. Ứng dụng web: WebLog Hiện thực ứng dụng Web sử dụng các công nghệ hỗ trợ ứng dụng Web đã nghiên cứu là UX (phần mô hình), JavaServer Faces, Hibernate (phần code) và các hướng tiếp cận hỗ trợ MDA (code template, transformation plugin): Ứng dụng Web này hiện thực các chức năng sau: • Login vào hệ thống, logout khỏi hện thống, đăng ký làm thành viên. Xem các thông tin (profile) và hiệu chỉnh một số thông tin của mình. • Các chức năng của admin như: xem xét, cập nhật, thêm mới, xóa user của hệ thống… Mô hình của ứng dụng Web được vẽ dựa trên ngôn ngữ UML và mô hình UX như sau: Nghiên cứu và áp dụng công nghệ MDA, các framework hỗ trợ ứng dụng Web 110 Hình 3-6: mô hình UX cho ứng dụng WebLog