軟件開發是什麼、如何作

From:http://www.jdon.com/46159

-------------------------------------------------------------------------------------------------------------

1、軟件開發是什麼

有形的工具是人類肢體的延伸；計算機系統則是人類大腦的延伸：
將人腦中的系統模型放到計算機系統中運行，從而將人腦解放出來作更有價值的事情。

「人腦中的系統模型」能夠比喻成導演腦中的電影，在真正拍攝以前，導演會在本身的腦中播放，而後經過演員、道具等再現一遍。抑或比喻成電器設計師腦中的電器設備，在投產以前，在設計師腦中是有完整的電器仿真的。

將 「人腦中的系統模型」變成能夠在計算機系統中可運行的系統的過程即爲軟件開發。

設計師腦中的電器模型必須和當前的生產工藝和技術水平相適應才能生產出產品，超前設計只能停留在概念階段；導演天馬行空的想象若是超越現實的拍攝技術限制也沒法拍成電影。 「人腦中的系統模型」要最終變成可運行的計算機系統也受到計算機技術發展水平的限制（包括硬件技術和軟件技術的限制），必須作一些適應性的調整，咱們只是但願隨着計算機技術的發展，這樣的調整幅度愈來愈小，不要讓咱們的設想被迫打個折扣。

在計算機技術發展初期，計算機只能作一些科學計算，人類只能將一些「科學計算模型」交由計算機實現；隨着計算機技術的發展，能夠勝任更復雜的任務時，咱們但願計算機系統可以幫助咱們作更多事情，不只僅是計算，還能作一些管理工做或處理一些繁瑣的事務。



2、軟件開發如何作

最開始，計算機只能用於一些科學計算，只能將人腦中的計算過程模型放到計算機中運行，軟件開發的思考方式很天然地是面向過程的，這一階段的編程語言也是面向過程的。後來的結構化編程也只是代碼層面的優化，即「改善程序的明晰性、品質，而且避免寫出麪條式代碼」。

隨着計算機硬件技術的發展和計算能力、存儲能力的提升，計算機被應用到更多的領域，這些領域內的模型已經不是線性的了，而是立體的有層次的，可是軟件世界中因爲受歷史編程語言和編程思想的限制，還再繼續用面向過程的編程思想和編程語言刻畫人腦中模型，這中間須要進行轉換——將立體的有層次的模型轉換成線性的過程模型，二者之間不能天然銜接。程序自己也由於不能直接反映人腦中的模型而顯得晦澀難懂。

針對這些問題，面向對象思惟開始興起。面向對象編程起源於 Doug Englebart的觀點：計算機是人類大腦的延伸。Alan Kay's Dynabook 後來建立了一門編程語言（Smalltalk）將他的觀點經過代碼實現。實際上，這位面向對象編程的先鋒的目的就是用代碼捕捉人們頭腦中的模型。今天，圖形交互界面的繁榮和麪向對象語言的控制地位正是當年這些面向對象思惟的結果。

可是"用代碼捕捉人們頭腦中的模型"的目標到目前也沒有徹底實現，當前處於控制地位的面向對象編程語言如Java，C++,C#等都不能很好的捕獲人腦中的模型。

人腦中模型大致上能夠分爲有生命的動態模型（人、組織和動物等）、響應式靜態模型（機器、電子設備等）和徹底靜態模型（建築、結構等）。現代的計算機系統通常是代替人類去處理事務，相似一我的或組織，刻畫的是人腦中的「有生命的動態模型」。 計算機系統有時也用於一些仿真、模擬等，刻畫的是人腦中的「響應式靜態模型和徹底靜態模型」。現代編程語言能夠很好地刻畫後兩個模型，但不能很好地刻畫「有生命的動態模型」。現代面向對象編程語言中的對象和「響應式靜態模型和徹底靜態模型」很接近，都是沒有生命的，只在線程看到它並調用它時纔有曇花一現的執行過程，即使如此現代面向對象編程語言在刻畫靜態模型時仍是有不少問題，好比人類中的「響應式靜態模型和徹底靜態模型」多是一個電子設備，受到物理和幾何特性的限制，組成電子設備的各組件之間是鬆耦合高內聚的，組件接口清晰、明確，組件之間的組裝很是天然、容易。可是咱們的程序中的對象卻常常不是鬆耦合高內聚的，咱們總認爲比大天然可以作的更好，卻每每陷入困境。因此才產生了那麼多的設計原則、設計模式等來指導咱們進行設計。

雖然經過設計原則、設計模式等的指導，咱們能夠比較完美的刻畫人腦中的「響應式靜態模型和徹底靜態模型」，可是在刻畫「有生命的動態模型」時仍是有些先天不足，語言層面不支持捕獲模型中有生命的對象、角色變化和通訊方式等。好比組織單位中的每一個人是獨立的有生命的對象，其角色多是多重的或可變換的，人與人之間的交流多是直接的、同步的、異步的或間接經過對話機制進行交流。這些模型還沒法經過現代面嚮對象語言直接進行表達。

將人腦中的模型放到計算機系統中運行的一個理想過程多是這樣的：
（1）人腦首先發揮其長處按照天然的方式（不按程序思惟或計算機思惟）創建業務模型
（2）業務模型不斷細化成爲能夠完成業務需求的模型系統，並可以在人腦中順暢的演繹運行。這個階段應該輸出最終的詳細模型。
（3）計算機系統理解上一步輸出的詳細模型併發揮計算機相對於人腦的優點更好的運行這個模型，提供模型中預先定義的服務。

在（2）和（3）之間理想狀況應該如上述那樣無縫銜接，或者至少可以比較天然、容易地進行銜接。可是現代的編程語言還不能很好的刻畫人腦中的模型以達到天然地、容易地進行銜接的目的。下面就來談談現代面嚮對象語言的問題。

（一）、現代面嚮對象語言的是與非

1. 封裝泄露問題
（1）對象的私有屬性可能就是對象
（2）全部對象都生活在人人均可訪問的堆空間中

私有屬性可能會被共享出去——有時是故意設計成這樣，但經常是意外的（咱們只須要將屬性對象的引用傳遞出去），不管哪一種緣由，都意味着失去了對私有屬性的本地控制，也失去了本地簡單推理的的正確性，數據封裝容易破壞。表面上某個對象只能經過其公開的方法訪問私有屬性，可是卻有不少隱藏的方式（直接修改私有屬性引用的對象、經過反射機制訪問私有屬性等）訪問到私有屬性。

2. 內部狀態一致性問題
即使對象的私有屬性是原始類型（如int, long等），也不能保證安全，例以下面的類A：


class A
{
private int count;
Thing thing = new Thing();
public void method1()
{
.....
count = 42;
thing.f();
......
}

}

method1中count=42;thing.f()執行以後，count的值時多少呢？沒法肯定，由於thing.f()調用可能會修改count的值。這種不肯定性有時防不勝防，就像咱們似曾相識的全局變量問題。

上述的對象問題致使咱們看到的（頭腦中的模型）和實際執行的（計算機系統模型）不同，很容易犯錯，犯了錯還意識不到。

3. 現代面嚮對象語言中的對象和咱們OO思想中的對象不同
（1）全部的對象都是死的，沒有本身的生命
（2）全部的對象方法必須由外部線程調用--他們必須面向調用者
（3）任意看見對象的線程均可以調用對象的方法，對象自己不能阻止對方法的調用
（4）即便對象自己處於不合適的狀態下，也不能阻止別人的訪問，對象沒法控制本身
（5）每一個線程在調用對象方法時帶給對象曇花一現的生命
（6）線程能夠隨意穿越對象的邊界，絕不關注底層結構的狀態是否失衡



（二）、迴歸面向對象思想
（1）對象封裝數據和操做數據的算法
（2）對象中的數據和算法是私有的，外界沒法看到數據，也不能直接執行組件中的方法 
（3）對象有本身的生命（線程），對象中的算法有內部生命體執行
（4）對象之間通訊方式有多種：同步、異步、直接、間接、一對多、多對1、多對多等等，但都不是直接的方法調用，而是發送消息