房間的改造基本完成。在中三比重建，被推翻後。七然後重建（外觀和工廠）。再重構，來來回回用了乙個月........
重構機房從繪圖畫到一半就廢棄了。由於對三層不熟。之後。做完了，才敢又一次拾起來畫。繪圖先從包圖開始。巨集觀上有個了解：
先前畫包圖的時候，跟師傅交流。結果被乙個師姐給笑話了，由於我覺得：它們各個層之間都是雙向箭頭的，後來才知道，箭頭表示呼叫關係，b層僅僅能被u層或外觀呼叫，b層不能呼叫u層，所以不存在雙向箭頭。大家注意。
在我這次重構中是嚴格依照上面的圖中來的。
對於ui呼叫外觀（facade）或者ui層呼叫bll層，都能夠：
ui呼叫外觀：client不知道b層的存在，減少了與b層的耦合。一旦使用者的需求有變動。僅僅改u層。加乙個b層就能夠了。
ui呼叫b層：有些功能非常單一的，事實上能夠直接ui層呼叫b層即可了。加上外觀反而認為有多此一舉了。
大家重構度數自己把握就能夠了。
關於用例圖，我認為有兩種分類的方法：
第一種：能夠依照功能來區分，功能依照大的能夠分為三類：查詢功能、維護功能、運算功能
另外一種：能夠依照角色來區分。角色能夠分為三類：一般使用者、操作員、管理員
依照功能來劃分舉個簡單的樣例：運算功能：
依照角色劃分：
在做第一次機房的時候，我們基本上就是依照角色來劃分的。
依照角色劃分：簡單直觀，乙個用例就是乙個介面。而且從總體上我們整個設計非常清晰，巨集觀上也非常easy接受。
依照功能劃分：b層是依照功能劃分的。這裡假設你是依照功能劃分的話，b層是非常easy就能夠做成的。可是一定要注意不要越纏越亂即可。
我是依照角色劃分的。
以充值為例：
這裡兩個icard和irecharge事實上是介面，為了與上面的七層的圖回應，就這樣畫了。
在類圖中我們不難看出u層是依照介面劃分的。乙個ui為乙個介面，外觀層和b層是依照功能劃分的，乙個介面可能有非常多個功能，有相應乙個外觀和多個b層，b層的功能要細化。外觀僅僅有乙個。乙個外觀呼叫多個b層。u層僅僅知道外觀不知道b層的細化功能。比方說充值（首先要推斷卡號是否存在，推斷充值金額是否低於最小金額，recharge表中加入資料。相應card表中cash欄位的改動。）。充值僅僅有乙個介面反應使用者的需求，外觀為乙個，可是b層會有幾個類分別為：查詢card表、查詢basicdata表、加入recharge表、改動card表。每個功能都是乙個b的類，這樣減少耦合。
關於外觀層，有幾種說法：
1、能夠依照用例分，乙個用例分為乙個外觀。有不同的返回值能夠通過不同的function來實現，不一定乙個外觀就僅僅有乙個function。
2、能夠依照使用者的級別來劃分，分別為：一般使用者、操作員、管理員，是誰的功能就調誰的外觀。
無論是哪一種，我認為都能夠。
這裡我想給大家提供幾條線供大家思考：
1、外觀用使用者級別劃分，幾個功能就有幾個function。用乙個function來呼叫b層的乙個類（依照功能劃分）。
2、外觀用使用者級別劃分，幾個功能就有幾個function。b層用表來劃分，跟idal層分類同樣，外觀中的function調b層的時候，可能要看清楚了。
3、外觀依照介面（用例）劃分，乙個外觀幾個function。b曾能夠用表來分，也能夠用功能劃分。
個人覺得前兩種更好一點，由於通知200個人和通知100個人沒有什麼差別，要是能實現通知10個人不就省了非常大的力氣了嗎？
我們劃分三層實際上就是解耦和，大家能巨集觀上不要脫離了這條主線就能夠了，如何做，給自己乙個說法，說的過去即可了。
房間計費系統改造 資料庫設計
曾記得。第一次編寫機房收費系統的文件模板，整整有12個文件須要編寫，只花了兩三天的時間就讓師傅驗收，完結專案。就這樣囫圇吞棗的文件編寫完畢了。要知道 欠下的賬，終究是要還的。如今到了機房收費系統個人版重構階段，1 進行資料抽象，設計區域性概念模型 2 將區域性概念模型綜合成全域性概念模型 3 就能夠...
關於新計費系統
首先新一代的計費系統需要使得實時通知 授權 推廣 運營商和客戶進行的 使用監控 以及其他實時活動均得到每天24小時，每週7天的支援。第二，新系統必須能夠提供乙個擁有選擇性 便捷性和控制權的新世界，以此增強客戶的忠誠度和增加來自每個使用者的平均收入 arpu 客戶越容易立即發現並定購它，他們就越有可能...
計費賬務系統介紹
對於乙個boss系統而言，計費賬務系統自然是乙個相當重要的組成部分，在整個boss系統中，最有別於別的行業的部分應該也就是計費賬務系統了，或者應該更強調的說是計費系統。一般來說，計費系統分為 採集 預處理 剃重 批價 詳單入庫 賬單入庫這幾個部分。採集系統負責從業務網元獲取各種業務的服務使用記錄，很...