Van hanh tien trinh nghiep vu tren moi truong web

Nghiên cứu và xây dựng ứng dụng hỗ trợ vận hành tiến trình nghiệp vụ (BPML) trên môi trường WEB

Trang 1

Lời cảm ơn

Chúng em xin chân thành cảm ơn Khoa Công Nghệ Thông Tin, Trường Đại

học Khoa học Tự nhiên, Tp HCM đã tạo điều kiện cho chúng em thực hiện đề tài

tốt nghiệp này.

Chúng em xin chân thành cảm ơn thầy Lâm Quang Vũ đã tận tình hướng dẫn,

chỉ bảo chúng em trong suốt quá trình thực hiện đề tài này. Qua sự hướng dẫn của

thầy, chúng em không chỉ học được nhiều kiến thức bổ ích mà còn học ở thầy

phương pháp nghiên cứu khoa học, thái độ và tinh thần làm việc nghiêm túc.

Chúng em cũng xin chân thành cảm ơn các thầy cô trong khoa công nghệ

thông tin đã trang bị cho chúng em những kiến thức bổ ích trong suốt quá trình

học tập tại trường. Những kiến thức ấy đã giúp chúng em rất nhiều trong quá trình

làm đề tài và cũng là hành trang cho chúng em tự tin, vững bước vào đời.

Chúng con xin ghi nhớ công ơn của Ba, Mẹ. Ba mẹ luôn là niềm động viên

giúp chúng con vuợt qua khó khăn trong cuộc sống.

Chúng em xin cảm ơn các anh chị khóa trước đã truyền đạt các kinh nghiệm

cho chúng em trong quá trình thực hiện luận văn tốt nghiệp.

Mặc dù đã cố gắng hoàn thành luận văn với tất cả nỗ lực của bản thân, nhưng

luận văn chắc chắn không tránh khỏi những sai sót, chúng em rất mong quí thầy cô

tận tình chỉ bảo. Một lần nữa chúng em xin gửi đến tất cả mọi người lời cảm ơn

chân thành nhất.


Trang 2

Giới thiệu tổng quan đề tài Ngày nay, cùng với sự gia tăng quy mô tổ chức, công việc ngày càng phức tạp. Nhu

cầu sử dụng tin học trong tổ chức cũng gia tăng tương ứng. Tuy nhiên, hiện nay, tin học

chỉ được áp dụng để thực hiện các công việc thường ngày, việc quản lý quy trình thực

hiện các chuỗi công việc chưa được hỗ trợ. Từ đó xuất hiện nhu cầu sử dụng tin học để

quản lý có hiệu quả các quy trình nghiệp vụ.

Năm 1998, tổ chức WfMC được thành lập với mục đích nghiên cứu và ứng dụng tin

học vào việc quản lý các quy trình nghiệp vụ. WfMC mong muốn xây dựng được hệ

thống quản lý quy trình nghiệp vụ, gọi tắt là BPMS (Business Process Management

System), một BPMS gồm hai phần chính sau:

Ø Phần hỗ trợ mô hình hóa quy trình nghiệp cụ (để định nghĩa các quy trình

nghiệp vụ trong thực tế): thông thường gồm một ngôn ngữ dùng để đặc tả quy

trình nghiệp vụ và các công cụ trực quan hỗ trợ người dùng thiết kế các quy

trình này.

Ø Phần hỗ trợ vận hành quy trình nghiệp vụ: thường gồm một động cơ vận hành

quy trình giúp quản lý việc vận hành quy trình cùng với các công cụ giúp

người dùng tham gia vào quá trình thực hiện quy trình nghiệp vụ.

Tuy nhiên hướng phát triển BPMS chưa có độ trưởng thành cao, đa số các BPMS vẫn

còn dừng lại ở mức nghiên cứu. Về ngôn ngữ đặc tả đã có những bước phát triển, xuất

hiện một số ngôn ngữ đặc tả chuẩn như XPDL, BPML. Về công cụ thiết kế và hỗ trợ vận

hành vẫn còn nhiều hạn chế.

Trong luận văn cử nhân tin học về đề tài “Tìm hiểu XPDL và xây dựng ứng dụng

minh hoạ” của hai sinh viên Trần Đăng Khoa và Phạm Minh Tuấn (Sinh viên khoa công

nghệ thông tin, trường Đại học Khoa học Tự nhiên) đã xây dựng thành công công cụ mô

hình hóa eXPDL. Trong khuôn khổ luận văn này, chúng em dự định nghiên cứu và xây

dựng ứng dụng hỗ trợ vận hành quy trình nghiệp vụ dựa trên đặc tả do công cụ mô hình

hóa eXPDL phát sinh.

Với đề tài “Nghiên cứu và xây dựng ứng dụng hỗ trợ vận hành tiến trình nghiệp

vụ (BPML) trên môi trường WEB ”, chúng em hy vọng góp một phần nhỏ vào việc ứng

dụng tin học quản lý các quy trình nghiệp vụ.


Trang 3

Mục lục

Danh mục các ký hiệu, các chữ viết tắt ........................................................................ 6

Danh mục các hình vẽ ..................................................................................................... 6

Danh mục các bảng ......................................................................................................... 7

Chương 1. Tổng quan .................................................................................................. 9

1.1. Tổng quan về quy trình nghiệp vụ: .................................................................... 9

1.1.1. Định nghĩa:...................................................................................................... 9

1.1.2. Các hướng nghiên cứu về tiến trình nghiệp vụ:............................................ 9

1.1.3. Cơ chế vận hành quy trình nghiệp vụ:......................................................... 13

1.1.4. Ưu và khuyết điểm của vận hành quy trình nghiệp vụ bằng WEB: .................. 14

1.2. Tổng quan về đề tài: ........................................................................................... 14

1.2.1. Các yêu cầu của đề tài: ................................................................................. 14

1.2.2. Kết quả đạt được:.......................................................................................... 14

1.2.3. Bố cục luận văn: ........................................................................................... 15

Chương 2. Giới thiệu một số ngôn ngữ mô hình hóa: .......................................... 16

2.1. Ngôn ngữ mô hình hóa XPDL: ......................................................................... 16

2.1.1. Lịch sử:.......................................................................................................... 17

2.1.2. Các đặc điểm chính của XPDL 2.0: ............................................................ 20

2.2. Ngôn ngữ mô hình hóa BPML:......................................................................... 22

2.2.1. Khái niệm:..................................................................................................... 22

2.2.2. Các thành phần chính:........................................................................................... 23

2.2.2.1. Công việc (Acitivity) :.................................................................................. 23

2.2.2.2. Các loại công việc (Activity types): ............................................................ 23

2.2.2.3. Ngữ cảnh công việc (The activity context):................................................ 23

2.2.2.4. Công việc đơn giản và công việc phức hợp (simple and complex activity):

........................................................................................................................ 24

2.2.2.5. Thể hiện công việc (Activity instance): ...................................................... 25

2.2.3. Quy trình (Process):...................................................................................... 26

2.2.4. Ngữ cảnh (Context): ..................................................................................... 31

2.2.5. Thuộc tính (Property): .................................................................................. 32

2.2.6. Tín hiệu (Signal):.......................................................................................... 34


Trang 4

2.2.7. Kế hoạch (Schedule): ................................................................................... 35

2.2.8. Ngoại lệ (Exception): ................................................................................... 35

2.2.9. Giao tác (Transaction):................................................................................. 38

2.2.10. Hàm (Function):............................................................................................ 40

2.3. Ngôn ngữ mô hình hóa eXPDL:........................................................................ 40

2.3.1. Giới thiệu: ..................................................................................................... 40

2.3.2. Những cải tiến của eXPDL so với XPDL và BPML:................................. 41

2.3.2.8. Hỗ trợ mô tả các quy trình có những hoạt động theo mẫu cột mốc: ......... 43

Chương 3. Giới thiệu tổng quan hệ thống .............................................................. 44

3.1. Ngữ cảnh phát triển hệ thống: .......................................................................... 45

3.2. Yêu cầu hệ thống cần xây dựng:....................................................................... 45

3.3. Ý nghĩa hệ thống: ................................................................................................ 45

3.4. Công cụ thiết kế: ................................................................................................. 46

3.4.1. Giới thiệu về công cụ mô hình hóa quy trình nghiệp vụ :.......................... 46

3.4.2. Một số chỉnh sửa công cụ MyXPDL cho phù hợp với việc quản lý quy

trình nghiệp vụ............................................................................................................... 47

3.5. Nguyên lý tổ chức hệ thống: .............................................................................. 47

3.6. Nguyên lý vận hành hệ thống:........................................................................... 47

3.7. Quy trình tổng quan:.......................................................................................... 48

Chương 4. Phân tích yêu cầu hệ thống ................................................................... 49

4.1. Các thành phần hỗ trợ trong luận văn:........................................................... 49

4.2. Các chức năng chính: ......................................................................................... 50

4.2.1. Quản lý quy trình mẫu:................................................................................. 50

4.2.2. Khởi tạo dự án: ............................................................................................. 50

4.2.3. Quản lý dự án:............................................................................................... 51

4.2.4. Thực hiện dự án: ........................................................................................... 52

4.2.5. Các chức năng quản trị:................................................................................ 52

4.3. Mô hình Use Case: .............................................................................................. 52

4.4. Đặc tả Actor:........................................................................................................ 53

4.5. Đặc tả Use Case:.................................................................................................. 53

Chương 5. Phân tích và thiết kế hệ thống .............................................................. 72


Trang 5

5.1. Thiết kế dữ liệu: .................................................................................................. 72

5.2. Một số lược đồ cơ sở dữ liệu: ............................................................................ 73

5.3. Thiết kế xử lý: ...................................................................................................... 74

5.3.1. Sơ đồ lớp: ...................................................................................................... 75

5.3.2. Một số mô hình chính:.................................................................................. 76

5.3.3. Một số luồng tuần tự chính trong ứng dụng:............................................... 79

5.4. Thiết kế giao diện:............................................................................................... 91

Chương 6. Thử nghiệm và đánh giá ........................................................................ 93

6.1. Một số quy trình mẫu:........................................................................................ 93

6.1.1. Quy trình đăng ký học phần:................................................................................ 93

6.1.2. Quy trình chuẩn bị thi thực hành: ........................................................................ 94

6.1.3. Quy trình xét tốt nghiệp cuối khóa ...................................................................... 94

6.2. Cài đặt và triển khai hệ thống: ......................................................................... 95

6.3. Đánh giá: .............................................................................................................. 95

Chương 7. Tổng kết và hướng phát triển ............................................................... 96

7.1. Những kết quả đạt được: ................................................................................... 97

7.1.1. Về mặt lý thuyết:........................................................................................... 97

7.1.2. Về mặt ứng dụng: ......................................................................................... 97

7.2. Ưu và khuyết điểm của hệ thống:..................................................................... 97

7.3. Hướng phát triển: ............................................................................................... 98

7.4. Lời kết:.................................................................................................................. 99

Tài liệu tham khảo......................................................................................................... 99

Phụ lục ...........................................................................................................................100

Phụ lục 1: Mô tả các bảng cơ sở dữ liệu ..................................................................100

Phụ lục 2: Các màn hình giao diện chính ................................................................117

Phụ lục 3: Quy trình đăng ký học phần...................................................................128


Trang 6

Danh mục các ký hiệu, các chữ viết tắt

WfMS Workflow Management System

WfMC Workflow Management Coalition

XPDL XML for Process Definition Language

BPML Business Process Modeling Language

BPEL Business Process Execution Language

BPMI Business Process Management Initiative

UML Unified Modelling Language

Danh mục các hình vẽ Hình 1 Mô hình hóa tiến trình nghiệp vụ ............................................................................... 9 Hình 2 Mô hình vận hình quy trình nghiệp vụ..................................................................... 13 Hình 3Sơ đồ chuyển đổi trạng thái thể hiện công việc trong BPML ................................. 26 Hình 4 Nguyên lý tổ chức hệ thống...................................................................................... 47 Hình 5 Nguyên lý vận hành hệ thống................................................................................... 48 Hình 6 Quy trình tổng quan .................................................................................................. 49 Hình 7 Mô hình Use Case ..................................................................................................... 53 Hình 8 Mô hình cơ sở dữ liệu tổng quan.............................................................................. 73 Hình 9 Lược đồ cơ sở dữ liệu phân công thực hiện công việc ........................................... 73 Hình 10 Lược đồ cơ sở dữ liệu tạo mới công việc .............................................................. 73 Hình 11 Lược đồ cơ sở dữ liệu tạo mới sản phẩm............................................................... 74 Hình 12 Sơ đồ lớp các đối tượng trong dự án...................................................................... 75 Hình 13 Sơ đồ lớp các đối tượng liên quan đến công việc ................................................. 76 Hình 14 Sơ đồ trạng thái công việc ...................................................................................... 76 Hình 15 Quy trình hiển thị cây dự án ................................................................................... 78 Hình 16 Quy trình tìm kích hoạt công việc tiếp theo .......................................................... 79 Hình 17 Lược đồ tuần tự tạo mới dự án theo mẫu............................................................... 80 Hình 18 Lược đồ tuần tự kích hoạt dự án ............................................................................ 81 Hình 19 Lược đồ tuần tự tạo mới thể hiện công việc .......................................................... 82 Hình 20 Lược đồ tuần tự tìm công việc tiếp theo trong dự án............................................ 83 Hình 21 Lược đồ tuần tự xử lý endevent ............................................................................. 84 Hình 22 Lược đồ tuần tự xử lý Gateway.............................................................................. 85 Hình 23 Lược đồ tuần tự thay đổi thông tin công việc........................................................ 86 Hình 24 Lược đồ tuần tự hiển thị cây tiến trình................................................................... 87 Hình 25 Lược đồ tuần tự upload sản phẩm.......................................................................... 88 Hình 26 Lược đồ tuần tự doawnload sản phẩm................................................................... 88 Hình 27 Lược đồ tuần tự thêm mới đối tượng..................................................................... 89 Hình 28 Lược đồ tuần tự luân chuyển sản phẩm................................................................. 90 Hình 29 Lược đồ tuần tự truy xuất cơ sở dữ liệu................................................................. 90 Hình 30 Menu chức năng hệ thống....................................................................................... 91 Hình 31 Cây tiến trình dự án................................................................................................. 91 Hình 32 Màn hình vận hành dự án ....................................................................................... 92


Trang 7

Hình 33 Màn hình báo cáo .................................................................................................... 93 Hình 34 Quy trình thi thực hành........................................................................................... 94 Hình 35 Quy trình xét tốt nghiệp cuối khóa......................................................................... 95 Hình 36 Màn hình thực hiện công việc ..............................................................................117 Hình 37 Màn hình tạo mới dự án........................................................................................118 Hình 38 Màn hình quy định thời gian thực hiện công việc...............................................119 Hình 39 Màn hình phân công user thực hiện công việc....................................................120 Hình 40 Màn hình chính thêm công việc vào dự án..........................................................121 Hình 41 Màn hình thêm sản phẩm......................................................................................122 Hình 42 Màn hình thêm cổng điều khiển...........................................................................123 Hình 43 Màn hình thêm kiểu dữ liệu tự định nghĩa ..........................................................124 Hình 44 Màn hình thêm luồng điều khiển vào quy trình ..................................................125 Hình 45 Màn hình quản lý sản phẩm..................................................................................126 Hình 46 Màn hình xem thông tin công việc.......................................................................127 Hình 47 Màn hình báo cáo dự án........................................................................................128 Hình 48 Quy trình đăng ký học phần .................................................................................129 Hình 49 Quy trình chuẩn bị công tác giảng dạy ................................................................129 Hình 50 Quy trình chuẩn bị đăng ký học phần lý thuyết ..................................................130 Hình 51 Quy trình đăng ký học phần lý thuyết..................................................................131 Hình 52 Quy trình chuẩn bị đăng ký thực hành.................................................................132 Hình 53 Quy trình đăng ký thực hành................................................................................133 Hình 54 Quy trình hiệu chỉnh học phần .............................................................................133 Hình 55 Quy trình đăng ký trả nợ.......................................................................................134 Hình 56 Quy trình tính toán và đóng học phí ....................................................................134 Hình 57 Các vai trò trong quy trình đăng ký học phần .....................................................135 Hình 58 Các sản phẩm trong quy trình đăng ký học phần ................................................135

Danh mục các bảng Bảng 1 Bản so sánh các loại khởi tạo quy trình................................................................... 28 Bảng 2 Bảng mô tả các trạng thái công việc........................................................................ 77 Bảng 3 CSDL mô tả người dùng ........................................................................................100 Bảng 4 CSDL mô tả quyền trong hệ thống........................................................................101 Bảng 5 CSDL mô tả sự phân quyền trong hệ thống..........................................................101 Bảng 6 CSDL lưu trữ các mẫu mô hình hóa......................................................................101 Bảng 7 CSDL lưu trữ các tập tin ........................................................................................102 Bảng 8 CSDL lưu trữ dự án ................................................................................................102 Bảng 9 CSDL lưu trữ mô hình............................................................................................103 Bảng 10 CSDL lưu trữ vai trò.............................................................................................103 Bảng 11 CSDL lưu trữ tiến trình ........................................................................................104 Bảng 12 CSDL lưu trữ công việc .......................................................................................104 Bảng 13 CSDL lưu trữ trạng thái mở rộng của công việc ................................................105 Bảng 14 CSDL lưu trữ sản phẩm........................................................................................105 Bảng 15 CSDL lưu trữ trạng thái mỡ rộng của sản phẩm.................................................106 Bảng 16 CSDL lưu trữ thuộc tính sản phẩm......................................................................106 Bảng 17 CSDL lưu trữ các sản phẩm vào/ra của công việc..............................................106


Trang 8

Bảng 18 CSDL lưu trữ phân vai trò thực hiện công việc..................................................107 Bảng 19 CSDL lưu trữ kiểu dữ liệu tự định nghĩa ............................................................107 Bảng 20 CSDL lưu trữ giá trị các kiểu dữ liệu tự định nghĩa...........................................107 Bảng 21 CSDL lưu trữ luồng tuần tự .................................................................................108 Bảng 22 CSDL lưu trữ điều kiện........................................................................................108 Bảng 23 CSDL lưu trữ biểu thức điều kiện nguyên tố ......................................................109 Bảng 24 CSDL lưu trữ cổng điều khiển.............................................................................109 Bảng 25 CSDL lưu trữ biến cố bắt đầu ..............................................................................110 Bảng 26 CSDL lưu trữ biến cố trung gian .........................................................................111 Bảng 27 CSDL lưu trữ biến cố kết thúc.............................................................................112 Bảng 28 CSDL lưu trữ bộ định giờ ....................................................................................112 Bảng 29 CSDL lưu trữ thể hiện công việc .........................................................................113 Bảng 30 CSDL lưu vết quá trình thực hiện công việc.......................................................113 Bảng 31 CSDL lưu trữ thể hiện sản phẩm .........................................................................114 Bảng 32 CSDL lưu trữ thể hiện sản phẩm đầu vào của công việc ...................................114 Bảng 33 CSDL lưu trữ thể hiện sản phẩm đầu ra của công việc......................................114 Bảng 34 CSDL lưu trữ thời gian thực hiện công việc.......................................................115 Bảng 35 CSDL lưu trữ phân công vai trò cho người dùng trong dự án...........................115 Bảng 36 CSDL lưu trữ câu hỏi ...........................................................................................116 Bảng 37 CSDL lưu trữ câu trả lời.......................................................................................116


Trang 9

Chương 1. Tổng quan

Trình bày tổng quan các vấn đề sẽ được nghiên cứu trong luận văn. Đồng thời

cung cấp một số định nghĩa, khái niệm ban đầu về các vấn đề liên quan đến luận

văn.

1.1. Tổng quan về quy trình nghiệp vụ:

1.1.1. Định nghĩa:

Là một tập hợp của một hoặc nhiều thủ tục hoặc công việc mà cùng chung mục

đích nghiệp vụ, thông thường trong ngữ cảnh của tổ chức định nghĩa các vai trò

chức năng và các mối quan hệ. 1

1.1.2. Các hướng nghiên cứu về tiến trình nghiệp vụ:

1.1.2.1. Về mô hình hóa tiến trình nghiệp vụ:

1.1.2.1.1. Mô hình hóa nghiệp vụ là gì?

Mô hình hóa tiến trình nghiệp vụ là việc định nghĩa các tiến trình nghiệp vụ

bằng cách sử dụng ngôn ngữ mô hình hóa tiến trình thích hợp. Hiện tại có rất

nhiều ngôn ngữ mô hình hóa tiến trình đang được nghiên cứu và phát triển nhưng

trong đó phổ biến nhất là 2 ngôn ngữ BPML và XPDL.

Hình 1 Mô hình hóa tiến trình nghiệp vụ2

Ngôn ngữ mô hình hóa tiến trình cần diễn đạt được các thành tố chính trong

tiến trình, thêm vào đó cũng cần diễn đạt được các thông tin phụ như tài nguyên,

việc phân tích, theo dõi, đo lường...Nhưng tại sao lại phải mô hình hóa tiến trình ? 1 Trang 3, Business Project Modeling Languages: Sorting through the alphabet soup, WfMC, 1999 2 Nghiên cứu và áp dụng các kỹ thuật hỗ trợ vận hành một số tiến trình phần mềm hửu dụng, luận văn thạc sĩ ngành tin học, TP HCM 2003


Trang 10

1.1.2.1.2. Mục đích của việc mô hình hóa:

Việc mô hình hóa quy trình nghiệp vụ nhằm các mục đích sau đây:

Ø Mô tả quy trình

Cung cấp một hệ thống đặc tả mang tính hình thức để thống nhất cơ chế giao

tiếp trao đổi tài liệu giữa các tổ chức.

Ø Phân tích quy trình

Dựa vào mô hình để xem xét cải tiến quy trình, phân tích nhằm tìm ra các thiếu

sót và hạn chế của quy trình.

Ø Thực thi quy trình

Mô phỏng hay cung cấp một mức độ hỗ trợ xử lý tự động nhất định cho các

quy trình nghiệp vụ.

Cung cấp hướng dẫn chi tiết cho các đối tượng tham gia vào tiến trình: nhờ đó

quá trình phối hợp thực hiện dễ dàng hơn.

1.1.2.1.3. Một số đặc điểm của các ngôn ngữ mô hình hóa:

XPDL,BPML, BPEL:

BPML, BPEL và XPDL là những ngôn ngữ định nghĩa tiến trình dựa trên

XML. Chúng cung cấp một mô hình hình thức để biểu thị những tiến trình có thể

thực hiện, những tiến trình này thể hiện tất cả diện mạo của tiến trình nghiệp vụ

của 1 công ty. Chúng dựa vào những mô hình đặc tả khác nhau.

Mỗi mô hình đều xem hoạt động (activities) như những phần tử cơ bản của sự

định nghĩa tiến trình. Mỗi hoạt động (activity) lại là 1 bộ phận của tiến trình đặc

biệt nào đó. Mỗi cái đều có thể hiện dữ liệu liên quan riêng có thể được đề cập đến

cổng lôgic và những biểu thức (expresstion).

Trong khi BPML và BPEL được xem như những ngôn ngữ lập trình có cấu

trúc khối, cho phép đệ quy các khối thì XPDL được xem như một ngôn ngữ có cấu

trúc đồ thị với những khái niệm bổ sung để điều khiển những khối.

BPML tập trung trong việc định nghĩa những dịch vụ mạng. BPEL cũng tập

trung trong vấn đề này và hướng giải quyết cũng tương tự với BPML. Trong khi

đó XPDL tập trung trên những vấn liên quan đến phân phối các công việc.


Trang 11

1.1.2.1.4. Các hướng nghiên cứu hiện nay:

Lĩnh vực mô hình hóa nghiệp vụ đang trong bước xây dựng và phát triển nên

có khá nhiều hướng nghiên cứu. Một số hướng tập trung vào việc đặc tả các

nghiệp vụ theo tính hướng sự kiện, một số khác lại xem xét mô hình nghiệp vụ

theo một lĩnh vực công nghiệp hay thương mại chuẩn. Trong đề tài này chúng em

xin được tập trung chủ yếu vào phương pháp mô hình hóa nghiệp vụ theo mô hình

luồng công việc (Workflow). Đây là mô hình xem xét quy trình nghiệp vụ tổng

quát dưới dạng các luồng thực thi có thứ tự, tập trung vào cơ chế mô tả nghiệp vụ

sao cho có thể đễ dàng lưu trữ và vận hành được trên máy tính. Mô hình

Workflow ra đời cách đây hơn 15 năm và hiện đang được xây dựng dần dần để

hoàn chỉnh về cấu trúc và ngữ nghĩa.

Một số hướng nghiên cứu chính về mô hình Workflow

ü Xây dựng các giao diện của mô hình Workflow

Để mô hình Workflow có khả năng hiểu được trong các hệ thống quản trị

luồng công việc, thì nó phải được cung cấp các giao diện ra “thế giới lập trình”

bên ngoài. Các giao diện này có thể được xem như các API chuẩn cung cấp khả

năng cho những thành phần bên ngoài có thể quản lý thông tin, giao tiếp, gọi các

hành vi ứng xử tương ứng trong mô hình.

ü Xây dựng hệ thống quản lý nghiệp vụ từ các mô hình Workflow :

Các hệ thống quản lý luồng công việc cung cấp khả năng đọc dữ liệu từ mô

hình đã được mô hình hóa, và cho phép vận hành, kiểm soát các mô hình này để tự

động hóa các nghiệp vụ thực tế. Hiện nay hướng nghiên cứu này đạt khá nhiều

thành tựu như : việc cung cấp các cơ chế động để hỗ trợ việc thực thi mô hình

workflow, giám sát ghi nhận các thông tin quản lý từ mô hình, cho phép phân

quyền và xử lý trên các thành phần thuộc mô hình khi thực thi.

ü Xây dựng cấu trúc mô hình luồng công việc ở mức meta :

Mô hình luồng công việc ở mức meta được định nghĩa ở mức trừu tượng hóa

cao nhất, nhằm cung cấp khả năng mở rộng mô hình luồng công việc ở mức tối đa.

Nó có ứng dụng rất mạnh trong việc chuyển đổi giữa các ngôn ngữ mô hình hóa


Trang 12

luồng công việc. Đồng thời từ mô hình này các ngôn ngữ mô hình hóa luồng công

việc có thể cung cấp những khả năng mở rộng khi cần thiết.

Đây là một trong những hướng nghiên cứu chính của các tổ chức mô hình hóa

lớn hiện nay. Điển hình là UML, WfMC, và BPMI. Tổ chức đang có những

nghiên cứu khá sâu về vấn đề này là WfMC. WfMC xây dựng một mô hình Meta

tương đối tốt và có cấu trúc tương tự với khá nhiều ngôn ngữ mô hình hóa khác.

Thông qua mô hình meta này có thể dễ dàng chuyển đổi giữa khá nhiều ngôn ngữ

mô hình hóa khác nhau thông qua việc ánh xạ về mô hình meta.

ü Xây dựng các ngôn ngữ mô hình hóa cho mô hình Workflow

Những nghiên cứu về ngôn ngữ mô hình hóa đi sâu vào việc phân tích khả

năng diễn đạt, xây dựng cú pháp, đặc tả các cấu trúc hỗ trợ cho các hệ quản trị

Workflow có thể phân tích và dễ dàng triển khai những mô hình xây dựng theo

các ngôn ngữ này.

Hiện tại có khá nhiều ngôn ngữ được xây dựng cho mô hình Workflow như :

XPDL, BPML, UML,… Tuy nhiên các ngôn ngữ này vẫn còn khá nhiều hạn chế

về khả năng diễn đạt cho các nghiệp vụ thực tế.

Bên cạnh đó còn có một số hướng tiếp cận khác đi sâu về lý thuyết các cơ chế

nghiệp vụ của mô hình luồng công việc : xây dựng phương pháp luận, tính toán

độ phức tạp, tính hiệu quả của các mô hình,...

1.1.2.2. Về vận hành tiến trình nghiệp vụ

1.1.2.2.1. Vận hành tiến trình nghiệp vụ là gì?

Vận hành tiến trình nghiệp vụ chính là quá trình xây dựng và phát triển nghiệp

vụ thực sự. Nếu một tiến trình được mô hình hóa hoặc định nghĩa trước đó bằng

các ngôn ngữ mô hình hóa tiến trình, việc vận hành tiến trình chính là việc trình

diễn lại những mô hình đã được mô hình hóa. Việc vận hành tiến trình được

những nhân viên tham gia phát triển tiến trình thực hiện thông qua các thao tác,

hành động


Trang 13

Hình 2 Mô hình vận hình quy trình nghiệp vụ3

1.1.2.2.2. Mục đích của vận hành tiến trình nghiệp vụ:

Tiến trình có thể được vận hành dưới sự kiểm soát và quản lý, hướng dẫn của

các động cơ tiến trình, đảm bảo các bước thực hiện đúng theo những mô hình tiến

trình đã được thiết kế, một số công việc đơn giản cũng có thể được thực hiện tự

động.

1.1.2.2.3. Hiện trạng:

Hiện nay cũng có nhiều cơ chế hỗ trợ vận hành một tiến trình phần mềm như:

hỗ trợ vận hành và quản lý tiến trình nghiệp vụ trên môi trường WEB, hỗ trợ vận

hành tiến trình bằng các hệ thống Agent hoặc các bằng các CaseTool, hỗ trợ vận

hành tập trung hoặc phân tán về mặt không gian, thời gian...Trên cơ sở khảo sát

một số cơ chế vận hành trong các môi trường PSEE hiện có Adele,Arcadia, ALF,

AP5, EPOS, Marvel, OIKOS, ProcessWeaver, SPADE,… chúng tôi thử nghiệm

xây dựng một Tool hỗ trợ việc vận hành tiến trình phần mềm được đặc tả bằng

ngôn ngữ eXPDL, hỗ trợ vận hành tiến trình nghiệp vụ trong một môi trường

WEB.

1.1.3. Cơ chế vận hành quy trình nghiệp vụ:

Quy trình nghiệp vụ được vận hành dựa vào một hệ thống quản lý luồng công

việc (Workflow Management System, gọi tắt là WfMS). WfMS xác định luồng

3 Nghiên cứu và áp dụng các kỹ thuật hỗ trợ vận hành một số tiến trình phần mềm hửu dụng, luận văn thạc sĩ ngành tin học, TP HCM 2003


Trang 14

công việc đã được định nghĩa trước trong định nghĩa quy trình nghiệp vụ. WfMS

quản lý các tài nguyên (ứng dụng, dữ liệu, con người) cần thiết để đạt được mục

tiêu của công việc, cung cấp khả năng theo dõi và điều khiển quy trình 4

1.1.4. Ưu và khuyết điểm của vận hành quy trình nghiệp vụ bằng WEB:

Ø Ưu điểm:

- Hỗ trợ tính chất phân tán của tiến trình rất mạnh.

- Tính không đồng nhất của tiến trình: do việc giao tiếp đều thông qua Web

nên các thành viên chỉ cần có một Web Browser để giao tiếp với hệ thống,

hoàn toàn không lệ thuộc vào môi trường thực hiện. - Hỗ trợ người dùng thực hiện công việc bất kỳ lúc nào

- Hỗ trợ làm việc nhóm thông qua mạng.

- Thực hiện liên kết với các quy trình nghiệp vụ khác trong nội bộ tổ chức.

Ø Khuyết điểm:

- Vấn đề bảo mật thông tin.

- Truyền thông chậm, đặc biệt việc kết nối cơ sở dữ liệu từ xa. Nếu dự án lớn

và đòi hỏi khối lượng thông tin trao đổi nhiều thì đây là khó khăn rất lớn.

1.2. Tổng quan về đề tài:

1.2.1. Các yêu cầu của đề tài:

Trong phạm vi nghiên cứu của luận văn chúng em dự kiến thực hiện một số

yêu cầu chủ yếu sau:

Ø Tìm hiểu về các ngôn ngữ mô hình hóa quy trình nghiệp vụ hiện nay.

Ø Tìm hiểu về vận hành quy trình nghiệp.

Ø Xây dựng ứng dụng hỗ trợ vận hành quy trình nghiệp vụ theo đặc tả của

một ngôn ngữ mô hình hóa.

1.2.2. Kết quả đạt được:

Ø Về mặt lý thuyết:

4 Micheal zur Muehlen và Rob Allen, Workflow classification Embeded & Autonomous Workflow Management System, Workflow Management Coalition, 10/3/2000.


Trang 15

o Kiến thức về vấn đề mô hình hóa và vận hành quy trình nghiệp vụ hiện nay.

Thực hiện so sánh đặc điểm của các ngôn ngữ mô hình hóa (trình bày trong

chương 1).

o Nguyên lý vận hành quy trình nghiệp vụ (trình bày trong chương 1)

o Kết quả nghiên cứu về ngôn ngữ mô hình hóa BPML (trình bày trong

chương 2).

o Kết quả nghiên cứu về ngôn ngữ mô hình hóa XPDL (trình bày trong

chương 2)

o Kết quả nghiên cứu về ngôn ngữ mô hình hóa eXPDL và công cụ mô hình

hóa MyXPDL (trình bày trong chương 2).

Ø Về mặt ứng dụng:

o Xây dựng ứng dụng hỗ trợ vận hành quy trình nghiệp vụ được đặc tả theo

ngôn ngữ eXPDL trên môi trường WEB. (trình bày trong chương 4,5).

o Ứng dụng hỗ trợ thiết kế và vận hành trực tiếp các quy trình đơn giản.

1.2.3. Bố cục luận văn:

Ø Chương 1: Tổng quan: Giới thiệu tổng quan về tiến trình nghiệp vụ, các ngôn

ngữ mô hình hóa và công cụ vận hành tiến trình nghiệp vụ hiện tại: các kết quả

đạt được, các vấn đề còn tồn động. Giới thiệu tổng quan về các yêu cầu và kết

quả đạt được của đề tài.

Ø Chương 2: Giới thiệu các ngôn ngữ mô hình hóa BPML phiên bản 1.0, XPDL

2.0, eXPDL.

Ø Chương 3: Giới thiệu tổng quan hệ thống: Giới thiệu các công cụ, ngôn ngữ

chính sử dụng, nguyên lý tổ chức hệ thống, một số quy trình tổng quan trong

hệ thống.

Ø Chương 4: Phân tích yêu cầu hệ thống: Bối cảnh ra đời, giới thiệu các chức

năng chính mà hệ thống cần phải xây dựng.

Ø Chương 5: Phân tích và thiết kế hệ thống: Trình bày về kỹ thuật thiết kế và xây

dựng ứng dụng iPMS.


Trang 16

Ø Chương 6: Thử nghiệm và đánh giá: Trình bày về thử nghiệm vận hành một số

quy trình nghiệp vụ, đánh giá kết quả đạt được và quá trình cài đặt và triển khai

hệ thống.

Ø Chương 7: Tổng kết và hướng phát triển: Tổng kết lại kết quả đạt được của

luận văn, ưu và khuyết điểm, cuối cùng đưa ra các hướng phát triển trong

tương lai.

Chương 2. Giới thiệu một số ngôn ngữ mô hình hóa:

Trình bày kiến thức tổng quát về các ngôn ngữ mô hình hóa: XPDL, BPML,

eXPDL. Đặc biệt là eXPDL, vì đặc tả quy trình nghiệp vụ theo eXPDL là đầu vào

cho việc xây dựng ứng dụng vận hành quy trình nghiệp vụ iPMS (Trình bày trong

chương 4,5).

XPDL, BPML, BPEL là những ngôn ngữ mô hình tiến trình được dùng cho

việc thực hiện tiến trình. Chúng không được sử dụng trực tiếp trong các pha phân

tích thiết kế. Được thể hiện trong bộ cú pháp của XML, chúng còn có một khuôn

dạng trao đổi riêng cho chính mình. Không có cái nào trong số chúng đưa ra được

bộ ký hiệu đồ họa chuẩn.Từ định nghĩa của chúng ta có thể thấy chúng thì chưa

được thiết kế để bao trùm các cấp độ của sự phân tích dây chuyền và có tổ chức.

WFMC là tổ chức đầu tiên phát triển một chuẩn thực hiện. Một phiên bản

XML mới của ngôn ngữ WFMC được phát hành vào năm 2002 dưới tên XPDL.

BPMI đã đưa ra 1 ngôn ngữ cạnh tranh vào năm 2001 được gọi là Ngôn ngữ

mô hình hóa tiến trình nghiệp vụ (BPML). Sáng kiến này khởi động lại những

công việc về những ngôn ngữ thực hiện tiến trình và làm ngày càng có nhiều đóng

góp tiếp sau đó như, BPEL. BPEL (Business Process Execution Language) được

bắt đầu bởi Microsoft và IBM để đáp lại sáng kiến của BPMI. Kể từ đó, ngôn ngữ

này đã nhận sự hỗ trợ của đa số người trên thị trường, bao gồm cả BPMI. BPEL đã

trở thành là chuẩn thực tế cho việc thực hiện qui trình nghiệp vụ. Nó có nhiệm vụ

chính là đặc tả các dịch vụ mạng. Từ năm 2003, một tổ chức có tính tiêu chuẩn là

OASIS đã mua và có trách nhiệm cho sự phát triển của ngôn ngữ BPEL..

2.1. Ngôn ngữ mô hình hóa XPDL:


Trang 17

2.1.1. Lịch sử:

STT Tên phiên bản Tác giả Đặc điểm chính

1 Version 1.0 Roberta Norin

2 Version 1.01 Mike Marin và Robert

Shapiro

Bản thảo ban đầu, ánh xạ 2 chiều đến

BPMN 1.0

3 Version 1.02 Mike Marin và Robert

Shapiro

Tổ chức lại tài liệu và thêm những siêu

mô hình (meta model) mới

4 Version 1.03 Robert Shapiro - Thêm phần chú thích dưới dạng

Text trong phần siêu mô hình của

BPMN

- Cập nhật lại những bảng và mô

hình riêng, thêm những mục

(section) cho tất cả các thành phần.

5 Version 1.04 Robert Shapiro - Một số thay đổi nhỏ trong mô hình:

thứ tự các phần tử và một số phần

tử được tạo tùy chọn.

- Ví dụ về gateways và events.

6 Version 1.05 Robert Shapiro - Một phần nhỏ thay đổi trong mô

hình: ProcessType - thứ tự của các

thành phần được giữ lại để tương

thích với phiên bản XPDL 1.0

- Một số lỗi nhỏ về in ấn.

- Thuộc tính Instantiate được loại bỏ

khỏi TaskSend và TaskService. Tài

liệu TaskSend được chỉnh sửa

- Giải thích mệnh đề OTHERWISE

được chuyển thành SPLITS. Chỉnh

sửa tài liệu về Splits và Joins trong


Trang 18

phần mở rộng của BPMN. Thêm tài

liệu vào mục Route Activity

- Những gói liên quan được mở rộng

bao gồm cả phần khai báo kiểu

- Thêm thuộc tính External Package

Reference

- Thêm sự tham khảo vào gói ngoài

(external package) cho những người

tham gia nhận biết.

7 Version 1.06 Robert Shapiro - Bao gồm tất cả những soạn thảo

thay đổi từ Justin Brunt

([email protected])

8 Version 1.07 Robert Shapiro - Bao gồm những thay đổi dựa trên

những yêu cầu của phiên bản

XPDL 1.0

- Chỉ số tham số hình thức (Formal

parameter index) không còn dùng

nữa

- Thuộc tính AccessLevel của tiến

trình được tạo tùy chọn với mặc

định là PUBLIC

- Thuộc tính Additional của dòng

con (Subflow) cung cấp tên của

vùng dữ liệu (datafield) trong đó

chứa instantiation id

- Thuộc tính Execution cho các

luồng con được tùy chọn với mặc

định là SYNCHR

mailto:[email protected]


Trang 19

- Thuộc tính GraphConformance

trong lớp Conformance được tùy

chọn với mặc định là

NON_BLOCKED.

- Điều kiện chuyển tiếp có thể có ở

bất cứ 1 thành phần con nào của

biểu thức

- “Kiểu” thuộc tính Tool được loại

bỏ : nó không còn được cần nữa kể

từ khi không có sự khởi dựng trong

việc khai báo Thủ tục (Procedures)

hoặc bất kỳ những thông tin nào về

tham số hình thức hoặc chuyển

tham số. Vì vậy kể từ giờ tất cả các

Tools phải chuyển là Applications.

- DeadlineCondition được loại bỏ.

Phần tử DeadlineDuration được

giới thiệu

Ví dụ làm lại sử dụng ký hiệu của

BPMN

9 Version 1.08 Mike Marin - Tăng cường tài liệu và mô hình với

những mẫu thuộc tính mở rộng mới

- Tất cả các kiểu mô hình (schema

types) được thêm vào tiếp đầu ngữ

‘t’

- Thay đổi thuộc tính

ExternalPackage id thành Id để


Trang 20

thích hợp với tất cả những Ids khác

- Bình thường hóa thuộc Name và id

cho tất cả các thực thể

- Thay đổi Assignment để có được

thực thể Đích (Target) và Biểu thức

(Expression)

- Thay đổi TaskScript để được biểu

thức tùy ý

- Giới thiệu kiểu tExpressionType

và sử dụng cho tất cả các biểu thức

- Cập nhật thêm mô hình ở tất cả các

mục(section)

- Thêm 1 mục (section) vào phiên

bản 1.0 để tượng thích

10 Version 1.09 Robert Shapiro - Những lỗi in của phiên bản trước

đã được chỉnh sửa

- Thuộc tính toolId được thay thế

bằng ToolId

- Kiểu thuộc tính Target được thay

đổi thành NMTIKEN

- Tất cả giản đồ thêm vào được cập

nhật cho cách tiếp cận mới sử dụng

namespace.

11 Version 2.0 Robert Shapiro, Mike

Marin, Justin Brunt và

Sasa Bojanic

- Phiên bản mới nhất hiện nay.

2.1.2. Các đặc điểm chính của XPDL 2.0:

Chúng em xin giới thiệu sơ lược về phiên bản mới nhất của XPDL 2.0


Trang 21

Phiên bản XPDL 2.0 thì tương thích với phiên bản XPDL 1.0, và được dự

định sẽ sử dụng như một dạng tập tin (file) cho BPMN. Mục đích nguyên thủy của

XPDL là phải được duy trì và tăng cường bởi phiên bản thứ hai này của bảng đặc

tả.

XPDL và bảng đặc tả BPMN đều có chung 1 vấn đề về mô hình từ những viễn

cảnh khác nhau. XPDL cung cấp 1 định dạng file XML mà từ đó ta có thể sử dụng

để trao đổi giữa những mô hình tiến trình và những công cụ. BPMN cung cấp một

bộ ký hiệu đồ họa để làm dễ dàng cho việc truyền thông của con người như giữa

những người dùng nghiệp vụ và người dùng kỹ thuật hoặc của những quy trình

nghiệp vụ phức tạp.

Có một số thành phần trong BPMN phiên bản 1.0 nhưng không được thể hiện

trong XPDL phiên bản 1.0. Tất cả các thành phần này được hợp nhất lại trong

phiên bản XPDL 2.0.

Phiên bản XPDL 2.0 tương thích với phiên bản XPDL 1.0. Tuy nhiên có một

số ngoại lệ phụ. Phiên bản XPDL 2.0 có một tên miền (namespace) khác, và

những công cụ muốn tương thích với phiên bản XPDL 1.0 cần hiểu cả XPDL 1.0

và tên miền của XPDL 2.0

Những thành phần trong phiên bản XPDL 1.0 sau đây đã được loại bỏ trong

phiên bản 2.0

• Thành phần Automatic. Thay thế bởi thuộc tính Mode trong thành

phần StartMode và FinishMode

• Thuộc tính BlockId của thành phần BlockActivity. Thay thế bởi

ActivitySetId.

• Thành phần DeadlineCondition. Thay thế với DeadlineDuration.

• Thuộc tính Index trong thành phần FormalParameter. Vì

FormalParameters phải phù hợp với thứ tự trong khai báo, và như vậy

không cần thiết phải có thuộc tính Index

• Thành phần Manual. Thay thế bởi thuộc tính Mode trong thành

phần FinishMode và StartMode


Trang 22

• Thuộc tính Type của thành phần Tool. Vì những công cụ là những

ứng dụng và như vậy thuộc tính này không phải là cần thiết. ( những công

cụ không thể là những thủ tục – từ WPDL - vì XPDL không cung cấp bất

kỳ những cách định nghĩa tham số hình thức cho những thủ tục nào.)

• Thành phần Xpression bên trong thành phần Condition. Thay thế

bởi Expression

• Thứ tự trong một WorkflowProcess thay đổi từ DataFields,

Participants, và Applications thành Participants, Applications, và

DataFields.

2.2. Ngôn ngữ mô hình hóa BPML:

2.2.1. Khái niệm:

Ø Phiên bản mới nhất BPML 1.0.

Ø Đặc tả BPML cung cấp một mô hình trừu tượng và cấu trúc XML cho

việc diễn tả các quy trình nghiệp vụ có thể thực hiện và hỗ trợ các thực

thể.BPML định nghĩa một mô hình hình thức cho việc diễn tả các quy

trình nghiệp vụ một cách trừu tượng và có thể thực thi được mà nhắm

đến tất cả các khía cạnh của của quy trình nghiệp vụ phát triển, bao

gồm các công việc ở các mức độ phức tạp khác nhau, các giao tác và

cơ chế đền bù giao tác, sự quản lý dữ liệu, sự nhất quán, bắt lỗi và các

ngữ nghĩa toán học (operational semantics). BPML cũng cung cấp một

cấu trúc ngữ pháp dưới dạng lược đồ XML cho việc duy trì và trao đổi

định nghĩa giữa các hệ thống và công cụ mô hình hóa không thống

nhất nhau. BPML tự nó không định nghĩa bất kỳ một ngữ nghĩa ứng

dụng nào cụ thể ví dụ như các quy trình cụ thể hay các quy trình trong

một lĩnh vực cụ thể. Thay vào đó, nó định nghĩa một mô hình trừu

tượng và ngữ pháp cho việc diễn tả các quy trình chung. Điều này cho

phép BPML có thể được sử dụng cho nhiều mục đích khác nhau bao

gồm, nhưng không hạn chế, định nghĩa các quy trình nghiệp vụ phát

triển (enterprise business processes), định nghĩa các dịch vụ WEB


Trang 23

phức tạp, và định nghĩa sự tương tác giữa nhiều đối tác cung cấp

(multi - party) với nhau. 5

Ø Là một ngôn ngữ hình thức, độc lập với nền tảng (flatform)/ phần

mềm, do đó các công ty có thể diễn tả rõ ràng quy trình nghiệp vụ của

họ dưới dạng biểu mẫu có thể chỉnh sủa và thực hiện được. 6

Ø Có thể cho phép tất cả các đối tượng tham gia trong việc thiết kế, triển

khai, thực hiện, bảo trì và tối ưu hóa quy trình quản lý các công việc

nghiệp vụ trong mô hình hướng quy trình (process – oriented fashion)

trong khi vẫn giữ nguyên tính toàn vẹn trong liên kết quy trình nghiệp

vụ.

2.2.2. Các thành phần chính:

Trong khuôn khổ luận văn chúng em xin giới thiệu tổng quan một số thành

phần chính và quan trong trong BPML.

2.2.2.1. Công việc (Acitivity) :

Là thành phần thực hiện một chức năng cụ thể. Các công việc phức tạp là sự

kết hợp của các công việc khác và hướng trực tiếp đến sự thực hiện của chúng.

Một quy trình là một sự kết hợp của các công việc và có thể nó là một công việc

trong một quy trình khác lớn hơn. Ngữ nghĩa của một công việc được áp dụng cho

định nghĩa quy trình với một số ngoại lệ.

2.2.2.2. Các loại công việc (Activity types):

BPML định nghĩa tất cả 17 loại Activity và 3 loại Process. Tất cả các loại

Activity đều được xuất phát từ một loại cơ bản thông dụng (common base type)

sau. Các thuộc tính của loại cơ bản:

- name: Tên công việc

- documentation: Tài liệu mô tả công việc.

- other: Các thuộc tính khác định nghĩa cho 1 loại Activity cụ thể.

2.2.2.3. Ngữ cảnh công việc (The activity context): 5 Business Process Modeling Language, 13/11/2002, Assaf Arkin, Intalio 6 IEEE Workshop on advanced issues of e-commerce and web-based information system, 26-28/6/2002, Newport Beach, California.


Trang 24

Các công việc mà thực hiện trong cùng ngữ cảnh sử dụng ngữ cảnh để trao đổi

thông tin thông qua thuộc tính được định nghĩa trong ngữ cảnh. Ví dụ, một công

việc nhận vào một thông điệp thiết lập các giá trị cho một thuộc tính từ nội dung

của thông điệp. Một chuỗi tuần tự con các công việc sử dụng giá trị của thuộc tính

vừa được tạo để tạo và gửi một thông điệp ra.

Ngữ cảnh định nghĩa tính chất thông dụng cho tất cả các công việc trong ngữ

cảnh đó, ví dụ bắt các điều kiện và lỗi ngoại lệ, cung cấp các ngữ nghĩa nguyên tố,

định nghĩa rang buộc thời gian…

Các công việc và ngữ cảnh được xây dựng theo kiểu phân cấp. Ngữ cảnh hiện

tại của công việc này có thể là ngữ cảnh con của một vài ngữ cảnh khác, và cũng

có thể là “cha” của nhiều ngữ cảnh con khác.

2.2.2.4. Công việc đơn giản và công việc phức hợp (simple and

complex activity):

Ø Công việc đơn giản (Simple activity): là một con việc mà không thể phân

rã nhỏ hơn. Các loại công việc đơn giản được định nghĩa trong BPML:

o Action: Thực hiện hoặc gọi một hành động liên quan đến trao đổi các

thông điệp vào và ra.

o Assign: Gán một giá trị mới cho thuộc tính.

o Call: Tạo mới một quy trình và chờ cho quy trình hoàn tất.

o Compensate: Gọi thực hiện đền bù (compensation) cho các quy trình

đã được đặt tên.

o Delay: Diễn tả sự trôi đi của thời gian.

o Emty: Không làm gì hết.

o Fault: Phát ra lỗi trong ngữ cảnh hiện tại.

o Raise: Phát sinh một tín hiệu.

o Spawn: Khởi tạo một quy trình nhưng không chờ cho quy trình hoàn

tất.

o Synch: Đồng bộ hóa trên một tín hiệu


Trang 25

Ø Công việc phức hợp (Complex activity): Là sự kết hợp của một hoặc

nhiều công việc. Các công việc có thể là đơn giản hoặc phức hợp. Một công

việc phức hợp chức một tập một hoặc nhiều công việc và hướng trực tiếp

đến sự thực hiện của các công việc từ một trong các tập công việc này.

Các loại công việc phức hợp được định nghĩa trong BPML:

o All: Thực hiện các công việc song song.

o Choice: Thực hiện các công việc từ một trong tập các công việc, được

chọn thực hiện để đáp ứng cho một sự kiện.

o Foreach: Thực hiện các công việc một lần cho mỗi công việc trong

danh sách các công việc.

o Sequence: Thực hiện các công việc theo thứ tự tuần tự.

o Switch: Thực hiện các công việc từ một trong tập các công việc, được

chọn dựa vào giá trị đúng của điều kiện.

o Until: Thực hiện các công việc một hoặc nhiều lần dựa vào giá trị đúng

của điều kiện.

o While: Thực hiện các công việc không hoặc nhiều lần dựa vào giá trị

đúng của điều kiện.

2.2.2.5. Thể hiện công việc (Activity instance):

Sự định nghĩa công việc chỉ rõ một thể hiện công việc sẽ được thực hiện như

thế nào. Nhiều thể hiện của công việc đó có thể được thực hiện song song. Mặc dù

các thể hiện này được khởi tạo từ cùng một định nghĩa công việc, chúng là khác

nhau và không có liên quan trực tiếp với nhau.

Các trạng thái của một thể hiện công việc:

o Ready: Thể hiện công việc chưa thực hiện bất kỳ công việc nào. Ở trạng

thái này chúng ta có thể thực hiện bỏ qua công việc, khi đó nó chuyển qua

“Cancelled” (tức là công việc bị hủy bỏ).

o Active: Thể hiện công việc đang thực hiện công việc cụ thể theo định nghĩa

của nó.


Trang 26

o Completing: Thể hiện công việc đã thực hiện tất cả các công việc mà nó

được định nghĩa, và bây giờ đang thực hiện tất cả các công việc được yêu

cầu để hoàn tất.

o Completed: Thể hiện công việc đã thực hiện tất cả các công việc được yêu

cầu để hoàn tất.

o Aborting: Thể hiện công việc không thể hoàn tất công việc được định

nghĩa và đang thực hiện tất cả các công việc được yêu cầu để bỏ qua (kết

thúc thất bại). Một số công việc mà thể hiện công việc phải thực hiện khi ở

trạng thái này: kiểm soát lỗi, kết thúc giao tác, thực hiện đền bù…

o Aborted: Thể hiện công việc đã thực hiện tất cả các công việc được yêu

cầu để bỏ qua.

Sơ đồ chuyển đổi trạng thái:

Hình 3Sơ đồ chuyển đổi trạng thái thể hiện công việc trong BPML

2.2.3. Quy trình (Process):

Quy trình là một loại công việc phức hợp mà định nghĩa trong nó ngữ cảnh cho

sự thực thi. Quy trình bao gồm nhiều công việc và hướng trực tiếp đến sự thực thi

của các công việc này. Quy trình có thể xem như là một công việc của một quy

trình lớn hơn. Quy trình thường được định nghĩa như một đơn vị có tính tái sử

dụng của công việc.

2.2.3.1. Sự khởi tạo quy trình:

Tuỳ theo định nghĩa quy trình mà chúng ta có ba cách khởi tạo sau:


Trang 27

Ø Activity: Các công việc loại call, compensate, và spawn được dùng để khởi

tạo định nghĩa quy trình mà có sự thể hiện loại activity. Các quy trình đang

khởi tạo và đã khởi tạo phải ở cùng ngữ cảnh hoặc các ngữ cảnh liên quan.

Định nghĩa quy trình đang khởi tạo phụ thuộc vào quy trình đã khởi tạo.

Hai quy trình này gắn kết chặt chẽ với nhau.

Ø Message: Một quy trình được khởi tạo để trả lời cho một thông điệp đầu

vào có thể được triển khai như một dịch vụ độc lập và có thể được khởi tạo

từ các tiến trình được triển khai trong các hệ thống khác hoặc trong các hệ

thống mạng. Các quy trình như vậy không gắn kết chặt chẽ với nhau và có

thể được triển khai và thực hiện trong môi trường không thống nhất suy ra

độc lập từ những quy trình khác. Tất cả các công việc phát sinh sự kiện

phải là “action activities”.

Ø Signal: Một quy trình được khởi tạo để đáp ứng cho việc phát sinh một tín

hiệu chỉ có thể được khởi tạo trong ngữ cảnh của đối tượng. Một quy trình

lưới (nested process) có thể đáp ứng một tín hiệu được phát sinh bởi các

công việc khác đang mà thực thi trong cùng ngữ cảnh. Hình thức khởi tạo

này chỉ được thực hiện đối với các quy trình được định nghĩa như một phần

của quy trình khác lớn hơn, ví dụ như nested processes và exception

processes. Tất cả các công việc phát sinh sự kiện phải là “synch activities”.

Bảng so sánh ba cách khởi tạo tiến trình: để tiện cho việc tham khảo chúng em

xin giữ nguyên bảng so sánh gốc bằng tiếng anh.

Instantation Definition Inputs Instantiating

activity

Activity No event Parameter Call, compensate,

spawn, schedule

Message Event activity=a

Action name=a

Receive

messageA Send messageA


Trang 28

messageA

Message Event activity=a b

Exclusive=true

Action name=a

Receive messgeA

Action name=b

Receive messageB

messageA or

messageB

Send messageA or

messageB

Event activity=a b

Exclusive=false

Action name=a

Receive messgeA

Action name=b

Receive messageB

messageA and

messageB

Send messageA

and messageB

Signal Event activity=a

Synch name=a

signalA condA

signalA Raise signalA

Signal Event activity=a b

Exclusive= true

Synch name=a

signalA condA

synch name=b

signalB condB

signalA or signalB Raise signalA or

signalB

Signal Event activity=a b

Exclusive= false

Synch name=a

signalA condA

synch name=b

signalB condB

signalA and

signalB

Raise signalA and

signalB

Bảng 1 Bản so sánh các loại khởi tạo quy trình


Trang 29

Nếu quy trình không được định nghĩa để tương tác với các công việc khác

đang thực hiện trong cùng ngữ cảnh, hoặc không được khởi tạo bởi quy trình khác

được định nghĩa trong cùng ngữ cảnh thì định nghĩa nên được khởi tạo theo loại

“message”.

2.2.3.2. Nested process:

Là sự định nghĩa quy trình được áp dụng cho một ngữ cảnh cho trước. Nested

process được dùng như một công việc trong một quy trình lớn hơn, để cục bộ hóa

sự định nghĩa quy trình trong ngữ cảnh mà nó được sử dụng, và để ràng buộc sự

khởi tạo và có giá trị của quy trình đối với ngữ cảnh cụ thể.

Nested process được khởi tạo trong ngữ cảnh mà nó được định nghĩa, có thể

truy cập các thuộc tính được định nghĩa trong ngữ cảnh đó, khởi tạo các quy trình

khác mà được định nghĩa trong ngữ cảnh đó, sử dụng tín hiệu để tương tác với các

công việc khác được định nghĩa trong cùng ngữ cảnh, và sử dụng các quy trình

ngoại lệ (exception processes) và bắt lỗi (fault handler) được định nghĩa bởi ngữ

cảnh.

Một “top – level process” là một định nghĩa quy trình mà không áp dụng cục

bộ cho bất kỳ ngữ cảnh cụ thể nào, nó được định nghĩa tại cấp độ gói (package

level) và không chia ngữ cảnh của nó với các “top – level process” khác. “Top –

level process” có thể được khởi tạo bất kỳ lúc nào. “Top – level process” không sử

dụng loại khởi tạo “signal activity”.

“Exception process” là một loại nested process đặc biệt. Khi “exception

process” được khởi tạo thì nó buộc công việc cha phải huỷ bỏ. Trong khi đó

“nested process” có thể được khởi tạo nhiều lần trong một ngữ cảnh đối tượng, chỉ

duy nhất một “exception process” được khởi tạo trong một ngữ cảnh đối tượng

cho trước.

“Compensation process” là một dạng “nested process” đặc biệt khác. Một

“compensation process” được khởi tạo sau khi thể hiện quy trình cha hoàn tất để

đền bù cho bất kỳ công việc nào mà nó đã thực hiện. “Compensation process” chỉ


Trang 30

được khởi tạo nếu thể hiện quy trình cha đã hoàn tất và có thể được khởi tạo duy

nhất một lần.

2.2.3.3. Định nghĩa quy trình (process definition):

Bao gồm các thuộc tính sau:

Name :tên quy trình.

Documentation: tài liệu mô tả quy trình.

Identity: Một hoặc nhiều tên định danh.

Persistent: thuộc tính sự liên tục.

Event: sự kiện khởi tạo.

Paranmeters: không có hoặc có nhiều tham số đầu vào.

Activity set: một tập các công việc.

Compensation: compensation process.

2.2.3.4. Tham số (parameter):


Name: tên tham số.

Direction: input, output.

Requyre: true nế được yêu cầu, mặc định là false.

Code: mã số lỗi (chỉ dành cho output).

Thuộc tính direction xác định tham số là tham số vào hay tham số ra.

• Input: Khi một quy trình được khởi tạo, một giá trị đầu vào của tham số

được gắn cho một thuộc tính đã được đặt tên trong quy trình.

• Output: Khi một tiến trình hoàn thành hay bỏ dở (abort), giá trị của thuộc

tính thể hiện quy trình được sử dụng như một giá trị ra cho tham số.

2.2.3.5. Định danh quy trình (process indentity):

Định danh quy trình phục vụ như một phương tiện để xác định một thể hiện

quy trình cụ thể từ một tập hợp các thể hiện quy trình được khởi tạo từ cùng một

định nghĩa. Nó cũng xác định các thể hiện quy trình liên quan trong một tập hợp

các thể hiện được khởi tạo từ các định nghĩa khác nhau.

Cấu trúc định danh


Trang 31

Name: tên định danh

Properties: một hoặc nhiều thuộc tính.

Documentation: tài liệu mô tả.

2.2.4. Ngữ cảnh (Context):

Ngữ cảnh định nghĩa một môi trường cho việc thực thi các công việc liên quan.

Các công việc thực thi trong cùng ngữ cảnh sử dụng ngữ cảnh cho việc trao đổi

thông tin và phối hợp hoạt động. Một công việc có thể truy cập và sửa đổi giá trị

của thuộc tính được định nghĩa trong ngữ cảnh, khởi tạo một “nested process”,

phát và đồng bộ hóa tín hiệu…

Ngữ cảnh định nghĩa các thuộc tính thông dụng cho tất cả các công việc đang

thực hiện trong nó.Nó định nghĩa các điều kiện ngoại lệ và lỗi được quản lý như

thế nào, cung cấp các ngữ nghĩa nguyên tố cho việc truy xuất thuộc tính và trao

đổi thông điệp…

Một định nghĩa ngữ cảnh chứa các định nghĩa cục bộ (local definitions) cho

các thực thể mà chỉ có thể truy cập trong ngữ cảng đó. Định nghĩa ngữ cảnh có thể

được kế thừa.

Có hai loại ngữ cảnh: Current context và Process context.

• Current context: Là ngữ cảnh mà trong đó một công việc được định nghĩa,

bao gồm ngữ cảnh chứa định nghĩa công việc và tất cả các ngữ cảnh cha.

• Process context: Là ngữ cảnh được dùng chung cho tất cả các công việc

thực hiện như một phần của định nghĩa quy trình. Ngữ cảnh này phục vụ

như là ngữ cảnh cha cho ngữ cảnh của nested và exception process.

Ngữ cảnh tiến trình của “top – level process” được gọi là root context, vì nó

không là ngữ cảnh con của bất kỳ ngữ cảnh cha nào.

Các thể hiện ngữ cảnh được khởi tạo từ cùng định nghĩa ngữ cảnh là khác nhau

và không dùng chung bất kỳ thể hiện nào của định nghĩa cục bộ. Đặc biệt, hai thể

hiện “top – level process” không dùng chung bất kỳ thể hiện thuộc tính , thể hiện

công việc và thể hiện của “nested process”.

2.2.4.1. Định nghĩa cục bộ (Local definition): bao gồm 6 loại sau:


Trang 32

• Exception: Định nghĩa một “exception process” cục bộ đối với ngữ cảnh

để đảm bảo các quy trình chỉ đáp ứng các sự kiện từ thể hiện của ngữ cảnh

đó, và tất cả các sự kiện dừng tất cả các công việc đang thực hiện trong thể

hiện ngữ cảnh đó.

• Process: Định nghĩa một quy trình cục bộ đối với ngữ cảnh để đảm bảo các

quy trình chỉ có thể được khởi tạo trong thể hiện của ngữ cảnh đó.

• Property: Định nghĩa một thuộc tính cục bộ trong ngữ cảnh để đảm bảo

giá trị của thể hiện thuộc tính chỉ có thể được truy cập và sửa đổi từ các

công việc đang thực hiện trong thể hiện của ngữ cảnh đó. Nó được dùng để

giới hạn quyền truy cập đối với thuộc tính.

• Schedule: Định nghĩa một kế hoạch cục bộ trong ngữ cảnh để đảm bảo kế

hoạch sẽ phát sinh các sự kiện thời gian trong khi các công việc đang thực

hiện trong thể hiện của ngữ cảnh.

• Signal: Định nghĩa một tín hiệu cục bộ trong ngữ cảnh để đảm bảo tín hiệu

chỉ có thể được phát sinh và được đồng bộ hóa bởi các công việc đang thực

hiện trong thể hiện của ngữ cảnh.

2.2.4.2. Định nghĩa ngữ cảnh (Context definition): bao gồm các thuộc

tính sau:

Atomic: True nếu là ngữ cảnh nguyên tố.

Exception: Không hoặc nhiều “exception process”.

Processes: Không hoặc nhiều định nghĩa quy trình.

Properties: Không hoặc nhiều định nghĩa thuộc tính.

Schedule: Không hoặc nhiều định nghĩa kế hoạch.

Signals: Không hoặc nhiều định nghĩa tín hiệu.

Faults: Không hoặc nhiều bộ quản lý lỗi.

2.2.5. Thuộc tính (Property):

Một định nghĩa thuộc tính khai báo tên, kiểu và cung cấp một giá trị khởi tạo

ban đầu (có thể không có). Một thể hiện thuộc tính giữ giá trị của thuộc tính.


Trang 33

Một thể hiện ngữ cảnh không thể có hai thể hiện thuộc tính cùng tên. Hai thể

hiện thuộc tính cùng tên là khác nhau nếu chúng thuộc hai thể hiện ngữ cảnh khác

nhau.

Thể hiện thuộc tính được khởi tạo khi một trong các điều sau xẩy ra:

• Định nghĩa thuộc tính khởi gán giá trị ban đầu khi thể hiện ngữ cảnh được

tạo.

• Định nghĩa thuộc tính được xác định bởi một thuộc tính tham chiếu

(reference attribute) và một thể hiện thuộc tính với cùng định nghĩa tồn tại

trong thể hiện ngữ cảnh cha khi một thể hiện ngữ cảnh được tạo. Thể hiện

thuộc tính sẽ có cùng giá trị với thể hiện thuộc tính mà nó được tham chiếu.

• Một giá trị được gán đầu tiên từ bất kỳ công việc nào thực hiện trong thể

hiện của ngữ cảnh đó hoặc trong một ngữ cảnh con.

Một công việc chỉ có thể truy cập giá trị của thuộc tính khi đã có thể hiện thuộc

tính.

2.2.5.1. Các loại thuộc tính:

• Đơn giản: Loại thuộc tính chỉ có thể là một trong các loại đơn giản được

định nghĩa bởi lược đồ XML hoặc một loại được xuất phát từ nó. Giá trị

thuộc tính là 1 giá trị nguyên tố của loại đó hoặc xuất phát từ loại đó và

cũng có thể là rỗng.

• Phức hợp: Loại thuộc tính là kiểu phức hợp được định nghĩa bởi lược đồ

XML. Giá trị thuộc tính cũng là giá trị phức hợp. Giá trị thuộc tính chỉ có

thể là rỗng nếu định nghĩa kiểu phức hợp cho phép một trình tự rỗng.

• Thành phần (element): Thuộc tính là một thành phần được định nghĩa bởi

sự khai báo lược đồ XML . Giá trị không được phép rỗng.

2.2.5.2. Thuộc tính cố định và thuộc tính ẩn:

Giá trị của thể hiện thuộc tính cố định không thể bị sửa đổi. Khi nó được khởi

tạo, giá trị của nó trở thành hằng. Nếu định nghĩa thuộc tính cố định không gán giá

trị ban đầu, một giá trị được gán cho thuộc tính khi nó khởi tạo thể hiện.


Trang 34

2.2.5.3. Biểu thức điều kiện (Expression):

Biểu thức điều kiện dùng để thiết lập giá trị động cho thuộc tính và có thể được

dẫn xuất từ giá trị của một hoặc nhiều thuộc tính.

2.2.5.4. Định nghĩa thuộc tính (Property definition):


Name

Type

Value

Fixed

Documentation

Định nghĩa thuộc tính được tham chiếu:

Reference: tên định nghĩa được tham chiếu.

Value

Fixed

Documentation

2.2.6. Tín hiệu (Signal):

Tín hiệu được dùng để phối hợp sự thực hiện của các công việc trong cùng ngữ

cảnh

“Raise activity” phát tín hiệu bằng cách khởi tạo một thể hiện tín hiệu. “Synch

activity” đồng bộ hóa trên tin hiệu bằng cách chờ cho tín hiệu được phát sinh, và

sau đó giảm tín hiệu bằng cách loại bỏ một thể hiện tín hiệu. “Raise activity” và

“Synch activity” có thể trao đổi thông tin bằng các truyền giá trị thông qua thể hiện

tín hiệu.

Thể hiện tín hiệu được tạo trong thể hiện của ngữ cảnh chứa định nghĩa của nó.

Định nghĩa tín hiệu:

Name: Tên tín hiệu.

Documentation: Tài liệu mô tả.

Type: loại giá trị.

Multi: đa tín hiệu hay đơn tín hiệu.


Trang 35

Source: nguồn của tín hiệu như một thuộc tính.

Value: Giá trị ban đầu.

2.2.7. Kế hoạch (Schedule):

Đại diện cho một chuỗi các sự kiện thời gian. Nếu sự kiện thời gian được tính

toán từ các thể hiện thuộc tính thì sự kiện thời gian có thể đươc thay đổi bằng cách

gán giá trị mới cho các thuộc tính này. Kế hoạch có thể được sửa đổi, hủy bỏ hoặc

làm phát sinh một sự kiện thời gian khác. Kế hoạch cũng có thể đại diện cho một

rang buộc về thời gian bằng cách phát sinh một lỗi buộc các công việc hoặc quy

trình liên quan phải bỏ dở.

Thể hiện kế hoạch được tạo từ sự định nghĩa kế hoạch. Thể hiện kế hoạch theo

dấu sự kiện thời gian tiếp theo và kích hoạt tại một thời gian xác định.

Thể hiện kế hoạch tính toán sự kiện thời gian tiếp theo dựa vào các đặc điểm

sau:

• Giá trị của thể hiện thuộc tính cung cấp sự kiện thời gian tiếp theo.

• Giá trị của thuộc tính duration đựơc thêm vào thể hiện thời gian tại thời

điểm kế hoạch được tạo.

• Giá trị của thuộc tính repeat được thêm vào thể hiện thời gian hiện hành

Định nghĩa kế hoạch:

Name

Documentation

Process: Tên quy trình.

Code: Mã số lỗi.

Duration

Instant

Reapeat

Other: Các cơ chế khác.

2.2.8. Ngoại lệ (Exception):

Một quy trình phải có khả năng phát hiện các điều kiện ngoại lệ nếu chúng

được giao tiếp bởi các quy trình khác sử dụng các thông điệp, báo hiệu bằng tín


Trang 36

hiệu, hoặc là kết quả của các công việc mà thất bại để hoàn tất. Quy trình tác động

trở lại các điều kiện ngoại lệ này sử dụng “exception process” và bộ kiểm soát lỗi.

2.2.8.1. Quy trình ngoại lệ (Exception process):

Các biến cố ngoại lệ có thể xẩy ra làm cho các công việc và quy trình không

thể hoàn tất thành công. Các biến cố ngoại lệ có thể được phát sinh từ các thông

điệp vào, yêu cầu quy trình phải kết thúc tất cả các công việc và hoàn tất ngay tức

thì, hoặc từ một nguồn phát sinh một tín hiệu thông báo điều kiện ngoại lệ.

Exception process chỉ được khởi tạo một lần trong một thể hiện ngữ cảnh và chỉ

đáp ứng cho một thông điệp vào hoặc một tín hiệu được phát sinh. Khi nó được

khởi tạo tất cả các công việc đang thực hiện trong ngữ cảnh đó bị kết thúc.

Exception process cắt ngang sự thực hiện của một công việc cha và buộc nó

phải bỏ dở. Công việc định nghĩa các “exception process” cắt ngang nó trong một

ngữ cảnh con. Sự cắt ngang chỉ có thể xảy ra khi công việc đang ở trạng thái

“active”

Định nghĩa “exception process” giống như định nghĩa “nested process”, với

một số khác biệt sau:

• “Exception process” không hỗ trợ kiểu khởi tạo “activity”, và không thể

đuợc khởi tạo từ các loại công việc “call”,”spawn”. Thuộc tính tham số

không được hỗ trợ.

• Bởi vì chỉ có một “Exception process” được khởi tạo trong một thể hiện

ngữ cảnh, nên nó có cùng định danh như quy trình cha. Thuộc tính

“identity” không được hỗ trợ.

• “Exception process” không được đền bù. Thuộc tính “compensation” không

được hỗ trợ.

Một thể hiện “Exception process” tồn tại nếu thể hiện quy trình cha tồn tại.

Thuộc tính “persistent” không được hỗ trợ.

2.2.8.2. Lỗi và kiểm soát lỗi (Fault và Fault handler):

Một lỗi là một điều kiện sai mà ngăn một công việc kết thúc thành công, hoặc

phục hồi từ một lỗi khác.


Trang 37

Các công việc phức hợp có thể phục hồi lại từ một lỗi bằng cách thực hiện

kiểm soát lỗi (Fault handler). Kiểm soát lỗi được thực hiện sau “exception

process”. Điều này cho phép các công việc cha bỏ dở mà không để lại lỗi, thậm

chí khi “exception process” để lại lỗi.

Khi tất cả các công việc trong thể hiện ngữ cảnh kết thúc hoặc bỏ dở, một kiểm

soát lỗi được thực hiện. Các kiểm soát lỗi là một phần của định nghĩa ngữ cảnh, và

thực hiện trong thể hiện ngữ cảnh nơi mà lỗi được phát sinh. Sau khi thực hiện

xong kiểm soát lỗi, công việc cha chuyển qua trạng thái “aborted”.

Cấu trúc kiểm soát lỗi:

Name: Tên kiểm soát lỗi.

Code: một hoặc nhiều mã lỗi.

Documentation: Tài liệu mô tả.

Activities: một hoặc nhiều công việc (có sắp thứ tự).

2.2.8.3. Chấm dứt công việc (Terminating activity):

Một công việc có thể chấm dứt mà khộng ảnh hưởng đến các đối tượng khác

chỉ khi nó đang ở trạng thái “ready”. Thực chất là công việc bị hủy bỏ (cancelled).

Nếu công việc ở bất kỳ trạng thái nào khác thì nó không thể chấm dứt và phải kết

thúc hoặc bỏ dở. Một thể hiện công việc chấm dứt bằng các chuyển qua trạng thái

“aborting”, sau đó chuyển qua “aborted”.

Các công việc phức hợp có thể chấm dứt khi đang ở trạng thái “ready” hoặc

“active”. Ở trạng thái “active” chúng thực hiện các công việc được định nghĩa

trong ngữ cảnh con và chấm dứt bằng cách phát ra lỗi “bpml:terminate” trong thể

hiện ngữ cảnh đó. Kết quả là công việc phức hợp chuyển qua trạng thái “aborting”

và kết thúc hoặc hoàn thành tất cả các công việc đang thực hiện. Sau đó công việc

phức hợp thực hiện một kiểm soát lỗi, và cuối cùng chuyển qua trạng thái

“aborted”.

2.2.8.4. Đền bù (Compensation):

Khi một công việc gặp một điều kiện ngoại lệ ngăn chúng hoàn thành thì nên

trả lại những gì nó đã làm trước khi bỏ dở. Nếu quy trình đã chiếm giữ các tài


Trang 38

nguyên được yêu cầu để hoàn thành thì chúng nên giải phóng các tài nguyên đó để

các quy trình khác có thể sử dụng. Nếu quy trình đã thực hiện công việc có khả

năng đảo ngược thì nên đảo ngược lại công việc đó.

Đền bù là sự phục hồi lại tất cả ảnh hưởng của một công việc đã hoàn thành.

Một quy trình đền bù (Compensation process) là một quy trình được định

nghĩa như một phần của quy trình cha với mục đích thực hiện sự đền bù. Quy trình

đền bù chỉ có thể được khởi tạo khi thể hiện quy trình cha hoàn tất. Nếu quy trình

cha thất bại để hoàn tất thì dùng kiểm soát lỗi để phục hồi và đền bù. Trong kiểm

soát lỗi có thể chứa các quy trình đền bù của bất kỳ quy trình nào mà nó được khởi

tạo.

Định nghĩa quy trình đền bù giống định nghĩa quy trình lưới (nested process),

với một số khác biệt sau:

• Thêm hai thuộc tính “instant”, “duration”.

• Vì chỉ có một quy trình đền bù có thể được tạo thể hiện từ một thể hiện quy

trình cha, nên nó có cùng định danh như quy trình cha. Thuộc tính

“indentity” không được hỗ trợ.

• Quy trình đền bù không thể được đền bù. Thuộc tính “compensation”

không được hỗ trợ.

• Một thể hiện quy trình đền bù tồn tại nếu thể hiện quy trình cha tồn tại.

Thuộc tính “persistent” không được hỗ trợ.

2.2.9. Giao tác (Transaction):

2.2.9.1. Công việc nguyên tố (Atomic activity):

Một công việc nguyên tố là một công việc thực hiện như một đơn vị công việc

riêng lẻ. Một công việc nguyên tố đảm bảo rằng các công việc khác sẽ không thấy

kết quả từng phần trong khi công việc đang thực hiện, chỉ thấy được kết quả sau

khi công việc thực hiện xong.

Hầu hết các công việc đơn là công việc nguyên tố. Một số ngoại lệ là loại công

việc: call, compensate, action khi thuộc tính “activities” được xác định.

2.2.9.2. Persistent process:


Trang 39

Một công việc thực hiện qua một khoảng thời gian dài phải thực hiện trong

môi trường phục hồi sự cố (do các điều kiện ngoại cảnh ví dụ : hệ thống bị dừng

do mất điện…). Khi hệ thống bị dừng xẩy ra, thì công việc phải cho phép thực

hiện tiếp ở trạng thái đã tồn tại rồi (thực hiện tiếp công việc mà công việc đã làm

rồi trước khi sự cố xẩy ra). “Persistence” được định nghĩa như là khả năng gọi lại

một thể hiện quy trình đã tồn tại sau khi hệ thống bị dừng.

Một thể hiện “persistent process” được định nghĩa như là trạng thái của thể

hiện quy trình tồn tại sau sự thực hiện của các công việc nguyên tố. Thể hiện quy

trình phải gọi lại tất cả các công việc nguyên tố đã hoàn thành hay bỏ dở.

Sự thực thi BPML cung cấp môi trường phục hồi sự cố cho việc thực hiện các

quy trình bằng cách thực hiện hai cơ chế phục hồi “backward” và “forward”.

• Forward: Là khả năng gọi các thể hiện quy trình sau khi hệ thống thất bại,

đưa chúng trở về trạng thái tồn tại và tiếp tục thực hiện chúng.

• Backward: Là khả năng hủy bỏ một công việc nguyên tố mà chưa hoàn

thành hoặc bỏ dở trước khi hệ thống xảy ra sự cố.

2.2.9.3. Giao tác (Transaction):

Các phương thức giao tác cho phép hai quy trình tương tác với nhau thông qua

trao đổi thông điệp để phối hợp cùng hoàn thành công việc của chúng. Có hai loại

giao tác: atomic transaction, open nested transaction.

• Atomic transaction: Cho phép hai hệ thống thực hiện các công việc

nguyên tố trong một ngữ cảnh nguyên tố dùng chung, do đó cả hai công việc hoàn

thành và bỏ dở cùng nhau. Đầu ra của giao tác là sự kết hợp của tất cả các đầu ra

của tất cả các công việc thực hiện như một phần của ngữ cảnh của giao tác. Đầu ra

của giao tác thành công nếu tất cả các đầu ra của các công việc thành công, thất

bại nếu bất kỳ công việc nào không thể kết thúc hoặc trạng thái của công việc đó

không thể xác định được.

Ngữ cảnh giao tác được xác định trước khi thực hiện công việc đầu tiên trong

giao tác. Ngữ cảnh giao tác được kết nối như một phần của trao đổi thông điệp để

chỉ rằng các công việc phải thực hiện như một phần của giao tác đó.


Trang 40

Một công việc nguyên tố thực hiện trong một ngữ cảnh giao tác không hoàn

thành cho đến khi các đầu ra của giao tác được xác định. Chúng vẫn giữ nguyên

trạng thái “completing”, chờ một giải pháp cho đầu ra của giao tác. Sau khi đầu ra

giao tác được xác định (thành công) thì công việc chuyển qua trạng thái

“completed”.

• Open nested transaction: Các công việc không phải nguyên tố cần phối

hợp với nhau sử dụng “open nested transaction”. Trong khi “atomic transaction”

được sủ dụng cho các giao tác ngắn, thì “open nested transaction” thích hợp cho cả

giao tác ngắn và dài. Một “open nested transaction” có thể bao gồm các công việc

thực hiện tương tác yêu cầu/ trả lời (request/response) sử dụng các hành động

đồng bộ hóa, và các công việc thực hiện qua một thời gian dài.

Một “open nested transaction” có thể bao gồm sự thực thi của một hoặc nhiều

“open nested transaction” và “atomic transaction”.

Các công việc không là nguyên tố giao tiếp với ngữ cảnh giao tác và đầu ra

giao tác giống như cách giao tiếp của công việc nguyên tố.

2.2.10. Hàm (Function):

Đặc tả BPML cung cấp một số hàm cần thiết cho việc định nghĩa quy trình có

khả năng thực thi. Một định nghĩa quy trình có thể sử dụng bất kỳ hàm nào trong

mô tả quy trình.

Cấu trúc chung:

returnType funcName(paramType paramName,…)

BPML phân chia làm hai loại hàm chính:

• Generic: Tập hợp các hàm dùng để tương tác với các thông tin tổng quát

như: thời gian, định danh…

• Instances: Dùng để tương tác với các thông tin của thể hiện công việc

trong quá trình thực hiện của công việc, ví dụ: thông tin trạng thái.

2.3. Ngôn ngữ mô hình hóa eXPDL:

2.3.1. Giới thiệu:


Trang 41

Trên cơ sở nghiên cứu hai ngôn ngữ mô hình hóa hiện nay là XPDL, BPML,

hai sinh viên Trần Đăng Khoa và Phạm Minh Tuấn, sinh viên trường Đại học

Khoa học Tự nhiên, đã nghiên cứu và đề xuất ngôn ngữ mô hình hóa eXPDL. 7

eXPDL quan tâm đặc biệt đến việc mô hình hóa các quy trình trong thực tế,

không quan tâm đến “siêu mô hình” (meta - model). Ngôn ngữ XPDL là ngôn ngữ

mô hình hóa hướng luồng công việc với khả năng vận hành và tính chuẩn hóa

luồng công việc rất cao. Ngôn ngữ BPML là ngôn ngữ xem xét quy trình dưới

dạng cấu trúc điều khiển, nó có tính biểu đạt và tính hình thức rất cao. eXPDL là

sự kết hợp của XPDL và BPML. Tuy nhiên eXPDL được xây dựng chủ yếu dựa

vào XPDL có kết hợp bổ sung các khái niệm mới của BPML để tăng tính diễn đạt.

2.3.2. Những cải tiến của eXPDL so với XPDL và BPML:

Phần này đã được trình bày chi tiết trong luận văn cử nhân tin học của Trần

Đăng Khoa và Phạm Minh Tuấn. Dưới đây chúng em xin tóm tắt lại một số ý

chính:

2.3.2.1. Loại bỏ sự nhập nhằng giữa các hoạt động và các cổng điều

khiển:

• XPDL: Đồng nhất các cổng điều khiển với các hoạt động.

• BPML: Các cổng điều khiển không được định nghĩa, mà việc điều

khiển các luồng công việc thông qua các hoạt động chuẩn (được định

nghĩa như các khối cấu trúc (while,switch,all, choice,…).

• eXPDL: Định nghĩa thêm đối tượng Gateway. Gateway làm nhiệm vụ

thể hiện ngữ nghĩa đồng bộ hóa giữa các luồng công việc trong quy

trình. Có thể chia Gateway thành 4 loại cơ bản : AND, OR, XOR,

COMPLEX.

2.3.2.2. Hỗ trợ mô tả các tiến trình thuộc loại Ad – Hoc:

Tiến trình loại AdHoc là các tiến trình bên trong nó các hoạt động không được

quy định thứ tự thực hiện . Tất cả các hoạt động này sẽ được thực hiện tùy ý cho

7 Tìm hiểu XPDL và xây dựng ứng dụng minh hoạ,Trần Đăng Khoa và Phạm Minh Tuấn, Luận văn cử nhân tin học, Tp.HCM 2004.


Trang 42

đến khi tất cả các hoạt động đều được hoàn thành. - chỉ có ràng buộc duy nhất là

không có 2 hoạt động nào được tiến hành song song cùng lúc. Đây là tiến trình

thuộc về mẫu “đường vào song song” (Interleaved Parallel Routing).

• XPDL: Định nghĩa hai loại cổng là Split và Join nhưng không đủ ngữ

nghĩa thể hiện cho Ad - Học.

• BPML: Không có cơ chế trực tiếp hỗ trợ mẫu này.

• eXPDL: Cung cấp thuộc tính để chỉ ra tiến trình thuộc loại Ad - Học.

2.3.2.3. Hỗ trợ mô tả các hoạt động đa thể hiện:

Có 4 mẫu hoạt động đa thể hiện:

• Mẫu đa thể hiện không đồng bộ

• Mẫu đa thể hiện biết thông tin ở thời điểm thiết kế

• Mẫu đa thể hiện biết trước thông tin ở thời điểm thực thi

• Mẫu đa thể hiện không biết trước thông tin.

• XPDL: chỉ thể hiện được mẫu đa thể hiện không đồng bộ và mẫu đa thể

hiện biết thông tin ở thời điểm thiết kế.

• BPML: hỗ trợ được tất cả các mẫu đa thể hiện thông qua việc sử dụng

các hoạt động điều khiển.

• eXPDL: Cung cấp các thuộc tính hỗ trợ cho việc thể hiện của mẫu đa

thể hiện trong các tác vụ và các tiến trình con.

2.3.2.4. Bổ sung các sự kiện vào mô hình nghiệp vụ:

• XPDL: Không hỗ trợ cơ chế đón bắt sự kiện giữa các hoạt động thành

phần với nhau.

• BPML: cho phép mô tả cơ chế này ở mức độ tương đối thông qua các

tín hiệu (signal).

• eXPDL: Cung cấp 3 loại sự kiện chính:

- Các sự kiện kích hoạt tiến trình : Start Events

- Các sự kiện kết thúc tiến trình : End Events


Trang 43

- Các sự kiện xảy ra tức thời trong tiến trình : Intermediate

Events.

2.3.2.5. Hỗ trợ mô tả cơ chế giao tác của hoạt động nghiệp vụ:

• XPDL: Không hỗ trợ việc định nghĩa các hoạt động mang tính giao tác.

• BPML: Có khả năng định nghĩa giao tác.

• eXPDL: Hỗ trợ thông qua thuộc tính Transaction của các tiến trình con

và các sự kiện Cancel bên trong tiến trình con này.

2.3.2.6. Hỗ trợ mô tả cơ chế giải quyết đền bù:

eXPDL cung cấp cơ chế giải quyết đền bù thông qua các sự kiện Intermediate

Event loại Compensation hoặc các End Event loại Compensation.

2.3.2.7. Hỗ trợ mô tả cơ chế phát sinh và giải quyết lỗi:

• XPDL: Không đủ ngữ nghĩa mô tả cơ chế này.

• BPML: Hỗ trợ mô tả cơ chế này.

• eXPDL: Sử dụng các đối tượng sự kiện để cung cấp khả năng biểu đạt

của cơ chế phát sinh và giải quyết lỗi, thông qua thuộc tính Exception

của sự kiện.

2.3.2.8. Hỗ trợ mô tả các quy trình có những hoạt động theo mẫu cột

mốc:

• Cả XPDL và BPML chưa hỗ trợ việc mô tả này.

• eXPDL sử dụng loại IntermediateEvent kiểu Timer(với Timer là

MileStone) để hỗ trợ mô tả cơ chế này.

2.3.2.9. Hỗ trợ cơ chế mô tả tổ chức và phân công vai trò nghiệp vụ

trong các hoạt động:

• XPDL: Cung cấp phần mô tả tổ chức: Role (các vai trò nghiệp vụ trong

tổ chức), Tool ( các công cụ hỗ trợ nghiệp vụ trong tổ chức). Ngoài ra

còn hỗ trợ việc phân công các Role tham gia các hoạt động và các Tool

hỗ trợ các hoạt động đó.


Trang 44

• BPML: Không hỗ trợ đặc tả các Role, Tool mà chỉ tập trung vào các cơ

chế điều khiển hoạt động là chính.

• eXPDL: Giữ lại đặc tính mô tả của XPDL. Tuy nhiên cụ thể hóa khái

niệm công cụ hơn để dễ mô tả cho các nghiệp vụ điện tử. Các công cụ

được phân làm 2 loại : các ứng dụng (Application) và các WebService

2.3.2.10. Hỗ trợ mô tả cơ chế phân công thực thi trên các sản phẩm:

Hầu hết các ngôn ngữ mô hình hóa luồng công việc không cho phép mô tả cơ

chế này (kể cả XPDL và BPML).

eXPDL hỗ trợ hai quyền là: Quyền đọc (Read) và Quyền ghi (Write).

2.3.2.11. Cải tiến trong khái niệm luồng vận chuyển sản phẩm của

nghiệp vụ:

Hiện tại đặc tính này chỉ ở mức đề xuất thử nghiệm trong đặc tả eXDPL, chưa

hỗ trợ mô tả cụ thể.

2.3.2.12. Hỗ trợ cơ chế kích hoạt giữa các hoạt động thông qua thông

điệp:

eXPDL hỗ trợ hai cơ chế: Cơ chế bắt thông điệp và Cơ chế gửi thông điệp.

2.3.2.13. Hỗ trợ việc mở rộng các đối tượng:

XPDL và BPML cho phép các tổ chức khác có thể mở rộng đối tượng đã có

thông qua các thuộc tính mở rộng. Tuy nhiên không có cơ chế thêm vào một loại

đối tượng mới thuộc cùng một lớp đối tượng. Ví dụ: không thể thêm vào một kiểu

hoạt động mới hoàn toàn.

eXPDL cho phép thêm vào mô hình các kiểu đối tượng mở rộng:

UserDefinedActivityType, UserDefinedEventType, UserDefinedFlowType. Do đó

có thể tạo các đối tượng mở rộng từ các kiểu trên: UserDefinedActivity (hoạt động

tự định nghĩa), UserDefinedEvent (sự kiện tự định nghĩa), UserDefinedFlow

(luồng tự định nghĩa).

Chương 3. Giới thiệu tổng quan hệ thống

Chúng ta thường nghe “tin học hóa trong giáo dục”, “tin học hóa trong quản lý

kế toán”, “tin học hóa ….” trong nhiều lĩnh vực. Vậy tại sao lại không nghĩ tới


Trang 45

việc “tin học hóa cho một tiến trình nghiệp vụ”. Chương này sẽ cho ta thấy rõ hơn

về con đường cần phải có một “bộ máy vận hành một tiến trình nghiệp vụ” và bộ

máy đó được xây dựng ra sao ?

3.1. Ngữ cảnh phát triển hệ thống:

Một hệ thống quản lý quy trình nghiệp vụ gồm hai phần chủ yếu sau:

Ø Phần hỗ trợ mô hình hóa quy trình nghiệp vụ: giúp người dùng có thể

mô hình hóa quy trình nghiệp vụ trong thực tế theo một chuẩn đặc tả

nhất định.

Ø Phần hỗ trợ vận hành quy trình nghiệp vụ đã được định nghĩa: thường

bao gồm một động cơ tiến trình giúp người dùng vận hành một quy

trình nghiệp vụ trong thực tế, ngoài ra còn hỗ trợ người dùng một số

tiện ích nhằm theo dõi và kiểm soát quy trình.

Về phần mô hình hóa quy trình nghiệp vụ: đã có nhiều ngôn ngữ mô hình hóa

ra đời nhằm hỗ trợ người dùng mô tả quy trình nghiệp vụ của mình. Mỗi ngôn ngữ

đều cố gắng cung cấp một hệ thống các ký hiệu và ngữ nghĩa kèm theo giúp cho

việc mô hình hóa phù hợp với thực tế hơn. Tuy nhiên công cụ mô hình hóa đi kèm

với đặc tả của ngô ngữ thì còn rất hạn chế. Riêng ngôn ngữ eXPDL có công cụ mô

hình hóa kèm theo MyXPDL hỗ trợ rất tốt mô hình hóa nghiệp vụ [trình bày trong

chương 2].

Về phần vận hành quy trình nghiệp vụ, hiện tại còn rất hạn chế.

Trong khuôn khổ luận văn, chúng em dự định xây dựng công cụ vận hành quy

trình nghiệp vụ do công cụ mô hình hóa MyXPDL phát sinh.

3.2. Yêu cầu hệ thống cần xây dựng:

Ø Quản lý các quy trình nghiệp vụ trong tổ chức: Lưu trữ các quy

trình nghiệp vụ với mục đích tái sử dụng.

Ø Khởi tạo và vận hành một dự án theo quy trình nghiệp vụ trong

thực tế.

3.3. Ý nghĩa hệ thống:


Trang 46

Công cụ mô hình hóa định nghĩa một quy trình mẫu. Tuy nhiên khi áp dụng

quy trình vào trong thực tế thì rất phức tạp. Khi thực hiện một nghiệp vụ trong

thực tế thì liên quan đến vấn đề nhân sự, kết quả cụ thể của từng công việc. Do đó,

hệ thống được xây dựng với mục đích hỗ trợ người dùng các nghiệp vụ sau:

Đối với tổ chức:

Ø Tái sử dụng các quy trình đã được định nghĩa.

Ø Lưu trữ sản phẩm của công việc, có thể tái sử dụng sau này.

Đối với người quản lý dự án:

Ø Tạo mới dự án dựa vào quy trình có sẳn, hoặc tạo mới dự án trực tiếp.

Ø Phân công nhân viên thực hiện công việc.

Ø Quản lý sản phẩm vào ra trong từng công việc.

Ø Theo dõi tiến độ thực hiện dự án.

Ø Hiệu chỉnh thông tin dự án khi cần thiết (trong trường hợp dự án bị trễ,

có sự thay đổi nhân sự…).

Đối với nhân viên thực hiện công việc:

Ø Thực hiện công việc phân tán: có thể thực hiện công việc bất cứ lúc nào

chỉ cần đăng nhập vào hệ thống.

Ø Xem thông tin các công việc phải thực hiện

Đối với nhân viên phát triển phần mềm thì ứng dụng được xem như là cơ sở để

phát triển thành một hệ thống quản lý quy trình nghiệp vụ hoàn chỉnh.

3.4. Công cụ thiết kế:

3.4.1. Giới thiệu về công cụ mô hình hóa quy trình nghiệp vụ :

MyXPDL là một công cụ giúp thiết kế mô hình nghiệp vụ do 2 sinh viên

trường ĐH Khoa học Tự nhiên là Trần Đăng Khoa và Phạm Minh Tuấn đã xây

dựng thành công dựa trên ngôn ngữ mô hình hóa eXPDL do chính họ đề xuất dựa

trên nền tảng của 2 ngôn ngữ mô hình phổ biến là BPML và XPDL. Bên cạnh đó

phần mềm còn cung cấp thêm một số tính năng hữu dụng khác để ràng buộc các

lỗi phát sinh khi mô hình hóa nghiệp vụ, kết xuất ra tài liệu dạng Web


Trang 47

3.4.2. Một số chỉnh sửa công cụ MyXPDL cho phù hợp với việc quản lý

quy trình nghiệp vụ

Ø Dù Task có định nghĩa Moderator hay không thì khi phát sinh file XML

vẫn tạo ra tag Moderator để tiện xử lý.

Ø Nếu trong một Task Loop Type là STANDARD thì khi phát sinh file XML

không phát sinh tag Loop Condition.

Ø Thêm tag Id cho một số đối tượng Role, Product … khi phát sinh file XML

để dễ xử lý tránh nhầm lẫn. Do đó, khi thêm một Role vào Task thì khi phát

sinh XML cho Task phải có một “truy cập” đến Role. Trong phiên bản

trước “truy cập” này là Name và trong bản sửa này được đổi thành Id.

Ø Thêm chức năng Add Role vào trong Task (phiên bản trước chưa hỗ trợ),

nhưng chưa thể hiện trong ứng dụng chỉ thêm trong file XML.

3.5. Nguyên lý tổ chức hệ thống:

Hệ thống được tổ chức theo mô hình dữ liệu tập trung.

Ø Tất cả các dữ liệu (tiến trình mẫu, các sản phẩm vào ra của hệ thống) đều

được lưu trữ trên Database Server (sử dụng hệ quản trị SQL Server 2000).

Ø Mỗi User sử dụng máy Client của mình đăng nhập vào hệ thống và thực

hiện công việc của mình. Sau khi kết thúc công việc, tất cả các dữ liệu được

lưu trữ lại trên Server.

Hình 4 Nguyên lý tổ chức hệ thống

3.6. Nguyên lý vận hành hệ thống:

Hệ thống quản lý qui trình nghiệp vụ


Trang 48

Hệ thống được vận hành theo cơ chế tuần tự, dựa vào trạng thái các hoạt động,

luồng điều khiển và các cổng điều khiển. Chương trình hỗ trợ vận hành ba loại

cổng chính:

Ø Cổng AND: Khi tất cả các luồng tuần tự đi vào cổng được kích hoạt thì tất

cả các hoạt động sau cổng sẽ được kích hoạt đồng thời.

Ø Cổng OR:Khi một luồng tuần tự đi vào cổng được kích hoạt thì tất cả các

luồng tuần tự sau cổng nếu thõa điều kiện sẽ được kích hoạt.

Ø Cổng Xor_DATABASE: Chỉ có duy nhất một luồng tuần tự sau cổng thõa

điều kiện đựơc kích hoạt.

Các biểu thức điều kiện dựa vào trạng thái mở rộng của hoạt động, sản phẩm,

và chương trình chỉ hỗ trợ loại điều kiện tự động (auto).

Hình 5 Nguyên lý vận hành hệ thống

3.7. Quy trình tổng quan:


Trang 49

Hình 6 Quy trình tổng quan

Chương 4. Phân tích yêu cầu hệ thống

4.1. Các thành phần hỗ trợ trong luận văn:

eXPDL hỗ trợ mô tả tốt 18/20 mẫu luồng công việc đã được công bố. Tuy

nhiên , trong khuôn khổ luận văn, chúng em không thể hỗ trợ hết tất cả các mẫu

công việc trên. Sau đây là một số thành phần mà chúng em hỗ trợ, được phân chia

theo đối tượng trong mô hình:

Ø Activity: Hỗ trợ điều kiện lặp kiểu "Standard". Đối với process chỉ

hỗ trợ ở mức đơn giản, không hỗ trợ "Transaction" và

"Compensation". Hỗ trợ cơ chế lặp theo "Timer"

Ø Gateway: Hỗ trợ 3 loại Gateway: AND, OR, Xor_DATABSED

Ø Event:Hỗ trợ 2 loại sự kiện là : StartEvent và EndEvent, tuy nhiên

chỉ hỗ trợ ở mức đơn giản nhất: loại "NONE".

Ø Atomic: hỗ trợ loại "AUTO".

Ø Expression


Trang 50

Ø UserDefinedType

Ø Product: chỉ hỗ trợ loại sản phẩm là "DOCUMENT".

Ø SequenceFlow: Hỗ trợ điều kiện dựa trên trạng thái mở rộng của

Product và Activity.

Ø ExecuteRelation: Chương trình hỗ trợ quan hệ thực thi thông qua

việc người dùng tự thiết lập lúc chạy dự án. Do tập tin phát sinh của

công cụ mô hình hóa eXPDL không lưu trữ quan hệ này.

Ø Role

Các đối tượng khác như: Model, Organization, Tool, IntermediateEvent được

lưu trữ lại để phát triển tiếp hệ thống về sau.

4.2. Các chức năng chính:

4.2.1. Quản lý quy trình mẫu:

Chức năng này cho phép các tổ chức có thể tạo mới các quy trình nghiệp vụ từ

tập tin mô hình hóa. Các quy trình này có thể được tái sử dụng trong nhiều dự án

khác nhau.

4.2.2. Khởi tạo dự án:

Trong đề tài chúng em phân chia dự án theo hai loại: dự án được khởi tạo từ

quy trình mẫu (template project) và dự án được khởi tạo không theo quy trình mẫu

(none template project).

Template project: là dự án được khởi tạo từ quy trình mẫu có sẳn.

None template project: Là dự án do người dùng tạo mới ở dạng “dự án rỗng”,

sau đó thêm các đối tượng cần thiết cho quy trình vào dự án. Thời gian có hạn nên

chúng em chưa hỗ trợ hết các loại đối tượng cho loại dự án này. Chức năng này

chỉ áp dụng cho các dự án đơn giản. Sau đây là một các đối tượng mà chương

trình hỗ trợ:

• Activity: Thêm công việc vào dự án, đây là các công việc nguyên tố.

• Process: Thêm quy trình con vào một quy trình nào đó, nếu thêm quy

trình vào dự án thì được xem là quy trình chính của dự án. Khi thêm

một quy trình thì chương trình tự động thêm hai sự kiện bắt đầu và kết


Trang 51

thúc cho quy trình. Do chương trình chưa hỗ trợ các loại sự kiện nên các

sự kiện được thêm mặc định có kiểu là “NONE”.

• Product: Thêm các sản phẩm vào trong dự án.

• Gateway: Thêm các công điều khiển vào trong dự án. Chương trình hỗ

trợ 3 loại cổng điều khiển là : AND, OR, Xor_DATABASED với ý

nghĩa theo đặc tả ngôn ngữ eXPDL.

• SequenceFlow: Thêm các luồng điều khiển. Các luồng điều khiển

được thêm vào trong từng quy trình cụ thể. Người dùng phải đảm bảo

thiết lập đúng luồng công việc, chương trình chưa hỗ trợ kiểm tra tính

đúng đắn của luồng công việc. Có thể xác lập điều kiện cho luồng điều

khiển thông qua trạng thái mở rộng của công việc và sản phẩm.

• UserDefinedType: Thêm các kiểu dữ liệu do người dùng tự định nghĩa.

Thường được dùng để quy định trạng thái mở rộng cho công việc, sản

phẩm.

• Expression: Thiết lập các biểu thức điều kiện.

4.2.3. Quản lý dự án:

Để dự án có thể thực hiện được người quản lý dự án phải thực hiện phân công

nhân sự, tài nguyên cho dự án. Ngoài ra khi dự án đang thực hiện người quản lý

dự án có thể thực hiện điều chỉnh nhân sự, thời gian cho kịp tiến độ thực hiện dự

án. Hệ thống hỗ trợ các chức năng sau:

• Phân công nhân viên thực hiện trong từng công việc cụ thể, và quyền

của nhân viên đối với công việc đó :

o View: Nhân viên đó chỉ được xem các thông tin công việc mà

không được phép cập nhật hay thực hiện bất kỳ thay đổi nào đối

với công việc.

o Edit: Nhân viên được thực hiện công việc (đây là quyền mặc

định khi thêm nhân viên vào công việc).


Trang 52

• Đối với “none template project” người quản lý có thể quy định các sản

phẩm vào/ra của từng công việc.

• Trong từng công việc, thực hiện phân quyền cho nhân viên đối với từng

sản phẩm của công việc:

o Upload: Nhân viên được phép upload và download sản phẩm

(đây là quyền mặc định).

o Download: Nhân viên chỉ được phép download mà không được

phép upload. Điều này tránh việc upload bừa bãi gây khó khăn

cho công việc và hệ thống.

• Cung cấp các tài nguyên (dưới dạng tập tin là chủ yếu) cho các sản

phẩm.

• Quy định khoảng thời gian thực hiện công việc. Mặc định các công việc

được thực hiện theo luồng tuần tự đã được định nghĩa trước nếu người

quản lý không quy định thời gian thực hiện cụ thể.

• Theo dõi tiến độ thực hiện dự án, bao gồm: theo dõi tiến độ chung hoặc

tiến độ của từng công việc cụ thể.

4.2.4. Thực hiện dự án:

Giúp người dùng thực hiện công việc của mình. Người dùng có thể tham gia

thảo luận nhóm trong công việc của mình thông qua “forum” trực tiếp trên công

việc.

Quản lý luân chuyển tự động sản phẩm qua các công việc trong dự án.

4.2.5. Các chức năng quản trị:

• Quản lý thông tin các thành viên: Tìm kiếm thành viên, thay đổi thông

tin cá nhân.

• Thêm thành viên mới.

• Phân quyền cho các thành viên trong hệ thống.

4.3. Mô hình Use Case:


Trang 53

Manage User Account

Search User Account

Manage Template

Admin

(f rom Actors)

Run Activity

UserActivity

Manage Product

Member

RegisterLoginUpdate User Info

User

Setup template Project

Edit Project

Delete Project

Project Report Search Project

Project Manager

Setup none template project

Hình 7 Mô hình Use Case

4.4. Đặc tả Actor:

Admin: Người quản trị hệ thống, có vai trò thiết lập các vai trò trong hệ thống,

đây là Actor có quyền cao nhất hệ thống.

Project Manager: Người quản lý dự án. Chịu trách nhiệm khởi tạo và vận

hành một dự án, tạo mới một quy trình nghiệp vụ.

Member: Thành viên, là actor có quyền thấp nhất trong hệ thống, chỉ được

phép thực hiện các công việc do Project Manager phân công.

4.5. Đặc tả Use Case:

4.5.1. Manage Template (Quản lý quy trình mẫu):

Tóm tắt:Use case này cho phép người quản lý dự án có thể thêm mới hoặc hủy

bỏ 1 quy trình nghiệp vụ đã được định nghĩa.

Dòng sự kiện :

Ø Dòng sự kiện chính:


Trang 54

Use case này bắt đầu khi Admin muốn thêm hay hủy 1 số quy trình nghiệp vụ

có sẳn trong tổ chức.

1. Hệ thống yêu cầu “Admin” chọn chức năng muốn thực hiện (“Delete

template”,”Add new template”).

2. Sau khi “Admin” chọn chức năng thực hiện, một trong các luồng phụ sau

được thực hiện.

Nếu chọn “Add new template”, luồng phụ Add new template được thực hiện.

Nếu chọn “Delete template”, luồng phụ Delete template được thực hiện.

• Add new template(Thêm 1 quy trình nghiệp vụ mới):

1. Hệ thống yêu cầu nhập các thong tin sau:

Name(Tên, Bắt buộc phải có)

File(File mô hình hóa quy trình nghiệp vụ, bắt buộc)

Mô tả(Description)

Created date (Ngày tạo)

2. Sau khi “Admin” nhập thong tin cần thiết vào. Hệ thống lưu lại thông tin

trên và phát sinh ra 1 số ID cho Template.

• Delete template(Xóa template khởi hệ thống):

1. Hệ thống yêu cầu chọn template từ danh sách có sẳn.

2. Hệ thống hiển thị thong tin của template: Ngày tạo, người tạo.

3. Người dung nhấn nút xóa.

4. Hệ thống nhắc nhở người dùng xác nhận thao tác xóa.

5. Người dùng xác nhận thao tác xóa.

6. Hệ thống xóa template ra khởi cơ sở dữ liệu.

Ø Dòng sự kiện khác:

• Thao tác xóa bị hủy:

Nếu trong luồng phụ “Delete template”, người dùng không xác nhận xóa

template thì thao tác xóa bị hủy và Dòng dự kiện chính được bắt đầu lại từ đầu.

o Tồn tại project đã tạo từ template này:


Trang 55

- Nếu đã có ít nhất 1 project đã được tạo từ Template này, hệ thống hiển thị

thông báo: Tên project, trạng thái project của những project khởi tạo từ

template này. Hệ thống nhắc nhở người dùng “Nếu xóa Template thì các

project bị xóa theo”.

- Nếu người dùng xác nhận, thì hệ thống xóa tự động xóa các project liên

quan và xóa Template

- Nếu người dùng không xác nhận, thao tác xóa bị hủy bỏ, Dòng sự kiện

chính được bắt đầu lại từ đầu.

o Không tồn tại template nào:

Một thông báo lỗi cho người dùng. Sau khi người dùng đọc xong và xác nhận,

Use case kết thúc.

Các yêu cầu đặc biệt:

Không có.

Điều kiện tiên quyết:

Người dùng phải đăng nhập vời quyền là “Admin”.

Post-Condition:

Nếu Use case thành công 1 template được them vào hoặc xóa khỏi hệ thống,

use case kết thúc.

Ngược lại trạng thái hệ thống không thay đổi.

Điểm mở rộng:

Không có.

4.5.2. Setup template project (Tạo mới dự án theo mẫu có sẵn):

Tóm tắt:

Use case cho phép PM khởi tạo mới 1 dự án theo 1 mẫu template.

Dòng sự kiện:


Use case bắt đầu khi PM muốn tạo mới 1 dự án.

1. Hệ thống load tất cả các Template có sẳn trong công ty.

2. Hệ thống yêu cầu PM nhập các thông tin của project:


Trang 56

Name :Tên project, bắt buộc.

Description :Mô tả ngắn gọn về dự án.

Template :Chọn 1 template từ danh sách có sẳn, bắt buộc.

Start date: Ngày bắt đầu thực hiện dự án.

Finish date: Ngày kết thúc dự án (Có tính tương đối).

3. Hệ thống ghi nhận thông tin khởi tạo project, phát sinh 1 số ID duy nhất

cho Project.

4. Hệ thống phân tích cấu trúc file Template, lưu xuống CSDL.

5. Trả lại cho PM số ID của project.

6. Dòng sự kiện chính được bắt đầu lại.


• Template không tồn tại:

Nếu không tồn tại Template nào, Use case kết thúc.

o Ngày kết thúc không hợp lệ:

Nếu ngày kết thúc trùng ngày bắt đầu, hệ thống thông báo lỗi cho PM, yêu cầu

PM nhập lại ngày kết thúc, hoặc có thể để trống.


Không có.


PM phải đăng nhập vào hệ thống.

Post-Condition:

Nếu Use case thành công, 1 dự án mới được them vào hệ thống.

Ngược lại, trạng thái hệ thống không thay đổi.


Không có.

4.5.3. Setup none template project (Tạo mới dự án không theo mẫu):

Tóm tắt:

Use case cho phép PM tạo mới 1 dự án không theo quy trình mẫu. Tất cả các

công việc, sản phẩm đều do PM tự định nghĩa.


Trang 57

Dòng sự kiện:


Use case khi PM khởi tạo 1 dự án không theo quy trình mẫu có sẳn.

1. Hệ thống yêu cầu PM nhập các thông tin của project:

Name :Tên project, bắt buộc.

Description :Mô tả ngắn gọn về dự án.

Template :Chọn 1 template từ danh sách có sẳn, bắt buộc.

Start date: Ngày bắt đầu thực hiện dự án.

Finish date: Ngày kết thúc dự án (Có tính tương đối).

2. Hệ thống phát sinh ra ID cho người dùng.


Không có.



Post-Condition:

Nếu Use case thành công, 1 dự án mới được thêm vào hệ thống.



Không có.

4.5.4. Delete Project: (Xóa dự án)

Tóm tắt:

Use case cho phép PM hủy bỏ Project đã triển khai.

Dòng sự kiện:


Use case bắt đầu khi PM muốn hủy các Project mà do mình triển khai.

1. Hệ thống yêu cầu PM nhập vào số ID của project.

2. Hệ thống hiển thị các thông tin của project.

3. Người dùng thực hiện thao tác xóa.



Trang 58

5. Người dùng xác nhận thao tác xóa.

6. Hệ thống xóa project ra khỏi hệ thống: Thông tin riêng , các công

việc trong project.

7. Dòng sự kiện chính được thực hiện lại.


• Không tìm thấy project:

Tong dòng sự kiện chính, nếu không tìm thấy project nào, hệ thống hiển thị

thông báo lỗi. PM có thể nhập vào số ID khác, hoặc hủy bỏ thao tác, Use case kết

thúc.

• Thao tác xóa bị hủy:

Nếu trong dòng sự kiện chính, PM không xác nhận thao tác xóa thì thao tác

xóa bị hủy và dòng sự kiện chính bắt đầu lại từ đầu.


Không có.



Post-Condition:

Nếu Use case thành công, 1 dự án bị xóa khỏi hệ thống.



Không có

4.5.5. Project Report (báo cáo dự án):

Tóm tắt:

Use case cho phép PM xem thông tin hoạt động của 1 dự án.

Nếu project chưa hoàn thành: Xem tiến trình thực hiện dự án

Nếu project đã hoàn thành: Xem bản báo cáo của dự án

Dòng sự kiện:



Trang 59

Use case bắt đầu khi PM muốn xem quá trình thực hiện dự án hay bản báo cáo

tổng kết dự án đã hoàn thành.

1. Hệ thống yêu cầu PM nhập số ID của Project.

2. Hệ thống hiển thị thông tin riêng của dự án.

3. Hệ thống hiển thị danh sách các công việc(Activity), tiến độ thực

hiện, danh sách các nhân viên tham gia công việc đó, Các sản phẩm

vào và ra của dự án(đến thời điểm hiện tại)

4. Đối với các công việc đã hoàn thành, Hệ thống tính số ngày hoàn

thành trước thời hạn.

5. PM có thể chuyển sang chế độ “edit”, Use case “Edit Project”

được thực hiện, hoặc có thể huỷ tác vụ -> Use case kết thúc.


• Không tìm thấy Project:

Trong dòng sự kiện chính, nếu hệ thống không tìm thấy project, 1 thông báo lỗi

được gửi đến PM, PM có thể nhập vào 1 ID khác hoặc hủy tác vụ -> Use case kết

thúc.


Không có.



Post-Condition:

Use case không làm thay đổi trạng thái hệ thống.


Không có

4.5.6. Search Project: (Tìm kiếm project)

Tóm tắt:

Use case cho phép PM hoặc Admin tìm kiếm Project theo các tiêu chuẩn khác

nhau:Mã(ID), Tên, Người tạo, Ngày tháng năm.

Dòng sự kiện:


Trang 60


Use bắt đầu khi PM hoặc Admin muốn tra cứu thông tin của 1 project.

1. Hệ thống yêu cầu người dùng nhập vào tiêu chuẩn tìm kiếm.

2. Hệ thống trả về danh sách các project thõa mãn tiêu chuẩn tìm

kiếm.

3. Người dùng muốn xem thông tin chi tiết của Project: Chọn 1

project trong danh sách trả về và Use case Project Report được

thực hiện.

4. Người dùng xác nhận kết quả tìm kiếm và dòng sự kiện chính được

thực hiện lại.




được gửi đến PM, PM có thể nhập vào 1 ID khác hoặc hủy tác vụ -> Use case kết

thúc.


Không có.


PM hoặc Admin phải đăng nhập vào hệ thống.

Post-Condition:



Không có

4.5.7. Edit Project:

Tóm tắt:

Use case cho phép PM thiết lập các thông tin ban đầu cho project: Ngày bắt

đầu, ngày kết thúc. Phân các các nhân viên tham gia vào các công việc cụ thể. PM

có thể thay đổi việc phân công cho 1 project đã khởi tạo rồi.

Dòng sự kiện:


Trang 61


Use case bắt đầu khi PM muốn thay đổi thông tin của project, phân công công

việc cho nhân viên tham gia vào trong project.

1. Hệ thống yêu cầu PM nhập vào số ID của Project.

2. Hệ thống load lại danh sách các công việc có trong project.

3. Hệ thống yêu cầu người dùng chọn chức năng năng thực hiện

(“Edit project info”, “Edit Activity”).

4. Nếu PM chọn “Edit project info”, luồng sự kiện phụ “Edit

project info” được thực hiện.

5. Nếu PM chọn “Edit Activity”, luồng sự kiện phụ “Edit Activity”

được thực hiện.

• Edit project info: Thay đổi thông tin project.

1. Hệ thống yêu cầu người dùng nhập vào ngày bắt đầu,ngày kết

thúc mới.

2. Hệ thống ghi nhận giá trị mới.

3. Dòng sự kiện chính được bắt đầu lại.

1.1.1.1. Edit Activity:

1. Hệ thống yêu cầu người dùng cung cấp ID Activity.

2. Hệ thống hiển thị thông tin của Activity: Tên, danh sách các role

được định nghĩa trong template.

3. Hệ thống hiển thị danh sách các nhân viên trong tổ chức.

4. Hệ thống yêu cầu người dùng nhập vào ngày bắt đầu,ngày kết

thúc công việc.

5. Hệ thống yêu cầu PM phân công nhân viên tham gia vào các

role.

6. Hệ thống yêu cầu PM cấp quyền cho nhân viên đối với Activity:

Xem (View), Thực hiện(Edit)

7. Nếu PM muốn hủy bỏ sự phân công vừa thiết lập, luồng phụ

“Delete user in role” được thực hiện.


Trang 62

8. PM chọn chức năng lưu lại kết quả edit.

9. Hệ thống lưu lại ngày bắt đầu, kết thúc của 1 công việc, sự phân

công nhân sự tham gia vào công việc.

10. Dòng sự kiện này được tiếp tục thực hiện lại.

11. Use case kết thúc khi PM kết thúc việc “Edit”

o Delete user in role:(Mỗi lần xóa 1 sự phân công)


2. Người dùng xác nhận thao tác.

3. Hệ thống xóa sự phân công vừa được thực hiện.

4. Dòng sự kiện Edit activity được thực hiện.

Ø Dòng sự kiện phụ:

• Project không tồn tại:

Nếu trong dòng sự kiện chính, không tồn tại project nào, 1 thông báo lỗi được

giửi đến cho người dùng. PM có thể nhập vào ID khác, hoặc hủy thao tác, use case

kết thúc.

• Ngày kết thúc không hợp lệ:

Nếu trong 2 dòng sự kiện phụ, nếu ngày kết thúc trùng với ngày bắt đầu. Hệ

thống thông báo lỗi cho người dùng. Hệ thống yêu cầu người dùng nhập lại ngày

hoặc để trống ngày kết thúc.

• Không tồn tại role:

Trong dòng sự kiện “Edit activity”, nếu không có role nào được định nghĩa

tham gia thực hiện Activity. Hệ thống vẫn ghi nhận sự phân công bình thường.


Không có.


PM phải đăng nhập hệ thống.

Post-Condition:

Nếu Use case thành công, các thông tin mới của dự án được ghi nhận.


Trang 63

Ngược lại, dự án đó chưa thể được thực hiện, trạng thái hệ thống không thay

đổi.


Thêm mới 1 Activity vào project.

4.5.8. Run Activity (thực hiện công việc):

Tóm tắt:

Use case cho phép Member thực hiện công việc được giao trong 1 project.

Dòng sự kiện:


Use case bắt đầu khi 1 Member login thành công vào hệ thống.

1. Hệ thống load tất cả các project chưa hoàn thành mà Member tham

gia.

2. Member chọn project muốn thực hiện công việc.

3. Hệ thống hiển thị tất cả các công việc(Kèm theo trạng thái) có

trong Project. Công việc nào Member được giao tham gia sẽ ở

trạng thái “Enable”, ngược lại ở trạng thái “Disable”.

4. Member chọn 1 công việc trong các công việc ở trạng thái

“Enable”.

5. Hệ thống hiển thị thông tin của Acitivty. Quá trình thực hiện của

các thành viên tham gia

6. Hệ thống kiểm tra quyền của Member đối với Activity đó:

a. Nếu là “View”: Member chỉ được phép xem.

b. Nếu là “Edit”: Member được phép Upload, Download các

product trong Activity, cập nhật trạng thái, trạng thái mở

rộng cho Activity.

7. Người dùng lưu lại kết quả làm việc(Update).

8. Hệ thống kiểm tra nếu công việc đã hoàn thành (Finish), thì kích

hoạt các công việc tiếp theo.

9. Member kết thúc phiên làm việc-> Use case kết thúc.


Trang 64




được gửi đến cho Member -> Use case kết thúc.

• Không tìm thấy Acitivity:

Trong dòng sự kiện chính, nếu các Activity member tham gia đều đã hoàn

thành(Finish), 1 thông báo gửi đến cho Member->Use case kết thúc.


Không có.


Member phải đăng nhập vào hệ thống.

Post-Condition:

Nếu Use case thành công, trạng thái công việc trong project bị thay đổi. ............



Không có

4.5.9. Manage Product (quản lý sản phẩm):

Tóm tắt:

Use case cho phép người dùng quản lý product (Upload, Download, Tạo mới )

trong 1 Activity.

Dòng sự kiện:


Use case bắt đầu khi người dùng muốn quản lý các product có trong Activity:

Người dùng chọn 1 loại product trong Activity.

1. Hệ thống yêu cầu người dùng chọn chức năng muốn thực hiện

(Upload, Download, Create Object).

2. Sauk hi người dùng chọn xong, 1 trong các luồng phụ sau được

thực hiện:

Nếu chọn “Upload”, luồng phụ “Upload product” được thực hiện.


Trang 65

Nếu chọn “Download”, luồng phụ “Download product” được thực

hiện.

Nếu chọn “Create Object”, luồng phụ “Create product” được thực

hiện.

• Upload product:

1. Hệ thống yêu cầu người dùng nhập vào tên file product muốn

upload.

2. Hệ thống lấy file từ máy người dùng lưu lại tại Server.

• Download product:

1. Hệ thống hiển thị danh sách các file(Product) mà người dùng có

thể download.

2. Người dùng chọn file cần download.

3. Hệ thống yêu cầu người dùng nhập vào địa chỉ lưu file(Tại máy

của user).

4. Hệ thống thực hiện chuyển nội dung file từ Server về máy của

user.

• Create product: Luồng này bắt đầu khi người dùng muốn tạo đối

product dạng Object. (Lưu ý kiểu này rất ít sử dụng nên ít được hổ trợ

trong chương trình)

1. Hệ thống yêu cầu người dùng nhập vào thông tin của Object (Bổ

sung sau).

2. Người dùng điền thông tin cho Object.

3. Hệ thống lưu lại thông tin Object.


Không có.


User phải đăng nhập vào hệ thống và tham gia thực hiện 1 Activity.

Post-Condition:

Nếu Use case thành công, thông tin công việc trong project bị thay đổi.


Trang 66



Không có

4.5.10. UserActivity (Xem thông tin công việc cá nhân):

Tóm tắt:

Use case cho phép 1 user có thể theo dõi thông tin hoạt động của mình. Đóng

vai trò tương tự như thời khóa biểu của user đó.

Dòng sự kiện:


Use case bắt đầu khi người dùng muốn xem thông tin hoạt động của mình.

1. Hệ thống hiển thị danh sách các project mà người dùng tham gia

2. Người dùng chọn project.

3. Hệ thống hiển thị danh sách các công việc mà người dùng tham gia:

Tên công việc, vai trò của người dùng, quyền (View, Edit), trạng thái

hiện tại của công việc, thời gian thực hiện.

4. Người dùng xác nhận xem xong.

5. Use case kết thúc.


• Không có công việc nào:

Nếu trong dòng sự kiện chính, người dùng không tham gia bất kỳ hoạt động

nào, Use case kết thúc.


Không có.


User phải đăng nhập vào hệ thống.

Post-Condition:



Không có


Trang 67

4.5.11. Login (đăng nhập):

Tóm tắt:

Use case cho phép người dùng đăng nhập vào hệ thống.

Dòng sự kiện:


Use case bắt đầu khi người dùng muốn đăng nhập vào hệ thống.

1. Hệ thống yêu cầu người dùng nhập vào Username, Password

2. Người dùng nhập Username và Password.

3. Hệ thống tiến hành kiểm tra Username và Password, và cho phép

người dùng đăng nhập hệ thống.


• Đăng nhập không hợp lệ:

Nếu trong dòng sự kiệnc chính, usename và password không hợp lệ, hệ thống

thông báo lỗi cho người dùng. Người dùng có thể nhập lại 2 thông tin trên hoặc

kết thúc việc đăng nhập.


Không có.


Không có.

Post-Condition:

Nếu Use case thành công, Người dùng đăng nhập vào hệ thống.



Không có

4.5.12. Register: (Đăng ký thành viên).

Tóm tắt:

Use case cho phép 1 người đăng ký làm thành viên của tổ chức.

Dòng sự kiện:

Ø Dòngsự kiện chính:


Trang 68

Use case bắt đầu khi 1 người muốn tham gia làm thành viên của tổ chức.

1. Hệ thống yêu cầu người dùng nhập các thông tin cá nhân:

First name: Họ.

Last name: Tên.

User name: Tên đăng nhập.

Password: mật khẩu đăng nhập.

Confirm password: Nhập lại mật khẩu.

Address: Địa chỉ tạm trú.

Email: Địa chỉ mail.

Telephone: Số điện thoại.

Fax

2. Người dùng nhập thông tin được yêu cầu.

3. Hệ thống kiểm tra username, password và ghi nhận lại thông tin.



• Username không hợp lệ:

Trong dòng sự kiện chính, nếu Username bị trùng với 1 username đã tồn tại.

Một thông báo lỗi được gửi cho người dùng. Người dùng có thể thay đổi username

hoặc hủy việc đăng ký.

• Password không hợp lệ:

Trong dòng sự kiện chính, Nếu người dùng nhập lại Password sai. Một thông

báo lỗi gửi cho người dùng. Người dùng có thể nhập lại Password hoặc hủy việc

đăng ký.


Không có.


Không có.

Post-Condition:

Nếu Use case thành công, 1 user được them vào hệ thống.


Trang 69



Không có

4.5.13. Update User Info (cập nhật thông tin cá nhân):

Tóm tắt:

Use case cho phép người dùng thay đổi thông tin cá nhân của mình(Các thông

tin đã có ở phần Register).

Dòng sự kiện:


Use case bắt đầu khi 1 người dùng muốn cập nhật lại thông tin cá nhân.

1. Hệ thống yêu cầu người dùng điền vào 1 hoặc nhiều trong các thông

tin sau:

First name

Last name

Password

Address

Email

Telephone

Fax

2. Hệ thống lưu lại thông tin mới của người dùng.

3. Dòng sự kiện chính được thực hiện lại hoặc kết thúc việc chỉnh sửa.


Không có.


User phải đăng nhập vào hệ thống.

Post-Condition:

Nếu Use case thành công, Thông tin mới về người dùng được cập nhật.




Trang 70

Không có

4.5.14. Manage User Account:

Tóm tắt:

Use case cho phép Admin quản lý các thành viên tham gia trang web: Xem

thông tin các thành viên, xóa thành viên, phân quyền cho các thành viên.

Dòng sự kiện:


Use case bắt đầu khi Admin muốn quản lý thông tin các User tham gia trang

web: Xóa User Account, Phân quyền cho các user.

1. Hệ thống hiển thị danh sách các User Account.

2. Hệ thống yêu cầu Admin chọn 1 User Account.

3. Admin chọn 1 User Acount.

4. Hệ thống yêu cầu người dùng chọn chức năng muốn thực hiện: Delete

User Account, Security Roles.

5. Người dùng chọn chức năng, 1 trong các luồng phụ sau được thực

hiện:

Nếu chọn “Delete User Account”, luồng phụ “Delete User

Account” đựơc thực hiện.

Nếu chọn “Security Roles”, luồng phụ “Security Roles” được thực

hiện.

• Delete User Account: Xóa User ra khỏi hệ thống.

1. Hệ thống hiện thống báo xác nhận thao tác xóa, đồng thời cảnh

báo Admin nếu người đó đang tham gia vào trong 1 project nào

đó.

2. Admin xác nhận thao tác xóa.

3. Hệ thống thực hiện xóa User được chọn.

4. Dòng sự kiện chính được thực hiện lại.

• Security Roles: Phân quyền cho các thành viên trong hệ thống.


Trang 71

1. Hệ thống hiển thị danh sách các Quyền(role) có trong hệ thống:

Admin, Project Manager, Member.

2. Hệ thống yêu cầu Admin chọn role cho user.

3. Admin xác nhận phân công.

4. Hệ thống lưu lại sự phân công.

5. Dòng sự kiện Security Roles được bắt đầu lại hoặc Admin có thể

chấm dứt sự phân công, Use case kết thúc.


• Không tìm thấy User:

Trong dòng sự kiện chính, Nếu không tìm thấy User Account nào thì Use case

kết thúc.

• User đang tham gia project:

Trong luồng phụ “Delete User Account”, nếu User đang tham gia 1 hay nhiều

dự án, thì hệ thống gửi thông báo đến cho Project Manager của dự án biết User

không còn tồn tại, đồng thời xóa sự phân công cho User trong project đó


Không có.


Admin phải đăng nhập vào hệ thống.

Post-Condition:

Nếu Use case thành công, 1 User bị xóa khởi hệ thống hoặc có sự phân công

role mới.



Không có

4.5.15. Search User Account:

Tóm tắt:

Use case cho phép Admin tìm kiếm User theo: User Name.

Dòng sự kiện:


Trang 72


Use case bắt đầu khi Admin muốn tìm kiếm thông tin của 1 User.

1. Hệ thống yêu cầu Admin nhập vào Username muốn tìm.

2. Hệ thống hiển thị danh sách các User Account (cùng thông tin liên

quan) có Username chứa Username muốn tìm.



• Không tìm thấy user:

Một thống báo lỗi được gửi đến Admin. Admin có thể nhập vào Username

khác hoặc hủy thao tác tìm kiếm, Use case kết thúc.


Không có.


Admin phải đăng nhập vào hệ thống.

Post-Condition:



Không có.

Chương 5. Phân tích và thiết kế hệ thống

5.1. Thiết kế dữ liệu:

Mô hình dữ liệu được thiết kế tập trung lưu trữ các thông tin của tiến trình qua

các giai đoạn: Lưu trữ quy trình mẫu, khởi tạo 1 dự án, vận hành 1 dự án và lưu

trữ các thành phần phát sinh trong quá trình vận hành dự án. Bên cạnh đó còn lưu

trữ thông tin các user.

Dữ liệu được thiết kế lưu trữ theo 3 cấp độ khác nhau, như sau:

- Cấp độ tổ chức: Lưu trữ các thông tin có tính chất chung: Người dùng, quy

trình mẫu, các tập tin sản phẩm vào ra của các dự án.

- Cấp độ dự án: Lưu trữ các thông tin của 1 dự án cụ thể.

- Cấp độ thực thi: Lưu trữ thông tin quá trình vận hành dự án.


Trang 73

Hình 8 Mô hình cơ sở dữ liệu tổng quan

5.2. Một số lược đồ cơ sở dữ liệu:

Ø Lược đồ cơ sở dữ liệu phân công user thực hiện công việc:

Hình 9 Lược đồ cơ sở dữ liệu phân công thực hiện công việc

Ø Lược đồ cơ sở dữ liệu tạo mới công việc:

Hình 10 Lược đồ cơ sở dữ liệu tạo mới công việc

Ø Lược đồ cơ sở dữ liệu tạo mới sản phẩm:


Trang 74

Hình 11 Lược đồ cơ sở dữ liệu tạo mới sản phẩm

5.3. Thiết kế xử lý:

Các xử lý chính tập trung vào việc hiển thị cây tiến trình, quản lý các sản phẩm

vào ra trong quá trình thực hiện công việc, kích hoạt các công việc tiếp theo khi

một công việc hoàn tất, phân công các thành viên vào các vai trò tương ứng trong

từng công việc cụ thể, quy định lại thời gian thực hiện công việc. Các xử lý được

mô tả bằng các lược đồ tuần tự (Sequence Diagram). Một số lược đồ tuần tự chính

được mô tả ở phần phụ lục.

Chương trình hỗ trợ hai loại dự án khác nhau:

Ø Dự án theo mô hình (Template Project): Dự án được khởi tạo theo mô hình

có sẳn do công cụ mô hình hóa phát sinh. Có khả năng tái sử dụng cho

nhiều dự án khác nhau theo cùng mẫu.

Ø Dự án không theo mô hình (None Template Project): Dự án được khởi tạo

do người dùng lần luợt thêm các công việc thích hợp vào dự án. Nói cách

khác, người quản lý dự án phải thiết kế quy trình cho dự án của mình mà

không dùng công cụ mô hình hóa. Do đó, dự án theo dạng này không có

khả năng tái sử dụng.

Các công đoạn chính trong việc khởi tạo và vận hành dự án:

- Khởi tạo dự án

Ø Đối với dự án theo mô hình hóa:

o Khởi tạo dự án từ tập tin mô hình hóa

Ø Đối với dự án không theo mô hình hóa:

o Tạo mới dự án rỗng


Trang 75

o Thêm các đối tượng(Main Process, Process, Activity, Product,

Gateway, SequenceFlow, ExtendedStatus, Expression) vào trong dự

án

- Phân công thực hiện dự án cho từng thành viên trong các công việc cụ thể.

- Quy định thời gian thực hiện dự án, thời gian thực hiện công việc cụ thể:

Người quản lý dự án có thể thay đổi thời gian thực hiện dự án, quy định lại

thời gian thực hiện dự án.

- Hiển thị cây dự án.

- Thực hiện các công việc được giao trên cây tiến trình:

5.3.1. Sơ đồ lớp:

5.3.1.1. Sơ đồ lớp các đối tượng chính trong dự án (chủ yếu được tạo

lập từ tập tin mô hình hóa nghiệp vụ):

Project

MyObjects

Model

ActivityProcess

Task

ProductAtomicCondition

Expression

Gateway

GatewayANDGatewayOR

GatewayXOR

Organization

ProcessTemplate

Role

RoleMap

SequenceFlow

Tool

TaskOnProduct

Timer

TaskTimer

ReadEvent

StartEvent

EndEvent

ActivityStatus

ProductStatus

ProductAttribute

UserDefinedType

UserDefinedTypeValue

IntermediateEvent

Hình 12 Sơ đồ lớp các đối tượng trong dự án

5.3.1.2. Sơ đồ lớp các đối tượng liên quan đến công việc:


Trang 76

MyObjects

Activity

Process Task

TaskTimerActivityStatus

TaskOnProduct

Hình 13 Sơ đồ lớp các đối tượng liên quan đến công việc

5.3.2. Một số mô hình chính:

Ø Sơ đồ các trạng thái của công việc:

InActive

Ready

Processing Finish

Abort

Waiting

Hình 14 Sơ đồ trạng thái công việc

Ø Bảng mô tả các trạng thái:

Stt Tên Mô tả

1 InActive Trạng thái công việc chưa được kích hoạt, hay

chưa có thể hiện


Trang 77

2 Ready Công việc đã được kích hoạt và sẳn sàng để thực

hiện

3 Waiting Trạng thái chờ, khi công việc trước nó được thực

hiện, nhưng chưa đến thời gian thực hiện công

việc. Khi đến thời gian thực hiện hoặc người

quản lý dự án tác động trực tiếp thì sẽ chuyển

qua trạng thái Ready

4 Processing Trạng thái đang thực hiện. Được thể hiện cụ thể

bằng các giá trị phần trăm.

5 Abort Trạng thái kết thúc thất bại. Khi người quản lý

dự án quyết định dừng công việc đang thực hiện.

Các công việc sau nó sẽ được kích hoạt.

6 Finish Trạng thái kết thúc thành công. Được thể hiện cụ

thể bằng “100%” hoặc “Finish”. Các công việc

sau nó sẽ được kích hoạt. Bảng 2 Bảng mô tả các trạng thái công việc

Ø Quy trình hiển thị dự án dưới dạng cây tiến trình:


Trang 78

Ñoïc te ân caùc saûn phaåm ñaàu vaøo/ ra cuûa coâng vieäc

Ñoïc danh saùch coâng vie äc trong qui trình chính

Kieåm tra loaïi coâng vieäc

Ñoïc saûn phaåm ñaàu vaøo/ ñaàu ra

Kieåm tra coù the å hieän

Task

KhoângÑoïc theå hieän

co âng vieäc

Ñoïc caùc theå hieän saûn phaåm ñaàu vaøo/ ñaàu ra

Kieåm tra xem coâng vieäc ñoù ñaõ ñöôïc kích hoaït chöa

Kieåm tra thôøi gian thöïc hie än

Coù

Chöa ñeán ngaøy

Caäp nhaät traïng thaùi cho theå hieän co âng vieäc

Ñeán ngaøy thöïc hieän

Ñoïc danh saùch caùc co âng vieäc trong qui trình con

Subprocess

2 loaïi coâng vieäc: Task, Subprocess

Theâm coâng vieäc vaøo caây tieán trìnhLaëp laïi qui trình "Ñoïc

danh saùch coâng vie äc" nhö trong qui trình chính

Hình 15 Quy trình hiển thị cây dự án

Ø Quy trình tìm công việc tiếp theo khi một công việc trước đó

hoàn tất. Do là một quy trình hơi phức tạp nên chúng em chỉ

trình bày ở dạng sơ đồ tổng quan.


Trang 79

Hình 16 Quy trình tìm kích hoạt công việc tiếp theo

5.3.3. Một số luồng tuần tự chính trong ứng dụng:

5.3.3.1. Lược đồ tuần tự tạo mới dự án theo mẫu có sẳn:


Trang 80

: Project Manager

SetupProjectPage Project ProcessTemplate Engine

1:Caäp nhaät thoâng tin

2: Taïo môùi döï aùn

3: Kieåm tra loaïi döï aùn

4: Laáy file moâ hình hoaù (TemplateId)

6: Ñoïc vaø löu caùc ñoái töôïng (TemplateFile)

8: Löu döï aùn

5: Laáy file moâ hình hoaù

7: Löu caùc ñoái töôïng

9: Löu döï aùn

Traû veà ID cuûa döï aùn

Hình 17 Lược đồ tuần tự tạo mới dự án theo mẫu

5.3.3.2. Lược đồ tuần tự kích hoạt 1 dự án:


Trang 81

Project StartEvent ActivityInstance Engine

1: Laáy qui trình chính cuûa döï aùn (ProjectId)

2: Tìm söï kieän baét ñaàu cuûa qui trình chính (MainProcessId)

3: Laáy söï kieän baét ñaàu qui trình

4: Tìm coâng vieäc tieáp theo trong qui trình (StartEventId)

Ñaây laø 1 luoàng tuaàn töï khaùc

5: Taïo môùi 1 theå hieän coâng vieäc (ActivityId)

6: Löu theå hieän coâng vieäc

7: Caäp nhaät laïi traïng thaùi cuûa döï aùn

Chuyeån sang traïng thaùi ñang thöïc hieän (Processing)

Hình 18 Lược đồ tuần tự kích hoạt dự án

5.3.3.3. Lược đồ tuần tự tạo mới 1 thể hiện công việc


Trang 82

AcitivtyInstance InputProductInstance Timer TaskTimer Engine

1: Taïo môùi ñoái töôïng

2: Löu theå hieän coâng vieäc

3: Taïo caùc theå hieän saûn phaåm ñaàu vaøo

Löôïc ñoà tuaàn töï "Luaân chuyeån saûn phaåm" (Derived product)

4: Laáy thôøi gian thöïc hieän (TaskId)

5: Laáy thôøi gian thöïc hieän

Thôøi gian ñöôïc ñònh nghóa trong moâ hình

6: Löu thôøi gian thöïc hieän cho theå hieän coâng vieäc

7: Löu thôøi gian thöïc hieän

Hình 19 Lược đồ tuần tự tạo mới thể hiện công việc

5.3.3.4. Lược đồ tuần tự tìm công việc tiếp theo trong dự án

Khi 1 công việc tiếp theo thì chương trình tự động tìm công việc tiếp theo

trong quy trình để kích hoạt. Quy trình tìm kiếm mang tính chất đệ quy nếu đối

tượng trả về là 1 quy trình con.


Trang 83

Project SequenceFlow Engine

1: Tìm ñoái töôïng tieáp theo (ID cuûa coâng vieäc vöøa keát thuùc)

2: Laáy ñoái töôïng tieáp theo

3: Kieåm tra loaïi ñoái töôïng

5: Xöû lyù ñoái töôïng laø qui trình con

6: Xöû lyù ñoái töôïng laø EndEvent

Coù 3 loaïi ñoái töôïng: Task, Subprocess, Event (chính laø endevent tr...

Laëp laïi qui trình kích hoaït döï aùn vôùi ID cuûa qui trình laø ID cuûa ñoái töôïng traû veà

4: Xöû lyù ñoái töôïng laø Gateway

Hình 20 Lược đồ tuần tự tìm công việc tiếp theo trong dự án

Xử lý đối tượng trả về là 1 sự kiện kết thúc (EndEvent)


Trang 84

Project Process Engine

1: Kieåm tra loaïi qui trình (IDProcess maû endevent thuoäc veà)

2: Laáy thoâng tin qui trình

3: Ghi nhaän keát thuùc döï aùn neáu laø qui trình chính

4: Tìm coâng vieäc tieáp theo vôùi (ID cuûa qui trình maø endevent thuoäc veà)

Neáu laø keát thuùc qui trình con, thì qui trình ñöôïc xem nhö laø 1 coâng vieäc vöøa keát thuùc, laëp laïi luoàng tuaàn töï "cha"

Hình 21 Lược đồ tuần tự xử lý endevent

Xử lý đối tượng là Gateway


Trang 85

Project Gateway SequenceFlow Engine

1: Laáy thoâng tin Gateway (ID)

2: Laáy thoâng tin gateway

3: Kieåm tra ñieàu kieän vaøo cuûa Gateway

Döïavaøo loaïi Gateway vaø ñieàu kieän treân caùc SequenceFlow gaén vôùi ñaàu vaøo cuûa Gateway

4: Laáy danh saùch caùc SequenceFlow ra khoûi Gateway

5: Tìm caùc ñoái töôïng tieáp theo trong SequenceFlow

7: Kieåm tra ñieàu kieän kích hoaït SequenceFlow

6: Laáy ñoái töôïng tieáp theo trong SequenceFlow

8: Danh saùch caùc ñoái töôïng traû veà

Laëp laïi qui trình kieåm tra loaïi ñoái töôïng vaø kích hoaït coâng vieäc tieáp theo

Hình 22 Lược đồ tuần tự xử lý Gateway

5.3.3.5. Lược đồ tuần tự thay đổi thông tin công việc (Edit activity)


Trang 86

Danh saùch caùc user tham gia, thôøi gian thöïc hieän

: Project ManagerEditProjectPage Activity TaskTimer UserInRole Engine

1: Choïn coâng vieäc

2: Laáy thoâng tin cuûa coâng vieäc (ActivityId)

3: Laáy thoâng tin coâng vieäc

4: Caäp nhaät thôøi gian thöïc hieän

5: Caäp nhaät thôøi gian thöïc hieän (ActivityId)

6: Caäp nhaät thôøi gian thöïc hieän

7: Caäp nhaät phaân coâng user

8: Caäp nhaät phaân coâng user (ActivityId)

9: Caäp nhaät phaân coâng userBao goàm theâm user vaø xoùa user, phaân laïi quyeàn thöïc hieän cho user (Edit,View)

Hình 23 Lược đồ tuần tự thay đổi thông tin công việc

5.3.3.6. Lược đồ tuần tự hiển thị cây tiến trình:

Cây tiến trình là hình thức trình bày dự án dưới dạng cây. Thuận tiện cho User

lúc thay đổi thông tin dự án hay thực hiện công việc.


Trang 87

Ñoïc caùc saûn phaåm do User laøm ra (Chuû yeáu laø caùc file)

: User

ProjectTreeView Project Process Task TaskOnProduct InputProductInstance OutputProductInstance Engine

1: Nhaäp vaøo ID cuûa döï aùn

2: Kieåm tra IDID phaûi laø soá nguyeân

3: Tìm döï aùn (ProjectId)

4: Ñoïc thoâng tin döï aùn

5: Kieåm tra döï aùn toàn taïi

6: Laáy caùc activity trong qui trình chính (MainProcessId)

9: Ñoïc thoâng tin cuûa coâng vieäc (TaskId)

7: Ñoïc caùc activity trong process

10: Ñoïc thoâng tin cuûa coâng vieäc

11: Ñoïc caùc saûn phaåm vaøo/ra cuûa coâng vieä (TaskId)

12: Ñoïc saûn phaåm vaùo ra cuûa coâng vieäc

17: Ñoïc caùc coâng vieäc trong subprocess (SubprocessId)

8: Kieåm tra loaïi acitivty

Task hoaëc Subprocess, Neáu laø Task, thöïc hieän töû 9->16, neáu laø Subprocess thöïc hieän 17

Laëp laïi caùc coâng vieäc töø 7->16

18: Hieån thò döï aùn leân caây tieán trình

13: Laáy caùc theå hieän saûn phaåm ñaàu vaøo (ProductId)

14: Laáy caùc theå hieän saûn phaåm ñaàu vaøo

15: Laáy caùc theå hieän saûn phaåm ñaàu ra (ProductId)

16: Laáy caùc theå hieän saûn phaåm ñaàu ra

Hình 24 Lược đồ tuần tự hiển thị cây tiến trình

5.3.3.7. Lược đồ tuần tự upload sản phẩm:


Trang 88

: UserHome FileManagerPage OutputProductInstance File Engine


2: Choïn saûn phaåm ñaàu ra

3: Choïn chöùc naêng quaûn lyù file

4: Hieån thò page FileManagerPage

5: Upload file

8: Löu saûn phaåm ñaàu ra cho coâng vieäc (FileId)

6: Löu file, traû veà FileId

7: Löu file

9: Löu saûn phaåm ñaàu ra cho coâng vieäc

Hình 25 Lược đồ tuần tự upload sản phẩm

5.3.3.8. Lược đồ tuần tự download sản phẩm:

: UserHome FileManagerPage FileDoawnload InputProductInstacne File Engine


2: Choïn saûn phaåm ñaàu vaøo

3: Choïn chöùc naêng quaûn lyù file

4: Hieån thò page FileManagerPage

5: Hieån thò danh saùch file (ProductId)

6: Ñoïc danh saùch FileId

7: Hieån thò thoâng tin file (FileId)

8: Ñoïc thoâng tin file

9: Choïn file muoán download

10: Download file (Teân file)

Hình 26 Lược đồ tuần tự doawnload sản phẩm


Trang 89

5.3.3.9. Lược đồ tuần tự thêm mới 1 đối tượng:

Nếu khởi tạo một dự án không theo mẫu template, người quản lý dự án (Project

Manager) phải thêm các đối tượng sau: Activity (Process, Subprocess, Task),

Product, UserDefinedType, Gateway, SequenceFlow. Luồng tuần tự sau có tính

chất chung cho tất cả các đối tượng trên. Mỗi loại đối tượng sẽ cần các thông tin

riêng theo chuẩn XPDL.

: Project Manager

EditNoneTemplateProjectPage Object Engine

1: Choïn loaïi object muoán theâm vaøo project

2: Taïo môùi ñoái töôïng

3: Löu thoâng tin objectPhaùt sinh ra soá ID cho object

Hình 27 Lược đồ tuần tự thêm mới đối tượng

5.3.3.10. Lược đồ luân chuyển sản phẩm

Nếu sản phẩm đầu vào của công việc này là sản phẩm đầu ra của công việc

trước đó, thì tất cả các thể hiện của sản phẩm đầu vào sẽ được lấy từ các sản phẩm

đầu ra của các công việc trước đó. Việc luân chuyển tự động được bắt đầu khi 1

công việc được kích hoạt.


Trang 90

Traû veà danh saùch caùc ID cuûa saûn phaåm

ActivityInstance TaskOnProduct OutputProductInstance InputProductInstance Engine

1: Laáy danh saùch caùc saûn phaåm ñaàu vaøo (ActivityId)

2: Laáy danh saùch caùc saûn phaåm ñaàu vaøo

3: Laáy danh saùch caùc theå hieän cuûa saûn phaåm (ProductId)

Caùc saûn phaåm ñaàu ra cuûa caùc coâng vieäc tröôùc ñoù, caùc saûn phaåm naøy ñaõ coù theå hieän

4: Laáy danh saùch caùc theå hieän cuûa saûn phaåm

5: Löu thoâng tin caùc saøn phaåm ñaàu ra (Thoâng tin theå hieän saûn phaåm)

6: Löu thoâng tin saûn phaåm

Hình 28 Lược đồ tuần tự luân chuyển sản phẩm

5.3.3.11. Lược đồ tuần tự cho việc truy xuất CSDL

Khi cần truy xuất cơ sở dữ liệu, thì tham số truyền vào là câu truy vấn. Nếu là

truy vấn dữ liệu thì kết quả trả về ở dạng bảng, hoặc đối tượng đơn giản (tương

ứng kiểu dữ liệu Object trong .NET).

Object Engine

1: Môû keát noái

2: Truy vaán döõ lieäu (Caâu truy vaán SQL)

4: Ñoùng keát noái

3: Caäp nhaät döõ lieäu (Caâu leänh caäp nhaät)

Hình 29 Lược đồ tuần tự truy xuất cơ sở dữ liệu


Trang 91

5.4. Thiết kế giao diện:

Các chức năng của hệ thống được tổ chức đưới hình thức thực đơn (menu)

Hình 30 Menu chức năng hệ thống

Giao diện của chương trình tập trung thể hiện cây tiến trình dự án. Trên cây

tiến trình tập trung thể hiện lại quy trình nghiệp vụ: Quy trình chính, quy trình con,

các công việc trong từng quy trình, các sản phẩm vào/ra của từng công việc. Khi

người dùng đăng nhập vào hệ thống chương trình tự động hiển thị danh sách các

công việc người đó phải thực hiện trong từng dự án. Người dùng chỉ việc chọn

công việc muốn thực hiện. Người dùng nhấp chuột phải để thực hiện các chức

năng khác như: Cập nhật trạng thái mở rộng cho công việc, sản phẩm, quản lý sản

phẩm.

Hình 31 Cây tiến trình dự án

Menu chính Menu con

Tên dự án

Tên qui trình

Tên công việc

Popup menu


Trang 92

Màn hình chính thực hiện công việc:

Hình 32 Màn hình vận hành dự án

Các màn hình báo cáo được trình bày dưới dạng bảng, có thể xem thông tin các

đối tượng trong màn hành báo cáo bằng cách chọn ID của đối tượng. Ví dụ khi

người dùng nhấp vào ID của công việc trên màn hình báo cáo dự án thì hệ thống

sẽ xuất ra các thông tin liên quan đến công việc đó.


Trang 93

Hình 33 Màn hình báo cáo

Chương 6. Thử nghiệm và đánh giá

6.1. Một số quy trình mẫu:

6.1.1. Quy trình đăng ký học phần:

Quy trình đăng ký học phần của trường Đại học Khoa học Tự nhiên. Mỗi đầu

học kỳ các sinh viên phải đăng ký môn học qua mạng của trường. Việc đăng ký

học phần chủ yếu do văn phòng khoa thực hiện. Tuy nhiên, trong quá trình thực

hiện, văn phòng khoa phải liên hệ với một số bộ phận sau: Phòng đào tạo, Ban

chủ nhiệm khoa, Bộ môn, phòng quản lý thiết bị, tổ kỹ thuật. Trong mô hình hóa,

mỗi bộ phận trên được phân công thành một “vai trò”. Chi tiết quy trình đăng ký

học phần được mô tả ở phần phụ lục.

Một số điểm lưu ý trong quy trình đăng ký học phần

- Có sử dụng một số quy trình con: Chuẩn bị kế hoạch giảng dạy, chuẩn bị

đăng ký học phần lý thuyết, Đăng ký học phần lý thuyết, Chuẩn bị đăng ký


Trang 94

học phần thực hành (Chuẩn bị ĐKHPTH), Đăng ký thực hành, Hiệu chỉnh

đăng ký học phần, Mở lớp trả nợ các môn tin học, Tính toán và nộp học

phí.

- Một số luồng tuần tự có sử dụng điều kiện dựa trên trạng thái mở rộng của

sản phẩm, của công việc.

- Sử dụng hai loại cổng điều khiển: AND, Xor_DATABASE.

- Sử dụng phân quyền trên sản phẩm, ví dụ: công việc “lấy số lượng phòng

máy từ tổ kỹ thuật” bao gồm hai vai trò tham gia thực hiện là “Phòng đào

tạo” và “tổ kỹ thuật’ cùng làm việc trên một sản phẩm là “số lượng phòng

máy”. Khi đó nhân viên phòng kỹ thuật có quyền “upload” sản phẩm, còn

nhân viên phòng đào tạo chỉ có quyền “download” sản phẩm.

6.1.2. Quy trình chuẩn bị thi thực hành:

Quy trình chuẩn bị công tác thi thực hành. Quy trình đơn giản chỉ sử dụng

cổng điều khiển AND.

Hình 34 Quy trình thi thực hành

6.1.3. Quy trình xét tốt nghiệp cuối khóa


Trang 95

Quy trình chỉ sử dụng cổng điều khiển AND. Công việc trước hoàn thành thì

công việc sau được kích hoạt. Quy trình này được sử dụng để minh hoạ cho “dự án

không theo mẫu mô hình hóa”.

Hình 35 Quy trình xét tốt nghiệp cuối khóa

6.2. Cài đặt và triển khai hệ thống:

Hệ thống được xây dựng và chạy thử nghiệm trên máy cục bộ. Các tập tin sản

phẩm được lưu trữ trong “c:\iPMSFiles”.

Cài đặt FlyTreeView của 9Rays.Net. Sau đó chép thư mục “ipmsimages” vào

“C:\Inetpub\wwwroot\aspnet_client\ninerays_web_ui_webcontrols_flytreeview_3

_4_4_0\images”.

Bảng mô tả một số user dùng cho việc đăng nhập hệ thống.

Stt User name Password Vai trò 1 anhduc anhduc Project manager 2 vtphong vtphong Member 3 vuql vuql Project manager 4 admin admin Admin 5 nttthuy nttthuy Member 6 nttran nttran Member

6.3. Đánh giá:


Trang 96

Sau khi chạy thử nghiệm với hai quy trình "Quy trình đăng ký học phần" và

"Quy trình xét tốt nghiệp cuối khóa". Chương trình đáp ứng tốt mục tiêu đề ra ban

đầu là khởi tạo và vận hành dự án.

Ø Ưu điểm:

o Vận hành tốt dự án theo các quy trình đã được định nghĩa (đối với cả

hai loại dự án).

o Thực hiện phân công thực hiện công việc cho nhân viên và qui định thời

gian thực hiện công việc tương đối dễ dàng.

o Màn hình báo cáo tiến độ thực hiện dự án, chi tiết thực hiện từng công

việc rõ ràng, dễ theo dõi.

o Các màn hình liên kết tốt với nhau.

o Forum thảo luận được tổ chức rõ ràng.

o Khi một user đăng nhập vào hệ thống thực hiện công việc của mình thì

người khác chỉ được xem thông tin công việc mà không được phép thực

hiện công việc đó.


o Đối với dự án không theo quy trình mẫu định sẳn, việc thêm các đối

tượng vào dự án gặp một số khó khăn do không được thực hiện trực

quan, và người dùng phải đảm bảo tính đúng đắn của qui trình mà mình

tự định nghĩa.

o Mỗi lần cập nhật thông tin thì cây tiến trình được tạo lại, do đó gây ra sự

chậm trễ và cảm giác khó chịu cho người dùng.

o Giao diện chưa tốt.

Chương 7. Tổng kết và hướng phát triển

Trong quá trình thực hiện đề tài, chúng em gặp một số khó khăn trong việc tìm

kiếm tài liệu. Vì đây là chủ đề tương đối mới nên hầu hết các tài liệu đều viết bằng

tiếng anh dưới dạng các bài nghiên cứu, các bài báo nên việc tìm tài liệu chính

thức gặp một số khó khăn. Ngoài ra, việc xây dựng các quy trình thử nghiệm cũng

gặp nhiều khó khăn do chúng em chưa có kiến thức về các nghiệp vụ trong thực


Trang 97

thế. Sau đây là một số kết quả mà chúng em đạt được sau quá trình thực hiện đề

tài.

7.1. Những kết quả đạt được:

7.1.1. Về mặt lý thuyết:

• Kiến thức về vấn đề mô hình hóa và vận hành quy trình nghiệp vụ

hiện nay. Thực hiện so sánh đặc điểm của các ngôn ngữ mô hình

hóa.

• Nguyên lý vận hành quy trình nghiệp vụ.

• Tài liệu tổng quan về ngôn ngữ mô hình hóa BPML.

• Tài liệu tổng quan về ngôn ngữ mô hình hóa XPDL.

• Kết quả nghiên cứu về ngôn ngữ mô hình hóa eXPDL và công cụ

mô hình hóa MyXPDL.

7.1.2. Về mặt ứng dụng:

• Xây dựng ứng dụng hỗ trợ vận hành quy trình nghiệp vụ được đặc tả

theo ngôn ngữ eXPDL trên môi trường WEB. Ứng dụng đã đáp ứng

được các chức năng sau:

o Lưu trữ các quy trình mẫu.

o Khởi tạo dự án theo quy trình mẫu.

o Khởi tạo dự án không theo quy trình mẫu.

o Vận hành dự án theo các luồng điều khiển và theo các ràng

buộc về thời gian.

o Quản lý dự án: Quản lý thông tin User tham gia dự án, quản

lý các sản phẩm trong dự án, quản lý các công việc về thời

gian và nhân sự, điều chỉnh dự án cho kịp tiến độ.

o Hỗ trợ người dùng làm việc trên môi trường phân tán.

• Ứng dụng hỗ trợ thiết kế và vận hành trực tiếp các quy trình đơn

giản.

7.2. Ưu và khuyết điểm của hệ thống:


Trang 98

Hệ thống đáp ứng tốt mục tiêu đề ra ban đầu. Sau đây là một số ưu điểm và

khuyết điểm của hệ thống.

Ø Ưu điểm:

o Hệ thống vận hành tốt quy trình nghiệp vụ theo ngôn ngữ eXPDL.

o Hệ thống hỗ trợ chức năng tự định nghĩa và vận hành dự án trực tiếp

trong hệ thống (không phải sử dụng công cụ mô hình hóa để định nghĩa

quy trình nghiệp vụ).

o Hệ thống trợ giúp một phần làm việc nhóm trong cùng một công việc

thông qua forum thảo luận.


o Hệ thống chưa hỗ trợ hết các đối tượng được định nghĩa trong mô hình

hóa.

o Giao diện chưa tiện dụng đối với người dùng.

o Vấn đề phân quyền cho người dùng chưa được quản lý tốt.

o Đối với dự án lớn thì vấn đề hiển thị cây tiến trình dự án sẽ thực hiện

chậm.

o Hệ thống không kiểm tra tính đúng đắn của mô hình (ví dụ trong mô

hình có vòng lặp vô hạn…). Mặc định hệ thống xem như người dùng

định nghĩa đúng quy trình nghiệp vụ.

7.3. Hướng phát triển:

Một số hướng phát triển trong tương lai:

• Hỗ trợ vận hành tiến trình có kết hợp với các biến cố.

• Hỗ trợ chức năng kiểm tra tính đúng đắn của mô hình.

• Hỗ trợ hết các kiểu đối tượng được định nghĩa trong mô hình: Sản phẩm

dạng đối tượng, các cơ chế lặp, cơ chế đền bù, các loại biến cố…

• Tích hợp quy trình khác vào dự án hiện tại.

• Cơ chế truyền thông giữa các tiến trình.

• Cung cấp thêm các tiện ích quản lý cho người dùng, tăng tính tiện dụng.


Trang 99

• Hỗ trợ người dùng theo dõi tiến độ thực hiện công việc, dự án dưới

dạng các biểu đồ.

• Hỗ trợ người dùng làm việc nhóm: tạo không gian làm việc riêng của

từng nhóm.

7.4. Lời kết:

Vì thời gian thực hiện có hạn, trong khuôn khổ luận văn, những phần nghiên

cứu mà chúng em đạt được không tránh khỏi những sai sót. Trong phần trình bày

của mình , chúng em đã cố gắng đưa ra các kiến thức tổng quan về vấn đề mô hình

hóa và quản lý quy trình nghiệp vụ hiện nay. Bên cạnh đó chúng em cũng xây

dựng được ứng dụng hỗ trợ vận hành quy trình nghiệp vụ. Với mong muốn xây

dựng một ứng dụng hoàn chỉnh về quản lý quy trình nghiệp vụ, chúng em sẽ cố

gắng nhiều hơn để nghiên cứu và xây dựng ứng dụng dựa trên kết quả chúng em

đã đạt được. Chúng em rất mong nhận được sự hướng dẫn của quí thầy cô, sự ủng

hộ và đóng góp của các bạn quan tâm đến vấn đề này.

Tài liệu tham khảo

[1.] Workflow and Process Management, Carol Prior, Maestro BPE Pty

Limited, Australia.

[2.] Workflow classification Embeded & Autonomus Workflow Management

System, Michael zur Muehlen, 10-3-2000, WfMC.

[3.] Business Process Modeling Language, Assaf Arkin and Intalio, 13-11-

2002.

[4.] BPMN and Business Process Management , Introduction to the new

Business Process Modeling Standard, Martin Owen and Jog Raj, Popkin

Software.

[5.] http://www.wfmc.org

[6.] http://www.bpmi.org

[7.] http://research.ibm.com

[8.] http://xml.coverpages.org/bpel4ws.html

[9.] http://ifr.sap.com/bpel4ws/index.html

http://www.wfmc.org

http://www.bpmi.org

http://research.ibm.com

http://xml.coverpages.org/bpel4ws.html

http://ifr.sap.com/bpel4ws/index.html


Trang 100

[10.] http://www.bpmn.org/Documents/Introduction%20to%20BPMN.pdf

[11.] http://www.fairdene.com/processes

Phụ lục

Phụ lục 1: Mô tả các bảng cơ sở dữ liệu

Ø Cấp độ tổ chức:

Tbl_User

Primary key:ID

Ghi chú: lưu trữ thông tin các user trong tổ chức

Stt Tên Kiểu dữ liệu Ghi chú

1 ID Số nguyên Do SQL phát sinh

2 Firstname Chuỗi

3 Lastname Chuỗi

4 Username Chuỗi Tên đăng nhập

5 Password Chuỗi

6 Address Chuỗi

7 Email Chuỗi “Ready”, “Finish”

8 Telephone Chuỗi

9 Fax Chuỗi

10 CreatedDate Ngày Ngày đăng ký thành viên

11 LastLogin Ngày Ngày login cuối cùng

12 Status Chuỗi Cho biết trạng thái hiện tại

của User: Online, Offline Bảng 3 CSDL mô tả người dùng

Tbl_AppRole

Primary key:ID

Ghi chú:Lưu các vai trò trong tổ chức, ví dụ: Project Manager,

Member, Admin



http://www.bpmn.org/Documents/Introduction%20to%20BPMN.pdf

http://www.fairdene.com/processes


Trang 101

2 Name Chuỗi

3 Description Chuỗi

4 AutoAssignment Boolean Bảng 4 CSDL mô tả quyền trong hệ thống

Tbl_AppRoleMap

Primary key:UserID,AppRoleID

Ghi chú: Lưu trữ việc phân vai trò cho các thành viên trong tổ

chức.


1 UserID Số nguyên

2 AppRoleID Số nguyên Bảng 5 CSDL mô tả sự phân quyền trong hệ thống

Tbl_ProcessTemplate

Primary key: ID

Ghi chú: Lưu trữ các quy trình mẫu trong tổ chức.



2 Name Chuỗi


4 TemplateFile Chuỗi Tên file mô hình hóa

5 CreatedDate Ngày Ngày tạo template

Bảng 6 CSDL lưu trữ các mẫu mô hình hóa Tbl_File

Primary key: ID

Ghi chú: Lưu trữ các file trong tổ chức, thường là file của các sản

phẩm vào ra trong các dự án.



2 Name Chuỗi Tên file

3 Path Chuỗi Tên file đầy đủ(gồm đường


Trang 102

dẫn) trên server.


5 UploadDate Ngày Ngày upload file lên Server

Bảng 7 CSDL lưu trữ các tập tin Ø Cấp độ dự án:

Tbl_Project

Primary key: ID

Ghi chú: Lưu trữ thông tin các dự án (Project) trong tổ chức.


1 ID Số nguyên

2 Name Chuỗi Tên project


4 TemplateID Số nguyên ID của template, tham chiếu

bảng tbl_ProcessTemplate.

= 0: không sử dụng template

5 IDMainProcess Chuỗi ID process chính

6 CreatedDate Ngày Ngày tạo project

7 FinishDate Ngày Ngày kết thúc project

8 State Chuỗi Trạng thái: Ready,

Processing, Finish, Abort

9 AuthorID Số nguyên ID của User setup

10 IsUseTemplate Chuỗi True: Sử dụng template

False: Không sử dụng

temlate, mang tính tiện dụng

có thể xác định thông qua

TemplateID Bảng 8 CSDL lưu trữ dự án

Tbl_Model

Primary key: ID

Ghi chú: thông tin các Model được định nghĩa trong template.


Trang 103


1 ID Số nguyên

2 Name Chuỗi


4 Author Chuỗi Bảng 9 CSDL lưu trữ mô hình

Tbl_Role

Primary key:ID

Ghi chú: thông tin các role tham gia trong dự án.


1 ID Số nguyên

2 Name Chuỗi


4 Organization Số nguyên Bảng 10 CSDL lưu trữ vai trò

Tbl_Process

Primary key:ID

Ghi chú: Lưu trữ các process trong các dự án.


1 ID Chuỗi

2 Name Chuỗi


4 Document Chuỗi

5 IsAdHoc Chuỗi “TRUE”, “FALSE”

6 IsTransaction Chuỗi Chỉ có ý nghĩa khi là

subprocess

7 IDParent Số nguyên ID cha của process, nếu là

subprocess thì <> 0, ngược

lại = 0.//Không sử dụng

8 ModelID Chuỗi ID model


Trang 104

Bảng 11 CSDL lưu trữ tiến trình Tbl_Activity

Primary key:ID

Ghi chú: lưu trữ các activity (task,subprocess).


1 ID Số nguyên

2 Name Chuỗi


4 IDProcess Số nguyên Process chứa Task, có thể là

process hoặc subprocess

5 LoopType Chuỗi Mang 3 giá trị: None,

Standard, MultiInstance

7 GenerateInstance Số nguyên Mang 2 giá trị 0(Serial),

1(Parallel), có ý nghĩa khi

LoopType là MultiInsatnce

8 Maximum Số nguyên Khi LoopType là

MultiInstance

9 Moderator Số nguyên Cho biết Agent nào làm

Moderator, Không có =0

10 IsTransaction Chuỗi TRUE,FALSE

11 IDIntermediateEvent Chuỗi

12 Type Chuỗi 2 giá trị: Task, SubProcess

Bảng 12 CSDL lưu trữ công việc Tbl_ActivityStatus

Primary key:ID (Chính là ID của Activity)

Ghi chú: Lưu trạng thái mở rộng của các activity


1 ID Chuỗi ID của activity

2 Name Chuỗi



Trang 105

4 Type Chuỗi Kiểu của status

5 UserDefinedTypeId Chuỗi Tham chiếu đến

tbl_UserDefinedType

6 CurrentExtStatusId Số nguyên Giá trị hiện tại của

activitystatus, tham chiếu

đến

tbl_UserDefinedTypeValues Bảng 13 CSDL lưu trữ trạng thái mở rộng của công việc

Tbl_Product

Primary key: ID

Ghi chú: Lưu các sản phẩm của dự án.


1 ID Chuỗi

2 Name Chuỗi


4 Type Chuỗi

5 Document Chuỗi

6 ToolID Số nguyên Tham chiếu đến tbl_Tool

7 TemplateFile Chuỗi

8 ModelID Số nguyên Sử dụng đối với template

project

9 ProjectID Số nguyên Sử dụng đối với none

template project Bảng 14 CSDL lưu trữ sản phẩm

Tbl_ProductStatus

Primary key:ID (Chính là ID của product)

Ghi chú: Lưu các trạng thái mở rộng của product


1 ID Chuỗi

2 Name Chuỗi


Trang 106


4 Type Chuỗi Kiểu của status


tbl_UserDefinedType

6 CurrentExtStatusId Số nguyên Giá trị hiện tại của product

status, tham chiếu đến

tbl_UserDefinedTypeValues Bảng 15 CSDL lưu trữ trạng thái mỡ rộng của sản phẩm

Tbl_ProductAttribute

Primary key:ID (ID của product)

Ghi chú: Lưu trữ các thuộc tính của sản phẩm nếu loại sản phẩm là

Object


1 ID Số nguyên

2 Name Chuỗi

3 Type Chuỗi Có 3 loại cơ bản: Integer,

Chuỗi, Boolean.

4 Value Chuỗi Giá trị của Attribute tùy

thuộc vào Type

5 Description Chuỗi Thông tin mô tả them

Bảng 16 CSDL lưu trữ thuộc tính sản phẩm Tbl_TaskOnProduct

Primary key:ID

Ghi chú:Lưu trữ các product tham gia trong các Activity(task)



2 IDTask Chuỗi Tham chiếu tbl_Activity

3 IDProduct Chuỗi Tham chiếu tbl_Product

4 Direction Chuỗi 2 giá trị : in, out

Bảng 17 CSDL lưu trữ các sản phẩm vào/ra của công việc Tbl_RoleMap


Trang 107

Primary key: IDRole, IDTask

Ghi chú: Lưu trữ phân role thực hiện các Activity( task), nếu là

template project


1 IDTask Chuỗi Tham chiếu tbl_Activity

2 IDRole Chuỗi Tham chiếu tbl_Role

Bảng 18 CSDL lưu trữ phân vai trò thực hiện công việc Tbl_UserDefinedType

Primary key:ID

Ghi chú: Lưu các kiểu dữ liệu mở rộng do người dùng tự định

nghĩa.


1 ID Chuỗi

2 Name Chuỗi


4 OrganizationID Số nguyên Sử dụng khi là template

project

5 ProjectID Số nguyên Sử dụng khi là none

template project Bảng 19 CSDL lưu trữ kiểu dữ liệu tự định nghĩa

Tbl_UserDefinedTypeValues

Primary key:ID

Ghi chú:Lưu trữ các giá trị tương ứng với các UserDefinedType


1 ID Số nguyên


tbl_UserDefinedType

3 Content Chuỗi Giá trị tương ứng

Bảng 20 CSDL lưu trữ giá trị các kiểu dữ liệu tự định nghĩa Tbl_SequenceFlow

Primary key:ID


Trang 108

Ghi chú: Danh sách các luồng điều khiển.


1 ID Chuỗi


3 Alternative Boolean

4 IDRef Chuỗi ID của Activity start: Event,

task, Gateway

5 RefType Chuỗi Loại đối tượng start: Task,

Process, Gateway, Event

6 Target Chuỗi ID của Activity end.

7 TargetType Chuỗi Tương tự RefType

8 IDProcess Chuỗi ID của Process

Bảng 21 CSDL lưu trữ luồng tuần tự Tbl_Expression

Primary key: ID

Ghi chú: Lưu các biểu thức điều kiện, Mỗi SequenceFlow chỉ có 1 Expression, do

đó lấy IDSequence làm ID của tbl_Expression, tương tự với Subprocess và Task


1 ID Chuỗi Chính là ID của object chứa

Expression

2 Type Chuỗi Hai giá trị: Manual, Auto

3 ManualCondition Chuỗi Type=Manual

4 ParentType Chuỗi Kiểu đối tượng mà Exp

thuộc về: PROCESS, TASK,

SEQUENCE Bảng 22 CSDL lưu trữ điều kiện

Tbl_AtomicCondition

Primary key: ID ( Phát sinh tự động trong SQL)

Ghi chú: Tập các điều kiện nguyên tố.



Trang 109

1 ID Số nguyên

2 Type Chuỗi Hai giá trị: Activity(gồm

Task và Process), Product

3 IDActivity Chuỗi

4 IDProduct Chuỗi

5 StatusName Chuỗi Tên trạng thái mở rộng của

Act or Pro

7 Value Chuỗi Giá trị đánh giá

8 IDExpression Chuỗi Tham chiếu đến

tbl_Expression Bảng 23 CSDL lưu trữ biểu thức điều kiện nguyên tố

Tbl_Gateway

Primary key:ID

Ghi chú: Danh sách các gateway.


1 ID Chuỗi

2 Type Chuỗi


4 IsDiscriminator Boolean Chi dùng XOR way

5 IDProcess Chuỗi Tham chiếu đến tbl_Process

6 DefaultGateway Chuỗi Tham chiếu đến

tbl_SequenceFlow. Luồng

mặc định ra gateway Bảng 24 CSDL lưu trữ cổng điều khiển

Tbl_StartEvent

Primarykey: ID

Ghi chú: Lưu trữ các start event trong process và các subprocess



Trang 110

1 ID Chuỗi


3 Document Chuỗi File name

4 Type Chuỗi Có 4 loại: None, Message,

Rule, Timer, Link

5 Message Chuỗi Thông điệp chuyển đến cho

start event.

6 Link Số nguyên Id của EndEvent khác đóng

vai trò kích hoạt cho tiến

trình này

7 IDExpression Số nguyên Khi Type là Rule, chứa ID

của biểu thức điều kiện để

kích hoạt StartEvent.

8 IDTimer Số nguyên Khi Type là Timer, chức ID

của bộ Timer.

9 IDProcess Số nguyên ID của Process trực tiếp mà

Event thuộc về. Bảng 25 CSDL lưu trữ biến cố bắt đầu

Tbl_IntermediateEvent

Primary key: ID

Ghi chú: Lưu các biến cố trung gian


1 ID Chuỗi




Compensation, Exception,

Timer, Link


start event.


Trang 111

6 Link Chuỗi

7 Exception Chuỗi Khi Type là Rule, chứa ID

của biểu thức điều kiện để

kích hoạt StartEvent.

8 Compensation Chuỗi


Event thuộc về. Bảng 26 CSDL lưu trữ biến cố trung gian

Tbl_EndEvent

Primary: ID

Ghi chú: Lưu trữ các end event trong Process và các subprocess


1 ID Chuỗi




Exception, Timer, Cancel,

Terminate, Compensation.


start event.

6 Link Số nguyên Id của EndEvent khác đóng

vai trò kích hoạt cho tiến

trình này

7 Exception Chuỗi Chứa lỗi ngoại lệ khi kết

thúc. Để đơn giản chỉ là câu

thong báo.

8 IDTimer Số nguyên Khi Type là Timer, chức ID

của bộ Timer.

9 IDCompensation Số nguyên ID chỉ tới 1 Activity giải


Trang 112

quyết đền bù, Nếu không có

= 0.


Event thuộc về. Bảng 27 CSDL lưu trữ biến cố kết thúc

Tbl_Timer

Primary key: ID

Ghi chú:


1 ID Chuỗi ID của object có gắn Timer

2 Type Chuỗi Loại Timer


5 Document Chuỗi

6 Month Chuỗi

7 Year Chuỗi

Chỉ dung khi Type là

“TIMEDATE”

8 TimeCycle Chuỗi Bảng 28 CSDL lưu trữ bộ định giờ

Ø Cấp độ thực thi:

Tbl_ActivityInstance

Primary key:ID

Ghi chú:Lưu thể hiện của các activity


1 ID Số nguyên

2 IDActivity Chuỗi Tham chiếu đến tbl_Activity

3 Type Chuỗi Loại Activity: Task,

Subprocess, mang tính chất

tiện dụng, vì có thể suy ra từ

IDActivity

4 State Chuỗi Trạng thái: Ready,

Processing(theo %), finish,


Trang 113

abort.

5 Version Số nguyên Nếu activity được lặp lại,

tăng Version lên 1

6 ActiveDate Ngày Ngày bắt đầu thực hiện

7 LastModifyDate Ngày Ngày cập nhật cuối cùng

8 FinishDate Ngày Ngày hoàn thành

9 Deadline Số nguyên thời gian thực hiện

10 UserID Số nguyên Nguời thực hiện cuối cùng

11 ProjectID Số nguyên Mang tính tiện dụng, thuận

tiện cho việc tổng kết báo

cáo

12 IsLock Boolean Trạng thái instance, khi 1

User đăng nhập thực hiện

công việc thì instance bị

khóa.

13 FirstEditedDate Ngày Ngày thực hiện công việc

đầu tiên. Bảng 29 CSDL lưu trữ thể hiện công việc

Tbl_ActInstanceHistory

Primary key:ID

Ghi chú: Lưu lại quá trình thực hiện 1 công việc của các user


1 ID Số nguyên

2 IDInstance Số nguyên Tham chiếu đến

tbl_ActivityInstance

3 ModifyDate Ngày Ngày thực hiện

4 UserID Số nguyên Người thực hiện, tham chiếu

tbl_User

5 State Chuỗi Trạng thái sau khi thực hiện

Bảng 30 CSDL lưu vết quá trình thực hiện công việc Tbl_ProductInstance


Trang 114

Primary key:ProductID

Ghi chú: Lưu thể hiện của 1 Product nói chung


1 ProductID Chuỗi

2 ExtStatusID Số nguyên Tham chiếu đến

tbl_UserDefinedTypeValues Bảng 31 CSDL lưu trữ thể hiện sản phẩm

Tbl_InputProductInstance

Primary key:ID

Ghi chú: thông tin thể hiện sản phẩm đầu vào của các activity


1 ID Số nguyên

2 ProductID Chuỗi Tham chiếu đến tbl_Product

3 TaskID Chuỗi Tham chiếu đến tbl_Activity

4 FileId Số nguyên Tham chiếu đến tbl_Files

5 InputMethod Chuỗi Hai giá trị: Upload, Derived

6 OutputProductId Số nguyên Quản lý tự động các

product. Inputproduct chính

là OutputProduct của các

activity trước đó. Bảng 32 CSDL lưu trữ thể hiện sản phẩm đầu vào của công việc Tbl_OutputProductInstance

Primary key:ID

Ghi chú: thông tin thể hiện sản phẩm đầu ra của các activity


1 ID Số nguyên

2 ProductID Chuỗi Tham chiếu đến tbl_Product


4 FileId Số nguyên Tham chiếu đến tbl_Files

Bảng 33 CSDL lưu trữ thể hiện sản phẩm đầu ra của công việc Tbl_TaskTimer


Trang 115

Primary key:TaskID, chính là ID của công việc.

Ghi chú: lưu các timer do PM thiết lập lại(hoặc tạo mới) cho các

activity (Task).


1 TaskID Chuỗi

2 Start Ngày Ngày bắt đầu

3 Finish Ngày Ngày kết thúc

4 Duration Số nguyên Thời gian thực hiện

5 Unit Chuỗi Đơn vị tính: Days, Months,

Years Bảng 34 CSDL lưu trữ thời gian thực hiện công việc

Tbl_UserInRoles

Primary key:ID

Ghi chú:Lưu lại việc phân chia các user tham gia vào trong các

Activity (Task) cụ thể .


1 ID Số nguyên

2 UserID Số nguyên Tham chiếu đến tbl_User

3 RoleID Số nguyên Tham chiếu đến tbl_Role,

có thể rỗng nếu là none

template project.


5 EditRight Chuỗi quyền thực hiện: Edit, View

6 Notification Boolean True: Gửi thông báo cho các

User nếu Task được kích

hoạt.

7 ProjectID Số nguyên Mang tính tiện dụng,thuận

tiện cho báo cáo. Bảng 35 CSDL lưu trữ phân công vai trò cho người dùng trong dự án

Tbl_Question


Trang 116

Primary key:ID

Ghi chú:Lưu các câu hỏi trong forum thảo luận


1 ID Số nguyên

2 ObjectID Chuỗi ID của đối tượng liên quan

đến câu hỏi (ID của sản

phẩm hoặc công việc)

3 CreatedByUser Số nguyên ID của user đã post câu hỏi

4 CreatedDate Ngày Ngày post câu hỏi lên forum

5 Title Chuỗi Tiêu đề

6 Content Chuỗi Nội dung

Bảng 36 CSDL lưu trữ câu hỏi Tbl_Reply

Primary key:ID

Ghi chú: Lưu các câu trả lời các câu hỏi trên forum


1 ID Số nguyên

2 QuestID Số nguyên ID của câu hỏi, khác “0”

nếu SelfReply là “false”

3 CreatedByUser Số nguyên ID của user đã trả lời câu

hỏi

4 CreatedDate Ngày Ngày trả lời câu hỏi lên

forum

5 Title Chuỗi Tiêu đề

6 Content Chuỗi Nội dung

7 SelfReply Boolean True: Trả lời cho câu trả lời

False: Trả lời cho câu hỏi

8 ParentID Số nguyên Khác “0” nếu SelfReply là

“true” Bảng 37 CSDL lưu trữ câu trả lời


Trang 117

Phụ lục 2: Các màn hình giao diện chính

Ø Màn hình thực hiện công việc

Đây là màn hình chính khi 1 User đăng nhập vào hệ thống

Hình 36 Màn hình thực hiện công việc

Ø Màn hình tạo mới 1 dự án

Tên dự án Công việc hiện tại

Cây tiến trình

Trạng thái công việc


Trang 118

Hình 37 Màn hình tạo mới dự án

Ø Màn hình phân công thực hiện công việc trong dự án:

Người quản lý dự án có thể thay đổi thời gian thực hiện của dự án.

Màn hình quy định thời gian thực hiện công việc:

Menu chính


Trang 119

Hình 38 Màn hình quy định thời gian thực hiện công việc

Màn hình phân công user thực hiện công việc:

Công việc đã hoàn thành

Công việc chưa thực hiện


Trang 120

Hình 39 Màn hình phân công user thực hiện công việc

Ø Màn hình thêm mới các đối tượng vào dự án (dự án không theo mẫu)

Màn hình thêm các đối tượng: Quy trình, công việc, sản phẩm, cổng điều khiển

vào dự án hoặc quy trình. Người dùng có thể phân công User thực hiện dự án,

thêm các sản phẩm vào ra của từng công việc.

Cập nhật lại quyền cho user

Thêm user thực hiện

Xóa phân công cho user


Trang 121

Hình 40 Màn hình chính thêm công việc vào dự án

Thêm sản phẩm


Trang 122

Hình 41 Màn hình thêm sản phẩm

Thêm cổng điều kiển


Trang 123

Hình 42 Màn hình thêm cổng điều khiển

Thêm kiểu dữ liệu tự định nghĩa


Trang 124

Hình 43 Màn hình thêm kiểu dữ liệu tự định nghĩa

Thêm các luồng điều khiển vào quy trình


Trang 125

Hình 44 Màn hình thêm luồng điều khiển vào quy trình

Màn hình quản lý sản phẩm

Các đối tượng trong qui trình


Trang 126

Hình 45 Màn hình quản lý sản phẩm

Ø Màn hình xem thông tin công việc trong 1 dự án


Trang 127

Hình 46 Màn hình xem thông tin công việc

Ø Màn hình báo cáo dự án


Trang 128

Hình 47 Màn hình báo cáo dự án

Phụ lục 3: Quy trình đăng ký học phần

Quy trình đăng ký học phần áp dụng tại trường Đại học Khoa học Tự nhiên, áp

dụng cho khoa Công nghệ thông tin. Quy trình được phân chia thực hiện theo thời

gian. Chi tiết quy trình như sau:

Quy trình tổng quan:


Trang 129

Hình 48 Quy trình đăng ký học phần

Cuối học kỳ trước: Bộ phận văn phòng khoa (Khoa CNTT) chuẩn bị cho công

tác giảng dạy. Dựa vào thời khóa biểu môn chung và chương trình đào tạo để soạn

ra kế hoạch giảng dạy cụ thể cho khoa, gồm các công việc nhỏ sau:

- Giáo vụ khoa soạn kế hoạch giảng dạy.

- Chuyển thời khóa biểu cho phòng quản lý thiết bị để xin phòng, nếu không

xếp được phòng theo yêu cầu thì phải đổi lại thời khóa biểu.

- Ban chủ nhiệm khoa duyệt và kết hợp với bộ môn phân công giảng dạy.

- Thông báo cho giáo viên đăng ký giờ dạy lý thuyết.

Quy trình mô hình hóa:

Hình 49 Quy trình chuẩn bị công tác giảng dạy


Trang 130

Đầu học kỳ: Chuẩn bị đăng ký học phần lý thuyết. Dựa vào kế hoạch giảng

dạy và điều kiện phòng máy để lập lịch đăng ký học phần cụ thể cho sinh viên.

Bao gồm các công việc cụ thể sau:

- Nhập thời khóa biểu chính thức vào hệ thống SMS cho sinh viên tham

khảo.

- Soạn lịch đăng ký học phần cụ thể cho từng lớp.

- Thông báo cho sinh viên lịch đăng ký học phần.

- Nhắc tổ kỹ thuật chuẩn bị phòng máy.

Hai công việc cuối có thể thực hiện song song.


Hình 50 Quy trình chuẩn bị đăng ký học phần lý thuyết

Đăng ký học phần lý thuyết: sinh viên đăng nhập vào hệ thống SMS để đăng

ký học phần lý thuyết theo thời khóa biểu. Bao gồm các công việc cụ thể sau:

- Bộ phận văn phòng khoa theo dõi và hiệu chỉnh các thông số SMS để sinh

viên đăng ký học phần lý thuyết.

- Đăng ký học phần lý thuyết.


Trang 131

- Văn phòng khoa thực hiện hiệu chỉnh thông tin cá nhân sinh viên nếu có

yêu cầu. Công việc này có thể được thực hiện song song với “sinh viên thực

hiện đăng ký học phần lý thuyết”.

- Sau khi sinh viên đăng ký xong, văn phòng khoa thực hiện thống kê số

lượng sinh viên đăng ký, xuất kết quả đăng ký học phần cụ thể của sinh

viên.

Quy trình mô hình hóa

Hình 51 Quy trình đăng ký học phần lý thuyết

Tuần 1: Chuẩn bị đăng ký học phần thực hành.Dựa vào kế hoạch giảng dạy và

điều kiện phòng máy để soạn lịch đăng ký học phần thực hành cụ thể. Bao gồm

các công việc cụ thể sau:

- Văn phòng khoa (VPK) lấy số lượng máy từ tổ kỹ thuật.

- VPK lấy thông tin đăng ký phòng máy của các lớp cao học.

- VPK lấy yêu cầu phòng máy của từng môn học cụ thể, nếu có.

Ba công việc trên có thể được thực hiện song song.

- VPK sắp thời khóa biểu thực hành cho các lớp.

- VPK sắp lịch đăng ký học phần thực hành cho sinh viên các khóa.

- VPK thông báo cho sinh viên lịch đăng ký học phần thực hành.



Trang 132

Hình 52 Quy trình chuẩn bị đăng ký thực hành

Tuần 2: Đăng ký học phần thực hành. Sinh viên đăng nhập vào hệ thống SMS

để đăng ký học phần thực hành. VPK xuất kết quả đăng ký học phần thực hành.

VPK hiệu chỉnh các thông tin cần thiết cho việc đăng ký. Bao gồm các công việc

cụ thể sau:

- VPK theo dõi và hiệu chỉnh thông số SMS để sinh viên thực hiện đăng ký

học phần thực hành.

- VPK hiệu chỉnh đăng ký học phần lý thuyết đối với các môn chuyên ngành

cho sinh viên.

- Sinh viên thực hiện đăng ký học phần thực hành.

- VPK xuất kết quả đăng ký học phần thực hành.



Trang 133

Hình 53 Quy trình đăng ký thực hành

Tuần 3: Hiệu chỉnh đăng ký học phần. Bao gồm các công việc cụ thể sau:

- VPK lên lịch hiệu chỉnh đăng ký học phần cho sinh viên các khóa.

- VPK thông báo lịch hiệu chỉnh đăng ký học phần.

- VPK theo dõi và hiệu chỉnh các thông số SMS để sinh viên đăng ký hiệu

chỉnh (có thể thực hiện song song với thông báo lịch hiệu chỉnh đăng ký

học phần).

- VPK xuất kết quả đăng ký học phần cuối cùng.


Hình 54 Quy trình hiệu chỉnh học phần

Tuần 5, 7: Mở lớp trả nợ các môn tin học. Dựa vào yêu cầu của sinh viên,

PĐT và BCN khoa xét duyệt mở lớp trả nợ cho sinh viên. Bao gồm các công việc

cụ thể sau:


Trang 134

- VPK nhận đơn mở lớp trả nợ của sinh viên, nếu có.

- BCN khoa và PĐT xét duyệt.

- Nếu BCN khoa và PĐT đồng ý Khoa bố trí giáo viên dạy.

- VPK liên hệ phòng quản lý thiết bị để xin phòng.

- Thông báo cho sinh viên các môn trả nợ và thời gian đăng ký, đóng học phí

tại PĐT.


Hình 55 Quy trình đăng ký trả nợ

Tuần 8: Tính toán và nộp học phí. Dựa vào kết quả đăng ký học phần để tính

học phí cho sinh viên. Bao gồm hai công việc thực hiện song song như sau:

- VPK nhận từ phòng đào tạo (PĐT) kết quả đăng ký học phần - học phí để

phát cho sinh viên các khóa.

- VPK thông báo thời hạn nộp học phí cho từng khóa (nhận từ PĐT)


Hình 56 Quy trình tính toán và đóng học phí


Trang 135

Danh sách các vai trò trong mô hình hóa:

Hình 57 Các vai trò trong quy trình đăng ký học phần

Danh sách các sản phẩm trong mô hình hóa:

Hình 58 Các sản phẩm trong quy trình đăng ký học phần