軟件設計入門1 架構設計

熱愛編程才能作優秀的軟件設計師！

軟件設計有一些方法能夠參考。但更重要的是要有好的需求分析、豐富的技術知識和設計經驗（多動手！）不斷追求更好的精神（多動腦！）。

遇到別人的系統想一下本身可否實現，如何實現？

 

1、優秀設計的標準：性價比高的設計。

1）優秀的設計都是需求驅動的，不熟悉需求就作出來的設計是不靠譜的；

2）優秀的設計應該是當前團隊能理解能實現的，太超前的設計項目團隊作不出來，這個設計只能是擺設；

3）優秀的設計應充分考慮當前各類限制條件，適當作出平衡，能保證達成項目的目標；

4）優秀的設計能儘可能下降項目的總體工做量，讓真個項目更加可控。

 

2、優秀的設計從需求開始

　　案例挑戰：考勤系統的軟件設計：

　　某公司要作一個內部的考勤系統，但願達成如下目標：

　　1）規範員工的上下班、請假、外出工做等行爲。

　　2）方便計算員工的薪金。

　　3）方便管理各類帶薪假期。

　　該如何設計本系統呢？

 

先作需求分析，確保需求分析沒有問題。

分析需求，先從業務角度分析，再從軟件設計的角度分析（5步走）：

　　1）誰會用本系統？（列出全部可能的用戶）

　　2）不一樣的人分別用哪些功能？（用例圖）

　　3）還有哪些不肯定或不具體的需求點？（用戶場景）

　　4）哪些需求對技術提出了怎樣的需求？（具體問題的解決方案）

　　5）系統的大體架構該如何考慮？（部署圖、組件圖、包圖）

 需求分析不但要作到第1）2）步還要深刻分析業務（業務流程、業務數據...）

 

3、軟件系統不是木桶型的（軟件設計通常都是要總體考慮的）

　　用戶場景之間是有關係的，如基礎數據。不一樣的用戶場景可能用到的基礎數據是相同的，不能把系統作成木桶型的（每多一個用戶場景就添加一份表現層、邏輯層、數據庫表)，這樣會很噁心。

　　軟件常見內部架構：

　　此圖說明：

　　1）各個用戶場景之間是有關聯的，不是獨立的。軟件設計應該多從業務概念、業務流程的角度考慮；

　　2）各個用戶場景的界面之間可能有重用和共享的部分（共用基礎信息）；

　　3）業務邏輯中的一些類原本就是一個總體。

 

4、軟件設計的「大道理」

一、軟件設計思路：

　　1）由頂而下：先假設軟件已經作出來了，想好軟件的外在表現，由此倒推軟件的實現方法；

　　2）由底而上：思考程序的數據結構，先設計數據庫，而後再搭建軟件的上層建築；

　　3）有中間至上下。

N層架構：以4層爲例

UML包圖，包與包之間的虛箭頭表示依賴關係。

上圖意思以下：

　　1）四層架構包括：表現層、邏輯層、數據訪問層、數據層；

　　2）表現層依賴邏輯層，邏輯層依賴數據訪問層，數據訪問層依賴數據層。

依賴可使一下狀況之一：

　　1）A須要調用B的方法，A依賴於B；

　　2）A的方法中某些參數的類型是B，A依賴於B；

　　3）A的某些方法的返回值類型是B，A依賴於B。

各層之間是怎麼傳遞數據的（傳參數？）No！將數據保存到實體類中，各層均依賴實體類！：

。

實體類：一般是隻有屬性沒有方法的類，一般咱們將一些業務對象的數據放在一個實體類中。如：請假條的實體類（請假人姓名、請假起止日期、請假類別、請假事由等）。

二、由頂而下：先想清楚表現層，再思考邏輯層、數據訪問層、數據層實現。

　　「需求驅動設計」哪部分需求驅動了什麼設計？看圖：。

　　本圖表達的意思：1）軟件設計首先要有正確的需求分析，須要將需求分解爲 用例、業務流程圖、業務概念圖。

　　2）設計不一樣的層時主要依賴的需求不同。

三、由底而上：

　　。

四、有中間到上下：（使用狀況：表現層不動，數據層變更。如：將SQLServer換爲Oracle）

　　定義實體類和數據層接口，在數據庫操做層實現接口功能。接口對於邏輯層是同樣的。

　　從中間到上下的軟件架構如圖：。

　　這樣作也不是沒有缺點的,這樣會不能使用數據庫的特性，如禁止在數據庫中邪存儲過程、觸發器、視圖等。增長了程序的複雜度和工做量。

 

5、規劃系統的骨架——架構設計

一、軟件設計至少須要4方面的設計：架構設計、數據庫設計、模塊設計、用戶體驗設計。

　　架構設計：通盤考慮需求後，從宏觀上規劃系統的各部分及各個部分的關係；

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

　　模塊設計：架構設計將系統劃分紅多個模塊，模塊設計駕駛針對某些或某個模塊的具體設計；

　　用戶體驗設計：須要考慮軟件的總體假面規劃、界面前後關係、文字表達、軟件與用戶如何交互等。由頂而下設計。

 

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

　　想一下架構設計的做用，下邊的軟件架構設計有至關於沒有，就是廢話:

　　沒有體現出需求，沒有體現出該系統的特殊性！

　　下邊的系統架構犯了一樣的毛病：。

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

1）、先經過用例圖列出所有需求：

　　，分析圖中須要重點關注的地方。

　　。

　　從關注點中發現問題，提出解決方案。

四、逐步拆解架構設計

　　不以解決需求爲目的的軟件設計就是耍流氓！

　　想說明一下工做流：

　　1）、死的工做流：代碼是死的，數據庫設計也是死的，流程或表單由任何變化，均可能須要改代碼和數據庫設計。

　　2）、半死不活的工做流：部分地方寫死，部分地方是靈活的，能適應部分需求變化。

　　3）、全活的工做流：代碼和數據庫設計等都是靈活的，能基本適應流程及表單的變化，不須要修改代碼或數據庫設計，只要配置一下就能夠搞定。

　　開發設計最好由易到難。

 

　　初步架構設計——第一層拆解

　　針對一個具體的項目作架構設計時，不能脫離具體的技術框架，要先肯定你的開發語言、數據庫種類等。架構設計要從物理設計的深度來思考，而不能僅僅是理論設計或邏輯上的設計，不然又會犯太空洞的毛病（「放之四海而皆準」的毛病）。

 

　　。

　　小結初步架構設計的要點：

　　1）、系統涉及到客戶端和服務器，咱們要考慮系統須要客戶端和服務器作哪些事？這須要客戶端和服務器具有哪些配置屬性：系統屬性、軟件屬性、硬件屬性等。

　　2）、客戶端和服務器見得物理聯繫方式：局域網？互聯網？仍是？

　　3）、客戶端和服務器上須要咱們開發什麼軟件？至關於第一條的軟件屬性。第一條更側重於硬件及其性能。

　　圖中須要咱們開發的東西有：WebApplication、工做流定義用的客戶端軟件、三個數據庫。

　　第一次架構設計就是劃分系統分了幾部分及各部分的關係。

 

　　繼續深刻拆解——第二層拆解（進入第一次劃分出的每一部分再次劃分）

　　以Web Application爲例，深刻設計。

　　分析Web Application的內部架構分幾部分及他們之間的關係時，也要考慮有哪些食慾外部交互的。

　　這張圖凸顯的是Web Application模塊內部的模塊與外部模塊的的鏈接關係，沒有與外部模塊鏈接的模塊被隱藏了。

　　細分到這一步，開始發現須要解決的問題：

　　，一一列出每個問題的可行的解決方案，及方案須要考慮的具體問題。

 

　　架構設計拆解小結：

　　1）、第一層拆解：解決「整個系統分爲幾塊，須要開發什麼軟件和數據庫」的問題。

　　2）、第二層拆解：深刻到系統的一個模塊，再次劃分能分紅幾個子模塊，考慮他們之間的關係，哪些子模塊是和外部模塊有聯繫的。能夠參考分層架構。

　　3）、「第二層拆解」的結果有多是組件、代碼包、某個分層等等，多是「物理拆分」，也多是「邏輯拆分」。

　　拆分到什麼程度纔算合適呢？：若是在拆解下去，下一步的拆解就到類了，那麼就能夠認爲目前的拆解粒度比較合適了。細化到類的拆解，能夠在模塊設計中再進一步考慮。

　　

　　「物理拆分」和「邏輯拆分」：

　　物理拆分：解釋物理上獨立的部分，有多是EXE、dll、數據庫文件等。該系統能夠物理拆分紅5部分：Web Application、流程定義用的客戶端軟件、3個數據庫。在對Web Application進一步進行拆分時,日曆控件是物理拆分，這個控件將經過二進制的方式供程序他部分調用，二這個控件未來也能夠供其餘系統使用。

　　邏輯拆分：代碼包、某個分層這些每每是邏輯拆分，物理上他們不會編譯成單獨的一部分，而是被總體變異近軟件當中。

　　「第二層拆解」的目的除了更加方便咱們設計出系統，另一個重要目的是作系統的重用設計。物理拆分——二進制重用；邏輯拆分——源代碼重用。這些重用會爲之後其餘軟件開發提供便利。

 

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

　　分佈式系統每每須要咱們在多臺設備上部署，個部分須要聯調後，整個系統才能正常工做。

　　本文前邊的系統架構就是分佈式架構。