「設計師」在「操作分析」作業期間已保留初步「子系統操作調查」的位置。 調查表也顯示(灰色背景)向後溯及系統使用案例黑箱步驟的可追蹤性, 指出(在表格中)系統使用案例黑箱步驟 <id 1> 和 <id 2> 都由
<system operation name 1> 的呼叫來執行。
子系統 <name>
|
系統操作
|
系統使用案例黑箱步驟 ID
|
位置
|
流程
|
工作者
|
子系統白箱步驟說明
|
子系統操作
|
<system operation name1>
|
<id 1>
|
位置 ID
|
流程 ID
|
組織或系統工作者 ID
|
(白箱步驟 ID):子系統以輸入、處理、輸出方式執行的動作的說明(黑箱步驟的執行部分)
|
(子系統操作
ID):此步驟呼叫的子系統操作的名稱,例如, "«subsystem operation» 開始處理銷售清單"(用於子系統訂單處理)
|
...
|
...
|
|
(白箱步驟 ID):...
|
|
...
|
...
|
|
...
|
|
<id 2>
|
...
|
...
|
|
...
|
|
<system operation name2>
|
<id 3>
|
...
|
...
|
|
...
|
|
<id 4>
|
...
|
...
|
|
...
|
|
...
|
...
|
...
|
...
|
|
...
|
|
子系統操作調查範例。
接下來,從白箱步驟和「操作實現」開始,找出「子系統操作」並指定行為。 如同確認系統操作一樣,每一個白箱步驟可能沒有唯一的子系統操作; 亦即,當您檢查白箱步驟及其相關的訊息交換、輸入/輸出實體等組合時,
可能會發現也許定義一組較小的「子系統操作」即可滿足需求。
請注意,調查表也可以依位置或流程來重新分組,藉以顯示一組「子系統操作」與每一個位置或每一個流程的關聯。 位置分組可以指出某一個位置的運算負荷(所以很適合推論支援此位置的實體元件的產能)。
由此可知,依位置分組的調查會成為「部署模型」的一項內容。
當一個「子系統操作」在多個位置上執行時,這表示至少會抄寫子系統的一部分。 但並不表示這些抄寫部份一定共同資料或保持同步化。 這些是設計決策的問題,取決於抄寫的運用和理由而定;
例如,所需的處理可能相同,但出現在不同的商業區段。 以極端的情形而言,一個子系統的所有操作可以在多個位置上執行,這表示實際上是抄寫子系統本身。 是否需要唯一地指定抄寫實例,也取決於抄寫的理由。
流程分組可讓「設計師」推論並行性議題:假設您將一項「子系統操作」視為參與者可用的一段獨立功能, 乍看之下,同一個流程的相關操作不能同步執行。 這可能導致「設計師」重新考量流程分配、考量流程抄寫,
或大致地檢查感受的延遲問題(例如,透過檢查時間分割選項)和操作堵塞時的流程共用(例如,執行輸入-輸出)。 這些技術可以達到令人滿意的回應性,但可能還是無法忍受操作開始時的延遲現象(嚴格序列化操作)。
由此可知,依流程分組的調查會成為「設計模型」的一項內容。
|