1、第三部分是迭代1基礎(chǔ)(3)、主要內(nèi)容、第17章基于GRASP角色的設(shè)計(jì)對象第18章使用GRASP的對象設(shè)計(jì)示例、第17章GRASP:基于角色的設(shè)計(jì)對象、引言GRASP模型是幫助您理解詳細(xì)原則和必要思維方式的學(xué)習(xí)工具。這些模型和相關(guān)類Grasp:General Responsibility Assignment Software Pattern Grasp的核心是做自己能做的事，只做自己的事。17.1 UML和設(shè)計(jì)原則，最重要的軟件開發(fā)工具是UML或其他技術(shù)，17.2對象設(shè)計(jì)：輸入、活動、輸出示例、輸入、對象設(shè)計(jì)活動的創(chuàng)造性，最困難的部分建模。使用各種OO設(shè)計(jì)原則將角色對象設(shè)計(jì)的輸出分配給協(xié)作對

2、象。UML交互圖表、類圖表和包圖表UI中的草圖和原型數(shù)據(jù)庫模型報(bào)告的草圖和原型、17.3角色和以角色為中心的設(shè)計(jì)，角色：類元素的合同或義務(wù)對象的行為角色3360自行執(zhí)行某些行為。例如，您可以創(chuàng)建對象、初始化其他對象的動作控制或調(diào)整其他對象的活動。例如，Sale負(fù)責(zé)識別SalesLineItem對象，負(fù)責(zé)識別個(gè)人包數(shù)據(jù)的識別相關(guān)對象，即識別或計(jì)算Sale牙齒總額。角色經(jīng)常受到變化的影響。解決方案分配角色保持高耐受性。例如，必須創(chuàng)建(cash) Payment的實(shí)例，以將Sale與解決方案1相關(guān)聯(lián)。如果有50個(gè)系統(tǒng)任務(wù)，則必須從Register接收。Register被編排為“非對稱”和“非集合”對

3、象，以完成與每個(gè)作業(yè)相關(guān)的任務(wù)。解決方案2，支持高內(nèi)部聚合，支持低耦合，討論。這是必須時(shí)刻牢記的原則。高聚集類(如低耦合模式)通常方法少，具有高相關(guān)功能，不執(zhí)行太多任務(wù)。另一個(gè)經(jīng)典原則：模塊化設(shè)計(jì)、模塊化是將系統(tǒng)分解為一個(gè)組，在基本對象級別，為每個(gè)方法設(shè)計(jì)明確的個(gè)別目標(biāo)，并將相關(guān)興趣集放在一個(gè)類中，用于模塊、內(nèi)聚和組合。也就是說，請考慮GUI窗口小部件類的方法。即繪制窗口以在數(shù)據(jù)庫中存儲數(shù)據(jù)以調(diào)用遠(yuǎn)程對象服務(wù)非聚合的方法：、但是，將SQL語句分開并合并到一個(gè)類中更合理。因?yàn)樾枰猄QL專家專門處理的特殊技術(shù)。要提高分布式應(yīng)用程序中的性能，可以設(shè)置遠(yuǎn)程操作setData，而不是單獨(dú)設(shè)置setNam

4、e、setSalary和setHireDate。使用第18個(gè)GRASP的對象設(shè)計(jì)示例、18.1用例實(shí)現(xiàn)、用例實(shí)現(xiàn)(use-case reedate) UML圖是描述用例實(shí)現(xiàn)的常用語言?？梢詫ο笤O(shè)計(jì)的原則和模式應(yīng)用于用例實(shí)現(xiàn)的設(shè)計(jì)工作。18.2產(chǎn)品說明、SSD、系統(tǒng)操作、交互圖和用例實(shí)現(xiàn)如果使用考慮“銷售處理”用例的SSD確定的系統(tǒng)操作和方案makenew sale Enter Indsale Make Payment通信圖描述用例實(shí)現(xiàn)，則繪制表示每個(gè)系統(tǒng)操作消息的處理的徐璐其他通信圖。順序圖也是如此。，通信圖用于顯示用例實(shí)現(xiàn)，順序圖用于顯示用例實(shí)現(xiàn)、用例和用例實(shí)現(xiàn)，用例是用例實(shí)現(xiàn)的第一輸入點(diǎn)

5、。請記住，記錄的要求不完整，以便客戶盡可能參與實(shí)施項(xiàng)目的整個(gè)過程、操作協(xié)議和使用案例。在用例的文本中直接設(shè)計(jì)用例實(shí)現(xiàn)可以用于某些復(fù)雜的系統(tǒng)任務(wù)。合同詳細(xì)說明合同CO2: enterItem操作： enterItem(Itemid 3360 Itemid，Quantity 3360 Integer)交叉參考3360用例：處理銷售前提條件：可用于增加處理中的銷售。后期條件：創(chuàng)建SalesLineItem的實(shí)例SLI。針對每份合同，根據(jù)對相關(guān)用例文本的思考，完成后期條件的狀態(tài)更改，設(shè)計(jì)符合要求的消息交互。區(qū)域模型和用例實(shí)現(xiàn)，選擇適當(dāng)?shù)呢?zé)任分配取決于區(qū)域模型，但用例實(shí)現(xiàn)可能導(dǎo)致區(qū)域模型的修改概念。設(shè)計(jì)

6、類域模型可用于在設(shè)計(jì)模型中定義軟件類，并相應(yīng)地命名設(shè)計(jì)類。應(yīng)該源于概念嗎？完全不是。發(fā)現(xiàn)初期缺失的新概念往往修飾軟件類，名稱和目的與域模型完全無關(guān)。18.3下一步工作，詳細(xì)討論NextGen POS。還詳細(xì)討論了單極案例研究。18.4 NextGen迭代的用例實(shí)現(xiàn)，初始和“開始”用例開始用例實(shí)現(xiàn)是考慮創(chuàng)建大部分“根”或壽命較長的對象的設(shè)計(jì)上下文。說明：編碼時(shí)，首先要考慮編寫開始初始化的程序。在進(jìn)行OO設(shè)計(jì)建模時(shí)，建議您最后開始初始化，直到發(fā)現(xiàn)過程中確實(shí)有需要?jiǎng)?chuàng)建和初始化的東西。(約翰f肯尼迪，美國電視電視劇(Northern Exposure)，在設(shè)計(jì)開始之前討論如何處理銷售用例實(shí)現(xiàn)。make

7、NewSale makeNewSale系統(tǒng)操作發(fā)生在收銀員在顧客到達(dá)后買東西和開始新買賣的時(shí)候。選擇控制類，然后根據(jù)控制器模式選擇選擇：在設(shè)計(jì)模型中，Register是一個(gè)。不是實(shí)際的物理計(jì)算臺，而是軟件抽象。選擇牙齒名稱可以縮小區(qū)域和軟件概念之間的表達(dá)差距。系統(tǒng)操作較少，Register可以滿足要求。必須創(chuàng)建新的Sale，軟件對象Sale必須創(chuàng)建： Creator方案。誰來制作它？登記記錄(或登記)登記冊帳戶信息(如銷售)。Register在記錄Sale的類Register中創(chuàng)建，然后關(guān)聯(lián)。如果生成了Sale牙齒，則必須創(chuàng)建一個(gè)空集合，以記錄將來添加的所有SalesLineItem實(shí)例。Re

8、gister創(chuàng)建Sale，Sale創(chuàng)建空集合。enteritem設(shè)計(jì)方法，enteritem系統(tǒng)操作在計(jì)算人員輸入購買商品的itemID和數(shù)量(可選)時(shí)發(fā)生。合同CO2: enterItem操作： enterItem、enterItem 3360 itemid、Quantity: integer交叉參考3360使用案例：銷售前提條件處理：正在進(jìn)行的銷售后綴條件： salessQuantity數(shù)字quantity(修改屬性)將Sli連接到產(chǎn)品規(guī)格(形成連接)、選擇控制類、處理系統(tǒng)操作消息enterItem的責(zé)任、使用控制器模式將寄存器繼續(xù)用作控制器(與makeNewSale類似)、商品項(xiàng)目說明以

9、及是否顯示價(jià)錢的使用案例說明在操作后顯示說明和價(jià)錢標(biāo)記在區(qū)域模型中，Sale包含SaleLineItem對象。因此，軟件Sale也包含軟件SalesLineItem牙齒。通過Creator模式將makeLineItem消息發(fā)送到Sale以創(chuàng)建SaleLineItem。包含MakeLineItem郵件參數(shù)Quantity。因此，SaleLineItem可以記錄牙齒值，而SaleLineItem還必須記錄與productDescription匹配的itemID值。ProductDescription查找，sales lineitem嘗試與與傳入的itemID匹配的ProductDescriptio

10、n建立連接。也就是說，必須根據(jù)itemID匹配返回product description。信息專家模型：表示擁有完成責(zé)任所需信息的對象應(yīng)承擔(dān)上述責(zé)任。誰知道所有產(chǎn)品說明對象？根據(jù)區(qū)域模型，ProductCatalog邏輯包含所有product description . product catalog，是查找product description responsibility的最佳候選項(xiàng)。使用名為GetProductDescription的方法執(zhí)行牙齒祖懷操作。產(chǎn)品目錄可見性，可見性：一個(gè)對象“顯示”或參考另一個(gè)對象的能力，當(dāng)一個(gè)對象向另一個(gè)對象發(fā)送消息時(shí)，必須具有傳入消息對象的可見性。誰應(yīng)將

11、getProductDescription消息發(fā)送到ProductCategory以請求ProductDescription？假設(shè)在啟動用例的初始過程中，生成了長生命周期的注冊和產(chǎn)品目錄實(shí)例，并存在永久關(guān)聯(lián)！Register提供了getProductDescription消息、enterItem最終設(shè)計(jì)協(xié)作圖、enterItem最終設(shè)計(jì)類圖表、可在數(shù)據(jù)庫中搜索產(chǎn)品設(shè)計(jì)的產(chǎn)品類別的可見性，但可以將其放在關(guān)系數(shù)據(jù)庫或?qū)ο髷?shù)據(jù)庫中，然后根據(jù)需要進(jìn)行搜索?？紤]到性能和容錯(cuò)，某些產(chǎn)品設(shè)計(jì)可以緩存在客戶端過程中。為了簡單起見，在數(shù)據(jù)庫上搜索的問題將在以后討論。這里假設(shè)所有產(chǎn)品說明都放在內(nèi)存中。(威廉莎士比

12、亞、產(chǎn)品說明、產(chǎn)品說明、說明、說明、說明、說明、說明)，如何設(shè)計(jì)endSale，計(jì)算人員按下表示商品項(xiàng)目輸入完成的按鈕后，endSale系統(tǒng)將啟動，選擇控制類，繼續(xù)使用Register作為控制器，根據(jù)總銷售計(jì)算、模型視圖分離的設(shè)計(jì)原則，我們現(xiàn)在不要集中在如何顯示總銷售金額上，而是要確認(rèn)總銷售金額目前沒有知道總銷售金額的設(shè)計(jì)類。為了滿足牙齒需求，需要設(shè)計(jì)對象的交互。除非是控制器或制造問題，否則信息專家模型是我們首先要考慮的應(yīng)用節(jié)目模型，分析過程：說明責(zé)任：誰需要了解總銷售額？(威廉莎士比亞，Northern Exposure(美國電視電視劇)，成功)必需信息匯總：總銷售額是銷售項(xiàng)目小計(jì)銷售項(xiàng)目數(shù)

13、量產(chǎn)品說明價(jià)錢，所有銷售項(xiàng)目的小計(jì)。列出履行牙齒職責(zé)所需的信息以及理解這些信息的類。誰負(fù)責(zé)計(jì)算總金額？信息專家：Sale負(fù)責(zé)知道計(jì)算總收入所需的所有SaleLineItem實(shí)例，因此Sale負(fù)責(zé)知道總金額。銷售項(xiàng)目小計(jì)？信息專家：SaleLineItem知道數(shù)量和相關(guān)產(chǎn)品說明，因此SaleLineItem負(fù)責(zé)了解小計(jì)。ProductionDescription價(jià)錢？信息專家：ProductionDescription本身就是其屬性之一。更詳細(xì)的分析、Sale-getTotal設(shè)計(jì)、所有交互圖形都不是以系統(tǒng)操作消息(如enterItem或makeNewSale)開始的，可以從設(shè)計(jì)者希望表達(dá)交互的

14、任何消息開始。，因?yàn)樗惴?通常)不是用消息說明的，所以可以將算法或約束添加到定義計(jì)算的圖中，以說明計(jì)算的細(xì)節(jié)。誰給Sale發(fā)了getTotal信息？輸入U(xiǎn)I層對象、makePayment設(shè)計(jì)方法、計(jì)算人員支付的現(xiàn)金金額后，makePayment系統(tǒng)操作、Payment生成、Payment生成實(shí)例p(創(chuàng)建實(shí)例)生成角色。兩個(gè)候選人3360 reed寄存器是接收系統(tǒng)操作makePayment消息的控制器，是否首先保留有關(guān)收款總額的信息？指令：如果有多個(gè)可選設(shè)計(jì)，則必須更深入地觀察可選設(shè)計(jì)的內(nèi)聚，以及未來可能存在的進(jìn)化壓力。(約翰f肯尼迪，Northern Exposure美國電視電視劇，作品)必須

15、將良好的內(nèi)聚、耦合、未來變化時(shí)穩(wěn)定的設(shè)計(jì)、Sale的日志記錄，在后一種情況下，將SaleLedger添加到區(qū)域模型中。這是實(shí)際領(lǐng)域的概念。專家模型：誰知道記錄的所有銷售并完成記錄工作？(威廉莎士比亞，美國電視電視劇，成功)1: Store2:財(cái)務(wù)SalesLedger，堅(jiān)持最初的計(jì)劃，使用Store計(jì)算馀額，信息專家：誰負(fù)責(zé)知道付款馀額？Payment :知道已支付的現(xiàn)金總額Sale:銷售馀額合計(jì)=已支付的現(xiàn)金總額-銷售總額選擇Payment: Sale需要Sale的可見性以請求銷售總額。這將增加整個(gè)設(shè)計(jì)的聯(lián)接器，因?yàn)镾ale:已經(jīng)是具有Payment可見性的作者，所以需要Payment的可見性。因此，不增加總聯(lián)接器。NextGen迭代1如何將最終DCD、U