關(guān)于我們
書單推薦
新書推薦
|
世界著名計(jì)算機(jī)教材精選:軟件架構(gòu)與模式 《世界著名計(jì)算機(jī)教材精選:軟件架構(gòu)與模式》可供計(jì)算機(jī)專業(yè)學(xué)生、工科學(xué)者、系統(tǒng)開(kāi)發(fā)人員和大型系統(tǒng)的系統(tǒng)架構(gòu)設(shè)計(jì)人員閱讀。本書的目標(biāo)是讓讀者掌握系統(tǒng)架構(gòu)和模式的基本原理與實(shí)際應(yīng)用。 1. 介紹面向?qū)ο笤O(shè)計(jì)方法中的架構(gòu)和設(shè)計(jì)模式。 2. 有助于提高軟件的編寫質(zhì)量,加深對(duì)軟件理論知識(shí)的理解,擴(kuò)展專業(yè)視野,了解大型軟件開(kāi)發(fā)中的架構(gòu)模式。 3. 介紹的設(shè)計(jì)模式和架構(gòu)模式都配有Java語(yǔ)言的程序?qū)嵗J街蓄惡皖愔g的靜態(tài)關(guān)系或?qū)ο箝g的動(dòng)態(tài)關(guān)系都用UML語(yǔ)言描述。各章末均提供了相應(yīng)的練習(xí)。 4. 本書在網(wǎng)絡(luò)上提供各章練習(xí)答案和書中實(shí)例的Java代碼。 5. 可以作為高校計(jì)算機(jī)相關(guān)專業(yè)的教材,也可供系統(tǒng)開(kāi)發(fā)人員和大型系統(tǒng)的系統(tǒng)架構(gòu)設(shè)計(jì)人員閱讀參考。 譯 者 序 隨著中德兩國(guó)交往的不斷加深,各行各業(yè)都在不斷地拓展多方位的合作。但是中德兩國(guó)在軟件行業(yè)的合作卻并不多見(jiàn),來(lái)自德國(guó)的計(jì)算機(jī)類翻譯著作也非常少。 德國(guó)企業(yè)出于嚴(yán)謹(jǐn)?shù)娘L(fēng)格和安全性的考慮,基本很少有軟件外包,對(duì)于應(yīng)用軟件的開(kāi)發(fā)和使用一般也都局限在德國(guó)本土范圍內(nèi)(除了一些大型公司,如SAP),所以我們對(duì)德國(guó)計(jì)算機(jī)行業(yè)的發(fā)展了解得并不多。 本書的作者Goll教授不僅有多年的計(jì)算機(jī)軟件工作經(jīng)驗(yàn),同時(shí)還在德國(guó)Esslingen應(yīng)用技術(shù)大學(xué)創(chuàng)建了軟件專業(yè),1994年他還建立了Steinbeis-Transferzentrum Systemtechnik軟件公司。因?yàn)樵摴舅诘厥潜捡Y公司和博世公司的總部,所以主要從事汽車和自動(dòng)化方向的軟件開(kāi)發(fā)。我在上學(xué)期間曾得到Goll教授的耐心指導(dǎo)。Goll教授無(wú)論是在專業(yè)技術(shù)還是在教學(xué)業(yè)務(wù)上都是令人敬重和贊佩的。 希望這本書的引進(jìn)能夠使廣大讀者對(duì)德國(guó)的軟件技術(shù)有初步的認(rèn)識(shí)。本書共分為5章。前3章主要是介紹一些軟件技術(shù)的理論。第4章介紹了常用的軟件模式,具有一定的軟件基礎(chǔ)知識(shí)的讀者通過(guò)學(xué)習(xí)本章的內(nèi)容可以提高編寫軟件的質(zhì)量,同時(shí)加深對(duì)軟件理論知識(shí)的理解。第5章介紹了軟件架構(gòu)模式,讀者在熟練掌握軟件模式后,通過(guò)本章可以擴(kuò)展視野,逐步了解大型軟件開(kāi)發(fā)所使用的架構(gòu)模式。對(duì)于軟件開(kāi)發(fā)人員來(lái)說(shuō),通過(guò)學(xué)習(xí)本章的內(nèi)容可以加快在專業(yè)方面的成長(zhǎng)。 賈山翻譯了本書的第1章、第3章和第4章,天津理工大學(xué)的李欣老師翻譯了第2章和第5章。在本書翻譯過(guò)程中,譯者得到了清華大學(xué)出版社的大力支持和幫助,在此致以衷心的感謝。讀者如果在閱讀中有任何疑問(wèn),可以直接發(fā)送電子郵件到zd_jiashan@126.com。 賈山 2016年10月 前 言 本書的內(nèi)容 軟件系統(tǒng)的架構(gòu)應(yīng)該是易于擴(kuò)展和標(biāo)準(zhǔn)化的,這樣便于開(kāi)發(fā)者對(duì)系統(tǒng)架構(gòu)進(jìn)行修改。在面向?qū)ο笤O(shè)計(jì)方法中,已經(jīng)有很多有意義的架構(gòu)和設(shè)計(jì)模式。這些模式都是建立在面向?qū)ο罄碚摶A(chǔ)上的,例如依賴倒置原則。所以,本書首先介紹的是一些基本的原則,接下來(lái)講解如何把這些面向?qū)ο蟮脑瓌t運(yùn)用到系統(tǒng)架構(gòu)和設(shè)計(jì)模式中。所有這些講解都配有Java語(yǔ)言的程序?qū)嵗?/p> 在講解設(shè)計(jì)原則之后,本書將重點(diǎn)探討系統(tǒng)架構(gòu)和設(shè)計(jì)模式,通過(guò)附帶的實(shí)例,讀者可以從中選擇適合自己系統(tǒng)的模式。書中的一些實(shí)例只截取了部分代碼,完整的實(shí)例可以從相應(yīng)的網(wǎng)站上查看。 本書可供計(jì)算機(jī)專業(yè)學(xué)生、工科學(xué)者、系統(tǒng)開(kāi)發(fā)人員和大型系統(tǒng)的系統(tǒng)架構(gòu)設(shè)計(jì)人員閱讀。本書的目標(biāo)是讓讀者掌握系統(tǒng)架構(gòu)和模式的基本原理與實(shí)際應(yīng)用。 書中的實(shí)例都是以Java語(yǔ)言為基礎(chǔ)的。在講解模式中類和類之間的靜態(tài)關(guān)系或者是對(duì)象之間的動(dòng)態(tài)關(guān)系時(shí),均是借助于UML語(yǔ)言進(jìn)行描述的。所以讀者應(yīng)該具備Java語(yǔ)言和UML語(yǔ)言的基礎(chǔ)知識(shí)。 書中的圖標(biāo)表示對(duì)相應(yīng)的內(nèi)容做簡(jiǎn)短的總結(jié)。圖標(biāo)提醒讀者,這是在實(shí)際開(kāi)發(fā)過(guò)程中經(jīng)常容易導(dǎo)致錯(cuò)誤的地方。 每章附帶簡(jiǎn)單的練習(xí),書中沒(méi)有提供答案,讀者可以在相應(yīng)的網(wǎng)站上查看。 本書的緣起 本書作者在此前的另一本書《軟件技術(shù)的方法和架構(gòu)》[Gol11]1中的第2章曾經(jīng)簡(jiǎn)短地介紹了設(shè)計(jì)和架構(gòu)模式。在本書中,主要介紹這部分內(nèi)容,不僅對(duì)這部分內(nèi)容做認(rèn)真的整理,而且還增加了面向?qū)ο笤O(shè)計(jì)的基本原理,因?yàn)檫@是設(shè)計(jì)模式的基礎(chǔ)和加深理解模式所必需的。在吸收了模式后面隱藏的設(shè)計(jì)原理并重新修訂以后,就形成了此書。 各章概要 下面簡(jiǎn)單地介紹各章的主要內(nèi)容。 第1章討論面向?qū)ο笤O(shè)計(jì)的基本原則,包括對(duì)于一個(gè)類的設(shè)計(jì)和多個(gè)類間合作的設(shè)計(jì)原則。一個(gè)類的設(shè)計(jì)原則有封裝、抽象、信息隱藏、關(guān)注點(diǎn)分離、單一職責(zé)原則和接口隔離原則。多個(gè)類的合作涉及松耦合原則、里氏代換原則、契約式設(shè)計(jì)原則、開(kāi)閉原則和依賴倒置原則。隨后分析了控制反轉(zhuǎn)和在對(duì)象創(chuàng)建過(guò)程中減少相互依賴性,這兩個(gè)是還沒(méi)有形成“原則”的技術(shù)。 第2章關(guān)注軟件架構(gòu)概念的定義和軟件架構(gòu)關(guān)于非功能性的質(zhì)量。軟件設(shè)計(jì)中的參考架構(gòu)和模式的相互比較。在分析和討論構(gòu)建一個(gè)系統(tǒng)的主要任務(wù)、軟件架構(gòu)的不同層次和結(jié)構(gòu)模型以后,再研究軟件架構(gòu)師對(duì)一個(gè)項(xiàng)目的意義。 第3章研究架構(gòu)模式、設(shè)計(jì)模式和慣用法的每一個(gè)特性,最后介紹描述設(shè)計(jì)模式和架構(gòu)模式的模板。 第4章研究面向?qū)ο笤O(shè)計(jì)模式。面向?qū)ο笤O(shè)計(jì)模式多用于在軟件開(kāi)發(fā)中解決子系統(tǒng)中的特定問(wèn)題。設(shè)計(jì)模式由類組成,通過(guò)類之間的互相協(xié)作解決特定的問(wèn)題。每一個(gè)模式適用于一類問(wèn)題的解決。本章將介紹結(jié)構(gòu)模式、行為模式和創(chuàng)建型模式。在結(jié)構(gòu)模式中講解適配器模式、橋梁模式、裝飾模式、外觀模式、組合模式和代理模式。在行為模式中研究模板方法模式、命令模式、觀察者模式、策略模式、中間者模式、狀態(tài)模式、角色模式、拜訪者模式和迭代器模式。創(chuàng)建型模式包括工廠方法模式、抽象工廠模式、單例模式和對(duì)象池模式。 第5章介紹架構(gòu)模式。架構(gòu)模式可以把系統(tǒng)劃分為系統(tǒng)組件。一個(gè)架構(gòu)模式可以含有多個(gè)設(shè)計(jì)模式,也可以不含有設(shè)計(jì)模式,例如分層架構(gòu)模式就不包含設(shè)計(jì)模式。本章介紹分層架構(gòu)模式、管道和過(guò)濾器架構(gòu)模式、插件架構(gòu)模式、中介模式、面向服務(wù)的設(shè)計(jì)模式和模型-視圖-控制器(MVC)模式。 書寫格式 本書中重要的概念加粗顯示。 相應(yīng)網(wǎng)址的重要提示 本書相應(yīng)的網(wǎng)址為http://pan.baidu.com/s/1o6MEsqu,包含各章練習(xí)答案和書中的實(shí)例。 感謝 作者在編寫本書的過(guò)程中,從實(shí)例到文字得到了很多人的幫助。他們是Benjamin Adolphi先生、Sebastian Bickel先生、Manuel Gotin先生、Konstantin Holl先生、Dominic Kadynski先生、MichaKoller先生、Paul Krohmer先生和Philipp Stehle先生。Steffen Wahl先生、Christian Tolk先生、Fabian Wirsum先生和Jennifer Rauscher女士對(duì)文字處理和資源配置做了長(zhǎng)期大量的細(xì)致工作。作者在此表示衷心的感謝。 J. Goll/M. Dausmann 1 本書正文中提及的參考文獻(xiàn)均以5字符或6字符代號(hào)表示,詳見(jiàn)書末的“參考文獻(xiàn)”!g注 書中涉及的概念 派生類 一個(gè)派生類是從一個(gè)基類派生出來(lái)的。派生類繼承了基類的結(jié)構(gòu)(屬性的名稱和類型)和方法。 依賴性 依賴性是指兩個(gè)模型元素間的特殊關(guān)系。它表明,一個(gè)獨(dú)立元素的變化會(huì)影響到相關(guān)的元素。 抽象窗口工具包(AWT) AWT類庫(kù)是Swing類庫(kù)的前身。AWT-GUI組件與操作系統(tǒng)密切相關(guān)。Swing-GUI組件則借助于Java 2D的類庫(kù),通過(guò)Java的模擬機(jī)顯示在屏幕上,所以看起來(lái)操作系統(tǒng)沒(méi)有依賴性。 抽象類 抽象類不能構(gòu)造實(shí)例。從技術(shù)上講,一個(gè)抽象類包含一個(gè)或多個(gè)方法的定義,但是在抽象類里并沒(méi)有實(shí)現(xiàn)這些方法。沒(méi)有實(shí)現(xiàn)的方法只能在其派生類中實(shí)現(xiàn)。 抽象類也可以是不包含抽象方法的。這種抽象類只是為表達(dá)自身,不能被實(shí)例化。例如,一個(gè)“電器”或“飲料”不能被實(shí)例化。 抽象 抽象就是去掉每一個(gè)不重要的細(xì)節(jié),而只專注于重點(diǎn)內(nèi)容。 聚集 聚集是一種特殊的組合,它表達(dá)的是部分與整體的關(guān)系,說(shuō)明部分與整體的生存期沒(méi)有關(guān)聯(lián)。這一點(diǎn)與組合(composition)正好相反。 參與者 參與者是指一個(gè)陌生的系統(tǒng)或者一個(gè)設(shè)備在系統(tǒng)環(huán)境中的角色。參與者與系統(tǒng)之間是相互作用的。 用例圖(use case) 用例圖是描述系統(tǒng)可以提供的服務(wù),包括實(shí)現(xiàn)這些功能的步驟。用例圖的功能通常由協(xié)作圖(對(duì)象之間的交互)實(shí)現(xiàn)。 架構(gòu) 架構(gòu)可以理解為: * 把系統(tǒng)分解為模塊。 * 描述如何通過(guò)模塊間的合作實(shí)現(xiàn)目標(biāo)功能。 * 描述結(jié)構(gòu)的策略,即分解(靜態(tài)的)和功能(動(dòng)態(tài)的)。 軟件架構(gòu)設(shè)計(jì)的目標(biāo)就是讓系統(tǒng)對(duì)外能實(shí)現(xiàn)所期望的功能。 關(guān)聯(lián) 關(guān)聯(lián)描述了連接的規(guī)則,用于連接兩個(gè)或多個(gè)對(duì)象(對(duì)象是同級(jí)別的)。關(guān)聯(lián)從原則上說(shuō)是一個(gè)類間的對(duì)稱結(jié)構(gòu)關(guān)系。人們可以把關(guān)聯(lián)限制成單向的。 屬性 屬性的概念存在于類、對(duì)象、關(guān)聯(lián)和數(shù)據(jù)庫(kù)中。面向?qū)ο笾械膶傩愿拍顏?lái)自面向數(shù)據(jù)范例。這意味著: * 屬性屬于類或?qū)ο蟆?/p> * 一個(gè)關(guān)聯(lián)類描述了一個(gè)關(guān)聯(lián)的特性。 * 數(shù)據(jù)庫(kù)中關(guān)系(表)的一列也稱為屬性。屬性與列的取值并不相關(guān),而只是列的標(biāo)題。屬性值是列里面具體的一個(gè)取值。 基類 基類處在繼承的層次結(jié)構(gòu)中,在被關(guān)注類的上方。 關(guān)系 兩個(gè)或多個(gè)元素之間的關(guān)系是指這些元素之間存在的聯(lián)系。關(guān)系有動(dòng)態(tài)的和靜態(tài)的。 分類器 分類器是來(lái)自UML元模型的一個(gè)概念。一般認(rèn)為,如果UML的模型元素能夠生成一個(gè)實(shí)例,它就是分類器。一個(gè)分類器正常情況下有一個(gè)結(jié)構(gòu)和一個(gè)功能,例如抽象類是一個(gè)分類器。接口可以特殊地當(dāng)作是分類器,因?yàn)榻涌跊](méi)有屬性,也就是說(shuō)沒(méi)有結(jié)構(gòu)。 委托 委托是一種結(jié)構(gòu),一個(gè)對(duì)象收到一條信息后,并不是自己實(shí)現(xiàn)全部方法,而是把消息繼續(xù)傳遞下去。 依賴倒置 一個(gè)對(duì)象依賴于另一個(gè)對(duì)象,使用依賴倒置后,依賴的方向會(huì)倒轉(zhuǎn),即依賴和被依賴的實(shí)體關(guān)系被倒轉(zhuǎn)。 依賴倒置原則 依賴倒置原則是為了避免或者減少不同等級(jí)中模塊間的依賴關(guān)系。這就要求一個(gè)高一級(jí)的類不能依賴于一個(gè)低一級(jí)的類。高一級(jí)的類應(yīng)該聚集了一個(gè)接口或者是一個(gè)抽象類。這個(gè)抽象類或接口應(yīng)該由高一級(jí)的類決定,低一級(jí)的類應(yīng)該依賴于這個(gè)抽象類或接口。 圖表 圖表是觀察系統(tǒng)的特定視角。 在UML中的圖表大部分包含許多用線連接起來(lái)的節(jié)點(diǎn)。此外,還有時(shí)間圖,用于模擬電子的脈沖圖表。 實(shí)體 實(shí)體在所要處理的問(wèn)題框架內(nèi),具有一定的意義。它可以表示物品、生物或者草案。 實(shí)體對(duì)象 實(shí)體對(duì)象就是現(xiàn)實(shí)世界中物品、生物或者草案的抽象化表示。 設(shè)計(jì)模式(design pattern) 在針對(duì)一個(gè)問(wèn)題的最佳解決方案中,類或?qū)ο笸ㄟ^(guò)相互合作所實(shí)現(xiàn)的功能,可以成為這類問(wèn)題的解決方案。 事件 事件是控制流或者控制流的組合。系統(tǒng)應(yīng)對(duì)事件做出反應(yīng)。 框架 框架可以為正在開(kāi)發(fā)的系統(tǒng)提供類,其派生類可以繼承它的功能。框架可以決定應(yīng)用的結(jié)構(gòu),即粗略的結(jié)構(gòu)?蚣芏x類和對(duì)象的劃分、各自的中心職責(zé)、類和對(duì)象的合作以及它們的控制流[Gam95]。 保密原則 保密原則確保類的對(duì)象中的內(nèi)部和私有結(jié)構(gòu)對(duì)外是不可以使用的,只有在類的內(nèi)部才可以識(shí)別內(nèi)部結(jié)構(gòu)和方法的具體實(shí)現(xiàn)部分。接口和它的實(shí)現(xiàn)部分是分離的。對(duì)象中的數(shù)據(jù)只能通過(guò)接口中定義的方法來(lái)使用。 泛化 泛化與細(xì)分的方向相反。在泛化時(shí),要在繼承的層次結(jié)構(gòu)的上端整理綜合的屬性,然后向下細(xì)分,泛化的屬性也會(huì)被繼承。在繼承的層次結(jié)構(gòu)中,向上是泛化,向下是細(xì)分。 業(yè)務(wù)流程 業(yè)務(wù)流程是專業(yè)技術(shù)方面的工作進(jìn)程。它體現(xiàn)了為達(dá)到一個(gè)業(yè)務(wù)目標(biāo)所采用的各個(gè)相關(guān)措施的結(jié)合。 分組 分組是多個(gè)元素的組合。在UML中存在包的模型元素。包并不是系統(tǒng)的組成部分,而是概念上的示意圖,把元素清楚地按組進(jìn)行組合。 標(biāo)識(shí) 即使不同的對(duì)象擁有相同的屬性值時(shí)也可以區(qū)分開(kāi)它們,因?yàn)槊總(gè)對(duì)象都有自己的 標(biāo)識(shí)。 慣用法 慣用法是在特定的程序語(yǔ)言中的模型,是在深層次的抽象水平上作為設(shè)計(jì)模式或架構(gòu)模式,即可以用一種編程語(yǔ)言來(lái)實(shí)現(xiàn)設(shè)計(jì)模式,用來(lái)解決不適用于設(shè)計(jì)模式的特定技術(shù) 問(wèn)題。 實(shí)例 實(shí)例是UML模型元素的具體表現(xiàn)形式。 實(shí)例化 生成類型的實(shí)例。 交互 交互是通過(guò)兩個(gè)對(duì)象間傳送消息或者是多個(gè)對(duì)象相互作用而體現(xiàn)出的動(dòng)態(tài)關(guān)系。 進(jìn)程間通信 進(jìn)程間通信(IPC)是把進(jìn)程間的通信看做聯(lián)動(dòng)機(jī)制。進(jìn)程間通信的概念包括操作系統(tǒng)進(jìn)程對(duì)操作系統(tǒng)進(jìn)程的通信、線程對(duì)線程的通信。在一臺(tái)計(jì)算機(jī)上要進(jìn)行進(jìn)程間通信,需要借助于這臺(tái)計(jì)算機(jī)的操作系統(tǒng)進(jìn)行信息交換。如果并行的進(jìn)程分布在不同的計(jì)算機(jī),則計(jì)算機(jī)之間必須可以使用計(jì)算機(jī)對(duì)計(jì)算機(jī)的通信。 控制反轉(zhuǎn) 在控制流反轉(zhuǎn)時(shí),原先掌握控制流的程序要把控制權(quán)轉(zhuǎn)交給其他的模塊(大部分情況是可復(fù)用的模塊),這樣可以從輪詢轉(zhuǎn)換到事件驅(qū)動(dòng)。一個(gè)可復(fù)用的模塊(例如框架)常常調(diào)用專有模塊(例如應(yīng)用程序)。 通道 通道表示點(diǎn)到點(diǎn)的連接,用直線來(lái)表示。通道遵守先進(jìn)先出原則,即先進(jìn)入通道的先離開(kāi)。 封裝 封裝是面向?qū)ο蟪绦蛟O(shè)計(jì)中的重要概念之一。一般認(rèn)為把數(shù)據(jù)和所屬的功能放在一個(gè)盒子里(類)是十分有意義的,這樣數(shù)據(jù)和所屬功能沒(méi)有被分開(kāi)。 基數(shù) 基數(shù)的概念在數(shù)據(jù)庫(kù)和UML中都存在: * 在數(shù)據(jù)庫(kù)領(lǐng)域,基數(shù)在系統(tǒng)分析階段確定實(shí)體與實(shí)體之間數(shù)量的對(duì)應(yīng)關(guān)系,或者在系統(tǒng)設(shè)計(jì)階段確定表與表的數(shù)據(jù)記錄數(shù)量的對(duì)應(yīng)關(guān)系。基數(shù)可以依照關(guān)系類型標(biāo)明 1對(duì)1、1對(duì)n或者n對(duì)m。 * 在UML中基數(shù)表明所關(guān)注的UML元素的個(gè)數(shù)。借助于基數(shù)可以表示出多倍的關(guān)系(例如,1..m)。 類 類在面向?qū)ο笾畜w現(xiàn)的是一種數(shù)據(jù)類型,它可以生成對(duì)象。類含有結(jié)構(gòu)和功能。結(jié)構(gòu)包括屬性。類里面的方法決定了其對(duì)象的功能。類的每一個(gè)對(duì)象都有自己的標(biāo)識(shí)。 類圖 類圖展示的是類與類之間的靜態(tài)關(guān)系(關(guān)聯(lián)、泛化、實(shí)現(xiàn)或依賴)。 協(xié)作 協(xié)作由一系列對(duì)象組成,它們通過(guò)合作實(shí)現(xiàn)在應(yīng)用場(chǎng)景下的功能。對(duì)象的協(xié)作可以實(shí)現(xiàn)一個(gè)功能。 通信圖 通信圖是在二維空間里展示所關(guān)注的對(duì)象、對(duì)象間的連接和沿連接實(shí)現(xiàn)的信息在對(duì)象間的交換。通過(guò)把對(duì)象分組和對(duì)象間的合作,盡管對(duì)象的連接是從動(dòng)態(tài)角度出發(fā)的,也可以清晰地看出對(duì)象的結(jié)構(gòu)組織。 模塊 模塊的概念體現(xiàn)在系統(tǒng)劃分和模塊技術(shù)中: * 模塊1是系統(tǒng)的組成部分,也就是劃分的產(chǎn)物。 * 模塊在模塊技術(shù)中表示它是系統(tǒng)模塊化的一部分。模塊功能的具體實(shí)現(xiàn)隱藏在模塊對(duì)外的接口內(nèi)。與類相對(duì)比,調(diào)用模塊的所有方法都必須通過(guò)接口。模塊可以穩(wěn)定地安裝在計(jì)算機(jī)上。模塊在實(shí)際使用中往往包含一個(gè)或多個(gè)類、接口或小的模塊。 模塊模型 模塊模型在軟件技術(shù)中描述的是由模塊組成的系統(tǒng)運(yùn)行時(shí)的框架。模塊模型定義了箱體,單模塊系統(tǒng)在箱體里運(yùn)行(運(yùn)行環(huán)境),同時(shí)還定義了模塊對(duì)箱體的接口和對(duì)其他模塊的接口。對(duì)此已經(jīng)定義了很多模塊的結(jié)構(gòu),比如模型的持久性、安全性和版本管理。 組合 組合是關(guān)聯(lián)的一個(gè)特例,它描述的是整體與其局部的關(guān)系。局部的存在和整體的存在相關(guān)聯(lián),一個(gè)局部只屬于一個(gè)唯一的整體。 具體類 具體類可以實(shí)例化,即具體類可以生成對(duì)象。 構(gòu)造函數(shù) 構(gòu)造函數(shù)是一個(gè)特殊的方法。構(gòu)造函數(shù)與類名相同,在生成對(duì)象時(shí)被調(diào)用,為實(shí)例化服務(wù)。構(gòu)造函數(shù)沒(méi)有返回值類型,而且不能被繼承。 控制對(duì)象 控制對(duì)象并不是現(xiàn)實(shí)世界的實(shí)體?刂茖(duì)象相當(dāng)于一個(gè)流程控制。 生命線 生命線存在于UML的時(shí)序圖和通信圖中。對(duì)象在通信圖中作為對(duì)話者可以在UML中被描述為生命線。在UML的時(shí)序圖和通信圖中的生命線之間可以實(shí)現(xiàn)信息交流。 方法 一個(gè)方法實(shí)現(xiàn)一個(gè)操作。 中間件 中間件是程序的一個(gè)層次,它可以擴(kuò)展延伸到多臺(tái)計(jì)算機(jī),服務(wù)于分布式應(yīng)用的進(jìn)程間通信。中間件還有其他功能,如持久化服務(wù)、信息安全功能或名稱管理。 多重性 多重性是對(duì)集合可能采取的基數(shù)范圍的說(shuō)明。 消息 對(duì)象之間可以通過(guò)消息進(jìn)行溝通,接收者負(fù)責(zé)對(duì)消息進(jìn)行解釋。 導(dǎo)航 通過(guò)導(dǎo)航可以觀察哪些對(duì)象是可以訪問(wèn)的(這些對(duì)象的類之間存在聯(lián)系)。導(dǎo)航就是說(shuō)明連接一端的對(duì)象是否能夠到達(dá)連接另一端的對(duì)象。對(duì)于直接可以導(dǎo)航的就不需要繞路訪問(wèn)了。 并行 如果事件A和B可以互不依賴地獨(dú)自工作,就稱為是并行的。也就是說(shuō),“A先發(fā)生,然后B發(fā)生”和“B先發(fā)生,然后A發(fā)生”是等效的。 注釋 注釋是在UML中對(duì)一個(gè)或者多個(gè)模型元素的注解。 對(duì)象圖 對(duì)象圖顯示的是在一個(gè)特定時(shí)刻對(duì)象和對(duì)象之間的連接。 操作 一個(gè)操作在UML中表達(dá)一個(gè)抽象的方法。它包括名稱、參數(shù)、返回值類型、前置條件、后置條件和操作的詳細(xì)說(shuō)明。一個(gè)操作將會(huì)在一個(gè)類中通過(guò)方法實(shí)現(xiàn)。操作的定義包括操作的名稱,對(duì)應(yīng)于所屬方法的參數(shù)和返回值類型。 在操作的詳細(xì)說(shuō)明中,一般說(shuō)明這個(gè)操作可以在不同的類中實(shí)現(xiàn)。一個(gè)操作通過(guò)詳細(xì)說(shuō)明擁有一個(gè)特殊的含義(語(yǔ)義)。這個(gè)含義對(duì)于所有通過(guò)方法實(shí)現(xiàn)這個(gè)操作的類是相同的。例如,一個(gè)操作可以通過(guò)“給出名稱和屬性值”來(lái)詳細(xì)說(shuō)明。在不同的類里如何用個(gè)數(shù)互不相同的屬性來(lái)實(shí)現(xiàn)。 操作視圖 操作視圖只關(guān)注對(duì)用戶重要的功能,不考慮系統(tǒng)管理員。 包 UML中的包用作對(duì)子包的分組或模型元素的分組,如類、接口、用例等。包可以理解為命名空間,用于訪問(wèn)保護(hù)的單元,使組織結(jié)構(gòu)更加清晰。 面板 面板是一種無(wú)形的對(duì)象容器,可以把圖形組件分成不同的組。 范式 范式是一種思維模式。 持久性 對(duì)象的持久性意味著它的壽命超過(guò)了一個(gè)會(huì)話(session),因?yàn)樗鼈兇鎯?chǔ)在非易失性存儲(chǔ)介質(zhì)(如磁盤)中。 多態(tài)性 多態(tài)性意味著多樣性。例如,一個(gè)子類型的對(duì)象可以看做是它的基類。 協(xié)議 通信雙方進(jìn)行通信的一組規(guī)則。 邊界條件 邊界條件經(jīng)常稱為限制,是必須起作用的條件。它可以正式或非正式地加以描述,可以由相鄰的系統(tǒng)指定。 實(shí)現(xiàn)關(guān)系 實(shí)現(xiàn)關(guān)系是兩個(gè)元素間(按照UML分類)的靜態(tài)關(guān)系。其中一個(gè)元素對(duì)契約進(jìn)行描述,另一個(gè)元素在實(shí)現(xiàn)過(guò)程中必須遵守這個(gè)契約。例如,一個(gè)類實(shí)現(xiàn)一個(gè)接口,在協(xié)作圖中的實(shí)現(xiàn)用例都是實(shí)現(xiàn)關(guān)系。 角色 角色的概念有多重含義: * 角色可以是代理人1。 * 角色可以實(shí)現(xiàn)一個(gè)接口。 在關(guān)聯(lián)和角色設(shè)計(jì)模式中,每一個(gè)對(duì)象可以承載一個(gè)角色。對(duì)象可以實(shí)現(xiàn)角色定義的接口,對(duì)外實(shí)現(xiàn)角色的功能。 接口 接口就是操作的清單。操作可以是一個(gè)類別(類或組件)提供的服務(wù)。一個(gè)接口可以表達(dá)一個(gè)類或組件的所有操作或者一部分操作。實(shí)現(xiàn)接口的類或組件必須遵守接口中對(duì)操作的定義。 自我委托 一個(gè)對(duì)象的方法調(diào)用自己的另外一個(gè)方法。 時(shí)序圖 時(shí)序圖按照時(shí)間順序描述對(duì)象間或?qū)ο笈c角色(系統(tǒng)角色)間信息的交換。 序列化 序列化(或稱為信號(hào)編集)是把方法調(diào)用的變化寫入到信息中。 編程中的簽名和UML中的簽名 簽名的定義在編程和UML中的用法不同: 。1)在UML中:導(dǎo)出接口包括方法名稱、參數(shù)類型列表和返回值類型。 。2)在Java中:導(dǎo)出接口包括方法名稱和參數(shù)類型列表。 會(huì)話(Session) 會(huì)話就是網(wǎng)絡(luò)中兩個(gè)地址化的單位利用建立起的連接進(jìn)行數(shù)據(jù)交換。 涉眾(Stakeholder) 涉眾是對(duì)系統(tǒng)感興趣的自然人、法人或者一組人。這種興趣會(huì)影響到系統(tǒng)的軟件和硬件需求。 結(jié)構(gòu) 系統(tǒng)的結(jié)構(gòu)是其靜態(tài)布局。 子類 參見(jiàn)派生類。 表 表是類似結(jié)構(gòu)的數(shù)據(jù)的綜合。在關(guān)系數(shù)據(jù)庫(kù)中也稱為關(guān)系。 類型 類型有屬性和操作,對(duì)于屬性有取值范圍。 繼承 在面向?qū)ο笾校粋(gè)類可以繼承另外一個(gè)類或者是從一個(gè)類派生出來(lái)。通過(guò)繼承,類自動(dòng)擁有了基類的屬性和方法,就是說(shuō)它繼承了基類的結(jié)構(gòu)和功能。 繼承的層次結(jié)構(gòu) 通過(guò)類之間的繼承關(guān)系,形成了層次結(jié)構(gòu):派生類從屬于基類,或者說(shuō)基類處于派生類的上一級(jí)。 在Java中,所有的類都是從類Object派生出來(lái)的,所以這個(gè)類在Java中處在繼承層次結(jié)構(gòu)的根部。 行為 系統(tǒng)的行為是其功能的表述。 連接 連接是關(guān)聯(lián)的一個(gè)實(shí)例。 使用關(guān)系 人們要表達(dá)一個(gè)元素使用另外一個(gè)元素,可以在UML中通過(guò) use 表明它們的依賴關(guān)系。use關(guān)系就是通常所說(shuō)的使用關(guān)系。使用關(guān)系表明一個(gè)元素的含義(語(yǔ)義)依賴于另外一個(gè)元素的含義(語(yǔ)義)。 狀態(tài)圖 按照Harel 或者Hatley/Pirbhai的理論,UML的狀態(tài)圖是狀態(tài)轉(zhuǎn)化圖的一個(gè)變形。狀態(tài)圖由要詳細(xì)描述的類元的狀態(tài)(可能是區(qū)域1性的)和轉(zhuǎn)移組成。狀態(tài)可以是延遲、進(jìn)入行為、退出行為和狀態(tài)行為。轉(zhuǎn)移描述引起狀態(tài)變化的事件、條件以及類元在轉(zhuǎn)化過(guò)程中的行為。在給反應(yīng)式系統(tǒng)(reactive system)建模時(shí)需要狀態(tài)圖。 狀態(tài)轉(zhuǎn)化圖 按照Harel 或者Hatley/Pirbhai的理論,在狀態(tài)轉(zhuǎn)化圖中系統(tǒng)的狀態(tài)在建模時(shí)以圖形化表示。圖形借助于狀態(tài)和轉(zhuǎn)移(狀態(tài)的變化)描述了一個(gè)自動(dòng)裝置。轉(zhuǎn)移詳細(xì)說(shuō)明了觸發(fā)事件、狀態(tài)變化的條件以及由狀態(tài)變化引起的行動(dòng)。 第1章 面向?qū)ο笤O(shè)計(jì)的原理 1 第3章 軟件設(shè)計(jì)的模式 軟件開(kāi)發(fā)過(guò)程中的每一步都有對(duì)應(yīng)的模式:用于系統(tǒng)分析的模式、系統(tǒng)設(shè)計(jì)模式、編程模式和測(cè)試模式。對(duì)于特殊的任務(wù)也有模式,比如對(duì)設(shè)計(jì)圖形界面或者與數(shù)據(jù)庫(kù)的數(shù)據(jù)交換。 本書專注于軟件設(shè)計(jì)中的模式。這里要注意它們的區(qū)別: * 架構(gòu)模式(architectural patterns)。 * 設(shè)計(jì)模式(design patterns)。 確定架構(gòu)模式和設(shè)計(jì)模式的界限參見(jiàn)3.3節(jié)。 用于設(shè)計(jì)的模式是已經(jīng)經(jīng)過(guò)證實(shí)的可用于解決一些特定問(wèn)題的參考答案。在設(shè)計(jì)系統(tǒng)時(shí)要考慮使用模式,因?yàn)樗鼈兌际且呀?jīng)在多個(gè)系統(tǒng)中被證明過(guò)的。 設(shè)計(jì)階段的模式起源于架構(gòu)師Christopher Alexander1。他在20世紀(jì)70年代整理總結(jié)了一套城市建設(shè)的模式。Christopher Alexander認(rèn)識(shí)到,建筑或者整條街道雖然可能包括相同的元素,但是完全可以按照不同的模式建造。換句話說(shuō),他通過(guò)元素和它們之間典型的關(guān)系可以辨別模式。 “……除了元素之外,每個(gè)建筑都是由元素之間的關(guān)系組成的一定模式定義的……” [Ale77] 在城市建筑學(xué)中,模式是一個(gè)具有開(kāi)創(chuàng)性意義的理念。但是它在建筑學(xué)中的流行和認(rèn)可的程度遠(yuǎn)遠(yuǎn)不如在軟件開(kāi)發(fā)領(lǐng)域。 模式對(duì)系統(tǒng)設(shè)計(jì)起到了重要的貢獻(xiàn),它促使軟件開(kāi)發(fā)在走向成熟的工程技術(shù)的道路上邁出了重要的一步。模式基本上是不依靠任何平臺(tái),不被限制于一種固定的編程語(yǔ)言。被命名的模式擴(kuò)展了專業(yè)技術(shù)語(yǔ)言,受過(guò)訓(xùn)練的開(kāi)發(fā)人員可以在一個(gè)更高的抽象層次中理解一個(gè)問(wèn)題和答案。 模式經(jīng)常要和抽象結(jié)合,它是一個(gè)抽象類或者接口的符號(hào)。真實(shí)的類是派生類,模式并不知道派生類,它們是由使用模式的用戶定義的。它們或者在編譯時(shí)出現(xiàn)在以具體類為基礎(chǔ)的模式中,或者是在運(yùn)行時(shí)在面向?qū)ο竽J街刑娲J街械某橄? 部分。 為了使模式可以供其他開(kāi)發(fā)者使用,必須做好文檔工作。模式不是發(fā)明出來(lái)的,而是在實(shí)際應(yīng)用中因?yàn)榭梢越鉀Q典型的問(wèn)題而被發(fā)現(xiàn)出來(lái)的方法,它們可以在很多實(shí)際應(yīng)用中使用。 3.1節(jié)研究在軟件設(shè)計(jì)中模式的使用。3.2節(jié)描述在軟件設(shè)計(jì)中模式的屬性和它的設(shè)計(jì)。3.3節(jié)確定架構(gòu)模式、設(shè)計(jì)模式和慣用法相互的界限。在3.4節(jié)中介紹模板,本書中利用這個(gè)模板介紹如何給模式做文檔。 3.1 模式的使用 軟件設(shè)計(jì)中模式的主要目標(biāo)是通過(guò)再次使用已經(jīng)獲得的經(jīng)驗(yàn)提高架構(gòu)的靈 活性。 大部分系統(tǒng)設(shè)計(jì)中包含很多模式,僅僅通過(guò)這個(gè)特征還不能判斷這是一個(gè)好的設(shè)計(jì)。 這里Christopher Alexander使用了適當(dāng)?shù)恼Z(yǔ)言:“建筑可能是通過(guò)松散排列的模式建造的。這樣的建筑只能體現(xiàn)出模式的聚集,并不具有內(nèi)部的一致性,它沒(méi)有真正的核心。還有一種模式結(jié)合的方式就是在同一空間的多模式疊加。這樣的建筑具有內(nèi)部的一致性,它把很多的含義包含在一個(gè)小的空間里。通過(guò)這種內(nèi)部的凝聚力使它具有核心力!币粋(gè)好的設(shè)計(jì)的形成,需要多個(gè)模式相互間完美地組合,形成疊加效應(yīng)。 只有在真正有意義的時(shí)候才可以使用模式。在使用模式之前,一定要仔細(xì)考慮要使用的模式是否適合解決這個(gè)問(wèn)題,使用之后會(huì)產(chǎn)生什么樣的結(jié)果。 從開(kāi)發(fā)者的角度認(rèn)為模式具有一定的安全性。這種安全性是建立在事實(shí)的基礎(chǔ)上的,是前人經(jīng)過(guò)應(yīng)用已經(jīng)得到證實(shí)的結(jié)果。然而這容易形成誤導(dǎo),認(rèn)為在任何情況下使用模式都是正確的選擇。單純使用模式并不能保證對(duì)于設(shè)計(jì)中出現(xiàn)的具體問(wèn)題是有意義的。 在以對(duì)象為基礎(chǔ)的模式中委托原則經(jīng)常起到重要的作用。委托一個(gè)用于接收信息的對(duì)象,消息可以繼續(xù)傳遞給 * 接收信息的對(duì)象所聚集的部分對(duì)象; * 或者是在運(yùn)行時(shí)實(shí)現(xiàn)一個(gè)抽象(接口或抽象類)的對(duì)象(這個(gè)抽象是由接收信息的對(duì)象實(shí)現(xiàn)的)。 使用任何形式的委托或者抽象,其代價(jià)都是降低系統(tǒng)的性能。額外增加的層次總是和降低系統(tǒng)的性能相聯(lián)系的。 如果要求系統(tǒng)具有擴(kuò)展性,那么模式的使用具有優(yōu)勢(shì)。但是如果首先是對(duì)系統(tǒng)性能的要求,系統(tǒng)的可修改性沒(méi)有重要作用時(shí),使用模式就要仔細(xì)考慮。 盡管使用模式可以提高架構(gòu)的可擴(kuò)展性,但是同時(shí)也增加了架構(gòu)的復(fù)雜度。 為了保證可擴(kuò)展性,可能會(huì)生成新的類和操作,或者是新的類和類之間的關(guān)系。這種復(fù)雜度會(huì)降低系統(tǒng)的性能,在這種情況下,復(fù)雜度所帶來(lái)的優(yōu)點(diǎn)并不能抵消性能降低的不足。 如果系統(tǒng)需要靈活性是推測(cè)的,即目前還不清楚系統(tǒng)將來(lái)是否需要,那么就應(yīng)該“只保持必要的靈活性,越少越好”。 本書關(guān)于模式的介紹,其核心是解釋如何解決問(wèn)題。然而,這個(gè)問(wèn)題的實(shí)質(zhì)是什么時(shí)候適合使用模式。這個(gè)問(wèn)題往往被忽視了。也許沒(méi)有已知的模式可以達(dá)到預(yù)期的目標(biāo)。 尋找解決具體設(shè)計(jì)問(wèn)題的方法是艱難的,人們必須仔細(xì)研究待解決的問(wèn)題,比較有關(guān)模式的性能。 3.2 模式的屬性和它的設(shè)計(jì) 模式的目標(biāo)就是提高架構(gòu)的屬性。例如屬性包括下面兩點(diǎn): * 可理解性; * 可擴(kuò)展性。 可理解性可以通過(guò)簡(jiǎn)易性達(dá)到,即通過(guò)為每個(gè)模式提供簡(jiǎn)易的結(jié)構(gòu)化的全面文檔?蓴U(kuò)展性可以通過(guò)以下兩點(diǎn)實(shí)現(xiàn): * 靜態(tài)繼承。 * 使用聚合接口2或者是抽象類。 面向?qū)ο竽J綕M足以下設(shè)計(jì)原則: * 松耦合性系統(tǒng)(詳見(jiàn)1.5節(jié)),組件的松耦合性。 * 抽象(詳見(jiàn)1.2節(jié)),通過(guò)泛化、接口或者抽象類。 * 信息隱藏(詳見(jiàn)1.2節(jié)),通過(guò)隱藏程序?qū)崿F(xiàn)的部分。 * 明確的職責(zé)(詳見(jiàn)1.3節(jié)),通過(guò)角色安排。 * 依賴倒置原則,高層的類不依賴于低層的類。 這里需要強(qiáng)調(diào)的是有時(shí)候需要為非面向?qū)ο笙到y(tǒng)制定模式。這樣的模式不需要繼承和多態(tài)[Bus98,24頁(yè)]。模式不一定都是面向?qū)ο蟮。本書中所介紹的設(shè)計(jì)模式都是以面向?qū)ο鬄榛A(chǔ)的。 人們想到面向?qū)ο髸r(shí),總會(huì)認(rèn)為是通過(guò)泛化達(dá)到盡可能高的抽象,換句話說(shuō),就是找到它的基類,通過(guò)細(xì)分得到不同的變化。 因此一些模式就設(shè)計(jì)成以抽象類為基類,還有一些模式使用接口。人們更偏愛(ài)于使用接口,有兩個(gè)原因: 。1)在一些編程語(yǔ)言中,例如Java,接口允許多重繼承,抽象基類則不允許。 (2)抽象基類可以包含抽象操作,也可以包含已經(jīng)完成的操作。接口則只能包含抽象操作,這樣更讓人一目了然。 接口優(yōu)于抽象類,但這并不總是成立的。如果人們?cè)诿總(gè)實(shí)現(xiàn)類中都必須實(shí)現(xiàn)一個(gè)聚集或者默認(rèn)實(shí)現(xiàn),這種情況就應(yīng)該使用抽象類。 3.3 架構(gòu)模式、設(shè)計(jì)模式和慣用法的界限。 ……
你還可能感興趣
我要評(píng)論
|