2012年9月6日

Linux中JDK1.6的安裝和配置方法
一、安裝
創建安裝目錄，在/usr/java下建立安裝路徑，并將文件考到該路徑下：
# mkdir /usr/java

1、jdk-6u11-linux-i586.bin 這個是自解壓的文件，在linux上安裝如下：
# chmod 755 jdk-6u11-linux-i586.bin
# ./jdk-6u11-linux-i586.bin （注意，這個步驟一定要在jdk-6u11-linux-i586.bin所在目錄下）

在按提示輸入yes后，jdk被解壓。
出現一行字：Do you aggree to the above license terms? [yes or no]
安裝程序在問您是否愿意遵守剛才看過的許可協議。當然要同意了，輸入"y" 或 "yes" 回車。

2、若是用jdk-6u11-linux-i586-rpm.bin 這個也是一個自解壓文件，不過解壓后的文件是jdk-6u11-linux-i586-rpm 包，執行rpm命令裝到linux上就可以了。安裝如下：
#chmod 755 ./jdk-6u11-linux-i586-rpm 
# ./jdk-6u11-linux-i586-rpm .bin
# rpm -ivh jdk-6u11-linux-i586-rpm
出現一行字：Do you aggree to the above license terms? [yes or no]
安裝程序在問您是否愿意遵守剛才看過的許可協議。當然要同意了，輸入"y" 或 "yes" 回車。
安裝軟件會將JDK自動安裝到 /usr/java/目錄下。

二、配置
#vi /etc/profile
在里面添加如下內容
export JAVA_HOME=/usr/java/jdk1.6.0_27
export JAVA_BIN=/usr/java/jdk1.6.0_27/bin
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
export JAVA_HOME JAVA_BIN PATH CLASSPATH

讓/etc/profile文件修改后立即生效 ,可以使用如下命令:
# . /etc/profile
注意: . 和 /etc/profile 有空格.

重啟測試
java -version
set 查看環境變量
pwd 顯示當前位置

samba文件共享服務可以讓linux和linux系統、linux和windows系統之間共享文件

服務查詢
默認情況下，Linux系統在默認安裝中已經安裝了Samba服務包的一部分，為了對整個過程有一個完整的了解，在此先將這部分卸載掉。使用命令
rpm -qa | grep samba，默認情況下可以查詢到兩個已經存在的包：
samba-client-xxx-xxx
samba-common-xxx.xxx

卸載Samba
用rpm -e 將兩個包卸載掉。對于samba-common-xxx.xxx，因為與其它rpm包之間存在依賴關系，所以必須加參數-f和--nodeps，-f是指強制，--nodeps是指不檢查依賴關系，具體完整命令為：
rpm -e samba-common-xxx -f --nodeps
rpm -e samba-client-xxx -f –nodeps

掛在鏡像文件

因為安裝samba你需要下載對應的安裝包，一般系統盤就有這些軟件，所以可以直接掛載上去

mount -o loop /home/rhel-server-6.2-x86_64-dvd.iso /media/OS

這樣就將系統盤掛載到指定的OS目錄了，在OS目錄下的Packages下有很多安裝包可以使用。

安裝Samba
用以下命令安裝：
rpm -ivh samba-xxx.rpm -f --nodeps
rpm -ivh samba-client-xxx.rpm  -f --nodeps
rpm -ivh samba-common-xxx.rpm -f --nodeps
安裝完成后，使用命令rpm -qa | grep samba進行查詢，發現搭建samba服務器所依賴的所有服務器都已經安裝好了即可。

安裝完成后配置/etc/samba/smb.conf配置文件，你可以備份原來的配置，把下面的配置覆蓋當前配置即可：

[global]

    workgroup=takecar

    netbios name=Linux-108.12

    server string=Linux Samba Server TestServer

    #security=share

    security=user

    map to guest=Bad User

[takecar]

    path=/opt/takecar

    writable=yes

    browseable=yes 

    guest ok=yes

以上就是配置匿名用戶共享目錄/opt/takecar

其中writable是寫入權限、browseable是瀏覽權限、guest是貴賓用戶

建立相應目錄并授權
[root@localhost ~]# mkdir -p /opt/linuxsir
[root@localhost ~]# id nobody
uid=99(nobody) gid=99(nobody) groups=99(nobody)
[root@localhost ~]# chown -R nobody:nobody /opt/linuxsir
注釋：關于授權nobody，我們先用id命令查看了nobody用戶的信息，發現他的用戶組也是nobody，我們要以這個為準。有些系統nobody用戶組并非是nobody ；

啟動smbd和nmbd服務器
[root@localhost ~]# smbd
[root@localhost ~]# nmbd

關閉和查詢服務

pkill smbd

pkill nmbd

pgrep smbd

pgrep nmbd

 

如果啟動后不能訪問可能是防火墻原因，關閉防火墻

service iptables stop
chkconfig iptables off

設置服務開機啟動 ntsysv命令可以進入圖形界面設置，如果windows不能建立linux的共享目錄可能是window中的某個服務原因。

可以在運行輸入 secpol.msc命令 進入本地策略/安全選項， 設置

直接用進程殺死程序

ps -ef|grep smb
kill -9 pid #pid 為相應的進程號
#直接查看指定端口的進程pid
netstat -anp|grep 9217

// 方式一：

double f = 3.1516;

BigDecimal b = new BigDecimal(f);

double f1 = b.setScale(2, BigDecimal.ROUND_HALF_UP).doubleValue();

// 方式二：

new java.text.DecimalFormat("#.00").format(3.1415926);

// #.00 表示兩位小數 #.0000四位小數 以此類推…

// 方式三：

double d = 3.1415926;

String result = String.format("%.2f", d);

// %.2f %. 表示 小數點前任意位數 2 表示兩位小數 格式后的結果為f 表示浮點型。

//方法四：

Math.round(5.2644555 * 100) * 0.01d;

//String.format("%0" + 15 + "d", 23) 23不足15為就在前面補0

在使用cxf實現webservice時,經常碰到的問題就是如果在服務端,修改了一個接口的簽名實現，如增加一個字段,或者刪除一個字段。在這種情況下，在默認的配置中，就會報以下的錯誤信息：

org.apache.cxf.interceptor.Fault: Unmarshalling Error: unexpected element . Expected elements are
這種錯誤即客戶端使用的傳輸對象與服務端接收的參數的字段不匹配。但如果，每次修改服務端的實現，都需要更新客戶端時，就會出現一些問題，如在某些情況下，客戶端的更新是不可能的事（如不在自己掌握之內，或者服務不能隨便更新，或者其它計劃時）。

如果避免這種問題，其實也很簡單，就是禁用cxf中的字段信息驗證，如果禁用掉此驗證，就不再會對相應的字段信息進行驗證，同時沒有的字段也會自動的忽略。整個解決只需要增加以下的一行配置即可，在cxf.xml(spring集成文件)中增加以下配置項：

<cxf:properties>
   <entry key="set-jaxb-validation-event-handler" value="false"/>
</cxf:properties>
這樣，即會禁用掉所有cxf的數據驗證，在大多數情況下，這可以滿足我們的要求(除非你有其它和cxf集成的數據驗證要求)。

轉載請標明出處:i flym
本文地址:http://www.iflym.com/index.php/code/201307310001.html

ant 命令行方式執行build javac編譯class出現 泛型無法轉換 無法確定 <X>X 的類型參數；對于上限為 X,java.lang.Object 的類型變量 X，不存在唯一最大實例

解決方法：

需要用到eclipse的jdt來編譯class，不能再使用javac的默認編譯方式。

在eclipse或MyEclipse的eclipse/plugin目錄中找到org.eclipse.jdt.core_3.5.2.v_981_R35x.jar里面找到jdtCompilerAdapter.jar

還有

org.eclipse.jdt.compiler.tool_1.0.100.v_972_R35x.jar
org.eclipse.jdt.core_3.5.2.v_981_R35x.jar
org.eclipse.jdt.debug.ui_3.4.1.v20090811_r351.jar
jdtCompilerAdapter.jar

并拷貝到ant_home/lib下。

在ant的build.xml腳本中加入

<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter"/>

<javac nowarn="false" debug="true" debuglevel="source,lines,vars" destdir="${dist.path}/classes" source="1.6" target="1.6" encoding="utf-8" fork="true" memoryMaximumSize="512m" includeantruntime="false">

 

或者

<javac compiler="org.eclipse.jdt.core.JDTCompilerAdapter" nowarn="false" debug="true" debuglevel="source,lines,vars" destdir="${dist.path}/classes" source="1.6" target="1.6" encoding="utf-8" fork="true" memoryMaximumSize="512m" includeantruntime="false"/>

如果是用eclipse運行ant腳本，在右鍵菜單選擇從RUN as Ant 啟動build.xml時，在對話框中 選擇Runtime jRE:run in the same JRE as workspace.

記得要引入上面需要的幾個jar包

UML是一種通用的建模語言，其表達能力相當的強，不僅可以用于軟件系統的建模，而且可用于業務建模以及其它非軟件系統建模。UML綜合了各種面向對象方法與表示法的優點，至提出之日起就受到了廣泛的重視并得到了工業界的支持。

本章將按視圖、模型元素、圖以及公共機制依次介紹UML的構造和基本元素，以使得讀者對UML有一個總體了解，其具體細節將在后續章節中詳細描述。

畫圖工具：eDraw、jude

 

歡迎大家繼續支持和關注我的博客：

http://hoojo.cnblogs.com

http://blog.csdn.net/IBM_hoojo

也歡迎大家和我交流、探討IT方面的知識。

email：hoojo_@126.com

如果你覺得本文不錯的話，請你點擊屏幕右下方的 。如果你以后會用到這篇文章的或覺得以后要重新翻閱的話，你可以點擊屏幕右下角的 。如果你覺得我的博文不錯或是想在第一時間看到我的動態的話，你可以點擊屏幕右下角 。如果你想說點什么的話，你可以點擊屏幕右下方的 。如果你都點過了，那真的太謝謝你了，兄弟太支持了。此時，或許你可以點擊 按鈕，然后看看博文的導航繼續瀏覽其他文章。

1. UML的組成

UML由視圖(View)、圖(Diagram)、模型元素(Model Element)和通用機制(General Mechanism)等幾個部分組成。

a) 視圖(View)： 是表達系統的某一方面的特征的UML建模元素的子集，由多個圖構成，是在某一個抽象層上，對系統的抽象表示。

b) 圖(Diagram)： 是模型元素集的圖形表示，通常是由弧（關系）和頂點（其他模型元素）相互連接構成的。

c) 模型元素(Model Element)：代表面向對象中的類、對象、消息和關系等概念，是構成圖的最基本的常用概念。

d) 通用機制(General Mechanism)：用于表示其他信息，比如注釋、模型元素的語義等。另外，UML還提供擴展機制，使UML語言能夠適應一個特殊的方法（或過程），或擴充至一個組織或用戶。

2. UML視圖的分類

UML是用來描述模型的，用模型來描述系統的機構或靜態特征，以及行為或動態特征。從不同的視角為系統構架建模，形成系統的不同視圖。

(1) 用例視圖(Use Case View)，強調從用戶的角度看到的或需要的系統功能，是被稱為參與者的外部用戶所能觀察到的系統功能的模型圖。

(2) 邏輯視圖(Logical View)，展現系統的靜態或結構組成及特征，也稱為結構模型視圖(Structural Model View)或靜態視圖(Static View)。

(3) 并發視圖(Concurrent View)，體現了系統的動態或行為特征，也稱為行為模型視圖(Behavioral Model View)或動態視圖(Dynamic View)。

(4) 組件視圖(Component View)，體現了系統實現的結構和行為特征，也稱為實現模型視圖(Implementation Model View)。

(5) 配置視圖(Deployment View)，體現了系統實現環境的結構和行為特征，也稱為環境模型視圖(Environment Model View)或物理視圖(Physical View)。

 

視圖是由圖組成的，UML提供9種不同的圖：

(1) 用例圖(Use Case Diagram)，描述系統功能；

(2) 類圖(Class Diagram)，描述系統的靜態結構；

(3) 對象圖(Object Diagram)，描述系統在某個時刻的靜態結構；

(4) 組件圖(Component Diagram)，描述了實現系統的元素的組織；

(5) 配置圖(Deployment Diagram)，描述了環境元素的配置，并把實現系統的元素映射到配置上；

(6) 狀態圖(State Diagram)，描述了系統元素的狀態條件和響應；

(7) 時序圖(Sequence Diagram)，按時間順序描述系統元素間的交互；

(8) 協作圖(Collaboration Diagram)，按照時間和空間順序描述系統元素間的交互和它們之間的關系；

(9) 活動圖(Activity Diagram)，描述了系統元素的活動；

建模方法由建模語言和建模過程兩部分構成。其中建模語言是用來表述設計方法的表示法，建模過程是對設計中所應采取的步驟的描述。UML是一種建模語言，它在很大程度上獨立于建模過程。在實際建模中，建模人員最好把UML用于以用案驅動的、以體系機構為中心的、迭代的和漸增式的開發過程中。

一般而言，軟件系統的體系結構給出了軟件系統的組織、組成系統的構造元素及其接口的選擇、系統的行為和體系結構風格等信息。也就是說，它不僅關心系統的結構和行為等功能性需求，而且也涉及系統的性能、易理解性、易復用性等非功能性需求。如下圖所示，UML利用用戶模型視圖、結構模型視圖、行為模型視圖、實現模型視圖和環境模型視圖來描述軟件系統的體系結構。

根據它們在不同架構視圖的應用，可以把9種圖分成：

(1) 用戶模型視圖：用例圖；

(2) 結構模型視圖：類圖和對象；

(3) 行為模型視圖：狀態圖、時序圖、協作圖和活動圖（動態圖）；

(4) 實現模型視圖：組件圖；

(5) 環境模型視圖：配置圖。

用戶模型視圖由專門描述最終用戶、分析人員和測試人員看到的系統行為的用案組成，它實際上是從用戶角度來描述系統應該具有的功能。用戶模型視圖所描述的系統功能依靠外部用戶或者另外一個系統來激活，為用戶或者另一系統提供服務，從而實現用戶或另一系統與系統的交互。系統實現的最終目標是提供用戶模型視圖中所描述的功能。在UML中，用戶模型視圖是由用案圖組成。

結構模型視圖描述組成系統的類、對象以及它們之間的關系等靜態結構，用來支持系統的功能需求，即描述系統內部功能是如何設計的。結構模型視圖由類圖和對象圖構成，主要供設計人員和開發人員使用。

行為模型視圖主要用來描述形成系統并發與同步機制的線程和進程，其關注的重點是系統的性能、易伸縮性和系統的吞吐量等非功能性需求。行為模型視圖利用并發來描述資源的高效使用、并行執行和處理異步事件。除了講系統劃分為并發執行的控制線程之外，行為模型還必須處理通信和這些線程及進程之間的同步問題。行為模型視圖主要供系統開發人員和系統集成人員使用，它由序列圖、協作圖、狀態圖和活動圖組成。

實現模型視圖用來描述系統的實現模塊它們之間的依賴關系以及資源分配情況。這種視圖主要用于系統的配置管理，它是由一些獨立的構件組成的。實現模型視圖由構件圖組成。其中構件是代碼模塊，不同類型的代碼模塊形成不同的構件。實現模型視圖主要供開發人員使用。

環境模型視圖用來描述物理系統的硬件拓撲結構。例如，系統中的計算機和設備的分布情況以及它們之間的連接方式，其中計算機和設備統稱為節點。在UML中環境模型視圖是由部署圖來表示的。系統部署圖描述了系統構件在節點上的分布情況，即用來描述軟件構件到物理節點的映射。部署圖主要供開發人員、系統集成人員和測試人員使用。

上面每一種視圖反映了系統的一個特定方面，不同人員可以單獨的使用其中每一種視圖，從而可以關注特定的體系結構問題。但在通常情況下，由于系統的最終目標是提供用戶模型視圖中描述的功能以及其它一些非功能性需求，因此，用戶模型視圖是其它視圖的核心基礎，其它視圖的構造都依賴與用戶模型視圖中所描述的類容。

細心的讀者已經發現，每一種UML圖都是由多個圖組成的，每一種圖都是體系結構某個側面的表示，各種圖實際上是一致的，所有的圖在一起組成了系統的完整視圖。如下圖所示，UML中總共提供了用案圖、類圖、對象圖、序列圖、協作圖、狀態圖、活動圖、構建圖和部署圖9種圖。根據它們描述的是系統的靜態結構還是動態行為，可以將它們分為靜態圖和動態圖兩類。再進一步介紹這9中UML圖時，先了解下什么是模型元素：

3. UML的建模機制

UML有兩套建模機制：靜態建模機制和動態建模機制。靜態建模機制包括用例圖、類圖、對象圖、包、組件圖和配置圖。動態建模機制包括狀態圖、時序圖、協作圖、活動圖。

(1) 用例圖：用例的可視化工具，它提供計算機系統的高層次的用戶視圖，表示以外部活動者的角度來看系統將是怎樣使用的。

用例圖（用案圖）是用于描述一組用案，參與者以及它們之間的連接關系。一個用案圖描述了一組動作序列，每一個序列表示系統的外部設施（系統的參與者）與系統本身的交互。從一個特定參與者的角度看，一個用案完成對其有價值的工作。如圖2.5所示，用案圖僅僅是從參與者使用系統的角度來描述系統中的信息，即站在系統外部查看系統應該具有什么功能，而并不描述該功能在軟件內部是如何實現的。用案可以應用于整個系統，也可以應用于系統的一個部分，包括子系統、單個的類或者接口。通常，用案不僅代表這些元素所期望的行為，而且還可以把這些元素用作開發過程中測試用案的基礎。

用例圖包括以下3方面內容：

(a) 用例(Use Case)

(b) 參與者(Actor)

(c) 依賴、泛化和關聯關系

用例圖示例：

(2) 類圖：描述類、接口、協作以及它們之間關系的圖。

類圖是用于描述一組類、接口、協作以及它們之間的靜態關系。在面向對象系統的建模中，類圖是最為常用的圖，它用來闡明系統的靜態結構。事實上類是對一組具有相同屬性、操作、關系和語義的對象的描述，其中對類的屬性和操作進行描述時的一個最重要的細節就是它的可見性。

類可以以多種形式連接，例如關聯、泛化、依賴和實現等。一個典型的系統中通常有若干個類圖。一個類圖不一定要包含系統中所有的類，一個類可以加到幾個類圖中。

類圖示例：

(3) 對象圖：表示在某一時間上一組對象以及它們之間的關系的圖。對象圖可以被看做是類圖在系統某一時刻的實例。

對象圖是類圖的實例，用來描述特定運行時刻一組對象之間的關系。也就是說，對象用于描述交互的靜態部分，它由參與協作的有關對象組成。但不包括在對象之間傳遞的任何消息。

在創建對象圖時，建模人員并不需要用單個的對象圖來描述系統中的每一個對象。事實上，絕大多數系統中都會包含成百上千的對象。用對象來描述系統的所有對象以及它們之間的關系一般是不太現實的。因此，建模人員可以選擇所感興趣的對象極其之間的關系來描述。

對象圖中所使用的符號和類圖中使用的符號幾乎完全相同，區別僅在于對象圖的對象名帶有下劃線，而且類與類之間關系的所有的實例都要畫出來。

(4) 組件圖：描述軟件組件以及組件之間的關系，組件本身是代碼的物理模塊，組件圖則顯示了代碼的結構。

組件圖（構件圖）是用于描述一組構件之間的組織和依賴關系，用于建模系統的靜態實現視圖。構件可以是可執行程序集、庫、表、文件和文檔等，它包含了邏輯類或者邏輯類的實現信息，因此結構模型視圖和實現模型視圖之間存在映射關系。

構建圖中也可以包括包或子系統，它們都是用于將模型元素組成較大的組塊。

組件圖例圖：

(5) 配置圖：描述系統硬件的物理拓撲結構以及在此結構上執行的軟件。配置圖可以顯示計算節點的拓撲結構和通信路徑、結點上運行的軟件組件、軟件組件包含的邏輯單元（對象、類）等。配置圖常常用于幫助理解分布式系統。

配置圖（部署圖）用來描述系統運行是進行處理的節點以及在節點上活動的構件的配置。部署圖用來對系統的環境模型視圖進行建模。在大多數情況下，部署圖用來描述系統硬件的擴普結構。

在UML中，建模人員可以用類圖來描述系統的靜態結構，可以用序列圖、協作圖、狀態圖、活動圖來描述系統的動態行為，而用部署圖來描述軟件所執行所需的處理器和設備的拓撲結構。

(6) 狀態圖：通過類對象的生命周期建立模型來描述對象隨時間變化的動態行為。

狀態圖實際上是一種由狀態、變遷、事件和活動組成的狀態機。狀態圖描述從狀態到狀態的控制流，常用于系統的動態特性建模。在大多數情況下，它用來對反應型對象的行為建模。

在UML中，狀態圖可以用來對一個對象按事件排序的行為建模。一個狀態圖是強調從狀態到狀態的控制流的狀態機的簡單表示。一般而言，狀態圖是對類所描述的設施的補充說明，它描述了類的所有對象可能具有的狀態以及引起狀態變化的事件。

(7) 時序圖：交互圖描述了一個交互，它由一組對象和它們之間的關系組成，并且還包括在對象間傳遞的信息。交互圖表達對象之間的交互，是描述一組對象如何協作完成某個行為的模型化工具。

序列圖和協作圖統稱為交互圖。其中，序列圖用來描述對象之間消息發送的先后次序，闡明對象之間的交互過程以及在系統執行過程中的某一具體時刻將會發生什么事件。序列圖是一種強調時間順序的交互圖，其中對象沿橫軸方向排列，消息沿縱軸方向排列。

序列圖中的對象生命線是一條垂直的虛線，它表示一個對象在一段時間內存在。由于序列圖中大多數對象都存在于整個交互過程中，因此這些對象全部排列在圖的頂部，它們的生命線從圖的頂部畫到圖的底部。每個對象的下方有一個矩形條，它與對象的生命線重疊，它表示該對象的控制焦點。序列圖中的消息可以有序號，但由于這種圖上的消息已經從縱軸上按時間順序排序，因此消息序號通常予以省略。

(8) 協作圖：包含類元角色和關聯角色，而不僅僅是類元和關聯。協作圖強調參加交互的各對象的組織。協作圖只對相互間有交互作用的對象和這些對象間的關系建模，而忽略了其他對象和關聯。協作圖也是一種交互圖，它強調收發消息的對象的組織結構。

協作圖和序列圖是協作的，它們可以互相轉換。在多數情況下，協作圖主要對單調的、順序的控制流建模，但它也可以用來對包括迭代和分支在內的復雜控制流進行建模。

一般而言，建模人員可以創建多個協作圖，其中一些是主要的，另外一些是可選擇的路徑或者異常條件。建模人員可以用包來組織這些協作圖，并給每個圖起一個合適的名字，以便與其它圖區別開。

(9) 活動圖：用于展現參與行為的類的活動或動作。

活動圖是狀態圖的一種特殊情況，其中幾乎所有或大多數狀態都處于活動狀態，而且幾乎所有或者大多數變遷都是由源狀態中活動的完成觸發的。活動圖本質上是一種流程圖，它描述了從活動到活動的控制流。

可以把活動圖看作是新樣的交互圖，但交互圖觀察的是傳遞消息的對象，而活動圖觀察到的是對象之間傳送的消息。盡管兩者在語義上的區別很細微，但它們使用不同的方式來看系統的。

如果你覺得本文不錯的話，請你點擊屏幕右下方的 。如果你以后會用到這篇文章的或覺得以后要重新翻閱的話，你可以點擊屏幕右下角的 。如果你覺得我的博文不錯或是想在第一時間看到我的動態的話，你可以點擊屏幕右下角 。如果你想說點什么的話，你可以點擊屏幕右下方的 。如果你都點過了，那真的太謝謝你了，兄弟太支持了。此時，或許你可以點擊 按鈕，然后看看博文的導航繼續瀏覽其他文章。

最后，歡迎大家繼續支持和關注我的博客：

http://hoojo.cnblogs.com

http://blog.csdn.net/IBM_hoojo

也歡迎大家和我交流、探討IT方面的知識。

一、UML中的六大關系

在UML類圖中，常見的有以下幾種關系: 泛化（Generalization）, 實現（Realization），關聯（Association)，聚合（Aggregation），組合(Composition)，依賴(Dependency)。

1.1、 繼承關系—泛化（Generalization）

指的是一個類（稱為子類、子接口）繼承另外的一個類（稱為父類、父接口）的功能，并可以增加它自己的新功能的能力，繼承是類與類或者接口與接口之間最常見的關系；在Java中用extends關鍵字。

【泛化關系】是一種繼承關系，表示一般與特殊的關系，它指定了子類如何特化父類的所有特征和行為。例如：貓頭鷹是鳥的一種，即有鳥的特性也有貓頭鷹的共性。

【箭頭指向】帶三角箭頭的實線，箭頭指向父類。

【描述】上圖中的類bird有嘴、翅膀、羽毛等屬性。會飛、會唧唧喳喳的叫，那么就有這些方法。而貓頭鷹有大眼睛和捕捉老鼠的本領，這則是自身的特性。

1.2、 實現關系（Realization）

指的是一個class類實現interface接口（可以是多個）的功能；實現是類與接口之間最常見的關系；在Java中此類關系通過關鍵字implements明確標識。

【實現關系】是一種類與接口的關系，表示類是接口所有特征和行為的實現.

【箭頭指向】帶三角箭頭的虛線，箭頭指向接口。

【描述】上圖中IFly是一個接口，接口中有時間、速度等常量，還有一個fly方法。FlyImpl繼承了這個IFly接口后，需要實現fly方法，同時實現類也可以擁有自己的屬性和方法。

1.3、 依賴（Dependency）

可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關系是具有偶然性的、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關系就是依賴；表現在代碼層面，為類B作為參數、屬性被類A在某個method方法中使用；

【依賴關系】是一種使用的關系，即一個類的實現需要另一個類的協助，所以要盡量不使用雙向的互相依賴。

【代碼表現】局部變量、方法的參數或者對靜態方法的調用

【箭頭及指向】帶箭頭的虛線，指向被使用者

【描述】Bird類中有一個setFly方法，它需要使用者用到IFly接口的實現，那么這種關系就是依賴關系。

1.4、 關聯

他體現的是兩個類、或者類與接口之間語義級別的一種強依賴關系，比如我和我的朋友；這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，而且雙方的關系一般是平等的、關聯可以是單向、雙向的；表現在代碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；

【關聯關系】是一種擁有的關系，它使一個類知道另一個類的屬性和方法；如：老師與學生，丈夫與妻子關聯可以是雙向的，也可以是單向的。雙向的關聯可以有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭。

【代碼體現】成員變量

【箭頭及指向】帶普通箭頭的實心線，指向被擁有者

【描述】在Bird類中有一個IFly類型的fly屬性，需要提供IFly的接口實現。Bird對象會利用IFly接口的實現完成fly方法。

1.4.1、雙向關聯

雙方都知道對方的存在，都可以調用對方的公共屬性、方法。

【關聯關系】雙方都有關聯的關系，通過自身對對方關聯的屬性來訪問對方的屬性和方法。

【代碼體現】成員變量

【箭頭及指向】用不帶箭頭的實線連接雙方

【描述】在中國一個妻子只能嫁給一個丈夫，一個丈夫也只能取一個妻子。

1.4.2、自身關聯

自己關聯自己，這種情況比較少出現但是也有用到。

【自關聯關系】雙方都有關聯的關系，通過自身對自身關聯的屬性引用來訪問對方的屬性和方法。

【代碼體現】成員變量

【箭頭及指向】用帶普通箭頭的實線連接自己

【描述】在盜夢空間中，演員需要在夢中再造夢，這種夢中夢的情況跟上圖描述很符合。

 

1.5、 聚合（Aggregation）

聚合是關聯關系的一種特例，他體現的是整體與部分、擁有的關系，即has-a的關系，此時整體與部分之間是可分離的，他們可以具有各自的生命周期，部分可以屬于多個整體對象，也可以為多個整體對象共享；比如計算機與CPU、公司與員工的關系等；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；

【聚合關系】是整體與部分的關系，且部分可以離開整體而單獨存在。如車和輪胎是整體和部分的關系，輪胎離開車仍然可以存在。聚合關系是關聯關系的一種，是強的關聯關系；關聯和聚合在語法上無法區分，必須考察具體的邏輯關系。

【代碼體現】成員變量

【箭頭及指向】帶空心菱形的實心線，菱形指向整體

【描述】birdChild一只鳥有很多鳥寶寶，所以自引用。鳥有很多不同數量和顏色的羽毛，所以引用關系是0~*。

1.6、 組合（Composition）

組合也是關聯關系的一種特例，他體現的是一種contains-a的關系，這種關系比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關系，但此時整體與部分是不可分的，整體的生命周期結束也就意味著部分的生命周期結束；比如你和你的大腦；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；

【組合關系】是整體與部分的關系，但部分不能離開整體而單獨存在。如公司和部門是整體和部分的關系，沒有公司就不存在部門。組合關系是關聯關系的一種，是比聚合關系還要強的關系，它要求普通的聚合關系中代表整體的對象負責代表部分的對象的生命周期。

【代碼體現】成員變量

【箭頭及指向】帶實心菱形的實線，菱形指向整體

【描述】一個學校由多個班級組成，班級離開學校也就不存在、而學校離開班級也不成立。像這種不可分離的關系就需要用組合。

綜合示例

對于繼承、實現這兩種關系沒多少疑問，他們體現的是一種類與類、或者類與接口間的縱向關系；其他的四者關系則體現的是類與類、或者類與接口間的引用、橫向關系，是比較難區分的，有很多事物間的關系要想準備定位是很難的，前面也提到，這幾種關系都是語義級別的，所以從代碼層面并不能完全區分各種關系；但總的來說，后幾種關系所表現的強弱程度依次為：泛化 = 實現 > 組合 > 聚合 > 關聯 > 依賴。

異常信息如下：

org.springframework.beans.ConversionNotSupportedException: Failed to convert property value of type 'java.util.Date' to required type 'java.sql.Timestamp' for property 'wfsj'; nested exception is java.lang.IllegalStateException: Cannot convert value of type [java.util.Date] to required type [java.sql.Timestamp] for property 'wfsj': no matching editors or conversion strategy found

    at org.springframework.beans.BeanWrapperImpl.convertIfNecessary(BeanWrapperImpl.java:463)

    at org.springframework.beans.BeanWrapperImpl.convertForProperty(BeanWrapperImpl.java:494)

    at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1097)

    at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:882)

    at org.springframework.flex.core.io.SpringPropertyProxy.setValue(SpringPropertyProxy.java:182)

    at flex.messaging.io.amf.Amf3Input.readScriptObject(Amf3Input.java:438)

    at flex.messaging.io.amf.Amf3Input.readObjectValue(Amf3Input.java:152)

    at flex.messaging.io.amf.Amf3Input.readObject(Amf3Input.java:130)

    at flex.messaging.io.amf.Amf3Input.readArray(Amf3Input.java:358)

    …………

    at flex.messaging.io.amf.AmfMessageDeserializer.readObject(AmfMessageDeserializer.java:227)

    at flex.messaging.io.amf.AmfMessageDeserializer.readBody(AmfMessageDeserializer.java:206)

    at flex.messaging.io.amf.AmfMessageDeserializer.readMessage(AmfMessageDeserializer.java:126)

    at flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:145)

    at flex.messaging.endpoints.BaseHTTPEndpoint.service(BaseHTTPEndpoint.java:291)

    at flex.messaging.endpoints.AMFEndpoint$$EnhancerByCGLIB$$6f090fa2.service(<generated>)

    at org.springframework.flex.servlet.MessageBrokerHandlerAdapter.handle(MessageBrokerHandlerAdapter.java:109)

    …………

Caused by: java.lang.IllegalStateException: Cannot convert value of type [java.util.Date] to required type [java.sql.Timestamp] for property 'wfsj': no matching editors or conversion strategy found

    at org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeConverterDelegate.java:264)

    at org.springframework.beans.BeanWrapperImpl.convertIfNecessary(BeanWrapperImpl.java:448)

    ... 59 more

看異常信息大概知道屬性wfsj這個字段，不能完成java.util.Date 到 java.sql.Timestamp 日期時間戳的轉換。后面還有提示， 沒有找到匹配的conversion或editor。

conversion 在Spring中轉換對象屬性會用到，而editor和converter 以及formatter也是在轉換對象（String –> Date, String –> Timestamp），從字符串到對象，從對象到字符串的時候會經常用到。

解決方法：

<bean id="customConfigProcessor" class="com.jp.tic.framework.flex.converter.CustomAmfConversionServiceConfigProcessor"/>

<flex:message-broker services-config-path="/WEB-INF/flex/services-config.xml">

    <flex:exception-translator ref="flexExceptionTranslator" />

    <flex:config-processor ref="configProcessor"/>

    <flex:config-processor ref="customConfigProcessor"/>

    <!--<flex:message-interceptor ref="flexMessageInterceptor" />

    <flex:message-interceptor ref="loginMessageInterceptor" />-->

</flex:message-broker>

為message-broker對象注入CustomAmfConversionServiceConfigProcessor對象，CustomAmfConversionServiceConfigProcessor是繼承AbstractAmfConversionServiceConfigProcessor對象。

AbstractAmfConversionServiceConfigProcessor對象中提供了對各個類型轉換serialization/deserialization的方法。

 

package com.jp.tic.framework.flex.converter;

import java.util.HashSet;

import java.util.Set;

import org.springframework.flex.core.io.AbstractAmfConversionServiceConfigProcessor;

/**

 * <b>function:</b> 自定義AMF轉換服務

 * @author hoojo

 * @createDate 2013-7-17 下午01:35:12

 * @file CustomAmfConversionServiceConfigProcessor.java

 * @package com.jp.tic.framework.flex.converter

 * @project JTZHJK-Server

 * @blog http://blog.csdn.net/IBM_hoojo

 * @email hoojo_@126.com

 * @version 1.0

 */

public class CustomAmfConversionServiceConfigProcessor extends AbstractAmfConversionServiceConfigProcessor {

    private static Set<Class<?>> classes = new HashSet<Class<?>>();

    @Override

    protected Set<Class<?>> findTypesToRegister() {

        return classes;

    }

}

如果你還需要添加更多自己的轉化服務，那么你需要給CustomAmfConversionServiceConfigProcessor 注入conversionService對象。

<!-- 添加配置類型轉換器、轉換服務 -->

    <bean id="conversionService" class="org.springframework.format.support.FormattingConversionServiceFactoryBean">

         <property name="converters">

            <list>

                <bean class="com.jp.tic.framework.mvc.convert.StringToTimestampConverter"/>

                <bean class="com.jp.tic.framework.mvc.convert.DateToTimestampConverter"/>

            </list>

        </property>

        <property name="formatters">

            <list>

                <bean class="com.jp.tic.framework.mvc.formatter.SimpleDateTimeFormatAnnotationFormatterFactory"/>

                <bean class="com.jp.tic.framework.mvc.formatter.TimestampFormatterFactory"/>

            </list>

        </property>

    </bean>

 

 

<bean id="customConfigProcessor" class="com.jp.tic.framework.flex.converter.CustomAmfConversionServiceConfigProcessor">

    <property name="conversionService" ref="conversionService"/>

</bean>

Eclipse下的Java反編譯插件：Eclipse Class Decompiler，整合了目前最好的2個Java反編譯工具Jad和JD-Core，并且和Eclipse Class Viewer無縫集成，能夠很方便的使用本插件查看類庫源碼，以及采用本插件進行Debug調試。

轉載自：http://bbs.csdn.net/topics/390263414

Eclipse Class Decompiler插件： http://download.csdn.net/detail/ibm_hoojo/5250263
下載后，解壓可以看到如下目錄，復制所有文件粘貼到你的eclipse或MyEclipse的目錄：D:\MyEclipse 6.5\myeclipse\eclipse下，選擇覆蓋即可。然后重新啟動eclipse。
 

下圖為Eclipse Class Decompiler的首選項頁面，可以選擇缺省的反編譯器工具，并進行反編譯器的基本設置。缺省的反編譯工具為JD-Core，JD-Core更為先進一些，支持泛型、Enum、注解等JDK1.5以后才有的新語法。

首選項配置選項：
1.重用緩存代碼：只會反編譯一次，以后每次打開該類文件，都顯示的是緩存的反編譯代碼。
2.忽略已存在的源代碼：若未選中，則查看Class文件是否已綁定了Java源代碼，如果已綁定，則顯示Java源代碼，如果未綁定，則反編譯Class文件。若選中此項，則忽略已綁定的Java源代碼，顯示反編譯結果。
3.顯示反編譯器報告：顯示反編譯器反編譯后生成的數據報告及異常信息。
4.使用Eclipse代碼格式化工具：使用Eclipse格式化工具對反編譯結果重新格式化排版，反編譯整個Jar包時，此操作會消耗一些時間。
5.使用Eclipse成員排序：使用Eclipse成員排序對反編譯結果重新格式化排版，反編譯整個Jar包時，此操作會消耗大量時間。
6.以注釋方式輸出原始行號信息：如果Class文件包含原始行號信息，則會將行號信息以注釋的方式打印到反編譯結果中。
7.根據行號對齊源代碼以便于調試：若選中該項，插件會采用AST工具分析反編譯結果，并根據行號信息調整代碼順序，以便于Debug過程中的單步跟蹤調試。
8.設置類反編譯查看器作為缺省的類文件編輯器：默認為選中，將忽略Eclipse自帶的Class Viewer，每次Eclipse啟動后，默認使用本插件提供的類查看器打開Class文件。

插件提供了系統菜單，工具欄，當打開了插件提供的類反編譯查看器后，會激活菜單和工具欄選項，可以方便的進行首選項配置，切換反編譯工具重新反編譯，以及導出反編譯結果。

類反編譯查看器右鍵菜單包含了Eclipse自帶類查看器右鍵菜單的全部選項，并增加了一個“導出反編譯源代碼”菜單項。

打開項目路徑下的Class文件，如果設置類反編譯查看器為缺省的查看器，直接雙擊Class文件即可，如果沒有設置為缺省查看器，可以使用右鍵菜單進行查看。

Eclipse Class Decompiler插件也提供了反編譯整個Jar文件或者Java包的反編譯。該操作支持Package Explorer對包顯示布局的操作，如果是平鋪模式布局，則導出的源代碼不包含子包，如果是層級模式布局，則導出選中的包及其所有的子包。

Debug調試：可以在首選項選中對齊行號進行單步跟蹤調試，和普通的包含源代碼時的調試操作完全一致，同樣的也可以設置斷點進行跟蹤。

轉載：http://bbs.csdn.net/topics/390263414

本人是做Java開發的，在程序開發中會經常使用到OpenSource開源框架，這些框架大多都靈活、簡單、易用、方便。而且開源框架一般會提供一些基本的配置，如我們常用的框架就有Hibernate要配置對象實體到數據庫的映射；Spring要配置bean的管理及其對象、屬性的注入；Struts要配置Action對象和返回的資源路徑；MyBatis要配置CRUD（增刪改查）的相關SQL語句。這些配置你不能省略，必須得有，沒有程序也不會自動添加。我們也是極可能的簡化這些配置，不管怎么樣簡化但這些配置是不能省略，雖然這些框架給我們開發程序都提供了很大方面上的便利。

但有時候你是否有糾結這么樣的一個問題：到底是用XML配置？還是用Annotation注解配置？或是用XML和Annotation混合配置？

首先看看兩種配置的優缺點比較

XML它是無可代替的超文本標記語言，可讀性、傳輸性好，它還具有一下優點：
1、可讀性、傳輸性好：XML可擴展標記語言，最大的優勢在于開發者能夠為軟件量身定制適用的標記，使代碼可讀性大大提升。
2、靈活性、易用性、擴展性、移植性好：利用XML配置能使軟件更具擴展性。如Spring將class間的依賴配置在XML中，最大限度地提升應用的可擴展性。同樣，如果是基于接口注入方式，可以隨便切換接口實現類進行注入即可。
3、驗證機制：具有成熟的驗證機制確保程序正確性。利用Schema或DTD可以對XML的正確性進行驗證，避免了非法的配置導致應用程序出錯。
4、修改配置而無需變動現有程序、無需重新編譯。

雖然XML有如此多的好處，但它也不是萬能的，XML也有自身的缺點：
1、開發友好性支持：需要解析工具或類庫的支持。如果你的XML配置需要用到XML的提示或是解析編譯，需要用到Schema或DTD進行驗證。
2、性能影響：解析XML勢必會影響應用程序性能，占用系統資源。至少你會用到一些解析XML的技術去解析節點元素內容。
3、維護性高：配置文件過多導致管理變得困難。
4、編譯期無法對其配置項的正確性進行驗證，或要查錯只能在運行期。如Spring Bean配置了一個錯誤的類路徑class。
5、IDE 無法驗證配置項的正確性無能為力。如Spring注入一個錯誤的對象或屬性。
6、查錯變得困難。往往配置的一個手誤導致莫名其妙的錯誤。
7、開發人員不得不同時維護代碼和配置文件，開發效率變得低下。
8、配置項與代碼間存在潛規則，改變了任何一方都有可能影響另外一方。

讓我們來看看Annotation的優點
1、保存在class文件中，降低維護成本。
2、無需工具支持，無需解析。
3、編譯期即可驗證正確性，查錯變得容易，雖然有部分錯誤需要在運行期間才能看到。
4、配置簡單、簡約，提升開發效率。

同樣Annotation也不是萬能的，它也有很多缺點
1、若要對配置項進行修改，不得不修改Java文件，重新編譯打包應用。
2、配置項編碼在Java文件中，可擴展性差、移植性性低。

那到底用什么樣的配置呢，在這里我談談我個人的看法：
1、在開發期間我們用Annotation注解，這樣在一定程度上不僅可以省去對XML配置文件的維護，而且大大的提高了開發效率，縮短了開發周期。
2、開發后期，項目功能完成，我們可以將Annotation配置轉換為XML配置，禁用Annotation即可。這樣做的理由是如果項目上線，我們需要修改相關代碼的配置，直接改XML、properties配置文件即可。這樣就不需要開發人員找到相應的代碼修改源代碼、重新編譯打包發布。而xml的配置是可以直接修改的，不需要重新編譯，只需重啟下你的服務器即可。

如果這樣是不是即利用到框架給我們提供的Annotation注解，也利用到了XML配置。充分的發揮了開源框架給我們提供的技術應用。

3、混合模式，Annotation和XML相互運用。需要動態配置、后期經常性修改的就用XML配置，如果是不怎么修改的就用Annotation。或許這種混合模式更適合我們，你覺得呢？O(∩_∩)O~

1. 全文檢索系統與Lucene簡介

1.1 什么是全文檢索與全文檢索系統

全文檢索是指計算機索引程序通過掃描文章中的每一個詞，對每一個詞建立一個索引，指明該詞在文章中出現的次數和位置，當用戶查詢時，檢索程序就根據事先建立的索引進行查找，并將查找的結果反饋給用戶的檢索方式。這個過程類似于通過字典中的檢索字表查字的過程。

全文檢索的方法主要分為按字檢索和按詞檢索兩種。按字檢索是指對于文章中的每一個字都建立索引，檢索時將詞分解為字的組合。對于各種不同的語言而言，字有不同的含義，比如英文中字與詞實際上是合一的，而中文中字與詞有很大分別。按詞檢索指對文章中的詞，即語義單位建立索引，檢索時按詞檢索，并且可以處理同義項等。英文等西方文字由于按照空白切分詞，因此實現上與按字處理類似，添加同義處理也很容易。中文等東方文字則需要切分字詞，以達到按詞索引的目的，關于這方面的問題，是當前全文檢索技術尤其是中文全文檢索技術中的難點，在此不做詳述。

全文檢索系統是按照全文檢索理論建立起來的用于提供全文檢索服務的軟件系統。一般來說，全文檢索需要具備建立索引和提供查詢的基本功能，此外現代的全文檢索系統還需要具有方便的用戶接口、面向WWW[1]的開發接口、二次應用開發接口等等。功能上，全文檢索系統核心具有建立索引、處理查詢返回結果集、增加索引、優化索引結構等等功能，外圍則由各種不同應用具有的功能組成。結構上，全文檢索系統核心具有索引引擎、查詢引擎、文本分析引擎、對外接口等等，加上各種外圍應用系統等等共同構成了全文檢索系統。圖1.1展示了上述全文檢索系統的結構與功能。

在上圖中，我們看到：全文檢索系統中最為關鍵的部分是全文檢索引擎，各種應用程序都需要建立在這個引擎之上。一個全文檢索應用的優異程度，根本上由全文檢索引擎來決定。因此提升全文檢索引擎的效率即是我們提升全文檢索應用的根本。另一個方面，一個優異的全文檢索引擎，在做到效率優化的同時，還需要具有開放的體系結構，以方便程序員對整個系統進行優化改造，或者是添加原有系統沒有的功能。比如在當今多語言處理的環境下，有時需要給全文檢索系統添加處理某種語言或者文本格式的功能，比如在英文系統中添加中文處理功能，在純文本系統中添加XML或者HTML格式的文本處理功能，系統的開放性和擴充性就十分的重要。

1.2 什么是Lucene

Lucene是apache軟件基金會jakarta項目組的一個子項目，是一個開放源代碼的全文檢索引擎工具包，即它不是一個完整的全文檢索引擎，而是一個全文檢索引擎的架構，提供了完整的查詢引擎和索引引擎，部分文本分析引擎（英文與德文兩種西方語言）。Lucene的目的是為軟件開發人員提供一個簡單易用的工具包，以方便的在目標系統中實現全文檢索的功能，或者是以此為基礎建立起完整的全文檢索引擎。

Lucene的原作者是Doug Cutting，他是一位資深全文索引/檢索專家，曾經是V-Twin搜索引擎的主要開發者，后在Excite擔任高級系統架構設計師，目前從事于一些Internet底層架構的研究。早先發布在作者自己的http://www.lucene.com/，后來發布在SourceForge，2001年年底成為apache軟件基金會jakarta的一個子項目：http://jakarta.apache.org/lucene/。

1.3 Lucene的應用、特點及優勢

作為一個開放源代碼項目，Lucene從問世之后，引發了開放源代碼社群的巨大反響，程序員們不僅使用它構建具體的全文檢索應用，而且將之集成到各種系統軟件中去，以及構建Web應用，甚至某些商業軟件也采用了Lucene作為其內部全文檢索子系統的核心。apache軟件基金會的網站使用了Lucene作為全文檢索的引擎，IBM的開源軟件eclipse的2.1版本中也采用了Lucene作為幫助子系統的全文索引引擎，相應的IBM的商業軟件Web Sphere中也采用了Lucene。Lucene以其開放源代碼的特性、優異的索引結構、良好的系統架構獲得了越來越多的應用。

Lucene作為一個全文檢索引擎，其具有如下突出的優點：

（1）索引文件格式獨立于應用平臺。Lucene定義了一套以8位字節為基礎的索引文件格式，使得兼容系統或者不同平臺的應用能夠共享建立的索引文件。

（2）在傳統全文檢索引擎的倒排索引的基礎上，實現了分塊索引，能夠針對新的文件建立小文件索引，提升索引速度。然后通過與原有索引的合并，達到優化的目的。

（3）優秀的面向對象的系統架構，使得對于Lucene擴展的學習難度降低，方便擴充新功能。

（4）設計了獨立于語言和文件格式的文本分析接口，索引器通過接受Token流完成索引文件的創立，用戶擴展新的語言和文件格式，只需要實現文本分析的接口。

（5）已經默認實現了一套強大的查詢引擎，用戶無需自己編寫代碼即使系統可獲得強大的查詢能力，Lucene的查詢實現中默認實現了布爾操作、模糊查詢（Fuzzy Search）、分組查詢等等。

面對已經存在的商業全文檢索引擎，Lucene也具有相當的優勢：

首先，它的開發源代碼發行方式（遵守Apache Software License），在此基礎上程序員不僅僅可以充分的利用Lucene所提供的強大功能，而且可以深入細致的學習到全文檢索引擎制作技術和面相對象編程的實踐，進而在此基礎上根據應用的實際情況編寫出更好的更適合當前應用的全文檢索引擎。在這一點上，商業軟件的靈活性遠遠不及Lucene。其次，Lucene秉承了開放源代碼一貫的架構優良的優勢，設計了一個合理而極具擴充能力的面向對象架構，程序員可以在Lucene的基礎上擴充各種功能，比如擴充中文處理能力，從文本擴充到HTML、PDF等等文本格式的處理，編寫這些擴展的功能不僅僅不復雜，而且由于Lucene恰當合理的對系統設備做了程序上的抽象，擴展的功能也能輕易的達到跨平臺的能力。最后，轉移到apache軟件基金會后，借助于apache軟件基金會的網絡平臺，程序員可以方便的和開發者、其它程序員交流，促成資源的共享，甚至直接獲得已經編寫完備的擴充功能。最后，雖然Lucene使用Java語言寫成，但是開放源代碼社區的程序員正在不懈的將之使用各種傳統語言實現（例如.net framework），在遵守Lucene索引文件格式的基礎上，使得Lucene能夠運行在各種各樣的平臺上，系統管理員可以根據當前的平臺適合的語言來合理的選。

2. Lucene系統結構分析

2.1 系統結構組織

Lucene作為一個優秀的全文檢索引擎，其系統結構具有強烈的面向對象特征。首先是定義了一個與平臺無關的索引文件格式，其次通過抽象將系統的核心組成部分設計為抽象類，具體的平臺實現部分設計為抽象類的實現，此外與具體平臺相關的部分比如文件存儲也封裝為類，經過層層的面向對象式的處理，最終達成了一個低耦合高效率，容易二次開發的檢索引擎系統。

以下將討論Lucene系統的結構組織，并給出系統結構與源碼組織圖：

從圖中我們清楚的看到，Lucene的系統由基礎結構封裝、索引核心、對外接口三大部分組成。其中直接操作索引文件的索引核心又是系統的重點。Lucene的將所有源碼分為了7個模塊（在java語言中以包即package來表示），各個模塊所屬的系統部分也如上圖所示。需要說明的是org.apache.lucene.queryPaser是做為org.apache.lucene.search的語法解析器存在，不被系統之外實際調用，因此這里沒有當作對外接口看待，而是將之獨立出來。

從面象對象的觀點來考察，Lucene應用了最基本的一條程序設計準則：引入額外的抽象層以降低耦合性。首先，引入對索引文件的操作org.apache.lucene.store的封裝，然后將索引部分的實現建立在（org.apache.lucene.index）其之上，完成對索引核心的抽象。在索引核心的基礎上開始設計對外的接口org.apache.lucene.search與org.apache.lucene.analysis。在每一個局部細節上，比如某些常用的數據結構與算法上，Lucene也充分的應用了這一條準則。在高度的面向對象理論的支撐下，使得Lucene的實現容易理解，易于擴展。

Lucene在系統結構上的另一個特點表現為其引入了傳統的客戶端服務器結構以外的的應用結構。Lucene可以作為一個運行庫被包含進入應用本身中去，而不是做為一個單獨的索引服務器存在。這自然和Lucene開放源代碼的特征分不開，但是也體現了Lucene在編寫上的本來意圖：提供一個全文索引引擎的架構，而不是實現。

2.2 數據流分析

了解數據流分析的重要性：

理解Lucene系統結構的另一個方式是去探討其中數據流的走向，并以此摸清楚Lucene系統內部的調用時序。在此基礎上，我們能夠更加深入的理解Lucene的系統結構組織，以方便以后在Lucene系統上的開發工作。這部分的分析，是深入Lucene系統的鑰匙，也是進行重寫的基礎。

Lucene系統中的主要的數據流以及它們之間的關系圖：

圖2.2很好的表明了Lucene在內部的數據流組織情況，并且沿著數據流的方向我們也可以對與Lucene內部的執行時序有一個清楚的了解。現在將圖中的涉及到的流的類型與各個邏輯對應系統的相關部分的關系說明一下。

圖中共存在4種數據流，分別是文本流、token流、字節流與查詢語句對象流。文本流表示了對于索引目標和交互控制的抽象，即用文本流表示了將要索引的文件，用文本流向用戶輸出信息；在實際的實現中，Lucene中的文本流采用了UCS-2作為編碼，以達到適應多種語言文字的處理的目的。Token流是Lucene內部所使用的概念，是對傳統文字中的詞的概念的抽象，也是Lucene在建立索引時直接處理的最小單位；簡單的講Token就是一個詞和所在域值的組合，后面在敘述文件格式時也將繼續涉及到token，這里不詳細展開。字節流則是對文件抽象的直接操作的體現，通過固定長度的字節（Lucene定義為8比特位長，后面文件格式將詳細敘述）流的處理，將文件操作解脫出來，也做到了與平臺文件系統的無關性。查詢語句對象流則是僅僅在查詢語句解析時用到的概念，它對查詢語句抽象，通過類的繼承結構反映查詢語句的結構，將之傳送到查找邏輯來進行查找的操作。

圖中的涉及到了多種邏輯，基本上直接對應于系統某一模塊，但是也有跨模塊調用的問題發生，這是因為Lucene的重用程度非常好，因此很多實現直接調用了以前的工作成果，這在某種程度上其實是加強了模塊耦合性，但是也是為了避免系統的過于龐大和不必要的重復設計的一種折衷體現。詞法分析邏輯對應于org.apache.lucene.analysis部分。查詢語句語法分析邏輯對應于org.apache.lucene.queryParser部分，并且調用了org.apache.lucene.analysis的代碼。查詢結束之后向評分排序邏輯輸出token流，繼而由評分排序邏輯處理之后給出文本流的結果，這一部分的實現也包含在了org.apache.lucene.search中。索引構建邏輯對應于org.apache.lucene.index部分。索引查找邏輯則主要是org.apache.lucene.search，但是也大量的使用了org.apache.lucene.index部分的代碼和接口定義。存儲抽象對應于org.apache.lucene.store。沒有提到的模塊則是做為系統公共基礎設施存在。

2.3 基于Lucene的應用開發

首先，我們需要的是按照目標語言的詞法結構來構建相應的詞法分析邏輯，實現Lucene在org.apache.lucene.analysis中定義的接口，為Lucene提供目標系統所使用的語言處理能力。Lucene默認的已經實現了英文和德文的簡單詞法分析邏輯（按照空格分詞，并去除常用的語法詞，如英語中的is，am，are等等）。在這里，主要需要參考實現的接口在org.apache.lucene.analysis中的Analyzer.java和Tokenizer.java中定義，Lucene提供了很多英文規范的實現樣本，也可以做為實現時候的參考資料。其次，需要按照被索引的文件的格式來提供相應的文本分析邏輯，這里是指除開詞法分析之外的部分，比如HTML文件，通常需要把其中的內容按照所屬于域分門別類加入索引，這就需要從org.apache.lucene.document中定義的類document繼承，定義自己的HTMLDocument類，然后就可以將之交給org.apache.lucene.index模塊來寫入索引文件。完成了這兩步之后，Lucene全文檢索引擎就基本上完備了。這個過程可以用下圖表示：

下面是使用java語言開發，Lucene系統能夠方便的嵌入到整個系統中去，作為一個API集來調用。這個過程十分簡單，以下便是一個示例程序，配合注釋理解起來很容易。

2.4 Lucene索引文件格式

首先在Lucene的文件格式中，以字節為基礎，定義了如下的數據類型：

表 3.1 Lucene文件格式中定義的數據類型

數據類型	所占字節長度（字節）	說明
Byte	1	基本數據類型，其他數據類型以此為基礎定義
UInt32	4	32位無符號整數，高位優先
UInt64	8	64位無符號整數，高位優先
VInt	不定，最少1字節	動態長度整數，每字節的最高位表明還剩多少字節，每字節的低七位表明整數的值，高位優先。可以認為值可以為無限大。其示例如下 值 字節1 字節2 字節3 0 00000000     1 00000001     2 00000010     127 01111111     128 10000000 00000001   129 10000001 00000001   130 10000010 00000001   16383 10000000 10000000 00000001 16384 10000001 10000000 00000001 16385 10000010 10000000 00000001
Chars	不定，最少1字節	采用UTF-8編碼[20]的Unicode字符序列
String	不定，最少2字節	由VInt和Chars組成的字符串類型，VInt表示Chars的長度，Chars則表示了String的值

以上的數據類型就是Lucene索引文件格式中用到的全部數據類型，由于它們都以字節為基礎定義而來，因此保證了是平臺無關，這也是Lucene索引文件格式平臺無關的主要原因。接下來我們看看Lucene索引文件的概念組成和結構組成。

以上就是Lucene的索引文件的概念結構。Lucene索引index由若干段(segment)組成，每一段由若干的文檔（document）組成，每一個文檔由若干的域（field）組成，每一個域由若干的項（term）組成。項是最小的索引概念單位，它直接代表了一個字符串以及其在文件中的位置、出現次數等信息。域是一個關聯的元組，由一個域名和一個域值組成，域名是一個字串，域值是一個項，比如將“標題”和實際標題的項組成的域。文檔是提取了某個文件中的所有信息之后的結果，這些組成了段，或者稱為一個子索引。子索引可以組合為索引，也可以合并為一個新的包含了所有合并項內部元素的子索引。我們可以清楚的看出，Lucene的索引結構在概念上即為傳統的倒排索引結構。

從概念上映射到結構中，索引被處理為一個目錄（文件夾），其中含有的所有文件即為其內容，這些文件按照所屬的段不同分組存放，同組的文件擁有相同的文件名，不同的擴展名。此外還有三個文件，分別用來保存所有的段的記錄、保存已刪除文件的記錄和控制讀寫的同步，它們分別是segments，deletable和lock文件，都沒有擴展名。每個段包含一組文件，它們的文件擴展名不同，但是文件名均為記錄在文件segments中段的名字。讓我們看如下的結構圖3.2：

每個段的文件中，主要記錄了兩大類的信息：域集合與項集合。這兩個集合中所含有的文件在圖3.2中均有表明。由于索引信息是靜態存儲的，域集合與項集合中的文件組采用了一種類似的存儲辦法：一個小型的索引文件，運行時載入內存；一個對應于索引文件的實際信息文件，可以按照索引中指示的偏移量隨機訪問；索引文件與信息文件在記錄的排列順序上存在隱式的對應關系，即索引文件中按照“索引項1、索引項2…”排列，則信息文件則也按照“信息項1、信息項2…”排列。比如在圖3.2所示文件中，segment1.fdx與segment1.fdt之間，segment1.tii與segment1.tis、segment1.prx、segment1.frq之間，都存在這樣的組織關系。而域集合與項集合之間則通過域的在域記錄文件（比如segment1.fnm）中所記錄的域記錄號維持對應關系，在圖3.2中segment1.fdx與segment1.tii中就是通過這種方式保持聯系。這樣，域集合和項集合不僅僅聯系起來，而且其中的文件之間也相互聯系起來。此外，標準化因子文件和被刪除文檔文件則提供了一些程序內部的輔助設施（標準化因子用在評分排序機制中，被刪除文檔是一種偽刪除手段）。這樣，整個段的索引信息就通過這些文檔有機的組成。

2.5 一些公用的基礎類

基礎結構封裝，或者基礎類，由org.apache.lucene.util和org.apache.lucene.document兩個包組成，前者定義了一些常量和優化過的常用的數據結構和算法，后者則是對于文檔（document）和域（field）概念的一個類定義。以下我們用列表的方式來分析這些封裝類，指出其要點；

表 3.2 基礎類包org.apache.lucene.util

類	說明
Arrays	一個關于數組的排序方法的靜態類，提供了優化的基于快排序的排序方法sort
BitVector	C/C++語言中位域的java實現品，但是加入了序列化能力
Constants	常量靜態類，定義了一些常量
PriorityQueue	一個優先隊列的抽象類，用于后面實現各種具體的優先隊列，提供常數時間內的最小元素訪問能力，內部實現機制是哈析表和堆排序算法

表 3.3 基礎類包org.apache.lucene.document

類	說明
Document	是文檔概念的一個實現類，每個文檔包含了一個域表（fieldList），并提供了一些實用的方法，比如多種添加域的方法、返回域表的迭代器的方法
Field	是域概念的一個實現類，每個域包含了一個域名和一個值，以及一些相關的屬性
DateField	提供了一些輔助方法的靜態類，這些方法將java中Date和Time數據類型和String相互轉化

2.6 存儲抽象

org.apache.lucene.store包：存儲抽象是唯一能夠直接對索引文件存取的包，因此其主要目的是抽象出和平臺文件系統無關的存儲抽象，提供諸如目錄服務（增、刪文件）、輸入流和輸出流。在分析其實現之前，首先我們看一下UML圖；

圖 3.3 存儲抽象實現UML圖（一）

圖 3.4 存儲抽象實現UML圖（二）

圖 3.4 存儲抽象實現UML圖（三）

圖3.2到3.4展示了整個org.apache.lucene.store中主要的繼承體系。共有三個抽象類定義：Directory、InputStream和OutputStrem，構成了一個完整的基于抽象文件系統的存取體系結構，在此基礎上，實作出了兩個實現品：（FSDirectory，FSInputStream，FSOutputStream）和（RAMDirectory，RAMInputStream和RAMOutputStream）。前者是以實際的文件系統做為基礎實現的，后者則是建立在內存中的虛擬文件系統。前者主要用來永久的保存索引文件，后者的作用則在于索引操作時是在內存中建立小的索引，然后一次性的輸出合并到文件中去，這一點我們在后面的索引邏輯部分能夠看到。此外，還定以了org.apache.lucene.store.lock和org.apache.lucene.store.with兩個輔助內部實現的類用在實現Directory方法的makeLock的時候，以在鎖定索引讀寫之前來讓客戶程序做一些準備工作。

（FSDirectory，FSInputStream，FSOutputStream）的內部實現依托于java語言中的io類庫，只是簡單的做了一個外部邏輯的包裝。這當然要歸功于java語言所提供的跨平臺特性，同時也帶了一些隱患：文件存取的效率提升需要依耐于文件類庫的優化。如果需要繼續優化文件存取的效率，應該還提供一個文件與目錄的抽象，以根據各種文件系統或者文件類型來提供一個優化的機會。當然，這是應用開發者所不需要關系的問題。

（RAMDirectory，RAMInputStream和RAMOutputStream）的內部實現就比較直接了，直接采用了虛擬的文件RAMFile類（定義于文件RAMDirectory.java中）來表示文件，目錄則看作一個String與RAMFile對應的關聯數組。RAMFile中采用數組來表示文件的存儲空間。在此的基礎上，完成各項操作的實現，就形成了基于內存的虛擬文件系統。因為在實際使用時，并不會牽涉到很大字節數量的文件，因此這種設計是簡單直接的，也是高效率的。

3. Lucene索引構建邏輯模塊分析

3.1對象體系與UML圖

1． 項（Term）

項（Term）：包括概念所實際涉及的類、永久化類。項（Term）所表示的是一個字符串，它擁有域、頻數和位置信息等等屬性。因此，Lucene中設計了兩個類來表示這個概念，如下圖

圖 4.1 UML圖（－）

上圖中，有意的突出了類Term和TermInfo中的數據成員，因為它反映了對于項（Term）這個概念的具體表示。同時上圖中也同時列出了用于永久化項（Term）的代理類TermInfosWriter和TermInfosReader，它們完成永久化的功能，需要注意的是，TermInfosReader內部使用了數組indexTerms和indexInfos來存儲一系列項；而TermInfosWriter則是一個類似于鏈表的結構，通過一個other指向下一個TermInfosWriter，每一個TermInfosWriter只負責本身那個lastTerm和lastTi的永久化工作。這是一個設計上的技巧，通過批量讀取（或者稱為緩沖的方式）來獲得讀入時候的效率優化；而通過一個鏈表式的、各負其責的方式，來獲得寫出時候的設計簡化。

項（term）這部分的設計中，還有一些重要的接口和類：

圖 4.2 UML圖（二）

圖4.2中，我們看到三個類：TermEnum、TermDocs與TermPositions，第一個是抽象類，后兩個都是接口。TermEnum的設計主要用在后面Segment和Document等等的實現中，以提供枚舉其中每一個項（Term）的能力。TermDocs是一個接口，用來繼承以提供返回<document, frequency>值對的能力，通過這個接口就可以獲得某個項（Term）在某個文檔中出現的頻數。TermPositions則是在TermDocs上的擴展，將項（Term）在文檔中的位置信息也表示出來。TermDocs（TermPositions）接口的使用方式類似于java中的Enumration接口，即通過next方法跳轉，通過doc，freq等方法獲得當前的屬性值。

2． 域（Field）

由于Field的基本概念在org.apache.lucene.document中已經做了定義，因此在這部分主要是針對項文件（.fnm文件、.fdx文件、.fdt文件）所需要的信息再來設計一些類。

圖 4.3 UML圖（三）

圖 4.3中展示的，就是表示與域（Field）所關聯的屬性信息的類。其中isIndexed表示的這個域的值是否被索引過，即值是否被分詞然后索引；另外兩個屬性所表示的意思則很明顯：一個是域的名字，一個是域的編號。

關于域表和存取邏輯的UML圖：

FieldInfos即為域表的概念表示，內部采用了冗余的方式以獲取在通過域的編號訪問或者通過域的名字來訪問時候的高效率。FieldsReader與FieldsWriter則分別是寫出和讀入的代理類。在功能和實現上，這兩個類都比較簡單。

3． 文檔（document）

文檔（document）同樣也是在org.apache.lucene.document中定義過的結構。由于對于這部分比較重要，我們也來看看其UML圖：

圖 4.5 UML圖（五）

在圖4.5中我們看到，Document的設計基本上沿用了鏈表的處理方法。左邊的Document類作為一個數據外包類，用來提供對于內部結構DocumentFieldList的增加刪除訪問操作等等。DocumentFieldList才是實際上的數據存儲單位，它用了鏈表的處理方法，直接指向一個當前的Field對象和下一個DocumentFieldList對象，這個與前面的類似。為了能夠逐個訪問鏈表中的節點，還設計了DocumentFieldEnumeration枚舉類。

圖 4.6 UML圖（六）

實際上定義于org.apache.lucene.index中的有關于Document的就是永久化的代理類。在圖4.6中給出了其UML圖。需要說明的是為什么沒有出現讀入的方法：這個方法已經隱含在圖4.5中Document類中的add方法中了，結合圖2.4中的程序代碼段，我們就能夠清楚的理解這種設計。

4． 段（segment）

段（Segment）這一部分設計的比較特殊，在實現簡單的對象結構之上，還特意的設計了用于段之間合并的類。接下來，我們仍然采取對照UML分析的方式逐個敘述。接下來我們看Lucene中如何表示段這個概念。

圖 4.7 UML圖（七）

Lucene定義了一個類SegmentInfo用來表示每一個段（Segment）的信息，包括名字（name）、含有的文檔的數目（docCount）和段所位于的目錄的位置（dir）。根據索引文件中的段的意義，有了這三點，就能唯一確定一個段了。SegmentInfos這個類則是用來表示一個段的鏈表（從標準的java.util.Vector繼承而來），實際上，也就是索引（index）的意思了。需要注意的是，這里并沒有在SegmentInfo中安插一個文檔（document）的鏈表。這樣做的原因牽涉到Lucene內部對于文檔（相當于一個被索引文件）的處理；Lucene內部采用了賦予文檔編號，給域賦值的方式來處理文檔，即加入的文檔順次編號，以后用文檔號表示文檔，而路徑信息，文件名字等等在以后索引查找需要的屬性，都作為域存儲下來；因此SegmentInfo中并沒有另外存儲一個文檔（document）的鏈表，對于這些的寫出和讀入，則交給了永久化的代理類來做。

圖 4.8 UML圖（八）

圖4.8給出了負責段（segment）的讀入操作的代理類，而負責段（segment）的寫出操作也同樣沒有定義，這些操作都直接實現在了類IndexWriter類中。段的操作同樣采用了之前的數組或者說是緩沖的處理方式。

針對前面項（term）那部分定義的幾個接口，段（segment）這部分也需要做相應的接口實現，因為提供直接遍歷訪問段中的各個項的能力對于檢索來說，無疑是十分重要的。即這部分的設計，實際上都是在為了檢索在服務。

圖 4.9 UML圖（九）

圖 4.10 UML圖（十）

圖4.9和圖4.10分別展示了前面項（term）那里定義的接口是如何在這里通過繼承實現的。Lucene在處理這部分的時候，也是分成兩部分（Segment與Segments開頭的類）來實現，而且很合理的運用了數組的技法，以及注意了繼承重用。但是細化到局部，終歸是比較簡單的按照語義來獲得結果而已了。

Lucene為了兼顧建立索引時的效率和讀取索引查找的速度，引入了分小段建立索引的方式，即每一次批量建立索引時，先在內存中的虛擬文件系統中為每一個文檔單獨建立一個段，然后在輸出的時候將這些段合并之后輸出成為索引文件，這時僅僅存在一個段。多次建立的索引后，如果想優化索引文件，也可采取合并段的方法，將索引中的段合并成為一個段。我們來看一下在IndexWriter類中相應的方法的實現，來了解一下這中建立索引的實現。

在mergeSegments函數中，將用到幾個重要的類結構，它們記錄了合并時候的一些重要信息，完成合并時候的工作。接下來，我們來看這幾個類的UML圖：

圖 4.12 UML圖（十一）

從圖4.12中，我們看到Lucene設計一個類SegmentMergeInfo用來保存每一個被合并的段的信息，也保存能夠訪問其內部的接口句柄，也就是說合并時的操作使用這個類作為對被合并的段的操作代理。類SegmentMergeQueue則設計為org.apache.lucene.util.PriorityQueue的子類，做為SegmentMergeInfo的容器類，而且附帶能夠自動排序。SegmentMerger是主要進行操作的類，主要完成合并各個數據項的問題。

5． IndexReader類與IndexWirter類

最后剩下的，就是整個索引邏輯部分的使用接口類了。外界通過這兩個類以及文檔（document）類的構造函數調用之，比如圖2.4中的代碼示例所示。下面我們來看一下這部分最后兩個類的UML圖：

圖 4.13 UML圖（十二）

IndexWriter的設計與IndexReader的設計很不相同，前者是一個實現類，而后者是一個抽象類，帶有沒有實現的接口。IndexWriter的主要作用就是接收新加入的文檔（document），然后在內部為之生成相應的小段，最后再合并并向索引文件中輸出，圖4.11中已經給出了一些實現的代碼。由于Lucene在面向對象上封裝的努力，通過各個構造函數就已經完成了對于各個概念的構造過程，剩下部分的代碼主要是依據各個數組或者是鏈表中的信息，逐個逐個的將信息寫出到相應的文件中去了。IndexReader部分則只是做了接口設計，沒有具體的實現，這個和本部分所完成的主要功能有關：索引構建邏輯。設計這個抽象類的目的是，預先完成一些函數，為以后的檢索（search）部分的各種形式的IndexReader鋪平道路，也是利用了在同一個包內可以方便訪問其它類的保護變量這個java語言的限制。

3.2 數據流邏輯

從宏觀上明白一個系統的設計，理清楚其中的運行規律，最好的方式應該是通過數據流圖。在分析了各個位于索引構建邏輯部分的類的設計之后，我們接下來就通過分析數據流圖的方式來總結一下。但是由于之前提到的原因：索引讀入部分在這一部分并沒有完全實現，所以我們在數據流圖中主要給出的是索引構建的數據流圖。

對于圖4.14中所描述的內容，結合Lucene源代碼中的一些文件看，能夠加深理解。準備階段可以參考demo文件夾中的org.apache.lucene.demo.IndexFiles類和java文件夾中的org.apache.lucene.document文件包。索引構建階段的主要源碼位于java文件夾中org.apache.lucene.index.IndexWriter類，因此這部分可以結合這個類的實現來看。至于內存文件系統，比較復雜，但是這時的邏輯相對簡單，因此也不難理解。

上面的數據流圖十分清楚的勾畫除了整個索引構建邏輯這部分的設計：通過層層嵌套的類結構，在構建時候即分步驟有計劃的生成了索引結構，將之存儲到內存中的文件系統中，然后通過對內存中的文件系統優化合并輸出到實際的文件系統中。

本文是在我2010年學習Lucene的時候在互聯網上摘抄整理而來，當時是在一家電子商務公司做商品檢索需要用到Lucene，所以就研究了下。這篇文章也是在當時在網絡上閱讀Lucene相關知識整理而來的。