軟件詳細設計專題講座課件

軟件詳細設計

講座主講人：軟件詳細設計

講座主講人：內容第二部分：軟件設計第一部分：軟件架構內容第二部分：軟件設計第一部分：軟件架構第一部分

軟件架構內容第一部分

軟件架構內容需求/架構/設計關系需求/架構/設計關系軟件架構定義什么是架構？如果你問五個不同的人，可能會得到五種不同的答案。很多人都試圖給“架構”下定義，而這些定義本身卻很難統(tǒng)一。軟件架構是一種無法以簡單的一維方式進行說明的復雜實體。軟件架構（softwarearchitecture）是一系列相關的架構視圖，用于指導大型軟件系統(tǒng)各個方面的設計。多重軟件架構視圖之所以必不可少，是因為各類型人員（用戶、開發(fā)人員、測試人員、維護人員、操作人員）需要從各自的角度理解和使用架構。軟件架構定義什么是架構？如果你問五個不同的人，可能會得到五種軟件架構的實際意義做正確的架構正確的表達架構讓別人能遵守架構軟件架構的實際意義做正確的架構軟件架構視圖單一的視圖無法完整的表達架構，因此需要具備完整的視圖集。軟件架構視圖是從特定的視角出發(fā)，專注于該視角系統(tǒng)的結構、模塊劃分、基本組件職責和主要控制流。軟件架構視圖的四要素：圖示化主要元素和元素之間的關系。具有明確的圖例、定義和說明元素。每個元素具備明確的接口和行為規(guī)范。設計的原理和設計決策信息。。軟件架構視圖單一的視圖無法完整的表達架構，因此需要具備完整的常見軟件架構視圖邏輯視圖開發(fā)視圖部署視圖進程視圖場景視圖數據視圖實現(xiàn)視圖常見軟件架構視圖邏輯視圖”4+1”模式邏輯視圖開發(fā)視圖進程視圖部署視圖場景視圖”4+1”模式邏輯視圖開發(fā)視圖進程視圖部署視圖場景視圖邏輯視圖面向對象：客戶/用戶/開發(fā)組織管理者。視角：系統(tǒng)的功能元素，以及它們的接口、職責、交互等。主要元素：系統(tǒng)、子系統(tǒng)、功能模塊、子功能模塊、接口用途：開發(fā)組織劃分，成本/進度評估邏輯視圖面向對象：客戶/用戶/開發(fā)組織管理者。邏輯視圖樣例一系統(tǒng)框架圖邏輯視圖樣例一系統(tǒng)框架圖邏輯視圖樣例二軟件結構圖邏輯視圖樣例二軟件結構圖邏輯視圖樣例三前置子系統(tǒng)結構圖邏輯視圖樣例三前置子系統(tǒng)結構圖邏輯視圖樣例四監(jiān)控子系統(tǒng)結構圖邏輯視圖樣例四監(jiān)控子系統(tǒng)結構圖邏輯視圖樣例五防誤子系統(tǒng)結構圖邏輯視圖樣例五防誤子系統(tǒng)結構圖開發(fā)視圖面向對象：開發(fā)相關人員/測試人員視角：系統(tǒng)如何開發(fā)實現(xiàn)主要元素：描述系統(tǒng)的層、分區(qū)、包、框架、系統(tǒng)通用服務、業(yè)務通用服務、類和接口、系統(tǒng)平臺和相關基礎框架用途：指導開發(fā)設計和開發(fā)實現(xiàn)開發(fā)視圖面向對象：開發(fā)相關人員/測試人員開發(fā)視圖樣例一開發(fā)視圖樣例一開發(fā)視圖樣例二對象請求代理ORB開發(fā)視圖樣例二對象請求代理ORB開發(fā)視圖樣例三復制數據庫技術架構開發(fā)視圖樣例三復制數據庫技術架構開發(fā)視圖樣例四進程和服務管理開發(fā)視圖樣例四進程和服務管理開發(fā)視圖樣例五數據庫專用平臺開發(fā)視圖樣例五數據庫專用平臺開發(fā)視圖樣例六前置子模塊間關系開發(fā)視圖樣例六前置子模塊間關系部署視圖也稱物理視圖面向對象：系統(tǒng)集成商/系統(tǒng)運維人員視角：系統(tǒng)邏輯組件到物理節(jié)點的物理部署、節(jié)點之間的物理網絡配置主要元素：物理節(jié)點以及節(jié)點的通訊用途：指導系統(tǒng)采購以及網絡、節(jié)點布局部署視圖也稱物理視圖部署視圖樣例一部署視圖樣例一部署視圖樣例二部署視圖樣例二部署視圖樣例三部署視圖樣例三部署視圖樣例四部署視圖樣例四進程視圖面向對象：性能優(yōu)化/開發(fā)相關人員視角：系統(tǒng)運行時線程/進程的情況主要元素：系統(tǒng)進程/線程以及處理隊列等用途：指導系統(tǒng)進程/線程分布進程視圖面向對象：性能優(yōu)化/開發(fā)相關人員進程視圖樣例進程視圖樣例場景視圖也稱用例視圖面向對象：設計和開發(fā)人員視角：囊括了架構上最重要的場景（最典型或最有風險）及其非功能性需求，通過這些場景的實現(xiàn)，闡明了架構的廣度或眾多架構元素的運行方式。場景視圖也稱用例視圖場景視圖樣例一場景視圖樣例一場景視圖樣例二場景視圖樣例二數據視圖面向對象：數據架構師/開發(fā)相關人員視角：系統(tǒng)數據模型以及數據存儲/存取方式主要元素：系統(tǒng)的核心實體模型以及相應的數據存儲模型和存儲方式系統(tǒng)的數據存儲相關策略系統(tǒng)核心的數據流數據視圖面向對象：數據架構師/開發(fā)相關人員數據視圖樣例一數據視圖樣例一數據視圖樣例二RAC模式數據視圖樣例二RAC模式數據視圖樣例三HA模式數據視圖樣例三HA模式數據視圖樣例四DataGuard模式數據視圖樣例四DataGuard模式總結架構設計以多視圖的模式呈現(xiàn)多視圖的目的是為了指導不同的團隊思維和實現(xiàn)多視圖是分而治之的多視圖可以并行多視圖可以組合總結架構設計以多視圖的模式呈現(xiàn)第二部分

軟件設計內容第二部分

軟件設計內容內容軟件設計金字塔軟件設計的價值觀優(yōu)秀設計遵循的原則破窗效應和技術債務代碼的壞味道重構技術內容軟件設計金字塔設計金字塔設計金字塔關注軟件維護成本軟件系統(tǒng)維護工作量所占比重超乎想象?。?！COST(total)=COST(develop)+COST(maintain)COST(maintain)=Cost(understand)+(理解)Cost(change)+(變更)Cost(test)(測試)Cost(depoly)(現(xiàn)場部署)關注軟件維護成本軟件系統(tǒng)維護工作量所占比重超乎想象！?。∈裁词呛玫脑O計?關注軟件的可維護性和可復用性區(qū)分功能需求和非功能需求一個好的設計應該有如下性質：可擴展性、靈活性、可插入性可擴展性：新的功能可以很容易的加入到系統(tǒng)中靈活性：可以容許代碼修改平穩(wěn)，而不會波及到很多其他模塊可插入性：可以很容易的將一個類抽出去，同時將另一個有同樣接口的類加入進來什么是好的設計?關注軟件的可維護性和可復用性軟件的可維護性大家有沒有注意到，原來我們自認為是很漂亮的設計隨著時間的推移慢慢“發(fā)出腐化的臭味”，代碼也會慢慢變成由一堆糾纏不清的函數和變量攪和在一起的“代碼漿糊”，為什么？是什么原因導致的呢？--都是客戶和老板的錯！客戶不斷的改變需求。如果用戶的要求僅限于他們最初所聲明的，我們的設計就沒有問題，錯就錯在用戶改變了他們的需求。老板沒有給我們充足的時間，進行充分的分析，使我們沒有時間設計出一個完美的結構。軟件的可維護性大家有沒有注意到，原來我們自認為是很漂亮的設計軟件的變更軟件是應該不斷變更的。我們認為,真實世界中使用的程序必須進行變更，否則它在環(huán)境中的作用就會原來越小。軟件復雜增加性法則：隨著一個不斷演進程序的變更，他的結構會變得越來越復雜。軟件是應該不斷變更的，因為需求是不斷變更的。難道變化的需求一定會導致系統(tǒng)“腐爛”嗎？為什么一個系統(tǒng)的設計不可以為以后的變化留出足夠的空間？如何實現(xiàn)一個優(yōu)秀的設計？軟件的變更軟件是應該不斷變更的。我們認為,真實世界中使用的程優(yōu)秀設計原則優(yōu)秀設計第一法則：開閉原則優(yōu)秀設計第二法則：重構優(yōu)秀設計原則優(yōu)秀設計第一法則：開閉原則開閉原則開放-封閉原則（OCP）軟件的組成實體（類、模塊、函數等等）應該是可以擴展的，但是是不可修改的。即軟件實體可以通過增加新代碼實現(xiàn)擴展，但是不能修改已有代碼。任何一個系統(tǒng)在其生命周期內都會發(fā)生變化。如果我們希望開發(fā)出的系統(tǒng)不會在第一版本后就被拋棄，我們就必須牢記這一點。開閉原則開放-封閉原則（OCP）發(fā)現(xiàn)變化并將其封裝優(yōu)秀設計精髓就是封裝變化，就是將變化進行抽象，封裝變化，這樣才能保證軟件的可擴展性以及模塊間的松耦合。一種可變性不應當散落在代碼的很多角落里，而應當被封裝到一個對象里。一種可變性不應當與另一種可變性混合在一起。發(fā)現(xiàn)變化并將其封裝優(yōu)秀設計精髓就是封裝變化，就是將變化進行抽共性和可變性分析(CVA)找到變化的地點，稱為“共性分析”然后找出如何變化，稱為“變性分析”CVA分析步驟先尋找共性；從這些共性創(chuàng)建抽象；從共性的變化派生可變性實現(xiàn)；看共性與其他共性之間的關系如何；共性和可變性分析(CVA)找到變化的地點，稱為“共性分析”CVA樣例主板和插槽CVA樣例主板和插槽開閉原則的代價100%開閉原則的代價：遵循開閉原則代價昂貴，正確的抽象（尋找共性并抽象）需要時間和精力，需求的不可預測性，給抽象增加了復雜度。對于應用程序中的每個部分都肆意的進行抽象同樣不是一個好主意。應該對程序中呈現(xiàn)頻繁變化的那些部分進行抽象。拒絕不成熟的抽象和抽象本身一樣重要。開閉原則的代價100%開閉原則的代價：亡羊補牢-重構面對需求的不可預測性，設計師根據經驗猜測程序可能遭受的變化，如果猜測正確，獲得成功，猜測錯誤，遭受失敗。隨著需求的不斷變化，軟件的不斷變更，“設計腐化”和“代碼漿糊”的現(xiàn)象慢慢呈現(xiàn)出來。為了解決這個問題，我們需要應用優(yōu)秀設計的第二法則：優(yōu)秀設計需要不斷重構。重構到優(yōu)秀設計。亡羊補牢-重構面對需求的不可預測性，設計師根據經驗猜測程序可拙劣設計的影響如果設計已經出現(xiàn)腐化，代碼漿糊已經開始產生，我們最初的設計已經成為拙劣的設計了，我們不去重構的話，將會產生“破窗效應”和“技術債務”問題。拙劣設計的影響如果設計已經出現(xiàn)腐化，代碼漿糊已經開始產生，我破窗效應破窗理論破窗效應(BreakPaneLaw)

沒修復的破窗，導致更多的窗戶被打破破窗效應破窗理論破窗效應(BreakPaneLaw)

破窗效應破窗效應：沒修復的破窗，導致更多的窗戶被打破所謂“破窗效應”，是關于環(huán)境對人們心理造成暗示性或誘導性影響的一種認識?！捌拼靶崩碚撌侵福阂粋€房子如果窗戶破了，沒有人去修補，隔不久，其它的窗戶也會莫名其妙的被人打破；一面墻，如果出現(xiàn)一些涂鴉沒有清洗掉，很快的，墻上就布滿了亂七八糟，不堪入目的東西。一個很干凈的地方，人們會不好意思丟垃圾，但是一旦地上有垃圾出現(xiàn)之后，人們就會毫不猶疑的拋，絲毫不覺羞愧。這真是很奇怪的現(xiàn)象破窗效應破窗效應：沒修復的破窗，導致更多的窗戶被打破技術債務“出來混，遲早要還的”技術債務“出來混，遲早要還的”技術債務(TechnicalDebt)開發(fā)團隊在設計或架構選型時從短期效應的角度選擇了一個易于實現(xiàn)的方案，但從長遠來看，這種方案會帶來更消極的影響，亦即開發(fā)團隊所欠的債務技術債務類似于金融債務，它也會產生利息，這里的利息其實就是指由于魯莽的設計決策導致需要在未來的開發(fā)中付出更多努力的后果。我們可以選擇繼續(xù)支付利息，也可以通過重構之前魯莽的設計來將本金一次付清。雖然一次性付清本金需要代價，但卻可以降低未來的利息技術債務(TechnicalDebt)開發(fā)團隊在設計或架技術債務技術債務的種類無意的——由于經驗的缺乏導致初級開發(fā)者編寫了質量低劣的代碼。有意的——團隊根據當前而非未來進行設計選型，這種方式可能很快就能解決當前的問題，但卻很拙劣技術債務技術債務的種類技術債務很多敏捷團隊都能認識到技術債務相關的罪狀。就跟財務上的負債一樣，技術債務也會產生利息。要支付這些利息，就要付出額外努力維護和改進正在“腐化”或基礎并不牢固的軟件。諸多敏捷人士推薦盡早償還技術債務。然而，大多數敏捷團隊無法成功以金錢的方式計算技術債務，因此無法得到有價值的深入理解和思考技術債務很多敏捷團隊都能認識到技術債務相關的罪狀。就跟財務上技術債務技術債務代碼的壞味道產生破窗效應和技術債務的一個原因就是代碼產生了壞味道。代碼壞味道是指在代碼之中潛在問題的警示信號，并非所有的壞味道所指示的確實是問題，但大部分壞味道需要加以詳細查看，并做出相應決定。代碼壞味道是需要重構的癥狀?；蛘呤菨撛诘膯栴}，或者是缺陷。代碼的壞味道重點在代碼層次，與拙劣的設計相比是低的層次。代碼的壞味道產生破窗效應和技術債務的一個原因就是代碼產生了壞偉大程序員的標準-避免壞味道“我不是什么偉大的程序員，我只是一個有著很多好習慣的程序員”。任何一個傻瓜都能寫出機器能讀懂的代碼，好的程序員應該寫出人能懂的代碼。我們不是要告訴別人什么才是好的程序的標準，而應該告訴別人不應該出現(xiàn)的錯誤。偉大程序員的標準-避免壞味道“我不是什么偉大的程序員，我只是22種常見的代碼的壞味道重復代碼過長函數過大類過長參數列發(fā)散式變化散彈式修改依戀情結22種常見的代碼的壞味道重復代碼22種常見的代碼的壞味道數據泥團基本類型迷戀分支語句(switch)平等繼承體系冗贅類夸夸其談未來性令人迷惑的暫時值域22種常見的代碼的壞味道數據泥團22種常見的代碼的壞味道過度耦合的消息鏈中間轉手人狎昵關系異曲同工的類不完美的程序庫類純粹的數據類被拒絕的遺贈過多的注釋22種常見的代碼的壞味道過度耦合的消息鏈代碼靜態(tài)分析代碼靜態(tài)分析工具是一種軟件，可以利用它對程序的源代碼進行分析，自動測試應用系統(tǒng)的很多方面。在軟件測試中，靜態(tài)分析工具并不執(zhí)行所測試的程序，只是掃描所測試程序的正文，對程序的源代碼進行分析，它類似于編譯程序中的詞法分析和語法分析，但工作量遠不止于此。使用代碼靜態(tài)分析工具可以發(fā)現(xiàn)一些代碼壞味道。但不會解決代碼的壞味道。代碼靜態(tài)分析代碼靜態(tài)分析工具是一種軟件，可以利用它對程序的源壞味道的解決之道-重構代碼的壞味道-設計師必知代碼壞味道-壞味道的名稱癥狀-有助于找出問題的線索原因-對問題如何會發(fā)生的說明采取的措施-可能的重構收益-在那些方面有所改善不適應情況-在哪些情況下不適用壞味道的解決之道-重構代碼的壞味道-設計師必知重構的定義名詞定義：對軟件內部結構的一種調整，目的是在不改變功能的前提下，提高其可理解性，降低其修改成本。動詞定義：使用一系列重構準則，在不改變軟件功能的前提下，調整其結構。重構的3次法則（事不過三）第一次做某事時盡管去做；第二次做類似的事情時會產生反感，但無論如何還是做了；第三次再做類似的事，你就應該重構。重構的定義名詞定義：對軟件內部結構的一種調整，目的是在不改變壞味道與重構重復代碼:在一個以上的地方看到相同的程序結構同一個class內的兩個函數含有相同表達式兩個互為兄弟的subclass內含有相同的表達式一般重構方法：提煉方法、提取類、方法上移、替換算法、鏈構造方法。壞味道與重構重復代碼:在一個以上的地方看到相同的程序結構壞味道與重構發(fā)散式變化:軟件應該能夠更容易的被修改。一旦需要修改，我們希望能夠集中到系統(tǒng)的某一點，只在此處做修改。散彈式修改：如果每遇到某種變化，你必須在許多不同的class內作出許多小修改以響應之，即需要修改的代碼四處散布，不但很難找到，而且容易遺漏。

一般重構方法：提取類、轉移方法、轉移字段。壞味道與重構發(fā)散式變化:軟件應該能夠更容易的被修改。一旦需要壞味道與重構過多的注釋:代碼中常?？吹揭欢魏荛L的注釋，然后發(fā)現(xiàn)，這些注釋存在的原因是因為代碼很糟糕。加入注釋的目的是讓大家能夠知道我的代碼是干什么的。如果我們找到這些代碼的壞味道，并使用重構的方法把壞味道清除掉，就會發(fā)現(xiàn)注釋已經變得多余了。壞味道與重構過多的注釋:代碼中常?？吹揭欢魏荛L的注釋，然后發(fā)壞味道與重構不同的壞味道，其重構方法方法不盡相同。壞味道還可以使用模式的方法進行重構。在此我們不做具體說明。壞味道與重構不同的壞味道，其重構方法方法不盡相同。壞味道還可總結我們應該了解設計的金字塔。我們應該明確自己設計的價值觀。是注重可維護性還是更注重性能。維護成本的計算。我們應該知道優(yōu)秀設計的原則。我們應該知道怎樣才是一個好的程序員。我們應該知道破窗效應、技術債務。我們應該知道代碼中那些常見的壞味道。我們應該知道如何清除代碼中的壞味道我們應該知道如何重構總結我們應該了解設計的金字塔。期望我們希望大家通過不同的架構視圖為系統(tǒng)做出正確的架構設計。我們希望大家在設計時能夠樹立正確的設計價值觀。我們希望大家都能做出優(yōu)秀的設計。我們希望少出現(xiàn)或不出現(xiàn)破窗效應和技術債務。我們希望系統(tǒng)中的代碼少出現(xiàn)或不出現(xiàn)壞味道。即使出現(xiàn)，我們也能通過重構將之清除。我們希望大家都能成為好的設計師和程序員。期望我們希望大家通過不同的架構視圖為系統(tǒng)做出正確的架構設計。軟件詳細設計

講座主講人：軟件詳細設計

講座主講人：內容第二部分：軟件設計第一部分：軟件架構內容第二部分：軟件設計第一部分：軟件架構第一部分

軟件架構內容第一部分

軟件架構內容需求/架構/設計關系需求/架構/設計關系軟件架構定義什么是架構？如果你問五個不同的人，可能會得到五種不同的答案。很多人都試圖給“架構”下定義，而這些定義本身卻很難統(tǒng)一。軟件架構是一種無法以簡單的一維方式進行說明的復雜實體。軟件架構（softwarearchitecture）是一系列相關的架構視圖，用于指導大型軟件系統(tǒng)各個方面的設計。多重軟件架構視圖之所以必不可少，是因為各類型人員（用戶、開發(fā)人員、測試人員、維護人員、操作人員）需要從各自的角度理解和使用架構。軟件架構定義什么是架構？如果你問五個不同的人，可能會得到五種軟件架構的實際意義做正確的架構正確的表達架構讓別人能遵守架構軟件架構的實際意義做正確的架構軟件架構視圖單一的視圖無法完整的表達架構，因此需要具備完整的視圖集。軟件架構視圖是從特定的視角出發(fā)，專注于該視角系統(tǒng)的結構、模塊劃分、基本組件職責和主要控制流。軟件架構視圖的四要素：圖示化主要元素和元素之間的關系。具有明確的圖例、定義和說明元素。每個元素具備明確的接口和行為規(guī)范。設計的原理和設計決策信息。。軟件架構視圖單一的視圖無法完整的表達架構，因此需要具備完整的常見軟件架構視圖邏輯視圖開發(fā)視圖部署視圖進程視圖場景視圖數據視圖實現(xiàn)視圖常見軟件架構視圖邏輯視圖”4+1”模式邏輯視圖開發(fā)視圖進程視圖部署視圖場景視圖”4+1”模式邏輯視圖開發(fā)視圖進程視圖部署視圖場景視圖邏輯視圖面向對象：客戶/用戶/開發(fā)組織管理者。視角：系統(tǒng)的功能元素，以及它們的接口、職責、交互等。主要元素：系統(tǒng)、子系統(tǒng)、功能模塊、子功能模塊、接口用途：開發(fā)組織劃分，成本/進度評估邏輯視圖面向對象：客戶/用戶/開發(fā)組織管理者。邏輯視圖樣例一系統(tǒng)框架圖邏輯視圖樣例一系統(tǒng)框架圖邏輯視圖樣例二軟件結構圖邏輯視圖樣例二軟件結構圖邏輯視圖樣例三前置子系統(tǒng)結構圖邏輯視圖樣例三前置子系統(tǒng)結構圖邏輯視圖樣例四監(jiān)控子系統(tǒng)結構圖邏輯視圖樣例四監(jiān)控子系統(tǒng)結構圖邏輯視圖樣例五防誤子系統(tǒng)結構圖邏輯視圖樣例五防誤子系統(tǒng)結構圖開發(fā)視圖面向對象：開發(fā)相關人員/測試人員視角：系統(tǒng)如何開發(fā)實現(xiàn)主要元素：描述系統(tǒng)的層、分區(qū)、包、框架、系統(tǒng)通用服務、業(yè)務通用服務、類和接口、系統(tǒng)平臺和相關基礎框架用途：指導開發(fā)設計和開發(fā)實現(xiàn)開發(fā)視圖面向對象：開發(fā)相關人員/測試人員開發(fā)視圖樣例一開發(fā)視圖樣例一開發(fā)視圖樣例二對象請求代理ORB開發(fā)視圖樣例二對象請求代理ORB開發(fā)視圖樣例三復制數據庫技術架構開發(fā)視圖樣例三復制數據庫技術架構開發(fā)視圖樣例四進程和服務管理開發(fā)視圖樣例四進程和服務管理開發(fā)視圖樣例五數據庫專用平臺開發(fā)視圖樣例五數據庫專用平臺開發(fā)視圖樣例六前置子模塊間關系開發(fā)視圖樣例六前置子模塊間關系部署視圖也稱物理視圖面向對象：系統(tǒng)集成商/系統(tǒng)運維人員視角：系統(tǒng)邏輯組件到物理節(jié)點的物理部署、節(jié)點之間的物理網絡配置主要元素：物理節(jié)點以及節(jié)點的通訊用途：指導系統(tǒng)采購以及網絡、節(jié)點布局部署視圖也稱物理視圖部署視圖樣例一部署視圖樣例一部署視圖樣例二部署視圖樣例二部署視圖樣例三部署視圖樣例三部署視圖樣例四部署視圖樣例四進程視圖面向對象：性能優(yōu)化/開發(fā)相關人員視角：系統(tǒng)運行時線程/進程的情況主要元素：系統(tǒng)進程/線程以及處理隊列等用途：指導系統(tǒng)進程/線程分布進程視圖面向對象：性能優(yōu)化/開發(fā)相關人員進程視圖樣例進程視圖樣例場景視圖也稱用例視圖面向對象：設計和開發(fā)人員視角：囊括了架構上最重要的場景（最典型或最有風險）及其非功能性需求，通過這些場景的實現(xiàn)，闡明了架構的廣度或眾多架構元素的運行方式。場景視圖也稱用例視圖場景視圖樣例一場景視圖樣例一場景視圖樣例二場景視圖樣例二數據視圖面向對象：數據架構師/開發(fā)相關人員視角：系統(tǒng)數據模型以及數據存儲/存取方式主要元素：系統(tǒng)的核心實體模型以及相應的數據存儲模型和存儲方式系統(tǒng)的數據存儲相關策略系統(tǒng)核心的數據流數據視圖面向對象：數據架構師/開發(fā)相關人員數據視圖樣例一數據視圖樣例一數據視圖樣例二RAC模式數據視圖樣例二RAC模式數據視圖樣例三HA模式數據視圖樣例三HA模式數據視圖樣例四DataGuard模式數據視圖樣例四DataGuard模式總結架構設計以多視圖的模式呈現(xiàn)多視圖的目的是為了指導不同的團隊思維和實現(xiàn)多視圖是分而治之的多視圖可以并行多視圖可以組合總結架構設計以多視圖的模式呈現(xiàn)第二部分

軟件設計內容第二部分

軟件設計內容內容軟件設計金字塔軟件設計的價值觀優(yōu)秀設計遵循的原則破窗效應和技術債務代碼的壞味道重構技術內容軟件設計金字塔設計金字塔設計金字塔關注軟件維護成本軟件系統(tǒng)維護工作量所占比重超乎想象?。?！COST(total)=COST(develop)+COST(maintain)COST(maintain)=Cost(understand)+(理解)Cost(change)+(變更)Cost(test)(測試)Cost(depoly)(現(xiàn)場部署)關注軟件維護成本軟件系統(tǒng)維護工作量所占比重超乎想象?。?！什么是好的設計?關注軟件的可維護性和可復用性區(qū)分功能需求和非功能需求一個好的設計應該有如下性質：可擴展性、靈活性、可插入性可擴展性：新的功能可以很容易的加入到系統(tǒng)中靈活性：可以容許代碼修改平穩(wěn)，而不會波及到很多其他模塊可插入性：可以很容易的將一個類抽出去，同時將另一個有同樣接口的類加入進來什么是好的設計?關注軟件的可維護性和可復用性軟件的可維護性大家有沒有注意到，原來我們自認為是很漂亮的設計隨著時間的推移慢慢“發(fā)出腐化的臭味”，代碼也會慢慢變成由一堆糾纏不清的函數和變量攪和在一起的“代碼漿糊”，為什么？是什么原因導致的呢？--都是客戶和老板的錯！客戶不斷的改變需求。如果用戶的要求僅限于他們最初所聲明的，我們的設計就沒有問題，錯就錯在用戶改變了他們的需求。老板沒有給我們充足的時間，進行充分的分析，使我們沒有時間設計出一個完美的結構。軟件的可維護性大家有沒有注意到，原來我們自認為是很漂亮的設計軟件的變更軟件是應該不斷變更的。我們認為,真實世界中使用的程序必須進行變更，否則它在環(huán)境中的作用就會原來越小。軟件復雜增加性法則：隨著一個不斷演進程序的變更，他的結構會變得越來越復雜。軟件是應該不斷變更的，因為需求是不斷變更的。難道變化的需求一定會導致系統(tǒng)“腐爛”嗎？為什么一個系統(tǒng)的設計不可以為以后的變化留出足夠的空間？如何實現(xiàn)一個優(yōu)秀的設計？軟件的變更軟件是應該不斷變更的。我們認為,真實世界中使用的程優(yōu)秀設計原則優(yōu)秀設計第一法則：開閉原則優(yōu)秀設計第二法則：重構優(yōu)秀設計原則優(yōu)秀設計第一法則：開閉原則開閉原則開放-封閉原則（OCP）軟件的組成實體（類、模塊、函數等等）應該是可以擴展的，但是是不可修改的。即軟件實體可以通過增加新代碼實現(xiàn)擴展，但是不能修改已有代碼。任何一個系統(tǒng)在其生命周期內都會發(fā)生變化。如果我們希望開發(fā)出的系統(tǒng)不會在第一版本后就被拋棄，我們就必須牢記這一點。開閉原則開放-封閉原則（OCP）發(fā)現(xiàn)變化并將其封裝優(yōu)秀設計精髓就是封裝變化，就是將變化進行抽象，封裝變化，這樣才能保證軟件的可擴展性以及模塊間的松耦合。一種可變性不應當散落在代碼的很多角落里，而應當被封裝到一個對象里。一種可變性不應當與另一種可變性混合在一起。發(fā)現(xiàn)變化并將其封裝優(yōu)秀設計精髓就是封裝變化，就是將變化進行抽共性和可變性分析(CVA)找到變化的地點，稱為“共性分析”然后找出如何變化，稱為“變性分析”CVA分析步驟先尋找共性；從這些共性創(chuàng)建抽象；從共性的變化派生可變性實現(xiàn)；看共性與其他共性之間的關系如何；共性和可變性分析(CVA)找到變化的地點，稱為“共性分析”CVA樣例主板和插槽CVA樣例主板和插槽開閉原則的代價100%開閉原則的代價：遵循開閉原則代價昂貴，正確的抽象（尋找共性并抽象）需要時間和精力，需求的不可預測性，給抽象增加了復雜度。對于應用程序中的每個部分都肆意的進行抽象同樣不是一個好主意。應該對程序中呈現(xiàn)頻繁變化的那些部分進行抽象。拒絕不成熟的抽象和抽象本身一樣重要。開閉原則的代價100%開閉原則的代價：亡羊補牢-重構面對需求的不可預測性，設計師根據經驗猜測程序可能遭受的變化，如果猜測正確，獲得成功，猜測錯誤，遭受失敗。隨著需求的不斷變化，軟件的不斷變更，“設計腐化”和“代碼漿糊”的現(xiàn)象慢慢呈現(xiàn)出來。為了解決這個問題，我們需要應用優(yōu)秀設計的第二法則：優(yōu)秀設計需要不斷重構。重構到優(yōu)秀設計。亡羊補牢-重構面對需求的不可預測性，設計師根據經驗猜測程序可拙劣設計的影響如果設計已經出現(xiàn)腐化，代碼漿糊已經開始產生，我們最初的設計已經成為拙劣的設計了，我們不去重構的話，將會產生“破窗效應”和“技術債務”問題。拙劣設計的影響如果設計已經出現(xiàn)腐化，代碼漿糊已經開始產生，我破窗效應破窗理論破窗效應(BreakPaneLaw)

沒修復的破窗，導致更多的窗戶被打破破窗效應破窗理論破窗效應(BreakPaneLaw)

破窗效應破窗效應：沒修復的破窗，導致更多的窗戶被打破所謂“破窗效應”，是關于環(huán)境對人們心理造成暗示性或誘導性影響的一種認識?！捌拼靶崩碚撌侵福阂粋€房子如果窗戶破了，沒有人去修補，隔不久，其它的窗戶也會莫名其妙的被人打破；一面墻，如果出現(xiàn)一些涂鴉沒有清洗掉，很快的，墻上就布滿了亂七八糟，不堪入目的東西。一個很干凈的地方，人們會不好意思丟垃圾，但是一旦地上有垃圾出現(xiàn)之后，人們就會毫不猶疑的拋，絲毫不覺羞愧。這真是很奇怪的現(xiàn)象破窗效應破窗效應：沒修復的破窗，導致更多的窗戶被打破技術債務“出來混，遲早要還的”技術債務“出來混，遲早要還的”技術債務(TechnicalDebt)開發(fā)團隊在設計或架構選型時從短期效應的角度選擇了一個易于實現(xiàn)的方案，但從長遠來看，這種方案會帶來更消極的影響，亦即開發(fā)團隊所欠的債務技術債務類似于金融債務，它也會產生利息，這里的利息其實就是指由于魯莽的設計決策導致需要在未來的開發(fā)中付出更多努力的后果。我們可以選擇繼續(xù)支付利息，也可以通過重構之前魯莽的設計來將本金一次付清。雖然一次性付清本金需要代價，但卻可以降低未來的利息技術債務(TechnicalDebt)開發(fā)團隊在設計或架技術債務技術債務的種類無意的——由于經驗的缺乏導致初級開發(fā)者編寫了質量低劣的代碼。有意的——團隊根據當前而非未來進行設計選型，這種方式可能很快就能解決當前的問題，但卻很拙劣技術債務技術債務的種類技術債務很多敏捷團隊都能認識到技術債務相關的罪狀。就跟財務上的負債一樣，技術債務也會產生利息。要支付這些利息，就要付出額外努力維護和改進正在“腐化”或基礎并不牢固的軟件。諸多敏捷人士推薦盡早償還技術債務。然而，大多數敏捷團隊無法成功以金錢的方式計算技術債務，因此無法得到有價值的深入理解和思考技術債務很多敏捷團隊都能認識到技術債務相關的罪狀。就跟財務上技術債務技術債務代碼的壞味道產生破窗效應和技術債務的一個原因就是代碼產生了壞味道。代碼壞味道是指在代碼之中潛在問題的警示信號，并非所有的壞味道所指示的確實是問題，但大部分壞味道需要加以詳細查看，并做出相應決定。代碼壞味道是需要重構的癥狀?；蛘呤菨撛诘膯栴}，或者是缺陷。代碼的壞味道重點在代碼層次，與拙劣的設計相比是低的層次。代碼的壞味道產生破窗效應和技術債務的一個原因就是代碼產生了壞偉大程序員的標準-避免壞味道“我不是什么偉大的程序員，我只是一個有著很多好習慣的程序員”。任何一個傻瓜都能寫出機器能讀懂的代碼，好的程序員應該寫出人能懂的代碼。我們不是要告訴別人什么才是好的程序的標準，而應該告訴別人不應該出現(xiàn)的錯誤。偉大程序員的標準-避免壞味道“我不是什么偉大的程序員，我只是22種常見的代碼的壞味道重復代碼過長函數過大類過長參數列發(fā)散式變化散彈式修改依戀情結22種常見的代碼的壞味道重復代碼22種常見的代碼的壞味道數據泥團基本類型迷戀分支語句(switch)平等繼承體系冗贅類夸夸其談未來性令人迷惑的暫時值域22種常見的代碼的壞味道數據泥團22種常見的代碼的壞味道過度耦合的消息鏈中間轉手人狎昵關系異曲同工的類不完美的程序庫類純粹的數據類被拒絕的遺贈過多的注釋22種常見的代碼的壞味道過度耦合的消息鏈代碼靜態(tài)分析代碼靜態(tài)分析工具是一種軟件，可以利用它對程序的源代碼進行分析，自動測試應用系統(tǒng)的很多方面。在軟件