Nghiên cứu xây dựng phương pháp chuyển đổi mô hình tích hợp ràng buộc trong phát triển ứng dụng web hướng mô hình theo kỹ thuật uwe

Tuy nhiên phương pháp phát triển ứng dụng Web hướng mô hình theo kỹ thuật UWE bằng việc mô hình hóa tất cả các mô hình trong UWE tồn tại một số nhược điểm sau: Thứ nhất: Việc mô hình hóa

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

PGS.TS Huỳnh Quyết Thắng

LỜI CAM ĐOAN

Tôi – Trần Quốc Khánh – cam kết luận văn là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của PGS.TS Huỳnh Quyết Thắng

Các kết quả nêu trong luận văn là trung thực, không phải là sao chép toàn văn của bất kỳ công trình nào khác

Hà Nội, ngày tháng 4 năm 2018

Học viên

Trần Quốc Khánh

LỜI CAM ĐOAN 2

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ 5

DANH MỤC HÌNH 6

DANH MỤC BẢNG 8

MỞ ĐẦU 10

1 Mục đích nghiên cứu của luận văn 11

2 Nội dung của luận văn 11

3 Các đóng góp khoa học của luận văn 12

Chương 1: Tổng quan về kỹ thuật UWE và ngôn ngữ ràng buộc OCL 13

1.1 Kiến trúc hướng mô hình 13

1.1.2 Giới thiệu 13

1.1.2 Các kỹ thuật Web hướng mô hình 13

1.2 Kỹ thuật UWE 15

1.2.1 Mô hình yêu cầu yêu cầu 18

1.2.2 Mô hình nội dung 18

1.2.3 Mô hình điều hướng 19

1.2.4 Mô hình xử lý 19

1.2.5 Mô hình trình bày 20

1.2.6 Mô hình MVC và các thành phần tương ứng trong UWE 20

1.3 Ngôn ngữ ràng buộc OCL 23

1.3.1 Khái niệm OCL 23

1.3.2 Cú pháp OCL 24

1.4 Vấn đề về xây dựng các bộ quy tắc chuyển đổi mô hình và ràng buộc OCL và nhiệm vụ trong luận văn 25

1.5 Tiểu kết chương 31

Chương 2: Xây dựng bộ quy tắc chuyển đổi mô hình trong UWE 32

2.1 Giới thiệu phương pháp chuyển đổi mô hình trong UWE 32

2.1.1 Quy tắc đã có của chuyển đổi mô hình xử lý 32

2.1.2 Quy tắc đã có của chuyển đổi mô hình trình bày 32

2.2 Hoàn thiện các quy tắc chuyển đổi từ mô hình yêu cầu sang mô hình xử lý 33

2.2.1 Quy tắc chuyển đổi U2P 34

2.2.3 Quy tắc chuyển đổi S2P 36

2.2.3 Quy tắc chuyển đổi U2U 38

2.2.4 Quy tắc chuyển đổi S2S 39

2.3.1 Quy tắc chuyển đổi D2G 42

2.3.2 Quy tắc chuyển đổi P2E 43

2.4 Tiểu kết chương 44

Chương 3: Tích hợp OCL 46

3.1 Giới thiệu phương pháp 46

3.1.1 Tích hợp OCL 46

3.1.2 Chuyển đổi OCL 47

3.2 Tích hợp và chuyển đổi OCL từ mô hình yêu cầu sang mô hình xử lý 47

3.2.1 Chuyển đổi các ràng buộc bất biến 48

3.2.2 Chuyển đồi các ràng buộc tiền điều kiện- hậu điều kiện 50

3.3 Tích hợp và chuyển đổi ràng buộc bất biến từ mô hình yêu cầu sang mô hình trình bày 52

3.4 Tiểu kết chương 53

Chương 4: Xây dựng công cụ MTO-Plugin và thử nghiệm 54

4.1 Xây dựng MTO-Plugin 54

4.2 Thử nghiệm và đánh giá 57

4.2.1 Chuyển đổi sang mô hình trình bày 61

4.2.2 Chuyển đổi sang mô hình xử lý 66

4.3 Tiểu kết chương 74

KẾT LUẬN 75

DANH MỤC THAM KHẢO 77

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ

Từ viết tắt, thuật ngữ Từ viết đầy đủ

MDSD Model Driven Software Development

MDWE Model Driven Web Enginnering

UWE Uml-based Web Engineering

WebSA Web Software Architecture

MDA Model Driven Architecture

CIM Computation Independent Model

PIM Platform Independent Model

PSM Platform Specific Model

UML Unified Modeling Language

MOF Query View Transformation

MVC Model View Controller

CSS Cascading Style Sheets

XML eXtensible Markup Language

XSLT eXtensible Stylesheet Language Transformation

DTD Document Type Definition

OCL Object Constraints Language

HTML Hypertext Markup Language

OMG Object Management Group

CWM Common Warehouse Metamodel

MDE Model Driven Engineering

ISM Impl Specific Model

MDD Model Driven Development

ALT Atlas Transformation Language

QVT Query/Views/Transformation

OOHDM Object Oriented Hypermedia Design Method

OOHDMA Object Oriented Hypermedia Design Method Approach W2000 (HDM) Hypertext Design Model

DANH MỤC HÌNH

Hình 1.1 Cấu trúc MDA cho kỹ thuật Web [2,13] 14

Hình 1.2 UWE metamodel [6] 16

Hình 1.3 UWE profile cho mô hình yêu cầu [6,16] 18

Hình 1.4 UWE profile cho mô hình nội dung [6,16] 19

Hình 1.5 UWE profile cho mô hình điều hướng [6, 16] 20

Hình 1.6 UWE profile cho mô hình xử lý [6, 16] 21

Hình 1.7 UWE profile cho mô hình trình bày [6,16] 22

Hình 1.8 Mô hình MVC trong Web [12] 22

Hình 1.9 Mối liên hệ giữa các mô hình trong UWE với mô hình MVC [3] 23

Hình 1.10 Tổng quan về chuyển đổi mô hình của ActionUWE 27

Hình 1.11 Chuyển đổi từ CIM tới PIM và từ PIM sang PIM trong UWE [5] 28

Hình 1.12 Phương pháp chuyển đổi mô hình 28

Hình 1.13 Các quy tắc chuyển đổi mô hình yêu cầu sang mô hình nội dung [3] 29

Hình 1.14 Các quy tắc chuyển đổi mô hình yêu cầu sang mô hình điều hướng [3] 29

Hình 1.15 Các quy tắc chuyển đổi đã có sang mô hình xử lý [3] 30

Hình 1.16 Các quy tắc chuyển đổi đã có sang mô hình trình bày [3] 30

Hình 2.1 Biểu đồ diễn tiến chuyển đổi quy tắc U2P 35

Hình 2.2 Biểu đồ diễn tiến chuyển đổi quy tắc U2P 36

Hình 2.3 Biểu đồ diễn tiến chuyển đổi quy tắc S2P 37

Hình 2.4 Biểu đồ diễn tiến chuyển đổi quy tắc S2P 38

Hình 2.5 Biểu đồ diễn tiến chuyển đổi quy tắc U2U 39

Hình 2.6 Biễu đồ diễn tiến của quy tắc S2S 40

Hình 2.7 Biểu đồ diễn tiến chuyển đổi quy tắc D2G 43

Hình 2.8 Biểu đồ diễn tiến xử lý cho quy tắc P2E 45

Hình 3.1 Giao diện HTML chuyển đổi từ mô hình tích hợp OCL 46

Hình 3.2 Chuyển đổi mô hình và chuyển đổi OCL 47

Hình 3.3 Chuyển đổi mô hình và mã nguồn tích hợp ràng buộc OCL 48

Hình 3.4 Biểu đồ diễn tiến chuyển đổi bất biến trong mô hình xử lý 49

Hình 3.5 Biểu đồ chuyển đổi tiền điều kiện – hậu điều kiện mô hình xử lý 51

Hình 3.6 Biểu đồ diễn tiến chuyển đổi ràng buộc bất biên mô hình trình bày 53

Hình 4.1 Kiến trúc MagicDraw và MTO-Plugin 55

Hình 4.3 Cơ chế khởi tạo và chạy plugin của Magic Draw 56

Hình 4.4 Giao diện công cụ MTO-Plugin 57

Hình 4.5 Sơ đồ Usecase của AddressBook 57

Hình 4.6 Activity diagram cho Create Contact 59

Hình 4.7 Activity diagram cho Update Contact 60

Hình 4.8 Activity diagram Search Contact 61

Hình 4.9 Activity diagram Delete Contact 61

Hình 4.10 Kết quả chuyển đổi Quy tắc D2G 62

Hình 4.11 Kết quả chuyển đổi quy tắc P2E 62

Hình 4.12 Kết quả chuyển đổi ràng buộc bất biến mô hình trình bày 63

Hình 4.13 Kết quả chuyển đổi mô hình trình bày ban đầu 63

Hình 4.14 Kết quả chuyển đổi mô hình trình bày sau khi bổ sung các quy tắc 64

Hình 4.15 Trang Home khi mô hình hóa bằng tay 65

Hình 4.16 CreateContact, SearchContact khi mô hình hóa bằng tay 66

Hình 4.18 Kết quả chuyển đổi Quy tắc S2P 67

Hình 4.19 Kết quả chuyển đổi Quy tắc U2U 68

Hình 4.20 Kết quả chuyển đổi Quy tắc S2S 68

Hình 4.21 Kết quả chuyển đổi các ràng buộc bất biến và tiền điều kiện- hậu điều kiện mô hình xử lý 69

Hình 4.22 Mô hình lớp xử lý ban đầu 69

Hình 4.23 Mô hình lớp xử lý được chuyển đổi với quy tắc bổ sung 70

Hình 4.24 Chuyển đổi sang mô hình luồng xử lý ban đầu 70

Hình 4.25 Mô hình luồng xử lý sau khi bổ sung các quy tắc 71

Hình 4.26 Mô hình lớp xử lý mô hình hóa bằng tay 72

Hình 4.27 Mô hình luồng xử lý mô hình hóa bằng tay 73

DANH MỤC BẢNG

Bảng 1 So sánh các kỹ thuật Web hướng mô hình [2,13] 15

Bảng 2 Các thành phần UWE stereo type [6,16] 17

Bảng 3 Các thành phần tương ứng DisplayAction type và Prentation element 42

Bảng 4 Các thành phần tương ứng với Pin type và giao diện 44

Bảng 5 Các pin trong create và update contact diagram 58

Bảng 6 Các ràng buộc OCL được tích hợp trong activity diagram 58

LỜI CẢM ƠN

Để có thể hoàn thành luận văn tốt nghiệp này, em xin chân thành cảm ơn thầy hướng dẫn luận văn tốt nghiệp, PGS.TS Huỳnh Quyết Thắng, Bộ môn Công nghệ phần mềm, Trường đại học Bách Khoa Hà Nội Thầy đã nhiệt tình hướng dẫn, truyền đạt những kiến thức cần thiết và định hướng cho em trong quá trình thực hiện đề tài

Em xin chân thành cảm ơn sự giúp đỡ quý báu của anh Trần Đình Diễn, nghiên cứu sinh tại Bộ môn Công nghệ phần mềm, trường đại học Bách Khoa Hà Nội

Em xin chân thành cảm ơn các thầy cô giáo ở Bộ môn Công nghệ phần mềm, trường Đại học Bách Khoa Hà Nội

Dù đã cố gắng nhưng luận văn chắc chắn không tránh khỏi thiếu sót, em rất mong nhận được ý kiến đóng góp của các thầy cô

Em xin chân thành cảm ơn!

MỞ ĐẦU

Phương pháp phát triển phần mềm hướng mô hình là quá trình phát triển tập trung vào mô hình hóa hệ thống UML và chuyển đổi các mô hình ngữ nghĩa mức cao xuống các mô hình cụ thể và từ đó xuống mã nguồn Nó giúp cho việc phát triển các ứng dụng nhanh chóng và hiệu quả hơn Ứng dụng Web là một trong những ứng dụng phổ biến,

nó cũng có những đặc trưng riêng Chính vì thế để áp dụng được phương pháp phát triển phần mềm hướng mô hình vào xây dựng ứng dụng Web đòi hỏi những thành phần mới được bổ sung vào UML

Kỹ thuật Web hướng mô hình UWE đã được phát triển để đáp ứng yêu cầu trên Không chỉ đáp ứng những quy định của kiến trúc MDA, UWE còn đưa ra những thành phần đặc thù của ứng dụng Web

Tuy nhiên phương pháp phát triển ứng dụng Web hướng mô hình theo kỹ thuật UWE bằng việc mô hình hóa tất cả các mô hình trong UWE tồn tại một số nhược điểm sau:

Thứ nhất: Việc mô hình hóa cả 5 mô hình sẽ làm cho việc phát triển ứng dụng Web tốn thời gian và chi phí;

Thứ hai: Với các ứng dụng Web thường bao gồm nhiều thành phần và các thành phần có thể sẽ phụ thuộc vào các nền tảng công nghệ khác nhau, do đó việc đảm bảo tính thống nhất giữa các mô hình cũng như cần cập nhật đồng bộ giữa các mô hình khi

có thay đổi là rất khó khăn

Bằng việc xây dựng bộ quy tắc chuyển đổi mô hình, từ mô hình yêu cầu sẽ chuyển đổi sang các mô hình khác như mô hình nội dung, mô hình điều hướng, mô hình xử lý,

mô hình trình bày một cách tự động Dựa trên các mô hình được chuyển đổi, có thể sinh mã nguồn tự động cho ứng dụng Web Do đó nó giúp tiết kiệm thời gian, chi phí

và đảm bảo tính thống nhất giữa các mô hình trong UWE

Ngoài ra, đặc tính tương tác cao với người sử dụng của ứng dụng Web đòi hỏi các

dữ liệu được đưa vào hệ thống phải được ràng buộc và kiểm tra hợp lệ trước khi xử lý nghiệp vụ

Do vậy, em chọn đề tài “Nghiên cứu xây dựng phương pháp chuyển đổi mô hình tích hợp ràng buộc trong phát triển ứng dụng Web hướng mô hình theo kỹ thuật UWE” để

giải quyết vấn đề nêu trên

1 Mục đích nghiên cứu của luận văn

Mục đích của luận văn là nghiên cứu xây dựng phương pháp chuyển đổi mô hình tích hợp ràng buộc trong phát triển ứng dụng Web hướng mô hình theo kỹ thuật UWE nhằm chuyển đổi tự động từ mô hình yêu cầu sang các mô hình mô hình nội dung, mô hình điều hướng, mô hình xử lý, mô hình trình bày giúp đảm bảo tính thống nhất giữa các mô hình, đồng thời tiết kiệm thời gian và chi phí cho ứng dụng Web, giúp phát triển ứng dụng Web đơn giản, linh hoạt, nhanh chóng và hiệu quả hơn

2 Nội dung của luận văn

Nội dung luận văn bao gồm 4 chương:

Chương 1: Tổng quan về kỹ thuật UWE và ngôn ngữ ràng buộc OCL Chương này trình bày về kiến trúc hướng mô hình, các kỹ thuật Web hướng mô hình phổ biến, lý do chọn UWE, các mô hình của UWE và mối tương quan giữa các mô hình UWE với mô hình MVC, lý thuyết về ràng buộc OCL Đồng thời chương 1 cũng làm rõ các nghiên cứu hiện có của chuyển đổi mô hình UWE, các quy tắc đã có và vấn đề hoàn thiện bộ quy tắc chuyển đổi mô hình và tích hợp chuyển đổi ràng buộc OCL cho mô hình trình bày và mô hình xử lý

Chương 2: Xây dựng bộ quy tắc chuyển đổi mô hình trong UWE Chương này trình bày các quy tắc đã có của chuyển đổi sang mô hình trình bày và mô hình xử lý Cơ sở

để đề xuất bổ sung một số quy tắc mới Trình bày các bước xử lý để thực hiện cho mỗi quy tắc và biễu đồ diễn tiến cài đặt mã nguồn tương ứng

Chương 3: Tích hợp và chuyển đổi OCL Chương này giới thiệu về phương pháp tích hợp và chuyển đổi ràng buộc OCL, sau đó mô tả chi tiết về các bước thực hiện và cài đặt mã nguồn tương ứng cho ràng buộc trong mô hình xử lý và trình bày

Chương 4: Xây dựng công cụ MTO-Plugin Chương này trình bày về kiến trúc và cơ chế hoạt động của một plugin trong công MagicDraw Sau đó áp dụng công cụ MTO-Plugin vào bài toán điển hình, so sánh và đánh giá với kết quả ban đầu và mô hình hóa bằng tay

3 Các đóng góp khoa học của luận văn

Luận văn có những đóng góp mới như sau:

Thứ nhất: Xây dựng thêm được một số quy tắc mới, để hoàn thiện bộ quy tắc chuyển đổi mô hình, nhằm cải thiện kết quả chuyển đổi

Thứ hai: Đưa ra phương pháp tích hợp ràng buộc OCL vào mô hình UWE, sau đó chuyển đổi nhằm đồng bộ giữa các mô hình, làm giàu thông tin cho các mô hình, cải thiện kết quả trong quá trình sinh mã

Thứ ba: Xây dựng công cụ MTO-Plugin minh họa các kỹ thuật trên để thử nghiệm

và đánh giá

Chương 1: Tổng quan về kỹ thuật UWE và ngôn ngữ ràng buộc OCL 1.1 Kiến trúc hướng mô hình

1.1.2 Giới thiệu

MDA là một hướng tiếp cận vấn đề MDE do tổ chức OMG đề xuất MDA bắt đầu với ý tưởng tách đặc điểm kỹ thuật của hệ thống ra khỏi nền tảng hoạt động của hệ thống [1,9,13] MDA cung cấp một cách tiếp cận và công cụ nhằm mục đích [1]:

có thể chạy được PSM có thể sử dụng các ngôn ngữ đặc tả chuyên biệt hoặc các ngôn ngữ phổ biến như: Java, C#, C++ [1, 13]

1.1.2 Các kỹ thuật Web hướng mô hình

Với những ưu điểm của MDA và những đặc điểm về tính đa dạng về công nghệ cũng như ngôn ngữ của phát triển các ứng dụng web thì kỹ thuật MDWE được áp dụng vào phát triển các ứng dụng Web nhằm tạo ra các ứng dụng web nhanh chóng linh hoạt

và chất lượng Trong kỹ thuật hướng mô hình bao gồm 4 mức [1,2,14]:

 Mô hình CIM thể hiện mô hình hóa các chức năng của hệ thống

 Mô hình PIM là một khung nhìn của hệ thống từ điểm nhìn độc lập nền tảng Đó

là một mô hình của hệ thống không chứa thông tin cụ thể về nền tảng, hay công nghệ được dùng để thực hiện nó

 Mô hình PSM là một khung nhìn của một hệ thống từ điểm nhìn nền tảng cụ thể Đó là một mô hình của hệ thống bao gồm thông tin về công nghệ cụ thể được dùng để thực hiện nó trong một nền tảng cụ thể ví dụ Java hoặc NET

Trong MDA, sự chuyển đổi giữa các mức được định nghĩa: Chuyển đổi CIM sang PIM, PIM sang PSM và từ PSM sang mã nguồn (xem Hình 1.1)

Hình 1.1 Cấu trúc MDA cho kỹ thuật Web [2,13]

Một số kỹ thuật Web hướng mô hình điển hình:

OOHDMDA: OOHDM được đề xuất năm 1995 Ý tưởng của phương pháp này là

chia việc thiết kế một hệ thống Web thành 3 mô hình: mô hình khái niệm, mô hình điều hướng và mô hình giao diện trừu tượng [1,2] OOHDMDA được phát triển dựa trên OOHDM Bắt đầu bằng mô hình PIM được thiết kế trong OOHDM, để tạo ra các PSM OOHDMDA cung cấp phương pháp thiết kế ứng dụng Web bằng cách kết hợp UML

và các mô hình được định nghĩa trong OOHDM

W2000 (HDM): W2000 dựa trên nguyên lý hướng đối tượng Phương pháp này đưa

ra một vòng đời cho phát triển một ứng dụng Web [2] W2000 bắt đầu bằng bước phân

và mở rộng một số mô hình UML như là biểu đồ lớp và biểu đồ trạng thái Cuối cùng

sử dụng các biểu đồ tuần tự để mô tả chức năng của hệ thống

WebML: WebML là một phương pháp thiết kế Web thế hệ thứ ba dựa trên MDA,

dựa trên mô hình quan hệ thực thể [2,10, 13] Trong WebML bổ sung, xây dựng tập ký pháp để thiết kế khái niệm của các trang Web phức tạp Phương pháp này sử dụng ký hiệu (notation) riêng và không sử dụng meta-model tuân thủ MOF, mà sử dụng DTD

để lưu các mô hình nội dung và điều hướng, ví dụ định nghĩa dạng ngữ pháp cho cấu trúc của tài liệu XML DTD không có tính trừu tượng như MOF và thiếu ký hiệu dễ hiểu Ngôn ngữ chuyển đổi XSLT được sử dụng cho việc chuyển đổi mô hình sang mã nguồn (hỗ trợ Java và JSP) XSLT không phù hợp với những chuyển đổi phức tạp, khó phát triển chương trình và dễ bị lỗi [13]

UWE: UWE là phương pháp hướng đối tượng dựa trên ngôn ngữ mô hình hóa

UML, là một trong những kỹ thuật đầu tiên phát triển theo kỹ thuật hướng mô hình và được sử dụng nhiều nhất trong kỹ thuật Web hướng mô hình [1, 2, 13] UWE là một kỹ thuật phát triển ứng dụng Web hoàn chỉnh nhưng chủ yếu tập trung vào giai đoạn phân tích và thiết kế Một trong những ưu điểm quan trọng của UWE là tất cả các mô hình của nó đều là phần mở rộng của UML UWE sử dụng ký pháp đồ họa hoàn toàn dựa trên UML Nó cho phép sử dụng các công cụ dựa trên UML và giảm thiểu thời gian nghiên cứu của các nhà phát triển Web, những người đã quen thuộc với UML Kỹ thuật Web hướng mô hình UWE đáp ứng đầy đủ các yêu cầu của MDA cho việc phát triển ứng dụng Web bao gồm mô hình CIM, PIM, PSM và kỹ thuật chuyển đổi từ mô hình

CIM sang PIM, từ mô hình PIM sang PSM

(domain-một meta-model Metamodel UWE được tách theo cấu trúc gói như trong hình 3 Trong đó, gói Adaptivity có mục đích cho phép ngôn ngữ có thể mở rộng [6, 16] Gói Core được chia thành các gói nhỏ hơn (còn được gọi là các mô hình trong UWE), bao gồm: (1) Requirements (Yêu cầu); (2) Content (Nội dung); (3) Navigation (Điều hướng); (4) Process (Xử lý); (5) Presentation (Trình bày)

Hình 1.2 UWE metamodel [6]

Bảng 2 Các thành phần UWE stereo type [6,16]

UWE metamodel được định nghĩa như một phần mở rộng cho UML 2.0 UML profile tương thích với hầu hết công cụ UML UWE metamodel định nghĩa một số stereotype mở rộng cho UML dựa trên những đặc trưng riêng của các ứng dụng Web

Mô hình yêu cầu sẽ bao gồm 2 thành phần cơ bản đó là các Usecase và các biểu đồ activity diagram 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ó thể hiện nghiệp vụ của hệ thống đối với bên ngoài, trong một hoàn cảnh nhất định, xét từ quan điểm của người sử dụng Biểu đồ Usercase mô tả các yêu cầu đối với hệ thống, có nghĩa là những gì hệ thống phải làm chứ không phải mô tả

hệ thống làm như thế nào Tập hợp tất cả Usecase của hệ thống sẽ mô tả tất cả các trường hợp mà hệ thống có thể được sử dụng

Activity diagram là bản vẽ tập trung vào mô tả các hoạt động, luồng xử lý bên trong

trong hệ thống đã được mô tả sơ lược trong biểu đồ Usecase Các luồng của một chức năng hoặc các hoạt động của một đối tượng Các thành phần tạo nên Usecase và activity diagram được mô tả trong Hình 1.3

1.2.1 Mô hình yêu cầu yêu cầu

Hình 1.3 UWE profile cho mô hình yêu cầu [6,16]

1.2.2 Mô hình nội dung

Mô hình nội dung như thể hiện trong Hình 1.4, mô tả cấu trúc và quan hệ giữa các thành phần tạo nên phần mềm Mô hình hoá nội dung không đòi hỏi bất kỳ cấu trúc bổ

Hình 1.4 UWE profile cho mô hình nội dung [6,16]

1.2.3 Mô hình điều hướng

Mô hình điều hướng mô tả luồng chuyển hướng tương ứng với hành động người sử dụng trong ứng dụng Web (Hình 1.5) Nó được thể hiện bằng biểu đồ lớp và bổ sung các khuôn mẫu của UWE đại diện cho các nút, các liên kết, menu và các index Mô hình điều hướng của một ứng dụng Web như trong Hình 1.5, thể hiện 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

1.2.4 Mô hình xử lý

Mô hình xử lý sẽ thể hiện chi tiết quá trình xử lý được thực hiện như thế nào, thể hiện trong Hình 1.6 Mô hình xử lý đại diện cho các khía cạnh động của ứng dụng Web Mô hình xử lý cung cấp các phần tử mô hình cho việc tích hợp quy trình vào một

mô hình ứng dụng Web Gói xử lý có thể được chia thành ba nhiệm vụ [6]: (1) Tích hợp các quy trình nghiệp vụ vào mô hình điều hướng; (2) Định nghĩa một giao diện người dùng để hỗ trợ các xử lý (3) Định nghĩa hành vi

Hình 1.5 UWE profile cho mô hình điều hướng [6, 16]

1.2.5 Mô hình trình bày

Mô hình trình bày như thể hiện trong Hình 1.7, mô tả một cái nhìn trừu tượng về giao diện người dùng của ứng dụng Web Mô hình trình bày định nghĩa nhiều khuôn mẫu cho các loại thành phần khác nhau (ví dụ như khung nhập văn bản, các nút bấm,

…) nhưng không cung cấp chi tiết cụ thể như kiểu CSS hoặc các yếu tố HTML [13]

1.2.6 Mô hình MVC và các thành phần tương ứng trong UWE

Mô hình MVC là một kiến trúc phần mềm hay mô hình thiết kế được sử dụng trong

kỹ thuật phần mềm Nó giúp cho người phát triển tách ứng dụng của 3 thành phần khác nhau Model, View và Controller Mỗi thành phần có một nhiệm vụ riêng biệt và độc lập với các thành phần khác Giúp phát triển các ứng dụng nói chung và ứng dụng Web nói riêng nhanh chóng, hiệu quả, dễ dàng nâng cấp hay bảo trì Quá trình xử lý dữ liệu trong mô hình MVC được mô tả trong Hình 1.8 [13]

Hình 1.6 UWE profile cho mô hình xử lý [6, 16]

Hình 1.7 UWE profile cho mô hình trình bày [6,16]

Hình 1.8 Mô hình MVC trong Web [12]

Nhiệm vụ của các thành phần như sau [12]:

Model: Có nhiệm vụ thao tác với cơ sở dữ liệu, nghĩa là nó sẽ chứa tất cả các hàm, các phương thức truy vấn trực tiếp với dữ liệu Controller sẽ thông qua các hàm, phương thức đó để lấy dữ liệu rồi gửi qua view

View: Có nhiệm vụ tiếp nhận dữ liệu từ controller và hiển thị nội dung sang các đoạn mã HTM, còn gọi là thành phần giao diện

Controller: Đóng vài trò trung gian giữa model và view Nó có nhiệm vụ tiếp nhận yêu cầu từ client sau đó xử lý các yêu cầu đó, gọi các model tương ứng và gửi dữ liệu qua view tương ứng rồi trả kết quả về cho client

Các mô hình trong UWE cũng tương ứng với các thành phần trong mô hình MVC

Mô hình nội dung tương ứng với thành phần model Mô hình trình bày tương ứng với thành phần view Mô hình điều hướng và mô hình xử lý tương ứng với thành phần controller [3,6]

Hình 1.9 Mối liên hệ giữa các mô hình trong UWE với mô hình MVC [3]

1.3 Ngôn ngữ ràng buộc OCL

1.3.1 Khái niệm OCL

Trong quá trình phát triển phần mềm người ta nhận ra rằng, chỉ với hệ thống ký hiệu trực quan trong UML không thể hiện được hết các khía cạnh của hệ thống phần mềm Chính vì thế, OCL được xây dựng và phát triển với mục đích bổ sung cho các đặc tả

UML trở nên rõ ràng và chính xác hơn Và OCL trở thành chuẩn ngôn ngữ đặc tả cho các biểu đồ trong UML trong thực tế [8,10,11]

Khi một biểu thức OCL được đánh giá, nó chỉ đơn giản là trả về một giá trị Nó không thể thay đổi bất cứ điều gì trong mô hình Điều này có nghĩa là trạng thái của hệ thống sẽ không bao giờ thay đổi vì sự đánh giá của một biểu thức OCL, mặc dù một biểu OCL có thể được sử dụng để xác định một sự thay đổi trạng thái OCL có thể được sử dụng vào nhiều mục đích khác nhau: Như ngôn ngữ truy vấn; Để chỉ định bất biến cho lớp và kiểu trong mô hình lớp; Để xác định loại bất biến cho khuôn mẫu; Để

mô tả trước và sau điều kiện về hoạt động và phương pháp; Để mô tả Guards; Để xác định mục tiêu (tập hợp) cho các thông điệp và hành động; Để xác định những ràng buộc về hoạt động; Để xác định quy định dẫn xuất cho các thuộc tính cho bất kỳ biểu hiện qua một mô hình UML

1.3.2 Cú pháp OCL

Khai báo ngữ cảnh: OCL là một ngôn ngữ hình thức, chúng được biểu diễn dưới

dạng biểu thức Biểu thức OCL dùng để đặc tả cho UML luôn luôn phải gắn liền với một đối tượng trong mô hình UML Do vậy trước khi tiến hành biểu diễn biểu thức OCL chúng ta phải khai báo ngữ cảnh mà biểu thức OCL tham gia Cú pháp khai báo một ngữ cảnh: Khai báo một ngữ cảnh bắt đầu bằng từ khóa context và tiếp đến là tên ngữ cảnh Ví dụ khai báo ngữ cảnh có tên là Person: context Person từ khóa seft biểu thức OCL luôn được đặt trong một ngữ cảnh cụ thể, và để chỉ ra thể hiện của đối tượng

trong ngữ cảnh đó chúng ta sử dụng từ khóa seft

Khai báo một bất biến – invariant: Một ràng buộc bất biến là một ràng buộc được

liên kết tới một lớp cụ thể trong một ngữ cảnh cụ thể Mục đích của một ràng buộc bất biến là chỉ rõ sự bất biến tại một khía cạnh nào đó của lớp Một ràng buộc bất biến chứa một biểu thức OCL Biểu thức này phải đúng cho mọi thể hiện của phân loại lớp tại mọi thời điểm Chỉ khi một thể hiện thực thi một phép toán thì không cần đánh giá biểu thức này là đúng Cú pháp khai báo một bất biến: Khai báo một bất biến bắt đầu

với từ khóa inv, tiếp đến là tên của bất biến

Ví dụ: context Company khai báo ngữ cảnh có tên là Company

inv: seft numberOfEmployees > 50 Khai báo một bất biến

Ý nghĩa: Mọi thể hiện của đối tượng Company phải thỏa mãn ràng buộc

đối tượng Company, sử dụng toán tử “.” để chỉ tới thuộc tính numberOfEmployees của đối tượng Company

Tiền điều kiện và hậu điều kiện: Tiền điều kiện và hậu điều kiện là các ràng buộc

liên kết tới phương thức của một phân loại lớp Mục đích của tiền điều kiện là chỉ rõ điều kiện phải có trước khi phương thức thực thi Tiền điều kiện chứa một biểu thức OCL (trả về kết quả Boolean) Biểu thức OCL này phải được đánh giá là đúng bất cứ khi nào phương thức bắt đầu thực thi, nhưng việc đánh giá này chỉ áp dụng cho thể hiện thực thi phương thức Mục đích của hậu điều kiện là chỉ rõ điều kiện phải có sau khi thực thi phương thức Hậu điều kiện cũng được biểu diễn bằng một biểu thức OCL (trả về kết quả Boolean) Việc đánh giá biểu thức OCL tại thời điểm kết thúc thực thi phương thức Bên trong ràng buộc tiền điều kiện không sử dụng toán tử @pre nhưng bên trong ràng buộc hậu điều kiện có thể sử dụng @pre để tham chiếu tới giá trị của

tiền điều kiện

Cú pháp: context Typename::operationName(para1 : Type1, para2 : Type2, ) Trong đó pre: Khai báo các tiền điều kiện

post: Khai báo các hậu điều kiện

hoặc: context Typename :: operationName(para1 : Type1, para2 : Type2, )

pre preconditionName: Khai báo tiền điều kiện

Ví dụ: post postconditionName: Khai báo hậu điều kiện

context Job::increase( perCent : Integer )

pre: percent>0 và <=100

post: salary=salary@pre*(1+perCent/100) – hậu điều kiện giá trị salary

1.4 Vấn đề về xây dựng các bộ quy tắc chuyển đổi mô hình và ràng buộc OCL và nhiệm vụ trong luận văn

Kỹ thuật UWE mang lại những ưu điểm cho phát triển ứng dụng Web Các mô hình yêu cầu, điều hướng, trình bày, xử lý giúp mô hình tất cả các khía cạnh của một ứng dụng Web: giao diện, điều hướng, xử lý Người phát triển sẽ phân tích yêu cầu, sau đó

mô hình hóa các mô hình trong UWE một cách đầy đủ và chi tiết, sau đó các mô hình này có thể được sử dụng cho quá trình sinh mã nguồn cho ứng dụng [7]

Với cách tiếp cận này sẽ mang lại hiệu quả khắc phục được sự phụ thuộc vào nền tảng công nghệ của các ứng dụng Web, tuy nhiên việc phải mô tả đầy đủ và chi tiết tất

cả 5 mô hình trong UWE cũng có những hạn chế Do đó với phương pháp tiếp cận chuyển đổi mô hình của luận văn giúp giải quyết các hạn chế đó

 Người phát triển chỉ cần tập trung vào mô hình hóa mô hình yêu cầu, các mô hình nội dung, điều hướng, xử lý, trình bày sẽ được chuyển đổi một cách tự động, giúp tiết kiệm thời gian và chi phí phát triển

 Đảm bảo tính thống nhất giữa các mô hình, đặc biệt khi có thay đổi cần cập nhật

ở mô hình yêu cầu các mô hình khác sẽ được đồng bộ

 Các ứng dụng Web thường gồm nhiều thành phần, các thành phần có thể phụ thuộc vào một nền tảng công nghệ cụ thể khác nhau Với phương pháp chuyển đổi

mô hình, người phát triển sẽ tập trung vào mô tả các phần logic, xử lý nghiệp vụ của

hệ thống mà không cần quan tâm đến nền tảng công nghệ cụ thể

 Việc chuyển đổi mô hình sẽ tạo điều kiện cho chuyển đổi các thành phần được tích hợp ví dụ như chuyển đổi các ràng buộc một cách tự động

Trong [17], các tác giả đã tạo ra công cụ chuyển đổi có tên là ActionUWE ActionUWE thực hiện chuyển đổi các mô hình theo kỹ thuật UWE như sau:

Mô hình yêu cầu: xác định các yêu cầu cho một dự án

Mô hình nội dung: Chứa cấu trúc dữ liệu

Mô hình vai trò: Xác định thứ bậc, vai trò của người sử dụng trong các nhóm

người dùng sẽ được sử dụng và kiểm soát truy cập của người dùng

Mô hình quyền cơ bản: Mô tả chính sách an ninh dựa trên kiểm soát truy cập

Nó rằng buộc các yếu tố từ mô hình nội dung của UWE và từ mô hình người dùng Nó rằng buộc các phần tử từ mô hình nội dung và người dùng

Mô hình trình bày: Mô tả phần giao diện của ứng dụng Web

Mô hình trạng thái điều hướng: mô tả luồng điều hướng của ứng dụng và

chính sách kiểm soát truy cập liên quan đến điều hướng

Mô hình thành phần UML: Mô tả cấu trúc dữ liệu

Mô hình an ninh: Mô tả chính sách kiểm soát truy cập

Theo [17] chuyển đổi mô hình gồm 4 bước:

Bước 1: Ánh xạ cấu trúc dữ liệu và tạo một cửa sổ chính cho ứng dụng Web và chuyển đổi các menu được mô phỏng trong UWE

Bước 3: Chuyển đổi đổi thông tin trong mô hình điều hướng từ mô hình trạng thái điều hướng UWE sang mô hình ActionGUI

Bước 4: Ánh xạ tính năng bảo mật Vì ActionGUI và UWE sử dụng cách khác nhau

để nhóm các tính năng với các mô hình, mô hình ActionGUI chứa hầu hết các yếu tố được chuyển đổi

Hình 1.10 Tổng quan về chuyển đổi mô hình của ActionUWE Trong [5], Nora Koch đề xuất chuyển đổi được phân thành ba nhóm công việc: (1) Xây dựng mô hình thiết kế; (2) Tạo mô hình tích hợp (big picture) và (3) Chuyển đổi các mô hình thành mã nguồn phần mềm

 Xây dựng mô hình thiết kế: Bước chuyển đổi mô hình đầu tiên của quá trình

UWE bao gồm lập bản đồ mô hình yêu cầu của ứng dụng Web cho mô hình thiết kế Các mô hình thiết kế bao gồm: mô hình nội dung, định hướng, xử lý, trình bày, và

mô hình thích nghi Tác giả xây dựng quy tắc chuyển đổi là ánh xạ từ metamodel WebRE với metamodel UWE và các metamodels của UWE

 Tạo mô hình tích hợp: Mục tiêu của giai đoạn này trong quá trình MDD của

UWE là tạo ra một mô hình cho phép tạo ra các mô hình nền tảng (PSM) và xác nhận tính đúng đắn của mô hình bằng cách kiểm tra mô hình

Quá trình bao gồm hai bước tích hợp chính: thứ nhất là tích hợp các mô hình chức năng và phi chức năng; thứ hai liên quan đến quyết định thiết kế kiến trúc Với các quan điểm khác nhau, các mô hình thiết kế khác nhau đại diện cho ứng dụng Web Chúng được tích hợp vào một mô hình nền độc lập nền khác được goi là bức tranh toàn cảnh (big picture)

Hình 1.11 Chuyển đổi từ CIM tới PIM và từ PIM sang PIM trong UWE [5]

 Chuyển đổi các mô hình thành mã nguồn phần mềm: Để chuyển đổi mô

hình độc lập nền thành các mô hình nền tảng cụ thể cần có thêm thông tin về nền tảng công nghệ này Các ngôn ngữ chuyển đổi được sử dụng là ngôn ngữ ATL và QVT Tác giả cũng đề xuất để xây dựng một tập hợp các CIM, PIM và chuyển đổi

từ CIM sang PIM (Hình 1.11), từ PIM sang PSM, và từ PSM có thể chuyển thành

mã chương trình cụ thể thực thi hệ thống

Trong [3] đã tổng hợp các ngôn ngữ và kĩ thuật được dùng trong chuyển đổi giữa các mô hình của UWE Các tác giả đã xây dựng các quy tắc chuyển mô hình cụ thể như sau:

Chuyển đổi Requirement2Content:

Requirement2Content chuyển đổi từ mô hình yêu cầu sang mô hình nội dung một cách tự động, bằng việc áp dụng 2 quy tắc chuyển đổi sau đây

Hình 1.13 Các quy tắc chuyển đổi mô hình yêu cầu sang mô hình nội dung [3]

Chuyển đổi RequirementsAndContent2Navigation:

Mục tiêu của mô hình điều hướng là xác định khả năng chuyển hướng giữa các mục trong một trang Web hoặc chuyển từ trang này sang trang khác của ứng dựng Web Từ

mô hình yêu cầu và mô hình nội dung, các quy tắc sau đây sẽ chuyển đổi sang mô hình điều hướng một cách tự động [3]

Chuyển đổi sang mô hình xử lý:

Mô hình điều hướng của một ứng dụng Web thể hiện cấu trúc thông tin tĩnh mà người dùng hệ thống có thể truy cập Mặt khác, mô hình xử lý đại diện cho các khía cạnh động của một ứng dụng Web Giúp cung cấp đầy đủ thông tin cho phần Controller của ứng dụng Web

Hình 1.15 Các quy tắc chuyển đổi đã có sang mô hình xử lý [3]

Chuyển đổi sang mô hình trình bày

Với các quy tắc chuyển đổi được mô tả như Hình 1.11 công cụ MagicUWE đã chuyển đổi được giữa các mô hình trong UWE

Hình 1.16 Các quy tắc chuyển đổi đã có sang mô hình trình bày [3]

Trong các phương pháp và công cụ đã được mô tả ở trên, phương pháp chuyển đổi

mô hình được các tác giả nghiên cứu cùng với công cụ MagicUWE giúp chuyển đổi được một cách đầy đủ nhất các mô hình của UWE cho các ứng dụng Web Tuy nhiên, dựa trên những mô tả về các thành phần trong UWE profile [6], trong chuyển đổi sang

mô hình trình bày và mô hình xử lý Một số thành phần trong mô hình yêu cầu cần phải

Mô hình UML đơn thuần, chưa mô tả được đầy đủ về các ràng buộc của các dữ liệu, ràng buộc giữa các thành phần của mô hình đó Do đó một số nghiên cứu giúp tích hợp OCL vào mô hình UML Trong [10], các tác giả sử dụng OCL cho các ràng buộc về các khóa của cơ sở dữ liệu, các liên kết giữa các bảng dữ liệu, giúp kiểm tra dữ liệu trước khi cập nhật vào cơ sở dữ liệu, đảm bảo an toàn cho hệ thống Trong [4,11], các tác giả tích hợp OCL vào các lớp, sau đó kiểm tra các đối tượng được tạo ra từ lớp đó

có thõa mãn ràng buộc không Sau đó, đưa ra các thông báo tương ứng

Đối với ứng dụng Web, với đặc trưng tương tác cao với người sử dụng thông qua giao diện Người sử dụng sẽ nhập dữ liệu thông qua các form Do đó việc kiểm tra tính hợp lệ của dữ liệu là bắt buộc để đảm bảo tính đúng đắn và hiệu quả xử lý của ứng dụng Web Quá trình kiểm tra phải được xử lý ở cả mô hình giao diện, và mô hình xử

lý Kết hợp với phương pháp chuyển đổi mô hình, OCL sau khi được thêm vào các thành phần ở mô hình yêu cầu cũng được chuyển đổi và tích hợp tự động vào các mô hình khác như: mô hình xử lý, mô hình trình bày, đảm bảo tính thống nhất trong toàn

hệ thống và cung cấp thông tin cho quá trình sinh mã

Đề tài của luận văn “Nghiên cứu kỹ thuật kỹ thuật hướng mô hình UWE và ngôn ngữ ràng buộc OCL và áp dụng cho bài toán điển hình” có 3 nhiệm vụ cụ thể:

1) Hoàn thiện bộ quy tắc chuyển đổi mô hình và xây dựng bộ quy tắc tích hợp và chuyển đổi OCL: nội dung này sẽ được trình bày trong chương 2 của luận văn

2) Xây dựng công cụ chuyển đổi mô hình, tích hợp và chuyển đổi ràng buộc OCL: nội dung này sẽ được trình bày trong chương 3 của luận văn

3) Áp dụng công cụ đã xây dựng vào bài toán điển hình và đánh giá kết quả: nội dung này sẽ được trình bày trong chương 4 của luận văn

người dùng, đảm bảo các ứng dụng Web hoạt động hiệu quả và chính xác

Chương 2: Xây dựng bộ quy tắc chuyển đổi mô hình trong UWE

2.1 Giới thiệu phương pháp chuyển đổi mô hình trong UWE

2.1.1 Quy tắc đã có của chuyển đổi mô hình xử lý

Mô hình xử lý đại diện cho các khía cạnh động của một ứng dụng Web Giúp cung cấp đầy đủ thông tin tương ứng với thành phần process class được thể trong mô hình điều hướng

Trong tài liệu [3], tác giả K Andreas đã xây dựng một số quy tắc để chuyển đổi từ

mô hình yêu cầu mô hình nội dung và mô hình điều hướng sang mô hình xử lý như sau:

Trong mô hình lớp xử lý quy tắc sau đã được định nghĩa:

 Quy tắc ProcessingAndBrowsing2ProcessClass: Quy tắc này sẽ chuyển đổi các thành phần processing và browsing từ mô hình Usecase sang thành các process class Thể hiện cho các nghiệp vụ cần xử lý của hệ thống

Quá trình chuyển đổi sang luồng xử lý (workflow) thì ba quy tắc sau đây đã được định nghĩa:

 Quy tắc CreateProcessDataAndFlowForWebProcess

 Quy tắc CreateProcessDataAndFlowForSimpleProcess

 Quy tắc CreateProcessDataAndFlowForEdit

Ba quy tắc nêu sẽ tạo ra các luồng xử lý tương ứng cho các activity diagram

2.1.2 Quy tắc đã có của chuyển đổi mô hình trình bày

Tương tự như khi chuyển đổi từ mô hình yêu cầu sang mô hình xử lý Trong chuyển đổi từ mô hình yêu cầu, mô hình xử lý, mô hình điều hướng sang mô hình trình bày thì bốn quy tắc sau đã được áp dụng [3]

2.2 Hoàn thiện các quy tắc chuyển đổi từ mô hình yêu cầu sang mô hình xử lý

User action được sử dụng biểu đồ activity diagram để thể hiện cho yêu cầu người dùng nhập dữ liệu User action sẽ được liên kết với một process class để xác định dữ liệu gì được thay đổi và presentation class nào sẽ hiện thị chúng Luồng điều khiển của các activity sẽ được tiếp tục sau khi người sử dụng gửi yêu cầu Mỗi thuộc tính của process class sẽ nhận giá trị từ các phần tử tương ứng cùng tên trong mô hình giao diện Tương tự các thuộc tính của process class có thể được chuyển đổi từ các input pin của thành phần user action Những giá trị này có được sử dụng là giá trị khởi tạo mặc định cho các phần tử tương ứng trong mô hình giao diện [6] Do đó user action trong activity diagram sẽ được chuyển đổi thành process class trong mô hình lớp xử lý với quy tắc U2P

System action là thành phần đại diện cho xử lý bên trong hệ thống, xác định một bước của luồng xử lý trong quá trình xử lý dữ liệu của ứng dụng Web Dữ liệu có thể là

từ một user action nhập dữ liệu từ người sử dụng, hoặc cũng có thể từ một quá trình xử

lý của một system action trước đó Vì vậy system action trong activity diagram cũng cần phải được chuyển đổi sang process class trong mô hình lớp xử lý với quy tắc S2P,

để xử lý toàn bộ luồng dữ liệu trong ứng dụng Web

Quy tắc U2P: Quy tắc này chuyển đổi user action thành process class, đồng thời các pin của user action thành các thuộc tính của process class đó

Quy tắc S2P: Quy tắc này chuyển đổi system ation thành process class cùng với phương thức xử lý

Như đã phân tích ở trên, user action và system action trong mô hình activity diagram chịu trách nhiệm cho quá trình xử lý dữ liệu trong ứng dụng Web Trong khi đó mô hình luồng xử lý, thể hiện cho khía cạnh động của ứng dụng Do đó một thành phần user action trong mô hình activity diagram cần phải được chuyển đổi sang một thành phần user action tương ứng trong mô hình luồng xử lý với quy tắc chuyển đổi U2U Tương tự một system action trong mô hình activity diagram cũng phải được chuyển đổi tương ướng sang một system action trong mô hình luồng xử lý với quy tắc S2S Nhằm thể hiện các bước xử lý dữ liệu của ứng dụng Web một cách đầy đủ và thống nhất Chi tiết các bước thực hiện cho mỗi quy tắc được trình bày trong mục 2.2.3 và 2.2.4

Quy tắc U2U: Quy tắc U2U chuyển đổi user action trong mô hình activity diagram thành user action tương ứng trong mô hình luồng xử lý, đồng thời các pin tương ứng

Quy tắc S2S: Quy tắc S2S chuyển đổi system action trong mô hình trình bày thành system action trong mô hình luồng xử lý

2.2.1 Quy tắc chuyển đổi U2P

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à người sử dụng trong suốt quá trình hoạt động Trong mô hình điều hướng, process class được liên kết với node điều hướng

khác bằng cách sử dụng process link thể hiện cho một process được gọi để xử lý dữ

liệu từ hành động điều hướng của người dùng thông qua giao diện 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 [6]

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ý Các input pin của user action cũng sẽ được

chuyển đổi thành các thuộc tính Đồng thời nếu có thẻ “validated” thì phương thức validateData (param1, param2, ) cũng được thêm vào để xử lý cho việc kiểm tra cho

các ràng buộc của dữ liệu nhập vào Các bước chuyển đổi user action thành process class:

Quy trình thực hiện quy tắc U2P

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 đó

Biểu đồ diễn tiến của quy tắc U2P được mô tả chi tiết trong Hình 2.1 và Hình 2.2

Hình 2.1 Biểu đồ diễn tiến chuyển đổi quy tắc U2P

Hình 2.2 Biểu đồ diễn tiến chuyển đổi quy tắc U2P

2.2.3 Quy tắc chuyển đổi S2P

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 Một “confirmation process class” sẽ được tạo ra trong mô hình xử lý kèm theo một phương thức thực hiện

Quy trình thực hiện quy tắc S2P

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 và danh sách tham số tương tứ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

Biểu đồ diễn tiến của quy tắc S2P được mô tả chi tiết trong Hình 2.3 và Hình 2.4

Hình 2.3 Biểu đồ diễn tiến chuyển đổi quy tắc S2P

Hình 2.4 Biểu đồ diễn tiến chuyển đổi quy tắc S2P

2.2.3 Quy tắc chuyển đổi U2U

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

Biểu đồ diễn tiến của quy tắc U2U được mô tả chi tiết trong Hình 2.5

Hình 2.5 Biểu đồ diễn tiến chuyển đổi quy tắc U2U

2.2.4 Quy tắc chuyển đổi S2S

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