好了，你現在會了面向對象的各種文法了， 但是你會發現很多同學都是學會了面向對象的文法，卻依然寫不出面向對象的程式，原因是什麼呢？原因就是因為你還沒掌握一門面向對象設計利器， 此刻有經驗的人可能會想到瀑布模型、螺旋模型、疊代開發、靈活、RUP等一堆軟體工程相關的軟體開發流程，但對于大部分人來說這些流程僅僅隻是項目管理上的流程.
本節我們就來了解下，作為一名程式員基于面向對象開發程式的開發流程：
需求模型->領域模型->設計模型->實作模型
一，需求模型
1. 需求VS功能
需求：客戶想要的效果，對客戶有價值的事情
功能：系統為了實作客戶的價值而提供的能力/功能
舉例：
汽車：駕駛是需求，刹車、加速、轉彎是功能
列印機：列印是需求，進紙、設定、與電腦連接配接等是功能
pos機：買單是需求，商品掃描、金額彙總、收銀等是功能
2. 需求的重要性
1/3的項目失敗或陷入困境是因為需求原因導緻的
garbage in，garbage out
垃圾上了生産餅幹的流水線，最後産出的是像拉吉一樣的餅幹
修複需求錯誤的問題成本極高
1 編碼階段修複發現一個錯誤耗費人類是1個機關
2 測試階段修複需求錯誤的成本是5-10倍
3 維護階段（産品上線後），修複需求錯誤成本是20倍
ps：在需求階段修複錯誤，成本隻需要0.1-0.2即可
結論：需求錯了，幾乎要把軟體項目重做一遍
3. 需求分析的目的
1 記錄員，記錄客戶的需求
2 分析員，和客戶一起分析，完善需求
3 引導員，能夠引導客戶的需求
4. 需求分析的方法
需求分析518方法，簡稱我要發，具體就是5w1h8c
5w + 1h屬于功能屬性 8c屬于品質屬性
5w：
when:使用者想在什麼時間用，例如半夜備份的任務，很明顯我們得知該需求需要自動化執行
where：使用者想在什麼地方用，例如垃圾桶室内和室外的差別，同樣的事物放到不同地方用肯定不一樣
who：使用者想讓誰來用，不僅是人，也可以是一個系統
what：使用者想要我們程式的輸出結果是什麼，如圖檔，文檔，系統
why：問一問使用者為什麼要這麼做，（你不問，他基本不說），包括客戶所有覺得不爽的事情
ps：why是核心
1h：how
8c：8個constraint限制
性能performance
性能是系統提供相應服務的效率。主要包括響應時間、吞吐量
性能是很多系統架構設計的關鍵限制條件之一
例如，同樣一個web網站，雖然都是提供資訊給使用者流量，設計一個日通路量1w的網站與
日通路量10億的網站，二者的設計截然不同
成本cost
成本指為了實作系統而需要付出的代價
成本也是很多系統架構設計的關鍵限制之一
例如客戶隻願意花100w，而我們卻設計了一個耗費1000w的系統
時間time
指客戶要求什麼時候傳遞
可靠性reliability
指系統長時間正确運作的能力，銀行、證券、電信這些公司，對當機時間要求很嚴格
安全security
指對資訊安全的保護能力，涉及到錢、身份證、社會保險号等需求對這個要求很高
合規性compliance
指滿足各種行業标準、法律法規、規範等，例如3C、SOX、3GPP，ITUT
技術性technology
有的客戶可能要求我們采用某種技術
例如客戶現在都是windows伺服器，要求我們基于windows平台開發
相容性compatibility
指我們的産品與客戶其他已有的産品或系統的相容能力，要知道現在很少有産品是孤立運作的，
特别是在大企業、大公司中，多個系統都是互相互動、互相配合的。新的系統必須能夠和已有
的系統配合，否則将無法運作
5，需求模型之用例的寫法
5.1 寫用例的技巧
三段法：NEA
1 正常處理（normal):分析正常流程
2 異常處理(exception)：分析每一步異常情況和對應的處理
3 替代處理(alternative)：分析每一步是否有其他替代方法，以及如何做
5.2用例的書寫格式
#1. 用例名稱
一般情況下，用例名稱即需求名稱
#2. 場景
場景即用例發生的環境，正好對應5w中的：when，where，who
#3. 用例描述
描述詳細的用例内容，對應5w中的what和how
即使用者應該怎樣做，以及每個步驟中的輸出，但不要求每個步驟都有一定的輸出，可以有也可以沒有，也可以有多個
#4. 用例價值
描述用例對應的客戶價值，對應5w中的why
#5. 限制和限制
即真個需求流程中相關的限制和限制條件，對應518方法中的8C
5.3 用例編寫案例
#用例名
答題系統
#場景：
when：8.10開始
where：西安
who：linux學院，網絡客戶
#用例描述：
linux學院提供50道題
每個客戶無需輸入任何個人資訊就可以參與答題，随機選擇20道題，給客戶回答，每道題5分，
3.答題結束後，輸入手機号，送出，算總分
60分參與抽獎，<60分贈送基礎視訊
#使用者價值：
答題有獎，答題送出時輸入自己的手機号擷取成績，獲得潛在客戶的聯系方式，為後期将客戶轉成學員做準備
#限制：
暫無
二，領域模型
需求分析階段不區分面向對象還是面向過程
領域模型是完成從需求分析到面向對象設計的一座橋梁
領域模型定義：
領域模型是對領域内的概念或現實世界中對象的可視化表示，
又稱為觀念模型，領域對象模型，分析對象模型
它專注于分析問題領域本身，發掘重要的業務領域概念，并建立業務領域概念之間的關系
領域模型主要兩個作用：
1 發掘重要的業務領域概念
2 建立業務領域概念之間的關系
歸納領域模組化的方法:
1 從用例中找名詞（找完後需要删除不是領域對象的名詞，具體删除什麼，
與不同領域有關，沒有統一标準，靠經驗）
2 加屬性（有些屬性并沒有在用例中明确給出，靠行業經驗自己添加）
3 連關系（畫UML圖）
三，設計模型
面向對象類設計的具體步驟
第一步：領域類映射（不是全盤拷貝）
類篩選：并不是每個領域類都會出現在軟體中
名稱映射：對應
屬性映射：對應，照搬
提煉方法：領域類中并沒有方法，在用例中找動詞
第二步：應用設計原則和設計模式
第三步：拆分輔助類（領域類可以在實作階段拆分為幾個類）
四，實作模型
選取一種支援面向對象的語言實作我們的設計，比如c++,java,python
五，答題系統案例
第一步，需求分析（寫用例）
#用例名
答題系統
#場景：
when：8.10開始
where：西安
who：linux學院，網絡客戶
#用例描述：
linux學院提供50道題
每個客戶無需輸入任何個人資訊就可以參與答題，随機選擇20道題，給客戶回答，每道題5分，
3.答題結束後，輸入手機号，送出，算總分
60分參與抽獎，<60分贈送基礎視訊
#使用者價值：
答題有獎，答題送出時輸入自己的手機号擷取成績，獲得潛在客戶的聯系方式，為後期将客戶轉成學員做準備
#限制：
暫無
第二步：領域模型（找名詞，加屬性，連關系===》出圖
2.1 找名詞：
找名詞：
linux學院，題，客戶，得分，獎，視訊
#篩選：去掉與領域無關的名詞。視訊應該算作一種獎品
linux學院，題，客戶，得分，獎
2.2 加屬性：
#加屬性
加屬性
名詞 屬性 備注
linux學院 NA 對于答題系統來說，并不需要linux學院的屬性，是以在領域模型中，linux學院是沒有屬性的
題 題目編号，題目類型，題目描述，答題選項，正确答案，分數
客戶 客戶編号，姓名，性别，年齡，手機号
答題記錄 記錄編号，客戶編号，題目編号清單，總分數，時間 通過答題記錄就可以知道使用者是誰，以及使用者答過的題目
獎品 獎品編号，獎品名字
2.3 連關系：
#連關系：畫圖
1：答題記錄是客戶與題的關系類，而客戶與獎品之間可以建一個關系類，這樣以後單查關系類就可以知道誰得了什麼獎品
2：找動詞：
建立題目
随機選擇題目
答題
送出
算總分
抽獎
2.4 出圖
第三步：設計模型
第四步：實作模型
連結: https://pan.baidu.com/s/1jHYFKWI 密碼: wimc
六，UML圖
UML-Unified Model Language 統一模組化語言，又稱标準模組化語言。是用來對軟體密集系統進行可視化模組化的一種語言。UML的定義包括UML語義和UML表示法兩個元素。
UML是在開發階段，說明、可視化、建構和書寫一個面向對象軟體密集系統的制品的開放方法。最佳的應用是工程實踐，對大規模，複雜系統進行模組化方面，特别是在軟體架構層次，已經被驗證有效。統一模組化語言（UML）是一種模型化語言。模型大多以圖表的方式表現出來。一份典型的模組化圖表通常包含幾個塊或框，連接配接線和作為模型附加資訊之用的文本。這些雖簡單卻非常重要，在UML規則中互相聯系和擴充。
主要模型
在UML系統開發中有三個主要的模型：
UML圖功能模型
從使用者的角度展示系統的功能，包括用例圖。
UML圖對象模型
采用對象、屬性、操作、關聯等概念展示系統的結構和基礎，包括類圖、對象圖、包圖。
UML圖動态模型
展現系統的内部行為。 包括序列圖、活動圖、狀态圖。
圖的功能
綜述
UML是資料庫設計過程中，在E-R圖（實體-聯系圖）的設計後的進一步模組化。
要了解一下UML設計中有的圖例及基本作用。首先對UML中的各個圖的功用做一個簡單介紹：
用例圖
描述角色以及角色與用例之間的連接配接關系。說明的是誰要使用系統，以及他們使用
該系統可以做些什麼。一個用例圖包含了多個模型元素，如系統、參與者和用例，
并且顯示了這些元素之間的各種關系，如泛化、關聯和依賴。
類圖
類圖是描述系統中的類，以及各個類之間的關系的靜态視圖。能夠讓我們在正确編寫
代碼以前對系統有一個全面的認識。類圖是一種模型類型，确切的說，是一種靜态模型
類型。類圖表示類、接口和它們之間的協作關系。
對象圖
與類圖極為相似，它是類圖的執行個體，對象圖顯示類的多個對象執行個體，而不是實際的類。
它描述的不是類之間的關系，而是對象之間的關系。
包圖
包圖用于描述系統的分層結構，由包或類組成，表示包與包之間的關系。
活動圖
描述用例要求所要進行的活動，以及活動間的限制關系，有利于識别并行活動。
能夠示範出系統中哪些地方存在功能，以及這些功能和系統中其他元件的功能如何
共同滿足前面使用用例圖模組化的商務需求。
狀态圖
描述類的對象所有可能的狀态，以及事件發生時狀态的轉移條件。可以捕獲對象、
子系統和系統的生命周期。他們可以告知一個對象可以擁有的狀态，并且事件(如消息
的接收、時間的流逝、錯誤、條件變為真等)會怎麼随着時間的推移來影響這些狀态。
一個狀态圖應該連接配接到所有具有清晰的可辨別狀态和複雜行為的類；該圖可以确定類
的行為，以及該行為如何根據目前的狀态變化，也可以展示哪些事件将會改變類的對
象的狀态。狀态圖是對類圖的補充。
序列圖（順序圖）
序列圖是用來顯示你的參與者如何以一系列順序的步驟與系統的對象互動的模型。
順序圖可以用來展示對象之間是如何進行互動的。順序圖将顯示的重點放在消息序列上，
即強調消息是如何在對象之間被發送和接收的。
協作圖
和序列圖相似，顯示對象間的動态合作關系。可以看成是類圖和順序圖的交集，協作圖建
模對象或者角色，以及它們彼此之間是如何通信的。如果強調時間和順序，則使用序列圖；
如果強調上下級關系，則選擇協作圖；這兩種圖合稱為互動圖。
構件圖（元件圖）
描述代碼構件的實體結構以及各種建構之間的依賴關系。用來模組化軟體的元件及其互相之間
的關系，這些圖由構件标記符和構件之間的關系構成。在元件圖中，構件是軟體單個組成部分，
它可以是一個檔案，産品、可執行檔案和腳本等。
部署圖（配置圖）
是用來模組化系統的實體部署。例如計算機和裝置，以及它們之間是如何連接配接的。部署圖的使
用者是開發人員、系統內建人員和測試人員。部署圖用于表示一組實體結點的集合及結點間的
互相關系，進而建立了系統實體層面的模型。
一：這十種模型圖各有側重
1:用例圖側重描述使用者需求，
2:類圖側重描述系統具體實作；
二：描述的方面都不相同
1:類圖描述的是系統的結構，
2:序列圖描述的是系統的行為；
三：抽象的層次也不同
1：構件圖描述系統的子產品結構，抽象層次較高，
2：類圖是描述具體子產品的結構，抽象層次一般，
3：對象圖描述了具體的子產品實作，抽象層次較低。
在有的文獻書籍中，将這九種模型圖分為三大類：
結構分類、動态行為和模型管理：
1：結構分類包括用例圖、類圖、對象圖、構件圖和部署圖，
2：動态行為包括狀态圖、活動圖、順序圖和協作圖，
3：模型管理則包含類圖。
類圖中通過加号(+)來表示 public
通過減号(-)表示 private
通過井号(#)表示 protected
七，作業練習
詳細請看：http://www.cnblogs.com/wj-1314/p/8707772.html
八，面向對象原則：高内聚，低耦合
軟體設計中通常用耦合度和内聚度作為衡量子產品獨立程度的标準，劃分子產品的一個準則就是高内聚低耦合。
這是軟體工程中的概念，是判斷設計好壞的标準，主要是面向OO的設計，主要是看類的内聚性是否高，耦合度是否低。
每一個類完成特定的獨立的功能，這就是高内聚，耦合就是類之間的互相調用關系，如果耦合很強，互相牽扯調用很多，那麼會牽一發而動全身，不利于維護和擴充。
類之間的設定應該要低耦合，但是每個類要高内聚，耦合就是類之間互相依賴的尺度，如果每個對象都有引用其他所有的對象，那麼就有高耦合，這是不合乎要求的，因為在兩個對象之間，潛在性地流動了太多的資訊，低耦合是合乎要求的：它意味着對象彼此之間更獨立的工作，低耦合最小化了修改一個類而導緻也要修改其他類的“連鎖反應”。内聚是一個類中變量與方法連接配接強度的尺度.高内聚是值得要的,因為它意味着類可以更好地執行一項工作.低内聚是不好的,因為它表明類中的元素之間很少相關.成分之間互相有關聯的子產品是合乎要求的.每個方法也應該高内聚.大多數的方法隻執行一個功能.不要在方法中添加’額外’的指令,這樣會導緻方法執行更多的函數.
什麼是耦合
耦合性也稱塊間聯系。指軟體系統結構中各子產品間互相聯系緊密程度的一種度量。子產品之間聯系越緊密，其耦合性就越強，子產品的獨立性則越差。子產品間耦合高低取決于子產品間接口的複雜性、調用的方式及傳遞的資訊。
耦合度就是某子產品（類）與其它子產品（類）之間的關聯、感覺和依賴的程度，是衡量代碼獨立性的一個名額，也是軟體工程設計及編碼品質評價的一個标準。耦合的強度依賴于以下幾個因素：
- （1）一個子產品對另一個子產品的調用；
- （2）一個子產品向另一個子產品傳遞的資料量；
- （3）一個子產品施加到另一個子產品的控制的多少；
- （4）子產品之間接口的複雜程度。
耦合分類
耦合按從強到弱的順序可分為以下幾種類型：
a)非直接耦合：兩子產品間沒有直接關系，之間的聯系完全是通過主子產品的控制和調用來實作的
b)資料耦合：指兩個子產品之間有調用關系，傳遞的是簡單的資料值，相當于進階語言的值傳遞;
c)标記耦合：指兩個子產品之間傳遞的是資料結構，如進階語言中的數組名、記錄名、檔案名等這些名字即标記，其實傳遞的是這個資料結構的位址;
d)控制耦合：一指一個子產品調用另一個子產品時，傳遞的是控制變量（如開關、标志等），被調子產品通過該控制變量的值有選擇地執行塊内某一功能;
e)外部耦合：一組子產品都通路同一全局簡單變量而不是同一全局資料結構，而且不是通過參數傳遞該全局變量的資訊
f)公共耦合：一組子產品都通路同一個公共數
據環境。該公共資料環境可以是全局資料結構、共享的通信區、記憶體的公共覆寫區等。
g)内容耦合：這是最高程度的耦合，也是最差的耦合。當一個子產品直接使用另一個子產品的内部資料，或通過非正常入口而轉入另一個子產品内部。
為什麼要低耦合（解耦合）
在面向對象程式設計中，對象自身是内聚的，是保管好自己的資料，完成好自己的操作的，而對外界呈現出自己的狀态和行為。但是，沒有絕對的自力更生，對外開放也是必要的！一個對象，往往需要跟其他對象打交道，既包括獲知其他對象的狀态，也包括仰賴其他對象的行為，而一旦這樣的事情發生時，我們便稱該對象依賴于另一對象。隻要兩個對象之間存在一方依賴一方的關系，那麼我們就稱這兩個對象之間存在耦合。 比如媽媽和baby，媽媽要随時關注baby的睡、醒、困、哭、尿等等狀态，baby則要仰賴媽媽的喂奶、哄睡、換紙尿褲等行為，從程式的意義上說，二者互相依賴，是以也存在耦合。首先要說，耦合是必要的。
耦合的程度就是耦合度，也就是雙方依賴的程度。上文所說的媽媽和baby就是強耦合。而你跟快遞小哥之間則是弱耦合。一般來說耦合度過高并不是一件好事。就拿作為IT精英的你來說吧，上級随時敦促你的工作進度，新手頻繁地需要你指導問題，隔三差五還需要參加酒局飯局，然後還要天天看上司的臉色、關注老婆的心情，然後你還要關注代碼中的bug 、bug、bug，和需求的變化、變化、變化，都夠焦頭爛額了，還猝不及防的要關注眼睛、頸椎、前列腺和頭發的狀态，然後你再炒個股，這些加起來大概就是個強耦合了。從某種意義上來說，耦合天生就與自由為敵，無論是其他對象依賴于你，還是你依賴其他對象。比如有人嗜煙、酗酒，你有多依賴它們就有多不自由；比如有人家裡生了七八個娃，還有年邁的父母、嶽父母，他們有多依賴你，你就有多不自由。是以老子這樣講：“五音令人耳聾，五色令人目盲，馳騁狩獵令人心發狂，難得之貨令人行妨。”盧梭也是不無悲涼的說“人生而自由，卻又無往而不在枷鎖中”。是以，要想自由，就必須要降低耦合，而這個過程就叫做解耦和。
耦合度很高的情況下，維護代碼時修改一個地方會牽連到很多地方，如果修改時沒有理清這些耦合關系，那麼帶來的後果
可能會是災難性的，特别是對于需求變化較多以及多人協作開發維護的項目，修改一個地方會引起本來已經運作穩定的子產品錯誤，嚴重時會導緻惡性循環，問題永遠改不完，開發和測試都在各種問題之間奔波勞累，最後導緻項目延期，使用者滿意度降低，成本也增加了，這對使用者和開發商影響都是很惡劣的，各種風險也就不言而喻了。
如何降低耦合（解耦合）
- 少使用類的繼承，多用接口隐藏實作的細節。 Java面向對象程式設計引入接口除了支援多态外， 隐藏實作細節也是其中一個目的。
- 子產品的功能化分盡可能的單一，道理也很簡單，功能單一的子產品供其它子產品調用的機會就少。（其實這是高内聚的一種說法，高内聚低耦合一般同時出現，為了限制篇幅，我們将在以後的版期中讨論）。
- 遵循一個定義隻在一個地方出現。
- 少使用全局變量。
- 類屬性和方法的聲明少用public，多用private關鍵字，
- 多用設計模式，比如采用MVC的設計模式就可以降低界面與業務邏輯的耦合度。
- 盡量不用“寫死”的方式寫程式，同時也盡量避免直接用SQL語句操作資料庫。
- 最後當然就是避免直接操作或調用其它子產品或類（内容耦合）；如果子產品間必須存在耦合，原則上盡量使用資料耦合，少用控制耦合，
- 限制公共耦合的範圍，避免使用内容耦合。
什麼是内聚
内聚，通俗的來講，就是自己的東西自己保管，自己的事情自己做。每個子產品盡可能獨立完成自己的功能，不依賴于子產品外部的代碼。
對象是什麼？對象就是保管好自己的東西，做好自己的事情的程式子產品——這就是内聚！當然，對象的内聚隻是内聚的一個層次，在不同的尺度下其實都有内聚的要求，比如方法也要講内聚，架構也要講内聚。
内聚： 内聚性又稱塊内聯系。指子產品的功能強度的度量，即一個子產品内部各個元素彼此結合的緊密程度的度量。若一個子產品内各元素（語名之間、程式段之間）聯系的越緊密，則它的内聚性就越高。
高内聚:類與類之間的關系而定，高，意思是他們之間的關系要簡單，明了，不要有很強的關系，不然，運作起來就會出問題。一個類的運作影響到其他的類。由于高内聚具備魯棒性，可靠性，可重用性，可讀性等優點，子產品設計推薦采用高内聚。
内聚度是指内部各元素之間聯系的緊密程度，子產品的内聚種類通常可分為7種，按其内聚度從低
到高的次序依此為：偶然内聚、邏輯内聚、瞬時内聚、過程内聚、通信内聚、順序内聚、功能内聚。
- 1 偶然内聚: 指一個子產品内的各處理元素之間沒有任何聯系。
- 2 邏輯内聚: 指子產品内執行幾個邏輯上相似的功能，通過參數确定該子產品完成哪一個功能。
- 3 時間内聚: 把需要同時執行的動作組合在一起形成的子產品為時間内聚子產品。
- 4 通信内聚: 指子產品内所有處理元素都在同一個資料結構上操作（有時稱之為資訊内聚），或者指各處理使用相同的輸入資料或者産生相同的輸出資料。
- 5 順序内聚: 指一個子產品中各個處理元素都密切相關于同一功能且必須順序執行，前一功能元素輸出就是下一功能元素的輸入。
- 6 功能内聚: 這是最強的内聚，指子產品内所有元素共同完成一個功能，缺一不可。與其他子產品的耦合是最弱的。
不經一番徹骨寒 怎得梅花撲鼻香