軟件工程複習（二）

時間 2019-11-13

標籤軟件工程複習简体版

原文原文鏈接

1. 面向對象基本思想: 分析、設計、編程
程序員

OO方法認爲，客觀世界是由各類各樣的對象組成的，每種對象都有各自的內部狀態和運動規律，不一樣的對象之間的相互做用和聯繫就構成了各類不一樣的系統。當咱們設計和實現一個客觀系統時，如能在知足需求的條件下，把系統設計成由一些不可變的（相對固定）部分組成的最小集合，這個設計就是最好的。而這些不可變的部分就是所謂的對象。數據庫

面向對象中的三種模型編程

面向對象分析方法:安全

手法架構	Shlaer &Mellor 法框架	Coad& Yourdon法分佈式	OMT法模塊化	Booch法函數
概述工具	（S&M方法）將意義模型做爲基礎	組合E-R圖、S&M方法、OOP及知識庫系統的概念而發展而來	從結構化分析繼承數據流和狀態轉換圖，對象、建摸受E-R圖等的影響	擴充了Ada方法論的Booch 法(HOOD, OOSD)，也受E-R，JSD法的影響
對象的靜態關係	信息模型(information Model)	對象圖 (Object Diagram)	對象模型(Object Model)	靜態模型(Static Model)
對象的動態關係	狀態模型 (State Model)	對象狀態圖 (Object State Diagram)	動態模型 (Dynamic Model)	動態模型 (Dynamic Model)
功能	過程模型 (Process Model)	服務圖 (Service Chart)	功能模型 (Functional Model)	--------

面向對象設計原則:

把分析階段獲得的需求轉變成符合成本和質量要求的、抽象的系統實現方案的過程

開-閉原則（The Open-Closed Principle, OCP）：軟件實體（類、模塊、函數等）能夠擴展（擴展是開放），可是不能夠修改（更改是封閉的）

單一職責原則（Single Responsibility Principle，SRP）：僅有一個引發它變化的緣由

里氏代換原則（Liskov Substitution Principle，LSP）：子類必須可以替換掉其父類。 LSP是繼承複用的基石，只有當衍生類能夠替換其基類，軟件功能或行爲不受影響時，基類才能真正被複用

依賴倒轉原則（Dependence Inversion Principle ，DIP）：高層模塊不該該依賴低層模塊，即抽象不該該依賴細節，細節依賴抽象。強調接口編程，不要對實現編程

接口隔離原則 （ interface separate principle, ISP ）：使用多個專門的接口比使用單一的總接口要好。

合成/聚合複用原則（Composition/Aggregation Reuse Principle，CARP）：儘可能使用合成/聚合（「has a」的關係），儘可能不使用類繼承（「is a」的關係），有助於保持每一個類的封裝

迪米特法則（Law of Demeter，LoD）：若是兩個類沒必要彼此直接通訊，那麼這兩個類就不該當發生直接的相互做用。類之間的耦合越弱，就越有利於複用。

面向對象系統的構造

面向對象分析

分析是提取和整理用戶需求，並創建問題域精確模型的過程。

面向對象分析通常須要創建3個模型（功能模型、對象模型和動態模型）並定義相應的服務

對象是OO方法的主體，對象至少應有如下特徵：
l）模塊性。即對象是一個獨立存在的實體，從外部能夠了解它的功能，但其內部細節是「隱蔽」的，它不受外界干擾。對象之間的相互依賴性很小，於是能夠獨立地被其它各個系統所選用。
2)繼承和類比性。事物之間都有必定的相互聯繫，事物在總體結構中都會佔有它自身的位置。在對象之間有屬性關係的共同性，在OO方法學中稱之爲繼承性次結構是靠繼承關係維繫着的。
3)對象是一個被嚴格模塊化了的實體，稱之爲封裝（encapsulation）。這種封裝了的對象知足軟件工程的一切要求，並且能夠直接被面向對象的程序設計語言所接受。

對象的行爲經過操做展現，外界不能夠直接訪問其內部屬性（封裝性），操做的實現對用戶透明

類是對具備相同內部狀態和外部行爲對象結構的描述，它定義了表示對象狀態的實例變量集和表示對象行爲的方法集。子類能夠繼承父類的實例變量和方法、重載父類的某個行爲（虛函數），同時還能夠定義新的變量和方法。

消息傳遞是對象間唯一的交互方式

2. 軟件需求：業務需求，用戶需求，功能需求

業務需求：反映組織機構或客戶對系統、產品的歸納性要求，包括所要達到的業務目標，由項目視圖與範圍文檔說明。

用戶需求：描述用戶使用系統而要完成的各類任務，由用例（use case）文檔或方案腳本說明。

功能需求：定義開發人員必須實現的軟件功能，它源於用戶需求，是軟件需求說明書中重要的組成部分。

3. 軟件工程定義： 是什麼樣的學科。

軟件工程是從計算機科學中的一個學科方向發展成爲與之並重的一門獨立學科，重點研究如何以系統的、可控的、高效的方式開發和維護高質量軟件的問題。

4. 軟件的可維護性

軟件可維護性即維護人員對該軟件進行維護的難易程度,具體包括理解、改正、改動和改進該軟件的難易程度。

決定可維護性的因素：

1).系統的大小

2).系統的年齡

3).結構合理性

可維護性可經過7個質量特性來衡量:

1).可理解性

2).可測試性

3).可修改性

4).可靠性

5).可移植性

6).可以使用性

7).效率

5. 軟件過程

軟件過程(Software Procedure) 是指軟件整個生命週期，從需求獲取，需求分析，設計，實現，測試，發佈和維護一個過程模型。一個軟件過程定義了軟件開發中採用的方法，但軟件工程還包含該過程當中應用的技術——技術方法和自動化工具。過程定義一個框架，爲有效交付軟件工程技術，這個框架必須建立。軟件過程構成了軟件項目管理控制的基礎，而且建立了一個環境以便於技術方法的採用、工做產品（模型、文檔、報告、表格等）的產生、里程碑的建立、質量的保證、正常變動的正確管理。

軟件過程可歸納爲三類：基本過程類、支持過程類和組織過程類。基本過程類包括獲取過程、供應過程、開發過程、運做過程，維護過程和管理過程。支持過程類包括文檔過程、配置管理過程、質量保證過程、驗證過程、確認過程、聯合評審過程、審計過程以及問題解決過程。組織過程類包括基礎設施過程、改進過程以及培訓過程。

6.軟件的風險管理

風險識別、風險分析和評估、風險管理策略、風險解決和風險監控五部分，它能讓風險管理者主動「攻擊」風險，進行有效的風險管理。在項目管理中，創建風險管理策略和在項目的生命週期中不斷控制風險是很是重要的。

7.軟件測試用例有那2大類

經常使用的軟件測試方法有兩大類：靜態測試方法和動態測試方法。

靜態測試就是靜態分析，對模塊的源代碼進行研讀，查找錯誤或收集一些度量數據，並不須要對代碼進行編譯和仿真運行。靜態測試採用人工檢測和計算機輔助靜態分析手段進行檢測。

動態測試是經過觀察代碼運行時的動做，來提供執行跟蹤、時間分析，以及測試覆蓋度方面的信息。動態測試經過真正運行程序發現錯誤。經過有效的測試用例，對應的輸入/輸出關係來分析被測程序的運行狀況。

八、軟件中遺留的錯誤數量和已經發現的錯誤數量之間是成「正比」的。

九、3種過程模型中：敏捷過程模型和傳統模型的區別

敏捷開發是近些年興起的一種軟件開發與管理的思想，以其靈活性、操做性獲得軟件行業的普遍關注。敏捷開發方法是一組開發方法的統稱，包括極限編程、Scrum、精益開發和動態系統開發方法(DS-DM)、特徵驅動開發(FDD)等。它的基本原則有迭代式開發、增量交付、互動式開發、持續集成等。在軟件開發過程當中，敏捷開發具備開發精確、高質量、高速度、高投資回報、高效率等優勢，所以敏捷開發方法愈來愈受到廣大程序員的青睞。敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成果都通過測試，具有集成和可運行的特徵.換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。

敏捷開發路線圖以下：

1. Test-Driven Development,測試驅動開發。

2. Continuous Integration，持續集成。

3. Refactoring，重構。

4. Pair-Programming:結對編程。

5. Stand up，站立會議。

6. Frequent Releases，小版本發佈.

7.MinimalDocumentation，較少的文檔。

8.CollaborativeFocus，以合做爲中心，表現爲代

碼共享。

9.CustomerEngagement，現場客戶。

10。AutomatedTesting，自動化測試。

11.AdaptivePlanning，可調整計劃。

敏捷軟件開發宣言：

個體和交互賽過過程和工具；

能夠工做的軟件賽過面面俱到的文檔；

客戶合做賽過合同談判；

響應變化賽過遵循計劃

10.軟件工程定義，集合實際談談軟件工程的理解

（1）軟件工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把通過時間考驗而證實正確的管理技術和當前可以獲得的最好的技術方法結合起來。它是從計算機科學中的一個學科方向發展成爲與之並重的一門獨立學科，重點研究如何以系統的、可控的、高效的方式開發和維護高質量軟件的問題。

（2）當技術尚未發展到必定程度時，軟件的開發就徹底是我的英雄主義的或是手工做坊式的開發。一個好的編程人員，能夠獨立製做出軟件。但技術的日益完善，所處理的問題日益複雜對軟件的開發提出了更高的要求，單一的做戰方式不能知足軟件開發的複雜度。這也就是60年代的軟件危機。必須改變手工做坊式的開發方法，採起工程化的開發方法和工業化的生產技術。這是軟件工程應運而生。簡單的邏輯上講，軟件工程就是將現實世界中複雜無序的高層問題，經過人的做用，轉化爲計算機（機器）能夠解決的簡單有序的底層問題。因爲有了「現實複雜」到「機器簡單」的過程，軟件工程就不只僅是單一的編程過程了。它包括系統分析->建模->概要設計->詳細設計->編碼->測試->維護。編碼能夠理解爲編程，這個只佔總時間的20％。編程只是一小部分。若是說把軟件工程比做建築業的話，是講的是怎麼進行有效組織順利完成目標，那麼編程只是工程設計到的一項技能，如同建築中砌磚，講究如何把磚砌的好。

11.軟件有哪些質量特性如何在軟件開發是保持這些質量特性

（1）功能性：是指當軟件在指定條件下使用，軟件產品知足明確和隱含要求功能的能力。

適合性：是指軟件產品與指定的任務和用戶目標提供一組合適的功能的能力。

準確性：是指軟件產品具備所需精確度的正確或相符的結果及效果的能力。

互操做性：是指軟件產品與一個或多個規定系統進行交互的能力。

保密安全性：是指軟件產品保護信息和數據的能力，以使未受權的人員或系統不能閱讀或修改這些信息和數據，但不拒絕受權人員或系統對其的訪問。

功能依從性：是指軟件產品依附與同功能性相關的標準、約定或法規以及相似規定的能力。

（2）可靠性：在指定條件下使用時，軟件產品維持規定的性能級別的能力。

成熟性：是指軟件產品避免因軟件中錯誤發生而致使失效的能力。

容錯性：是指在軟件發生故障或違反指定接口的狀況下，軟件產品維持規定的性能級別的能力。

易恢復性：是指在失效發生的狀況下，軟件產品重建規定的性能級別並恢復受直接影響的數據的能力。

可靠性依從性：是指軟件產品依附與同可靠性相關的標準、約定或法規以及相似規定的能力。

創建以可靠性爲核心的質量標準。選擇適應的開發方法。最大限度地重用現有的成熟軟件。使用開發管理工具。增強測試。容錯設計。

（3）易用性：是指在指定條件下使用時，軟件產品被理解、學習、使用和吸引用戶的能力。

易理解性：是指軟件產品使用戶能理解軟件產品是否合適以及如何能將軟件用於特定的任務和使用環境的能力。

易學性：是指軟件產品使用戶能學習它的能力。

易操做性：是指軟件產品使用戶能操做和控制它的能力。

吸引性：是指軟件產品吸引用戶的能力。

易用性依從性：是指軟件產品依附與同易用性相關的標準、約定、風格指南或法規以及相似規定的能力。

（4）效率：是指在規定條件下，相對於所用資源的數量，軟件產品可提供適當的性能的能力。

時間特性：是指在規定條件下，軟件產品執行其功能時，提供適當的響應時間和處理時間以及吞吐率的能力。

資源利用性：是指在規定條件下，軟件產品執行其功能時，提供合適的數量和類型的資源的能力。

效率依從性：是指軟件產品依附與同效率相關的標準或約定的能力。

（5）維護性：是指軟件產品可被修改的能力，修改可能包括修正，改進或軟件適應環境、需求和功能規格說明中的變化。

易分析性：是指軟件產品診斷軟件中的缺陷或失效緣由，以及斷定待修改的部分的能力。

易改變性：是指軟件產品使指定的修改能夠被實現的能力。

穩定性：是指軟件產品避免因爲軟件修改而形成意外結果的能力。

易測試性：是指軟件產品使已修改軟件能被確認的能力。

維護性依從性：是指軟件產品依附與同維護性相關的標準或約定的能力。

在需求分析、軟件設計、軟件代碼、軟件系統交付、軟件維護等每一個階段作好的審查和複審工做，以提升軟件的可維護性。

（6）可移植性：是指軟件產品從一種環境遷移到另外一種環境的能力。

適應性：是指軟件產品無需採用有別於爲考慮該軟件的目的而準備的活動或手段，就可能適應不一樣的指定環境的能力。

易安裝性：是指軟件產品在指定環境中被安裝的能力。

共存性：是指軟件產品在公共環境中同與其分享公共資源的其餘獨立軟件共存的能力。

易替換性：是指軟件產品在環境相同、目的相同的狀況下替代另外一個指定軟件產品的能力。

可移植性依從性：是指軟件產品依附與同可移植性相關的標準或約定的能力。

儘可能用高級語言編寫系統中對效率要求不高的部分，統一高級語言，採用系列機，模擬與仿真、寫跨平臺代碼、多用開源庫。

12. 軟件測試有哪些階段？每一個階段有哪些目標？採用哪些技術？

按照開發階段劃分，軟件測試可分爲單元測試、集成測試，系統測試和驗收測試.

（1）單元測試：目標針對每一個單元的測試，以確保每一個模塊能正常工做爲目標。可使用junit等一些工具，或其餘一些代碼覆蓋率工具幫助分析測試用例的覆蓋程度。

（2）集成測試：對已測試過的模塊進行組裝，進行集成測試。目的在於檢驗與軟件設計相關的程序結構問題。功能性測試。使用黑盒測試技術針對被測模塊的接口規格說明進行測試。非功能性測試。對模塊的性能或可靠性進行測試。

（3）系統測試：檢驗軟件產品可否與系統的其餘部分（好比，硬件、數據庫及操做人員）協調工做。

a、爲項目指定一個測試工程師負責貫徹和執行系統測試活動；

b、測試組向各事業部總經理/項目經理報告系統測試的執行情況；

c、系統測試活動遵循文檔化的標準和過程；

d、向外部用戶提供經系統測試驗收經過的預部署及技術支持；

e、創建相應項目的（BUG）缺陷庫，用於系統測試階段項目不一樣生命週期的缺陷記錄和缺陷狀態跟蹤；

f、按期的對系統測試活動及結果進行評估，向各事業部經理/項目辦總監/項目經理彙報/提供項目的產品質量信息及數據；

（4）驗收（用戶）測試：檢驗軟件產品質量的最後一道工序。主要突出用戶的做用，同時軟件開發人員也應有必定程度的參與。

經過文檔審覈、源代碼審覈、配置腳本審覈、測試程序或腳本審覈、可執行程序測試等來實現。

13.什麼是面向服務的方法？ SOA 面向服務的架構分爲那幾個層次？

（1）它將應用程序功能做爲服務發送給最終用戶或者其餘服務，採用表示的標準方式實現。它是一個組件模型，它將應用程序的不一樣功能單元（稱爲服務）經過這些服務之間定義良好的接口和契約聯繫起來。

（2）WSDL，UDDI和SOAP是SOA基礎的基礎部件。WSDL用來描述服務；UDDI用來註冊和查找服務；而SOAP，做爲傳輸層，用來在消費者和服務提供者之間傳送消息。

1四、軟件過程的評估有哪些內容？有哪些評估方式和類型？

軟件過程評估的內容有：軟件需求獲取、分析、開發等能力;項目計劃能力..項目監督和控制能力..合同管理能力..軟件度量指標設定、度量工具和方法..軟件質量保證和管理流程、手段和方法等..技術開發、革新、創新.產品的定義、設計、實現..產品集成，項目集成管理..組織過程定義、調整和改進的能力。配置管理、維護、風險識別、控制和管理。

評估方式： 自我評估包括「以團隊爲基礎的評估」和「持續型評估」.

評估類型：

A類評估。全面綜合的評估方法，要求在評估中全面覆蓋評估中所使用的模型，而且在評估結果中提供對組織的成熟度等級的評定結果。

B類評估。在開始時作部分自我評估，並集中於須要關注的過程域。不評定組織的成熟度等級。

C類評估，也稱爲快估。主要是檢查特定的風險域，找出過程當中的問題所在。

15.微軟解決方案框架是什麼？ MSF 有哪些子過程（階段內容）？

微軟解決方案框架結構(MSF)是「一組創建、開發和實現分佈式企業系統應用的工做模型、開發準則和應用指南」。它幫助企業融合商業和技術的目標，下降採用新技術後系統總體的費用，以及成功的應用微軟技術整合商業過程的方法。

構思階段(Envisioning):

一、目標：建立一個關於項目的目標、限定條件和解決方案的架構

二、團隊的工做重點

a)肯定業務問題和機會

b)肯定所需的團隊技能