2017-2-3
軟件開發最初始是規模較小的程序，編寫者和使用者是同一個人。
軟件工程面對的問題：
1、產品很多時候根本不是用戶想要的。
2、開發成本和進度難以估計。前期的估算到後期演變爲指數級都常見。爲了時間或成本進度而權宜之計常常影響產品質量。
3、軟件產品的質量靠不住。軟件質量保證技術如審查、測試因爲主觀或客觀原因沒有完全運用。
4、軟件常常是不可維護的。缺乏乏文檔資料。
軟件危機的原因：軟件本身的屬性；開發和維護的方法不科學。
屬性：
1、缺乏可見性；過程進展質量難以定量衡量。軟件運行中發現錯誤可能就是在開發期間引入，而測試沒有檢測出來。軟件維護意味着需要修改原來的設計，這使得維護異常艱難。
2、規模龐大，程序的複雜性隨着程序的規模指數級上升，多人協作構建軟件系統極端困難，涉及技術問題，分析方法，設計方法，形式說明，版本控制，需要有嚴格科學的管理
3、意識上重視開發，明確需求、測試維護、規範性等缺乏正確的認知。
軟件不同階段進行修改的成本差異巨大。越前成本越低。
軟件維護的費用佔軟件總費用的55%-70%。
軟件是程序、數據以及相關文檔的集合。程序是能完成預定功能和性能的可執行的指令序列。數據是程序能處理信息的數據結構。文檔是開發使用和維護程序所需要的圖文資料。
軟件工程的中心課題是控制複雜性。把問題分解，各個部分是可理解的，各個部分保持簡單的通信關係。這種方式不能降低整體複雜性，但是可變成可管理的。如何協作，明確規定每個人的責任和相互通信的方法，標準和規章。
軟件工程師常常缺乏應用領域的相關知識。產品經理。
開發人員應該少而精，素質高。
軟件工程包括技術和管理兩方面，是技術和管理緊密結合的工程學科。所謂的管理就是通過計劃、組織和控制，合理配置和使用資源達到既定的目標。
傳統的方法是一個階段一個階段的順序推進。前一個階段的完成是後一個階段的前提和基礎。需要嚴格的管理複查纔算結束。需要高質量的文檔資料。優點是有條不紊，保證質量，提高可維護性，極大的提高成功率。缺點是當規模龐大，以及對軟件需求模糊或隨時間變化需求往往難以沿用。
傳統方法是強調自頂向下順序完成各個階段的任務，一開始對於整體有相當明確的定義，然而人類的認知是一個漸進的過程。人的認知需要在繼承已有的知識基礎上，經過多次反覆才能逐步深化，人的認知深化過程包括了從一般到特殊的演繹過程，也包括了特殊到一般的歸納思想。
面向對象的基本原則是儘量模仿人類的習慣，使開發軟件的方法和過程接近人類認知世界，解決問題的方法和過程，從而使描述問題的問題空間與實現解法的解空間在結構上一致。
面向對象將數據和行爲結合。
面向對象的方法是一個主動反覆迭代的演化過程，面向對象的類即爲特殊到一般的歸納思想，通過繼承建立的等級體系即爲一般到特殊的演繹過程。
面向對象的優點是促進了軟件複用重用。面向對象的特點：抽象，繼承，封裝，多態性。
2017-2-4
軟件生命週期：
1、軟件定義時期
需求分析，定義解決的問題，定義目標系統，產品需求說明書。產品經理職責。
2、軟件開發時期
總體設計是在較抽象的高層次上進行分析和設計問題。一個系統應該是由若干個規模適中的模塊按合理的層次結構組織而成，總體設計需要確定系統由哪些模塊構成以及模塊間的關係。以較爲抽象的概括方式提出瞭解決問題的方法。
詳細設計是把總體設計的方案具體化。詳細的規格說明。模塊設計，詳細的設計模塊，確定模塊功能的算法和數據結構。
編碼和單元測試。
綜合測試。集成測試和驗收測試。集成測試是把通過了單元測試的模塊按照某種策略組織起來，在裝配過程中進行測試。驗收測試是對需求分析階段確定的系統交由用戶進行測試驗收。
3、軟件維護時期
提出維護需求，分析維護需求，提出方案，確定方案，修改設計，修改程序，測試程序，複查驗收。實際上是壓縮和簡化的軟件工程。
常見的軟件模型：
1、瀑布模型
需求分析驗證、規格說明驗證、設計驗證、編碼驗證、綜合測試、維護。
特點：階段間具有順序性和依賴性，前一階段的輸出是後一階段的輸入；推遲實現；文檔驅動.
優點：強迫開發人員用規範的方法，每個階段都被驗證，每個階段提交高質量文檔，軟件維護有基礎。
缺點：在產品交付用戶以前，用戶只能通過文檔瞭解產品是怎樣的。事實證明，當用戶開始接觸一個軟件，在頭腦中關於該軟件應該做什麼的想法或多或少的會變化，當初提出的需求不完全適用了。要求用戶不經過實踐就完全提出準確完全的需求是不切實際的。瀑布模型完全依賴文檔規格說明，可能導致最終的軟件產品不是用戶想要的。
2、快速原型模型
快速建立可以運行的原型，它所完成的功能往往是產品所有功能的子集。讓用戶使用，提出修改意見以後迅速迭代，再次使用。一旦用戶認爲原型系統可以完成工作，即開始編寫文檔，並根據文檔進行開發。原型系統是通過與用戶交互得到驗證的。
採用瀑布模型和快速原型模型，目標都是一次把滿足所有需求的產品提供給用戶。
3、增量模型
把軟件看作一系列的增量進行設計、編碼、集成和測試。如第一個構件完成軟件的最核心功能，之後的構件不斷累加。增量模型逐步的分批提交產品。構件規模適中。
在實際工作中，增量模型的設計需要更加開放的設計，這是非常困難的。有構件無法集成在一起的風險。最好的是能在實現構件之前就完成所有的分析設計工作。
4、螺旋模型
適用於開發大規模的軟件項目。項目越大，風險越大，進行風險分析必要性越大。螺旋模型是風險驅動的，管控風險也是異常困難的事情。
使用原型來降低風險，增加了風險分析過程的快速原型模型。
最佳實踐建議：
1、迭代開發，線性開發不適用，一方面不可能開發大複雜的系統，同時需求常常變更。因此需要通過一系列細化和漸進反覆過程得到有效解決方案的迭代方法。
2、管理需求。確定系統需求是一個連續的過程。
3、使用基於構件的體系結構。構件是功能清晰的模塊或子系統。
4、可視化建模。模型是爲了理解事物而對事物進行的抽象，可視化圖形更易理解。
5、驗證軟件質量。質量評估貫徹開發過程，全員參與。
6、控制軟件變更。修改都是可接受和可跟蹤的。
迭代和漸增的思路。
敏捷過程：
1、可以工作的軟件勝過面面俱到的文檔。
2、客戶合作勝過合同談判，滿足用戶不斷變更的需求。
3、響應變化勝過遵循計劃。計劃有靈活性和可塑性。
4、優先致力於構建開發團隊，包括成員和交互方式，再根據需要配置項目過程和工具。
極限編程是敏捷過程中最有名的。極限指的是把好的開發實踐運用到極致。廣泛運用於需求模糊且經常變動的場合。
特點：
1、客戶作爲開發團隊的成員。客戶與開發緊密配合，客戶負責確定需求，回答問題，驗收。
2、短交付週期。兩週一次迭代，交互目標系統可工作的版本，不斷演示迭代生成的系統獲得反饋意見。
3、結對編程，測試驅動開發。先有好的測試方案然後再編程，所有的測試工作完成了纔算工作完成。
4、集成所有。程序代碼歸所有人所有，任何人都有修改代碼的權利，全體成員對所有代碼負責。
5、持續集成。多次集成系統，隨着需求的變更，不斷迴歸測試。
6、可持續開發速度，能維持長期穩定的速度，開放的工作空間，全體成員在開放場所工作，隨時自由交流討論。
7、及時調整計劃。計劃是靈活和循序漸進的。
8、重構。代碼重構是在不影響系統行爲的前提下，重新調整和優化系統的內部結構，降低複雜性，消除冗餘，增加靈活性，提高性能。不要過分依賴重構，前期重設計。
面對變化和不確定性更加快速敏捷，能快速持續迭代漸增。
2017-2-5
分層，面對複雜的系統，比較好的方法是分層次的描述系統。分層的描述方式是從抽象到具體的過程逐步深入瞭解一個複雜的系統。
首先用系統流程圖描述系統總體概貌，表明系統的關鍵功能。然後分別把關鍵功能擴展爲適當的詳細程度，畫在單獨的空間。
系統流程圖：數據在系統各個部件之間的流動情況。部件（程序、文檔、數據庫、人工過程等）
數據流圖：描述信息流和數據從輸入移動到輸出的過程總所經受的變換。考慮數據的起點和終點，考慮數據存儲，任何改變數據的操作是處理。只描述數據在軟件中的流動和被處理的邏輯過程。只需考慮系統必須完成的邏輯功能，不用考慮具體實現。
實體聯繫圖（ER圖）：包含數據對象（實體）、關係和屬性。描述用戶的數據要求。數據對象是具有一系列性質或屬性的事物，是複合信息的抽象。可以用一組屬性來定義的實體都是數據對象，數據對象彼此是有關聯的，1:1，1:n，n:n。
範式定義消除數據冗餘的程度，第一範式1NF數據冗餘程度最大，第五範式最小。滿足第二範式的條件之一是滿足第一範式。範式級別越高，存儲相同的數據需要更多的表，因此存儲本身就更加複雜，範式級別提高需求變化時穩定性差，需要訪問的表增多，效率降低。
數據庫設計三大範式：
1：原子性。數據庫的字段都是具有單一屬性的，不可再分。
2：唯一性。每個非主屬性都完全函數依賴於鍵碼。記錄具有唯一標識。每列都跟主鍵有關係。（以一對多爲例）
3：消除傳遞依賴。每個非主屬性都不偉遞領帶於鍵碼。即任何字段不能由其他字段派生出來，它要求字段沒有冗餘。一個非關鍵字屬性值不依賴於另外一個非關鍵字屬性值。
沒有冗餘的數據庫設計可以做到。但是，沒有冗餘的數據庫未必是最好的數據庫，有時爲了提高運行效率，就必須降低範式標準，適當保留冗餘數據。具體做法是：在概念數據模型設計時遵守第三範式，降低範式標準的工作放到物理數據模型設計時考慮。降低範式就是增加字段，允許冗餘。
狀態轉換圖：通過描述系統的狀態以及引起系統狀態轉換的事件來表示系統的行爲。
狀態是任何可以被觀察的系統行爲模式。系統對事件的響應，可以是一個或一系列動作，也可以是改變狀態，還可以是both.
IPO圖是輸入、處理、輸出圖，描述輸入數據，對數據處理和輸出數據的關係。
實體聯繫圖建立數據模型，數據流圖建立功能模型，狀態圖建立行爲模型。IPO描述算法模型。
按照形式化的程度，可以把軟件工程使用的方法劃分爲非形式化，半形式化和形式化三類。自然語言來描述需求規格說明是非形式化方法，數據流圖或實體聯繫圖來建立模型是半形式化方法。描述系統性質是基於數學基礎的則是形式化方法。
自然語言描寫規格說明書可能出現矛盾，二義性，含糊，不完整，抽象層次混亂的問題。
2017-2-6
總體設計，設計軟件結構，確定由哪些模塊構成以及模塊間的關係。模塊處於黑盒級別。
總體設計階段產生邏輯模型，分析物理實現方案以後根據最優方案實現。
設計軟件結構：通常程序的一個模塊完成一個適當的子功能，應該把模塊組織成良好的層次系統，頂層模塊調用下層模塊，下層調用更加下層，最下層的完成具體功能。
總體設計可以重點嘗試使用數據流圖。分析數據流圖中的每一個處理，如果處理的功能過於複雜，切分爲一系列簡單的功能。最終可以考慮使用IPO圖定義處理的算法。
系統說明：用系統流程圖描繪系統的構成方案，層次圖或結構圖描述軟件結構（即由模塊組成的層次系統），數據流圖描述定義功能，IPO圖描述算法。
設計原理：
模塊是構成軟件的基本構件，模塊化是爲了使一個複雜的系統爲人的智力所能管理，是軟件應該具備的唯一屬性。模塊化把程序劃分爲可獨立命名和訪問的模塊，每個模塊完成一個子功能，模塊集成構成整體。
如果一個問題由兩個問題組合而成，那麼它的複雜程度要大於分別考慮兩個問題的複雜程度之和。當模塊數量增加，每個模塊的規模將會減少，但是設計模塊間的接口將會增加工作量。每個軟件有相應的大小最適當的模塊規模。
模塊化的原理使得軟件結構清晰，軟件容易閱讀和理解，程序的錯誤常常是在接口間或是模塊內，模塊化使得軟件容易調試和測試。模塊化有助於工程管理。
人們認知複雜事物強有力的思維工具是抽象，抽象是抽出事件的本質不考慮細節。由於人的思維能力的限制，如果面對的因素太多是不能產生精確思維的，處理複雜系統的唯一有效的方式是用層次的方式構造它。一個複雜的系統可以由一系列的抽象概念來構造，如此下去不斷重複直至最底層的具體元素。
頂層設計與逐步求精。自頂向下，從抽象到具體的方式分配控制.簡化軟件的設計和實現，提高軟件的可理解和可測試性，並且使得軟件更加易於維護。
逐步求精：爲了集中精力解決主要問題而儘量推遲對問題細節的考慮。
Miller法則，一個人的注意力的極限是集中注意力在7+-2個事物上。這是對人類能力的研究得到的結果：一個人能力的極限也只能把注意力集中在7+-2個信息塊。這就像人彈跳的極限，人忍受肌餓的極限一樣，是不可改變的客觀因素。它很大程度上限制人的思維能力。
承認自身的侷限性，並在這個前提之下最大化努力的工作。
逐步求精的強大在於，幫助人把精力集中在當下最相關的事物上，忽略、留在以後考慮其他細節。
信息隱藏原理，一個模塊內包含的信息（過程和數據）對於不需要這些信息的模塊是不可訪問的。局部化，把關係密切的軟件元素物理的放得比較近。實際上，應該隱藏的是模塊的實現信息。獨立的模塊之間彼此交換那些爲了完成系統功能必須交換的信息。隱藏原理對於模塊化程序設計有極大的好處，對於測試和維護，修改涉及的錯誤會很少的傳播到其他部分。
2017-2-7
具有獨立功能，與其他模塊之間沒有過多的相互作用的模塊極爲模塊獨立。獨立的模塊易於測試和維護，錯誤傳播範圍小。評判模塊獨立有兩個定性標準度量，內聚和耦合。耦合衡量不同模塊之間互相依賴（連接）的緊密程度。內聚是模塊內元素結合緊密程度。
低耦合便於研究、測試維護任意模塊不需要對其他的模塊瞭解太多。由於模塊間的聯繫簡單，因此錯誤傳播範圍小。一個模塊與另外的模塊完全無關就是無耦合。數據耦合：模塊間通過參數傳遞數據。控制耦合：模塊間傳遞的信息包括控制信息。數據耦合是低耦合，控制耦合是中等程度的耦合，增加了系統的複雜情況。控制耦合往往是多餘的，把模塊適當的分解往往可以用數據耦合取代。
總體設計基本目的是用抽象概括的方式確定系統如何完成預定的任務。
軟件結構設計，確定軟件由哪些模塊組成以及模塊間的調用關係。結構圖和層次圖描述軟件結構。系統-模塊-子模塊。軟件設計應該遵循的主要原理是模塊獨立原則，軟件應該由一組完成相對獨立的子功能的模塊構成，模塊間的接口關係儘量簡單。
抽象和求精是互補的概念，是人類解決複雜問題時最常用和最有效的方法。由抽象到具體構造出軟件的層次結構。
測試，測試的目標是暴露程序中的錯誤，從心理學角度來講，程序的編寫者來測試是不恰當的。
測試的準則：1、建立設計模型以後就能立即開始設計詳細的測試方案；2、先小規模測試，然後逐步大規模，先測試單個程序模塊，然後測試集成模塊，然後測試整個系統。3、窮舉測試不切實際，設計測試方案，覆蓋程序的邏輯。
黑盒測試（功能測試），不考慮程序內部的結構和處理過程。只檢查程序是否能按照需求說明書的規定正常使用，程序是否能適當接收輸入數據併產生正確的輸出數據。
白盒測試（結構測試），完全獲悉程序的結構和處理算法。根據程序內部的邏輯測試程序，檢測主要執行通路是否按照預定的工作。
模塊測試、集成測試、系統測試、驗收測試（用戶參與）、平行測試。平行測試：驗收完成後並不立即投入運行，而是需要將新的系統和舊系統同時運行，比較。優點如下：風險小，意外可控，驗證性能指標。
測試方案中的測試用例不僅僅包括測試使用的測試數據，還有每組數據需要檢測的功能以及預期正確輸出。
2017-2-8
單元測試，檢測軟件的最小單元，即模塊。一般而言單元測試和編碼屬於同一階段。單元測試通常是白盒測試。
測試重點：1、模塊接口，輸入輸出；2、局部數據結構；3、重要執行通路；4、出錯處理通路；5、邊界條件
集成設計，模塊按照設計要求組裝起來測試，主要發現接口有關的問題。漸增式測試，把下一個要測試的模塊同已經測試好的模塊結合起來進行測試，測試完再集合下一個模塊進來。
迴歸測試，重新執行已經執行過的測試，保證由於調試等其他原因引起的變化，不會帶來額外的副作用。
確認測試也是驗收測試，驗證軟件的有效性。軟件的功能和性能如同用戶所期待軟件就是有效的。需求規格說明書是確認測試的基礎。確認測試是用戶參與的黑盒測試。
Alpha測試，用戶在開發者的場所進行，並在開發者的陪同下接受測試，在受控的環境下測試。Beta測試，開發者不在現場。
所謂的測試方案是測試目的（即要測的功能），輸入的測試數據，預期結果。通常把輸入的測試數據，預期結果叫做測試用例。
邏輯測試，有選擇的執行程序中的最具有代表性的通路是對窮盡測試的唯一可行的替代方案。
調試，在錯誤發生排除錯誤的過程。方法：1、回溯法，針對小程序比較有效，從發現症狀的開始，人工沿着程序的控制流追蹤錯誤。2、對半查找法，在調試模塊中央位置注入正確變量值，然後運行程序檢查輸出。
白盒測試和黑盒測試相結合。白盒測試主要技術有邏輯覆蓋和控制結構測試。黑盒測試方案有等價劃分、邊界值分析、錯誤推測。（黑盒測試白盒測試需要單獨處理）
軟件維護：改正錯誤或滿足新的需要而修改軟件的過程。
逆向工程：分析程序以便在代碼抽象層次更高的基礎上把握產品。抽取數據、體系結構、處理過程等信息。
2017-2-10
面向對象的基本原則和思想，儘可能模仿人類的思維方式，模仿人是怎麼認識世界和解決問題的方法和過程，描述問題的問題空間和實現解法的解空間在結構上儘可能一致。
客觀世界的問題是由客觀世界的實體以及實體之間的相互關係構成的。客觀世界的實體既有靜態的屬性，又有動態的行爲。
面向對象認爲1、客觀世界由各種對象組成，任何事物都是對象，複雜的對象是由簡單的對象以某種方式構成的。2、所有對象被劃分爲類，每個類定義了一組數據和方法。3、子類父類之間的繼承關係構成一定的層次結構。4、對象間通過傳遞消息聯繫。私有信息被封裝。
傳統的方法把數據和過程作爲相對獨立的部分，數據代表問題空間的實體，程序代碼用於處理數據。軟件系統的問題空間和解空間並不一致。實際上，計算機解決的問題都是實際問題，實際問題即是相互之間存在聯繫的物體所組成，每個具體的物體都具有屬性和行爲。完整自然的描述客觀世界的實體的方法是同時描述事物靜態的數據結構和動態行爲。
面向對象的思路強調現實世界中的概念，而不是算法。計算機的觀點不重要，現實的模型重要。
對問題領域進行自然的分解，確定要使用的對象和類，建立適當的類等級，按照人們的思維習慣建立問題領域的模型。
傳統的軟件開發方法是瀑布模型，強調自頂向下按部就班，然而人們認知世界的方式是漸進的，繼承之前的知識反覆逐步深化。人的深化過程中包括從一般都特殊的演繹，也包括從特殊到一般的歸納。人們認識和解決複雜問題的思維工具是抽象。