畢業(yè)設(shè)計(jì)文獻(xiàn)翻譯：無(wú)縫的面向?qū)ο筌浖軜?gòu)

文獻(xiàn)翻譯二級(jí)學(xué)院計(jì)算機(jī)科學(xué)與工程學(xué)院班級(jí)學(xué)生姓名學(xué)號(hào)譯文要求1、譯文內(nèi)容必須與課題（或?qū)I(yè)）內(nèi)容相關(guān)，并需注明詳細(xì)出處。2、外文翻譯譯文不少于2000字；外文參考資料閱讀量至少3篇（相當(dāng)于10萬(wàn)外文字符以上）。3、譯文原文（或復(fù)印件）應(yīng)附在譯文后備查。譯文評(píng)閱導(dǎo)師評(píng)語(yǔ)（應(yīng)根據(jù)學(xué)?！白g文要求”，對(duì)學(xué)生外文翻譯的準(zhǔn)確性、翻譯數(shù)量以及譯文的文字表述情況等作具體的評(píng)價(jià)）指導(dǎo)教師：年月日無(wú)縫的面向?qū)ο筌浖軜?gòu)摘要：在這篇論文中主要分析無(wú)縫的面向?qū)ο筌浖軜?gòu)。闡述軟件在分析、設(shè)計(jì)以及開(kāi)發(fā)過(guò)程中面向?qū)ο笤O(shè)計(jì)思想如何使概念到實(shí)現(xiàn)的平穩(wěn)過(guò)渡，避免軟件系統(tǒng)與需求目標(biāo)的偏離。關(guān)鍵詞：面向?qū)ο罂芍赜眯詿o(wú)縫性1面向?qū)ο筌浖l(fā)展1.1介紹什么是面向?qū)ο蠓独臐撃埽课覀兺ㄟ^(guò)合理地使用這種在發(fā)明25年后終于征服軟件產(chǎn)業(yè)的技術(shù)能夠多大限度的改進(jìn)軟件開(kāi)發(fā)過(guò)程？弗雷德·布魯克斯，在他的著名文章“沒(méi)有銀彈：軟件工程的本質(zhì)性與附屬性工作”[布魯克斯1987]中，把創(chuàng)造軟件的困難劃分為本質(zhì)性與附屬性。一款軟件的本質(zhì)是一系列互相關(guān)聯(lián)的概念的構(gòu)件：數(shù)據(jù)集合，數(shù)據(jù)項(xiàng)之間的關(guān)系，算法和函數(shù)調(diào)用。軟件的的總體結(jié)構(gòu)——其邏輯結(jié)構(gòu)的一部分獨(dú)立于任何特別的機(jī)器表征，但是還不足夠詳細(xì)的足以明確轉(zhuǎn)換為可執(zhí)行代碼。它的附屬性則相反，所有復(fù)雜的細(xì)節(jié)需要用于表示在給定的計(jì)算環(huán)境的附屬性。布魯克斯認(rèn)為，相對(duì)于表示軟件和測(cè)試它的保真度的模型（附屬部分），創(chuàng)造軟件的最重要的部分是說(shuō)明書(shū)，設(shè)計(jì)和本質(zhì)概念構(gòu)想的測(cè)試。如果這是真的，他推斷，構(gòu)造軟件將會(huì)一直困難。不管語(yǔ)言和工具如何的給力，都會(huì)使我們遠(yuǎn)離我們想要表達(dá)的真正的問(wèn)題。乍一看，布魯克斯的結(jié)論似乎認(rèn)為面向?qū)ο蟮某橄缶哂刑岣哕浖a(chǎn)效率的潛力這一顯著因素是無(wú)效的。而事實(shí)上，如果面向?qū)ο蠹夹g(shù)主要講授和用于從頭開(kāi)始構(gòu)建新的系統(tǒng)，像那些現(xiàn)代工業(yè)常見(jiàn)的案例一樣，也許只有邊際生產(chǎn)率的提高可以期待。但是，在另一方面，它強(qiáng)調(diào)的是從單個(gè)系統(tǒng)轉(zhuǎn)移到可分割的軟件組件的生產(chǎn)和使用，使深刻的變化成為可能?？芍赜梅椒ǖ暮锰巸蓚€(gè)值得樂(lè)觀的理由。首先，通過(guò)排除工業(yè)軟件工程大多數(shù)意外的困難可以使軟件費(fèi)用降低一個(gè)數(shù)量級(jí)——或許不是一個(gè)單獨(dú)的系統(tǒng)版本，但肯定覆蓋整個(gè)產(chǎn)品生命周期。方法和實(shí)現(xiàn)語(yǔ)言是不夠的，但是，要達(dá)到降低費(fèi)用的目標(biāo)，無(wú)論多么強(qiáng)大的概念和高度自動(dòng)化。我們還需要訪問(wèn)那些在現(xiàn)代工業(yè)軟件項(xiàng)目中被一遍又一遍改造的底層封裝基礎(chǔ)概念的大量可重用構(gòu)件基礎(chǔ)。其次，可重用抽象并不僅限于隱藏意外的困難，也可以用來(lái)攻擊軟件設(shè)計(jì)的本質(zhì)。涉及解決問(wèn)題的復(fù)雜性不僅取決于問(wèn)題本身，同樣受到推理問(wèn)題的原始有效觀念影響。所以如果我們能夠提高表達(dá)能力和原始事物的可理解性在不同的問(wèn)題領(lǐng)域，那么類(lèi)似抽象設(shè)計(jì)的復(fù)雜性就可以減小。作為附帶影響，投資于重用還可以帶來(lái)另外一個(gè)重要的好處。軟件構(gòu)件在多重環(huán)境下被用到或重用多次意味著軟件質(zhì)量有連續(xù)提高的機(jī)會(huì)，這在經(jīng)濟(jì)上比只在一個(gè)項(xiàng)目中使用可行性更高。這可以使新的抽象逐步發(fā)展直到它們成為概念上強(qiáng)大到足以使它們成為系統(tǒng)的一部分開(kāi)發(fā)人員的標(biāo)準(zhǔn)詞匯。這也許，反過(guò)來(lái)促進(jìn)新的有用的，但是由于初步努力尚未達(dá)到要求的更高水平的抽象被發(fā)現(xiàn)。起初的困難目前已投資超過(guò)過(guò)去二十年來(lái)的顯著努力用于建立和使用工業(yè)系統(tǒng)開(kāi)發(fā)的軟件組件庫(kù)。盡管某些應(yīng)用領(lǐng)域已經(jīng)看到了一些成功，在一般案例中實(shí)現(xiàn)高度重用程度被在練習(xí)中被證明困難比預(yù)期中的更難。大多數(shù)的失敗被歸咎于組織的缺點(diǎn)，例如缺少明確責(zé)任的角色（重用管理者），沒(méi)有一致的管理策略，缺少自動(dòng)化工具的支持，以及與短期項(xiàng)目預(yù)算沖突等。其它的問(wèn)題是自然的商業(yè)，例如如何保護(hù)可重用設(shè)計(jì)足以使與投資人的投資是匹配的。這些問(wèn)題之所以存在，是因?yàn)槲覜](méi)轉(zhuǎn)換技術(shù)，必須要先解決問(wèn)題。但這一切的關(guān)鍵是面向?qū)ο蟮某橄蟆ㄒ坏淖阋詨蛴糜跇?gòu)建所需的通用組件的技術(shù)。由于重用主要依賴(lài)于傳統(tǒng)的技術(shù)，也就不必為它的失敗而感到奇怪了。就像我們?nèi)鄙倩镜姆椒ㄉa(chǎn)正確的部件，正式組織和自動(dòng)瀏覽工具難以提供幫助。另一方面，面向?qū)ο蟛](méi)有自動(dòng)解決所有問(wèn)題，許多面向?qū)ο蟮捻?xiàng)目同樣報(bào)告難以實(shí)現(xiàn)重用目標(biāo)的困難。然而，這并不能作為大規(guī)模重用在實(shí)踐中無(wú)法實(shí)現(xiàn)的跡象，或者說(shuō)面向?qū)ο鬅o(wú)效。相反，有很多原因可以解釋這些初步的困難只是沒(méi)有預(yù)料到而已。首先，大多數(shù)或者說(shuō)全部的工業(yè)化的面向?qū)ο蟮捻?xiàng)目仍然在使用混合的語(yǔ)言或者混合的方法。致使部分自相矛盾的概念產(chǎn)生混亂并延遲充分利用新方法必需的心理轉(zhuǎn)變?；旌险Z(yǔ)言落后的兼容性需求同樣使完全支持面向?qū)ο蟮暮诵母拍钭兊貌豢赡?，進(jìn)而使建設(shè)高質(zhì)量的組件庫(kù)變得困難。其次，即使技術(shù)手段是一個(gè)先決條件且必須是第一位的，組織方面也同樣重要。許多項(xiàng)目失敗是因?yàn)闇?zhǔn)備不充分的培訓(xùn)，缺少管理支撐或者重用協(xié)調(diào)。這些同樣是必須解決的問(wèn)題，尤其是對(duì)于大型機(jī)構(gòu)。最后，商用類(lèi)庫(kù)的大小和質(zhì)量是一個(gè)重要變量，甚至最好的面向?qū)ο蟮沫h(huán)境也只是一個(gè)目標(biāo)的一小部分影響因素。因?yàn)榱己玫某橄笮枰蕾?lài)多種已經(jīng)被嘗試過(guò)的方法逐步開(kāi)發(fā)，在我們可以期待一些東西可以接近最常見(jiàn)的改造軟件組件的完整封裝之前，它自然會(huì)耗費(fèi)一些時(shí)間。 知識(shí)的重用之路如果我們把當(dāng)前的面向?qū)ο笳Z(yǔ)言趨勢(shì)與1970年代到1980年代初向高級(jí)語(yǔ)言過(guò)渡比較，這種情形盡管有很多相似之處，也是相當(dāng)不同的。像Pascal和C這類(lèi)控制結(jié)構(gòu)體現(xiàn)抽象的組裝的語(yǔ)言，程序員總是通過(guò)智力解決（經(jīng)常發(fā)生在一些偽陵符號(hào)注釋?zhuān)?，因?大回報(bào)是立竿見(jiàn)影。當(dāng)由構(gòu)造序列組成的機(jī)器指令的冗長(zhǎng)的且易出錯(cuò)的翻譯不再需要時(shí)，工作可以繼續(xù)像以前一樣，只是更快。在一些重要的領(lǐng)域，當(dāng)從今天被認(rèn)為是傳統(tǒng)語(yǔ)言的（如Pascal或C）轉(zhuǎn)向一個(gè)更好的面向?qū)ο蟓h(huán)境同樣如此。使用現(xiàn)成的組件的能力代表了幾乎所有的基本數(shù)據(jù)結(jié)構(gòu)和基本算法（列表，哈希表，隊(duì)列，棧），而不需要知道任何關(guān)于它們的實(shí)現(xiàn)，是一個(gè)直接并聯(lián)。另一個(gè)領(lǐng)域是圖形接口。但是面向?qū)ο蟮某橄笠詾橹?，因?yàn)樗鼛缀蹩梢栽谌魏我粋€(gè)領(lǐng)域被用來(lái)創(chuàng)建新概念。這意味著它最大的潛能（從長(zhǎng)遠(yuǎn)來(lái)看）不在于代表我們已經(jīng)熟悉的概念，而是作為發(fā)明新的概念的媒介。這是面向?qū)ο笞鳛橐粋€(gè)技術(shù)投資而非短期收益的一個(gè)主要原因（盡管并不排除后者）。真正的大回報(bào)將取決于重用在特定領(lǐng)域的水平。它有可能捕獲在整個(gè)應(yīng)用程序類(lèi)型即所謂的框架,而且從一個(gè)環(huán)境到另一個(gè)環(huán)境只需修改小部分即可。成功的框架在開(kāi)始的時(shí)候很難構(gòu)思。相當(dāng)于它們逐漸適應(yīng)進(jìn)化的一群解決一個(gè)特定問(wèn)題也能解決其它問(wèn)題的組件，類(lèi)似的在實(shí)踐中出現(xiàn)的問(wèn)題。因此產(chǎn)生的結(jié)構(gòu)的有效性證明被經(jīng)驗(yàn)證明，保證低成本/收益比率。所以如果事情進(jìn)展緩慢我們不能絕望——畢竟，我們是伸手摘星。未來(lái)的潛力是巨大的，盡管廣泛的培訓(xùn)和組織支持是必要的且不是免費(fèi)的，在我們的投資開(kāi)始獲得匯報(bào)之前我們不需要走很遠(yuǎn)的重用之路。在本書(shū)中，我們將介紹來(lái)自確實(shí)至關(guān)重要的廣泛的軟件重用為基礎(chǔ)的面向?qū)ο蟮姆治龊驮O(shè)計(jì)，而且只要我們利用面向?qū)ο蟾拍畹姆绞皆趯?shí)踐中實(shí)現(xiàn)是符合這以目標(biāo)的。這一觀點(diǎn)強(qiáng)調(diào)我們認(rèn)為沒(méi)有充分解決的面向?qū)ο蠹夹g(shù)的某些方面。那么，什么是有能力使軟件重用變成標(biāo)準(zhǔn)的做法并且最終給出軟件工程面向?qū)ο笮g(shù)語(yǔ)的面向?qū)ο蟊举|(zhì)的意義？除了類(lèi)的概念提供的極致的靈活性——讓我們可以通過(guò)繼承建立可組合且可量身定做的開(kāi)放組件——已經(jīng)在序言中提到的面向?qū)ο蟮娜齻€(gè)重要方面，無(wú)縫性、可逆性和和軟件外包，比迄今為止已有的關(guān)于分析和設(shè)計(jì)文獻(xiàn)更值得關(guān)注。我們來(lái)依次看一下。 1.2無(wú)縫性面向?qū)ο蠓椒ㄊ瞧駷橹挂阎奈ㄒ痪哂袧摿Φ姆椒ǎ梢允狗治?、設(shè)計(jì)，以及通用的軟件系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)轉(zhuǎn)變?yōu)檎嬲臒o(wú)縫過(guò)程。從用戶(hù)需求到分析與設(shè)計(jì)，到運(yùn)行系統(tǒng)平穩(wěn)過(guò)渡，軟件工程的目標(biāo)需要20多年，但是傳統(tǒng)的方法在實(shí)踐中已經(jīng)失?。m然經(jīng)常聲稱(chēng)已經(jīng)解決）。這不是令人驚訝的，因?yàn)楦拍詈头?hào)設(shè)計(jì)師的方法被迫從Scylla和Charybdis選擇。要么你提供一個(gè)傳統(tǒng)編程語(yǔ)言的翻譯，那些改變符號(hào)就能成為另外一種的語(yǔ)言（通常引起的復(fù)雜性比它解決的問(wèn)題更多），或者你發(fā)明一個(gè)完全不同的高級(jí)符號(hào)并保持規(guī)范和代碼之間的差異。同樣的抽象機(jī)制（類(lèi)）可以用于所有的發(fā)展階段使面向?qū)ο笕绱说奈??；靖拍钚枰韧獠扛拍钅Ｐ蛯?duì)象代表醫(yī)院,飛機(jī),和廣泛的區(qū)域網(wǎng)絡(luò)并不是本質(zhì)上有什么不同，所需對(duì)象代表四精度浮點(diǎn)數(shù),街道地址或進(jìn)程調(diào)度程序。抽象封裝的類(lèi)的語(yǔ)義解釋會(huì)有所不同，但是一般的問(wèn)題仍然是相同的：指定類(lèi)的一致性，與其他類(lèi)的關(guān)系，通過(guò)適用操作的行為。通過(guò)生產(chǎn)、維修工作系統(tǒng)嫩鞏固保持相同的模式從最初的可行性研究帶來(lái)巨大的優(yōu)勢(shì)。當(dāng)基本概念對(duì)于每個(gè)人都相同時(shí)，與每一個(gè)不同角色的項(xiàng)目成員溝通是一個(gè)很大的提高。教育促進(jìn)人造說(shuō)明符與實(shí)現(xiàn)者之間的障礙消失，為系統(tǒng)生命周期的整體視圖創(chuàng)造空間。無(wú)縫性也促進(jìn)了需求跟蹤。由于類(lèi)從分析階段被引入直到最終的系統(tǒng)還會(huì)呈現(xiàn)，通過(guò)設(shè)計(jì)和實(shí)現(xiàn)跟蹤需求擴(kuò)展變得很容易。 1.3可逆性真正的無(wú)縫性不僅僅意味著容易從規(guī)范的轉(zhuǎn)變實(shí)現(xiàn)。太多的面向?qū)ο蠓椒ㄒ蕾?lài)于不言而喻的只用于早期開(kāi)發(fā)階段分析和設(shè)計(jì)符號(hào)的設(shè)想，然后翻譯成面向?qū)ο缶幊痰某绦蚧虿弧５谀承r(shí)候（其實(shí)很快）初始系統(tǒng)將被修改以滿(mǎn)足新的要求。理想地，這意味著首先改變最高的描述，然后向下相繼地傳遞變化直到代碼實(shí)現(xiàn)。然而，這不是在實(shí)踐中大多數(shù)系統(tǒng)的工作方式。因?yàn)楦呒?jí)規(guī)范只能代表系統(tǒng)的一個(gè)粗略的草圖,在規(guī)格可以執(zhí)行之前必須忽略很多細(xì)節(jié)和問(wèn)題在這一點(diǎn)上。這意味著一個(gè)全新的根據(jù)實(shí)現(xiàn)語(yǔ)言概念的抽象世界將被創(chuàng)造，主要的興趣和創(chuàng)造性工作將逐步轉(zhuǎn)移到現(xiàn)在的環(huán)境。連續(xù)的改進(jìn)和修正將會(huì)被直接應(yīng)用與程序代碼，因?yàn)橹挥形覀冇凶銐虻谋磉_(dá)能力能夠解決不可能解決的隱晦的、詳細(xì)的決定性規(guī)范。而且有些細(xì)節(jié)總是被證明對(duì)系統(tǒng)結(jié)構(gòu)具有重大影響。（如果程序代碼可以從規(guī)范代碼自動(dòng)生成，后者將簡(jiǎn)單的成為我們新的編程語(yǔ)言而且我們一點(diǎn)也不需要討論的低水平。）然而，如果抽象系統(tǒng)描述是為了在第一次翻譯成程序代碼時(shí)的價(jià)值，修改代碼則必須定期的反射回給規(guī)格。在這里，所有的傳統(tǒng)方法被摧毀。如果概念原語(yǔ)被規(guī)格和實(shí)現(xiàn)語(yǔ)言所分別使用，不能被直接映射到彼此（總是用非面向?qū)ο筇幚淼那闆r），這將導(dǎo)致規(guī)范和實(shí)現(xiàn)之間的分歧。隨著系統(tǒng)的發(fā)展保持兩個(gè)世界始終一致將會(huì)變得非常昂貴，因?yàn)檫@意味著或多或少的在不兼容的概念結(jié)構(gòu)之間重復(fù)簡(jiǎn)單的翻譯。事實(shí)上，即使你努力使所有的規(guī)范保持最新，也沒(méi)有辦法知道它們真的是最新的（由于概念上的不匹配），所以通常人們不會(huì)信任它們。畢竟，只有可執(zhí)行的規(guī)范，即程序代碼，通過(guò)實(shí)行系統(tǒng)操作與硬件交流。它是決定飛機(jī)是否安全起飛或降落的完整程序代碼，而不是吸引分析師或設(shè)計(jì)師的藍(lán)圖。一個(gè)正確的系統(tǒng)可以沒(méi)有故障的運(yùn)行，即使它的規(guī)范是錯(cuò)的，而不是相反。因此，當(dāng)我們?cè)趯?shí)踐中要選擇支持的描述，選擇很簡(jiǎn)單。規(guī)范的價(jià)值直接關(guān)系到它們可以直接通過(guò)規(guī)范翻譯成程序代碼或被程序代碼直接翻譯為規(guī)范。那些聲稱(chēng)只有非常高層次的需求和分析模型要緊，沒(méi)有給出任何如何映射到可執(zhí)行代碼或從可執(zhí)行代碼反射的做法的提示，看起來(lái)似乎并不了解現(xiàn)在的軟件意味著管理數(shù)十億美元的投資。面向?qū)ο蟾拍畹母呒?jí)建模技術(shù)被奮力征服程序設(shè)計(jì)的復(fù)雜性的人們發(fā)現(xiàn)似乎并不是一個(gè)巧合。不像其他的方法，面向?qū)ο蟊举|(zhì)上是可你的。由于分析和設(shè)計(jì)類(lèi)可以作為最終系統(tǒng)的一部分，任何影響這些類(lèi)的結(jié)構(gòu)和接口的實(shí)現(xiàn)更改變得立即可見(jiàn)，但是前提是我們避免包括其他領(lǐng)域的元素，如我們的方法的標(biāo)準(zhǔn)部分：如實(shí)體關(guān)系圖、狀態(tài)轉(zhuǎn)換圖、或者數(shù)據(jù)流程圖?；旌戏妒酱蚱屏丝赡嫘?，并且引入了新的復(fù)雜性，這在大多數(shù)情況下將大于預(yù)期效益。這并不意味著這些技術(shù)能用于面向?qū)ο笙到y(tǒng)。一些應(yīng)用程序可能會(huì)受益于特殊場(chǎng)合的實(shí)體-關(guān)系圖，并且通過(guò)狀態(tài)轉(zhuǎn)換圖建造某些抽象將會(huì)極其的強(qiáng)大，但是它們基于一般方法則會(huì)丟失重點(diǎn)。相反，我們應(yīng)該利用面向?qū)ο蟮奶厥馄焚|(zhì)：它的簡(jiǎn)單易行，連貫性，以及極其普遍性。它在沒(méi)有強(qiáng)制改變?nèi)魏翁厥獾牟榭捶绞降那闆r下提供了對(duì)各級(jí)抽象的支持。這使這種途徑在開(kāi)發(fā)方法中變得獨(dú)特，且它的基本概念被證明足夠的支持我們需要的大多數(shù)軟件的規(guī)范和實(shí)現(xiàn)，幾乎可以忽略軟件的應(yīng)用領(lǐng)域。 1.4軟件外包軟件重用需要額外的高質(zhì)量，因?yàn)槠錆撃芴岣呱a(chǎn)效率也比以前造成傷害的風(fēng)險(xiǎn)更大。從頭編寫(xiě)大多數(shù)用傳統(tǒng)風(fēng)格編寫(xiě)的軟件至少在限制錯(cuò)誤在特定系統(tǒng)發(fā)展的影響的具有優(yōu)勢(shì)。然而，如果一個(gè)不適當(dāng)?shù)能浖?gòu)件應(yīng)用于成千上萬(wàn)的應(yīng)用程序，積累損傷實(shí)際上是非常高的。在一定程度上這會(huì)讓重用軟件片段受到廣泛測(cè)試沉重反擊，但是測(cè)試只能揭示一小部分潛在的錯(cuò)誤，只要使用模式在變化，以前隱藏的問(wèn)題可能會(huì)被發(fā)現(xiàn)。面向?qū)ο蠓椒ǖ恼麄€(gè)想法是通過(guò)在抽象層不斷地建立更強(qiáng)大的組件設(shè)計(jì)軟件從而反映出在各種應(yīng)用領(lǐng)域的高級(jí)概念，每個(gè)都建立在之前的基礎(chǔ)上。我們知道沒(méi)有更好的方式來(lái)掌握錯(cuò)綜復(fù)雜的事物，但這同樣意味著產(chǎn)生的結(jié)構(gòu)變得完全依賴(lài)于組成部分的正確機(jī)能。如果一些核心抽象失敗了，整個(gè)建筑就有可能分崩離析。因此想辦法保證軟件的正確性也更加重要。幸運(yùn)地，近年來(lái)提出來(lái)了一個(gè)非常有前途的方法，將元素從抽象數(shù)據(jù)類(lèi)型和正式規(guī)范的研究領(lǐng)引入到軟件工程的標(biāo)準(zhǔn)用法。這是軟件外包的理論【Meyer1992c】。這個(gè)想法是用聲明定義每個(gè)類(lèi)的語(yǔ)義。先決條件和每個(gè)操作的結(jié)果行為是通過(guò)預(yù)處理和后置條件規(guī)定，且全部類(lèi)一致通過(guò)類(lèi)的不變式。然后，這些語(yǔ)義規(guī)范在沒(méi)個(gè)類(lèi)之間形成一個(gè)合約基礎(chǔ)，供給方和所有的類(lèi)使用它的業(yè)務(wù)操作和客戶(hù)端。一個(gè)軟件被視為一個(gè)客戶(hù)和供應(yīng)商合作的網(wǎng)絡(luò)，而軟件的請(qǐng)求和服務(wù)通過(guò)分散的合同精確定義。根據(jù)合同，一致的錯(cuò)誤處理機(jī)制是可能的。如果聲明在運(yùn)行時(shí)被監(jiān)控，違反合同則會(huì)導(dǎo)致異常。分散的處理程序可以被定義和實(shí)現(xiàn)為一般的異常管理工具處理錯(cuò)誤恢復(fù)。軟件外包代表程序生產(chǎn)中具有重大意義的一步，應(yīng)該被包括在任何面向?qū)ο蟮姆治龊驮O(shè)計(jì)方法中，旨在建立可靠的、高質(zhì)量的專(zhuān)業(yè)化產(chǎn)品。2BON方法2.1介紹本書(shū)描述的方法叫做BON，代表“業(yè)務(wù)對(duì)象表示法（BusinessObjectNotation”。它提供了一組面向?qū)ο筌浖５母拍?，兩個(gè)版本的支持表示法——一個(gè)圖形一個(gè)文本——一套可以用于生產(chǎn)模型的規(guī)則和指引。BON專(zhuān)注于分析和設(shè)計(jì)的基本要素，該方法是集成和適應(yīng)可以應(yīng)用與不同的組織的各種開(kāi)發(fā)框架和標(biāo)準(zhǔn)。BON支持核心沒(méi)有特殊應(yīng)用程序類(lèi)型的整體軟件開(kāi)發(fā)，特別是對(duì)質(zhì)量和可靠性要求很高的產(chǎn)品。概念和符號(hào)的設(shè)計(jì)提倡在前一章中提出的可重用性方法：無(wú)縫性，可逆性，軟件外包。與發(fā)現(xiàn)在許多面向?qū)ο蟮年嚑I(yíng)中大規(guī)模重用的可達(dá)性有些消極態(tài)度相反，我們認(rèn)為這確實(shí)是該技術(shù)的首要目標(biāo)。BON不引入任何根本性的新概念；面向?qū)ο蟮幕舅枷虢Y(jié)合軟件規(guī)范元素作為原語(yǔ)是足夠的。它是一個(gè)可以造成質(zhì)的區(qū)別的通過(guò)一個(gè)擴(kuò)展標(biāo)記的詳細(xì)定義和概念表達(dá)排列。（到一定程度時(shí)，BON由被不包含它的表示方法定義，因?yàn)闊o(wú)縫和簡(jiǎn)單是指導(dǎo)明星。）讀者當(dāng)然會(huì)懷疑在很多表示法已經(jīng)出版的情況下而不引入新的表示法是否會(huì)導(dǎo)致目標(biāo)不能實(shí)現(xiàn)。我們不能只是適應(yīng)一個(gè)更廣泛使用的現(xiàn)有的表示法來(lái)實(shí)現(xiàn)我們的目標(biāo)嗎？遺憾的是不能。盡管在許多已經(jīng)被提出的方法中使用的概念似乎是或多或少相同（類(lèi)，操作，關(guān)系），依然有表面下的細(xì)微差異以防它們一對(duì)一映射。由于表示法只是一種用綜合的可讀的形式表達(dá)基本概念的方式，重用在這種情形下不能工作。面向?qū)ο蟮姆治龊驮O(shè)計(jì)領(lǐng)域還很年輕、不成熟，許多競(jìng)爭(zhēng)的方法和相應(yīng)的表示法自然地會(huì)在它該出現(xiàn)的時(shí)間不斷涌現(xiàn)。也許這會(huì)對(duì)一些潛在的用戶(hù)制造混亂，但這真的是他們的最佳收益。規(guī)范化太早是極其有害的，因?yàn)樗s小了建模的角度，擋住了真正理解的方式。（我們很高興地看到，這一觀點(diǎn)被眾多在該領(lǐng)域知名的專(zhuān)家共享，通過(guò)最近的一封公開(kāi)信“過(guò)早的標(biāo)準(zhǔn)化方法是有害的”[Mellor1993]） 2.2什么是BON沒(méi)有的許多現(xiàn)有的分析和設(shè)計(jì)的方法，也許大多數(shù)，不是使用一些實(shí)體-關(guān)系方法(實(shí)體關(guān)系建模[Chen1976])或有限狀態(tài)機(jī)（FSM建模）的變種的數(shù)據(jù)建模，就是全部，作為高級(jí)系統(tǒng)描述的一個(gè)重要部分。我們的想法是把這些技術(shù)的優(yōu)點(diǎn)與面向?qū)ο蟾拍罱Y(jié)合起來(lái)，從而從連個(gè)方面受益。然而，這種方法嚴(yán)重阻礙了在前面章節(jié)提到的無(wú)縫和可逆性主張。我們認(rèn)為，這個(gè)缺點(diǎn)遠(yuǎn)遠(yuǎn)超過(guò)因此帶來(lái)的好處。使用FSM建模，由于在狀態(tài)轉(zhuǎn)換圖和最終實(shí)現(xiàn)之間沒(méi)有簡(jiǎn)單的映射，阻抗不匹配是顯而易見(jiàn)的。（除非我們把沒(méi)個(gè)對(duì)象都建模為一個(gè)狀態(tài)機(jī)，從而放棄所有類(lèi)概念的抽象力量）。使用ER建模，情況則比較復(fù)雜一點(diǎn)。 為什么不用ER建模？分析ER建模的支持者聲稱(chēng)二元關(guān)系比類(lèi)的相互引用更加通用，因?yàn)樵谇懊嫣岬降暮笠环N明確的設(shè)計(jì)選擇仍然保持開(kāi)放。這當(dāng)然是真實(shí)的，因?yàn)榭梢酝ㄟ^(guò)多種方式表示兩個(gè)類(lèi)之間的特定關(guān)系。然而，通過(guò)限制所有的類(lèi)依賴(lài)于二元關(guān)系使選擇保持開(kāi)放通常并不是最好的一種方案。事實(shí)上，為了得到一個(gè)好的系統(tǒng)模型我們反而不能保持一切開(kāi)放，因?yàn)檫@將嚴(yán)重地影響我們理解問(wèn)題。所以問(wèn)題不是是否應(yīng)該做出設(shè)計(jì)決策，而是選擇哪一個(gè)。ER建模當(dāng)然也不例外。相反，就像許多武斷的或有疑問(wèn)的決定必須被做出以達(dá)成ER建模，正如一個(gè)純粹的面向?qū)ο竽Ｐ?。在后一種情況下，我們必須選擇概念模型作為類(lèi)和哪些應(yīng)該成為這些類(lèi)的操作。用ER建模，我們必須選擇描繪實(shí)體的概念，以及哪些會(huì)成為實(shí)體的屬性，哪些會(huì)成為它們之間的關(guān)系。這對(duì)改變來(lái)說(shuō)并不意味著比選擇更容易或者影響更小。例如，一個(gè)ER模型中的屬性被視為實(shí)體中的“性質(zhì)”，并由一個(gè)值表示。但一個(gè)屬性是什么？考慮實(shí)體員工和一個(gè)服務(wù)部門(mén)最受歡迎的人的概念。顯然，最受歡迎的是一種人的性質(zhì)，但是從系統(tǒng)的觀點(diǎn)來(lái)看把這當(dāng)做一個(gè)員工的屬性建模可能是相當(dāng)錯(cuò)誤的。員工抽象可能不知道它的條件，知識(shí)表示自身的唯一方式可能相反是其它實(shí)體屬性的組合，也許是統(tǒng)計(jì)數(shù)字和客戶(hù)投票。所以我們?cè)谶@里有一個(gè)問(wèn)題：任何一個(gè)屬性都被認(rèn)為是和儲(chǔ)存在實(shí)體中的數(shù)值是直接對(duì)應(yīng)的，在這種情況下太低級(jí)，或者這只是一個(gè)不明確的“性質(zhì)”，這又太高級(jí)，因?yàn)樗鼪](méi)有告訴我們關(guān)于系統(tǒng)足夠多的信息。面向?qū)ο蟮闹虚g道路是一個(gè)類(lèi)操作返回一個(gè)值，而值可能是任何類(lèi)型的。這避免了過(guò)早的確定不同的值的存儲(chǔ)方式，并且告知了足夠多的系統(tǒng)行為允許無(wú)縫過(guò)渡到實(shí)現(xiàn)。另外一個(gè)麻煩的地方是為實(shí)體的屬性和關(guān)系選擇什么級(jí)別的“標(biāo)準(zhǔn)化”。實(shí)體A與B之間的二元關(guān)系通常不會(huì)對(duì)A與B之間的聯(lián)系作任何說(shuō)明（除了通過(guò)語(yǔ)義標(biāo)簽，例如“適用于”和它的相對(duì)角色“使用”）。按此推理，傳遞規(guī)律也必須適用：如果B通過(guò)關(guān)系“有下級(jí)單位”反過(guò)來(lái)與C關(guān)聯(lián)，那么A也能通過(guò)“適用于上級(jí)單位”與C關(guān)聯(lián)，C通過(guò)“是上級(jí)單位的下級(jí)單位”與A關(guān)聯(lián)（圖2.1）。由于ER模型通常是連接圖，可以查找每一個(gè)實(shí)體與其它實(shí)體之間的二元關(guān)系遞歸地調(diào)用規(guī)律產(chǎn)生圖。因此，只有被認(rèn)為是最重要的關(guān)系被包含在圖中，其余的則被隱藏。有些作者建議分離獨(dú)立的屬性和關(guān)系的正交基，并且標(biāo)記所有其它顯示的正交基。然而，哪些作為正交基被選擇遠(yuǎn)不夠明顯，也不清楚“衍生”意味著什么。例如，考慮圖2.2所示的實(shí)體，我們可以選擇母親-兒子和母親-女兒兩個(gè)關(guān)系作為正交基。兒子-女兒之間的關(guān)系兄弟-姐妹就變成了衍生，因?yàn)閷?duì)于任何一對(duì)兒子和女兒我們可以推斷出他們是否是兄弟姐妹。但是我們可以選擇其他兩個(gè)作為正交基（假設(shè)兄弟-姐妹意味著所有的兄弟姐妹，共有雙方的父母）。此外，可導(dǎo)出的屬性通常是全局的。從兒子的視角，母親和姐姐的角色可能同樣重要，且事實(shí)上一個(gè)屬性從另一個(gè)屬性中導(dǎo)出并不應(yīng)該總是被強(qiáng)調(diào)。相反，可能晚些時(shí)候一個(gè)系統(tǒng)中母親的角色也能被繼母實(shí)體所實(shí)現(xiàn)，那么，可導(dǎo)出性將不再持有。出于同樣的原因，衍生屬性和基礎(chǔ)屬性的區(qū)別并不總是明顯。確定可導(dǎo)出性必須經(jīng)常做出關(guān)于底層信息內(nèi)容的比預(yù)期要早的假設(shè)。這些問(wèn)題會(huì)在純粹的面向?qū)ο蠓椒ㄇ跋В驗(yàn)槲覀儗?zhuān)注于系統(tǒng)行為而不是什么信息需要被存儲(chǔ)。因?yàn)檫@種行為是實(shí)現(xiàn)系統(tǒng)功能的需要，更多的重在應(yīng)對(duì)未來(lái)變化的結(jié)果。底線是如果我們?cè)诜治龊驮O(shè)計(jì)級(jí)別加入ER建模我們將放棄面向?qū)ο蠓椒ü逃械臒o(wú)縫性，但是我們卻得不到多少回報(bào)。在實(shí)踐中，真正的系統(tǒng)通常有幾百個(gè)潛在的實(shí)體和它們之間的關(guān)系。因此產(chǎn)生的完整的ER圖變得巨大，其本質(zhì)上是一個(gè)平面結(jié)構(gòu)。為實(shí)現(xiàn)一些目的，大型圖通常被分解較小的重疊的部分，其中每個(gè)部分包含一些實(shí)體集與一個(gè)相互關(guān)系的子集。這可能使任意的關(guān)聯(lián)遺漏。這種技術(shù)類(lèi)似于過(guò)去的分割項(xiàng)目流程圖，只是留下很多引用其他圖的箭頭，邊界關(guān)系只是簡(jiǎn)單的限制。然而，這并不改變固有的平面結(jié)構(gòu)，也不是對(duì)理解大型系統(tǒng)如此重要的“縮放”功能，我們堅(jiān)持“平移”的形式。強(qiáng)調(diào)作為一個(gè)建模概念的關(guān)聯(lián)與對(duì)象行為分離有利于整體系統(tǒng)觀察。它打破封裝和集中在短期細(xì)節(jié)上比局部概念更多，這可能有潛力時(shí)之存活更長(zhǎng)時(shí)間。ER建模作為分析和設(shè)計(jì)方法的部分不會(huì)幫助我們找到可能在其它情況下使用的代表有趣概念的類(lèi)，除了解決當(dāng)前的一部分問(wèn)題。面向?qū)ο箝_(kāi)發(fā)的無(wú)縫性和可逆性因此不能完全利用，因而不利用重用。而且，我們不需要這種類(lèi)型的獨(dú)立的聯(lián)合，因?yàn)槊嫦驅(qū)ο笤Z(yǔ)可以直接用來(lái)建模任何我們想要的概念。由于這些原因，BON被設(shè)計(jì)為遵循不同的軌道。與其試圖包含傳統(tǒng)數(shù)據(jù)建模概念或或所謂的結(jié)構(gòu)化技術(shù)帶著所有附帶的缺點(diǎn)，更富有成果的是尋求：面向?qū)ο蟮撵`活性和透明度、強(qiáng)類(lèi)型的表現(xiàn)能力，以及類(lèi)之間的正式契約的結(jié)合。1Object-orientedsoftwaredevelopment1.1INTRODUCTIONWhatisthepotentialoftheobject-orientedparadigm?Howmuchimprovementofthesoftwaredevelopmentprocesscanwereasonablyexpectfromusingthistechnology,which25yearsafteritsinitialinventionfinallyseemstobeconqueringthesoftwareindustry?FredBrooks,inhiswell-knownarticle“NoSilverBullet:EssenceandAccidentsinSoftwareEngineering”[Brooks1987],dividesthedifficultiesofbuildingsoftwareintoessenceandaccidents.Theessenceofapieceofsoftwareisaconstructofinterlockingconcepts:datasets,relationshipsamongdataitems,algorithms,andfunctioninvocations.Thisconstructisthegeneralarchitectureofthesoftware—thatpartofitslogicalstructurewhichisindependentofanyparticularmachinerepresentation,butstilldetailedenoughtoallowunambiguoustranslationtoexecutablecode.Theaccidents,bycontrast,areeverythingelse—allthegorydetailsandcontortionsnecessaryforrepresentingtheessenceinagivencomputingenvironment.Brooksbelievesthehardpartofbuildingsoftwareisthespecification,design,andtestingoftheessentialconceptualconstructs,asopposedtorepresentingthemandtestingthefidelityoftherepresentations(theaccidentalpart).Ifthisistrue,heconcludes,buildingsoftwarewillalwaysbehard.Languagesandtoolsnomatterhowpowerful,canonlytakeusthatfarwhentherealproblemistodecidewhatexactlywewanttoexpress.Atfirstsight,Brook’sconclusionmayseemtoinvalidateallclaimsthatobject-orientedabstractionhasthepotentialtoincreasesoftwareproductivitybyasignificantfactor.Infact,ifobject-orientedtechniquesaremainlytaughtandusedtobuildnewsystemsfromscratch,asoftenseemstobethecaseinindustrytoday,onlymarginalproductivityimprovementscanprobablybeexpected.Ifontheotherhand,theemphasisisshiftedfromindividualsystemstotheproductionanduseoftailorablesoftwarecomponents,aprofoundchangebecomespossible.BenefitsofareusabilityapproachTherearetworeasonsforoptimism.First,thecostofsoftwarecanstillbereducedbyanorderofmagnitudebyremovingmostoftheaccidentaldifficultiesfromindustrialsoftwareengineering—maybenotforasinglesystemversion,butsurelyoveraproduct’slifecycle.Methodsandimplementationlanguagesarenotenough,however,toachievethiscostreduction,nomatterhowconceptuallypowerfulandhighlyautomated.Wealsoneedaccesstoalargebaseofreusablecomponentswhichencapsulatethebasicconceptsthatarebeingreinventedoverandoverintoday’sindustrialsoftwareprojects.Second,reusableabstractionsarenotlimitedtohidingaccidentaldifficulties,butcanalsobeusedtoattacktheessenceofsoftwaredesign.Thecomplexityinvolvedinsolvingaproblemdependsnotonlyontheproblem,butjustasmuchontheprimitiveconceptsavailableforreasoningabouttheproblem.Soifwecanincreasetheexpressivepowerandunderstandabilityoftheseprimitivesinvariousproblemareas,thecomplexityofcorrespondingabstractdesignscanalsobereduced.Asasideeffect,investinginreusebringsanothercrucialadvantage.Softwarecomponentsthatareusedandreusedmanytimesinmanydifferentcontextsstandthechanceofacquiringmuchhigherqualitythroughsuccessiveimprovementthanisevereconomicallyfeasibleforcomponentsthatarejustusedwithinasingleproject.Thisenablesnewabstractionstograduallyevolveuntiltheybecomeconceptuallystrongenoughtobecomepartofthesystemdeveloper’sstandardvocabulary.Thismay,inturn,leadtothediscoveryofnewusefulabstractionsatyethigherlevelsthatwouldotherwisenothavebeenfoundowingtotheinitialeffortrequired.InitialdifficultiesTherehasbeensignificanteffortinvestedoverthepasttwodecadestobuildanduserepositoriesofsoftwarecomponentsforindustrialsystemsdevelopment.Althoughcertainapplicationareashaveseensomesuccesses,achievingahighdegreeofreuseinthegeneralcasehasturnedouttobemuchmoredifficultinpracticethanfirstexpected.Muchofthefailurehasbeenattributedtoorganizationalshortcomings,suchaslackofclearresponsibilityroles(reusemanagers),noconsistentmanagementpolicy,lackofautomatedtoolssupport,andconflictswithshort-termprojectbudgets.Otherproblemsarecommercialinnature,suchashowtoprotectreusabledesignsenoughtomaketheeffortinvestedworthwhilefortheoriginators.Theseproblemsdonotgoawayjustbecauseweswitchtechnology,andmuststillbesolved.Butthekeytoitallisobject-orientedabstraction—theonlytechniqueflexibleenoughforbuildingthegeneralcomponentsneeded.Sincereuseeffortshavemainlyreliedontraditionaltechniques,itisnosurprisethattheyhavelargelyfailed.Aslongaswelackthebasicmeanstoproducetherightcomponents,formalorganizationandautomatedbrowsingtoolscandolittletohelp.Ontheotherhand,object-orientationdoesnotautomaticallysolveallproblems,andmanyobject-orientedprojectshavealsoreporteddifficultiesattainingtheirreusegoals.This,however,mustnotbetakenasasignthatlarge-scalereuseisunattainableinpractice,orthattheobject-orientedapproachdoesnotwork.Onthecontrary,thereareanumberofreasonswhytheseinitialdifficultiesareonlytobeexpected.First,mostindustrialobject-orientedprojectsarestillusinghybridlanguagesorhybridmethods,orboth.Theresultingmixofpartlycontradictoryconceptscreatesconfusionanddelaysthementalshiftnecessarytotakefulladvantageofthenewapproach.Therequirementofbackwardcompatibilityforhybridlanguagesalsomakesitimpossibletosupportcleanlyallofthecentralobject-orientedconcepts,whichinturnmakestheconstructionofhigh-qualitycomponentlibrariesdifficult.Second,evenifthetechnicalmeansareaprerequisiteandmustcomefirst,theorganizationalaspectsarealsocrucial.Manyprojectshavefailedbecauseofinadequatetraining,lackofmanagementsupportorreusecoordination.Theseareproblemsthatmustbeaddressedinparallel,particularlyforlargeorganizations.Third,thesizeandqualityofcommerciallyavailableclasslibrariesishighlyvariable,andeventhebestobject-orientedenvironmentsonlycoverasmallpartofwhatonewouldwishfor.Sincegoodabstractionsneedtobedevelopedincrementallywithmanyalternativeapproachestried,itwillnaturallytakesometimebeforewecanexpectanythingclosetoacompleteencapsulationofthemostcommonlyreinventedsoftwarecomponents.TheroadtoreuseofknowledgeIfwecomparethecurrenttrendtowardsobject-orientedlanguageswiththetransitiontohigh-levellanguagesinthe1970sandearly1980s,thesituation,althoughithasmanysimilarities,isalsoquitedifferent.ThecontrolstructuresoflanguageslikePascalandCembodyabstractionsthattheassemblyprogrammerswerealreadyusingmentally(oftenoccurringascommentsinsomepseudo-Algolnotation),sothebigpayoffswereimmediate.Whenthetediousanderror-pronetranslationsoftheseconstructsintosequencesofmachineinstructionswerenolongerneeded,workcouldproceedasbefore,onlymuchfaster.Insomeimportantareas,thesameistruewhenmovingfromwhatcanbeconsideredatraditionallanguagetoday(suchasPascalorCabove)toagoodobject-orientedenvironment.Theabilitytouseoff-the-shelfcomponentsrepresentingthebasicdatastructuressofundamentalforalmostanycomputingalgorithm(lists,hashtables,queues,stacks),withouttheneedtoknowanythingabouttheirimplementation,isadirectparallel.Anothersuchareaisgraphicalinterfaces.Butobject-orientedabstractionmeansmuchmore,sinceitcanalsobeusedtocreatenewconceptsinalmosteveryconceivablearea.Thismeansitsgreatestpotential(inthelongrun)liesnotinrepresentingtheconceptswithwhichwearealreadyfamiliar,butratherinservingasavehicleforinventingnewones.Thisisthemainreasonwhyobject-orientedtechnologyisatechnologyofinvestmentmorethanofshort-termprofit(evenifthelatterisbynomeansprecluded).Thereallybigpayoffswillcomefromreuseatmoredomain-specificlevels.Itispossibletocapturewholeapplicationtypesinso-calledframeworks,andonlytailorthesmallportionsthatneedtobedifferentfromonesituationtoanother.Successfulframeworksarehardlyeverconceivedassuchfromthebeginning.Rathertheyevolvebygradualadaptationofagroupofcomponentssolvingaparticularproblemintoalsosolvingother,similarproblemsthatoccurinpractice.Theusefulnessoftheresultingstructuresisthusempiricallyproven,whichguaranteeslowcost/benefitratios.Sowemustnotdespairifthingsappeartogoslowly—afterall,wearereachingforthestars.Thefuturepotentialisenormous,andeventhoughextensivetrainingandorganizationalsupportisnecessaryandnotfree,weneednotgoveryfardowntheroadtoreusebeforeourinvestmentstartstoshowreturns.Andfromthere,thingswillonlygetbetter.Inthisbook,wewillpresentaviewofobject-orientedanalysisanddesignderivedfromthebasicpremisethatextensivesoftwarereuseisindeedessential,andthatitcanbeattainedinpracticeprovidedwetakeadvantageoftheobject-orientedconceptsinawaythatiscompatiblewiththisgoal.Thisviewemphasizescertainaspectsofobject-orientedtechnologywhichwethinkhavenotbeensufficientlyaddressed.Whatexactly,then,aretheobject-orientedqualitiesthathavethecapacitytoturnsoftwarereuseintostandardpracticeandfinallygivethetermsoftwareengineeringitsintendedmeaning?Inadditiontotheextremeflexibilityprovidedbytheclassconcept—allowingustobuildopencomponentsthatcanbecombinedandtailoredthroughinheritance—threecrucialaspectsofobject-orientationalreadymentionedinthepreface,seamlessness,reversibility,andsoftwarecontracting,deservemuchmoreattentionthantheyhavehadsofarintheliteratureonanalysisanddesign.Wewilltakealookattheminorder.1.2SEAMLESSNESSTheobject-orientedapproachistheonlymethodknowntodatethathasthepotentialtoturnanalysis,design,andimplementationofgeneralsoftwaresystemsintoatrulyseamlessprocess.Asmoothtransitionfromuserrequirementsoveranalysisanddesignintorunningsystemshasbeenthegoalofsoftwareengineeringforover20years,buttraditionalmethods(althoughoftenclaimingtohavethesolution)havegenerallyfailedinpractice.Thisisnotsurprising,sincethedesignersofconceptsandnotationsforsuchmethodsareforcedtochoosebetweenScyllaandCharybdis.Eitheryouprovideaneasytranslationtosometraditionalprogramminglanguage,whichforcesthenotationtobecomejustanotherprocedurallanguage(oftenintroducingmorecomplexitythanitsolves),oryouinventacompletelydifferenthigh-levelnotationandkeepthebarrierbetweenspecificationandcode.Whatmakesobject-orientationsoattractiveisthatthesameabstractionmechanism(theclass)canbeusedinalldevelopmentphases.Thebasicconceptsneededtomodelobjectsrepresentingsuchexternalnotionsashospitals,airplanes,andwideareanetworksarenotessentiallydifferentfromwhatisneededforobjectsrepresentingquadrupleprecisionfloatingpointnumbers,streetaddresses,orprocessdispatchers.Thesemanticinterpretationoftheabstractionsencapsulatedbytheclassesmayvary,butthegeneralproblemremainsthesame:tospecifyclassconsistency,relationswithotherclasses,andbehaviorthroughapplicableoperations.Beingabletokeepthesameparadigmfrominitialfeasibilitystudyallthewaythroughproductionandmaintenanceofaworkingsystembringsenormousadvantages.Communicationbetweenprojectmemberswithdifferentrolesisgreatlyimprovedwhenthebasicconceptsarethesameforeverybody.Educationisfacilitatedandtheartificialbarriersbetweenspecifiersandimplementorsvanish,makingroomforaholisticviewofthesystemlifecycle.Seamlessnessalsofacilitatesrequirementstraceability.Sincetheclassesintroducedintheanalysisphasewillstillbepresentinthefinalsystem,tracingthepropagationofinitialrequirementsthroughdesignandimplementationbecomesmucheasier.1.3REVERSIBILITYTrueseamlessnessmeansmorethanjusteasytransitionfromspecificationtoimplementation.Fartoomanyobject-orientedmethodsrelyontheunspokenassumptionthattheanalysisanddesignnotationwillonlybeusedintheearlydevelopmentphases,andthentranslatedonceintoprogramcode—objectorientedornot.Butatsomepoint(infact,verysoon)theinitialsystemwillbemodifiedtomeetnewrequirements.Ideally,thiswouldmeanchangingfirstthetopmostdescriptions,andthensuccessivelypropagatingallchangesdownwardsuntilthecodeisreached.However,thisisnotthewayitworksinpracticeformostsystems.Sincehigh-levelspecificationcanonlyrepresentacrudesketchofasystem,lotsofdetailsandproblemsignoredatthatpointwillhavetobetakencareofbeforethespecificationscanbemadeexecutable.Thismeansthatawholenewworldofabstractionsintermsofimplementationlanguageconceptswillbecreated,andthemaininterestandcreativeeffortwillgraduallyshifttothisenvironment.Successiverefinementsandcorrectionswilltendtobeapplieddirectlytotheprogramcode,sinceonlytheredowehaveenoughexpressivepowertoresolveallobscuritiesanddetaileddecisionsthatcouldnotbeaddressedbythespecifications.Andsomeofthesedetailswillnearlyalwaysturnouttohaveasignificantimpactonthesystemstructure.(Iftheprogramcodecouldbeautomaticallygeneratedfromthespecifications,thelatterwouldsimplybecomeournewprogramminglanguageandwewouldnotneedtotalkAboutthelowerlevelsatall.)However,ifabstractsystemdescriptionistokeepitsvaluebeyondthefirsttranslationintoprogramcode,changestothecodemustbereflectedbackintothespecificationsatregularintervals.Hereiswherealltraditionalmethodsbreakdown.Iftheconceptualprimitivesusedbythespecificationandimplementationlanguages,respectively,cannotbedirectlymappedtoeachother(whichisalwaysthecaseinnon-object-orientedapproaches)thiswillleadtoacreepingdivergencebetweenspecificationandimplementation.Itsimplybecomestooexpensivetokeepthetwoworldsconsistentasthesystemevolves,sincethiswouldmeanrepeatednon-trivialtranslationsbetweenmoreorlessincompatibleconceptualstructures.Infact,evenifyoutryhardtokeepallspecificationsuptodate,thereisnowayofknowingiftheyreallyare(becauseoftheconceptualmismatch)sopeoplewillusuallynottrustthemanyway.Afterall,onlytheexecutablespecifications,thatistheprogramcode,evergettotalktothehardwarewhichcarriesoutthesystemactions.Itisthecompleteprogramcodethatdecideswhethertheairplanewilltakeoffandlandsafely,nottheblueprintsdrawnbytheanalyst/designer.Acorrectsystemcanrunwithoutproblemsevenifitsspecificationiswrong,butnotthereverse.Therefore,whenweneedtochooseinpracticewhichdescriptiontofavor,thechoiceiseasy.Thevalueofthespecificationsisthereforedirectlyrelatedtotheeasebywhichtheycanbeseamlesslytranslatedtoandfromprogramcode.Thoseclaimingthatonlytheveryhigh-levelrequirementsandanalysismodelsmatter,withoutgivinganyhintastohowthemappingtoandfromtheexecutablecodecanbedone,donotseemtohavefullyunderstoodwhatitmeanstomanagethemulti-billiondollarinvestmentrepresentedbytoday’ssoftware.Itisprobablynotacoincidencethatthehigh-levelmodelingconceptsofobject-orientedtechnologywerediscoveredbypeoplewhowerestrugglingtomasterthecomplexityofprogramming.Unlikeanyotherapproach,theobject-orientedmethodisinherentlyreversible.Sincetheclassesofanalysisanddesigncanbemadepartofthefinalsystem,anychangestotheimplementationaffectingthestructureandinterfaceoftheseclassesthenbecomeimmediatelyvisible,butonlyifwerefrainfromincludingelementsfromotherfields,suchasentity?relationshipdiagrams,statetransitiondiagrams,ordataflowdiagramsasstandardpartsofourapproach.Mixingparadigmsbreaksthereversibilityandintroducesnewcomplexity,whichwillinmostcasesoutweightheexpectedbenefits.Thisdoesnotmeanthatsuchtechniquescanneverbeusedinobject-orientedsystems.Someapplicationsmaybenefitfromanoccasionalentity?relationshipdiagram,andmodelingcertainabstractionsusingstatetransitiondiagramscanbeextremelypowerful,butbasingageneralmethodonthemmissesthepoint.Instead,weshouldtakeadvantageofthespecialqualitiesofobject-orientation:itssimplicity,coherence,andextremegenerality.Itprovidesthesamesupportforabstractionatalllevelswithoutforcingthemtobeviewedinanyparticularway.Thismakestheapproachuniqueamongdevelopmentmethods,anditsbasicconceptshaveprovedsufficienttospecifyandimplementmostofthesoftwareweneed,almostregardlessofapplicationarea.1.4SOFTWARECONTRACTINGSoftwaredesignedforreuseneedstobeofextrahighquality,sinceitspotentialtoincreaseproductivityalsobringstheriskofcausingmuchmoreharmthanbefore.Writingmostofthesoftwarefromscratchintraditionalstyleatleasthastheadvantageoflimitingtheeffectsofmistakestotheparticularsystembeingdeveloped.However,ifaninadequatesoftwarecomponentis