Luận án Các kỹ thuật chuyển đổi mô hình và sinh mã trong phát triển ứng dụng web hướng mô hình

iểu diễn cho một đối tượng, là đầu vào hay đầu ra của một hành động).
Chuyển đổi mô hình và mã nguồn tích hợp ràng buộc OCL
Biểu đồ diễn tiến chuyển đổi bất biến trong mô hình xử lý
Chuyển đổi ràng buộc bất biến: Các ràng buộc của các Pin trong mô hình yêu cầu sẽ được chuyển đổi thành các ràng buộc bất biến, để tích hợp vào các thuộc tính của lớp xử lý, tương ứng với dữ liệu trả về từ thành phần giao diện.
Quy trình thực hiện chuyển đổi bất biến mô hình yêu cầu sang mô hình xử lý
B1: Đọc mô hình lấy danh sách các activity diagram.
B2: Với mỗi activity diagram, đọc lấy danh sách các node.
B3: Với mỗi node có sterrotype là user action. Lấy danh sách các output pin, loại bỏ các pin trùng lặp.
B4: Với mỗi pin, đọc tất các ràng buộc bất biến của pin đó. Thêm vào danh sách ràng buộc nếu chưa tồn tại.
B5: Tạo ràng buộc tương ứng và thêm vào cho các thuộc tính tương ứng trong process class tương ứng tạo ra trong U2C
- Chuyển đổi tiền điều kiện – hậu điều kiện: Các ràng buộc tiền điều kiện – hậu điều kiện sẽ được tích hợp vào phương thức validateData trong process class được tạo ra trong quy tắc chuyển đổi U2C. Dữ liệu sau khi người dùng nhập vào các input form sẽ được kiểm tra tính hợp lệ thỏa mãn các ràng buộc, trước khi tiếp tục xử lý các nghiệp vụ của hệ thống.
Biểu đồ chuyển đổi tiền điều kiện – hậu điều kiện mô hình xử lý
Quy trình thực hiện chuyển đổi tiền điều kiện - hậu điều kiện mô hình yêu cầu sang xử lý
B1: Đọc mô hình lấy danh sách các activity diagram.
B2: Với mỗi activity diagram, đọc lấy danh sách các node.
B3: Với mỗi node có stereotype là user action và có thẻ là “validated”. Lấy danh sách các output pin. Loại bỏ các pin trùng lặp.
B4: Với mỗi pin, nếu pin đó có ràng buộc OCL thì thêm pin đó cùng với các ràng buộc vào danh sách.
B5: Thêm các ràng buộc tương ứng với các pin trong bước 4 vào tiền điều kiện của phương thức validateData() trong process class tương ứng theo quy tăc U2C.. Hậu điều kiện là kết quả trả về dữ liệu hợp lệ hoặc không.

Bổ sung các quy tắc chuyển đổi mô hình
Quy tắc chuyển đổi U2C (User acction in activity to process Class): Process class được sử dụng để tích hợp các quá trình xử lý vào mô hình điều hướng và xác định dữ liệu được trao đổi giữa ứng dụng với người sử dụng trong suốt quá trình hoạt động. Nếu quá trình xử lý này cần một số bước tương ứng với các giao diện người dùng khác nhau. Thì quá trình xử lý này phải được chia thành các quá trình xử lý nhỏ hơn tương ứng với mỗi hành động của người dùng, được thể hiện bằng user action trong activity diagram [77]. Quy tắc này sẽ chuyển đổi user action trong các mô hình activity sẽ được chuyển đổi thành process class trong mô hình xử lý. 
Quy trình thực hiện quy tắc U2C
B1: Đọc mô hình, lấy ra các biểu đồ ca activity diagram.
B2: Với mỗi activity, đọc tất cả các node. 
B3: Duyệt các node. Kiểm tra node stereotype là user action. Thêm vào danh sách
B4: Với mỗi phần tử trong danh sách node lấy được sau bước 3. Tạo một process class tương ứng.
B5: Với mỗi process class và user action tương ứng. Đọc các output pin của user action đó thêm vào danh sách pin. 
B6: Duyệt các pin trong danh sách thu được ở B5. Tạo thuộc tính tương ứng cho process class. Nếu process class đó tương ứng với một user action có gắn thẻ là “validated”. Thì tạo phương thức validateData (param1, param2, ...) cùng danh sách tham số cần kiểm tra cho process class đó.
 Quy tắc S2C (System action in activity to process Class): Tương tự như use action, system action cũng mô tả cho quá trình xử lý trong luồng xử lý. System action trong mô hình yêu cầu đại diện cho xử lý bên trong của hệ thống. Do đó, system action cũng sẽ được chuyển đổi thành process class trong mô hình xử lý. Đồng thời, nếu system action đó được gán thẻ là “confirmed” để biểu thị rằng: Trước khi thực hiện hành động xử lý đó, ứng dụng cần hiển thị thông báo để người dùng xác nhận, ví dụ như khi xóa một tài khoản người dùng trong hệ thống. 
Quy trình thực hiện quy tắc S2C
B1: Đọc mô hình, lấy ra các biểu đồ ca activity diagram.
B2: Với mỗi activity, đọc tất cả các node. 
B3: Duyệt các node, với mỗi node có stereotype là system action. Thêm vào danh sách.
B4. Với system action node đang duyệt ở B3. Kiểm tra thẻ của node đó. Nếu thẻ là ”confirmed” thì tạo confirmation node tương ứng và thêm vào danh sách.
B5: Với mỗi phần tử trong danh sách node lấy được sau B3 và B4. Tạo một process class tương ứng.
B6: Lấy tất cả các input pin của system action. Thêm vào danh sách tham số nếu chưa tồn tại trong danh sách tham số.
B7: Nếu system action có thẻ là “confirmed” thì tạo phương thức tương ứng và danh sách tham số tương ứng cho “confirmation class” tương ứng với confirmation node trong B4. Ngược lại, tạo phương thức và danh sách tham số tương ứng cho process class của node trong B3.
Quy tắc chuyển đổi U2U (User action in activity to User action in processing model): Quy tắc này sẽ chuyển đổi user action trong activity diagram thành user action trong mô hình luồng xử lý. Các pin tương ứng cũng được chuyển đổi kèm theo. Nếu user action có thẻ “validated”, nghĩa là dữ liệu nhập vào từ người sử dụng thông qua user action trong biểu đồ activity diagram này cần được kiểm tra tính hợp lệ trước khi quyết định hành động xử lý tiếp theo. Các bước thực hiện chuyển đổi của quy tắc này như sau:
Quy trình thực hiện quy tắc U2U
B1: Đọc mô hình, lấy danh sách các activity diagram.
B2: Với mỗi activity diagram đọc tất cả các node. Nếu node đó có stereotype là user action. Tạo user action tương ứng trong mô hình luồng xử lý. 
B3: Đọc tất cả các pin của node và tạo ra pin tương ứng cho user action được tạo ra ở B2.
B4: Nếu user action có thẻ “validated”. Tạo phần tử validate với stereotype là system action để thực hiện việc kiểm tra dữ liệu và một “decision node” để rẽ nhánh true/false tương ứng với hai trường hợp dữ liệu thỏa mãn các ràng buộc hoặc ngược lại.
Quy tắc chuyển đổi S2S (System action in activity to System action in processing model): Phần tử system action trong biểu đồ ca của mô hình yêu cầu biễu diễn cho hành động xử lý của hệ thống. Do đó, nó cũng sẽ được chuyển đổi tương ứng sang một system action trong mô hình luồng xử lý. Nếu system action đó được đánh dấu với một thẻ “confirmed”, thể hiện cho hành động cần được xác nhận từ người dùng trước khi xử lý. Do vậy, cần tạo thêm một user action để thực hiện việc xác nhận này.
Quy trình thực hiện quy tắc S2S
B1: Đọc mô hình, lấy danh sách các activity diagram
B2: Với mỗi activity diagram đọc tất cả các node. Nếu node đó có stereotype là system action thì tạo system action tương ứng trong mô hình luồng xử lý. 
B3: Nếu user action có thẻ “confirmed”. Tạo confirmation user action để thực hiện việc yêu cầu xác nhận lại từ người sử dụng và “decision node” để rẽ nhánh true/false tương ứng với hai trường hợp người dùng đồng ý hoặc hủy bỏ.
2.3.3. Tích hợp OCL trong mô hình trình bày
Mô hình trình bày tương ứng với thành phần giao diện của ứng dụng Web. Mô hình này sẽ chứa các form để người dùng nhập dữ liệu. Do đó, việc kiểm tra tính hợp lệ dữ liệu của các trường trong form nhập liệu là hết sức quan trọng, giúp đưa ra các thông báo, hướng dẫn nhập liệu tương ứng, nâng cao trải nghiệm của người sử dụng. Yếu tố cốt lỗi đóng vai trò thành công của ứng dụng Web.
Quy trình thực hiện chuyển đổi bất biến mô hình yêu cầu sang mô hình trình bày
B1: Duyệt danh sách các presentation group được tạo ra theo quy tắc D2G
B2: Với mỗi presentation group, đọc lấy danh sách các interation pin của display action tương ứng.
B3: Với mỗi pin, đọc tất các ràng buộc OCL của pin đó. Thêm vào danh sách ràng buộc nếu chưa tồn tại.
B4: Với mỗi ràng buộc trong danh sách lấy ở B3. Tạo ràng buộc tương ứng và thêm vào cho các thành phần tương ứng với pin đó trong mô hình trình bày

Biểu đồ chuyển đổi ràng buộc bất biên mô hình trình bày
Trong nội dung này, tác giả trình bày phương pháp chuyển đổi từ mô hình yêu cầu sang mô hình nội dung, điều hướng sang mô hình xử lý và mô hình yêu cầu sang mô hình trình bày với các quy tắc chuyển đổi bổ sung. Với mỗi quy tắc, nghiên cứu trình bày các bước xử lý và biểu đồ diễn tiến của quá trình cài đặt. Với những quy tắc chuyển đổi được bổ sung vào bộ quy tắc, giúp cho quá trình chuyển đổi tự động hiệu quả hơn.
 Bổ sung các quy tắc chuyển đổi sang mô hình trình bày:
Quy tắc D2G (Display action to group element): Display action đại diện cho thành phần hiển thị hoặc nhập dữ liệu trong mô hình hoạt động, bao gồm tập các pin. Do đó, display action sẽ được chuyển đổi thành một group element. Dựa trên type của display action thành phần tương ứng trong mô hình trình bày sẽ được tạo.
Thành phần DisplayAction type và Prentation element
Display action type
Presentation element
Form 
InputForm
Group
PresentationGroup
Alternatives
PresentationAlternatives
Iteration
IteratedPresentationGroup

Quy trình thực hiện quy tắc D2G
B1: Đọc mô hình lấy activity diagram tương ứng với process class.
B2: Đọc tất cả các node của activity diagram. Nếu stereotype là display action. Kiểm tra type của node đó và tạo thành phần ánh xạ tương ứng với node đó theo Bảng 2.1. 
B3: Nếu type của node “validated” tạo button confirm và button cancel thêm vào thành phần giao diện được tạo ra ở B2.
Quy tắc P2E (Pin of display action to UIElement): Các input pin của display action trong mô hình yêu cầu đại diện cho các trường nhập dữ liệu từ người sử dụng. Do đó, các pin sẽ được chuyển đổi tương ứng sang các UIElement trong mô hình giao diện tương ứng với Bảng 2.2 sau đây:
Các thành phần tương ứng với Pin type và giao diện
Pin Type
Thành phần giao diện tương ứng
Display Pin
Text
Text
Image
Picture
Media
MediaObject
Interaction Pin
Text
InputText
Selection
Selection
File
FileUpload
 Các bước thực hiện quy tắc P2E:
Quy trình thực hiện quy tắc P2E
B1: Đọc mô hình lấy activity diagram tương ứng với display action trong quy tắc D2G.
B2: Với activity diagram ở B1, đọc tất các input pin, thêm vào danh sách
B3: Với mỗi pin trong B3. Tạo thành phần tương ứng trong mô hình giao diện tương ứng với Bảng 2.2.

2.3.4. Kết quả và thảo luận
Nghiên cứu bổ sung các quy tắc và tích hợp ngôn ngữ rằng buộc OCL vào chuyển đổi mô hình UWE. Điểm mới của nghiên cứu, là chuyển đổi tự động giữa các mô hình hiệu quả, các thành phần của mô hình sau chuyển đổi được thể hiện chi tiết hơn, tiết kiệm thời gian hơn, do ít phải can thiệp thủ công. Kết quả cho thấy, việc chuyển đổi tự động giữa các mô hình trong UWE tốt hơn trong các nghiên cứu [1, 73, 85]. Nghiên cứu đã minh họa sự hiệu quả của phương pháp đề xuất bằng ví dụ về quản lý contact với công cụ chuyển đổi MTO-plugin, một plugin do tác giả xây dựng và được tích hợp thêm trong phần mềm MagicDraw. Trong tương lai, việc tiếp tục phát triển ứng dụng web theo hướng mô hình tích hợp với ngôn ngữ rằng buộc OCL để việc chuyển đổi giữa các mô hình tới mô hình và đặc biệt là từ mô hình sang mã nguồn được tốt hơn, áp dụng vào các bài toán khác nhau, nhằm đánh giá được đầy đủ và chính xác hơn, đó là các vấn đề mà tác giả sẽ giải quyết trong những nghiên cứu tiếp theo.
2.4. Phát triển quy tắc chuyển đổi mô hình với ATL
Nghiên cứu đã xây dựng các quy tắc chuyển đổi từ mô hình yêu cầu sang mô hình xử lý và mô hình trình bày. Trên cơ sở đó, đã xây dựng công cụ MTO-Plugin để cải tiến, nâng cao hiệu quả chuyển đổi mô hình của công cụ MagicUWE. Tuy nhiên, các quy tắc này được xây dựng bằng Java chưa phải bằng ngôn ngữ chuyên nghiệp. Hơn nữa, công cụ MagicUWE [71] hiện nay đều không còn được hỗ trợ bởi MagicDraw [86].
Để tiếp tục phát triển phương pháp UWE cho xây dựng ứng dụng web hướng mô hình, tác giả sử dụng ATL để đặc tả 06 quy tắc đã phát triển và bổ sung các quy tắc chuyển đổi mô hình yêu cầu sang mô hình nội dung và điều hướng để đảm bảo đầy đủ cách thức chuyển đổi từ mô hình yêu cầu sang mô hình nội dung, điều hướng, xử lý và trình bày. Luận án phát triển công cụ UWE-ATL tích hợp các quy tắc, cung cấp đầy đủ cách thức chuyển đổi mô hình theo phương pháp UWE. Các chuyển đổi được thực hiện tự động bằng cách sử dụng ATLAS [87].
Trong nghiên cứu này, tác giải sử dụng các metamodel đề xuất bởi UWE để biểu diễn các khía cạnh khác nhau của ứng dụng web. Phương pháp UWE là một cách tiếp cận kỹ thuật phần mềm nhằm mục đích bao quát toàn bộ vòng đời phát triển ứng dụng Web. Chuyển đổi mô hình là kỹ thuật chính trong phương pháp UWE, trong đó một mô hình là nguồn được chuyển đổi thành một mô hình đích. UWE đưa ra 05 mô hình đại diện cho những thành phần đặc trưng nhất của ứng dụng web[77]. Đặc biệt, các mô hình được xác định giống như các meta model và các thành phần của mô hình được biểu diễn bằng ngôn ngữ mô hình hóa UML.
2.4.1. Giải pháp
2.4.1.1. Siêu mô hình yêu cầu
Siêu mô hình yêu cầu chứa các khái niệm về các cấu trúc và quy tắc cần thiết để đặc tả yêu cầu của hệ thống Web. Nó cung cấp mô tả chính xác về các khái niệm được sử dụng để mô hình hóa và cho phép xây dựng các khung nhìn khác nhau về các yêu cầu của một hệ thống Web. Chúng được biểu diễn dưới dạng UML metaclasses và tạo thành metamodel của mô hình yêu cầu mà nghiên cứu sử dụng làm mô hình nguồn cho việc chuyển đổi mô hình. Requirement Metamodel với hai thành phần: Use case metamodel và activity metamodel dùng để hỗ trợ cho việc xây dựng các quy tắc ATL.
Use Case meta-model
Use case meta model (hình 2.15) được tác giả đề xuất nhằm mục đích khái quát hóa tất cả cách tiếp cận để có thể mô hình hóa các trường hợp sử dụng. Một sơ đồ ca sử dụng bao gồm các yếu tố riêng biệt, mô tả hoạt động của một hệ thống như: Bản thân hệ thống, các tác nhân tương tác với hệ thống, các dịch vụ (hoặc trường hợp sử dụng) hệ thống được yêu cầu thực hiện và các mối quan hệ giữa những yếu tố này. Trong Use Case meta-model, tác giả đề xuất gồm các thành phần: Model có thuộc tính packagedElement kiểu Object. Nó chứa tất cả các phần tử thuộc mô hình yêu cầu; Use case mô tả sự tương tác giữa người dùng bên ngoài (actor) và hệ thống, từ UseCase sử dụng ProcessingUseCase, BrowsingUseCase để chuyển thành ProcessClass, NavigationClass trong mô hình xử lý và điều hướng tương ứng; Association có 2 thuộc tính source, target và có kiểu Object, có thể biểu diễn liên kết của 2 đối tượng bất kỳ. Cụ thể được dùng để biểu diễn liên kết giữa actor với usecase, giữa các usecase với nhau và các liên kết trên biểu đồ activity, được chuyển đổi thành các quan hệ trong mô hình nội dung và các liên kết trong mô hình điều hướng.
Activity Diagram Metamodel
Siêu mô hình hoạt động chứa các thành phần và ngữ nghĩa của biểu đồ hoạt động. Một tập các phần tử của siêu mô hình hoạt động đã được tác giả lựa chọn (hình 2.16). Tập các phần tử này được xác định để chuyển đổi tự động thành các mô hình sẽ được giới thiệu trong phần tiếp theo. Các thành phần trong siêu mô hình hoạt động gồm: 
Nút quyết định cho phép chọn một luồng đi là kết quả của việc đánh giá các vị từ boolean. 
Các phần tử InitialNode và ActivityFinalNode chỉ ra nơi luồng đi bắt đầu và kết thúc.
Pin là một nút đối tượng cho đầu vào và đầu ra của các hành động. Pin gồm có inputpin, outputPin là các thuộc tính đính kèm trên các activity hoặc node trên biểu đồ hoạt động. Kiểu của pin được chuyển đổi thành các thuộc tính của đối tượng trong mô hình nội dung và thành tên các thành phần tương ứng trên mô hình trình bày.
Activity: Là biểu diễn của mô hình activity, gồm có name và thuộc tính được trỏ tới tất cả các đối tượng thuộc biểu đồ activity được sử dụng để chuyển đổi sang các thành phần trong mô hình điều hướng và xử lý tương ứng.
Action là hành động trên biểu đồ activity gồm có: Các user action và system action trong biểu đồ hoạt động chịu trách nhiệm cho quá trình xử lý dữ liệu trong ứng dụng Web. Do đó, chúng được chuyển thành các ProcessClass tương ứng trong mô hình xử lý. DisplayAction đại diện cho thành phần hiển thị hoặc nhập dữ liệu trong biểu đồ hoạt động, bao gồm tập các pin. Display action sẽ được chuyển đổi thành các thành phần tương ứng trong mô hình trình bày dựa trên kiểu của display action. NavigationAction là một đường dẫn kết nối tới một đích, trên biểu đồ hoạt động thu thập các navigationActions và chuyển sang Association trên biểu đồ Navigation. Trong đó, nếu activity có nhiền hơn 1 navigationAction, tạo association với nguồn là Menu tương ứng. Nếu activity chỉ có 1 navigationAction, tạo association với nguồn là Class tương ứng với activity này trên biểu đồ Navigation.
ActivityParameterNode gồm có tên tham số, kiểu tham số được hiển thị bên dưới tên hoạt động trên biểu đồ hoạt động để tạo phương thức và danh sách tham số tương ứng cho process class.
Central Buffer Node: Là nút đối tượng để quản lý luồng xử lý từ nhiều nguồn và đích, được biểu diễn trong biểu đồ hoạt động. Nó hoạt động như một bộ đệm cho nhiều luồng vào và luồng ra từ các nút đối tượng khác.
Thuộc tính owner của NavigationAction và CentralBufferNode được thêm vào để dễ dàng truy vấn biểu đồ activity chứa đối tượng NavigationAction hoặc CentralBufferNode đang được gọi trong quy tắc chuyển đổi.
2.4.1.2 Siêu mô hình: content, navigation, process, presentation
Trên cơ sở các siêu mô hình đã được đề xuất bởi UWE. Tác giả đề xuất các siêu mô hình cụ thể cho bài toán music portal, sau khi đã loại bỏ những thành phần không thực sự cần thiết. Các siêu mô hình đề xuất cho bài toán music portal cụ thể như sau:
Siêu mô hình nội dung được thể hiện trong Hình 2.17, cung cấp định nghĩa về tất cả các thành phần của nội dung ứng dụng web như các thông tin về các lớp, các thuộc tính Nó mô tả cấu trúc và quan hệ giữa các thành phần tạo nên ứng dụng web. Các thành phần UML thông thường được sử dụng cho việc mô hình hoá nội dung tương tự như mô hình hóa các ứng dụng không phải là Web.
Content Metamodel
Siêu mô hình điều hướng được biểu diễn trong Hình 2.18, cung cấp các metaclass cụ thể cho miền web để xác định mô hình điều hướng như: NavigationClass và ProcessClass, ngoài ra còn có các liên kết, menu ... Siêu mô hình điều hướng của một ứng dụng Web mô tả cấu trúc thông tin tĩnh của hệ thống, mà người dùng có thể tương tác để chuyển đổi giữa các trang, các danh mục nội dung của trang Web.
Navigation Metamodel
Siêu mô hình xử lý mô tả chi tiết quá trình xử lý của ứng dụng web. Các thành phần trong siêu mô hình xử lý đại diện cho các khía cạnh động của ứng dụng Web, được sử dụng để mô hình hóa mô hình xử lý của ứng dụng web như mô tả trong Hình 2.19. 
Process Metamodel
Siêu mô hình trình bày xác định các yếu tố mô hình hóa cần thiết để chỉ định bố cục cho các mô hình quy trình và điều hướng cơ bản. Lớp trình bày là một lớp đặc biệt đại diện cho một trang Web hoặc một phần của trang web. Nó bao gồm các thành phần giao diện người dùng và các lớp trình bày khác. UIElements là các lớp đại diện cho yếu tố giao diện người dùng trong một trang web. Siêu mô hình trình bày được mô tả trong hình sau:
Presentation Metamodel
2.4.2. Các quy tắc ATL 
Phương pháp đề xuất sử dụng hai thành phần cơ bản của mô hình yêu cầu là biểu đồ Usecase và các biểu đồ hoạt động làm đầu vào cho các quy tắc chuyển đổi ATL.
Tổng quan phương pháp đề xuất
Hình 2.21 xác định phương pháp chuyển đổi thành các mô hình đích tuân thủ metamodel PIM, từ mô hình nguồn là mô hình yêu cầu phù hợp với metamodel CIM. Việc chuyển đổi được mô tả bằng các quy tắc phù hợp với metamodel ATL. Các mô hình đích thu được dựa trên metamodel CIM và PIM. Tuy nhiên, các metamodel CIM, PIM và ATL tuân thủ MOF (đặc tả ngôn ngữ metamodel). Mô hình yêu cầu bao gồm 2 thành phần cơ bản đó là các Usecase và các biểu đồ hoạt động tương ứng. Usecase mô tả sự tương tác đặc trưng giữa người dùng bên ngoài và hệ thống. Nó mô tả các yêu cầu đối với hệ thống. Biểu đồ hoạt động biểu diễn chính xác hơn các khía cạnh của ứng dụng, gồm có một tập khuôn mẫu (stereotypes) và các giá trị được gán nhãn (tag value). Nó có thể được sử dụng để mô tả chi tiết cho các yêu cầu quy trình nghiệp vụ trong hệ thống đã được mô tả sơ lược trong biểu đồ Usecase (bảng 2.3). Các thành phần tạo nên Usecase và biểu đồ hoạt động được mô tả trong hình 2.15, hình 2.16.
Các khuôn mẫu