理論基礎之——軟體方案設計
軟體設計是從使用者故事或者軟體需求規格說明書或者軟體需求文件出發,根據需求階段確定的需求功能定義,設計軟體系統的整體結構、劃分功能模組、確定每個模組之間的資料交換、資訊流通、頁面互動以及後期的資料收集、整合、展現等;形成軟體具體設計方案。
軟體設計是把許多概念的事物和問題進行抽象化,並抽象根它們不同的層次和角度;將問題或事物分解並模組化,使得解決問題變得容易,分解越細模組功能越小也就越有利實現。
一、設計階段
1、概要設計——
結構設計:定義,軟體系統各主要部件之間的關係
介面設計:軟體內部與外部的資料交換或軟體和作業系統間,以及軟體和人之間如何通訊。
全域性資料結構設計:將模型轉換成資料結構的定義。
過程設計:系統結構部件轉成軟體的過程描述
主要是關注如何將需求轉換成資料和軟體框架。
2、詳細設計
關注於將框架逐步求精細化為具體的資料結構和軟體的演算法表達。發生中的設計行為、資料、演算法和程式設計都需要由現代程式所需的介面設計的行為結合。
二、設計原則
1、設計對於分析模型應該是可跟蹤的——軟體的模組可能被對映到多個需求上。
2、設計結構應儘可能模擬現實
3、設計應該表現出一致性
4、不要把設計當成編寫程式碼
5、在建立設計時就應該能夠評估質量
6、評審設計以減少語義性錯誤
7、設計應模組化,將軟體邏輯劃分為元素或子系統,幷包含資料、體系結構、介面和構件的清晰表示。
三、軟體架構
軟體架構涉及到程式的兩個特性:(1)模組的層次結構 (2)資料結結構
這源自於需求分析時將真實世界問題定義與軟體解決方案要素聯絡起來的分割過程。當問題的每個部分通過一個或多個軟體要素得到解決後與問題的定義和解決相一致,軟體和資料結構的進化就開始了。這個過程代表了軟體需求分析和設計之間的位置。控制層級也叫程式結構,描述程式元件的組織並意味著控制層級,它並不描述軟體程式方面,例如程序順序、決定的事件/命令、工作迴圈。
資料結構描述了當個數據之間的邏輯關係,規定了資料的組織、訪問方法、關聯程度和資訊選擇處理。
程式結構著重處理每個模組的細節並必須提供一個精確的處理範規範,包括事件順序、準確的判定、重複操作、資料結構。軟體的程式表現是分層的。
四、設計方法論
設計過程中用以促成模組化設計的四個區域:模組、資料、體系、程式設計。
模組設計降低了複雜性、便於修改、且使得支援系統不同部分的並行開發實現起來更容易。模組型別提供的操作特性通過結合時間歷史、啟用機制、控制模式來表現。在程式結構內部,模組可以被分類為:
1、順序模組,由應用程式引用和執行,但不能從表現上中斷。
2、增量模組,可被應用程式先行中斷,而後再從中斷點重新開始。
3、並行模組,在處理器環境下可與其他模組同時執行。單獨的模組更容易開發,因為功能可以被劃分出來,而介面只是用來保證功能的獨立。功能的獨立性可以使兩個定性的標準來衡量:凝聚性——衡量模組的功能強度的相關性 耦合性——衡量模組間的相互依賴的相關性。
五、舉例說明
軟體方案設計在需求開發人員看來,不外乎就是系統的架構設計,也就是我們常說的解決方案,從整個系統層面進行梳理,將系統的功能、架構,資料、資訊,頁面互動、模組重新進行梳理、擴充套件、展現的一個過程。
1、架構設計的實踐
(1)看透需求——深入瞭解需求,例如做分銷系統後臺,必須瞭解分銷概念架構,有一個整體模型,通過檢視細化架構;重視功能;需要根據需求全面的考慮整體功能。
(2)架構大方向正確——瞭解分銷系統後臺的基本模組,保證與其競品功能無異議;滿足系統資料流向、資料處理、資訊產生、資訊儲存及處理等要求。
(3)設計好架構的各方面——要根據需求開發的結構進行系統功能梳理,各層次及功能要區分。
2、架構設計的步驟
(1)需求分析
(2)領域建模
(3)確定關鍵需求
(4)概念架構設計
(5)細化架構設計
(6)架構驗證
需求分析。有全面認識需求並權衡不同需求之間相互影響的情況下,設計出的架構很可能有問題。
領域建模。領域建模的目的是:透過問題領域的重重現象,捕捉其背後最為穩固的領域概念,以及這些概念之間的關係。在專案前期,所建立的領域模型將為所有團隊成員之間、團隊成員和客戶之間的交流提供共同認可的語言核心。隨著專案的進展,領域模型不斷被精化,最終成為整個軟體的問題領域層,該層決定了軟體系統能力的範圍。
概念架構的設計,軟體系統的規模越大、複雜程度越高,進行概念架構設計的好處就越明顯。
確定對架構關鍵的需求。這不僅要求對功能需求(如用例)進行篩選,還要對非功能需求進行綜合權衡,最終確定對軟體架構起關鍵作用的需求子集。
概念架構設計。概念架構的設計,必須同時重視關鍵功能和關鍵質量。業界流行的一種錯誤觀點是“概念架構=理想化架構”,不考慮任何非功能需求,也不考慮任何具體技術。
概念架構要明確:1)如何劃分頂級子系統;
2)架構風格選型;
3)開發技術選型;
4)整合技術選型;
5)二次開發技術選型。
在接下來,全面展開規格級的架構設計工作,設計出能實際指導團隊並行開發的細化架構。
細化架構設計。一般而言,可以分別從邏輯架構、開發架構、執行架構、物理架構、資料架構等不同架構檢視進行設計。
架構驗證。對後續工作產生重大影響返工代價很高的任何工作都應該進行驗證,軟體需求如此,架構設計方案也是如此。至於驗證架構的手段,對軟體專案而言,往往需要開發出架構原型,並對原型進行測試和評審來達到;而對軟體產品而言,可以開發一個框架來貫徹架構設計方案,再通過在框架之上開發特定的垂直原型來驗證特定的功能或質量屬性。
因此,從架構驗證工作得到的不應該僅僅是“軟體架構是否有效”的回答,還必須有可實際執行的程式:體現軟體架構的垂直拋棄原型或垂直演進原型,或者是更利於重用的框架。這些成果為後續的開發提供了實在的支援。
從最初的概念設計到落地實施,見證了整個軟體方案設計,其中就涉及到一個重點,那就是需求開發,整個過程需要管理與把控;這就形成了一個整體的需求開發與管理活動。軟體方案設計,就是為了使使用者、開發人員更能清晰的認識,從軟體的概念期到實際軟體研發後的落地整個流程的瞭解。