設計階段
實現階段
總結軟體設計是軟體工程中技術方向部分，軟體工程大方向上劃分，包含管理方向和軟體設計方向。管理方向，主要指軟體迭代、資源管理等專案進度、巨集觀質量把控方面，涉及理論知識，書籍，如《敏捷迭代開發：管理者指南》、《敏捷軟體開發的組織模式》、《軟體專案管理：乙個統一的框架》、《oo專案求生法則》。
該總結主要總結軟體涉及部分。軟體合理設計是專案成功的核心，合理的設計使軟體具備靈魂，專案才預示著成功。該部分包含：需求分析、領域建模、軟體架構、詳細設計、單元測試、**重構。按照現在經過行業驗證和總結出來的結論：該過程不是瀑布式的，整體是乙個迭代過程，不同的迭代階段，偏重點不同，整體偏重點逐漸後移。如圖1：
該總結主要來自《uml和模式應用》、《設計模式》兩本書，前一本主要介紹了up敏捷開發思想，其中grasp（職責驅動設計）尤為可貴。基於物件導向設計6原則和grasp，設計模式做了完美的補充，前面的是思想，後面的是具體方案，方案詳細的詮釋思想。
物件導向思想包含：物件導向分析、物件導向設計、物件導向程式設計。不同階段涉及知識如下表：
設計階段
指導思想
需求分析、領域建模
用例分析、領域建模、活**
軟體架構、詳細設計
ssd、設計6原則、grasp、設計模式
編碼設計6原則、grasp、設計模式、重構、單元測試
製品及模型演變過程，如圖2：
分析階段核心是發現業務用例、領域概念，並合理構建領域概念間關係（即領域模型）。在一些軟體設計方法中，認為熟悉的領域，可以使用用例驅動設計，經過深入學習和體會，個人認為領域模型至關重要，從最新的設計思想–領域驅動設計，也體現了領域建模有著很高的價值。
對於乙個陌生領域，核心場景入手，畫活**，發現需要核心業務用例，用例在用例圖中體現；畫活**同時，可以深入了解領域中專業的領域概念，活**結束後，可以輸出用例圖和領域概念，深入分析活**體現的場景，構建合理的領域模型。對於乙個陌生領域，很少能一次獲取所有用例和構建玩領域模型，這個隨著軟體迭代及系統順序圖（ssd）等深入分析，迴圈迭代式完善用例及領域模型，迭代方式如下圖：
前期活**輸出用例圖及粗略的領域模型，用例圖體現領域邊界並在領域模型中適當表達，如一些系統的參與者等；隨著用例的完善，使用用例規約，合理構建領域概念間關聯關係。
有助於工作流和業務過程視覺化。因為用例覆蓋過程和工作流分析，所以活**能夠成為編寫用例文字的有用的輔助措施，對於那些描述複雜的工作流的業務用例來說更是如此，因為其中涉及大量參與者和併發活動。
畫活**過程中，會發現領域概念和熟悉領域業務流程。有助於用例、領域模型的構建。認識領域過程，首先有主流程活**，然後根據場景梳理其他活**。
參與者：某些具有行為的事物，可以是人、計算機系統或組織。
場景：參與者與系統之間的一系列特定情節或用例的一條執行路勁。
用例：就是一組相關成功和失敗的場景集合，用來描述參與者如何使用系統來實現其目標。
用例就是需求，主要是說明系統如何工作的功能性或行為性需求。按照「furps+」需求型別，用例強調了「f」（功能性和行為性）。編寫用例準則如下：
編寫簡介用例
編寫黑盒用例
採用參與者和參與者目標的視點（目標和典型情況，行為結果價值）
發現用例（明確參與者（即邊界）、主要參與者和其目標）
用例名稱用動詞開頭
有用用例測試（老闆測試、ebp測試、規模測試）。
用例圖體現系統邊界及主要系統功能，方便開發迭代紀錄，從主要用例場景迭代逐漸完善系統和豐富用例。系統邊界體現在系統有哪些使用者。軟體迭代過程，初始確定大部分用例名稱，詳細分析確定架構和有風險用例。在以後的迭代中，每次以10%重要用例分析迭代。
指導用例編寫書籍有《編寫有效用例》（writing effective use case)、有效用例模式（patterns for effective use case)、《用例建模》（use case modeling）、《需求協同：定義需求的討論會》、《用例：通過背景環境獲取需求》。
領域建模過程非瀑布式，建立整個系統的完整模型。確定系統主要場景，按照用例場景分析，系統按照用例量迭代，領域模型也隨著用例迭代，領域模型可以是草圖，個人認為領域模型比較重要，建議儲存，大型系統的模型迭代過程最好儲存。
建立領域概念間的關聯，是領域模型的關鍵，隨著關聯關係梳理清楚，即時乙個陌生領域也會逐漸清晰。這也是領域建模的價值體現。
類名：概念類類名
屬性：必要屬性的非必須的
重用、修改現有的模型。參考《分析模式》
使用分類列表
用例規約中確定名詞短語
建立領域概念間的關聯，是領域模型的關鍵，隨著關聯關係梳理清楚，即時乙個陌生領域也會逐漸清晰。這也是領域建模的價值體現。
該階段使用設計思想和方法，把領域模型轉化為設計模型，指導開發編碼。此階段核心關注：低耦合、高內聚、可擴充套件。主要指導思想和方法為：grasp職責驅動設計、軟體設計6原則和設計模式。除了這些，還有很多原則，很多實際上是場景特化或者相同思想不同稱呼，不必開始就完全掌握，隨著深入學習，逐漸了解掌握；設計模式實際是對思想的應用，也是對經常出現的場景的總結，掌握設計模式，可以快速有限的提高軟體質量和程式設計質量，核心還是思想。
從分析模型轉為設計模型，設計模型演化過程如下（圖3）：
描述外部參與者如何與建立的系統機型互動。確定是系統事件。在領域模型基礎上，利用ssd，從需求分析轉向軟體設計。確定系統事件後，使用grasp職責驅動設計思想，領域模型轉為軟體類圖（領域層）。
也即規格說明（軟體）透檢視，表示方法同領域模型的類圖。用來描述軟體的抽象物或具有規格說明和介面的構件，但是並不約束特定實現。
結合設計模式、軟體設計6原則，優化軟體類圖為設計類圖。複雜用例，可以結合順序圖或通訊圖及其他動態圖，如狀態圖等完善優化類圖。在編寫詳細設計文件中，順序圖等動態圖也很重要，類圖是結果，動態圖是分析過程，有助於回顧或參考梳理思路。
按照迭代計畫，完成迭代設計**。實現過程中嚴格參考程式設計規範，減少ide檢測**後的重構工作。**檢測工具，如專業的工具sourcemonitor，及ide整合的檢測工具，如android studio中的**質量檢測功能。**實現過程中，根據實際情況，可能還會抽象出一些工具類等，按照設計思想和方法設計即可。
為確保編碼效率和質量，核心功能建議做好單元測試，有些人認為測試就是測bug的，沒必要做單元測試。我不認為，從乙個點時間看，做單元測試不能提高開發效率，但是從整個軟體生命週期看，做好單元測試，不僅降低核心功能設計風險，而且提高軟體開發效率和質量。單元測試的框架也有很多，也足以說明單元測試的重要性，junit、android自身提供的方法等。
重構主要是通過重構工具檢測不良**實現，確保完成高質量**，也是乙個培養良好習慣的過程。好的**也可以在一定程度提高軟體質量、維護效率等。**檢測基本是乙個自動化過程，因此不需要太為檢測鬧心，只需要搭建好的檢測環境和使用正確的工具，重構過程網上也有很多指導方法，工具檢測結果也會給出指導性說明。
好的設計也需要高質量的**，設計是骨，**是血肉，任何乙個不好，都不會有個健壯的軟體。
物件導向設計是乙個不斷實踐，持久學習的過程。經過對uml、《uml和模式應用》的學習，了解了軟體設計的流水線，對於乙個新的專案，不至於摸著石頭過河，在開發中有了指向和原則。生命不息，學習不止，再接再厲。
物件導向學習總結
物件導向繼承 繼承 是指以個類為父類，另乙個類可以做為其子類，子類在繼承了父類的屬性 方法，可以進一步操作。語法 extends 子類 extends 父類 public 公共的 private 私有的，protected保護的，private保護，你可以繼承，但不可以訪問和操作。對於protect...
學習物件導向總結
實現多型的步驟 1 找出父類 2 找出所有子類都具有的相同方法 但是實現方式各不一樣 3 將這個方法在父類中標記為虛方法或抽象方法 4 在子類中重寫 5 讓父類變數指向子類物件 父類型別作為引數，作為返回值 6 呼叫父類變數的虛方法 抽象方法 虛方法 繼承 多型 封裝 1 抽象用abstrace修飾...
物件導向學習總結
一 物件導向基礎概念 類和例項介紹 1.定義 物件導向程式設計 object oriented programming，簡稱oop，是一種程式設計思想。oop把物件作為程式的基本單元，乙個物件包含了資料和運算元據的函式。python中，所有資料型別都可以視為物件，當然也可以自定義物件。自定義的物件資...