需求是引起設計變化的源動力。
沒有需求的變化，任何已經完成原有功能的軟體在設計上，都沒有變化的必要了，無論原先的設計是好的還是糟糕的。需求變化了，為什麼要修改原有的設計，可不可以不修改原有設計。答案是可以的，然而為什麼要修改，或者說完善原有的設計，讓原有設計朝著適應需求變化的方向發展。因為原有設計不能滿足軟體需求變化的需要。就要修改原有設計。
好的設計是什麼？
在需求變化時，只做新增**，而不去修改原有已經存在的**。這樣的設計具有彈性--可以迎接新的需求。具有可維護性--原有**和新**之間的耦合性很小。原有**中的bug，經過幾輪測試之後，越來越少。bug的數量承收斂狀態，逐漸趨於收斂。這就好比蓋樓的時候，一層蓋好了，再建第二層的時候，不用將重新加固第一層的樓的牆壁，來支撐第二層（把第一層拆掉重新蓋的可能性很少）。好的設計在於只是針對新的需求，增加新的**，而不是修改原有的**以適應需求。如何才能做好這一切呢。
為什麼要進行分析和設計？
當然人們需要功能更強大的軟體來滿足自己的需求，以不斷的提高自己的生產力的時候，出現了物件導向語言。這種語言能夠更好的描述現實中的事物，而且相比結構化語言更貼切。物件導向語言出現之後，隨之而來的是物件導向設計和分析方法。這些方法都是為了實現更大規模的軟體而出現的。軟體開發在這個時期，脫離了原有的小作坊式的開發方式，出現了大規模團隊開發的方式，這時也出現了軟體開發的工程方法和管理方式。這個時期的軟體開發不再是單兵作戰，為了在更短的時間內完成更多的使用者需求，團隊合作被高度重視。另一方面，由於軟體越來越大，**量越來越多，軟體質量也被重視起來，人們開始明白軟體的缺陷發現的越早，成本就會越低的道理，所以軟體開發的前期分析和建模就顯得很重要了，因為這時候的成本是最低的。
無論是團隊開發還是前期分析，都離不開軟體的建模。有了模型大家都不再用憑空想想，溝通起來也方便很多。模型中子系統和子系統之間的互動關係，子系統內部模組之間的互動關係，以及模組中類之間的互動關係都通過對軟體的建模，討論清楚。可以想象如果，拿到需求直接寫**，寫完**之後再討論類之間、模組之間、子系統之間的關係。結果會是如何？系統是否得到了足夠的驗證？軟體越大、越複雜，內部的關聯關係就越複雜。寫**之前所要考慮的方面就會越多。所以，拿到需求之後，不是直接寫**來滿足使用者需求,而是分析和設計。
盲人摸象的道理，大家都是知道的。要開發的系統，對於我們來說就是乙隻大象，我們就那些盲人。如果我們只考慮到我們自己的需求和現有的需求，那麼我們「摸出」的「象」會是什麼樣子呢？是使用者要的嗎？不滿足使用者需求的軟體就是存在邏輯上的bug。但是，我們現在有方法學（呵呵，這點比那些盲人強多了），我們可以分別按照自己的理解構造乙個「象」的模型出來，然後通過討論，最後設計出乙隻最像「象」的模型出來。這樣就可以使我們的軟體和使用者的實際需求最接近了。在以後的日子裡，我們可以根據這個模型來繪製自己心中的那只大象了。這也正式軟體需要架構、子系統、模型、類的設計理由。至於我們用來分析和設計的統一建模語言（uml），只是為了讓大家都有共同的溝通工具。想想如果每個人都會自己構造的「象」用一種語言來描述，那麼溝通中會有增加多少麻煩？統一建模語言給大家帶來標準的溝通方式外，還具有很強的擴充套件性和表達能力。
自動軟體設計
在1973年，美國人peter freeman在他的文章 自動軟體設計 automating software design 中有這樣的假設 如果有這樣一台機器 當我們告訴它我們需要什麼軟體的時候，它立刻就會滿足我們的要求，自動生成我們需要的程式。這台機器我稱之為萬能機。當我們提出需求的時候，需要關...
軟體設計原則
開閉原則 ocp 軟體設計的最大原則 這個原則說的是 對擴充套件開放，對修改關閉。其實意思是說，給系統新增新的功能，但不修改原有 如果能做到呢，關鍵在於抽象化，也就是封裝變化，抽象層不變，讓具體實現依賴抽象隨需求變化。使得系統具有很強的擴充套件性和可維護性。黎克特制代換原則 任何基類可以出現的地方，...
軟體設計原則
高內聚 低耦合 乙個軟體系統要有乙個穩定的架構，不會隨需求的改變而發生巨大的變動。因此，高內聚 低耦合是乙個軟體系統設計中必須遵循的基本原則 面向抽象程式設計 在面向過程的軟體開發中，上層元件呼叫下層元件，就意味著上層元件依賴於下層元件，當下層元件發生劇烈變化時，上層元件也要跟著一起發生變動，這將導...