【項目管理】N002:軟件設計沒那麼簡單

1. 軟件設計概述

1.1 軟件設計的目的

軟件設計是在系統設計或者概要設計的基礎上,將系統設計進行細化,確定模塊劃分、模塊之間的接口定義、系統中的數據構成等事項,從而確定怎樣通過編碼來實現系統功能的一個階段。軟件設計是編碼工作的基準,主要輸出文檔是軟件設計書。

1.2 軟件設計的前提

在進行軟件設計前,項目前期需要完成的資料如下:

  • 系統功能用例列表
  • 系統業務流程說明
  • 系統軟硬件構成
  • 系統使用的核心算法
  • 系統設計方針
  • 系統軟件構成
  • ER圖及數據項目清單
  • 畫面列表及畫面遷移圖
  • 畫面UI設計原則
  • 指導詳細設計的文檔規約,設計規約等

1.3 軟件設計的內容

軟件設計書的主要內容包括以下幾方面:

  • 項目背景介紹:項目系統的名稱,目的,使用方法等相關信息,進行概要說明。

  • 項目整體概要介紹:對詳細設計的整體方針進行介紹,包括開發語言和開發技術,系統架構等。

  • 設計方針:包括模塊劃分方法,如何複用,如何處理錯誤和異常,如何實現可擴展性、可靠性、安全性和性能

    方面的要求,如何進行日誌處理及測試等。

  • 系統模塊設計

  • 系統數據設計

  • 畫面設計

  • 報表設計

  • 數據量與性能設計

  • 錯誤處理及錯誤信息一覽

2. 系統架構(軟硬件環境)

軟件設計過程中要詳細確定軟件,硬件,中間件的具體信息,特別是一些限制,根據這些限制調整軟件設計的策略。軟件設計過程的輸入輸出內容如下:

輸入內容:

  • 系統設計書

輸出內容:

  • 使用的軟件版本,安裝目錄列表
  • 配置管理工具以及項目中的各種文件及源代碼存儲說明
  • 特殊硬件的數量及規格說明
  • 中間件產品的說明書,以及由此造成的開發限制的說明

2.1 系統軟件

  • 確定開發和運行使用的操作系統類型和版本
  • 確定數據庫類型版本
  • 確定開發工具和版本
  • 確定軟件設計文檔使用的Office版本,不同版本的Office編寫的文檔整合起來比較困難
  • 確定配置管理使用的軟件
  • 確定使用瀏覽器類型和版本
  • 確定APP客戶端的支持類型和版本

2.2 系統硬件

  • 確認開發使用的PC機
  • 開發使用的服務器
  • 確認開發過程中需要使用的特殊的硬件產品。例如:特定型號手機、特殊型號的打印機以及對字體的支持

2.3 中間件版本

  • 確定應用服務器的版本。例如:Tomcat 8.0.53
  • 確定Web服務器和版本。例如:Nginx-1.15.8
  • 確定消息服務器和版本。例如:RabbitMQ、ActiveMQ
  • 確定第三方類庫和版本。例如:druid、mybatis
  • 確定使用的開源框架產品和版本。例如:SpringBoot(後端)、Vue(前端)

2.4 測試環境

爲了保證測試的有效性,測試環境必須能夠模仿真實的生產環境,在可能的情況下應該保證測試環境與真實環境一致。在準備測試環境的時候要注意一下問題:

  • 操作系統的類型和版本
  • 數據庫系統的類型和版本
  • 客戶端瀏覽器的類型和版本
  • 開發使用程序包、類庫、中間件的版本和限制
  • 針對於一些特殊的,需要 License才能運用的軟件應該取保在測試開始之前有開發版的License
  • 特殊的硬件設備,例如:特殊的打印機,在沒有特殊設備需要替代設備時一定要經過客戶確認
  • 在滿足測試環境要求的同時,制定完善的測試計劃,測試計劃必須能夠可執行,可衡量

3 系統模塊設計

模塊設計在整個軟件設計中是非常重要的一個部分。進行模塊設計需要根據模塊設計的原則,進行模塊的抽取劃分,並進行最終的模塊詳細設計。

3.1 模塊設計三原則

模塊泛指軟件系統的功能,每個模塊都具有特定的、明確的功能。模塊設計的核心工作是接口的設計和數據結構與算法的設計。在模塊設計時我們遵循以下幾個原則:

3.1.1 信息隱藏

我們設計的模塊應該僅僅公開必須讓外界知道的東西,而隱藏其他一切內容。接口是模塊的外部特徵,應該公開;而數據結構、算法實現體是模塊的內部特徵,應當隱藏。如果一個模塊是一個類(Class),那麼這個模塊的接口就是該類的公共函數。

3.1.2 高內聚

內聚是一個模塊內部各成分之間相關聯程度。我們設計模塊時應該儘量爭取模塊的各成分之間關聯程度緊密結合。

3.1.3 低耦合

耦合是模塊之間的依賴程度。耦合的強度通常依賴於以下幾個因素:

  • 一個模塊對另外一個模塊的函數調用數量
  • 一個模塊向另一個模塊傳遞的數據量
  • 模塊之間接口的複雜程度

模塊設計應當爭取“高內聚,低耦合”,而避免“低內聚,高耦合”。

3.2 共通模塊的抽取

在模塊設計時共通模塊的抽取有一個非常重要的原則。原則上,只要某一功能被不同的模塊調用兩次以上,就應該作爲共通模塊抽出來。

3.2.1 抽出共通模塊好處

  • 減少軟件開發時的冗餘代碼,減少作業量
  • 當發生需求變更時要修改共通模塊時,減少變更的工作量
  • 有助於提高開發的生產效率和軟件的質量

3.2.2 抽出共通模塊注意事項

  • 適度抽出。模塊劃分過細,會增加程序的複雜性,從而抵消了共通模塊帶來的好處。
  • 保證品質。最好由經驗豐富的開發人員來參與共通模塊的設計和編碼。
  • 嚴格審查。對共通模塊,要加強審查的頻度和力度,減少變更,因爲它會影響到很多其它模塊。
    當發生式樣變更要修改共通模塊時,有可能擴大變更的影響範圍。

3.2.3 常用抽取共通模塊

  • 日誌處理
  • 數據庫操作
  • 錯誤處理
  • 數據類型處理
  • 文件讀寫操作
  • 數據類型處理(類型轉化、日期處理等)
  • 用戶輸入檢驗(如是否爲數字、半角等)

3.3 模塊設計的工作

模塊設計包括以下幾方面的工作:

  • 描述:介紹模塊相關信息
  • 功能:簡要介紹該模塊在系統中的作用,屬於哪一部分,實現哪些功能
  • 接口:模塊中函數或方法的定義
  • 輸入項:模塊的參數
  • 輸出項:模塊的返回結果
  • 處理流程:按照一定的邏輯順序,描述模塊根據輸入得到輸出的處理步驟。可以用圖表(如流程圖……)
    輔以必要的說明來更形象地表達
  • 數據結構:模塊中用到的複雜數據類型
  • 限制條件:說明程序運行中所受到的限制條件
  • 核心算法:模塊中用到一些較複雜的算法,程序說明具體的計算公式和計算步驟
  • 性能要求:程序說明對模塊的性能要求,包括對精度、靈活性和時間特性的要求
  • 數據庫邏輯結構:模塊中的處理涉及到數據庫,將相關數據庫的結構程序說明

4 數據設計

4.1 文件格式設計

定義文件構成格式,包括字段長度,分隔符,不足位時補充空格等約束,制訂整體規範。

  • 異常信息文件格式
  • 日誌文件格式
  • 配置文件格式

4.2 數據庫設計

數據庫設計輸出內容:數據表構造圖、數據項目列表、索引列表、視圖列表。

4.2.1 數據對象設計

  • 用戶:說明除數據庫安裝時系統自帶用戶外的所有用戶,及其對應的角色和權限。

  • 表:說明除數據庫安裝時系統自帶系統表外的所有表結構,包括表名,字段名,數據類型,長度,
    主鍵,外鍵,索引,訪問權限,存儲空間

  • 視圖:視圖物理名,視圖的定義

  • 抽象數據類型:抽象數據類型物理名,抽象數據類型的定義

  • 觸發器:觸發時間(before和after),觸發條件(insert,update,delete),觸發子類型(行觸發和語句觸發)。

  • 存儲過程:存儲過程物理名,輸入參數,輸出參數,使用權限,功能說明

  • 函數:函數物理名,輸入參數,返回值。

4.2.2 數據庫數據設計

  • 事務處理量:系統每秒的事務處理量的累計值

  • 處理時間:處理一個事務所需要的時間。這個過程包括客戶端向服務器發出請求、服務器做出響應以及客戶端接收到服務器應答所需要的時間。

  • 併發量:最大的同時連接數。

5 畫面UI設計

整體根據系統設計書中的畫面Layout、畫面一覽和畫面遷移,進行畫面共通部分(多個畫面中存在。 例如:異常信息顯示、共通的畫面頭等)、業務部分(畫面獨特的功能、處理。例如:用戶登錄等)的功能整理,並作成詳細設計書中的畫面項目說明文檔。

  • 項目名稱:畫面中表示項目的名稱。例如:登錄按鈕
  • 項目ID:用英文、數字等表示的項目名,以便於在程序中使用。例如:BTN001
  • 項目類型:項目空間的類型描述。例如:按鈕、下拉框
  • 寬度、高度:項目的表示寬度、表示高度
  • 必須、可選:項目的內容是必須輸入還是不必須輸入的
  • 默認值:和變量設初始值一樣,文本框、單選按鈕、複選按鈕等項目最好設定默認值
  • 文字:文字的字體、顏色和大小
  • 背景色:有的時候需要對有焦點和沒有焦點設定不同的背景色
  • 顯示位置:表示內容的水平對齊和垂直對齊
  • 顯示格式:顯示內容的時候,一些特殊的格式要求。例如:四捨五入、金額數字中的間隔號等
  • 光標移動:按TAB、ENTER等功能鍵的時候,光標如何在畫面中移動
  • 輸入文字數: 可以輸入的最大文字數,
  • 數據輸入輸出:該畫面項目與數據庫哪張表、哪個字段對應,以及與數據庫進行數據交換的條件、方法

6 錯誤處理設計

6.1 錯誤處理原則

  • 分層:模塊在函數調用中的層次不同,每一層都分別捕獲和處理不同的錯誤。
  • 集中處理:所有的錯誤處理,最終都由一個共通的錯誤處理模塊來處理,包括記錄日誌、顯示 錯誤消息等。

6.2 錯誤處理步驟

  • 在調用的最底層,捕獲所有錯誤。已知錯誤,調用錯誤處理模塊;未知錯誤,拋給上層。
  • 在調用的中間層,將底層的錯誤拋給上層。
  • 在調用的最高層(通常是畫面按鈕),捕獲所有錯誤,調用錯誤處理模塊。

6.3 錯誤處理措施

軟件系統中的錯誤通常可分爲以下三種類型:

  • 操作錯誤:用戶通過系統畫面與系統交互時不滿足輸入規則、輸入範圍等發生的錯誤。
    • 處理:校驗用戶輸入,提示正確規則。
  • 運行錯誤:軟件系統與外部環境交互時發生的錯誤,如網絡、文件系統、數據庫、其它業務應用系統等。
    • 處理:記錄日誌,顯示錯誤消息,終止系統運行或允許用戶採取補救措施後,重新操作。
  • 程序員錯誤:由於編碼不慎導致發生的錯誤,如空指針等。
    • 處理:修正代碼。

6.4 錯誤信息記錄

通過日誌記錄捕獲到的每個錯誤的原始信息,包括錯誤發生函數、錯誤發生模塊、錯誤詳細描述等。另外,關於函數調用中由參數不符引發的錯誤,可分爲兩種情況:

  • 詳細設計的接口說明當中,明確列出了參數不允許的非法值。這樣開發人員在調用該函數時,應該避免傳入非法值。如果出現此類錯誤,就是程序員錯誤。
  • 詳細設計的接口說明當中沒有明確列出哪些參數值是非法的,這樣開發人員需要在該函數內部的處理開始添加非法參數的校驗。

7 軟件設計收尾

軟件設計階段的收尾時,需要檢查如下內容:

  • 參照系統設計書以及需求文檔,確認所有的機能都已經被設計,沒有發現遺漏。
  • 所有的軟件設計書經過了內部的Review或者同行評審,並且Review發現的問題已經修正完畢。
  • 所有的文檔都遵循了之前確定的軟件設計書模版,並且在打印預覽模式下進行了檢查,確認文檔能夠正常被打印出來。
  • 將軟件設計書的文檔進行整理定版存放在了指定位置作爲下階段編碼工作的指導。

8 後記

以上,基於今年的特殊情勢,在家閒暇之餘,梳理了近些年來的開發過程,就自己感覺重要的部分進行了整理,供大家參考。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章