在路上

路上有驚慌，路上有理想

BlogJava :: 首頁 :: 聯(lián)系 :: 聚合

:: 管理

28 Posts :: 1 Stories :: 10 Comments :: 0 Trackbacks

[導入]websphere下使用jndi lookup

首先：websphere server處于啟動狀態(tài)，jndi已在服務器下配置，名稱為 mail/wfewcs/wfewcs_mailservice

1.在需要脫離container(app未部署至websphere)進行JNDI lookup查找時，

可以使用如下代碼（以mail session的jndi為例）：

Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming.WsnInitialContextFactory");
        properties.put(Context.PROVIDER_URL, "iiop://localhost:2809/");
    Context ctx=new InitialContext(properties);
    Session mail_session= (Session)ctx.lookup("mail/wfewcs/wfewcs_mailservice");

JAR要求:wssec.jar, naming.jar, namingclient.jar, sas.jar and ecutils.jar,如果IDE為IBM RAD，則只需添加websphere運行時庫以及namingclient.jar包即可(此jar不在websphere運行時庫中)。

2.在container中(app已部署至websphere)進行jndi lookup查找：

比較簡單:

Context ctx=new InitialContext();
Session mail_session= (Session)ctx.lookup("mail/wfewcs/wfewcs_mailservice");

posted @ 2010-02-27 15:38 阮步兵閱讀(903) | 評論 (0) | 編輯收藏

[導入]編寫用例(3)

用例模板



UC01: XXXXXXXXXX
Description

      XXXXXXXXXXXXXXXXXXXXXXXX
Interacting Actors

·    XXXXXXX
Related Use Cases
    XXXXXXX
Preconditions/Assumptions for all Flows

·         XXXXXXXXXXXXXXXXXXXXXXXX
Main Flow of Events
Main Flow Description

XXXXXXXXXXXXXXXXXXXXXXXX
Main Flow Preconditions/Assumptions

·         None
Main Flow Description

1.       XXXXXXXXXXXXXXXXXXXXXXXX

2    XXXXXXXXXXXXXXXXXXXXXXXX
Main Flow Postconditions

·         XXXXXXXXXXXXXXXXXXXXXXXX
Main Flow Notes

·         None.
Alternate Flow of Events #1
XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Description

XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Preconditions/Assumptions

XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Description

1.      XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Postconditions

·         XXXXXXXXXXXXXXXXXXXXXXXX
Alternate Flow Notes

·         None.
Postconditions for all Flows

·         None
Exceptions for all Flows

XXXXXXXXXXXXXXXXXXXXXXXX
Business Rules for all Flows

   XXXXXXXXXXXXXXXXXXXXXXXX
Design Notes for all Flows

· XXXXXXXXXXXXXXXXXXXXXXXX
Issues/Comments for all Flows

·         None.

posted @ 2010-02-27 15:38 阮步兵閱讀(239) | 評論 (0) | 編輯收藏

[導入]編寫用例(2)

目標層次的劃分:

在對系統(tǒng)的設計范圍進行確認后，下一階段的工作便是劃分每個業(yè)務目標的層次結(jié)構(gòu)

目標層次的劃分如下圖：

水平面以上的為概要目標，對相似功能業(yè)務的一種概括。對于屬于概要目標范圍的用例說明，用例序號之后做(*)號以作區(qū)分

水平面上的為用戶目標，也就是業(yè)務功能點。

水平面一下的為子功能點，包含于用戶目標之中。對于屬于子功能范圍的用例說明，最好在用例序號之后做(+)號以作區(qū)分

執(zhí)行者與場景：

用例目標層次劃分后，該到用戶目標用例的定義，這里面最主要的概念就是執(zhí)行者與場景

a.收集一個用戶目標的所有場景，定義主成功場景。其他場景為擴展。

主執(zhí)行者完成了目標，所有系統(tǒng)相關者的需求都被滿足，這個場景就是主成功場景。

其他的成功場景和所有的錯誤處理場景，都會在主成功場景的擴展中進行描述

b.場景主體的描述

兩個執(zhí)行者之間的交互過程——客戶輸入地址等

保護系統(tǒng)客戶需求的確認過程——系統(tǒng)確認PIN密碼等

滿足系統(tǒng)客戶需求的內(nèi)部變化——系統(tǒng)扣除某個產(chǎn)品的庫存等

posted @ 2010-02-27 15:38 阮步兵閱讀(236) | 評論 (0) | 編輯收藏

[導入]編寫用例(1)

用例技術是很多項目中都會應用到的。usecase文檔的編寫可以說是入門簡單，人人都能寫，但是難于深入，寫好了不容易。這主要在于語言文字的運用。凡是涉及到文字的東西，都是長于嚴謹，短語直觀。下面就談一談編寫用例個人的感想。

編寫用例文檔的準則

1. 使用簡單的語法

句子不宜過長，句子結(jié)構(gòu)不要過于復雜。平鋪直敘，簡明扼要。重復解釋一個問題，有時不失為一種必要。

2. usecase步驟的描述盡量不要過多

10步以內(nèi)。太長不易于理解。讓讀者看起來很繁瑣。

3.增加直觀性，輔以圖形化的手段來闡釋：UML 的usecase圖。圖形唯一的缺點在于維護，一點改變，就可以讓所有的圖重畫。

確定系統(tǒng)邊界:

1.in-out list

Topic，為系統(tǒng)需求點。以in 標志為系統(tǒng)內(nèi)部需求，以out標志系統(tǒng)外部需求。系統(tǒng)內(nèi)的屬于工作內(nèi)容，系統(tǒng)外的屬于考慮范疇。內(nèi)外表法不只可以用在用例編寫階段，也可以用在需求分析階段。

2 actor-goal list

posted @ 2010-02-27 15:38 阮步兵閱讀(265) | 評論 (0) | 編輯收藏

[導入]需求分析：問題分析

在需求采集結(jié)束后，就進入了一個相對重要的環(huán)節(jié)：問題分析。

1.問題與客戶達成共識

這個共識有簽字式的——協(xié)議，也有非簽字式的——確認。

記住，所有的共識都基于雙方的理解。文字的東西往往會引起歧義，電話確認又往往失于嚴肅。圖形化的方法可以彌補這些缺憾。個人經(jīng)驗，文字的描述比較適用于早起的問題收集，或者是簡單的問題確認。復雜的問題需要交給圖形化來解決，wireframe——虛擬界面，是個不錯的選擇。它除了可以收集輸入輸出數(shù)據(jù) 項，還可以給客戶一個比較直觀的感覺。當然，這個也相對費時一些。但對于需求的確認至關重要，可以減少客戶與軟件人員的誤解。

2.找出問題背后的發(fā)生原因

韋伯說過，社會行為是行動者賦予主觀意義的人類行為。任何人（團體、組織）的活動在社會中都會牽涉到另一個人（團體、組織）。任何行為本身都具有意義，如無意義，則無行為。

扯遠了，還是談談需求問題。客戶問題的提出，是為了解決問題。要想解決問題，就必需知道問題是如何產(chǎn)生的。也就是說，要想找到蛋，就必需先找到下蛋的雞，研究它的活動軌跡，最后定位雞蛋的位置——解決問題。在社會學里，找到了行為的意義，也就掌握了行為本身。記住，無意義就無行為，有行為則必有意義。

3.確定系統(tǒng)用戶

包括用戶的角色和權限。這是系統(tǒng)能夠運行起來的基本條件。如果不能引起足夠的重視，對于系統(tǒng)將是嚴重的災難。筆者曾做過一個office resource management系統(tǒng)，從初始的一個角色對應一個office,到一個role對應多個office,一個人一個角色，到一個人多個角色。修改之多，之繁重，不能與人言。

4.確定系統(tǒng)邊界

在實踐過程中，個人引入了"內(nèi)外表"來定義系統(tǒng)邊界。這個在稍后的usecase中具體描述

5.劃分子系統(tǒng)的三個原則：

a.職責不同的功能劃歸不同子系統(tǒng)：將一類包含統(tǒng)一職責的功能劃分為一個子系統(tǒng)。如權限管理系統(tǒng)與業(yè)務系統(tǒng)分離。（企業(yè)系統(tǒng)需要統(tǒng)一的權限管理：安全認證以及系統(tǒng)授權），再如社會保障信息系統(tǒng)按業(yè)務類別的劃分：養(yǎng)老，醫(yī)療，工傷，失業(yè)，生育。按照業(yè)務規(guī)則劃分又可以分為：公共業(yè)務（單位，個人），待遇，報表

b.需要不同開發(fā)技能的單元劃歸不同子系統(tǒng):如報表系統(tǒng)與數(shù)據(jù)倉庫的獨立開發(fā)。

C.軟件工程管理的劃分：

1)兼顧工作量的相對均衡，進一步切分太大的子系統(tǒng)。交給不同的team進行并行開發(fā)。

2)同一類公用\復用模塊劃分為一個子系統(tǒng)：如規(guī)則引擎，簡單報表，css theme管理，數(shù)據(jù)同步\交換，基礎平臺的二次開發(fā)(統(tǒng)一彈出式查詢,輸入校驗,頁面組件)等等。

posted @ 2010-02-27 15:38 阮步兵閱讀(243) | 評論 (0) | 編輯收藏

[導入]需求分析：問題采集

題解：做了多個系統(tǒng)的需求分析之后，有做總結(jié)的必要了。

在需求分析階段，甚至是整個軟件開發(fā)階段，需求的變化是唯一不變的東西。項目中最難做的也是如何去控制需求。這個有點復雜，放到后續(xù)文章去說，先說說如何將客戶的問題信息轉(zhuǎn)化為需求：

1.分清客戶的問題是“需要”還是一個“需求”

需要，指問題已明確。需求則表示問題未明確

2.分清最好有與必須有。

必須有，這個是硬性需求；最好有，非硬性需求。根據(jù)項目的實際情況，如成本，時間(計劃)，范圍的約束來綜合評定。

3.客戶對問題的描述是為了說明問題還是提供一種解決方案

在收集和分析客戶需求時，一定要搞清楚客戶是在描述問題本身還是問題的解決方案

4 有哪些人使用這個系統(tǒng)

俗語說，有什么樣的客戶，就有什么樣的系統(tǒng)。客戶的能力以及偏好，包括理解力，對系統(tǒng)的設計至關重要。

5.有那些人不喜歡這個系統(tǒng)

是辦公室政治？是易用性？是穩(wěn)定性？maybe something else

6.挖掘潛在問題，形成問題鏈

客戶大都沒有系統(tǒng)訓練，他們對問題的描述往往比較零散和隨意。如何將問題竄成鏈，挖掘更深層次的問題是需求分析人員需要幫助他們完成的。記住是幫助，不是強迫他們按照你的思維思考問題。這里面最難的部分屬于如果從軟件專業(yè)人員的角度提出建議。同時又要讓自己的的建議不干擾到客戶的原始需求。

根據(jù)個人的經(jīng)驗，需求階段最大的悲哀在于你出于最好的目的卻造成了最壞的結(jié)果——建議客戶如何如何，建議有時會掩蓋客戶的真實想法。客戶信任我們的建議，他們誤以為我們的建議可以解決他們的問題，然而有時事與愿違。所以，我們應該多聽客戶的想法，延遲你的建議與引導。

7.非功能性需求的采集

易用性，擴展性，交互性，性能，安全性等等。

posted @ 2010-02-27 15:38 阮步兵閱讀(301) | 評論 (0) | 編輯收藏

[導入]Effective Java總結(jié)

1.使用靜態(tài)工廠方法構(gòu)造對象
2.Boolean.valueOf() 即是1的實現(xiàn)，類似的還有collection集合的實例化，所有的集合實現(xiàn)類都是通過collection的靜態(tài)工廠方法構(gòu)造的。
3.靜態(tài)工廠方法比構(gòu)造函數(shù)的好處：可以構(gòu)建原類型的子類.不一定每次都創(chuàng)建新的對象。缺點：靜態(tài)/如果工廠方法不是公有則不能被子類繼承
4.注意銷毀過期的對象.array=null
5.對于函數(shù)里需要構(gòu)建復雜的對象時需要注意，是否可以放到類的成員變量，這樣就不必每次調(diào)用該函數(shù)都創(chuàng)建新的復雜對象
6.避免創(chuàng)建重復的對象strng a=new String("a"); ---> String a="a";
7.當你改寫 equals時，總是要改寫hashcode方法:相等的對象必須具有相同的散列碼，這樣在此對象與map合用的時候才不會出錯
8.復寫 equals原則：自反性，對稱性，傳遞性，一致性
9.equals方法的參數(shù)一定要說object，方法內(nèi)不要依賴不可靠資源
10. 提供對象的toString方法
11.實現(xiàn)Cloneable接口提供克隆機制：深層克隆
12.接口優(yōu)于抽象類
13.組合優(yōu)于繼承
14.compareTo,Comparable接口比較
15.注意方法的參數(shù)檢查

posted @ 2010-02-27 15:38 阮步兵閱讀(345) | 評論 (0) | 編輯收藏

[導入]Apache CouchDB在Ubuntu下的安裝

先下載couchdb安裝文件：版本為0.9.1

http://couchdb.apache.org/downloads.html

1開始安裝依賴包

sudo apt-get build-dep couchdb

sudo apt-get install libmozjs-dev libicu-dev libcurl4-gnutls-dev libtool

2.解壓縮

tar -zxvf apache-couchdb-0.9.1.tar.gz

3.開始安裝

cd apache-couchdb-0.9.1

./configure

make

sudo make install

4.啟動couchdb

sudo couchdb

5.訪問:http://127.0.0.1:5984/_utils/

啟動報錯：

$ bin/couchdb















Apache CouchDB 0.9.0a691361-incubating (LogLevel=info) is starting.







{"init terminating in do_boot",{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1},







{erl_eval,do_apply,5},{erl_eval,exprs,5},{init,start_it,1},{init,start_em,1}]}}







Crash dump was written to: erl_crash.dump







init terminating in do_boot ()







查了一下官方wiki:







原來是安裝文件夾的權限問題















解決辦法：







sudo adduser couchdb







chown -R couchdb:couchdb /usr/local/etc/couchdb 







chown -R couchdb:couchdb /usr/local/var/lib/couchdb 







chown -R couchdb:couchdb /usr/local/var/log/couchdb 







chown -R couchdb:couchdb /usr/local/var/run 







chmod -R 0770 /usr/local/etc/couchdb 







chmod -R 0770 /usr/local/var/lib/couchdb 







chmod -R 0770 /usr/local/var/log/couchdb 







chmod -R 0770 /usr/local/var/run















再此啟動，看到歡迎界面，所有的testsuite run success,大功告成！