1. Trang chủ
  2. » Luận Văn - Báo Cáo

Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình

68 12 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Sinh Tự Động Chế Tác Phần Mềm Từ Mô Hình Quy Trình Nghiệp Vụ Dựa Vào Chuyển Đổi Mô Hình
Tác giả Trần Thu Trang
Người hướng dẫn TS. Đặng Đức Hạnh
Trường học Đại học Quốc gia Hà Nội
Chuyên ngành Công nghệ thông tin
Thể loại luận văn thạc sĩ
Năm xuất bản 2022
Thành phố Hà Nội
Định dạng
Số trang 68
Dung lượng 4,48 MB

Cấu trúc

  • CHƯƠNG 1. TỔNG QUAN (12)
    • 1.1. Đặt vấn đề (12)
    • 1.2. Mục tiêu và phương pháp (15)
    • 1.3. Bố cục của luận văn (15)
  • CHƯƠNG 2. KIẾN THỨC NỀN TẢNG (16)
    • 2.1. Kỹ nghệ hướng mô hình (16)
      • 2.1.1. Mô hình hóa (Modeling) (16)
      • 2.1.2. Chuyển đổi mô hình (18)
    • 2.2. Mô hình quy trình nghiệp vụ (21)
      • 2.2.1. Mô hình hóa quy trình nghiệp vụ (22)
      • 2.2.2. Tiêu chuẩn ký hiệu và mô hình hóa quy trình nghiệp vụ BPMN (23)
    • 2.3. Mô hình ca sử dụng (25)
      • 2.3.1. Ngôn ngữ mô hình thống nhất (25)
      • 2.3.2. Biểu đồ ca sử dụng (26)
  • CHƯƠNG 3. PHƯƠNG PHÁP SINH TỰ ĐỘNG CA SỬ DỤNG TỪ MÔ HÌNH (28)
    • 3.1. Giới thiệu (28)
    • 3.2. Tổng quan về phương pháp BPMN2UseCase (0)
    • 3.3. Biểu diễn mô hình BPMN (31)
    • 3.4. Biểu diễn mô hình ca sử dụng (32)
    • 3.5. Xác định các luật chuyển đổi mô hình (34)
      • 3.5.1. Luật chuyển đổi cho các đối tượng (Rules for Elements) (0)
      • 3.5.2. Luật chuyển đổi cho các quan hệ giữa các đối tượng (Rules for Association) (0)
      • 3.5.3. Luật chuyển đổi cho các quan hệ với dữ liệu (Rules for Data association) . 32 3.6. Thuật toán và thực thi chuyển đổi mô hình (39)
    • 3.7. Tổng kết chương (44)
  • CHƯƠNG 4. THỰC NGHIỆM VÀ ĐÁNH GIÁ (45)
    • 4.1. Công cụ, ngôn ngữ và môi trường hỗ trợ (45)
      • 4.1.1. Kỹ thuật biểu diễn quy trình nghiệp vụ (45)
      • 4.1.2. Kỹ thuật biểu diễn biểu đồ ca sử dụng (46)
    • 4.2. Nghiên cứu tình huống thực nghiệm (46)
      • 4.2.1. School Library System (46)
      • 4.2.2. Phương pháp đánh giá kết quả (50)
      • 4.2.3. Tổng kết thực nghiệm và đánh giá (54)
    • 4.3. Tổng kết chương (55)
  • CHƯƠNG 5. KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN (56)
    • 5.1. Kết quả đạt được (56)
    • 5.2. Hướng phát triển (57)
  • TÀI LIỆU THAM KHẢO (58)
  • PHỤ LỤC (61)

Nội dung

TỔNG QUAN

Đặt vấn đề

Trong phát triển phần mềm, kỹ thuật yêu cầu (Requirement Engineering - RE) đóng vai trò vô cùng quan trọng, ảnh hưởng đến toàn bộ quá trình nếu không được thực hiện chính xác RE được coi là chìa khóa cho sự thành công của các dự án phần mềm Tuy nhiên, trong các hệ thống lớn và phức tạp, việc xác định chính xác các yêu cầu phần mềm gặp nhiều khó khăn Nghiên cứu cho thấy rằng 70% lỗi hệ thống xuất phát từ việc đặc tả không đầy đủ, trong khi 30% còn lại liên quan đến các vấn đề thiết kế Các nguyên nhân dẫn đến những vấn đề này có thể được phân loại thành nhiều nhóm chính.

Vấn đề về phạm vi trong thiết kế hệ thống thường xuất phát từ ranh giới không rõ ràng, điều này có thể dẫn đến việc thông tin không quan trọng được đưa vào trong khi các thông tin cần thiết lại bị thiếu trong đặc tả yêu cầu.

Vấn đề nhận thức và hiểu rõ hệ thống thường phát sinh khi người phân tích hoặc phát triển không xác định đúng nhu cầu của người yêu cầu, hoặc khi người yêu cầu cùng các bên liên quan không thể hiện rõ nhu cầu của mình Thêm vào đó, sự thiếu trao đổi và hiểu sai trong giao tiếp giữa bên yêu cầu và bên phân tích/phát triển cũng dẫn đến việc hình thành các yêu cầu không đầy đủ, chính xác, hoặc mơ hồ và không nhất quán.

Đáp ứng sự thay đổi là một thách thức quan trọng, khi các yêu cầu cần được cập nhật liên tục để phù hợp với nhu cầu và mục đích của bên yêu cầu, cũng như sự phát triển không ngừng của công nghệ phần mềm Sự chậm trễ trong việc thích ứng hoặc giải quyết không thỏa đáng các xung đột có thể dẫn đến nhiều vấn đề nghiêm trọng.

Nhiều nghiên cứu đã chỉ ra rằng việc nâng cao hiệu quả trong pha yêu cầu và khắc phục lỗi là cần thiết để tạo ra các chế tác phần mềm chính xác và hiệu quả Hướng tiếp cận mô hình quy trình nghiệp vụ được xem là giải pháp phù hợp, vì hơn một nửa sự phát triển phần mềm công nghiệp liên quan đến phát triển ứng dụng kinh doanh Hiểu rõ quy trình hoạt động là chìa khóa để xác định và phân tích các yêu cầu hệ thống cần thiết Thực tế cho thấy nhiều tổ chức đã có sẵn các mô hình quy trình nghiệp vụ chi tiết, cung cấp nền tảng cho việc mô hình hóa yêu cầu phần mềm Ví dụ, một nghiên cứu tại một ngân hàng quốc tế cho thấy 350 trong tổng số 1000 quy trình kinh doanh đã được mô tả rõ ràng và sử dụng trong hoạt động hàng ngày Mô hình quy trình nghiệp vụ cũng giúp thể hiện hoạt động của tổ chức một cách rõ ràng qua các biểu đồ đồ họa, giảm thiểu lỗi phát sinh.

Mô hình quy trình nghiệp vụ giúp giải quyết vấn đề nhận thức và hiểu rõ hệ thống, đồng thời xác định rõ phạm vi khi xây dựng đặc tả yêu cầu Bằng cách thể hiện cách thức tổ chức thực hiện và sắp xếp công việc, mô hình này cũng quy định rõ cấu trúc và mục đích của hệ thống.

Theo nghiên cứu, ca sử dụng và quy trình nghiệp vụ có nhiều điểm tương đồng Ca sử dụng UML mô tả chuỗi hành động mà hệ thống thực hiện để tạo ra giá trị cho tác nhân, trong khi quy trình kinh doanh là tập hợp các hoạt động được thiết kế để tạo ra đầu ra cho khách hàng hoặc thị trường Cả hai đều tập trung vào các hành động có cấu trúc nhằm đạt kết quả cụ thể Ngoài ra, quy trình nghiệp vụ có thể được mô tả bằng mô hình ca sử dụng, cho thấy việc chuyển đổi giữa chúng là khả thi và hợp lý Việc này không chỉ tiết kiệm thời gian và công sức, mà còn đảm bảo phản ánh đúng nhu cầu nghiệp vụ của hệ thống, vì quy trình kinh doanh thường đã có sẵn dưới dạng hướng dẫn hoặc sổ tay.

Hiện nay, nhiều nghiên cứu đã đề xuất ba phương pháp chính để giải quyết vấn đề chuyển đổi giữa BPM và UC Phương pháp đầu tiên là chuyển đổi thủ công, trong khi phương pháp thứ hai tập trung vào việc xây dựng thuật toán để tự động chuyển đổi mô hình UC từ BPM Cuối cùng, phương pháp thứ ba áp dụng MDE để thực hiện chuyển đổi tự động mô hình UC từ BPM.

Cruz và các đồng tác giả đã phát triển một bộ luật để chuyển đổi giữa mô hình quy trình nghiệp vụ (BPM) và mô hình ca sử dụng (UC), tập trung vào việc tạo ra các đặc tả chi tiết thông qua ngôn ngữ tự nhiên Quá trình này sử dụng năm luật chuyển đổi cho các thành phần như Participant, Lane, Activity và các mối quan hệ giữa chúng trong mô hình BPMN Kết quả là biểu đồ ca sử dụng được tạo ra khá đơn giản, chỉ bao gồm các yếu tố cơ bản như Actor, Use Case và mối quan hệ giữa chúng, mà không đề cập đến các quan hệ phức tạp hơn như mở rộng hay bao gồm.

 Chuyển đổi tự động mô hình UC từ BPM bằng cách xây dựng thuật toán chuyển đổi

Nghiên cứu [13, 14] giới thiệu một thuật toán chuyển đổi mô hình quy trình nghiệp vụ thành đặc tả yêu cầu chức năng, đặc biệt là biểu đồ ca sử dụng Thuật toán này hoạt động bằng cách tạo ra siêu mô hình cho quy trình nghiệp vụ và yêu cầu chức năng ca sử dụng, sau đó so sánh các khái niệm và ý nghĩa của chúng để xác định ánh xạ tương quan giữa các mô hình Chi tiết về việc xây dựng khái niệm tương quan này được trình bày trong [14] (Hình 1.1).

Hình 1.1 Ánh xạ các khái niệm UC từ quy trình nghiệp vụ [14]

Trong quá trình thực nghiệm, phương pháp đã đánh giá 6 quy trình nghiệp vụ và tạo ra 42 ca sử dụng Tuy nhiên, trong số đó, có 17 ca sử dụng với cấu trúc chưa chính xác, cho thấy một tỷ lệ lỗi tương đối cao.

 Chuyển đổi tự động mô hình UC từ BPM bằng cách áp dụng MDE

Trong nghiên cứu [21], một giải pháp tự động hóa đã được phát triển để chuyển đổi từ mô hình độc lập tính toán (CIM) sang mô hình độc lập nền tảng (PIM) Giải pháp này sử dụng biểu đồ cộng tác và biểu đồ quy trình BPMN để thể hiện mô hình nghiệp vụ tiêu chuẩn ở mức CIM, từ đó tạo ra biểu đồ ca sử dụng quy định chức năng của hệ thống và cuối cùng là biểu đồ lớp mô hình hóa các lớp và mối quan hệ giữa chúng Việc chuyển đổi được thực hiện thông qua công cụ dựa trên ngôn ngữ QVT theo kiến trúc hướng mô hình (MDA) Một nghiên cứu khác [6] cũng theo hướng MDE đã đề xuất công cụ BPMN2UC, sử dụng ngôn ngữ ATL để sinh ra biểu đồ ca sử dụng từ các khái niệm BPMN, đồng thời cho phép tạo ra đặc tả cho các ca sử dụng phức tạp thông qua Acceleo.

Mặc dù các phương pháp tiếp cận hiện tại mang lại hiệu quả nhất định, nhưng vẫn tồn tại nhiều nhược điểm Đầu tiên, hầu hết các giải pháp được thực hiện thủ công, dẫn đến độ chính xác thấp và phát sinh chi phí nhân lực cao Thứ hai, khả năng bao trùm các loại phần tử và khái niệm còn hạn chế, khiến cho đầu ra chưa đầy đủ và nghèo thông tin Cuối cùng, quá trình chuyển đổi phức tạp và sự dư thừa trong xử lý cũng là những vấn đề cần được cải thiện.

Mục tiêu và phương pháp

Mục đích của luận văn là phát triển phương pháp sinh tự động mô hình ca từ mô hình quy trình nghiệp vụ, nhằm nâng cao hiệu quả trong pha yêu cầu phần mềm và tăng cường tự động hóa trong phát triển phần mềm Giải pháp được đề xuất cần đơn giản, dễ áp dụng và phản ánh chính xác các hoạt động nghiệp vụ của hệ thống Để đạt được mục tiêu này, luận văn đưa ra một phương thức tiếp cận cụ thể.

Nghiên cứu siêu mô hình quy trình nghiệp vụ và các ca sử dụng giúp phân tích, so sánh và đánh giá mối tương quan giữa các yếu tố trong mô hình.

Từ đó, xây dựng một bộ quy tắc chuyển đổi mô hình

Chương trình chuyển đổi mô hình BPMN2UseCase được phát triển nhằm tự động hóa quá trình sinh ca sử dụng từ mô hình nghiệp vụ đầu vào, dựa trên bộ luật đã được nêu.

Sau khi áp dụng chương trình vào tình huống cụ thể và bộ test-cases, việc thử nghiệm và đánh giá là rất quan trọng Chương trình sẽ được xem xét dựa trên ba tiêu chí chính: tính ổn định, tính đầy đủ và tính đúng đắn.

Bố cục của luận văn

Chương 1: Giới thiệu, trình bày vấn đề nghiên cứu, mục tiêu và phương pháp đề xuất

Chương 2: Kiến thức nền tảng, trình bày cơ sở lý thuyết về kỹ nghệ hướng mô hình, mô hình quy trình nghiệp vụ và mô hình ca sử dụng

Chương 3: Tìm hiểu về bài toán chuyển đổi mô hình quy trình nghiệp vụ sang ca sử dụng và các công trình nghiên cứu liên quan Từ đó đề xuất phương pháp BPMN2UseCase sinh tự động mô hình ca sử dụng từ mô hình quy trình nghiệp vụ

Chương 4: Cách cài đặt chương trình, ứng dụng thực nghiệm giải pháp vào các tình huống cụ thể Xây dựng bộ test-cases để kiểm tra đánh giá phương pháp

Chương 5: Kết quả đạt được và hướng phát triển trong tương lai.

KIẾN THỨC NỀN TẢNG

Kỹ nghệ hướng mô hình

Mô hình đóng vai trò quan trọng trong nghiên cứu và phát triển phần mềm phức tạp, với Kỹ nghệ hướng mô hình (MDE) là một phương pháp hứa hẹn sử dụng mô hình để hỗ trợ các giai đoạn trong vòng đời phát triển phần mềm MDE dựa trên các nguyên tắc về mô hình, siêu mô hình, siêu-siêu mô hình và chuyển đổi mô hình, tạo ra quy trình phát triển tự động cho hệ thống Trong MDE, mô hình là biểu diễn trừu tượng của hệ thống, được xác định bởi ngôn ngữ mô hình hóa, cho phép thể hiện hệ thống một cách đơn giản và chính xác qua các biểu đồ, ký hiệu và chữ cái Ba khái niệm mô hình, siêu mô hình và siêu-siêu mô hình tạo thành một mẫu mô hình ba cấp, trong đó mô hình ở cấp cao hơn thể hiện mức độ trừu tượng cao hơn.

Hình 2.1 Mẫu mô hình hóa trong MDE [8]

Mô hình là một biểu hiện trừu tượng của một đối tượng hoặc hệ thống thực, thường được thể hiện dưới dạng hình ảnh hoặc biểu diễn, nhằm phản ánh và diễn tả các đặc điểm của hệ thống đó.

 Ở một mức trừu tượng hóa nhất định

 Theo một quan điểm hay một góc nhìn nào đó

 Bởi một hình thức diễn tả có thể hiểu được (đồ thị, bảng, văn bản,…)

Mô hình hóa là quá trình thay thế các đối tượng thực trong hệ thống bằng các mô hình, nhằm nghiên cứu và hiểu rõ hoạt động của hệ thống Thông qua việc thiết lập và sử dụng mô hình, ta có thể thu thập thông tin quan trọng cần thiết cho hệ thống bằng cách thực hiện các thí nghiệm trên mô hình Các mục đích chính của quá trình mô hình hóa bao gồm việc cải thiện hiểu biết về hệ thống và hỗ trợ ra quyết định hiệu quả hơn.

Hiểu biết là quá trình tạo ra hình ảnh rõ ràng và đơn giản về một hệ thống cần nghiên cứu Việc sử dụng mô hình giúp nhận diện và giải quyết các vấn đề một cách nhanh chóng và hiệu quả hơn.

 Để trao đổi: Mô hình có thể coi như một loại ngôn ngữ để trao đổi giữa những người quan tâm đến hệ thống.

Mô hình minh bạch và rõ ràng giúp người dùng đánh giá tính đầy đủ, chặt chẽ và sự phù hợp của hệ thống với yêu cầu Điều này tạo điều kiện để cải thiện và hoàn thiện hệ thống một cách hiệu quả hơn.

Ngôn ngữ mô hình hóa (Modeling language)

Ngôn ngữ mô hình hóa là một ngôn ngữ nhân tạo dùng để diễn tả thông tin hoặc hệ thống theo một cấu trúc nhất định, dựa trên các quy tắc cụ thể để giải thích ý nghĩa của các thành phần Các ngôn ngữ này có thể được phân loại thành bốn loại chính: mô hình hóa hệ thống, mô hình hóa đối tượng, mô hình hóa dữ liệu và mô hình hóa thực tế ảo Ngoài ra, ngôn ngữ mô hình hóa có thể được thể hiện dưới dạng đồ họa hoặc văn bản, tùy thuộc vào ngữ cảnh và yêu cầu sử dụng.

Ngôn ngữ mô hình hóa đồ họa là kỹ thuật sử dụng biểu diễn sơ đồ với các ký hiệu có tên để thể hiện các khái niệm và mối quan hệ giữa chúng Các ký hiệu đồ họa này cũng được dùng để diễn đạt các ràng buộc trong hệ thống Một số ví dụ tiêu biểu bao gồm Business Process Modeling Notation (BPMN) cho mô hình hóa quy trình, EXPRESS cho mô hình hóa dữ liệu, và Unified Modeling Language (UML) cho mô hình hóa các hệ thống phần mềm chuyên sâu.

13 kỹ thuật biểu đồ khác nhau…

Ngôn ngữ mô hình hóa văn bản sử dụng các từ khóa chuẩn hóa kết hợp với tham số và thuật ngữ để tạo ra các biểu thức mà máy tính có thể hiểu.

Để lưu trữ mô hình, công nghệ phổ biến là tiêu chuẩn eXtensible Markup Language Metadata Interchange (XMI), được phát triển và duy trì bởi Tổ chức Quản lý Đối tượng (OMG) Mục tiêu của XMI là tạo điều kiện thuận lợi cho việc trao đổi dữ liệu đặc tả giữa các công cụ mô hình hóa dựa trên UML và kho lưu trữ dữ liệu đặc tả dựa trên MOF (Meta Object Facility) XMI được sử dụng rộng rãi trong định dạng trao đổi XML và định nghĩa các vấn đề liên quan đến việc mô tả các đối tượng trong XML.

 Biểu diễn các đối tượng dưới dạng các phần tử và các thuộc tính XML.

 Các cơ chế chuẩn cho các đối tượng trong cùng một tập tin hay trên nhiều tập tin.

Xác định đối tượng là quá trình cho phép các đối tượng tham chiếu lẫn nhau thông qua các định danh (ID) hoặc định danh toàn thể duy nhất (UUID).

XMI cung cấp một phương thức chuẩn cho việc trao đổi thông tin về dữ liệu đặc tả giữa các lập trình viên Nó hỗ trợ người dùng sử dụng UML cùng với các ngôn ngữ và công cụ phát triển khác để chia sẻ các mô hình dữ liệu Đặc biệt, XMI tiêu chuẩn hóa cách mô tả tập dữ liệu đặc tả, yêu cầu người dùng thống nhất cách mô tả dữ liệu trên nhiều lĩnh vực và môi trường hoạt động khác nhau.

Trong kỹ nghệ mô hình hóa MDE, chuyển đổi mô hình là quá trình tự động biến đổi một mô hình nguồn thành mô hình đích cùng hệ thống dựa trên định nghĩa chuyển đổi Định nghĩa này bao gồm các quy tắc để mô tả cách chuyển đổi cấu trúc của mô hình nguồn sang cấu trúc của mô hình đích Hình 2.2 minh họa các khái niệm cơ bản của chương trình chuyển đổi mô hình, trong đó đầu vào là mô hình nguồn tạo nên siêu mô hình nguồn và đầu ra là mô hình đích tạo thành siêu mô hình đích Chương trình chuyển đổi sử dụng một bộ quy tắc và một ngôn ngữ chuyển đổi để thực hiện quá trình này.

Hình 2.2 Chuyển đổi mô hình [25]

Các hướng chuyển đổi mô hình

Cách tiếp cận chuyển đổi mô hình được chia thành hai hướng chính: mô hình-thành-mô hình (M2M) và mô hình-thành-văn bản (M2T) Sự khác biệt cơ bản giữa hai phương pháp này là M2M tạo ra một mô hình đích với cú pháp trừu tượng, trong khi M2T sản sinh kết quả dưới dạng chuỗi ký tự, văn bản, hoặc mã nguồn cụ thể Theo nghiên cứu, chuyển đổi M2T được phân thành hai loại: “visitor-based” và “template-based”, trong khi M2M bao gồm năm loại chính.

Thao tác trực tiếp (direct-manipulation) cung cấp một mô hình nội bộ cùng với các API để người dùng có thể tương tác Thông thường, phương pháp này được triển khai dưới dạng khung hướng đối tượng, yêu cầu người dùng xây dựng các quy tắc chuyển đổi, lập kế hoạch và theo dõi thông qua một ngôn ngữ lập trình.

Quan hệ (relational) là một phương pháp giải quyết các ràng buộc, trong đó ý tưởng cốt lõi là xác định mối quan hệ giữa các phần tử nguồn và đích thông qua các ràng buộc không thể thực thi.

Mô hình quy trình nghiệp vụ

Quy trình nghiệp vụ là chuỗi các công việc diễn ra trong một tổ chức hoặc doanh nghiệp, phản ánh các thành phần quan trọng của hoạt động kinh doanh.

Quy trình nghiệp vụ cũng cho thấy các bước từ đầu đến cuối của quy trình để đảm bảo đáp ứng các mục tiêu của tổ chức đề ra

Quản lý quy trình nghiệp vụ (BPM) là một lĩnh vực quan trọng trong quản lý doanh nghiệp, tập trung vào việc tối ưu hóa các quy trình nghiệp vụ để cải thiện dịch vụ và nâng cao chất lượng phục vụ khách hàng BPM mang đến cho doanh nghiệp một phương pháp mới để ứng dụng công nghệ thông tin, đã nhanh chóng phát triển trong hơn một thập kỷ qua với nhiều phương pháp, công cụ và kinh nghiệm triển khai thành công Với những ưu điểm nổi bật về tính đơn giản và dễ dàng triển khai, BPM đã được áp dụng hiệu quả và trở nên phổ biến trong nhiều tổ chức doanh nghiệp trên toàn thế giới.

2.2.1 Mô hình hóa quy trình nghiệp vụ

Trong quá trình khảo sát hệ thống, cách tiếp cận nghiệp vụ là phương pháp hệ thống nhất để nắm bắt yêu cầu ứng dụng Mô hình hóa quy trình nghiệp vụ giúp hiểu rõ quy trình của tổ chức và xác định các quy trình được hỗ trợ bởi hệ thống Sự phức tạp của phần mềm yêu cầu áp dụng kỹ thuật mô hình hóa và phương pháp mô hình hóa trực quan một cách hiệu quả Tiêu chuẩn ngôn ngữ mô hình hóa chặt chẽ là yếu tố quan trọng cho sự thành công của dự án Mục tiêu chính của mô hình hóa nghiệp vụ là xây dựng mô hình tổ chức thực tế, từ đó thiết kế chương trình máy tính dựa trên hiện tượng thế giới thực như con người và các tác vụ Việc thực hiện mô hình hóa quy trình nghiệp vụ mang lại nhiều lợi ích cho tổ chức và doanh nghiệp.

- Hiểu được cấu trúc và các hoạt động của tổ chức được triển khai hệ thống.

- Hiểu được các vấn đề hiện tại trong tổ chức và xác định các vấn đề cần cải tiến

- Bảo đảm các khách hàng, người dùng cuối và các nhà phát triển có sự hiểu biết chung về tổ chức.

- Thiết lập các yêu cầu hệ thống nhằm hỗ trợ tổ chức.

Mô hình hóa nghiệp vụ có ảnh hưởng linh hoạt tùy thuộc vào nhu cầu và hệ thống cụ thể của từng tổ chức Mục tiêu có thể là nâng cao năng suất qua cải tiến quy trình hiện tại hoặc thực hiện những thay đổi lớn dựa trên phân tích kỹ lưỡng các mục tiêu và khách hàng Để đạt được điều này, luồng công việc mô hình hóa nghiệp vụ cung cấp cái nhìn tổng quan về tổ chức, xác định các quy trình, vai trò và trách nhiệm trong mô hình ca sử dụng và mô hình đối tượng nghiệp vụ.

2.2.2 Tiêu chuẩn ký hiệu và mô hình hóa quy trình nghiệp vụ BPMN

Trong quá trình tin học hóa quy trình nghiệp vụ, các tác nhân như người thực hiện nghiệp vụ, nhà phân tích, người phát triển kỹ thuật và quản lý thường gặp khó khăn trong việc hiểu ý tưởng của nhau Điều này còn xảy ra giữa các nhà phân tích nghiệp vụ của các tổ chức khác nhau, dẫn đến việc giao tiếp không hiệu quả trong việc liên thông quy trình Để khắc phục vấn đề này, cần thiết phải có các ký hiệu tiêu chuẩn để biểu diễn các phần tử nghiệp vụ như sự kiện, hoạt động, luồng dữ liệu và đơn vị tổ chức Một bộ ký hiệu đồ họa mô hình hóa quy trình nghiệp vụ sẽ xác định các biểu tượng cho các phần tử này, cùng với ý nghĩa và khả năng kết hợp của chúng.

Tiêu chuẩn ký hiệu và mô hình hóa quy trình nghiệp vụ (BPMN) được phát triển nhằm kết nối thông tin giữa các bên liên quan, giúp giải quyết các vấn đề trong thiết kế và triển khai quy trình nghiệp vụ BPMN hiện đang được áp dụng rộng rãi trong nhiều tổ chức, hỗ trợ cả người dùng kỹ thuật lẫn người dùng nghiệp vụ trong việc quản lý quy trình thông qua một tập hợp các ký hiệu chung, trực quan và dễ hiểu.

2.2.2.1 Lịch sử phát triển của BPMN

BPMN, hay Ngôn ngữ mô hình hóa quy trình nghiệp vụ, được phát triển bởi Tổ chức Sáng kiến quản lý quy trình nghiệp vụ (BPMI), bao gồm các công ty phần mềm Mục tiêu ban đầu của BPMN là cung cấp một bộ ký hiệu đồ họa để mô tả quy trình trong Ngôn ngữ mô hình hóa quy trình nghiệp vụ (BPML), nhằm xác định các mô tả quy trình có thể được thực thi bởi hệ thống quản lý quy trình nghiệp vụ (BPMS).

Phiên bản đầu tiên của BPMN, được phát triển bởi nhóm của Stephen A White tại IBM vào năm 2004, đã dẫn đến sự hình thành BPMI như một nhóm thuộc Tổ chức quản lý đối tượng (OMG) OMG, nổi tiếng với các tiêu chuẩn phần mềm như UML, đã chính thức chấp nhận BPMN phiên bản 1.0 là một tiêu chuẩn vào năm 2006.

OMG đã công bố phiên bản BPMN v1.1 vào tháng 01/2008 và BPMN v1.2 vào tháng 01/2009 với một số thay đổi nhỏ Phiên bản BPMN v2.0, với nhiều cải tiến và mở rộng, được phát hành vào tháng 01/2011 Phiên bản mới nhất, BPMN v2.0.2, được công bố vào tháng 12/2013, chủ yếu sửa lỗi nhỏ trong văn bản so với BPMN v2.0 Đặc biệt, vào năm 2013, BPMN đã chính thức trở thành tiêu chuẩn quốc tế ISO/IEC 19510:2013.

2.2.2.2 Các phần tử (element) của BPMN

 Flow Objects: là tập hợp của các phần tử chính, được gọi là các đối tượng luồng.

Sự kiện trong kinh doanh được biểu thị bằng hình tròn, đại diện cho những điều "diễn ra" trong quá trình hoạt động Những sự kiện này không chỉ ảnh hưởng đến dòng chảy của quy trình mà còn thường có nguyên nhân (kích hoạt) hoặc tác động (kết quả) rõ ràng.

Có ba loại Event, dựa trên thời điểm chúng ảnh hưởng đến luồng: Start, Intermediate và End (thứ tự tương ứng với các hình bên phải).

Activity được thể hiện dưới dạng hình chữ nhật bo góc, là thuật ngữ chung chỉ các hoạt động mà công ty tiến hành Các loại Activity bao gồm nhiều hình thức khác nhau.

Gateway, được biểu thị dưới dạng hình thoi, đóng vai trò quan trọng trong việc kiểm soát sự phân kỳ và hội tụ của chuỗi hoạt động Tại điểm này, các hoạt động sẽ được kết hợp hoặc phân nhánh thành các luồng xử lý trong quy trình.

Các Flow Objects được kết nối trong một biểu đồ để hình thành cấu trúc cơ bản của quy trình nghiệp vụ Có ba loại Connecting Objects cung cấp chức năng này.

Flow được biểu thị bằng một đường mũi tên liền nét, thể hiện thứ tự thực hiện các hoạt động trong quy trình.

Flow được biểu thị bằng một đường mũi tên đứt nét, nhằm mục đích minh họa luồng tin nhắn giữa các bên tham gia trong quá trình, bao gồm các thực thể kinh doanh hoặc vai trò kinh doanh khác nhau.

Mô hình ca sử dụng

2.3.1 Ngôn ngữ mô hình thống nhất

UML, viết tắt của Unified Modeling Language, là ngôn ngữ mô hình hóa hình ảnh tiêu chuẩn dùng để mô hình hóa nghiệp vụ và quy trình, cũng như phân tích, thiết kế và triển khai các hệ thống phần mềm Được phát triển bởi Tổ chức Quản lý Đối tượng (OMG), phiên bản UML 1.0 đã được đề xuất và thông qua vào năm 1997.

Khác với các ngôn ngữ lập trình như C++, Java hay COBOL, UML là một ngôn ngữ hình ảnh chuyên dụng cho việc thiết kế phần mềm Nó được xem là một ngôn ngữ mô hình trực quan với mục đích chung để trực quan hóa, xây dựng và lập tài liệu cho hệ thống phần mềm Mặc dù UML chủ yếu được sử dụng để mô hình hóa các hệ thống phần mềm, nó cũng có thể áp dụng cho việc mô hình hóa các hệ thống không phải phần mềm, chẳng hạn như quy trình trong một đơn vị sản xuất.

UML, được ví như "một bức tranh có giá trị bằng một nghìn từ", nhằm phát triển một ngôn ngữ mô hình hóa chung, dễ hiểu và dễ sử dụng cho tất cả các nhà lập mô hình Biểu đồ UML không chỉ phục vụ cho các nhà phát triển mà còn hữu ích cho người dùng doanh nghiệp và bất kỳ ai muốn hiểu hệ thống Tóm lại, UML hướng đến việc cung cấp một cơ chế mô hình hóa đơn giản để mô hình hóa tất cả các hệ thống thực tế trong môi trường phức tạp hiện nay.

UML, hay Ngôn ngữ Mô hình Hướng Đối Tượng, là công cụ quan trọng trong thiết kế và phân tích hệ thống Nó sử dụng các phần tử và mối liên kết giữa chúng để tạo ra các biểu đồ trực quan Các biểu đồ trong UML có thể được phân loại thành nhiều loại khác nhau, phục vụ cho các mục đích khác nhau trong quá trình phát triển phần mềm.

Biểu đồ cấu trúc là công cụ quan trọng để chụp lại các khía cạnh tĩnh của hệ thống và các bộ phận của nó ở nhiều mức độ trừu tượng khác nhau, đồng thời thể hiện mối quan hệ giữa chúng Các yếu tố trong biểu đồ này đại diện cho các khái niệm có ý nghĩa trong hệ thống Các loại biểu đồ cấu trúc bao gồm biểu đồ thành phần, biểu đồ đối tượng, biểu đồ lớp và biểu đồ triển khai.

Biểu đồ hành vi là công cụ quan trọng để ghi lại các khía cạnh động hoặc hành vi của hệ thống và các đối tượng trong đó, phản ánh chuỗi thay đổi của hệ thống theo thời gian Các loại biểu đồ hành vi bao gồm biểu đồ ca sử dụng, biểu đồ trạng thái, biểu đồ hoạt động và biểu đồ tương tác, giúp người dùng hiểu rõ hơn về cách thức hoạt động của hệ thống.

2.3.2 Biểu đồ ca sử dụng

Biểu đồ ca sử dụng cung cấp cái nhìn tổng quan về hệ thống, mô hình hóa các chuỗi hành động và xác định sự tương tác giữa người dùng và hệ thống một cách rõ ràng và dễ hiểu.

Bảng 2.5 Các khái niệm trong ca sử dụng

Khái niệm Ký hiệu Ý nghĩa

Actor Người dùng hệ thống hay một hệ thống khác

Diễn viên có thể thực hiện ba chức năng chính liên quan đến hệ thống: cung cấp thông tin cho hệ thống, lấy thông tin từ hệ thống, và nhận thông tin từ hệ thống để tiếp tục cung cấp cho hệ thống.

Use Case Một khối chức năng được thực hiện bởi hệ thống để mang lại một kết quả có giá trị đối với một Actor cụ thể.

Relationship Quan hệ giữa các phần tử trong mô hình, bao gồm kết hợp (association), tổng quát hóa (generalization)

Include Một Use Case có thể có chức năng của 1

Extend Dùng để chỉ các hành vi không bắt buộc (có thể có hoặc không), các hành vi theo điều kiện nhất định

PHƯƠNG PHÁP SINH TỰ ĐỘNG CA SỬ DỤNG TỪ MÔ HÌNH

Giới thiệu

Trong quá trình phát triển hệ thống, chuyển đổi từ mô hình quy trình nghiệp vụ sang mô hình ca sử dụng mang lại nhiều lợi ích thiết thực Phương pháp này hỗ trợ phát triển phần mềm, đặc biệt trong việc xác định chức năng phần mềm, bằng cách tận dụng các mô hình nghiệp vụ hiện có Điều này giúp giảm thiểu bước thừa, tiết kiệm thời gian, nguồn lực và chi phí Mô hình đầu ra rõ ràng và trực quan giúp các bên liên quan nhanh chóng nắm bắt được hệ thống, bao gồm phạm vi, các tác nhân và tình huống sử dụng với các tương tác giữa tác nhân và hệ thống.

Bài toán chuyển đổi quy trình nghiệp vụ gặp nhiều khó khăn và thách thức do sự khác biệt giữa các mô hình quy trình và ca sử dụng, mặc dù có những tương đồng về khái niệm tổng quát Việc phân tích kỹ lưỡng từng phần tử là cần thiết để xác định sự tương quan và xây dựng các quy tắc chuyển đổi Ngoài ra, nếu quy trình nghiệp vụ chưa được chuẩn hóa hoặc không tuân thủ các tiêu chuẩn mô hình ký hiệu phù hợp, sẽ gây khó khăn trong việc đánh giá và trích xuất các phần tử từ mô hình đầu vào Một ví dụ minh họa cho quy trình nghiệp vụ thực tế là giải Nobel, như được thể hiện trong Hình 3.1.

Mô hình quy trình nghiệp vụ Nobel Prize là một mô hình thông tin phong phú, bao gồm hầu hết các loại phần tử và siêu khái niệm phổ biến trong quy trình nghiệp vụ Tuy nhiên, mô hình này gặp khó khăn trong việc phân tích và xác định các luật chuyển đổi, dẫn đến việc mô hình ca sử dụng đầu ra còn sơ sài, thiếu đầy đủ và thông tin cần thiết.

Hình 3.2 Mô hình ca sử dụng Nobel Prize [9]

Luận văn đề xuất phương pháp sinh tự động biểu đồ ca từ mô hình quy trình nghiệp vụ thông qua chuyển đổi mô hình Giải pháp dựa trên nguyên lý sử dụng siêu mô hình metamodels cho cả đầu vào và đầu ra, từ đó xây dựng các luật chuyển đổi dựa trên sự tương quan giữa các khái niệm Nội dung mô hình được lưu trữ và trao đổi qua định dạng XMI, một tiêu chuẩn phổ biến trong việc quản lý dữ liệu đặc tả Nhờ đó, việc biểu diễn biểu đồ các mô hình trở nên thuận lợi hơn với sự hỗ trợ của các công cụ mô hình hóa UML hiện nay.

3.2 Tổng quan về phương pháp BPMN2UseCase Để thực hiện sinh tự động biểu đồ ca sử dụng từ mô hình quy trình nghiệp vụ, luận văn đã phát triển chương trình BPMN2UseCase sử dụng ngôn ngữ chuyển đổi mô hình ATL và nền tảng mô hình hóa Eclipse (EMF) Hình 3.3 thể hiện quy trình thực hiện của phương pháp, bao gồm 3 bước riêng biệt: biểu diễn mô hình BPMN đầu vào, chuyển đổi BPMN2UseCase dựa trên tập luật định sẵn và biểu diễn mô hình UseCase đầu ra

Hình 3.3 Quy trình chuyển đổi mô hình đề xuất

Hình 3.4 mô tả tổng quan cách thức hoạt động của chương trình được cài đặt, tương ứng với ba bước thực hiện quy trình trên

Hình 3.4 Cơ chế chuyển đổi mô hình BPMN2UseCase

Một lợi thế quan trọng của phương pháp này là dựa trên ký hiệu mô hình tiêu chuẩn, giúp dễ dàng tích hợp vào các nền tảng và công cụ hiện có Trong chương trình, mô hình quy trình nghiệp vụ được thiết kế và sử dụng thông qua công cụ Eclipse.

BPMN2 Modeler và tạo ra file đầu vào chuẩn định dạng bpmn như ví dụ Hình 3.5

Sau khi hoàn tất quá trình chuyển đổi với ATL, chương trình sẽ tạo ra file đầu ra chuẩn XMI với định dạng uml Khi file này được nhập vào công cụ Eclipse Papyrus, biểu đồ ca sử dụng sẽ được hiển thị một cách trực quan và dễ dàng tiếp cận hơn.

Hình 3.5 Định dạng đầu vào *.bpmn

Hình 3.6 Định dạng đầu ra *.uml

3.3 Biểu diễn mô hình BPMN

Nhiều kỹ thuật và công cụ đã được phát triển để mô hình hóa quy trình nghiệp vụ, chủ yếu tập trung vào các khía cạnh như cấu trúc tổ chức và đối tượng dữ liệu, trong khi biểu đồ ca sử dụng lại chỉ tập trung vào hành vi Điều này dẫn đến sự thiếu tương quan giữa các mô hình và khó khăn trong việc tạo ra chuyển đổi phù hợp Luận văn này lựa chọn BPMN cho mô hình khái niệm quy trình nghiệp vụ, với các định nghĩa về hành vi là Flow Objects và các mối quan hệ kết nối giữa chúng là Sequence Flow, Message Flow và Association Hình 3.7 minh họa metamodel BPMN đơn giản.

Hình 3.7 Siêu mô hình lược giản BPMN [8]

Quy trình nghiệp vụ đơn giản của một webshop trong việc xử lý đơn hàng online được minh họa qua bốn bước chính: Nhận Đơn Hàng, Kiểm Tra Tín Dụng, Thực Hiện Đơn Hàng và Gửi Hóa Đơn Hệ thống web đóng vai trò là đối tượng thực hiện, tương ứng với siêu khái niệm BPMNPool Mỗi bước được thể hiện bằng các siêu khái niệm BPMNTask, trong khi sự kiện bắt đầu và kết thúc của quy trình được đại diện bởi BPMNStart và BPMNEnd trong siêu khái niệm BPMNEvent Ví dụ này giúp người đọc hình dung rõ hơn về quy trình nghiệp vụ thực tế và cách các siêu khái niệm được thể hiện trong siêu mô hình BPMN.

Hình 3.8 Mô hình quy trình nghiệp vụ xử lý đơn hàng online

3.4 Biểu diễn mô hình ca sử dụng

Biểu đồ ca sử dụng mô tả cách một thực thể tương tác với hệ thống, bao gồm các thành phần chính là Actor và Use Case Actor đại diện cho thực thể tác động đến hệ thống, trong khi Use Case thể hiện tập hợp các tương tác giữa Actor và hệ thống, mô tả hành vi của hệ thống Hình 3.9 minh họa siêu mô hình của ca sử dụng một cách đơn giản.

Hình 3.9 Siêu mô hình ca sử dụng đơn giản [13]

Mô hình ca sử dụng trong Hình 3.10 minh họa các hành vi hoạt động của nhà hàng với 4 tác nhân chính: Client, Waiter, Cashier và Chef Các ca sử dụng như Order Food, Serve Food, và Pay for Food thể hiện những hoạt động chính tại nhà hàng Quan hệ giữa tác nhân và ca sử dụng được thể hiện qua các Association, trong khi mối quan hệ giữa các ca sử dụng sử dụng Include và Extend Với cấu trúc biểu đồ rõ ràng, mô hình ca sử dụng giúp người dùng hiểu cách thức hoạt động của hệ thống và tương tác với nó một cách dễ dàng.

Hình 3.10 Mô hình hoá ca sử dụng trong một nhà hàng

3.5 Xác định các luật chuyển đổi mô hình Ở phần này, luận văn đưa ra một tập hợp các mối tương quan giữa các đối tượng và các quan hệ của hai mô hình trên (dưới dạng XMI), từ đó cho phép xây dựng phương pháp để chuyển đổi mô hình một cách hợp lý Cụ thể, tập luật được chia thành ba nhóm: chuyển đổi đối tượng, chuyển đổi quan hệ giữa các đối tượng và chuyển đổi quan hệ với dữ liệu Dựa trên việc phân tích và trích xuất các yếu tố thành phần tương ứng với các luật chuyển đổi đã được xác định, luận văn sẽ phát triển các hàm ATL thực hiện quá trình chuyển đổi, xác định bởi từ khóa cú pháp rule

3.5.1 Luật chuyển đổi cho các đối tƣợng (Rules for Elements)

Luật RE1: Ánh xạ Task sang UseCase [9]

Trong BPMN, Task thể hiện sự tương tác của người dùng với hệ thống, trong khi đó, ca sử dụng phản ánh mục tiêu mà người dùng mong muốn đạt được khi sử dụng hệ thống Vì vậy, có thể chuyển đổi một Task trong BPMN thành một Use Case, với tên của Use Case tương ứng với tên của Task.

Hình 3.11 Luật RE1 - Ánh xạ Task sang UseCase

Siêu khái niệm Task được chuyển đổi thành siêu khái niệm UseCase, trong đó thuộc tính name được giữ nguyên và gán cho đối tượng UseCase mới Hình 3.12 minh họa cấu trúc cài đặt của luật RE1.

Hình 3.12 Hàm chuyển đổi RE1 - Task2UseCase

Luật RE2: Ánh xạ Participant sang Actor [7, 9]

Trong BPMN, bất kỳ ai tham gia vào một hoạt động hoặc quy trình đều được gọi là Participant Trong khi đó, trong biểu đồ ca sử dụng, một Actor đại diện cho người dùng của hệ thống Do đó, một Participant trong quy trình nghiệp vụ có thể được liên kết với một Actor trong biểu đồ ca sử dụng.

Hình 3.13 Luật RE2 - Ánh xạ Participant sang Actor

Biểu diễn mô hình BPMN

Nhiều kỹ thuật và công cụ đã được phát triển để mô hình hóa quy trình nghiệp vụ, nhưng chủ yếu tập trung vào các khía cạnh ngoài hành vi như cấu trúc tổ chức và đối tượng dữ liệu Biểu đồ ca sử dụng, thuộc loại biểu đồ hành vi, chỉ tập trung vào hành vi mà không có các khái niệm khác, dẫn đến sự thiếu tương quan và khó khăn trong việc chuyển đổi Trong nghiên cứu này, BPMN được lựa chọn cho mô hình khái niệm quy trình nghiệp vụ, với các định nghĩa về hành vi là Flow Objects và các mối quan hệ giữa chúng được thể hiện qua Sequence Flow, Message Flow và Association Hình 3.7 minh họa metamodel BPMN đơn giản.

Hình 3.7 Siêu mô hình lược giản BPMN [8]

Quy trình nghiệp vụ đơn giản trong việc xử lý đơn hàng online của một webshop được minh họa trong Hình 3.8, thể hiện luồng công việc cơ bản của hệ thống bán hàng sau khi nhận đơn từ người dùng Đối tượng thực hiện là Web system, tương ứng với siêu khái niệm BPMNPool Quy trình bao gồm bốn bước: Receive Order, Check Credit, Fulfill Order và Send Invoice, được đại diện bởi các siêu khái niệm BPMNTask Sự kiện bắt đầu và kết thúc quy trình tương ứng với BPMNStart và BPMNEnd, nằm trong siêu khái niệm BPMNEvent Đây là ví dụ đơn giản giúp hình dung quy trình nghiệp vụ thực tế và cách thể hiện các siêu khái niệm trong siêu mô hình BPMN.

Hình 3.8 Mô hình quy trình nghiệp vụ xử lý đơn hàng online.

Biểu diễn mô hình ca sử dụng

Biểu đồ ca sử dụng mô tả cách một thực thể tương tác với hệ thống, bao gồm các yếu tố chính như Actor và Use Case Actor đại diện cho thực thể tác động đến hệ thống, trong khi Use Case là tập hợp các tương tác giữa Actor và hệ thống, phản ánh hành vi của hệ thống Hình 3.9 minh họa siêu mô hình của ca sử dụng một cách đơn giản.

Hình 3.9 Siêu mô hình ca sử dụng đơn giản [13]

Mô hình ca sử dụng trong Hình 3.10 minh họa các hành vi hoạt động của một nhà hàng, xác định 4 tác nhân chính: Client, Waiter, Cashier và Chef Các ca sử dụng như Order Food, Serve Food, Pay for Food thể hiện những hoạt động chính tại nhà hàng Mối quan hệ giữa các tác nhân và ca sử dụng được thể hiện qua các Association, trong khi các ca sử dụng liên kết với nhau bằng Include và Extend Với cấu trúc biểu đồ đơn giản và rõ ràng, mô hình ca sử dụng giúp người dùng dễ dàng hiểu cách thức hoạt động và tương tác với hệ thống.

Hình 3.10 Mô hình hoá ca sử dụng trong một nhà hàng.

Xác định các luật chuyển đổi mô hình

Luận văn trình bày một tập hợp các mối tương quan giữa các đối tượng và quan hệ của hai mô hình dưới dạng XMI, nhằm xây dựng phương pháp chuyển đổi mô hình hợp lý Tập luật được phân chia thành ba nhóm: chuyển đổi đối tượng, chuyển đổi quan hệ giữa các đối tượng và chuyển đổi quan hệ với dữ liệu Qua việc phân tích và trích xuất các yếu tố thành phần liên quan đến các luật chuyển đổi đã xác định, luận văn phát triển các hàm ATL để thực hiện quá trình chuyển đổi, được xác định bởi từ khóa cú pháp rule.

3.5.1 Luật chuyển đổi cho các đối tƣợng (Rules for Elements)

Luật RE1: Ánh xạ Task sang UseCase [9]

Trong BPMN, Task đại diện cho sự tương tác của người dùng với hệ thống, trong khi ca sử dụng thể hiện mục tiêu mà người dùng muốn đạt được khi sử dụng hệ thống Vì vậy, có thể chuyển đổi một Task trong BPMN thành một Use Case, với tên của Use Case tương ứng với tên của Task.

Hình 3.11 Luật RE1 - Ánh xạ Task sang UseCase

Siêu khái niệm Task được chuyển đổi thành siêu khái niệm UseCase, trong đó thuộc tính name được giữ nguyên và gán cho đối tượng UseCase mới Hình 3.12 minh họa cấu trúc cài đặt của luật RE1.

Hình 3.12 Hàm chuyển đổi RE1 - Task2UseCase

Luật RE2: Ánh xạ Participant sang Actor [7, 9]

Trong BPMN, bất kỳ ai có hoạt động cần thực hiện trong quy trình được gọi là Participant Trong khi đó, trong biểu đồ ca sử dụng, Actor đại diện cho người dùng của hệ thống Do đó, một Participant trong quy trình nghiệp vụ có thể được ánh xạ sang một Actor trong ca sử dụng.

Hình 3.13 Luật RE2 - Ánh xạ Participant sang Actor

Siêu khái niệm Participant được chuyển đổi thành siêu khái niệm Actor, trong đó thuộc tính name được giữ nguyên và gán cho đối tượng Actor mới Hình 3.14 minh họa cấu trúc cài đặt của luật RE2.

Hình 3.14 Hàm chuyển đổi RE2 - Participant2Actor

3.5.2 Luật chuyển đổi cho các quan hệ giữa các đối tƣợng (Rules for Association)

Luật RA1: Ánh xạ quan hệ giữa Participant và Task sang Association giữa Actor và UseCase [7, 9]

Từ 2 luật RE1 và RE2, một Participant và một Task trong quy trình nghiệp vụ có thể tương ứng sinh ra một Actor và một Use Case trong biểu đồ ca sử dụng Do đó, liên kết giữa Participant và Task sẽ tương ứng với liên kết Actor và Use Case trên

Hình 3.15 Luật RA1 - Ánh xạ giữa Participant và Task sang Association

Mối quan hệ giữa hai siêu khái niệm Task và Participant được ánh xạ sang siêu khái niệm Association thông qua thuộc tính ownedEnd, xác định Use Case và Actor Mỗi đối tượng ownedEnd sẽ được gán tên và loại tương ứng với khái niệm nguồn của Use Case và Actor Chi tiết về cài đặt này được minh họa trong Hình 3.16.

Hình 3.16 Hàm chuyển đổi RA1 - Task2UseCasenAssociation

Luật RA2: Ánh xạ SequenceFlow sang Dependency

Trong BPMN, dòng trình tự (SequenceFlow) thể hiện thứ tự thực hiện các tác vụ trong quy trình, tương tự như quan hệ Dependency trong mô hình ca sử dụng Luận văn này cung cấp thêm mô tả chi tiết về khái niệm này.

để thể hiện một ca sử dụng hoàn thành trước khi ca sử dụng tiếp theo xảy ra Hình 3.17 biểu diễn quy tắc chuyển đổi này.

Hình 3.17 Luật RA2 - Ánh xạ SequenceFlow sang Dependency

Siêu khái niệm SequenceFlow thể hiện luồng thực hiện giữa hai Task được chuyển đổi thành quan hệ Dependency với thuộc tính name là

để thể hiện thứ tự của các UseCase sinh ra

Hình 3.18 Hàm chuyển đổi RA2 - SequenceFlow2Dependency

Luật RA3 mô tả mối liên hệ giữa Exclusive Gateway trong BPMN và quan hệ trong mô hình ca sử dụng Exclusive Gateway kết nối các Task, với việc thực hiện các Task đích không bắt buộc và phụ thuộc vào điều kiện của Gateway Tương tự, Use Case ban đầu có thể được mở rộng để thêm chức năng cho hệ thống, trong khi Use Case mở rộng phụ thuộc vào Use Case ban đầu và thường không bắt buộc, chỉ được sử dụng trong những điều kiện nhất định Hình 3.19 minh họa cụ thể cho luật chuyển đổi này.

Hình 3.19 Luật RA3 - Ánh xạ ExclusiveGateway sang quan hệ Extend

Luồng rẽ nhánh qua ExclusiveGateway được chuyển đổi thành các quan hệ Extend giữa các UseCase Cụ thể, UseCase nguồn, tương ứng với Task nguồn, sẽ có thuộc tính ExtensionPoint, trong khi các UseCase đích, tương ứng với các Task đích, sẽ có thuộc tính Extend Thuộc tính này trỏ extendedCase tới UseCase nguồn và extensionLocation tới ExtensionPoint của UseCase nguồn.

Hình 3.20 Hàm chuyển đổi RA3 - Gateway2Extend

Luật RA4: Ánh xạ MessageFlow sang Association [7, 9]

Một Actor - đại diện cho một Participant bên ngoài - có quan hệ Association với Use Case - đại diện cho Task mà Participant trao đổi thông điệp.

Hình 3.21 Luật RA4 - Ánh xạ MessageFlow sang Association

The concept of MessageFlow from Participant to Task corresponds to the Association between Actor and the relevant UseCase Similar to the implementation of rule RA1, the Association includes ownedEnd properties that point to the Actor and UseCase, with the name and type attributes assigned accordingly to these entities.

Hình 3.22 Hàm chuyển đổi RA4 - MessageFlow2Association

3.5.3 Luật chuyển đổi cho các quan hệ với dữ liệu (Rules for Data association)

Quan hệ "bao gồm" trong biểu đồ ca sử dụng phản ánh rằng hành vi của Use Case bao gồm là cần thiết và là một phần không thể thiếu của Use Case cơ bản Use Case cơ bản sẽ không thể hoàn thành nếu thiếu Use Case bao gồm Tương tự, các Task trong quy trình nghiệp vụ cũng kết nối với các đối tượng dữ liệu thông qua các hành động như đọc/ghi thông tin từ Data Store và gửi/nhận thông tin từ Data object Sự chuyển đổi tương ứng với những hành động này được thể hiện qua bốn quy luật sau đây.

Luật RD1: Ánh xạ đọc Data Store sang quan hệ include ReadData Việc một Task đọc thông tin từ Data Store có thể chuyển thành quan hệ

giữa hai Use Case như Hình 3.23.

Hình 3.23 Luật RD1 - Ánh xạ đọc Data Store sang quan hệ include ReadData

In the context of a Task reading data from a Data Store, the program will create a new Use Case with the attribute name "Read information from [Data Store name]." The Use Case generated corresponding to the Task will include an attribute that points to the newly created ReadData Use Case.

Hình 3.24 Hàm chuyển đổi RD1 - DataStore2ReadData

Luật RD2: Ánh xạ ghi Data Store sang quan hệ include WriteData Việc một Task ghi thông tin vào Data Store có thể chuyển thành quan hệ

giữa hai Use Case như Hình 3.25.

Hình 3.25 Luật RD2 - Ánh xạ ghi Data Store sang quan hệ include WriteData

In relation to the Task that writes data to the Data Store, the program will create a new Use Case with the attribute name "Write information to " followed by the Data Store name The Use Case generated corresponding to the Task will include an attribute that points to the newly created Use Case "WriteData."

Hình 3.26 Hàm chuyển đổi RD2 – DataStore2WriteData

Luật RD3: Ánh xạ nhận Data Object sang quan hệ include ReceiveData Việc một Task nhận thông tin Data Object có thể chuyển thành quan hệ

giữa hai Use Case như Hình 3.27.

Hình 3.27 Luật RD3 - Ánh xạ nhận Data Object sang quan hệ include ReceiveData

Chương trình sẽ tạo một UseCase mới với thuộc tính tên là "Receive" cộng với tên của Data Object, dựa trên quan hệ Task nhận dữ liệu Data Object UseCase mới này sẽ có thuộc tính include và liên kết với UseCase ReceiveData tương ứng với Task.

Hình 3.28 Hàm chuyển đổi RD3 - DataObject2ReceiveData

Luật RD4: Ánh xạ gửi Data Object sang quan hệ include SendData Việc một Task gửi thông tin Data Object có thể chuyển thành quan hệ

giữa hai Use Case như Hình 3.29.

Hình 3.29 Luật RD4 - Ánh xạ gửi Data Object sang quan hệ include SendData

Tổng kết chương

Trong chương này, luận văn trình bày quy trình tự động hóa mô hình ca sử dụng từ mô hình quy trình nghiệp vụ BPMN Bằng cách phân tích và đánh giá các định nghĩa cũng như khái niệm của hai siêu mô hình, luận văn đã xây dựng các luật chuyển đổi tương ứng và đề xuất một thuật toán thực hiện quá trình chuyển đổi Kết quả là, các kỹ thuật biểu diễn mô hình UML được áp dụng để tạo ra biểu đồ ca sử dụng theo yêu cầu của người dùng.

THỰC NGHIỆM VÀ ĐÁNH GIÁ

Công cụ, ngôn ngữ và môi trường hỗ trợ

Theo quy trình tự động được mô tả trong Hình 3.3, luận văn đã áp dụng các công cụ và môi trường cần thiết để thực hiện cài đặt chương trình.

4.1.1 Kỹ thuật biểu diễn quy trình nghiệp vụ

BPMN là một tiêu chuẩn phổ biến trong mô hình hóa quy trình nghiệp vụ, được hỗ trợ bởi nhiều công cụ như Eclipse BPMN2 Modeler, Bizagi Modeler và Enterprise Architect Luận văn này lựa chọn sử dụng Eclipse BPMN2 Modeler vì những lợi ích vượt trội mà nó mang lại.

 Công cụ miễn phí cung cấp đầy đủ các tính năng cần thiết, có thể cài đặt plugin đơn giản trong bộ công cụ Eclipse.

 Thiết kế biểu đồ BPMN một cách thuận tiện với đồ họa đơn giản dễ nhìn và kéo thả các thành phần dễ dàng

 Lưu mô hình dưới định dạng bpmn chuẩn và hỗ trợ xuất ra file ảnh (.png,

Hình 4.1 Giao diện công cụ Eclipse BPMN2 Modeler

4.1.2 Kỹ thuật biểu diễn biểu đồ ca sử dụng

Sau khi chuyển đổi mô hình, chúng ta thu được một file XMI chứa đầy đủ nội dung mô hình ca sử dụng Để trực quan hóa biểu đồ ca sử dụng, có nhiều công cụ như Eclipse Papyrus, UML Designer, và Sirius Tuy nhiên, để thống nhất môi trường cho toàn bộ giải pháp, luận văn đã chọn sử dụng Eclipse Papyrus nhờ vào các ưu điểm nổi bật của nó.

Công cụ mã nguồn mở cho kỹ thuật dựa trên mô hình (Model-Based Engineering) mang lại sự tiện lợi trong việc cài đặt và sử dụng, có thể sử dụng bộ cài riêng hoặc dưới dạng plugin trên nền tảng Eclipse.

 Cho phép biểu diễn biểu đồ UML dễ dàng từ các tệp XMI chuẩn hóa.

Hình 4.2 Giao diện công cụ Eclipse Papyrus.

Nghiên cứu tình huống thực nghiệm

Trong phần này, luận văn nghiên cứu và áp dụng phương pháp BPMN2UseCase vào mô hình quy trình nghiệp vụ của Hệ thống Thư viện Trường học Mô hình này được chia thành ba phần nhỏ: Mua sách, Cho mượn sách và Trả sách, như thể hiện trong các hình 4.3, 4.4 và 4.5 Kết quả từ mô hình ca sử dụng sẽ được sử dụng để so sánh và đánh giá hiệu quả của cả hai phương pháp.

Hình 4.3 Mô hình BPMN Purchase book [10]

Hình 4.4 Mô hình BPMN Lend book [10]

Áp dụng các luật chuyển đổi BPMN2UseCase, chúng ta có thể xây dựng biểu đồ ca sử dụng cho mô hình BPMN "Return book" như thể hiện trong các hình 4.6, 4.7 và 4.8.

 Luật RE1: 15 UseCase sinh ra từ 15 Task tương ứng (Analyze suggestions for new acquisitions, Reject suggestion, Request budget,…)

 Luật RE2: 4 Actor sinh ra từ 4 Participant tương ứng (Librarian, Supplier, Attendant, Borrower)

The RA1 rule establishes an Association link between four Actors and their corresponding Use Cases, which arise from the relationships among four Participants and the specific Tasks assigned to each Participant, such as the Librarian analyzing suggestions for new acquisitions and the Attendant checking borrower identification.

 Luật RA2: 3 Dependency > sinh ra từ 3 SequenceFlow giữa 2 Task (Receive returned book đến Search for book‟s active loan, Penalty treatment đến Upload Loan info, )

 Luật RA3: 8 Extend association giữa các UseCase sinh ra từ 4 ExclusiveGateway (Check book status đến Register loan và đến Inform Book not available, )

 Luật RA4: 7 Association sinh ra từ 7 MessageFlow giữa các Participant và Task (Request budget đến Supplier, Borrower đến Check book status, )

 Luật RD1: 5 quan hệ Include ReadData sinh ra từ 5 quan hệ đọc dữ liệu từ Data Store (Suggestions đến Analyze suggestions for new acquisitions, Book đến Check book status, )

 Luật RD2: 3 quan hệ Include WriteData sinh ra từ 3 quan hệ ghi dữ liệu vào Data Store (Perform order ghi vào Order, Register loan ghi vào Loan…)

Hình 4.6 Mô hình ca sử dụng Purchase book

Hình 4.7 Mô hình ca sử dụng Lend book

Hình 4.8 Mô hình ca sử dụng Return book

Theo kết quả thu được, biểu đồ bao gồm 4 Actor , 22 UseCase , 22 Association giữa Actor và UseCase , 20 Association giữa các UseCase thuộc 3 loại (include, extend, precedes ).

Biểu đồ ca sử dụng được tạo ra theo phương pháp đơn giản, bao gồm 4 Actor, 15 Use Case và 10 mối liên kết giữa Actor và Use Case, không có mối liên kết nào giữa các Use Case.

Hình 4.9 Mô hình ca sử dụng School Library System [10]

4.2.2 Phương pháp đánh giá kết quả Để kiểm tra và đánh giá hiệu quả cũng như tính chính xác của phương pháp, luận văn đã đề xuất một bộ gồm 14 test-cases để thử nghiệm, bao gồm 3 test-cases School Library System được trình bày ở Mục 4.2.1 Các test-cases là những ví dụ về mô hình quy trình nghiệp vụ được sưu tầm online [28], chi tiết (đầu vào và đầu ra) sẽ được thể hiện trong phần Phụ lục Sau quá trình chạy thực nghiệm, kết quả sẽ được sử dụng để đánh giá phương pháp dựa trên ba tiêu chí: tính ổn định, tính đúng đắn và tính đầy đủ

4.2.2.1 Đánh giá tính ổn định

Trong phần này, luận văn sẽ kiểm tra tính ổn định của chương trình và xác định xem nó có cho ra kết quả đúng định dạng hay không Tiêu chí đánh giá quan trọng nhất là chương trình có thực hiện và truyền tải đầy đủ các quy tắc chuyển đổi đã đề xuất trong Mục 3.5 hay không Để thực hiện điều này, hai mô hình ca sử dụng sẽ được tạo ra bằng hai phương thức: BPMN2UseCase và cách thủ công Mọi sai lệch giữa hai kết quả đầu ra sẽ phản ánh tỷ lệ sai sót trong quá trình cài đặt chương trình Chương trình sẽ được chạy với 14 ca kiểm thử và đánh giá dựa trên 4 tiêu chí.

- Chương trình có lỗi khi đang chạy hay không?

- Sau khi chạy xong, chương trình có tạo ra được kết quả không?

- Kết quả sinh ra có đúng định dạng cho trước không?

- Tỉ lệ sai sót khi truyền tải bộ luật chuyển đổi như thế nào?

Kết quả cho thấy phương pháp chạy ổn định, không gặp lỗi và đảm bảo đầu ra tuân thủ đúng quy tắc chuyển đổi mô hình.

4.2.2.2 Đánh giá tính đúng đắn Đối với các yếu tố thành phần cơ bản (UseCase, Actor và Association), phương thức đánh giá đó là thực hiện chuyển đổi mô hình quy trinh nghiệp vụ sang mô hình ca sử dụng bởi hai phương pháp: thủ công và tự động sử dụng BPMN2UseCase Từ đó có thể xác định tính đúng đắn của phương pháp đề xuất trong trường hợp xét riêng các thành phần cơ bản này.

Bảng 4.1 Kết quả đánh giá tính đúng đắn

Actor from Participant 2 2 100% Association from Participant-Task 5 5 100%

Actor from Participant 5 2 40% Association from Participant-Task 8 8 100%

Actor from Participant 3 3 100% Association from Participant-Task 8 8 100%

Actor from Participant 2 2 100% Association from Participant-Task 12 12 100%

Actor from Participant 5 5 100% Association from Participant-Task 12 12 100%

Actor from Participant 3 3 100% Association from Participant-Task 10 10 100%

Actor from Participant 2 2 100% Association from Participant-Task 4 4 100%

Actor from Participant 4 2 50% Association from Participant-Task 7 7 100%

Actor from Participant 5 2 40% Association from Participant-Task 8 8 100%

Actor from Participant 2 2 100% Association from Participant-Task 8 8 100%

Actor from Participant 2 2 100% Association from Participant-Task 8 8 100%

Actor from Participant 2 2 100% Association from Participant-Task 8 8 100%

Actor from Participant 2 2 100% Association from Participant-Task 8 8 100%

Actor from Participant 2 2 100% Association from Participant-Task 8 8 100%

Phương pháp BPMN2UseCase thường cho ra kết quả trùng khớp hoàn toàn với phương pháp thủ công, tuy nhiên, có sự khác biệt ở một số test-case như Book selling, Payment process và Pizza store, đặc biệt là về số lượng Actor được tạo ra Khi xem xét mô hình BPMN đầu vào, nhận thấy rằng trong trường hợp một Participant có nhiều Lane, BPMN2UseCase chỉ sinh ra 1 Actor cho Participant chính, trong khi phương pháp thủ công tạo ra nhiều Actor cho từng Lane Điều này dẫn đến tổng số lượng Actor tăng lên Để khắc phục vấn đề này, cần nghiên cứu sâu hơn về Lane và khả năng chuyển đổi trong các hướng phát triển tiếp theo.

4.2.2.3 Đánh giá tính đầy đủ

Luận văn này sẽ phân tích khả năng bao trùm của phương pháp BPMN2UseCase đối với các ký hiệu khác nhau được sử dụng trong mô hình quy trình nghiệp vụ.

Bảng 4.2 Kết quả đánh giá tính đầy đủ

Số ký hiệu đƣợc chuyển đổi

Số ký hiệu không đƣợc chuyển đổi

Loại ký hiệu không đƣợc chuyển đổi

Auction Service 5 2 SequenceFlow giữa 2 Gateway

SequenceFlow giữa Gateway và Event

Online 4 1 SequenceFlow giữa Event và shopping Gateway

SequenceFlow giữa Gateway và Event

Nobel Prize 8 1 SequenceFlow giữa 2 Gateway

Theo nhận xét từ Bảng 4.2, có hai loại ký hiệu BPMN chưa được chuyển đổi sang biểu đồ ca sử dụng:

SequenceFlow giữa hai Gateway có ảnh hưởng lớn đến luồng thực hiện nghiệp vụ trong mô hình đầu vào Trong một số trường hợp cụ thể, việc xuất hiện hai Gateway liên tiếp có thể xảy ra, và dữ liệu này có thể được phân tích để đề xuất chuyển đổi thành Pre-condition trong phần đặc tả ca sử dụng.

SequenceFlow giữa Gateway và Event đóng vai trò quan trọng trong quy trình Một Event quyết định xem quy trình sẽ kết thúc hay tiếp tục thực thi, trong khi Gateway giúp phân luồng thực hiện quy trình Mối liên kết giữa hai loại ký hiệu này có thể được xem xét như một Post-condition trong phần đặc tả ca sử dụng.

4.2.3 Tổng kết thực nghiệm và đánh giá

Sau khi cài đặt phương pháp BPMN2UseCase, luận văn đã thực nghiệm và áp dụng giải pháp trên mô hình quy trình nghiệp vụ cụ thể của Hệ thống Thư viện Trường học, bao gồm 3 mô hình nhỏ Kết quả cho thấy biểu đồ ca sử dụng thu được chi tiết và giàu thông tin hơn so với các nghiên cứu trước đó, đặc biệt với việc bổ sung nhiều mối quan hệ Association giữa các đối tượng Actor và Use Case.

Để đánh giá hiệu quả của giải pháp BPMN2UseCase, luận văn đã đề xuất phương pháp đánh giá dựa trên ba tiêu chí: tính ổn định, tính đúng đắn và tính đầy đủ Luận văn xây dựng bộ test-cases gồm 14 test-cases, phản ánh các mô hình quy trình nghiệp vụ thực tế Dựa trên kết quả chạy thực nghiệm, có thể tiến hành phân tích và đưa ra các nhận xét liên quan đến hiệu quả của giải pháp này.

Chương trình chạy bộ test-cases thể hiện tính ổn định với tỉ lệ lỗi nghiêm trọng là 0% Kết quả luôn đúng định dạng, chứng tỏ rằng chương trình hoạt động ổn định và đảm bảo đầu ra tuân theo đúng quy tắc chuyển đổi mô hình.

Tổng kết chương

Trong chương này, chúng tôi trình bày chi tiết quá trình cài đặt, áp dụng và đánh giá phương pháp sinh tự động ca sử dụng từ mô hình quy trình nghiệp vụ Luận văn nêu rõ các bộ công cụ, môi trường hỗ trợ và kỹ thuật biểu diễn mô hình cho phương pháp này Bộ quy tắc chuyển đổi mô hình được đề xuất trong Mục 3.5 đã được cài đặt trong chương trình BPMN2UseCase sử dụng ngôn ngữ ATL, với việc xây dựng các hàm chính và hàm bổ trợ để thực hiện từng quy tắc Sau khi hoàn thiện cài đặt, chương trình đã được thử nghiệm và áp dụng trên các tình huống cụ thể với bộ test-cases, từ đó cho phép phân tích, đánh giá và rút ra nhận xét về hiệu quả của giải pháp.

Ngày đăng: 05/10/2022, 09:09

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[2] Phạm Nguyễn Cương, Hồ Tường Vinh, Phân tích thiết kế hệ thống hướng đối tượng bằng UML, Đại học KHTN-TP. HCM, ASIA-ITC 1 Sách, tạp chí
Tiêu đề: Phân tích thiết kế hệ thống hướng đối tượng bằng UML
[4] Beichter F. W., Herzog O., Petzsch H. (1984), "SLAN-4-A software specification and design language.", IEEE transactions on software engineering 2, pp. 155-162 Sách, tạp chí
Tiêu đề: SLAN-4-A software specification and design language
Tác giả: Beichter F. W., Herzog O., Petzsch H
Năm: 1984
[6] Bouzidi A., Haddar N., Abdallah M. B., Haddar K. (2017), “Deriving Use Case Models from BPMN Models”, IEEE/ACS 14th International Conference on Computer Systems and Applications, Hammamet, pp. 238-243 Sách, tạp chí
Tiêu đề: Deriving Use Case Models from BPMN Models”, "IEEE/ACS 14th International Conference on Computer Systems and Applications
Tác giả: Bouzidi A., Haddar N., Abdallah M. B., Haddar K
Năm: 2017
[7] Bouzidi, A., Haddar, N., Ben-Abdallah, M. and Haddar, K. (2020), “Toward the Alignment and Traceability between Business Process and Software Models”, Proceedings of the 22nd International Conference on Enterprise Information Systems, Vol. 2, pp. 701-708 Sách, tạp chí
Tiêu đề: Toward the Alignment and Traceability between Business Process and Software Models”, "Proceedings of the 22nd International Conference on Enterprise Information Systems
Tác giả: Bouzidi, A., Haddar, N., Ben-Abdallah, M. and Haddar, K
Năm: 2020
[8] Cetinkaya D., Verbraeck A., and Seck M. D. (2011), "MDD4MS: A Model Driven Development Framework for Modeling and Simulation", Proceedings of the 2011 Summer Computer Simulation Conference, The Hague, Netherlands Sách, tạp chí
Tiêu đề: MDD4MS: A Model Driven Development Framework for Modeling and Simulation
Tác giả: Cetinkaya D., Verbraeck A., and Seck M. D
Năm: 2011
[9] Cruz E. F., Machado R. J., and Santos M. Y. (2014), “From Business Process Models to Use Case Models: A systematic approach”, Advances in Enterprise Engineering VIII. Springer International Publishing, pp. 167-181 Sách, tạp chí
Tiêu đề: From Business Process Models to Use Case Models: A systematic approach”", Advances in Enterprise Engineering
Tác giả: Cruz E. F., Machado R. J., and Santos M. Y
Năm: 2014
[10] Cruz E. F., Machado R. J., and Santos M. Y. (2015), “Bridging the gap between a set of interrelated business process models and software models”, 17th International Conference on Enterprise Information Systems, pp. 338–345 Sách, tạp chí
Tiêu đề: Bridging the gap between a set of interrelated business process models and software models”, "17th International Conference on Enterprise Information Systems
Tác giả: Cruz E. F., Machado R. J., and Santos M. Y
Năm: 2015
[11] Cruz E. F., Cruz A. M. R (2018), “Deriving Integrated Software Design Models from BPMN Business Process Models”, Proceedings of the 13th International Conference on Software Technologies, pp. 571-582 Sách, tạp chí
Tiêu đề: Deriving Integrated Software Design Models from BPMN Business Process Models”, "Proceedings of the 13th International Conference on Software Technologies
Tác giả: Cruz E. F., Cruz A. M. R
Năm: 2018
[12] Davenport T. H. (1993), Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press, Boston Sách, tạp chí
Tiêu đề: Process Innovation: Reengineering Work through Information Technology
Tác giả: Davenport T. H
Năm: 1993
[13] Dijkman R. M., Joosten S. M. (2002), An algorithm to derive use case diagrams from business process models, the 6th Intern. Conf. on Software Engineering and Applications, US Sách, tạp chí
Tiêu đề: An algorithm to derive use case diagrams from business process model
Tác giả: Dijkman R. M., Joosten S. M
Năm: 2002
[14] Dijkman R. M., Joosten S. M. (2002), Deriving use case diagrams from business process models, CTIT Tech. Rep., Enschede, The Netherlands Sách, tạp chí
Tiêu đề: Deriving use case diagrams from business process models
Tác giả: Dijkman R. M., Joosten S. M
Năm: 2002
[15] Nurcan S., Grosz G., and Souveyet C. (1998), “Describing business processes with a guided use case approach”, Proceedings of the 1998 Conference on Advanced Information Systems Engineering, Vol. 1413 of Lecture Notes in Computer Science, pp. 339–362, Berlin Sách, tạp chí
Tiêu đề: Describing business processes with a guided use case approach”, "Proceedings of the 1998 Conference on Advanced Information Systems Engineering
Tác giả: Nurcan S., Grosz G., and Souveyet C
Năm: 1998
[16] Object Management Group (2001), OMG Unified Modeling Language Specification version 1.4, OMG Specification formal/2001, pp. 09-67 Sách, tạp chí
Tiêu đề: OMG Unified Modeling Language Specification version 1.4
Tác giả: Object Management Group
Năm: 2001
[17] Object Management Group (2011), Business process model and notation (BPMN) version 2.0, tech. rep.,Object Management Group Sách, tạp chí
Tiêu đề: Business process model and notation (BPMN) version 2.0
Tác giả: Object Management Group
Năm: 2011
[18] Rajagopal P., Lee R., Ahlswede T., Chiang C., Karolak D. (2005), "A new approach for software requirements elicitation." Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Network, IEEE Sách, tạp chí
Tiêu đề: A new approach for software requirements elicitation
Tác giả: Rajagopal P., Lee R., Ahlswede T., Chiang C., Karolak D
Năm: 2005
[19] Rehman T., Khan M. N. A., Riaz N. (2013), “Analysis of Requirement Engineering Processes, Tools/Techniques and Methodologies”, International Journal of Information Technology and Computer Science, pp. 40-48 Sách, tạp chí
Tiêu đề: Analysis of Requirement Engineering Processes, Tools/Techniques and Methodologies”, "International Journal of Information Technology and Computer Science
Tác giả: Rehman T., Khan M. N. A., Riaz N
Năm: 2013
[20] Rodríguez A., García-Rodríguez de Guzmán I. (2007), “Obtaining Use Cases and Security Use Cases from Secure Business Process through the MDA Approach”, Proceedings of the 5th International Workshop on Security in Information Systems, pp. 209-219 Sách, tạp chí
Tiêu đề: Obtaining Use Cases and Security Use Cases from Secure Business Process through the MDA Approach”, "Proceedings of the 5th International Workshop on Security in Information Systems
Tác giả: Rodríguez A., García-Rodríguez de Guzmán I
Năm: 2007
[22] Turkman S. and Taweel A. (2019), “Business Process Model Driven Automatic Software Requirements Generation”, Shishkov, B. (ed.) BMSD 2019.LNBIP, vol. 356, pp. 270–278 Sách, tạp chí
Tiêu đề: Business Process Model Driven Automatic Software Requirements Generation”, "Shishkov, B. (ed.) BMSD 2019. "LNBIP
Tác giả: Turkman S. and Taweel A
Năm: 2019
[25] Di Ruscio D., Eramo R., Pierantonio A. (2012), “Model transformations”, Formal Methods for Model-Driven Engineering, pp. 91–136, Springer Sách, tạp chí
Tiêu đề: Model transformations”, "Formal Methods for Model-Driven Engineering
Tác giả: Di Ruscio D., Eramo R., Pierantonio A
Năm: 2012
[27] Czarnecki K, Helsen S (2003), “Classification of model transformation approaches”, Proceedings of the 2nd OOPSLA workshop on generative techniques in the context of the model driven architecture, Vol. 45 (No. 3), pp 1–17 Sách, tạp chí
Tiêu đề: Classification of model transformation approaches”, "Proceedings of the 2nd OOPSLA workshop on generative techniques in the context of the model driven architecture
Tác giả: Czarnecki K, Helsen S
Năm: 2003

HÌNH ẢNH LIÊN QUAN

TỪ MƠ HÌNH QUY TRÌNH NGHIỆP VỤ DỰA TRÊN CHUYỂN ĐỔI MƠ HÌNH - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
TỪ MƠ HÌNH QUY TRÌNH NGHIỆP VỤ DỰA TRÊN CHUYỂN ĐỔI MƠ HÌNH (Trang 1)
TỪ MÔ HÌNH QUY TRÌNH NGHIỆP VỤ DỰA TRÊN CHUYỂN ĐỔI MƠ HÌNH - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
TỪ MÔ HÌNH QUY TRÌNH NGHIỆP VỤ DỰA TRÊN CHUYỂN ĐỔI MƠ HÌNH (Trang 2)
2.1.2. Chuyển đổi mơ hình - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
2.1.2. Chuyển đổi mơ hình (Trang 18)
Hình 2.3. Cơ chế chuyển đổi mơ hình [24]. - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
Hình 2.3. Cơ chế chuyển đổi mơ hình [24] (Trang 20)
Bảng 2.1. BPMN Flow Objects [23] - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
Bảng 2.1. BPMN Flow Objects [23] (Trang 24)
Bảng 2.3. BPMN Swimlanes [23] - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
Bảng 2.3. BPMN Swimlanes [23] (Trang 25)
Relationship Quan hệ giữa các phần tử trong mơ hình, bao gồm  kết  hợp  (association),  tổng  quát  hóa  (generalization) - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
elationship Quan hệ giữa các phần tử trong mơ hình, bao gồm kết hợp (association), tổng quát hóa (generalization) (Trang 27)
Trong quá trình phát triển các hệ thống hiện nay, vấn đề chuyển đổi mơ hình quy trình nghiệp vụ sang mơ hình ca sử dụng có thể mang một ý nghĩa ứng dụng rất  lớn và đem lại nhiều lợi ích cụ thể - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
rong quá trình phát triển các hệ thống hiện nay, vấn đề chuyển đổi mơ hình quy trình nghiệp vụ sang mơ hình ca sử dụng có thể mang một ý nghĩa ứng dụng rất lớn và đem lại nhiều lợi ích cụ thể (Trang 28)
khó khăn trong việc phân tích và xác định các luật chuyển đổi, mơ hình ca sử dụng đầu ra cịn sơ sài, chưa đầy đủ và thiếu nhiều thơng tin [9] (Hình 3.2) - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
kh ó khăn trong việc phân tích và xác định các luật chuyển đổi, mơ hình ca sử dụng đầu ra cịn sơ sài, chưa đầy đủ và thiếu nhiều thơng tin [9] (Hình 3.2) (Trang 29)
Hình 3.3. Quy trình chuyển đổi mơ hình đề xuất. - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
Hình 3.3. Quy trình chuyển đổi mơ hình đề xuất (Trang 30)
Hình 3.5. Định dạng đầu vào *.bpmn. - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
Hình 3.5. Định dạng đầu vào *.bpmn (Trang 31)
Hình 3.7. Siêu mơ hình lược giản BPMN [8]. - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
Hình 3.7. Siêu mơ hình lược giản BPMN [8] (Trang 32)
Hình 3.8. Mơ hình quy trình nghiệp vụ xử lý đơn hàng online. - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
Hình 3.8. Mơ hình quy trình nghiệp vụ xử lý đơn hàng online (Trang 32)
Hình 3.9. Siêu mơ hình ca sử dụng đơn giản [13]. - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
Hình 3.9. Siêu mơ hình ca sử dụng đơn giản [13] (Trang 33)
Hình 3.16. Hàm chuyển đổi RA 1- Task2UseCasenAssociation. - Sinh tự động chế tác phần mềm từ mô hình quy trình nghiệp vụ dựa vào chuyển đổi mô hình
Hình 3.16. Hàm chuyển đổi RA 1- Task2UseCasenAssociation (Trang 36)

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w