從結(jié)構(gòu)化到面向?qū)ο蟪绦蛟O(shè)計的模型轉(zhuǎn)換

1、電腦應(yīng)用技術(shù)二零零六總第六十七期從結(jié)構(gòu)化到面向?qū)ο蟪绦蛟O(shè)計的模型轉(zhuǎn)換袁勝忠山東大學(xué)威海分?，F(xiàn)代教育技術(shù)部威海 264209摘要：隨著軟件系統(tǒng)內(nèi)在復(fù)雜性的不斷提高，面向?qū)ο蠹夹g(shù)已經(jīng)取代結(jié)構(gòu)化設(shè)計技術(shù)成 為產(chǎn)業(yè)化軟件開發(fā)的主流技術(shù)。本文剖析對象模型與結(jié)構(gòu)化設(shè)計瀑布模型隊程序設(shè)計風(fēng)格 的影響，探討導(dǎo)致面向?qū)ο筌浖こ淌〉闹饕?，論證了成功實施面向?qū)ο筌浖こ?的關(guān)鍵技術(shù)，幫助軟件工程師完成從結(jié)構(gòu)化設(shè)計實踐向面向?qū)ο蠓治龊驮O(shè)計實踐的進(jìn)化。 關(guān)鍵詞：對象模型瀑布模型迭代和增量式開發(fā)面向?qū)ο筌浖こ蘉odel Changing From Structured Design Style toObject

2、-Oriented ProgrammingY UAN She ngzho ngDepartme nt of Moder n Educati on Tech no logy of Shandong Uni versity at Weihai, Weihai,264209Abstract: In the past several years, with enhance of in here nt complex of various systems, the object-orie nted tech no logy have actually become the main stream of

3、in dustrial software developme nt. Compared with traditi onal structured desig n style and the waterfall model, i n this paper, we stre ngth the correct un dersta nd to object model and discuss the main reas ons for the failure of object-orie nted developme nt in order to promote the software engin

4、eers evoluti on from structured desig n to object-orie nted an alysis and desig n.Keywords:object model; waterfall model; iterative and in creme ntal developme nt;object-orie nted software engin eeri ng1引言面向?qū)ο蟮募夹g(shù)可以分為：面向?qū)ο蟮某绦蛟O(shè)計語言，面向?qū)ο蟮臄?shù)據(jù)庫技術(shù)，面向 對象的分析和設(shè)計方法。對應(yīng)用軟件開發(fā)組而言，面向?qū)ο蟮姆治龊驮O(shè)計方法是一種新的方法，它比面向?qū)ο?的程序設(shè)計語言和

5、面向?qū)ο蟮臄?shù)據(jù)庫技術(shù)更加難以掌握。因為它與開發(fā)組熟悉的結(jié)構(gòu)化設(shè) 計方法是兩種完全不同的設(shè)計風(fēng)格，在建立系統(tǒng)時，結(jié)構(gòu)化設(shè)計方法利用算法作為基本構(gòu) 件，而面向?qū)ο蠓椒ɡ妙惡蛯ο笞鳛榛緲?gòu)件。二者要求開發(fā)組用不同的思考方法對待 問題的分解，而且面向?qū)ο笤O(shè)計方法創(chuàng)造出來的軟件體系結(jié)構(gòu)大大超出了作者簡介：袁勝忠：男，1965年岀生，軟件工程師，主要研究方向為應(yīng)用軟件開發(fā)，網(wǎng)絡(luò)管理與優(yōu)化。1関09 ('hitia Acadcinic Journal Electronic Publishing llouw All rights reserved, litrp!,n電腦應(yīng)用技術(shù)二零零六總第六十七期結(jié)

6、構(gòu)化設(shè)計文化的領(lǐng)域。在應(yīng)用軟件開發(fā)中， 面向?qū)ο蠓椒ㄖ两駴]有得到應(yīng)有的使用。正如Rentsch曾經(jīng)準(zhǔn)確地預(yù)料到的，“我猜想面向?qū)ο蟮木幊虒⒊霈F(xiàn)在20世紀(jì)的80年代，就像結(jié)構(gòu)化編程出現(xiàn)在20世紀(jì)的70年代一樣。每一個人都會喜歡上它。每個制造商都會改進(jìn)自己的產(chǎn)品以支持 它。每個管理者都會在口頭上承諾它。每個編程人員都會（以不同方式）實踐它。但是沒 有一個人會知道它是什么”。遺憾的是，在我們的開發(fā)過程中，Ren tsch的預(yù)測至今仍然是正確的。現(xiàn)在多數(shù)程序員都僅在結(jié)構(gòu)化設(shè)計原則方面受過正規(guī)或非正規(guī)的訓(xùn)練，并利用這些結(jié) 構(gòu)化設(shè)計技術(shù)開發(fā)和實施了無數(shù)有用的軟件系統(tǒng)。他們即使認(rèn)識到只使用算法分解可以應(yīng) 對

7、的復(fù)雜性是有限的，必須轉(zhuǎn)向面向?qū)ο蟮姆纸?；他們即使想早日使用面向?qū)ο蟮募夹g(shù)， 反復(fù)學(xué)習(xí)了 C+或JAVA，但是，他們發(fā)現(xiàn)面向?qū)ο蠹夹g(shù)很難應(yīng)用，面對問題領(lǐng)域的時候， 設(shè)計一開始就不自覺地轉(zhuǎn)換到結(jié)構(gòu)化程序設(shè)計上了。這一切都是因為他們還沒有真正掌握 面向?qū)ο蟮姆治雠c設(shè)計方法，沒有深刻認(rèn)識面向?qū)ο蟮姆治龊驮O(shè)計方法與結(jié)構(gòu)化設(shè)計方法 的根本區(qū)別。沒有正確的方法指導(dǎo)，只學(xué)習(xí)面向?qū)ο蟮某绦蛟O(shè)計語言是遠(yuǎn)不足以成功實施 面向?qū)ο髴?yīng)用軟件開發(fā)的。如果把C+和JAVA這樣的語言作為傳統(tǒng)的面向算法的語言來使用，就不僅不能利用它們所賦予的功能，而且結(jié)果比使用更早的語言如C或PASCAL還差。如果給一個根本不懂電的木匠一把

8、電鉆，他有可能把電鉆當(dāng)成錘子來用并在砸彎無 數(shù)個釘子后認(rèn)為電鉆不如錘子好用。本文在第二部分分析如何全面理解面向?qū)ο蠓治龅哪Ｐ?，在分析的開始階段，模型提 供了一種組織大量信息的機(jī)制，這些信息起初使分析者無從下手。此外，模型的規(guī)范化和 系統(tǒng)化會暴露出系統(tǒng)種的不一致性和缺陷，從而指導(dǎo)后續(xù)的開發(fā)工作，所以，模型對于正 確掌握面向?qū)ο蟮姆椒ㄊ呛苤匾?。在第三部分，作者結(jié)合自己的實踐經(jīng)驗總結(jié)了導(dǎo)致面 向?qū)ο箝_發(fā)失敗的主要原因，用反證法論述了成功實施面向?qū)ο筌浖_發(fā)的關(guān)鍵概念和技 術(shù)，希望幫助那些熟悉結(jié)構(gòu)化設(shè)計方法的同行避開這些陷阱，順利進(jìn)化到面向?qū)ο蟮姆治?與設(shè)計開發(fā)。第四部分是結(jié)論，闡述了什么情況下應(yīng)該

9、采用面向?qū)ο蠹夹g(shù)。論述中經(jīng)常用到的概念有2:（1）面向?qū)ο蠓治?（object-oriented analysis，有時稱作 00A ）。OOA是一種分析方法， 它以可在問題域的詞匯表中找到的類和對象的觀點來審視需求，強(qiáng)調(diào)利用面向?qū)ο蟮挠^點建立真實世界的模型。（2）面向?qū)ο笤O(shè)計（object-oriented design，有時稱作 00D）。00D是一種設(shè)計方法， 它包含面向?qū)ο蠓纸獾倪^程，以及一種表示方法，用來描寫設(shè)計中的系統(tǒng)的邏輯模型與物理模型和靜態(tài)模型與動態(tài)模型。正是對面向?qū)ο蠓纸獾闹С质沟肙OD與結(jié)構(gòu)化設(shè)計大不一樣：OOD使用類和對象抽象在邏輯上構(gòu)建系統(tǒng)，而結(jié)構(gòu)化設(shè)計使用的卻是算法抽

10、象。上述兩個概念的關(guān)系是：OOA的結(jié)果可以作為OOD開始的模型，接著利用面向?qū)ο?編程實現(xiàn)。OOD的結(jié)果可以作為完整實現(xiàn)一個系統(tǒng)的藍(lán)圖。（3）面向?qū)ο蟮拈_發(fā)（object-oriented development ）。面向?qū)ο蟮拈_發(fā)是一個迭代和增量式的開發(fā)過程。其宏觀過程為2:建立核心需求（概念化）開發(fā)要求的行為的模式（分析）創(chuàng)立體系結(jié)構(gòu)（設(shè)計）演化實現(xiàn)（演化）管理后續(xù)的演化（維護(hù)）微觀過程為2:識別一個給定的抽象層次上的類和對象1H識別類和對象的語義識別類和對象之間的關(guān)系規(guī)定這些類和對象之間的接口，然后說明這些類和對象的實現(xiàn)。2深刻理解面向?qū)ο蠓治龅哪Ｐ兔嫦驅(qū)ο蟮姆治?，其目的在于有效地描述與

11、刻畫問題領(lǐng)域的信息和行為。實現(xiàn)這樣一 種描述，必須以一種全局的觀點來考慮系統(tǒng)中的各種聯(lián)系，系統(tǒng)的完整性和一致性。同時，這種描述能夠說明系統(tǒng)中各種操作的細(xì)節(jié)。為達(dá)到面向?qū)ο蠓治龅哪康?，面向?qū)ο蟮姆治鎏峁┝擞凶銐虮磉_(dá)力的模型：邏輯模型（類結(jié)構(gòu)、對象結(jié)構(gòu)）和物理模型（模塊體系結(jié)構(gòu)、進(jìn)程體系結(jié)構(gòu)）。對于一個給定的項目，分析和設(shè)計的結(jié)果都是通過這些模型表示出來。其中，類結(jié)構(gòu)的靜態(tài)語義用類圖表示、動態(tài)語義用狀態(tài)轉(zhuǎn)換圖表示；對象結(jié)構(gòu)的靜態(tài) 語義用對象圖表示、動態(tài)語義用交互圖表示；模塊體系結(jié)構(gòu)的靜態(tài)語義用模塊圖表示、動 態(tài)語義用子系統(tǒng)圖表示；進(jìn)程體系結(jié)構(gòu)用進(jìn)程圖表示。由此可見。面向?qū)ο箝_發(fā)的表示法包括四個基本

12、圖：類圖、對象圖、模塊圖和進(jìn)程圖，以及兩個補(bǔ)充圖：狀態(tài)轉(zhuǎn)換圖和交互圖。類圖用來顯示類和它們的關(guān)系在系統(tǒng)的邏輯設(shè)計中的存在。類圖代表系統(tǒng)的類結(jié)構(gòu) 視圖。對象圖用來顯示在系統(tǒng)的邏輯設(shè)計中存在的對象和它們的關(guān)系。對象圖通常用來表 示場景。模塊圖用來顯示在系統(tǒng)物理設(shè)計中分配給模塊的類和對象。模塊圖代表系統(tǒng)的模塊 體系結(jié)構(gòu)的視圖。進(jìn)程圖用來顯示在系統(tǒng)物理設(shè)計中分配給處理器的進(jìn)程。進(jìn)程圖代表系統(tǒng)的進(jìn)程體 系結(jié)構(gòu)的視圖。狀態(tài)轉(zhuǎn)換圖用來顯示給定類的實例的狀態(tài)空間，引起由一個狀態(tài)向另一個狀態(tài)轉(zhuǎn)換 的事件，以及由狀態(tài)變化引起的動作。交互圖用來跟蹤與對象圖同一個語境中的場景的執(zhí)行。在應(yīng)用軟件開發(fā)過程中，設(shè)計行為不是

13、一種畫圖的行為，圖只是被用來描繪一個設(shè)計。 面向?qū)ο蠓椒◤囊陨隙鄠€視圖來觀察設(shè)計是很重要的。在面向?qū)ο蟮姆治龇椒ㄖ?，建立?shù) 據(jù)流圖的作用，不如其它面向功能的方法明顯。因為數(shù)據(jù)流圖中并沒有添加任何新的信息 5，但是，建立動態(tài)模型可以使系統(tǒng)分析者對系統(tǒng)設(shè)計進(jìn)行精化，把相同或相似的處理操 作進(jìn)行調(diào)整，使系統(tǒng)結(jié)構(gòu)更加完善。注意，面向?qū)ο蟮南到y(tǒng)分析提供了一種獨特的方法，它反映了軟件問題的本質(zhì)所在。 軟件問題的本質(zhì)在于數(shù)據(jù)處理，數(shù)據(jù)和處理是兩件顯然的事情，是我們進(jìn)行軟件設(shè)計要做 的最基本的工作，在分析數(shù)據(jù)和信息的過程中分析其處理過程是我們本來應(yīng)該這樣做的。 將數(shù)據(jù)和處理人為地分離，可能會人為地制造系統(tǒng)分析

14、的障礙。面向?qū)ο蟮姆治鍪且环N以 數(shù)據(jù)或信息為主線，數(shù)據(jù)和處理緊密結(jié)合的方法，這種方法是以建立對象模型為基礎(chǔ)的。3導(dǎo)致面向?qū)ο箝_發(fā)失敗的主要原因3.1 原因之一 在面向?qū)ο箝_發(fā)過程之上疊加瀑布型思維如果您的開發(fā)過程基本遵循（1）企圖定義和穩(wěn)定絕大部分的需求，然后簽署開發(fā)協(xié) 議；（2）基于需求，進(jìn)行詳細(xì)設(shè)計；（3）基于設(shè)計進(jìn)行實現(xiàn)；（4）進(jìn)行集成、系統(tǒng)測試和部署。這是一個線性的、串行的瀑布型生命周期的典型例子，而且是一個最優(yōu)先的導(dǎo)致面3電腦應(yīng)用技術(shù)二零零六總第六十七期向?qū)ο箝_發(fā)完全失敗的策略。雖然我們接受了瀑布式模型教育，但是瀑布式開發(fā)模型沒有得到任何統(tǒng)計意義上的證據(jù)支持。更加重要的是，當(dāng)前的軟件

15、項目失敗研究結(jié)論性地表明，瀑布模型是風(fēng)險最高、極易失敗、低生產(chǎn)率以及高缺陷率的軟件構(gòu)建方法。盡管它與20世紀(jì)60年代開發(fā)軟件的隨心所欲方式相比是相對合理的策略，但幾代師生不假思索地學(xué)習(xí)和照搬它已經(jīng)導(dǎo)致了很 多軟件開發(fā)的失敗。有些東西必須像建筑那樣被建造，但是軟件通常不屬于這一類。瀑布 模型導(dǎo)致軟件失敗的最具有說服力的是一個錯誤的假定，即可以在項目的第一個階段中定 義絕大部分的需求。Capers Jon eS等人的研究粉碎了這一神話，蔓延的需求（在項目開始時沒有預(yù)見到）是軟件開發(fā)中非常顯著的事實，在普通項目中它大概占到 25%,在大型項目中則占到50%。瀑布模型竭力回避需求變化的現(xiàn)實，它假定需求

16、和設(shè)計能夠正確地被指明和凍結(jié)，這 與項目的現(xiàn)實嚴(yán)重不符。軟件開發(fā)在設(shè)計和實現(xiàn)之前無法固定需求有許多原因，但不管什 么原因，高明的應(yīng)對方法不是去 “對抗變化”，竭力固定需求，而正相反，應(yīng)該像Ken Beck 積極主張的那樣“擁抱變化”，并把這當(dāng)作軟件過程的一個核心驅(qū)動力。00A和00D使用迭代的、增量式的過程，并考慮它的不同階段的目的、產(chǎn)品、活動 和度量標(biāo)準(zhǔn)。開發(fā)的行進(jìn)表現(xiàn)為一系列的迭代，迭代過程不斷地對面向?qū)ο篌w系結(jié)構(gòu)進(jìn)行 細(xì)化，并將以往的經(jīng)驗以及每次發(fā)布的結(jié)果用于下一個迭代階段的分析和設(shè)計中。增量式 的開發(fā)過程要經(jīng)過一個分析、設(shè)計、演化的生命周期。以便不斷精化戰(zhàn)略決策和策略決策， 最后發(fā)展成

17、一個滿足用戶實際需求的（經(jīng)常是未加說明的）、并兼顧簡單性、可靠性和適應(yīng)性的系統(tǒng)。在一個迭代中，有一種類似微型瀑布的情況。首先挑選一小部分需求，相對全面地對 其進(jìn)行分析，用幾天的時間進(jìn)行設(shè)計，然后迅速地對系統(tǒng)的這一部分開始實現(xiàn)、集成和進(jìn) 行實際的系統(tǒng)測試與壓力測試。每次迭代的結(jié)束將產(chǎn)生一個可運行的部分系統(tǒng)，它能產(chǎn)生 反饋，并引發(fā)未來迭代中對需求和設(shè)計的調(diào)整。隨著時間流逝，這些反饋-適應(yīng)周期揭示 了一組合適的需求和一個健壯的、經(jīng)過驗證的設(shè)計與實現(xiàn)。這里，串行的瀑布方法在周的 實踐內(nèi)得到了應(yīng)用，當(dāng)?shù)L度增加到月或年，這種方式將不再有效。所以，面向?qū)ο箝_發(fā)的迭代和增量式的生命周期不同于瀑布型生命周期

18、，其過程既不 是嚴(yán)格的自頂向下，也不是嚴(yán)格的自底向上，正如Druke所指出的：通過使用“反復(fù)綜合設(shè)計”（round-trip gestalt design ）,可以最佳地構(gòu)造出結(jié)構(gòu)良好的復(fù)雜系統(tǒng)。一個面向?qū)ο?開發(fā)的項目團(tuán)隊面臨的最大挑戰(zhàn)就是有意或無意地在迭代和增量式開發(fā)之上疊加瀑布模 型。典型的錯誤有（1 ）在設(shè)計或?qū)崿F(xiàn)之前就確定絕大部分的需求；（2 ）項目剛開始就期望獲得可信的估算和詳細(xì)的計劃；（3 ）把迭代和增量式開發(fā)四個階段（起始、細(xì)化、構(gòu)建和移交）與瀑布模型四個階段（需求、分析設(shè)計、實現(xiàn)和部署）直接等同起來；（4）迭代不是太長就是太短。3.2 原因之二一一把面向?qū)ο箝_發(fā)當(dāng)作一個有許多

19、步驟需要遵循的規(guī)范過程來運作盡管我們希望面向?qū)ο蟮拈_發(fā)有規(guī)律可循，但是，“對象對于不同的人意味著不同的事物” 2，面向?qū)ο箝_發(fā)的實施過程充滿了創(chuàng)新性，它可以被足夠明確地定義，但不能像 食譜一樣被描述，誰也不能確保有適用于任何組織的成熟的、可重復(fù)的開發(fā)過程。GradyBooch提出要有一個管理良好的迭代和增量式的生命周期，“管理良好”意味著開發(fā)過程是可控和可測量的，但又不至于嚴(yán)格到影響發(fā)揮創(chuàng)造性和創(chuàng)新性的程度。即成功的面向?qū)ο?的項目是既不遵循失去控制的生命周期也不遵循極度嚴(yán)格的生命周期，相反，成功地構(gòu)造 出面向?qū)ο篌w系結(jié)構(gòu)的過程是迭代和增量式的，是一個經(jīng)濟(jì)且有彈性的過程。4在面向?qū)ο箝_發(fā)的核心

20、理念和最佳實踐中，迭代式開發(fā)的地位是最突出的。對于正從 瀑布式價值觀和實踐上開始轉(zhuǎn)變的開發(fā)者而言，迭代式開發(fā)就像一場革命，它靈活地支持 需求的變化并隨之作適應(yīng)性調(diào)整，不像瀑布模型那樣具有表面上明顯的穩(wěn)定性和確定性一 其實這是具有欺騙性的，只有通過測試，才能評估對事物真?zhèn)蔚念A(yù)先假定，只有通過實 現(xiàn)，才能知道完成一個任務(wù)到底需要多少工作量。因此，如果沒有在對待軟件思考的許多 層面上經(jīng)歷痛苦的變革，通常就把握不了迭代式開發(fā)并真正采用它。為了讓迭代式開發(fā)發(fā)揮作用，客戶必須參與其中。迭代式開發(fā)的精髓是根據(jù)反饋進(jìn)行 及時調(diào)整，而不是預(yù)先揣測?？蛻舻姆e極參與能幫助開發(fā)人員從理解需要解決的問題開始, 以一種演

21、進(jìn)的方式，將功能和易用性變得真實有效。大張旗鼓地或強(qiáng)制性地要求所有的項目切換到面向?qū)ο箝_發(fā)上來是無用的。好的經(jīng)驗 是，在一位有經(jīng)驗的教練指導(dǎo)下，通過一個小型的示范項目，嘗試采用一批少量的、簡單 的面向?qū)ο箝_發(fā)方法，讓項目組從實踐中學(xué)習(xí)，逐漸增加實施內(nèi)容，在完成第一個項目的 基礎(chǔ)上再啟動第二個項目。3.3 原因之三一一忽視對象技術(shù)技能面向?qū)ο蠹夹g(shù)項目失敗或遭到嚴(yán)重挫折的一個普遍原因是缺乏真正地能以對象方式 思考，熟練掌握對象設(shè)計、對象模式和面向?qū)ο缶幊痰娜藛T。擁有技藝精湛的面向?qū)ο箝_ 發(fā)人員是一個絕對優(yōu)先的關(guān)鍵成功因素，而采用迭代和增量式開發(fā)或其它過程則相對次 要。正如Kempf所說，“相比學(xué)習(xí)

22、另外一門編程語言，學(xué)習(xí)面向?qū)ο蟮木幊淌且豁椄щy 的任務(wù)。這可能是這樣一種情況，在相同框架中涉及到的不是一種新的編程而是一種關(guān)于 編程的新的思考方式”。要培養(yǎng)擁有出色對象技能的人員，并非指先有一個星期的JAVA技術(shù)課程，然后是一個星期的面向?qū)ο蠓治雠c設(shè)計課程，而是需要向軟件工程師提供半年內(nèi)大致八周的、有老 師精心指導(dǎo)的培訓(xùn)，之后還需要一年左右的專家輔導(dǎo)鞏固期。先在一些風(fēng)險低的小項目使 用面向?qū)ο蟮拈_發(fā)，允許開發(fā)組犯錯誤，然后讓這些開發(fā)組成員去開發(fā)其它的項目并擔(dān)當(dāng) 面向?qū)ο蠓椒ǚ矫娴膶?dǎo)師。將構(gòu)造良好的面向?qū)ο笙到y(tǒng)別的示例展示給開發(fā)人員和管理人 員也是發(fā)展面向?qū)ο笏枷雰A向的好方式之一。總之，對象技

23、術(shù)開發(fā)技能絕非一般，成功的 對象設(shè)計與編程需要受過良好訓(xùn)練的開發(fā)人員。如果回避那些真正懂得迭代式開發(fā)的顧 問、讓技能生疏的工程師勉強(qiáng)參加開發(fā)或不聘用或培養(yǎng)熟練的對象技術(shù)人才，就會確保項 目失敗。明確軟件開發(fā)歸根到底是一項人為活動是很重要的。面向?qū)ο箝_發(fā)的人員之間是不可以互換的，任何一個復(fù)雜系統(tǒng)的開發(fā)都需要一個作為核心的開發(fā)組的各位成員所具有的獨 特和各種各樣的技能。與傳統(tǒng)開發(fā)方式相比，面向?qū)ο箝_發(fā)過程需要對不同的技能有一個 很細(xì)致的劃分。Grady Booch認(rèn)為，在面向?qū)ο蟮捻椖拷M中主要有項目構(gòu)架師、子系統(tǒng)設(shè) 計領(lǐng)導(dǎo)、應(yīng)用工程師三類角色。項目構(gòu)架師是構(gòu)想家，負(fù)責(zé)演化和維護(hù)系統(tǒng)的體系結(jié)構(gòu)。對于

24、中小型系統(tǒng)來說，系統(tǒng) 體系結(jié)構(gòu)的設(shè)計通常由一個或兩個具有獨特洞察力的個人負(fù)責(zé)。但對于大型項目來說，系 統(tǒng)體系結(jié)構(gòu)的設(shè)計則由一個較大的項目組負(fù)責(zé)。項目構(gòu)架師并不需要是最高級的開發(fā)人 員，但他應(yīng)具有豐富的建造類似系統(tǒng)的經(jīng)驗，憑直覺就能判斷出哪種公用的體系結(jié)構(gòu)模式 與給定領(lǐng)域有關(guān)，以及什么樣的性能問題可能出現(xiàn)在特定的體系結(jié)構(gòu)變體中。項目構(gòu)架師 也不需要是最好的程序員，但他應(yīng)精通面向?qū)ο箝_發(fā)的表示法和過程，因為他必須根據(jù)類5電腦應(yīng)用技術(shù)二零零六總第六十七期的聚集和對象間的協(xié)作來展示他關(guān)于系統(tǒng)體系結(jié)構(gòu)的構(gòu)想。最好讓項目構(gòu)架師積極參與系 統(tǒng)分析過程，并隨后讓他繼續(xù)參與大部分的系統(tǒng)演化過程。這樣他會更加熟悉

25、系統(tǒng)的實際 需求，并且隨時間推移接受自己的決策結(jié)果。子系統(tǒng)設(shè)計領(lǐng)導(dǎo)的工作是對項目進(jìn)行最初的抽象。他主要負(fù)責(zé)設(shè)計一個完整的類類別或子系統(tǒng)。和項目構(gòu)架師一起，他必須設(shè)計、保護(hù)和商討一個類類別或子系統(tǒng)的接口，然 后指導(dǎo)它的實現(xiàn)。子系統(tǒng)設(shè)計領(lǐng)導(dǎo)必須精通面向?qū)ο箝_發(fā)的表示法和過程，通常，他是比 項目構(gòu)架師編程速度更快、水平更高的程序員，但是缺乏項目構(gòu)架師擁有的廣泛經(jīng)驗。平 均來說，子系統(tǒng)設(shè)計領(lǐng)導(dǎo)約占整個開發(fā)組的1/3到1/2。應(yīng)用工程師在項目中是次一級的開發(fā)人員，只完成一項或兩項職責(zé)。某些應(yīng)用工程師 負(fù)責(zé)在子系統(tǒng)設(shè)計領(lǐng)導(dǎo)的監(jiān)督下實現(xiàn)一個類類別或子系統(tǒng)，包括類的設(shè)計和實現(xiàn)、對開發(fā) 組內(nèi)其他設(shè)計人員所設(shè)計的

26、類和機(jī)制進(jìn)行單元測試。其他的應(yīng)用工程師負(fù)責(zé)使用這些類， 并組裝這些類來完成系統(tǒng)的功能點或小的程序。應(yīng)用工程師必須熟悉面向?qū)ο箝_發(fā)的表示 法和過程，是優(yōu)秀程序員，但不一定是這個領(lǐng)域內(nèi)的專家。平均來說，一個開發(fā)組中應(yīng)該 包含1/2或更多的應(yīng)用工程師。在更大型的項目中，還需要許多其它不同的角色來完成項目中的某些工作，如復(fù)用工 程師、質(zhì)量保證員、集成經(jīng)理、文檔編寫員等。但并非每個項目都需要所有的角色。在小 型項目中，同一個人可以承擔(dān)多種角色，在大型項目中，可能整個一個開發(fā)組織來承擔(dān)其 中的一個角色。4結(jié)論盡管有種種理由讓我們使用面向?qū)ο蟮姆椒ǎ谝淮谓⒚嫦驅(qū)ο蟮南到y(tǒng)時，系統(tǒng)成 本還是會比用結(jié)構(gòu)化方法建立的系統(tǒng)成本高得多。所以，目前的應(yīng)用項目采用面向?qū)ο蠹?術(shù)通常包括幾個實際的原因：第一，這些項目尋求競爭優(yōu)勢，例如，縮短產(chǎn)品上市時間、 增強(qiáng)產(chǎn)品靈活性、預(yù)計產(chǎn)品生產(chǎn)進(jìn)度。第二，這些項目可能具有一些非常復(fù)雜以至于似乎 沒有任何其它解決方案的問題。另外，如果要把