《軟件工程》研究生復試知識點總結


title: 《軟件工程》研究生復試知識點總結
categories: 計算機專業(yè)課
tags: "軟件工程" "復試"


前言:軟件工程知識點總結,是在本人的另外兩篇文章——《軟件工程導論》期末知識點復習《UML面向對象需求分析與建模教程》期末知識點總結復習的基礎上按常見復試大綱詳細總結的。注:本書參考《軟件工程導論》第六版翘鸭,張海藩绰更,紅色的那本竹握。

<--more-->

第一章 軟件工程概論

軟件

  1. *軟件:是計算機程序既穆、方法、規(guī)則良风、相關的文檔以及運行計算機系統(tǒng)時所必需的數(shù)據(jù)的總和(狹義定義:軟件=程序+數(shù)據(jù)+文檔)
  2. *軟件的特性:軟件是復雜的嗡载、軟件是不可見的、軟件是不斷變化的和軟件質量難以穩(wěn)定哮独。
  3. *軟件的質量特性:功能性拳芙、可靠性、易用性皮璧、效率舟扎、維護性、可移植性悴务。

軟件危機

  1. 軟件危機:指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題睹限。
  2. 軟件危機的主要表現(xiàn):
  • 對軟件開發(fā)成本和進度估計常常很不準確
  • 用戶對"已完成"的系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生
  • 軟件產(chǎn)品的質量往往靠不住
  • 軟件常常是不可維護的
  • 軟件成本在計算機系統(tǒng)總成本所占的比例逐年上升
  1. 軟件危機產(chǎn)生的主要原因:
  • 軟件日益復雜和龐大
  • 軟件開發(fā)管理困難和復雜
  • 軟件開發(fā)技術落后
  • 生產(chǎn)方式落后
  • 開發(fā)工具落后
  • 軟件開發(fā)費用不斷增加
  1. 軟件危機如何解決:既要有技術措施(方法和工具),又要有必要的組織管理措施讯檐。

軟件工程

  1. 軟件工程:是指導計算機軟件開發(fā)和維護的一門工程學科羡疗。采用工程的概念、原理别洪、技術和方法來開發(fā)與維護軟件叨恨,把經(jīng)過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來,以經(jīng)濟地開發(fā)出高質量的軟件并有效地維護它挖垛。(1993年IEEE給出的定義:“軟件工程:①把系統(tǒng)的痒钝、規(guī)范的秉颗、可度量的途徑應用于軟件開發(fā)、運行和維護的過程送矩,也就是把工程應用于軟件蚕甥;②研究①中提到的途徑《拜”)
  2. 軟件工程本質特征(7個)
  • 軟件工程關注與大型程序的構造
  • 軟件工程的中心課題是控制復雜性
  • 軟件經(jīng)常變化
  • 開發(fā)軟件的效率非常重要
  • 和諧地合作是開發(fā)軟件的關鍵
  • 軟件必須有效地支持它的用戶
  • 在軟件工程領域中通常由具有一種文化背景的人替代另一種有文化背景的人創(chuàng)造產(chǎn)品
  1. 軟件工程的基本原理(7條)
  • 用分階段的生命周期計劃嚴格管理
  • 堅持進行階段評審
  • 實行嚴格的產(chǎn)品控制
  • 采用現(xiàn)代程序設計技術
  • 結果應能清楚的審查
  • 開發(fā)小組人員應該少而精
  • 承認不斷改進軟件工程實踐的必要性

軟件工程方法

  1. 軟件工程方法學:把軟件生命周期全過程中使用的一整套技術方法的集合成為方法學(也稱范型paradigm),包括三個要素:方法(完成軟件開發(fā)的技術方法),工具(為方法提供支撐環(huán)境)和過程(為獲得高質量軟件所需要的框架).目前使用最廣泛的是傳統(tǒng)方法學和面向對象方法學
  2. 傳統(tǒng)方法學(也稱生命周期方法學或結構化范型):采用結構化技術(結構化分析,結構化技術,結構化實現(xiàn))來完成軟件開發(fā)的各項任務,并使用適當?shù)能浖ぞ呋蜍浖h(huán)境來支持結構化技術的運用菇怀。

這種方法把軟件生命周期分為若干階段;每個階段相對獨立蒸其;每個階段的開始和結束都有嚴格的標準敏释;前一個階段是后一個階段的前提和基礎,后一個階段是前一個階段的具體化摸袁。文檔是通訊的工具

  1. 面向對象方法學:是一種以數(shù)據(jù)為主線钥顽,把數(shù)據(jù)和對數(shù)據(jù)的操作緊密地結合起來方法。
  • 4個要點
    ①把對象(object)作為融合了數(shù)據(jù)及在數(shù)據(jù)上的操作行為的統(tǒng)一的軟件構件
    ②把所有對象都劃分成類(class)
    ③按照父類(或稱為基類)與子類(或稱為派生類)的關系靠汁,把若干個相關類組成一個層次結構的系統(tǒng)(也稱為類等級)
    ④對象彼此間僅能通發(fā)送消息互相聯(lián)系
  • 優(yōu)點:它是一個多次反復迭代的演化的過程;特有的繼承性和多態(tài)性進一步提高了面向對象軟件的可重用性蜂大。

軟件生命周期

  1. 軟件生命周期:由軟件定義、軟件開發(fā)和軟件維護三個時期組成蝶怔,每個時期又由若干階段組成奶浦。見下圖
    軟件生命周期
  • 問題定義:確定要解決的問題是什么(通過客戶的訪問調查,系統(tǒng)分析員寫出問題的性質,工程目標和工程規(guī)模的書面報告,并得到客戶的確認)
  • 可行性研究:不是具體解決問題,而是研究問題的范圍,探索問題是否值得去解,是否有可行的解決方法
  • 需求分析:準確確定"為了解決這個問題,目標系統(tǒng)必須做什么",主要是確定目標系統(tǒng)必須具備哪些功能
  • 總體設計:設計出目標系統(tǒng)的多種方案;設計程序的體系結構
  • 詳細設計:詳細的設計每個模塊,確定要實現(xiàn)模塊功能所需要的算法和數(shù)據(jù)結構
  • 編碼和單元測試:寫出正確的容易理解,容易維護的程序模塊
  • 綜合測試:通過各種類型的測試(及相應的的調試)使軟件達到預定的要求
  • 軟件維護:通過各種必要的維護活動使系統(tǒng)持久地滿足用戶的需要

軟件過程

  1. 軟件過程:指為了獲得高質量軟件所需完成一系列任務框架,它規(guī)定了完成各項任務的工作步驟。概括的說:軟件工程描述為了開發(fā)出客戶需要的軟件踢星,什么人(who)澳叉、在什么時候(when)、做什么事(what)以及怎么做(how)以實現(xiàn)一個特定的目標沐悦。通常使用生命周期模型簡潔地描述軟件過程
  2. 生命周期模型:也稱過程模型規(guī)定了把生命周期劃分成哪些階段及各個階段的執(zhí)行順序
  3. 瀑布模型

①瀑布模型特點:

  • 階段間具有順序性和依賴性:必須等前一階段的工作完成后之后,才能開始后一段的工作;前一段的輸出文檔就是后一階段的輸入文檔
  • 推遲實現(xiàn)的觀點:在編碼之前設置了系統(tǒng)分析和系統(tǒng)設計的各個階段,分析與設計階段的基本任務規(guī)定,這兩個階段主要考慮目標系統(tǒng)的邏輯模型,不涉及物理實現(xiàn)
  • 質量保證的觀點:每個階段必須完成規(guī)定的文檔;每個階段結束前都要對完成的文檔進行評審,以便盡早發(fā)現(xiàn)問題

②瀑布模型適用:在開發(fā)的早期階段軟件需求被完整確定
③瀑布模型的優(yōu)點: 可強迫開發(fā)人員采用規(guī)范的方法;嚴格規(guī)定了每個階段必須提交的文檔;要求每個階段交出的所有產(chǎn)品都必須經(jīng)過質量保證小組的仔細驗證
④瀑布模型缺點:瀑布模型是由文檔驅動;最終產(chǎn)品不能真正滿足客戶的需求

  1. 快速原型模型:首先建立一個反映用戶主要需求的原型系統(tǒng)(往往是最終產(chǎn)品能完成的功能的一個子集),讓用戶體驗,之后提出意見,隨之進行修改,再讓用戶體驗...直至用戶完全滿意,據(jù)此寫出規(guī)格說明文檔
  2. 增量模型:也稱漸增模型成洗,把軟件產(chǎn)品作為一系列的增量構件來設計、編碼藏否、集成和測試瓶殃,融合了瀑布模型的基本成分(重復應用)和原型實現(xiàn)的迭代特征,該模型采用隨著日程時間的進展而交錯的線性序列副签,每一個線性序列產(chǎn)生軟件的一個可發(fā)布的“增量”遥椿。
  • 增量模型優(yōu)點:人員分配靈活,剛開始不用投入大量人力資源;可先發(fā)布部分功能給客戶淆储,對客戶起到鎮(zhèn)靜劑的作用冠场,客戶也有充分的時間了解新產(chǎn)品;增量能夠有計劃地管理技術風險本砰。
  • 增量模型缺點:需要軟件具備開放式的體系結構慈鸠;容易退化為邊做邊改模型,從而使軟件過程的控制失去整體性灌具;增加系統(tǒng)內部的耦合復雜性青团。
  1. 螺旋模型:基本思想是使用原型及其他方法來盡量降低風險。(可看作在每個階段之前增加了風險分析的快速原型模型)
    螺旋模型優(yōu)點:①利于軟件重用②有助于把軟件質量作為開發(fā)的重要目標之一③減少過多測試或測試不足帶來的風險④維護是在另外一個周期咖楣,不影響開發(fā)

  2. 噴泉模型:典型的具有面向對象軟件開發(fā)過程迭代和無縫的特性

Rational 統(tǒng)一過程

  1. Rational 統(tǒng)一過程(Rational Unified Process Rational督笆,RUP): RUP核心:RUP核心是解決可操作性問題,幫助開發(fā)人員盡可能少地依賴那些“不可描述的經(jīng)驗”诱贿。RUP特點:用例驅動娃肿;以體系結構為中心(高內聚低耦合);增量和迭代開發(fā)珠十。
  2. RUP最佳實踐
  • 迭代式開發(fā):允許每次迭代過程中需求都可以有變化;采用可驗證的方法來減少風險
  • 管理需求:RUP采用用例分析來捕獲需求,并由它們驅動設計和實現(xiàn)
  • 使用基于構件的體系架構:使用現(xiàn)有的或新開發(fā)的構件定義體系結構的系統(tǒng)化方法,從而降低軟件開發(fā)的復雜性,提高軟件重用率
  • 可視化建模:建立軟件系統(tǒng)的可視化模型,提高管理復雜軟件的能力,如UML
  • 驗證軟件質量:軟件質量評估貫穿整個開發(fā)過程,由全體成員參與
  • 控制軟件的變更:RUP描述了如何控制,跟蹤和監(jiān)控修改,以確保迭代開發(fā)的成功
  1. RUP軟件開發(fā)生命周期

①核心工作流 (縱軸代表核心工作流,橫軸代表時間) 前6個為核心過程工作流, 后3個為核心支持工作流

  • 業(yè)務建模:深入了解使用目標系統(tǒng)的機構及商務運作評估目標系統(tǒng)對使用它的機構的影響
  • 需求:捕獲客戶的需求并且使開發(fā)人員和用戶達成對需求描述的共識
  • 分析與設計:把需求分析的結果轉化為分析模型和設計模型
  • 實現(xiàn):把設計模型轉化為實現(xiàn)結果
  • 測試:檢查各子系統(tǒng)的交互與集成,驗證所有需求是否都被正確實現(xiàn),識別,確認缺陷并確保在軟件部署之前消除缺陷
  • 部署:成功生成目標系統(tǒng)的可運行版本,并將軟件移交給用戶
  • 配置與變更管理:跟蹤并維護在軟件過程中產(chǎn)生的所有制品的完整性和一致性
  • 項目管理:提供項目管理框架,為軟件開發(fā)制定計劃,人員配備,執(zhí)行和監(jiān)控等方面的使用準則,并為風險管理提供框架
  • 環(huán)境:向軟件開發(fā)機構提供軟件開發(fā)環(huán)境,包括過程管理和工具支持

②工作階段

  • 初始階段:建立業(yè)務模型,定義最終產(chǎn)品視圖,并確定項目的范圍
  • 精化階段:設計并確定系統(tǒng)的體系結構,制定項目計劃確定資源需求
  • 構建階段:開發(fā)出所有構件和應用程序,把它們集成客戶需要的產(chǎn)品,并且詳細地測試所有功能
  • 移交階段:把開發(fā)出的產(chǎn)品提交給用戶使用

③RUP迭代式開發(fā):RUP強調采用迭代和漸增的方式來開發(fā)軟件料扰,整個項目由多個迭代過程組成。

敏捷過程與極限編程

  1. 敏捷過程的四個價值聲明
  • 個體和交互勝過過程和工具
  • 可以工作的軟件勝過面面俱到的文檔
  • 客戶合作勝過合同談判
  • 響應變化勝過遵循計劃
  1. 極限編程的特點
  • 有效實踐
  • 整體開發(fā)過程
  • 迭代過程

第二章 可行性研究

  1. 可行性研究的目的不是為了解決問題焙蹭,而是確定問題是否值得去解決
  2. 可行性:技術可行性晒杈、經(jīng)濟可行性、操作可行性孔厉、運行可行性拯钻、法律可行性。
  3. 可行性研究過程
  • 復查系統(tǒng)規(guī)模和目標
  • 研究正在使用的系統(tǒng)
  • 導出新系統(tǒng)的高層邏輯模型
  • 進一步定義問題
  • 導出和評價供選擇的解法
  • 推薦行動方針
  • 草擬開發(fā)計劃
  • 書寫文檔提交審查
  1. *系統(tǒng)流程圖:是概括地描繪物理系統(tǒng)的傳統(tǒng)工具撰豺。用圖形符號以黑盒子形式描繪組成系統(tǒng)的每個部件(程序粪般,文檔,數(shù)據(jù)庫污桦,人工過程等)亩歹。表達的是數(shù)據(jù)在系統(tǒng)各部件之間流動的情況
符號 名稱 說明
矩形 處理 能改變數(shù)據(jù)值或數(shù)據(jù)位置的加工或部件。如程序 凡橱、處理機小作、人工加工等都是處理
平行四邊形 輸入輸出 表示輸入或輸出,是一個廣義的不指名具體設備的符號
圓形 連接 指出轉到圖的另一部分或從圖的另一部分轉來梭纹,通常在同一頁上
矩形下面 加個三角形 換頁連接 指出轉到另一頁圖上或另一頁圖轉來
箭頭 數(shù)據(jù)流 用來連接其他符號躲惰,指明數(shù)據(jù)流的方向
  1. 數(shù)據(jù)流圖(DED)是一種圖形化技術,它描繪信息流和數(shù)據(jù)從輸入移動到輸出移動的過程中所經(jīng)受的變換变抽。是系統(tǒng)邏輯功能的圖形表示础拨。
圖形 說明
正方形或立方體 數(shù)據(jù)的源點/終點
圓角矩形或圓形 變換數(shù)據(jù)的處理
矩形缺了右邊一條邊或平行雙線 數(shù)據(jù)存儲
箭頭 數(shù)據(jù)流
*
+
互斥(異或)
  1. 數(shù)據(jù)字典:是關于數(shù)據(jù)的信息集合,也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合绍载。由四類元素定義組成:數(shù)據(jù)流 數(shù)據(jù)流分量(即數(shù)據(jù)元素) 數(shù)據(jù)存儲 處理诡宗。數(shù)據(jù)字典和數(shù)據(jù)流圖共同構成系統(tǒng)的邏輯模型。

  2. 數(shù)據(jù)字典定義數(shù)據(jù)的方法(對數(shù)據(jù)自頂向下分解):

符號 含義
= 等價于或定義為
+ 和(連接兩個分量)
[] 或击儡,多個用|隔開
{} 重復
() 可選
標識符 字母字符+字母數(shù)字串
字母數(shù)字串 0{字母或數(shù)字}7
字母或數(shù)字 [字母字符|數(shù)字字符]
  1. 成本效益分析的方法及如何運算:
    第一步估計開發(fā)成本塔沃、運行費用和新系統(tǒng)將帶來的經(jīng)濟效益。需從貨幣時間價值,投資回收期,純收入,投資回收率
    方法有三種:
  • 代碼行技術:軟件成本=每行代碼的平均成本*估計的源代碼總行數(shù)
  • 任務分解技術:單本任務成本=任務所需人力估計值*每人每月平均工資阳谍;軟件開發(fā)項目總成本=每個單獨任務成本估計總和
  • 自動估計成本技術:采用自動估計成本的軟件

第三章 需求分析

  1. 需求分析的任務
  • 確定對系統(tǒng)的綜合要求
  • 分析系統(tǒng)的數(shù)據(jù)要求
  • 導出系統(tǒng)的邏輯模型
  • 修正系統(tǒng)開發(fā)計劃
  1. 分析建模:分析過程應建立三種模型數(shù)據(jù)模型 功能模型 行為模型
    模型: 就是為了理解事物而對事物作出的一種抽象,是對事物的一種無歧義的書面描述蛀柴。通常螃概,模型由一組圖形符號和組織這些符號的規(guī)則組成
  • 數(shù)據(jù)模型—>實體-聯(lián)系圖:描繪數(shù)據(jù)對象、數(shù)據(jù)對象的屬性及數(shù)據(jù)對象之間的關系鸽疾,用于建立數(shù)據(jù)模型
  • 功能模型—>數(shù)據(jù)流圖:描繪當數(shù)據(jù)在軟件系統(tǒng)中流動和被處理的邏輯過程吊洼,是建立功能模型的基礎
  • 行為模型—>狀態(tài)轉換圖:描繪系統(tǒng)的狀態(tài)及引起狀態(tài)轉換的事件,來表示系統(tǒng)的行為
  1. 狀態(tài)轉換圖符號含義及怎么畫 P65制肮,P67
  2. 其他圖形工具
  • 層次方框圖(P68):是用樹形結構的一系列多層次的矩形框描繪數(shù)據(jù)的層次結構冒窍。最頂層矩形框:代表完整的數(shù)據(jù)結構;下面各層的矩形框代表數(shù)據(jù)的子集豺鼻;最底層的矩形框代表實際數(shù)據(jù)元素
  • IPO圖(P69):IPO是輸入综液、處理、輸出圖的簡稱儒飒,描繪輸入數(shù)據(jù)谬莹、對數(shù)據(jù)的處理和輸出數(shù)據(jù)之間的關系。

*第四章 形式化說明技術

  1. 按形式化程度分為三類:
  • 非形式化约素,如用自然語言描述規(guī)格說明
  • 半形式化届良,如用數(shù)據(jù)流圖或實體-聯(lián)系圖建立模型
  • 形式化,如描述系統(tǒng)性質是基于數(shù)學的技術
  1. 非形式化的缺點
  • 矛盾性:在需求規(guī)格說明書中對同一問題前后存在不同的描述
  • 二義性:讀者可以用不同的方式理解的陳述
  • 含糊性:需求規(guī)格說明書對某一問題描述不清晰圣猎,不可理解
  • 不完整性:需求規(guī)格說明書對某一問題只說明了局部士葫,沒說明整體
  • 抽象層次混亂:指在非常抽象的陳述中混入了關于低層次的細節(jié)陳述
  1. 形式化的優(yōu)點:
  • 能夠簡潔準確的描述物理現(xiàn)象、對象或動作的結果
  • 在不同的軟件工程活動之間平滑過渡
  • 提供了高層確認的手段
  1. 應用形式化準則
  • 選用適當?shù)谋硎痉椒?/li>
  • 應該形式化送悔,但不要過分形式化
  • 應該估算成本
  • 應該有形式化顧問隨時提供咨詢
  • 不應該放棄傳統(tǒng)的開發(fā)方法
  • 應該建立詳盡的文檔
  • 不應該放棄質量標準
  • 應該測試慢显,測試再測試
  • 應該重用

第五章 總體設計

  1. 設計過程2個階段(系統(tǒng)設計階段:確定系統(tǒng)的具體實現(xiàn)方案 和 結構設計階段:確定軟件結構); 9個步驟
  • 設想供選擇的方案
  • 選取合理的方案
  • 推薦最佳方案
  • 功能分解
  • 設計軟件結構
  • 設計數(shù)據(jù)庫
  • 制定測試計劃
  • 書寫文檔
  • 審查和復審
  1. 設計原理的相關概念(很重要需細讀課本)
  • 模塊化:就是把程序劃分成獨立命名且可獨立訪問的模塊,每個模塊完成一個子功能欠啤,這些模塊集成起來構成一個整體荚藻,可以完成指定的功能滿足用戶的需求
  • 抽象:抽出事物本質特性而暫時不考慮細節(jié)
  • 逐步求精:為了能集中精力解決最主要問題而盡量推遲對問題細節(jié)的考慮。逐步求精是人類解決復雜問題時采用的基本方法洁段,也是許多軟件工程技術的基礎
  • 信息隱藏:應該這樣設計和確定模塊应狱,使得一個模塊內包含的信息對于不需要這些信息的模塊來說是不能訪問的
  • 局部化:是指把一些關系密切的軟件元素物理地址放得彼此靠近
  • 模塊獨立:是模塊化、抽象祠丝、信息隱藏和局部化的概念的直接結果疾呻。獨立的程度測量標準:內聚、耦合
  1. 耦合:是對一個軟件結構內不同模塊之間互連程度的度量写半。耦合強弱取決于模塊間接口的復雜程度岸蜗,進入或訪問一個模塊的點,以及通過接口的數(shù)據(jù)叠蝇。耦合程度強烈影響著系統(tǒng)的可理解性璃岳、可測試性、可靠性、可維護性铃慷。設計原則:盡量使用數(shù)據(jù)耦合单芜,少用控制耦合和特征耦合,限制公共環(huán)境的耦合的范圍枚冗,完全不用內容耦合缓溅。
  • 數(shù)據(jù)耦合:如果兩個模塊彼此間通過參數(shù)交換信息,而且交換的信息僅僅是數(shù)據(jù)赁温。數(shù)據(jù)耦合是低耦合
  • 控制耦合:傳遞的信息中有控制信息。中等耦合淤齐,增加了系統(tǒng)的復雜性
  • 特征耦合:當整個數(shù)據(jù)結構作為參數(shù)傳遞而被調用的模塊只需要使用其中一部分數(shù)據(jù)元素時
  • 公共環(huán)境耦合:當兩個或多個模塊通過一個公共數(shù)據(jù)環(huán)境互相作用時股囊。公共環(huán)境可以是全程變量、共享通信區(qū)更啄、內存的公共覆蓋區(qū)稚疹、任何存儲介質的文件、物理設備等祭务。
  • 內容耦合:如果發(fā)生之一就是①一個模塊訪問另一個模塊的內部數(shù)據(jù),②一個模塊不通過正常入口而轉到另一個模塊的內部,③兩個模塊有一部分程序代碼重疊,④一個模塊有多個入口
  1. 內聚:標志著一個模塊內各個元素彼此之間結合的緊密程度内狗,它是信息隱藏和局部化概念的擴展。設計原則:力求高內聚义锥,通過提高模塊間的內聚降低耦合從而使模塊獲得較高的獨立性柳沙。高內聚意味著低耦合
  2. 低內聚
  • 偶然內聚:如果一個模塊完成一組任務,這些任務彼此之間有關系拌倍,關系也是很松散的赂鲤。如在一個程序內有一組語句在兩處或多處出現(xiàn),于是把這些語句作為一個模塊以節(jié)省內存
  • 邏輯內聚:如果一個模塊完成的任務在邏輯上屬于相同或相似的一類柱恤。如一個模塊產(chǎn)生各種類型的全部輸出
  • 時間內聚:如果一個模塊包含的任務必須在同一時間內執(zhí)行数初。如模塊完成各種初始化工作
  1. 中內聚
  • 過程內聚:如果一個模塊內的處理元素是相關的,且必須以特定次序執(zhí)行梗顺。如流程圖確定模塊的劃分泡孩,得到的往往是過程內聚的模塊
  • 通信內聚:如果一個模塊中所有元素都是用同一個輸入數(shù)據(jù)和產(chǎn)生同一個輸出數(shù)據(jù)
  1. 高內聚
  • 順序內聚:如果一個模塊內的處理元素和同一個功能密切相關,且這些處理必須順序執(zhí)行寺谤。如一個處理元素的輸出數(shù)據(jù)作為下一個處理元素的輸入數(shù)據(jù)仑鸥,根據(jù)數(shù)據(jù)流圖劃分模塊得到往往是順序內聚模塊
  • 功能內聚:如果模塊內的所有處理元素屬于一個整體,完成單一的功能
  1. 7種內聚的優(yōu)劣評分
名稱 得分
功能內聚 10
順序內聚 9
通信內聚 7
過程內聚 5
時間內聚 3
邏輯內聚 1
偶然內聚 0
  1. 啟發(fā)規(guī)則
  • 改進軟件結構提高模塊的獨立性
  • 模塊規(guī)模應該適中
  • 深度矗漾、寬度锈候、扇出和扇入都應適當
  • 模塊的作用域應該在控制域內
  • 力爭降低模塊接口的復雜程度
  • 設計單入口單出口的模塊
  • 模塊的功能應該可預測
  1. 描繪軟件結構的圖形工具(例子見P102~P104)
  • 層次圖:描繪軟件的層次結構,和前面的層次方框圖形式相同敞贡。一個矩形框代表一個模塊泵琳,方框間的連線表示調用關系
  • HIPO圖(適合自頂向下):“層次圖加輸入/處理/輸出圖”,就是在層次圖的每個方框加編號
  • 結構圖:每個方框代表一個模塊,框內注明模塊的名字或主要功能获列,方框間的箭頭(或直線)代表模塊的調用關系谷市,注釋表示來回傳遞的信息【尾部空心圓表示傳遞數(shù)據(jù),實心圓代表傳遞控制信息】

*第六章 詳細設計

過程設計工具

  1. 程序流程圖:
  • 優(yōu)點:對控制流程的描繪直觀击孩,初學者很容易掌握
  • 缺點:①程序流程圖不是精益求精的好工具嗎迫悠,它誘使程序員過早地考慮程序的控制流程,而不去考慮全局結構②程序流程圖中用箭頭代表控制流 巩梢,因此程序員不受任何約束创泄,可以完全不顧結構程序設計的思想,隨意轉移③程序流程圖不易表示數(shù)據(jù)結構
  1. 盒圖(N-S圖)的特點:
  • 功能域明確
  • 不可能任意轉移控制
  • 很容易確定局部和全局數(shù)據(jù)的作用域
  • 很容易表現(xiàn)嵌套關系括蝠,也可以表示模塊的層次結構
  1. 問題分析圖(PAD圖):使用二維結構的圖來表示程序的控制流鞠抑。其優(yōu)點:
  • 使用PAD符號設計出來必然是結構化程序
  • PAD圖描繪的程序結構十分清楚
  • PAD圖表現(xiàn)程序的邏輯,易讀忌警、易懂搁拙、易記
  • 很容易將PAD圖轉化為高級語言程序
  • 即可表示程序邏輯,也可表示數(shù)據(jù)結構
  • PAD符號支持自動向下法绵,逐步求精
  1. 判定表:當算法中含有多重嵌套的條件選擇時
  • 優(yōu)點:能清晰表示復雜的條件組合與應做的動作之間的關系
  • 缺點:①判定表的含義不能一眼看出來②當數(shù)據(jù)元素多于兩個時箕速,判定表的簡潔程度下降
  1. 判定樹:判定表變種
  • 優(yōu)點:一眼看出其含義,易于掌握朋譬,使用
  • 缺點:①簡潔性不如判定表盐茎,數(shù)據(jù)元素需重復寫多遍②判定樹的分支次序對畫出的判定樹的簡潔程度有較大影響

面向數(shù)據(jù)結構設計方法

  1. PDL(過程設計語言):也稱偽碼,具有嚴格的關鍵字外部語法此熬,用于定義控制結構和數(shù)據(jù)結構庭呜,內部語法靈活自由,適應各種工程項目犀忱。

其優(yōu)點:

  • 可作為注釋直接插在源程序中間
  • 可使用普通的正文編輯程序或文字處理系統(tǒng)完成PDL的書寫和編輯
  • 已有自動處理PDL的程序募谎,可自動生成程序代碼

其缺點:

  • 不如圖形工具形象直觀,描述復雜的條件組合與動作間的對應關系時阴汇,不如判定表清晰簡單
  1. McCabe方法:McCabe根據(jù)程序控制流的復雜程度度量 程序的復雜程度数冬,這樣度量出的結果稱為程序的環(huán)形復雜度

①流圖的表示:

  • 結點:用圓表示,一個圓代表一條或多條語句
  • 邊:箭頭線稱為邊搀庶,代表控制流
  • 區(qū)域:由邊和結點圍成的面積 稱為區(qū)域拐纱,當計算區(qū)域數(shù)時應該包括圖外未被圍起來的區(qū)域
  • 判定結點:包含條件的結點

②計算環(huán)形復雜度的方法:

  • 流圖中線性無關的區(qū)域數(shù)等于環(huán)形復雜度
  • 流圖G的環(huán)形復雜度V(G)=E-N+2,其中E是流圖中邊的條數(shù),N是結點數(shù)
  • 流圖G的環(huán)形復雜度V(G)=P+1,其中P是流圖中判定結點的數(shù)目

第七章 實現(xiàn)(編碼和測試統(tǒng)稱為實現(xiàn))

編碼:把詳細設計結果翻譯成某種程序語言書寫的程序
軟件測試:是保證軟件質量的關鍵步驟哥倔,是對軟件規(guī)格說明秸架、設計和編碼的最后復審

第七章實現(xiàn)(編碼和測試).png

點擊查看大圖

  1. 如何選擇程序語言:用戶要求;編譯程序咆蒿;軟件工具东抹;工程規(guī)模蚂子;程序員知識;軟件可移植性要求缭黔;應用領域

軟件測試

  1. 軟件測試的目標
  • 為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程
  • 好的測試方案實際可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案
  • 成功的測試是發(fā)現(xiàn)至今為止尚未發(fā)現(xiàn)的錯誤的測試
  1. 軟件測試準則
  • 所有測試都能追溯到用戶需求
  • 在進行測試前就制定出測試計劃
  • 從“小規(guī)氖尘ィ”測試開始逐步到“大規(guī)模”測試
  • 窮舉測試是不可能的
  • 由獨立的第三方進行測試

測試方法

  1. 白盒測試:又稱為結構測試馏谨,把測試對象看作一個透明的盒子别渔,測試人員根據(jù)程序內部的邏輯結構及有關信息設計測試用例,檢查程序中所有邏輯路徑是否都按預定的要求正確地工作惧互。
  • 白盒測試主要用于對模塊的測試哎媚,包括:程序模塊中的所有獨立路徑至少執(zhí)行一次;對所有邏輯判定的取值(“真”與“假”)都至少測試一次壹哺;在上下邊界及可操作范圍內運行所有循環(huán)抄伍;測試內部數(shù)據(jù)結構的有效性等。
  • 常用的白盒測試方法有:邏輯覆蓋測試管宵;基本路徑測試;循環(huán)測試攀甚。
  1. 黑盒測試:又稱行為測試箩朴,把測試對象看做一個黑盒子,測試人員完全不考慮程序內部的邏輯結構和內部特性秋度,只依據(jù)需求規(guī)格說明書炸庞,檢查程序的功能是否符合它的功能需求。
  • 黑盒測試可用于各種測試荚斯,它試圖發(fā)現(xiàn)以下類型的錯誤:不正確或遺漏的功能埠居;界面錯誤;數(shù)據(jù)結構錯誤或外部信息(如外部數(shù)據(jù)庫)訪問錯誤事期;性能錯誤滥壕;初始化和終止錯誤。
  • 主要的黑盒測試方法有:等價類劃分兽泣;邊界值分析绎橘;錯誤推測法;因果圖唠倦。
  1. 測試步驟:模塊測試 子系統(tǒng)測試 系統(tǒng)測試 平行運行

測試用例:所謂測試用例是為特定的目的而設計的一組測試輸入称鳞、執(zhí)行條件和預期的結果;測試用例是執(zhí)行測試的最小實體稠鼻。

  1. 單元測試:稱模塊測試冈止,是針對軟件設計的最小單位 ─ 程序模塊,進行正確性檢驗的測試工作候齿。其目的在于發(fā)現(xiàn)各模塊內部可能存在的各種差錯熙暴。
  • 單元測試的內容:模塊接口闺属;局部數(shù)據(jù)結構 ;重要執(zhí)行通路 怨咪;出錯處理通路屋剑;邊界條件
  • 單元測試優(yōu)點:更易發(fā)現(xiàn)bug;更容易維護诗眨;更容易理解唉匾;更容易開發(fā)。
  1. 集成測試:查看大圖

第八章 維護

  1. 軟件維護的定義:就是在軟件已經(jīng)交付使用之后匠楚,為了改正錯誤或滿足新的需要而修改軟件的過程
  2. 結構化維護和非結構化維護

①非結構化維護

  • 如果軟件配置的唯一成分是程序代碼巍膘,那么維護活動從評價代碼開始,而且由于內部文檔不足而使評價更困難
  • 非結構化維護需要付出巨大代價芋簿,是沒有使用良好定義的方法學開發(fā)出來的必然結果
    ②結構化維護
  • 如果有一個完整軟件配置存在峡懈,那么維護從評價設計文檔開始就很規(guī)范
  • 減少精力的浪費,提高維護的總體質量
  1. 決定軟件可維護的因素
  • 可理解性
  • 可測試性
  • 可修改性
  • 可移植性
  • 可重用性
  1. 軟件再工程過程


    軟件再工程過程模型

第八章 面向對象方法學引論

  1. 面向對象方法學要點

①基本原則:盡可能模擬人類習慣的思維方式与斤,是開發(fā)軟件的方法和過程盡可能接近人類認識的世界解決問題的方法和過程
②4個要點

  • 軟件是由對象組成的肪康,任何元素都是對象,復雜軟件對向由比較簡單的軟件對象組成
  • 所有對象都劃分成對象類撩穿,類都定義了一組數(shù)據(jù)和一組方法
  • 若干對象類組成一個層次的系統(tǒng)
  • 對象間僅能通過傳遞消息互相聯(lián)系
    ③面向對象方法學優(yōu)點
  • 與人類習慣的思維方法一致
  • 穩(wěn)定性好
  • 可重用性好
  • 較易開發(fā)大型軟件產(chǎn)品
  • 可維護性好
  1. 對象:是描述該對象屬性的數(shù)據(jù)以及對這些數(shù)據(jù)施加的所有操作封裝在一起構成的統(tǒng)一體

①對象的定義

  • 對象是具有相同狀態(tài)的一組操作的集合
  • 對象是對問題域中某個東西的抽象
  • 對象::=<ID,MS,DS,MI>磷支。ID是對象的標識或名字,MS操作集合食寡,DS數(shù)據(jù)結構雾狈,MI對象受理的消息名集合
    ②對象的特點
  • 以數(shù)據(jù)為中心
  • 對象是主動
  • 實現(xiàn)了數(shù)據(jù)的封裝
  • 本質上具有并行性
  • 模塊獨立性好
  1. 其它概念
  • 類:是一組具有相同屬性和相同操作的對象的集合。
  • 實例:由某個特定的類所描述的一個具體的對象抵皱。
  • 消息:要求某個對象執(zhí)行在定義它的那個類中所定義的某個操作的規(guī)格說明善榛。組成部分:接收消息的對象;消息名呻畸;消息變元
  • 方法:就是對象所能執(zhí)行的操作移盆,也就是類中所定義的服務。
  • 屬性:屬性就是類中所定義的數(shù)據(jù)擂错,它是對客觀世界實體所具有的性質的抽象味滞。
  • 封裝:對象封裝了對象的數(shù)據(jù)以及對這些數(shù)據(jù)的操作。
  • 繼承:繼承是子類自動地共享基類中定義的數(shù)據(jù)和方法的機制钮呀。
  • 單重繼承:子類僅從一個父類繼承屬性和方法
  • 多重繼承:子類可從多個父類繼承屬性和方法
  • 多態(tài)性:指子類對象可以像父類那樣使用
  • 函數(shù)重載:指在同一作用域內的若干參數(shù)特征不同的函數(shù)可以使用相同的函數(shù)名
  • 運算符重載:指在同一個運算符可以施加于不同類型的操作數(shù)上面

第十章 面向對象分析

  1. 建立對象模型

①三個子模型剑鞍,按所解決的問題進行劃分

  • 靜態(tài)結構(對象模型)
  • 交互次序(動態(tài)模型)
  • 數(shù)據(jù)變換(功能模型)

②5個層次

  • 主題層
  • 類與對象層
  • 結構層
  • 屬性層
  • 服務層

③對象模型創(chuàng)建的步驟

  • 確定類與對象
  • 確定關聯(lián)
  • 劃分主題
  • 確定屬性
  • 識別繼承關系
  • 反復修改

第十一章 面向對象設計

  1. 面向對象設計準則
  • 模塊化
  • 抽象
  • 信息隱藏
  • 弱耦合
  • 強內聚
  • 可重用
  1. 類構件的重用方式
  • 實例重用
  • 繼承重用
  • 多態(tài)重用
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市爽醋,隨后出現(xiàn)的幾起案子蚁署,更是在濱河造成了極大的恐慌,老刑警劉巖蚂四,帶你破解...
    沈念sama閱讀 219,539評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件光戈,死亡現(xiàn)場離奇詭異哪痰,居然都是意外死亡,警方通過查閱死者的電腦和手機久妆,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,594評論 3 396
  • 文/潘曉璐 我一進店門晌杰,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人筷弦,你說我怎么就攤上這事肋演。” “怎么了烂琴?”我有些...
    開封第一講書人閱讀 165,871評論 0 356
  • 文/不壞的土叔 我叫張陵爹殊,是天一觀的道長。 經(jīng)常有香客問我奸绷,道長梗夸,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,963評論 1 295
  • 正文 為了忘掉前任号醉,我火速辦了婚禮反症,結果婚禮上,老公的妹妹穿的比我還像新娘畔派。我一直安慰自己惰帽,他們只是感情好,可當我...
    茶點故事閱讀 67,984評論 6 393
  • 文/花漫 我一把揭開白布父虑。 她就那樣靜靜地躺著,像睡著了一般授药。 火紅的嫁衣襯著肌膚如雪士嚎。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,763評論 1 307
  • 那天悔叽,我揣著相機與錄音莱衩,去河邊找鬼。 笑死娇澎,一個胖子當著我的面吹牛笨蚁,可吹牛的內容都是我干的。 我是一名探鬼主播趟庄,決...
    沈念sama閱讀 40,468評論 3 420
  • 文/蒼蘭香墨 我猛地睜開眼括细,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了戚啥?” 一聲冷哼從身側響起奋单,我...
    開封第一講書人閱讀 39,357評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎猫十,沒想到半個月后览濒,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體呆盖,經(jīng)...
    沈念sama閱讀 45,850評論 1 317
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,002評論 3 338
  • 正文 我和宋清朗相戀三年贷笛,在試婚紗的時候發(fā)現(xiàn)自己被綠了应又。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,144評論 1 351
  • 序言:一個原本活蹦亂跳的男人離奇死亡乏苦,死狀恐怖株扛,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情邑贴,我是刑警寧澤席里,帶...
    沈念sama閱讀 35,823評論 5 346
  • 正文 年R本政府宣布,位于F島的核電站拢驾,受9級特大地震影響奖磁,放射性物質發(fā)生泄漏。R本人自食惡果不足惜繁疤,卻給世界環(huán)境...
    茶點故事閱讀 41,483評論 3 331
  • 文/蒙蒙 一咖为、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧稠腊,春花似錦躁染、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,026評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至叹放,卻和暖如春饰恕,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背井仰。 一陣腳步聲響...
    開封第一講書人閱讀 33,150評論 1 272
  • 我被黑心中介騙來泰國打工埋嵌, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留另凌,地道東北人秸滴。 一個月前我還...
    沈念sama閱讀 48,415評論 3 373
  • 正文 我出身青樓,卻偏偏與公主長得像仔拟,于是被迫代替她去往敵國和親合是。 傳聞我的和親對象是個殘疾皇子了罪,可洞房花燭夜當晚...
    茶點故事閱讀 45,092評論 2 355

推薦閱讀更多精彩內容