前言：
某共享系統涉及到多種異質、異構教育資源，研究其信息服務模型基礎結構對于屏蔽資源差異，為用戶提供統一服務具有重要的意義。數據字典是該信息服務模型基礎結構中的重要組成部分，本文詳細介紹了該系統中數據字典基于J2EE平臺的設計與開發，包括需求分析、總體設計、詳細設計直到編碼實現的全過程，整個系統采用UML進行分析和建模。
1 概述
1.1信息服務模式流程
信息服務模型基礎結構在該共享系統中，位于底層數據庫和上層各種應用（如統計分析、設備作業調度等等）之間，是整個共享系統的支持層面。數據字典作為信息服務模型分系統的最底層，維護共享系統的數據組織模式（Data Schema），并直接與數據庫進行交互。
在數據字典之上，分系統對資源信息數據進行封裝，按照OGSA標準將各種資源封裝成為以“服務”（Services）為基礎的信息模型單元。這些“服務”統一以“接口”的形式為其上層的應用系統提供支持。即該共享系統的所用應用通過調用信息服務模型分系統為其提供的接口與底層數據庫完成交互，并獲得共享資源提供的服務。
1.2. 數據字典在該信息服務模型中所處地位
l 通用數據元素字典，為不同的分系統開發者提供公共數據字典服務。
l 基于領域本體的資源屬性字典，為全局信息服務模型及資源統一服務目錄提供支持。
2 共享系統中數據字典模塊的設計與實現
2.1本模塊任務與內容
該共享系統建立數據字典用來存儲信息資源管理基礎標準的全部內容，以支持各個應用項目的開發，多個項目的互連，全系統的建設、運行、維護和數據信息的使用。
本共享系統建立數據字典主要基于三點：一為信息服務系統提供屬性字典服務，而信息服務是本共享系統集成支撐平臺的重要組成部分。二是對本系統數據庫的一個完整的描述與總體的把握。三為所有模塊開發者提供公用數據字典服務，促進數據共享，提高數據的使用效率。
本共享系統數據字典的用戶可分為兩類：一類為數據管理員，負責數據字典的創建與維護；另一類為上層應用，他們從數據字典中獲取所需的數據與信息。
本模塊兩個任務：
2.1.1 數據字典體系結構的設計
數據字典體系結構的設計非常重要，關鍵要從系統的客觀需要出發，分析各模塊需要共享的公用數據和需要提供的接口，從而確定數據字典的類型。公用數據字典的設計必須參考國標來建立，屬性字典的建立則需要研究專業領域的相關信息規范，結合本系統的實際情況來設計。信息模型字典體系主要包括五類字典：專家字典，通用數據字典，資源屬性字典，表屬性字典，索引信息字典。
2.1.2 基于數據字典的操作
基于信息模型數據字典的操作包括：創建字典，維護字典、瀏覽和查詢、接口封裝。
創建字典指設計字典的存儲結構，即數據庫表結構，然后錄入數據。
維護字典指基于各類字典的增加、刪除、修改操作。
數據字典創建好以后，還必須可以根據開發人員的要求進行一些操作，如增加一些特色屬性，對自定義的屬性的修改，或者刪除不必要的屬性或數據等等。因此我們的數據字典應該是動態的，可擴充的，在需求分析階段建立，系統開發過程不斷修改、充實、完善的。
對數據字典的維護往往是數據管理員應開發人員的要求來具體實施的，而數據字典一旦修改，數據管理員也應該及時將最新版本及時通知相關人員。
2.2 本模塊的需求分析
2.2.1 第一階段功能需求
由于本共享系統的開發歷時比較長，數據字典體系結構也很豐富，所以從系統的客觀需要出發，確定了第一階段的功能需求，以后的開發中將繼續完善整個字典體系結構的設計。
由于各個字典功能需求很相似，僅以專家字典為例介紹具體的功能需求。本數據字典模塊動態地維護一個專家庫，包括以下功能：
u 增加專家：數據管理員可以增加專家。
u 刪除專家：數據管理員可以刪除專家。
u 修改角色：數據管理員可以對專家的信息進行修改。
u 瀏覽：數據管理員或上層應用可以瀏覽全部專家。
u 查詢：數據管理員或上層應用可以根據專家所屬專業或所屬儀器設備類別進行單一或組合查詢。
2.2.2 UML的USE CASE建模
USE CASE建模就是把上述的功能需求站在參與者的視角表達出來，通過應用用例建模來描述一個系統需要的準確的模型。
在UML中，USE CASE（用例）簡單地顯示了參與者和用例之間地靜態關系，而不是動態關系。下面給出本應用程序在本階段（功能需求分析）中的用例建模，將主要以USE CASE方式描述。
2.3 總體設計
2.3.1 數據庫設計
一般說來，每一個屬性Attribute不只對應于一個類別Class，且每一個類別會有多個屬性，因此實體Class和Attribute是多對多的關系。每一個Expert必須是系統已經注冊的一個用戶，對應了唯一的一個用戶號UserID,但每一個注冊用戶不一定是專家，因此實體User和Expert是繼承的關系，而顯然實體省和學校是一對多的關系。
2.3.2 用例描述
在本階段，由于交互的對象是分析類，整個系統的職責也在分析類之間劃分。同時，分析類也根據職責的不同分為邊界類、控制類和實體類。
由于系統用例比較多，只選取其中最具代表性的一個用例維護屬性字典來說明設計思路和實現方法。維護屬性字典用例是由增加屬性、修改屬性信息、刪除屬性這三個用例來實現的，由于這三個用例的時序圖很相似，只以修改屬性信息來說明。
l 修改屬性信息
用戶從相應的類別中選擇需要修改的屬性，進行修改；系統提供給用戶可選擇屬性和修改屬性的界面，并完成該操作，即將修改結果寫入數據庫�？梢院苋菀椎胤从吵鱿旅娴牟僮餍蛄校�
u 用戶從相應的類別中選擇需要修改的屬性
u 系統列出該屬性的全部信息
u 用戶輸入修改信息
u 用戶提交修改信息
u 完成修改，即將修改后的信息寫入數據庫。
在時序圖中，系統被細化為若干的分析類，這些類就是在代碼階段構成真正的類的基礎（包括JSP頁面，JavaBean以及EJB組件）�；旧�，這些類是按照功能的不同來劃分的。
2.4 詳細設計
截至到目前，從需求分析到概要設計，使用了UML語言對系統進行了建模。但是，還沒有對J2EE組件（從JSP、JavaBean到EJB組件）進行詳細的描述和設計。因此本階段將：
l 對EJB組件進行詳細設計，包括Session Bean和Entity Bean.
l 對前臺組件進行詳細設計，包括JSP頁面、JavaBean的設計。
為此在設計的時候，并不像前面那樣，純粹從邏輯方面考慮，還參考了J2EE的架構特性，參考了一些成熟的設計模式，比如MVC結構。把UML和J2EE的特性最大限度的結合起來，是設計當中遇到的很大的難點。這里，將會分散在各個用例的建模中簡單說明。
2.4.1 設計方案的理論依據以及方案討論
MVC模型是由Xrox公司在80年代末期發表的一系列論文中首先提出來的。這種模型的基本原理是把應用程序的數據和商務邏輯，數據的外觀呈現以及對數據的操作劃分到不同的實體中去，這些實體成為模型、視圖、控制器。使用這種模型可以使設計過程更加靈活，可以對商務規則和數據的物理表示進行修改而不觸及任何用戶界面的代碼。
盡管這種方案最初是為了編寫獨立的GUI應用程序而開發出來的，然而它也可以很好的應用于J2EE的多層應用程序。用戶將和控制器發生交互，告訴控制器他將要做哪些事情，控制器將以一種獨立于客戶端類型的方法把用戶的請求轉交給模型。
2.4.2 設計方案
EJB是一種服務器端組件體系結構，是一個基本的事務管理系統和一種與客戶端類型無關的組件模型，它簡化了用Java開發企業級的分布式組件應用程序的過程。通過EJB，我們能寫出可擴展的、健壯的和安全的應用程序，而不用自己去寫復雜的分布式組件框架。在一個多層結構的電子商務應用中，后臺持久存儲是由一個或多個數據庫提供的。Web引擎使用HTML處理靜態內容，使用Servlet和JSP處理動態表示邏輯，EJB提供Web層與數據庫之間的業務邏輯。
EJB組件有兩種類型，實體bean和會話Bean。在本應用程序中，選用了容器管理持久性（CMP）實體Bean，無狀態會話Bean。用每個實體Bean來替換前面分析過的分析類中的實體類。會話bean主要用來處理商務邏輯，用它來替換控制類。把EJB納入方案之后，MVC的角色就可以擴展到Web容器和EJB容器中的多個組件。在應用程序中，頁面獲得參數，并通過Javabean調用Session bean處理來自頁面的請求。因此，Session bean是控制器，方案中，實體bean對應模型，JSP和Javabean對應視圖。分析類中的Attri_Tbl和Class_Tbl分別轉化為兩個實體bean（Attri_Tbl和Class_Tbl），分別持有數據庫相應表中某一相關元組的數據。設計中通常采用一個entity bean來映射一個數據庫中的表�？刂破饔蒘ession bean充當，負責對entity bean的調用。
3 結束語
數據字典作為信息服務模型基礎結構的最底層，維護共享系統的數據組織模式（Data Schema），并直接與數據庫進行交互。在數據字典之上，信息服務模型基礎結構對資源信息數據進行封裝，按照OGSA標準將各種資源封裝成為以“服務”（Services）為基礎的信息模型單元。這些“服務”統一以“接口”的形式為其上層的應用系統提供支持，并獲得共享資源提供的服務。
