所在位置:首頁 -- 技術培訓 -- 軟件設計 -- 軟件詳細設計原理與實踐

軟件詳細設計原理與實踐


 課程背景
俗話說“殺死一個程序員不需要刀,只要軟件需求變三次就好了”。請問設計師你為什么這么痛苦呢?除了埋怨那些該死的需求變化之外,我們還應該有哪些反思?設計師應該具備哪些能力來應對變化呢?
如果您是具有多年經驗的軟件設計師,請問什么是好的設計?
軟件大師Peter Code認為,一個好的系統設計應該有如下的性質:可擴展性、靈活性、可插入性。為什么他認為軟件的靈活性是這么重要呢?這是因為:
·軟件的成本Cost(total)可以分解為初始開發成本Cost(develop)和后期維護成本Cost(maintain)之和
Cost(total)= Cost(develop)+ Cost(maintain)
而維護成本包括以下幾個部分:
Cost(maintain)= Cost(understand)+ Cost(change)+Cost(test)+Cost(deploy)
隨著軟件開發經驗積累,我們意識到軟件維護成本遠遠高于它的初始開發成本。這是因為理解現有設計需要成本,修改需要成本,還有測試和部署這也需要大量成本。最終發現軟件的維護成本遠遠大于初始創建成本。
Cost(maintain)>> Cost(develop)
但是,我們的軟件設計師卻很少關注設計的靈活性性,現實中的軟件系統幾乎總是會慢慢變為一個爛攤子。去年才構建的漂亮小巧的系統到了今年卻變成了由一堆糾纏不清的函數和變量攪和在一起的“代碼漿糊”。
為什么會這樣?
為什么一個設計會逐漸“發出腐化的臭味”?
為什么它們不能保持原先那樣的清晰簡潔呢?
有時候設計人員會把原因歸咎于客戶,責怪他們總是需求變更。那么,難道我們的設計就是沒問題的,都是客戶的錯嗎?設計師難道就不能設計靈活一些嗎?
如果您有這方面的困惑,那就請參加我們的課程吧! 
 教學大綱

教學單元 單元教學內容
第一單元:什么優秀設計以及如何實現應對需求變化 內容一:什么是好的設計
1. 什么是好的軟件詳細設計和衡量的手段。
2. 世界大師的觀點(Robert C Martin、Peter Code、James Shor)。
3. 我們現實項目的情況隨時需求的變化,我們自以為豪的設計都逐漸變爛,變成糾纏不清的代碼漿糊。
4. 可擴展性(Extensibility)容易添加新的功能。結合案例,通過哪些手段如何實現該目標?
5. 靈活性(Flexibility)代碼修改平穩地發生。結合案例,通過哪些手段如何實現該目標?
6. 可插入性(Pluggability)容易將一個類抽出去,同時將另一個有同樣接口的類加入進來。結合案例,通過哪些手段如何實現該目標?
7. 分析真實項目,如何做的詳細設計,給我們哪些啟示,我們可以學習到什么?
8. 分析我們在項目之中是那些原因導致了沒有實現這些目標。

內容二:案例——某省移動基站綜合管理項目案例
1. 某省移動項目,必須考慮支持多種設備廠商。
2. 初始設計的問題分析。
3. 應用何種模式解決問題。

內容三:如何應對需求的變化
1. 設計基本原則。
2. 發現和封裝變化的原則。
3. 面向對象的基本原則(OCP/SRP/DIP等基本設計原則)。
4. 根據共性性分析進行行為職責或者數據的抽象。
5. 根據可變性分析進行職責的結構分析和實現。
6. 局部化變更,可修改性戰術目標是減少由某個變更直接影響的模塊數量。
7. 防止連鎖反應,目標是限制對局部化的模塊的修改,減少間接受變更影響的模塊。
8. 推遲綁定時間,盡量不要靜態編譯,應該運行期間決定組件之間關系。
9. 結合多個案例項目進行分析,怎樣發現和封裝變化,如何通過具體的手段來進行適應這些變化。
10. 結合多個案例項目進行分析,怎樣發現和封裝變化,如何通過具體的手段來進行適應這些變化。

內容四:案例——某省電信網管項目
1. 某省移動項目,必須考慮支持多種設備廠商。
2. 初始設計的問題分析。

第二單元:技術債務和軟件設計腐化 內容一:技術債務
1. 技術債務概述。
2. 軟件債務對軟件系統的危害。
3. 軟件債務對軟件開發人員的危害。
4. 技術債務與破窗效應。
5. 技術債務的解決之道。
6. 通過案例分析,如何解決破窗效應。

內容二:混亂的設計
1. 目前國內軟件項目的設計現狀。
2. 大泥球仍然是最常見的設計方式。
3. 通過案例分析,對比2種設計思維帶來的維護問題。

內容三:案例——演示系統軟件腐化的過程
1. 某電信項目系統。
2. 初始設計的問題分析。
3. 通過該案例分析,對比有時是因為人員的設計技能導致加速軟件的腐化。

第三單元:設計層次(架構、詳細設計、編碼)如何交互 內容一:軟件架構和設計概述
1. 軟件架構和詳細設計關注點和區別。
2. 軟件架構師職責。
3. 軟件架構視圖和軟件架構文檔。
4. 詳細設計師必須知道的架構決策。
5. 軟件詳細設計師和職責。
6. 結合多個案例進行分析,根據項目的不同類型,進行合適的架構視圖,展現多個大型項目的架構視圖。


內容二:軟件詳細設計
1. 傳統詳細設計的局限性。
2. 什么是好的軟件詳細設計和衡量的手段。
3. 軟件詳細設計的過程和內容。
4. 敏捷設計新思想。
5. 過度詳細設計(Over-engineering)問題和注意事項。
6. 設計不足(Under-engineering)問題和注意事項,分析真實項目,設計與實現的新思想。

內容三:源代碼就是設計
1. 傳統代碼認識的誤區。
2. 設計與施工分離的誤區。
3. 源代碼就是設計。
4. 分析真實項目代碼,認識代碼的重要性,垃圾代碼的危害。

內容四:案例——多項目詳細設計分析
1. 通過多個零售系統設計分析。

第四單元:敏捷設計—預先設計做到什么程度 內容一:軟件不可預測性
1. 軟件需求的不可預測性。
2. 預先設計的局限性。
3. 傳統瀑布型設計的問題。
4. 案例分析,根據課程介紹的壞癥狀,進行重構合理的設計。

內容二:敏捷設計思想——演化式設計
1. 敏捷設計思想:強調通過提高團隊的能力、設計的彈性和流程的靈活性來適應變化。
2. 演化設計:重構帶來了一種新的構設計方法,稱為反思性設計(Reflective Design)。除了創建一種設計并用代碼實現它之外,你現在還可以分析已有代碼的設計并改善它。尋求改進的一種最好的方法是通過代碼嗅覺(code smells)。
3. 在詳細設計之中,如何對發現問題的設計進行重構。
4. 案例分析,根據課程介紹的壞癥狀,進行重構合理的設計。

內容三:案例——某電信項目系統
1. 故障單管理系統。
2. 流程審核的改變。
3. 故障單類型的增加。
4. 傳統設計的問題與如何通過代碼進行演化。
 

第五單元:防止變異技術 內容一:防止變異技術
1. 防止變異技術。
2. 多態(polymorphism)和針對接口的編程。
3. 數據驅動(Data-Driven Design)。
4. 元數據驅動設計。
5. 反射驅動(Meta-data or Reflective)。
6. 解釋器驅動。
7. 腳本引擎技術。
8. 結合多個案例項目進行分析,怎樣發現和封裝變化,如何通過具體的手段來進行適應這些變化。

內容二:案例——某項目系統防止變異技術的應用分析
1. 結合多種技術防止變異,如何做的通用性。

第六單元:領域驅動設計--軟件核心復雜性應對之道 內容一:領域驅動設計
1. 業務邏輯層架構模式。
2. 事務腳本模式/領取驅動設計/表模塊。
3. 領域驅動設計的優缺點和面臨的挑戰。
4. 如何建立軟件項目的有效模型。
5. 構建基于模型的語言,用來連接領域專家,開發者和代碼自身。
6. 技術人員和業務人員在建模過程中的探索式交互。
7. 案例分析,通過案例演示,領會驅動設計與傳統事務腳本模式的優缺點。
第七單元:軟件設計復用 內容一:軟件復用設計
1. 在詳細設計中分析發現共同的行為的抽象和共同的機制來實現。
2. 軟件通用服務組件的設計。
3. 復用已有的東西,比自己編寫更容易。如果不容易,大家就不會去復用。
4. 軟件復用的管理策略。

內容二:軟件通用機制的設計與實現
1. 異常的機制設計與實現。
2. 系統的配置管理機制的設計與實現。
3. 系統的Cache緩存機制的設計與實現。
4. 異步消息和通知機制的設計與實現。
5. 認證授權以及安全/加解密的機制設計與實現。
6. 事務管理機制的設計與實現。
7. 定時觸發的機制設計與實現。
8. 后臺批處理機制設計與實現。
9. 校驗機制設計與實現。
10. 通信機制設計與實現。

內容三:框架(Application framework)設計
1. 應用框架概述。
2. 框架vs.類庫的不同。
3. 在軟件詳細設計時如何應用框架和設計新的框架。
4. 典型案例分析:結合多個項目實例,在實際項目中如何進行應用和開發框架。

內容四:某電信項目案例-異常處理框架設計
1. 系統的異常處理策略。
2. 設計一個通用異常處理子系統。
3. 分析如何應用設計模式在該案例。
4. 分析通過應用設計模式,帶來了哪些好處(表現在軟件的靈活性)。
5. 分析如何轉換為Framework。
6. 典型案例分析:該框架已經在多個大型項目之中應用。

內容五:某電信項目案例的詳細設計分析
1. 項目背景。
2. 使用AOP思想改造項目設計。
3. AOP與軟件復用。

第八單元:敏捷建模 內容一:敏捷建模
1. UML在詳細設計階段的應用方式(4種方式)。
2. UML類圖和順序圖在詳細設計中如何協作進行職責分配。
3. UML圖的是否保留和廢棄。
4. 結合多個案例項目進行分析如何正確應用UML建模,以避免過度建模以及怎樣保留UML建模成果和代碼的同步問題。

內容二:詳細設計的文檔和相關工具(根據學員和時間,現場適當調整)
1. 設計文檔撰寫。
2. 設計文檔的評審與基線。
3. 設計文檔的版本管理。
4. 設計文檔的變更控制略。
5. 詳細設計轉化為代碼。
6. 界面設計工具。
7. 數據建模工具。
8. 部署模型設計相關工具。
9. 結合案例進行分析詳細設計文檔的編寫。
 

第九單元:軟件設計質量 內容一:軟件的質量屬性
1. 軟件開發的4個要素成本、時間、功能范圍和質量。
2. 什么是系統質量屬性。
3. 如何進行定義質量屬性。
4. 詳細設計需要考慮的質量屬性。
5. 通過案例分析如何在設計時考慮設計質量。

內容二:軟件的質量屬性對詳細設計的影響
1. 軟件的可靠性設計策略。
2. 軟件的可修改性設計策略。
3. 軟件的性能設計策略。
4. 軟件的安全性設計策略。
5. 軟件的易用性設計策略。
6. 系統質量屬性和設計原則和模式的關系。
7. 結合多個案例進行分析,通過哪些手段來實現這些質量屬性。

第十單元:軟件設計案例分析 內容一:大型軟件項目詳細設計案例分析
1. 軟件詳細設計最佳實踐。
2. 某電信項目詳細設計最佳實踐。
3. 某電力項目詳細設計最佳實踐。
4. 某Web互聯網項目詳細設計最佳實踐。

 

中国北京单场足球彩票