1. PMD

     1)PMD是一個代碼檢查工具，它用于分析 Java 源代碼，找出潛在的 問題：
1)潛在的bug：空的try/catch/finally/switch語句
2)未使用的代碼：未使用的局部變量、參數(shù)、私有方法等
3)可選的代碼：String/StringBuffer的濫用
4)復(fù)雜的表達式：不必須的if語句、可以使用while循環(huán)完成的for循環(huán)
5)重復(fù)的代碼：拷貝/粘貼代碼意味著拷貝/粘貼bugs
2)PMD特點：
1)與其他分析工具不同的是，PMD通過靜態(tài)分析獲知代碼錯誤。也就是說，在
不運行Java程序的情況下報告錯誤。
2)PMD附帶了許多可以直接使用的規(guī)則，利用這些規(guī)則可以找出Java源程序的許
多問題
3)用戶還可以自己定義規(guī)則，檢查Java代碼是否符合某些特定的編碼規(guī)范。
3)同時，PMD已經(jīng)與JDeveloper、Eclipse、jEdit、JBuilder、BlueJ、
CodeGuide、NetBeans、Sun JavaStudio Enterprise/Creator、
IntelliJ IDEA、TextPad、Maven、Ant、Gel、JCreator以及Emacs
集成在一起。
4)PMD規(guī)則是可以定制的: 可用的規(guī)則并不僅限于內(nèi)置規(guī)則。您可以添加新規(guī)則：
可以通過編寫 Java 代碼并重新編譯 PDM，或者更簡單些，編寫 XPath 表
達式，它會針對每個 Java 類的抽象語法樹進行處理。
5)只使用PDM內(nèi)置規(guī)則，PMD 也可以找到你代碼中的一些真正問題。某些問題可能
很小，但有些問題則可能很大。PMD 不可能找到每個 bug，你仍然需要做單元測
試和接受測試，在查找已知 bug 時，即使是 PMD 也無法替代一個好的調(diào)試器。
但是，PMD 確實可以幫助你發(fā)現(xiàn)未知的問題。

1. FindBugs

     1)FindBugs是一個開源的靜態(tài)代碼分析工具，基于LGPL開源協(xié)議，無需
運行就能對代碼進行分析的工具。不注重style及format，注重檢測真正
的bug及潛在的性能問題 ，尤其注意了盡可能抑制誤檢測(false positives)
的發(fā)生。以bytecode（*.class、*.jar）為對象進行檢查。除了單獨動作，還可
以用作Eclipse 的plug-in，以及嵌入Ant作為task之一 進行利用。
2)findbugs自帶檢測器的介紹:  findbugs自帶60余種Bad practice，80余種
Correntness，1種Internationalization，12種Malicious code
vulnerability，27種Multithreaded correntness，23種Performance，
43種Dodgy。
3)Findbugs的一些特點：
1)FindBugs主要著眼于尋找代碼中的缺陷，這就與其他類似工具有些區(qū)別了，
直接操作類文件（class文件）而不是源代碼。
2)FindBugs可以通過命令行、各種構(gòu)建工具（如Ant、Maven等）、獨立的
Swing GUI或是以Eclipse和NetBeans IDE插件的方式來運行。                
3)FindBugs輸出結(jié)果既可以是XML的，也可以是文本形式的。
4)開發(fā)者可以通過多種方式來使用FindBugs，最常見的是在新編寫模塊的代碼
分析以及對現(xiàn)有代碼進行更大范圍的分析。   
5)不注重style及format，注重檢測真正的bug及潛在的性能問題，
尤其注意了盡可能抑制誤檢測(false positives)的發(fā)生。    
4)FindBugs可檢測的bug pattern舉例:
檢測java programing中容易陷入的bug pattern，equals() 實現(xiàn)時的一般規(guī)約違反
Null pointer的參照 ，Method的返回值的check遺漏 ，初始化前field的訪問，
Multi-thread的正確性， 同期化處理的矛盾， 無條件的wait()，  Code的脆弱性 ，
可以變更的靜態(tài)object ，內(nèi)部數(shù)列參照的return等

1. Checkstyle

     1)定義： Checkstyle是一款檢查Java程序源代碼樣式的工具。
2)特點：
1)它可以有效的幫助我們檢視代碼以便更好的遵循代碼編寫標準，特
別適用于小組開發(fā)時彼此間的樣式規(guī)范和統(tǒng)一。
2)Checkstyle提供了高可配置性，以便適用于各種代碼規(guī)范，所以
除了使用它提供的幾種常見標準之外，你也可以定制自己的標準。
3)Checkstyle提供了支持大多數(shù)常見IDE的插件，大部分插件中就含有
最新的Checkstyle，就不用費心再部署一份了。
4)Checkstyle可以檢查代碼的很多方面，從傳統(tǒng)觀點看，它主要是用來
檢查代碼層面的，自從第三版以后，它的內(nèi)部架構(gòu)作了重大改變，很多
其它意圖的檢測加了進來，現(xiàn)在Checkstyle可以檢查像類設(shè)計的問題，
重復(fù)代碼，如鎖的雙重檢查的bug模式。
3)CheckStyle的主要流程是：
1)對Java文件進行詞法語法分析，生成語法樹。
2)載入配置文件（checkstyle-metadata.xml以及自定義的配置文件）
register check事件。
3)按照深度優(yōu)先遍歷對語法樹進行解析，按照注冊的事件，在到達某些節(jié)點
( AST ) 時進行style檢查（AST，A child-Sibling Tree，是語法
樹中的某個節(jié)點，其類型在TokenTypes類中定義。）
4)我們所說的自定義Style的檢查，就是在第二步設(shè)定的。
這里牽涉到一個叫com.puppycrawl.tools.checkstyle.api.Check 的類，
我們通常需要重載其中的兩個函數(shù)： public int[] getDefaultTokens()
        和public void visitToken(DetailAST ast). 這兩個函數(shù)的含義為，
在遍歷語法樹的過程中，每當(dāng)?shù)竭_getDefaultTokens函數(shù)所返回的AST類型，
程序就進入visitToken進行具體的檢查和分析，即，真正的分析檢查過程是在
visitToken中實現(xiàn)的。

1. Hammurapi

     1)定義： Hammurapi它是一個開源的代碼審查/評審(review)工具。它可以幫助改進
Java代碼的質(zhì)量。它可以基于一套設(shè)計規(guī)范來分析代碼庫。當(dāng)它碰到違反規(guī)
范的地方，會在報告中標識。就像Checkstyle一樣，它與Ant無縫集成并且
由基于XML配置文件來驅(qū)動。
2)特點：
1)Hammurapi是用來強制代碼設(shè)計規(guī)范的。
2)Hammurapi是一個遵循設(shè)計的工具，提供了自動而且一致的方式來實現(xiàn)設(shè)計規(guī)范，
因此使代碼評審更加有效而輕松。
3)Hammurapi如何工作：
         Hammurapi這樣的代碼分析工具都帶有語言分析器。語言分析器是一種輸入
語言代碼并輸出抽象語法樹的工具。這個樹上的節(jié)點代表語言標識。例如，考
慮一下簡單的算術(shù)表達式：3+4. 語言分析器會解析他成為一個如圖5所示的語
法樹。在這個樹中，節(jié)點+代表操作符標識。節(jié)點3和4是操作數(shù)標識Hammurapi
使用ANTLR（另一個語言識別工具）作為語言分析器。然而ANTLR API是相當(dāng)?shù)讓拥摹?
為改善可用性，Hammurapi使用另一個API，基于ANTLR 的JSEL（Java源程序
工程類庫），來訪問抽象語法樹。 一旦樹構(gòu)建完成，一種樹遍歷算法就被用來訪
問樹中每一個節(jié)點。每次訪問到一個節(jié)點，一種回調(diào)機制（Visitor模式）被用來
提示相應(yīng)的檢查器。在這些回調(diào)方法中，檢查器收集相關(guān)的信息來確定是否有違反
規(guī)范的地方存在。　　

1. Lint4j

     1)定義:Lint4J是一個針對Java的源代碼分析工具，它可以對Java源碼和字節(jié)
碼進行靜態(tài)分析，判斷其中是否存在死鎖、性能問題或者伸縮性問題。
它可以集成到任何IDE種或構(gòu)建系統(tǒng)
2)特點：
1)檢測代碼語法規(guī)則
2)潛在的bug
3)檢測編碼模式對代碼可讀性及大小的影響
4)檢測是否違反EJB規(guī)范

1. Sonar

     1)定義：代碼質(zhì)量管理工具Sonar提供了設(shè)計與架構(gòu)度量。Sonar 2.0引入了
針對Java應(yīng)用的設(shè)計分析、架構(gòu)與面向?qū)ο蟮亩攘浚琒onar 2.1可以
檢測到未使用的方法以及對不建議使用方法的調(diào)用。是一個集成了
CheckStyle,PMD,Findbugs的代碼校驗規(guī)則 ,重復(fù)代碼發(fā)現(xiàn)，
代碼測試覆蓋率， 代碼注釋率，及所有的檢測率變化追蹤的完美
代碼質(zhì)量檢查工具。它包含了代碼質(zhì)量檢測的七個方面，如下圖
2)特點：
        1)代碼覆蓋：通過單元測試，將會顯示哪行代碼被選中。
2)改善編碼規(guī)則。
3)搜尋編碼規(guī)則：按照名字，插件，激活級別和類別進行查詢。
4)項目搜尋：按照項目的名字進行查詢。
5)對比數(shù)據(jù)：比較同一張表中的任何測量的趨勢。
6)單元測試
3)Sonar2.1：
Sonar還基于Squid引入了一個全新的規(guī)則引擎、Sonar解析器既可以處
理源代碼，也可以處理字節(jié)碼，解析器帶有內(nèi)建的規(guī)則，可以檢測未使用
的私有與保護方法以及客戶端對不建議使用的方法的調(diào)用。
Squid通過分析應(yīng)用源代碼、Java API和外部程序庫
的字節(jié)碼來決定哪些方法、類和屬性是不建議使用的。
Sonar 2.1的新特性：
1)一個全新的“Libraries”頁面，顯示了項目中所有的程序庫和依賴，該特性要求使用
Maven來構(gòu)建項目。
一旦在Sonar站點的主頁上選擇了一個項目，該服務(wù)就會以
可視化的樹形結(jié)構(gòu)展示出項目依賴。此外，還有一個可選的
動態(tài)過濾器，可以根據(jù)名稱過濾程序庫以便在應(yīng)用的依賴間導(dǎo)航。
2)用于搜索程序庫使用情況的“Dependencies”頁面。比如說，可以
搜索到使用了第三方框架如Commons Logging 1.1的所有項目。
3)可以使用各種插件擴展Sonar的功能。現(xiàn)在有一個全新的
“System Info”頁面顯示了系統(tǒng)屬性、已裝插件和Java虛擬機內(nèi)存
統(tǒng)計信息。該頁面還給出了關(guān)于Sonar配置和數(shù)據(jù)庫統(tǒng)計的詳細信息。
4)一個用于管理已裝插件和系統(tǒng)信息的管理控制臺。
最新版的Sonar為這些插件引入了一個測試框架和一個客戶化的Maven
生命周期管理工具。它還帶有一個用于集成項目事件的
Web Service并在項目的size widget中增加了一個新的度量模塊。

1. JDepend

     1)JDepend一個開放源代碼的可以用來評價Java程序質(zhì)量的優(yōu)秀工具，
它遍歷Java class的文件目錄，以Java包（package）為
單位，為每一個包/類自動生成 包的依賴程度，穩(wěn)定性，可靠度等
的評價報告，根據(jù)這些報告，我們可以得到包或類之間的依賴關(guān)
系，并分析出包的穩(wěn)定程度，抽象程度，是否存在循環(huán)依耐關(guān)系等 。
可以根據(jù)JDepend給出的報告數(shù)據(jù)，分析出我們的包是否是
可靠的，穩(wěn)定的，健壯的包，是否符合面向?qū)ο蟮脑O(shè)計原則。
2)特點：
1)評價設(shè)計質(zhì)量
2)翻轉(zhuǎn)依賴性
3)支持并行開發(fā)和極限編程
4)獨立的發(fā)布模塊
5)識別package的循環(huán)依賴
3）Depend生成的Java包的質(zhì)量評價報告主要包括：    
1)Number of Classes and Interfaces：實現(xiàn)類與抽象接口的數(shù)目
2)Abstractness (A)：包的抽象度。指一個包內(nèi)包含的抽象類或接口
占整個包中的類的比重。
3)Afferent Couplings (Ca)：向心耦合。依賴該包（包含的類）的外
部包（類）的數(shù)目（i.e. incoming dependencies），該數(shù)值越大，
說明該包的擔(dān)當(dāng)?shù)穆氊?zé)越大，也就越穩(wěn)定。
4)Efferent Couplings (Ce)：離心耦合。被該包依賴的外部包的數(shù)目
（i.e. outgoing dependencies），該數(shù)值越大， 說明該包越不獨
立（因為依賴了別的包），也越不穩(wěn)定。
5)Instability (I)：衡量一個包的不穩(wěn)定程度。I=Ce/(Ce+Ca)。它的值處于
[0，1]之間。I=0時說明包是最穩(wěn)定的，反之I=1則說明包極不穩(wěn)定。
6)Distance from the Main Sequence (D)： 該指標主要用來評價包的抽象
程度與穩(wěn)定程度的平衡關(guān)系，它可以用二維直線圖 A + I = 1 來表示。
7)Package Dependency Cycles：包的循環(huán)依賴度。
8.  IBM Checking Tool for Bugs Errors and Mistakes(簡稱BEAM)
1) 定義：是 IBM 開發(fā)的一個靜態(tài)分析工具，可以用于分析并查找出 C, C++ 和 Java
代碼中的一些不容易發(fā)現(xiàn)的潛在錯誤，從而達到提高代碼質(zhì)量的目的。同動態(tài)
分析工具和其它靜態(tài)分析工具相比，它擁有一些可貴的特性。
2)特點：
1)對代碼進行語法掃描，通過算法對代碼進行檢查分析
2)和一些 bug 模式進行比較，最終標明問題區(qū)域，輸出分析結(jié)果
3)使用了額外的定理證明（theorem proving）技術(shù)來判斷一個潛在的錯誤是否
是真正的錯誤，從而減輕了程序員判斷錯誤真?zhèn)嗡璧墓ぷ髁?
 9. LDRA Testbed  
1)定義：LDRA Testbed為應(yīng)用軟件的確認和驗證提供強大的源代碼測試和分析功能，
是獨特的質(zhì)量控制工具。 它有助于提高計算機軟件必需的可靠性，健壯性和盡
可能的零缺陷，它的使用帶來時間、成本和效率上真實的節(jié)省，這些都是無法衡
量其價值的。它是強大和完整的集成工具包，使先進的軟件分析技術(shù)應(yīng)用在開發(fā)生
命周期的關(guān)鍵階段。
2)LDRA Testbed提供強大的分析功能，用于兩個主要的測試領(lǐng)域，靜態(tài)分析和動態(tài)分析。
1）靜態(tài)分析： 分析代碼，并且提供對代碼結(jié)構(gòu)的理解。
2）動態(tài)分析： 利用源代碼的插裝版本，使用測試數(shù)據(jù)執(zhí)行，在運行時發(fā)現(xiàn)軟件
缺陷
3) 使用LDRA testbed 的好處
軟件開發(fā)和測試過程的成本效率分析工具
單元、集成和系統(tǒng)測試的理想工具 
貫穿于軟件開發(fā)的整個生命周期
LDRA Testbed應(yīng)用于許多不同的領(lǐng)域 
過程改進
軟件測試
軟件維護
LDRA Testbed的優(yōu)點：
改進軟件質(zhì)量
定位軟件缺陷
強制執(zhí)行工業(yè)標準
減少維護費用40％以上
減少開發(fā)和測試成本75％以上
通過自動化過程提高員工動力
10.   Yasca 
1) 定義：yasca是一個開源靜態(tài)代碼分析工具插件框架,　集成流行的多語言靜態(tài)分析工
具如findbugs/pmd/jlint/rats/cppcheck,由于插件本身多樣故可支持java
c++等語言靜態(tài)分析.Yasca是一個用來尋找安全漏洞，在程序的源代碼中檢測代
碼質(zhì)量、性能以及一致性的軟件。它集成了其他開源項目，其中包括FindBugs
PMD ，JLint ， Cppcheck ，并掃描某些文件類型，以及自定義掃描書面的
Yasca 這是一個命令行工具，與報告中生成的HTML ， CSV格式， XML的，的
SQLite ，和其他格式。

　　Java Excel API 文檔

　　http://www.andykhan.com/jexcelapi/

  java api 幫助文檔 chm 1.5 1.6 中文版英文版. 收藏
Sun 公司提供的Java API Docs是學(xué)習(xí)和使用Java語言中最經(jīng)常使用的參考資料之一。但是長期以來此文檔只有英文版，對于中國地區(qū)的Java開發(fā)者來說相當(dāng)?shù)牟槐恪Ｄ壳癝un 公司正在組織多方力量將此文檔翻譯成中文，并于2005年10月31日在Sun 中國技術(shù)社區(qū)（http://gceclub.sun.com.cn/）正式發(fā)布第一批中文版Java API文檔（包括java.lang和java.util類庫API 文檔的中文版）。經(jīng)過將近10個月的努力，目前我們已經(jīng)將Java SE 5.0的全部API文檔中文化。開發(fā)人員可以通過Sun 中國技術(shù)社區(qū)的網(wǎng)站在線瀏覽相關(guān)文檔，也可以將全部文檔下載到本地以方便檢索和使用。
J2SE DK & API下載
-------------------------
http://java.sun.com/j2se/1.3/download.html
http://java.sun.com/j2se/1.4.2/download.html
http://java.sun.com/javase/downloads/index_jdk5.jsp
http://java.sun.com/javase/downloads/index.jsp
J2EE DK & API下載 
-------------------------
http://java.sun.com/j2ee/1.3/index.jsp
http://java.sun.com/j2ee/1.3/download.html
http://java.sun.com/j2ee/1.4/index.jsp
http://java.sun.com/j2ee/1.4/download.html
http://java.sun.com/javaee/downloads/index.jsp
JDK1.6API中文版（全）
-------------------------
* HTML 格式(在線英文) http://java.sun.com/javase/6/docs/
* HTML 格式(在線中文) http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/html/zh_CN/api/index.html
* zip 格式(中文) http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/html_zh_CN.zip
* CHM 格式(中文)  http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/chm/JDK_API_1_6_zh_CN.CHM

JDK1.5API中文版（全）
-------------------------
* HTML 格式(在線英文) http://java.sun.com/javase/5/docs/
* HTML 格式(在線中文)  http://gceclub.sun.com.cn/Java_Docs/html/zh_CN/api/index.html
* zip 格式(中文) http://gceclub.sun.com.cn/Java_Docs/html_zh_CN.zip
* CHM 格式(中文) http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/builds/JDK_API_1_5_zh_CN.CHM

相關(guān)網(wǎng)站
-------------------------
http://java.sun.com
http://gceclub.sun.com.cn/
http://developers.sun.com/downloads/
http://java.sun.com/javaee/downloads/
http://java.sun.com/javase/downloads/
http://www.netbeans.info/downloads/
 

本文來自CSDN博客，轉(zhuǎn)載請標明出處：http://blog.csdn.net/zhsp1029/archive/2008/04/05/2253865.aspx

VLAN的好處在于有效地限制了L2的廣播域。對于有線網(wǎng)絡(luò)，常見的VLAN劃分方法包括基于交換機端口的劃分、基于MAC地址的劃分、基于L3的IP劃分以及基于802.1x的安全憑證劃分等，這方面的資料比較多，支持的產(chǎn)品也很多，應(yīng)用很成熟。

但對于WLAN，該如何劃分VLAN呢？

WLAN的網(wǎng)絡(luò)結(jié)構(gòu)基本單位是BSS。BSS有兩種形態(tài)：獨立基礎(chǔ)結(jié)構(gòu)（IBSS，也叫自組網(wǎng)Adhoc）和基礎(chǔ)結(jié)構(gòu)Infrastructure。自組網(wǎng)就是多個站點自發(fā)組成一個可以互通的WLAN，而基礎(chǔ)結(jié)構(gòu)模式則以AP為中心，其它站點都先與AP關(guān)聯(lián)，然后才能與BSS中的其它站點進行通信。以下所提到的BSS僅指基礎(chǔ)結(jié)構(gòu)。

WLAN中的VLAN劃分必須要有AP的支持。每一個VLAN由一個VLAN ID來標示，因此以什么作為VLAN ID的依據(jù)，決定了VLAN在哪個層次劃分。根據(jù)VLAN與BSS的關(guān)系，WLAN中的VLAN劃分有幾種情況。

1. 以MAC層依據(jù)作為VLAN ID

一個AP至少可以組建一個BSS，而且不少實際的產(chǎn)品還支持同時虛擬出多個BSS，每個BSS擁有不同的BSSID。對于每個BSS，一些AP產(chǎn)品還可以同時支持多個SSID，不同的SSID共享大部分的BSS配置和Radio接口配置，可以有少部分配置不一樣（比如密鑰）。

1.1 以SSID或BSSID為劃分依據(jù)

一種容易實現(xiàn)的VLAN劃分方法就是以SSID為劃分依據(jù)，每個SSID對應(yīng)一個VLAN ID。這種劃分依據(jù)完全來自于802.11 MAC層的SSID，因此可以完全在AP內(nèi)部實現(xiàn)。根據(jù)AP對多SSID支持情況的不同，具體情況又有所不同。

1.1.1 AP支持多個BSS，每個BSS又支持多個SSID

這種情況下按照SSID來劃分VLAN，所有連接到該SSID的站點都屬于同一個VLAN。每個SSID提供給STATION的接入端口均為VLAN的Access端口，是不帶tag的端口。

由于一個BSS內(nèi)有多個SSID，因此一個BSS內(nèi)就會有多個VLAN。由于這些SSID均屬于同一BSS，因此如果位于兩個VLAN內(nèi)的STATION要通信，只需要經(jīng)過AP內(nèi)部的轉(zhuǎn)發(fā)橋接即可。

1.1.2 AP僅支持一個BSS，每個BSS支持多SSID

這種情況下按照SSID來劃分VLAN，跟上面的情況類似。

1.1.3 AP支持多個BSS，每個BSS僅支持一個SSID

這種情況下SSID與BSSID一一對應(yīng)，因此根據(jù)SSID來劃分VLAN與根據(jù)BSSID來劃分是一樣的。這種情況下屬于同一個BSS的站點屬于同一個VLAN，位于兩個VLAN內(nèi)的STATION要通信，只需要經(jīng)過AP內(nèi)部的轉(zhuǎn)發(fā)橋接即可也僅僅需要AP內(nèi)部的轉(zhuǎn)發(fā)。

1.1.4 AP僅支持BSS，每個BSS僅支持一個SSID

這種情況下如果按照SSID或BSSID來劃分VLAN，則整個BSS均屬于同一VLAN。由于不存在多個VLAN，因此不存在VLAN互通的問題。

可見，如果在同一AP內(nèi)部劃分不同的VLAN，那么這些VLAN間的互通僅需要AP內(nèi)部的MAC橋接即可實現(xiàn)，而不需要將數(shù)據(jù)交到更高層進行轉(zhuǎn)發(fā)或橋接。

1.2 以MAC地址為劃分依據(jù)

這種情況根據(jù)STATION的MAC地址在BSS內(nèi)劃分VLAN。AP根據(jù)從STATION發(fā)來的幀中的源地址決定該STATION所屬的VLAN，從而可以保證同一VLAN的互通和不同VLAN的橋接。

上面的兩種劃分均是以802.11 MAC層的信息作為VLAN ID的劃分依據(jù)，因此同一VLAN內(nèi)部的轉(zhuǎn)發(fā)和不同VLAN之間的橋接均可在AP內(nèi)部實現(xiàn)，而不需要分發(fā)。

在上面的兩種情況下，在AP內(nèi)部只需要維護兩張表即可：一張表是VLAN ID與VLAN依據(jù)（SSID/BSSID或MAC地址）之間的對應(yīng)表，另一張表示VLAN ID與VLAN接口之間的對應(yīng)表。Access端口上的數(shù)據(jù)收發(fā)情況如下：

進入Access端口的數(shù)據(jù)：可以不帶tag。如果需要分發(fā)到AP外（目的地址不是BSSID且不是任何BSS中的其它站點），則加上tag通過分發(fā)接口分發(fā)；如果不需要分發(fā)到AP外，則有幾種情況：

DA為BSSID，則由AP接收并處理；
DA為同一VLAN中的其它STATION，則MAC層轉(zhuǎn)發(fā)；
DA為不同VLAN，但同一AP中的其它STATION，則執(zhí)行VLAN之間的橋接協(xié)議。
從Access端口發(fā)出的數(shù)據(jù)：不帶tag，直接發(fā)到STATION。

這種劃分的缺點僅適合于較小的網(wǎng)絡(luò)，靈活性較差。比如，無法實現(xiàn)跨AP的VLAN，也就是連接到不同AP的兩個STATION無法劃分到同一個VLAN。

2. 動態(tài)VLAN劃分方式

動態(tài)劃分方式并不由AP來決定VLAN ID，而是由其它更高級的設(shè)備來決定。一種方法是由RADIUS服務(wù)器來劃分。當(dāng)一個STATION與AP關(guān)聯(lián)時，AP中的RADIUS客戶端與RADIUS服務(wù)器進行通信，從而得到該STATION所屬的VLAN ID。RADIUS決定STATION服務(wù)器所屬VLAN的依據(jù)可以是用戶名、IP地址等，因此具有很大的靈活性。當(dāng)用戶的位置改變后，他所屬的VLAN仍然不變。

采用動態(tài)VLAN方式后，同一個AP的同一個SSID中的兩個STATION可能屬于不同的VLAN，而連接到兩個不同AP中的STATION卻可能屬于同一VLAN。因此這種情況下，要實現(xiàn)同一VLAN中不同STATION之間的互通，需要更高層的轉(zhuǎn)發(fā)和橋接，可能需要經(jīng)過位于WDS接口或以太網(wǎng)DS接口等接口之上的VLAN trunk、hybrid端口。

本文來自CSDN博客，轉(zhuǎn)載請標明出處：http://blog.csdn.net/rangzh/archive/2008/07/02/2606778.aspx

從用例到代碼, 第一部分： 用例分析

從用例到代碼，第二部分：用例設(shè)計

第1章前言

目的

需求調(diào)研是為需要說明書做前期工作，可以說需要說明書說是從需求調(diào)研表中得到或抽取而出。

需求調(diào)研是要了解現(xiàn)實世界中做實際工作的人們真正需要什么樣的程序的過程，再把這些需求開進細節(jié)整理由設(shè)計部開發(fā)，再由銷售部銷售給用戶。

用戶：系統(tǒng)分析人員

回頁首

第2章前期準備

2.1. 確定工具

• 沒有什么工具是好還是壞的問題，問題是關(guān)鍵是如何使用它們，無論是什么工具也只是一個輔助工具，也不是生成工具。
• 工具的選取要求是自己（本組）熟悉的工具，不能是一件最新時髦工具而自己對它了解很少，結(jié)果大部分時間化在學(xué)習(xí)工具上，而不是使用它為你工作。
• 工具最好也是要求是普通流行的，因為要考慮交流的問題。

2.2. 要做什么就要先了解什么

• 如果做的項目是你所不了解的一個行業(yè)（專業(yè)）同組有要最好有要專家----最終用戶做為這個專家是最好的，最少你有了解這個專業(yè)，不是要你成為專家，但最少要了解一定的專業(yè)知識（最少專來詞匯你要知道），不然您甚至不知道去問什么問題或者如何去問他們，甚至于人家在說什么你也不知道。
• 相應(yīng)的專業(yè)資料是必須的，最少要有專業(yè)入門書籍和對應(yīng)的資料，也需要求更深入的一些資料。當(dāng)然有專家的參入就另當(dāng)別論。
• 如果行業(yè)的難度不是很大，可以通入分析人員的自我學(xué)習(xí)在短時間內(nèi)了解行業(yè)，也許可以不用專家，否則專家是必須的。

2.3. 建立設(shè)計環(huán)境

一定建立一個專門的設(shè)計環(huán)境來為本項目服務(wù)，進行一定的資源分配，進行必要的文件管理。

2.4. 真正了解自己和用戶

• 那些是用戶可能明確要達到的目地
• 要知道那些是自己能做到的，那些是自己不能做的。
• 對于不能做的處理方法，如拒絕，轉(zhuǎn)包等
• 那些是用戶想要做到的

2.5. 列出人員分配表和所有工具列表

• 明確項目人員分工
• 統(tǒng)一項目所用的工具
• 統(tǒng)一項目文件模版
• 其它資源列表（資料，相關(guān)網(wǎng)站，資詢電話。。。）

回頁首

第3章調(diào)研過程

3.1. 搜集需求得到需求說明書

注意：

1. 雖然最終必須要編成基于計算機解決方案的描述，但到目前為止，我們關(guān)注的焦點的文檔在相應(yīng)領(lǐng)域方面的部分。
2. 記住這里沒有計算機方面的行話，如果是編寫一個會計軟件，那么一位會計師都應(yīng)該清楚地理解程序員寫的會計方面的問題說明書
3. 需求說明書問題中，不要太正式。只要描述能表達您想要做的事情就行了，就和另外一個人在說話一樣就可以。
4. 對于客戶或相應(yīng)人員了解問題時，一定要有記筆記的習(xí)慣，談上幾個小時，很多細節(jié)是記不住的。

3.2. 整理，檢查和細化需求說明書

1. 對于客戶的需要進行必要的整理和分類有進從用戶那里會得到很多信息，不行進必要的整理就不能從中進行合理的分析
2. 分清有用功能、可選功能用、無用功能及不可實現(xiàn)功能對于用戶來講他可以說出他想要的很多功能，但這些功能間的關(guān)系有時是清晰的，但對于很多用戶來講想通過計算機或新系統(tǒng)實現(xiàn)他以前沒有的功能，在這時他所提出的新需求的可行性和與其它模塊之間的關(guān)系就已經(jīng)不清，所以對于分析員來講，要從用戶的需求中分清有用功能和無用功能和可選功能，進行分別區(qū)分處理，比如不可實現(xiàn)功能請用戶放棄。
3. 不要忽略明顯的錯誤用戶倒是不經(jīng)常提及他需要的東西，而這些東西對問題來說都是很基本的，要細化檢查一定有注意這個問題。
4. 你認為的也許不是對的對于系統(tǒng)分析員對需求分析的自認為的情況要加以注意，對于一個行業(yè)來說，有些規(guī)則可以不是最合理，但它就是那樣存在和使用，所以對于每一個非明確確定的需求，要由專業(yè)人員來審定。除非你就是專家。

3.3. 改進

最初的第一次需求在分析，細化一定有不明及不確定之處，那么就把整理出一份問題細化問詢表，對發(fā)現(xiàn)的問題進行整理，列出不明之處，可根椐以下格式

問詢?nèi)耍?
            問題：
            業(yè)務(wù)不清問題列表（業(yè)務(wù)描述不清）：
            1 ….是什么含義？
            2 …..與XX是什么關(guān)系？
            多種選擇可以列表（請用戶進行選擇）：
            1 ……有多個可能，那么現(xiàn)在我們使用
            A ……   B…….   C……..  D ……

3.4. 審核需求

1. 自我審枋
   把自己從用戶的角度來考慮
   是否合理，是否可以提高效率，是否可以達到目的，是否有完整
2. 由用戶來評價
   由最終用戶來評價你所列的需求是否達到了用戶要求（用戶人數(shù)1-3人，再多也沒有什么益處）。
3. 重復(fù)過程，最終通過審核完成需求說明書

參考資料

• 標準版API 規(guī)范，JAVA 2 核心技術(shù)和其他方面的信息。