【正文】 ()。 (aYiYeQingRen)。依賴關系在代碼實現(xiàn)上，把服務器端對象作為客戶端對象的方法的參數(shù)，客戶端職責的完成通過對服務器端靜態(tài)方法的調用來實現(xiàn)。在UML中，泛化關系用一條從子類指向父類的空心三角形箭頭來表示。本講將通過男人、女人、丈夫、妻子、一夜情人、情人、房子、家和孩子這樣一個完整的例子來說明這五種關系?？蛻舳藢ο驛只能向服務端對象B發(fā)出兩種類型的消息：消息應該是一個問題，或者一個命令，不能兩者都是。二、客戶提供者消息協(xié)作模式前提：B擁有A所問問題的知識；B具有A所請求事情的處理能力。1. A問，B答2. A問，B不答（問而不答型）3. A不問，B主動告知。（不問自答型）再如下述場景2：A希望B去做飯。但是A不問時，B不主動回答；A不請求B做事情，B不主動做事情。（3）對服務提供者的約束消息對應行為的執(zhí)行者，即，服務提供者。一、 泛化關系泛化關系常與繼承關系相提并論，繼承關系指子類繼承父類的屬性和行為；泛化關系則是指將子類的共同屬性和行為提取出來，形成更一般的概念，子類相對于一般化概念來講就是特殊概念。下圖表示了丈夫與男人之間的泛化關系，以及一夜情人、情人和妻人與女人之間的泛化關系。上圖示例的代碼如下代碼實現(xiàn)如下所示：Class zhangfu{ doThing(YiYeQingRen aYiYeQingRen )//該對象作為方法的輸入?yún)?shù)，該對象的作用域為整個程序 { ()。}}三、 關聯(lián)關系對于兩個相對獨立的對象，當一個對象的實例與另一個對象的特定實例存在固定的對應關系時，這兩個對象之間為關聯(lián)關系。}}主程序：Public Class Test{ZhangFu aZhangFu= new ZhangFu(“LMB”,”30”)。//該對象的作用域是整個類 doThing(){ ()。丈夫、妻子與家之間的組合關系可以用下圖來表示。//作用域為整個類}主程序：Public Class Test{ Main() { Jia aJia= new Jia(“LMB”,”30”,”DZX”,”28”)。} Public Baby doThing(YiYeQingRen aYiYeQingRen) //產生的新對象的作用域是整個程序{ ()。}由上分析，可以得到如下對象與對象之間關系的整體結構圖。（2）抽象類模型，類名，類的屬性（此時類只具有靜態(tài)屬性）（3）對象之間互發(fā)消息，得到客服消息表，得到對象消息交互圖，從而轉換為服務器端類的方法。體會軟件系統(tǒng)中類模板與類的對象的關系體會軟件系統(tǒng)中類模板與類的對象的關系體會：（1）.由類創(chuàng)建對象屬性值的不同產生了不同的對象。類的不同對象之間其屬性值可以不同，但各個對象的行為算法一樣，因此，同一個類的所有對象可以共享算法代碼，這些屬性和行為可以被看作是新建類的對象的模板，類與對象的關系如同模具與產品之間的關系，類可以創(chuàng)建屬于它的新對象。行為的協(xié)作就是通過消息的傳遞來實現(xiàn)的。客戶端向服務器端發(fā)送的消息，可以分為如下兩類：獲知類消息和執(zhí)行類消息。每個用例的 活動圖活動圖以用例為單位，對每個用例的業(yè)務處理過程描述是繪制 活動圖的依據(jù)。基本用例敘述 基本用例敘述也是面向對象系統(tǒng)分析與設計過程中非常重要的一個模型。（5）基本用例敘述 224。菜單管理員是餐廳特定員工，可以管理菜單。（2） 對活動圖進行分塊對活動圖的分塊，其實就是對完成這項活動所對應的任務，所需的相關動作的劃分，也即，模塊的劃分。這同時也可以作為動作劃分的一個依據(jù)，如果劃分出的一個動作集合，既包括回答問題，也包括執(zhí)行過程，那么就需要對這個動作集合進一步進行劃分。耦合性是模塊間互相連接的緊密程度的度量。模塊之間聯(lián)系越緊密，其耦合性就越強，模塊的獨立性則越差。 無直接耦合。 4控制耦合指一個模塊調用另一個模塊時，傳遞的是控制變量（如開關、標志等），被調模塊通過該控制變量的值有選擇地執(zhí)行塊內某一功能。 時間內聚。 與其他模塊的耦合是最弱的。增加新對象顧客訂單，對兩部分進行耦合。特殊需求顧客在提交數(shù)據(jù)后，系統(tǒng)3秒內給予響應事件流描述（處理過程交互的描述） 參與者操作系統(tǒng)響應1當顧客準備訂餐時用例開始。因此，系統(tǒng)時序圖是一個不完整的消息序列圖。4顧客請求系統(tǒng)提供選菜服務5系統(tǒng)生成顧客訂單系統(tǒng)核實顧客身份；？提供核實顧客身份信息的服務。8用例結束種類圖示種類圖示ActorBusiness EntityBoundaryBusiness EventBusiness ActorBusiness GoalBusiness WorkerDomainControlentityInterfaceTableView在建模工具JUDE中，關于域模型中對象的種類也非常多，有：Boundary, Control, Entity, Business Entity等。第二層次做圖：依據(jù)域模型類與類之間的關系增加了選菜與顧客、與菜譜的關系，訂單與餐廳員工的關系。類名系統(tǒng)(COS)類的屬性類的方法1:顯示菜單服務showMenu()Void showMenu(aMenu Menu)。Void show(){ 顯示ListMenuInfo。//增加訂單項 return aCustOrder。 =?。相應的類圖如下：數(shù)據(jù)文件存放在外存中，由數(shù)據(jù)庫管理系統(tǒng)進行管理，以增、刪、改、查為主要操作。要求程序員不僅掌握面向對象編程知識也要掌握SQL數(shù)據(jù)處理知識。弊端：擯棄了數(shù)據(jù)庫管理系統(tǒng)的強大的數(shù)據(jù)管理功能，擯棄了成熟的SQL語言。(顧客id, 選菜id,付款總金額，付款方式，送餐時間，送餐地點，確認id.). 顧客id要求與選菜id的顧客id相同。 entry 事件指定進入該狀態(tài)的動作， exit 事件指定退出該狀態(tài)的動作，而 do 事件則指定在該狀態(tài)下的動作。如果只有守衛(wèi)條件沒有事件說明，則只要守衛(wèi)條件為真狀態(tài)轉換就發(fā)生。業(yè)務邏輯從JSP頁面中分離后，JSP文件蛻變成一個單純完成顯示任務的東西，即，,再加上控制器control，就構成了MVC模式?？蚣軜嫵闪送ㄓ玫?、具有一般性的系統(tǒng)主體部分，二次開發(fā)人員只需要像做填空題一樣，根據(jù)具體業(yè)務，完成特定應用系統(tǒng)中相關部分。Servlet 常用的方法為：doGet()與doPost(),用于接收用戶的請求，調用后臺的JavaBean,或EJB對用戶進行響應。第七部分 詳細設計表示層詳細設計、業(yè)務層詳細設計、數(shù)據(jù)層詳細設計已分別加在總體設計之后。這個想法分析可得到如下對象消息序列圖：問題：對于 生產產品 這個方法的返回對象類型的確定解決方法：使用對象的多態(tài)性來解決這個問題。但是靜態(tài)方法是要占用內存的。 if ((apple)) {簡單工廠模式的優(yōu)點：(1)提供了一個公共工廠類方法，一旦需要某個對象時，只需傳入相應的參數(shù)，就可以得到相應的對象。父類與子類 實現(xiàn)與接口 都可以實現(xiàn)對象的多態(tài)和方法的多態(tài)。}}Public interface FruitFactory{ Public Fruit produce()。 f2 =new AppleFactory()。}}Public class BananaFactory {Public Fruit produce(){ Fruit f= new Banana()。}}Public class TestApp{Private AppleFactory f1。p2=()。 return f。實現(xiàn)與接口 則強調 實現(xiàn)類要實現(xiàn)接口類中公布的所有方法。(2)系統(tǒng)擴展困難。根據(jù)對象消息序列圖，抽象相應的設計類圖如下：為了使用簡單工廠的工廠方法時，不必實例化很多簡單工廠對象，考慮將該方法定義為靜態(tài)方法。2. 業(yè)務層詳細設計:3. 數(shù)據(jù)層詳細設計:第八部分 設計原則1. 拙劣設計的癥狀（1） 癥狀僵化性設計難以改變脆弱性設計易于遭到破壞頑固性設計難以重用粘滯性難以做正確的事情不必要的復雜性過分設計不必要的重復濫用鼠標進行復制、粘貼晦澀性混亂的表達（2） 案例（3） 原因分析（4） 問題解決2. 設計原則單一職責原則開放封閉原則Liskov替換原則依賴倒置原則接口分離原則（1） 單一職責原則（2） 開放封閉原則（3） Liskov替換原則（4） 依賴倒置原則（5） 接口分離原則第九部分 設計模式1. 設計模式分類（1） 創(chuàng)建型創(chuàng)建型設計模式重點解決的問題：有新對象要創(chuàng)建，是？負責新對象的創(chuàng)建工作。不同點在于JSP是在html或者xml中嵌入了Java代碼或者JSP的標記，在制作頁面方面具有優(yōu)勢，可以使用網(wǎng)頁編輯工具來制作網(wǎng)頁，然后嵌入Java或者JSP的標記。（3） 系統(tǒng)體系結構的發(fā)展進程1 單機版1. 單機版人機交互與業(yè)務邏輯耦合在一起=控制臺應用程序=控制臺界面+業(yè)務邏輯控制2. 單機版(圖形用戶界面+業(yè)務邏輯控制)+ODBC/JDBC+數(shù)據(jù)庫=HTML/Applet/JSP+JavaBean+JDBC+數(shù)據(jù)庫=asp/+C+ODBC+數(shù)據(jù)庫2 基于C/S架構的系統(tǒng)體系結構3 基于Web的系統(tǒng)體系結構3. B/S模式人機交互與業(yè)務邏輯耦合在一起=(圖形用戶界面+業(yè)務邏輯控制1)(分布在客戶端)+業(yè)務邏輯控制2+JDBC/ODBC(布署在應用服務器端)+應用服務器+數(shù)據(jù)庫(布署在數(shù)據(jù)庫服務器)+數(shù)據(jù)庫服務器= HTML/Applet/JSP+JavaBean+JDBC+Tomcat+數(shù)據(jù)庫+MySql/SqlServer= HTML/Applet/JSP+Servlet+JavaBean+JDBC+Tomcat+數(shù)據(jù)庫+MySql/SqlServer.基于web的應用程序模型圖示：4 基于Web的三層系統(tǒng)體系結構4. B/S 模式將業(yè)務邏輯完全從表示層剝離Model 2引入了“控制器”的概念，控制器一般由servlet來擔任，客戶端的請求不再直接送給一個處理業(yè)務邏輯的JSP頁面，而是送給控制器，再由控制器根據(jù)具體的請求調用不同的事務邏輯，并將處理結果返回到合適的頁面。JspServerlet(充當控制器)dao (javaBean)Entity(javaBean)dbms與前一種方案類似。2 訂餐系統(tǒng)的狀態(tài)圖：系統(tǒng)頁面設計：初態(tài)歡迎界面1菜單與今日特價顯示頁面2顧客訂單顯示頁面3訂單顯示頁面4次態(tài)動作顯示菜單與今日特價2無效2無效選菜33無效無效確認訂單or提交訂單or確認訂餐無效無效4無效關閉終態(tài)3 菜譜狀態(tài)圖：4 顧客訂單的狀態(tài)圖：顧客訂單頁面設計：初態(tài)顧客訂單為空1顧客訂單不空2次態(tài)動作確認添加菜信息22確認刪除菜信息無效25 訂單的狀態(tài)圖（2） 表示層設計:系統(tǒng)總體狀態(tài)轉換表：初態(tài)（1）（2）（3）（4）（5）（6）（7）（8）次態(tài)動作特價區(qū)2無效無效無效無效無效無效無效會員登錄33無效無效3無效無效無效會員注冊444無效無效無效無效無效查看所有菜單無效66無效無效無效無效無效登錄無效無效5/6無效無效無效無效無效重新登錄無效無效無效無效無效無效無效無效訂餐無效無效無效無效無效6無效無效查看訂單無效無效無效無效無效7無效無效進入結算無效無效無效無效無效8無效無效由狀態(tài)轉換表可以得到相應的狀態(tài)轉換圖如下：（3） 表示層的實現(xiàn)：1 基于窗體的表示層2 基于web頁面的表示層2. 數(shù)據(jù)層設計與前一種方案類似?；顒颖碇械膭幼鞅磉_式描述應做的具體動作。顧客id菜項id份數(shù)送餐時間送餐地點員工id員工姓名第五部分 系統(tǒng)總體設計方案3：人機交互界面+業(yè)務處理+DBMS系統(tǒng)使用的過程，即選菜控制器的使用過程，要對選菜控制器以及其所涉及的其他對象的狀態(tài)進行分析，因此，需要對選菜控制器的使用狀態(tài)、顧客是否登錄的狀態(tài)、菜譜的顯示狀態(tài)，以及顧客訂單的編輯狀態(tài)進行分析。（1） ER圖：ER圖是概念數(shù)據(jù)模型。表示層控制臺業(yè)務層業(yè)務處理層DAO數(shù)據(jù)層ODBC/JDBCDBMS系統(tǒng)框