Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ

ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG


NGUYỄN VĂN QUÝ




KHẢO SÁT TÍNH HỢP LỆ CỦA MÔ HÌNH
TIẾN TRÌNH NGHIỆP VỤ



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







THÁI NGUYÊN - 2012
1Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên



ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

NGUYỄN VĂN QUÝ


KHẢO SÁT TÍNH HỢP LỆ CỦA MÔ HÌNH
TIẾN TRÌNH NGHIỆP VỤ


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

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


Người hướng dẫn khoa học: TS. ĐẶNG ĐỨC HẠNH





THÁI NGUYÊN - 2012
2Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
i
Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ
LỜI CẢM ƠN

Tôi xin gửi lời cảm ơn chân thành tới các thầy cô Trường Đại học
Công nghệ thông tin và Truyền thông - Trường Đại học Thái Nguyên cũng như tất
cả các thầy Viện Công nghệ thông tin thuộc Viện Khoa học và Công nghệ Việt
Nam đã trực tiếp giảng dạy và truyền đạt cho tôi những kiến thức nền tảng và quý
báu.

Tôi muốn đặc biệt gửi lời cảm ơn sâu sắc đến TS. Đặng Đức Hạnh – Bộ môn
Công Nghệ Phần Mềm, Khoa Công Nghệ Thông Tin, Trường Đại Học Công Nghệ,
Đại Học Quốc Gia Hà Nội, người đã trực tiếp nhiệt tình hướng dẫn và giúp đỡ tôi
hoàn thành Luận văn này.
Xin gửi lời cảm ơn tới gia đình, toàn thể bạn bè và người thân đã cổ vũ,
khuyến khích và động viên tôi trong suốt quá trình thực hiện Luận văn.
3Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
ii
Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ
TÓM TẮT NỘI DUNG

Một trong những hướng mới và rất “nóng” hiện nay của ngành công nghiệp
phần mềm đó là phát triển các hệ thống BPM (Business Process Management –
Quản lý quy trình nghiệp vụ). BPM là một tập hợp các công nghệ và các chuẩn hỗ
trợ việc thiết kế, thực thi, giám sát và quản trị các quy trình nghiệp vụ cho tổ chức
doanh nghiệp. BPM bao gồm rất nhiều chuẩn và một trong số đó là BPMN
(Business Process Modeling and Notation) - chuẩn để mô hình hóa các quy trình
nghiệp vụ. BPMN bao gồm một tập các kí pháp đồ họa và ngữ nghĩa của chúng
nhằm mô tả dưới dạng trực quan (các diagram) mô hình của các quy trình nghiệp
vụ. Luận văn dưới đây sẽ trình bày một kỹ thuật trong việc kiểm tra tính hợp lệ của
các mô hình quy trình nghiệp vụ được mô hình hóa bằng BPMN. BPM (Business
Process Model) metamodel sẽ được biểu diễn dưới dạng biểu đồ lớp UML (UML
class diagram) trong công cụ USE (UML-based Specification Environment). Các
ràng buộc ngữ nghĩa và cú pháp được mô tả bằng các điều kiện bất biến (OCL
invariants). Mỗi mô hình quy trình nghiệp vụ được biểu diễn như một thể hiện
(instance) của BPM metamodel và được kiểm tra tính hợp lệ bởi các điều kiện bất
biến đã định nghĩa.

4Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
iii

Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ
LỜI CAM ĐOAN

Tôi xin cam đoan toàn bộ nội dung được trình bày trong Luận văn Tốt nghiệp
này hoàn toàn là phần nghiên cứu và thể hiện của riêng tôi, dưới sự hướng dẫn và cố
vấn của TS. Đặng Đức Hạnh – Bộ môn Công Nghệ Phần Mềm, Khoa Công Nghệ
Thông Tin, Trường Đại Học Công Nghệ, Đại Học Quốc Gia Hà Nội. Tất cả các số
liệu, bảng biểu, nội dung trích dẫn từ các tài liệu tham khảo bên ngoài đã được chú
thích và liệt kê đầy đủ trong phần Tài liệu tham khảo.
5Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
iv
Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ
MỤC LỤC
Nội dung: Trang
MỞ ĐẦU 1
Chương 1. BIỂU DIỄN MÔ HÌNH VỚI METAMODEL 2
1.1 Lược đồ hướng đối tượng 2
1.1.1 Gii thiu UML 2
1.1.2 UML vn cn h thng 2
1.1.3 a UML 3
1.1.4 Bi lp 5
1.1.5 Bi ng 5
1.2 Ràng buộc OCL cho các metamodel 6
1.2.1  truy vn v c 7
1.2.2  d  dc 7
1.2.3  iu 7
1.2.4   7
1.3 Giới thiệu công cụ USE 8
2.3a USE 8
1.3.2 Ki 8

1.3.3 a h thng 10
1.3.4 Kip l ca h thng 11
1.3.5 c t i USE 13
Chương 2. TỔNG QUAN VỀ MÔ HÌNH QUY TRÌNH NGHIỆP VỤ 19
2.1 Tổng quan về BPMN 19
2.1.1 m 19
2.1.2 n t n ca BPMN 20
2.2 Metamodel của mô hình BPM[4][7] 28
Chương 3. KIỂM TRA TÍNH HỢP LỆ CỦA MÔ HÌNH TIẾN TRÌNH
NGHIỆP VỤ BPMN 31
3.1 Biểu diễn metamodel của mô hình tiến trình nghiệp vụ với USE 31
3.1.1 c t BPM metamodel 31
3.1.2  31
3.1.3 p 32
3.1.4  gip 36
3.2 Các ràng buộc OCL cho metamodel của mô hình BPMN 38
3.2.1 Lp BaseElement 38
3.2.2 Lp FlowElementContainer 39
3.2.3 Lp SequenceFlow 39
6Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
v
Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ
3.2.4 Lp ConditionSequenceFlow 40
3.2.5 Lp FlowNode 40
3.2.6 Lp Activity 41
3.2.7 Lp StartEvent 41
3.2.8 Lp EndEvent 41
3.2.9 Lp IntermediateEvent 42
3.2.10 Lp NormalFlowEvent 42
3.2.11 Lp BoundaryEvent 42

3.2.12 Lp Gateway 42
3.2.13 Lp ExclusiveGateway 44
3.3 Kiểm tra tính hợp lệ của mô hình BPMN cho quy trình vay tín dụng 44
3.3.1 Gii thiu nghip v p v 44
3.3.2 Kihp l cng vi USE 49
KẾT LUẬN 62
Tài Liệu Tham Khảo 66


7Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
vi
Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ
Phụ lục
Danh mục thuật ngữ Tiếng Anh
BPM - Business Process Management
Tập hợp các công cụ, công nghệ và các
chuẩn cho phép mô hình hóa, tự động hóa
và quản lý các quy trình nghiệp vụ
BPMN – Business Process Model and
Notation
Chuẩn của BPM cho phép mô hình hóa
các quy trình nghiệp vụ
BPM metamodel – Business Process
Model metamodel
Mô hình đặc tả BPM – Business Process
Model
EAI – Enterprise Application
Integration
Mô hình tích hợp ứng dụng doanh nghiệp
ESB – Enterprise Service Bus

Mô hình băng thông dịch vụ
OCL – Object Constraint Language
Một chuẩn hỗ trợ cho UML giúp UML
chặt chẽ và chính xác hơn
Process
Trong tài liệu này Process được hiểu là
một mô hình quy trình nghiệp vụ được tạo
nên từ các phần tử mô hình hóa của
BPMN
Process instance
Một thể hiện của mô hình quy trình, một
luồng thực thi thực sự của mô hình quy
trình, đi từ điểm đầu đến điểm cuối của
mô hình, qua một tập các phần tử mô hình
Sub-process
Process con, là một process nằm bên
trong một process khác, nó được biểu diễn
như một phần tử luồng trong process kia
SOA – Service Oriented Architecture
Mô hình kiến trúc hướng dịch vụ
8Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
vii
Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ
UML – Unified Modelling Language
Chuẩn ngôn ngữ mô hình hóa thống nhất
USE – UML based Specification
Environment
Công cụ hỗ trợ đặc tả các hệ thống thông
tin dựa trên một phần của UML và OCL
OMG - Object Management Group

Tổ chức đưa ra các chuẩn cho xây dựng
các hệ thống hướng đối tượng

9Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
viii
Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ
DANH MỤC HÌNH VẼ


1-1: a UML 4
1-2: Bi lp cho mt giao d 5
1-3: Bi l ng th hin ca lp 6
1-4: Biu dip trong USE 10
1-5: Bi ng biu din trong USE 11
1-6: Kip l ca tr thng vi USE 13
2-p v ng BPMN [1] 20
2-2: (Start - Intermediate - End) Event [7] 21
2-u b sung cho Event [7] 22
2-Sub-process [7] 22
2-i Gateway [7] 24
2-6: Sequence Flow [7] 24
2-7: Conditional Flow [7] 25
2-8: Default Flow [7] 25
2-9: Association [7] 25
2-10: Pool [7] 26
2-11: Lane [7] 26
2-12: Minh ha Pool  27
2-i Data Object [7] 27
2-14: Group [7] 28

2-15: Text Annotation [7] 28
2- 30
3-1: Qu 45
3-ng 46
10Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
ix
Khảo sát tính hợp lệ của mô hình tiến trình nghiệp vụ
 3-3: Sub-process duy        
Information) 47
3-4: Sub-process ging (Disbursement) 49
3-5: Bi lp cho BPM metamodel biu din trong USE 50
3- 50
3-7: T ng
51
3-8: Kic v c 52
3-u din trong USE 58
3-10: Quan h gin t  58
3-11: Quan h gin t  59
3-12: Lung cu din trong USE 59
3-13: Kt qu kiu kin bt bin 60
3-t v c b vi phm 60
3-i 61
3-i biu din trong USE 61
3-17: Kt qu kim tra vu kin bt bi
 62
3-18: Giao din phn m meta BPM 63
3- meta BPM 63
3-c t  64
3-21: Kt qu c t  USE 64
11Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

1


MỞ ĐẦU
Mỗi cơ quan, tổ chức doanh nghiệp muốn hoạt động hiệu quả đều cần phải xây
dựng cho mình hệ thống quy trình nghiệp vụ phù hợp. Quy trình nghiệp vụ tốt sẽ
giúp giảm thiểu những sai lầm, lược bỏ những công việc dư thừa với hoạt động
chung của tổ chức, giúp phát hiện những điểm xung đột giữa các quy trình… Trong
môi trường kinh doanh sản xuất hội nhập quốc tế, yêu cầu về tính chuyên nghiệp và
hiệu quả càng cần được nâng cao hơn nữa. Các quy trình nghiệp vụ được xử lý thủ
công sẽ tạo áp lực vô cùng lớn về tiến độ, độ chính xác lên những người thực thi
quy trình đó.
BPM (Business Process Management) là một tập hợp các công nghệ và các
chuẩn để thiết kế, thực thi, giám sát và quản trị nhằm mục đích tự động hóa các quy
trình nghiệp vụ, nâng cao tính hiệu quả của quy trình nghiệp vụ. Nó được dùng như
một công cụ bổ trợ cho kiến trúc hướng dịch vụ (Service Oriented Architecture –
SOA) [3], tích hợp các chương trình ứng dụng (Enterprise Application Integration –
EAI) , và các băng thông dịch vụ (Enterprise Service Bus - ESB) .
BPMN[6][7] (Business Process Model and Notation) là một trong các chuẩn
của BPM và được dùng để mô hình hóa các quy trình nghiệp vụ. Các hệ thống BPM
đều cung cấp các công cụ hỗ trợ chuẩn này trong giai đoạn thiết kế và mô hình hóa
các quy trình nghiệp vụ và các công cụ đó đều có các bộ kiểm tra cú pháp giúp
người thiết kế mô hình tuân thủ đúng các đặc tả của BPMN. Rõ ràng việc kiểm tra
được định dạng đúng của các mô hình quy trình nghiệp vụ là vô cùng cần thiết để
tránh mắc phải các sai lầm ngay từ khi thiết kế và mô hình hóa các quy trình.
Luận văn này sẽ trình bày một kỹ thuật để thực hiện việc kiểm tra định dạng
đúng cho các mô hình quy trình nghiệp vụ. Phương pháp này có thể được mô tả vắn
tắt như sau: Trước hết ta xây dựng BPM metamodel và các ràng buộc OCL[8] cho
BPM metamodel dựa trên đặc tả của BPMN. BPM metamodel sẽ được biểu diễn
trong một công cụ hỗ trợ đặc tả là USE [2] dưới dạng biểu đồ lớp UML cùng với

các ràng buộc OCL. Công cụ này cho phép việc kiểm tra tính đúng dạng của các
trạng thái của hệ thống được sinh ra từ biểu đồ lớp (hay các thể hiện của biểu đồ
lớp) dựa trên các ràng buộc OCL. Các mô hình quy trình nghiệp vụ thực chất là các
thể hiện của BPM metamodel vậy nên ta có thể sử dụng công cụ này để kiểm tra
tính hợp lệ của các mô hình quy trình nghiệp vụ. Trong phạm vi nghiên cứu Luận
văn, tôi thực nghiệm phương pháp kiểm tra trên với mô hình tiến trình nghiệp vụ
cho quy trình vay tín dụng.
12Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
2


Chương 1. BIỂU DIỄN MÔ HÌNH VỚI METAMODEL
1.1 Lược đồ hướng đối tượng
1.1.1 Giới thiệu UML
Unified Modeling Language (UML) là ngôn ngữ mô hình hóa thống nhất được
đưa ra bởi ba tác giả chính là James Rumbaugh, Ivar Jacobson và Grady Booch.
UML bao gồm một tập các ký hiệu hình học để mô tả các khía cạnh khác nhau của
hệ thống. UML được sử dụng để đặc tả, xây dựng và làm tài liệu trong hầu hết các
quy trình phát triển phần mềm. Ngoài ra, UML được sử dụng làm công cụ giao tiếp
giữa các đối tượng trong giai đoạn phát triển như người dùng, người phần tích, thiết
kế hay người phát triển hệ thống.
1.1.2 UML và các giai đoạn của quy trình phát triển hệ thống
Thông thường, phát triển một hệ thống phần mềm thường trải qua các giai
đoạn phát triển như: nghiên cứu sơ bộ, phân tích, thiết kế, xây dựng, kiểm thử, thực
hiện triển khai và nâng cấp bảo trì. UML có thể được sử dụng trong nhiều giai đoạn,
từ phát triển, thiết kế cho tới thực hiện và bảo trì. Phần sau đây chúng tôi sẽ chỉ ra
cách ứng dụng UML vào trong các giai đoạn của chu trình phát triển phần mềm.
1.1.2.1 Giai đoạn nghiên cứu sơ bộ
Chúng ta sử dụng biểu đồ ca sử dụng UML (Usecase Diagram) trong giai đoạn
nghiên cứu sơ bộ. Giai đoạn này đưa ra mối quan hệ giữa các tác nhân (Actor) và ca

sử dụng (Usecase) trong hệ thống. Ở trong giai đoạn này, chúng ta tập trung làm rõ
những yêu cầu của ứng dụng cần xây dựng mà không quan tâm tới việc chúng được
thực hiện như thế nào.
1.1.2.2 Giai đoạn phân tích
Giai đoạn phân tích trừu tượng hóa các đối tượng trong hệ thống dưới dạng
các lớp (Class) và đối tượng (Object). Giai đoạn này sử dụng biểu đồ lớp UML
(Class Diagram) để biểu diễn các lớp và mối quan hệ giữa chúng. Đây có thể coi là
mô hình hóa thành phần cấu trúc của hệ thống. Ngoài ra, một số mô hình khác của
UML cũng được sử dụng để thể hiện khía cạnh động của hệ thống như mô hình tuần
tự, mô hình cộng tác, mô hình trạng thái
13Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
3


1.1.2.3 Giai đoạn thiết kế
Trong giai đoạn này, chúng ta sẽ mở rộng thêm các thành phần trong giai đoạn
phân tích để có thể biểu diễn được những khía cạnh khác của hệ thống như giao
diện người dùng, lưu trữ dữ liệu trong cơ sở dữ liệu như thế nào, kết nối với các
thiết bị, hệ thống khác Giai đoạn này sẽ cho chúng ta một bản đặc tả chi tiết cho
hệ thống.
1.1.2.4 Giai đoạn xây dựng
Đây là giai đoạn thực hiện thực tế của hệ thống. Qua giai đoạn này, các đặc tả
chi tiết trong giai đoạn thiết kế sẽ được chuyển thành mã thực tế trong một ngôn
ngữ lập trình cụ thế.
1.1.2.5 Giai đoạn thử nghiệm
Giai đoạn kiểm thử đảm bảo rằng hệ thống hoạt động đúng với đặc tả đã đưa
ra trong các giai đoạn phát triển hệ thống. Giai đoạn kiểm thử có thể được thực hiện
qua nhiều giai đoạn và thực hiện bởi nhiều nhóm kiểm thử khác nhau. Có nhiều loại
kiểm thử được đưa ra. Mỗi loại kiểm thử chúng ta sử dụng một loại biểu đồ UML.
Ví dụ, kiểm thử đơn vị sử dụng biểu đồ lớp UML, kiểm thử tích hợp sử dụng biểu

đồ thành phần (component diagram) và biểu đồ cộng tác (collaboration diagram),
kiểm thử hệ thống sử dụng biểu đồ ca sử dụng.
1.1.3 Các hướng nhìn của UML
Khi mô hình hóa một hệ thống, do tính chất phức tạp, chúng ta thường không
thể miêu tả cả hệ thống đó chỉ trong một bản vẽ. Một hệ thống thường được miêu tả
qua nhiều biểu đồ tương ứng với nhiều khía cạnh khác nhau của hệ thống như về
mặt chức năng (cấu trúc của hệ thống và sự tương tác trong hệ thống), về mặt phi
chức năng (yêu cầu về thời gian, độ tin cậy ) hay khía cạnh tổ chức của hệ thống
(module, tổ chức làm việc ). Vì vậy, một hệ thống thường được miêu tả trong một
loạt các hướng nhìn khác nhau, mỗi hướng nhìn thể hiện một khía cạnh riêng của hệ
thống.
Mỗi hướng nhìn lại được miêu tả trong một loạt các biểu đồ để chỉ rõ khía
cạnh đó của hệ thống. Do hệ thống thường phức tạp nên một biểu đồ cũng có thể
nằm trong nhiều hướng nhìn khác nhau. Biểu đồ được thể hiện bằng các ký hiệu
hình học để mô hình hóa hệ thống. Một biểu đồ trong một khía cạnh nào đó cần
phải dễ hiểu, dễ dàng giao tiếp và có độ kết dính với các biểu đồ và các hướng nhìn
khác. UML có một số hướng nhìn sau:
14Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
4


• Hướng nhìn ca sử dụng (use case view) : đây là hướng nhìn chỉ ra khía cạnh
chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài.

Hình 1-1: Các hướng nhìn của UML
• Hướng nhìn logic (logical view): chỉ ra chức năng sẽ được thiết kế bên trong
hệ thống như thế nào, qua các khái niệm về cấu trúc tĩnh cũng như hành vi động của
hệ thống.
• Hướng nhìn thành phần (component view hay implement view): chỉ ra khía
cạnh tổ chức của các thành phần code.

• Hướng nhìn song song (concurrency view hay process view): chỉ ra sự tồn tại
song song/ trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa
trong hệ thống.
• Hướng nhìn triển khai (deployment view): chỉ ra khía cạnh triển khai hệ
thống vào các kiến trúc vật lý.
Ngoài ra, trong công nghệ phần mềm còn sử dụng cả các hướng nhìn khác như
hướng nhìn tĩnh-động, hướng nhìn logic-vật lý, quy trình nghiệp vụ (workflow) và
một số hướng nhìn khác.
15Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
5


1.1.4 Biểu đồ lớp
Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống (nhìn hình 3.3).
Các lớp là đại diện cho các “vật” được xử lý trong hệ thống. Các lớp có thể quan hệ
với nhau trong nhiều dạng thức: liên kết (associated - được nối kết với nhau), phụ
thuộc (dependent - một lớp này phụ thuộc vào lớp khác), chuyên biệt hóa
(specialized - một lớp này là một kết quả chuyên biệt hóa của lớp khác), hay đóng
gói ( packaged - hợp với nhau thành một đơn vị). Tất cả các mối quan hệ đó đều
được thể hiện trong biểu đồ lớp, đi kèm với cấu trúc bên trong của các lớp theo khái
niệm thuộc tính (attribute) và thủ tục (operation). Biểu đồ được coi là biểu đồ tĩnh
theo phương diện cấu trúc được miêu tả ở đây có hiệu lực tại bất kỳ thời điểm nào
trong toàn bộ vòng đời hệ thống.
Một hệ thống thường sẽ có một loạt các biểu đồ lớp – chẳng phải bao giờ tất
cả các biểu đồ lớp này cũng được nhập vào một biểu đồ lớp tổng thể duy nhất – và
một lớp có thể tham gia vào nhiều biểu đồ lớp.

Hình 1-2: Biểu đồ lớp cho một giao dịch Tài chính
1.1.5 Biểu đồ đối tượng
Một biểu đồ đối tượng là một phiên bản của biểu đồ lớp và thường cũng sử

dụng các ký hiệu như biểu đồ lớp. Sự khác biệt giữa hai loại biểu đồ này nằm ở chỗ
biểu đồ đối tượng chỉ ra một loạt các đối tượng thực thể của lớp, thay vì các lớp.
Một biểu đồ đối tượng vì vậy là một ví dụ của biểu đồ lớp, chỉ ra một bức tranh
16Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
6


thực tế có thể xảy ra khi hệ thống thực thi: bức tranh mà hệ thống có thể có tại một
thời điểm nào đó. Biểu đồ đối tượng sử dụng chung các ký hiệu của biểu đồ lớp, chỉ
trừ hai ngoại lệ: đối tượng được viết với tên được gạch dưới và tất cả các thực thể
trong một mối quan hệ đều được chỉ ra như hình 1-3.
Biểu đồ đối tượng không quan trọng bằng biểu đồ lớp, chúng có thể được sử
dụng để ví dụ hóa một biểu đồ lớp phức tạp, chỉ ra với những thực thể cụ thể và
những mối quan hệ như thế thì bức tranh toàn cảnh sẽ ra sao. Một biểu đồ đối tượng
thường thường được sử dụng làm một thành phần của một biểu đồ cộng tác
(collaboration), chỉ ra lối ứng xử động giữa một loạt các đối tượng.

Hình 1-3: Biểu đồ lớp và biểu đồ đối tượng thể hiện của lớp
1.2 Ràng buộc OCL cho các metamodel
OCL [8][2] (Object Constraint Language) là một ngôn ngữ mô hình hóa để
xây dựng các mô hình phần mềm. OCL như là một chuẩn thêm trong phân tích và
thiết kế hướng đối tượng. Mỗi biểu thức trong OCL phụ thuộc vào các kiểu (lớp,
giao diện, ) được định nghĩa trong biểu đồ UML.
Biểu thức viết trong OCL đưa thêm các thông tin vào các mô hình hướng đối
tượng. Những thông tin này thường không thể biểu diễn bằng ký hiệu biểu đồ.
Trong UML, biểu thức OCL thường là các ràng buộc được định nghĩa để hạn chế
một hay nhiều giá trị của một mô hình hướng đối tượng hay hệ thống. Trong phiên
bản UML 2.0, các thông tin như định nghĩa truy vấn, giá trị tham chiếu, điều kiện
bắt đầu, quy tắc nghiệp vụ trong mô hình đều có thể được mô tả bằng các biểu thức
OCL. OCL là một ngôn ngữ chuẩn trong đó, các biểu thức được viết một cách rõ

ràng và dễ hiểu.
17Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
7


1.2.1 Ngôn ngữ truy vấn và ngôn ngữ ràng buộc
OCL là một ngôn ngữ để biểu diễn ràng buộc trên các thành phần trong các
biểu đồ của mô hình. Các ràng buộc này kiểm tra tính hợp lệ của các mô hình trạng
thái của hệ thống thông qua các điều kiện được chỉ ra trong ràng buộc. Biểu thức
OCL có thể được sử dụng ở bất cứ đâu trong mô hình để chỉ ra một giá trị. Giá trị
có thể là một giá trị đơn giản, nhưng cũng có thể là tham chiếu tới một đối tượng,
một tập hợp giá trị hay một tập hợp tham chiếu tới nhiều đối tượng. Điều này tương
tự như khả năng của ngôn ngữ truy vấn cấu trúc (Structure Query Language - SQL).
Vì vậy, OCL còn là một ngôn ngữ truy vấn.
1.2.2 Ngôn ngữ dựa trên cơ sở toán học nhưng không sử dụng ký hiệu
toán học
Đặc điểm nổi bật của OCL là xây dựng dựa trên cơ sở toán học. Nó dựa trên lý
thuyết tập hợp và logic vị từ. Tuy nhiên, OCL lại không sử dụng các ký hiệu toán
học. OCL dùng các khái niệm toán học nhưng bỏ qua các ký hiệu khó hiểu của toán
học. Thay vì sử dụng ký hiệu toán học, OCL dùng các từ khóa dễ hiểu để biểu diễn
cùng một khái niệm.
1.2.3 Ngôn ngữ định nghĩa kiểu
Đặc trưng quan trọng của OCL là một ngôn ngữ định nghĩa kiểu. Các biểu
thức OCL được dùng cho các mục đích mô hình hóa và đặc tả. Do hầu hết các mô
hình không được thực thi trực tiếp, các biểu thức OCL được biết trên phiên bản
không thực thi của hệ thống. Giống như các ngôn ngữ định nghĩa kiểu khác, các
biểu thức OCL có thể được kiểm tra trong mô hình hóa trước khi thực thi. Nhờ đó
mà các lỗi của mô hình có thể phát hiện và loại bỏ sớm.
1.2.4 Ngôn ngữ khai báo
Một đặc tính dễ phân biệt khác của OCL là ngôn ngữ khai báo. Trong các

ngôn ngữ thủ tục giống như các ngôn ngữ lập trình, các biểu thức là các mô tả về
các hành động phải thực hiện. Trong một ngôn ngữ khai báo, một biểu thức phát
biểu đơn giản đều được thể hiện nhưng không chỉ ra cách thực hiện như thế nào. Để
đảm bảo điều này, các biểu thức OCL không có ảnh hưởng tới hệ thống, có nghĩa là
việc đánh giá một biểu thức OCL không thay đổi trạng thái của hệ thống.
18Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
8


1.3 Giới thiệu công cụ USE
Một trong số các công cụ hỗ trợ OCL là USE (UML-based Specification
Environment). USE được phát triển bởi nhóm nghiên cứu DSG thuộc khoa Toán và
Khoa học máy tính (Department for Mathematics and Computer Science), trường
Đại học Bremen (University of Bremen), nước Đức. USE dựa trên các khái niệm về
cấu trúc ngữ nghĩa của OCL, một số phần có liên quan với UML và metamodel của
OCL. Nhiệm vụ chính của USE là xác nhận và kiểm tra tính hợp lệ của đặc tả UML
thông qua OCL. Người dùng có thể tương tác với USE qua giao diện dòng lệnh
(command shell) hoặc giao diện đồ họa GUI.
Đầu vào của USE là biểu đồ lớp UML, biểu đồ trạng thái UML dưới dạng
ngôn ngữ đặc tả dạng text, các điều kiện bất biến, tiền điều kiện và hậu điều kiện.
USE hỗ trợ sinh ra biểu đồ đối tượng UML (object diagram), biểu đồ tuần tự
(sequence diagram), và kết quả của việc kiểm tra tính hợp lệ của các mô hình với
các điều kiện bất biến, tiền điều kiện và hậu điều kiện.
2.3.1 Các chức năng của USE
USE có nhiều chức năng hỗ trợ việc đặc tả các mô hình UML tuy nhiên trong
phạm vi Luận văn sẽ chỉ giới thiệu những chức năng có liên quan tới mục đích của
Luận văn là trình bày một kỹ thuật để kiểm tra tính hợp lệ của mô hình quy trình
nghiệp vụ.
1.3.2 Kiểm tra cú pháp
Biểu đồ lớp UML, các điều kiện bất biến, tiền điều kiện, hậu điều kiện, biểu

đồ trạng thái UML biểu diễn trong USE dưới dạng ngôn ngữ đặc tả dạng text. Các
lớp và quan hệ giữa các lớp được viết đơn giản: Lớp bao gồm các thuộc tính và các
hành vi. Trong các hành vi có thể mô tả thêm các biểu thức OCL. Quan hệ giữa các
lớp miêu tả lực lượng (multiplicity) và các tên vai trò (role name). Thông thường,
các điều kiện bất biến thường nằm trong lớp và để kiểm tra hợp lệ của thuộc tính và
quan hệ. Còn hành vi được kiểm tra hợp lệ bởi tiền điều kiện và hậu điều kiện. Ví
dụ về đặc tả mô hình với ngôn ngữ đặc tả dạng text của USE [2]:
19Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
9


model Company

classes

class Employee
attributes
name : String
salary : Integer
end

class Department
attributes
name : String
location : String
budget : Integer
end

class Project
attributes

name : String
budget : Integer
end

associations

association WorksIn between
Employee[*]
Department[1 *]
end

20Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
10


association WorksOn between
Employee[*]
Project[*]
end

association Controls between
Department[1]
Project[*]
end
USE cho phép biểu diễn dưới dạng trực quan như hình 1-4 sau đây:

Hình 1-4: Biểu diễn mô hình lớp trong USE
1.3.3 Sinh các trạng thái của hệ thống
Trạng thái của hệ thống được biểu diễn thông qua biểu đồ đối tượng (object
diagram). Mỗi đối tượng trong biểu đồ đối tượng thuộc về một lớp trong biểu đồ lớp

và USE chỉ ra giá trị của từng thuộc tính của đối tượng đó, hiển thị tên vai trò của
các liên kết mà đối tượng đó có với các đối tượng khác.
21Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
11



Hình 1-5: Biểu đồ đối tượng biểu diễn trong USE
1.3.4 Kiểm tra tính hợp lệ của các trạng thái của hệ thống
USE cho phép kiểm tra tính hợp lệ của một trạng thái bất kì của hệ thống bằng
cách đánh giá các điều kiện bất biến, tiền điều kiện và hậu điều kiện được định
nghĩa trước. Ví dụ với các OCL constraints cho đặc tả mô hình Company ở trên như
sau [2]:
OCL constraints
constraints
context Department
the number of employees working in a
department must
be greater or equal to the number of
projects
controlled by the department
inv MoreEmployeesThanProjects:
self.employee->size >= self.project->size
22Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
12


context Employee
employees get a higher salary when they work
on more projects

inv MoreProjectsHigherSalary:
Employee.allInstances->forAll(e1, e2 |
e1.project->size > e2.project->size
implies e1.salary > e2.salary)
context Project
the budget of a project must not exceed the
budget of the controlling department
inv BudgetWithinDepartmentBudget:
self.budget <= self.department.budget
employees working on a project must also
work in the controlling department
inv EmployeesInControllingDepartment:
self.department.employee->
includesAll(self.employee)

Ta sẽ có kết quả kiểm tra trạng thái hệ thống như ở ví dụ trên với các ràng
buộc vừa mô tả như trong hình 1-6:
23Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
13



Hình 1-6: Kiểm tra tính hợp lệ của trạng thái hệ thống với USE
1.3.5 Đặc tả mô hình UML với USE
Để đặc tả mô hình UML với USE, chúng ta có thể sử dụng một
trình soạn thảo bất kỳ như notepad, textedit… sau đó lưu file với phần mở rộng .use
1.3.5.1 Khai báo một đặc tả mô hình UML
Cú pháp để định nghĩa tên một mô hình như sau [2]:
<umlmodel> ::= model <modelname>[<modelbody>]
<modelname> ::=<name>

<modelbody> bao gồm các định nghĩa cho enumeration trên cùng, tiếp
theo là các khai báo lớp(class) và quan hệ (association), cuối cùng là các ràng
buộc constraints
<modelbody> ::= { <enumerationdefinition> }
{<associationdefinition> | <associationclassdefinition> }
<classdefinition>
{<classdefinition>|<associationdefinition>
|<associationclassdefinition> }
24Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
14


[constraints{<constraintdefinition>}]
Ví dụ: Xem ở mục 3.1.1
1.3.5.2 Đặc tả các thành phần trong mô hình UML vừa khai báo ở trên
Dưới đây mô tả cú pháp để đặc tả từng thành phần trong <modelbody> của mô
hình được khai báo ở trên.
a. Enumerations
Đặt ngay sau khai báo của đặc tả mô hình. Cú pháp để khai báo một
Enumeration như sau [2]:
<enumerationdefinition> ::= enum <enumerationname>
{<elementname> {, <elementname>}}
<enumerationname> ::= <name>
<elementname> ::= <name>
Ví dụ: Xem ở mục 3.1.2
b. Classes
Bao gồm tên lớp, các thuộc tính và hành vi. Bắt buộc phải khai báo tên lớp.
Thuộc tính, hành vi, ràng buộc có thể khai báo hoặc không. USE hỗ trợ việc kế thừa
trong cấu trúc lớp. Ở đây sự đa kế thừa có thể được áp dụng. Ta sử dụng ký tự “<”
để biểu diễn sự kế thừa. Cú pháp khai báo lớp như sau [2]:

<classdefinition>::=
[abstract] class <classname> [< <classname>{,
<classname>}]
[attributes {<attributename> : <type>}]
[operations <operationdeclaration>[=<oclexpression>]
{<preconditiondefinition> |
<postconditiondefinition>}}]
[constraints {<invariantdefinition>}]
end
25Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên