軟體設計方案

標籤：

軟體設計方案

使用者介面設計規範

使用者介面：又稱人機介面，實現使用者與電腦之間的通訊，以控制電腦或進行使用者與電腦之間的資料傳送的系統組件。
GUI：即圖形化使用者介面，一種可視化的使用者介面，它使用圖形介面代替本文介面。
本系統堅持圖形化使用者介面（GUI）設計原則，介面直觀、對使用者透明。使用者接觸軟體後對介面上對應的功能一目瞭然、不需要多少培訓就可以方便地使用本應用系統。
1、介面設計介紹
介面設計是為了滿足軟體專業化標準化的需求而產生的對軟體的使用介面進行美化最佳化正常化的設計分支。
1）軟體啟動封面設計
應使軟體啟動封面最終為高清晰度的映像，選用的色彩不宜超過256色，大小多為主流顯示器解析度的1/6大。啟動封面上應該醒目地標註製作或支援的公司標誌、產品商標、軟體名稱、版本號碼、網址、著作權聲明、序號等資訊，以樹立軟體形象，方便使用者或購買者在軟體啟動的時候得到提示。插圖宜使用具有獨立著作權的、象徵性強的、識別性高的、視覺傳達效果好的圖形，若使用攝影也應該進行數位處理，以形成該軟體的個人化特徵。如果是系列軟體還將考慮整體設計的統一和延續性。
2）軟體架構設計
軟體的架構設計要複雜得多。軟體架構設計應該簡潔明快，盡量少用無謂的裝飾，應該考慮節省螢幕空間，各種解析度的大小，縮放時的狀態和原則，並且為將來設計的按鈕、菜單、標籤、捲軸及狀態列預留位置。設計中將整體色彩組合進行合理搭配，將軟體商標放在顯著位置，主菜單應放在左邊或上邊，捲軸放在右邊，狀態列放在下邊，以符合視覺流程和使用者使用心理。
3）軟體按鈕設計
軟體按鈕設計應該具有互動性，即應該有3到6種狀態效果：點擊前滑鼠未放在上面時的狀態；滑鼠放在上面但未點擊的狀態；點擊時狀態；點擊後滑鼠未放在上面時的狀態；不能點擊時狀態；獨立自動變化的狀態。按鈕應具備簡潔的圖示效果，名稱易懂，用詞準確，能望文知意最好，讓使用者產生功能關聯反應，群組內按鈕應該風格統一，功能差異大的按鈕應該有所區別。
4）軟體面板設計
軟體面板設計應該具有縮放功能，面板應該對功能區間劃分清晰，應該和對話方塊、彈出框等風格匹配，盡量節省空間的，切換方便。
5）菜單設計
菜單設計一般有選中狀態和未選中狀態，左邊應為名稱，右邊應為快速鍵。如果有下級菜單應該有下級箭頭符號，不同功能區間應該用線條分割。 對與進行的操作無關的菜單要用屏蔽的方式加以處理，如果採用動態載入方式，即只有需要的菜單才顯示最好。主菜單的寬度要接近，字數不應多於四個，每個菜單的字數能相同最好。 主菜單數目不應太多，最好為單排布置。
6）標籤設計
標籤設計應該注意轉角部分的變化，狀態可參考按鈕。
7）表徵圖設計
表徵圖設計色彩不宜超過64色，大小為16x16、32x32兩種，應該加以著重考慮視覺衝擊力，它需要在很小的範圍表現出軟體的內涵，在設計時使用簡單的顏色，利用眼睛對色彩和網點的空間混合效果，做出精彩表徵圖。
8）捲軸及狀態列設計
捲軸主要是為了對地區性空間的固定大小中內容量的變換進行設計，應該有上下箭頭，滾動標等，有些還有翻頁標。狀態列是為了對軟體目前狀態的顯示和提示。
9）安裝過程設計
安裝過程設計主要是將軟體安裝的過程進行美化，包括對軟體功能進行圖示化。
10）封裝及商品化
最後軟體產品的封裝應該考慮保護好軟體產品，功能的宣傳融合於美觀中，可以印刷部分產品介紹。
2、介面設計原則
1）易用性
（1）完成相同或相近功能的按鈕用Frame框起來，常用按鈕要支援捷徑；
（2）完成同一功能或任務的元素放在集中位置，減少滑鼠移動的距離；
（3）按功能將介面劃分局域塊，用Frame框括起來，並要有功能說明或標題；
（4）介面要支援鍵盤自動瀏覽按鈕功能，即按Tab鍵的自動切換功能；
（5）同一介面上的控制項數最好不要超過10個，多於10個時可以考慮使用分頁介面顯示；
（6）分頁介面要支援在頁面間的快捷切換，常用組合快速鍵Ctrl+Tab；
（7）預設按鈕要支援Enter及選操作，即按Enter後自動執行預設按鈕對應操作；
（8）可寫控制項檢測到非法輸入後應給出說明並能自動獲得焦點；
（9）Tab鍵的順序與控制項排列順序要一致，目前流行從上到下、從左至右的方式；
（10）複選框和選項框要有預設選項，按選擇機率的高低而先後排列，並支援Tab選擇；
（11）介面空間較小時使用下拉框而不用選項框；
（12）選項數較少時使用選項框，相反使用下拉式清單方塊；
（13）適當使用相關的專業術語，提倡使用通用性字眼。
2）規範性
通常介面設計都按Windows介面的規範來設計，即包含“菜單條、工具列、工具廂、狀態列、捲軸、右鍵捷徑功能表”的標準格式。小型軟體一般不提供工具廂。
（1）菜單前的表徵圖能直觀地代表要完成的操作，常用菜單要有命令捷徑 ；
（2）完成相同或相近功能的菜單用橫線隔開放在同一位置，菜單深度一般要求最多控制在三層以內；
（3）相同或相近功能的工具列放在一起，工具列中的每一個按鈕要有及時提示資訊；
（4）系統常用的工具列設定預設置放位置，工具列的表徵圖能直觀地代表要完成的操作，一條工具列的長度不能超出螢幕寬度；
（5）工具列太多時可以考慮使用工具廂； 工具廂要具有可增減性，由使用者自己根據需求定製，預設總寬度不要超過螢幕寬度的1/5；
（6）狀態條要能顯示使用者切實需要的資訊，常用的有：目前的操作、系統狀態、使用者位置、使用者資訊、提示資訊、錯誤資訊等，高度以放置五好字為宜；
（7）捲軸的長度要根據顯示資訊的長度或寬度能及時變換，以利於使用者瞭解顯示資訊的位置和百分比，並且寬度應比狀態條的略窄；
（8）菜單和工具條要有清楚的界限，菜單要求凸出顯示，這樣在移走工具條時仍有立體感；
（9）菜單和狀態條中通常使用五號字型。工具條一般比菜單要寬，但不要寬得太多，否則看起來很不協調；
（10）右鍵捷徑功能表採用與菜單相同的準則。
3）合理性
螢幕對角線相交的位置是使用者直視的地方，正上方四分之一處為易吸引使用者注意力的位置，在放置表單時要注意利用這兩個位置。
（1）父表單或主表單的中心位置應該在對角線焦點附近；
（2）子表單位置應該在主表單的左上方或正中，多個子表單彈出時應該依次向右下方位移，以顯示出表單標題為宜；
（3）重要的命令按鈕與使用較頻繁的按鈕要放在介面上注目的位置；
（4）與進行中的操作無關的按鈕應該加以屏蔽(Windows中用灰色顯示，沒法使用該按鈕) ；
（5）對可能造成資料無法恢複的操作必須提供確認資訊，給使用者放棄選擇的機會。
4）美觀與協調性
（1）按鈕大小基本相近，且與介面的大小、空間要協調，忌用太長的名稱；
（2）避免空曠的介面上放置很大的按鈕，放置完控制項後介面不應有很大的空缺位置；
（3）前景與背景色搭配合理協調，反差不宜太大，最好少用深色，常用色考慮使用Windows介面色調；
（4）介面風格要保持一致，字的大小、顏色、字型要相同，除非是需要藝術處理或有特殊要求的地方；
（5）如果表單支援最小化、最大化或放大時，表單上的控制項也要隨著表單而縮放；
（6）對於含有按鈕的介面一般不應該支援縮放，即右上方只有關閉功能；
（7）通常父表單支援縮放時，子表單沒有必要縮放。
5）介面一致性
在介面設計中應該保持介面的一致性。一致性既包括使用標準的控制項,也指使用相同的資訊表現方法，如在字型、標籤風格、顏色、術語、顯示錯誤資訊等方面確保一致。
（1）顯示資訊一致性
①標籤提示：字型為不加粗、宋體、黑色、灰底或透明、無邊框、靠右對齊、不帶冒號、一般情況為五號；
②日期：正常字型、宋體、白底黑字；
③對齊方法
靠左對齊：一般文字、單個數字、日期等
靠右對齊：數字、時間、日期加時間
④解析度800*600，增強色16色；
⑤字型預設為宋體、五號、黑色；
⑥底色預設為灰色。
這些資訊的排列顯示風格供參考, 在同一軟體中應當注意表現形式的一致性。
（2）布局合理化
應注意在一個視窗內部所有控制項的布局和資訊組織的藝術性，使得使用者介面美觀。布局不宜過於密集，也不能過於空曠，合理的利用空間。
在一個視窗中按tab鍵，移動順序不能雜亂無章，先從上至下，再從左至右。一屏中首先應輸入的和重要訊息的控制項在tab順序中應當靠前,並放在視窗上較醒目的位置。布局力求簡潔、有序、易於操作。
（3）滑鼠與鍵盤對應
應用中的功能只用鍵盤也應當可以完成，即設計的應用中還應加入一些必要的按鈕和功能表項目。但是，許多滑鼠的操作，如雙擊、拖動對象等，並不能簡單地用鍵盤來類比即可實現。例如在一個列表框中用按一下滑鼠其中一項表示選中該項內容，為了用鍵盤也能實現這一功能，必須在視窗中定義一個表示選中的按鈕，以作為實現單擊功能的替。又如在一個視窗中有兩個資料視窗，可以用滑鼠從一個資料視窗中將一項拖出然後放到另一個中，如果只用鍵盤，就應當在菜單中設定拷貝或移動的功能表項目。
（4）快速鍵
在功能表項目中使用快速鍵可以讓使用鍵盤的使用者操作得更快一些，在Windows及其應用軟體中快速鍵的使用大多是一致的。本系統中應用的快速鍵在各個配置項上語義必須保持一致。
Ctrl-O 開啟 Ctrl-Tab 下一視窗
Ctrl-S 儲存 Ctrl-Esc 工作清單
Ctrl-C 拷貝 Ctrl-F4 關閉視窗
Ctrl-V 粘貼 Alt-F4 結束應用
Ctrl-D 刪除 Alt-Tab 下一應用
Ctrl-X 剪下 Enter 預設按鈕/確認操作
Ctrl-I 插入 Esc 取消按鈕/取消操作
Ctrl-H 協助 Shift-F1 即時線上說明
Ctrl-P 列印
Ctrl-W 關閉
其它快速鍵
其它快速鍵使用漢語拼音的開頭字母，不常用的可以沒有快速鍵。
6）嚮導
對於應用中某些部分的處理流程是固定的，使用者必須按照指定的順序輸入操作資訊，為了使使用者操作得到必要的引示應該使用嚮導，使使用者使用功能時比較輕鬆明了，但是嚮導必須用在固定處理流程中，並且處理流程應該不少於3個處理步驟。
7）使用者協助
系統應該提供詳盡而可靠的協助文檔，在使用者使用產生迷惑時可以自己尋求解決方案。
常用的協助設施有兩種：整合的和附加的。整合的協助設施一開始就是設計在軟體中的，它與語境有關，使用者可以直接選擇與所要執行操作相關的主題。通過整合協助設施可以縮短使用者獲得協助的時間，增加介面的友好性，附加的協助設施在系統建好以後再加進去，通常是一種查詢能力比較弱的線上說明。
（1）協助文檔中的效能介紹與說明要和系統效能配套一致；
（2）操作時要提供及時調用系統協助的功能，常用F1；
（3）最好提供目前流行的線上說明格式或HTML協助格式；
（4）使用者可以用關鍵詞在協助索引中搜尋所要的協助，當然也應該提供說明主題詞；
（5）在協助中應該提供我們的支援人員方式，一旦使用者難以自己解決可以方便地尋求新的協助方式。
8）出錯資訊和警告
出錯資訊和警告是指出現問題時系統給出的壞訊息，資訊以使用者可以理解的術語描述。
（1）資訊應提供如何從錯誤中恢複的建設性意見；
（2）資訊應指出錯誤可能導致哪些不良後果，以便使用者檢查是否出現了這些情況並協助使用者進行改正；
（3）資訊應伴隨著視覺上的提示，如特殊的映像、顏色或者資訊閃爍；
（4）資訊不能帶有判斷色彩，即在任何情況下不能指責使用者。
9）一般互動
（1）一致性：菜單選擇、資料顯示以及其它功能都應使用一致的格式；
（2）提供有意義的反饋；
（3）在資料錄入上允許取消大多數操作；
（4）減少在動作間必須記憶的資訊數量；
（5）允許使用者非惡意錯誤，系統應保護自己不受致命錯誤的破壞。
10）資料輸入
（1）盡量減少使用者輸入動作的數量；
（2）維護資訊顯示和資料輸入的一致性；
（3）互動應該是靈活的，對鍵盤和滑鼠輸入的靈活性提供支援；
（4）在當前動作的語境中使不合適的命令不起作用。
11）獨特性
如果一味地遵循業界的介面標準，則會喪失自己的個性。在架構符合規範的情況下，設計具有自己獨特風格的介面尤為重要，在商業軟體流通中會有很好的潛移默化的廣告效用。安裝介面上應有單位介紹或產品介紹，並有自己的表徵圖。
編程規範總則
1、排版
1）程式塊要採用縮排風格編寫，縮排的空格數為4個，對於由開發工具自動產生的程式碼可以不一致；
2）相對獨立的程式塊之間、變數說明之後必須加空行；
3）較長的語句要分成多行書寫，長運算式要在低優先順序操作符處劃分新行，操作符放在新行之首，劃分出的新行要進行適當的縮排，使排版整齊，語句可讀；
4）迴圈、判斷等語句中若有較長的運算式或語句，則要進行適應的劃分，同3）；
5）若函數或過程中的參數較長，也要進行適當的劃分；
6）不允許把多個短語句寫在一行中，即一行唯寫一條語句；
7）if、for、do、while、case、switch、default等語句自佔一行，且if、for、do、while等語句的執行語句部分無論多少都要加括弧{}；
8）對齊只使用空格鍵，不使用TAB鍵；
9）函數或過程的開始、結構的定義及迴圈、判斷等語句中的代碼都要採用縮排風格，case語句下的處理語句也要遵從語句縮排要求；
10）程式塊的分界符（如大括弧‘{’和‘}’）應各獨佔一行並且位於同一列，同時與引用它們的語句靠左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case語句中的程式都要採用如上的縮排方式；
11）在兩個以上的關鍵字、變數、常量進行對等操作時，它們之間的操作符之前、之後或者前後要加空格，但不要連續留兩個以上空格。進行非對等操作時，如果是關係密切的操作符（如－>）後不應加空格。
採用這種鬆散方式編寫代碼的目的是使代碼更加清晰，在已經非常清晰的語句中沒有必要再留空格。如果語句已足夠清晰，則括弧內側(即左括弧後面和右括弧前面)不需要加空格，多重括弧間也不必加空格。 在長語句中，如果需要加的空格非常多，那麼應該保持整體清晰，而在局部不加空格。
（1）逗號、分號只在後面加空格。
int a, b, c;
（2）比較操作符、賦值操作符、算術操作符、邏輯操作符、位操作符等雙目操作符的前後加空格。
a = b + c;
a *= 2;
a = b ^ 2;
（3）"!"、"~"、"++"、"--"、"&"（地址運算子）等單目操作符前後不加空格。
flag = !isFull;
p = &com;
i++;
（4）"->"、"."前後不加空格。
（5）if、for、while、switch等與後面的括弧間應加空格，使if等關鍵字更為突出、明顯。
if (a >= b && c > d)
12）一行程式以小於80字元為宜，不要寫得過長。
2、注釋
注釋應該說明代碼的目的，要講清為什麼要那麼做，而不是怎麼去做。 1）一般情況下，來源程式有效注釋量必須在20％以上。注釋的原則是有助於對程式的閱讀理解，在該加的地方都加，注釋不宜太多也不能太少，注釋語言必須準確、易懂、簡潔；
2）注釋格式盡量統一，建議使用“/* …… */”；
3）說明性檔案（如標頭檔.h檔案、.inc檔案等）頭部應進行注釋，注釋必須列出：著作權說明、版本號碼、產生日期、作者、內容、功能、與其它檔案的關係等，標頭檔的注釋中還應有函數功能簡要說明；
4）源檔案頭部應進行注釋，列出：著作權說明、版本號碼、產生日期、作者、模組功能、主要函數及其功能等；
5）函數頭部應進行注釋，列出：函數功能、輸入參數、輸出參數、傳回值等；
6）邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性；
7）避免在注釋中使用縮寫，特別是非常用的縮寫。如無法避免，應對縮寫進行必要的說明；
8）注釋應與其描述的代碼相近，對代碼的注釋應放在其上方或右方（對單條語句的注釋）相鄰位置，如放於上方則需與其上面的代碼用空行隔開；
9）變數、常量、宏的注釋有時也是必須的，應放在其上方相鄰位置或右方；
10）資料結構聲明(包括數組、結構、類、枚舉等)，如果其命名不是充分自注釋的，必須加以注釋。對資料結構的注釋應放在其上方相鄰位置，對結構中的每個域的注釋放在此域的右方；
11）全域變數要有較詳細的注釋，包括對其功能、取值範圍、哪些函數或過程存取它以及存取時注意事項等的說明；
12）將注釋與其上面的代碼用空行隔開，注釋與所描述內容進行同樣的縮排；
13）對變數的定義和分支語句（條件分支、迴圈語句等）必須編寫注釋。這些語句往往是程式實現某一特定功能的關鍵，對於維護人員來說，良好的注釋協助更好地理解程式，有時甚至優於看設計文檔；
14）通過對函數或過程、變數、結構等正確的命名以及合理地組織代碼的結構，使代碼成為自注釋的，減少不必要的注釋；
15）當程式碼片段較長，特別是多重嵌套時，在程式塊的結束行右方加註釋標記，以表明某程式塊的結束；
16）建議注釋多使用中文，除非能用非常流利準確的英文表達。
3、標識符命名
1）標識符的命名要清晰明了，有明確含義，同時使用完整的單詞或大家基本可以理解的縮寫，避免使人產生誤解。較長的單詞可取單詞的頭幾個字母形成縮寫，一些單詞有大家公認的縮寫；
2）命名中若使用特殊約定或縮寫，應該在源檔案的開始之處，進行必要的注釋說明；
3）命名風格要自始至終保持一致；
4）對於變數命名，禁止取單個字元（如i、j、k...）。單個字元容易敲錯，且編譯時間又不易檢查出來。建議除了要有具體含義外，還能表明其變數類型、資料類型等，但i、j、k作局部迴圈變數是可以的；
5）命名規範必須與所使用的系統風格保持一致，並在同一項目中統一。除非必要，不要用數字或較奇怪的字元來定義標識符；
6）在同一軟體產品內，應規劃好介面部分標識符（變數、結構、函數及常量）的命名，防止編譯、連結時產生衝突；
7）用正確的反義片語命名具有互斥意義的變數或相反動作的函數等；
下面是一些在軟體中常用的反義片語：
add / remove begin / end create / destroy
insert / delete add / delete get / release
increment / decrement put / get
lock / unlock open / close first / last
min / max old / new start / stop
next / previous send / receive show / hide
source / target source / destination
cut / paste up / down
8）除了特殊應用，應避免使用以底線開始和結尾的定義。
4、可讀性
1）注意運算子的優先順序，並用括弧明確運算式的操作順序，避免使用預設優先順序；
2）避免使用不易理解的數字，用有意義的標識來替代；
3）來源程式中關係較為緊密的代碼應儘可能相鄰，便於程式閱讀和尋找；
4）不要使用難懂的技巧性很高的語句，除非很有必要時。程式的高效率並不等同於語句的高技巧，而在於演算法。
5、變數與結構
1）去掉沒必要的公開變數，以降低模組間的耦合度；
2）仔細定義並明確公開變數的含義、作用、取值範圍及公開變數間的關係；
3）明確公開變數與操作此公開變數的函數或過程的關係，如訪問、修改及建立等。這種關係的說明可在注釋或文檔中描述；
4）當向公開變數傳遞資料時，要十分小心，防止賦與不合理的值或越界等現象發生。若有必要應進行合法性檢查，以提高代碼的可靠性、穩定性；
5）構造僅有一個模組或函數可以修改、建立，而其餘有關模組或函數只訪問的公開變數，防止多個不同模組或函數都可以修改、建立同一公開變數的現象；
6）使用嚴格形式定義的、可移植的標準資料類型，盡量不要使用與具體硬體或軟體環境關係密切的變數；
7）結構的功能要單一，是針對一種事務的抽象。結構中的各元素應代表同一事務的不同側面，而不應把描述沒有關係或關係很弱的不同事務的元素放到同一結構中；
8）不同結構間的關係不要過於複雜，否則應合為一個結構；
9）仔細設計結構中元素的布局與排列順序，使結構容易理解、節省佔用空間，並減少引起誤用的現象；
10）結構的設計要盡量考慮向前相容和以後的版本升級，並為某些未來可能的應用保留餘地；
11）留心具體語言及編譯器處理不同資料類型的原則及有關細節；
12）編程時，要注意資料類型的強制轉換。對編譯系統預設的資料類型轉換要有充分的認識，盡量減少沒有必要的資料類型預設轉換與強制轉換，合理地設計資料並使用自訂資料類型，避免資料間進行不必要的類型轉換；
13）對自訂資料類型進行恰當命名，使它成為自描述性的，以提高代碼可讀性，但要注意其命名方式在同一產品中的統一。
6、函數與過程
1）設計高扇入、合理扇出（小於7）的函數。較良好的軟體結構通常是頂層函數的扇出較高，中層函數的扇出較少，而底層函數則扇入到公用模組中；
2）函數的規模盡量限制在200行以內，不包括注釋和空格行；
3）對所調用函數的錯誤返回碼要仔細、全面地處理；
4）在同一項目組應明確規定對介面函數參數的合法性檢查應由函數的調用者負責還是由介面函數本身負責，預設是由函數調用者負責；
5）防止將函數的參數作為工作變數。對必須改變的參數，最好先用局部變數代之，再將該局部變數的內容賦給該參數；
6）一個函數僅完成一件功能，不要設計多用途的函數。函數名應準確描述函數的功能；
7）函數的功能應該是可以預測的，也就是說只要輸入資料相同就應產生同樣的輸出；
8）避免設計多參數函數，不使用的參數從介面中去掉，減少函數間介面的複雜度；
9）非調度函數應減少或防止控制參數，盡量只使用資料參數，防止函數間的控制耦合；
10）檢查函數所有參數輸入與非參數輸入的有效性；
11）在編程時，經常遇到在不同函數中使用相同的代碼，許多開發人員都願把這些代碼提出來，並構成一個新函數。若這些代碼關聯較大並且是完成一個功能的，那麼這種構造是合理的，否則這種構造將產生隨機內聚的函數；
12）功能不明確且較小的函數，特別是僅有一個上級函數調用它時，應考慮把它合并到上級函數中，而不必單獨存在；
13）減少函數本身或函數間的遞迴調用。除非為某些演算法或功能的實現方便，應減少沒必要的遞迴調用；
14）仔細分析模組的功能及效能需求，並進一步細分，若有必要畫出有關資料流圖，據此來進行模組的函數劃分與組織；
15）對於提供了傳回值的函數，在引用時最好使用其傳回值；
16）當一個過程（函數）中對較長變數（一般是結構的成員）有較多引用時，可以用一個意義相當的宏代替。
7、可測性
1）在同一項目組或產品組內，要有一套統一的為整合測試與系統聯調準備的調測開關及相應列印函數，並且要有詳細的說明；
2）在同一項目組或產品組內，調測列印出的資訊串的格式要有統一的形式。資訊串中至少要有所在模組名（或源檔案名稱）及行號；
3）編程的同時要為單元測試選擇恰當的測試點，並仔細構造測試代碼、測試案例，同時給出明確的注釋說明。測試代碼部分應作為（模組中的）一個子模組，以方便測試代碼在模組中的安裝與拆卸（通過調測開關）；
4）使用斷言來發現軟體問題，提高代碼可測性。用斷言來檢查程式正常運行時不應發生但在調測時有可能發生的非法情況，但不能用斷言來檢查最終產品肯定會出現且必須處理的錯誤情況；
5）對較複雜的斷言加上明確的注釋，用斷言確認函數的參數，保證沒有定義的特性或功能不被使用，對程式開發環境的假設進行檢查；
6）正式軟體產品中應把斷言及其它調測代碼去掉（即把有關的調測開關關掉），以加快軟體運行速度；
7）在軟體系統中設定與取消有關測試手段，不能對軟體實現的功能等產生影響；
8）用調測開關來切換軟體的DEBUG版和正式版，而不要同時存在正式版本和DEBUG版本的不同源檔案，以減少維護的難度；
9）軟體的DEBUG版本和發行版本應該統一維護，不允許分家，並且要時刻注意保證兩個版本在實現功能上的一致性；
10）在編寫代碼之前，應預先設計好程式調試與測試的方法和手段，並設計好各種調測開關及相應測試代碼如列印函數等；
11）調測開關應分為不同層級和類型。針對模組或系統某部分代碼的調測，針對模組或系統某功能的調測，對效能、容量等的測試；
12）編寫防錯程式，然後在處理錯誤之後可用斷言宣布發生錯誤。
8、程式效率
1）在保證軟體系統的正確性、穩定性、可讀性及可測性的前提下提高代碼效率，包括全域效率、局部效率、時間效率及空間效率；
2）局部效率應為全域效率服務，不能因為提高局部效率而對全域效率造成影響；
3）通過對系統資料結構的劃分與組織的改進，以及對程式演算法的最佳化來提高空間效率；
4）仔細考慮迴圈體內的語句是否可以放在迴圈體之外，使迴圈體內工作量最小，從而提高程式的時間效率；
5）仔細考查、分析系統及模組處理輸入（如事務、訊息等）的方式，並加以改進；
6）對模組中函數的劃分及組織方式進行分析、最佳化，改進模組中函數的組織圖，提高程式效率；
7）不應花過多的時間拚命地提高調用不很頻繁的函數代碼的效率；
8）仔細地構造或直接用彙編編寫調用頻繁或效能要求極高的函數。嵌入彙編可提高時間及空間效率，但也存在一定風險；
9）在保證程式品質的前提下，通過壓縮代碼量、去掉不必要代碼以及減少不必要的局部和全域變數，來提高空間效率；
10）盡量減少迴圈嵌套層次。在多重迴圈中，應將最忙的迴圈放在最內層，以減少CPU切入迴圈層的次數；
11）避免迴圈體內含判斷語句，應將迴圈語句置於判斷語句的代碼塊之中；
12）盡量用乘法或其它方法代替除法，特別是浮點運算中的除法；
13）不要一味地追求緊湊的代碼，因為緊湊的代碼並不代表高效的機器碼。
9、品質保證
1）在軟體設計過程中構築軟體品質；
2）代碼品質保證優先原則
（1）正確性，指程式要實現設計要求的功能；
（2）穩定性/安全性，指程式穩定、可靠、安全；
（3）可測試性，指程式要具有良好的可測試性；
（4）規範/可讀性，指程式書寫風格、命名規則等要符合規範；
（5）全域效率，指軟體系統的整體效率；
（6）局部效率，指某個模組、子模組、函數的本身效率；
（7）個人表達方式，指個人編程習慣。
3）只引用屬於自己的存貯空間；
4）防止引用已經釋放的記憶體空間；
5）過程/函數中分配的記憶體，在過程/函數退出之前要釋放；
6）過程/函數中申請的（為開啟檔案而使用的）檔案控制代碼，在過程/函數退出之前要關閉；
7）防止記憶體操作越界；
8）認真處理常式所能遇到的各種出錯情況；
9）系統運行之初，要初始化有關變數及運行環境，防止未經初始化的變數被引用，並對載入到系統中的資料進行一致性檢查；
10）嚴禁隨意更改其它模組或系統（不屬於自己）的有關設定和配置，不能隨意改變與其它模組的介面；
11）注意易混淆的操作符。當編完程式後，應從頭至尾檢查一遍這些操作符，以防止拼字錯誤；
12）有可能的話，if語句盡量加上else分支，對沒有else分支的語句要小心對待。switch語句必須有default分支；
13）不使用與硬體或作業系統關係很大的語句，而使用建議的標準語句，以提高軟體的可移植性和可重用性；
14）精心構造演算法，並對其效能、效率進行測試，對較關鍵的演算法最好使用其它演算法來確認；
15）注意運算式是否會上溢、下溢，使用變數時要注意其邊界值；
16）系統應具有一定的容錯能力，對一些錯誤事件（如使用者誤操作等）能進行自動補救；
17）對一些具有危險性的作業碼要仔細考慮，防止對資料、硬體等的安全構成危害，以提高系統的安全性。
10、代碼編輯、編譯與審查
1）同產品軟體（項目組）內，最好使用相同的編輯器，並使用相同的設定選項；
2）開啟編譯器的所有警示開關對程式進行編譯；
3）通過代碼走讀及審查方式對代碼進行檢查；
4）編寫代碼時要注意隨時儲存，並定期備份，防止由於斷電、硬碟損壞等原因造成代碼丟失；
5）某些語句經編譯後產生警示，如果你認為它是正確的，那麼應通過某種手段去掉警示資訊；
6）使用代碼檢查工具對來源程式檢查，使用軟體工具進行代碼審查。
11、代碼測試與維護
1）單元測試要求至少達到語句覆蓋；
2）整理或最佳化後的代碼要經過審查及測試；
3）代碼版本升級要經過嚴格測試；
4）使用工具軟體對代碼版本進行維護；
5）正式版本上軟體的任何修改都應有詳細的文檔記錄；
6）發現錯誤立即修改，並且要記錄下來；
7）關鍵的代碼在彙編級跟蹤；
8）仔細設計並分析測試案例，使測試案例覆蓋儘可能多的情況，以提高測試案例的效率；
9）儘可能類比出程式的各種出錯情況，對出錯處理代碼進行充分的測試；
10）仔細測試代碼處理資料、變數的邊界情況；
11）保留測試資訊，以便分析、總結經驗及進行更充分的測試；
12）不應通過“試”來解決問題，應尋找問題的根本原因；
13）對自動消失的錯誤進行分析，搞清楚錯誤是如何消失的；
14）測試時應設法使很少發生的事件經常發生；
15）明確模組或函數處理哪些事件，並使它們經常發生；
16）堅持在編碼階段就對代碼進行徹底的單元測試，不要等以後的測試工作來發現問題；
17）去除代碼啟動並執行隨機性，讓函數啟動並執行結果可預測，並使出現的錯誤可再現。


資料庫設計原則
資料庫技術是資訊資源管理最有效手段。資料庫設計是建立資料庫及其應用系統的核心和基礎，它要求對於指定的應用環境，構造出較優的資料庫模式，建立起資料庫應用系統，並使系統能有效地儲存資料，滿足使用者的各種應用需求。
1、設計資料庫之前
1）理解客戶需求，詢問使用者如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶以保證其需求仍然在開發的目的之中；
2）瞭解企業業務，在以後的開發階段節約大量時間；
3）重視輸入輸出。在定義資料庫表和欄位需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出），以決定為了支援這些輸出哪些是必要的表和欄位；
4）建立資料字典和E-R 圖，對SQL 運算式的文檔化來說這是完全必要的；
5）定義標準的對象命名規範。
2、表與欄位的設計
　　
1）表設計原則
（1）標準化和正常化；
資料的標準化有助於消除資料庫中的資料冗餘。標準化有好幾種形式，但Third Normal Form（3NF）通常被認為在效能、擴充性和資料完整性方面達到了最好平衡。事實上，為了效率的緣故，對錶不進行標準化有時也是必要的。
（2）採用資料驅動，增強系統的靈活性與擴充性；
（3）在設計資料庫的時候考慮到哪些資料欄位將來可能會發生變更。
2）欄位設計原則
（1）每個表中都應該添加的3 個有用的欄位；
①dRecordCreationDate，在SQL Server 下預設為GETDATE()；
②sRecordCreator，在SQL Server 下預設為NOT NULL
DEFAULT USER；
③nRecordVersion，記錄的版本戳記，有助於準確說明記錄中出現null 資料或者遺失資料的原因。
（2）對地址和電話採用多個欄位，電話號碼和郵件地址最好擁有自己的資料表，其間具有自身的類型和標記類別；
（3）使用角色實體定義屬於某類別的列，建立特定的時間關聯關係，從而可以實現自我文檔化；
（4）選擇數字類型和文本類型要盡量充足，否則無法進行計算操作；
（5）增加刪除標記欄位。在關聯式資料庫裡不要單獨刪除某一行，而在表中包含一個“刪除標記”欄位，這樣就可以把行標記為刪除。
3、鍵和索引
1）鍵選擇原則
（1）鍵設計4 原則
①所有的鍵都必須唯一；
②為關聯欄位建立外鍵；
③避免使用複合鍵；
④外鍵總是關聯唯一的鍵欄位。
（2）使用系統產生的主鍵，控制資料庫的索引完整性，並且當擁有一致的鍵結構時，找到邏輯缺陷很容易；
（3）不要用使用者的鍵，通常情況下不要選擇使用者可編輯的欄位作為鍵；
（4）可選鍵有時可作主鍵，能擁有建立強大索引的能力。
2）索引使用原則
索引是從資料庫中擷取資料的最高效方式之一，絕大多數的資料庫效能問題都可以採用索引技術得到解決。
（1）邏輯主鍵使用唯一的成組索引，對系統鍵（作為預存程序）採用唯一的非成組索引，對任何外鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用於讀寫；
（2）大多數資料庫都索引自動建立的主鍵欄位，但是不能忘了索引外鍵，它們也是經常使用的鍵；
（3）不要索引memo/note 欄位，不要索引大型欄位，這樣會讓索引佔用太多的儲存空間；
（4）不要索引常用的小型表，不要為小型資料表設定任何鍵，尤其當它們經常有插入和刪除操作時。
4、資料完整性設計　　
1）完整性實現機制
（1）實體完整性：主鍵
（2）參照完整性
①父表中刪除資料：串聯刪除，受限刪除，置空值；
　 ②父表中插入資料：受限插入，遞迴插入；
　 ③父表中更新資料：串聯更新，受限更新，置空值。
DBMS對參照完整性可以有兩種方法實現：外鍵實現機制（約束規則）和觸發器實現機制。
（3）使用者定義完整性：NOT NULL，CHECK，觸發器。
2）用約束而非商務規則強制資料完整性；
3）強制指示完整性。在有害資料進入資料庫之前將其剔除，啟用資料庫系統的指示完整性特性；　　
4）使用尋找控制資料完整性，控制資料完整性的最佳方式就是限制使用者的選擇；　　
5）採用視圖。可以為應用程式建立專門的視圖而不必非要應用程式直接存取資料表，這樣做還等於在處理資料庫變更時給你提供了更多的自由。
5、其他設計
1）避免使用觸發器，確實需要的話最好集中對它文檔化；
2）使用常用英語（或者其他任何語言）而不要使用編碼，確實需要的話可以在編碼旁附上使用者知道的英語；
3）儲存常用資訊。讓一個表專門存放一般資料庫資訊，可以實現一種簡單機制追蹤資料庫，這樣做對非客戶機/伺服器環境特別有用；
4）包含版本機制，在修改資料庫結構時更為方便；　　
5）編製文檔，對所有的捷徑、命名規範、限制和函數都要編製文檔；
6）反覆測試，保證選擇的資料類型滿足商業要求；　　
7）檢查設計，在開發期間檢查資料庫設計的常用技術是通過其所支援的應用程式原型檢查資料庫。
6、資料庫命名規範
1）實體（表）的命名
（1）表以名詞或名詞短語命名，給表的別名定義簡單規則；　　
（2）如果表或者是欄位的名稱僅有一個單詞，那麼建議不使用縮寫，而是用完整的單詞；
（3）所有的儲存值列表的表前面加上首碼Z，目的是將這些值列表類排序在資料庫最後；
（4）所有的冗餘類的命名(主要是累計表)前面加上首碼X。冗餘類是為了提高資料庫效率，非正常化資料庫的時候加入的欄位或者表；
（5）關聯類別通過用底線串連兩個基本類之後，再加首碼R的方式命名，後面按照字母順序羅列兩個表名或者表名的縮寫。關聯表用於儲存多對多關係。
2）屬性（列）的命名
（1）採用有意義的列名，表內的列要針對鍵採用一整套設計規則；
每一個表都將有一個自動ID作為主健，邏輯上的主健作為第一組候選主健來定義。如果是自訂的邏輯上的編碼則用縮寫加“ID”的方法命名。如果鍵是數字類型，你可以用_NO 作為尾碼。如果是字元類型則可以採用_CODE 尾碼。對列名應該採用標準的首碼和尾碼。
（2）所有的屬性加上有關類型的尾碼，如果還需要其它的尾碼，都放在類型尾碼之前。資料類型是文本的欄位，類型尾碼TX可以不寫，有些類型比較明顯的欄位也可以不寫類型尾碼；
（3）採用首碼命名。給每個表的列名都採用統一的首碼，那麼在編寫SQL運算式的時候會得到大大的簡化，但這樣做也有缺點，比如會破壞自動表串連工具的作用。
3）視圖的命名
（1）視圖以V作為首碼，其他命名規則和表的命名類似；
（2）命名應盡量體現各視圖的功能。
4）觸發器的命名
觸發器以TR作為首碼，觸發器名為相應的表名加上尾碼，Insert觸發器加 _I ，Delete觸發器加 _D ，Update觸發器加 _U 。如：TR_User_I，TR_User_D，TR_User_U。
5）預存程序名
預存程序應以 UP_ 開頭，和系統的預存程序區分，後續部分主要以動賓形式構成，並用底線分割各個組成部分。　　
6）變數名
變數名採用小寫，若屬於片語形式，用底線分隔每個單詞。
7）命名中其他注意事項
（1）以上命名都不得超過30個字元的系統限制，變數名的長度限制為29（不包括標識字元@）；
（2）資料對象、變數的命名都採用英文字元，禁止使用中文命名，絕對不要在對象名的字元之間留空格；
（3）小心保留詞，要保證你的欄位名沒有和保留詞、資料庫系統或者常用存取方法衝突；
（4）保持欄位名和類型的一致性，在命名欄位並為其指定資料類型的時候一定要保證一致性。 　　

軟體設計方案