軟體設計描述(SDD)檔案是軟體開發流程中不可或缺的一環,用於詳述系統設計細節,幫助開發者、測試者和其他相關人員理解系統架構和功能。本文以資料擷取(DAQ)系統為例,說明 SDD 中使用案例、組成、邏輯、相依性等多重視角分析方法,並輔以 UML 圖表,闡述如何透過 SDD 檔案有效提升系統設計品質。DAQ 系統的 SDD 檔案包含多個視角,例如使用案例視角描述了主機與 DAQ 系統間的命令介面互動,並以 UML 使用案例圖呈現;組成視角則以 UML 元件圖展現系統主要模組與元件,例如命令處理、通訊模組等;邏輯視角則使用 UML 類別圖描述系統中類別、介面定義,例如類別比輸入模組的 adcClass_t 類別;最後,相依性視角雖然已不常用,但在舊有 SDD 檔案中仍可能出現,主要描述設計實體間的關係。透過這些視角,SDD 檔案能完整呈現 DAQ 系統的設計細節,方便不同角色的專案成員理解系統架構和功能。

軟體設計描述檔案化:DAQ系統的多重視角分析

軟體設計描述(Software Design Description, SDD)是軟體開發過程中不可或缺的一部分,它提供了系統設計的詳細資訊,有助於開發者、測試人員和其他利益相關者理解系統的架構和功能。本文將以DAQ(資料擷取)系統為例,探討SDD中的多重視角分析。

使用案例視角:DAQ命令介面

DAQ系統的使用案例視角描述了外部系統(主機)與DAQ系統之間的命令介面。圖11-6展示了DAQ命令的使用案例,涵蓋了16個使用案例,每個使用案例都對應於DAQ SRS(軟體需求規格)中的需求。

此圖示描述了主機與DAQ系統之間的互動關係。

內容解密:

  1. 使用案例視角關注系統的功能性需求。
  2. 每個使用案例代表一個特定的功能或操作。
  3. DAQ命令的使用案例涵蓋了系統的主要功能。

組成視角:系統主要元件

組成視角列出了構成系統的主要模組或元件。圖11-7展示了DAQ系統的組成視角,使用簡化的元件圖來描述系統的主要元件。

此圖示描述了DAQ系統的主要元件及其關係。

內容解密:

  1. 組成視角關注系統的整體架構。
  2. 主要元件包括命令處理、監控維護、通訊模組等。
  3. 元件之間的關係透過聚合和組合來描述。

邏輯視角:類別和介面定義

邏輯視角描述了系統中使用的類別、介面和結構定義。圖11-9展示了adcClass_t類別的類別圖,描述了類別比輸入模組的屬性和方法。

此圖示描述了adcClass_t類別的屬性和方法。

內容解密:

  1. 邏輯視角關注系統的類別和介面定義。
  2. adcClass_t類別描述了類別比輸入模組的屬性和方法。
  3. 屬性和方法的定義對於理解系統的功能至關重要。

相依性視角:已棄用的視角

相依性視角是一種已棄用的視角,主要用於描述設計實體之間的關係。雖然在現代設計中不常使用,但仍有可能在舊有的SDD檔案中遇到。

內容解密:

  1. 相依性視角關注設計實體之間的關係。
  2. 在現代設計中,其他視角(如邏輯視角和資源視角)可以更好地描述相依性。
  3. 瞭解相依性視角有助於閱讀舊有的SDD檔案。

軟體設計描述檔案化

軟體設計描述(SDD)是一種用於描述軟體系統設計的檔案。IEEE Std 1016-2009 提供了建立 SDD 的指導方針,定義了多種視角(viewpoints),用於描述軟體系統的不同方面。

11.2.2 各視角的描述

依賴關係視角(Dependency Viewpoint)

依賴關係視角用於描述系統中各元件或模組之間的依賴關係。可以使用 UML 元件圖或套件圖來呈現此視角。套件圖特別適合用於描述套件之間的依賴關係,如圖 11-10 所示。

此圖示顯示了 UI 模組對 sensors 和 clock 的依賴關係。

資訊/資料函式庫視角(Information/Database Viewpoint)

資訊/資料函式庫視角描述了系統中持久化資料的使用。此視角與邏輯視角相似,使用類別圖來呈現資料結構、內容和元資料定義。然而,在現代設計中,此視角已被邏輯視角或資源視角所取代。

模式使用視角(Patterns Use Viewpoint)

模式使用視角用於描述系統中使用的設計模式及其實作。可以使用 UML 複合結構圖、類別圖和套件圖來呈現此視角。

介面視角(Interface Viewpoint)

介面視角描述了系統提供的服務(如 API)。可以使用 UML 元件圖來呈現此視角,如圖 11-11 所示。

此圖示顯示了 Digital I/O 和 Relay output 元件提供的介面。

結構視角(Structure Viewpoint)

結構視角描述了系統中物件的內部組織和建構。可以使用 UML 複合結構圖、套件圖和類別圖來呈現此視角,如圖 11-12、11-13 和 11-14 所示。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title DAQ 系統軟體設計多重視角分析

package "資料視覺化流程" {
    package "資料準備" {
        component [資料載入] as load
        component [資料清洗] as clean
        component [資料轉換] as transform
    }

    package "圖表類型" {
        component [折線圖 Line] as line
        component [長條圖 Bar] as bar
        component [散佈圖 Scatter] as scatter
        component [熱力圖 Heatmap] as heatmap
    }

    package "美化輸出" {
        component [樣式設定] as style
        component [標籤註解] as label
        component [匯出儲存] as export
    }
}

load --> clean --> transform
transform --> line
transform --> bar
transform --> scatter
transform --> heatmap
line --> style --> export
bar --> label --> export

note right of scatter
  探索變數關係
  發現異常值
end note

@enduml

內容解密:

  1. SwimmingPoolMonitor 類別封裝了游泳池監控系統的核心功能和屬性。
  2. 屬性如 curPoolLevelpoolLowpoolHi 用於記錄當前水位和水位狀態。
  3. 方法如 readKpd()getPoolLvl() 用於讀取鍵盤輸入和取得水位資訊。
  4. pumpCtrl(onOff: boolean) 方法控制水泵的開關。
  5. getPoolHiLo(sensor: int) 方法根據感測器輸入判斷水位是否過高或過低。

軟體設計描述檔案(SDD)的組織結構與檢視管理

軟體設計描述檔案(Software Design Description, SDD)是軟體開發過程中至關重要的技術檔案,用於詳細記錄軟體系統的設計架構、功能模組、互動關係及資源使用等資訊。IEEE Std 1016-2009 提供了 SDD 的標準化組織方式,強調透過多重檢視(viewpoints)與檢視(views)來呈現系統設計的不同導向,以滿足不同利益相關者的需求。

設計檢視與視角的定義

在 SDD 中,設計視角(design viewpoint) 定義了觀察和描述系統設計的特定角度或方法,例如情境視角、互動視角和邏輯視角等。每個視角規範了一組相關的設計元素和表達方式,用於滿足特定的設計關注點。相對地,設計檢視(design view) 是根據特定視角所建立的實際設計內容,包含圖表、文字描述和其他相關資訊。

兩者的關係是一對一的,即一個設計檢視對應一個設計視角。設計視角提供了設計的框架和組織方式,而設計檢視則是根據該框架所實作的具體設計內容。例如,情境視角規範了系統與外部環境的互動關係,而對應的情境檢視則透過 UML 圖表和文字詳細描述這些互動。

SDD 的完整性與一致性要求

根據 IEEE Std 1016-2009 的規定,一份完整的 SDD 必須滿足以下條件:

  1. 涵蓋所有需求:每個設計關注點(design concern)至少在一個設計檢視中得到體現。
  2. 元素完整性:包含設計視角所定義的所有實體和關係。
  3. 約束符合性:符合所有施加於設計的約束條件。

此外,SDD 的一致性要求不同設計檢視之間不存在衝突。例如,若某屬性在類別圖中被定義為布林型別,而在活動圖中被當作字串處理,則構成不一致性。

設計覆寫(Design Overlays)的應用

當需要在某個設計檢視中引入其他視角的元素時,可以使用設計覆寫。設計覆寫相當於一種「例外機制」,允許在保持整體視角組織結構的前提下,靈活加入額外的設計資訊。例如,在邏輯視角中加入互動圖以輔助說明邏輯關係。

1 視角 #1
1.1 視角 #1 說明
1.2 檢視 #1
1.3 覆寫 #1
1.4 覆寫 #2
2 等等

內容解密:

  • 視角(Viewpoint):定義觀察系統的角度或方法,例如情境視角、互動視角。
  • 檢視(View):根據特定視角建立的具體設計內容,包含 UML 圖表和文字描述。
  • 覆寫(Overlay):用於在特定檢視中加入其他視角的元素,以增強說明或補充資訊。

這種組織方式使 SDD 能夠根據不同利益相關者的需求進行結構化呈現,提高檔案的可讀性和實用性。

UML 圖表在 SDD 中的應用

在 SDD 中,各類別 UML 圖表扮演著至關重要的角色,用於直觀地表達系統的靜態結構和動態行為。常見的 UML 圖表包括:

  • 類別圖(Class Diagram):描述系統中的類別及其靜態關係。
  • 序列圖(Sequence Diagram):展示物件之間的互動順序。
  • 活動圖(Activity Diagram):描述業務流程或系統操作的工作流程。
  • 狀態機圖(Statechart Diagram):表示物件的狀態變遷。

內容解密:

  • 靜態結構:類別圖用於呈現類別、屬性及它們之間的靜態關聯。
  • 動態行為:序列圖和活動圖分別用於描述物件互動的時間順序和系統操作流程。
  • 狀態變遷:狀態機圖表示物件在不同狀態下的行為及觸發條件。

資源視角與上下文視角的應用

資源視角(Resource Viewpoint)主要關注系統如何利用各種資源,如 CPU、記憶體、儲存和周邊裝置等。在新的 SDD 中,通常建議使用上下文視角(Context Viewpoint)來取代資源視角,以更全面地描述系統與外部環境的互動及資源使用情況。

內容解密:

  • 資源利用:資源視角關注系統對 CPU、記憶體等資源的使用情況。
  • 上下文描述:上下文視角用於描述系統與外部環境的介面及互動關係。
  • 新舊標準差異:IEEE Std 1016-2009 建議在新設計中使用上下文視角取代部分資源視角的功能。

軟體設計描述檔案(SDD)製作

軟體設計描述檔案(SDD)是軟體開發過程中至關重要的技術檔案,詳細記錄了軟體的設計架構、設計元素及設計原理。本文將根據IEEE Std 1016-2009標準,探討SDD的製作內容、結構及追蹤方法。

SDD的關鍵組成要素

1. 設計檢視(Design Views)與視點(Viewpoints)

設計檢視用於描述軟體的不同導向,類別似於UML圖表但不拘泥於特定圖表型別。每個設計檢視必須對應一個設計視點,定義了該檢視的結構和內容。設計檢視之間的關聯性可透過疊加層(Overlays)來擴充套件或修改現有的設計語言。

2. 設計疊加層(Design Overlays)

設計疊加層允許在不改變原有視點的情況下,擴充套件或修改設計語言。這種機制使得設計師能夠混合使用不同的設計語言,或在現有語言不足以滿足需求時進行擴充套件。設計疊加層必須明確標識、命名,並與特定的視點相關聯。

3. 設計原理(Design Rationale)

設計原理闡述了設計決策的背景和理由,通常包含註解、註解以及對不同設計選項的討論。這些資訊有助於其他開發者理解設計的脈絡,並在後續開發中做出正確的判斷。

SDD的可追蹤性與標籤管理

為了實作需求規格書(SRS)與SDD之間的追蹤,需要使用特定的標籤(Tags)。建議使用proj_SDD_xxx形式的標籤,其中xxx為唯一數值。這種標籤機制使得從需求到設計元素的追蹤變得更加容易。

在實踐中,建議將標籤附加到設計檢視或視點上,以避免複雜的多對多關係。這樣可以簡化可追蹤性矩陣(RTM)的建立和管理工作。

SDD的大綱建議

IEEE Std 1016-2009的附錄C提供了一個建議的大綱,用於組織和格式化符合標準的SDD。遵循這個大綱,可以確保SDD包含所有必要的資訊,並且結構清晰易於理解。

此圖示說明瞭軟體設計描述檔案(SDD)的架構與主要元素之間的關係,包括設計檢視、視點、疊加層及原理等核心組成部分,同時展示了與利益相關者、需求規格書及可追蹤性矩陣的關聯。
  1. SDD作為主體,包含了多個關鍵組成部分。
  2. 設計檢視與UML圖表相關聯,用於描述軟體的不同導向。
  3. 設計視點定義了檢視的結構和內容,是理解設計檢視的基礎。
  4. 設計疊加層提供了擴充套件或修改現有設計語言的機制,增強了設計的靈活性。
  5. 利益相關者、需求規格書及可追蹤性矩陣都與SDD密切相關,共同構成了軟體開發過程中的重要技術檔案和管理工具。

軟體設計描述檔案(SDD)解析與實務應用

軟體設計描述檔案(Software Design Description, SDD)是軟體開發過程中不可或缺的檔案之一,主要用於描述軟體系統的設計細節。根據IEEE Std 1016-2009標準,SDD應包含軟體系統的整體架構、模組劃分、介面定義等關鍵設計資訊。本文將探討SDD的結構、內容以及實務應用。

SDD範例解析

以下以Plantation Productions公司的數位資料擷取與控制(DAQ)系統中的DIP開關控制元件SDD為例,進行詳細解析。


### 1. Plantation Productions DAQ DIP開關控制

#### 1.2 發行日期與狀態
首次建立於2018年3月18日
目前狀態:完成

#### 1.4 作者資訊
Randall L. Hyde
版權所有 2019,Plantation Productions, Inc.

#### 2. 簡介

##### 2.1 目的
本SDD描述了DAQ系統中DIP開關初始化元件的設計,旨在協助開發者根據軟體需求規格(SRS)實作DIP開關控制功能。

##### 2.2 範圍
本檔案僅描述DAQ系統中的DIP開關設計。

##### 2.3 預期讀者
本檔案主要供實作該設計的軟體開發者、希望在實施前審查設計的利害關係人,以及編寫軟體測試案例(STC)和軟體測試程式(STP)檔案的作者使用。

#### 6. 軟體設計

##### 6.1 利害關係人與設計關注點
主要利害關係人包括Plantation Productions, Inc.和Randall Hyde。設計關注點包括簡化SDD以適應編輯限制,同時滿足DAQ DIP開關系統的所有需求。

##### 6.2 上下文視點與整體架構
描述了使用者與系統之間的互動功能。

#### 內容解密:

此段落描述了SDD的主要內容和結構。首先,檔案的後設資料(如發行日期、作者和版權資訊)提供了基本的識別資訊。在簡介部分,明確了SDD的目的、範圍和預期讀者,有助於讀者快速瞭解檔案的背景和適用範圍。在軟體設計部分,透過識別利害關係人和設計關注點,闡述了設計的核心考量。上下文視點與整體架構的描述則進一步闡明瞭系統的功能性需求和設計決策。

SDD的實務應用

在實務中,SDD對於確保軟體系統的設計品質和可維護性具有重要意義。透過制定詳細的SDD,開發團隊可以:

  • 提高溝通效率:SDD為開發者、測試人員和其他利害關係人提供了一個共同的參考框架,有助於減少誤解和溝通成本。
  • 確保設計一致性:透過明確設計決策和架構選擇,SDD有助於保持系統設計的一致性和完整性。
  • 支援測試和驗證:SDD為測試案例和測試程式的編寫提供了基礎,確保測試活動的有效性和全面性。

綜上所述,SDD是軟體開發過程中不可或缺的重要檔案。透過深入理解SDD的結構、內容和實務應用,可以有效提升軟體系統的設計品質和開發效率。