ch7-軟件工程七章編碼設計2011209_第1頁
ch7-軟件工程七章編碼設計2011209_第2頁
ch7-軟件工程七章編碼設計2011209_第3頁
ch7-軟件工程七章編碼設計2011209_第4頁
ch7-軟件工程七章編碼設計2011209_第5頁
已閱讀5頁,還剩32頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

編碼設計(主講趙元哲)西安電子科技大學研究生院課程程序設計語言的選擇程序設計途徑與編寫程序的風格保護性編程冗余編程1程序設計語言的選擇

翻譯過程在編程步驟中,要把詳細設計的表達式翻譯成編程語言的構造,編譯器接受作為輸入的源代碼,源代碼生成作為輸出并從屬于機器的目標代碼(obj),然后編譯器把輸出目標代碼進一步翻譯成機器代碼(它是真正指令),由CPU執行。

程序設計的語言分類:基礎語言(BASIC,FORTRAN,COBOL,ALGOL)

結構語言(PL/1,PASCAL,C.ADA)

專用語言(FORTH,PROLOG,LISP)

系統實現語言(C)語言分類靜態高級語言(COBOL,FORTRAN)

動態高級語言塊結構高級語言(ALGOL,PASCAL)

可視化編程語言(VB,VC,PB,BC,C++BUILDER)

程序設計語言特點與特性

編程語言的特點命令式語言(c)、面向對象式語言(c++)、函數式語言(lisp)、邏輯型語言(prolog)心理學觀點在編程中,人的因素極其重要,所以,語言的心理學特性對代碼的翻譯和實現的設計都有重要影響。

1)一致性一致性是表示某種語言使用一致的符號、采用看似任意的限制以及支持語法或語義例外規則的程度。例如,FORTRAN用圓括號作數組下標的界限符,算術運算有限次序的修改符等,容易引起難以覺察的錯誤。

2)

多義性編程語言的多義性是程序員的理解。一般一條語句一個解釋。有時卻有多種解釋。

3)

緊湊性

緊湊性是一種面向代碼信息量的表示.度量緊湊性的語言屬性有:

(1)該語言支持結構化構造和邏輯“塊”的程度

(2)

所用的關鍵字和縮寫詞的種類

(3)

數據類型和缺省特性的品種

(4)

算術運算和邏輯運算的數量

4)

局域性編程語言的綜合特性,當語句可以組合為程序塊,結構化構造可以直接實現,設計代碼和合成代碼具有高的模塊性和聚合時,局域性就高.

5)

線性:一種心理特性.它與保持功能域的概念緊密聯系。即當遇到一個邏輯運算線性序列時,人容易理解;外延分支和外延大的循環都違反處理的線性,而結構化構造的直接實現有助于編程語言的線性。工程觀點以具體的軟件開發項目的需要為基礎,注意源代碼的工程特性:

(1)易于把設計翻譯為代碼;

(2)編譯器效率;

(3)源代碼可移植性:源代碼不修改或很小修改,直接搬到另一編譯器,環境變了,源碼不變;

(4)開發工具的可用性:許多編程語言有調試工具,

內部編輯,源碼控制,瀏覽器,宏處理器,反向工程工具和其他工具;

(5)可維護性:源碼必須可讀,并能根據設計的變化進行修改等。技術觀點數據結構的復雜性問題數據實時處理能力數據庫操作問題

選擇一種語言

因為一種語言不可能同時滿足各種需求,應該對各種需求(項目應用領域、軟件開發方法、執行環境等)進行權衡,比較各種可用語言的適用程度,選擇最適用的。

用于評價語言的準則:(1)一般的應用領域,(2)算法和計算的復雜性

(3)軟件運行環境

(4)性能考慮

(5)數據結構的復雜性

(6)軟件開發人員的知識

(7)好的編譯器或交叉編譯器的可使用性.

2程序設計途徑與編寫程序的風格

l程序設計方法論

方法論:

自上而下:程序可讀性好,可靠性高。

自下而上:局部優化:系統整體性差,但能及時發現算法是否可行,返工性好。二種方法各有優缺點:在軟件預研和攻關,技術積累時采用自下而上,在緊迫工程時,采用自上而下.

l程序設計自動化

三種途徑實現程序設計自動化l程序設計工具

1.編譯程序它是最基本的程序設計工具,它可以診斷出程序中的錯誤,減少開發成本,生成高效率的機器代碼

2.代碼管理系統l編碼風格編碼風格實際上是一種編碼原則,編碼對象是有兩個:

機器:編碼要為機器所理解與執行

人:能讀懂,方便使用與維護編碼風格最重要的有兩條:簡單和清晰。與編碼風格有關的因素:

代碼的文檔化、數據說明方法、語句構造處理、I/O技術。L代碼文檔化

代碼文檔化是從選擇標識符(變量、標號)的名字開始,接著是寫程序和安排注釋,最后是程序的整個視覺組織形式。所有的編程語言都允許用自然語言在程序中進行注釋,問題在于:

(1)多少注釋才算夠?

(2)

注釋應該放在什么位置?

(3)

注釋是否會使邏輯流不清楚?

(4)

注釋是否會使讀者誤解?

(5)

注釋是否會使程序不可維護?很難回答,但必須清楚:軟件必須包含代碼的內部說明,開發者可以用注釋的方法對代碼內部進行說明。L注釋(注釋范例):

①序言性注釋:應該安排在模塊的起始部分,內容有:

(1)說明每個模塊的用途,指明它的功能

(2)接口描述,包括:調用序列,每個參數的描述,以及所有從屬模塊清單。

(3)討論有關數據,包括:重要的變量和它們的用途、限制或約束條件,以及其他必要的信息。

(4)開發歷史,包括:模塊設計人姓名,評審人姓名及日期、修改說明及日期。②功能性注釋:

應嵌入在源代碼體內,描述處理功能。注釋基本原則是:注釋要解釋程序代碼,提供附加說明。此外,還應做到:

(1)

注釋是說明代碼塊,而不是注釋每一行代碼。(2)

使用空行或縮格,以易于區分注釋和代碼。

(3)

注釋一定要正確,以免引起錯誤,造成誤解。序言性注釋:功能性注釋:當使用PDL表示進行詳細設計時,設計文檔可以作為注釋直接嵌入在源代碼體內,十分有效,當修改設計或代碼時,確保設計和代碼都能維護。(1)數據說明的次序應規范化,可使數據屬性更容易尋找,有利于測試、糾錯和維護。

(2)當多個變量名在一條語句說明時,變量名的次序應按字母順序排列。

(3)如果設計中,確定了一個復雜的數據結構,就應該用注釋說明在編程語言實現時的特點。l語句構造

軟件邏輯構造是在設計時確定的,每個語句構造則是編碼步驟中的一部分。語句構造應當遵守的原則是:

每條語句應當簡單而直接,不應為了追求運行效率而使代碼變得復雜化,讓人難以理解。為了提高代碼的可讀性,最好一行只寫一條語句(因為許多編程語言允許一行寫多條語句)。還應采用縮排的方式,這樣可以使程序段的邏輯結構和功能特征更加清晰。單條源代碼(語句)的簡化方法如下:(1)避免使用復雜的條件測試。(2)排除測試條件的“非”。(3)避免多重循環嵌套或條件嵌套。(4)用括號的方法使邏輯表達式或算術表達式更加清晰。(5)用空格或可讀的符號使語句內容更加清晰。(6)只使用國家標準。(7)要想著,如果代碼不是我編寫的,我也能讀懂它。

總之,一句話:要力求直接了當,簡單明了。

l

I/O

I/O的風格不是在編碼時確定的,是在軟件需求分析和設計中確定的。但編碼時,I/O的實現方式決定了用戶對系統特征的可接受程度。不管軟件的性質是批處理,還是交互的,在設計和編碼時,都應考慮下述有關I/O風格原則:(1)檢查所有輸入數據的有效性。(2)檢查輸入項上的重要組合的合法性。(3)

保持簡單的輸入格式。(4)使用數據結束說明符,不應要求用戶規定輸入項目的數量。(5)用標記標明交互的輸入請求,應規定可以使用的選擇值或邊界值。(6)當編程語言對格式有嚴格的要求時,應保持輸入格式的一致性。(7)給所有輸出加標記,并設計所有輸出報告。l

效率

有三條準則應該指出的:(1)效率是一種性能要求。因此,應當在軟件需求時規定。軟件效率應按實際需要來要求,而不是越高越好。(2)

一個良好的設計可以提高效率。(3)

代碼效率與代碼的簡單性緊密聯系。

追求效率建立在不損害程序可靠性和可讀性基礎上!提高效率的根本途徑:設計方法、數據組織、算法,而非簡單的語句調整!l

代碼效率

源代碼的效率與詳細設計階段所確定的算法效率直接相關。但編碼風格也會影響運行速度和對內存的需要。一般可以使用以下準則:(1)在進行編碼以前,應簡化算術表達式和邏輯表達式。(2)要細心的評價嵌套循環,以確定能否把一些語句或表達式移到循環外邊。(3)

應盡量避免使用多維數組。(4)

應盡量避免使用指針和復雜的列表。(5)

采用快的算術運算。(6)

即使語言允許,也不要采用混合數據類型。(7)只要可能,應當采用整型算術表達式和布爾表達式。l

內存效率

內存限制大多已是過去的事了。低成本內存提供了大的物理地址空間,虛存管理為應用軟件提供了巨大的邏輯地址空間,對于這樣的環境,內存效率不等于使用最小內存。

內存效率必須注意考慮操作系統的分頁特征,代碼局域性或通過結構化構造功能域的管理是減少分頁和提高效率的最好辦法。盡管低成本、高密度內存芯片發展很快,但在嵌入式微處理器領域中,內存限制仍是一個非常實際非常重要的問題。如果系統需求(如高容量低成本產品)要求最小內存,必須非常細心的對高級語言的編譯程序進行估算,或作為最后的手段,也可以采用匯編語言。l

I/O效率當討論I/O效率時,有兩類I/O要考慮。(1)

由人支配的I/O。

(2)

取決于其他設備的(如磁盤或另一臺計算機)的I/O。提高I/O效率的簡單原則:(1)

I/O要求的數量應當減至最小。(2)所有I/O應當緩存,以減少過多的通信次數。(3)對于輔存(如磁盤),應當選擇和使用最簡單的可接受的存取方法。(4)輔存設備的I/O,應當是塊狀的。終端和打印機的

I/O,應當考慮設備的特性,以提高質量和速度。(5)要記住,如果超高效的I/O不能被人們所理解,那么這樣的I/O是沒有價值的。Defensiveprogrammingisaformofdefensivedesignintendedtoensurethecontinuingfunctionofapieceofsoftwareinspiteofunforeseeableusageofsaidsoftware.TheideacanbeviewedasreducingoreliminatingtheprospectofMurphy'sLawhavingeffect.Defensiveprogrammingtechniquesareusedespeciallywhenapieceofsoftwarecouldbemisusedmischievouslyorinadvertentlytocatastrophiceffect.Defensiveprogrammingisanapproachtoimprovesoftwareandsourcecode,intermsof:

Generalquality-Reducingthenumberofsoftwarebugsandproblems.

Makingthesourcecodecomprehensible-thesourcecodeshouldbereadableandunderstandablesoitisapprovedinacodeaudit.

Makingthesoftwarebehaveinapredictablemannerdespiteunexpectedinputsoruseractions.西方的“墨菲定律”(Murphy'sLaw)。“墨菲定律”是這樣說的:Anythingthatcangowrongwillgowrong.:“凡事只要有可能出錯,那就一定會出錯。”3保護性編程(defensiveprogramming)最常見的defensiveprogramming方法是加assertion(就是一種強制檢查),比如:

在訪問一個內存地址之前,先檢查指向那里的指針是否有效。在win32平臺上可以加入<assert.h>,然后就可以用assert(bool)這個函數。如果檢查出這里有錯,程序就會被中斷在這行語句處,同時在終端打印出文件名、行號、和assert的內容.對于認為編寫程序可以做到完全沒有錯誤的人來說,在軟件中建立檢查的意義不大。相反,對于相信軟件中總會有遺留錯誤的人來說,進行軟件內部的錯誤檢查則是一項重要策略,這種策略就是保護性編程。保護性編程技術可分為主動和被動兩種:

主動保護技術周期性的或在空閑時間對整個程序或數據庫進行搜索,用以發現異常情況。

被動保護技術是在到達檢查代碼時,對程序的某些部分進行檢查。反對保護性編程人員提出了許多逃避保護性編程的理由:(1)“我們的程序中即使有錯誤,也是很少的,所以不需要保護性編程。”(2)“要求采用他人的程序來檢查和發現我的程序錯誤,這是不公正的。”(3)“錯誤檢查降低了計算機系統的速度,而且還要求額外的內存。”(4)“錯誤檢查要占用很多編程時間。”(5)“可以在我的程序中加入錯誤檢查,不過一旦程序通過測試,就應把它撤去。”

對這些反對意見的回答,都直接或間接的與程序中預料的錯誤數及其潛在后果有關。

如果相信錯誤無所不在,即有相當數量的錯誤在晚期發現是不可避免的,就必須采用保護性編程。

如果這種保護在測試階段對我們有幫助,則肯定要在程序操作使用時繼續將其包括在內。

如果承認錯誤會出現這一事實,則比起因出現錯誤所帶來的責難來說,增加一些工作量是有意義的。

另一方面,基于運行時間、存儲空間和編程費用等方面的反對意見:僅當保護性編程要求設計增加的資源量相當大時需慎重考慮。事實上,只有在極少數情況下,保護性編程所要求增加的資源量才會相當大,以致不得不放棄考慮這種技術。

Yourdon曾提出過一個建設性意見:

在設計過程的早期就把保護性編程包括進去。在設計過程中,大多數設計在填充可用存儲空間時,其規模都增加的很快,如果企圖在設計過程的結尾再引入保護性編程,則肯定已沒有剩余空間。而且在近乎完成的設計中,移動任何部分擠出空間的任何做法,都會招致強烈的反對。但如果在一開始就把保護性編程包括進來,在希望增加新的保護性特征時,就能容易的避開設計中的討價還價。

另一個要考慮的重要事項是檢查哪些項目?盡管可以不受冗余編程概念的約束并檢查不合理的情況,如果企圖檢查所有項目,實質上是實現冗余編程。關于這個問題,Shooman建議設計人員先準備以下列表,以利于做出正確的判斷。

(1)可能需要檢查的項目表,應附有對編程時間、運行時間及存儲要求的開銷估計。

(2)各種類型錯誤出現的期望數據表,應標出每種類型錯誤可能造成的后果。研究這些信息有助于設計者確定應進行的檢查。保護性編程中的典型檢查項目(1)來自外部設備的輸入數據(范圍、屬性)。(2)由其他程序提供的數據。(3)數據庫(數組、文件、結構、記錄)。(4)操作員的輸入(性質、順序)。(5)棧的深度。(6)DOCASEI中的I范圍(并計算GOTO)。

(7)數組界限。(8)表達式中出現零分母的可能性。(9)所期望的程序版本是否在運行(最后系統重新組合的日期)。(10)通過其他程序或外部設備的輸出。

以上討論的所有保護技術都是被動式保護技術,因為必須等到某個輸入之后才能開始檢查。而主動式保護技術則既可在處理輸入信息期間使用,也可在系統空閑或等待下一次輸入時使用。

幾種應用主動式保護技術的例子。

(1)存儲器范圍檢查如果只在存儲器的某些塊中存放了某種類型和范圍的數據,則可經常檢查這些條件。

(2)標志驗證如果采用標志來指示系統的狀態,則可經常對它們作獨立的檢查。

(3)逆翻譯有時必須將數據或變量值從一種代碼或系統翻譯為另一種代碼或系統,可以利用反變換來檢查原始值的翻譯是否正確。(4)狀態驗證在多數情況下,復雜系統由多個操作狀態,它們可以采用某些特定的存儲值來表示。如果能夠獨立的驗證這些狀態,就可以進行檢查。

(5)連接檢查使用鏈表結構時,可以對其連接

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論