作為軟件生命周期前期的重要部分，架構設計要完成項目從面向業(yè)務到面向技術的轉換，是跨越現(xiàn)實世界與計算機世界之間鴻溝的一座橋梁。完成架構設計的過程是軟件架構設師們思考、總結并提煉的過程。軟件架構設計對項目以后是否能繼續(xù)正常進行、項目最終質量的好壞都起到很關鍵的作用。
首先介紹軟件架構的概念，以利于后面內(nèi)容的展開。這是一個有很多版本的定義。IEEE標準中對架構是這樣定義的：架構是在組件及其彼此間和與環(huán)境間的關系引導設計發(fā)展原則中體現(xiàn)的系統(tǒng)的基本結構。 UMAL1.5中對架構的定義是： 架構是系統(tǒng)的組織結構和相關行為；架構可被重復分解為通過接口，互聯(lián)部分的關系和結合部相互作用的部分；通過接口相互作用的部分，包括類、 組件和子系統(tǒng)。雖然它們有些區(qū)別，但是核心思想都是相通的。架構要包括各個顆粒度或粗或細的元素（組件）和定義他們之間的交互關系；架構還是許多重要問題的決策，這些問題包括：
軟件系統(tǒng)的組織
選擇組成系統(tǒng)的結構元素與他們之間的接口，以及當這些元素相互協(xié)作時所體現(xiàn)的行為
如何把這些元素組成更大的子系統(tǒng)
用于指導這個組織結構的架構風格：這些元素以及他們的接口、協(xié)作和組合
總之，我們不用去苛求定義的一致性，我們要領會它們是關于元素與重要決策的精神。形式只是其內(nèi)容的表現(xiàn)，而深刻理解其內(nèi)容的精髓，將在實踐中給我們帶來莫大的好處。下面我們就將展開軟件架構設計的內(nèi)容。
在需求獲取和需求分析階段，如何能夠正確理解并提取需求，是成功項目的先決條件。軟件的需求，可以從用戶和開發(fā)人員兩個不同的視角來看。從用戶的角度看，又可以分為功能性需求和非功能性需求。我們必須從不同的視角和級別去全面的認識需求并分析需求，理解業(yè)務模型。
在全面的認識需求并掌握了需求的相互影響后，我們還要掌握軟件所屬領域各種概念與問題，做到對項目整體需求情況“心中有數(shù)”。理解業(yè)務需求最好的方式莫過于進行領域建模，領域建模與需求分析往往是交替穿叉進行的。如果把這些需求都做成用例，那么一定是一個數(shù)量很龐大的用例集。分析功能需求與非功能需求，可以先抓住對整個軟件起決定作用的部分關鍵需求，并把他們形成列表。我們可以輔助用例圖，來更直接的搞清軟件的用戶與這些需求之間的關系。如下圖就是一個項目管理系統(tǒng)的用例圖。從張圖很清晰的看出該項目用戶與這些需求的關系，還可以總結出各個需求所屬的模塊。這樣我們就可以進行很關鍵的概念性架構設計了。
概念架構界定了系統(tǒng)的高層組建、以及他們之間的關系；他對系統(tǒng)進行分解但不陷入細節(jié)；借此項目各方人員可以進行交流；它包括架構圖以及各組件的非正式規(guī)約（無接口細節(jié)）。他針對重大需求、特色需求、高風險需求，給出高層次的解決方案。
魯棒圖是設計概念架構一個很好的工具與思考方式。我們可以通過魯棒圖展開案例，構造系統(tǒng)的理想化的模型。如下圖，是一個“項目管理系統(tǒng)”案例，通過它我們可以發(fā)現(xiàn)并分析對象，初步看出用戶的操作與數(shù)據(jù)的組成與流轉。（具體魯棒圖的定義、語法、元素、規(guī)則等細節(jié)就不在這里介紹了）
下圖是魯棒圖中的元素與MVC的對應，通過他我們可以看到，如果有了魯棒圖，概念架構設計的下一步似乎容易了很多。
我們似乎已經(jīng)有了比較獨立的小系統(tǒng)，接下來，我們又要提煉了：形成初步的概念架構，而我們期待已久的“分層、分區(qū)”（架構模式）就要出現(xiàn)了。這當然需要一些水平和經(jīng)驗。我們可以先大致“分層、分區(qū)”（確定架構模式），然后結合魯棒圖完成里面的內(nèi)容。如下圖所示，我們可以看到魯棒圖如何幫助我們完成初步概念架構。
形成初步概念架構后，我們還需要考慮非功能實現(xiàn)需求，實現(xiàn)高層設計決策。非功能需求在這里提出就是要早發(fā)現(xiàn)問題，早作出決策。這里推薦使用“目標-場景-決策”表（使用方法建議大家自學，我這里不介紹了）來幫助我們完成之一工作。通過分析需求、目標與質量屬性、約束，我們把可預見的風險、問題、約束想象到場景中，并填寫到表中相應位置，我們自然會得到我們想要的決策，補充我們的概念架構。如下圖，就是通過“目標-場景-決策”表得到?jīng)Q策的過程。
好了，我們已經(jīng)有概念架構了，但是他顯然還是無法指導開發(fā)、規(guī)劃、實施、運行，所以現(xiàn)在我們需要細化軟件架構。軟件的架構設計必須考慮到項目的各個方面，根據(jù)前期工作確立的領域模型、關鍵需求、系統(tǒng)約束等進行設計，必須從系統(tǒng)用戶、開發(fā)人員、系統(tǒng)管理員、部署管理員、數(shù)據(jù)管理員等人員的角度去分析并解決問題。我們不可能只提交一個圖就告訴大家所有的事情都怎么做，就像一個學生的一門成績無法完整的顯示他的學習狀況，只有提交所有成績才可以評價他學習的好壞。5視圖就是一個很好的設計思路與應用。如同下圖所示，他反映了軟件的各個方面，對概念架構的細化其實就是完成他們的過程。當然要根據(jù)實際情況決定選擇全部還是其中的幾個視圖。
展開介紹5視圖的完成過程需要很大篇幅去介紹，這里就不進行了。但是我們可以總結一下各個架構的功能。其中：
邏輯架構：負責劃分子系統(tǒng)（包括分層的細化、分區(qū)、機制的提取）、確定接口。
開發(fā)架構：并行開發(fā)的基礎（包括定義程序單元與相互的關系、開發(fā)技術的選型）
運行架構：系統(tǒng)“運行時”架構（包括引入控制流、確定控制流相互關系）
物理架構：物理節(jié)點與部署結構（包括物理拓撲、軟件到硬件的影射）
數(shù)據(jù)架構：數(shù)據(jù)的組織與存儲格式
細化軟件架構工作完成了，我們可以對我們的架構進行評審。無論是內(nèi)部評審、外部評審還是專家評審，在評審會議之前，我們要進行充分的準備工作，如準備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目。在會議前應將這些資料發(fā)給與會人員，請他們抽空先了解一下。在進行評審會時，要學會控制會議的進度，提高會議的效率。當然，在會議上，同行們可能會提很多問題或意見，而且可能很尖銳，但一定要虛心接受，并做好記錄。還有要強調一點的是，在大張旗鼓開始下一步工作之前，花點時間進行架構評審這一步還是很重要的。架構設計實在太重要了，如果這里都不合理，后面的大量工作就會被白白浪費掉。
架構設計的重要性，也決定了架構設計的風險性。架構設計中決定了很多重要的設計決策，而這些重要決策是否能夠在復雜的軟件系統(tǒng)中真正實現(xiàn)我們對軟件質量和需求的預期，即使做了充分的架構評審，我們有時還是會心中沒底。鑒于不同軟件項目規(guī)模的大小和其重要性，我們可以選擇進行軟件系統(tǒng)架構的驗證工作—為軟件架構設計方案實現(xiàn)一個小規(guī)模的原型，對該原型進行測試與評審，來繼續(xù)評估架構的合理性，從而進一步降低項目的風險性。
軟件的架構是系統(tǒng)在其環(huán)境中的最高層概念，它要兼顧系統(tǒng)完整性、經(jīng)濟約束條件、審美等要求。它不僅注重對內(nèi)部的考慮，而且還在系統(tǒng)的用戶環(huán)境和開發(fā)環(huán)境中對系統(tǒng)進行整體考慮，即同時注重對外部的考慮。在進行架構設計的時候，既不要“高來高去”或“過度設計”，也不要只簡單的分分層和包、畫一個大體的輪廓圖就草草了事了。正確的軟件架構設計，應該既包括戰(zhàn)略全局上的設計，也包括戰(zhàn)術細節(jié)（關鍵路徑）上的設計。有了這種科學的態(tài)度和方法，我們有理由相信自己團隊決策的正確性和有效性。而我們精心的架構設計，不但滿足系統(tǒng)用戶、開發(fā)人員、系統(tǒng)管理員、部署管理員、數(shù)據(jù)管理員等各個角色的要求，更為項目的最終成功打下了最堅實的基礎。（中國軟件評測中心 李征宇 ）
聯(lián)系客服
