軟件工程 -- 總體設計


目錄

總體設計階段兩個階段
三層結構
雪球理論
總體設計階段的工作步驟
結構設計
模塊划分
應該遵守原理
耦合
內聚
軟件結構設計的啟發式規則
設計優化


總體設計階段兩個階段

1.系統設計階段:確定系統的具體實現方案

  • 划分出組成系統的物理元素——程序、文件、數據庫、人工過程和文檔等.
  • 設計系統的結構,也就是要確定系統中每個程序是由哪些模塊組成的,以及這些模塊相互間的關系

2.結構設計階段:確定軟件結構


三層結構

  • 表達層: 控制怎樣把數據通過用戶界面顯示給用戶,同時接受用戶的交互輸入
  • 業務層: 把跟這個應用相關的業務流程和業務規則集中在一起形成一個獨立部分
  • 數據層: 負責與數據庫打交道,把數據庫中的表,記錄等細節隱藏起來,使業務層見到的是普通的函數或者數值對象

關系:表達層(表達邏輯)<---->業務層(業務邏輯)<---->數據層(數據存儲)<--->數據庫


雪球理論

  • 從堅實的內核做起: 雪球起點不是一堆散雪而是捏了又捏的很緊密的雪核
  • 從小到大慢慢來: 一點一點由小變大,而不是通過一次性組裝變大
  • 邊滾邊看邊調整: 不能朝一個方向一直滾下去,往往是看着哪個缺了,重新換個方向繼續滾
  • 任何時候都接近圓: 任何時候滾出來的都是圓(及早集成,這樣在開發中遇到的困難就越小)

總體設計階段的工作步驟(七步)

  • 提供多種可能實現的方案.
  • 選取合理的方案.
  • 推薦最佳的方案
  • 對程序的結構設計:確定程序由那些模塊組成,模塊需要完成那些適當的子功能,以及模塊之間的關系(至於過程設計屬於詳細設計階段的任務.過程設計:確定每個模塊的處理過程 
  • 設計數據庫
  • 制定測試計划
  • 書寫文檔:計入總體設計的結果(文檔總類: 1.系統說明 2.用戶手冊 3.測試計划 4.詳細的實現計划 5.數據庫設計結果)

結構設計

要求:

結構設計簡單明確

體系結構:

在保證色戒能夠完成系統目標的前提下,減少不必要的中間層次和模塊,能夠直接通話的盡量直接通話,除非非常有必要.別人的東西不要在重復一遍,吧系統的規模保持在最小的程度.同時注意除去多余的聯系和耦合

類結構:

類結構的設計的繼承關系應該經過仔細推敲,真正反映普遍和特殊的關系,同時在數量上是精簡的,在繼承結構上是扁平化的

數據結構:

數據結構做到精簡成員變量意義明確,提高算法效率高減少功能作用類似的局部變量

概念的一致性:

在整個設計中使用統一,連貫的系統分析法,角度,和一致性的平衡尺度,直到在每個部分使用同樣的類比和詞匯


模塊划分

--模塊划分首先要有合理性,有助於對模塊的認識和理解

1)種類:

  • 基於邏輯關系(例:分層結構的層次間的依賴關系)
  • 基於功能

2)判斷划分的好壞:

模塊之間的耦合程度和方式,越少越好,越簡單越好.有適當的依賴是件好事,證明模塊之間有共享和復用,但不可取的是"你中有我,我中有你",以致模塊如一堆亂麻彼此分不開來.做到能不耦合在一起就盡量分開來,能不相互依賴就不要相互依賴


應該遵守原理

1.模塊化:

把程序划分為若干個獨立的訪問且完成一個子功能的模塊,且把這些模塊集合起來變可以滿足用戶所需求的功能.

2.模塊化好處

  • 使軟件結構清晰,不僅容易設計也容易閱讀和理解.
  • 容易測試和調試,提高軟件的可靠性.
  • 提高軟件的可修改性.
  • 有助於軟件開發工程的組織管理.

3.抽象

把這些相似的方面集中和概括起來,暫時忽略它們之間的差異,這就是抽象.或者說抽象就是考慮事物間被關注的特性而不考慮它們其他的細節.

4.逐步求精:

為了能集中精力解決主要問題而盡量推遲對問題細節的考慮.因為每次面臨的因素太多,是不可能做出精確思維的.處理復雜系統的唯一有效的方法是用層次的方法構造和分析它,把精力集中在與當前開發階段最相關的那些方面上,而忽略那些對整體解決方案來說雖然必要的,然而目前還不需要的細節.每一步對軟件解法的抽象層次的一次精化.

5.信息隱藏和局部化

應該這樣設計模塊,使得一個模塊內包含的信息對於不需要這些信息的模塊來說,是不能訪問的.把一些關系密切的軟件元素物理地放得彼此靠近.優點---如果在測試期間和以后的軟件維護期間需要修改軟件不會把影響擴散到別的模塊.

6.為何軟件設計中應該追求盡可能松散的系統?

這樣的系統中可以研究、測試和維護任何個模塊,不需要對系統的其他模塊有很多了解.模塊間的偶合程度強烈影響系統的可理解性、可測試性、可靠性和可維護性.


耦合

定義:

是指不同模塊彼此間互相依賴的緊密程度;

耦合的分類(五類):

  • 數據耦合: 如果兩個模塊通過參數交換信息,而且交換的信息僅僅是數據,那么這種耦合就是數據耦合.
  • 控制耦合: 如果兩個模塊通過參數交換信息,交換的信息有控制信息,那么這種耦合就是控制耦合.
  • 特征耦合: 如果被調用的模塊需要使用作為參數傳遞進來的數據結構中的所有數據時,那么把這個數據結構作為參數整體傳送是完全正確的.但是,當把整個數據結構作為參數傳遞而使用其中一部分數據元素時,就出現了特征耦合.在這種情況下,被調用的模塊可以使用的數據多於它確實需要的數據,這將導致對數據的訪問失去控制,從而給計算機犯錯誤提供機會.
  • 公共環境耦合當兩個或多個模塊通過公共數據環境相互作用時,他們之間的耦合稱為公共環境耦合.
  • 內容耦合有下列情形之一,兩個模塊就發生了內容耦合
    • 一個模塊訪問另一個模塊的內部數據
    • 一個模塊不通過正常入口而轉到另一個模塊的內部
    • 一個模塊有多個入口

在進行軟件結構設計時,應該采用的原則

盡量使用數據耦合,少用控制耦合和特征耦合,限制公共環境耦合的范圍,完全不用內用耦合.


內聚

定義:

是指在模塊內部各個元素彼此結合的緊密程度.

內聚的分類(大三類,小七類):

  • 低內聚
    • 偶然內聚:如果一個模塊完成一組任務,這些任務彼此間即使有關系,關系也比較松散,就叫做偶然內聚.
    • 邏輯內聚:如果一個模塊完成的任務在邏輯上屬於相同或相似的一類,則稱為邏輯內聚.
    • 時間內聚:如果一個模塊包含的任務必修在同一段時間內執行,就叫時間內聚.
  • 中內聚
    • 過程內聚:如果一個模塊內的處理元素是相關的,而且必須以特定次序執行,則稱為過程內聚.
    • 通信內聚:如果模塊中所有元素都使用同一個輸入數據和產生一個輸出數據,則成為通信內聚.
  • 高內聚
    • 順序內聚:如果一個模塊內的處理元素同一個功能密切相關,而且這些處理必須順序執行,則稱為順序內聚.
    • 功能內聚:如果模塊內所有處理元素屬於一個整體,完成一個單一的功能,則稱為功能內聚.

內聚在設計中的要求:

設計時力爭做到高內聚,並且能夠辨認出低內聚的模塊,有能力通過修改設計提高模塊的內聚程度降低模塊間的耦合程度


軟件結構設計的啟發式規則(七點)

1、改進軟件結構提高模塊獨立性.
2、模塊規模應該適中.
3、深度,寬度,扇出和扇入都應適當.

  • 深度: 表示軟件結構中控制的層數,它往往能夠粗略的標志一個系統的大小和復雜程度.
  • 寬度: 是軟件結構在同一層次上的模塊總數的最大值.一般來說,寬度越大系統就越復雜.
  • 扇出: 指一個模塊直接調用的模塊的數目,經驗表明,一個設計的好的典型系統的平均扇出通常是3或4個,太多或太少都不好.
  • 扇入: 指一個模塊被別的多少個模塊直接調用.扇入越大越好.

4、模塊的作用域應該在控制域之內
5、力爭降低模塊接口的復雜程度
6、設計單入口單出口的模塊
7、模塊功能應該可以預測:

如果一個模塊可以當作一個黑盒子,也就是說,只要輸入相同的數據就能產生同樣的的輸出,這個模塊的功能就是可以預測的.帶有內部“存儲器”的模塊的功能可能是不可預測的,因為它的輸出取決於內部存儲器的狀態.由於內部存儲器對於上級模塊是不可見的,所以這樣的模塊既不易理解又難於測試和維護.

************************************************************************
以上的啟發式規則多數是經驗規律,對改進設計,提高軟件質量,往往有重要的參考價值;但是,他們既不是設計的目標也不是設計時應該普遍遵循的原理.


設計優化(五點)

1、考慮設計優化問題時應該記住“一個不能工作的‘最佳設計’的價值是值得懷疑的”.
2、應該在設計的早期階段盡量對軟件結構進行精化.可以導出不同的軟件結構,然后對他們進行評價和比較,力求得到“最好”的結果.這種優化的可能是把軟件結構設計和過程設計分開的真正優點之一.
3結構簡單通常即表示設計風格優雅,又表明效率高.設計優化應該力求做到在有效的模塊化的前提下使用最少量的模塊,以及在能夠滿足信息要求的前提下使用最簡單數據結構.
4、優化時遵守一句格言:“先使它能工作,然后再使它快起來.”


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM