UML系統分析與設計SystemAnalysis&Design第十二章數據庫設計持久性數據庫層對象數據庫模型對象關系數據庫模型關系數據庫模型UML系統分析與設計第2版ZhenyanJi2數據庫設計在UML中，類圖定義了應用程序所需要的數據結構，用實體類以及實體類之間的關系來為數據庫中持久存在的數據結構建模。因此，需要將實體類映射為可以被數據庫識別的數據結構。如何將實體類、關聯關系、聚合關系、類屬關系轉變為3種數據庫（面向對象型、對象關系型、關系型數據庫）模型中的數據結構？UML系統分析與設計第2版ZhenyanJi3持久性數據庫層數據模型數據模型（DataModel）是以比原始的位和字節更易理解的方式描述數據庫結構的抽象。通用的數據模型層分類法認可3種抽象。概念數據模型概念數據模型是面向用戶、面向現實世界的數據模型邏輯數據模型邏輯數據模型提供的模型反應了數據庫管理系統DBMS的存儲結構，它是用戶從數據庫所看到的數據模型。物理數據模型物理數據模型定義了實際應用中數據是如何存儲于持久存儲設備（如磁盤）中的。UML系統分析與設計第2版ZhenyanJi4持久性數據庫層UML模型與持久數據庫層UML系統分析與設計第2版ZhenyanJi5對象數據庫模型ODB建模原語對象數據庫模型的基本建模基元是對象和字面量。每個對象都有個對象標識符，字面量沒有對象標識符。ODB區分類（Class）和類型（Type），一個類型可以有多個類。例如，類“Tiger”和類“Lion”都實現了接口“Animal”，它們的類型都是“Animal”。ODB類可以有特性（Properties）和操作，特性可以是屬性（Attribute）或關系（Relationship），即連接該對象與其他對象的屬性。UML系統分析與設計第2版ZhenyanJi6對象數據庫模型ODB建模原語1．字面量和對象類型字面量可以分為以下3種類型：（1）原子字面量（AtomicLiterals）。（2）結構化字面量（StructuredLiterals）。（3）集字面量（CollectionLiterals）。對象類型可以分為以下3種類型。（1）原子對象。（2）結構化對象。（3）集（如set<Person>，Person是一個類）。UML系統分析與設計第2版ZhenyanJi7對象數據庫模型ODB建模原語2．關系對于關聯關系、聚合關系和類屬關系這3種關系，ODB模型可直接支持關聯關系和類屬關系，聚合關系則通過約束關聯來支持。UML系統分析與設計第2版ZhenyanJi8對象數據庫模型ODB建模原語3．ISA和EXTENDS繼承ODMG對象模型定義了兩種類屬關系，即ISA關系和EXTENDS關系。其中，ISA關系對應于早期的接口繼承（InterfaceInheritance），EXTENDS關系對應于實現繼承（Implemen-tationInheritance）。UML系統分析與設計第2版ZhenyanJi9對象數據庫模型映射到ODB1．映射實體類理論上，UML沒有禁止設計者通過定義新類（在分析階段）和使用模板（在設計階段）來擴充類型系統。但在實踐中，為了避免UML中次要類的激增，只有當實現平臺支持可擴充的類型系統、內建的結構化類型、集類型時，設計者才這樣做。UML系統分析與設計第2版ZhenyanJi10對象數據庫模型將實體類映射到ODB設計UML系統分析與設計第2版ZhenyanJi11對象數據庫模型映射到ODB2．映射關聯在UML模型中，類之間的關聯允許類對象之間的導航，這正是對象數據庫所擅長的，即由永久對象標識符連接的對象之間的導航。在映射過程中，可對設計進行優化，將一些UML屬性或UML類模擬為ODB接口，從而將這些接口用作ODB類的屬性的類型。UML系統分析與設計第2版ZhenyanJi12對象數據庫模型關聯的映射UML系統分析與設計第2版ZhenyanJi13對象數據庫模型映射到ODB3．映射聚合UML的聚合有兩種語義，即具有引用語義的聚合（Aggregation）和具有值語義的組合（Composition）。在數據庫中，聚合被模擬為關聯或嵌套屬性。如果要加入特別的聚合語義，則需通過過程的方式（在程序中）實現，而不是通過聲明的方式（在數據結構中）實現。UML系統分析與設計第2版ZhenyanJi14對象數據庫模型聚合關系和組合關系UML系統分析與設計第2版ZhenyanJi15對象數據庫模型映射到ODB4．映射類屬從UML類屬關系到ODB的ISA和EXTENDS關系的映射基本上是“一對一”的，接口繼承用ISA關系來模擬，類繼承用EXTENDS關系來模擬。UML系統分析與設計第2版ZhenyanJi16對象數據庫模型類屬關系的映射UML系統分析與設計第2版ZhenyanJi17對象關系數據庫模型對象關系數據庫（Object-RelationalDatabaseMode，ORDBM）合并了老式關系模型數據庫和新式對象模型數據庫，使得對象關系數據庫管理系統（Object-RelationalDatabaseManagementSystem，ORDBMS）既能處理關系數據結構（關系表），又能處理對象數據結構（對象表）。UML系統分析與設計第2版ZhenyanJi18對象關系數據庫模型ORDB建模原語ORDB建模原語由對象建模原語和關系建模原語組成。主要的對象建模原語是用戶定義的結構化類型（StructuredType），該類型對應于ODB的“Interface”概念和UML的“Class”概念。ORDB的存儲機制是表（Table），表的列代表了可以接受用戶定義的結構化類型的值。為了與常規的關系表相區別，在ORDBMS實現中將這樣的表稱為對象表（ObjectTable）。UML系統分析與設計第2版ZhenyanJi19對象關系數據庫模型ORDB建模原語1．結構化類型ORDB表的列可以接受內建類型或用戶定義類型的值，ORDB的內建類型的功能類似于ODB的內建類型的功能。UML系統分析與設計第2版ZhenyanJi20對象關系數據庫模型ORDB建模原語2．對象表（ObjectTable）對象表是具有一個或多個列的行的集合。行是行類型的實例，對象表中的每一行都是由一個OID唯一標識的對象。行是可以插入表中或從表中刪除的數據的最小單位。為了快速區別對象類型和對象表，建議結構化后的類型名使用后綴TY。UML系統分析與設計第2版ZhenyanJi21對象關系數據庫模型ORDB建模原語3．行類型（RowType）行類型允許表在沒有使用結構化類型或集類型的情況下，具有相當復雜的內部結構。行類型是域的序列（即<域名><數據類型>對）。實際上，行類型允許將一個表嵌入到另一個表中，且表中的列可以含有行值。從數據庫編程的角度來說，行類型允許將完整的行存儲到變量中，允許將完整的行作為操作的輸入參數進行傳遞，還允許將完整的行作為操作的輸出參數或返回值進行返回。UML系統分析與設計第2版ZhenyanJi22對象關系數據庫模型ORDB建模原語4．引用類型（ReferenceType）結構化類型可以用來定義引用類型，用關鍵字“ref”來定義引用。例如，studref(StudentTY)就表示對象表中一個對結構化類型的引用。在SQL:1999中，引用類型是有作用域的，即它們引用的表在編譯時是確定的。UML系統分析與設計第2版ZhenyanJi23對象關系數據庫模型ORDB建模原語5．OF和UNDER繼承SQL:1999允許為已存在類型創建子類型，目前，SQL:1999只支持單一的實現繼承。對應于類型層次結構，可創建表層次結構。也就是說，為超類型創建超表，為子類型創建子表。但有時候，在表層次結構中有可能忽略類型層次結構中的類型UML系統分析與設計第2版ZhenyanJi24對象關系數據庫模型ORDB中的繼承UML系統分析與設計第2版ZhenyanJi25映射到ORDB1．映射實體類（EntityClass）UML系統分析與設計第2版ZhenyanJi26對象關系數據庫模型映射到ORDB2．映射關聯（Association）UML系統分析與設計第2版ZhenyanJi27對象關系數據庫模型映射到ORDB3．映射聚合（Aggregation）UML系統分析與設計第2版ZhenyanJi28對象關系數據庫模型映射到ORDB4．映射類屬（Generalization）UML系統分析與設計第2版ZhenyanJi29對象關系數據庫模型關系數據庫模型在過去的20年，關系數據庫模型（RelationalDatabaseModel）已經基本占領了數據庫軟件市場，關系數據庫模型已經取代了分層數據庫（HierarchicalDatabase）和網絡數據庫（NetworkDatabase）模型。最后的關系數據庫模型標準是SQL92，它是1992年得到ANSI和ISO的批準而發布的。市場上所有重要的RDBMS產品（包括Oracle、DB2、Sybase、Informix、SQLServer等）都遵守這一標準，雖然其方式各不相同。UML系統分析與設計第2版ZhenyanJi30關系數據庫模型RDB建模原語1．列、域和規則關系數據庫將數據存儲在由行和列組成的表中。其中存儲在行列交叉點的數據值必須是不可分的、單一的值，也就是說，列具有原子域（數據類型）。域定義了列可以接受的合法的值集，域可以是匿名的（如namevarchar(40)）也可以是有名的（如nameName），域Name在用來定義列“name”之前已經定義過了。UML系統分析與設計第2版ZhenyanJi31關系數據庫模型RDB建模原語2．關系表關系表是由它的固定列集定義的，列具有內建的或用戶定義的類型。表可以有任意多行，但沒有重復的行。特定行的列值可以是Null，Null值意味著“值目前不知道”或“值不適用”。由于RDB模型要求“沒有重復行”，因此每個表都有一個主鍵（PrimaryKey）。一個表可以有多個鍵，任意選擇這些鍵中的一個作為對用戶最重要的主鍵，其他的鍵則被稱為備用鍵（AlternateKeys）。UML系統分析與設計第2版ZhenyanJi32RDB建模原語3．引用完整性（ReferentialIntegrity）RDB模型通過引用完整性約束來維護表之間的關系。這種表之間關系不是固定的行到行的連接，而是每當用戶請求系統發現關系時，RDB才去發現行到行的連接。這種發現是通過比較一個表的主鍵值與該表或另一個表的外鍵值來實現的。外鍵（ForeignKey）被定義為表中的列的集合，其值為Null，或者通過匹配同一個表中或另一個表中的主鍵值所得。主、外鍵的一致性被稱作引用完整性，引用完整性中的主鍵和外鍵必須是基于同一個域定義的，但可以有不同的名字。UML系統分析與設計第2版ZhenyanJi33關系數據庫模型引用完整性UML系統分析與設計第2版ZhenyanJi34關系數據庫模型RDB建模原語4．范式（NormalForms）RDB設計中一個最重要、但同時最不容易被理解的概念就是規范化。關系表必須是范式（NormalForm，NF），范式被分為以下6種。第一范式。第二范式。第三范式。BC范式（Boyce-Codd范式）。第四范式。第五范式。UML系統分析與設計第2版ZhenyanJi35關系數據庫模型映射到RDB如同ODB和ORDB模型一樣，RDB設計也可以用UML衍型和其他擴充機制來模擬。從UML類模型到RDB模式設計的映射需考慮RDB模型的局限性，即在關系模式中表達類的一些內建的聲明式語義是不可能存在的，這樣的語義必須在數據庫程序中解決。1．映射實體類（EntityClass）實體類到關系表的映射必須遵循表的第一范式，列必須是原子的。UML系統分析與設計第2版ZhenyanJi36關系數據庫模型映射實體類UML系統分析與設計第2版ZhenyanJi37關系數據庫模型映射到RDB2．映射關聯（Association）將關聯映射到RDB的過程涉及了表之間引用完整性約束的使用。任何“一對一”或“一對多”的關聯都可以通過在一個表中插入一個外鍵來匹配另一個表中的主鍵來表達。對于“一對一”關聯，可以將外鍵添加到其中任何一個表中，也可將兩個實體類合并在一個表中（取決于想達到的規范化水平）。對于遞歸的“一對一”或“一對多”關聯，外鍵和主鍵位于同一個表中。UML系統分析與設計第2版ZhenyanJi38關系數據庫模型映射關聯UML系統分析與設計第2版ZhenyanJi39關系數據庫模型映射到RDB3．映射聚合（Aggregation）關聯映射的主要原理也適用于聚合映射。對于強形式聚合——組合（具有引用語義的聚合被看作是弱形式的聚合，具有值語義的組合則被看作是強形式的聚合），應該將子集和超集實體類組合到一張表中。這對于“一對一”的聚合是可能的，但對于“一對多”的聚合，子集類（無論是強形式聚合還是弱形式聚合）則必須被模擬為一個單獨的表（用一個外鍵將它和它的超集類的表連接起來）。UML系統分析與設計第2版ZhenyanJi40關系數據庫模型映射聚合UML系統分析與設計第2版ZhenyanJi41關系數據庫模型映射到RDB4．映射類屬（Generalization）類屬關系到RDB的映射有多種方式。不過，用RDB數據結構表達類屬關系容易忽略類屬關系的繼承、多態、代碼重用等。將類屬關系的層次映射為RDB設計模型的方法有4種。（1）將每個類映射到一個表。（2）將整個類層次映射到一個超類表。（3）將每個具體類映射到一個表。（4）將每個不相交的具體類映射到一個表。UML系統分析與設計第2版ZhenyanJi42關系數據庫模型類屬關系UML系統分析與設計第2版ZhenyanJi43關系數據庫模型將每個類映射到一個表UML系統分析與設計第2版ZhenyanJi44關系數據庫模型將整個類層次映射到一個超類表UML系統分析與設計第2版ZhenyanJi45關系數據庫模型將每個具體類映射到一個表UML系統分析與設計第2版ZhenyanJi46關系數據庫模型將每個不相交的具體類映射到一個表UML系統分析與設計第2版ZhenyanJi47關系數據庫模型映射類屬UML系統分析與設計第2版ZhenyanJi48小結數據庫在軟件開發中是非常重要的。一個糟糕的數據庫設計無法通過任何其他方法（包括好的應用程序設計）來矯正。本章對3個主要的數據庫模型——對象數據庫、對象關系數據庫、關系數據庫模型分別進行了討論，講解并舉例說明了如何將UML類模型映射到這3種數據庫的邏輯模型。UML系統分析與設計第2版ZhenyanJi49UML系統分析與設計SystemAnalysis&Design冀振燕北京交通大學

第十三章圖書管理系統的分析與設計系統需求需求分析靜態結構模型動態行為模型物理模型UML系統分析與設計第2版ZhenyanJi51系統需求圖書館圖書管理系統的域描述如下：在圖書管理系統中，要為每個借閱者建立一個賬戶，并給借閱者發放借閱卡（借閱卡可以提供借閱卡號、借閱者名），其中賬戶中存儲借閱者的個人信息、借閱信息以及預訂信息。持有借閱卡的借閱者可以借閱書刊、返還書刊、查詢書刊信息、預訂書刊并取消預訂，所有這些操作都是通過圖書管理員進行的，也即借閱者不直接與系統交互，而是讓圖書管理員充當借閱者的代理與系統交互。UML系統分析與設計第2版ZhenyanJi52系統需求在借閱書刊時，需要輸入所借閱的書刊名、書刊的ISBN/ISSN號，然后輸入借閱者的借閱卡號和借閱者名，完成后提交所填表格，系統驗證借閱者是否有效（在系統中是否存在賬戶），若有效，借閱請求被接受，系統查詢數據庫系統，看借閱者要求借閱的書刊是否存在，若存在，則借閱者可借出書刊，并在系統中建立存儲借閱記錄。借閱者還書后，刪除關于所還書刊的借閱記錄。UML系統分析與設計第2版ZhenyanJi53系統需求如果借閱者所借的書刊已被借出，則借閱者可以選擇預訂該書刊，一旦借閱者預訂的書刊可以獲得，就將書刊直接寄給預訂人（為了簡化系統，當預訂書刊可獲得時就不通知借閱者了）。另外，為了簡化系統，暫不考慮書刊的最長借閱期限，即假設借閱者可以無限期地保存所借閱的書刊。UML系統分析與設計第2版ZhenyanJi54系統需求對上述圖書管理系統的域描述進行分析，可以獲得如下功能性需求。（1）借閱者持有借閱卡（借閱卡包含借閱者姓名和借閱卡號）。（2）圖書管理員作為借閱者的代理借書。（3）圖書管理員作為借閱者的代理預訂書刊。（4）圖書管理員作為借閱者的代理取消預訂。（5）圖書管理員作為借閱者的代理還書。（6）圖書管理員可以創建新的借閱者賬戶。（7）圖書管理員可以修改借閱者的賬戶信息。UML系統分析與設計第2版ZhenyanJi55系統需求（8）圖書管理員可以刪除已存在的借閱者賬戶。（9）圖書管理員可以添加新書目。（10）圖書管理員可以修改書目信息。（11）圖書管理員可以刪除系統中的書目。（12）圖書管理員可以在系統中添加書刊信息（注意區分“書目”與“書刊”）。（13）圖書管理員可以編輯書刊信息。（14）圖書管理員可以刪除書刊信息。UML系統分析與設計第2版ZhenyanJi56需求分析識別參與者（1）BorrowerActor。描述：借閱者可以借閱、預訂、歸還物理書刊，還可以取消預訂。示例：持有借閱卡的任何人或組織。（2）Librarian。描述：圖書管理員維護系統，他可以創建、修改、刪除借閱者的信息；可以添加、編輯、刪除書目信息，即維護書刊目錄；可以添加、編輯、刪除物理書刊信息。示例：圖書管理員。UML系統分析與設計第2版ZhenyanJi57需求分析識別用例（1）BorrowBook（借閱物理書刊）。本用例提供了借閱物理書刊的功能。（2）ReturnBook（返還物理書刊）。本用例提供了返還物理書刊的功能。（3）ReserveTitle（預訂書刊）。預訂書刊時一般針對書目，而非某個物理拷貝。本用例提供了預訂書刊的功能。（4）CancelReservation（取消預訂）。本用例提供了取消預訂書刊的功能。UML系統分析與設計第2版ZhenyanJi58需求分析識別用例（5）MaintainBorrowerInfo（維護借閱者信息）。本用例提供了創建、修改以及取消借閱者賬戶的功能。（6）MaintainTitleInfo（維護書目信息）。本用例提供了添加、修改以及刪除書目信息的功能。（7）MaintainBookInfo（維護物理書刊信息）。本用例提供了添加、修改以及刪除物理書刊信息的功能。（8）LogIn（登錄）。本用例描述了用戶如何登錄進入該管理系統。UML系統分析與設計第2版ZhenyanJi59需求分析UML系統分析與設計第2版ZhenyanJi60系統用例圖需求分析圖書管理系統的用例事件流描述如下。1．借閱物理書刊（BorrowBook）1.1．前置條件（Pre-Conditions）在這個用例開始前，Librarian必須登錄到系統中。1.2．后置條件（Post-Conditions）如果這個用例成功，在系統中建立并存儲借閱記錄，若必要還要刪除預訂記錄。反之，系統的狀態沒有變化。1.3．擴充點（ExtensionPoints）沒有。1.4．事件流1.4.1．基流（BasicFlow）當借閱者從圖書館借閱物理書刊時，用例啟動。如果Librarian選擇“借書”，則執行分支流S-1：借閱物理書刊。UML系統分析與設計第2版ZhenyanJi61需求分析如果所借的物理書刊是經過預訂的，則執行分支流S-2：通過預訂借閱物理書刊。1.4.2．分支流（Subflows）S-1：借閱物理書刊（1）提供書目、借閱者信息。（2）檢索書目（Title）（E-1）。（3）確定所借閱的物理書刊是否可以獲得（E-2），即所借的物理書刊是否都已借出。（4）檢索借閱者（E-3）。（5）圖書館將物理書刊借給借閱者。（6）創建借閱記錄。（7）存儲借閱記錄。UML系統分析與設計第2版ZhenyanJi62需求分析S-2：通過預訂借閱物理書刊（1）提供書目、借閱者信息。（2）檢索書目（Title）（E-1）。（3）檢索借閱者（E-3）。（4）確定該種類書刊的物理拷貝是否可以獲得（E-2）。（5）將物理書刊發給借閱者。（6）創建借閱記錄。（7）存儲借閱記錄。（8）刪除預訂記錄。1.4.3．替代流（AlternativeFlow）E-1：該書目不存在，系統顯示提示信息，用例終止。E-2：物理書刊都已借出，系統顯示提示信息，用例終止。E-3：系統中不存在該借閱者，系統顯示提示信息，用例終止。UML系統分析與設計第2版ZhenyanJi63需求分析5．維護借閱者信息（MaintainBorrowerInfo）5.1．前置條件（Pre-Conditions）在這個用例開始前，Librarian必須登錄到系統中。5.2．后置條件（Post-Conditions）如果這個用例成功，系統添加、修改或刪除借閱者信息。反之，系統的狀態沒有變化。5.3．擴充點（ExtensionPoints）沒有。5.4．事件流5.4.1．基流（BasicFlow）當Librarian想維護借閱者信息時，用例啟動。UML系統分析與設計第2版ZhenyanJi64需求分析系統要求Librarian選擇所想執行的活動（即添加借閱者、刪除借閱者或修改借閱者）。如果所選的活動是“添加借閱者”，則執行分支流S-1：添加借閱者。如果所選的活動是“刪除借閱者”，則執行分支流S-2：刪除借閱者。如果所選的活動是“修改借閱者”，則執行分支流S-3：修改借閱者。5.4.2．分支流（Subflows）S-1：添加借閱者（1）提供借閱者信息，如姓名、地址、郵政編碼和身份證號碼等。（2）系統存儲借閱者信息（E-1）。S-2：刪除借閱者（1）提供借閱者信息。（2）查詢借閱者（E-2）。UML系統分析與設計第2版ZhenyanJi65需求分析（3）查詢借閱者的借閱記錄（E-3）。（4）從系統中刪除借閱者的信息，以及借閱者的預訂記錄。S-3：更改借閱者（1）提供借閱者的信息。（2）查詢并顯示借閱者的信息（E-2），修改相應的信息。（3）更新并存儲系統中借閱者的信息。5.4.3．替代流（AlternativeFlow）E-1：若借閱者已存在，系統顯示提示信息，用例終止。E-2：若查詢不到借閱者，系統顯示提示信息，用例終止。E-3：若存在借閱記錄，系統顯示提示信息，用例終止。UML系統分析與設計第2版ZhenyanJi66靜態結構模型定義系統對象（1）借閱者（Borrower）。借閱者是有身份的。例如，“王紅”和“劉新”是兩個身份不同的人，具有相同名字和不同身份證號碼的兩個人也是身份不同的。在這個系統中，借閱者有相關的行為，即借閱者可以借閱、返還、預訂書刊或取消預訂，所以借閱者應該成為系統中的一個對象，類名為Borrower。（2）書目（Title）。書目可以通過不同的ISBN/ISSN號來區分。在這個系統中，書目也有相關的行為，書目可以被預訂或被取消預訂，所以，書目也是系統中的一個對象，類名為Title。UML系統分析與設計第2版ZhenyanJi67靜態結構模型定義系統對象（3）物理書刊（Book）。物理書刊在圖書館中通過獨一無二的索引號來區分，因此不同的物理書刊不會被混淆。在這個系統中，物理書刊也有相關的行為，物理書刊可以被借閱或被返還，所以，物理書刊也是系統中的一個對象，類名為Book。（4）借閱記錄（Loan）。借閱記錄有身份，借閱記錄可以彼此區分，而不會被混淆。例如，同一個人關于不同書刊的借閱記錄是不同的。在這個系統中，借閱記錄也有相關的行為，它可以被建立或刪除，因此，借閱記錄也是系統中的一個對象，類名為Loan。UML系統分析與設計第2版ZhenyanJi68靜態結構模型定義系統對象（5）預訂記錄（Reservation）。預訂記錄也有身份，預訂記錄可以被此區別，不會被混淆。例如，借閱者相同但書目不同的預訂記錄是不同的，書目相同但借閱者不同的預訂記錄也是不同的。在這個系統中，借閱記錄也有相關的行為，它可以被建立或刪除，因此，借閱記錄也是系統中的一個對象，類名為Reservation。從上述分析可知，系統至少含有5個重要的類，即類Borrower、類Book、類Title、類Loan和類Reservation。上述5個類都是實體類，都是持久性的，都需要存儲在數據庫中。UML系統分析與設計第2版ZhenyanJi69靜態結構模型定義系統對象由于上述5個類都是持久性類，因此還可以抽象出一個代表持久性的父類，以實現面向對象數據庫文件的讀、寫、存儲、檢索、刪除、更新等操作。（6）類Persistent。類Persistent是類Borrower、類Title、類Book、類Loan、類Reservation的父類。類Persistent為商業對象的持久存儲提供了支持，它的子類必須能夠實現從數據庫文件中讀、寫對象屬性的操作。（7）類OID。類OID實現了對象ID。UML系統分析與設計第2版ZhenyanJi70靜態結構模型（1）類Persistent的屬性和操作。類Persistent支持對象的持久存儲。類Persistent具有將對象寫入數據庫文件的方法“write()”和從數據庫文件中讀出對象的方法“read()”，類Persistent還提供了通過OID檢索對象，獲得持久對象的OID，以及存儲、刪除、更新對象的方法。類Persistent的子類繼承了類Persistent的方法，并實現了該類的“write()”和“read()”方法，覆蓋了父類Persistent的“write()”和“read()”方法，從而實現了將特定子類對象的屬性寫入數據庫文件，或者從數據庫文件中讀出特定子類對象的屬性。UML系統分析與設計第2版ZhenyanJi71靜態結構模型（2）類OID的屬性和操作。類OID實現了對象ID，類OID的對象可用來引用系統中的持久對象，使得從數據庫文件中引用和檢索對象變得容易。對象ID由所引用的類的類名和一個獨一無二的idNumber號組成。通過將OID傳遞給類Persistent的方法getObject()，可以從數據庫文件中讀出對象，并將對象返回給調用者。UML系統分析與設計第2版ZhenyanJi72靜態結構模型（3）類Borrower的屬性和操作。類Borrower描述了物理借閱者（可以是人，也可以是公司或另一個圖書館等）的信息。借閱者的信息包括姓名、地址、郵政區號、身份證號碼和電話號碼。類Borrower與參與者BorrowerActor是不同的，參與者BorrowerActor代表了系統外的物理借閱者，而類Borrower則代表了系統中存儲的物理借閱者的信息，即代表了物理借閱者在系統中的賬戶。類Borrower的所有對象都是持久的，因為類Borrower繼承了類Persistent，并實現了讀寫操作。UML系統分析與設計第2版ZhenyanJi73靜態結構模型（4）類Title的屬性和操作。類Title描述了書目信息。對于每種書目（Title對象）來說，圖書館通常擁有多個物理拷貝（Book對象）。類Title封裝了書刊名、作者、ISBN/ISSN號等信息，它可以沒有預訂記錄或有多個預訂記錄（Reservation對象）。類Title繼承了類Persistent，并實現了讀寫操作，所以類Title的所有對象都是持久的。UML系統分析與設計第2版ZhenyanJi74靜態結構模型（5）類Book的屬性和操作。類Book代表可以借閱的物理書刊。類Book的對象有兩個狀態，即“已借出”或“未借出”。類Book的對象總是與一個Title對象對應。之所以區分類Book和類Title，是因為借閱者預訂書刊時只是預訂了某種書刊，而不是這種書刊的特定物理拷貝，圖書館對同一種書刊通常保存幾本物理拷貝（每本拷貝都可以被一個借閱者借出）。每個物理書刊都有一個獨一無二的id號，這個id號被標記在書上，用來唯一地標識圖書館中的物理書刊，且同一種類的不同物理書刊拷貝可通過id號來區分。類Book繼承了類Persistent并實現了讀寫操作，所以類Book的所有對象都是持久的。UML系統分析與設計第2版ZhenyanJi75靜態結構模型（6）類Loan的屬性和操作。類Loan描述了借閱者從圖書館借閱物理書刊的借閱記錄。一個Loan對象對應著一個借閱者（Borrower對象）和一個物理書刊（Book對象）。Loan對象的存在表示借閱者（Borrower對象）借閱了借閱記錄（Loan對象）中記錄的物理書刊（Book對象）。當物理書刊（Book對象）被還回時，要刪除借閱記錄（Loan對象）。類Loan繼承了類Persistent并實現了讀寫操作，所以類Loan的所有對象都是持久的。UML系統分析與設計第2版ZhenyanJi76靜態結構模型（7）類Reservation的屬性和操作。如果某書目（Title對象）的所有可借物理拷貝（Book對象）都已借出，則需要該書目的借閱者就需要預訂，當該書目的某個物理拷貝（Book對象）被還回時，預訂該書目（Title對象）的借閱者就可以優先借閱該物理拷貝（Book對象）。一種書刊（Title對象）可以被不同的借閱者（Borrower對象）預訂。當預訂生效時，系統要保存預訂記錄。類Reservation就是描述預訂記錄的類。當預訂的借閱者獲得書刊物理拷貝時（Book對象），預訂記錄（Reservation對象）要被刪除。類Reservation繼承了類Persistent并實現了讀寫操作，所以類Reservation的所有對象都是持久的。UML系統分析與設計第2版ZhenyanJi77靜態結構模型定義用戶界面類（1）類MainWindow。界面類MainWindow是系統的主界面，系統的主界面具有菜單和菜單項，當用戶選擇不同的菜單項時，系統可以執行不同的操作。當程序退出時，主界面窗口關閉。（2）類BorrowerDialog。界面類BorrowerDialog是進行操作“添加借閱者”、“修改借閱者”或“刪除借閱者”時所需的對話框。UML系統分析與設計第2版ZhenyanJi78靜態結構模型定義用戶界面類（3）類FindBwrDialog。界面類FindBwrDialog是根據借閱者ID號查找借閱者的對話框。當主窗口中的菜單項“刪除借閱者”或“修改借閱者”被選擇時，該對話框彈出，圖書管理員輸入借閱者ID，單擊“OK”按鈕，則系統查詢數據庫中具有指定ID號的借閱者信息。（4）類TitleDialog。界面類TitleDialog是進行操作“添加書目”、“修改書目”或“刪除書目”時所需的對話框。UML系統分析與設計第2版ZhenyanJi79靜態結構模型定義用戶界面類（5）類FindTDialog。界面類FindTDialog是根據書目的ISBN/ISSN信息來查找相應書目的對話框。當主窗口中的菜單項“刪除書目”或“修改書目”被選擇時，該對話框彈出，圖書管理員輸入書目的ISBN/ISSN信息，單擊“OK”按鈕，系統將查詢數據庫中具有指定ISBN/ISSN號的Title信息。（6）類BorrowDialog。界面類BorrowDialog是進行“借閱”操作時所需的對話框。當主窗口中的菜單項“借閱”被選擇時，該對話框彈出，圖書管理員輸入書刊名、書刊的ISBN/ISSN信息和借閱者信息，然后單擊“OK”按鈕，借閱動作被確認，系統創建并保存借閱記錄。UML系統分析與設計第2版ZhenyanJi80靜態結構模型定義用戶界面類（7）類ReturnDialog。界面類ReturnDialog是進行“還書”操作時所需的對話框。（8）類RsvDialog。界面類RsvDialog是進行操作“預訂”或“取消預訂”時所需的對話框。（9）類MessageWindow。界面類MessageWindow是用來顯示提示信息的窗口。（10）類LoginDialog。界面類LoginDialog是用來輸入用戶名和密碼的對話框。UML系統分析與設計第2版ZhenyanJi81靜態結構模型系統包圖UML系統分析與設計第2版ZhenyanJi82靜態結構模型用戶界面類的類圖UML系統分析與設計第2版ZhenyanJi83靜態結構模型實體類的類圖UML系統分析與設計第2版ZhenyanJi84動態行為模型建立交互作用圖添加借閱者“添加借閱者”的過程是，圖書管理員首先選擇菜單項“添加借閱者”，對話框彈出，圖書管理員輸入借閱者信息，然后提交，系統根據借閱者ID號查詢數據庫，看數據庫中是否已存在借閱者，若不存在，創建借閱者賬戶，并存儲借閱者信息。UML系統分析與設計第2版ZhenyanJi85“添加借閱者”順序圖UML系統分析與設計第2版ZhenyanJi86動態行為模型建立交互作用圖（2）刪除借閱者。“刪除借閱者”的過程是，圖書管理員首先選擇菜單項“刪除借閱者”，查詢對話框彈出，然后輸入待刪除的借閱者ID號，系統查詢數據庫，顯示借閱者信息（若借閱者信息不存在，顯示提示信息，結束刪除動作），按下刪除按鈕，系統確定是否存在與該借閱者相關的借閱記錄（若有，給出提示信息，結束刪除動作；若沒有，查詢是否存在與該借閱者相關的預訂記錄，若存在，刪除預訂記錄），最后從系統中刪除借閱者。UML系統分析與設計第2版ZhenyanJi87“刪除借閱者”順序圖UML系統分析與設計第2版ZhenyanJi88動態行為模型建立交互作用圖（3）添加書目。“添加書目”的過程是，圖書管理員首先選擇菜單項“添加書目”，對話框彈出，然后輸入書刊名、ISBN/ISSN號、作者等信息，提交信息，系統根據ISBN/ISSN號查詢書種信息是否已存在，若存在，顯示提示信息，終止操作；若不存在，創建書目，并存儲書目信息。UML系統分析與設計第2版ZhenyanJi89“添加書目”順序圖UML系統分析與設計第2版ZhenyanJi90動態行為模型建立交互作用圖（4）刪除書目。“刪除書目”的過程是，圖書管理員首先選擇菜單項“刪除書目”，對話框彈出，然后輸入書刊的ISBN/ISSN號，提交信息。系統查詢數據庫，顯示書目信息（若書目信息不存在，給出提示信息，結束刪除動作）。查詢物理書刊是否有借出，若有，給出提示信息，結束刪除動作；若沒有，刪除物理書刊信息。查詢是否有預訂記錄，若有，刪除預訂記錄并通知借閱者；若沒有，確認之后刪除書目。UML系統分析與設計第2版ZhenyanJi91“刪除書目”順序圖UML系統分析與設計第2版ZhenyanJi92動態行為模型建立交互作用圖（5）添加物理書刊。“添加物理書刊”的過程是，圖書管理員首先選擇菜單項“添加物理書刊”，對話框彈出，然后輸入書刊的ISBN/ISSN號，提交信息。系統查詢數據庫，顯示書刊信息，圖書管理員添加物理書刊，單擊按鈕確認添加，系統創建并存儲物理書刊對象。最后將物理書刊添加到書目中，更新書目信息。UML系統分析與設計第2版ZhenyanJi93“添加物理書刊”順序圖UML系統分析與設計第2版ZhenyanJi94動態行為模型建立交互作用圖（6）刪除物理書刊。“刪除物理書刊”的過程是，圖書管理員首先選擇菜單項“刪除物理書刊”，對話框彈出，然后輸入書刊的ISBN/ISSN號并提交。系統查詢數據庫，顯示書刊信息，圖書管理員從物理書刊列表中刪除物理書刊，單擊“確認”按鈕刪除，系統刪除物理書刊對象，并從書目信息中刪除物理書刊，最后更新書目信息。UML系統分析與設計第2版ZhenyanJi95“刪除物理書刊”順序圖UML系統分析與設計第2版ZhenyanJi96動態行為模型建立交互作用圖（7）預訂書刊。“預訂書刊”的過程是，圖書管理員首先選擇菜單項“預訂書刊”，對話框彈出，然后輸入書刊和借閱者的信息并提交。系統查詢數據庫，確定該書目是否存在，若存在，確定借閱者是否有效；若不存在，則顯示提示信息，圖書管理員重新輸入書刊信息或終止預訂操作。若借閱者有效，創建并存儲預訂記錄，并將預訂記錄添加到相應的借閱者和書目信息中；若借閱者無效，則顯示提示信息，圖書管理員重新輸入借閱者信息或終止預訂操作。UML系統分析與設計第2版ZhenyanJi97“預定圖書”順序圖UML系統分析與設計第2版ZhenyanJi98動態行為模型建立交互作用圖（8）取消預訂。“取消預訂”的過程是，圖書管理員首先選擇菜單項“取消預訂”，對話框彈出，然后輸入書刊和借閱者的信息并提交。系統查詢數據庫，確定該書目是否存在，若存在（若不存在，則顯示提示信息，圖書管理員重新輸入書刊信息或終止“取消預訂”操作），確定借閱者是否有效，若有效（若無效，則顯示提示信息，圖書管理員重新輸入借閱者信息或終止“取消預訂”操作），確定預訂記錄是否存在，若存在（若不存在，則顯示提示信息，