做機房收費系統的時候，剛對uml有乙個大致的概念，就開始了對機房收費系統的建模。
uml可以理解為乙個分析交流的方法。多個人建乙個系統，人多了，為了避免歧義，就得用標準化的交流方法。圖形表現力最強，所以在眾人進行交流的時候，畫圖最好。
建模的過程：在建模的過程中花了大量的時間。開始其實沒有什麼建模的概念，就知道要畫用例圖，類圖，時序圖，至於怎麼把系統合理的反映在圖上，就不知道了。於是各種嘗試，首先是用例圖，當時參考了《大象thinking in uml》這本書，這本書講的很細，用例圖就有三種，業務用例分析，系統用例分析，系統用例實現。當時都讓我一一嘗試了。結果是越畫越不明白，用例圖這就搞暈了。
現在會過頭來看，不管如何建模，建立乙個清晰的系統模型才是關鍵，糾結在乙個小知識點上意義不大，比如說某個用例的粒度該怎麼確定，到底該用哪些實體類。因為學習需要乙個過程，不可能通過一遍就認識全面，重要的是進行下去，不要因為困難多就在這停住了。由於沒有乙個巨集觀上的理解，因此就在乙個個小知識點上來回徘徊，到最後應用的效果還很不好。
現在回想建模的過程就清晰多了，用例圖確定系統的主要功能。然後畫出三層的包圖來確定下系統的大體結構（可以說是系統的架構），再之後確定每個包裡面的類。然後通過用例和類畫一下就差不多了。這就是我現在對機房收費系統uml的理解（有待加深，嘿嘿）。
用uml建模，說到底還是搭雞窩和建摩天大樓的區別了。第一次用vb敲機房收費系統，就大概分析了要實現什麼功能，當時的水平根本不知道還有建模這回事，然後就開始敲**了，可能連雞窩都算不上。現在知道敲程式之前要分析，建模，也就是把程式的大體框架搭建一下。搭雞窩的時候用不著這個，建摩天大樓的，這個就比較重要。
在實際專案中用UML建模的總結
做機房收費系統的時候，剛對uml有乙個大致的概念，就開始了對機房收費系統的建模。uml可以理解為乙個分析交流的方法。多個人建乙個系統，人多了，為了避免歧義，就得用標準化的交流方法。圖形表現力最強，所以在眾人進行交流的時候，畫圖最好。建模的過程 在建模的過程中花了大量的時間。開始其實沒有什麼建模的概念...
關於cachedrowset在實際專案中的應用
由於專案需求原因，需要實現乙個功能就是，抽取大量的資料庫資料然後寫入文字並打包上傳。看似乙個很簡單的東西，在大資料量的環境下就顯得不是那麼簡單了。首先有60張左右的表需要進行資料的處理。各個公司情況不同，表的總資料量可能是幾千萬到幾十億不等。所以，耗時非常嚴重。由於只是單純的進行資料的提取加工寫入文...
OTP在實際專案中的整合
提起動態令牌，大家都會想到認證伺服器，而這個認證伺服器又怎麼應用到實際的應用系統中呢？在這裡做乙個分析和說明，幫助廣大使用者能夠更好的使用otp動態令牌這種身份認證產品。從前面otp原理部分中可以看出，伺服器端是在乙個範圍內計算出多個otp，然後檢驗客戶端硬體產生的otp口令是否在這個範圍內。那麼伺...