軟體設計深度挖掘(一) (轉)

軟體設計深度挖掘(一) (轉)[@more@]

設計深度挖掘

一 從軟體工程說起

  大家都會有這樣的困惑：當一個專案擺到我們的面前，我們不知道如何進行分析處理，我們總是不能把握它們的工作量，對於難度我們也沒有把握，或者不能確定我們的處理方法是否為最先進或者最穩定等等。我們可以拿出很多書籍進行參考，總想標新立異，但還是沒有結果。我們尋找原因，卻總是沒有答案。下面我們就來談談這個問題。

1.1 總體概念
  這裡我們不講解某個的用法，某個結構的意義，這裡我們講解的是一個完全的肢解問題的途徑。面對一個需求，我們主要作的 便是實現它。我們有兩種方法：首先是從頭開發，其次是借鑑它山之石。現在的基本上都是基於第三方的軟體平臺進行的，我們不願，也不可能真的從頭開發，因此我們要學會引用這種學問。比如我們需要一個，mpeg1，mpeg2是標準的東西，我們需要重頭來過，看著標準進行編碼嗎？現在的軟體業,如果你不是專門的解碼公司，這種做法是極為愚蠢的。如果你是軟體經理那麼你的做法將影響到整個的軟體進度，質量，因此為了確保沒一步的正確性，我們需要進行正確的分析。現在已經有很多成熟的解碼標準，從頭開發先不說對於精力的浪費，就算開發出來的程式碼能快一些，但對於現在的我們有必要在乎它們的差別嗎？現在軟體所表現出的賣點大部分集中在互動的親和性,和功能的完備上，我們便不必被限制在軟體的純理論的成績上。 現在的軟體速度已經到了前所未有的地步，我們作為開發者，能想到的只有創新超越，但是我們的基礎卻相對薄弱了一些。一個軟體所包含的內在含義不是表面上可以看出來的。比如金山的2000 就是一個比較好的國產軟體，起初看起來好像並沒有想像的複雜，好像每個模組我們都可以寫出來，那麼你可以試試寫寫其中的某個功能。你可能會發現你所缺少的東西，整個軟體過程的控制？設計不明確？資料結構的語言描述不過硬？等等。那麼你就需要從頭開始，這些基本功並不是需要你全部都記住，但是熟能生巧，巧就是飛躍，就象量變會導致質變一樣。  軟體是一個大的領域，比如你是開發介面的程式設計師，那麼或許可以對某些資料結構看的輕一些，如果你是作程式的，那麼或許你可以對設計模式置之不理。但這並不影響到我們的軟體水平，所謂在其位，某其政。從現在軟體發展來看，整個軟體業象是一個小世界，針對某個領域的程式開發，象程式設計師，程式設計師等等，會成為一個單獨的行業。因此這裡也有隔行如隔山的問題。我們並不要求程式設計師具有多麼完美的表現，最主要的是將每個程式設計師的亮點匯聚到一點。因此開發程式最重要的是專案經理--分析師。他是我們的帶頭人，但是現在真正具備專案經理素質的還是比較少。

  1.2 關於軟體工程

  軟體工程這個領域書籍種類十分的繁多，講解的深度也是大相徑庭。我們這裡討論的軟體工程只是從一個程式設計師的角度來看待軟體工程的。也就是最實用的一部分軟體工程。現在我們都知道軟體業中有個名詞叫做軟體工程，國內的著作也是舉不勝舉。但是如果大家看過國外的軟體工程的話就會知道，我們的東西只是他們的一部分。自從軟體誕生以來中國就一直在追逐世界的先進技術。當計算機產業在國外發展的如火如荼的時候，我們終於覺醒了，我們也要做軟體。但這是多麼的艱難，所有國外的標準建立起來的計算機體系已經根深蒂固了。於是我們只能借鑑國外的，按照別人的要求進行開發。我們追逐者，漸漸的我們學會了一些技巧，但別人的，開發環境等系統軟體卻迎面襲來，我們措手不及，我們沉默的接受了一切。這之中當然包括別人的軟體工程。於是我們看到的東西都是別人寫出來的。我們想實踐那些理論，但是我們總是失敗，但也有成功。我們就象當年說美國人的幾百年的歷史，他們用什麼來理解我們幾千年的文化一樣，我們不能完全理解他們的軟體工程，我們在努力，我們於是又有了些收穫，我們慢慢的明白了他們軟體工程的博大精深。這裡我就已經理解的部分進行講述。
1.1.1 我們怎麼看待軟體工程呢？
不錯，軟體工程是軟體業的一個管理上的mba，但是，現實中很多情況成功者並沒有讀過管理學。只是他們的行為遵循了管理學的某些定律。所以我們理解軟體工程也不必實踐全部理論，那是完全沒有必要的，就象古人“靠半部論語治天下”，他們也沒有完全理解論語一樣,但是一定要理解軟體工程的精髓。我們要注意我們管理軟體時不是為了符合軟體工程，而是為了符合軟體正確的軟體規律，這裡不是否定軟體工程，只是大家要清楚軟體工程會隨著實踐而改變，但是你解決問題的方法也是有可能符合將來的軟體工程的。就象牛頓定律被更新了很多此一樣。我們不必生搬硬套。只是沒有足夠經驗的情況下很難有質的飛躍。因此我們可以把現在所有的軟體理論當做基礎，一種解決問題的基礎，當我們需要解決問題的時候可以利用它們，然後加入我們專案特徵就可以了。不知道講清楚了沒有：是軟體工程符合我們，不是我們追隨軟體工程。
1.1.2 軟體工程的內容
我們都知道軟體工程講解的是軟體的管理。現在很多的書籍介紹的都是軟體工程的一部分，但它真正包括多少內容呢？我們就來討論一個軟體所包含的內容。
軟體工程是隨理念有所變化的。原來的程式是結構化的，現在的是面向的。這就導致了軟體工程的不同描述。因此我們在大學裡學的大部分是結構化的軟體工程描述，現在從軟體發展方向來看，這個已經不再適用了。
一個軟體就是一個產品，因此軟體工程所包括的內容應該包括一個產品的開發過程。因此質量概念是十分強的，這也就是軟體工程的發展法則。這個開發過程其實就是一個問題迴圈解決的過程。它包括了四個截然不同的階段：狀態描述，問題定義，技術開發和方案綜述。
狀態描述表示了事務的當前狀態；
問題定義標識了要解決的特定問題；
技術開發透過應用某些技術來解決問題；
方案綜述提交結果給那些從一開始就需要方案的人。

因此軟體工程應該包括：
1、 軟體專案的管理部分
這是一些基本原則適用與軟體的所有階段。
2、 傳統的軟體工程部分
包括了原來結構化分析部分的物件導向之前的軟體工程。
3、 物件導向的軟體工程部分
這是現在最常用的基於物件導向的軟體工程方法。
4、 一些特殊的工程處理方法
包括一些比較先進的軟體工程理念的技術，但可能沒有推廣開的那些理論。比如面向的軟體工程
5、 軟體產品過程的分析
這就是作為軟體產品來控制的工程理論。這是一個產品的控制，和技術不同。
上面的部分就是軟體工程的內容了。真正我們每個人需要了解的卻可以不同，因人而異。

談到軟體工程我們不得不討論一下現在很火爆的這個東西。
現在有實力的軟體公司都在想辦法過什麼cmm等等認證，我見
過很多軟體公司有種錯誤的觀點：符合標準就可以改變一切。
這其實是大錯特錯，我們不能盲目附和標準，要搞清楚適用範
圍和時間限制。這些標準對於我們國家的軟體公司來講（一般
的公司）是有些太大，什麼意思呢，就是太龐大，從機構設定
到開發過程到最終產品提交。我們不能指望幾十個人員在三個
月內完成一個大型專案，還要完成所有文件，完成所有的質量保證
程式，完成rose等的設計圖，最重要的是不能在開發過程中一
路順風。我們遇到的技術問題一般會很多。
那我們要符合標準應該是什麼意思呢？對於一般的軟體公司
很多的標準不適合它們，比如程式碼量少於10000行的程式一般會

被炒作為中型專案，按照所有的開發步驟，那樣會被規則束縛。

都說印度軟體產業好，其實他們規範中也有很大的靈活性，

什麼都不能妄下定論，就象那個10000行程式碼的軟體，其實可以
不寫用例設計圖，可以不用概要設計說明、直接達到詳細
設計說明中，還可以因專案而異，有的可以省卻使用者介面設計部分，
有的可以就僅僅使用rup的那些文件，自動生成。我們的開發
是靈活的，但是基本的東西卻一定要具備，比如：程式碼規範，
通用開發流程（根據不同的軟體行業將會不同），公司軟體制度
等等。如果我們的公司還不注意這一點，一定會被其拖垮，自己
還認為做的不夠。那些制度大部分是針對大中型企業的，就象window2000
server 很好但是很貴，window 95便宜但是夠用了一樣，我們要選擇
適合自己的就是最好的，隨著公司的變大，軟體管理也會漸漸的
完善，和軟體開發一樣是疊代漸進的。
軟體配置管理是體現一個公司管理層次的大問題。一般公司使用的
可能是safe，現在很火的clearcase的優點我們也許都知道了。
但是選擇還是不選擇，我們沒有定論，一樣的適合最重要。如果配置
clearcase，那麼要求單獨的一個管理人員，單獨的維護，複雜的操作。

我經過了cleaecase培訓，但是不具體實踐那些東西還是很模糊體會不到它

的好處，但是漸漸的你就會發現它的好處了，但那是多麼漫長的時間啊。
用到深處好處就體現出來了，想一想，卻發現又有多少個公
司能挺過這個階段呢？（我認為cleaecase是現在比較好的軟體配置工具）

(據我所知很多大的公司有自己的軟體標準來取代uml，因此這裡不作討論

我認為是要普及uml比較好）

我們依然循序漸進。

(下面講解解決問題的方法，將會具體到實現方法,比如影像軟體等等）