在實際專案中用UML建模的總結

2021-08-26 22:42:56 字數 777 閱讀 2926

做機房收費系統的時候,剛對uml有乙個大致的概念,就開始了對機房收費系統的建模。

uml可以理解為乙個分析交流的方法。多個人建乙個系統,人多了,為了避免歧義,就得用標準化的交流方法。圖形表現力最強,所以在眾人進行交流的時候,畫圖最好。

建模的過程:在建模的過程中花了大量的時間。開始其實沒有什麼建模的概念,就知道要畫用例圖,類圖,時序圖,至於怎麼把系統合理的反映在圖上,就不知道了。於是各種嘗試,首先是用例圖,當時參考了《大象thinking in uml》這本書,這本書講的很細,用例圖就有三種,業務用例分析,系統用例分析,系統用例實現。當時都讓我一一嘗試了。結果是越畫越不明白,用例圖這就搞暈了。

現在會過頭來看,不管如何建模,建立乙個清晰的系統模型才是關鍵,糾結在乙個小知識點上意義不大,比如說某個用例的粒度該怎麼確定,到底該用哪些實體類。因為學習需要乙個過程,不可能通過一遍就認識全面,重要的是進行下去,不要因為困難多就在這停住了。由於沒有乙個巨集觀上的理解,因此就在乙個個小知識點上來回徘徊,到最後應用的效果還很不好。

現在回想建模的過程就清晰多了,用例圖確定系統的主要功能。然後畫出三層的包圖來確定下系統的大體結構(可以說是系統的架構),再之後確定每個包裡面的類。然後通過用例和類畫一下就差不多了。這就是我現在對機房收費系統uml的理解(有待加深,嘿嘿)。

用uml建模,說到底還是搭雞窩和建摩天大樓的區別了。第一次用vb敲機房收費系統,就大概分析了要實現什麼功能,當時的水平根本不知道還有建模這回事,然後就開始敲**了,可能連雞窩都算不上。現在知道敲程式之前要分析,建模,也就是把程式的大體框架搭建一下。搭雞窩的時候用不著這個,建摩天大樓的,這個就比較重要。

在實際專案中用UML建模的總結

做機房收費系統的時候,剛對uml有乙個大致的概念,就開始了對機房收費系統的建模。uml可以理解為乙個分析交流的方法。多個人建乙個系統,人多了,為了避免歧義,就得用標準化的交流方法。圖形表現力最強,所以在眾人進行交流的時候,畫圖最好。建模的過程 在建模的過程中花了大量的時間。開始其實沒有什麼建模的概念...

關於cachedrowset在實際專案中的應用

由於專案需求原因,需要實現乙個功能就是,抽取大量的資料庫資料然後寫入文字並打包上傳。看似乙個很簡單的東西,在大資料量的環境下就顯得不是那麼簡單了。首先有60張左右的表需要進行資料的處理。各個公司情況不同,表的總資料量可能是幾千萬到幾十億不等。所以,耗時非常嚴重。由於只是單純的進行資料的提取加工寫入文...

OTP在實際專案中的整合

提起動態令牌,大家都會想到認證伺服器,而這個認證伺服器又怎麼應用到實際的應用系統中呢?在這裡做乙個分析和說明,幫助廣大使用者能夠更好的使用otp動態令牌這種身份認證產品。從前面otp原理部分中可以看出,伺服器端是在乙個範圍內計算出多個otp,然後檢驗客戶端硬體產生的otp口令是否在這個範圍內。那麼伺...