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

Thuật ngữ

Ý nghĩa

Application Programming Interface
Binding Of Duty

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

BPM
BPMN

Business Process Management
Business Process Model and Notation

Quản lý quy trình nghiệp vụ
Tiêu chuẩn và mô hình quy trình
nghiệp vụ

DSM
DSML

Domain-Specific Modeling
Domain-Specific Modeling Language

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

EMF
PEP
SoA
SLA
SoD
RBAC

Eclipse Model Framework
Policy Enforcement Point
Service Oriented Architecture
Service-level agreement
Separation Of Duty
Role-Based Access Control

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ò

REST
WSBPEL
XACML

REpresentational State Transfer
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
Language

Markup

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

Biểu diễn

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

Intermediate
Event
End Event

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

SubProcess

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

Call-

Tái sử dụng các quy trình hoặc Task dùng chung

Activity

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
Exclusive

Biểu diễn

Ý nghĩa
Được sử dụng khi chúng ta muốn thực hiện duy nhất

GW

một Path trong nhiều Paths. (câu lệnh If-else)

Inclusive

Được sử dụng khi chúng ta muốn thực hiện các

GW

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

Paths sẽ được thực hiện dựa trên các sự kiện thỏa

GW

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

Biểu diễn

Ý nghĩa
Biểu diễn thứ tự thực hiện của Activities trong quy

trình nghiệp vụ

Message
flow

Thể hiện các bản tin đang trao đổi trong quy trình

Associations

Biểu diễn mối quan hệ giữa Flow object và Artifacts
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

Biểu diễn

Pool

Ý 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

Lanes

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

Biểu diễn

Group

Ý nghĩa
Hữu ích cho việc xem thông tin liên quan đến dữ liệu
được yêu cầu trong Activity
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