內容: 出自：yesky 設計當已經考慮了所有的技術細節和限制條件，我們就可以進入設計階段，設計階段需要展開和細化分析模型。設計的目的是為了說明一種可以很容易地翻譯成程序設計代碼的工作解決方案。設計階段可以分成兩部分：1、結構設計 這是非常高級的設計，說明在什么地方定義包（子系統），以及包與包之間的相互依賴與通信機制。自然，我們的目標是構建一種清晰而又簡單的體系結構，包與包之間的依賴要少，如果可能的話，盡量避免雙向的依賴。 2、詳細設計 所有的類都應描述足夠的細節，來明確規定誰來編碼這些類。 UML中的動態模型用于示范類的對象在具體的環境中的行為。 下面我將詳細說明。第一節 結構設計一個設計良好的體系結構是開發一個可擴展、可改變的系統的基礎，程序包所需要關心的是要么處理一個具體的功能區域，要么處理一個具體的技術區域。從技術邏輯中把應用程序邏輯（域類）區分開來是極其重要的，這是為了萬一需要修改程序的某一部分而不會對另一部分產生影響：一個目標就是標識并設定包與包之間（例如“子系統）的相互依賴的規則，并不在包之間創建雙向的依賴（為了避免程序包集成的太過緊密），另一個目標是為了表示標準類庫的需要。現在可用的應用程序庫強調的主要還是在技術領域，比如用戶界面，數據庫或通信機制等等，但是，我們也同樣盼望出現更多的具體的應用程序庫。本案例研究中的程序包或者說是子系統如下：1、用戶界面包（User-Interface） 這些類都是基于 Java AWT包這個Java中用于編寫用戶界面應用程序的一個標準的類庫。這個程序包與商業對象包（Business Object）協作，商業對象包包含了實際上用于儲存數據用的類，用戶界面包調用商業對象中的方法來取得并向商業對象中插入數據。2、商業對象包（Business Object） 它包括來自分析模型，比如 BorrowerInformation， Title， Item， Loan等等的討論域類。 該設計完全地定義了它們的操作并且添加了對于持久性的支持。 商業對象包與數據庫包合作，所有的商業對象類都必須從數據庫包中的 Persistent類繼承而來。3、數據庫包 （Database Package） 數據庫包給商業對象包中的另外一個類提供服務，以使它們能夠持久的儲存信息。在目前的版本，Persistent類將儲存它的子類對象到文件系統中的文件中去。4、實用程序包（Utility Package） 實用程序包包含用于該系統中的另外一個包的服務，現在，該包中只有 ObjId類，它用于引用遍及本系統的持久對象，包括用戶界面，商業對象和數據庫包。這些程序包的內部設計見圖 4。圖4解釋 圖書館應用程序結構概圖。 這是一張類圖，說明應用程序包以及它們之間的關系。數據庫包提供了持久性，公用程序包提供了Object ID類，商業對象包包含了討論域類，這點在圖5中將詳細列出。最后，基于標準Java AWT類庫的UI包調用商業對象中的操作來向它們中間插入數據。第二節 詳細設計詳細設計描述新的類--在用戶界面和數據庫包中的類，以及在本分析中描繪的商業對象類以外的人。本類的狀態和動態圖表使用的是與分析過程中一樣的圖表，但是它們被定義在更加詳細和更高的技術層次，分析過程中的使用案例描述用于驗證在設計階段處理的使用案例，使用序列圖表闡明在系統中，每個使用案例是如何在技術上實現的。數據庫包 應用程序必須有持久儲存對象，所以必須添加一個數據庫層來提供這個服務，為了簡單起見，我們把對象作為文件儲存在磁盤上，關于存儲器的細節就不需要被應用程序所知了，它調用通用操作，比如 store()、update()、delete()和 find()等等，這些都是一個調用 Persistent的類的一部分，所有的類都需要繼承 Persistent（持久對象）。持久性處理中的一個重要的因素就是 ObjId類，它的對象用于引用任何系統中的持久對象 (無論對象是在磁盤上還是已經被讀入應用程序中了 )。 ObjId是Object Identity的簡寫，是一種熟知的技術，用于處理應用程序中的對象引用。 通過使用對象標識，一個對象標識號就能被傳遞到 Persistent.getObject ( )操作，然后該對象將從持久存儲器中取回。 通常，這要通過每個持久類中的 getObject操作來完成，它還要執行必要的類型檢查和轉換。對象標識號還可以很容易地作為操作的參數被傳遞 (例如，一個尋找具體對象的搜索窗口可以通過對象標識號傳遞它的結果到另外一個窗口 )。ObjId標識系統（用戶界面、商業對象和數據庫）中所有的包使用的一個常規類，因此它在設計階段就被放進實用程序包中而不是數據庫包中。Persistent類的當前實現還可以不夠完善，它的最終目標是可以很容易的改變持久存儲器的實現，目前的替代的辦法是把對象出存在關系數據庫或面向對象數據庫中，也可以使用Java中的持久對象支持儲存它們。商業對象包 在設計階段中的商業對象包基于分析過程中相應的包——討論域類。類以及它們的相互關系和行為沒有變，但是類被描述的更加詳細，包括了它們的相互關系和行為如何實現。一些操作已經被翻譯成好幾個設計模型中的操作，一些還被改了名稱，這都是很正常的，因為分析只是每個類的能力的描繪，而設計則是系統詳細的描述，因此設計模型中的所有的操作都必須有定義好的特征和返回值，注意，下面給出了設計與分析的不同。圖5解釋 商業對象設計。 這張圖表充實了商業對象程序包的各種不同的類的設計。接口更加精確，選擇了屬性的數據類型。系統的當前版本不必檢查一本書是否及時歸還，也不必處理預借書籍的訂單，因此Loan和 Reservation類的日期屬性就沒有實現。 雜志和書的處理過程是完全相同的，除了借期的不同，而且它還不用處理。 在分析中， Magazine和 Book Title子類已經被認為不必要的并且在 Title類中只有一個類型屬性指定該書名是否指出一本書或雜志。在以后的應用程序版本中，如果認為有必要的話，這兩個簡化都可以刪除。 分析過程中的狀態圖表在設計階段又被細化了，顯示在工作系統中狀態如何被表示以及被處理。 Title類的設計狀態圖表如圖 6。 其他對象可以通過調用 addReservation ( )和 removeReservation ( )操作來改變 Title的狀態，就像這張圖表中所顯示的那樣。圖6解釋 設計Title的狀態圖 用戶界面包 用戶界面包總是在其他包之前，在系統中，它給用戶提供服務和信息，顯然，這個包基于標準的 Java AWT ( Abstract Window Toolkit )類。設計模型中的動態模型已經被分配到 GUI包中，因為所有的與用戶的交互作用都是通過用戶界面開始的， 此外，我們還選擇序列圖表來說明動態模型，本使用案例的設計模型的實現都是用細節描述的，包括類中的實際的操作。序列圖表實際上是以一系列迭代的形式創建的。在實現(即編碼)階段更多的細節上的發掘會產生更進一步的迭代。 圖 7表明 Add Title的結果設計序列圖表。圖7解釋 Add Title的序列圖 我們還可以使用協作圖表代替序列圖表，象圖 8。圖8解釋 Add Title的協作圖。第三節 用戶界面設計在設計階段，我們使用一個特定活動創建用戶界面。圖書館應用程序中的用戶界面是基于本使用案例的，并且已經被分成下列部分，在主窗口上，它的每個部分都已經被給予一個單獨的菜單欄：1、功能 本系統中的主要功能的窗口就是用來借書、還書以及與借書籍的登記工作等。 2、信息 本系統中的查看信息的窗口就是用來收集書名和借書者的信息。 3、維護 維護本系統的窗口用來添加、更新和刪除書名、借書者以及書籍。 圖9 是一個用戶界面包中的類圖的例子。圖9解釋 功能類圖模型。一般情況下，每個窗口提供一個系統中的服務并且映射到一個使用案例 (即使并不是所有的用戶界面都必須從一個使用案例中映射而來）， 創建一個成功的用戶界面超出本文討論的范圍，讀者朋友請參閱文后提供的代碼。我以后還會專門輯文探討這個問題。 Java, java, J2SE, j2se, J2EE, j2ee, J2ME, j2me, ejb, ejb3, JBOSS, jboss, spring, hibernate, jdo, struts, webwork, ajax, AJAX, mysql, MySQL, Oracle, Weblogic, Websphere, scjp, scjd