【正文】 根。Application）能夠進(jìn)行互操作SF體系結(jié)構(gòu)（ 5）? 核心商業(yè)過(guò)程 (CBPs)層是 SF的頂層，提供了通用的商業(yè)過(guò)程，而且提供了基于 CBOs和 Foundation層的擴(kuò)展機(jī)制? CBP層的目的：– 創(chuàng)建一個(gè)良好的面向?qū)ο蟮捏w系結(jié)構(gòu)和一個(gè)易于擴(kuò)展的具有基礎(chǔ)應(yīng)用結(jié)構(gòu)和行為的實(shí)現(xiàn)– 在基礎(chǔ)應(yīng)用結(jié)構(gòu)和行為之上，提供一組有限的應(yīng)用功能。Objects）? 在描述商業(yè)活動(dòng)時(shí)常使用的概念和實(shí)體– 公共商業(yè)服務(wù)– 設(shè)計(jì)模式（ DesignProcesses,Business? 面向?qū)ο蠹夹g(shù)– 封裝了復(fù)雜的變化性，使得應(yīng)用系統(tǒng)可以使得應(yīng)用可以很容易得隨著需求的變化而改變，更易于維護(hù)和演化? 跨平臺(tái)– 通過(guò) JAVA的虛擬機(jī) ,SF實(shí)現(xiàn)了與操作系統(tǒng)隔離，獲得平臺(tái)獨(dú)立性? 商業(yè)應(yīng)用框架– 商用應(yīng)用框架是一些代表商業(yè)實(shí)體的類，它們相互協(xié)作實(shí)現(xiàn)核心商業(yè)過(guò)程。ofinfrastructureFrancisco（簡(jiǎn)稱 SF）是 IBM網(wǎng)絡(luò)領(lǐng)域解決方案系列產(chǎn)品中的戰(zhàn)略性產(chǎn)品? 它是一個(gè)基于 Java的構(gòu)件集，使得開(kāi)發(fā)者不再?gòu)淖畹讓娱_(kāi)始構(gòu)造商業(yè)應(yīng)用系統(tǒng)，而是利用已經(jīng)有的構(gòu)件對(duì)服務(wù)器端的商業(yè)應(yīng)用系統(tǒng)進(jìn)行開(kāi)發(fā)? 同時(shí)，應(yīng)用系統(tǒng)只需要一次開(kāi)發(fā)就可以在包括 Windows每個(gè)特定于客戶程序的接口僅僅聲明它的特定客戶或客戶組調(diào)用的那些函數(shù)，接著該胖類就可以繼承所有特定于客戶程序的接口，并實(shí)現(xiàn)它們。3）使用多繼承 分離接口下圖給出使用多繼承并達(dá)到遵循 ISP的方案 :Timer 《 Interface》 Timer Client+TimeoutDoorTimedDoor +DoorTimeOut0..*其中 ,在這個(gè)模型中 , TimedDoor同時(shí)繼承了Door和 ,盡管這 2個(gè)基類的客戶程序都可以使用 TimedDoor,但在實(shí) ,它們就通過(guò)分離的接口使 用同一對(duì)象 .比較 : 就這一問(wèn)題的 2),3)方案而言 , 只有當(dāng) Door Timer Adapter對(duì)象所做的轉(zhuǎn)換是必須的 ,或不同時(shí)候回需要不同轉(zhuǎn)換時(shí) ,才會(huì)選擇 2)中給出的方案 .結(jié)論 胖類可以導(dǎo)致它們的客戶程序之間產(chǎn)生不正常的、且有害的耦合關(guān)系。 }。原因是客戶程序?qū)λ鼈兪褂玫慕涌谑怯杏绊懙?。這是一個(gè)接口污染問(wèn)題： 1） Door的接口被一個(gè)它不需要的方法污染了 在 Door的接口中加入這個(gè)方法只是為了給它的子類帶來(lái)好處。 該方案的主要問(wèn)題就出現(xiàn)在這里。? 即如果希望得到超時(shí)時(shí)間，就可以調(diào)用 Timer的 Register函數(shù) ,該函數(shù)有 2個(gè)參數(shù)：一個(gè)是超時(shí)時(shí)間，另一個(gè)是 TimerClient對(duì)象的指針，該對(duì)象的 TimeOut函數(shù)會(huì)在達(dá)到超時(shí)時(shí)予以調(diào)用。virtualvoid{class– 何謂胖接口？如果類的接口不是內(nèi)聚的，則稱該接口是胖接口。同時(shí)對(duì)建造具有彈性的代碼（應(yīng)對(duì)變化）是非常重要的。– 面向?qū)ο蟪绦蛟O(shè)計(jì)倒置了依賴關(guān)系的結(jié)構(gòu)，是策略和細(xì)節(jié)都依賴抽象，并且通常是客戶的服務(wù)接口。但問(wèn)題是 Lamp可能還受其他類的控制。它是系統(tǒng)內(nèi)部的系統(tǒng) 隱喻 (metaphore)Button+poll()《 interface》ButtonServer+turnOn() + turnOff() Lamp通過(guò)倒置對(duì) Lamp的依賴關(guān)系，可以形成以上的設(shè)計(jì)。其中， Button類直接依賴 Lamp對(duì)象，這個(gè)設(shè)計(jì)不能讓 Button控制其它設(shè)備。這說(shuō)明對(duì)那些穩(wěn)定的具體類而言，啟發(fā)式規(guī)則似乎不大合理。– 根據(jù)這個(gè)啟發(fā)式規(guī)則，可知：? 任何變量都不應(yīng)該持有一個(gè)指向具體類的指針或引用；? 任何類都不應(yīng)該從具體類派生；? 任何方法都不應(yīng)該覆寫(xiě)它的任何基類中已實(shí)現(xiàn)的方法。call原則 “Don’t （ 2）這種依賴是可傳遞的。– 抽象不應(yīng)該依賴細(xì)節(jié)。– “isA”的含義過(guò)于寬泛，以至于不能作為子類型的定義。– 在派生類的方法中填加了其基類不能割舍的異常? 結(jié)論：– LSP是使 OCP成為可能的主要原因之一。Square類和 Circle類不能替換 Shape， 這違反了 LSP， 從而使 DrawShape違反了 OCP。Shape}? 顯然，該程序中的 DrawShape函數(shù)違反了 OCP– 它必須知道 Shape類所有的派生類，且每次創(chuàng)建一個(gè) Shape的派生類都必須要更改它。elseSquare(s).Draw()。(==Shape::square)ShapeDraw()Square:publicDraw()Circle():Shape(Circle)}。Shape(ShapeType{{x,y。語(yǔ)句或 if/else來(lái)確定一個(gè)對(duì)象的類型，以便可以選擇該類型的正確行為。? 顯然， D對(duì)于 f來(lái)說(shuō)是脆弱的?！薄叭魧?duì)每個(gè)類型 S的對(duì)象 o1,? 以上正是 LSP原則要回答的問(wèn)題。Liskov替換原則 ( LSP)? 在 C++和 Java這類語(yǔ)言中，支持抽象和多態(tài)的關(guān)鍵機(jī)制是繼承（ inheritance）。– 不是使用了面向?qū)ο笳Z(yǔ)言就是遵循了這一原則。核心。 以上兩個(gè)模式是滿足 OCP原則最常用的方法。不同的是，在這個(gè)結(jié)構(gòu)中，這些抽象接口是 Policy 類的一部分。 ClientInterface的子類型可以以任何方式來(lái)實(shí)現(xiàn)這個(gè)接口。– 例如， Client ServerClient類是既不開(kāi)放又不封閉的類 （ 其中， Client 類和 Server類都是具體類）? 實(shí)現(xiàn) OCP的一種結(jié)構(gòu)：Client 《 interface》 Client InterfaceServerSTRATEGY模式：既開(kāi)放又封閉的 Client 其中， ClientInterface類是一個(gè)擁有抽象成員的抽象類。? 怎樣才能做到看起來(lái)似乎矛盾的以上兩點(diǎn)？– 關(guān)鍵的是抽象！– 不允許修改的模塊，通常被認(rèn)為是具有 “固定 ”行為的模塊。模塊的二進(jìn)制可執(zhí)行版本，無(wú)論是可鏈接的 forextention）? 這意味著模塊的行為是可以擴(kuò)展的。Jacobson曾經(jīng)說(shuō)過(guò)： “任何系統(tǒng)在其生存周期中都會(huì) 美國(guó)英語(yǔ)傳統(tǒng)字典，第 4版， 2023年? 內(nèi)容：軟件實(shí)體（類、模塊、函數(shù)等）應(yīng)該是可擴(kuò)展的，但是不可修改的。開(kāi)放 封閉原則 (The OpenClosed Principle,OCP)? 兩截門(mén)（ DutchPROXY模式對(duì)設(shè)計(jì)進(jìn)行重構(gòu)，分離這 2種職責(zé)。因?yàn)闃I(yè)務(wù)規(guī)則往往會(huì)不斷的變化，并且變化的原因也各不相同。除了 main外，誰(shuí)也不知道它的存在。那么調(diào)用 send和 recv就必須重新編譯，因此應(yīng)分離這兩種職責(zé)。recv(char)。publicvoidvoid(charvoid(string{例如：– of它變化的原因，這條原則被稱為內(nèi)聚性原則。– 子類重構(gòu)：將一個(gè)復(fù)雜的類分解成幾個(gè)小一點(diǎn)的具體類和一個(gè)表達(dá)抽象的基類 CookMacAppService機(jī)制擴(kuò)展點(diǎn) ——CBF腳本 消息機(jī)制Web Services容器小結(jié) ——OOF 和 CBF的不同? 面向?qū)ο罂蚣塄C 機(jī)制：面向?qū)ο蠹夹g(shù)的多態(tài)和繼承機(jī)制– 復(fù)用方式：通過(guò)繼承框架中的抽象類來(lái)完成特定行為的定制，白盒復(fù)用– 問(wèn)題：框架的過(guò)度增值、脆弱的基類和隱式體系結(jié)構(gòu)? 基于構(gòu)件的框架– 機(jī)制：構(gòu)件接口調(diào)用、構(gòu)件組裝等– 復(fù)用方式：通過(guò)一些集成機(jī)制得到對(duì)象或者構(gòu)件的不同組裝，來(lái)定義特定行為的，黑盒復(fù)用框架描述語(yǔ)言（ 1/6）? 框架文檔必須包含的內(nèi)容– 框架的目的? 明確框架針對(duì)的問(wèn)題域，以及框架為問(wèn)題域的哪些問(wèn)題提供了解決方案– 如何使用框架? 框架得到正確使用并發(fā)揮最優(yōu)效果的關(guān)鍵所在– 應(yīng)用實(shí)例? 閱讀實(shí)例是理解框架主要結(jié)構(gòu)的方法? 框架使用者可以從一組實(shí)例中看出框架的邊界和不足– 框架的設(shè)計(jì)描述? 表達(dá)框架的整體體系結(jié)構(gòu)和擴(kuò)展點(diǎn)的設(shè)計(jì)細(xì)節(jié)框架描述語(yǔ)言（ 2/6）? CookVariability):這些變化性之間不存在互斥的關(guān)系，可以同時(shí)存在? 變化性維度– 組織機(jī)構(gòu)、數(shù)據(jù)、功能、過(guò)程 —— 問(wèn)題域– 實(shí)現(xiàn)技術(shù) —— 解空間擴(kuò)展點(diǎn)（ 1/3）? 為什么需要擴(kuò)展點(diǎn)– 支持應(yīng)用領(lǐng)域的變化性– 提高框架的靈活性– 提高框架的可復(fù)用性? 什么是擴(kuò)展點(diǎn)– 擴(kuò)展點(diǎn)是軟件框架中針對(duì)應(yīng)用需求的、支持適應(yīng)性變更的的擴(kuò)展機(jī)制– 擴(kuò)展點(diǎn)是定義良好的框架特性，可以通過(guò)特例化或者組裝等擴(kuò)展機(jī)制來(lái)滿足特定應(yīng)用的需求擴(kuò)展點(diǎn) ——OOF? 面向?qū)ο罂蚣苤兄饕褂靡韵录夹g(shù)實(shí)現(xiàn)擴(kuò)展功能– 繼承– 組合– 委托– 參數(shù)化 應(yīng)用程序框架構(gòu)件 構(gòu)件構(gòu)件 構(gòu)件 構(gòu)件 構(gòu)件 構(gòu)件領(lǐng)域不變部分 可變部分內(nèi)容1. 軟件框架概念2. 軟件框架構(gòu)造技術(shù)3. 實(shí)例研究 ——San框架的分類? 框架的分類– 根據(jù)應(yīng)用范圍分類? 基礎(chǔ)設(shè)施框架： GUI框架、語(yǔ)言處理框架 …? 中間件集成框架： ORB框架、消息中間件 …? 企業(yè)應(yīng)用框架： San95]軟件框架的概念 (續(xù) )? 框架反映了一個(gè)領(lǐng)域內(nèi)應(yīng)用的軟件體系結(jié)構(gòu)，包括其組成成分、關(guān)系以及約束? 框架同時(shí)定義了針對(duì)特定的功能需要在哪里進(jìn)行調(diào)整和修改?因此，軟件 框架? 1.88]– 定義 696]– 定義 5框架是指一個(gè)部分完成的軟件（子）系統(tǒng)，它將要被進(jìn)一步實(shí)例化?？蚣苁且环N微體系結(jié)構(gòu)，為特定領(lǐng)域內(nèi)的軟件系統(tǒng)提供未完全實(shí)現(xiàn)的模板。 [楊芙清， 97]– 定義 2Francisco等等? 許多學(xué)者，包括 Johnson,system,User軟件體系結(jié)構(gòu)(Software Architecture)講義九：軟件框架構(gòu)造技術(shù)及案例分析內(nèi) 容1. 軟件框架概述2. 軟件框架研究現(xiàn)狀3. 實(shí)例研究 ——SanInc.alarm(IBM)San一個(gè)框架由一組協(xié)作類組成，闡明了整個(gè)設(shè)計(jì)、類間依賴及成員類的責(zé)任分布。94]– 定義 399]– 定義 4 [Buschmann,Foot, [Gamma,是一個(gè)部分完成的軟件（子）系統(tǒng)，它將要被進(jìn)一步實(shí)例化。– 框架與構(gòu)件庫(kù)的區(qū)別? 框架不僅僅是類的簡(jiǎn)單集合，而且定義了一個(gè)領(lǐng)域通用的高層設(shè)計(jì)? 構(gòu)件庫(kù)的結(jié)構(gòu)建立于構(gòu)件分類基礎(chǔ)之上，而框架則直接反映了問(wèn)題域的結(jié)構(gòu)相關(guān)概念? 框架和體系結(jié)構(gòu)– 框架決定了應(yīng)用系統(tǒng)的體系結(jié)構(gòu)– 一個(gè)框架可以被實(shí)例化成為多個(gè)應(yīng)用系統(tǒng)，每個(gè)應(yīng)用系統(tǒng)具有特定的體系結(jié)構(gòu)，因此框架從框架使用的角度來(lái)看，框架和體系結(jié)構(gòu)之間存在著 1對(duì)多 (1:N)的關(guān)系– 從框架開(kāi)發(fā)的角度來(lái)看，框架反映了一個(gè)領(lǐng)域的體系結(jié)構(gòu)（DSSA），它是 DSSA的一個(gè)實(shí)例，因此， DSSA和框架之間同樣存在著 1對(duì)多 (1:N)的關(guān)系– 從在軟件開(kāi)發(fā)過(guò)程中所起的作用而言，? 體系結(jié)構(gòu)是軟件的高層設(shè)計(jì)抽象，它有助于系統(tǒng)開(kāi)發(fā)團(tuán)隊(duì)之間的交流? DSSA是可以視為 “參考 ”體系結(jié)構(gòu)，對(duì)于領(lǐng)域內(nèi)應(yīng)用系統(tǒng)體系結(jié)構(gòu)的設(shè)計(jì)具有指導(dǎo)意義? 而開(kāi)發(fā)框架最重要的目的則是針對(duì)特定領(lǐng)域的設(shè)計(jì)和代碼復(fù)用相關(guān)概念? 應(yīng)用體系結(jié)構(gòu)、 DSSAApplication(N)Architecture(N)DSSA(1)Framework111n 實(shí)例化領(lǐng)域工程n1n1相關(guān)概念? 框架和軟件開(kāi)發(fā)過(guò)程– 框架在整個(gè)軟件開(kāi)發(fā)過(guò)程中屬于資產(chǎn)庫(kù)建設(shè)的范疇，是領(lǐng)域設(shè)計(jì)和領(lǐng)域?qū)崿F(xiàn)的重要制品之一– 基于框架的軟件開(kāi)發(fā)活動(dòng)可以分為? 框架的設(shè)計(jì)和開(kāi)發(fā) —— 框架開(kāi)發(fā)階段? 基于框架定制應(yīng)用系統(tǒng) —— 框架使用階段? 框架演化和維護(hù)階段– 設(shè)計(jì)和開(kāi)發(fā)一個(gè)框架成本高，但是通過(guò)復(fù)用帶來(lái)的效益也更加顯著– 框架本身是可復(fù)用資產(chǎn)，也有助于實(shí)現(xiàn)擴(kuò)展部分的復(fù)用相關(guān)概念? 框架和設(shè)計(jì)模式– 從粒度上看，設(shè)計(jì)模式要小于框架，一個(gè)框架可以包括多個(gè)設(shè)計(jì)模式，但是設(shè)計(jì)模式不可能包括框架– 框架要比設(shè)計(jì)模式更加特化，框架總是與特定的應(yīng)用領(lǐng)域相關(guān)，而通常設(shè)計(jì)模式更加普通，可以應(yīng)用任何的應(yīng)用領(lǐng)域– 框架的設(shè)計(jì)、實(shí)現(xiàn)以及描述利用了設(shè)計(jì)模式相關(guān)概念? 框架