1.7.3面向?qū)ο笤O(shè)計方法
面向?qū)ο蟮念愒O(shè)計相關(guān)原則:
1. 開閉原則(the Open Closed Principle OCP)
一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。因此在進行面向?qū)ο笤O(shè)計時要盡量考慮接口封裝機制、抽象機制和多態(tài)技術(shù)。該原則同樣適合于非面向?qū)ο笤O(shè)計的方法,是軟件工程設(shè)計方法的重要原則之一。
2. 替換原則 (the Liskov Substitution Principle LSP)
子類應當可以替換父類并出現(xiàn)在父類能夠出現(xiàn)的任何地方。這個原則是Liskov于1987年提出的設(shè)計原則。它同樣可以從Bertrand Meyer 的DBC (Design by Contract) 的概念推出。
3. 依賴原則 (the Dependency Inversion Principle DIP)
在進行業(yè)務設(shè)計時,與特定業(yè)務有關(guān)的依賴關(guān)系應該盡量依賴接口和抽象類,而不是依賴于具體類。具體類只負責相關(guān)業(yè)務的實現(xiàn),修改具體類不影響與特定業(yè)務有關(guān)的依賴關(guān)系。
為此,我們在進行業(yè)務設(shè)計時,應盡量在接口或抽象類中定義業(yè)務方法的原型,并通過具體的實現(xiàn)類(子類)來實現(xiàn)該業(yè)務方法,業(yè)務方法內(nèi)容的修改將不會影響到運行時業(yè)務方法的調(diào)用。
4. 接口分離原則(the Interface Segregation Principle ISP)
采用多個與特定客戶類有關(guān)的接口比采用一個通用的涵蓋多個業(yè)務方法的接口要好。
ISP原則是另外一個支持諸如COM等組件化的使能技術(shù)。缺少ISP,組件、類的可用性和移植性將大打折扣。
這個原則的本質(zhì)相當簡單。如果你擁有一個針對多個客戶的類,為每一個客戶創(chuàng)建特定業(yè)務接口,然后使該客戶類繼承多個特定業(yè)務接口將比直接加載客戶所需所有方法有效。
例題:
國家標準《計算機軟件產(chǎn)品開發(fā)文件編制指南GB8567-88》中規(guī)定,在一項軟件開發(fā)過程中,一般來說應該產(chǎn)生14種文件,其中管理人員主要使用的有A 、B 、C 、開發(fā)進度月報、項目開發(fā)總結(jié)報告。開發(fā)人員主要使用的有A 、B 、D 、數(shù)據(jù)要求說明書、概要設(shè)計說明書、詳細設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、測試計劃和E 。維護人員主要使用的有設(shè)計說明書、E和C 。
A~E:①軟件需求說明書 ②項目開發(fā)計劃 ③可行性研究報告
、苣K開發(fā)卷宗 ⑤測試分析報告 ⑥操作手冊
⑦用戶手冊
[分析]
本題綜合考查了軟件生命周期各個階段的相關(guān)知識。
大家在復習軟件工程這部分內(nèi)容的時候,除了對軟件生命周期的每個階段(如需求分析、軟件設(shè)計、軟件維護等)的相關(guān)知識應該仔細復習以外,對整個軟件生命周期各階段還應有個總體的認識和把握。前面在知識要點中有比較表對各階段的任務、參與人員和產(chǎn)生文檔做出了歸納和總結(jié),大家復習的時候可以好好參考一下。
[答案]
A:② B:③ C:④ D:① E:⑤
同步輔導中的軟件工程部分的題目很好,大家可以做一下,題目類型和軟考類似;
1.8軟件質(zhì)量(重點)
軟件質(zhì)量是指反映軟件系統(tǒng)或軟件產(chǎn)品滿足規(guī)定或隱含需求的能力的特征和特性全體。下面從管理的角度列出了影響軟件質(zhì)量的主要因素。
質(zhì)量因素 |
定義 | |
產(chǎn)品運行 |
正確性 |
系統(tǒng)滿足規(guī)格說明和用戶目標的程序,即在預定環(huán)境下能正確的完成預期功能的程序 |
健壯性 |
在硬件發(fā)生故障、輸入的數(shù)據(jù)無效或操作錯誤等意外環(huán)境下,系統(tǒng)能做出適當響應的程序 | |
效率 |
為了完成預定的功能,系統(tǒng)需要的計算資源的多少 | |
完整性(安全性) |
對未經(jīng)授權(quán)的人使用軟件或數(shù)據(jù)的企圖,系統(tǒng)能夠控制(禁止)的程序 | |
可用性 |
系統(tǒng)在完成預定應該完成的功能時令人滿意的程度 | |
風險 |
按預定的成本和進度將系統(tǒng)開發(fā)處理,并且為用戶滿意的概率 | |
產(chǎn)品修改 |
可理解性 |
理解和使用該系統(tǒng)的容易程度 |
可維修性 |
診斷和改正在運行現(xiàn)場發(fā)現(xiàn)的錯誤所需要的工作量的多少 | |
靈活性(適應性) |
修改或改進正在運行的系統(tǒng)需要的工作量的多少 | |
可測試性 |
軟件容易測試的程度 | |
產(chǎn)品轉(zhuǎn)移 |
可移植性 |
把程序從一種硬件配置和(或)軟件系統(tǒng)環(huán)境轉(zhuǎn)移到另一種配置和環(huán)境時,需要的工作量多少 |
可再用性 |
在其他應用中該程序可以被再次使用的程度(或范圍) | |
互運行性 |
把該系統(tǒng)和另一個系統(tǒng)結(jié)合起來需要的工作量的多少 |
北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內(nèi)蒙古 |