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

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

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

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

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

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

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

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

 Đố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]

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ụ,

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

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

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 (MMUML-PP) và BPEL (MMBPEL) Một mô hình tiến trình phần mềm bất

kỳ (MUML-PP) sẽ được chuyển đổi sang mô hình tiến trình nghiệp vụ (MBPEL) bằng cách xây dựng một bộ luật ATL (MATL) MATL được xây dựng dựa vào việc tìm kiếm các luật chuyển đổi từ metamodel MMUML-PP sang MMBPEL

 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

 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

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

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]

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]:

 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ữ

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

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

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

 <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

 <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"?

<! Note: At least one role must be specified >

<partnerLink name ="NCName"

<! Note: There must be at least one faultHandler >

<catch faultName ="QName"?

faultVariable ="BPELVariableName"?

( faultMessageType ="QName" | faultElement ="QName" )? >* activity

<! Note: There must be at least one onEvent or onAlarm >

<onEvent partnerLink ="NCName"

Tiến trình BPEL được chia làm hai loại: trừu tượng và thực thi được Tiến trình trừu tượng không nhằm mục đích thực thi mà chỉ phục vụ mô tả hoặc làm khuôn mẫu tiến trình Các công việc trong tiến trình trừu tượng cũng không được cài đặt chi tiết như trong tiến trình thực thi được

2.2.3 Thực thi tiến trình

Tiến trình BPEL được lưu dưới dạng một file XML và được thực thi trong các bộ máy thực thi hỗ trợ BPEL Một số các bộ máy thực thi bao gồm: ActiveVOS, Oracle Process Manager, GlassFish Server, Microsoft BizTalk Server

Một tiến trình được thực thi khi bộ máy thực thi nhận được các thông

điệp gởi đến cho tiến trình (ví dụ công việc <receive> hoặc <pick>) Nếu

chưa có một thực thể tiến trình nào đang được chạy, bộ máy thực thi sẽ tạo tự

động một thực thể với điều kiện thuộc tính createInstance phải có giá trị true Việc giao tiếp ngang hàng giữa tiến trình BPEL và các dịch vụ web

khác đóng vai trò trọng tâm trong thực thi tiến trình BPEL Do vậy, BPEL

cung cấp khả năng mô tả các mối quan hệ này với <partnerLinkType>

<partnerLinkType> xác định vai trò của hai dịch vụ khi tham gia giao tiếp với nhau, đồng thời xác định <portType> của hai dịch vụ này <portType>

chứa mô tả về các công việc mà dịch vụ web cung cấp đồng thời với kiểu thông điệp truyền/nhận gắn với các công việc này Khi một tiến trình muốn giao tiếp với một dịch vụ web khác, bắt buộc nó phải tạo một kênh giao tiếp

<partnerLink> thuộc kiểu <partnerLinkType>

Hình II-1 Mô hình thực thi của BPEL

Ví dụ sau định nghĩa một kiểu giao tiếp tên BuyerSellerLink giữa người mua (Buyer) và người bán (Seller) Thông tin về người mua được qui định bởi BuyerPortType và thông tin về người bán qui định bởi SellerPortType:

<plnk:partnerLinkType name ="BuyerSellerLink">

<plnk:role name ="Buyer" portType ="buy:BuyerPortType" />

<plnk:role name ="Seller" portType ="sell:SellerPortType" />

</plnk:partnerLinkType>

Ví dụ sau chứa thông tin về các dịch vụ mà người bán cung cấp Type) bao gồm tên dịch vụ (priceQuote), kiểu của thông điệp nhận (Item-Message) và kiểu cuả thông điệp kết quả (ItemMessage):

(SellerPort-<wsdl:portType name ="sell:SellerPortType">

<wsdl:operation name ="priceQuote">

<wsdl:input message ="sell:ItemMessage" />

<wsdl:output message ="sell:ItemQuoteMessage" />

partnerLinkType ="lns:BuyerSellerLink" myRole ="Buyer"

/>

Một tiến trình BPEL khi chạy có thể có nhiều thực thể, như vậy làm cách nào để khi một thông điệp đến được thực thể tiến trình mong muốn Ví dụ, một tiến trình mua hàng gồm nhiều bước như tính giá, lên kế hoạch sản xuất, tiến hành chuyển hàng, xuất hóa đơn… thường tốn nhiều thời gian để hoàn thành Hơn nữa khi chạy trong thực tế, nhiều thực thể của tiến trình mua hàng sẽ được tạo và chạy đồng thời, mỗi thực thể ứng với một khách hàng Trong trường hợp khách hàng A muốn hủy đơn hàng và gởi một thông điệp hủy đến tiến trình mua hàng, làm cách nào để thông điệp này đến với đúng thực thể tiến trình đang xử lý đơn hàng của A? BPEL xử lý vần đề này bằng cách chỉ ra rằng, trong mỗi thông điệp đều có chứa thông tin sẽ định danh được thực thể tiến trình Ví dụ, trong thông điệp hủy sẽ chứa thông tin về mã khách hàng, mã đơn hàng sẽ hủy, hai thông tin này giúp xác định duy nhất

tiến trình đang xử lý đơn hàng của khách BPEL sử dụng thẻ <vprop> để

quy định các thuộc tính dữ liệu trong thông điệp có thể được dùng để định danh tiến trình Trong mỗi công việc của BPEL đều có thể xác định một tập

các thuộc tính dùng để định danh tiến trình bằng thẻ <correlationset> Như

vậy khi một thông điệp đến, bộ máy thực thi sẽ lấy các giá trị thuộc tính của

thông điệp và so sánh với tập giá trị thuộc tính trong <correlationset> của

công việc đang chạy của các thực thể, nếu giá trị này trùng khớp thông điệp

sẽ được chuyển đến cho thực thể này

2.2.4 Nhận xét

Do dựa vào XML nên ngôn ngữ BPEL là một ngôn ngữ dễ đọc, dễ hiểu

Việc cung cấp các điều khiển <if>, <while>; xử lý song song và cơ chế bắt

lỗi khiến BPEL trở nên một ngôn ngữ lập trình tiến trình Hơn nữa, BPEL tận dụng được thế mạnh của các công nghệ xây dựng trên dịch vụ web Tuy nhiên, BPEL không hỗ trợ hết các mẫu điều khiển (workflow pattern) như

trộn nhiều đường thực thi mà không cần đồng bộ (multiple merges pattern)

và thực thi công việc sau khi trộn một lần không cần đồng bộ (discriminators pattern) [13] Hơn nữa BPEL không hỗ trợ đồng bộ giữa cùng một công việc trong nhiều thực thể của một tiến trình

Hiện nay, kể cả phiên bản mới nhất BPEL 2.0 cũng không có một bộ ký hiệu dùng để mô tả các công việc như UML Bộ ký hiệu này khác nhau trên mỗi công cụ mô hình Trong thực tế, trong hầu hết các tiến trình nghiệp vụ đều có sự tham gia của con người, thế nhưng BPEL thiếu các đặc tả về việc tương tác với các công việc do người đảm nhiệm Năm 2007, Active Endpoints, Adobe, BEA, IBM, Oracle và SAP đã phát hành BPEL4-PEOPLE và WS-HumanTask Đây được xem như là phần mở rộng nhằm giúp BPEL mô tả các tương tác với người WS-HumanTask xem công việc

do người đảm nhiệm cũng là một dịch vụ web WS-HumanTask cung cấp mô

tả về cú pháp, trạng thái, vai trò con người và giao thức làm việc giữa các dịch vụ này BPEL4PEOPLE cung cấp đặc tả về việc phối hợp các công việc

do người thực thi Kể từ bản 2.0, BPEL cung cấp <extensionActivity> giúp

các nhà phát triển có thể mở rộng BPEL với các thẻ tự định nghĩa Các mở rộng này sẽ được tự động bỏ qua trong các bộ máy thực thi không hỗ trợ

2.3 Ngôn ngữ UML-PP

UML-PP là ngôn ngữ mô hình thừa hưởng các khái niệm về tiến trình phần mềm từ SPEM 1.1 và tái sử dụng gói Infrastructure của UML2.0 [Hình II-2] mô tả vị trí của UML-PP trong kiến trúc MDA (Model Driven Architecture) UML-PP tuân theo meta-metamodel MOF 2.0

Ở mức M1 là một ví dụ về mô hình tác vụ Review Code được thực hiện bởi Reviewer sử dụng tham số đầu vào Code Trong khi đó ở mức M0 là một thể hiện của mô hình Review Code ở mức M1, trong đó tác vụ Review Code của dự án P được thực hiện bởi Reviewer A với tham số đầu vào là Code của Module TourBooking Điểm đặc biệt của ngôn ngữ UML-PP là hỗ trợ việc

quá trình phát triển phần mềm như lập kế hoạch, lập trình, kiểm thử… Mỗi

tác vụ có thể có nhiều bước (Step) để hoàn thành nhằm đạt một số mục tiêu nhất định (DevelopmentObjective) bằng việc sử dụng các tài nguyên trong tổ chức (Resource) và đáp ứng các điều kiện trước khi bắt đầu (Precondition)

và sau khi kết thúc (Postcondition) Vai trò là tập hợp các nhiệm vụ và kỹ

năng mà một người khi tham gia vào qui trình phần mềm phải đảm nhiệm Vai trò không những thực hiện các tác vụ mà nó còn chịu trách nhiệm cho các sản phẩm được tạo ra trong suốt quá trình phát triển phần mềm như các bản thiết kế, các mã nguồn… Các sản phẩm cần thiết trong quá trình thực

hiện một tác vụ được xem như là các tham số (TaskParameter) của tác vụ

đó Thuộc tính “direction” của TaskParameter được dùng để chỉ rõ sản phẩm

đầu vào, sản phẩm kết quả đầu ra, sản phẩm được hiệu chỉnh trong quá trình thực hiện tác vụ

Hình II-3 Metamodel biểu diễn các thành tố tiến trình trong UML-PP [6]

Nhằm tổng quát hóa tất cả các trường hợp trong thực tế, UML-PP định nghĩa ba mức trừu tượng cho các thành tố phần mềm Đó là: Abstract, General và Concrete Mức Abstract dùng để chỉ các thành tố phần mềm với mức trừu tượng cao nhất đại diện cho một thành tố phần mềm bất kỳ như Role R, Product P, Task T Mức General dùng để chỉ các thành tố phần mềm chi tiết hơn mức Abstract nhưng không cụ thể như mức Concrete Mức Concrete dùng cho các thành tố cụ thể như một vai trò cụ thể, một tác vụ cụ thể, một sản phẩm cụ thể trong một tiến trình phần mềm thực tế như vai trò

JavaTester trong tác vụ JavaCodeReview và cần có tài liệu

JavaCode-ReviewGuide để tiến hành Trong một tiến trình phần mềm, mức trừu tượng của tiến trình sẽ là mức trừu tượng cao nhất của các thành tố tiến trình

Ví dụ trong [Hình II-4] chỉ ra sản phẩm P mang mức trừu tượng Abstract,

trong khi đó sản phẩm Program mang mức trừu tượng General do nó mô tả một chương trình chung, không phụ thuộc nền tảng Trong khi đó chương trình JavaProgram trên nền tảng Java mang mức Concrete

Hình II-4 Ví dụ về các mức trừu tượng của sản phẩm [6]

2.3.2 Mô hình tiến trình

Để biểu diễn một tiến trình phần mềm, UML-PP định nghĩa mô hình tiến

trình (ProcessModel) Mỗi mô hình tiến trình bao gồm nhiều nốt (Node) được nối với nhau bởi các cạnh (Edge) UML-PP có hai góc nhìn với mô

hình tiến trình: mô hình cấu trúc và mô hình hành vi

Mô hình cấu trúc (StructruralModel) mô tả các thành phần của tiến

trình phần mềm cùng với các quan hệ giữa chúng Các nốt chính là các thành

tố tiến trình và cạnh chính là các mối quan hệ trong tiến trình Các thành tố tiến trình bao gồm sản phẩm, tác vụ, vai trò thậm chí là các mẫu tiến trình

Các mối quan hệ trong tiến trình bao gồm quan hệ kết hợp (Aggregation),

làm rõ (Refinement), tham số (TaskParameter), thứ tự (TaskPrecedence), ảnh hưởng (ProductImpact)

Hình II-5 Metamodel của mô hình cấu trúc UML-PP [6]

[Hình II-6] mô tả một ví dụ về mô hình cấu trúc của tiến trình kiểm thử (Test) Tác vụ Test với ba tác vụ con: Anyalyze Required Tests, Design Tests và Conduct Tests Mô hình này chỉ rõ được các vai trò chịu trách nhiệm thực hiện các tác vụ và các sản phẩm được xử lý tương ứng Mô hình này cũng mô tả sự phụ thuộc thứ tự giữa các tác vụ (FS – Finish To Start), cấu trúc của các sản phẩm Ví dụ sản phẩm Test Design Document bao gồm bốn sản phẩm con: Plan Test, Test Interfaces, Test Strategy và Test Structure Ngoài ra ví dụ cũng mô tả được sự phụ thuộc giữa các sản phẩm như ảnh hưởng giữa Test Requirement và Test Design Document

hoặc một mô hình tiến trình (ProcessModel)

Hình II-7 Metamodel của mô hình hành vi UML-PP [6]

[Hình II-8] chứa ví dụ mô tả về các tác vụ trong quá trình Phân tích sơ bộ yêu cầu phần mềm Đây là quá trình chứa các tác vụ ở mức trừu tƣợng Genernal Tác vụ Draft Owner Models và Define User Requirement đƣợc thực thi đồng thời Tác vụ Define User Requirement bao gồm các Step theo tuần tự Consider user interface aspects, Consider distribution aspects và Explore with prototypes

dạng mô-đun có thể sử dụng ngay trong mô hình tiến trình, UML-PP giúp việc tái sử dụng mẫu tiến trình trở nên dễ dàng hơn Mô hình mẫu tiến trình

của UML-PP bao gồm một vấn đề (ProcessProblem), một mô hình giải pháp cho vấn đề trên (ProcessModel) và các ngữ cảnh (ProcessContext) để áp

dụng UML-PP cung cấp ba mức trừu tượng Abtract, General và Concrete cho mẫu tiến trình

Hình II-9 Metamodel của mẫu tiến trình UML-PP [6]

Vấn đề (PatternProblem) diễn tả mục tiêu giải quyết của một mẫu tiến trình Một vấn đề có thể được chia nhỏ thành nhiều vấn đề con (SubProblem)

và để xử lý một vấn đề lớn người ta cần phải xử lý tất cả các vấn đề con tương ứng của nó Ngữ cảnh của một mẫu tiến trình bao gồm các ràng buộc

(ApplicationConstraint) nhằm mô tả điều kiện cần có thể áp dụng mẫu tiến trình (InitialContext), điều kiện về các kết quả (ResultingContext) và bản mô

tả tình huống sử dụng lại mẫu tiến trình (ReuseSituation) Trong phần lớn các

trường hợp, các điều kiện ở đây là các ràng buộc về sản phẩm hoặc các ràng buộc liên quan đến các tài nguyên và môi trường phát triển (người tham gia, giới hạn thời gian, cơ sở hạ tầng của dự án ) Giải pháp cho một mẫu tiến trình được mô tả bởi một mô hình tiến trình, mức độ trừu tượng của mô hình tiến trình này có thể thay đổi tùy theo vấn đề mà nó giải quyết

Để mô tả việc sử dụng mẫu tiến trình trong các mô hình tiến trình, UML-PP

đề xuất hai quan hệ là ProcessPatternBinding và ProcessPatternApplying

ProcessPatternBinding Trong quan hệ binding, mô hình tiến trình giải pháp

của mẫu tiến trình sẽ được sao chép để tạo thành nội dung của một thành tố thông qua việc thực hiện thay thế các tham số hình thức bằng các tham số thực tương ứng Để cho phép việc phát sinh các thành tố mới, một quan hệ

ProcessPatternBinding có thể chấp nhận các tham số thực là các thành tố

chưa tồn tại, và được khai báo dưới dạng các biểu thức chuỗi

Hình II-10 Ví dụ về quan hệ ProcessPatternBinding [6]

Trong ví dụ ở [Hình II-10], tác vụ DesignReview được bind với mẫu tiến trình FaganInspection – một mẫu được dùng để review sản phẩm Các tham

số qui định việc thay thế các tác vụ tương ứng trong mẫu tiến trình Ví dụ như sản phẩm Artifact được thay thế bằng DesignModel, công đoạn Preparation sẽ được hủy bỏ Kết quả sau khi áp dụng quan hệ binding ta sẽ được tiến trình như [Hình II-11]

tiến trình cũng sẽ bị thay đổi theo Với kiểu quan hệ mở rộng hoặc thay thế, tiến trình ban đầu sẽ đƣợc hợp nhất với mẫu tiến trình Nếu có sự xung đột giữa các thành tố tiến trình ban đầu và thành tố mẫu tiến trình, kiểu quan hệ

mở rộng sẽ giữ lại các thành tố tiến trình ban đầu trong tiến trình kết quả; trong khi đó quan hệ thay thế sẽ loại bỏ các thành tố tiến trình này

Hình II-12 Ví dụ sử dụng quan hệ applying để tái tổ chức tiến trình [6]

Trong ví dụ ở [Hình II-12], mẫu tiến trình FeedbackDevelopment đƣợc dùng

để tái tổ chức lại quá trình từ thu thập đến phân tích yêu cầu và quá trình lập trình đến tích hợp, kiểm thử Việc tái tổ chức đƣợc mô tả bởi sự cấu trúc các thành tố tiến trình sử dụng cấu trúc của mẫu tiến trình và sự mô tả các tham

số hình thức [Hình II-13] là tiến trình kết quả sau khi áp dụng quan hệ applying

khác là cung cấp nhiều mức trừu tượng cho một thành tố phần mềm (Abstract, General, Concrete) Nhờ vậy một mô hình có thể dùng làm khuôn mẫu kham khảo hoặc dùng để ghi lại một tiến trình thực tế Bên cạnh đó UML-PP còn có thể biểu diễn các mẫu tiến trình phục vụ cho mục đích sử dụng lại Với hai phương pháp sử dụng lại là applying và binding, việc tận dụng các mẫu tiến trình trở nên dễ dàng hơn bao giờ hết

Tuy nhiên UML-PP có một số các điểm hạn chế nhất định UML-PP không phân biệt được các hoạt động của người và các hoạt động có thể tự động Việc phân biệt hai loại hoạt động này là cần thiết nếu ta muốn hỗ trợ thực thi tự động tiến trình Hơn nữa, tuy UML-PP cung cấp mức trừu tượng Concrete để biểu diễn các hành động có thể thực thi được nhưng lại thiếu công cụ để mô tả ngữ nghĩa thực thi của các hoạt động này UML-PP tận dụng được sơ đồ hoạt động của UML để biểu diễn khía cạnh động của tiến trình nhưng sơ đồ hoạt động của UML-PP không biểu diễn được Role, Resource, Tools… Một điểm quan trọng là UML-PP là một ngôn ngữ hoàn toàn mới nên chưa có công cụ mô hình và chưa có bộ máy thực thi

2.4 Các phương pháp chuyển đổi mô hình

MDA đã cung cấp hướng tiếp cận mới cho công nghệ phần mềm với hướng tiếp cận sử dụng mô hình như đối tượng trung tâm của quá trình phát triển MDA cho phép [14]:

 Xác định phần độc lập giữa hệ thống và platform

 Xác định phần phụ thuộc platform

 Chọn một platform chuyên biệt mà hệ thống phụ thuộc

 Chuyển đổi hệ thống từ đặc tả platform này sang đặc tả ở platform khác

Quá trình phát triển phần mềm bao gồm một loạt các phép biến đổi mô hình từ mức trừu tượng cao đến mức trừu tượng thấp hơn, sau cùng là