兩天開會總結 收費系統 架構

每次開會，我都很高興，不過沒想到這次竟還是個持久戰哈。

1月30號早8點開始上課，截止到昨天晚上12點，這兩天的時間我們大部分時間都在南五小屋開會討論關於機房收費管理系統的架構和相關知識的引用。

很早以前，每次開會，公尺老師和我們討論的，都是巨集觀上的思想，不會細到程式設計**裡邊去，多是因為那樣會導致我們陷進去，理不出思路來。思想和技術同步，思想層次高了需要依仗技術上的實現，技術上的提公升更離不開思想的高度，彼此相輔相成，公尺老師主抓我們的思想，而我們在機房實現的就是技術的提高了。

我以前認為這個機房收費管理系統就是使用物件導向（類、多型、繼承、介面等）來做，現在看來也的確是那樣的，可是有一點不同，通過這兩天的討論，我發現自己以前所想還只是部分物件導向，而非全部物件導向，既然物件導向相較面向過程等等好處更多，為什麼不做成完全物件導向呢，這算是我這兩天來的乙個醒悟。（開會的時候還提到了物件集，針對資料庫中每一條記錄都例項為乙個物件，這樣用物件導向來處理這個細節；還有比如說學宇自己寫的hebernate框架，就是面向sql語句的。）

巨集觀上來看，我們用rose畫的系統包圖主要體現的就是系統架構情況，告訴軟體開發人員這個系統是如何分層的，是如何將系統的繁雜關係分離開的，如何做到系統的強擴充套件，也使得開發人員之間的團結合作更加容易，更確定了乙個共同努力的目標，同時這也凸顯了存在的約束(很重要),就說我們uml建模的時候，需要用到五種關係（依賴è關聯è聚合è組合è繼承），既然關係劃分開了，那麼肯定有些許的不同，那麼對於我們在建模圖中表示的直線和箭頭就承載著這五種關係，表示兩端物件的關係，這其中還承載著一種約束，用公尺老師說的木匠做三腿板凳這其中的各個約束，就是使得系統有乙個範圍的約束，各個模組都在約束中完成自己的功能，也不至於組建之後的系統由於各個模組間缺乏約束合作，而分崩離析。

構建系統中的各個約束，這都會體現在uml建模中，將在圖上體現的淋漓盡致，但是畫圖建模也是要詳略得當，用例圖等不必太細，而時序圖倒是需要詳細一點，並且個中要求都是要認真考究的，時序圖做的細了，在後面實現系統的時候能幫我們很好的校驗，差錯。

並且這次開會，公尺老師問我們uml建模中的其他圖，比如協作圖，部署圖等等，都有什麼用？怎麼用？(緣於我們的圖裡邊有用例圖、時序圖、類圖，而缺少後面的這些協作圖等)，既然rose經過了大浪淘沙，現在還暫居主流，那麼存在就有存在的道理。有何用，如何用，都是要在實踐中、失敗後總結的。

通過這兩天開會，整天的架構明了了很多，今天又看了看自己畫的圖，和已經寫的一些基礎**對照，之間的對應關係還是比較明了的。不過為了更好的把這段時間的學習貫穿起來，還是要奔著完全物件導向去做的，即使會對原來的東西改動很大，但是這是經驗。公尺老師說，失敗是我們的驕傲和資本，也是說出了我們積累經驗的途徑和過程。

接下來就要好好實現系統了。

兩天開會總結 收費系統 架構

每次開會，我都很高興，不過沒想到這次竟還是個持久戰哈。1月30號早8點開始上課，截止到昨天晚上12點，這兩天的時間我們大部分時間都在南五小屋開會討論關於機房收費管理系統的架構和相關知識的引用。很早以前，每次開會，公尺老師和我們討論的，都是巨集觀上的思想，不會細到程式設計 裡邊去，多是因為那樣會導致我...

兩天的總結

昨天實在是太累了，晚上一回來倒頭就睡，也沒看幾點，反正是9點之前 有史以來最早睡的一次 然後就沒有寫日誌了 今天補做。其實，這兩天的生活大致相同，大半天時間都是在寶山網球館，隨著比賽的進行，越來越多的選手被淘汰，比賽也越顯精彩許多，屢屢出現那種連續搶七的三盤大戰，雖然讓觀眾一飽眼福但卻是苦了我們當球...

兩天C 專案總結

這兩天做了乙個簡單的銀證轉賬管理系統，做得不是很滿意，但是其中學到了一些很實用的東西，比如socket多執行緒程式設計，介面設計要統一等等.現在結束了特想寫個部落格記錄下，以後再寫相關的專案就能很好地利用上這些資源。1 show是模態對話方塊，showdialog是非模態對話方塊，如果用show來現...