第一，用例講解。
用例分可以有兩種分類方法，乙個是按照功能模組分，乙個是按照角色分，這兩個各有優劣，按照什麼分得看使用者要求時候的切入點是什麼。按照使用者角色分到跟下面的類打交道的時候可能更清晰一些，按功能模組分可能當某部分除了問題查詢的時候更方便。同時用例的分析得細緻有度，也不能夠太細緻。
第二，包圖。
具體分了三層，ui層，bll層，dal層，實體層，每一層乙個包。前三層是前一層依賴後一層，他們三層跟實體層是關係關係，不是依賴關係（待查證）。同時實體層存放的不一定都是表。對於一些全域性變數等的資訊要建立乙個類，然後變數作為類的乙個屬性被呼叫，這些類一般放在實體層。所以一般實體層類的數目肯定是大於等於表的數目。
第三，包中的類圖。
一》，介面層無異議，都是乙個窗體乙個類。
二》，然後業務邏輯層，三種分法。一種是增刪改查算四個類就可以，但是這樣分類太粗了，不足以起到為窗體中的方法分類概括的作用。還有一種是按照表來分，因為這些窗體中的方法都是對不同的表進行的操作，這樣可以把所有窗體這些方法歸為對乙個表的操作為乙個類，但是這裡考慮到表可能會變動，所以為了體現少變動的原則，為了在表發生變動的時候這個類不要再新增對應的類，所以最好不要這樣分類。第三種就是每乙個窗體對應乙個類，畢竟這個層是為窗體層服務的，這樣分類才說得過去。
三》，之後是資料連線層，跟業務邏輯層一樣，我第一次分類就是按照增刪改查分了四個類，這樣當增加乙個表的時候這個表中的每乙個類都要發生變動，所以不可行。然後就是按照每乙個表建立乙個類與之對應比較可行，然後每乙個類有增刪改查方法。這樣可以起到為資料庫中的表服務的作用。
》四裡面可以放全域性變數等的其它類。
到這裡明白了為什麼每乙個層有這些類了。然後是聽完後明白了一些關於分類的新的東西。
一》首先說介面，其實每乙個i層跟層之間都可以由乙個介面的，然後呢可以乙個類對應乙個介面，也可以乙個層緊緊有乙個介面，同時還可以乙個層先有乙個介面，下面再每乙個類對應乙個介面，兩層介面是繼承和被繼承的關係。
二》，考慮到了介面，就要考慮用一些工廠模式等的設計模式了，這樣會更優化結構。
三》，考慮完了這些就是考慮到時序圖的時候，需不需要考慮把需要判斷的在建模的時候建立出來。答案應該是跟資料庫相關的判斷要畫出來，然後跟資料庫無關的在時序圖中就沒必要畫出來了。在活**等其他圖中體現出來就是了。
第四，類中的方法。
對於業務邏輯層中的方法具體該如何定。俗話說是有什麼操作就如何定方法，比如查詢學生資訊，那就乙個查詢方法。但是那如果說是上機，那算是什麼方法呢，所以我感覺應該是設計到對乙個表的乙個增刪改查這樣乙個操作了，那就算是有乙個方法了。（這裡注意，每乙個方法的後面應該註明傳遞的引數。）
對於下面資料連線層，是對錶的具體操作，自然就是每乙個類乙個增刪改查方法了。
資料表中類就是沒有方法，並且乙個屬性對應表的乙個欄位了。
以上就是到現在為止對建模的全部理解。然後在慢慢作圖過程中肯定還會有不同的分類方法，在具體實現過程中還會有更多的問題，以後遇到再說了。
三層 我眼中的三層結構
從行為型模式命令模式引發的對三層的思考。記得 大話設計模式 中對命令模式的講解。燒烤攤和燒烤店之間的區別。由於客戶和烤羊肉串老闆的 緊耦合 所以容易出錯，容易混亂，也容易挑剔。這其實就是 行為請求者 與 行為實現者 的緊耦合。對請求排隊或記錄請求日誌，以及支援可撤銷的操作等行為時，行為請求者 與 行...
成也三層，敗也三層
這重構版的機房的計畫早就開始，但開始的僅僅是計畫，卻遲遲沒有行動的意思，於是頻頻地徘徊著，迷茫著。這都過去三個星期了，每次的停滯不前我都有自己的理由，但是我應該從心底裡明白 成也三層，敗也三層 用三層對機房收費進行重構是乙個坎兒，這就是乙個對我們的的考驗，挺過去的就是通往下一站的乘客，沒過去應該就和...
三層架構 之三層擴充套件七層
哎，真心不想在這裡寫這篇部落格，本來三層到七層頂多了也就用兩天時間去分析，結果我用了將近四天，最後我都快崩潰了，還有好多問題都是同學幫我找出來的，真是很是汗顏吶！下面是我三層架構擴充套件成七層架構的uml包圖 之前看別人都是用的vb.net版，我就覺得剛學習了c 語言，就先用c 版吧，結果倒好，兩種...