與機房收費系統圖的初步情結

 從六月一號開始著手畫的UML圖，現在已經一個半月過去了！下面說說這一個半月來我與UML圖的情結吧：

第一階段： 6月1號—6月5號 

1.第一步使用案例圖

  使用案例圖主要是系統的功能模型圖，有第一次機房收費系統的畫圖經驗，所以這個使用案例圖是最簡單不過了，並不糾結！

2.第二步 包圖

    主要是根據經典的三層架構來畫，主要分為實體層，介面層，商務邏輯層和資料訪問層。前面已經學習了三層的理論和實踐，所以經典三層架構並不感覺到困難。

    介面層：毫無疑問就是使用者能直觀看到的表單；下面是商務邏輯層，這個就難辦多了，這時候稍微有點困惑了，這個商務邏輯到底應該根據什麼來劃分比較好呢？分析了一下系統，發現整個系統都是圍繞著增、刪、改、查這四個功能來進行實體層與資料庫進行一一對應；從實體層可以得出資料訪問層，資料訪問層：主要是進行對資料庫的操作，也就是對錶進行增、刪、改、查的操作。

3.第三步 時序圖

   再畫時序圖的時候，想起了師父說過要加設計模式，最基本的要瞭解抽象工程模式+反射+設定檔的用法。所以進行了下一階段。所以先把設計模式添加到包圖中，再進行時序圖！

第二階段：6月6號—6月15號 

      經典的三層架構完成之後，就想往上面加設計模式！最基本的就是抽象原廠模式+反射+設定檔了。

       這個階段挺糾結的，主要是對抽象原廠模式+反射+設定檔很不理解。學設計模式的時候，反射那一塊就看不懂！上次看不懂還可以忽略它，因為我們並沒有用到它，但是這次不行了，所以抱著一定要弄懂的心情去學習！先是回頭看大話設計模式關於抽象原廠模式那點知識，然後是上網找資料和找一個抽象工程模式模式在三層中的應用的一個執行個體來學習。最後是拿機房收費系統的登入表單進行開刀。這次對抽象原廠模式+反射+設定檔的用法總算是有了進一步的認識。這也驗證了那一句話：學習是一個過程。剛開始的時候，我們對這一塊並不懂，但是當你用到的時候，你再回過頭來學習，就相對於來說容易多了。就拿這次的模式來說，我們之前學習設計模式的時候，我們要學的是23個模式，現在想起來腦子還是一片混濁。但是，我們現在由於系統的需要，我們需要知道抽象原廠模式，這時候我們就有目的的去學習具體的某一個模式，大大的減少新知識的量。所以也就輕鬆多了，而如果我們一開始，就非要把這23個模式一個個的都弄懂的話，那不累死才怪呢？

       之後就是重新在第一階段的基礎上對包圖進行修改，這次加上了抽象原廠模式。

   緊接著是畫時序圖，這裡停留了兩天都沒進展，不知道該怎麼辦？感覺應該是自己前面畫的包圖（B層)有出問題了吧。所以找導師檢查了自己前面的圖：

     經過導師檢查，自己再畫圖的時候暴露的問題和需要完善的：

      1.使用案例圖：應該畫在Use Case View下面，而我是把所有的圖都堆積到一起了

      2.時序圖：

           a.因為時序圖主要是根據功能來進行的，所以一個時序圖應該對應一個用例，而且應該畫在使用案例圖下面。

           b. 時序圖調用的方法沒有參數與傳回值

           c.工廠的主要作用是為了建立對象，並且通過反射執行個體化出介面，所以工廠層與資料訪問層之間不應該存在調用關係，而應該是由工廠建立好對象之後，返回給商務邏輯層，商務邏輯層再通過方法進行調用。

      3.包圖：

          a.B層的劃分應該是按照商務邏輯來進行劃分，B層的主要作用就是為瞭解耦，即隔離對資料庫的直接操作，而我根據增、刪、改、查功能來進行劃分，很明顯的又跟資料庫掛鈎上 了！

          b.D層命名參考規範，方法考慮不周全，需要有參數和傳回值。

          c.建議使用原則模式和單例模式。

     總而言之，在學習的過程當中，應該是讓自己保持輕鬆，愉快！

     始終相信學習本身就是一件快樂的事情就可以了！