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

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

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

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

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

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

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

MỤC LỤC

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à các giai đoạn của quy trình phát triển hệ thống 2

1.1.3 Các hướng nhìn của UML 3

1.1.4 Biểu đồ lớp 5

1.1.5 Biểu đồ đối tượng 5

1.2 Ràng buộc OCL cho các metamodel 6

1.2.1 Ngôn ngữ truy vấn và ngôn ngữ ràng buộc 7

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 7

1.2.3 Ngôn ngữ định nghĩa kiểu 7

1.2.4 Ngôn ngữ khai báo 7

1.3 Giới thiệu công cụ USE 8

2.3.1 Các chức năng của USE 8

1.3.2 Kiểm tra cú pháp 8

1.3.3 Sinh các trạng thái của hệ thống 10

1.3.4 Kiểm tra tính hợp lệ của các trạng thái của hệ thống 11

1.3.5 Đặc tả mô hình UML vớ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 Khái niệm 19

2.1.2 Các phần tử và kí pháp cơ bả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 Khai báo đặc tả BPM metamodel 31

3.1.2 Khai báo Enumeration GatewayDirection 31

3.1.3 Khai báo và định nghĩa các lớp 32

3.1.4 Khai báo và định nghĩa các quan hệ giữa các lớ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

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ụ vay tính dụng và các mô hình tiến trình nghiệp vụ 44

3.3.2 Kiểm tra tính hợp lệ của mô hình BPM vay tín dụng với USE 49

KẾT LUẬN 62

Tài Liệu Tham Khảo 66

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

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ụ

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

DANH MỤC HÌNH VẼ

ình 1-1: Các hướng nhìn của UML 4

ình 1-2: Biểu đồ lớp cho một giao dịch Tài chính 5

ình 1-3: Biểu đồ lớp và biểu đồ đối tượng thể hiện của lớp 6

ình 1-4: Biểu diễn mô hình lớp trong USE 10

ình 1-5: Biểu đồ đối tượng biểu diễn trong USE 11

ình 1-6: Kiểm tra tính hợp lệ của trạng thái hệ thống với USE 13

ình 2-1: Quy trình nghiệp vụ được mô hình hóa bằng BPMN [1] 20

ình 2-2: (Start - Intermediate - End) Event [7] 21

ình 2-3: Các kí hiệu bổ sung cho Event [7] 22

ình 2-4: Task và Sub-process [7] 22

ình 2-5: Các loại Gateway [7] 24

ình 2-6: Sequence Flow [7] 24

ình 2-7: Conditional Flow [7] 25

ình 2-8: Default Flow [7] 25

ình 2-9: Association [7] 25

ình 2-10: Pool [7] 26

ình 2-11: Lane [7] 26

ình 2-12: Minh họa Pool và Lane [13] 27

ình 2-13: Các loại Data Object [7] 27

ình 2-14: Group [7] 28

ình 2-15: Text Annotation [7] 28

ình 2-16: Metamodel cơ bản cho các mô hình BPM 30

ình 3-1: Quản lý công tác phí (Expense Management) 45

ình 3-2: Quy trình vay tín dụng 46

ình 3-3: Sub-process duyệt thông tin hồ sơ khách hàng (Check Application

Information) 47

ình 3-4: Sub-process giải ngân tín dụng (Disbursement) 49

ình 3-5: Biểu đồ lớp cho BPM metamodel biểu diễn trong USE 50

ình 3-6: Mô hình quy trình quản lý công tác phí 50

ình 3-7: Tạo các đối tượng, liên kết, và đặt giá trị cho các thuộc tính của đối tượng 51

ình 3-8: Kiểm tra các ràng buộc về cấu trúc 52

ình 3-9: Mô hình quy trình quản lý công tác phí biểu diễn trong USE 58

ình 3-10: Quan hệ giữa process và các phần tử bên trong (1) 58

ình 3-11: Quan hệ giữa process và các phần tử bên trong (2) 59

ình 3-12: Luồng của mô hình quy trình biểu diễn trong USE 59

ình 3-13: Kết quả kiểm tra mô hình quy trình với các điều kiện bất biến 60

ình 3-14: Thông tin chi tiết về ràng buộc bị vi phạm 60

ình 3-15: Quy trình quản lý công tác phí đã sửa đổi 61

ình 3-16: Mô hình quy trình quản lý công tác phí đã sửa đổi biểu diễn trong USE 61 ình 3-17: Kết quả kiểm tra với các điều kiện bất biến sau khi đã sửa đổi mô hình quy trình 62

ình 3-18: Giao diện phần mềm mô tả meta BPM 63

ình 3-19: Mô tả meta BPM 63

ình 3-20: Lưu đặc tả mô hình 64

ình 3-21: Kết quả đặc tả làm nguồn cho công cụ USE 64

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

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

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:

• 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ướ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

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

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

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

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

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

association WorksOn between Employee[*]

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

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

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

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

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

để biểu diễn sự kế thừa Cú pháp khai báo lớp như sau [2]:

<postconditiondefinition>}}]

[constraints {<invariantdefinition>}]

số lượng đối tượng của mỗi lớp trong quan hệ đó Cú pháp khai báo quan hệ như sau [2]:

<associationclassdefinition> ::= [ abstract ] associationclass <classname> [ < <classname>

{<invariantdefinition>}

<operationcontext> ::= context <classname>

<operationconstraints>

<invariantdefinition> ::= inv [<invariantname>]:<booleanoclexpression>

<operationconstraints> ::= :: <operationdeclaration> ( <preconditiondefinition> |

<postconditiondefinition>) { <preconditiondefinition> |

<postconditiondefinition>}

<preconditiondefinition>::=pre [<preconditionname>]:<booleanoclexpression>

<postconditiondefinition>::=post [<postconditionname>]:<booleanoclexpression>)

<parameters>::=<parametername> :<type> {,<parametername> :<type>}

({<collectiontype>|<simpletype>|<enumerationname>})

<simpletype> ::= Integer | Real | Boolean | String |

<classname>

h Names, Number, OCL Constraints

Viết các biểu thức OCL: các biểu thức toán học trên đối tượng [2]

<name> ::= ( <letter> | _) { <letter> | <digit> | _

}

<letter> ::= a | b | | z | A | B | | Z

<digit> ::= 0 | 1 | | 9

<oclexpression> ::= biểu thức OCL

<booleanoclexpression>::= biểu thức OCL có giá trị

trả về kiểu Boolean

Chương 2 TỔNG QUAN VỀ MÔ HÌNH QUY TRÌNH NGHIỆP VỤ 2.1 Tổng quan về BPMN

Trong phần này, các khái niệm, các kí pháp, biểu tượng và các quy tắc của BPMN sẽ được trình bày chi tiết và cụ thể Toàn bộ phần trình bày về BPMN trong Luận văn đều tuân theo đặc tả mới nhất của BPMN là bản đặc tả BPMN 2.0 [7] Một số VD về các quy trình nghiệp vụ đã được mô hình hóa bằng các công cụ mô hình hóa phổ biến và tốt nhất hiện nay cũng sẽ được trình bày (tất cả các VD đưa ra trong Luận văn đều được mô hình hóa bằng công cụ mô hình hóa quy trình nghiệp

vụ của Oracle BPM Studio [12])

2.1.1 Khái niệm

BPMN (Business Process Modeling and Notation) là một trong các chuẩn của

BPM (Business Process Management) được dùng để đặc tả các quy trình nghiệp vụ bằng các kí pháp đồ họa BPMN định nghĩa 1 tập các kí pháp đồ họa và ngữ nghĩa của chúng, các ngữ nghĩa về mặt logic và ngữ nghĩa thực thi cho quy trình nghiệp

vụ Phiên bản đầu tiên của BPMN được công bố năm 2004, phát triển bởi BPMI - Business Process Modeling Initiative (đã sáp nhập với OMG - Object Management Group từ năm 2005) và hiện nay được chấp nhận như 1 chuẩn chung, phổ biến nhất trên toàn thế giới trong việc mô hình hóa các quy trình nghiệp vụ Phiên bản mới nhất hiện nay là BPMN 2.0, phát hành ngày 3-1-2011 BPMN hoàn toàn độc lập với các phương pháp mô hình hóa quy trình nghiệp vụ BPMN đóng vai trò là một ngôn ngữ giao tiếp rõ ràng, hoàn chỉnh và hiệu quả giữa người phân tích thiết kế và người phát triển, người quản lý cũng như người thực thi hay tham gia vào các quy trình nghiệp vụ Đặc tả cho BPMN cũng định nghĩa các quy tắc tham chiếu giữa BPMN

và BPEL [7] (Business Process Execution Language), một loại “executable language”, giúp thu hẹp khoảng cách và rút ngắn các bước từ việc phân tích thiết kế tới việc phát triển các quy trình nghiệp vụ, cho phép cập nhật và cải tiến quy trình nghiệp vụ một cách nhanh chóng, dễ dàng và hiệu quả nhất

BPMN 2.0 bao gồm đặc tả cho 3 loại mô hình là: Process, Collaboration và Choreography Trong phạm vi của Luận văn này sẽ chỉ tập trung trình bày về mô hình cho Process

 Data: Các thành phần mô tả tài nguyên và dữ liệu cho quy trình

 Artifacts: Bổ sung ngữ nghĩa

Các phần tử này sẽ liên kết với nhau theo những quy tắc riêng để xác định

được một mô hình quy trình (sau đây gọi là process) dưới dạng trực quan như hình

minh họa dưới đây Mô hình này sẽ chỉ ra những con đường hay trình tự mà theo đó

các process có thể được đi từ điểm bắt đầu đến điểm kết thúc, qua các điểm nút

Các Flow Objects đóng vai trò là các điểm nút Connection Object đóng vai trò liên kết giữa các điểm nút Swimlanes có chức năng phân chia các điểm nút thành các nhóm Artifacts có chức năng bổ sung ý nghĩa cho các phần tử trong process, có thể bằng cách nhóm chúng lại hoặc thêm các chú thích dạng text đi kèm Còn Data mô

tả các tài nguyên mà process sử dụng đến trong suốt quá trình nó được thực thi

Hình 2-1: Quy trình nghiệp vụ được mô hình hóa bằng BPMN [1]

Để mô tả rõ hơn về các phần tử trong BPMN, ta làm quen với khái niệm

process instance Process instance được hiểu là một luồng thực thi thực sự của process đi qua các điểm nút và các liên kết (Connection Object) theo một con đường hay trình tự nào đó từ điểm bắt đầu đến điểm kết thúc của process

2.1.2.1 Các đối tượng luồng (Flow Objects - Flow Node)

Flow Objects là các điểm nút trong process, ở đó nó định nghĩa các hành vi

mà process instance phải thực hiện trước khi theo các liên kết để chuyển tiếp sang

điểm nút khác Flow Objects bao gồm các loại sau:

a Event

Là đối tượng mô tả những sự kiện “xảy ra” trong suốt quá trình process diễn

ra Có các loại sự kiện như: Start Event, End Event (hay Stop Event) và Intermediate Event được kí hiệu bằng các kí pháp như hình minh họa 2-2 Start

Event là nơi bắt đầu cho một process và End Event là nơi kết thúc một process Intermediate Event là các sự kiện xảy ra trong khi process đang diễn ra và có tác động tới process VD: sự kiện công dân nộp bổ sung hồ sơ trong quy trình giải

quyết thủ tục hành chính

Hình 2-2: (Start - Intermediate - End) Event [7]

Ở giữa các đường tròn của Event để chừa các khoảng trắng để đưa vào các kí hiệu bổ sung nhằm phân biệt các loại sự kiện Có các loại kí hiệu bổ sung như Message – sự kiện gửi hoặc nhận thông điệp, Timer – sự kiện xảy ra sau khi kết thúc một khoảng thời gian nào đó định trước (bộ đếm giờ) hay Error – sự kiện lỗi:

Hình 2-3: Các kí hiệu bổ sung cho Event [7]

b Activity

Activity định nghĩa các công việc hoặc nhóm các công việc được thực thi

trong một process để có thể hoàn thành process đó Activity mà không thể chia nhỏ

hơn gọi là một Task Ngược lại, nếu Activity bao gồm một chuỗi các Activity nhỏ

hơn thì đó được gọi là một sub-process Sub-process tương đương với một process

xét theo khía cạnh cấu trúc

Hình 2-4: Task và Sub-process [7]

Activity có thể được thực thi (implement) bởi những người tham gia quy trình

(Automatic Activity) hoặc gọi đến một dịch vụ (Service) nào đó theo mô hình kiến trúc SOA Mỗi Activity đều có một Activity Handler giúp định nghĩa đối tượng sẽ thực thi Activity đó

c Gateway

Gateway là đối tượng được sử dụng để rẽ nhánh, kết hợp hoặc chia nhánh các

luồng của một process Tùy thuộc vào chức năng hội tụ hay phân kì của Gateway

mà nó sẽ có một hay nhiều “đường vào” và một hay nhiều “đường ra” “Đường vào” và “đường ra” chính là các liên kết hay các Connection Object (sẽ được trình bày ở phần sau)

Exclusive Gateway và Inclusive Gateway định hướng cho luồng process dựa

trên các điều kiện được xác định trên mỗi “đường ra” Các Gateway này sẽ làm nhiệm vụ xét các điều kiện trên các đường ra Nếu điều kiện trên đường ra được

thỏa mãn thì process sẽ được chuyển tiếp khỏi Gateway theo “đường ra” đó Với

Inclusive Gateway thì cho phép chọn nhiều hơn một đường ra, tức là các điều kiện ở các đường ra không loại trừ nhau Ngược lại, Exclusive Gateway chỉ cho phép duy nhất một đường ra có điều kiện thỏa mãn, tức là các điều kiện loại trừ lẫn nhau Cả

2 loại Gateway này đều cần đến một loại đường ra đặc biệt gọi là default để khi không có điều kiện nào thỏa mãn thì process instance sẽ đi ra theo đường này

Complex Gateway cũng tương tự như Exclusive và Inclusive Gateway, có các

đường ra có điều kiện và một đường ra default Điểm khác giữa Complex Gateway

và 2 loại kia là bản thân nó cũng chứa 1 điều kiện để kết hợp các process instance

đến từ các đường vào Điều kiện đó cũng giúp nó xác định các đường ra phù hợp Event-based Gateway là Gateway mà mỗi đường ra của nó đều liên kết tới một Event nào đó Và cuối cùng là Parallel Gateway, là loại Gateway đơn giản nhất

Nếu là Parallel Gateway phân kì thì nó sẽ tự động sinh ra các bản sao của process instance ở đường vào và chuyển tiếp mỗi process instance đó đến các đường ra của

nó còn nếu là Parallel Gateway hội tụ thì chức năng của nó ngược lại

Hình 2-5: Các loại Gateway [7]

2.1.2.2 Các đối tượng kết nối (Connection Objects)

Connection Objects là các đối tượng sử dụng để liên kết giữa phần tử còn lại

của process (giữa các Flow Object với nhau hay giữa Flow Object và Artifacts)

a Sequence Flow

Là loại liên kết được dùng để kết nối giữa các Flow Object với nhau Mũi tên

chỉ hướng đi của process instance khi đi qua Sequence Flow Mỗi Sequence Flow

có “nguồn” và “đích” đều là các Flow Object

Hình 2-6: Sequence Flow [7]

Kí pháp trên hình 1.6 là kí pháp cơ bản nhất dùng cho Sequence Flow Trong Sequence Flow có thể chia ra thành các loại nhỏ hơn là Unconditional Flow và Conditional Flow Conditional Flow là loại Sequence Flow có định nghĩa điều kiện Nếu Conditional Flow đi ra từ một Gateway thì nó sử dụng kí pháp cơ bản như hình 2-7, nhưng nếu nó đi ra từ một Activity thì buộc phải sử dụng kí pháp sau đây:

Hình 2-7: Conditional Flow [7]

Default Flow là Sequence Flow đặc biệt sử dụng trong các Gateway hoặc Activity có các “đường ra” là các Conditional Flow Nó thuộc loại Unconditional Flow nhưng lại sử dụng kí pháp như sau:

Swimlane dùng để phân nhóm các Flow Object Có 2 loại Swimlane là Pool

và Lane Pool chỉ ra ranh giới, phạm vi của process Tất cả các đối tượng nằm bên trong Pool của một process đều thuộc về process đó Trong một process có nhiều

vai trò (role) tham gia, mỗi vai trò sẽ thực hiện những công việc nhất định trong

process để hoàn thành process đó Lane sẽ chia các Flow Object thành các nhóm

theo từng vai trò này Những công việc thuộc về cùng một vai trò sẽ thuộc cùng một Lane

Hình 2-12: Minh họa Pool và Lane [13]

2.1.2.4 Data

Data Object là các đối tượng cung cấp các tài nguyên cần thiết cho process

Data Object có thể thể hiện một đối tượng đơn lẻ hoặc một tập các đối tượng Đối

với cả process thì Data Input và Data Output cung cấp thông tin như nhau

Hình 2-13: Các loại Data Object [7]

2.1.2.5 Artifacts

Artifacts được sử dụng để cung cấp thêm thông tin cho các phần tử của

process