如何進行軟件架構設計？

 軟件架構設計的目的

    對於外包業務類型的項目，軟件架構設計的目的與產品類型的項目有所不一樣，在這裏主要討論外包類型項目的軟件架構設計目的。

    1、爲大規模開發提供基礎和規範，並提供可重用的資產，軟件系統的大規模開發，必需要有必定的基礎和遵循必定的規範，這既是軟件工程自己的要求，也是客戶的要求。架構設計的過程當中能夠將一些公共部分抽象提取出來，造成公共類和工具類，以達到重用的目的。

    2、必定程度上縮短項目的週期，利用軟件架構提供的框架或重用組件，縮短項目開發的週期。

    3、下降開發和維護的成本，大量的重用和抽象，能夠提取出一些開發人員不用關心的公共部分，這樣即可以使開發人員僅僅關注於業務邏輯的實現，從而減小了不少工做量，提升了開發效率。

    4、提升產品的質量，好的軟件架構設計是產品質量的保證，特別是對於客戶經常提出的非功能性需求的知足。

    軟件架構設計的原則

    軟件架構設計必須遵循如下原則：

    1、知足功能性需求和非功能需求。這是一個軟件系統最基本的要求，也是架構設計時應該遵循的最基本的原則。

    2、實用性原則，就像每個軟件系統交付給用戶使用時必須實用，能解決用戶的問題同樣，架構設計也必須實用，不然就會「高來高去」或「過分設計」。

    3、知足複用的要求，最大程度的提升開發人員的工做效率。

    軟件架構設計的幾種視圖

    咱們經常在討論架構設計該作些什麼的時候，或是在架構設計評審的會議上，會提出各類各樣的問題，例如開發人員該如何記錄Log，事務如何控制？怎樣才能提升咱們的開發人員的工做效率，即在單位時間內更有品質的完成更多的功能？怎樣知足客戶的非功能性需求？怎樣讓生產環境的平臺管理人員更好的維護系統？

    上面這些問題，其實是軟件系統的不一樣的干係人站在不一樣的角度上提出的問題，要回答上面這些問題，咱們就得從不一樣的視角來看待軟件架構設計這項工做。

    1、邏輯架構視角，從系統用戶的角度考慮問題，設計出來的軟件架構可以知足業務邏輯的需求，可以處理如今愈來愈複雜的業務邏輯需求。

    2、開發架構視角，從系統開發人員的角度來考慮問題，設計的架構要易於理解，易於開發，易於單元測試，最好作到讓開發人員能夠用最少的代碼行數完成功能的開發。

    3、運行架構視角，從系統運行時的質量需求考慮問題，特別關注於系統的非功能需求，客戶經常都會要求咱們系統的功能畫面的最長響應時間不超過4秒，能知足2000個用戶同時在線使用，基於角色的系統資源的安全控制等。

    4、物理架構視角，關注系統安裝和部署在什麼樣的環境上，例如如今最流行的企業應用服務解決方案IBM Http Server ＋WebSphere Application Server ＋ DB2，WebLogic + Oracle等。

    5、數據架構視角，現在咱們開發的各種系統，如MIS，ERP，SAP，基本上都是對各種數據的操做，把一堆不太好懂的數據展示成用戶容易看懂的數據，自動處理各種數據的運算等，因此數據的持久化是十分重要的一件事情。

 

1、分析需求和理解業務模型（或領域建模），並選定關鍵Use case。

    軟件的需求，能夠分爲從用戶視角和開發人員視角來看，從用戶的角度看，又能夠分爲功能性和非功能性需求，咱們必須從不一樣的視角和級別去全面的認識需求並分析需求，理解業務模型。實踐代表，經常被咱們忽視的非功能性需求經常會致使整個項目失敗。

    理解業務需求最好的方式莫過於進行領域建模，領域建模與需求分析每每是交替穿叉進行的，領域建模主要有如下三個方面的做用：

    ◆探索複雜問題，弄清領域知識。Martin Fowler曾經說過，他採用面向對象方法最大的好處就是它有助於解決更爲複雜的問題。領域建模自己做爲輔助思惟的工具，幫助咱們將注意力始終保持在最爲重要的業務概念及其關係上，使咱們可以不斷深刻地，系統的對需求進行分析和認識。領域建模每每是一個從模糊到清晰，從零散到系統的過程。

    ◆決定功能範圍，影響可擴展性。任何模型都是對現實世界某種程序的抽象，這種抽象就會忽略某一些東西，例如忽略對象的屬性和對象間的關係，而這些忽略每每都是帶有必定的目的性的，這種忽略就決定了功能的範圍。模型揭示了各類功能背後的結構，若是說定義功能至關於「拍照片」的話，那麼領域建模就至關於「作透視」，更加關注問題領域的內在結構，至關於對問題領域進行了必定的抽象，良好的領域模型不只能很好的支持現有的功能，並且還能夠在必定程度上支持將來可能出現的新需求，體現良好的可擴展性。

    ◆提供交流基礎，促進有效溝通。領域建模一般會使用UML圖做爲呈現的方式，這樣爲咱們的溝通提供了方便。固然，有時候文字在描述某些特定領域的問題時可能更適合，能夠靈活運用。

    在咱們公司的實際軟件開發流程中，每每領域建模缺乏這一環節，這多是在之後的工做中須要進一步提升之處。

    雖然咱們老是指望架構設計師能全面掌握需求，但因爲時間和精力的限制，擺在咱們面前的現實就是架構設計師沒有時間對全部需求進行深刻分析，因此咱們的策略就是「把好鋼用在刀刃上」，即把大部分時間和精力花在對決定架構最重要的關鍵需求上。在選擇關鍵需求時要注意：高優先級的需求每每是從用戶的角度來看的，可能並非真正的關鍵需求。在《RUP實踐者指南》一書中向咱們講述瞭如何肯定關鍵功能需求？A.做爲應用程序的核心或實現了系統的主要接口的功能，B.必須被實現的功能，即若是這些功能不被實現，則開發出來的軟件就失去了價值，C.覆蓋了系統架構的一些方面，但沒有被其餘重要的Use case覆蓋到的功能。

    2、分別從各個視角來考慮軟件架構的方方面面。

    軟件的架構設計必須考慮到各方面，根據前期工做確立的領域模型，關鍵需求，系統約束等進行設計，必須從系統用戶，開發人員，系統管理員，部署管理員，數據管理員等人員的角度去分析並解決問題。好比說，若是咱們的運行架構採用Cluster方式時，就必須當心Cache和Session等的使用；若是咱們的業務邏輯要求咱們要操做多個數據庫時，就要考慮採用支持二階段事務提交的方式。

    只有將這些方方面面的問題都考慮到了，這樣的架構設計纔是完整的。至於每個視圖中，咱們應該設計到什麼細節這一問題，實際上與整個項目的過程定義有關。例如，若是咱們有專門安排數據庫概要設計的活動，那咱們在架構設計的過程當中就能夠只須要關注更高層次的數據庫特性及數據庫之間的關係，而每一張表的數據字典能夠在後續的相關活動中進行設計，但若是沒有這樣的活動，那咱們就要細化到每一張表的每個欄位，以及表之間的關係。

    3、解決技術面的重點問題和難題

    在軟件架構設計的過程當中，咱們每每會須要攻克一些技術面的重點問題和難題，這徹底是一項極其須要紮實的理論知識和豐富的實踐經驗支撐的工做。例如，咱們如何提升整個系統的性能？如何能很好的導出極其複雜的「中國式報表」（通常比西方國家產出的報表要複雜不少，並且不少開源的BI類的框架並不能徹底解決問題）？

    當遇到確實是很困難的問題，能夠去百度一下或Google一下，也能夠去請教公司的資深技術人員或專家，或者召開小範圍的技術專題討論會議，採用腦力激盪的方法試着找找答案，這樣才能提升工做的效率。

    4、召開架構設計評審會議進行同行評審。

    架構設計評審是極其重要的一環，我曾將其形容爲「七種武器」中的離別鉤，就是由於在會議上，同行們可能會提不少問題或意見，並且不少意見很尖銳，因此必定要虛心接受，並作好記錄，正所謂「良藥苦口利於病，忠言逆耳利於行」。

    在評審會議以前，咱們要完成不少準備工做，最好是能準備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目的，在會議前就將這些資料發給與會人員，請他們抽空先了解一下，在會議進行時，要學會控制會議的進度，提升會議的效率。

    5、針對關鍵Use case在設計的架構上實現功能來驗證架構。

    對於架構設計的驗證也是一項十分重要的工做，其驗證技術有不少種，在咱們公司一般會採用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣作的好處是既能夠從實際的產品角度出發來有效的驗證架構是否知足要求，又能夠比拋棄型原型驗證技術節省成本。

    這個Sample毫不是咱們在解決架構設計中的問題時拿來作實驗的一些代碼的拼湊，而是完整的實現某一關鍵Use case的符合架構設計和一系列規範的可交付的代碼及相關文檔。同時，這個Sample能夠做爲你在給你們講解或培訓架構時的教材，也能夠做爲開發人員使用此架構進行開發的藍本，甚至是隻須要複製粘貼，加上簡單的修改便可。

    6、交付給客戶Review。

    這一環節，在不少公司可能並不存在，由於他們的軟件架構並不必定須要客戶Review，但像咱們這種作服務的公司，最重要的就是客尊，落實到軟件架構設計這一活動，就是讓客戶理解並接受你的架構設計方案，同時，客戶也會起到幫你驗證架構的做用。一般，咱們的架構獲得客戶的承認後，即可進入大規模的開發。

    在交付給客戶Review時，一般可能會以會議的形式進行Review，因此咱們能夠參照評審會議時好的作法來召開會議，在這裏就再也不冗述。

 

軟件架構設計的常見誤區及解決辦法 

    1、架構設計的經常會「高來高去」。所謂高來高去，實際上就是咱們的架構設計僅停留在模型階段，但也毫不是產生第一支樣例程式。

    2、架構設計時經常會在某些方面過分設計（Over engineering）。爲了一些根本不會發生的變化而進行一系列複雜的設計，這樣的設計就叫過分設計，每每會帶來資源的浪費而且會增長開發的工做量或難度。雖然咱們必須考慮到系統的擴展性，可維護性等，但切忌過分設計。有時候或許你並不能判斷出哪些設計是過分設計，此時你能夠請教你的PM，讓他站在整個項目的高度來幫你決策一下。

    3、架構（Architecture）不是框架(Framework)，也不是簡單的將幾種框架或技術的組合，框架自己也是有架構的。框架通常是針對於某一方面或領域的重用性和可擴展性很是好的半成品，咱們能夠用一句較爲經典的話來總結：框架是軟件，架構不是軟件，框架是一種特殊的軟件。咱們在工做中經過將許多方面的可重用的工具類，公共類，基礎類等抽象出來，便可造成一些可重用的框架。

    4、架構設計毫不是新技術展現平臺，合適的技術纔是對於項目有利的技術，必須考慮到開發人員的能力和維護人員的能力。做爲一名架構設計師應該更多的考慮如何平衡業務需求，織織運做（主要指團隊中的協做）和技術三者的關係，而不只僅是去關注那些技術細節。

    5、架構設計的成功與否決定着系統品質的好壞，由於架構設計很差而致使交付的系統Bug過多，沒法知足客戶非功能性需求等問題，從而致使項目取消的案例時有發生。架構設計不是架構設計師一我的的事情，也不是幾天就能完成的一項工做，必須是架構設計師付出大量辛勤勞動後的成果，其成敗每每與組織、主管、項目經理的支持有着密切的關係。

    關於架構設計的一點通用技巧

    1、分層（Layer）規則。這裏的層是指邏輯上的層次（Layer），並不是指物理上的層次（Tier）。目前的絕大多數的企業級應用系統中都分爲三層，即表現層，領域層和數據層。在對各層次進行劃分時，主要能夠從如下幾個方面來考慮：A、每一層是一個相對獨立的部分，能夠做爲一個總體，無需對其它層瞭解；B、將層次間的依賴性降到最低，即下降耦合；C、能夠從某種程度上替換掉某一層，而對其它層不會產生過多的影響；D，層次並不能封閉全部的東西，假如用戶界面上增長了一個欄位，那麼領域層就要增長一個數據域，數據層就要增長一個相應的字段。同時，過多的分層可能會對性能形成必定的影響。

    2、包（package）之間不要產生循環依賴。一般包的劃分會先按不一樣的邏輯層來劃分，在層的包下面再按功能來劃分。避免包間的循環依賴是一個比較通用的規則，這樣的規則必定有其存在的價值和道理，之因此這樣主要是出於如下緣由：A、循環依賴會使分層失去意義；B、循環依賴會帶來許多潛在的風險，如可能會產生嵌套事務（nested transaction，JavaEE標準中並不支持這種事務）的現象，我就曾遇到過這樣的問題，在一個項目中，事務放在業務邏輯層統一控制，但因爲開發人員忽視了架構中這樣的原則，在持久層調用了展示層的公用類，造成了迴圈的現象，致使了嵌套事務的發生。

    3、設計模式的應用。在不少人的觀念裏，提供設計模式就等同於GOF的設計模式，其實設計模式是個普遍的概念，好比需求模式、領域模式、反模式等都屬於設計模式。模式實際上是一門工具，是人們對於過去解決某一類問題的經驗總結，因此咱們能夠在設計活動中應用各類設計模式，可是在應用這些模式以前必定要先分析清楚問題，不然就可能出現「牛頭不對馬嘴」的現象。

    成功的項目總有類似之處，失敗的項目卻各有各的失敗之處。好的軟件架構設計一定是成功項目的類似之處，咱們有什麼理由不把軟件架構設計作好了？

 

 

原文鏈接：http://www.cnblogs.com/kongzheng/articles/1370165.html