從10月份到重慶工作後，一直忙於工作，感興趣的幾個方面的技術都處於暫停。
乙個多月來，按照公司要求在做b/s集中式基衛產品的原型，主要是畫原型圖，開始是用axure，弄來弄去感覺功能還是弱了些，尤其是不同page之間的呼叫，大多少情況下需要借助全域性變數進行操作，非常麻煩，另外介面也比較難看。看了網上的介紹，由於個人比較熟悉delphi，決定試用unigui。做了一周多效果還是不錯，體驗總結如下：
1、用unigui開發，就如同c/s開發一樣，非常方便，包括類繼承、frame、介面視覺化設計等；
2、我個人習慣使用datasnap+dbexpress，unigui框架下都支援，資料庫操作一點問題沒有；
3、用了一周多後，感覺有幾個遺憾的地方：
（1）沒有help資料，demo又太簡單了，網上介紹也比較少，很多功能只能試，比較費時間；
（2）由於採用伺服器運算方式，整體效能偏低，幾個客戶端還好，量大了應該不行；
（3）沒有源**，難以擴充，比如想繼承現有控制項，弄幾個業務上專用的控制項，結果不行，另外發生bug時，找問題比較困難。
總的來講，unigui用作業務系統開發還有待觀察，但是用作原型開發，只要熟悉delphi，又在做b/s的可以考慮。
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...
業務用例和系統用例
業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。第乙個壞訊息 編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去...
做系統 貴在理清 業務需求
機房收費系統總結 做乙個已成型的小系統，如果由乙個人單獨完成，那麼在做系統之初，對於詳細分析內部關係的意義，可能體現得並不那麼明顯。因為先做什麼，後做什麼，基本上執行一遍，到處點點，可能就了解得差不多了。但對於複雜一點的系統，尤其是多模組，由不同的人分工進行，那麼就需要在做前對系統理清邏輯，搞清楚業...