軟件工程知識點匯總軟件工程知識點匯總11/11軟件工程知識點匯總軟件工程知識點匯總軟件工程,軟件工程方法學：三要素軟件工程：eq\o\ac(○,1)應用系統化的,規范化的,可度量的方法來開發,運行和維護軟件，即將工程應用到軟件；eq\o\ac(○,2)對eq\o\ac(○,1)的各種方法的探討軟件工程是一門探討用工程化方法構建和維護有效的好用的和高質量的軟件的學科軟件工程三要素是：方法,工具,過程 軟件工程的方法：是指完成軟件開發各項任務的技術方法 軟件工具：是指為軟件工程方法的運用供應自動半自動的軟件支撐環境 軟件工程過程：是指將軟件工程方法和工具綜合起來以達到合理,及時地進行計算機軟件開發這一目的軟件工程的原則包括：模塊化原則,信息隱藏原則,抽象化原則,模塊獨立原則（內聚,耦合）,依靠倒轉原則,開閉原則等模塊化原則：指解決一個困難問題時自頂向下逐層把軟件系統劃分為若干模塊的過程。模塊是程序中相對獨立的成分，一個獨立的編程單位，應有良好的編程接口，模塊的大小要適中，模塊過大會使模塊內部的困難性增加不利于模塊的理解和修改，模塊過小會導致整個系統表示過于困難，不利于限制系統的困難性。信息隱藏原則：采納封裝技術，將程序模塊的實現細微環節隱藏起來，使模塊接口盡量簡單。抽象化原則：抽取事物最基本的特性和行為，忽視非本質細微環節，采納分層次抽象，自頂向下，逐層細化的方法限制軟件開發過程的困難性。模塊獨立原則：是指每個模塊只完成系統要求的獨立子功能，并且及其他模塊的聯系最少且接口簡單。要求在一個物理模塊內集中邏輯上相互關聯的計算機資源，保證模塊間由松散的偶合關系，模塊內部有較強的內聚性，這有助于限制系統的困難性。（即：高內聚低耦合）依靠倒轉原則：抽象不應當依靠于細微環節，細微環節應當依靠于抽象。開閉原則：軟件實體應當是可擴展的，但是不可以修改。即對于擴展是開放的，對于更改是封閉的。軟件開發模型：瀑布模型；快速原型；噴泉模型；各種模型的工作原理,階段,每階段任務,特點,示意圖；軟件開發模型（也稱為軟件過程模型）：是從軟件項目需求定義開始直至軟件經運用后廢棄為止，跨越整個生命周期的系統開發,運行和維護所實施的全部過程,活動和任務的結構框架瀑布模型（又稱線性模型）：工作原理：規定了它們自上而下,相互連接的固定次序，猶如瀑布流水，逐級下落。前一階段的工作成果是后一階段工作開始的基礎.所以,每個階段都必需交出合格的文檔,必需對前階段的工作進行評審,前一階段的工作完成后才可以開始后一階段的工作階段： 安排時期：問題定義,可行性探討 開發時期：需求分析,設計,編碼,測試 運行時期：運行和維護各階段任務：1.需求分析和定義在軟件項目進行過程中，需求分析是從軟件定義到軟件開發的關鍵步驟，是今后軟件，開發的基本依據，同時也是用戶對軟件產品進行驗收的基本依據。需求分析和定義是以用戶需求為基本依據，從功能,性能,數據,操作等多個方面，對軟件系統給出完整,精確,具體的描述，用于確定軟件規格。2.軟件設計依據系統需求的定義，確定系統的結構，進行系統的概要設計和各部分的功能及結構的具體設計。3.編碼及單元測試在這一階段，依據軟件設計文檔完成了程序模塊或程序單元的編碼。通過程序單元測試，驗證其是否滿意設計規范。4.集成和系統測試程序模塊或程序單元被組裝集成起來成為一個軟件系統，然后進行系統測試。測試完成后即交付用戶運用。5.運行和維護通常這是軟件生命周期中最長的一個階段。假如在運行期發覺了軟件的錯誤，就要修改軟件，可能會重復上述某個或多個階段的活動。特點：依次性,依靠性：下一階段依靠上一階段的完成。推遲實現：階段任務結束形成文檔，并審核后方能進行設計任務，將程序的實現推遲進行。質量保證:文檔完整,文檔評審，避開錯誤積累及放大效應。示意圖：快速原型工作原理：快速原型是利用原型協助軟件開發的一種新思想。經過簡單快速分析，快速實現一個原型，用戶及開發者在試用原型過程中加強通信及反饋，通過反復評價和改進原型，削減誤會，彌補漏洞，適應變化，最終提高軟件質量。廢棄型：也稱快速建立需求規格原型法：先構造一個功能簡單而質量要求不高的模型系統，針對這個模型系統反復的進行分析修改，從而形成較好的設計思想，據此設計出更加完整,精確,一樣牢靠的最終系統，系統構造完成后，原來的模型就被廢棄 追加型：也稱快速建立漸進原型法。它采納按部就班的開發方式，對系統模型作連續精化，即先構造一個功能簡單而且質量要求不高的模型系統，最為最終系統的核心，將系統須要具備的性能逐步添加上去，通過不斷地擴充修改，逐步追加新的要求，直至全部性能全部滿意，此時原型模型也就是最終的產品。階段及任務 原型快速分析：是指在分析者和用戶的緊密協作下，快速確定軟件系統的基本要求，依據原型所要體現的特性（總體結構,處理功能,模擬性能,界面形式等），描述基本需求規格說明，以滿意開發圓形的須要。 原型構造：在快速原型分析的基礎上，依據基本需求規格說明，忽視細微環節只考慮主要特性快速構造一個可運行的系統。 原型運行及評價：是軟件開發人員及用戶頻繁通信,發覺問題,消退誤會的用藥階段，目的是驗證原型的正確程度，進而開發新的并修改原有的需求。 原型修改：依據評價原型的活動結果進行修改。若原型未滿意需求說明的要求，說明對需求說明存在不一樣的理解或實現方案不夠合理，則依據明確的要求快速修改原型。特點 1．增加了軟件開發人員和用戶對系統需求的理解，便于將用戶模糊的功能需求明確化 2．為用戶供應了一種強有力的學習手段 3．易于確定系統的性能，是理解和確定軟件需求規格說明的良好工具 4．依據快速建立漸進原型法建立的原型即為最終的產品利用快速原型化技術可以為軟件開發供應一種完整,敏捷,近似動態的需求規格說明方法。示意圖噴泉模型工作原理：噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用于描述面對對象的軟件開發過程。該模型認為軟件開發過程自下而上周期的各階段是相互重疊和多次反復的，各個開發階段沒有特定的次序要求，并且可以交互進行，可以在某個開發階段中隨時補充其他任何開發階段中的遺漏。階段每階段任務特點：噴泉模型體現了軟件創建所固有的迭代和無間隙的特征。迭代指系統中某個部分經常重復工作多次，無間隙指活動之間沒有明顯的間隙，如在分析和設計之間沒有明顯的界限。示意圖。軟件生命周期：階段,各階段功能,所涉及的內容（圖,工具和文檔）軟件生命周期：是指一個計算機軟件從功能確定,設計到開發勝利投入運用，并在運用中不斷地修改,增補和完善，知道被新的需求所替代而停止該軟件的運用全過程。四個工作階段：初始階段：建立業務模型，定義最終產品視圖，并且確定項目的范圍。精化階段：設計并確定系統的體系結構，制定項目安排，確定資源需求。構建階段：開發出全部構件和應用程序，把它們集成為客戶須要的產品，并且詳盡地測試全部功能。移交階段：把開發出的產品提交給用戶運用各階段功能：1問題定義可行性探討eq\o\ac(○,1)可性探討的任務是以最小的代價在盡可能短的時間內確定問題是否值得解決,是否能夠解決。eq\o\ac(○,2)階段性成果《項目可行性報告》2需求分析階段eq\o\ac(○,1)需求分析的主要任務就是要通過軟件開發人員及用戶的溝通和探討，精確地獲得用戶對系統的具體要求。eq\o\ac(○,2)階段性成果《需求規格說明書》,數據字典,數據流圖（DFD）3概要設計階段eq\o\ac(○,1)劃分出組成系統的物理元素，設計軟件的結構，即確定模塊及模塊間的關系，依據需求分析階段得到的邏輯模型來設計系統的物理模型eq\o\ac(○,2)階段性成果《概要設計說明書》4具體設計階段eq\o\ac(○,1)設計每個模塊的算法，確定每一模塊運用的數據結構，確定模塊接口的細微環節，為每一個模塊設計一個測試用例，編寫具體設計說明書eq\o\ac(○,2)《軟件具體設計》文檔5編碼和單元測試6系統測試7軟件維護階段各階段所涉及的內容（文檔,工具,圖）結構化方法:生命周期中各階段任務.獲得用戶需求,畫數據流圖,數據字典可行性分析,需求分析,設計（概要設計+具體設計）,測試,維護面對對象方法：核心概念,模型面對對象中的基本概念：對象：代表了一個現實的或虛構的實體類：對具有相同數據和相同操作的一組相像對象的定義繼承：子類自動的共享父類中定義的數據和方法的機制多態性：一個名字具有多種語義封裝：將屬性和操作包裝成一個單元，使得對狀態的訪問和修改只能通過封裝供應的接口進行消息：對象間在交互中所傳送的通訊信息關聯：對象之間所存在的聯系模型對象模型：即找尋問題域中的對象，從對象中抽象出類的定義，識別對象的內部特征，定義屬性，識別對象的外部關系，識別主題。動態模型：即建立交互圖,狀態圖和活動圖，進一步定義用例。功能模型：即用例分析，以用例對用戶需求進行規范化描述；為了更好地理解問題，人們常采納建立建立問題模型的方法。模型就是為了理解事物而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。通常，模型由一組圖示符號和組織這些符號的規則組成。模型是一種思索工具，可以把知識規范地表示出來。對于那些因過分困難而不能直接理解的系統，特殊須要建立模型，建模的目的主要是為了削減困難性。一旦建立起模型之后，就要經受用戶和各個領域專家的嚴格審查。模型經常會經過多次必要的修改。用OO方法開發軟件，通常須要建立3種形式的模型：對象模型描述系統數據結構；動態模型描述系統限制結構；功能模型描述系統功能；這三種模型各自從不同的側面反映軟件系統的內容，相互影響,相互制約，有機地結合在一起，全面地表達對目標系統的需求。對象模型表示靜態的,結構化的系統的“數據”性質。描述了系統的靜態結構。面對對象方法強調圍繞對象而不是功能來構造系統。對象模型為建立動態模型和功能模型，供應了實質性的框架。1997年11月，國際對象管理組織OMG批準把UML1。1作為基于面對對象技術的標準建模語言。通常，運用UML的類圖來建立對象模型。在UML中術語“類”的實際含義是，“一個類及屬于該類的對象”狀態模型表示瞬時的,行為化的系統的“限制”性質，它規定了對象模型中的對象的合法變化序列。一旦建立起對象模型之后，就須要考察對象的動態行為。全部對象都具有自己的生命周期。狀態，是對對象屬性值的一種抽象。各對象之間相互觸發就形成了一系列的狀態變化。一個觸發行為稱作一個事務。對象對事務的響應，取決于接受該觸發的對象當時所處的狀態，響應包括改變自己的狀態或者又形成一個新的觸發行為。狀態有持續性，它占用一段時間間隔。狀態及事務密不可分，一個事務隔開兩個狀態，一個狀態隔開兩個事務。事務表示時刻，狀態表示時間間隔。UML中用狀態圖來描繪對象的狀態,觸發狀態轉換的事務及對象的行為。每個類的動態行為用一張狀態圖來描繪，各個類的狀態圖通過共享事務合并起來，從而構成系統的動態模型。動態模型是基于事務共享而相互關聯的一組狀態圖的集合。功能模型表示變化的系統的“功能”性質，它指明白系統應當“做什么”，因此更直接地反映了用戶對目標系統的需求。通常，功能模型由一組數據流圖組成。在OO方法中，數據流圖遠不如在結構化方法中那樣重要。但建立功能模型有助于開發人員更深化地理解問題域，改進和完善自己的設計。UML中供應的用例圖也是進行需求分析和建立功能模型的強有力工具。UML中把用例圖建立起來的系統模型稱為用例模型。運用用例模型代替傳統的功能說明，往往能夠更好地獲得用戶需求，它所回答的問題是“系統應當為每個（或每類）用戶做什么”。面對對象方法,UML：獲得用戶需求,畫用例圖,對象模型,UML中的關系1.面對對象的方法（1）分析：包括問題描述,構建對象模型,構建動態模型,構建功能模型。最終得到的分析文檔包括問題需求的陳述,對象模型,動態模型和功能模型。（2）系統設計：結合問題域的知識和目標系統的體系結構，將目標系統分解為子系統，標識由問題所規定的并發性，設計適當的限制機制組織子系統協調工作，然后選擇數據管理的基本策略，考慮對邊界條件的處理。最終得到的系統設計文檔包括基本的系統體系結構和高層次的決策策略。（3）對象設計：以分析模型為基礎，首先定義類，設計類屬性及操作，為每個操作選擇合適的數據結構并定義算法，調整類結構以強化繼承性；然后創建對象，設計消息以補充對象關聯；通過關聯發覺新的對象或交互條件時，修改類組織以優化對數據的訪問，改善設計結構。最終得到的對象設計文檔包括細化的對象模型,細化的動態模型和細化的功能模型。（4）實現：將設計轉換為特定編程語言代碼并在相應環境運行，同時保持可追蹤性,敏捷性和可擴展性。2.UML：統一建模語言（UML）是一個通用的可視化建模語言，用于對軟件進行描述,可視化處理,構造和建立軟件系統產品的文檔。UML描述了一個系統的靜態結構和動態行為3.獲得用戶需求（1）及用戶進行充分溝通，了解用戶對軟件的需求；（2）識別對象集合及對象間的關系；（3）定義類（包括屬性和操作）并建立類間的層次關系；（4）建立模型來表示對象之間的關系及行為特性。4.用例圖：用例模型描述外部執行者所理解的系統功能。用例模型用于需求分析階段，描述待開發系統的功能要求，扶植軟件設計人員理解系統要做的工作，同時用例模型還可以為其他模型建立,結構設計,實現及測試工作等供應依據。一個用例模型是由若干用例圖組成的，進行用例建模的過程主要包括找尋執行者,找尋用例,描述用例,確定執行者和用例之間的關系等工作，其中找尋執行者和用例是用例建模的關鍵。5.對象模型：對象模型表示靜態的,結構化的系統的“數據”性質。描述了系統的靜態結構。面對對象方法強調圍繞對象而不是功能來構造系統。對象模型為建立動態模型和功能模型，供應了實質性的框架。通常，運用UML的類圖來建立對象模型。在UML中術語“類”的實際含義是，“一個類及屬于該類的對象”6.關系：依靠關聯泛化實現測試：黑盒,白盒設計測試用例白盒測試（結構測試,邏輯驅動測試）：語句覆蓋：設計若干個測試用例，使得被測試的程序中的每條可執行語句至少被執行一次推斷覆蓋：每個推斷至少都獲得一次“真”值和“假”值條件覆蓋：每個推斷中的條件可能的取值至少被執行一次推斷及條件覆蓋：每個推斷的真假值分支至少被執行一遍，并且每個推斷的條件的內部推斷式的真假值分支也要被執行一遍條件組合覆蓋：程序中每個推斷條件的內部推斷式的各種真假值組合可能都至少執行一遍路徑覆蓋：覆蓋程序中全部可能的路徑六種邏輯覆蓋從弱到強的排列依次語句覆蓋-推斷覆蓋-條件覆蓋--推斷條件覆蓋條件組合覆蓋--路徑覆蓋黑盒測試等價類劃分：有效等價類和無效等價類邊界值分析軟件項目管理：項目管理,五大過程,九大知識領域,項目三角形項目管理：是為完成一個預定的目標，而對任務和資源進行規劃,組織和管理的程序項目三角形：時間：反映在項目安排中的項目完成所需時間。資金：即項目的預算，取決于資源的成本，這些資源包括完成任務所需的人員,設備和材料。范圍：項目的目標和任務，以及完成這些目標和任務所需的工時。項目管理的五大過程：啟動過程,安排過程,實施過程,限制過程,收尾過程項目管理的九大知識領域：范圍管理,時間管理,成本管理,質量管理,風險管理,人力資源管理,溝通管理,選購 管理,綜合管理配置管理：配置管理,配置管理項,基線,里程碑配置管理：是一組追蹤和限制活動，它們開始于軟件項目開始時，結束于軟件被淘汰之時。配置管理項：1。計算機程序源代碼和可執行程序2。描述計算機程序的文檔供技術人員或用戶運用3。數據程序內包含的或在程序外的。。。每個配置項的主要屬性出名稱,標識符,文件狀態,版本,作者,日期等基線：是一組配置項，這些配置項不能被隨意修改和變更。基線是軟件生存期中各開發階段末尾的特定點，又稱里程碑。軟件開發各階段的基線：結構化方法及面對對象方法的比較：基本思想；分階段比較1．結構化方法：基本思想：可以概括為自頂向下,逐步求精，采納模塊化技術和功能抽象將系統按功能分解為若干模塊，從而將困難的系統分解成若干易于限制和處理的子系統，子系統又可分解為更小的子任務，最終的子任務都可以獨立編寫成子程序模塊，模塊內部由依次,選擇,循環等基本限制結構組成。2．面對對象方法基本思想：面對對象方法的動身點和基本原則，是盡可能模擬人類習慣的思維方式，使開發軟件的方法及過程盡可能接近人類相識世界,解決問題的方法及過程，將客觀世界中的實體抽象為問題域中的對象。運用現實的概念抽象地思索問題，從而自然地解決問題，保證軟件系統的穩定性和可復用性以及良好的維護性。3．兩種方法的比較：傳統的結構化方法，是軟件工程中最為成熟的方法。對于能夠預先確定需求的系統的開發，采納結構化方法特別有效，但是對于需求是模糊的或隨時間變化的系統開發這種方法不能適應。面對對象方法，對于需求不能預先確定的系統的開發，可采納面對對象方法結合，這樣就能夠結合面對對象方法所具有的穩定性好,可復用性好和可維護性好的特點。需求分析階段：結構化方法：采納自頂向下功能分解的方法，強調邏輯功能而不是實現功能的具體方法，運用圖形進行系統分析并表達分析的結果--數據流圖，運用結構化分析方法獲得的需求規格說明書由數據流圖,數據詞典及補充材料組成。面對對象方法：面對對象分析的關鍵是識別出問題域中的對象，并分析它們之間的關系，最終建立起問題域的簡潔,精確,可理解的正確模型。面對對象分析模型通常包括對象模型,動態模型和功能模型。對象模型是最重要,最基本,最核心的。設計階段：結構化軟件是功能的集合,通過模塊調用實現系統。面對對象軟件是事物的集合,通過對象及聯系實現系統。結構化軟件=過程+數據,以過程為中心。面對對象軟件=數據+相應操作,以數據為中心。結構化軟件采納依次處理方式,由過程驅動限制;面對對象軟件采納交互式,并行處理方式,由消息驅動限制;結構化方法的重點是設計；面對對象方法的重點是分析。結構化方法更適合數據類型比較簡單的軟件項目的開發；面對對象方法更適合大型困難的軟件項目的開發練習題：看書上實例A，理解RUP過程試探討RUP過程的優缺點RUP過程主要適用于何種項目？用面對對象方法開發軟件時及結構化方法開發軟件時相比較，軟件的生命周期有何不同？這種差異帶來了什么后果？為什么說廣州本田牌汽車是小汽車類的特化，而發動機不是小汽車類的特化？什么是對象？它及傳統的數據有何區分？試用面對對象分析方法設計下述程序：在顯示器屏幕上圓心坐標為（100,100）的位置畫一個半徑為40的圓，在圓心坐標為（200,300）的位置畫一個半徑為20的圓，在圓心坐標為（400,150）的位置畫一條弧，起始角為30度，結束角度為120度，半徑為50.思索題1,一個程序能夠既正確又不牢靠嗎？請說明你的答案。軟件牢靠性是程序在給定的時間間隔內按規格說明書的規定勝利地運行的概率。軟件牢靠性即包含正確性又包含健壯性。即程序在正常環境下應能正確地完成預期功能，在意外環境下，也應能作出適當的響應。假如某程序在正常環境下可正常運行，在異樣環境下不能作出適當的響應，則該項程序就是既正確又不牢靠思索題2,為什么在開發軟件的過程中變化既是必要的又是不可避開的？為什么必需進行配置管理？在軟件開發過程中，下述緣由會導致軟件配置項發生變化，新的市場條件導致需求或業務規則變化，客戶的需求也會或多或少地發生變化。企業改組或業務縮減，引起項目優先級或軟件工程隊伍結構變化，預算或進度限制，導致對目標系統的重新定義，發覺了前期階段的錯誤，必需加以改正。因此，在開發軟件的過程中，變化既是必要的，又是不可避開的。假如不能適當地限制和管理變化，勢必造成混亂并產生很多嚴峻的錯誤。軟件配置管理是在軟件的整個生命期內管理變化的一組活動，可以認為軟件配置管理是應用于整個軟件生命期的軟件質量保證活動，是特地用于管理變化的軟件質量保證活動，軟件配置管理的目標是使變化更正確且更簡單被適應，在必需變化時削減所需花費的工作量，綜上所述，進行配置管理是特別必要的3,某些軟件工程師不同意“目前國外很多軟件開發組織把60%以上的人力用于維護已有的軟件”的說法。他們爭辯說：“我并沒有花費我的60%的時間去改正我所開發的程序中的錯誤”。

請問，你對上述爭辯有何看法？ 答：軟件維護并非僅僅是改正程序中的錯誤，它還包括適應性維護,完善性維護和預防性維護。糾錯性維護只占維護活動總量的1/5，“目前國外很