軟件設計方案


軟件設計方案

用戶界面設計規范

用戶界面:又稱人機界面,實現用戶與計算機之間的通信,以控制計算機或進行用戶與計算機之間的數據傳送的系統部件。
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)保持字段名和類型的一致性,在命名字段並為其指定數據類型的時候一定要保證一致性。   


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM