Luận văn thạc sĩ công nghệ thông tin mở rộng công cụ activiti cho đặc tả và cài đặt chính sách an ninh

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐỖ ANH VIỆT

MỞ RỘNG CÔNG CỤ ACTIVITI CHO
ĐẶC TẢ VÀ CÀI ĐẶT CHÍNH SÁCH AN NINH
Ngành: Công nghệ Thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60480103

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. ĐẶNG ĐỨC HẠNH

Hà Nội – 2018
L


LỜI CAM ĐOAN
Tôi xin cam đoan luận văn thạc sĩ “Mở rộng công cụ Activiti cho đặc tả và cài
đặt chính sách an ninh” là công trình nghiên cứu của riêng tôi và được sự hướng dẫn
của TS. Đặng Đức Hạnh. Các nội dung nghiên cứu và kết quả trong đề tài là trung
thực và chưa từng được ai công bố trong bất kỳ công trình nào khác.
Những phân tích, đánh giá được tác giả thu thập từ các nguồn khác nhau có ghi rõ
trong tài liệu tham khảo.

Học viên thực hiện

Đỗ Anh Việt

i


LỜI CẢM ƠN
Để hoàn thành được luận văn thạc sĩ, bên cạnh sự nỗ lực của bản thân còn có sự
hướng dẫn nhiệt tình của quý Thầy Cô, cũng như sự động viên ủng hộ của gia đình và
bạn bè trong suốt quá trình nghiên cứu và thực hiện luận văn.
Tôi xin chân thành bày tỏ lòng biết ơn sâu sắc đến Thầy TS. Đặng Đức Hạnh,
người đã tận tình hướng dẫn và tạo mọi điều kiện tốt nhất cho tôi hoàn thành luận văn
này. Xin chân thành cảm ơn các thầy cô khoa Công nghệ thông tin, Trường đại học
Công Nghệ đã truyền đạt những kiến thức quý báu cũng như giúp đỡ tôi trong quá
trình học tập nghiên cứu tại trường.
Xin chân thành cảm ơn Trung tâm Tư vấn Thiết kế Mobifone đã cho phép và
tạo điều kiện để triển khai kết quả nghiên cứu của luận văn.
Cuối cùng, xin gửi lời cảm ơn đến gia đình, bạn bè, đồng nghiệp, những người
đã hỗ trợ tôi trong suốt quá trình học tập, nghiên cứu và thực hiện luận văn.
Học viên thực hiện

Đỗ Anh Việt

ii


MỤC LỤC
Trang

LỜI CAM ĐOAN ....................................................................................................................... i
LỜI CẢM ƠN ............................................................................................................................. ii
MỤC LỤC ................................................................................................................................... iii
DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT ................................................... v

DANH SÁCH CÁC HÌNH VẼ............................................................................................. vi
MỞ ĐẦU ...................................................................................................................................... 1
CHƯƠNG 1. KIẾN THỨC NỀN TẢNG ........................................................................... 3
1.1.

Giới thiệu chương ........................................................................................... 3

1.2. Mô hình hóa chuyên biệt miền ........................................................................... 3
1.2.1. Khái niệm .................................................................................................... 3
1.2.2. Ngôn ngữ mô hình hóa chuyên biệt miền..................................................... 6
1.3. Mô hình hóa đặc tả chính sách truy nhập RBAC ................................................ 8
1.3.1. RBAC và các ràng buộc phân quyền............................................................ 8
1.3.2. MetaModel cho RBAC .............................................................................. 10
1.4. Mô hình hóa và thực thi quy trình nghiệp vụ với Activiti ................................. 11
1.4.1. Mô hình hóa quy trình nghiệp vụ ............................................................... 12
1.4.2. Công cụ Activiti ........................................................................................ 17
1.5. Kết luận chương .............................................................................................. 20

CHƯƠNG 2. TÍCH HỢP MÔ ĐUN CHÍNH SÁCH TRUY CẬP RBAC VỚI
ACTIVITI ....................................................................................................................................21
2.1. Giới thiệu chương ............................................................................................ 21
2.2. Phương pháp tích hợp RBAC vào BPM ........................................................... 21
2.3. Tích hợp RBAC vào Activiti BPM .................................................................. 24
2.3.1. Một số khái niệm ....................................................................................... 24
2.3.2. Mô hình hóa các chính sách truy nhập RBAC............................................ 26
2.4.3. Thực thi các chính sách truy nhập RBAC .................................................. 32
2.4. Tổng kết chương.............................................................................................. 33

iii

CHƯƠNG 3. CÀI ĐẶT VÀ THỰC NGHIỆM ...............................................................35
3.1. Giới thiệu chương ............................................................................................ 35
3.2. Bài toán vận tải ................................................................................................ 35
3.3. Cài đặt trên Activiti ......................................................................................... 36
3.3.1. Cài đặt Activiti BPM ................................................................................. 36
3.3.2. Mô hình hóa quy trình trên Activiti Designer............................................. 38
3.3.3. Triển khai quy trình trên Activiti Explorer ................................................. 44
3.4. Kết quả thực nghiệm ........................................................................................ 45
3.5. Tổng kết chương.............................................................................................. 49

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN ........................................................................50
TÀI LIỆU THAM KHẢO ......................................................................................................51

iv


DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT
Từ viết tắt

Thuật ngữ

Ý nghĩa

API

Application Programming Interface

BoD

Binding Of Duty

BPM

Business Process Management

BPMN
DSM
DSML
EMF
PEP
SoA
SLA
SoD

Business Process Model and Notation
Domain-Specific Modeling
Domain-Specific Modeling Language
Eclipse Model Framework
Policy Enforcement Point
Service Oriented Architecture
Service-level agreement
Separation Of Duty

RBAC

Role-Based Access Control

REST

REpresentational State Transfer

WSBPEL
XACML

Giao diện lập trình ứng dụng
Ràng buộc các nhiệm vụ được
thực hiện bởi một người
Quản lý quy trình nghiệp vụ
Tiêu chuẩn và mô hình quy trình
nghiệp vụ
Mô hình hóa chuyên biệt miền
Ngôn ngữ mô hình hóa chuyên
biệt miền
Nền tảng mô hình hóa Eclipse
Điểm thực thi chính sách
Kiến trúc hướng dịch vụ
Cam kết chất lượng dịch vụ
Tách biệt nhiệm vụ
Điều khiển truy cập dựa theo vai
trò

Web Services Business Process Ngôn ngữ thực thi quy trình
Execution Language
nghiệp vụ bằng Web services
eXtensible Access Control Markup
Language

v

DANH SÁCH CÁC HÌNH VẼ
Hình 1.1: Thu hẹp khoảng cách trừu tượng giữa ý tưởng miền và cài đặt của chúng
Hình 1.2: Kiến trúc cơ bản của DSM
Hình 1.3: Core RBAC
Hình 1.4: MetaModel của RBAC
Hình 1.5: MetaModel 2 của RBAC
Hình 1.6: Quy trình nghiệp vụ
Hình 1.7: Vòng đời BPM
Hình 1.8: Metamodel của BPMN
Hình 1.9: Các thành phần của Activiti
Hình 1.10: Các thành phần của Activiti Engine

Hình 2.1: Yêu cầu an ninh kết hợp với ký hiệu
Hình 2.2: Metamodel của BPMN tích hợp với một số chính sách an ninh
Hình 2.3: Ecore Diagram của RBAC trong Eclipse
Hình 2.4: Mô hình Ecore của RBAC thu được từ EcoreDiagram
Hình 2.5: Lớp JAVA được sinh ra từ mô hình
Hình 2.6: Tab Security trong Patelle
Hình 2.7: Tab Security trong Properties

Hình 3.1: Cơ cấu tổ chức trung tâm Tư vấn Thiết kế
Hình 3.2: Màn hình đăng nhập Activiti Designer
Hình 3.3: Màn hình quản lý Task trên Activiti Designer
Hình 3.4: Màn hình quản lý Process trên Activiti Designer
Hình 3.5: Màn hình quản lý cấu hình trên Activiti Designer
Hình 3.6: Tạo dự án Activti BPM trên Eclipse
Hình 3.7: Tạo sơ đồ Activiti Diagram trên Eclipse
Hình 3.8: Visual Editor của Activiti
Hình 3.9: Quy trình điều xe trên Activiti Designer

Hình 3.10: Khai báo các data objects của quy trình điều xe
Hình 3.11: Cấu hình rẽ nhánh cho Gateway
vi


Hình 3.12: Cấu hình kết quả phê duyệt của Manager Approval
Hình 3.13: Cấu hình Security cho Manager Approval
Hình 3.14: Cấu hình SeparationOfDuty
Hình 3.15: Cấu hình Form thông tin của CarSupervisor Approval
Hình 3.16: Cấu hình MailTask
Hình 3.17: Tạo nhóm người dùng trên Activiti Explorer
Hình 3.18: Tạo người dùng trên Activiti Explorer
Hình 3.19: Triển khai quy trình trên Activit Explorer
Hình 3.20: Biểu mẫu thông tin yêu cầu
Hình 3.21: Màn hình Task Manager Approval
Hình 3.22: Thông báo vi phạm chính sách RBAC
Hình 3.23: Chọn người thực hiện Task
Hình 3.24: Thực hiện phê duyệt yêu cầu
Hình 3.25: Mail thông báo kết quả phê duyệt
Hình 3.26: Thống kê số lần quy trình được thực hiện theo tháng

vii


MỞ ĐẦU
Quy trình nghiệp vụ đóng một vai trò then chốt để doanh nghiệp có thể quản lý
và vận hành một cách nhịp nhàng, đạt hiệu quả cao. Có thể khẳng định, một doanh
nghiệp xây dựng được quy trình tốt sẽ phát triển bền vững và có tính cạnh tranh cao
hơn Để có thể triển khai thì trước tiên quy trình nghiệp vụ phải được mô hình hóa. Mô
hình hóa quy trình nghiệp vụ không những được sử dụng trong việc trao đổi các yêu

cầu giữa chuyên gia nghiệp vụ và chuyên gia hệ thống mà còn được sử dụng để cài đặt
hệ thống thực tế. Các quy trình nghiệp vụ hiện đại thường kết hợp các tác vụ của con
người với các tác vụ tự động (ví dụ, được cài đặt bởi webservice), nên ngôn ngữ mô
hình hóa quy trình nghiệp vụ cần phải thu hẹp khoảng cách giữa giữa chuyên gia
nghiệp vụ và chuyên gia hệ thống [2].
Mô hình hóa quy trình nghiệp vụ thường tập trung vào mô hình hóa chính xác
chức năng của quy trình mà bỏ qua các yêu cầu về an ninh. Nguyên nhân chủ yếu là do
thực tế rằng các chuyên gia trong lĩnh vực quy trình nghiệp vụ không phải là chuyên
gia về an ninh. Các yêu cầu về an ninh thường xuyên được xem xét sau khi định nghĩa
hệ thống. Cách tiếp cận này dẫn đến các lỗ hổng an ninh và rõ ràng cần thiết phải tăng
cường nỗ lực an ninh trong các giai đoạn trước phát triển do việc sửa lỗi sẽ hiệu quả và
tiết kiệm chi phí hơn. Các nghiên cứu thực nghiệm cho thấy tại mức thiết kế quy trình
nghiệp vụ thì khách hàng và người dùng cuối có thể biểu diễn các yêu cầu an ninh của
họ và sau đó có thể thể hiện tại mức cao, các yêu cầu an ninh dễ dàng xác định bởi
người mô hình hóa quy trình nghiệp vụ [2].
Các yêu cầu an ninh có thể được mô hình hóa trong quy trình nghiệp vụ và cần
thiết phải xem xét các yêu cầu an ninh này trong bất kì ứng dụng nào tại mức độ trừu
tượng cao nhất. Một trong các yêu cầu an ninh là điều khiển truy nhập tức là kiểm soát
việc truy cập và thực hiện các hành động trên các nguồn tài nguyên hệ thống được
được bảo vệ. RBAC (Role-Based Access Control) điều khiển truy cập theo vai trò là
một phương pháp điều khiển truy cập hiệu quả nhất hiện nay [3,4]. Tuy nhiên, các nền
tảng cho phép mô hình hóa quy trình nghiệp vụ hiện nay như Oracle BPM, Acitivi
BPM đều chưa tích hợp đầy đủ điều khiển truy cập theo vai trò RBAC [5]. Chính vì
vậy, tôi xin chọn đề tài “Mở rộng công cụ Activiti cho đặc tả và cài đặt chính sách
an ninh”.
Trong luận văn, tôi đã trình bày một phương pháp tích hợp chính sách an ninh
RBAC vào quy trình nghiệp vụ BPM bằng cách mở rộng tiêu chuẩn BPMN cho đặc tả
các chính sách an ninh [2], đồng thời ứng dụng của phương pháp này vào việc mở
rộng công cụ Activiti BPM cho đặc tả và cài đặt RBAC dựa vào [5]. Kết quả cụ thể đạt
được: thứ nhất, tích hợp các chính sách RBAC vào pha mô hình hóa để các yêu cầu an

ninh có thể được xem xét ngay từ đầu. Thứ hai, đã kiểm tra các chính sách đó tại pha
thực thi để đảm bảo an toàn an ninh cho hệ thống.
1


Về phần bố cục, luận văn được chia thành 3 chương chính như sau:
Chương 1. Kiến thức nền tảng : Trình bày cơ sở lý thuyết và các công nghệ
chính được sử dụng trong luận văn. Bao gồm: Mô hình hóa chuyên biệt miền, mô hình
hóa đặc tả chính sách truy cập RBAC, mô hình hóa quy trình nghiệp vụ và cuối cùng,
giới thiệu về công cụ mã nguồn mở Activiti BPM
Chương 2. Tích hợp mô đun chính sách truy cập RBAC với Activiti : Trình
bày phương pháp tích hợp chính sách an ninh vào quy trình nghiệp vụ và ứng dụng của
phương pháp vào việc tích hợp chính sách truy cập RBAC vào Activiti BPM
Chương 3. Cài đặt và thực nghiệm : Trình bày bài toán vận tải hiện đang được
triển khai tại Trung tâm Tư vấn Thiết kế Mobifone, ứng dụng kết quả của luận văn để
giải quyết bài toán và cài đặt trên Activiti BPM. Cuối cùng là các kết quả đạt được.

2


CHƯƠNG 1. KIẾN THỨC NỀN TẢNG
1.1.

Giới thiệu chương

Chương này sẽ trình bày cơ sở lý thuyết và các công nghệ chính được sử dụng
trong luận văn. Bao gồm ba nội dung chính là:
 Mô hình hóa chuyên biệt miền: các khái niệm và kiến trúc của DSM; cú pháp và
ngữ nghĩa của một ngôn ngữ mô hình hóa chuyên biệt miền DMSL.
 Mô hình hóa và đặc tả chính sách truy cập RBAC: các khái niệm cơ bản về Core

RBAC và ràng buộc phân quyền. Từ đó, xây dựng mô hình metamodel cho RBAC.
 Mô hình hóa và thực thi quy trình nghiệp vụ với Activiti BPM: khái niệm, thành
phần, vòng đời và tiêu chuẩn ký hiệu BPMN của quy trình nghiệp vụ. Cuối cùng,
giới thiệu công cụ mã nguồn mở Activti BPM cho việc mô hình hóa và thực thi quy
trình nghiệp vụ một cách tự động.

1.2. Mô hình hóa chuyên biệt miền
Các hệ thống phần mềm hiện nay ngày càng trở nên phức tạp, muốn cải thiện
hiệu suất phát triển phần mềm không chỉ tốc độ mà còn chất lượng hệ thống được tạo
ra, các nhà nghiên cứu đã cố gắng tìm ra một phương pháp tự động chuyển từ mô hình
sang code. Do đó, mô hình hóa chuyên biệt miền (DSM) đã ra đời. DSM sử dụng một
ngôn ngữ mô hình hóa chuyên biệt miền (DSML) để sinh code đầy đủ từ mô hình và
code được sinh ra có ít lỗi hơn là code viết bằng tay [6].

1.2.1. Khái niệm
DSM chủ yếu tập trung vào hai vấn đề. Đầu tiên, nâng cao mức độ trừu tượng
trên cả lập trình bằng cách xác định một ngôn ngữ trực tiếp sử dụng các khái niệm và
các luật từ miền vấn đề cụ thể. Thứ hai, tạo ra sản phẩm cuối cùng trong một ngôn ngữ
lập trình đã chọn hoặc một hình thức khác từ các đặc tả mức cao đó. Thông thường, bộ
sinh code tiếp tục được hỗ trợ bởi một số nền tảng (framework). Tự động hóa phát
triển phần mềm có thể trở nên phổ biến bởi vì ngôn ngữ mô hình hóa, bộ sinh code và
code của framework đã phù hợp với các yêu cầu của miền ứng dụng. Nói cách khác
chúng là chuyên biệt miền và chúng hoàn toàn được kiểm soát bởi người dùng.
Các mức độ trừu tượng cao
Sự trừu tượng rất quan trọng trong phát triển phần mềm. Trong suốt lịch sử phát
triển phần mềm, nâng cao mức độ trừu tượng là nguyên nhân của các bước nhảy vọt
trong hiệu suất của nhà phát triển. Nếu nâng cao mức độ trừu tượng làm giảm tính
phức tạp thì làm sao để tiếp tục nâng cao nó. Hình 1.1 thể hiện, các nhà phát triển tại
3

các thời điểm khác nhau đã thu hẹp khoảng cách trừu tượng giữa ý tưởng trong miền
và cài đặt của chúng.

Hình 1.1: Thu hẹp khoảng cách trừu tượng giữa ý tưởng miền và cài đặt của chúng
Bước đầu tiên trong phát triển bất kỳ phần mềm nào luôn là nghĩ về giải pháp liên
quan đến miền vấn đề - một giải pháp ở mức độ trừu tượng cao nhất (bước 1). Ví dụ,
quyết định nên hỏi tên người trước hay hỏi phương thức thanh toán trước trong khi
đăng ký một hội thảo. Sau khi tìm ra giải pháp sẽ ánh xạ sang đặc tả của một số ngôn
ngữ (bước 2). Trong lập trình truyền thống, bước này các nhà phát triển ánh xạ các
khái niệm miền vào việc code các khái niệm. Trong UML hoặc các ngôn ngữ mô hình
hóa mục đích chung khác, các nhà phát triển ánh xạ giải pháp miền vấn đề vào đặc tả
trong ngôn ngữ mô hình hóa. Bước 3, cài đặt đầy đủ giải pháp: đưa ra các điều kiện
đúng và nội dung code cho các vòng lặp. Tuy nhiên, nếu sử dụng các ngôn ngữ mô
hình hóa mục đích chung, thì cần ánh xạ bổ sung từ mô hình sang code. Điều đáng chú
nhất ở đây là các nhà phát triển vẫn phải thực hiện từ bước 1 mà không có bất kì công
cụ nào hỗ trợ, đặc biệt để giải quyết các lỗi phát sinh trong giai đoạn phát triển thường
tốn nhiều chi phí nhất.
Tự động sinh code
Trong bước 3, việc sinh code tự động từ thiết kế UML là không thể. Thay vì yêu
cầu nhà phát triển nắm vững cả miền vấn đề và lập trình, một giải pháp tốt hơn cho
phép các nhà phát triển đặc tả ứng dụng dưới dạng đã từng biết và sử dụng, sau đó có
các bộ sinh code sử dụng các đặc tả đó và tạo ra cùng loại code giống như họ viết bằng
tay. Điều này sẽ làm tăng mức độ trừu tượng đáng kể; từ việc lập trình với byte/bit,
thuộc tính và kết quả trả về; lên đến các khái niệm và luật lệ của miền vấn đề mà các
nhà phát triển đang làm việc với. Sau đó, ngôn ngữ lập trình mới này hợp nhất với
bước 1 và bước 2 và tự động hóa hoàn toàn ở bước 3. Mức độ trừu tượng được nâng
lên gắn liền với code được sinh tự động là mục đích của DSM.
4

DSM không kỳ vọng rằng tất cả code có thể được sinh ra từ các mô hình nhưng bất cứ
gì mô hình hóa được từ quan điểm của người mô hình hóa thì đều sinh ra code hoàn
chỉnh. Trong DSM, code được sinh ra dễ đọc và hiệu quả - lý tưởng là giống như code
được viết bởi những nhà phát triển giàu kinh nghiệm, những người định nghĩa ra bộ
sinh code. Code được sinh ra thường được hỗ trợ bởi framework với mục đích nhất
định cũng như bởi các nền tảng, thư viện, thành phần và các code kế thừa khác. Bộ
sinh code không chỉ giới hạn bất kì ngôn ngữ hay kiểu lập trình nào. Ví dụ kết quả của
bộ sinh code có thể là ngôn ngữ lập trình hướng đối tượng hoặc ngôn ngữ lập trình cấu
trúc hay chức năng, nó có thể là ngôn ngữ lập trình truyền thống, một ngôn ngữ kịch
bản, các định nghĩa dữ liệu hoặc một file cấu hình.
Tóm lại, DSM về cơ bản nâng cao mức độ trừu tượng trong khi thu hẹp không
gian thiết kế (thường là các sản phẩm trong một công ty). Cùng với ngôn ngữ mô hình
hóa chuyên biệt miền DSML, vấn đề sẽ được giải quyết khi việc mô hình hóa trực
quan giải pháp mà chỉ sử dụng các khái niệm miền quen thuộc. Sản phẩm cuối cùng
được sinh tự động bởi các bộ sinh code chuyên biệt miền. Với DSM, không cần ánh xạ
từ khái niệm miền sang khái niệm thiết kế và cuối cùng sang khái niệm ngôn ngữ lập
trình. DSM tuân theo công thức: cung cấp mức độ trừu tượng cao hơn và thực hiện ánh
xạ tự động từ các khái niệm mức cao hơn sang các khái niệm mức thấp hơn đã biết và
sử dụng trước đó.
Kiến trúc của DSM gồm 3 thành phần chính là ngôn ngữ, bộ sinh code và
framework miền như hình 1.2 :

Hình 1.2: Kiến trúc cơ bản của DSM
Ngôn ngữ chuyên biệt miền : cung cấp cơ chế trừu tượng để giải quyết sự phức tạp của
miền cho trước. Điều này được thực hiện bằng cách cung cấp các khái niệm và các luật
trong một ngôn ngữ biểu diễn miền ứng dụng hơn là các khái niệm của một ngôn ngữ
5

lập trình nhất định. Nhìn chung, các khái niệm miền chính ánh xạ lên các đối tượng
của ngôn ngữ mô hình hóa, trong khi các khái niệm miền khác sẽ được coi như thuộc
tính đối tượng, các kết nối, các mô hình con hoặc các đường dẫn đến mô hình. Bởi
vậy, ngôn ngữ này cho phép nhà phát triển làm việc trực tiếp với các khái niệm miền.
Ngôn ngữ này được định nghĩa như một metamodel với các ký hiệu và công cụ hỗ trợ.
Bộ sinh code xác định làm sao thông tin được lấy ra từ mô hình và chuyển đổi sang
code. Trong trường hợp đơn giản nhất, mỗi symbol (ký tự) mô hình hóa tạo ra code
nhất định, bao gồm các giá trị được nhập vào trong symbol là các tham số. Bộ sinh
code cũng có thể tạo ra các code khác nhau phụ thuộc vào các giá trị trong symbol, các
mối quan hệ nó có với các symbol khác, hoặc thông tin khác trong mô hình. Code này
sẽ được liên kết với framework và được biên dịch thành mã thực thi hoàn chỉnh. Trong
giải pháp DSM, mục tiêu chính là sau khi sinh code không cần bổ sung code bằng tay
để thay đổi và mở rộng code đã sinh. Bởi vậy, code đã sinh chỉ đơn giản là một sản
phẩm trung gian trên con đường đưa ra sản phẩm cuối cùng.
Framework miền: cung cấp giao diện giữa code được sinh ra và các nền tảng phía
dưới. Trong một số trường hợp, không cần thêm code của framework: code sinh ra có
thể trực tiếp gọi các thành phần nền tảng nếu nó có đủ các dịch vụ. Mặc dù vậy, việc
định nghĩa code hoặc thành phần tiện ích bổ sung giúp code sinh ra dễ dàng hơn.
Code sinh ra không được thực hiện một mình mà còn cùng với code thêm vào trong
một số môi trường đích. Điều này được sử dụng bất kể việc cài đặt được thực hiện như
thế nào, bằng tay hay sử dụng các bộ sinh. Sản phẩm đã phát triển có thể sử dụng một
phần của một nền tảng lớn (như J2EE), toàn bộ nền tảng (như Tomcat server) hay một
số nền tảng khác.

1.2.2. Ngôn ngữ mô hình hóa chuyên biệt miền
Ngôn ngữ chuyên biệt miền (DSL) là một ngôn ngữ lập trình hoặc một ngôn ngữ
đặc tả thực thi, thông qua các ký hiệu thích hợp và trừu tượng, tập trung vào biểu diễn;
và thường được giới hạn trong một miền cụ thể. DSL làm tăng mức độ trừu tượng
bằng cách sử dụng các khái niệm quen thuộc với chuyên gia miền. Trong mô hình hóa
chuyên biệt miền, DSL được gọi là DSML được sử dụng cho việc xây dựng mô hình

đồ họa cho một hệ thống phần mềm.
DSML thường gồm cú pháp (syntax) và ngữ nghĩa (semantics). Cú pháp bao gồm cú
pháp trừu tượng (abstract syntax) và cú pháp cụ thể (concrete syntax). Cú pháp trừu
tượng biểu thị cấu trúc và các quy tắc ngữ pháp của một ngôn ngữ. Trong khi cú pháp
cụ thể giải quyết các symbol ký hiệu và các biểu mẫu hiển thị mà ngôn ngữ sử dụng.
Còn ngữ nghĩa biểu diễn ý nghĩa của các cụm từ và câu mà chuyên gia miền muốn
diễn đạt. Để tăng sự trừu tượng thiết kế, cần mở rộng cả cú pháp và ngữ nghĩa.
6


Cú pháp
Cú pháp định nghĩa các thành phần hợp lệ trong một ngôn ngữ nhất định. Tuy
nhiên, tự nó không liên quan đến cấu trúc có ý nghĩa gì. Cú pháp chỉ xác định một cấu
trúc có hợp lệ nhưng nó có thể có ngữ nghĩa không hợp lệ.
Cú pháp trừu tượng: xác định cấu trúc khái niệm của một ngôn ngữ: cấu trúc của một
ngôn ngữ mô hình hóa, các thuộc tính của nó và các kết nối của chúng với nhau. Cú
pháp của một ngôn ngữ chuyên biệt miền có ý nghĩa không chỉ là các từ dành riêng mà
thường được xem như các quy tắc (rule) ngữ pháp cần được tuân theo trong khi xác
định mô hình. Các quy tắc này bắt nguồn từ miền và chúng ràng buộc việc mô hình
được tạo ra như thế nào: định nghĩa các giá trị, các mối quan hệ giữa các khái niệm và
các khái niệm nhất định được sử dụng như thế nào. Một khi các quy tắc được định
nghĩa, ngôn ngữ mô hình hóa của công cụ hỗ trợ sẽ đảm bảo tất cả các nhà phát triển
tuân theo cùng các quy tắc đó trong miền. Việc có các quy tắc sẽ giảm đáng kể không
gian thiết kế, giúp cho cài đặt của bộ sinh trở nên dễ dàng hơn do các bộ sinh không
cần bắt đầu bằng việc kiểm tra lại tính chính xác của mô hình. Trong DSM, các quy
tắc được kiểm tra sớm nhất có thể bởi vì việc phát hiện và ngăn nữa lỗi ở mô hình sẽ
đơn giản và hiệu quả chi phí hơn việc tìm lỗi trong code đã sinh.
Ngôn ngữ metamodel được sử dụng để xác định cú pháp trừu tượng của ngôn ngữ mô
hình hóa. Một metamodel là một mô hình của ngôn ngữ mô hình hóa chứa tất cả các
thuộc tính và tính năng cần thiết bao gồm các khái niệm ngôn ngữ mà nó hỗ trợ, cú

pháp và ngữ nghĩa.
Cú pháp cụ thể: Cú pháp và ngữ nghĩa thuần không đủ cho việc định nghĩa ngôn ngữ:
mô hình phải được truy cập thông qua một vài dạng trực quan. Cú pháp cụ thể xác
định các thành phần từ cú pháp trừu tượng được biểu diễn trực quan như thế nào. Mỗi
ngôn ngữ mô hình hóa tuân theo một số dạng biểu diễn cũng với một ký hiệu. Dạng
biểu diễn của hầu hết các ngôn ngữ mô hình hóa là đồ họa kết hợp với text. Các ngôn
ngữ mô hình hóa cũng có thể dựa trên các dạng khác như ma trận, bảng biểu và các
biểu mẫu hoặc là văn bản thuần túy. Lựa chọn ký hiệu cho ngôn ngữ DSM nên gắn
liền với biểu diễn thực tế của các khái niệm miền, ví dụ nút điều khiển trong hệ thống
giải trí xe nên giống với nút điều khiển trong ngôn ngữ mô hình hóa. Một cách lý
tưởng, mỗi khái niệm trong ngôn ngữ mô hình hóa nên có ký hiệu biểu diễn chính xác
nó. Nguyên tắc này tối thiểu hóa sự quá tải các ký tự và đảm bảo rằng tất cả các khái
niệm có thể được biểu diễn trong ngôn ngữ.
Ngữ nghĩa
Mỗi khái niệm mô hình hóa đều có một số ý nghĩa, ngữ nghĩa. Khi thêm một
thành phần vào mô hình hoặc kết nối các phần tử với nhau, chúng ta tạo ra ý nghĩa.
Trong DSM, ngữ nghĩa của ngôn ngữ mô hình hóa đến trực tiếp từ miền vấn đề. Ví dụ,
7


nếu phát triển một hệ thống giải trí cho xe, các khái niệm mô hình hóa như “menu”,
“event”,..đã có ý nghĩa rõ ràng trong miền ứng dụng.
Sử dụng ngữ nghĩa miền trong ngôn ngữ không chỉ giới hạn là các khái niệm miền mà
còn bao gồm các kết nối giữa kiến trúc mô hình hóa cũng như các quy tắc liên quan.
Ví dụ, ở hệ thống giải trí cho xe ở trên, một “menu” có thể kích hoạt một hành động
hoặc mở ra một submenu thì trong ngôn ngữ mô hình chuyên biệt miền một menu có
thể kết nối đến một hành động hoặc một menu khác.
Ngữ nghĩa của miền vấn đề không phải là nguồn duy nhất cho ngữ nghĩa DSM. Giống
như sinh code đích cho tất cả ngôn ngữ mô hình hóa, nhất thiết phải nhận ra ngữ nghĩa
của phía cài đăt; làm sao các kiến trúc mô hình được ánh xạ lên miền vấn đề. Sự ánh

xạ này được thực hiện không chỉ trên miền vấn đề mà còn trên các ngôn ngữ lập trình
khác. Sau đó, ngôn ngữ mô hình hóa sẽ thực sự được ánh xạ 1-1 lên ngôn ngữ lập trình
được sinh ra. Sự trừu tượng là giống nhau và code sinh ra là tối thiểu. Một ví dụ điển
hình là việc ánh xạ một lớp trong sơ đồ sang một lớp trong code. Nhà phát triển người
mà tạo ra mô hình đã nghĩ về các khái niệm và ngữ nghĩa của code. Nếu muốn tăng
mức độ trừu tượng và cải thiện hiệu suất, ngữ nghĩa của miền vấn đề có quan hệ nhiều
hơn ngữ nghĩa của miền giải pháp.

1.3. Mô hình hóa đặc tả chính sách truy nhập RBAC
Việc sử dụng các cơ chế kiểm soát truy nhập trong các tổ chức có quy mô từ
trung bình đến lớn luôn là một vấn đề rất quan trọng. Nghiên cứu [3,4] cho thấy điều
khiển truy nhập dựa trên vai trò RBAC là một mô hình hiệu quả và linh hoạt cho việc
kiểm soát truy nhập vào các nguồn tài cần được bảo vệ và việc thực thi chính sách các
chính sách an ninh của tổ chức.

1.3.1. RBAC và các ràng buộc phân quyền
Điều khiển truy cập dựa theo vai trò RBAC là một mô hình điều khiển truy cập,
trong đó việc quản trị an ninh có thể được đơn giản hóa bằng cách sử dụng các vai trò
để tổ chức các quyền truy nhập và cuối cùng giảm bớt sự phức tạp và chi phí quản trị
an ninh [3]. Mô hình tham chiếu RBAC được định nghĩa dưới dạng 3 thành phần mô
hình : Core RBAC (RBAC lõi), Hierachy RBAC (RBAC phân cấp) và Authorization
Constraints (các ràng buộc phân quyền).
Core RBAC [3] định nghĩa tối thiểu các phần tử, các tập phần tử và các mối
quan hệ để đạt được một hệ thống điều khiển truy nhập dựa theo vai trò một cách hoàn
chỉnh. Core RBAC được yêu cầu trong bất kì hệ thống RBAC nào nhưng các thành
phần khác độc lập với nhau và có thể được cài đặt riêng rẽ. Các tập phần tử và các mối
quan hệ của mô hình Core RBAC được thể hiện trong hình 3.
8

Hình 1.3: Core RBAC
Core RBAC bao gồm các tập của 5 phần tử dữ liệu cơ bản được gọi là user (USERS),
roles (ROLES), objects (OBS), operations (OPS) và permissions (PRMS).
 Một user được định nghĩa là một con người.
 Một role là một chức năng công việc trong ngữ cảnh của tổ chức, liên quan đến
quyền hạn và trách nhiệm của người dùng được gán vai trò đó.
 Một object là một thực thể chứa hoặc nhận thông tin. Trong hệ thống cài đặt
RBAC, đối tượng có thể là container chứa thông tin (file, thư mục, …) hoặc có thể
đại diện cho các nguồn tài nguyên hệ thống (máy in, ổ cứng,…)
 Một permission là một sự chấp nhận để thực hiện một hành động trên một hoặc
nhiều đối tượng được RBAC bảo vệ.
 Một operation là một hành động trên một đối tượng được bảo vệ, ví dụ trong hệ
thống file, các hoạt động có thể là đọc file, ghi file và xóa file.
Tổng thể mô hình RBAC được định nghĩa dưới dạng từng USERS được gán cho
ROLES và PRMS được gán cho ROLES. Như vậy, ROLES là phương tiện để đặt tên
cho các quan hệ nhiều – nhiều giữa USERS và PRMS. Ngoài ra, mô hình Core RBAC
còn bao gồm 1 tập các phiên làm việc (SESSIONS) mà mỗi phiên là một sự ánh xạ
giữa USER và một tập các ROLE con đã kích hoạt được gán cho USER.
Một mô hình RBAC được sử dụng rộng rãi do Sandhu và các cộng sự [4] giới thiệu :
 Các tập hợp USERS, ROLES, PRMS, SESSIONS ( người dùng, vai trò, quyền và
phiên làm việc tương ứng)
 UA ⊆ USERS x ROLES (mối quan hệ gán người dùng với vai trò)
 PA ⊆ PRMS x ROLES (mối quan hệ gán quyền với vai trò)
 RH ⊆ ROLES x ROLES (mối quan hệ phân cấp vai trò)
Một USER có thể là thành viên của nhiều ROLES và một ROLE có thể có nhiều
USERS. Tượng tự, một ROLE có thể có nhiều PRMS và cùng PRMS có thể được gán
9


cho nhiều ROLES. Một USER có thể kích hoạt một tập con các ROLES được gán cho

mình trong một SESSION. Các PRMS có sẵn cho USER là sự kết hợp của PRMS từ
tất cả các ROLES được kích hoạt trong SESSION. Các phân cấp vai trò có thể được
hình thành bởi quan hệ RH, ví dụ vai trò của bác sĩ trưởng khoa kế thừa tất cả các
quyền từ vai trò của bác sĩ .
Authorizaiton Constraints là một khía cạnh quan trọng của RBAC và thỉnh
thoảng được xem như là động lực chính đằng sau RBAC[7]. Mục đích của
Authorizaiton Constraints không chỉ để giảm nguy cơ gian lận hoặc vi phạm an ninh
mà còn tăng cơ hội phát hiện lỗi trong cấu trúc an ninh của tổ chức. Authorizaiton
Constraints có thể cần được áp dụng với các chức năng và mối hệ RBAC để ngăn chặn
việc sử dụng thông tin sai lệch và các hành động gian lận. Một vài loại Authorizaiton
Constraints như ràng buộc SoD tĩnh và động, ràng buộc ngữ cảnh, ràng buộc
cardinality. Trong đó, SoD (tách biệt nhiệm vụ) là nguyên tắc cơ bản trong các hệ
thống an ninh, các hành động bắt buộc được chia cho hai hoặc nhiều người khác nhau
thực hiện để không có cá nhân nào có thể tự thỏa hiệp an ninh. Ví dụ, trong một tổ
chức yêu cầu không có người dùng nào được gán 3 trong 4 vai trò cho chức năng mua
hàng tức là vừa đăng ký yêu cầu mua hàng và vừa phê duyệt yêu cầu. Các ràng buộc
SoD được sử dụng để thực thi các chính sách mâu thuẫn với lợi ích. Một phương tiện
để ngăn chặn mâu thuẫn lợi ích thông qua SoD tĩnh, nghĩa là thực thi các ràng buộc về
gán USERS cho ROLES. Mặt khác, các ràng buộc SoD động giới hạn PRMS có sẵn
cho một USER bằng cách đặt các ràng buộc trên các ROLES được kích hoạt trong
phiên làm việc của USER.

1.3.2. MetaModel cho RBAC
Metamodel là một mô hình của ngôn ngữ mô hình hóa. Một metamodel của
RBAC với các khái niệm tương ứng : Subject (mở rộng khái niệm User thành các đối
tượng cùng vai trò có thể là User hoặc nhóm User được gọi là Group), Role,
Permission, Action, Authorization, Resource và mối quan hệ giữa các khái niệm gọi là
references. Ví dụ, một User có nhiều vai trò, tương ứng với reference là asignRole.

Hình 1.4: MetaModel của RBAC

10


Một Permission là một đối tượng kết nối một Role tới một tập Action được thực
hiện trên một Resource của hệ thống. Ngữ nghĩa của Permission được xác định bởi
thành phần Action. Mỗi Action đại diện cho mỗi kiểu hành động an ninh thích hợp
trên tài nguyên được bảo vệ, ví dụ như việc thực thi phê duyệt quy trình. Action cũng
có thể đại diện cho nhiều lớp khái niệm của các hoạt động ở mức trừu tượng cao. Mỗi
lớp có thể có nhiều phương thức và thuộc tính. Lớp này được gán cho Permission cho
phép Permission có quyền gọi tất cả các phương thức và đọc các giá trị của tất cả các
thuộc tính của lớp. Ví dụ, trong quy trình quản lý nghiệp vụ, Action là lớp cha đại diện
cho nhiều lớp Action như ActivityAction, ProcessAction, mỗi lớp Action con chứa các
phương thức và thuộc tính đại diện cho các hành động trên tài nguyên của quy trình.
AuthorizationContraint là một phần của chính sách kiểm soát truy cập thể hiện
điều kiện tiên quyết đối với mọi lời gọi thực hiện hành động của tài nguyên cụ thể
thông qua việc gán nó cho các Permission. Ví dụ, SoD được gán cho một Permission
A và Permission B để ràng buộc người thực hiện hai permission này phải khác nhau;
ngược lại nếu BoD được gán cho hai permission này thì bắt buộc người thực hiện
permision A cũng phải thực hiện luôn permission B.
Các khái niệm RBAC được đại diện trực tiếp như các kiểu metamodel. Để xây
dựng mô hình, cần phải thêm vào trong miền các khái niệm đại diện cho mô hình và
các thuộc tính, kiểu thuộc tính, cuối cùng là các khái niệm trừu tượng của miền [1].
Kết quả thu được là MetaModel 2 của RBAC như sau:

Hình 1.5: MetaModel 2 của RBAC

1.4. Mô hình hóa và thực thi quy trình nghiệp vụ với Activiti
Môi trường kinh doanh hiện nay ngày càng trở nên gay gắt, doanh nghiệp luôn
phải thay đổi để thích nghi và thỏa mãn nhu cầu của khách hàng. Nhằm xây dựng và
duy trì lợi thế cạnh tranh của mình, doanh nghiệp cũng cần liên tục cải tiến các quy

trình nghiệp vụ và BPM là một công cụ đắc lực hỗ trợ việc tối ưu các quy trình trong
bộ máy vận hành của doanh nghiệp.
11


1.4.1. Mô hình hóa quy trình nghiệp vụ
Quy trình nghiệp vụ được định nghĩa là một tập các sự kiện, hành động và quyết
định liên quan đến các tác nhân và nguồn tài nguyên, tất cả tạo ra một kết quả mang lại
giá trị cho tổ chức hoặc khách hàng của tổ chức [9]. Quy trình nghiệp vụ đóng vai trò
cốt lõi để căn cứ theo đó doanh nghiệp quản lý và vận hành một cách nhịp nhàng và
đạt hiệu quả cao.

Hình 1.6: Quy trình nghiệp vụ
Quản lý quy trình nghiệp vụ BPM chính là các nguyên tắc, các phương pháp và
các công cụ để thiết kế, phân tích, thực thi và giám sát các quy trình nghiệp vụ. Mục
đích của quản lý quy trình nghiệp vụ BPM là giảm sai sót của con người và sự gián
đoạn của quy trình để tập trung các bên liên quan vào vai trò nhiệm vụ của họ. Với sự
giúp đỡ của BPM, các tổ chức doanh nghiệp có thể hoạt động hiệu quả hơn và có khả
năng thích nghi tốt với những thay đổi.
1.4.1.1. Vòng đời quy trình nghiệp vụ
Việc tạo ra một quy trình nghiệp vụ bao gồm 5 pha được gọi là vòng đời BPM.
Năm pha này là: Thiết kế, Mô hình hóa, Thực thi, Giám sát và Tối ưu. Mỗi pha được
thiết kế để cài đặt một giải pháp quy trình thành công. Nhờ có vòng đời BPM, người ta
có thể hiểu việc cài đặt một quy trình nghiệp vụ là một quá trình liên tục do những
những thay đổi luôn xảy ra trong môi thường kinh doanh.

12


Hình 1.7: Vòng đời BPM

Pha thiết kế chịu trách nhiệm xác định các hành động; phân tích các thay đổi có
thể xảy ra trong tổ chức; định nghĩa cam kết mức độ dịch vụ SLA; và xác định chi tiết
các thành phần của quy trình như các tác nhân, sự thông báo, sự leo thang. Mục đích
chính của pha này là đảm bảo một thiết kế lý thuyết đúng và hiệu quả được chuẩn bị.
Pha này được thực hiện bởi chủ quy trình (process owners), người mà quyết định
luồng đi của quy trình trong doanh nghiệp.
Pha mô hình hóa là pha thứ hai của vòng đời BPM, trong đó quy trình nghiệp vụ
được kiểm tra lại và xác định đầy đủ. Pha thiết kế chuẩn bị một thiết kế lý thuyết còn
pha mô hình hóa, quy trình nghiệp vụ lý thuyết được thiết kế sử dụng các thành phần
của tiêu chuẩn ký hiệu BPMN. Pha này chủ yếu thuộc trách nhiệm của nhà phân tích
và nhà tích hợp hệ thống.
Một khi thiết kế lý thuyết được chuyển đổi thành mô hình, nó có thể được cài đặt
trong ứng dụng quy trình nghiệp vụ để tự động hóa việc thực thi của quy trình. Pha
thực thi là pha mà các dịch vụ được định nghĩa để tự động hóa quy trình nghiệp vụ.
Các ngôn ngữ được sử dụng để tạo các dịch vụ này là WSBPEL và BPMN 2.0. Pha
này thuộc trách nhiệm của các nhà phát triển người mà phát triển hệ thống.
Pha giám sát theo dõi hoạt động của các quy trình riêng lẻ. Giám sát hiệu năng
của mỗi và mọi quy trình để cung cấp các thông tin thống kê, đồng thời các trạng thái
của quy trình cũng có thể được duy trì. Trong pha giám sát, các vấn đề của quy trình
nghiệp vụ có thể được xác định và có các biện pháp khắc phục để cải thiện nó.
Pha tối ưu là pha cuối cùng của vòng đời BPM. Trong pha này, thông tin hiệu
năng của quy trình được lấy ra từ pha giám sát và các cải tiến, thay đổi trong quy trình
được xác định. Một khi hoàn thành pha tối ưu, quy trình nghiệp vụ lại bắt đầu lại từ
13


pha thiết kế đến khi vòng đời hoàn tất. Cứ thế, vòng đời BPM là một quá trình liên tục,
thích nghi tốt với những sự thay đổi trong môi trường kinh doanh.
1.4.1.2. Tiêu chuẩn ký hiệu BPMN
Có nhiều tiêu chuẩn BPM khác nhau được giới thiệu cho việc phát triển quy trình

nghiệp vụ nhưng BPMN 2.0 là tiêu chuẩn được sử dụng rộng rãi nhất do nó hỗ trợ cả
thiết kế và các tính năng của ngôn ngữ lập trình. Trước đây, các nhà phân tích nghiệp
vụ thiết kế quy trình nhưng rất khó cho các nhà phát triển có thể thêm các chi tiết kĩ
thuật vào nó. Tiêu chuẩn BPMN 2.0 khiến điều này trở nên dễ dàng hơn bao giờ hết
nhờ việc cho phép định nghĩa các component biểu diễn các thuộc tính và logic kỹ
thuật.
Một sơ đồ BPMN đơn giản bao gồm các thành phần đại diện cho luồng công
việc, đem lại hữu ích cho cả người sử dụng và người phát triển quy trình. Hình 1.8 mô
tả metamodel của BPMN bao gồm bốn thành phần cơ bản là: Flow objects,
Connecting objects, Swim lanes và Artifacts [10].

Hình 1.8: Metamodel của BPMN
Flow objects
Chứa các các thành phần chính biểu diễn quy trình nghiệp vụ, đặc trưng cho hành
vi của một quy trình bao gồm : events, activities và gateways.
 Events có thể được coi như các hành động xảy ra trong quy trình nghiệp vụ. Trong
sơ đồ BPMN, chúng được biểu diễn bằng một hình tròn. Có ba loại events : là Start
Event, Intermediate Event và End Event
14


Loại

Biểu diễn

Start Event

Intermediate
Event

End Event

Ý nghĩa
Cho biết sự bắt đầu của quy trình nghiệp vụ. Nên có
ít nhất một Start Event trong quy trình.
Liên quan đến các sự kiện xảy ra giữa thời điểm bắt
đầu và kết thúc của quy trình nghiệp vụ. Những sự
kiện này không ảnh hưởng đến quy trình do chúng
không bắt đầu hoặc kết thúc.
Cho biết sự kết thúc của quy trình nghiệp vụ. Nên có
ít nhất một End Event trong quy trình.

 Activities biểu diễn các nhiệm vụ hoặc công việc đang được thực hiện trong quy
trình nghiệp vụ. Trong sơ đồ BPMN, chúng được biểu diễn bằng hình chữ nhật tròn
góc. Các loại activities khác nhau là Task, Sub-Process và Call-Activity
Loại

Task

Biểu diễn

Ý nghĩa
Được sử dụng khi có một Activity được cài đặt
trong một quy trình. Các loại Tasks khác nhau
được cung cấp bởi BPMN là :
 Script task: sử dụng để tự động hóa 1 Task,
các logic được cài đặt ở đây.
 User task: sử dụng khi quy trình yêu cầu
tương tác với con người.
 Mail task: Là một loại dịch vụ để gửi e-mails

hoặc thông báo từ quy trình
 Service task: Là một Task tùy chỉnh khi muốn
một số hoạt động cụ thể được thực hiện

SubProcess

Biểu diễn các mức trong quy trình, giúp sơ đồ
hiển thị đơn giản và dễ hiểu hơn.

CallActivity

Tái sử dụng các quy trình hoặc Task dùng chung
và có sẵn trong hệ thống. Khi thực thi, hệ thống
sẽ gọi tới các quy trình hoặc Task đó.

 Gateways được sử dụng để xử lý rẽ nhánh hoặc nối các Paths trong quy trình. Mục
đích chính của gateways là điều khiển luồng đi của quy trình. Các loại gateway là
Exclusive GW, Inclusive GW, Parallel GW và Event-based GW.
15


Loại

Biểu diễn

Ý nghĩa

Exclusive
GW

Được sử dụng khi chúng ta muốn thực hiện duy nhất
một Path trong nhiều Paths. (câu lệnh If-else)

Inclusive
GW

Được sử dụng khi chúng ta muốn thực hiện các
Paths thỏa mãn điều kiện. (câu lệnh nhiều If)

Parallel GW

Tất cả các Paths đi ra sẽ được thực hiện mà không
cần kiểm tra bất kì điều kiện nào.

Event-based
GW

Paths sẽ được thực hiện dựa trên các sự kiện thỏa
mãn điều kiện.

Connecting objects
Được dùng để biểu diễn kiến trúc quy trình nghiệp vụ. Mỗi Flow objects được
kết nối với nhau sử dụng các Connecting objecs. Có ba loại Connecting objects là
Sequence flow, Message flow, và Associations
Loại
Biểu diễn
Ý nghĩa
Sequence
Biểu diễn thứ tự thực hiện của Activities trong quy
flow

trình nghiệp vụ
Message
Thể hiện các bản tin đang trao đổi trong quy trình
flow
Biểu diễn mối quan hệ giữa Flow object và Artifacts
Associations
hoặc dữ liệu trong quy trình nghiệp vụ

Swim lanes
Được sử dụng cho mục đích hiển thị hóa. Nhờ có Swim lanes mà có thể dễ dàng
tổ chức các Activites của một nghiệp vụ. Swim lanes bao gồm 2 đối tượng là Pool và
Lanes
Loại

Pool

Lanes

Biểu diễn

Ý nghĩa
Đại diện cho một thực thể trong quy trình nghiệp
vụ. Pool có thể chứ một vài Lanes. Khi làm việc
trong Pool, chúng ta không thể kết nối với các
Activities bên ngoài Pool
Một phân vùng của Pool, được sử dụng để tổ
chức quy trình nghiệp vụ theo các vai trò hoặc
chức năng đang thực hiện

16

Artifacts
Được sử dụng để cung cấp thông tin bổ sung trong sơ đồ BPMN, việc sử dụng
các ký hiệu trong quy trình nghiệp vụ có thể chú thích rõ ràng và mọi người cùng hiểu
được. Có ba loại Artifacts là Data object, Group và Anotation
Loại

Biểu diễn

Ý nghĩa

Data object

Hữu ích cho việc xem thông tin liên quan đến dữ liệu
được yêu cầu trong Activity

Group

Nhóm các Activities hoặc các Node cùng loại hay
cùng mục đích lại với nhau

Anotation

Thêm một số nhận xét, chú thích vào quy trình

1.4.2. Công cụ Activiti
Activiti được phát triển bởi Tom Baeyens và Joram Barez [11] dưới dạng mã
nguồn mở, để thực thi các quy trình nghiệp vụ được biểu diễn bằng BPMN 2.0. Activti
là nền tảng tốt nhất để xây dựng BPM cho giao tiếp giữa con người với con người. Nó

có thể được sử dụng rất dễ dàng trong mọi môi trường Java, hỗ trợ tất cả các khía cạnh
của BPM trong ngữ cảnh phát triển phần mềm. Người dùng có thể xây dựng bất kì
ngôn ngữ quy trình tùy chỉnh nào phù hợp với yêu cầu của mình vì nó cho phép họ sử
dụng các công cụ đã biết thay vì việc thay thế bằng một công cụ hoàn toàn mới. Thậm
chí, nếu người dùng thiếu kiến thức về kỹ thuật thì họ cũng có thể dễ dàng cài đặt và
chạy quy trình với tiện ích cài đặt. Activi có một cơ chế xử quy trình BPMN 2.0 siêu
nhanh và ổn định, cung cấp nền tảng tốt nhất cho sự hợp tác giữa người dùng ít hiểu
biết về kỹ thuật và nhà phát triển kỹ thuật.
Activiti được chia thành các mô-đun khác nhau. Activiti Modeler, Activiti
Designer, and Activiti Kickstart được sử dụng trong pha mô hình hóa để thiết kế quy
trình. Activiti Engine được tích hợp với ứng dụng và được đặt tại vị trí trung tâm như
một phần của pha thực thi. Để giám sát và quản lý quy trình, Activiti Explorer và
Activiti Rest được sử dụng.

17