Khảo sát khả năng sử dụng ngôn ngữ bpel để cài đặt các mô hình tiến trình phần mềm

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƢỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN



Trần Khải Hoàng



KHẢO SÁT KHẢ NĂNG SỬ DỤNG NGÔN NGỮ BPEL ĐỂ
CÀI ĐẶT CÁC MÔ HÌNH TIẾN TRÌNH PHẦN MỀM

Chuyên ngành: Khoa học máy tính
Mã số: 02 06 4801 14


LUẬN VĂN THẠC SĨ:
KHOA HỌC MÁY TÍNH



NGƢỜI HƢỚNG DẪN KHOA HỌC:
1. TS. Trần Hạnh Nhi



TP. Hồ Chí Minh – 2011

LỜI CẢM ƠN


Tôi xin chân thành cảm ơn Khoa Công Nghệ Thông Tin, Đại học Khoa Học
Tự Nhiên đã hỗ trợ mọi điều kiện để tôi có thể hoàn thành đƣợc đề tài này. Em xin
chân thành cảm ơn sự hƣớng dẫn và truyền đạt tận tình của cô Trần Hạnh Nhi,
ngƣời đã quan tâm theo dõi em trong suốt quá trình nghiên cứu và hoàn thiện đề tài.

Em xin gởi lời cảm ơn sâu sắc đến tất cả giảng viên cao học K.16, những
ngƣời đã đào tạo và dìu dắt em trong suốt những năm cao học. Cảm ơn Bùi Tấn Lộc
đã giúp tháo dỡ những vƣớng mắc của đề tài.

Cuối cùng, xin gởi lời biết ơn và tình yêu từ tận đáy lòng con đến ba mẹ,
ngƣời đã luôn bên con khi hạnh phúc cũng nhƣ lúc đau buồn. Nhờ những lời
khuyên nhủ của ngƣời, con đã vƣợt qua các khó khăn để hoàn thành đề tài.

Mặc dù luận văn đã hoàn thành nhƣng do kiến thức của ngƣời thực hiện có
hạn nên chắc chắn đề tài còn nhiều thiếu sót và hạn chế. Rất mong nhận đƣợc ý kiến
đóng góp chân thành của mọi ngƣời.
TP. Hồ Chí Minh, 29/03/2011
Trần Khải Hoàng




NỘI DUNG

THUẬT NGỮ VÀ CÁC TỪ VIẾT TẮT I

DANH SÁCH CÁC HÌNH II
DANH SÁCH CÁC BẢNG V
Chƣơng I – MỞ ĐẦU 1
1.1 Giới thiệu 1
1.2 Phát biểu bài toán 4
1.3 Hƣớng tiếp cận của đề tài 5
1.4 Các kết quả đạt đƣợc 6
1.5 Bố cục của luận văn 7
Chƣơng II – CƠ SỞ LÝ THUYẾT 10
2.1 Tiến trình 10
2.1.1 Tiến trình nghiệp vụ 10
2.1.2 Tiến trình phần mềm 11
2.1.3 Mô hình tiến trình 11
2.1.4 Ngôn ngữ mô hình tiến trình 12
2.2 Ngôn ngữ BPEL 14
2.2.1 Nguồn gốc 14
2.2.2 Tiến trình BPEL 14
2.2.3 Thực thi tiến trình 18
2.2.4 Nhận xét 20
2.3 Ngôn ngữ UML-PP 21
2.3.1 Thành tố tiến trình 22



2.3.2 Mô hình tiến trình 25
2.3.3 Mẫu tiến trình 29
2.3.4 Nhận xét 34
2.4 Các phƣơng pháp chuyển đổi mô hình 35
2.4.1 Chuyển đổi mô hình sang mã nguồn 38
2.4.1.1 Hƣớng tiếp cận visitor-based 38

2.4.1.2 Hƣớng tiếp cận template-based 38
2.4.2 Chuyển đổi mô hình sang mô hình 39
2.4.2.1 Hƣớng tiếp cận định dạng trực tiếp 39
2.4.2.2 Hƣớng tiếp cận quan hệ 39
2.4.2.3 Hƣớng tiếp cận dựa vào chuyển đổi hình 39
2.4.2.4 Hƣớng tiếp cận hƣớng cấu trúc 40
2.4.2.5 Hƣớng tiếp cận lai 40
Chƣơng III – CÁC NGHIÊN CỨU LIÊN QUAN 42
3.1 Mô hình hóa và thực thi tiến trình phần mềm 42
3.2 Mô hình hóa và thực thi tiến trình nghiệp vụ 44
3.3 Chuyển đổi BPMN sang BPEL 46
3.4 Chuyển đổi UML sang BPEL 50
3.5 Kết luận 55
Chƣơng IV – PHƢƠNG PHÁP KHẢO SÁT 58
4.1 Phƣơng pháp khảo sát 58
4.2 Xây dựng metamodel UML-PP 60
4.3 Xây dựng metamodel BPEL 67
4.4 Chuyển đổi mô hình từ UML-PP sang BPEL 68



Chƣơng V – HIỆN THỰC VÀ KIỂM CHỨNG CHUYỂN ĐỔI UML-PP SANG
BPEL 76
5.1 Xây dựng công cụ mô hình UML-PP 76
5.2 Cài đặt ATL của bộ luật chuyển đổi UML-PP sang BPEL 81
5.3 Cài đặt Acceleo cho chuyển đổi mô hình BPEL sang dạng BPEL XML 83
5.4 Các ví dụ chuyển đổi 85
5.4.1 Fagan Code Inspection 85
5.4.2 Refactor Code 88
5.4.3 Modify Design 90

5.4.4 Mô hình sử dụng Process Pattern Binding 92
5.5 Kiểm chứng tiến trình kết quả BPEL 95
Chƣơng VI – KẾT LUẬN 101
6.1 Kết quả đạt đƣợc 101
6.2 Nhận xét 102
6.3 Hƣớng phát triển 103
TÀI LIỆU THAM KHẢO 105
A. PHỤ LỤC - CẢI TIẾN UML-PP METAMODEL 108
B. PHỤ LỤC - MÃ NGUỒN ATL 124
C. PHỤ LỤC - MÃ NGUỒN ACCELEO 132



II


DANH SÁCH CÁC HÌNH


Hình I-1 Kiến trúc Metadata MOF [8] 5
Hình I-2 Mô hình chuyển đổi mô hình của ATL 6
Hình II-1 Mô hình thực thi của BPEL 19
Hình II-2 Vị trí của metamodel UML-PP trong kiến trúc MDA [6] 22
Hình II-3 Metamodel biểu diễn các thành tố tiến trình trong UML-PP [6] 24
Hình II-4 Ví dụ về các mức trừu tƣợng của sản phẩm [6] 25
Hình II-5 Metamodel của mô hình cấu trúc UML-PP [6] 26
Hình II-6 Ví dụ mô hình cấu trúc của một tiến trình kiểm thử [6] 27
Hình II-7 Metamodel của mô hình hành vi UML-PP [6] 28
Hình II-8 Ví dụ mô hình hành vi của quá trình Phân tích sơ bộ [6] 29
Hình II-9 Metamodel của mẫu tiến trình UML-PP [6] 30

Hình II-10 Ví dụ về quan hệ ProcessPatternBinding [6] 31
Hình II-11 Mô hình tiến trình sau khi áp dụng quan hệ binding [6] 32
Hình II-12 Ví dụ sử dụng quan hệ applying để tái tổ chức tiến trình [6] 33
Hình II-13 Kết quả áp dụng quan hệ applying trong Hình II-12 34
Hình II-14 Minh họa chuyển đổi giữa các mô hình trong kiến trúc MDA 36
Hình II-15 Giải pháp chuyển đổi mô hình tổng quát trong kiến trúc MDA [14] 37
Hình III-1 Minh họa hoạt động của một PCSEE 44
Hình III-2 Một ví dụ về mô hình sử dụng BPMN 47
Hình III-3 Tập hợp các thành tố cơ bản của BPMN [21] 48
Hình III-4 Chuyển đổi các well-structured component sang BPEL [21] 49
Hình III-5 Quá trình chuyển đổi BPMN sang BPEL dùng metamodel 50
Hình III-6 Qui trình chuyển đổi UML Profile sang BPEL [23] 51
Hình IV-1 Phƣơng pháp chuyển đổi mô hình UML-PP sang BPEL 59
Hình IV-2 Gói Umlpp chứa các lớp của UML-PP 61
Hình IV-3 Gói L0 62
III


Hình IV-4 Gói L2 62
Hình IV-5 Gói LM 63
Hình IV-6 Gói UmlppComplete là trộn các gói để tạo Umlpp metamodel 63
Hình IV-7 Metamodel của Umlpp dƣơí dạng UML 64
Hình IV-8 Tạo Umlpp metamodel 65
Hình IV-9 Metamodel của Umlpp 66
Hình V-1 File umlppcomplete.gmftool mô tả các công cụ 77
Hình V-2 File umlppcomplete.graph chứa mô tả hình biểu diễn nốt, liên kết 78
Hình V-3 File umlppcomplete.map giúp ánh xạ công cụ, hình vẽ và lớp lƣu trữ 79
Hình V-4 Công cụ mô hình hóa UML-PP 80
Hình V-5 Mô hình Fagan Code Inspection 85
Hình V-6 Mô hình BPEL Fagan Code Inspection sau khi kiểm tra 87

Hình V-7 Mô hình dịch vụ web HumanActivity 88
Hình V-8 Mô hình tiến trình Refactor Code 89
Hình V-9 Mô hình BPEL Refactor Code sau khi kiểm tra 90
Hình V-10 Mô hình tiến trình Modify Design 91
Hình V-11 Mô hình BPEL của Modify Design sau khi kiểm tra 92
Hình V-12 Qui trình phần mềm sử dụng quan hệ Process Pattern Binding 93
Hình V-13 Qui trình sau khi mở quan hệ Process Pattern Binding 94
Hình V-14 Mô hình BPEL sau khi kiểm tra 95
Hình V-15 Kết quả thực thi tiến trình Modify Design 96
Hình V-16 Kết quả thực thi tiến trình Fagan Code Inspection 97
Hình V-17 Kết quả thực thi tiến trình Refactor Code 98
Hình V-18 Kết quả thực thi tiến trình sử dụng Process Pattern Binding 99
Hình A-1 ProcessElement  ParameterizableElement  Classifier 108
Hình A-2 ProcessElement  Classifier 109
Hình A-3 Mô hình sau khi xóa bỏ thừa kế ProcessElement  Classifier 110
Hình A-4 Thuộc tính type trùng với tên thuộc tính type của ObjectNode 110
Hình A-5 Mô hình sau khi đổi tên type thành productType 111
Hình A-6 Mô hình dƣ thừa thừa kế DirectedRelationShip 112
IV


Hình A-7 Sau khi xóa thừa kế Aggreation, Refinement DirectedRelationship 112
Hình A-8 Lớp Resource abstract 113
Hình A-9 Mô hình sau khi chuyển lớp Resource không abstract 113
Hình A-10 StructuralModel và BehaviourModel là abstract 114
Hình A-11 StructuralModel và BehaviourModel không abstract 114
Hình A-12 Dƣ thừa lớp Edge và Node 115
Hình A-13 Xóa bỏ lớp Node và Edge 115
Hình A-14 Tất cả lớp con của ProcessElement đều thừa kế StructuralNode,
ProcessRelation đều thừa kế từ StructuralEdge 116

Hình A-15 Mô hình chuyển ProcessRelation  StructuralEdge, ProcessElement 
StructuralNode 117
Hình A-16 Dƣ thừa thừa kế Classifier trên lớp ProcessModel, ProcessPattern 118
Hình A-17 Sau khi loại bỏ thừa kế Classifier trên ProcessModel, ProcessPattern . 119
Hình A-18 Trùng quan hệ incoming, outgoing ở các lớp con ProcessElement nhƣ
Task, Product và quan hệ target, source ở lớp PatternApplicationRelationship 120
Hình A-19 Đổi tên các quan hệ incoming, outgoing, source và target 121
Hình A-20 Trùng quan hệ target, source ở lớp PatternApplicationRelationship 122
Hình A-21 Xoá quan hệ thừa kế PatternApplicationRelationship 
DirectedRelationship 123
V


DANH SÁCH CÁC BẢNG


Bảng III-1 Các bộ máy thực thi BPMN và BPEL 45
Bảng III-2 UML1.4 Profile thành BPEL [23] 51
Bảng III-3 Bảng quan hệ giữa UML2 profile và BPEL 52
Bảng III-4 Luật chuyển đổi UMLActivity2BusinessProcess 53
Bảng III-5 Một số các luật chuyển đổi UML4SPM sang BPEL 54







Chƣơng I
MỞ ĐẦU

Giới thiệu
Phát biểu bài toán
Hƣớng tiếp cận của đề tài
Các kết quả đạt đƣợc
Bố cục của luận văn
1



Chƣơng I – MỞ ĐẦU

1.1 Giới thiệu
Theo một thống kê năm 2010 của Miniwatts Marketing Group [1] số
lƣợng ngƣời dùng internet là 1.9 tỷ ngƣời chiếm 28.7% dân số trái đất với
tốc độ tăng trƣởng trung bình 40.3%/năm. Sự phát triển mạnh mẽ của
internet trong thập niên này đã làm thay đổi nhiều ngành trong đó có công
nghệ phần mềm. Internet đã xóa đi giới hạn về ranh giới các quốc gia hay
khoảng cách địa lý. Các công việc vì thế có thể dễ dàng đƣợc chia nhỏ và
đƣợc thuê ngoài khắp nơi trên thế giới. Đi cùng với sự bùng nổ của internet
là sự phát triển và hội tụ của các thiết bị số. Thiết bị số ngày càng trở nên
nhỏ gọn hơn, năng lực xử lý ngày càng mạnh hơn, khả năng kết nối và chia
sẻ càng tăng. Hơn nữa, việc bùng nổ các công nghệ mới sẽ khiến nhiều kiến
thức, kỹ thuật công nghệ phần mềm nhanh chóng trở nên lạc hậu. Tất cả
những thách thức này khiến sự cạnh tranh trong ngành công nghệ phần
mềm ngày càng trở nên gay gắt. Các công ty bắt buộc phải linh hoạt hơn,
năng suất phải cao hơn để có thể cho ra đời những sản phẩm phần mềm với
chất lƣợng ngày càng tăng và thời gian càng ngắn.
Tuy nhiên, một số trở ngại nhất định khiến việc dung hòa hiệu suất và
chất lƣợng của công việc phát triển phần mềm vẫn còn là các mục tiêu khó
đạt [2]:

 Khó nắm bắt chính xác yêu cầu của khách hàng. Nhà phát triển
thƣờng có hiểu biết hạn chế về lĩnh vực của khách hàng. Khách
hàng cũng không có kiến thức về qui trình phát triển phần mềm.
Thậm chí, khách hàng còn không biết hoặc không đƣa ra yêu cầu rõ
ràng. Điều này thƣờng dẫn đến nhu cầu thay đổi trong quá trình
phát triển phần mềm.
2



 Đối phó thường trực với yêu cầu thay đổi. Thay đổi có thể diễn ra
bất kỳ lúc nào trong quá trình phát triển phần mềm. Rất nhiều loại
thay đổi có thể xảy ra nhƣ lỗi mã nguồn, thay đổi thiết kế, thay đổi
nhân sự, thay đổi yêu cầu… Thay đổi càng trễ chi phí khắc phục
càng cao.
 Môi trường phát triển không đồng nhất. Đối với những dự án phần
mềm lớn đội ngũ phát triển có thể bao gồm nhiều đội với nhiều
nhân viên có những kỹ năng lập trình, giao tiếp khác nhau đến từ
nhiều nơi trên thế giới và sử dụng những những nền tảng kỹ thuật
khác biệt. Việc phối hợp các môi trƣờng này thƣờng đòi hỏi chi phí
cao và làm phức tạp hóa quá trình phát triển.
Trƣớc đặc thù phức tạp của bài toán phát triển phần mềm hiện đại, nhiều
nghiên cứu đƣợc thực hiện nhằm nâng cao hiệu suất, rút ngắn thời gian phát
triển và bảo đảm chất lƣợng sản phẩm phần mềm. Một trong những cách tiếp
cận đƣợc sử dụng rộng rãi tại các công ty phần mềm là xây dựng và tuân thủ
các tiến trình phát triển phần mềm hiệu quả.
Tiến trình phần mềm đƣợc định nghĩa là một tập hợp các bƣớc có thể có
thứ tự liên quan đến những thành tố phần mềm nhƣ tài liệu, con ngƣời và
máy tính nhằm sản xuất và bảo trì các sản phẩm phần mềm (Software
Deliverables) [3]. Việc sử dụng một tiến trình phát triển phần mềm ƣu việt sẽ

giúp giảm thời gian và chi phí phát triển đồng thời cải thiện chất lƣợng phần
mềm.
Nhằm kiểm soát và hỗ trợ tốt hơn tiến trình phần mềm, nhiều nghiên cứu
đã đƣợc thực hiện để tạo và biểu diễn nó [4]. Kết quả là sự ra đời các ngôn
ngữ mô hình hóa tiến trình phần mềm - SPML (Software Process Modeling
Language). Các ngôn ngữ mô hình hóa tiến trình có thể đƣợc phát triển với
nhiều mức độ hình thức hóa khác nhau: một số ngôn ngữ biễu diễn tiến trình
dƣới dạng có thể thực thi đƣợc và một số chỉ cung cấp bộ ký hiệu để mô tả
tiến trình [5].
3



Ngôn ngữ mô hình hóa tiến trình dạng thực thi cung cấp một đặc tả đầy
đủ về ngữ nghĩa và cú pháp cho phép biểu diễn các thành tố khác nhau của
một tiến trình. Tiến trình đƣợc biểu diễn trong ngôn ngữ này có thể đƣợc
thực thi trên một bộ máy tiến trình. Khi đƣợc thực thi, một số bƣớc trong tiến
trình phần mềm có thể đƣợc thực hiện tự động nhƣ: thông báo nhắc nhở công
việc, gởi tài liệu cho ngƣời có trách nhiệm, điều khiển các công cụ phát triển,
phân chia quyền và áp đặt vai trò cho ngƣời phát triển Việc thực thi tự
động các bƣớc trong tiến trình phần mềm mà không có sự tham gia của con
ngƣời không những giúp giảm thiểu sai sót, gia tăng năng suất làm việc, rút
ngắn thời gian hoàn thành sản phẩm mà còn giúp nhà quản lý nắm bắt đƣợc
hiện trạng của tiến trình phần mềm. Để thực thi đƣợc các mô hình phần
mềm, đòi hỏi phải có các môi trƣờng thực thi – PCSEE (Process Centered
Software Engineering Environment) hỗ trợ SPML tƣơng ứng. Nhiều nghiên
cứu tập trung phát triển các SPML chỉ dừng ở mức mô hình hóa dựa trên
thừa hƣởng hệ thống các ký hiệu và sơ đồ chuẩn của UML (nhƣ UML4SPM
[5], UML-PP [6]). Tuy nhiên, còn rất ít các nghiên cứu nhằm hiện thực môi
trƣờng thực thi cho SPML. Một số ngôn ngữ đƣợc hỗ trợ môi trƣờng thực thi

ở dạng sơ khai (nhƣ UML4SPM) hoặc chƣa có (nhƣ với UML-PP).
Trong khi đó, đối với lĩnh vực mô hình hóa tiến trình nghiệp vụ, nhiều
ngôn ngữ mô hình chuẩn đã ra đời và đang đƣợc sử dụng rộng rãi điển hình
là BPEL (Business Process Execution Language). BPEL là ngôn ngữ giúp
định nghĩa và thực thi các dịch vụ web (Web Service) một cách dễ dàng.
Đƣợc sự hỗ trợ rất lớn từ các công ty nhƣ Oracle, IBM, Microsoft… BPEL
hiện có rất nhiều môi trƣờng thực thi kể cả thƣơng mại và mã nguồn mở nhƣ
Oracle Process Engine, ActiveVOS, ApacheODE, GlassFish Server…
Quan sát hiện trạng phát triển của công nghệ tiến trình trong cộng đồng
tiến trình phần mềm và tiến trình nghiệp vụ dẫn chúng tôi đến câu hỏi sau:
Trong bối cảnh thiếu vắng môi trường thực thi các tiến trình phần mềm
trái lại với sự trưởng thành của các môi trường thực thi tiến trình nghiệp vụ,
4



liệu chúng ta có thể sử dụng các môi trường thực thi tiến trình nghiệp vụ
đang có sẵn để thực thi mô hình tiến trình phần mềm?
Đó là xuất phát điểm của đề tài nghiên cứu đƣợc thực hiện trong luận
văn này.

1.2 Phát biểu bài toán
Nhằm tận dụng môi trƣờng thực thi hỗ trợ tiến trình nghiệp vụ để giải
quyết vấn đề thiếu môi trƣờng thực thi các mô hình tiến trình phần mềm,
chúng tôi đã đề nghị đề tài “Khảo sát khả năng sử dụng ngôn ngữ BPEL để
cài đặt các mô hình tiến trình phần mềm”.
Đề tài tập trung làm rõ giả thuyết về tính khả thi của việc dùng BPEL để
cài đặt các tiến trình phần mềm và khảo sát các ƣu, khuyết điểm của việc sử
dụng môi trƣờng thực thi tiến trình nghiệp vụ để thực thi tiến trình phần
mềm.

Về bản chất, tiến trình phần mềm là một loại tiến trình nghiệp vụ. Thế
nhƣng trọng tâm của tiến trình phần mềm là các hoạt động và giao tiếp mang
tính sáng tạo cao của con ngƣời trong khi đó trọng tâm của tiến trình nghiệp
vụ thƣờng là mục đích kinh tế với các hoạt động tính toán, nghiệp vụ. Tiến
trình phần mềm vì thế thƣờng phức tạp, khó định nghĩa chính xác và thiếu ổn
định hơn so với các tiến trình nghiệp vụ.
Ngôn ngữ mô hình phần mềm đƣợc sử dụng để khảo sát là ngôn ngữ
UML-PP [6], một ngôn ngữ mô hình mới do Tran.HN đề xuất với ƣu điểm
cung cấp đầy đủ cú pháp cho các thành tố phần mềm đồng thời có hỗ trợ tái
sử dụng mẫu tiến trình phần mềm (Process Pattern). Ngôn ngữ mô hình tiến
trình nghiệp vụ khảo sát là ngôn ngữ BPEL [7], một ngôn ngữ phổ biến đƣợc
tổ chức OASIS công nhận tiêu chuẩn. Ngôn ngữ UML-PP có thể biểu diễn
tiến trình phần mềm ở khía cạnh cấu trúc và hành vi. Với mục đích khảo sát
tính thực thi của tiến trình, chúng tôi chỉ tiến hành khảo sát trên mô hình
hành vi của UML-PP.
5




1.3 Hƣớng tiếp cận của đề tài
Nhằm trả lời cho giả thuyết của đề tài, chúng tôi sẽ tiến hành khảo sát
khả năng chuyển đổi một số mô hình phần mềm cơ bản đƣợc biểu diễn bởi
UML-PP (bao gồm Fagan Code Inspection, Refactor Code và Modify
Design) sang BPEL. UML-PP là ngôn ngữ mô hình đƣợc chọn do UML-PP
có tính hình tƣợng cao, dễ đọc, dễ hiểu hơn nữa UML-PP nổi trội hơn các
ngôn ngữ khác ở khả năng dùng lại mẫu tiến trình.
Theo mô hình kiến trúc bốn tầng cua OMG, mô hình sẽ đƣợc biểu diễn
ở mức M1 trong khi đó ngôn ngữ mô hình hóa đƣợc biểu diễn bởi
metamodel ở mức M2.

Hình I-1 Kiến trúc Metadata MOF [8]
Có một số trở ngại nhất định khi tiến hành chuyển đổi là BPEL đƣợc xây
dựng dựa trên ngôn ngữ XML [7] trong khi đó UML-PP đƣợc kế thừa từ
SPEM [9] (Software & Systems Process Engineering Metamodel Specifica-
tion) và UML sử dụng mô hình MOF [8] (Meta Object Facility) của OMG.
Để hiện thực việc chuyển đổi giữa mô hình UML-PP sang mô hình
BPEL, chúng tôi sử dụng ngôn ngữ chuyển đổi mô hình ATL (ATL
6



Transformation Language). Việc chuyển đổi có thể đƣợc tóm lƣợc bởi [Hình
I-2].


Hình I-2 Mô hình chuyển đổi mô hình của ATL
Trƣớc tiên, chúng tôi sẽ xây dựng metamodel cho cả hai ngôn ngữ UML-
PP (MM
UML-PP
) và BPEL (MM
BPEL
). Một mô hình tiến trình phần mềm bất
kỳ (M
UML-PP
) sẽ đƣợc chuyển đổi sang mô hình tiến trình nghiệp vụ (M
BPEL
)
bằng cách xây dựng một bộ luật ATL (M
ATL

). M
ATL
đƣợc xây dựng dựa vào
việc tìm kiếm các luật chuyển đổi từ metamodel MM
UML-PP
sang MM
BPEL


1.4 Các kết quả đạt đƣợc
Luận văn khảo sát việc sử dụng BPEL để cài đặt các mô hình tiến trình
phần mềm, bƣớc đầu đã đạt đƣợc một số kết quả nhƣ sau:
 Báo cáo tổng hợp về mô hình tiến trình nghiệp vụ, mô hình tiến
trình phần mềm, tổng quan về chuyển đổi mô hình, hiện trạng các
nghiên cứu về việc chuyển đổi mô hình giữa hai miền tiến trình
phần mềm và tiến trình nghiệp vụ
MMM
MM
UML-PP

MM
ATL

MM
BPEL

M
UML-PP
M
BEL

M
ATL

Chuyển đổi
Tuân theo
Tuân theo
Tuân theo
Tuân theo
Tuân theo
Tuân theo
7



 Xây dựng metamodel của ngôn ngữ BPEL, metamodel của ngôn
ngữ UML-PP. Để hỗ trợ mô hình hóa các tiến trình UML-PP,
chúng tôi đã xây dựng một công cụ mô hình UML-PP trên nền tảng
GMF (Graphical Modeling Framework) của eclipse hỗ trợ mô hình
MOF và lƣu trữ theo chuẩn XMI (XML Metadata Interchange)
 Thử nghiệm chuyển đổi một số tiến trình phần mềm (lấy từ [6])
UML-PP sang BPEL và cài đặt các chuyển đổi này bằng phƣơng
pháp chuyển đổi mô hình sử dụng ATL. Nhằm kiểm chứng việc
chuyển đổi, các tiến trình BPEL kết quả sẽ đƣợc kiểm tra trên
Netbeans 6.7.1 sau đó sẽ đƣợc cấu hình và thực thi trên môi trƣờng
GlassFish Server v2.1.

1.5 Bố cục của luận văn
Luận văn đƣợc trình bày theo cấu trúc nhƣ sau:
 Chƣơng I giới thiệu động cơ, phát biểu bài toán cùng với sơ lƣợc
hƣớng tiếp cận của đề tài

 Chƣơng II cung cấp cái nhìn tổng quan về mô hình tiến trình
nghiệp vụ và mô hình tiến trình phần mềm. Các ngôn ngữ đƣợc sử
dụng phổ biến trong cả hai miền sẽ đƣợc giới thiệu trong chƣơng
này. Bên cạnh đó chúng tôi cũng tóm lƣợc các đặc điểm chính và
cú pháp của hai ngôn ngữ: BPEL dùng mô hình tiến trình nghiệp vụ
và UML-PP dùng để mô hình tiến trình phần mềm. Các phƣơng
pháp chuyển đổi mô hình cũng đƣợc đề cập trong chƣơng này
 Chƣơng III khám phá các nghiên cứu liên quan đến đề tài. Trong
số đó có các nghiên cứu chuyển đổi mô hình trong cùng miền (nhƣ
từ BPMN sang BPEL) và khác miền (nhƣ từ BPEL sang UML và
ngƣợc lại). Hƣớng tiếp cận chuyển đổi mô hình M2M (Model To
Model) đƣợc sử dụng phổ biến nhất
8



 Chƣơng IV trình bày hƣớng tiếp cận chính của luận văn. Các bƣớc
chúng tôi đã tiến hành để khảo sát chuyển đổi một mô hình phần
mềm đƣợc cài đặt trên UML-PP sang mô hình trên BPEL. Các
bƣớc chính bao gồm xây dựng và kiểm tra các metamodel UML-
PP, BPEL; xây dựng công cụ mô hình hóa cho UML-PP; dùng
ATL chuyển đổi mô hình UML-PP sang BPEL; dùng Acceleo (là
một ngôn ngữ chuyển đổi mô hình sang văn bản) chuyển đổi mô
hình BPEL sang BPEL XML và cuối cùng là cấu hình thực thi file
BPEL XML kết quả
 Chƣơng V trình bày các tiến trình đƣợc sử dụng để khảo sát, mô tả
các quá trình thực hiện và kết quả các bƣớc chuyển đổi
 Chƣơng VI phân tích, đánh giá các kết quả đã đạt đƣợc. Các ƣu và
nhƣợc điểm của việc dùng BPEL để cài đặt các tiến trình phần mềm
cũng sẽ đƣợc mổ xẻ trong chƣơng này. Tổng kết bằng cách liệt kê

những đóng góp chính của luận án và chỉ ra một số các hƣớng phát
triển của đề tài.


9





Chƣơng II
CƠ SỞ LÝ THUYẾT
Tiến trình
Tiến trình nghiệp vụ
Tiến trình phần mềm
Ngôn ngữ mô hình hóa tiến trình
Ngôn ngữ BPEL
Ngôn ngữ UML-PP
Các phƣơng pháp chuyển đổi mô hình

10



Chƣơng II – CƠ SỞ LÝ THUYẾT
Trong chƣơng này, chúng tôi giới thiệu các định nghĩa về tiến trình, tiến trình
nghiệp vụ và tiến trình phần mềm đồng thời tóm lƣợc các khái niệm, cú pháp và
bộ ký hiệu của ngôn ngữ BPEL và UML-PP. Việc phân loại chuyển đổi mô hình
(chuyển đổi mô hình sang mô hình và mô hình sang mã nguồn) sẽ đƣợc trình
bày cuối chƣơng.

2.1 Tiến trình
Khái niệm tiến trình đã tồn tại từ lâu và gắn liền với các hoạt động sản
xuất, kinh doanh và dịch vụ của các tổ chức, cá nhân. Khái niệm này đƣợc
quan tâm trong những năm gần đây khi ngƣời ta muốn ghi lại nó phục vụ
mục đích học tập, đánh giá, cải tiến nhằm mục đích nâng cao hiệu quả và
hiệu suất hoạt động. Tổ chức ISO định nghĩa: “Tiến trình là một quá trình sử
dụng các tài nguyên để chuyển hóa các yếu tố đầu vào thành các yếu tố đầu
ra thông qua việc thực hiện một loạt các công việc” [10]. Khái niệm tiến
trình đƣợc sử dụng rất rộng rãi và trong nhiều lĩnh vực khác nhau không
riêng gì trong lĩnh vực công nghệ phần mềm.

2.1.1 Tiến trình nghiệp vụ
Trong lĩnh vực kinh tế, tiến trình nghiệp vụ đƣợc định nghĩa một cách
tổng quát là tập hợp các hoạt động để đạt tới một mục đích kinh tế nào đó.
Tiến trình đƣợc biểu diễn bằng một luồng các công việc đƣợc phối hợp với
nhau để hoàn thành mục tiêu này. Tổ chức OMG lại xem “ Tiến trình nghiệp
vụ là một hoạt động diễn trong một tổ chức hoặc công ty. Tiến trình có thể
đƣợc định nghĩa ở bất kỳ một mức độ nào từ doanh nghiệp cho đến mức cá
nhân. Các tiến trình ở mức thấp có thể đƣợc nhóm lại để đạt tới một mục tiêu
chung” [11].

11



2.1.2 Tiến trình phần mềm
Trong lĩnh vực công nghệ phần mềm, tiến trình phần mềm đƣợc hiểu là:
“Một tập hợp các hoạt động của ngành công nghệ phần mềm nhằm biến các
yêu cầu của ngƣời dùng thành phần mềm” [12]. Cần hiểu tiến trình phần

mềm là một khái niệm rộng hơn qui trình phát triển phần mềm SDLC
(Software Development Life Cycle). SDLC biểu diễn các giai đoạn khác
nhau trong vòng đời của một tiến trình phần mềm bắt đầu khi phần mềm
đƣợc thai ngén cho đến khi nó không còn đƣợc sử dụng nữa. Các giai đoạn
trong SDLC có thể kể đến là giai đoạn yêu cầu, giao đoạn hiện thực, giai
đoạn kiểm thử, giai đoạn cài đặt, vận hành và giai đoạn bảo trì. SDLC mô tả
tiến trình ở mức tổng quát, những thông tin trong SDLC không đủ để ghi
nhận, vận hành các tiến trình phần mềm thực tế vốn có nhiều hoạt động sử
dụng nhiều công cụ liên quan đến nhiều ngƣời bị ràng buộc bởi nhiều chính
sách và yêu cầu từ phía khách hàng.

2.1.3 Mô hình tiến trình
Tiến trình có thể ảnh hƣởng to lớn đến sản phẩm của hoạt động sản xuất
và kinh doanh. Việc sử dụng một tiến trình tốt có thể nâng cao hiệu suất hoạt
động và chất lƣợng sản phẩm [12]. Tất cả các tổ chức hoạt động đều đang sử
dụng tiến trình. Nhằm hỗ trợ việc phân tích và cải tiến tiến trình, một yêu cầu
cấp thiết đặt ra là phải thực hiện mô tả tƣờng minh các tiến trình.
Mô hình hóa tiến trình phần mềm là việc mô tả tiến trình phần mềm
thông qua một hoặc một vài mô hình tiến trình. Mô hình tiến trình là một bản
mô tả tiến trình bằng một ngôn ngữ mô hình hóa nào đó (Process Modeling
Language).
Mô hình tiến trình là một mô tả tƣờng minh của tiến trình sử dụng hình
vẽ, văn bản theo một cú pháp và ràng buộc nhất định – ngôn ngữ mô hình
tiến trình. Việc mô hình hóa tiến trình mang lại các lợi ích [12]:
12



 Giúp tiến trình dễ hiểu: việc mô tả các khái niệm, hoạt động bằng
các hình vẽ, văn bản khiến tiến trình trở nên rõ ràng và dễ hiểu hơn.

Thêm vào đó, việc sử dụng cùng một ngôn ngữ khiến việc trao đổi
thông tin về tiến trình cũng thống nhất, thuận tiện hạn chế các sai
sót do mơ hồ
 Giúp quản lý và vận hành tiến trình: mô hình tiến trình có khả
năng cung cấp thông tin về tình trạng của các hoạt động, trạng thái
các sản phẩm vào bất kỳ thời điểm nào. Các thông tin này giúp nhà
quản lý có cái nhìn tổng thể về hệ thống, có thể tiến hành theo dõi
và điều chỉnh kịp thời các hoạt động nếu có sai sót xảy ra. Ngoài ra,
bằng việc sử dụng các công cụ hỗ trợ thực thi tiến trình, một số
hoạt động trong tiến trình có thể đƣợc thực hiện hoàn toàn tự động
 Giúp phân tích và cải tiến tiến trình: việc giả lập tiến trình là rất
quan trọng trong việc phân tích và cải tiến tiến trình. Mô hình tiến
trình cung cấp các thông tin cho việc phân tích và giả lập tiến trình.
Hơn nữa, sự tồn tại của mô hình tiến trình cho phép dễ dàng hơn
trong việc sử dụng lại các tiến trình đã đƣợc kiểm nghiệm, đây là
một nhân tố quan trọng để cải tiến tiến trình. Việc cải tiến tiến trình
có thể đƣợc thực hiên thông qua việc sử dụng các mẫu tiến trình
nhằm tái cấu trúc tiến trình hiện có.

2.1.4 Ngôn ngữ mô hình tiến trình
Một mô hình tiến trình phải đƣợc diễn đạt bằng một ngôn ngữ nào đó.
Ngôn ngữ mô tả tiến trình định nghĩa các khái niệm dành cho các tiến trình,
đồng thời cung cấp cú pháp và hệ thống ký hiệu để biểu diễn mô hình tiến
trình thông qua các khái niệm này.
Có nhiều cách phân loại ngôn ngữ mô tả tiến trình khác nhau, ví dụ nhƣ
dựa trên hệ ngôn ngữ, dựa trên mức độ hình thức của ngôn ngữ… Trong
phần này, chúng tôi quan tâm đến khía cạnh mức độ hình thức của ngôn ngữ
13

để phân loại các ngôn ngữ. Mức độ hình thức của một ngôn ngữ đƣợc đo dựa
trên mức độ chặt chẽ, chính xác trong định nghĩa của ngôn ngữ đó. Các ngôn
ngữ mô hình hóa có thể đƣợc phân thành 3 loại nhƣ sau [22]:
 Ngôn ngữ không hình thức: là một ngôn ngữ không đƣợc định
nghĩa một cách rõ ràng. Ngôn ngữ dạng này không định nghĩa hệ
thống các khái niệm, cú pháp và ngữ nghĩa một cách đầy đủ và
chính xác để thiết lập nên các quy luật tạo dựng các mô hình tiến
trình. Các mô hình đƣợc mô tả bởi các ngôn ngữ này có thể không
chính xác và nhập nhằng. Vì vậy chúng khó phân tích và khó vận
hành đƣợc. Các ký hiệu đƣợc dùng có thể ở dạng văn bản (ngôn
ngữ tự nhiên) hoặc ký hiệu đồ họa. Mặc dù không chính xác, nhƣng
các ngôn ngữ này có khả năng diễn đạt cao nên đƣợc dùng để mô tả
các tiến trình phức tạp, ví dụ nhƣ các mô hình tiến trình đƣợc đề
xuất trong CMMI và ISO 12207
 Ngôn ngữ bán hình thức: Các ngôn ngữ này đƣa ra một định
nghĩa rõ ràng các khái niệm của tiến trình, một cú pháp hình thức
để tạo dựng các mô hình bằng cách sử dụng các khái niệm đã đề
nghị. Ngữ nghĩa của các khái niệm cũng đƣợc định nghĩa, nhƣng
vẫn còn chƣa chính xác, chƣa hoàn chỉnh và không thực thi đƣợc.
Các ngôn ngữ này có thể hỗ trợ cho việc phân tích nhƣng không thể
cho việc giả lập hoặc thực thi tự động các mô hình tiến trình
 Ngôn ngữ hình thức: Các ngôn ngữ này xác định một cách đầy đủ
và chính xác hệ thống các khái niệm, cú pháp hình thức và ngữ
nghĩa tƣơng ứng để tạo dựng nên các mô hình tiến trình. Các mô
hình đƣợc biểu diễn bằng loại ngôn ngữ này có thể giả lập và thực
thi tự động đƣợc.

14

2.2 Ngôn ngữ BPEL
BPEL là một ngôn ngữ chuẩn dựa vào XML để phối hợp các dịch vụ
web nhằm cài đặt các tiến trình nghiệp vụ [7]. BPEL đƣợc tổ chức OASIS
chuẩn hóa lần đầu vào năm 2003. Phiên bản mới nhất của BPEL là 2.0.

2.2.1 Nguồn gốc
BPEL là kết quả hợp tác giữa hai công ty Microsoft và IBM trong nỗ lực
tìm tiếng nói chung khi biểu diễn tiến trình nghiệp vụ. Trƣớc đó, Mircrosoft
và IBM đều xây dựng riêng hai ngôn ngữ WSFL và XLANG. Kết quả hợp
tác cho ra đời ngôn ngữ mới gọi là BPEL4WS. Năm 2003, với sự tham gia
của BEA, SAP và Siebel System, BPEL4WS 1.1 đƣợc tổ chức OASIS chuẩn
hóa. Năm 2004, OASIS tiến hành một số cải tiến với BPEL4WS và nhất trí
đổi tên chuẩn thành WS-BPEL 2.0 nhằm phù hợp với các chuẩn về dịch vụ
web hiện có nhƣ WS-Address, WS-Policy, WS-Security… Tên gọi BPEL
đƣợc sử dụng rộng rãi hơn WS-BPEL.
BPEL là một chuẩn XML đƣợc xây dựng dựa vào WSDL (Web Service
Description Language), lƣợc đồ XML (XML Schema). WSDL dùng để mô
tả các thông điệp truyền/ nhận giữa các dịch vụ web. Lƣợc đồ XML dùng để
mô tả kiểu dữ liệu của biến, của các thông điệp.

2.2.2 Tiến trình BPEL
BPEL sử dụng các thẻ XML để mô tả tiến trình nghiệp vụ. Mỗi tiến trình
BPEL bao gồm một tập hợp các công việc (activity). Có hai loại công việc:
cơ bản và cấu trúc.
Các công việc cơ bản là các hành động không thể chia nhỏ trong một tiến
trình. Các hành động này bao gồm:
 <invoke> để gọi thực thi dịch vụ web
 <receive> để chờ nhận một thông điệp từ bên ngoài

15



 <reply> để trả lời cho lời gọi thực thi của dịch vụ web khác
 <assign> để gán giá trị cho biến
 <exit> để dừng và hủy một tiến trình đang chạy
 <throw>, <rethrow> để báo hiệu lỗi
 <wait> để tạm dừng tiến trình.
Các công việc cấu trúc dùng để qui định thứ tự thực hiện các công việc
cơ bản. Các công việc này bao gồm các cấu trúc điều khiển, bắt lỗi, phối
hợp trao đổi thông điệp giữa các thực thể tiến trình:
 Thực thi tuần tự trong BPEL đƣợc cung cấp bởi <sequence>, <if>,
<while>, <repeatUntil>, <forEach> phiên bản tuần tự
 Thực thi đồng thời giữa các công việc đƣợc cung cấp bởi <flow>
hoặc <forEach> phiên bản song song
 <pick> đƣợc dùng để cài đặt xử lý các thông điệp và sự kiện từ bên
ngoài
 <link> đƣợc định nghĩa để biểu diễn sự phụ thuộc trƣớc sau giữa
các công việc khi nhiều công việc đƣợc thực thi song song, đồng
thời cung cấp <joinCondition> để mô tả điều kiện đồng bộ các
công việc.
Tiến trình nghiệp vụ thƣờng đƣợc chạy trong một khoảng thời gian dài
với nhiều thao tác xử lý dữ liệu quan trọng ở phía khách hàng cũng nhƣ ở
phía quản trị. Lỗi xảy ra trong quá trình thực thi của tiến trình có ảnh hƣởng
rất lớn đến công việc kinh doanh vì vậy việc bắt và xử lý lỗi, thậm chí hoàn
tác là rất quan trọng. BPEL cung cấp <compensationHandler> để thực hiện
hoàn tác và <fault-Handler>, <catch>, <catchAll> để bắt và xử lý lỗi.
Cú pháp của một tiến trình BPEL đƣợc mô tả nhƣ sau [7]:
<process name="NCName" targetNamespace="anyURI"

queryLanguage="anyURI"?
expressionLanguage="anyURI"?
suppressJoinFailure="yes|no"?
exitOnStandardFault="yes|no"?