建模知識在實際設計中的應用（下）
本篇主要嘮嘮建模知識在日常工作、實際設計中的應用。
以下為上篇總結，補充在此；
角色矩陣、系統主流程以及狀態圖，三者之間相互補充與制衡，最終達到完美的統一；
狀態圖梳理後調整補充系統主流程，系統主流程調整後調整補充角色矩陣；
同樣，角色矩陣也限制、指導著系統的主要功能，防止在梳理需求時被無限放大；
相關閱讀：
一、原型線框圖
在角色矩陣、系統主流程和狀態圖達到統一後，接下來就來到原型設計的階段，此階段的主要目的是把每個實體的屬性以及實體之間的聯絡，以我們日常可見、理解的方式呈現；
1.1 模組劃分
基礎模組的劃分遵循實體的界限，一般來說，一個實體就是一個基礎模組，通常模組首頁以列表形式展示；如普通的電商後臺系統，即使用者、商品、訂單這些基礎模組，這些其實也是實體；
統計，關聯類，根據實際需求定義模組，通常以圖表、列表形式展示；
1.2 站點地圖
系統涉及到的頁面以及頁面之間的流轉以地圖索引的方式展示；一般以模組劃分，如系統功能較簡單，可以系統為單位。
1.3 頁面資訊架構
即頁面呈現的資訊，從建模角度來看，其實就是實體屬性以及實體之間聯絡的展示；
實體屬性，即實體的基本屬性，比如員工有員工號、姓名、身份證號、職位、性別、郵箱等基本屬性；實體之間的聯絡，即該實體與其他實體之前的聯絡，如我們在上篇中寫到的部門-人員的關係；
1:1，
當實體之間為1：1的聯絡時，當前實體的頁面展示可以
將對面實體以其屬性的形式展示
；如某公司業務支撐部，經理張三，在員工基本資訊頁，職位：部門經理，部門：業務支撐部；在部門基本資訊檢視時，部門：業務支撐部，部門經理：張三；
1：N，
當實體之間為1：N的聯絡時，為“1”的實體頁面資訊展示時，可以將對面的“N”
以下級頁面或列表的形式展示
；為“N”的實體頁面資訊展示時，可以將對面的“1”
以其屬性的形式展示
；如業務支撐部下屬員工有2個，分別是小麗、小黃，檢視業務部資訊時，可以設定“下屬員工”連結到下級頁面，也可以以列表的形式展示這2個員工資訊。同理，在員工基本資訊頁面時，可以將該員工的所在/所屬部門以其基本屬性展示；
N：N，
當實體之間為N：N的聯絡時，對面實體
以下級頁面或列表的形式展示；
如學生-課程，在學生模組，可以將所選課程以下級頁面的形式展示，也可以以列表的形式展示；同理在課程模組，該課程被哪些學生選修，可以以下級頁面展示，也可以以列表的形式展示；
二、設計原則
2.1 始終把“使用者+需求”放在第一位
使用者：
即該系統的終端使用者，可遵循我們在上兩篇中講到的角色實體；
需求：
即功能，使用者透過系統想要達到的目的；
使用者+需求：
即考慮該功能的實際應用場景，根據實際場景把控設計的方向；
實際場景應考慮的因素如下，持續補充：
使用者年齡大小，這直接影響到視覺上的配色、字型、字號等；
使用者整體素質水平，在流程跳轉、提示等節點儘量簡潔易懂；
使用者所處環境，使用者是處在比較莊嚴的機關單位還是新潮的網際網路行業，都有一套行業規則；
功能使用週期、頻率；這直接影響到表結構的設計，在大頻率的功能上，訪問速度是需要著重考慮的問題；
2.2 遵循“高內聚，低耦合”的設計原則
這應該是我從大學，老師就一直強調的，就像一項指明燈指引我們前進；你會發現，所有不好用的設計邏輯，都會忽略這個原則。
官方解釋：
高內聚：
又稱塊內聯絡。指模組的功能強度的度量，即一個模組內部各個元素彼此結合的緊密程度的度量。若一個模組內各元素（語名之間、程式段之間）聯絡的越緊密，則它的內聚性就越高。
低耦合：
一個完整的系統，模組與模組之間，儘可能的使其獨立存在。也就是說，讓每個模組，儘可能的獨立完成某個特定的子功能。模組與模組之間的介面，儘量的少而簡單。
官方給出的解釋中，主要是針對模組之間，
實際上，這個結論對大至平臺，小至實體都是適應；
下面舉個關於實體之間的栗子：我之前接過的一個專案，其中有一條這樣的邏輯“一個經銷商下最多3個聯絡人”；這時我們會疑問，為啥會有這種設定， 這樣的規則在後續會產生哪些問題呢：
當經銷商下聯絡人超過3個時，系統是不支援的；
系統是由簡到繁的過程，一開始設定這樣的限制，如果後面想在撤銷這種設定的話會涉及很多改動；
實體之間不夠獨立且依賴太多，所以這不遵循高內聚低耦合的原則
； 其實這就是簡單的1：N的關係，只是在某些特定方式下，如匯入經銷商及其聯絡人的時候，這時我們可以設定這個聯絡人最多是3個，但是，在系統的使用中，這種關係反而是一種負擔；
2.3 遵循“複用性”原則，所有設計力求複用最最佳化
官方解釋：
可複用性
，複用又叫重用，是重複使用的意思。複用的好處可以得到 較高的生產效率以及隨之而來的成本降低、較高的軟體質量（錯誤可以更快的被糾正）以及 恰當的使用複用可以改善系統的可維護性。
模組之間的複用，
即實體的複用，當實體之間是N：N的關係時，一定會存在這樣的複用關係；如果不存在，那這個設計可能沒有達到複用最最佳化的標準；
如我們常見的元件與商品的關係，是N：N，在商品新建時會以屬性的方式增加元件；
這樣做的好處是：
元件不需要重複新建，直接在商品新增時引用加入即可；
可對元件進行管理、控制；
如果我們換一種設計思維，如新建商品時，一個個編輯填寫元件資訊，這樣做會帶來
如不同商品的元件資訊相同時，要重複錄入；
元件是以屬性的方式附屬在商品上，達不到元件可控可管的需求；
階梯性關聯關係的設計
，即多個實體之間有階梯性關聯關係，建議採用斷層式資料結構設計，不建議跨級發生聯絡，即使需要跨級也要把中間那層關係加上；
為了便於理解，以下例項奉上。
背景：專案-經銷商是N：N的關係，經銷商-聯絡人是1：N的關係；
需求1：當專案新增成功後，會根據一定條件匹配經銷商，確認此專案可能推送的經銷商，或者叫預推送；此時的預推送表結構的設計應該是專案-經銷商，而不是專案-聯絡人或專案-經銷商-聯絡人；這樣設計的好處有，
我們只固定了前半邊的關係，後面的關係可以透過經銷商來匹配帶出，當經銷商人員發生變更時也不會有任何影響；如果採用其他方式，在經銷商人員變更時會多出很多複雜的資料操作，以保證此功能不受影響；
經銷商-聯絡人是1：N的關係，插入一條專案-經銷商關係就要插入多條專案-聯絡人或專案-經銷商-聯絡人的關係，從資料的冗餘角度考慮，也是專案-經銷商的關係比較適合；
需求2：專案推送，專案預推送匹配成功後，可以對專案進行推送，這是真正的推送，有了這條推送，聯絡人才能在前端看到對應的專案；而此時的設計應該是如何呢
答案是，專案-經銷商-聯絡人；為什麼會加入“經銷商”呢？前面的背景也說到，專案與聯絡人其實是沒有這種關係的，他們產生關係的載體其實就是“經銷商”；這樣做的好處是
明確該聯絡人時透過什麼載體（即經銷商）來獲得這從推送關係的，當聯絡人與載體的關係發生變更時，有個依據來對關聯資料進行相關操作；如聯絡人從載體A變更到B，那此時，聯絡人當時透過A獲得的專案推送關係就應該刪除；
相反的，如果不加入“經銷商”的載體，那聯絡人可見的專案是隻增不減，因為我們沒有這個載體的依據去操作資料；
注：一切實際需求為標準，僅供參考；
三、日常設計要點
3.1 保持對需求的嚴謹態度
雖然需求多如牛毛，產品累成狗（微笑），但我們也要始終保持一顆嚴謹、謙遜的態度；做軟體的都知道，即使是一個很小的需求，他的改動有時也不一定比一個大的需求少；所以，在需求被提出時，我們要保證我們已經瞭解到該需求的所有細節，以及涉及到的所有改動點；
3.2 儘量囊括所有擴充套件場景
好的產品，流程極簡且不容易發生異常
；為什麼說不容易呢，因為即使是神，也有考慮不周的地方，所以在設計時，應儘量囊括所有場景。
（1）外部條件導致的異常如斷網、服務掛掉等，應給出合適的提示資訊；
（2）另外還有一種，即在常規流程外的分支流程，這個是特別需要我們注意且控制的。
重複提交：
提交按鈕沒有控制可用狀態&&頁面流程較慢的情況下會出現多次重複提交的現象，一般前端+後臺，雙重控制，杜絕重讀提交；
流程異常，無法繼續走下去：
充分考慮擴充套件場景，避免出現操作異常，即使異常，也應給出相關提示，指導使用者繼續走下去。
3.3 模組關聯性，版本規劃
模組、需求，都有可能產生關聯，有前後的這種關係，這種情況應該考慮先規劃前置位的模組或功能，然後再是後置位；版本的規劃，
以系統核心模組為基礎，遵從“關聯性模組中的前置模組，優先順序高於後置模組”的規則
，來規劃版本；
3.4 其他
（1）唯一性校驗，當實體有唯一性要求時，如使用者的手機號碼，身份證號等，在實體新增、修改時，校驗是否已存在、保證唯一性；
（2）關聯性關係，當刪除父節點時，子節點也會對應刪除或軟刪除；
（3）在對實體進行變更時，應首先以使用者的角色看問題；如已經發出去的優惠券，此時應設定不可再進行變更，因為發生變更後，使用者看到的將是更改後的優惠券；
