畢業(yè)設計文獻翻譯：無縫的面向?qū)ο筌浖軜?gòu)

文獻翻譯二級學院計算機科學與工程學院班級學生姓名學號譯文要求1、譯文內(nèi)容必須與課題（或?qū)I(yè)）內(nèi)容相關(guān)，并需注明詳細出處。2、外文翻譯譯文不少于2000字；外文參考資料閱讀量至少3篇（相當于10萬外文字符以上）。3、譯文原文（或復印件）應附在譯文后備查。譯文評閱導師評語（應根據(jù)學?！白g文要求”，對學生外文翻譯的準確性、翻譯數(shù)量以及譯文的文字表述情況等作具體的評價）指導教師：年月日無縫的面向?qū)ο筌浖軜?gòu)摘要：在這篇論文中主要分析無縫的面向?qū)ο筌浖軜?gòu)。闡述軟件在分析、設計以及開發(fā)過程中面向?qū)ο笤O計思想如何使概念到實現(xiàn)的平穩(wěn)過渡，避免軟件系統(tǒng)與需求目標的偏離。關(guān)鍵詞：面向?qū)ο罂芍赜眯詿o縫性1面向?qū)ο筌浖l(fā)展1.1介紹什么是面向?qū)ο蠓独臐撃?？我們通過合理地使用這種在發(fā)明25年后終于征服軟件產(chǎn)業(yè)的技術(shù)能夠多大限度的改進軟件開發(fā)過程？弗雷德·布魯克斯，在他的著名文章“沒有銀彈：軟件工程的本質(zhì)性與附屬性工作”[布魯克斯1987]中，把創(chuàng)造軟件的困難劃分為本質(zhì)性與附屬性。一款軟件的本質(zhì)是一系列互相關(guān)聯(lián)的概念的構(gòu)件：數(shù)據(jù)集合，數(shù)據(jù)項之間的關(guān)系，算法和函數(shù)調(diào)用。軟件的的總體結(jié)構(gòu)——其邏輯結(jié)構(gòu)的一部分獨立于任何特別的機器表征，但是還不足夠詳細的足以明確轉(zhuǎn)換為可執(zhí)行代碼。它的附屬性則相反，所有復雜的細節(jié)需要用于表示在給定的計算環(huán)境的附屬性。布魯克斯認為，相對于表示軟件和測試它的保真度的模型（附屬部分），創(chuàng)造軟件的最重要的部分是說明書，設計和本質(zhì)概念構(gòu)想的測試。如果這是真的，他推斷，構(gòu)造軟件將會一直困難。不管語言和工具如何的給力，都會使我們遠離我們想要表達的真正的問題。乍一看，布魯克斯的結(jié)論似乎認為面向?qū)ο蟮某橄缶哂刑岣哕浖a(chǎn)效率的潛力這一顯著因素是無效的。而事實上，如果面向?qū)ο蠹夹g(shù)主要講授和用于從頭開始構(gòu)建新的系統(tǒng)，像那些現(xiàn)代工業(yè)常見的案例一樣，也許只有邊際生產(chǎn)率的提高可以期待。但是，在另一方面，它強調(diào)的是從單個系統(tǒng)轉(zhuǎn)移到可分割的軟件組件的生產(chǎn)和使用，使深刻的變化成為可能?？芍赜梅椒ǖ暮锰巸蓚€值得樂觀的理由。首先，通過排除工業(yè)軟件工程大多數(shù)意外的困難可以使軟件費用降低一個數(shù)量級——或許不是一個單獨的系統(tǒng)版本，但肯定覆蓋整個產(chǎn)品生命周期。方法和實現(xiàn)語言是不夠的，但是，要達到降低費用的目標，無論多么強大的概念和高度自動化。我們還需要訪問那些在現(xiàn)代工業(yè)軟件項目中被一遍又一遍改造的底層封裝基礎概念的大量可重用構(gòu)件基礎。其次，可重用抽象并不僅限于隱藏意外的困難，也可以用來攻擊軟件設計的本質(zhì)。涉及解決問題的復雜性不僅取決于問題本身，同樣受到推理問題的原始有效觀念影響。所以如果我們能夠提高表達能力和原始事物的可理解性在不同的問題領(lǐng)域，那么類似抽象設計的復雜性就可以減小。作為附帶影響，投資于重用還可以帶來另外一個重要的好處。軟件構(gòu)件在多重環(huán)境下被用到或重用多次意味著軟件質(zhì)量有連續(xù)提高的機會，這在經(jīng)濟上比只在一個項目中使用可行性更高。這可以使新的抽象逐步發(fā)展直到它們成為概念上強大到足以使它們成為系統(tǒng)的一部分開發(fā)人員的標準詞匯。這也許，反過來促進新的有用的，但是由于初步努力尚未達到要求的更高水平的抽象被發(fā)現(xiàn)。起初的困難目前已投資超過過去二十年來的顯著努力用于建立和使用工業(yè)系統(tǒng)開發(fā)的軟件組件庫。盡管某些應用領(lǐng)域已經(jīng)看到了一些成功，在一般案例中實現(xiàn)高度重用程度被在練習中被證明困難比預期中的更難。大多數(shù)的失敗被歸咎于組織的缺點，例如缺少明確責任的角色（重用管理者），沒有一致的管理策略，缺少自動化工具的支持，以及與短期項目預算沖突等。其它的問題是自然的商業(yè)，例如如何保護可重用設計足以使與投資人的投資是匹配的。這些問題之所以存在，是因為我沒轉(zhuǎn)換技術(shù)，必須要先解決問題。但這一切的關(guān)鍵是面向?qū)ο蟮某橄蟆ㄒ坏淖阋詨蛴糜跇?gòu)建所需的通用組件的技術(shù)。由于重用主要依賴于傳統(tǒng)的技術(shù)，也就不必為它的失敗而感到奇怪了。就像我們?nèi)鄙倩镜姆椒ㄉa(chǎn)正確的部件，正式組織和自動瀏覽工具難以提供幫助。另一方面，面向?qū)ο蟛]有自動解決所有問題，許多面向?qū)ο蟮捻椖客瑯訄蟾骐y以實現(xiàn)重用目標的困難。然而，這并不能作為大規(guī)模重用在實踐中無法實現(xiàn)的跡象，或者說面向?qū)ο鬅o效。相反，有很多原因可以解釋這些初步的困難只是沒有預料到而已。首先，大多數(shù)或者說全部的工業(yè)化的面向?qū)ο蟮捻椖咳匀辉谑褂没旌系恼Z言或者混合的方法。致使部分自相矛盾的概念產(chǎn)生混亂并延遲充分利用新方法必需的心理轉(zhuǎn)變?；旌险Z言落后的兼容性需求同樣使完全支持面向?qū)ο蟮暮诵母拍钭兊貌豢赡?，進而使建設高質(zhì)量的組件庫變得困難。其次，即使技術(shù)手段是一個先決條件且必須是第一位的，組織方面也同樣重要。許多項目失敗是因為準備不充分的培訓，缺少管理支撐或者重用協(xié)調(diào)。這些同樣是必須解決的問題，尤其是對于大型機構(gòu)。最后，商用類庫的大小和質(zhì)量是一個重要變量，甚至最好的面向?qū)ο蟮沫h(huán)境也只是一個目標的一小部分影響因素。因為良好的抽象需要依賴多種已經(jīng)被嘗試過的方法逐步開發(fā)，在我們可以期待一些東西可以接近最常見的改造軟件組件的完整封裝之前，它自然會耗費一些時間。 知識的重用之路如果我們把當前的面向?qū)ο笳Z言趨勢與1970年代到1980年代初向高級語言過渡比較，這種情形盡管有很多相似之處，也是相當不同的。像Pascal和C這類控制結(jié)構(gòu)體現(xiàn)抽象的組裝的語言，程序員總是通過智力解決（經(jīng)常發(fā)生在一些偽陵符號注釋），因此,大回報是立竿見影。當由構(gòu)造序列組成的機器指令的冗長的且易出錯的翻譯不再需要時，工作可以繼續(xù)像以前一樣，只是更快。在一些重要的領(lǐng)域，當從今天被認為是傳統(tǒng)語言的（如Pascal或C）轉(zhuǎn)向一個更好的面向?qū)ο蟓h(huán)境同樣如此。使用現(xiàn)成的組件的能力代表了幾乎所有的基本數(shù)據(jù)結(jié)構(gòu)和基本算法（列表，哈希表，隊列，棧），而不需要知道任何關(guān)于它們的實現(xiàn)，是一個直接并聯(lián)。另一個領(lǐng)域是圖形接口。但是面向?qū)ο蟮某橄笠詾橹?，因為它幾乎可以在任何一個領(lǐng)域被用來創(chuàng)建新概念。這意味著它最大的潛能（從長遠來看）不在于代表我們已經(jīng)熟悉的概念，而是作為發(fā)明新的概念的媒介。這是面向?qū)ο笞鳛橐粋€技術(shù)投資而非短期收益的一個主要原因（盡管并不排除后者）。真正的大回報將取決于重用在特定領(lǐng)域的水平。它有可能捕獲在整個應用程序類型即所謂的框架,而且從一個環(huán)境到另一個環(huán)境只需修改小部分即可。成功的框架在開始的時候很難構(gòu)思。相當于它們逐漸適應進化的一群解決一個特定問題也能解決其它問題的組件，類似的在實踐中出現(xiàn)的問題。因此產(chǎn)生的結(jié)構(gòu)的有效性證明被經(jīng)驗證明，保證低成本/收益比率。所以如果事情進展緩慢我們不能絕望——畢竟，我們是伸手摘星。未來的潛力是巨大的，盡管廣泛的培訓和組織支持是必要的且不是免費的，在我們的投資開始獲得匯報之前我們不需要走很遠的重用之路。在本書中，我們將介紹來自確實至關(guān)重要的廣泛的軟件重用為基礎的面向?qū)ο蟮姆治龊驮O計，而且只要我們利用面向?qū)ο蟾拍畹姆绞皆趯嵺`中實現(xiàn)是符合這以目標的。這一觀點強調(diào)我們認為沒有充分解決的面向?qū)ο蠹夹g(shù)的某些方面。那么，什么是有能力使軟件重用變成標準的做法并且最終給出軟件工程面向?qū)ο笮g(shù)語的面向?qū)ο蟊举|(zhì)的意義？除了類的概念提供的極致的靈活性——讓我們可以通過繼承建立可組合且可量身定做的開放組件——已經(jīng)在序言中提到的面向?qū)ο蟮娜齻€重要方面，無縫性、可逆性和和軟件外包，比迄今為止已有的關(guān)于分析和設計文獻更值得關(guān)注。我們來依次看一下。 1.2無縫性面向?qū)ο蠓椒ㄊ瞧駷橹挂阎奈ㄒ痪哂袧摿Φ姆椒ǎ梢允狗治?、設計，以及通用的軟件系統(tǒng)的設計和實現(xiàn)轉(zhuǎn)變?yōu)檎嬲臒o縫過程。從用戶需求到分析與設計，到運行系統(tǒng)平穩(wěn)過渡，軟件工程的目標需要20多年，但是傳統(tǒng)的方法在實踐中已經(jīng)失敗（雖然經(jīng)常聲稱已經(jīng)解決）。這不是令人驚訝的，因為概念和符號設計師的方法被迫從Scylla和Charybdis選擇。要么你提供一個傳統(tǒng)編程語言的翻譯，那些改變符號就能成為另外一種的語言（通常引起的復雜性比它解決的問題更多），或者你發(fā)明一個完全不同的高級符號并保持規(guī)范和代碼之間的差異。同樣的抽象機制（類）可以用于所有的發(fā)展階段使面向?qū)ο笕绱说奈??；靖拍钚枰韧獠扛拍钅Ｐ蛯ο蟠磲t(yī)院,飛機,和廣泛的區(qū)域網(wǎng)絡并不是本質(zhì)上有什么不同，所需對象代表四精度浮點數(shù),街道地址或進程調(diào)度程序。抽象封裝的類的語義解釋會有所不同，但是一般的問題仍然是相同的：指定類的一致性，與其他類的關(guān)系，通過適用操作的行為。通過生產(chǎn)、維修工作系統(tǒng)嫩鞏固保持相同的模式從最初的可行性研究帶來巨大的優(yōu)勢。當基本概念對于每個人都相同時，與每一個不同角色的項目成員溝通是一個很大的提高。教育促進人造說明符與實現(xiàn)者之間的障礙消失，為系統(tǒng)生命周期的整體視圖創(chuàng)造空間。無縫性也促進了需求跟蹤。由于類從分析階段被引入直到最終的系統(tǒng)還會呈現(xiàn)，通過設計和實現(xiàn)跟蹤需求擴展變得很容易。 1.3可逆性真正的無縫性不僅僅意味著容易從規(guī)范的轉(zhuǎn)變實現(xiàn)。太多的面向?qū)ο蠓椒ㄒ蕾囉诓谎远鞯闹挥糜谠缙陂_發(fā)階段分析和設計符號的設想，然后翻譯成面向?qū)ο缶幊痰某绦蚧虿?。但在某些時候（其實很快）初始系統(tǒng)將被修改以滿足新的要求。理想地，這意味著首先改變最高的描述，然后向下相繼地傳遞變化直到代碼實現(xiàn)。然而，這不是在實踐中大多數(shù)系統(tǒng)的工作方式。因為高級規(guī)范只能代表系統(tǒng)的一個粗略的草圖,在規(guī)格可以執(zhí)行之前必須忽略很多細節(jié)和問題在這一點上。這意味著一個全新的根據(jù)實現(xiàn)語言概念的抽象世界將被創(chuàng)造，主要的興趣和創(chuàng)造性工作將逐步轉(zhuǎn)移到現(xiàn)在的環(huán)境。連續(xù)的改進和修正將會被直接應用與程序代碼，因為只有我們有足夠的表達能力能夠解決不可能解決的隱晦的、詳細的決定性規(guī)范。而且有些細節(jié)總是被證明對系統(tǒng)結(jié)構(gòu)具有重大影響。（如果程序代碼可以從規(guī)范代碼自動生成，后者將簡單的成為我們新的編程語言而且我們一點也不需要討論的低水平。）然而，如果抽象系統(tǒng)描述是為了在第一次翻譯成程序代碼時的價值，修改代碼則必須定期的反射回給規(guī)格。在這里，所有的傳統(tǒng)方法被摧毀。如果概念原語被規(guī)格和實現(xiàn)語言所分別使用，不能被直接映射到彼此（總是用非面向?qū)ο筇幚淼那闆r），這將導致規(guī)范和實現(xiàn)之間的分歧。隨著系統(tǒng)的發(fā)展保持兩個世界始終一致將會變得非常昂貴，因為這意味著或多或少的在不兼容的概念結(jié)構(gòu)之間重復簡單的翻譯。事實上，即使你努力使所有的規(guī)范保持最新，也沒有辦法知道它們真的是最新的（由于概念上的不匹配），所以通常人們不會信任它們。畢竟，只有可執(zhí)行的規(guī)范，即程序代碼，通過實行系統(tǒng)操作與硬件交流。它是決定飛機是否安全起飛或降落的完整程序代碼，而不是吸引分析師或設計師的藍圖。一個正確的系統(tǒng)可以沒有故障的運行，即使它的規(guī)范是錯的，而不是相反。因此，當我們在實踐中要選擇支持的描述，選擇很簡單。規(guī)范的價值直接關(guān)系到它們可以直接通過規(guī)范翻譯成程序代碼或被程序代碼直接翻譯為規(guī)范。那些聲稱只有非常高層次的需求和分析模型要緊，沒有給出任何如何映射到可執(zhí)行代碼或從可執(zhí)行代碼反射的做法的提示，看起來似乎并不了解現(xiàn)在的軟件意味著管理數(shù)十億美元的投資。面向?qū)ο蟾拍畹母呒壗＜夹g(shù)被奮力征服程序設計的復雜性的人們發(fā)現(xiàn)似乎并不是一個巧合。不像其他的方法，面向?qū)ο蟊举|(zhì)上是可你的。由于分析和設計類可以作為最終系統(tǒng)的一部分，任何影響這些類的結(jié)構(gòu)和接口的實現(xiàn)更改變得立即可見，但是前提是我們避免包括其他領(lǐng)域的元素，如我們的方法的標準部分：如實體關(guān)系圖、狀態(tài)轉(zhuǎn)換圖、或者數(shù)據(jù)流程圖?；旌戏妒酱蚱屏丝赡嫘?，并且引入了新的復雜性，這在大多數(shù)情況下將大于預期效益。這并不意味著這些技術(shù)能用于面向?qū)ο笙到y(tǒng)。一些應用程序可能會受益于特殊場合的實體-關(guān)系圖，并且通過狀態(tài)轉(zhuǎn)換圖建造某些抽象將會極其的強大，但是它們基于一般方法則會丟失重點。相反，我們應該利用面向?qū)ο蟮奶厥馄焚|(zhì)：它的簡單易行，連貫性，以及極其普遍性。它在沒有強制改變?nèi)魏翁厥獾牟榭捶绞降那闆r下提供了對各級抽象的支持。這使這種途徑在開發(fā)方法中變得獨特，且它的基本概念被證明足夠的支持我們需要的大多數(shù)軟件的規(guī)范和實現(xiàn)，幾乎可以忽略軟件的應用領(lǐng)域。 1.4軟件外包軟件重用需要額外的高質(zhì)量，因為其潛能提高生產(chǎn)效率也比以前造成傷害的風險更大。從頭編寫大多數(shù)用傳統(tǒng)風格編寫的軟件至少在限制錯誤在特定系統(tǒng)發(fā)展的影響的具有優(yōu)勢。然而，如果一個不適當?shù)能浖?gòu)件應用于成千上萬的應用程序，積累損傷實際上是非常高的。在一定程度上這會讓重用軟件片段受到廣泛測試沉重反擊，但是測試只能揭示一小部分潛在的錯誤，只要使用模式在變化，以前隱藏的問題可能會被發(fā)現(xiàn)。面向?qū)ο蠓椒ǖ恼麄€想法是通過在抽象層不斷地建立更強大的組件設計軟件從而反映出在各種應用領(lǐng)域的高級概念，每個都建立在之前的基礎上。我們知道沒有更好的方式來掌握錯綜復雜的事物，但這同樣意味著產(chǎn)生的結(jié)構(gòu)變得完全依賴于組成部分的正確機能。如果一些核心抽象失敗了，整個建筑就有可能分崩離析。因此想辦法保證軟件的正確性也更加重要。幸運地，近年來提出來了一個非常有前途的方法，將元素從抽象數(shù)據(jù)類型和正式規(guī)范的研究領(lǐng)引入到軟件工程的標準用法。這是軟件外包的理論【Meyer1992c】。這個想法是用聲明定義每個類的語義。先決條件和每個操作的結(jié)果行為是通過預處理和后置條件規(guī)定，且全部類一致通過類的不變式。然后，這些語義規(guī)范在沒個類之間形成一個合約基礎，供給方和所有的類使用它的業(yè)務操作和客戶端。一個軟件被視為一個客戶和供應商合作的網(wǎng)絡，而軟件的請求和服務通過分散的合同精確定義。根據(jù)合同，一致的錯誤處理機制是可能的。如果聲明在運行時被監(jiān)控，違反合同則會導致異常。分散的處理程序可以被定義和實現(xiàn)為一般的異常管理工具處理錯誤恢復。軟件外包代表程序生產(chǎn)中具有重大意義的一步，應該被包括在任何面向?qū)ο蟮姆治龊驮O計方法中，旨在建立可靠的、高質(zhì)量的專業(yè)化產(chǎn)品。2BON方法2.1介紹本書描述的方法叫做BON，代表“業(yè)務對象表示法（BusinessObjectNotation”。它提供了一組面向?qū)ο筌浖５母拍?，兩個版本的支持表示法——一個圖形一個文本——一套可以用于生產(chǎn)模型的規(guī)則和指引。BON專注于分析和設計的基本要素，該方法是集成和適應可以應用與不同的組織的各種開發(fā)框架和標準。BON支持核心沒有特殊應用程序類型的整體軟件開發(fā)，特別是對質(zhì)量和可靠性要求很高的產(chǎn)品。概念和符號的設計提倡在前一章中提出的可重用性方法：無縫性，可逆性，軟件外包。與發(fā)現(xiàn)在許多面向?qū)ο蟮年嚑I中大規(guī)模重用的可達性有些消極態(tài)度相反，我們認為這確實是該技術(shù)的首要目標。BON不引入任何根本性的新概念；面向?qū)ο蟮幕舅枷虢Y(jié)合軟件規(guī)范元素作為原語是足夠的。它是一個可以造成質(zhì)的區(qū)別的通過一個擴展標記的詳細定義和概念表達排列。（到一定程度時，BON由被不包含它的表示方法定義，因為無縫和簡單是指導明星。）讀者當然會懷疑在很多表示法已經(jīng)出版的情況下而不引入新的表示法是否會導致目標不能實現(xiàn)。我們不能只是適應一個更廣泛使用的現(xiàn)有的表示法來實現(xiàn)我們的目標嗎？遺憾的是不能。盡管在許多已經(jīng)被提出的方法中使用的概念似乎是或多或少相同（類，操作，關(guān)系），依然有表面下的細微差異以防它們一對一映射。由于表示法只是一種用綜合的可讀的形式表達基本概念的方式，重用在這種情形下不能工作。面向?qū)ο蟮姆治龊驮O計領(lǐng)域還很年輕、不成熟，許多競爭的方法和相應的表示法自然地會在它該出現(xiàn)的時間不斷涌現(xiàn)。也許這會對一些潛在的用戶制造混亂，但這真的是他們的最佳收益。規(guī)范化太早是極其有害的，因為它縮小了建模的角度，擋住了真正理解的方式。（我們很高興地看到，這一觀點被眾多在該領(lǐng)域知名的專家共享，通過最近的一封公開信“過早的標準化方法是有害的”[Mellor1993]） 2.2什么是BON沒有的許多現(xiàn)有的分析和設計的方法，也許大多數(shù)，不是使用一些實體-關(guān)系方法(實體關(guān)系建模[Chen1976])或有限狀態(tài)機（FSM建模）的變種的數(shù)據(jù)建模，就是全部，作為高級系統(tǒng)描述的一個重要部分。我們的想法是把這些技術(shù)的優(yōu)點與面向?qū)ο蟾拍罱Y(jié)合起來，從而從連個方面受益。然而，這種方法嚴重阻礙了在前面章節(jié)提到的無縫和可逆性主張。我們認為，這個缺點遠遠超過因此帶來的好處。使用FSM建模，由于在狀態(tài)轉(zhuǎn)換圖和最終實現(xiàn)之間沒有簡單的映射，阻抗不匹配是顯而易見的。（除非我們把沒個對象都建模為一個狀態(tài)機，從而放棄所有類概念的抽象力量）。使用ER建模，情況則比較復雜一點。 為什么不用ER建模？分析ER建模的支持者聲稱二元關(guān)系比類的相互引用更加通用，因為在前面提到的后一種明確的設計選擇仍然保持開放。這當然是真實的，因為可以通過多種方式表示兩個類之間的特定關(guān)系。然而，通過限制所有的類依賴于二元關(guān)系使選擇保持開放通常并不是最好的一種方案。事實上，為了得到一個好的系統(tǒng)模型我們反而不能保持一切開放，因為這將嚴重地影響我們理解問題。所以問題不是是否應該做出設計決策，而是選擇哪一個。ER建模當然也不例外。相反，就像許多武斷的或有疑問的決定必須被做出以達成ER建模，正如一個純粹的面向?qū)ο竽Ｐ?。在后一種情況下，我們必須選擇概念模型作為類和哪些應該成為這些類的操作。用ER建模，我們必須選擇描繪實體的概念，以及哪些會成為實體的屬性，哪些會成為它們之間的關(guān)系。這對改變來說并不意味著比選擇更容易或者影響更小。例如，一個ER模型中的屬性被視為實體中的“性質(zhì)”，并由一個值表示。但一個屬性是什么？考慮實體員工和一個服務部門最受歡迎的人的概念。顯然，最受歡迎的是一種人的性質(zhì)，但是從系統(tǒng)的觀點來看把這當做一個員工的屬性建模可能是相當錯誤的。員工抽象可能不知道它的條件，知識表示自身的唯一方式可能相反是其它實體屬性的組合，也許是統(tǒng)計數(shù)字和客戶投票。所以我們在這里有一個問題：任何一個屬性都被認為是和儲存在實體中的數(shù)值是直接對應的，在這種情況下太低級，或者這只是一個不明確的“性質(zhì)”，這又太高級，因為它沒有告訴我們關(guān)于系統(tǒng)足夠多的信息。面向?qū)ο蟮闹虚g道路是一個類操作返回一個值，而值可能是任何類型的。這避免了過早的確定不同的值的存儲方式，并且告知了足夠多的系統(tǒng)行為允許無縫過渡到實現(xiàn)。另外一個麻煩的地方是為實體的屬性和關(guān)系選擇什么級別的“標準化”。實體A與B之間的二元關(guān)系通常不會對A與B之間的聯(lián)系作任何說明（除了通過語義標簽，例如“適用于”和它的相對角色“使用”）。按此推理，傳遞規(guī)律也必須適用：如果B通過關(guān)系“有下級單位”反過來與C關(guān)聯(lián)，那么A也能通過“適用于上級單位”與C關(guān)聯(lián)，C通過“是上級單位的下級單位”與A關(guān)聯(lián)（圖2.1）。由于ER模型通常是連接圖，可以查找每一個實體與其它實體之間的二元關(guān)系遞歸地調(diào)用規(guī)律產(chǎn)生圖。因此，只有被認為是最重要的關(guān)系被包含在圖中，其余的則被隱藏。有些作者建議分離獨立的屬性和關(guān)系的正交基，并且標記所有其它顯示的正交基。然而，哪些作為正交基被選擇遠不夠明顯，也不清楚“衍生”意味著什么。例如，考慮圖2.2所示的實體，我們可以選擇母親-兒子和母親-女兒兩個關(guān)系作為正交基。兒子-女兒之間的關(guān)系兄弟-姐妹就變成了衍生，因為對于任何一對兒子和女兒我們可以推斷出他們是否是兄弟姐妹。但是我們可以選擇其他兩個作為正交基（假設兄弟-姐妹意味著所有的兄弟姐妹，共有雙方的父母）。此外，可導出的屬性通常是全局的。從兒子的視角，母親和姐姐的角色可能同樣重要，且事實上一個屬性從另一個屬性中導出并不應該總是被強調(diào)。相反，可能晚些時候一個系統(tǒng)中母親的角色也能被繼母實體所實現(xiàn)，那么，可導出性將不再持有。出于同樣的原因，衍生屬性和基礎屬性的區(qū)別并不總是明顯。確定可導出性必須經(jīng)常做出關(guān)于底層信息內(nèi)容的比預期要早的假設。這些問題會在純粹的面向?qū)ο蠓椒ㄇ跋В驗槲覀儗Ｗ⒂谙到y(tǒng)行為而不是什么信息需要被存儲。因為這種行為是實現(xiàn)系統(tǒng)功能的需要，更多的重在應對未來變化的結(jié)果。底線是如果我們在分析和設計級別加入ER建模我們將放棄面向?qū)ο蠓椒ü逃械臒o縫性，但是我們卻得不到多少回報。在實踐中，真正的系統(tǒng)通常有幾百個潛在的實體和它們之間的關(guān)系。因此產(chǎn)生的完整的ER圖變得巨大，其本質(zhì)上是一個平面結(jié)構(gòu)。為實現(xiàn)一些目的，大型圖通常被分解較小的重疊的部分，其中每個部分包含一些實體集與一個相互關(guān)系的子集。這可能使任意的關(guān)聯(lián)遺漏。這種技術(shù)類似于過去的分割項目流程圖，只是留下很多引用其他圖的箭頭，邊界關(guān)系只是簡單的限制。然而，這并不改變固有的平面結(jié)構(gòu)，也不是對理解大型系統(tǒng)如此重要的“縮放”功能，我們堅持“平移”的形式。強調(diào)作為一個建模概念的關(guān)聯(lián)與對象行為分離有利于整體系統(tǒng)觀察。它打破封裝和集中在短期細節(jié)上比局部概念更多，這可能有潛力時之存活更長時間。ER建模作為分析和設計方法的部分不會幫助我們找到可能在其它情況下使用的代表有趣概念的類，除了解決當前的一部分問題。面向?qū)ο箝_發(fā)的無縫性和可逆性因此不能完全利用，因而不利用重用。而且，我們不需要這種類型的獨立的聯(lián)合，因為面向?qū)ο笤Z可以直接用來建模任何我們想要的概念。由于這些原因，BON被設計為遵循不同的軌道。與其試圖包含傳統(tǒng)數(shù)據(jù)建模概念或或所謂的結(jié)構(gòu)化技術(shù)帶著所有附帶的缺點，更富有成果的是尋求：面向?qū)ο蟮撵`活性和透明度、強類型的表現(xiàn)能力，以及類之間的正式契約的結(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