Figure 3.9 WorkflowConstraint syntax
在 WorkflowConstraint 此節點下有眾多不同的條件限制，以下簡述他的功 用：
flowInstanceNumber：此標籤內容的限制是描述一個 Workflow 的最大實體 化數目，具體的例子可以由 Figure 3.2 來描述之，當一個處室的行政人員有限 下，系統開發者可能自行撰寫相對應的限制在他的系統中，此時透過此標籤的描 述，測試平台可以協助監控系統內真正運行所有由該 Workflow definition 所實 體化的 Workflow processes 數目，此標籤有一個 max 的屬性，內容只能填寫數 字，而此標籤的內容是填寫 Flow 的名稱，用來指定這個條件用在哪個 Flow 上，
Table 3.17 是一個撰寫的範例。
Table 3.17 Structure of constaint with type = flowInstanceNumber
<FlowInstanceNumber max="3">flowNameA</FlowInstanceNumber>
interflowInstanceNumber：此標籤內容的限制是描述多個不同的 Workflow definitions 的最大實體化數目，具體的例子可以由 Figure 3.2 以及 Figure 3.3 此兩流程來描述，如果此兩個流程使用相同的行政人員，此時系統開發者可能自 己 撰 寫 方 法 來 限 定 兩 個 流 程 同 時 實 體 化 的 最 大 數 目 ， 若 要 測 試 這 樣 的
37
Application，我們可以藉由定義此項標籤內容來協助監控真正系統上實體化的 數目。此標籤有一個 max 的屬性，內容只能填寫數字，而此標籤的內容是填寫 flow 的名稱，用來指定這個條件用在哪個 flow 上，Table 3.18 是一個撰寫的範例。
Table 3.18 Structure of constaint with type = interflowInstanceNumber
<FlowInstanceNumber max="3">flowNameA, flowNameB
</FlowInstanceNumber>
executionOrder：此標籤內含三個屬性，分別為 Before, After, Current，
表是三個不同的 Activity 間的順序，而此標籤的內容僅能填入描述限制的 flow 名稱。此標籤功用是限制 Workflow 內 Activities 間的執行順序，當開發者想測 試自己撰寫的流程有沒有問題時，他可以藉由詳細的撰寫這項標籤來測試自己寫 的流程定義是否有誤，我們使用 Figure 3.2 來描述此標籤作用，A1 這個 Activity 是負責登入的動作，所以無論如何他都必須要在 A2 前執行，假若開發者在寫他 的流程定義檔時將 A2 寫在 A1 前執行，如此一來我們可以利用此屬性的功能來設 定我們的 Constraint，架構如 Table 3.19 所述。以下簡介此標籤的屬性作用：
Table 3.19 Structure of constaint with type = executionOrder
<ExecutionOrder before="beforActivity" after="afterActivity"
current="currentActivity">flowName</ExecutionOrder>
Before：相對於 Current 之前一個 Activity，可填入名稱為 Activity 名稱。
Current：現在執行到的 Activity 名稱，可填入之值為 Activity 名。
After：相對於 Current 所描述的 Activity 之後的下一個 Activity，可 填入的值為 Activity 名稱。
singleActivityExecutionCount ： 此 標 籤 含 意 是 測 試 指 定 之 Workflow definition 內個別 Activities 的總共被執行個數，我們使用 Figure 3.2、Figure 3.3 來舉例，Figure 3.2 的流程裡 A4 這個 Activity 是負責撰寫電子公文，若此
38
系統有限定一天最多能送件的公文數目，則系統開發者可以藉由使用此標籤來撰 寫這樣的條件，如此測試平台即可協助監控，具體的範例如 Table 3.20 所示。
此標籤的值只能填入流程名稱，且他有三項屬性，分別在以下描述之：
maximun：最大的執行次數限制，只能填入數字。
minimun：最小的執行次數限制，只能填入數字。
activity：受限制的 Activity 名稱。
Table 3.20 Structure of constaint with type = singleActivityExecutionCount
<SingleActivityExecutionCount maximun="INT" minimun="INT"
activity="ActivityName">FlowName</SingleActivityExecutionCount>
Loop：此標籤含有四個屬性，分別為 Maximum, Minimum, Start, End，此 標籤內容是填寫受限制的 flow 名稱，他的屬性含意解釋如下：
Maximum：受限制之迴圈最大的次數，只可填入數字。
Minimum：受限制之迴圈最大的次數，只可填入數字。
Start：描述開始的 Activity 是哪一個，內容只能填入 Activity 名稱。
End：描述結束的 Activity 是哪一個，內容只能填入 Activity 名稱。
此標籤用來測試同一個 Workflow 裡面 Activity 間循環執行次數，使用 Figure 3.2 為範例，A1 的行為是登入，如果登入錯誤他會一直回到自己，此時 我們可以用此標籤描述限制登入次數最多幾次，然後與實際程式下去測試，除了 單一的 Activity 的循環外，也可以測試不同 Activity 間的循環，比如 A1 和 A2，
系統開發者可能會要限定同一個 Session 內最大只能註冊一個帳號，此時我們就 由此標籤可以讓測試系統來協助系統開發者做監控，其架構如 Table 3.21 所示。
Table 3.21 Structure of constraint with type = Loop
<Loop maximum="5" minimun="0" start="anotherActivity"
end="someActivity">flowName</Loop>
ResourceLimitation：此標籤用來描述 Activity 開始與結束時之資源限制，
標籤內容必須填入受限制之 Flow 名稱，其屬性簡介如下：
39
ActionOn：描述此資源限制的檢查時間，此屬性只能填入 EndACT, StartACT 兩種資訊。
Type：此屬性用來描述系統發展者所欲限定之資源類型，且此值必須和 Resource 節點內的 Type 屬性值一致，否則 Resource manager 會回報找 不到該項資源。
Name：此屬性用來描述系統發展者所欲限定之資源名稱，此值必須和 Resource 節點內的 Name 子節點的值一致，否則會找不到資源。
Lower：此屬性描述此項資源最少的數量，內容只能填入數值。
Upper：此屬性描述此項資源最大的數量，內容只能填入數值。
Activity：此屬性描述被限制的 Activity 名稱，內容必須填入 Activity 名稱。
此標籤旨在描述 Activity 啟動時，可能會有最少需求的實體資源需要 存在且可利用，藉由此屬性可以用來明確檢驗，具體的範例可使用 Figure 3.3 內的 A3 來解釋，A3 的啟動需要一個行政人員以及交通車的參與，系統開發 者可能自己有撰寫監控的相關程式，此時藉由測試平台所提供的此項標籤，
系統開發者將得以測試他所設定的條件限制是否執行正確。其架構如 Table 3.22 所示。
Table 3.22 Structure of constraint with type = resourceLimitation
<ResourceLimitation actionON="startACT" type="car" name="audi"
lower="0" upper="5"
activity="ActivityNameA">flowNameA</ResourceLimitation>
<ResourceLimitation actionON="endACT" type="car" name="B.M.W"
lower="2" upper="5"
activity="ActivityNameB">flowNameA</ResourceLimitation>
ActivityExecutionTimeDuration：此標籤用來描述一個 Activity 開始與結 束時之間的執行時限制，標籤內容必須填入受限制之 flow 名稱，其屬性簡介如 下：
Activity：描述受限之 Activity 名稱。
Duration：描述執行時間，只能填入數字。
40
此標籤使用的具體範例可由 Figure 3.3 內的 A4 來描述，A4 是 A3 執行完後 便會啟動的 Activity，他的終止條件是行政人員送件結束後必須回來登記，系統 開發者可能自行撰寫了這個 Activity 最大運行時間以便偵測此 Activity 的正確 性，此時他可以藉由撰寫此標籤的語法來利用測試平台測試他的條件限定的正確 性。撰寫範例如 Table 3.23 所示。
Table 3.23 Structure of constraint with type = ActivityExecutionTimeDuration
<ActivityExecutionTimeDuration activity="A4" duration="30">電子送件系
</ActivityExecutionTimeDuration>
ActivityExecutionDeadlineTime：此標籤用來描述一個 Activity 執行結束 時間的執行時限制，標籤內容必須填入受限制之 Flow 名稱，其屬性簡介如下：
Activity：描述受限之 activity 名稱。
deadlineTime：描述某一個執行日期。
我們使用 Figure 3.2 的 A4 以及 Figure 3.3 的 A3 作為範例，一個行政人員 可能都是在固定時間統整所有公文再寄出，此時系統開發者可能會在 Figure 3.2 的 A4 內撰寫最晚執行結束的時間點，比如是下午的兩點半前，超過該時間後所 撰寫的公文將會在隔天才被 Figure 3.3 的 A3 寄送，系統開發者可以藉由撰寫測 試平台所提供的語法來協助測試他的條件限制是否有誤\，撰寫範例如 Table 3.24 所示。
Table 3.24 Structure of constraint with type = ActivityExecutionDeadlineTime
<ActivityExecutionDeadlineTime activity="ActivityNameA"
duration="INT">FlowName</ActivityExecutionDeadlineTime>
簡介完所有條件限制語法後，我們使用實際範例更進一步的將整區段寫法表 達出來，以下是 WorkflowConstraint 可能的描述方式：
Table 3.25 example of WorkflowConstraint tag in TS-WfMS
41
<WorkflowConstraint>
<FlowInstanceNumber max="3">flowNameA</FlowInstanceNumber>
<ExecutionOrder before="beforActivity" after="afterActivity"
current="currentActivity">flowName</ExecutionOrder>
<Loop maximun="5" minimun="0" start="anotherActivity"
end="someActivity">flowName</Loop>
<ResourceLimitation actionON="startACT" type="car" name="audi"
lower="0" upper="5"
activity="ActivityNameA">flowNameA</ResourceLimitation>
<ResourceLimitation actionON="endACT" type="car" name="B.M.W"
lower="2" upper="5"
activity="ActivityNameB">flowNameA</ResourceLimitation>
<ActivityExecutionDeadlineTime activity="ActivityNameA"
duration="INT">FlowName</ActivityExecutionDeadlineTime>
<ActivityExecutionTimeDuration activity="ActivityNameA"
duration="INT">FlowName</ActivityExecutionTimeDuration>
<SingleActivityExecutionCount maximun="INT" minimun="INT"
activity="ActivityName">FlowName</SingleActivityExecutionCount>
</WorkflowConstraint>
上面所描述的所有條件限制會在 Figure 1.8 所描述的三種不同測試策略中 進行，藉由在不同的執行環境下，我們的測試平台得以更精確的告知使用者錯誤 發生的地點。
3.2 Agent
Agent 是負責自動測試程式與 WfMS 溝通的橋梁，當 WfMS 開始測試後，他必 須根據目前運行的流程名稱，以及 Activity 名稱，動態的從 TS-WfMS 中讀取該 次輸入與輸出的相關資訊。Agent 除了擔負與 WfMS 溝通的責任外，同時還必須與 Resource Manager 的進行互動(Table 3.26 中的 ParticipantAction 標籤)，最 後將從 WfMS 收集到的輸出送回 Execution Collector 進行最後步驟的驗證。
42 WfMS