軟件設計是怎樣煉成的（4）——軟件設計的「大道理」

摘要：

十幾年前剛畢業不久，我從事第一份軟件開發的工做，要完成一個項目，但沒有任何軟件設計的思路，因而請教個人老闆。個人老闆給了我兩種思路：1）先假設軟件已經作出來了，想好軟件的外在表現，由此倒推軟件的實現方法；2）思考程序的數據結構，先設計數據庫，而後再搭建軟件的上層建築。老闆給了我很大的啓發，隨着工做的開展，後來我又發現了第3種設計的思路。本文將爲你分享三種軟件設計的思路：1）由頂而下；2）由底而上；3）由中間到上下。

 

大綱：

1.什麼是優秀的設計？
2.優秀的設計能節省項目工做量
3.優秀設計從分析需求開始
4.軟件系統不是木桶型的
5.軟件設計的「大道理」
6.規劃系統骨架——架構設計
7.打造系統的底蘊——數據庫設計
8.細節決定成敗——詳細設計
9.用戶感受好纔是真的好——用戶體驗設計
10.持續提高設計水平

 

本文章是系列文章之一，若是你尚未看過以前的文章，建議先看完前面的文章再看本篇，這樣效果更好。

 

 

5.軟件設計的「大道理」

 

 

5.1 個人第一次商業軟件的設計經驗

 

1999年剛畢業不久，我從事第一份軟件開發工做，當時要負責一個大型桌面軟件，但不知道應該如何開展軟件設計工做，因而向老闆請教。老闆也僅僅是年長我幾歲，不過公司的核心產品是老闆開發的，老闆說他其實也沒有什麼系統的方法，不過有兩種思路供我參考：

1）先假設軟件已經作出來了，想好軟件的外在表現，由此倒推軟件的實現方法；
2）思考程序的數據結構，先設計數據庫，而後再搭建軟件的上層建築。

上述的兩種軟件設計思路，相信不少有軟件設計經驗的朋友都能體會到。後來我又體會到第三種的設計思路，後文將會爲你分享我對這三種設計思路的一些體會。

 

 

5.2 N層架構是怎麼回事？

 

這三種設計思路都與軟件系統的N層架構有關係，咱們以常見的四層架構爲例子，請看圖：

 

圖5.1 四層架構

 

這個是UML的包圖（Package Diagram），圖中好像文件夾的那個東西就是「包」，包與包之間的虛線箭頭表示的是依賴關係。

上圖表示的意思以下：

1）四層架構的四層，分別是指：表現層、邏輯層、數據訪問層和數據層；
2）表現層依賴於邏輯層，邏輯層依賴於數據訪問層，數據訪問層依賴於數據層。

 

那「依賴」是什麼意思呢？

「依賴」能夠是如下狀況之一：

1）A須要調用B的方法，則A依賴於B；
2）A的方法中某些參數的類型是B，則A依賴於B；
3）A的某些方法的返回值類型時B，則A依賴於B。

 

這樣咱們大概瞭解了四層架構是怎麼回事了，但咱們還會有如下問題：

1）表現層如何將數據傳遞給邏輯層？

2）邏輯層如何將數據傳遞給數據訪問層？
3）數據訪問層如何將數據傳遞給數據庫？

 

一般咱們不會這麼老土經過一大堆參數來傳遞層與層之間的數據，一般咱們會將數據裝在實體類中，經過實體類來傳遞數據。因此圖5.1能夠進一步表示爲圖5.2：

圖5.2 四層架構與實體類

 

補充說明一下什麼實體類？

實體類一般是一個只有屬性沒有方法的類，一般咱們會將某一業務對象的數據裝在一個實體類中。例如：某請假單實體類，該類可能有請假人姓名、請假起止時間、請假類別和請假事由等屬性。

 

 

5.3 「由頂而下」的設計思路

 

看了圖5.1和圖5.2，你大概就清楚了什麼是軟件的「頂」？什麼是軟件的「 底」？「頂」就是表現層，「底」就是數據層。那麼「由頂而下」的設計思路，其實就是先想清楚軟件的表現層，而後再思考邏輯層、數據訪問層、數據層的實現。

前文咱們提到要「需求驅動設計」，這個說法有點籠統，咱們須要進一步思考：「什麼需求」驅動「什麼設計」？

請看下圖：

圖5.3 由頂而下的設計思路

 

這是UML的活動圖，橫線將圖分紅了上下兩部分，上部分是需求分析，下部分回答了「什麼需求」驅動「什麼設計」的問題。

說明一下：「需求驅動」及橫線不是UML圖的標準語法，圖加上這些非UML元素是爲了更好地表達問題。

「需求分析」這個活動有三種工做產品，分別是：

1）用例/用戶故事；
2）業務流程圖；
3）業務概念圖。

你能夠理解爲上述三種工做產品是「需求分析」這個活動的「輸出」。

「用例/用戶故事」和「業務流程圖」是「規劃界面」這個活動的「輸入」；相似，「業務流程圖」和「業務概念圖」是「設計邏輯層」這個活動的「輸入」。其餘就再也不多解釋了，你應該能夠看懂這個圖了，後續幾個圖的語法相似，也再也不解釋了。

 

上述是對圖5.3語法及表達意思的基本解釋，這裏再稍微小結一下：

1）分析需求是設計的開始，咱們還須要將需求至少分解爲三部分：軟件要知足的功能（用例/用戶故事）、業務流程（業務流程圖）、業務概念（業務概念圖）三部分；
2）設計不一樣的層時，主要依賴的需求是不太同樣的，上述分解的三部分需求對不一樣的層設計提出了不一樣的要求。比方說：設計數據庫時主要是根據業務概念來設計的，規劃界面時主要根據軟件須要知足的功能點，還有業務流程來設計。

 

 

5.4 「由底而上」的設計思路

 

通過前面的鋪墊後，這個「由底而上」的設計思路，相信你一看圖就能夠懂了。

圖5.4：由底而上的設計思路

 

這個圖也分紅了上下兩部分，上部分的內容其實和圖5.3是同樣的，只是左右順序不太同樣而已。

 

 

5.5 「由中間到上下」的設計思路

 

這種設計思路是我從事軟件研發工做若干年後才認識的，當時是由於項目出現了特殊情況，爲了應對這樣的情況而採起的一種設計方法。

 

案例分享：客戶要改SQLServer爲Oracle

簽定合同時，咱們和客戶約定的項目技術架構是.net+SQLServer，當時客戶沒有反對，咱們就按這樣的技術架構完成了系統，而且部署上線。可是不久客戶竟然提出了這樣的要求：要求咱們使用Oracle數據庫，而不能用SQLServer數據庫！咱們一般是按照「由底而上」的思路來設計軟件的，若是數據庫要更換，基本上整個軟件就等於重作！

若是你遇到這樣的情況，你會怎麼辦呢？能不能按需求變動來處理呢？只有客戶願意付錢，咱們就願意幹！但客戶願意付錢嗎？這但是要付推翻重作的錢啊！！

 

最後咱們的領導決定免費重作，領導決定免費重作的緣由是：

這是公司的一個核心項目，咱們指望這個項目未來能產品化，能持續賺錢。但咱們技術選型主要是根據咱們當前的技術狀況來決定的，沒有充分考慮客戶的狀況。客戶是某重要行業的企業單位，單位體制內的全部企業基本都是用Oracle的，但咱們選擇「視而不見」，選擇了咱們最熟悉的SQLServer來開發系統，其實早晚是要遇到問題的。客戶除了用咱們的系統，還會用其餘更大型的更重要的系統，客戶的其餘系統基本上都是使用Oracle數據庫的。因此若是咱們要在這個客戶領域打開市場，將項目作好，就有必要將系統改造爲Oracle數據庫。

 

可是咱們已經有部分客戶使用了咱們的基於SQLServer的系統了，未來也有可能會有部分客戶要求用SQLServer，因此咱們領導決心改造軟件的架構，要讓咱們的軟件能夠支持SQLServer，也能夠支持Oracle！因而咱們按照「由中間到上下」的思路，從新打造了軟件架構，請看下圖：

圖5.5 由中間到上下的設計思路

 

這個圖也分紅了上下兩部分，上面部分和前面的圖內容也是同樣的，但下面部分就很不同了，並且可能比較難理解。

「由中間到上下」基本的思路是這樣的：

1）先不考慮表現層，也不考慮數據層；
2）先定義實體類和數據層接口；
3）接口定義好後，往上能夠設計邏輯層和表現層，往下能夠設計數據層接口的實現和設計數據庫。

 

按照這樣的設計思路作出來的軟件架構，應該是這樣的：

圖5.6 由中間到上下的系統架構

 

圖中見到數據操做層接口有兩種不一樣的數據庫實現，分別是SQLServer和Oracle，若是要考慮第三種數據庫，那麼再增長一個實現就搞定了，而系統的上層建築（表現層、邏輯層）不須要改變。

 

這樣的設計方式看上去很酷，是否是應該全部系統都要考慮用這樣的方式來打造呢？

不是滴，這樣的設計方式是有缺點的：

1）系統將不能充分利用數據庫的特性，通常會禁止在數據庫中寫存儲過程、觸發器、甚至是視圖等，程序的的性能其實會下降；
2）由於不能充分利用數據庫自己的特性，因此大部分甚至是所有的業務邏輯只能靠程序搞定，這樣其實增長了程序的複雜度和工做量。

 

因此每種設計方法都是有針對性的，都很難作到十全十美，通常只能針對主要矛盾作出一些取捨。

 

 

5.6 小結

 

若是系統沒有多數據庫的要求，我會比較建議你用「由頂而下+由底而上」的設計思路；若是程序須要支持多數據庫，那麼可能考慮「由中間到上下」。上面介紹的三種設計思路，其實在實際工做中咱們每每不會只選其一，每每是結合了多種思路的。不要侷限本身的思路，軟件設計的可能性是無窮的。

 

 

本文是系列文章的第4篇，要作軟件設計師一點都不簡單啊，請留意後續文章！

 

若是本文對你有幫助，麻煩點一下「推薦」啦，謝謝！

 

 

 

做者：張傳波

創新工場創業課堂（敏捷課程）講師

軟件研發管理資深顧問

CMMI首席專家

《火球——UML大戰需求分析》做者

軟件知識原創基地創辦人