【正文】 RDATA_ADDRESS 讀取數(shù)據(jù)起始地址錯誤，ERROR_SENDDATA_FAIL 發(fā)送給讀寫器的數(shù)據(jù)格式錯誤，內(nèi)部故障，ERROR_RECEIVEDATA_LEN 數(shù)據(jù)長度校驗錯誤，ERROR_READWRITE_FAIL 讀用戶區(qū)數(shù)據(jù)失敗，ERROR_OTHER_FAIL 其它錯誤，數(shù)據(jù)包不完整。用途：寫標簽用戶區(qū)數(shù)據(jù)。概要：include “”unsigned char __stdcall XCWriteUserData (HANDLE hCom,unsigned char ucTagType,\unsigned char ucStartAdd, \unsigned char *pTagID, \unsigned char *pValue, \unsigned char ucLength=1)。說明：此功能是為XCTF5000系列標簽設計的，XCTF5000系列標簽為用戶設置了224個字節(jié)可讀空間，允許用戶讀寫自己的信息。第三章 關鍵技術分析本系統(tǒng)實現(xiàn)方案以Microsoft MFC框架為基礎的C/S架構，結合ODBC數(shù)據(jù)庫技術，在面向?qū)ο蟮南到y(tǒng)分析和設計思想的指導下，介紹了基于RFID的立體庫實驗系統(tǒng)的分析、設計和實現(xiàn)的過程。由于世界對軟件系統(tǒng)的需求日益增長，變化也越來越快，軟件開發(fā)技術的發(fā)展方向已悄悄地從“提升被開發(fā)系統(tǒng)的執(zhí)行效率”轉變成為“提升開發(fā)效率”。 C/S架構概況[22]C/S 是 Client/Server的縮寫。客戶端需要安裝專用的客戶端軟件。C/S 一般面向相對固定的用戶群對信息安全的控制能力很強一般高度機密的信息系統(tǒng)采用C/S結構適宜。C/S程序的構件的重用性不如在B/S要求下的構件的重用性好。C/S程序可以處理用戶面固定，并且在相同區(qū)域，安全要求高，與操作系統(tǒng)相關的應用情況。 數(shù)據(jù)庫技術[23]在現(xiàn)代軟件開發(fā)中，數(shù)據(jù)庫技術越來越廣泛地應用。最初，廠商推出一個新的數(shù)據(jù)庫產(chǎn)品時，相應地，他會為程序員提供一套訪問該數(shù)據(jù)庫的接口，即API。這樣，在使用一個新的數(shù)據(jù)庫時，就要學習一套新的API，當然這就加大了開發(fā)數(shù)據(jù)庫的難度，也不利于數(shù)據(jù)庫在軟件開發(fā)過程中的應用。ODBC提供一個單一的API，可用于處理不同數(shù)據(jù)庫的客戶應用程序。那么我們使用ODBC API就可以訪問這些數(shù)據(jù)庫。圖31 ODBC體系架構我們所編寫的客戶程序直接和ODBC驅(qū)動程序管理器打交道，后者利用ODBC驅(qū)動程序所提供的API訪問數(shù)據(jù)庫。OLE DB(對象鏈接與嵌入數(shù)據(jù)庫)OLE DB在兩個方面對ODBC進行了擴展。通常我們所說的數(shù)據(jù)庫都是指關系型數(shù)據(jù)庫。OLE DB的兩個基本結構式OLE DB提供程序(Provider)和OLE DB用戶程序(Consumer)。ADO(ActiveX Data Object，ActiveX數(shù)據(jù)對象)ADO建立在OLE DB之上。使用ADO的應用程序都要間接地使用OLE DB。 MFC[24]MFC是微軟提供的WinDOS下應用程序的編程語言接口，是一種軟件編程的規(guī)范，但并不是一種程序開發(fā)語言，可以允許用戶使用各種各樣的第三方的編程語言來對WinDOS下應用程序進行開發(fā)，使這些被開發(fā)出來的應用程序能在WinDOS下運行，比如VB，VC++，Java，Dehpi編程語言函數(shù)本質(zhì)上全部源于API。MFC是微軟封裝了的API。MFC是面向?qū)ο蟪绦蛟O計與Application framework的完美結合，他將傳統(tǒng)的API進行了分類封裝，并且為你創(chuàng)建了程序的一般框架。General Purpose classes：提供字符串類、數(shù)據(jù)處理類(如數(shù)組與鏈表)，異常情況處理類、文件類等等。Windows API classes：用來封裝Windows API，例如窗口類、對話框類、DC類等等。Application framework classes：組成應用程序骨干者，包括Document/View、消息映射、消息傳遞、動態(tài)創(chuàng)建、文件讀寫等等。High level abstractions：包括工具欄、狀態(tài)欄、拆分窗口、滾動窗口等等。Operation system extensions：包括OLE、ODBC、DAO、MAPI、WinSock、ISAPI等等。在過去40年中，信息系統(tǒng)的發(fā)展孕育了四種現(xiàn)代方法學：傳統(tǒng)型、結構化型、信息建模型和面向?qū)ο笮?。?31 四種典型方法學比較一覽表系統(tǒng)流程數(shù)據(jù)用戶交流過程邏輯傳統(tǒng)系統(tǒng)流程圖表單、格式描述、網(wǎng)格圖面談自然語言、口述、腳本、程序流程圖、模塊結構圖結構化數(shù)據(jù)流圖數(shù)據(jù)字典、數(shù)據(jù)結構圖、ER圖面談、用戶點評、聯(lián)合開發(fā)會議（JAD）決策樹/表、結構化自然語言、結構圖、Warnier圖信息建模業(yè)務領域分析（BAA）、處理模型業(yè)務領域分析（BAA）、ER圖面談、用戶點評、聯(lián)合開發(fā)會議（JAD）集思廣益法業(yè)務系統(tǒng)設計面向?qū)ο髮ο竽Ｐ蛯ο竽Ｐ蛯傩悦嬲劇⒂脩酎c評、聯(lián)合開發(fā)會議（JAD）、集思廣益法對象模型服務、情景法、決策樹/表、結構化自然面向?qū)ο蠓椒ㄅc傳統(tǒng)的程序設計方法有很大的區(qū)別。實際上，傳統(tǒng)的程序設計方法并不關心程序與實物相對應，人們追求的是功能，即一切從功能出發(fā)，從而形成了程序與功能的映射關系。因為，計算機程序起初就為了應付科學計算，需求就是計算功能的要求。而今天的計算機程序大多數(shù)是面對信息處理，其需求往往與日常工程和生活緊密聯(lián)系。當前令軟件工程師們最傷腦筋的就是變化的需求給程序的維護帶來極大的麻煩，它使得程序結構變得越來越脆弱。因此，反映需求分析與軟件框架設計的模型應該圍繞需求中的人和物，而不是變化多端的功能，后者是需求實現(xiàn)的細節(jié)設計應該考慮的問題。首先，它使得程序與需求更為接近，便于理解，便于進行程序維護。其次，雖然功能發(fā)生變化，但人和物沒有變，變化的只是它們的特征。再者，以人和物為對象進行建模，可以構造抽象和具體的繼承結構。建立這樣的層次概念，不但可以從較高層次把握復雜事物結構，而且可以預測未來的變化。利用面向?qū)ο蟮幕咎匦?，如封裝，多態(tài)和繼承，我們可以開發(fā)出安全的，易維護的，健壯的系統(tǒng)。 本章小結本章對系統(tǒng)開發(fā)所涉及到的方法和技術進行了專門的介紹，包括構建基于RFID的立體庫實驗系統(tǒng)的MFC框架，數(shù)據(jù)庫技術和面向?qū)ο蟮南到y(tǒng)分析和設計思想。IEEE軟件工程標準詞匯表中定義的需求為：“用戶解決問題或達到目標所需的條件或權能(capability)” ，另外一種定義認為需求是“用戶所需要的并能觸發(fā)一個程序或系統(tǒng)開發(fā)工作的說明” ，需求分析專家Alan Davis則認為：“從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿足于用戶的特點、功能及屬性等”。業(yè)務需求(Business requirement)――表示組織或客戶高層次的目標。業(yè)務需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達到的目標。用戶需求(User Requirement)――描述的是用戶的目標，或用戶要求系統(tǒng)必須能完成的任務。也就是說用戶需求描述了用戶能使用系統(tǒng)來做些什么。功能需求有時也被稱作行為需求(behavioral requirement)，因為習慣上總是用“應該”對其進行描述：“系統(tǒng)應該發(fā)送電子郵件來通知用戶已接受其預定”。除了以上的軟件需求，從項目的設計原則來說，從立體庫貨物出入庫檢驗的業(yè)務流程的實際出發(fā)圍繞信息資源的綜合利用這一主線索。因此本系統(tǒng)的設計就遵循以下原則：可靠性：保證系統(tǒng)是一個有機整體，傳輸中不致出現(xiàn)數(shù)據(jù)丟失。 系統(tǒng)必要性分析基于RFID的物流實驗室視頻監(jiān)控系統(tǒng)可以克服傳統(tǒng)的手工作業(yè)或計算機半自動化管理方式，它能有效、準確、智能的對進出立體庫的貨物進行信息自動識別、采集、記錄、上傳，為“精確”庫存的管理方式提供了數(shù)字化手段，對出入庫的數(shù)據(jù)進行多次實時動態(tài)復核。(1) 經(jīng)濟可行性：主要是對項目的經(jīng)濟效益進行評價，本系統(tǒng)開發(fā)經(jīng)費較少，并且本系統(tǒng)實施后可以顯著提高工作效率，有助于企業(yè)實現(xiàn)信息化管理，進而帶來經(jīng)濟效益。(2) 技術上的可行性：技術上的可行性分析主要分析技術條件能否順利完成開發(fā)工作，硬、軟件能否滿足開發(fā)者的需要等。數(shù)據(jù)庫服務器選用Oracle數(shù)據(jù)庫，它能夠處理大量數(shù)據(jù)，同時保持數(shù)據(jù)的完整性并提供許多高級管理功能。因此，系統(tǒng)的軟件開發(fā)平臺已成熟可行。(3) 時機可行性：目前，絕大多數(shù)企業(yè)都越來越重視物流這一“第三利潤源泉”，積極建立適合自己的立體倉庫。綜上所述 ，此系統(tǒng)開發(fā)目標已明確，在技術和經(jīng)濟等方面都可行，并且投入少、見效快。 業(yè)務需求 入庫過程的RFID信息校核實驗第一步、從WMS系統(tǒng)下載當天要生產(chǎn)的任務信息；第二步、操作工人將料箱放上輸送線；第三步、入庫輸送機帶動料箱進入入庫站臺。然后做出驗證通過或告警提示。第二步、當通過RFID檢測門的時候，實驗系統(tǒng)將自動驗證料箱所入庫物資和WMS系統(tǒng)記錄是否一致，系統(tǒng)將根據(jù)比對情況做出驗證通過或告警提示。操作者將用條碼槍掃描需要入庫的料箱上的條碼，更新WMS的記錄。 功能需求在本系統(tǒng)中，需要實現(xiàn)以下功能：(1) 錄入標簽信息功能；(2) 制定作業(yè)任務功能；(3) 查詢并核對標簽功能；(4) 顯示功能；(5) 信息上傳能；(6) 信息綜合查詢。圖43 基于RFID的立體庫實驗系統(tǒng)的用例圖 系統(tǒng)靜態(tài)分析 構造概念類圖根據(jù)以上的系統(tǒng)需求分析，我們得到了系統(tǒng)需要的對象。圖44 基于RFID的立體庫實驗系統(tǒng)的概念類圖CTaskDlg和CWirteDlg：分別完成作業(yè)任務的制定和標簽信息的錄入。CCheckView：進行綜合查詢的顯示。 狀態(tài)圖通過業(yè)務需求的分析，可知本系統(tǒng)的狀態(tài)有兩種：待機和掃描與可對。為了詳細了解對象的職責，必須對系統(tǒng)進行動態(tài)的分析。圖46 系統(tǒng)時序圖 本章小結本章主要完成了對系統(tǒng)的分析工作。第五章 系統(tǒng)設計 系統(tǒng)總體設計 項目規(guī)劃根據(jù)需求分析，設計系統(tǒng)框架。設計各部分具體功能如下：(1) 基礎信息管理模塊該模塊包括標簽信息錄入、制定作業(yè)任務兩部分。(3) 信息查詢管理模塊該模塊主要實現(xiàn)對核對信息的查詢，如總體查詢、按作業(yè)任務ID查詢、按標簽ID查詢、按貨物信息查詢以及模糊查詢等。 系統(tǒng)功能結構圖基于RFID的立體庫實驗系統(tǒng)的功能結構圖如圖51所示：圖51 基于RFID的立體庫實驗系統(tǒng)的功能結構圖 系統(tǒng)設計 設計目標基于RFID的立體庫實驗系統(tǒng)主要實現(xiàn)貨物出入庫的智能核對，提高倉庫的管理效率。(2) 界面設計美觀簡潔，人機交互界面友好。(4) 滿足鍵盤和鼠標的雙重操作，完全支持回車鍵。(6) 對用戶輸入的數(shù)據(jù)，系統(tǒng)進行嚴格的數(shù)據(jù)檢驗，盡可能排除人為地錯誤。(2) 數(shù)據(jù)庫管理系統(tǒng)軟件：Oracle 10g。(4) 顯示像素：最低800600，最佳效果1024768。新建作業(yè)任務表59 新建作業(yè)任務名稱：新建作業(yè)任務 編號：e0040000xxxxxxxx說明：模擬WMS功能，向本系統(tǒng)發(fā)送作業(yè)任務輸入：需要核對的貨物信息，如貨物名稱、數(shù)量、出入庫狀態(tài) 輸出：顯示核對狀態(tài)，正確或錯誤處理：采集標簽中的信息，調(diào)用數(shù)據(jù)庫進行比對，若正確則進行出入庫操作，若錯誤則警告，進行處理。 數(shù)據(jù)存儲定義 概念模型設計首先，考慮該系統(tǒng)數(shù)據(jù)庫的概念結構，即概念模型(Conceptual Data Model，簡稱CDM)。CDM所包含的對象通常并沒有在物理數(shù)據(jù)庫中實現(xiàn)，它僅僅給出了商業(yè)或業(yè)務活動中所需要數(shù)據(jù)的形式化的表示。圖52 基于RFID的立體庫實驗系統(tǒng)數(shù)據(jù)庫概念設計圖 物理模型設計通過建立概念模型(CDM)，我們掌握了本系統(tǒng)的實體關系。如圖53所示。圖54 基于RFID的立體庫實驗系統(tǒng)主窗口界面 菜單設計[29]設計菜單項如表512所示：表512 菜單對象的基本屬性對象名稱ID標題內(nèi)容主菜單條目無基礎信息管理子菜單條目ID_NEW_TASK新建作業(yè)任務子菜單條目ID_NEWID標簽信息錄入子菜單條目ID_APP_EXIT退出主菜單條目無信息核對管理子菜單條目ID_ACTION開始掃描子菜單條目ID_CLOSE關閉掃描主菜單條目無信息查詢管理子菜單條目ID_VIEW_TOOLBAR工具欄子菜單條目ID_VIEW_STATUS_BAR狀態(tài)欄子菜單條目ID_QUERYALL綜合查詢主菜單條目無幫助子菜單條目ID_CONTEXT幫組文檔子菜單條目ID_APP_ABOUT關于RFID(amp。圖55 菜單 工具欄設計創(chuàng)建一個動態(tài)真彩工具欄，效果如圖56所示。其相關信息顯示在主窗口的WMS信息顯示窗口中。圖510 基礎信息管理模塊運行界面 信息核對管理模塊的設計該模塊主要完成以下標簽信息的采集與核對的功能。圖511 信息核對管理模塊類圖信息核對管理模塊運行界面如圖512所示。其類圖設計如圖513所示。圖514 綜合查詢子模塊的運行界面信息查詢管理模塊運行界面如圖515所示。如果在每次使用時都重新編寫代碼，則過于繁瑣，整體程序的可讀性差。其類圖設計如圖516所示。XCRF500系列讀寫器數(shù)據(jù)的通行采用的是字節(jié)流方式，其數(shù)據(jù)類型都是16進制。實現(xiàn)的方式是事先在數(shù)據(jù)庫中建議一個映射表，確定16進制與中文字符的對照關系，然后，在進行標簽信息采集時，根據(jù)所采集到的16進制數(shù)據(jù)，查找數(shù)據(jù)庫找出其對應的中文字符，然后進行顯示。圖517 映射表 硬件設計 設備組成如圖518所示，XCRF500系列讀寫器和天線電纜、天線，標簽組成一個完整的射頻識別應