工作成果: 操作
這個構件代表可向物件要求來影響行為的一項服務。操作會指定名稱、類型、參數及限制來呼叫相關的行為。
目的

「操作」的主要目的是擷取一項元素所支援或需要的供應服務和需求服務。

關係
角色負責: 修改者:
輸出來源
主要說明

操作規格的概要如下:

  • 說明
  • 輸入/輸出參數
  • 非功能面需求:
    • 衍生自這項操作所支援的各種「使用案例」中的步驟相關的非功能面需求。
    • 可能無法擷取到使用操作的環境(亦即特定的「使用案例」),例如在考量「使用案例」時,可能指定為支援最低效能需求
  • 前置條件
  • 後置條件
  • 卓越的系統追蹤性
  • 選用:使用案例(步驟)追蹤性

在大多數情況下,開發中的系統和主要的子系統會定義「操作」,並且視情況來遞迴地深入分解。「操作」依據介面及目前考量的(子)系統的主要責任來分組。

視精細程度和使用環境而定,不同的角色會指定、定義、修正或使用操作,做為相關作業的主要輸入:

  • 架構設計師描述重大架構性元素所支援的主要服務。
  • 分析師架構設計師共同合作將使用案例步驟對映至系統的操作。
  • 設計師將操作當做修正和重構階段的輸入,操作成為「介面設計規格」的建置區塊。
  • 測試人員根據指定的操作來衍生測試案例。
  • 管理人員以操作為基準來規劃階段和反覆。
內容
選用
規劃Yes
主要考量
「設計師」負責操作集的完整性,確保:
  • 操作是唯一的,彼此不重疊
  • 在邏輯上根據介面將相關的操作分組
  • 適當地記載每一個操作
  • 已建立對其他操作及/或使用案例步驟的可追蹤性關係
  • 在現行反覆的範圍內,使用案例或系統的操作達到適當的涵蓋率
調整
表示法選項

在定義系統及主要子系統支援的服務時,以操作為主的方法是較為正式、嚴格的方法。 通常從系統使用案例著手,因此,已假設操作和使用案例會一起使用。

主要的調整決策如下:

  • 只描述架構面重大的操作嗎(與最重要的使用案例有關的操作)?
  • 子系統邏輯分解應該達到什麼「深度」?
  • 完整描述前置條件和後置條件嗎?
  • 需要維護操作和系統操作及/或使用案例之間的可追蹤性嗎?

如果需要產生「介面設計規格」,則這些規格包含的操作的詳細程度和正式性,將提升達到可以實作和測試構件的程度。