基於 Petri 網的軟體過程支撐環境設計

基於 Petri 網的軟體過程支撐環境設計

1. 基於 Petri 網的軟體過程支撐環境設計
   1. 摘要
   2. 第 1 章 緒論
      1. 1.1 軟體過程與過程建模
      2. 1.3 軟體過程支撐環境現狀
      3. 1.3 本課題的研究內容及意義
         1. 1.3.1 研究內容
         2. 1.3.2 意義
      4. 1.4 Petri 網簡介
   3. 第 2 章 軟體流程定義語言
      1. 2.1 SPDL 概述
      2. 2.2 SPDL 元模型
         1. 2.2.1 XML Schema
      3. 2.3 模型變換
         1. 2.3.1 SPDL 域到 Java 域的變換
         2. 2.3.2 SPDL 執行個體的 Petri 網圖產生
            1. 2.3.2.1 基元塊
            2. 2.3.2.2 Petri 網圖產生
      4. 2.4 基於 SPDL 的軟體過程建模方法
   4. 第 3 章 軟體過程執行控制
      1. 3.1 過程生存周期
      2. 3.2 過程執行控制
         1. 3.2.1 標記網初始化
         2. 3.2.2 點火控制
      3. 3.3 曆史追蹤
   5. 第 4 章 軟體過程支撐環境設計
      1. 4.1 BeyondTrack 項目簡介
      2. 4.2 體繫結構設計
   6. 結論
   7. 致謝
   8. 參考文獻
   9. 附錄

摘要

在軟體的生存周期中，軟體過程是整個軟體開發實施的核心。成功實施的軟體項目必須基於一個良好的軟體過程元模型與相應的軟體過程支撐環境。本論文為提出了
一個基於 XML Schema 定義的以活動為中心的軟體流程定義語言 SPDL，設計並初步實現了其基於 Petri
網理論進行軟體過程執行控制的支撐環境。

關鍵詞：Petri 網，軟體過程，過程模型，SPDL

Abstract

Software
process is the core of development in software life cycle. Successful
software project must base on a good software process meta model and a
corresponding support environment. The thesis presents a XML
Schema-based and activity-centric software process definition language
SPDL, then designs and implements a execution controlling support
environment based on the Petri net theory.

Keywords: Petri net, software process, process model, SPDL

第 1 章 緒論 1.1 軟體過程與過程建模

軟體過程是軟體生存周期中所涉及的一系列相關過程。過程是活動的集合，活動是任務的集合，任務是把輸入轉換為輸出的操作[3]。軟體過程模型是軟體過程的靜態描述，是軟體過程執行的依據。軟體過程是軟體過程模型的執行執行個體，它是軟體過程模型的動態表現。
在進行具體軟模組時，都需要對其進行建模，根據 L. Osterweil 提出的“軟體過程也是軟體”[3]的觀點出發，軟體過程需要建模是自然的。目前，對軟體模組進行建模時最為常用的建模工具是 UML[1]，它提供了對物件導向軟體模組進行建模的統一標準。
1.3 軟體過程支撐環境現狀

對於軟體過程建模來說，目前尚未形成類似 UML 影響力的建模工具。OMG 提出了 SPEM（Software Process
Engineering Meta-Model ）[16] 用於描述軟體過程模型，文獻[17]提出了基於 SPEM 的 CMM
軟體過程元模型，但都卻缺乏一個軟體過程執行、過程演化的執行支撐環境。
在文獻[3]中提出了一個的軟體並行開發模型及其控制模型，並基於 Petri 網理論對這些模型進行了精確定義，表明了 Petri 網理論是解決軟體過程建模與執行控制的有效途徑。

1.3 本課題的研究內容及意義 1.3.1 研究內容

1. 軟體過程與軟體過程模型
   軟體過程是指軟體生存周期中所涉及的一系列相關過程，軟體過程模型是軟體過程的靜態描述。如何準確地描述軟體過程模型是重中之重。
2. 軟體過程式控制制
   為了精確地進行軟體過程執行控制，基於 Petri 網的軟體過程模型描述與軟體過程式控制制是解決這一問題的有效途徑之一。
3. 軟體過程支撐環境
   軟體過程建模、軟體過程模型修改（模型演化）、軟體過程執行管理最終的目的是為了提高軟體生產率，所以提供一個高品質的支撐環境是必然的。

1.3.2 意義

近年來，隨著社會對軟體需求的與日俱增，如何控制軟體生產過程以及如何持續地改進、演化軟體過程就成為了軟體工程研究的核心問題之一。我認為提出一個精確
的軟體流程定義語言，並實現針對此語言可用的軟體過程支撐環境是非常有必要的。在該支撐環境下，軟體開發人員：

1. 能夠準確地定義軟體生存周期涉及的各類軟體過程模型
2. 能夠根據定義的軟體過程模型精確地完成相應的軟體過程
3. 在發現已定義的軟體過程模型有缺陷時能夠將其及時修正

綜上，通過軟體過程的精確控制及其模型的不斷演化，達到軟體開發人員認為最優的軟體過程，從而提高其軟體生產率。

1.4 Petri 網簡介

Petri 網是一種用於描述離散的、分布式系統的數學建模工具。1962 年，Carl Adam Petri 以其著名的論文“Kommunikation mit Automaten”獲得博士學位。在該論文中，他正式提出了 Petri 網論，這一年被視作 Petri 網的誕生之年。1970 年以後，Petri 又將他的網論發展為通用網論。現在，世界各地有許多科研人員專註於 Petri 網的研究，每年都舉行 Petri 網國際會議。

Petri 網含有五個基本元素：

• place（庫所）
  一般用圓圈表示，可以形容為容納標碼的場所。它可以有容量限制也可以假設為容量無窮大。
• transition（變遷）
  一般用矩形或者一條短線表示，描述了從一個狀態到另一狀態的變化。變遷的發生是發生一般是原子性的，即不可中斷。
• arc（有向弧）
  一般用一段有向弧表示，從庫所指向變遷或者由變遷指向庫所，表徵了兩者之前一種偏序關係。弧上可以設定權值大小，即一次性消耗的資源數目。
• token（標碼）
  即網系統中的資源，標碼的數目即資源數。在活的網系統中，資源可以在庫所變遷中不斷流動。
• marking（標記）
  記錄了 Petri 網中 token 的分布情況，描述了 Petri 網的狀態。

第 2 章 軟體流程定義語言

2.1 SPDL 概述

軟體流程定義語言 —— SPDL 是一種面向軟體過程建模者、以活動為中心的模型定義語言。它具有如下特徵：

• 涵蓋了軟體過程所涉及的基本元素，對這些元素的關聯、功能、資訊進行了描述
• 能夠對軟體過程中的活動進行並行描述
• 能夠對軟體過程中涉及的角色進行統一的職責描述，定義各角色的許可權
• 使用 XML 作為過程模型描述載體，具有良好的可讀性與互通性

2.2 SPDL 元模型

元模型（meta-model）是用來定義語義模型的構造（construct）和規則（rule）的，通常稱為定義表達模型的語言的模型[1]。軟體過
程定義語言 —— SPDL 的元模型是用於描述軟體過程模型中的各個元素、元素之間的關係以及元素屬性的。
對象管理組織（OMG）使用元對象設施（Meta-Object Facility, MOF）對 UML 進行元模型建模[4]。MOF 是一個 4 層體繫結構的模型驅動工程[5]， 如：
圖 2.1 MOF 模型

在 M3 層中，MOF 定義了最基本的元元模型；在 M2 層中，使用了 MOF 定義的元元模型定義了 UML 元模型；在 M1 層中，使用了
UML 元模型進行軟體模型建模；在 M0 層中，將建模好的軟體模型進行執行個體化，該執行個體描述了真實世界中的對象。

效仿 UML 的元模型建模方法，得出 SPDL 元模型建模體繫結構如：
圖 2.2 SPDL 模型

在 M3 層中，XML Schema[15] 定義了最基本的元元模型；在 M2 層中，使用了 XML Schema 定義的元元模型定義了 SPDL 元模型；在 M1 層中，使用了 SPDL 元模型進行軟體過程模型建模；在 M0 層中，將建模好的軟體過程模型進行執行個體化，該執行個體描述了真實世界中的軟體過程執行個體。
是 SPDL 的類設計（為簡潔起見，所有類圖都隱去了屬性以及操作）

圖 2.3 SPDL 類圖2.2.1 XML Schema

附錄1
2.3 模型變換

2001 年，對象管理組織（OMG）提出了 MDA[2] 開發的概念，其中提到下面兩種類型的模型：

• PIM（平台獨立的模型，Platform Independent Model）
  此類模型不與任何具體特定的平台技術相關。例如，當我們在討論 SPDL 概念時，我們只關心什麼是流程定義、什麼是活動定義、什麼是任務定義，而不會去關心 SPDL 的支撐環境是如何?這些概念。

• PSM（平台特定的模型，Platform Specific Model）
  此類模型非常重視給定平台的特殊性與平台的能力，讓模型變換以及代碼產生成為可能。例如，一個銀行應用的 PIM 可以使用 UML 來建模，然後變換這個 PIM UML 模型到 PSM Java EJB 模型以及產生絕大部分的 Java 代碼。

給出了從一種模型變換成另一種模型的原理概要：

圖 2.4 模型變換原理概要2.3.1 SPDL 域到 Java 域的變換

一個 SPDL 的執行個體是一個 XML 文檔，它描述了一個軟體過程模型。當 SPDL 執行個體部署到支撐環境中時，必須解析並產生相應的一些 Java 對象，以方便操作，例如進行 Petri 網圖的產生，過程模型與過程的關聯等。
在實現從 XML 領域到 Java 領域的模型變換時，JAXB 2.0（JSR 222）[7] 提供了規範的方法，給出這個變換處理的原理概要：

圖 2.5 JAXB 2.0 原理概要2.3.2 SPDL 執行個體的 Petri 網圖產生

Petri 網可以從兩個層次去描述，一是靜態層次，即 Petri 網圖；二是動態層次，即標記網。本節主要闡述 Petri 網圖及其產生。
下面給出 Petri 網圖的形式定義及其基本術語。
定義 1.1[3] 如果三元組 (S, T, W) 稱為一個 Petri 網圖，那麼

• S 是庫所的有限集合
• T 是變遷的有限集合
  
• S ∪ T ≠ Φ，且 S ∩ T = Φ
• W: (S × T) ∪ (T × S) → N 為弧的多重集

流關係是弧的集合：F = {(x, y) | W(x, y) > 0}。在一些介紹 Petri 網相關文獻中，弧的重度只定義為 1，並在定義 Petri 網圖時使用 F 代替了 W。

定義 1.2[3] 設 N = (S, T, F) 為一個 Petri 網圖，x ∈ S ∪ T，則

• .x = {y ∈ S ∪ T | (y, x) ∈ F}
• x. = {y ∈ S ∪ T | (x, y) ∈ F}
• .x.＝ .x ∪ x.

其中，.x 稱為 x 的前提，x. 稱為 x 的後提，.x. 稱為 x 的前後提。

根據定義 1.1， Petri 網圖的 UML 建模如下：

圖 2.6 Petri 網圖類圖

根據 SPDL 的元素結構，可以將其定義的軟體過程模型分為如下三種基本結構：

1. 順序結構
2. 選擇結構
3. 並行結構

在實際的軟體過程建模中，一般需要組合這三種基本結構從而定義出實用的軟體過程模型。
2.3.2.1 基元塊

基元塊使用 Petri 網刻畫了 SPDL 過程模型中的基本結構。基元塊有以下幾類：

1. 順序塊
   刻畫了活動 ei 與 ej 是依次串列進行的，。
   
   圖 2.7 順序塊

2. 選擇塊
   刻畫了活動 ei 與 ej 是有選擇地進行，。
   圖 2.8 選擇塊

3. 並行塊
   刻畫了活動 ei 與 ej 是並行進行的，。
   圖 2.9 並行塊

2.3.2.2 Petri 網圖產生 根據 SPDL 執行個體產生的 Petri 網圖中，庫所用於存放標碼，一個標碼描述了一個過程執行個體；變遷描述了 SPDL 活動，活動的完成將導致變遷的點火，從而引起標碼的移動。
下面各圖分別展示了順序、選擇與並行結構的 Petri 網圖產生執行個體。

• 順序結構圖 2.10 順序結構的 Petri 網圖產生

• 選擇結構圖 2.11 選擇結構的 Petri 網圖產生

• 並行結構
  在進行並行結構的 Petri 網圖產生時，將產生 Join 庫所隊列結構。這個結構是一個順序塊，其中庫所的個數與變遷的個數都等於並行活動個數 － 1。

圖 2.12 並行結構的 Petri 網圖產生

2.4 基於 SPDL 的軟體過程建模方法

基於 SPDL 進行軟體過程建模時有兩種基本策略：

1. 自頂向下
   從過程開始建模，發現過程模型中所需要的活動不存在時進行活動建模、任務建模等。
2. 自底向上
   從參與者、屬性等開始建模，最後將這些實體組合成過程。

這兩種策略在建模時是交替使用的，自頂向下的策略可以看作是對過程建模的逐步精化；自底向上的策略可以看作是對流程元素的複用。
下面是基於 SPDL 的軟體過程建模方法的 UML 使用案例圖。
圖 2.13 建模方法 UML 使用案例圖

是基於 SPDL 的軟體過程建模方法的 UML 活動圖表。

圖 2.14 建模方法 UML 活動圖表

第 3 章 軟體過程執行控制
3.1 過程生存周期

過程是從無到有的，首先經過過程建模，得到一個原始的過程模型。該過程模型部署後執行時將得到過程執行個體，在過程執行個體的執行期對其進行監控，並針對過程執行中的資料、問題進行分析，可以得到一個改進的過程模型，最終將原始的過程模型進行重建模，並反覆這個過程。
綜上，軟體過程是動態，根據過程執行的反饋，按需修改過程模型，達到進一步提高軟體生產率的目標。軟體過程的生存周期如所示。

圖 3.1 軟體過程生存周期3.2 過程執行控制

SPDL 為建模者提供了一種軟體過程模型的定義語言。在軟體過程模型執行個體化出一個軟體過程後必須精確地控制其執行，而基於 Petri 網的過程式控制制正是解決這一問題的有效途徑之一。
在執行的過程中，活動的完成將導致過程的完成或者導致下一個活動的建立，該執行控制是基於 Petri 網進行控制的。在一次點火後，將改變過程狀態，產生新的活動，如所示。

圖 3.2 過程執行控制概覽3.2.1 標記網初始化

標記網用於描述 Petri 網圖的狀態的，在軟體過程支撐環境中用於描述過程的狀態。
下面給出標記網的形式定義及其基本術語。

定義 1.3[3] 設 N = (S, T, F) 為一個 Petri 網圖，∑ ＝ (S, T, F, M) 稱為一個標記網，其中

• M ⊆ S，稱為 N 的一個標記或一個瞬態
• 若 S ∈ T，且 .x ⊆ M，x. ∩ M ＝ Φ，稱事件 x 為可觸發的
• 若事件 x 被觸發（稱為點火），則標記網 ∑ 轉化為 ∑' = (S, T, F, M')，其中 M' = (M - .x) ∪ x.，M' 也是 N 的一個標記，∑' 也是一個標記網

使用一個給定的過程模型執行個體化一個過程時就是在與給定的過程模型對應的 Petri 網圖中初始化一個標記網的過程。
過程執行個體化的 UML 時序圖如下：

圖 3.3 過程執行個體化 UML 時序圖

3.2.2 點火控制

當一個過程執行時，其中某一個活動滿足了其完成條件時將觸發一次對應此活動的變遷的點火。如果點火順利完成，則相關標碼也會被成功移動，並產生對應的活動或結束整個過程。
根據基元塊類別，可以將點火控制分為如下三類：

1. 順序塊點火
2. 選擇塊點火
3. 並行塊點火

在控制這三種基本結構中的變遷點火時都基於如下步驟概要：

1. 檢查變遷的點火條件是否滿足，如果滿足進行步驟 2；如果不滿足則退出點火
2. 在輸入庫所中根據需要完成活動所在的過程選出對應標碼將標碼
3. 從輸入庫所移到輸出庫所，即進行點火

下面各圖分別展示了順序塊、選擇塊與並行塊的點火控制執行個體。

• 順序塊點火
  
  圖 3.4 順序塊點火

• 選擇塊點火

  圖 3.5 選擇塊點火（1）點火 Activity 1[Choice]，說明在過程執行時選擇了 Activity 1。

  圖 3.6 選擇塊點火（2）

• 並行塊點火
  在完成 Start Activity 活動時將引起其相關聯的 Petri 網的執行：與這個完成活動的過程相關聯的標碼將與 Start Activity[Start] 庫所移動到 Fork 庫所。

  圖 3.7 並行塊點火（1）

  當標碼移動到 Fork 庫所時，自動進行一次 Fork 變遷點火。

  圖 3.8 並行塊點火（2）

  當
  各並行的活動之一完成時，其對應的變遷的輸入庫所中的標碼將被移動到 Join 輸出庫所。此時，變遷 Activity 2
  是不能被點火的，如果活動 Activity 2 在這個時刻完成，其對應的變遷 Activity 2 的點火將在變遷 Join 自動點火後進行。

  圖 3.9 並行塊點火（3）

  當標碼移動到 Join 庫所時，自動進行一次 Join 變遷點火，使得這一標碼進入 Join 庫所隊列中。如果並行活動個數為 n，則在這個庫所隊列中進行（n - 2）次點火，使得標碼移動到隊列的尾部庫所（Join Queue n-1）。

  圖 3.10 並行塊點火（4）

  當各並行的活動之一完成時，其對應的變遷的輸入庫所中的標碼將被移動到 Join 輸出庫所。此時，若不能進行變遷 Join 點火，說明所有的並行活動已經完成，因為 Join 庫所隊列已經放置滿了標碼。
  圖 3.11 並行塊點火（5）
  並行活動已完成後，點火 Join 庫所隊列隊尾變遷，結束整個並行塊。
  圖 3.12 並行塊點火（6）

3.3 曆史追蹤
過程是動態，其狀態隨著過程執行而變化，所以必須記錄每次過程狀態的變化。通過對曆史的追蹤，可以得到很多重要的資料，對這些資料進行挖掘整理，有助於對過程模型的演化提供資訊，並可以提供專案管理所需的必要資料。
根據軟體過程的結構[6]，將記錄分為如下三個部分：

1. 過程曆史
   記錄了過程在某一操作發生時的關鍵資料。例如過程建立 / 完成，過程的活動執行路徑，優先順序變更等。
2. 活動曆史
   記錄了過程中的活動在某一操作發生時的關鍵資料。例如活動建立 / 完成，活動所有者變更等。
3. 任務曆史
   記錄了活動中的任務在某一操作發生時的關鍵資料。例如任務建立 / 完成，參與者、優先順序變更等。

第 4 章 軟體過程支撐環境設計
4.1 BeyondTrack 項目簡介

ByondTrack 是一個基於
JavaEE 平台的 B/S
結構的軟體過程支撐環境。在該環境下，使用者可以進行：

• 可視化的軟體過程建模
• 自定製過程變數
• 過程變數粒度的許可權管理
• 過程任務、參與者管理
• 基於 Wiki 的文件管理
• 追蹤過程事件曆史

4.2 體繫結構設計

BeyondTrack 項目涉及到的主要技術以及相應的使用方式如下：

• 在 SPDL 處理上使用 JAXB 2.0（JSR 222）
• 在應用程式框架上使用 JBoss Seam 架構[8]（2.1.1.GA），該架構為 Java Context and Dependency Injection（JSR 299）[9]的超集實現
• 資料庫持久化方面使用 JPA 1.0 （a part of JSR 220）[10]的 Hibernate[14] 實現，使用 Seam 託管的實體管理與交易管理
• 表現層選擇了 JSF 1.2（JSR 252）[11]的 RichFaces[12] 實現，以 Facelets[13] 作為 JSF 視圖定義架構

這裡簡述一下選擇 JBoss Seam 架構的原因：

• 優秀的組件範圍與組件生存周期管理
• Annotation-based 組件配置，架構配置非常簡潔
• 整合了很多應用功能，例如規則引擎、工作流程引擎、PDF 產生等
• 是一個 full-stack 的應用程式框架，提供了表現層、商務邏輯層與資料持久化層的整體解決方案
• 是 Java 企業級應用程式框架的"准規範"

高層組件設計如下：

圖 4.1 BeyondTrack 組件設計

高層包設計如下：

圖 4.2 BeyondTrack 包設計

結論

軟
件過程模型是軟體項目進行可控實施的基本保證，一個優良的、項目規模適用的軟體過程元模型是軟體過程模型建模的必要條件。使用 SPDL
能夠描述簡單的（順序 / 選擇 / 並行）軟體過程模型，並在 BeyondTrack
系統中得到過程建模、部署、執行、最佳化全生存周期的全支撐，在一定程度上提高了軟體開發效率。 在進一步的工作中，將繼續完善 SPDL
元模型，使之能夠描述更複雜的軟體過程（例如子過程），並加入對活動變遷條件的定義，使之在基於 Petri
網的過程執行控制時能夠自動或半自動地進行。

致謝

在此衷心感謝我的導師李彤博士，正是有了他辛勤的工作，細心的指導和嚴格的要求，才有了本篇論文的順利完成。
感謝金峰軟體公司，在那裡我學習到了很多學校裡學不到的軟體工程實踐與經驗。
感謝 BeyondTrack 項目組的成員，大家一起齊心協力，成功地完成了這個項目。這裡特別感謝趙禹同學，他給出了很多細心的建議，在項目實現上也盡心盡責。
最後感謝家長控制，是你們深情的教誨和無微不至的關懷，才有了我今天的成績，對你們的感激之情無論用多少語言都無法表達！
參考文獻

[1] Rumbaugh J, Jacobson I, Booch G. The Unified Modeling Language Reference Manual. Addison
Wesley Longman, Inc., 1999
[2] OMG. MDA Guide Version 1.0.1, document no: omg/2003-06-01, 2003
[3] 李彤, 孔兵, 王黎霞等. 軟體並行開發過程. 北京:科學出版社, 2003
[4] http://en.wikipedia.org/wiki/Metamodeling
[5] http://en.wikipedia.org/wiki/Model-driven_engineering
[6] ISO/IEC 12207, SOFTWARE LIFE CYCLE PROCESSES
[7] JSR 222, JavaTM Architecture for XML Binding (JAXB) 2.0
[8] http://www.seamframework.org
[9] JSR 299, Web Beans
[10] JSR 220, Enterprise JavaBeansTM 3.0
[11] JSR 252, JavaServer Faces 1.2
[12] http://www.jboss.org/jbossrichfaces
[13] http://facelets.dev.java.net
[14] http://www.hibernate.org
[15] http://www.w3.org/XML/Schema
[16] http://www.omg.org/technology/documents/formal/spem.htm
[17] 基於SPEM的CMM軟體過程元模型, 2005 Journal of Software, Vol.16, No.8

附錄

1 SPDL XML Schema

狀態：草稿 日期：2009 年 4 月 22 日 作者：丁亮