J2EE項(xiàng)目實(shí)訓(xùn)UML及設(shè)計(jì)模式——第3章 系統(tǒng)概要設(shè)計(jì)中的架構(gòu)設(shè)計(jì)（第2部分）

1、楊教授工作室 精心創(chuàng)作的優(yōu)秀程序員 職業(yè)提升必讀系列資料第3章 系統(tǒng)概要設(shè)計(jì)中的架構(gòu)設(shè)計(jì)（第2/3部分）1.1.1 軟件系統(tǒng)的架構(gòu)師1、什么是軟件系統(tǒng)架構(gòu)師（architecture）（1）架構(gòu)師是軟件行業(yè)中的一種新興職業(yè)所謂軟件系統(tǒng)的架構(gòu)師通俗地說(shuō)就是軟件系統(tǒng)的設(shè)計(jì)師、結(jié)構(gòu)設(shè)計(jì)者，或者按照現(xiàn)有的國(guó)內(nèi)企業(yè)的技術(shù)職稱來(lái)對(duì)照，應(yīng)該為“總工程師”的角色的人員。比如我們常說(shuō)bill gate是微軟公司的系統(tǒng)構(gòu)架師。（2）誰(shuí)能夠勝任軟件架構(gòu)師的工作職責(zé)軟體開(kāi)發(fā)中有一些技術(shù)水平較高、行業(yè)經(jīng)驗(yàn)較為豐富的人，他們可以承擔(dān)軟件系統(tǒng)的架構(gòu)設(shè)計(jì)工作。從而保證所開(kāi)發(fā)出的軟件系統(tǒng)項(xiàng)目或者軟件產(chǎn)品能夠符合投資人的技術(shù)要求

2、。（3）架構(gòu)師主要的工作內(nèi)容軟件系統(tǒng)的架構(gòu)師也就是需要設(shè)計(jì)軟件系統(tǒng)中的各個(gè)部件（邏輯的、物理的），這包括如何劃分軟件系統(tǒng)的總體結(jié)構(gòu)、系統(tǒng)中的各個(gè)模塊組件之間是如何發(fā)生相互作用，如何使應(yīng)用系統(tǒng)滿足性能等方面的要求。2、架構(gòu)師的主要工作職責(zé)架構(gòu)師的主要工作職責(zé)是保證在一個(gè)軟件項(xiàng)目開(kāi)發(fā)的過(guò)程中，能夠?qū)⒖蛻舻母鞣N需求轉(zhuǎn)換為規(guī)范的開(kāi)發(fā)計(jì)劃及相關(guān)的文檔；并制定這個(gè)項(xiàng)目的總體架構(gòu)設(shè)計(jì)的方案，同時(shí)也應(yīng)該要指導(dǎo)整個(gè)開(kāi)發(fā)團(tuán)隊(duì)完成對(duì)這個(gè)設(shè)計(jì)方案的具體實(shí)現(xiàn)。盡管對(duì)軟件架構(gòu)師的角色有這樣或那樣的定義或描述，但大體上下面的幾個(gè)職責(zé)是必需要承擔(dān)的：（1）技術(shù)方向的決定、技術(shù)風(fēng)險(xiǎn)的承擔(dān)，具體的解決方案的提供者或者建議者（2）

3、與項(xiàng)目經(jīng)理緊密合作，共同制定出本項(xiàng)目的開(kāi)發(fā)計(jì)劃和過(guò)程控制，決定項(xiàng)目中的成員、組織項(xiàng)目的開(kāi)發(fā)團(tuán)隊(duì)（3）最終保證軟件項(xiàng)目能夠按時(shí)、按質(zhì)地順利地完成3、軟件架構(gòu)師的主要任務(wù)（1）首先需要明確的是“自己不做什么，而不是考慮做什么”因?yàn)榧軜?gòu)師的主要任務(wù)和工作的內(nèi)容不應(yīng)該是從事具體的軟件程序的編寫(xiě)，也不是承擔(dān)繁瑣的行政管理等方面的工作，更不是像有些國(guó)營(yíng)企業(yè)的總工程師，大部分時(shí)間都是忙于應(yīng)酬和請(qǐng)客吃飯！而應(yīng)該是從事更高層次的有關(guān)技術(shù)方向的制定、技術(shù)難題的攻關(guān)、系統(tǒng)開(kāi)發(fā)和架構(gòu)工作，架構(gòu)師不是程序員，也不應(yīng)該成為行政領(lǐng)導(dǎo)！ （2）不應(yīng)該只是從純技術(shù)的角度來(lái)考慮整個(gè)軟件項(xiàng)目的實(shí)施架構(gòu)設(shè)計(jì)工作不應(yīng)該僅僅考慮技術(shù)方面

4、的問(wèn)題，也應(yīng)該考慮如何與本企業(yè)的發(fā)展方向相匹配來(lái)選擇技術(shù)。從而通過(guò)本次項(xiàng)目的開(kāi)發(fā)為企業(yè)的發(fā)展提供“內(nèi)功”和儲(chǔ)備“能量”這包括人才的培養(yǎng)和儲(chǔ)備。（3）預(yù)見(jiàn)客戶的技術(shù)走向，從而在早期決定技術(shù)研發(fā)的方向和技術(shù)的積累架構(gòu)師必須對(duì)本軟件系統(tǒng)所涉及的相關(guān)的開(kāi)發(fā)技術(shù)要非常了解，同時(shí)還應(yīng)該對(duì)系統(tǒng)所涉及的業(yè)務(wù)規(guī)則也應(yīng)該比較熟悉；并且需要有一定的良好組織管理能力。因此，一個(gè)系統(tǒng)架構(gòu)師的工作能力的高低會(huì)決定整個(gè)軟件開(kāi)發(fā)項(xiàng)目的成敗和軟件的總體質(zhì)量。（4）在架構(gòu)設(shè)計(jì)的實(shí)踐工作中，最好不要過(guò)分地追求新技術(shù)的應(yīng)用不要使用時(shí)髦但還不成熟、不可靠的技術(shù)，因?yàn)檫@樣會(huì)增加項(xiàng)目實(shí)現(xiàn)過(guò)程中的技術(shù)風(fēng)險(xiǎn)。同時(shí)架構(gòu)師必須也要關(guān)注軟件系統(tǒng)的需

5、求、并參與系統(tǒng)的需求分析活動(dòng)。4、努力學(xué)習(xí)把自己培養(yǎng)和鍛煉成為軟件架構(gòu)師（1）軟件架構(gòu)師初始的職業(yè)為程序員因?yàn)檐浖軜?gòu)師首先必須在技術(shù)上要比較過(guò)硬，這可以通過(guò)在程序員的職業(yè)階段加以積累和豐富自己的技術(shù)能力。 當(dāng)然在此階段中所應(yīng)該要把握的是，在實(shí)際的軟件開(kāi)發(fā)中不斷地積累的應(yīng)該是對(duì)問(wèn)題的分析能力、對(duì)出錯(cuò)情況之診斷能力、對(duì)軟件系統(tǒng)的結(jié)構(gòu)的設(shè)計(jì)能力, 而不應(yīng)該僅僅停留在編寫(xiě)代碼的能力方面。（2）從程序員逐步成為高級(jí)程序員當(dāng)然，也不是所有的程序員都能夠成長(zhǎng)為系統(tǒng)架構(gòu)師，而應(yīng)該是對(duì)技術(shù)有自己的獨(dú)特的理解和掌握能力的程序員，同時(shí)在技術(shù)等方面應(yīng)該有比較廣泛的知識(shí)面。在開(kāi)發(fā)團(tuán)隊(duì)中，逐步體現(xiàn)出自己對(duì)項(xiàng)目中所遇到的

6、實(shí)際問(wèn)題的解決能力、并不斷地加以提高，慢慢成長(zhǎng)為程序員隊(duì)伍中的“領(lǐng)頭羊”。（3）從程序員提升為設(shè)計(jì)師由于軟件系統(tǒng)的架構(gòu)師和程序員（coding）在職業(yè)的范疇和工作的性質(zhì)、工作的內(nèi)容、解決問(wèn)題的思路等方面是有差別的，同時(shí)對(duì)兩者在技術(shù)能力的要求也是不同的。優(yōu)秀的程序員經(jīng)過(guò)多個(gè)項(xiàng)目的實(shí)際鍛煉，逐步將對(duì)項(xiàng)目的設(shè)計(jì)等方面的工作有一定的感捂后，能夠培養(yǎng)成為企業(yè)應(yīng)用系統(tǒng)的設(shè)計(jì)師。對(duì)設(shè)計(jì)工作初步涉及和參與，并不斷地積累系統(tǒng)設(shè)計(jì)方面的經(jīng)驗(yàn)。（4）系統(tǒng)架構(gòu)師應(yīng)該是高級(jí)設(shè)計(jì)師的角色因?yàn)閷?duì)系統(tǒng)架構(gòu)師應(yīng)該有一定的系統(tǒng)的整體觀念的要求，這主要體現(xiàn)在分析問(wèn)題的能力、把握抽象的能力、綜合地應(yīng)用知識(shí)解決問(wèn)題的能力等方面；同時(shí)也

7、應(yīng)該有一定的溝通能力，比如與客戶溝通能力、與項(xiàng)目組中的其它成員的溝通能力；在知識(shí)面方面應(yīng)該有一定的廣度和深度，不僅要把握本行業(yè)的技術(shù)發(fā)展、流行的趨勢(shì)，同時(shí)也還應(yīng)該掌握與系統(tǒng)架構(gòu)相關(guān)的知識(shí)和擁有相應(yīng)的行業(yè)經(jīng)驗(yàn)；最后還應(yīng)該具有很強(qiáng)的自學(xué)能力、分析能力、解決問(wèn)題的能力?！俺绦騿T-高級(jí)程序員-項(xiàng)目實(shí)施工程師-it咨詢專家-資深it專家”的發(fā)展過(guò)程。這是系統(tǒng)架構(gòu)師培養(yǎng)的路線。同時(shí)軟件架構(gòu)設(shè)計(jì)也是一個(gè)非常嚴(yán)肅、細(xì)致、敏感而且技術(shù)困難的工作，必須一點(diǎn)一滴地認(rèn)真做起，扎扎實(shí)實(shí)地努力，實(shí)實(shí)在在地積累經(jīng)驗(yàn)，尤其是在失敗中積累和豐富經(jīng)驗(yàn)。5、軟件架構(gòu)師與系統(tǒng)分析師的區(qū)別（1）軟件項(xiàng)目開(kāi)發(fā)團(tuán)隊(duì)中人員的一般組成在一個(gè)較

8、大規(guī)模的軟件開(kāi)發(fā)的團(tuán)隊(duì)中，一般應(yīng)該有項(xiàng)目管理師（項(xiàng)目經(jīng)理）、軟件架構(gòu)師、系統(tǒng)分析師、軟件設(shè)計(jì)師、測(cè)試工程師、數(shù)據(jù)庫(kù)工程師、程序員、過(guò)程改進(jìn)、質(zhì)量保證等不同的角色或者崗位的人員。（2）系統(tǒng)分析師的主要工作內(nèi)容系統(tǒng)分析師的主要工作內(nèi)容是包括對(duì)系統(tǒng)中所涉及的業(yè)務(wù)需求進(jìn)行分析、可行性分析以及系統(tǒng)建模等方面，其工作的特點(diǎn)和性質(zhì)更多地是與行業(yè)領(lǐng)域?qū)＜?、用戶溝通，以及與項(xiàng)目經(jīng)理（項(xiàng)目管理師）、軟件架構(gòu)師以及企業(yè)的負(fù)責(zé)人進(jìn)行交流，分析項(xiàng)目具備的特點(diǎn)、成本、風(fēng)險(xiǎn)等方面的因素。（3）軟件架構(gòu)師的主要工作內(nèi)容本節(jié)在前面介紹了軟件架構(gòu)師的主要工作內(nèi)容，現(xiàn)在再歸納和總結(jié)一下：是在系統(tǒng)需求比較清晰的條件下進(jìn)行軟件系統(tǒng)總體

9、的架構(gòu)設(shè)計(jì)和技術(shù)的方向性把握，項(xiàng)目中的技術(shù)難題的解決。當(dāng)然它也可能會(huì)涵蓋一些系統(tǒng)分析師的工作內(nèi)容和軟件設(shè)計(jì)師的內(nèi)容，但其特點(diǎn)是做出技術(shù)決定或者技術(shù)決策，力求為軟件系統(tǒng)找到或架構(gòu)出一個(gè)最優(yōu)的軟件系統(tǒng)的模型。6、有關(guān)軟件架構(gòu)設(shè)計(jì)工作中的幾個(gè)觀點(diǎn)（1）要承認(rèn)軟件系統(tǒng)本身是不完美的因?yàn)槿魏稳藢?duì)問(wèn)題的理解和把握也都是循序漸進(jìn)的過(guò)程。必然也會(huì)導(dǎo)致對(duì)問(wèn)題的解決也應(yīng)該是不斷地完善和豐富的過(guò)程，否則軟件系統(tǒng)就不會(huì)有升級(jí)和改進(jìn)版本的必要！但這并不意味著對(duì)本次設(shè)計(jì)和開(kāi)發(fā)實(shí)現(xiàn)，可以掉以輕心?。?）要承認(rèn)軟件的需求是不完全的、是動(dòng)態(tài)地變化的正是由于軟件系統(tǒng)本身的需求是動(dòng)態(tài)地變化的，否則軟件系統(tǒng)的架構(gòu)設(shè)計(jì)工作不會(huì)出現(xiàn)那么

10、多的矛盾，那么棘手！那么多的不確定因素！哪如何開(kāi)展軟件系統(tǒng)的架構(gòu)和設(shè)計(jì)工作呢？關(guān)鍵是要學(xué)會(huì)“擁抱變化、適應(yīng)變化”而設(shè)計(jì)，因?yàn)椴豢赡艿鹊较到y(tǒng)的需求“不再變化”時(shí)再開(kāi)展架構(gòu)設(shè)計(jì)工作。（3）在衡量軟件系統(tǒng)的各種性能標(biāo)準(zhǔn)中，什么是架構(gòu)師最需要關(guān)注的呢？首先應(yīng)該是系統(tǒng)的穩(wěn)定性、安全性和可擴(kuò)展性；其次再是系統(tǒng)所采用的技術(shù)的先進(jìn)性。因此，技術(shù)并不是第一位的！技術(shù)是解決問(wèn)題的、但不是系統(tǒng)的根本！因?yàn)橛脩糇罱K所需要的是一個(gè)能夠滿足其業(yè)務(wù)需要的穩(wěn)定、可靠的應(yīng)用系統(tǒng)。（4）架構(gòu)師最重要的處理和解決問(wèn)題的素質(zhì)應(yīng)該是把握解決問(wèn)題的重點(diǎn)！另外，在進(jìn)行系統(tǒng)架構(gòu)時(shí)不能僅僅考慮技術(shù)本身，項(xiàng)目的管理和風(fēng)險(xiǎn)控制有時(shí)比技術(shù)更應(yīng)該多地

11、關(guān)注! 1.1.2 軟件架構(gòu)設(shè)計(jì)的目標(biāo) 1、與架構(gòu)相關(guān)的概念之一框架（framework）（1）框架是從技術(shù)的橫切面去解決實(shí)際應(yīng)用問(wèn)題的很多框架表現(xiàn)上一般為中間件技術(shù)，并且是從技術(shù)的角度來(lái)解決同類型的問(wèn)題的。比如apache struts框架就解決j2ee web層的開(kāi)發(fā)和實(shí)現(xiàn)，而spring框架則解決了j2ee平臺(tái)中的類的對(duì)象管理，當(dāng)然hibernate框架則是為應(yīng)用系統(tǒng)解決數(shù)據(jù)訪問(wèn)和o/r mapping的開(kāi)發(fā)和實(shí)現(xiàn)。（2）框架是具體化的架構(gòu)它也是根據(jù)應(yīng)用框架的需求而制定的純技術(shù)方面的實(shí)現(xiàn)支持，主要用于細(xì)化整個(gè)架構(gòu)或某一組成部分。例如apache struts框架是定義web層的框架，sp

12、ring框架是定義應(yīng)用層的框架，而hibernate框架是定義數(shù)據(jù)訪問(wèn)層的框架。（3）框架應(yīng)當(dāng)要更多地體現(xiàn)重用框架應(yīng)當(dāng)要更多地體現(xiàn)出重用，也就是框架應(yīng)當(dāng)包含有設(shè)計(jì)重用（其設(shè)計(jì)方案能夠被重用）和代碼重用（其代碼能夠被重用）兩層意思，并且是架構(gòu)在某一問(wèn)題域的具體化的實(shí)現(xiàn)方案，更關(guān)注的是可重用性。l 框架中的設(shè)計(jì)重用一般是通過(guò)提供或者借助于設(shè)計(jì)模式來(lái)體現(xiàn)。如在apache struts框架中就應(yīng)用了mvc架構(gòu)模式、j2ee前端控制器模式等，而spring框架中則提供了控制反轉(zhuǎn)（ioc）和依賴注入（di）模式。l 框架中的代碼重用一般是通過(guò)提供基礎(chǔ)組件和對(duì)應(yīng)的api（包括類和接口）、并通過(guò)模板模式回調(diào)

13、框架的使用者的具體實(shí)現(xiàn)代碼來(lái)體現(xiàn)。如struts框架中的actionservlet、actionform和action等組件類。2、與架構(gòu)相關(guān)的概念之二設(shè)計(jì)模式（design pattern）設(shè)計(jì)模式則主要側(cè)重于思想和方法（如mvc模式、橋模式、命令模式、工廠模式等），不象框架那樣明確地提供了組件。因?yàn)樵谔幚泶罅繂?wèn)題時(shí)，在很多不同的問(wèn)題中經(jīng)常會(huì)重復(fù)出現(xiàn)相同的解決方法但細(xì)節(jié)永不會(huì)重復(fù)的性質(zhì)的內(nèi)容。模式化過(guò)程是把問(wèn)題抽象化，在忽略掉不重要的細(xì)節(jié)后發(fā)現(xiàn)問(wèn)題的一般性的本質(zhì)，并找到普遍使用的方法去解決的過(guò)程。因此，設(shè)計(jì)模式是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過(guò)分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。并且是在大量的

14、實(shí)踐中總結(jié)和理論化之后的優(yōu)選的代碼結(jié)構(gòu),編程風(fēng)格, 及解決問(wèn)題的思考方式。3、架構(gòu)設(shè)計(jì)的目標(biāo)之一是希望能夠達(dá)到最大化地重用（1）在系統(tǒng)架構(gòu)設(shè)計(jì)中靈活地使用各種共享的、特別是開(kāi)源的框架技術(shù)當(dāng)架構(gòu)師成功地實(shí)施了某個(gè)系統(tǒng)的架構(gòu)后，應(yīng)該概括和總結(jié)出在本項(xiàng)目中的一些共性的和經(jīng)驗(yàn)性的內(nèi)容，并把它提煉出來(lái)。這樣將有助于下次的系統(tǒng)設(shè)計(jì)中能夠重用，以避免重復(fù)地解決相似的問(wèn)題，因?yàn)槊總€(gè)不同的項(xiàng)目只是有其內(nèi)容和一些實(shí)現(xiàn)細(xì)節(jié)方面的差別。但問(wèn)題是，如何能夠?qū)崿F(xiàn)和達(dá)到最大化的重用？一般應(yīng)該在系統(tǒng)架構(gòu)設(shè)計(jì)中靈活地使用各種共享的、特別是開(kāi)源的框架技術(shù)。因?yàn)橐粋€(gè)共享的架構(gòu)，可以使企業(yè)開(kāi)發(fā)團(tuán)隊(duì)很方便地分解問(wèn)題，從而確定出本項(xiàng)目中

15、哪些功能模塊是可以由企業(yè)本身（或者開(kāi)發(fā)組）內(nèi)部解決和具體開(kāi)發(fā)實(shí)現(xiàn)的，而哪些功能模塊可以使用已有的外部服務(wù)，以避免重新開(kāi)發(fā)實(shí)現(xiàn)。（2）在系統(tǒng)架構(gòu)設(shè)計(jì)中為什么要應(yīng)用成熟的框架？1) 首先，由于軟件系統(tǒng)發(fā)展到現(xiàn)在已經(jīng)很復(fù)雜了，特別是對(duì)于服務(wù)器端的軟件系統(tǒng)的開(kāi)發(fā)實(shí)現(xiàn)，所涉及到的知識(shí)、內(nèi)容、要解決的技術(shù)問(wèn)題實(shí)在是太多！在某些方面使用第三方成熟的框架，就相當(dāng)于讓別人幫助開(kāi)發(fā)者完成了一些基礎(chǔ)性的工作，此時(shí)的開(kāi)發(fā)者只需要集中精力和時(shí)間來(lái)完成系統(tǒng)的業(yè)務(wù)邏輯設(shè)計(jì)和實(shí)現(xiàn)。2) 而且框架一般是成熟、穩(wěn)健的，并且已經(jīng)幫助應(yīng)用系統(tǒng)的開(kāi)發(fā)者處理了系統(tǒng)中很多的技術(shù)細(xì)節(jié)問(wèn)題。比如，軟件系統(tǒng)中的對(duì)象生命周期管理、對(duì)象的緩存、事務(wù)

16、（本地和分布式）處理，身份驗(yàn)證等安全性，數(shù)據(jù)的訪問(wèn)和數(shù)據(jù)流的控制等方面的技術(shù)問(wèn)題。3) 另外，成熟的框架一般都是經(jīng)過(guò)很多開(kāi)發(fā)者使用過(guò)的，所以系統(tǒng)本身的結(jié)構(gòu)也應(yīng)該是比較好的，同時(shí)應(yīng)用該框架的上層軟件系統(tǒng)本身的擴(kuò)展性也會(huì)很好；框架本身由于也是不斷地升級(jí)的，這樣開(kāi)發(fā)者就可以直接享受別人升級(jí)框架后對(duì)自身的軟件系統(tǒng)所帶來(lái)的好處。（3）采用struts + spring +hibernate三種框架技術(shù)來(lái)架構(gòu)j2ee的輕量級(jí)系統(tǒng)示例在下面的圖3.8中示例了某個(gè)系統(tǒng)的整體架構(gòu)設(shè)計(jì)的示例，該系統(tǒng)架構(gòu)是充分地應(yīng)用了目前在j2ee平臺(tái)中比較主流的三種不同形式的框架技術(shù)。圖3.8 某系統(tǒng)的整體架構(gòu)設(shè)計(jì)示圖采用該形式

17、的系統(tǒng)架構(gòu)的主要目的，是希望能夠保證項(xiàng)目在系統(tǒng)架構(gòu)設(shè)計(jì)方面所提出的盡可能達(dá)到系統(tǒng)的可重用性、可擴(kuò)展性及技術(shù)實(shí)現(xiàn)的簡(jiǎn)單化等設(shè)計(jì)目標(biāo)的要求。1) 表示層由基于struts框架的jsp頁(yè)面組件實(shí)現(xiàn)，并且在其中應(yīng)用struts框架的各種標(biāo)簽技術(shù)來(lái)減少頁(yè)面中的jsp腳本的數(shù)量，同時(shí)也應(yīng)用支持ajax技術(shù)的dwr框架來(lái)產(chǎn)生異步通訊交互的實(shí)現(xiàn)。2) 控制層由基于struts框架的前端控制器actionservlet組件（作為項(xiàng)目的前端控制器，并對(duì)它進(jìn)行重寫(xiě)以滿足項(xiàng)目中的特殊要求）和后端業(yè)務(wù)控制器action組件（實(shí)際是應(yīng)用struts中的dispatchaction類型的action組件）實(shí)現(xiàn)。3) 業(yè)務(wù)處

18、理層由spring框架承擔(dān)，并利用其控制反轉(zhuǎn)ioc技術(shù)實(shí)現(xiàn)對(duì)整個(gè)項(xiàng)目中的從控制層、業(yè)務(wù)處理層和持久層中各個(gè)相關(guān)對(duì)象的實(shí)例進(jìn)行管理，以產(chǎn)生出松藕合的系統(tǒng)類；同時(shí)借助spring框架中的面向切面編程aop技術(shù)，為項(xiàng)目提供各種形式的“攔截器”通知組件以分離系統(tǒng)中的“技術(shù)關(guān)注點(diǎn)”。4) 數(shù)據(jù)訪問(wèn)層由目前比較主流的支持o/r mapping技術(shù)的hibernate框架承擔(dān)，利用其功能強(qiáng)大的o/r mapping技術(shù)以及數(shù)據(jù)緩存等方面的技術(shù)，以實(shí)現(xiàn)面向?qū)ο蟮臄?shù)據(jù)庫(kù)訪問(wèn)操作。同時(shí)也能夠改進(jìn)項(xiàng)目中的數(shù)據(jù)訪問(wèn)的性能。4、架構(gòu)設(shè)計(jì)的目標(biāo)之二是希望能夠達(dá)到最靈活的可擴(kuò)展性（1）軟件系統(tǒng)開(kāi)發(fā)中必須要考慮的一個(gè)問(wèn)題如何

19、盡可能地延長(zhǎng)所開(kāi)發(fā)出的軟件系統(tǒng)的生命期，以降低企業(yè)經(jīng)營(yíng)中在信息化技術(shù)方面的成本和投資？（2）如何達(dá)到本應(yīng)用系統(tǒng)具有“最靈活的可擴(kuò)展性”當(dāng)然，靈活地應(yīng)用各種架構(gòu)模式和代碼的設(shè)計(jì)模式是必要的技術(shù)實(shí)現(xiàn)手段。因?yàn)樵诿嫦驅(qū)ο蠓治?、設(shè)計(jì)和開(kāi)發(fā)中，系統(tǒng)設(shè)計(jì)師和程序員更重視應(yīng)用系統(tǒng)本身和系統(tǒng)在編程實(shí)現(xiàn)時(shí)的代碼的可重用性和可維護(hù)性，這通過(guò)應(yīng)用各種架構(gòu)模式（如可以應(yīng)用j2ee的核心設(shè)計(jì)模式，分布式系統(tǒng)和交互式系統(tǒng)都有特定的架構(gòu)模式）和代碼的設(shè)計(jì)模式（如gof的23種設(shè)計(jì)模式）能夠使設(shè)計(jì)師和程序員可以更加簡(jiǎn)單、方便地重復(fù)使用成功的設(shè)計(jì)和體系結(jié)構(gòu)。同時(shí)，在代碼的設(shè)計(jì)模式中所倡導(dǎo)的面向接口編程，也能夠提高系統(tǒng)的可擴(kuò)展性

20、和可移植性。5、架構(gòu)設(shè)計(jì)的目標(biāo)之三是希望能夠設(shè)計(jì)出“高內(nèi)聚低藕合”的應(yīng)用系統(tǒng)（1）利用“分層”架構(gòu)造實(shí)現(xiàn)系統(tǒng)在縱向上的低耦合比如將應(yīng)用系統(tǒng)在分層設(shè)計(jì)時(shí)，可以劃分為五個(gè)層次。分別是：表示層、控制層、業(yè)務(wù)邏輯層、服務(wù)層（dao）、數(shù)據(jù)訪問(wèn)層。在縱向上分層的目的是為了達(dá)到：表示邏輯、控制邏輯、業(yè)務(wù)邏輯與數(shù)據(jù)訪問(wèn)邏輯的分離和層與層之間的松散耦合。相鄰的層次之間，通過(guò)“接口”進(jìn)行調(diào)用和通信，即：采用面向接口編程的思想，從而實(shí)現(xiàn)了系統(tǒng)的易用維護(hù)和升級(jí)的目的。（2）利用開(kāi)源框架進(jìn)一步確?？v向的分層的具體實(shí)現(xiàn)l 系統(tǒng)的“表示層 + 控制層”采用struts框架技術(shù)來(lái)實(shí)現(xiàn) 原因如下：struts的標(biāo)簽技術(shù)具有強(qiáng)

21、大的功能。因此在表示層中，使得數(shù)據(jù)的顯示、簡(jiǎn)單的邏輯處理以及模板的應(yīng)用非常方便。同時(shí)struts 采用了前段控制器的架構(gòu)模式，這使得表示層與控制層之間能夠更好的實(shí)現(xiàn)松散耦合。同時(shí)進(jìn)行在控制層中進(jìn)行了明確的分工（如：actionservlet與action），為系統(tǒng)的維護(hù)與升級(jí)提供了有力的保障。同時(shí)提供了數(shù)據(jù)連接池、加入了表單驗(yàn)證等機(jī)制等。使得程序設(shè)計(jì)的方面的工作會(huì)更少。l 業(yè)務(wù)邏輯層采用spring 框架技術(shù)來(lái)實(shí)現(xiàn)。原因如下：采用spring技術(shù)主要是利用其“依賴注入”和“控制反轉(zhuǎn)”兩大思想。依賴注入完全實(shí)現(xiàn)了設(shè)計(jì)模式中的抽象工廠方法，同時(shí)更有利于我們實(shí)現(xiàn)面向借口的編程的思想。我們?cè)诳刂茖又兄?/p>

22、需調(diào)用（操縱）業(yè)務(wù)類所實(shí)現(xiàn)的借口，而由spring框架為我們動(dòng)態(tài)的注入對(duì)象。這使得系統(tǒng)今后可以很方便的進(jìn)行升級(jí)和維護(hù)?？刂品崔D(zhuǎn)主要采用了模板模式的設(shè)計(jì)思想，使得我們?cè)诔绦蛟O(shè)計(jì)時(shí)不必再為系統(tǒng)的控制而認(rèn)為的調(diào)用系統(tǒng)類庫(kù)，而只需實(shí)現(xiàn)系統(tǒng)定義的方法或是補(bǔ)充適量的自定義方法即可。即：把控制權(quán)交給了框架，這使可以大大減輕開(kāi)發(fā)的工作量，同時(shí)實(shí)現(xiàn)了“非侵入式”方案（即：輕量級(jí)的框架）。l 系統(tǒng)的“服務(wù)層 + 業(yè)務(wù)邏輯層”可以采用dao模式設(shè)計(jì) + hibernate框架來(lái)實(shí)現(xiàn)原因如下：由于采用面向?qū)ο蟮脑O(shè)計(jì)，而現(xiàn)有的數(shù)據(jù)庫(kù)都是采用結(jié)構(gòu)化進(jìn)行設(shè)計(jì)的，所以需要一種o/r mapping工具來(lái)進(jìn)行關(guān)系數(shù)據(jù)庫(kù)到對(duì)象數(shù)

23、據(jù)的一種映射，hibernate技術(shù)很好的實(shí)現(xiàn)了這種功能。它能夠使得我們采用面向?qū)ο蟮乃枷雭?lái)進(jìn)行數(shù)據(jù)的持久化。同時(shí)它又實(shí)現(xiàn)了日志管理、數(shù)據(jù)緩存、事務(wù)管理等各種技術(shù)，簡(jiǎn)化了程序開(kāi)發(fā)過(guò)程。利用dao模式，主要是對(duì)hibernate的進(jìn)一步封裝。即：用dao實(shí)現(xiàn)了“服務(wù)層”的功能。這樣做的優(yōu)點(diǎn)是避免了業(yè)務(wù)邏輯處理層中直接調(diào)用有關(guān)數(shù)據(jù)訪問(wèn)的操作，實(shí)現(xiàn)了業(yè)務(wù)邏輯層與數(shù)據(jù)訪問(wèn)層之間的松散耦合。（3）通過(guò)功能劃分子系統(tǒng)來(lái)實(shí)現(xiàn)橫方向上的低耦合按照系統(tǒng)功能的聚集關(guān)系對(duì)系統(tǒng)進(jìn)行劃分，通過(guò)將不同的子系統(tǒng)放到不同的目錄下實(shí)現(xiàn)系統(tǒng)橫方向上的劃分。設(shè)計(jì)好各個(gè)不同子系統(tǒng)之間調(diào)用的接口，各子系統(tǒng)面向接口編程，實(shí)現(xiàn)松散耦合。同

24、時(shí)注意應(yīng)用設(shè)計(jì)模式是實(shí)現(xiàn)橫向上的低耦合的有效措施，如：“橋接模式”的應(yīng)用。（4）利用“包”結(jié)構(gòu)確保橫向上的低耦合的具體實(shí)現(xiàn)按照業(yè)務(wù)邏輯進(jìn)行包的劃分。在每個(gè)包的內(nèi)部，同樣采用分層的思想，針對(duì)接口編程，實(shí)現(xiàn)松散耦合。同時(shí)再為每個(gè)包提供一個(gè)或多個(gè)接口，以達(dá)到橫向方向上的低耦合；而在包內(nèi)則充分應(yīng)用封裝策略，使復(fù)雜性內(nèi)聚。6、明確軟件產(chǎn)品或者軟件項(xiàng)目中的“變化”的要素好的軟件產(chǎn)品在開(kāi)發(fā)的過(guò)程中就應(yīng)該要考慮到可能的變化，任何一個(gè)軟件的系統(tǒng)架構(gòu)師都不能解決或者說(shuō)前瞻所有的變化，但是好的軟件的架構(gòu)設(shè)計(jì)（框架和組件）能夠比較容易的適應(yīng)變化。此時(shí)的開(kāi)發(fā)者只需要很小的代價(jià)就能夠完成系統(tǒng)的改動(dòng)和升級(jí)，大大地降低軟件系

25、統(tǒng)的開(kāi)發(fā)和維護(hù)的成本。當(dāng)然，為了能夠達(dá)到該目標(biāo)，需要開(kāi)發(fā)人員特別是系統(tǒng)架構(gòu)師必須明確項(xiàng)目中“變化”的部分有哪些? 并對(duì)這些部分加以隔離。（1）第一方面的可能變化是需求（功能性和非功能性、運(yùn)行環(huán)境）的變化經(jīng)常變化的部分主要是需求，因?yàn)橄到y(tǒng)的功能是不斷地?cái)U(kuò)展和提升的；系統(tǒng)的性能要求也是越來(lái)越高的、應(yīng)用系統(tǒng)所依賴的運(yùn)行環(huán)境也有可能發(fā)生改變。為了不至于拒絕需求的改變而令客戶的利益受損或屈從于需求的改變而導(dǎo)致項(xiàng)目失控。下面的圖3.9 所示為一個(gè)緊密藕合的系統(tǒng)架構(gòu)設(shè)計(jì)的示例，因?yàn)樵撓到y(tǒng)中的前端（控制層和表示層）與系統(tǒng)中的后端緊密關(guān)聯(lián)。圖3.9 緊密藕合的系統(tǒng)架構(gòu)設(shè)計(jì)的示例該系統(tǒng)的設(shè)計(jì)師采用如此的系統(tǒng)架構(gòu)設(shè)

26、計(jì)方案是基于系統(tǒng)中的業(yè)務(wù)處理功能實(shí)現(xiàn)非常簡(jiǎn)單、但對(duì)系統(tǒng)的數(shù)據(jù)訪問(wèn)功能要求卻非常高、數(shù)據(jù)訪問(wèn)的性能也要求比較高，因此系統(tǒng)的分層采用三層，控制層與系統(tǒng)中的持久層直接關(guān)聯(lián)。但該設(shè)計(jì)師對(duì)系統(tǒng)功能的擴(kuò)展和運(yùn)行環(huán)境的變化沒(méi)有預(yù)見(jiàn)性，因?yàn)樵谙到y(tǒng)中的持久層是經(jīng)常會(huì)發(fā)生變化的（如數(shù)據(jù)源變化、數(shù)據(jù)連接的方式、數(shù)據(jù)訪問(wèn)操作的功能等），同時(shí)系統(tǒng)的前端也是可能經(jīng)常會(huì)變化的（如從瀏覽器改變?yōu)閼?yīng)用程序窗口、或者改變?yōu)槭謾C(jī)屏幕）。因此，必須要將應(yīng)用系統(tǒng)中的經(jīng)常變化的部分進(jìn)行隔離！這樣就不會(huì)出現(xiàn)相互影響的局面。這可以通過(guò)數(shù)據(jù)訪問(wèn)服務(wù)層來(lái)隔離系統(tǒng)的前端和系統(tǒng)中的后端組件，該數(shù)據(jù)訪問(wèn)服務(wù)層作為系統(tǒng)中的持久層門(mén)面為系統(tǒng)中的前端提供統(tǒng)

27、一的數(shù)據(jù)訪問(wèn)服務(wù)。由于數(shù)據(jù)訪問(wèn)服務(wù)層分離了兩個(gè)都可能會(huì)變化的部分，因此系統(tǒng)中的前端或者后端發(fā)生變化時(shí)，不會(huì)產(chǎn)生相互影響。請(qǐng)見(jiàn)下面圖3.10中所示的優(yōu)化設(shè)計(jì)的結(jié)果。圖3.10 松藕合的系統(tǒng)架構(gòu)設(shè)計(jì)的示例（優(yōu)化設(shè)計(jì)的結(jié)果）系統(tǒng)架構(gòu)設(shè)計(jì)師應(yīng)該要對(duì)系統(tǒng)功能中的擴(kuò)展部分有可預(yù)見(jiàn)性，在設(shè)計(jì)方面應(yīng)該預(yù)留好接口并隔離變化；在需求管理方面，不應(yīng)一味的聽(tīng)取客戶的想法，也要有自己的主張并且用實(shí)際的理論或是例子來(lái)說(shuō)服客戶向著自己的方向走，同時(shí)還要以商業(yè)合同規(guī)范客戶的合理要求。另外，一個(gè)好的架構(gòu)設(shè)計(jì)（接口設(shè)計(jì)）應(yīng)該是規(guī)定好輸入和輸出的要求。這樣的設(shè)計(jì)方案有助于代碼的替換和擴(kuò)展，而不需要改變?cè)创a。比如將具體的類的調(diào)用，

28、可以在配置文件中配置好，當(dāng)某方面的功能代碼需要發(fā)生變化時(shí)，就不需要再被動(dòng)地變化自身了。（2）第二方面的可能變化是程序結(jié)構(gòu)方面的變化采用抽象的原則，將系統(tǒng)中的公共屬性提取出來(lái)，然后再由子類來(lái)定義具有自己的特有的屬性；在代碼設(shè)計(jì)上，遵循“grasp設(shè)計(jì)原則”，同時(shí)合理的運(yùn)用“設(shè)計(jì)模式”。例如：運(yùn)用模板方法模式適應(yīng)縱向的變化；運(yùn)用橋接模式適應(yīng)橫向的變化；運(yùn)用裝飾器模式適應(yīng)核心與外圍的變化。下面的圖3.11為模板方法模式程序結(jié)構(gòu)的uml的類圖，當(dāng)系統(tǒng)的功能要求發(fā)生改變時(shí)，可以提供一個(gè)新的實(shí)現(xiàn)類來(lái)適應(yīng)該變化。圖3.11 體現(xiàn)模板方法模式程序結(jié)構(gòu)的uml的類圖（3）第三方面的可能變化是開(kāi)發(fā)組人員的變更人員

29、變更在項(xiàng)目開(kāi)發(fā)當(dāng)中是相當(dāng)普遍的，首先項(xiàng)目的管理者需要安排一個(gè)合理的計(jì)劃來(lái)安排每一個(gè)開(kāi)發(fā)人員的工作時(shí)間，充分估計(jì)系統(tǒng)的關(guān)鍵路徑，當(dāng)發(fā)生沖突時(shí)，也要提前準(zhǔn)備好解決辦法；對(duì)于新成員的加入或老成員的退出，開(kāi)發(fā)規(guī)范和代碼的可讀性是相當(dāng)必要的，盡量減少新人上手的時(shí)間。（4）第四方面的可能變化是技術(shù)實(shí)現(xiàn)和新技術(shù)的應(yīng)用所帶來(lái)的技術(shù)實(shí)現(xiàn)的變化針對(duì)領(lǐng)先技術(shù)，系統(tǒng)設(shè)計(jì)人員認(rèn)為如果功能上現(xiàn)行技術(shù)支持的話，就沒(méi)有必要去研究新技術(shù)，當(dāng)進(jìn)度時(shí)間不是很緊張的話，可以去考慮使用新技術(shù)，但也要充分考慮新技術(shù)可能有的潛在問(wèn)題和負(fù)面影響。7、軟件系統(tǒng)的設(shè)計(jì)人員怎樣才能夠使軟件系統(tǒng)具有較好的適應(yīng)性呢？軟件系統(tǒng)的成敗的關(guān)鍵在于對(duì)系統(tǒng)需求

30、的準(zhǔn)確地理解和充分的收集，而質(zhì)量則在于對(duì)系統(tǒng)的設(shè)計(jì)的優(yōu)劣，這包括對(duì)各個(gè)接口的設(shè)計(jì)、系統(tǒng)的交互性的設(shè)計(jì)、數(shù)據(jù)庫(kù)的表結(jié)構(gòu)的設(shè)計(jì)以及系統(tǒng)的性能設(shè)計(jì)等方面。（1）在系統(tǒng)主要的業(yè)務(wù)功能方面應(yīng)該預(yù)測(cè)到可能會(huì)有那些變化1) 首先，系統(tǒng)的開(kāi)發(fā)者在開(kāi)發(fā)系統(tǒng)時(shí)應(yīng)該站在行業(yè)的高度，從客戶的業(yè)務(wù)需求出發(fā)，預(yù)測(cè)行業(yè)未來(lái)的發(fā)展趨勢(shì)。也就是要求軟件系統(tǒng)應(yīng)能適應(yīng)目前的和未來(lái)可能發(fā)生的各種復(fù)雜情況，具有靈活的應(yīng)變能力和適應(yīng)性，并且要充分考慮到今后一段時(shí)間內(nèi)業(yè)務(wù)需求的變化。2) 其次，系統(tǒng)的開(kāi)發(fā)者要借助自己和他人的經(jīng)驗(yàn)對(duì)易發(fā)生變化的內(nèi)容進(jìn)行總結(jié)，探索規(guī)律，尋求解決之道；比如用戶在使用中可以隨時(shí)進(jìn)行改變，這可以用配置界面的形式提供

31、給用戶；或者另一種變化是系統(tǒng)部署和發(fā)布時(shí)才確定的，則通過(guò)配置文件的形式提供給系統(tǒng)部署人員。3) 要與客戶多溝通，并通過(guò)構(gòu)造出原型來(lái)進(jìn)一步準(zhǔn)確地獲取客戶的需求，定期請(qǐng)客戶參與需求評(píng)審會(huì)，將變化可能帶來(lái)的影響盡可能變小。（1） 在系統(tǒng)的架構(gòu)設(shè)計(jì)和模塊設(shè)計(jì)方面要有前瞻性l 在系統(tǒng)的架構(gòu)設(shè)計(jì)中盡可能地充分利用各種成熟的框架（商業(yè)或者開(kāi)源類型的）因?yàn)樵趹?yīng)用成熟的框架來(lái)進(jìn)行系統(tǒng)開(kāi)發(fā)時(shí)，系統(tǒng)的開(kāi)發(fā)者可以不需要考慮具體實(shí)現(xiàn)的細(xì)節(jié)。框架的靈活之處就在于它是一個(gè)大范圍的指導(dǎo)原則，就像j2ee框架那樣。在這種原則的指導(dǎo)下，系統(tǒng)的開(kāi)發(fā)者所開(kāi)發(fā)出的系統(tǒng)將會(huì)具有一定的通用性，這也是能夠使軟件系統(tǒng)具有更好的適應(yīng)性的一個(gè)常用

32、的手段。l 盡量達(dá)到模塊之間的“高內(nèi)聚、低耦合”的設(shè)計(jì)目標(biāo)應(yīng)用層體系架構(gòu)模式來(lái)構(gòu)造系統(tǒng)的總體架構(gòu)時(shí)，還應(yīng)該要在實(shí)現(xiàn)過(guò)程中，盡量做到模塊之間的“高內(nèi)聚、低耦合”、面向接口等下面的各個(gè)原則：對(duì)象的封裝原則、最小接口原則、最小職責(zé)原則、最小藕合原則和松散耦合的分層原則。（2） 在軟件開(kāi)發(fā)方法方面采用很好的軟件生命周期流程能夠很好的控制變化。比如現(xiàn)在的敏捷開(kāi)發(fā)方法，就是充分考慮到了需求不是一成不變的。在好的生命周期流程控制下，開(kāi)發(fā)出的軟件系統(tǒng)能夠具有較好的適應(yīng)變化性。（3） 在系統(tǒng)的各個(gè)模塊代碼實(shí)現(xiàn)中應(yīng)用各種設(shè)計(jì)模式來(lái)優(yōu)化實(shí)現(xiàn)代碼使用對(duì)象職責(zé)分配模式grasp以及gof設(shè)計(jì)模式來(lái)優(yōu)化實(shí)現(xiàn)代碼，這樣將能

33、夠使所開(kāi)發(fā)出的應(yīng)用系統(tǒng)在代碼實(shí)現(xiàn)方面也具有一定的適應(yīng)性和可擴(kuò)展性。1.1.3 軟件架構(gòu)設(shè)計(jì)時(shí)可能的設(shè)計(jì)誤區(qū)1、架構(gòu)師所可能步入的軟件架構(gòu)設(shè)計(jì)方面的誤區(qū)架構(gòu)師很容易走向極端，最常見(jiàn)的兩種極端情況是下面的兩種形式。不管是“完美主義”者的架構(gòu)師也好，還是低能的或不負(fù)責(zé)任的架構(gòu)師，其實(shí)都是作為一個(gè)系統(tǒng)的架構(gòu)師所不應(yīng)該出現(xiàn)的行為。（1）過(guò)分追求完美，從而步入軟件架構(gòu)設(shè)計(jì)和軟件工程理論方面的誤區(qū)。（2）做出來(lái)就行、能夠滿足用戶的一般的要求就夠了！而不考慮軟件的品質(zhì)和性能。2、“完美主義”者的架構(gòu)師作為一個(gè)系統(tǒng)架構(gòu)師，很多人具有完美主義的傾向。他們不斷地考慮系統(tǒng)的性能、可擴(kuò)展性、安全性，技術(shù)的先進(jìn)性等等。他

34、們最喜歡鼓吹本軟件系統(tǒng)如何達(dá)到松藕合、系統(tǒng)是如何實(shí)現(xiàn)具有通用性和擴(kuò)展性等等。當(dāng)然，為了能夠達(dá)到上述的各個(gè)設(shè)計(jì)目標(biāo)，肯定需要不斷地修改系統(tǒng)的架構(gòu)、不斷地更新系統(tǒng)中所使用的技術(shù)實(shí)現(xiàn)。這在作為實(shí)驗(yàn)性的、原理性的教學(xué)項(xiàng)目中，是沒(méi)有什么問(wèn)題的，而且也是值得鼓勵(lì)的！但如果在企業(yè)應(yīng)用系統(tǒng)中，也如此極端地實(shí)施，將會(huì)讓項(xiàng)目陷入不可控制的地步。主要的原因在于忽略了軟件開(kāi)發(fā)過(guò)程中的跌代性，因?yàn)檐浖到y(tǒng)總是在不斷地跌代、更新和不斷地完善中的，發(fā)展的方式應(yīng)該是螺旋式上升的。（1）新穎的技術(shù)不應(yīng)該成為軟件系統(tǒng)設(shè)計(jì)的目標(biāo)系統(tǒng)架構(gòu)師不應(yīng)該迷戀于對(duì)新穎的技術(shù)的應(yīng)用，或者認(rèn)為只要用了新的技術(shù)，就能夠開(kāi)發(fā)出最好的軟件產(chǎn)品，企業(yè)用戶

35、也一定會(huì)喜歡、一定會(huì)給企業(yè)帶來(lái)進(jìn)步，其實(shí)這是個(gè)誤區(qū)。因?yàn)槠髽I(yè)客戶在購(gòu)買軟件產(chǎn)品或者委托開(kāi)發(fā)出軟件項(xiàng)目時(shí)，并不是購(gòu)買它的技術(shù)本身，而更多的是關(guān)注于如何能夠給本企業(yè)創(chuàng)造和帶來(lái)價(jià)值。因此，應(yīng)該是軟件系統(tǒng)的市場(chǎng)決定了產(chǎn)品的設(shè)計(jì)，而不是技術(shù)決定軟件產(chǎn)品的設(shè)計(jì)，這一點(diǎn)千萬(wàn)不要本末倒置?。?）把軟件系統(tǒng)當(dāng)成自我能力體現(xiàn)的“工藝作品”系統(tǒng)架構(gòu)師不應(yīng)該將所設(shè)計(jì)和開(kāi)發(fā)的軟件系統(tǒng)當(dāng)成自我能力體現(xiàn)的“工藝作品”，用于表達(dá)自己的智慧，以及表達(dá)自己對(duì)于技術(shù)的理解和掌握的熟練程度的體現(xiàn)。保障客戶的投資和相應(yīng)地獲得一定的回報(bào)是所有的軟件工程師所應(yīng)該牢記的一個(gè)職業(yè)準(zhǔn)則。系統(tǒng)架構(gòu)師應(yīng)該對(duì)企業(yè)的需求、市場(chǎng)狀況以及已經(jīng)存在的系統(tǒng)作為

36、目標(biāo)模型來(lái)進(jìn)行調(diào)查和分析，搞清和理順客戶所在的企業(yè)對(duì)軟件產(chǎn)品的最終的要求到底是什么？產(chǎn)品的設(shè)計(jì)應(yīng)該來(lái)自于對(duì)企業(yè)需求的調(diào)研，而不是開(kāi)發(fā)者自己對(duì)新技術(shù)的激情和實(shí)驗(yàn)。（3）把軟件設(shè)計(jì)成“大而全”的通用性工具系統(tǒng)架構(gòu)師還應(yīng)該避免的另一種情形是把軟件系統(tǒng)設(shè)計(jì)成“大而全”的通用性工具軟件，幾乎能滿足用戶的各種應(yīng)用環(huán)境的需要！而忽略了實(shí)現(xiàn)這些功能時(shí)的技術(shù)上的可行性、成本的可控制性、開(kāi)發(fā)時(shí)間的有限性?！按蠖钡耐ㄓ眯怨ぞ哕浖拈_(kāi)發(fā)背后，一定是高投資和長(zhǎng)開(kāi)發(fā)周期！合理的思維應(yīng)該是在整個(gè)企業(yè)發(fā)展的戰(zhàn)略規(guī)劃下，從可行性研究出發(fā)，構(gòu)造一系列的基本上是相互獨(dú)立的并且滿足現(xiàn)有企業(yè)的規(guī)模和業(yè)務(wù)需要的子系統(tǒng)，這些子系統(tǒng)之間預(yù)先定義或者預(yù)留出一些穩(wěn)定的接口。根據(jù)企業(yè)運(yùn)營(yíng)的規(guī)模狀態(tài)而相應(yīng)地改變和調(diào)整各個(gè)子系統(tǒng)的投運(yùn)和繼續(xù)開(kāi)發(fā)，從而螺