2009年12月25日 星期五

RFID定位目前計畫-更正



  1. 在資料庫儲存商品在地圖上的x,y座標位置 (假定同樣商品都會放在固定的位置)


  2. 搜尋商品,先讀取兩個商品,以arc_tan((start1.y - start2.y) / (start1.x - start2.x))找出目前行進角度與方向,運算出到達目標商品的最短路徑。 (目前是假定無wifi,等wifi定位完成再想辦法整合)(由client運算)


  3. 在地圖上標示可行進的點,作為計算最短路徑的依據。(須討論地圖的資料表示方式)


  4. Client將兩個起點與一個終點的座標傳至Server端運算出路徑,並傳回最短路徑陣列(以起點與終點表達單一直線路徑(start, end),多個直線路徑組成一個完整路徑)。例如,傳入 start1(0,0), start2(0,10) , dest(10, 20)(螢幕左上角為 0,0),假設走斜線有障礙物,只能走直線與橫線,則傳回 {Path[start(0,0), end(0,20)](先走直線,因目前方向為向南方走), Path[start(0,20), end(10,20)]}


  5. client請求格式:
    <Request type="find_path">
    <Map name="地圖名稱" />
    <Start x="XX" y="XX" /> -> 目前位置
    <Destination x="XX" y="XX" /> 目標商品的位置
    </Request>
    request回應格式:
    <Response type="find_path_success">
    <Map name="地圖名稱" block_size="區塊大小" />
    <Path>
    <Start x="XX" y="XX" />
    <End x="XX" y="XX" />
    </Path>
    <Path>
    <Start x="XX" y="XX" />
    <End x="XX" y="XX" />
    </Path>
    ...
    </Response>
這是目前的計畫,有問題可以提出。

2009年12月24日 星期四

CheckOut 的XML格式-更正

client 向 server 提出 checkout 要求時的XML格式

<Request type="checkout">
  <account id="會員編號" />
  <products>
    <product id="編號" amount="數量"/> 
    <product id="編號" amount="數量"/>
       ...
  </products>
</Request>


之後 server 會回傳以下的XML

<Response type="checkout_success">
  <cashier id="收銀檯編號" />
</Response>

2009年12月16日 星期三

剩餘的工作

  1. 測定新的Sample點
    • 測定T4五樓的Sample點
    • 將Sample點資料輸入到資料庫

  2. 測定WIFI的訊號精準度
    • 測量WIFI block的距離

  3. 結帳部分
    • 結帳端圖形介面
    • 結帳端程式與圖形介面整合

  4. Server端
    • 整合結帳部分程式
    • 完成get_position response:WIFI block 與RFID block的換算

  5. 用戶端
    • 整合WIFI訊號偵測程式
    • 完成get_position request
    • 結帳功能

2009年10月16日 星期五

Server端的資料

有關於Server端的資料,都放在 ftp://tw-yen.no-ip.org/server
推甄有需要用到的,請自行前往下載。
如果需要的資料不在上面,可以跟我要。
如果有要補充的資料,請自行放上去。(可匿名登入)

目前行數:3288行(含註解與空行), 2245行(不含註解)
Server端使用之平台(Windows Server 2003)...比較不會當機
CPU: Intel core 2 E6300, 1.86GHZ
Memory: 4GB

Server端的設計理念是:必須能承受同時多個請求又不過度取用資源,功能方面也必須能夠簡單地擴充。

目前曾對Server端做過5000筆資料的壓力測試,執行至今軟體本身沒有發生過異常(作業系統當機除外)。(可參考之前阿汶做的測試)

曾遇到比較有趣的問題:
  1. 多執行緒同步問題。
  2. 資料編碼格式問題。(編碼為UTF-8,然而在傳輸時常忘記轉碼)
  3. 功能擴充問題。(在軟體設計上獲得解決)
    目前的軟體設計,予許在只更動 MarketRequestType的狀況下,就能新增一個可處理的請求型態。想要新增一個請求型態,只需要先把特定的Responder寫好(實作Responder介面),並在MarketRequestType類別裡註冊請求型態與處理該型態的Responder即可。
由於處理請求的Responder實作類別還可以不斷擴充,我沒有把這些類別畫進類別圖裡。FTP裡的類別圖只是初稿,後來有經過一些細微修改,但大致上無太大改變。

有問題可以提出。

2009年9月19日 星期六

目前於PDA上開發的諸點困難

RFID Reader -
目前大部份的 Rfid 專案是使用 PC 作為平台,且市面上所見書籍也幾乎是以PC為例

Mysaifu( Java 虛擬機器 )
Mysaifu和原本PC的Java虛擬機器相比,功能有相差或欠缺之處

性能 -
PDA無法完美地使程式運行順暢,記憶體的限制使得程式無法載入所需的複數圖片

連線 -
目前借到的PDA未能解決連線問題

2009年9月3日 星期四

RFID Reader 賣場搜索

===使用SDIO介面(可裝置在PDA上)=====

reader
HF
$13500

===使用USB介面(可能無法裝置於PDA上)=====

reader
HF
$3900

reader
HF
$3150
備註 : 友鵬科技

2009年8月18日 星期二

Production XML 回覆格式變更

增加 "photo"
12/25 增加 x 和 y 的屬性

<Response type="product_found">
<account level="3" />
<product id="01010001" name="商品1" onsale="true" price="1000.0" expiration="30" manufacturer="NTUST" detail="" x="0" y="0">
<photo> 編碼 </photo>
</product>
</Response>



參考用網址(感謝 Yen )

2009年7月30日 星期四

結帳XML(暫定)

<Request type="checkout">
<account id="??" />
<product id="??" amount="數量"/>
</Request>


傳送帳戶ID與商品ID即可。
同樣的商品若有多個,則設定amount屬性。

確認結帳的必要性再討論。
取消結帳則發送不含商品資料的結帳request即可。

2009年7月29日 星期三

定位組目前規劃


以先前所找到的paper定位方法進行實作:

架構如左圖
由client端偵測user AP強度傳給server端做定位計算

server端程式:
處理定位以及回傳位置的main
三個演算法各一class
以及一個紀錄參考點的database







三個演算法的整合想法如下:
P(x,y) = α Fun(knn) + β Fun(PDF) + γ Fun(RBFS)

目前大概模擬為 γ > α > β

(RBFN耗費以及定位精確度皆為中等 故假設加權最大,PDF計算時間最常精準度最低,到時可能會捨棄)

計劃表:
1.模擬一個database始可模擬演算法
2.先著手 KNN 以及 RBFN 演算法程式 最後PDF
(因RBFN算式較複雜,視狀況而定 可能僅採用KNN演算法( KNN是三者中定位效果最好的))
3.做好計算的main
4.做測量AP的程式(用於建立sample node 以及user的AP偵測)
5.建置sample node,完成database
6.實際測試再行修改

觸發程式時機:
定位系統發現所屬區塊變化時跳出新區塊的特價訊息(選擇性)
---為達此功能 須自動定偵測位置
使用者要求
---傳送要求時執行

2009年7月26日 星期日

結帳XML (構想)

結帳
-商品列表(裡頭的商品可能會有重覆)

確認結帳
- 交易No. ( 確認身份和取消用 )

取消結帳
- 交易No.

有問題用MSN討論

2009年7月24日 星期五

Catelog XML規格(修改)


  • Request
    <request type="category_query" >
    <category id="10000000" page="1"/>
    #page屬性若沒有,就預設1
    </request>
  • Response
    成功找到:
    <Response type="category_found">
    <page current="1" all="12" />
    <category id="10010000" name="汽水"/>
    <category id="10020000" name="果汁"/>
    </Response>
    沒有找到:
    <Response type="category_not_found">
    <category id="10000000" page="1"/>
    </Response>


2009年7月22日 星期三

RFID Reader

http://tw.page.bid.yahoo.com/tw/auction/d41049462
為Reader
頻率 125hz
讀取距離 8~15cm
$1800
使用USB


http://tw.page.bid.yahoo.com/tw/auction/b48673433?r=1242889954
為Tag
頻率 125hz (適用上面的Reader)

有看到新的還會再更新

2009年7月21日 星期二

Client 流程圖

整體流程:

登入頁面:



購物清單:


商品的詳細頁面:

另外圖形化後的Client端 與 Server端測試後也確認無誤

現在只需再繼續新增資料庫的內容以及確認分類的方式

2009年7月17日 星期五

Client 目前進度

Client的圖形介面聽取了 Yen 的建議,
將原本全部視窗都為Frame的方式,全改為一個主Frame來放其餘的視窗,而其餘的視窗都改為Panel來切換。

目前完成了

AccountHandler //處理登入及帳號問題
ProductionHandler //處理商品的詳細問題
FrameHandler //處理Frame切換Panel的問題

圖形化頁面有:
1. 登入畫面 (暫時還是手動輸入,等與RFID結合會用讀會員卡的方式)
2. 主選單
3. 購物清單列表 (改用JList 來表示)
4. 商品詳細頁面 (由購物清單點選想要的商品時切換)
5. 備忘清單 (待考察實用性)
6. 商品型錄 (待確定格式討論完)

核心的程式已經與 Server 進行測試過,大致上無問題
圖形化的還待測試,等測試完再PO上來

2009年7月12日 星期日

MVC範例程式

給Client端介面設計人員:
不好意思,說明文越打越長,暫時是打不完了。可以先看網路上的資料,但大多都很籠統。
其實MVC骨子裡就是Observer pattern,可以找這方面的資料來參考。

目前先寫出一個範例程式,可以看看:

http://docs.google.com/View?id=dfj5vj97_379qn4xpfz

在這個範例裡,Controller就是負責接收按鈕事件的ActionListener,Model是FrameState而View就是JButton和JFrame。Model的狀態只要一更動,就會通知View更新,因此View必須實作Observer介面,才可以註冊為Model的觀察者並接收更新訊息。

以下是下面的圖和程式碼行號的對應:

事件觸發:
使用Java的內部機制,110行的 actionPerformed會在按鈕事件觸發後被呼叫。

取得View的資料:
此範例不需要取得任何View的資料。

更新資料:
111行的state.setCurrentPanel(XXX); 就是更新model裡的資料。(state在本範例裡就是model)

通知有更新:
72和77行的notifyObservers(); 會呼叫96行的notifyObservers()方法,該方法會呼叫每個已註冊的Observer的stateChanged()方法。觀察者就會執行它們各自的stateChanged()實作。
這部份很像Strategy Pattern,可以參考Wiki

取得資料:
45行的state.getCurrentPanel()就是從state取得資料,並更新view。


如果有問題請再提出來。

--------------------------------------------------------------------------
以下是目前說明文完成的部分,全部完成後會放到言式法則上:

Model-View-Controller架構是相當被廣泛應用的架構模式之一,將物件在某一互動元件中所扮演的角色區分為Model、View與Controller,能夠有效地分離商業邏輯與使用者介面。
所謂的Model指的是資料內部表現,也就是資料結構;View是資料的外在表現,也就是與使用者互動的介面;Controller則是介於內外部資料表現之間的協調者,負責將外部要求反應到內部資料。因此MVC能用一句話概括:「內部資料表現必須直接反應到外部資料表現上,而外部要求必須經由協調者反應到內部資料表現上。」圖示如下:



必須注意這只是標準的架構。MVC有相當多變化的形式,各個物件之間不見得必須互有關連,例如MVP (Model-View-Presenter)就是一種MVC的衍伸,其Passive View的做法是將View與Model的直接關聯消除,改由Presenter去協調雙方。

如果覺得看上圖不清楚,我們生活週遭其實就有相當多MVC的例子可以現學現賣。試想你現在要使用印表機印出資料,你會在你的Word上按下列印按鈕,這個你可以看得到的按鈕,就是所謂的View(概念很簡單,因為你看得到它)。按下按鈕後,就會觸發事件,讓Word內部程序擷取Word的資料。資料經過處理後,會送到印表機的列印佇列上排隊等列印。這個內部程序就是Controller,負責把外部要求反應到內部資料。列印資料會暫存在列印佇列上等待,這個列印佇列是一種先進先出(FIFO)的資料結構,也就是Model。最後,Model會通知印表機有資料需要列印,資料就從印表機裡印出來了。印表機也是一種View。
看完這個故事,你可能會覺得很奇怪:為什麼View從一開始的按鈕變成印表機了?其實觸發事件的View與反映結果的View不需要是同一個,一切都取決於Controller怎麼協調。因此請將上圖的View、Model與Controller視為角色的集合,而不是單一物件。

2009年7月10日 星期五

測試部分part4

登入 1(一瞬間傳送多筆資料):
5000執行緒

SINGLE:
使用的Executor: java.util.concurrent.Executors$FinalizableDelegatedExecutorService
測試時間: Sat Jul 11 13:48:08 CST 2009
所需時間: 27 minutes 12 seconds

CACHE:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 10:44:09 CST 2009
所需時間: 7 minutes 1 second

FIX:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 10:52:00 CST 2009
所需時間: 3 minutes 30 seconds

SCHEDULE:
使用的Executor: java.util.concurrent.ScheduledThreadPoolExecutor
測試時間: Sat Jul 11 10:56:49 CST 2009
所需時間: 9 minutes 4 seconds

SINGLE_SCHEDULE:
使用的Executor: java.util.concurrent.Executors$DelegatedScheduledExecutorService
測試時間: Sat Jul 11 13:08:09 CST 2009
所需時間: 15 minutes 15 seconds

測試部分part3

商品查詢 1(一瞬間傳送多筆資料):
5000執行緒
用亂數選擇

SINGLE:
使用的Executor: java.util.concurrent.Executors$FinalizableDelegatedExecutorService
測試時間: Sat Jul 11 12:03:00 CST 2009
所需時間: 33 minutes 21 seconds

CACHE:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 12:39:16 CST 2009
所需時間: 3 minutes 58 seconds

FIX:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 12:44:47 CST 2009
所需時間: 7 minutes 5 seconds

SCHEDULE:
使用的Executor: java.util.concurrent.ScheduledThreadPoolExecutor
測試時間: Sat Jul 11 12:52:32 CST 2009
所需時間: 4 minutes 49 seconds

SINGLE_SCHEDULE:
使用的Executor: java.util.concurrent.Executors$DelegatedScheduledExecutorService
測試時間: Sat Jul 11 12:58:13 CST 2009
所需時間: 5 minutes 47 seconds

測試部分part2

商品查詢 2(每隔一段時間傳送一筆資料):
1000執行緒 1執行緒有5筆 間隔時間:1 second

SINGLE:
使用的Executor: java.util.concurrent.Executors$FinalizableDelegatedExecutorService
測試時間: Sat Jul 11 09:47:23 CST 2009
所需時間: 15 minutes 9 seconds

CACHE:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 09:24:18 CST 2009
所需時間: 1 minute 56 seconds

FIX:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 09:17:36 CST 2009
所需時間: 3 minutes 57 seconds

SCHEDULE:
使用的Executor: java.util.concurrent.ScheduledThreadPoolExecutor
測試時間: Sat Jul 11 09:13:34 CST 2009
所需時間: 2 minutes 23 seconds

SINGLE_SCHEDULE:
使用的Executor: java.util.concurrent.Executors$DelegatedScheduledExecutorService
測試時間: Sat Jul 11 08:56:48 CST 2009
所需時間: 14 minutes 47 seconds

共同的ERROR:
java.net.ConnectException: Connection refused: connect

測試部分part1

測試10000筆會有ERROR: java.lang.OutOfMemoryError: Java heap space
改測試5000筆

使用全部為0查詢,好像只列出一樣商品,即使資料庫有多筆商品

格式不符,出現錯誤結果,概念簡單但須注意


登入 2(每隔一段時間傳送一筆資料):
1000執行緒 1執行緒有5筆 間隔時間:1 second

SINGLE:
使用的Executor: java.util.concurrent.Executors$FinalizableDelegatedExecutorService
測試時間: Sat Jul 11 08:15:48 CST 2009
所需時間: 13 minutes 24 seconds

CACHE:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 08:31:20 CST 2009
所需時間: 2 minutes 0 seconds

FIX:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 08:34:28 CST 2009
所需時間: 2 minutes 43 seconds

SCHEDULE:
使用的Executor: java.util.concurrent.ScheduledThreadPoolExecutor
測試時間: Sat Jul 11 08:39:49 CST 2009
所需時間: 2 minutes 6 seconds

SINGLE_SCHEDULE:
使用的Executor: java.util.concurrent.Executors$DelegatedScheduledExecutorService
測試時間: Sat Jul 11 08:43:23 CST 2009
所需時間: 12 minutes 11 seconds

共同的ERROR:
java.net.ConnectException: Connection refused: connect


2009年7月8日 星期三

目前完成的部分(Yen)

  1. 更正Server端的bug
    已改正連線池的問題,詳情見http://yensrule.blogspot.com/2009/07/blog-post_08.html

  2. 改進Server端的組態設定方式
    改為以config.xml組態檔設定
JAR檔案與測試說明連結:http://tw-yen.no-ip.org/public/RFIDServer.zip
密碼是我的學號,大寫。

2009年7月6日 星期一

7/7 ~ 7/20 預計做的事情(Yen)


  1. 更正Server端的bug
    目前發現Server端連線池的設計上有點問題,導致無法正常關閉,以及回收Connection的讀秒器會造成Race Condition。前者目前已擬出解決辦法,後者則待觀察。其餘bug則待測試發掘。

  2. 改進Server端的組態設定方式
    目前是採用hard-coded的方式寫死在Default組態類別裡,將改採以組態檔的方式設定。

  3. 擴大Server端錯誤回報的範圍
    目前只能針對連線與資料庫連線兩部份進行logging的動作。已想到擴大範圍的辦法,待實作。

  4. 閱讀RFID Essentials
    想先深入了解RFID的應用方式。閱讀到某個階段會將重點貼上來。

Server端目前的Javadoc,請參考http://tw-yen.no-ip.org/javadoc/rfidserver/

也煩請各位貼出這段期間的計畫,並在每件事情完成後將相關訊息貼上來。

有空閒會將一些Programming的心得寫在 http://yensrule.blogspot.com,大家有空可以看看。

第九次Meeting記錄

開會時間:
2009年 07月 06日(一)

討論內容:
報告暑假期間的各個組的進度
檢視目前Client完成的程度
硬體的需求

討論結果:
下次開會時Client主要功能完成,並與Server測試
定位組的需決定採取何種方法來實做

目前進度:
Server : 完成 (待與Client測試)
Client : 50%
定位組 :
硬體 : 暫無

細節:
阿汶今次缺席,希望今後多注意





下次開會時間:
2009年 07月 20日(一)

預計下次開會前的進度:
Client 完成
定位方法確定

2009年6月21日 星期日

CVS使用方法

關於Netbeans CVS的使用方法,請參考

由於帳號密碼比較必須保密,因此請用MSN跟我索取。

第八次Meeting記錄

開會時間:
2009年6月15日(一)

討論內容:
暑假Meeting時間與暑假組長的安排。

討論結果:
同樣為兩個禮拜一次,即每個月奇數週的禮拜一。
暑假由大魔王負責專題的溝通事項。
Yen的進度報告則在Meeting前傳送給大魔王。
專題評分方式改為依照個人預計達成之進度及實際達成之進度來評比。

目前進度:
???

細節:
後來與大魔王討論後,認為今後必須定期將個人預計達成之進度與實際達成之進度報告在網誌上,以方便馮大評比,也較容易掌握專題之進度。至於什麼時候開始,則在大魔王考完試後決定。



下次開會時間:
2009年 7月 6日(一)

預計下次開會前的進度:

擬定好暑假的進度。

2009年5月8日 星期五

第六次Meeting記錄

開會時間:
2009年 5月 4日(一)

討論內容:
報告目前進度與定位應用。

討論結果:
定位部分,WiFi為主,RFID為輔。
三個禮拜後再Meeting。

目前進度:
軟體開發中。
定位部份先實作wifi sample點的部份
做出大略位置的定位後,再以RFID做近一步詳細位置定位

細節:
盡量在三個禮拜後把目前延後的進度完成。



下次開會時間:
2009年 5月 25日(一) 12點半

預計下次開會前的進度:
Client 與 Server 端完成。(盡量趕工吧。)
實作wifi sample點&可訂出大略位置範圍

2009年4月14日 星期二

4/13 MEETING內容

開會時間:
2009年 4月13 日(一)

討論內容:
(1)報告client的程式流程圖
(2)報告client介面的架構
(3)報告RFID定位資料搜尋的結果

討論結果:
(1) 改成WIFI定位,RFID為輔
(2) 會員登錄改成RFID讀卡式




下次開會時間:


2009年5 月 4日(一)

預計下次開會前的進度:
(1)user端以及client端的軟體完成 然後測試完成
(2)找尋wifi定位(找看看有沒有可預防室內誤差的方法),以及RFID的使用資料

2009年4月10日 星期五

第四次Meeting紀錄

開會時間:
  • 2009年4月6日(一)

討論內容:
  • 目前進度報告及軟體設計。

討論結果:
  • 2009年4月20日的Meeting提前至4/13日。

目前進度:
  • Client端軟體設計進行中。

  • Server端軟體設計完成。

  • RFID定位資訊蒐集進行中。

細節:
  • Client端軟體設計於4/13日報告進度。

  • Server端軟體可先行實作。

  • RFID定位資訊也於4/13日報告進度。

下次開會時間:
  • 2009年 4月 13日(一) 中午12:30 在馮大Office

預計下次開會前的進度:
  • Client端軟體設計盡可能趕工。

  • 準備好RFID定位資訊的進度報告。

2009年4月5日 星期日

Javadoc註解格式

在Java中只要按照標準的格式去寫註解,就能用Javadoc tool來自動產生出HTML格式的說明文件。在此提供Javadoc的註解格式。

※由於Javadoc產生後為HTML格式的文件,因此文件中需要美工或圖片、連結的功能可以直接以HTML標籤加入。

Javadoc的標準註解格式為:

/**
* 註解第一行
* 註解詳細內容
* .........
*
*@tag
*/

若註解只有單行,可以用這種形式(類別或實體變數常使用這種形式):

/** 註解第一行 */

Javadoc tool能夠辨認的註解為類別、建構子、方法及成員的註解,因此Javadoc的註解區塊必須放置在上述幾種程式組成單位的起點前,上述組成單位的內部實作程式碼的註解將會被自動忽略,因此在類別、方法的註解中必須將內部實作的大略細節描述詳細,例如在java.util.arrays.sort(int[] a)的註解中,便詳細註明了所使用的演算法。類別也應該將其主要角色與必須知道的細節內容
請參考Java API Arrays類別中的 sort方法 :http://java.sun.com/j2se/1.5.0/docs/api/java/util/Arrays.html

Javadoc tool會將註解(無論是類別、建構子、方法、成員)的第一行視為是整段註解的結論,因此第一行註解必須以簡短的方式說明描述對象的功能以及應該注意的事項。Javadoc tool會判定句點後跟著空白、tab或換行字元的字串為一行,因此若在第一行中使用句點卻不希望被判定為換行的情況下,
可以用HTML的註解標籤<!-- -->或HTML空白字元&nbsp; 讓句號的下一個字元不是空白或tab。
詳情可參考:http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#descriptions

在註解的描述中,可以使用Javadoc tool認得的tag來標示某些屬性,幫助Javadoc tool排版或產生連結。tag以@開頭,緊接著是tag name,最後是參數。。

類別或介面註解能夠使用的tag如下:
  • @see
    稱為see also,有3種格式,如下:
    1. @see "字串"
      例如輸入:
      @see "The Java Programming Language"
      會產生:
      See Also:
      "The Java Programming Language"

    2. @see <a href="網址">顯示文字</a> (HTML連結)
      例如輸入:
      @see <a href="http://www.blogger.com/spec.html#section">Java Spec</a>
      會產生:
      See Also:
      Java Spec

    3. @see package.class#member label (最常用的一種)
      例如在註解裡輸入:
      /**
      * @see String#equals(Object) equals
      */
      會產生以下格式的HTML:
      <dl>
      <dt><b>See Also:</b>
      <dd><a href="../../java/lang/String#equals(java.lang.Object)"><code>equals</code></a>
      </dl>

      亦即,會產生連結到其他類別成員超連結。
      ※若是要連結到同一類別的成員,#號前的類別名稱可省略。
      ※若是要連結到同一包裝內的成員,類別前的包裝名稱可省略,如上述例子。
      ※注意若要連結到建構子或方法,參數型態必須寫好,參數名稱可省略。

  • @author
    作者署名,用法是直接在標籤後接名字,例如:
    - @author 嘴砲安

  • @since
    該類別加入時,軟體的版本。後面加上字串或數字就行了,例如:
    - @since 1.1
建構子或方法註解能夠使用的tag如下:
  • @see
    詳見如上。

  • @param
    方法或泛型的參數介紹。格式為 @param 參數名 參數說明。例如:
    /**
    * @param string 要被轉換的字串
    * @param type 要轉換成的型態
    * @param <T> 元素的型態
    * @param <V> 元素的值
    */
    <T, V extends T> V convert(String string, Class<T> type) {
    }

    ※類別的泛型參數也能夠使用此tag。

  • @return
    方法的回傳值。後面接回傳值的敘述即可,例如:
    - @return 以參數id為根據取出的商品,當找不到商品時則為null。
    ※在特殊情況下回傳的值(像null),必須註明。
    ※一個方法只有一個@return。

  • @throws
    方法所丟出的例外。後面接丟出的例外類型,以及會丟出例外的情況,例如:
    -@throws IOException 如果網路發生異常,或者無法取得需要的檔案。
    ※受檢例外一定要寫說明,否則就算沒有寫出該例外,Javadoc tool還是會產生無說明的@throws項目。若方法有覆寫(overriding)父類別的方法,才可以不寫受檢例外的說明,Javadoc會直接從父類別的@throws拷貝說明。

類別變數或實體變數註解能夠使用的tag如下:
  • @see
    詳見如上。

  • {@value}
    可以連結到類別裡final static變數的值。這是使用這註解內文的tag,格式為:
    - {@value package.class#field}
    例如:
    /**
    * The value of this constant is {@value}
    */

    public static final String SCRIPT_START = "<script>"

    /**
    * Evaluates the script starting with {@value #SCRIPT_START}.
    */
    public String evalScript(String script) {
    }

    ※{@value #SCRIPT_START}會被替換為 <script>


一些可以用在內文裡的tag:
  • {@link}
    產生到所在類別或其他類別之欄位、類別或方法的連結。格式為:
    - {@link package.class#member 顯示文字}
    例如如果要連結到同一類別的getComponentAt(int, int)方法,可以輸入:
    {@link #getComponentAt(int, int) getComponentAt}
    就會產生顯示文字是getComponentAt的連結,連結到同一類別裡的getComponentAt(int, int)的說明。

  • {@linkplain}
    跟@link的用途一樣,只是字型是用plain text。

  • {@inheritDoc}
    直接從最相近的父類別複製說明,複製的說明會顯示在tag放置的位置上。注意這個tag只能用在方法的註解內文、方法的@return、@param、@throws說明裡。
    ※注意如果覆寫父類別的方法卻沒有寫註解,Javadoc tool會直接複製父類別的說明。

  • {@literal}
    自動處理特殊文字。格式為 {@literal 文字} 。可以把像角括號或其他會被HTML視為特殊字元的文字處理成一般文字。

  • {@code}
    把文字以plain text的字體顯示出。格式為 {@code 文字}
    通常用來顯示數學公式或程式碼。


參考文章:
http://www.javatwofriday.com.tw/member/javamag_article/J040901502.pdf
http://www.javatwofriday.com.tw/member/javamag_article/J041001601.pdf
How to Write Doc Comments for the Javadoc Tool
Javadoc Reference Guide

2009年4月3日 星期五

Server端介面部分需要寫的Unit Test Case

  1. Server - 呼叫startService()後,以Socket丟入一個請求,收到回應後執行stopService(),若2秒內沒回應則測試失敗。stopService()後若丟入請求沒有發生錯誤,也視同測試失敗。

  2. Handler - 傳入一個InputStream(可以用ByteArrayInputStream,把測試字串序列化),與OutputStream(可以用ByteArrayOutputStream,把結果反序列化成字串),看OutputStream的結果是否如預期。測試文件請用XML格式,並使用以下階層:
    <Request type="product_query" >
    <account level="0" />
    <product id="00101001"/>
    </Request>

  3. RequestAnalyzer - 類似上述的做法,並對回傳的Request做檢驗,看是否確實取出元素。

  4. Responder - 類似上述做法,Request的值可以自己訂。


  5. ProductDataSource - 先寫open()、close()的狀態測試,測試addProduct後可以得到商品,及removeProduct後無法得到商品。getCategorySet和getCategory也一樣。其他部分先擱著。

  6. ContentProvider - 測試每次由getConnection()得到的Connection不是null,isClosed()也不能是true。對open()、close()做狀態的測試。

  7. AccountDataSource - 同ProductDataSource。
架構圖如下:
http://tw-yen.no-ip.org/images/RSs.png
紅色框框圍住的為界接介面,以黑色框框圍住的則是實作細節。

2009年3月29日 星期日

萬惡的微軟

我們的構想被萬惡的微軟搶先了:
http://www.foniao.net/index.php?option=com_content&task=view&id=217&Itemid=34

萬惡的微軟,連大學生的專題都不放過...Orz

2009年3月27日 星期五

Meeting時間改變

馮大說Meeting的時間改為星期一12點半,大家可以吃完午餐再去。

上一屆專題的評選時間

馮大說四年級專題的評選時間是4/10(五)下午1點~2點半,馮大的專題生是最後一組,排在2點。
由於最後一組可能會提早結束,最好提早10~15分鐘去。那天有空的人請一起去看看。

千萬別忘了。

2009年3月23日 星期一

第三次Meeting紀錄

開會時間:
2009年 3月 23日(一)

討論內容:
  1. 目前的進度報告與RFID的問題。(投影片連結)

討論結果:
  1. 軟體開發Server端與Client端改為每組2人惠姐楊媽負責蒐集定位的資料

  2. 負責軟體開發的人員禮拜三第四節討論軟體溝通介面

  3. 詢問電機系教授RFID的問題,並借借看器材。

  4. 能借到器材就借,不然只好買,預算大約一萬左右。

目前進度:
  1. 完成責任分派。

  2. 大略規劃出軟體開發時程。



下次軟體開發人員討論時間:
2009年3月24日(三) 11點30 三舍交誼廳

下次小組開會時間:
2009年3月30日(一) 12點30 三舍交誼廳

下次Meeting時間:
2009年4月6日(一) 12點整


預計下次Meeting前的進度:

  1. 完成軟體設計與單元測試程式。

  2. 蒐集RFID結合WiFi的定位資料。

2009年3月19日 星期四

接下來的任務

目前為止軟體的大略需求已經定好,所以可以開始談如何開發軟體了。
軟體分為兩個部分-Client和Server端,因此必須分兩組人馬來進行開發,兩組都必須有人設計軟體的架構,先將Use case圖畫出來,並詳細描述,之後再將Class diagram畫出來。Class diagram先從interface開始畫,以interface勾勒出整個軟體的大致架構後,再去進行實作。

3/23~4/6 必須把軟體架構與單元測試程式完成。
4/7~4/21 實作軟體的細節。
4/22 ~ 4/29 測試另一組人寫的軟體。

註解必須遵守JavaDoc的規格,單元測試則使用JUnit來製作。
說明文件這幾天會PO上來。

原則上是用Netbeans的共同開發功能來編寫軟體,CVS伺服器我會在這周末架好。

以上。

2009年3月10日 星期二

第二次Meeting的記錄

開會時間:
  • 2009年3月9日(一)

討論內容:
  • 專題題目的確定以及可行性。

討論結果:
  • 專題分為兩個部分電子購物車使用者定位

  • 電子購物車是以RFID偵測使用者放入購物車中的商品,並且顯示商品細節及總價格至行動裝置上。結帳時只需要以計算好的價格結帳,省去目前必須個別讀取商品條碼的麻煩。若具有會員資格,也會一起傳送,自動由電腦計算優惠等訊息,如此一來便不需要隨身攜帶會員卡。也可以事先輸入預算與購物備忘錄,方便使用者理財。

  • 使用者定位則是以RFID的方式偵測顧客目前的所在地,並能指引顧客至需要的商品附近。由於在約3公尺距離內目測就能夠看見商品,因此精確度不需要很高。詳細情形可以參考這篇論文:http://etdncku.lib.ncku.edu.tw/theses/available/etd-0826108-145013/unrestricted/etd-0826108-145013.pdf

  • 目前先從軟體方面動工,從資料庫的建製下手。硬體如何取得稍後再想辦法。

目前進度:
  • 定好專題題目。
  • 先把重心放在電子購物車的實作上,定位問題則先等資料蒐集齊全再決定使用何種方式實作。
細節:
  • 目前RFID存在許多問題,包括容易受金屬及液體(目前已有公司研發解決方案)干擾、以及頻段尚未統一(時間上的問題)、定位不精確及成本偏高。上述問題有些不是目前科技能夠解決的,但還煩請藍藍路繼續找尋有無感應距離大約是1m且容易與行動裝置聯繫的RFID Reader。目前是有看到用SD和CF卡介面的Reader,但距離都相當短,最多14 cm。若找不到,可以考慮做出袖珍版來模擬就好。

  • RFID的定位不精確且容易受干擾,找尋有無其他可行替代方案。目前聽說有使用Wi-Fi的方式(頂天端推薦),但其可行性目前尚不確定,麻煩嘴砲安及惠姐搜集一下情報,計算sample點的間隔距離與100m*100m範圍內所需設立的sample點數量、精確度及成本。關於訊號干擾問題的資料也麻煩多留意(目前看到的資料是寫易受空氣及其他頻率干擾,且精確度不高)。

  • 麻煩修二尋找目前Wal-Mart使用RFID所遇到的困難,與目前使用的情形。最好能找出Wal-Mart所使用的RFID tag的規格與儲存資訊的格式。

  • 電子購物車目前的硬體架構藍圖麻煩先由大魔王繪製,3/16號中午12點大家一起討論。

  • 商品資料庫的ER-Model藍圖則由Yen負責繪製,一樣在3/16中午討論。

  • RFID為供應鏈帶來的效益可以看http://rfid.me.ntu.edu.tw/teaching/CH9.ppt

上述指派的工作除了硬體架構藍圖和ER-Model必須在3/16號完成外,其餘在3/16號報告工作進度,並在3/20號前徹底完成,將重點整理成PPT檔,傳給彙整者即可。彙整者在3/16號當日指派。



下次小組開會時間;
2009年3月16日(一) 中午12點整。
討論購物車硬體架構及ER-Model,並將目前蒐集到的資料先整理出來讓大家了解各自的進度。

下次與教授Meeting時間:
2009年3月23日(一) 中午12點整。


預計下次Meeting前的進度:
  1. 整理出RFID在電子購物車及定位上會遇到的問題。
  2. 將資料庫的內容規劃出來。
  3. 完成購物車的硬體架構圖。
  4. 開始繪製軟體藍圖及UI設計。

2009年2月23日 星期一

第一次Meeting的紀錄

開會時間:
  • 2009年2月23日 (一)

討論內容:
  • 專題的大致方向。

討論結果:
  • 大家在下次meeting前,想出以行動裝置結合網路應用為主軸的可能需求。
  • 範例有林務局的防火災裝置、餵魚裝置、管理員以網路遙控開啟閘門、博物館的導覽系統。
  • 希望大家能想出不同的點子。
  • 下次meeting前完成工作分配

目前進度:
  • 得到兩張光碟,一張為餵魚裝置,一張內容尚未驗證。
  • 得到林務局監控系統與餵魚裝置的報告書,並存放於美術社社辦。

細節:
  • 希望組員在下禮拜三(2009/3/4)前能夠想出不錯的需求,並於當天11點30~12點30(原本OS那節課)在三舍交誼廳討論各位的點子與專題的分工。
  • 將討論結果做成3/9要報告的資料或投影片。
  • 時間上有問題的請盡快提出,



下次開會時間:
  • 2009年3月9日 (一)

預計下次開會前的進度:
  • 敲定專題的具體內容。
  • 完成組員分工。