軟體開發是什麼、如何做

zhanggongying發表於2014-02-25
一、軟體開發是什麼

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

“人腦中的系統模型”可以比喻成導演腦中的電影，在真正拍攝之前，導演會在自己的腦中播放，然後透過演員、道具等再現一遍。抑或比喻成電器設計師腦中的電器裝置，在投產之前，在設計師腦中是有完整的電器模擬的。

將 “人腦中的系統模型”變成可以在計算機系統中可執行的系統的過程即為軟體開發。

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

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



二、軟體開發如何做

最開始，計算機只能用於一些科學計算，只能將人腦中的計算過程模型放到計算機中執行，軟體開發的思考方式很自然地是程式導向的，這一階段的程式語言也是程式導向的。後來的結構化程式設計也只是程式碼層面的最佳化，即“改善程式的明晰性、品質，並且避免寫出麵條式程式碼”。

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

針對這些問題，物件導向思維開始興起。物件導向程式設計起源於 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）物件之間通訊方式有多種：同步、非同步、直接、間接、一對多、多對一、多對多等等，但都不是直接的方法呼叫，而是傳送訊息

相關文章