Các quy tắc chuyển đổi mô hình yêu cầu sang mô hình điều hướng [3].. Trang 10 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
Trang 1HỢP RÀNG BUỘC TRONG PHÁT TRIỂN ỨNG DỤNG WEB HƯỚNG MÔ
HÌNH THEO KỸ THU T UWE Ậ
Chuyên ngành: K thu t ph n m m ỹ ậ ầ ề
LUẬN VĂN THẠC SĨ ỸK THU T Ậ
NGƯỜI HƯỚNG DẪN KHOA H C: Ọ
PGS.TS Hu nh Quyỳ ết Thắng
H N I 2018À Ộ –
Trang 2LỜ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
Trang 3LỜI CAM ĐOAN 2
DANH MỤC CÁC TỪ ẾT TVI Ắ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 đề ề xây dựng các bộ v 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 đổ ừ mô hình yêu cầu sang mô hình xửi t 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
Trang 42.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: ây dựng công cụX 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Ả
Trang 5DANH 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
H™L 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
Trang 6DANH 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 đổ mô hình yêu cầ sang mô hình nội u 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 H™L chuyển đổ ừ mô hình tích hợi t 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 đổ ền điềi ti 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ộ ất biên mô hình trình bàyế c b 53
Hình 4.1 Kiến trúc MagicDraw và MTO-Plugin 55
Trang 7Hì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 D2G 62ắc 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
Trang 8DANH 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
Trang 9LỜ I CẢ ƠN M
Để có thể hoàn thành ận văn ốlu 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 ông nghệC 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 ông nghệC ph n mầ ềm, trường đạ ọc Bách Khoa Hà Nội h i
Em xin chân thành cảm ơn các thầy cô giáo ở ộ môn ông nghệ B C ph n mầ ềm, trường
Đạ ọc Bách Khoa Hà Nội h i
Dù đã cố ắng nhưng ận văn ắ g lu 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!
Trang 10M Ở ĐẦ 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ệ ống UML và chuyển đổi các mô hình ngữ nghĩa mứ th c cao xu ng ốcác mô hình cụ ể và từ đó xuống mã nguồn Nó giúp cho việc phát triển các ứ th 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ấ ả các mô hình trong UWE tồ ạt c 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ề ảng công nghệ khác nhau, do đó việc đảm ảo n t btí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ề hướng, mô hình xử lý, u
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
Trang 11Ngoài ra, đặ tính tương tác cao với ngườ ử ụ c 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ề ến trúc hướng mô hình, các kỹ ki thuật Web hướng mô hình phổ ến, lý do bichọ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ế ề ràng buộc OCL Đồt v 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
Trang 12Chươ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ề ến trúc và cơ kichế 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ộ OCL vào mô hình UWE, sau đó c 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, ải , cthiện k t qu ế ả trong quá trình sinh mã
Thứ ba: Xây dựng công cụ MTO-Plugin minh họ các kỹa thuật trên để ử th nghi m ệ
và đánh giá
Trang 13Chương 1: Tổ ng quan v k thu UWE ề ỹ ậ t 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ộ hướt 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 ,9,13] MDA cung c[1 ấp m t cách ti p cộ ế ận và công cụ nh m m c đích [1]: ằ ụ
t lả ại thành các mô hình, định nghĩa các chức năng của h ệ thống dựa trên mô hình độc
l p n n t ng - PIM, s dậ ề ả ử ụng các ngôn ngữ đặ ả chuyên biệ PIM sau đó đượ c t t c chuy n ểthành một ho c mặ ột vài mô hình dựa trên nề ảng chuyên biện t t - PSM mà các máy tính
có thể chạy được PSM có thể ử ụng các ngôn ngữ đặ ả chuyên biệ s d c t 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 eb hướng mô hình W
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ữ ủa phát triển cá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 hi n mthể ệ ô 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 ứa thông tin cụch 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 ặ
Trang 14Trong 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ồ (xem Hình 1.1)n
Hình 1.1 Cấu trúc MDA cho kỹ thuật Web [2,13]
Một số ỹ thuật Web hướng mô hình điển hình: k
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 ng ccu ấ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 ] W2000 bụ [2 ắt đầu bằng bước phân
Trang 15và mở ộ r ng m t s ộ ố mô hình UML như là biểu đồ ớp và biểu đồ ạng thái Cuối cùng l tr
s dử ụng các biểu đồtuầ ự để mô tả chức năn t 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ứ ạ Phương pháp này sử ụng ký c t p d
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 Wụ eb hoàn chỉnh nhưng chủ ế ập trung vào giai đoạn phân y u ttích và thiế ết k M t trong nhộ ững ưu điểm quan tr ng cọ ủa UWE là tấ ả các mô hình t c
của nó đều là phần m r ng c a UML UWE s dở ộ ủ ử ụng ký pháp đồ ọa hoàn toàn dự h a trên UML Nó cho phép sử ụng các công cụ ựa trên UML và giả d d 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 đổ ừ mô hình i t CIM sang PIM, t ừ mô hình PIM sang PSM
Trang 16(domain-m t (domain-meta-(domain-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 , 16[6 ] 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]
Trang 17B ng 2 ả Các thành phần UWE stereo type ,16] [6UWE 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 ụ UML UWE metamodel định nghĩa mộ ố c 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ả ự tương tác đặc trưng giữa người dùng bên s 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 đố ớ ệ ống, có nghĩa là những gì hệ ối v i h th 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ả ấ ả các t t c trường hợp mà hệ ống có thể đượ 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
Trang 18trong 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ầ yêu cầ u 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ácthành ph n t o ầ ạ nênphần mềm Mô hình hoá ộ n i dung không đòi ỏ ấ ỳ ấ h i b t k c u trúc b ổ
Trang 19Hì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 W ụ ứ ụ eb (Hình 1.5) Nó được th hi n b ng biể ệ ằ ểu đồ ớp và bổ l sung các khuôn mẫu của UWE đại di n cệ ho 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ầ ử mô hình cho việc tích hợp quy trình vào mộn t 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 để ỗ ợ các xử ý h tr l (3) Định nghĩa hành vi
Trang 20Hình 1.5 UWE profile cho mô hình điều hướng [6, 16]
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ể tách ứn 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]
Trang 21Hình 1.6 UWE profile cho mô hình xử lý [6, 16]
Trang 22Hì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 u, liệ nghĩa là nó sẽ chứ ấ ả các hàm, a t t c 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 p nh n d u t ụ tiế ậ ữ liệ ừ 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 ệ
Trang 23Controller: Đóng vài trò trung gian giữa model vvà iew Nó có nhiệm v ti p nh n ụ ế ậyêu cầ ừ client sau đó xửu t lý các yêu cầu đó ọi các , g 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 vầ iew 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ữ àng buộ r 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
Trang 24UML 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ều gì trong mô hình Điều này có nghĩa là trạng thái củi b t 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ấ ỳ ểu t k bi
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 để đặ ả cho UML luôn luôn phả ắ c t 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ữ ảnh mà biể c 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ữ ảnh có tên là Person: context Person từ khóa seft b ể c i u
thức OCL luôn được đặt trong m t ng c nh c ể, và đểộ ữ ả ụth ch ra th hi n cỉ ể ệ ủa đối tượng trong ngữ ảnh đó chúng ta sử ụ c 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ủ ất biếa b n
Ví d : context Company ụ khai báo ngữ ảnh có tên là Company c
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
Trang 25đố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ế ới phương thứt t 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ử ụng toán tử @pre nhưng dbên trong ràng buộc hậu điều kiện có thể ử ụng @pre để s d 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 đề ề xây dựng các bộ v 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 ầu, điều hướng, trình bày, xử lý giúp mô hình tấ ả các khía cạ c t 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ó ể đượ ử ụng cho quá trình sinh mã nguồ th c s d 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
Trang 26c ả 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ộ ề ảng công nghệ ụt n n t c ể khác nhau Với phương pháp chuyển đổth 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ầ quan tâm đến n n n tề ảng công nghệ ụ c thể
Việc chuyển đổi mô hình sẽ ạo điề t 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
Mô hình quyền cơ bản ô tả chính sách an ninh ựa trên ểm soát truy cập
Nó r ng bu c ằ ộ các yế ố ừ mô hình nộu t t i dung của UWE và từ ô hình gười dùng Nó m n
r ng buằ ộc các phầ ử ừ mô hình nội dung và người dùngn t t
ph n giao di n c ng d ng Web
Mô hình trạng thái điều hướng: mô tả ồng điều hướ lu 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
n UML
Mô hình thành phầ : Mô tả ấu trúc ữ ệ 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ạ ấu trúc dữ ệu và tạ c li o m t c a s ộ ử ổ chính cho ứng d ng Wụ eb và chuyển đổi các menu được mô phỏng trong UWE
Trang 27Bướ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ử ụng cách khác nhau d
để 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], №ra 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
Trang 28 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 đượ ích hợp vào một mô hình nền độ ậc t 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]
Trang 29 Chuyển đổi các mô hình thành mã nguồn ph n m m: Đểầ ề chuyển đổ mô i 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à gôn ngữn ATLvà 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ụ ể như th sau:
Trang 30Chuyể 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ứ cùng với công cụ MagicUWE giúp chuyển đổu 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ả ề các thành phầ v n trong UWE profile [6], trong chuyển đổi sang
mô hình trình bày và mô hình xử lý Mộ ố thành phần trong mô hình yêu cầt s u c n ph i ầ ả
Trang 31Mô hình UML đơn thuần, chưa mô tả được đầy đủ ề các ràng buộ v 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ộ ố nghiên cứu giúp tích hợt s 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ở ữ ệu, các liên kế d li 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ở ữ ệu, đả d li 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ý ở ả mô hình giao diện, và mô hình xử c
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ầ ở mô hình yêu cầu cũng đượn c chuyển đổi và tích hợ ự động vào các mô p t 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 ủa luận văn ẽ c
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
một cách tự động, đồng thời giúp cho việc kiểm tra tính hợ ệ ủp l c a d u nhữ liệ ập vào từngười dùng, đảm bảo các ứng d ng Web hoụ ạt động hi u qu ệ ả và chính xác
Trang 32Chươ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 ProcessingAndBrowsing2ProcessClass Quy tắc : ắ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ể ện cho các nghiệ hi 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 CreateProcessDataAndFlowForWebProcess ắc
Quy t CreateProcessDataAndFlowForSimpleProcess ắc
Quy t CreateProcessDataAndFlowForEdit ắc
Ba quy tắc nêu ẽ ạo ra các l ồs t u 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 đổ ừ mô hình yêu cầu sang mô hình xử lý Trong chuyểi t n
đổ ừ mô hình yêu cầ , mô hình xử lý, mô hình điều hưới t u ng sang mô hình trình bày thì
b n quy tố ắc sau đã được áp dụng ] [3
NavigationClass2PresentationClass
Menu2PresentionClass
Index2PresentaionClass
ProcessClass2PrecentionClass
Các quy tắc này giúp chuyển đổi thành các presentation class, tuy nhiên các thành
ph n con tầ ạo nên các group hiện th ị thì chưa được chuyển đổi
Trang 332.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ì đượ hay đổi và presentation class nào sẽ ệc t 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ị ừ các phầ t 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 đổ ừ các input pin i t
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ầ ử tương ứng trong mô hình giao diện t 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 u t ừ ộ ậ ữliệ ừ ngườ ử ụi s d ng, hoặc cũng có thể ừ ột quá trình xử t m
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 ser action thành process class, đồu ng thời các
pin của user action thành các thuộc tính ủa process class đóc
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ự ột system action trong mô hình activity diagram cũng phả đượ m 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ể ện các bướ hi c x ử lý dữ ệu cli ủ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
Trang 34Quy 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 ắc t 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ế ới node điều hướt v ng khác bằng cách sử ụ d ng process link th hi n cho mể ệ ột process được gọi để ử lý dữ x liệ ừ hành động điều hướu t 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 để ử lý cho việ x 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ấ ả các node t c
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 ction tương ứng Đọc các output pin ủ a c a u ser
a ction đó thêm vào danh sách p in
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
Trang 35Hình 2.1 Biểu đồ diễn tiến chuyển đổi quy tắc U2P
Trang 36Hình 2.2 Biểu đồ diễn tiến chuyển đổi quy tắc U2P
2.2.3 Quy t ắ c c huy ể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ông báo để người dùng xác ụ ầ ể th
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 ” ẽ đượ ạo ra trong mô hìc t nh x ử lý kèm theo một phương thức th c hiự ện
x ử lý sau khi người dùng xác nhận đồng ý Chuyển đổi system action thành process
Trang 37Quy 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ấ ả các node t c
B3: Duy ệt các node, vớ i m i nod ỗ e có stereotype là system action Thêm vào danh sách
B4 V i system a ớ ction node đang duyệ t ở B3 Ki m tra th c ể ẻ ủa node đó Nế u th ẻ là
”confirmed” thì t o c ạ onfirmation node tương ứng và thêm vào danh sách
B5: V m i ph n t ới ỗ ầ ử trong danh sách node lấy đượ c sau B3 và B 4 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 “c onfirmation 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ắ Sc 2P được mô ảt chi tiết trong Hình 2.3 Hình 2.4 và
Hình 2.3 Biểu đồ diễn tiến chuyển đổi quy tắc S2P
Trang 38Hình 2.4 Biểu đồ diễn tiến chuyển đổi quy tắc S2P
2.2.3 Quy t chuy ắ c ể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ườ ử ụng thông qua user i s daction 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ác node ếu node đó có stereotype là c t t c N use r action ạ T o user action tương ứng trong mô hình luồ ng x ử lý
B3: Đọ ấ ả các p c t t c in c ủa node và tạ o ra p in tương ứ ng cho user a ction đượ ạ c t o
ra ở B2.
B4: N u user a ế ction có thẻ “validated” T o ph n t validate v ạ ầ ử ới stereotype là
s ystem 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
Trang 39Biểu đồ ễ di n ti n c a ế ủ quy tắ U2U c đượ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 chuy ắ c ể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” ể ện cho hành độth hi ng cần được xác nhậ ừ ngườn t 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