標籤:
軟體工程基本概念
軟體危機
軟體的功能、規模及複雜性與日俱增,軟體的複雜性達到了它的開發人員難以控制的程度
這種情況導致了嚴重的後果: 軟體可靠性下降 開發效率低下 維護極為困難
這使軟體開發人員陷入困境,人們稱之為“軟體危機”
解決軟體危機
軟體開發行業的研究
1. 程式設計方法學的研究
結構化程式設計方法
物件導向程式設計方法
2. 軟體工程學的研究
用工程學的方法進行軟體的開發與維護,並對軟體生產過程進行工程化的管理
3. 其它方面
並發程式設計
資料結構與演算法
程式設計語言 ……
軟體工程的定義
概括地說,軟體工程是指導電腦軟體開發和維護的一門工程學科。採用工程化的方法來開發和維護軟體,把經過時間考驗而證明正確的工程管理技術和當前能夠得到的最好的技術方法結合起來,以經濟地開發出高品質的軟體並有效地維護它,這就是軟體工程。
軟體工程的內容
針對軟體生命週期全過程及其每個具體階段的工程方法、技術細則、文檔規範、支援人員、管理制度、人員組織以及品質保證體系等。每個軟體開發人員必須按工程的統一要求行事,不能隨意地自由發揮。每個開發階段都要產生健全的、符合工程規範的文檔。軟體產品是這些文檔的總合,而不僅僅是程式。
軟體工程三要素
1. 方法:完成軟體開發的各項任務的技術方法,為軟體開發提供 “如何做” 的技術
2. 工具:為運用方法而提供的自動的或半自動的軟體工程的支撐環境
3. 過程:為了獲得高品質的軟體所需要完成的一系列任務的架構,它規定了完成各項任務的工作步驟,如何將軟體工程方法與軟體工具相結合,合理、及時地進行軟體開發
我們在項目中採用的方法、工具、過程
方法:物件導向方法
工具:EA
過程:基於原型的增量迭代軟體開發過程
軟體生命週期(一)
1. 可行性分析階段
本階段的主要任務:系統分析員在使用者的配合下對使用者的要求和現有的環境進行深入調查並寫出調研報告,從經濟可行性、技術可行性、操作可行性、法律可行性等方面研究並論證該項目的可行性,即該項目是否值得去做,是否存在可行的解決辦法。
本階段的主要成果:可行性分析報告。
2. 需求分析階段
本階段的主要任務:系統分析員和使用者反覆討論和商量,充分交流資訊,確定待開發的軟體系統“做什麼”,確定軟體系統的功能需求和非功能需求,用某種方法和工具構件軟體系統模型,並編寫軟體需求規格說明書。
本階段的主要成果:軟體需求規格說明書(Software Requirements Specification,即SRS)。
軟體生命週期(二)
3. 系統設計階段
本階段的主要任務:根據需求分析階段確定的功能需求和非功能需求,對整個系統進行總體架構設計、詳細功能設計和資料庫設計等。簡單來說,需求分析階段回答“做什麼”的問題,而系統設計階段要回答“怎麼做”的問題。設計階段又分為概要設計和詳細設計。概要設計是以需求分析的結果為依據定義系統的主要構成成分和它們之間的關係。而詳細設計是定義每個系統成分內部的構造細節。
本階段的主要成果:概要設計說明、詳細設計說明書、資料庫設計說明書。
4. 系統實現階段: 通常也稱為編碼階段。
本階段的主要任務:根據詳細設計說明書,用某種選定的程式設計語言把詳細設計的結果轉化成機器可啟動並執行原始碼,這是一個編寫和偵錯工具的過程。
本階段的主要成果:通過單元測試的原始碼。
軟體生命週期(三)
5. 測試階段
本階段的主要任務:通過各種軟體測試方法和測試載入器,使軟體的Bug降到最低。
本階段的主要成果:軟體測試報告。
6. 維護階段
本階段的主要任務:通過各種必要的維護活動使系統持久地滿足使用者的需要。
通常維護活動有四類:
改正性維護:診斷和改正系統使用過程中發現的軟體錯誤。
適應性維護:修改軟體以適應環境的變化。
完善性維護:根據使用者的要求改進或擴充軟體使它更完善。
預防性維護:即修改軟體為將來的維護活動做準備。
本階段的主要成果:軟體問題報告、軟體變動記錄、軟體維護記錄。
軟體開發過程
軟體開發過程是在軟體生命週期的軟體系統開發過程中,一系列活動和軟體產生結果的集合。軟體過程模型描述軟體開發過程的各項活動、角色、產品及其相互關係的模型。
目前有若干軟體過程模型,各種模型有其不同的特點,並適用於不同的開發方法。例如,瀑布模型、迴圈模型、螺旋模型、增量模型和噴泉模型等。
不同的軟體開發方法和軟體開發模型要求有不同的工程體系。從曆史看,使用最多的是結構化方法和瀑布模型。代表當前技術主流的是物件導向方法和噴泉模型。
整合模組化語言UML
如同蓋一座高樓大廈需要先畫建築圖建立模型一樣,在軟體系統開發的系統分析和設計階段時,我們通常會使用建模技術為系統建立模型。在軟體工程發展過程中,出現了很多建模技術。最終,IBM的整合模組化語言UML成為業界認同的統一建模技術。
整合模組化語言UML(Unified Modeling Language)是專門用來進行軟體系統設計和架構建模的一門可視化建模語言,它通過各種圖示展示了軟體系統的方方面面。
UML圖有很多種,對於程式員來說,最頻繁使用的莫過於類圖。類圖主要是用來顯示系統中的類、介面以及它們之間的靜態結構和關係的一種靜態模型。類圖中最基本的元素是類、介面。軟體設計師設計出類圖後,程式員就可以用代碼實作類別圖中包含的內容。
使用類圖表示關係
類和類、類和介面、介面和介面之間存在一定關係,共有六種類型:分別是實現關係、泛化關係、關聯關係、依賴關係、彙總關係、組合關係,
1. 實現關係是指介面及其實作類別之間的關係。
2. 泛化關係(Generalization)是指對象與對象之間的繼承關係。
3. 關聯關係(Association)是指對象和對象之間的串連,它使一個對象知道另一個對象的屬性和方法。在Java中,關聯關係的代碼錶現形式為一個對象含有另一個對象的引用。 關聯關係有單向關聯和雙向關聯。
4. 依賴 (Dependency) 關係是一種弱關聯關係。依賴關係在Java中的具體代碼錶現形式為B為A的構造器或方法中的局部變數、方法或構造器的參數、方法的傳回值,或者A調用B的靜態方法。
5. 彙總(Aggregation)是關聯關係的一種特例,它體現的是整體與部分的擁有關係,即“has a”的關係。此時整體與部分之間是可分離的,它們可以具有各自的生命週期,部分可以屬於多個整體對象,也可以為多個整體對象共用,所以彙總關係也常稱為共用關係。(比如:部門和員工)
6. 組合(Composition)也是關聯關係的一種特例,它同樣體現整體與部分間的內含項目關聯性,即“contains a”的關係。但此時整體與部分是不可分的,部分也不能給其它整體共用,作為整體的對象負責部分的對象的生命週期。這種關係比彙總更強,也稱為強彙總。(比如:公司和部門)
物件導向系統分析與設計
在物件導向技術中,建造整個軟體系統的過程常常被稱為物件導向的分析和設計(Object-Oriented Analysis and Design,OOAD)。對於我們要開發的軟體系統來說,OOAD解決了系統是什麼(物件導向的系統分析,即OOA)以及如何做的問題(物件導向的系統設計,即OOD),OOP只是用程式設計語言去實現該系統。
一般來說,OOAD工作一般由需求分析師、系統分析員、系統架構師來完成,而OOP則由程式員來完成。但是,對於程式員來說,掌握OOD技術,對於編寫高品質的代碼以及個人技術成長和職業規劃來說,有特別重要的意義。
物件導向軟體工程與UML