軟件設計是怎樣煉成的（5）——規劃系統的骨架（架構設計）（上篇）

摘要：

概要設計和詳細設計，多是最開始據說的設計，但後來發現若是侷限在這兩個設計的框架下，可能會有諸多不順，咱們須要架構設計、數據庫設計、模塊設計和用戶體驗設計，本文主要分享架構設計，此文有點長，因此分拆爲上下兩篇，上篇爲你分享：如何避免架構設計」放之四海而皆準「的問題，如何作到」需求驅動架構設計「？

 

大綱：

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

 

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

 

 

6.規劃系統骨架——架構設計

 

 

6.1 從概要設計、詳細設計提及

 

最開始我對概要設計和詳細設計的理解是這樣的：概要設計就是初步的比較粗線條的設計，詳細設計就是詳細的能指導編碼的設計。其實個人這個理解比較「廢」，基本上「概要「和」詳細「這兩個詞囉嗦解釋而已，其實當時沒有見過這兩種設計的實際案例，更加不清楚概要設計和詳細設計的界線在哪。

我剛開始作程序員的時候是沒有什麼設計文檔的，但有時我會主動寫一些，也沒有什麼格式和模板要求，本身以爲須要就寫而已。後來咱們開始要寫概要設計和詳細設計文檔了，咱們寫這兩個文檔不是爲了規範化而規範化，而是但願文檔能有效果，咱們的作法是這樣的：

1）咱們參考業界標準和本身的實際狀況，制定了概要設計和詳細設計的模板。
2）項目寫設計文檔時建議套用模板，但沒必要侷限於模板的格式；

3）概要設計文檔是必須有的，而詳細設計文檔可由項目組決定是否須要。

 

我以爲寫規範的設計文檔是必要的，不能總是土法煉鋼的模式來開發軟件啊，因而我開始「正式」寫概要設計和詳細設計文檔，可是慢慢產生了一些困惑：

1）概要設計要寫到怎樣的程度，確實沒譜，基本上都是「憑感受」，能規劃出系統的大體架構以及各部分的關係就差很少了。
2）詳細設計是否是描述出關鍵算法、設計思路就OK了，是否有必要進一步細化到類名、方法名、參數類型呢？文檔須要寫得這麼詳細嗎？是否是直接寫代碼更好呢？

3）數據庫設計是概要設計仍是詳細設計呢？

4）軟件的外在表現、人機交互的細節、界面風格字體大小等等這些，應該是詳細設計文檔要考慮的吧？

漸漸地咱們發現不能在侷限在概要設計和詳細設計這兩個概念的框框內，咱們以爲軟件項目至少須要四方面的設計，就是：架構設計、數據庫設計、模塊設計和用戶體驗設計。

 

 

6.2 架構設計、數據庫設計、模塊設計和用戶體驗設計

 

咱們先大概看看這四種設計是怎麼回事？

架構設計：近似於概要設計，其實也能夠叫「概要設計」，但我以爲「架構設計」這個詞可能更合適。架構設計須要通盤考慮需求後，從宏觀上規劃系統的各個部分以及各個部分的關係。

數據庫設計：對需求中的業務概念進行系統分析後，設計出表和表關係、視圖等數據庫元素。

模塊設計：相似於詳細設計，一般詳細設計是一個文檔，但模塊設計文檔能夠有多個。架構設計將系統劃分紅多個模塊，模塊設計就是針對某些或某個模塊的具體設計了。

用戶體驗設計： 用戶體驗是指用戶使用軟件時的總體感受，用戶體驗設計須要考慮清楚軟件的總體界面規劃、界面前後關係、文字表達、軟件與用戶如何交互等等。用戶體驗設計是「由頂而下」設計思路重要的第一步！

 

我作的項目中一般每一個項目至少須要1份架構設計文檔、1份數據庫設計文檔、0到多份模塊設計文檔和1份用戶體驗設計文檔。 但須要特別說明是：這四種設計其實不表明四種文檔，僅僅是說明了四種類型的設計而已，設計文檔的格式和數量是不限的，文檔的名字也是沒有規定必須叫什麼的。軟件設計是有無盡的可能性的，不要被文中的說法侷限你的思惟。

 

本篇重點介紹架構設計，其餘三種設計請留意後續文章。

 

 

6.3 不要「放之四海而皆準」的架構設計

 

架構設計是從宏觀上規劃系統的各個部分及各部分的關係，那怎樣表示系統的」各個部分「和「各部分的關係」呢？咱們看兩個案例。

 

案例1 ：用分層架構表示的軟件架構

以下這個圖的表示方法合適嗎？

圖6.1 分層架構

你可能會發現，這個圖不是在前面的系列文章中見過嗎？沒錯，這就是前一篇中出現過的圖。

某一次我做爲面試官面試一位應聘軟件設計師崗位的應聘者，我讓他畫圖表示一下他曾經作過的一個項目的架構設計。他當時就畫了一個三層架構的圖給我，不過不是用UML圖，而是用簡單的集合圖形（矩形、圓形、線條等）畫出來。其實不用UML圖畫架構設計也不是很什麼大問題，問題是這樣畫出來的設計是否是太粗了？是否是「放之四海而皆準」？他畫了這個圖後，我跟進問了一些具體的問題，他都沒有能答出來，只能用一些軟件設計的大道理來「招架」，因此我只能認爲他軟件設計不具有實際的工做能力了。

圖6.1在前面中出現，是由於我要說明什麼是N層架構，這個圖在前文中是沒有問題的。但若是用這個圖來表示一個具體項目的架構設計，那麼就是等於「廢話」！若是設計文檔中僅僅只有相似圖6.1的通用設計圖，這個文檔能夠扔掉了。

但凡有例外，某公司的設計文檔果真就是這個樣子的，你會發現一個很「神奇」的狀況：只有將項目的名字和相關的背景描述改一下，這個設計文檔立刻能夠成爲另一個項目的設計文檔！而項目組們對這個事情樂此不彼，他們很是「欣賞」這樣的設計文檔。你會以爲很奇怪，難道這個項目小組是不幹實事，喜歡幹這些沒用的事情？後來我才發現其中奧妙：由於該公司的過程規定項目必須寫設計文檔，QA常常來檢查，項目組爲了應付這個檢查，就用這個最節省工做量的辦法來應付過去。瞭解真相後，真的是讓人啼笑皆非！

分層設計確實是不少系統的設計思路，但在一個具體系統中表示分層設計時就須要表達得更加具體，太抽象就變成「放之四海而皆準」了，咱們要避免「一招走天下」。

 

案例2：部署圖表示的系統架構

圖6.2 部署圖表示的系統架構

爲了不「放之四海而皆準」的問題，咱們要求要用部署圖表示系統架構。最開始還挺有新鮮感的，但慢慢咱們發現畫出來的圖與圖6.2相似。咱們作的系統大部分是「網頁+數據庫」類型的，系統就只有三種機器，分別是：客戶端、Web服務器和數據庫服務器，而Web服務器和數據庫服務器還每每是同一臺服務器呢。因而有同事提出：部署圖畫架構設計一點用處都沒有，由於都是一個鬼樣，大同小異而已。確實如若是每一個項目的架構設計圖和圖6.2差很少，那麼又犯了「放之四海而皆準」這個問題！

 

架構設計應該如何作呢？下面咱們經過實際案例來體會。

 

 

6.4 架構設計是考慮「所有需求」後作出來的

 

咱們仍然用考勤系統爲案例，不過和前面的要求不一樣，需求有所調整。

 

先看看項目背景：

某公司員工人數約100人，領導想作一個系統對員工的外出及請假進行管理，具體需求見用例圖（見後文）。
假定咱們不太須要考慮進度、成本的限制，咱們的目標是作出一個高性價比的設計。

 

如今請看需求：

圖6.3 外出請假管理系統的用例圖

圖中紅色虛線框框框住的內容是比較麻煩的，對軟件設計提出了更高的要求。

架構設計須要考慮所有需求，咱們要從這些需求當中發現一些設計的關注點，你發現了哪些呢？

 

發現設計關注點

 

我將經過兩個圖來分析設計關注點，先看第一個圖：

圖6.4 設計關注點1

咱們須要思考所有需求，對不清楚不具體的需求要進一步提問題，思考這些需求的技術解決方案等等。

此圖列出了兩個關注點，紅色邊框框住的部分是第1個關注點，標記上「1」這個符號；而藍色邊框框住的部是第2個關注點，標記上"2"這個符號。

 

請看第二個圖：

圖6.5 設計關注點2

此圖展現了第三、4個關注點。

 

實際上設計關注點可能不止4個；也有可能 少於4個，由於你很牛的話，有些技術點已經得心應手了，對於你來講就不是問題。上述兩個圖展現了前文提到的「優秀的設計從分析需求開始」的思路，接下來咱們須要進行初步架構設計而且逐步細化這個設計。

 

本文有點長，因此我仍是分拆爲上下兩篇爲你們分享，下篇將會爲你分享：

6.5 逐步拆解架構設計

6.6 分佈式系統與單機系統的架構設計

6.7 架構設計小結

 

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

 

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

 

 

 

做者：張傳波

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

軟件研發管理資深顧問

CMMI首席專家

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

軟件知識原創基地創辦人