作業: 作業設計
這項作業將「操作分析」的結果提煉成詳細的「操作實現」。
規範: 分析 設計
目的
  • 將初步的子系統互動提煉成「設計模型」中的「操作實現」。
  • 修正和指定「子系統操作」。
關係
角色主要執行者: 其他執行者:
輸入強制: 選用:
輸出
流程用法
步驟
建立操作實現

作業:操作分析中,「設計師」在「分析模型」中建立子系統互動(不太仔細)。 回想一下,您已處理過這些互動的粗細度,並依「系統操作」來分組,亦即,您已捕捉到實現每一個「系統操作」的互動。 現在,開始處理展開的(白箱)系統使用案例說明,加入訊息的細節、交換的實體、順序安排、控制流程及相關的資料, 並在「設計模型」中捕捉產生的「操作實現」,同樣依「系統操作」來組織。 由於加入這項詳細資料,「設計師」可以評估緊急合作的品質,利用機會來重新建構設計。 在「操作實現」上註明子系統在處理訊息時要做什麼(必要的話,引用白箱步驟的說明再修正)。 這些說明有利於下一步開發每一個「系統操作」的規格。

聚集類似的子系統白箱步驟並指定子系統操作

「設計師」在「操作分析」作業期間已保留初步「子系統操作調查」的位置。 調查表也顯示(灰色背景)向後溯及系統使用案例黑箱步驟的可追蹤性, 指出(在表格中)系統使用案例黑箱步驟 <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> ... ...   ...  
... ... ... ...   ...  

子系統操作調查範例。

接下來,從白箱步驟和「操作實現」開始,找出「子系統操作」並指定行為。 如同確認系統操作一樣,每一個白箱步驟可能沒有唯一的子系統操作; 亦即,當您檢查白箱步驟及其相關的訊息交換、輸入/輸出實體等組合時, 可能會發現也許定義一組較小的「子系統操作」即可滿足需求。

請注意,調查表也可以依位置或流程來重新分組,藉以顯示一組「子系統操作」與每一個位置或每一個流程的關聯。 位置分組可以指出某一個位置的運算負荷(所以很適合推論支援此位置的實體元件的產能)。 由此可知,依位置分組的調查會成為「部署模型」的一項內容。

當一個「子系統操作」在多個位置上執行時,這表示至少會抄寫子系統的一部分。 但並不表示這些抄寫部份一定共同資料或保持同步化。 這些是設計決策的問題,取決於抄寫的運用和理由而定; 例如,所需的處理可能相同,但出現在不同的商業區段。 以極端的情形而言,一個子系統的所有操作可以在多個位置上執行,這表示實際上是抄寫子系統本身。 是否需要唯一地指定抄寫實例,也取決於抄寫的理由。

流程分組可讓「設計師」推論並行性議題:假設您將一項「子系統操作」視為參與者可用的一段獨立功能, 乍看之下,同一個流程的相關操作不能同步執行。 這可能導致「設計師」重新考量流程分配、考量流程抄寫, 或大致地檢查感受的延遲問題(例如,透過檢查時間分割選項)和操作堵塞時的流程共用(例如,執行輸入-輸出)。 這些技術可以達到令人滿意的回應性,但可能還是無法忍受操作開始時的延遲現象(嚴格序列化操作)。 由此可知,依流程分組的調查會成為「設計模型」的一項內容。

註解說明已達到的目的

對於每一個子系統,您已經:

  • 定義操作
  • 定義您希望子系統支援的介面
  • 描述子系統之間如何分工合作來實現系統使用案例
  • 定義子系統的環境:參與者、介面及 I/O 實體

到此一切就緒,您可以提交這組工作成果來進入獨立開發,或重新呼叫 RUP「需求」規範的作業,遞迴地執行進一步的分解。

詳細資訊