軟件設計必備的6大方面「軟件設計方案包括哪些方面」

軟件設計是從用戶故事或者軟件需求規格說明書或者軟件需求文檔出發，根據需求階段確定的需求功能定義，設計軟件系統的整體結構、劃分功能模塊、確定每個模塊之間的數據交換、信息流通、頁面交互以及後期的數據收集、整合、展現等;形成軟件具體設計方案。

軟件設計是把許多概念的事物和問題進行抽象化，並抽象根它們不同的層次和角度;將問題或事物分解並模塊化，使得解決問題變得容易，分解越細模塊功能越小也就越有利實現。

一、設計階段

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）二次開發技術選型。

在接下來，全面展開規格級的架構設計工作，設計出能實際指導團隊並行開發的細化架構。

細化架構設計。一般而言，可以分別從邏輯架構、開發架構、運行架構、物理架構、數據架構等不同架構視圖進行設計。

架構驗證。對後續工作產生重大影響返工代價很高的任何工作都應該進行驗證，軟件需求如此，架構設計方案也是如此。至於驗證架構的手段，對軟件項目而言，往往需要開發出架構原型，並對原型進行測試和評審來達到；而對軟件產品而言，可以開發一個框架來貫徹架構設計方案，再通過在框架之上開發特定的垂直原型來驗證特定的功能或質量屬性。

因此，從架構驗證工作得到的不應該僅僅是“軟件架構是否有效”的回答，還必須有可實際運行的程序：體現軟件架構的垂直拋棄原型或垂直演進原型，或者是更利於重用的框架。這些成果為後續的開發提供了實在的支持。

從最初的概念設計到落地實施，見證了整個軟件方案設計，其中就涉及到一個重點，那就是需求開發，整個過程需要管理與把控；這就形成了一個整體的需求開發與管理活動。軟件方案設計，就是為了使用戶、開發人員更能清晰的認識，從軟件的概念期到實際軟件研發後的落地整個流程的了解。