軟件架構(gòu)設(shè)計

軟件架構(gòu)設(shè)計軟件架構(gòu)設(shè)計的目的對于外包業(yè)務(wù)類型的項目，軟件架構(gòu)設(shè)計的目的與產(chǎn)品類型的項目有所不同，在這里主要討論外包類型項目的軟件架構(gòu)設(shè)計目的。1、為大規(guī)模開發(fā)提供基礎(chǔ)和規(guī)范，并提供可重用的資產(chǎn)，軟件系統(tǒng)的大規(guī)模開發(fā)，必須要有一定的基礎(chǔ)和遵循一定的規(guī)范，這既是軟件工程本身的要求，也是客戶的要求。架構(gòu)設(shè)計的過程中可以將一些公共部分抽象提取出來，形成公共類和工具類，以達到重用的目的。2、 一定程度上縮短項目的周期，利用軟件架構(gòu)提供的框架或重用組件，縮短項目開發(fā)的周期。3、 降低開發(fā)和維護的成本，大量的重用和抽象，可以提取出一些開發(fā)人員不用關(guān)心的公共部分，這樣便可以使開發(fā)人員僅僅關(guān)注于業(yè)務(wù)邏輯的實現(xiàn)，從而減少了很多工作量，提高了開發(fā)效率。4、 提高產(chǎn)品的質(zhì)量，好的軟件架構(gòu)設(shè)計是產(chǎn)品質(zhì)量的保證，特別是對于客戶常常提出的非功能性需求的滿足。軟件架構(gòu)設(shè)計的原則軟件架構(gòu)設(shè)計必須遵循以下原則：1、滿足功能性需求和非功能需求。這是一個軟件系統(tǒng)最基本的要求，也是架構(gòu)設(shè)計時應(yīng)該遵循的最基本的原則。2、實用性原則，就像每一個軟件系統(tǒng)交付給用戶使用時必須實用，能解決用戶的問題一樣，架構(gòu)設(shè)計也必須實用，否則就會“高來高去”或“過度設(shè)計”。3、滿足復(fù)用的要求，最大程度的提高開發(fā)人員的工作效率。軟件架構(gòu)設(shè)計的幾種視圖我們常常在討論架構(gòu)設(shè)計該做些什么的時候，或是在架構(gòu)設(shè)計評審的會議上，會提出各種各樣的問題，例如開發(fā)人員該如何記錄Log，事務(wù)如何控制？怎樣才能提高我們的開發(fā)人員的工作效率，即在單位時間內(nèi)更有品質(zhì)的完成更多的功能？怎樣滿足客戶的非功能性需求？怎樣讓生產(chǎn)環(huán)境的平臺管理人員更好的維護系統(tǒng)？上面這些問題，實際上是軟件系統(tǒng)的不同的干系人站在不同的角度上提出的問題，要回答上面這些問題，我們就得從不同的視角來看待軟件架構(gòu)設(shè)計這項工作。1、 邏輯架構(gòu)視角，從系統(tǒng)用戶的角度考慮問題，設(shè)計出來的軟件架構(gòu)能夠滿足業(yè)務(wù)邏輯的需求，能夠處理現(xiàn)在越來越復(fù)雜的業(yè)務(wù)邏輯需求。2、 開發(fā)架構(gòu)視角，從系統(tǒng)開發(fā)人員的角度來考慮問題，設(shè)計的架構(gòu)要易于理解，易于開發(fā)，易于單元測試，最好做到讓開發(fā)人員可以用最少的代碼行數(shù)完成功能的開發(fā)。3、 運行架構(gòu)視角，從系統(tǒng)運行時的質(zhì)量需求考慮問題，特別關(guān)注于系統(tǒng)的非功能需求，客戶常常都會要求我們系統(tǒng)的功能畫面的最長響應(yīng)時間不超過4秒，能滿足2000個用戶同時在線使用，基于角色的系統(tǒng)資源的安全控制等。4、物理架構(gòu)視角，關(guān)注系統(tǒng)安裝和部署在什么樣的環(huán)境上，例如現(xiàn)在最流行的企業(yè)應(yīng)用服務(wù)解決方案IBMHttpServer+WebSphereApplicationServer+DB2,WebLogic+Oracle等。5、數(shù)據(jù)架構(gòu)視角，如今我們開發(fā)的各類系統(tǒng)，如MIS,ERP,SAP,基本上都是對各類數(shù)據(jù)的操作，把一堆不太好懂的數(shù)據(jù)展現(xiàn)成用戶容易看懂的數(shù)據(jù)，自動處理各類數(shù)據(jù)的運算等，所以數(shù)據(jù)的持久化是十分重要的一件事情。1、分析需求和理解業(yè)務(wù)模型（或領(lǐng)域建模），并選定關(guān)鍵Usecase。軟件的需求，可以分為從用戶視角和開發(fā)人員視角來看，從用戶的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級別去全面的認(rèn)識需求并分析需求，理解業(yè)務(wù)模型。實踐表明，常常被我們忽視的非功能性需求常常會導(dǎo)致整個項目失敗。理解業(yè)務(wù)需求最好的方式莫過于進行領(lǐng)域建模，領(lǐng)域建模與需求分析往往是交替穿叉進行的，領(lǐng)域建模主要有以下三個方面的作用：?探索復(fù)雜問題，弄清領(lǐng)域知識。MartinFowler曾經(jīng)說過，他采用面向?qū)ο蠓椒ㄗ畲蟮暮锰幘褪撬兄诮鉀Q更為復(fù)雜的問題。領(lǐng)域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業(yè)務(wù)概念及其關(guān)系上，使我們能夠不斷深入地，系統(tǒng)的對需求進行分析和認(rèn)識。領(lǐng)域建模往往是一個從模糊到清晰，從零散到系統(tǒng)的過程。?決定功能范圍，影響可擴展性。任何模型都是對現(xiàn)實世界某種程序的抽象，這種抽象就會忽略某一些東西，例如忽略對象的屬性和對象間的關(guān)系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。模型揭示了各種功能背后的結(jié)構(gòu)，如果說定義功能相當(dāng)于“拍照片”的話，那么領(lǐng)域建模就相當(dāng)于“做透視”，更加關(guān)注問題領(lǐng)域的內(nèi)在結(jié)構(gòu)，相當(dāng)于對問題領(lǐng)域進行了一定的抽象，良好的領(lǐng)域模型不僅能很好的支持現(xiàn)有的功能，而且還可以在一定程度上支持未來可能出現(xiàn)的新需求，體現(xiàn)良好的可擴展性。?提供交流基礎(chǔ)，促進有效溝通。領(lǐng)域建模通常會使用UML圖作為呈現(xiàn)的方式，這樣為我們的溝通提供了方便。當(dāng)然，有時候文字在描述某些特定領(lǐng)域的問題時可能更適合，可以靈活運用。在我們公司的實際軟件開發(fā)流程中，往往領(lǐng)域建模缺少這一環(huán)節(jié)，這可能是在以后的工作中需要進一步提高之處。雖然我們總是期望架構(gòu)設(shè)計師能全面掌握需求，但由于時間和精力的限制，擺在我們面前的現(xiàn)實就是架構(gòu)設(shè)計師沒有時間對所有需求進行深入分析，所以我們的策略就是“把好鋼用在刀刃上”，即把大部分時間和精力花在對決定架構(gòu)最重要的關(guān)鍵需求上。在選擇關(guān)鍵需求時要注意：高優(yōu)先級的需求往往是從用戶的角度來看的，可能并不是真正的關(guān)鍵需求。在《RUP實踐者指南》一書中向我們講述了如何確定關(guān)鍵功能需求？A.作為應(yīng)用程序的核心或?qū)崿F(xiàn)了系統(tǒng)的主要接口的功能，B.必須被實現(xiàn)的功能，即如果這些功能不被實現(xiàn)，則開發(fā)出來的軟件就失去了價值，C.覆蓋了系統(tǒng)架構(gòu)的一些方面，但沒有被其他重要的Usecase覆蓋到的功能。2、分別從各個視角來考慮軟件架構(gòu)的方方面面。軟件的架構(gòu)設(shè)計必須考慮到各方面，根據(jù)前期工作確立的領(lǐng)域模型，關(guān)鍵需求，系統(tǒng)約束等進行設(shè)計，必須從系統(tǒng)用戶，開發(fā)人員，系統(tǒng)管理員，部署管理員，數(shù)據(jù)管理員等人員的角度去分析并解決問題。比如說，如果我們的運行架構(gòu)采用Cluster方式時，就必須小心Cache和Session等的使用；如果我們的業(yè)務(wù)邏輯要求我們要操作多個數(shù)據(jù)庫時，就要考慮采用支持二階段事務(wù)提交的方式。只有將這些方方面面的問題都考慮到了，這樣的架構(gòu)設(shè)計才是完整的。至于每一個視圖中，我們應(yīng)該設(shè)計到什么細(xì)節(jié)這一問題，實際上與整個項目的過程定義有關(guān)。例如，如果我們有專門安排數(shù)據(jù)庫概要設(shè)計的活動，那我們在架構(gòu)設(shè)計的過程中就可以只需要關(guān)注更高層次的數(shù)據(jù)庫特性及數(shù)據(jù)庫之間的關(guān)系，而每一張表的數(shù)據(jù)字典可以在后續(xù)的相關(guān)活動中進行設(shè)計，但如果沒有這樣的活動，那我們就要細(xì)化到每一張表的每一個欄位，以及表之間的關(guān)系。3、解決技術(shù)面的重點問題和難題在軟件架構(gòu)設(shè)計的過程中，我們往往會需要攻克一些技術(shù)面的重點問題和難題，這完全是一項極其需要扎實的理論知識和豐富的實踐經(jīng)驗支撐的工作。例如，我們?nèi)绾翁岣哒麄€系統(tǒng)的性能？如何能很好的導(dǎo)出極其復(fù)雜的“中國式報表”（一般比西方國家產(chǎn)出的報表要復(fù)雜很多，而且很多開源的BI類的框架并不能完全解決問題）？當(dāng)遇到確實是很困難的問題，可以去百度一下或Google一下，也可以去請教公司的資深技術(shù)人員或?qū)＜?，或者召開小范圍的技術(shù)專題討論會議，采用腦力激蕩的方法試著找找答案，這樣才能提高工作的效率。4、召開架構(gòu)設(shè)計評審會議進行同行評審。架構(gòu)設(shè)計評審是極其重要的一環(huán)，我曾將其形容為“七種武器”中的離別鉤，就是因為在會議上，同行們可能會提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，并做好記錄，正所謂“良藥苦口利于病，忠言逆耳利于行”。在評審會議之前，我們要完成很多準(zhǔn)備工作，最好是能準(zhǔn)備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目的，在會議前就將這些資料發(fā)給與會人員，請他們抽空先了解一下，在會議進行時，要學(xué)會控制會議的進度，提高會議的效率。5、針對關(guān)鍵Usecase在設(shè)計的架構(gòu)上實現(xiàn)功能來驗證架構(gòu)。對于架構(gòu)設(shè)計的驗證也是一項十分重要的工作，其驗證技術(shù)有很多種，在我們公司通常會采用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣做的好處是既可以從實際的產(chǎn)品角度出發(fā)來有效的驗證架構(gòu)是否滿足要求，又可以比拋棄型原型驗證技術(shù)節(jié)省成本。這個Sample絕不是我們在解決架構(gòu)設(shè)計中的問題時拿來做實驗的一些代碼的拼湊，而是完整的實現(xiàn)某一關(guān)鍵Usecase的符合架構(gòu)設(shè)計和一系列規(guī)范的可交付的代碼及相關(guān)文檔。同時，這個Sample可以作為你在給大家講解或培訓(xùn)架構(gòu)時的教材，也可以作為開發(fā)人員使用此架構(gòu)進行開發(fā)的藍(lán)本，甚至是只需要復(fù)制粘貼，加上簡單的修改即可。6、交付給客戶Reviewo 這一環(huán)節(jié)，在很多公司可能并不存在，因為他們的軟件架構(gòu)并不一定需要客戶Review，但像我們這種做服務(wù)的公司，最重要的就是客尊，落實到軟件架構(gòu)設(shè)計這一活動，就是讓客戶理解并接受你的架構(gòu)設(shè)計方案，同時，客戶也會起到幫你驗證架構(gòu)的作用。通常，我們的架構(gòu)得到客戶的認(rèn)可后，便可進入大規(guī)模的開發(fā)。在交付給客戶Review時，通?？赡軙詴h的形式進行Review，所以我們可以參照評審會議時好的做法來召開會議，在這里就不再冗述。軟件架構(gòu)設(shè)計的常見誤區(qū)及解決辦法1、架構(gòu)設(shè)計的常常會"高來高去”。所謂高來高去，實際上就是我們的架構(gòu)設(shè)計僅停留在模型階段，但也絕不是產(chǎn)生第一支樣例程式。2、架構(gòu)設(shè)計時常常會在某些方面過度設(shè)計(Overengineering)。為了一些根本不會發(fā)生的變化而進行一系列復(fù)雜的設(shè)計，這樣的設(shè)計就叫過度設(shè)計，往往會帶來資源的浪費并且會增加開發(fā)的工作量或難度。雖然我們必須考慮到系統(tǒng)的擴展性，可維護性等，但切忌過度設(shè)計。有時候或許你并不能判斷出哪些設(shè)計是過度設(shè)計，此時你可以請教你的PM，讓他站在整個項目的高度來幫你決策一下。3、架構(gòu)(Architecture)不是框架(Framework)，也不是簡單的將幾種框架或技術(shù)的組合，框架本身也是有架構(gòu)的?？蚣芤话闶轻槍τ谀骋环矫婊蝾I(lǐng)域的重用性和可擴展性非常好的半成品，我們可以用一句較為經(jīng)典的話來總結(jié)：框架是軟件，架構(gòu)不是軟件，框架是一種特殊的軟件。我們在工作中通過將許多方面的可重用的工具類，公共類，基礎(chǔ)類等抽象出來，即可形成一些可重用的框架。4、架構(gòu)設(shè)計絕不是新技術(shù)展示平臺，合適的技術(shù)才是對于項目有利的技術(shù)，必須考慮到開發(fā)人員的能力和維護人員的能力。作為一名架構(gòu)設(shè)計師應(yīng)該更多的考慮如何平衡業(yè)務(wù)需求，織織運作（主要指團隊中的協(xié)作）和技術(shù)三者的關(guān)系，而不僅僅是去關(guān)注那些技術(shù)細(xì)節(jié)。5、架構(gòu)設(shè)計的成功與否決定著系統(tǒng)品質(zhì)的好壞，因為架構(gòu)設(shè)計不好而導(dǎo)致交付的系統(tǒng)Bug過多，無法滿足客戶非功能性需求等問題，從而導(dǎo)致項目取消的案例時有發(fā)生。架構(gòu)設(shè)計不是架構(gòu)設(shè)計師一個人的事情，也不是幾天就能完成的一項工作，必須是架構(gòu)設(shè)計師付出大量辛勤勞動后的成果，其成敗往往與組織、主管、項目經(jīng)理的支持有著密切的關(guān)系。關(guān)于架構(gòu)設(shè)計的一點通用技巧1、分層（Layer）規(guī)則。這里的層是指邏輯上的層次（Layer），并非指物理上的層次（Tier）。目前的絕大多數(shù)的企業(yè)級應(yīng)用系統(tǒng)中都分為三層，即表現(xiàn)層，領(lǐng)域?qū)雍蛿?shù)據(jù)層。在對各層次進行劃分時，主要可以從以下幾個方面來考慮：A、每一層是一個相對獨立的部分，可以作為一個整體，無需對其它層了解；B、將層次間的依賴性降到最低，即降低耦合；C、可以從某種程度上替換掉某一層，而對其它層不會產(chǎn)生過多的影響；D，層次并不能封閉所有的東西，假如用戶界面上增加了一個欄位，那么領(lǐng)域?qū)泳鸵黾右粋€數(shù)據(jù)域，數(shù)據(jù)層就要增加一個相應(yīng)的字段。同時，過多的分層可能會對性能造成一定的影響。2、 包（package）之間不要產(chǎn)生循環(huán)依賴。通常包的劃分會先按不同的邏輯層來劃分，在層的包下面再按功能來劃分。避免包間的循環(huán)依賴是一個比較通用的規(guī)則，這樣的規(guī)則一定有其存在的價值和道理，之所以這樣主要是出于以下原因：A、循環(huán)依賴會使分層失去意義；B、循環(huán)依賴會帶來許多潛在的風(fēng)險，如可能會產(chǎn)生嵌套事務(wù)（nestedtransaction，JavaEE標(biāo)準(zhǔn)中并不支持這種事務(wù)）的現(xiàn)象，我就曾遇到過這樣的問題，在一個項目中，事務(wù)放在業(yè)務(wù)邏輯層統(tǒng)一控制，但由于開發(fā)人員忽視了架構(gòu)中這樣的原則，在持久層調(diào)用了展現(xiàn)層