KIẾN THỨC NỀN TẢNG
Lược đồ hướng mô hình
Trong phần này, luận văn trình bày tổng quan về kiến trúc metamodeling, siêu mô hình metamodel và ngôn ngữ ràng buộc đối tượng OCL
2.1.1 Kiến trúc metamodeling Động lực cơ bản của phát triển phần mềm hướng mô hình MDSD (Model-Driven Software Development) là nâng cao năng suất và chất lượng phát triển phần mềm bằng cách nâng cao mức độ trừu tượng Có 4 loại thay đổi chính ảnh hưởng đến vòng đời của các chế tác phần mềm bao gồm: Thay đổi nền tảng triển khai; thay đổi nền tảng phát triển; thay đổi yêu cầu; thay đổi nhân sự Thông qua việc chuyển trọng tâm phát triển từ mã nguồn sang các mô hình có mức độ trừu tượng chống lại các thay đổi được đề cập ở trên, có thể cải thiện đáng kể vòng đời của các chế tác phần mềm Để chống lại các thay đổi đe doạ đến vòng đời của các chế tác phần mềm, các kỹ thuật metamodeling ra đời [21]
Metamodeling mở rộng các công nghệ mô hình hóa hiện có, như hỗ trợ trực tiếp cho ngôn ngữ mô hình hóa UML Việc áp dụng metamodeling trong thiết kế hệ thống giúp trừu tượng hóa các khái niệm từ nhiều miền ứng dụng khác nhau, đồng thời cung cấp khả năng khai thác siêu dữ liệu (metadata) cho các tác vụ thiết kế như phân tích và kiểm chứng.
Một trong những công nghệ metamodeling cơ bản theo tiêu chuẩn OMG là kiến trúc phân cấp 4 tầng truyền thống, dựa trên ý tưởng phân loại Các tầng trong kiến trúc này được xác định bởi các mối quan hệ "thể hiện của" giữa chúng Hình 2.1 dưới đây minh họa rõ ràng kiến trúc metamodeling.
4 tầng theo tiêu chuẩn OMG:
Hình 2.1: Kiến trúc metamodeling 4 tầng theo tiêu chuẩn OMG [4]
Các tầng trong kiến trúc metamodeling được mô tả như sau [4]:
Tầng M3 (Meta-metamodel) xác định các khái niệm, thuộc tính và mối quan hệ giữa các phần tử ở tầng M2, trong khi tầng M2 chứa các thể hiện của các phần tử ở tầng M3 OMG đã quy định một ngôn ngữ và tiêu chuẩn gọi là MOF (Meta-Object Facility) để mô tả tất cả các phần tử ở tầng M2.
Tầng M2 (Metamodel) xác định các phần tử hợp lệ trong mô hình cụ thể ở tầng M1 Các phần tử ở tầng M1 là các thể hiện của các phần tử ở tầng M2, ví dụ như UML.
Tầng M1 (Model) xác định các phân loại cho các phần tử ở tầng M0, trong đó các phần tử ở tầng M0 là các thể hiện của các phần tử ở tầng M1, ví dụ như biểu đồ lớp UML.
• Tầng M0: Các phần tử trong thế giới thực
Thuật ngữ metamodel (tầng M2) có nhiều cách định nghĩa khác nhau:
Mô hình khái niệm xác định các khái niệm, mối quan hệ và ngữ nghĩa, cho phép tạo ra các mô hình cụ thể Metamodel là công cụ quan trọng trong việc phát triển và tổ chức các mô hình này.
Bozidar Radenkovic An Integrated Approach to Supply Chain Simulation
• Một mô hình được sử dụng để mô tả cấu trúc và các thành phần của mô hình khác (Ritu Sharma, and Manu Sood Mitigating Technology Obsolescence in
Cloud Software Services: A Model-Driven Approach 2014.)
Hình 2.2 dưới đây thể hiện dạng tóm lược của siêu mô hình UML:
Hình 2.2: Dạng tóm lược của siêu mô hình UML [3]
2.1.2 Ngôn ngữ ràng buộc đối tượng OCL
Ngôn ngữ ràng buộc đối tượng OCL (Object Constraint Language) là một ngôn ngữ đặc tả hình thức, được sử dụng để định nghĩa các ràng buộc và truy vấn các mô hình UML OCL có ngữ nghĩa chính xác và là một phần quan trọng trong tiêu chuẩn UML.
OCL được phát triển nhằm khắc phục những hạn chế của ngôn ngữ mô hình hóa thống nhất UML, đặc biệt là trong việc chỉ định chính xác các khía cạnh chi tiết của thiết kế hệ thống OCL có thể được áp dụng cho nhiều mục đích khác nhau.
To validate models, OCL constraints can be employed to ensure the correctness of UML metamodels with the assistance of OCL tools For instance, a UML metamodel may have a constraint stating that all associations must have unique names This constraint can be translated into an OCL expression as follows: context Classifier inv singleIdentity: self.allConnections()->forAll(a1, a2 | a1.name.name implies a1).
• Đặc tả các quy tắc nghiệp vụ/các ràng buộc: Cho một biểu đồ lớp UML như
Hình 2.3: Một ví dụ về biểu đồ lớp UML [7]
In Figure 2.3, OCL can be utilized to specify the constraint between the attributes start and end of the Meeting class, expressed as: context Meeting inv: self.end > self.start.
Đánh giá các quy tắc nghiệp vụ và ràng buộc là rất quan trọng Ràng buộc giữa hai thuộc tính start và end trong lớp Meeting có thể được kiểm tra tự động bằng các công cụ OCL, như USE.
Mở rộng UML giúp bổ sung ngữ nghĩa chính xác cho các mô hình trực quan, vì nhiều chi tiết quan trọng trong thiết kế hệ thống không thể được định nghĩa chỉ bằng các ký hiệu của biểu đồ lớp UML Một số khía cạnh nghiệp vụ cũng không được hỗ trợ đầy đủ bởi biểu đồ lớp UML.
For instance, we can utilize OCL to describe the applicability of the shift method in the Meeting class by declaring additional precondition and postcondition constraints The precondition states that the meeting must not be confirmed and the shift value must be greater than zero The postcondition specifies that the start and end times of the meeting are adjusted by the specified shift value.
Ngôn ngữ ràng buộc đối tượng OCL được mô tả chi tiết trong tài liệu [8,11] Dưới đây là Bảng 2.1, trong đó liệt kê một số công cụ OCL cùng với các tính năng mà chúng hỗ trợ.
Bảng 2.1: Một số công cụ OCL và các tính năng chúng hỗ trợ [11]
Mô hình điều khiển truy cập dựa trên vai trò RBAC
Bài viết này cung cấp cái nhìn tổng quan về các mô hình tham chiếu RBAC, bao gồm mô hình RBAC cơ bản, mô hình RBAC phân cấp và mô hình RBAC ràng buộc Ngoài ra, nó cũng giới thiệu những tính năng nổi bật của một số ngôn ngữ đặc tả RBAC.
2.2.1 Tiêu chuẩn RBAC Điều khiển truy cập là khả năng cho phép hoặc hạn chế người dùng thực hiện thao tác nhất định trên tài nguyên Điều khiển truy cập bao gồm 3 bước cơ bản: Định danh, xác thực và uỷ quyền Có một số loại điều khiển truy cập như điều khiển truy cập tùy ý, điều khiển truy cập bắt buộc, điều khiển truy cập dựa trên luật và điều khiển truy cập dựa trên vai trò RBAC (Role Based Access Control ) Trong đó RBAC là một tiêu chuẩn được chấp nhận rộng rãi và đang dần thay thế cho điều khiển truy cập bắt buộc và điều khiển truy cập tùy ý truyền thống [1] Dưới đây là một số nguyên tắc cơ bản trong tiêu chuẩn RBAC:
• Quyết định cấp quyền truy cập tới một đối tượng cho một người dùng được dựa trên vai trò người dùng đó được gán
• Các vai trò được xác định dựa trên các chức năng công việc
• Các quyền hạn được xác định dựa trên trách nhiệm và thẩm quyền công việc trong một chức năng công việc
• Các thao tác trên một đối tượng được gọi tới dựa trên các quyền hạn
Tiêu chuẩn RBAC gồm 2 phần chính: Các mô hình tham chiếu RBAC và đặc tả yêu cầu [1]
Mô hình tham chiếu RBAC xác định các yếu tố cơ bản như người dùng, vai trò, quyền hạn, thao tác và đối tượng, cùng với các mối quan hệ giữa chúng.
• Đặc tả yêu cầu xác định các tính năng cần thiết cho một hệ thống RBAC
Các mô hình tham chiếu RBAC bao gồm bốn thành phần chính: RBAC cơ bản, RBAC phân cấp, mối quan hệ tách biệt nhiệm vụ tĩnh (SSD) và mối quan hệ tách biệt nhiệm vụ động (DSD).
2.2.2 Mô hình RBAC cơ bản
Mô hình RBAC cơ bản được thể hiện như Hình 2.4 dưới đây:
• USERS: Khái niệm về USERS ở đây cần được hiểu theo nghĩa rộng, nó có thể là máy tính, tác nhân hoặc một hệ thống khác
• ROLES: Một chức năng công việc trong một tổ chức kèm theo một định nghĩa rõ ràng về trách nhiệm và thẩm quyền của nó
• OPERATIONS: Một sự thực thi một chức năng xác định trong chương trình được gọi tới bởi một người dùng
• OBJECTS: Một thực thể chứa hoặc nhận thông tin hoặc các tài nguyên hệ thống
• User Assignment (UA): Một người dùng có thể được gán một hoặc nhiều vai trò, một vai trò có thể được gán cho một hoặc nhiều người dùng
• PERMISSIONS: Sự cấp quyền thực hiện một thao tác trên một tài nguyên được bảo vệ
• Permission Assignment (PA): Một permission có thể được gán cho một hoặc nhiều vai trò, một vai trò có thể được gán một hoặc nhiều permission
• SESSIONS: Mỗi phiên là một ánh xạ giữa một người dùng và một vai trò được gán tương ứng
Chúng ta sẽ sử dụng một website Tin Tức làm ví dụ, trong đó các bài viết là tài nguyên duy nhất Bảng 2.2 dưới đây minh họa các khái niệm cơ bản của RBAC (Quản lý quyền truy cập theo vai trò) trên website Tin Tức này.
Bảng 2.2: Một ví dụ về các khái niệm RBAC cơ bản của một website Tin Tức
User1 Visitor User1.article1.session Search article1 Read
User2 User User2.article2.session
User3 Writer User3.article3.session
User4 Administrator User4.article4.session
Publish Edit Delete Search Read Comment
Trong bảng trên, các người dùng User1, User2, User3 và User4 được phân loại theo các vai trò khác nhau: Visitor, User, Writer và Administrator thông qua mối quan hệ UA Đồng thời, các quyền truy cập tương ứng cũng được gán cho từng vai trò này thông qua mối quan hệ PA.
2.2.3 Mô hình RBAC phân cấp
Mô hình RBAC phân cấp được thể hiện như Hình 2.5 dưới đây:
Mô hình RBAC phân cấp giới thiệu khái niệm phân cấp vai trò Role Hierarchy (RH), cho phép xác định mối quan hệ kế thừa giữa các vai trò Trong mô hình này, vai trò cấp cao hơn sẽ nắm giữ tất cả các quyền hạn của vai trò cấp thấp hơn Có hai loại phân cấp vai trò RH, bao gồm General RH và Limited RH, trong đó General RH hỗ trợ đa kế thừa.
In the hierarchy of roles outlined in Table 2.2, there exists a mutual inheritance relationship, categorized as General RH The Administrator role stands at the top of this hierarchy, representing the highest level of authority, while the Visitor role occupies the lowest position, indicating the least level of access and privileges.
2.2.4 Mô hình RBAC ràng buộc
Mô hình RBAC (Role-Based Access Control) được mở rộng với mối quan hệ tách biệt nhiệm vụ (Separation of Duty - SoD), một nguyên tắc quan trọng trong an ninh, nhằm đảm bảo rằng các hoạt động phải được phân chia giữa hai hoặc nhiều người dùng để bảo vệ an toàn hệ thống SoD bao gồm hai loại: tách biệt nhiệm vụ tĩnh (Static Separation of Duty - SSD) và tách biệt nhiệm vụ động (Dynamic Separation of Duty - DSD), được áp dụng rộng rãi trong nhiều lĩnh vực để ngăn chặn rủi ro an ninh.
Các mối quan hệ SSD thiết lập ràng buộc trong việc gán vai trò cho người dùng, ngăn cản họ trở thành thành viên của các vai trò khác khi các luật SSD được áp dụng Hình 2.6 minh họa sự tích hợp của mối quan hệ SSD vào mô hình RBAC phân cấp.
Hình 2.6: SSD trong mô hình RBAC phân cấp [1]
Trong Bảng 2.2, người dùng User3 với vai trò Writer sẽ không thể có vai trò Administrator khi luật SSD được viết bằng OCL dưới đây được thực thi:
Bảng 2.3: Một ví dụ về ràng buộc SSD context User inv SSDforWA: let
Writer:Role=Role.allInstances->any(name='Writer'),
Administrator:Role=Role.allInstances->any(name='Administrator'),
CR:Set(Role)=Set{Writer, Administrator} in self.role_->intersection(CR)->size() < CR->size()
Các mối quan hệ DSD và SSD đều hạn chế khả năng cấp quyền cho người dùng, nhưng chúng khác nhau ở ngữ cảnh áp đặt các hạn chế này Các luật liên quan đến DSD tạo ra những điều kiện riêng biệt cho việc quản lý quyền truy cập.
DSD giới hạn quyền truy cập của người dùng bằng cách áp dụng các ràng buộc cho các vai trò trong phiên làm việc của họ Hình 2.7 minh họa mối quan hệ giữa DSD và mô hình RBAC phân cấp.
Hình 2.7: DSD trong mô hình RBAC phân cấp [1]
Các mối quan hệ DSD giúp người dùng nhận diện các vai trò xung đột Luật DSD ngăn chặn vi phạm bằng cách áp đặt ràng buộc lên các vai trò có thể kích hoạt trong mỗi phiên, từ đó hạn chế sự kết hợp quyền hạn mà người dùng có thể nhận.
Hiện nay, có nhiều ngôn ngữ đặc tả RBAC như LTL, UML/OCL, TOCL, và RCL 2000 Bảng 2.4 dưới đây trình bày các tính năng của một số ngôn ngữ này trong việc mô tả hệ thống kiểm soát truy cập dựa trên vai trò.
Bảng 2.4: Các tính năng của một số ngôn ngữ đặc tả RBAC [9]
RCL 2000 UML/OCL LTL TOCL
Các ràng buộc SSD Hỗ trợ Hỗ trợ Hỗ trợ Hỗ trợ
DSD đơn giản Hỗ trợ Hỗ trợ Hỗ trợ Hỗ trợ
Các ràng buộc SoD dựa trên lịch sử Không hỗ trợ Không hỗ trợ Hỗ trợ Hỗ trợ
Các ràng buộc trong luồng công việc có thể được phân loại thành hai nhóm: không hỗ trợ và hỗ trợ Trong khi một số điều kiện tiên quyết không được hỗ trợ, các vai trò và quyền truy cập lại được hỗ trợ đầy đủ Điều này cho thấy sự linh hoạt trong việc quản lý luồng công việc, giúp tối ưu hóa quy trình làm việc.
Các ràng buộc ngữ cảnh liên quan đến vị trí
Không hỗ trợ Hỗ trợ Hỗ trợ Hỗ trợ
Các ràng buộc ngữ cảnh liên quan đến thời gian Không hỗ trợ Hiện tại không hỗ trợ
Hiện tại không hỗ trợ
Hiện tại không hỗ trợ
Công cụ uỷ quyền Hiện tại không hỗ trợ Hỗ trợ Hiện tại không hỗ trợ
Hiện tại không hỗ trợ
Kiểm chứng / Thẩm định Không hỗ trợ Thẩm định với USE
Kiểm chứng hình thức với Isabelle
Hiện tại không hỗ trợ
Mô hình điều khiển truy cập dựa trên vai trò RBAC có một số lợi ích sau đây:
• Tính khả dụng cao, hầu hết các ứng dụng trong thực tiễn đều có thể sử dụng mô hình điều khiển truy cập dựa trên vai trò RBAC
• Đơn giản, hiệu quả trong việc quản lý cấp quyền truy cập cho người dùng, nhóm người dùng
• Mô hình RBAC phân cấp ngăn chặn sự gia tăng các vai trò, tăng khả năng tái sử dụng
Mô hình điều khiển truy cập dựa trên vai trò RBAC có một số hạn chế sau đây:
• Không phù hợp với các ứng dụng không xác định được các tài nguyên cần được bảo vệ
• Các chính sách RBAC thường trở nên phức tạp trong các tổ chức có quy mô lớn.
Mô hình quy trình nghiệp vụ
Trong phần này, luận văn trình bày tổng quan về quản lý quy trình nghiệp vụ BPM và tiêu chuẩn mô hình hoá quy trình nghiệp vụ BPMN 2.0
2.3.1 Quản lý quy trình nghiệp vụ
Quy trình nghiệp vụ là chuỗi hoạt động nhằm đạt được mục tiêu cụ thể của tổ chức Quản lý quy trình nghiệp vụ (BPM) là phương pháp hệ thống giúp tối ưu hóa luồng công việc, nâng cao hiệu quả và khả năng thích ứng với những thay đổi trong môi trường kinh doanh.
Quy trình nghiệp vụ bao gồm nhiều bước quan trọng như xử lý đơn hàng, thanh toán, đảm bảo chất lượng, quản lý rủi ro, lắp ráp sản phẩm và bàn giao sản phẩm Những quy trình này đóng vai trò thiết yếu trong việc tối ưu hóa hoạt động kinh doanh và nâng cao hiệu quả sản xuất.
Quy trình nghiệp vụ đóng vai trò quan trọng trong mọi tổ chức, và việc quản lý quy trình này cũng không kém phần quan trọng Dưới đây là một số định nghĩa khác về BPM (Quản lý Quy trình Kinh doanh).
BPM là tập các nguyên lý, phương pháp và công cụ để phân tích, thiết kế, thực thi và giám sát các quy trình nghiệp vụ (Marlon Dumas 2014)
BPM là phương pháp hệ thống nhằm nắm bắt, thiết kế, thực thi và giám sát các quy trình, cả tự động lẫn không tự động, để đạt được các mục tiêu chiến lược của doanh nghiệp và tổ chức.
Trong cuốn sách của mình, Scheer (2006) đã phân biệt hai loại BPM: BPM kinh doanh và BPM công nghệ Theo quan điểm của Scheer, BPM kinh doanh được coi như một triết lý quản lý trong doanh nghiệp, tập trung vào các khía cạnh như chi phí và hiệu quả hoạt động.
Hiệp hội Châu Âu về Quản lý Quy trình Kinh doanh (EABPM) tập trung vào việc cải thiện và tối ưu hóa quy trình kinh doanh nhằm giảm phí, thời gian, số lượng và tài nguyên Trong khi đó, BPM công nghệ hướng đến tự động hóa các quy trình nghiệp vụ một cách hiệu quả và linh hoạt Mục tiêu của tự động hóa trong BPM công nghệ là cung cấp ứng dụng phù hợp với quy trình nghiệp vụ đã được xác định, sử dụng các mô hình và mô tả quy trình để hướng dẫn thực hiện các hoạt động nghiệp vụ.
Hình 2.8 dưới đây thể hiện vòng đời quản lý quy trình nghiệp vụ:
Hình 2.8: Vòng đời quản lý quy trình nghiệp vụ [6]
Các pha trong vòng đời quản lý quy trình nghiệp vụ được mô tả như sau [6]:
Pha Design đóng vai trò quan trọng trong việc nhận diện và thiết kế quy trình nghiệp vụ, tập trung vào việc xác định các hoạt động, phân tích các thay đổi tiềm năng trong tổ chức, và định nghĩa các thỏa thuận mức dịch vụ Pha này cũng xác định các chi tiết của quy trình như các actor và thông báo, với mục tiêu chính là đảm bảo một thiết kế lý thuyết chính xác và hiệu quả được chuẩn bị.
Pha Modeling là giai đoạn quan trọng trong quy trình nghiệp vụ, nơi mô hình lý thuyết được thiết kế theo tiêu chuẩn BPMN Giai đoạn này yêu cầu sự thẩm định và quy định đầy đủ, với trách nhiệm chủ yếu thuộc về các nhà phân tích và tích hợp hệ thống.
Pha thực thi là giai đoạn mà thiết kế lý thuyết được chuyển đổi thành mô hình và được cài đặt trong ứng dụng để tự động hóa quy trình Trong giai đoạn này, các dịch vụ cần thiết được xác định nhằm tự động hóa quy trình nghiệp vụ Các ngôn ngữ chính được sử dụng để phát triển các dịch vụ này bao gồm WSBPEL và BPMN 2.0, và đây là trách nhiệm của các nhà phát triển quy trình nghiệp vụ.
Pha Giám sát là giai đoạn quan trọng trong việc theo dõi hiệu suất của từng quy trình riêng lẻ, giúp thu thập thông tin thống kê và duy trì trạng thái ổn định cho các quy trình Trong quá trình này, các vấn đề phát sinh trong quy trình nghiệp vụ sẽ được xác định, từ đó cần thực hiện các biện pháp khắc phục nhằm cải tiến hiệu quả hoạt động.
Trong pha tối ưu hóa, thông tin về hiệu suất quy trình được thu thập từ pha giám sát, cùng với các cải tiến và thay đổi yêu cầu nghiệp vụ Sau khi hoàn thành pha tối ưu hóa, vòng đời quản lý quy trình nghiệp vụ sẽ kết thúc.
Có nhiều tiêu chuẩn để mô hình hóa quy trình nghiệp vụ như EPC, biểu đồ hoạt động UML và Petri nets, nhưng chúng thường gặp hạn chế trong việc hỗ trợ tính năng của ngôn ngữ lập trình Việc thêm các chi tiết kỹ thuật vào quy trình nghiệp vụ trở nên khó khăn khi dựa vào những tiêu chuẩn này Để khắc phục vấn đề này, tiêu chuẩn BPMN (Ký hiệu và mô hình hóa quy trình nghiệp vụ) đã được phát triển, hỗ trợ thiết kế quy trình nghiệp vụ đồng thời tích hợp các tính năng của ngôn ngữ lập trình.
Hình 2.9 minh họa các thành phần chính trong biểu đồ quy trình nghiệp vụ, bao gồm Flow Object, Connecting Element, Swimlane và Artifact, được trình bày dưới dạng một siêu mô hình.
Hình 2.9: Metamodel của biểu đồ quy trình nghiệp vụ [2]
• Flow Object: Các phần tử đồ họa chính được sử dụng để xác định hành vi của một quy trình nghiệp vụ Nó bao gồm Events, Activities và Gateways
• Connecting Element: Có 3 cách để liên kết các Flow Object lại với nhau bao gồm Sequence Flow, Message Flow và Association
• Swimlane: Có 2 cách để nhóm các phần tử mô hình hóa thông qua làn bơi là
• Artifact: Được sử dụng để cung cấp thêm thông tin cho quy trình nghiệp vụ
Nó bao gồm Group, Text Annotation và Data Object
Các phần tử BPMN 2.0 được mô tả chi tiết trong [12].
Một số công cụ hỗ trợ
Activiti là một trong những khung công việc BPM hàng đầu, cung cấp nền tảng thiết kế và triển khai quy trình nghiệp vụ nhanh chóng Trong khi đó, USE là công cụ OCL duy nhất cho phép giám sát sự tương tác giữa các bất biến OCL và hỗ trợ thẩm định mô tả UML và OCL Phần này của luận văn sẽ trình bày tổng quan về hai phần mềm mã nguồn mở Activiti và USE.
Hình 2.10: Các mô đun của Activiti [6].
Activiti là phần mềm mã nguồn mở được phát triển bằng Java và phân phối theo giấy phép Apache V2, cung cấp giải pháp hiệu quả cho việc mô hình hóa, tự động hóa và tối ưu hóa quy trình nghiệp vụ Hình 2.10 minh họa các mô đun của Activiti.
• 3 thành phần Activiti Modeler, Activiti Designer và Activiti Kickstart là 3 thành phần trong pha mô hình hóa được sử dụng để thiết kế quy trình nghiệp vụ
Activiti Modeler là công cụ thiết kế quy trình nghiệp vụ trên nền tảng web, tích hợp trong ứng dụng Activiti Explorer Nó hỗ trợ đầy đủ các yếu tố mô hình hóa theo tiêu chuẩn BPMN.
Activiti Designer là công cụ thiết kế workflow trên nền tảng Eclipse của Activiti, cho phép người dùng thêm chi tiết kỹ thuật cho quy trình nghiệp vụ, điều này tạo ra sự khác biệt so với Activiti Modeler.
• Activiti Engine có thể được tích hợp với ứng dụng của ta, nó là một thành phần tại Runtime
• 2 thành phần Activiti Explorer và Activiti Rest là 2 thành phần trong pha quản lý được sử dụng để xử lý và thực thi quy trình nghiệp vụ
Môi trường đặc tả dựa trên UML (USE) là một hệ thống chuyên dụng nhằm đặc tả các hệ thống thông tin, hỗ trợ hiển thị các biểu đồ lớp, đối tượng, tuần tự và trạng thái UML USE tự động tạo ra các trạng thái hệ thống từ các tập tin soil và cho phép thẩm định các mô tả UML và OCL Mục tiêu chính của USE là kiểm tra các tiêu chí đánh giá chất lượng phần mềm, bao gồm tính đúng đắn của các mô tả UML ở mức thiết kế độc lập với cài đặt Đặc tả USE cung cấp mô tả văn bản cho mô hình thông qua các đặc trưng trong biểu đồ lớp UML, với các biểu thức được viết bằng ngôn ngữ ràng buộc đối tượng OCL để chỉ định các ràng buộc toàn vẹn cho mô hình.
Các trạng thái hệ thống, hay còn gọi là các snapshot của một hệ thống đang thực thi, có thể được tạo ra và tự động kiểm tra các ràng buộc OCL cho mỗi snapshot Thông tin về trạng thái hệ thống được trình bày thông qua các khung nhìn đồ họa Ngoài ra, các biểu thức OCL cũng có thể được bổ sung vào đặc tả USE để đánh giá trạng thái hệ thống.
Hình 2.11 dưới đây thể hiện khung nhìn chung về cách tiếp cận USE:
Hình 2.11: Khung nhìn chung về cách tiếp cận USE [5]
Ngôn ngữ đặc tả USE dựa trên UML và OCL đã được cải tiến từ phiên bản 3.0, khi ngôn ngữ dòng lệnh cũ được thay thế bằng ngôn ngữ lập trình SOIL SOIL là một ngôn ngữ lập trình mệnh lệnh đơn giản dựa trên OCL, mang lại sự linh hoạt và hiệu quả hơn trong việc mô tả các hệ thống Thông tin chi tiết về ngôn ngữ lập trình SOIL có thể được tìm thấy trong tài liệu [18].
Tổng kết chương
Chương này cung cấp cái nhìn tổng quan về các kiến thức nền tảng trong luận văn, bao gồm kiến trúc metamodeling, siêu mô hình metamodel, ngôn ngữ ràng buộc đối tượng OCL, tiêu chuẩn RBAC và quản lý quy trình nghiệp vụ Tiêu chuẩn RBAC được giải thích với các mô hình tham chiếu và hai khái niệm quan trọng là tách biệt nhiệm vụ tĩnh (SSD) và tách biệt nhiệm vụ động (DSD) Ngoài ra, chương cũng giới thiệu tiêu chuẩn Ký hiệu và mô hình hoá quy trình nghiệp vụ BPMN, cùng với công cụ hỗ trợ Activiti và cách tiếp cận USE.
TÍCH HỢP MÔ HÌNH RBAC VÀ MÔ HÌNH BPMN
Giới thiệu
Các quy trình nghiệp vụ có thể được phân tích và thiết kế ở nhiều mức độ trừu tượng khác nhau, với sự phân biệt giữa các mô hình dành cho phân tích, cải tiến nghiệp vụ và các mô hình cho tự động hoá Ở mức độ tự động hoá, trọng tâm là khả năng thực thi các quy trình nghiệp vụ, đòi hỏi cung cấp các đặc tả chi tiết về mô hình dữ liệu, chính sách phân bổ công việc và giao diện người dùng (Decker và các cộng sự, 2010).
Thiết kế mô hình quy trình nghiệp vụ khả thi là bước đầu tiên trong việc tự động hóa quy trình, sử dụng các ký hiệu BPMN như user tasks, mail tasks, sequence flows và gateways Sau khi xây dựng mô hình, luồng công việc sẽ được thực thi trên môi trường BPMN, tạo ra các thể hiện quy trình BPMN engine sẽ đánh giá điều kiện rẽ nhánh tại các gateway, gửi tin nhắn, email, gọi dịch vụ web và gán tác vụ cho người dùng hoặc nhóm cụ thể Tất cả hành động này diễn ra trên môi trường BPMN do khung công việc BPM cung cấp.
Trong chính sách truy cập của quy trình nghiệp vụ BPMN, các quy tắc nghiệp vụ đóng vai trò quan trọng trong việc kiểm soát và điều phối hoạt động Chúng đảm bảo rằng các quy trình này đáp ứng đầy đủ và chính xác các yêu cầu về nghiệp vụ và an ninh mà tổ chức đặt ra.
Quy trình nghiệp vụ BPMN được thực hiện trong môi trường thực thi do khung công việc BPM cung cấp Môi trường này chủ yếu hỗ trợ kiểm tra một số quy tắc nghiệp vụ nhất định, đặc biệt là các quy tắc liên quan đến các luồng sau các điểm quyết định trong mô hình BPMN Tuy nhiên, nó không đảm bảo kiểm tra tất cả các quy tắc nghiệp vụ trong chính sách truy cập Nếu có vấn đề phát sinh trong quy trình BPMN, chúng thường liên quan đến sai sót trong thiết kế hoặc đặc tả mô hình, chứ không phải vi phạm chính sách an ninh.
Theo cách tiếp cận mô hình, việc sử dụng ngôn ngữ ràng buộc đối tượng OCL và các biểu đồ UML để đặc tả chính sách truy cập là giải pháp phổ biến Mô hình an ninh RBAC hiện đang được áp dụng rộng rãi trong thiết kế và phân tích các chính sách truy cập Để đảm bảo tính nhất quán và độ chính xác của các chính sách truy cập RBAC, cần thiết phải có các cơ chế kiểm chứng và thẩm định.
Trong quá trình thực thi quy trình nghiệp vụ BPMN trên khung công việc BPM, một số quy tắc nghiệp vụ trong chính sách truy cập có thể không được kiểm tra, dẫn đến tính tuân thủ không đảm bảo cho các thể hiện khác nhau của quy trình Ngoài ra, thiết kế chính sách truy cập có thể gặp phải các vấn đề như thiếu quy tắc hoặc quy tắc xung đột do sai sót trong thiết kế, gây ra tính nhất quán của đặc tả chính sách không được đảm bảo.
Hiện tại, chưa có phương pháp nào hỗ trợ đầy đủ việc đặc tả, kiểm tra tính nhất quán và chứng thực tính tuân thủ của chính sách truy cập RBAC cho các thể hiện khác nhau của quy trình nghiệp vụ BPMN Các câu hỏi quan trọng đặt ra bao gồm: làm thế nào để kiểm tra tính nhất quán của đặc tả chính sách truy cập RBAC? Các thể hiện khác nhau của quy trình nghiệp vụ BPMN được xác định như thế nào? Và cách thức chứng thực tính tuân thủ của chính sách truy cập RBAC cho các thể hiện này là gì?
Chương này tập trung vào việc áp dụng mô hình để đặc tả và kiểm chứng chính sách truy cập RBAC trong quá trình thực hiện quy trình nghiệp vụ theo mô hình BPMN Các chi tiết về cách tiếp cận này sẽ được trình bày trong các phần tiếp theo.
Tổng quan về phương pháp
Luận văn đề xuất một phương pháp tiếp cận mô hình nhằm đặc tả và kiểm chứng chính sách truy cập RBAC trong quá trình thực hiện quy trình nghiệp vụ theo mô hình BPMN, như được minh họa trong Hình 3.1.
Hình 3.1: Tổng quan về phương pháp
Luận văn xây dựng một khung công việc theo cách tiếp cận mô hình nhằm đặc tả và kiểm chứng chính sách truy cập RBAC Khung công việc này hỗ trợ nhà phát triển trong việc đặc tả, thực thi quy trình nghiệp vụ và thiết kế chính sách truy cập RBAC dựa trên tài liệu yêu cầu nghiệp vụ với các mô tả về quy trình và yêu cầu an ninh Đầu ra của khung là kết quả kiểm tra tính nhất quán của chính sách RBAC và việc kiểm chứng tính tuân thủ của nó cho các thể hiện khác nhau của quy trình nghiệp vụ Khung công việc này bao gồm ba phần chính.
Nhà phát triển có thể mô hình hoá quy trình nghiệp vụ từ tài liệu yêu cầu nghiệp vụ bằng cách sử dụng mô đun đặc tả để tạo ra một mô hình BPMN Mô hình BPMN này chứa tất cả các mô tả về quy trình nghiệp vụ và sẽ được sử dụng làm đầu vào cho việc triển khai quy trình nghiệp vụ thông qua một mô đun giám sát thực thi Các thể hiện khác nhau của quy trình BPMN đang được thực thi sẽ được lưu trữ trong một cơ sở dữ liệu quan hệ.
Trong phần 2 (tác vụ 3-4-5), một metamodel dựa trên UML sẽ được xây dựng để biểu diễn mô hình an ninh RBAC, tập trung vào chính sách và mức người dùng truy cập Đầu ra của tác vụ 3 là một đặc tả chứa mô tả UML dạng văn bản của metamodel RBAC Tiếp theo, các yêu cầu an ninh nghiệp vụ được diễn đạt bằng ngôn ngữ tự nhiên sẽ được chuyển đổi thành quy tắc nghiệp vụ thông qua các ngôn ngữ đặc tả RBAC trong tác vụ 4 Đặc tả metamodel RBAC và quy tắc nghiệp vụ từ tác vụ 3 và 4 sẽ là đầu vào cho việc thiết kế chính sách truy cập RBAC ở tác vụ 5 Trong quá trình thiết kế này, có thể phát hiện các quy tắc nghiệp vụ xung đột hoặc thiếu sót thông qua các công cụ thẩm định chính sách, dẫn đến việc cần phải thiết kế lại chính sách truy cập RBAC.
Phần 3 (tác vụ 6-7-8) bắt đầu với đầu vào từ các thể hiện quy trình nghiệp vụ BPMN và đặc tả chính sách truy cập RBAC Tác vụ 6 tạo ra các scripts điều khiển trạng thái của quy trình BPMN dựa trên cấu trúc chính sách RBAC, xác định các trạng thái này từ cơ sở dữ liệu quan hệ Đầu ra của tác vụ 6 là các snapshot khác nhau của quy trình BPMN, được sử dụng làm ca kiểm thử để kiểm tra tính nhất quán của chính sách RBAC (tác vụ 7) và xác minh tính tuân thủ chính sách RBAC cho các thể hiện quy trình BPMN (tác vụ 8) với sự hỗ trợ của các công cụ chuyên dụng.
Nội dung các bước thực hiện trong phương pháp sẽ được trình bày chi tiết trong các phần tiếp theo của chương này.
Đặc tả và thực thi quy trình nghiệp vụ
Trong phần này, luận văn trình bày cách thức mô hình hoá, đặc tả và triển khai quy trình nghiệp vụ theo mô hình BPMN
3.3.1 Mô hình hoá quy trình nghiệp vụ
Nhà phát triển có thể mô hình hóa quy trình nghiệp vụ dựa trên tài liệu yêu cầu nghiệp vụ và sử dụng mô đun đặc tả để biểu diễn quy trình này theo tiêu chuẩn BPMN.
Mô đun đặc tả này thuộc về một khung công việc BPM, với đầu ra là mô hình BPMN mô tả quy trình nghiệp vụ Đối với các nhà phát triển, việc mô hình hóa quy trình nghiệp vụ cần dựa trên khung công việc BPM Luận văn chọn BPM Activiti, một trong những khung công việc BPM hàng đầu, cung cấp chuẩn thực thi cho quy trình nghiệp vụ và là nền tảng thiết kế, triển khai quy trình một cách nhanh chóng.
Mô hình quy trình nghiệp vụ BPMN có thể được thiết kế trên Activiti Modeler hoặc Activiti Designer, hai mô đun hỗ trợ các phần tử mô hình hoá theo tiêu chuẩn BPMN 2.0 Trong khi Activiti Modeler tập trung vào việc mô hình hóa quy trình, Activiti Designer cho phép thêm các chi tiết kỹ thuật vào quy trình nghiệp vụ, tạo nên sự khác biệt giữa hai công cụ này Activiti Designer được cài đặt trên Eclipse, như được minh họa trong Hình 3.2.
Để cài đặt Activiti Designer, người dùng nên sử dụng gói Eclipse Kepler hoặc Eclipse Indigo cho phiên bản Activiti 5.x, trong khi gói Eclipse Helios không được hỗ trợ.
The BPMN modeling interface of Activiti Designer on Eclipse consists of the Editor, Palette, and Properties Users can drag and drop elements from the Palette to define components such as StartEvent, SequenceFlow, UserTask, MailTask, Gateway, and EndEvent in the BPMN model Additionally, the General, Main config, and Form properties for each BPMN element can be initialized in the Properties section A detailed explanation of BPMN process modeling using Activiti Designer will be provided in Chapter 4.
3.3.2 Triển khai quy trình nghiệp vụ
Mô hình BPMN được phát triển sẽ được sử dụng làm đầu vào cho việc triển khai quy trình nghiệp vụ thông qua một mô-đun giám sát thực thi trong khung công việc BPM Mục tiêu là tạo ra các thể hiện đa dạng của quy trình nghiệp vụ BPMN, và những thể hiện này sẽ được lưu trữ trong một cơ sở dữ liệu quan hệ.
Mô hình BPMN có thể được triển khai trên ứng dụng web Activiti Explorer để định nghĩa quy trình nghiệp vụ Các thể hiện của quy trình BPMN sẽ được lưu trữ trong cơ sở dữ liệu MySQL, được cấu hình trong tập tin db.properties tại đường dẫn Apache Tomcat 9.0.22\webapps\activiti-explorer\WEB-INF\classes\db.properties.
Bảng 3.1: Cấu hình cơ sở dữ liệu quan hệ activiti dbtiviti jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/activiti jdbc.username=root jdbc.password=Thanhcong2019
Việc triển khai quy trình nghiệp vụ BPMN trên Activiti Explorer sẽ được trình bày chi tiết trong Chương 4.
Đặc tả chính sách RBAC
Bài viết này trình bày quy trình xây dựng một metamodel dựa trên UML nhằm biểu diễn mô hình an ninh RBAC, cùng với việc đặc tả các quy tắc nghiệp vụ thông qua ngôn ngữ đặc tả RBAC và thiết kế một chính sách truy cập RBAC toàn diện.
Mô hình điều khiển truy cập dựa trên vai trò (RBAC) sẽ được phát triển thành một metamodel, bao gồm chính sách và mức độ truy cập của người dùng, dựa trên biểu đồ lớp UML và các ràng buộc ủy quyền Kết quả của quá trình này là một đặc tả cho metamodel RBAC.
Mức chính sách trong mô hình RBAC bao gồm các lớp như Role, Permission, Operation, Resource và các liên kết giữa chúng Người dùng cần được gán ít nhất một vai trò, và các vai trò này phải có các permission cụ thể để thực hiện hành động trên tài nguyên Phân cấp vai trò và ràng buộc uỷ quyền là các khái niệm nâng cao trong RBAC, trong đó một vai trò có thể bao gồm nhiều vai trò cấp thấp hơn, và vai trò cấp cao hơn sẽ có tất cả các permission của vai trò cấp thấp hơn Ràng buộc uỷ quyền là yếu tố quan trọng giúp phát hiện lỗi và giảm thiểu vi phạm an ninh trong tổ chức.
Mức độ truy cập của người dùng bao gồm các lớp Access, Session, User, Snapshot cùng với các liên kết association giữa chúng, được sử dụng để phân tích chính sách Hình 3.3 dưới đây minh họa một metamodel RBAC điển hình được xây dựng ở mức chính sách và mức độ truy cập của người dùng.
Hình 3.3: Một RBAC metamodel điển hình [10]
Trong Hình 3.3, các thuộc tính và liên kết association có thể được gán ràng buộc Bảng 3.2 dưới đây trình bày một số ràng buộc dưới dạng bất biến OCL cho siêu mô hình RBAC, thể hiện sự độc lập với các ứng dụng cụ thể.
Table 3.2 outlines several OCL invariants for the RBAC metamodel The invariant for roles states that if the maximum number of members is defined, then the size of the users associated with that role must not exceed this maximum For users, the invariant specifies that if the maximum number of roles is defined, then the size of the roles assigned to that user must be less than or equal to this maximum Lastly, the permission invariant indicates that if the maximum number of sessions is defined, the number of sessions associated with a role must not exceed this maximum.
Metamodel RBAC được phát triển nhằm hỗ trợ thiết kế các chính sách truy cập hiệu quả Nó cần bao gồm cả các khái niệm cơ bản và nâng cao của RBAC đã được đề cập Hơn nữa, metamodel RBAC cần được xây dựng với khả năng mở rộng để đáp ứng nhu cầu thay đổi trong tương lai.
Trong luận văn này, mức chính sách của metamodel RBAC tập trung vào các khía cạnh chính sách tĩnh, tức là xem xét một chính sách RBAC cụ thể, trong khi mức người dùng truy cập lại chú trọng vào khía cạnh truy cập tài nguyên với một kịch bản RBAC cụ thể Đầu ra của tác vụ này là một đặc tả USE, bao gồm các mô tả UML dạng văn bản của metamodel RBAC Đặc tả USE được định nghĩa là một mô tả dạng văn bản của một mô hình, sử dụng các đặc trưng của biểu đồ lớp UML như các lớp và các liên kết association Các biểu thức trong đặc tả USE được viết bằng ngôn ngữ ràng buộc đối tượng OCL.
3.4.2 Biểu diễn các quy tắc nghiệp vụ
Trong chính sách an ninh của quy trình nghiệp vụ, các quy tắc nghiệp vụ là yếu tố then chốt để kiểm soát và điều phối hoạt động, đảm bảo quy trình đáp ứng đầy đủ và chính xác các yêu cầu về nghiệp vụ và an ninh của tổ chức Những quy tắc này có thể được diễn đạt qua nhiều hình thức khác nhau như ngôn ngữ tự nhiên, văn bản, đồ họa hoặc toán học.
Trong kiến trúc metamodeling 4 tầng, ngôn ngữ OCL được sử dụng để đặc tả quy tắc nghiệp vụ tại tầng M1 (tầng Model) Đầu tiên, các yêu cầu an ninh nghiệp vụ sẽ được chuyển đổi thành quy tắc nghiệp vụ bằng ngôn ngữ tự nhiên Tiếp theo, những quy tắc này sẽ được chuyển thành các ràng buộc uỷ quyền dưới dạng bất biến OCL Kết quả cuối cùng là một đặc tả quy tắc nghiệp vụ bao gồm một tập hợp các bất biến OCL.
Chẳng hạn, trong siêu thị Big C có một số quy tắc nghiệp vụ được biểu diễn dưới dạng các bất biến OCL như Bảng 3.3 dưới đây:
Bảng 3.3: Một số ví dụ biểu diễn các quy tắc nghiệp vụ dưới dạng các bất biến OCL
Diễn đạt bằng ngôn ngữ tự nhiên Biểu diễn dưới dạng các bất biến OCL
Không người nào trong siêu thị được làm cả hai công việc
Nhân viên Thu ngân context User inv SSDforCS: let Cashier:Role=Role.allInstances->any(id='Cashier'), và Nhân viên Giám sát tính tiền quầy thu ngân cho khách hàng
Cashier’sSupervisor:Role=Role.allInstances->any(id='Cashier’sSupervisor'), CR:Set(Role)=Set{Cashier, Cashier’sSupervisor} in self.role_->intersection(CR)->size() < CR->size()
Không nhân viên nào trong siêu thị dưới 18 tuổi context Employee inv MinimumOfAge: self.age.isDefined implies self.age >= 18
3.4.3 Thiết kế chính sách truy cập RBAC Đặc tả RBAC metamodel và đặc tả các quy tắc nghiệp vụ được tạo ra ở trên sẽ là đầu vào để thiết kế chính sách truy cập RBAC Định nghĩa về chính sách truy cập RBAC được phát biểu như sau: Đị nh ngh ĩ a 3.2: Một chính sách truy cập RBAC là mô hình RBAC phân cấp bổ sung thêm các ràng buộc uỷ quyền [9]
Việc phân tách metamodel RBAC và bổ sung các ràng buộc ủy quyền sẽ tạo ra các chính sách truy cập RBAC cụ thể Trong quá trình thiết kế chính sách này, có thể phát hiện các quy tắc nghiệp vụ xung đột hoặc thiếu sót thông qua các công cụ thẩm định chính sách, dẫn đến việc phải thiết kế lại chính sách truy cập RBAC Định nghĩa một cấu hình cho chính sách truy cập RBAC bao gồm các vai trò, quyền hạn, người dùng và phiên người dùng cụ thể, cùng với hệ thống phân cấp vai trò hiện tại Đồng thời, một snapshot hay trạng thái hệ thống được định nghĩa là chứa các đối tượng và liên kết hiện tại, thể hiện qua biểu đồ đối tượng UML, và phải có một biểu đồ lớp UML tương ứng Một snapshot được coi là khác rỗng nếu nó chứa ít nhất một đối tượng.
Trong luận văn này, công cụ USE được sử dụng để thẩm định chính sách truy cập RBAC Cách tiếp cận bao gồm việc tạo ra các cấu hình cho chính sách RBAC dựa trên đặc tả của nó, thông qua việc chạy các script điều khiển trạng thái do hệ thống USE sinh ra, hiển thị dưới dạng các biểu đồ UML hay snapshot Các ràng buộc ủy quyền được biểu diễn bằng bất biến OCL sẽ được kiểm tra tự động để xác định xem các snapshot có thoả mãn hay không Nếu snapshot không mong muốn nhưng thoả mãn tất cả các ràng buộc, điều này cho thấy chính sách RBAC thiếu ràng buộc Ngược lại, nếu snapshot hợp lý nhưng không thoả mãn một hoặc nhiều ràng buộc, điều này chỉ ra rằng chính sách RBAC có các ràng buộc xung đột Hình 3.4 minh hoạ cách tiếp cận này.
Hình 3.4: Tổng quan về cách tiếp cận thẩm định chính sách RBAC trên USE
Bảng 3.4 dưới đây minh hoạ một ví dụ về hai ràng buộc xung đột nhau:
Bảng 3.4: Một ví dụ về hai ràng buộc xung đột nhau context User inv PrerequisiteRoleDS: self.role_->includes('Director') implies self.role_->includes('Staff') inv SSDforDS: let
Director:Role=Role.allInstances->any(id='Director'),
Staff:Role=Role.allInstances->any(id='Staff'),
Đầu ra của tác vụ này là một đặc tả hoàn chỉnh của chính sách truy cập RBAC cho quy trình nghiệp vụ BPMN dưới dạng đặc tả USE, bao gồm hai phần Phần đầu tiên chứa các mô tả UML dạng văn bản được tách biệt từ đặc tả RBAC metamodel, trong khi phần thứ hai chứa các quy tắc nghiệp vụ được biểu diễn dưới dạng các bất biến OCL.
Kiểm chứng trên môi trường đặc tả OCL
Trong phần này, bài viết giới thiệu phương pháp tạo các script thể hiện các trạng thái khác nhau của quy trình nghiệp vụ BPMN đang thực thi Bên cạnh đó, nó cũng trình bày cách kiểm tra tính nhất quán của đặc tả chính sách RBAC và cách xác minh tính tuân thủ của chính sách RBAC đối với các thể hiện khác nhau của quy trình nghiệp vụ BPMN.
3.5.1 Tạo các script Đầu vào cho tác vụ này là các thể hiện khác nhau của quy trình BPMN đang được thực thi và đặc tả chính sách RBAC Các thể hiện khác nhau của quy trình BPMN đang thực thi được lưu trữ trong một cơ sở dữ liệu quan hệ (mục 3.3.2) Mục tiêu của tác vụ này là tạo ra các script chứa các tập lệnh điều khiển các trạng thái khác nhau của quy trình BPMN đang được thực thi dựa trên việc tích hợp mô hình RBAC và mô hình BPMN với nhau Đây chính là ý tưởng cơ bản trong cách tiếp cận để thực hiện tác vụ này
Trong luận văn này, các script sẽ được lưu trữ trong các tập tin soil, được tạo ra từ các chương trình Java viết tay trong Eclipse Chương trình Java sẽ ghi lại các lệnh điều khiển trạng thái của quy trình BPMN vào các tập tin soil, dựa trên trạng thái hiện tại của cơ sở dữ liệu quan hệ Activiti Các lệnh này tuân theo cú pháp của ngôn ngữ lập trình mệnh lệnh đơn giản OCL SOIL và dựa trên cấu trúc của đặc tả siêu mô hình RBAC Điều này tạo nền tảng cho việc tích hợp mô hình BPMN với mô hình RBAC.
SOIL là một ngôn ngữ lập trình đơn giản nhưng hoàn chỉnh, được sử dụng để chỉ định hoạt động cho các mô hình UML và viết chương trình cho chúng Ngôn ngữ này phát triển dựa trên việc nhúng OCL vào một ngôn ngữ lập trình mệnh lệnh, nhằm tái sử dụng các công cụ và thư viện có sẵn Kể từ phiên bản 3.0, ngôn ngữ dòng lệnh cũ của USE đã được thay thế bởi SOIL, với mô tả chi tiết về ngôn ngữ này có trong tài liệu tham khảo [18].
Hình 3.5 dưới đây minh hoạ cách tiếp cận được sử dụng trong tác vụ này để tạo các script:
Hình 3.5 trình bày tổng quan về phương pháp tạo các script, với đầu ra là các script điều khiển các trạng thái khác nhau trong quy trình BPMN đang thực thi Các biểu đồ đối tượng UML (snapshot) trên USE được tạo tự động thông qua việc chạy các script này.
3.5.2 Kiểm tra tính nhất quán của chính sách RBAC
Công việc kiểm chứng trong luận văn bao gồm hai tác vụ chính: đầu tiên là kiểm tra tính nhất quán của chính sách truy cập RBAC trong quy trình nghiệp vụ BPMN, và thứ hai là xác minh tính tuân thủ của chính sách này đối với các thể hiện khác nhau của quy trình BPMN đang được thực thi Định nghĩa về tính nhất quán của một chính sách truy cập RBAC được nêu rõ: một chính sách được coi là nhất quán nếu tồn tại một chuỗi các cấu hình không rỗng thỏa mãn tất cả các quy tắc trong chính sách.
Cách tiếp cận trong tác vụ này là tạo ra một snapshot chứa các trạng thái khác nhau của quy trình nghiệp vụ BPMN đang thực thi, với các cấu hình khác rỗng của chính sách truy cập RBAC cần kiểm tra tính nhất quán Snapshot này được tạo ra từ một script, có thể phát triển dựa trên phương pháp trình bày trong mục 3.5.1, và được sử dụng để kiểm tra tính nhất quán của chính sách truy cập RBAC với sự hỗ trợ của công cụ chuyên dụng.
Theo định nghĩa 3.4, snapshot được thể hiện dưới dạng biểu đồ đối tượng UML trên USE, trong đó các đối tượng đại diện cho các lớp và các liên kết thể hiện các association trong biểu đồ lớp UML tương ứng Biểu đồ lớp UML này là mô hình tĩnh của RBAC, bao gồm các lớp RBAC và các association giữa chúng Đầu vào để tạo ra biểu đồ lớp UML trên USE là đặc tả USE của RBAC metamodel.
Trong luận văn, một snapshot sẽ được tạo ra từ các trạng thái khác nhau của quy trình nghiệp vụ BPMN thông qua việc chạy script trong tập tin soil Snapshot này sẽ được hiển thị dưới dạng biểu đồ UML trên công cụ USE, bao gồm các đối tượng cụ thể, giá trị thuộc tính và các liên kết giữa chúng Công cụ USE sẽ tự động kiểm tra các bất biến OCL trong chính sách truy cập RBAC để xác định xem snapshot có đáp ứng các yêu cầu này hay không Nếu snapshot thỏa mãn tất cả các bất biến OCL, điều này cho thấy chính sách truy cập RBAC được thiết kế có tính nhất quán.
3.5.3 Kiểm chứng tính tuân thủ chính sách RBAC
Chúng tôi tạo ra các snapshot chứa các thể hiện khác nhau của quy trình nghiệp vụ BPMN bằng cách chạy các script trong các tập tin soil, tương tự như cách kiểm tra tính nhất quán của chính sách truy cập RBAC Mỗi snapshot này được sử dụng như một ca kiểm thử để xác minh tính tuân thủ chính sách RBAC cho từng thể hiện của quy trình BPMN đang được thực thi Các bất biến OCL trong đặc tả chính sách RBAC sẽ được tự động kiểm tra để xác định xem các snapshot này có đáp ứng yêu cầu hay không, với sự hỗ trợ của công cụ USE.
Nếu tất cả các snapshot được tạo ra đều thỏa mãn các bất biến OCL trong đặc tả chính sách RBAC, thì quy trình nghiệp vụ BPMN đang thực thi sẽ được coi là hợp lệ và tuân thủ chính sách truy cập Ngược lại, nếu có một hoặc nhiều snapshot không thỏa mãn các bất biến OCL, quy trình nghiệp vụ BPMN sẽ không hợp lệ, và chúng ta có thể xác định các thể hiện vi phạm quy tắc nghiệp vụ nào.
Tổng kết chương
Chương này cung cấp cái nhìn tổng quan về phương pháp mô hình luận để mô tả và kiểm chứng chính sách truy cập RBAC cho các biểu diễn khác nhau của quy trình nghiệp vụ BPMN Khung công việc bao gồm ba phần chính: (1) Mô tả và thực thi quy trình nghiệp vụ; (2) Mô tả chính sách RBAC; và (3) Kiểm chứng trong môi trường OCL Các phần của phương pháp này được trình bày chi tiết trong chương.
Quy trình nghiệp vụ được thực thi trên khung công việc BPM theo mô hình BPMN, với chính sách truy cập RBAC được xây dựng dựa trên một metamodel sử dụng ngôn ngữ UML và OCL Việc phân tách metamodel RBAC và bổ sung các ràng buộc ủy quyền dưới dạng bất biến OCL giúp tạo ra các chính sách RBAC cụ thể Hai tác vụ chính trong việc kiểm chứng chính sách truy cập RBAC là kiểm tra tính nhất quán và tính tuân thủ của chính sách cho các thể hiện quy trình BPMN Ý tưởng chính là tạo ra các snapshot chứa các trạng thái khác nhau của quy trình BPMN đang thực thi, được sinh ra từ các script điều khiển trạng thái dựa trên cơ sở dữ liệu quan hệ và cấu trúc của siêu mô hình RBAC Các script này tuân theo cú pháp của ngôn ngữ lập trình SOIL, và công cụ hỗ trợ được phát triển từ sự tích hợp giữa Activiti và USE.